From bnocera at redhat.com  Sat Nov  1 00:01:57 2008
From: bnocera at redhat.com (Bastien Nocera)
Date: Sat, 01 Nov 2008 00:01:57 +0000
Subject: Dia has .la files
In-Reply-To: <870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>
	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>
	<870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>
Message-ID: <1225497717.3450.256.camel@cookie.hadess.net>

On Fri, 2008-10-31 at 15:12 -0600, Jerry James wrote:
> On Fri, Oct 31, 2008 at 1:55 PM, Colin Walters <walters at verbum.org> wrote:
> > On Fri, Oct 31, 2008 at 3:46 PM, Debarshi Ray <debarshi.ray at gmail.com> wrote:
> >> I noticed that the dia package has %{_libdir}/%{name}/*.la files. Any
> >> particular reason for them to be there? Doesn't guidelines ask us to
> >> remove them?
> >
> > Yes, please remove them.  We should not encourage the libtool agenda
> > to redefine how shared libraries work on our platform.
> 
> I've got quite a collection of .la files under /usr/lib64 on my Fedora
> 9 x86_64 machine.  All of the following packages contain at least one
> .la file:
<snip>
> bluez-utils

Obsolete package, bluez doesn't have any .la files.
<snip>
> gnome-bluetooth-libs

Fixed in CVS.

Cheers



From mtasaka at ioa.s.u-tokyo.ac.jp  Sat Nov  1 00:12:03 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Sat, 01 Nov 2008 09:12:03 +0900
Subject: Dia has .la files
In-Reply-To: <870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>
	<870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>
Message-ID: <490B9ED3.8000808@ioa.s.u-tokyo.ac.jp>

Jerry James wrote, at 11/01/2008 06:12 AM +9:00:
> I've got quite a collection of .la files under /usr/lib64 on my Fedora
> 9 x86_64 machine.  All of the following packages contain at least one
> .la file:

> ImageMagick

c.f.
https://bugzilla.redhat.com/show_bug.cgi?id=185237

Regards,
Mamoru




From mw_triad at users.sourceforge.net  Sat Nov  1 00:35:37 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Fri, 31 Oct 2008 19:35:37 -0500
Subject: Dia has .la files
In-Reply-To: <faa16b610810311632w71f4937evcc494ff88642005a@mail.gmail.com>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>	<870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>	<faa16b610810311421m56051690ia378ebde7ab693f8@mail.gmail.com>	<91705d080810311615u7a00ddai936c78e4d6de0119@mail.gmail.com>	<faa16b610810311617v5ae4d6e4ife8e5368073ad563@mail.gmail.com>	<91705d080810311624tdfd2f91x2b0e8fc15edfd099@mail.gmail.com>
	<faa16b610810311632w71f4937evcc494ff88642005a@mail.gmail.com>
Message-ID: <geg88p$p2r$1@ger.gmane.org>

Colin Walters wrote:
> On Fri, Oct 31, 2008 at 7:24 PM, Dan Nicholson <dbn.lists at gmail.com> wrote:
>> OK, now convince the libtool developers to break everyone's `make
>> distcheck'.
> 
> Or alternatively convince the automake people that it shouldn't be in
> the business of software lifecycle management (make uninstall) any
> more than people should be coding/overriding build systems (make;make
> install) inside RPM spec files.

...and once you've done that, you can convince them that building 
rpm/apt/whatever on, say, AIX, should be a prerequisite before building 
grep/make/etc? Wait... somehow I'm not too sure that will work well.

+1 to fixing it for systems with sane package managers. -1 to removing 
functionality that may be wanted on more exotic systems.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Will your shell have salvation? Only if it's Bourne Again.



From mw_triad at users.sourceforge.net  Sat Nov  1 00:38:19 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Fri, 31 Oct 2008 19:38:19 -0500
Subject: Fedora on EEE?
In-Reply-To: <1225495720.25414.381.camel@ignacio.lan>
References: <geclck$mlc$2@ger.gmane.org>	<d25f375f0810301702p2ab95cdfla61d6a552555090e@mail.gmail.com>	<gef7ir$fm9$1@ger.gmane.org>
	<1225495720.25414.381.camel@ignacio.lan>
Message-ID: <geg8dr$p2r$2@ger.gmane.org>

Ignacio Vazquez-Abrams wrote:
> On Fri, 2008-10-31 at 10:17 -0500, Matthew Woehlke wrote:
>> Pavel Shevchuk wrote:
>>> Synaptics driver has multitouch for years. I used macbook-style two
>>> finger scroll 3 years ago on my acer laptop. Check "man synaptics"
> 
>> Ok, so it's not new to Acer/Xandros, just that they're using the right 
>> driver? Nice to know.
> 
> No, it's that they've configured it the right way. Look for
> VertTwoFingerScroll, HorizTwoFingerScroll, TapButton2, and TapButton3 in
> the synaptics man page.

Close enough :-). The point is, you're telling me it should (with 
sufficient configuration prodding) work fine with Fedora, i.e. there 
isn't anything "magic" about Xandros (custom drivers, for example).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Will your shell have salvation? Only if it's Bourne Again.



From forum at ru.bir.ru  Sat Nov  1 01:11:56 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Sat, 01 Nov 2008 04:11:56 +0300
Subject: Fedora 9 spins beta???
In-Reply-To: <loom.20081030T111628-898@post.gmane.org>
References: <gec0ih$fl9$1@ger.gmane.org>	<loom.20081030T103319-30@post.gmane.org>	<gec437$r9p$1@ger.gmane.org>
	<loom.20081030T111628-898@post.gmane.org>
Message-ID: <gegacs$rir$1@ger.gmane.org>

Kevin Kofler ?????:
> Pavel Alexeev (aka Pahan-Hubbitus <forum <at> ru.bir.ru> writes:
>> Off course. I do not known what is Electronic Lab, but I come here for 
>> XFCE spin, which is not in official spins.
>>
>> So if it is wrong maillist for that question may you point me right?
> 
> Well, I think the custom spins are still considered "beta". But for a definite 
> answer, you'll have to wait, it's the right mailing list, the people who know 
> the answer just haven't seen your post yet.

Ok, tank you, Kevin. I wait other answers...

And one more question concerning this: Do you plan make XFCE spin 
official in near future?

> 
>         Kevin Kofler
> 



From ivazqueznet at gmail.com  Sat Nov  1 01:19:24 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 31 Oct 2008 21:19:24 -0400
Subject: Fedora on EEE?
In-Reply-To: <geg8dr$p2r$2@ger.gmane.org>
References: <geclck$mlc$2@ger.gmane.org>
	<d25f375f0810301702p2ab95cdfla61d6a552555090e@mail.gmail.com>
	<gef7ir$fm9$1@ger.gmane.org> <1225495720.25414.381.camel@ignacio.lan>
	<geg8dr$p2r$2@ger.gmane.org>
Message-ID: <1225502364.25414.410.camel@ignacio.lan>

On Fri, 2008-10-31 at 19:38 -0500, Matthew Woehlke wrote:
> Ignacio Vazquez-Abrams wrote:
> > On Fri, 2008-10-31 at 10:17 -0500, Matthew Woehlke wrote:
> >> Pavel Shevchuk wrote:
> >>> Synaptics driver has multitouch for years. I used macbook-style two
> >>> finger scroll 3 years ago on my acer laptop. Check "man synaptics"
> > 
> >> Ok, so it's not new to Acer/Xandros, just that they're using the right 
> >> driver? Nice to know.
> > 
> > No, it's that they've configured it the right way. Look for
> > VertTwoFingerScroll, HorizTwoFingerScroll, TapButton2, and TapButton3 in
> > the synaptics man page.
> 
> Close enough :-). The point is, you're telling me it should (with 
> sufficient configuration prodding) work fine with Fedora, i.e. there 
> isn't anything "magic" about Xandros (custom drivers, for example).

I have 2-finger scroll working (for a certain value of "working") on my
full-size Acer laptop running Fedora 9. Pinch is another story though,
mostly due to lack of standards in apps.

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

From kevin.kofler at chello.at  Sat Nov  1 01:29:30 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 1 Nov 2008 01:29:30 +0000 (UTC)
Subject: rawhide report: 20081031 changes
References: <20081031145123.2D23E1F824C@releng2.fedora.phx.redhat.com>
	<adf480660810310904p7042ec95y4ea1901a70fa5fc9@mail.gmail.com>
	<490B3B9B.5070805@redhat.com>
Message-ID: <loom.20081101T012617-767@post.gmane.org>

Lillian Angel <langel <at> redhat.com> writes:
> Correct. The -devel package now includes visualvm, which depends on 
> netbeans-platform8.

IMHO an optional tool which is not required to build Java programs has no
business being in java-1.6.0-openjdk-devel.

> We can talk about moving this out to a separate package,

I think that makes a lot of sense.

> and adding it as a "Suggests" for the java-1.6.0-openjdk-devel package.

Do we have all the infrastructure for soft dependencies in Fedora yet? I
don't think we do.

        Kevin Kof?er



From cmadams at hiwaay.net  Sat Nov  1 01:41:50 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 31 Oct 2008 20:41:50 -0500
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <1225495302.9931.21.camel@jcmlaptop.bos.redhat.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<200810291513.11983.sgrubb@redhat.com>
	<faa16b610810291225k4f77afc2o7d7dbb49f9948c63@mail.gmail.com>
	<200810291640.00051.sgrubb@redhat.com>
	<faa16b610810291352p5b5e9002n2af909ab1ffe1cd2@mail.gmail.com>
	<1225495302.9931.21.camel@jcmlaptop.bos.redhat.com>
Message-ID: <20081101014150.GA772665@hiwaay.net>

Once upon a time, Jon Masters <jonathan at jonmasters.org> said:
> Personally I think switching to fully POSIX file caps is a wonderful
> idea for sometime around 2010 or a bit later, but it's not practical for
> regular system utilities that might be sitting on older filesystems to
> do this today. Root NFS will break, many custom spins, just a lot of
> stuff is going to be very unhappy if we start doing this.

Would it be possible to implement capabilities in a backwards compatible
fashion?  For example, still have e.g. /bin/ping setuid-root, but also
have capabilities assigned, and have the capabilities override
setuid-root (if capabilities are assigned the setuid/setgid bits are
ignored).

If you are running from a filesystem where capabilities are not
supported (or are not passed from server to client as in the case of
NFS), you'd just get the "old-fashioned" setuid/setgid effect and things
would still work.  If you _do_ see the capabilities, you ignore the
setuid/setgid flags and only assign the requested capabilities and get
the benefits of fine-grained security.
-- 
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 vonbrand at inf.utfsm.cl  Sat Nov  1 00:35:31 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Fri, 31 Oct 2008 21:35:31 -0300
Subject: Reasons to preseve X on tty7
In-Reply-To: <490A24F9.1030005@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<4908BA9F.6000301@redhat.com> <4908C09B.6080609@gmail.com>
	<1225311126.23396.113.camel@nibbler.dlib.indiana.edu>
	<4908C757.1000902@gmail.com> <gealfk$4td$1@ger.gmane.org>
	<490943C0.4070703@gmail.com> <gecjut$mlc$1@ger.gmane.org>
	<4909D963.8010301@gmail.com> <geclvo$v87$1@ger.gmane.org>
	<490A24F9.1030005@gmail.com>
Message-ID: <200811010035.mA10ZVqI023537@laptop14.inf.utfsm.cl>

Les Mikesell <lesmikesell at gmail.com> wrote:
> Matthew Woehlke wrote:
> >
> >>> I've had with Fedora 8/9 is the cr*p nvidia drivers don't work
> >>> quite right on my setup, and that's hardly Fedora's fault.
> >>
> >> It is fedora's fault that their policy makes it difficult for you
> >> to run vendor drivers.
> > I'm sure this wasn't your intent anyway, but please don't put words
> > in my mouth :-). I happen to *agree* with the policy. The problem,
> > rather -
> > at least as I see it - is simply that nvidia's drivers suck :-).
> 
> Nobody can write code that always survives changes in non-standard
> interfaces.  Nvidia's drivers for OS's that provide stable interfaces
> work fine.
> 
> > Which is hardly Fedora's fault;
> 
> Well, it is a generic Linux problem, but fedora could make it easier
> for the users by not pushing out interface changes without
> coordinating with driver providers.

Oh, but Fedora does. For the drivers it supports, that is. If you download
random junk from the 'net, it's no wonder if it doesn't work right.
Complain to whoever supplies that (nVidia, in this case).

> > if nvidia would get with the program and make Free and Open drivers,
> > then maybe they could be fixed.

> Probably not - they would just be in the same shape as firewire and
> scsi drivers that go months/years with bugs that don't get fixed.

Which drivers? Have you reported said bugs to Fedora or the kernel folks?

[...]

> > Given what it is, I'm sure some people have trouble with Fedora, and
> > you have my sympathy if you're one of them. I'm not convinced,
> > however, that such problems are the norm and not the exception.

> And I'm not convinced that anyone even tries anything that matters
> with fedora - or runs it across a large variety of hardware.

I'm running Fedora on a range of hardware, and it works fine.
-- 
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 orion at cora.nwra.com  Sat Nov  1 03:49:28 2008
From: orion at cora.nwra.com (orion at cora.nwra.com)
Date: Fri, 31 Oct 2008 21:49:28 -0600 (MDT)
Subject: Fedora  8 most popular (then 7?)
In-Reply-To: <4909AE5F.6070606@fedoraproject.org>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<4908BA9F.6000301@redhat.com> <4908C09B.6080609@gmail.com>
	<4908C716.2090906@redhat.com>
	<alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>
	<4908F6A1.4020509@fedoraproject.org>
	<alpine.LRH.2.00.0810292308280.7694@arj.bjyevire.pbz>
	<4909AE5F.6070606@fedoraproject.org>
Message-ID: <2335.71.208.51.222.1225511368.squirrel@www.cora.nwra.com>


>
> Oh, we already did for Fedora.
>
> http://fedoraproject.org/wiki/Infrastructure/Metrics
> http://smolts.org/
>
> Rahul

http://smolts.org/static/stats/stats.html -> OS

Hmm, Fedora 8 is the most common followed by F7.   (What's the expiration
time again for smolt reports?)

Is that telling us something?

Are there historical snapshots of the smolt database?  It would be
interested to see the relative installs of 6,7,8 just before 9 came out.

- Orion



From rakesh.pandit at gmail.com  Sat Nov  1 03:53:41 2008
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Sat, 1 Nov 2008 09:23:41 +0530
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <528188.21827.qm@web32801.mail.mud.yahoo.com>
References: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>
	<528188.21827.qm@web32801.mail.mud.yahoo.com>
Message-ID: <b401d2530810312053g5fb59a22pa7ec6ef5ff55a646@mail.gmail.com>

2008/11/1 Orcan Ogetbil <orcanbahri at yahoo.com>:
> What is the status of this project? Did anyone started out writing some code? I want to contribute to this. Is there a webpage?
[..]
> As time goes more features can be implemented and more items from 3 can be shifted into 1 or 2. We will need to build a powerful parser. I think some code can be borrowed from rpmlint.
>

You are welcome.

The aim is to get as much as automated checks in rpmlint. If there are
certain things which cannot go in rpmlint because they are fedora
specific should go here (review-o-matic).

We are still to start brainstorming. But hopefully soon we will,
backed up with patches ;-)

-- 
rakesh
For time being, in case you have queries or want to discuss drop a mail to me.



From sundaram at fedoraproject.org  Sat Nov  1 04:03:00 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 01 Nov 2008 09:33:00 +0530
Subject: Fedora 9 spins beta???
In-Reply-To: <gegacs$rir$1@ger.gmane.org>
References: <gec0ih$fl9$1@ger.gmane.org>	<loom.20081030T103319-30@post.gmane.org>	<gec437$r9p$1@ger.gmane.org>	<loom.20081030T111628-898@post.gmane.org>
	<gegacs$rir$1@ger.gmane.org>
Message-ID: <490BD4F4.3080101@fedoraproject.org>

Pavel Alexeev (aka Pahan-Hubbitus) wrote:
> Kevin Kofler ?????:
>> Pavel Alexeev (aka Pahan-Hubbitus <forum <at> ru.bir.ru> writes:
>>> Off course. I do not known what is Electronic Lab, but I come here 
>>> for XFCE spin, which is not in official spins.
>>>
>>> So if it is wrong maillist for that question may you point me right?
>>
>> Well, I think the custom spins are still considered "beta". But for a 
>> definite answer, you'll have to wait, it's the right mailing list, the 
>> people who know the answer just haven't seen your post yet.
> 
> Ok, tank you, Kevin. I wait other answers...
> 
> And one more question concerning this: Do you plan make XFCE spin 
> official in near future?

It is already official.

Rahul



From lesmikesell at gmail.com  Sat Nov  1 04:47:57 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 31 Oct 2008 23:47:57 -0500
Subject: Fedora  8 most popular (then 7?)
In-Reply-To: <2335.71.208.51.222.1225511368.squirrel@www.cora.nwra.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<4908BA9F.6000301@redhat.com>
	<4908C09B.6080609@gmail.com>	<4908C716.2090906@redhat.com>	<alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>	<4908F6A1.4020509@fedoraproject.org>	<alpine.LRH.2.00.0810292308280.7694@arj.bjyevire.pbz>	<4909AE5F.6070606@fedoraproject.org>
	<2335.71.208.51.222.1225511368.squirrel@www.cora.nwra.com>
Message-ID: <490BDF7D.1010201@gmail.com>

orion at cora.nwra.com wrote:
>> Oh, we already did for Fedora.
>>
>> http://fedoraproject.org/wiki/Infrastructure/Metrics
>> http://smolts.org/
>>
>> Rahul
> 
> http://smolts.org/static/stats/stats.html -> OS
> 
> Hmm, Fedora 8 is the most common followed by F7.   (What's the expiration
> time again for smolt reports?)
> 
> Is that telling us something?
> 
> Are there historical snapshots of the smolt database?  It would be
> interested to see the relative installs of 6,7,8 just before 9 came out.
> 

I'm surprised you have any stats for FC6.  Aside from not being 
installed by default and having no man page:
# smoltSendProfile
Traceback (most recent call last):
   File "/usr/bin/smoltSendProfile", line 35, in ?
     from scan import scan
ImportError: No module named scan

-- 
   Les Mikesell
    lesmikesell at gmail.com



From tim.lauridsen at googlemail.com  Sat Nov  1 05:21:31 2008
From: tim.lauridsen at googlemail.com (Tim Lauridsen)
Date: Sat, 01 Nov 2008 06:21:31 +0100
Subject: PackageKit 0.3.10 into F9
In-Reply-To: <1225476378.15633.21.camel@hughsie-laptop>
References: <1225476378.15633.21.camel@hughsie-laptop>
Message-ID: <490BE75B.8010705@googlemail.com>

Richard Hughes wrote:
> I'm asking for your opinions as to whether PackageKit 0.3.10 should be
> pushed into F9 as an update. 0.3.10 will be released on Monday, and is
> much more feature complete and stable than the 0.2.x series. There have
> been 10 releases on the 0.3.x codebase in the last three months. 0.3.x
> is API and ABI incompatible with 0.2.x and 0.1.x versions, and has been
> in rawhide for a few months now.
>
> Uploading 0.3.10 also allows us to build KPackageKit for F9, which is
> quite nice to use now. Something for all the KDE people.
> gnome-packagekit is also much more user friendly and all the
> transactions should be much faster.
>
> If there are any early adopters keen to try a package (please!), can you
> please download a automatically generated git-snapshots here
> http://www.packagekit.org/packages/ and:
>
> * yum remove PackageKit gnome-packagekit
> * rebuild PackageKit-x.srpm
> * install PackageKit-x-*.rpm
> * rebuild gnome-packagekit-x.srpm
> * install gnome-packagekit-x-*.rpm
> * reboot
>
> Please send error reports to me, or the PackageKit mailing list.
>
> If there are no user regressions, I'll build this in f9-updates-testing,
> and then push it out using bodhi.
>
> Thanks,
>
> Richard.
>
>
>   
Sound like a good idea to me,  +1 for get it into updates-testing

Tim



From tim.lauridsen at googlemail.com  Sat Nov  1 06:39:57 2008
From: tim.lauridsen at googlemail.com (Tim Lauridsen)
Date: Sat, 01 Nov 2008 07:39:57 +0100
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <528188.21827.qm@web32801.mail.mud.yahoo.com>
References: <528188.21827.qm@web32801.mail.mud.yahoo.com>
Message-ID: <490BF9BD.2060002@googlemail.com>

Orcan Ogetbil wrote:
> What is the status of this project? Did anyone started out writing some code? I want to contribute to this. Is there a webpage?
>
> My opinion on this idea is, we should first write a script that displays 3 different kind of outputs:
>
> 1- Pure automatic checks: sha1sums, %files etc. -> Display results
> 2- Semi-automatic checks: For instance, the script will check for static libraries in the build. -> Display results (If there are static libraries then it will warn the reviewer so he can check for the necessity of them.)
> 3- Purely manual checks: Not everything in the guidelines is easy to implement. Hence after the script is done, it will tell the reviewer what else needs to be checked manually.
>
> As time goes more features can be implemented and more items from 3 can be shifted into 1 or 2. We will need to build a powerful parser. I think some code can be borrowed from rpmlint.
>
>
> -oget
>
>
>       
>
>   
I the ideal tool for this purpose IHO, would be some kind of web 
application, to handle all the workflow around getting packages into Fedora.
* uploading specs and srpms
* do automatic tests based on packaging guidelines.
* a reviewer multiple choice popquiz to go through all the checks in 
review guidelines. showing the result of the automatic test for the each 
rules.

TurboGear would be a good choice for such an application.

A standalone checker would also be a good idea, for the packager to 
check that the spec etc, there has been made complies to the guidelines, 
before it is uploaded to web application.

It would also be a good idea to design some kind framework to implement 
the different rules in a generic way, so it is easier for  the 
web/standalone application to interface  with the  tests, and it would  
be easier to add new ones and  the current one can  made better without 
breaking the interface with the
generic tools. Each test should be some kind of plugin into the main 
application.

Tim





From dkelson at gurulabs.com  Sat Nov  1 07:09:13 2008
From: dkelson at gurulabs.com (Dax Kelson)
Date: Sat, 01 Nov 2008 01:09:13 -0600
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <200810291502.11358.sgrubb@redhat.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<200810291502.11358.sgrubb@redhat.com>
Message-ID: <1225523353.3670.11.camel@mentor.gurulabs.com>

On Wed, 2008-10-29 at 15:02 -0400, Steve Grubb wrote:

> We tried to support this in F-10 by having a test run with ping. We figured 
> that is a simple well defined app that could be used as a test subject. We 
> opened bz 455713 to document the change over. Turns out that people compile 
> their own kernels and do not necessarily turn this on. So, what do we do in 
> that case?

I thought more about this.

How about a check in rc.sysinit to see if the kernel supports
capabilities? 

If the check fails it could do either or both of the following:

1. Display and log nasty warning message
2. Run the command: chmod u+s `cat /etc/posixcapbinaries`

Doing 2. would be the "friendly" thing to give the user a non-broken
system. It does make it a bit more complicated because you'd want some
logic that if they booted back to a kernel with posix capabilities you
stripped the suid bits. Also, rpm verity will complain.

Dax Kelson
Guru Labs





From dkelson at gurulabs.com  Sat Nov  1 07:14:05 2008
From: dkelson at gurulabs.com (Dax Kelson)
Date: Sat, 01 Nov 2008 01:14:05 -0600
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <1225523353.3670.11.camel@mentor.gurulabs.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<200810291502.11358.sgrubb@redhat.com>
	<1225523353.3670.11.camel@mentor.gurulabs.com>
Message-ID: <1225523645.3670.16.camel@mentor.gurulabs.com>

On Sat, 2008-11-01 at 01:09 -0600, Dax Kelson wrote:
> On Wed, 2008-10-29 at 15:02 -0400, Steve Grubb wrote:
> 
> > We tried to support this in F-10 by having a test run with ping. We figured 
> > that is a simple well defined app that could be used as a test subject. We 
> > opened bz 455713 to document the change over. Turns out that people compile 
> > their own kernels and do not necessarily turn this on. So, what do we do in 
> > that case?
> 
> I thought more about this.
> 
> How about a check in rc.sysinit to see if the kernel supports
> capabilities? 
> 
> If the check fails it could do either or both of the following:
> 
> 1. Display and log nasty warning message
> 2. Run the command: chmod u+s `cat /etc/posixcapbinaries`
> 
> Doing 2. would be the "friendly" thing to give the user a non-broken
> system. It does make it a bit more complicated because you'd want some
> logic that if they booted back to a kernel with posix capabilities you
> stripped the suid bits. Also, rpm verity will complain.

Another idea.

Leave all the binaries with SUID bit set, but have the /etc/fstab have
'nosuid' on all the filesystems.

Again, have logic in rc.sysinit that detects posix capabilities status
of the kernel and if it is missing, remounts the filesystems with suid
support.

For all mounted filesystems
do
mount -o remount,suid $filesystem
done

With this idea you don't have to maintain state, and rpm verify will
always be happy.

Dax Kelson
Guru Labs



From kushaldas at gmail.com  Sat Nov  1 07:27:12 2008
From: kushaldas at gmail.com (Kushal Das)
Date: Sat, 1 Nov 2008 12:57:12 +0530
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <490BF9BD.2060002@googlemail.com>
References: <528188.21827.qm@web32801.mail.mud.yahoo.com>
	<490BF9BD.2060002@googlemail.com>
Message-ID: <b399909d0811010027x26503932w52911572690ce621@mail.gmail.com>

On Sat, Nov 1, 2008 at 12:09 PM, Tim Lauridsen
<tim.lauridsen at googlemail.com> wrote:
> Orcan Ogetbil wrote:
> I the ideal tool for this purpose IHO, would be some kind of web
> application, to handle all the workflow around getting packages into Fedora.
> * uploading specs and srpms
> * do automatic tests based on packaging guidelines.
> * a reviewer multiple choice popquiz to go through all the checks in review
> guidelines. showing the result of the automatic test for the each rules.
This is going to be a web application only. Current code is for PoC.

Kushal
-- 
http://fedoraproject.org
http://kushaldas.in



From dwmw2 at infradead.org  Sat Nov  1 07:38:02 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 01 Nov 2008 07:38:02 +0000
Subject: Dia has .la files
In-Reply-To: <490B95BC.9000404@poolshark.org>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>
	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>
	<870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>
	<faa16b610810311421m56051690ia378ebde7ab693f8@mail.gmail.com>
	<91705d080810311615u7a00ddai936c78e4d6de0119@mail.gmail.com>
	<faa16b610810311617v5ae4d6e4ife8e5368073ad563@mail.gmail.com>
	<490B95BC.9000404@poolshark.org>
Message-ID: <1225525082.16774.145.camel@macbook.infradead.org>

On Sat, 2008-11-01 at 00:33 +0100, Denis Leroy wrote:
> Colin Walters wrote:
> > On Fri, Oct 31, 2008 at 7:15 PM, Dan Nicholson <dbn.lists at gmail.com> wrote:
> >> On Fri, Oct 31, 2008 at 2:21 PM, Colin Walters <walters at verbum.org> wrote:
> >>> The ideal of course would be to convince libtool upstream that trying
> >>> to change the entire world to use libtool makes a lot less sense than
> >>> having those few modules that interact with shared libraries have
> >>> platform-specific code.
> >> The libtool developers understand that the .la files aren't needed in
> >> normal operation. The reason that they insist on keeping them is so
> >> that `make uninstall' works since the .la files are the only place
> >> that store information about the actual libraries (.so + links vs. .a,
> >> etc.).
> > 
> > Right - we have a "make uninstall", it's called "rpm -e".
> 
> Was a libtool fork ever attempted ?

Why fork it when you can just throw it away and forget it ever existed?

I just write proper Makefiles, and if I ever _want_ to spend a couple of
minutes watch some bizarre script trying to work out what type of
FORTRAN compiler I have on my system, I can write myself a little bash
script for that too.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From pmatilai at laiskiainen.org  Sat Nov  1 08:23:14 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Sat, 1 Nov 2008 10:23:14 +0200 (EET)
Subject: rawhide report: 20081031 changes
In-Reply-To: <loom.20081101T012617-767@post.gmane.org>
References: <20081031145123.2D23E1F824C@releng2.fedora.phx.redhat.com>
	<adf480660810310904p7042ec95y4ea1901a70fa5fc9@mail.gmail.com>
	<490B3B9B.5070805@redhat.com>
	<loom.20081101T012617-767@post.gmane.org>
Message-ID: <alpine.LFD.2.00.0811011020090.8025@turre.koti.laiskiainen.org>

On Sat, 1 Nov 2008, Kevin Kofler wrote:

> Lillian Angel <langel <at> redhat.com> writes:
>> Correct. The -devel package now includes visualvm, which depends on
>> netbeans-platform8.
>
> IMHO an optional tool which is not required to build Java programs has no
> business being in java-1.6.0-openjdk-devel.
>
>> We can talk about moving this out to a separate package,
>
> I think that makes a lot of sense.
>
>> and adding it as a "Suggests" for the java-1.6.0-openjdk-devel package.
>
> Do we have all the infrastructure for soft dependencies in Fedora yet? I
> don't think we do.

No we don't. Soft dependencies were supposed to go into rpm 4.6.0 but 
didn't make it afterall, as I wasn't happy with some details of the 
existing implementations and didn't get around to work them out in time.

 	- Panu -



From joshuacov at googlemail.com  Sat Nov  1 08:58:39 2008
From: joshuacov at googlemail.com (Joshua C.)
Date: Sat, 1 Nov 2008 09:58:39 +0100
Subject: Strange ext3 problem
In-Reply-To: <m31vxwqrh6.fsf@ursa.amorsen.dk>
References: <5f6f8c5f0810311525s4a1ddd31y49527359340190b6@mail.gmail.com>
	<m31vxwqrh6.fsf@ursa.amorsen.dk>
Message-ID: <5f6f8c5f0811010158n47085a3eu5a5b87c58e9377b5@mail.gmail.com>

2008/11/1 Benny Amorsen <benny+usenet at amorsen.dk>:
> "Joshua C." <joshuacov at googlemail.com> writes:
>
>> I tested the hdd with smartmontools (short and long tests) and got no
>> errors of any kind. then used fsck and e2fsck on the partition and
>> they corrected something. I thought the problem was gone but here it
>> happens again.
>
> Memory error. Or CPU. Try booting into memtest86; I believe the Fedora
> iso's offer that. memtest86 isn't perfect though, your PC could still
> have a problem even if memtest86 says OK (after a few days of testing).
>
>
> /Benny
 I tried memtest86+ 2.01 (for about 3 hours) and it didn't display any
errors. I use f9 x86 but I have 4GB of memory. fedora sees only 2,25gb
but I thought it should be about 3gb. where are the rest 0,75gb? Could
this be connected with this?

Actually winxp sp3 sees also 2,25 gb but I see 4096mb in the bios
settings. maybe bios/dsdt table problem or sothing else?



From rjones at redhat.com  Sat Nov  1 09:23:09 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 1 Nov 2008 09:23:09 +0000
Subject: rawhide report: 20081031 changes
In-Reply-To: <20081031145123.2D23E1F824C@releng2.fedora.phx.redhat.com>
References: <20081031145123.2D23E1F824C@releng2.fedora.phx.redhat.com>
Message-ID: <20081101092309.GA18754@amd.home.annexia.org>

Is there a freeze on now which is preventing new packages from
appearing in this list?

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  Sat Nov  1 09:25:39 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 1 Nov 2008 09:25:39 +0000
Subject: Dia has .la files
In-Reply-To: <faa16b610810311421m56051690ia378ebde7ab693f8@mail.gmail.com>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>
	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>
	<870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>
	<faa16b610810311421m56051690ia378ebde7ab693f8@mail.gmail.com>
Message-ID: <20081101092539.GB18754@amd.home.annexia.org>

On Fri, Oct 31, 2008 at 05:21:55PM -0400, Colin Walters wrote:
> Really we need a post-build (BRP) hook in RPM to nuke them instead of
> copy&paste of rm into spec files.

We need the *.la files for MinGW packages.

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 rjones at redhat.com  Sat Nov  1 09:27:20 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 1 Nov 2008 09:27:20 +0000
Subject: Dia has .la files
In-Reply-To: <1225525082.16774.145.camel@macbook.infradead.org>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>
	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>
	<870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>
	<faa16b610810311421m56051690ia378ebde7ab693f8@mail.gmail.com>
	<91705d080810311615u7a00ddai936c78e4d6de0119@mail.gmail.com>
	<faa16b610810311617v5ae4d6e4ife8e5368073ad563@mail.gmail.com>
	<490B95BC.9000404@poolshark.org>
	<1225525082.16774.145.camel@macbook.infradead.org>
Message-ID: <20081101092720.GC18754@amd.home.annexia.org>

On Sat, Nov 01, 2008 at 07:38:02AM +0000, David Woodhouse wrote:
> On Sat, 2008-11-01 at 00:33 +0100, Denis Leroy wrote:
> > Was a libtool fork ever attempted ?
> 
> Why fork it when you can just throw it away and forget it ever existed?

Try building shared libraries on Windows / AIX / HP-SUX / whatever
before you make such silly comments.

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 steven.moix at axianet.ch  Sat Nov  1 09:35:25 2008
From: steven.moix at axianet.ch (Steven Moix)
Date: Sat, 01 Nov 2008 10:35:25 +0100
Subject: Fedora  8 most popular (then 7?)
In-Reply-To: <2335.71.208.51.222.1225511368.squirrel@www.cora.nwra.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<4908BA9F.6000301@redhat.com> <4908C09B.6080609@gmail.com>
	<4908C716.2090906@redhat.com>
	<alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>
	<4908F6A1.4020509@fedoraproject.org>
	<alpine.LRH.2.00.0810292308280.7694@arj.bjyevire.pbz>
	<4909AE5F.6070606@fedoraproject.org>
	<2335.71.208.51.222.1225511368.squirrel@www.cora.nwra.com>
Message-ID: <1225532125.4119.5.camel@hp6710.axianet.ch>

On Fri, 2008-10-31 at 21:49 -0600, orion at cora.nwra.com wrote:
> >
> > Oh, we already did for Fedora.
> >
> > http://fedoraproject.org/wiki/Infrastructure/Metrics
> > http://smolts.org/
> >
> > Rahul
> 
> http://smolts.org/static/stats/stats.html -> OS
> 
> Hmm, Fedora 8 is the most common followed by F7.   (What's the expiration
> time again for smolt reports?)
> 
> Is that telling us something?
> 
> Are there historical snapshots of the smolt database?  It would be
> interested to see the relative installs of 6,7,8 just before 9 came out.
> 
> - Orion

I don't know exactly how these statistics are are generated, but keep in
mind that:

1) The Smolt service isn't launched by default (if I remember
correctly).
2) A lot of people don't send Smolt profiles during the installation
process. Maybe the don't because they don't have network access during
the installation (think wifi).
3) After an initial submission, their profile never gets updated.

This leads me to think that these statistics are probably biased?

Steven



From forum at ru.bir.ru  Sat Nov  1 09:59:19 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Sat, 01 Nov 2008 12:59:19 +0300
Subject: Fedora 9 spins beta???
In-Reply-To: <490BD4F4.3080101@fedoraproject.org>
References: <gec0ih$fl9$1@ger.gmane.org>	<loom.20081030T103319-30@post.gmane.org>	<gec437$r9p$1@ger.gmane.org>	<loom.20081030T111628-898@post.gmane.org>	<gegacs$rir$1@ger.gmane.org>
	<490BD4F4.3080101@fedoraproject.org>
Message-ID: <geh99n$nas$1@ger.gmane.org>

Rahul Sundaram ?????:
> Pavel Alexeev (aka Pahan-Hubbitus) wrote:
>> Kevin Kofler ?????:
>>> Pavel Alexeev (aka Pahan-Hubbitus <forum <at> ru.bir.ru> writes:
>>>> Off course. I do not known what is Electronic Lab, but I come here 
>>>> for XFCE spin, which is not in official spins.
>>>>
>>>> So if it is wrong maillist for that question may you point me right?
>>>
>>> Well, I think the custom spins are still considered "beta". But for a 
>>> definite answer, you'll have to wait, it's the right mailing list, 
>>> the people who know the answer just haven't seen your post yet.
>>
>> Ok, tank you, Kevin. I wait other answers...
>>
>> And one more question concerning this: Do you plan make XFCE spin 
>> official in near future?
> 
> It is already official.
Where???
I can't find any mention of XFCE on http://torrent.fedoraproject.org/

> 
> Rahul
> 



From camilo at mesias.co.uk  Sat Nov  1 10:02:11 2008
From: camilo at mesias.co.uk (Camilo Mesias)
Date: Sat, 1 Nov 2008 10:02:11 +0000
Subject: rawhide / 10 beta suspend resume problem (ATI Radeon M300)
Message-ID: <d551e0e20811010302m3fee97e6wf7811e6dfafad8cb@mail.gmail.com>

Hi,

I've seen on-list reports of changes in the kernel and ati driver
(mode switching etc) and assumed they were trying to address the
suspend issues. Is there a bug for this or some other forum of
discussion. I'm still seeing failure to resume with a characteristic
blinking blue and yellow barcode type pattern (and a solitary beep) on
resume. The system locks up completely afterwards.

It's been like this for the last few kernels but has definitely been
improving since I used pre-upgrade to switch from '9' to 10 beta.

Here's my hardware details:
http://www.smolts.org/client/show/pub_44edc881-6d87-4d54-b878-9dda238ef4d0

The display is a largeish 1920x1200 panel, the machine has 2Gb RAM if
that makes a difference.

Is there anything I can do to help diagnose or fix the problem?

Mode switching works fine BTW. Apart from this resume issue the F10
beta is looking very impressive indeed. Great progress.

Thanks in advance,

-Cam



From joshuacov at googlemail.com  Sat Nov  1 10:29:18 2008
From: joshuacov at googlemail.com (Joshua C.)
Date: Sat, 1 Nov 2008 11:29:18 +0100
Subject: Strange ext3 problem
In-Reply-To: <5f6f8c5f0811010158n47085a3eu5a5b87c58e9377b5@mail.gmail.com>
References: <5f6f8c5f0810311525s4a1ddd31y49527359340190b6@mail.gmail.com>
	<m31vxwqrh6.fsf@ursa.amorsen.dk>
	<5f6f8c5f0811010158n47085a3eu5a5b87c58e9377b5@mail.gmail.com>
Message-ID: <5f6f8c5f0811010329r509680c1n684ed46ddb2af190@mail.gmail.com>

2008/11/1 Joshua C. <joshuacov at googlemail.com>:
>  I tried memtest86+ 2.01 (for about 3 hours) and it didn't display any
> errors. I use f9 x86 but I have 4GB of memory. fedora sees only 2,25gb
> but I thought it should be about 3gb. where are the rest 0,75gb? Could
> this be connected with this?
>
> Actually winxp sp3 sees also 2,25 gb but I see 4096mb in the bios
> settings. maybe bios/dsdt table problem or sothing else?
>

I retested the modules with memtest86+ 2.01. memtest86 3.4a gave me an
error "unexpected interrupt". one of modules gave me about 2000 errors
(at a small range but consistent through the tests) and the other one
was ok. So it is a memory problem. they are on the way back to gskill.

by the way, why cann't fedora see the 3gb of memory and shows only about 2,25gb?



From rawhide at fedoraproject.org  Sat Nov  1 11:10:58 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sat,  1 Nov 2008 11:10:58 +0000 (UTC)
Subject: rawhide report: 20081101 changes
Message-ID: <20081101111059.075FD1F824D@releng2.fedora.phx.redhat.com>

Compose started at Sat Nov  1 06:01:16 UTC 2008

Updated Packages:

fedora-release-9.93-1
---------------------
* Fri Oct 31 18:00:00 2008 jkeating <jkeating at redhat.com> 9.93-1
- Update for Fedora 10 Preview
- Remove compose content, that's now in spin-kickstarts


Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 1









Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot





From Victor.Vasilyev at Sun.COM  Sat Nov  1 12:19:28 2008
From: Victor.Vasilyev at Sun.COM (Victor Vasilyev)
Date: Sat, 01 Nov 2008 15:19:28 +0300
Subject: rawhide report: 20081031 changes
In-Reply-To: <20081031192144.GA4966@redhat.com>
References: <20081031145123.2D23E1F824C@releng2.fedora.phx.redhat.com>
	<20081031173852.GA3664@redhat.com> <490B4422.1070205@redhat.com>
	<200810311745.33433.billcrawford1970@gmail.com>
	<20081031192144.GA4966@redhat.com>
Message-ID: <490C4950.7060803@sun.com>

I've noticed that the Fedora-10-Snap3-i386-DVD.iso [1] contains
the java-1.6.0-openjdk-devel  package, but it doesn't contain the 
netbeans packages.
Should the feature [2] be included in the torrent releases?

[1] http://torrent.fedoraproject.org/
[2] https://fedoraproject.org/wiki/Features/NetBeans

Victor



From benny+usenet at amorsen.dk  Sat Nov  1 12:21:57 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Sat, 01 Nov 2008 13:21:57 +0100
Subject: Strange ext3 problem
In-Reply-To: <5f6f8c5f0811010329r509680c1n684ed46ddb2af190@mail.gmail.com>
	(Joshua C.'s message of "Sat\, 1 Nov 2008 11\:29\:18 +0100")
References: <5f6f8c5f0810311525s4a1ddd31y49527359340190b6@mail.gmail.com>
	<m31vxwqrh6.fsf@ursa.amorsen.dk>
	<5f6f8c5f0811010158n47085a3eu5a5b87c58e9377b5@mail.gmail.com>
	<5f6f8c5f0811010329r509680c1n684ed46ddb2af190@mail.gmail.com>
Message-ID: <m34p2rk55m.fsf@ursa.amorsen.dk>

"Joshua C." <joshuacov at googlemail.com> writes:

> by the way, why cann't fedora see the 3gb of memory and shows only about 2,25gb?

You most likely downloaded the wrong iso. Your computer is x86_64, not i686.


/Benny

(Who believes that the 32-bit kernel should refuse to boot on 64-bit
machines. Welcome to the 90's.)



From opensource at till.name  Sat Nov  1 12:29:43 2008
From: opensource at till.name (Till Maas)
Date: Sat, 01 Nov 2008 13:29:43 +0100
Subject: Strange ext3 problem
In-Reply-To: <m34p2rk55m.fsf@ursa.amorsen.dk>
References: <5f6f8c5f0810311525s4a1ddd31y49527359340190b6@mail.gmail.com>
	<5f6f8c5f0811010329r509680c1n684ed46ddb2af190@mail.gmail.com>
	<m34p2rk55m.fsf@ursa.amorsen.dk>
Message-ID: <200811011329.54878.opensource@till.name>

On Sat November 1 2008, Benny Amorsen wrote:
> "Joshua C." <joshuacov at googlemail.com> writes:
> > by the way, why cann't fedora see the 3gb of memory and shows only about
> > 2,25gb?
>
> You most likely downloaded the wrong iso. Your computer is x86_64, not
> i686.

> (Who believes that the 32-bit kernel should refuse to boot on 64-bit
> machines. Welcome to the 90's.)

The last time I tested my setup, free showed more memory from my 4GB with 
32-bit PAE than with x86_64.
Currently it's 4022 MB with 32-bit PAE, and afiak some of the memory is used 
for my on board graphic device.

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/20081101/b18a3d65/attachment.sig>

From lists at sapience.com  Sat Nov  1 13:18:35 2008
From: lists at sapience.com (Mail Lists)
Date: Sat, 01 Nov 2008 09:18:35 -0400
Subject: Fedora  8 most popular (then 7?)
In-Reply-To: <1225532125.4119.5.camel@hp6710.axianet.ch>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<4908BA9F.6000301@redhat.com>
	<4908C09B.6080609@gmail.com>	<4908C716.2090906@redhat.com>	<alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>	<4908F6A1.4020509@fedoraproject.org>	<alpine.LRH.2.00.0810292308280.7694@arj.bjyevire.pbz>	<4909AE5F.6070606@fedoraproject.org>	<2335.71.208.51.222.1225511368.squirrel@www.cora.nwra.com>
	<1225532125.4119.5.camel@hp6710.axianet.ch>
Message-ID: <490C572B.6030406@sapience.com>

On 11/01/2008 05:35 AM, Steven Moix wrote:

> This leads me to think that these statistics are probably biased?
> 

  Could be - but that doesn't explain why its biased for F8 .. in fact
would you not expect more people to use smolt over time - as suspicion
fades about big brother etc ...

  I suspect some are lagged as always - hence the large F7 base - these
could be server type installs which usually come after the admin has
experience with the desktop and is comfortable with it.

  Then I imagine the KDE issue has prevented many from upgrading until
KDE 4.2 is out - too bad smolt cant easily answer the kde vs gnome usage
- its not just an install issue - need to scan for dates inside .kde and
.gnomeX perhaps - maybe ignore anything over X weeks old etc. Maybe
someone can figure out a way.

   It would also be interesting to know the laptop install base too -
which while large I doubt would be more than 1/2 the installs. Did F7
and F8 have a way during install to connect to encrypted wireless ? If
not that could not have been a biasing issue either - if it did then yes
it may indeed.




From sundaram at fedoraproject.org  Sat Nov  1 13:39:09 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 01 Nov 2008 19:09:09 +0530
Subject: Fedora  8 most popular (then 7?)
In-Reply-To: <1225532125.4119.5.camel@hp6710.axianet.ch>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<4908BA9F.6000301@redhat.com>
	<4908C09B.6080609@gmail.com>	<4908C716.2090906@redhat.com>	<alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>	<4908F6A1.4020509@fedoraproject.org>	<alpine.LRH.2.00.0810292308280.7694@arj.bjyevire.pbz>	<4909AE5F.6070606@fedoraproject.org>	<2335.71.208.51.222.1225511368.squirrel@www.cora.nwra.com>
	<1225532125.4119.5.camel@hp6710.axianet.ch>
Message-ID: <490C5BFD.8010600@fedoraproject.org>

Steven Moix wrote:

> 1) The Smolt service isn't launched by default (if I remember
> correctly).

It is. It doesn't send any information automatically however.

> 3) After an initial submission, their profile never gets updated.

It is. There is a cron job running.

Rahul



From sundaram at fedoraproject.org  Sat Nov  1 13:40:28 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 01 Nov 2008 19:10:28 +0530
Subject: Fedora 9 spins beta???
In-Reply-To: <geh99n$nas$1@ger.gmane.org>
References: <gec0ih$fl9$1@ger.gmane.org>	<loom.20081030T103319-30@post.gmane.org>	<gec437$r9p$1@ger.gmane.org>	<loom.20081030T111628-898@post.gmane.org>	<gegacs$rir$1@ger.gmane.org>	<490BD4F4.3080101@fedoraproject.org>
	<geh99n$nas$1@ger.gmane.org>
Message-ID: <490C5C4C.1050905@fedoraproject.org>

Pavel Alexeev (aka Pahan-Hubbitus) wrote:
> Rahul Sundaram ?????:
>> Pavel Alexeev (aka Pahan-Hubbitus) wrote:
>>> Kevin Kofler ?????:
>>>> Pavel Alexeev (aka Pahan-Hubbitus <forum <at> ru.bir.ru> writes:
>>>>> Off course. I do not known what is Electronic Lab, but I come here 
>>>>> for XFCE spin, which is not in official spins.
>>>>>
>>>>> So if it is wrong maillist for that question may you point me right?
>>>>
>>>> Well, I think the custom spins are still considered "beta". But for 
>>>> a definite answer, you'll have to wait, it's the right mailing list, 
>>>> the people who know the answer just haven't seen your post yet.
>>>
>>> Ok, tank you, Kevin. I wait other answers...
>>>
>>> And one more question concerning this: Do you plan make XFCE spin 
>>> official in near future?
>>
>> It is already official.
> Where???
> I can't find any mention of XFCE on http://torrent.fedoraproject.org/

Everything hosted in http://spins.fedoraproject.org is considered official.

Rahul



From joshuacov at googlemail.com  Sat Nov  1 13:46:16 2008
From: joshuacov at googlemail.com (Joshua C.)
Date: Sat, 1 Nov 2008 14:46:16 +0100
Subject: Strange ext3 problem
In-Reply-To: <m34p2rk55m.fsf@ursa.amorsen.dk>
References: <5f6f8c5f0810311525s4a1ddd31y49527359340190b6@mail.gmail.com>
	<m31vxwqrh6.fsf@ursa.amorsen.dk>
	<5f6f8c5f0811010158n47085a3eu5a5b87c58e9377b5@mail.gmail.com>
	<5f6f8c5f0811010329r509680c1n684ed46ddb2af190@mail.gmail.com>
	<m34p2rk55m.fsf@ursa.amorsen.dk>
Message-ID: <5f6f8c5f0811010646y7ec677avaca913e0e07d50bb@mail.gmail.com>

2008/11/1 Benny Amorsen <benny+usenet at amorsen.dk>:
> "Joshua C." <joshuacov at googlemail.com> writes:
>
>> by the way, why cann't fedora see the 3gb of memory and shows only about 2,25gb?
>
> You most likely downloaded the wrong iso. Your computer is x86_64, not i686.
>
>
> /Benny
>
> (Who believes that the 32-bit kernel should refuse to boot on 64-bit
> machines. Welcome to the 90's.)

No, I have i686 and I know that it cannot detect the whole 4GB of
memory. and i know that 128mb are used for the video anyway. so i got
about 3968mb free to the OS.

What I expect is that the i686 detects about 3GB of free memory (not
the whole 4GB). according to different forums linux (and windows x86)
x86 should be able to detect up to 3,2GB of free memory (the limit of
32bits). but my fedora 9 i686 sees only 2,25gb (which is away from the
3GB). Windowsxp sees exactly the same amount of memory.
So either i got a crapy mashine or the forums are wrong.



From sgrubb at redhat.com  Sat Nov  1 14:12:45 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Sat, 1 Nov 2008 10:12:45 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <1225523645.3670.16.camel@mentor.gurulabs.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<1225523353.3670.11.camel@mentor.gurulabs.com>
	<1225523645.3670.16.camel@mentor.gurulabs.com>
Message-ID: <200811011012.46116.sgrubb@redhat.com>

On Saturday 01 November 2008 03:14:05 Dax Kelson wrote:
> On Sat, 2008-11-01 at 01:09 -0600, Dax Kelson wrote:
> > On Wed, 2008-10-29 at 15:02 -0400, Steve Grubb wrote:
> > > We tried to support this in F-10 by having a test run with ping. We
> > > figured that is a simple well defined app that could be used as a test
> > > subject. We opened bz 455713 to document the change over. Turns out
> > > that people compile their own kernels and do not necessarily turn this
> > > on. So, what do we do in that case?
> >
> > I thought more about this.
> >
> > How about a check in rc.sysinit to see if the kernel supports
> > capabilities?
> >
> > If the check fails it could do either or both of the following:
> >
> > 1. Display and log nasty warning message
> > 2. Run the command: chmod u+s `cat /etc/posixcapbinaries`

I don't like self modifying systems. It can generate audit events and cause 
aide to complain.


> > Doing 2. would be the "friendly" thing to give the user a non-broken
> > system. It does make it a bit more complicated because you'd want some
> > logic that if they booted back to a kernel with posix capabilities you
> > stripped the suid bits. Also, rpm verity will complain.
>
> Another idea.
>
> Leave all the binaries with SUID bit set, but have the /etc/fstab have
> 'nosuid' on all the filesystems.

The file system capabilities inside the kernel are treated as if they were 
suid apps. IOW, nosuid also disables file system capabilities.

-Steve



From sgrubb at redhat.com  Sat Nov  1 14:14:22 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Sat, 1 Nov 2008 10:14:22 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <20081101014150.GA772665@hiwaay.net>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<1225495302.9931.21.camel@jcmlaptop.bos.redhat.com>
	<20081101014150.GA772665@hiwaay.net>
Message-ID: <200811011014.23116.sgrubb@redhat.com>

On Friday 31 October 2008 21:41:50 Chris Adams wrote:
> Would it be possible to implement capabilities in a backwards compatible
> fashion? ?For example, still have e.g. /bin/ping setuid-root, but also
> have capabilities assigned, and have the capabilities override
> setuid-root (if capabilities are assigned the setuid/setgid bits are
> ignored).

This is an interesting idea. I haven't tested to see which one overrides, but 
I think this would be a good backwards compatible solution. Might take a 
kernel patch to fix, but worth looking into.

Thanks,
-Steve



From jkeating at redhat.com  Sat Nov  1 14:45:28 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 01 Nov 2008 07:45:28 -0700
Subject: rawhide report: 20081031 changes
In-Reply-To: <20081101092309.GA18754@amd.home.annexia.org>
References: <20081031145123.2D23E1F824C@releng2.fedora.phx.redhat.com>
	<20081101092309.GA18754@amd.home.annexia.org>
Message-ID: <1225550728.31015.37.camel@luminos.localdomain>

On Sat, 2008-11-01 at 09:23 +0000, Richard W.M. Jones wrote:
> Is there a freeze on now which is preventing new packages from
> appearing in this list?

Yes, we've been in an announced freeze, the final freeze, since 0555 UTC
October 28th.

https://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy

-- 
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/20081101/fd657a7c/attachment.sig>

From forum at ru.bir.ru  Sat Nov  1 14:47:00 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Sat, 01 Nov 2008 17:47:00 +0300
Subject: Fedora 9 spins beta???
In-Reply-To: <490C5C4C.1050905@fedoraproject.org>
References: <gec0ih$fl9$1@ger.gmane.org>	<loom.20081030T103319-30@post.gmane.org>	<gec437$r9p$1@ger.gmane.org>	<loom.20081030T111628-898@post.gmane.org>	<gegacs$rir$1@ger.gmane.org>	<490BD4F4.3080101@fedoraproject.org>	<geh99n$nas$1@ger.gmane.org>
	<490C5C4C.1050905@fedoraproject.org>
Message-ID: <gehq54$6n7$1@ger.gmane.org>

Rahul Sundaram ?????:
> Pavel Alexeev (aka Pahan-Hubbitus) wrote:
>> Rahul Sundaram ?????:
>>> Pavel Alexeev (aka Pahan-Hubbitus) wrote:
>>>> Kevin Kofler ?????:
>>>>> Pavel Alexeev (aka Pahan-Hubbitus <forum <at> ru.bir.ru> writes:
>>>>>> Off course. I do not known what is Electronic Lab, but I come here 
>>>>>> for XFCE spin, which is not in official spins.
>>>>>>
>>>>>> So if it is wrong maillist for that question may you point me right?
>>>>>
>>>>> Well, I think the custom spins are still considered "beta". But for 
>>>>> a definite answer, you'll have to wait, it's the right mailing 
>>>>> list, the people who know the answer just haven't seen your post yet.
>>>>
>>>> Ok, tank you, Kevin. I wait other answers...
>>>>
>>>> And one more question concerning this: Do you plan make XFCE spin 
>>>> official in near future?
>>>
>>> It is already official.
>> Where???
>> I can't find any mention of XFCE on http://torrent.fedoraproject.org/
> 
> Everything hosted in http://spins.fedoraproject.org is considered official.
Hm... What about first answer from Kevin Kofler what there custom spins 
and all official spins on http://torrent.fedoraproject.org/ ??
I misunderstood anything?

And if its spin also official, why there only Fedora 9 beta spins so far???

> 
> Rahul
> 



From benny+usenet at amorsen.dk  Sat Nov  1 15:23:38 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Sat, 01 Nov 2008 16:23:38 +0100
Subject: Strange ext3 problem
In-Reply-To: <200811011329.54878.opensource@till.name> (Till Maas's message of
	"Sat\, 01 Nov 2008 13\:29\:43 +0100")
References: <5f6f8c5f0810311525s4a1ddd31y49527359340190b6@mail.gmail.com>
	<5f6f8c5f0811010329r509680c1n684ed46ddb2af190@mail.gmail.com>
	<m34p2rk55m.fsf@ursa.amorsen.dk>
	<200811011329.54878.opensource@till.name>
Message-ID: <m3zlkjii6d.fsf@ursa.amorsen.dk>

Till Maas <opensource at till.name> writes:

> The last time I tested my setup, free showed more memory from my 4GB with 
> 32-bit PAE than with x86_64.

About time we got that kind of issue debugged then.

> Currently it's 4022 MB with 32-bit PAE, and afiak some of the memory is used 
> for my on board graphic device.

So? You can get 32GB with 32-bit PAE. That doesn't mean it's a good
idea.


/Benny



From mattdm at mattdm.org  Sat Nov  1 15:26:17 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 1 Nov 2008 11:26:17 -0400
Subject: Fedora  8 most popular (then 7?)
In-Reply-To: <490C572B.6030406@sapience.com>
References: <4908BA9F.6000301@redhat.com> <4908C09B.6080609@gmail.com>
	<4908C716.2090906@redhat.com>
	<alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>
	<4908F6A1.4020509@fedoraproject.org>
	<alpine.LRH.2.00.0810292308280.7694@arj.bjyevire.pbz>
	<4909AE5F.6070606@fedoraproject.org>
	<2335.71.208.51.222.1225511368.squirrel@www.cora.nwra.com>
	<1225532125.4119.5.camel@hp6710.axianet.ch>
	<490C572B.6030406@sapience.com>
Message-ID: <20081101152617.GA5985@jadzia.bu.edu>

On Sat, Nov 01, 2008 at 09:18:35AM -0400, Mail Lists wrote:
>   Could be - but that doesn't explain why its biased for F8 .. in fact
> would you not expect more people to use smolt over time - as suspicion
> fades about big brother etc ...

When it was new and exciting, I went out of my way to turn it on. Now I
often forget.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From a.badger at gmail.com  Sat Nov  1 15:33:31 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sat, 01 Nov 2008 08:33:31 -0700
Subject: Dia has .la files
In-Reply-To: <20081101092539.GB18754@amd.home.annexia.org>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>	<870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>	<faa16b610810311421m56051690ia378ebde7ab693f8@mail.gmail.com>
	<20081101092539.GB18754@amd.home.annexia.org>
Message-ID: <490C76CB.2000606@gmail.com>

Richard W.M. Jones wrote:
> On Fri, Oct 31, 2008 at 05:21:55PM -0400, Colin Walters wrote:
>> Really we need a post-build (BRP) hook in RPM to nuke them instead of
>> copy&paste of rm into spec files.
> 
> We need the *.la files for MinGW packages.
> 
Is that a "We need the *.la files for MinGW packages" or "We need the
*.la files in MinGW packages"?

I think it's the latter but want to make sure.

Also, as Patrice erroneously points out, some packages will break
without the *.la files.  I have yet to see a package where that's
actually a "needs" case.  However, I have seen places where the upstream
code looks for the *.la file when libltdl (the libtool library) is
willing to look for either the *.so or the *.la.

-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/20081101/ed6f0282/attachment.sig>

From kevin.kofler at chello.at  Sat Nov  1 15:46:11 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 1 Nov 2008 15:46:11 +0000 (UTC)
Subject: Fedora 9 spins beta???
References: <gec0ih$fl9$1@ger.gmane.org>	<loom.20081030T103319-30@post.gmane.org>	<gec437$r9p$1@ger.gmane.org>	<loom.20081030T111628-898@post.gmane.org>	<gegacs$rir$1@ger.gmane.org>	<490BD4F4.3080101@fedoraproject.org>	<geh99n$nas$1@ger.gmane.org>
	<490C5C4C.1050905@fedoraproject.org> <gehq54$6n7$1@ger.gmane.org>
Message-ID: <loom.20081101T152552-734@post.gmane.org>

Pavel Alexeev (aka Pahan-Hubbitus <forum <at> ru.bir.ru> writes:
> Hm... What about first answer from Kevin Kofler what there custom spins 
> and all official spins on http://torrent.fedoraproject.org/ ??

There are different levels of officialness. ;-)

The spins at torrent.fedoraproject.org are the primary, permanent ones:
installer DVD, GNOME ("Desktop"), KDE.

The spins at spins.fedoraproject.org are spins which have to get approved
at each release, to make sure they're still actively maintained. They have
approval to use the Fedora trademark and to be endorsed as products of the
Fedora Project. They are, however, not mirrored over HTTP/FTP/RSYNC (at
least not by Fedora - spin maintainers may of course make mirroring
arrangements outside of Fedora's infrastructure), only distributed through
BitTorrent, and they may get dropped in future releases if the maintainers
don't update them. The XFCE spin is in that category.

So what you really want to ask is if there are plans to make the XFCE spin
a "permanent" spin. But that doesn't depend only on the spin maintainers.

        Kevin Kofler



From kevin.kofler at chello.at  Sat Nov  1 15:47:45 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 1 Nov 2008 15:47:45 +0000 (UTC)
Subject: Fedora 9 spins beta???
References: <gec0ih$fl9$1@ger.gmane.org>	<loom.20081030T103319-30@post.gmane.org>	<gec437$r9p$1@ger.gmane.org>	<loom.20081030T111628-898@post.gmane.org>
	<gegacs$rir$1@ger.gmane.org> <490BD4F4.3080101@fedoraproject.org>
Message-ID: <loom.20081101T154711-548@post.gmane.org>

Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
> It is already official.

Shouldn't the description on spins.fedoraproject.org be changed to remove the
"BETA" label?

        Kevin Kofler



From bruno at wolff.to  Sat Nov  1 15:55:39 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 1 Nov 2008 10:55:39 -0500
Subject: rawhide / 10 beta suspend resume problem (ATI Radeon M300)
In-Reply-To: <d551e0e20811010302m3fee97e6wf7811e6dfafad8cb@mail.gmail.com>
References: <d551e0e20811010302m3fee97e6wf7811e6dfafad8cb@mail.gmail.com>
Message-ID: <20081101155539.GA2583@wolff.to>

On Sat, Nov 01, 2008 at 10:02:11 +0000,
  Camilo Mesias <camilo at mesias.co.uk> wrote:
> Hi,
> 
> I've seen on-list reports of changes in the kernel and ati driver
> (mode switching etc) and assumed they were trying to address the
> suspend issues. Is there a bug for this or some other forum of
> discussion. I'm still seeing failure to resume with a characteristic
> blinking blue and yellow barcode type pattern (and a solitary beep) on
> resume. The system locks up completely afterwards.

Based on the comments I have seen for the updates, David has been mostly trying
to get the modesetting working without display glitches before the release so
the feature doesn't have to be disabled. That might have been fixed yesterday
though.

I don't do suspend / resume, so haven't been looking for those bugs. It
would probably be a good idea to see if there is such a bug and create one
if there isn't.



From dominik at greysector.net  Sat Nov  1 16:10:48 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Sat, 1 Nov 2008 17:10:48 +0100
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <b399909d0811010027x26503932w52911572690ce621@mail.gmail.com>
References: <528188.21827.qm@web32801.mail.mud.yahoo.com>
	<490BF9BD.2060002@googlemail.com>
	<b399909d0811010027x26503932w52911572690ce621@mail.gmail.com>
Message-ID: <20081101161047.GD31023@mokona.greysector.net>

On Saturday, 01 November 2008 at 08:27, Kushal Das wrote:
> On Sat, Nov 1, 2008 at 12:09 PM, Tim Lauridsen
> <tim.lauridsen at googlemail.com> wrote:
> > Orcan Ogetbil wrote:
> > I the ideal tool for this purpose IHO, would be some kind of web
> > application, to handle all the workflow around getting packages into Fedora.
> > * uploading specs and srpms
> > * do automatic tests based on packaging guidelines.
> > * a reviewer multiple choice popquiz to go through all the checks in review
> > guidelines. showing the result of the automatic test for the each rules.
> This is going to be a web application only. Current code is for PoC.

Bleh. What about offline checking? Or at least, will this web application
work with lynx/links?

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 oisin.feeley at gmail.com  Sat Nov  1 16:13:36 2008
From: oisin.feeley at gmail.com (Oisin Feeley)
Date: Sat, 1 Nov 2008 12:13:36 -0400
Subject: rawhide netbook resume with xorg intel driver?
In-Reply-To: <5256d0b0810301326p1ae11640g5b731c0dabae92bd@mail.gmail.com>
References: <5256d0b0810301251t56a4e35xeaefb3437e6fc16c@mail.gmail.com>
	<507738ef0810301300odeb166et6b7d8f1f7a8fb855@mail.gmail.com>
	<1225397990.25818.389.camel@aglarond.local>
	<5256d0b0810301326p1ae11640g5b731c0dabae92bd@mail.gmail.com>
Message-ID: <e5f157b0811010913p47a56074pd9d641e3d66eb627@mail.gmail.com>

2008/10/30 Peter Robinson <pbrobinson at gmail.com>


> No, I must say I haven't primarily because it was working quite nicely
> until very recently so was initially wondering whether it was something I
> had changed (not that I tend to change much on my eeePC). Is there a link
> somewhere for these quirks?
>

Richard Hughes has an extensive site here:

http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-index.html

Best wishes,
Oisin Feeley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081101/631e43ba/attachment.htm>

From mschwendt at gmail.com  Sat Nov  1 16:18:30 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sat, 1 Nov 2008 17:18:30 +0100
Subject: Dia has .la files
In-Reply-To: <490C76CB.2000606@gmail.com>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>
	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>
	<870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>
	<faa16b610810311421m56051690ia378ebde7ab693f8@mail.gmail.com>
	<20081101092539.GB18754@amd.home.annexia.org>
	<490C76CB.2000606@gmail.com>
Message-ID: <20081101171830.5956e144.mschwendt@gmail.com>

On Sat, 01 Nov 2008 08:33:31 -0700, Toshio Kuratomi wrote:

> Also, as Patrice erroneously points out, some packages will break
> without the *.la files.  I have yet to see a package where that's
> actually a "needs" case.  However, I have seen places where the upstream
> code looks for the *.la file when libltdl (the libtool library) is
> willing to look for either the *.so or the *.la.

There are old libltdl libs that don't work if the libtool archives
are missing. The packagers of such apps should know about that.

The other case where removing libtool archives causes breakage is
if there are inter-library dependencies in the .la files. Then you
need to remove all .la files.



From lesmikesell at gmail.com  Sat Nov  1 16:42:20 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 01 Nov 2008 11:42:20 -0500
Subject: Fedora  8 most popular (then 7?)
In-Reply-To: <490C5BFD.8010600@fedoraproject.org>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<4908BA9F.6000301@redhat.com>	<4908C09B.6080609@gmail.com>	<4908C716.2090906@redhat.com>	<alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>	<4908F6A1.4020509@fedoraproject.org>	<alpine.LRH.2.00.0810292308280.7694@arj.bjyevire.pbz>	<4909AE5F.6070606@fedoraproject.org>	<2335.71.208.51.222.1225511368.squirrel@www.cora.nwra.com>	<1225532125.4119.5.camel@hp6710.axianet.ch>
	<490C5BFD.8010600@fedoraproject.org>
Message-ID: <490C86EC.1010600@gmail.com>

Rahul Sundaram wrote:
> Steven Moix wrote:
> 
>> 1) The Smolt service isn't launched by default (if I remember
>> correctly).
> 
> It is. It doesn't send any information automatically however.
> 
>> 3) After an initial submission, their profile never gets updated.
> 
> It is. There is a cron job running.

Do you know why such a tiny percentage of video hardware is reported?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Sat Nov  1 16:57:40 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 01 Nov 2008 11:57:40 -0500
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <200810291708.27051.sgrubb@redhat.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>	<200810291521.32293.sgrubb@redhat.com>	<20081029205330.GG1371252@hiwaay.net>
	<200810291708.27051.sgrubb@redhat.com>
Message-ID: <490C8A84.4010801@gmail.com>

Steve Grubb wrote:
> On Wednesday 29 October 2008 16:53:30 Chris Adams wrote:
>>> Its not a ping issue, its an installation issue. :)   I can either chmod
>>> 4755 or capset cap_net_raw=ep  during the installation. Upstream is not
>>> involved in this.
>> How do these new bits get backed up?  I'm still working on getting
>> SELinux backed up correctly, and now this... <sigh> an admin's job is
>> never done.
> 
> Since they are stored as xattrs, tar and star should do it if you tell them to 
> get the extended attributes. Also, aide supports looking for changes in 
> xattrs if you need that, too.
> 

What about cp -a and rsync -a?  I expect either of these to give me a 
working system.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Sat Nov  1 17:14:03 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 01 Nov 2008 12:14:03 -0500
Subject: PolicyKit auditing - was Re: Fedora 11: moving to posix file
 capabilities?
In-Reply-To: <200810291704.43907.sgrubb@redhat.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>	<200810291640.00051.sgrubb@redhat.com>	<faa16b610810291352p5b5e9002n2af909ab1ffe1cd2@mail.gmail.com>
	<200810291704.43907.sgrubb@redhat.com>
Message-ID: <490C8E5B.4070006@gmail.com>

Steve Grubb wrote:
> 
>>> Where's the GUI or commandline tool that lets me configure it? I may need
>>> to have auditing of who changed what entry in that file. When I chmod
>>> 4755 a program, I know who changed it, what the old and new values are,
>>> when they did it, and what the outcome was.
>> There's no real story on that other than "uid 0" and $EDITOR yet.
>> This is basically the same as all the other OS config files.
> 
> No...we have a handful of apps that audit changes to trusted databases. 
> password and adduser are two examples.

Why doesn't someone throw the entire set of config files into a version 
control system?  With bonus points for permitting it to reside remotely 
and contain similar machines as branches.  Aside from wanting to know 
who changed what and when, the more important issue is usually what was 
there last week when it still worked, or how it is different from a 
similar machine.  And the machine in question may not be working when 
you need to know this.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From sundaram at fedoraproject.org  Sat Nov  1 17:20:56 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 01 Nov 2008 22:50:56 +0530
Subject: Fedora  8 most popular (then 7?)
In-Reply-To: <490C86EC.1010600@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<4908BA9F.6000301@redhat.com>	<4908C09B.6080609@gmail.com>	<4908C716.2090906@redhat.com>	<alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>	<4908F6A1.4020509@fedoraproject.org>	<alpine.LRH.2.00.0810292308280.7694@arj.bjyevire.pbz>	<4909AE5F.6070606@fedoraproject.org>	<2335.71.208.51.222.1225511368.squirrel@www.cora.nwra.com>	<1225532125.4119.5.camel@hp6710.axianet.ch>	<490C5BFD.8010600@fedoraproject.org>
	<490C86EC.1010600@gmail.com>
Message-ID: <490C8FF8.6060203@fedoraproject.org>

Les Mikesell wrote:
> Rahul Sundaram wrote:
>> Steven Moix wrote:
>>
>>> 1) The Smolt service isn't launched by default (if I remember
>>> correctly).
>>
>> It is. It doesn't send any information automatically however.
>>
>>> 3) After an initial submission, their profile never gets updated.
>>
>> It is. There is a cron job running.
> 
> Do you know why such a tiny percentage of video hardware is reported?

No idea.

Rahul



From sundaram at fedoraproject.org  Sat Nov  1 17:23:20 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 01 Nov 2008 22:53:20 +0530
Subject: Fedora 9 spins beta???
In-Reply-To: <loom.20081101T154711-548@post.gmane.org>
References: <gec0ih$fl9$1@ger.gmane.org>	<loom.20081030T103319-30@post.gmane.org>	<gec437$r9p$1@ger.gmane.org>	<loom.20081030T111628-898@post.gmane.org>	<gegacs$rir$1@ger.gmane.org>
	<490BD4F4.3080101@fedoraproject.org>
	<loom.20081101T154711-548@post.gmane.org>
Message-ID: <490C9088.3040103@fedoraproject.org>

Kevin Kofler wrote:
> Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
>> It is already official.
> 
> Shouldn't the description on spins.fedoraproject.org be changed to remove the
> "BETA" label?

That is something for rel-eng to consider. They are already informed 
that I haven't got any bug reports on the current beta and that I 
consider it ready as it is.

Rahul



From sundaram at fedoraproject.org  Sat Nov  1 17:25:12 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 01 Nov 2008 22:55:12 +0530
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <490C8A84.4010801@gmail.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>	<200810291521.32293.sgrubb@redhat.com>	<20081029205330.GG1371252@hiwaay.net>	<200810291708.27051.sgrubb@redhat.com>
	<490C8A84.4010801@gmail.com>
Message-ID: <490C90F8.5050007@fedoraproject.org>

Les Mikesell wrote:
> Steve Grubb wrote:
>> On Wednesday 29 October 2008 16:53:30 Chris Adams wrote:
>>>> Its not a ping issue, its an installation issue. :)   I can either 
>>>> chmod
>>>> 4755 or capset cap_net_raw=ep  during the installation. Upstream is not
>>>> involved in this.
>>> How do these new bits get backed up?  I'm still working on getting
>>> SELinux backed up correctly, and now this... <sigh> an admin's job is
>>> never done.
>>
>> Since they are stored as xattrs, tar and star should do it if you tell 
>> them to get the extended attributes. Also, aide supports looking for 
>> changes in xattrs if you need that, too.
>>
> 
> What about cp -a and rsync -a?  I expect either of these to give me a 
> working system.

Read the man page. You need to pass -X or -xattrs to preserve extended 
attributes.

Rahul



From dkelson at gurulabs.com  Sat Nov  1 17:30:20 2008
From: dkelson at gurulabs.com (Dax Kelson)
Date: Sat, 01 Nov 2008 11:30:20 -0600
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <200811011012.46116.sgrubb@redhat.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<1225523353.3670.11.camel@mentor.gurulabs.com>
	<1225523645.3670.16.camel@mentor.gurulabs.com>
	<200811011012.46116.sgrubb@redhat.com>
Message-ID: <152d2fecfb0f88e3a9c6a328a4036981@gurulabs.com>

On 8:12:45 am 11/01/08 Steve Grubb <sgrubb at redhat.com> wrote:
> On Saturday 01 November 2008 03:14:05 Dax Kelson wrote:
> >  On Sat, 2008-11-01 at 01:09 -0600, Dax Kelson wrote:
> > >  On Wed, 2008-10-29 at 15:02 -0400, Steve Grubb wrote:
> > > >  We tried to support this in F-10 by having a test run with
> > > >  ping. We figured that is a simple well defined app that could
> > > >  be used as a test subject. We opened bz 455713 to document the
> > > >  change over. Turns out that people compile their own kernels
> > > >  and do not necessarily turn this on. So, what do we do in that
> > > case?
> > >  I thought more about this.
> > >
> > >  How about a check in rc.sysinit to see if the kernel supports
> > >  capabilities?
> > >
> > >  If the check fails it could do either or both of the following:
> > >
> > >  1. Display and log nasty warning message
> > >  2. Run the command: chmod u+s `cat /etc/posixcapbinaries`
>
> I don't like self modifying systems. It can generate audit events and
> cause aide to complain.

Doing 1 above is fine of course. Should be the minimum.

Regarding 2, I recognize that it isn't ideal, but it is probably better
than the alternative (broken system).

> > >  Doing 2. would be the "friendly" thing to give the user a
> > >  non-broken system. It does make it a bit more complicated
> > >  because you'd want some logic that if they booted back to a
> > >  kernel with posix capabilities you stripped the suid bits. Also,
> > rpm verity will complain.
> >  Another idea.
> >
> >  Leave all the binaries with SUID bit set, but have the /etc/fstab
> >  have 'nosuid' on all the filesystems.
>
> The file system capabilities inside the kernel are treated as if they
> were suid apps. IOW, nosuid also disables file system capabilities.

That's too bad. Seems like that would be an elegant solution. No aid or rpm
verify complaints since the filesystem itself isn't modified and
compatibility with both types of kernels. Maybe worth separating suid and
file system capabilities within the kernel in regards to the "nosuid" mount
option.

Dax Kelson



From a.badger at gmail.com  Sat Nov  1 17:28:43 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sat, 01 Nov 2008 10:28:43 -0700
Subject: Dia has .la files
In-Reply-To: <20081101171830.5956e144.mschwendt@gmail.com>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>	<870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>	<faa16b610810311421m56051690ia378ebde7ab693f8@mail.gmail.com>	<20081101092539.GB18754@amd.home.annexia.org>	<490C76CB.2000606@gmail.com>
	<20081101171830.5956e144.mschwendt@gmail.com>
Message-ID: <490C91CB.4060606@gmail.com>

Michael Schwendt wrote:
> On Sat, 01 Nov 2008 08:33:31 -0700, Toshio Kuratomi wrote:
> 
>> Also, as Patrice erroneously points out, some packages will break
>> without the *.la files.  I have yet to see a package where that's
>> actually a "needs" case.  However, I have seen places where the upstream
>> code looks for the *.la file when libltdl (the libtool library) is
>> willing to look for either the *.so or the *.la.
> 
> There are old libltdl libs that don't work if the libtool archives
> are missing. The packagers of such apps should know about that.
> 
It's been a while since I looked at this but isn't libltdl a shared
library?  So in Fedora we should be running against the newer version of
libltdl that does work with missing libtool archives?

> The other case where removing libtool archives causes breakage is
> if there are inter-library dependencies in the .la files. Then you
> need to remove all .la files.
> 
True.  That doesn't conflict with removing .la files everywhere, 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/20081101/85020450/attachment.sig>

From cmadams at hiwaay.net  Sat Nov  1 17:34:50 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Sat, 1 Nov 2008 12:34:50 -0500
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <490C8A84.4010801@gmail.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<200810291521.32293.sgrubb@redhat.com>
	<20081029205330.GG1371252@hiwaay.net>
	<200810291708.27051.sgrubb@redhat.com> <490C8A84.4010801@gmail.com>
Message-ID: <20081101173450.GC921665@hiwaay.net>

Once upon a time, Les Mikesell <lesmikesell at gmail.com> said:
> What about cp -a and rsync -a?  I expect either of these to give me a 
> working system.

cp -a copies SELinux context and ACLs currently.  It does not appear to
copy arbitrary extended attributes though, so I doubt it will pick up
capabilities.

rsync -a doesn't copy SELinux context or ACLs, so you've already lost
there.  Adding -A copies ACLs and -X copies extended attributes (but not
security or system attributes, so still no SELinux and probably no
capabilities).

Of course, tar requires --xattrs to pick up extended attributes, so
requiring an extra option already appears to be "standard" (although I
don't see an option for cp to pick up arbitrary extended attributes).

If my suggestion of having capabilities supersede and disable setuid and
setgid bits (so the bits are still set as well) is workable and
implemented (I have no idea of the code for that, so it may not be
something the kernel guys want), you wouldn't break anything if you
copied and didn't get the extended attributes.  You'd lose the added
security of capabilities, but setuid/setgid would still take effect and
programs would still work.

-- 
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 a.badger at gmail.com  Sat Nov  1 17:33:47 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sat, 01 Nov 2008 10:33:47 -0700
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <528188.21827.qm@web32801.mail.mud.yahoo.com>
References: <528188.21827.qm@web32801.mail.mud.yahoo.com>
Message-ID: <490C92FB.4050103@gmail.com>

Orcan Ogetbil wrote:
> What is the status of this project? Did anyone started out writing some code? I want to contribute to this. Is there a webpage?
> 
> My opinion on this idea is, we should first write a script that displays 3 different kind of outputs:
> 
> 1- Pure automatic checks: sha1sums, %files etc. -> Display results

I agree with the three broad categories that you have but please
remember that sha1sums are only a semi-automatic check.  sha1sums of the
included tarball can be run against the source URLs listed in the spec
file but those Source URLs must be checked by a human.  A computer will
gloss over::
  Source0: http://crackz.com/foo.tar.gz

but a human can check via google, mailing lists, and other distros to
see that the Source url is canonical.

> 2- Semi-automatic checks: For instance, the script will check for static libraries in the build. -> Display results (If there are static libraries then it will warn the reviewer so he can check for the necessity of them.)
> 3- Purely manual checks: Not everything in the guidelines is easy to implement. Hence after the script is done, it will tell the reviewer what else needs to be checked manually.
> 
> As time goes more features can be implemented and more items from 3 can be shifted into 1 or 2. We will need to build a powerful parser. I think some code can be borrowed from rpmlint.
> 

-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/20081101/2efad523/attachment.sig>

From a.badger at gmail.com  Sat Nov  1 17:37:45 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sat, 01 Nov 2008 10:37:45 -0700
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <20081101161047.GD31023@mokona.greysector.net>
References: <528188.21827.qm@web32801.mail.mud.yahoo.com>	<490BF9BD.2060002@googlemail.com>	<b399909d0811010027x26503932w52911572690ce621@mail.gmail.com>
	<20081101161047.GD31023@mokona.greysector.net>
Message-ID: <490C93E9.7030301@gmail.com>

Dominik 'Rathann' Mierzejewski wrote:
> On Saturday, 01 November 2008 at 08:27, Kushal Das wrote:
>> On Sat, Nov 1, 2008 at 12:09 PM, Tim Lauridsen
>> <tim.lauridsen at googlemail.com> wrote:
>>> Orcan Ogetbil wrote:
>>> I the ideal tool for this purpose IHO, would be some kind of web
>>> application, to handle all the workflow around getting packages into Fedora.
>>> * uploading specs and srpms
>>> * do automatic tests based on packaging guidelines.
>>> * a reviewer multiple choice popquiz to go through all the checks in review
>>> guidelines. showing the result of the automatic test for the each rules.
>> This is going to be a web application only. Current code is for PoC.
> 
> Bleh. What about offline checking? Or at least, will this web application
> work with lynx/links?
> 
Also, do we trust mock with unaudited spec files?  I know that we do
trust it with unaudited tarballs but I don't know if this is a reason to
open things up further.

-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/20081101/8d83d960/attachment.sig>

From lesmikesell at gmail.com  Sat Nov  1 17:44:23 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 01 Nov 2008 12:44:23 -0500
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <490C90F8.5050007@fedoraproject.org>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>	<200810291521.32293.sgrubb@redhat.com>	<20081029205330.GG1371252@hiwaay.net>	<200810291708.27051.sgrubb@redhat.com>	<490C8A84.4010801@gmail.com>
	<490C90F8.5050007@fedoraproject.org>
Message-ID: <490C9577.4080904@gmail.com>

Rahul Sundaram wrote:
> Les Mikesell wrote:
>> Steve Grubb wrote:
>>> On Wednesday 29 October 2008 16:53:30 Chris Adams wrote:
>>>>> Its not a ping issue, its an installation issue. :)   I can either 
>>>>> chmod
>>>>> 4755 or capset cap_net_raw=ep  during the installation. Upstream is 
>>>>> not
>>>>> involved in this.
>>>> How do these new bits get backed up?  I'm still working on getting
>>>> SELinux backed up correctly, and now this... <sigh> an admin's job is
>>>> never done.
>>>
>>> Since they are stored as xattrs, tar and star should do it if you 
>>> tell them to get the extended attributes. Also, aide supports looking 
>>> for changes in xattrs if you need that, too.
>>>
>>
>> What about cp -a and rsync -a?  I expect either of these to give me a 
>> working system.
> 
> Read the man page. You need to pass -X or -xattrs to preserve extended 
> attributes.

Yes, but it is more complicated in the rsync case in the face of 
changing APIs and attributes.  The remote side is unlikely to match 
exactly or I wouldn't be doing this copy, and it might even involve 
temporary snapshots parked on a 3rd (also different) system as a backup 
or master copy. Does -xattr always mean exactly the same set of extended 
attributes on every system, or will I need a matrix of what version of 
what OS running what version of what filesystem to be sure I have 
matching semantics?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From ivazqueznet at gmail.com  Sat Nov  1 18:07:26 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Sat, 01 Nov 2008 14:07:26 -0400
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <490C93E9.7030301@gmail.com>
References: <528188.21827.qm@web32801.mail.mud.yahoo.com>
	<490BF9BD.2060002@googlemail.com>
	<b399909d0811010027x26503932w52911572690ce621@mail.gmail.com>
	<20081101161047.GD31023@mokona.greysector.net>
	<490C93E9.7030301@gmail.com>
Message-ID: <1225562847.25414.449.camel@ignacio.lan>

On Sat, 2008-11-01 at 10:37 -0700, Toshio Kuratomi wrote:
> Also, do we trust mock with unaudited spec files?  I know that we do
> trust it with unaudited tarballs but I don't know if this is a reason to
> open things up further.

Doesn't the chroot mitigate most of the issues there might be in the
source package? A VM can probably mitigate the rest.

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

From mschwendt at gmail.com  Sat Nov  1 18:08:47 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sat, 1 Nov 2008 19:08:47 +0100
Subject: Dia has .la files
In-Reply-To: <490C91CB.4060606@gmail.com>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>
	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>
	<870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>
	<faa16b610810311421m56051690ia378ebde7ab693f8@mail.gmail.com>
	<20081101092539.GB18754@amd.home.annexia.org>
	<490C76CB.2000606@gmail.com>
	<20081101171830.5956e144.mschwendt@gmail.com>
	<490C91CB.4060606@gmail.com>
Message-ID: <20081101190847.63863fb4.mschwendt@gmail.com>

On Sat, 01 Nov 2008 10:28:43 -0700, Toshio Kuratomi wrote:

> It's been a while since I looked at this but isn't libltdl a shared
> library?  So in Fedora we should be running against the newer version of
> libltdl that does work with missing libtool archives?

Unless an old or customised copy of libltdl is used -- which has been the
case several times before. One of the more prominent examples was KDE,
albeit a few years ago. Wow, lots of hits at Google when searching for
such issues related to Fedora.
 
> > The other case where removing libtool archives causes breakage is
> > if there are inter-library dependencies in the .la files. Then you
> > need to remove all .la files.
> > 
> True.  That doesn't conflict with removing .la files everywhere, though.

Except that there has been resistance from some packagers, as they
refuse[d] to remove libtool archives. Perhaps this has changed
meanwhile. ;)



From a.badger at gmail.com  Sat Nov  1 18:17:56 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sat, 01 Nov 2008 11:17:56 -0700
Subject: Dia has .la files
In-Reply-To: <20081101190847.63863fb4.mschwendt@gmail.com>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>	<870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>	<faa16b610810311421m56051690ia378ebde7ab693f8@mail.gmail.com>	<20081101092539.GB18754@amd.home.annexia.org>	<490C76CB.2000606@gmail.com>	<20081101171830.5956e144.mschwendt@gmail.com>	<490C91CB.4060606@gmail.com>
	<20081101190847.63863fb4.mschwendt@gmail.com>
Message-ID: <490C9D54.7010503@gmail.com>

Michael Schwendt wrote:
> On Sat, 01 Nov 2008 10:28:43 -0700, Toshio Kuratomi wrote:
> 
>> It's been a while since I looked at this but isn't libltdl a shared
>> library?  So in Fedora we should be running against the newer version of
>> libltdl that does work with missing libtool archives?
> 
> Unless an old or customised copy of libltdl is used -- which has been the
> case several times before. One of the more prominent examples was KDE,
> albeit a few years ago. Wow, lots of hits at Google when searching for
> such issues related to Fedora.
>  
Yeah.  KDE3 I showed how to fix it but it was decided to move to KDE4
which doesn't use libltdl rather than fix it in KDE3.

As a general rule, using a private copy of a system library would be a
violation of the Packaging Guidelines for security reasons so it's
probably something we want to patch whenever we find it.

>>> The other case where removing libtool archives causes breakage is
>>> if there are inter-library dependencies in the .la files. Then you
>>> need to remove all .la files.
>>>
>> True.  That doesn't conflict with removing .la files everywhere, though.
> 
> Except that there has been resistance from some packagers, as they
> refuse[d] to remove libtool archives. Perhaps this has changed
> meanwhile. ;)
> 
heh :-)  That's a good point.  But if it's causing issues for dependent
packages that want to get rid of the .la then it makes even more sense
to tell them they must remove the .la's in their package.

-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/20081101/c2afc55f/attachment.sig>

From jspaleta at gmail.com  Sat Nov  1 18:36:11 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 1 Nov 2008 10:36:11 -0800
Subject: Fedora 8 most popular (then 7?)
In-Reply-To: <2335.71.208.51.222.1225511368.squirrel@www.cora.nwra.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<4908BA9F.6000301@redhat.com> <4908C09B.6080609@gmail.com>
	<4908C716.2090906@redhat.com>
	<alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>
	<4908F6A1.4020509@fedoraproject.org>
	<alpine.LRH.2.00.0810292308280.7694@arj.bjyevire.pbz>
	<4909AE5F.6070606@fedoraproject.org>
	<2335.71.208.51.222.1225511368.squirrel@www.cora.nwra.com>
Message-ID: <604aa7910811011136u5aeb2fd1w67e1e11310fa407a@mail.gmail.com>

On Fri, Oct 31, 2008 at 7:49 PM,  <orion at cora.nwra.com> wrote:
> Is that telling us something?


I think you have to look at the unique IP mirror manager stats as well
to get an idea of whether the smolt opt-in stats are valid as a metric
for overall adoption.  Do those stats support the same conclusion you
are trying to draw from the smolt data?  Can you reconcile what they
are saying?  I wish we had the maps up, they are snapshot of the
MirrorManager logs from the last week, so they give a different
picture versus the total unique ip count since release.

The sampling statistics for smolt's voluntary opt-in mechanism are not
necessarily statistically valid to extrapolate from a population
sampling theory point of view, since smolt users may be an
unrepresentative sample of the wider userbase.  Are certain types of
users more likely to use smolt than others? We've no statistically
valid survey of active workloads or usage scenarios.  Are people less
interested in optting into smolt now than they were a year ago? We've
no idea.  Is smolt usage itself trending downward with each release?

And likewise with the mirror manager unique ips.  That is clearly
going to be missing some people who reconfigure their systems to use a
static mirror.  Do we have any idea how many people do that? No. Do we
know if people are less interested now in using MirrorManager than a
year ago? No idea.  Is MirrorManager usage itself trending downward
with each release?

It's also interesting to look at this from the global map point of
view as a distribution of Fedora installs globally, instead of trying
to get a single number.  I think trending the global distribution of
clients matters more in terms of figuring out where to concentrate new
community building efforts.

Let me be very clear... no one in this project has stepped up and made
the case for an adoption increase goal for each release.  If you are
looking for a measurable uptick in adoption then you need to step up
and lead a user adoption effort.  Looking at the metrics for total
adoption goal numbers and parsing out small relative percentage
changes in adoption from release to release when we've no organized
effort to drive those numbers up is absolutely pointless.  Until the
goal of driving user counts up with each release becomes personally
important to someone, someone who will lead an effort, it will not be
important.

Let me be even clearer.  I personally do not care about seeing
adoption driven significantly higher for its own sake with each
release.  I believe in the concept of  the "right" users for
sustainable growth, I do not need to see user numbers driven upward
just for the sake of pointing to it patting ourselves on the back. I
only care about sustainable growth, where users become contributors
and help sustain new efforts.  Which is why I care about the map
densities as a tool to see where in the world new community effort can
be incubated.

-jef



From a.badger at gmail.com  Sat Nov  1 18:34:52 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sat, 01 Nov 2008 11:34:52 -0700
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <1225562847.25414.449.camel@ignacio.lan>
References: <528188.21827.qm@web32801.mail.mud.yahoo.com>	<490BF9BD.2060002@googlemail.com>	<b399909d0811010027x26503932w52911572690ce621@mail.gmail.com>	<20081101161047.GD31023@mokona.greysector.net>	<490C93E9.7030301@gmail.com>
	<1225562847.25414.449.camel@ignacio.lan>
Message-ID: <490CA14C.5040108@gmail.com>

Ignacio Vazquez-Abrams wrote:
> On Sat, 2008-11-01 at 10:37 -0700, Toshio Kuratomi wrote:
>> Also, do we trust mock with unaudited spec files?  I know that we do
>> trust it with unaudited tarballs but I don't know if this is a reason to
>> open things up further.
> 
> Doesn't the chroot mitigate most of the issues there might be in the
> source package?

It's supposed to but we have had issues in the past where the build
process modified the host environment.  I don't know if we traced that
down to something escaping the chroot or if it was something that mock
did before entering the chroot.  In either case, if we go for a web
app-only we need to decide whether we're comfortable building unaudited
spec files from someone who may not have a Fedora Account yet (Note: You
presently only need to have a bugzilla account when you submit your
first package.  This could be changed to cla_done for use of the
review-o-matic web app) via a web app hosted in Fedora Infrastructure.

If it was a script run on a reviewer's machine this would be something
each reviewer could decide for themselves, possibly after prereviewing a
certain portion of the package.

> A VM can probably mitigate the rest.
>
As in creating and tearing down a xen guest every time a build is
requested?  That might help.  review-o-matic would need the ability to
do that, though, and Infrastructure needs to decide that they want to
host a web app that has the ability to kick off creation and destruction
of VMs.

-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/20081101/b626dc0f/attachment.sig>

From pbrobinson at gmail.com  Sat Nov  1 18:37:57 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Sat, 1 Nov 2008 18:37:57 +0000
Subject: yum upgrade from F-9 to F-10
Message-ID: <5256d0b0811011137ye3910fco1a0726c96c3a4c65@mail.gmail.com>

Hi All,

I've done a  yum upgrade to F-10 rawhide using the method below. All seemed
to go OK but on reboot GDM doesn't work. The user list just lists "Other"
and the shutdown and reboot buttons are in operable. Any one seen this, any
idea?
https://fedoraproject.org/wiki/YumUpgradeFaq
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081101/b0944949/attachment.htm>

From kevin.kofler at chello.at  Sat Nov  1 19:06:53 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 01 Nov 2008 20:06:53 +0100
Subject: Fedora  8 most popular (then 7?)
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<4908BA9F.6000301@redhat.com> <4908C09B.6080609@gmail.com>
	<4908C716.2090906@redhat.com>
	<alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>
	<4908F6A1.4020509@fedoraproject.org>
	<alpine.LRH.2.00.0810292308280.7694@arj.bjyevire.pbz>
	<4909AE5F.6070606@fedoraproject.org>
	<2335.71.208.51.222.1225511368.squirrel@www.cora.nwra.com>
Message-ID: <gei9ce$jq6$1@ger.gmane.org>

orion at cora.nwra.com wrote:
> Hmm, Fedora 8 is the most common followed by F7.   (What's the expiration
> time again for smolt reports?)
> 
> Is that telling us something?

As an additional data point (though with a small sample), repo.calcforge.org
still got more requests for the F8 repo than the F9 one in October.

F8 i386: 5566
F9 i386: 3926

F8 i386 non-free: 4996
F9 i386 non-free: 3813

F8 x86_64: 1427
F9 x86_64: 1152

F8 x86_64 non-free: 1423
F9 x86_64 non-free: 1150

(The F7 repo is no longer up, but it had very few hits remaining when I took
it down.)

This is unlike past trends where new versions have been adopted more
quickly, so it looks like Fedora 9 in particular isn't very popular. I
think the major changes (KDE 4, X server 1.5.0, maybe also GCC 4.3 if there
are developers in the audience) are scaring people.

It has to be noted though that these are hits, not unique users, so those
stats probably correspond to very few people. My repository isn't immensely
popular. It might be interesting to see the stats for larger repositories,
such as Livna, or for Fedora updates on the mirrors.

        Kevin Kofler



From k.georgiou at imperial.ac.uk  Sat Nov  1 19:27:41 2008
From: k.georgiou at imperial.ac.uk (Kostas Georgiou)
Date: Sat, 1 Nov 2008 19:27:41 +0000
Subject: Fedora  8 most popular (then 7?)
In-Reply-To: <2335.71.208.51.222.1225511368.squirrel@www.cora.nwra.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<4908BA9F.6000301@redhat.com> <4908C09B.6080609@gmail.com>
	<4908C716.2090906@redhat.com>
	<alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>
	<4908F6A1.4020509@fedoraproject.org>
	<alpine.LRH.2.00.0810292308280.7694@arj.bjyevire.pbz>
	<4909AE5F.6070606@fedoraproject.org>
	<2335.71.208.51.222.1225511368.squirrel@www.cora.nwra.com>
Message-ID: <20081101192741.GA24873@imperial.ac.uk>

On Fri, Oct 31, 2008 at 09:49:28PM -0600, orion at cora.nwra.com wrote:

> 
> >
> > Oh, we already did for Fedora.
> >
> > http://fedoraproject.org/wiki/Infrastructure/Metrics
> > http://smolts.org/
> >
> > Rahul
> 
> http://smolts.org/static/stats/stats.html -> OS
> 
> Hmm, Fedora 8 is the most common followed by F7.   (What's the expiration
> time again for smolt reports?)
> 
> Is that telling us something?

It is also strange that the most popular kernels are the ones in the
release so either nobody updates their systems or something is wrong
with the smolt stats.

To me having it seems that having a cron job running once a month and
waiting between 0 and 3 days to sumbit the results makes it a bit
unlikely to get any stats from laptop or machines that aren't online
all the time. 

Kostas Georgiou



From sundaram at fedoraproject.org  Sat Nov  1 19:27:33 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 02 Nov 2008 00:57:33 +0530
Subject: Fedora  8 most popular (then 7?)
In-Reply-To: <gei9ce$jq6$1@ger.gmane.org>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<4908BA9F.6000301@redhat.com>
	<4908C09B.6080609@gmail.com>	<4908C716.2090906@redhat.com>	<alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>	<4908F6A1.4020509@fedoraproject.org>	<alpine.LRH.2.00.0810292308280.7694@arj.bjyevire.pbz>	<4909AE5F.6070606@fedoraproject.org>	<2335.71.208.51.222.1225511368.squirrel@www.cora.nwra.com>
	<gei9ce$jq6$1@ger.gmane.org>
Message-ID: <490CADA5.2040509@fedoraproject.org>

Kevin Kofler wrote:

> 
> It has to be noted though that these are hits, not unique users, so those
> stats probably correspond to very few people. My repository isn't immensely
> popular. It might be interesting to see the stats for larger repositories,
> such as Livna, or for Fedora updates on the mirrors.


http://fedoraproject.org/wiki/Statistics
http://fedoraproject.org/maps/

Rahul








From dbn.lists at gmail.com  Sat Nov  1 20:06:17 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Sat, 1 Nov 2008 13:06:17 -0700
Subject: Dia has .la files
In-Reply-To: <91705d080810311624tdfd2f91x2b0e8fc15edfd099@mail.gmail.com>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>
	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>
	<870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>
	<faa16b610810311421m56051690ia378ebde7ab693f8@mail.gmail.com>
	<91705d080810311615u7a00ddai936c78e4d6de0119@mail.gmail.com>
	<faa16b610810311617v5ae4d6e4ife8e5368073ad563@mail.gmail.com>
	<91705d080810311624tdfd2f91x2b0e8fc15edfd099@mail.gmail.com>
Message-ID: <91705d080811011306y69396819j8d9aff7bdc9c5087@mail.gmail.com>

On Fri, Oct 31, 2008 at 4:24 PM, Dan Nicholson <dbn.lists at gmail.com> wrote:
> On Fri, Oct 31, 2008 at 4:17 PM, Colin Walters <walters at verbum.org> wrote:
>> On Fri, Oct 31, 2008 at 7:15 PM, Dan Nicholson <dbn.lists at gmail.com> wrote:
>>> On Fri, Oct 31, 2008 at 2:21 PM, Colin Walters <walters at verbum.org> wrote:
>>>>
>>>> The ideal of course would be to convince libtool upstream that trying
>>>> to change the entire world to use libtool makes a lot less sense than
>>>> having those few modules that interact with shared libraries have
>>>> platform-specific code.
>>>
>>> The libtool developers understand that the .la files aren't needed in
>>> normal operation. The reason that they insist on keeping them is so
>>> that `make uninstall' works since the .la files are the only place
>>> that store information about the actual libraries (.so + links vs. .a,
>>> etc.).
>>
>> Right - we have a "make uninstall", it's called "rpm -e".
>
> OK, now convince the libtool developers to break everyone's `make
> distcheck'. Might be tough. But I certainly would support a way to opt
> out of that situation at build time. Something like:
>
> export LIBTOOLFLAGS="--no-installed-la-files"

Here's a patch against libtool-1.5.24 (should apply to F-9 or rawhide)
that adds a --no-la-files option. If the source tree libtool has been
generated using the patched libtool, then setting
LIBTOOLFLAGS="--no-la-files" will suppress installing the .la files.
However, older automake does not pass LIBTOOLFLAGS during the install
phase, so it may not work in all cases.

To test, you can just apply to your system ltmain.sh:

# sudo patch -b /usr/share/libtool/ltmain.sh \
    libtool-1.5.24-no-la-files.patch
# sudo patch -b /usr/share/libtool/libltdl/ltmain.sh \
    libtool-1.5.24-no-la-files.patch

Find a simple libtooled package to test (I've been using libpciaccess
since it's clean), run `autoreconf -iv', export
LIBTOOLFLAGS=--no-la-files and build away.

--
Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libtool-1.5.24-no-la-files.patch
Type: application/mbox
Size: 2791 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081101/66f73994/attachment.mbox>

From konrad at tylerc.org  Sat Nov  1 21:09:09 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Sat, 1 Nov 2008 14:09:09 -0700
Subject: Strange ext3 problem
In-Reply-To: <m3zlkjii6d.fsf@ursa.amorsen.dk>
References: <5f6f8c5f0810311525s4a1ddd31y49527359340190b6@mail.gmail.com>
	<200811011329.54878.opensource@till.name>
	<m3zlkjii6d.fsf@ursa.amorsen.dk>
Message-ID: <200811011409.09809.konrad@tylerc.org>

On Saturday 01 November 2008 08:23:38 am Benny Amorsen wrote:
> Till Maas <opensource at till.name> writes:
> > The last time I tested my setup, free showed more memory from my 4GB with
> > 32-bit PAE than with x86_64.
>
> About time we got that kind of issue debugged then.

I think the point he was getting at is that 64-bit uses more memory than 
32-bit.

-- 
Conrad Meyer <konrad at tylerc.org>




From camilo at mesias.co.uk  Sat Nov  1 22:15:47 2008
From: camilo at mesias.co.uk (Camilo Mesias)
Date: Sat, 1 Nov 2008 22:15:47 +0000
Subject: rawhide / 10 beta suspend resume problem (ATI Radeon M300)
In-Reply-To: <20081101155539.GA2583@wolff.to>
References: <d551e0e20811010302m3fee97e6wf7811e6dfafad8cb@mail.gmail.com>
	<20081101155539.GA2583@wolff.to>
Message-ID: <d551e0e20811011515x13fed63bs9b38627baa17b693@mail.gmail.com>

FYI: https://bugzilla.redhat.com/show_bug.cgi?id=469517



From rc040203 at freenet.de  Sat Nov  1 22:24:48 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sat, 01 Nov 2008 23:24:48 +0100
Subject: Dia has .la files
In-Reply-To: <20081101190847.63863fb4.mschwendt@gmail.com>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>
	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>
	<870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>
	<faa16b610810311421m56051690ia378ebde7ab693f8@mail.gmail.com>
	<20081101092539.GB18754@amd.home.annexia.org>
	<490C76CB.2000606@gmail.com>
	<20081101171830.5956e144.mschwendt@gmail.com>
	<490C91CB.4060606@gmail.com>
	<20081101190847.63863fb4.mschwendt@gmail.com>
Message-ID: <1225578288.3897.652.camel@beck.corsepiu.local>

On Sat, 2008-11-01 at 19:08 +0100, Michael Schwendt wrote:
> On Sat, 01 Nov 2008 10:28:43 -0700, Toshio Kuratomi wrote:

> Except that there has been resistance from some packagers, as they
> refuse[d] to remove libtool archives. Perhaps this has changed
> meanwhile. ;)
No, it hasn't changed. What has changed is the packagers. 

Newcomer maintainers tend to blindly follow the what others tell them,
no matter how wrong it is (Such as the lies on *.la's).




From kevin.kofler at chello.at  Sat Nov  1 22:47:29 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 01 Nov 2008 23:47:29 +0100
Subject: Fedora  8 most popular (then 7?)
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<4908BA9F.6000301@redhat.com>
	<4908C09B.6080609@gmail.com>	<4908C716.2090906@redhat.com>	<alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>	<4908F6A1.4020509@fedoraproject.org>	<alpine.LRH.2.00.0810292308280.7694@arj.bjyevire.pbz>	<4909AE5F.6070606@fedoraproject.org>	<2335.71.208.51.222.1225511368.squirrel@www.cora.nwra.com>
	<gei9ce$jq6$1@ger.gmane.org> <490CADA5.2040509@fedoraproject.org>
Message-ID: <geima1$lfi$1@ger.gmane.org>

Rahul Sundaram wrote:
> http://fedoraproject.org/wiki/Statistics

Those don't seem to have what I'm looking for (F8 vs. F9 repo stats for a
current interval, like last month or last week or last 24 hours), except
for the maps...

> http://fedoraproject.org/maps/

... but unfortunately all the actual maps there give me 404s, is something
wrong with the map generation process?

        Kevin Kofler



From kevin.kofler at chello.at  Sat Nov  1 22:49:04 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 01 Nov 2008 23:49:04 +0100
Subject: Fedora  8 most popular (then 7?)
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<4908BA9F.6000301@redhat.com> <4908C09B.6080609@gmail.com>
	<4908C716.2090906@redhat.com>
	<alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>
	<4908F6A1.4020509@fedoraproject.org>
	<alpine.LRH.2.00.0810292308280.7694@arj.bjyevire.pbz>
	<4909AE5F.6070606@fedoraproject.org>
	<2335.71.208.51.222.1225511368.squirrel@www.cora.nwra.com>
	<20081101192741.GA24873@imperial.ac.uk>
Message-ID: <geimd0$lfi$2@ger.gmane.org>

Kostas Georgiou wrote:
> It is also strange that the most popular kernels are the ones in the
> release so either nobody updates their systems or something is wrong
> with the smolt stats.

Most smolt stats are submitted at install time. It is possible to submit
smolt data later (either manually or via cron), which explains why not all
data is with the GA kernel, but most users will submit it only once and
then disable it, assuming they submit it at all.

        Kevin Kofler



From m.a.young at durham.ac.uk  Sat Nov  1 23:01:46 2008
From: m.a.young at durham.ac.uk (M A Young)
Date: Sat, 1 Nov 2008 23:01:46 +0000 (GMT)
Subject: yum upgrade from F-9 to F-10
In-Reply-To: <5256d0b0811011137ye3910fco1a0726c96c3a4c65@mail.gmail.com>
References: <5256d0b0811011137ye3910fco1a0726c96c3a4c65@mail.gmail.com>
Message-ID: <alpine.LFD.2.00.0811012257430.30198@vega2.dur.ac.uk>

On Sat, 1 Nov 2008, Peter Robinson wrote:

> I've done a? yum upgrade to F-10 rawhide using the method below. All seemed
> to go OK but on reboot GDM doesn't work. The user list just lists "Other"
> and the shutdown and reboot buttons are in operable. Any one seen this, any
> idea?
> https://fedoraproject.org/wiki/YumUpgradeFaq

Clicking other should get you a login prompt. If that doesn't work either, 
do you have an intel graphics card? X is broken for some intel graphics 
cards in rawhide.

 	Michael Young

From airlied at redhat.com  Sun Nov  2 00:06:37 2008
From: airlied at redhat.com (Dave Airlie)
Date: Sun, 02 Nov 2008 10:06:37 +1000
Subject: rawhide / 10 beta suspend resume problem (ATI Radeon M300)
In-Reply-To: <d551e0e20811010302m3fee97e6wf7811e6dfafad8cb@mail.gmail.com>
References: <d551e0e20811010302m3fee97e6wf7811e6dfafad8cb@mail.gmail.com>
Message-ID: <1225584397.14357.0.camel@optimus>

On Sat, 2008-11-01 at 10:02 +0000, Camilo Mesias wrote:
> Hi,
> 
> I've seen on-list reports of changes in the kernel and ati driver
> (mode switching etc) and assumed they were trying to address the
> suspend issues. Is there a bug for this or some other forum of
> discussion. I'm still seeing failure to resume with a characteristic
> blinking blue and yellow barcode type pattern (and a solitary beep) on
> resume. The system locks up completely afterwards.
> 
> It's been like this for the last few kernels but has definitely been
> improving since I used pre-upgrade to switch from '9' to 10 beta.
> 
> Here's my hardware details:
> http://www.smolts.org/client/show/pub_44edc881-6d87-4d54-b878-9dda238ef4d0
> 
> The display is a largeish 1920x1200 panel, the machine has 2Gb RAM if
> that makes a difference.
> 
> Is there anything I can do to help diagnose or fix the problem?
> 
> Mode switching works fine BTW. Apart from this resume issue the F10
> beta is looking very impressive indeed. Great progress.

Have you logged a bug?

I have suspend/resume running fine on my two radeon laptops, so I
suspect this is something specific to one or two models.

Can you try pm-suspend --quirk-none 

to see if maybe the BIOS is messing things up.

Dave.




From vonbrand at inf.utfsm.cl  Sun Nov  2 01:15:09 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sat, 01 Nov 2008 22:15:09 -0300
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <152d2fecfb0f88e3a9c6a328a4036981@gurulabs.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<1225523353.3670.11.camel@mentor.gurulabs.com>
	<1225523645.3670.16.camel@mentor.gurulabs.com>
	<200811011012.46116.sgrubb@redhat.com>
	<152d2fecfb0f88e3a9c6a328a4036981@gurulabs.com>
Message-ID: <200811020115.mA21F9uu025172@laptop14.inf.utfsm.cl>

Dax Kelson <dkelson at gurulabs.com> wrote:
> On 8:12:45 am 11/01/08 Steve Grubb <sgrubb at redhat.com> wrote:

[...]

> > The file system capabilities inside the kernel are treated as if they
> > were suid apps. IOW, nosuid also disables file system capabilities.

> That's too bad. Seems like that would be an elegant solution. No aid or rpm
> verify complaints since the filesystem itself isn't modified and
> compatibility with both types of kernels. Maybe worth separating suid and
> file system capabilities within the kernel in regards to the "nosuid" mount
> option.

It wouldn't be the first time Fedora (and before that, Red Hat Linux)
requires a kernel with specific configuration options. If you compile your
own kernel, you _are_ on your own...

As long as it isn't a Fedora-only patch to the kernel, it is OK with me
(yes, I used to run self-compiled kernels most of the time [Got caught by
other stuff lately]).
-- 
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  Sun Nov  2 01:45:57 2008
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Sun, 2 Nov 2008 07:15:57 +0530
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <490CA14C.5040108@gmail.com>
References: <528188.21827.qm@web32801.mail.mud.yahoo.com>
	<490BF9BD.2060002@googlemail.com>
	<b399909d0811010027x26503932w52911572690ce621@mail.gmail.com>
	<20081101161047.GD31023@mokona.greysector.net>
	<490C93E9.7030301@gmail.com> <1225562847.25414.449.camel@ignacio.lan>
	<490CA14C.5040108@gmail.com>
Message-ID: <b401d2530811011845w2cf1ba7do817f0ae3778ad14d@mail.gmail.com>

2008/11/2 Toshio Kuratomi <a.badger at gmail.com>:
`[..]
> If it was a script run on a reviewer's machine this would be something
> each reviewer could decide for themselves, possibly after prereviewing a
> certain portion of the package.
>
[..]

It would be there. When we get something working first, we can easily
make scripts for reviewer to run locally or even for reporter (for
some major part at least) e.g checking spec for guidelines.

-- 
Cheers,
rakesh



From jspaleta at gmail.com  Sun Nov  2 03:27:33 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 1 Nov 2008 19:27:33 -0800
Subject: Fedora 8 most popular (then 7?)
In-Reply-To: <geima1$lfi$1@ger.gmane.org>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<4908C716.2090906@redhat.com>
	<alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>
	<4908F6A1.4020509@fedoraproject.org>
	<alpine.LRH.2.00.0810292308280.7694@arj.bjyevire.pbz>
	<4909AE5F.6070606@fedoraproject.org>
	<2335.71.208.51.222.1225511368.squirrel@www.cora.nwra.com>
	<gei9ce$jq6$1@ger.gmane.org> <490CADA5.2040509@fedoraproject.org>
	<geima1$lfi$1@ger.gmane.org>
Message-ID: <604aa7910811012027u195fbbd2qba7bdd197bb1a825@mail.gmail.com>

On Sat, Nov 1, 2008 at 2:47 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> ... but unfortunately all the actual maps there give me 404s, is something
> wrong with the map generation process?

It's being worked on... some of the maps were up last week.  Its one
of the last casualties of the infrastructure rebuild.

-jef



From mjg at redhat.com  Sun Nov  2 09:15:04 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Sun, 2 Nov 2008 09:15:04 +0000
Subject: rawhide netbook resume with xorg intel driver?
In-Reply-To: <e5f157b0811010913p47a56074pd9d641e3d66eb627@mail.gmail.com>
References: <5256d0b0810301251t56a4e35xeaefb3437e6fc16c@mail.gmail.com>
	<507738ef0810301300odeb166et6b7d8f1f7a8fb855@mail.gmail.com>
	<1225397990.25818.389.camel@aglarond.local>
	<5256d0b0810301326p1ae11640g5b731c0dabae92bd@mail.gmail.com>
	<e5f157b0811010913p47a56074pd9d641e3d66eb627@mail.gmail.com>
Message-ID: <20081102091504.GB10983@srcf.ucam.org>

On Sat, Nov 01, 2008 at 12:13:36PM -0400, Oisin Feeley wrote:
> 2008/10/30 Peter Robinson <pbrobinson at gmail.com>
>     No, I must say I haven't primarily because it was working quite nicely
>     until very recently so was initially wondering whether it was something I
>     had changed (not that I tend to change much on my eeePC). Is there a link
>     somewhere for these quirks?
> 
> 
> Richard Hughes has an extensive site here:
> 
> http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-index.html

Please (please, please) don't attempt to add resume quirks for anything 
with Intel video hardware now. It's only hiding kernel bugs.

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



From rawhide at fedoraproject.org  Sun Nov  2 10:45:34 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sun,  2 Nov 2008 10:45:34 +0000 (UTC)
Subject: rawhide report: 20081102 changes
Message-ID: <20081102104535.31E501F8250@releng2.fedora.phx.redhat.com>

Compose started at Sun Nov  2 06:01:10 UTC 2008

Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 0









Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot





From kanarip at kanarip.com  Sun Nov  2 12:27:22 2008
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Sun, 02 Nov 2008 13:27:22 +0100
Subject: Package Review SIG Meeting Summary 2008-10-23
In-Reply-To: <1225135895.21297.7.camel@kennedy>
References: <1225135895.21297.7.camel@kennedy>
Message-ID: <490D9CAA.4000905@kanarip.com>

Brian Pepple wrote:
> == Summary ==
> === Brain-Storming ===
>              6. Hold an IRC workshop (or maybe a trac at FUDCon) on
>                 package reviewing.
> 

I should say on the past 4 or 5 FUDCon's I've been to, there usually 
*is* a how to become a packager barcamp session, followed by a hackfest, 
where one of the soon-to-be-packagers reviews someone else's package.

Kind regards,

Jeroen van Meeuwen
-kanarip



From rjones at redhat.com  Sun Nov  2 12:48:47 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sun, 2 Nov 2008 12:48:47 +0000
Subject: Dia has .la files
In-Reply-To: <490C76CB.2000606@gmail.com>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>
	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>
	<870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>
	<faa16b610810311421m56051690ia378ebde7ab693f8@mail.gmail.com>
	<20081101092539.GB18754@amd.home.annexia.org>
	<490C76CB.2000606@gmail.com>
Message-ID: <20081102124847.GA12371@amd.home.annexia.org>

On Sat, Nov 01, 2008 at 08:33:31AM -0700, Toshio Kuratomi wrote:
> Richard W.M. Jones wrote:
> > On Fri, Oct 31, 2008 at 05:21:55PM -0400, Colin Walters wrote:
> >> Really we need a post-build (BRP) hook in RPM to nuke them instead of
> >> copy&paste of rm into spec files.
> > 
> > We need the *.la files for MinGW packages.
> > 
> Is that a "We need the *.la files for MinGW packages" or "We need the
> *.la files in MinGW packages"?

I'm going to do a bit more testing on this tomorrow to make sure this
is really true, then get back to you about it ...

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 jwboyer at gmail.com  Sun Nov  2 12:53:03 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Sun, 2 Nov 2008 07:53:03 -0500
Subject: Fedora 9 spins beta???
In-Reply-To: <loom.20081101T154711-548@post.gmane.org>
References: <gec0ih$fl9$1@ger.gmane.org>
	<loom.20081030T103319-30@post.gmane.org>
	<gec437$r9p$1@ger.gmane.org>
	<loom.20081030T111628-898@post.gmane.org>
	<gegacs$rir$1@ger.gmane.org> <490BD4F4.3080101@fedoraproject.org>
	<loom.20081101T154711-548@post.gmane.org>
Message-ID: <20081102125303.GA11707@zod.rchland.ibm.com>

On Sat, Nov 01, 2008 at 03:47:45PM +0000, Kevin Kofler wrote:
>Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
>> It is already official.
>
>Shouldn't the description on spins.fedoraproject.org be changed to remove the
>"BETA" label?

Yes.  I have failed to do this repeatedly now.  I will try later today.

josh



From valent.turkovic at gmail.com  Sun Nov  2 20:29:55 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Sun, 2 Nov 2008 21:29:55 +0100
Subject: Software is once again unpatentable in the United States
Message-ID: <64b14b300811021229h5551a891i990eb3fccca2b9b5@mail.gmail.com>

Quote from http://www.pli.edu/patentcenter/blog.asp?view=plink&id=368 :

Here are the highlights:

  * The Federal Circuit rejected the that the "useful, concrete and tangible
	result" inquiry as being inadequate.

  * Patentability under 101 does not depend on process steps, but rather
	requires a tangible machine or transformation into a different state.

  * *Software* *is* *once* *again* *unpatentable* *in* *the* *United* *States*

  * In order to protect what was formerly known as patentable software we
	will have to go back to claiming a machine that provides certain
	functionality.

  * Software patents that have been issued under the previous understanding
	of the law are almost certainly now worthless.

-- 
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 drago01 at gmail.com  Sun Nov  2 20:32:25 2008
From: drago01 at gmail.com (drago01)
Date: Sun, 2 Nov 2008 21:32:25 +0100
Subject: PolicyKit auditing - was Re: Fedora 11: moving to posix file
	capabilities?
In-Reply-To: <faa16b610810291417n7e9f73bavaf99d303fc840577@mail.gmail.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<200810291640.00051.sgrubb@redhat.com>
	<faa16b610810291352p5b5e9002n2af909ab1ffe1cd2@mail.gmail.com>
	<200810291704.43907.sgrubb@redhat.com>
	<faa16b610810291417n7e9f73bavaf99d303fc840577@mail.gmail.com>
Message-ID: <f6ca9fed0811021232pe0141b6j71667c98a89acdd3@mail.gmail.com>

On Wed, Oct 29, 2008 at 10:17 PM, Colin Walters <walters at verbum.org> wrote:

> [1] Why the heck is my F9 desktop running iscsid?

pulled in by libvirt



From pemboa at gmail.com  Sun Nov  2 20:40:47 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Sun, 2 Nov 2008 14:40:47 -0600
Subject: Software is once again unpatentable in the United States
In-Reply-To: <64b14b300811021229h5551a891i990eb3fccca2b9b5@mail.gmail.com>
References: <64b14b300811021229h5551a891i990eb3fccca2b9b5@mail.gmail.com>
Message-ID: <16de708d0811021240y3adfb1f6u7b0db89dbc63db5d@mail.gmail.com>

On Sun, Nov 2, 2008 at 2:29 PM, Valent Turkovic
<valent.turkovic at gmail.com> wrote:
> Quote from http://www.pli.edu/patentcenter/blog.asp?view=plink&id=368 :
>
> Here are the highlights:
>
>  * The Federal Circuit rejected the that the "useful, concrete and tangible
>        result" inquiry as being inadequate.
>
>  * Patentability under 101 does not depend on process steps, but rather
>        requires a tangible machine or transformation into a different state.
>
>  * *Software* *is* *once* *again* *unpatentable* *in* *the* *United* *States*
>
>  * In order to protect what was formerly known as patentable software we
>        will have to go back to claiming a machine that provides certain
>        functionality.
>
>  * Software patents that have been issued under the previous understanding
>        of the law are almost certainly now worthless.


Wait a few months. It's likely that some involved haven't received
their cheques yet.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From konrad at tylerc.org  Sun Nov  2 21:04:48 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Sun, 2 Nov 2008 14:04:48 -0700
Subject: Software is once again unpatentable in the United States
In-Reply-To: <64b14b300811021229h5551a891i990eb3fccca2b9b5@mail.gmail.com>
References: <64b14b300811021229h5551a891i990eb3fccca2b9b5@mail.gmail.com>
Message-ID: <200811021304.49218.konrad@tylerc.org>

For a more accurate summary of this court decision, try this reference:

http://www.groklaw.net/article.php?story=20081030150903555

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




From lesmikesell at gmail.com  Sun Nov  2 21:09:03 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 02 Nov 2008 15:09:03 -0600
Subject: Software is once again unpatentable in the United States
In-Reply-To: <64b14b300811021229h5551a891i990eb3fccca2b9b5@mail.gmail.com>
References: <64b14b300811021229h5551a891i990eb3fccca2b9b5@mail.gmail.com>
Message-ID: <490E16EF.40709@gmail.com>

Valent Turkovic wrote:
> Quote from http://www.pli.edu/patentcenter/blog.asp?view=plink&id=368 :
> 
> Here are the highlights:
> 
>   * The Federal Circuit rejected the that the "useful, concrete and tangible
> 	result" inquiry as being inadequate.
> 
>   * Patentability under 101 does not depend on process steps, but rather
> 	requires a tangible machine or transformation into a different state.
> 
>   * *Software* *is* *once* *again* *unpatentable* *in* *the* *United* *States*
> 
>   * In order to protect what was formerly known as patentable software we
> 	will have to go back to claiming a machine that provides certain
> 	functionality.
> 
>   * Software patents that have been issued under the previous understanding
> 	of the law are almost certainly now worthless.

This is a step in the right direction in terms of seeing most software 
as math operations instead of a model of hardware.  But the Supreme 
Court is probably going to have to rule on it before the matter is 
settled - if the legislation isn't changed first to be more explicit.

But the concept that I'd really like to see put forth is that if, as a 
consumer, you have one set of bits incorporating a patented algorithm 
you then have the right to use any other arrangement of bits to 
accomplish that same algorithm's effect, just as in the hardware case 
that this is supposed to model, you would be permitted to rearrange and 
alter the parts of your licensed device without having to purchase a new 
license to cover the same patent.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From luis at tieguy.org  Sun Nov  2 21:13:22 2008
From: luis at tieguy.org (Luis Villa)
Date: Sun, 2 Nov 2008 16:13:22 -0500
Subject: [Fedora-legal-list] Software is once again unpatentable in the
	United States
In-Reply-To: <64b14b300811021229h5551a891i990eb3fccca2b9b5@mail.gmail.com>
References: <64b14b300811021229h5551a891i990eb3fccca2b9b5@mail.gmail.com>
Message-ID: <2cb10c440811021313r28e16697m6b146861dd34367c@mail.gmail.com>

[Apologies to those on legal-list who get this multiple times, but I
wasn't sub'd to f-d-l.]

[This is not legal advice; I am not a lawyer (yet); if you're seeking
understanding of the current state of software patents you should seek
a lawyer with expertise in the field.]

On Sun, Nov 2, 2008 at 3:29 PM, Valent Turkovic
<valent.turkovic at gmail.com> wrote:
> Quote from http://www.pli.edu/patentcenter/blog.asp?view=plink&id=368 :
>
> Here are the highlights:
>
>  * The Federal Circuit rejected the that the "useful, concrete and tangible
>        result" inquiry as being inadequate.
>
>  * Patentability under 101 does not depend on process steps, but rather
>        requires a tangible machine or transformation into a different state.
>
>  * *Software* *is* *once* *again* *unpatentable* *in* *the* *United* *States*
>
>  * In order to protect what was formerly known as patentable software we
>        will have to go back to claiming a machine that provides certain
>        functionality.
>
>  * Software patents that have been issued under the previous understanding
>        of the law are almost certainly now worthless.


That is almost certainly an over-reading of the case. The case
(Bilski) does say that a patent must involve a 'particular machine',
but the case very explicitly does not define a 'particular machine',
and no one knows what a particular machine really is.

Plausible arguments can be made (and most certainly will be made) that
general-purpose PCs are 'particular machines' for the purposes of
patent law; the opposite argument has also been made, including by the
Patent and Trade Office itself. Until that question is settled, it
would be very premature to say that software patents in the US are on
the outs.

Or to put it another way: if someone sued you for a violation of a
software patent tomorrow, Bilski would be a critical and central part
of your defense, and you might win, but you'd still be in for a trial
lasting years and costing millions of dollars. If you won, you'd be a
hero to anyone who dislikes software patents, and your case would be
cited for years to come as the real milestone case (not Bilski.) But
you would also stand a significant chance of losing. You have a much
better chance of winning than you did before Bilski, but still a big
chance of losing.

If this case were as definitive as the linked author makes it sound,
and you were sued tomorrow, Bilski would be all of your defense and
your case would quickly be thrown out. But that is simply not the
case.

Luis



From ville.skytta at iki.fi  Sun Nov  2 21:38:51 2008
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Sun, 2 Nov 2008 23:38:51 +0200
Subject: Directory for drop-in config files in rpmlint 0.85-2
Message-ID: <200811022338.51642.ville.skytta@iki.fi>

rpmlint 0.85-2 has been pushed to F-9 and Rawhide (and will be pushed to F-10 
as soon as Bodhi starts accepting F-10 updates).  I'd like to point out one 
thing about this release:

rpmlint now reads all *config files from /etc/rpmlint as config files.  This 
means that packages can now drop their own message filters etc there [0] and 
rpmlint does no need to be patched or its default config changed as often as 
before.

We'll see how this feature ends up being used, but personally I think it would 
be best to keep the number of files there small and collect filters etc in 
bigger "subsystem" chunks, such as is probably being already created for 
mingw32 (probably to be included in the ming32-filesystem package, and all 
mingw32-* would benefit).

[0] Usually, drop the *config there, and own the /etc/rpmlint directory unless 
your package already depends on rpmlint for some other reason.



From chris.stone at gmail.com  Sun Nov  2 21:38:49 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Sun, 2 Nov 2008 13:38:49 -0800
Subject: xine/gxine xine-plugin gxine-mozplugin confusion
Message-ID: <d9c612bf0811021338r2df7fb54gd2229c0e4861cfae@mail.gmail.com>

Hi,

What the heck is the difference between xine, and gxine and
xine-plugin and gxine-mozplugin?  And which should I have installed,
if any?  Is totem better the xine/gxine?

Also, I tried removing all my xine rpms because I was getting massive
selinux deinal messages with it [1], and the result is some cheezy
looking interface in firefox [2].  How can I make it so totem and/or
xine/gxine runs inside firefox instead of in a seperate window?

TIA to anyone who can bring me some clarity with regards to this.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=469571
[2] http://tkmame.retrogames.com/totem_plug.png



From gemi at bluewin.ch  Sun Nov  2 22:11:01 2008
From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister)
Date: Sun, 02 Nov 2008 23:11:01 +0100
Subject: Orphaning GCL
Message-ID: <1225663861.4906.15.camel@localhost.localdomain>

Hi,

I am orphaning GCL (GNU Common Lisp):
https://admin.fedoraproject.org/pkgdb/packages/name/gcl

I cannot get it to build on any platform anymore and have
not been successful in gathering support. I hope somebody
else will have more success.

gemi



From chris.stone at gmail.com  Sun Nov  2 23:18:03 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Sun, 2 Nov 2008 15:18:03 -0800
Subject: xine/gxine xine-plugin gxine-mozplugin confusion
In-Reply-To: <d9c612bf0811021338r2df7fb54gd2229c0e4861cfae@mail.gmail.com>
References: <d9c612bf0811021338r2df7fb54gd2229c0e4861cfae@mail.gmail.com>
Message-ID: <d9c612bf0811021518u5cdb59ecnf3a33f5e206c8203@mail.gmail.com>

On Sun, Nov 2, 2008 at 1:38 PM, Christopher Stone <chris.stone at gmail.com> wrote:
>  How can I make it so totem and/or
> xine/gxine runs inside firefox instead of in a seperate window?

Okay, it seems removing mozplugger solves that problem (thanks ivazquez)



From bpepple at fedoraproject.org  Sun Nov  2 23:38:52 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Sun, 02 Nov 2008 18:38:52 -0500
Subject: FESCo Meeting Summary for 2008-10-29
Message-ID: <1225669132.8280.7.camel@kennedy>

=== Members Present ===
* Brian Pepple          (bpepple)
* Jarod Wilson          (j-rod)
* Bill Nottingham       (notting)
* Jon Stanley           (jds2001)
* Dennis Gilmore        (dgilmore)
* Josh Boyer            (jwb)
* David Woodhouse       (dwmw2)
* Karsten Hopp          (kick_)
* Kevin Fenzi           (nirik)

== Summary ==
=== Features ===
* FESCo pushed the EFI(1) feature to F11, since it wasn't complete by
the devel freeze. 
* FESCo approved Java Liveconnect(2) as a feature for F10, even though
it was submitted late.  They felt this feature warranted giving an
exception to, since it's a feature that was created by in-house at
Fedora, and there was no open source solution that provided Liveconnect
support. NOTE: In the interest of being fair, FESCo will look at giving
the features that were dropped due to not meeting the feature freeze
deadline the same exception, providing they were completed by the devel
freeze. 
     1. https://fedoraproject.org/wiki/Features/EFI
     2. http://fedoraproject.org/wiki/Features/Liveconnect

=== Elections ===
* Briefly discussed the dates (Dec. 7 - Dec 20) for the upcoming FESCo
election.

=== Comps ===
* FESCo brain-stormed for a bit on ways to improve comps.  Some of the
ideas were:
      * Having a Grand Arbitrator of Comps (notting's name was thrown as
        a possible candidate)
      * Use pkgdb to manage comps
      * Making comps a MUST item in the package review.
* In the interim, notting will update the comps wiki page to better
clarify what should be included in comps, and FESCo will discuss some
more whether to make comps a MUST item in the review process.

IRC log can be found at:
http://bpepple.fedorapeople.org/fesco/FESCo-2008-10-29.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/20081102/96d4388c/attachment.sig>

From chris.stone at gmail.com  Mon Nov  3 00:13:07 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Sun, 2 Nov 2008 16:13:07 -0800
Subject: FESCo Meeting Summary for 2008-10-29
In-Reply-To: <1225669132.8280.7.camel@kennedy>
References: <1225669132.8280.7.camel@kennedy>
Message-ID: <d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>

2008/11/2 Brian Pepple <bpepple at fedoraproject.org>:
> === Comps ===
> * FESCo brain-stormed for a bit on ways to improve comps.  Some of the
> ideas were:
>      * Having a Grand Arbitrator of Comps (notting's name was thrown as
>        a possible candidate)
>      * Use pkgdb to manage comps
>      * Making comps a MUST item in the package review.
> * In the interim, notting will update the comps wiki page to better
> clarify what should be included in comps, and FESCo will discuss some
> more whether to make comps a MUST item in the review process.

All packages should go in comps.  I don't know why notting is against
this?!!?  Why should my php-pear-* packages be excluded from comps for
example?  Just because some newb might not want to install them does
not mean a php web developer would not use comps to install them.



From mattdm at mattdm.org  Mon Nov  3 00:54:09 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 2 Nov 2008 19:54:09 -0500
Subject: FESCo Meeting Summary for 2008-10-29
In-Reply-To: <d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
Message-ID: <20081103005409.GA9247@jadzia.bu.edu>

On Sun, Nov 02, 2008 at 04:13:07PM -0800, Christopher Stone wrote:
> All packages should go in comps.  I don't know why notting is against
> this?!!?  Why should my php-pear-* packages be excluded from comps for
> example?  Just because some newb might not want to install them does
> not mean a php web developer would not use comps to install them.

If all packages are to go in comps, we need a more fine-grained comps.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From chris.stone at gmail.com  Mon Nov  3 01:00:12 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Sun, 2 Nov 2008 17:00:12 -0800
Subject: FESCo Meeting Summary for 2008-10-29
In-Reply-To: <20081103005409.GA9247@jadzia.bu.edu>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
Message-ID: <d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>

On Sun, Nov 2, 2008 at 4:54 PM, Matthew Miller <mattdm at mattdm.org> wrote:
> On Sun, Nov 02, 2008 at 04:13:07PM -0800, Christopher Stone wrote:
>> All packages should go in comps.  I don't know why notting is against
>> this?!!?  Why should my php-pear-* packages be excluded from comps for
>> example?  Just because some newb might not want to install them does
>> not mean a php web developer would not use comps to install them.
>
> If all packages are to go in comps, we need a more fine-grained comps.

I concur.



From skvidal at fedoraproject.org  Mon Nov  3 03:27:05 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Sun, 2 Nov 2008 22:27:05 -0500 (EST)
Subject: FESCo Meeting Summary for 2008-10-29
In-Reply-To: <d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
Message-ID: <alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>



On Sun, 2 Nov 2008, Christopher Stone wrote:

> On Sun, Nov 2, 2008 at 4:54 PM, Matthew Miller <mattdm at mattdm.org> wrote:
>> On Sun, Nov 02, 2008 at 04:13:07PM -0800, Christopher Stone wrote:
>>> All packages should go in comps.  I don't know why notting is against
>>> this?!!?  Why should my php-pear-* packages be excluded from comps for
>>> example?  Just because some newb might not want to install them does
>>> not mean a php web developer would not use comps to install them.
>>
>> If all packages are to go in comps, we need a more fine-grained comps.
>
> I concur.

more fine-grained how?

-sv



From douglas at paradise.net.nz  Mon Nov  3 03:47:44 2008
From: douglas at paradise.net.nz (Douglas Bagnall)
Date: Mon, 3 Nov 2008 16:47:44 +1300
Subject: undefined symbol: __stack_chk_fail_local
In-Reply-To: <20081030121002.GT14706@tyan-ft48-01.lab.bos.redhat.com>
References: <d24e24ab0810300256t232fd400s531fe07f5cd7e17f@mail.gmail.com>
	<20081030121002.GT14706@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: <d24e24ab0811021947g3693a471ld237b102a0b6b99e@mail.gmail.com>

>> http://sundaram.fedorapeople.org/packages/pam_sotp-0.3.3-1.fc9.src.rpm
>>
>>  PAM unable to dlopen(/lib/security/pam_sotp.so): \
>>   /lib/security/pam_sotp.so: undefined symbol: __stack_chk_fail_local
>>
>>   Some googling suggested linking with gcc rather than ld, but I
>> can't work out how to make the rpm do that.

Jakub Jelinek wrote:

> Yeah, that's very likely the case.  Linking with ld -shared as opposed
> to gcc -shared is (almost always) a bug.
> Guess you need to modify this package's Makefiles to do the right thing...

OK, thanks. I found the right Makefile.in, fixed it, and it works.


and Andrew Haley wrote:

>> (This is all Fedora 9, gcc-4.3.0-8.i386).
>
>This symbol hould be in /lib/libc.so.6.  Isn't it?

No.  At least not according to strings or nm.  It is in
/usr/lib/libc.a though (and __stack_chk_fail is in libc.so.6).  That's
with glibc-2.8-8.i686.

thanks to both of you for your help.


Douglas



From ville.skytta at iki.fi  Mon Nov  3 06:39:34 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Mon, 3 Nov 2008 08:39:34 +0200
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <1225495446.25414.377.camel@ignacio.lan>
References: <528188.21827.qm@web32801.mail.mud.yahoo.com>
	<1225495446.25414.377.camel@ignacio.lan>
Message-ID: <200811030839.34865.ville.skytta@iki.fi>

On Saturday 01 November 2008, Ignacio Vazquez-Abrams wrote:
> On Fri, 2008-10-31 at 16:11 -0700, Orcan Ogetbil wrote:
> > I think some code can be borrowed from rpmlint.
>
> Borrowing code is a losing proposition. What we need is for the main
> rpmlint script to be refactored so that we can call it with a filename.

I'm not sure what you mean by "call it with a filename", could you elaborate?  
Specfiles, package .rpm files and directories can already be passed to it.



From ivazqueznet at gmail.com  Mon Nov  3 07:09:05 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Mon, 03 Nov 2008 02:09:05 -0500
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <200811030839.34865.ville.skytta@iki.fi>
References: <528188.21827.qm@web32801.mail.mud.yahoo.com>
	<1225495446.25414.377.camel@ignacio.lan>
	<200811030839.34865.ville.skytta@iki.fi>
Message-ID: <1225696145.25414.566.camel@ignacio.lan>

On Mon, 2008-11-03 at 08:39 +0200, Ville Skytt? wrote:
> On Saturday 01 November 2008, Ignacio Vazquez-Abrams wrote:
> > On Fri, 2008-10-31 at 16:11 -0700, Orcan Ogetbil wrote:
> > > I think some code can be borrowed from rpmlint.
> >
> > Borrowing code is a losing proposition. What we need is for the main
> > rpmlint script to be refactored so that we can call it with a filename.
> 
> I'm not sure what you mean by "call it with a filename", could you elaborate?  
> Specfiles, package .rpm files and directories can already be passed to it.

Right now rpmlint.py contains a large amount of magick, in the forms of
a lot of global code and a rather complex main(). It would be handy
various functions could be called that loaded the tests, tested the
files, and processed the results. That way rpmlint could be used as part
of a larger Python app such as the future Review-o-Matic.

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

From rjones at redhat.com  Mon Nov  3 10:22:41 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 3 Nov 2008 10:22:41 +0000
Subject: Policy on circular build deps?
Message-ID: <20081103102241.GA16659@amd.home.annexia.org>


Is there a policy on whether circular build dependencies are permitted
or not?  The nearest I can find is this (obsolete?) page:

https://fedoraproject.org/wiki/Extras/PackagesNeedingBootstrap

MinGW has one hard circular dependency which will require rel-eng
cooperation to build first time[1], but we also have another one which
is only a "nice to have" (mingw32-iconv & mingw32-gettext[2]).

Rich.

[1] https://fedoraproject.org/wiki/MinGW/Bootstrapping
[2] As noted in this file: http://www.annexia.org/tmp/mingw32-iconv.spec

-- 
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 rawhide at fedoraproject.org  Mon Nov  3 10:24:58 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Mon,  3 Nov 2008 10:24:58 +0000 (UTC)
Subject: rawhide report: 20081103 changes
Message-ID: <20081103102458.B7F911F8252@releng2.fedora.phx.redhat.com>

Compose started at Mon Nov  3 06:01:07 UTC 2008

Updated Packages:

amarok-1.94-2.fc10
------------------
* Fri Oct 31 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1.94-2
- amarok-1.94 (2beta4)


anaconda-11.4.1.54-1
--------------------
* Thu Oct 30 18:00:00 2008 David Cantrell <dcantrell at redhat.com> - 11.4.1.54-1
- Call startNewt earlier than network bring up (#469171). (clumens)
- Write out the path to the repo, not anaconda-ks.cfg (#467753). (clumens)
- Allow specifying devices by path if they're files (#468504) (katzj)
- Fix the last pychecker warnings in master (hdegoede)
- Add --strict option to runpychecker.sh (hdegoede)


eclipse-mylyn-3.0.3-3.fc10
--------------------------
* Fri Oct 31 18:00:00 2008 Alexander Kurtakov <akurtako at redhat.com> 3.0.3-3
- Don't apply nojaxb.patch.
- Fix eclipse-mylyn-splitxmlrpc.patch to Import-Package:org.apache.xmlrpc.


gnome-chemistry-utils-0.10.0-1.fc10
-----------------------------------
* Fri Oct 31 18:00:00 2008 Julian Sikorski <belegdol[at]gmail[dot]com> - 0.10.0-1
- Updated to 0.10.0


initscripts-8.85-1
------------------
* Fri Oct 31 18:00:00 2008 Bill Nottingham <notting at redhat.com> - 8.85-1
- add some error handling/hiding to netfs NM dispatcher script (#469197)
- halt: fix code that causes a syntax error on multiple sound cards (#469156)
- require a new enough udev version to handle where we put the rules
- exit 0 in /etc/rc.d/rc (#469050)
- don't set up encrypted devices that have already been set up under different
  names (#462371, <wwoods at redhat.com>)
- accept either the '+<addr>', or comma-separated addresses for arp_ip_target. (#467954,
  <darcy.sherwood at gmail.com>)
- translation updates: hu, kn, ko, ml, sr, sr at latin


kde-settings-4.1-4.20081031svn.fc10
-----------------------------------
* Fri Oct 31 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1-4
- KPackageKit: [CheckUpdate] autoUpdate=0 (#469375)


kdebase-workspace-4.1.2-10.fc10
-------------------------------
* Sun Nov  2 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.2-10
- never touch PATH in startkde, prepending $QTDIR/bin is unnecessary on Fedora
  and breaks locating Qt 3 Assistant and other Qt 3 stuff (startkde gets run
  with a full path by KDM)

* Sat Nov  1 18:00:00 2008 Than Ngo <than at redhat.com> 4.1.2-9
- previous session button should be enabled

* Fri Oct 31 18:00:00 2008 Than Ngo <than at redhat.com> 4.1.2-8
- apply patch to fix multihead issue
- bz#469235, use non-blocking QProcess:startDetacted


ldm-2.0.16-1.fc10
-----------------

libpng10-1.0.41-1.fc10
----------------------
* Fri Oct 31 18:00:00 2008 Paul Howarth <paul at city-fan.org> 1.0.41-1
- update to 1.0.41 (addresses #468990, memory leak after reading a malformed
  tEXt chunk)


ltsp-5.1.32-1.fc10
------------------
* Sat Nov  1 18:00:00 2008 Warren Togami <wtogami at redhat.com> - 5.1.32-1
- Exclude wireless drivers because they cannot netboot, and they can often
  cause boot problems because of missing firmware
- Point Fedora 10 client chroot at Fedora 10 mirrormanager


pulseaudio-0.9.13-6.fc10
------------------------
* Sat Nov  1 18:00:00 2008 Lennart Poettering <lpoetter at redhat.com> 0.9.13-6
- Backport another two fixes from current git master

* Tue Oct 28 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> 0.9.13-5
- Require new enough speex-devel


rpm-4.6.0-0.rc1.7
-----------------
* Fri Oct 31 18:00:00 2008 Panu Matilainen <pmatilai at redhat.com>
- adjust find-debuginfo for "file" output change (#468129)


solar-kde-theme-0.1.12-1.fc10
-----------------------------
* Fri Oct 31 18:00:00 2008 Than Ngo <than at redhat.com> 0.1.12-1
- fix multihead issue
- fix topline/inputbox issue
- fix date string runs past the boundaries with DPI=120


system-config-nfs-1.3.41-1.fc10
-------------------------------
* Thu Oct 30 18:00:00 2008 Nils Philippsen <nphilipp at redhat.com> - 1.3.41-1
- require usermode-gtk instead of usermode

* Tue Jul 15 18:00:00 2008 Nils Philippsen <nphilipp at redhat.com>
- fix entry labels that are for setting both TCP and UDP ports
- add option for rquotad port


system-config-samba-1.2.66-1.fc10
---------------------------------
* Fri Oct 31 18:00:00 2008 Nils Philippsen <nils at redhat.com> - 1.2.66-1
- fix typo that caused traceback

* Tue Oct 28 18:00:00 2008 Nils Philippsen <nils at redhat.com> - 1.2.65-1
- don't use consolehelper (#467784)
- fix installation without DESTDIR set

* Fri Oct 17 18:00:00 2008 Nils Philippsen <nils at redhat.com>
- use temporary smbusers file (/etc/samba/smbusers.new) for writing, then
  rename

* Fri Oct 10 18:00:00 2008 Nils Philippsen <nils at redhat.com>
- default to not using dbus as root and using dbus otherwise

* Fri Aug 29 18:00:00 2008 Nils Philippsen <nils at redhat.com>
- don't remove widgets in the add/edit user dialog when editing users (#460323)

* Thu Aug 28 18:00:00 2008 Nils Philippsen <nils at redhat.com>
- make --no-dbus work
- dump error message in case of pdbedit errors that don't stem from the user
  not being root (#460437)


system-config-services-0.99.25-1.fc10
-------------------------------------
* Tue Oct 28 18:00:00 2008 Nils Philippsen <nils at redhat.com> - 0.99.25-1
- let gettext return the correct encoding (#468351)
- backout use of slip.dbus.proxy.unknown_method_default as this breaks things
  drastically

* Fri Oct 17 18:00:00 2008 Nils Philippsen <nils at redhat.com>
- use slip.dbus.proxy.unknown_method_default to handle objects that vanished
  from the bus


system-config-users-1.2.81-1.fc10
---------------------------------
* Thu Oct 30 18:00:00 2008 Nils Philippsen <nphilipp at redhat.com> - 1.2.81-1
- require usermode-gtk instead of usermode


uw-imap-2007d-1.fc10
--------------------
* Fri Oct 31 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 2007d-1
- imap-2007d


xmlrpc3-3.0-2.9.fc10
--------------------
* Fri Oct 31 18:00:00 2008 Alexander Kurtakov <akurtako at redhat.com> 3.0-2.9
- Fix client osgi manifest - client should require common bundle.


Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 19









Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot





From denis at poolshark.org  Mon Nov  3 10:46:47 2008
From: denis at poolshark.org (Denis Leroy)
Date: Mon, 03 Nov 2008 11:46:47 +0100
Subject: FESCo Meeting Summary for 2008-10-29
In-Reply-To: <20081103005409.GA9247@jadzia.bu.edu>
References: <1225669132.8280.7.camel@kennedy>	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
Message-ID: <490ED697.4000503@poolshark.org>

Matthew Miller wrote:
> On Sun, Nov 02, 2008 at 04:13:07PM -0800, Christopher Stone wrote:
>> All packages should go in comps.  I don't know why notting is against
>> this?!!?  Why should my php-pear-* packages be excluded from comps for
>> example?  Just because some newb might not want to install them does
>> not mean a php web developer would not use comps to install them.
> 
> If all packages are to go in comps, we need a more fine-grained comps.

Comps evolved over time into something that doesn't make a whole bunch 
of sense to me. Is the main use of comps still for installation groups 
within yum and anaconda ? A lot of packages are not installation 
"targets" but simply libraries that should only be installed by being 
pulled in from dependency resolution. Now if we're trying to 
"categorize" all packages nonetheless, it'd be better to have a 
tag-based system from packagedb, where packages can be "tagged" 
a-la-gmail, and also belong into multiple tag groups as some things
  really belong into multiple categories...



From nicolas.mailhot at laposte.net  Mon Nov  3 10:58:06 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 3 Nov 2008 11:58:06 +0100 (CET)
Subject: FESCo Meeting Summary for 2008-10-29
In-Reply-To: <490ED697.4000503@poolshark.org>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<490ED697.4000503@poolshark.org>
Message-ID: <e258687eed7e156ebac3647bcf962d50.squirrel@arekh.dyndns.org>



Le Lun 3 novembre 2008 11:46, Denis Leroy a ?crit :

> Comps evolved over time into something that doesn't make a whole bunch
> of sense to me. Is the main use of comps still for installation groups
> within yum and anaconda ? A lot of packages are not installation
> "targets" but simply libraries that should only be installed by being
> pulled in from dependency resolution. Now if we're trying to
> "categorize" all packages nonetheless, it'd be better to have a
> tag-based system from packagedb, where packages can be "tagged"
> a-la-gmail, and also belong into multiple tag groups as some things
>   really belong into multiple categories...

This tag-based system still needs to have a human-editable file
deployment format since we do want third-party and private
repositories to be categorised and 'just install packagedb' won't ever
fly.

Right now this deployment format is comps.

I agree it is less than ideal, but so far no clear entity has stepped
up to make it evolve (and any evolution would need
anaconda/yum/packagedb/packagekit/spin-tools buy-in).

-- 
Nicolas Mailhot



From ndbecker2 at gmail.com  Mon Nov  3 13:37:41 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Mon, 03 Nov 2008 08:37:41 -0500
Subject: mod_python error from koji
Message-ID: <gemur5$28d$1@ger.gmane.org>

koji is broken?:

http://koji.fedoraproject.org/koji/taskinfo?taskID=9155140

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 413, in taskinfo
    task = server.getTaskInfo(taskID, request=True)

  File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1133, in __call__
    return self.__func(self.__name,args,opts)

  File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1378, in _callMethod
    raise err

GenericError: query returned no rows



From gilboad at gmail.com  Mon Nov  3 13:58:38 2008
From: gilboad at gmail.com (Gilboa Davara)
Date: Mon, 03 Nov 2008 15:58:38 +0200
Subject: Semi-OT: makedepend isn't aware of
	/usr/lib/gcc/$ARCH-redhat-linux/4.3.0/include/
Message-ID: <1225720718.5355.29.camel@gilboa-work-dev.localdomain>

Hello all,

I'm not sure if this is a bug or not, so I'm posting here before I open
up a BZ.

Here's a short test program:

$ cat test.c
#include <stdlib.h>
#include <stdio.h>


int main(int argc, char *argv[])
{
        printf("Hello world\n");
        return 0;
}

$ makedepend -f- test.c 
# DO NOT DELETE                                   
makedepend: warning:  test.c (reading /usr/include/stdlib.h, line 33): cannot find include file "stddef.h"                                                                                            
        not in /usr/include/stddef.h                                                                
makedepend: warning:  test.c (reading /usr/include/sys/types.h, line 147): cannot find include file "stddef.h"                                                                                          
        not in /usr/include/stddef.h                                                                
makedepend: warning:  test.c (reading /usr/include/alloca.h, line 25): cannot find include file "stddef.h"                                                                                              
        not in /usr/include/stddef.h                                                                
makedepend: warning:  test.c (reading /usr/include/stdio.h, line 34): cannot find include file "stddef.h"                                                                                               
        not in /usr/include/stddef.h                                                                
makedepend: warning:  test.c (reading /usr/include/_G_config.h, line 15): cannot find include file "stddef.h"
        not in /usr/include/stddef.h
makedepend: warning:  test.c (reading /usr/include/wchar.h, line 52): cannot find include file "stddef.h"
        not in /usr/include/stddef.h
makedepend: warning:  test.c (reading /usr/include/libio.h, line 53): cannot find include file "stdarg.h"
        not in /usr/include/stdarg.h

.. But once I add the missing include. (/usr/lib/gcc/xxx)

$ makedepend -f- test.c  -I/usr/lib/gcc/x86_64-redhat-linux/4.3.0/include/
# DO NOT DELETE
test.o: /usr/include/stdlib.h /usr/include/features.h
test.o: /usr/include/sys/cdefs.h /usr/include/bits/wordsize.h
test.o: /usr/include/gnu/stubs.h /usr/include/gnu/stubs-64.h
test.o: /usr/lib/gcc/x86_64-redhat-linux/4.3.0/include/stddef.h
test.o: /usr/include/sys/types.h /usr/include/bits/types.h
test.o: /usr/include/bits/typesizes.h /usr/include/time.h
test.o: /usr/include/endian.h /usr/include/bits/endian.h
test.o: /usr/include/sys/select.h /usr/include/bits/select.h
test.o: /usr/include/bits/sigset.h /usr/include/bits/time.h
test.o: /usr/include/sys/sysmacros.h /usr/include/bits/pthreadtypes.h
test.o: /usr/include/alloca.h /usr/include/stdio.h /usr/include/libio.h
test.o: /usr/include/_G_config.h /usr/include/wchar.h
test.o: /usr/lib/gcc/x86_64-redhat-linux/4.3.0/include/stdarg.h
test.o: /usr/include/bits/stdio_lim.h /usr/include/bits/sys_errlist.h

Shouldn't makedepend be aware of the hardware coded include
path /usr/lib/gcc/$ARCH-redhat-linux/xxx?

- Gilboa



From laxathom at fedoraproject.org  Mon Nov  3 14:06:35 2008
From: laxathom at fedoraproject.org (Xavier Lamien)
Date: Mon, 3 Nov 2008 15:06:35 +0100
Subject: mod_python error from koji
In-Reply-To: <gemur5$28d$1@ger.gmane.org>
References: <gemur5$28d$1@ger.gmane.org>
Message-ID: <62bc09df0811030606v64a58a1cj8590532d754699e1@mail.gmail.com>

On Mon, Nov 3, 2008 at 2:37 PM, Neal Becker <ndbecker2 at gmail.com> wrote:
> koji is broken?:

Could you re-run your task, that should work fine now.

-- 
Xavier.t Lamien
--
http://fedoraproject.org/wiki/XavierLamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB



From billcrawford1970 at gmail.com  Mon Nov  3 14:05:14 2008
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Mon, 3 Nov 2008 14:05:14 +0000
Subject: Fedora  8 most popular (then 7?)
In-Reply-To: <490C572B.6030406@sapience.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225532125.4119.5.camel@hp6710.axianet.ch>
	<490C572B.6030406@sapience.com>
Message-ID: <200811031405.14260.billcrawford1970@gmail.com>

On Saturday 01 November 2008 13:18:35 Mail Lists wrote:
> On 11/01/2008 05:35 AM, Steven Moix wrote:
> > This leads me to think that these statistics are probably biased?
>
>   Could be - but that doesn't explain why its biased for F8 .. in fact
> would you not expect more people to use smolt over time - as suspicion
> fades about big brother etc ...

Well, I don't think I've submitted smolt stats for this machine, but it still 
runs F8 for two reasons:

1. KDE4 just wasn't ready for me to use here for work. Fun to play with at home, 
but I couldn't imagine using it here without some workflow changes. The latest 
versions I've seen in Rawhide would be pretty much usable at work now, BUT ...

2. I can't use the latest snapshots or Rawhide on my system here because X (and 
the boot sequence unless I use "nomodeset nofb? on the kernel command line) 
explodes, the OOPSes have gone to kerneloops.org, but the problem is, there is 
no support for soft-booting secondary video cards and I have three (all PCI) in 
this machine. Which helps me find bugs in xscreensaver ;o)

So, I simply cannot upgrade it at the moment. I have a partition with Rawhide 
installed, and as long as I use the kernel command line magic to stop the 
radeon drm driver loading, and run X on a single screen without DRI, it works 
well enough to see that KDE is now really pretty (looks like my WindowMaker 
desktop c. 1998 ;o) but that's good). I would love to upgrade, it's sweet.

>   Then I imagine the KDE issue has prevented many from upgrading until
> KDE 4.2 is out - too bad smolt cant easily answer the kde vs gnome usage
> - its not just an install issue - need to scan for dates inside .kde and
> .gnomeX perhaps - maybe ignore anything over X weeks old etc. Maybe
> someone can figure out a way.

Absolutely. I hung back waiting for F10 here, because I didn't find KDE4 to be 
ready for "production" use - but now I can't run it for other reasons.

[ please no flamewar about kde4 - I like it but it wasn't ready to replace 3.5 
*for me, in my working environment* yet; now, it looks like it is good enough, 
although I've not had a chance to investigate how well it works for multiple X 
heads, 'cause X don't work :o) ]



From mschwendt at gmail.com  Mon Nov  3 14:27:16 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 3 Nov 2008 15:27:16 +0100
Subject: Semi-OT: makedepend isn't aware of
 /usr/lib/gcc/$ARCH-redhat-linux/4.3.0/include/
In-Reply-To: <1225720718.5355.29.camel@gilboa-work-dev.localdomain>
References: <1225720718.5355.29.camel@gilboa-work-dev.localdomain>
Message-ID: <20081103152716.3fd98f45.mschwendt@gmail.com>

On Mon, 03 Nov 2008 15:58:38 +0200, Gilboa Davara wrote:

> $ makedepend -f- test.c 
> # DO NOT DELETE                                   
> makedepend: warning:  test.c (reading /usr/include/stdlib.h, line 33): cannot find include file "stddef.h"                                                                                            
>         not in /usr/include/stddef.h                                                                

Why not run gccmakedep instead?



From gilboad at gmail.com  Mon Nov  3 14:46:30 2008
From: gilboad at gmail.com (Gilboa Davara)
Date: Mon, 03 Nov 2008 16:46:30 +0200
Subject: Semi-OT: makedepend isn't aware of
	/usr/lib/gcc/$ARCH-redhat-linux/4.3.0/include/
In-Reply-To: <20081103152716.3fd98f45.mschwendt@gmail.com>
References: <1225720718.5355.29.camel@gilboa-work-dev.localdomain>
	<20081103152716.3fd98f45.mschwendt@gmail.com>
Message-ID: <1225723590.5355.33.camel@gilboa-work-dev.localdomain>

On Mon, 2008-11-03 at 15:27 +0100, Michael Schwendt wrote:
> On Mon, 03 Nov 2008 15:58:38 +0200, Gilboa Davara wrote:
> 
> > $ makedepend -f- test.c 
> > # DO NOT DELETE                                   
> > makedepend: warning:  test.c (reading /usr/include/stdlib.h, line 33): cannot find include file "stddef.h"                                                                                            
> >         not in /usr/include/stddef.h                                                                
> 
> Why not run gccmakedep instead?
> 

Interesting concept... Slipped my mid.
Thanks!

- Gilboa



From gilboad at gmail.com  Mon Nov  3 14:49:13 2008
From: gilboad at gmail.com (Gilboa Davara)
Date: Mon, 03 Nov 2008 16:49:13 +0200
Subject: Semi-OT: makedepend isn't aware of
	/usr/lib/gcc/$ARCH-redhat-linux/4.3.0/include/
In-Reply-To: <20081103152716.3fd98f45.mschwendt@gmail.com>
References: <1225720718.5355.29.camel@gilboa-work-dev.localdomain>
	<20081103152716.3fd98f45.mschwendt@gmail.com>
Message-ID: <1225723753.5355.35.camel@gilboa-work-dev.localdomain>

On Mon, 2008-11-03 at 15:27 +0100, Michael Schwendt wrote:
> On Mon, 03 Nov 2008 15:58:38 +0200, Gilboa Davara wrote:
> 
> > $ makedepend -f- test.c 
> > # DO NOT DELETE                                   
> > makedepend: warning:  test.c (reading /usr/include/stdlib.h, line 33): cannot find include file "stddef.h"                                                                                            
> >         not in /usr/include/stddef.h                                                                
> 
> Why not run gccmakedep instead?
> 

Now I remember.
I couldn't find a Win32 port of gccmakedep - only makedepend.
Though, come to think about it - I could use gccmakedep under Linux and
makedepend under Windows, as both behave the same.

- Gilboa



From ajax at redhat.com  Mon Nov  3 14:54:28 2008
From: ajax at redhat.com (Adam Jackson)
Date: Mon, 03 Nov 2008 09:54:28 -0500
Subject: Policy on circular build deps?
In-Reply-To: <20081103102241.GA16659@amd.home.annexia.org>
References: <20081103102241.GA16659@amd.home.annexia.org>
Message-ID: <1225724068.19538.245.camel@atropine.boston.devel.redhat.com>

On Mon, 2008-11-03 at 10:22 +0000, Richard W.M. Jones wrote:
> Is there a policy on whether circular build dependencies are permitted
> or not?  The nearest I can find is this (obsolete?) page:
> 
> https://fedoraproject.org/wiki/Extras/PackagesNeedingBootstrap
> 
> MinGW has one hard circular dependency which will require rel-eng
> cooperation to build first time[1], but we also have another one which
> is only a "nice to have" (mingw32-iconv & mingw32-gettext[2]).

I don't think there's any strict policy.  It's polite to mark the
packages needing special handling during bootstrap somehow.  In Mesa I
just note at the top of the specfile that the -demos subpackage needs to
be excluded on the way up (it needs libglut, which you can't build until
you've built a libGL, which the main Mesa package provides...)

- 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/20081103/b7698ea3/attachment.sig>

From ajax at redhat.com  Mon Nov  3 15:04:38 2008
From: ajax at redhat.com (Adam Jackson)
Date: Mon, 03 Nov 2008 10:04:38 -0500
Subject: Semi-OT: makedepend isn't aware of
 /usr/lib/gcc/$ARCH-redhat-linux/4.3.0/include/
In-Reply-To: <1225720718.5355.29.camel@gilboa-work-dev.localdomain>
References: <1225720718.5355.29.camel@gilboa-work-dev.localdomain>
Message-ID: <1225724678.19538.254.camel@atropine.boston.devel.redhat.com>

On Mon, 2008-11-03 at 15:58 +0200, Gilboa Davara wrote:
> Hello all,
> 
> I'm not sure if this is a bug or not, so I'm posting here before I open
> up a BZ.

makedepend is part of the imake package in Fedora. imake is - shall we
say - under a policy of malign neglect by upstream.  Rightly so, in my
opinion, but makedepend is legitimately useful on its own.

I think the only semi-serious problem with teaching makedepend more
about gcc is what to do in the face of multiple gcc versions.  We could
certainly make makedepend search %{_libdir}/gcc/`gcc -dumpmachine`/`gcc
-dumpversion`/include but that only works if you're building with gcc
and not say compat-gcc34.  Maybe inherit $CC from the environment and
use that?  Who knows.

Ideally you'd just use gccmakedep instead, but it doesn't support the
same set of options as makedepend so that may not be an option.

I'd take a patch, but that's about the extent to which I care about
being a build tools maintainer.

- 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/20081103/0e1c082e/attachment.sig>

From dbn.lists at gmail.com  Mon Nov  3 15:07:29 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Mon, 3 Nov 2008 07:07:29 -0800
Subject: Semi-OT: makedepend isn't aware of
	/usr/lib/gcc/$ARCH-redhat-linux/4.3.0/include/
In-Reply-To: <1225724678.19538.254.camel@atropine.boston.devel.redhat.com>
References: <1225720718.5355.29.camel@gilboa-work-dev.localdomain>
	<1225724678.19538.254.camel@atropine.boston.devel.redhat.com>
Message-ID: <91705d080811030707x5cde112dm6023227d307d4cc5@mail.gmail.com>

2008/11/3 Adam Jackson <ajax at redhat.com>:
> On Mon, 2008-11-03 at 15:58 +0200, Gilboa Davara wrote:
>> Hello all,
>>
>> I'm not sure if this is a bug or not, so I'm posting here before I open
>> up a BZ.
>
> makedepend is part of the imake package in Fedora. imake is - shall we
> say - under a policy of malign neglect by upstream.  Rightly so, in my
> opinion, but makedepend is legitimately useful on its own.
>
> I think the only semi-serious problem with teaching makedepend more
> about gcc is what to do in the face of multiple gcc versions.  We could
> certainly make makedepend search %{_libdir}/gcc/`gcc -dumpmachine`/`gcc
> -dumpversion`/include but that only works if you're building with gcc
> and not say compat-gcc34.  Maybe inherit $CC from the environment and
> use that?  Who knows.
>
> Ideally you'd just use gccmakedep instead, but it doesn't support the
> same set of options as makedepend so that may not be an option.
>
> I'd take a patch, but that's about the extent to which I care about
> being a build tools maintainer.

I have a patch somewhere that adds a --with-extra-include build option
for makedepend. It still means you have to rebuild makedepend whenever
gcc gets a major upgrade, but that was probably happening anyway. If
that sounds useful, I'll go locate it.

--
Dan



From rc040203 at freenet.de  Mon Nov  3 15:20:08 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 03 Nov 2008 16:20:08 +0100
Subject: Policy on circular build deps?
In-Reply-To: <1225724068.19538.245.camel@atropine.boston.devel.redhat.com>
References: <20081103102241.GA16659@amd.home.annexia.org>
	<1225724068.19538.245.camel@atropine.boston.devel.redhat.com>
Message-ID: <1225725608.2897.12.camel@beck.corsepiu.local>

On Mon, 2008-11-03 at 09:54 -0500, Adam Jackson wrote:
> On Mon, 2008-11-03 at 10:22 +0000, Richard W.M. Jones wrote:
> > Is there a policy on whether circular build dependencies are permitted
> > or not?  The nearest I can find is this (obsolete?) page:
> > 
> > https://fedoraproject.org/wiki/Extras/PackagesNeedingBootstrap
> > 
> > MinGW has one hard circular dependency which will require rel-eng
> > cooperation to build first time[1], but we also have another one which
> > is only a "nice to have" (mingw32-iconv & mingw32-gettext[2]).
> 
> I don't think there's any strict policy. 
Right.

>  It's polite to mark the
> packages needing special handling during bootstrap somehow.  In Mesa I
> just note at the top of the specfile that the -demos subpackage needs to
> be excluded on the way up (it needs libglut, which you can't build until
> you've built a libGL, which the main Mesa package provides...)

One approach trick is to have a special "--with/without" magic inside of
an rpm spec, which is sufficient to let subsequent incremental builds
succeed.

 IIRC, the ghc-case, they once had carried some binary packages inside
which were used to provide an initial build of other packages. A similar
approach can be applied to many cross-toolchains (Initially once "seed"
with binary packages, then later build incrementally).

Another approach is to "gradually introduce features", i.e. to initially
build a package with certain features disabled, use this package's
contents to built another package providing a feature, etc.
(Think building a gcc with i18n disabled to build iconv/libgettext, and
then build gcc with i18n enabled).

Ralf





From mattdm at mattdm.org  Mon Nov  3 15:28:57 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 3 Nov 2008 10:28:57 -0500
Subject: FESCo Meeting Summary for 2008-10-29
In-Reply-To: <alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
Message-ID: <20081103152857.GA20404@jadzia.bu.edu>

On Sun, Nov 02, 2008 at 10:27:05PM -0500, Seth Vidal wrote:
>>> If all packages are to go in comps, we need a more fine-grained comps.
>> I concur.
> more fine-grained how?

If comps ends up with a thousand programs under Games and Entertainment,
another thousand under Graphical Internet, etc., it's even more useless than
having nothing in comps at all. What would be the point? On the other hand,
having a thousand small comps groups is also no good.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From skvidal at fedoraproject.org  Mon Nov  3 15:36:53 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 3 Nov 2008 10:36:53 -0500 (EST)
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <20081103152857.GA20404@jadzia.bu.edu>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
Message-ID: <alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>

>
> If comps ends up with a thousand programs under Games and Entertainment,
> another thousand under Graphical Internet, etc., it's even more useless than
> having nothing in comps at all. What would be the point? On the other hand,
> having a thousand small comps groups is also no good.
>

So we're in the same boat if we start 'tagging' packages and/or if we just 
group them (which is essentially tagging from the other direction).


Let's take a step back. How do we group several thousand things such that 
they don't make the avg user lose his/her mind to look at them.

do we need groups of groups? A tree hierarchy the user can drill through? 
Font-sized tags like flickr/bloggers, etc?

I'm open to ideas, really. :)


-sv



From a.badger at gmail.com  Mon Nov  3 15:43:15 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 03 Nov 2008 07:43:15 -0800
Subject: FESCo Meeting Summary for 2008-10-29
In-Reply-To: <e258687eed7e156ebac3647bcf962d50.squirrel@arekh.dyndns.org>
References: <1225669132.8280.7.camel@kennedy>	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>	<20081103005409.GA9247@jadzia.bu.edu>	<490ED697.4000503@poolshark.org>
	<e258687eed7e156ebac3647bcf962d50.squirrel@arekh.dyndns.org>
Message-ID: <490F1C13.5090809@gmail.com>

Nicolas Mailhot wrote:
> 
> Le Lun 3 novembre 2008 11:46, Denis Leroy a ?crit :
> 
>> Comps evolved over time into something that doesn't make a whole bunch
>> of sense to me. Is the main use of comps still for installation groups
>> within yum and anaconda ? A lot of packages are not installation
>> "targets" but simply libraries that should only be installed by being
>> pulled in from dependency resolution. Now if we're trying to
>> "categorize" all packages nonetheless, it'd be better to have a
>> tag-based system from packagedb, where packages can be "tagged"
>> a-la-gmail, and also belong into multiple tag groups as some things
>>   really belong into multiple categories...
> 
> This tag-based system still needs to have a human-editable file
> deployment format since we do want third-party and private
> repositories to be categorised and 'just install packagedb' won't ever
> fly.
> 
> Right now this deployment format is comps.
> 
> I agree it is less than ideal, but so far no clear entity has stepped
> up to make it evolve (and any evolution would need
> anaconda/yum/packagedb/packagekit/spin-tools buy-in).
> 
+1

I think we should be storing tag information into the packagedb.  But I
think it should be used to generate static files that are used in other
tools.

I'm leaning towards the idea that there should be separate files for the
installer and general use (so that the installer isn't sprinkled with
thousands of libraries but one could still use yum to search for "all
packages that have a 'python' 'library' to do 'ssl'").

Note that this requires quite a bit of work.  The packagedb currently
operates on SRPMS-only.  It should be easy to add built packages to the
data model but the whole infrastructure of populating that data,
displaying it, etc will need to be built.  If someone would like to work
on it, I'd be very happy to help get you working with the codebase.

-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/20081103/db041c9b/attachment.sig>

From skvidal at fedoraproject.org  Mon Nov  3 15:48:47 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 3 Nov 2008 10:48:47 -0500 (EST)
Subject: FESCo Meeting Summary for 2008-10-29
In-Reply-To: <490F1C13.5090809@gmail.com>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<490ED697.4000503@poolshark.org>
	<e258687eed7e156ebac3647bcf962d50.squirrel@arekh.dyndns.org>
	<490F1C13.5090809@gmail.com>
Message-ID: <alpine.LFD.2.00.0811031046280.32547@localhost.localdomain>



On Mon, 3 Nov 2008, Toshio Kuratomi wrote:
>
> I think we should be storing tag information into the packagedb.  But I
> think it should be used to generate static files that are used in other
> tools.
>
> I'm leaning towards the idea that there should be separate files for the
> installer and general use (so that the installer isn't sprinkled with
> thousands of libraries but one could still use yum to search for "all
> packages that have a 'python' 'library' to do 'ssl'").


We can add these to the items that yum already searches from a 'yum 
search' fairly easily.


> Note that this requires quite a bit of work.  The packagedb currently
> operates on SRPMS-only.  It should be easy to add built packages to the
> data model but the whole infrastructure of populating that data,
> displaying it, etc will need to be built.  If someone would like to work
> on it, I'd be very happy to help get you working with the codebase.

The only trick I can think of is how to store this info so it is:
1. compact
2. not constantly being re-downloaded.
3. not irrationally over-tagged so you get waaaay too many matches.


-sv



From mattdm at mattdm.org  Mon Nov  3 15:54:58 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 3 Nov 2008 10:54:58 -0500
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
	2008-10-29]
In-Reply-To: <alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
Message-ID: <20081103155458.GA22752@jadzia.bu.edu>

On Mon, Nov 03, 2008 at 10:36:53AM -0500, Seth Vidal wrote:
> Let's take a step back. How do we group several thousand things such that 
> they don't make the avg user lose his/her mind to look at them.
> do we need groups of groups? A tree hierarchy the user can drill through? 
> Font-sized tags like flickr/bloggers, etc?
> I'm open to ideas, really. :)

Me too. I'm just raising the notion that we need the shed painted. :) This
time, I don't care what color it is.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From nicolas.mailhot at laposte.net  Mon Nov  3 15:56:51 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 3 Nov 2008 16:56:51 +0100 (CET)
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for 
 2008-10-29]
In-Reply-To: <alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
Message-ID: <a264be7213e6618996960dbeed6066b6.squirrel@arekh.dyndns.org>



Le Lun 3 novembre 2008 16:36, Seth Vidal a ?crit :
>
>>
>> If comps ends up with a thousand programs under Games and
>> Entertainment,
>> another thousand under Graphical Internet, etc., it's even more
>> useless than
>> having nothing in comps at all. What would be the point? On the
>> other hand,
>> having a thousand small comps groups is also no good.
>>
>
> So we're in the same boat if we start 'tagging' packages and/or if we
> just
> group them (which is essentially tagging from the other direction).
>
>
> Let's take a step back. How do we group several thousand things such
> that
> they don't make the avg user lose his/her mind to look at them.
>
> do we need groups of groups? A tree hierarchy the user can drill
> through?
> Font-sized tags like flickr/bloggers, etc?
>
> I'm open to ideas, really. :)

Also:
- Hierarchical or tag-oriented classification ?
- Relationship between classification and spins/repositories/tasks?
- Single view of available repositories or multiple simplified
(task-oriented? spin-oriented?) views?
- Should we build those views from a single classification or can we
afford to maintain different classification efforts per spin?
- How are we going to merge classification from different repositories?
- What is the classification workflow for Fedora? For
third-party/private repositories without pkgdb access?
- Do we need the comps mandatory/default/optional tristate or
something else?
- How do we scale from a three-package private repository to a
Fedora-everything repository?
- Do we need to manipulate packages? Package groups? Something else?
- Do we need multilevel inheritance? (group A is in group B which is
in group C, etc)
- What is the right file format. XML, something else?
- How can a classification file/set of files be audited for syntax
errors (preferably in automated way)
- i18n needs?
- CLI tool needs?
- GUI tools needs?

There are lots of questions. Short term just putting everything into
comps is the way to go but for mid-term to happen it should start
soonish.

Regards,

-- 
Nicolas Mailhot



From jakub at redhat.com  Mon Nov  3 15:21:10 2008
From: jakub at redhat.com (Jakub Jelinek)
Date: Mon, 3 Nov 2008 16:21:10 +0100
Subject: Semi-OT: makedepend isn't aware of
	/usr/lib/gcc/$ARCH-redhat-linux/4.3.0/include/
In-Reply-To: <91705d080811030707x5cde112dm6023227d307d4cc5@mail.gmail.com>
References: <1225720718.5355.29.camel@gilboa-work-dev.localdomain>
	<1225724678.19538.254.camel@atropine.boston.devel.redhat.com>
	<91705d080811030707x5cde112dm6023227d307d4cc5@mail.gmail.com>
Message-ID: <20081103152110.GI14706@tyan-ft48-01.lab.bos.redhat.com>

On Mon, Nov 03, 2008 at 07:07:29AM -0800, Dan Nicholson wrote:
> 2008/11/3 Adam Jackson <ajax at redhat.com>:
> > On Mon, 2008-11-03 at 15:58 +0200, Gilboa Davara wrote:
> >> I'm not sure if this is a bug or not, so I'm posting here before I open
> >> up a BZ.
> >
> > makedepend is part of the imake package in Fedora. imake is - shall we
> > say - under a policy of malign neglect by upstream.  Rightly so, in my
> > opinion, but makedepend is legitimately useful on its own.
> >
> > I think the only semi-serious problem with teaching makedepend more
> > about gcc is what to do in the face of multiple gcc versions.  We could
> > certainly make makedepend search %{_libdir}/gcc/`gcc -dumpmachine`/`gcc
> > -dumpversion`/include but that only works if you're building with gcc
> > and not say compat-gcc34.  Maybe inherit $CC from the environment and
> > use that?  Who knows.
> >
> > Ideally you'd just use gccmakedep instead, but it doesn't support the
> > same set of options as makedepend so that may not be an option.
> >
> > I'd take a patch, but that's about the extent to which I care about
> > being a build tools maintainer.
> 
> I have a patch somewhere that adds a --with-extra-include build option
> for makedepend. It still means you have to rebuild makedepend whenever
> gcc gets a major upgrade, but that was probably happening anyway. If
> that sounds useful, I'll go locate it.

If that would be just a major upgrade, it wouldn't be so bad, but
the directory changes even with gcc patchlevel changes, which happen
usually at least once during each Fedora release.

	Jakub



From skvidal at fedoraproject.org  Mon Nov  3 15:59:09 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 3 Nov 2008 10:59:09 -0500 (EST)
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <20081103155458.GA22752@jadzia.bu.edu>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<20081103155458.GA22752@jadzia.bu.edu>
Message-ID: <alpine.LFD.2.00.0811031056281.32547@localhost.localdomain>



On Mon, 3 Nov 2008, Matthew Miller wrote:

> On Mon, Nov 03, 2008 at 10:36:53AM -0500, Seth Vidal wrote:
>> Let's take a step back. How do we group several thousand things such that
>> they don't make the avg user lose his/her mind to look at them.
>> do we need groups of groups? A tree hierarchy the user can drill through?
>> Font-sized tags like flickr/bloggers, etc?
>> I'm open to ideas, really. :)
>
> Me too. I'm just raising the notion that we need the shed painted. :) This
> time, I don't care what color it is.
>

A couple of simple ideas:
  tagging a-la flickr. If we key it on pkg name, we can keep the metadata 
from changing a lot. We could do a pre-made sqlite db, for example, and 
keep querying simple.

But let's say an average of 5 tags per pkg name at 7000 pkgs ends up being 
35000 tags. Searching shouldn't be ridiculously hard and having a table 
that maps the other way tag->pkg shouldn't be too bad, either.

Toshio, any thoughts on if that's enough info?

-sv




From lesmikesell at gmail.com  Mon Nov  3 16:07:03 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 03 Nov 2008 10:07:03 -0600
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
	2008-10-29]
In-Reply-To: <alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
References: <1225669132.8280.7.camel@kennedy>	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>	<20081103005409.GA9247@jadzia.bu.edu>	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
Message-ID: <490F21A7.8030203@gmail.com>

Seth Vidal wrote:
>>
>> If comps ends up with a thousand programs under Games and Entertainment,
>> another thousand under Graphical Internet, etc., it's even more 
>> useless than
>> having nothing in comps at all. What would be the point? On the other 
>> hand,
>> having a thousand small comps groups is also no good.
>>
> 
> So we're in the same boat if we start 'tagging' packages and/or if we 
> just group them (which is essentially tagging from the other direction).
> 
> 
> Let's take a step back. How do we group several thousand things such 
> that they don't make the avg user lose his/her mind to look at them.
> 
> do we need groups of groups? A tree hierarchy the user can drill 
> through? Font-sized tags like flickr/bloggers, etc?
> 
> I'm open to ideas, really. :)

The thing I've always wanted is:

Duplicate the installed packages on this other, existing machine
with options as to whether you want the same package versions or the 
currnt versions.

And done in a way where the existing machine publishes it's list so the 
person installing just picks the example instead of wading through the 
thousands of packages every time.

Bonus points for installing from the same repositories as the original 
packages...

This could replace the concept of 'spins' with a minimal install and a 
command that says 'make it like that one' that someone with some 
expertise has configured for a similar purpose.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From a.badger at gmail.com  Mon Nov  3 16:06:00 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 03 Nov 2008 08:06:00 -0800
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
	2008-10-29]
In-Reply-To: <alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
References: <1225669132.8280.7.camel@kennedy>	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>	<20081103005409.GA9247@jadzia.bu.edu>	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
Message-ID: <490F2168.20507@gmail.com>

Seth Vidal wrote:
>>
>> If comps ends up with a thousand programs under Games and Entertainment,
>> another thousand under Graphical Internet, etc., it's even more
>> useless than
>> having nothing in comps at all. What would be the point? On the other
>> hand,
>> having a thousand small comps groups is also no good.
>>
> 
> So we're in the same boat if we start 'tagging' packages and/or if we
> just group them (which is essentially tagging from the other direction).
> 
> 
> Let's take a step back. How do we group several thousand things such
> that they don't make the avg user lose his/her mind to look at them.
> 
> do we need groups of groups? A tree hierarchy the user can drill
> through? Font-sized tags like flickr/bloggers, etc?
> 
> I'm open to ideas, really. :)
> 
When I see the group word applied to packages it's almost always a
single group per package usage.  Having multiple tags per package would
allow the user to narrow their browsing like this:

  tags: games 1000 entries - (action, strategy, cards, boardgame, rpg,
[...]).
  tags: games, strategy - 276 entries (wargame, cards, no others, rpg,
[...])
  tags: games, strategy, cards - 17 entries (no others, wargame)
  Only tags: games, strategy, card - 15 entries ()
  Browse results

font-sized tags are a good idea in this context but not applicable to
the commandline.  Ordering of the possible tags to intersect with by
popularity is an approximation of this.

A tree hierarchy has good qualities compared to the comps groups that we
have now but I think that intersecting tags have most of the advantages
of a more rigid group.

Rigid groups do have the feature of growing at a more leisurely pace
whereas tags are somewhat of a free for all where more tags are usually
better.  (May be important if we're trying to stuff all of the
catagorization information into repo metadata to download.)

-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/20081103/65bdf4ec/attachment.sig>

From skvidal at fedoraproject.org  Mon Nov  3 16:11:55 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 3 Nov 2008 11:11:55 -0500 (EST)
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <490F21A7.8030203@gmail.com>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<490F21A7.8030203@gmail.com>
Message-ID: <alpine.LFD.2.00.0811031110380.32547@localhost.localdomain>

>
> The thing I've always wanted is:
>
> Duplicate the installed packages on this other, existing machine
> with options as to whether you want the same package versions or the currnt 
> versions.
>
> And done in a way where the existing machine publishes it's list so the 
> person installing just picks the example instead of wading through the 
> thousands of packages every time.
>
> Bonus points for installing from the same repositories as the original 
> packages...
>
> This could replace the concept of 'spins' with a minimal install and a 
> command that says 'make it like that one' that someone with some expertise 
> has configured for a similar purpose.
>

That's really off-subject, though. That's something you do WITH the 
metadata, not how to format the metadata to begin with.

And the above is doable as things are now, it's just not been written.

Tag-based viewing isn't doable now.

-sv




From skvidal at fedoraproject.org  Mon Nov  3 16:14:52 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 3 Nov 2008 11:14:52 -0500 (EST)
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <490F2168.20507@gmail.com>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<490F2168.20507@gmail.com>
Message-ID: <alpine.LFD.2.00.0811031112030.32547@localhost.localdomain>



On Mon, 3 Nov 2008, Toshio Kuratomi wrote:

> When I see the group word applied to packages it's almost always a
> single group per package usage.  Having multiple tags per package would
> allow the user to narrow their browsing like this:
>
>  tags: games 1000 entries - (action, strategy, cards, boardgame, rpg,
> [...]).
>  tags: games, strategy - 276 entries (wargame, cards, no others, rpg,
> [...])
>  tags: games, strategy, cards - 17 entries (no others, wargame)
>  Only tags: games, strategy, card - 15 entries ()
>  Browse results
>
> font-sized tags are a good idea in this context but not applicable to
> the commandline.  Ordering of the possible tags to intersect with by
> popularity is an approximation of this.

>
> A tree hierarchy has good qualities compared to the comps groups that we
> have now but I think that intersecting tags have most of the advantages
> of a more rigid group.

A tree hierarchy + font/ordered tags might make sense for delving through 
all the pkgs. For example

You see a page like:

Games, Utilities, System, Mail, WebServices, Development, etc

Then you click on Games and it expands out the tags sorted or fonted by 
most common tag, etc (not including games) in that group. So you create 
implicit subgroups by going to what you want most.


That should be relatively easy to do, I think.

-sv



From mw_triad at users.sourceforge.net  Mon Nov  3 16:17:17 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Mon, 03 Nov 2008 10:17:17 -0600
Subject: Fedora  8 most popular (then 7?)
In-Reply-To: <200811031405.14260.billcrawford1970@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225532125.4119.5.camel@hp6710.axianet.ch>	<490C572B.6030406@sapience.com>
	<200811031405.14260.billcrawford1970@gmail.com>
Message-ID: <gen86d$2j6$2@ger.gmane.org>

Bill Crawford wrote:
> [ please no flamewar about kde4 - I like it but it wasn't ready to replace 3.5 
> *for me, in my working environment* yet; now, it looks like it is good enough, 
> although I've not had a chance to investigate how well it works for multiple X 
> heads, 'cause X don't work :o) ]

I've seen some complaints, but the only problem *I've* run into (I have 
three heads, btw) is that the splash screen always wants to go on the 
leftmost head where I'd prefer it on the center. Of course, I'm also 
running KDE trunk, but it's worked well for about as long as I can 
remember. (It probably helps though that all three of my screens are the 
same size; the problems I've heard seem to often involve different-sized 
screens.)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Anything that can go wrong, will go wrong. Plan accordingly.



From a.badger at gmail.com  Mon Nov  3 16:18:10 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 03 Nov 2008 08:18:10 -0800
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
	2008-10-29]
In-Reply-To: <alpine.LFD.2.00.0811031056281.32547@localhost.localdomain>
References: <1225669132.8280.7.camel@kennedy>	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>	<20081103005409.GA9247@jadzia.bu.edu>	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>	<20081103152857.GA20404@jadzia.bu.edu>	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>	<20081103155458.GA22752@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031056281.32547@localhost.localdomain>
Message-ID: <490F2442.5040104@gmail.com>

Seth Vidal wrote:
> 
> A couple of simple ideas:
>  tagging a-la flickr. If we key it on pkg name, we can keep the metadata
> from changing a lot. We could do a pre-made sqlite db, for example, and
> keep querying simple.
> 
> But let's say an average of 5 tags per pkg name at 7000 pkgs ends up
> being 35000 tags. Searching shouldn't be ridiculously hard and having a
> table that maps the other way tag->pkg shouldn't be too bad, either.
> 
> Toshio, any thoughts on if that's enough info?
> 
That should be enough to create the UI I was thinking of.

My main question would be, do we want this to be wholly separate from
comps or to integrate somehow?  If it's separate then we can implement
this and the feature is ready to go.  If it's integrated then Nicolas
Mailhot's questions become important to answer.

-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/20081103/e2695186/attachment.sig>

From skvidal at fedoraproject.org  Mon Nov  3 16:26:55 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 3 Nov 2008 11:26:55 -0500 (EST)
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <490F2442.5040104@gmail.com>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<20081103155458.GA22752@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031056281.32547@localhost.localdomain>
	<490F2442.5040104@gmail.com>
Message-ID: <alpine.LFD.2.00.0811031126050.32547@localhost.localdomain>



On Mon, 3 Nov 2008, Toshio Kuratomi wrote:

> Seth Vidal wrote:
>>
>> A couple of simple ideas:
>>  tagging a-la flickr. If we key it on pkg name, we can keep the metadata
>> from changing a lot. We could do a pre-made sqlite db, for example, and
>> keep querying simple.
>>
>> But let's say an average of 5 tags per pkg name at 7000 pkgs ends up
>> being 35000 tags. Searching shouldn't be ridiculously hard and having a
>> table that maps the other way tag->pkg shouldn't be too bad, either.
>>
>> Toshio, any thoughts on if that's enough info?
>>
> That should be enough to create the UI I was thinking of.
>
> My main question would be, do we want this to be wholly separate from
> comps or to integrate somehow?  If it's separate then we can implement
> this and the feature is ready to go.  If it's integrated then Nicolas
> Mailhot's questions become important to answer.
>

I think we do POC on its own and then figure out if:
1. it should be merged into comps
or
2. comps should be merged to it
or
3. if all group selection should be redone to match up with a tag-based 
pseudo-hierarchy.

-sv





From dwmw2 at infradead.org  Mon Nov  3 16:31:15 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 03 Nov 2008 16:31:15 +0000
Subject: Semi-OT: makedepend isn't aware of
	/usr/lib/gcc/$ARCH-redhat-linux/4.3.0/include/
In-Reply-To: <20081103152716.3fd98f45.mschwendt@gmail.com>
References: <1225720718.5355.29.camel@gilboa-work-dev.localdomain>
	<20081103152716.3fd98f45.mschwendt@gmail.com>
Message-ID: <1225729875.745.17.camel@macbook.infradead.org>

On Mon, 2008-11-03 at 15:27 +0100, Michael Schwendt wrote:
> Why not run gccmakedep instead?

Why do it in a separate pass at all? Why not just get gcc to do the
dependencies for you when you first build each object, using -MF -MD?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From notting at redhat.com  Mon Nov  3 16:34:08 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 3 Nov 2008 11:34:08 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <91705d080810311401gdc85e93i1bd182ce56976bb3@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<91705d080810290706h3c7f2a33q5dfb37f7ce55a73e@mail.gmail.com>
	<20081029215123.GL25197@nostromo.devel.redhat.com>
	<91705d080810291533o7a7f3a5dl1cbcbef4fa3498c8@mail.gmail.com>
	<20081030154405.GA12240@nostromo.devel.redhat.com>
	<91705d080810301155q487a968qc91be14ecdc6909d@mail.gmail.com>
	<20081030202920.GB31153@nostromo.devel.redhat.com>
	<91705d080810301410h415f6e4fj6fbf881eada2f69d@mail.gmail.com>
	<20081031202054.GB8150@nostromo.devel.redhat.com>
	<91705d080810311401gdc85e93i1bd182ce56976bb3@mail.gmail.com>
Message-ID: <20081103163408.GB7109@nostromo.devel.redhat.com>

Dan Nicholson (dbn.lists at gmail.com) said: 
> > There's still the issue of what to do with respect to stopping sometihng
> > on a current tty that GDM is using, if there is something there.
> 
> You mean the `telinit 3' from runlevel 5 case? I'm not following exactly.

The reverse, actually.

Bill



From katzj at redhat.com  Mon Nov  3 16:36:33 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 03 Nov 2008 11:36:33 -0500
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
Message-ID: <1225730193.25818.426.camel@aglarond.local>

On Mon, 2008-11-03 at 10:36 -0500, Seth Vidal wrote:
> Let's take a step back. How do we group several thousand things such that 
> they don't make the avg user lose his/her mind to look at them.

Also, what are the circumstances in which people are using this
metadata?  What sort of interface are they expected to be working with,
etc.  We have tons of unstructured metadata (see package summaries and
descriptions :-) 

The current comps format came about from looking at "okay, what are we
trying to enable the user to do" and then working back from there.  The
same exercise but with the changed landscape that is present today is
likely to be quite helpful in figuring out the best approach.

Jeremy



From dbn.lists at gmail.com  Mon Nov  3 16:39:15 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Mon, 3 Nov 2008 08:39:15 -0800
Subject: Semi-OT: makedepend isn't aware of
	/usr/lib/gcc/$ARCH-redhat-linux/4.3.0/include/
In-Reply-To: <1225729875.745.17.camel@macbook.infradead.org>
References: <1225720718.5355.29.camel@gilboa-work-dev.localdomain>
	<20081103152716.3fd98f45.mschwendt@gmail.com>
	<1225729875.745.17.camel@macbook.infradead.org>
Message-ID: <91705d080811030839o40817a1blbb60f11c24a6443d@mail.gmail.com>

On Mon, Nov 3, 2008 at 8:31 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Mon, 2008-11-03 at 15:27 +0100, Michael Schwendt wrote:
>> Why not run gccmakedep instead?
>
> Why do it in a separate pass at all? Why not just get gcc to do the
> dependencies for you when you first build each object, using -MF -MD?

That's a very valid argument, but I think the reason is because
existing build systems expect to do it in a separate pass. I was
working on a patch for mesa to just use gcc directly for generating
the depends, but it was kind of difficult to shoehorn it in without
breaking the build for non-gcc.

--
Dan



From lesmikesell at gmail.com  Mon Nov  3 16:40:46 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 03 Nov 2008 10:40:46 -0600
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
	2008-10-29]
In-Reply-To: <alpine.LFD.2.00.0811031110380.32547@localhost.localdomain>
References: <1225669132.8280.7.camel@kennedy>	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>	<20081103005409.GA9247@jadzia.bu.edu>	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>	<20081103152857.GA20404@jadzia.bu.edu>	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>	<490F21A7.8030203@gmail.com>
	<alpine.LFD.2.00.0811031110380.32547@localhost.localdomain>
Message-ID: <490F298E.6000008@gmail.com>

Seth Vidal wrote:
>>
>> The thing I've always wanted is:
>>
>> Duplicate the installed packages on this other, existing machine
>> with options as to whether you want the same package versions or the 
>> currnt versions.
>>
>> And done in a way where the existing machine publishes it's list so 
>> the person installing just picks the example instead of wading through 
>> the thousands of packages every time.
>>
>> Bonus points for installing from the same repositories as the original 
>> packages...
>>
>> This could replace the concept of 'spins' with a minimal install and a 
>> command that says 'make it like that one' that someone with some 
>> expertise has configured for a similar purpose.
>>
> 
> That's really off-subject, though. That's something you do WITH the 
> metadata, not how to format the metadata to begin with.
> 
> And the above is doable as things are now, it's just not been written.

Yes, it 'could' be done, except for yum knowing which repository should 
supply which package, but until someone puts a 'publish my packages' 
button somewhere it isn't going to replace spins or allow people with 
configuration expertise to guide others without.  And I don't see a 
convenient way for the recipient to make the choice between matching 
reves or not.

> Tag-based viewing isn't doable now.

Can it span repos nicely?  How many different people will be able to add 
tags to get a package included in a group where they would like to see 
it?  This isn't something that 'belongs' to the package, it is something 
that relates more or less arbitrarily to the planned use of the machine 
and needs to arbitrate among equivalent packages.  How would you tag 
something related to being a mail server, for example?  If you have to 
know the difference between postfix and sendmail you've lost any 
advantage that tags might provide.

-- 
     Les Mikesell
      lesmikesell at gmail.com





From skvidal at fedoraproject.org  Mon Nov  3 16:42:05 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 3 Nov 2008 11:42:05 -0500 (EST)
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <1225730193.25818.426.camel@aglarond.local>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<1225730193.25818.426.camel@aglarond.local>
Message-ID: <alpine.LFD.2.00.0811031139340.32547@localhost.localdomain>



On Mon, 3 Nov 2008, Jeremy Katz wrote:

> On Mon, 2008-11-03 at 10:36 -0500, Seth Vidal wrote:
>> Let's take a step back. How do we group several thousand things such that
>> they don't make the avg user lose his/her mind to look at them.
>
> Also, what are the circumstances in which people are using this
> metadata?  What sort of interface are they expected to be working with,
> etc.  We have tons of unstructured metadata (see package summaries and
> descriptions :-)
>
> The current comps format came about from looking at "okay, what are we
> trying to enable the user to do" and then working back from there.  The
> same exercise but with the changed landscape that is present today is
> likely to be quite helpful in figuring out the best approach.
>

Well, to start with I was thinking of the flickr/blogger larger-font-size 
tag browser with the ability to drill down per tag for additional info?

So combining tagging with a tree?

For example: you browse the 15 most common tags then you click on one 
which opens up the 15 most common tags at that layer? maybe? and/or a list 
of pkgs below that?

Maybe that's crazy, I'm just playing with what it might look like based on 
other interfaces I've seen.

-sv



From dbn.lists at gmail.com  Mon Nov  3 16:45:27 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Mon, 3 Nov 2008 08:45:27 -0800
Subject: Semi-OT: makedepend isn't aware of
	/usr/lib/gcc/$ARCH-redhat-linux/4.3.0/include/
In-Reply-To: <20081103152110.GI14706@tyan-ft48-01.lab.bos.redhat.com>
References: <1225720718.5355.29.camel@gilboa-work-dev.localdomain>
	<1225724678.19538.254.camel@atropine.boston.devel.redhat.com>
	<91705d080811030707x5cde112dm6023227d307d4cc5@mail.gmail.com>
	<20081103152110.GI14706@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: <91705d080811030845j6252bef0sef004140e4a585e2@mail.gmail.com>

On Mon, Nov 3, 2008 at 7:21 AM, Jakub Jelinek <jakub at redhat.com> wrote:
> On Mon, Nov 03, 2008 at 07:07:29AM -0800, Dan Nicholson wrote:
>> 2008/11/3 Adam Jackson <ajax at redhat.com>:
>> > On Mon, 2008-11-03 at 15:58 +0200, Gilboa Davara wrote:
>> >> I'm not sure if this is a bug or not, so I'm posting here before I open
>> >> up a BZ.
>> >
>> > makedepend is part of the imake package in Fedora. imake is - shall we
>> > say - under a policy of malign neglect by upstream.  Rightly so, in my
>> > opinion, but makedepend is legitimately useful on its own.
>> >
>> > I think the only semi-serious problem with teaching makedepend more
>> > about gcc is what to do in the face of multiple gcc versions.  We could
>> > certainly make makedepend search %{_libdir}/gcc/`gcc -dumpmachine`/`gcc
>> > -dumpversion`/include but that only works if you're building with gcc
>> > and not say compat-gcc34.  Maybe inherit $CC from the environment and
>> > use that?  Who knows.
>> >
>> > Ideally you'd just use gccmakedep instead, but it doesn't support the
>> > same set of options as makedepend so that may not be an option.
>> >
>> > I'd take a patch, but that's about the extent to which I care about
>> > being a build tools maintainer.
>>
>> I have a patch somewhere that adds a --with-extra-include build option
>> for makedepend. It still means you have to rebuild makedepend whenever
>> gcc gets a major upgrade, but that was probably happening anyway. If
>> that sounds useful, I'll go locate it.
>
> If that would be just a major upgrade, it wouldn't be so bad, but
> the directory changes even with gcc patchlevel changes, which happen
> usually at least once during each Fedora release.

Good point. Just for the record, this could be done today without
patching makedepend since there are already macros for handling extra
directories. This is what I was doing for my makedepend build before:

gccincdir=`${CC-gcc} -print-file-name=include`
echo "#define EXTRAINCDIR \"$gccincdir\"" >> makedepend-config.h.in

--
Dan



From notting at redhat.com  Mon Nov  3 16:46:25 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 3 Nov 2008 11:46:25 -0500
Subject: FESCo Meeting Summary for 2008-10-29
In-Reply-To: <d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
Message-ID: <20081103164625.GC7109@nostromo.devel.redhat.com>

Christopher Stone (chris.stone at gmail.com) said: 
> All packages should go in comps.  I don't know why notting is against
> this?!!?  Why should my php-pear-* packages be excluded from comps for
> example?  Just because some newb might not want to install them does
> not mean a php web developer would not use comps to install them.

It's the wrong idiom that does not scale to the size of our current
repository. If you want "Python library for doing 'foo'", any useful
package search is a far better mechanism than scrolling through a graphical
list of 650+ checkboxes.

Bill



From notting at redhat.com  Mon Nov  3 16:48:09 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 3 Nov 2008 11:48:09 -0500
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
	2008-10-29]
In-Reply-To: <a264be7213e6618996960dbeed6066b6.squirrel@arekh.dyndns.org>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<a264be7213e6618996960dbeed6066b6.squirrel@arekh.dyndns.org>
Message-ID: <20081103164809.GD7109@nostromo.devel.redhat.com>

Given...

Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> - Hierarchical or tag-oriented classification ?
> - Relationship between classification and spins/repositories/tasks?
> - Single view of available repositories or multiple simplified
> (task-oriented? spin-oriented?) views?
> - Should we build those views from a single classification or can we
> afford to maintain different classification efforts per spin?
> - How are we going to merge classification from different repositories?
> - What is the classification workflow for Fedora? For
> third-party/private repositories without pkgdb access?
> - Do we need the comps mandatory/default/optional tristate or
> something else?
> - How do we scale from a three-package private repository to a
> Fedora-everything repository?
> - Do we need to manipulate packages? Package groups? Something else?
> - Do we need multilevel inheritance? (group A is in group B which is
> in group C, etc)
> - What is the right file format. XML, something else?
> - How can a classification file/set of files be audited for syntax
> errors (preferably in automated way)
> - i18n needs?
> - CLI tool needs?
> - GUI tools needs?

...

> There are lots of questions. Short term just putting everything into
> comps is the way to go but for mid-term to happen it should start
> soonish.

I'm not sure 'we need to answer 10-15 questions before we can even
do the classification' implies 'right now we need to change it so
everything is listed.'

Bill



From skvidal at fedoraproject.org  Mon Nov  3 16:49:34 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 3 Nov 2008 11:49:34 -0500 (EST)
Subject: FESCo Meeting Summary for 2008-10-29
In-Reply-To: <20081103164625.GC7109@nostromo.devel.redhat.com>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103164625.GC7109@nostromo.devel.redhat.com>
Message-ID: <alpine.LFD.2.00.0811031147120.32547@localhost.localdomain>



On Mon, 3 Nov 2008, Bill Nottingham wrote:

> Christopher Stone (chris.stone at gmail.com) said:
>> All packages should go in comps.  I don't know why notting is against
>> this?!!?  Why should my php-pear-* packages be excluded from comps for
>> example?  Just because some newb might not want to install them does
>> not mean a php web developer would not use comps to install them.
>
> It's the wrong idiom that does not scale to the size of our current
> repository. If you want "Python library for doing 'foo'", any useful
> package search is a far better mechanism than scrolling through a graphical
> list of 650+ checkboxes.
>

To be fair - I'm not sure that's entirely true.

Keywords as a concept are harder than you might think for a lot of people. 
Especially if they have to come up with them on their own. You ever met 
someone for whom google was not useful? Those are often people who have 
trouble figuring out what are good keywords on their own. However, if they 
are presented with a list of common keywords they can pick out the ones 
they care about. I know it's odd but I've seen it occur very commonly.

Your point about browing a bunch of checkboxes is correct, though. Which 
is why I was thinking browsing trees of tags.

Maybe that doesn't work, either, though.

-sv





From dbn.lists at gmail.com  Mon Nov  3 16:52:07 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Mon, 3 Nov 2008 08:52:07 -0800
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081103163408.GB7109@nostromo.devel.redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029215123.GL25197@nostromo.devel.redhat.com>
	<91705d080810291533o7a7f3a5dl1cbcbef4fa3498c8@mail.gmail.com>
	<20081030154405.GA12240@nostromo.devel.redhat.com>
	<91705d080810301155q487a968qc91be14ecdc6909d@mail.gmail.com>
	<20081030202920.GB31153@nostromo.devel.redhat.com>
	<91705d080810301410h415f6e4fj6fbf881eada2f69d@mail.gmail.com>
	<20081031202054.GB8150@nostromo.devel.redhat.com>
	<91705d080810311401gdc85e93i1bd182ce56976bb3@mail.gmail.com>
	<20081103163408.GB7109@nostromo.devel.redhat.com>
Message-ID: <91705d080811030852v5c8a45c0lc332cc1c79572a8c@mail.gmail.com>

On Mon, Nov 3, 2008 at 8:34 AM, Bill Nottingham <notting at redhat.com> wrote:
> Dan Nicholson (dbn.lists at gmail.com) said:
>> > There's still the issue of what to do with respect to stopping sometihng
>> > on a current tty that GDM is using, if there is something there.
>>
>> You mean the `telinit 3' from runlevel 5 case? I'm not following exactly.
>
> The reverse, actually.

Well, upstart will stop prefdm when leaving runlevel 5, opening up
tty1. Then it will run event.d/tty1 after event.d/rc3 completes,
starting a getty on tty1. So, I think that's covered, but maybe I'm
missing something.

--
Dan



From bruno.matos at gmail.com  Mon Nov  3 17:21:53 2008
From: bruno.matos at gmail.com (Bruno Matos)
Date: Mon, 03 Nov 2008 17:21:53 +0000
Subject: Mono and MonoDev packages
Message-ID: <490F3331.1060100@gmail.com>

Hello,

I would like to contribute with mono and monodev packages for Fedora. I 
need a starting point please.
(I hope you are here too Paul).

Thank you,
Bruno Matos



From katzj at redhat.com  Mon Nov  3 17:24:19 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 03 Nov 2008 12:24:19 -0500
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <alpine.LFD.2.00.0811031139340.32547@localhost.localdomain>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<1225730193.25818.426.camel@aglarond.local>
	<alpine.LFD.2.00.0811031139340.32547@localhost.localdomain>
Message-ID: <1225733059.25818.431.camel@aglarond.local>

On Mon, 2008-11-03 at 11:42 -0500, Seth Vidal wrote:
> On Mon, 3 Nov 2008, Jeremy Katz wrote:
> > On Mon, 2008-11-03 at 10:36 -0500, Seth Vidal wrote:
> >> Let's take a step back. How do we group several thousand things such that
> >> they don't make the avg user lose his/her mind to look at them.
> >
> > Also, what are the circumstances in which people are using this
> > metadata?  What sort of interface are they expected to be working with,
> > etc.  We have tons of unstructured metadata (see package summaries and
> > descriptions :-)
> >
> > The current comps format came about from looking at "okay, what are we
> > trying to enable the user to do" and then working back from there.  The
> > same exercise but with the changed landscape that is present today is
> > likely to be quite helpful in figuring out the best approach.
> >
> Well, to start with I was thinking of the flickr/blogger larger-font-size 
> tag browser with the ability to drill down per tag for additional info?
> 
> So combining tagging with a tree?
> 
> For example: you browse the 15 most common tags then you click on one 
> which opens up the 15 most common tags at that layer? maybe? and/or a list 
> of pkgs below that?
> 
> Maybe that's crazy, I'm just playing with what it might look like based on 
> other interfaces I've seen.

It might make sense -- it depends on what the context is that they're
doing it in.  If I'm looking to play a certain type of game on my
installed box, yeah, I can maybe see that making sense.

But if instead I'm looking to install a system, I'm not as sure that it
does.  

And I do think that you want to have the same sort of
groupings/taggings/whatever for both cases... that or we switch to a "we
always install a large base set of stuff and then you can go in and
tweak to your heart's content".  But that suggestion tends to make
server-type people come after me with pitchforks and fire ;-)

Jeremy



From skvidal at fedoraproject.org  Mon Nov  3 17:31:41 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 3 Nov 2008 12:31:41 -0500 (EST)
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <1225733059.25818.431.camel@aglarond.local>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<1225730193.25818.426.camel@aglarond.local>
	<alpine.LFD.2.00.0811031139340.32547@localhost.localdomain>
	<1225733059.25818.431.camel@aglarond.local>
Message-ID: <alpine.LFD.2.00.0811031227560.32547@localhost.localdomain>



On Mon, 3 Nov 2008, Jeremy Katz wrote:

>
> It might make sense -- it depends on what the context is that they're
> doing it in.  If I'm looking to play a certain type of game on my
> installed box, yeah, I can maybe see that making sense.
>
> But if instead I'm looking to install a system, I'm not as sure that it
> does.

Something like this:
http://skvidal.fedorapeople.org/misc/search-browse-mockup.html



> And I do think that you want to have the same sort of
> groupings/taggings/whatever for both cases... that or we switch to a "we
> always install a large base set of stuff and then you can go in and
> tweak to your heart's content".

Which is like livecd-based-install + gui-installer later, right?

>  But that suggestion tends to make server-type people come after me with pitchforks and fire ;-)

My perspective on server-type installs has always been the same:
kickstart a minimal and %post the rest in via: yum -y install pkg1 pkg2 
pkg3. But it might just be the years of success deploying like in that way 
which makes me think that ;)

-sv



From katzj at redhat.com  Mon Nov  3 17:35:52 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 03 Nov 2008 12:35:52 -0500
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <alpine.LFD.2.00.0811031227560.32547@localhost.localdomain>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<1225730193.25818.426.camel@aglarond.local>
	<alpine.LFD.2.00.0811031139340.32547@localhost.localdomain>
	<1225733059.25818.431.camel@aglarond.local>
	<alpine.LFD.2.00.0811031227560.32547@localhost.localdomain>
Message-ID: <1225733752.25818.440.camel@aglarond.local>

On Mon, 2008-11-03 at 12:31 -0500, Seth Vidal wrote:
> On Mon, 3 Nov 2008, Jeremy Katz wrote:
> > And I do think that you want to have the same sort of
> > groupings/taggings/whatever for both cases... that or we switch to a "we
> > always install a large base set of stuff and then you can go in and
> > tweak to your heart's content".
> 
> Which is like livecd-based-install + gui-installer later, right?

Same idea.  We could do it installing actual packages, though which is
what we'd want to do for the general case

> >  But that suggestion tends to make server-type people come after me with pitchforks and fire ;-)
> 
> My perspective on server-type installs has always been the same:
> kickstart a minimal and %post the rest in via: yum -y install pkg1 pkg2 
> pkg3. But it might just be the years of success deploying like in that way 
> which makes me think that ;)

That's fine for people that have been using Linux for a long time and
something that I recommend too.  But how do you know what set of pkg1
pkg2, etc you want without those years of experience?

It's a hard problem.  And unfortunately, it's a problem that's made that
much harder by the vast amounts of choice we present to people.

Jeremy



From skvidal at fedoraproject.org  Mon Nov  3 17:43:13 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 3 Nov 2008 12:43:13 -0500 (EST)
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <1225733752.25818.440.camel@aglarond.local>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<1225730193.25818.426.camel@aglarond.local>
	<alpine.LFD.2.00.0811031139340.32547@localhost.localdomain>
	<1225733059.25818.431.camel@aglarond.local>
	<alpine.LFD.2.00.0811031227560.32547@localhost.localdomain>
	<1225733752.25818.440.camel@aglarond.local>
Message-ID: <alpine.LFD.2.00.0811031238360.32547@localhost.localdomain>



On Mon, 3 Nov 2008, Jeremy Katz wrote:

>> My perspective on server-type installs has always been the same:
>> kickstart a minimal and %post the rest in via: yum -y install pkg1 pkg2
>> pkg3. But it might just be the years of success deploying like in that way
>> which makes me think that ;)
>
> That's fine for people that have been using Linux for a long time and
> something that I recommend too.  But how do you know what set of pkg1
> pkg2, etc you want without those years of experience?
>
> It's a hard problem.  And unfortunately, it's a problem that's made that
> much harder by the vast amounts of choice we present to people.
>

Which is part of what having the same interface available online would 
solve.

I'm a server-type-person. I go to the packagedb and I look at the 'daemon' 
tag and start going down from there.

daemon->mail->MTA:
  - exim
  - postfix
  - sendmail

daemon->mail->spam:
  - amavisd-new
  - spamasssassin
  - pyzor

daemon->web:
  - httpd
  - lighttpd
  - thttpd


etc, etc.

And part of how you learn what pkgs are available is by doing arbitrary 
searches for stuff you know about and learning organically. There's not 
much we can do about the vastness of the internet other than make our 
searches and our keywording pretty good.

-sv



From lesmikesell at gmail.com  Mon Nov  3 17:52:16 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 03 Nov 2008 11:52:16 -0600
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
	2008-10-29]
In-Reply-To: <alpine.LFD.2.00.0811031227560.32547@localhost.localdomain>
References: <1225669132.8280.7.camel@kennedy>	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>	<20081103005409.GA9247@jadzia.bu.edu>	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>	<20081103152857.GA20404@jadzia.bu.edu>	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>	<1225730193.25818.426.camel@aglarond.local>	<alpine.LFD.2.00.0811031139340.32547@localhost.localdomain>	<1225733059.25818.431.camel@aglarond.local>
	<alpine.LFD.2.00.0811031227560.32547@localhost.localdomain>
Message-ID: <490F3A50.6060400@gmail.com>

Seth Vidal wrote:
> 
> 
> My perspective on server-type installs has always been the same:
> kickstart a minimal and %post the rest in via: yum -y install pkg1 pkg2 
> pkg3. But it might just be the years of success deploying like in that 
> way which makes me think that ;)

Make it so everyone else can say:
yum -y install "seth's server packages"
and everyone else can have equal success.

And it will work for desktops too, given a few experts that publish 
their lists of packages for for given purposes and preferences.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From skvidal at fedoraproject.org  Mon Nov  3 17:55:05 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 3 Nov 2008 12:55:05 -0500 (EST)
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <490F3A50.6060400@gmail.com>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<1225730193.25818.426.camel@aglarond.local>
	<alpine.LFD.2.00.0811031139340.32547@localhost.localdomain>
	<1225733059.25818.431.camel@aglarond.local>
	<alpine.LFD.2.00.0811031227560.32547@localhost.localdomain>
	<490F3A50.6060400@gmail.com>
Message-ID: <alpine.LFD.2.00.0811031254030.32547@localhost.localdomain>



On Mon, 3 Nov 2008, Les Mikesell wrote:

> Seth Vidal wrote:
>> 
>> 
>> My perspective on server-type installs has always been the same:
>> kickstart a minimal and %post the rest in via: yum -y install pkg1 pkg2 
>> pkg3. But it might just be the years of success deploying like in that way 
>> which makes me think that ;)
>
> Make it so everyone else can say:
> yum -y install "seth's server packages"
> and everyone else can have equal success.
>
> And it will work for desktops too, given a few experts that publish their 
> lists of packages for for given purposes and preferences.
>

look at yum-groups-manager

you can easily make a local, custom comps.xml right now with a list of 
groups.

then you can do:

createrepo -g that_comps.xml somedir

and you have a repository that ONLY has comps.xml in it that is then 
instantly usable by any site which can get to the baseurl where it lives.

neat, huh?

-sv



From lesmikesell at gmail.com  Mon Nov  3 18:00:19 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 03 Nov 2008 12:00:19 -0600
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
	2008-10-29]
In-Reply-To: <alpine.LFD.2.00.0811031238360.32547@localhost.localdomain>
References: <1225669132.8280.7.camel@kennedy>	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>	<20081103005409.GA9247@jadzia.bu.edu>	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>	<20081103152857.GA20404@jadzia.bu.edu>	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>	<1225730193.25818.426.camel@aglarond.local>	<alpine.LFD.2.00.0811031139340.32547@localhost.localdomain>	<1225733059.25818.431.camel@aglarond.local>	<alpine.LFD.2.00.0811031227560.32547@localhost.localdomain>	<1225733752.25818.440.camel@aglarond.local>
	<alpine.LFD.2.00.0811031238360.32547@localhost.localdomain>
Message-ID: <490F3C33.3010001@gmail.com>

Seth Vidal wrote:
> 
> And part of how you learn what pkgs are available is by doing arbitrary 
> searches for stuff you know about and learning organically. There's not 
> much we can do about the vastness of the internet other than make our 
> searches and our keywording pretty good.

That's like you sharing your knowledge of how to manage packages by 
describing how the program should work and making everyone else type it 
in from the description.  Why not give us the ability to share complete, 
working configurations in one shot?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From nicolas.mailhot at laposte.net  Mon Nov  3 18:00:39 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 03 Nov 2008 19:00:39 +0100
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <1225730193.25818.426.camel@aglarond.local>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<1225730193.25818.426.camel@aglarond.local>
Message-ID: <1225735239.10861.2.camel@arekh.okg>

Le lundi 03 novembre 2008 ? 11:36 -0500, Jeremy Katz a ?crit :
> On Mon, 2008-11-03 at 10:36 -0500, Seth Vidal wrote:
> > Let's take a step back. How do we group several thousand things such that 
> > they don't make the avg user lose his/her mind to look at them.
> 
> Also, what are the circumstances in which people are using this
> metadata?  What sort of interface are they expected to be working with,
> etc.  We have tons of unstructured metadata (see package summaries and
> descriptions :-) 

Also any sort of structured metadata will be
1. expensive to collect
2. always incomplete

The #1 problem of categorisation systems is not how to exploit metadata
but how to create and maintain it in the first place.

-- 
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/20081103/00f03ed0/attachment.sig>

From nicolas.mailhot at laposte.net  Mon Nov  3 18:03:12 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 03 Nov 2008 19:03:12 +0100
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <20081103164809.GD7109@nostromo.devel.redhat.com>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<a264be7213e6618996960dbeed6066b6.squirrel@arekh.dyndns.org>
	<20081103164809.GD7109@nostromo.devel.redhat.com>
Message-ID: <1225735392.10861.4.camel@arekh.okg>

Le lundi 03 novembre 2008 ? 11:48 -0500, Bill Nottingham a ?crit :

> > There are lots of questions. Short term just putting everything into
> > comps is the way to go but for mid-term to happen it should start
> > soonish.
> 
> I'm not sure 'we need to answer 10-15 questions before we can even
> do the classification' implies 'right now we need to change it so
> everything is listed.'

It means a non-comps solution won't happen short term, so in the
meanwhile if we want to classify things comps is the only realistic
place to do so (even if it's not perfect)

-- 
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/20081103/89e6b690/attachment.sig>

From james at fedoraproject.org  Mon Nov  3 18:03:47 2008
From: james at fedoraproject.org (James Antill)
Date: Mon, 03 Nov 2008 13:03:47 -0500
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
	2008-10-29]
In-Reply-To: <alpine.LFD.2.00.0811031227560.32547@localhost.localdomain>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<1225730193.25818.426.camel@aglarond.local>
	<alpine.LFD.2.00.0811031139340.32547@localhost.localdomain>
	<1225733059.25818.431.camel@aglarond.local>
	<alpine.LFD.2.00.0811031227560.32547@localhost.localdomain>
Message-ID: <1225735427.16415.74.camel@code.and.org>

On Mon, 2008-11-03 at 12:31 -0500, Seth Vidal wrote:
> 
> On Mon, 3 Nov 2008, Jeremy Katz wrote:
> 
> >
> > It might make sense -- it depends on what the context is that they're
> > doing it in.  If I'm looking to play a certain type of game on my
> > installed box, yeah, I can maybe see that making sense.
> >
> > But if instead I'm looking to install a system, I'm not as sure that it
> > does.
> 
> Something like this:
> http://skvidal.fedorapeople.org/misc/search-browse-mockup.html

 What makes the keywords smaller/bigger? The only way this works in
del.icio.us/etc. is that you have some kind of popularity metric, where
is that going to live and how is it going to be done? If "popularity" ==
number of packages in a group/tag ... then it'll be complete fail, IMO.

 Also how do we display this on the cmd line?

 Also, as Jeremy said, I haven't seen anyone say what they want the
"new" thing to be or do ... just that what we have kind of sucks (in
various ways). At a quick guess at that we have:

1. PK doesn't use it, by default.
2. No easy way to create custom groups for the user.
3. Not wasy way for packagers to add/remove their packages from groups.
4. "groupremove KDE" removes GNOME stuff, etc.
5. "groupinstall FOO" && "groupremove FOO" should act like a noop.
6. Groups should be able to depend on groups, so we don't duplicate
data.
7. Groups depending on groups is insane.
8. hierarchical groups (even though we only have 2 levels) "sucks" and
confuses people / is too advanced / etc.
9. non-hierarchical groups "sucks" for 10,000 - 20,000 pkgs all in at
least one group.
10. We'd like "virtual packages" to go away, and be groups/whatever ...
thus. implying 100s - 1,000s of groups.
11. More than 100 groups is unusable.

...of those 1-3 don't need a huge overhall of groups, 4-5 could probably
be fixed by fixing the data and the rest are pairs of mutually exclusive
requirements.

-- 
James Antill <james at fedoraproject.org>
Fedora



From lesmikesell at gmail.com  Mon Nov  3 18:05:56 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 03 Nov 2008 12:05:56 -0600
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
	2008-10-29]
In-Reply-To: <alpine.LFD.2.00.0811031254030.32547@localhost.localdomain>
References: <1225669132.8280.7.camel@kennedy>	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>	<20081103005409.GA9247@jadzia.bu.edu>	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>	<20081103152857.GA20404@jadzia.bu.edu>	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>	<1225730193.25818.426.camel@aglarond.local>	<alpine.LFD.2.00.0811031139340.32547@localhost.localdomain>	<1225733059.25818.431.camel@aglarond.local>	<alpine.LFD.2.00.0811031227560.32547@localhost.localdomain>	<490F3A50.6060400@gmail.com>
	<alpine.LFD.2.00.0811031254030.32547@localhost.localdomain>
Message-ID: <490F3D84.1070402@gmail.com>

Seth Vidal wrote:
> 
>> Make it so everyone else can say:
>> yum -y install "seth's server packages"
>> and everyone else can have equal success.
>>
>> And it will work for desktops too, given a few experts that publish 
>> their lists of packages for for given purposes and preferences.
>>
> 
> look at yum-groups-manager
> 
> you can easily make a local, custom comps.xml right now with a list of 
> groups.
> 
> then you can do:
> 
> createrepo -g that_comps.xml somedir
> 
> and you have a repository that ONLY has comps.xml in it that is then 
> instantly usable by any site which can get to the baseurl where it lives.
> 
> neat, huh?

That might work locally, but I don't see it happening for arbitrary 
sharing between people who have installed a system suitable for some 
purpose and those who would like to duplicate it where they have no 
other relationship.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From nicolas.mailhot at laposte.net  Mon Nov  3 18:10:41 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 03 Nov 2008 19:10:41 +0100
Subject: FESCo Meeting Summary for 2008-10-29
In-Reply-To: <e258687eed7e156ebac3647bcf962d50.squirrel@arekh.dyndns.org>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu> <490ED697.4000503@poolshark.org>
	<e258687eed7e156ebac3647bcf962d50.squirrel@arekh.dyndns.org>
Message-ID: <1225735841.10861.10.camel@arekh.okg>

Also please remember current comps format has lots of good properties:

1. it can be version controled
2. it can be diffed
3. it can be grepped
4. it can be edited with minimal tooling
5. it can be syntax-checked with minimal tooling
6. none of those tools are platform-specific
7. it scales better than the alternatives presented so far

So it's not totally bad.

-- 
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/20081103/b1cdc851/attachment.sig>

From james at fedoraproject.org  Mon Nov  3 18:12:41 2008
From: james at fedoraproject.org (James Antill)
Date: Mon, 03 Nov 2008 13:12:41 -0500
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
	2008-10-29]
In-Reply-To: <490F21A7.8030203@gmail.com>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<490F21A7.8030203@gmail.com>
Message-ID: <1225735961.16415.81.camel@code.and.org>

On Mon, 2008-11-03 at 10:07 -0600, Les Mikesell wrote:

> The thing I've always wanted is:
> 
> Duplicate the installed packages on this other, existing machine
> with options as to whether you want the same package versions or the 
> currnt versions.
> 
> And done in a way where the existing machine publishes it's list so the 
> person installing just picks the example instead of wading through the 
> thousands of packages every time.

 yum-debug-dump (and the currently unfinished yum-debug-restore) is our
attempt at this, having that output group information al. la.
yum-groups-manager shouldn't be hard. But this isn't really the same
thing as groups, IMO.

> Bonus points for installing from the same repositories as the original 
> packages...

 We need rpm to support storing that data first.

> This could replace the concept of 'spins' with a minimal install and a 
> command that says 'make it like that one' that someone with some 
> expertise has configured for a similar purpose.

 And, yeh, those kinds of tools for check-update/update/etc. are
something I'm interested in (see myum-list-updates for a very prototype
example solution). But again, I think that's a very different problem
than what groups are for atm.

-- 
James Antill <james at fedoraproject.org>
Fedora



From skvidal at fedoraproject.org  Mon Nov  3 18:12:31 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 3 Nov 2008 13:12:31 -0500 (EST)
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <1225735427.16415.74.camel@code.and.org>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<1225730193.25818.426.camel@aglarond.local>
	<alpine.LFD.2.00.0811031139340.32547@localhost.localdomain>
	<1225733059.25818.431.camel@aglarond.local>
	<alpine.LFD.2.00.0811031227560.32547@localhost.localdomain>
	<1225735427.16415.74.camel@code.and.org>
Message-ID: <alpine.LFD.2.00.0811031306400.32547@localhost.localdomain>



On Mon, 3 Nov 2008, James Antill wrote:

>
> What makes the keywords smaller/bigger? The only way this works in
> del.icio.us/etc. is that you have some kind of popularity metric, where
> is that going to live and how is it going to be done? If "popularity" ==
> number of packages in a group/tag ... then it'll be complete fail, IMO.

Smaller/bigger based on how often the tag appears in any given package. 
Look at how it is done in flickr. That's the gist of it.

>
> Also how do we display this on the cmd line?

Either:

1. we don't.
or
2. sorted most common first and have a cutoff limit on it.


> Also, as Jeremy said, I haven't seen anyone say what they want the
> "new" thing to be or do ... just that what we have kind of sucks (in
> various ways). At a quick guess at that we have:
>
> 1. PK doesn't use it, by default.

- that's not a technical problem afaict.

> 2. No easy way to create custom groups for the user.

- that's unrelated to this classification, though.

> 3. Not wasy way for packagers to add/remove their packages from groups.

- which is the point of tying this metadata into the pkgdb interface and 
having it dump out a static file. Then the packager can add keywords 
through the pkgdb

> 4. "groupremove KDE" removes GNOME stuff, etc.

- not really related to search/browse enhancement via keyword.

> 5. "groupinstall FOO" && "groupremove FOO" should act like a noop.

- also not really related


> 6. Groups should be able to depend on groups, so we don't duplicate
> data.
> 7. Groups depending on groups is insane.

- groupreq is doable in current infrastructure. Figuring out how to make 
that behave with installs/removes is ugly, of course.

> 8. hierarchical groups (even though we only have 2 levels) "sucks" and
> confuses people / is too advanced / etc.

- but tag browsing (which can ultimately be hierarchical doesn't seem to 
boggle too many folks. See Flickr - seriously.

> 9. non-hierarchical groups "sucks" for 10,000 - 20,000 pkgs all in at
> least one group.

- see above

> 11. More than 100 groups is unusable.

Which is what tags/popular tags is about.


Categorizing thousands of items is pain. Period. Figuring out a way to 
make it semi-sanely browseable might not be AS excruciating.

-sv



From laxathom at fedoraproject.org  Mon Nov  3 18:23:05 2008
From: laxathom at fedoraproject.org (Xavier Lamien)
Date: Mon, 3 Nov 2008 19:23:05 +0100
Subject: RPM Fusion is now Available
Message-ID: <62bc09df0811031023k11c9b381j12099cf1aec516fa@mail.gmail.com>

The RPM Fusion team is proud to announce the public availability of
our repositories that provide software which the Fedora project cannot
provide as easy-to-install RPM packages.



== What applications can be found in the RPM Fusion repositories ==

The RPM Fusion project provides a variety of different applications:


=== Sound and Video / Multimedia applications ===

We have all that is needed to play all kinds of media files, such as
MP3 or unencrypted DVDs
and ship additional multimedia applications such as MPlayer, VLC and Xine.


=== Kernel Drivers ===

We offer the ATI and Nvidia closed-source drivers in a
Fedora-compatible RPM package
for users whose video cards are not yet fully supported with the stock
open source drivers.


=== Games ===

We offer couple of games such as:
* Bub's Brothers
* Secret Maryo Chronicles
* UFO: Alien Invasion
* W?rms of Prey, xrick
* GLtron
* and lot others !


=== Emulators ===

We offer emulators for most retro platform:

* VICE for Commodore 64 and other vintage Commodore 8 bit computers
* E-UAE for Amiga
* Nestopia and FCEUltra for NES
* ZSNES and Snes9x for Super NES
* and many many others!


== More Information ==

RPM Fusion provides packages for all Fedora releases that are
supported by Fedora project, which includes the development branch
"rawhide".

We have two separate repository lines:

 * "free" for Open Source Software (as defined by the Fedora Licensing
Guidelines) which the Fedora project cannot ship
 * "nonfree" for redistributable software that is not Open Source
Software (as defined by the Fedora Licensing Guidelines); this
includes software with publicly available source-code that has "no
commercial use"-like restrictions

Please read our wiki page about how to enable these repositories:
http://rpmfusion.org/Configuration

RPM Fusion is a project started by the Dribble, Freshrpms and Livna
teams. It aims to bring together many packagers from various 3rd party
repositories and build a single add-on repository for Fedora and Red
Hat Enterprise Linux. We hope to attract new Fedora packagers and hope
that other 3rd party repositories will join us.

Are you interested? Do you want to help? Don't hesitate and subscribe
to our mailing lists at http://lists.rpmfusion.org or meet us in the
#rpmfusion channel on freenode.

==== Do you find problems? ====

 Fill bugs at https://bugzilla.rpmfusion.org/


=== A note for Livna users ===

All users that installed Livna properly (e.g. by installing the
livna-release package) will get RPM Fusion free and nonfree
repositories enabled automatically. All packages in Livna that are
superseded by packages from RPM Fusion will soon be removed from the
Livna repositories.




== Final notes ==

Thanks for you interest in RPM Fusion.


--
The RPM Fusion Team (http://rpmfusion.org)



From notting at redhat.com  Mon Nov  3 18:26:31 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 3 Nov 2008 13:26:31 -0500
Subject: FESCo Meeting Summary for 2008-10-29
In-Reply-To: <alpine.LFD.2.00.0811031147120.32547@localhost.localdomain>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103164625.GC7109@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811031147120.32547@localhost.localdomain>
Message-ID: <20081103182631.GE7109@nostromo.devel.redhat.com>

Seth Vidal (skvidal at fedoraproject.org) said: 
> Keywords as a concept are harder than you might think for a lot of 
> people. Especially if they have to come up with them on their own. You 
> ever met someone for whom google was not useful? Those are often people 
> who have trouble figuring out what are good keywords on their own. 
> However, if they are presented with a list of common keywords they can 
> pick out the ones they care about. I know it's odd but I've seen it occur 
> very commonly.

Yes, but which audience are we talking about? The one that wants to find
a billiards game, or the one that wants to find PHP bindings for FTP
support? It's possible that these two audiences have a similar searching/
keywording skill level, but I'm not sure it's likely.

(Which goes back, again, to who and what are we creating this data for.)

Bill



From lesmikesell at gmail.com  Mon Nov  3 18:30:53 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 03 Nov 2008 12:30:53 -0600
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary
	for	2008-10-29]
In-Reply-To: <1225735961.16415.81.camel@code.and.org>
References: <1225669132.8280.7.camel@kennedy>	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>	<20081103005409.GA9247@jadzia.bu.edu>	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>	<20081103152857.GA20404@jadzia.bu.edu>	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>	<490F21A7.8030203@gmail.com>
	<1225735961.16415.81.camel@code.and.org>
Message-ID: <490F435D.3020105@gmail.com>

James Antill wrote:
>
>  And, yeh, those kinds of tools for check-update/update/etc. are
> something I'm interested in (see myum-list-updates for a very prototype
> example solution). But again, I think that's a very different problem
> than what groups are for atm.

Categorizing things into groups barely makes sense when about 90% of the 
packages are general-purpose tools.

What are groups for anyway?  Things that have to be installed together 
should be pulled by dependencies.  Things that one person thinks might 
belong in one group might not make any sense there to someone else.

Where do you put things like the bazillion perl modules?  Are they 
grouped by their purpose where one is obvious?  Or do you need to know 
you are using perl to get one?  If you start tagging things for every 
purpose it could possibly have, you are going to make browsing 
categories worse than just wading through the whole package list.

-- 
   Les Mikesell
    lesmikesell at gmail.com




From skvidal at fedoraproject.org  Mon Nov  3 18:30:52 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 3 Nov 2008 13:30:52 -0500 (EST)
Subject: FESCo Meeting Summary for 2008-10-29
In-Reply-To: <20081103182631.GE7109@nostromo.devel.redhat.com>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103164625.GC7109@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811031147120.32547@localhost.localdomain>
	<20081103182631.GE7109@nostromo.devel.redhat.com>
Message-ID: <alpine.LFD.2.00.0811031328480.32547@localhost.localdomain>



On Mon, 3 Nov 2008, Bill Nottingham wrote:

> Seth Vidal (skvidal at fedoraproject.org) said:
>> Keywords as a concept are harder than you might think for a lot of
>> people. Especially if they have to come up with them on their own. You
>> ever met someone for whom google was not useful? Those are often people
>> who have trouble figuring out what are good keywords on their own.
>> However, if they are presented with a list of common keywords they can
>> pick out the ones they care about. I know it's odd but I've seen it occur
>> very commonly.
>
> Yes, but which audience are we talking about? The one that wants to find
> a billiards game, or the one that wants to find PHP bindings for FTP
> support? It's possible that these two audiences have a similar searching/
> keywording skill level, but I'm not sure it's likely.
>
> (Which goes back, again, to who and what are we creating this data for.)
>

Which is why the interface isn't all-or-nothing.

If you know the search terms you want to find then type in:

php ftp

then you get back more or less what 'yum search php ftp' gives you:

============================== Matched: ftp, php ========================
php-pear-Net-FTP.noarch : Provides an OO interface to the PHP FTP
                         : functions plus some additions
....


But in both cases additional tags will help you find that information and, 
of course, to find where the intersections are.

-sv




From notting at redhat.com  Mon Nov  3 18:31:53 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 3 Nov 2008 13:31:53 -0500
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
	2008-10-29]
In-Reply-To: <1225735392.10861.4.camel@arekh.okg>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<a264be7213e6618996960dbeed6066b6.squirrel@arekh.dyndns.org>
	<20081103164809.GD7109@nostromo.devel.redhat.com>
	<1225735392.10861.4.camel@arekh.okg>
Message-ID: <20081103183153.GF7109@nostromo.devel.redhat.com>

> It means a non-comps solution won't happen short term, so in the
> meanwhile if we want to classify things comps is the only realistic
> place to do so (even if it's not perfect)

But what does a classification with every single package gain you?
(Including libraries?) What's the usage case?

Right now, we use comps as:

- An input to a graphical package selector

  Adding everything here is likely to make large portions of the UI
  unusable. 

- An input to tree composition tools

  Adding everything here, as long as it's all 'optional', is likely
  to have less effect.

<insert other things that comps is used for here>

Bill



From nicolas.mailhot at laposte.net  Mon Nov  3 18:41:38 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 03 Nov 2008 19:41:38 +0100
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <20081103183153.GF7109@nostromo.devel.redhat.com>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<a264be7213e6618996960dbeed6066b6.squirrel@arekh.dyndns.org>
	<20081103164809.GD7109@nostromo.devel.redhat.com>
	<1225735392.10861.4.camel@arekh.okg>
	<20081103183153.GF7109@nostromo.devel.redhat.com>
Message-ID: <1225737698.11768.3.camel@arekh.okg>

Le lundi 03 novembre 2008 ? 13:31 -0500, Bill Nottingham a ?crit :
> > It means a non-comps solution won't happen short term, so in the
> > meanwhile if we want to classify things comps is the only realistic
> > place to do so (even if it's not perfect)
> 
> But what does a classification with every single package gain you?
> (Including libraries?) What's the usage case?

The use case is checking we've actually exposed all the packages we
intended to users. Even a mega "libs" ghetto group no one but the sanity
checker tools parsed would get you that.

-- 
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/20081103/2cdc8ac9/attachment.sig>

From jkeating at redhat.com  Mon Nov  3 19:07:19 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 03 Nov 2008 11:07:19 -0800
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <1225737698.11768.3.camel@arekh.okg>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<a264be7213e6618996960dbeed6066b6.squirrel@arekh.dyndns.org>
	<20081103164809.GD7109@nostromo.devel.redhat.com>
	<1225735392.10861.4.camel@arekh.okg>
	<20081103183153.GF7109@nostromo.devel.redhat.com>
	<1225737698.11768.3.camel@arekh.okg>
Message-ID: <1225739239.24018.0.camel@luminos.localdomain>

On Mon, 2008-11-03 at 19:41 +0100, Nicolas Mailhot wrote:
> The use case is checking we've actually exposed all the packages we
> intended to users. Even a mega "libs" ghetto group no one but the sanity
> checker tools parsed would get you that.


If the packages are in the metadata, they're exposed to the user by the
various search frontends we have to the metadata.  I really really don't
understand what flooding comps will accomplish.

-- 
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/20081103/2ed223ef/attachment.sig>

From nicolas.mailhot at laposte.net  Mon Nov  3 18:45:41 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 03 Nov 2008 19:45:41 +0100
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <1225735392.10861.4.camel@arekh.okg>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<a264be7213e6618996960dbeed6066b6.squirrel@arekh.dyndns.org>
	<20081103164809.GD7109@nostromo.devel.redhat.com>
	<1225735392.10861.4.camel@arekh.okg>
Message-ID: <1225737941.12092.3.camel@arekh.okg>

BTW I'd like for the people that advocate extracting keywords or keyword
priority from summaries/descriptions to explain how it's supposed to
work in an i18n/l10n world.

-- 
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/20081103/c10c0e3f/attachment.sig>

From hhoffman at ip-solutions.net  Mon Nov  3 19:24:52 2008
From: hhoffman at ip-solutions.net (Harry Hoffman)
Date: Mon, 03 Nov 2008 14:24:52 -0500
Subject: iscsi lvm and /dev and bootup
Message-ID: <1225740292.4024.21.camel@n1-14-96.dhcp.drexel.edu>

Hi,

I'm stuck here...

I've got iscsi running here with two drives on a lefthand networks iscsi
box.

I'm able to successfully login and can see the targets.

I'm using lvm to create physical volumes:
pvcreate external_iscsi /dev/sdb /dev/sdc


I then create a logical volume:
lvcreate -l 1310718 external_iscsi -n srv

and finally create a filesystem:
mkfs.ext3 -m 1 /dev/external_iscsi/srv

All of this works well and I can mount the filesystem just fine.

When I reboot it all goes to hell. I see iscsi logging into the lefthand
box and it reports success.

and if I run vgdisplay I get:
 vgdisplay external_iscsi
  --- Volume group ---
  VG Name               external_iscsi
  System ID             
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               0
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               5.00 TB
  PE Size               4.00 MB
  Total PE              1310718
  Alloc PE / Size       1310718 / 5.00 TB
  Free  PE / Size       0 / 0   
  VG UUID               vLGcVU-cAj0-Z7Ox-EcYF-bx5e-fMWs-9wGh3t


however, there's no /dev/ entry for /dev/external_iscsi

Can someone tell me what I'm missing?

Cheers,
Harry





From rvinyard at cs.nmsu.edu  Mon Nov  3 19:28:30 2008
From: rvinyard at cs.nmsu.edu (rvinyard at cs.nmsu.edu)
Date: Mon, 3 Nov 2008 12:28:30 -0700 (MST)
Subject: bit License Change
Message-ID: <36166.155.148.81.31.1225740510.squirrel@intranet.cs.nmsu.edu>

FYI bit-0.4.90 changed the license to GPLv3 from LGPLv2.

This shouldn't cause any problems since nothing depends on bit.



From skvidal at fedoraproject.org  Mon Nov  3 19:12:33 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 3 Nov 2008 14:12:33 -0500 (EST)
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <1225737941.12092.3.camel@arekh.okg>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<a264be7213e6618996960dbeed6066b6.squirrel@arekh.dyndns.org>
	<20081103164809.GD7109@nostromo.devel.redhat.com>
	<1225735392.10861.4.camel@arekh.okg>
	<1225737941.12092.3.camel@arekh.okg>
Message-ID: <alpine.LFD.2.00.0811031410460.32547@localhost.localdomain>



On Mon, 3 Nov 2008, Nicolas Mailhot wrote:

> BTW I'd like for the people that advocate extracting keywords or keyword
> priority from summaries/descriptions to explain how it's supposed to
> work in an i18n/l10n world.
>

This is why we don't extract them from summaries/descriptions. You have 
a keyword file per language. For empty language files you get the 
american-english ones to search against, more or less like you have now.

-sv



From nicolas.mailhot at laposte.net  Mon Nov  3 19:39:38 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 03 Nov 2008 20:39:38 +0100
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <1225739239.24018.0.camel@luminos.localdomain>
References: <1225669132.8280.7.camel@kennedy>
	<d9c612bf0811021613u7adf3bf9x6447aa6f9641d7f@mail.gmail.com>
	<20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<a264be7213e6618996960dbeed6066b6.squirrel@arekh.dyndns.org>
	<20081103164809.GD7109@nostromo.devel.redhat.com>
	<1225735392.10861.4.camel@arekh.okg>
	<20081103183153.GF7109@nostromo.devel.redhat.com>
	<1225737698.11768.3.camel@arekh.okg>
	<1225739239.24018.0.camel@luminos.localdomain>
Message-ID: <1225741178.17171.2.camel@arekh.okg>

Le lundi 03 novembre 2008 ? 11:07 -0800, Jesse Keating a ?crit :
> On Mon, 2008-11-03 at 19:41 +0100, Nicolas Mailhot wrote:
> > The use case is checking we've actually exposed all the packages we
> > intended to users. Even a mega "libs" ghetto group no one but the sanity
> > checker tools parsed would get you that.
> 
> 
> If the packages are in the metadata, they're exposed to the user by the
> various search frontends we have to the metadata.  I really really don't
> understand what flooding comps will accomplish.

How do you check without involving humans that every new package has
been categorized (or not) as it should?

It's all fine and dandy to say "some packages do not need this" but
that's not a criterium automatons can verify and if it can't be
auto-QAed it will rot.

-- 
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/20081103/5071a8f0/attachment.sig>

From notting at redhat.com  Mon Nov  3 19:46:12 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 3 Nov 2008 14:46:12 -0500
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
	2008-10-29]
In-Reply-To: <1225737698.11768.3.camel@arekh.okg>
References: <20081103005409.GA9247@jadzia.bu.edu>
	<d9c612bf0811021700x307bc70fnaf4abd63238c2f6c@mail.gmail.com>
	<alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<a264be7213e6618996960dbeed6066b6.squirrel@arekh.dyndns.org>
	<20081103164809.GD7109@nostromo.devel.redhat.com>
	<1225735392.10861.4.camel@arekh.okg>
	<20081103183153.GF7109@nostromo.devel.redhat.com>
	<1225737698.11768.3.camel@arekh.okg>
Message-ID: <20081103194612.GA10703@nostromo.devel.redhat.com>

Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> > But what does a classification with every single package gain you?
> > (Including libraries?) What's the usage case?
> 
> The use case is checking we've actually exposed all the packages we
> intended to users.

And I'll make the statment that I certainly don't intend to expose the
libs group to users, as it makes no sense.

Bill



From notting at redhat.com  Mon Nov  3 19:47:12 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 3 Nov 2008 14:47:12 -0500
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
	2008-10-29]
In-Reply-To: <1225741178.17171.2.camel@arekh.okg>
References: <alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<a264be7213e6618996960dbeed6066b6.squirrel@arekh.dyndns.org>
	<20081103164809.GD7109@nostromo.devel.redhat.com>
	<1225735392.10861.4.camel@arekh.okg>
	<20081103183153.GF7109@nostromo.devel.redhat.com>
	<1225737698.11768.3.camel@arekh.okg>
	<1225739239.24018.0.camel@luminos.localdomain>
	<1225741178.17171.2.camel@arekh.okg>
Message-ID: <20081103194712.GB10703@nostromo.devel.redhat.com>

Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> How do you check without involving humans that every new package has
> been categorized (or not) as it should?

That's solving a different problem the wrong way, which certainly
seems better suited to a bit in the review request, or packagedb, etc.

Bill



From kevin.kofler at chello.at  Mon Nov  3 19:58:12 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 03 Nov 2008 20:58:12 +0100
Subject: Fedora  8 most popular (then 7?)
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225532125.4119.5.camel@hp6710.axianet.ch>
	<490C572B.6030406@sapience.com>
	<200811031405.14260.billcrawford1970@gmail.com>
Message-ID: <genl4k$gbd$1@ger.gmane.org>

Bill Crawford wrote:
> Well, I don't think I've submitted smolt stats for this machine, but it
> still runs F8 for two reasons:
> 
> 1. KDE4 just wasn't ready for me to use here for work. Fun to play with at
> home, but I couldn't imagine using it here without some workflow changes.
> The latest versions I've seen in Rawhide would be pretty much usable at
> work now, BUT ...
> 
> 2. I can't use the latest snapshots or Rawhide on my system here because X
> (and the boot sequence unless I use "nomodeset nofb? on the kernel command
> line) explodes, the OOPSes have gone to kerneloops.org, but the problem
> is, there is no support for soft-booting secondary video cards and I have
> three (all PCI) in this machine. Which helps me find bugs in xscreensaver
> ;o)
> 
> So, I simply cannot upgrade it at the moment.

Try F9 + updates then, you get the exact same KDE (4.1.2 with the same
patches) (except that kdepim, Digikam and Amarok are KDE 3 versions, you
can get the KDE 4 versions rebuilt for F9 from kde-redhat unstable if you
really want them, but if you want something rock solid you'll want the KDE
3 versions of those anyway), without the assorted breakage elsewhere.
(Hopefully that stuff will get sorted out soon in an update for F10.)

        Kevin Kofler



From jspaleta at gmail.com  Mon Nov  3 20:39:34 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 3 Nov 2008 11:39:34 -0900
Subject: Fedora 8 most popular (then 7?)
In-Reply-To: <604aa7910811012027u195fbbd2qba7bdd197bb1a825@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>
	<4908F6A1.4020509@fedoraproject.org>
	<alpine.LRH.2.00.0810292308280.7694@arj.bjyevire.pbz>
	<4909AE5F.6070606@fedoraproject.org>
	<2335.71.208.51.222.1225511368.squirrel@www.cora.nwra.com>
	<gei9ce$jq6$1@ger.gmane.org> <490CADA5.2040509@fedoraproject.org>
	<geima1$lfi$1@ger.gmane.org>
	<604aa7910811012027u195fbbd2qba7bdd197bb1a825@mail.gmail.com>
Message-ID: <604aa7910811031239q711bfaf2uc47851b3a3d3cc2b@mail.gmail.com>

On Sat, Nov 1, 2008 at 6:27 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Sat, Nov 1, 2008 at 2:47 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
>> ... but unfortunately all the actual maps there give me 404s, is something
>> wrong with the map generation process?
>
> It's being worked on... some of the maps were up last week.  Its one
> of the last casualties of the infrastructure rebuild.

Looks like they are up today.

-jef



From orion at cora.nwra.com  Mon Nov  3 20:55:26 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Mon, 03 Nov 2008 13:55:26 -0700
Subject: Detecting binaries in rpmbuild
Message-ID: <490F653E.7010508@cora.nwra.com>

I just discovered in a package I'm putting through review that the 
upstream tar ball contains some pre-compiled binaries.  It seems like 
this would be a good check for rpmbuild to run automatically before the 
%build step.  Thoughts?

-- 
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 nicolas.mailhot at laposte.net  Mon Nov  3 23:46:39 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 04 Nov 2008 00:46:39 +0100
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <20081103194712.GB10703@nostromo.devel.redhat.com>
References: <alpine.LFD.2.00.0811022226300.4297@localhost.localdomain>
	<20081103152857.GA20404@jadzia.bu.edu>
	<alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<a264be7213e6618996960dbeed6066b6.squirrel@arekh.dyndns.org>
	<20081103164809.GD7109@nostromo.devel.redhat.com>
	<1225735392.10861.4.camel@arekh.okg>
	<20081103183153.GF7109@nostromo.devel.redhat.com>
	<1225737698.11768.3.camel@arekh.okg>
	<1225739239.24018.0.camel@luminos.localdomain>
	<1225741178.17171.2.camel@arekh.okg>
	<20081103194712.GB10703@nostromo.devel.redhat.com>
Message-ID: <1225755999.3530.3.camel@arekh.okg>

Le lundi 03 novembre 2008 ? 14:47 -0500, Bill Nottingham a ?crit :
> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> > How do you check without involving humans that every new package has
> > been categorized (or not) as it should?
> 
> That's solving a different problem the wrong way, which certainly
> seems better suited to a bit in the review request, or packagedb, etc.

The target is to automate review requests as much as possible not pile
up new manual checks. I don't ask this just for fun. I ask this because
I happen to do comps QA for my SIG every few months and manual checks
are not fun at all.

Not declaring everything is only fine when you don't care about checking
the result.

-- 
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/20081104/7d65b52c/attachment.sig>

From jkeating at redhat.com  Tue Nov  4 00:38:04 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 03 Nov 2008 16:38:04 -0800
Subject: CVS mass-branching coming soon
Message-ID: <1225759084.24018.9.camel@luminos.localdomain>

On Thursday of this week we will be mass branching CVS for F-10.  I
realize that this is a bit late, however it is the earliest we are
comfortable doing it given changes in pkgdb to facilitate the branching.

There will be an outage of CVS during the actual branching due to
disabling email delivery of cvs changes during the branching.  We don't
want any changes sneaking in during that time.  This outage is scheduled
to begin at 0300 UTC Friday Nov 7th.

Unfortunately we do not have a good estimate as to how long the outage
will last, however it should be much much quicker than previous outages
for mass branching.

If any plans change before now and then we will announce them, as well
as announce a reminder just prior to the outage.

Any questions can be asked on fedora-devel-list or #fedora-admin on
Freenode IRC.

-- 
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/20081103/19c03151/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 sxzzsf at sohu.com  Tue Nov  4 02:14:32 2008
From: sxzzsf at sohu.com (sfzhou)
Date: Tue, 4 Nov 2008 10:14:32 +0800
Subject: Is it possible to add an option to anaconda to not load some module
Message-ID: <DreamMail__101432_93712418211@smtp.sohu.com>

Hi,
On openSUSE, I can add brokenmodules=some_module to the boot option to not load some_module,
is it possible for Fedora?



From jim at rossberry.com  Tue Nov  4 02:41:48 2008
From: jim at rossberry.com (Jim Wildman)
Date: Mon, 3 Nov 2008 21:41:48 -0500 (EST)
Subject: iscsi lvm and /dev and bootup
In-Reply-To: <1225740292.4024.21.camel@n1-14-96.dhcp.drexel.edu>
References: <1225740292.4024.21.camel@n1-14-96.dhcp.drexel.edu>
Message-ID: <alpine.LRH.2.00.0811032140560.31159@jim.rossberry.private>

On Mon, 3 Nov 2008, Harry Hoffman wrote:

> I'm using lvm to create physical volumes:
> pvcreate external_iscsi /dev/sdb /dev/sdc

You need to use the /dev/mapper entries since the /dev/sd? are not
guaranteed to be permanent across reboots (which device is the first
one??)

----------------------------------------------------------------------
Jim Wildman, CISSP, RHCE       jim at rossberry.com http://www.rossberry.com
"Society in every state is a blessing, but Government, even in its best
state, is a necessary evil; in its worst state, an intolerable one."
Thomas Paine



From loganjerry at gmail.com  Tue Nov  4 03:45:29 2008
From: loganjerry at gmail.com (Jerry James)
Date: Mon, 3 Nov 2008 20:45:29 -0700
Subject: Orphaning GCL
In-Reply-To: <1225663861.4906.15.camel@localhost.localdomain>
References: <1225663861.4906.15.camel@localhost.localdomain>
Message-ID: <870180fe0811031945l662a8c6ak87d58c9485e54e8b@mail.gmail.com>

On Sun, Nov 2, 2008 at 3:11 PM, G?rard Milmeister <gemi at bluewin.ch> wrote:
> Hi,
>
> I am orphaning GCL (GNU Common Lisp):
> https://admin.fedoraproject.org/pkgdb/packages/name/gcl
>
> I cannot get it to build on any platform anymore and have
> not been successful in gathering support. I hope somebody
> else will have more success.
>
> gemi
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

I'm interested in taking it.  It looks like Camm Maguire is the Debian
maintainer.  He's got a massive patch for Debian, which appears to
address at least some of the problems we are having in Fedora.  I
tried an initial build, but ran into a rather strange problem.  Try to
compile this:

int main() {
#include <unistd.h>
  return 0;
}

I can compile it with -O.  I can compile it with -D_FORTIFY_SOURCE.
But I cannot compile it with -O -D_FORTIFY_SOURCE.  GCC spews a whole
bunch of errors about formerly extern functions now declared as
static.  Is that a glibc header bug?  It is preventing GCL's sbrk
randomization code from compiling.

If we can get that worked out, I would like to take GCL.
-- 
Jerry James
http://loganjerry.googlepages.com/



From james at fedoraproject.org  Tue Nov  4 05:29:17 2008
From: james at fedoraproject.org (James Antill)
Date: Tue, 04 Nov 2008 00:29:17 -0500
Subject: Strange ext3 problem
In-Reply-To: <5f6f8c5f0811010646y7ec677avaca913e0e07d50bb@mail.gmail.com>
References: <5f6f8c5f0810311525s4a1ddd31y49527359340190b6@mail.gmail.com>
	<m31vxwqrh6.fsf@ursa.amorsen.dk>
	<5f6f8c5f0811010158n47085a3eu5a5b87c58e9377b5@mail.gmail.com>
	<5f6f8c5f0811010329r509680c1n684ed46ddb2af190@mail.gmail.com>
	<m34p2rk55m.fsf@ursa.amorsen.dk>
	<5f6f8c5f0811010646y7ec677avaca913e0e07d50bb@mail.gmail.com>
Message-ID: <1225776557.16415.82.camel@code.and.org>

On Sat, 2008-11-01 at 14:46 +0100, Joshua C. wrote:

> What I expect is that the i686 detects about 3GB of free memory (not
> the whole 4GB). according to different forums linux (and windows x86)
> x86 should be able to detect up to 3,2GB of free memory (the limit of
> 32bits). but my fedora 9 i686 sees only 2,25gb (which is away from the
> 3GB). Windowsxp sees exactly the same amount of memory.
> So either i got a crapy mashine or the forums are wrong.

 Check your motherboard firmware revision, I've seen bugs where certain
firemware will limit what the software can see.

-- 
James Antill <james at fedoraproject.org>
Fedora



From poelstra at redhat.com  Tue Nov  4 05:31:20 2008
From: poelstra at redhat.com (John Poelstra)
Date: Mon, 03 Nov 2008 21:31:20 -0800
Subject: Fedora Release Engineering Meeting Recap 2008-11-03 
Message-ID: <490FDE28.7040704@redhat.com>

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

Please make corrections and clarifications to the wiki page.

== Preview Release ==
* on track for release on tomorrow (Tuesday)
* schedule CVS outage for Thursday evening in order to mass-branch for F-10
* have some really bad split media splitting going on
** needing more than one disc for a minimal install
** needing 5 disks for a default minus office install, etc.
** f13 to look at where packages are going and why they aren't being 
split right

== Fedora 11 Schedule ==
* https://fedorahosted.org/rel-eng/ticket/843 (discussion to date)
** Includes three proposals
* attendees would like to see a different proposed scenario to compare 
to a regular "may day" schedule
*# ''May Day'' schedule should GA on 2009-05-05 (not 2009-04-28)
*# second scenario should be F10 GA date + six month schedule 
(2009-05-05 + ~30 days)

== IRC Transcript ==



From fedora at leemhuis.info  Tue Nov  4 07:59:00 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 04 Nov 2008 08:59:00 +0100
Subject: Fedora Release Engineering Meeting Recap 2008-11-03
In-Reply-To: <490FDE28.7040704@redhat.com>
References: <490FDE28.7040704@redhat.com>
Message-ID: <491000C4.3060802@leemhuis.info>

On 04.11.2008 06:31, John Poelstra wrote:
 > [...]
> == Fedora 11 Schedule ==
> * https://fedorahosted.org/rel-eng/ticket/843 (discussion to date)
> ** Includes three proposals
> * attendees would like to see a different proposed scenario to compare 
> to a regular "may day" schedule
> *# ''May Day'' schedule should GA on 2009-05-05 (not 2009-04-28)
> *# second scenario should be F10 GA date + six month schedule 
> (2009-05-05 + ~30 days)

12 to 18 months ago the Board IIRC decided to *always* target late 
April/early May and late October/early November for the releases. IOW: 
we got rid of the GA + six months schedule we had for some time. Why is 
the idea coming back? Was the board involved?

CU
knurd



From sundaram at fedoraproject.org  Tue Nov  4 08:03:35 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 04 Nov 2008 13:33:35 +0530
Subject: Fedora Release Engineering Meeting Recap 2008-11-03
In-Reply-To: <491000C4.3060802@leemhuis.info>
References: <490FDE28.7040704@redhat.com> <491000C4.3060802@leemhuis.info>
Message-ID: <491001D7.3060608@fedoraproject.org>

Thorsten Leemhuis wrote:
> On 04.11.2008 06:31, John Poelstra wrote:
>  > [...]
>> == Fedora 11 Schedule ==
>> * https://fedorahosted.org/rel-eng/ticket/843 (discussion to date)
>> ** Includes three proposals
>> * attendees would like to see a different proposed scenario to compare 
>> to a regular "may day" schedule
>> *# ''May Day'' schedule should GA on 2009-05-05 (not 2009-04-28)
>> *# second scenario should be F10 GA date + six month schedule 
>> (2009-05-05 + ~30 days)
> 
> 12 to 18 months ago the Board IIRC decided to *always* target late 
> April/early May and late October/early November for the releases. IOW: 
> we got rid of the GA + six months schedule we had for some time. Why is 
> the idea coming back? Was the board involved?

Reading the ticket suggests that this issue is already been discussed 
within the ticket. It would be better to continue within there to keep 
the ideas together. Note: the rel-eng proposal is a draft.

Rahul



From musuruan at gmail.com  Tue Nov  4 08:28:19 2008
From: musuruan at gmail.com (Andrea Musuruane)
Date: Tue, 4 Nov 2008 09:28:19 +0100
Subject: Mono and MonoDev packages
In-Reply-To: <490F3331.1060100@gmail.com>
References: <490F3331.1060100@gmail.com>
Message-ID: <29fee02b0811040028j5ed5b928h105ddbc38fc2a65c@mail.gmail.com>

2008/11/3 Bruno Matos <bruno.matos at gmail.com>:
> I would like to contribute with mono and monodev packages for Fedora. I need
> a starting point please.

Try these:
https://fedoraproject.org/wiki/PackageMaintainers
https://fedoraproject.org/wiki/Packaging/Mono

I hope this answer your question.

Bye,

Andrea.



From pbrobinson at gmail.com  Tue Nov  4 09:28:43 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Tue, 4 Nov 2008 09:28:43 +0000
Subject: Mono and MonoDev packages
In-Reply-To: <29fee02b0811040028j5ed5b928h105ddbc38fc2a65c@mail.gmail.com>
References: <490F3331.1060100@gmail.com>
	<29fee02b0811040028j5ed5b928h105ddbc38fc2a65c@mail.gmail.com>
Message-ID: <5256d0b0811040128x57751439te3f6bb89e0e2fe6e@mail.gmail.com>

>> I would like to contribute with mono and monodev packages for Fedora. I need
>> a starting point please.
>
> Try these:
> https://fedoraproject.org/wiki/PackageMaintainers
> https://fedoraproject.org/wiki/Packaging/Mono

There's also the Mono SIG here
https://fedoraproject.org/wiki/SIGs/Mono

Peter



From joost at cnoc.nl  Tue Nov  4 09:53:33 2008
From: joost at cnoc.nl (Joost van der Sluis)
Date: Tue, 04 Nov 2008 10:53:33 +0100
Subject: Detecting binaries in rpmbuild
In-Reply-To: <490F653E.7010508@cora.nwra.com>
References: <490F653E.7010508@cora.nwra.com>
Message-ID: <1225792413.31158.0.camel@wsjoost>

Op maandag 03-11-2008 om 13:55 uur [tijdzone -0700], schreef Orion
Poplawski:
> I just discovered in a package I'm putting through review that the 
> upstream tar ball contains some pre-compiled binaries.  It seems like 
> this would be a good check for rpmbuild to run automatically before
> the 
> %build step.  Thoughts? 

That would kill some packages. Like all compilers that have to bootstrap
theirselves. 

Joost



From debarshi.ray at gmail.com  Tue Nov  4 10:10:50 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Tue, 4 Nov 2008 15:40:50 +0530
Subject: Detecting binaries in rpmbuild
In-Reply-To: <490F653E.7010508@cora.nwra.com>
References: <490F653E.7010508@cora.nwra.com>
Message-ID: <3170f42f0811040210g7e6ac2b1s994f6202165f9e38@mail.gmail.com>

> I just discovered in a package I'm putting through review that the upstream
> tar ball contains some pre-compiled binaries.  It seems like this would be a
> good check for rpmbuild to run automatically before the %build step.
>  Thoughts?

Is it not better to do it in RPMLint with appropriate exceptions?

Cheerio,
Debarshi



From breeves at redhat.com  Tue Nov  4 10:10:48 2008
From: breeves at redhat.com (Bryn M. Reeves)
Date: Tue, 04 Nov 2008 10:10:48 +0000
Subject: iscsi lvm and /dev and bootup
In-Reply-To: <1225740292.4024.21.camel@n1-14-96.dhcp.drexel.edu>
References: <1225740292.4024.21.camel@n1-14-96.dhcp.drexel.edu>
Message-ID: <49101FA8.4070301@redhat.com>

Harry Hoffman wrote:
> All of this works well and I can mount the filesystem just fine.
> 
> When I reboot it all goes to hell. I see iscsi logging into the lefthand
> box and it reports success.
> 
> and if I run vgdisplay I get:
>  vgdisplay external_iscsi
>   --- Volume group ---
>   VG Name               external_iscsi
>   System ID             
[snip]
> 
> however, there's no /dev/ entry for /dev/external_iscsi

Sounds like your VG has not been activated by your distribution's init
sripts. Run "vgchange -ay external_iscsi" and the VG should be activated
and made accessible, creating the entries in /dev. There's no need to
use the /dev/mapper/$vg-$lv entries - for LVM2 devices, the /dev/$vg/$lv
symlinks are guaranteed to be persistent.

What distro are you using here? Some perform a vgchange -ay from the
iscsi initialisation script (Fedora and RHEL both do this). If that's
not the case for your distribution then you might need to either add the
command to the script yourself, or make sure that if the distribution
provides an "lvm" initscript, that it's set to start later than the
iscsi script.

Assuming this is Fedora, it might be that it's taking a long time for 
the login to the storage to complete, and we're "missing" the VG when 
the vgchange in the iscsi script runs - I don't see a call to udevsettle 
in the script which would sync up with the new device discovery.

Regards,
Bryn.




From limb at jcomserv.net  Tue Nov  4 10:38:04 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Tue, 4 Nov 2008 04:38:04 -0600 (CST)
Subject: Detecting binaries in rpmbuild
In-Reply-To: <490F653E.7010508@cora.nwra.com>
References: <490F653E.7010508@cora.nwra.com>
Message-ID: <60405f92f97dd91d9432c26832de3174.squirrel@mail.chuzibooks.com>


> I just discovered in a package I'm putting through review that the
> upstream tar ball contains some pre-compiled binaries.  It seems like
> this would be a good check for rpmbuild to run automatically before the
> %build step.  Thoughts?

Fine, as long as it doesn't prevent building rpms from precompiled
binaries.  I mean, other than compilers, we really shouldn't do it in
Fedora, but taking away that functionality would prevent companies
building some rpms for internal use.  I agree that rpmlint sounds like a
great place for this.

> --
> Orion Poplawski
> Technical Manager                     303-415-9701 x222
> NWRA/CoRA Division                    FAX: 303-415-9702
> 3380 Mitchell Lane                  orion at cora.nwra.com
> Boulder, CO 80301              http://www.cora.nwra.com
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From aph at redhat.com  Tue Nov  4 10:42:32 2008
From: aph at redhat.com (Andrew Haley)
Date: Tue, 04 Nov 2008 10:42:32 +0000
Subject: Detecting binaries in rpmbuild
In-Reply-To: <60405f92f97dd91d9432c26832de3174.squirrel@mail.chuzibooks.com>
References: <490F653E.7010508@cora.nwra.com>
	<60405f92f97dd91d9432c26832de3174.squirrel@mail.chuzibooks.com>
Message-ID: <49102718.8050308@redhat.com>

Jon Ciesla wrote:
>> I just discovered in a package I'm putting through review that the
>> upstream tar ball contains some pre-compiled binaries.  It seems like
>> this would be a good check for rpmbuild to run automatically before the
>> %build step.  Thoughts?
> 
> Fine, as long as it doesn't prevent building rpms from precompiled
> binaries.  I mean, other than compilers, we really shouldn't do it in
> Fedora, but taking away that functionality would prevent companies
> building some rpms for internal use.  I agree that rpmlint sounds like a
> great place for this.

Hold on, how do you know that something is a "binary" ?  What if, for
example, it's an image bitmap?  In the general case it's not possible
to tell if something is source or binary.

Andrew.



From jos at xos.nl  Tue Nov  4 10:48:56 2008
From: jos at xos.nl (Jos Vos)
Date: Tue, 4 Nov 2008 11:48:56 +0100
Subject: Detecting binaries in rpmbuild
In-Reply-To: <49102718.8050308@redhat.com>
References: <490F653E.7010508@cora.nwra.com>
	<60405f92f97dd91d9432c26832de3174.squirrel@mail.chuzibooks.com>
	<49102718.8050308@redhat.com>
Message-ID: <20081104104856.GB6115@jasmine.xos.nl>

On Tue, Nov 04, 2008 at 10:42:32AM +0000, Andrew Haley wrote:

> Hold on, how do you know that something is a "binary" ?  What if, for
> example, it's an image bitmap?  In the general case it's not possible
> to tell if something is source or binary.

Well, you could run "file" on it to see if it can recognize it as an
object file.  But, like some of the other commentors, I see (too?)
many caveats showing up when actually implementing this idea.

-- 
--    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  Tue Nov  4 10:51:11 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 4 Nov 2008 11:51:11 +0100
Subject: Detecting binaries in rpmbuild
In-Reply-To: <49102718.8050308@redhat.com>
References: <490F653E.7010508@cora.nwra.com>
	<60405f92f97dd91d9432c26832de3174.squirrel@mail.chuzibooks.com>
	<49102718.8050308@redhat.com>
Message-ID: <20081104105110.GE3264@free.fr>

On Tue, Nov 04, 2008 at 10:42:32AM +0000, Andrew Haley wrote:
> 
> Hold on, how do you know that something is a "binary" ?  What if, for
> example, it's an image bitmap?  In the general case it's not possible
> to tell if something is source or binary.

At least ELF files could be found out.

--
Pat



From dominik at greysector.net  Tue Nov  4 10:53:46 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Tue, 4 Nov 2008 11:53:46 +0100
Subject: Detecting binaries in rpmbuild
In-Reply-To: <20081104105110.GE3264@free.fr>
References: <490F653E.7010508@cora.nwra.com>
	<60405f92f97dd91d9432c26832de3174.squirrel@mail.chuzibooks.com>
	<49102718.8050308@redhat.com> <20081104105110.GE3264@free.fr>
Message-ID: <20081104105345.GD17684@mokona.greysector.net>

On Tuesday, 04 November 2008 at 11:51, Patrice Dumas wrote:
> On Tue, Nov 04, 2008 at 10:42:32AM +0000, Andrew Haley wrote:
> > 
> > Hold on, how do you know that something is a "binary" ?  What if, for
> > example, it's an image bitmap?  In the general case it's not possible
> > to tell if something is source or binary.
> 
> At least ELF files could be found out.

So could Windows binaries (executables, DLLs, C# blobs) and Java JARs.

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 opensource at till.name  Tue Nov  4 10:57:22 2008
From: opensource at till.name (Till Maas)
Date: Tue, 04 Nov 2008 11:57:22 +0100
Subject: Detecting binaries in rpmbuild
In-Reply-To: <60405f92f97dd91d9432c26832de3174.squirrel@mail.chuzibooks.com>
References: <490F653E.7010508@cora.nwra.com>
	<60405f92f97dd91d9432c26832de3174.squirrel@mail.chuzibooks.com>
Message-ID: <200811041157.40547.opensource@till.name>

On Tue November 4 2008, Jon Ciesla wrote:
> > I just discovered in a package I'm putting through review that the
> > upstream tar ball contains some pre-compiled binaries.  It seems like
> > this would be a good check for rpmbuild to run automatically before the
> > %build step.  Thoughts?
>
> Fine, as long as it doesn't prevent building rpms from precompiled
> binaries.  I mean, other than compilers, we really shouldn't do it in
> Fedora, but taking away that functionality would prevent companies
> building some rpms for internal use.  I agree that rpmlint sounds like a
> great place for this.

I would more prefer if this was included via an extension in rpbuild, e.g. 
like there is a way to enable rpath checking. Also wrt. to rpmlint, how 
should this work in rpmlint? Should it run a rpmbuild -bp and then examine 
the build directory? It is afaik absolutely valid to have binaries in the 
tarball that is included in the srpm and remove them in %prep.

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/20081104/045e8b2a/attachment.sig>

From pertusus at free.fr  Tue Nov  4 10:59:07 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 4 Nov 2008 11:59:07 +0100
Subject: Detecting binaries in rpmbuild
In-Reply-To: <20081104105345.GD17684@mokona.greysector.net>
References: <490F653E.7010508@cora.nwra.com>
	<60405f92f97dd91d9432c26832de3174.squirrel@mail.chuzibooks.com>
	<49102718.8050308@redhat.com> <20081104105110.GE3264@free.fr>
	<20081104105345.GD17684@mokona.greysector.net>
Message-ID: <20081104105907.GF3264@free.fr>

On Tue, Nov 04, 2008 at 11:53:46AM +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Tuesday, 04 November 2008 at 11:51, Patrice Dumas wrote:
> > On Tue, Nov 04, 2008 at 10:42:32AM +0000, Andrew Haley wrote:
> > > 
> > > Hold on, how do you know that something is a "binary" ?  What if, for
> > > example, it's an image bitmap?  In the general case it's not possible
> > > to tell if something is source or binary.
> > 
> > At least ELF files could be found out.
> 
> So could Windows binaries (executables, DLLs, C# blobs) and Java JARs.

File isn't very good at detecting java code, and it only see jar as Zip
archive, and .class file as data. But using the extension + the fact
that it is a zip archive may be a safe bet.

--
Pat



From aph at redhat.com  Tue Nov  4 11:03:28 2008
From: aph at redhat.com (Andrew Haley)
Date: Tue, 04 Nov 2008 11:03:28 +0000
Subject: Detecting binaries in rpmbuild
In-Reply-To: <20081104105907.GF3264@free.fr>
References: <490F653E.7010508@cora.nwra.com>	<60405f92f97dd91d9432c26832de3174.squirrel@mail.chuzibooks.com>	<49102718.8050308@redhat.com>
	<20081104105110.GE3264@free.fr>	<20081104105345.GD17684@mokona.greysector.net>
	<20081104105907.GF3264@free.fr>
Message-ID: <49102C00.1040708@redhat.com>

Patrice Dumas wrote:
> On Tue, Nov 04, 2008 at 11:53:46AM +0100, Dominik 'Rathann' Mierzejewski wrote:
>> On Tuesday, 04 November 2008 at 11:51, Patrice Dumas wrote:
>>> On Tue, Nov 04, 2008 at 10:42:32AM +0000, Andrew Haley wrote:
>>>> Hold on, how do you know that something is a "binary" ?  What if, for
>>>> example, it's an image bitmap?  In the general case it's not possible
>>>> to tell if something is source or binary.
>>> At least ELF files could be found out.
>> So could Windows binaries (executables, DLLs, C# blobs) and Java JARs.
> 
> File isn't very good at detecting java code, and it only see jar as Zip
> archive, and .class file as data. But using the extension + the fact
> that it is a zip archive may be a safe bet.

The fact that it's a JAR doesn't tell you it has any precompiled code in
it: some JARs don't.  By all means do this for ELF, but let's be sensible.

Andrew.



From rawhide at fedoraproject.org  Tue Nov  4 11:20:49 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Tue,  4 Nov 2008 11:20:49 +0000 (UTC)
Subject: rawhide report: 20081104 changes
Message-ID: <20081104112049.832A01F8255@releng2.fedora.phx.redhat.com>

Compose started at Tue Nov  4 06:01:09 UTC 2008

Updated Packages:

autofs-5.0.3-30
---------------
* Sun Nov  2 17:00:00 2008 Ian Kent <kent at redhat.com> - 5.0.3-30
- fix segv during library re-open.
- fix incorrect pthreads condition handling for expire requests.
- fix master map lexer eval order.
- fix bad alloca usage.


cluster-2.99.12-1.fc10
----------------------
* Mon Nov  3 17:00:00 2008 Fabio M. Di Nitto <fdinitto at redhat.com> - 2.99.12-1
- new upstream release.
  Fix several security related issues.


coreutils-6.12-17.fc10
----------------------
* Mon Nov  3 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> - 6.12-17
- Requires: ncurses (#469277)


enscript-1.6.4-11.fc10
----------------------
* Mon Nov  3 17:00:00 2008 Adam Tkac <atkac redhat com> 1.6.4-11
- fixed various buffer overflows (CVE-2008-3863, CVE-2008-4306)


gimp-2.6.2-1.fc10
-----------------
* Fri Oct 31 18:00:00 2008 Nils Philippsen <nils at redhat.com> - 2:2.6.2-1
- version 2.6.2
- update xdg-open patch

  Overview of Changes from GIMP 2.6.1 to GIMP 2.6.2
  =================================================

  * Bugs fixed:

   557950 ??? Scaling in Gimp 2.6 is much slower than in Gimp 2.4
   558215 ??? unit and zoom entries in Statusbar not visible
   558451 ??? Cannot build GIMP using Sun CC on Solaris 2.8
   558420 ??? projection incorrect with alpha-less layers
   556603 ??? Zoom region always zooms in center of image
   557870 ??? "Qmask" message popping up here and there
   557705 ??? compatibility with GEGL > 0.0.20
   556248 ??? Scaling gives 'jagged' edges
   556804 ??? Zoom drop down doesn't update
   524615 ??? Print not to scale
   555246 ??? gimp crashes when a file is opened while a preview is generating
   556741 ??? Alpha layer automatically added (in psd format)
   556182 ??? Could you please explain a few strings [I18N]
   555697 ??? build fails if configured with --without-libjpeg
   134956 ??? Curves tool doesn't save free curves

  * Updated translations:

   Czech (cs)
   Danish (da)
   Finnish (fi)
   French (fr)
   Japanese (ja)
   Polish (pl)
   Brazilian Portuguese (pt_BR)
   Swedish (sv)
   Simplified Chinese (zh_CN)

* Tue Oct 28 18:00:00 2008 Nils Philippsen <nils at redhat.com> - 2:2.6.1-2
- update required versions of some packages (#467065)


gnome-power-manager-2.24.1-3.fc10
---------------------------------
* Fri Oct 31 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.24.1-3
- Make "Make default" button work


groff-1.18.1.4-16.fc10
----------------------
* Sun Oct 19 18:00:00 2008 Robert Scheck <robert at fedoraproject.org> - 1.18.1.14-16
- Fixed wrong symlinking of man pages into %{_bindir} after simplifying


kdepimlibs-4.1.2-4.fc10
-----------------------
* Sat Nov  1 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.2-4
- turn off system libical for now, crashes KOrganizer (#469228)


sectool-0.9.1-3
---------------
* Mon Nov  3 17:00:00 2008 Peter Vrabec <pvrabec at redhat.com> - 0.9.1-3
- fix getValueFromH() (#469368)
- fix GUI: set REFRESH, DEBUG, LEVEL


system-config-date-1.9.33-1.fc10
--------------------------------
* Thu Oct 30 18:00:00 2008 Nils Philippsen <nils at redhat.com> - 1.9.33-1
- require usermode-gtk instead of usermode


Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 10









Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot





From jwboyer at gmail.com  Tue Nov  4 12:20:30 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Tue, 4 Nov 2008 07:20:30 -0500
Subject: Fedora Release Engineering Meeting Recap 2008-11-03
In-Reply-To: <491001D7.3060608@fedoraproject.org>
References: <490FDE28.7040704@redhat.com> <491000C4.3060802@leemhuis.info>
	<491001D7.3060608@fedoraproject.org>
Message-ID: <20081104122030.GA17680@yoda.jdub.homelinux.org>

On Tue, Nov 04, 2008 at 01:33:35PM +0530, Rahul Sundaram wrote:
> Thorsten Leemhuis wrote:
>> On 04.11.2008 06:31, John Poelstra wrote:
>>  > [...]
>>> == Fedora 11 Schedule ==
>>> * https://fedorahosted.org/rel-eng/ticket/843 (discussion to date)
>>> ** Includes three proposals
>>> * attendees would like to see a different proposed scenario to 
>>> compare to a regular "may day" schedule
>>> *# ''May Day'' schedule should GA on 2009-05-05 (not 2009-04-28)
>>> *# second scenario should be F10 GA date + six month schedule  
>>> (2009-05-05 + ~30 days)
>>
>> 12 to 18 months ago the Board IIRC decided to *always* target late  
>> April/early May and late October/early November for the releases. IOW:  
>> we got rid of the GA + six months schedule we had for some time. Why is 
>> the idea coming back? Was the board involved?
>
> Reading the ticket suggests that this issue is already been discussed  
> within the ticket. It would be better to continue within there to keep  
> the ideas together. Note: the rel-eng proposal is a draft.


Wait.  rel-eng opened the ticket to have a place to discuss it internally.
They wanted to come to a cohesive proposal before sending it to f-a-b or
-devel.  So while you can certainly comment the ticket if you want, they do
plan on sending this to the lists at some point.  It might be a bit easier
to do discussion on that list instead.

josh



From dominik at greysector.net  Tue Nov  4 12:28:55 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Tue, 4 Nov 2008 13:28:55 +0100
Subject: breaking rawhide freeze
Message-ID: <20081104122854.GE17684@mokona.greysector.net>

You know, I'm somewhat disappointed in the uneven treatment of packagers here.
A couple of days ago, I wanted to break the freeze and push an update to gnomeradio
that would make the application fully usable again (as it is now, it crashes
every time you try to name a radio station), but I was told (by Jesse himself,
and some other nice folks) to wait until after F-10 is released, because it
wasn't "critical enough". And now I'm reading the recent rawhide changelogs
and seeing non-critical changes being committed, mostly by people @redhat.com.
I don't want to draw any far-fetched conclusions, but I wonder what's going on
here. Why was I actively discouraged from pushing my change, which would have
zero side-effects but would have made gnomeradio in vanilla F-10 fully functional?

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 jeff at ocjtech.us  Tue Nov  4 12:47:38 2008
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Tue, 4 Nov 2008 06:47:38 -0600
Subject: breaking rawhide freeze
In-Reply-To: <20081104122854.GE17684@mokona.greysector.net>
References: <20081104122854.GE17684@mokona.greysector.net>
Message-ID: <935ead450811040447w7a52c303y45a1bb5b121e59a9@mail.gmail.com>

On Tue, Nov 4, 2008 at 6:28 AM, Dominik 'Rathann' Mierzejewski
<dominik at greysector.net> wrote:
> You know, I'm somewhat disappointed in the uneven treatment of packagers here.
> A couple of days ago, I wanted to break the freeze and push an update to gnomeradio
> that would make the application fully usable again (as it is now, it crashes
> every time you try to name a radio station), but I was told (by Jesse himself,
> and some other nice folks) to wait until after F-10 is released, because it
> wasn't "critical enough". And now I'm reading the recent rawhide changelogs
> and seeing non-critical changes being committed, mostly by people @redhat.com.
> I don't want to draw any far-fetched conclusions, but I wonder what's going on
> here. Why was I actively discouraged from pushing my change, which would have
> zero side-effects but would have made gnomeradio in vanilla F-10 fully functional?

>From what I saw in today's (2008/11/04) rawhide report all of the
packages that got updated had some commonalities:

1) Would be in one of the "official" Live images, and therefore
difficult/impossible to update once F10 was released.
2) Security fixes.
3) Very popular apps.

>From what I saw GIMP only fit in category 3, but I think you'd have to
agree that GIMP is a much more widely used app than gnomeradio.

-- 
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 gilboad at gmail.com  Tue Nov  4 12:59:24 2008
From: gilboad at gmail.com (Gilboa Davara)
Date: Tue, 04 Nov 2008 14:59:24 +0200
Subject: Semi-OT: makedepend isn't aware of
	/usr/lib/gcc/$ARCH-redhat-linux/4.3.0/include/
In-Reply-To: <1225729875.745.17.camel@macbook.infradead.org>
References: <1225720718.5355.29.camel@gilboa-work-dev.localdomain>
	<20081103152716.3fd98f45.mschwendt@gmail.com>
	<1225729875.745.17.camel@macbook.infradead.org>
Message-ID: <1225803564.19382.16.camel@gilboa-work-dev.localdomain>

On Mon, 2008-11-03 at 16:31 +0000, David Woodhouse wrote:
> On Mon, 2008-11-03 at 15:27 +0100, Michael Schwendt wrote:
> > Why not run gccmakedep instead?
> 
> Why do it in a separate pass at all? Why not just get gcc to do the
> dependencies for you when you first build each object, using -MF -MD?
> 
> -- 

A. I rather not modify the existing build system.
B. I use makedepend & make duo on platforms that use proprietary
compilers. (E.g. cl.exe under Windows.)

- Gilboa



From bmr at redhat.com  Tue Nov  4 13:44:15 2008
From: bmr at redhat.com (Bryn M. Reeves)
Date: Tue, 04 Nov 2008 13:44:15 +0000
Subject: iscsi lvm and /dev and bootup
In-Reply-To: <49101FA8.4070301@redhat.com>
References: <1225740292.4024.21.camel@n1-14-96.dhcp.drexel.edu>
	<49101FA8.4070301@redhat.com>
Message-ID: <491051AF.8080601@redhat.com>

Bryn M. Reeves wrote:
> Sounds like your VG has not been activated by your distribution's init
> sripts. Run "vgchange -ay external_iscsi" and the VG should be activated
> and made accessible, creating the entries in /dev. There's no need to
> use the /dev/mapper/$vg-$lv entries - for LVM2 devices, the /dev/$vg/$lv
> symlinks are guaranteed to be persistent.
> 
> What distro are you using here? Some perform a vgchange -ay from the
> iscsi initialisation script (Fedora and RHEL both do this). If that's

Actually, I'm wrong - for Fedora/RHEL/CentOS the vgchange is done from 
the netfs script rather than directly from the iscsi script, but only in 
the case that at least one entry in /etc/fstab or /etc/mtab has the 
"_netdev" option present.

RHEL/CentOS up to 5.2 have a bug in this script that may cause devices 
to be misssed due to not syncing up with udev - see:

     https://bugzilla.redhat.com/show_bug.cgi?id=452866

Looking on my f9 boxes, this bug still appears to be present in Fedora, 
will clone the BZ for rawhide if it's still there too.

Regards,
Bryn.



From jkeating at redhat.com  Tue Nov  4 13:55:29 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 04 Nov 2008 05:55:29 -0800
Subject: Fedora Release Engineering Meeting Recap 2008-11-03
In-Reply-To: <20081104122030.GA17680@yoda.jdub.homelinux.org>
References: <490FDE28.7040704@redhat.com> <491000C4.3060802@leemhuis.info>
	<491001D7.3060608@fedoraproject.org>
	<20081104122030.GA17680@yoda.jdub.homelinux.org>
Message-ID: <1225806929.24018.13.camel@luminos.localdomain>

On Tue, 2008-11-04 at 07:20 -0500, Josh Boyer wrote:
> On Tue, Nov 04, 2008 at 01:33:35PM +0530, Rahul Sundaram wrote:
> > Thorsten Leemhuis wrote:
> >> On 04.11.2008 06:31, John Poelstra wrote:
> >>  > [...]
> >>> == Fedora 11 Schedule ==
> >>> * https://fedorahosted.org/rel-eng/ticket/843 (discussion to date)
> >>> ** Includes three proposals
> >>> * attendees would like to see a different proposed scenario to 
> >>> compare to a regular "may day" schedule
> >>> *# ''May Day'' schedule should GA on 2009-05-05 (not 2009-04-28)
> >>> *# second scenario should be F10 GA date + six month schedule  
> >>> (2009-05-05 + ~30 days)
> >>
> >> 12 to 18 months ago the Board IIRC decided to *always* target late  
> >> April/early May and late October/early November for the releases. IOW:  
> >> we got rid of the GA + six months schedule we had for some time. Why is 
> >> the idea coming back? Was the board involved?
> >
> > Reading the ticket suggests that this issue is already been discussed  
> > within the ticket. It would be better to continue within there to keep  
> > the ideas together. Note: the rel-eng proposal is a draft.
> 
> 
> Wait.  rel-eng opened the ticket to have a place to discuss it internally.
> They wanted to come to a cohesive proposal before sending it to f-a-b or
> -devel.  So while you can certainly comment the ticket if you want, they do
> plan on sending this to the lists at some point.  It might be a bit easier
> to do discussion on that list instead.
> 
> josh
> 

Josh is correct.  Releng has taken some input from various parties and
feels that there is sufficient reason to break tradition with the F11
schedule.  However, given the significance of such a break this needs to
get a full vetting in the public space, and I'll be starting a thread on
Fedora Advisory Board shortly to start that discussion.  The rel-eng
discussion up to date has been exploring what the different scenarios
would lead to in a schedule as well as some other adjustments such as as
staggered freezes.

Releng has not the power nor the desire to make this decision on it's
own.

-- 
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/20081104/1cb539a0/attachment.sig>

From jkeating at redhat.com  Tue Nov  4 14:10:16 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 04 Nov 2008 06:10:16 -0800
Subject: breaking rawhide freeze
In-Reply-To: <20081104122854.GE17684@mokona.greysector.net>
References: <20081104122854.GE17684@mokona.greysector.net>
Message-ID: <1225807816.24018.15.camel@luminos.localdomain>

On Tue, 2008-11-04 at 13:28 +0100, Dominik 'Rathann' Mierzejewski wrote:
> A couple of days ago, I wanted to break the freeze and push an update to gnomeradio
> that would make the application fully usable again (as it is now, it crashes
> every time you try to name a radio station), but I was told (by Jesse himself,
> and some other nice folks) to wait until after F-10 is released, because it
> wasn't "critical enough".

Can you refresh my memory of the conversation, was it email, irc, or a
releng ticket?  I'm pretty sure we would have said after Preview release
but still in before final.  About the only tag requests we've turned
down are untested things, and brand new 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/20081104/6e8c0d66/attachment.sig>

From notting at redhat.com  Tue Nov  4 13:58:01 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 4 Nov 2008 08:58:01 -0500
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
	2008-10-29]
In-Reply-To: <1225755999.3530.3.camel@arekh.okg>
References: <alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<a264be7213e6618996960dbeed6066b6.squirrel@arekh.dyndns.org>
	<20081103164809.GD7109@nostromo.devel.redhat.com>
	<1225735392.10861.4.camel@arekh.okg>
	<20081103183153.GF7109@nostromo.devel.redhat.com>
	<1225737698.11768.3.camel@arekh.okg>
	<1225739239.24018.0.camel@luminos.localdomain>
	<1225741178.17171.2.camel@arekh.okg>
	<20081103194712.GB10703@nostromo.devel.redhat.com>
	<1225755999.3530.3.camel@arekh.okg>
Message-ID: <20081104135801.GB20827@nostromo.devel.redhat.com>

Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> > That's solving a different problem the wrong way, which certainly
> > seems better suited to a bit in the review request, or packagedb, etc.
> 
> The target is to automate review requests as much as possible not pile
> up new manual checks. I don't ask this just for fun. I ask this because
> I happen to do comps QA for my SIG every few months and manual checks
> are not fun at all.

How is packagedb or bugzilla not automatable? We have programmatic interfaces
to both.

All I'm saying is that changing the user-visible behavior in order
to implement a specific QA method for comps is putting the cart
before the horse.

Bill



From notting at redhat.com  Tue Nov  4 13:59:14 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 4 Nov 2008 08:59:14 -0500
Subject: Is it possible to add an option to anaconda to not load some
	module
In-Reply-To: <DreamMail__101432_93712418211@smtp.sohu.com>
References: <DreamMail__101432_93712418211@smtp.sohu.com>
Message-ID: <20081104135914.GC20827@nostromo.devel.redhat.com>

sfzhou (sxzzsf at sohu.com) said: 
> On openSUSE, I can add brokenmodules=some_module to the boot option to not load some_module,
> is it possible for Fedora?

blacklist=<foo> (for Fedora 9 and later)

Bill



From jkeating at redhat.com  Tue Nov  4 15:09:30 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 04 Nov 2008 07:09:30 -0800
Subject: Cambridge (F-10) Preview Release announcement
Message-ID: <1225811370.24018.22.camel@luminos.localdomain>

We've been cooking, and now it's time for a final taste test!

The Fedora Project is proud to announce the availability of the Fedora
10 Preview Release. The Fedora 10 Preview Release is our last
pre-release offering before we let everyone taste the goods for real.

https://fedoraproject.org/get-prerelease

Doesn't it smell yummy? We know you can't resist, and we don't want you
to. We want everyone in the Fedora community to take an early sample and
tell us what you find. The recipe is pretty good, but now is the time to
make it perfect. Ingredients include:

      * Faster boot using Plymouth
      * Wireless connection sharing
      * Better printing
      * Enhanced software update and maintenance, from RPM 4.6 to
        PackageKit
      * Virtualization storage
      * SecTool, security audit and intrusion detection system
      * Glitch free audio using timer-based scheduling

And, since this is Fedora, we don't have anything to hide. Take a peek
at what is in the not-so-secret sauce by looking at our Release Notes in
the Fedora Project wiki. We use 100% pure free and open source software
here, none of that high-fructose proprietary stuff.

http://docs.fedoraproject.org/release-notes

Most of you should get a very tasty treat, but some of you might
experience a little bitterness. Don't fret - all is not lost - there is
still time to improve the recipe before we share it with the world. Head
over to the Fedora Bugzilla (http://bugzilla.redhat.com) and let us know
what offended your palate.

https://fedoraproject.org/wiki/How_to_file_a_bug_report

File bugs here:

https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=rawhide

If you'd like to interact with the chefs more directly, join the live
staff in the kitchen by coming to #fedora-qa on irc.freenode.net, or
leave a message on the corkboard by the back door:

http://www.redhat.com/mailman/listinfo/fedora-test-list

Ready to get your free preview sample? Go ahead and swipe one straight
from the oven - we don't mind. Put on your favorite heat resistant
BitTorrent mitt and grab one of the following goodies. Take as many as
you like.

Thanks for tasting!

https://fedoraproject.org/get-prerelease

P.S. Please remember that as we run a public mirror system, the mirrors
for Fedora 10 Preview will not all be ready at this time, and may become
overloaded as the day goes on.  If you receive permission denied
messages, please continue trying until you get through.

-- 
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/20081104/0e8526d9/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 loganjerry at gmail.com  Tue Nov  4 15:21:24 2008
From: loganjerry at gmail.com (Jerry James)
Date: Tue, 4 Nov 2008 08:21:24 -0700
Subject: Orphaning GCL
In-Reply-To: <870180fe0811031945l662a8c6ak87d58c9485e54e8b@mail.gmail.com>
References: <1225663861.4906.15.camel@localhost.localdomain>
	<870180fe0811031945l662a8c6ak87d58c9485e54e8b@mail.gmail.com>
Message-ID: <870180fe0811040721j65009794s36bdb19cfa0b0d2@mail.gmail.com>

On Mon, Nov 3, 2008 at 8:45 PM, Jerry James <loganjerry at gmail.com> wrote:
> I'm interested in taking it.  It looks like Camm Maguire is the Debian
> maintainer.  He's got a massive patch for Debian, which appears to
> address at least some of the problems we are having in Fedora.  I
> tried an initial build, but ran into a rather strange problem.  Try to
> compile this:
>
> int main() {
> #include <unistd.h>
>  return 0;
> }
>
> I can compile it with -O.  I can compile it with -D_FORTIFY_SOURCE.
> But I cannot compile it with -O -D_FORTIFY_SOURCE.  GCC spews a whole
> bunch of errors about formerly extern functions now declared as
> static.  Is that a glibc header bug?  It is preventing GCL's sbrk
> randomization code from compiling.
>
> If we can get that worked out, I would like to take GCL.

This is now https://bugzilla.redhat.com/show_bug.cgi?id=469866 and I
have a workaround for it.  I'll take GCL.
-- 
Jerry James
http://loganjerry.googlepages.com/



From gemi at bluewin.ch  Tue Nov  4 17:15:22 2008
From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister)
Date: Tue, 04 Nov 2008 18:15:22 +0100
Subject: Orphaning GCL
In-Reply-To: <870180fe0811040721j65009794s36bdb19cfa0b0d2@mail.gmail.com>
References: <1225663861.4906.15.camel@localhost.localdomain>
	<870180fe0811031945l662a8c6ak87d58c9485e54e8b@mail.gmail.com>
	<870180fe0811040721j65009794s36bdb19cfa0b0d2@mail.gmail.com>
Message-ID: <1225818922.4906.17.camel@localhost.localdomain>

On Tue, 2008-11-04 at 08:21 -0700, Jerry James wrote:
> This is now https://bugzilla.redhat.com/show_bug.cgi?id=469866 and I
> have a workaround for it.  I'll take GCL.

Great,

you might be interested in the following:
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00778.html



From loganjerry at gmail.com  Tue Nov  4 17:41:10 2008
From: loganjerry at gmail.com (Jerry James)
Date: Tue, 4 Nov 2008 10:41:10 -0700
Subject: Orphaning GCL
In-Reply-To: <1225818922.4906.17.camel@localhost.localdomain>
References: <1225663861.4906.15.camel@localhost.localdomain>
	<870180fe0811031945l662a8c6ak87d58c9485e54e8b@mail.gmail.com>
	<870180fe0811040721j65009794s36bdb19cfa0b0d2@mail.gmail.com>
	<1225818922.4906.17.camel@localhost.localdomain>
Message-ID: <870180fe0811040941h6e51dd26h9c76392fbcba70e1@mail.gmail.com>

On Tue, Nov 4, 2008 at 10:15 AM, G?rard Milmeister <gemi at bluewin.ch> wrote:
> Great,
>
> you might be interested in the following:
> https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00778.html

Thanks for the pointer.  Wish me luck!  It looks like I'm going to need it.
-- 
Jerry James
http://loganjerry.googlepages.com/



From jkeating at redhat.com  Tue Nov  4 17:41:23 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 04 Nov 2008 09:41:23 -0800
Subject: Seeking new maintainer(s) for package(s)
Message-ID: <1225820483.24018.35.camel@luminos.localdomain>

The previous maintainer of emacs and lsscsi has asked me to find new
maintainers for these packages.  He is no longer able to devote any time
to Fedora and had unsubscribed from lists a while ago while on vacation.

If you are interested in taking over one or both of these packages in
Fedora, please contact me.

-- 
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/20081104/3ca6f3d0/attachment.sig>

From dan at danny.cz  Tue Nov  4 17:49:28 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Tue, 04 Nov 2008 18:49:28 +0100
Subject: Seeking new maintainer(s) for package(s)
In-Reply-To: <1225820483.24018.35.camel@luminos.localdomain>
References: <1225820483.24018.35.camel@luminos.localdomain>
Message-ID: <1225820968.3547.60.camel@eagle.danny.cz>


Jesse Keating p??e v ?t 04. 11. 2008 v 09:41 -0800:
> The previous maintainer of emacs and lsscsi has asked me to find new
> maintainers for these packages.  He is no longer able to devote any time
> to Fedora and had unsubscribed from lists a while ago while on vacation.
> 
> If you are interested in taking over one or both of these packages in
> Fedora, please contact me.

I will take lsscsi.


		Dan




From jkeating at redhat.com  Tue Nov  4 17:52:47 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 04 Nov 2008 09:52:47 -0800
Subject: Seeking new maintainer(s) for package(s)
In-Reply-To: <1225820968.3547.60.camel@eagle.danny.cz>
References: <1225820483.24018.35.camel@luminos.localdomain>
	<1225820968.3547.60.camel@eagle.danny.cz>
Message-ID: <1225821167.24018.36.camel@luminos.localdomain>

On Tue, 2008-11-04 at 18:49 +0100, Dan Hor?k wrote:
> Jesse Keating p??e v ?t 04. 11. 2008 v 09:41 -0800:
> > The previous maintainer of emacs and lsscsi has asked me to find new
> > maintainers for these packages.  He is no longer able to devote any time
> > to Fedora and had unsubscribed from lists a while ago while on vacation.
> > 
> > If you are interested in taking over one or both of these packages in
> > Fedora, please contact me.
> 
> I will take lsscsi.
> 
> 
> 		Dan
> 
> 

Please apply for it in 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/20081104/3236953c/attachment.sig>

From bruno.matos at gmail.com  Tue Nov  4 17:53:17 2008
From: bruno.matos at gmail.com (Bruno Matos)
Date: Tue, 04 Nov 2008 17:53:17 +0000
Subject: Seeking new maintainer(s) for package(s)
In-Reply-To: <1225820483.24018.35.camel@luminos.localdomain>
References: <1225820483.24018.35.camel@luminos.localdomain>
Message-ID: <49108C0D.4060301@gmail.com>

Jesse Keating wrote:
> The previous maintainer of emacs and lsscsi has asked me to find new
> maintainers for these packages.  He is no longer able to devote any time
> to Fedora and had unsubscribed from lists a while ago while on vacation.
>
> If you are interested in taking over one or both of these packages in
> Fedora, please contact me.
>
>   
Hello,

I would like to do some work on lsscsi, but I never did package 
maintenance you would have to teach me almost everything.

Thank you,
Bruno Matos



From jonathan.underwood at gmail.com  Tue Nov  4 17:56:19 2008
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Tue, 4 Nov 2008 17:56:19 +0000
Subject: Seeking new maintainer(s) for package(s)
In-Reply-To: <1225820483.24018.35.camel@luminos.localdomain>
References: <1225820483.24018.35.camel@luminos.localdomain>
Message-ID: <645d17210811040956m7cbe7701mad0b49701e6222e5@mail.gmail.com>

2008/11/4 Jesse Keating <jkeating at redhat.com>:
> The previous maintainer of emacs and lsscsi has asked me to find new
> maintainers for these packages.  He is no longer able to devote any time
> to Fedora and had unsubscribed from lists a while ago while on vacation.
>
> If you are interested in taking over one or both of these packages in
> Fedora, please contact me.

I would happily be a comaintainer for emacs. Emphasis on co :)



From jkeating at redhat.com  Tue Nov  4 18:02:26 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 04 Nov 2008 10:02:26 -0800
Subject: Seeking new maintainer(s) for package(s)
In-Reply-To: <49108C0D.4060301@gmail.com>
References: <1225820483.24018.35.camel@luminos.localdomain>
	<49108C0D.4060301@gmail.com>
Message-ID: <1225821746.24018.37.camel@luminos.localdomain>

On Tue, 2008-11-04 at 17:53 +0000, Bruno Matos wrote:
> 
> I would like to do some work on lsscsi, but I never did package 
> maintenance you would have to teach me almost everything.
> 

Pair up with Dan Hor?k, he has taken on lsscsi

-- 
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/20081104/3b1bce1a/attachment.sig>

From ml at deadbabylon.de  Tue Nov  4 18:09:09 2008
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Tue, 4 Nov 2008 19:09:09 +0100
Subject: KDE-SIG weekly report (45/2008)
Message-ID: <200811041909.16765.ml@deadbabylon.de>

This is a report of the weekly KDE-SIG-Meeting with a summary of the 
topics that were discussed. If you want to add a comment please reply
?to this email or add it to the related meeting page.

----------------------------------------------------------------------------------

= Weekly KDE Summary =

Week: 45/2008

Time: 2008-11-04 16:00 UTC

Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-11-04

Meeting log: https://fedoraproject.org/w/uploads/5/58/KDE-SIG-2008-11-04.txt

----------------------------------------------------------------------------------

= Participants =

- KevinKofler
- RexDieter
- SebastianVahl
- ThanNgo

----------------------------------------------------------------------------------

= Agenda =

* Systray backport [1]
* Desktop User Guide 
* additional packages for live images (~20 megs free)  [2]
* #468889- libldap-2.4.so.2: undefined symbol: ldap_int_tls_destroy [3]

= Summary =

Systray backport :
- - - - -
* This is a backport of KDE 4.2's systray which replaces the systray plasmoid 
entirely. 
* The main reason for including this would be the high visibility of ugly 
backgrounds of the KDE4 systray applets. 
* As this backport was proposed by JaroslavReznik who wasn't present at 
meeting time the decision was postponed. 

Desktop User Guide:
- - - - -
* (This topic wasn't discussed) 

* additional packages for live images (~20 megs free):
- - - - -
* Since the input-methods group was removed from fedora-live-base.ks there is 
plenty of free space. 
* These packages were added after the Preview release was composed: digikam, 
kdeedu-kstars, konq-plugins, pavucontrol, twinkle. 
* One proposal was lancelot which will be included in the next push of the 
kickstart. 
* There were no other packages proposed, so the remaining free space (about 20 
megs minus lancelot) could be used for localized spins. 

#468889 - libldap-2.4.so.2: undefined symbol: ldap_int_tls_destroy:
- - - - -
* "kcmshell4 kdm" crashes with an undefined symbol error after hitting cancel. 
* As a workaround for this kcm_kdm will be linked against ldap. 
* This change will be tagged as f10-final as soon as possible. 

Open discussion: 
- - - - -
o Plans for KDE 4.1.3: 
* KDE 4.1.3 is scheduled to be released on Nov 05 2008. [4]
* As it's too risky to include it in F10-release, it will be released as an 
update for F10. 
* KDE 4.1.3 will also be released as an update for F9. 

o battery applet: 
* Because of guidance the battery applet will be removed from the default 
setting.

----------------------------------------------------------------------------------

= Next Meeting =

http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-11-11

----------------------------------------------------------------------------------

= Links =

[1] http://websvn.kde.org/?view=rev&revision=876362 
[2] 
https://fedoraproject.org/w/index.php?title=SebastianVahl/CurrentPackageList&oldid=57929
[3] https://bugzilla.redhat.com/show_bug.cgi?id=468889
[4] 
http://techbase.kde.org/Schedules/KDE4/4.1_Release_Schedule#November_5th.2C_2008:_Release_KDE_4.1.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081104/53422774/attachment.sig>

From dan at danny.cz  Tue Nov  4 18:29:38 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Tue, 04 Nov 2008 19:29:38 +0100
Subject: Seeking new maintainer(s) for package(s)
In-Reply-To: <1225821746.24018.37.camel@luminos.localdomain>
References: <1225820483.24018.35.camel@luminos.localdomain>
	<49108C0D.4060301@gmail.com>
	<1225821746.24018.37.camel@luminos.localdomain>
Message-ID: <1225823378.3547.71.camel@eagle.danny.cz>


Jesse Keating p??e v ?t 04. 11. 2008 v 10:02 -0800:
> On Tue, 2008-11-04 at 17:53 +0000, Bruno Matos wrote:
> > 
> > I would like to do some work on lsscsi, but I never did package 
> > maintenance you would have to teach me almost everything.
> > 
> 
> Pair up with Dan Hor?k, he has taken on lsscsi

I am open to accept a co-maintainer for this package, but first you
should be familiar with the miscellaneous guidelines located
https://fedoraproject.org/wiki/PackageMaintainers


		Dan




From bruno.matos at gmail.com  Tue Nov  4 18:47:43 2008
From: bruno.matos at gmail.com (Bruno Matos)
Date: Tue, 04 Nov 2008 18:47:43 +0000
Subject: Seeking new maintainer(s) for package(s)
In-Reply-To: <1225823378.3547.71.camel@eagle.danny.cz>
References: <1225820483.24018.35.camel@luminos.localdomain>	<49108C0D.4060301@gmail.com>	<1225821746.24018.37.camel@luminos.localdomain>
	<1225823378.3547.71.camel@eagle.danny.cz>
Message-ID: <491098CF.8070703@gmail.com>

Dan Hor?k wrote:
> Jesse Keating p??e v ?t 04. 11. 2008 v 10:02 -0800:
>   
>> On Tue, 2008-11-04 at 17:53 +0000, Bruno Matos wrote:
>>     
>>> I would like to do some work on lsscsi, but I never did package 
>>> maintenance you would have to teach me almost everything.
>>>
>>>       
>> Pair up with Dan Hor?k, he has taken on lsscsi
>>     
>
> I am open to accept a co-maintainer for this package, but first you
> should be familiar with the miscellaneous guidelines located
> https://fedoraproject.org/wiki/PackageMaintainers
>
>
> 		Dan
>
>
>   
Thank you to both. I will.



From jwboyer at gmail.com  Tue Nov  4 18:54:18 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Tue, 4 Nov 2008 13:54:18 -0500
Subject: breaking rawhide freeze
In-Reply-To: <1225807816.24018.15.camel@luminos.localdomain>
References: <20081104122854.GE17684@mokona.greysector.net>
	<1225807816.24018.15.camel@luminos.localdomain>
Message-ID: <20081104185418.GA27793@yoda.jdub.homelinux.org>

On Tue, Nov 04, 2008 at 06:10:16AM -0800, Jesse Keating wrote:
>On Tue, 2008-11-04 at 13:28 +0100, Dominik 'Rathann' Mierzejewski wrote:
>> A couple of days ago, I wanted to break the freeze and push an update to gnomeradio
>> that would make the application fully usable again (as it is now, it crashes
>> every time you try to name a radio station), but I was told (by Jesse himself,
>> and some other nice folks) to wait until after F-10 is released, because it
>> wasn't "critical enough".
>
>Can you refresh my memory of the conversation, was it email, irc, or a
>releng ticket?  I'm pretty sure we would have said after Preview release
>but still in before final.  About the only tag requests we've turned
>down are untested things, and brand new packages.

You and I were both involved.  You told him to do it as an update on
#fedora-devel.

josh



From nicolas.mailhot at laposte.net  Tue Nov  4 18:58:11 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 04 Nov 2008 19:58:11 +0100
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <20081104135801.GB20827@nostromo.devel.redhat.com>
References: <alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<a264be7213e6618996960dbeed6066b6.squirrel@arekh.dyndns.org>
	<20081103164809.GD7109@nostromo.devel.redhat.com>
	<1225735392.10861.4.camel@arekh.okg>
	<20081103183153.GF7109@nostromo.devel.redhat.com>
	<1225737698.11768.3.camel@arekh.okg>
	<1225739239.24018.0.camel@luminos.localdomain>
	<1225741178.17171.2.camel@arekh.okg>
	<20081103194712.GB10703@nostromo.devel.redhat.com>
	<1225755999.3530.3.camel@arekh.okg>
	<20081104135801.GB20827@nostromo.devel.redhat.com>
Message-ID: <1225825091.22015.1.camel@arekh.okg>

Le mardi 04 novembre 2008 ? 08:58 -0500, Bill Nottingham a ?crit :
> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> > > That's solving a different problem the wrong way, which certainly
> > > seems better suited to a bit in the review request, or packagedb, etc.
> > 
> > The target is to automate review requests as much as possible not pile
> > up new manual checks. I don't ask this just for fun. I ask this because
> > I happen to do comps QA for my SIG every few months and manual checks
> > are not fun at all.
> 
> How is packagedb or bugzilla not automatable? We have programmatic interfaces
> to both.

How the hell is software going to guess some stuff is not in comps
because we intend it not to be in comps as opposed to stuff not being in
comps because someone forgot to put it there?

-- 
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/20081104/9b198e8f/attachment.sig>

From notting at redhat.com  Tue Nov  4 19:08:02 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 4 Nov 2008 14:08:02 -0500
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
	2008-10-29]
In-Reply-To: <1225825091.22015.1.camel@arekh.okg>
References: <20081103164809.GD7109@nostromo.devel.redhat.com>
	<1225735392.10861.4.camel@arekh.okg>
	<20081103183153.GF7109@nostromo.devel.redhat.com>
	<1225737698.11768.3.camel@arekh.okg>
	<1225739239.24018.0.camel@luminos.localdomain>
	<1225741178.17171.2.camel@arekh.okg>
	<20081103194712.GB10703@nostromo.devel.redhat.com>
	<1225755999.3530.3.camel@arekh.okg>
	<20081104135801.GB20827@nostromo.devel.redhat.com>
	<1225825091.22015.1.camel@arekh.okg>
Message-ID: <20081104190802.GA27000@nostromo.devel.redhat.com>

Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> How the hell is software going to guess some stuff is not in comps
> because we intend it not to be in comps as opposed to stuff not being in
> comps because someone forgot to put it there?

A simple 'should this be in comps' flag in packagedb. Or bugzilla. Easily
queryable.

Bill



From nicolas.mailhot at laposte.net  Tue Nov  4 19:41:28 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 04 Nov 2008 20:41:28 +0100
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <20081104190802.GA27000@nostromo.devel.redhat.com>
References: <20081103164809.GD7109@nostromo.devel.redhat.com>
	<1225735392.10861.4.camel@arekh.okg>
	<20081103183153.GF7109@nostromo.devel.redhat.com>
	<1225737698.11768.3.camel@arekh.okg>
	<1225739239.24018.0.camel@luminos.localdomain>
	<1225741178.17171.2.camel@arekh.okg>
	<20081103194712.GB10703@nostromo.devel.redhat.com>
	<1225755999.3530.3.camel@arekh.okg>
	<20081104135801.GB20827@nostromo.devel.redhat.com>
	<1225825091.22015.1.camel@arekh.okg>
	<20081104190802.GA27000@nostromo.devel.redhat.com>
Message-ID: <1225827688.22015.16.camel@arekh.okg>

Le mardi 04 novembre 2008 ? 14:08 -0500, Bill Nottingham a ?crit :
> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> > How the hell is software going to guess some stuff is not in comps
> > because we intend it not to be in comps as opposed to stuff not being in
> > comps because someone forgot to put it there?
> 
> A simple 'should this be in comps' flag in packagedb. Or bugzilla. Easily
> queryable.

However
1. both packagedb and bugzilla work on srpms, and not all the rpms
created from a srpm are necessarily equal
2. this stuff can change during the (sub)package life, bugzilla only has
the initial state (and not even all the packages, early packages are not
in there)
3. that pushes more logic infra-side, which is not nice for third
parties (and we want third parties to be comfortable creating their own
private additions to Fedora)
4. that would mean packagers need to control the way their package
appears in comps in two different places (unless you generate the whole
file from this other place, which almost certainly rules out bugzilla
and is contrary to 3. anyway), which means more packager hassle and
something we want to avoid

The KISS solution is to just add everything in comps and run basic
scripts that check every package we ship appears there (say in a
dev-null group for libs or such stuff). You can easily cull the dev-null
group at comps.xml.in -> comps.xml stage if needed.

Granted, just because a package appears in comps does not mean it
appears in the right place, but usually packagers that make the effort
to edit comps try to do it properly.

-- 
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/20081104/8e52870d/attachment.sig>

From notting at redhat.com  Tue Nov  4 19:52:01 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 4 Nov 2008 14:52:01 -0500
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
	2008-10-29]
In-Reply-To: <1225827688.22015.16.camel@arekh.okg>
References: <20081103183153.GF7109@nostromo.devel.redhat.com>
	<1225737698.11768.3.camel@arekh.okg>
	<1225739239.24018.0.camel@luminos.localdomain>
	<1225741178.17171.2.camel@arekh.okg>
	<20081103194712.GB10703@nostromo.devel.redhat.com>
	<1225755999.3530.3.camel@arekh.okg>
	<20081104135801.GB20827@nostromo.devel.redhat.com>
	<1225825091.22015.1.camel@arekh.okg>
	<20081104190802.GA27000@nostromo.devel.redhat.com>
	<1225827688.22015.16.camel@arekh.okg>
Message-ID: <20081104195201.GA27408@nostromo.devel.redhat.com>

Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> 2. this stuff can change during the (sub)package life, bugzilla only has
> the initial state (and not even all the packages, early packages are not
> in there)

Then do packagedb, and it's even a per-release flag. Realistically, if
someone isn't editing comps when they split things into subpackages, I
don't know that having to have a defined person always going through
and cleaning up after them is better.

> 3. that pushes more logic infra-side, which is not nice for third
> parties (and we want third parties to be comfortable creating their own
> private additions to Fedora)

???? If they're doing their own repo, they already are doing any
infrastructure work themselves in their own file. However we verify
ours doesn't really matter.

> The KISS solution is to just add everything in comps and run basic
> scripts that check every package we ship appears there (say in a
> dev-null group for libs or such stuff). You can easily cull the dev-null
> group at comps.xml.in -> comps.xml stage if needed.
> 
> Granted, just because a package appears in comps does not mean it
> appears in the right place, but usually packagers that make the effort
> to edit comps try to do it properly.

This doesn't actually help you get *useful* comps, as the first step
would be 'add all packages not listed to the devnull group', repeated
weekly. Which doesn't actually help you with respect to missing packages.

Bill



From nicolas.mailhot at laposte.net  Tue Nov  4 20:14:15 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 04 Nov 2008 21:14:15 +0100
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
 2008-10-29]
In-Reply-To: <20081104195201.GA27408@nostromo.devel.redhat.com>
References: <20081103183153.GF7109@nostromo.devel.redhat.com>
	<1225737698.11768.3.camel@arekh.okg>
	<1225739239.24018.0.camel@luminos.localdomain>
	<1225741178.17171.2.camel@arekh.okg>
	<20081103194712.GB10703@nostromo.devel.redhat.com>
	<1225755999.3530.3.camel@arekh.okg>
	<20081104135801.GB20827@nostromo.devel.redhat.com>
	<1225825091.22015.1.camel@arekh.okg>
	<20081104190802.GA27000@nostromo.devel.redhat.com>
	<1225827688.22015.16.camel@arekh.okg>
	<20081104195201.GA27408@nostromo.devel.redhat.com>
Message-ID: <1225829655.22015.27.camel@arekh.okg>

Le mardi 04 novembre 2008 ? 14:52 -0500, Bill Nottingham a ?crit :
> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> > 2. this stuff can change during the (sub)package life, bugzilla only has
> > the initial state (and not even all the packages, early packages are not
> > in there)
> 
> Then do packagedb, and it's even a per-release flag. Realistically, if
> someone isn't editing comps when they split things into subpackages, I
> don't know that having to have a defined person always going through
> and cleaning up after them is better.

The aim is not to have a defined person going there and cleaning up
after people (quick burn-out receipe).

The aim is to have regular automated checks and packager nagmail if
their package is not listed in comps at all. Just like we already do for
lots of other stuff (packages approved but not built, dependency
breakage, etc)

> > 3. that pushes more logic infra-side, which is not nice for third
> > parties (and we want third parties to be comfortable creating their own
> > private additions to Fedora)
> 
> ???? If they're doing their own repo, they already are doing any
> infrastructure work themselves in their own file. However we verify
> ours doesn't really matter.

If we move validation then generation packagedb side it certainly does.

> > The KISS solution is to just add everything in comps and run basic
> > scripts that check every package we ship appears there (say in a
> > dev-null group for libs or such stuff). You can easily cull the dev-null
> > group at comps.xml.in -> comps.xml stage if needed.
> > 
> > Granted, just because a package appears in comps does not mean it
> > appears in the right place, but usually packagers that make the effort
> > to edit comps try to do it properly.
> 
> This doesn't actually help you get *useful* comps, as the first step
> would be 'add all packages not listed to the devnull group', 

The first step would be "for release foo (I guess 11), please *think*
where your packages should appear in comps, and put them here (including
in the dev-null group if that's the best choice), if you don't want to
get nagmails and appear in the daily breakage status report"

> repeated
> weekly. Which doesn't actually help you with respect to missing packages.

That does not help you only if you forget weekly which packages you've
decided should not be exposed to users in comps. Which is exactly what
happens if you refuse to list them somewhere.

If you do have a packager-provided list of packages to exclude, and
scripts that check it regularly, you have a nicely converging system
that does not require one poor person doing all the tedious work alone
manually.

-- 
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/20081104/5a72611c/attachment.sig>

From bpepple at fedoraproject.org  Tue Nov  4 20:28:17 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 04 Nov 2008 15:28:17 -0500
Subject: Plan for tomorrows (20081105) FESCO meeting
Message-ID: <1225830497.4688.1.camel@kennedy>

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 -- Features - 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/20081104/7df3ca73/attachment.sig>

From james.antill at redhat.com  Tue Nov  4 21:12:41 2008
From: james.antill at redhat.com (James Antill)
Date: Tue, 04 Nov 2008 16:12:41 -0500
Subject: Comps/groups/tags-concepts [Was: FESCo Meeting Summary for
	2008-10-29]
In-Reply-To: <20081104135801.GB20827@nostromo.devel.redhat.com>
References: <alpine.LFD.2.00.0811031033480.32547@localhost.localdomain>
	<a264be7213e6618996960dbeed6066b6.squirrel@arekh.dyndns.org>
	<20081103164809.GD7109@nostromo.devel.redhat.com>
	<1225735392.10861.4.camel@arekh.okg>
	<20081103183153.GF7109@nostromo.devel.redhat.com>
	<1225737698.11768.3.camel@arekh.okg>
	<1225739239.24018.0.camel@luminos.localdomain>
	<1225741178.17171.2.camel@arekh.okg>
	<20081103194712.GB10703@nostromo.devel.redhat.com>
	<1225755999.3530.3.camel@arekh.okg>
	<20081104135801.GB20827@nostromo.devel.redhat.com>
Message-ID: <1225833161.16415.91.camel@code.and.org>

On Tue, 2008-11-04 at 08:58 -0500, Bill Nottingham wrote:
> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> > > That's solving a different problem the wrong way, which certainly
> > > seems better suited to a bit in the review request, or packagedb, etc.
> > 
> > The target is to automate review requests as much as possible not pile
> > up new manual checks. I don't ask this just for fun. I ask this because
> > I happen to do comps QA for my SIG every few months and manual checks
> > are not fun at all.
> 
> How is packagedb or bugzilla not automatable? We have programmatic interfaces
> to both.
> 
> All I'm saying is that changing the user-visible behavior in order
> to implement a specific QA method for comps is putting the cart
> before the horse.

 There is a visible flag for groups?. So we could have a /dev/null group
without it being directly user visible.
 However that'll add roughly 874K to comps. (65K compressed), then
yum/etc. has to parse it all out whenever we need group info. and the
"all packagenames need to be in at least one group" doesn't strike me as
a very good rule, anyway.

? yum-groups-manager --id /dev/null --not-user-visible yum

-- 
James Antill <james.antill at redhat.com>
Red Hat
-------------- next part --------------
A 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/20081104/1fe723ca/attachment.sig>

From lmacken at redhat.com  Tue Nov  4 21:24:45 2008
From: lmacken at redhat.com (Luke Macken)
Date: Tue, 4 Nov 2008 16:24:45 -0500
Subject: Bodhi open for F-10
Message-ID: <20081104212445.GG8807@x300>

Last night I created the Fedora 10 release within bodhi, so you should
now be able to enqueue your 0-day updates.  You can submit updates for
your dist-f10-updates-candidate builds using the web form[0], the
command-line client[1], or by running `make update` in the CVS branch.
As always, please file bodhi issues in trac[2].

Thanks,

luke

[0]: https://admin.fedoraproject.org/updates/new
[1]: https://fedorahosted.org/bodhi/wiki/CLI
[2]: https://fedorahosted.org/bodhi/newticket

_______________________________________________
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  Tue Nov  4 21:56:31 2008
From: opensource at till.name (Till Maas)
Date: Tue, 04 Nov 2008 22:56:31 +0100
Subject: Comps/groups/tags-concepts
In-Reply-To: <1225827688.22015.16.camel@arekh.okg>
References: <20081103164809.GD7109@nostromo.devel.redhat.com>
	<20081104190802.GA27000@nostromo.devel.redhat.com>
	<1225827688.22015.16.camel@arekh.okg>
Message-ID: <200811042256.49940.opensource@till.name>

On Tue November 4 2008, Nicolas Mailhot wrote:

> 2. this stuff can change during the (sub)package life, bugzilla only has
> the initial state (and not even all the packages, early packages are not
> in there)

I agree that bugzilla is not a good choice for this.

> 3. that pushes more logic infra-side, which is not nice for third
> parties (and we want third parties to be comfortable creating their own
> private additions to Fedora)

I cannot follow here, because third parties still can use the comps file that 
any frontend will spit out.

> 4. that would mean packagers need to control the way their package
> appears in comps in two different places (unless you generate the whole
> file from this other place, which almost certainly rules out bugzilla
> and is contrary to 3. anyway), which means more packager hassle and
> something we want to avoid

I would enjoy a useful UI to edit groups, because I have to edit it around 
once for each package I bring into Fedora, so a well designed UI can help a 
lot here, that too manually search trough a huge xml file to find a 
appropriate category. Also I do not see any reason why not both should be 
possible, i.e. use packagedb as a frontend to edit comps and still store it 
in some scm, where anyone interested can edit it manually.

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/20081104/bc13ee07/attachment.sig>

From lists at ebourne.me.uk  Tue Nov  4 22:17:05 2008
From: lists at ebourne.me.uk (Martin Ebourne)
Date: Tue, 4 Nov 2008 22:17:05 +0000 (UTC)
Subject: breaking rawhide freeze
References: <20081104122854.GE17684@mokona.greysector.net>
	<935ead450811040447w7a52c303y45a1bb5b121e59a9@mail.gmail.com>
Message-ID: <pan.2008.11.04.22.17.05@ebourne.me.uk>

On Tue, 04 Nov 2008 06:47:38 -0600, Jeffrey Ollie wrote:
> From what I saw in today's (2008/11/04) rawhide report all of the
> packages that got updated had some commonalities:
> 
> 1) Would be in one of the "official" Live images, and therefore
> difficult/impossible to update once F10 was released.
> 2) Security fixes.
> 3) Very popular apps.
> 
> From what I saw GIMP only fit in category 3, but I think you'd have to
> agree that GIMP is a much more widely used app than gnomeradio.

By your list (3) makes no sense. An update can only affect people that 
use the package. So the risk-reward ratio of updating a package is not 
related to the popularity of a package.

If there's a major fix to gnome-radio this will be very important to 
gnome-radio users and zero risk to everyone else. The only risk would be 
of extra breakage which only affected gnome-radio users anyway.

Cheers,
Martin



From jkeating at redhat.com  Tue Nov  4 22:23:33 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 04 Nov 2008 14:23:33 -0800
Subject: breaking rawhide freeze
In-Reply-To: <20081104185418.GA27793@yoda.jdub.homelinux.org>
References: <20081104122854.GE17684@mokona.greysector.net>
	<1225807816.24018.15.camel@luminos.localdomain>
	<20081104185418.GA27793@yoda.jdub.homelinux.org>
Message-ID: <1225837413.25248.13.camel@luminos.localdomain>

On Tue, 2008-11-04 at 13:54 -0500, Josh Boyer wrote:
> On Tue, Nov 04, 2008 at 06:10:16AM -0800, Jesse Keating wrote:
> >On Tue, 2008-11-04 at 13:28 +0100, Dominik 'Rathann' Mierzejewski wrote:
> >> A couple of days ago, I wanted to break the freeze and push an update to gnomeradio
> >> that would make the application fully usable again (as it is now, it crashes
> >> every time you try to name a radio station), but I was told (by Jesse himself,
> >> and some other nice folks) to wait until after F-10 is released, because it
> >> wasn't "critical enough".
> >
> >Can you refresh my memory of the conversation, was it email, irc, or a
> >releng ticket?  I'm pretty sure we would have said after Preview release
> >but still in before final.  About the only tag requests we've turned
> >down are untested things, and brand new packages.
> 
> You and I were both involved.  You told him to do it as an update on
> #fedora-devel.
> 
> josh
> 

Well, file a ticket if you want re-consideration.  We're not above that.
I could have been distracted by the Preview disaster at the time and not
really friendly toward updates.

However I would argue that if you're an internet radio user, you're
likely connected to the Internet and able to get updates....  

-- 
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/20081104/ab8c4cf4/attachment.sig>

From mw_triad at users.sourceforge.net  Tue Nov  4 23:37:56 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Tue, 04 Nov 2008 17:37:56 -0600
Subject: Software is once again unpatentable in the   United States
In-Reply-To: <64b14b300811021229h5551a891i990eb3fccca2b9b5@mail.gmail.com>
References: <64b14b300811021229h5551a891i990eb3fccca2b9b5@mail.gmail.com>
Message-ID: <geqmck$dpq$1@ger.gmane.org>

Valent Turkovic wrote:
> Quote from http://www.pli.edu/patentcenter/blog.asp?view=plink&id=368 :
> 
> Here are the highlights:
> 
>   * The Federal Circuit rejected the that the "useful, concrete and tangible
> 	result" inquiry as being inadequate.
> 
>   * Patentability under 101 does not depend on process steps, but rather
> 	requires a tangible machine or transformation into a different state.
> 
>   * *Software* *is* *once* *again* *unpatentable* *in* *the* *United* *States*
> 
>   * In order to protect what was formerly known as patentable software we
> 	will have to go back to claiming a machine that provides certain
> 	functionality.
> 
>   * Software patents that have been issued under the previous understanding
> 	of the law are almost certainly now worthless.

Also from http://ben.klemens.org/blog/arch/00000009.htm:
> Despite claiming that all that matters is the
> machine-or-transformation test, the ruling also bears in mind many
> other necessary conditions for patentability, such as the rule that a
> patent may not ?wholly pre-empt? a law of nature or principle or
> mathematical formula. Also, if you wholly pre-empt a mathematical
> algorithm within some narrow field of endeavor, the court rules that
> this is still a pre-emption. I'll have a little more on this below.

Note "a patent may not 'wholly pre-empt' ... a mathematical formula".

...which means all those codecs from livna/rpmfusion just became 100% 
legal, no royalty required*.

(* assuming the copyright license is not an issue, of course)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Igor Peshansky: Don't hippos love water even more than dogs?
Dave Korn: Don't ask me. I didn't even know that hippos loved dogs.



From limb at jcomserv.net  Tue Nov  4 23:42:57 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Tue, 4 Nov 2008 17:42:57 -0600 (CST)
Subject: Software is once again unpatentable in the   United States
In-Reply-To: <geqmck$dpq$1@ger.gmane.org>
References: <64b14b300811021229h5551a891i990eb3fccca2b9b5@mail.gmail.com>
	<geqmck$dpq$1@ger.gmane.org>
Message-ID: <9b1db7c129b6250b6a2f325e6a75f59d.squirrel@mail.jcomserv.net>


> Valent Turkovic wrote:
>> Quote from http://www.pli.edu/patentcenter/blog.asp?view=plink&id=368 :
>>
>> Here are the highlights:
>>
>>   * The Federal Circuit rejected the that the "useful, concrete and
>> tangible
>> 	result" inquiry as being inadequate.
>>
>>   * Patentability under 101 does not depend on process steps, but rather
>> 	requires a tangible machine or transformation into a different state.
>>
>>   * *Software* *is* *once* *again* *unpatentable* *in* *the* *United*
>> *States*
>>
>>   * In order to protect what was formerly known as patentable software
>> we
>> 	will have to go back to claiming a machine that provides certain
>> 	functionality.
>>
>>   * Software patents that have been issued under the previous
>> understanding
>> 	of the law are almost certainly now worthless.
>
> Also from http://ben.klemens.org/blog/arch/00000009.htm:
>> Despite claiming that all that matters is the
>> machine-or-transformation test, the ruling also bears in mind many
>> other necessary conditions for patentability, such as the rule that a
>> patent may not ?wholly pre-empt? a law of nature or principle or
>> mathematical formula. Also, if you wholly pre-empt a mathematical
>> algorithm within some narrow field of endeavor, the court rules that
>> this is still a pre-emption. I'll have a little more on this below.
>
> Note "a patent may not 'wholly pre-empt' ... a mathematical formula".
>
> ...which means all those codecs from livna/rpmfusion just became 100%
> legal, no royalty required*.
>
> (* assuming the copyright license is not an issue, of course)

I assume an "official" statement on this from Fedora/RedHat legal folk
will be forthcoming.

Unless it already has, and I missed it, which is entirely possible.

> --
> Matthew
> Please do not quote my e-mail address unobfuscated in message bodies.
> --
> Igor Peshansky: Don't hippos love water even more than dogs?
> Dave Korn: Don't ask me. I didn't even know that hippos loved dogs.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From jspaleta at gmail.com  Tue Nov  4 23:50:49 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 4 Nov 2008 14:50:49 -0900
Subject: Software is once again unpatentable in the United States
In-Reply-To: <9b1db7c129b6250b6a2f325e6a75f59d.squirrel@mail.jcomserv.net>
References: <64b14b300811021229h5551a891i990eb3fccca2b9b5@mail.gmail.com>
	<geqmck$dpq$1@ger.gmane.org>
	<9b1db7c129b6250b6a2f325e6a75f59d.squirrel@mail.jcomserv.net>
Message-ID: <604aa7910811041550n3cbbef99y628b67fa32f669b4@mail.gmail.com>

On Tue, Nov 4, 2008 at 2:42 PM, Jon Ciesla
> I assume an "official" statement on this from Fedora/RedHat
> legal folk will be forthcoming.
>
> Unless it already has, and I missed it, which is entirely possible.

As seen in the groklaw article previously posted:

http://www.press.redhat.com/2008/11/03/bilski-and-software-patents-?-good-news-for-foss/

-jef



From mw_triad at users.sourceforge.net  Wed Nov  5 00:31:26 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Tue, 04 Nov 2008 18:31:26 -0600
Subject: Software is once again unpatentable in the   United States
In-Reply-To: <9b1db7c129b6250b6a2f325e6a75f59d.squirrel@mail.jcomserv.net>
References: <64b14b300811021229h5551a891i990eb3fccca2b9b5@mail.gmail.com>	<geqmck$dpq$1@ger.gmane.org>
	<9b1db7c129b6250b6a2f325e6a75f59d.squirrel@mail.jcomserv.net>
Message-ID: <geqpgv$ngp$1@ger.gmane.org>

Jon Ciesla wrote:
> Matthew Woehlke wrote:
>> Also from http://ben.klemens.org/blog/arch/00000009.htm:
>>> Despite claiming that all that matters is the
>>> machine-or-transformation test, the ruling also bears in mind many
>>> other necessary conditions for patentability, such as the rule that a
>>> patent may not ?wholly pre-empt? a law of nature or principle or
>>> mathematical formula. Also, if you wholly pre-empt a mathematical
>>> algorithm within some narrow field of endeavor, the court rules that
>>> this is still a pre-emption. I'll have a little more on this below.
>> Note "a patent may not 'wholly pre-empt' ... a mathematical formula".
>>
>> ...which means all those codecs from livna/rpmfusion just became 100%
>> legal, no royalty required*.
>>
>> (* assuming the copyright license is not an issue, of course)
> 
> I assume an "official" statement on this from Fedora/RedHat legal folk
> will be forthcoming.
> 
> Unless it already has, and I missed it, which is entirely possible.

Jeff already pointed out RH's press release. As has been stated, the 
Bilski decision does not paint the issue in black and white, and as 
such, I don't expect *Red Hat* to decide that including e.g. lame in 
Fedora is now okay.

Nevertheless, if the rule that math cannot be patented is upheld, I 
think victory, at least for some areas that have historically caused 
much friction (i.e. multimedia codecs) is inevitable. (And since other 
areas fall more closely into "business methods", well... those patents 
are in for rough times as well.)

And it's ammunition for non-paid "patented" codec users to say 
(rightfully) that the patents they are allegedly violating are, in fact, 
illegal.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Igor Peshansky: Don't hippos love water even more than dogs?
Dave Korn: Don't ask me. I didn't even know that hippos loved dogs.



From jspaleta at gmail.com  Wed Nov  5 00:43:26 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 4 Nov 2008 15:43:26 -0900
Subject: Software is once again unpatentable in the United States
In-Reply-To: <geqpgv$ngp$1@ger.gmane.org>
References: <64b14b300811021229h5551a891i990eb3fccca2b9b5@mail.gmail.com>
	<geqmck$dpq$1@ger.gmane.org>
	<9b1db7c129b6250b6a2f325e6a75f59d.squirrel@mail.jcomserv.net>
	<geqpgv$ngp$1@ger.gmane.org>
Message-ID: <604aa7910811041643m3ea3cebfrd9c67990b9dffdbe@mail.gmail.com>

On Tue, Nov 4, 2008 at 3:31 PM, Matthew Woehlke
> And it's ammunition for non-paid "patented" codec users to say (rightfully)
> that the patents they are allegedly violating are, in fact, illegal.

Even if this was a clear cut KO of all software patents in the
US..which it isn't... the problem is its not just US patent law.
People like to pretend it is...but it isn't.  The police raids for mp3
infringers at the German CeBIT conference will most likely happen
again next year.

-jef



From dominik at greysector.net  Wed Nov  5 01:52:12 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 5 Nov 2008 02:52:12 +0100
Subject: breaking rawhide freeze
In-Reply-To: <1225837413.25248.13.camel@luminos.localdomain>
References: <20081104122854.GE17684@mokona.greysector.net>
	<1225807816.24018.15.camel@luminos.localdomain>
	<20081104185418.GA27793@yoda.jdub.homelinux.org>
	<1225837413.25248.13.camel@luminos.localdomain>
Message-ID: <20081105015211.GC21844@mokona.greysector.net>

On Tuesday, 04 November 2008 at 23:23, Jesse Keating wrote:
> On Tue, 2008-11-04 at 13:54 -0500, Josh Boyer wrote:
> > On Tue, Nov 04, 2008 at 06:10:16AM -0800, Jesse Keating wrote:
> > >On Tue, 2008-11-04 at 13:28 +0100, Dominik 'Rathann' Mierzejewski wrote:
> > >> A couple of days ago, I wanted to break the freeze and push an update to gnomeradio
> > >> that would make the application fully usable again (as it is now, it crashes
> > >> every time you try to name a radio station), but I was told (by Jesse himself,
> > >> and some other nice folks) to wait until after F-10 is released, because it
> > >> wasn't "critical enough".
> > >
> > >Can you refresh my memory of the conversation, was it email, irc, or a
> > >releng ticket?  I'm pretty sure we would have said after Preview release
> > >but still in before final.  About the only tag requests we've turned
> > >down are untested things, and brand new packages.
> > 
> > You and I were both involved.  You told him to do it as an update on
> > #fedora-devel.
> 
> Well, file a ticket if you want re-consideration.  We're not above that.
> I could have been distracted by the Preview disaster at the time and not
> really friendly toward updates.

Done.

> However I would argue that if you're an internet radio user,
> you're likely connected to the Internet and able to get updates....

Actually, gnomeradio is not for internet radio, but real live FM radio.
It needs a tuner hardware, which is why it took me so long to issue
an update to fix the bug - I didn't have the hardware back in my desktop
until recently.

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  Wed Nov  5 08:52:33 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 05 Nov 2008 09:52:33 +0100
Subject: Software is once again unpatentable in the United States
In-Reply-To: <604aa7910811041643m3ea3cebfrd9c67990b9dffdbe@mail.gmail.com>
References: <64b14b300811021229h5551a891i990eb3fccca2b9b5@mail.gmail.com>	<geqmck$dpq$1@ger.gmane.org>	<9b1db7c129b6250b6a2f325e6a75f59d.squirrel@mail.jcomserv.net>	<geqpgv$ngp$1@ger.gmane.org>
	<604aa7910811041643m3ea3cebfrd9c67990b9dffdbe@mail.gmail.com>
Message-ID: <49115ED1.6060907@hhs.nl>

Jeff Spaleta wrote:
> On Tue, Nov 4, 2008 at 3:31 PM, Matthew Woehlke
>> And it's ammunition for non-paid "patented" codec users to say (rightfully)
>> that the patents they are allegedly violating are, in fact, illegal.
> 
> Even if this was a clear cut KO of all software patents in the
> US..which it isn't... the problem is its not just US patent law.
> People like to pretend it is...but it isn't.  The police raids for mp3
> infringers at the German CeBIT conference will most likely happen
> again next year.
> 

That is just the German Border Cops being stupid (*) and acting on a not proven 
valid patent. The general legal opinion in the EU is still that software is not 
patentable, attempts have been made to change the law, but have sofar all been 
blocked by the EU parlement.

Note IANAL, this is my personal opinion, etc.

(*) and an Italian patent troll abusing this.

Regards,

Hans



From rawhide at fedoraproject.org  Wed Nov  5 10:11:23 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Wed,  5 Nov 2008 10:11:23 +0000 (UTC)
Subject: rawhide report: 20081105 changes
Message-ID: <20081105101123.6007C1F8255@releng2.fedora.phx.redhat.com>

Compose started at Wed Nov  5 06:01:12 UTC 2008

Updated Packages:

alliance-5.0-22.20070718snap.fc10
---------------------------------
* Mon Nov  3 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 5.0-22.20070718snap
- rebuild for F10


gedit-2.24.1-1.fc10
-------------------
* Tue Nov  4 17:00:00 2008 Ray Strode <rstrode at redhat.com> - 1:2.24.1-1
- Update to 2.24.1 (bug 469934)


gnome-panel-2.24.1-3.fc10
-------------------------
* Mon Nov  3 17:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.1-3
- Fix up panel slide in patch to work better with empty panels

* Mon Nov  3 17:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.1-2
- Fix up panel slide in patch to
  1) not have odd effects with vertical panels
  2) set up struts earlier


gvfs-1.0.2-3.fc10
-----------------
* Tue Nov  4 17:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> - 1.0.2-3
- Return an empty array on success when no content type
  matches (#468946)


gwave-2-10.20070514snap.fc10
----------------------------
* Mon Nov  3 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 2-10.20070514snap
- rebuild due to segmentation fault - F10


ktechlab-0.3.69-10.20081031svn.fc10
-----------------------------------
* Mon Nov  3 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 0.3.69-10.20081031svn
- added sdcc as Requires

* Sat Nov  1 18:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 0.3.69-9.20081031svn
- fixed microcontrollers support
- fixed Bug 469126 -  ktechlab quits when attempting to add a component to a schematic


perl-Email-Date-1.103-4.fc10
----------------------------
* Tue Nov  4 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.103-4
- add Requires: perl(Email::Abstract) to fix bz 468716


plymouth-0.6.0-0.2008.10.30.4.fc10
----------------------------------
* Mon Nov  3 17:00:00 2008 Jeremy Katz <katzj at redhat.com> - 0.6.0-0.2008.10.30.4
- Allow pre-setting the default plugin when calling plymouth-populate-initrd

* Fri Oct 31 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.10.30.3
- Add pango minimum version to buildrequires


policycoreutils-2.0.57-11.fc10
------------------------------
* Tue Nov  4 17:00:00 2008 Jesse Keating <jkeating at redhat.com> - 2.0.57-11
- Move the usermode-gtk requires to the -gui subpackage.


pungi-2.0.8-1.fc10
------------------
* Tue Nov  4 17:00:00 2008 Jesse Keating <jkeating at redhat.com> - 2.0.8-1
- Set default disc size to 695

* Tue Nov  4 17:00:00 2008 Jesse Keating <jkeating at redhat.com> - 2.0.7-1
- Fix splittree to actually use the iso size defined in kickstarts
- Use https url for bugzilla by default.


solar-kde-theme-0.1.15-1.fc10
-----------------------------
* Tue Nov  4 17:00:00 2008 Than Ngo <than at redhat.com> 0.1.15-1
- fix bz#469819, Username and password input fields overlaps each other

* Mon Nov  3 17:00:00 2008 Jaroslav Reznik <jreznik at redhat.com> 0.1.14-1
- revert clock label overflows changes (bz#469141)

* Mon Nov  3 17:00:00 2008 Jaroslav Reznik <jreznik at redhat.com> 0.1.13-1
- fixes KDM clock label overflows the login box (bz#469141)


xorg-x11-server-1.5.2-12.fc10
-----------------------------
* Fri Oct 31 18:00:00 2008 Adam Jackson <ajax at redhat.com> 1.5.2-12
- xserver-1.5.2-drain-console.patch: Silently eat any input we get from the
  tty fd, lest terrible wakeup storms ensue.

* Tue Oct 28 18:00:00 2008 Adam Jackson <ajax at redhat.com> 1.5.2-11
- Un-require mouse and keyboard, we're an evdev shop now
- Drop some obsoletes from the F7 timeframe
- Require vesa on i386 and amd64, fbdev elsewhere


yum-utils-1.1.18-1.fc10
-----------------------
* Wed Oct 29 18:00:00 2008 Tim Lauridsen <timlau at fedoraproject.org>
- mark as 1.1.18

* Mon Oct 27 18:00:00 2008 Seth Vidal <skvidal at fedoraproject.org>
- add rpm-warm-cache plugin


Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 13









Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot





From dwalsh at redhat.com  Wed Nov  5 13:23:40 2008
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Wed, 05 Nov 2008 08:23:40 -0500
Subject: Is there a way to set up gnome-screensaver or gnome-sesssion to
 autologout when idle.
Message-ID: <49119E5C.8070300@redhat.com>

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

I would like to give the admin the ability to setup xguest to logout
when the session is idle for some time period?

I know this is a risky thing to do.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkRnlwACgkQrlYvE4MpobO3ZACgwlzs5AXZxjOyDUvngxCWvAt6
8AgAoLGLmBf8jgpfa8WH0RungVNlEX/o
=f7sx
-----END PGP SIGNATURE-----



From rjones at redhat.com  Wed Nov  5 13:32:58 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 5 Nov 2008 13:32:58 +0000
Subject: Orphaning GCL
In-Reply-To: <870180fe0811031945l662a8c6ak87d58c9485e54e8b@mail.gmail.com>
References: <1225663861.4906.15.camel@localhost.localdomain>
	<870180fe0811031945l662a8c6ak87d58c9485e54e8b@mail.gmail.com>
Message-ID: <20081105133258.GA14366@amd.home.annexia.org>

On Mon, Nov 03, 2008 at 08:45:29PM -0700, Jerry James wrote:
> int main() {
> #include <unistd.h>
>   return 0;
> }

Is it supposed to be possible to compile this?

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top



From rjones at redhat.com  Wed Nov  5 13:36:28 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 5 Nov 2008 13:36:28 +0000
Subject: Detecting binaries in rpmbuild
In-Reply-To: <1225792413.31158.0.camel@wsjoost>
References: <490F653E.7010508@cora.nwra.com> <1225792413.31158.0.camel@wsjoost>
Message-ID: <20081105133628.GB14366@amd.home.annexia.org>

On Tue, Nov 04, 2008 at 10:53:33AM +0100, Joost van der Sluis wrote:
> Op maandag 03-11-2008 om 13:55 uur [tijdzone -0700], schreef Orion
> Poplawski:
> > I just discovered in a package I'm putting through review that the 
> > upstream tar ball contains some pre-compiled binaries.  It seems like 
> > this would be a good check for rpmbuild to run automatically before
> > the 
> > %build step.  Thoughts? 
> 
> That would kill some packages. Like all compilers that have to bootstrap
> theirselves. 

Should compilers be carrying binary stuff in their source tarballs
even for bootstrapping?

For MinGW we separated the binary bootstrap stuff into separate
*NON-Fedora* RPMs.  The idea is that if you need to bootstrap on a
bare system, you have to install these *-bootstrap RPMs, and then you
can compile the real RPMs (from pure source SRPMS of course), and once
these are installed they obsolete the *-bootstrap RPMs.  Thus our
Fedora SRPMs are pure source, no binaries.

http://fedoraproject.org/wiki/MinGW/Bootstrapping

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  Wed Nov  5 13:38:03 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 5 Nov 2008 13:38:03 +0000
Subject: Detecting binaries in rpmbuild
In-Reply-To: <49102718.8050308@redhat.com>
References: <490F653E.7010508@cora.nwra.com>
	<60405f92f97dd91d9432c26832de3174.squirrel@mail.chuzibooks.com>
	<49102718.8050308@redhat.com>
Message-ID: <20081105133803.GC14366@amd.home.annexia.org>

On Tue, Nov 04, 2008 at 10:42:32AM +0000, Andrew Haley wrote:
> Jon Ciesla wrote:
> >> I just discovered in a package I'm putting through review that the
> >> upstream tar ball contains some pre-compiled binaries.  It seems like
> >> this would be a good check for rpmbuild to run automatically before the
> >> %build step.  Thoughts?
> > 
> > Fine, as long as it doesn't prevent building rpms from precompiled
> > binaries.  I mean, other than compilers, we really shouldn't do it in
> > Fedora, but taking away that functionality would prevent companies
> > building some rpms for internal use.  I agree that rpmlint sounds like a
> > great place for this.
> 
> Hold on, how do you know that something is a "binary" ?  What if, for
> example, it's an image bitmap?  In the general case it's not possible
> to tell if something is source or binary.

It's probably a good idea to spot some common binary traps, such as
ELF objects/executables, COFF binaries (for Windows/MinGW), jar files
with bytecode, and Mono assemblies with CIL code.

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 loganjerry at gmail.com  Wed Nov  5 13:54:24 2008
From: loganjerry at gmail.com (Jerry James)
Date: Wed, 5 Nov 2008 06:54:24 -0700
Subject: Orphaning GCL
In-Reply-To: <20081105133258.GA14366@amd.home.annexia.org>
References: <1225663861.4906.15.camel@localhost.localdomain>
	<870180fe0811031945l662a8c6ak87d58c9485e54e8b@mail.gmail.com>
	<20081105133258.GA14366@amd.home.annexia.org>
Message-ID: <870180fe0811050554x7eb9f9d7y58e8cca8a6782384@mail.gmail.com>

On Wed, Nov 5, 2008 at 6:32 AM, Richard W.M. Jones <rjones at redhat.com> wrote:
> On Mon, Nov 03, 2008 at 08:45:29PM -0700, Jerry James wrote:
>> int main() {
>> #include <unistd.h>
>>   return 0;
>> }
>
> Is it supposed to be possible to compile this?

No, that's not legal C.  I didn't know that, so I learned something
from the experience, which makes it a good one.  I sent a patch
upstream yesterday to fix the GCL code so it doesn't do this.
-- 
Jerry James
http://loganjerry.googlepages.com/



From bmr at redhat.com  Wed Nov  5 14:05:35 2008
From: bmr at redhat.com (Bryn M. Reeves)
Date: Wed, 05 Nov 2008 14:05:35 +0000
Subject: Orphaning GCL
In-Reply-To: <870180fe0811050554x7eb9f9d7y58e8cca8a6782384@mail.gmail.com>
References: <1225663861.4906.15.camel@localhost.localdomain>	<870180fe0811031945l662a8c6ak87d58c9485e54e8b@mail.gmail.com>	<20081105133258.GA14366@amd.home.annexia.org>
	<870180fe0811050554x7eb9f9d7y58e8cca8a6782384@mail.gmail.com>
Message-ID: <4911A82F.2000206@redhat.com>

Jerry James wrote:
> On Wed, Nov 5, 2008 at 6:32 AM, Richard W.M. Jones <rjones at redhat.com> wrote:
>> On Mon, Nov 03, 2008 at 08:45:29PM -0700, Jerry James wrote:
>>> int main() {
>>> #include <unistd.h>
>>>   return 0;
>>> }
>> Is it supposed to be possible to compile this?
> 
> No, that's not legal C.  I didn't know that, so I learned something
> from the experience, which makes it a good one.  I sent a patch
> upstream yesterday to fix the GCL code so it doesn't do this.

OT but.. That snippet *is* legal C, but the validity of compiling this 
file then depends on the content of unistd.h (which if it's a "real" 
unistd.h will of course never produce legal preprocessed C...).

If the file being included were to just contain e.g. statements, macro 
or variable declarations and definitions the above code would compile 
just fine.

You can put a preprocessor directive pretty much anywhere you like, as 
long as it's the first non-whitespace thing on the line (I think), 
you're just expected to make sure the results of processing that 
directive result in legal preprocessed sources.

Regards,
Bryn.

---x.c---
#include <stdio.h>
int main(int argc, char **argv)
{
#include "y.h"
         return 0;
}

---y.h---
int a = 2, b = 2;
printf("%d + %d = %d\n", a, b, a+b);



From mitr at volny.cz  Wed Nov  5 14:17:31 2008
From: mitr at volny.cz (Miloslav =?UTF-8?Q?Trma=C4=8D?=)
Date: Wed, 05 Nov 2008 15:17:31 +0100
Subject: Orphaning GCL
In-Reply-To: <4911A82F.2000206@redhat.com>
References: <1225663861.4906.15.camel@localhost.localdomain>
	<870180fe0811031945l662a8c6ak87d58c9485e54e8b@mail.gmail.com>
	<20081105133258.GA14366@amd.home.annexia.org>
	<870180fe0811050554x7eb9f9d7y58e8cca8a6782384@mail.gmail.com>
	<4911A82F.2000206@redhat.com>
Message-ID: <1225894651.3076.41.camel@kulicka>

Bryn M. Reeves p??e v St 05. 11. 2008 v 14:05 +0000:
> Jerry James wrote:
> > On Wed, Nov 5, 2008 at 6:32 AM, Richard W.M. Jones <rjones at redhat.com> wrote:
> >> On Mon, Nov 03, 2008 at 08:45:29PM -0700, Jerry James wrote:
> >>> int main() {
> >>> #include <unistd.h>
> >>>   return 0;
> >>> }
> >> Is it supposed to be possible to compile this?
> > 
> > No, that's not legal C.  I didn't know that, so I learned something
> > from the experience, which makes it a good one.  I sent a patch
> > upstream yesterday to fix the GCL code so it doesn't do this.
> 
> OT but.. That snippet *is* legal C, but the validity of compiling this 
> file then depends on the content of unistd.h
>From the point of the C standard, this is "not invalid" because C
doesn't say anything about unistd.h, so this might be a conforming (but
not a strictly conforming) C program.

It is not a conforming POSIX application, though: see XSI 2.2.2:
> If used, the application shall ensure that a header is included
> outside of any external declaration or definition ...
	Mirek



From loganjerry at gmail.com  Wed Nov  5 14:18:41 2008
From: loganjerry at gmail.com (Jerry James)
Date: Wed, 5 Nov 2008 07:18:41 -0700
Subject: Orphaning GCL
In-Reply-To: <4911A82F.2000206@redhat.com>
References: <1225663861.4906.15.camel@localhost.localdomain>
	<870180fe0811031945l662a8c6ak87d58c9485e54e8b@mail.gmail.com>
	<20081105133258.GA14366@amd.home.annexia.org>
	<870180fe0811050554x7eb9f9d7y58e8cca8a6782384@mail.gmail.com>
	<4911A82F.2000206@redhat.com>
Message-ID: <870180fe0811050618q45f0d2b5tc7f218e3c2b871c2@mail.gmail.com>

On Wed, Nov 5, 2008 at 7:05 AM, Bryn M. Reeves <bmr at redhat.com> wrote:
> OT but.. That snippet *is* legal C, but the validity of compiling this file
> then depends on the content of unistd.h (which if it's a "real" unistd.h
> will of course never produce legal preprocessed C...).

When I filed a bug about this, Jakub Jelinek replied:

Then GCL is buggy.  Standard headers are never meant to be included inside of a
function.  E.g. ISO C99 says in 7.1.2/4:
... "If used, a header shall be included outside of any external declaration or
definition, and it shall first be included before the first reference to any of
the functions or objects it declares, or to any of the types or macros it
defines."...

Regards,
-- 
Jerry James
http://loganjerry.googlepages.com/



From overholt at redhat.com  Wed Nov  5 14:23:47 2008
From: overholt at redhat.com (Andrew Overholt)
Date: Wed, 5 Nov 2008 09:23:47 -0500
Subject: Call for submissions for EclipseCon 2009
Message-ID: <20081105142347.GE3689@redhat.com>

Hi,

The submission system for EclipseCon 2009 is now open:

http://www.eclipsecon.org/2009/submissions?page=submissions/

The deadline is the 24th of November which is coming up very soon.

For those who don't know, EclipseCon is a great conference that is 
taking place this year from 23 - 26 March, 2009 in Santa Clara,
California.  It's the premiere North American Eclipse gathering and is
an awesome place to learn about the latest Eclipse happenings, interact
with everyone in the community and generally have a good time.

There are a variety of submission categories to choose from so read the
descriptions here:

http://wiki.eclipse.org/EclipseCon_2009_Category_Descriptions

** New for 2009 **

This year we're having a special 1 day Linux DevCon in conjunction with
the Linux Foundation.  For this one day sub-conference we are looking
for short talks, long talks, and tutorials dedicated to the intersection
of Eclipse and Linux.  We'd like to hear about Linux developments that
will affect Eclipse.  Much Eclipse development on and for Linux takes
place on "enterprise" distributions so talks discussing more bleeding
edge developments and ideas about the future of Linux technologies would
be especially welcome.  We are also interested in learning about
Linux-specific Eclipse tooling and Linux adoption of Eclipse tools - 
what's good, what's bad, what's missing?  What recent and upcoming
developments in the Linux ecosystem will affect Eclipse?  We would also              
like to hear about development, deployment, and use of Eclipse
technologies in multi-platform environments.  What are some areas where
Eclipse and Linux technologies can make more effective use of each
other?  What can Eclipse learn from Linux and other Free Software/Open
Source communities and vice versa?

Let me know if you have any questions.  I look forward to lots of great
submissions!

Thanks,

Andrew



From debarshi.ray at gmail.com  Wed Nov  5 14:29:07 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Wed, 5 Nov 2008 19:59:07 +0530
Subject: Seeking new maintainer(s) for package(s)
In-Reply-To: <645d17210811040956m7cbe7701mad0b49701e6222e5@mail.gmail.com>
References: <1225820483.24018.35.camel@luminos.localdomain>
	<645d17210811040956m7cbe7701mad0b49701e6222e5@mail.gmail.com>
Message-ID: <3170f42f0811050629t6251d858r499d002c54ca69ca@mail.gmail.com>

> I would happily be a comaintainer for emacs. Emphasis on co :)

Same here. :-)

So who will be the first maintainer?

Cheers,
Debarshi



From tcallawa at redhat.com  Wed Nov  5 14:46:35 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 05 Nov 2008 09:46:35 -0500
Subject: sox soname bump in devel (F10)
Message-ID: <1225896395.14073.104.camel@localhost.localdomain>

sox had a few F10 showstopper bugs that needed to be fixed, but
unfortunately, the upstream fixes came with a soname bump (from 0.0.0 to
1.0.0). Looking at repoquery, the following Fedora packages depend on
sox:

asterisk-voicemail (only calls out to /usr/bin/sox, does not need a
rebuild)
mozplugger (only calls out to /usr/bin/sox, does not need a rebuild)
psi (I don't think it really needs sox, the spec file has the broken
"Requires(hint): sox")

Thus, this should affect no one. I glanced quickly at a repoquery call
on rpmfusion, and it says that dvd-slideshow and uade-mod2ogg depend on
sox, but not on sox's library.

Thanks,
~spot



From jonathan.underwood at gmail.com  Wed Nov  5 14:52:18 2008
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Wed, 5 Nov 2008 14:52:18 +0000
Subject: Seeking new maintainer(s) for package(s)
In-Reply-To: <3170f42f0811050629t6251d858r499d002c54ca69ca@mail.gmail.com>
References: <1225820483.24018.35.camel@luminos.localdomain>
	<645d17210811040956m7cbe7701mad0b49701e6222e5@mail.gmail.com>
	<3170f42f0811050629t6251d858r499d002c54ca69ca@mail.gmail.com>
Message-ID: <645d17210811050652w3245cf64y468d59bf0d7b388@mail.gmail.com>

2008/11/5 Debarshi Ray <debarshi.ray at gmail.com>:
>> I would happily be a comaintainer for emacs. Emphasis on co :)
>
> Same here. :-)
>
> So who will be the first maintainer?

If you're happy to, please go ahead!



From notting at redhat.com  Wed Nov  5 14:58:48 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 5 Nov 2008 09:58:48 -0500
Subject: Detecting binaries in rpmbuild
In-Reply-To: <20081105133628.GB14366@amd.home.annexia.org>
References: <490F653E.7010508@cora.nwra.com> <1225792413.31158.0.camel@wsjoost>
	<20081105133628.GB14366@amd.home.annexia.org>
Message-ID: <20081105145848.GA6832@nostromo.devel.redhat.com>

Richard W.M. Jones (rjones at redhat.com) said: 
> > > I just discovered in a package I'm putting through review that the 
> > > upstream tar ball contains some pre-compiled binaries.  It seems like 
> > > this would be a good check for rpmbuild to run automatically before
> > > the 
> > > %build step.  Thoughts? 
> > 
> > That would kill some packages. Like all compilers that have to bootstrap
> > theirselves. 
> 
> Should compilers be carrying binary stuff in their source tarballs
> even for bootstrapping?

Well, RPM doesn't necessarily *require* that you build from source, even
though it encourages it. Otherwise it wouldn't have support for things
like nosrc rpms.

Hence, I'd agree with the person who suggested that this be an optional
check, or better done in rpmlint (which, admittedly, may not be feasible.)

Bill



From jamundso at gmail.com  Wed Nov  5 16:09:49 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Wed, 5 Nov 2008 10:09:49 -0600
Subject: OpenChange, etc.
Message-ID: <6d06ce20811050809h2016f7cep7631323fc1e9ec6c@mail.gmail.com>

Has anyone picked up the OpenChange feature (Samba4, libmapi, Heimdal)?
I'd really like access to Exchange servers that's more stable and
functional than what's available now.

Thanks,
jerry

-- 
There's plenty of youth in America - it's time we find the "fountain of smart".



From poelstra at redhat.com  Wed Nov  5 02:59:13 2008
From: poelstra at redhat.com (John Poelstra)
Date: Tue, 04 Nov 2008 18:59:13 -0800
Subject: Fedora 11 Feature process
Message-ID: <49110C01.3060604@redhat.com>

Before FESCo starts accepting features for Fedora 11, as we've done for 
each of the past releases since starting the feature process, I would 
like to collect your constructive criticism and ideas for making the 
process better.

* We will collect input from November 4, 2008 through November 11, 2008.
* I will propose that FESCo review the proposed changes to the policy at 
their meeting on November 12, 2008

Please add your comments to this page which will be used for the discussion:
https://fedoraproject.org/wiki/Features/F11PolicyReview

Thank you,
John

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From dmalcolm at redhat.com  Wed Nov  5 18:30:42 2008
From: dmalcolm at redhat.com (David Malcolm)
Date: Wed, 05 Nov 2008 13:30:42 -0500
Subject: Detecting binaries in rpmbuild
In-Reply-To: <20081105145848.GA6832@nostromo.devel.redhat.com>
References: <490F653E.7010508@cora.nwra.com> <1225792413.31158.0.camel@wsjoost>
	<20081105133628.GB14366@amd.home.annexia.org>
	<20081105145848.GA6832@nostromo.devel.redhat.com>
Message-ID: <1225909842.1970.4.camel@radiator.bos.redhat.com>


On Wed, 2008-11-05 at 09:58 -0500, Bill Nottingham wrote:
> Richard W.M. Jones (rjones at redhat.com) said: 
> > > > I just discovered in a package I'm putting through review that the 
> > > > upstream tar ball contains some pre-compiled binaries.  It seems like 
> > > > this would be a good check for rpmbuild to run automatically before
> > > > the 
> > > > %build step.  Thoughts? 
> > > 
> > > That would kill some packages. Like all compilers that have to bootstrap
> > > theirselves. 
> > 
> > Should compilers be carrying binary stuff in their source tarballs
> > even for bootstrapping?
> 
> Well, RPM doesn't necessarily *require* that you build from source, even
> though it encourages it. Otherwise it wouldn't have support for things
> like nosrc rpms.
> 
> Hence, I'd agree with the person who suggested that this be an optional
> check, or better done in rpmlint (which, admittedly, may not be feasible.)

Looks like this is already in bz as:
https://bugzilla.redhat.com/show_bug.cgi?id=232982
but CLOSED WONTFIX with this (comment #2)

"Short version: if there's a patch, I can have a look, but it's unlikely
I will
personally spend time on this anytime soon (and no promises about later either);
it's quite a bit of work for a smallish gain which can be also argued to be
harmful, depending on opinion.

Feel free to reopen here if you disagree and want to try convince me otherwise
(preferably with patches included ;)), or in upstream Trac
(http://rpmlint.zarb.org) if you want other rpmlint devs' opinions."





From loganjerry at gmail.com  Wed Nov  5 19:44:14 2008
From: loganjerry at gmail.com (Jerry James)
Date: Wed, 5 Nov 2008 12:44:14 -0700
Subject: How to get an SELinux policy change
Message-ID: <870180fe0811051144k72da42f5gcc8401fd5b68a7b8@mail.gmail.com>

I'm working on getting GCL to run again.  The current Debian patch
(which is enormous) fixes most problems, but not the long-running
SELinux problem that GCL has had.  I took a hint from a thread on this
list a couple of months ago.  I let make run until it crashed due to a
denied mprotect() call, did chcon -t java_exec_t on the binaries, and
restarted the make.  It completed successfully.  I can patch the
makefile to do the chcon call in the right place, but I'm worried
about getting the right security context on installation now.  First,
is using java_exec_t in this way acceptable?  Second, if so, how do I
ask for Fedora's policy to reflect that: bugzilla, request on this
list, some other list?  Thanks,
-- 
Jerry James
http://loganjerry.googlepages.com/



From Jochen at herr-schmitt.de  Wed Nov  5 19:48:05 2008
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Wed, 05 Nov 2008 20:48:05 +0100
Subject: How to get an SELinux policy change
In-Reply-To: <870180fe0811051144k72da42f5gcc8401fd5b68a7b8@mail.gmail.com>
References: <870180fe0811051144k72da42f5gcc8401fd5b68a7b8@mail.gmail.com>
Message-ID: <4911F875.6000704@herr-schmitt.de>

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

Jerry James schrieb:
> I'm working on getting GCL to run again.  The current Debian patch
> (which is enormous) fixes most problems, but not the long-running
> SELinux problem that GCL has had.  I took a hint from a thread on this
> list a couple of months ago.  I let make run until it crashed due to a
> denied mprotect() call, did chcon -t java_exec_t on the binaries, and
> restarted the make.  It completed successfully.  I can patch the
> makefile to do the chcon call in the right place, but I'm worried
> about getting the right security context on installation now.  First,
> is using java_exec_t in this way acceptable?  Second, if so, how do I
> ask for Fedora's policy to reflect that: bugzilla, request on this
> list, some other list?  Thanks,
There should be a fedora-selinux-list mailing list.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkR+FgACgkQT2AHK6txfgycTwCgtNdtJispTMx+9LdFqVz1wipC
Di4AoJPvs50m0NrSlLI+U20VqIfDb9Fz
=DywW
-----END PGP SIGNATURE-----



From j.w.r.degoede at hhs.nl  Wed Nov  5 19:52:48 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 05 Nov 2008 20:52:48 +0100
Subject: How to get an SELinux policy change
In-Reply-To: <870180fe0811051144k72da42f5gcc8401fd5b68a7b8@mail.gmail.com>
References: <870180fe0811051144k72da42f5gcc8401fd5b68a7b8@mail.gmail.com>
Message-ID: <4911F990.2010304@hhs.nl>

Jerry James wrote:
> I'm working on getting GCL to run again.  The current Debian patch
> (which is enormous) fixes most problems, but not the long-running
> SELinux problem that GCL has had.  I took a hint from a thread on this
> list a couple of months ago.  I let make run until it crashed due to a
> denied mprotect() call, did chcon -t java_exec_t on the binaries, and
> restarted the make.  It completed successfully.  I can patch the
> makefile to do the chcon call in the right place, but I'm worried
> about getting the right security context on installation now.  First,
> is using java_exec_t in this way acceptable?  Second, if so, how do I
> ask for Fedora's policy to reflect that: bugzilla, request on this
> list, some other list?  Thanks,

Just file a bugzilla against selinux-policy. Dan Walsh (the maintainer) is 
usually very fast and correct in fixing issues like this one.

Regards,

Hans



From sundaram at fedoraproject.org  Wed Nov  5 19:52:26 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 06 Nov 2008 01:22:26 +0530
Subject: How to get an SELinux policy change
In-Reply-To: <4911F875.6000704@herr-schmitt.de>
References: <870180fe0811051144k72da42f5gcc8401fd5b68a7b8@mail.gmail.com>
	<4911F875.6000704@herr-schmitt.de>
Message-ID: <4911F97A.2040009@fedoraproject.org>

Jochen Schmitt wrote:

> There should be a fedora-selinux-list mailing list.

There already is for many years now.


Rahul



From dwalsh at redhat.com  Wed Nov  5 20:20:26 2008
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Wed, 05 Nov 2008 15:20:26 -0500
Subject: How to get an SELinux policy change
In-Reply-To: <870180fe0811051144k72da42f5gcc8401fd5b68a7b8@mail.gmail.com>
References: <870180fe0811051144k72da42f5gcc8401fd5b68a7b8@mail.gmail.com>
Message-ID: <4912000A.6060605@redhat.com>

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

Jerry James wrote:
> I'm working on getting GCL to run again.  The current Debian patch
> (which is enormous) fixes most problems, but not the long-running
> SELinux problem that GCL has had.  I took a hint from a thread on this
> list a couple of months ago.  I let make run until it crashed due to a
> denied mprotect() call, did chcon -t java_exec_t on the binaries, and
> restarted the make.  It completed successfully.  I can patch the
> makefile to do the chcon call in the right place, but I'm worried
> about getting the right security context on installation now.  First,
> is using java_exec_t in this way acceptable?  Second, if so, how do I
> ask for Fedora's policy to reflect that: bugzilla, request on this
> list, some other list?  Thanks,
You can get the context of the final destination of the file using

chcon `matchpathcon -n /usr/bin/gcl` LOCALPATH/gcl

Which seems to be a fine way of doing. this.

Of course I am guessing that gcl is the name of the executable.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkSAAoACgkQrlYvE4MpobMH5gCbBjXxGYUFEsELC3bi3dOwEXEy
TxcAoOs5vcMsDnUwHPmAZP05G/76273D
=tQE6
-----END PGP SIGNATURE-----



From paul at all-the-johnsons.co.uk  Wed Nov  5 21:45:10 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Wed, 05 Nov 2008 21:45:10 +0000
Subject: Seeking new maintainer(s) for package(s)
In-Reply-To: <3170f42f0811050629t6251d858r499d002c54ca69ca@mail.gmail.com>
References: <1225820483.24018.35.camel@luminos.localdomain>
	<645d17210811040956m7cbe7701mad0b49701e6222e5@mail.gmail.com>
	<3170f42f0811050629t6251d858r499d002c54ca69ca@mail.gmail.com>
Message-ID: <1225921510.9784.0.camel@PB3.Linux>

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...

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/20081105/5d1ec128/attachment.sig>

From loganjerry at gmail.com  Thu Nov  6 00:44:16 2008
From: loganjerry at gmail.com (Jerry James)
Date: Wed, 5 Nov 2008 17:44:16 -0700
Subject: How to get an SELinux policy change
In-Reply-To: <4912000A.6060605@redhat.com>
References: <870180fe0811051144k72da42f5gcc8401fd5b68a7b8@mail.gmail.com>
	<4912000A.6060605@redhat.com>
Message-ID: <870180fe0811051644x7a49e6b9r22543f9126ebd75c@mail.gmail.com>

On Wed, Nov 5, 2008 at 1:20 PM, Daniel J Walsh <dwalsh at redhat.com> wrote:
> You can get the context of the final destination of the file using
>
> chcon `matchpathcon -n /usr/bin/gcl` LOCALPATH/gcl
>
> Which seems to be a fine way of doing. this.

So that tells me that it will have a type of bin_t.  Due to the funny
stuff that GCL is doing on the heap, SELinux won't let it run.  The
type java_exec_t is sufficiently lenient that GCL runs fine with that
type.  Is it okay to abuse the name java_exec_t in this way?  If so,
I'll bugzilla a request for the label change.

Thanks to everyone who responded.
-- 
Jerry James
http://loganjerry.googlepages.com/



From a.badger at gmail.com  Thu Nov  6 03:58:11 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 05 Nov 2008 19:58:11 -0800
Subject: PackageDB Upgrade
Message-ID: <49126B53.5020509@gmail.com>

The package Database had a major upgrade today.  Unlike the past several
updates this one doesn't have any stunning new end-user features.  What
it does have is a lot of reorganization and optimization.  You should
notice a much snappier response when loading a package page.  You might
also notice some bugs because of the restructuring of code.  If that
happens, let me know.  You can either email or find me on #fedora-admin
on irc.freenode.net.  I'm abadger1999.

Thanks,
Toshio

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

From foss.mailinglists at gmail.com  Thu Nov  6 05:04:07 2008
From: foss.mailinglists at gmail.com (=?UTF-8?B?IlNhbmthcnNoYW4gKOCmuOCmmeCnjeCmleCmsOCnjeCmt+Cmoyki?=)
Date: Thu, 06 Nov 2008 10:34:07 +0530
Subject: Detecting binaries in rpmbuild
In-Reply-To: <3170f42f0811040210g7e6ac2b1s994f6202165f9e38@mail.gmail.com>
References: <490F653E.7010508@cora.nwra.com>
	<3170f42f0811040210g7e6ac2b1s994f6202165f9e38@mail.gmail.com>
Message-ID: <49127AC7.702@gmail.com>

Debarshi Ray wrote:

> Is it not better to do it in RPMLint with appropriate exceptions?

Perhaps it would be a better option to separate this test from rpmlint
(without stretching definitions of 'lint'). Payloading binaries isn't an
RPM problem per se but more of a Packaging definition issue and,
probably optional hence.



-- 

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 shamardin at gmail.com  Thu Nov  6 06:12:34 2008
From: shamardin at gmail.com (Lev Shamardin)
Date: Thu, 06 Nov 2008 09:12:34 +0300
Subject: kernel 2.6.27 for fedora 8?
Message-ID: <49128AD2.8060704@gmail.com>

Hi all,

Not sure if this is a right place to ask, but have not found a more appropriate
place.

Is it planned to package and release kernel 2.6.27 for Fedora 8?

--
Lev.



From debarshi.ray at gmail.com  Thu Nov  6 07:29:11 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Thu, 6 Nov 2008 12:59:11 +0530
Subject: Detecting binaries in rpmbuild
In-Reply-To: <49127AC7.702@gmail.com>
References: <490F653E.7010508@cora.nwra.com>
	<3170f42f0811040210g7e6ac2b1s994f6202165f9e38@mail.gmail.com>
	<49127AC7.702@gmail.com>
Message-ID: <3170f42f0811052329u75d8ddaqf640e0804c150925@mail.gmail.com>

>> Is it not better to do it in RPMLint with appropriate exceptions?

> Perhaps it would be a better option to separate this test from rpmlint
> (without stretching definitions of 'lint'). Payloading binaries isn't an
> RPM problem per se but more of a Packaging definition issue and,
> probably optional hence.

RPMLint does check for strange file permissions within the tarballs
which are part of the SRPMs. eg., non-644 bits for a C/C++ files.

Cheers,
Debarshi



From yanmin_zhang at linux.intel.com  Thu Nov  6 09:12:22 2008
From: yanmin_zhang at linux.intel.com (Zhang, Yanmin)
Date: Thu, 06 Nov 2008 17:12:22 +0800
Subject: The source codes of nash-6.0.19-4.fc8
Message-ID: <1225962742.1685.116.camel@ymzhang>

Anyone knows where I can download the source code rpm of nash-6.0.19-4.fc8?
I can't find it under
http://download.fedora.redhat.com/pub/fedora/linux/releases/8/Everything/source/SRPMS/.

I'm debugging a boot initrd hang issue of the latest kernel with FC8.

Thanks in advance!

-yanmin




From musuruan at gmail.com  Thu Nov  6 09:24:25 2008
From: musuruan at gmail.com (Andrea Musuruane)
Date: Thu, 6 Nov 2008 10:24:25 +0100
Subject: The source codes of nash-6.0.19-4.fc8
In-Reply-To: <1225962742.1685.116.camel@ymzhang>
References: <1225962742.1685.116.camel@ymzhang>
Message-ID: <29fee02b0811060124y762489daia7fc1534100e0e51@mail.gmail.com>

2008/11/6 Zhang, Yanmin <yanmin_zhang at linux.intel.com>:
> Anyone knows where I can download the source code rpm of nash-6.0.19-4.fc8?
> I can't find it under
> http://download.fedora.redhat.com/pub/fedora/linux/releases/8/Everything/source/SRPMS/.

The source package is mkinitrd.
http://cvs.fedoraproject.org/viewvc/rpms/mkinitrd/F-8/mkinitrd.spec?revision=1.227&view=markup

Bye,

Andrea.



From rawhide at fedoraproject.org  Thu Nov  6 10:37:29 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Thu,  6 Nov 2008 10:37:29 +0000 (UTC)
Subject: rawhide report: 20081106 changes
Message-ID: <20081106103730.242381F8251@releng2.fedora.phx.redhat.com>

Compose started at Thu Nov  6 06:01:22 UTC 2008

Removed package rcssbase
Updated Packages:

anaconda-11.4.1.55-1
--------------------
* Mon Nov  3 17:00:00 2008 David Cantrell <dcantrell at redhat.com> - 11.4.1.55-1
- Revert "Make sure dialog deletions take effect sooner (#455676)." (clumens)
- Don't set up the launcher for the installer on XO (katzj)
- Whitespace cleanups for timezone.py (dcantrell)
- Do not store mount options in loaderData->instRepo (#467760) (dcantrell)
- Make sure we look up the IP address for the correct device (#469439)
  (dcantrell)
- Remove unused bool() function. (dcantrell)
- Check for required space for / on live installs (#468867) (katzj)
- Add a basic method for checking the minimal size needed for a backend
  (katzj)
- Fix typo that somehow snuck in (katzj)
- If there's no language selected, don't traceback (#469578). (clumens)
- Improve filtering of non-available groups (#469438) (katzj)
- filer.py: set defaultProduct in __init__ (hdegoede)
- Fix indentation error in filer.py (again) (hdegoede)
- Rebuild keymaps to get rid of trq.map (#469433). (clumens)
- Provide sample punch card reader script for s390x (#462953) (dcantrell)
- Fix a typo that shouldn't have even gotten though. (clumens)
- Check that the platform and product are also correct (#469367). (clumens)
- Remove cio_ignore functionality for s390x (dcantrell)
- Remove bootdisk/s390 (dcantrell)
- If method=nfs: is given, check if it's really an NFSISO install (#468885).
  (clumens)
- Get the right list elements for the iscsi text interface (#466902).
  (clumens)
- Don't traceback when displaying error messages (#469372). (clumens)
- Make sure we differentiate locked luks devs from deleted ones. (dlehman)
- Fix a typo that breaks kickstart with encryption. (#469318) (dlehman)


gcc-4.3.2-7
-----------
* Wed Nov  5 17:00:00 2008 Jakub Jelinek <jakub at redhat.com> 4.3.2-7
- update from gcc-4_3-branch
  - PRs c/35437, fortran/35680, fortran/37723, fortran/37749, fortran/37787,
	fortran/37794, fortran/37903, libfortran/37707, libfortran/37863,
	middle-end/37882, other/37897, rtl-optimization/37769, target/37909,
	target/37939, tree-optimization/37102
- fix ICE in extract_bit_field_1 (PR middle-end/37870)
- combiner fix for shifts (PR c/37924)
- fix -fdump-ipa-all -dv (PR middle-end/37858)
- fix ICE with wrong use of noreturn attribute (PR tree-optimization/37879)
- fix up --with-java_bootstrap build


glibc-2.8.90-16
---------------
* Fri Oct 31 18:00:00 2008 Jakub Jelinek <jakub at redhat.com> 2.8.90-16
- update from trunk
  - further resolver fixes
  - another dynamic TLS handling fix (#469263)
  - misc fixes (BZ#6867, BZ#6875, BZ#6919, BZ#6920, BZ#6942, BZ#6947,
		BZ#6968, BZ#6974, BZ#6980, BZ#6995)
- rebuild with newer rpm to avoid stripping
  shared libraries when they shouldn't be (#468129)

* Tue Oct 28 18:00:00 2008 Jakub Jelinek <jakub at redhat.com> 2.8.90-15
- update from trunk
  - __libc_res_nquery fixes (#466786)


gnomeradio-1.8-1.fc10
---------------------
* Fri Oct 31 18:00:00 2008 Dominik Mierzejewski <rpm at greysector.net> - 1.8-1
- update to 1.8
- drop obsolete patch
- fixes failed assertion when editing presets (bug #448315)
- preserve timestamps on doc files
- bring back ppc* builds

* Sun Mar  9 18:00:00 2008 Dominik Mierzejewski <rpm at greysector.net> - 1.7-6
- disable ppc*, because of missing gnome-media(-devel) (bug #435771)


gtk-nodoka-engine-0.7.2-1.fc10
------------------------------
* Sun Nov  2 17:00:00 2008 Martin Sourada <mso at fedoraproject.org> - 0.7.2-1
- New upstream release, fix misrender in menus on some systems (rhbz #469398)


gwave-2-11.20070514snap.fc10
----------------------------
* Wed Nov  5 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 2-11.20070514snap
- Fixed crash by adding guile-gnome-platform-devel as Requires, upstream will be notified.


hal-0.5.12-12.20081027git.fc10
------------------------------
* Wed Nov  5 17:00:00 2008 Richard Hughes <rhughes at redhat.com> - 0.5.12-10.20081027git
- Add a small FDI file to match OLPC devices so we can remap the keyboard.

* Wed Nov  5 17:00:00 2008 Matthew Garrett <mjg at redhat.com> - 0.5.12-11.20081027git
- Add support for the memstick bus

* Wed Nov  5 17:00:00 2008 Jeremy Katz <katzj at redhat.com> - 0.5.12-12.20081027git
- Fix up OLPC detection with regard to what's in the upstream kernel


kdebase-workspace-4.1.2-11.fc10
-------------------------------
* Tue Nov  4 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.2-11
- add workaround for ldap issue


kernel-2.6.27.4-79.fc10
-----------------------
* Mon Nov  3 17:00:00 2008 Matthew Garrett <mjg at redhat.com> 2.6.27.4-79
- linux-2.6-toshiba-acpi-update.patch: backport from 2.6.28
  * Adds support for rfkill control of Bluetooth (#437091)
- linux-2.6-dmi-autoload.patch: backport DMI autoloading from 2.6.28
  * Fixes autoloading of Macbook Pro Nvidia backlight driver (#462409)

* Mon Nov  3 17:00:00 2008 Matthew Garrett <mjg at redhat.com> 2.6.27.4-75
- linux-2.6-pciehp-update.patch
  * Update pciehp driver to support autoloading and listening for events
- linux-2.6-defaults-pciehp.patch
  * Enable passive mode by default
- Build acpiphp in statically
- disable-p4-cpufreq-ui.patch
  * Remove the UI from the p4-clockmod code, but allow it to be used in-kernel

* Mon Nov  3 17:00:00 2008 Eric Paris <eparis at redhat.com> 2.6.27.4-76
- Fix selinux oops on ppc64 due to empty tty_files list (#469079)

* Mon Nov  3 17:00:00 2008 Dave Airlie <airlied at redhat.com> 2.6.27.4-73
- drm-modesetting-radeon.patch: fix modeset reporting for pm-utils

* Mon Nov  3 17:00:00 2008 Dave Airlie <airlied at redhat.com> 2.6.27.4-72
- backport upstream fixes to make 64-bit Intel GEM useable (#469584)

* Fri Oct 31 18:00:00 2008 Dave Airlie <airlied at redhat.com> 2.6.27.4-69
- radeon: fix out of bounds VRAM access - hopefully fixes the corruption

* Fri Oct 31 18:00:00 2008 Chuck Ebbert <cebbert at redhat.com> 2.6.27.4-71
- Fix overflow in libata when using large disks.

* Fri Oct 31 18:00:00 2008 Chuck Ebbert <cebbert at redhat.com> 2.6.27.4-70
- Silence bogus MTRR warning when running in vmware (#468845)
- Remove xen dependencies patch, now upstream and not needed in Fedora.


mkinitrd-6.0.70-1.fc10
----------------------
* Tue Nov  4 17:00:00 2008 Peter Jones <pjones at redhat.com> - 6.0.70-1
- Get rid of glib usage in libbdevid, since it's huge and not used much
  (Patch from Pascal Terjan)
- For text plymouth plugin for live initrds (katzj)
- Fix erroneous qpushd's (lxo, #469611)
- Handle raidstat contents better (lxo, #465542)
- Fix logic in stabilizedHash (#466607)
- Get rid of CVS stuff in the Makefile (notting)
- Fix firmware path in the resultant initrd (#377921)
- Hide the splash screen when booting fails (#460606)
- Make scsi waiting happen on any device with a scsi modalias.


ntfs-3g-1.5012-4.fc10
---------------------

sox-14.1.0-5.20081105cvs.fc10
-----------------------------
* Wed Nov  5 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 14.1.0-5.20081105cvs
- forgot to add libtool as a BR

* Wed Nov  5 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 14.1.0-4.20081105cvs
- update to 20081105 cvs checkout (fixes many bugs, no longer creates _fmt_*.so.*)
- move _fmt_*.so to main package so support for file formats no longer requires devel


system-config-date-1.9.34-1.fc10
--------------------------------
* Wed Nov  5 17:00:00 2008 Nils Philippsen <nils at redhat.com> - 1.9.34-1
- avoid map traceback on non-geographic timezones (#467231)


yaboot-1.3.14-6.fc10
--------------------
* Wed Nov  5 17:00:00 2008 Roman Rakus <rrakus at redhat.com> - 1.3.14-6
- Changed kernel load base address
  Resolves: #468492


Summary:
Added Packages: 0
Removed Packages: 1
Modified Packages: 14
Broken deps for i386
----------------------------------------------------------
	rcsslogplayer-12.1.2-1.fc10.i386 requires librcssbase.so.0
	rcsslogplayer-12.1.2-1.fc10.i386 requires librcssnet.so.1
	rcssserver-12.1.4-1.fc10.i386 requires librcssgz.so.1
	rcssserver-12.1.4-1.fc10.i386 requires librcssbase.so.0
	rcssserver-12.1.4-1.fc10.i386 requires librcssconfparser.so.2
	rcssserver-12.1.4-1.fc10.i386 requires librcssnet.so.1
	rcssserver-12.1.4-1.fc10.i386 requires librcsserror.so.0
	rcssserver-12.1.4-1.fc10.i386 requires librcsslib.so.0
	rcssserver-devel-12.1.4-1.fc10.i386 requires rcssbase-devel



Broken deps for x86_64
----------------------------------------------------------
	rcsslogplayer-12.1.2-1.fc10.i386 requires librcssbase.so.0
	rcsslogplayer-12.1.2-1.fc10.i386 requires librcssnet.so.1
	rcsslogplayer-12.1.2-1.fc10.x86_64 requires librcssbase.so.0()(64bit)
	rcsslogplayer-12.1.2-1.fc10.x86_64 requires librcssnet.so.1()(64bit)
	rcssserver-12.1.4-1.fc10.i386 requires librcssgz.so.1
	rcssserver-12.1.4-1.fc10.i386 requires librcssbase.so.0
	rcssserver-12.1.4-1.fc10.i386 requires librcssconfparser.so.2
	rcssserver-12.1.4-1.fc10.i386 requires librcssnet.so.1
	rcssserver-12.1.4-1.fc10.i386 requires librcsserror.so.0
	rcssserver-12.1.4-1.fc10.i386 requires librcsslib.so.0
	rcssserver-12.1.4-1.fc10.x86_64 requires librcssconfparser.so.2()(64bit)
	rcssserver-12.1.4-1.fc10.x86_64 requires librcssgz.so.1()(64bit)
	rcssserver-12.1.4-1.fc10.x86_64 requires librcsserror.so.0()(64bit)
	rcssserver-12.1.4-1.fc10.x86_64 requires librcsslib.so.0()(64bit)
	rcssserver-12.1.4-1.fc10.x86_64 requires librcssbase.so.0()(64bit)
	rcssserver-12.1.4-1.fc10.x86_64 requires librcssnet.so.1()(64bit)
	rcssserver-devel-12.1.4-1.fc10.i386 requires rcssbase-devel
	rcssserver-devel-12.1.4-1.fc10.x86_64 requires rcssbase-devel



Broken deps for ppc
----------------------------------------------------------
	rcsslogplayer-12.1.2-1.fc10.ppc requires librcssbase.so.0
	rcsslogplayer-12.1.2-1.fc10.ppc requires librcssnet.so.1
	rcsslogplayer-12.1.2-1.fc10.ppc64 requires librcssbase.so.0()(64bit)
	rcsslogplayer-12.1.2-1.fc10.ppc64 requires librcssnet.so.1()(64bit)
	rcssserver-12.1.4-1.fc10.ppc requires librcssgz.so.1
	rcssserver-12.1.4-1.fc10.ppc requires librcssbase.so.0
	rcssserver-12.1.4-1.fc10.ppc requires librcssconfparser.so.2
	rcssserver-12.1.4-1.fc10.ppc requires librcssnet.so.1
	rcssserver-12.1.4-1.fc10.ppc requires librcsserror.so.0
	rcssserver-12.1.4-1.fc10.ppc requires librcsslib.so.0
	rcssserver-12.1.4-1.fc10.ppc64 requires librcssconfparser.so.2()(64bit)
	rcssserver-12.1.4-1.fc10.ppc64 requires librcssgz.so.1()(64bit)
	rcssserver-12.1.4-1.fc10.ppc64 requires librcsserror.so.0()(64bit)
	rcssserver-12.1.4-1.fc10.ppc64 requires librcsslib.so.0()(64bit)
	rcssserver-12.1.4-1.fc10.ppc64 requires librcssbase.so.0()(64bit)
	rcssserver-12.1.4-1.fc10.ppc64 requires librcssnet.so.1()(64bit)
	rcssserver-devel-12.1.4-1.fc10.ppc requires rcssbase-devel
	rcssserver-devel-12.1.4-1.fc10.ppc64 requires rcssbase-devel



Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot
	rcsslogplayer-12.1.2-1.fc10.ppc64 requires librcssbase.so.0()(64bit)
	rcsslogplayer-12.1.2-1.fc10.ppc64 requires librcssnet.so.1()(64bit)
	rcssserver-12.1.4-1.fc10.ppc64 requires librcssconfparser.so.2()(64bit)
	rcssserver-12.1.4-1.fc10.ppc64 requires librcssgz.so.1()(64bit)
	rcssserver-12.1.4-1.fc10.ppc64 requires librcsserror.so.0()(64bit)
	rcssserver-12.1.4-1.fc10.ppc64 requires librcsslib.so.0()(64bit)
	rcssserver-12.1.4-1.fc10.ppc64 requires librcssbase.so.0()(64bit)
	rcssserver-12.1.4-1.fc10.ppc64 requires librcssnet.so.1()(64bit)
	rcssserver-devel-12.1.4-1.fc10.ppc64 requires rcssbase-devel





From debarshi.ray at gmail.com  Thu Nov  6 10:52:11 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Thu, 6 Nov 2008 16:22:11 +0530
Subject: Who moved my bug?
Message-ID: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>

Of late I am often noticed changes like these on the bugs that are
assigned to me:

          What    |Removed                     |Added
----------------------------------------------------------------------------
          Keywords|                            |FutureFeature
            Status|NEW                         |ASSIGNED

The most recent example one such bug is https://bugzilla.redhat.com/469696

I can understand the "FutureFeature" keyword, but why is the status
being changed?

Thanks,
Debarshi



From opensource at till.name  Thu Nov  6 10:59:49 2008
From: opensource at till.name (Till Maas)
Date: Thu, 06 Nov 2008 11:59:49 +0100
Subject: Who moved my bug?
In-Reply-To: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>
Message-ID: <200811061200.07562.opensource@till.name>

On Thu November 6 2008, Debarshi Ray wrote:
> Of late I am often noticed changes like these on the bugs that are
> assigned to me:
>
>           What    |Removed                     |Added
> ---------------------------------------------------------------------------
>- Keywords|                            |FutureFeature
>             Status|NEW                         |ASSIGNED
>
> The most recent example one such bug is https://bugzilla.redhat.com/469696
>
> I can understand the "FutureFeature" keyword, but why is the status
> being changed?

ASSIGNED means, that the bug has been triaged, i.e. it is assigned to the 
rigth component and all necessary information is provided[1]. A member of the 
Fedora Triage Team probably did the changes to your bugs.

Regards,
Till

[1] https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow
-------------- 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/20081106/1c1a2315/attachment.sig>

From rjones at redhat.com  Thu Nov  6 11:01:42 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 6 Nov 2008 11:01:42 +0000
Subject: Automatic BuildRequires
Message-ID: <20081106110142.GA3165@amd.home.annexia.org>

[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/

This tries to find the correct set of BuildRequires automatically when
running 'rpmbuild'.  Just replace the ordinary rpmbuild command with
auto-br-rpmbuild, and it will print out a suggested set of
BuildRequires lines at the end.  For example:

$ auto-br-rpmbuild -ba mingw32-iconv.spec
[...]
Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/rjones/rpmbuild/BUILDROOT/mingw32-iconv-1.12-5.fc10.x86_64
Wrote: /home/rjones/rpmbuild/SRPMS/mingw32-iconv-1.12-5.fc10.src.rpm
Wrote: /home/rjones/rpmbuild/RPMS/noarch/mingw32-iconv-1.12-5.fc10.noarch.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.XpFhTF
+ umask 022
+ cd /home/rjones/rpmbuild/BUILD
+ cd libiconv-1.12
+ rm -rf /home/rjones/rpmbuild/BUILDROOT/mingw32-iconv-1.12-5.fc10.x86_64
+ exit 0
BuildRequires: bash = 3.2.29.fc10.x86_64
BuildRequires: binutils = 2.18.50.0.9.7.fc10.x86_64
BuildRequires: ccache = 2.4.13.fc9.x86_64
BuildRequires: coreutils = 6.12.16.fc10.x86_64
BuildRequires: diffutils = 2.8.1.21.fc9.x86_64
BuildRequires: file = 4.26.3.fc10.x86_64
BuildRequires: findutils = 1:4.4.0.1.fc10.x86_64
BuildRequires: gawk = 3.1.5.18.fc10.x86_64
BuildRequires: gcc-gfortran = 4.3.2.6.x86_64
BuildRequires: gettext = 0.17.8.fc10.x86_64
BuildRequires: glibc-common = 2.8.90.14.x86_64
BuildRequires: grep = 2.5.1a.61.fc10.x86_64
BuildRequires: gzip = 1.3.12.7.fc10.x86_64
BuildRequires: make = 1:3.81.14.fc10.x86_64
BuildRequires: mingw32-binutils = 2.18.50_20080109_2.8.fc9.x86_64
BuildRequires: mingw32-filesystem = 34.1.fc9.noarch
BuildRequires: mingw32-gcc-c++ = 4.3.2.8.fc9.x86_64
BuildRequires: mingw32-gcc = 4.3.2.8.fc9.x86_64
BuildRequires: mingw32-gettext = 0.17.6.fc9.noarch
BuildRequires: mingw32-iconv = 1.12.4.fc9.noarch
BuildRequires: mingw32-runtime = 3.15.1.1.fc9.noarch
BuildRequires: mingw32-w32api = 3.12.1.fc9.noarch
BuildRequires: net-tools = 1.60.91.fc10.x86_64
BuildRequires: sed = 4.1.5.10.fc9.x86_64
BuildRequires: tar = 2:1.20.3.fc10.x86_64

As you can see it's not perfect.  It doesn't ignore 'core' packages
which are always expected in a mock/koji build.  Also because autoconf
scripts tend to touch the C++ and Fortran compilers, even when they
are not used, it always suggests those packages.  Also it doesn't
exclude some tools like tar which are touched by rpmbuild itself.

The implementation is a simple LD_PRELOAD script that analyzes open(2)
and execve(2) system calls, a Perl script that does the analysis, and
some shell scripts to hang it all together.

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 ivazqueznet at gmail.com  Thu Nov  6 11:15:38 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Thu, 06 Nov 2008 06:15:38 -0500
Subject: Automatic BuildRequires
In-Reply-To: <20081106110142.GA3165@amd.home.annexia.org>
References: <20081106110142.GA3165@amd.home.annexia.org>
Message-ID: <1225970138.4625.15.camel@ignacio.lan>

On Thu, 2008-11-06 at 11:01 +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/
> 
> This tries to find the correct set of BuildRequires automatically when
> running 'rpmbuild'.  Just replace the ordinary rpmbuild command with
> auto-br-rpmbuild, and it will print out a suggested set of
> BuildRequires lines at the end.  For example:

I take it that it needs to be run in a system/root that already has the
appropriate packages installed?

-- 
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/20081106/f3c9c499/attachment.sig>

From rjones at redhat.com  Thu Nov  6 11:16:50 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 6 Nov 2008 11:16:50 +0000
Subject: Automatic BuildRequires
In-Reply-To: <1225970138.4625.15.camel@ignacio.lan>
References: <20081106110142.GA3165@amd.home.annexia.org>
	<1225970138.4625.15.camel@ignacio.lan>
Message-ID: <20081106111649.GB3165@amd.home.annexia.org>

On Thu, Nov 06, 2008 at 06:15:38AM -0500, Ignacio Vazquez-Abrams wrote:
> On Thu, 2008-11-06 at 11:01 +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/
> > 
> > This tries to find the correct set of BuildRequires automatically when
> > running 'rpmbuild'.  Just replace the ordinary rpmbuild command with
> > auto-br-rpmbuild, and it will print out a suggested set of
> > BuildRequires lines at the end.  For example:
> 
> I take it that it needs to be run in a system/root that already has the
> appropriate packages installed?

Yes, you just run it on a normal system.  The main idea is so you
don't have to keep submitting Koji jobs because you missed out some
BuildRequires.

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 sgrubb at redhat.com  Thu Nov  6 11:22:45 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Thu, 6 Nov 2008 06:22:45 -0500
Subject: Who moved my bug?
In-Reply-To: <200811061200.07562.opensource@till.name>
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>
	<200811061200.07562.opensource@till.name>
Message-ID: <200811060622.45203.sgrubb@redhat.com>

On Thursday 06 November 2008 05:59:49 Till Maas wrote:
> On Thu November 6 2008, Debarshi Ray wrote:
> > Of late I am often noticed changes like these on the bugs that are
> > assigned to me:
> >
> >           What    |Removed                     |Added
> > -------------------------------------------------------------------------
> >-- - Keywords|                            |FutureFeature
> >             Status|NEW                         |ASSIGNED
> >
> > The most recent example one such bug is
> > https://bugzilla.redhat.com/469696
> >
> > I can understand the "FutureFeature" keyword, but why is the status
> > being changed?
>
> ASSIGNED means, that the bug has been triaged, i.e. it is assigned to the
> rigth component and all necessary information is provided[1]. A member of
> the Fedora Triage Team probably did the changes to your bugs.

I thought they decided to use something like a "triaged" keyword so that state 
is preserved.

https://www.redhat.com/archives/fedora-test-list/2008-October/msg00221.html

-Steve



From bmr at redhat.com  Thu Nov  6 11:30:38 2008
From: bmr at redhat.com (Bryn M. Reeves)
Date: Thu, 06 Nov 2008 11:30:38 +0000
Subject: Who moved my bug?
In-Reply-To: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>
Message-ID: <4912D55E.4000909@redhat.com>

Debarshi Ray wrote:
> Of late I am often noticed changes like these on the bugs that are
> assigned to me:
> 
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>           Keywords|                            |FutureFeature
>             Status|NEW                         |ASSIGNED
> 
> The most recent example one such bug is https://bugzilla.redhat.com/469696
> 
> I can understand the "FutureFeature" keyword, but why is the status
> being changed?

As Till mentioned, having your bug ASSIGNED is a Good Thing(TM) ;)

If you want to see the details, load the bug in your browser and hit the 
  "History" link at the top right (next to the "Modified" field). This 
takes you to a page that lists every change to the bug, when it was made 
and who made it.

The table format it displays in gets somewhat chewed up when pasted into 
a mail, but following that link for your bug I can see:

poelstra at redhat.com  	2008-11-05 15:32:55 EDT
                         Keywords  	  	FutureFeature
                         Status 	                NEW    ASSIGNED


So, John added the keyword and changed the status from new -> assigned.

Regards,
Bryn.



From opensource at till.name  Thu Nov  6 11:43:38 2008
From: opensource at till.name (Till Maas)
Date: Thu, 06 Nov 2008 12:43:38 +0100
Subject: Who moved my bug?
In-Reply-To: <200811060622.45203.sgrubb@redhat.com>
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>
	<200811061200.07562.opensource@till.name>
	<200811060622.45203.sgrubb@redhat.com>
Message-ID: <200811061243.49188.opensource@till.name>

On Thu November 6 2008, Steve Grubb wrote:

> I thought they decided to use something like a "triaged" keyword so that
> state is preserved.

It was decided to keep it as it is for the time beeing:

https://fedoraproject.org/wiki/BugZappers/Meetings/Minutes-2008-Oct-07#NEW-.3EASSIGNED

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/20081106/4b46ad62/attachment.sig>

From jwboyer at gmail.com  Thu Nov  6 12:23:04 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 6 Nov 2008 07:23:04 -0500
Subject: kernel 2.6.27 for fedora 8?
In-Reply-To: <49128AD2.8060704@gmail.com>
References: <49128AD2.8060704@gmail.com>
Message-ID: <20081106122303.GA2307@yoda.jdub.homelinux.org>

On Thu, Nov 06, 2008 at 09:12:34AM +0300, Lev Shamardin wrote:
>Hi all,
>
>Not sure if this is a right place to ask, but have not found a more appropriate
>place.
>
>Is it planned to package and release kernel 2.6.27 for Fedora 8?

Most likely not.  Fedora 8 will probably get one final 2.6.26 update
and then go EOL one month after F10 comes out.

josh



From fedora at shmuelhome.mine.nu  Thu Nov  6 14:02:27 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Thu, 06 Nov 2008 16:02:27 +0200
Subject: Who moved my bug?
In-Reply-To: <200811061243.49188.opensource@till.name>
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>	<200811061200.07562.opensource@till.name>	<200811060622.45203.sgrubb@redhat.com>
	<200811061243.49188.opensource@till.name>
Message-ID: <4912F8F3.10205@shmuelhome.mine.nu>

Till Maas wrote:
> On Thu November 6 2008, Steve Grubb wrote:
>
>   
>> I thought they decided to use something like a "triaged" keyword so that
>> state is preserved.
>>     
>
> It was decided to keep it as it is for the time beeing:
>
> https://fedoraproject.org/wiki/BugZappers/Meetings/Minutes-2008-Oct-07#NEW-.3EASSIGNED
>
> Regards,
> Till
>   
I'd like to suggest that when committees reach decisions with regard to 
discussions from this list, the decision is communicated to this list.



From kevin.kofler at chello.at  Thu Nov  6 15:18:35 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 6 Nov 2008 15:18:35 +0000 (UTC)
Subject: Who moved my bug?
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>
	<200811061200.07562.opensource@till.name>
Message-ID: <loom.20081106T151546-155@post.gmane.org>

Till Maas <opensource <at> till.name> writes:
> ASSIGNED means, that the bug has been triaged, i.e. it is assigned to the 
> rigth component and all necessary information is provided[1]. A member of the 
> Fedora Triage Team probably did the changes to your bugs.

I'll also add that if you work in a team and need a status to set when you're
actively working on fixing something (so you don't duplicate work in the team),
you can use the ON_DEV status for that purpose. (KDE SIG and a few other teams
use this.) Note that this is not required, it's only a convention followed by
some team-maintained packages.

        Kevin Kofler



From jonstanley at gmail.com  Thu Nov  6 15:46:09 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Thu, 6 Nov 2008 10:46:09 -0500
Subject: Who moved my bug?
In-Reply-To: <4912F8F3.10205@shmuelhome.mine.nu>
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>
	<200811061200.07562.opensource@till.name>
	<200811060622.45203.sgrubb@redhat.com>
	<200811061243.49188.opensource@till.name>
	<4912F8F3.10205@shmuelhome.mine.nu>
Message-ID: <da159fda0811060746j4348fb08u61f2bfaa24bb7aff@mail.gmail.com>

On Thu, Nov 6, 2008 at 9:02 AM, shmuel siegel <fedora at shmuelhome.mine.nu> wrote:

> I'd like to suggest that when committees reach decisions with regard to
> discussions from this list, the decision is communicated to this list.

Since there was a decision made NOT to deviate from current policy,
then there was no need to communicate outside of the normal meeting
minutes. If we had made a change to the policy, that would have been
communicated loudly :)



From dominik at greysector.net  Thu Nov  6 16:18:31 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 6 Nov 2008 17:18:31 +0100
Subject: Who moved my bug?
In-Reply-To: <da159fda0811060746j4348fb08u61f2bfaa24bb7aff@mail.gmail.com>
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>
	<200811061200.07562.opensource@till.name>
	<200811060622.45203.sgrubb@redhat.com>
	<200811061243.49188.opensource@till.name>
	<4912F8F3.10205@shmuelhome.mine.nu>
	<da159fda0811060746j4348fb08u61f2bfaa24bb7aff@mail.gmail.com>
Message-ID: <20081106161830.GE1412@mokona.greysector.net>

On Thursday, 06 November 2008 at 16:46, Jon Stanley wrote:
> On Thu, Nov 6, 2008 at 9:02 AM, shmuel siegel <fedora at shmuelhome.mine.nu> wrote:
> 
> > I'd like to suggest that when committees reach decisions with regard to
> > discussions from this list, the decision is communicated to this list.
> 
> Since there was a decision made NOT to deviate from current policy,
> then there was no need to communicate outside of the normal meeting
> minutes. If we had made a change to the policy, that would have been
> communicated loudly :)

And the current policy is in effect since when, exactly? Is it documented?
Was it announced? I don't seem to recall anyone telling me to use ASSIGNED
if I haven't even started working on a bug.

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 opensource at till.name  Thu Nov  6 16:18:25 2008
From: opensource at till.name (Till Maas)
Date: Thu, 06 Nov 2008 17:18:25 +0100
Subject: Who moved my bug?
In-Reply-To: <loom.20081106T151546-155@post.gmane.org>
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>
	<200811061200.07562.opensource@till.name>
	<loom.20081106T151546-155@post.gmane.org>
Message-ID: <200811061718.37642.opensource@till.name>

On Thu November 6 2008, Kevin Kofler wrote:
> Till Maas <opensource <at> till.name> writes:
> > ASSIGNED means, that the bug has been triaged, i.e. it is assigned to the
> > rigth component and all necessary information is provided[1]. A member of
> > the Fedora Triage Team probably did the changes to your bugs.
>
> I'll also add that if you work in a team and need a status to set when
> you're actively working on fixing something (so you don't duplicate work in
> the team), you can use the ON_DEV status for that purpose. (KDE SIG and a
> few other teams use this.) Note that this is not required, it's only a
> convention followed by some team-maintained packages.

I updated the wiki to show 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/20081106/95be3667/attachment.sig>

From jonstanley at gmail.com  Thu Nov  6 16:30:53 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Thu, 6 Nov 2008 11:30:53 -0500
Subject: Who moved my bug?
In-Reply-To: <20081106161830.GE1412@mokona.greysector.net>
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>
	<200811061200.07562.opensource@till.name>
	<200811060622.45203.sgrubb@redhat.com>
	<200811061243.49188.opensource@till.name>
	<4912F8F3.10205@shmuelhome.mine.nu>
	<da159fda0811060746j4348fb08u61f2bfaa24bb7aff@mail.gmail.com>
	<20081106161830.GE1412@mokona.greysector.net>
Message-ID: <da159fda0811060830p5455c814x5dd1a6317f423b1@mail.gmail.com>

On Thu, Nov 6, 2008 at 11:18 AM, Dominik 'Rathann' Mierzejewski
<dominik at greysector.net> wrote:

> And the current policy is in effect since when, exactly? Is it documented?
> Was it announced? I don't seem to recall anyone telling me to use ASSIGNED
> if I haven't even started working on a bug.

Policy has been in effect since 2008/01/24, and was announced loudly
at that time.

http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20080124

http://www.redhat.com/archives/fedora-devel-announce/2008-February/msg00019.html



From opensource at till.name  Thu Nov  6 16:31:51 2008
From: opensource at till.name (Till Maas)
Date: Thu, 06 Nov 2008 17:31:51 +0100
Subject: Who moved my bug?
In-Reply-To: <20081106161830.GE1412@mokona.greysector.net>
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>
	<da159fda0811060746j4348fb08u61f2bfaa24bb7aff@mail.gmail.com>
	<20081106161830.GE1412@mokona.greysector.net>
Message-ID: <200811061732.01834.opensource@till.name>

On Thu November 6 2008, Dominik 'Rathann' Mierzejewski wrote:

> And the current policy is in effect since when, exactly? Is it documented?
> Was it announced? I don't seem to recall anyone telling me to use ASSIGNED
> if I haven't even started working on a bug.

This mail to fedora-devel-announce answers all your questions afaics:
https://www.redhat.com/archives/fedora-devel-announce/2008-March/msg00005.html

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/20081106/ac68dc88/attachment.sig>

From Jochen at herr-schmitt.de  Thu Nov  6 16:41:10 2008
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Thu, 06 Nov 2008 17:41:10 +0100
Subject: How to get an SELinux policy change
In-Reply-To: <870180fe0811051644x7a49e6b9r22543f9126ebd75c@mail.gmail.com>
References: <870180fe0811051144k72da42f5gcc8401fd5b68a7b8@mail.gmail.com>
	<4912000A.6060605@redhat.com>
	<870180fe0811051644x7a49e6b9r22543f9126ebd75c@mail.gmail.com>
Message-ID: <0ML31I-1Ky7vX0iQd-0008Ti@mrelayeu.kundenserver.de>

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

On Wed, 5 Nov 2008 17:44:16 -0700, you wrote:

>So that tells me that it will have a type of bin_t.  Due to the funny
>stuff that GCL is doing on the heap, SELinux won't let it run.  The
>type java_exec_t is sufficiently lenient that GCL runs fine with that
>type.  Is it okay to abuse the name java_exec_t in this way?  If so,
>I'll bugzilla a request for the label change.

Because you wrote, that all works fine, if you are labeled
/usr/bin/gcl with java_exec_t. I will suggest the following:

Installing the selinux-policy soruce rpm on your system and make
a rpmbuild -bp to get the sources of the SELinux reference
policy.

- From this you should search for the following files:

Java.fc
java.if
java.te

Fromt this files, you should create copies with the names:

gcl.fc
gcl.if
gcl.te

Now you should rename any occurence of 'java' into 'gcl'.

At last you should assigned the lable 'gcl_exec_t' to
/usr/bin/gcl into the gcl.fc file.

Now you should be abled to create a SELinux module which should
fix your reported mprotect-SELinux issue.

Best Regards:

Jochen Schmitt

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.9.0 (Build 397)
Charset: us-ascii

wj8DBQFJEx4/T2AHK6txfgwRAmFTAKCT+/1XGfR1G1LblKy2oNkIE5NhYgCeMMuh
PGptOsP6/3B9xdGCNBBu2B8=
=lxCm
-----END PGP SIGNATURE-----



From poelstra at redhat.com  Thu Nov  6 17:01:20 2008
From: poelstra at redhat.com (John Poelstra)
Date: Thu, 06 Nov 2008 09:01:20 -0800
Subject: Who moved my bug?
In-Reply-To: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>
Message-ID: <491322E0.9050107@redhat.com>

Debarshi Ray wrote:
> Of late I am often noticed changes like these on the bugs that are
> assigned to me:
> 
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>           Keywords|                            |FutureFeature
>             Status|NEW                         |ASSIGNED
> 
> The most recent example one such bug is https://bugzilla.redhat.com/469696
> 
> I can understand the "FutureFeature" keyword, but why is the status
> being changed?
> 

http://fedoraproject.org/wiki/BugsAndFeatureRequests#Enhancement_Requests

https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow

The "history" link is your friend: 
https://bugzilla.redhat.com/show_activity.cgi?id=469696

At the GA date of Fedora 10, all "rawhide" version bugs that are not 
package reviews, feature requests/RFEs, or Tracking bugs will be changed 
to version "10".  The FutureFeature keyword will insure that this bug 
retain the 'rawhide' version.

https://fedoraproject.org/wiki/BugZappers/HouseKeeping#Rawhide_Version

A separate announcement reminding people of this process will be going 
to fedora-devel-announce about this process soon.

John



From dbn.lists at gmail.com  Thu Nov  6 17:21:41 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Thu, 6 Nov 2008 09:21:41 -0800
Subject: Is there a way to set up gnome-screensaver or gnome-sesssion to
	autologout when idle.
In-Reply-To: <49119E5C.8070300@redhat.com>
References: <49119E5C.8070300@redhat.com>
Message-ID: <91705d080811060921y36d64668l3792f685ae781ea5@mail.gmail.com>

On Wed, Nov 5, 2008 at 5:23 AM, Daniel J Walsh <dwalsh at redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I would like to give the admin the ability to setup xguest to logout
> when the session is idle for some time period?

I don't think it's currently possible, but I think it would be pretty
easy to code up something to do this. You can check for session idle
by listening for the org.gnome.ScreenSaver.SessionIdleChanged signal
and then checking org.gnome.ScreenSaver.GetSessionIdleTime (I think)
over dbus. Then when it's been idle long enough, execute
`gnome-session-save --kill --silent'. Somebody could probably code
that up in python pretty easily and then spawn it from autostart.

--
Dan



From andrew.cagney at gmail.com  Thu Nov  6 17:25:54 2008
From: andrew.cagney at gmail.com (Andrew Cagney)
Date: Thu, 6 Nov 2008 12:25:54 -0500
Subject: Who moved my bug?
In-Reply-To: <da159fda0811060830p5455c814x5dd1a6317f423b1@mail.gmail.com>
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>
	<200811061200.07562.opensource@till.name>
	<200811060622.45203.sgrubb@redhat.com>
	<200811061243.49188.opensource@till.name>
	<4912F8F3.10205@shmuelhome.mine.nu>
	<da159fda0811060746j4348fb08u61f2bfaa24bb7aff@mail.gmail.com>
	<20081106161830.GE1412@mokona.greysector.net>
	<da159fda0811060830p5455c814x5dd1a6317f423b1@mail.gmail.com>
Message-ID: <c51b944b0811060925r69447448m8e52301f1ff67e56@mail.gmail.com>

On Thu, Nov 6, 2008 at 11:30 AM, Jon Stanley <jonstanley at gmail.com> wrote:
> On Thu, Nov 6, 2008 at 11:18 AM, Dominik 'Rathann' Mierzejewski
> <dominik at greysector.net> wrote:
>
>> And the current policy is in effect since when, exactly? Is it documented?
>> Was it announced? I don't seem to recall anyone telling me to use ASSIGNED
>> if I haven't even started working on a bug.

(oh, what the heck)

Dominik,

I'd have to agree, I'm just as puzzled by this one as you.  From my
point of view, re-defining the ASSIGNED state to mean CONFIRMED (and
taking the well defined ASSIGNED state away from developers) is
nothing short of new-speak, and, in my opinion, more likely to confuse
everyone; especially anyone familiar with bugzilla from other
projects, or even familiar with this same bugzilla but from the Red
Hat prospective (or perhaps that also changed while I wasn't looking
:-).

Looking at https://bugzilla.redhat.com/docs/en/html/lifecycle.html as
best I can tell the bugzilla-way is to just start things out in the
UNCONFIRMED state instead (it's a shame the state wasn't called
CONFIRMED, but what ever).

however, I guess all this was considered; learn something every day :-)

Andrew

> Policy has been in effect since 2008/01/24, and was announced loudly
> at that time.
>
> http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20080124
>
> http://www.redhat.com/archives/fedora-devel-announce/2008-February/msg00019.html
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From mschwendt at gmail.com  Thu Nov  6 18:23:02 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 6 Nov 2008 19:23:02 +0100
Subject: Automatic BuildRequires
In-Reply-To: <20081106110142.GA3165@amd.home.annexia.org>
References: <20081106110142.GA3165@amd.home.annexia.org>
Message-ID: <20081106192302.c2285926.mschwendt@gmail.com>

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



From Jochen at herr-schmitt.de  Thu Nov  6 18:45:31 2008
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Thu, 06 Nov 2008 19:45:31 +0100
Subject: How to get an SELinux policy change
In-Reply-To: <0ML31I-1Ky7vX0iQd-0008Ti@mrelayeu.kundenserver.de>
References: <870180fe0811051144k72da42f5gcc8401fd5b68a7b8@mail.gmail.com>	<4912000A.6060605@redhat.com>	<870180fe0811051644x7a49e6b9r22543f9126ebd75c@mail.gmail.com>
	<0ML31I-1Ky7vX0iQd-0008Ti@mrelayeu.kundenserver.de>
Message-ID: <49133B4B.3050308@herr-schmitt.de>

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

Jochen Schmitt schrieb:
> On Wed, 5 Nov 2008 17:44:16 -0700, you wrote:
>
>> So that tells me that it will have a type of bin_t.  Due to the
>> funny stuff that GCL is doing on the heap, SELinux won't let it
>> run.  The type java_exec_t is sufficiently lenient that GCL runs
>> fine with that type.  Is it okay to abuse the name java_exec_t in
>> this way?  If so, I'll bugzilla a request for the label change.
>
> Because you wrote, that all works fine, if you are labeled
> /usr/bin/gcl with java_exec_t. I will suggest the following:
>
> Installing the selinux-policy soruce rpm on your system and make a
> rpmbuild -bp to get the sources of the SELinux reference policy.
>
> - From this you should search for the following files:
>
> Java.fc java.if java.te
>
> Fromt this files, you should create copies with the names:
>
> gcl.fc gcl.if gcl.te
>
> Now you should rename any occurence of 'java' into 'gcl'.
>
> At last you should assigned the lable 'gcl_exec_t' to /usr/bin/gcl
> into the gcl.fc file.
>
> Now you should be abled to create a SELinux module which should fix
> your reported mprotect-SELinux issue.
>
> Best Regards:
>
> Jochen Schmitt
>
I have try to create a SELinux module which I have uploaded to:

http://www.herr-schmitt.de/pub/gcl/gcl.tar.gz

I home this may be helpful for the original poster.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkTO0IACgkQT2AHK6txfgylPgCggxAf+9CYR7k+CnJwxrKbWwBO
I8kAn3Gd8aJSqiJVP/xPNyNBLsb631XS
=frGz
-----END PGP SIGNATURE-----



From dominik at greysector.net  Thu Nov  6 18:38:02 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 6 Nov 2008 19:38:02 +0100
Subject: Who moved my bug?
In-Reply-To: <da159fda0811060830p5455c814x5dd1a6317f423b1@mail.gmail.com>
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>
	<200811061200.07562.opensource@till.name>
	<200811060622.45203.sgrubb@redhat.com>
	<200811061243.49188.opensource@till.name>
	<4912F8F3.10205@shmuelhome.mine.nu>
	<da159fda0811060746j4348fb08u61f2bfaa24bb7aff@mail.gmail.com>
	<20081106161830.GE1412@mokona.greysector.net>
	<da159fda0811060830p5455c814x5dd1a6317f423b1@mail.gmail.com>
Message-ID: <20081106183801.GA3363@mokona.greysector.net>

On Thursday, 06 November 2008 at 17:30, Jon Stanley wrote:
> On Thu, Nov 6, 2008 at 11:18 AM, Dominik 'Rathann' Mierzejewski
> <dominik at greysector.net> wrote:
> 
> > And the current policy is in effect since when, exactly? Is it documented?
> > Was it announced? I don't seem to recall anyone telling me to use ASSIGNED
> > if I haven't even started working on a bug.
> 
> Policy has been in effect since 2008/01/24, and was announced loudly
> at that time.
> 
> http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20080124

Sorry, not a word about "ASSIGNED" meaning CONFIRMED here. The word "ASSIGNED"
wasn't even mentioned during the meeting, unless the log is incomplete.

> http://www.redhat.com/archives/fedora-devel-announce/2008-February/msg00019.html

Therefore, I have to conclude that this change was NOT, in fact, approved
by the FESCo.

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 bpepple at fedoraproject.org  Thu Nov  6 19:36:21 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Thu, 06 Nov 2008 14:36:21 -0500
Subject: Who moved my bug?
In-Reply-To: <20081106183801.GA3363@mokona.greysector.net>
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>
	<200811061200.07562.opensource@till.name>
	<200811060622.45203.sgrubb@redhat.com>
	<200811061243.49188.opensource@till.name>
	<4912F8F3.10205@shmuelhome.mine.nu>
	<da159fda0811060746j4348fb08u61f2bfaa24bb7aff@mail.gmail.com>
	<20081106161830.GE1412@mokona.greysector.net>
	<da159fda0811060830p5455c814x5dd1a6317f423b1@mail.gmail.com>
	<20081106183801.GA3363@mokona.greysector.net>
Message-ID: <1226000181.3145.12.camel@kennedy>

On Thu, 2008-11-06 at 19:38 +0100, Dominik 'Rathann' Mierzejewski wrote:
> 
> Sorry, not a word about "ASSIGNED" meaning CONFIRMED here. The word "ASSIGNED"
> wasn't even mentioned during the meeting, unless the log is
> incomplete.

No, the IRC log is complete.  No one in FESCo (or the various member of
qa and rel-eng that weighed-in during that discuss) had any objections
about that particular part of the proposal.

> 
> > http://www.redhat.com/archives/fedora-devel-announce/2008-February/msg00019.html
> 
> Therefore, I have to conclude that this change was NOT, in fact,
> approved by the FESCo.
> 

No, as stated in the meeting summary it was approved, and has been in
effect for the last 9+ months.

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/20081106/d6a50ed5/attachment.sig>

From caillon at redhat.com  Thu Nov  6 20:09:04 2008
From: caillon at redhat.com (Christopher Aillon)
Date: Thu, 06 Nov 2008 15:09:04 -0500
Subject: OpenChange, etc.
In-Reply-To: <6d06ce20811050809h2016f7cep7631323fc1e9ec6c@mail.gmail.com>
References: <6d06ce20811050809h2016f7cep7631323fc1e9ec6c@mail.gmail.com>
Message-ID: <49134EE0.4020500@redhat.com>

Jerry Amundson wrote:
> Has anyone picked up the OpenChange feature (Samba4, libmapi, Heimdal)?
> I'd really like access to Exchange servers that's more stable and
> functional than what's available now.

Matt Barnes is investigating right now.  Obviously, not going to make 
F10 at this point, but we're evaluating things and should have a better 
feel for a potential timeline/roadmap soonish.



From dominik at greysector.net  Thu Nov  6 20:29:26 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 6 Nov 2008 21:29:26 +0100
Subject: Who moved my bug?
In-Reply-To: <1226000181.3145.12.camel@kennedy>
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>
	<200811061200.07562.opensource@till.name>
	<200811060622.45203.sgrubb@redhat.com>
	<200811061243.49188.opensource@till.name>
	<4912F8F3.10205@shmuelhome.mine.nu>
	<da159fda0811060746j4348fb08u61f2bfaa24bb7aff@mail.gmail.com>
	<20081106161830.GE1412@mokona.greysector.net>
	<da159fda0811060830p5455c814x5dd1a6317f423b1@mail.gmail.com>
	<20081106183801.GA3363@mokona.greysector.net>
	<1226000181.3145.12.camel@kennedy>
Message-ID: <20081106202925.GB3363@mokona.greysector.net>

On Thursday, 06 November 2008 at 20:36, Brian Pepple wrote:
> On Thu, 2008-11-06 at 19:38 +0100, Dominik 'Rathann' Mierzejewski wrote:
> > 
> > Sorry, not a word about "ASSIGNED" meaning CONFIRMED here. The word "ASSIGNED"
> > wasn't even mentioned during the meeting, unless the log is
> > incomplete.
> 
> No, the IRC log is complete.  No one in FESCo (or the various member of
> qa and rel-eng that weighed-in during that discuss) had any objections
> about that particular part of the proposal.

I'm surprised. I must better research who I'm voting for next time, then.

> > > http://www.redhat.com/archives/fedora-devel-announce/2008-February/msg00019.html
> > 
> > Therefore, I have to conclude that this change was NOT, in fact,
> > approved by the FESCo.
> > 
> 
> No, as stated in the meeting summary it was approved, and has been in
> effect for the last 9+ months.

Well, thanks for clearing this up, anyway.

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 loganjerry at gmail.com  Thu Nov  6 20:34:34 2008
From: loganjerry at gmail.com (Jerry James)
Date: Thu, 6 Nov 2008 13:34:34 -0700
Subject: How to get an SELinux policy change
In-Reply-To: <49133B4B.3050308@herr-schmitt.de>
References: <870180fe0811051144k72da42f5gcc8401fd5b68a7b8@mail.gmail.com>
	<4912000A.6060605@redhat.com>
	<870180fe0811051644x7a49e6b9r22543f9126ebd75c@mail.gmail.com>
	<0ML31I-1Ky7vX0iQd-0008Ti@mrelayeu.kundenserver.de>
	<49133B4B.3050308@herr-schmitt.de>
Message-ID: <870180fe0811061234h1e97bbbam3dc123a397d979ff@mail.gmail.com>

On Thu, Nov 6, 2008 at 11:45 AM, Jochen Schmitt <Jochen at herr-schmitt.de> wrote:
> I have try to create a SELinux module which I have uploaded to:
>
> http://www.herr-schmitt.de/pub/gcl/gcl.tar.gz
>
> I home this may be helpful for the original poster.

Wow, now that's what I call service with a smile!  Thank you very
much, Jochen.  I will give this a try.
-- 
Jerry James
http://loganjerry.googlepages.com/



From mw_triad at users.sourceforge.net  Thu Nov  6 21:08:46 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 06 Nov 2008 15:08:46 -0600
Subject: [REMINDER] next monday cmake 2.6.2 will be required
In-Reply-To: <200811052359.09076.neundorf@kde.org>
References: <200811052359.09076.neundorf@kde.org>
Message-ID: <gevmd1$reu$1@ger.gmane.org>

Alexander Neundorf wrote:
> in case you didn't update yet to cmake 2.6.2, please do so soon, next monday 
> it will be required, as announced two weeks ago.

This is for KDE trunk. I noticed that 2.6.2 is already in koji. Any 
plans on pushing it to updates (for F9) in the (very) near future?

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
In the beginning, there were not enough colors. -- Guy Keren



From jkeating at redhat.com  Thu Nov  6 21:34:41 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 06 Nov 2008 13:34:41 -0800
Subject: Who moved my bug?
In-Reply-To: <20081106202925.GB3363@mokona.greysector.net>
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>
	<200811061200.07562.opensource@till.name>
	<200811060622.45203.sgrubb@redhat.com>
	<200811061243.49188.opensource@till.name>
	<4912F8F3.10205@shmuelhome.mine.nu>
	<da159fda0811060746j4348fb08u61f2bfaa24bb7aff@mail.gmail.com>
	<20081106161830.GE1412@mokona.greysector.net>
	<da159fda0811060830p5455c814x5dd1a6317f423b1@mail.gmail.com>
	<20081106183801.GA3363@mokona.greysector.net>
	<1226000181.3145.12.camel@kennedy>
	<20081106202925.GB3363@mokona.greysector.net>
Message-ID: <1226007281.5146.14.camel@luminos.localdomain>

On Thu, 2008-11-06 at 21:29 +0100, Dominik 'Rathann' Mierzejewski wrote:
> I'm surprised. I must better research who I'm voting for next time,
> then.

Or you could read the logs from the numerous triage meetings where these
things were discussed, and many FESCo et al members where there as well.
Just because it doesn't come up at a meeting doesn't mean it hasn't been
discussed/considered/debated/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/20081106/c15b0e04/attachment.sig>

From ville.skytta at iki.fi  Thu Nov  6 22:14:06 2008
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Fri, 7 Nov 2008 00:14:06 +0200
Subject: Detecting binaries in rpmbuild
In-Reply-To: <3170f42f0811052329u75d8ddaqf640e0804c150925@mail.gmail.com>
References: <490F653E.7010508@cora.nwra.com> <49127AC7.702@gmail.com>
	<3170f42f0811052329u75d8ddaqf640e0804c150925@mail.gmail.com>
Message-ID: <200811070014.07246.ville.skytta@iki.fi>

On Thursday 06 November 2008, Debarshi Ray wrote:
> >> Is it not better to do it in RPMLint with appropriate exceptions?
> >
> > Perhaps it would be a better option to separate this test from rpmlint
> > (without stretching definitions of 'lint'). Payloading binaries isn't an
> > RPM problem per se but more of a Packaging definition issue and,
> > probably optional hence.
>
> RPMLint does check for strange file permissions within the tarballs
> which are part of the SRPMs. eg., non-644 bits for a C/C++ files.

Not really, IIRC.  It just checks permissions of packaged files, and some 
source files in tarballs often propagate to -debuginfo packages with 
those "strange" permissions intact, and /that/ is something it'll warn about.



From opensource at till.name  Thu Nov  6 22:22:33 2008
From: opensource at till.name (Till Maas)
Date: Thu, 06 Nov 2008 23:22:33 +0100
Subject: Detecting binaries in rpmbuild
In-Reply-To: <200811070014.07246.ville.skytta@iki.fi>
References: <490F653E.7010508@cora.nwra.com>
	<3170f42f0811052329u75d8ddaqf640e0804c150925@mail.gmail.com>
	<200811070014.07246.ville.skytta@iki.fi>
Message-ID: <200811062322.47348.opensource@till.name>

On Thu November 6 2008, Ville Skytt? wrote:

> Not really, IIRC.  It just checks permissions of packaged files, and some
> source files in tarballs often propagate to -debuginfo packages with
> those "strange" permissions intact, and /that/ is something it'll warn
> about.

What a coincidence, I noticed this today, too. But I would consider this to be 
a bug in rpmbuild, because the permissions of the files for the -debuginfo 
package should be sanitized.

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/20081106/95ef0a01/attachment.sig>

From mw_triad at users.sourceforge.net  Thu Nov  6 22:59:55 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 06 Nov 2008 16:59:55 -0600
Subject: f8 packages not upgraded by f9
Message-ID: <gevstb$qo6$1@ger.gmane.org>

While peeking at my list of orphaned packages, I noticed these, from f8:

grub-0.97-33.1.fc8.x86_64
hal-info-20080607-2.fc8.noarch

In the case of grub, it looks like the f9 distro tag isn't being 
considered as newer than f8 when the version is otherwise the same (bug?).

For hal-info, it looks suspiciously like an f8 update postdated the f9 
release and is versioned such that the f8 is "newer". I guess the 
even-newer f10 package will just "fix" this, but it's still strange.

Any thoughts?

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
In the beginning, there were not enough colors. -- Guy Keren



From nicolas.mailhot at laposte.net  Thu Nov  6 23:04:48 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 07 Nov 2008 00:04:48 +0100
Subject: Detecting binaries in rpmbuild
In-Reply-To: <200811062322.47348.opensource@till.name>
References: <490F653E.7010508@cora.nwra.com>
	<3170f42f0811052329u75d8ddaqf640e0804c150925@mail.gmail.com>
	<200811070014.07246.ville.skytta@iki.fi>
	<200811062322.47348.opensource@till.name>
Message-ID: <1226012688.8832.1.camel@arekh.okg>

Le jeudi 06 novembre 2008 ? 23:22 +0100, Till Maas a ?crit :
> On Thu November 6 2008, Ville Skytt? wrote:
> 
> > Not really, IIRC.  It just checks permissions of packaged files, and some
> > source files in tarballs often propagate to -debuginfo packages with
> > those "strange" permissions intact, and /that/ is something it'll warn
> > about.
> 
> What a coincidence, I noticed this today, too. But I would consider this to be 
> a bug in rpmbuild, because the permissions of the files for the -debuginfo 
> package should be sanitized.

Really, that's our own fault for not making %defattr(644,root,root,755)
the default and not forcing packagers to actually check what files need
special permissions in each package.

-- 
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/20081107/62c07b37/attachment.sig>

From mschwendt at gmail.com  Thu Nov  6 23:10:18 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 7 Nov 2008 00:10:18 +0100
Subject: f8 packages not upgraded by f9
In-Reply-To: <gevstb$qo6$1@ger.gmane.org>
References: <gevstb$qo6$1@ger.gmane.org>
Message-ID: <20081107001018.70a67806.mschwendt@gmail.com>

On Thu, 06 Nov 2008 16:59:55 -0600, Matthew Woehlke wrote:

> While peeking at my list of orphaned packages, I noticed these, from f8:
> 
> grub-0.97-33.1.fc8.x86_64
> hal-info-20080607-2.fc8.noarch
> 
> In the case of grub, it looks like the f9 distro tag isn't being 
> considered as newer than f8 when the version is otherwise the same (bug?).

Packaging mistake. In RPM version comparison, numbers are "higher than"
letters:

1 > a
1 > f
1 > fc9
33.1 > 33.fc9
33.1.fc8 > 33.fc9

> For hal-info, it looks suspiciously like an f8 update postdated the f9 
> release and is versioned such that the f8 is "newer". I guess the 
> even-newer f10 package will just "fix" this, but it's still strange.
> 
> Any thoughts?

Packaging mistakes. Such updates for older dist branches ought to
increase the package release at the very right:  1.fc8 --> 1.fc8.1 --> 1.fc8.2
and so on, to stay "older than" 1.fc9



From loganjerry at gmail.com  Thu Nov  6 23:15:35 2008
From: loganjerry at gmail.com (Jerry James)
Date: Thu, 6 Nov 2008 16:15:35 -0700
Subject: How to get an SELinux policy change
In-Reply-To: <49133B4B.3050308@herr-schmitt.de>
References: <870180fe0811051144k72da42f5gcc8401fd5b68a7b8@mail.gmail.com>
	<4912000A.6060605@redhat.com>
	<870180fe0811051644x7a49e6b9r22543f9126ebd75c@mail.gmail.com>
	<0ML31I-1Ky7vX0iQd-0008Ti@mrelayeu.kundenserver.de>
	<49133B4B.3050308@herr-schmitt.de>
Message-ID: <870180fe0811061515x39ef4bb6q5f06eb724f0ba431@mail.gmail.com>

On Thu, Nov 6, 2008 at 11:45 AM, Jochen Schmitt <Jochen at herr-schmitt.de> wrote:
> I have try to create a SELinux module which I have uploaded to:
>
> http://www.herr-schmitt.de/pub/gcl/gcl.tar.gz
>
> I home this may be helpful for the original poster.

Pardon my ignorance, but I have another question.  During the build
process, the gcl binary is created first, then it is executed multiple
times to create the saved images.  The build dies when the built
binary is invoked to create the images, if building on an
SElinux-enabled host.  Is there any way to use this module to solve
that problem?  It seems like this only helps postinstall.

My test SRPM is currently modifying upstream's makefile to insert
"chcon -t java_exec_t <insert name here>" to get around this problem.
Is there a better way?

Thanks again,
-- 
Jerry James
http://loganjerry.googlepages.com/



From mw_triad at users.sourceforge.net  Thu Nov  6 23:15:49 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 06 Nov 2008 17:15:49 -0600
Subject: f8 packages not upgraded by f9
In-Reply-To: <20081107001018.70a67806.mschwendt@gmail.com>
References: <gevstb$qo6$1@ger.gmane.org>
	<20081107001018.70a67806.mschwendt@gmail.com>
Message-ID: <gevtr5$qpa$2@ger.gmane.org>

Michael Schwendt wrote:
> On Thu, 06 Nov 2008 16:59:55 -0600, Matthew Woehlke wrote:
> 
>> While peeking at my list of orphaned packages, I noticed these, from f8:
>>
>> grub-0.97-33.1.fc8.x86_64
>> hal-info-20080607-2.fc8.noarch
>>
>> In the case of grub, it looks like the f9 distro tag isn't being 
>> considered as newer than f8 when the version is otherwise the same (bug?).
> 
> Packaging mistake. In RPM version comparison, numbers are "higher than"
> letters:
> 
> 1 > a
> 1 > f
> 1 > fc9
> 33.1 > 33.fc9
> 33.1.fc8 > 33.fc9

Ah, I missed that the f8 version was "33.1.fc8", not "33.fc8".

>> For hal-info, it looks suspiciously like an f8 update postdated the f9 
>> release and is versioned such that the f8 is "newer". I guess the 
>> even-newer f10 package will just "fix" this, but it's still strange.
>>
>> Any thoughts?
> 
> Packaging mistakes. Such updates for older dist branches ought to
> increase the package release at the very right:  1.fc8 --> 1.fc8.1 --> 1.fc8.2
> and so on, to stay "older than" 1.fc9

:-)

Oh, well, guess I'll wait for f10 to have versions that actually look newer.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
In the beginning, there were not enough colors. -- Guy Keren



From bpepple at fedoraproject.org  Fri Nov  7 00:15:32 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Thu, 06 Nov 2008 19:15:32 -0500
Subject: FESCo Meeting Summary for 2008-11-05
Message-ID: <1226016932.5758.3.camel@kennedy>

=== Members Present ===
* Brian Pepple          (bpepple)
* Jarod Wilson          (j-rod)
* Bill Nottingham       (notting)
* Jon Stanley           (jds2001)
* Karsten Hopp          (kick_)
* Kevin Fenzi           (nirik)

=== Members Absent ===
* Josh Boyer            (jwb)
* David Woodhouse       (dwmw2)
* Dennis Gilmore        (dgilmore)

== Summary ==
=== Features ===
      * After evaluating Empathy(1) with Colin Walters (walters) and
        Will Woods (wwoods), FESCo felt that Empathy wasn't ready at
        this time to become the default IM client for Fedora 10. This
        was due to some missing features and bugs in comparison to
        Pidgin.  The plan is to reevaluate Empathy for Fedora 11, since
        most of the current issues should be resolved for Gnome 2.26.
             1. https://fedoraproject.org/wiki/Features/Empathy
      * wwoods had a suggestion for the feature process that the Scope
        section have *specific* features that are expected, and the Test
        Plan have *specific* directions on how to ensure those features
        are present and working.

IRC log can be found at:
http://bpepple.fedorapeople.org/fesco/FESCo-2008-11-05.html

/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/20081106/fad15fee/attachment.sig>

From bpepple at fedoraproject.org  Fri Nov  7 00:30:19 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Thu, 06 Nov 2008 19:30:19 -0500
Subject: Who moved my bug?
In-Reply-To: <1226007281.5146.14.camel@luminos.localdomain>
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>
	<200811061200.07562.opensource@till.name>
	<200811060622.45203.sgrubb@redhat.com>
	<200811061243.49188.opensource@till.name>
	<4912F8F3.10205@shmuelhome.mine.nu>
	<da159fda0811060746j4348fb08u61f2bfaa24bb7aff@mail.gmail.com>
	<20081106161830.GE1412@mokona.greysector.net>
	<da159fda0811060830p5455c814x5dd1a6317f423b1@mail.gmail.com>
	<20081106183801.GA3363@mokona.greysector.net>
	<1226000181.3145.12.camel@kennedy>
	<20081106202925.GB3363@mokona.greysector.net>
	<1226007281.5146.14.camel@luminos.localdomain>
Message-ID: <1226017819.5758.11.camel@kennedy>

On Thu, 2008-11-06 at 13:34 -0800, Jesse Keating wrote:
> On Thu, 2008-11-06 at 21:29 +0100, Dominik 'Rathann' Mierzejewski wrote:
> > I'm surprised. I must better research who I'm voting for next time,
> > then.
> 
> Or you could read the logs from the numerous triage meetings where these
> things were discussed, and many FESCo et al members where there as well.
> Just because it doesn't come up at a meeting doesn't mean it hasn't been
> discussed/considered/debated/etc...

Or the thread were the proposal was originally discussed by the
community before it was brought to FESCo.

https://www.redhat.com/archives/fedora-devel-list/2008-January/msg01359.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/20081106/5e2268c3/attachment.sig>

From seandarcy2 at gmail.com  Fri Nov  7 00:41:11 2008
From: seandarcy2 at gmail.com (sean darcy)
Date: Thu, 06 Nov 2008 19:41:11 -0500
Subject: firefox, mozplugger or evince: what messes up pdf's in firefox?
Message-ID: <gf02r8$bnu$1@ger.gmane.org>

On an F10 box updated often, for the past week, if I open a pdf url in 
firefox, evince opens in sort of a separate window which is Always On 
Top (for instance, any Print dialogs can't be seen since they're 
"behind" the window). No window manager stuff ( minimize , close ). Only 
way to close is from the File menu.

I'd file a bug, especially this close to a release, but whose bug is it?

sean



From mclasen at redhat.com  Fri Nov  7 00:59:50 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 06 Nov 2008 19:59:50 -0500
Subject: firefox, mozplugger or evince: what messes up pdf's in firefox?
In-Reply-To: <gf02r8$bnu$1@ger.gmane.org>
References: <gf02r8$bnu$1@ger.gmane.org>
Message-ID: <1226019590.3468.5.camel@localhost.localdomain>

On Thu, 2008-11-06 at 19:41 -0500, sean darcy wrote:
> On an F10 box updated often, for the past week, if I open a pdf url in 
> firefox, evince opens in sort of a separate window which is Always On 
> Top (for instance, any Print dialogs can't be seen since they're 
> "behind" the window). No window manager stuff ( minimize , close ). Only 
> way to close is from the File menu.
> 
> I'd file a bug, especially this close to a release, but whose bug is it?

mozplugger



From kevin.kofler at chello.at  Fri Nov  7 01:17:38 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 7 Nov 2008 01:17:38 +0000 (UTC)
Subject: f8 packages not upgraded by f9
References: <gevstb$qo6$1@ger.gmane.org>
Message-ID: <loom.20081107T011432-71@post.gmane.org>

Matthew Woehlke <mw_triad <at> users.sourceforge.net> writes:
> While peeking at my list of orphaned packages, I noticed these, from f8:
> grub-0.97-33.1.fc8.x86_64
> hal-info-20080607-2.fc8.noarch

I already filed bugs for both of these:
https://bugzilla.redhat.com/show_bug.cgi?id=469486
https://bugzilla.redhat.com/show_bug.cgi?id=469487

The problem with grub is that the disttag was incorrectly bumped. It should have
been 33%{?dist} or 33%{?dist}.1, not 33.1%{%dist}. Now there MUST be a F9 upgrade
bumping the version to at least 33.1%{%dist} even if there are no other changes,
there's no other way to fix this.

        Kevin Kofler



From yanmin_zhang at linux.intel.com  Fri Nov  7 01:34:02 2008
From: yanmin_zhang at linux.intel.com (Zhang, Yanmin)
Date: Fri, 07 Nov 2008 09:34:02 +0800
Subject: The source codes of nash-6.0.19-4.fc8
In-Reply-To: <1225962742.1685.116.camel@ymzhang>
References: <1225962742.1685.116.camel@ymzhang>
Message-ID: <1226021642.1685.118.camel@ymzhang>


On Thu, 2008-11-06 at 17:12 +0800, Zhang, Yanmin wrote:
> Anyone knows where I can download the source code rpm of nash-6.0.19-4.fc8?
> I can't find it under
> http://download.fedora.redhat.com/pub/fedora/linux/releases/8/Everything/source/SRPMS/.
> 
> I'm debugging a boot initrd hang issue of the latest kernel with FC8.
I got it. nash source codes were merged to source rpm of mkinitrd.




From fedora at shmuelhome.mine.nu  Fri Nov  7 01:36:37 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Fri, 07 Nov 2008 03:36:37 +0200
Subject: Who moved my bug?
In-Reply-To: <1226017819.5758.11.camel@kennedy>
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>	<200811061200.07562.opensource@till.name>	<200811060622.45203.sgrubb@redhat.com>	<200811061243.49188.opensource@till.name>	<4912F8F3.10205@shmuelhome.mine.nu>	<da159fda0811060746j4348fb08u61f2bfaa24bb7aff@mail.gmail.com>	<20081106161830.GE1412@mokona.greysector.net>	<da159fda0811060830p5455c814x5dd1a6317f423b1@mail.gmail.com>	<20081106183801.GA3363@mokona.greysector.net>	<1226000181.3145.12.camel@kennedy>	<20081106202925.GB3363@mokona.greysector.net>	<1226007281.5146.14.camel@luminos.localdomain>
	<1226017819.5758.11.camel@kennedy>
Message-ID: <49139BA5.9090503@shmuelhome.mine.nu>

Brian Pepple wrote:
> Or the thread were the proposal was originally discussed by the
> community before it was brought to FESCo.
>
> https://www.redhat.com/archives/fedora-devel-list/2008-January/msg01359.html
>
> Later,
> /B
>   
Thanks for the reference. It was a pleasure reading a long thread that 
was constructive throughout. But I do want to point out two things.

1) Developers who have no interest in triage might not have watched this 
thread. In particular, they might not have realized the consequence of 
the bugzilla workflow changes. Also, as was pointed out in the thread, 
users would not understand that ASSIGNED meant something different in 
Fedora than in other open source projects. The point is that this 
discussion and decision making process occurred within a limited 
audience, not necessarily including everybody who will be affected. It 
should not be surprising that other audiences will object when they 
realize the consequences of the changes.
2) As the subject was reopened in this list and needed another committee 
discussion to close the issue, the conclusion should have been 
communicated to this list, preferably as a note to the thread that 
reopened the discussion.

That said, I really want to praise Jon for a well thought out proposal 
for improving the bugzilla workflow. Also, after the last few flame wars 
that I have watched, the entire approach to community input was refreshing.





From tgl at redhat.com  Fri Nov  7 02:00:20 2008
From: tgl at redhat.com (Tom Lane)
Date: Thu, 06 Nov 2008 21:00:20 -0500
Subject: f8 packages not upgraded by f9 
In-Reply-To: <loom.20081107T011432-71@post.gmane.org> 
References: <gevstb$qo6$1@ger.gmane.org>
	<loom.20081107T011432-71@post.gmane.org>
Message-ID: <18330.1226023220@sss.pgh.pa.us>

Kevin Kofler <kevin.kofler at chello.at> writes:
> The problem with grub is that the disttag was incorrectly bumped. It should have
> been 33%{?dist} or 33%{?dist}.1, not 33.1%{%dist}. Now there MUST be a F9 upgrade
> bumping the version to at least 33.1%{%dist} even if there are no other changes,
> there's no other way to fix this.

This seems like a relatively easy mistake to make, and one that could be
caught automatically by bodhi or some other part of the packaging
infrastructure.  Is such a test easy enough to be worth installing?

			regards, tom lane



From jkeating at redhat.com  Fri Nov  7 02:26:13 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 06 Nov 2008 18:26:13 -0800
Subject: f8 packages not upgraded by f9
In-Reply-To: <18330.1226023220@sss.pgh.pa.us>
References: <gevstb$qo6$1@ger.gmane.org>
	<loom.20081107T011432-71@post.gmane.org>
	<18330.1226023220@sss.pgh.pa.us>
Message-ID: <1226024773.5146.19.camel@luminos.localdomain>

On Thu, 2008-11-06 at 21:00 -0500, Tom Lane wrote:
> This seems like a relatively easy mistake to make, and one that could be
> caught automatically by bodhi or some other part of the packaging
> infrastructure.  Is such a test easy enough to be worth installing?

We have the start of some scripts to do automated checking of these on a
daily or on a push by push basis.  I plan on working more on these once
F10 is out the door.

-- 
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/20081106/d3715e0d/attachment.sig>

From jkeating at redhat.com  Fri Nov  7 03:19:09 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 06 Nov 2008 19:19:09 -0800
Subject: CVS Outage (now)
Message-ID: <1226027949.5146.26.camel@luminos.localdomain>

Outage Notification - 2008-11-07 03:00 UTC

There will be an outage starting at 2008-11-07 03:00 UTC, which will last
an unknown amount of time.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2008-11-07 03:00 UTC'

Affected Services:

CVS / Source Control

Reason for Outage:
Mass branching for F-10

Contact Information:
Jesse Keating <jkeating at redhat.com>

Please join #fedora-admin in irc.freenode.net or respond to this email to track
the status of this outage.

-- 
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/20081106/d330c8b8/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 jkeating at redhat.com  Fri Nov  7 03:41:20 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 06 Nov 2008 19:41:20 -0800
Subject: CVS Outage (now)
In-Reply-To: <1226027949.5146.26.camel@luminos.localdomain>
References: <1226027949.5146.26.camel@luminos.localdomain>
Message-ID: <1226029280.5146.30.camel@luminos.localdomain>

On Thu, 2008-11-06 at 19:19 -0800, Jesse Keating wrote:
> 
> There will be an outage starting at 2008-11-07 03:00 UTC, which will last
> an unknown amount of time.

Now that we've been branching, it appears that this outage should only
last a total of 2 hours.  A vast improvement from previous releases!

-- 
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/20081106/87ac60bf/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 orion at cora.nwra.com  Fri Nov  7 04:11:21 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Thu, 6 Nov 2008 21:11:21 -0700 (MST)
Subject: [REMINDER] next monday cmake 2.6.2 will be required
In-Reply-To: <gevmd1$reu$1@ger.gmane.org>
References: <200811052359.09076.neundorf@kde.org> <gevmd1$reu$1@ger.gmane.org>
Message-ID: <1393.71.208.51.222.1226031081.squirrel@www.cora.nwra.com>


On Thu, November 6, 2008 2:08 pm, Matthew Woehlke wrote:
> Alexander Neundorf wrote:
>> in case you didn't update yet to cmake 2.6.2, please do so soon, next
>> monday
>> it will be required, as announced two weeks ago.
>
> This is for KDE trunk. I noticed that 2.6.2 is already in koji. Any
> plans on pushing it to updates (for F9) in the (very) near future?

It's in testing.

https://admin.fedoraproject.org/updates/F9/FEDORA-2008-9347


-- 
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 debarshi.ray at gmail.com  Fri Nov  7 04:12:53 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Fri, 7 Nov 2008 09:42:53 +0530
Subject: libgnomecanvas owns %{_libdir}/libglade
Message-ID: <3170f42f0811062012v135f1766s4c8152cd26811383@mail.gmail.com>

I need to put a symlink in %{_libdir}/libglade/2.0/ [1] and found that
it is libgnomecanvas that owns it and not libglade in Fedora 9.

[rishi at freebook ~]$ rpm -qf /usr/lib64/libglade/
libgnomecanvas-2.20.1.1-2.fc9.x86_64
[rishi at freebook ~]$

Is this how it is supposed to be? Or is this a bug?

Cheers,
Debarshi

----
[1] https://bugzilla.redhat.com/467894



From debarshi.ray at gmail.com  Fri Nov  7 04:18:15 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Fri, 7 Nov 2008 09:48:15 +0530
Subject: Who moved my bug?
In-Reply-To: <200811061200.07562.opensource@till.name>
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>
	<200811061200.07562.opensource@till.name>
Message-ID: <3170f42f0811062018n30a28a0eg78c91107ef235303@mail.gmail.com>

> ASSIGNED means, that the bug has been triaged, i.e. it is assigned to the
> rigth component and all necessary information is provided[1]. A member of the
> Fedora Triage Team probably did the changes to your bugs.

This sounds different from the way package review submissions are
treated. The status is not changed to ASSIGNED just because someone
submitted a nicely done package.

Regards,
Debarshi



From debarshi.ray at gmail.com  Fri Nov  7 04:23:39 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Fri, 7 Nov 2008 09:53:39 +0530
Subject: CC'ed to my own bugs
Message-ID: <3170f42f0811062023uab6907cw1aa5e444377e63e5@mail.gmail.com>

Since the Bugzilla update, I find that by default I am set to be CC'ed
to a bug which is already assigned to me. This has been like this for
quite some time now, so is this how it is meant to be?

Cheers,
Debarshi



From mtasaka at ioa.s.u-tokyo.ac.jp  Fri Nov  7 04:44:53 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Fri, 07 Nov 2008 13:44:53 +0900
Subject: Who moved my bug?
In-Reply-To: <3170f42f0811062018n30a28a0eg78c91107ef235303@mail.gmail.com>
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>	<200811061200.07562.opensource@till.name>
	<3170f42f0811062018n30a28a0eg78c91107ef235303@mail.gmail.com>
Message-ID: <4913C7C5.3000406@ioa.s.u-tokyo.ac.jp>

Debarshi Ray wrote, at 11/07/2008 01:18 PM +9:00:
>> ASSIGNED means, that the bug has been triaged, i.e. it is assigned to the
>> rigth component and all necessary information is provided[1]. A member of the
>> Fedora Triage Team probably did the changes to your bugs.
> 
> This sounds different from the way package review submissions are
> treated. The status is not changed to ASSIGNED just because someone
> submitted a nicely done package.

My recognition is that currently triage team does not treat
package reviews (c.f.
https://fedoraproject.org/wiki/BugZappers/F9CleanUp#Overall_strategy )

Mamoru 



From jonstanley at gmail.com  Fri Nov  7 04:52:18 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Thu, 6 Nov 2008 23:52:18 -0500
Subject: Who moved my bug?
In-Reply-To: <3170f42f0811062018n30a28a0eg78c91107ef235303@mail.gmail.com>
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>
	<200811061200.07562.opensource@till.name>
	<3170f42f0811062018n30a28a0eg78c91107ef235303@mail.gmail.com>
Message-ID: <da159fda0811062052l5cca3a64yd7fbae06125b0f2f@mail.gmail.com>

On Thu, Nov 6, 2008 at 11:18 PM, Debarshi Ray <debarshi.ray at gmail.com> wrote:

> This sounds different from the way package review submissions are
> treated. The status is not changed to ASSIGNED just because someone
> submitted a nicely done package.

Indeed not.  Due to an existing process that semi-works being in place
for package reviews, it was also agreed that we wouldn't touch them.
If that policy were not in place, we would indeed be changing them to
ASSIGNED if someone submitted something with a spec and SRPM location
:)

There *is* a package review SIG that's getting going, and I'd like to
discuss with them how we can help (I've had some preliminary
discussions with tibbs a few months back)



From jonstanley at gmail.com  Fri Nov  7 05:05:13 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Fri, 7 Nov 2008 00:05:13 -0500
Subject: Who moved my bug?
In-Reply-To: <49139BA5.9090503@shmuelhome.mine.nu>
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>
	<da159fda0811060746j4348fb08u61f2bfaa24bb7aff@mail.gmail.com>
	<20081106161830.GE1412@mokona.greysector.net>
	<da159fda0811060830p5455c814x5dd1a6317f423b1@mail.gmail.com>
	<20081106183801.GA3363@mokona.greysector.net>
	<1226000181.3145.12.camel@kennedy>
	<20081106202925.GB3363@mokona.greysector.net>
	<1226007281.5146.14.camel@luminos.localdomain>
	<1226017819.5758.11.camel@kennedy>
	<49139BA5.9090503@shmuelhome.mine.nu>
Message-ID: <da159fda0811062105p26353f0eja5f0481c41414ebe@mail.gmail.com>

On Thu, Nov 6, 2008 at 8:36 PM, shmuel siegel <fedora at shmuelhome.mine.nu> wrote:

> in other open source projects. The point is that this discussion an
> decision making process occurred within a limited audience, not necessarily

How is fedora-devel a "limited" audience? Many of the major
maintainers weighed in on that thread.

> including everybody who will be affected. It should not be surprising that
> other audiences will object when they realize the consequences of the
> changes.

Are there concrete changes that you could suggest to how to actively
involve more people? I'm all ears.

> 2) As the subject was reopened in this list and needed another committee
> discussion to close the issue, the conclusion should have been communicated
> to this list, preferably as a note to the thread that reopened the
> discussion.

It actually came up on fedora-test-list, where the majority of
discussions like this take place.  The reason that the discussion of
the workflow proposal was done on f-devel is precisely to engage a
wider audience than that of f-t-l

The meeting minutes of the triage meeting are always posted to f-t-l
by the wonderful John Poelstra. And in a private email, someone
mentioned that the discussion was held in private. All of the triage
meetings are open to any interested party, they occur on Tuesdays at
1500UTC in #fedora-meeting on irc.freenode.net

> That said, I really want to praise Jon for a well thought out proposal for
> improving the bugzilla workflow. Also, after the last few flame wars that I
> have watched, the entire approach to community input was refreshing.

Thanks!  No one is perfect. If you have ways that I could improve,
please feel free to let me know :)



From martin.langhoff at gmail.com  Fri Nov  7 06:13:38 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Fri, 7 Nov 2008 01:13:38 -0500
Subject: Anaconda installs OOM with selinux-policy-targeted rpm from F9
	updates
Message-ID: <46a038f90811062213i35d243a9xfac6b0d0bd8aab47@mail.gmail.com>

One the last rounds of testing the new release of OLPCXS, I rebuilt it
with fresh packages from F9 update and started testing the installer.
Funny thing, the install did not complete -- instead, the machine
would switch off after spending a few minutes trying to install
selinux-policy-targeted.

After a few attempts to diagnose the problem, I managed to see vmstat
go all the way down to almost 0 memory just before the machine turned
itself off. This particular machine has ~980MB RAM available to the
OS. Tested on another machine with a proper 1GB memory, vmstat hit
bottom at ~10MB free while installing selinux-policy-targeted but
quickly recovered.

I know I've installed earlier F9 based spins on machines with 512 MB
of physical RAM so this seems like a fairly bad regression, specially
considering that I'll soon need to install this on a machine with
256MB RAM.

So I suspect we have 2 problems

 - Selinux-policy-targeted instalation seems to have balooned into a
memory hog between f9-release and f9-updates

 - Anaconda OOMs without a warning or useful message to the user

Has anyone else seen this? Diagnostics to recommend? I can
successfully log anything to disk until moments before the OOM
shutdown.

Will post version numbers of the selinux rpm tomorrow when I get back
in front of the offending machine and installer image. Apologies for
the vagueness :-)

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  Fri Nov  7 06:44:42 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 06 Nov 2008 22:44:42 -0800
Subject: CVS Outage (now)
In-Reply-To: <1226029280.5146.30.camel@luminos.localdomain>
References: <1226027949.5146.26.camel@luminos.localdomain>
	<1226029280.5146.30.camel@luminos.localdomain>
Message-ID: <1226040282.5146.39.camel@luminos.localdomain>

On Thu, 2008-11-06 at 19:41 -0800, Jesse Keating wrote:
> On Thu, 2008-11-06 at 19:19 -0800, Jesse Keating wrote:
> > 
> > There will be an outage starting at 2008-11-07 03:00 UTC, which will last
> > an unknown amount of time.
> 
> Now that we've been branching, it appears that this outage should only
> last a total of 2 hours.  A vast improvement from previous releases!
> 

The outage is now over.  If you find that your package has not been
branched for F-10, or otherwise you find problems with the branching,
please contact us in #fedora-admin on freenode IRC, or file a ticket
with our Trac instance https://fedorahosted.org/fedora-infrastructure/

Cheers!

-- 
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/20081106/db3c1ece/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 a.badger at gmail.com  Fri Nov  7 07:14:36 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 06 Nov 2008 23:14:36 -0800
Subject: CC'ed to my own bugs
In-Reply-To: <3170f42f0811062023uab6907cw1aa5e444377e63e5@mail.gmail.com>
References: <3170f42f0811062023uab6907cw1aa5e444377e63e5@mail.gmail.com>
Message-ID: <4913EADC.9030901@gmail.com>

Debarshi Ray wrote:
> Since the Bugzilla update, I find that by default I am set to be CC'ed
> to a bug which is already assigned to me. This has been like this for
> quite some time now, so is this how it is meant to be?
> 
This is likely due to a requested feature for the pkgdb.  It's to enable
comaintainer to more easily reassign the bug and still remain on the CC
list.  Is this causing problems (like duplicate messages) or is it just
something that you noticed that was different?

-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/20081106/1f7c2284/attachment.sig>

From fedora at shmuelhome.mine.nu  Fri Nov  7 07:35:48 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Fri, 07 Nov 2008 09:35:48 +0200
Subject: Who moved my bug?
In-Reply-To: <da159fda0811062105p26353f0eja5f0481c41414ebe@mail.gmail.com>
References: <3170f42f0811060252lf34c70fk9f1a644bf4969b5b@mail.gmail.com>	<da159fda0811060746j4348fb08u61f2bfaa24bb7aff@mail.gmail.com>	<20081106161830.GE1412@mokona.greysector.net>	<da159fda0811060830p5455c814x5dd1a6317f423b1@mail.gmail.com>	<20081106183801.GA3363@mokona.greysector.net>	<1226000181.3145.12.camel@kennedy>	<20081106202925.GB3363@mokona.greysector.net>	<1226007281.5146.14.camel@luminos.localdomain>	<1226017819.5758.11.camel@kennedy>	<49139BA5.9090503@shmuelhome.mine.nu>
	<da159fda0811062105p26353f0eja5f0481c41414ebe@mail.gmail.com>
Message-ID: <4913EFD4.4090605@shmuelhome.mine.nu>

Jon Stanley wrote:
> How is fedora-devel a "limited" audience? Many of the major
> maintainers weighed in on that thread.
>   
.....
> Are there concrete changes that you could suggest to how to actively
> involve more people? I'm all ears.
>
>
>   
The following is said in hind-sight. I have no reason to believe that I 
would have done anything any different.

This list is limited in the sense that it is only developers/packagers 
and a few lurkers like me. This change also affects bug reporters so 
test-list should have been notified (I am not saying that it wasn't, I 
don't know). There is also the much larger group of Fedora users, some 
of whom report bugs. I am not sure how many of them would even read a 
Fedora list but probably a fair portion of them are subscribed to 
fedora-announce.

But the real reason that I referred to the audience as a limited 
audience was because the title of the post referred to a change in the 
triage procedures. Since I am not a triager, I probably would not have 
(carefully) read such a post. Using bugzilla in the title, instead of 
triage, might have brought in a larger, more diverse, audience. It is 
debatable whether or not you would have had a productive discussion in a 
larger discussion; so maybe your initial procedure was best.

A short announcement should have been made at the end saying that such 
and such are the tangible changes to bugzilla that FESCo approved. Then 
wait to see the fireworks
>> .....It should not be surprising that
>> other audiences will object when they realize the consequences of the
>> changes.
>>     
Also,
>> 2) As the subject was reopened ... and needed another committee
>> discussion to close the issue, the conclusion should have been communicated
>> to [the posting] list, preferably as a note to the thread that reopened the
>> discussion.
>>     
>
>   
> No one is perfect. If you have ways that I could improve,
> please feel free to let me know :)
>
>   
Really, I was very pleased with the handling. I just felt that it would 
have been better had there been closure on the threads that discussed 
the issue.




From kanarip at kanarip.com  Fri Nov  7 08:22:04 2008
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Fri, 07 Nov 2008 09:22:04 +0100
Subject: CVS Outage (now)
In-Reply-To: <1226040282.5146.39.camel@luminos.localdomain>
References: <1226027949.5146.26.camel@luminos.localdomain>	<1226029280.5146.30.camel@luminos.localdomain>
	<1226040282.5146.39.camel@luminos.localdomain>
Message-ID: <4913FAAC.7070701@kanarip.com>

Jesse Keating wrote:
> On Thu, 2008-11-06 at 19:41 -0800, Jesse Keating wrote:
>> On Thu, 2008-11-06 at 19:19 -0800, Jesse Keating wrote:
>>> There will be an outage starting at 2008-11-07 03:00 UTC, which will last
>>> an unknown amount of time.
>> Now that we've been branching, it appears that this outage should only
>> last a total of 2 hours.  A vast improvement from previous releases!
>>

Wow!

> 
> The outage is now over.  If you find that your package has not been
> branched for F-10, or otherwise you find problems with the branching,
> please contact us in #fedora-admin on freenode IRC, or file a ticket
> with our Trac instance https://fedorahosted.org/fedora-infrastructure/
> 

Congratulations, it seems to have been running just a little smoother 
this time, huh?

;-)

Kind regards,

Jeroen van Meeuwen
-kanarip



From debarshi.ray at gmail.com  Fri Nov  7 09:11:50 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Fri, 7 Nov 2008 14:41:50 +0530
Subject: CC'ed to my own bugs
In-Reply-To: <4913EADC.9030901@gmail.com>
References: <3170f42f0811062023uab6907cw1aa5e444377e63e5@mail.gmail.com>
	<4913EADC.9030901@gmail.com>
Message-ID: <3170f42f0811070111t7abe3ca2jd3a482c806fec8ad@mail.gmail.com>

>> Since the Bugzilla update, I find that by default I am set to be CC'ed
>> to a bug which is already assigned to me. This has been like this for
>> quite some time now, so is this how it is meant to be?

> This is likely due to a requested feature for the pkgdb.  It's to enable
> comaintainer to more easily reassign the bug and still remain on the CC
> list.

I see.

> Is this causing problems (like duplicate messages) or is it just
> something that you noticed that was different?

I have not paid much attention to whether it is generating duplicate
messages or not, so I would say it is just something that I noticed
was different.

Thanks,
Debarshi



From yersinia.spiros at gmail.com  Fri Nov  7 10:25:43 2008
From: yersinia.spiros at gmail.com (yersinia)
Date: Fri, 7 Nov 2008 11:25:43 +0100
Subject: How to get an SELinux policy change
In-Reply-To: <870180fe0811061515x39ef4bb6q5f06eb724f0ba431@mail.gmail.com>
References: <870180fe0811051144k72da42f5gcc8401fd5b68a7b8@mail.gmail.com>
	<4912000A.6060605@redhat.com>
	<870180fe0811051644x7a49e6b9r22543f9126ebd75c@mail.gmail.com>
	<0ML31I-1Ky7vX0iQd-0008Ti@mrelayeu.kundenserver.de>
	<49133B4B.3050308@herr-schmitt.de>
	<870180fe0811061515x39ef4bb6q5f06eb724f0ba431@mail.gmail.com>
Message-ID: <b086760e0811070225w45a2e95lf61db56378a3628b@mail.gmail.com>

Do look useful this docu ?

http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules



On Fri, Nov 7, 2008 at 12:15 AM, Jerry James <loganjerry at gmail.com> wrote:

> On Thu, Nov 6, 2008 at 11:45 AM, Jochen Schmitt <Jochen at herr-schmitt.de>
> wrote:
> > I have try to create a SELinux module which I have uploaded to:
> >
> > http://www.herr-schmitt.de/pub/gcl/gcl.tar.gz
> >
> > I home this may be helpful for the original poster.
>
> Pardon my ignorance, but I have another question.  During the build
> process, the gcl binary is created first, then it is executed multiple
> times to create the saved images.  The build dies when the built
> binary is invoked to create the images, if building on an
> SElinux-enabled host.  Is there any way to use this module to solve
> that problem?  It seems like this only helps postinstall.
>
> My test SRPM is currently modifying upstream's makefile to insert
> "chcon -t java_exec_t <insert name here>" to get around this problem.
> Is there a better way?
>
> Thanks again,
> --
> Jerry James
> http://loganjerry.googlepages.com/
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081107/7b22f02e/attachment.htm>

From atkac at redhat.com  Fri Nov  7 12:09:05 2008
From: atkac at redhat.com (Adam Tkac)
Date: Fri, 7 Nov 2008 13:09:05 +0100
Subject: End of bind-chroot-admin script
Message-ID: <20081107120905.GA3188@evileye.atkac.englab.brq.redhat.com>

Hi all,

bind-chroot-admin script should sync BIND configuration files to
chroot() directory. It was written with good intention but it has
never worked correctly in all situations. There is long history with
many broken configurations and urgent severity bugs.

I'm going to remove this script from Fedora 11 (it is part of Fedora/RHEL
only, no other distro uses it). After removal, "standard" chroot
structure will be created when you install bind-chroot package. It
will contain all needed files for running named in chroot but admin
shall move needed configuration files to chroot manually. Do you have
any comments?

Regards, Adam

-- 
Adam Tkac, Red Hat, Inc.



From dominik at greysector.net  Fri Nov  7 11:17:28 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Fri, 7 Nov 2008 12:17:28 +0100
Subject: Who moved my bug?
In-Reply-To: <1226017819.5758.11.camel@kennedy>
References: <200811061243.49188.opensource@till.name>
	<4912F8F3.10205@shmuelhome.mine.nu>
	<da159fda0811060746j4348fb08u61f2bfaa24bb7aff@mail.gmail.com>
	<20081106161830.GE1412@mokona.greysector.net>
	<da159fda0811060830p5455c814x5dd1a6317f423b1@mail.gmail.com>
	<20081106183801.GA3363@mokona.greysector.net>
	<1226000181.3145.12.camel@kennedy>
	<20081106202925.GB3363@mokona.greysector.net>
	<1226007281.5146.14.camel@luminos.localdomain>
	<1226017819.5758.11.camel@kennedy>
Message-ID: <20081107111727.GA10541@mokona.greysector.net>

On Friday, 07 November 2008 at 01:30, Brian Pepple wrote:
> On Thu, 2008-11-06 at 13:34 -0800, Jesse Keating wrote:
> > On Thu, 2008-11-06 at 21:29 +0100, Dominik 'Rathann' Mierzejewski wrote:
> > > I'm surprised. I must better research who I'm voting for next time,
> > > then.
> > 
> > Or you could read the logs from the numerous triage meetings where these
> > things were discussed, and many FESCo et al members where there as well.
> > Just because it doesn't come up at a meeting doesn't mean it hasn't been
> > discussed/considered/debated/etc...
> 
> Or the thread were the proposal was originally discussed by the
> community before it was brought to FESCo.
> 
> https://www.redhat.com/archives/fedora-devel-list/2008-January/msg01359.html

You can't expect every packager to read every mail on fedora-devel-list.
There is simply too much traffic here, not to mention the contents of any
longer discussion have little to do with the original subject.

Personally, I only glimpse over the subjects and only read (parts of) the threads
that have interesting subjects.

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 paul at city-fan.org  Fri Nov  7 11:32:46 2008
From: paul at city-fan.org (Paul Howarth)
Date: Fri, 7 Nov 2008 11:32:46 +0000
Subject: End of bind-chroot-admin script
In-Reply-To: <20081107120905.GA3188@evileye.atkac.englab.brq.redhat.com>
References: <20081107120905.GA3188@evileye.atkac.englab.brq.redhat.com>
Message-ID: <20081107113246.4127a212@metropolis.intra.city-fan.org>

On Fri, 7 Nov 2008 13:09:05 +0100
Adam Tkac <atkac at redhat.com> wrote:

> Hi all,
> 
> bind-chroot-admin script should sync BIND configuration files to
> chroot() directory. It was written with good intention but it has
> never worked correctly in all situations. There is long history with
> many broken configurations and urgent severity bugs.
> 
> I'm going to remove this script from Fedora 11 (it is part of
> Fedora/RHEL only, no other distro uses it). After removal, "standard"
> chroot structure will be created when you install bind-chroot
> package. It will contain all needed files for running named in chroot
> but admin shall move needed configuration files to chroot manually.
> Do you have any comments?

That's what I do anyway (I never used bind-chroot-admin). Worth a
mention in the release notes for people that do use it though.

Paul.



From paul at city-fan.org  Fri Nov  7 11:40:35 2008
From: paul at city-fan.org (Paul Howarth)
Date: Fri, 7 Nov 2008 11:40:35 +0000
Subject: libgnomecanvas owns %{_libdir}/libglade
In-Reply-To: <3170f42f0811062012v135f1766s4c8152cd26811383@mail.gmail.com>
References: <3170f42f0811062012v135f1766s4c8152cd26811383@mail.gmail.com>
Message-ID: <20081107114035.0402300d@metropolis.intra.city-fan.org>

On Fri, 7 Nov 2008 09:42:53 +0530
"Debarshi Ray" <debarshi.ray at gmail.com> wrote:

> I need to put a symlink in %{_libdir}/libglade/2.0/ [1] and found that
> it is libgnomecanvas that owns it and not libglade in Fedora 9.
> 
> [rishi at freebook ~]$ rpm -qf /usr/lib64/libglade/
> libgnomecanvas-2.20.1.1-2.fc9.x86_64
> [rishi at freebook ~]$
> 
> Is this how it is supposed to be? Or is this a bug?

Neither libglade nor libglade-devel include the %{_libdir}/libglade
directory or anything within it.

It's an old Gnome-1 compat package and the vast majority of people
won't have it on their systems anyway, though the same appears to apply
to its successor libglade2 as well.

Paul.



From dominik at greysector.net  Fri Nov  7 11:47:44 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Fri, 7 Nov 2008 12:47:44 +0100
Subject: Detecting binaries in rpmbuild
In-Reply-To: <1226012688.8832.1.camel@arekh.okg>
References: <490F653E.7010508@cora.nwra.com>
	<3170f42f0811052329u75d8ddaqf640e0804c150925@mail.gmail.com>
	<200811070014.07246.ville.skytta@iki.fi>
	<200811062322.47348.opensource@till.name>
	<1226012688.8832.1.camel@arekh.okg>
Message-ID: <20081107114743.GB10541@mokona.greysector.net>

On Friday, 07 November 2008 at 00:04, Nicolas Mailhot wrote:
[...]
> Really, that's our own fault for not making %defattr(644,root,root,755)
> the default and not forcing packagers to actually check what files need
> special permissions in each package.

+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 debarshi.ray at gmail.com  Fri Nov  7 11:51:28 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Fri, 7 Nov 2008 17:21:28 +0530
Subject: libgnomecanvas owns %{_libdir}/libglade
In-Reply-To: <20081107114035.0402300d@metropolis.intra.city-fan.org>
References: <3170f42f0811062012v135f1766s4c8152cd26811383@mail.gmail.com>
	<20081107114035.0402300d@metropolis.intra.city-fan.org>
Message-ID: <3170f42f0811070351x6e8a77cew605dc311b2be857b@mail.gmail.com>

> It's an old Gnome-1 compat package and the vast majority of people
> won't have it on their systems anyway, though the same appears to apply
> to its successor libglade2 as well.

You mean libgnomecanvas-2.20.1.1-2.fc9.x86_64 is an old Gnome-1 compat
package? Or were you referring to something else?

Cheers,
Debarshi



From paul at city-fan.org  Fri Nov  7 11:55:33 2008
From: paul at city-fan.org (Paul Howarth)
Date: Fri, 7 Nov 2008 11:55:33 +0000
Subject: libgnomecanvas owns %{_libdir}/libglade
In-Reply-To: <3170f42f0811070351x6e8a77cew605dc311b2be857b@mail.gmail.com>
References: <3170f42f0811062012v135f1766s4c8152cd26811383@mail.gmail.com>
	<20081107114035.0402300d@metropolis.intra.city-fan.org>
	<3170f42f0811070351x6e8a77cew605dc311b2be857b@mail.gmail.com>
Message-ID: <20081107115533.57ecbe76@metropolis.intra.city-fan.org>

On Fri, 7 Nov 2008 17:21:28 +0530
"Debarshi Ray" <debarshi.ray at gmail.com> wrote:

> > It's an old Gnome-1 compat package and the vast majority of people
> > won't have it on their systems anyway, though the same appears to
> > apply to its successor libglade2 as well.
> 
> You mean libgnomecanvas-2.20.1.1-2.fc9.x86_64 is an old Gnome-1 compat
> package? Or were you referring to something else?

I was referring to libglade.

Paul.



From debarshi.ray at gmail.com  Fri Nov  7 12:13:15 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Fri, 7 Nov 2008 17:43:15 +0530
Subject: libgnomecanvas owns %{_libdir}/libglade
In-Reply-To: <20081107114035.0402300d@metropolis.intra.city-fan.org>
References: <3170f42f0811062012v135f1766s4c8152cd26811383@mail.gmail.com>
	<20081107114035.0402300d@metropolis.intra.city-fan.org>
Message-ID: <3170f42f0811070413g7e90fddq989ff28dfb05b964@mail.gmail.com>

>> I need to put a symlink in %{_libdir}/libglade/2.0/ [1] and found that
>> it is libgnomecanvas that owns it and not libglade in Fedora 9.
>>
>> [rishi at freebook ~]$ rpm -qf /usr/lib64/libglade/
>> libgnomecanvas-2.20.1.1-2.fc9.x86_64
>> [rishi at freebook ~]$
>>
>> Is this how it is supposed to be? Or is this a bug?

> Neither libglade nor libglade-devel include the %{_libdir}/libglade
> directory or anything within it.

Maybe I was not very clear. I used "libglade" to mean the any of the
libglade packages -- 1.0 and 2.0.

My main objective is to know whether a package that is going to put a
symlink in %{_libdir}/libglade/2.0/ would need to have 'Requires:
libgnomecanvas' because, if not anything, it looks a bit odd to me
since it looks related to libglade.

Cheerio,
Debarshi



From rawhide at fedoraproject.org  Fri Nov  7 12:16:17 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri,  7 Nov 2008 12:16:17 +0000 (UTC)
Subject: rawhide report: 20081107 changes
Message-ID: <20081107121617.D238F1F8252@releng2.fedora.phx.redhat.com>

Compose started at Fri Nov  7 06:01:25 UTC 2008

New package rcssbase
        Robocup 2D Soccer Simulation Base Library
Updated Packages:

PackageKit-0.3.9-4.fc10
-----------------------
* Wed Nov  5 17:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.9-4
- Increase the timeout for cleaning up unused transactions. Due to a bug
  in the PkClient library the new TID was not being requested, and the old
  TID was being re-used. This gave a DBUS error if the user spent longer than
  five seconds entering the password the very first time they used PackageKit
  to do an authentication.
  Apply a simple patch to mitigate this, as a more invasive (and correct)
  patch is upstream. A new release will follow in f10-updates. Fixes rh#469950


cherokee-0.10.0-2.fc10
----------------------
* Thu Nov  6 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.10.0-2
- do not package spawn-fcgi files (lighttpd-fastcgi provides them)
  Resolves bz 469947
- get rid of rpath in compiled files

* Fri Oct 31 18:00:00 2008 Pavel Lisy <pavel.lisy at gmail.com> - 0.10.0-1
- updated to 0.10.0


cryptsetup-luks-1.0.6-6.fc10
----------------------------
* Thu Oct 30 18:00:00 2008 Milan Broz <mbroz at redhat.com> - 1.0.6-6
- Wipe old fs headers to not confuse blkid (#468062)


fedora-logos-10.0.1-2.fc10
--------------------------
* Thu Nov  6 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 10.0.1-2
- pull .git files out of source tarball to keep SRPM size down

* Thu Nov  6 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 10.0.1-1
- fix broken xfce4 icon (bz 470353)
- own directories for clean removal (bz 169282)


mock-0.9.13-1.fc10
------------------
* Thu Nov  6 17:00:00 2008 Jesse Keating <jkeating at redhat.com> - 0.9.13-1
- Add configs for F10 (jkeating)


torque-2.1.10-6.fc10
--------------------
* Wed Apr 16 18:00:00 2008 Garrick Staples <garrick at usc.edu> 2.1.10-6
- add alternatives system


Summary:
Added Packages: 1
Removed Packages: 0
Modified Packages: 6









Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot





From paul at city-fan.org  Fri Nov  7 12:52:02 2008
From: paul at city-fan.org (Paul Howarth)
Date: Fri, 7 Nov 2008 12:52:02 +0000
Subject: libgnomecanvas owns %{_libdir}/libglade
In-Reply-To: <3170f42f0811070413g7e90fddq989ff28dfb05b964@mail.gmail.com>
References: <3170f42f0811062012v135f1766s4c8152cd26811383@mail.gmail.com>
	<20081107114035.0402300d@metropolis.intra.city-fan.org>
	<3170f42f0811070413g7e90fddq989ff28dfb05b964@mail.gmail.com>
Message-ID: <20081107125202.65fb0ff4@metropolis.intra.city-fan.org>

On Fri, 7 Nov 2008 17:43:15 +0530
"Debarshi Ray" <debarshi.ray at gmail.com> wrote:

> >> I need to put a symlink in %{_libdir}/libglade/2.0/ [1] and found
> >> that it is libgnomecanvas that owns it and not libglade in Fedora
> >> 9.
> >>
> >> [rishi at freebook ~]$ rpm -qf /usr/lib64/libglade/
> >> libgnomecanvas-2.20.1.1-2.fc9.x86_64
> >> [rishi at freebook ~]$
> >>
> >> Is this how it is supposed to be? Or is this a bug?
> 
> > Neither libglade nor libglade-devel include the %{_libdir}/libglade
> > directory or anything within it.
> 
> Maybe I was not very clear. I used "libglade" to mean the any of the
> libglade packages -- 1.0 and 2.0.
> 
> My main objective is to know whether a package that is going to put a
> symlink in %{_libdir}/libglade/2.0/ would need to have 'Requires:
> libgnomecanvas' because, if not anything, it looks a bit odd to me
> since it looks related to libglade.

You either need to own the directory yourself (probably the best bet of
you don't need libgnomecanvas otherwise), or add a dep on
libgnomecanvas, and add a comment in the spec that libgnomecanvas is
only needed for ownership of %{_libdir}/libglade{,/2.0}.

There's actually another option, which would be to add a dependency on
the directory itself, which would be satisfied by any package that
claimed ownership of that directory. That approach is frowned upon
though because it means that depsolvers need to download the large
filelists data to find an appropriate package to resolve the dependency.

Paul.



From mschwendt at gmail.com  Fri Nov  7 13:06:17 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 7 Nov 2008 14:06:17 +0100
Subject: CVS Outage (now)
In-Reply-To: <1226040282.5146.39.camel@luminos.localdomain>
References: <1226027949.5146.26.camel@luminos.localdomain>
	<1226029280.5146.30.camel@luminos.localdomain>
	<1226040282.5146.39.camel@luminos.localdomain>
Message-ID: <20081107140617.0d19e682.mschwendt@gmail.com>

On Thu, 06 Nov 2008 22:44:42 -0800, Jesse Keating wrote:

> On Thu, 2008-11-06 at 19:41 -0800, Jesse Keating wrote:
> > On Thu, 2008-11-06 at 19:19 -0800, Jesse Keating wrote:
> > > 
> > > There will be an outage starting at 2008-11-07 03:00 UTC, which will last
> > > an unknown amount of time.
> > 
> > Now that we've been branching, it appears that this outage should only
> > last a total of 2 hours.  A vast improvement from previous releases!
> > 
> 
> The outage is now over.  If you find that your package has not been
> branched for F-10, or otherwise you find problems with the branching,
> please contact us in #fedora-admin on freenode IRC, or file a ticket
> with our Trac instance https://fedorahosted.org/fedora-infrastructure/

devel still tags for dist-f10-updates-candidate instead of dist-f11



From mtasaka at ioa.s.u-tokyo.ac.jp  Fri Nov  7 13:08:10 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Fri, 07 Nov 2008 22:08:10 +0900
Subject: libgnomecanvas owns %{_libdir}/libglade
In-Reply-To: <3170f42f0811070413g7e90fddq989ff28dfb05b964@mail.gmail.com>
References: <3170f42f0811062012v135f1766s4c8152cd26811383@mail.gmail.com>	<20081107114035.0402300d@metropolis.intra.city-fan.org>
	<3170f42f0811070413g7e90fddq989ff28dfb05b964@mail.gmail.com>
Message-ID: <49143DBA.7090407@ioa.s.u-tokyo.ac.jp>

Debarshi Ray wrote, at 11/07/2008 09:13 PM +9:00:
>>> I need to put a symlink in %{_libdir}/libglade/2.0/ [1] and found that
>>> it is libgnomecanvas that owns it and not libglade in Fedora 9.
>>>
>>> [rishi at freebook ~]$ rpm -qf /usr/lib64/libglade/
>>> libgnomecanvas-2.20.1.1-2.fc9.x86_64
>>> [rishi at freebook ~]$
>>>
>>> Is this how it is supposed to be? Or is this a bug?
> 
>> Neither libglade nor libglade-devel include the %{_libdir}/libglade
>> directory or anything within it.
> 
> Maybe I was not very clear. I used "libglade" to mean the any of the
> libglade packages -- 1.0 and 2.0.
> 
> My main objective is to know whether a package that is going to put a
> symlink in %{_libdir}/libglade/2.0/ would need to have 'Requires:
> libgnomecanvas' because, if not anything, it looks a bit odd to me
> since it looks related to libglade.

libgnomecanvas has the dependency on libglade-2.0.so.0,
libgnomecanvas.src has "BuildRequires: libglade2-devel", so
I guess %_libdir/libglade{,/2.0} must be owned by libglade2. not
by libgnomecanvas.

Regards,
Mamoru



From pbrobinson at gmail.com  Fri Nov  7 13:11:09 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Fri, 7 Nov 2008 13:11:09 +0000
Subject: CVS Outage (now)
In-Reply-To: <1226040282.5146.39.camel@luminos.localdomain>
References: <1226027949.5146.26.camel@luminos.localdomain>
	<1226029280.5146.30.camel@luminos.localdomain>
	<1226040282.5146.39.camel@luminos.localdomain>
Message-ID: <5256d0b0811070511s1e9a3057n47fb0b6d98e3a827@mail.gmail.com>

>> > There will be an outage starting at 2008-11-07 03:00 UTC, which will last
>> > an unknown amount of time.
>>
>> Now that we've been branching, it appears that this outage should only
>> last a total of 2 hours.  A vast improvement from previous releases!
>>
>
> The outage is now over.  If you find that your package has not been
> branched for F-10, or otherwise you find problems with the branching,
> please contact us in #fedora-admin on freenode IRC, or file a ticket
> with our Trac instance https://fedorahosted.org/fedora-infrastructure/

Should we get the F-10 pulled when we do a 'cvs update' against
packages. It doesn't seem to pull it.

Peter



From paul at city-fan.org  Fri Nov  7 13:11:03 2008
From: paul at city-fan.org (Paul Howarth)
Date: Fri, 7 Nov 2008 13:11:03 +0000
Subject: libgnomecanvas owns %{_libdir}/libglade
In-Reply-To: <49143DBA.7090407@ioa.s.u-tokyo.ac.jp>
References: <3170f42f0811062012v135f1766s4c8152cd26811383@mail.gmail.com>
	<20081107114035.0402300d@metropolis.intra.city-fan.org>
	<3170f42f0811070413g7e90fddq989ff28dfb05b964@mail.gmail.com>
	<49143DBA.7090407@ioa.s.u-tokyo.ac.jp>
Message-ID: <20081107131103.55560a91@metropolis.intra.city-fan.org>

On Fri, 07 Nov 2008 22:08:10 +0900
Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> wrote:

> Debarshi Ray wrote, at 11/07/2008 09:13 PM +9:00:
> >>> I need to put a symlink in %{_libdir}/libglade/2.0/ [1] and found
> >>> that it is libgnomecanvas that owns it and not libglade in Fedora
> >>> 9.
> >>>
> >>> [rishi at freebook ~]$ rpm -qf /usr/lib64/libglade/
> >>> libgnomecanvas-2.20.1.1-2.fc9.x86_64
> >>> [rishi at freebook ~]$
> >>>
> >>> Is this how it is supposed to be? Or is this a bug?
> > 
> >> Neither libglade nor libglade-devel include the %{_libdir}/libglade
> >> directory or anything within it.
> > 
> > Maybe I was not very clear. I used "libglade" to mean the any of the
> > libglade packages -- 1.0 and 2.0.
> > 
> > My main objective is to know whether a package that is going to put
> > a symlink in %{_libdir}/libglade/2.0/ would need to have 'Requires:
> > libgnomecanvas' because, if not anything, it looks a bit odd to me
> > since it looks related to libglade.
> 
> libgnomecanvas has the dependency on libglade-2.0.so.0,
> libgnomecanvas.src has "BuildRequires: libglade2-devel", so
> I guess %_libdir/libglade{,/2.0} must be owned by libglade2. not
> by libgnomecanvas.

You might expect so, but it's not the case:

$ rpm -qf /usr/lib64/libglade/{,2.0/}
libgnomecanvas-2.20.1.1-2.fc9.x86_64
libgnomecanvas-2.20.1.1-2.fc9.x86_64

Paul.



From mtasaka at ioa.s.u-tokyo.ac.jp  Fri Nov  7 13:15:07 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Fri, 07 Nov 2008 22:15:07 +0900
Subject: libgnomecanvas owns %{_libdir}/libglade
In-Reply-To: <20081107131103.55560a91@metropolis.intra.city-fan.org>
References: <3170f42f0811062012v135f1766s4c8152cd26811383@mail.gmail.com>	<20081107114035.0402300d@metropolis.intra.city-fan.org>	<3170f42f0811070413g7e90fddq989ff28dfb05b964@mail.gmail.com>	<49143DBA.7090407@ioa.s.u-tokyo.ac.jp>
	<20081107131103.55560a91@metropolis.intra.city-fan.org>
Message-ID: <49143F5B.7070905@ioa.s.u-tokyo.ac.jp>

Paul Howarth wrote, at 11/07/2008 10:11 PM +9:00:
>>> My main objective is to know whether a package that is going to put
>>> a symlink in %{_libdir}/libglade/2.0/ would need to have 'Requires:
>>> libgnomecanvas' because, if not anything, it looks a bit odd to me
>>> since it looks related to libglade.
>> libgnomecanvas has the dependency on libglade-2.0.so.0,
>> libgnomecanvas.src has "BuildRequires: libglade2-devel", so
>> I guess %_libdir/libglade{,/2.0} must be owned by libglade2. not
>> by libgnomecanvas.
> 
> You might expect so, but it's not the case:
> 
> $ rpm -qf /usr/lib64/libglade/{,2.0/}
> libgnomecanvas-2.20.1.1-2.fc9.x86_64
> libgnomecanvas-2.20.1.1-2.fc9.x86_64


So what I am saying is that this is a bug in both libglade2
and libgnomecanvas.

c.f some similar example:
    https://bugzilla.redhat.com/show_bug.cgi?id=469491

Regards,
Mamoru



From sven at lank.es  Fri Nov  7 13:16:42 2008
From: sven at lank.es (Sven Lankes)
Date: Fri, 7 Nov 2008 14:16:42 +0100
Subject: CVS Outage (now)
In-Reply-To: <5256d0b0811070511s1e9a3057n47fb0b6d98e3a827@mail.gmail.com>
References: <1226027949.5146.26.camel@luminos.localdomain>
	<1226029280.5146.30.camel@luminos.localdomain>
	<1226040282.5146.39.camel@luminos.localdomain>
	<5256d0b0811070511s1e9a3057n47fb0b6d98e3a827@mail.gmail.com>
Message-ID: <20081107131642.GF22088@killefiz>

On Fri, Nov 07, 2008 at 01:11:09PM +0000, Peter Robinson wrote:

> Should we get the F-10 pulled when we do a 'cvs update' against
> packages. It doesn't seem to pull it.

You need to use 'cvs update -d' - cvs update doesn't include new
directories by default.

-- 
sven === jabber/xmpp: sven at lankes.net



From loganjerry at gmail.com  Fri Nov  7 14:10:08 2008
From: loganjerry at gmail.com (Jerry James)
Date: Fri, 7 Nov 2008 07:10:08 -0700
Subject: How to get an SELinux policy change
In-Reply-To: <b086760e0811070225w45a2e95lf61db56378a3628b@mail.gmail.com>
References: <870180fe0811051144k72da42f5gcc8401fd5b68a7b8@mail.gmail.com>
	<4912000A.6060605@redhat.com>
	<870180fe0811051644x7a49e6b9r22543f9126ebd75c@mail.gmail.com>
	<0ML31I-1Ky7vX0iQd-0008Ti@mrelayeu.kundenserver.de>
	<49133B4B.3050308@herr-schmitt.de>
	<870180fe0811061515x39ef4bb6q5f06eb724f0ba431@mail.gmail.com>
	<b086760e0811070225w45a2e95lf61db56378a3628b@mail.gmail.com>
Message-ID: <870180fe0811070610r1ba81a3dnc0bb1f74f468b450@mail.gmail.com>

2008/11/7 yersinia <yersinia.spiros at gmail.com>:
> Do look useful this docu ?
>
> http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules

Thank you.  That is a very useful document.  However, it does not
appear to answer my question.  I need a non-default security context
for binaries that are both built and executed in the %build script,
when the policy module has not yet been installed.  It appears to me
that there are only two ways to accomplish this: keep abusing
java_exec_t like I have been, or get a GCL policy incorporated into
selinux-policy* prior to building GCL.  Am I wrong?  Is there some
other option?  Does anyone have any guidance to offer me on which
option to pursue?  Thanks,
-- 
Jerry James
http://loganjerry.googlepages.com/



From paul at city-fan.org  Fri Nov  7 14:17:25 2008
From: paul at city-fan.org (Paul Howarth)
Date: Fri, 7 Nov 2008 14:17:25 +0000
Subject: How to get an SELinux policy change
In-Reply-To: <870180fe0811070610r1ba81a3dnc0bb1f74f468b450@mail.gmail.com>
References: <870180fe0811051144k72da42f5gcc8401fd5b68a7b8@mail.gmail.com>
	<4912000A.6060605@redhat.com>
	<870180fe0811051644x7a49e6b9r22543f9126ebd75c@mail.gmail.com>
	<0ML31I-1Ky7vX0iQd-0008Ti@mrelayeu.kundenserver.de>
	<49133B4B.3050308@herr-schmitt.de>
	<870180fe0811061515x39ef4bb6q5f06eb724f0ba431@mail.gmail.com>
	<b086760e0811070225w45a2e95lf61db56378a3628b@mail.gmail.com>
	<870180fe0811070610r1ba81a3dnc0bb1f74f468b450@mail.gmail.com>
Message-ID: <20081107141725.42e14fa0@metropolis.intra.city-fan.org>

On Fri, 7 Nov 2008 07:10:08 -0700
"Jerry James" <loganjerry at gmail.com> wrote:

> 2008/11/7 yersinia <yersinia.spiros at gmail.com>:
> > Do look useful this docu ?
> >
> > http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules
> 
> Thank you.  That is a very useful document.  However, it does not
> appear to answer my question.  I need a non-default security context
> for binaries that are both built and executed in the %build script,
> when the policy module has not yet been installed.  It appears to me
> that there are only two ways to accomplish this: keep abusing
> java_exec_t like I have been, or get a GCL policy incorporated into
> selinux-policy* prior to building GCL.  Am I wrong?  Is there some
> other option?  Does anyone have any guidance to offer me on which
> option to pursue?  Thanks,

Move the discussion to fedora-selinux-list where it'll get Dan's
attention more quickly and probably result in a GCL policy being
incorporated into the main selinux-policy package.

Paul.



From mclasen at redhat.com  Fri Nov  7 14:22:20 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 07 Nov 2008 09:22:20 -0500
Subject: libgnomecanvas owns %{_libdir}/libglade
In-Reply-To: <3170f42f0811070413g7e90fddq989ff28dfb05b964@mail.gmail.com>
References: <3170f42f0811062012v135f1766s4c8152cd26811383@mail.gmail.com>
	<20081107114035.0402300d@metropolis.intra.city-fan.org>
	<3170f42f0811070413g7e90fddq989ff28dfb05b964@mail.gmail.com>
Message-ID: <1226067740.3417.1.camel@localhost.localdomain>

On Fri, 2008-11-07 at 17:43 +0530, Debarshi Ray wrote:
> >> I need to put a symlink in %{_libdir}/libglade/2.0/ [1] and found that
> >> it is libgnomecanvas that owns it and not libglade in Fedora 9.
> >>
> >> [rishi at freebook ~]$ rpm -qf /usr/lib64/libglade/
> >> libgnomecanvas-2.20.1.1-2.fc9.x86_64
> >> [rishi at freebook ~]$
> >>
> >> Is this how it is supposed to be? Or is this a bug?
> 
> > Neither libglade nor libglade-devel include the %{_libdir}/libglade
> > directory or anything within it.
> 
> Maybe I was not very clear. I used "libglade" to mean the any of the
> libglade packages -- 1.0 and 2.0.
> 
> My main objective is to know whether a package that is going to put a
> symlink in %{_libdir}/libglade/2.0/ would need to have 'Requires:
> libgnomecanvas' because, if not anything, it looks a bit odd to me
> since it looks related to libglade.


 It would probably be better if libglade2 owned %{libdir}/libglade and
%{libdir}/libglade/2.0. Can you take care of that ?



From tibbs at math.uh.edu  Fri Nov  7 14:35:52 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 07 Nov 2008 08:35:52 -0600
Subject: CVS Outage (now)
In-Reply-To: <20081107131642.GF22088@killefiz>
References: <1226027949.5146.26.camel@luminos.localdomain>
	<1226029280.5146.30.camel@luminos.localdomain>
	<1226040282.5146.39.camel@luminos.localdomain>
	<5256d0b0811070511s1e9a3057n47fb0b6d98e3a827@mail.gmail.com>
	<20081107131642.GF22088@killefiz>
Message-ID: <ufazlkba9iv.fsf@epithumia.math.uh.edu>

>>>>> "SL" == Sven Lankes <sven at lank.es> writes:

SL> You need to use 'cvs update -d' - cvs update doesn't include new
SL> directories by default.

It's a good idea to do something like

echo "update -dPA" >> ~/.cvsrc

 - J<



From tibbs at math.uh.edu  Fri Nov  7 14:38:02 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 07 Nov 2008 08:38:02 -0600
Subject: CC'ed to my own bugs
In-Reply-To: <3170f42f0811062023uab6907cw1aa5e444377e63e5@mail.gmail.com>
References: <3170f42f0811062023uab6907cw1aa5e444377e63e5@mail.gmail.com>
Message-ID: <ufavduza9f9.fsf@epithumia.math.uh.edu>

>>>>> "DR" == Debarshi Ray <debarshi.ray at gmail.com> writes:

DR> Since the Bugzilla update, I find that by default I am set to be
DR> CC'ed to a bug which is already assigned to me. This has been like
DR> this for quite some time now, so is this how it is meant to be?

Bugzilla will by default auto-CC you on every bug you touch, but of
course there's a convenient place on the preferences page to turn
this off.  Under the General Preferences tab:
  Automatically add me to the CC list of bugs I change

 - J<



From paul at city-fan.org  Fri Nov  7 14:19:02 2008
From: paul at city-fan.org (Paul Howarth)
Date: Fri, 7 Nov 2008 14:19:02 +0000
Subject: libgnomecanvas owns %{_libdir}/libglade
In-Reply-To: <49143F5B.7070905@ioa.s.u-tokyo.ac.jp>
References: <3170f42f0811062012v135f1766s4c8152cd26811383@mail.gmail.com>
	<20081107114035.0402300d@metropolis.intra.city-fan.org>
	<3170f42f0811070413g7e90fddq989ff28dfb05b964@mail.gmail.com>
	<49143DBA.7090407@ioa.s.u-tokyo.ac.jp>
	<20081107131103.55560a91@metropolis.intra.city-fan.org>
	<49143F5B.7070905@ioa.s.u-tokyo.ac.jp>
Message-ID: <20081107141902.75b6eb9a@metropolis.intra.city-fan.org>

On Fri, 07 Nov 2008 22:15:07 +0900
Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> wrote:

> Paul Howarth wrote, at 11/07/2008 10:11 PM +9:00:
> >>> My main objective is to know whether a package that is going to
> >>> put a symlink in %{_libdir}/libglade/2.0/ would need to have
> >>> 'Requires: libgnomecanvas' because, if not anything, it looks a
> >>> bit odd to me since it looks related to libglade.
> >> libgnomecanvas has the dependency on libglade-2.0.so.0,
> >> libgnomecanvas.src has "BuildRequires: libglade2-devel", so
> >> I guess %_libdir/libglade{,/2.0} must be owned by libglade2. not
> >> by libgnomecanvas.
> > 
> > You might expect so, but it's not the case:
> > 
> > $ rpm -qf /usr/lib64/libglade/{,2.0/}
> > libgnomecanvas-2.20.1.1-2.fc9.x86_64
> > libgnomecanvas-2.20.1.1-2.fc9.x86_64
> 
> 
> So what I am saying is that this is a bug in both libglade2
> and libgnomecanvas.
> 
> c.f some similar example:
>     https://bugzilla.redhat.com/show_bug.cgi?id=469491

Yes, I agree.

Paul.



From dwalsh at redhat.com  Fri Nov  7 14:49:56 2008
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Fri, 07 Nov 2008 09:49:56 -0500
Subject: Anaconda installs OOM with selinux-policy-targeted rpm from F9
 updates
In-Reply-To: <46a038f90811062213i35d243a9xfac6b0d0bd8aab47@mail.gmail.com>
References: <46a038f90811062213i35d243a9xfac6b0d0bd8aab47@mail.gmail.com>
Message-ID: <49145594.4070106@redhat.com>

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

Martin Langhoff wrote:
> One the last rounds of testing the new release of OLPCXS, I rebuilt it
> with fresh packages from F9 update and started testing the installer.
> Funny thing, the install did not complete -- instead, the machine
> would switch off after spending a few minutes trying to install
> selinux-policy-targeted.
> 
> After a few attempts to diagnose the problem, I managed to see vmstat
> go all the way down to almost 0 memory just before the machine turned
> itself off. This particular machine has ~980MB RAM available to the
> OS. Tested on another machine with a proper 1GB memory, vmstat hit
> bottom at ~10MB free while installing selinux-policy-targeted but
> quickly recovered.
> 
> I know I've installed earlier F9 based spins on machines with 512 MB
> of physical RAM so this seems like a fairly bad regression, specially
> considering that I'll soon need to install this on a machine with
> 256MB RAM.
> 
> So I suspect we have 2 problems
> 
>  - Selinux-policy-targeted instalation seems to have balooned into a
> memory hog between f9-release and f9-updates
> 
>  - Anaconda OOMs without a warning or useful message to the user
> 
> Has anyone else seen this? Diagnostics to recommend? I can
> successfully log anything to disk until moments before the OOM
> shutdown.
> 
> Will post version numbers of the selinux rpm tomorrow when I get back
> in front of the offending machine and installer image. Apologies for
> the vagueness :-)
> 
> cheers,
> 
> 
> 
> m
selinux-policy-targeted is a memory hog, but it should not have changed
that drastically in updates.

Is this repeatable?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkUVZQACgkQrlYvE4MpobNfJQCgkYO4qEHY74KbRuTHrM16FgNg
F7MAn2IK03lRzhhBO4RfMSs57ysHfY/L
=QegF
-----END PGP SIGNATURE-----



From dwalsh at redhat.com  Fri Nov  7 14:53:18 2008
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Fri, 07 Nov 2008 09:53:18 -0500
Subject: How to get an SELinux policy change
In-Reply-To: <870180fe0811070610r1ba81a3dnc0bb1f74f468b450@mail.gmail.com>
References: <870180fe0811051144k72da42f5gcc8401fd5b68a7b8@mail.gmail.com>	<4912000A.6060605@redhat.com>	<870180fe0811051644x7a49e6b9r22543f9126ebd75c@mail.gmail.com>	<0ML31I-1Ky7vX0iQd-0008Ti@mrelayeu.kundenserver.de>	<49133B4B.3050308@herr-schmitt.de>	<870180fe0811061515x39ef4bb6q5f06eb724f0ba431@mail.gmail.com>	<b086760e0811070225w45a2e95lf61db56378a3628b@mail.gmail.com>
	<870180fe0811070610r1ba81a3dnc0bb1f74f468b450@mail.gmail.com>
Message-ID: <4914565E.40704@redhat.com>

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

Jerry James wrote:
> 2008/11/7 yersinia <yersinia.spiros at gmail.com>:
>> Do look useful this docu ?
>>
>> http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules
> 
> Thank you.  That is a very useful document.  However, it does not
> appear to answer my question.  I need a non-default security context
> for binaries that are both built and executed in the %build script,
> when the policy module has not yet been installed.  It appears to me
> that there are only two ways to accomplish this: keep abusing
> java_exec_t like I have been, or get a GCL policy incorporated into
> selinux-policy* prior to building GCL.  Am I wrong?  Is there some
> other option?  Does anyone have any guidance to offer me on which
> option to pursue?  Thanks,
I would go with the chcon solution you have but instead of hard coding
the java_exec_t, I would execute

You can get the context of the final destination of the file using

chcon `matchpathcon -n /usr/bin/gcl` LOCALPATH/gcl

Which seems to be a fine way of doing. this.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkUVl4ACgkQrlYvE4MpobN7FgCfQYUN5Xeui9NAYfyaDGisUqKV
hyYAoJbnNpRFq4hsVhClKDDysq+CBPJ7
=GYSP
-----END PGP SIGNATURE-----



From emmanuel.seyman at club-internet.fr  Fri Nov  7 14:55:49 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Fri, 7 Nov 2008 15:55:49 +0100
Subject: CC'ed to my own bugs
In-Reply-To: <3170f42f0811070111t7abe3ca2jd3a482c806fec8ad@mail.gmail.com>
References: <3170f42f0811062023uab6907cw1aa5e444377e63e5@mail.gmail.com>
	<4913EADC.9030901@gmail.com>
	<3170f42f0811070111t7abe3ca2jd3a482c806fec8ad@mail.gmail.com>
Message-ID: <20081107145549.GA2493@orient.maison.lan>

* Debarshi Ray [07/11/2008 11:02] :
>
> >> Since the Bugzilla update, I find that by default I am set to be CC'ed
> >> to a bug which is already assigned to me. This has been like this for
> >> quite some time now, so is this how it is meant to be?

Yes. Note that this is an upstream change, not something the maintainers
of bugzilla.redhat.com did. This is so you do not stop getting mail from
a bug simply because someone assigned it to somebody other than you.

> I have not paid much attention to whether it is generating duplicate
> messages or not, so I would say it is just something that I noticed
> was different.

You'll keep getting one mail but you'll now get it for two different
reasons instead of one.

Emmanuel



From clumens at redhat.com  Fri Nov  7 14:59:51 2008
From: clumens at redhat.com (Chris Lumens)
Date: Fri, 7 Nov 2008 09:59:51 -0500
Subject: Anaconda installs OOM with selinux-policy-targeted rpm from F9
	updates
In-Reply-To: <46a038f90811062213i35d243a9xfac6b0d0bd8aab47@mail.gmail.com>
References: <46a038f90811062213i35d243a9xfac6b0d0bd8aab47@mail.gmail.com>
Message-ID: <20081107145951.GT11925@localhost.localdomain>

>  - Anaconda OOMs without a warning or useful message to the user

I don't believe there's any way for anaconda to know this, and there's
certainly no way for us to do anything about it.

- Chris



From paul at city-fan.org  Fri Nov  7 15:02:52 2008
From: paul at city-fan.org (Paul Howarth)
Date: Fri, 7 Nov 2008 15:02:52 +0000
Subject: How to get an SELinux policy change
In-Reply-To: <4914565E.40704@redhat.com>
References: <870180fe0811051144k72da42f5gcc8401fd5b68a7b8@mail.gmail.com>
	<4912000A.6060605@redhat.com>
	<870180fe0811051644x7a49e6b9r22543f9126ebd75c@mail.gmail.com>
	<0ML31I-1Ky7vX0iQd-0008Ti@mrelayeu.kundenserver.de>
	<49133B4B.3050308@herr-schmitt.de>
	<870180fe0811061515x39ef4bb6q5f06eb724f0ba431@mail.gmail.com>
	<b086760e0811070225w45a2e95lf61db56378a3628b@mail.gmail.com>
	<870180fe0811070610r1ba81a3dnc0bb1f74f468b450@mail.gmail.com>
	<4914565E.40704@redhat.com>
Message-ID: <20081107150252.6e71748c@metropolis.intra.city-fan.org>

On Fri, 07 Nov 2008 09:53:18 -0500
Daniel J Walsh <dwalsh at redhat.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jerry James wrote:
> > 2008/11/7 yersinia <yersinia.spiros at gmail.com>:
> >> Do look useful this docu ?
> >>
> >> http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules
> > 
> > Thank you.  That is a very useful document.  However, it does not
> > appear to answer my question.  I need a non-default security context
> > for binaries that are both built and executed in the %build script,
> > when the policy module has not yet been installed.  It appears to me
> > that there are only two ways to accomplish this: keep abusing
> > java_exec_t like I have been, or get a GCL policy incorporated into
> > selinux-policy* prior to building GCL.  Am I wrong?  Is there some
> > other option?  Does anyone have any guidance to offer me on which
> > option to pursue?  Thanks,
> I would go with the chcon solution you have but instead of hard coding
> the java_exec_t, I would execute
> 
> You can get the context of the final destination of the file using
> 
> chcon `matchpathcon -n /usr/bin/gcl` LOCALPATH/gcl
> 
> Which seems to be a fine way of doing. this.

Indeed, but it needs the context type for /usr/bin/gcl to be set to
java_exec_t or equivalent in the selinux-policy package before it'll
work.

Paul.



From opensource at till.name  Fri Nov  7 15:02:59 2008
From: opensource at till.name (Till Maas)
Date: Fri, 07 Nov 2008 16:02:59 +0100
Subject: CVS Outage (now)
In-Reply-To: <ufazlkba9iv.fsf@epithumia.math.uh.edu>
References: <1226027949.5146.26.camel@luminos.localdomain>
	<20081107131642.GF22088@killefiz>
	<ufazlkba9iv.fsf@epithumia.math.uh.edu>
Message-ID: <200811071603.10243.opensource@till.name>

On Fri November 7 2008, Jason L Tibbitts III wrote:
> >>>>> "SL" == Sven Lankes <sven at lank.es> writes:
>
> SL> You need to use 'cvs update -d' - cvs update doesn't include new
> SL> directories by default.
>
> It's a good idea to do something like
>
> echo "update -dPA" >> ~/.cvsrc

Do we use sticky stuff (I do not really understand what this does) in Fedora, 
i.e. is -A useful here?

From the manpage:
-A
         Reset any sticky tags, dates, or -k options.  Does not reset
         sticky -k options on modified files.  See see node  ?Sticky  tags' in
         the CVS manual, for more information on sticky tags/dates.

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/20081107/91266759/attachment.sig>

From a.badger at gmail.com  Fri Nov  7 14:43:42 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 07 Nov 2008 06:43:42 -0800
Subject: CVS Outage (now)
In-Reply-To: <20081107131642.GF22088@killefiz>
References: <1226027949.5146.26.camel@luminos.localdomain>	<1226029280.5146.30.camel@luminos.localdomain>	<1226040282.5146.39.camel@luminos.localdomain>	<5256d0b0811070511s1e9a3057n47fb0b6d98e3a827@mail.gmail.com>
	<20081107131642.GF22088@killefiz>
Message-ID: <4914541E.1060803@gmail.com>

Sven Lankes wrote:
> On Fri, Nov 07, 2008 at 01:11:09PM +0000, Peter Robinson wrote:
> 
>> Should we get the F-10 pulled when we do a 'cvs update' against
>> packages. It doesn't seem to pull it.
> 
> You need to use 'cvs update -d' - cvs update doesn't include new
> directories by default.
> 
If it still doesn't pull after you do this.  Let me know.  It may mean
that the package was skipped over in the mass branch for some reason.

-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/20081107/68809e71/attachment.sig>

From ville.skytta at iki.fi  Fri Nov  7 15:19:37 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Fri, 7 Nov 2008 17:19:37 +0200
Subject: CVS Outage (now)
In-Reply-To: <200811071603.10243.opensource@till.name>
References: <1226027949.5146.26.camel@luminos.localdomain>
	<ufazlkba9iv.fsf@epithumia.math.uh.edu>
	<200811071603.10243.opensource@till.name>
Message-ID: <200811071719.38213.ville.skytta@iki.fi>

On Friday 07 November 2008, Till Maas wrote:
> On Fri November 7 2008, Jason L Tibbitts III wrote:
> > >>>>> "SL" == Sven Lankes <sven at lank.es> writes:
> >
> > SL> You need to use 'cvs update -d' - cvs update doesn't include new
> > SL> directories by default.
> >
> > It's a good idea to do something like
> >
> > echo "update -dPA" >> ~/.cvsrc
>
> Do we use sticky stuff (I do not really understand what this does) in
> Fedora, i.e. is -A useful here?

I don't think any of the Fedora infrastructure uses branches in the 
traditional way that would cause -A to end up switching branches.  If, 
however -A blows away for example -ko or -kb settings from the repository, 
then it's actively harmful (I don't think it does, though).  It will also 
interfere with working on traditional branches if one creates them in Fedora 
CVS, ditto with any other project that uses such branches one might be 
working on.  Personally there's no way I'd want -A for "update" in my .cvsrc.



From martin.langhoff at gmail.com  Fri Nov  7 15:38:32 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Fri, 7 Nov 2008 10:38:32 -0500
Subject: Anaconda installs OOM with selinux-policy-targeted rpm from F9
	updates
In-Reply-To: <49145594.4070106@redhat.com>
References: <46a038f90811062213i35d243a9xfac6b0d0bd8aab47@mail.gmail.com>
	<49145594.4070106@redhat.com>
Message-ID: <46a038f90811070738g602ea761nbd235cefbd1ebc9d@mail.gmail.com>

On Fri, Nov 7, 2008 at 9:49 AM, Daniel J Walsh <dwalsh at redhat.com> wrote:
> selinux-policy-targeted is a memory hog, but it should not have changed
> that drastically in updates.
>
> Is this repeatable?

100% repeatable on the 3 attempts on the lower-mem machine. On the same machin

The package  selinux-policy-targeted 3.3.1 103.fc9 -- I am running a
couple of additional installs to gather more information.

On Fri, Nov 7, 2008 at 9:59 AM, Chris Lumens <clumens at redhat.com> wrote:
>>  - Anaconda OOMs without a warning or useful message to the user
>
> I don't believe there's any way for anaconda to know this, and there's
> certainly no way for us to do anything about it.

Well, the behaviour is really weird. Perhaps there is no OOM killer in
place during an anaconda install? If there was, it'd expect the rpm
process or anaconda to be shot down -- but the machine is halting
instead, it literally switches off.

Whatever is bootstrapping anaconda (init script in the initrd?) should
be able to at least see the odd exit status and echo a "something went
wrong" msg...? Maybe that's the problem?

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 dwalsh at redhat.com  Fri Nov  7 15:44:04 2008
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Fri, 07 Nov 2008 10:44:04 -0500
Subject: Anaconda installs OOM with selinux-policy-targeted rpm from F9
 updates
In-Reply-To: <46a038f90811070738g602ea761nbd235cefbd1ebc9d@mail.gmail.com>
References: <46a038f90811062213i35d243a9xfac6b0d0bd8aab47@mail.gmail.com>	<49145594.4070106@redhat.com>
	<46a038f90811070738g602ea761nbd235cefbd1ebc9d@mail.gmail.com>
Message-ID: <49146244.9020708@redhat.com>

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

Martin Langhoff wrote:
> On Fri, Nov 7, 2008 at 9:49 AM, Daniel J Walsh <dwalsh at redhat.com> wrote:
>> selinux-policy-targeted is a memory hog, but it should not have changed
>> that drastically in updates.
>>
>> Is this repeatable?
> 
> 100% repeatable on the 3 attempts on the lower-mem machine. On the same machin
> 
> The package  selinux-policy-targeted 3.3.1 103.fc9 -- I am running a
> couple of additional installs to gather more information.
> 
> On Fri, Nov 7, 2008 at 9:59 AM, Chris Lumens <clumens at redhat.com> wrote:
>>>  - Anaconda OOMs without a warning or useful message to the user
>> I don't believe there's any way for anaconda to know this, and there's
>> certainly no way for us to do anything about it.
> 
> Well, the behaviour is really weird. Perhaps there is no OOM killer in
> place during an anaconda install? If there was, it'd expect the rpm
> process or anaconda to be shot down -- but the machine is halting
> instead, it literally switches off.
> 
> Whatever is bootstrapping anaconda (init script in the initrd?) should
> be able to at least see the odd exit status and echo a "something went
> wrong" msg...? Maybe that's the problem?
> 
> cheers,
> 
> 
> 
> m
Well selinux-policy-targeted is not supported on olpc so you should
probably exclude it from the install.  I can not imagine what in updates
caused it to grow.  Upgrades add rules but usually not a large amount.
Going from Fedora 9 to 10 could be a problem.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkUYkQACgkQrlYvE4MpobP7iwCeMpfEbsKEmvbp1oaAM5U9akG+
l8IAoIOlHoMsPXo6T36A/UWER0mtLMIS
=3pHW
-----END PGP SIGNATURE-----



From rc040203 at freenet.de  Fri Nov  7 15:46:24 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 07 Nov 2008 16:46:24 +0100
Subject: CVS Outage (now)
In-Reply-To: <200811071603.10243.opensource@till.name>
References: <1226027949.5146.26.camel@luminos.localdomain>
	<20081107131642.GF22088@killefiz>
	<ufazlkba9iv.fsf@epithumia.math.uh.edu>
	<200811071603.10243.opensource@till.name>
Message-ID: <1226072784.2897.267.camel@beck.corsepiu.local>

On Fri, 2008-11-07 at 16:02 +0100, Till Maas wrote:
> On Fri November 7 2008, Jason L Tibbitts III wrote:
> > >>>>> "SL" == Sven Lankes <sven at lank.es> writes:
> >
> > SL> You need to use 'cvs update -d' - cvs update doesn't include new
> > SL> directories by default.
> >
> > It's a good idea to do something like
> >
> > echo "update -dPA" >> ~/.cvsrc
> 
> Do we use sticky stuff (I do not really understand what this does) in Fedora, 
No.

> i.e. is -A useful here?
Not really. However, Tibbs' advise to add -A to ~/.cvsrc is pretty
harmful to anybody who seriously uses CVS. 

Temporarily using -A (e.g. on the command-line), e.g. in cases such as
Fedora checkouts, is OK.

Ralf




From dwalsh at redhat.com  Fri Nov  7 15:49:41 2008
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Fri, 07 Nov 2008 10:49:41 -0500
Subject: How to get an SELinux policy change
In-Reply-To: <20081107150252.6e71748c@metropolis.intra.city-fan.org>
References: <870180fe0811051144k72da42f5gcc8401fd5b68a7b8@mail.gmail.com>	<4912000A.6060605@redhat.com>	<870180fe0811051644x7a49e6b9r22543f9126ebd75c@mail.gmail.com>	<0ML31I-1Ky7vX0iQd-0008Ti@mrelayeu.kundenserver.de>	<49133B4B.3050308@herr-schmitt.de>	<870180fe0811061515x39ef4bb6q5f06eb724f0ba431@mail.gmail.com>	<b086760e0811070225w45a2e95lf61db56378a3628b@mail.gmail.com>	<870180fe0811070610r1ba81a3dnc0bb1f74f468b450@mail.gmail.com>	<4914565E.40704@redhat.com>
	<20081107150252.6e71748c@metropolis.intra.city-fan.org>
Message-ID: <49146395.7080909@redhat.com>

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

Paul Howarth wrote:
> On Fri, 07 Nov 2008 09:53:18 -0500
> Daniel J Walsh <dwalsh at redhat.com> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Jerry James wrote:
>>> 2008/11/7 yersinia <yersinia.spiros at gmail.com>:
>>>> Do look useful this docu ?
>>>>
>>>> http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules
>>> Thank you.  That is a very useful document.  However, it does not
>>> appear to answer my question.  I need a non-default security context
>>> for binaries that are both built and executed in the %build script,
>>> when the policy module has not yet been installed.  It appears to me
>>> that there are only two ways to accomplish this: keep abusing
>>> java_exec_t like I have been, or get a GCL policy incorporated into
>>> selinux-policy* prior to building GCL.  Am I wrong?  Is there some
>>> other option?  Does anyone have any guidance to offer me on which
>>> option to pursue?  Thanks,
>> I would go with the chcon solution you have but instead of hard coding
>> the java_exec_t, I would execute
>>
>> You can get the context of the final destination of the file using
>>
>> chcon `matchpathcon -n /usr/bin/gcl` LOCALPATH/gcl
>>
>> Which seems to be a fine way of doing. this.
> 
> Indeed, but it needs the context type for /usr/bin/gcl to be set to
> java_exec_t or equivalent in the selinux-policy package before it'll
> work.
> 
> Paul.
> 

+/usr/bin/gcl 		       --	gen_context(system_u:object_r:execmem_exec_t,s0)


Will be in selinux-policy-3.5.13-19.fc10
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkUY5UACgkQrlYvE4MpobNcZwCffDDyogNaxP/4ozZE0omAJ5N5
pjcAnijuOdoAT67e5eD2RVHiiED6p5Gv
=86wN
-----END PGP SIGNATURE-----



From tibbs at math.uh.edu  Fri Nov  7 15:54:46 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 07 Nov 2008 09:54:46 -0600
Subject: CVS Outage (now)
In-Reply-To: <200811071603.10243.opensource@till.name>
References: <1226027949.5146.26.camel@luminos.localdomain>
	<20081107131642.GF22088@killefiz>
	<ufazlkba9iv.fsf@epithumia.math.uh.edu>
	<200811071603.10243.opensource@till.name>
Message-ID: <ufahc6ja5vd.fsf@epithumia.math.uh.edu>

>>>>> "TM" == Till Maas <opensource at till.name> writes:

TM> Do we use sticky stuff (I do not really understand what this does)
TM> in Fedora, i.e. is -A useful here?

I do checkouts by timestamp often enough and don't want them to
stick.

 - J<



From debarshi.ray at gmail.com  Fri Nov  7 16:05:22 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Fri, 7 Nov 2008 21:35:22 +0530
Subject: CC'ed to my own bugs
In-Reply-To: <20081107145549.GA2493@orient.maison.lan>
References: <3170f42f0811062023uab6907cw1aa5e444377e63e5@mail.gmail.com>
	<4913EADC.9030901@gmail.com>
	<3170f42f0811070111t7abe3ca2jd3a482c806fec8ad@mail.gmail.com>
	<20081107145549.GA2493@orient.maison.lan>
Message-ID: <3170f42f0811070805r151176ccy6309d4c2c6e2a566@mail.gmail.com>

> This is so you do not stop getting mail from
> a bug simply because someone assigned it to somebody other than you.

I see.

>> I have not paid much attention to whether it is generating duplicate
>> messages or not, so I would say it is just something that I noticed
>> was different.

> You'll keep getting one mail but you'll now get it for two different
> reasons instead of one.

That is good to know. :-)

Cheers,
Debarshi



From debarshi.ray at gmail.com  Fri Nov  7 16:04:04 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Fri, 7 Nov 2008 21:34:04 +0530
Subject: libgnomecanvas owns %{_libdir}/libglade
In-Reply-To: <1226067740.3417.1.camel@localhost.localdomain>
References: <3170f42f0811062012v135f1766s4c8152cd26811383@mail.gmail.com>
	<20081107114035.0402300d@metropolis.intra.city-fan.org>
	<3170f42f0811070413g7e90fddq989ff28dfb05b964@mail.gmail.com>
	<1226067740.3417.1.camel@localhost.localdomain>
Message-ID: <3170f42f0811070804h1b3b737eke1140f52a54e13a9@mail.gmail.com>

>  It would probably be better if libglade2 owned %{libdir}/libglade and
> %{libdir}/libglade/2.0. Can you take care of that ?

Sure. :-) This is just what I wanted to know.

Mamoru, thanks for your bit too. :-)

Cheers,
Debarshi



From mw_triad at users.sourceforge.net  Fri Nov  7 16:24:24 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Fri, 07 Nov 2008 10:24:24 -0600
Subject: f8 packages not upgraded by f9
In-Reply-To: <1226024773.5146.19.camel@luminos.localdomain>
References: <gevstb$qo6$1@ger.gmane.org>	<loom.20081107T011432-71@post.gmane.org>	<18330.1226023220@sss.pgh.pa.us>
	<1226024773.5146.19.camel@luminos.localdomain>
Message-ID: <gf1q3o$e36$1@ger.gmane.org>

Jesse Keating wrote:
> On Thu, 2008-11-06 at 21:00 -0500, Tom Lane wrote:
>> This seems like a relatively easy mistake to make, and one that could be
>> caught automatically by bodhi or some other part of the packaging
>> infrastructure.  Is such a test easy enough to be worth installing?
> 
> We have the start of some scripts to do automated checking of these on a
> daily or on a push by push basis.  I plan on working more on these once
> F10 is out the door.

Sounds nice. Thanks for the info, all.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
No .sig for you! NEXT! -- Unknown



From martin.langhoff at gmail.com  Fri Nov  7 16:34:35 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Fri, 7 Nov 2008 11:34:35 -0500
Subject: Anaconda installs OOM with selinux-policy-targeted rpm from F9
	updates
In-Reply-To: <46a038f90811070738g602ea761nbd235cefbd1ebc9d@mail.gmail.com>
References: <46a038f90811062213i35d243a9xfac6b0d0bd8aab47@mail.gmail.com>
	<49145594.4070106@redhat.com>
	<46a038f90811070738g602ea761nbd235cefbd1ebc9d@mail.gmail.com>
Message-ID: <46a038f90811070834w3150cf04p25dcf500a77ef04f@mail.gmail.com>

On Fri, Nov 7, 2008 at 10:38 AM, Martin Langhoff
<martin.langhoff at gmail.com> wrote:
> On Fri, Nov 7, 2008 at 9:49 AM, Daniel J Walsh <dwalsh at redhat.com> wrote:
>> selinux-policy-targeted is a memory hog, but it should not have changed
>> that drastically in updates.
>>
>> Is this repeatable?
>
> 100% repeatable on the 3 attempts on the lower-mem machine. On the same machin

Ok - now I have a few more tests

 - it does not happen in text mode
 - it does not happen in gui mode if I'm looking at the VT
 - it does happen in gui mode if I am looking at X

And according to the logs, it's does not appear to be an OOM -- the
last reading shows 32MB free. Or it's such a sudden OOM that it never
gets written to disk. Memory usage logs are captured doing (in the
VT):

  tail -f /mnt/sysimage/root/install.log >> /mnt/sysimage/root/instmem.log &
  vmstat 1 >> /mnt/sysimage/root/instmem.log &

so I have a log showing mem usage during each rpm installation. The
memory usage is not specially high.

Perhaps something else is happening during that rpm installation. Is
there any command that I can pass to anaconda to write a more verbose
log?

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 davej at redhat.com  Fri Nov  7 17:11:43 2008
From: davej at redhat.com (Dave Jones)
Date: Fri, 7 Nov 2008 12:11:43 -0500
Subject: Anaconda installs OOM with selinux-policy-targeted rpm from F9
	updates
In-Reply-To: <46a038f90811062213i35d243a9xfac6b0d0bd8aab47@mail.gmail.com>
References: <46a038f90811062213i35d243a9xfac6b0d0bd8aab47@mail.gmail.com>
Message-ID: <20081107171143.GA27590@redhat.com>

On Fri, Nov 07, 2008 at 01:13:38AM -0500, Martin Langhoff wrote:
 > One the last rounds of testing the new release of OLPCXS, I rebuilt it
 > with fresh packages from F9 update and started testing the installer.
 > Funny thing, the install did not complete -- instead, the machine
 > would switch off after spending a few minutes trying to install
 > selinux-policy-targeted.
 > 
 > After a few attempts to diagnose the problem, I managed to see vmstat
 > go all the way down to almost 0 memory just before the machine turned
 > itself off. This particular machine has ~980MB RAM available to the
 > OS. Tested on another machine with a proper 1GB memory, vmstat hit
 > bottom at ~10MB free while installing selinux-policy-targeted but
 > quickly recovered.
 > 
 > I know I've installed earlier F9 based spins on machines with 512 MB
 > of physical RAM so this seems like a fairly bad regression, specially
 > considering that I'll soon need to install this on a machine with
 > 256MB RAM.
 > 
 > So I suspect we have 2 problems
 > 
 >  - Selinux-policy-targeted instalation seems to have balooned into a
 > memory hog between f9-release and f9-updates
 > 
 >  - Anaconda OOMs without a warning or useful message to the user
 > 
 > Has anyone else seen this? Diagnostics to recommend? I can
 > successfully log anything to disk until moments before the OOM
 > shutdown.

Did you configure any swap ?
If no, then there's really not much that we can do if something
uses more than available system RAM.

If you did, it might be interesting to try (from tty2)
echo 1 > /proc/sys/vm/would_have_oomkilled

That will prevent the actually 'killing', but will still
log all the same output that the oomkiller would have spewed.
It might be interesting to see that output.

If you're drastically low enough on memory to invoke an OOM kill
though, setting that sysctl may just mean the system livelocks.

	Dave

-- 
http://www.codemonkey.org.uk



From camilo at mesias.co.uk  Fri Nov  7 17:40:09 2008
From: camilo at mesias.co.uk (Camilo Mesias)
Date: Fri, 7 Nov 2008 17:40:09 +0000
Subject: preupgrade F9 -> rawhide?
In-Reply-To: <d551e0e20810262348m2a94520eh562373b2df491b30@mail.gmail.com>
References: <d551e0e20810261105u1fce4b2am7ead022a5c2f9c83@mail.gmail.com>
	<1225084095.3077.24.camel@zebes.localdomain>
	<d551e0e20810262348m2a94520eh562373b2df491b30@mail.gmail.com>
Message-ID: <d551e0e20811070940k6277b1a4ufdf5f27add2c90b@mail.gmail.com>

A quick update on this. I successfully upgraded one machine about a
week ago, so I tried another machine today and it had a problem
booting during the install.

After all the packages had been downloaded and the 'reboot' button was
pressed, grub was no longer able to come up. The word 'GRUB' was
displayed and nothing else.

I booted with the F9 Live USB and did the following (sorry it doesn't
help with diagnosis but it might help if anyone else has this problem)

mkdir /tmp/rootdir
mount /dev/mapper/VolGroup00-LogVol00 /tmp/rootdir
mount /dev/sda1 /tmp/rootdir/boot
/tmp/rootdir/sbin/grub-install --root-directory=/tmp/rootdir /dev/sda

If there are any logs that might help diagnose the problem, let me
know. I have one more desktop and one more laptop running F9 which I
plan to preupgrade in the same way, Please let me know if there is
anything I should note to help improve the process.

-Cam



From sundaram at fedoraproject.org  Fri Nov  7 17:43:53 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 07 Nov 2008 23:13:53 +0530
Subject: Who moved my bug?
In-Reply-To: <20081107111727.GA10541@mokona.greysector.net>
References: <200811061243.49188.opensource@till.name>	<4912F8F3.10205@shmuelhome.mine.nu>	<da159fda0811060746j4348fb08u61f2bfaa24bb7aff@mail.gmail.com>	<20081106161830.GE1412@mokona.greysector.net>	<da159fda0811060830p5455c814x5dd1a6317f423b1@mail.gmail.com>	<20081106183801.GA3363@mokona.greysector.net>	<1226000181.3145.12.camel@kennedy>	<20081106202925.GB3363@mokona.greysector.net>	<1226007281.5146.14.camel@luminos.localdomain>	<1226017819.5758.11.camel@kennedy>
	<20081107111727.GA10541@mokona.greysector.net>
Message-ID: <49147E59.2090900@fedoraproject.org>

Dominik 'Rathann' Mierzejewski wrote:
> On Friday, 07 November 2008 at 01:30, Brian Pepple wrote:
>> https://www.redhat.com/archives/fedora-devel-list/2008-January/msg01359.html
> 
> You can't expect every packager to read every mail on fedora-devel-list.
> There is simply too much traffic here, not to mention the contents of any
> longer discussion have little to do with the original subject.
> 
> Personally, I only glimpse over the subjects and only read (parts of) the threads
> that have interesting subjects.

There is a expectation however the all packagers read the announcements 
to fedora-devel-announce list carefully. It was created precisely 
because this list is high traffic.

Rahul



From dwmw2 at infradead.org  Fri Nov  7 17:45:30 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 07 Nov 2008 18:45:30 +0100
Subject: End of bind-chroot-admin script
In-Reply-To: <20081107120905.GA3188@evileye.atkac.englab.brq.redhat.com>
References: <20081107120905.GA3188@evileye.atkac.englab.brq.redhat.com>
Message-ID: <1226079930.3997.12.camel@macbook.infradead.org>

On Fri, 2008-11-07 at 13:09 +0100, Adam Tkac wrote:
> bind-chroot-admin script should sync BIND configuration files to
> chroot() directory. It was written with good intention but it has
> never worked correctly in all situations. There is long history with
> many broken configurations and urgent severity bugs.
> 
> I'm going to remove this script from Fedora 11 (it is part of Fedora/RHEL
> only, no other distro uses it). After removal, "standard" chroot
> structure will be created when you install bind-chroot package. It
> will contain all needed files for running named in chroot but admin
> shall move needed configuration files to chroot manually. Do you have
> any comments?

?

-- 
dwmw2



From jkeating at redhat.com  Fri Nov  7 17:59:32 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 07 Nov 2008 09:59:32 -0800
Subject: CVS Outage (now)
In-Reply-To: <20081107140617.0d19e682.mschwendt@gmail.com>
References: <1226027949.5146.26.camel@luminos.localdomain>
	<1226029280.5146.30.camel@luminos.localdomain>
	<1226040282.5146.39.camel@luminos.localdomain>
	<20081107140617.0d19e682.mschwendt@gmail.com>
Message-ID: <1226080772.5146.43.camel@luminos.localdomain>

On Fri, 2008-11-07 at 14:06 +0100, Michael Schwendt wrote:
> devel still tags for dist-f10-updates-candidate instead of dist-f11

Whoops!  Thanks for catching that.  I'll add that tidbit to the SOP.

-- 
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/20081107/eaf251c3/attachment.sig>

From sundaram at fedoraproject.org  Fri Nov  7 18:41:32 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 08 Nov 2008 00:11:32 +0530
Subject: FESCo Meeting Summary for 2008-11-05
In-Reply-To: <1226016932.5758.3.camel@kennedy>
References: <1226016932.5758.3.camel@kennedy>
Message-ID: <49148BDC.7020702@fedoraproject.org>

Brian Pepple wrote:

> === Features ===
>       * After evaluating Empathy(1) with Colin Walters (walters) and
>         Will Woods (wwoods), FESCo felt that Empathy wasn't ready at
>         this time to become the default IM client for Fedora 10. This
>         was due to some missing features and bugs in comparison to
>         Pidgin.  The plan is to reevaluate Empathy for Fedora 11, since
>         most of the current issues should be resolved for Gnome 2.26.
>              1. https://fedoraproject.org/wiki/Features/Empathy
>       * wwoods had a suggestion for the feature process that the Scope
>         section have *specific* features that are expected, and the Test
>         Plan have *specific* directions on how to ensure those features
>         are present and working.

This is really late to be switching default apps. A lot of time gets 
wasted in testing, documenting changes in release notes that already 
been translated into dozens of languages etc that would have avoided by 
making changes like this earlier in the release cycle and no later than 
the feature freeze. This is not to the say, that I disagree with the 
decision itself. Just that it is very very late.

Rahul



From jkeating at redhat.com  Fri Nov  7 18:53:36 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 07 Nov 2008 10:53:36 -0800
Subject: FESCo Meeting Summary for 2008-11-05
In-Reply-To: <49148BDC.7020702@fedoraproject.org>
References: <1226016932.5758.3.camel@kennedy>
	<49148BDC.7020702@fedoraproject.org>
Message-ID: <1226084016.5146.49.camel@luminos.localdomain>

On Sat, 2008-11-08 at 00:11 +0530, Rahul Sundaram wrote:
> This is really late to be switching default apps. A lot of time gets 
> wasted in testing, documenting changes in release notes that already 
> been translated into dozens of languages etc that would have avoided by 
> making changes like this earlier in the release cycle and no later than 
> the feature freeze. This is not to the say, that I disagree with the 
> decision itself. Just that it is very very late.

In this case, it's a switch /back/ to what has been the default for
years.  Far far less risky  then switching to something /new/ at this
point.

-- 
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/20081107/926490f0/attachment.sig>

From dominik at greysector.net  Fri Nov  7 19:29:02 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Fri, 7 Nov 2008 20:29:02 +0100
Subject: Who moved my bug?
In-Reply-To: <49147E59.2090900@fedoraproject.org>
References: <da159fda0811060746j4348fb08u61f2bfaa24bb7aff@mail.gmail.com>
	<20081106161830.GE1412@mokona.greysector.net>
	<da159fda0811060830p5455c814x5dd1a6317f423b1@mail.gmail.com>
	<20081106183801.GA3363@mokona.greysector.net>
	<1226000181.3145.12.camel@kennedy>
	<20081106202925.GB3363@mokona.greysector.net>
	<1226007281.5146.14.camel@luminos.localdomain>
	<1226017819.5758.11.camel@kennedy>
	<20081107111727.GA10541@mokona.greysector.net>
	<49147E59.2090900@fedoraproject.org>
Message-ID: <20081107192902.GB12723@mokona.greysector.net>

On Friday, 07 November 2008 at 18:43, Rahul Sundaram wrote:
> Dominik 'Rathann' Mierzejewski wrote:
> >On Friday, 07 November 2008 at 01:30, Brian Pepple wrote:
> >>https://www.redhat.com/archives/fedora-devel-list/2008-January/msg01359.html
> >
> >You can't expect every packager to read every mail on fedora-devel-list.
> >There is simply too much traffic here, not to mention the contents of any
> >longer discussion have little to do with the original subject.
> >
> >Personally, I only glimpse over the subjects and only read (parts of) the 
> >threads
> >that have interesting subjects.
> 
> There is a expectation however the all packagers read the announcements 
> to fedora-devel-announce list carefully. It was created precisely 
> because this list is high traffic.

Yes. I guess I should've paid more attention to the announcement. I still
think it's counter-intuitive to redefine the meaning of "ASSIGNED" state.

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 sundaram at fedoraproject.org  Fri Nov  7 19:37:02 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 08 Nov 2008 01:07:02 +0530
Subject: Who moved my bug?
In-Reply-To: <20081107192902.GB12723@mokona.greysector.net>
References: <da159fda0811060746j4348fb08u61f2bfaa24bb7aff@mail.gmail.com>	<20081106161830.GE1412@mokona.greysector.net>	<da159fda0811060830p5455c814x5dd1a6317f423b1@mail.gmail.com>	<20081106183801.GA3363@mokona.greysector.net>	<1226000181.3145.12.camel@kennedy>	<20081106202925.GB3363@mokona.greysector.net>	<1226007281.5146.14.camel@luminos.localdomain>	<1226017819.5758.11.camel@kennedy>	<20081107111727.GA10541@mokona.greysector.net>	<49147E59.2090900@fedoraproject.org>
	<20081107192902.GB12723@mokona.greysector.net>
Message-ID: <491498DE.9080704@fedoraproject.org>

Dominik 'Rathann' Mierzejewski wrote:

> 
> Yes. I guess I should've paid more attention to the announcement. I still
> think it's counter-intuitive to redefine the meaning of "ASSIGNED" state.

Agreed and I did bring this point to the discussion and was shot down.

Rahul



From mdehaan at redhat.com  Fri Nov  7 19:44:13 2008
From: mdehaan at redhat.com (Michael DeHaan)
Date: Fri, 07 Nov 2008 14:44:13 -0500
Subject: Concerns about 'provenpackager' and why I didn't mass ACL open
Message-ID: <49149A8D.3080608@redhat.com>

Jesse Keating mentioned I should probably start a thread about why I 
didn't include a few packages of mine in the mass-ACL opening with the 
idea of starting a discussion about why some packages should or 
shouldn't be included.   I generally think in most cases people will do 
the right thing with such access, but I choose to err on the side of 
paranoid security when it comes to systems management software.

I'll explain -- For starters, I agree that it's important for people to 
be able to fix packaging problems when needed (when the project owner is 
not around especially), though my concern with the provenpackager system 
is I am not sure of the levels of controls in place for what allows 
someone to become a provenpackager -- or what would happen if a 
provenpackager's machine+passwords get comprimised.    With the number 
of people being able to access a package being reasonably low, the risk 
is low, but as we increase the number of people with commit access to 
/anything/ so the risk also increases.

As I understand it, in general, provenpackager status requires packaging 
a certain number of packages (N).    In my opinion, this is insufficient 
and potentially dangerous and package access should be given under an 
"as needed" basis.   This is for the same reason commit access to 
repositories needs to be vetted (do any of us allow /everyone/ to 
commit?) -- though in this case it's more important -- while git allows 
backing off on a version, deleting history, and other things, this 
system seems to allow for potentially releasing bits -- which is much 
more powerful.   It seems to allow deployed code to be changed without 
the descretion of the people running the project.     The risk is 
unlikely but possible.

There are two events when it is dangerous -- (A) provenpackager decides 
to correct what he thinks is an rpmlint error and thus unintentially 
breaks the security of the packaged application, (B) credentials of 
provenpackager are compromised allowing $evil to replace the contents of 
a said package.    In either case, the change could either be making a 
new release of an application (which contains an exploit and/or 
unwitting bug), or  updating the specfile in a way that breaks file 
permissions in a way that may not be immediately obvious (whether 
intentional or not).
Now for some things, like desktop libraries, that could be used to 
install a botnet type application -- through you still have to 
comprimise N machines.    What if you had a tool that allowed you to 
comprimise an entire organization?    That's something I want to make 
sure never happens.    Our security track record does not only stem from 
things like SELinux, Unix permissions, and the like -- it also stems 
from a culture of vigilance.

Now the two packages I've left off from the mass ACL opening now are 
cobbler, koan, func, and certmaster.

The reason being for this is that these, if comprised, are tools that 
/do/ allow reprogramming of an entire datacenter in very easy steps.    
Cobbler could reinstall an entire set of managed machines in 1 
command.   Func should be more obvious.   We pay very close attention to 
these programs and while we are very accepting of any contributions and 
ideas, we /do/ watch the commits very carefully.  I know there are many 
programs with similar capability that /have/ been opened up, but perhaps 
because we didn't talk about consequences.

While it's true that any comprimised package would be a problem, 
something as simple as making an unintended change to package 
permissions (without first discussing it on the project lists), could 
expose not the one system with packages installed but the entire set of 
/managed/ systems.

I am not really comfortable with opening that up.

So, anyway, that's my logic ... if anyone can persuade me that releasing 
new code is /not/ possible through the provenpackager system, I think I 
could be persuaded to flip things, but right now, I can't see an 
advantage in doing so.

(If a change is needed, people can still bring up the change on the 
project lists and it can be made)

--Michael




From mdehaan at redhat.com  Fri Nov  7 20:03:08 2008
From: mdehaan at redhat.com (Michael DeHaan)
Date: Fri, 07 Nov 2008 15:03:08 -0500
Subject: Concerns about 'provenpackager' and why I didn't mass ACL open
In-Reply-To: <49149A8D.3080608@redhat.com>
References: <49149A8D.3080608@redhat.com>
Message-ID: <49149EFC.3030202@redhat.com>


>
>
> Now the two packages I've left off from the mass ACL opening now are 
> cobbler, koan, func, and certmaster.

I mean Four .. and bright red shiny uniforms.



From a.badger at gmail.com  Fri Nov  7 20:08:23 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 07 Nov 2008 12:08:23 -0800
Subject: Concerns about 'provenpackager' and why I didn't mass ACL open
In-Reply-To: <49149A8D.3080608@redhat.com>
References: <49149A8D.3080608@redhat.com>
Message-ID: <4914A037.10803@gmail.com>

Michael DeHaan wrote:
> Jesse Keating mentioned I should probably start a thread about why I
> didn't include a few packages of mine in the mass-ACL opening with the
> idea of starting a discussion about why some packages should or
> shouldn't be included.   I generally think in most cases people will do
> the right thing with such access, but I choose to err on the side of
> paranoid security when it comes to systems management software.
> 
> I'll explain -- For starters, I agree that it's important for people to
> be able to fix packaging problems when needed (when the project owner is
> not around especially), though my concern with the provenpackager system
> is I am not sure of the levels of controls in place for what allows
> someone to become a provenpackager -- or what would happen if a
> provenpackager's machine+passwords get comprimised.    With the number
> of people being able to access a package being reasonably low, the risk
> is low, but as we increase the number of people with commit access to
> /anything/ so the risk also increases.
> 
> As I understand it, in general, provenpackager status requires packaging
> a certain number of packages (N).    In my opinion, this is insufficient
> and potentially dangerous and package access should be given under an
> "as needed" basis.   This is for the same reason commit access to
> repositories needs to be vetted (do any of us allow /everyone/ to
> commit?) -- though in this case it's more important -- while git allows
> backing off on a version, deleting history, and other things, this
> system seems to allow for potentially releasing bits -- which is much
> more powerful.   It seems to allow deployed code to be changed without
> the descretion of the people running the project.     The risk is
> unlikely but possible.
> 
> There are two events when it is dangerous -- (A) provenpackager decides
> to correct what he thinks is an rpmlint error and thus unintentially
> breaks the security of the packaged application, (B) credentials of
> provenpackager are compromised allowing $evil to replace the contents of
> a said package.    In either case, the change could either be making a
> new release of an application (which contains an exploit and/or
> unwitting bug), or  updating the specfile in a way that breaks file
> permissions in a way that may not be immediately obvious (whether
> intentional or not).
> Now for some things, like desktop libraries, that could be used to
> install a botnet type application -- through you still have to
> comprimise N machines.    What if you had a tool that allowed you to
> comprimise an entire organization?    That's something I want to make
> sure never happens.    Our security track record does not only stem from
> things like SELinux, Unix permissions, and the like -- it also stems
> from a culture of vigilance.
> 
> Now the two packages I've left off from the mass ACL opening now are
> cobbler, koan, func, and certmaster.
> 
> The reason being for this is that these, if comprised, are tools that
> /do/ allow reprogramming of an entire datacenter in very easy steps.   
> Cobbler could reinstall an entire set of managed machines in 1
> command.   Func should be more obvious.   We pay very close attention to
> these programs and while we are very accepting of any contributions and
> ideas, we /do/ watch the commits very carefully.  I know there are many
> programs with similar capability that /have/ been opened up, but perhaps
> because we didn't talk about consequences.
> 
> While it's true that any comprimised package would be a problem,
> something as simple as making an unintended change to package
> permissions (without first discussing it on the project lists), could
> expose not the one system with packages installed but the entire set of
> /managed/ systems.
> 
> I am not really comfortable with opening that up.
> 
> So, anyway, that's my logic ... if anyone can persuade me that releasing
> new code is /not/ possible through the provenpackager system, I think I
> could be persuaded to flip things, but right now, I can't see an
> advantage in doing so.
> 
> (If a change is needed, people can still bring up the change on the
> project lists and it can be made)
> 
I cannot allay your concerns and I can see your point.  I'd like to
mention, though, that func depends on the following packages with open acls:

pyOpenSSL, python, python-simplejson

So in terms of protecting against $EVIL, restricting provenpackager
isn't very effective.

It is, effective for restricting people in provenpackager from making
unaudited changes to your code, though.  So if you are a conscientious
maintainer who is on top of their bug reports, restricting
provenpackager could be good for everyone.  On the other hand, if you're
a maintainer that has too many packages and other responsibilities and
doesn't get around to fixing things (or at least showing presence on a
bug) quickly, having provenpackager set is a definite detriment.

-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/20081107/e1299955/attachment.sig>

From jkeating at redhat.com  Fri Nov  7 20:15:27 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 07 Nov 2008 12:15:27 -0800
Subject: Concerns about 'provenpackager' and why I didn't mass ACL open
In-Reply-To: <49149A8D.3080608@redhat.com>
References: <49149A8D.3080608@redhat.com>
Message-ID: <1226088927.5146.54.camel@luminos.localdomain>

On Fri, 2008-11-07 at 14:44 -0500, Michael DeHaan wrote:
> As I understand it, in general, provenpackager status requires packaging 
> a certain number of packages (N).    In my opinion, this is insufficient 
> and potentially dangerous and package access should be given under an 
> "as needed" basis. 

Small correction here.  Against my advise, the "has more than 5
packages" mark was only used for the initial seeding of the
provenpackager group.  From this point on, the way to get in is to
request membership via the account system, and somebody already in the
group has to approve the membership.  It isn't the same sponsorship type
thing that getting into packager has, once you approve somebody you're
not ultimately responsible for them.  But we did want to make it
something somebody has to explicitly ask for, rather than be
auto-granted whether they want it or not.
> 
> I am not really comfortable with opening that up.
> 
> So, anyway, that's my logic ... if anyone can persuade me that releasing 
> new code is /not/ possible through the provenpackager system, I think I 
> could be persuaded to flip things, but right now, I can't see an 
> advantage in doing so.

For rawhide, somebody would be able to commit a change and do a build,
and it would automatically go out in rawhide.  But for a released
package, since it has to go through bodhi, only the "owner" can do bodhi
updates at this time.  There are plans to enable co-maintainers to
submit updates too, but that would again be specifically granted people,
rather than members of a larger group.

All that said, I don't think your logic is wrong, and I think it has
been well thought out.  I just wanted other folks to know where you were
coming from on these particular packages, mostly because it had seemed
in the past you were very much in favor of a more open system.

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/20081107/4b1e6f6a/attachment.sig>

From wwoods at redhat.com  Fri Nov  7 20:21:52 2008
From: wwoods at redhat.com (Will Woods)
Date: Fri, 07 Nov 2008 15:21:52 -0500
Subject: preupgrade F9 -> rawhide?
In-Reply-To: <d551e0e20811070940k6277b1a4ufdf5f27add2c90b@mail.gmail.com>
References: <d551e0e20810261105u1fce4b2am7ead022a5c2f9c83@mail.gmail.com>
	<1225084095.3077.24.camel@zebes.localdomain>
	<d551e0e20810262348m2a94520eh562373b2df491b30@mail.gmail.com>
	<d551e0e20811070940k6277b1a4ufdf5f27add2c90b@mail.gmail.com>
Message-ID: <1226089312.3459.43.camel@metroid.rdu.redhat.com>

On Fri, 2008-11-07 at 17:40 +0000, Camilo Mesias wrote:
> A quick update on this. I successfully upgraded one machine about a
> week ago, so I tried another machine today and it had a problem
> booting during the install.
> 
> After all the packages had been downloaded and the 'reboot' button was
> pressed, grub was no longer able to come up. The word 'GRUB' was
> displayed and nothing else.
> 
> I booted with the F9 Live USB and did the following (sorry it doesn't
> help with diagnosis but it might help if anyone else has this problem)
> 
> mkdir /tmp/rootdir
> mount /dev/mapper/VolGroup00-LogVol00 /tmp/rootdir
> mount /dev/sda1 /tmp/rootdir/boot
> /tmp/rootdir/sbin/grub-install --root-directory=/tmp/rootdir /dev/sda
> 
> If there are any logs that might help diagnose the problem, let me
> know. I have one more desktop and one more laptop running F9 which I
> plan to preupgrade in the same way, Please let me know if there is
> anything I should note to help improve the process.

This is a GRUB bug that we've been unable to reproduce reliably, and
therefore haven't traced fully. It's often triggered by using the grub
--once flag, which is used by both preupgrade and suspend-to-disk
(hibernate). We've seen it happen with both of those things, but the
preupgrade case seems to be more frequent because it tends to also
involve upgrading GRUB at the same time.

As far as we've been able to trace it, *something* causes GRUB stage2
(or stage 1.5) to move its physical on-disk location. But we don't know
what. Nothing that we're doing to GRUB *should* cause that. But
something does, and then stage1 can't find the rest of GRUB, and we get
stuck with "GRUB" on-screen and an unbootable system.

Anyway. I've spent *weeks* trying to track that one down, bugging pjones
(our GRUB maintainer) and esandeen (our mad ext3/ext4 hacker) endlessly,
and never made any real progress. Reinstalling GRUB, as you did, is the
proper fix when this happens. But we still don't know what causes it,
and therefore how to keep it from happening in the first place.

Any further help or theories on this would be greatly appreciated.

-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/20081107/4cec90a4/attachment.bin>

From berrange at redhat.com  Fri Nov  7 20:22:17 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Fri, 7 Nov 2008 20:22:17 +0000
Subject: Concerns about 'provenpackager' and why I didn't mass ACL open
In-Reply-To: <4914A037.10803@gmail.com>
References: <49149A8D.3080608@redhat.com> <4914A037.10803@gmail.com>
Message-ID: <20081107202217.GE4734@redhat.com>

On Fri, Nov 07, 2008 at 12:08:23PM -0800, Toshio Kuratomi wrote:
> I cannot allay your concerns and I can see your point.  I'd like to
> mention, though, that func depends on the following packages with open acls:
> 
> pyOpenSSL, python, python-simplejson
> 
> So in terms of protecting against $EVIL, restricting provenpackager
> isn't very effective.
> 
> It is, effective for restricting people in provenpackager from making
> unaudited changes to your code, though.  So if you are a conscientious
> maintainer who is on top of their bug reports, restricting
> provenpackager could be good for everyone.  On the other hand, if you're
> a maintainer that has too many packages and other responsibilities and
> doesn't get around to fixing things (or at least showing presence on a
> bug) quickly, having provenpackager set is a definite detriment.

IMHO, provenpackager is the wrong solution to that problem. Rather than
having a large group of people with commit to (nearly) everything for
fixing minor issues, the focus should be on significantly increasing our
levels of co-maintainership. The ideal should be for every package in the 
distro to have at least 1 extra co-maintainer, or preferrably 3 or 4.
People with a little domain knowledge for the package who can handle 
both the low-hanging fruit the main maintainer misses, with less risk
of making mistakes due to lack of package specific knowledge. Sure it'd
take more people resources than 'provenpackager' solution, and likely 
require a big community publicity campaign to kick it off, but long
term it'd be more helpful & safer - particularly for 'infrastruture'
packages (python, perl, etc runtimes & important addon modules) and 
security sensitive packages (openssl, gnutls, func, koan, etc). 

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 mdehaan at redhat.com  Fri Nov  7 20:32:18 2008
From: mdehaan at redhat.com (Michael DeHaan)
Date: Fri, 07 Nov 2008 15:32:18 -0500
Subject: Concerns about 'provenpackager' and why I didn't mass ACL open
In-Reply-To: <1226088927.5146.54.camel@luminos.localdomain>
References: <49149A8D.3080608@redhat.com>
	<1226088927.5146.54.camel@luminos.localdomain>
Message-ID: <4914A5D2.2090809@redhat.com>

Jesse Keating wrote:
> On Fri, 2008-11-07 at 14:44 -0500, Michael DeHaan wrote:
>   
>> As I understand it, in general, provenpackager status requires packaging 
>> a certain number of packages (N).    In my opinion, this is insufficient 
>> and potentially dangerous and package access should be given under an 
>> "as needed" basis. 
>>     
>
> Small correction here.  Against my advise, the "has more than 5
> packages" mark was only used for the initial seeding of the
> provenpackager group.  From this point on, the way to get in is to
> request membership via the account system, and somebody already in the
> group has to approve the membership.  

This still seems a bit broad and unchecked to my liking.

The use cases for this are mainly what?   Maintaince of packages 
breaking other packages?

How large do we forsee this group being?

> It isn't the same sponsorship type
> thing that getting into packager has, once you approve somebody you're
> not ultimately responsible for them.  But we did want to make it
> something somebody has to explicitly ask for, rather than be
> auto-granted whether they want it or not.
>   
>> I am not really comfortable with opening that up.
>>
>> So, anyway, that's my logic ... if anyone can persuade me that releasing 
>> new code is /not/ possible through the provenpackager system, I think I 
>> could be persuaded to flip things, but right now, I can't see an 
>> advantage in doing so.
>>     
>
> For rawhide, somebody would be able to commit a change and do a build,
> and it would automatically go out in rawhide.  But for a released
> package, since it has to go through bodhi, only the "owner" can do bodhi
> updates at this time.  There are plans to enable co-maintainers to
> submit updates too, but that would again be specifically granted people,
> rather than members of a larger group.
>
> All that said, I don't think your logic is wrong, and I think it has
> been well thought out.  I just wanted other folks to know where you were
> coming from on these particular packages, mostly because it had seemed
> in the past you were very much in favor of a more open system.
>
>   

I'm definitely big on collaboration and openness and all that -- not so 
much on extending that decision as to when and what
to release of every software component.

If proven packagers cannot access non-rawhide updates, that's a 
reasonable check, but is EPEL still not exposed (i.e. can a proven packager
use the build system and then EPEL testing will pick up the code just 
like rawhide)?

I am basically looking at this in terms of the entire distro, and the 
potential for exploit -- those packages
are just the ones I keep an eye on to explain my actions there.

We obviously can watch the commit logs for package CVS, though something 
subtle has the chance to get
through.   I want to be sure our bases are covered.

--Michael



From mdehaan at redhat.com  Fri Nov  7 20:37:58 2008
From: mdehaan at redhat.com (Michael DeHaan)
Date: Fri, 07 Nov 2008 15:37:58 -0500
Subject: Concerns about 'provenpackager' and why I didn't mass ACL open
In-Reply-To: <20081107202217.GE4734@redhat.com>
References: <49149A8D.3080608@redhat.com> <4914A037.10803@gmail.com>
	<20081107202217.GE4734@redhat.com>
Message-ID: <4914A726.7050808@redhat.com>

Daniel P. Berrange wrote:
> On Fri, Nov 07, 2008 at 12:08:23PM -0800, Toshio Kuratomi wrote:
>   
>> I cannot allay your concerns and I can see your point.  I'd like to
>> mention, though, that func depends on the following packages with open acls:
>>
>> pyOpenSSL, python, python-simplejson
>>
>> So in terms of protecting against $EVIL, restricting provenpackager
>> isn't very effective.
>>
>> It is, effective for restricting people in provenpackager from making
>> unaudited changes to your code, though.  So if you are a conscientious
>> maintainer who is on top of their bug reports, restricting
>> provenpackager could be good for everyone.  On the other hand, if you're
>> a maintainer that has too many packages and other responsibilities and
>> doesn't get around to fixing things (or at least showing presence on a
>> bug) quickly, having provenpackager set is a definite detriment.
>>     
>
> IMHO, provenpackager is the wrong solution to that problem. Rather than
> having a large group of people with commit to (nearly) everything for
> fixing minor issues, the focus should be on significantly increasing our
> levels of co-maintainership. The ideal should be for every package in the 
> distro to have at least 1 extra co-maintainer, or preferrably 3 or 4.
> People with a little domain knowledge for the package who can handle 
> both the low-hanging fruit the main maintainer misses, with less risk
> of making mistakes due to lack of package specific knowledge. Sure it'd
> take more people resources than 'provenpackager' solution, and likely 
> require a big community publicity campaign to kick it off, but long
> term it'd be more helpful & safer - particularly for 'infrastruture'
> packages (python, perl, etc runtimes & important addon modules) and 
> security sensitive packages (openssl, gnutls, func, koan, etc). 
>
> Daniel
>   

Well said. Not just bringing up the problem but offering solutions.

How about we generate some reports on those packages that have one 
maintainer and ones that we need obviously need backup for?
Minor issues that don't require an immediate fix /should/ be addressed 
with the project (i.e. permissions look wrong in spec file, etc) rather 
than being changed in CVS by someone and issuing their own builds. That 
seems to be the responsible thing to do.

I assume Fedora release engineering folks already have 
something-other-than-provenpackager access for emergency use anyway?

--Michael



From camilo at mesias.co.uk  Fri Nov  7 20:46:38 2008
From: camilo at mesias.co.uk (Camilo Mesias)
Date: Fri, 7 Nov 2008 20:46:38 +0000
Subject: preupgrade F9 -> rawhide?
In-Reply-To: <1226089312.3459.43.camel@metroid.rdu.redhat.com>
References: <d551e0e20810261105u1fce4b2am7ead022a5c2f9c83@mail.gmail.com>
	<1225084095.3077.24.camel@zebes.localdomain>
	<d551e0e20810262348m2a94520eh562373b2df491b30@mail.gmail.com>
	<d551e0e20811070940k6277b1a4ufdf5f27add2c90b@mail.gmail.com>
	<1226089312.3459.43.camel@metroid.rdu.redhat.com>
Message-ID: <d551e0e20811071246g5ee473depaeaed3e3481aba84@mail.gmail.com>

> Any further help or theories on this would be greatly appreciated.

Is there a canonical command that will tell me if grub is in a
consistent state or not?

I'm guessing it's worth running such a command (if it exists) at the
point when preupgrade says "Reboot", and then at several points during
the shutdown sequence to see what happens.

Stop me if this is obvious or has been tried already, but as I said I
have two more systems to upgrade so it's worth experimenting a bit.



From cdahlin at redhat.com  Fri Nov  7 19:47:04 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Fri, 07 Nov 2008 14:47:04 -0500
Subject: Mass ACL open complete
Message-ID: <49149B38.5010203@redhat.com>

The mass ACL open has at last been completed. If you did not opt out of 
this change in pkgdb, your package is now open to all of the 
uber^H^Hprovenpackager group. The checkbox to opt in or out may still be 
present, but is no longer useful and should go away very shortly.

--CJD

_______________________________________________
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  Fri Nov  7 21:18:28 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 07 Nov 2008 13:18:28 -0800
Subject: Concerns about 'provenpackager' and why I didn't mass ACL open
In-Reply-To: <4914A726.7050808@redhat.com>
References: <49149A8D.3080608@redhat.com>
	<4914A037.10803@gmail.com>	<20081107202217.GE4734@redhat.com>
	<4914A726.7050808@redhat.com>
Message-ID: <4914B0A4.7070204@gmail.com>

Michael DeHaan wrote:
> Daniel P. Berrange wrote:
>> On Fri, Nov 07, 2008 at 12:08:23PM -0800, Toshio Kuratomi wrote:
>>  
>>> I cannot allay your concerns and I can see your point.  I'd like to
>>> mention, though, that func depends on the following packages with
>>> open acls:
>>>
>>> pyOpenSSL, python, python-simplejson
>>>
>>> So in terms of protecting against $EVIL, restricting provenpackager
>>> isn't very effective.
>>>
>>> It is, effective for restricting people in provenpackager from making
>>> unaudited changes to your code, though.  So if you are a conscientious
>>> maintainer who is on top of their bug reports, restricting
>>> provenpackager could be good for everyone.  On the other hand, if you're
>>> a maintainer that has too many packages and other responsibilities and
>>> doesn't get around to fixing things (or at least showing presence on a
>>> bug) quickly, having provenpackager set is a definite detriment.
>>>     
>>
>> IMHO, provenpackager is the wrong solution to that problem.

provenpackager is the wrong solution to many problems.  To me, the
provenpackager/packager split was a welcome thing because it allows us
to contain the *packager* group more strictly.

provenpackager is not as useful because it is broadly what the old
packager group was.  If we were designing a group-style solution
specifically to fit the need of having people who can step in and make
corrections to packages then I'd advocate for a level above
provenpackager that has stricter entrance requirements.

>> Rather than
>> having a large group of people with commit to (nearly) everything for
>> fixing minor issues, the focus should be on significantly increasing our
>> levels of co-maintainership. The ideal should be for every package in
>> the distro to have at least 1 extra co-maintainer, or preferrably 3 or 4.
>> People with a little domain knowledge for the package who can handle
>> both the low-hanging fruit the main maintainer misses, with less risk
>> of making mistakes due to lack of package specific knowledge. Sure it'd
>> take more people resources than 'provenpackager' solution, and likely
>> require a big community publicity campaign to kick it off, but long
>> term it'd be more helpful & safer - particularly for 'infrastruture'
>> packages (python, perl, etc runtimes & important addon modules) and
>> security sensitive packages (openssl, gnutls, func, koan, etc).

This makes a lot of theoretical sense but has had mixed results in
practice.  I can recall at least two drives to get comaintainers for
packages in the past.  This has had some more people sign up for
comaintainership for some packages but it hasn't gotten us near to 100%
coverage.  Some of the things it doesn't address:

Trust: If I'm a new contributor who just needed to get X.Y.Z in because
I just started using it on my shiny Fedora Desktop, I may not have any
contact with any other Fedora Contributor.  If I don't trust the
provenpackager group with this software, I'm not likely to trust an
unknown packager who asks to be a comaintainer either.  In fact, if
there was an over-all group of people who seldom make a mistake and know
packaging and software backward and forward, I'm more likely to entrust
that group with the ability to modify my package than the random packager.

Non-Responsiveness: If the package in question is getting bug reports
from people about the low-hanging packaging bugs but the bug reports are
 not being answered even if there are two or more maintainers, there
still needs to be a way for the changes to be applied to the packages.
We also need to have a means of adding comaintainers when the maintainer
does not answer the requests to add a comaintainer.

A non-responsive, forced comaintenance policy would help deal with the
second part of this problem.

Interest in fixing an error that is easily checked for:  Contributors
like Michael Schwendt have written and run checks for specific packaging
errors and then opened bugs for them against many packages.  When the
bug is not replied to, they have written patches.  When those aren't
acknoledged they have applied them where the acls are open.  When the
acls are closed the process breaks.

A non-responsive: forced acl opening policy would work for this.

Interest in a package:  If the packager is the only one interested in
doing work on a package, then there won't be a comaintainer.  That
doesn't mean that the package won't have common problems so that someone
looking for common problems won't need to get changes applied to it later.

> 
> Well said. Not just bringing up the problem but offering solutions.
> 
> How about we generate some reports on those packages that have one
> maintainer and ones that we need obviously need backup for?

Some reports I'd be interested in seeing would be:
1) Open bug reports vs number of comaintainers
2) Unanswered bug reports vs number of comaintainers
3) Newer upstream versions (in rawhide) vs number of comaintainers


> Minor issues that don't require an immediate fix /should/ be addressed
> with the project (i.e. permissions look wrong in spec file, etc) rather
> than being changed in CVS by someone and issuing their own builds. That
> seems to be the responsible thing to do.
> 
> I assume Fedora release engineering folks already have
> something-other-than-provenpackager access for emergency use anyway?
> 
At the moment, the cvsadmin group has the ability to make commits
despite what acls are in place.  I don't think we're often called on to
make changes to a package due to non-responsive maintainers, though.
Instead, we have opened the acls and orphaned packages for
non-responsiveness and people who are more interested in the package
have then taken over and done the work.

-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/20081107/e3b56ebb/attachment.sig>

From jkeating at redhat.com  Fri Nov  7 21:26:08 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 07 Nov 2008 13:26:08 -0800
Subject: Concerns about 'provenpackager' and why I didn't mass ACL open
In-Reply-To: <4914B0A4.7070204@gmail.com>
References: <49149A8D.3080608@redhat.com> <4914A037.10803@gmail.com>
	<20081107202217.GE4734@redhat.com> <4914A726.7050808@redhat.com>
	<4914B0A4.7070204@gmail.com>
Message-ID: <1226093168.5146.57.camel@luminos.localdomain>

On Fri, 2008-11-07 at 13:18 -0800, Toshio Kuratomi wrote:
> 
> Trust: If I'm a new contributor who just needed to get X.Y.Z in because
> I just started using it on my shiny Fedora Desktop, I may not have any
> contact with any other Fedora Contributor.  If I don't trust the
> provenpackager group with this software, I'm not likely to trust an
> unknown packager who asks to be a comaintainer either.  In fact, if
> there was an over-all group of people who seldom make a mistake and know
> packaging and software backward and forward, I'm more likely to entrust
> that group with the ability to modify my package than the random packager.

To be fair, when I first proposed new maintainer containment, this above
was my vision for the elevated access group.

Unfortunately FESCo chose to fill that group with a much larger set of
people with nothing but "number of packages" as a requirement.

-- 
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/20081107/a117ae20/attachment.sig>

From mdehaan at redhat.com  Fri Nov  7 21:59:41 2008
From: mdehaan at redhat.com (Michael DeHaan)
Date: Fri, 07 Nov 2008 16:59:41 -0500
Subject: Concerns about 'provenpackager' and why I didn't mass ACL open
In-Reply-To: <4914B0A4.7070204@gmail.com>
References: <49149A8D.3080608@redhat.com>	<4914A037.10803@gmail.com>	<20081107202217.GE4734@redhat.com>	<4914A726.7050808@redhat.com>
	<4914B0A4.7070204@gmail.com>
Message-ID: <4914BA4D.50603@redhat.com>


>>> Rather than
>>> having a large group of people with commit to (nearly) everything for
>>> fixing minor issues, the focus should be on significantly increasing our
>>> levels of co-maintainership. The ideal should be for every package in
>>> the distro to have at least 1 extra co-maintainer, or preferrably 3 or 4.
>>> People with a little domain knowledge for the package who can handle
>>> both the low-hanging fruit the main maintainer misses, with less risk
>>> of making mistakes due to lack of package specific knowledge. Sure it'd
>>> take more people resources than 'provenpackager' solution, and likely
>>> require a big community publicity campaign to kick it off, but long
>>> term it'd be more helpful & safer - particularly for 'infrastruture'
>>> packages (python, perl, etc runtimes & important addon modules) and
>>> security sensitive packages (openssl, gnutls, func, koan, etc).
>>>       
>
> This makes a lot of theoretical sense but has had mixed results in
> practice.  I can recall at least two drives to get comaintainers for
> packages in the past.  This has had some more people sign up for
> comaintainership for some packages but it hasn't gotten us near to 100%
> coverage.  Some of the things it doesn't address:
>
> Trust: If I'm a new contributor who just needed to get X.Y.Z in because
> I just started using it on my shiny Fedora Desktop, I may not have any
> contact with any other Fedora Contributor.  If I don't trust the
> provenpackager group with this software, I'm not likely to trust an
> unknown packager who asks to be a comaintainer either.  In fact, if
> there was an over-all group of people who seldom make a mistake and know
> packaging and software backward and forward, I'm more likely to entrust
> that group with the ability to modify my package than the random packager.
>   

I would hope the process here is to:

(A) email package-owner at fedoraproject.org about the version and/or file 
a bugzilla
(B) have a process to handle things if the owner is MIA

Let's take the "I need X.Y.Z" case.   If someone can't make a change in 
a week --- that in itself may not be a problem -- provenpackager may be 
trying to be helpful, but may not have the domain knowledge about the 
app -- say version X.Y.Z is not ready for prime time.  I would say "I 
need version X.Y.Z" now is not a strong enough reason to require an 
override by a provenpackager if a maintainer is not immediately 
reachable (say, on vacation).  If the package maintainer is orphaned by 
our definitions, it needs a maintainer.   I certaintly would not want 
someone updating the package and being suprised by that -- and then 
having to revert those changes because they were wrong for the package.

And yes, I'm not likely to trust someone I don't know to co-maintain a 
package, but likely are people that we /do/ know in many cases. 

provenpackagers seems to imply a whole new need for a level of oversight 
-- especially if any provenpackager can make more.

> Non-Responsiveness: If the package in question is getting bug reports
> from people about the low-hanging packaging bugs but the bug reports are
>  not being answered even if there are two or more maintainers, there
> still needs to be a way for the changes to be applied to the packages.
> We also need to have a means of adding comaintainers when the maintainer
> does not answer the requests to add a comaintainer.
>
> A non-responsive, forced comaintenance policy would help deal with the
> second part of this problem.
>
> Interest in fixing an error that is easily checked for:  Contributors
> like Michael Schwendt have written and run checks for specific packaging
> errors and then opened bugs for them against many packages.  When the
> bug is not replied to, they have written patches.  When those aren't
> acknoledged they have applied them where the acls are open.  When the
> acls are closed the process breaks.
>
>   


This /seems/ to be why we have the "MIA maintainer" policy.  If the 
maintainer is unresponsive we have a larger issue and a temporary fix to 
the package will still leave the package out of date, and it starts to 
be maintained ad-hoc and is likely to grow more out of date.

> A non-responsive: forced acl opening policy would work for this.
>
> Interest in a package:  If the packager is the only one interested in
> doing work on a package, then there won't be a comaintainer.  That
> doesn't mean that the package won't have common problems so that someone
> looking for common problems won't need to get changes applied to it later.
>   

I think it's covered by the above too, isn't it?

>   
>> Minor issues that don't require an immediate fix /should/ be addressed
>> with the project (i.e. permissions look wrong in spec file, etc) rather
>> than being changed in CVS by someone and issuing their own builds. That
>> seems to be the responsible thing to do.
>>
>> I assume Fedora release engineering folks already have
>> something-other-than-provenpackager access for emergency use anyway?
>>
>>     
> At the moment, the cvsadmin group has the ability to make commits
> despite what acls are in place.  I don't think we're often called on to
> make changes to a package due to non-responsive maintainers, though.
> Instead, we have opened the acls and orphaned packages for
> non-responsiveness and people who are more interested in the package
> have then taken over and done the work.
>   

Yeah, the orphan policy seems to solve most of the problems that I can see.

> -Toshio
>
>   



From a.badger at gmail.com  Fri Nov  7 22:52:16 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 07 Nov 2008 14:52:16 -0800
Subject: Concerns about 'provenpackager' and why I didn't mass ACL open
In-Reply-To: <4914BA4D.50603@redhat.com>
References: <49149A8D.3080608@redhat.com>	<4914A037.10803@gmail.com>	<20081107202217.GE4734@redhat.com>	<4914A726.7050808@redhat.com>	<4914B0A4.7070204@gmail.com>
	<4914BA4D.50603@redhat.com>
Message-ID: <4914C6A0.4080005@gmail.com>

Michael DeHaan wrote:
> 
>>>> Rather than
>>>> having a large group of people with commit to (nearly) everything for
>>>> fixing minor issues, the focus should be on significantly increasing
>>>> our
>>>> levels of co-maintainership. The ideal should be for every package in
>>>> the distro to have at least 1 extra co-maintainer, or preferrably 3
>>>> or 4.
>>>> People with a little domain knowledge for the package who can handle
>>>> both the low-hanging fruit the main maintainer misses, with less risk
>>>> of making mistakes due to lack of package specific knowledge. Sure it'd
>>>> take more people resources than 'provenpackager' solution, and likely
>>>> require a big community publicity campaign to kick it off, but long
>>>> term it'd be more helpful & safer - particularly for 'infrastruture'
>>>> packages (python, perl, etc runtimes & important addon modules) and
>>>> security sensitive packages (openssl, gnutls, func, koan, etc).
>>>>       
>>
>> This makes a lot of theoretical sense but has had mixed results in
>> practice.  I can recall at least two drives to get comaintainers for
>> packages in the past.  This has had some more people sign up for
>> comaintainership for some packages but it hasn't gotten us near to 100%
>> coverage.  Some of the things it doesn't address:
>>
>> Trust: If I'm a new contributor who just needed to get X.Y.Z in because
>> I just started using it on my shiny Fedora Desktop, I may not have any
>> contact with any other Fedora Contributor.  If I don't trust the
>> provenpackager group with this software, I'm not likely to trust an
>> unknown packager who asks to be a comaintainer either.  In fact, if
>> there was an over-all group of people who seldom make a mistake and know
>> packaging and software backward and forward, I'm more likely to entrust
>> that group with the ability to modify my package than the random
>> packager.
>>   
> 
> I would hope the process here is to:
> 
> (A) email package-owner at fedoraproject.org about the version and/or file
> a bugzilla
> (B) have a process to handle things if the owner is MIA
> 
You're looking at it from the opposite angle from what this paragraph
does.  You're playing the potential co-maintainer.  I was playing the
potential maintainer.  As a maintainer who doesn't know anyone in this
community I'd be much more likely to give access to a packager group
that Fedora says is made up of people who can teach me a thing or two
about packaging than a random contributor who shows up and says they'd
like to comaintain.  Having a "comaintainer campaign" is going to create
more of the latter.

The normal process of attaining comaintainers (you submit a patch.  You
submit another patch.  Either you ask for comaintainership or I get
tired of being your proxy) is separate from such a campaign and would
more or less follow the steps you outline.

> Let's take the "I need X.Y.Z" case.   If someone can't make a change in
> a week --- that in itself may not be a problem -- provenpackager may be
> trying to be helpful, but may not have the domain knowledge about the
> app -- say version X.Y.Z is not ready for prime time.  I would say "I
> need version X.Y.Z" now is not a strong enough reason to require an
> override by a provenpackager if a maintainer is not immediately
> reachable (say, on vacation).  If the package maintainer is orphaned by
> our definitions, it needs a maintainer.   I certaintly would not want
> someone updating the package and being suprised by that -- and then
> having to revert those changes because they were wrong for the package.
> 
Sure.  But how often does this happen?  We're pretty wary of stepping on
each other's toes.  Michael Schwendt's fixups are one example of things
that went through a long amount of time and multiple emails before
getting to cvs.  The FTBS process is another one.  Having a higher level
packaging group should be populated with people who are careful about
things, take time to think things through, are thorough about their
announcements of changes.

Note, that provenpackager does not meet these criteria IMHO.


> And yes, I'm not likely to trust someone I don't know to co-maintain a
> package, but likely are people that we /do/ know in many cases.
> provenpackagers seems to imply a whole new need for a level of oversight
> -- especially if any provenpackager can make more.
> 
I would argue that that's not true.  The people that are well known are
the people who are vocal on the mailing lists, on irc, and involved with
upstreams.  Other people are not.  If we have a campaign to get
comaintainers for every package we're going to quickly exhaust the
supply of known participants.

>> Non-Responsiveness: If the package in question is getting bug reports
>> from people about the low-hanging packaging bugs but the bug reports are
>>  not being answered even if there are two or more maintainers, there
>> still needs to be a way for the changes to be applied to the packages.
>> We also need to have a means of adding comaintainers when the maintainer
>> does not answer the requests to add a comaintainer.
>>
>> A non-responsive, forced comaintenance policy would help deal with the
>> second part of this problem.
>>
>> Interest in fixing an error that is easily checked for:  Contributors
>> like Michael Schwendt have written and run checks for specific packaging
>> errors and then opened bugs for them against many packages.  When the
>> bug is not replied to, they have written patches.  When those aren't
>> acknoledged they have applied them where the acls are open.  When the
>> acls are closed the process breaks.
>>
>>   
> 
> 
> This /seems/ to be why we have the "MIA maintainer" policy.  If the
> maintainer is unresponsive we have a larger issue and a temporary fix to
> the package will still leave the package out of date, and it starts to
> be maintained ad-hoc and is likely to grow more out of date.
> 
We can block a package from the next release if we know that it is
effectively orphaned.  Packages that are in released distros need to be
maintained until the package goes EOL.  Perhaps all we need is to
specify that orphaned packages will have their provenpackager ACL opened
 automatically and then the MIA policy will be sufficient.

>> A non-responsive: forced acl opening policy would work for this.
>>
>> Interest in a package:  If the packager is the only one interested in
>> doing work on a package, then there won't be a comaintainer.  That
>> doesn't mean that the package won't have common problems so that someone
>> looking for common problems won't need to get changes applied to it
>> later.
>>   
> 
> I think it's covered by the above too, isn't it?

Note that MIA does not address the question of getting a comaintainer on
every package which this email was a reply to.  I'm arguing that a
comaintainer campaign is insufficient as there will always be some
packages which are not interesting to more than one packager.

That said, MIA policy is a lot of work and effort.  Because of that, it
is mostly applied by people who want to take over maintainance of a
package.  People who are taking care of a bug that's widespread
throughout the distribution are concentrating on getting the most
packages fixed rather than getting a specific package fixed.  So
packages that should be orphaned and dropped from the distro aren't
getting dealt with.

Having a streamlined policy for orphaning packages once a release under
terms similar to the MIA policy could help.  ie: once a release, take
candidate bugs/packages for MIA status.  Send email to the owners of
those packages, file new bugzillas if necessary.  For those packages
that don't get responses, orphan them and give people an opportunity to
take them over before the orphan culling that happens near release time.

-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/20081107/ad19b5da/attachment.sig>

From s-t-rhbugzilla at wwwdotorg.org  Fri Nov  7 23:16:49 2008
From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren)
Date: Fri, 7 Nov 2008 16:16:49 -0700 (MST)
Subject: preupgrade F9 -> rawhide?
In-Reply-To: <1226089312.3459.43.camel@metroid.rdu.redhat.com>
References: <d551e0e20810261105u1fce4b2am7ead022a5c2f9c83@mail.gmail.com>
	<1225084095.3077.24.camel@zebes.localdomain>
	<d551e0e20810262348m2a94520eh562373b2df491b30@mail.gmail.com>
	<d551e0e20811070940k6277b1a4ufdf5f27add2c90b@mail.gmail.com>
	<1226089312.3459.43.camel@metroid.rdu.redhat.com>
Message-ID: <1226099810.26908.TMDA@tmda.severn.wwwdotorg.org>

On Fri, November 7, 2008 1:21 pm, Will Woods wrote:
> On Fri, 2008-11-07 at 17:40 +0000, Camilo Mesias wrote:
>> A quick update on this. I successfully upgraded one machine about a
>> week ago, so I tried another machine today and it had a problem
>> booting during the install.
>> ...
> ...
> As far as we've been able to trace it, *something* causes GRUB stage2
> (or stage 1.5) to move its physical on-disk location. But we don't know
> what. Nothing that we're doing to GRUB *should* cause that. But
> something does, and then stage1 can't find the rest of GRUB, and we get
> stuck with "GRUB" on-screen and an unbootable system.
>
> Anyway. I've spent *weeks* trying to track that one down, bugging pjones
> (our GRUB maintainer) and esandeen (our mad ext3/ext4 hacker) endlessly,
> and never made any real progress. Reinstalling GRUB, as you did, is the
> proper fix when this happens. But we still don't know what causes it,
> and therefore how to keep it from happening in the first place.

Can preupgrade just re-install grub itself at some suitable point. It
seems that'd work around the issue...



From paul at all-the-johnsons.co.uk  Fri Nov  7 23:20:55 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Fri, 07 Nov 2008 23:20:55 +0000
Subject: Building for rawhide
Message-ID: <1226100055.21103.277.camel@PB3.Linux>

Hi,

When I try to build for rawhide on koji, all I get is the dist-f10 is
locked error. What should I be using for building in rawhide?

TTFN

Paul
-- 
?Sie k?nnen mich aufreizen und wirklich hei? machen!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081107/7b220858/attachment.sig>

From laxathom at fedoraproject.org  Fri Nov  7 23:29:30 2008
From: laxathom at fedoraproject.org (Xavier Lamien)
Date: Sat, 8 Nov 2008 00:29:30 +0100
Subject: Building for rawhide
In-Reply-To: <1226100055.21103.277.camel@PB3.Linux>
References: <1226100055.21103.277.camel@PB3.Linux>
Message-ID: <62bc09df0811071529l2ac21876te75676f22c45d651@mail.gmail.com>

2008/11/8 Paul <paul at all-the-johnsons.co.uk>:
> Hi,
>
> When I try to build for rawhide on koji, all I get is the dist-f10 is
> locked error. What should I be using for building in rawhide?
>

it's dist-f11 now



-- 
Xavier.t Lamien
--
http://fedoraproject.org/wiki/XavierLamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB



From paul at xelerance.com  Fri Nov  7 23:44:37 2008
From: paul at xelerance.com (Paul Wouters)
Date: Fri, 7 Nov 2008 18:44:37 -0500 (EST)
Subject: FESCo Meeting Summary for 2008-11-05
In-Reply-To: <49148BDC.7020702@fedoraproject.org>
References: <1226016932.5758.3.camel@kennedy>
	<49148BDC.7020702@fedoraproject.org>
Message-ID: <alpine.LFD.1.10.0811071836480.20989@newtla.xelerance.com>

On Sat, 8 Nov 2008, Rahul Sundaram wrote:

>>       * After evaluating Empathy(1) with Colin Walters (walters) and
>>         Will Woods (wwoods), FESCo felt that Empathy wasn't ready at
>>         this time to become the default IM client for Fedora 10. This
>>         was due to some missing features and bugs in comparison to
>>         Pidgin.  The plan is to reevaluate Empathy for Fedora 11, since
>>         most of the current issues should be resolved for Gnome 2.26.

I notice on my F9 copy of Empathy that there is no support for MSN or AIM
on the default Empahty install i got (even though the 'help' claims supports
it).

More importantly, I see no OTR support. Which means this default app change
is like going from ssh to telnet.

> is not to the say, that I disagree with the decision itself. Just that it is 
> very very late.

I do disagree with a switch. And I do hate pidgin with a vengance.

Paul



From jkeating at redhat.com  Fri Nov  7 23:46:29 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 07 Nov 2008 15:46:29 -0800
Subject: Building for rawhide
In-Reply-To: <1226100055.21103.277.camel@PB3.Linux>
References: <1226100055.21103.277.camel@PB3.Linux>
Message-ID: <1226101589.5146.62.camel@luminos.localdomain>

On Fri, 2008-11-07 at 23:20 +0000, Paul wrote:
> 
> 
> When I try to build for rawhide on koji, all I get is the dist-f10 is
> locked error. What should I be using for building in rawhide?

cd to your module directory and run cvs up -d.  You should get a F-10
directory as well as some updates to common/.  This will setup the build
targets correctly for 'make build' from the various branches.

-- 
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/20081107/caf0c51f/attachment.sig>

From paul at xelerance.com  Fri Nov  7 23:52:10 2008
From: paul at xelerance.com (Paul Wouters)
Date: Fri, 7 Nov 2008 18:52:10 -0500 (EST)
Subject: End of bind-chroot-admin script
In-Reply-To: <1226079930.3997.12.camel@macbook.infradead.org>
References: <20081107120905.GA3188@evileye.atkac.englab.brq.redhat.com>
	<1226079930.3997.12.camel@macbook.infradead.org>
Message-ID: <alpine.LFD.1.10.0811071845170.20989@newtla.xelerance.com>

On Fri, 7 Nov 2008, David Woodhouse wrote:

> On Fri, 2008-11-07 at 13:09 +0100, Adam Tkac wrote:
>> bind-chroot-admin script should sync BIND configuration files to
>> chroot() directory. It was written with good intention but it has
>> never worked correctly in all situations. There is long history with
>> many broken configurations and urgent severity bugs.
>>
>> I'm going to remove this script from Fedora 11 (it is part of Fedora/RHEL
>> only, no other distro uses it). After removal, "standard" chroot
>> structure will be created when you install bind-chroot package. It
>> will contain all needed files for running named in chroot but admin
>> shall move needed configuration files to chroot manually. Do you have
>> any comments?

I'd rather see something replace it. For unbound, another caching resolver
with chroot (which got pushed in the repository a few days ago), the
same problem is solved by copying/linking/mounting files in the
chroot via the init script.

Updating the chroot becomes important for shipping DNSSEC keys via a package.
I am putting in a review request today for a new package 'dnssec-keys'
that allows people to easily enable/disable DNSSEC and preload the proper
keys for active TLD's. Things should get easier once the root is signed.

I was about to look at bind, since the DNSSEC key format for unbound and
bind is the same, so I am using one include file that will work on both
nameservers, once they copy it into their chroot environment.

Have a look at the unbound method, and see if that is something that could
also work for named?

Paul



From paul at xelerance.com  Sat Nov  8 02:35:15 2008
From: paul at xelerance.com (Paul Wouters)
Date: Fri, 7 Nov 2008 21:35:15 -0500 (EST)
Subject: FESCo Meeting Summary for 2008-11-05
In-Reply-To: <aed8ecaa0811071756l3731d218g6a55eecdddf36224@mail.gmail.com>
References: <1226016932.5758.3.camel@kennedy>
	<49148BDC.7020702@fedoraproject.org>
	<alpine.LFD.1.10.0811071836480.20989@newtla.xelerance.com>
	<aed8ecaa0811071756l3731d218g6a55eecdddf36224@mail.gmail.com>
Message-ID: <alpine.LFD.1.10.0811072110410.20989@newtla.xelerance.com>

On Sat, 8 Nov 2008, Stu Tomlinson wrote:

> On Fri, Nov 7, 2008 at 11:44 PM, Paul Wouters <paul at xelerance.com> wrote:
>> And I do hate pidgin with a vengance.
>
> May I ask why?

I've CC:ed the fedora list, though you gave me a private reply, because I
thought the large list of bugs might be useful to someone. Hope that's okay.

- It is the 2nd largest memory consuming application running (after firefox)
   using up 10% of my total memory:
    6698 paul      20   0  843m  96m  15m S  0.0  9.6  16:43.17 pidgin
   And I am not a super consumer, only 25 friends and 5 irc channels online now.
- It is prone to crashes and freezes (once every couple of days)
- Somewhere it lost "reconnect all accounts", and I need to click reconnect per
   account.
- Somewhere it lost the ability to be clever and allow typing when the 'focus'
   was on the receiving part of a conversation window. Now that typing is lost
   until you click on the small input box.
- Somewhere between gaim-beta 2.0 and pidgin it lost all concepts of
   workspaces, resulting in my buddy list being unmovable from the screen
   I started from (often with my conversation screen stuck in another workspace)
   This results in some really crappy things. If my buddy list is in workspace 1
   and I am working in worspace 2, and someone initiates a talk this happens. If
   I then later want to talk to someone else, i have to double flip through
   workspaces (or move one of the windows manually to the other workspace).
   The old gaim I could just left click the top icon twice to move the buddy list
   from one workspace to the other.
- Leaves a mess in /tmp/
- Combined user accounts lead to strange things due to pidgin seemingly picking
   randomly whch user account to use, which causes problems with OTR.
- The file transfer function is completely unreliable and often fails silently,
   eg the other end does not even see you're trying to send them a file.
- Buddylist window icon at the bottom turns blue ("attention") grabbing when
   some event has fixed itself, leaving me to wonder what requires my attention.
- When i have more tabs open then fit in the window, and I'm at the right most
   tab, and I got a new mesage in a tab that's scrolled off screen at the left,
   I can only go there by going through the tabs, causing them to lose the 'unread'
   state. 
- Once every couple of months, some accounts turns to "unvisible" (might be an
   MSN/AIM protocol thing, not something pidgin can help)
- irc handling of nicknames when briefly bouncing is bad. You'll fight with your
   own old nick, and with freenode you then lose the ability to privmsg.
   (not sure if that is fixiable in a client, not really pidgin's fault probably)

For the features I am using, I've mostly seen a downgrade in usability
since gaim2 beta, and a buggier client. I still use it because I think it is
the best client out there right now, but I'd jump ship if there was another
more usable client, though for me the OTR plugin is a mandatory feature I want
to have. I can't switch to empathy without it.

Paul



From tim.lauridsen at googlemail.com  Sat Nov  8 11:24:05 2008
From: tim.lauridsen at googlemail.com (Tim Lauridsen)
Date: Sat, 08 Nov 2008 12:24:05 +0100
Subject: Concerns about 'provenpackager' and why I didn't mass ACL open
In-Reply-To: <1226088927.5146.54.camel@luminos.localdomain>
References: <49149A8D.3080608@redhat.com>
	<1226088927.5146.54.camel@luminos.localdomain>
Message-ID: <491576D5.60706@googlemail.com>

Jesse Keating wrote:
> For rawhide, somebody would be able to commit a change and do a build,
> and it would automatically go out in rawhide.  But for a released
> package, since it has to go through bodhi, only the "owner" can do bodhi
> updates at this time.  There are plans to enable co-maintainers to
> submit updates too, but that would again be specifically granted people,
> rather than members of a larger group.
>   
Are you sure this is right, i maintain yum-utils upstream and in fedora, 
but Seth
is the owner. I have no troubles submitting  updates in bodhi to yum-utils.

Tim



From mschwendt at gmail.com  Sat Nov  8 12:06:42 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sat, 8 Nov 2008 13:06:42 +0100
Subject: Concerns about 'provenpackager' and why I didn't mass ACL open
In-Reply-To: <491576D5.60706@googlemail.com>
References: <49149A8D.3080608@redhat.com>
	<1226088927.5146.54.camel@luminos.localdomain>
	<491576D5.60706@googlemail.com>
Message-ID: <20081108130642.38865ff6.mschwendt@gmail.com>

On Sat, 08 Nov 2008 12:24:05 +0100, Tim Lauridsen wrote:

> Jesse Keating wrote:
> > For rawhide, somebody would be able to commit a change and do a build,
> > and it would automatically go out in rawhide.  But for a released
> > package, since it has to go through bodhi, only the "owner" can do bodhi
> > updates at this time.  There are plans to enable co-maintainers to
> > submit updates too, but that would again be specifically granted people,
> > rather than members of a larger group.
> >   
> Are you sure this is right, i maintain yum-utils upstream and in fedora, 
> but Seth
> is the owner. I have no troubles submitting  updates in bodhi to yum-utils.

When exactly did you do that the last time?
It's quite a recent change in the bodhi production instance, afaik.



From mschwendt at gmail.com  Sat Nov  8 12:23:25 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sat, 8 Nov 2008 13:23:25 +0100
Subject: Concerns about 'provenpackager' and why I didn't mass ACL open
In-Reply-To: <4914BA4D.50603@redhat.com>
References: <49149A8D.3080608@redhat.com> <4914A037.10803@gmail.com>
	<20081107202217.GE4734@redhat.com> <4914A726.7050808@redhat.com>
	<4914B0A4.7070204@gmail.com> <4914BA4D.50603@redhat.com>
Message-ID: <20081108132325.3b2e4fa9.mschwendt@gmail.com>

On Fri, 07 Nov 2008 16:59:41 -0500, Michael DeHaan wrote:

> I would hope the process here is to:
> 
> (A) email package-owner at fedoraproject.org about the version and/or file 
> a bugzilla

* There's a small group of people who complain to you if you mail them
privately instead of using bugzilla for EasyFix stuff. I do understand
that, but I hope they do watch their cvs commit notifications closely and
notice any changes merged by other committers, because if such changes
are overwritten (and that has happened before), the entire system fails.

* There's a larger group of people who can't handle all their bugzilla
traffic. They refer to bugzilla notification mails as "spam". This has
been discussed several times before. You can file a bug, and it won't be
looked at. You can file a bug and get a reply, but the issue won't be
fixed. You can ping such people repeatedly, and the issue would remain
unfixed even after many months. It's tiresome for reporters to deal
with such tickets and the additional disturbances from triagers or
scripts that threaten to close aging tickets for EOL.

> (B) have a process to handle things if the owner is MIA
> 
> Let's take the "I need X.Y.Z" case.

Are any examples known about X.Y.Z version upgrade requests that have not
been fulfilled and have been a problem before? Or is it just FUD, to
believe that someone from the provenpackager group (is that the final acl
group name?) runs mad in cvs/koji/bodhi and prepares such version upgrades
without a very good rationale and without permission from FESCo?



From rawhide at fedoraproject.org  Sat Nov  8 12:57:41 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sat,  8 Nov 2008 12:57:41 +0000 (UTC)
Subject: rawhide report: 20081108 changes
Message-ID: <20081108125741.A94CB1B8001@releng2.fedora.phx.redhat.com>

Compose started at Sat Nov  8 06:01:34 UTC 2008

Removed package gstreamer-plugins-pulse
Updated Packages:

anaconda-11.4.1.56-1
--------------------
* Thu Nov  6 17:00:00 2008 David Cantrell <dcantrell at redhat.com> - 11.4.1.56-1
- Don't have the key icon take up so much space on the LUKS dialog
  (#470338). (clumens)
- Avoid getting linux-base in the kernel list (katzj)
- Deselect groups when we reset things also (#469854) (katzj)
- make iscsi login code wait for udev to create the devices (#466661,
  - Set the correct path when using the directory chooser. (clumens)
- We always need a wait window, not just when the repo has a name. (clumens)
- Set initial state of IP configuration fields in text mode (#469933)
  (dcantrell)
- Prevent traceback when there are no network devices (#469339) (dcantrell)
- Indentation fix. (pjones)
- Let users edit net settings on network failure in stage 1 (#465887)
  (dcantrell)
- Move startNewt later to avoid printing extra messages on the screen
  (#469687). (clumens)


control-center-2.24.0.1-9.fc10
------------------------------
* Thu Nov  6 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0.1-9
- Remove a nonworking help button (#470375)


desktop-backgrounds-9.0.0-5
---------------------------
* Tue Nov  4 17:00:00 2008 Ray Strode <rstrode at redhat.com> 9.0.0-5
- Fix compat links after solar-backgrounds restructuring
  (bug 469789)


e2fsprogs-1.41.3-2.fc10
-----------------------
* Fri Nov  7 17:00:00 2008 Eric Sandeen <sandeen at redhat.com> 1.41.3-2
- Bump to revision 2, f10 was behind f9, oops.


gdm-2.24.0-12.fc10
------------------
* Fri Nov  7 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 1:2.24.0-12
- Make logout auditing work (#470269)


gnome-desktop-2.24.1-5.fc10
---------------------------
* Thu Nov  6 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.1-5
- Require gnome-python2-gnome (#469938)


qt-4.4.3-2.fc10
---------------
* Thu Nov  6 17:00:00 2008 Than Ngo <than at redhat.com> 4.4.3-2
- bz#468814, immodule selection behavior is unpredictable without QT_IM_MODULE,
  patch from Peng Wu
- backport fix from 4.5


Summary:
Added Packages: 0
Removed Packages: 1
Modified Packages: 7









Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot





From tim.lauridsen at googlemail.com  Sat Nov  8 13:40:37 2008
From: tim.lauridsen at googlemail.com (Tim Lauridsen)
Date: Sat, 08 Nov 2008 14:40:37 +0100
Subject: Concerns about 'provenpackager' and why I didn't mass ACL open
In-Reply-To: <20081108130642.38865ff6.mschwendt@gmail.com>
References: <49149A8D.3080608@redhat.com>	<1226088927.5146.54.camel@luminos.localdomain>	<491576D5.60706@googlemail.com>
	<20081108130642.38865ff6.mschwendt@gmail.com>
Message-ID: <491596D5.1030405@googlemail.com>

Michael Schwendt wrote:
> On Sat, 08 Nov 2008 12:24:05 +0100, Tim Lauridsen wrote:
>
>   
>> Jesse Keating wrote:
>>     
>>> For rawhide, somebody would be able to commit a change and do a build,
>>> and it would automatically go out in rawhide.  But for a released
>>> package, since it has to go through bodhi, only the "owner" can do bodhi
>>> updates at this time.  There are plans to enable co-maintainers to
>>> submit updates too, but that would again be specifically granted people,
>>> rather than members of a larger group.
>>>   
>>>       
>> Are you sure this is right, i maintain yum-utils upstream and in fedora, 
>> but Seth
>> is the owner. I have no troubles submitting  updates in bodhi to yum-utils.
>>     
>
> When exactly did you do that the last time?
> It's quite a recent change in the bodhi production instance, afaik.
>
>   
18/9.
So if it is recent, then i might be that way today,  so it seams that i 
will not be able push updates to yum-utils, until the
co-maintainer thing is implemented :(

Tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081108/438eb917/attachment.htm>

From opensource at till.name  Sat Nov  8 14:52:18 2008
From: opensource at till.name (Till Maas)
Date: Sat, 08 Nov 2008 15:52:18 +0100
Subject: Concerns about 'provenpackager' and why I didn't mass ACL open
In-Reply-To: <1226088927.5146.54.camel@luminos.localdomain>
References: <49149A8D.3080608@redhat.com>
	<1226088927.5146.54.camel@luminos.localdomain>
Message-ID: <200811081552.31122.opensource@till.name>

On Fri November 7 2008, Jesse Keating wrote:

> For rawhide, somebody would be able to commit a change and do a build,
> and it would automatically go out in rawhide.  But for a released
> package, since it has to go through bodhi, only the "owner" can do bodhi
> updates at this time.  There are plans to enable co-maintainers to
> submit updates too, but that would again be specifically granted people,
> rather than members of a larger group.

Can the comainters edit the update after it is created, e.g. add bugs and a 
description and request moves or is this now all left to the primary 
maintainer?

Is there are timeframe until it will be possible to completely comaintain 
packages again? E.g. I started to comaintain some packages where the original 
maintainers did not have enough time to completely maintain them, so if they 
are now again needed to do more work, this does not really work out. :-/

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/20081108/dc1e7c12/attachment.sig>

From kanarip at kanarip.com  Sat Nov  8 15:10:10 2008
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Sat, 08 Nov 2008 16:10:10 +0100
Subject: Concerns about 'provenpackager' and why I didn't mass ACL open
In-Reply-To: <1226088927.5146.54.camel@luminos.localdomain>
References: <49149A8D.3080608@redhat.com>
	<1226088927.5146.54.camel@luminos.localdomain>
Message-ID: <4915ABD2.40209@kanarip.com>

Jesse Keating wrote:
   But for a released
> package, since it has to go through bodhi, only the "owner" can do bodhi
> updates at this time.

I think that isn't entirely accurate:

https://admin.fedoraproject.org/pkgdb/packages/name/rubygem-fastthread#Fedora9

https://admin.fedoraproject.org/updates/rubygem-fastthread-1.0.1-1.fc9

/me goes to request co-maintainership for the package now.

Kind regards,

Jeroen van Meeuwen
-kanarip



From kevin.kofler at chello.at  Sat Nov  8 15:20:29 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 08 Nov 2008 16:20:29 +0100
Subject: Concerns about 'provenpackager' and why I didn't mass ACL open
References: <49149A8D.3080608@redhat.com>
	<1226088927.5146.54.camel@luminos.localdomain>
Message-ID: <gf4ant$81h$1@ger.gmane.org>

Jesse Keating wrote:
> For rawhide, somebody would be able to commit a change and do a build,
> and it would automatically go out in rawhide.  But for a released
> package, since it has to go through bodhi, only the "owner" can do bodhi
> updates at this time.  There are plans to enable co-maintainers to
> submit updates too, but that would again be specifically granted people,
> rather than members of a larger group.

Ouch... If that's true, that's a really big regression! Bodhi has allowed
comaintainers and even members of packager to submit updates for quite a
while now, and this has been seen as a good thing.

An "owner-only" policy is going to severely impede pushing KDE updates, as
we need to submit updates for a big group of packages with different
nominal primary maintainers (but all effectively team-maintained by us).
And they need to be pushed as a group because all the new KDE packages
depend on the new kdelibs (it's backwards- but not forwards-compatible).

Other updates which need to be pushed as grouped updates are also similarly
affected (e.g. xulrunner and dependent packages).

I think it is absolutely essential for at least people with explicit commit
access to be able to push updates.

        Kevin Kofler



From mschwendt at gmail.com  Sat Nov  8 15:53:51 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sat, 8 Nov 2008 16:53:51 +0100
Subject: Concerns about 'provenpackager' and why I didn't mass ACL open
In-Reply-To: <gf4ant$81h$1@ger.gmane.org>
References: <49149A8D.3080608@redhat.com>
	<1226088927.5146.54.camel@luminos.localdomain>
	<gf4ant$81h$1@ger.gmane.org>
Message-ID: <20081108165351.4f7e5b57.mschwendt@gmail.com>

On Sat, 08 Nov 2008 16:20:29 +0100, Kevin Kofler wrote:

> Jesse Keating wrote:
> > For rawhide, somebody would be able to commit a change and do a build,
> > and it would automatically go out in rawhide.  But for a released
> > package, since it has to go through bodhi, only the "owner" can do bodhi
> > updates at this time.  There are plans to enable co-maintainers to
> > submit updates too, but that would again be specifically granted people,
> > rather than members of a larger group.
> 
> Ouch... If that's true, that's a really big regression! Bodhi has allowed
> comaintainers and even members of packager to submit updates for quite a
> while now, and this has been seen as a good thing.

Here's where I heard about it for the first time:
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02281.html



From cmadams at hiwaay.net  Sat Nov  8 16:06:46 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Sat, 8 Nov 2008 10:06:46 -0600
Subject: CVS access for first-time packager?
Message-ID: <20081108160646.GA903002@hiwaay.net>

I submitted a package, got it reviewed, got sponsored, and submitted the
CVS request.  I got mail back that CVS was done, but I can't seem to log
in:

kosh:72:~/cvs$ fedora-cvs ufiformat
Checking out ufiformat from fedora cvs:
Error: Permission denied (publickey).
cvs [checkout aborted]: end of file from server (consult above messages if any)

I double-checked my SSH key in the account system, so I don't think that
is the problem.

This all went through right before the CVS outage Thursday night - could
something have fallen through the cracks with respect to setting up my
account?  Or did I miss a step somewhere?
-- 
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 jkeating at redhat.com  Sat Nov  8 16:29:48 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 08 Nov 2008 08:29:48 -0800
Subject: Concerns about 'provenpackager' and why I didn't mass ACL open
In-Reply-To: <1226088927.5146.54.camel@luminos.localdomain>
References: <49149A8D.3080608@redhat.com>
	<1226088927.5146.54.camel@luminos.localdomain>
Message-ID: <1226161788.13198.0.camel@luminos.localdomain>

On Fri, 2008-11-07 at 12:15 -0800, Jesse Keating wrote:
> For rawhide, somebody would be able to commit a change and do a build,
> and it would automatically go out in rawhide.  But for a released
> package, since it has to go through bodhi, only the "owner" can do bodhi
> updates at this time. 

Whoops.  This wasn't quite right.
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02282.html



-- 
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/20081108/8ccc74a7/attachment.sig>

From stu at nosnilmot.com  Sat Nov  8 16:50:37 2008
From: stu at nosnilmot.com (Stu Tomlinson)
Date: Sat, 08 Nov 2008 11:50:37 -0500
Subject: Pidgin (was Re: FESCo Meeting Summary for 2008-11-05)
In-Reply-To: <alpine.LFD.1.10.0811072110410.20989@newtla.xelerance.com>
References: <1226016932.5758.3.camel@kennedy>
	<49148BDC.7020702@fedoraproject.org>
	<alpine.LFD.1.10.0811071836480.20989@newtla.xelerance.com>
	<aed8ecaa0811071756l3731d218g6a55eecdddf36224@mail.gmail.com>
	<alpine.LFD.1.10.0811072110410.20989@newtla.xelerance.com>
Message-ID: <1226163037.5115.121.camel@sputnik.gravel>

On Fri, 2008-11-07 at 21:35 -0500, Paul Wouters wrote:
> On Sat, 8 Nov 2008, Stu Tomlinson wrote:
> 
> > On Fri, Nov 7, 2008 at 11:44 PM, Paul Wouters <paul at xelerance.com> wrote:
> >> And I do hate pidgin with a vengance.
> >
> > May I ask why?
> 
> I've CC:ed the fedora list, though you gave me a private reply, because I
> thought the large list of bugs might be useful to someone. Hope that's okay.

Fine, but I think bugzilla is a better place for bugs to be reported.

> - It is the 2nd largest memory consuming application running (after firefox)
>    using up 10% of my total memory:
>     6698 paul      20   0  843m  96m  15m S  0.0  9.6  16:43.17 pidgin
>    And I am not a super consumer, only 25 friends and 5 irc channels online now.

That's certainly unacceptable. There have been some reports of high
memory utilization but I have been unable to reproduce such high numbers
or track down any significant leaks recently. It is possible this is
caused by 3rd party plugins, I'd ask you to try disabling OTR to see if
it improves things but I suspect you don't want to do that :) What other
plugins do you use?

For comparison this is my current utilization:
 9315 stu       20   0  164m  52m  21m S    0  2.6  84:29.60 pidgin

That's with 17 accounts online on various protocols, ~200 buddies, 4
chat channels and 6 IM conversations open, and it's been running for 14
days.

> - It is prone to crashes and freezes (once every couple of days)

Have you reported bugs with backtraces for these?

> - Somewhere it lost "reconnect all accounts", and I need to click reconnect per
>    account.

This should not be necessary, as accounts should automatically reconnect
without user intervention, unless they disconnected for reasons Pidgin
determines are not automatically resolvable (such as incorrect
password). What sort of disconnection results in the accounts being in
this state?

> - Somewhere it lost the ability to be clever and allow typing when the 'focus'
>    was on the receiving part of a conversation window. Now that typing is lost
>    until you click on the small input box.

I can't reproduce that here.

> - Somewhere between gaim-beta 2.0 and pidgin it lost all concepts of
>    workspaces, resulting in my buddy list being unmovable from the screen
>    I started from (often with my conversation screen stuck in another workspace)
>    This results in some really crappy things. If my buddy list is in workspace 1
>    and I am working in worspace 2, and someone initiates a talk this happens. If
>    I then later want to talk to someone else, i have to double flip through
>    workspaces (or move one of the windows manually to the other workspace).
>    The old gaim I could just left click the top icon twice to move the buddy list
>    from one workspace to the other.

That is indeed annoying - unfortunately it is not something that changed
in Pidgin, but something that changed in the DE or WM or something else.
I'll try to dig into what it is and see if we can work around it in
Pidgin.

> - Leaves a mess in /tmp/

What sort of mess? I am not aware of anything Pidgin puts in /tmp - Gaim
used to a long time ago before we switched to using DBUS for remote
control.

> - Combined user accounts lead to strange things due to pidgin seemingly picking
>    randomly whch user account to use, which causes problems with OTR.

Pidgin picks the most 'available' buddy within a contact to send an IM,
if buddies are determined to be equally available, the 1st one listed in
the expanded contact is used. Drag and drop can be used to re-arrange
them.

> - The file transfer function is completely unreliable and often fails silently,
>    eg the other end does not even see you're trying to send them a file.

File transfer functionality varies by protocol, and also depends on what
client the other end is using. I agree it is not perfect. Can you be
more specific about what protocol(s) you see this on?

> - Buddylist window icon at the bottom turns blue ("attention") grabbing when
>    some event has fixed itself, leaving me to wonder what requires my attention.

This sounds like a bug - did you file a bug?

> - When i have more tabs open then fit in the window, and I'm at the right most
>    tab, and I got a new mesage in a tab that's scrolled off screen at the left,
>    I can only go there by going through the tabs, causing them to lose the 'unread'
>    state. 

You can right click on any tab to see a list of all tabs and jump direct
to the one you want.

> - Once every couple of months, some accounts turns to "unvisible" (might be an
>    MSN/AIM protocol thing, not something pidgin can help)

I haven't heard of this happening - did you file a bug?

> - irc handling of nicknames when briefly bouncing is bad. You'll fight with your
>    own old nick, and with freenode you then lose the ability to privmsg.
>    (not sure if that is fixiable in a client, not really pidgin's fault probably)

There is a plugin in the purple plugin pack called 'IRC Helper' that can
manage ghosting of nicks and authenticating to Nickserv
(yum install purple-plugin_pack) 

Regards,


Stu.



From lemenkov at gmail.com  Sat Nov  8 17:16:54 2008
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Sat, 8 Nov 2008 20:16:54 +0300
Subject: Pidgin (was Re: FESCo Meeting Summary for 2008-11-05)
In-Reply-To: <1226163037.5115.121.camel@sputnik.gravel>
References: <1226016932.5758.3.camel@kennedy>
	<49148BDC.7020702@fedoraproject.org>
	<alpine.LFD.1.10.0811071836480.20989@newtla.xelerance.com>
	<aed8ecaa0811071756l3731d218g6a55eecdddf36224@mail.gmail.com>
	<alpine.LFD.1.10.0811072110410.20989@newtla.xelerance.com>
	<1226163037.5115.121.camel@sputnik.gravel>
Message-ID: <adf480660811080916n68af22ffn8cb0f859912dba4f@mail.gmail.com>

2008/11/8, Stu Tomlinson <stu at nosnilmot.com>:
>  > - It is the 2nd largest memory consuming application running (after firefox)
>  >    using up 10% of my total memory:
>  >     6698 paul      20   0  843m  96m  15m S  0.0  9.6  16:43.17 pidgin
>  >    And I am not a super consumer, only 25 friends and 5 irc channels online now.

Oh come on! It's just a GTK applications (with, as usual, poor desing,
which in turn leads to high memory usage due to poor allocators,
complex internal structure, which leads to bugs which cannot be fixed
even by maintainers months and years, and so on).

Take a look - this is a Firefox with switched off memory cache and 8
opened tabs.

26819 petro     20   0  449m 299m  21m S  0.3 59.7   6:32.90 firefox

If we'll start complaining about memory consumption of GTK-based
monsters we'll spend all free time in useless conversations.

You shoud try to use some better alternatives. Try Psi, for example.
In any case there are tons of better XMPP clients (you're not using
proprietary protocols like oscar/msn/aim/etc, are you?). In case of
Firefox we don't have such obvious variants to switch to (mainly due
to Firefox extensions - real killer feature of this memory hungry
beast).

BTW does someone knows about those unlucky ISVs, who based significant
part of  their business on GTK?
-- 
With best regards!



From paul at xelerance.com  Sat Nov  8 18:39:53 2008
From: paul at xelerance.com (Paul Wouters)
Date: Sat, 8 Nov 2008 13:39:53 -0500 (EST)
Subject: Pidgin (was Re: FESCo Meeting Summary for 2008-11-05)
In-Reply-To: <adf480660811080916n68af22ffn8cb0f859912dba4f@mail.gmail.com>
References: <1226016932.5758.3.camel@kennedy>
	<49148BDC.7020702@fedoraproject.org>
	<alpine.LFD.1.10.0811071836480.20989@newtla.xelerance.com>
	<aed8ecaa0811071756l3731d218g6a55eecdddf36224@mail.gmail.com>
	<alpine.LFD.1.10.0811072110410.20989@newtla.xelerance.com>
	<1226163037.5115.121.camel@sputnik.gravel>
	<adf480660811080916n68af22ffn8cb0f859912dba4f@mail.gmail.com>
Message-ID: <alpine.LFD.1.10.0811081332460.20989@newtla.xelerance.com>

On Sat, 8 Nov 2008, Peter Lemenkov wrote:

>> >     6698 paul      20   0  843m  96m  15m S  0.0  9.6  16:43.17 pidgin
>> >    And I am not a super consumer, only 25 friends and 5 irc channels online now.
>
> Oh come on! It's just a GTK applications (with, as usual, poor desing,
> which in turn leads to high memory usage due to poor allocators,
> complex internal structure, which leads to bugs which cannot be fixed
> even by maintainers months and years, and so on).

I'm complaining because my machine actually runs out of memory after a
few weeks :P (Yes, my home desktop only has 1GB of RAM :)
And yes, restarting firefox tends to help :P

> You shoud try to use some better alternatives. Try Psi, for example.
> In any case there are tons of better XMPP clients (you're not using
> proprietary protocols like oscar/msn/aim/etc, are you?).

Apparently unlike you, I have friends :) So yes, although I prefer XMPP,
I also talk to people using proprietary evil central servers (hence my
insistence on needing OTR).

Paul



From debarshi.ray at gmail.com  Sat Nov  8 19:01:47 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Sun, 9 Nov 2008 00:31:47 +0530
Subject: libgnomecanvas owns %{_libdir}/libglade
In-Reply-To: <1226067740.3417.1.camel@localhost.localdomain>
References: <3170f42f0811062012v135f1766s4c8152cd26811383@mail.gmail.com>
	<20081107114035.0402300d@metropolis.intra.city-fan.org>
	<3170f42f0811070413g7e90fddq989ff28dfb05b964@mail.gmail.com>
	<1226067740.3417.1.camel@localhost.localdomain>
Message-ID: <3170f42f0811081101u82c56c3mb821282eaa8d16b2@mail.gmail.com>

>  It would probably be better if libglade2 owned %{libdir}/libglade and
> %{libdir}/libglade/2.0. Can you take care of that ?

I made the changes in Rawhide. Can we have the fix in Fedora 9 & 10 as
updates? Fedora 8 would be a bit too much, I guess?

Cheerio,
Debarshi



From mclasen at redhat.com  Sat Nov  8 19:15:14 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Sat, 08 Nov 2008 14:15:14 -0500
Subject: libgnomecanvas owns %{_libdir}/libglade
In-Reply-To: <3170f42f0811081101u82c56c3mb821282eaa8d16b2@mail.gmail.com>
References: <3170f42f0811062012v135f1766s4c8152cd26811383@mail.gmail.com>
	<20081107114035.0402300d@metropolis.intra.city-fan.org>
	<3170f42f0811070413g7e90fddq989ff28dfb05b964@mail.gmail.com>
	<1226067740.3417.1.camel@localhost.localdomain>
	<3170f42f0811081101u82c56c3mb821282eaa8d16b2@mail.gmail.com>
Message-ID: <1226171714.3881.0.camel@localhost.localdomain>

On Sun, 2008-11-09 at 00:31 +0530, Debarshi Ray wrote:
> >  It would probably be better if libglade2 owned %{libdir}/libglade and
> > %{libdir}/libglade/2.0. Can you take care of that ?
> 
> I made the changes in Rawhide. Can we have the fix in Fedora 9 & 10 as
> updates? Fedora 8 would be a bit too much, I guess?
> 

If you do the builds, I won't object...



From a.badger at gmail.com  Sat Nov  8 19:14:14 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sat, 08 Nov 2008 11:14:14 -0800
Subject: Concerns about 'provenpackager' and why I didn't mass ACL open
In-Reply-To: <20081108132325.3b2e4fa9.mschwendt@gmail.com>
References: <49149A8D.3080608@redhat.com>
	<4914A037.10803@gmail.com>	<20081107202217.GE4734@redhat.com>
	<4914A726.7050808@redhat.com>	<4914B0A4.7070204@gmail.com>
	<4914BA4D.50603@redhat.com>
	<20081108132325.3b2e4fa9.mschwendt@gmail.com>
Message-ID: <4915E506.8010502@gmail.com>

Michael Schwendt wrote:

> provenpackager (is that the final acl group name?)

Yes as in "I'm not going to willingly change this again".

If we need another level of packager power, then there will of course be
another group to go along with that.

-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/20081108/47469a8b/attachment.sig>

From sgrubb at redhat.com  Sat Nov  8 19:19:20 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Sat, 8 Nov 2008 14:19:20 -0500
Subject: Who moved my bug?
In-Reply-To: <20081107111727.GA10541@mokona.greysector.net>
References: <200811061243.49188.opensource@till.name>
	<1226017819.5758.11.camel@kennedy>
	<20081107111727.GA10541@mokona.greysector.net>
Message-ID: <200811081419.20620.sgrubb@redhat.com>

On Friday 07 November 2008 06:17:28 Dominik 'Rathann' Mierzejewski wrote:
> > Or the thread were the proposal was originally discussed by the
> > community before it was brought to FESCo.
> >
> > https://www.redhat.com/archives/fedora-devel-list/2008-January/msg01359.h
> >tml
>
> You can't expect every packager to read every mail on fedora-devel-list.
> There is simply too much traffic here, not to mention the contents of any
> longer discussion have little to do with the original subject.

I agree with this. I don't like my bugs being changed from NEW to ASSIGNED 
unless I'm working on the bugs. Please use the triaged keyword so that bug 
zappers can do their thing without interrupting maintainers. There is 
absolutely no way that I can read all the Fedora mail and participate in the 
relevant discussions and do my job. I easily get > 800 emails a day.

We had this discussion a couple weeks ago and people decided on the test list 
to start using the triaged keyword.

https://www.redhat.com/archives/fedora-test-list/2008-October/msg00221.html

What happened? This really is an unnecessary irritation.

Thanks,
-Steve



From walters at verbum.org  Sat Nov  8 19:36:38 2008
From: walters at verbum.org (Colin Walters)
Date: Sat, 8 Nov 2008 14:36:38 -0500
Subject: End of bind-chroot-admin script
In-Reply-To: <alpine.LFD.1.10.0811071845170.20989@newtla.xelerance.com>
References: <20081107120905.GA3188@evileye.atkac.englab.brq.redhat.com>
	<1226079930.3997.12.camel@macbook.infradead.org>
	<alpine.LFD.1.10.0811071845170.20989@newtla.xelerance.com>
Message-ID: <faa16b610811081136g7544549fw6543240a1c135be@mail.gmail.com>

On Fri, Nov 7, 2008 at 6:52 PM, Paul Wouters <paul at xelerance.com> wrote:
>
> I'd rather see something replace it.

SELinux obsoletes this use of chroot for security.  Every daemon
doesn't need to grow its own private copy of the OS infrastructure.



From debarshi.ray at gmail.com  Sat Nov  8 20:24:01 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Sun, 9 Nov 2008 01:54:01 +0530
Subject: libgnomecanvas owns %{_libdir}/libglade
In-Reply-To: <1226171714.3881.0.camel@localhost.localdomain>
References: <3170f42f0811062012v135f1766s4c8152cd26811383@mail.gmail.com>
	<20081107114035.0402300d@metropolis.intra.city-fan.org>
	<3170f42f0811070413g7e90fddq989ff28dfb05b964@mail.gmail.com>
	<1226067740.3417.1.camel@localhost.localdomain>
	<3170f42f0811081101u82c56c3mb821282eaa8d16b2@mail.gmail.com>
	<1226171714.3881.0.camel@localhost.localdomain>
Message-ID: <3170f42f0811081224p9e6e7ffpfca6970eee4015e6@mail.gmail.com>

>> >  It would probably be better if libglade2 owned %{libdir}/libglade and
>> > %{libdir}/libglade/2.0. Can you take care of that ?

>> I made the changes in Rawhide. Can we have the fix in Fedora 9 & 10 as
>> updates? Fedora 8 would be a bit too much, I guess?

> If you do the builds, I won't object...

Tagged and built for F-8, F-9 and F-10 now. I put in a versioned
Requires on libglade2 in libgnomecanvas to avoid %{_libdir}/libglade
from becoming unowned if someone only updated libgnomecanvas. However
I did not bump the BuildRequires on libglade2-devel since the new
libglade2 packages are not yet in the buildroots and the directory
issue won't make any difference.

Thanks,
Debarshi



From paul at xelerance.com  Sat Nov  8 20:47:31 2008
From: paul at xelerance.com (Paul Wouters)
Date: Sat, 8 Nov 2008 15:47:31 -0500 (EST)
Subject: End of bind-chroot-admin script
In-Reply-To: <faa16b610811081136g7544549fw6543240a1c135be@mail.gmail.com>
References: <20081107120905.GA3188@evileye.atkac.englab.brq.redhat.com>
	<1226079930.3997.12.camel@macbook.infradead.org>
	<alpine.LFD.1.10.0811071845170.20989@newtla.xelerance.com>
	<faa16b610811081136g7544549fw6543240a1c135be@mail.gmail.com>
Message-ID: <alpine.LFD.1.10.0811081546260.20989@newtla.xelerance.com>

On Sat, 8 Nov 2008, Colin Walters wrote:

> On Fri, Nov 7, 2008 at 6:52 PM, Paul Wouters <paul at xelerance.com> wrote:
>>
>> I'd rather see something replace it.
>
> SELinux obsoletes this use of chroot for security.  Every daemon
> doesn't need to grow its own private copy of the OS infrastructure.

You're absolutely right. And in fact, it makes a lot of things for
me a lot easier. I'll look into getting unbound proper SElinux
policies, though if anyone has pointers for me, those would be
appreciated.

Paul



From jesselist at gmail.com  Sat Nov  8 20:52:30 2008
From: jesselist at gmail.com (Jesse Hutton)
Date: Sat, 8 Nov 2008 15:52:30 -0500
Subject: Rubygems >= 1.3.0 for Merb
Message-ID: <7d74b2790811081252m56b86b5al6c2153ee7eed79ad@mail.gmail.com>

Merb 1.0 was just released yesterday and it requires Rubygems >= 3.0.

I have very little experience messing with spec files, but I tried modifying
rubygems-1.2.0-2.fc10.src.rpm to build the 1.3.1 tgz. I adapted the noarch
patch to rubygems-1.3.1, but ran into some difficulty building the rpm. The
patch applied fine, but the install files seemed to be in different
directories than what was expected in the spec file (the gem binary was in
/bin and ubygems.rb, rubygems.rb, rubygems, and rubyconfig also were in
paths without a '/usr' prefix). After adjusting rubygems.spec to find the
files in the right directories, it built and installed. But, perhaps
unsurprisingly, stuff was in the wrong directory, eg gem was in /bin, etc.

I am running Rawhide (up to date as of today, 11/8) on x86_64, so the noarch
patch does affect where gems end up on my system. Does anyone know how to
build rubygems-1.3.1 correctly into an rpm? Or will 1.3.1 be making it's way
into F10 in the near future?

Jesse
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081108/85cecdb8/attachment.htm>

From lemenkov at gmail.com  Sat Nov  8 20:57:25 2008
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Sat, 8 Nov 2008 23:57:25 +0300
Subject: Pidgin (was Re: FESCo Meeting Summary for 2008-11-05)
In-Reply-To: <alpine.LFD.1.10.0811081332460.20989@newtla.xelerance.com>
References: <1226016932.5758.3.camel@kennedy>
	<49148BDC.7020702@fedoraproject.org>
	<alpine.LFD.1.10.0811071836480.20989@newtla.xelerance.com>
	<aed8ecaa0811071756l3731d218g6a55eecdddf36224@mail.gmail.com>
	<alpine.LFD.1.10.0811072110410.20989@newtla.xelerance.com>
	<1226163037.5115.121.camel@sputnik.gravel>
	<adf480660811080916n68af22ffn8cb0f859912dba4f@mail.gmail.com>
	<alpine.LFD.1.10.0811081332460.20989@newtla.xelerance.com>
Message-ID: <adf480660811081257l3d9b2093g6c80f18b316a90a7@mail.gmail.com>

2008/11/8, Paul Wouters <paul at xelerance.com>:
> > You shoud try to use some better alternatives. Try Psi, for example.
> > In any case there are tons of better XMPP clients (you're not using
> > proprietary protocols like oscar/msn/aim/etc, are you?).
> >
>
>  Apparently unlike you, I have friends :) So yes, although I prefer XMPP,
>  I also talk to people using proprietary evil central servers (hence my
>  insistence on needing OTR).

Heh :)
Two common geek's mistakes:

* Friends == proprietary IM system's contacts
* 99% of people using proprietary IM systems :)


In any case  this is offtopic. Nevertheless, since 99% posts in recent
100+ threads in fedora-devel are also offtopic (weren't tightly
associated with fedora development), does it still matters? :)
-- 
With best regards!



From konrad at tylerc.org  Sat Nov  8 21:00:09 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Sat, 8 Nov 2008 14:00:09 -0700
Subject: Rubygems >= 1.3.0 for Merb
In-Reply-To: <7d74b2790811081252m56b86b5al6c2153ee7eed79ad@mail.gmail.com>
References: <7d74b2790811081252m56b86b5al6c2153ee7eed79ad@mail.gmail.com>
Message-ID: <200811081300.10256.konrad@tylerc.org>

On Saturday 08 November 2008 12:52:30 pm Jesse Hutton wrote:
> Merb 1.0 was just released yesterday and it requires Rubygems >= 3.0.
>
> I have very little experience messing with spec files, but I tried
> modifying rubygems-1.2.0-2.fc10.src.rpm to build the 1.3.1 tgz. I adapted
> the noarch patch to rubygems-1.3.1, but ran into some difficulty building
> the rpm. The patch applied fine, but the install files seemed to be in
> different directories than what was expected in the spec file (the gem
> binary was in /bin and ubygems.rb, rubygems.rb, rubygems, and rubyconfig
> also were in paths without a '/usr' prefix). After adjusting rubygems.spec
> to find the files in the right directories, it built and installed. But,
> perhaps unsurprisingly, stuff was in the wrong directory, eg gem was in
> /bin, etc.
>
> I am running Rawhide (up to date as of today, 11/8) on x86_64, so the
> noarch patch does affect where gems end up on my system. Does anyone know
> how to build rubygems-1.3.1 correctly into an rpm? Or will 1.3.1 be making
> it's way into F10 in the near future?
>
> Jesse

David Lutterkort (dlutter BOGUS AT redhat DOT com (remove the BOGUS)) is the 
maintainer for rubygems; if you need a newer version you should file a bug 
against rubygems.

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




From cmadams at hiwaay.net  Sat Nov  8 21:08:05 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Sat, 8 Nov 2008 15:08:05 -0600
Subject: CVS access for first-time packager?
In-Reply-To: <20081108160646.GA903002@hiwaay.net>
References: <20081108160646.GA903002@hiwaay.net>
Message-ID: <20081108210805.GB903002@hiwaay.net>

Once upon a time, Chris Adams <cmadams at hiwaay.net> said:
> I submitted a package, got it reviewed, got sponsored, and submitted the
> CVS request.  I got mail back that CVS was done, but I can't seem to log
> in:

Well, somebody did something, because it is working now.  Thanks!
-- 
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 debarshi.ray at gmail.com  Sat Nov  8 21:14:55 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Sun, 9 Nov 2008 02:44:55 +0530
Subject: Non-responsive maintainer process for Damien Durand
Message-ID: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>

I would like to initiate the non-responsive maintainer policy [1]
against Damien Durand (CC'ed). Damien has not touched most of his
packages [2] for the last one year. Significantly, Pessulus was not
updated from 2.23.x to 2.24.x, while libgtksourceviewmm has also
missed a few upstream releases. An effort was made to contact by
filing a bug against 'gnubiff': https://bugzilla.redhat.com/464012
However there has been no response till now.

Here is another bug pending response for a long time:
https://bugzilla.redhat.com/257721

Happy hacking,
Debarshi

[1] https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers
[2] https://admin.fedoraproject.org/pkgdb/users/packages/splinux



From jesselist at gmail.com  Sat Nov  8 21:19:11 2008
From: jesselist at gmail.com (Jesse Hutton)
Date: Sat, 8 Nov 2008 16:19:11 -0500
Subject: Rubygems >= 1.3.0 for Merb
In-Reply-To: <200811081300.10256.konrad@tylerc.org>
References: <7d74b2790811081252m56b86b5al6c2153ee7eed79ad@mail.gmail.com>
	<200811081300.10256.konrad@tylerc.org>
Message-ID: <7d74b2790811081319l6710bd96v3542dbcde59b5f42@mail.gmail.com>

Thanks, I filed a bug:

https://bugzilla.redhat.com/show_bug.cgi?id=470688

On Sat, Nov 8, 2008 at 4:00 PM, Conrad Meyer <konrad at tylerc.org> wrote:

> On Saturday 08 November 2008 12:52:30 pm Jesse Hutton wrote:
> > Merb 1.0 was just released yesterday and it requires Rubygems >= 3.0.
> >
> > I have very little experience messing with spec files, but I tried
> > modifying rubygems-1.2.0-2.fc10.src.rpm to build the 1.3.1 tgz. I adapted
> > the noarch patch to rubygems-1.3.1, but ran into some difficulty building
> > the rpm. The patch applied fine, but the install files seemed to be in
> > different directories than what was expected in the spec file (the gem
> > binary was in /bin and ubygems.rb, rubygems.rb, rubygems, and rubyconfig
> > also were in paths without a '/usr' prefix). After adjusting
> rubygems.spec
> > to find the files in the right directories, it built and installed. But,
> > perhaps unsurprisingly, stuff was in the wrong directory, eg gem was in
> > /bin, etc.
> >
> > I am running Rawhide (up to date as of today, 11/8) on x86_64, so the
> > noarch patch does affect where gems end up on my system. Does anyone know
> > how to build rubygems-1.3.1 correctly into an rpm? Or will 1.3.1 be
> making
> > it's way into F10 in the near future?
> >
> > Jesse
>
> David Lutterkort (dlutter BOGUS AT redhat DOT com (remove the BOGUS)) is
> the
> maintainer for rubygems; if you need a newer version you should file a bug
> against rubygems.
>
> Regards,
> --
> Conrad Meyer <konrad at tylerc.org>
>
>
> --
> 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/20081108/62f0068b/attachment.htm>

From wolfy at nobugconsulting.ro  Sat Nov  8 21:20:47 2008
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Sat, 08 Nov 2008 23:20:47 +0200
Subject: Pidgin (was Re: FESCo Meeting Summary for 2008-11-05)
In-Reply-To: <1226163037.5115.121.camel@sputnik.gravel>
References: <1226016932.5758.3.camel@kennedy>	<49148BDC.7020702@fedoraproject.org>	<alpine.LFD.1.10.0811071836480.20989@newtla.xelerance.com>	<aed8ecaa0811071756l3731d218g6a55eecdddf36224@mail.gmail.com>	<alpine.LFD.1.10.0811072110410.20989@newtla.xelerance.com>
	<1226163037.5115.121.camel@sputnik.gravel>
Message-ID: <491602AF.2000004@nobugconsulting.ro>


>> - Somewhere it lost "reconnect all accounts", and I need to click reconnect per
>>    account.
>>     
>
> This should not be necessary, as accounts should automatically reconnect
> without user intervention, unless they disconnected for reasons Pidgin
> determines are not automatically resolvable (such as incorrect
> password). What sort of disconnection results in the accounts being in
> this state?
>   
happened to me, too. I am constantly connected to gtalk, YM and ICQ and 
sometimes I am simply disconnected and not reconnected to any of them 
(and it is for sure not a local network problem, as anything else but 
pidgin works ). However I am almost sure that I haven't seen this 
problem since upgrading to 2.5.2


>> - Leaves a mess in /tmp/
>>     
>
> What sort of mess? I am not aware of anything Pidgin puts in /tmp - Gaim
> used to a long time ago before we switched to using DBUS for remote
> control.
>   
I haven't seen anything left by pidgin in /tmp either...


>> - The file transfer function is completely unreliable and often fails silently,
>>    eg the other end does not even see you're trying to send them a file.
>>     
>
> File transfer functionality varies by protocol, and also depends on what
> client the other end is using. I agree it is not perfect. Can you be
> more specific about what protocol(s) you see this on?
>   

I have huge problems with transfers via YM. I can understand that I 
cannot see the photos shared by people using the oficial YM client (the 
"share photos" option), but file transfers sometimes work, sometimes 
don't. I have been unable to find a repetitive pattern. In the beginning 
I thought it's related to me being  behind a NAT. Then I thought it's my 
firewall. But I was surprised to see that transfers with other pidgin 
users work (more often than not). And after a while I realized that even 
Windows people can send me files... sometimes. Even when both me and my 
conversation partner are NATed. But the big problem is "sometimes". 
Bottom line, I can only assume it's a matter of incompatibility among 
protocols and that the success of the transfer is dependent on the YM 
version used by the Windows user who attempts to send me the file.




From a.badger at gmail.com  Sat Nov  8 21:25:36 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sat, 08 Nov 2008 13:25:36 -0800
Subject: CVS access for first-time packager?
In-Reply-To: <20081108210805.GB903002@hiwaay.net>
References: <20081108160646.GA903002@hiwaay.net>
	<20081108210805.GB903002@hiwaay.net>
Message-ID: <491603D0.5090606@gmail.com>

Chris Adams wrote:
> Once upon a time, Chris Adams <cmadams at hiwaay.net> said:
>> I submitted a package, got it reviewed, got sponsored, and submitted the
>> CVS request.  I got mail back that CVS was done, but I can't seem to log
>> in:
> 
> Well, somebody did something, because it is working now.  Thanks!

ricky found that cron on the cvs server was having some issues.  He
restarted the cron daemon and hopefully things are straightened 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/20081108/6ebfa687/attachment.sig>

From jos at xos.nl  Sat Nov  8 22:16:40 2008
From: jos at xos.nl (Jos Vos)
Date: Sat, 08 Nov 2008 23:16:40 +0100
Subject: Flash 10 in 64-bit F9: does it work?
Message-ID: <200811082216.mA8MGeSh004187@jasmine.xos.nl>

Hi,

Did anyone manage to get flash 10 working on 64-bit F9?  Note that
I didn't try on 32-bit yet, so I can't comment on that (yet).  But
on 64-bit, the flash 10 plugin is loaded (using nspluginwrapper etc.)
and listed in Firefox.  But as soon as I visit a flash page, it gives
error messages about not finding "soundwrapper" in my $PATH and it
doesn't display anything.

Suggestions?
Thanks,

--
--    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 wolfy at nobugconsulting.ro  Sat Nov  8 22:21:27 2008
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Sun, 09 Nov 2008 00:21:27 +0200
Subject: Flash 10 in 64-bit F9: does it work?
In-Reply-To: <200811082216.mA8MGeSh004187@jasmine.xos.nl>
References: <200811082216.mA8MGeSh004187@jasmine.xos.nl>
Message-ID: <491610E7.50704@nobugconsulting.ro>

On 11/09/2008 12:16 AM, Jos Vos wrote:
> Hi,
>
> Did anyone manage to get flash 10 working on 64-bit F9?  Note that
> I didn't try on 32-bit yet, so I can't comment on that (yet).  But
> on 64-bit, the flash 10 plugin is loaded (using nspluginwrapper etc.)
> and listed in Firefox.  But as soon as I visit a flash page, it gives
> error messages about not finding "soundwrapper" in my $PATH and it
> doesn't display anything.
>   
    Not answering directly to your question, but I tested it on 
F7/x86_64 and Centos 5/x86_64, but with Firefox/32 . On both systems ff 
crashed instantaneously when loading the flash10 plugin. I am still 
using flash-plugin-9.0.124.0-release.i386



From jos at xos.nl  Sat Nov  8 22:26:32 2008
From: jos at xos.nl (Jos Vos)
Date: Sat, 8 Nov 2008 23:26:32 +0100
Subject: Flash 10 in 64-bit F9: does it work?
In-Reply-To: <491610E7.50704@nobugconsulting.ro>
References: <200811082216.mA8MGeSh004187@jasmine.xos.nl>
	<491610E7.50704@nobugconsulting.ro>
Message-ID: <20081108222632.GA4209@jasmine.xos.nl>

On Sun, Nov 09, 2008 at 12:21:27AM +0200, Manuel Wolfshant wrote:

>    Not answering directly to your question, but I tested it on 
> F7/x86_64 and Centos 5/x86_64, but with Firefox/32 . On both systems ff 
> crashed instantaneously when loading the flash10 plugin. I am still 
> using flash-plugin-9.0.124.0-release.i386

I just heard from someone that it seems to work fine on 32-bit F9.
Firefox on 64-bit F10 doesn't crash, but it doesn't work.

-- 
--    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 cmadams at hiwaay.net  Sat Nov  8 22:33:08 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Sat, 8 Nov 2008 16:33:08 -0600
Subject: Flash 10 in 64-bit F9: does it work?
In-Reply-To: <200811082216.mA8MGeSh004187@jasmine.xos.nl>
References: <200811082216.mA8MGeSh004187@jasmine.xos.nl>
Message-ID: <20081108223308.GC903002@hiwaay.net>

Once upon a time, Jos Vos <jos at xos.nl> said:
> Did anyone manage to get flash 10 working on 64-bit F9?  Note that
> I didn't try on 32-bit yet, so I can't comment on that (yet).  But
> on 64-bit, the flash 10 plugin is loaded (using nspluginwrapper etc.)
> and listed in Firefox.  But as soon as I visit a flash page, it gives
> error messages about not finding "soundwrapper" in my $PATH and it
> doesn't display anything.

It is working for me on F9/x86_64.  I didn't do anything special; I have
the Adobe repo in my yum config and got flash-plugin-10.0.12.36-release
with a yum update.
-- 
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 pablo.martin-gomez at laposte.net  Sat Nov  8 22:48:12 2008
From: pablo.martin-gomez at laposte.net (Martin-Gomez Pablo)
Date: Sat, 8 Nov 2008 23:48:12 +0100
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
Message-ID: <20081108234812.6b327e4f@laposte.net>

Le Sun, 9 Nov 2008 02:44:55 +0530,
"Debarshi Ray" <debarshi.ray at gmail.com> a ?crit :

> 
> I would like to initiate the non-responsive maintainer policy [1]
> against Damien Durand (CC'ed). Damien has not touched most of his
> packages [2] for the last one year. Significantly, Pessulus was not
> updated from 2.23.x to 2.24.x, while libgtksourceviewmm has also
> missed a few upstream releases. An effort was made to contact by
> filing a bug against 'gnubiff': https://bugzilla.redhat.com/464012
> However there has been no response till now.
It's useless, he has change his email some time ago. As he cames
sporadically on the french fedora channel, I could contact him : he
completely give up his contribution for fedora (he was a great geek,
he decided to came back to the real live, you know :-)); but he has
some laziness to orphan his packages  (our pressure seems to be
ineficient).

So go ahead in this process, i'm supporting you.
> 
> Here is another bug pending response for a long time:
> https://bugzilla.redhat.com/257721
> 
> Happy hacking,
> Debarshi
> 
> [1]
> https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers
> [2] https://admin.fedoraproject.org/pkgdb/users/packages/splinux
> 
Pablo



From ivazqueznet at gmail.com  Sat Nov  8 22:52:13 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Sat, 08 Nov 2008 17:52:13 -0500
Subject: Flash 10 in 64-bit F9: does it work?
In-Reply-To: <200811082216.mA8MGeSh004187@jasmine.xos.nl>
References: <200811082216.mA8MGeSh004187@jasmine.xos.nl>
Message-ID: <1226184733.4625.139.camel@ignacio.lan>

On Sat, 2008-11-08 at 23:16 +0100, Jos Vos wrote:
> Did anyone manage to get flash 10 working on 64-bit F9?  Note that
> I didn't try on 32-bit yet, so I can't comment on that (yet).

Works fine here, on both i386 and x86_64 (using nspluginwrapper in both
cases; I'm not THAT crazy :P ).

-- 
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/20081108/81af11ad/attachment.sig>

From rjones at redhat.com  Sat Nov  8 23:00:55 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 8 Nov 2008 23:00:55 +0000
Subject: CVS access for first-time packager?
In-Reply-To: <20081108210805.GB903002@hiwaay.net>
References: <20081108160646.GA903002@hiwaay.net>
	<20081108210805.GB903002@hiwaay.net>
Message-ID: <20081108230055.GA17699@amd.home.annexia.org>

On Sat, Nov 08, 2008 at 03:08:05PM -0600, Chris Adams wrote:
> Once upon a time, Chris Adams <cmadams at hiwaay.net> said:
> > I submitted a package, got it reviewed, got sponsored, and submitted the
> > CVS request.  I got mail back that CVS was done, but I can't seem to log
> > in:
> 
> Well, somebody did something, because it is working now.  Thanks!

There's a delay between CVS access being granted and some cron job
running which allows you to actually do stuff.  If this happens again
just wait an hour or so for the cron job to run and everything will
work.

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 orcanbahri at yahoo.com  Sat Nov  8 23:07:03 2008
From: orcanbahri at yahoo.com (Orcan Ogetbil)
Date: Sat, 8 Nov 2008 15:07:03 -0800 (PST)
Subject: Flash 10 in 64-bit F9: does it work?
In-Reply-To: <20081108223308.GC903002@hiwaay.net>
Message-ID: <84298.7018.qm@web32804.mail.mud.yahoo.com>

--- On Sat, 11/8/08, Chris Adams  wrote:
> 
> It is working for me on F9/x86_64.  I didn't do
> anything special; I have
> the Adobe repo in my yum config and got
> flash-plugin-10.0.12.36-release
> with a yum update.
> -- 

I also got the same version of flash-plugin from the Adobe repo. It works but there is this infamous "grey rectangle bug" on 64 bit systems that drives me insane. I read very many discussions about this but there is no known solution (to me).

Basically when I go to a website that makes use of flash, sometimes the flash content is replaced with a grey box. Left- or right-clicking on the grey box doesn't do anything. The page needs to be reloaded (some times a large number of times) until it shows properly. Sometimes it turns to grey in the middle of a flash video that I'm watching (this is the most annoying case since some flash players don't have time-seeking feature, I have to watch everything over). The bug happens more often when I have multiple tabs/windows open that display websites with flash content.

The issue is reported on different linux systems (Ubuntu, Fedora...). Some say that it broke during a minor update in the 9.0.x series. I can't verify this because I couldn't find copies of old versions of flash plugins. 10.0.x series didn't fix the problem. 

Typically when the grey rectangle bug happens I get messages in the system log, such as

npviewer.bin[18365]: segfault at 13 ip 1493db7 sp ff9b3964 error 4 in libflashplayer.so[def000+951000]
npviewer.bin[13560]: segfault at 13 ip 1493db7 sp ffbb3364 error 4 in libflashplayer.so[def000+951000]
npviewer.bin[810]: segfault at 13 ip 1493db7 sp ffaaea64 error 4 in libflashplayer.so[def000+951000]
npviewer.bin[15403]: segfault at 13 ip 1493db7 sp ffdd0d84 error 4 in libflashplayer.so[def000+951000]
npviewer.bin[4703]: segfault at ff9d1e4c ip ff9d1e4c sp fffd45dc error 14

npviewer.bin segfaults are there in every single case. If someone knows of a solution or workaround, I'm all ears.

-Orcan


      



From rdieter at math.unl.edu  Sat Nov  8 23:35:29 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Sat, 08 Nov 2008 17:35:29 -0600
Subject: Flash 10 in 64-bit F9: does it work?
References: <200811082216.mA8MGeSh004187@jasmine.xos.nl>
Message-ID: <gf57nr$si$1@ger.gmane.org>

Jos Vos wrote:

> Did anyone manage to get flash 10 working on 64-bit F9?

works here, in firefox + nspluginwrapper.

-- Rex



From kanarip at kanarip.com  Sun Nov  9 00:43:58 2008
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Sun, 09 Nov 2008 01:43:58 +0100
Subject: Rubygems >= 1.3.0 for Merb
In-Reply-To: <7d74b2790811081319l6710bd96v3542dbcde59b5f42@mail.gmail.com>
References: <7d74b2790811081252m56b86b5al6c2153ee7eed79ad@mail.gmail.com>	<200811081300.10256.konrad@tylerc.org>
	<7d74b2790811081319l6710bd96v3542dbcde59b5f42@mail.gmail.com>
Message-ID: <4916324E.4000101@kanarip.com>

Jesse Hutton wrote:
> Thanks, I filed a bug:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=470688
> 

I've attached a new patch, a new spec and a new srpm for you to test.

Besides, I've requested official co-maintainership on the package.

Kind regards,

Jeroen van Meeuwen
-kanarip



From mike at cchtml.com  Sun Nov  9 02:22:57 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Sat, 08 Nov 2008 20:22:57 -0600
Subject: Flash 10 in 64-bit F9: does it work?
In-Reply-To: <84298.7018.qm@web32804.mail.mud.yahoo.com>
References: <84298.7018.qm@web32804.mail.mud.yahoo.com>
Message-ID: <49164981.3060408@cchtml.com>

Orcan Ogetbil wrote:
> npviewer.bin segfaults are there in every single case. If someone knows of a solution or workaround, I'm all ears.
>
> -Orcan
>   

There is no solution. The nspluginwrapper[1] program is crashing. It 
happens often. It's "normal" in a sense. If you wish to make it more 
stable, I'm sure the nspluginwrapper people are accepting patches.

Please know that the binary Adobe Flash plug-in is 32-bit only. There is 
no 64-bit plugin. In order to use the Flash plugin in Firefox 64-bit, 
the nspluginwrapper plugin is used.

[1] http://gwenole.beauchesne.info//en/projects/nspluginwrapper



From bashton at brennanashton.com  Sun Nov  9 02:24:34 2008
From: bashton at brennanashton.com (Brennan Ashton)
Date: Sat, 8 Nov 2008 18:24:34 -0800
Subject: Flash 10 in 64-bit F9: does it work?
In-Reply-To: <84298.7018.qm@web32804.mail.mud.yahoo.com>
References: <20081108223308.GC903002@hiwaay.net>
	<84298.7018.qm@web32804.mail.mud.yahoo.com>
Message-ID: <981da310811081824l1e0b6df6pc341e2e387254d05@mail.gmail.com>

On Sat, Nov 8, 2008 at 3:07 PM, Orcan Ogetbil <orcanbahri at yahoo.com> wrote:
> --- On Sat, 11/8/08, Chris Adams  wrote:
>>
>> It is working for me on F9/x86_64.  I didn't do
>> anything special; I have
>> the Adobe repo in my yum config and got
>> flash-plugin-10.0.12.36-release
>> with a yum update.
>> --
>
> I also got the same version of flash-plugin from the Adobe repo. It works but there is this infamous "grey rectangle bug" on 64 bit systems that drives me insane. I read very many discussions about this but there is no known solution (to me).
>
> Basically when I go to a website that makes use of flash, sometimes the flash content is replaced with a grey box. Left- or right-clicking on the grey box doesn't do anything. The page needs to be reloaded (some times a large number of times) until it shows properly. Sometimes it turns to grey in the middle of a flash video that I'm watching (this is the most annoying case since some flash players don't have time-seeking feature, I have to watch everything over). The bug happens more often when I have multiple tabs/windows open that display websites with flash content.
>
> The issue is reported on different linux systems (Ubuntu, Fedora...). Some say that it broke during a minor update in the 9.0.x series. I can't verify this because I couldn't find copies of old versions of flash plugins. 10.0.x series didn't fix the problem.
>
> Typically when the grey rectangle bug happens I get messages in the system log, such as
>
> npviewer.bin[18365]: segfault at 13 ip 1493db7 sp ff9b3964 error 4 in libflashplayer.so[def000+951000]
> npviewer.bin[13560]: segfault at 13 ip 1493db7 sp ffbb3364 error 4 in libflashplayer.so[def000+951000]
> npviewer.bin[810]: segfault at 13 ip 1493db7 sp ffaaea64 error 4 in libflashplayer.so[def000+951000]
> npviewer.bin[15403]: segfault at 13 ip 1493db7 sp ffdd0d84 error 4 in libflashplayer.so[def000+951000]
> npviewer.bin[4703]: segfault at ff9d1e4c ip ff9d1e4c sp fffd45dc error 14
>
> npviewer.bin segfaults are there in every single case. If someone knows of a solution or workaround, I'm all ears.
>
> -Orcan

This all rolls back to this "bug" in pulseaudio
http://www.pulseaudio.org/ticket/267  note that I put bug in quotes
because pulseaudio says it is a flash issue.  You can find a lot more
information about it in these bug reports, some have a lot of good
information. The Ubuntu one has some well though out ideas about how
to resolve this problem.  The pulseaudio bug was submitted 8 months
ago, something needs to be done.

http://www.pulseaudio.org/ticket/267
http://www.pulseaudio.org/ticket/225
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/192888



From nicolas.mailhot at laposte.net  Sun Nov  9 11:09:10 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 09 Nov 2008 12:09:10 +0100
Subject: Fedora 11 font package changes proposal (renames, splits, etc)
Message-ID: <1226228950.21652.95.camel@arekh.okg>

Hi,

If you've received this message directly (not via a list) you're
concerned by the font package changes proposed for Fedora 11:
? the changes touch one of your packages or
? the changes touch/need one component you're lead on (comps, packagedb,
rpm?)

Please reply to the fedora fonts list however to keep the discussion in
a single place.

The complete list of proposed changes is published there
http://fedoraproject.org/wiki/Fonts_SIG_Fedora_11_packaging_changes

All is open to discussion, and it's on a wiki page, so don't hesitate to
complete/correct it.

This list is pretty ambitious and requires buy-in by many people to be
executed properly. Not to mention that the Fedora 11 cycle will start
soon. Please do respond to the list, stating:
? your requests and comments (if any)
? if you will change your packages along those lines for Fedora 11
? if you will allow other packagers to change your packages in your
stead
? if you totally object to one part of the proposal, and why

Unless there is strong opposition I will apply those changes to my own
packages (and to vera and liberation if their maintainers are ok with
it). However, to be effective, other packagers must change their
packages too.


??? Short proposal summary:

? package renames, to fix the naming discrepancies that have crept in
with the repository growth 
(different packagers followed different conventions)

? package splits, to offer more flexibility to spin groups and fedora
users

? new comps groups, to group related fonts together
(gfs fonts, sil fonts, etc)

? reminder of the ongoing fontconfig guidelines change
(still waiting for fontconfig upstream to comment on)

? new packaging template and macros
(to put in rpm? some other place?)


??? Rationale:

? help spins and users

Wanting serif from dejavu, mono from liberation, and sans from tiresias,
without dragging in all the other dejavu/liberation/tiresias fonts is a
valid setup.

? help packagers and package reviewers

Inconsistent repository and fuzzy rules mean package reviews drag on
while the kinks are ironed out, which is not fun at all for everyone
involved. Much better to have clear conventions packagers can identify
before hitting review stage.


??? Proof of concept:

Dejavu has been used to proof the concepts in rawhide (cf the wiki page)


I hope those proposals will be agreeable to everyone.

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/20081109/6f1e76c2/attachment.sig>

From jos at xos.nl  Sun Nov  9 11:14:48 2008
From: jos at xos.nl (Jos Vos)
Date: Sun, 9 Nov 2008 12:14:48 +0100
Subject: Flash 10 in 64-bit F9: does it work?
In-Reply-To: <1226184733.4625.139.camel@ignacio.lan>
References: <200811082216.mA8MGeSh004187@jasmine.xos.nl>
	<1226184733.4625.139.camel@ignacio.lan>
Message-ID: <20081109111448.GA14366@jasmine.xos.nl>

On Sat, Nov 08, 2008 at 05:52:13PM -0500, Ignacio Vazquez-Abrams wrote:

> Works fine here, on both i386 and x86_64 (using nspluginwrapper in both
> cases; I'm not THAT crazy :P ).

OK, I found the problem: it seems like flash 10 needs libcurl.i386.
I found this hint in some Ubuntu forum, IIRC.  Maybe it has to be
documented too on the Fedora Wiki.

With that, it works now, but some sites still have problems, as pointed
out in earlier reactions.

-- 
--    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 rakesh.pandit at gmail.com  Sun Nov  9 11:24:22 2008
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Sun, 9 Nov 2008 16:54:22 +0530
Subject: help required regarding Bugzilla
Message-ID: <b401d2530811090324t217ffa50v2b81938a8e827ad3@mail.gmail.com>

I was writing a script for generating weekly report from bugzilla
using python-bugzilla. Everything seems to work for old bugs but for
new bugs I get "Bug <no> does not exist. Most probably the there has
been an upgrade in bugzilla and I am not using correct url to connect.
Suggestions or help ?

Here is an example python session. 469811 is latest bug and 445027 is
an old bug.

>>> from bugzilla import Bugzilla
>>> bZilla = Bugzilla(url='https://partner-bugzilla.redhat.com/xmlrpc.cgi', username='<bugzilla_username>', password='<bugzilla_password>')
>>> history_bug1 = bugzilla._proxy.Bug.get_history({'ids':[469811]})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'bugzilla' is not defined
>>> history_bug1 = bZilla._proxy.Bug.get_history({'ids':[469811]})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/xmlrpclib.py", line 1150, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib/python2.5/xmlrpclib.py", line 1440, in __request
    verbose=self.__verbose
  File "/usr/lib/python2.5/site-packages/bugzilla.py", line 713, in request
    return self._parse_response(h.getfile(), sock)
  File "/usr/lib/python2.5/xmlrpclib.py", line 1343, in _parse_response
    return u.close()
  File "/usr/lib/python2.5/xmlrpclib.py", line 790, in close
    raise Fault(**self._stack[0])
xmlrpclib.Fault: <Fault 101: 'Bug #469811 does not exist.'>
>>>
>>>
>>> history_bug1 = bZilla._proxy.Bug.get_history({'ids':[445027]})
>>>

Thanks,

-- 
rakesh



From rawhide at fedoraproject.org  Sun Nov  9 11:50:04 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sun,  9 Nov 2008 11:50:04 +0000 (UTC)
Subject: rawhide report: 20081109 changes
Message-ID: <20081109115004.DCB7E1B8001@releng2.fedora.phx.redhat.com>

Compose started at Sun Nov  9 06:01:09 UTC 2008

Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 0









Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot





From rakesh.pandit at gmail.com  Sun Nov  9 12:45:50 2008
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Sun, 9 Nov 2008 18:15:50 +0530
Subject: help required regarding Bugzilla
In-Reply-To: <b401d2530811090324t217ffa50v2b81938a8e827ad3@mail.gmail.com>
References: <b401d2530811090324t217ffa50v2b81938a8e827ad3@mail.gmail.com>
Message-ID: <b401d2530811090445n745a3e8bjb191016586772783@mail.gmail.com>

My bad, I was using wrong url. It works okay now.
--
rakesh



From alsadi at gmail.com  Sun Nov  9 14:42:14 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Sun, 9 Nov 2008 16:42:14 +0200
Subject: Fedora 11 font package changes proposal (renames, splits, etc)
In-Reply-To: <1226228950.21652.95.camel@arekh.okg>
References: <1226228950.21652.95.camel@arekh.okg>
Message-ID: <385866f0811090642s7c437dd7m936c2825bf633e36@mail.gmail.com>

regarding arabeyes-kacst-fonts
kacst fonts are not from arabeyes they are only hosted there
the fonts are by www.kacst.edu.sa/default.aspx

rpm -qi kacst-fonts-2.0-1.fc10.noarch
...
from the King Abdulaziz City for Science & Technology(kacst).

arabeyes produce two types of fonts: core and decorative and I packed
them for ojuba, here is the .spec file (attached)

I would love to maintain it for the fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arabeyes-fonts.spec
Type: application/octet-stream
Size: 3820 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081109/9f19d986/attachment.obj>

From nicolas.mailhot at laposte.net  Sun Nov  9 15:25:37 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 09 Nov 2008 16:25:37 +0100
Subject: Fedora 11 font package changes proposal (renames, splits, etc)
In-Reply-To: <385866f0811090642s7c437dd7m936c2825bf633e36@mail.gmail.com>
References: <1226228950.21652.95.camel@arekh.okg>
	<385866f0811090642s7c437dd7m936c2825bf633e36@mail.gmail.com>
Message-ID: <1226244337.24809.19.camel@arekh.okg>

Le dimanche 09 novembre 2008 ? 16:42 +0200, Muayyad AlSadi a ?crit :
> regarding arabeyes-kacst-fonts
> kacst fonts are not from arabeyes they are only hosted there
> the fonts are by www.kacst.edu.sa/default.aspx
> 
> rpm -qi kacst-fonts-2.0-1.fc10.noarch
> ...
> from the King Abdulaziz City for Science & Technology(kacst).

I suppose that if kacst lets arabeyes distribute them they are not
unfriendly with each other. Open Font Library likewise only
re-distributes other people work, I guess the prefix in this case would
mainly be there to denote some sort of oflb or arabeyes editorial work

Anyway, duly noted, if more people feel karcst should not be prefixed I
guess we'll make it and exception (but I'd love to have a clear simple
common sense naming rule).

> arabeyes produce two types of fonts: core and decorative and I packed
> them for ojuba, here is the .spec file (attached)

Some (but not all) of those fonts are currently in review:

https://bugzilla.redhat.com/show_bug.cgi?id=461139
https://bugzilla.redhat.com/show_bug.cgi?id=462711

You can either work with the current would-be packager (and become
co-maintainer) or submit a competing proposal (some reviews never go
anywhere, unfortunately, don't wait for others to do the stuff you care
about).

The path to get a font in Fedora is documented there:
http://fedoraproject.org/wiki/Font_package_lifecycle

We mostly ask packagers to adhere as closely as possible to the official
spec template, create a wiki page that can be referenced in release
notes, and avoid bundling different fonts in a single package.

http://fedoraproject.org/wiki/Annotated_fonts_spec_template

When there is little deviation from guidelines reviews tend to be quick
(unfortunately the reverse is also true)

> I would love to maintain it for the fedora

New font packagers are always welcome! Your spec is not acceptable
as-is, but if you're motivated I think you'll find creating
guidelines-conformant spec files is not too hard.

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/20081109/c46ad0c1/attachment.sig>

From mclasen at redhat.com  Sun Nov  9 16:04:00 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Sun, 09 Nov 2008 11:04:00 -0500
Subject: Fedora 11 font package changes proposal (renames, splits, etc)
In-Reply-To: <1226228950.21652.95.camel@arekh.okg>
References: <1226228950.21652.95.camel@arekh.okg>
Message-ID: <1226246640.7388.4.camel@localhost.localdomain>

On Sun, 2008-11-09 at 12:09 +0100, Nicolas Mailhot wrote:


> ? package splits, to offer more flexibility to spin groups and fedora
> users

Can I voice some doubt about the usefulness of this ? Going to your wiki
page, I read that dejavu has been split into ~10 subpackages. If this
happens to all font packages, it will blow up metadata and package lists
and make it harder for users to install a reasonable set of fonts. There
are real costs associated with overly fine-grained package splits. Have
you really weighted to pros and cons of this idea ? The use case you
cite

  Wanting serif from dejavu, mono from liberation, and sans from     
  tiresias, without dragging in all the other dejavu/liberation/tiresias
  fonts is a valid setup.

Doesn't really strike me as worth supporting...


Matthias



From alsadi at gmail.com  Sun Nov  9 16:11:08 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Sun, 9 Nov 2008 18:11:08 +0200
Subject: Fedora 11 font package changes proposal (renames, splits, etc)
In-Reply-To: <1226246640.7388.4.camel@localhost.localdomain>
References: <1226228950.21652.95.camel@arekh.okg>
	<1226246640.7388.4.camel@localhost.localdomain>
Message-ID: <385866f0811090811m5996b1c7ob9e973d5266cdef6@mail.gmail.com>

I added some comments on
https://bugzilla.redhat.com/show_bug.cgi?id=461139

please check them



From nicolas.mailhot at laposte.net  Sun Nov  9 16:53:55 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 09 Nov 2008 17:53:55 +0100
Subject: Fedora 11 font package changes proposal (renames, splits, etc)
In-Reply-To: <1226246640.7388.4.camel@localhost.localdomain>
References: <1226228950.21652.95.camel@arekh.okg>
	<1226246640.7388.4.camel@localhost.localdomain>
Message-ID: <1226249635.25621.34.camel@arekh.okg>

Le dimanche 09 novembre 2008 ? 11:04 -0500, Matthias Clasen a ?crit :
> On Sun, 2008-11-09 at 12:09 +0100, Nicolas Mailhot wrote:
> 
> 
> > ? package splits, to offer more flexibility to spin groups and fedora
> > users
> 
> Can I voice some doubt about the usefulness of this ?

Sure, the whole discussion is open.

> Going to your wiki
> page, I read that dejavu has been split into ~10 subpackages.

Actually, it has been split from 3 packages (2 full + 1 lgc) to 6 font
packages (3 full + 3 lgc) + 1 common package and 2 compat packages which
are only used for upgrades (and will be killed in F12). 

The font packages still weight more than your average package. And I'd
be happy to get rid of the lgc packages, except that's pitchfork land,
so if I had to maintain them they should follow the same rules as
dejavu-full.

> If this
> happens to all font packages, it will blow up metadata and package lists
> and make it harder for users to install a reasonable set of fonts.

I don't think so, packages with a clear content are more user-friendly
than packages that mix good and bad stuff. And the item users recognize
is the font family name they get in font lists. I've seen all too many
times users ask what package provides a particular font, because it was
hidden in a big bundle.

One package per font family means we can get packagekit font
auto-install to work (the main problem when it was last discussed was
how to handle fonts with different capabilities in a single package)
instead of having @font-face install proprietary blobs on use systems.

Also it means that when we add support to a new script spins only need
to add *one* small package to their default package list instead of big
packages that weight 10s of megs.

(for example there is enough size pressure on defaults we're seriously
considering to pass on korean bold because the space is already taken by
other packages)

As written in the wiki page we've tried to let maintainers find the
"best" split and it ended up a mess, one package per font family is a
clear rule which is easy to understand by everyone, and will even result
in subpackage consolidation in a few cases.

> There
> are real costs associated with overly fine-grained package splits. Have
> you really weighted to pros and cons of this idea ? The use case you
> cite
> 
>   Wanting serif from dejavu, mono from liberation, and sans from     
>   tiresias, without dragging in all the other dejavu/liberation/tiresias
>   fonts is a valid setup.
> 
> Doesn't really strike me as worth supporting...

Another use-case is indic fonts. If we had a big monolithic lohit
package malayam users would complain. Because it is split we can have
one set of defaults taken from lohit, and another from smc, without
requiring full install of both of them.

And which font is default at any time is a policy decision, having to
rework package split each time one font gets better than another is not
a good use of resources.

Lastly, multi-font packages have all too often turned into a licensing
mess, because fonts are usually not created together and bundling fonts
often means bundling licenses. tetex is a sorry example of what happens
when you start creating font collections. And once you've decided you
want to split collections the only simple splitting rule everyone
understands without running circles in package reviews is splitting
along font family lines.

(I'm sorry if I need to insist on clear rules for new packagers. I've
just had too many painful font reviews lately)

-- 
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/20081109/abb0aee7/attachment.sig>

From hughsient at gmail.com  Sun Nov  9 18:04:29 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 09 Nov 2008 18:04:29 +0000
Subject: Fedora 11 font package changes proposal (renames, splits, etc)
In-Reply-To: <1226249635.25621.34.camel@arekh.okg>
References: <1226228950.21652.95.camel@arekh.okg>
	<1226246640.7388.4.camel@localhost.localdomain>
	<1226249635.25621.34.camel@arekh.okg>
Message-ID: <1226253869.9475.29.camel@hughsie-laptop>

On Sun, 2008-11-09 at 17:53 +0100, Nicolas Mailhot wrote:
> One package per font family means we can get packagekit font
> auto-install to work (the main problem when it was last discussed was
> how to handle fonts with different capabilities in a single package)
> instead of having @font-face install proprietary blobs on use systems.

Behdad, what's the status of the auto font install thing? I've got the
DBUS interface wired up and some initial UI code in place:
http://www.packagekit.org/img/gpk-client-font.png

Anything you're waiting for me for? Anything I can be testing?

Richard.




From kevin.kofler at chello.at  Sun Nov  9 18:18:04 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 09 Nov 2008 19:18:04 +0100
Subject: Fedora 11 font package changes proposal (renames, splits, etc)
References: <1226228950.21652.95.camel@arekh.okg>
Message-ID: <gf79gs$uai$1@ger.gmane.org>

Nicolas Mailhot wrote:
> The complete list of proposed changes is published there
> http://fedoraproject.org/wiki/Fonts_SIG_Fedora_11_packaging_changes

> ghostscript-fonts
> Needs to be split but at the same time finding OTF replacements would
> probably be better

Please don't forget that GhostScript's URW fonts are metrically compatible
with the standard PostScript fonts and even look similar to them. Please
don't drop them without an equivalent (i.e. also metrically and visually
compatible with the standard PostScript fonts) replacement!

        Kevin Kofler



From nicoleau.fabien at gmail.com  Sun Nov  9 19:05:16 2008
From: nicoleau.fabien at gmail.com (Nicoleau Fabien)
Date: Sun, 09 Nov 2008 20:05:16 +0100
Subject: Build a noarch package with files in %{_libdir}
Message-ID: <4917346C.2050502@gmail.com>

Hi,
I have a problem to build a package 
(http://sd-2469.dedibox.fr/photobatch/download/index.html). This is a 
python program, so it's a noarch package.
But some files are installed in : %{_libdir}/nautilus/extensions-2.0/python/

So it can no really be a noarch package. Then if I remove "noarch", 
rpmlint complains because there are no binary file in the package.

What is the best option ?

Regard


Nicoleau Fabien



From cmadams at hiwaay.net  Sun Nov  9 19:49:45 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Sun, 9 Nov 2008 13:49:45 -0600
Subject: Flash 10 in 64-bit F9: does it work?
In-Reply-To: <20081109111448.GA14366@jasmine.xos.nl>
References: <200811082216.mA8MGeSh004187@jasmine.xos.nl>
	<1226184733.4625.139.camel@ignacio.lan>
	<20081109111448.GA14366@jasmine.xos.nl>
Message-ID: <20081109194945.GA793444@hiwaay.net>

Once upon a time, Jos Vos <jos at xos.nl> said:
> OK, I found the problem: it seems like flash 10 needs libcurl.i386.
> I found this hint in some Ubuntu forum, IIRC.  Maybe it has to be
> documented too on the Fedora Wiki.

Would it make sense for libflashsupport to "Require: libcurl.so.4" then?
It is a hack, but libflashsupport in general is a hack, so it would seem
to be the best place for this (since the flash-plugin RPM itself is not
requiring the needed dependencies).

-- 
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 Nov  9 19:57:04 2008
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Sun, 9 Nov 2008 21:57:04 +0200
Subject: Build a noarch package with files in %{_libdir}
In-Reply-To: <4917346C.2050502@gmail.com>
References: <4917346C.2050502@gmail.com>
Message-ID: <200811092157.05530.ville.skytta@iki.fi>

On Sunday 09 November 2008, Nicoleau Fabien wrote:
> Hi,
> I have a problem to build a package
> (http://sd-2469.dedibox.fr/photobatch/download/index.html). This is a
> python program, so it's a noarch package.
> But some files are installed in :
> %{_libdir}/nautilus/extensions-2.0/python/
>
> So it can no really be a noarch package. Then if I remove "noarch",
> rpmlint complains because there are no binary file in the package.
>
> What is the best option ?

Remove noarch and ignore rpmlint if there's no arch independent dir, 
eg. %{_datadir}/nautilus/..., where to install the files instead 
of %{_libdir}/nautilus/... available.

If you remove noarch, remember also to disable the likely resulting 
empty/useless debuginfo package with "%define debug_package %{nil}".



From mike at cchtml.com  Sun Nov  9 20:02:03 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Sun, 09 Nov 2008 14:02:03 -0600
Subject: Flash 10 in 64-bit F9: does it work?
In-Reply-To: <20081109194945.GA793444@hiwaay.net>
References: <200811082216.mA8MGeSh004187@jasmine.xos.nl>	<1226184733.4625.139.camel@ignacio.lan>	<20081109111448.GA14366@jasmine.xos.nl>
	<20081109194945.GA793444@hiwaay.net>
Message-ID: <491741BB.6070106@cchtml.com>

Chris Adams wrote:
>
> Would it make sense for libflashsupport to "Require: libcurl.so.4" then?
> It is a hack, but libflashsupport in general is a hack, so it would seem
> to be the best place for this (since the flash-plugin RPM itself is not
> requiring the needed dependencies).
>
>   
Flash 10 no longer needs libflashsupport. In fact, the Flash 10 RPM 
already has a Require: libcurl.so.4. You couldn't install it without it. 
Fedora updated the libcurl RPM to have a libcurl.so.4. This was 
discussed back in the Fedora 10 beta when it was first changed.

If you somehow didn't have curl already installed... I question how you 
installed Flash in the first place. It definitely wasn't by RPM or else 
you added a --nodeps to your install arguments.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081109/dcbb7c2a/attachment.htm>

From jos at xos.nl  Sun Nov  9 20:08:00 2008
From: jos at xos.nl (Jos Vos)
Date: Sun, 9 Nov 2008 21:08:00 +0100
Subject: Flash 10 in 64-bit F9: does it work?
In-Reply-To: <20081109194945.GA793444@hiwaay.net>
References: <200811082216.mA8MGeSh004187@jasmine.xos.nl>
	<1226184733.4625.139.camel@ignacio.lan>
	<20081109111448.GA14366@jasmine.xos.nl>
	<20081109194945.GA793444@hiwaay.net>
Message-ID: <20081109200800.GA21703@jasmine.xos.nl>

On Sun, Nov 09, 2008 at 01:49:45PM -0600, Chris Adams wrote:

> Would it make sense for libflashsupport to "Require: libcurl.so.4" then?
> It is a hack, but libflashsupport in general is a hack, so it would seem
> to be the best place for this (since the flash-plugin RPM itself is not
> requiring the needed dependencies).

In that case you may want to add libz.so.1 too, as I also needed to
install zlib.i386 IIRC.  But in that case you still have to know
that you have to install libflashsupport.i386 ;-).

I am used to built my own flash RPM for internal use, so I already
added this to my spec file.

-- 
--    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 cmadams at hiwaay.net  Sun Nov  9 20:12:14 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Sun, 9 Nov 2008 14:12:14 -0600
Subject: Flash 10 in 64-bit F9: does it work?
In-Reply-To: <491741BB.6070106@cchtml.com>
References: <200811082216.mA8MGeSh004187@jasmine.xos.nl>
	<1226184733.4625.139.camel@ignacio.lan>
	<20081109111448.GA14366@jasmine.xos.nl>
	<20081109194945.GA793444@hiwaay.net> <491741BB.6070106@cchtml.com>
Message-ID: <20081109201214.GB793444@hiwaay.net>

Once upon a time, Michael Cronenworth <mike at cchtml.com> said:
> Flash 10 no longer needs libflashsupport. In fact, the Flash 10 RPM 
> already has a Require: libcurl.so.4. You couldn't install it without it. 
> Fedora updated the libcurl RPM to have a libcurl.so.4. This was 
> discussed back in the Fedora 10 beta when it was first changed.
> 
> If you somehow didn't have curl already installed... I question how you 
> installed Flash in the first place. It definitely wasn't by RPM or else 
> you added a --nodeps to your install arguments.

The flash-plugin RPM I have has essentially no useful Requires:

kosh:2:~$ rpm -q flash-plugin
flash-plugin-10.0.12.36-release.i386
kosh:3:~$ rpm -q --requires flash-plugin
/bin/bash  
/bin/sh  
/bin/sh  
/bin/sh  
/bin/sh  
glibc >= 2.4
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1

There is certainly no libcurl (or any other library) requirement; I
assume Adobe has (wrongly) disabled automatic requirement generation.
Here's what the actual plugin is linked against:

kosh:14:~$ ldd /usr/lib/flash-plugin/libflashplayer.so 
        linux-gate.so.1 =>  (0x00110000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00be3000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00b80000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x00cd3000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0x00b99000)
        libXt.so.6 => /usr/lib/libXt.so.6 (0x00dd4000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00e2e000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00ebd000)
        libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00eec000)
        libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x016c0000)
        libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x07f8c000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x012f6000)
        libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00ba9000)
        libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x01313000)
        libcairo.so.2 => /usr/lib/libcairo.so.2 (0x01477000)
        libgobject-2.0.so.0 => /lib/libgobject-2.0.so.0 (0x01356000)
        libgmodule-2.0.so.0 => /lib/libgmodule-2.0.so.0 (0x00bb3000)
        libdl.so.2 => /lib/libdl.so.2 (0x00bb7000)
        libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x01b34000)
        libnss3.so => /lib/libnss3.so (0x0202f000)
        libsmime3.so => /lib/libsmime3.so (0x07ede000)
        libssl3.so => /lib/libssl3.so (0x01396000)
        libplds4.so => /lib/libplds4.so (0x00bbc000)
        libplc4.so => /lib/libplc4.so (0x00bbf000)
        libnspr4.so => /lib/libnspr4.so (0x013c7000)
        libm.so.6 => /lib/libm.so.6 (0x01401000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x07bec000)
        libc.so.6 => /lib/libc.so.6 (0x034a4000)
        /lib/ld-linux.so.2 (0x00bc5000)
        libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0x07a90000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0x07d82000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x07aad000)
        libSM.so.6 => /usr/lib/libSM.so.6 (0x06ad8000)
        libICE.so.6 => /usr/lib/libICE.so.6 (0x06b7a000)
        libexpat.so.1 => /lib/libexpat.so.1 (0x06bef000)
        libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0x06aab000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x06abd000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x0142a000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0x06ae1000)
        libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x01452000)
        libXi.so.6 => /usr/lib/libXi.so.6 (0x01455000)
        libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x06acf000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x07885000)
        libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x07b65000)
        libz.so.1 => /lib/libz.so.1 (0x0796b000)
        libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0x07baa000)
        libnssutil3.so => /lib/libnssutil3.so (0x079de000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x07829000)
        libuuid.so.1 => /lib/libuuid.so.1 (0x077fb000)

No libcurl in there, so I guess they must be dlopening it or something
like that.

-- 
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 jos at xos.nl  Sun Nov  9 20:13:53 2008
From: jos at xos.nl (Jos Vos)
Date: Sun, 9 Nov 2008 21:13:53 +0100
Subject: Flash 10 in 64-bit F9: does it work?
In-Reply-To: <491741BB.6070106@cchtml.com>
References: <200811082216.mA8MGeSh004187@jasmine.xos.nl>
	<1226184733.4625.139.camel@ignacio.lan>
	<20081109111448.GA14366@jasmine.xos.nl>
	<20081109194945.GA793444@hiwaay.net> <491741BB.6070106@cchtml.com>
Message-ID: <20081109201353.GB21703@jasmine.xos.nl>

On Sun, Nov 09, 2008 at 02:02:03PM -0600, Michael Cronenworth wrote:

> Flash 10 no longer needs libflashsupport. In fact, the Flash 10 RPM 
> already has a Require: libcurl.so.4. You couldn't install it without it. 

The Adobe RPM does not require libcurl.so.4:

$ rpm -qp --requires flash-plugin-10.0.12.36-release.i386.rpm
/bin/bash  
/bin/sh  
/bin/sh  
/bin/sh  
/bin/sh  
glibc >= 2.4
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1

But I'll try it without libflashsupport...

> If you somehow didn't have curl already installed... I question how you 
> installed Flash in the first place. It definitely wasn't by RPM or else 
> you added a --nodeps to your install arguments.

I did not use the Adobe RPM, but I am using my own RPM.  Given the above,
I don't see how installing the Adobe RPM would pull in libcurl.i386.

-- 
--    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 nicolas.mailhot at laposte.net  Sun Nov  9 20:43:29 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 09 Nov 2008 21:43:29 +0100
Subject: Fedora 11 font package changes proposal (renames, splits, etc)
In-Reply-To: <gf79gs$uai$1@ger.gmane.org>
References: <1226228950.21652.95.camel@arekh.okg> <gf79gs$uai$1@ger.gmane.org>
Message-ID: <1226263409.26223.3.camel@arekh.okg>

Le dimanche 09 novembre 2008 ? 19:18 +0100, Kevin Kofler a ?crit :
> Nicolas Mailhot wrote:
> > The complete list of proposed changes is published there
> > http://fedoraproject.org/wiki/Fonts_SIG_Fedora_11_packaging_changes
> 
> > ghostscript-fonts
> > Needs to be split but at the same time finding OTF replacements would
> > probably be better
> 
> Please don't forget that GhostScript's URW fonts are metrically compatible
> with the standard PostScript fonts and even look similar to them. Please
> don't drop them without an equivalent (i.e. also metrically and visually
> compatible with the standard PostScript fonts) replacement!

Reworks of the Ghostscript fonts exist (ie TEX Gyre, but there are
probably others). They should have kept the original style and metrics
(maybe fixed hinting and kerning). 

The only reason they've not been merged yet is a legal mess.

-- 
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/20081109/e38a3c59/attachment.sig>

From Matt_Domsch at dell.com  Sun Nov  9 20:49:46 2008
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Sun, 9 Nov 2008 14:49:46 -0600
Subject: Automatic BuildRequires
In-Reply-To: <20081106192302.c2285926.mschwendt@gmail.com>
References: <20081106110142.GA3165@amd.home.annexia.org>
	<20081106192302.c2285926.mschwendt@gmail.com>
Message-ID: <20081109204946.GA12715@auslistsprd01.us.dell.com>

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.

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From Matt_Domsch at dell.com  Sun Nov  9 21:01:46 2008
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Sun, 9 Nov 2008 15:01:46 -0600
Subject: Automatic BuildRequires
In-Reply-To: <20081109204946.GA12715@auslistsprd01.us.dell.com>
References: <20081106110142.GA3165@amd.home.annexia.org>
	<20081106192302.c2285926.mschwendt@gmail.com>
	<20081109204946.GA12715@auslistsprd01.us.dell.com>
Message-ID: <20081109210146.GA16833@auslistsprd01.us.dell.com>

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

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From alsadi at gmail.com  Sun Nov  9 21:11:47 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Sun, 9 Nov 2008 23:11:47 +0200
Subject: sound skipping in F10
Message-ID: <385866f0811091311q31e1a367u9de08b054a9e0989@mail.gmail.com>

I consider this bug very very critical
https://bugzilla.redhat.com/show_bug.cgi?id=469591

for the following reasons
1. we have't this bug in F9
2. we claim a Glitchless audio experience
http://fedoraproject.org/wiki/Features/GlitchFreeAudio
  ie. to the end user "when you did not claim this thing it was smooth
and when you claim it, you lost it!"
3. I don't listen to Music, maybe when it skips a tune it will be
missed by ear considering the noisy music of those times but I listen
to lectures and speaks, it will be very annoying when it skips a "no"
or "not" in the middle of a sentence

I'm not underestimating the good effort behind pulse

but please make that bug assigned and let's inspect it more

PS. My sound card is ESS (snd_es1938)



From dennis at ausil.us  Sun Nov  9 21:49:42 2008
From: dennis at ausil.us (Dennis Gilmore)
Date: Sun, 9 Nov 2008 15:49:42 -0600
Subject: Automatic BuildRequires
In-Reply-To: <20081106111649.GB3165@amd.home.annexia.org>
References: <20081106110142.GA3165@amd.home.annexia.org>
	<1225970138.4625.15.camel@ignacio.lan>
	<20081106111649.GB3165@amd.home.annexia.org>
Message-ID: <200811091553.03271.dennis@ausil.us>

On Thursday 06 November 2008 05:16:50 am Richard W.M. Jones wrote:
> On Thu, Nov 06, 2008 at 06:15:38AM -0500, Ignacio Vazquez-Abrams wrote:
> > On Thu, 2008-11-06 at 11:01 +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/
> > >
> > > This tries to find the correct set of BuildRequires automatically when
> > > running 'rpmbuild'.  Just replace the ordinary rpmbuild command with
> > > auto-br-rpmbuild, and it will print out a suggested set of
> > > BuildRequires lines at the end.  For example:
> >
> > I take it that it needs to be run in a system/root that already has the
> > appropriate packages installed?
>
> Yes, you just run it on a normal system.  The main idea is so you
> don't have to keep submitting Koji jobs because you missed out some
> BuildRequires.
Thats what mock on your local system is for.  Please don't abuse koji by doing 
that.  if you have it right on one arch using scratch builds in koji to test 
all arches is appropriate. but not to work out missing BuildRequires.  Again 
please be thoughtful with the resources fedora provides  they are not infinite.

Dennis



From schaiba at gmail.com  Sun Nov  9 22:33:18 2008
From: schaiba at gmail.com (Aioanei Rares)
Date: Mon, 10 Nov 2008 00:33:18 +0200
Subject: sound skipping in F10
In-Reply-To: <385866f0811091311q31e1a367u9de08b054a9e0989@mail.gmail.com>
References: <385866f0811091311q31e1a367u9de08b054a9e0989@mail.gmail.com>
Message-ID: <4917652E.3020004@gmail.com>

Muayyad AlSadi wrote:
> I consider this bug very very critical
> https://bugzilla.redhat.com/show_bug.cgi?id=469591
>
> for the following reasons
> 1. we have't this bug in F9
> 2. we claim a Glitchless audio experience
> http://fedoraproject.org/wiki/Features/GlitchFreeAudio
>   ie. to the end user "when you did not claim this thing it was smooth
> and when you claim it, you lost it!"
> 3. I don't listen to Music, maybe when it skips a tune it will be
> missed by ear considering the noisy music of those times but I listen
> to lectures and speaks, it will be very annoying when it skips a "no"
> or "not" in the middle of a sentence
>
> I'm not underestimating the good effort behind pulse
>
> but please make that bug assigned and let's inspect it more
>
> PS. My sound card is ESS (snd_es1938)
>
>   
Yes, I get this too with Intel ICH and Amarok or Juk and rawhide...plus 
I couldn't get youtube to work with sound with a player running 
(paused), despite libflashsupport.{i386,x86_64} installed. So i 
uninstalled pulseaudio for now and it's all ok.



From rjones at redhat.com  Sun Nov  9 23:04:57 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sun, 9 Nov 2008 23:04:57 +0000
Subject: Automatic BuildRequires
In-Reply-To: <200811091553.03271.dennis@ausil.us>
References: <20081106110142.GA3165@amd.home.annexia.org>
	<1225970138.4625.15.camel@ignacio.lan>
	<20081106111649.GB3165@amd.home.annexia.org>
	<200811091553.03271.dennis@ausil.us>
Message-ID: <20081109230457.GA10902@amd.home.annexia.org>

On Sun, Nov 09, 2008 at 03:49:42PM -0600, Dennis Gilmore wrote:
> On Thursday 06 November 2008 05:16:50 am Richard W.M. Jones wrote:
> > On Thu, Nov 06, 2008 at 06:15:38AM -0500, Ignacio Vazquez-Abrams wrote:
> > > On Thu, 2008-11-06 at 11:01 +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/
> > > >
> > > > This tries to find the correct set of BuildRequires automatically when
> > > > running 'rpmbuild'.  Just replace the ordinary rpmbuild command with
> > > > auto-br-rpmbuild, and it will print out a suggested set of
> > > > BuildRequires lines at the end.  For example:
> > >
> > > I take it that it needs to be run in a system/root that already has the
> > > appropriate packages installed?
> >
> > Yes, you just run it on a normal system.  The main idea is so you
> > don't have to keep submitting Koji jobs because you missed out some
> > BuildRequires.
> Thats what mock on your local system is for.

Or the same for mock ...

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 david at hlacik.eu  Sun Nov  9 23:10:59 2008
From: david at hlacik.eu (=?ISO-8859-2?Q?David_Hl=E1=E8ik?=)
Date: Mon, 10 Nov 2008 00:10:59 +0100
Subject: sound skipping in F10
In-Reply-To: <4917652E.3020004@gmail.com>
References: <385866f0811091311q31e1a367u9de08b054a9e0989@mail.gmail.com>
	<4917652E.3020004@gmail.com>
Message-ID: <cba415ca0811091510i55c8215mbcfee1a170fc9d@mail.gmail.com>

Same problem here - Intel HD Audio - Asus F3Sr

D.

On Sun, Nov 9, 2008 at 23:33, Aioanei Rares <schaiba at gmail.com> wrote:
> Muayyad AlSadi wrote:
>>
>> I consider this bug very very critical
>> https://bugzilla.redhat.com/show_bug.cgi?id=469591
>>
>> for the following reasons
>> 1. we have't this bug in F9
>> 2. we claim a Glitchless audio experience
>> http://fedoraproject.org/wiki/Features/GlitchFreeAudio
>>  ie. to the end user "when you did not claim this thing it was smooth
>> and when you claim it, you lost it!"
>> 3. I don't listen to Music, maybe when it skips a tune it will be
>> missed by ear considering the noisy music of those times but I listen
>> to lectures and speaks, it will be very annoying when it skips a "no"
>> or "not" in the middle of a sentence
>>
>> I'm not underestimating the good effort behind pulse
>>
>> but please make that bug assigned and let's inspect it more
>>
>> PS. My sound card is ESS (snd_es1938)
>>
>>
>
> Yes, I get this too with Intel ICH and Amarok or Juk and rawhide...plus I
> couldn't get youtube to work with sound with a player running (paused),
> despite libflashsupport.{i386,x86_64} installed. So i uninstalled pulseaudio
> for now and it's all ok.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From dragos.tatulea at gmail.com  Sun Nov  9 23:11:19 2008
From: dragos.tatulea at gmail.com (Dragos Tatulea)
Date: Mon, 10 Nov 2008 01:11:19 +0200
Subject: Fwd: bridging for system-config-network
In-Reply-To: <6d1764b50811091458r4daae1bfqb491f0e5a6911113@mail.gmail.com>
References: <6d1764b50811091458r4daae1bfqb491f0e5a6911113@mail.gmail.com>
Message-ID: <6d1764b50811091511q49924110mab017f25e2b24308@mail.gmail.com>

Hi,

   It seems that there is little support for bridging in
system-config-network and maybe even NetworkManager. I'd like to help adding
them. I don't know if this is the right place to ask but are there any
ongoing plans for this? Do you find it useful? Maybe it has beed done before
and I missed it.

   I use bridging a lot for virtualisation and every time I want to start
using virtual machines some script invocation is needed. It would be nicer
to have it integrated and make NetworkManager cope nicely with this
situation. What do you think?

--Dragos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081110/5aa943de/attachment.htm>

From stlwrt at gmail.com  Mon Nov 10 00:22:05 2008
From: stlwrt at gmail.com (Pavel Shevchuk)
Date: Mon, 10 Nov 2008 02:22:05 +0200
Subject: sound skipping in F10
In-Reply-To: <385866f0811091311q31e1a367u9de08b054a9e0989@mail.gmail.com>
References: <385866f0811091311q31e1a367u9de08b054a9e0989@mail.gmail.com>
Message-ID: <d25f375f0811091622p2d6c4d53u9ff6e5b6a9282de1@mail.gmail.com>

Same stuff for me on my SB Live! and x86_64 rawhide. I guess it's not
hardware related

On Sun, Nov 9, 2008 at 11:11 PM, Muayyad AlSadi <alsadi at gmail.com> wrote:
> I consider this bug very very critical
> https://bugzilla.redhat.com/show_bug.cgi?id=469591
>
> for the following reasons
> 1. we have't this bug in F9
> 2. we claim a Glitchless audio experience
> http://fedoraproject.org/wiki/Features/GlitchFreeAudio
>  ie. to the end user "when you did not claim this thing it was smooth
> and when you claim it, you lost it!"
> 3. I don't listen to Music, maybe when it skips a tune it will be
> missed by ear considering the noisy music of those times but I listen
> to lectures and speaks, it will be very annoying when it skips a "no"
> or "not" in the middle of a sentence
>
> I'm not underestimating the good effort behind pulse
>
> but please make that bug assigned and let's inspect it more
>
> PS. My sound card is ESS (snd_es1938)
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
http://scwlab.com



From tnorth at fedoraproject.org  Mon Nov 10 00:24:06 2008
From: tnorth at fedoraproject.org (Thibault North)
Date: Sun, 9 Nov 2008 19:24:06 -0500
Subject: Segfault with alliance on liveDVD
Message-ID: <200811091924.06581.tnorth@fedoraproject.org>

Hi,

We have as part of FEL a package (alliance), which works well on Rawhide, but 
crashes (segfault) on our liveDVD. (built from rawhide also.)

There must be a required file or something like that missing, but for now we 
don't know which one.

We are looking for pointers on how to resolve that kind of issue. Have been 
explored for now: valgrind[1] and strace[2][3] on rawhide and that liveDVD.

Valgrind complains about a "source and destination overlap" happening in 
libXm.so.2.0.1 before the crash. 

Strace shows some differences before the load (or crash) of the program, but 
I?ve not been able to spot something interesting enough in it.

Any idea on how to fix that ?

Cheers,
Thibault

[1] http://tnorth.ch/fel/graal.valgrind
[2] Working on Rawhide http://tnorth.ch/fel/graal.ok.strace
[3] Segfault-ing on liveDVD http://tnorth.ch/fel/graal.strace

Tested version: last build of alliance (.22) on i386.
graal, the executable used here is part of the alliance package.

List of installed packages on Rawhide (where graal works):
http://chitlesh.fedorapeople.org/FEL/nirik
List of the install packages on the livedvd (where graal segfaults)
http://tnorth.ch/fel/livedvd



From kevin.kofler at chello.at  Mon Nov 10 00:38:06 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 10 Nov 2008 01:38:06 +0100
Subject: Segfault with alliance on liveDVD
References: <200811091924.06581.tnorth@fedoraproject.org>
Message-ID: <gf7vpe$gio$1@ger.gmane.org>

Thibault North wrote:
> Valgrind complains about a "source and destination overlap" happening in
> libXm.so.2.0.1 before the crash.

That means the offending call to memcpy should be changed into a memmove
(just change "memcpy" to "memmove"), chances are that'll be enough to fix
your crash.

        Kevin Kofler



From mike at cchtml.com  Mon Nov 10 01:07:16 2008
From: mike at cchtml.com (mike at cchtml.com)
Date: Sun,  9 Nov 2008 19:07:16 -0600 (CST)
Subject: Flash 10 in 64-bit F9: does it work?
In-Reply-To: <20081109201353.GB21703@jasmine.xos.nl>
Message-ID: <YECkBvyS.1226279236.8149890.mike@cchtml.com>


On 11/9/2008, "Jos Vos" <jos at xos.nl> wrote:

>The Adobe RPM does not require libcurl.so.4:
>

It did when the first Flash 10 beta that required it came out. I guess
they removed this Requires on the final RPM. That's unfortunate.

No, I'm not making it up. I don't have a beta RPM anymore so I can't
pull out screenshots, but I remember it explicitly not allowing me to
install Flash 10 beta when I had no /usr/lib/libcurl.so.4 file. I had to
make a symlink to the .so.3 file and add --no-deps to the RPM install
command.



From abartlet at samba.org  Mon Nov 10 01:43:00 2008
From: abartlet at samba.org (Andrew Bartlett)
Date: Mon, 10 Nov 2008 12:43:00 +1100
Subject: End of bind-chroot-admin script
In-Reply-To: <20081107120905.GA3188@evileye.atkac.englab.brq.redhat.com>
References: <20081107120905.GA3188@evileye.atkac.englab.brq.redhat.com>
Message-ID: <1226281380.4613.30.camel@naomi.s4.naomi.abartlet.net>

On Fri, 2008-11-07 at 13:09 +0100, Adam Tkac wrote:
> Hi all,
> 
> bind-chroot-admin script should sync BIND configuration files to
> chroot() directory. It was written with good intention but it has
> never worked correctly in all situations. There is long history with
> many broken configurations and urgent severity bugs.
> 
> I'm going to remove this script from Fedora 11 (it is part of Fedora/RHEL
> only, no other distro uses it). After removal, "standard" chroot
> structure will be created when you install bind-chroot package. It
> will contain all needed files for running named in chroot but admin
> shall move needed configuration files to chroot manually. Do you have
> any comments?

So, after this, the master configuration files will no longer live
in /etc but in /var/named/chroot/etc?  Will the /etc/ files be removed?
What will prevent the frustrated admin from editing the wrong file?

As part of my efforts on Samba4, I've been trying to make it easier for
administrators to include the pre-generated zone file, and the rules for
GSS-TSIG updates (required by windows clients).  I hope this will not
make it harder to have fairly generic instructions (insert this snippit
into /etc/named.conf) for my users. 

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/20081110/a3b9be55/attachment.sig>

From sundaram at fedoraproject.org  Mon Nov 10 03:06:40 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 10 Nov 2008 08:36:40 +0530
Subject: sound skipping in F10
In-Reply-To: <4917652E.3020004@gmail.com>
References: <385866f0811091311q31e1a367u9de08b054a9e0989@mail.gmail.com>
	<4917652E.3020004@gmail.com>
Message-ID: <4917A540.7050108@fedoraproject.org>

Aioanei Rares wrote:

>>   
> Yes, I get this too with Intel ICH and Amarok or Juk and rawhide...plus 
> I couldn't get youtube to work with sound with a player running 
> (paused), despite libflashsupport.{i386,x86_64} installed. So i 
> uninstalled pulseaudio for now and it's all ok.

If you are using Flash 10, you should *not* install libflashsupport.

Rahul



From jonathan at jonmasters.org  Mon Nov 10 05:02:23 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Mon, 10 Nov 2008 00:02:23 -0500
Subject: db-compat
Message-ID: <1226293343.30170.4.camel@jcmlaptop>

Hi,

It would seem we're no longer shipping libdb-4.1.so, whereas we do have
4.2, 4.3, and 4.5 in that db4 compatibility package. I wound up just
stealing the binary from an older RPM and copying it in place.

Anyway, software like Xilinx's ISE/EDK would like it back :)

Jon.




From paul at city-fan.org  Mon Nov 10 07:11:46 2008
From: paul at city-fan.org (Paul Howarth)
Date: Mon, 10 Nov 2008 07:11:46 +0000
Subject: Flash 10 in 64-bit F9: does it work?
In-Reply-To: <YECkBvyS.1226279236.8149890.mike@cchtml.com>
References: <20081109201353.GB21703@jasmine.xos.nl>
	<YECkBvyS.1226279236.8149890.mike@cchtml.com>
Message-ID: <20081110071146.573a3456@metropolis.intra.city-fan.org>

On Sun,  9 Nov 2008 19:07:16 -0600 (CST)
<mike at cchtml.com> wrote:

> 
> On 11/9/2008, "Jos Vos" <jos at xos.nl> wrote:
> 
> >The Adobe RPM does not require libcurl.so.4:
> >
> 
> It did when the first Flash 10 beta that required it came out. I guess
> they removed this Requires on the final RPM. That's unfortunate.
> 
> No, I'm not making it up. I don't have a beta RPM anymore so I can't
> pull out screenshots, but I remember it explicitly not allowing me to
> install Flash 10 beta when I had no /usr/lib/libcurl.so.4 file. I had
> to make a symlink to the .so.3 file and add --no-deps to the RPM
> install command.

I'm pretty sure it was the other way around. Fedora ships libcurl.so.4,
not libcurl.so.3, and Flash 10 required the latter. I believe it will
now use either, and dlopen()s whichever one it finds.

Paul.



From mike at cchtml.com  Mon Nov 10 07:29:35 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Mon, 10 Nov 2008 01:29:35 -0600
Subject: Flash 10 in 64-bit F9: does it work?
In-Reply-To: <20081110071146.573a3456@metropolis.intra.city-fan.org>
References: <20081109201353.GB21703@jasmine.xos.nl>	<YECkBvyS.1226279236.8149890.mike@cchtml.com>
	<20081110071146.573a3456@metropolis.intra.city-fan.org>
Message-ID: <4917E2DF.9060507@cchtml.com>

Paul Howarth wrote:
>
> I'm pretty sure it was the other way around. Fedora ships libcurl.so.4,
> not libcurl.so.3, and Flash 10 required the latter. I believe it will
> now use either, and dlopen()s whichever one it finds.
>
> Paul.
>
>   

Yeah.... Do a massive s/4/3/ on all of my e-mails. *annoyed grunt*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081110/759f7c49/attachment.htm>

From jos at xos.nl  Mon Nov 10 07:43:38 2008
From: jos at xos.nl (Jos Vos)
Date: Mon, 10 Nov 2008 08:43:38 +0100
Subject: Flash 10 in 64-bit F9: does it work?
In-Reply-To: <20081110071146.573a3456@metropolis.intra.city-fan.org>
References: <20081109201353.GB21703@jasmine.xos.nl>
	<YECkBvyS.1226279236.8149890.mike@cchtml.com>
	<20081110071146.573a3456@metropolis.intra.city-fan.org>
Message-ID: <20081110074338.GA30995@jasmine.xos.nl>

On Mon, Nov 10, 2008 at 07:11:46AM +0000, Paul Howarth wrote:

> I'm pretty sure it was the other way around. Fedora ships libcurl.so.4,
> not libcurl.so.3, and Flash 10 required the latter. I believe it will
> now use either, and dlopen()s whichever one it finds.

IIRC I read in the forum (Ubuntu?) where I found the libcurl suggestion
that those users had a problem because their distro had libcurl.so.3 and
that flash 10 needed libcurl.so.4.  But I'll soon know because I'll try
to get flash 10 working on RHEL5, having libcurl.so.3...

-- 
--    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 ivazqueznet at gmail.com  Mon Nov 10 07:34:35 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Mon, 10 Nov 2008 02:34:35 -0500
Subject: Flash 10 in 64-bit F9: does it work?
In-Reply-To: <YECkBvyS.1226279236.8149890.mike@cchtml.com>
References: <YECkBvyS.1226279236.8149890.mike@cchtml.com>
Message-ID: <1226302476.16027.14.camel@ignacio.lan>

On Sun, 2008-11-09 at 19:07 -0600, mike at cchtml.com wrote:
> On 11/9/2008, "Jos Vos" <jos at xos.nl> wrote:
> 
> >The Adobe RPM does not require libcurl.so.4:
> >
> 
> It did when the first Flash 10 beta that required it came out. I guess
> they removed this Requires on the final RPM. That's unfortunate.

s/beta/rc/

And actually, it needed libcurl.so.3, while Fedora provided .so.4.

http://blogs.adobe.com/penguin.swf/2008/08/10rc1.html#comment-1588172

-- 
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/20081110/41a6b801/attachment.sig>

From schaiba at gmail.com  Mon Nov 10 08:53:41 2008
From: schaiba at gmail.com (Aioanei Rares)
Date: Mon, 10 Nov 2008 10:53:41 +0200
Subject: sound skipping in F10
In-Reply-To: <4917A540.7050108@fedoraproject.org>
References: <385866f0811091311q31e1a367u9de08b054a9e0989@mail.gmail.com>	<4917652E.3020004@gmail.com>
	<4917A540.7050108@fedoraproject.org>
Message-ID: <4917F695.2040005@gmail.com>

Rahul Sundaram wrote:
> Aioanei Rares wrote:
>
>>>   
>> Yes, I get this too with Intel ICH and Amarok or Juk and 
>> rawhide...plus I couldn't get youtube to work with sound with a 
>> player running (paused), despite libflashsupport.{i386,x86_64} 
>> installed. So i uninstalled pulseaudio for now and it's all ok.
>
> If you are using Flash 10, you should *not* install libflashsupport.
>
> Rahul
>
It's all the same with or without libflashsupport. My two cents go to 
the kernel being responsible
for the sound skipping part.



From giallu at gmail.com  Mon Nov 10 09:10:26 2008
From: giallu at gmail.com (Gianluca Sforna)
Date: Mon, 10 Nov 2008 10:10:26 +0100
Subject: Flash 10 in 64-bit F9: does it work?
In-Reply-To: <20081109111448.GA14366@jasmine.xos.nl>
References: <200811082216.mA8MGeSh004187@jasmine.xos.nl>
	<1226184733.4625.139.camel@ignacio.lan>
	<20081109111448.GA14366@jasmine.xos.nl>
Message-ID: <d5ad21470811100110v22cd7404t9c312c594de8f929@mail.gmail.com>

On Sun, Nov 9, 2008 at 12:14 PM, Jos Vos <jos at xos.nl> wrote:
> OK, I found the problem: it seems like flash 10 needs libcurl.i386.
> I found this hint in some Ubuntu forum, IIRC.  Maybe it has to be
> documented too on the Fedora Wiki.

The most relevant info I've found are at:
http://macromedia.mplug.org/


-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna



From giallu at gmail.com  Mon Nov 10 09:10:26 2008
From: giallu at gmail.com (Gianluca Sforna)
Date: Mon, 10 Nov 2008 10:10:26 +0100
Subject: Flash 10 in 64-bit F9: does it work?
In-Reply-To: <20081109111448.GA14366@jasmine.xos.nl>
References: <200811082216.mA8MGeSh004187@jasmine.xos.nl>
	<1226184733.4625.139.camel@ignacio.lan>
	<20081109111448.GA14366@jasmine.xos.nl>
Message-ID: <d5ad21470811100110v22cd7404t9c312c594de8f929@mail.gmail.com>

On Sun, Nov 9, 2008 at 12:14 PM, Jos Vos <jos at xos.nl> wrote:
> OK, I found the problem: it seems like flash 10 needs libcurl.i386.
> I found this hint in some Ubuntu forum, IIRC.  Maybe it has to be
> documented too on the Fedora Wiki.

The most relevant info I've found are at:
http://macromedia.mplug.org/


-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna



From markmc at redhat.com  Mon Nov 10 09:40:07 2008
From: markmc at redhat.com (Mark McLoughlin)
Date: Mon, 10 Nov 2008 09:40:07 +0000
Subject: Fwd: bridging for system-config-network
In-Reply-To: <6d1764b50811091511q49924110mab017f25e2b24308@mail.gmail.com>
References: <6d1764b50811091458r4daae1bfqb491f0e5a6911113@mail.gmail.com>
	<6d1764b50811091511q49924110mab017f25e2b24308@mail.gmail.com>
Message-ID: <1226310007.4068.14.camel@blaa>

On Mon, 2008-11-10 at 01:11 +0200, Dragos Tatulea wrote:
> Hi,
> 
>    It seems that there is little support for bridging in
> system-config-network and maybe even NetworkManager. I'd like to help
> adding them. I don't know if this is the right place to ask but are
> there any ongoing plans for this? Do you find it useful? Maybe it has
> beed done before and I missed it.
> 
>    I use bridging a lot for virtualisation and every time I want to
> start using virtual machines some script invocation is needed. It
> would be nicer to have it integrated and make NetworkManager cope
> nicely with this situation. What do you think?

See upstream bugzilla:

  http://bugzilla.gnome.org/show_bug.cgi?id=543232

Cheers,
Mark.



From chitlesh.goorah at gmail.com  Mon Nov 10 09:56:03 2008
From: chitlesh.goorah at gmail.com (Chitlesh GOORAH)
Date: Mon, 10 Nov 2008 10:56:03 +0100
Subject: Segfault with alliance on liveDVD
In-Reply-To: <200811091924.06581.tnorth@fedoraproject.org>
References: <200811091924.06581.tnorth@fedoraproject.org>
Message-ID: <50baabb30811100156pe30841cw1acaada5b0f784df@mail.gmail.com>

On Mon, Nov 10, 2008 at 1:24 AM, Thibault North
<tnorth at fedoraproject.org> wrote:
> Hi,
>
> We have as part of FEL a package (alliance), which works well on Rawhide, but
> crashes (segfault) on our liveDVD. (built from rawhide also.)
>
> There must be a required file or something like that missing, but for now we
> don't know which one.
>
> We are looking for pointers on how to resolve that kind of issue. Have been
> explored for now: valgrind[1] and strace[2][3] on rawhide and that liveDVD.
>
> Valgrind complains about a "source and destination overlap" happening in
> libXm.so.2.0.1 before the crash.
>
> Strace shows some differences before the load (or crash) of the program, but
> I've not been able to spot something interesting enough in it.
>
> Any idea on how to fix that ?
>


I guess we are missing a specific Requires, which one ?
If package X requires Y and package Y requires Z, I believe that we
are missing package Z.

The same n-v-r works on an installed rawhide and not on a livedvd. Has
anyone removed a Requires from a libX??? or mesa-??? for some reason ?

Have anyone encountered other package aside alliance which is
suffering with such symptoms ?

Chitlesh



From chitlesh.goorah at gmail.com  Mon Nov 10 10:03:44 2008
From: chitlesh.goorah at gmail.com (Chitlesh GOORAH)
Date: Mon, 10 Nov 2008 11:03:44 +0100
Subject: db-compat
In-Reply-To: <1226293343.30170.4.camel@jcmlaptop>
References: <1226293343.30170.4.camel@jcmlaptop>
Message-ID: <50baabb30811100203p6e7e2e23y17a5fa048574d283@mail.gmail.com>

On Mon, Nov 10, 2008 at 6:02 AM, Jon Masters <jonathan at jonmasters.org> wrote:
> Hi,
>
> It would seem we're no longer shipping libdb-4.1.so, whereas we do have
> 4.2, 4.3, and 4.5 in that db4 compatibility package. I wound up just
> stealing the binary from an older RPM and copying it in place.
>
> Anyway, software like Xilinx's ISE/EDK would like it back :)
>
> Jon.

Jindrich Novy, can you package it for us, please ?
Xilinx ISE/EDK is also an important tool for me :)

Chitlesh



From dwmw2 at infradead.org  Mon Nov 10 10:35:08 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 10 Nov 2008 11:35:08 +0100
Subject: Fwd: bridging for system-config-network
In-Reply-To: <6d1764b50811091511q49924110mab017f25e2b24308@mail.gmail.com>
References: <6d1764b50811091458r4daae1bfqb491f0e5a6911113@mail.gmail.com>
	<6d1764b50811091511q49924110mab017f25e2b24308@mail.gmail.com>
Message-ID: <1226313308.4367.40.camel@macbook.infradead.org>

On Mon, 2008-11-10 at 01:11 +0200, Dragos Tatulea wrote:
>    It seems that there is little support for bridging in
> system-config-network and maybe even NetworkManager. I'd like to help adding
> them. I don't know if this is the right place to ask but are there any
> ongoing plans for this? Do you find it useful? Maybe it has beed done before
> and I missed it.

The networking scripts already handle bridging; it's easy enough to set
it up by creating ifcfg-brX files. It would be good to teach
system-config-network about it too, I agree.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From chitlesh.goorah at gmail.com  Mon Nov 10 10:43:39 2008
From: chitlesh.goorah at gmail.com (Chitlesh GOORAH)
Date: Mon, 10 Nov 2008 11:43:39 +0100
Subject: Segfault with alliance on liveDVD
In-Reply-To: <50baabb30811100156pe30841cw1acaada5b0f784df@mail.gmail.com>
References: <200811091924.06581.tnorth@fedoraproject.org>
	<50baabb30811100156pe30841cw1acaada5b0f784df@mail.gmail.com>
Message-ID: <50baabb30811100243i260437cdja5de55c310c38ace@mail.gmail.com>

On Mon, Nov 10, 2008 at 10:56 AM, Chitlesh GOORAH wrote:
> I guess we are missing a specific Requires, which one ?
> If package X requires Y and package Y requires Z, I believe that we
> are missing package Z.
>
> The same n-v-r works on an installed rawhide and not on a livedvd. Has
> anyone removed a Requires from a libX??? or mesa-??? for some reason ?
>
> Have anyone encountered other package aside alliance which is
> suffering with such symptoms ?
>
> Chitlesh
>

I guess I found it : xorg-x11-fonts-misc-7.2-6.fc9.noarch
Without xorg-x11-fonts-misc, graal crashes. I'll spin to verify it.

Chitlesh



From atkac at redhat.com  Mon Nov 10 12:26:58 2008
From: atkac at redhat.com (Adam Tkac)
Date: Mon, 10 Nov 2008 13:26:58 +0100
Subject: End of bind-chroot-admin script
In-Reply-To: <alpine.LFD.1.10.0811071845170.20989@newtla.xelerance.com>
References: <20081107120905.GA3188@evileye.atkac.englab.brq.redhat.com>
	<1226079930.3997.12.camel@macbook.infradead.org>
	<alpine.LFD.1.10.0811071845170.20989@newtla.xelerance.com>
Message-ID: <20081110122658.GA4224@evileye.atkac.englab.brq.redhat.com>

On Fri, Nov 07, 2008 at 06:52:10PM -0500, Paul Wouters wrote:
> On Fri, 7 Nov 2008, David Woodhouse wrote:
>
>> On Fri, 2008-11-07 at 13:09 +0100, Adam Tkac wrote:
>>> bind-chroot-admin script should sync BIND configuration files to
>>> chroot() directory. It was written with good intention but it has
>>> never worked correctly in all situations. There is long history with
>>> many broken configurations and urgent severity bugs.
>>>
>>> I'm going to remove this script from Fedora 11 (it is part of Fedora/RHEL
>>> only, no other distro uses it). After removal, "standard" chroot
>>> structure will be created when you install bind-chroot package. It
>>> will contain all needed files for running named in chroot but admin
>>> shall move needed configuration files to chroot manually. Do you have
>>> any comments?
>
> I'd rather see something replace it. For unbound, another caching resolver
> with chroot (which got pushed in the repository a few days ago), the
> same problem is solved by copying/linking/mounting files in the
> chroot via the init script.
>
> Updating the chroot becomes important for shipping DNSSEC keys via a package.
> I am putting in a review request today for a new package 'dnssec-keys'
> that allows people to easily enable/disable DNSSEC and preload the proper
> keys for active TLD's. Things should get easier once the root is signed.
>
> I was about to look at bind, since the DNSSEC key format for unbound and
> bind is the same, so I am using one include file that will work on both
> nameservers, once they copy it into their chroot environment.
>
> Have a look at the unbound method, and see if that is something that could
> also work for named?
>
> Paul

I looked into unbound init script (if I understand correctly it
deals with chroot symlinks). Unbound uses only small amount of
configuration files so it is quite easy to create chroot.

If you look into bind-chroot-admin it tries deal with all possible
situations and it sometimes doesn't work and when something fails
it generally breaks configuration which is, of course, pretty bad.

BIND has good SELinux policy so for "mainstream" configurations chroot
is simply not needed.

Chroot is used by traditional admins whose create it manually or when
you need really secure environment (chroot+SELinux). Both cases
doesn't need bind-chroot-admin because in the first case user doesn't use
it and in the second case configuration is maintained in some kind of
VSC (CVS, SVN etc...) and bind-chroot-admin makes only problems.

Adam

-- 
Adam Tkac, Red Hat, Inc.



From atkac at redhat.com  Mon Nov 10 12:34:23 2008
From: atkac at redhat.com (Adam Tkac)
Date: Mon, 10 Nov 2008 13:34:23 +0100
Subject: End of bind-chroot-admin script
In-Reply-To: <faa16b610811081136g7544549fw6543240a1c135be@mail.gmail.com>
References: <20081107120905.GA3188@evileye.atkac.englab.brq.redhat.com>
	<1226079930.3997.12.camel@macbook.infradead.org>
	<alpine.LFD.1.10.0811071845170.20989@newtla.xelerance.com>
	<faa16b610811081136g7544549fw6543240a1c135be@mail.gmail.com>
Message-ID: <20081110123423.GB4224@evileye.atkac.englab.brq.redhat.com>

On Sat, Nov 08, 2008 at 02:36:38PM -0500, Colin Walters wrote:
> On Fri, Nov 7, 2008 at 6:52 PM, Paul Wouters <paul at xelerance.com> wrote:
> >
> > I'd rather see something replace it.
> 
> SELinux obsoletes this use of chroot for security.  Every daemon
> doesn't need to grow its own private copy of the OS infrastructure.
> 

Chroot is good and traditional method how restrict daemons. Many users
still use it and it is far more easy create chroot configuration than
create/maintain SELinux policy. I don't think SELinux obsoletes
chroot, both try restrict daemon privileges and both have + and -.

Adam

-- 
Adam Tkac, Red Hat, Inc.



From atkac at redhat.com  Mon Nov 10 12:36:52 2008
From: atkac at redhat.com (Adam Tkac)
Date: Mon, 10 Nov 2008 13:36:52 +0100
Subject: End of bind-chroot-admin script
In-Reply-To: <1226281380.4613.30.camel@naomi.s4.naomi.abartlet.net>
References: <20081107120905.GA3188@evileye.atkac.englab.brq.redhat.com>
	<1226281380.4613.30.camel@naomi.s4.naomi.abartlet.net>
Message-ID: <20081110123652.GC4224@evileye.atkac.englab.brq.redhat.com>

On Mon, Nov 10, 2008 at 12:43:00PM +1100, Andrew Bartlett wrote:
> On Fri, 2008-11-07 at 13:09 +0100, Adam Tkac wrote:
> > Hi all,
> > 
> > bind-chroot-admin script should sync BIND configuration files to
> > chroot() directory. It was written with good intention but it has
> > never worked correctly in all situations. There is long history with
> > many broken configurations and urgent severity bugs.
> > 
> > I'm going to remove this script from Fedora 11 (it is part of Fedora/RHEL
> > only, no other distro uses it). After removal, "standard" chroot
> > structure will be created when you install bind-chroot package. It
> > will contain all needed files for running named in chroot but admin
> > shall move needed configuration files to chroot manually. Do you have
> > any comments?
> 
> So, after this, the master configuration files will no longer live
> in /etc but in /var/named/chroot/etc?  Will the /etc/ files be removed?
> What will prevent the frustrated admin from editing the wrong file?

Master configuration will be in /etc and /var/named by default like
now. Only one difference is when you want to use chroot you have to move
configuration files to chroot manually.

> 
> As part of my efforts on Samba4, I've been trying to make it easier for
> administrators to include the pre-generated zone file, and the rules for
> GSS-TSIG updates (required by windows clients).  I hope this will not
> make it harder to have fairly generic instructions (insert this snippit
> into /etc/named.conf) for my users. 
> 
> Andrew Bartlett

Adam

-- 
Adam Tkac, Red Hat, Inc.



From yersinia.spiros at gmail.com  Mon Nov 10 11:57:58 2008
From: yersinia.spiros at gmail.com (yersinia)
Date: Mon, 10 Nov 2008 12:57:58 +0100
Subject: End of bind-chroot-admin script
In-Reply-To: <20081110122658.GA4224@evileye.atkac.englab.brq.redhat.com>
References: <20081107120905.GA3188@evileye.atkac.englab.brq.redhat.com>
	<1226079930.3997.12.camel@macbook.infradead.org>
	<alpine.LFD.1.10.0811071845170.20989@newtla.xelerance.com>
	<20081110122658.GA4224@evileye.atkac.englab.brq.redhat.com>
Message-ID: <b086760e0811100357j5ec031b6m77033507ea49adf6@mail.gmail.com>

But many people disable Selinux, so it is always better to have a secure
alternatives - Selinux is better IMHO and it is possible
to do "chroot" better with selinux (
http://www.coker.com.au/selinux/talks/sage-2006/PolyInstantiatedDirectories.html
)


On Mon, Nov 10, 2008 at 1:26 PM, Adam Tkac <atkac at redhat.com> wrote:

> On Fri, Nov 07, 2008 at 06:52:10PM -0500, Paul Wouters wrote:
> > On Fri, 7 Nov 2008, David Woodhouse wrote:
> >
> >> On Fri, 2008-11-07 at 13:09 +0100, Adam Tkac wrote:
> >>> bind-chroot-admin script should sync BIND configuration files to
> >>> chroot() directory. It was written with good intention but it has
> >>> never worked correctly in all situations. There is long history with
> >>> many broken configurations and urgent severity bugs.
> >>>
> >>> I'm going to remove this script from Fedora 11 (it is part of
> Fedora/RHEL
> >>> only, no other distro uses it). After removal, "standard" chroot
> >>> structure will be created when you install bind-chroot package. It
> >>> will contain all needed files for running named in chroot but admin
> >>> shall move needed configuration files to chroot manually. Do you have
> >>> any comments?
> >
> > I'd rather see something replace it. For unbound, another caching
> resolver
> > with chroot (which got pushed in the repository a few days ago), the
> > same problem is solved by copying/linking/mounting files in the
> > chroot via the init script.
> >
> > Updating the chroot becomes important for shipping DNSSEC keys via a
> package.
> > I am putting in a review request today for a new package 'dnssec-keys'
> > that allows people to easily enable/disable DNSSEC and preload the proper
> > keys for active TLD's. Things should get easier once the root is signed.
> >
> > I was about to look at bind, since the DNSSEC key format for unbound and
> > bind is the same, so I am using one include file that will work on both
> > nameservers, once they copy it into their chroot environment.
> >
> > Have a look at the unbound method, and see if that is something that
> could
> > also work for named?
> >
> > Paul
>
> I looked into unbound init script (if I understand correctly it
> deals with chroot symlinks). Unbound uses only small amount of
> configuration files so it is quite easy to create chroot.
>
> If you look into bind-chroot-admin it tries deal with all possible
> situations and it sometimes doesn't work and when something fails
> it generally breaks configuration which is, of course, pretty bad.
>
> BIND has good SELinux policy so for "mainstream" configurations chroot
> is simply not needed.
>
> Chroot is used by traditional admins whose create it manually or when
> you need really secure environment (chroot+SELinux). Both cases
> doesn't need bind-chroot-admin because in the first case user doesn't use
> it and in the second case configuration is maintained in some kind of
> VSC (CVS, SVN etc...) and bind-chroot-admin makes only problems.
>
> Adam
>
> --
> Adam Tkac, Red Hat, Inc.
>
> --
> 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/20081110/4daa9b83/attachment.htm>

From alan at redhat.com  Mon Nov 10 11:58:38 2008
From: alan at redhat.com (Alan Cox)
Date: Mon, 10 Nov 2008 06:58:38 -0500
Subject: End of bind-chroot-admin script
In-Reply-To: <20081110123423.GB4224@evileye.atkac.englab.brq.redhat.com>
References: <20081107120905.GA3188@evileye.atkac.englab.brq.redhat.com>
	<1226079930.3997.12.camel@macbook.infradead.org>
	<alpine.LFD.1.10.0811071845170.20989@newtla.xelerance.com>
	<faa16b610811081136g7544549fw6543240a1c135be@mail.gmail.com>
	<20081110123423.GB4224@evileye.atkac.englab.brq.redhat.com>
Message-ID: <20081110115838.GA13043@shell.devel.redhat.com>

On Mon, Nov 10, 2008 at 01:34:23PM +0100, Adam Tkac wrote:
> Chroot is good and traditional method how restrict daemons. Many users
> still use it and it is far more easy create chroot configuration than
> create/maintain SELinux policy. I don't think SELinux obsoletes
> chroot, both try restrict daemon privileges and both have + and -.

chroot isn't a security feature. It helps for some non-root cases but there
are ways out of chroots and there are all sorts of fun things that can be
used to escape a chroot in the right circumstances.

Its also inadequate for some forms of attack. If I can persuade your named to
run code of my choice in a chroot without selinux then I can still use your
box as a spam machine, botnet host, DoS attack tool, proxy, etc .. all without
breaking the chroot.

In the SELinux case a lot of those actions will hit SELinux denials.



From rawhide at fedoraproject.org  Mon Nov 10 12:01:31 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Mon, 10 Nov 2008 12:01:31 +0000 (UTC)
Subject: rawhide report: 20081110 changes
Message-ID: <20081110120131.943561B8001@releng2.fedora.phx.redhat.com>

Compose started at Mon Nov 10 06:01:12 UTC 2008

Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 0









Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot





From atkac at redhat.com  Mon Nov 10 13:09:23 2008
From: atkac at redhat.com (Adam Tkac)
Date: Mon, 10 Nov 2008 14:09:23 +0100
Subject: Note for packagers whose packages need swig
Message-ID: <20081110130923.GA20286@evileye.atkac.englab.brq.redhat.com>

Hi all,

there is long standing problem with SWIG when you are wrapping around
C code and use system headers. SWIG doesn't define "standard" C
preprocessor macros. Due this it might happen that wrapped code uses
wrong data types, wrong function prototypes etc. There is bug about
this problem in upsteam bugzilla
(http://sourceforge.net/tracker/?func=detail&atid=101645&aid=1604332&group_id=1645)
but upsteam is not going to fix it.

List of packages whose use SWIG and their maintainers is on
http://atkac.fedorapeople.org/packages_needs_swig. I think every
maintainer should check his package and if it uses system C headers he
should add this to .i file (SWIG template)

$ cpp -dM /dev/null | grep -v __STDC__ > cpp_macros.h # SWIG defines __STDC__ macro

and then add '%include "cpp_macros.h" to top of .i file

After that you can be sure that wrapped code uses correct data sizes.
Feel free to ask me if you have any question.

Regards, Adam

-- 
Adam Tkac, Red Hat, Inc.



From atkac at redhat.com  Mon Nov 10 13:26:30 2008
From: atkac at redhat.com (Adam Tkac)
Date: Mon, 10 Nov 2008 14:26:30 +0100
Subject: End of bind-chroot-admin script
In-Reply-To: <20081110115838.GA13043@shell.devel.redhat.com>
References: <20081107120905.GA3188@evileye.atkac.englab.brq.redhat.com>
	<1226079930.3997.12.camel@macbook.infradead.org>
	<alpine.LFD.1.10.0811071845170.20989@newtla.xelerance.com>
	<faa16b610811081136g7544549fw6543240a1c135be@mail.gmail.com>
	<20081110123423.GB4224@evileye.atkac.englab.brq.redhat.com>
	<20081110115838.GA13043@shell.devel.redhat.com>
Message-ID: <20081110132630.GA20557@evileye.atkac.englab.brq.redhat.com>

On Mon, Nov 10, 2008 at 06:58:38AM -0500, Alan Cox wrote:
> On Mon, Nov 10, 2008 at 01:34:23PM +0100, Adam Tkac wrote:
> > Chroot is good and traditional method how restrict daemons. Many users
> > still use it and it is far more easy create chroot configuration than
> > create/maintain SELinux policy. I don't think SELinux obsoletes
> > chroot, both try restrict daemon privileges and both have + and -.
> 
> chroot isn't a security feature. It helps for some non-root cases but there
> are ways out of chroots and there are all sorts of fun things that can be
> used to escape a chroot in the right circumstances.

Well, we are quite OT but could you point me how daemon could escape chroot
when it is written correctly?

> 
> Its also inadequate for some forms of attack. If I can persuade your named to
> run code of my choice in a chroot without selinux then I can still use your
> box as a spam machine, botnet host, DoS attack tool, proxy, etc .. all without
> breaking the chroot.
> 
> In the SELinux case a lot of those actions will hit SELinux denials.
> 

Right you are but when you are using chroot it is very hard to do
such attack. I think it is nearly impossible insert and run such long
arbitrary code especially when binary is compiled with stack protector.

Make sure I also think SELinux is better but it doesn't mean that
chroot is useless and obsoleted.

Adam

-- 
Adam Tkac, Red Hat, Inc.



From mitr at volny.cz  Mon Nov 10 12:30:16 2008
From: mitr at volny.cz (Miloslav =?UTF-8?Q?Trma=C4=8D?=)
Date: Mon, 10 Nov 2008 13:30:16 +0100
Subject: Note for packagers whose packages need swig
In-Reply-To: <20081110130923.GA20286@evileye.atkac.englab.brq.redhat.com>
References: <20081110130923.GA20286@evileye.atkac.englab.brq.redhat.com>
Message-ID: <1226320216.3072.36.camel@kulicka>

Adam Tkac p??e v Po 10. 11. 2008 v 14:09 +0100:
> there is long standing problem with SWIG when you are wrapping around
> C code and use system headers. SWIG doesn't define "standard" C
> preprocessor macros.
> 
> I think every
> maintainer should check his package and if it uses system C headers he
> should add this to .i file (SWIG template)
> 
> $ cpp -dM /dev/null | grep -v __STDC__ > cpp_macros.h # SWIG defines __STDC__ macro
> 
> and then add '%include "cpp_macros.h" to top of .i file
Is there any reason not to use %import instead?  AFAICS the macros still
work in #ifdefs, but they are not added to the generated file.
	Mirek



From atkac at redhat.com  Mon Nov 10 13:36:56 2008
From: atkac at redhat.com (Adam Tkac)
Date: Mon, 10 Nov 2008 14:36:56 +0100
Subject: Note for packagers whose packages need swig
In-Reply-To: <1226320216.3072.36.camel@kulicka>
References: <20081110130923.GA20286@evileye.atkac.englab.brq.redhat.com>
	<1226320216.3072.36.camel@kulicka>
Message-ID: <20081110133656.GA28612@evileye.atkac.englab.brq.redhat.com>

On Mon, Nov 10, 2008 at 01:30:16PM +0100, Miloslav Trma? wrote:
> Adam Tkac p??e v Po 10. 11. 2008 v 14:09 +0100:
> > there is long standing problem with SWIG when you are wrapping around
> > C code and use system headers. SWIG doesn't define "standard" C
> > preprocessor macros.
> > 
> > I think every
> > maintainer should check his package and if it uses system C headers he
> > should add this to .i file (SWIG template)
> > 
> > $ cpp -dM /dev/null | grep -v __STDC__ > cpp_macros.h # SWIG defines __STDC__ macro
> > 
> > and then add '%include "cpp_macros.h" to top of .i file
> Is there any reason not to use %import instead?  AFAICS the macros still
> work in #ifdefs, but they are not added to the generated file.
> 	Mirek
> 

Yes, %import will be better than %include.

Adam

-- 
Adam Tkac, Red Hat, Inc.



From thibault.north at gmail.com  Mon Nov 10 12:43:01 2008
From: thibault.north at gmail.com (Thibault North)
Date: Mon, 10 Nov 2008 07:43:01 -0500
Subject: Segfault with alliance on liveDVD
In-Reply-To: <50baabb30811100243i260437cdja5de55c310c38ace@mail.gmail.com>
References: <200811091924.06581.tnorth@fedoraproject.org>
	<50baabb30811100156pe30841cw1acaada5b0f784df@mail.gmail.com>
	<50baabb30811100243i260437cdja5de55c310c38ace@mail.gmail.com>
Message-ID: <200811100743.04888.thibault.north@gmail.com>

Le Monday, 10. November 2008 05:43:39 am Chitlesh GOORAH, vous avez ?crit?:
> On Mon, Nov 10, 2008 at 10:56 AM, Chitlesh GOORAH wrote:
>
> I guess I found it : xorg-x11-fonts-misc-7.2-6.fc9.noarch
> Without xorg-x11-fonts-misc, graal crashes. I'll spin to verify it.
>
> Chitlesh

I can confirm that installing xorg-x11-fonts-misc fixes the problem on the 
liveDVD !
Thanks Chitlesh !

Thibault
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081110/e5a51d45/attachment.sig>

From enrico.scholz at informatik.tu-chemnitz.de  Mon Nov 10 12:47:02 2008
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Mon, 10 Nov 2008 13:47:02 +0100
Subject: End of bind-chroot-admin script
In-Reply-To: <20081110115838.GA13043@shell.devel.redhat.com> (Alan Cox's
	message of "Mon, 10 Nov 2008 06:58:38 -0500")
References: <20081107120905.GA3188@evileye.atkac.englab.brq.redhat.com>
	<1226079930.3997.12.camel@macbook.infradead.org>
	<alpine.LFD.1.10.0811071845170.20989@newtla.xelerance.com>
	<faa16b610811081136g7544549fw6543240a1c135be@mail.gmail.com>
	<20081110123423.GB4224@evileye.atkac.englab.brq.redhat.com>
	<20081110115838.GA13043@shell.devel.redhat.com>
Message-ID: <87vduvbveh.fsf@fc5.bigo.ensc.de>

Alan Cox <alan at redhat.com> writes:

> Its also inadequate for some forms of attack. If I can persuade your
> named to run code of my choice in a chroot without selinux then I can
> still use your box as a spam machine, botnet host, DoS attack tool,
> proxy, etc .. all without breaking the chroot.

Can be prevented with traditional tools too:

iptables -A OUTPUT -m owner --uid-owner named -j o-NAMED




Enrico



From yersinia.spiros at gmail.com  Mon Nov 10 12:49:31 2008
From: yersinia.spiros at gmail.com (yersinia)
Date: Mon, 10 Nov 2008 13:49:31 +0100
Subject: End of bind-chroot-admin script
In-Reply-To: <20081110132630.GA20557@evileye.atkac.englab.brq.redhat.com>
References: <20081107120905.GA3188@evileye.atkac.englab.brq.redhat.com>
	<1226079930.3997.12.camel@macbook.infradead.org>
	<alpine.LFD.1.10.0811071845170.20989@newtla.xelerance.com>
	<faa16b610811081136g7544549fw6543240a1c135be@mail.gmail.com>
	<20081110123423.GB4224@evileye.atkac.englab.brq.redhat.com>
	<20081110115838.GA13043@shell.devel.redhat.com>
	<20081110132630.GA20557@evileye.atkac.englab.brq.redhat.com>
Message-ID: <b086760e0811100449v4124eabdjf1777f60c4bbb5ac@mail.gmail.com>

Well, it is off topic IMHO with the principal mail subject but the
discussion is so interesting so some consideration on the point could be
useful

http://etbe.coker.com.au/2007/08/22/se-linux-vs-chroot/

of Russel Cooker



On Mon, Nov 10, 2008 at 2:26 PM, Adam Tkac <atkac at redhat.com> wrote:

> On Mon, Nov 10, 2008 at 06:58:38AM -0500, Alan Cox wrote:
> > On Mon, Nov 10, 2008 at 01:34:23PM +0100, Adam Tkac wrote:
> > > Chroot is good and traditional method how restrict daemons. Many users
> > > still use it and it is far more easy create chroot configuration than
> > > create/maintain SELinux policy. I don't think SELinux obsoletes
> > > chroot, both try restrict daemon privileges and both have + and -.
> >
> > chroot isn't a security feature. It helps for some non-root cases but
> there
> > are ways out of chroots and there are all sorts of fun things that can be
> > used to escape a chroot in the right circumstances.
>
> Well, we are quite OT but could you point me how daemon could escape chroot
> when it is written correctly?
>
> >
> > Its also inadequate for some forms of attack. If I can persuade your
> named to
> > run code of my choice in a chroot without selinux then I can still use
> your
> > box as a spam machine, botnet host, DoS attack tool, proxy, etc .. all
> without
> > breaking the chroot.
> >
> > In the SELinux case a lot of those actions will hit SELinux denials.
> >
>
> Right you are but when you are using chroot it is very hard to do
> such attack. I think it is nearly impossible insert and run such long
> arbitrary code especially when binary is compiled with stack protector.
>
> Make sure I also think SELinux is better but it doesn't mean that
> chroot is useless and obsoleted.
>
> Adam
>
> --
> Adam Tkac, Red Hat, Inc.
>
> --
> 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/20081110/dbc88632/attachment.htm>

From mjg at redhat.com  Mon Nov 10 12:59:04 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Mon, 10 Nov 2008 12:59:04 +0000
Subject: End of bind-chroot-admin script
In-Reply-To: <20081110132630.GA20557@evileye.atkac.englab.brq.redhat.com>
References: <20081107120905.GA3188@evileye.atkac.englab.brq.redhat.com>
	<1226079930.3997.12.camel@macbook.infradead.org>
	<alpine.LFD.1.10.0811071845170.20989@newtla.xelerance.com>
	<faa16b610811081136g7544549fw6543240a1c135be@mail.gmail.com>
	<20081110123423.GB4224@evileye.atkac.englab.brq.redhat.com>
	<20081110115838.GA13043@shell.devel.redhat.com>
	<20081110132630.GA20557@evileye.atkac.englab.brq.redhat.com>
Message-ID: <20081110125904.GB30894@srcf.ucam.org>

On Mon, Nov 10, 2008 at 02:26:30PM +0100, Adam Tkac wrote:

> Well, we are quite OT but could you point me how daemon could escape chroot
> when it is written correctly?

If the daemon is written correctly then you wouldn't need the chroot in 
the first place. The fundamental assumption behind these security 
policies is that you don't trust the software.

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



From tim at niemueller.de  Mon Nov 10 13:21:22 2008
From: tim at niemueller.de (Tim Niemueller)
Date: Mon, 10 Nov 2008 14:21:22 +0100
Subject: dlopen()/festival problem
Message-ID: <49183552.1010302@niemueller.de>

Hi C/C++ developers.

I'm having an interesting problem with Festival on F-9/F-8 and I'm not
sure whether it is a problem with dlopen(), or Festival, or if I'm just
trying something stupid. Maybe someone here has a clue or point me
somewhere I should look into to solve it:

I'm developing a software which uses shared objects (.so) as plugins.
One of those plugins provides speech synthesis via Festival. The problem
is now that it crashes at a very specific position in the speech_tools
library that comes with Festival. There are module-global variables in a
.cc file which are not properly initialized, but only if the lib is
opened via dlopen(). If I put it directly into main, or link the main
program that dlopen()s the festival plugin against the festival lib
everything works fine.

So is it intended that the standard runtime linker and dlopen() work
differently in initializing global variables of a library? Or am I
trying something not meant to work?

I have put code to illustrate the problem at
http://fedorapeople.org/~timn/festival/. To get it working do:

- install festival-devel, festival-speechtools-devel, festival-debuginfo
(if you want to see the backtrace in gdb)

- First as root you have to move some files as the festival package has
a longstanding bug (#242607), which I'm going to fix this as soon as I
got this sorted.
# cd /usr/include/speech_tools
# mv unix/EST/EST_* unix/
# mv instantiate/EST/instantiate/EST_T* instantiate/
# mv sigpr/EST/EST_* sigpr/
# mv ling_class/EST/EST_* ling_class/

- Download all files of the code from
http://fedorapeople.org/~timn/festival/. It has a simple Makefile to
build the code.

- the festival binary simply uses festival and directly links against
festival and should work just fine

- The uselib binary will dlopen() festival_lib.so (which is the custom
plugin and not the festival library itself) and then tries to execute
festival_initialize() where it fails with a segfault which can be traced
down to uninitialized global variables.


Anyone with an idea what's going wrong, what's broken or what I'm trying
that is stupid?

Thank you,
	Tim

-- 
    Tim Niemueller <tim at niemueller.de>      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)



From mcepl at redhat.com  Mon Nov 10 13:15:40 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Mon, 10 Nov 2008 14:15:40 +0100
Subject: FESCo Meeting Summary for 2008-11-05
References: <1226016932.5758.3.camel@kennedy>
	<49148BDC.7020702@fedoraproject.org>
	<alpine.LFD.1.10.0811071836480.20989@newtla.xelerance.com>
Message-ID: <soolu5xvao.ln2@ppp1053.in.ipex.cz>

On 2008-11-07, 23:44 GMT, Paul Wouters wrote:
> I notice on my F9 copy of Empathy that there is no support for 
> MSN or AIM on the default Empahty install i got (even though 
> the 'help' claims supports it).

yum install telepathy-haze

should help here.

Mat?j



From mcepl at redhat.com  Mon Nov 10 13:16:53 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Mon, 10 Nov 2008 14:16:53 +0100
Subject: Pidgin (was Re: FESCo Meeting Summary for 2008-11-05)
References: <1226016932.5758.3.camel@kennedy>
	<49148BDC.7020702@fedoraproject.org>
	<alpine.LFD.1.10.0811071836480.20989@newtla.xelerance.com>
	<aed8ecaa0811071756l3731d218g6a55eecdddf36224@mail.gmail.com>
	<alpine.LFD.1.10.0811072110410.20989@newtla.xelerance.com>
	<1226163037.5115.121.camel@sputnik.gravel>
	<adf480660811080916n68af22ffn8cb0f859912dba4f@mail.gmail.com>
	<alpine.LFD.1.10.0811081332460.20989@newtla.xelerance.com>
Message-ID: <5rolu5xvao.ln2@ppp1053.in.ipex.cz>

On 2008-11-08, 18:39 GMT, Paul Wouters wrote:
> Apparently unlike you, I have friends :) So yes, although 
> I prefer XMPP, I also talk to people using proprietary evil 
> central servers (hence my insistence on needing OTR).

Jabber transports?

Mat?j



From mcepl at redhat.com  Mon Nov 10 13:59:25 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Mon, 10 Nov 2008 14:59:25 +0100
Subject: Who moved my bug?
References: <200811061243.49188.opensource@till.name>
	<1226017819.5758.11.camel@kennedy>
	<20081107111727.GA10541@mokona.greysector.net>
	<200811081419.20620.sgrubb@redhat.com>
Message-ID: <tarlu5x85q.ln2@ppp1053.in.ipex.cz>

On 2008-11-08, 19:19 GMT, Steve Grubb wrote:
> We had this discussion a couple weeks ago and people decided on 
> the test list to start using the triaged keyword.
>
> https://www.redhat.com/archives/fedora-test-list/2008-October/msg00221.html
>
> What happened? This really is an unnecessary irritation.

Sorry, Steve, for this misunderstanding, but John really haven't 
promised to revert all ASSIGNed bugs back to NEW or something 
like that, he told he is leaning towards. Then he brought it to 
the Bug Zappers meeting, and was shut down with disagreement 
(https://fedoraproject.org/wiki/BugZappers/Meetings/Minutes-2008-Oct-07).  
If you really need to distinguish between the bugs which triaged 
(and their future life is a responsibility of a package 
maintainer -- thus they are ASSIGNED as defined by FESCO 
https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow) and 
bugs which you actively work on, I would suggest using status 
ON_DEV -- it is still present in our bugzilla (for legacy 
reasons), but not used for anything, so you can freely use it.  
Going through 9078 ASSIGNED bugs and deciding whether they should 
be moved back to NEW or not, that's just too much work for the 
very very doubtful benefit.

Best,

Mat?j



From erikina at gmail.com  Mon Nov 10 13:42:46 2008
From: erikina at gmail.com (Eric Springer)
Date: Mon, 10 Nov 2008 23:42:46 +1000
Subject: Proposal: Rolling Release
Message-ID: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>

Fedora has always lead the progress of FOSS by closely following
upstream and making non-trivial contributions. I see this is a great
strength, and like many other people it's my primary reason for using
it. But it's not without trade-offs, such as giving Fedora a
perception of being 'beta' software and balancing new software without
burning the large user base is not easy either.

This hit home today, after being impressed with the work you guys have
done with plymouth, I did a quick Google search[1] to find out a
little more. The first result is a "Ubuntu brainstorm" page[2] about
implementing it in their own distribution and the second comment is "I
support the idea but I do think that it should only be considered
after Fedora has done all the dirty work of getting it to work". This
is no way intended as a criticism of a Ubuntu, but it's a realization
that distributions like Ubuntu are able to offer a better user
experience by using stable software on a longer support cycle.

So what I propose is that Fedora goes to a rolling release cycle.
Implemented properly I believe we can better achieve Fedoras
objectives[3] of rapidly progressing Free Open Source Software, while
providing a more user centric focus (and bringing something new to the
easy-to-use-table). While I would prefer to not get bogged down in the
technical details at this stage, we would need to provide software in
varying levels of stability.

Perhaps something like:
hemorrhaging -> rawhide -> stable -> rocksolid

Users should be able to very easily and freely move through the
levels, especially on a per-package basis (with PackageKit). It should
also be easy for users to "freeze" their system/package to only
receive security (and optionally bug) patches, as many aren't
interested in the constant upgrade cycle.

New features/software/functionality would be easily tested by the
masses without needing to upgrade the entire distribution. It would
give the open source community a massive user-base they could call
upon to test easily.

The average user would sit at the 'stable' level while perhaps
testing/using a few of their favorite software from rawhide. Servers
would typically sit at the rocksolid level, and use stable packages on
a needs-only basis.



Thoughts? Flames? Ideas?




[1] http://www.google.com/search?q=Fedora+Plymouth
[2] http://brainstorm.ubuntu.com/idea/11165/
[3] http://fedoraproject.org/wiki/Objectives



From alsadi at gmail.com  Mon Nov 10 14:19:21 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Mon, 10 Nov 2008 16:19:21 +0200
Subject: sound skipping in F10
In-Reply-To: <4917F695.2040005@gmail.com>
References: <385866f0811091311q31e1a367u9de08b054a9e0989@mail.gmail.com>
	<4917652E.3020004@gmail.com> <4917A540.7050108@fedoraproject.org>
	<4917F695.2040005@gmail.com>
Message-ID: <385866f0811100619u55d9bce8rcb3bae30c8ec09b4@mail.gmail.com>

> It's all the same with or without libflashsupport. My two cents go to the
> kernel being responsible
> for the sound skipping part.
>
the same assumption by home

also I assume that ffmpeg were falsely accused for bad performance on rpmfusion

I suspect the kernel because both  alsasink and pulsesink in gst



From gnomeuser at gmail.com  Mon Nov 10 14:50:38 2008
From: gnomeuser at gmail.com (David Nielsen)
Date: Mon, 10 Nov 2008 15:50:38 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
Message-ID: <1dedbbfc0811100650w99d2c40gf8fc336e85f591e9@mail.gmail.com>

2008/11/10 Eric Springer <erikina at gmail.com>

> Fedora has always lead the progress of FOSS by closely following
> upstream and making non-trivial contributions. I see this is a great
> strength, and like many other people it's my primary reason for using
> it. But it's not without trade-offs, such as giving Fedora a
> perception of being 'beta' software and balancing new software without
> burning the large user base is not easy either.
>
> This hit home today, after being impressed with the work you guys have
> done with plymouth, I did a quick Google search[1] to find out a
> little more. The first result is a "Ubuntu brainstorm" page[2] about
> implementing it in their own distribution and the second comment is "I
> support the idea but I do think that it should only be considered
> after Fedora has done all the dirty work of getting it to work". This
> is no way intended as a criticism of a Ubuntu, but it's a realization
> that distributions like Ubuntu are able to offer a better user
> experience by using stable software on a longer support cycle.
>
> So what I propose is that Fedora goes to a rolling release cycle.
> Implemented properly I believe we can better achieve Fedoras
> objectives[3] of rapidly progressing Free Open Source Software, while
> providing a more user centric focus (and bringing something new to the
> easy-to-use-table). While I would prefer to not get bogged down in the
> technical details at this stage, we would need to provide software in
> varying levels of stability.
>
> Perhaps something like:
> hemorrhaging -> rawhide -> stable -> rocksolid
>
> Users should be able to very easily and freely move through the
> levels, especially on a per-package basis (with PackageKit). It should
> also be easy for users to "freeze" their system/package to only
> receive security (and optionally bug) patches, as many aren't
> interested in the constant upgrade cycle.
>
> New features/software/functionality would be easily tested by the
> masses without needing to upgrade the entire distribution. It would
> give the open source community a massive user-base they could call
> upon to test easily.
>
> The average user would sit at the 'stable' level while perhaps
> testing/using a few of their favorite software from rawhide. Servers
> would typically sit at the rocksolid level, and use stable packages on
> a needs-only basis.
>
> Thoughts? Flames? Ideas?


We already have a pretty much rolling release, and in many cases it serves
us best to attain stability. Take an application like Banshee, typically
only the latest release will be supported upstream, keeping one version for
a long time will thus not do our users any favors. Many applications are
like that today, we really need to supply the latest to lessen the burden on
maintainers. The same way with frameworks such as Mono (or KDE, GNOME),
upstream today generally has good QA and if it's deemed stable enough for
F10 then it should also be for F9. If something cannot be backported to
earlier releases for stability reasons then it only has a place in rawhide.

Keeping the same platform across releases will cut down on the amount of
code we have to maintain and it will keep our users supplied with the
applications they crave.

There are distributions that does this, Foresight Linux e.g. and they are
incidently greatly helped by Conary in this way of working. Gentoo also does
this. Neither camp has ever reported serious issues with this approach to
releasing updates and it seems generally appriciated by their users. It does
though diminish the idea of a release, and would require much greater effort
in QA underway (and find a convincing yet reasonably safe approach to con
users into enabling updates-testing to smoothen the roll out of big
updates).

I, for one, really like that I can install my F9 desktop and be sure that
most of my applications are up to date, and in terms of maintaining I always
did my best to keep the packages the same regardless of which release it was
on simply because it was much less work supporting and confirming bugs this
way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081110/8fd02f78/attachment.htm>

From alsadi at gmail.com  Mon Nov 10 14:21:15 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Mon, 10 Nov 2008 16:21:15 +0200
Subject: sound skipping in F10
In-Reply-To: <385866f0811100619u55d9bce8rcb3bae30c8ec09b4@mail.gmail.com>
References: <385866f0811091311q31e1a367u9de08b054a9e0989@mail.gmail.com>
	<4917652E.3020004@gmail.com> <4917A540.7050108@fedoraproject.org>
	<4917F695.2040005@gmail.com>
	<385866f0811100619u55d9bce8rcb3bae30c8ec09b4@mail.gmail.com>
Message-ID: <385866f0811100621w3410f3bp1b111e4890ad7d33@mail.gmail.com>

I have a question about
> If you are using Flash 10, you should *not* install libflashsupport.
do you mean it or do you mean "need not"

anyway the problem is even in nonflash player



From jan.kratochvil at redhat.com  Mon Nov 10 15:24:54 2008
From: jan.kratochvil at redhat.com (Jan Kratochvil)
Date: Mon, 10 Nov 2008 16:24:54 +0100
Subject: dlopen()/festival problem
In-Reply-To: <49183552.1010302@niemueller.de>
References: <49183552.1010302@niemueller.de>
Message-ID: <20081110152454.GA9380@host0.dyn.jankratochvil.net>

Hi Tim,

On Mon, 10 Nov 2008 14:21:22 +0100, Tim Niemueller wrote:
> So is it intended that the standard runtime linker and dlopen() work
> differently in initializing global variables of a library?

I did not see a problem with this.  BTW I would use `g++' instead of
`gcc -lstdc++'.

The problem is in the festival libraries build.  They use the default
visibility and their symbol `backtrace':
  ./speech_tools/siod/slib.cc
  LISP backtrace = NIL;
is being overriden by the glibc function `backtrace':
  /usr/include/execinfo.h
  extern int backtrace (void **__array, int __size) __nonnull ((1));
One apparently cannot write to a .text readonly section as it attempts to.

The package festival should be built with -fvisibility=hidden and specific
global functions/variables marked by `__attribute__ ((visibility("default")))'
as described in `man gcc' -fvisibility and
http://people.redhat.com/drepper/dsohowto.pdf .

As a temporary workaround you may use dlopen() flag RTLD_DEEPBIND.
BTW it is also more effective to use RTLD_LAZY than RTLD_NOW.


Regards,
Jan



From poelstra at redhat.com  Mon Nov 10 15:37:44 2008
From: poelstra at redhat.com (John Poelstra)
Date: Mon, 10 Nov 2008 07:37:44 -0800
Subject: Flash 10 in 64-bit F9: does it work?
In-Reply-To: <200811082216.mA8MGeSh004187@jasmine.xos.nl>
References: <200811082216.mA8MGeSh004187@jasmine.xos.nl>
Message-ID: <49185548.8050609@redhat.com>

Jos Vos wrote:
> Hi,
> 
> Did anyone manage to get flash 10 working on 64-bit F9?  Note that
> I didn't try on 32-bit yet, so I can't comment on that (yet).  But
> on 64-bit, the flash 10 plugin is loaded (using nspluginwrapper etc.)
> and listed in Firefox.  But as soon as I visit a flash page, it gives
> error messages about not finding "soundwrapper" in my $PATH and it
> doesn't display anything.

This explains how...

section 4.1.9.1
http://docs.fedoraproject.org/release-notes/f10preview/en_US/What_is_the_Latest_on_the_Desktop.html

I wonder if there is a way to include this in the table of contents so 
it is easier to find.

John



From jreiser at BitWagon.com  Mon Nov 10 15:47:33 2008
From: jreiser at BitWagon.com (John Reiser)
Date: Mon, 10 Nov 2008 07:47:33 -0800
Subject: dlopen()/festival problem
In-Reply-To: <20081110152454.GA9380@host0.dyn.jankratochvil.net>
References: <49183552.1010302@niemueller.de>
	<20081110152454.GA9380@host0.dyn.jankratochvil.net>
Message-ID: <49185795.1030605@BitWagon.com>

> BTW it is also more effective to use RTLD_LAZY than RTLD_NOW.

In what way is RTLD_LAZY more effective than RTLD_NOW?

Using RTLD_NOW can make future latencies lower (or at least more
deterministric) by performing most dynamic symbol resolutions
immediately in one big batch.  This trades a higher initial cost
(and possibly more total work, if not all the resolutions
will be used) for lower latency in the future.

-- 



From mike at cchtml.com  Mon Nov 10 15:58:52 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Mon, 10 Nov 2008 09:58:52 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
Message-ID: <49185A3C.7050700@cchtml.com>

-------- Original Message --------
Subject: Proposal: Rolling Release
From: Eric Springer <erikina at gmail.com>
To: fedora-devel-list at redhat.com
Date: 11/10/2008 07:42 AM

> 
> Thoughts? Flames? Ideas?
> 
> 

Actually, what Fedora needs already exists: preupgrade

It just needs to be turned into a mandatory update tool with PackageKit. 
  Joe Enduser needs to be able to click "Update Me!" and go from Fedora 
9 to Fedora 10 with a single click.

Software moves too quickly today to have a "long term" distribution. If 
you need "long term" look at a commercial distro like Red Hat (Cent OS).



From nicolas.mailhot at laposte.net  Mon Nov 10 16:17:24 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 10 Nov 2008 17:17:24 +0100
Subject: Fedora 11 font package changes proposal (renames, splits, etc)
In-Reply-To: <1226228950.21652.95.camel@arekh.okg>
References: <1226228950.21652.95.camel@arekh.okg>
Message-ID: <1226333844.17989.9.camel@arekh.okg>

Le dimanche 09 novembre 2008 ? 12:09 +0100, Nicolas Mailhot a ?crit :

> ??? Proof of concept:
> 
> Dejavu has been used to proof the concepts in rawhide (cf the wiki page)

To proof it some more I've separated the common macro, spec templates
and directory definitions in a separate package, then modified three
font packages to use it:
? dejavu: multiple font families, multiple fontconfig files, 
? theokritos: single font family and fontconfig file,
? vera: multiple font families and no config file

It all works with the same macros, factors out the magic and reduces
average font package complexity.

(and hopefully the number of mistakes on has to correct in review)

What do people think of it ?

http://nim.fedorapeople.org/rpm-fonts/

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/20081110/f531724d/attachment.sig>

From sundaram at fedoraproject.org  Mon Nov 10 16:47:11 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 10 Nov 2008 22:17:11 +0530
Subject: Proposal: Rolling Release
In-Reply-To: <49185A3C.7050700@cchtml.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<49185A3C.7050700@cchtml.com>
Message-ID: <4918658F.8060709@fedoraproject.org>

Michael Cronenworth wrote:
> -------- Original Message --------
> Subject: Proposal: Rolling Release
> From: Eric Springer <erikina at gmail.com>
> To: fedora-devel-list at redhat.com
> Date: 11/10/2008 07:42 AM
> 
>>
>> Thoughts? Flames? Ideas?
>>
>>
> 
> Actually, what Fedora needs already exists: preupgrade
> 
> It just needs to be turned into a mandatory update tool with PackageKit. 
>  Joe Enduser needs to be able to click "Update Me!" and go from Fedora 9 
> to Fedora 10 with a single click.

Already implemented. PackageKit hooks up to Preupgrade and you would get 
a desktop blurb letting you know that when a subsequent release of 
Fedora is available.

Rahul



From paul at xelerance.com  Mon Nov 10 17:03:35 2008
From: paul at xelerance.com (Paul Wouters)
Date: Mon, 10 Nov 2008 12:03:35 -0500 (EST)
Subject: End of bind-chroot-admin script
In-Reply-To: <b086760e0811100357j5ec031b6m77033507ea49adf6@mail.gmail.com>
References: <20081107120905.GA3188@evileye.atkac.englab.brq.redhat.com> 
	<1226079930.3997.12.camel@macbook.infradead.org> 
	<alpine.LFD.1.10.0811071845170.20989@newtla.xelerance.com> 
	<20081110122658.GA4224@evileye.atkac.englab.brq.redhat.com>
	<b086760e0811100357j5ec031b6m77033507ea49adf6@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0811101159220.27084@newtla.xelerance.com>

On Mon, 10 Nov 2008, yersinia wrote:

> But many people disable Selinux, so it is always better to have a secure
> alternatives - Selinux is better IMHO and it is possible
> to do "chroot" better with selinux (
> http://www.coker.com.au/selinux/talks/sage-2006/PolyInstantiatedDirectories.html
> )

The question is, is it worth the hassle of maintaining the chroot. This is
important for both named and unbound as they will be able in the near
future to include dnssec keys, which will be provided by a different
package. So one has to update the chroot when a "third party" package
updates itself. 

I'm currently doing this with the unbound nameserver, but it is quite
ugly.

Paul



From jspaleta at gmail.com  Mon Nov 10 16:59:40 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 10 Nov 2008 07:59:40 -0900
Subject: Proposal: Rolling Release
In-Reply-To: <4918658F.8060709@fedoraproject.org>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<49185A3C.7050700@cchtml.com> <4918658F.8060709@fedoraproject.org>
Message-ID: <604aa7910811100859i709a9b57r41ede8ee8fe4468f@mail.gmail.com>

On Mon, Nov 10, 2008 at 7:47 AM, Rahul Sundaram
> Already implemented. PackageKit hooks up to Preupgrade and you would get a
> desktop blurb letting you know that when a subsequent release of Fedora is
> available.

Uhm, is that notification going to happen on F9 systems the moment F10
is available?  It might be wise to hold off a few days at least so
that the initial release day iso grab subsides from the mirrors.

-jef



From pertusus at free.fr  Mon Nov 10 17:01:02 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 10 Nov 2008 18:01:02 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
Message-ID: <20081110170101.GB3153@free.fr>

On Mon, Nov 10, 2008 at 11:42:46PM +1000, Eric Springer wrote:
> varying levels of stability.
> 
> Perhaps something like:
> hemorrhaging -> rawhide -> stable -> rocksolid

There has been a long thread about keeping infrastructure open after 
normal end of life:
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00671.html
It is very long and very heated. I don't think it is time to restart the
flamewar. Maybe the other things you propose (be able to use parts of
rawhide through a gui) should better be in a thread not mentionning
something that smells like longer term support.

Are you satisfied with

yum update something --enable-repo=rawhide

on the command line? Or do you want to be able to also go back to older
versions?

--
Pat



From pertusus at free.fr  Mon Nov 10 17:01:54 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 10 Nov 2008 18:01:54 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <49185A3C.7050700@cchtml.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<49185A3C.7050700@cchtml.com>
Message-ID: <20081110170154.GC3153@free.fr>

On Mon, Nov 10, 2008 at 09:58:52AM -0600, Michael Cronenworth wrote:
>
> Actually, what Fedora needs already exists: preupgrade
>
> It just needs to be turned into a mandatory update tool with PackageKit.  
>  Joe Enduser needs to be able to click "Update Me!" and go from Fedora 9 
> to Fedora 10 with a single click.

It is very different than what the other person asked for. That being
said I don't think it is time to revive recent flamewars.

--
Pat



From notting at redhat.com  Mon Nov 10 17:10:35 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 10 Nov 2008 12:10:35 -0500
Subject: Fedora 11 font package changes proposal (renames, splits, etc)
In-Reply-To: <1226228950.21652.95.camel@arekh.okg>
References: <1226228950.21652.95.camel@arekh.okg>
Message-ID: <20081110171035.GG8850@nostromo.devel.redhat.com>

Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> ? package splits, to offer more flexibility to spin groups and fedora
> users

...
> ? help spins and users
> 
> Wanting serif from dejavu, mono from liberation, and sans from tiresias,
> without dragging in all the other dejavu/liberation/tiresias fonts is a
> valid setup.

This sounds like severe overkill. If they want different scripts, why
not just adjust their fontconfig configuration? Realistically, I can't
think of an example where we'd want to ship dejavu for one script but
not another. Do you have one?

It's not as if the split would save that much space on any normal
install.

Bill



From notting at redhat.com  Mon Nov 10 17:17:12 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 10 Nov 2008 12:17:12 -0500
Subject: db-compat
In-Reply-To: <1226293343.30170.4.camel@jcmlaptop>
References: <1226293343.30170.4.camel@jcmlaptop>
Message-ID: <20081110171712.GH8850@nostromo.devel.redhat.com>

Jon Masters (jonathan at jonmasters.org) said: 
> It would seem we're no longer shipping libdb-4.1.so, whereas we do have
> 4.2, 4.3, and 4.5 in that db4 compatibility package. I wound up just
> stealing the binary from an older RPM and copying it in place.
> 
> Anyway, software like Xilinx's ISE/EDK would like it back :)

So, this is software that hasn't been rebuilt since RHEL 3 (or an
equivalent thereof.) We certainly don't support Fedora releases that
far back.

Bill



From lesmikesell at gmail.com  Mon Nov 10 17:27:31 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 10 Nov 2008 11:27:31 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <4918658F.8060709@fedoraproject.org>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<49185A3C.7050700@cchtml.com>
	<4918658F.8060709@fedoraproject.org>
Message-ID: <49186F03.5040008@gmail.com>

Rahul Sundaram wrote:
> Michael Cronenworth wrote:
>> -------- Original Message --------
>> Subject: Proposal: Rolling Release
>> From: Eric Springer <erikina at gmail.com>
>> To: fedora-devel-list at redhat.com
>> Date: 11/10/2008 07:42 AM
>>
>>>
>>> Thoughts? Flames? Ideas?
>>>
>>>
>>
>> Actually, what Fedora needs already exists: preupgrade
>>
>> It just needs to be turned into a mandatory update tool with 
>> PackageKit.  Joe Enduser needs to be able to click "Update Me!" and go 
>> from Fedora 9 to Fedora 10 with a single click.
> 
> Already implemented. PackageKit hooks up to Preupgrade and you would get 
> a desktop blurb letting you know that when a subsequent release of 
> Fedora is available.

The real missing piece is 'undo' when you find out that a change in the 
new version breaks something that you need.  Does anyone know if that 
actually works on systems using conary (i.e. can you back up a major 
revision)?

If that's not feasible, how about something else, useful in its own 
right: a migration tool that would let you move an existing system to 
different hardware or in/out of VMware/virtualbox, etc., preferably with 
the ability to keep everything but the system partitions intact and 
shared.  Then when it is time to upgrade, you could migrate into a 
virtualbox image or spare machine, upgrade that, then after testing your 
apps and usage, migrate it to the host hardware.

Or if that's too complicated, how about an option to pre-allocate a 
spare system partition during the initial install for the next version 
and have that upgrade process give you a dual-boot system so you have a 
way back.  Then the next upgrade would rotate back to the first 
partition, and so on.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From alsadi at gmail.com  Mon Nov 10 17:36:49 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Mon, 10 Nov 2008 19:36:49 +0200
Subject: Fedora 11 font package changes proposal (renames, splits, etc)
In-Reply-To: <20081110171035.GG8850@nostromo.devel.redhat.com>
References: <1226228950.21652.95.camel@arekh.okg>
	<20081110171035.GG8850@nostromo.devel.redhat.com>
Message-ID: <385866f0811100936p797ba409xa60c4cf8e61bada9@mail.gmail.com>

I consider dejavu the only complete font collection and I want all of its fonts

maybe because I don't have to read CJK scripts and I'm not sure if
dejavu supports them

but dejavu are the only generic fonts that supports Arabic in fedora
(other Arabic fonts are arabic only fonts)

to me dejavu is a must and there is no use of splitting them



From mattdm at mattdm.org  Mon Nov 10 17:44:42 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 10 Nov 2008 12:44:42 -0500
Subject: dlopen()/festival problem
In-Reply-To: <20081110152454.GA9380@host0.dyn.jankratochvil.net>
References: <49183552.1010302@niemueller.de>
	<20081110152454.GA9380@host0.dyn.jankratochvil.net>
Message-ID: <20081110174442.GA1935@jadzia.bu.edu>

On Mon, Nov 10, 2008 at 04:24:54PM +0100, Jan Kratochvil wrote:
> The problem is in the festival libraries build.  They use the default
> visibility and their symbol `backtrace':
>   ./speech_tools/siod/slib.cc
>   LISP backtrace = NIL;
> is being overriden by the glibc function `backtrace':
>   /usr/include/execinfo.h
>   extern int backtrace (void **__array, int __size) __nonnull ((1));
> One apparently cannot write to a .text readonly section as it attempts to.
> 
> The package festival should be built with -fvisibility=hidden and specific
> global functions/variables marked by `__attribute__ ((visibility("default")))'
> as described in `man gcc' -fvisibility and
> http://people.redhat.com/drepper/dsohowto.pdf .
> 
> As a temporary workaround you may use dlopen() flag RTLD_DEEPBIND.
> BTW it is also more effective to use RTLD_LAZY than RTLD_NOW.

Can you file this in bugzilla so that I don't forget about it? I'm planning
to do a big update of festival after F10 is out the door.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From nicolas.mailhot at laposte.net  Mon Nov 10 17:53:52 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 10 Nov 2008 18:53:52 +0100
Subject: Fedora 11 font package changes proposal (renames, splits, etc)
In-Reply-To: <20081110171035.GG8850@nostromo.devel.redhat.com>
References: <1226228950.21652.95.camel@arekh.okg>
	<20081110171035.GG8850@nostromo.devel.redhat.com>
Message-ID: <1226339632.17989.28.camel@arekh.okg>

Le lundi 10 novembre 2008 ? 12:10 -0500, Bill Nottingham a ?crit :
> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> > ? package splits, to offer more flexibility to spin groups and fedora
> > users
> 
> ...
> > ? help spins and users
> > 
> > Wanting serif from dejavu, mono from liberation, and sans from tiresias,
> > without dragging in all the other dejavu/liberation/tiresias fonts is a
> > valid setup.
> 
> This sounds like severe overkill. If they want different scripts, why
> not just adjust their fontconfig configuration? Realistically, I can't
> think of an example where we'd want to ship dejavu for one script but
> not another. Do you have one?

Actually dejavu is a bad example because everyone wants it. I only did
it because it's a complex and complete package that could stress the
macros (also because it's my main package).

But for the other font packages, it's very common to want only one font
in a collection (for example all our artists use one mgopen font but not
the others, we only need one font installed by default for each script
to support it in the default install, etc).

Also that makes dynamic font installation possible: when a document or
web page references a font you can just install the corresponding
package and not drag megs of unrelated fonts that just happened to be
released by the same entity.

-- 
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/20081110/729a00c0/attachment.sig>

From martin.langhoff at gmail.com  Mon Nov 10 17:57:23 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Mon, 10 Nov 2008 12:57:23 -0500
Subject: Proposal: Rolling Release
In-Reply-To: <49186F03.5040008@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<49185A3C.7050700@cchtml.com> <4918658F.8060709@fedoraproject.org>
	<49186F03.5040008@gmail.com>
Message-ID: <46a038f90811100957u175bd866hcdfa636a88530352@mail.gmail.com>

On Mon, Nov 10, 2008 at 12:27 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> The real missing piece is 'undo' when you find out that a change in the new
> version breaks something that you need.  Does anyone know if that actually
> works on systems using conary (i.e. can you back up a major revision)?

Using hardlink forests, Scott's olpc-update does some of that. It's
not integrated to rpm/yum but it could easily be turned into a "cheap
snapshot" without having to wait for ZFS/BTRFS. I am not madly in love
with it, but it does its job.

You'll find - however- that applications and desktop environments
often upgrade their storage formats, so your downgrade path may be
well oiled in the rpm/yum sense, and yet completely unusable for end
users.

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 behdad at behdad.org  Mon Nov 10 17:59:58 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Mon, 10 Nov 2008 18:59:58 +0100
Subject: Fedora 11 font package changes proposal (renames, splits, etc)
In-Reply-To: <1226339632.17989.28.camel@arekh.okg>
References: <1226228950.21652.95.camel@arekh.okg>	<20081110171035.GG8850@nostromo.devel.redhat.com>
	<1226339632.17989.28.camel@arekh.okg>
Message-ID: <4918769E.2090404@behdad.org>

Nicolas Mailhot wrote:
> Le lundi 10 novembre 2008 ? 12:10 -0500, Bill Nottingham a ?crit :
>> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
>>> ? package splits, to offer more flexibility to spin groups and fedora
>>> users
>> ...
>>> ? help spins and users
>>>
>>> Wanting serif from dejavu, mono from liberation, and sans from tiresias,
>>> without dragging in all the other dejavu/liberation/tiresias fonts is a
>>> valid setup.
>> This sounds like severe overkill. If they want different scripts, why
>> not just adjust their fontconfig configuration? Realistically, I can't
>> think of an example where we'd want to ship dejavu for one script but
>> not another. Do you have one?

I have to agree with Bill here.  It's overkill.  Also note that, the more font
packages we have, means the more font directories we have (unless we stuff
fonts from different packages in the same dir), which means more work to do at
each application startup (we mmap() one cache file per font dir).  On my
system any application mmap's 150 cache files right now.  Don't make that 150.
    The cost is nonnegligible;  on the order of 1ms per cache file.

behdad

> Actually dejavu is a bad example because everyone wants it. I only did
> it because it's a complex and complete package that could stress the
> macros (also because it's my main package).
> 
> But for the other font packages, it's very common to want only one font
> in a collection (for example all our artists use one mgopen font but not
> the others, we only need one font installed by default for each script
> to support it in the default install, etc).
> 
> Also that makes dynamic font installation possible: when a document or
> web page references a font you can just install the corresponding
> package and not drag megs of unrelated fonts that just happened to be
> released by the same entity.
> 
> 



From sundaram at fedoraproject.org  Mon Nov 10 18:02:42 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 10 Nov 2008 23:32:42 +0530
Subject: Proposal: Rolling Release
In-Reply-To: <604aa7910811100859i709a9b57r41ede8ee8fe4468f@mail.gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<49185A3C.7050700@cchtml.com>
	<4918658F.8060709@fedoraproject.org>
	<604aa7910811100859i709a9b57r41ede8ee8fe4468f@mail.gmail.com>
Message-ID: <49187742.2040702@fedoraproject.org>

Jeff Spaleta wrote:
> On Mon, Nov 10, 2008 at 7:47 AM, Rahul Sundaram
>> Already implemented. PackageKit hooks up to Preupgrade and you would get a
>> desktop blurb letting you know that when a subsequent release of Fedora is
>> available.
> 
> Uhm, is that notification going to happen on F9 systems the moment F10
> is available?  It might be wise to hold off a few days at least so
> that the initial release day iso grab subsides from the mirrors.

It is a Fedora 10 feature and that requires that new packagekit. Not 
available for Fedora 9 users (yet).

Rahul



From sundaram at fedoraproject.org  Mon Nov 10 18:05:16 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 10 Nov 2008 23:35:16 +0530
Subject: Proposal: Rolling Release
In-Reply-To: <49186F03.5040008@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<49185A3C.7050700@cchtml.com>	<4918658F.8060709@fedoraproject.org>
	<49186F03.5040008@gmail.com>
Message-ID: <491877DC.4010806@fedoraproject.org>

Les Mikesell wrote:
> Rahul Sundaram wrote:
>> Michael Cronenworth wrote:
>>> -------- Original Message --------
>>> Subject: Proposal: Rolling Release
>>> From: Eric Springer <erikina at gmail.com>
>>> To: fedora-devel-list at redhat.com
>>> Date: 11/10/2008 07:42 AM
>>>
>>>>
>>>> Thoughts? Flames? Ideas?
>>>>
>>>>
>>>
>>> Actually, what Fedora needs already exists: preupgrade
>>>
>>> It just needs to be turned into a mandatory update tool with 
>>> PackageKit.  Joe Enduser needs to be able to click "Update Me!" and 
>>> go from Fedora 9 to Fedora 10 with a single click.
>>
>> Already implemented. PackageKit hooks up to Preupgrade and you would 
>> get a desktop blurb letting you know that when a subsequent release of 
>> Fedora is available.
> 
> The real missing piece is 'undo' when you find out that a change in the 
> new version breaks something that you need.  Does anyone know if that 
> actually works on systems using conary (i.e. can you back up a major 
> revision)?

Not feasible for RPM due to pre/post scripts. The rudimentary roll back 
support in RPM has actually been removed in 4.6. It probably needs the 
underlying filesytem to support snapshots. Something like btrfs needs to 
be in place first.

> If that's not feasible, how about something else, useful in its own 
> right: a migration tool that would let you move an existing system to 
> different hardware or in/out of VMware/virtualbox, etc., preferably with 
> the ability to keep everything but the system partitions intact and 
> shared.  Then when it is time to upgrade, you could migrate into a 
> virtualbox image or spare machine, upgrade that, then after testing your 
> apps and usage, migrate it to the host hardware.
> 
> Or if that's too complicated, how about an option to pre-allocate a 
> spare system partition during the initial install for the next version 
> and have that upgrade process give you a dual-boot system so you have a 
> way back.  Then the next upgrade would rotate back to the first 
> partition, and so on.

File RFE's in http://bugzilla.redhat.com. Otherwise it will likely just 
get lost in a long thread.

Rahul



From stlwrt at gmail.com  Mon Nov 10 18:08:51 2008
From: stlwrt at gmail.com (Pavel Shevchuk)
Date: Mon, 10 Nov 2008 20:08:51 +0200
Subject: Proposal: Rolling Release
In-Reply-To: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
Message-ID: <d25f375f0811101008h95479f3sa43dc09bf0c6f231@mail.gmail.com>

I was ArchLinux user for 2.5 years before switched to Fedora. I DO NOT
WANT rolling release please. Leave rolling to gentoo, arch and other
plumber's distros, keep making great desktop system i can put on work
box and just use it.

Recently nagios got updated from 2.x to 3.x branch in RPMForge EL
repository and yum-cron pulled it in automagically. Result is broken
monitoring tool i don't have time/will to repair. I don't want to my
development tools to break suddenly few days before project deadline
at work while applying bugfix packages to amarok.

There's a reason why Fedora supports development, current and previous
branches. Fedora is designed to WORK while being bleeding edge

On Mon, Nov 10, 2008 at 3:42 PM, Eric Springer <erikina at gmail.com> wrote:
> Fedora has always lead the progress of FOSS by closely following
> upstream and making non-trivial contributions. I see this is a great
> strength, and like many other people it's my primary reason for using
> it. But it's not without trade-offs, such as giving Fedora a
> perception of being 'beta' software and balancing new software without
> burning the large user base is not easy either.
>
> This hit home today, after being impressed with the work you guys have
> done with plymouth, I did a quick Google search[1] to find out a
> little more. The first result is a "Ubuntu brainstorm" page[2] about
> implementing it in their own distribution and the second comment is "I
> support the idea but I do think that it should only be considered
> after Fedora has done all the dirty work of getting it to work". This
> is no way intended as a criticism of a Ubuntu, but it's a realization
> that distributions like Ubuntu are able to offer a better user
> experience by using stable software on a longer support cycle.
>
> So what I propose is that Fedora goes to a rolling release cycle.
> Implemented properly I believe we can better achieve Fedoras
> objectives[3] of rapidly progressing Free Open Source Software, while
> providing a more user centric focus (and bringing something new to the
> easy-to-use-table). While I would prefer to not get bogged down in the
> technical details at this stage, we would need to provide software in
> varying levels of stability.
>
> Perhaps something like:
> hemorrhaging -> rawhide -> stable -> rocksolid
>
> Users should be able to very easily and freely move through the
> levels, especially on a per-package basis (with PackageKit). It should
> also be easy for users to "freeze" their system/package to only
> receive security (and optionally bug) patches, as many aren't
> interested in the constant upgrade cycle.
>
> New features/software/functionality would be easily tested by the
> masses without needing to upgrade the entire distribution. It would
> give the open source community a massive user-base they could call
> upon to test easily.
>
> The average user would sit at the 'stable' level while perhaps
> testing/using a few of their favorite software from rawhide. Servers
> would typically sit at the rocksolid level, and use stable packages on
> a needs-only basis.
>
>
>
> Thoughts? Flames? Ideas?
>
>
>
>
> [1] http://www.google.com/search?q=Fedora+Plymouth
> [2] http://brainstorm.ubuntu.com/idea/11165/
> [3] http://fedoraproject.org/wiki/Objectives
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
http://scwlab.com



From lesmikesell at gmail.com  Mon Nov 10 18:17:34 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 10 Nov 2008 12:17:34 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <46a038f90811100957u175bd866hcdfa636a88530352@mail.gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<49185A3C.7050700@cchtml.com>
	<4918658F.8060709@fedoraproject.org>	<49186F03.5040008@gmail.com>
	<46a038f90811100957u175bd866hcdfa636a88530352@mail.gmail.com>
Message-ID: <49187ABE.10305@gmail.com>

Martin Langhoff wrote:
> On Mon, Nov 10, 2008 at 12:27 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
>> The real missing piece is 'undo' when you find out that a change in the new
>> version breaks something that you need.  Does anyone know if that actually
>> works on systems using conary (i.e. can you back up a major revision)?
> 
> Using hardlink forests, Scott's olpc-update does some of that. It's
> not integrated to rpm/yum but it could easily be turned into a "cheap
> snapshot" without having to wait for ZFS/BTRFS. I am not madly in love
> with it, but it does its job.

I'm not sure returning to a filesystem snapshot is exactly the right 
thing either unless the update fails to run at all.  You may have run 
long enough to make changes you want to keep before discovering the 
showstopper bug.

> You'll find - however- that applications and desktop environments
> often upgrade their storage formats, so your downgrade path may be
> well oiled in the rpm/yum sense, and yet completely unusable for end
> users.

Yes, but that is a problem on its own.  It is just as horrible that you 
can't mount a shared /home for an assortment for an assortment of 
distro's/versions to access simultaneously or serially.  You'd think 
there would be some standards for that sort of thing - or people would 
just avoid applications that can't settle on a format that can be 
backwards/forwards compatible.

-- 
   Les Mikesell
    lesmikesll at gmail.com



From galibert at pobox.com  Mon Nov 10 18:19:43 2008
From: galibert at pobox.com (Olivier Galibert)
Date: Mon, 10 Nov 2008 19:19:43 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <1dedbbfc0811100650w99d2c40gf8fc336e85f591e9@mail.gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<1dedbbfc0811100650w99d2c40gf8fc336e85f591e9@mail.gmail.com>
Message-ID: <20081110181943.GD30058@dspnet.fr.eu.org>

On Mon, Nov 10, 2008 at 03:50:38PM +0100, David Nielsen wrote:
> I, for one, really like that I can install my F9 desktop and be sure that
> most of my applications are up to date

Only for a year from the release of f9 though...

  OG.



From nicolas.mailhot at laposte.net  Mon Nov 10 18:22:05 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 10 Nov 2008 19:22:05 +0100
Subject: Fedora 11 font package changes proposal (renames, splits, etc)
In-Reply-To: <4918769E.2090404@behdad.org>
References: <1226228950.21652.95.camel@arekh.okg>
	<20081110171035.GG8850@nostromo.devel.redhat.com>
	<1226339632.17989.28.camel@arekh.okg>  <4918769E.2090404@behdad.org>
Message-ID: <1226341325.22664.3.camel@arekh.okg>

Le lundi 10 novembre 2008 ? 18:59 +0100, Behdad Esfahbod a ?crit :

> Also note that, the more font
> packages we have, means the more font directories we have (unless we stuff
> fonts from different packages in the same dir), 

Right now separate subpackages share the same directory. Precisely
because the cost of a fc-cache run is smaller than multiplying font
directories (and the splitting macros even enforce that which was not
the case of all the manual packaging we did before).

So on this front, controlled macroized split will make the situation
better, not worse.


-- 
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/20081110/8abee43f/attachment.sig>

From pertusus at free.fr  Mon Nov 10 18:23:29 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 10 Nov 2008 19:23:29 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <d25f375f0811101008h95479f3sa43dc09bf0c6f231@mail.gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<d25f375f0811101008h95479f3sa43dc09bf0c6f231@mail.gmail.com>
Message-ID: <20081110182329.GH3153@free.fr>

On Mon, Nov 10, 2008 at 08:08:51PM +0200, Pavel Shevchuk wrote:
> 
> Recently nagios got updated from 2.x to 3.x branch in RPMForge EL
> repository and yum-cron pulled it in automagically. Result is broken
> monitoring tool i don't have time/will to repair. I don't want to my

This can also happen in fedora, it is common to have package changes
applied to 'stable' branches. Also I don't think this is what the person
you responded to had in mind, indeed a 'rocksolid' (or even a 'stable'?)
release would certainly be a release where updating packages to the
latest version is avoided.

--
Pat



From galibert at pobox.com  Mon Nov 10 18:24:58 2008
From: galibert at pobox.com (Olivier Galibert)
Date: Mon, 10 Nov 2008 19:24:58 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <49185A3C.7050700@cchtml.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<49185A3C.7050700@cchtml.com>
Message-ID: <20081110182458.GE30058@dspnet.fr.eu.org>

On Mon, Nov 10, 2008 at 09:58:52AM -0600, Michael Cronenworth wrote:
> It just needs to be turned into a mandatory update tool with PackageKit. 
>  Joe Enduser needs to be able to click "Update Me!" and go from Fedora 
> 9 to Fedora 10 with a single click.

Can I update from up-to-date fedora N to fedora N+1 through a command
line ssh connection now?  Or is that still unsupported?

And if yes, how?  Is it just changing the repository to N+1 and yum
update?

No clicking or booting on something else involved, please.  Something
one can do reasonably automatically on 300+ systems without having to
go in front of them.

  OG.



From limb at jcomserv.net  Mon Nov 10 18:30:45 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Mon, 10 Nov 2008 12:30:45 -0600 (CST)
Subject: Proposal: Rolling Release
In-Reply-To: <20081110182458.GE30058@dspnet.fr.eu.org>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<49185A3C.7050700@cchtml.com>
	<20081110182458.GE30058@dspnet.fr.eu.org>
Message-ID: <24efe1db0d551166bc41c2a9969bb74d.squirrel@mail.jcomserv.net>


> On Mon, Nov 10, 2008 at 09:58:52AM -0600, Michael Cronenworth wrote:
>> It just needs to be turned into a mandatory update tool with PackageKit.
>>  Joe Enduser needs to be able to click "Update Me!" and go from Fedora
>> 9 to Fedora 10 with a single click.
>
> Can I update from up-to-date fedora N to fedora N+1 through a command
> line ssh connection now?  Or is that still unsupported?
>
> And if yes, how?  Is it just changing the repository to N+1 and yum
> update?

http://fedoraproject.org/wiki/SIGs/LiveUpgrade

> No clicking or booting on something else involved, please.  Something
> one can do reasonably automatically on 300+ systems without having to
> go in front of them.
>
>   OG.
>
> --
> 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 galibert at pobox.com  Mon Nov 10 18:49:19 2008
From: galibert at pobox.com (Olivier Galibert)
Date: Mon, 10 Nov 2008 19:49:19 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <24efe1db0d551166bc41c2a9969bb74d.squirrel@mail.jcomserv.net>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<49185A3C.7050700@cchtml.com>
	<20081110182458.GE30058@dspnet.fr.eu.org>
	<24efe1db0d551166bc41c2a9969bb74d.squirrel@mail.jcomserv.net>
Message-ID: <20081110184919.GA44008@dspnet.fr.eu.org>

On Mon, Nov 10, 2008 at 12:30:45PM -0600, Jon Ciesla wrote:
> 
> > On Mon, Nov 10, 2008 at 09:58:52AM -0600, Michael Cronenworth wrote:
> >> It just needs to be turned into a mandatory update tool with PackageKit.
> >>  Joe Enduser needs to be able to click "Update Me!" and go from Fedora
> >> 9 to Fedora 10 with a single click.
> >
> > Can I update from up-to-date fedora N to fedora N+1 through a command
> > line ssh connection now?  Or is that still unsupported?
> >
> > And if yes, how?  Is it just changing the repository to N+1 and yum
> > update?
> 
> http://fedoraproject.org/wiki/SIGs/LiveUpgrade

Niiiiiiiiiice.  Now that's one thing that is going to make my sysadmin
life nicer.

  OG.



From seg at haxxed.com  Mon Nov 10 18:52:10 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Mon, 10 Nov 2008 12:52:10 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <491877DC.4010806@fedoraproject.org>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<49185A3C.7050700@cchtml.com>	<4918658F.8060709@fedoraproject.org>
	<49186F03.5040008@gmail.com>  <491877DC.4010806@fedoraproject.org>
Message-ID: <1226343130.4020.12.camel@localhost.localdomain>

On Mon, 2008-11-10 at 23:35 +0530, Rahul Sundaram wrote:
> > The real missing piece is 'undo' when you find out that a change in the 
> > new version breaks something that you need.  Does anyone know if that 
> > actually works on systems using conary (i.e. can you back up a major 
> > revision)?
> 
> Not feasible for RPM due to pre/post scripts. The rudimentary roll back 
> support in RPM has actually been removed in 4.6. It probably needs the 
> underlying filesytem to support snapshots. Something like btrfs needs to 
> be in place first.

We need rollback if we ever want to be serious about end-user testing.

With non-critical (as in, not needed for yum to run...) packages an "rpm
-e somepackage --nodeps" "yum install somepackage" offers something of a
rollback...

Filesystem rollback may work for full-distribution upgrade rollback, but
won't work so well for per-package rollback. A user should be able to
cherry pick updates to try from "updates-testing", and easily roll back
individual packages, or their entire system to "updates" or even the
"fedora" repo should something go wrong.

Debian can do this. The only reason we can not is because we refuse to.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081110/623c4ec6/attachment.sig>

From jkeating at redhat.com  Mon Nov 10 19:02:00 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 10 Nov 2008 11:02:00 -0800
Subject: Proposal: Rolling Release
In-Reply-To: <1226343130.4020.12.camel@localhost.localdomain>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<49185A3C.7050700@cchtml.com>	<4918658F.8060709@fedoraproject.org>
	<49186F03.5040008@gmail.com>  <491877DC.4010806@fedoraproject.org>
	<1226343130.4020.12.camel@localhost.localdomain>
Message-ID: <1226343720.12953.8.camel@luminos.localdomain>

On Mon, 2008-11-10 at 12:52 -0600, Callum Lerwick wrote:
> Debian can do this. The only reason we can not is because we refuse
> to.

And so far we refuse to be cause we allow free-form scriptlets in rpms.

It would be interesting to see how one would upgrade say mysql major
version and then roll it back all via packaging.  Something that
requires changing the on disk format of your databases and 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/20081110/bab50d6b/attachment.sig>

From limb at jcomserv.net  Mon Nov 10 19:08:00 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Mon, 10 Nov 2008 13:08:00 -0600 (CST)
Subject: Proposal: Rolling Release
In-Reply-To: <20081110184919.GA44008@dspnet.fr.eu.org>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<49185A3C.7050700@cchtml.com> <20081110182458.GE30058@dspnet.fr.eu.org>
	<24efe1db0d551166bc41c2a9969bb74d.squirrel@mail.jcomserv.net>
	<20081110184919.GA44008@dspnet.fr.eu.org>
Message-ID: <40aba04dd4ff35e70d8b001e33ce9fda.squirrel@mail.jcomserv.net>


> On Mon, Nov 10, 2008 at 12:30:45PM -0600, Jon Ciesla wrote:
>>
>> > On Mon, Nov 10, 2008 at 09:58:52AM -0600, Michael Cronenworth wrote:
>> >> It just needs to be turned into a mandatory update tool with
>> PackageKit.
>> >>  Joe Enduser needs to be able to click "Update Me!" and go from
>> Fedora
>> >> 9 to Fedora 10 with a single click.
>> >
>> > Can I update from up-to-date fedora N to fedora N+1 through a command
>> > line ssh connection now?  Or is that still unsupported?
>> >
>> > And if yes, how?  Is it just changing the repository to N+1 and yum
>> > update?
>>
>> http://fedoraproject.org/wiki/SIGs/LiveUpgrade
>
> Niiiiiiiiiice.  Now that's one thing that is going to make my sysadmin
> life nicer.

I've been doing this since F-1, and I have one box that's been done that
way since F-3.   Basically, read the release notes, prepare what you have
to, generally db dumps, etc, and do the above.  With very few exceptions,
it works very well.  Still not "officially supported", though I like
preupgrade, too, even though it's not the same goal at all.

>   OG.
>


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

-d. bowie



From pertusus at free.fr  Mon Nov 10 19:17:53 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 10 Nov 2008 20:17:53 +0100
Subject: what QA gets mailed to the packagers?
In-Reply-To: <20081025110430.GC2608@free.fr>
References: <20081025110430.GC2608@free.fr>
Message-ID: <20081110191753.GK3153@free.fr>

On Sat, Oct 25, 2008 at 01:04:30PM +0200, Patrice Dumas wrote:
> Hello,
> 
> Still trying to bring the wiki up-to-date, I'd like to fix
> https://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModifyWhichPackages

I have hopefully brought it up-to-date, since the nagmails are changing
now and then, I tried to adapt wording to that situation.

--
Pat



From lesmikesell at gmail.com  Mon Nov 10 19:18:19 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 10 Nov 2008 13:18:19 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <1226343720.12953.8.camel@luminos.localdomain>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<49185A3C.7050700@cchtml.com>	<4918658F.8060709@fedoraproject.org>	<49186F03.5040008@gmail.com>
	<491877DC.4010806@fedoraproject.org>	<1226343130.4020.12.camel@localhost.localdomain>
	<1226343720.12953.8.camel@luminos.localdomain>
Message-ID: <491888FB.3000501@gmail.com>

Jesse Keating wrote:
> On Mon, 2008-11-10 at 12:52 -0600, Callum Lerwick wrote:
>> Debian can do this. The only reason we can not is because we refuse
>> to.
> 
> And so far we refuse to be cause we allow free-form scriptlets in rpms.
> 
> It would be interesting to see how one would upgrade say mysql major
> version and then roll it back all via packaging.  Something that
> requires changing the on disk format of your databases and such.

And the answer to that is that sometimes interactive choices need to be 
made during installation/upgrade/downgrade operations.  Or they can't be 
done with a package at all.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From pertusus at free.fr  Mon Nov 10 19:23:09 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 10 Nov 2008 20:23:09 +0100
Subject: PackageMaintainers/Policy/EOL out of date
In-Reply-To: <20081025102343.GB2608@free.fr>
References: <20081025102343.GB2608@free.fr>
Message-ID: <20081110192309.GL3153@free.fr>

Please, could somebody step up?

On Sat, Oct 25, 2008 at 12:23:43PM +0200, Patrice Dumas wrote:
> Hello,
> 
> The page 
> https://fedoraproject.org/wiki/PackageMaintainers/Policy/EOL
> is out of date, pre-merge. I would like to update it, however I cannot
> find an explanation of the current scheedule, there is only something
> about the releases, 
> https://fedoraproject.org/wiki/Releases/Schedule
> I can't find the description of the EOL. Unless I am wrong, F-N+2 is EOL
> one month after the release of F-N, but I don't know exaclty when events
> relevant for packagers happen, like when new branches for packages
> aren't created anymore, or when the builds are stopped for real happen.
> 
> If you give me some information or link to a page explaining the
> EOL schedule, I'll update.
> 
> --
> Pat
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From pertusus at free.fr  Mon Nov 10 19:29:37 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 10 Nov 2008 20:29:37 +0100
Subject: dependencies between {swfdec-mozilla, gnash-plugin} and
	nspluginwrapper
In-Reply-To: <e73de96e0810230641g669b1fb1k4ae70fb2c4c7bb9d@mail.gmail.com>
References: <e73de96e0810230641g669b1fb1k4ae70fb2c4c7bb9d@mail.gmail.com>
Message-ID: <20081110192937.GM3153@free.fr>

On Thu, Oct 23, 2008 at 11:41:46AM -0200, Mart?n Marqu?s wrote:
> Yesterday I started to finish configuring some things that were left
> behind on my new laptop (amd64), and bumpped up with flash support for
> firefox.
> 
> The thing is that swfdec didn't work, and gnash neither.

I have just tested, on rawhide, that when gnash and nspluginwrapper are
installed, gnash is used.

--
Pat



From sundaram at fedoraproject.org  Mon Nov 10 19:31:16 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 11 Nov 2008 01:01:16 +0530
Subject: Proposal: Rolling Release
In-Reply-To: <491888FB.3000501@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<49185A3C.7050700@cchtml.com>	<4918658F.8060709@fedoraproject.org>	<49186F03.5040008@gmail.com>	<491877DC.4010806@fedoraproject.org>	<1226343130.4020.12.camel@localhost.localdomain>	<1226343720.12953.8.camel@luminos.localdomain>
	<491888FB.3000501@gmail.com>
Message-ID: <49188C04.8020203@fedoraproject.org>

Les Mikesell wrote:
> Jesse Keating wrote:
>> On Mon, 2008-11-10 at 12:52 -0600, Callum Lerwick wrote:
>>> Debian can do this. The only reason we can not is because we refuse
>>> to.
>>
>> And so far we refuse to be cause we allow free-form scriptlets in rpms.
>>
>> It would be interesting to see how one would upgrade say mysql major
>> version and then roll it back all via packaging.  Something that
>> requires changing the on disk format of your databases and such.
> 
> And the answer to that is that sometimes interactive choices need to be 
> made during installation/upgrade/downgrade operations.  Or they can't be 
> done with a package at all.

They can't be done then since RPM doesn't support interactive 
installations. It is designed to be completely automatic. If you have to 
ask questions in the middle of a transaction, you lose anyway.

Rahu;



From drago01 at gmail.com  Mon Nov 10 19:32:25 2008
From: drago01 at gmail.com (drago01)
Date: Mon, 10 Nov 2008 20:32:25 +0100
Subject: dependencies between {swfdec-mozilla,
	gnash-plugin} and nspluginwrapper
In-Reply-To: <20081110192937.GM3153@free.fr>
References: <e73de96e0810230641g669b1fb1k4ae70fb2c4c7bb9d@mail.gmail.com>
	<20081110192937.GM3153@free.fr>
Message-ID: <f6ca9fed0811101132q4a3740a5tbbb245b5fd7ed0a6@mail.gmail.com>

On Mon, Nov 10, 2008 at 8:29 PM, Patrice Dumas <pertusus at free.fr> wrote:
> On Thu, Oct 23, 2008 at 11:41:46AM -0200, Mart?n Marqu?s wrote:
>> Yesterday I started to finish configuring some things that were left
>> behind on my new laptop (amd64), and bumpped up with flash support for
>> firefox.
>>
>> The thing is that swfdec didn't work, and gnash neither.
>
> I have just tested, on rawhide, that when gnash and nspluginwrapper are
> installed, gnash is used.

well there is no reason for it not to work when nspluginwrapper is
installed because its the only flash plugin you have (nspluginwrapper
is not a flash plugin), everything else would be a bug.



From pmatilai at laiskiainen.org  Mon Nov 10 19:34:00 2008
From: pmatilai at laiskiainen.org (pmatilai at laiskiainen.org)
Date: Mon, 10 Nov 2008 21:34:00 +0200 (EET)
Subject: Proposal: Rolling Release
In-Reply-To: <1226343130.4020.12.camel@localhost.localdomain>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<49185A3C.7050700@cchtml.com> <4918658F.8060709@fedoraproject.org>
	<49186F03.5040008@gmail.com> <491877DC.4010806@fedoraproject.org>
	<1226343130.4020.12.camel@localhost.localdomain>
Message-ID: <alpine.LFD.2.00.0811102117260.2899@turre.koti.laiskiainen.org>

On Mon, 10 Nov 2008, Callum Lerwick wrote:

> On Mon, 2008-11-10 at 23:35 +0530, Rahul Sundaram wrote:
>>> The real missing piece is 'undo' when you find out that a change in the
>>> new version breaks something that you need.  Does anyone know if that
>>> actually works on systems using conary (i.e. can you back up a major
>>> revision)?
>>
>> Not feasible for RPM due to pre/post scripts. The rudimentary roll back
>> support in RPM has actually been removed in 4.6. It probably needs the
>> underlying filesytem to support snapshots. Something like btrfs needs to
>> be in place first.
>
> We need rollback if we ever want to be serious about end-user testing.
>
> With non-critical (as in, not needed for yum to run...) packages an "rpm
> -e somepackage --nodeps" "yum install somepackage" offers something of a
> rollback...
>
> Filesystem rollback may work for full-distribution upgrade rollback, but
> won't work so well for per-package rollback. A user should be able to
> cherry pick updates to try from "updates-testing", and easily roll back
> individual packages, or their entire system to "updates" or even the
> "fedora" repo should something go wrong.
>
> Debian can do this. The only reason we can not is because we refuse to.

The above use-case (perfectly valid use-case, mind you) is a very very 
limited special case of rollback called "software downgrade". And that rpm 
can handle just as well or badly as dpkg - it all depends on the software 
in question, what its scriptlets do or don't do etc.

The question is, how would the package management toolchain be able to 
differentiate "oops db4-4.7.21-4 from updates-testing crashes with a NULL 
pointer thinko, gimme back db4-4.7.21-3 from stable repo" from "db4 update 
from 4.5 to 4.6 broke things and testing it converted my db to 4.6 format 
so downgrading back to 4.5 wouldn't do any good" and act intelligently in 
both cases? One heuristic would be allowing downgrade between different 
releases of the same version more freely but scriptlets can do damage even 
in release bumps.. thats no solution either.

 	- Panu -



From kevin at scrye.com  Mon Nov 10 19:29:13 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Mon, 10 Nov 2008 12:29:13 -0700
Subject: PackageMaintainers/Policy/EOL out of date
In-Reply-To: <20081110192309.GL3153@free.fr>
References: <20081025102343.GB2608@free.fr>
	<20081110192309.GL3153@free.fr>
Message-ID: <20081110122913.2b368366@ohm.scrye.com>

On Mon, 10 Nov 2008 20:23:09 +0100
pertusus at free.fr (Patrice Dumas) wrote:

> Please, could somebody step up?
> 
> On Sat, Oct 25, 2008 at 12:23:43PM +0200, Patrice Dumas wrote:
> > Hello,
> > 
> > The page 
> > https://fedoraproject.org/wiki/PackageMaintainers/Policy/EOL
> > is out of date, pre-merge. I would like to update it, however I
> > cannot find an explanation of the current scheedule, there is only
> > something about the releases, 
> > https://fedoraproject.org/wiki/Releases/Schedule
> > I can't find the description of the EOL. Unless I am wrong, F-N+2

F-N - 2 ? 

> > is EOL one month after the release of F-N, but I don't know exaclty
> > when events relevant for packagers happen, like when new branches
> > for packages aren't created anymore, or when the builds are stopped
> > for real happen.

New branches are no longer allowed for N-2 when N is released. 
New builds are no longer allowed at N release + 1 month. 

Exceptions can be made if warented, I guess by petitioning FESCo about
it. 

> > If you give me some information or link to a page explaining the
> > EOL schedule, I'll update.

If you could that would be great!

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/20081110/a2f011e4/attachment.sig>

From mdehaan at redhat.com  Mon Nov 10 19:47:09 2008
From: mdehaan at redhat.com (Michael DeHaan)
Date: Mon, 10 Nov 2008 14:47:09 -0500
Subject: (devel) New --comment field
Message-ID: <49188FBD.40901@redhat.com>

Cobbler now has a "--comment" field on all objects.

It works like you would expect:

Cobbler system edit --name=foo --comment="This virtual machine has zork 
installed on it"

(I still have to add this to the webapp, and then after that I'll add 
the "Creation time" and "Edit time" to the "cobbler report" and webapp, 
which will display as user readable dates and will be returned as 
partial-seconds-since-epoch in API calls.  These won't have command line 
options -- they won't even be modifiable by the API directly, but will 
be transparently updated behind the scenes)

--Michael



From lesmikesell at gmail.com  Mon Nov 10 19:50:34 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 10 Nov 2008 13:50:34 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <49188C04.8020203@fedoraproject.org>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<49185A3C.7050700@cchtml.com>	<4918658F.8060709@fedoraproject.org>	<49186F03.5040008@gmail.com>	<491877DC.4010806@fedoraproject.org>	<1226343130.4020.12.camel@localhost.localdomain>	<1226343720.12953.8.camel@luminos.localdomain>	<491888FB.3000501@gmail.com>
	<49188C04.8020203@fedoraproject.org>
Message-ID: <4918908A.8070103@gmail.com>

Rahul Sundaram wrote:
> 
>>> On Mon, 2008-11-10 at 12:52 -0600, Callum Lerwick wrote:
>>>> Debian can do this. The only reason we can not is because we refuse
>>>> to.
>>>
>>> And so far we refuse to be cause we allow free-form scriptlets in rpms.
>>>
>>> It would be interesting to see how one would upgrade say mysql major
>>> version and then roll it back all via packaging.  Something that
>>> requires changing the on disk format of your databases and such.
>>
>> And the answer to that is that sometimes interactive choices need to 
>> be made during installation/upgrade/downgrade operations.  Or they 
>> can't be done with a package at all.
> 
> They can't be done then since RPM doesn't support interactive 
> installations. It is designed to be completely automatic. If you have to 
> ask questions in the middle of a transaction, you lose anyway.

So the RPM design forces you to not use it at all.  Great.  But, that 
brings back the concept of migration.  Is there any interest in that, so 
your upgrade becomes a non-destructive copy that you can test before the 
old copy is gone?  Disk space is cheap these days.

-- 
  Les Mikesell
    lesmikesell at gmail.com



From mdehaan at redhat.com  Mon Nov 10 20:02:58 2008
From: mdehaan at redhat.com (Michael DeHaan)
Date: Mon, 10 Nov 2008 15:02:58 -0500
Subject: (devel) New --comment field
In-Reply-To: <49188FBD.40901@redhat.com>
References: <49188FBD.40901@redhat.com>
Message-ID: <49189372.1050302@redhat.com>

Michael DeHaan wrote:
> Cobbler now has a "--comment" field on all objects.
>
> It works like you would expect:
>
> Cobbler system edit --name=foo --comment="This virtual machine has 
> zork installed on it"
>
> (I still have to add this to the webapp, and then after that I'll add 
> the "Creation time" and "Edit time" to the "cobbler report" and 
> webapp, which will display as user readable dates and will be returned 
> as partial-seconds-since-epoch in API calls.  These won't have command 
> line options -- they won't even be modifiable by the API directly, but 
> will be transparently updated behind the scenes)
>
> --Michael
>
>

Wrong list agian, /very/ sorry.




From sundaram at fedoraproject.org  Mon Nov 10 20:02:31 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 11 Nov 2008 01:32:31 +0530
Subject: Proposal: Rolling Release
In-Reply-To: <4918908A.8070103@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<49185A3C.7050700@cchtml.com>	<4918658F.8060709@fedoraproject.org>	<49186F03.5040008@gmail.com>	<491877DC.4010806@fedoraproject.org>	<1226343130.4020.12.camel@localhost.localdomain>	<1226343720.12953.8.camel@luminos.localdomain>	<491888FB.3000501@gmail.com>	<49188C04.8020203@fedoraproject.org>
	<4918908A.8070103@gmail.com>
Message-ID: <49189357.4040708@fedoraproject.org>

Les Mikesell wrote:

> So the RPM design forces you to not use it at all.  Great. 

Deb or other package management systems are no different here. They are 
all designed to be non-interactive. Debian used to dump questions on a 
terminal for some packages but that is not recommended anymore for 
obvious reasons and everybody is advised to used to use debconf. There 
is only limited magic you can do to workaround incompatibilities of 
certain kinds. Postgres frequently requires a dump and restore.

  But, that
> brings back the concept of migration.  Is there any interest in that, so 
> your upgrade becomes a non-destructive copy that you can test before the 
> old copy is gone?  Disk space is cheap these days.

You have to explain how that will work for a complex dependency set. 
What about say glibc breakage? You are going to need filesystem 
snapshots I suspect.

Btw, disk space is not always cheap. Think: thin clients, embedded 
systems, netbooks like OLPC or eeepc etc.

Rahul



From notting at redhat.com  Mon Nov 10 20:35:34 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 10 Nov 2008 15:35:34 -0500
Subject: Fedora 11 font package changes proposal (renames, splits, etc)
In-Reply-To: <1226339632.17989.28.camel@arekh.okg>
References: <1226228950.21652.95.camel@arekh.okg>
	<20081110171035.GG8850@nostromo.devel.redhat.com>
	<1226339632.17989.28.camel@arekh.okg>
Message-ID: <20081110203534.GC12640@nostromo.devel.redhat.com>

Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> > This sounds like severe overkill. If they want different scripts, why
> > not just adjust their fontconfig configuration? Realistically, I can't
> > think of an example where we'd want to ship dejavu for one script but
> > not another. Do you have one?
> 
> Actually dejavu is a bad example because everyone wants it. I only did
> it because it's a complex and complete package that could stress the
> macros (also because it's my main package).

Then we shouldn't build it as split...

Bill



From pertusus at free.fr  Mon Nov 10 19:14:38 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 10 Nov 2008 20:14:38 +0100
Subject: old release bugs handling
In-Reply-To: <20081017173118.GB2681@free.fr>
References: <20081017173118.GB2681@free.fr>
Message-ID: <20081110191438.GJ3153@free.fr>

Nobody interested?

On Fri, Oct 17, 2008 at 07:31:18PM +0200, Patrice Dumas wrote:
> Hello,
> 
> When looking at the infra after eol issue, Toshio made me aware that 
> nothing special is done for bugzilla in eol branches. Maybe it would 
> be nice to have bugs filled against old branches associated with 
> another product, such that they are easier to triage, and owner 
> doesn't get those bugs automatically? As a disclaimer I know nothing 
> about both the technical issues and the organizational issues involved
> by that proposal. The idea could be along (provided it is technically 
> feasible):
> 
> * when a bug is filled against an old release in the current fedora 
>   product, the product is automatically changed to 'fedora EOL' 
>   (or 'fedora Legacy' if that product is to be reused), which means 
>   that they don't necessarily go to the same mail adress than current
>   releases. Also there is an automatic answer for those bugs, along:
> 
> 'You are reporting a bug against an unsupported fedora release, you 
> are urged to upgrade, and retry with the new release'.
> 
> * the owner of this product is the owner of one of the old releases,
>   for example could be the owner of F7 currently. That way, if this 
>   release is orphaned by the maintainer, he won't get bug reports 
>   for the old branch anymore. I would even suggest mass orphaning such 
>   that the default is that the maintainer doesn't get those bugs.
> 
> 
> Then people interested in triaging bugs for old releases could be 
> subscribed to the adress all the product bugs are forwarded to, 
> such that they can triage the bugs.
> 
> 
> Of course this would make more sense in case the infra was left 
> open for old releases, as there would be people specifically interested 
> in triaging those bugs and also interested in becoming maintainers 
> of old branches, but even if the proposal to keep infra open for old
> branches is rejected --- and I am almost sure that it will be 
> rejected --- it could still be something relevant to do.
> 
> Thoughts?
> 
> 
> 
> PS: tell me if this is better to ask that kind of question on the infra
> list.
> 
> --
> Pat
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From lesmikesell at gmail.com  Mon Nov 10 21:01:19 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 10 Nov 2008 15:01:19 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <49189357.4040708@fedoraproject.org>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<49185A3C.7050700@cchtml.com>	<4918658F.8060709@fedoraproject.org>	<49186F03.5040008@gmail.com>	<491877DC.4010806@fedoraproject.org>	<1226343130.4020.12.camel@localhost.localdomain>	<1226343720.12953.8.camel@luminos.localdomain>	<491888FB.3000501@gmail.com>	<49188C04.8020203@fedoraproject.org>	<4918908A.8070103@gmail.com>
	<49189357.4040708@fedoraproject.org>
Message-ID: <4918A11F.8070500@gmail.com>

Rahul Sundaram wrote:
> 
>> So the RPM design forces you to not use it at all.  Great. 
> 
> Deb or other package management systems are no different here. They are 
> all designed to be non-interactive. Debian used to dump questions on a 
> terminal for some packages but that is not recommended anymore for 
> obvious reasons and everybody is advised to used to use debconf. There 
> is only limited magic you can do to workaround incompatibilities of 
> certain kinds. Postgres frequently requires a dump and restore.

And you may need both old and new versions present while you perform the 
operations an upgrade requires.  So generic package-magic would involve 
being able to install the new version without removing the old so you 
have a chance to do the interactive parts before it is too late.  That 
would be a nice feature to have in general but pretty far from existing 
practice.

>  But, that
>> brings back the concept of migration.  Is there any interest in that, 
>> so your upgrade becomes a non-destructive copy that you can test 
>> before the old copy is gone?  Disk space is cheap these days.
> 
> You have to explain how that will work for a complex dependency set. 
> What about say glibc breakage? You are going to need filesystem 
> snapshots I suspect.

I'd like it to not touch the existing system at all.  One  approach 
would be to migrate to a different machine, which I consider a badly 
needed feature on its own.  Macs have done this for years, using 
firewire target mode on the old system to access it as a disk drive and 
providing automated copy plus update of the existing users, 
applications, and data.  Any technique that permits a backup/restore of 
the old system followed by an upgrade that would also do the fixup for 
potentially different hardware would work, though. Building a 
virtualbox/vmware (etc.) clone should be a transparent variation of 
this, but you need the 'migrate to hardware' tool that doesn't exist.

Another would be to have pre-allocated a spare partition - or add a new 
one, perhaps via USB where you copy the old system, then upgrade, making 
a dual-boot setup so you can go back to an untouched existing system if 
necessary.  In the USB case, you would need a subsequent migration step 
to move the partition over the old system after you were convinced it 
was safe.  I've done alternate-partition installs manually in the past 
but it takes some tweaking, and if you maintain the existing /home, 
there is no way to know which files you need to save/restore between 
versions so that should be automated too.

> Btw, disk space is not always cheap. Think: thin clients, embedded 
> systems, netbooks like OLPC or eeepc etc.

Think USB external, flash or laptop form.  They are great things to have 
around for other purposes too.

-- 
    Les Mikesell
     lesmikesell at gmail.com





From jcm at redhat.com  Mon Nov 10 21:13:31 2008
From: jcm at redhat.com (Jon Masters)
Date: Mon, 10 Nov 2008 16:13:31 -0500
Subject: db-compat
In-Reply-To: <20081110171712.GH8850@nostromo.devel.redhat.com>
References: <1226293343.30170.4.camel@jcmlaptop>
	<20081110171712.GH8850@nostromo.devel.redhat.com>
Message-ID: <1226351611.18109.15.camel@londonpacket.bos.redhat.com>

On Mon, 2008-11-10 at 12:17 -0500, Bill Nottingham wrote:
> Jon Masters (jonathan at jonmasters.org) said: 
> > It would seem we're no longer shipping libdb-4.1.so, whereas we do have
> > 4.2, 4.3, and 4.5 in that db4 compatibility package. I wound up just
> > stealing the binary from an older RPM and copying it in place.
> > 
> > Anyway, software like Xilinx's ISE/EDK would like it back :)
> 
> So, this is software that hasn't been rebuilt since RHEL 3 (or an
> equivalent thereof.) We certainly don't support Fedora releases that
> far back.

What, db-compat, or the SO in question?

Jon.




From notting at redhat.com  Mon Nov 10 21:30:30 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 10 Nov 2008 16:30:30 -0500
Subject: db-compat
In-Reply-To: <1226351611.18109.15.camel@londonpacket.bos.redhat.com>
References: <1226293343.30170.4.camel@jcmlaptop>
	<20081110171712.GH8850@nostromo.devel.redhat.com>
	<1226351611.18109.15.camel@londonpacket.bos.redhat.com>
Message-ID: <20081110213030.GB13633@nostromo.devel.redhat.com>

Jon Masters (jcm at redhat.com) said: 
> > So, this is software that hasn't been rebuilt since RHEL 3 (or an
> > equivalent thereof.) We certainly don't support Fedora releases that
> > far back.
> 
> What, db-compat, or the SO in question?

db-4.1 was last the system DB library in RHEL 3/FC1.

Bill



From notting at redhat.com  Mon Nov 10 21:49:01 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 10 Nov 2008 16:49:01 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <91705d080810311401gdc85e93i1bd182ce56976bb3@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<91705d080810290706h3c7f2a33q5dfb37f7ce55a73e@mail.gmail.com>
	<20081029215123.GL25197@nostromo.devel.redhat.com>
	<91705d080810291533o7a7f3a5dl1cbcbef4fa3498c8@mail.gmail.com>
	<20081030154405.GA12240@nostromo.devel.redhat.com>
	<91705d080810301155q487a968qc91be14ecdc6909d@mail.gmail.com>
	<20081030202920.GB31153@nostromo.devel.redhat.com>
	<91705d080810301410h415f6e4fj6fbf881eada2f69d@mail.gmail.com>
	<20081031202054.GB8150@nostromo.devel.redhat.com>
	<91705d080810311401gdc85e93i1bd182ce56976bb3@mail.gmail.com>
Message-ID: <20081110214901.GA14463@nostromo.devel.redhat.com>

Dan Nicholson (dbn.lists at gmail.com) said: 
> It is certainly getting complex, but the current setup is not robust.
> Even if you take away the "I always want getty on tty1" pref, how do
> you handle the case when the display manager is not gdm? Just have
> nothing running on tty1? Because, init currently will not start a
> getty on tty1 in runlevel 5 in any situation.
> 
> > There's still the issue of what to do with respect to stopping sometihng
> > on a current tty that GDM is using, if there is something there.
> 
> You mean the `telinit 3' from runlevel 5 case? I'm not following exactly.

Further testing with this is giving me some bizarre errors and hangs
relating to VT switching that don't happen with this patchset backed
out. Unless I can track those down, I can't really recommend using
it.

Bill



From ville.skytta at iki.fi  Mon Nov 10 21:51:47 2008
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Mon, 10 Nov 2008 23:51:47 +0200
Subject: Removing "minimal buildroot" dependencies from rpmdevtools
Message-ID: <200811102351.47926.ville.skytta@iki.fi>

Hi,

I'm planning to drop the "minimal buildroot" dependencies from rpmdevtools, 
leaving in only dependencies that are required for the utils in the package 
to work.

There are two main reasons for this, in no particular order:

1) Some utilities in the package are useful for people and cases that have 
nothing to do with rpm packaging or development, and rpmdevtools has been 
made a dependency of various "normal end user" packages because of this.  
Pulling in the whole minimal build root is not welcome in these cases.

2) rpmdevtools is not really the most natural place for pulling in a minimal 
build root, it's not really a Fedora specific package.  Yes, we want people 
to use mock, but reality is that many prefer to pull the minimal build root 
setup into their normal system layout quickly for one reason or another, so 
this possibility should IMO be preserved somewhere else when/if this 
dependency set gets removed from rpmdevtools.  Maybe the fedora-packager 
package or a subpackage of it?

Thoughts?



From nicolas.mailhot at laposte.net  Mon Nov 10 22:09:08 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 10 Nov 2008 23:09:08 +0100
Subject: Fedora 11 font package changes proposal (renames, splits, etc)
In-Reply-To: <1226339752.17989.29.camel@arekh.okg>
References: <1226339752.17989.29.camel@arekh.okg>
Message-ID: <1226354948.26647.4.camel@arekh.okg>

After a long irc discussion with Bill Nottingham, I've reworked the
package splitting rule in:

? When packaging an upstream font archive that contains different font
families (different font names in GUI font dropdowns), one must split
each font family in a separate subpackage. Each subpackage must include
every upstream-provided font face (bold, italic, condensed, oblique?) of
the corresponding font family. 

As a special exception a packager is allowed to optionally keep
sans/serif/mono latin families of the same name together.

When upstream releases separate font archives, just create separate
packages. ?

http://fedoraproject.org/wiki/Fonts_SIG_Fedora_11_packaging_changes#Split_big_font_packages_on_font_family_lines

Practically, that would make splitting (or not) Bitstream Vera,
Liberation and GNU FreeFont a packager per packager decision.

Regards,

-- 
Nicolas Mailhot
That only makes 3 packagers to bribe!
-------------- 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/20081110/4c00db90/attachment.sig>

From wolfy at nobugconsulting.ro  Mon Nov 10 22:23:09 2008
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Tue, 11 Nov 2008 00:23:09 +0200
Subject: db-compat
In-Reply-To: <20081110213030.GB13633@nostromo.devel.redhat.com>
References: <1226293343.30170.4.camel@jcmlaptop>	<20081110171712.GH8850@nostromo.devel.redhat.com>	<1226351611.18109.15.camel@londonpacket.bos.redhat.com>
	<20081110213030.GB13633@nostromo.devel.redhat.com>
Message-ID: <4918B44D.4050904@nobugconsulting.ro>

On 11/10/2008 11:30 PM, Bill Nottingham wrote:
> Jon Masters (jcm at redhat.com) said: 
>   
>>> So, this is software that hasn't been rebuilt since RHEL 3 (or an
>>> equivalent thereof.) We certainly don't support Fedora releases that
>>> far back.
>>>       
>> What, db-compat, or the SO in question?
>>     
>
> db-4.1 was last the system DB library in RHEL 3/FC1.
>   
For ther record: compat-db-4.1.25-9.i386.rpm is available in RHEL 4.  
and it works OK in RHEL 5 (I have a commercial EDA tool which claims 
RHEL5 compatibility but does not work without this lib)



From opensource at till.name  Mon Nov 10 22:20:55 2008
From: opensource at till.name (Till Maas)
Date: Mon, 10 Nov 2008 23:20:55 +0100
Subject: Removing "minimal buildroot" dependencies from rpmdevtools
In-Reply-To: <200811102351.47926.ville.skytta@iki.fi>
References: <200811102351.47926.ville.skytta@iki.fi>
Message-ID: <200811102321.08688.opensource@till.name>

On Mon November 10 2008, Ville Skytt? wrote:

> else when/if this dependency set gets removed from rpmdevtools.  Maybe the
> fedora-packager package or a subpackage of it?
>
> Thoughts?

I like this and I want to suggest to use comps to collect the dependencies 
that are considered useful for Fedora maintainers. But I am not sure, whether 
this can be done, because I remember some restrictions that a package can 
only be in one comps group.

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/20081110/77300b28/attachment.sig>

From sundaram at fedoraproject.org  Mon Nov 10 22:30:40 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 11 Nov 2008 04:00:40 +0530
Subject: Proposal: Rolling Release
In-Reply-To: <4918A11F.8070500@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<49185A3C.7050700@cchtml.com>	<4918658F.8060709@fedoraproject.org>	<49186F03.5040008@gmail.com>	<491877DC.4010806@fedoraproject.org>	<1226343130.4020.12.camel@localhost.localdomain>	<1226343720.12953.8.camel@luminos.localdomain>	<491888FB.3000501@gmail.com>	<49188C04.8020203@fedoraproject.org>	<4918908A.8070103@gmail.com>	<49189357.4040708@fedoraproject.org>
	<4918A11F.8070500@gmail.com>
Message-ID: <4918B610.1080905@fedoraproject.org>

Les Mikesell wrote:

> And you may need both old and new versions present while you perform the 
> operations an upgrade requires.  So generic package-magic would involve 
> being able to install the new version without removing the old so you 
> have a chance to do the interactive parts before it is too late.

Again, this is something upstream project should do. GTK and gstreamer 
for example does make this easy.

http://www106.pair.com/rhp/parallel.html

Working around this at the packaging level is always going to require 
elaborate hacks. OpenSUSE did this for shipping KDE 3 and KDE 4 in 
parallel but other distributions refused.

> Think USB external, flash or laptop form.  They are great things to have 
> around for other purposes too.

External USB's are not a answer in embedded systems. You cannot rely on 
external disk storage for base os functionality.

Rahul



From jkeating at redhat.com  Mon Nov 10 22:31:41 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 10 Nov 2008 14:31:41 -0800
Subject: Removing "minimal buildroot" dependencies from rpmdevtools
In-Reply-To: <200811102351.47926.ville.skytta@iki.fi>
References: <200811102351.47926.ville.skytta@iki.fi>
Message-ID: <1226356301.12953.12.camel@luminos.localdomain>

On Mon, 2008-11-10 at 23:51 +0200, Ville Skytt? wrote:
> so 
> this possibility should IMO be preserved somewhere else when/if this 
> dependency set gets removed from rpmdevtools.  Maybe the fedora-packager 
> package or a subpackage of it?

groupinstall buildsys-build  It's already tracked in comps.

-- 
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/20081110/9fa13d79/attachment.sig>

From jkeating at redhat.com  Mon Nov 10 22:32:25 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 10 Nov 2008 14:32:25 -0800
Subject: Removing "minimal buildroot" dependencies from rpmdevtools
In-Reply-To: <200811102321.08688.opensource@till.name>
References: <200811102351.47926.ville.skytta@iki.fi>
	<200811102321.08688.opensource@till.name>
Message-ID: <1226356346.12953.13.camel@luminos.localdomain>

On Mon, 2008-11-10 at 23:20 +0100, Till Maas wrote:
> 
> I like this and I want to suggest to use comps to collect the dependencies 
> that are considered useful for Fedora maintainers. But I am not sure, whether 
> this can be done, because I remember some restrictions that a package can 
> only be in one comps group.

There is the fedora-packager group, as well as the buildsys-build group.
One gives you tools and utilities useful to packaging for Fedora, the
other gives you the minimal buildroot contents, what mock has been using
for a few releases now.

-- 
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/20081110/9c63f7bb/attachment.sig>

From dbn.lists at gmail.com  Mon Nov 10 22:40:50 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Mon, 10 Nov 2008 14:40:50 -0800
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081110214901.GA14463@nostromo.devel.redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029215123.GL25197@nostromo.devel.redhat.com>
	<91705d080810291533o7a7f3a5dl1cbcbef4fa3498c8@mail.gmail.com>
	<20081030154405.GA12240@nostromo.devel.redhat.com>
	<91705d080810301155q487a968qc91be14ecdc6909d@mail.gmail.com>
	<20081030202920.GB31153@nostromo.devel.redhat.com>
	<91705d080810301410h415f6e4fj6fbf881eada2f69d@mail.gmail.com>
	<20081031202054.GB8150@nostromo.devel.redhat.com>
	<91705d080810311401gdc85e93i1bd182ce56976bb3@mail.gmail.com>
	<20081110214901.GA14463@nostromo.devel.redhat.com>
Message-ID: <91705d080811101440t9c5e80ai7c895835e76eb625@mail.gmail.com>

On Mon, Nov 10, 2008 at 1:49 PM, Bill Nottingham <notting at redhat.com> wrote:
> Dan Nicholson (dbn.lists at gmail.com) said:
>> It is certainly getting complex, but the current setup is not robust.
>> Even if you take away the "I always want getty on tty1" pref, how do
>> you handle the case when the display manager is not gdm? Just have
>> nothing running on tty1? Because, init currently will not start a
>> getty on tty1 in runlevel 5 in any situation.
>>
>> > There's still the issue of what to do with respect to stopping sometihng
>> > on a current tty that GDM is using, if there is something there.
>>
>> You mean the `telinit 3' from runlevel 5 case? I'm not following exactly.
>
> Further testing with this is giving me some bizarre errors and hangs
> relating to VT switching that don't happen with this patchset backed
> out. Unless I can track those down, I can't really recommend using
> it.

Without doing anything from event.d, there's nothing on tty1 for the
`telinit 5' from runlevel 3 case, right? I don't want you to use a
broken patch, but I do think the current behavior is wrong.

1. plymouth writes /var/spool/gdm/force-display-on-active-vt even
though it has no notion of the initialization environment or display
manager.The only advantage of doing this in plymouth is that you can
be fairly certain it's only happening at boot.

2. Since there is no way for a getty to start on tty1 in runlevel 5,
it will have nothing running on it in either the case of `telinit 5'
or a gdm restart.

IMO, upstart/event.d is the only place where you can collect enough
details to do this correctly, even if you're not considering the "I
want X on tty7" pref (personally, I don't care where X starts). So,
I'd be willing to help you work on whatever solution you think is
appropriate, but I hope you don't just stick with the current
situation.

An alternative to signaling via initctl would be to add back the
"start on started prefdm" to event.d/tty1 and duplicate the
runlevel/display logic from event.d/prefdm. Uglier, but it might work
more reliably since I didn't really test initctl much.

--
Dan



From green at redhat.com  Mon Nov 10 22:45:06 2008
From: green at redhat.com (Anthony Green)
Date: Mon, 10 Nov 2008 14:45:06 -0800
Subject: Orphaning jakarta-commons-cli
Message-ID: <4918B972.4040606@redhat.com>

I plan on orphaning jakarta-commons-cli.  This package is still required 
by checkstyle and others, but I have no interest in maintaining it. 

This old bugzilla.....
https://bugzilla.redhat.com/show_bug.cgi?id=453018
...tells me there's a new version.  I have not managed to make time to 
upgrade the package, so I'm hoping somebody with more interest will make 
the effort.  Contact me if you are willing to take this package over.

Thanks!

Anthony Green



From tim at niemueller.de  Mon Nov 10 22:48:47 2008
From: tim at niemueller.de (Tim Niemueller)
Date: Mon, 10 Nov 2008 23:48:47 +0100
Subject: dlopen()/festival problem
In-Reply-To: <20081110152454.GA9380@host0.dyn.jankratochvil.net>
References: <49183552.1010302@niemueller.de>
	<20081110152454.GA9380@host0.dyn.jankratochvil.net>
Message-ID: <4918BA4F.7000803@niemueller.de>


> As a temporary workaround you may use dlopen() flag RTLD_DEEPBIND.
> BTW it is also more effective to use RTLD_LAZY than RTLD_NOW.

Thanks a lot Jan, you are my dlopen() hero! That fixed the problem
indeed and everything seems to work fine! Awesome!

	Tim

-- 
    Tim Niemueller <tim at niemueller.de>      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)



From lesmikesell at gmail.com  Mon Nov 10 23:13:48 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 10 Nov 2008 17:13:48 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <4918B610.1080905@fedoraproject.org>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<49185A3C.7050700@cchtml.com>	<4918658F.8060709@fedoraproject.org>	<49186F03.5040008@gmail.com>	<491877DC.4010806@fedoraproject.org>	<1226343130.4020.12.camel@localhost.localdomain>	<1226343720.12953.8.camel@luminos.localdomain>	<491888FB.3000501@gmail.com>	<49188C04.8020203@fedoraproject.org>	<4918908A.8070103@gmail.com>	<49189357.4040708@fedoraproject.org>	<4918A11F.8070500@gmail.com>
	<4918B610.1080905@fedoraproject.org>
Message-ID: <4918C02C.7030907@gmail.com>

Rahul Sundaram wrote:
> 
>> And you may need both old and new versions present while you perform 
>> the operations an upgrade requires.  So generic package-magic would 
>> involve being able to install the new version without removing the old 
>> so you have a chance to do the interactive parts before it is too late.
> 
> Again, this is something upstream project should do. GTK and gstreamer 
> for example does make this easy.
> 
> http://www106.pair.com/rhp/parallel.html
> 
> Working around this at the packaging level is always going to require 
> elaborate hacks. OpenSUSE did this for shipping KDE 3 and KDE 4 in 
> parallel but other distributions refused.

I'm not sure I understand the logic of making upstream deal with the 
problem that RPM's design introduces.  There's rarely an issue if you 
want to do parallel version installs out of an upstream source - and I'd 
guess the developers _always_ do that for anything they rely on.

>> Think USB external, flash or laptop form.  They are great things to 
>> have around for other purposes too.
> 
> External USB's are not a answer in embedded systems. You cannot rely on 
> external disk storage for base os functionality.

OK, so there are tradeoffs.  If you are building embedded systems you 
probably need a spare one to test on. You really only need the backout 
capability until someone has thoroughly tested the replacement in the 
environment where it needs to run.  Or add a micro-sd slot so you can 
throw in an extra 16 gigs in an itty-bitty package when you need it - 
even my phone can do that...

As a minimal step you could add the capability of clonezilla to the 
install - that is, offer to save a compressed image backup somewhere 
before starting in a form that can be restored without a lot of work. 
That's not quite as nice as keeping old/new filesytems online so work in 
progress could be accessed/recovered from either version, but better 
than nothing.

-- 
   Les Mikesell
    lesmikesell at gmail.com




From petersen at redhat.com  Mon Nov 10 23:58:02 2008
From: petersen at redhat.com (Jens Petersen)
Date: Mon, 10 Nov 2008 18:58:02 -0500 (EST)
Subject: [LONG] The fonts SIG irregular status report
In-Reply-To: <1225055984.5093.1.camel@arekh.okg>
Message-ID: <606741161.1554531226361482904.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

> Actually we have 57 since Behdad requested FersiWeb fonts and no one

I should not be that hard really to generate a script to generate a skeleton spec file for any given font .

I know some packaging people frown on automated packaging but this might help lower the barrier to font packaging for which creating rpm's is really quite easy compared to general packaging.  Such spec files would still need to go through being tweaked and polished during review of course but it would make it easier for people to get started I think.

Perhaps it is something we (Fonts SIG) should consider working on?

Jens



From bojan at rexursive.com  Tue Nov 11 01:13:57 2008
From: bojan at rexursive.com (Bojan Smojver)
Date: Tue, 11 Nov 2008 01:13:57 +0000 (UTC)
Subject: Proposal: Rolling Release
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
Message-ID: <loom.20081111T010408-920@post.gmane.org>

Eric Springer <erikina <at> gmail.com> writes:

> So what I propose is that Fedora goes to a rolling release cycle.

Fedora is these days more than a collection of applications. Each release is
supposed to bring better integration of everything shipped within the release.
So, when you say:

> New features/software/functionality would be easily tested by the masses
without needing to upgrade the entire distribution.

I'm not so sure about the "easily" bit.

Let's say disconnected non-local authentication got addressed by various
components. How are you going to test this without pulling in the whole new
distro if something in say glibc got changed to accommodate it? Very hard to do
and not worth the trouble of risking massive breakage this can cause.

It's a pipe dream, IMHO.

--
Bojan





From pemboa at gmail.com  Tue Nov 11 03:31:11 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Mon, 10 Nov 2008 21:31:11 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
Message-ID: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>

On Mon, Nov 10, 2008 at 7:42 AM, Eric Springer <erikina at gmail.com> wrote:
> Fedora has always lead the progress of FOSS by closely following
> upstream and making non-trivial contributions. I see this is a great
> strength, and like many other people it's my primary reason for using
> it. But it's not without trade-offs, such as giving Fedora a
> perception of being 'beta' software and balancing new software without
> burning the large user base is not easy either.

Yes. That is a fact. There is almost no good way to tell people who
don't like this "get used to it". Someone has to do this. Someone has
to be the "custodian" and it seems like we (Fedora) are it. And I feel
that we should be proud of our role on the frontlines.

I think that as long as we do not burn these users away from Linux as
a whole, this is okay.

> This hit home today, after being impressed with the work you guys have
> done with plymouth, I did a quick Google search[1] to find out a
> little more. The first result is a "Ubuntu brainstorm" page[2] about
> implementing it in their own distribution and the second comment is "I
> support the idea but I do think that it should only be considered
> after Fedora has done all the dirty work of getting it to work".

I feel like this is something for Fedora to be proud of. It is a
community, and different parts have their niches, this seems to be
Fedora's own, and we should be proud of it.

> This
> is no way intended as a criticism of a Ubuntu, but it's a realization
> that distributions like Ubuntu are able to offer a better user
> experience by using stable software on a longer support cycle.

And this is good thing. Ubuntu has not shown themselves capable of
doing anything else but this, so let the, have that. If anything, we
need an easier migration path between Fedora and Ubuntu.

> So what I propose ...

I read through everything, but just wanted to shorten the email a bit..
This all sounds good, but it seems entirely like a good idea, which
needs a lot of resources and additional man power to do. Without the
added man power, we would likely be taking away from what makes Fedora
Fedora as is today.

We are Fedora, do we need to be Ubuntu as well?

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From lesmikesell at gmail.com  Tue Nov 11 04:17:05 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 10 Nov 2008 22:17:05 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
Message-ID: <49190741.6090902@gmail.com>

Arthur Pemberton wrote:
> > 
>> This
>> is no way intended as a criticism of a Ubuntu, but it's a realization
>> that distributions like Ubuntu are able to offer a better user
>> experience by using stable software on a longer support cycle.
> 
> And this is good thing. Ubuntu has not shown themselves capable of
> doing anything else but this, so let the, have that.

Beg your pardon?  How many years has fedora policy forced a horribly 
fractured 3rd party repository situation - and not had a working java at 
  all while Ubuntu's approach was much more sensible?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From pemboa at gmail.com  Tue Nov 11 04:25:08 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Mon, 10 Nov 2008 22:25:08 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <49190741.6090902@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>
Message-ID: <16de708d0811102025x7a1dfba8t8e0e04ee78e5d2bd@mail.gmail.com>

On Mon, Nov 10, 2008 at 10:17 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Arthur Pemberton wrote:
>>
>> >
>>>
>>> This
>>> is no way intended as a criticism of a Ubuntu, but it's a realization
>>> that distributions like Ubuntu are able to offer a better user
>>> experience by using stable software on a longer support cycle.
>>
>> And this is good thing. Ubuntu has not shown themselves capable of
>> doing anything else but this, so let the, have that.
>
> Beg your pardon?  How many years has fedora policy forced a horribly
> fractured 3rd party repository situation - and not had a working java at
>  all while Ubuntu's approach was much more sensible?

Fedora has a policy which they stuck to. A policy which many of us agree with.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From lesmikesell at gmail.com  Tue Nov 11 04:37:28 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 10 Nov 2008 22:37:28 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <16de708d0811102025x7a1dfba8t8e0e04ee78e5d2bd@mail.gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>	<49190741.6090902@gmail.com>
	<16de708d0811102025x7a1dfba8t8e0e04ee78e5d2bd@mail.gmail.com>
Message-ID: <49190C08.5030800@gmail.com>

Arthur Pemberton wrote:
> On Mon, Nov 10, 2008 at 10:17 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
>> Arthur Pemberton wrote:
>>>>
>>>> This
>>>> is no way intended as a criticism of a Ubuntu, but it's a realization
>>>> that distributions like Ubuntu are able to offer a better user
>>>> experience by using stable software on a longer support cycle.
>>> And this is good thing. Ubuntu has not shown themselves capable of
>>> doing anything else but this, so let the, have that.
>> Beg your pardon?  How many years has fedora policy forced a horribly
>> fractured 3rd party repository situation - and not had a working java at
>>  all while Ubuntu's approach was much more sensible?
> 
> Fedora has a policy which they stuck to. A policy which many of us agree with.

Then I guess I shouldn't be surprised at your lack of concern about 
having a usable product on other fronts as well.

-- 
    Les Mikesell
     lesmikesell at gmail.com





From paul at xelerance.com  Tue Nov 11 04:44:48 2008
From: paul at xelerance.com (Paul Wouters)
Date: Mon, 10 Nov 2008 23:44:48 -0500 (EST)
Subject: Pidgin (was Re: FESCo Meeting Summary for 2008-11-05)
In-Reply-To: <1226163037.5115.121.camel@sputnik.gravel>
References: <1226016932.5758.3.camel@kennedy>
	<49148BDC.7020702@fedoraproject.org>
	<alpine.LFD.1.10.0811071836480.20989@newtla.xelerance.com> 
	<aed8ecaa0811071756l3731d218g6a55eecdddf36224@mail.gmail.com> 
	<alpine.LFD.1.10.0811072110410.20989@newtla.xelerance.com>
	<1226163037.5115.121.camel@sputnik.gravel>
Message-ID: <Pine.LNX.4.64.0811102329260.30001@newtla.xelerance.com>

On Sat, 8 Nov 2008, Stu Tomlinson wrote:

> > I've CC:ed the fedora list, though you gave me a private reply, because I
> > thought the large list of bugs might be useful to someone. Hope that's okay.
> 
> Fine, but I think bugzilla is a better place for bugs to be reported.

Did you mean fedora bugzilla  or a pidgin one?

> > - It is the 2nd largest memory consuming application running (after firefox)
> >    using up 10% of my total memory:
> >     6698 paul      20   0  843m  96m  15m S  0.0  9.6  16:43.17 pidgin
> >    And I am not a super consumer, only 25 friends and 5 irc channels online now.
> 
> That's certainly unacceptable. There have been some reports of high
> memory utilization but I have been unable to reproduce such high numbers
> or track down any significant leaks recently. It is possible this is
> caused by 3rd party plugins, I'd ask you to try disabling OTR to see if
> it improves things but I suspect you don't want to do that :) What other
> plugins do you use?

Whatever comes with a stock install, and otr. Is there anyway pidgin can track
memory usage of its modules?

> > - It is prone to crashes and freezes (once every couple of days)
> 
> Have you reported bugs with backtraces for these?

No, I will see about getting pidgin to core dump and get backtraces for you.

> > - Somewhere it lost "reconnect all accounts", and I need to click reconnect per
> >    account.
> 
> This should not be necessary, as accounts should automatically reconnect
> without user intervention, unless they disconnected for reasons Pidgin
> determines are not automatically resolvable (such as incorrect
> password). What sort of disconnection results in the accounts being in
> this state?

I don't know. At times it just appears at the bottom of the buddy list window.

> > - Somewhere it lost the ability to be clever and allow typing when the 'focus'
> >    was on the receiving part of a conversation window. Now that typing is lost
> >    until you click on the small input box.
> 
> I can't reproduce that here.

I just tried to do it again, and could not reprpduce it either. I'll keep track
of it and see if I run into it again.

[workspaces]

> That is indeed annoying - unfortunately it is not something that changed
> in Pidgin, but something that changed in the DE or WM or something else.
> I'll try to dig into what it is and see if we can work around it in
> Pidgin.

Thanks!

> > - Leaves a mess in /tmp/
> 
> What sort of mess? I am not aware of anything Pidgin puts in /tmp - Gaim
> used to a long time ago before we switched to using DBUS for remote
> control.

Seems related to getting notifications about new mail on MSN accounts,
for example /tmp/purpleL3Q6HU contains:
temp files contain:

<html>
<head>
<noscript>
<meta http-equiv="Refresh" content="0; url=http://www.hotmail.com">
</noscript>
</head>

<body onload="document.pform.submit(); ">
<form name="pform" action="https://login.live.com/ppsecure/md5auth.srf?lc=1033" 
method="POST">

<input type="hidden" name="mode" value="ttl">
<input type="hidden" name="login" value="letoams at hotmail.com">
<input type="hidden" name="username" value="letoams at hotmail.com">

[...]

> > - Combined user accounts lead to strange things due to pidgin seemingly picking
> >    randomly whch user account to use, which causes problems with OTR.
> 
> Pidgin picks the most 'available' buddy within a contact to send an IM,
> if buddies are determined to be equally available, the 1st one listed in
> the expanded contact is used. Drag and drop can be used to re-arrange
> them.

That would lead to a lot of ping-ponging between accounts, if one person is
talking on two different protocols at once with two people.....
It is definately not ideal OTR. Not only because of the crypto, but also because
the Opportunistic Encryption reply cannot be "exempted" from the user input,
leading to accounts which are actually idle (and perhaps on a different physical
location) to appear as not-idle.

> > - The file transfer function is completely unreliable and often fails silently,
> >    eg the other end does not even see you're trying to send them a file.
> 
> File transfer functionality varies by protocol, and also depends on what
> client the other end is using. I agree it is not perfect. Can you be
> more specific about what protocol(s) you see this on?

That's hard to say, as I don't always know which account pidgin has chosen
while talking to someone. Most of my buddies have multiple protocols, so these
are all grouped by me in the buddy list.

> > - Buddylist window icon at the bottom turns blue ("attention") grabbing when
> >    some event has fixed itself, leaving me to wonder what requires my attention.
> 
> This sounds like a bug - did you file a bug?

No. I do try to file bugs regularly for things (and with my own software, try to
respond to them quickly), but I don't always have the time to do so.

> > - When i have more tabs open then fit in the window, and I'm at the right most
> >    tab, and I got a new mesage in a tab that's scrolled off screen at the left,
> >    I can only go there by going through the tabs, causing them to lose the 'unread'
> >    state. 
> 
> You can right click on any tab to see a list of all tabs and jump direct
> to the one you want.

Okay. I didn't know about that one.

> > - Once every couple of months, some accounts turns to "unvisible" (might be an
> >    MSN/AIM protocol thing, not something pidgin can help)
> 
> I haven't heard of this happening - did you file a bug?

See above. It's vague and more likely to be a MSN interop issue when they change
something. I wouldn't be able to do more then file a very vague bug report.

> > - irc handling of nicknames when briefly bouncing is bad. You'll fight with your
> >    own old nick, and with freenode you then lose the ability to privmsg.
> >    (not sure if that is fixiable in a client, not really pidgin's fault probably)
> 
> There is a plugin in the purple plugin pack called 'IRC Helper' that can
> manage ghosting of nicks and authenticating to Nickserv
> (yum install purple-plugin_pack) 

Thanks, I just installed it.

Paul



From pemboa at gmail.com  Tue Nov 11 04:56:34 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Mon, 10 Nov 2008 22:56:34 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <49190C08.5030800@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>
	<16de708d0811102025x7a1dfba8t8e0e04ee78e5d2bd@mail.gmail.com>
	<49190C08.5030800@gmail.com>
Message-ID: <16de708d0811102056y3101ef63l70469c387c236c38@mail.gmail.com>

On Mon, Nov 10, 2008 at 10:37 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Arthur Pemberton wrote:
>>
>> On Mon, Nov 10, 2008 at 10:17 PM, Les Mikesell <lesmikesell at gmail.com>
>> wrote:
>>>
>>> Arthur Pemberton wrote:
>>>>>
>>>>> This
>>>>> is no way intended as a criticism of a Ubuntu, but it's a realization
>>>>> that distributions like Ubuntu are able to offer a better user
>>>>> experience by using stable software on a longer support cycle.
>>>>
>>>> And this is good thing. Ubuntu has not shown themselves capable of
>>>> doing anything else but this, so let the, have that.
>>>
>>> Beg your pardon?  How many years has fedora policy forced a horribly
>>> fractured 3rd party repository situation - and not had a working java at
>>>  all while Ubuntu's approach was much more sensible?
>>
>> Fedora has a policy which they stuck to. A policy which many of us agree
>> with.
>
> Then I guess I shouldn't be surprised at your lack of concern about having a
> usable product on other fronts as well.


I have a very usable product thank you very much. And this seems
fairly offtopic for this thread.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From jonathan at jonmasters.org  Tue Nov 11 05:16:14 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Tue, 11 Nov 2008 00:16:14 -0500
Subject: db-compat
In-Reply-To: <4918B44D.4050904@nobugconsulting.ro>
References: <1226293343.30170.4.camel@jcmlaptop>
	<20081110171712.GH8850@nostromo.devel.redhat.com>
	<1226351611.18109.15.camel@londonpacket.bos.redhat.com>
	<20081110213030.GB13633@nostromo.devel.redhat.com>
	<4918B44D.4050904@nobugconsulting.ro>
Message-ID: <1226380574.23813.5.camel@perihelion.int.jonmasters.org>

On Tue, 2008-11-11 at 00:23 +0200, Manuel Wolfshant wrote:
> On 11/10/2008 11:30 PM, Bill Nottingham wrote:
> > Jon Masters (jcm at redhat.com) said: 
> >   
> >>> So, this is software that hasn't been rebuilt since RHEL 3 (or an
> >>> equivalent thereof.) We certainly don't support Fedora releases that
> >>> far back.
> >>>       
> >> What, db-compat, or the SO in question?
> >>     
> >
> > db-4.1 was last the system DB library in RHEL 3/FC1.

What's the point of a "compat" library if not to support software built
for such systems? We might argue that we only care about F8/F9 and so
start removing other "old" compat libraries, but that's hardly useful.

> For ther record: compat-db-4.1.25-9.i386.rpm is available in RHEL 4.  
> and it works OK in RHEL 5 (I have a commercial EDA tool which claims 
> RHEL5 compatibility but does not work without this lib)

Indeed. Xilinx claim their tools work on "Red Hat Enterprise
Linux" (which in reality means RHEL4 in this case) but they work fine on
Fedora[0], except for this single library. I just think this is a nice
re-affirmation of the point of compatibility libraries. Once I borrowed
the binary from an older db-compat, place and route works just fine.

Jon.

[0] With the caveat that their setup scripts are some of the worst I've
ever seen. Not handling spaces in automounted CD names results in a need
to copy the CD content/remount, which is so 1970s.




From mschwendt at gmail.com  Tue Nov 11 08:07:21 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 11 Nov 2008 09:07:21 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <49190741.6090902@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>
Message-ID: <20081111090721.928d792a.mschwendt@gmail.com>

On Mon, 10 Nov 2008 22:17:05 -0600, Les Mikesell wrote:

> Beg your pardon?  How many years has fedora policy forced a horribly 
> fractured 3rd party repository situation

Which policy is that?



From erikina at gmail.com  Tue Nov 11 08:37:54 2008
From: erikina at gmail.com (Eric Springer)
Date: Tue, 11 Nov 2008 18:37:54 +1000
Subject: Proposal: Rolling Release
In-Reply-To: <1226343720.12953.8.camel@luminos.localdomain>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<49185A3C.7050700@cchtml.com> <4918658F.8060709@fedoraproject.org>
	<49186F03.5040008@gmail.com> <491877DC.4010806@fedoraproject.org>
	<1226343130.4020.12.camel@localhost.localdomain>
	<1226343720.12953.8.camel@luminos.localdomain>
Message-ID: <ce9c609e0811110037p54087c36wf306befec42cb07d@mail.gmail.com>

2008/11/11 Jesse Keating <jkeating at redhat.com>:
>
> And so far we refuse to be cause we allow free-form scriptlets in rpms.
>
> It would be interesting to see how one would upgrade say mysql major
> version and then roll it back all via packaging.  Something that
> requires changing the on disk format of your databases and such.

Such packages could be marked and the burden transfered to the user.
The user could be warned that a downgrade will technically be an
uninstall and reinstall at a lower version.



From nicolas.mailhot at laposte.net  Tue Nov 11 09:09:24 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 11 Nov 2008 10:09:24 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <4918C02C.7030907@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<49185A3C.7050700@cchtml.com>	<4918658F.8060709@fedoraproject.org>
	<49186F03.5040008@gmail.com>	<491877DC.4010806@fedoraproject.org>
	<1226343130.4020.12.camel@localhost.localdomain>
	<1226343720.12953.8.camel@luminos.localdomain>	<491888FB.3000501@gmail.com>
	<49188C04.8020203@fedoraproject.org>	<4918908A.8070103@gmail.com>
	<49189357.4040708@fedoraproject.org>	<4918A11F.8070500@gmail.com>
	<4918B610.1080905@fedoraproject.org>  <4918C02C.7030907@gmail.com>
Message-ID: <1226394564.26647.22.camel@arekh.okg>

Le lundi 10 novembre 2008 ? 17:13 -0600, Les Mikesell a ?crit :

> I'm not sure I understand the logic of making upstream deal with the 
> problem that RPM's design introduces.  There's rarely an issue if you 
> want to do parallel version installs out of an upstream source - and I'd 
> guess the developers _always_ do that for anything they rely on.

Developpers typically re-create configuration files and data files when
they do parallel installs. Thus they do not have to deal with
config/data format conversion and rollback. Which is the main problem in
doing rpm rollbacks, because unlike on dev stations, we can not afford
to lose of duplicate user data.

-- 
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/20081111/9d4c1f94/attachment.sig>

From nicolas.mailhot at laposte.net  Tue Nov 11 09:02:52 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 11 Nov 2008 10:02:52 +0100
Subject: [LONG] The fonts SIG irregular status report
In-Reply-To: <606741161.1554531226361482904.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
References: <606741161.1554531226361482904.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <1226394172.26647.19.camel@arekh.okg>

Le lundi 10 novembre 2008 ? 18:58 -0500, Jens Petersen a ?crit :
> > Actually we have 57 since Behdad requested FersiWeb fonts and no one
> 
> I should not be that hard really to generate a script to generate a
> skeleton spec file for any given font .
> 
> I know some packaging people frown on automated packaging but this
> might help lower the barrier to font packaging for which creating
> rpm's is really quite easy compared to general packaging.  Such spec
> files would still need to go through being tweaked and polished during
> review of course but it would make it easier for people to get started
> I think.

Since I do a lot of font reviews I'd like the polishing to be done
before a spec hit bugzilla :)

Anyway, with the experience of recent font reviews (un fonts in
particular), I've written some macros and spec templates that push all
the fc-cache scriptlet magic out of specfiles and should be a little
easier for new maintainers to work on.

They still require a human to
1. decide which font file goes in which (sub)package
2. decide which fontconfig generic family to associate with each font
3. write summaries and descriptions
4. do some legal auditing

Quite frankly, appart from 1. that could possibly be automated by
writing some script that uses fontconfig to tell people what font files
declare the same font family, I don't see how we could go much farther
(maybe generating the wiki page when it does not exist?)

Please review the files at
http://nim.fedorapeople.org/rpm-fonts/
and in particular the rpm-fonts package and how it is used by the other
packages.

I don't like the fontconfig file symlinking stuff much, if you can find
a simpler way to express it I'd be happy to change it.

> Perhaps it is something we (Fonts SIG) should consider working on?

I don't really know what parts new font packagers find hardest, I'd love
to see some feedback on the list.

As I wrote before, I don't think we could win a lot by automating. But
anyway, it's Fedora and everyone is free to work on what he likes, so if
you think automating would help far from me to stop you :p I wouldn't
mind being proven wrong.


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/20081111/ec66c60f/attachment.sig>

From nicolas.mailhot at laposte.net  Tue Nov 11 09:18:29 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 11 Nov 2008 10:18:29 +0100
Subject: db-compat
In-Reply-To: <1226380574.23813.5.camel@perihelion.int.jonmasters.org>
References: <1226293343.30170.4.camel@jcmlaptop>
	<20081110171712.GH8850@nostromo.devel.redhat.com>
	<1226351611.18109.15.camel@londonpacket.bos.redhat.com>
	<20081110213030.GB13633@nostromo.devel.redhat.com>
	<4918B44D.4050904@nobugconsulting.ro>
	<1226380574.23813.5.camel@perihelion.int.jonmasters.org>
Message-ID: <1226395109.26647.30.camel@arekh.okg>

Le mardi 11 novembre 2008 ? 00:16 -0500, Jon Masters a ?crit :
> On Tue, 2008-11-11 at 00:23 +0200, Manuel Wolfshant wrote:

> > > db-4.1 was last the system DB library in RHEL 3/FC1.
> 
> What's the point of a "compat" library if not to support software built
> for such systems? 

Compat libraries are here to help transitions within the repository,
when some packages have been rebuilt to use the new version and others ?
not. They're killed as soon as this transition is complete because:
? compat libraries have their own maintainer cost, and we don't want to
pay it when there are no in-distro users
? as long as they're available there's the risk someone adds a new
package depending on them in the repo, making the transition go
backwards

Thus compat libraries represent a grace period for everyone to
transition gracefully. That some ISVs do not want to understand this and
wait till the grace period is over to realise they need to do some work
is something you should take with those ISVs. Fedora/RHEL provided a
grace period, they chose not to use it.

It's the same problem as users wanting to block xorg releases till
nvidia supported the new APIs, while nvidia waits for new releases to be
official to start working on those APIs.

Bad service from ISVs that do proprietary software, nothing less.

-- 
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/20081111/b235fcd2/attachment.sig>

From nicolas.mailhot at laposte.net  Tue Nov 11 09:24:00 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 11 Nov 2008 10:24:00 +0100
Subject: Removing "minimal buildroot" dependencies from rpmdevtools
In-Reply-To: <200811102321.08688.opensource@till.name>
References: <200811102351.47926.ville.skytta@iki.fi>
	<200811102321.08688.opensource@till.name>
Message-ID: <1226395440.26647.32.camel@arekh.okg>

Le lundi 10 novembre 2008 ? 23:20 +0100, Till Maas a ?crit :
> But I am not sure, whether 
> this can be done, because I remember some restrictions that a package can 
> only be in one comps group.

We've tried at some point to have each package in one group only, but
there were so many exceptions I had to remove the check from the xslt a
long time ago.

-- 
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/20081111/c06c2e67/attachment.sig>

From tim at niemueller.de  Tue Nov 11 10:08:21 2008
From: tim at niemueller.de (Tim Niemueller)
Date: Tue, 11 Nov 2008 11:08:21 +0100
Subject: dlopen()/festival problem
In-Reply-To: <20081110174442.GA1935@jadzia.bu.edu>
References: <49183552.1010302@niemueller.de>
	<20081110152454.GA9380@host0.dyn.jankratochvil.net>
	<20081110174442.GA1935@jadzia.bu.edu>
Message-ID: <49195995.6020804@niemueller.de>

Matthew Miller schrieb:
> Can you file this in bugzilla so that I don't forget about it? I'm planning
> to do a big update of festival after F10 is out the door.

I filed it as #470995
(https://bugzilla.redhat.com/show_bug.cgi?id=470995) with links to the
ML postings. I have filed it against rawhide. Although I didn't check
the problem on rawhide your mail suggests that not much has changed
since F-9.

If you don't mind I will add a workaround for the include file problem
to the current package and push updates for festival on F-8 to F-10,
because otherwise the -devel packages are completely useless.

	Tim

-- 
    Tim Niemueller <tim at niemueller.de>      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)



From green at redhat.com  Tue Nov 11 11:50:41 2008
From: green at redhat.com (Anthony Green)
Date: Tue, 11 Nov 2008 03:50:41 -0800
Subject: [fedora-java] Orphaning jakarta-commons-cli
In-Reply-To: <c79f4f0c0811102120o35e0078ar5bb969118d4f9a13@mail.gmail.com>
References: <4918B972.4040606@redhat.com>
	<c79f4f0c0811102120o35e0078ar5bb969118d4f9a13@mail.gmail.com>
Message-ID: <49197191.8070009@redhat.com>

Jesus M. Rodriguez wrote:
> On Mon, Nov 10, 2008 at 5:45 PM, Anthony Green <green at redhat.com> wrote:
>   
>> I plan on orphaning jakarta-commons-cli.  This package is still required by
>> checkstyle and others, but I have no interest in maintaining it.
>> This old bugzilla.....
>> https://bugzilla.redhat.com/show_bug.cgi?id=453018
>> ...tells me there's a new version.  I have not managed to make time to
>> upgrade the package, so I'm hoping somebody with more interest will make the
>> effort.  Contact me if you are willing to take this package over.
>>
>> Thanks!
>>
>> Anthony Green
>>     
>
> I'd be interested. We use this on Spacewalk.
>   
Thank you Jesus.  I've release ownership in the package db for F-9, F-10 
and devel.  rakesh at fedoraproject.org has also volunteered to co-maintain.

AG



>
> jesus
>   



From pertusus at free.fr  Tue Nov 11 11:59:18 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 11 Nov 2008 12:59:18 +0100
Subject: db-compat
In-Reply-To: <1226395109.26647.30.camel@arekh.okg>
References: <1226293343.30170.4.camel@jcmlaptop>
	<20081110171712.GH8850@nostromo.devel.redhat.com>
	<1226351611.18109.15.camel@londonpacket.bos.redhat.com>
	<20081110213030.GB13633@nostromo.devel.redhat.com>
	<4918B44D.4050904@nobugconsulting.ro>
	<1226380574.23813.5.camel@perihelion.int.jonmasters.org>
	<1226395109.26647.30.camel@arekh.okg>
Message-ID: <20081111115917.GB2801@free.fr>

On Tue, Nov 11, 2008 at 10:18:29AM +0100, Nicolas Mailhot wrote:
> 
> Thus compat libraries represent a grace period for everyone to
> transition gracefully. That some ISVs do not want to understand this and
> wait till the grace period is over to realise they need to do some work
> is something you should take with those ISVs. Fedora/RHEL provided a
> grace period, they chose not to use it.

I completly disagree. Not everything needs to be rebuilt to work, compat
libraries are interesting when one wants to avoid to rebuild
applications when the application doesn't change. The other way is to
use static libraries, but this isn't more accepted in fedora.

An example is the numerical models. Once it is built, it is better not
to rebuild it. It may be adapted to the new API and rebuilt, of course,
but if this extra work can be avoided by providing a compat library, it
may be better. 

So if maintainers are ready to maintain compat library, let
them do it, it means that it is less work for them than a rebuild of the
application.

--
Pat



From rawhide at fedoraproject.org  Tue Nov 11 12:25:44 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Tue, 11 Nov 2008 12:25:44 +0000 (UTC)
Subject: rawhide report: 20081111 changes
Message-ID: <20081111122544.7DB911F8257@releng2.fedora.phx.redhat.com>

Compose started at Tue Nov 11 06:01:09 UTC 2008

Updated Packages:

alliance-5.0-23.20070718snap.fc10
---------------------------------
* Mon Nov 10 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 5.0-23.20070718snap
- Added Requires xorg-x11-fonts-misc to fix launch crash


banshee-1.4.0.1-1.fc10
----------------------
* Mon Nov 10 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.4.0.1-1
- update to 1.4.0.1


beagle-0.3.8-13.fc10
--------------------
* Sat Nov  8 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> - 0.3.8-13
- Fix patch to apply

* Sat Nov  8 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> - 0.3.8-12
- Use new libgnome-desktop
- Backport fix for RH #556243

* Sun Nov  2 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> - 0.3.8-11
- Revert last change

* Sun Nov  2 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> - 0.3.8-10
- Require gnome-deskop in the gnome package (RH #556243)


clamav-0.94.1-1.fc10
--------------------
* Wed Nov  5 17:00:00 2008 Robert Scheck <robert at fedoraproject.org> - 0.94.1-1
- Upgrade to 0.94.1


fedora-release-10-1
-------------------

fedora-release-notes-10.0.0-0.2
-------------------------------
* Fri Nov  7 17:00:00 2008 Paul W. Frields <stickster at gmail.com> - 10.0.0-0.2
- Snapshot package for updated fedora-release compatibility


gajim-0.11.4-6.fc10
-------------------
* Sun Nov  9 17:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 0.11.4-6
- Added 'Requires: gnome-python2-gnome' on all distributions starting from
  Fedora 10. Closes Red Hat Bugzilla bug #470181.

* Tue Oct 28 18:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 0.11.4-5
- Added 'Requires: avahi-tools'.


gdb-6.8-29.fc10
---------------
* Sun Nov  9 17:00:00 2008 Jan Kratochvil <jan.kratochvil at redhat.com> - 6.8-29
- Fix more the variable-length-arrays support (BZ 468266, feature BZ 377541).
- Integrate the `bt full' protection (for BZ 466901) into the VLA patch.

* Thu Nov  6 17:00:00 2008 Jan Kratochvil <jan.kratochvil at redhat.com> - 6.8-28
- Fix the "never terminate `bt full'" patch false GCC warning / build error.

* Thu Nov  6 17:00:00 2008 Jan Kratochvil <jan.kratochvil at redhat.com> - 6.8-27
- Fix resolving of variables at locations lists in prelinked libs (BZ 466901),
  bugreported by Michal Babej.
- Never terminate `bt full' on a problem of variable resolving (for BZ 466901).

* Thu Nov  6 17:00:00 2008 Jan Kratochvil <jan.kratochvil at redhat.com> - 6.8-26
- Fix more the variable-length-arrays support (BZ 468266, feature BZ 377541).
- Fix the watchpoints conditionals.
- Fix on PPC spurious SIGTRAPs on active watchpoints.
- Fix occasional stepping lockup on many threads, seen on ia64.

* Mon Nov  3 17:00:00 2008 Jan Kratochvil <jan.kratochvil at redhat.com> - 6.8-25
- Fix the variable-length-arrays support (BZ 468266, feature BZ 377541).
- Fix the debuginfo-install suggestions for missing base packages (BZ 467901),
  also update the rpm/yum code to no longer require _RPM_4_4_COMPAT.


gnome-packagekit-0.3.9-8.fc10
-----------------------------
* Mon Nov 10 17:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.9-8
- Rewrite the patch by Warren to only silently exit for the update icon.

* Fri Nov  7 17:00:00 2008 Warren Togami <wtogami at redhat.com> - 0.3.9-7
- Bug #470617 Just exit instead of complaining about a non-local session

* Wed Nov  5 17:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.9-6
- Fix up the fedora system-install-packages compatibility script.
- Fixes #468568

* Sat Nov  1 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.9-5
- Fix up the pirut obsoletes to fix upgrades from F8. Fixes #469481


kdebase-workspace-4.1.2-14.fc10
-------------------------------
* Fri Nov  7 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.2-14
- only omit battery applet when guidance-power-manager is installed

* Fri Nov  7 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1.2-13
- omit battery applet from default panel

* Wed Nov  5 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.2-12
- fix i18n issue in kdm


kernel-2.6.27.5-94.fc10
-----------------------
* Mon Nov 10 17:00:00 2008 Jeremy Katz <katzj at redhat.com> 2.6.27.5-94
- Fix up bogons in OLPC touchpad patch
- Reduce error level of an mmc warning on boot for XO (#469159)

* Mon Nov 10 17:00:00 2008 Dave Jones <davej at redhat.com> 2.6.27.5-93
- Make UTF-8 the default for FAT/VFAT filesystems again.

* Mon Nov 10 17:00:00 2008 Dave Airlie <airlied at redhat.com> 2.6.27.5-92
- radeon modesetting - fix oops on powerpc + ring sizing bug

* Sun Nov  9 17:00:00 2008 Chuck Ebbert <cebbert at redhat.com> 2.6.27.5-91
- Fix up the CVE-2008-3528 patch so we get it from -stable.

* Sun Nov  9 17:00:00 2008 Chuck Ebbert <cebbert at redhat.com> 2.6.27.5-90
- ext4 updates to 2.6.28-rc3

* Sun Nov  9 17:00:00 2008 Chuck Ebbert <cebbert at redhat.com> 2.6.27.5-89
- Fix ACPI dock bugs (#470321)

* Sat Nov  8 17:00:00 2008 Dave Airlie <airlied at redhat.com> 2.6.27.5-88
- radeon modesetting - fix mouse on second head and 3 second hangs hopefully

* Fri Nov  7 17:00:00 2008 John W. Linville <linville at redhat.com> 2.6.27.4-85
- Re-modularize ieee80211 component
- Cleanup ieee80211-related config stuff

* Fri Nov  7 17:00:00 2008 Chuck Ebbert <cebbert at redhat.com> 2.6.27.5-87
- Linux 2.6.27.5
  Dropped Patches:
    linux-2.6-sched-features-disable-hrtick.patch
    linux-2.6-sched_clock-prevent-scd-clock-from-moving-backwards
    linux-2.6-x86-avoid-dereferencing-beyond-stack-THREAD_SIZE.patch
    linux-2.6-usb-storage-unusual-devs-jmicron-ata-bridge.patch
    linux-2.6-acpi-clear-wake-status.patch
    linux-2.6-acpi-ignore-reset_reg_sup.patch
    linux-2.6-net-tcp-option-ordering.patch
    linux-2.6-input-dell-keyboard-keyup.patch
    linux-2.6.27-acpi-ec-drizzle.patch
    linux-2.6-libata-pata_it821x-fix-lba48-on-raid-volumes.patch
    linux-2.6-rtc-cmos-look-for-pnp-rtc-first.patch
    linux-2.6-x86-register-platform-rtc-if-pnp-doesnt-describe-it.patch
    linux-2.6-agp-intel-cantiga-fix.patch
  Reverted from upstream:
    firewire-fix-ioctl-return-code.patch
    firewire-fix-setting-tag-and-sy-in-iso-transmission.patch
    firewire-fix-struct-fw_node-memory-leak.patch
    firewire-fw-sbp2-delay-first-login-to-avoid-retries.patch
    firewire-fw-sbp2-fix-races.patch
    firewire-survive-more-than-256-bus-resets.patch

* Fri Nov  7 17:00:00 2008 Chuck Ebbert <cebbert at redhat.com> 2.6.27.4-86
- Update the r8169 network driver to the 2.6.28 version.


openoffice.org-3.0.0-9.10.fc10
------------------------------
* Fri Nov  7 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.0-9.10
- window manager hatred

* Thu Nov  6 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.0-9.9
- add openoffice.org-3.0.0.ooo95908.pyuno.debugging.spew.patch
- add openoffice.org-3.0.0.ooo90072.sw.undo-longtext.patch

* Tue Nov  4 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.0-9.8
- Resolves: rhbz#469804 openoffice.org-3.0.0.ooo95793.goodies.met.patch
- Resolves: rhbz#469630 openoffice.org-3.0.0.ooo95834.dontset-nonfunctional-forward.patch

* Wed Oct 29 18:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.0-9.7
- Resolves: rhbz#468336 openoffice.org-3.0.0.ooo95533.sw.safertableexport.patch
- workspace.impress163.patch
- Resolves: rhbz#468935 Print to file can have no effect in an edge-case
- openoffice.org-3.0.0.ooo95341.cppcanvas.patch


plymouth-0.6.0-0.2008.11.10.5.fc10
----------------------------------
* Mon Nov 10 17:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.11.10.5
- Force the right arch when calling plymouth-set-default-plugin
  (bug 470732)

* Mon Nov 10 17:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.11.10.4
- Drop comet (bug 468705)
- make boot-duration config(noreplace)

* Mon Nov 10 17:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.11.10.3
- Actually move patches upstream

* Mon Nov 10 17:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.11.10.2
- Don't abort if no splash when root gets mounted

* Mon Nov 10 17:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.11.10.1
- Fix feedback loop with plymouth:debug
- Move patches upstream
- Improve comet animation

* Thu Nov  6 17:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.11.06.2
- show details plugin on --hide-splash so people can see why the splash
  got hidden.

* Thu Nov  6 17:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.11.06.1
- Don't exit on plymouth --show-splash after sulogin
- Properly retake console after that --show-splash

* Wed Nov  5 17:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.11.05.1
- reset colors on quit --retain-splash
- fix off by one in damage calculation for label

* Tue Nov  4 17:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.10.30.5
- Add a sample boot-duration for livecds and first time boots
  (bug 469752)


podsleuth-0.6.3-1.fc10
----------------------
* Mon Nov 10 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.6.3-1
- update to 0.6.3
- apply patch from upstream to update model info, fix artwork bug


redhat-menus-10.0.1-1.fc10
--------------------------
* Mon Nov 10 17:00:00 2008 Ray Strode <rstrode at redhat.com> - 10.0.1-1
- Update translations (bug 470652)


scim-bridge-0.4.15-8.fc10
-------------------------
* Sun Sep 28 18:00:00 2008 Huang Peng <phuang at redhat.com> - 0.4.15-8
- Change release version to 8 for rebuilding rpms.


selinux-policy-3.5.13-18.fc10
-----------------------------
* Wed Nov  5 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.13-18
- Allow postgresl to bind to udp nodes

* Wed Nov  5 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.13-17
- Allow lvm to dbus chat with hal
- Allow rlogind to read nfs_t

* Wed Nov  5 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.13-16
- Fix cyphesis file context

* Mon Nov  3 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.13-15
- Allow hal/pm-utils to look at /var/run/video.rom
- Add ulogd policy

* Mon Nov  3 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.13-14
- Additional fixes for cyphesis
- Fix certmaster file context
- Add policy for system-config-samba
- Allow hal to read /var/run/video.rom

* Mon Nov  3 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.13-13
- Allow dhcpc to restart ypbind
- Fixup labeling in /var/run

* Thu Oct 30 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.13-12
- Add certmaster policy


solar-backgrounds-0.92.0-1.fc10
-------------------------------
* Sat Nov  8 17:00:00 2008 Martin Sourada <mso at fedoraproject.org> - 0.92.0-1
- New releases, fixes 1680x1050 wallpapers (rhbz #469779)

* Fri Oct 31 18:00:00 2008 Martin Sourada <mso at fedoraproject.org> - 0.91.1-2
- Move Requires: before %description for -extras subpackage, koji seem to omit
  those otherwise


taglib-sharp-2.0.3.0-7.fc10
---------------------------
* Mon Nov 10 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2.0.3.0-7
- apply mimetypes fix recommended by banshee upstream


udev-127-3.fc10
---------------
* Mon Nov 10 17:00:00 2008 Harald Hoyer <harald at redhat.com> 127-3
- added memory stick rules (bug #470096)


xorg-x11-drv-i810-2.5.0-3.fc10
------------------------------
* Mon Nov 10 17:00:00 2008 Adam Jackson <ajax at redhat.com> 2.5.0-3
- intel-2.4.2-dell-quirk.patch: No LVDS on Dell Studio Hybrid.

* Fri Oct 31 18:00:00 2008 Dave Airlie <airlied at redhat.com> 2.5.0-2
- disable legacy 3D allocation now we have GEM.


Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 21









Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot





From nicolas.mailhot at laposte.net  Tue Nov 11 13:01:53 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 11 Nov 2008 14:01:53 +0100
Subject: Fedora 11 font package changes proposal (renames, splits, etc)
In-Reply-To: <1226333844.17989.9.camel@arekh.okg>
References: <1226228950.21652.95.camel@arekh.okg>
	<1226333844.17989.9.camel@arekh.okg>
Message-ID: <1226408513.8833.3.camel@arekh.okg>

Le lundi 10 novembre 2008 ? 17:17 +0100, Nicolas Mailhot a ?crit :

> To proof it some more I've separated the common macro, spec templates
> and directory definitions in a separate package, then modified three
> font packages to use it:
> ? dejavu: multiple font families, multiple fontconfig files, 
> ? theokritos: single font family and fontconfig file,
> ? vera: multiple font families and no config file
> 
> It all works with the same macros, factors out the magic and reduces
> average font package complexity.
> 
> (and hopefully the number of mistakes on has to correct in review)
> 
> What do people think of it ?
> 
> http://nim.fedorapeople.org/rpm-fonts/

I've released a new version with some fontconfig templates added in. I
hope Behdad will find some time to review 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/20081111/70fae8f8/attachment.sig>

From wolfy at nobugconsulting.ro  Tue Nov 11 13:23:02 2008
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Tue, 11 Nov 2008 15:23:02 +0200
Subject: db-compat
In-Reply-To: <1226395109.26647.30.camel@arekh.okg>
References: <1226293343.30170.4.camel@jcmlaptop>	<20081110171712.GH8850@nostromo.devel.redhat.com>	<1226351611.18109.15.camel@londonpacket.bos.redhat.com>	<20081110213030.GB13633@nostromo.devel.redhat.com>	<4918B44D.4050904@nobugconsulting.ro>	<1226380574.23813.5.camel@perihelion.int.jonmasters.org>
	<1226395109.26647.30.camel@arekh.okg>
Message-ID: <49198736.9050100@nobugconsulting.ro>

Nicolas Mailhot wrote:
> Le mardi 11 novembre 2008 ? 00:16 -0500, Jon Masters a ?crit :
>   
>> On Tue, 2008-11-11 at 00:23 +0200, Manuel Wolfshant wrote:
>>     
>
>   
>>>> db-4.1 was last the system DB library in RHEL 3/FC1.
>>>>         
>> What's the point of a "compat" library if not to support software built
>> for such systems? 
>>     
>
> Compat libraries are here to help transitions within the repository,
> when some packages have been rebuilt to use the new version and others ?
> not. They're killed as soon as this transition is complete because:
> ? compat libraries have their own maintainer cost, and we don't want to
> pay it when there are no in-distro users
> ? as long as they're available there's the risk someone adds a new
> package depending on them in the repo, making the transition go
> backwards
>
> Thus compat libraries represent a grace period for everyone to
> transition gracefully. That some ISVs do not want to understand this and
> wait till the grace period is over to realise they need to do some work
> is something you should take with those ISVs. Fedora/RHEL provided a
> grace period, they chose not to use it.
>   
Good luck convincing IBM 
(http://www.haifa.ibm.com/projects/verification/RB_Homepage/ ), Cadence 
(www.cadence.com) and Synopsys (http://www.synopsys.com/) about that 
[*]. Until Feb 2008 Rulebase was still built with compatibility with RH9 
in mind. The switch to RHEL4 occured less than one year ago. Latest 
build (this summer)  claims compatibility (as I have said before) with 
RHEL5 but needs db-4.1; Synopsys still has NO official support for 
anything but RHEL 3.0 / 4.0 (but most of their tools do work on 5); 
Cadence has lots of tools which do NOT work on RHEL5. Mentor Graphics 
are the only ones who really support RHEL 5 (via static builds)

> It's the same problem as users wanting to block xorg releases till
> nvidia supported the new APIs, while nvidia waits for new releases to be
> official to start working on those APIs.
>
> Bad service from ISVs that do proprietary software, nothing less.
>   
That is correct. Try convincing the hardware industry to not use the 
tools from the above vendors, in the context where there are only 3 
major players and 2 of them have their own agenda.


-- 
     Manuel Wolfshant       linux registered user #131416
        IT manager    NoBug Consulting SRL
  A: Yes.
  >Q: Are you sure?
  >>A: Because it reverses the logical flow of conversation.
  >>>Q: Why is top posting frowned upon? 





From lesmikesell at gmail.com  Tue Nov 11 13:51:05 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 11 Nov 2008 07:51:05 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <20081111090721.928d792a.mschwendt@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>	<49190741.6090902@gmail.com>
	<20081111090721.928d792a.mschwendt@gmail.com>
Message-ID: <49198DC9.3030609@gmail.com>

Michael Schwendt wrote:
> On Mon, 10 Nov 2008 22:17:05 -0600, Les Mikesell wrote:
> 
>> Beg your pardon?  How many years has fedora policy forced a horribly 
>> fractured 3rd party repository situation
> 
> Which policy is that?

I'm not even sure how to describe it.  There's the part about not 
admitting that users need things like vendor provided drivers, Sun Java, 
  VMware, etc. and coordinating with the people that provide them. 
There's the part about never coming to terms that the several 3rd party 
repositories could agree on to coordinate into one or at least stay in 
sync with each other and the core.  There's the part about never 
including references to any of these 3rd party resources in the distro 
so users are forced to discover them on their own and hope they pick the 
right one, since they conflict with each other.  These are big problems 
for anyone trying to use fedora, and something that Ubuntu has taken 
care of so it is rarely a user problem.  There are some understandable 
legal issues involving patented components, but that's not all there is 
to it.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From sundaram at fedoraproject.org  Tue Nov 11 14:07:01 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 11 Nov 2008 19:37:01 +0530
Subject: Proposal: Rolling Release
In-Reply-To: <4918C02C.7030907@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<49185A3C.7050700@cchtml.com>	<4918658F.8060709@fedoraproject.org>	<49186F03.5040008@gmail.com>	<491877DC.4010806@fedoraproject.org>	<1226343130.4020.12.camel@localhost.localdomain>	<1226343720.12953.8.camel@luminos.localdomain>	<491888FB.3000501@gmail.com>	<49188C04.8020203@fedoraproject.org>	<4918908A.8070103@gmail.com>	<49189357.4040708@fedoraproject.org>	<4918A11F.8070500@gmail.com>	<4918B610.1080905@fedoraproject.org>
	<4918C02C.7030907@gmail.com>
Message-ID: <49199185.4080904@fedoraproject.org>

Les Mikesell wrote:
> Rahul Sundaram wrote:
>>
>>> And you may need both old and new versions present while you perform 
>>> the operations an upgrade requires.  So generic package-magic would 
>>> involve being able to install the new version without removing the 
>>> old so you have a chance to do the interactive parts before it is too 
>>> late.
>>
>> Again, this is something upstream project should do. GTK and gstreamer 
>> for example does make this easy.
>>
>> http://www106.pair.com/rhp/parallel.html
>>
>> Working around this at the packaging level is always going to require 
>> elaborate hacks. OpenSUSE did this for shipping KDE 3 and KDE 4 in 
>> parallel but other distributions refused.
> 
> I'm not sure I understand the logic of making upstream deal with the 
> problem that RPM's design introduces.  There's rarely an issue if you 
> want to do parallel version installs out of an upstream source - and I'd 
> guess the developers _always_ do that for anything they rely on.

If you read the link above, they don't do much of that in many upstream 
projects and pointing fingers at RPM here doesn't help because no other 
package manager can do magic either. Packagers can hack it to make it 
work but it is pretty difficult.

Rahul








From lesmikesell at gmail.com  Tue Nov 11 14:14:32 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 11 Nov 2008 08:14:32 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <1226394564.26647.22.camel@arekh.okg>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<49185A3C.7050700@cchtml.com>	<4918658F.8060709@fedoraproject.org>	<49186F03.5040008@gmail.com>	<491877DC.4010806@fedoraproject.org>	<1226343130.4020.12.camel@localhost.localdomain>	<1226343720.12953.8.camel@luminos.localdomain>	<491888FB.3000501@gmail.com>	<49188C04.8020203@fedoraproject.org>	<4918908A.8070103@gmail.com>	<49189357.4040708@fedoraproject.org>	<4918A11F.8070500@gmail.com>	<4918B610.1080905@fedoraproject.org>
	<4918C02C.7030907@gmail.com> <1226394564.26647.22.camel@arekh.okg>
Message-ID: <49199348.7080502@gmail.com>

Nicolas Mailhot wrote:
> Le lundi 10 novembre 2008 ? 17:13 -0600, Les Mikesell a ?crit :
> 
>> I'm not sure I understand the logic of making upstream deal with the 
>> problem that RPM's design introduces.  There's rarely an issue if you 
>> want to do parallel version installs out of an upstream source - and I'd 
>> guess the developers _always_ do that for anything they rely on.
> 
> Developpers typically re-create configuration files and data files when
> they do parallel installs. Thus they do not have to deal with
> config/data format conversion and rollback. Which is the main problem in
> doing rpm rollbacks, because unlike on dev stations, we can not afford
> to lose of duplicate user data.

Yes, developers deal with well known real-world situations.  If RPM 
can't handle this, then perhaps it misses some important design concepts 
- like letting the admin decide whether to duplicate or migrate data, 
where to put the copies, and what scratch space to use for the process. 
   A packaging system could present a few simple forms for the needed 
run-time choices as a commercial-quality product almost certainly would, 
but by avoiding this concept completely, the distro forces the 
admin/user to keep a whole spare machine whenever a fallback might be 
needed and to find and understand all the low-level migration tools that 
the developer would use but didn't have a way to package/automate 
because the package manager couldn't accommodate it.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From sundaram at fedoraproject.org  Tue Nov 11 14:20:58 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 11 Nov 2008 19:50:58 +0530
Subject: Proposal: Rolling Release
In-Reply-To: <49198DC9.3030609@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>	<49190741.6090902@gmail.com>	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
Message-ID: <491994CA.2040108@fedoraproject.org>

Les Mikesell wrote:

There's the part about never
> including references to any of these 3rd party resources in the distro 
> so users are forced to discover them on their own and hope they pick the 
> right one, since they conflict with each other. 

This has been explained many times before. Pointing to third party 
repositories/ explaining what they provide is a *legal* issue.  Pretty 
much all of them include free but patent encumbered code. Ubuntu is 
legally based in Isle of Man and has different legal restrictions. Even 
they cannot point to any repository that includes libdvdcss for example. 
You have to use a third party repository (medubuntu) which Canonical/ 
official ubuntu websites are careful not to point to.


Rahul



From valent.turkovic at gmail.com  Tue Nov 11 14:48:12 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Tue, 11 Nov 2008 15:48:12 +0100
Subject: kernel-devel in "Fedora" spin?
In-Reply-To: <48D0232E.7080101@redhat.com>
References: <1221522171.2102.6.camel@luminos.localdomain>
	<48CF04A1.7020801@redhat.com>
	<20080916020742.GA11480@yoda.jdub.homelinux.org>
	<48D0232E.7080101@redhat.com>
Message-ID: <64b14b300811110648m54e6e5fdwf67b9f21462732a4@mail.gmail.com>

On Tue, Sep 16, 2008 at 10:20 PM, Chris Snook <csnook at redhat.com> wrote:
> Josh Boyer wrote:
>>
>> On Mon, Sep 15, 2008 at 08:58:09PM -0400, Chris Snook wrote:
>>>
>>> Jesse Keating wrote:
>>>>
>>>> Back in December, I had made a change that blocked kernel-devel packages
>>>> from winding up in the install media for the Fedora spin.  I don't
>>>> recall getting any push back at the time, but I've gotten at least one
>>>> angry comment since then.  So I'm putting it out for more discussion.
>>>> Do we feel that the kernel-devel (5~megs) should be in the install
>>>> media?
>>>
>>> Yes please.  There's always new hardware we don't support yet, so some
>>> people will need to build drivers just to get online and access the repos.
>>>  If we ship it on the install media, it's much easier to distribute code
>>> that you're reasonably confident will work on a new install.  If people have
>>> to hunt down matching kernel and kernel-devel rpms, it's a moving target for
>>> people working on these device drivers.
>>>
>>> I'm not saying we should bend over backwards for out-of-tree drivers, but
>>> this is precisely the scenario that determines the first impression for
>>> someone trying this "Linux" thing on their shiny new bleeding-edge box, and
>>> it's pretty easy to accomodate.
>>
>> Erm... if this is the first time someone is trying a shiny new "Linux"
>> thing
>> on a bleeding edge box, and they have to grab a kernel-devel package and
>> build drivers _themselves_, then they are obviously smart enough  to run
>> 'yum install kernel-devel'.  Somehow I think your example is slightly off.
>> I don't know many Linux newbies that know 1) that they need to build a
>> driver, 2) what driver to build, and 3) what packages they need to build
>> it
>> all without knowing how to install anything.
>>
>> <jedi>
>> These are not the people you are targeting.  They know enough to not
>> require
>> kernel-devel on the install media.   You can move on to finding some other
>> use case that makes sense.
>> </jedi>
>>
>> josh
>>
>
> How are they going to 'yum install kernel-devel' with no internet
> connection? And how does the maintainer of the not-yet-merged driver ensure
> that his code always works with whatever kernel Fedora has rebased to today?
>  If you can be reasonably confident that every Fedora 10 user can at least
> get a certain matching kernel and kernel-devel, it's a lot easier to
> maintain drivers.  In theory you could build packages, but when you're doing
> this for Fedora, Debian, Ubuntu, CentOS, etc. it isn't really feasible.
>
> I know this is a niche use case, but it's a very large niche, and it's the
> niche that's most likely to become avid Linux users if we don't push them
> away the first time.  I know because I had this experience when I first
> started maintaining the atl2 network driver.  Tens of thousands of EeePC
> users, many of them technically savvy but Linux novices, wanted to replace
> the hacked up Xandros that ships on the Eee with something a bit more
> flexible, but they needed atl2 to make it work, and it wasn't merged in the
> distros yet.  When fast-moving distros like Fedora rebased their kernels to
> 2.6.24, my code broke, but the users who had kernel-devel or equivalent on
> their install media were fine, while the others either had to dig around to
> find a matching kernel and development headers, since only the latest were
> in the repos, or wait for me to fix it.
>
> The situation is much worse in the wireless world, where many of the drivers
> are reverse engineered and break on every new hardware rev, forcing users to
> install experimental stuff that isn't ready for merging in order to get
> their shiny new laptop online.
>
> I'm not saying that kernel-devel is an absolutely critical package to have
> on the install media, but it's extremely convenient at a time when users are
> most frustrated.  If we're going to trim the install media, which I'm not
> fundamentally opposed to, there are much more frivolous things that should
> go first.
>
> -- Chris
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


+1

This package is extremely useful and would help a lot of users if it
was on the install media (too bad that Live CD has no space for it
also).

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 schaiba at gmail.com  Tue Nov 11 14:54:37 2008
From: schaiba at gmail.com (Aioanei Rares)
Date: Tue, 11 Nov 2008 16:54:37 +0200
Subject: kernel-devel in "Fedora" spin?
In-Reply-To: <64b14b300811110648m54e6e5fdwf67b9f21462732a4@mail.gmail.com>
References: <1221522171.2102.6.camel@luminos.localdomain>
	<48CF04A1.7020801@redhat.com>
	<20080916020742.GA11480@yoda.jdub.homelinux.org>
	<48D0232E.7080101@redhat.com>
	<64b14b300811110648m54e6e5fdwf67b9f21462732a4@mail.gmail.com>
Message-ID: <778179b00811110654v235fb883l8245a4e9ab4a7ef7@mail.gmail.com>

On Tue, Nov 11, 2008 at 4:48 PM, Valent Turkovic
<valent.turkovic at gmail.com>wrote:

> +1
>
> This package is extremely useful and would help a lot of users if it
> was on the install media (too bad that Live CD has no space for it
> also).
>
> 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
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


+1
-- 
Aioanei Rares
schaiba at fedoraproject.org
"China is a big country, inhabited by many Chinese." --Charles de Gaulle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081111/e3e908d8/attachment.htm>

From mschwendt at gmail.com  Tue Nov 11 15:16:42 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 11 Nov 2008 16:16:42 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <49198DC9.3030609@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>
	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
Message-ID: <20081111161642.711a1d5d.mschwendt@gmail.com>

On Tue, 11 Nov 2008 07:51:05 -0600, Les Mikesell wrote:

> Michael Schwendt wrote:
> > On Mon, 10 Nov 2008 22:17:05 -0600, Les Mikesell wrote:
> > 
> >> Beg your pardon?  How many years has fedora policy forced a horribly 
> >> fractured 3rd party repository situation
> > 
> > Which policy is that?
> 
> I'm not even sure how to describe it.  There's the part about not 
> admitting that users need things like vendor provided drivers, Sun Java, 
>   VMware, etc. and coordinating with the people that provide them. 
> There's the part about never coming to terms that the several 3rd party 
> repositories could agree on to coordinate into one or at least stay in 
> sync with each other and the core.

How does that answer my question? Let me repeat. I've asked what policy it
is that "forced a horribly fractured 3rd party repository situation"? I'm
not aware of any such policy. The Fedora licensing guidelines are not
reponsible for fragmenting the 3rd party repo community. The licensing
situation just required that any stuff that cannot be included in the
Fedora package collection can only be provided in an external repo. What I
observe is that the 3rd party repo people have choosen not to team up for
various reasons, some of which are unchanged for several years. Repository
mixing problems are still alive and in some cases they are still caused by
replacing Fedora core packages. Coordinating beyond the borders of the
Fedora Project means extra efforts. There simply is not enough man-power
to spend additional time on coordinating between 3rd party packagers. They
are occupied with the task of keeping packages in their own repo
compatible with eachother. What hasn't changed in several years, expecting
individual volunteer packagers to stay informed about a multitude of 3rd
party repos and coordinating updates and upgrades for ultimate inter-repo
compatibility is still a tall order.



From bruno at wolff.to  Tue Nov 11 15:29:29 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Tue, 11 Nov 2008 09:29:29 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <20081111161642.711a1d5d.mschwendt@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>
	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
	<20081111161642.711a1d5d.mschwendt@gmail.com>
Message-ID: <20081111152929.GA13880@wolff.to>

On Tue, Nov 11, 2008 at 16:16:42 +0100,
  Michael Schwendt <mschwendt at gmail.com> wrote:
> 
> Fedora package collection can only be provided in an external repo. What I
> observe is that the 3rd party repo people have choosen not to team up for
> various reasons, some of which are unchanged for several years. Repository

Several have recently, as rpmfusion is now live.



From jnovy at redhat.com  Tue Nov 11 15:39:37 2008
From: jnovy at redhat.com (Jindrich Novy)
Date: Tue, 11 Nov 2008 16:39:37 +0100
Subject: db-compat
In-Reply-To: <50baabb30811100203p6e7e2e23y17a5fa048574d283@mail.gmail.com>
References: <1226293343.30170.4.camel@jcmlaptop>
	<50baabb30811100203p6e7e2e23y17a5fa048574d283@mail.gmail.com>
Message-ID: <20081111153937.GA3487@dhcp-lab-186.brq.redhat.com>

Hi,

On Mon, Nov 10, 2008 at 11:03:44AM +0100, Chitlesh GOORAH wrote:
> On Mon, Nov 10, 2008 at 6:02 AM, Jon Masters <jonathan at jonmasters.org> wrote:
> > Hi,
> >
> > It would seem we're no longer shipping libdb-4.1.so, whereas we do have
> > 4.2, 4.3, and 4.5 in that db4 compatibility package. I wound up just
> > stealing the binary from an older RPM and copying it in place.
> >
> > Anyway, software like Xilinx's ISE/EDK would like it back :)
> >
> > Jon.
> 
> Jindrich Novy, can you package it for us, please ?
> Xilinx ISE/EDK is also an important tool for me :)

not a problem. I needed to change the compat-db structure anyway to be
easily extendable for older BDBs. Actually the current rawhide
compat-db is just a dummy package containing only Requires to
compat-db45 and compat-db46. It doesn't seem to be too hard to add
compat-db41, 42 and 43 subpackages. But I will let the main compat-db
be dependent on the 4.5 and 4.6 BDBs only, so that the older
compat-dbs would need to be installed/required separately.

HTH,
Jindrich

> 
> Chitlesh

-- 
Jindrich Novy <jnovy at redhat.com>   http://people.redhat.com/jnovy/



From loganjerry at gmail.com  Tue Nov 11 15:21:12 2008
From: loganjerry at gmail.com (Jerry James)
Date: Tue, 11 Nov 2008 08:21:12 -0700
Subject: Filtering -fstack-protector out of CFLAGS
Message-ID: <870180fe0811110721n40d90907od33b24f93183ead6@mail.gmail.com>

GCL will not run successfully if compiled with -fstack-protector.  It has
its own internal stack management code that interacts badly with
-fstack-protector.  So I decided to try filtering that option out of the
default CFLAGS.  I put this at the top of the GCL spec file:

%global __global_cflags %{echo %__global_cflags | %{__sed} 's/
-fstack-protector//'}

That seems to work, in that %configure passes RPM_OPT_FLAGS minus
-fstack-protector, but when I run rpmbuild, I see:

echoechoechoechoechoechoechoechoExecuting(%prep): ...

What's with the 8 "echo" strings, one right after the other?  Is that
something I should worry about?  Am I filtering CFLAGS the right way?  Do I
need to get explicit permission from some group to do this?  Thanks,
-- 
Jerry James
http://loganjerry.googlepages.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081111/4eb8b3a1/attachment.htm>

From rmeggins at redhat.com  Tue Nov 11 15:42:36 2008
From: rmeggins at redhat.com (Rich Megginson)
Date: Tue, 11 Nov 2008 08:42:36 -0700
Subject: db-compat
In-Reply-To: <20081111153937.GA3487@dhcp-lab-186.brq.redhat.com>
References: <1226293343.30170.4.camel@jcmlaptop>	<50baabb30811100203p6e7e2e23y17a5fa048574d283@mail.gmail.com>
	<20081111153937.GA3487@dhcp-lab-186.brq.redhat.com>
Message-ID: <4919A7EC.9010208@redhat.com>

Jindrich Novy wrote:
> Hi,
>
> On Mon, Nov 10, 2008 at 11:03:44AM +0100, Chitlesh GOORAH wrote:
>   
>> On Mon, Nov 10, 2008 at 6:02 AM, Jon Masters <jonathan at jonmasters.org> wrote:
>>     
>>> Hi,
>>>
>>> It would seem we're no longer shipping libdb-4.1.so, whereas we do have
>>> 4.2, 4.3, and 4.5 in that db4 compatibility package. I wound up just
>>> stealing the binary from an older RPM and copying it in place.
>>>
>>> Anyway, software like Xilinx's ISE/EDK would like it back :)
>>>
>>> Jon.
>>>       
>> Jindrich Novy, can you package it for us, please ?
>> Xilinx ISE/EDK is also an important tool for me :)
>>     
>
> not a problem. I needed to change the compat-db structure anyway to be
> easily extendable for older BDBs. Actually the current rawhide
> compat-db is just a dummy package containing only Requires to
> compat-db45 and compat-db46. It doesn't seem to be too hard to add
> compat-db41, 42 and 43 subpackages. But I will let the main compat-db
> be dependent on the 4.5 and 4.6 BDBs only, so that the older
> compat-dbs would need to be installed/required separately.
>   
Would it be possible to also have a compat-db-devel package that 
includes the db.h from the older releases?  Or does this sort of defeat 
the purpose of "compat"?
> HTH,
> Jindrich
>
>   
>> Chitlesh
>>     
>
>   



From notting at redhat.com  Tue Nov 11 16:01:27 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 11 Nov 2008 11:01:27 -0500
Subject: db-compat
In-Reply-To: <1226380574.23813.5.camel@perihelion.int.jonmasters.org>
References: <1226293343.30170.4.camel@jcmlaptop>
	<20081110171712.GH8850@nostromo.devel.redhat.com>
	<1226351611.18109.15.camel@londonpacket.bos.redhat.com>
	<20081110213030.GB13633@nostromo.devel.redhat.com>
	<4918B44D.4050904@nobugconsulting.ro>
	<1226380574.23813.5.camel@perihelion.int.jonmasters.org>
Message-ID: <20081111160127.GE22663@nostromo.devel.redhat.com>

Jon Masters (jonathan at jonmasters.org) said: 
> > > db-4.1 was last the system DB library in RHEL 3/FC1.
> 
> What's the point of a "compat" library if not to support software built
> for such systems? We might argue that we only care about F8/F9 and so
> start removing other "old" compat libraries, but that's hardly useful.

It depends on both the library, and the release they're referring to.

For example, db-4.3 was the DB library in FC6 and RHEL 5. That is
probably a more reasonable compat library to maintain for a longer
period than the db-4.5 that was shipped in Fedora 7 but no RHEL
release.

But including all compat for all prior releases indefinitely is
a losing proposition - the db3/db2 from RHEL 2.1 would be an
example here. Or, to pick a random library from Fedora, we don't
carry old versions of directfb indefinitely, if at all.

Bill



From notting at redhat.com  Tue Nov 11 16:03:18 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 11 Nov 2008 11:03:18 -0500
Subject: Proposal: Rolling Release
In-Reply-To: <loom.20081111T010408-920@post.gmane.org>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<loom.20081111T010408-920@post.gmane.org>
Message-ID: <20081111160318.GF22663@nostromo.devel.redhat.com>

Bojan Smojver (bojan at rexursive.com) said: 
> I'm not so sure about the "easily" bit.
> 
> Let's say disconnected non-local authentication got addressed by various
> components. How are you going to test this without pulling in the whole new
> distro if something in say glibc got changed to accommodate it? Very hard to do
> and not worth the trouble of risking massive breakage this can cause.

To bring a more concrete angle to the discussion - the new plymouth
bootup support required not just the new plymouth package, but also
changes to:

- mkinitrd
- initscripts
- X server
- X drivers
- kernel
- gdm
- mesa (?)

... at which point you're dragging back an awful lot.

Bill



From lesmikesell at gmail.com  Tue Nov 11 16:06:56 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 11 Nov 2008 10:06:56 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <20081111161642.711a1d5d.mschwendt@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>	<49190741.6090902@gmail.com>	<20081111090721.928d792a.mschwendt@gmail.com>	<49198DC9.3030609@gmail.com>
	<20081111161642.711a1d5d.mschwendt@gmail.com>
Message-ID: <4919ADA0.1050900@gmail.com>

Michael Schwendt wrote:
> 
> How does that answer my question? Let me repeat. I've asked what policy it
> is that "forced a horribly fractured 3rd party repository situation"? I'm
> not aware of any such policy.

All I can say is that with Ubuntu you can pick vendor drivers and Sun 
Java 1.5 from the software management tool and you almost never have to 
worry about conflicts among packages from the different repositories. 
I've repeatedly requested these things in fedora and been repeatedly 
told it wasn't going to happen.

 > There simply is not enough man-power
> to spend additional time on coordinating between 3rd party packagers.

That's something that potential users have to take into account when 
choosing the distro they are going run.

> They
> are occupied with the task of keeping packages in their own repo
> compatible with eachother. What hasn't changed in several years, expecting
> individual volunteer packagers to stay informed about a multitude of 3rd
> party repos and coordinating updates and upgrades for ultimate inter-repo
> compatibility is still a tall order.

Which make the effort that Ubuntu (with the help of the underlying 
debian packages) makes particularly outstanding.  The point of using any 
distribution instead of rolling your own linux from scratch is that 
others theoretically have worked together to make sure that everything 
is compatible. If a distro doesn't arrange for this kind of cooperation 
it can't provide what users need and expect.

-- 
   Les Mikesell
    lesmikesell at gmail.com
	



From pemboa at gmail.com  Tue Nov 11 16:11:10 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Tue, 11 Nov 2008 10:11:10 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <4919ADA0.1050900@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>
	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com>
Message-ID: <16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>

On Tue, Nov 11, 2008 at 10:06 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Michael Schwendt wrote:
>>
>> How does that answer my question? Let me repeat. I've asked what policy it
>> is that "forced a horribly fractured 3rd party repository situation"? I'm
>> not aware of any such policy.
>
> All I can say is that with Ubuntu you can pick vendor drivers and Sun Java
> 1.5 from the software management tool and you almost never have to worry
> about conflicts among packages from the different repositories. I've
> repeatedly requested these things in fedora and been repeatedly told it
> wasn't going to happen.


And so you troll every thread looking to inject your negativity into
it, no matter what.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From mcepl at redhat.com  Tue Nov 11 16:11:56 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Tue, 11 Nov 2008 17:11:56 +0100
Subject: Proposal: Rolling Release
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
Message-ID: <cfnou5x4af.ln2@ppp1053.in.ipex.cz>

On 2008-11-11, 03:31 GMT, Arthur Pemberton wrote:
>> implementing it in their own distribution and the second 
>> comment is "I support the idea but I do think that it should 
>> only be considered after Fedora has done all the dirty work of 
>> getting it to work".
>
> I feel like this is something for Fedora to be proud of. It is a
> community, and different parts have their niches, this seems to be
> Fedora's own, and we should be proud of it.

I would vote for the T-Shirt with slogan:

Fedora?
Your tomorrow's distribution today!

Mat?j



From ajax at redhat.com  Tue Nov 11 16:17:26 2008
From: ajax at redhat.com (Adam Jackson)
Date: Tue, 11 Nov 2008 11:17:26 -0500
Subject: Filtering -fstack-protector out of CFLAGS
In-Reply-To: <870180fe0811110721n40d90907od33b24f93183ead6@mail.gmail.com>
References: <870180fe0811110721n40d90907od33b24f93183ead6@mail.gmail.com>
Message-ID: <1226420246.31982.363.camel@atropine.boston.devel.redhat.com>

On Tue, 2008-11-11 at 08:21 -0700, Jerry James wrote:
> GCL will not run successfully if compiled with -fstack-protector.  It
> has its own internal stack management code that interacts badly with
> -fstack-protector.  So I decided to try filtering that option out of
> the default CFLAGS.  I put this at the top of the GCL spec file:
> 
> %global __global_cflags %{echo %__global_cflags | %{__sed} 's/
> -fstack-protector//'}
> 
> That seems to work, in that %configure passes RPM_OPT_FLAGS minus
> -fstack-protector, but when I run rpmbuild, I see:
> 
> echoechoechoechoechoechoechoechoExecuting(%prep): ...
> 
> What's with the 8 "echo" strings, one right after the other?  Is that
> something I should worry about?  Am I filtering CFLAGS the right way?
> Do I need to get explicit permission from some group to do this?
> Thanks,

In the X server, I do:

export CFLAGS="${RPM_OPT_FLAGS} -Wstrict-overflow -rdynamic $CFLAGS"
%configure --enable-maintainer-mode %{xservers} \
# ...

Which seems to work 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/20081111/a2c7c7c8/attachment.sig>

From cdahlin at redhat.com  Tue Nov 11 16:18:29 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Tue, 11 Nov 2008 11:18:29 -0500
Subject: Proposal: Rolling Release
In-Reply-To: <4918B610.1080905@fedoraproject.org>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<49185A3C.7050700@cchtml.com>	<4918658F.8060709@fedoraproject.org>	<49186F03.5040008@gmail.com>	<491877DC.4010806@fedoraproject.org>	<1226343130.4020.12.camel@localhost.localdomain>	<1226343720.12953.8.camel@luminos.localdomain>	<491888FB.3000501@gmail.com>	<49188C04.8020203@fedoraproject.org>	<4918908A.8070103@gmail.com>	<49189357.4040708@fedoraproject.org>	<4918A11F.8070500@gmail.com>
	<4918B610.1080905@fedoraproject.org>
Message-ID: <4919B055.2040304@redhat.com>

Rahul Sundaram wrote:
> Les Mikesell wrote:
>
>> And you may need both old and new versions present while you perform 
>> the operations an upgrade requires.  So generic package-magic would 
>> involve being able to install the new version without removing the 
>> old so you have a chance to do the interactive parts before it is too 
>> late.
>
> Again, this is something upstream project should do. GTK and gstreamer 
> for example does make this easy.
>
> http://www106.pair.com/rhp/parallel.html
>
> Working around this at the packaging level is always going to require 
> elaborate hacks. OpenSUSE did this for shipping KDE 3 and KDE 4 in 
> parallel but other distributions refused.
The article you link to is about a subtly different problem: having two 
versions independently usable by the user. For Les's scenario we just 
need the file sets of both packages available. They aren't separate 
entities to the user. Also, Les's scenario is more granular: You can 
install gstreamer-0.8 and gstreamer-0.10 at the same time, but not 
gstreamer-0.10.1 and gstreamer-0.10.2. Requiring upstream to rename 
their packages even for bugfix releases with no abi effect is hell on 
them and on the users of their libraries.

There's been talk of snapshots and rollbacks, but I'd like to see 
discussion of some of the more exotic filesystem features. Btrfs is 
supposed to support transactions, which is a much more correct way of 
dealing with this sort of thing.

--CJD



From mclasen at redhat.com  Tue Nov 11 16:27:55 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 11 Nov 2008 11:27:55 -0500
Subject: Status of libtool 2.2.X?
In-Reply-To: <48ECEFB9.1080600@redhat.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
Message-ID: <1226420875.3368.1.camel@localhost.localdomain>

On Wed, 2008-10-08 at 19:36 +0200, Karsten Hopp wrote:

> Getting libtool-2.2 into F-11 is my plan, but I most likely need to get that through
> FESCo as it breaks up to 300 packages according to my mass rebuilds. I'm going to
> prepare a Wiki page with details about that.

F11 is open for business now. I think it would be a good idea to get the
libtool2 conversion underway early in the cycle.


Matthias



From mschwendt at gmail.com  Tue Nov 11 16:28:46 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 11 Nov 2008 17:28:46 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <20081111152929.GA13880@wolff.to>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>
	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<20081111152929.GA13880@wolff.to>
Message-ID: <20081111172846.3b4c3e27.mschwendt@gmail.com>

On Tue, 11 Nov 2008 09:29:29 -0600, Bruno Wolff III wrote:

> On Tue, Nov 11, 2008 at 16:16:42 +0100,
>   Michael Schwendt wrote:
> > 
> > Fedora package collection can only be provided in an external repo. What I
> > observe is that the 3rd party repo people have choosen not to team up for
> > various reasons, some of which are unchanged for several years. Repository
> 
> Several have recently, as rpmfusion is now live.

... and doesn't solve the problem as it doesn't unite the most
relevant and large 3rd party repos. (rpmrepo-devel list)



From hughsient at gmail.com  Tue Nov 11 16:37:44 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Tue, 11 Nov 2008 16:37:44 +0000
Subject: PackageKit 0.3.10 in Fedora 9
Message-ID: <1226421464.3033.80.camel@hughsie-laptop>

I've just built 0.3.10 for F10 and pushed it to updates-testing:

https://admin.fedoraproject.org/updates/PackageKit-0.3.10-1.fc9,gnome-packagekit-0.3.10-1.fc9

I would appreciate some feedback. If you can test the preupgrade
notification, that would be even better. Thanks.

Richard.




From lesmikesell at gmail.com  Tue Nov 11 16:39:01 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 11 Nov 2008 10:39:01 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>	<49190741.6090902@gmail.com>	<20081111090721.928d792a.mschwendt@gmail.com>	<49198DC9.3030609@gmail.com>	<20081111161642.711a1d5d.mschwendt@gmail.com>	<4919ADA0.1050900@gmail.com>
	<16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>
Message-ID: <4919B525.3070300@gmail.com>

Arthur Pemberton wrote:
>
>>> How does that answer my question? Let me repeat. I've asked what policy it
>>> is that "forced a horribly fractured 3rd party repository situation"? I'm
>>> not aware of any such policy.
>> All I can say is that with Ubuntu you can pick vendor drivers and Sun Java
>> 1.5 from the software management tool and you almost never have to worry
>> about conflicts among packages from the different repositories. I've
>> repeatedly requested these things in fedora and been repeatedly told it
>> wasn't going to happen.
> 
> 
> And so you troll every thread looking to inject your negativity into
> it, no matter what.

Would you rather just pretend fedora is perfect, supplies everything all 
users will ever need, and never ships a package with bugs that needs to 
be backed out?  Or that no other approaches to these problems can be better?

-- 
   Les Mikesell
     lesmikesell at gmail.com



From rjones at redhat.com  Tue Nov 11 16:42:56 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 11 Nov 2008 16:42:56 +0000
Subject: Filtering -fstack-protector out of CFLAGS
In-Reply-To: <870180fe0811110721n40d90907od33b24f93183ead6@mail.gmail.com>
References: <870180fe0811110721n40d90907od33b24f93183ead6@mail.gmail.com>
Message-ID: <20081111164256.GA20349@amd.home.annexia.org>

On Tue, Nov 11, 2008 at 08:21:12AM -0700, Jerry James wrote:
> GCL will not run successfully if compiled with -fstack-protector.  It has
> its own internal stack management code that interacts badly with
> -fstack-protector.  So I decided to try filtering that option out of the
> default CFLAGS.  I put this at the top of the GCL spec file:

We used to do something like this for the MinGW packages, since
-fstack-protector also causes a problem under Windows / MinGW
cross-compilation:

  CFLAGS="$RPM_OPT_FLAGS -fno-stack-protector" \
  ./configure [etc]

(example: http://hg.et.redhat.com/misc/fedora-mingw--devel/?fd=136ab7f25dc2;file=gnutls/mingw-gnutls.spec )

I should hasten to add that we don't do that any more, because we
defined our own %{_mingw32_cflags} macro so we'd have finer control.

Also, if anyone can fix -fstack-protector on Windows / MinGW, please
help!

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 schaiba at gmail.com  Tue Nov 11 16:48:31 2008
From: schaiba at gmail.com (Aioanei Rares)
Date: Tue, 11 Nov 2008 18:48:31 +0200
Subject: PackageKit 0.3.10 in Fedora 9
In-Reply-To: <1226421464.3033.80.camel@hughsie-laptop>
References: <1226421464.3033.80.camel@hughsie-laptop>
Message-ID: <778179b00811110848m1fd4f339o1c1bfa473bef1e98@mail.gmail.com>

On Tue, Nov 11, 2008 at 6:37 PM, Richard Hughes <hughsient at gmail.com> wrote:

> I've just built 0.3.10 for F10 and pushed it to updates-testing:
>
>
> https://admin.fedoraproject.org/updates/PackageKit-0.3.10-1.fc9,gnome-packagekit-0.3.10-1.fc9
>
> I would appreciate some feedback. If you can test the preupgrade
> notification, that would be even better. Thanks.
>
> Richard.
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


Richard, I'm using KDE; do you think a notification applet for it would be a
bad idea?
-- 
Aioanei Rares
schaiba at fedoraproject.org
"China is a big country, inhabited by many Chinese." --Charles de Gaulle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081111/b9fae321/attachment.htm>

From tcallawa at redhat.com  Tue Nov 11 16:48:09 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Tue, 11 Nov 2008 11:48:09 -0500
Subject: Proposal: Rolling Release
In-Reply-To: <4919B525.3070300@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com>
	<16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>
	<4919B525.3070300@gmail.com>
Message-ID: <1226422090.3417.23.camel@localhost.localdomain>

On Tue, 2008-11-11 at 10:39 -0600, Les Mikesell wrote:
> Would you rather just pretend fedora is perfect, supplies everything
> all 
> users will ever need, and never ships a package with bugs that needs
> to 
> be backed out?  Or that no other approaches to these problems can be
> better?

Les, 

I hate to bring logic to a troll fight, but lets try to be objective
here.

If the problem is truly:

* Fedora does not provide non-free, legally encumbered applications out
of the box

Then, there is nothing that we can do to resolve this which does not:

* Compromise Fedora's position on only including Free Software
* Break US law (and yes, this includes not committing contributory
infringement)

These are the facts. Now, if you think you have a constructive
suggestion on how to solve the problem I stated above which doesn't
compromise Fedora's Free Software only position or break US law, speak
now. Otherwise, please drop this point.

~spot



From hughsient at gmail.com  Tue Nov 11 16:56:49 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Tue, 11 Nov 2008 16:56:49 +0000
Subject: PackageKit 0.3.10 in Fedora 9
In-Reply-To: <778179b00811110848m1fd4f339o1c1bfa473bef1e98@mail.gmail.com>
References: <1226421464.3033.80.camel@hughsie-laptop>
	<778179b00811110848m1fd4f339o1c1bfa473bef1e98@mail.gmail.com>
Message-ID: <1226422609.3033.81.camel@hughsie-laptop>

On Tue, 2008-11-11 at 18:48 +0200, Aioanei Rares wrote:
> Richard, I'm using KDE; do you think a notification applet for it
> would be a bad idea?

Already exists: KPackageKit.

The prerequisite of KPackageKit is PackageKit 0.3.x which is one of the
reasons for this backport.

Richard.




From rc040203 at freenet.de  Tue Nov 11 17:06:59 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 11 Nov 2008 18:06:59 +0100
Subject: Filtering -fstack-protector out of CFLAGS
In-Reply-To: <1226420246.31982.363.camel@atropine.boston.devel.redhat.com>
References: <870180fe0811110721n40d90907od33b24f93183ead6@mail.gmail.com>
	<1226420246.31982.363.camel@atropine.boston.devel.redhat.com>
Message-ID: <1226423219.3752.131.camel@beck.corsepiu.local>

On Tue, 2008-11-11 at 11:17 -0500, Adam Jackson wrote:
> On Tue, 2008-11-11 at 08:21 -0700, Jerry James wrote:
> > GCL will not run successfully if compiled with -fstack-protector.  It
> > has its own internal stack management code that interacts badly with
> > -fstack-protector.  So I decided to try filtering that option out of
> > the default CFLAGS.  I put this at the top of the GCL spec file:
> > 
> > %global __global_cflags %{echo %__global_cflags | %{__sed} 's/
> > -fstack-protector//'}
> > 
> > That seems to work, in that %configure passes RPM_OPT_FLAGS minus
> > -fstack-protector, but when I run rpmbuild, I see:
> > 
> > echoechoechoechoechoechoechoechoExecuting(%prep): ...
> > 
> > What's with the 8 "echo" strings, one right after the other?  Is that
> > something I should worry about?  Am I filtering CFLAGS the right way?
> > Do I need to get explicit permission from some group to do this?
> > Thanks,
> 
> In the X server, I do:
> 
> export CFLAGS="${RPM_OPT_FLAGS} -Wstrict-overflow -rdynamic $CFLAGS"
> %configure --enable-maintainer-mode %{xservers} \
> # ...
> 
> Which seems to work fine.
With modern configure scripts you can pass CFLAGS to configure directly
instead of resorting to using the environment.

Ralf




From jonstanley at gmail.com  Tue Nov 11 17:13:39 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Tue, 11 Nov 2008 12:13:39 -0500
Subject: Upcoming Bugzilla activities related to F10 GA
Message-ID: <da159fda0811110913l7d9ceafi617c3f0f0bc2d2ef@mail.gmail.com>

Ahh, the leaves are changing, it's getting cold (at least here in the
Northern Hemisphere!), and snow is just around the corner! All of this
brings a new release of Fedora! And with each new Fedora release comes
some Bugzilla housekeeping. This e-mail is designed to let you know
about two things happening around November 25, 2008 (release of Fedora
10) and what you need to do, if anything.

1. We will be rebasing all rawhide bugs to F10. This will result in
regular bugs reported against rawhide during the Fedora 10 development
cycle being changed to version '10' instead of their current
assignment, 'rawhide'.  This is done in order to more accurately tell
where in the lineage of releases the bug was last reported because
over time 'rawhide' becomes ambiguous.

Note that this procedure does not apply to bugs that are against
component 'Package Review' or bugs that have the 'FutureFeature' or
'Tracking' keywords set, which will stay open in rawhide indefinitely.

If you do not want your bugs changed to version '10', add the
FutureFeature keyword. If you need help changing a large amount of
bugs manually, we'd be glad to help. Stop by #fedora-qa on
irc.freenode.net and we'll help you.

2. All bugs for EOL releases (at this point, Fedora 8) will get a
comment on or about GA of Fedora 10, explaining that one month of
maintenance remains, and to either move the bug to a later version if
still applicable, or they will be automatically closed in one month
with a resolution of WONTFIX.

More about these processes is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From cdahlin at redhat.com  Tue Nov 11 17:17:06 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Tue, 11 Nov 2008 12:17:06 -0500
Subject: PackageKit 0.3.10 in Fedora 9
In-Reply-To: <1226421464.3033.80.camel@hughsie-laptop>
References: <1226421464.3033.80.camel@hughsie-laptop>
Message-ID: <4919BE12.5000303@redhat.com>

Richard Hughes wrote:
> I've just built 0.3.10 for F10 and pushed it to updates-testing:
>
>   
Your subject says F9 and here you say F10... What's going on here exactly?\

--CJD

> https://admin.fedoraproject.org/updates/PackageKit-0.3.10-1.fc9,gnome-packagekit-0.3.10-1.fc9
>
> I would appreciate some feedback. If you can test the preupgrade
> notification, that would be even better. Thanks.
>
> Richard.
>
>
>   



From mschwendt at gmail.com  Tue Nov 11 17:17:07 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 11 Nov 2008 18:17:07 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <4919ADA0.1050900@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>
	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com>
Message-ID: <20081111181707.8fa55669.mschwendt@gmail.com>

On Tue, 11 Nov 2008 10:06:56 -0600, Les Mikesell wrote:

> All I can say is that with Ubuntu you can pick vendor drivers and Sun 
> Java 1.5 from the software management tool and you almost never have to 
> worry about conflicts among packages from the different repositories. 

"Almost never"? How many external repositories have you tried? Dependency
problems and inter-repository issues are not specific to Fedora or RPM.
Experimental upgrades/replacements/alternatives, orphans, and poorly
maintained packages do exist for other dists, too, not just in 3rd
party repos. Just talk to open-minded (!) Debian/Ubuntu followers.

And what has this to do with your earlier claim anyway? (the "horribly
fractured 3rd party situation")

> > There simply is not enough man-power
> > to spend additional time on coordinating between 3rd party packagers.
> 
> That's something that potential users have to take into account when 
> choosing the distro they are going run.

"Potential users" don't and can't know about such things. It's nothing
that plays a role in dist advertising yet. 3rd party repos are
_independent_. They are not controlled by the Fedora Project. They may
choose to follow project guidelines and contribute inside the project, but
that still may be too limiting. Sure, you can have a repo like Livna say they
are a pure add-ons repo for Fedora, but other repos might not do anything
like that since they want to upgrade/replace or conflict with Fedora
packages whenever they feel that's necessary. There are no guarantees
especially not with regard to mixing multiple repos, who probably don't
even know eachother.

Users switch dists out of many different reasons anyway. Some stick with a
dist for several years till they run into a problem that isn't solved
quickly (perhaps with exotical hardware). It's not unusual for users to
return after some time or to try another dist. It's also not unusual for
users to gain experience and notice that a lot of dists have many problems
in common (in particular everywhere where the same upstream software is
used unmodified), sometimes only with a delay due to a different release
cycle.

> Which make the effort that Ubuntu (with the help of the underlying 
> debian packages) makes particularly outstanding. 

Is a distribution war your only interest? I don't share your view.
So, no comment on packaging quality or repo quality here.
"the help of the underlying debian packages" is a funny phrase, btw.

> The point of using any 
> distribution instead of rolling your own linux from scratch is that 
> others theoretically have worked together to make sure that everything 
> is compatible.

And the context of this sentence is what?

> If a distro doesn't arrange for this kind of cooperation 
> it can't provide what users need and expect.

Apples and oranges. A discussion thread on this level only scratches
the surface. It won't be fruitful at all. Not enough substance.



From lesmikesell at gmail.com  Tue Nov 11 17:18:20 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 11 Nov 2008 11:18:20 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <1226422090.3417.23.camel@localhost.localdomain>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>	<49190741.6090902@gmail.com>	<20081111090721.928d792a.mschwendt@gmail.com>	<49198DC9.3030609@gmail.com>	<20081111161642.711a1d5d.mschwendt@gmail.com>	<4919ADA0.1050900@gmail.com>	<16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>	<4919B525.3070300@gmail.com>
	<1226422090.3417.23.camel@localhost.localdomain>
Message-ID: <4919BE5C.9050001@gmail.com>

Tom "spot" Callaway wrote:
> 
> I hate to bring logic to a troll fight, but lets try to be objective
> here.
> 
> If the problem is truly:
> 
> * Fedora does not provide non-free, legally encumbered applications out
> of the box

No, the problem is not that Fedora doesn't include those things in the 
box.  The problem is that Fedora does not admit that users need things 
that are not included in the box, does nothing to co-operate with others 
that would provide them, and by shipping a wildly moving target with no 
coordination, actively breaks everything others even attempt to do in 
this regard.

> Then, there is nothing that we can do to resolve this which does not:
> 
> * Compromise Fedora's position on only including Free Software
> * Break US law (and yes, this includes not committing contributory
> infringement)
> 
> These are the facts. Now, if you think you have a constructive
> suggestion on how to solve the problem I stated above which doesn't
> compromise Fedora's Free Software only position or break US law, speak
> now. Otherwise, please drop this point.

I fail to see how, for example, including a java-1.5.0-sun-compat 
package in the box, or maintaining a working relationship with the 
jpackage.org packagers would have compromised any sensible positions, 
yet it would have dramatically changed the user experience.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From hughsient at gmail.com  Tue Nov 11 17:18:09 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Tue, 11 Nov 2008 17:18:09 +0000
Subject: PackageKit 0.3.10 in Fedora 9
In-Reply-To: <4919BE12.5000303@redhat.com>
References: <1226421464.3033.80.camel@hughsie-laptop>
	<4919BE12.5000303@redhat.com>
Message-ID: <1226423889.3033.85.camel@hughsie-laptop>

On Tue, 2008-11-11 at 12:17 -0500, Casey Dahlin wrote:
> Your subject says F9 and here you say F10... What's going on here
> exactly?\

Sorry, it's been a long day. I did build 0.3.10 for F9, F10 and rawhide,
but in this instance I meant F9.

Richard.




From drago01 at gmail.com  Tue Nov 11 17:26:31 2008
From: drago01 at gmail.com (drago01)
Date: Tue, 11 Nov 2008 18:26:31 +0100
Subject: PackageKit 0.3.10 in Fedora 9
In-Reply-To: <1226423889.3033.85.camel@hughsie-laptop>
References: <1226421464.3033.80.camel@hughsie-laptop>
	<4919BE12.5000303@redhat.com>
	<1226423889.3033.85.camel@hughsie-laptop>
Message-ID: <f6ca9fed0811110926w308efdcagaf38466713c3b35b@mail.gmail.com>

On Tue, Nov 11, 2008 at 6:18 PM, Richard Hughes <hughsient at gmail.com> wrote:
> On Tue, 2008-11-11 at 12:17 -0500, Casey Dahlin wrote:
>> Your subject says F9 and here you say F10... What's going on here
>> exactly?\
>
> Sorry, it's been a long day. I did build 0.3.10 for F9, F10 and rawhide,
> but in this instance I meant F9.
>
> Richard.

anyone else with this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=471078 ?



From gnomeuser at gmail.com  Tue Nov 11 17:30:07 2008
From: gnomeuser at gmail.com (David Nielsen)
Date: Tue, 11 Nov 2008 18:30:07 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <20081111160318.GF22663@nostromo.devel.redhat.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<loom.20081111T010408-920@post.gmane.org>
	<20081111160318.GF22663@nostromo.devel.redhat.com>
Message-ID: <1dedbbfc0811110930y294ce663ld396b2000f083dba@mail.gmail.com>

2008/11/11 Bill Nottingham <notting at redhat.com>

> Bojan Smojver (bojan at rexursive.com) said:
> > I'm not so sure about the "easily" bit.
> >
> > Let's say disconnected non-local authentication got addressed by various
> > components. How are you going to test this without pulling in the whole
> new
> > distro if something in say glibc got changed to accommodate it? Very hard
> to do
> > and not worth the trouble of risking massive breakage this can cause.
>
> To bring a more concrete angle to the discussion - the new plymouth
> bootup support required not just the new plymouth package, but also
> changes to:
>
> - mkinitrd
> - initscripts
> - X server
> - X drivers
> - kernel
> - gdm
> - mesa (?)
>
> ... at which point you're dragging back an awful lot.


And if it's deemed stable enough for F10 as a release then surely it should
be stable enough as an update for F9. A big and not uncomplicated update
granted but we could in theory put this into updates-testing and roll it out
for F9 as well. If the argument against doing this would be stability one
would be left questioning how F10 could be labelled stable in the fist
place.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081111/97a50b33/attachment.htm>

From gnomeuser at gmail.com  Tue Nov 11 17:30:07 2008
From: gnomeuser at gmail.com (David Nielsen)
Date: Tue, 11 Nov 2008 18:30:07 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <20081111160318.GF22663@nostromo.devel.redhat.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<loom.20081111T010408-920@post.gmane.org>
	<20081111160318.GF22663@nostromo.devel.redhat.com>
Message-ID: <1dedbbfc0811110930y294ce663ld396b2000f083dba@mail.gmail.com>

2008/11/11 Bill Nottingham <notting at redhat.com>

> Bojan Smojver (bojan at rexursive.com) said:
> > I'm not so sure about the "easily" bit.
> >
> > Let's say disconnected non-local authentication got addressed by various
> > components. How are you going to test this without pulling in the whole
> new
> > distro if something in say glibc got changed to accommodate it? Very hard
> to do
> > and not worth the trouble of risking massive breakage this can cause.
>
> To bring a more concrete angle to the discussion - the new plymouth
> bootup support required not just the new plymouth package, but also
> changes to:
>
> - mkinitrd
> - initscripts
> - X server
> - X drivers
> - kernel
> - gdm
> - mesa (?)
>
> ... at which point you're dragging back an awful lot.


And if it's deemed stable enough for F10 as a release then surely it should
be stable enough as an update for F9. A big and not uncomplicated update
granted but we could in theory put this into updates-testing and roll it out
for F9 as well. If the argument against doing this would be stability one
would be left questioning how F10 could be labelled stable in the fist
place.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081111/97a50b33/attachment-0001.htm>

From gnomeuser at gmail.com  Tue Nov 11 17:30:07 2008
From: gnomeuser at gmail.com (David Nielsen)
Date: Tue, 11 Nov 2008 18:30:07 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <20081111160318.GF22663@nostromo.devel.redhat.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<loom.20081111T010408-920@post.gmane.org>
	<20081111160318.GF22663@nostromo.devel.redhat.com>
Message-ID: <1dedbbfc0811110930y294ce663ld396b2000f083dba@mail.gmail.com>

2008/11/11 Bill Nottingham <notting at redhat.com>

> Bojan Smojver (bojan at rexursive.com) said:
> > I'm not so sure about the "easily" bit.
> >
> > Let's say disconnected non-local authentication got addressed by various
> > components. How are you going to test this without pulling in the whole
> new
> > distro if something in say glibc got changed to accommodate it? Very hard
> to do
> > and not worth the trouble of risking massive breakage this can cause.
>
> To bring a more concrete angle to the discussion - the new plymouth
> bootup support required not just the new plymouth package, but also
> changes to:
>
> - mkinitrd
> - initscripts
> - X server
> - X drivers
> - kernel
> - gdm
> - mesa (?)
>
> ... at which point you're dragging back an awful lot.


And if it's deemed stable enough for F10 as a release then surely it should
be stable enough as an update for F9. A big and not uncomplicated update
granted but we could in theory put this into updates-testing and roll it out
for F9 as well. If the argument against doing this would be stability one
would be left questioning how F10 could be labelled stable in the fist
place.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081111/97a50b33/attachment-0002.htm>

From gnomeuser at gmail.com  Tue Nov 11 17:30:07 2008
From: gnomeuser at gmail.com (David Nielsen)
Date: Tue, 11 Nov 2008 18:30:07 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <20081111160318.GF22663@nostromo.devel.redhat.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<loom.20081111T010408-920@post.gmane.org>
	<20081111160318.GF22663@nostromo.devel.redhat.com>
Message-ID: <1dedbbfc0811110930y294ce663ld396b2000f083dba@mail.gmail.com>

2008/11/11 Bill Nottingham <notting at redhat.com>

> Bojan Smojver (bojan at rexursive.com) said:
> > I'm not so sure about the "easily" bit.
> >
> > Let's say disconnected non-local authentication got addressed by various
> > components. How are you going to test this without pulling in the whole
> new
> > distro if something in say glibc got changed to accommodate it? Very hard
> to do
> > and not worth the trouble of risking massive breakage this can cause.
>
> To bring a more concrete angle to the discussion - the new plymouth
> bootup support required not just the new plymouth package, but also
> changes to:
>
> - mkinitrd
> - initscripts
> - X server
> - X drivers
> - kernel
> - gdm
> - mesa (?)
>
> ... at which point you're dragging back an awful lot.


And if it's deemed stable enough for F10 as a release then surely it should
be stable enough as an update for F9. A big and not uncomplicated update
granted but we could in theory put this into updates-testing and roll it out
for F9 as well. If the argument against doing this would be stability one
would be left questioning how F10 could be labelled stable in the fist
place.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081111/97a50b33/attachment-0003.htm>

From gnomeuser at gmail.com  Tue Nov 11 17:30:07 2008
From: gnomeuser at gmail.com (David Nielsen)
Date: Tue, 11 Nov 2008 18:30:07 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <20081111160318.GF22663@nostromo.devel.redhat.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<loom.20081111T010408-920@post.gmane.org>
	<20081111160318.GF22663@nostromo.devel.redhat.com>
Message-ID: <1dedbbfc0811110930y294ce663ld396b2000f083dba@mail.gmail.com>

2008/11/11 Bill Nottingham <notting at redhat.com>

> Bojan Smojver (bojan at rexursive.com) said:
> > I'm not so sure about the "easily" bit.
> >
> > Let's say disconnected non-local authentication got addressed by various
> > components. How are you going to test this without pulling in the whole
> new
> > distro if something in say glibc got changed to accommodate it? Very hard
> to do
> > and not worth the trouble of risking massive breakage this can cause.
>
> To bring a more concrete angle to the discussion - the new plymouth
> bootup support required not just the new plymouth package, but also
> changes to:
>
> - mkinitrd
> - initscripts
> - X server
> - X drivers
> - kernel
> - gdm
> - mesa (?)
>
> ... at which point you're dragging back an awful lot.


And if it's deemed stable enough for F10 as a release then surely it should
be stable enough as an update for F9. A big and not uncomplicated update
granted but we could in theory put this into updates-testing and roll it out
for F9 as well. If the argument against doing this would be stability one
would be left questioning how F10 could be labelled stable in the fist
place.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081111/97a50b33/attachment-0004.htm>

From gnomeuser at gmail.com  Tue Nov 11 17:30:07 2008
From: gnomeuser at gmail.com (David Nielsen)
Date: Tue, 11 Nov 2008 18:30:07 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <20081111160318.GF22663@nostromo.devel.redhat.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<loom.20081111T010408-920@post.gmane.org>
	<20081111160318.GF22663@nostromo.devel.redhat.com>
Message-ID: <1dedbbfc0811110930y294ce663ld396b2000f083dba@mail.gmail.com>

2008/11/11 Bill Nottingham <notting at redhat.com>

> Bojan Smojver (bojan at rexursive.com) said:
> > I'm not so sure about the "easily" bit.
> >
> > Let's say disconnected non-local authentication got addressed by various
> > components. How are you going to test this without pulling in the whole
> new
> > distro if something in say glibc got changed to accommodate it? Very hard
> to do
> > and not worth the trouble of risking massive breakage this can cause.
>
> To bring a more concrete angle to the discussion - the new plymouth
> bootup support required not just the new plymouth package, but also
> changes to:
>
> - mkinitrd
> - initscripts
> - X server
> - X drivers
> - kernel
> - gdm
> - mesa (?)
>
> ... at which point you're dragging back an awful lot.


And if it's deemed stable enough for F10 as a release then surely it should
be stable enough as an update for F9. A big and not uncomplicated update
granted but we could in theory put this into updates-testing and roll it out
for F9 as well. If the argument against doing this would be stability one
would be left questioning how F10 could be labelled stable in the fist
place.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081111/97a50b33/attachment-0005.htm>

From sundaram at fedoraproject.org  Tue Nov 11 17:42:33 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 11 Nov 2008 23:12:33 +0530
Subject: Proposal: Rolling Release
In-Reply-To: <4919ADA0.1050900@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>	<49190741.6090902@gmail.com>	<20081111090721.928d792a.mschwendt@gmail.com>	<49198DC9.3030609@gmail.com>	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com>
Message-ID: <4919C409.4060401@fedoraproject.org>

Les Mikesell wrote:
> Michael Schwendt wrote:
>>
>> How does that answer my question? Let me repeat. I've asked what 
>> policy it
>> is that "forced a horribly fractured 3rd party repository situation"? I'm
>> not aware of any such policy.
> 
> All I can say is that with Ubuntu you can pick vendor drivers and Sun 
> Java 1.5 from the software management tool and you almost never have to 
> worry about conflicts among packages from the different repositories. 

If you meant proprietary drivers, just say it. "vendor drivers" is 
confusing since several of the drivers in the kernel and xorg are vendor 
supported and developed and available in the repository without conflicts.

Rahul



From mcepl at redhat.com  Tue Nov 11 17:41:38 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Tue, 11 Nov 2008 18:41:38 +0100
Subject: Proposal: Rolling Release
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>
	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com>
Message-ID: <insou5xh2j.ln2@ppp1053.in.ipex.cz>

On 2008-11-11, 16:06 GMT, Les Mikesell wrote:
> The point of using any distribution instead of rolling your own 
> linux from scratch is that others theoretically have worked 
> together to make sure that everything is compatible. If 
> a distro doesn't arrange for this kind of cooperation it can't 
> provide what users need and expect.

I know that I shouldn't feed a troll, but I couldn't resist -- in 
my not so humble opinion, most of the third party repos (except 
for the one, which I cannot name here) are more or less products 
of the time when it was difficult to put new packages into Fedora 
proper (yes, there were times before Extras). Now, I really don't 
see the reason, why you cannot take your package (except for the 
pesky legal reasons, but less put that aside) and put that 
package into Fedora.

Do I miss anything?

Mat?j



From lesmikesell at gmail.com  Tue Nov 11 17:52:11 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 11 Nov 2008 11:52:11 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <4919C409.4060401@fedoraproject.org>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>	<49190741.6090902@gmail.com>	<20081111090721.928d792a.mschwendt@gmail.com>	<49198DC9.3030609@gmail.com>	<20081111161642.711a1d5d.mschwendt@gmail.com>	<4919ADA0.1050900@gmail.com>
	<4919C409.4060401@fedoraproject.org>
Message-ID: <4919C64B.3010606@gmail.com>

Rahul Sundaram wrote:
>
>>> How does that answer my question? Let me repeat. I've asked what 
>>> policy it
>>> is that "forced a horribly fractured 3rd party repository situation"? 
>>> I'm
>>> not aware of any such policy.
>>
>> All I can say is that with Ubuntu you can pick vendor drivers and Sun 
>> Java 1.5 from the software management tool and you almost never have 
>> to worry about conflicts among packages from the different repositories. 
> 
> If you meant proprietary drivers, just say it. "vendor drivers" is 
> confusing since several of the drivers in the kernel and xorg are vendor 
> supported and developed and available in the repository without conflicts.

I meant redistributable drivers, of course.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Tue Nov 11 17:52:48 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 11 Nov 2008 11:52:48 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <20081111181707.8fa55669.mschwendt@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>	<49190741.6090902@gmail.com>	<20081111090721.928d792a.mschwendt@gmail.com>	<49198DC9.3030609@gmail.com>	<20081111161642.711a1d5d.mschwendt@gmail.com>	<4919ADA0.1050900@gmail.com>
	<20081111181707.8fa55669.mschwendt@gmail.com>
Message-ID: <4919C670.6090506@gmail.com>

Michael Schwendt wrote:
> 
>> All I can say is that with Ubuntu you can pick vendor drivers and Sun 
>> Java 1.5 from the software management tool and you almost never have to 
>> worry about conflicts among packages from the different repositories. 
> 
> "Almost never"? How many external repositories have you tried?

That's the real difference.  Ubuntu does not have the same exclusionary 
policy so you don't have to track down packages from a million 
uncoordinated places.

 > Dependency
> problems and inter-repository issues are not specific to Fedora or RPM.
> Experimental upgrades/replacements/alternatives, orphans, and poorly
> maintained packages do exist for other dists, too, not just in 3rd
> party repos.

Of course that can happen - Fedora just makes it impossible not to happen.

> Just talk to open-minded (!) Debian/Ubuntu followers.

I just have my own experience - on my laptop Ubuntu installs the right 
video and wireless driver and lets me pick Sun java from the GUI 
software tool.  Fedora doesn't.

> And what has this to do with your earlier claim anyway? (the "horribly
> fractured 3rd party situation")

Again - that's just my experience.  When I've installed fedora, I've had 
to track down the components myself and had them break regularly during 
updates.

>>> There simply is not enough man-power
>>> to spend additional time on coordinating between 3rd party packagers.
>> That's something that potential users have to take into account when 
>> choosing the distro they are going run.
> 
> "Potential users" don't and can't know about such things. It's nothing
> that plays a role in dist advertising yet. 3rd party repos are
> _independent_.

You are seriously underestimating users if you don't think they are 
capable of trying a few distros and tossing the ones that break.  Fedora 
forces the replacement issue regularly anyway with its fast expiration 
cycle.

>> Which make the effort that Ubuntu (with the help of the underlying 
>> debian packages) makes particularly outstanding. 
> 
> Is a distribution war your only interest? I don't share your view.
> So, no comment on packaging quality or repo quality here.

No, it is actually a fairly complicated issue.  Fedora serves a purpose, 
but I think it would be even better served if it were more usable on 
several fronts.  One is the upgrade cycle per the start of this thread, 
but equally critical is the effect of the changes on other software the 
user needs to run and whether or not the user trusts the distro enough 
to actually run things that will test it well.

> "the help of the underlying debian packages" is a funny phrase, btw.

How so?  Would the accomplishments of Ubuntu be possible if they 
isolated themselves from other's work instead of using it to best 
advantage?  What's funny to me is that packagers work to maintain 
incompatible systems and keep changing them yet say there is a lack of 
time to keep all their incompatible repository versions coordinated.

>> The point of using any 
>> distribution instead of rolling your own linux from scratch is that 
>> others theoretically have worked together to make sure that everything 
>> is compatible.
> 
> And the context of this sentence is what?

Simply that users will choose the distro that works. If you want to keep 
rolling out new stuff and have someone test it, it has to at least 
mostly work together most of the time.

>> If a distro doesn't arrange for this kind of cooperation 
>> it can't provide what users need and expect.
> 
> Apples and oranges. A discussion thread on this level only scratches
> the surface. It won't be fruitful at all. Not enough substance.

Agreed, but dismissing the ways Ubuntu provides a better user experience 
isn't all that useful either.

-- 
   Les Mikesell
    lesmikesell at gmail.com




From drago01 at gmail.com  Tue Nov 11 17:53:46 2008
From: drago01 at gmail.com (drago01)
Date: Tue, 11 Nov 2008 18:53:46 +0100
Subject: PackageKit 0.3.10 in Fedora 9
In-Reply-To: <1226421464.3033.80.camel@hughsie-laptop>
References: <1226421464.3033.80.camel@hughsie-laptop>
Message-ID: <f6ca9fed0811110953i9f5a83ds42a7d338147a9e71@mail.gmail.com>

On Tue, Nov 11, 2008 at 5:37 PM, Richard Hughes <hughsient at gmail.com> wrote:
> I've just built 0.3.10 for F10 and pushed it to updates-testing:
>
> https://admin.fedoraproject.org/updates/PackageKit-0.3.10-1.fc9,gnome-packagekit-0.3.10-1.fc9
>
> I would appreciate some feedback. If you can test the preupgrade
> notification, that would be even better. Thanks.
>
> Richard.

gpk-application.desktop

has

Icon=system-software-install

while it should be

Icon=system-software-installer

(It shows no icon in the menu because there is no such file)



From drago01 at gmail.com  Tue Nov 11 17:53:46 2008
From: drago01 at gmail.com (drago01)
Date: Tue, 11 Nov 2008 18:53:46 +0100
Subject: PackageKit 0.3.10 in Fedora 9
In-Reply-To: <1226421464.3033.80.camel@hughsie-laptop>
References: <1226421464.3033.80.camel@hughsie-laptop>
Message-ID: <f6ca9fed0811110953i9f5a83ds42a7d338147a9e71@mail.gmail.com>

On Tue, Nov 11, 2008 at 5:37 PM, Richard Hughes <hughsient at gmail.com> wrote:
> I've just built 0.3.10 for F10 and pushed it to updates-testing:
>
> https://admin.fedoraproject.org/updates/PackageKit-0.3.10-1.fc9,gnome-packagekit-0.3.10-1.fc9
>
> I would appreciate some feedback. If you can test the preupgrade
> notification, that would be even better. Thanks.
>
> Richard.

gpk-application.desktop

has

Icon=system-software-install

while it should be

Icon=system-software-installer

(It shows no icon in the menu because there is no such file)



From lesmikesell at gmail.com  Tue Nov 11 17:57:47 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 11 Nov 2008 11:57:47 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <insou5xh2j.ln2@ppp1053.in.ipex.cz>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>	<49190741.6090902@gmail.com>	<20081111090721.928d792a.mschwendt@gmail.com>	<49198DC9.3030609@gmail.com>	<20081111161642.711a1d5d.mschwendt@gmail.com>	<4919ADA0.1050900@gmail.com>
	<insou5xh2j.ln2@ppp1053.in.ipex.cz>
Message-ID: <4919C79B.5020800@gmail.com>

Matej Cepl wrote:

>> The point of using any distribution instead of rolling your own 
>> linux from scratch is that others theoretically have worked 
>> together to make sure that everything is compatible. If 
>> a distro doesn't arrange for this kind of cooperation it can't 
>> provide what users need and expect.
> 
> I know that I shouldn't feed a troll, but I couldn't resist -- in 
> my not so humble opinion, most of the third party repos (except 
> for the one, which I cannot name here) are more or less products 
> of the time when it was difficult to put new packages into Fedora 
> proper (yes, there were times before Extras). Now, I really don't 
> see the reason, why you cannot take your package (except for the 
> pesky legal reasons, but less put that aside) and put that 
> package into Fedora.
> 
> Do I miss anything?

Can a java-sun-compat package go there - or is one already for a Sun 1.5 
version?  Can all the stuff from jpackage.org go there?  Should it have 
to?  If it doesn't all go is there any way to keep the parts that do 
from conflicting with the parts that don't?

-- 
   Les Mikesell
     lesmikesell at gmail.com



From drago01 at gmail.com  Tue Nov 11 17:53:46 2008
From: drago01 at gmail.com (drago01)
Date: Tue, 11 Nov 2008 18:53:46 +0100
Subject: PackageKit 0.3.10 in Fedora 9
In-Reply-To: <1226421464.3033.80.camel@hughsie-laptop>
References: <1226421464.3033.80.camel@hughsie-laptop>
Message-ID: <f6ca9fed0811110953i9f5a83ds42a7d338147a9e71@mail.gmail.com>

On Tue, Nov 11, 2008 at 5:37 PM, Richard Hughes <hughsient at gmail.com> wrote:
> I've just built 0.3.10 for F10 and pushed it to updates-testing:
>
> https://admin.fedoraproject.org/updates/PackageKit-0.3.10-1.fc9,gnome-packagekit-0.3.10-1.fc9
>
> I would appreciate some feedback. If you can test the preupgrade
> notification, that would be even better. Thanks.
>
> Richard.

gpk-application.desktop

has

Icon=system-software-install

while it should be

Icon=system-software-installer

(It shows no icon in the menu because there is no such file)



From drago01 at gmail.com  Tue Nov 11 17:53:46 2008
From: drago01 at gmail.com (drago01)
Date: Tue, 11 Nov 2008 18:53:46 +0100
Subject: PackageKit 0.3.10 in Fedora 9
In-Reply-To: <1226421464.3033.80.camel@hughsie-laptop>
References: <1226421464.3033.80.camel@hughsie-laptop>
Message-ID: <f6ca9fed0811110953i9f5a83ds42a7d338147a9e71@mail.gmail.com>

On Tue, Nov 11, 2008 at 5:37 PM, Richard Hughes <hughsient at gmail.com> wrote:
> I've just built 0.3.10 for F10 and pushed it to updates-testing:
>
> https://admin.fedoraproject.org/updates/PackageKit-0.3.10-1.fc9,gnome-packagekit-0.3.10-1.fc9
>
> I would appreciate some feedback. If you can test the preupgrade
> notification, that would be even better. Thanks.
>
> Richard.

gpk-application.desktop

has

Icon=system-software-install

while it should be

Icon=system-software-installer

(It shows no icon in the menu because there is no such file)



From rc040203 at freenet.de  Tue Nov 11 17:58:57 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 11 Nov 2008 18:58:57 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <insou5xh2j.ln2@ppp1053.in.ipex.cz>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>
	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com>  <insou5xh2j.ln2@ppp1053.in.ipex.cz>
Message-ID: <1226426337.3752.147.camel@beck.corsepiu.local>

On Tue, 2008-11-11 at 18:41 +0100, Matej Cepl wrote:
> On 2008-11-11, 16:06 GMT, Les Mikesell wrote:
> > The point of using any distribution instead of rolling your own 
> > linux from scratch is that others theoretically have worked 
> > together to make sure that everything is compatible. If 
> > a distro doesn't arrange for this kind of cooperation it can't 
> > provide what users need and expect.
> 
> I know that I shouldn't feed a troll, but I couldn't resist -- in 
> my not so humble opinion, most of the third party repos (except 
> for the one, which I cannot name here) are more or less products 
> of the time when it was difficult to put new packages into Fedora 
> proper (yes, there were times before Extras). Now, I really don't 
> see the reason, why you cannot take your package (except for the 
> pesky legal reasons, but less put that aside) and put that 
> package into Fedora.
> 
> Do I miss anything?
Yes, it often is MUCH easier to run a 3rd party repo than to try getting
a package into Fedora.

Ralf





From notting at redhat.com  Tue Nov 11 18:10:30 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 11 Nov 2008 13:10:30 -0500
Subject: Proposal: Rolling Release
In-Reply-To: <1dedbbfc0811110930y294ce663ld396b2000f083dba@mail.gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<loom.20081111T010408-920@post.gmane.org>
	<20081111160318.GF22663@nostromo.devel.redhat.com>
	<1dedbbfc0811110930y294ce663ld396b2000f083dba@mail.gmail.com>
Message-ID: <20081111181030.GA25255@nostromo.devel.redhat.com>

David Nielsen (gnomeuser at gmail.com) said: 
> > - mkinitrd
> > - initscripts
> > - X server
> > - X drivers
> > - kernel
> > - gdm
> > - mesa (?)
> >
> > ... at which point you're dragging back an awful lot.
> 
> And if it's deemed stable enough for F10 as a release then surely it should
> be stable enough as an update for F9. A big and not uncomplicated update
> granted but we could in theory put this into updates-testing and roll it out
> for F9 as well.

For what gain, exactly? Do we really want to disrupt the paradigm of a
stable release for existing users?

> If the argument against doing this would be stability one
> would be left questioning how F10 could be labelled stable in the fist
> place.

The argument against it is sanity.

Bill



From drago01 at gmail.com  Tue Nov 11 18:11:44 2008
From: drago01 at gmail.com (drago01)
Date: Tue, 11 Nov 2008 19:11:44 +0100
Subject: PackageKit 0.3.10 in Fedora 9
In-Reply-To: <f6ca9fed0811110953i9f5a83ds42a7d338147a9e71@mail.gmail.com>
References: <1226421464.3033.80.camel@hughsie-laptop>
	<f6ca9fed0811110953i9f5a83ds42a7d338147a9e71@mail.gmail.com>
Message-ID: <f6ca9fed0811111011sdec3ac0te208a77a43604e90@mail.gmail.com>

On Tue, Nov 11, 2008 at 6:53 PM, drago01 <drago01 at gmail.com> wrote:
> On Tue, Nov 11, 2008 at 5:37 PM, Richard Hughes <hughsient at gmail.com> wrote:
>> I've just built 0.3.10 for F10 and pushed it to updates-testing:
>>
>> https://admin.fedoraproject.org/updates/PackageKit-0.3.10-1.fc9,gnome-packagekit-0.3.10-1.fc9
>>
>> I would appreciate some feedback. If you can test the preupgrade
>> notification, that would be even better. Thanks.
>>
>> Richard.
>
> gpk-application.desktop
>
> has
>
> Icon=system-software-install
>
> while it should be
>
> Icon=system-software-installer
>
> (It shows no icon in the menu because there is no such file)
>

Removing packages fails with
"TID already set to /46_cadabccd_data"



From jkeating at redhat.com  Tue Nov 11 18:13:44 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 11 Nov 2008 10:13:44 -0800
Subject: Proposal: Rolling Release
In-Reply-To: <4919BE5C.9050001@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com>
	<16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>
	<4919B525.3070300@gmail.com>
	<1226422090.3417.23.camel@localhost.localdomain>
	<4919BE5C.9050001@gmail.com>
Message-ID: <1226427224.10458.3.camel@luminos.localdomain>

On Tue, 2008-11-11 at 11:18 -0600, Les Mikesell wrote:
> I fail to see how, for example, including a java-1.5.0-sun-compat 
> package in the box, or maintaining a working relationship with the 
> jpackage.org packagers would have compromised any sensible positions, 
> yet it would have dramatically changed the user experience.

Which policy prevents this from happening?

-- 
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/20081111/d64eb59e/attachment.sig>

From jkeating at redhat.com  Tue Nov 11 18:16:46 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 11 Nov 2008 10:16:46 -0800
Subject: Proposal: Rolling Release
In-Reply-To: <1dedbbfc0811110930y294ce663ld396b2000f083dba@mail.gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<loom.20081111T010408-920@post.gmane.org>
	<20081111160318.GF22663@nostromo.devel.redhat.com>
	<1dedbbfc0811110930y294ce663ld396b2000f083dba@mail.gmail.com>
Message-ID: <1226427406.10458.4.camel@luminos.localdomain>

On Tue, 2008-11-11 at 18:30 +0100, David Nielsen wrote:
> If the argument against doing this would be stability one
> would be left questioning how F10 could be labelled stable in the fist
> place.

The argument would be the amount of work it would take to port it back
and make it work on the older release, taking time and energy away from
the /next/ Fedora release.  Fedora releases are quick, spending time and
effort to backport huge feature sets to older releases does nothing to
help this.

-- 
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/20081111/dfa095bd/attachment.sig>

From nicolas.mailhot at laposte.net  Tue Nov 11 18:24:28 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 11 Nov 2008 19:24:28 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <4919BE5C.9050001@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com>
	<16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>
	<4919B525.3070300@gmail.com>
	<1226422090.3417.23.camel@localhost.localdomain>
	<4919BE5C.9050001@gmail.com>
Message-ID: <1226427868.10317.1.camel@arekh.okg>

Le mardi 11 novembre 2008 ? 11:18 -0600, Les Mikesell a ?crit :

> I fail to see how, for example, including a java-1.5.0-sun-compat 
> package in the box, or maintaining a working relationship with the 
> jpackage.org packagers 

Since Jesse Keating is now part of the jpackage.org team I don't see how
Fedora "does not maintain a working relationship with the jpackage.org
packagers"

-- 
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/20081111/60e68690/attachment.sig>

From lesmikesell at gmail.com  Tue Nov 11 18:28:24 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 11 Nov 2008 12:28:24 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <1226427224.10458.3.camel@luminos.localdomain>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>	<49190741.6090902@gmail.com>	<20081111090721.928d792a.mschwendt@gmail.com>	<49198DC9.3030609@gmail.com>	<20081111161642.711a1d5d.mschwendt@gmail.com>	<4919ADA0.1050900@gmail.com>	<16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>	<4919B525.3070300@gmail.com>	<1226422090.3417.23.camel@localhost.localdomain>	<4919BE5C.9050001@gmail.com>
	<1226427224.10458.3.camel@luminos.localdomain>
Message-ID: <4919CEC8.40208@gmail.com>

Jesse Keating wrote:
> On Tue, 2008-11-11 at 11:18 -0600, Les Mikesell wrote:
>> I fail to see how, for example, including a java-1.5.0-sun-compat 
>> package in the box, or maintaining a working relationship with the 
>> jpackage.org packagers would have compromised any sensible positions, 
>> yet it would have dramatically changed the user experience.
> 
> Which policy prevents this from happening?

I have no idea.  Up through FC5, jpackage packages worked.  Then some 
small subset of packages that looked like they had a jpackage history, 
not including any reasonable way to install Sun java were included in 
the fedora repo and fedora support was dropped in the jpackage repo. 
Probably unrelated, but around the same time, Sun Java 1.5 was included 
in the RHEL5 update repository.  I basically gave up on getting any of 
it to work.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From rdieter at math.unl.edu  Tue Nov 11 18:34:14 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 11 Nov 2008 12:34:14 -0600
Subject: Proposal: Rolling Release
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>
	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com> <insou5xh2j.ln2@ppp1053.in.ipex.cz>
	<1226426337.3752.147.camel@beck.corsepiu.local>
Message-ID: <gfcj76$76a$1@ger.gmane.org>

Ralf Corsepius wrote:

> On Tue, 2008-11-11 at 18:41 +0100, Matej Cepl wrote:

>> Do I miss anything?

> Yes, it often is MUCH easier to run a 3rd party repo than to try getting
> a package into Fedora.

<sarcasm>
Who really needs all that fedora infrastructure, peer/package review,
qa/testing, anyway.  Much easier to skip all that.
</sarcasm>

-- Rex



From lesmikesell at gmail.com  Tue Nov 11 18:39:21 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 11 Nov 2008 12:39:21 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <1226427868.10317.1.camel@arekh.okg>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>	<49190741.6090902@gmail.com>	<20081111090721.928d792a.mschwendt@gmail.com>	<49198DC9.3030609@gmail.com>	<20081111161642.711a1d5d.mschwendt@gmail.com>	<4919ADA0.1050900@gmail.com>	<16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>	<4919B525.3070300@gmail.com>	<1226422090.3417.23.camel@localhost.localdomain>	<4919BE5C.9050001@gmail.com>
	<1226427868.10317.1.camel@arekh.okg>
Message-ID: <4919D159.1050909@gmail.com>

Nicolas Mailhot wrote:
> Le mardi 11 novembre 2008 ? 11:18 -0600, Les Mikesell a ?crit :
> 
>> I fail to see how, for example, including a java-1.5.0-sun-compat 
>> package in the box, or maintaining a working relationship with the 
>> jpackage.org packagers 
> 
> Since Jesse Keating is now part of the jpackage.org team I don't see how
> Fedora "does not maintain a working relationship with the jpackage.org
> packagers"

Maybe things have changed since the last time I tried it, but by 
'maintain', I meant over a period of time, not changing wildly between 
versions.  Is there a sane way to install a Sun 1.5 again?

-- 
   Les Mikesell
     lesmikesell at gmail.com



From rc040203 at freenet.de  Tue Nov 11 18:41:31 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 11 Nov 2008 19:41:31 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <gfcj76$76a$1@ger.gmane.org>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>
	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com> <insou5xh2j.ln2@ppp1053.in.ipex.cz>
	<1226426337.3752.147.camel@beck.corsepiu.local>
	<gfcj76$76a$1@ger.gmane.org>
Message-ID: <1226428891.3752.167.camel@beck.corsepiu.local>

On Tue, 2008-11-11 at 12:34 -0600, Rex Dieter wrote:
> Ralf Corsepius wrote:
> 
> > On Tue, 2008-11-11 at 18:41 +0100, Matej Cepl wrote:
> 
> >> Do I miss anything?
> 
> > Yes, it often is MUCH easier to run a 3rd party repo than to try getting
> > a package into Fedora.
> 
> <sarcasm>
> Who really needs all that fedora infrastructure, peer/package review,
> qa/testing, anyway.  Much easier to skip all that.
> </sarcasm>

Well, ... if the fedora infrastructure was really serving contributors,
if peer/package reviews were functional, if testing was functional, then
this all would not be an issue.

The unpleasant truth is: It isn't.






From ml at deadbabylon.de  Tue Nov 11 18:41:41 2008
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Tue, 11 Nov 2008 19:41:41 +0100
Subject: KDE-SIG weekly report (46/2008)
Message-ID: <200811111941.50352.ml@deadbabylon.de>

This is a report of the weekly KDE-SIG-Meeting with a summary of the 
topics that were discussed. If you want to add a comment please reply
?to this email or add it to the related meeting page.

----------------------------------------------------------------------------------

= Weekly KDE Summary =

Week: 46/2008

Time: 2008-11-11 16:00 UTC

Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-11-11

Meeting log: https://fedoraproject.org/w/uploads/c/c4/KDE-SIG-2008-11-11.txt

----------------------------------------------------------------------------------

= Participants =

- BenBoeckel 
- JaroslavReznik 
- KevinKofler 
- LukasTinkl 
- RexDieter 
- SebastianVahl 
- ThanNgo

----------------------------------------------------------------------------------

= Agenda =

topics to discuss: 
* KDE 4.1.3 update for F-9/F-10 
* Desktop User Guide
* Backports: systray
* Possible KDE spin additions: liveusb-creator 
* Upcoming events: FUDCon11, CampKDE 

recent bugs: 
#469452: akregator crashs on startup with an imported feeds.opml (marked as 
fixed by upstream) [1,2,3]
#471022: Can't hide akregator by clicking systray icon (marked as fixed by 
upstream in 4.1.3, patch for 4.1.2)

----------------------------------------------------------------------------------

= Summary =

KDE 4.1.3 update for F-9/F-10:
- - - - -
* KDE 4.1.3 will be included in the next push to Fedora 9 
updates-testing-newkey. [5]
* The work for F10 will start now and KDE 4.1.3 will be provided as a 0-day 
update. 

Desktop User Guide: 
- - - - -
* JaroslavReznik has posted a first draft. [6]
* The remaining topics will be delegated on #fedora-kde after the meeting. 

Backports: systray: 
- - - - -
* According to JaroslavReznik his backport is crashing with missing symbols 
due to changes in libplasma. 
* So we will wait for KDE 4.2 and avoid a backport then. 

Possible KDE spin additions: liveusb-creator:
- - - - -
* The proposed addition liveusb-creator has already been included in the KDE 
live images since Snapshot2. 
* But there would be enough space for more proposals. Currently the spins are 
at 678 megs for i686 and 683 megs for x86_64. 

Upcoming events: FUDCon11, CampKDE:
- - - - -
* RexDieter asked if any KDE SIG member will attend one of them. 
 Unfortunately both events are too far away for most of the KDE SIG members. 

#469452: akregator crashes on startup with an imported feeds.opml:
- - - - -
* Short summary: akregator will crash on startup when expiry is enabled. 
* We'll try to backport the upstream fixes and include them in f10-final. 

#471022: Can't hide akregator by clicking systray icon:
- - - - -
*  Short summary: clicking on akregator's systray icon doesn't minimize 
akregator when it's already visible. 
* This is fixed in kdepim 4.1.3 which will be provided as a 0-day update. 
* If the fix is only trivial it will be backported to the version in 
f10-final. 

Open discussion:
- - - - -
o KDE related classroom: 
* KevinFenzi asked the KDE SIG for a KDE-related class in the new  IRC 
classrooms. [7]
* The most popular discussed topic for a KDE class was a KDE 4 for KDE 3 users 
session. 
* RexDieter, KevinKofler and JaroslavReznik will hold this at December 6 at 
14:45 UTC.

----------------------------------------------------------------------------------

= Next Meeting =

http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-11-18

----------------------------------------------------------------------------------

= Links =

[1] https://bugzilla.redhat.com/show_bug.cgi?id=469452
[2] http://websvn.kde.org/?view=rev&revision=873573
[3] http://websvn.kde.org/?view=rev&revision=873575
[4] https://bugzilla.redhat.com/show_bug.cgi?id=471022
[5] http://tinyurl.com/kde413f9
[6] https://fedoraproject.org/wiki/KDE/Docs/DesktopUserGuide
[7] https://fedoraproject.org/wiki/Communicate/IRC/Classroom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081111/7b0b6e75/attachment.sig>

From alsadi at gmail.com  Tue Nov 11 18:48:44 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Tue, 11 Nov 2008 20:48:44 +0200
Subject: Proposal: Rolling Release
In-Reply-To: <1226428891.3752.167.camel@beck.corsepiu.local>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<49190741.6090902@gmail.com>
	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com> <insou5xh2j.ln2@ppp1053.in.ipex.cz>
	<1226426337.3752.147.camel@beck.corsepiu.local>
	<gfcj76$76a$1@ger.gmane.org>
	<1226428891.3752.167.camel@beck.corsepiu.local>
Message-ID: <385866f0811111048r467af021k12bf218ccd8ac08d@mail.gmail.com>

from http://fedoraproject.org/wiki/Interviews/PreUpgrade

Seth Vidal: However, in a huge number of the cases a yum upgrade
worked fine for updating your distro. I've been updating my laptop for
quite some time that way, lots of people have.

Will Woods: Live upgrades are kind of crazy. It's a
frequently-requested feature, especially from people coming from
Ubuntu or Debian: "Why doesn't Fedora have 'apt-get dist-upgrade'!
It's so simple and easy!"

Well, it's actually not that simple *or* easy. Have you actually read
the 20 pages of directions for preparing for an upgrade[1] ? Or the
11-page-long list of potential problems with performing such an
upgrade[2] ?

Yum upgrades use your (now old and out-of-date) yum, rpm libraries,
kernel, etc. to perform the upgrade. And they do it on a running
system! All sorts of weird things can happen when you upgrade the
entire system while it's running.



From dan at danny.cz  Tue Nov 11 18:50:41 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Tue, 11 Nov 2008 19:50:41 +0100
Subject: starting Fedora Server SIG
Message-ID: <1226429441.3593.77.camel@eagle.danny.cz>

There were many discussions in the past few days and weeks about the
orientation Fedora currently has. It is a fact that currently
Fedora is primarily desktop oriented.

We agree that Desktop is important part of the system, it is highly
visible to the public and large number of Fedora users. But we also see
a large number of Fedora and CentOS users and RHEL customers with very
specific needs and demands. We can not omit the server fundamentals that
later create a successful enterprise product and in our opinion a formal
entity must exist to coordinate these efforts.

That's why we started work on establishing the Fedora Server SIG. The
draft is available at https://fedoraproject.org/wiki/DanHorak/ServerSIG
Any constructive ideas are welcome  :-)


		Dan

-- 
Dan Hor?k
Software Engineer, BaseOS

Red Hat Czech s.r.o., Purky?ova 99, 612 45 Brno



From rdieter at math.unl.edu  Tue Nov 11 18:51:41 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 11 Nov 2008 12:51:41 -0600
Subject: Proposal: Rolling Release
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>
	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com> <insou5xh2j.ln2@ppp1053.in.ipex.cz>
	<1226426337.3752.147.camel@beck.corsepiu.local>
	<gfcj76$76a$1@ger.gmane.org>
	<1226428891.3752.167.camel@beck.corsepiu.local>
Message-ID: <gfck7t$ba9$1@ger.gmane.org>

Ralf Corsepius wrote:

> On Tue, 2008-11-11 at 12:34 -0600, Rex Dieter wrote:
>> Ralf Corsepius wrote:
 
>> <sarcasm>
>> Who really needs all that fedora infrastructure, peer/package review,
>> qa/testing, anyway.  Much easier to skip all that.
>> </sarcasm>

> Well, ... if the fedora infrastructure was really serving contributors,
> if peer/package reviews were functional, if testing was functional, then
> this all would not be an issue.

> The unpleasant truth is: It isn't.

Standard response: how exactly isn't it?  How exactly do you propose to make
it better?

-- Rex




From skvidal at fedoraproject.org  Tue Nov 11 18:51:38 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Tue, 11 Nov 2008 13:51:38 -0500 (EST)
Subject: Proposal: Rolling Release
In-Reply-To: <1226343130.4020.12.camel@localhost.localdomain>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<49185A3C.7050700@cchtml.com> <4918658F.8060709@fedoraproject.org>
	<49186F03.5040008@gmail.com> <491877DC.4010806@fedoraproject.org>
	<1226343130.4020.12.camel@localhost.localdomain>
Message-ID: <alpine.LFD.2.00.0811111350570.20660@localhost.localdomain>



On Mon, 10 Nov 2008, Callum Lerwick wrote:

>
> Filesystem rollback may work for full-distribution upgrade rollback, but
> won't work so well for per-package rollback. A user should be able to
> cherry pick updates to try from "updates-testing", and easily roll back
> individual packages, or their entire system to "updates" or even the
> "fedora" repo should something go wrong.
>
> Debian can do this. The only reason we can not is because we refuse to.


No, debian can't do this. They have the exact same maintainer-scripts 
problem that we have. They just allow users to screw themselves with 
broken maintainer-scripts.

-sv



From seg at haxxed.com  Tue Nov 11 18:53:24 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 11 Nov 2008 12:53:24 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <1226343720.12953.8.camel@luminos.localdomain>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<49185A3C.7050700@cchtml.com>	<4918658F.8060709@fedoraproject.org>
	<49186F03.5040008@gmail.com>  <491877DC.4010806@fedoraproject.org>
	<1226343130.4020.12.camel@localhost.localdomain>
	<1226343720.12953.8.camel@luminos.localdomain>
Message-ID: <1226429604.8532.8.camel@localhost.localdomain>

On Mon, 2008-11-10 at 11:02 -0800, Jesse Keating wrote:
> On Mon, 2008-11-10 at 12:52 -0600, Callum Lerwick wrote:
> > Debian can do this. The only reason we can not is because we refuse
> > to.
> 
> And so far we refuse to be cause we allow free-form scriptlets in rpms.

And as I was trying to point out, this doesn't stop you from
uninstalling a package and installing an older version.

Some concrete examples of scriptlets that would break rollback would be
helpful here. Right now we're in hypothetical handwavy land.

> It would be interesting to see how one would upgrade say mysql major
> version and then roll it back all via packaging.  Something that
> requires changing the on disk format of your databases and such.

We went over this in another thread. We really ought to be packaging
mysql major versions as parallel installable packages.

Or slap upstream(s) with a salmon until they stop changing on-disk
formats in backward-incompatible manners...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081111/8844bab6/attachment.sig>

From walters at verbum.org  Tue Nov 11 19:04:20 2008
From: walters at verbum.org (Colin Walters)
Date: Tue, 11 Nov 2008 14:04:20 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <1226429441.3593.77.camel@eagle.danny.cz>
References: <1226429441.3593.77.camel@eagle.danny.cz>
Message-ID: <faa16b610811111104t464e39c4wa8c099a31b4d4a69@mail.gmail.com>

On Tue, Nov 11, 2008 at 1:50 PM, Dan Hor?k <dan at danny.cz> wrote:
> There were many discussions in the past few days and weeks about the
> orientation Fedora currently has. It is a fact that currently
> Fedora is primarily desktop oriented.
>
> We agree that Desktop is important part of the system, it is highly
> visible to the public and large number of Fedora users. But we also see
> a large number of Fedora and CentOS users and RHEL customers with very
> specific needs and demands. We can not omit the server fundamentals that
> later create a successful enterprise product and in our opinion a formal
> entity must exist to coordinate these efforts.
>
> That's why we started work on establishing the Fedora Server SIG. The
> draft is available at https://fedoraproject.org/wiki/DanHorak/ServerSIG
> Any constructive ideas are welcome  :-)

Sounds like a great idea; as you state, I think it is important to
have a voice for the more conservative server side in Fedora to
counterpoint the fast-moving desktop.

In addition to the list of goals you have there, I would suggest:

* Create an official minimal server spin image, link to it on
fedoraproject.org/get-fedora (when we do this, we can relegate the
choose-your-own-adventure DVD images to a secondary page)
* Consider creating a landing point page for all the admin
technologies in Fedora (kickstart, cobbler, etc.) Does one exist now?

Do you plan to create a mailing list, or use this one?



From lesmikesell at gmail.com  Tue Nov 11 19:07:54 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 11 Nov 2008 13:07:54 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <1226429604.8532.8.camel@localhost.localdomain>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<49185A3C.7050700@cchtml.com>	<4918658F.8060709@fedoraproject.org>	<49186F03.5040008@gmail.com>
	<491877DC.4010806@fedoraproject.org>	<1226343130.4020.12.camel@localhost.localdomain>	<1226343720.12953.8.camel@luminos.localdomain>
	<1226429604.8532.8.camel@localhost.localdomain>
Message-ID: <4919D80A.4020404@gmail.com>

Callum Lerwick wrote:
>
>>> Debian can do this. The only reason we can not is because we refuse
>>> to.
>> And so far we refuse to be cause we allow free-form scriptlets in rpms.
> 
> And as I was trying to point out, this doesn't stop you from
> uninstalling a package and installing an older version.
> 
> Some concrete examples of scriptlets that would break rollback would be
> helpful here. Right now we're in hypothetical handwavy land.
> 
>> It would be interesting to see how one would upgrade say mysql major
>> version and then roll it back all via packaging.  Something that
>> requires changing the on disk format of your databases and such.
> 
> We went over this in another thread. We really ought to be packaging
> mysql major versions as parallel installable packages.

And postgresql, and Sun's javas and python, and everything else that has 
   3rd party and likely user-created content/code that will break and 
needs a period of overlap to fix.

> Or slap upstream(s) with a salmon until they stop changing on-disk
> formats in backward-incompatible manners...

Yea!  At least, don't encourage them by shipping with no tools to help 
migrate gracefully.  And make the people who store stuff in home 
directories understand that they need to run in nfs-mounted homes with 
both new and old releases of their code hitting it at once.

-- 
   Les Mikesell
     lesmikesell at gmail.com





From joshuacov at googlemail.com  Tue Nov 11 19:14:51 2008
From: joshuacov at googlemail.com (Joshua C.)
Date: Tue, 11 Nov 2008 20:14:51 +0100
Subject: F10 Post-Preview snapshots?
Message-ID: <5f6f8c5f0811111114i302752e4pb900c595ef0b0763@mail.gmail.com>

We saw 3 snapshots between f10 beta and f10 preview release. Will
there be any snapshots before f10 final? torrents?

--joshua



From dennis at ausil.us  Tue Nov 11 19:17:11 2008
From: dennis at ausil.us (Dennis Gilmore)
Date: Tue, 11 Nov 2008 13:17:11 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1226429441.3593.77.camel@eagle.danny.cz>
References: <1226429441.3593.77.camel@eagle.danny.cz>
Message-ID: <200811111317.15198.dennis@ausil.us>

On Tuesday 11 November 2008 12:50:41 pm Dan Hor?k wrote:
> There were many discussions in the past few days and weeks about the
> orientation Fedora currently has. It is a fact that currently
> Fedora is primarily desktop oriented.
>
> We agree that Desktop is important part of the system, it is highly
> visible to the public and large number of Fedora users. But we also see
> a large number of Fedora and CentOS users and RHEL customers with very
> specific needs and demands. We can not omit the server fundamentals that
> later create a successful enterprise product and in our opinion a formal
> entity must exist to coordinate these efforts.
>
> That's why we started work on establishing the Fedora Server SIG. The
> draft is available at https://fedoraproject.org/wiki/DanHorak/ServerSIG
> Any constructive ideas are welcome  :-)

I fully agree that there should be a server SIG. When I was at FISL this year 
I was amazed that parts of the Brazilian Govt. run fedora on all of there 
machines, from server to desktop. There is no reason that they couldn't help 
with the server SIG, along with RHEL customers, and anyone else who has an 
intrested in driving forward the direction that Fedora and derivatives move in 
regards to running on servers. I've also run and continue to run fedora 
servers.

If there was a server spin i would think it would be just enough to have yum 
working  there are so many different server purposes. ?I think a better thing 
would be to have kickstart files with different pre-configured systems. ?mail 
server, web server, db server etc. ?along with kickstarts for setting up 
infrastructure, puppet server, dhcp, dns, etc. ?perhaps enhancing system-
config-kickstart with the predefined roles to allow customisation or a web 
version.

Along with kickstarts ?there needs to be whitepapers documenting best 
practices. ?setting up things like func, koan, cobbler. ? showing how the 
whole infrastructure can be managed using best practices and open source 
tools. ?This is where the server SIG can really win.  Fedora Infrastructure is 
a great place to look for a open forward thinking, functional infrastructure 
team

There is also the whole kit and kaboodle of monitoring and alerting, cacti, 
nagios, zabbix. ?then the security monitoring, audit, snort, prelude and 
freinds. ?There is a huge scope to work with.   

Thanks for bringing this forward.

Dennis



From cra at WPI.EDU  Tue Nov 11 19:24:08 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Tue, 11 Nov 2008 14:24:08 -0500
Subject: PackageKit 0.3.10 in Fedora 9
In-Reply-To: <1226421464.3033.80.camel@hughsie-laptop>
References: <1226421464.3033.80.camel@hughsie-laptop>
Message-ID: <20081111192408.GB23749@angus.ind.WPI.EDU>

On Tue, Nov 11, 2008 at 04:37:44PM +0000, Richard Hughes wrote:
> I've just built 0.3.10 for F10 and pushed it to updates-testing:
> 
> https://admin.fedoraproject.org/updates/PackageKit-0.3.10-1.fc9,gnome-packagekit-0.3.10-1.fc9
> 
> I would appreciate some feedback. If you can test the preupgrade
> notification, that would be even better. Thanks.

I updated my F9 system to this then used the PK GUI to enable the 
updates-testing-newkey software repo (I don't know how/why I had that 
disabled--I must have been testing something a long time ago, disabled 
it, and forgot to re-enable it.  Doh.).  I got a bunch of testing 
updates and applied them successfully.  So far so good.

How are we supposed to test the preupgrade notification?  I enabled 
checking for updates every hour, and major upgrades daily.  If I wait 
a day should I see the F10 upgrade appear?



From debarshi.ray at gmail.com  Tue Nov 11 19:26:45 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Wed, 12 Nov 2008 00:56:45 +0530
Subject: Who moved my bug?
In-Reply-To: <tarlu5x85q.ln2@ppp1053.in.ipex.cz>
References: <200811061243.49188.opensource@till.name>
	<1226017819.5758.11.camel@kennedy>
	<20081107111727.GA10541@mokona.greysector.net>
	<200811081419.20620.sgrubb@redhat.com>
	<tarlu5x85q.ln2@ppp1053.in.ipex.cz>
Message-ID: <3170f42f0811111126y4868f99bj9fca37934c880bf0@mail.gmail.com>

> If you really need to distinguish between the bugs which triaged
> (and their future life is a responsibility of a package
> maintainer -- thus they are ASSIGNED as defined by FESCO
> https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow) and
> bugs which you actively work on, I would suggest using status
> ON_DEV -- it is still present in our bugzilla (for legacy
> reasons), but not used for anything, so you can freely use it.

Now that I started using ON_DEV, I find that the "my front page" link
does not list bugs in this state. However, "my bugs" does work. Is
there any reason for this to be so? This is not a major irritation,
but I am curios.

Thanks,
Debarshi



From lesmikesell at gmail.com  Tue Nov 11 19:27:24 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 11 Nov 2008 13:27:24 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <200811111317.15198.dennis@ausil.us>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us>
Message-ID: <4919DC9C.1030009@gmail.com>

Dennis Gilmore wrote:
> 
> If there was a server spin i would think it would be just enough to have yum 
> working  there are so many different server purposes.  I think a better thing 
> would be to have kickstart files with different pre-configured systems. 

That isn't unique to servers.  Is there some reason not to do that in 
general and allow anyone to submit package lists to create machines 
tuned for any purpose?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From vonbrand at inf.utfsm.cl  Tue Nov 11 19:34:02 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 11 Nov 2008 16:34:02 -0300
Subject: Proposal: Rolling Release
In-Reply-To: <4919ADA0.1050900@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>
	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com>
Message-ID: <200811111934.mABJY2ie006851@laptop14.inf.utfsm.cl>

Les Mikesell <lesmikesell at gmail.com> wrote:
> Michael Schwendt wrote:

> > How does that answer my question? Let me repeat. I've asked what
> > policy it is that "forced a horribly fractured 3rd party repository
> > situation"? I'm not aware of any such policy.

> All I can say is that with Ubuntu you can pick vendor drivers and Sun
> Java 1.5 from the software management tool and you almost never have
> to worry about conflicts among packages from the different
> repositories. I've repeatedly requested these things in fedora and
> been repeatedly told it wasn't going to happen.

What the people handling non-Fedora repositories do (or fail to do) is not
Fedora's fault. Go talk to them. Help clarify the "interface" they have to
keep to be able to interoperate cleanly with Fedora. Etc.

Complaining here won't do any good. Fedora's policies are (in large part)
dictated by US (and other) laws. If other distributions believe that they
are inmune to that because of geographical or other reasons, it's their
risk-taking (And I for one like the "no risk" policy of Fedora better than
fearing that some fine day my distribution becomes non viable because it is
being accused of large-scale "software piracy". Remember Linux is what it
is (at least in part) because of the fear around the USL-BSDI-UCB lawsuits).

> > There simply is not enough man-power
> > to spend additional time on coordinating between 3rd party packagers.

If somebody is willing to do the work, I'm certainly not going to stand in
the way. It is much more (and harder) work than what it superficially looks
like, that is all.

> That's something that potential users have to take into account when
> choosing the distro they are going run.

Right.
-- 
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 Nov 11 19:33:45 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 11 Nov 2008 16:33:45 -0300
Subject: Proposal: Rolling Release
In-Reply-To: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
Message-ID: <200811111933.mABJXjdw006843@laptop14.inf.utfsm.cl>

Eric Springer <erikina at gmail.com> wrote:

[...]

> So what I propose is that Fedora goes to a rolling release cycle.
> Implemented properly I believe we can better achieve Fedoras
> objectives[3] of rapidly progressing Free Open Source Software, while
> providing a more user centric focus (and bringing something new to the
> easy-to-use-table). While I would prefer to not get bogged down in the
> technical details at this stage, we would need to provide software in
> varying levels of stability.
> 
> Perhaps something like:
> hemorrhaging -> rawhide -> stable -> rocksolid
> 
> Users should be able to very easily and freely move through the
> levels, especially on a per-package basis (with PackageKit). It should
> also be easy for users to "freeze" their system/package to only
> receive security (and optionally bug) patches, as many aren't
> interested in the constant upgrade cycle.

If you do it across the board, you have rawhide/Fedora du annee/Fedora d
l'annee derniere. And the unending flamewar on Fedora legacy has amply
shown /nobody/ is interested beyond that.

If you want to mix&match, you get a mess that nobody can do any sane QA on.

> New features/software/functionality would be easily tested by the
> masses without needing to upgrade the entire distribution.

They have a knack at involving the whole distribution (i.e., use
NetworkManager and all the other new, automated stuff is on or off; and
impacts much other stuff. Keeping both around is double work, double QA,
double (or more) bugreports to triage, ... Just not worth the (very minor)
advantage. Plus /really/ enterprising users do install stuff from latest
upstream commit and futz around with that. Sure, they (hopefully) won't
come around here reporting on their experiences...).

>                                                            It would
> give the open source community a massive user-base they could call
> upon to test easily.

Sorry, said _user_-base wants to _use_ the system, not play guinea
pig. Those insane enough to want to, can use rawhide.
-- 
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 seg at haxxed.com  Tue Nov 11 19:37:02 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 11 Nov 2008 13:37:02 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <4919ADA0.1050900@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com>
Message-ID: <1226432222.8532.16.camel@localhost.localdomain>

On Tue, 2008-11-11 at 10:06 -0600, Les Mikesell wrote:
> All I can say is that with Ubuntu you can pick vendor drivers and Sun 
> Java 1.5 from the software management tool and you almost never have to 
> worry about conflicts among packages from the different repositories. 
> I've repeatedly requested these things in fedora and been repeatedly 
> told it wasn't going to happen.

Are you completely retarded or just autistic? The reasons for these
things have been explained to you ten times over, yet you show no sign
of understanding.

If you love Ubuntu so much, please, go marry it and GTFO.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081111/f8d68b23/attachment.sig>

From vonbrand at inf.utfsm.cl  Tue Nov 11 19:48:15 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 11 Nov 2008 16:48:15 -0300
Subject: Automatic BuildRequires
In-Reply-To: <200811091553.03271.dennis@ausil.us>
References: <20081106110142.GA3165@amd.home.annexia.org>
	<1225970138.4625.15.camel@ignacio.lan>
	<20081106111649.GB3165@amd.home.annexia.org>
	<200811091553.03271.dennis@ausil.us>
Message-ID: <200811111948.mABJmFvn007059@laptop14.inf.utfsm.cl>

Dennis Gilmore <dennis at ausil.us> wrote:

[...]

> Thats what mock on your local system is for.  Please don't abuse koji by
> doing that.  if you have it right on one arch using scratch builds in
> koji to test all arches is appropriate. but not to work out missing
> BuildRequires.  Again please be thoughtful with the resources fedora
> provides they are not infinite.

Last time I tried to use mock it spent 10 times as much resources setting
up the same environment over and over than doing useful work. Gave up.
-- 
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 jarod at redhat.com  Tue Nov 11 19:55:07 2008
From: jarod at redhat.com (Jarod Wilson)
Date: Tue, 11 Nov 2008 14:55:07 -0500
Subject: Automatic BuildRequires
In-Reply-To: <200811111948.mABJmFvn007059@laptop14.inf.utfsm.cl>
References: <20081106110142.GA3165@amd.home.annexia.org>
	<200811091553.03271.dennis@ausil.us>
	<200811111948.mABJmFvn007059@laptop14.inf.utfsm.cl>
Message-ID: <200811111455.07310.jarod@redhat.com>

On Tuesday 11 November 2008 14:48:15 Horst H. von Brand wrote:
> Dennis Gilmore <dennis at ausil.us> wrote:
>
> [...]
>
> > Thats what mock on your local system is for.  Please don't abuse koji by
> > doing that.  if you have it right on one arch using scratch builds in
> > koji to test all arches is appropriate. but not to work out missing
> > BuildRequires.  Again please be thoughtful with the resources fedora
> > provides they are not infinite.
>
> Last time I tried to use mock it spent 10 times as much resources setting
> up the same environment over and over than doing useful work. Gave up.

*cough* mock --no-clean *cough*

-- 
Jarod Wilson
jarod at redhat.com



From jkeating at redhat.com  Tue Nov 11 19:57:13 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 11 Nov 2008 11:57:13 -0800
Subject: F10 Post-Preview snapshots?
In-Reply-To: <5f6f8c5f0811111114i302752e4pb900c595ef0b0763@mail.gmail.com>
References: <5f6f8c5f0811111114i302752e4pb900c595ef0b0763@mail.gmail.com>
Message-ID: <1226433433.10458.8.camel@luminos.localdomain>

On Tue, 2008-11-11 at 20:14 +0100, Joshua C. wrote:
> We saw 3 snapshots between f10 beta and f10 preview release. Will
> there be any snapshots before f10 final? torrents?

No, please use rawhide for that.

-- 
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/20081111/1fd04d5e/attachment.sig>

From jkeating at redhat.com  Tue Nov 11 19:59:14 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 11 Nov 2008 11:59:14 -0800
Subject: Automatic BuildRequires
In-Reply-To: <200811111948.mABJmFvn007059@laptop14.inf.utfsm.cl>
References: <20081106110142.GA3165@amd.home.annexia.org>
	<1225970138.4625.15.camel@ignacio.lan>
	<20081106111649.GB3165@amd.home.annexia.org>
	<200811091553.03271.dennis@ausil.us>
	<200811111948.mABJmFvn007059@laptop14.inf.utfsm.cl>
Message-ID: <1226433555.10458.10.camel@luminos.localdomain>

On Tue, 2008-11-11 at 16:48 -0300, Horst H. von Brand wrote:
> 
> Last time I tried to use mock it spent 10 times as much resources setting
> up the same environment over and over than doing useful work. Gave up.

Use mock caching of packages, use caching of buildroots, use ramdisk
chroots, etc...

A local mock build once packages et al are cached is going to be far
faster than waiting for an upload to koji and a build in that
environment, because koji is using mock 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/20081111/5dea5371/attachment.sig>

From martin.langhoff at gmail.com  Tue Nov 11 20:06:07 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Tue, 11 Nov 2008 15:06:07 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <1226429441.3593.77.camel@eagle.danny.cz>
References: <1226429441.3593.77.camel@eagle.danny.cz>
Message-ID: <46a038f90811111206k324e962cu4153c818647b88df@mail.gmail.com>

On Tue, Nov 11, 2008 at 1:50 PM, Dan Hor?k <dan at danny.cz> wrote:
> There were many discussions in the past few days and weeks about the
> orientation Fedora currently has. It is a fact that currently
> Fedora is primarily desktop oriented.

I am definitely interested in this track. Right now in the middle of a
release of the OLPC School Server (so a bit swamped) but count me in.

Server tasks deserve love and attention, and make Fedora viable in
low-end and embedded platforms as well.

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 emmanuel.seyman at club-internet.fr  Tue Nov 11 20:16:15 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Tue, 11 Nov 2008 21:16:15 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <4919C64B.3010606@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>
	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com> <4919C409.4060401@fedoraproject.org>
	<4919C64B.3010606@gmail.com>
Message-ID: <20081111201615.GA15724@orient.maison.lan>

* Les Mikesell [11/11/2008 19:20] :
>
> I meant redistributable drivers, of course.

This is confusing as well. All the drivers shipped with the kernel and
xorg are redistributable, after all.

Emmanuel



From lesmikesell at gmail.com  Tue Nov 11 20:26:26 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 11 Nov 2008 14:26:26 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <200811111934.mABJY2ie006851@laptop14.inf.utfsm.cl>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>
	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com>
	<200811111934.mABJY2ie006851@laptop14.inf.utfsm.cl>
Message-ID: <4919EA72.7040900@gmail.com>

Horst H. von Brand wrote:
> 
> What the people handling non-Fedora repositories do (or fail to do) is not
> Fedora's fault. Go talk to them. Help clarify the "interface" they have to
> keep to be able to interoperate cleanly with Fedora. Etc.

I want to run applications and my own code.  Fedora I can take or leave. 


> Complaining here won't do any good. Fedora's policies are (in large part)
> dictated by US (and other) laws.

And I have generally been talking about things that are legal to 
redistribute.  I don't believe Debian breaks any laws in packaging Sun 
Java 1.5 and having a java-sun-compat wouldn't have broken any.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From emmanuel.seyman at club-internet.fr  Tue Nov 11 20:47:17 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Tue, 11 Nov 2008 21:47:17 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <4919BE5C.9050001@gmail.com>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>
	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com>
	<16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>
	<4919B525.3070300@gmail.com>
	<1226422090.3417.23.camel@localhost.localdomain>
	<4919BE5C.9050001@gmail.com>
Message-ID: <20081111204717.GB15724@orient.maison.lan>

* Les Mikesell [11/11/2008 19:20] :
>
>       The problem is that Fedora does not admit that users need things  
> that are not included in the box, does nothing to co-operate with others  
> that would provide them, and by shipping a wildly moving target with no  
> coordination, actively breaks everything others even attempt to do in  
> this regard.

Fedora releases betas, snapshots and previews of a version of its
distribution before its release, as well as allowing anyone to run
Rawhide. Developement is done in the open and all mailing lists are
public.

Saying that Fedora "does nothing to co-operate with others" and ships "a
wildly moving target" is a straw man.

Emmanuel



From dledford at redhat.com  Tue Nov 11 21:09:22 2008
From: dledford at redhat.com (Doug Ledford)
Date: Tue, 11 Nov 2008 16:09:22 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <1226429441.3593.77.camel@eagle.danny.cz>
References: <1226429441.3593.77.camel@eagle.danny.cz>
Message-ID: <1226437763.4765.49.camel@firewall.xsintricity.com>

On Tue, 2008-11-11 at 19:50 +0100, Dan Hor?k wrote:
> There were many discussions in the past few days and weeks about the
> orientation Fedora currently has. It is a fact that currently
> Fedora is primarily desktop oriented.
> 
> We agree that Desktop is important part of the system, it is highly
> visible to the public and large number of Fedora users. But we also see
> a large number of Fedora and CentOS users and RHEL customers with very
> specific needs and demands. We can not omit the server fundamentals that
> later create a successful enterprise product and in our opinion a formal
> entity must exist to coordinate these efforts.
> 
> That's why we started work on establishing the Fedora Server SIG. The
> draft is available at https://fedoraproject.org/wiki/DanHorak/ServerSIG
> Any constructive ideas are welcome  :-)

I'll help.

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081111/4bce3494/attachment.sig>

From mschwendt at gmail.com  Tue Nov 11 20:40:27 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 11 Nov 2008 21:40:27 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <4919C670.6090506@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>
	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com>
	<20081111181707.8fa55669.mschwendt@gmail.com>
	<4919C670.6090506@gmail.com>
Message-ID: <20081111214027.176e8bb0.mschwendt@gmail.com>

On Tue, 11 Nov 2008 11:52:48 -0600, Les Mikesell wrote:

> Ubuntu does not have the same exclusionary 
> policy so you don't have to track down packages from a million 
> uncoordinated places.

Yet they have created Gobuntu and the new installer option for using
"open-source non-restricted software" only, which I consider an option
for end-users, who want to stay on the safe side and avoid the threat
of legal/patenting/licencing issues.

I think you're struggling to draw a connection between legal requirements
in Fedora and 3rd party repos which don't work together. It's the Fedora
community's fault that incompatible repos are offered and advertised in
community support places. Another trend is to publish and advertise
personal repositories of small sets of packages instead of working a
little bit harder on getting the stuff included in Fedora. You can find
people who offer "fixes" that way (replacement packages, unofficial
upgrades) or add-ons, which could be included in Fedora. Of course,
a personal repo is much more convenient.

> > Dependency
> > problems and inter-repository issues are not specific to Fedora or RPM.
> > Experimental upgrades/replacements/alternatives, orphans, and poorly
> > maintained packages do exist for other dists, too, not just in 3rd
> > party repos.
> 
> Of course that can happen - Fedora just makes it impossible not to happen.

Not impossible.

Actually, the Fedora policies are not adhered to in many cases when
packages break the ABI/API (and hence break compatibility with 3rd party
repos). Add to that the normal regression caused by version upgrades.
It's the packagers who are over-ambitious in publishing the latest
upstream releases without appropriate testing. You would think they would
test for binary incompatibility. No, they don't. And those who do won't
search for--and get in contact with--an unknown number of 3rd party repos
that may be considered relevant/popular/whatever in the Fedora universe.
And it's the insatiable (and impatient) target group who requests version
upgrades, as the dist gets boring without hot+new+exciting stuff.

I'm not a fan of "bleeding edge at all cost" in case you don't know. ;)

> on my laptop Ubuntu installs the right 
> video and wireless driver and lets me pick Sun java from the GUI 
> software tool.  Fedora doesn't.

You're free to choose, especially if you have very specific preferences.
A couple of months in the future it may already be different again.

> When I've installed fedora, I've had 
> to track down the components myself and had them break regularly during 
> updates.

What issues? What bugzilla ticket numbers?

> You are seriously underestimating users if you don't think they are 
> capable of trying a few distros and tossing the ones that break.

Well, I'm watching them as they either jump to false conclusions
(e.g. comparing dist ABC v5 with dist XYZ v6) or discover after some time
that the big (well-known) dists have different strengths and weaknesses,
and that they are not fully happy with either dist. Or some would swear that
App 1.2.3 in dist ABC works while exactly the same App version in dist XYZ
doesn't -- only to learn later that both are affected by the same problem
actually as confirmed by the maintainers.

> Fedora forces the replacement issue regularly anyway with its fast
> expiration cycle.

There's nothing wrong in using CentOS. Even [online] upgrades of Fedora
work fine for users. I have no reason to believe that Fedora could easily
enlengthen its dist life-cycle.

I've cut off the bottom of the mail as I don't see the goal of this
sub-thread.



From limb at jcomserv.net  Tue Nov 11 21:12:22 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Tue, 11 Nov 2008 15:12:22 -0600 (CST)
Subject: starting Fedora Server SIG
In-Reply-To: <1226429441.3593.77.camel@eagle.danny.cz>
References: <1226429441.3593.77.camel@eagle.danny.cz>
Message-ID: <312e361df9b78ba2da71a71ffd6a6522.squirrel@mail.jcomserv.net>


> There were many discussions in the past few days and weeks about the
> orientation Fedora currently has. It is a fact that currently
> Fedora is primarily desktop oriented.
>
> We agree that Desktop is important part of the system, it is highly
> visible to the public and large number of Fedora users. But we also see
> a large number of Fedora and CentOS users and RHEL customers with very
> specific needs and demands. We can not omit the server fundamentals that
> later create a successful enterprise product and in our opinion a formal
> entity must exist to coordinate these efforts.
>
> That's why we started work on establishing the Fedora Server SIG. The
> draft is available at https://fedoraproject.org/wiki/DanHorak/ServerSIG
> Any constructive ideas are welcome  :-)

I'm in.  I run a side business on all Fedora servers.  People think I'm
nuts.  I love the up-to-date software and stability.  And I upgrade via
yum. :)

>
> 		Dan
>
> --
> Dan Hor??k
> Software Engineer, BaseOS
>
> Red Hat Czech s.r.o., Purky??ova 99, 612 45 Brno
>
> --
> 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 lesmikesell at gmail.com  Tue Nov 11 21:23:17 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 11 Nov 2008 15:23:17 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <20081111204717.GB15724@orient.maison.lan>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>	<49190741.6090902@gmail.com>	<20081111090721.928d792a.mschwendt@gmail.com>	<49198DC9.3030609@gmail.com>	<20081111161642.711a1d5d.mschwendt@gmail.com>	<4919ADA0.1050900@gmail.com>	<16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>	<4919B525.3070300@gmail.com>	<1226422090.3417.23.camel@localhost.localdomain>	<4919BE5C.9050001@gmail.com>
	<20081111204717.GB15724@orient.maison.lan>
Message-ID: <4919F7C5.1090705@gmail.com>

Emmanuel Seyman wrote:
> * Les Mikesell [11/11/2008 19:20] :
>>       The problem is that Fedora does not admit that users need things  
>> that are not included in the box, does nothing to co-operate with others  
>> that would provide them, and by shipping a wildly moving target with no  
>> coordination, actively breaks everything others even attempt to do in  
>> this regard.
> 
> Fedora releases betas, snapshots and previews of a version of its
> distribution before its release, as well as allowing anyone to run
> Rawhide. Developement is done in the open and all mailing lists are
> public.
> 
> Saying that Fedora "does nothing to co-operate with others" and ships "a
> wildly moving target" is a straw man.

Which repos have a chance to rebuild against new fedora libraries before 
they are publicly available so a user updating with both enabled won't 
experience conflicts?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From loganjerry at gmail.com  Tue Nov 11 21:24:46 2008
From: loganjerry at gmail.com (Jerry James)
Date: Tue, 11 Nov 2008 14:24:46 -0700
Subject: Filtering -fstack-protector out of CFLAGS
In-Reply-To: <20081111164256.GA20349@amd.home.annexia.org>
References: <870180fe0811110721n40d90907od33b24f93183ead6@mail.gmail.com>
	<20081111164256.GA20349@amd.home.annexia.org>
Message-ID: <870180fe0811111324w1d1fc232lb2c730906feed828@mail.gmail.com>

On Tue, Nov 11, 2008 at 9:42 AM, Richard W.M. Jones <rjones at redhat.com> wrote:
> We used to do something like this for the MinGW packages, since
> -fstack-protector also causes a problem under Windows / MinGW
> cross-compilation:
>
>  CFLAGS="$RPM_OPT_FLAGS -fno-stack-protector" \
>  ./configure [etc]

I've adopted this approach.  Thank you.  Thanks also to Ajax and Ralf
for their replies.
-- 
Jerry James
http://loganjerry.googlepages.com/



From bpepple at fedoraproject.org  Tue Nov 11 21:27:19 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 11 Nov 2008 16:27:19 -0500
Subject: Plan for tomorrows (20081112) FESCO meeting
Message-ID: <1226438839.26212.2.camel@kennedy>

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 -- F10 Release/Blockers Status - 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/20081111/63523490/attachment.sig>

From notting at redhat.com  Tue Nov 11 21:28:04 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 11 Nov 2008 16:28:04 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <91705d080811101440t9c5e80ai7c895835e76eb625@mail.gmail.com>
References: <20081029215123.GL25197@nostromo.devel.redhat.com>
	<91705d080810291533o7a7f3a5dl1cbcbef4fa3498c8@mail.gmail.com>
	<20081030154405.GA12240@nostromo.devel.redhat.com>
	<91705d080810301155q487a968qc91be14ecdc6909d@mail.gmail.com>
	<20081030202920.GB31153@nostromo.devel.redhat.com>
	<91705d080810301410h415f6e4fj6fbf881eada2f69d@mail.gmail.com>
	<20081031202054.GB8150@nostromo.devel.redhat.com>
	<91705d080810311401gdc85e93i1bd182ce56976bb3@mail.gmail.com>
	<20081110214901.GA14463@nostromo.devel.redhat.com>
	<91705d080811101440t9c5e80ai7c895835e76eb625@mail.gmail.com>
Message-ID: <20081111212804.GA11450@nostromo.devel.redhat.com>

Dan Nicholson (dbn.lists at gmail.com) said: 
> > Further testing with this is giving me some bizarre errors and hangs
> > relating to VT switching that don't happen with this patchset backed
> > out. Unless I can track those down, I can't really recommend using
> > it.
> 
> Without doing anything from event.d, there's nothing on tty1 for the
> `telinit 5' from runlevel 3 case, right? I don't want you to use a
> broken patch, but I do think the current behavior is wrong.

It's 'wrong', but it's predictably wrong without side-effects on the
rest of the interface (crash, hang, etc.) and easily explained what
to do. At this stage of the release cycle, that's better than a patch
that fixes it for some cases and does really bizarre things in ways
that I haven't characterized yet. (I've seen hangs in the VT switch
code, and I can reliably reproduce a condition where the console
is perfectly fine... but not actually updating on the screen.)
Still poking at it, though.

Bill



From jkeating at redhat.com  Tue Nov 11 21:42:20 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 11 Nov 2008 13:42:20 -0800
Subject: Proposal: Rolling Release
In-Reply-To: <4919F7C5.1090705@gmail.com>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com>
	<16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>
	<4919B525.3070300@gmail.com>
	<1226422090.3417.23.camel@localhost.localdomain>
	<4919BE5C.9050001@gmail.com> <20081111204717.GB15724@orient.maison.lan>
	<4919F7C5.1090705@gmail.com>
Message-ID: <1226439740.10458.15.camel@luminos.localdomain>

On Tue, 2008-11-11 at 15:23 -0600, Les Mikesell wrote:
> 
> Which repos have a chance to rebuild against new fedora libraries before 
> they are publicly available so a user updating with both enabled won't 
> experience conflicts?

Every repo.  Our build roots are public and static repo locations are
updated hourly with their contents.  It's all public, anybody in the
would can access 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/20081111/37178161/attachment.sig>

From mschwendt at gmail.com  Tue Nov 11 21:43:36 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 11 Nov 2008 22:43:36 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <4919F7C5.1090705@gmail.com>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>
	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com>
	<16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>
	<4919B525.3070300@gmail.com>
	<1226422090.3417.23.camel@localhost.localdomain>
	<4919BE5C.9050001@gmail.com>
	<20081111204717.GB15724@orient.maison.lan>
	<4919F7C5.1090705@gmail.com>
Message-ID: <20081111224336.c8008b5f.mschwendt@gmail.com>

On Tue, 11 Nov 2008 15:23:17 -0600, Les Mikesell wrote:

> Which repos have a chance to rebuild against new fedora libraries before 
> they are publicly available so a user updating with both enabled won't 
> experience conflicts?

That's what updates-testing is for, in particular if rebuilds of
dependencies will be necessary.



From james at fedoraproject.org  Tue Nov 11 21:46:06 2008
From: james at fedoraproject.org (James Antill)
Date: Tue, 11 Nov 2008 16:46:06 -0500
Subject: Proposal: Rolling Release
In-Reply-To: <1dedbbfc0811110930y294ce663ld396b2000f083dba@mail.gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<loom.20081111T010408-920@post.gmane.org>
	<20081111160318.GF22663@nostromo.devel.redhat.com>
	<1dedbbfc0811110930y294ce663ld396b2000f083dba@mail.gmail.com>
Message-ID: <1226439966.22230.104.camel@code.and.org>

On Tue, 2008-11-11 at 18:30 +0100, David Nielsen wrote:
> 
> And if it's deemed stable enough for F10 as a release then surely it
> should be stable enough as an update for F9.

 Are you insane?
 What kind of world do you live in where shipping something in X GA is
held to the exact same standard as shipping it in X-1 that's been
released for 6 months?

-- 
James Antill <james at fedoraproject.org>
Fedora



From poelstra at redhat.com  Tue Nov 11 21:50:51 2008
From: poelstra at redhat.com (John Poelstra)
Date: Tue, 11 Nov 2008 13:50:51 -0800
Subject: Plan for tomorrows (20081112) FESCO meeting
In-Reply-To: <1226438839.26212.2.camel@kennedy>
References: <1226438839.26212.2.camel@kennedy>
Message-ID: <4919FE3B.1070602@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 -- F10 Release/Blockers Status - 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
> 

I would like to discuss 
https://fedoraproject.org/wiki/Features/F11PolicyReview and propose that 
FESCo start review Fedora 11 features next week, time permitting.

John



From emmanuel.seyman at club-internet.fr  Tue Nov 11 21:52:05 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Tue, 11 Nov 2008 22:52:05 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <4919F7C5.1090705@gmail.com>
References: <20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com>
	<16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>
	<4919B525.3070300@gmail.com>
	<1226422090.3417.23.camel@localhost.localdomain>
	<4919BE5C.9050001@gmail.com>
	<20081111204717.GB15724@orient.maison.lan>
	<4919F7C5.1090705@gmail.com>
Message-ID: <20081111215205.GA17407@orient.maison.lan>

* Les Mikesell [11/11/2008 22:40] :
>
> Which repos have a chance to rebuild against new fedora libraries before  
> they are publicly available so a user updating with both enabled won't  
> experience conflicts?

???
All of them. New Fedora libraries are always publicly available and
there's no "before" phase.

Freshrpms and Livna have released third party repos on the same day as
the Fedora release they targeted. Rpmfusion is planning the same thing
for Fedora 10 so I'm not sure there's a point in arguing that this is
impossible.

Emmanuel



From sundaram at fedoraproject.org  Tue Nov 11 21:54:20 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 12 Nov 2008 03:24:20 +0530
Subject: Proposal: Rolling Release
In-Reply-To: <4919C64B.3010606@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>	<49190741.6090902@gmail.com>	<20081111090721.928d792a.mschwendt@gmail.com>	<49198DC9.3030609@gmail.com>	<20081111161642.711a1d5d.mschwendt@gmail.com>	<4919ADA0.1050900@gmail.com>	<4919C409.4060401@fedoraproject.org>
	<4919C64B.3010606@gmail.com>
Message-ID: <4919FF0C.8000105@fedoraproject.org>

Les Mikesell wrote:
> Rahul Sundaram wrote:
>>
>>>> How does that answer my question? Let me repeat. I've asked what 
>>>> policy it
>>>> is that "forced a horribly fractured 3rd party repository 
>>>> situation"? I'm
>>>> not aware of any such policy.
>>>
>>> All I can say is that with Ubuntu you can pick vendor drivers and Sun 
>>> Java 1.5 from the software management tool and you almost never have 
>>> to worry about conflicts among packages from the different repositories. 
>>
>> If you meant proprietary drivers, just say it. "vendor drivers" is 
>> confusing since several of the drivers in the kernel and xorg are 
>> vendor supported and developed and available in the repository without 
>> conflicts.
> 
> I meant redistributable drivers, of course.

"Redistributable" is again unclear. If you meant, proprietary drivers, 
they aren't always redistributable and even otherwise, their legality is 
a grey area. The open source drivers are redistributable and are being 
distributed.

Rahul



From nicolas.mailhot at laposte.net  Tue Nov 11 21:57:56 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 11 Nov 2008 22:57:56 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <1226439740.10458.15.camel@luminos.localdomain>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com>
	<16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>
	<4919B525.3070300@gmail.com>
	<1226422090.3417.23.camel@localhost.localdomain>
	<4919BE5C.9050001@gmail.com> <20081111204717.GB15724@orient.maison.lan>
	<4919F7C5.1090705@gmail.com>
	<1226439740.10458.15.camel@luminos.localdomain>
Message-ID: <1226440676.31847.0.camel@arekh.okg>

Le mardi 11 novembre 2008 ? 13:42 -0800, Jesse Keating a ?crit :
> On Tue, 2008-11-11 at 15:23 -0600, Les Mikesell wrote:
> > 
> > Which repos have a chance to rebuild against new fedora libraries before 
> > they are publicly available so a user updating with both enabled won't 
> > experience conflicts?
> 
> Every repo.  Our build roots are public and static repo locations are
> updated hourly with their contents.  It's all public, anybody in the
> would can access it.

BTW do we have koji static repos for debuginfo packages?

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081111/50efd100/attachment.sig>

From jkeating at redhat.com  Tue Nov 11 22:07:29 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 11 Nov 2008 14:07:29 -0800
Subject: Proposal: Rolling Release
In-Reply-To: <1226440676.31847.0.camel@arekh.okg>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com>
	<16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>
	<4919B525.3070300@gmail.com>
	<1226422090.3417.23.camel@localhost.localdomain>
	<4919BE5C.9050001@gmail.com> <20081111204717.GB15724@orient.maison.lan>
	<4919F7C5.1090705@gmail.com>
	<1226439740.10458.15.camel@luminos.localdomain>
	<1226440676.31847.0.camel@arekh.okg>
Message-ID: <1226441249.10458.16.camel@luminos.localdomain>

On Tue, 2008-11-11 at 22:57 +0100, Nicolas Mailhot wrote:
> BTW do we have koji static repos for debuginfo packages?

Not at this time, but it's not all that difficult to fetch what you need
out of koji directly.

-- 
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/20081111/ffd98a5b/attachment.sig>

From rakesh.pandit at gmail.com  Tue Nov 11 22:14:10 2008
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Wed, 12 Nov 2008 03:44:10 +0530
Subject: Package Review SIG Meeting Summary 2008-10-23
In-Reply-To: <1225135895.21297.7.camel@kennedy>
References: <1225135895.21297.7.camel@kennedy>
Message-ID: <b401d2530811111414t479b09f7sfad106b778f5d2dd@mail.gmail.com>

2008/10/28 Brian Pepple <bpepple at fedoraproject.org>:
> === Present ===
> * Brian Pepple          (bpepple)
> * Jon Ciesla            (limburgher)
> * Rakesh Pandit         (chacha_chaudry)
> * Kushal Das            (kushal)
> * Jason Tibbitts        (ubertibbs)
> * Rex Dieter            (rdieter)
>
> == Summary ==
> === Package Review Statistics ===
>      * bpepple, limburger, and chacha_chaudhry will work on a script to
>        generate weekly package review statistics.
>
> === Brain-Storming ===
>      * The group brain-stormed for a bit on ways to improve
>        participation in package reviews.  Some ideas were:
>             1. Monthly (or some other time frame) swag drawing for
>                folks that complete a certain number of reviews in a
>                month.

Looking at what we already had in scripts, I thought it would be time
saving to write new one which generates timespan reports:

http://rakesh.fedorapeople.org/misc/bugzillaReport.py

Right now it just counts the number of reviews done by each reviewer,
reviews undergoing review, or new packages submitted, all of them in a
timespan supplied by user. Presenting bug number in review wouldn't be
a big problem. Any suggestions are welcome and bugs also (I have just
tested for reviews done against reviewers for a week.)

-- 
rakesh



From nicolas.mailhot at laposte.net  Tue Nov 11 22:18:45 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 11 Nov 2008 23:18:45 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <1226441249.10458.16.camel@luminos.localdomain>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com>
	<16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>
	<4919B525.3070300@gmail.com>
	<1226422090.3417.23.camel@localhost.localdomain>
	<4919BE5C.9050001@gmail.com> <20081111204717.GB15724@orient.maison.lan>
	<4919F7C5.1090705@gmail.com>
	<1226439740.10458.15.camel@luminos.localdomain>
	<1226440676.31847.0.camel@arekh.okg>
	<1226441249.10458.16.camel@luminos.localdomain>
Message-ID: <1226441925.31847.2.camel@arekh.okg>

Le mardi 11 novembre 2008 ? 14:07 -0800, Jesse Keating a ?crit :
> On Tue, 2008-11-11 at 22:57 +0100, Nicolas Mailhot wrote:
> > BTW do we have koji static repos for debuginfo packages?
> 
> Not at this time, but it's not all that difficult to fetch what you need
> out of koji directly.

Sure, it's not difficult. But recursing manually through debuginfo
packages is no fun.

-- 
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/20081111/d4b44a83/attachment.sig>

From gnomeuser at gmail.com  Tue Nov 11 22:19:32 2008
From: gnomeuser at gmail.com (David Nielsen)
Date: Tue, 11 Nov 2008 23:19:32 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <20081111214027.176e8bb0.mschwendt@gmail.com>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>
	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com>
	<20081111181707.8fa55669.mschwendt@gmail.com>
	<4919C670.6090506@gmail.com>
	<20081111214027.176e8bb0.mschwendt@gmail.com>
Message-ID: <1dedbbfc0811111419u145a44d6iaa411008d14b578a@mail.gmail.com>

2008/11/11 Michael Schwendt <mschwendt at gmail.com>

> On Tue, 11 Nov 2008 11:52:48 -0600, Les Mikesell wrote:
>
> > Ubuntu does not have the same exclusionary
> > policy so you don't have to track down packages from a million
> > uncoordinated places.
>
> Yet they have created Gobuntu and the new installer option for using
> "open-source non-restricted software" only, which I consider an option
> for end-users, who want to stay on the safe side and avoid the threat
> of legal/patenting/licencing issues.
>

Actually, they stopped working on Gobuntu, it is no longer a supported not a
distributed part of the Ubuntu family. Apparently they did not gather enough
volunteers to keep up the project so Mark effectively shut it down. People
are requested to use gNewSense instead which is also an Ubuntu remix without
nonfree elements present (and blessed by Stallman if I am not mistaken).

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081111/6c5c0c52/attachment.htm>

From jkeating at redhat.com  Tue Nov 11 22:26:07 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 11 Nov 2008 14:26:07 -0800
Subject: Proposal: Rolling Release
In-Reply-To: <1226441925.31847.2.camel@arekh.okg>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com>
	<16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>
	<4919B525.3070300@gmail.com>
	<1226422090.3417.23.camel@localhost.localdomain>
	<4919BE5C.9050001@gmail.com> <20081111204717.GB15724@orient.maison.lan>
	<4919F7C5.1090705@gmail.com>
	<1226439740.10458.15.camel@luminos.localdomain>
	<1226440676.31847.0.camel@arekh.okg>
	<1226441249.10458.16.camel@luminos.localdomain>
	<1226441925.31847.2.camel@arekh.okg>
Message-ID: <1226442367.10458.17.camel@luminos.localdomain>

On Tue, 2008-11-11 at 23:18 +0100, Nicolas Mailhot wrote:
> Sure, it's not difficult. But recursing manually through debuginfo
> packages is no fun.

Neither is taking on another 10~ minutes or so to each repo creation run
in koji (:

-- 
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/20081111/4874c63a/attachment.sig>

From bruno at wolff.to  Tue Nov 11 22:26:53 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Tue, 11 Nov 2008 16:26:53 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <20081110182458.GE30058@dspnet.fr.eu.org>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<49185A3C.7050700@cchtml.com>
	<20081110182458.GE30058@dspnet.fr.eu.org>
Message-ID: <20081111222653.GA23642@wolff.to>

On Mon, Nov 10, 2008 at 19:24:58 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> On Mon, Nov 10, 2008 at 09:58:52AM -0600, Michael Cronenworth wrote:
> > It just needs to be turned into a mandatory update tool with PackageKit. 
> >  Joe Enduser needs to be able to click "Update Me!" and go from Fedora 
> > 9 to Fedora 10 with a single click.
> 
> Can I update from up-to-date fedora N to fedora N+1 through a command
> line ssh connection now?  Or is that still unsupported?

It might work.

> And if yes, how?  Is it just changing the repository to N+1 and yum
> update?

Yes. (Well you would want to use yum upgrade, but on Fedora the default
is to have obsoletes=1 . You might also want to have skip_broken=1 .
Afterwords you'll want to check for orphaned packages and do something with
them. You can use package-cleanup --orphans to get a list.



From sundaram at fedoraproject.org  Tue Nov 11 22:36:35 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 12 Nov 2008 04:06:35 +0530
Subject: starting Fedora Server SIG
In-Reply-To: <4919DC9C.1030009@gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>	<200811111317.15198.dennis@ausil.us>
	<4919DC9C.1030009@gmail.com>
Message-ID: <491A08F3.7040503@fedoraproject.org>

Les Mikesell wrote:
> Dennis Gilmore wrote:
>>
>> If there was a server spin i would think it would be just enough to 
>> have yum working  there are so many different server purposes.  I 
>> think a better thing would be to have kickstart files with different 
>> pre-configured systems. 
> 
> That isn't unique to servers.  Is there some reason not to do that in 
> general and allow anyone to submit package lists to create machines 
> tuned for any purpose?

Nothing except people like you with an interest should volunteer and 
participate.

Rahul



From bpepple at fedoraproject.org  Tue Nov 11 23:16:22 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 11 Nov 2008 18:16:22 -0500
Subject: Plan for tomorrows (20081112) FESCO meeting
In-Reply-To: <4919FE3B.1070602@redhat.com>
References: <1226438839.26212.2.camel@kennedy> <4919FE3B.1070602@redhat.com>
Message-ID: <1226445382.3255.10.camel@kennedy>

On Tue, 2008-11-11 at 13:50 -0800, John Poelstra wrote:
> I would like to discuss 
> https://fedoraproject.org/wiki/Features/F11PolicyReview and propose that 
> FESCo start review Fedora 11 features next week, time permitting.

Added to the schedule.  Also, I don't think it will be a problem
starting the F11 feature reviews next week.

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/20081111/617dc587/attachment.sig>

From camilo at mesias.co.uk  Wed Nov 12 00:01:44 2008
From: camilo at mesias.co.uk (Camilo Mesias)
Date: Wed, 12 Nov 2008 00:01:44 +0000
Subject: preupgrade F9 -> rawhide?
In-Reply-To: <1226089312.3459.43.camel@metroid.rdu.redhat.com>
References: <d551e0e20810261105u1fce4b2am7ead022a5c2f9c83@mail.gmail.com>
	<1225084095.3077.24.camel@zebes.localdomain>
	<d551e0e20810262348m2a94520eh562373b2df491b30@mail.gmail.com>
	<d551e0e20811070940k6277b1a4ufdf5f27add2c90b@mail.gmail.com>
	<1226089312.3459.43.camel@metroid.rdu.redhat.com>
Message-ID: <d551e0e20811111601u54a1a2acq15c6a2260d619976@mail.gmail.com>

Hi

2008/11/7 Will Woods <wwoods at redhat.com>:
> This is a GRUB bug that we've been unable to reproduce reliably, and
> therefore haven't traced fully. It's often triggered by using the grub
> --once flag, which is used by both preupgrade and suspend-to-disk
> (hibernate). We've seen it happen with both of those things, but the
> preupgrade case seems to be more frequent because it tends to also
> involve upgrading GRUB at the same time.

I've just seen this problem happen after a yum upgrade. I installed
switchdesk-gui, yum updated and groupinstalled XFCE. on the next
reboot I had a broken grub. Here are log excerpts showing what got
updated/installed:

http://pastebin.com/m7863382d

Could this happen just by installing a new kernel?

-Cam



From stickster at gmail.com  Wed Nov 12 01:01:44 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Tue, 11 Nov 2008 20:01:44 -0500
Subject: F8 EOL messaging
Message-ID: <20081112010144.GE8501@localhost.localdomain>

It seems really wrong to EOL F8 on Christmas Day.  Can we make that
December 26th? :-)

-- 
Paul W. Frields    ("Boxing Day jokes ftl.")
  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/20081111/1058235c/attachment.sig>

From mclasen at redhat.com  Wed Nov 12 01:04:17 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 11 Nov 2008 20:04:17 -0500
Subject: poppler soname bump
Message-ID: <1226451857.3368.6.camel@localhost.localdomain>

I've just built poppler-0.10.1 for F11, which caused the library version
to go from .3 to .4. 

Looks like a couple of things need rebuilds, at least:

inkscape
tracker
evince (I'll take care of this one)


Matthias



From jspaleta at gmail.com  Wed Nov 12 01:09:16 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 11 Nov 2008 16:09:16 -0900
Subject: F8 EOL messaging
In-Reply-To: <20081112010144.GE8501@localhost.localdomain>
References: <20081112010144.GE8501@localhost.localdomain>
Message-ID: <604aa7910811111709s3d27cc53m4a74f982b9499a75@mail.gmail.com>

2008/11/11 Paul W. Frields <stickster at gmail.com>:
> It seems really wrong to EOL F8 on Christmas Day.  Can we make that
> December 26th? :-)

And ruin Boxing Day?

-jef



From stickster at gmail.com  Wed Nov 12 02:33:26 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Tue, 11 Nov 2008 21:33:26 -0500
Subject: F8 EOL messaging
In-Reply-To: <604aa7910811111709s3d27cc53m4a74f982b9499a75@mail.gmail.com>
References: <20081112010144.GE8501@localhost.localdomain>
	<604aa7910811111709s3d27cc53m4a74f982b9499a75@mail.gmail.com>
Message-ID: <20081112023326.GI8501@localhost.localdomain>

On Tue, Nov 11, 2008 at 04:09:16PM -0900, Jeff Spaleta wrote:
> 2008/11/11 Paul W. Frields <stickster at gmail.com>:
> > It seems really wrong to EOL F8 on Christmas Day.  Can we make that
> > December 26th? :-)
> 
> And ruin Boxing Day?

I see someone didn't read my .signature. ;-)

-- 
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/20081111/d13bf66d/attachment.sig>

From poelstra at redhat.com  Wed Nov 12 02:39:03 2008
From: poelstra at redhat.com (John Poelstra)
Date: Tue, 11 Nov 2008 18:39:03 -0800
Subject: Fedora Release Engineering Meeting Recap 2008-11-11
Message-ID: <491A41C7.8010706@redhat.com>

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

Please make corrections and clarifications to the wiki page.

== Fedora 10 ==
* still frozen, and still accepting bugfix builds.
* November 16 is the last day to tag packages
* November 17 to 21 to create a final release
* Fedora 10 blocker list is needs to some work
* team of people is meeting on #fedora-blocker to work through list
* discussion of signed repo data


== IRC Transcript ==



From sundaram at fedoraproject.org  Wed Nov 12 03:03:24 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 12 Nov 2008 08:33:24 +0530
Subject: Fedora Release Engineering Meeting Recap 2008-11-11
In-Reply-To: <491A41C7.8010706@redhat.com>
References: <491A41C7.8010706@redhat.com>
Message-ID: <491A477C.9050903@fedoraproject.org>

John Poelstra wrote:
> Recap and full IRC transcript found here:
> https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-nov-10
> 
> Please make corrections and clarifications to the wiki page.
> 
> == Fedora 10 ==
> * still frozen, and still accepting bugfix builds.
> * November 16 is the last day to tag packages
> * November 17 to 21 to create a final release
> * Fedora 10 blocker list is needs to some work
> * team of people is meeting on #fedora-blocker to work through list

Is this a new IRC channel? Was it announced somewhere?

Rahul



From bruno at wolff.to  Wed Nov 12 03:03:39 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Tue, 11 Nov 2008 21:03:39 -0600
Subject: F10 Post-Preview snapshots?
In-Reply-To: <5f6f8c5f0811111114i302752e4pb900c595ef0b0763@mail.gmail.com>
References: <5f6f8c5f0811111114i302752e4pb900c595ef0b0763@mail.gmail.com>
Message-ID: <20081112030339.GA15403@wolff.to>

On Tue, Nov 11, 2008 at 20:14:51 +0100,
  "Joshua C." <joshuacov at googlemail.com> wrote:
> We saw 3 snapshots between f10 beta and f10 preview release. Will
> there be any snapshots before f10 final? torrents?

What are you looking to test? There are already F10 packages that will be
updates as soon as F10 is released. Testing rawhide won't test those.
If you want to test fresh installs rawhide makes sense. If you are interested
in specific packages you might want to look at koji to see if there are
post release updates already for those packages.



From dennis at ausil.us  Wed Nov 12 03:07:17 2008
From: dennis at ausil.us (Dennis Gilmore)
Date: Tue, 11 Nov 2008 21:07:17 -0600
Subject: F8 EOL messaging
In-Reply-To: <20081112023326.GI8501@localhost.localdomain>
References: <20081112010144.GE8501@localhost.localdomain>
	<604aa7910811111709s3d27cc53m4a74f982b9499a75@mail.gmail.com>
	<20081112023326.GI8501@localhost.localdomain>
Message-ID: <200811112107.19853.dennis@ausil.us>

On Tuesday 11 November 2008 08:33:26 pm Paul W. Frields wrote:
> On Tue, Nov 11, 2008 at 04:09:16PM -0900, Jeff Spaleta wrote:
> > 2008/11/11 Paul W. Frields <stickster at gmail.com>:
> > > It seems really wrong to EOL F8 on Christmas Day.  Can we make that
> > > December 26th? :-)
> >
> > And ruin Boxing Day?
>
> I see someone didn't read my .signature. ;-)
ill be at the beach drinking sprite. playing cricket and footy. and having fun 
with my mates on boxing day.  

Oh wait no i wont ill be stuck in the frozen tundra that is north of the Mason 
Dixon line,  no sun sand and surf for me  :(

Dennis



From bpepple at fedoraproject.org  Wed Nov 12 03:28:07 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 11 Nov 2008 22:28:07 -0500
Subject: Fedora Release Engineering Meeting Recap 2008-11-11
In-Reply-To: <491A477C.9050903@fedoraproject.org>
References: <491A41C7.8010706@redhat.com> <491A477C.9050903@fedoraproject.org>
Message-ID: <1226460487.8124.1.camel@truman>

On Wed, 2008-11-12 at 08:33 +0530, Rahul Sundaram wrote:
> John Poelstra wrote:
> > Recap and full IRC transcript found here:
> > https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-nov-10
> > 
> > Please make corrections and clarifications to the wiki page.
> > 
> > == Fedora 10 ==
> > * still frozen, and still accepting bugfix builds.
> > * November 16 is the last day to tag packages
> > * November 17 to 21 to create a final release
> > * Fedora 10 blocker list is needs to some work
> > * team of people is meeting on #fedora-blocker to work through list
> 
> Is this a new IRC channel? Was it announced somewhere?

No, as far as I'm aware, this is the usual weekly rel-eng meeting.

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/20081111/f6546ce8/attachment.sig>

From sundaram at fedoraproject.org  Wed Nov 12 03:40:44 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 12 Nov 2008 09:10:44 +0530
Subject: Fedora Release Engineering Meeting Recap 2008-11-11
In-Reply-To: <1226460487.8124.1.camel@truman>
References: <491A41C7.8010706@redhat.com> <491A477C.9050903@fedoraproject.org>
	<1226460487.8124.1.camel@truman>
Message-ID: <491A503C.9080404@fedoraproject.org>

Brian Pepple wrote:
> On Wed, 2008-11-12 at 08:33 +0530, Rahul Sundaram wrote:
>> John Poelstra wrote:
>>> Recap and full IRC transcript found here:
>>> https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-nov-10
>>>
>>> Please make corrections and clarifications to the wiki page.
>>>
>>> == Fedora 10 ==
>>> * still frozen, and still accepting bugfix builds.
>>> * November 16 is the last day to tag packages
>>> * November 17 to 21 to create a final release
>>> * Fedora 10 blocker list is needs to some work
>>> * team of people is meeting on #fedora-blocker to work through list
>> Is this a new IRC channel? Was it announced somewhere?
> 
> No, as far as I'm aware, this is the usual weekly rel-eng meeting.

In case, it wasn't clear, I was talking about #fedora-blocker. This is 
the first time I am seeing a mention of this irc channel. I don't see it 
announced anywhere or listed at

https://fedoraproject.org/wiki/Communicate

Rahul



From stickster at gmail.com  Wed Nov 12 03:55:56 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Tue, 11 Nov 2008 22:55:56 -0500
Subject: Fedora Release Engineering Meeting Recap 2008-11-11
In-Reply-To: <491A503C.9080404@fedoraproject.org>
References: <491A41C7.8010706@redhat.com> <491A477C.9050903@fedoraproject.org>
	<1226460487.8124.1.camel@truman>
	<491A503C.9080404@fedoraproject.org>
Message-ID: <20081112035556.GN8501@localhost.localdomain>

On Wed, Nov 12, 2008 at 09:10:44AM +0530, Rahul Sundaram wrote:
> Brian Pepple wrote:
>> On Wed, 2008-11-12 at 08:33 +0530, Rahul Sundaram wrote:
>>> John Poelstra wrote:
>>>> Recap and full IRC transcript found here:
>>>> https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-nov-10
>>>>
>>>> Please make corrections and clarifications to the wiki page.
>>>>
>>>> == Fedora 10 ==
>>>> * still frozen, and still accepting bugfix builds.
>>>> * November 16 is the last day to tag packages
>>>> * November 17 to 21 to create a final release
>>>> * Fedora 10 blocker list is needs to some work
>>>> * team of people is meeting on #fedora-blocker to work through list
>>> Is this a new IRC channel? Was it announced somewhere?
>>
>> No, as far as I'm aware, this is the usual weekly rel-eng meeting.
>
> In case, it wasn't clear, I was talking about #fedora-blocker. This is  
> the first time I am seeing a mention of this irc channel. I don't see it  
> announced anywhere or listed at
>
> https://fedoraproject.org/wiki/Communicate

It was first seen in a previous post on this list:
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02428.html

-- 
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/20081111/24aaf15b/attachment.sig>

From rc040203 at freenet.de  Wed Nov 12 03:59:24 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 12 Nov 2008 04:59:24 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <gfck7t$ba9$1@ger.gmane.org>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>
	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com> <insou5xh2j.ln2@ppp1053.in.ipex.cz>
	<1226426337.3752.147.camel@beck.corsepiu.local>
	<gfcj76$76a$1@ger.gmane.org>
	<1226428891.3752.167.camel@beck.corsepiu.local>
	<gfck7t$ba9$1@ger.gmane.org>
Message-ID: <1226462364.3752.226.camel@beck.corsepiu.local>

On Tue, 2008-11-11 at 12:51 -0600, Rex Dieter wrote:
> Ralf Corsepius wrote:
> 
> > On Tue, 2008-11-11 at 12:34 -0600, Rex Dieter wrote:
> >> Ralf Corsepius wrote:
>  
> >> <sarcasm>
> >> Who really needs all that fedora infrastructure, peer/package review,
> >> qa/testing, anyway.  Much easier to skip all that.
> >> </sarcasm>
> 
> > Well, ... if the fedora infrastructure was really serving contributors,
> > if peer/package reviews were functional, if testing was functional, then
> > this all would not be an issue.
> 
> > The unpleasant truth is: It isn't.
> 
> Standard response: how exactly isn't it?

Let me pick just 2 examples:

* infrastructure: Fedora's infrastructure in first place mean struggling
with a zoo of more or less arguable processes/work-flows (freezes, FTBP,
wikis ...), a zoo of more or less functional tools (bugzilla, FAS,
packagedb, koji, bodhi, ...) and a zoo of bureaucracy they are
implementing.

* testing: The parties testing a contributed package in first place is
the package's upstream, the packager and this package's end-users.
Fedora only contributes to testing a package insofar, as having a
package in Fedora widens the "potential user-base" of a package.

>   How exactly do you propose to make it better?
I guess you should know my answers :-)

Points to getting started with would be 
* "getting rid of the freezes"
* "getting rid of the update delays"
* improve the tools contributors are forced to use.

Ralf




From dbn.lists at gmail.com  Wed Nov 12 04:05:38 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Tue, 11 Nov 2008 20:05:38 -0800
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081111212804.GA11450@nostromo.devel.redhat.com>
References: <20081029215123.GL25197@nostromo.devel.redhat.com>
	<20081030154405.GA12240@nostromo.devel.redhat.com>
	<91705d080810301155q487a968qc91be14ecdc6909d@mail.gmail.com>
	<20081030202920.GB31153@nostromo.devel.redhat.com>
	<91705d080810301410h415f6e4fj6fbf881eada2f69d@mail.gmail.com>
	<20081031202054.GB8150@nostromo.devel.redhat.com>
	<91705d080810311401gdc85e93i1bd182ce56976bb3@mail.gmail.com>
	<20081110214901.GA14463@nostromo.devel.redhat.com>
	<91705d080811101440t9c5e80ai7c895835e76eb625@mail.gmail.com>
	<20081111212804.GA11450@nostromo.devel.redhat.com>
Message-ID: <91705d080811112005s42e85637id419ba4ec460f105@mail.gmail.com>

On Tue, Nov 11, 2008 at 1:28 PM, Bill Nottingham <notting at redhat.com> wrote:
> Dan Nicholson (dbn.lists at gmail.com) said:
>> > Further testing with this is giving me some bizarre errors and hangs
>> > relating to VT switching that don't happen with this patchset backed
>> > out. Unless I can track those down, I can't really recommend using
>> > it.
>>
>> Without doing anything from event.d, there's nothing on tty1 for the
>> `telinit 5' from runlevel 3 case, right? I don't want you to use a
>> broken patch, but I do think the current behavior is wrong.
>
> It's 'wrong', but it's predictably wrong without side-effects on the
> rest of the interface (crash, hang, etc.) and easily explained what
> to do. At this stage of the release cycle, that's better than a patch
> that fixes it for some cases and does really bizarre things in ways
> that I haven't characterized yet. (I've seen hangs in the VT switch
> code, and I can reliably reproduce a condition where the console
> is perfectly fine... but not actually updating on the screen.)
> Still poking at it, though.

That's understandable. It would be nice if the display manager would
be taken into account since kdm and xdm users will just get nothing on
tty1 in runlevel 5 at all times. I'm sure you'll come up with
something sooner or later.

--
Dan



From sundaram at fedoraproject.org  Wed Nov 12 04:12:12 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 12 Nov 2008 09:42:12 +0530
Subject: Fedora Release Engineering Meeting Recap 2008-11-11
In-Reply-To: <20081112035556.GN8501@localhost.localdomain>
References: <491A41C7.8010706@redhat.com>
	<491A477C.9050903@fedoraproject.org>	<1226460487.8124.1.camel@truman>	<491A503C.9080404@fedoraproject.org>
	<20081112035556.GN8501@localhost.localdomain>
Message-ID: <491A579C.3090001@fedoraproject.org>

Paul W. Frields wrote:
> 
> It was first seen in a previous post on this list:
> https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02428.html

Ah, I missed it.

It should have been more widely announced and documented in the right 
places IMO. We seem to have mailing lists and irc channels not even 
listed in

https://fedoraproject.org/wiki/Communicate

Adding more without widely announcing them is not very helpful.

Rahul




From fedora at leemhuis.info  Wed Nov 12 05:49:13 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 12 Nov 2008 06:49:13 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <1226439740.10458.15.camel@luminos.localdomain>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>	<49190741.6090902@gmail.com>	<20081111090721.928d792a.mschwendt@gmail.com>	<49198DC9.3030609@gmail.com>	<20081111161642.711a1d5d.mschwendt@gmail.com>	<4919ADA0.1050900@gmail.com>	<16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>	<4919B525.3070300@gmail.com>	<1226422090.3417.23.camel@localhost.localdomain>	<4919BE5C.9050001@gmail.com>
	<20081111204717.GB15724@orient.maison.lan>	<4919F7C5.1090705@gmail.com>
	<1226439740.10458.15.camel@luminos.localdomain>
Message-ID: <491A6E59.3070803@leemhuis.info>

On 11.11.2008 22:42, Jesse Keating wrote:
> On Tue, 2008-11-11 at 15:23 -0600, Les Mikesell wrote:
>> Which repos have a chance to rebuild against new fedora libraries before 
>> they are publicly available so a user updating with both enabled won't 
>> experience conflicts?
> Every repo.  Our build roots are public and static repo locations are
> updated hourly with their contents.  It's all public, anybody in the
> would can access it.

As someone that takes care of a 3rd party repo I can mostly agree to 
this statement from Jesse. But there is one important thing that is not 
really foreseeable for the public: Pushes to the stable or testing 
updates repos.

They just happen suddenly out of the blue and I as 3rd party repo 
manager have no real chance to do push at exactly the same time. All a 
3rd party repo manager can do is to watch fedora-announce-list closely 
and push packages that have dependencies on specific Fedora packages 
(xine-lib-extras-nonfree, qmmp-plugins-freeworld, all kmods, some 
others) once he sees that Fedora did the push.

That is one of the big problems. Another one: Dependency problems due to 
mirror lags afaik confuse yum (at least on F8 and F9). Details can be 
found here:
http://www.redhat.com/archives/rhl-devel-list/2008-August/msg00041.html

CU
knurd



From jkeating at redhat.com  Wed Nov 12 06:00:09 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 11 Nov 2008 22:00:09 -0800
Subject: Fedora Release Engineering Meeting Recap 2008-11-11
In-Reply-To: <491A503C.9080404@fedoraproject.org>
References: <491A41C7.8010706@redhat.com>
	<491A477C.9050903@fedoraproject.org> <1226460487.8124.1.camel@truman>
	<491A503C.9080404@fedoraproject.org>
Message-ID: <1226469609.10458.47.camel@luminos.localdomain>

On Wed, 2008-11-12 at 09:10 +0530, Rahul Sundaram wrote:
> In case, it wasn't clear, I was talking about #fedora-blocker. This is 
> the first time I am seeing a mention of this irc channel. I don't see it 
> announced anywhere or listed at

It's a temporary channel that was created to grab a few people and
review current blocker bugs.  It will go away once the release is out.

-- 
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/20081111/ccc82cf2/attachment.sig>

From dan at danny.cz  Wed Nov 12 08:51:13 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Wed, 12 Nov 2008 09:51:13 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <faa16b610811111104t464e39c4wa8c099a31b4d4a69@mail.gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<faa16b610811111104t464e39c4wa8c099a31b4d4a69@mail.gmail.com>
Message-ID: <1226479873.3638.14.camel@eagle.danny.cz>


Colin Walters p??e v ?t 11. 11. 2008 v 14:04 -0500:
> On Tue, Nov 11, 2008 at 1:50 PM, Dan Hor?k <dan at danny.cz> wrote:
> > There were many discussions in the past few days and weeks about the
> > orientation Fedora currently has. It is a fact that currently
> > Fedora is primarily desktop oriented.
> >
> > We agree that Desktop is important part of the system, it is highly
> > visible to the public and large number of Fedora users. But we also see
> > a large number of Fedora and CentOS users and RHEL customers with very
> > specific needs and demands. We can not omit the server fundamentals that
> > later create a successful enterprise product and in our opinion a formal
> > entity must exist to coordinate these efforts.
> >
> > That's why we started work on establishing the Fedora Server SIG. The
> > draft is available at https://fedoraproject.org/wiki/DanHorak/ServerSIG
> > Any constructive ideas are welcome  :-)
> 
> Sounds like a great idea; as you state, I think it is important to
> have a voice for the more conservative server side in Fedora to
> counterpoint the fast-moving desktop.
> 
> In addition to the list of goals you have there, I would suggest:
> 
> * Create an official minimal server spin image, link to it on
> fedoraproject.org/get-fedora (when we do this, we can relegate the
> choose-your-own-adventure DVD images to a secondary page)

The spin is already covered by existing goals, I think.

> * Consider creating a landing point page for all the admin
> technologies in Fedora (kickstart, cobbler, etc.) Does one exist now?
> 

I don't think that such page exists, but it really should.

> Do you plan to create a mailing list, or use this one?
> 

The plan is to create and use fedora-server list.


		Dan



From rjones at redhat.com  Wed Nov 12 09:02:23 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 12 Nov 2008 09:02:23 +0000
Subject: Plan for tomorrows (20081112) FESCO meeting
In-Reply-To: <1226445382.3255.10.camel@kennedy>
References: <1226438839.26212.2.camel@kennedy> <4919FE3B.1070602@redhat.com>
	<1226445382.3255.10.camel@kennedy>
Message-ID: <20081112090223.GA24778@amd.home.annexia.org>

On Tue, Nov 11, 2008 at 06:16:22PM -0500, Brian Pepple wrote:
> On Tue, 2008-11-11 at 13:50 -0800, John Poelstra wrote:
> > I would like to discuss 
> > https://fedoraproject.org/wiki/Features/F11PolicyReview and propose that 
> > FESCo start review Fedora 11 features next week, time permitting.
> 
> Added to the schedule.  Also, I don't think it will be a problem
> starting the F11 feature reviews next week.

One of the proposed features is
https://fedoraproject.org/wiki/Features/Windows_cross_compiler, but
I'm not going to be around this evening to discuss it.  Next week is
probably OK.

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 dan at danny.cz  Wed Nov 12 09:06:56 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Wed, 12 Nov 2008 10:06:56 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <4919DC9C.1030009@gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us>  <4919DC9C.1030009@gmail.com>
Message-ID: <1226480816.3638.19.camel@eagle.danny.cz>


Les Mikesell p??e v ?t 11. 11. 2008 v 13:27 -0600:
> Dennis Gilmore wrote:
> > 
> > If there was a server spin i would think it would be just enough to have yum 
> > working  there are so many different server purposes.  I think a better thing 
> > would be to have kickstart files with different pre-configured systems. 
> 
> That isn't unique to servers.  Is there some reason not to do that in 
> general and allow anyone to submit package lists to create machines 
> tuned for any purpose?

Yes, it will be interesting to see what packages will come in when you
issue "yum --installroot=/your/new/server/disk install grub kernel
initscripts bash yum" :-)


		Dan




From sundaram at fedoraproject.org  Wed Nov 12 09:19:16 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 12 Nov 2008 14:49:16 +0530
Subject: starting Fedora Server SIG
In-Reply-To: <1226479873.3638.14.camel@eagle.danny.cz>
References: <1226429441.3593.77.camel@eagle.danny.cz>	<faa16b610811111104t464e39c4wa8c099a31b4d4a69@mail.gmail.com>
	<1226479873.3638.14.camel@eagle.danny.cz>
Message-ID: <491A9F94.1030009@fedoraproject.org>

Dan Hor?k wrote:

> 
> The plan is to create and use fedora-server list.

Can you continue using fedora-devel list for that till there is a active 
community around your SIG? Creating your own silos early is a bad move.

Rahul










From yanmin_zhang at linux.intel.com  Wed Nov 12 09:29:50 2008
From: yanmin_zhang at linux.intel.com (Zhang, Yanmin)
Date: Wed, 12 Nov 2008 17:29:50 +0800
Subject: T61 mobile fails to boot randomly
In-Reply-To: <1226395002.2866.32.camel@ymzhang>
References: <1226395002.2866.32.camel@ymzhang>
Message-ID: <1226482190.2866.36.camel@ymzhang>


On Tue, 2008-11-11 at 17:16 +0800, Zhang, Yanmin wrote:
> Peter,
> 
> I run into a random boot failure issue with my t61 mobile. It's
> a dual-core x86-64 mobile. I installed Fedora core x86-64 8.
> with kernel 2.6.28-rc, system fails to boot randomly.
> 
> Pls. see http://bugzilla.kernel.org/show_bug.cgi?id=11899.
> 
> I found there are 2 issues.
> 1) when root=LABEL=/1, almost fails. nash fails to find the DISK type
> for root device (MAJOR 259), so it couldn't probe for the boot file
> system labels; It might be resolved by calling register_blkdev in kernel for 259.
> 2) when root=/dev/sda1, random fails. I instrumented both kernel and nash. kernel really
> sends out netlink uevent info for device /dev/sdaXXX, but nash doesn't receive it.
> 
> I did a quick check of the source codes of the latest nash of FC10. It seems FC10's nash
> just added some new features (subcommands). So it shouldn't fix it. I didn't really test
> the latest nash because the nash update depends on too many rpms.
Peter,

I think I found the root cause of issue 2). Pls. see
http://bugzilla.kernel.org/show_bug.cgi?id=11899#c38.

Could you help review the patch?

-yanmin




From dan at danny.cz  Wed Nov 12 10:23:42 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Wed, 12 Nov 2008 11:23:42 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <1226480816.3638.19.camel@eagle.danny.cz>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us>  <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
Message-ID: <1226485422.3638.22.camel@eagle.danny.cz>


Dan Hor?k p??e v St 12. 11. 2008 v 10:06 +0100:
> Les Mikesell p??e v ?t 11. 11. 2008 v 13:27 -0600:
> > Dennis Gilmore wrote:
> > > 
> > > If there was a server spin i would think it would be just enough to have yum 
> > > working  there are so many different server purposes.  I think a better thing 
> > > would be to have kickstart files with different pre-configured systems. 
> > 
> > That isn't unique to servers.  Is there some reason not to do that in 
> > general and allow anyone to submit package lists to create machines 
> > tuned for any purpose?
> 
> Yes, it will be interesting to see what packages will come in when you
> issue "yum --installroot=/your/new/server/disk install grub kernel
> initscripts bash yum" :-)

Not so bad - 145 packages, 110 MB


		Dan




From pertusus at free.fr  Wed Nov 12 11:05:06 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 12 Nov 2008 12:05:06 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <1226485422.3638.22.camel@eagle.danny.cz>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
Message-ID: <20081112110506.GA3142@free.fr>

On Wed, Nov 12, 2008 at 11:23:42AM +0100, Dan Hor?k wrote:
> 
> Not so bad - 145 packages, 110 MB

Fedora is not in a bad state with respect to fine grained dependencies
(it was quite bad back, at least up to FC4), mostly 
* thanks to olpc,
* to maintainers who reported these issues,
* because there is always some space needed on the live disc
* thanks to split to some -libs because of multilib issues.

Unless it has been solved, there was still an issue with metacity (and
maybe gnome) and themes interdependencies. Also there are still
monolithic big beasts like texlive, but I am not sure that it is
that desirable to fix those.

--
Pat



From pertusus at free.fr  Wed Nov 12 11:17:12 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 12 Nov 2008 12:17:12 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <1226485422.3638.22.camel@eagle.danny.cz>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
Message-ID: <20081112111712.GB3142@free.fr>

On Wed, Nov 12, 2008 at 11:23:42AM +0100, Dan Hor?k wrote:
> 
> Not so bad - 145 packages, 110 MB

I tried 

yum --installroot=/mnt/tmp/ install '@core' '@base'
  -> 416 Packages, 257 M.

and it is less right, X is brought in, and also qt qt-X11. Should
certainly be investigated.

--
Pat



From buc at odusz.so-cdu.ru  Wed Nov 12 11:24:50 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Wed, 12 Nov 2008 14:24:50 +0300
Subject: starting Fedora Server SIG
In-Reply-To: <312e361df9b78ba2da71a71ffd6a6522.squirrel@mail.jcomserv.net>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<312e361df9b78ba2da71a71ffd6a6522.squirrel@mail.jcomserv.net>
Message-ID: <491ABD02.8070504@odu.neva.ru>

Jon Ciesla wrote:
>> There were many discussions in the past few days and weeks about the
>> orientation Fedora currently has. It is a fact that currently
>> Fedora is primarily desktop oriented.
>>
>> We agree that Desktop is important part of the system, it is highly
>> visible to the public and large number of Fedora users. But we also see
>> a large number of Fedora and CentOS users and RHEL customers with very
>> specific needs and demands. We can not omit the server fundamentals that
>> later create a successful enterprise product and in our opinion a formal
>> entity must exist to coordinate these efforts.
>>
>> That's why we started work on establishing the Fedora Server SIG. The
>> draft is available at https://fedoraproject.org/wiki/DanHorak/ServerSIG
>> Any constructive ideas are welcome  :-)
>>     
>
> I'm in.  I run a side business on all Fedora servers.  People think I'm
> nuts.  I love the up-to-date software and stability.  And I upgrade via
> yum. :)
>   

/me too. :)

Dmitry Butskoy
http://www.fedoraproject.org/wiki/DmitryButskoy



From pbrobinson at gmail.com  Wed Nov 12 11:53:21 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 12 Nov 2008 11:53:21 +0000
Subject: starting Fedora Server SIG
In-Reply-To: <20081112111712.GB3142@free.fr>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
Message-ID: <5256d0b0811120353y4b3d076bra38ffcbf71a021b5@mail.gmail.com>

>> Not so bad - 145 packages, 110 MB
>
> I tried
>
> yum --installroot=/mnt/tmp/ install '@core' '@base'
>  -> 416 Packages, 257 M.
>
> and it is less right, X is brought in, and also qt qt-X11. Should
> certainly be investigated.

For some reason redhat-lsb pulls in qt, qt-X11 and qt3. redhat-lsb is
certainly something you'd probably want in a server environment but no
idea why it would need qt. Its also a 'default' in base. I'm also not
quite sure why old not often used tools like ypbind, rsh, rdate, rdate
are set as default either. Anyone that would need to use those style
systems would also know how to install them.

Peter



From nicolas.mailhot at laposte.net  Wed Nov 12 11:56:22 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 12 Nov 2008 12:56:22 +0100 (CET)
Subject: starting Fedora Server SIG
In-Reply-To: <20081112110506.GA3142@free.fr>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr>
Message-ID: <0723b17086a6d54f23356db45ef65384.squirrel@arekh.dyndns.org>



Le Mer 12 novembre 2008 12:05, Patrice Dumas a ?crit :
> Also there are still
> monolithic big beasts like texlive, but I am not sure that it is
> that desirable to fix those.

It is very desirable to fix texlive:
1. The latest upstream version is modularized, not monolithic,
monolithic packaging prevents us from upgraring
2. Lumping all kinds of different resources in a single package
resulted in licensing hell (ask spot)
3. All the stuff inside texlive is not packaged following the
guidelines that would have applied if it were packaged separately, and
as a result stuff like fonts which could be used in a print server or
some other server app is not made available to non-tex users.

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Wed Nov 12 11:58:09 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 12 Nov 2008 12:58:09 +0100 (CET)
Subject: starting Fedora Server SIG
In-Reply-To: <20081112111712.GB3142@free.fr>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
Message-ID: <385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>



Le Mer 12 novembre 2008 12:17, Patrice Dumas a ?crit :
>
> On Wed, Nov 12, 2008 at 11:23:42AM +0100, Dan Hor?k wrote:
>>
>> Not so bad - 145 packages, 110 MB
>
> I tried
>
> yum --installroot=/mnt/tmp/ install '@core' '@base'
>   -> 416 Packages, 257 M.
>
> and it is less right, X is brought in, and also qt qt-X11. Should
> certainly be investigated.

That's probably because of LSB compliance. As has been discussed
previously, someone needs to split the lsb package in server-side
stuff and other stuff (yes that would mean a system that used only the
first part would not be fully lsb compliant)

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Wed Nov 12 12:00:03 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 12 Nov 2008 13:00:03 +0100 (CET)
Subject: starting Fedora Server SIG
In-Reply-To: <5256d0b0811120353y4b3d076bra38ffcbf71a021b5@mail.gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<5256d0b0811120353y4b3d076bra38ffcbf71a021b5@mail.gmail.com>
Message-ID: <c456c10d0c4ff59b18c296ae68ccd188.squirrel@arekh.dyndns.org>



Le Mer 12 novembre 2008 12:53, Peter Robinson a ?crit :

> For some reason redhat-lsb pulls in qt, qt-X11 and qt3. redhat-lsb is
> certainly something you'd probably want in a server environment but no
> idea why it would need qt. Its also a 'default' in base. I'm also not
> quite sure why old not often used tools like ypbind, rsh, rdate, rdate
> are set as default either. Anyone that would need to use those style
> systems would also know how to install them.

It pulls them in because the LSB specified them as available on a
conformant LSB system. That the old stuff is there too is a reflection
of ISVs conservativeness.

-- 
Nicolas Mailhot



From schaiba at gmail.com  Wed Nov 12 12:00:26 2008
From: schaiba at gmail.com (Aioanei Rares)
Date: Wed, 12 Nov 2008 14:00:26 +0200
Subject: starting Fedora Server SIG
In-Reply-To: <385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
Message-ID: <778179b00811120400s5fda1277y2130ceddeb9d0422@mail.gmail.com>

On Wed, Nov 12, 2008 at 1:58 PM, Nicolas Mailhot <
nicolas.mailhot at laposte.net> wrote:

>
>
> Le Mer 12 novembre 2008 12:17, Patrice Dumas a ?crit :
> >
> > On Wed, Nov 12, 2008 at 11:23:42AM +0100, Dan Hor?k wrote:
> >>
> >> Not so bad - 145 packages, 110 MB
> >
> > I tried
> >
> > yum --installroot=/mnt/tmp/ install '@core' '@base'
> >   -> 416 Packages, 257 M.
> >
> > and it is less right, X is brought in, and also qt qt-X11. Should
> > certainly be investigated.
>
> That's probably because of LSB compliance. As has been discussed
> previously, someone needs to split the lsb package in server-side
> stuff and other stuff (yes that would mean a system that used only the
> first part would not be fully lsb compliant)
>
> --
> Nicolas Mailhot
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


LSB requests qt?
-- 
Aioanei Rares
schaiba at fedoraproject.org
"China is a big country, inhabited by many Chinese." --Charles de Gaulle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081112/990860d1/attachment.htm>

From rc040203 at freenet.de  Wed Nov 12 12:10:30 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 12 Nov 2008 13:10:30 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <778179b00811120400s5fda1277y2130ceddeb9d0422@mail.gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<778179b00811120400s5fda1277y2130ceddeb9d0422@mail.gmail.com>
Message-ID: <1226491831.3752.298.camel@beck.corsepiu.local>

On Wed, 2008-11-12 at 14:00 +0200, Aioanei Rares wrote:
> 
> 
> On Wed, Nov 12, 2008 at 1:58 PM, Nicolas Mailhot
> <nicolas.mailhot at laposte.net> wrote:
>         
>         
>         Le Mer 12 novembre 2008 12:17, Patrice Dumas a ?crit :
>         >
>         > On Wed, Nov 12, 2008 at 11:23:42AM +0100, Dan Hor?k wrote:
>         >>
>         >> Not so bad - 145 packages, 110 MB
>         >
>         > I tried
>         >
>         > yum --installroot=/mnt/tmp/ install '@core' '@base'
>         >   -> 416 Packages, 257 M.
>         >
>         > and it is less right, X is brought in, and also qt qt-X11.
>         Should
>         > certainly be investigated.
>         
>         
>         That's probably because of LSB compliance. As has been
>         discussed
>         previously, someone needs to split the lsb package in
>         server-side
>         stuff and other stuff (yes that would mean a system that used
>         only the
>         first part would not be fully lsb compliant)

> 
> LSB requests qt?

The LSB Desktop specs[1] requires them.

The LSB Core specs[2] don't.

I'd say this is a badly packaged package, which is in dire need of being
split ;)


Ralf


[1]
http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Desktop-generic/LSB-Desktop-generic/book1.html

[2]
http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/book1.html




From rawhide at fedoraproject.org  Wed Nov 12 12:11:00 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Wed, 12 Nov 2008 12:11:00 +0000 (UTC)
Subject: rawhide report: 20081112 changes
Message-ID: <20081112121100.C89DF1F8258@releng2.fedora.phx.redhat.com>

Compose started at Wed Nov 12 06:01:43 UTC 2008

Updated Packages:

acpid-1.0.6-9.fc10
------------------
* Tue Nov 11 17:00:00 2008 Zdenek Prikryl <zprikryl at redhat.com> - 1.0.6-9
- power.sh works with ConsoleKit >= 0.3.0 (#470752)
- Fixed conditions in power.sh, which look for power-managers (#470752)
- Added check to init script


anaconda-11.4.1.57-1
--------------------
* Tue Nov 11 17:00:00 2008 David Cantrell <dcantrell at redhat.com> - 11.4.1.57-1
- Fix more UnicodeDecodeErrors, hopefully for good this time (#470733).
  (clumens)
- iscsi do missing value check only once (hdegoede)
- Don't try to label XFS filesystems on livecd installs (#470951). (clumens)
- Include cracklib .mo files and look up strings in the right domain.
  (clumens)
- Bugzilla has changed its return values for a couple queries. (clumens)
- Set the default keyboard based on the language (#470446). (clumens)
- Prevent traceback for vnc installs on KVM guests (#470559) (dcantrell)
- Bring up networking early enough for syslog= param (#470513) (dcantrell)
- Sleep a bit before calling udevsettle in iscsiTarget.login (#470073,
  - kickstart, iscsi do not call iscsi.startup after startIBFT has been called
  (hdegoede)
- Do not stop and restart iscsid when rescanning disks/partitions (#470223)
  (hdegoede)
- iscsi.startup should not login to targets as we are already logged in
  (#470230) (hdegoede)
- Remove obsolete normally never reached code from _stopIscsiDaemon
  (#470229) (hdegoede)
- The function getEncryptedDevice gets called correctly expect when we are
  in (jgranado)
- More translations


cheese-2.24.1-2.fc10
--------------------
* Sun Nov  9 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 2.24.1-2
- Fix cams which only support 1 resolution not working (rh470698, gnome560032)


dovecot-1.1.6-2.fc10
--------------------
* Mon Nov  3 17:00:00 2008 Michal Hlavinka <mhlavink at redhat.com> - 1:1.1.6-2
- changed comment in sysconfig to match actual state

* Mon Nov  3 17:00:00 2008 Michal Hlavinka <mhlavink at redhat.com> - 1:1.1.6-1
- update to upstream version 1.1.6
- change permissions of deliver and dovecot.conf to prevent possible password exposure


Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 4









Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot





From jreznik at redhat.com  Wed Nov 12 12:13:01 2008
From: jreznik at redhat.com (Jaroslav Reznik)
Date: Wed, 12 Nov 2008 07:13:01 -0500 (EST)
Subject: starting Fedora Server SIG
In-Reply-To: <778179b00811120400s5fda1277y2130ceddeb9d0422@mail.gmail.com>
Message-ID: <836571834.1985451226491981676.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

----- "Aioanei Rares" <schaiba at gmail.com> wrote:

> On Wed, Nov 12, 2008 at 1:58 PM, Nicolas Mailhot <
> nicolas.mailhot at laposte.net > wrote:
> 
> 
> 
> 
> Le Mer 12 novembre 2008 12:17, Patrice Dumas a ?crit :
> 
> >
> > On Wed, Nov 12, 2008 at 11:23:42AM +0100, Dan Hor?k wrote:
> >>
> >> Not so bad - 145 packages, 110 MB
> >
> > I tried
> >
> > yum --installroot=/mnt/tmp/ install '@core' '@base'
> > -> 416 Packages, 257 M.
> >
> > and it is less right, X is brought in, and also qt qt-X11. Should
> > certainly be investigated.
> 
> That's probably because of LSB compliance. As has been discussed
> previously, someone needs to split the lsb package in server-side
> stuff and other stuff (yes that would mean a system that used only the
> first part would not be fully lsb compliant)
> 
> --
> Nicolas Mailhot
> 
> 
> 
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
> 
> 
> LSB requests qt?

Cite: "An conforming implementation shall support the following Qt libraries which provide interfaces for creating rich user applications, either graphical or console."

http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Desktop-generic/LSB-Desktop-generic/book1.html

But this is LSB 3.2 Desktop spec. So there should be lsb-core, lsb-desktop etc. packages.

R.

> --
> Aioanei Rares
> schaiba at fedoraproject.org
> "China is a big country, inhabited by many Chinese." --Charles de
> Gaulle
> 
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list




From vonbrand at inf.utfsm.cl  Wed Nov 12 12:33:44 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Wed, 12 Nov 2008 09:33:44 -0300
Subject: Proposal: Rolling Release
In-Reply-To: <1226462364.3752.226.camel@beck.corsepiu.local>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>
	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com> <insou5xh2j.ln2@ppp1053.in.ipex.cz>
	<1226426337.3752.147.camel@beck.corsepiu.local>
	<gfcj76$76a$1@ger.gmane.org>
	<1226428891.3752.167.camel@beck.corsepiu.local>
	<gfck7t$ba9$1@ger.gmane.org>
	<1226462364.3752.226.camel@beck.corsepiu.local>
Message-ID: <200811121233.mACCXimC003917@laptop14.inf.utfsm.cl>

Ralf Corsepius <rc040203 at freenet.de> wrote:
> On Tue, 2008-11-11 at 12:51 -0600, Rex Dieter wrote:
> > Ralf Corsepius wrote:
> > 
> > > On Tue, 2008-11-11 at 12:34 -0600, Rex Dieter wrote:
> > >> Ralf Corsepius wrote:
> >  
> > >> <sarcasm>
> > >> Who really needs all that fedora infrastructure, peer/package review,
> > >> qa/testing, anyway.  Much easier to skip all that.
> > >> </sarcasm>
> > 
> > > Well, ... if the fedora infrastructure was really serving contributors,
> > > if peer/package reviews were functional, if testing was functional, then
> > > this all would not be an issue.
> > 
> > > The unpleasant truth is: It isn't.
> > 
> > Standard response: how exactly isn't it?
> 
> Let me pick just 2 examples:

> * infrastructure: Fedora's infrastructure in first place mean struggling
> with a zoo of more or less arguable processes/work-flows (freezes, FTBP,
> wikis ...), a zoo of more or less functional tools (bugzilla, FAS,
> packagedb, koji, bodhi, ...) and a zoo of bureaucracy they are
> implementing.

How exactly do you propose getting rid of that and _get the work done_?
Complex work requires coordination. Get over it.

> * testing: The parties testing a contributed package in first place is
> the package's upstream, the packager and this package's end-users.
> Fedora only contributes to testing a package insofar, as having a
> package in Fedora widens the "potential user-base" of a package.

Dead wrong. Upstream can only test i /their/ environment, not as part of
Fedora.

> >   How exactly do you propose to make it better?
> I guess you should know my answers :-)

Humor us.

> Points to getting started with would be 
> * "getting rid of the freezes"

Impossible. If you want to ship something halfway tested, you need to stop
the firehose of updates and concentrate on fixing.

> * "getting rid of the update delays"

What do you mean?

> * improve the tools contributors are forced to use.

Help out it that then.
-- 
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 rc040203 at freenet.de  Wed Nov 12 12:42:26 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 12 Nov 2008 13:42:26 +0100
Subject: Proposal: Rolling Release
In-Reply-To: <200811121233.mACCXimC003917@laptop14.inf.utfsm.cl>
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<49190741.6090902@gmail.com>
	<20081111090721.928d792a.mschwendt@gmail.com>
	<49198DC9.3030609@gmail.com>
	<20081111161642.711a1d5d.mschwendt@gmail.com>
	<4919ADA0.1050900@gmail.com> <insou5xh2j.ln2@ppp1053.in.ipex.cz>
	<1226426337.3752.147.camel@beck.corsepiu.local>
	<gfcj76$76a$1@ger.gmane.org>
	<1226428891.3752.167.camel@beck.corsepiu.local>
	<gfck7t$ba9$1@ger.gmane.org>
	<1226462364.3752.226.camel@beck.corsepiu.local>
	<200811121233.mACCXimC003917@laptop14.inf.utfsm.cl>
Message-ID: <1226493746.3752.315.camel@beck.corsepiu.local>

On Wed, 2008-11-12 at 09:33 -0300, Horst H. von Brand wrote:
> Ralf Corsepius <rc040203 at freenet.de> wrote:
> > On Tue, 2008-11-11 at 12:51 -0600, Rex Dieter wrote:
> > > Ralf Corsepius wrote:
> > > 
> > > > On Tue, 2008-11-11 at 12:34 -0600, Rex Dieter wrote:
> > > >> Ralf Corsepius wrote:
> > >  
> > > >> <sarcasm>
> > > >> Who really needs all that fedora infrastructure, peer/package review,
> > > >> qa/testing, anyway.  Much easier to skip all that.
> > > >> </sarcasm>
> > > 
> > > > Well, ... if the fedora infrastructure was really serving contributors,
> > > > if peer/package reviews were functional, if testing was functional, then
> > > > this all would not be an issue.
> > > 
> > > > The unpleasant truth is: It isn't.
> > > 
> > > Standard response: how exactly isn't it?
> > 
> > Let me pick just 2 examples:
> 
> > * infrastructure: Fedora's infrastructure in first place mean struggling
> > with a zoo of more or less arguable processes/work-flows (freezes, FTBP,
> > wikis ...), a zoo of more or less functional tools (bugzilla, FAS,
> > packagedb, koji, bodhi, ...) and a zoo of bureaucracy they are
> > implementing.
> 
> How exactly do you propose getting rid of that and _get the work done_?
One step would have been rel-eng not only branch in CVS, but also to
branch the repos, ....

Many hundred of bugs are waiting for Fedora's infrastructure team to
look into ...

> Complex work requires coordination. Get over it.

> > * testing: The parties testing a contributed package in first place is
> > the package's upstream, the packager and this package's end-users.
> > Fedora only contributes to testing a package insofar, as having a
> > package in Fedora widens the "potential user-base" of a package.
> 
> Dead wrong. Upstream can only test i /their/ environment, not as part of
> Fedora.
And, where is the problem? 

Are you seriously telling us Fedora's testing group was testing all the
packages in Fedora? They might be testing some very limited set of
packages but claiming they were testing more than this is simply
laughable.

> > >   How exactly do you propose to make it better?
> > I guess you should know my answers :-)
> 
> Humor us.
I will tell you on PM.

> > Points to getting started with would be 
> > * "getting rid of the freezes"
> 
> Impossible. If you want to ship something halfway tested, you need to stop
> the firehose of updates and concentrate on fixing.
Rubbish - If Fedora wants their upcoming releases tested, they need to release them for _testing_.

> > * "getting rid of the update delays"
> 
> What do you mean?
Waiting weeks ans months for some Fedora deity to lean down to push a
package into the repos.

> > * improve the tools contributors are forced to use.
> 
> Help out it that then.
It's rel-eng who pushed them onto comtributors. Shall they do their job.




From joshuacov at googlemail.com  Wed Nov 12 12:54:52 2008
From: joshuacov at googlemail.com (Joshua C.)
Date: Wed, 12 Nov 2008 13:54:52 +0100
Subject: F10 Post-Preview snapshots?
In-Reply-To: <20081112030339.GA15403@wolff.to>
References: <5f6f8c5f0811111114i302752e4pb900c595ef0b0763@mail.gmail.com>
	<20081112030339.GA15403@wolff.to>
Message-ID: <5f6f8c5f0811120454x40f7378ah6a8b20986cf01fe6@mail.gmail.com>

2008/11/12 Bruno Wolff III <bruno at wolff.to>:
> On Tue, Nov 11, 2008 at 20:14:51 +0100,
>  "Joshua C." <joshuacov at googlemail.com> wrote:
>> We saw 3 snapshots between f10 beta and f10 preview release. Will
>> there be any snapshots before f10 final? torrents?
>
> What are you looking to test? There are already F10 packages that will be
> updates as soon as F10 is released. Testing rawhide won't test those.
> If you want to test fresh installs rawhide makes sense. If you are interested
> in specific packages you might want to look at koji to see if there are
> post release updates already for those packages.
>

I have i686 and want to try x86_64. therefore i downloaded livecd but
because of a dsdt error i need to recompile the x86_64 kernel. this is
not possible on i686 installation and the dsdt fix was committed to
f10 kernel after the preview release.

Therefore I need a precompiled livecd image, which won't be released
before stable :(



From pertusus at free.fr  Wed Nov 12 12:55:20 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 12 Nov 2008 13:55:20 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <0723b17086a6d54f23356db45ef65384.squirrel@arekh.dyndns.org>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr>
	<0723b17086a6d54f23356db45ef65384.squirrel@arekh.dyndns.org>
Message-ID: <20081112125520.GD3142@free.fr>

On Wed, Nov 12, 2008 at 12:56:22PM +0100, Nicolas Mailhot wrote:
> 
> 
> Le Mer 12 novembre 2008 12:05, Patrice Dumas a ?crit :
> > Also there are still
> > monolithic big beasts like texlive, but I am not sure that it is
> > that desirable to fix those.
> 
> It is very desirable to fix texlive:
> 1. The latest upstream version is modularized, not monolithic,
> monolithic packaging prevents us from upgraring

Even though it is modularized, upstream (Karl Berry) nevertheless
adviced to use big meta-packages for tex users.

> 2. Lumping all kinds of different resources in a single package
> resulted in licensing hell (ask spot)
> 3. All the stuff inside texlive is not packaged following the
> guidelines that would have applied if it were packaged separately, and
> as a result stuff like fonts which could be used in a print server or
> some other server app is not made available to non-tex users.

I agree with all that, but even if the packaging is less monolithic,
there will certainly be inter-dependencies between TeX packages such
that in the end most of the packages will be pulled in as dependencies.
It still will be easier to use TeX components outside of TeX, like
fonts, but I don't think that it will help TeX users who will still need
to install a bunch of packages. There is already some splitting that
is quite artificial since all the packages get in in the end, because
they all depend on each others (dvips, tex, kpathsea, corresponding 
-texmf...).

--
Pat



From mjc at avtechpulse.com  Wed Nov 12 13:00:52 2008
From: mjc at avtechpulse.com (Dr. Michael J. Chudobiak)
Date: Wed, 12 Nov 2008 08:00:52 -0500
Subject: camera mounts, gphoto, gvfs, gthumb
Message-ID: <491AD384.7000709@avtechpulse.com>

I'm a little unclear how gthumb is supposed to handle cameras in the 
modern gvfs-based world. A Ubuntu user has proposed a patch here:

http://bugzilla.gnome.org/show_bug.cgi?id=560352

Could a Fedora guru take a look at that and confirm that it works for 
Fedora too?

- Mike



From joshuacov at googlemail.com  Wed Nov 12 12:53:35 2008
From: joshuacov at googlemail.com (Joshua C.)
Date: Wed, 12 Nov 2008 13:53:35 +0100
Subject: Missing dependency gnome-python2-gnome
Message-ID: <5f6f8c5f0811120453n3afd7a34wd4b8b609c3eb7a82@mail.gmail.com>

In todays testing updates i got Missing Dependency:
gnome-python2-gnome is needed by package
setroubleshoot-2.0.12-3.fc9.noarch (updates-testing-newkey). I cannot
find it. there are gnome-python2-gnomedesktop,
gnome-python2-gnomekeyring but they don't have the missing one. where
is it?



From mtasaka at ioa.s.u-tokyo.ac.jp  Wed Nov 12 13:11:35 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Wed, 12 Nov 2008 22:11:35 +0900
Subject: Missing dependency gnome-python2-gnome
In-Reply-To: <5f6f8c5f0811120453n3afd7a34wd4b8b609c3eb7a82@mail.gmail.com>
References: <5f6f8c5f0811120453n3afd7a34wd4b8b609c3eb7a82@mail.gmail.com>
Message-ID: <491AD607.8030706@ioa.s.u-tokyo.ac.jp>

Joshua C. wrote, at 11/12/2008 09:53 PM +9:00:
> In todays testing updates i got Missing Dependency:
> gnome-python2-gnome is needed by package
> setroubleshoot-2.0.12-3.fc9.noarch (updates-testing-newkey). I cannot
> find it. there are gnome-python2-gnomedesktop,
> gnome-python2-gnomekeyring but they don't have the missing one. where
> is it?

The split between gnome-python2 <-> gnome-python2-gnome happened
only on F-10+, so there is no "gnome-python2-gnome" on F-9.
>From your message this is a packaging bug in F-9 testing setroubleshoot.

Regards,
Mamoru



From cmadams at hiwaay.net  Wed Nov 12 13:18:06 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 12 Nov 2008 07:18:06 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <20081112110506.GA3142@free.fr>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr>
Message-ID: <20081112131806.GA1461854@hiwaay.net>

Once upon a time, Patrice Dumas <pertusus at free.fr> said:
> Fedora is not in a bad state with respect to fine grained dependencies
> (it was quite bad back, at least up to FC4), mostly 
> * thanks to olpc,
> * to maintainers who reported these issues,
> * because there is always some space needed on the live disc
> * thanks to split to some -libs because of multilib issues.
> 
> Unless it has been solved, there was still an issue with metacity (and
> maybe gnome) and themes interdependencies. Also there are still
> monolithic big beasts like texlive, but I am not sure that it is
> that desirable to fix those.

I tried to install ntop on a firewall (minimal F9 install, tuned via
kickstart).  There were 70 packages added because of dependencies,
including metacity.

-- 
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 schaiba at gmail.com  Wed Nov 12 13:29:24 2008
From: schaiba at gmail.com (Aioanei Rares)
Date: Wed, 12 Nov 2008 15:29:24 +0200
Subject: starting Fedora Server SIG
In-Reply-To: <20081112131806.GA1461854@hiwaay.net>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr> <20081112131806.GA1461854@hiwaay.net>
Message-ID: <778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>

On Wed, Nov 12, 2008 at 3:18 PM, Chris Adams <cmadams at hiwaay.net> wrote:

> Once upon a time, Patrice Dumas <pertusus at free.fr> said:
> > Fedora is not in a bad state with respect to fine grained dependencies
> > (it was quite bad back, at least up to FC4), mostly
> > * thanks to olpc,
> > * to maintainers who reported these issues,
> > * because there is always some space needed on the live disc
> > * thanks to split to some -libs because of multilib issues.
> >
> > Unless it has been solved, there was still an issue with metacity (and
> > maybe gnome) and themes interdependencies. Also there are still
> > monolithic big beasts like texlive, but I am not sure that it is
> > that desirable to fix those.
>
> I tried to install ntop on a firewall (minimal F9 install, tuned via
> kickstart).  There were 70 packages added because of dependencies,
> including metacity.
>

I agree here...and I don't think Fedora is not in a bad state regarding
fine-grained deps...
if you want a point of comparison, take a look at Debian, maybe. Or the
*BSD's.

>
> --
> 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.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
Aioanei Rares
schaiba at fedoraproject.org
"China is a big country, inhabited by many Chinese." --Charles de Gaulle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081112/98a3ae18/attachment.htm>

From dominik at greysector.net  Wed Nov 12 13:40:38 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 12 Nov 2008 14:40:38 +0100
Subject: Missing dependency gnome-python2-gnome
In-Reply-To: <491AD607.8030706@ioa.s.u-tokyo.ac.jp>
References: <5f6f8c5f0811120453n3afd7a34wd4b8b609c3eb7a82@mail.gmail.com>
	<491AD607.8030706@ioa.s.u-tokyo.ac.jp>
Message-ID: <20081112134038.GA15651@mokona.greysector.net>

On Wednesday, 12 November 2008 at 14:11, Mamoru Tasaka wrote:
> Joshua C. wrote, at 11/12/2008 09:53 PM +9:00:
> >In todays testing updates i got Missing Dependency:
> >gnome-python2-gnome is needed by package
> >setroubleshoot-2.0.12-3.fc9.noarch (updates-testing-newkey). I cannot
> >find it. there are gnome-python2-gnomedesktop,
> >gnome-python2-gnomekeyring but they don't have the missing one. where
> >is it?
> 
> The split between gnome-python2 <-> gnome-python2-gnome happened
> only on F-10+, so there is no "gnome-python2-gnome" on F-9.

Huh? WTF is gnome-python2-gnome supposed to be? Couldn't the packager
have invented some more sane name?

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 nicolas.mailhot at laposte.net  Wed Nov 12 14:07:18 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 12 Nov 2008 15:07:18 +0100 (CET)
Subject: starting Fedora Server SIG
In-Reply-To: <778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr> <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
Message-ID: <bf12ed8db9f8b20e1501263e2df5b778.squirrel@arekh.dyndns.org>



>> Once upon a time, Patrice Dumas <pertusus at free.fr> said:
>> > Fedora is not in a bad state with respect to fine grained
>> dependencies
>> > (it was quite bad back, at least up to FC4), mostly
>> > * thanks to olpc,

BTW I think that nicely illustrate the benefits of having different
groups work on a common package repository instead of making one set
of objectives absolute and telling other groups to go elsewhere.

Good engineering tends to help everyone, and who you end up helping is
often surprising.

-- 
Nicolas Mailhot



From lesmikesell at gmail.com  Wed Nov 12 13:54:23 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 12 Nov 2008 07:54:23 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1226491831.3752.298.camel@beck.corsepiu.local>
References: <1226429441.3593.77.camel@eagle.danny.cz>	<200811111317.15198.dennis@ausil.us>
	<4919DC9C.1030009@gmail.com>	<1226480816.3638.19.camel@eagle.danny.cz>	<1226485422.3638.22.camel@eagle.danny.cz>	<20081112111712.GB3142@free.fr>	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>	<778179b00811120400s5fda1277y2130ceddeb9d0422@mail.gmail.com>
	<1226491831.3752.298.camel@beck.corsepiu.local>
Message-ID: <491AE00F.5010703@gmail.com>

Ralf Corsepius wrote:
> >>
>>         >> Not so bad - 145 packages, 110 MB
>>         >
>>         > I tried
>>         >
>>         > yum --installroot=/mnt/tmp/ install '@core' '@base'
>>         >   -> 416 Packages, 257 M.
>>         >
>>         > and it is less right, X is brought in, and also qt qt-X11.
>>         Should
>>         > certainly be investigated.
>>         
>>         
>>         That's probably because of LSB compliance. As has been
>>         discussed
>>         previously, someone needs to split the lsb package in
>>         server-side
>>         stuff and other stuff (yes that would mean a system that used
>>         only the
>>         first part would not be fully lsb compliant)
> 
>> LSB requests qt?
> 
> The LSB Desktop specs[1] requires them.
> 
> The LSB Core specs[2] don't.
> 
> I'd say this is a badly packaged package, which is in dire need of being
> split ;)

Even on machines where I never run an X display on the console, I often 
find it extremely handy to have wireshark-gnome installed and run it via 
ssh port-forwarding.   Likewise I might want to install VMware server 
which needs X libs and perhaps a few other things on a machine that 
doesn't run X on the console.  And on some other machines that I would 
still classify as servers I run a whole desktop environment (or several) 
remotely via freenx.  Are the packages split so you can easily get the X 
libs, fonts, etc., without hardware related components?

-- 
    Les Mikesell
     lesmikesell at gmail.com



From mclasen at redhat.com  Wed Nov 12 14:33:01 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Wed, 12 Nov 2008 09:33:01 -0500
Subject: camera mounts, gphoto, gvfs, gthumb
In-Reply-To: <491AD384.7000709@avtechpulse.com>
References: <491AD384.7000709@avtechpulse.com>
Message-ID: <1226500381.3423.2.camel@localhost.localdomain>

On Wed, 2008-11-12 at 08:00 -0500, Dr. Michael J. Chudobiak wrote:
> I'm a little unclear how gthumb is supposed to handle cameras in the 
> modern gvfs-based world. A Ubuntu user has proposed a patch here:
> 
> http://bugzilla.gnome.org/show_bug.cgi?id=560352
> 
> Could a Fedora guru take a look at that and confirm that it works for 
> Fedora too?

Splitting off a gthumb-import.desktop sounds like a good idea.
Longer-term, we probably want a small dedicated photo-importer app,
since neither f-spot nor gthumb do a very good job at it...



From pbrobinson at gmail.com  Wed Nov 12 14:35:51 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 12 Nov 2008 14:35:51 +0000
Subject: starting Fedora Server SIG
In-Reply-To: <778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr> <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
Message-ID: <5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>

>> Once upon a time, Patrice Dumas <pertusus at free.fr> said:
>> > Fedora is not in a bad state with respect to fine grained dependencies
>> > (it was quite bad back, at least up to FC4), mostly
>> > * thanks to olpc,
>> > * to maintainers who reported these issues,
>> > * because there is always some space needed on the live disc
>> > * thanks to split to some -libs because of multilib issues.
>> >
>> > Unless it has been solved, there was still an issue with metacity (and
>> > maybe gnome) and themes interdependencies. Also there are still
>> > monolithic big beasts like texlive, but I am not sure that it is
>> > that desirable to fix those.
>>
>> I tried to install ntop on a firewall (minimal F9 install, tuned via
>> kickstart).  There were 70 packages added because of dependencies,
>> including metacity.
>
>
> I agree here...and I don't think Fedora is not in a bad state regarding
> fine-grained deps...
> if you want a point of comparison, take a look at Debian, maybe. Or the
> *BSD's.

Yes there are still issues, but its improving and just about every bug
I've filed for dependencies over the last couple of months has been
fixed quick and effectively (with only a few that will remain nameless
cause me issues). Maybe the Server SIG guys should have a tracking bug
for all these sort of things and people should file bugs against the
package and add it as a blocker to the Server SIG tracking bug (see
Fedora Mini tracking bug linked to off the SIG page as an example). So
if its a problem where's the bug report, I don't currently see any
open bugs against ntop at all which means the problem has either been
fixed, or the maintainer isn't aware there's an issue. Having a quick
look at the ntop rpm it looks like its the graphviz bit the pulls in
all the gnome stuff, no doubt that can be split out into a sub
package, as could probably the mysql and perl dependencies.

Regards,
Peter



From john.ellson at comcast.net  Wed Nov 12 14:49:55 2008
From: john.ellson at comcast.net (John Ellson)
Date: Wed, 12 Nov 2008 09:49:55 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>	<200811111317.15198.dennis@ausil.us>
	<4919DC9C.1030009@gmail.com>	<1226480816.3638.19.camel@eagle.danny.cz>	<1226485422.3638.22.camel@eagle.danny.cz>	<20081112110506.GA3142@free.fr>
	<20081112131806.GA1461854@hiwaay.net>	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
Message-ID: <491AED13.8050204@comcast.net>

Peter Robinson wrote:
>>> Once upon a time, Patrice Dumas <pertusus at free.fr> said:
>>>       
>>>> Fedora is not in a bad state with respect to fine grained dependencies
>>>>
>>>>         
>  So
> if its a problem where's the bug report, I don't currently see any
> open bugs against ntop at all which means the problem has either been
> fixed, or the maintainer isn't aware there's an issue. Having a quick
> look at the ntop rpm it looks like its the graphviz bit the pulls in
> all the gnome stuff, no doubt that can be split out into a sub
> package, as could probably the mysql and perl dependencies.
>
>   
Whats the issue with graphviz?

-- 
John Ellson



From pbrobinson at gmail.com  Wed Nov 12 15:00:05 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 12 Nov 2008 15:00:05 +0000
Subject: starting Fedora Server SIG
In-Reply-To: <491AED13.8050204@comcast.net>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr> <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
Message-ID: <5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>

>>>>> Fedora is not in a bad state with respect to fine grained dependencies
>>>>>
>>>>>
>>
>>  So
>> if its a problem where's the bug report, I don't currently see any
>> open bugs against ntop at all which means the problem has either been
>> fixed, or the maintainer isn't aware there's an issue. Having a quick
>> look at the ntop rpm it looks like its the graphviz bit the pulls in
>> all the gnome stuff, no doubt that can be split out into a sub
>> package, as could probably the mysql and perl dependencies.
>>
>>
>
> Whats the issue with graphviz?

Nothing per say. Its the case of ntop's dependency on it for a base
leve firewall/router style device it pulls in essentially the whole of
gnome. A quick look at graphviz's list of deps it looks like it has
split up the dependencies quite a bit. See the complaint about ntop
and it pulling in metacity further up in the thread.

Peter



From tibbs at math.uh.edu  Wed Nov 12 15:08:27 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 12 Nov 2008 09:08:27 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <491AED13.8050204@comcast.net>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr> <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
Message-ID: <ufa3ahxm178.fsf@epithumia.math.uh.edu>

>>>>> "JE" == John Ellson <john.ellson at comcast.net> writes:

JE> Whats the issue with graphviz?

It pulls in a bunch of gnome, but for purely command-line usage it
shouldn't even need X.

 - J<



From john.ellson at comcast.net  Wed Nov 12 15:12:25 2008
From: john.ellson at comcast.net (John Ellson)
Date: Wed, 12 Nov 2008 10:12:25 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>	<200811111317.15198.dennis@ausil.us>
	<4919DC9C.1030009@gmail.com>	<1226480816.3638.19.camel@eagle.danny.cz>	<1226485422.3638.22.camel@eagle.danny.cz>	<20081112110506.GA3142@free.fr>
	<20081112131806.GA1461854@hiwaay.net>	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
Message-ID: <491AF259.40907@comcast.net>

Peter Robinson wrote:
>>>>>> Fedora is not in a bad state with respect to fine grained dependencies
>>>>>>
>>>>>>
>>>>>>             
>>>  So
>>> if its a problem where's the bug report, I don't currently see any
>>> open bugs against ntop at all which means the problem has either been
>>> fixed, or the maintainer isn't aware there's an issue. Having a quick
>>> look at the ntop rpm it looks like its the graphviz bit the pulls in
>>> all the gnome stuff, no doubt that can be split out into a sub
>>> package, as could probably the mysql and perl dependencies.
>>>
>>>
>>>       
>> Whats the issue with graphviz?
>>     
>
> Nothing per say. Its the case of ntop's dependency on it for a base
> leve firewall/router style device it pulls in essentially the whole of
> gnome. A quick look at graphviz's list of deps it looks like it has
> split up the dependencies quite a bit. See the complaint about ntop
> and it pulling in metacity further up in the thread.
>
> Peter
>
>   
Are there guidelines somewhere on what packages should not be pulled in 
on a server?

Currently graphviz has a gtk+  renderer in its base package.  I can see 
that that could be separated.   What else?


-- 
John Ellson



From bruno at wolff.to  Wed Nov 12 15:12:34 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 12 Nov 2008 09:12:34 -0600
Subject: F10 Post-Preview snapshots?
In-Reply-To: <5f6f8c5f0811120454x40f7378ah6a8b20986cf01fe6@mail.gmail.com>
References: <5f6f8c5f0811111114i302752e4pb900c595ef0b0763@mail.gmail.com>
	<20081112030339.GA15403@wolff.to>
	<5f6f8c5f0811120454x40f7378ah6a8b20986cf01fe6@mail.gmail.com>
Message-ID: <20081112151234.GA311@wolff.to>

On Wed, Nov 12, 2008 at 13:54:52 +0100,
  "Joshua C." <joshuacov at googlemail.com> wrote:
> 
> I have i686 and want to try x86_64. therefore i downloaded livecd but
> because of a dsdt error i need to recompile the x86_64 kernel. this is
> not possible on i686 installation and the dsdt fix was committed to
> f10 kernel after the preview release.
> 
> Therefore I need a precompiled livecd image, which won't be released
> before stable :(

Rawhide has later kernels, so you might be able to build a Live CD yourself
without having to rebuild the kernel. I haven't tried to build a liveCD for
x86_64 on i386, but I would expect this to be possible.



From tibbs at math.uh.edu  Wed Nov 12 15:29:35 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 12 Nov 2008 09:29:35 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <491AF259.40907@comcast.net>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr> <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net>
Message-ID: <ufatzadklnk.fsf@epithumia.math.uh.edu>

>>>>> "JE" == John Ellson <john.ellson at comcast.net> writes:

JE> Are there guidelines somewhere on what packages should not be
JE> pulled in on a server?

One would figure that one of the goals of a server SIG would be to
define some.

 - J<



From nicolas.mailhot at laposte.net  Wed Nov 12 15:33:47 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 12 Nov 2008 16:33:47 +0100 (CET)
Subject: starting Fedora Server SIG
In-Reply-To: <5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr> <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
Message-ID: <816ac2ab305ba80cdab84efccd139a9d.squirrel@arekh.dyndns.org>



Le Mer 12 novembre 2008 15:35, Peter Robinson a ?crit :
> Maybe the Server SIG guys should have a tracking bug
> for all these sort of things and people should file bugs against the
> package and add it as a blocker to the Server SIG tracking bug (see
> Fedora Mini tracking bug linked to off the SIG page as an example).

In the fonts SIG we use a dedicated bug mailing list not a tracker bug.
The main advantage is you can CC upstream issue trackers to the list
instead of being limited to fedora bugzilla.

http://fedoraproject.org/wiki/Known_fonts_and_text_bugs

-- 
Nicolas Mailhot



From john.ellson at comcast.net  Wed Nov 12 15:56:33 2008
From: john.ellson at comcast.net (John Ellson)
Date: Wed, 12 Nov 2008 10:56:33 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <ufa3ahxm178.fsf@epithumia.math.uh.edu>
References: <1226429441.3593.77.camel@eagle.danny.cz>	<200811111317.15198.dennis@ausil.us>
	<4919DC9C.1030009@gmail.com>	<1226480816.3638.19.camel@eagle.danny.cz>	<1226485422.3638.22.camel@eagle.danny.cz>	<20081112110506.GA3142@free.fr>
	<20081112131806.GA1461854@hiwaay.net>	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>	<491AED13.8050204@comcast.net>
	<ufa3ahxm178.fsf@epithumia.math.uh.edu>
Message-ID: <491AFCB1.2090003@comcast.net>

Jason L Tibbitts III wrote:
>>>>>> "JE" == John Ellson <john.ellson at comcast.net> writes:
>>>>>>             
>
> JE> Whats the issue with graphviz?
>
> It pulls in a bunch of gnome, but for purely command-line usage it
> shouldn't even need X.
>   
Thats two different things.

Graphviz doesn't use X now for basic command line usage, but its core 
package includes
demand-loaded plugins  for X and gtk+.  

I could pull those out, I suppose, but note that pango, cairo, gd, 
librsvg2 all have X dependencies currently.

I'm guessing you will end up with X-client support on servers, in which 
case perhaps I just need to
pull out the gtk+ bits.

I'll wait for this proposed SIG to propose guidelines before I start 
splitting graphviz packages any further.


-- 
John Ellson



From promac at gmail.com  Wed Nov 12 16:19:13 2008
From: promac at gmail.com (Paulo Cavalcanti)
Date: Wed, 12 Nov 2008 14:19:13 -0200
Subject: iproute - Error: an inet prefix is expected rather than "0/0"
Message-ID: <68720af30811120819w33e6cc16r8c14b33623bcee34@mail.gmail.com>

Hi,

I updated iproute (2.6.26) today (F8), and every time I restart my network,
I get:

Shutting down interface eth0:  Error: an inet prefix is expected rather than
"0/0".
Error: an inet prefix is expected rather than "0/0".
                                                           [  OK  ]
Shutting down loopback interface:  Error: an inet prefix is expected rather
than "0/0".
Error: an inet prefix is expected rather than "0/0".
                                                           [  OK  ]
Disabling IPv4 packet forwarding:  net.ipv4.ip_forward = 0
                                                           [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:

According to this post, it seems to be fixed with
initscripts-8.80:

http://www.nabble.com/-Bug-42503--initscripts,-NEW:-Strange-error-messages-on-shutdown-td18824867.html

Can anyone confirm this?

Thanks.

-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081112/6ab85a66/attachment.htm>

From pertusus at free.fr  Wed Nov 12 16:29:13 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 12 Nov 2008 17:29:13 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <491AE00F.5010703@gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<778179b00811120400s5fda1277y2130ceddeb9d0422@mail.gmail.com>
	<1226491831.3752.298.camel@beck.corsepiu.local>
	<491AE00F.5010703@gmail.com>
Message-ID: <20081112162912.GA2725@free.fr>

On Wed, Nov 12, 2008 at 07:54:23AM -0600, Les Mikesell wrote:
>
> Even on machines where I never run an X display on the console, I often  
> find it extremely handy to have wireshark-gnome installed and run it via  
> ssh port-forwarding.   Likewise I might want to install VMware server  
> which needs X libs and perhaps a few other things on a machine that  
> doesn't run X on the console.  And on some other machines that I would  
> still classify as servers I run a whole desktop environment (or several)  
> remotely via freenx.  Are the packages split so you can easily get the X  
> libs, fonts, etc., without hardware related components?

Yes. The X server should never be required, nor any window manager.
(except that firstboot and system-config-display requires metacity
because they really use it). there is still the metacity issue I talked
about, and that was reported months ago, without success, but otherwise
I am not aware of such issues.

--
Pat



From stickster at gmail.com  Wed Nov 12 12:52:50 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Wed, 12 Nov 2008 07:52:50 -0500
Subject: Fedora Board IRC meeting 1800 UTC 2008-11-18
Message-ID: <20081112125250.GA6439@localhost.localdomain>

The Board is holding its monthly public meeting on Tuesday, 18 November
2008, at 1800 UTC on IRC Freenode.  The public is invited to do the
following:

* Join #fedora-board-meeting to see the Board's conversation.  This
channel is read-only for non-Board members.
* Join #fedora-board-public to discuss topics and post questions.  This
channel is read/write for everyone.

The moderator will direct questions from the #fedora-board-public
channel to the Board members at #fedora-board-meeting.  This should limit
confusion and ensure our logs are useful to everyone.

We look forward to seeing you at the meeting.

-- 
Paul W. Frields
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://paul.frields.org/   -  -   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/20081112/f50363ef/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 notting at redhat.com  Wed Nov 12 16:45:44 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 12 Nov 2008 11:45:44 -0500
Subject: F8 EOL messaging
In-Reply-To: <20081112010144.GE8501@localhost.localdomain>
References: <20081112010144.GE8501@localhost.localdomain>
Message-ID: <20081112164544.GB6260@nostromo.devel.redhat.com>

Paul W. Frields (stickster at gmail.com) said: 
> It seems really wrong to EOL F8 on Christmas Day.  Can we make that
> December 26th? :-)

Hm, I suppose part of it is 'when do we have someone available to do
the final update push?'

Bill



From lesmikesell at gmail.com  Wed Nov 12 16:46:43 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 12 Nov 2008 10:46:43 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <491A6E59.3070803@leemhuis.info>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>	<49190741.6090902@gmail.com>	<20081111090721.928d792a.mschwendt@gmail.com>	<49198DC9.3030609@gmail.com>	<20081111161642.711a1d5d.mschwendt@gmail.com>	<4919ADA0.1050900@gmail.com>	<16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>	<4919B525.3070300@gmail.com>	<1226422090.3417.23.camel@localhost.localdomain>	<4919BE5C.9050001@gmail.com>	<20081111204717.GB15724@orient.maison.lan>	<4919F7C5.1090705@gmail.com>	<1226439740.10458.15.camel@luminos.localdomain>
	<491A6E59.3070803@leemhuis.info>
Message-ID: <491B0873.50503@gmail.com>

Thorsten Leemhuis wrote:
> On 11.11.2008 22:42, Jesse Keating wrote:
>> On Tue, 2008-11-11 at 15:23 -0600, Les Mikesell wrote:
>>> Which repos have a chance to rebuild against new fedora libraries 
>>> before they are publicly available so a user updating with both 
>>> enabled won't experience conflicts?
>> Every repo.  Our build roots are public and static repo locations are
>> updated hourly with their contents.  It's all public, anybody in the
>> would can access it.
> 
> As someone that takes care of a 3rd party repo I can mostly agree to 
> this statement from Jesse. But there is one important thing that is not 
> really foreseeable for the public: Pushes to the stable or testing 
> updates repos.
> 
> They just happen suddenly out of the blue and I as 3rd party repo 
> manager have no real chance to do push at exactly the same time. All a 
> 3rd party repo manager can do is to watch fedora-announce-list closely 
> and push packages that have dependencies on specific Fedora packages 
> (xine-lib-extras-nonfree, qmmp-plugins-freeworld, all kmods, some 
> others) once he sees that Fedora did the push.
> 
> That is one of the big problems. Another one: Dependency problems due to 
> mirror lags afaik confuse yum (at least on F8 and F9). Details can be 
> found here:
> http://www.redhat.com/archives/rhl-devel-list/2008-August/msg00041.html

Thank you! That's exactly the point of view that needs to be emphasized 
here, both with respect to the people trying to cooperate with the 
fedora distribution and the users who are affected.

Every time I try to point out the need for 3rd party add-ons here, the 
discussion degenerates into useless rationalization as to why the entire 
universe can't live in the fedora repository. But it doesn't matter why. 
The fact is that it doesn't, never will, and it would be a bad idea for 
everyone to rely on a single source for their critical applications 
even if they could.  We just need an understanding that people will 
always need additional software and they need it to not break when 
updates are pushed out - and if that can't be fixed, next best would be 
a way to back out the breakage or run old/new in parallel while fixing 
compatibility.

-- 
   Les Mikesell
     lesmikesell at gmail




From mw_triad at users.sourceforge.net  Wed Nov 12 16:50:39 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 12 Nov 2008 10:50:39 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <5256d0b0811120353y4b3d076bra38ffcbf71a021b5@mail.gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>	<200811111317.15198.dennis@ausil.us>
	<4919DC9C.1030009@gmail.com>	<1226480816.3638.19.camel@eagle.danny.cz>	<1226485422.3638.22.camel@eagle.danny.cz>	<20081112111712.GB3142@free.fr>
	<5256d0b0811120353y4b3d076bra38ffcbf71a021b5@mail.gmail.com>
Message-ID: <gff1h2$spb$1@ger.gmane.org>

Peter Robinson wrote:
> I'm also not quite sure why old not often used tools like ypbind,
> rsh, rdate, rdate are set as default either.

Is something other than ypbind is doing NIS these days?

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
I sure hope they never make a hearse out of a Scion. I wouldn't want to 
be caught dead in one.



From jspaleta at gmail.com  Wed Nov 12 16:51:40 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 12 Nov 2008 07:51:40 -0900
Subject: Proposal: Rolling Release
In-Reply-To: <491B0873.50503@gmail.com>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>
	<4919B525.3070300@gmail.com>
	<1226422090.3417.23.camel@localhost.localdomain>
	<4919BE5C.9050001@gmail.com>
	<20081111204717.GB15724@orient.maison.lan>
	<4919F7C5.1090705@gmail.com>
	<1226439740.10458.15.camel@luminos.localdomain>
	<491A6E59.3070803@leemhuis.info> <491B0873.50503@gmail.com>
Message-ID: <604aa7910811120851u361eac4sc4c05c2baf57fda4@mail.gmail.com>

On Wed, Nov 12, 2008 at 7:46 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
>- and if that can't be fixed, next best would be a way to back out the
> breakage or run old/new in parallel while fixing compatibility.

yum allowdowngrade plugin doesn't do what you need?

-jef



From alsadi at gmail.com  Wed Nov 12 16:58:38 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Wed, 12 Nov 2008 18:58:38 +0200
Subject: Proposal: Rolling Release
In-Reply-To: <491B0873.50503@gmail.com>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>
	<4919B525.3070300@gmail.com>
	<1226422090.3417.23.camel@localhost.localdomain>
	<4919BE5C.9050001@gmail.com>
	<20081111204717.GB15724@orient.maison.lan>
	<4919F7C5.1090705@gmail.com>
	<1226439740.10458.15.camel@luminos.localdomain>
	<491A6E59.3070803@leemhuis.info> <491B0873.50503@gmail.com>
Message-ID: <385866f0811120858u38105e32p4b61d7715f055a75@mail.gmail.com>

I'm aware of rss feeds in
https://admin.fedoraproject.org/updates/f10/testing, but I ask for
more

let's say I'm a 3rd party repo maintainer and I maintain a package
which depends on xulrunner like let's say mplayer-plugin or something
like that

can we has a per-package feeds (regardless of version)
so I can subscript to the rss feed of the packages I need and I watch
them being pushed from pending to testing to stable



From pertusus at free.fr  Wed Nov 12 17:01:03 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 12 Nov 2008 18:01:03 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <gff1h2$spb$1@ger.gmane.org>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<5256d0b0811120353y4b3d076bra38ffcbf71a021b5@mail.gmail.com>
	<gff1h2$spb$1@ger.gmane.org>
Message-ID: <20081112170103.GB2725@free.fr>

On Wed, Nov 12, 2008 at 10:50:39AM -0600, Matthew Woehlke wrote:
> Peter Robinson wrote:
>> I'm also not quite sure why old not often used tools like ypbind,
>> rsh, rdate, rdate are set as default either.
>
> Is something other than ypbind is doing NIS these days?

No, so ypbind is really needed in @base. And I guess that it is rather
small and don't have too many deps.

--
Pat



From jkeating at redhat.com  Wed Nov 12 17:06:43 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 12 Nov 2008 09:06:43 -0800
Subject: Proposal: Rolling Release
In-Reply-To: <385866f0811120858u38105e32p4b61d7715f055a75@mail.gmail.com>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>
	<4919B525.3070300@gmail.com>
	<1226422090.3417.23.camel@localhost.localdomain>
	<4919BE5C.9050001@gmail.com> <20081111204717.GB15724@orient.maison.lan>
	<4919F7C5.1090705@gmail.com>
	<1226439740.10458.15.camel@luminos.localdomain>
	<491A6E59.3070803@leemhuis.info> <491B0873.50503@gmail.com>
	<385866f0811120858u38105e32p4b61d7715f055a75@mail.gmail.com>
Message-ID: <1226509604.10774.4.camel@luminos.localdomain>

On Wed, 2008-11-12 at 18:58 +0200, Muayyad AlSadi wrote:
> 
> can we has a per-package feeds (regardless of version)
> so I can subscript to the rss feed of the packages I need and I watch
> them being pushed from pending to testing to stable

In theory you can get rss feeds out of koji itself.  But you may have to
filter that feed into the packages you care about.

I haven't played much with the koji rss feeding in a while.

-- 
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/20081112/bbe34c36/attachment.sig>

From notting at redhat.com  Wed Nov 12 17:08:05 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 12 Nov 2008 12:08:05 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
Message-ID: <20081112170805.GC6260@nostromo.devel.redhat.com>

Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> > and it is less right, X is brought in, and also qt qt-X11. Should
> > certainly be investigated.
> 
> That's probably because of LSB compliance. As has been discussed
> previously, someone needs to split the lsb package in server-side
> stuff and other stuff (yes that would mean a system that used only the
> first part would not be fully lsb compliant)

Alternatively... make it optional? Is LSB conformance required
for a minimal install?

Bill



From notting at redhat.com  Wed Nov 12 17:10:37 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 12 Nov 2008 12:10:37 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <5256d0b0811120353y4b3d076bra38ffcbf71a021b5@mail.gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<5256d0b0811120353y4b3d076bra38ffcbf71a021b5@mail.gmail.com>
Message-ID: <20081112171037.GD6260@nostromo.devel.redhat.com>

Peter Robinson (pbrobinson at gmail.com) said: 
> For some reason redhat-lsb pulls in qt, qt-X11 and qt3. redhat-lsb is
> certainly something you'd probably want in a server environment but no
> idea why it would need qt. Its also a 'default' in base. I'm also not
> quite sure why old not often used tools like ypbind, rsh, rdate, rdate
> are set as default either. Anyone that would need to use those style
> systems would also know how to install them.

I wonder if authconfig could be taught to install packages; at
the moment, it expects the components it configures to be installed,
and simply disables the configuration bits for those components that
aren't.

Bill



From jspaleta at gmail.com  Wed Nov 12 17:11:15 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 12 Nov 2008 08:11:15 -0900
Subject: starting Fedora Server SIG
In-Reply-To: <20081112170805.GC6260@nostromo.devel.redhat.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<20081112170805.GC6260@nostromo.devel.redhat.com>
Message-ID: <604aa7910811120911x465761a4pf7aeb6f877fb87e@mail.gmail.com>

On Wed, Nov 12, 2008 at 8:08 AM, Bill Nottingham <notting at redhat.com> wrote:
> Alternatively... make it optional? Is LSB conformance required
> for a minimal install?


I think the point was.. if the LSB as a different spec for "core" and
"desktop" etc.... make it possible to layer up a system in the same
ways that the LSB is layered... so you can have an LSB core compliant
system when its appropriate to not need an LSB Desktop compliant
system.

-jef



From dan at danny.cz  Wed Nov 12 17:16:00 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Wed, 12 Nov 2008 18:16:00 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <20081112170805.GC6260@nostromo.devel.redhat.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<20081112170805.GC6260@nostromo.devel.redhat.com>
Message-ID: <1226510160.3638.28.camel@eagle.danny.cz>


Bill Nottingham p??e v St 12. 11. 2008 v 12:08 -0500:
> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> > > and it is less right, X is brought in, and also qt qt-X11. Should
> > > certainly be investigated.
> > 
> > That's probably because of LSB compliance. As has been discussed
> > previously, someone needs to split the lsb package in server-side
> > stuff and other stuff (yes that would mean a system that used only the
> > first part would not be fully lsb compliant)
> 
> Alternatively... make it optional? Is LSB conformance required
> for a minimal install?

IMHO LSB Core conformance should be required in minimal install


		Dan




From pertusus at free.fr  Wed Nov 12 17:31:37 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 12 Nov 2008 18:31:37 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <1226510160.3638.28.camel@eagle.danny.cz>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<20081112170805.GC6260@nostromo.devel.redhat.com>
	<1226510160.3638.28.camel@eagle.danny.cz>
Message-ID: <20081112173137.GC2725@free.fr>

On Wed, Nov 12, 2008 at 06:16:00PM +0100, Dan Hor?k wrote:
> 
> IMHO LSB Core conformance should be required in minimal install

Not LSB-Desktop. Rule of thumb should (in my opinion) be that @base 
should not bring in X or gnome/qt/gtk...

--
Pat



From james at fedoraproject.org  Wed Nov 12 17:37:24 2008
From: james at fedoraproject.org (James Antill)
Date: Wed, 12 Nov 2008 12:37:24 -0500
Subject: Proposal: Rolling Release
In-Reply-To: <604aa7910811120851u361eac4sc4c05c2baf57fda4@mail.gmail.com>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>
	<4919B525.3070300@gmail.com>
	<1226422090.3417.23.camel@localhost.localdomain>
	<4919BE5C.9050001@gmail.com> <20081111204717.GB15724@orient.maison.lan>
	<4919F7C5.1090705@gmail.com>
	<1226439740.10458.15.camel@luminos.localdomain>
	<491A6E59.3070803@leemhuis.info> <491B0873.50503@gmail.com>
	<604aa7910811120851u361eac4sc4c05c2baf57fda4@mail.gmail.com>
Message-ID: <1226511444.22230.133.camel@code.and.org>

On Wed, 2008-11-12 at 07:51 -0900, Jeff Spaleta wrote:
> On Wed, Nov 12, 2008 at 7:46 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> >- and if that can't be fixed, next best would be a way to back out the
> > breakage or run old/new in parallel while fixing compatibility.
> 
> yum allowdowngrade plugin doesn't do what you need?

 It doesn't work on any recent yum ... it's on the TODO list to fix it
for soon after Fedora 10 is released though (maybe for the zero day we
are planning, maybe the one after that).

-- 
James Antill <james at fedoraproject.org>
Fedora



From lesmikesell at gmail.com  Wed Nov 12 17:37:34 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 12 Nov 2008 11:37:34 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <604aa7910811120851u361eac4sc4c05c2baf57fda4@mail.gmail.com>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>	<16de708d0811110811t14b21c56m918a479a2614c766@mail.gmail.com>	<4919B525.3070300@gmail.com>	<1226422090.3417.23.camel@localhost.localdomain>	<4919BE5C.9050001@gmail.com>	<20081111204717.GB15724@orient.maison.lan>	<4919F7C5.1090705@gmail.com>	<1226439740.10458.15.camel@luminos.localdomain>	<491A6E59.3070803@leemhuis.info>
	<491B0873.50503@gmail.com>
	<604aa7910811120851u361eac4sc4c05c2baf57fda4@mail.gmail.com>
Message-ID: <491B145E.3020900@gmail.com>

Jeff Spaleta wrote:
> On Wed, Nov 12, 2008 at 7:46 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
>> - and if that can't be fixed, next best would be a way to back out the
>> breakage or run old/new in parallel while fixing compatibility.
> 
> yum allowdowngrade plugin doesn't do what you need?
> 

It might if I knew when and how to use it.  Would that be obvious if 
some 3rd party or local program(s) no longer worked some time after an 
update?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jspaleta at gmail.com  Wed Nov 12 17:44:47 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 12 Nov 2008 08:44:47 -0900
Subject: Proposal: Rolling Release
In-Reply-To: <491B145E.3020900@gmail.com>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<1226422090.3417.23.camel@localhost.localdomain>
	<4919BE5C.9050001@gmail.com>
	<20081111204717.GB15724@orient.maison.lan>
	<4919F7C5.1090705@gmail.com>
	<1226439740.10458.15.camel@luminos.localdomain>
	<491A6E59.3070803@leemhuis.info> <491B0873.50503@gmail.com>
	<604aa7910811120851u361eac4sc4c05c2baf57fda4@mail.gmail.com>
	<491B145E.3020900@gmail.com>
Message-ID: <604aa7910811120944r81e6b8bsc23ef3ef60d2bd69@mail.gmail.com>

On Wed, Nov 12, 2008 at 8:37 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> It might if I knew when and how to use it.  Would that be obvious if some
> 3rd party or local program(s) no longer worked some time after an update?

How does anyone with a niche need know about the existence of any
capability in our software collection that is not installed by
default? That's a deep question. Far deeper than I think you are
prepared to discuss.

-jef



From jspaleta at gmail.com  Wed Nov 12 17:44:47 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 12 Nov 2008 08:44:47 -0900
Subject: Proposal: Rolling Release
In-Reply-To: <491B145E.3020900@gmail.com>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<1226422090.3417.23.camel@localhost.localdomain>
	<4919BE5C.9050001@gmail.com>
	<20081111204717.GB15724@orient.maison.lan>
	<4919F7C5.1090705@gmail.com>
	<1226439740.10458.15.camel@luminos.localdomain>
	<491A6E59.3070803@leemhuis.info> <491B0873.50503@gmail.com>
	<604aa7910811120851u361eac4sc4c05c2baf57fda4@mail.gmail.com>
	<491B145E.3020900@gmail.com>
Message-ID: <604aa7910811120944r81e6b8bsc23ef3ef60d2bd69@mail.gmail.com>

On Wed, Nov 12, 2008 at 8:37 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> It might if I knew when and how to use it.  Would that be obvious if some
> 3rd party or local program(s) no longer worked some time after an update?

How does anyone with a niche need know about the existence of any
capability in our software collection that is not installed by
default? That's a deep question. Far deeper than I think you are
prepared to discuss.

-jef



From jspaleta at gmail.com  Wed Nov 12 17:44:47 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 12 Nov 2008 08:44:47 -0900
Subject: Proposal: Rolling Release
In-Reply-To: <491B145E.3020900@gmail.com>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<1226422090.3417.23.camel@localhost.localdomain>
	<4919BE5C.9050001@gmail.com>
	<20081111204717.GB15724@orient.maison.lan>
	<4919F7C5.1090705@gmail.com>
	<1226439740.10458.15.camel@luminos.localdomain>
	<491A6E59.3070803@leemhuis.info> <491B0873.50503@gmail.com>
	<604aa7910811120851u361eac4sc4c05c2baf57fda4@mail.gmail.com>
	<491B145E.3020900@gmail.com>
Message-ID: <604aa7910811120944r81e6b8bsc23ef3ef60d2bd69@mail.gmail.com>

On Wed, Nov 12, 2008 at 8:37 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> It might if I knew when and how to use it.  Would that be obvious if some
> 3rd party or local program(s) no longer worked some time after an update?

How does anyone with a niche need know about the existence of any
capability in our software collection that is not installed by
default? That's a deep question. Far deeper than I think you are
prepared to discuss.

-jef



From herrold at owlriver.com  Wed Nov 12 17:55:47 2008
From: herrold at owlriver.com (R P Herrold)
Date: Wed, 12 Nov 2008 12:55:47 -0500 (EST)
Subject: LSB; was: Re: starting Fedora Server SIG
Message-ID: <alpine.LRH.2.00.0811121232000.20680@arj.bjyevire.pbz>

Sorry to come late to this discussion and break fedora-devel 
ML threading, as I am working from the web archive (I had 
tossed the underlying pieces already)

Dan Hor?k at Wed, 12 Nov 2008 18:16:00 +0100:

> IMHO LSB Core conformance should be required in minimal 
> install

Sadly, as a long time participant in the LSB process, I would 
offer that there is not a well defined subset such as 'LSB 
Core' (and adjuncts or extensions such as: 'LSB Desktop', 'LSB 
Mobile Device', 'LSB Headless') are not a way that the LSB 
decided to go in 4.0 initial (the next scheduled release, due 
out later this year).  This is in part from a lack of 
developer mass and consensus.

LSB has a weekly conference call open to all contributors to 
the LSB; its mailing list is open as are its archives {some 
process happens 'out of sight' which is out of scope here}. 
Mats Wichmann and I have been at OLS, and the LSB BOFH or 
presentation for the last few years has drawn few attendees, 
and sadly either just the 'usual suspects' or people looking 
for a seat in a reasonably empty and quiet presentation room 
;)

archive:
    http://lists.linux-foundation.org/pipermail/lsb-discuss
subscription:
    https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss

Earlier, Peter Robinson at Wed, 12 Nov 2008 11:53:21 +0000

> For some reason redhat-lsb pulls in qt, qt-X11 and qt3. 
> redhat-lsb is certainly something you'd probably want in a 
> server environment but no idea why it would need qt

This being an 'redhat-lsb' lsb in the 3.x series.

LSB 4 is in release testing, and 'slops' all sorts of 'goop' 
in to a 'conformant' installation: sound, printing, X, and GUI 
widget sets, ... and more, in.  The 'use case' was that the 
ISV's needed each to be predictably present.

I predict that when LSB 4.0 releases, there will be much 
wailing and gnashing of teeth, because no-one from Fedora has 
'been at the table' arguing (and getting the consensus and 
running code in place for) the 'Server SIG' need case.

A year ago, and periodically, lone voices contributors to the 
LSB in the server wilderness, cry out:
 	Enough to the LSB

but no-one steps up to suggest the subset [and then to do the 
repackaging (breaking off the one GUI dep that 'Requires in 
much unwanted (in a server environment) GUI 'goop') in support 
within the distributions] to elide such cruft not wanted in a 
'server' environment.

LSB is willing and interested in having a sensible discussion, 
and reaching specification of such a 'subset'; this seems like 
a natural for people in a Fedora Server SIG to collaborate and 
participate with this 'upstream' at LSB.

In the weekly conference call today, it was clear that such an 
effort do advance a rational subset would be entertained (not 
in the initial 4.0, probably -- it is past feature freeze 
there, but later in that series)

Please join in.

-- Russ herrold



From lesmikesell at gmail.com  Wed Nov 12 18:00:22 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 12 Nov 2008 12:00:22 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <604aa7910811120944r81e6b8bsc23ef3ef60d2bd69@mail.gmail.com>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>	<1226422090.3417.23.camel@localhost.localdomain>	<4919BE5C.9050001@gmail.com>	<20081111204717.GB15724@orient.maison.lan>	<4919F7C5.1090705@gmail.com>	<1226439740.10458.15.camel@luminos.localdomain>	<491A6E59.3070803@leemhuis.info>
	<491B0873.50503@gmail.com>	<604aa7910811120851u361eac4sc4c05c2baf57fda4@mail.gmail.com>	<491B145E.3020900@gmail.com>
	<604aa7910811120944r81e6b8bsc23ef3ef60d2bd69@mail.gmail.com>
Message-ID: <491B19B6.40509@gmail.com>

Jeff Spaleta wrote:
> On Wed, Nov 12, 2008 at 8:37 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
>> It might if I knew when and how to use it.  Would that be obvious if some
>> 3rd party or local program(s) no longer worked some time after an update?
> 
> How does anyone with a niche need know about the existence of any
> capability in our software collection that is not installed by
> default? That's a deep question. Far deeper than I think you are
> prepared to discuss.

That's the wrong question.  The real question is, what interface did you 
just break in an update? You don't need to know anything about anyone 
else's software.  You just need to provide working interfaces.  Or, when 
you whimsically break them in updates, give a hint about how to get a 
working version back.

-- 
    Les Mikesell
     lesmikesell at gmail.com





From skvidal at fedoraproject.org  Wed Nov 12 18:06:00 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 12 Nov 2008 13:06:00 -0500 (EST)
Subject: starting Fedora Server SIG
In-Reply-To: <1226510160.3638.28.camel@eagle.danny.cz>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<20081112170805.GC6260@nostromo.devel.redhat.com>
	<1226510160.3638.28.camel@eagle.danny.cz>
Message-ID: <alpine.LFD.2.00.0811121305350.31693@localhost.localdomain>



On Wed, 12 Nov 2008, Dan Hor?k wrote:

>
> Bill Nottingham p??e v St 12. 11. 2008 v 12:08 -0500:
>> Nicolas Mailhot (nicolas.mailhot at laposte.net) said:
>>>> and it is less right, X is brought in, and also qt qt-X11. Should
>>>> certainly be investigated.
>>>
>>> That's probably because of LSB compliance. As has been discussed
>>> previously, someone needs to split the lsb package in server-side
>>> stuff and other stuff (yes that would mean a system that used only the
>>> first part would not be fully lsb compliant)
>>
>> Alternatively... make it optional? Is LSB conformance required
>> for a minimal install?
>
> IMHO LSB Core conformance should be required in minimal install
>

Why? LSB compliance should be an OPTION you can choose to have but it 
doesn't need to be there for a system work very well.

-sv

From tcallawa at redhat.com  Wed Nov 12 18:04:50 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 12 Nov 2008 13:04:50 -0500
Subject: LSB; was: Re: starting Fedora Server SIG
In-Reply-To: <alpine.LRH.2.00.0811121232000.20680@arj.bjyevire.pbz>
References: <alpine.LRH.2.00.0811121232000.20680@arj.bjyevire.pbz>
Message-ID: <1226513090.5519.22.camel@localhost.localdomain>

On Wed, 2008-11-12 at 12:55 -0500, R P Herrold wrote:
> I predict that when LSB 4.0 releases, there will be much 
> wailing and gnashing of teeth, because no-one from Fedora has 
> 'been at the table' arguing (and getting the consensus and 
> running code in place for) the 'Server SIG' need case.

Either that, or we'll just choose to ignore LSB, like, say, every Linux
ISV does.

Don't get me wrong, the idea of an LSB is sound, but somewhere between
implementation and adoption, things somehow went wrong, and we ended up
with ManBearPig.

~spot



From nicolas.mailhot at laposte.net  Wed Nov 12 18:07:18 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 12 Nov 2008 19:07:18 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <20081112171037.GD6260@nostromo.devel.redhat.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<5256d0b0811120353y4b3d076bra38ffcbf71a021b5@mail.gmail.com>
	<20081112171037.GD6260@nostromo.devel.redhat.com>
Message-ID: <1226513238.18648.1.camel@arekh.okg>

Le mercredi 12 novembre 2008 ? 12:10 -0500, Bill Nottingham a ?crit :
> Peter Robinson (pbrobinson at gmail.com) said: 
> > For some reason redhat-lsb pulls in qt, qt-X11 and qt3. redhat-lsb is
> > certainly something you'd probably want in a server environment but no
> > idea why it would need qt. Its also a 'default' in base. I'm also not
> > quite sure why old not often used tools like ypbind, rsh, rdate, rdate
> > are set as default either. Anyone that would need to use those style
> > systems would also know how to install them.
> 
> I wonder if authconfig could be taught to install packages; at
> the moment, it expects the components it configures to be installed,
> and simply disables the configuration bits for those components that
> aren't.

The PK people would be happy to plug this in, though if the authconfig
bit is necessary to open a session you're out of luck.

-- 
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/20081112/f25bcfb1/attachment.sig>

From jkeating at redhat.com  Wed Nov 12 18:20:01 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 12 Nov 2008 10:20:01 -0800
Subject: starting Fedora Server SIG
In-Reply-To: <1226510160.3638.28.camel@eagle.danny.cz>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<20081112170805.GC6260@nostromo.devel.redhat.com>
	<1226510160.3638.28.camel@eagle.danny.cz>
Message-ID: <1226514001.5295.0.camel@luminos.localdomain>

On Wed, 2008-11-12 at 18:16 +0100, Dan Hor?k wrote:
> IMHO LSB Core conformance should be required in minimal install

I disagree pretty strongly with that.  Default?  Sure.  Should I be able
to opt-out of it?  Absolutely.

-- 
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/20081112/40f653a5/attachment.sig>

From lesmikesell at gmail.com  Wed Nov 12 18:34:58 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 12 Nov 2008 12:34:58 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811121305350.31693@localhost.localdomain>
References: <1226429441.3593.77.camel@eagle.danny.cz>	<200811111317.15198.dennis@ausil.us>
	<4919DC9C.1030009@gmail.com>	<1226480816.3638.19.camel@eagle.danny.cz>	<1226485422.3638.22.camel@eagle.danny.cz>	<20081112111712.GB3142@free.fr>	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>	<20081112170805.GC6260@nostromo.devel.redhat.com>	<1226510160.3638.28.camel@eagle.danny.cz>
	<alpine.LFD.2.00.0811121305350.31693@localhost.localdomain>
Message-ID: <491B21D2.4010104@gmail.com>

Seth Vidal wrote:
> 
>>>>> and it is less right, X is brought in, and also qt qt-X11. Should
>>>>> certainly be investigated.
>>>>
>>>> That's probably because of LSB compliance. As has been discussed
>>>> previously, someone needs to split the lsb package in server-side
>>>> stuff and other stuff (yes that would mean a system that used only the
>>>> first part would not be fully lsb compliant)
>>>
>>> Alternatively... make it optional? Is LSB conformance required
>>> for a minimal install?
>>
>> IMHO LSB Core conformance should be required in minimal install
>>
> 
> Why? LSB compliance should be an OPTION you can choose to have but it 
> doesn't need to be there for a system work very well.
>

The LSB really has no value at all until you can assume that all systems 
   comply.  So yes you can make it optional, but doing so makes it 
useless baggage for everyone else too.

On the other hand, I'd really like to see a pre-install stage with the 
absolute minimum required to reboot and tell yum to get the other things 
you want.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From promac at gmail.com  Wed Nov 12 18:13:38 2008
From: promac at gmail.com (Paulo Cavalcanti)
Date: Wed, 12 Nov 2008 16:13:38 -0200
Subject: iproute - Error: an inet prefix is expected rather than "0/0"
In-Reply-To: <68720af30811120819w33e6cc16r8c14b33623bcee34@mail.gmail.com>
References: <68720af30811120819w33e6cc16r8c14b33623bcee34@mail.gmail.com>
Message-ID: <68720af30811121013p49a81788xe080e1640084f8b@mail.gmail.com>

On Wed, Nov 12, 2008 at 2:19 PM, Paulo Cavalcanti <promac at gmail.com> wrote:

> Hi,
>
> I updated iproute (2.6.26) today (F8), and every time I restart my network,
> I get:
>
> Shutting down interface eth0:  Error: an inet prefix is expected rather
> than "0/0".
> Error: an inet prefix is expected rather than "0/0".
>                                                            [  OK  ]
> Shutting down loopback interface:  Error: an inet prefix is expected rather
> than "0/0".
> Error: an inet prefix is expected rather than "0/0".
>                                                            [  OK  ]
> Disabling IPv4 packet forwarding:  net.ipv4.ip_forward = 0
>                                                            [  OK  ]
> Bringing up loopback interface:                            [  OK  ]
> Bringing up interface eth0:
>
> According to this post, it seems to be fixed with
> initscripts-8.80:
>
>
> http://www.nabble.com/-Bug-42503--initscripts,-NEW:-Strange-error-messages-on-shutdown-td18824867.html
>
> Can anyone confirm this?
>
> Thanks.
>

In fact it has been fixed in initscripts 0.82


* Wed Sep 10 2008 Bill Nottingham <notting at redhat.com> - 8.82-1
- refresh translation strings
- plymouth updates. (#460702, <rstrode at redhat.com>)
- translation updates: fi, lv, no
- remove duplicate dependency (#465182)
- ifup-eth: Change how we set the zeroconf route. (#239609)
- ifup*: Use 0.0.0.0/0, not 0/0. (#460580)

and the fix is easy. Just the files

/etc/sysconfig/network-scripts/network-functions

/etc/sysconfig/network-scripts/ifup-ppp

use 0/0


-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081112/3c82d07c/attachment.htm>

From ajax at redhat.com  Wed Nov 12 18:45:48 2008
From: ajax at redhat.com (Adam Jackson)
Date: Wed, 12 Nov 2008 13:45:48 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <491AE00F.5010703@gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>	<20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<778179b00811120400s5fda1277y2130ceddeb9d0422@mail.gmail.com>
	<1226491831.3752.298.camel@beck.corsepiu.local>
	<491AE00F.5010703@gmail.com>
Message-ID: <1226515548.31982.403.camel@atropine.boston.devel.redhat.com>

On Wed, 2008-11-12 at 07:54 -0600, Les Mikesell wrote:

> Even on machines where I never run an X display on the console, I often 
> find it extremely handy to have wireshark-gnome installed and run it via 
> ssh port-forwarding.   Likewise I might want to install VMware server 
> which needs X libs and perhaps a few other things on a machine that 
> doesn't run X on the console.  And on some other machines that I would 
> still classify as servers I run a whole desktop environment (or several) 
> remotely via freenx.  Are the packages split so you can easily get the X 
> libs, fonts, etc., without hardware related components?

Yes, they are.  On an install without any X components, 'yum install
gnome-terminal' will pull in X libs but not an X server.

- 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/20081112/7a91185a/attachment.sig>

From jkeating at redhat.com  Wed Nov 12 18:49:29 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 12 Nov 2008 10:49:29 -0800
Subject: starting Fedora Server SIG
In-Reply-To: <491B21D2.4010104@gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>	<20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<20081112170805.GC6260@nostromo.devel.redhat.com>
	<1226510160.3638.28.camel@eagle.danny.cz>
	<alpine.LFD.2.00.0811121305350.31693@localhost.localdomain>
	<491B21D2.4010104@gmail.com>
Message-ID: <1226515769.5295.4.camel@luminos.localdomain>

On Wed, 2008-11-12 at 12:34 -0600, Les Mikesell wrote:
> On the other hand, I'd really like to see a pre-install stage with the 
> absolute minimum required to reboot and tell yum to get the other things 
> you want.

that's basically @core.

-- 
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/20081112/e09e3a45/attachment.sig>

From jkeating at redhat.com  Wed Nov 12 18:53:07 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 12 Nov 2008 10:53:07 -0800
Subject: starting Fedora Server SIG
In-Reply-To: <1226515548.31982.403.camel@atropine.boston.devel.redhat.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>	<20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<778179b00811120400s5fda1277y2130ceddeb9d0422@mail.gmail.com>
	<1226491831.3752.298.camel@beck.corsepiu.local>
	<491AE00F.5010703@gmail.com>
	<1226515548.31982.403.camel@atropine.boston.devel.redhat.com>
Message-ID: <1226515988.5295.5.camel@luminos.localdomain>

On Wed, 2008-11-12 at 13:45 -0500, Adam Jackson wrote:
> Yes, they are.  On an install without any X components, 'yum install
> gnome-terminal' will pull in X libs but not an X server.
> 

In fact, if you install the gnome desktop group, but don't check the X
group, you get gnome but not X server to run it 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/20081112/c95e0dd9/attachment.sig>

From limb at jcomserv.net  Wed Nov 12 19:00:40 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Wed, 12 Nov 2008 13:00:40 -0600 (CST)
Subject: starting Fedora Server SIG
In-Reply-To: <1226515988.5295.5.camel@luminos.localdomain>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<778179b00811120400s5fda1277y2130ceddeb9d0422@mail.gmail.com>
	<1226491831.3752.298.camel@beck.corsepiu.local>
	<491AE00F.5010703@gmail.com>
	<1226515548.31982.403.camel@atropine.boston.devel.redhat.com>
	<1226515988.5295.5.camel@luminos.localdomain>
Message-ID: <71051a5a7ff9f9bc8da6c383a4ba235c.squirrel@mail.jcomserv.net>


> On Wed, 2008-11-12 at 13:45 -0500, Adam Jackson wrote:
>> Yes, they are.  On an install without any X components, 'yum install
>> gnome-terminal' will pull in X libs but not an X server.
>>
>
> In fact, if you install the gnome desktop group, but don't check the X
> group, you get gnome but not X server to run it on.

Perfect for ssh tunneling or a freenx server.

> --
> 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


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

-d. bowie



From chitlesh.goorah at gmail.com  Wed Nov 12 19:11:21 2008
From: chitlesh.goorah at gmail.com (Chitlesh GOORAH)
Date: Wed, 12 Nov 2008 20:11:21 +0100
Subject: manual override needed for liborigin and libgeda
Message-ID: <50baabb30811121111v30b6161x19af6f8e2421fbda@mail.gmail.com>

Hello there,

can anyone do a manual override for both F-8, F-9 and F-10 branches as
I need to build a chain of packages ?

The packages are:
 	
liborigin-20080225-1.fc8
liborigin-20080225-1.fc9
liborigin-20080225-1.fc10

and

libgeda-20080929-1.fc8
libgeda-20080929-1.fc9
libgeda-20080929-1.fc10

thanks,
Kind regards,
Chitlesh



From j.w.r.degoede at hhs.nl  Wed Nov 12 19:19:05 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 12 Nov 2008 20:19:05 +0100
Subject: manual override needed for liborigin and libgeda
In-Reply-To: <50baabb30811121111v30b6161x19af6f8e2421fbda@mail.gmail.com>
References: <50baabb30811121111v30b6161x19af6f8e2421fbda@mail.gmail.com>
Message-ID: <491B2C29.70207@hhs.nl>

Chitlesh GOORAH wrote:
> Hello there,
> 
> can anyone do a manual override for both F-8, F-9 and F-10 branches as
> I need to build a chain of packages ?
> 
> The packages are:
>  	
> liborigin-20080225-1.fc8
> liborigin-20080225-1.fc9
> liborigin-20080225-1.fc10
> 
> and
> 
> libgeda-20080929-1.fc8
> libgeda-20080929-1.fc9
> libgeda-20080929-1.fc10
> 
> thanks,
> Kind regards,
> Chitlesh
> 

The proper way to request this is to file a ticket in rel-eng trac:
https://fedorahosted.org/rel-eng/newticket

And the proper term for what you want is "tag package foo-123-1.fcX for fcX 
buildroot inclusion" :)

Regards,

Hans



From lesmikesell at gmail.com  Wed Nov 12 19:14:47 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 12 Nov 2008 13:14:47 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <71051a5a7ff9f9bc8da6c383a4ba235c.squirrel@mail.jcomserv.net>
References: <1226429441.3593.77.camel@eagle.danny.cz>	<200811111317.15198.dennis@ausil.us>
	<4919DC9C.1030009@gmail.com>	<1226480816.3638.19.camel@eagle.danny.cz>	<1226485422.3638.22.camel@eagle.danny.cz>	<20081112111712.GB3142@free.fr>	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>	<778179b00811120400s5fda1277y2130ceddeb9d0422@mail.gmail.com>	<1226491831.3752.298.camel@beck.corsepiu.local>	<491AE00F.5010703@gmail.com>	<1226515548.31982.403.camel@atropine.boston.devel.redhat.com>	<1226515988.5295.5.camel@luminos.localdomain>
	<71051a5a7ff9f9bc8da6c383a4ba235c.squirrel@mail.jcomserv.net>
Message-ID: <491B2B27.1060703@gmail.com>

Jon Ciesla wrote:

>>> Yes, they are.  On an install without any X components, 'yum install
>>> gnome-terminal' will pull in X libs but not an X server.
>>>
>> In fact, if you install the gnome desktop group, but don't check the X
>> group, you get gnome but not X server to run it on.
> 
> Perfect for ssh tunneling or a freenx server.

Will you be missing any authentication or device ownership magic if you 
use freenx exclusively instead of the console?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From cmadams at hiwaay.net  Wed Nov 12 19:15:51 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 12 Nov 2008 13:15:51 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <491AF259.40907@comcast.net>
References: <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr>
	<20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net>
Message-ID: <20081112191551.GC1461854@hiwaay.net>

Once upon a time, John Ellson <john.ellson at comcast.net> said:
> Are there guidelines somewhere on what packages should not be pulled in 
> on a server?

Well, I guess start with a very minimal install and see what is there.
With rawhide, it appears impossible to install a kernel without pulling
in X libraries (because of plymouth), so I guess the base X libraries
can be considered "core" now.

Here's a script that lets you install packages and their dependencies
into a subdirectory to see what gets pulled in.  If you just install
kernel and grub, you get 116 packages, including python, core X
libraries, and freetype.  Add in yum and you get another 29 packages.

-- 
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.


#!/bin/bash

# "Install" a specified set of packages (plus dependencies) in a
# subdirectory using yum.
# The subdirectory is the first argument (must not already exist) and
# everything else is taken as a list of packages to install

if (($(id -u) != 0)); then
	echo "Must run as root" 1>&2
	exit 1
fi

BASE="$1"
shift
if [ -z "$BASE" ]; then
	echo "Must supply top-level directory" 1>&2
	exit 1
fi
if [ -e "$BASE" ]; then
	echo "$BASE exists" 1>&2
	exit 1
fi
if [ -z "$*" ]; then
	echo "Must supply package(s) to install" 1>&1
	exit 1
fi

# make the base fully-specified
mkdir "$BASE"
BASE="$(cd "$BASE"; pwd)"

# rpm init
mkdir -p "$BASE/var/lib/rpm"
rpm --initdb --dbpath "$BASE/var/lib/rpm"

# filesystem setup (keeps kernel %post happy)
mkdir -p "$BASE/etc"
touch "$BASE/etc/fstab"

# install and clean up
yum -y --installroot="$BASE" --disablerepo="*" --enablerepo=rawhide \
    install $@
yum --installroot="$BASE" --disablerepo="*" --enablerepo=rawhide clean all



From cmadams at hiwaay.net  Wed Nov 12 19:20:33 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 12 Nov 2008 13:20:33 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1226515769.5295.4.camel@luminos.localdomain>
References: <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<20081112170805.GC6260@nostromo.devel.redhat.com>
	<1226510160.3638.28.camel@eagle.danny.cz>
	<alpine.LFD.2.00.0811121305350.31693@localhost.localdomain>
	<491B21D2.4010104@gmail.com>
	<1226515769.5295.4.camel@luminos.localdomain>
Message-ID: <20081112192033.GD1461854@hiwaay.net>

Once upon a time, Jesse Keating <jkeating at redhat.com> said:
> On Wed, 2008-11-12 at 12:34 -0600, Les Mikesell wrote:
> > On the other hand, I'd really like to see a pre-install stage with the 
> > absolute minimum required to reboot and tell yum to get the other things 
> > you want.
> 
> that's basically @core.

@core could probably be kernel, grub (or other platform-appropriate boot
loader), and yum (I'd say yum is pretty much core to any Fedora system).
If something isn't pulled in by dependencies from that, then it probably
isn't really all that core.
-- 
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 jkeating at redhat.com  Wed Nov 12 19:22:39 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 12 Nov 2008 11:22:39 -0800
Subject: starting Fedora Server SIG
In-Reply-To: <20081112192033.GD1461854@hiwaay.net>
References: <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<20081112170805.GC6260@nostromo.devel.redhat.com>
	<1226510160.3638.28.camel@eagle.danny.cz>
	<alpine.LFD.2.00.0811121305350.31693@localhost.localdomain>
	<491B21D2.4010104@gmail.com>
	<1226515769.5295.4.camel@luminos.localdomain>
	<20081112192033.GD1461854@hiwaay.net>
Message-ID: <1226517759.5295.12.camel@luminos.localdomain>

On Wed, 2008-11-12 at 13:20 -0600, Chris Adams wrote:
> 
> @core could probably be kernel, grub (or other platform-appropriate boot
> loader), and yum (I'd say yum is pretty much core to any Fedora system).
> If something isn't pulled in by dependencies from that, then it probably
> isn't really all that core.

Have you looked at core lately?  Mostly it's things listed that would
already get pulled in via deps, and a few things that aren't just
because we haven't manually added the deps to the 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/20081112/400c5c5a/attachment.sig>

From jkeating at redhat.com  Wed Nov 12 19:23:17 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 12 Nov 2008 11:23:17 -0800
Subject: starting Fedora Server SIG
In-Reply-To: <20081112191551.GC1461854@hiwaay.net>
References: <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr>
	<20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net>  <20081112191551.GC1461854@hiwaay.net>
Message-ID: <1226517797.5295.13.camel@luminos.localdomain>

On Wed, 2008-11-12 at 13:15 -0600, Chris Adams wrote:
> Well, I guess start with a very minimal install and see what is there.
> With rawhide, it appears impossible to install a kernel without pulling
> in X libraries (because of plymouth), so I guess the base X libraries
> can be considered "core" now.

Pardon?

-- 
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/20081112/43564455/attachment.sig>

From dan at danny.cz  Wed Nov 12 19:28:10 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Wed, 12 Nov 2008 20:28:10 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <20081112191551.GC1461854@hiwaay.net>
References: <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr>
	<20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net>  <20081112191551.GC1461854@hiwaay.net>
Message-ID: <1226518090.3638.37.camel@eagle.danny.cz>


Chris Adams p??e v St 12. 11. 2008 v 13:15 -0600:
> Once upon a time, John Ellson <john.ellson at comcast.net> said:
> > Are there guidelines somewhere on what packages should not be pulled in 
> > on a server?
> 
> Well, I guess start with a very minimal install and see what is there.
> With rawhide, it appears impossible to install a kernel without pulling
> in X libraries (because of plymouth), so I guess the base X libraries
> can be considered "core" now.
> 

plymouth (required by mkinitrd) can installed by default, but there
should be possibility to run without it


		Dan




From notting at redhat.com  Wed Nov 12 19:28:55 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 12 Nov 2008 14:28:55 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <1226517797.5295.13.camel@luminos.localdomain>
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr>
	<20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
Message-ID: <20081112192855.GB12723@nostromo.devel.redhat.com>

Jesse Keating (jkeating at redhat.com) said: 
> > Well, I guess start with a very minimal install and see what is there.
> > With rawhide, it appears impossible to install a kernel without pulling
> > in X libraries (because of plymouth), so I guess the base X libraries
> > can be considered "core" now.
> 
> Pardon?

plymouth's default dep chain pulls in libpng & pango, due to the graphical
plugins. Whether those are considered 'X' libraries is debatable.

Bill



From notting at redhat.com  Wed Nov 12 19:29:54 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 12 Nov 2008 14:29:54 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <1226518090.3638.37.camel@eagle.danny.cz>
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr>
	<20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226518090.3638.37.camel@eagle.danny.cz>
Message-ID: <20081112192954.GC12723@nostromo.devel.redhat.com>

Dan Hor?k (dan at danny.cz) said: 
> plymouth (required by mkinitrd) can installed by default, but there
> should be possibility to run without it

As it's used for handling encryption passphrases (and will be used even
more in future releases for this, to do sane storage handling), it's
not optional.

What plugin you use by default (such as the details one) is another
matter entirely.

Bill



From cmadams at hiwaay.net  Wed Nov 12 19:30:00 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 12 Nov 2008 13:30:00 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1226517759.5295.12.camel@luminos.localdomain>
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<20081112170805.GC6260@nostromo.devel.redhat.com>
	<1226510160.3638.28.camel@eagle.danny.cz>
	<alpine.LFD.2.00.0811121305350.31693@localhost.localdomain>
	<491B21D2.4010104@gmail.com>
	<1226515769.5295.4.camel@luminos.localdomain>
	<20081112192033.GD1461854@hiwaay.net>
	<1226517759.5295.12.camel@luminos.localdomain>
Message-ID: <20081112193000.GE1461854@hiwaay.net>

Once upon a time, Jesse Keating <jkeating at redhat.com> said:
> Have you looked at core lately?  Mostly it's things listed that would
> already get pulled in via deps, and a few things that aren't just
> because we haven't manually added the deps to the packages.

Sorry, no I haven't, not at all since F9 (and not much before that) was
released.  I do get frustrated sometimes by what gets pulled in when
trying to build a minimal box (like a firewall or a simple NFS server).

Why is "ed" still mandatory in core?  Does anything (or anybody)
actually use it?

I see a few other things that don't really seem core to me (file,
hdparm, prelink, dhclient); it isn't that I don't use them, but I don't
necessarily see why they should be mandatory.

-- 
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 notting at redhat.com  Wed Nov 12 19:35:10 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 12 Nov 2008 14:35:10 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <20081112193000.GE1461854@hiwaay.net>
References: <20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<20081112170805.GC6260@nostromo.devel.redhat.com>
	<1226510160.3638.28.camel@eagle.danny.cz>
	<alpine.LFD.2.00.0811121305350.31693@localhost.localdomain>
	<491B21D2.4010104@gmail.com>
	<1226515769.5295.4.camel@luminos.localdomain>
	<20081112192033.GD1461854@hiwaay.net>
	<1226517759.5295.12.camel@luminos.localdomain>
	<20081112193000.GE1461854@hiwaay.net>
Message-ID: <20081112193510.GD12723@nostromo.devel.redhat.com>

Chris Adams (cmadams at hiwaay.net) said: 
> Why is "ed" still mandatory in core?

Because ed is the stnadard text editor. (Couldn't resist.)

> Does anything (or anybody) actually use it?

LSB dep, apparently. That being said, I don't see why it can't
be removed. Done for F11.

> I see a few other things that don't really seem core to me (file,
> hdparm, prelink, dhclient); it isn't that I don't use them, but I don't
> necessarily see why they should be mandatory.

hdparm is a bug, removed in the F11 tree. (I'm tempted to do it for F10
too). prelink's sort of weird, in that I'm not sure how it would get on
the system otherwise - it could probably be moved to Base. dhclient is
included so you can always configure and start minimal networking.

Bill



From lesmikesell at gmail.com  Wed Nov 12 19:35:30 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 12 Nov 2008 13:35:30 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <20081112192855.GB12723@nostromo.devel.redhat.com>
References: <1226485422.3638.22.camel@eagle.danny.cz>	<20081112110506.GA3142@free.fr>	<20081112131806.GA1461854@hiwaay.net>	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>	<491AED13.8050204@comcast.net>	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>	<491AF259.40907@comcast.net>
	<20081112191551.GC1461854@hiwaay.net>	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112192855.GB12723@nostromo.devel.redhat.com>
Message-ID: <491B3002.1030002@gmail.com>

Bill Nottingham wrote:
> Jesse Keating (jkeating at redhat.com) said: 
>>> Well, I guess start with a very minimal install and see what is there.
>>> With rawhide, it appears impossible to install a kernel without pulling
>>> in X libraries (because of plymouth), so I guess the base X libraries
>>> can be considered "core" now.
>> Pardon?
> 
> plymouth's default dep chain pulls in libpng & pango, due to the graphical
> plugins. Whether those are considered 'X' libraries is debatable.

This is all pretty strange from a server perspective.  And plymouth is 
there to keep the screen from blinking while you boot?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jkeating at redhat.com  Wed Nov 12 19:44:54 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 12 Nov 2008 11:44:54 -0800
Subject: starting Fedora Server SIG
In-Reply-To: <491B3002.1030002@gmail.com>
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr>	<20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112192855.GB12723@nostromo.devel.redhat.com>
	<491B3002.1030002@gmail.com>
Message-ID: <1226519094.5295.14.camel@luminos.localdomain>

On Wed, 2008-11-12 at 13:35 -0600, Les Mikesell wrote:
> 
> This is all pretty strange from a server perspective.  And plymouth is 
> there to keep the screen from blinking while you boot?

More importantly, plymouth is handling the passphase prompting for
encrypted volumes.

-- 
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/20081112/cf3785a8/attachment.sig>

From lesmikesell at gmail.com  Wed Nov 12 19:46:06 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 12 Nov 2008 13:46:06 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <20081112192954.GC12723@nostromo.devel.redhat.com>
References: <1226485422.3638.22.camel@eagle.danny.cz>	<20081112110506.GA3142@free.fr>	<20081112131806.GA1461854@hiwaay.net>	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>	<491AED13.8050204@comcast.net>	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>	<491AF259.40907@comcast.net>
	<20081112191551.GC1461854@hiwaay.net>	<1226518090.3638.37.camel@eagle.danny.cz>
	<20081112192954.GC12723@nostromo.devel.redhat.com>
Message-ID: <491B327E.3040608@gmail.com>

Bill Nottingham wrote:
> 
>> plymouth (required by mkinitrd) can installed by default, but there
>> should be possibility to run without it
> 
> As it's used for handling encryption passphrases (and will be used even
> more in future releases for this, to do sane storage handling), it's
> not optional.

How does that work for an unattended machine?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From notting at redhat.com  Wed Nov 12 19:49:26 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 12 Nov 2008 14:49:26 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <491B327E.3040608@gmail.com>
References: <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226518090.3638.37.camel@eagle.danny.cz>
	<20081112192954.GC12723@nostromo.devel.redhat.com>
	<491B327E.3040608@gmail.com>
Message-ID: <20081112194926.GE12723@nostromo.devel.redhat.com>

Les Mikesell (lesmikesell at gmail.com) said: 
>>> plymouth (required by mkinitrd) can installed by default, but there
>>> should be possibility to run without it
>>
>> As it's used for handling encryption passphrases (and will be used even
>> more in future releases for this, to do sane storage handling), it's
>> not optional.
>
> How does that work for an unattended machine?

Probably just about as well as setting up a passphrased-protected
encrypted volume worked before plymouth.

Now, if you want to set it up to use keys from a file...

Bill



From dan at danny.cz  Wed Nov 12 19:50:09 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Wed, 12 Nov 2008 20:50:09 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <20081112192954.GC12723@nostromo.devel.redhat.com>
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr> <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226518090.3638.37.camel@eagle.danny.cz>
	<20081112192954.GC12723@nostromo.devel.redhat.com>
Message-ID: <1226519409.3638.41.camel@eagle.danny.cz>


Bill Nottingham p??e v St 12. 11. 2008 v 14:29 -0500:
> Dan Hor?k (dan at danny.cz) said: 
> > plymouth (required by mkinitrd) can installed by default, but there
> > should be possibility to run without it
> 
> As it's used for handling encryption passphrases (and will be used even
> more in future releases for this, to do sane storage handling), it's
> not optional.
> 
> What plugin you use by default (such as the details one) is another
> matter entirely.

hm, I primarily want to be sure that plymouth doesn't interfere with
serial console only systems and similar devices


		Dan




From notting at redhat.com  Wed Nov 12 19:56:37 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 12 Nov 2008 14:56:37 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <1226519409.3638.41.camel@eagle.danny.cz>
References: <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226518090.3638.37.camel@eagle.danny.cz>
	<20081112192954.GC12723@nostromo.devel.redhat.com>
	<1226519409.3638.41.camel@eagle.danny.cz>
Message-ID: <20081112195637.GF12723@nostromo.devel.redhat.com>

Dan Hor?k (dan at danny.cz) said: 
> > What plugin you use by default (such as the details one) is another
> > matter entirely.
> 
> hm, I primarily want to be sure that plymouth doesn't interfere with
> serial console only systems and similar devices

It should work - we've done some testing on PPC boxes via serial/hvc
consoles. Please test that it works in your scenarios as well, of course.

Bill



From dominik at greysector.net  Wed Nov 12 20:04:47 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 12 Nov 2008 21:04:47 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <1226519094.5295.14.camel@luminos.localdomain>
References: <778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112192855.GB12723@nostromo.devel.redhat.com>
	<491B3002.1030002@gmail.com>
	<1226519094.5295.14.camel@luminos.localdomain>
Message-ID: <20081112200447.GA19196@mokona.greysector.net>

On Wednesday, 12 November 2008 at 20:44, Jesse Keating wrote:
> On Wed, 2008-11-12 at 13:35 -0600, Les Mikesell wrote:
> > 
> > This is all pretty strange from a server perspective.  And plymouth is 
> > there to keep the screen from blinking while you boot?
> 
> More importantly, plymouth is handling the passphase prompting for
> encrypted volumes.

Do we have an option of NOT installing plymouth at all? If not, why?

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 enrico.scholz at informatik.tu-chemnitz.de  Wed Nov 12 20:05:17 2008
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Wed, 12 Nov 2008 21:05:17 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <20081112192954.GC12723@nostromo.devel.redhat.com> (Bill
	Nottingham's message of "Wed, 12 Nov 2008 14:29:54 -0500")
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr> <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226518090.3638.37.camel@eagle.danny.cz>
	<20081112192954.GC12723@nostromo.devel.redhat.com>
Message-ID: <87iqqsiubm.fsf@sheridan.bigo.ensc.de>

Bill Nottingham <notting at redhat.com> writes:

>> plymouth (required by mkinitrd) can installed by default, but there
>> should be possibility to run without it
>
> As it's used for handling encryption passphrases (and will be used
> even more in future releases for this, to do sane storage handling),
> it's not optional.

This thread is about a *server* SIG, isn't it?  Most servers do not need
disk encryption as they are located in physically secured rooms.  They
must be able to reboot without manual interaction too.

Hence, when password prompts are the only reason for plymouth, then
plymouth should be optional; especially when it has heavy dependencies
like pango.



Enrico



From lesmikesell at gmail.com  Wed Nov 12 20:05:42 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 12 Nov 2008 14:05:42 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1226519094.5295.14.camel@luminos.localdomain>
References: <1226485422.3638.22.camel@eagle.danny.cz>	<20081112110506.GA3142@free.fr>	<20081112131806.GA1461854@hiwaay.net>	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>	<491AED13.8050204@comcast.net>	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>	<491AF259.40907@comcast.net>
	<20081112191551.GC1461854@hiwaay.net>	<1226517797.5295.13.camel@luminos.localdomain>	<20081112192855.GB12723@nostromo.devel.redhat.com>	<491B3002.1030002@gmail.com>
	<1226519094.5295.14.camel@luminos.localdomain>
Message-ID: <491B3716.1050706@gmail.com>

Jesse Keating wrote:
> On Wed, 2008-11-12 at 13:35 -0600, Les Mikesell wrote:
>> This is all pretty strange from a server perspective.  And plymouth is 
>> there to keep the screen from blinking while you boot?
> 
> More importantly, plymouth is handling the passphase prompting for
> encrypted volumes.

But shouldn't that be optional for unattended boxes in remote locations 
that are either headless or have a KVM that generally won't have this 
box selected?

-- 
   Les Mikesell
    lesmikesell at gamil.com



From cmadams at hiwaay.net  Wed Nov 12 20:07:50 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 12 Nov 2008 14:07:50 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1226517797.5295.13.camel@luminos.localdomain>
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr>
	<20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
Message-ID: <20081112200750.GF1461854@hiwaay.net>

Once upon a time, Jesse Keating <jkeating at redhat.com> said:
> On Wed, 2008-11-12 at 13:15 -0600, Chris Adams wrote:
> > Well, I guess start with a very minimal install and see what is there.
> > With rawhide, it appears impossible to install a kernel without pulling
> > in X libraries (because of plymouth), so I guess the base X libraries
> > can be considered "core" now.
> 
> Pardon?

Doing a "yum install kernel" from rawhide in an empty install root
gives:

================================================================================
 Package                 Arch     Version                     Repository  Size
================================================================================
Installing:
 kernel                  x86_64   2.6.27.5-94.fc10            rawhide      20 M
Installing for dependencies:
 ConsoleKit-libs         x86_64   0.3.0-2.fc10                rawhide      15 k
 MAKEDEV                 x86_64   3.24-1                      rawhide      94 k
 audit-libs              x86_64   1.7.8-6.fc10                rawhide      79 k
 basesystem              noarch   10.0-1                      rawhide     2.8 k
 bash                    x86_64   3.2-29.fc10                 rawhide     1.8 M
 bzip2-libs              x86_64   1.0.5-3.fc10                rawhide      37 k
 ca-certificates         noarch   2008-7                      rawhide     307 k
 cairo                   x86_64   1.8.0-1.fc10                rawhide     436 k
 chkconfig               x86_64   1.3.38-1                    rawhide     162 k
 coreutils               x86_64   6.12-17.fc10                rawhide     4.7 M
 cpio                    x86_64   2.9.90-2.fc10               rawhide     185 k
 cracklib                x86_64   2.8.12-2                    rawhide      48 k
 cracklib-dicts          x86_64   2.8.12-2                    rawhide     3.7 M
 db4                     x86_64   4.7.25-5.fc10               rawhide     649 k
 dbus                    x86_64   1.2.4-1.fc10                rawhide     227 k
 dbus-libs               x86_64   1.2.4-1.fc10                rawhide     130 k
 device-mapper           x86_64   1.02.27-6.fc10              rawhide      75 k
 device-mapper-libs      x86_64   1.02.27-6.fc10              rawhide      72 k
 diffutils               x86_64   2.8.1-21.fc9                rawhide     215 k
 dmraid                  x86_64   1.0.0.rc15-1.fc10           rawhide     129 k
 e2fsprogs               x86_64   1.41.3-2.fc10               rawhide     747 k
 e2fsprogs-libs          x86_64   1.41.3-2.fc10               rawhide     147 k
 elfutils-libelf         x86_64   0.137-3.fc10                rawhide      54 k
 ethtool                 x86_64   6-1.fc9                     rawhide      66 k
 expat                   x86_64   2.0.1-5                     rawhide      83 k
 fedora-logos            noarch   10.0.1-2.fc10               rawhide     1.8 M
 fedora-release          noarch   10-1                        rawhide      25 k
 fedora-release-notes    noarch   10.0.0-0.2                  rawhide     5.0 M
 filesystem              x86_64   2.4.19-1.fc10               rawhide     120 k
 findutils               x86_64   1:4.4.0-1.fc10              rawhide     568 k
 fontconfig              x86_64   2.6.0-3.fc10                rawhide     183 k
 freetype                x86_64   2.3.7-1.fc10                rawhide     353 k
 gamin                   x86_64   0.1.9-6.fc10                rawhide     141 k
 gawk                    x86_64   3.1.5-18.fc10               rawhide     981 k
 gdbm                    x86_64   1.8.0-29.fc10               rawhide      28 k
 glib2                   x86_64   2.18.2-3.fc10               rawhide     1.4 M
 glibc                   x86_64   2.8.90-16                   rawhide     5.1 M
 glibc-common            x86_64   2.8.90-16                   rawhide      22 M
 grep                    x86_64   2.5.1a-61.fc10              rawhide     184 k
 gzip                    x86_64   1.3.12-7.fc10               rawhide     116 k
 info                    x86_64   4.12-4.fc10                 rawhide     186 k
 initscripts             x86_64   8.85-1                      rawhide     1.9 M
 iproute                 x86_64   2.6.26-1.fc10               rawhide     861 k
 iputils                 x86_64   20071127-6.fc10             rawhide     135 k
 isomd5sum               x86_64   1:1.0.4-1                   rawhide      26 k
 kernel-firmware         noarch   2.6.27.5-94.fc10            rawhide     350 k
 keyutils-libs           x86_64   1.2-3.fc9                   rawhide      18 k
 kpartx                  x86_64   0.4.8-7.fc10                rawhide      23 k
 krb5-libs               x86_64   1.6.3-16.fc10               rawhide     737 k
 less                    x86_64   424-1.fc10                  rawhide     111 k
 libX11                  x86_64   1.1.4-5.fc10                rawhide     827 k
 libXau                  x86_64   1.0.4-1.fc10                rawhide      20 k
 libXdmcp                x86_64   1.0.2-6.fc10                rawhide      21 k
 libXext                 x86_64   1.0.4-1.fc9                 rawhide      39 k
 libXft                  x86_64   2.1.13-1.fc10               rawhide      51 k
 libXrender              x86_64   0.9.4-3.fc9                 rawhide      29 k
 libacl                  x86_64   2.2.47-3.fc10               rawhide      22 k
 libattr                 x86_64   2.4.43-1.fc10               rawhide      14 k
 libcap                  x86_64   2.10-2.fc10                 rawhide      30 k
 libdhcp                 x86_64   1.99.8-1.fc10               rawhide      70 k
 libdhcp4client          x86_64   12:4.0.0-30.fc10            rawhide     281 k
 libdhcp6client          x86_64   1.0.22-1.fc10               rawhide      88 k
 libgcc                  x86_64   4.3.2-7                     rawhide      69 k
 libidn                  x86_64   0.6.14-8                    rawhide     212 k
 libnl                   x86_64   1.1-5.fc10                  rawhide     137 k
 libpng                  x86_64   2:1.2.31-2.fc10             rawhide     246 k
 libselinux              x86_64   2.0.73-1.fc10               rawhide      98 k
 libsepol                x86_64   2.0.33-1.fc10               rawhide     132 k
 libstdc++               x86_64   4.3.2-7                     rawhide     320 k
 libthai                 x86_64   0.1.9-4.fc9                 rawhide     186 k
 libvolume_id            x86_64   127-3.fc10                  rawhide      54 k
 libxcb                  x86_64   1.1.91-5.fc10               rawhide     120 k
 linux-atm-libs          x86_64   2.5.0-5                     rawhide      23 k
 logrotate               x86_64   3.7.7-1.fc10                rawhide      52 k
 lvm2                    x86_64   2.02.39-6.fc10              rawhide     395 k
 mdadm                   x86_64   2.6.7.1-1.fc10              rawhide     951 k
 mingetty                x86_64   1.08-2.fc9                  rawhide      20 k
 mkinitrd                x86_64   6.0.70-1.fc10               rawhide     113 k
 module-init-tools       x86_64   3.5-3.fc10                  rawhide     481 k
 nash                    x86_64   6.0.70-1.fc10               rawhide     164 k
 ncurses                 x86_64   5.6-20.20080927.fc10        rawhide     169 k
 ncurses-base            x86_64   5.6-20.20080927.fc10        rawhide      63 k
 ncurses-libs            x86_64   5.6-20.20080927.fc10        rawhide     327 k
 net-tools               x86_64   1.60-91.fc10                rawhide     368 k
 openssl                 x86_64   0.9.8g-11.fc10              rawhide     1.3 M
 pam                     x86_64   1.0.2-2.fc10                rawhide     663 k
 pango                   x86_64   1.22.1-1.fc10               rawhide     379 k
 parted                  x86_64   1.8.8-8.fc10                rawhide     640 k
 pcre                    x86_64   7.8-1.fc10                  rawhide     213 k
 pixman                  x86_64   0.12.0-1.fc10               rawhide     109 k
 plymouth                x86_64   0.6.0-0.2008.11.10.5.fc10   rawhide      48 k
 plymouth-libs           x86_64   0.6.0-0.2008.11.10.5.fc10   rawhide      66 k
 plymouth-plugin-label   x86_64   0.6.0-0.2008.11.10.5.fc10   rawhide      18 k
 plymouth-plugin-solar   x86_64   0.6.0-0.2008.11.10.5.fc10   rawhide     550 k
 plymouth-scripts        x86_64   0.6.0-0.2008.11.10.5.fc10   rawhide      16 k
 popt                    x86_64   1.13-4.fc10                 rawhide      39 k
 procps                  x86_64   3.2.7-21.fc10               rawhide     215 k
 psmisc                  x86_64   22.6-8.fc10                 rawhide      74 k
 python                  x86_64   2.5.2-1.fc10                rawhide     4.9 M
 python-libs             x86_64   2.5.2-1.fc10                rawhide     604 k
 readline                x86_64   5.2-13.fc9                  rawhide     190 k
 rsyslog                 x86_64   3.21.3-4.fc10               rawhide     373 k
 sed                     x86_64   4.1.5-10.fc9                rawhide     189 k
 setup                   noarch   2.7.4-1.fc10                rawhide     140 k
 shadow-utils            x86_64   2:4.1.2-8.fc10              rawhide     1.3 M
 sqlite                  x86_64   3.5.9-2.fc10                rawhide     242 k
 sysvinit-tools          x86_64   2.86-24                     rawhide      62 k
 tar                     x86_64   2:1.20-3.fc10               rawhide     976 k
 tzdata                  noarch   2008h-1.fc10                rawhide     753 k
 udev                    x86_64   127-3.fc10                  rawhide     262 k
 upstart                 x86_64   0.3.9-19.fc10               rawhide     258 k
 util-linux-ng           x86_64   2.14.1-3.fc10               rawhide     2.0 M
 xorg-x11-filesystem     noarch   7.3-2.fc10                  rawhide     5.6 k
 zlib                    x86_64   1.2.3-18.fc9                rawhide      75 k


It looks like the dep chain to the X libraries is:

cairo requires libX11.so.6
plymouth-plugin-label requires libcairo.so.2
plymouth-plugin-solar requires plymouth-plugin-label
plymouth requires system-plymouth-plugin (provided by plymouth-plugin-solar)
mkinitrd requires plymouth

If I explicitly add "plymouth-text-and-details-only" to my install, it
satisfies the system-plymouth-plugin dependency, and I don't get libX11
and such.

Maybe plymouth-text-and-details-only should be in @core and
plymouth-plugin-solar in @base?

-- 
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 emmanuel.seyman at club-internet.fr  Wed Nov 12 20:08:04 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Wed, 12 Nov 2008 21:08:04 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <491B21D2.4010104@gmail.com>
References: <200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<20081112170805.GC6260@nostromo.devel.redhat.com>
	<1226510160.3638.28.camel@eagle.danny.cz>
	<alpine.LFD.2.00.0811121305350.31693@localhost.localdomain>
	<491B21D2.4010104@gmail.com>
Message-ID: <20081112200804.GA25197@orient.maison.lan>

* Les Mikesell [12/11/2008 20:08] :
>
> The LSB really has no value at all until you can assume that all systems  
>   comply.

I can't reconcile that with the fact that LSB-compliant packages are
ordered to have dependencies that indicate which LSB modules are
required.

Emmanuel



From jkeating at redhat.com  Wed Nov 12 20:09:17 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 12 Nov 2008 12:09:17 -0800
Subject: starting Fedora Server SIG
In-Reply-To: <87iqqsiubm.fsf@sheridan.bigo.ensc.de>
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr> <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226518090.3638.37.camel@eagle.danny.cz>
	<20081112192954.GC12723@nostromo.devel.redhat.com>
	<87iqqsiubm.fsf@sheridan.bigo.ensc.de>
Message-ID: <1226520557.5295.20.camel@luminos.localdomain>

On Wed, 2008-11-12 at 21:05 +0100, Enrico Scholz wrote:
> 
> This thread is about a *server* SIG, isn't it?  Most servers do not need
> disk encryption as they are located in physically secured rooms.  They
> must be able to reboot without manual interaction too.
> 
> Hence, when password prompts are the only reason for plymouth, then
> plymouth should be optional; especially when it has heavy dependencies
> like pango.

Don't be so sure about that.  In a colo environment I /would/ want some
encryption on the disk, and if I have to use a remote kvm to input the
passphrase at reboot time, that's OK.  Reboots are either planned
events, or emergencies, both of which are going to require the attention
of the people who have the passphrase.

-- 
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/20081112/d63baf61/attachment.sig>

From dan at danny.cz  Wed Nov 12 20:09:58 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Wed, 12 Nov 2008 21:09:58 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <20081112195637.GF12723@nostromo.devel.redhat.com>
References: <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226518090.3638.37.camel@eagle.danny.cz>
	<20081112192954.GC12723@nostromo.devel.redhat.com>
	<1226519409.3638.41.camel@eagle.danny.cz>
	<20081112195637.GF12723@nostromo.devel.redhat.com>
Message-ID: <1226520598.3638.49.camel@eagle.danny.cz>


Bill Nottingham p??e v St 12. 11. 2008 v 14:56 -0500:
> Dan Hor?k (dan at danny.cz) said: 
> > > What plugin you use by default (such as the details one) is another
> > > matter entirely.
> > 
> > hm, I primarily want to be sure that plymouth doesn't interfere with
> > serial console only systems and similar devices
> 
> It should work - we've done some testing on PPC boxes via serial/hvc
> consoles. Please test that it works in your scenarios as well, of course.

I think the real test will come on s390x ;-) But good to know that when
it doesn't work it is a bug.

Is there any page with some technical description of plymouth's
architecture and its position in the boot process?


		Dan




From notting at redhat.com  Wed Nov 12 20:10:42 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 12 Nov 2008 15:10:42 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <491B3716.1050706@gmail.com>
References: <5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112192855.GB12723@nostromo.devel.redhat.com>
	<491B3002.1030002@gmail.com>
	<1226519094.5295.14.camel@luminos.localdomain>
	<491B3716.1050706@gmail.com>
Message-ID: <20081112201042.GA13652@nostromo.devel.redhat.com>

Les Mikesell (lesmikesell at gmail.com) said: 
>> More importantly, plymouth is handling the passphase prompting for
>> encrypted volumes.
>
> But shouldn't that be optional for unattended boxes in remote locations  
> that are either headless or have a KVM that generally won't have this  
> box selected?

plymouth also handles the boot logging.

Bill



From jkeating at j2solutions.net  Wed Nov 12 20:11:06 2008
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 12 Nov 2008 12:11:06 -0800
Subject: starting Fedora Server SIG
In-Reply-To: <20081112200750.GF1461854@hiwaay.net>
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr> <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
Message-ID: <1226520666.5295.21.camel@luminos.localdomain>

On Wed, 2008-11-12 at 14:07 -0600, Chris Adams wrote:
> It looks like the dep chain to the X libraries is:
> 
> cairo requires libX11.so.6
> plymouth-plugin-label requires libcairo.so.2
> plymouth-plugin-solar requires plymouth-plugin-label
> plymouth requires system-plymouth-plugin (provided by
> plymouth-plugin-solar)
> mkinitrd requires plymouth
> 
> If I explicitly add "plymouth-text-and-details-only" to my install, it
> satisfies the system-plymouth-plugin dependency, and I don't get
> libX11
> and such.
> 
> Maybe plymouth-text-and-details-only should be in @core and
> plymouth-plugin-solar in @base?

This confirms my assumption.  It's not a hard requirement, it's just a
guess the system is making when not provided any other details (such
that you'd prefer to have the text plugin to plymouth).

As to how to sort that out in the groups....

-- 
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/20081112/84aaa5cf/attachment.sig>

From cmadams at hiwaay.net  Wed Nov 12 20:12:15 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 12 Nov 2008 14:12:15 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <20081112193510.GD12723@nostromo.devel.redhat.com>
References: <385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<20081112170805.GC6260@nostromo.devel.redhat.com>
	<1226510160.3638.28.camel@eagle.danny.cz>
	<alpine.LFD.2.00.0811121305350.31693@localhost.localdomain>
	<491B21D2.4010104@gmail.com>
	<1226515769.5295.4.camel@luminos.localdomain>
	<20081112192033.GD1461854@hiwaay.net>
	<1226517759.5295.12.camel@luminos.localdomain>
	<20081112193000.GE1461854@hiwaay.net>
	<20081112193510.GD12723@nostromo.devel.redhat.com>
Message-ID: <20081112201215.GG1461854@hiwaay.net>

Once upon a time, Bill Nottingham <notting at redhat.com> said:
> Chris Adams (cmadams at hiwaay.net) said: 
> > Why is "ed" still mandatory in core?
> 
> Because ed is the stnadard text editor. (Couldn't resist.)

Okay, but then you need to drop vim-minimal. :-)

> > I see a few other things that don't really seem core to me (file,
> > hdparm, prelink, dhclient); it isn't that I don't use them, but I don't
> > necessarily see why they should be mandatory.
> 
> hdparm is a bug, removed in the F11 tree. (I'm tempted to do it for F10
> too). prelink's sort of weird, in that I'm not sure how it would get on
> the system otherwise - it could probably be moved to Base. dhclient is
> included so you can always configure and start minimal networking.

prelink should be in base (and as "default", not "mandatory").  Even
dhclient probably shouldn't be "mandatory" (I set servers up with static
IPs on networks with no DHCP server).

Remember, "mandatory" means the only way to not install it is a custom
kickstart; it should not be used very much.

-- 
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 dominik at greysector.net  Wed Nov 12 20:13:54 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 12 Nov 2008 21:13:54 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <1226520557.5295.20.camel@luminos.localdomain>
References: <778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226518090.3638.37.camel@eagle.danny.cz>
	<20081112192954.GC12723@nostromo.devel.redhat.com>
	<87iqqsiubm.fsf@sheridan.bigo.ensc.de>
	<1226520557.5295.20.camel@luminos.localdomain>
Message-ID: <20081112201354.GB19196@mokona.greysector.net>

On Wednesday, 12 November 2008 at 21:09, Jesse Keating wrote:
> On Wed, 2008-11-12 at 21:05 +0100, Enrico Scholz wrote:
> > 
> > This thread is about a *server* SIG, isn't it?  Most servers do not need
> > disk encryption as they are located in physically secured rooms.  They
> > must be able to reboot without manual interaction too.
> > 
> > Hence, when password prompts are the only reason for plymouth, then
> > plymouth should be optional; especially when it has heavy dependencies
> > like pango.
> 
> Don't be so sure about that.  In a colo environment I /would/ want some
> encryption on the disk, and if I have to use a remote kvm to input the
> passphrase at reboot time, that's OK.

And don't worry about sniffers attached to the KVM. Why would you?

Who decided that it was a jolly good idea to make plymouth essential?
I don't need a fancy progress bar that drags in tens of MBs of dependencies,
thank you. After all, nobody is going to see it anyway.

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  Wed Nov 12 20:16:10 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 12 Nov 2008 21:16:10 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <20081112201042.GA13652@nostromo.devel.redhat.com>
References: <491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112192855.GB12723@nostromo.devel.redhat.com>
	<491B3002.1030002@gmail.com>
	<1226519094.5295.14.camel@luminos.localdomain>
	<491B3716.1050706@gmail.com>
	<20081112201042.GA13652@nostromo.devel.redhat.com>
Message-ID: <20081112201609.GC19196@mokona.greysector.net>

On Wednesday, 12 November 2008 at 21:10, Bill Nottingham wrote:
> Les Mikesell (lesmikesell at gmail.com) said: 
> >> More importantly, plymouth is handling the passphase prompting for
> >> encrypted volumes.
> >
> > But shouldn't that be optional for unattended boxes in remote locations  
> > that are either headless or have a KVM that generally won't have this  
> > box selected?
> 
> plymouth also handles the boot logging.

You say it as if nothing handled it before plymouth appeared when in fact
it worked just fine without rhgb, which plymouth is supposedly replacing.

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 pbrobinson at gmail.com  Wed Nov 12 20:16:55 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 12 Nov 2008 20:16:55 +0000
Subject: starting Fedora Server SIG
In-Reply-To: <20081112194926.GE12723@nostromo.devel.redhat.com>
References: <20081112131806.GA1461854@hiwaay.net>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226518090.3638.37.camel@eagle.danny.cz>
	<20081112192954.GC12723@nostromo.devel.redhat.com>
	<491B327E.3040608@gmail.com>
	<20081112194926.GE12723@nostromo.devel.redhat.com>
Message-ID: <5256d0b0811121216h72dc6e35x38d15fc9890e025@mail.gmail.com>

>>> As it's used for handling encryption passphrases (and will be used even
>>> more in future releases for this, to do sane storage handling), it's
>>> not optional.
>>
>> How does that work for an unattended machine?
>
> Probably just about as well as setting up a passphrased-protected
> encrypted volume worked before plymouth.
>
> Now, if you want to set it up to use keys from a file...

Is it/would it be possible to take that from something like a smart
card or similar of physical and removable device?

Peter



From notting at redhat.com  Wed Nov 12 20:17:14 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 12 Nov 2008 15:17:14 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <20081112201215.GG1461854@hiwaay.net>
References: <20081112170805.GC6260@nostromo.devel.redhat.com>
	<1226510160.3638.28.camel@eagle.danny.cz>
	<alpine.LFD.2.00.0811121305350.31693@localhost.localdomain>
	<491B21D2.4010104@gmail.com>
	<1226515769.5295.4.camel@luminos.localdomain>
	<20081112192033.GD1461854@hiwaay.net>
	<1226517759.5295.12.camel@luminos.localdomain>
	<20081112193000.GE1461854@hiwaay.net>
	<20081112193510.GD12723@nostromo.devel.redhat.com>
	<20081112201215.GG1461854@hiwaay.net>
Message-ID: <20081112201714.GB13652@nostromo.devel.redhat.com>

Chris Adams (cmadams at hiwaay.net) said: 
> Remember, "mandatory" means the only way to not install it is a custom
> kickstart; it should not be used very much.

Core isn't editable, ergo 'default' and 'optional' make no sense there
(outside of bootloaders, which are listed as optional there for the
purpose of tree compose tools.)

Bill



From dan at danny.cz  Wed Nov 12 20:19:27 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Wed, 12 Nov 2008 21:19:27 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <87iqqsiubm.fsf@sheridan.bigo.ensc.de>
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr> <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226518090.3638.37.camel@eagle.danny.cz>
	<20081112192954.GC12723@nostromo.devel.redhat.com>
	<87iqqsiubm.fsf@sheridan.bigo.ensc.de>
Message-ID: <1226521167.3638.56.camel@eagle.danny.cz>


Enrico Scholz p??e v St 12. 11. 2008 v 21:05 +0100:
> Bill Nottingham <notting at redhat.com> writes:
> 
> >> plymouth (required by mkinitrd) can installed by default, but there
> >> should be possibility to run without it
> >
> > As it's used for handling encryption passphrases (and will be used
> > even more in future releases for this, to do sane storage handling),
> > it's not optional.
> 
> This thread is about a *server* SIG, isn't it?  Most servers do not need
> disk encryption as they are located in physically secured rooms.  They
> must be able to reboot without manual interaction too.
> 

But the server can be a NAS in your office and encryption can really be
useful there.


		Dan




From lesmikesell at gmail.com  Wed Nov 12 20:20:05 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 12 Nov 2008 14:20:05 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <20081112200804.GA25197@orient.maison.lan>
References: <200811111317.15198.dennis@ausil.us>
	<4919DC9C.1030009@gmail.com>	<1226480816.3638.19.camel@eagle.danny.cz>	<1226485422.3638.22.camel@eagle.danny.cz>	<20081112111712.GB3142@free.fr>	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>	<20081112170805.GC6260@nostromo.devel.redhat.com>	<1226510160.3638.28.camel@eagle.danny.cz>	<alpine.LFD.2.00.0811121305350.31693@localhost.localdomain>	<491B21D2.4010104@gmail.com>
	<20081112200804.GA25197@orient.maison.lan>
Message-ID: <491B3A75.5000407@gmail.com>

Emmanuel Seyman wrote:
> * Les Mikesell [12/11/2008 20:08] :
>> The LSB really has no value at all until you can assume that all systems  
>>   comply.
> 
> I can't reconcile that with the fact that LSB-compliant packages are
> ordered to have dependencies that indicate which LSB modules are
> required.

I thought the point of LSB was to make it possible to provide a working 
program independently from any distribution's packaging system quirks. 
At least that's the only reason I see to care about it at all.  If it 
just duplicates things packaging systems already do, why bother?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jkeating at redhat.com  Wed Nov 12 20:21:28 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 12 Nov 2008 12:21:28 -0800
Subject: starting Fedora Server SIG
In-Reply-To: <20081112201609.GC19196@mokona.greysector.net>
References: <491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112192855.GB12723@nostromo.devel.redhat.com>
	<491B3002.1030002@gmail.com>
	<1226519094.5295.14.camel@luminos.localdomain>
	<491B3716.1050706@gmail.com>
	<20081112201042.GA13652@nostromo.devel.redhat.com>
	<20081112201609.GC19196@mokona.greysector.net>
Message-ID: <1226521288.5295.26.camel@luminos.localdomain>

On Wed, 2008-11-12 at 21:16 +0100, Dominik 'Rathann' Mierzejewski wrote:
> 
> You say it as if nothing handled it before plymouth appeared when in fact
> it worked just fine without rhgb, which plymouth is supposedly replacing.

When was the last time you had a working /var/log/boot.log ?  (pre
plymouth that is)

I seem to recall it has been broken for quite some 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/20081112/0c1957b9/attachment.sig>

From limb at jcomserv.net  Wed Nov 12 20:22:20 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Wed, 12 Nov 2008 14:22:20 -0600 (CST)
Subject: starting Fedora Server SIG
In-Reply-To: <491B2B27.1060703@gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<778179b00811120400s5fda1277y2130ceddeb9d0422@mail.gmail.com>
	<1226491831.3752.298.camel@beck.corsepiu.local>
	<491AE00F.5010703@gmail.com>
	<1226515548.31982.403.camel@atropine.boston.devel.redhat.com>
	<1226515988.5295.5.camel@luminos.localdomain>
	<71051a5a7ff9f9bc8da6c383a4ba235c.squirrel@mail.jcomserv.net>
	<491B2B27.1060703@gmail.com>
Message-ID: <32227dfa84e9d3f2337a10682cd87685.squirrel@mail.jcomserv.net>


> Jon Ciesla wrote:
>
>>>> Yes, they are.  On an install without any X components, 'yum install
>>>> gnome-terminal' will pull in X libs but not an X server.
>>>>
>>> In fact, if you install the gnome desktop group, but don't check the X
>>> group, you get gnome but not X server to run it on.
>>
>> Perfect for ssh tunneling or a freenx server.
>
> Will you be missing any authentication or device ownership magic if you
> use freenx exclusively instead of the console?

I would expect to add those bits manually if authconfig didn't provide
them.  Kickstart FTW!

> --
>    Les Mikesell
>     lesmikesell at gmail.com
>


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

-d. bowie



From jkeating at redhat.com  Wed Nov 12 20:22:30 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 12 Nov 2008 12:22:30 -0800
Subject: starting Fedora Server SIG
In-Reply-To: <20081112201354.GB19196@mokona.greysector.net>
References: <778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226518090.3638.37.camel@eagle.danny.cz>
	<20081112192954.GC12723@nostromo.devel.redhat.com>
	<87iqqsiubm.fsf@sheridan.bigo.ensc.de>
	<1226520557.5295.20.camel@luminos.localdomain>
	<20081112201354.GB19196@mokona.greysector.net>
Message-ID: <1226521350.5295.27.camel@luminos.localdomain>

On Wed, 2008-11-12 at 21:13 +0100, Dominik 'Rathann' Mierzejewski wrote:
> I don't need a fancy progress bar that drags in tens of MBs of dependencies,
> thank you. After all, nobody is going to see it anyway.

Tens of MBs of deps for the text and details plugin?  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/20081112/4af54aa0/attachment.sig>

From notting at redhat.com  Wed Nov 12 20:23:29 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 12 Nov 2008 15:23:29 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <5256d0b0811121216h72dc6e35x38d15fc9890e025@mail.gmail.com>
References: <5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226518090.3638.37.camel@eagle.danny.cz>
	<20081112192954.GC12723@nostromo.devel.redhat.com>
	<491B327E.3040608@gmail.com>
	<20081112194926.GE12723@nostromo.devel.redhat.com>
	<5256d0b0811121216h72dc6e35x38d15fc9890e025@mail.gmail.com>
Message-ID: <20081112202329.GC13652@nostromo.devel.redhat.com>

Peter Robinson (pbrobinson at gmail.com) said: 
> > Probably just about as well as setting up a passphrased-protected
> > encrypted volume worked before plymouth.
> >
> > Now, if you want to set it up to use keys from a file...
> 
> Is it/would it be possible to take that from something like a smart
> card or similar of physical and removable device?

Not without breaking the current crypttab format - it currently
only specifies a path to the file, there's not a device:path syntax.

(TBH - I haven't checked that specifying a passphrase file works
for the root filesystem - it may be worth testing.)

Bill



From jspaleta at gmail.com  Wed Nov 12 20:33:01 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 12 Nov 2008 11:33:01 -0900
Subject: Proposal: Rolling Release
In-Reply-To: <491B19B6.40509@gmail.com>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<20081111204717.GB15724@orient.maison.lan>
	<4919F7C5.1090705@gmail.com>
	<1226439740.10458.15.camel@luminos.localdomain>
	<491A6E59.3070803@leemhuis.info> <491B0873.50503@gmail.com>
	<604aa7910811120851u361eac4sc4c05c2baf57fda4@mail.gmail.com>
	<491B145E.3020900@gmail.com>
	<604aa7910811120944r81e6b8bsc23ef3ef60d2bd69@mail.gmail.com>
	<491B19B6.40509@gmail.com>
Message-ID: <604aa7910811121233l40705289q9478607a66762549@mail.gmail.com>

On Wed, Nov 12, 2008 at 9:00 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> That's the wrong question.  The real question is, what interface did you
> just break in an update? You don't need to know anything about anyone else's
> software.  You just need to provide working interfaces.  Or, when you
> whimsically break them in updates, give a hint about how to get a working
> version back.

Are you suggesting that we should never provide an unstable interface
in any of the libraries or scripting modules that we package?  And
that we only provide technologies that upstream has committed to API
stability between subsequent releases? Surely you aren't suggesting
that.  You can't really expect us to hold an API stable when upstream
isn't...that's just silly.

At best you could maybe hope for a subset of available technologies to
be identified as upstream interface stable, and get a subset of
maintainers to pledge to keep interfaces stable inside a release
timeframe in conjunction with those upstream projects. There is no
coherent initiative towards what could be generously termed a 'Fedora
SDK'. I've seen no interest from a group of active
maintainers..ever..to take on that problem space and commit to seeing
it happen.  Something like this would require a community member to
step forward and be a strong, active, persuasive leader on the effort.

I very much doubt that you are the right person to lead such an
effort, even if you did decide this is the issue that would finally
get you off the fence and working on something constructively.  So my
advice to you is, dial back the rhetoric and see if you can get other
people talking about this and identify the person you think can lead
this initiative.

-jef"if I only had a beowulf cluster of XO's"spaleta



From dominik at greysector.net  Wed Nov 12 20:34:41 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 12 Nov 2008 21:34:41 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <1226521288.5295.26.camel@luminos.localdomain>
References: <491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112192855.GB12723@nostromo.devel.redhat.com>
	<491B3002.1030002@gmail.com>
	<1226519094.5295.14.camel@luminos.localdomain>
	<491B3716.1050706@gmail.com>
	<20081112201042.GA13652@nostromo.devel.redhat.com>
	<20081112201609.GC19196@mokona.greysector.net>
	<1226521288.5295.26.camel@luminos.localdomain>
Message-ID: <20081112203440.GD19196@mokona.greysector.net>

On Wednesday, 12 November 2008 at 21:21, Jesse Keating wrote:
> On Wed, 2008-11-12 at 21:16 +0100, Dominik 'Rathann' Mierzejewski wrote:
> > 
> > You say it as if nothing handled it before plymouth appeared when in fact
> > it worked just fine without rhgb, which plymouth is supposedly replacing.
> 
> When was the last time you had a working /var/log/boot.log ?  (pre
> plymouth that is)
> 
> I seem to recall it has been broken for quite some time.

Hm, you're right, all my boot.log files are 0 bytes (F-9). So instead of fixing
the bug, a new package was introduced? Amazing.

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 notting at redhat.com  Wed Nov 12 20:43:38 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 12 Nov 2008 15:43:38 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <20081112203440.GD19196@mokona.greysector.net>
References: <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112192855.GB12723@nostromo.devel.redhat.com>
	<491B3002.1030002@gmail.com>
	<1226519094.5295.14.camel@luminos.localdomain>
	<491B3716.1050706@gmail.com>
	<20081112201042.GA13652@nostromo.devel.redhat.com>
	<20081112201609.GC19196@mokona.greysector.net>
	<1226521288.5295.26.camel@luminos.localdomain>
	<20081112203440.GD19196@mokona.greysector.net>
Message-ID: <20081112204338.GA14068@nostromo.devel.redhat.com>

Dominik 'Rathann' Mierzejewski (dominik at greysector.net) said: 
> > When was the last time you had a working /var/log/boot.log ?  (pre
> > plymouth that is)
> > 
> > I seem to recall it has been broken for quite some time.
> 
> Hm, you're right, all my boot.log files are 0 bytes (F-9). So instead of fixing
> the bug, a new package was introduced? Amazing.

Because, of course, that doesn't ever happen. We don't fix suspend by
introducing new packages like pm-utils. We don't fix X by moving from
XFree86 to X.org. We don't fix syslog deficiencies by moving from
sysklogd to rsyslog. We don't fix issues with device naming by moving
from devlabel (ayaaaaaaugh) to udev.

So, if we can find a way to arrange the output plugins, what is the issue
here other than "Change? We fear change!"

Bill



From jkeating at redhat.com  Wed Nov 12 20:43:27 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 12 Nov 2008 12:43:27 -0800
Subject: starting Fedora Server SIG
In-Reply-To: <20081112203440.GD19196@mokona.greysector.net>
References: <491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112192855.GB12723@nostromo.devel.redhat.com>
	<491B3002.1030002@gmail.com>
	<1226519094.5295.14.camel@luminos.localdomain>
	<491B3716.1050706@gmail.com>
	<20081112201042.GA13652@nostromo.devel.redhat.com>
	<20081112201609.GC19196@mokona.greysector.net>
	<1226521288.5295.26.camel@luminos.localdomain>
	<20081112203440.GD19196@mokona.greysector.net>
Message-ID: <1226522607.5295.29.camel@luminos.localdomain>

On Wed, 2008-11-12 at 21:34 +0100, Dominik 'Rathann' Mierzejewski wrote:
> Hm, you're right, all my boot.log files are 0 bytes (F-9). So instead
> of fixing
> the bug, a new package was introduced? Amazing.

No, instead of spending a lot of time and effort fixing it in two
places, and maintaining it in two places, we did it in one.

I'm still not buying that plymouth + text plugin is such a huge burden
upon minimal installs.

-- 
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/20081112/6e49f91b/attachment.sig>

From cdahlin at redhat.com  Wed Nov 12 20:57:55 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 12 Nov 2008 15:57:55 -0500
Subject: F8 EOL messaging
In-Reply-To: <20081112164544.GB6260@nostromo.devel.redhat.com>
References: <20081112010144.GE8501@localhost.localdomain>
	<20081112164544.GB6260@nostromo.devel.redhat.com>
Message-ID: <491B4353.80405@redhat.com>

Bill Nottingham wrote:
> Paul W. Frields (stickster at gmail.com) said: 
>   
>> It seems really wrong to EOL F8 on Christmas Day.  Can we make that
>> December 26th? :-)
>>     
>
> Hm, I suppose part of it is 'when do we have someone available to do
> the final update push?'
>
> Bill
>
>   
Was the answer to that question really "Christmas Day" previously?

--CJD



From emmanuel.seyman at club-internet.fr  Wed Nov 12 21:03:50 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Wed, 12 Nov 2008 22:03:50 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <491B3A75.5000407@gmail.com>
References: <1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<20081112170805.GC6260@nostromo.devel.redhat.com>
	<1226510160.3638.28.camel@eagle.danny.cz>
	<alpine.LFD.2.00.0811121305350.31693@localhost.localdomain>
	<491B21D2.4010104@gmail.com>
	<20081112200804.GA25197@orient.maison.lan>
	<491B3A75.5000407@gmail.com>
Message-ID: <20081112210350.GA25498@orient.maison.lan>

* Les Mikesell [12/11/2008 21:26] :
>
> I thought the point of LSB was to make it possible to provide a working  
> program independently from any distribution's packaging system quirks.  

[ I'm having trouble parsing the above sentence. ]

The point of the LSB is to enable third-party vendors to make a
LSB-compliant binary package and ensure it runs on any LSB-compliant
Linux distribution. It won't be integrated as well as a
distribution-specific package but it will work.

> At least that's the only reason I see to care about it at all.  If it  
> just duplicates things packaging systems already do, why bother?

Search me...
A while back, I became convinced that the LSB was a conspiracy to get
all the people interested in running closed-source software on GNU/Linux
distributions involved in a project that
  a) required vast amounts of time and energy to run and
  b) was doomed to fail,
thus minimizing the harm they could do. I haven't seen anything since
then that would make me change my mind.

Emmanuel



From jkeating at redhat.com  Wed Nov 12 21:04:44 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 12 Nov 2008 13:04:44 -0800
Subject: F8 EOL messaging
In-Reply-To: <491B4353.80405@redhat.com>
References: <20081112010144.GE8501@localhost.localdomain>
	<20081112164544.GB6260@nostromo.devel.redhat.com>
	<491B4353.80405@redhat.com>
Message-ID: <1226523884.5295.31.camel@luminos.localdomain>

On Wed, 2008-11-12 at 15:57 -0500, Casey Dahlin wrote:
> Was the answer to that question really "Christmas Day" previously?

Killing Fedora releases is the only Christmas present I look forward to.

-- 
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/20081112/e47ae2c2/attachment.sig>

From mdehaan at redhat.com  Wed Nov 12 21:18:49 2008
From: mdehaan at redhat.com (Michael DeHaan)
Date: Wed, 12 Nov 2008 16:18:49 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <1226429441.3593.77.camel@eagle.danny.cz>
References: <1226429441.3593.77.camel@eagle.danny.cz>
Message-ID: <491B4839.5010704@redhat.com>

Dan Hor?k wrote:
> There were many discussions in the past few days and weeks about the
> orientation Fedora currently has. It is a fact that currently
> Fedora is primarily desktop oriented.
>
> We agree that Desktop is important part of the system, it is highly
> visible to the public and large number of Fedora users. But we also see
> a large number of Fedora and CentOS users and RHEL customers with very
> specific needs and demands. We can not omit the server fundamentals that
> later create a successful enterprise product and in our opinion a formal
> entity must exist to coordinate these efforts.
>
> That's why we started work on establishing the Fedora Server SIG. The
> draft is available at https://fedoraproject.org/wiki/DanHorak/ServerSIG
> Any constructive ideas are welcome  :-)
>
>
> 		Dan
>
>   

Strongly interested.   All I do in Fedora/EPEL-land is focused towards 
enterprisey/server usage and there are some suprisingly large 
datacenter/grid installations.   

Please do start a list.   Fedora-devel is much too high traffic to keep 
up momentum (kind of like carrying on a conversation while treading 
water in a rough sea) and I can guarantee you'll see interest.

I'll offer to bring this up on the cobbler and Func lists, I'd suggest 
you also mention this on the EPEL list as there's a lot of overlap with 
that community and Fedora development interests.

I think some of the most important things we can do is encourage people 
to share information about the tools they are using, getting them 
packaged, and creating a community for people who use Fedora in server 
configurations to talk about what they are doing and how we can better 
integrate management applications.   The value in spins diminishes when 
network install environments are available -- so I'm much less 
interested in that.  Providing a community where we can get people 
together who use Fedora in a server context however, and just see what 
happens, however, would be supremely valuable.

--Michael




From lesmikesell at gmail.com  Wed Nov 12 21:44:23 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 12 Nov 2008 15:44:23 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <604aa7910811121233l40705289q9478607a66762549@mail.gmail.com>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>	<20081111204717.GB15724@orient.maison.lan>	<4919F7C5.1090705@gmail.com>	<1226439740.10458.15.camel@luminos.localdomain>	<491A6E59.3070803@leemhuis.info>
	<491B0873.50503@gmail.com>	<604aa7910811120851u361eac4sc4c05c2baf57fda4@mail.gmail.com>	<491B145E.3020900@gmail.com>	<604aa7910811120944r81e6b8bsc23ef3ef60d2bd69@mail.gmail.com>	<491B19B6.40509@gmail.com>
	<604aa7910811121233l40705289q9478607a66762549@mail.gmail.com>
Message-ID: <491B4E37.30706@gmail.com>

Jeff Spaleta wrote:
> 
>> That's the wrong question.  The real question is, what interface did you
>> just break in an update? You don't need to know anything about anyone else's
>> software.  You just need to provide working interfaces.  Or, when you
>> whimsically break them in updates, give a hint about how to get a working
>> version back.
> 
> Are you suggesting that we should never provide an unstable interface
> in any of the libraries or scripting modules that we package?

No, I'm saying that necessary changes should be planned, and to the 
extent possible, batched at version releases.  And where that isn't 
possible, interface and command line changes to expect should be 
published before the update so users and 3rd parties know how to work 
around the breakage.

> And
> that we only provide technologies that upstream has committed to API
> stability between subsequent releases?

I'd like that very much but given what you have to work with, I'll agree 
it is impossible.  However, like any other QA aspect, I'm suggesting 
that you do the best you can not to break local or 3rd party programs 
built on the platform you just shipped.

> Surely you aren't suggesting
> that.  You can't really expect us to hold an API stable when upstream
> isn't...that's just silly.

No, what is silly is to actually try to use a platform that you know is 
going to break because the people building it have no concern for the 
people using it.  Even simple things like the change in samba that broke 
backuppc's ability to pass windows authentication some time ago can be a 
disaster.

> At best you could maybe hope for a subset of available technologies to
> be identified as upstream interface stable, and get a subset of
> maintainers to pledge to keep interfaces stable inside a release
> timeframe in conjunction with those upstream projects.

Who forces you to push interface-changing updates out of rawhide?  If I 
wanted today's bugs from an upstream project I'd grab it from there 
instead of using a distribution's release version of the code.   The 
fedora major release cycle is already fast enough anyway.  If some 
upstream project can't settle on an interface you are doing your users a 
favor by keeping it away from them.

> There is no
> coherent initiative towards what could be generously termed a 'Fedora
> SDK'. I've seen no interest from a group of active
> maintainers..ever..to take on that problem space and commit to seeing
> it happen.  Something like this would require a community member to
> step forward and be a strong, active, persuasive leader on the effort.

I'm not sure what that even means.  If fedora has something unique, I 
don't particularly want it and don't understand why anyone would develop 
for something intentionally non-standard.  What I'd really want is for 
LSB-compliance to someday get to the point where programs running on 
Fedora would never need to know that it is fedora at all, much less the 
version and last-update-date underneath.

> I very much doubt that you are the right person to lead such an
> effort, even if you did decide this is the issue that would finally
> get you off the fence and working on something constructively.  So my
> advice to you is, dial back the rhetoric and see if you can get other
> people talking about this and identify the person you think can lead
> this initiative.

Is there someone involved in development that eats his own dog food 
(i.e. uses fedora with current updates as infrastructure for some large 
project or even in a lab setting with many users)?

-- 
   Les Mikesell
     lesmikesell at gmail.com



From lesmikesell at gmail.com  Wed Nov 12 21:53:50 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 12 Nov 2008 15:53:50 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <20081112210350.GA25498@orient.maison.lan>
References: <1226480816.3638.19.camel@eagle.danny.cz>	<1226485422.3638.22.camel@eagle.danny.cz>	<20081112111712.GB3142@free.fr>	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>	<20081112170805.GC6260@nostromo.devel.redhat.com>	<1226510160.3638.28.camel@eagle.danny.cz>	<alpine.LFD.2.00.0811121305350.31693@localhost.localdomain>	<491B21D2.4010104@gmail.com>	<20081112200804.GA25197@orient.maison.lan>	<491B3A75.5000407@gmail.com>
	<20081112210350.GA25498@orient.maison.lan>
Message-ID: <491B506E.4080505@gmail.com>

Emmanuel Seyman wrote:
> * Les Mikesell [12/11/2008 21:26] :
>> I thought the point of LSB was to make it possible to provide a working  
>> program independently from any distribution's packaging system quirks.  
> 
> [ I'm having trouble parsing the above sentence. ]
> 
> The point of the LSB is to enable third-party vendors to make a
> LSB-compliant binary package and ensure it runs on any LSB-compliant
> Linux distribution. It won't be integrated as well as a
> distribution-specific package but it will work.

Does the LSB demand that program be encapsulated in 
distribution,version-specific packages before it can work? If it does, I 
don't see much advantage over having to build in every 
distribution,version environment in the first place.  And if not, then 
how is it supposed to know about the dependencies you mentioned.

>> At least that's the only reason I see to care about it at all.  If it  
>> just duplicates things packaging systems already do, why bother?
> 
> Search me...
> A while back, I became convinced that the LSB was a conspiracy to get
> all the people interested in running closed-source software on GNU/Linux
> distributions involved in a project that
>   a) required vast amounts of time and energy to run and
>   b) was doomed to fail,
> thus minimizing the harm they could do. I haven't seen anything since
> then that would make me change my mind.

I have to agree that so far the LSB appears to be aimlessly moving 
things around - but I don't see why that would have to be the case if 
someone actually wanted programs to run.

-- 
    Les Mikesell
     lesmikesell at gmail.com



From alan at redhat.com  Wed Nov 12 21:58:57 2008
From: alan at redhat.com (Alan Cox)
Date: Wed, 12 Nov 2008 16:58:57 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <1226520557.5295.20.camel@luminos.localdomain>
References: <778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226518090.3638.37.camel@eagle.danny.cz>
	<20081112192954.GC12723@nostromo.devel.redhat.com>
	<87iqqsiubm.fsf@sheridan.bigo.ensc.de>
	<1226520557.5295.20.camel@luminos.localdomain>
Message-ID: <20081112215857.GB3409@shell.devel.redhat.com>

On Wed, Nov 12, 2008 at 12:09:17PM -0800, Jesse Keating wrote:
> Don't be so sure about that.  In a colo environment I /would/ want some
> encryption on the disk, and if I have to use a remote kvm to input the

If you are storing personal data on a system in a colo its practically mandatory
to have encryption, and if you are storing anything sensitive its a big deal
indeed - at least in those parts of the world with real data and privacy law ;)



From skvidal at fedoraproject.org  Wed Nov 12 22:00:47 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 12 Nov 2008 17:00:47 -0500 (EST)
Subject: starting Fedora Server SIG
In-Reply-To: <20081112215857.GB3409@shell.devel.redhat.com>
References: <778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226518090.3638.37.camel@eagle.danny.cz>
	<20081112192954.GC12723@nostromo.devel.redhat.com>
	<87iqqsiubm.fsf@sheridan.bigo.ensc.de>
	<1226520557.5295.20.camel@luminos.localdomain>
	<20081112215857.GB3409@shell.devel.redhat.com>
Message-ID: <alpine.LFD.2.00.0811121659510.31693@localhost.localdomain>



On Wed, 12 Nov 2008, Alan Cox wrote:

> On Wed, Nov 12, 2008 at 12:09:17PM -0800, Jesse Keating wrote:
>> Don't be so sure about that.  In a colo environment I /would/ want some
>> encryption on the disk, and if I have to use a remote kvm to input the
>
> If you are storing personal data on a system in a colo its practically mandatory
> to have encryption, and if you are storing anything sensitive its a big deal
> indeed - at least in those parts of the world with real data and privacy law ;)
>

And with more things using xen/kvm instances you can have the encryption 
work inside the install and access the console for typing in a password in 
a variety of interesting ways.

-sv



From jspaleta at gmail.com  Wed Nov 12 21:51:44 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 12 Nov 2008 12:51:44 -0900
Subject: Proposal: Rolling Release
In-Reply-To: <491B4E37.30706@gmail.com>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<1226439740.10458.15.camel@luminos.localdomain>
	<491A6E59.3070803@leemhuis.info> <491B0873.50503@gmail.com>
	<604aa7910811120851u361eac4sc4c05c2baf57fda4@mail.gmail.com>
	<491B145E.3020900@gmail.com>
	<604aa7910811120944r81e6b8bsc23ef3ef60d2bd69@mail.gmail.com>
	<491B19B6.40509@gmail.com>
	<604aa7910811121233l40705289q9478607a66762549@mail.gmail.com>
	<491B4E37.30706@gmail.com>
Message-ID: <604aa7910811121351k709ec984l1e98fa06562910a6@mail.gmail.com>

On Wed, Nov 12, 2008 at 12:44 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> I'd like that very much but given what you have to work with, I'll agree it
> is impossible.  However, like any other QA aspect, I'm suggesting that you
> do the best you can not to break local or 3rd party programs built on the
> platform you just shipped.

How about this for an answer. Given what we have to work with right
now. We are doing our best.
Now if you and anyone else don't think our current best effort is not
good enough.. you can certainly choose to add your manhours into the
effort.  Which packages would you specifically like to help
co-maintain?

-jef



From nicolas.mailhot at laposte.net  Wed Nov 12 22:06:29 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 12 Nov 2008 23:06:29 +0100
Subject: New font-design group in Fedora 11
Message-ID: <1226527589.25306.3.camel@arekh.okg>

Hi,

At the demand of the free/open font community, a font-design group has
been added to Fedora 11 comps (may still find a way to slip it in Fedora
10 post-release).
You may add your font-related tools there now.

Comments/corrections are welcome.

http://cvs.fedoraproject.org/viewvc/comps/comps-f11.xml.in?r1=1.6&r2=1.7


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/20081112/ac962871/attachment.sig>

From lesmikesell at gmail.com  Wed Nov 12 23:02:23 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 12 Nov 2008 17:02:23 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <604aa7910811121351k709ec984l1e98fa06562910a6@mail.gmail.com>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>	<1226439740.10458.15.camel@luminos.localdomain>	<491A6E59.3070803@leemhuis.info>
	<491B0873.50503@gmail.com>	<604aa7910811120851u361eac4sc4c05c2baf57fda4@mail.gmail.com>	<491B145E.3020900@gmail.com>	<604aa7910811120944r81e6b8bsc23ef3ef60d2bd69@mail.gmail.com>	<491B19B6.40509@gmail.com>	<604aa7910811121233l40705289q9478607a66762549@mail.gmail.com>	<491B4E37.30706@gmail.com>
	<604aa7910811121351k709ec984l1e98fa06562910a6@mail.gmail.com>
Message-ID: <491B607F.9020306@gmail.com>

Jeff Spaleta wrote:
> On Wed, Nov 12, 2008 at 12:44 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
>> I'd like that very much but given what you have to work with, I'll agree it
>> is impossible.  However, like any other QA aspect, I'm suggesting that you
>> do the best you can not to break local or 3rd party programs built on the
>> platform you just shipped.
> 
> How about this for an answer. Given what we have to work with right
> now. We are doing our best.

OK, but if breakage didn't scare off the user base maybe there would be 
a lot more to work with.

> Now if you and anyone else don't think our current best effort is not
> good enough.. you can certainly choose to add your manhours into the
> effort.  Which packages would you specifically like to help
> co-maintain?

It's not really about effort or engineering or packaging, all of which 
are probably better in fedora than anywhere else.  It's more about 
timing and recognizing the effect of an interface change on the things 
on the other side of it.  Just admitting that there are things on the 
other side of the interfaces you ship would be a start.  Otherwise it is 
an endless package shuffle for no end purpose and no way to tell if you 
are going forwards or backwards.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From bojan at rexursive.com  Wed Nov 12 23:02:23 2008
From: bojan at rexursive.com (Bojan Smojver)
Date: Wed, 12 Nov 2008 23:02:23 +0000 (UTC)
Subject: Proposal: Rolling Release
References: <ce9c609e0811100542h5638368bt64ecc0ebc2c629f@mail.gmail.com>
	<loom.20081111T010408-920@post.gmane.org>
	<20081111160318.GF22663@nostromo.devel.redhat.com>
	<1dedbbfc0811110930y294ce663ld396b2000f083dba@mail.gmail.com>
Message-ID: <loom.20081112T225733-85@post.gmane.org>

David Nielsen <gnomeuser <at> gmail.com> writes:

> And if it's deemed stable enough for F10 as a release then surely it should be
stable enough as an update for F9. A big and not uncomplicated update granted
but we could in theory put this into updates-testing and roll it out for F9 as
well. If the argument against doing this would be stability one would be left
questioning how F10 could be labelled stable in the fist place.

An oversimplification, IMHO. Just because all that was stable with the rest of
the stuff shipped with F-10, doesn't mean the effect will be the same when it
lands next to the rest of the stuff from F-9. It needs to be compiled (with a
different compiler and libs?), packaged (against different dependencies?) and
tested _again_ (in how many combinations?).

It is just too much work for not good reason whatsoever.

--
Bojan



From alsadi at gmail.com  Wed Nov 12 23:07:36 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Thu, 13 Nov 2008 01:07:36 +0200
Subject: a trivial fix makes a big change
Message-ID: <385866f0811121507y228eb82egb77544b3edccae3f@mail.gmail.com>

I made a trivial fix to this bug
https://bugzilla.redhat.com/show_bug.cgi?id=447072#c1

nautilus-share now works, just right click share and you are there

the problem is that this package is broken since the F9 and it's an
orphan package

how can we manage to get it working a gain

can it be in F10 or it's too late for that an I should hope that it
would be in F11

note: the fix is trivial which is to replace the directory name from
-1.0 to -2.0

a second thing I want to request a feature for F11
that this package works with zero user configuration
just installing this package, ie. to make the changes in the smb.conf
to be default



From lesmikesell at gmail.com  Wed Nov 12 23:18:24 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 12 Nov 2008 17:18:24 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1226520557.5295.20.camel@luminos.localdomain>
References: <1226485422.3638.22.camel@eagle.danny.cz>	<20081112110506.GA3142@free.fr>
	<20081112131806.GA1461854@hiwaay.net>	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>	<491AED13.8050204@comcast.net>	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>	<491AF259.40907@comcast.net>
	<20081112191551.GC1461854@hiwaay.net>	<1226518090.3638.37.camel@eagle.danny.cz>	<20081112192954.GC12723@nostromo.devel.redhat.com>	<87iqqsiubm.fsf@sheridan.bigo.ensc.de>
	<1226520557.5295.20.camel@luminos.localdomain>
Message-ID: <491B6440.6050609@gmail.com>

Jesse Keating wrote:
> On Wed, 2008-11-12 at 21:05 +0100, Enrico Scholz wrote:
>> This thread is about a *server* SIG, isn't it?  Most servers do not need
>> disk encryption as they are located in physically secured rooms.  They
>> must be able to reboot without manual interaction too.
>>
>> Hence, when password prompts are the only reason for plymouth, then
>> plymouth should be optional; especially when it has heavy dependencies
>> like pango.
> 
> Don't be so sure about that.  In a colo environment I /would/ want some
> encryption on the disk, and if I have to use a remote kvm to input the
> passphrase at reboot time, that's OK.

It might be good to have as an option for the database holding the 
personal or credit card info but I don't think you'd really like that on 
a large server farm.

> Reboots are either planned
> events, or emergencies, both of which are going to require the attention
> of the people who have the passphrase.

A normal reboot is needed at least as often as you push new kernels (we 
are still talking about fedora, aren't we?) - not something that should 
require a cross country trip.  And there's always the rare case where 
your UPS or power transfer switch fails and all of a sudden you have to 
bring back hundreds of machines as fast as you can.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From emmanuel.seyman at club-internet.fr  Wed Nov 12 23:23:05 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Thu, 13 Nov 2008 00:23:05 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <491B506E.4080505@gmail.com>
References: <20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<20081112170805.GC6260@nostromo.devel.redhat.com>
	<1226510160.3638.28.camel@eagle.danny.cz>
	<alpine.LFD.2.00.0811121305350.31693@localhost.localdomain>
	<491B21D2.4010104@gmail.com>
	<20081112200804.GA25197@orient.maison.lan>
	<491B3A75.5000407@gmail.com>
	<20081112210350.GA25498@orient.maison.lan>
	<491B506E.4080505@gmail.com>
Message-ID: <20081112232305.GB25696@orient.maison.lan>

* Les Mikesell [12/11/2008 23:07] :
>
> Does the LSB demand that program be encapsulated in  
> distribution,version-specific packages before it can work?

LSB requires an application to either be packaged as an RPM or supply an
installer which is itself LSB conforming.

> If it does, I don't see much advantage over having to build in every  
> distribution,version environment in the first place.  And if not, then  
> how is it supposed to know about the dependencies you mentioned.

The LSB specifies an lsb_release program that you can use to determine
how LSB compliant the box is :

[manu at orient ~]$ /usr/bin/lsb_release
LSB Version:	:core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch

Emmanuel



From jkeating at redhat.com  Wed Nov 12 23:22:54 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 12 Nov 2008 15:22:54 -0800
Subject: starting Fedora Server SIG
In-Reply-To: <491B6440.6050609@gmail.com>
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr> <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226518090.3638.37.camel@eagle.danny.cz>
	<20081112192954.GC12723@nostromo.devel.redhat.com>
	<87iqqsiubm.fsf@sheridan.bigo.ensc.de>
	<1226520557.5295.20.camel@luminos.localdomain>
	<491B6440.6050609@gmail.com>
Message-ID: <1226532175.5295.36.camel@luminos.localdomain>

On Wed, 2008-11-12 at 17:18 -0600, Les Mikesell wrote:
> A normal reboot is needed at least as often as you push new kernels (we 
> are still talking about fedora, aren't we?) - not something that should 
> require a cross country trip.  And there's always the rare case where 
> your UPS or power transfer switch fails and all of a sudden you have to 
> bring back hundreds of machines as fast as you can.

A reboot for new kernels is a planned event right?

And we're not necessarily talking about 100s of machines needing the
encryption, only a few that really really need it.  Basically don't
write off encryption as a local only technology.

-- 
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/20081112/8b7ced0c/attachment.sig>

From csnook at redhat.com  Wed Nov 12 23:40:43 2008
From: csnook at redhat.com (Chris Snook)
Date: Wed, 12 Nov 2008 18:40:43 -0500
Subject: a trivial fix makes a big change
In-Reply-To: <385866f0811121507y228eb82egb77544b3edccae3f@mail.gmail.com>
References: <385866f0811121507y228eb82egb77544b3edccae3f@mail.gmail.com>
Message-ID: <491B697B.4030603@redhat.com>

Muayyad AlSadi wrote:
> I made a trivial fix to this bug
> https://bugzilla.redhat.com/show_bug.cgi?id=447072#c1
> 
> nautilus-share now works, just right click share and you are there
> 
> the problem is that this package is broken since the F9 and it's an
> orphan package
> 
> how can we manage to get it working a gain

You can volunteer to maintain it.

> can it be in F10 or it's too late for that an I should hope that it
> would be in F11

It's too late to put it in the install image, but there's no reason we couldn't 
put it in the yum repo.

> note: the fix is trivial which is to replace the directory name from
> -1.0 to -2.0
> 
> a second thing I want to request a feature for F11
> that this package works with zero user configuration
> just installing this package, ie. to make the changes in the smb.conf
> to be default

The RPM philosophy is that installation and configuration should be separate 
activities.  There are a few carefully reasoned exceptions we permit, but by and 
large, when packagers violate this policy, bad things happen.  As a general 
rule, installing a GUI convenience package (or having it pulled in as a 
dependency) shouldn't mess with your Samba configuration.

If there's a way to make the default smb.conf enable nautilus-share when 
installed, and do no harm when not installed, that would be okay if you can 
somehow address the inherent security concerns.  I doubt that's possible, so it 
would probably make more sense to have a configuration wizard.

-- Chris



From lesmikesell at gmail.com  Wed Nov 12 23:41:58 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 12 Nov 2008 17:41:58 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1226532175.5295.36.camel@luminos.localdomain>
References: <1226485422.3638.22.camel@eagle.danny.cz>	<20081112110506.GA3142@free.fr>
	<20081112131806.GA1461854@hiwaay.net>	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>	<491AED13.8050204@comcast.net>	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>	<491AF259.40907@comcast.net>
	<20081112191551.GC1461854@hiwaay.net>	<1226518090.3638.37.camel@eagle.danny.cz>	<20081112192954.GC12723@nostromo.devel.redhat.com>	<87iqqsiubm.fsf@sheridan.bigo.ensc.de>	<1226520557.5295.20.camel@luminos.localdomain>	<491B6440.6050609@gmail.com>
	<1226532175.5295.36.camel@luminos.localdomain>
Message-ID: <491B69C6.2080000@gmail.com>

Jesse Keating wrote:
> On Wed, 2008-11-12 at 17:18 -0600, Les Mikesell wrote:
>> A normal reboot is needed at least as often as you push new kernels (we 
>> are still talking about fedora, aren't we?) - not something that should 
>> require a cross country trip.  And there's always the rare case where 
>> your UPS or power transfer switch fails and all of a sudden you have to 
>> bring back hundreds of machines as fast as you can.
> 
> A reboot for new kernels is a planned event right?
> 
> And we're not necessarily talking about 100s of machines needing the
> encryption, only a few that really really need it.  Basically don't
> write off encryption as a local only technology.

No argument about the value - but it seems similar to the need for the 
md devices at boot time.  If you don't need it, why include it in the 
install?  A tool help modify initrd post-install would be nice to fix 
things up when the boot hardware or requirements change, though.

-- 
   Les Mikesell
    lesmikesell at gmailc.om



From lesmikesell at gmail.com  Wed Nov 12 23:46:47 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 12 Nov 2008 17:46:47 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <20081112232305.GB25696@orient.maison.lan>
References: <20081112111712.GB3142@free.fr>	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>	<20081112170805.GC6260@nostromo.devel.redhat.com>	<1226510160.3638.28.camel@eagle.danny.cz>	<alpine.LFD.2.00.0811121305350.31693@localhost.localdomain>	<491B21D2.4010104@gmail.com>	<20081112200804.GA25197@orient.maison.lan>	<491B3A75.5000407@gmail.com>	<20081112210350.GA25498@orient.maison.lan>	<491B506E.4080505@gmail.com>
	<20081112232305.GB25696@orient.maison.lan>
Message-ID: <491B6AE7.6030905@gmail.com>

Emmanuel Seyman wrote:
> * Les Mikesell [12/11/2008 23:07] :
>> Does the LSB demand that program be encapsulated in  
>> distribution,version-specific packages before it can work?
> 
> LSB requires an application to either be packaged as an RPM or supply an
> installer which is itself LSB conforming.

What does that mean for distributions that don't use RPM?

>> If it does, I don't see much advantage over having to build in every  
>> distribution,version environment in the first place.  And if not, then  
>> how is it supposed to know about the dependencies you mentioned.
> 
> The LSB specifies an lsb_release program that you can use to determine
> how LSB compliant the box is :
> 
> [manu at orient ~]$ /usr/bin/lsb_release
> LSB Version:	:core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch

Gak.. something that specifies locations by purpose wants an information 
file in /usr/bin?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Wed Nov 12 23:49:31 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 12 Nov 2008 17:49:31 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <32227dfa84e9d3f2337a10682cd87685.squirrel@mail.jcomserv.net>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<778179b00811120400s5fda1277y2130ceddeb9d0422@mail.gmail.com>
	<1226491831.3752.298.camel@beck.corsepiu.local>
	<491AE00F.5010703@gmail.com>
	<1226515548.31982.403.camel@atropine.boston.devel.redhat.com>
	<1226515988.5295.5.camel@luminos.localdomain>
	<71051a5a7ff9f9bc8da6c383a4ba235c.squirrel@mail.jcomserv.net>
	<491B2B27.1060703@gmail.com>
	<32227dfa84e9d3f2337a10682cd87685.squirrel@mail.jcomserv.net>
Message-ID: <491B6B8B.5040201@gmail.com>

Jon Ciesla wrote:
>
>>>>> Yes, they are.  On an install without any X components, 'yum install
>>>>> gnome-terminal' will pull in X libs but not an X server.
>>>>>
>>>> In fact, if you install the gnome desktop group, but don't check the X
>>>> group, you get gnome but not X server to run it on.
>>> Perfect for ssh tunneling or a freenx server.
>> Will you be missing any authentication or device ownership magic if you
>> use freenx exclusively instead of the console?
> 
> I would expect to add those bits manually if authconfig didn't provide
> them.  Kickstart FTW!

I thought these days certain things were changed dynamically depending 
on who logged into the console.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jkeating at redhat.com  Wed Nov 12 23:50:04 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 12 Nov 2008 15:50:04 -0800
Subject: starting Fedora Server SIG
In-Reply-To: <491B6AE7.6030905@gmail.com>
References: <20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<20081112170805.GC6260@nostromo.devel.redhat.com>
	<1226510160.3638.28.camel@eagle.danny.cz>
	<alpine.LFD.2.00.0811121305350.31693@localhost.localdomain>
	<491B21D2.4010104@gmail.com>	<20081112200804.GA25197@orient.maison.lan>
	<491B3A75.5000407@gmail.com>	<20081112210350.GA25498@orient.maison.lan>
	<491B506E.4080505@gmail.com> <20081112232305.GB25696@orient.maison.lan>
	<491B6AE7.6030905@gmail.com>
Message-ID: <1226533804.5295.38.camel@luminos.localdomain>

On Wed, 2008-11-12 at 17:46 -0600, Les Mikesell wrote:
> What does that mean for distributions that don't use RPM?

rpm is part of lsb requirements is it not?

> 
> >> If it does, I don't see much advantage over having to build in every  
> >> distribution,version environment in the first place.  And if not, then  
> >> how is it supposed to know about the dependencies you mentioned.
> > 
> > The LSB specifies an lsb_release program that you can use to determine
> > how LSB compliant the box is :
> > 
> > [manu at orient ~]$ /usr/bin/lsb_release
> > LSB Version:  :core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch
> 
> Gak.. something that specifies locations by purpose wants an information 
> file in /usr/bin?

it's not a text file, it's an application that will check your level of
lsb.

-- 
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/20081112/6aaf45e9/attachment.sig>

From jkeating at redhat.com  Wed Nov 12 23:51:22 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 12 Nov 2008 15:51:22 -0800
Subject: starting Fedora Server SIG
In-Reply-To: <491B69C6.2080000@gmail.com>
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr> <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226518090.3638.37.camel@eagle.danny.cz>
	<20081112192954.GC12723@nostromo.devel.redhat.com>
	<87iqqsiubm.fsf@sheridan.bigo.ensc.de>
	<1226520557.5295.20.camel@luminos.localdomain>	<491B6440.6050609@gmail.com>
	<1226532175.5295.36.camel@luminos.localdomain>
	<491B69C6.2080000@gmail.com>
Message-ID: <1226533883.5295.39.camel@luminos.localdomain>

On Wed, 2008-11-12 at 17:41 -0600, Les Mikesell wrote:
> No argument about the value - but it seems similar to the need for the 
> md devices at boot time.  If you don't need it, why include it in the 
> install?  A tool help modify initrd post-install would be nice to fix 
> things up when the boot hardware or requirements change, though.

Now you've lost me.

-- 
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/20081112/38b71b27/attachment.sig>

From sundaram at fedoraproject.org  Thu Nov 13 00:11:16 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 13 Nov 2008 05:41:16 +0530
Subject: a trivial fix makes a big change
In-Reply-To: <385866f0811121507y228eb82egb77544b3edccae3f@mail.gmail.com>
References: <385866f0811121507y228eb82egb77544b3edccae3f@mail.gmail.com>
Message-ID: <491B70A4.6090102@fedoraproject.org>

Muayyad AlSadi wrote:
> I made a trivial fix to this bug
> https://bugzilla.redhat.com/show_bug.cgi?id=447072#c1
> 
> nautilus-share now works, just right click share and you are there
> 
> the problem is that this package is broken since the F9 and it's an
> orphan package
> 
> how can we manage to get it working a gain

Sign up to be a maintainer.

Rahul



From jspaleta at gmail.com  Thu Nov 13 00:25:16 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 12 Nov 2008 15:25:16 -0900
Subject: starting Fedora Server SIG
In-Reply-To: <491B6AE7.6030905@gmail.com>
References: <20081112111712.GB3142@free.fr>
	<1226510160.3638.28.camel@eagle.danny.cz>
	<alpine.LFD.2.00.0811121305350.31693@localhost.localdomain>
	<491B21D2.4010104@gmail.com>
	<20081112200804.GA25197@orient.maison.lan>
	<491B3A75.5000407@gmail.com>
	<20081112210350.GA25498@orient.maison.lan>
	<491B506E.4080505@gmail.com>
	<20081112232305.GB25696@orient.maison.lan>
	<491B6AE7.6030905@gmail.com>
Message-ID: <604aa7910811121625h6294d9d0r75d760221959a523@mail.gmail.com>

On Wed, Nov 12, 2008 at 2:46 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> What does that mean for distributions that don't use RPM?

Is a Fedora mailinglist really the best place to have an informed
discussion on how non-RPM based distros deal with the requirements of
the LSB?  The fact that you are asking this question may indicate that
this is a very good time to perhaps stop talking and to take a step
back to do a baseline assessment concerning what the LSB actually
mandates.

-jef"
http://packages.debian.org/etch/lsb-core
depends on: http://packages.debian.org/etch/alien
depends on: http://packages.debian.org/etch/rpm
"spaleta

-jef"



From dominik at greysector.net  Thu Nov 13 00:26:00 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 13 Nov 2008 01:26:00 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <20081112204338.GA14068@nostromo.devel.redhat.com>
References: <1226517797.5295.13.camel@luminos.localdomain>
	<20081112192855.GB12723@nostromo.devel.redhat.com>
	<491B3002.1030002@gmail.com>
	<1226519094.5295.14.camel@luminos.localdomain>
	<491B3716.1050706@gmail.com>
	<20081112201042.GA13652@nostromo.devel.redhat.com>
	<20081112201609.GC19196@mokona.greysector.net>
	<1226521288.5295.26.camel@luminos.localdomain>
	<20081112203440.GD19196@mokona.greysector.net>
	<20081112204338.GA14068@nostromo.devel.redhat.com>
Message-ID: <20081113002559.GA21498@mokona.greysector.net>

On Wednesday, 12 November 2008 at 21:43, Bill Nottingham wrote:
[...]
> So, if we can find a way to arrange the output plugins, what is the issue
> here other than "Change? We fear change!"

OK. One more thing. Where in the picture is plymouth if I don't specify "rhgb"
at the kernel's command line?

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 lesmikesell at gmail.com  Thu Nov 13 00:31:20 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 12 Nov 2008 18:31:20 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1226533883.5295.39.camel@luminos.localdomain>
References: <1226485422.3638.22.camel@eagle.danny.cz>	<20081112110506.GA3142@free.fr>
	<20081112131806.GA1461854@hiwaay.net>	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>	<491AED13.8050204@comcast.net>	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>	<491AF259.40907@comcast.net>
	<20081112191551.GC1461854@hiwaay.net>	<1226518090.3638.37.camel@eagle.danny.cz>	<20081112192954.GC12723@nostromo.devel.redhat.com>	<87iqqsiubm.fsf@sheridan.bigo.ensc.de>	<1226520557.5295.20.camel@luminos.localdomain>	<491B6440.6050609@gmail.com>	<1226532175.5295.36.camel@luminos.localdomain>	<491B69C6.2080000@gmail.com>
	<1226533883.5295.39.camel@luminos.localdomain>
Message-ID: <491B7558.1040204@gmail.com>

Jesse Keating wrote:
> On Wed, 2008-11-12 at 17:41 -0600, Les Mikesell wrote:
>> No argument about the value - but it seems similar to the need for the 
>> md devices at boot time.  If you don't need it, why include it in the 
>> install?  A tool help modify initrd post-install would be nice to fix 
>> things up when the boot hardware or requirements change, though.
> 
> Now you've lost me.

When you install, something decides whether or not to include the md 
module in the installed initrd.  Shouldn't the same decision be made for 
  whatever handles encryption and any other services it will need at 
about the same time?  Hmmm, maybe that's a different choice than whether 
it needs to be available, though.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From sundaram at fedoraproject.org  Thu Nov 13 00:39:08 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 13 Nov 2008 06:09:08 +0530
Subject: starting Fedora Server SIG
In-Reply-To: <20081113002559.GA21498@mokona.greysector.net>
References: <1226517797.5295.13.camel@luminos.localdomain>	<20081112192855.GB12723@nostromo.devel.redhat.com>	<491B3002.1030002@gmail.com>	<1226519094.5295.14.camel@luminos.localdomain>	<491B3716.1050706@gmail.com>	<20081112201042.GA13652@nostromo.devel.redhat.com>	<20081112201609.GC19196@mokona.greysector.net>	<1226521288.5295.26.camel@luminos.localdomain>	<20081112203440.GD19196@mokona.greysector.net>	<20081112204338.GA14068@nostromo.devel.redhat.com>
	<20081113002559.GA21498@mokona.greysector.net>
Message-ID: <491B772C.6050805@fedoraproject.org>

Dominik 'Rathann' Mierzejewski wrote:
> On Wednesday, 12 November 2008 at 21:43, Bill Nottingham wrote:
> [...]
>> So, if we can find a way to arrange the output plugins, what is the issue
>> here other than "Change? We fear change!"
> 
> OK. One more thing. Where in the picture is plymouth if I don't specify "rhgb"
> at the kernel's command line?
> 
> Regards,
> R.

http://fedoraproject.org/wiki/Releases/FeatureBetterStartup

"If rhgb is not in the kernel commandline, we still run plymouthd and it 
handles input but we just don't do the graphical plugins. This lets us 
consistently be able to count on plymouth being available "

Rahul



From bruno at wolff.to  Thu Nov 13 00:39:15 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 12 Nov 2008 18:39:15 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <491B6440.6050609@gmail.com>
References: <5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226518090.3638.37.camel@eagle.danny.cz>
	<20081112192954.GC12723@nostromo.devel.redhat.com>
	<87iqqsiubm.fsf@sheridan.bigo.ensc.de>
	<1226520557.5295.20.camel@luminos.localdomain>
	<491B6440.6050609@gmail.com>
Message-ID: <20081113003915.GA18025@wolff.to>

On Wed, Nov 12, 2008 at 17:18:24 -0600,
  Les Mikesell <lesmikesell at gmail.com> wrote:
> Jesse Keating wrote:
>>
>> Don't be so sure about that.  In a colo environment I /would/ want some
>> encryption on the disk, and if I have to use a remote kvm to input the
>> passphrase at reboot time, that's OK.
>
> It might be good to have as an option for the database holding the  
> personal or credit card info but I don't think you'd really like that on  
> a large server farm.

If you have any data you want confidential at a server farm, you want to
consider encryption. What if someone subpoena's the colo company? How do you
know they aren't going to roll over and release your data without giving you
a chance to contest it?



From bruno at wolff.to  Thu Nov 13 00:41:30 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 12 Nov 2008 18:41:30 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <491B7558.1040204@gmail.com>
References: <20081112191551.GC1461854@hiwaay.net>
	<1226518090.3638.37.camel@eagle.danny.cz>
	<20081112192954.GC12723@nostromo.devel.redhat.com>
	<87iqqsiubm.fsf@sheridan.bigo.ensc.de>
	<1226520557.5295.20.camel@luminos.localdomain>
	<491B6440.6050609@gmail.com>
	<1226532175.5295.36.camel@luminos.localdomain>
	<491B69C6.2080000@gmail.com>
	<1226533883.5295.39.camel@luminos.localdomain>
	<491B7558.1040204@gmail.com>
Message-ID: <20081113004130.GB18025@wolff.to>

On Wed, Nov 12, 2008 at 18:31:20 -0600,
  Les Mikesell <lesmikesell at gmail.com> wrote:
> Jesse Keating wrote:
>> On Wed, 2008-11-12 at 17:41 -0600, Les Mikesell wrote:
>>> No argument about the value - but it seems similar to the need for 
>>> the md devices at boot time.  If you don't need it, why include it in 
>>> the install?  A tool help modify initrd post-install would be nice to 
>>> fix things up when the boot hardware or requirements change, though.
>>
>> Now you've lost me.
>
> When you install, something decides whether or not to include the md  
> module in the installed initrd.  Shouldn't the same decision be made for  
>  whatever handles encryption and any other services it will need at  
> about the same time?  Hmmm, maybe that's a different choice than whether  
> it needs to be available, though.

mkinitrd I believe. I have had problems with yum upgrades where mkinitrd
didn't include all of the modules the new kernel was going to need, because
it was basing something on how it worked on the installed kernel.



From lesmikesell at gmail.com  Thu Nov 13 00:42:49 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 12 Nov 2008 18:42:49 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <604aa7910811121625h6294d9d0r75d760221959a523@mail.gmail.com>
References: <20081112111712.GB3142@free.fr>	<1226510160.3638.28.camel@eagle.danny.cz>	<alpine.LFD.2.00.0811121305350.31693@localhost.localdomain>	<491B21D2.4010104@gmail.com>	<20081112200804.GA25197@orient.maison.lan>	<491B3A75.5000407@gmail.com>	<20081112210350.GA25498@orient.maison.lan>	<491B506E.4080505@gmail.com>	<20081112232305.GB25696@orient.maison.lan>	<491B6AE7.6030905@gmail.com>
	<604aa7910811121625h6294d9d0r75d760221959a523@mail.gmail.com>
Message-ID: <491B7809.2040005@gmail.com>

Jeff Spaleta wrote:
> On Wed, Nov 12, 2008 at 2:46 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
>> What does that mean for distributions that don't use RPM?
> 
> Is a Fedora mailinglist really the best place to have an informed
> discussion on how non-RPM based distros deal with the requirements of
> the LSB?  The fact that you are asking this question may indicate that
> this is a very good time to perhaps stop talking and to take a step
> back to do a baseline assessment concerning what the LSB actually
> mandates.
> 
> -jef"
> http://packages.debian.org/etch/lsb-core
> depends on: http://packages.debian.org/etch/alien
> depends on: http://packages.debian.org/etch/rpm
> "spaleta
> 

According to this, 
http://en.wikipedia.org/wiki/Linux_Standard_Base#Criticism
debian might not be the best place either.  If it has to install rpms it 
already misses the point of being distribution-agnostic.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From bpepple at fedoraproject.org  Thu Nov 13 00:44:53 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 12 Nov 2008 19:44:53 -0500
Subject: FESCo Meeting Summary for 2008-11-12
Message-ID: <1226537093.21353.14.camel@kennedy>

=== Members Present ===
* Brian Pepple          (bpepple)
* Jarod Wilson          (j-rod)
* Bill Nottingham       (notting)
* Jon Stanley           (jds2001)
* Karsten Hopp          (kick_)
* Kevin Fenzi           (nirik)
* Josh Boyer            (jwb)
* David Woodhouse       (dwmw2)
* Dennis Gilmore        (dgilmore)

== Summary ==
=== Features ===
      * FESCo approved the following policy changes to the Features
        process:
              * Feature owner will be cc'd on agenda & meeting summaries
                where there feature is discussed (Feature owners will
                need to include e-mail addresses on the feature page).
              * One week prior to final freeze, testing must have
                returned reasonable results or will consider drop,
                contingency plan, etc.

=== FESCo Election ===
      * The nomination period for the four open seats in the upcoming
        FESCo election is open.  If you would like to run for FESCo,
        please add you nomination here:
        http://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations

=== FESCo Chair ===
      * bpepple attempted to abdicate his chair position, but was
        convinced to continue until after the upcoming elections.  They
        will look at having a secretary position in future FESCo's to
        reduce the work load on the chair position.

IRC log can be found at:
http://bpepple.fedorapeople.org/fesco/FESCo-2008-11-12.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/20081112/88984ce8/attachment.sig>

From emmanuel.seyman at club-internet.fr  Thu Nov 13 00:45:45 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Thu, 13 Nov 2008 01:45:45 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <491B6AE7.6030905@gmail.com>
References: <20081112170805.GC6260@nostromo.devel.redhat.com>
	<1226510160.3638.28.camel@eagle.danny.cz>
	<alpine.LFD.2.00.0811121305350.31693@localhost.localdomain>
	<491B21D2.4010104@gmail.com>
	<20081112200804.GA25197@orient.maison.lan>
	<491B3A75.5000407@gmail.com>
	<20081112210350.GA25498@orient.maison.lan>
	<491B506E.4080505@gmail.com>
	<20081112232305.GB25696@orient.maison.lan>
	<491B6AE7.6030905@gmail.com>
Message-ID: <20081113004545.GA26214@orient.maison.lan>

* Les Mikesell [13/11/2008 01:08] :
>
> What does that mean for distributions that don't use RPM?

The LSB doesn't impose you use rpm, just that you accept rpm pacakges.
Alien and Ubuntu use alien to convert the rpms to debs before
installation.

If you're really interested in the LSB, you're be better served by reading
the spec (or, at least, Wikipedia's entry of it) rather than getting my
interpretation of it.

http://www.linuxfoundation.org/en/Specifications
http://en.wikipedia.org/wiki/Linux_Standard_Base

>> [manu at orient ~]$ /usr/bin/lsb_release
>> LSB Version:	:core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch
>
> Gak.. something that specifies locations by purpose wants an information  
> file in /usr/bin?

It's a non-essential binary usable by all users.
The LSB (through the FHS) mandates that it be in /usr/bin .

Emmanuel



From stickster at gmail.com  Thu Nov 13 00:36:27 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Wed, 12 Nov 2008 19:36:27 -0500
Subject: ERR: Board IRC meeting **1900 UTC** 2008-11-18
In-Reply-To: <20081112125250.GA6439@localhost.localdomain>
References: <20081112125250.GA6439@localhost.localdomain>
Message-ID: <20081113003627.GA32412@localhost.localdomain>

On Wed, Nov 12, 2008 at 07:52:50AM -0500, Paul W. Frields wrote:
> The Board is holding its monthly public meeting on Tuesday, 18 November
> 2008, at 1800 UTC on IRC Freenode.  The public is invited to do the
> following:

Apologies to all, DST change fail!

The meeting will occur at **1900 UTC**.  That's 2:00 US-Eastern for
those of you keeping score at home.

Thanks for your attention and sorry about the mistake.

-- 
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/20081112/0b9698c8/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 rodrigopadula at projetofedora.org  Thu Nov 13 03:58:13 2008
From: rodrigopadula at projetofedora.org (Rodrigo Padula de Oliveira)
Date: Thu, 13 Nov 2008 01:58:13 -0200
Subject: [Bug 471343] New: Error to create a livecd minimal.ks based
In-Reply-To: <bug-471343-194791@bugzilla.redhat.com>
References: <bug-471343-194791@bugzilla.redhat.com>
Message-ID: <491BA5D5.9030309@projetofedora.org>

Hello Guys!

Somebody can help me ?

bugzilla at redhat.com escreveu:
> Please do not reply directly to this email. All additional
> comments should be made in the comments box of this bug.
> 
> Summary: Error to create a livecd minimal.ks based
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=471343
> 
>            Summary: Error to create a livecd minimal.ks based
>            Product: Fedora
>            Version: rawhide
>           Platform: i386
>         OS/Version: Linux
>             Status: NEW
>           Severity: urgent
>           Priority: medium
>          Component: livecd-tools
>         AssignedTo: katzj at redhat.com
>         ReportedBy: rodrigopadula at projetofedora.org
>          QAContact: extras-qa at fedoraproject.org
>                 CC: katzj at redhat.com, davidz at redhat.com
>     Classification: Fedora
> 
> 
> Command executed:
> livecd-creator --verbose --config=livecd-fedora-minimal.ks
> --fslabel=Fedora_10-Padula_Teste
> 
> Error:
> 
> This filesystem will be automatically checked every 26 mounts or
> 180 days, whichever comes first.  Use tune2fs -c or -i to override.
> tune2fs 1.41.3 (12-Oct-2008)
> Setting maximal mount count to -1
> Setting interval between checks to 0 seconds
> Retrieving
> http://fedora.c3sl.ufpr.br/linux/development/i386/os/repodata/repomd.xml ...OK
> Retrieving
> http://fedora.c3sl.ufpr.br/linux/development/i386/os/repodata/308b02df8b0887e7fc522377a9dfa7a98fe87090-primary.sqlite.bz2
> ...OK
> Traceback (most recent call last):
>   File "/usr/bin/livecd-creator", line 136, in <module>
>     sys.exit(main())
>   File "/usr/bin/livecd-creator", line 128, in main
>     logging.error("Error creating Live CD : %s" % e)
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xed' in position
> 66: ordinal not in range(128)
> 



From sundaram at fedoraproject.org  Thu Nov 13 04:00:15 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 13 Nov 2008 09:30:15 +0530
Subject: Keeping an eye on fedora-list
Message-ID: <491BA64F.3020104@fedoraproject.org>

Hi,

If you are a developer of a key component of Fedora such as Anaconda, 
Kernel, NetworkManager, PulseAudio, PackageKit, yum etc, I would request 
that you subscribe and follow fedora-list to keep an eye on the 
discussions.

There are a few developers who consistently do this. I recall Dan Walsh 
for SELinux and Tim Waugh for printing (CUPS, system-config-printer), 
KDE SIG people, Dave Jones for kernel (atleast a bit earlier) 
consistently doing this and we are all better off a result of that.

I know you are all busy and it is difficult to follow a high traffic 
list in additional to dealing with bug reports, packaging and other 
tasks but it is quite useful to know what common issues affect end users.

This is especially if true if this is a new component like say Plymouth. 
Just a request.

Rahul



From sundaram at fedoraproject.org  Thu Nov 13 04:07:26 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 13 Nov 2008 09:37:26 +0530
Subject: [Bug 471343] New: Error to create a livecd minimal.ks based
In-Reply-To: <491BA5D5.9030309@projetofedora.org>
References: <bug-471343-194791@bugzilla.redhat.com>
	<491BA5D5.9030309@projetofedora.org>
Message-ID: <491BA7FE.9090609@fedoraproject.org>

Rodrigo Padula de Oliveira wrote:
> Hello Guys!
> 
> Somebody can help me ?

Where is your kickstart file? Are you including the updates repository 
in it? The error looks like the one I used to get from an older version 
of yum.

Also pick and use a local mirror or one that is synced properly and use 
--cachedir=<foo> to avoid redownloading packages everytime.

Rahul



From rodrigopadula at projetofedora.org  Thu Nov 13 04:19:04 2008
From: rodrigopadula at projetofedora.org (Rodrigo Padula de Oliveira)
Date: Thu, 13 Nov 2008 02:19:04 -0200
Subject: [Bug 471343] New: Error to create a livecd minimal.ks based
In-Reply-To: <491BA7FE.9090609@fedoraproject.org>
References: <bug-471343-194791@bugzilla.redhat.com>	<491BA5D5.9030309@projetofedora.org>
	<491BA7FE.9090609@fedoraproject.org>
Message-ID: <491BAAB8.3040802@projetofedora.org>

Rahul Sundaram escreveu:
> Rodrigo Padula de Oliveira wrote:
>> Hello Guys!
>>
>> Somebody can help me ?
> 
> Where is your kickstart file? Are you including the updates repository
> in it? The error looks like the one I used to get from an older version
> of yum.
> 
> Also pick and use a local mirror or one that is synced properly and use
> --cachedir=<foo> to avoid redownloading packages everytime.
> 
> Rahul
> 

I'm using the basic livecd-fedora-minimal.ks in the livecd-tools folder.

-- 

Rodrigo Padula de Oliveira
M.Sc. Student - COPPE/UFRJ
Fedora Community Manager - Latin America
http://www.proyectofedora.org





From sundaram at fedoraproject.org  Thu Nov 13 04:30:37 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 13 Nov 2008 10:00:37 +0530
Subject: [Bug 471343] New: Error to create a livecd minimal.ks based
In-Reply-To: <491BAAB8.3040802@projetofedora.org>
References: <bug-471343-194791@bugzilla.redhat.com>	<491BA5D5.9030309@projetofedora.org>	<491BA7FE.9090609@fedoraproject.org>
	<491BAAB8.3040802@projetofedora.org>
Message-ID: <491BAD6D.8050602@fedoraproject.org>

Rodrigo Padula de Oliveira wrote:

> I'm using the basic livecd-fedora-minimal.ks in the livecd-tools folder

What does your host run? Is the livecd-tools and yum the latest? You 
might want to try including the updates repository in the kickstart 
file. Login with the locale set to US English might help as well.

Rahul



From rodrigopadula at projetofedora.org  Thu Nov 13 04:34:35 2008
From: rodrigopadula at projetofedora.org (Rodrigo Padula de Oliveira)
Date: Thu, 13 Nov 2008 02:34:35 -0200
Subject: [Bug 471343] New: Error to create a livecd minimal.ks based
In-Reply-To: <491BAD6D.8050602@fedoraproject.org>
References: <bug-471343-194791@bugzilla.redhat.com>	<491BA5D5.9030309@projetofedora.org>	<491BA7FE.9090609@fedoraproject.org>	<491BAAB8.3040802@projetofedora.org>
	<491BAD6D.8050602@fedoraproject.org>
Message-ID: <491BAE5B.90807@projetofedora.org>

Rahul Sundaram escreveu:
> Rodrigo Padula de Oliveira wrote:
> 
>> I'm using the basic livecd-fedora-minimal.ks in the livecd-tools folder
> 
> What does your host run? Is the livecd-tools and yum the latest? You
> might want to try including the updates repository in the kickstart
> file. Login with the locale set to US English might help as well.
> 
> Rahul
> 

I'm using the default file of Fedora 10 Preview livecd-tools (last version).

Please, see the bug 471343
-- 

Rodrigo Padula de Oliveira
M.Sc. Student - COPPE/UFRJ
Fedora Community Manager - Latin America
http://www.proyectofedora.org





From joshuacov at googlemail.com  Thu Nov 13 05:18:53 2008
From: joshuacov at googlemail.com (Joshua C.)
Date: Thu, 13 Nov 2008 06:18:53 +0100
Subject: F10 Post-Preview snapshots?
In-Reply-To: <20081112151234.GA311@wolff.to>
References: <5f6f8c5f0811111114i302752e4pb900c595ef0b0763@mail.gmail.com>
	<20081112030339.GA15403@wolff.to>
	<5f6f8c5f0811120454x40f7378ah6a8b20986cf01fe6@mail.gmail.com>
	<20081112151234.GA311@wolff.to>
Message-ID: <5f6f8c5f0811122118k250d7c3cyb59031c33bd3b0b3@mail.gmail.com>

2008/11/12 Bruno Wolff III <bruno at wolff.to>:
> On Wed, Nov 12, 2008 at 13:54:52 +0100,
>  "Joshua C." <joshuacov at googlemail.com> wrote:
>>
>> I have i686 and want to try x86_64. therefore i downloaded livecd but
>> because of a dsdt error i need to recompile the x86_64 kernel. this is
>> not possible on i686 installation and the dsdt fix was committed to
>> f10 kernel after the preview release.
>>
>> Therefore I need a precompiled livecd image, which won't be released
>> before stable :(
>
> Rawhide has later kernels, so you might be able to build a Live CD yourself
> without having to rebuild the kernel. I haven't tried to build a liveCD for
> x86_64 on i386, but I would expect this to be possible.
>

No, it is not. x86_64 livecd can only be created in a x86_64
environment, bacause the installation on the packages includes running
the post section of some of them which requires x86_64 binaries. :(



From paul at xelerance.com  Thu Nov 13 05:59:40 2008
From: paul at xelerance.com (Paul Wouters)
Date: Thu, 13 Nov 2008 00:59:40 -0500 (EST)
Subject: starting Fedora Server SIG
In-Reply-To: <1226532175.5295.36.camel@luminos.localdomain>
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr>
	<20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226518090.3638.37.camel@eagle.danny.cz>
	<20081112192954.GC12723@nostromo.devel.redhat.com>
	<87iqqsiubm.fsf@sheridan.bigo.ensc.de>
	<1226520557.5295.20.camel@luminos.localdomain>
	<491B6440.6050609@gmail.com>
	<1226532175.5295.36.camel@luminos.localdomain>
Message-ID: <alpine.LFD.1.10.0811130059100.23693@newtla.xelerance.com>


> A normal reboot is needed at least as often as you push new kernels (we

kexec?

Paul



From enrico.scholz at informatik.tu-chemnitz.de  Thu Nov 13 09:00:21 2008
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Thu, 13 Nov 2008 10:00:21 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <20081112200750.GF1461854@hiwaay.net> (Chris Adams's message of
	"Wed, 12 Nov 2008 14:07:50 -0600")
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr> <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
Message-ID: <87ej1ghufu.fsf@sheridan.bigo.ensc.de>

Chris Adams <cmadams at hiwaay.net> writes:

> If I explicitly add "plymouth-text-and-details-only" to my install,
> it satisfies the system-plymouth-plugin dependency, and I don't get
> libX11 and such.
>
> Maybe plymouth-text-and-details-only should be in @core and
> plymouth-plugin-solar in @base?

Maybe 'yum' should be fixed to handle ambiguous situations better?
E.g. fail, warn and/or prompt when multiple packages satisfy a (virtual)
dependency?


Enrico



From dominik at greysector.net  Thu Nov 13 09:52:20 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 13 Nov 2008 10:52:20 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <491B772C.6050805@fedoraproject.org>
References: <491B3002.1030002@gmail.com>
	<1226519094.5295.14.camel@luminos.localdomain>
	<491B3716.1050706@gmail.com>
	<20081112201042.GA13652@nostromo.devel.redhat.com>
	<20081112201609.GC19196@mokona.greysector.net>
	<1226521288.5295.26.camel@luminos.localdomain>
	<20081112203440.GD19196@mokona.greysector.net>
	<20081112204338.GA14068@nostromo.devel.redhat.com>
	<20081113002559.GA21498@mokona.greysector.net>
	<491B772C.6050805@fedoraproject.org>
Message-ID: <20081113095219.GA25904@mokona.greysector.net>

On Thursday, 13 November 2008 at 01:39, Rahul Sundaram wrote:
> Dominik 'Rathann' Mierzejewski wrote:
> >On Wednesday, 12 November 2008 at 21:43, Bill Nottingham wrote:
> >[...]
> >>So, if we can find a way to arrange the output plugins, what is the issue
> >>here other than "Change? We fear change!"
> >
> >OK. One more thing. Where in the picture is plymouth if I don't specify 
> >"rhgb"
> >at the kernel's command line?
> >
> >Regards,
> >R.
> 
> http://fedoraproject.org/wiki/Releases/FeatureBetterStartup
> 
> "If rhgb is not in the kernel commandline, we still run plymouthd and it 
> handles input but we just don't do the graphical plugins. This lets us 
> consistently be able to count on plymouth being available "

O...K. Thank you. I wouldn't have guessed I should look under "Tasks".

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  Thu Nov 13 09:54:55 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 13 Nov 2008 10:54:55 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <87ej1ghufu.fsf@sheridan.bigo.ensc.de>
References: <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
Message-ID: <20081113095455.GB25904@mokona.greysector.net>

On Thursday, 13 November 2008 at 10:00, Enrico Scholz wrote:
> Chris Adams <cmadams at hiwaay.net> writes:
> 
> > If I explicitly add "plymouth-text-and-details-only" to my install,
> > it satisfies the system-plymouth-plugin dependency, and I don't get
> > libX11 and such.
> >
> > Maybe plymouth-text-and-details-only should be in @core and
> > plymouth-plugin-solar in @base?
> 
> Maybe 'yum' should be fixed to handle ambiguous situations better?
> E.g. fail, warn and/or prompt when multiple packages satisfy a (virtual)
> dependency?

+1 for prompting, i.e.

2 packages found satisfying "system-plymouth-plugin" dependency:
1: plymouth-graphics-solar
2: plymouth-text-and-details-only
Enter number to select [1]:

Of course, the usual select-the-one-with-the-shortest-name behaviour would
occur when using -y.

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 karsten at redhat.com  Thu Nov 13 12:29:19 2008
From: karsten at redhat.com (Karsten Hopp)
Date: Thu, 13 Nov 2008 13:29:19 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <1226420875.3368.1.camel@localhost.localdomain>
References: <48ECE6CC.6030001@cora.nwra.com>	<20081008171428.GA7911@nostromo.devel.redhat.com>	<20081008171607.GE3447@yoda.jdub.homelinux.org>	<48ECEFB9.1080600@redhat.com>
	<1226420875.3368.1.camel@localhost.localdomain>
Message-ID: <491C1D9F.4020508@redhat.com>

Matthias Clasen schrieb:
> On Wed, 2008-10-08 at 19:36 +0200, Karsten Hopp wrote:
> 
>> Getting libtool-2.2 into F-11 is my plan, but I most likely need to get that through
>> FESCo as it breaks up to 300 packages according to my mass rebuilds. I'm going to
>> prepare a Wiki page with details about that.
> 
> F11 is open for business now. I think it would be a good idea to get the
> libtool2 conversion underway early in the cycle.
> 
> 
> Matthias
> 

Matthias Clasen schrieb:
 > On Wed, 2008-10-08 at 19:36 +0200, Karsten Hopp wrote:
 >
 >> Getting libtool-2.2 into F-11 is my plan, but I most likely need to get that through
 >> FESCo as it breaks up to 300 packages according to my mass rebuilds. I'm going to
 >> prepare a Wiki page with details about that.
 >
 > F11 is open for business now. I think it would be a good idea to get the
 > libtool2 conversion underway early in the cycle.
 >
 >
 > Matthias
 >

I'm going to build libtool-2.2.6a soon. As this will bump the soname of libltdl, the following
packages depending on that will need to be rebuilt:

autodir thias
ettercap limb
freeradius jdennis
gambas2 spot
gift rdieter
google-gadgets salimma
graphviz jima
guile mlichvar
gyachi sundaram
heartbeat kevin
ImageMagick nmurray
libcanberra lennart
libextractor ensc
libgphoto2 jnovy
libp11 mra
mapnik rezso
mysql-connector-odbc tgl
openct tmraz
openhpi sharkcz
openldap jsafrane
opensc tmraz
picviz theinric
pinball limb
player timn
plplot orion
pulseaudio lennart
rcssbase hedayat
sox jmoskovc


A copy of this mail goes to the maintainers of these packages.

    Karsten



From rawhide at fedoraproject.org  Thu Nov 13 12:43:07 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Thu, 13 Nov 2008 12:43:07 +0000 (UTC)
Subject: rawhide report: 20081113 changes
Message-ID: <20081113124307.5CB291F8258@releng2.fedora.phx.redhat.com>

Compose started at Thu Nov 13 06:01:34 UTC 2008

Updated Packages:

gridengine-6.2-4.fc10
---------------------
* Tue Nov 11 17:00:00 2008 - Orion Poplawski <orion at cora.nwra.com> - 6.2-4
- Add note to README about localhost line in /etc/hosts
- Cleanup setting.sh some, no more MAN stuff
- Add conditional build support for EL

* Wed Nov  5 17:00:00 2008 - Orion Poplawski <orion at cora.nwra.com> - 6.2-3
- Add Requires: ncurses for "clear"
- Add patch from CVS to update install scripts
- Patch sge_ca script not to use system openssl
- Modify code to dlopen runtime ssl library
- Patch install_qmaster to update /etc/sysconfig/gridengine
- Point install scripts to proper JAVA_HOME
- Have sgemaster init script use /etc/sysconfig/gridengine
- Add patch to point to jni library locations
- Make sure install_qmaster sets up default managers/operators


gstreamer-0.10.21-2.fc10
------------------------
* Tue Nov 11 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.10.21-2
- fix gnome bz 555631 with patch from upstream cvs
- use system libtool to prevent rpaths


kdepim-4.1.2-5.fc10
-------------------
* Tue Nov 11 17:00:00 2008 Jaroslav Reznik <jreznik at redhat.com> 4.1.2-5
- revert akregator systray show/hide backport (#471022)
- fix akregator crashes on startup (#469452)


kernel-2.6.27.5-101.fc10
------------------------
* Wed Nov 12 17:00:00 2008 Dave Airlie <airlied at redhat.com> 2.6.27.5-101
- drm/intel: further interrupt fixes

* Tue Nov 11 17:00:00 2008 Dave Jones <davej at redhat.com> 2.6.27.5-98
- qla3xxx: Cleanup: Fix link print statements. (#461623)

* Tue Nov 11 17:00:00 2008 Dave Jones <davej at redhat.com> 2.6.27.5-97
- ALSA: revo51: add headphone output. (#470813)

* Tue Nov 11 17:00:00 2008 Dave Airlie <airlied at redhat.com> 2.6.27.5-99
- drm rebase patches against latest upstream tree.

* Tue Nov 11 17:00:00 2008 Chuck Ebbert <cebbert at redhat.com> 2.6.27.5-100
- Check for additional ATI chipset timer bugs (#470939, #470723)


livecd-tools-020-1.fc10
-----------------------
* Wed Nov 12 17:00:00 2008 Jeremy Katz <katzj at redhat.com> - 020-1
- Support setting up a swap file
- Verify integer args in livecd-iso-to-disk (#467257)
- Set up persistent /home on internal mtd0 for XO
- Default to resetting the overlay on XO
- Support copying the raw ext3fs to the usb stick instead of the squash
- Mactel fixes
- Align initrd properly on XO (#467093)
- Make initrd load addr work on newer XO firmwares
- Fix up Xen paths for Xen live images (Michael Ansel)
- Support --defaultdesktop (Orion Poplawski)


mkinitrd-6.0.71-2.fc10
----------------------
* Wed Nov 12 17:00:00 2008 Peter Jones <pjones at redhat.com> - 6.0.71-2
- Rebuild on the F-10 branch.

* Wed Nov 12 17:00:00 2008 Peter Jones <pjones at redhat.com> - 6.0.71-1
- Allow passing live_keytable= for live keyboard (katzj, #470869)
- Add "mkchardevs" command, so /dev/hvc* get created (#470839)
- Fix option passing in mountCommand (#471142)
- Do full console initialization in the initrd, not just keymap
  (notting, #458362)
- move loadDrivers before plymouth for ltsp (wtogami, #470858)


mod_fcgid-2.2-7.fc10
--------------------
* Wed Nov 12 17:00:00 2008 Paul Howarth <paul at city-fan.org> 2.2-7
- SELinux policy module no longer built for Fedora 8 onwards as it is
  obsoleted by the main selinux-policy package
- Conflicts for selinux-policy packages older than the releases where mod_fcgid
  policy was incorporated have been added for Fedora 8, 9, and 10 versions, to
  ensure that SELinux support will work if installed


optipng-0.6.2-1.fc10
--------------------
* Wed Nov 12 17:00:00 2008 Till Maas <opensource at till.name> - 0.6.2-1
- Update to new release to fix buffer overflow
- Red Hat Bugzilla #471206


pm-utils-1.2.2.1-2.fc10
-----------------------
* Tue Nov  4 17:00:00 2008 Richard Hughes <rhughes at redhat.com> - 1.2.2.1-2
- Add a patch from airlied to disable quirks when radeon is being used with KMS.


quassel-0.3.0.3-1.fc10
----------------------
* Wed Nov 12 17:00:00 2008 Steven M. Parrish <smparrish at shallowcreek.net> 0.3.0.3-1
- New upstream release fixes a security issue with CTCP handling in 
- Quassel Core, that could potentially be exploited to send 
- arbitrary IRC commands on your behalf.


smolt-1.1.1.1-9.fc10
--------------------
* Wed Nov 12 17:00:00 2008 Mike McGrath <mmcgrath at redhat.com> 1.1.1.1-9
- Fix for bug 470829

* Tue Nov 11 17:00:00 2008 Mike McGrath <mmcgrath at redhat.com> 1.1.1.1-8
- Added patch for fixed scanner

* Wed Oct  1 18:00:00 2008 Mike McGrath <mmcgrath at redhat.com> 1.1.1.1-7
- Fix for 439496


sugar-calculator-23-2.fc10
--------------------------
* Wed Nov 12 17:00:00 2008 Jeremy Katz <katzj at redhat.com> - 23-2
- install sharedstate bits (#468816)


yum-utils-1.1.18-2.fc10
-----------------------
* Wed Nov 12 17:00:00 2008 Seth Vidal <skvidal at fedoraproject.org>
- patch to fix traceback in yum-complete-transaction


Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 13














From atkac at redhat.com  Thu Nov 13 13:27:42 2008
From: atkac at redhat.com (Adam Tkac)
Date: Thu, 13 Nov 2008 14:27:42 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <1226429441.3593.77.camel@eagle.danny.cz>
References: <1226429441.3593.77.camel@eagle.danny.cz>
Message-ID: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>

On Tue, Nov 11, 2008 at 07:50:41PM +0100, Dan Hor?k wrote:
> There were many discussions in the past few days and weeks about the
> orientation Fedora currently has. It is a fact that currently
> Fedora is primarily desktop oriented.
> 
> We agree that Desktop is important part of the system, it is highly
> visible to the public and large number of Fedora users. But we also see
> a large number of Fedora and CentOS users and RHEL customers with very
> specific needs and demands. We can not omit the server fundamentals that
> later create a successful enterprise product and in our opinion a formal
> entity must exist to coordinate these efforts.
> 
> That's why we started work on establishing the Fedora Server SIG. The
> draft is available at https://fedoraproject.org/wiki/DanHorak/ServerSIG
> Any constructive ideas are welcome  :-)
> 

We discussed LSB and plymouth so let's start discussion about NetworkManager.
That tool is used by anaconda in F10 and is installed by default. In one
case it is nice tool for desktop but it still can't satisfy server demands
and is generally unusable and annoying.

Crucial thing is static IPs which NM can't handle. Thus I think it
should not be part of core system. Many people says that servers will
be integrated with NM and after that they will dynamically react when
network interfaces go up or down. It will be nice feature but it is
simply to early to put NM to core system.

Btw could anyone explain me what is the reason why NM is installed by
default? (make sure I'm not talking about desktops)

Regards, Adam

-- 
Adam Tkac, Red Hat, Inc.



From limb at jcomserv.net  Thu Nov 13 13:33:03 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 13 Nov 2008 07:33:03 -0600 (CST)
Subject: starting Fedora Server SIG
In-Reply-To: <491B6B8B.5040201@gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<778179b00811120400s5fda1277y2130ceddeb9d0422@mail.gmail.com>
	<1226491831.3752.298.camel@beck.corsepiu.local>
	<491AE00F.5010703@gmail.com>
	<1226515548.31982.403.camel@atropine.boston.devel.redhat.com>
	<1226515988.5295.5.camel@luminos.localdomain>
	<71051a5a7ff9f9bc8da6c383a4ba235c.squirrel@mail.jcomserv.net>
	<491B2B27.1060703@gmail.com>
	<32227dfa84e9d3f2337a10682cd87685.squirrel@mail.jcomserv.net>
	<491B6B8B.5040201@gmail.com>
Message-ID: <d00e55646459538ac6359ab855f52989.squirrel@mail.jcomserv.net>


> Jon Ciesla wrote:
>>
>>>>>> Yes, they are.  On an install without any X components, 'yum install
>>>>>> gnome-terminal' will pull in X libs but not an X server.
>>>>>>
>>>>> In fact, if you install the gnome desktop group, but don't check the
>>>>> X
>>>>> group, you get gnome but not X server to run it on.
>>>> Perfect for ssh tunneling or a freenx server.
>>> Will you be missing any authentication or device ownership magic if you
>>> use freenx exclusively instead of the console?
>>
>> I would expect to add those bits manually if authconfig didn't provide
>> them.  Kickstart FTW!
>
> I thought these days certain things were changed dynamically depending
> on who logged into the console.

Such as?  Not sure I follow you.

> --
>    Les Mikesell
>     lesmikesell at gmail.com
>


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

-d. bowie



From dennisml at conversis.de  Thu Nov 13 13:39:23 2008
From: dennisml at conversis.de (Dennis J.)
Date: Thu, 13 Nov 2008 14:39:23 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <20081113095455.GB25904@mokona.greysector.net>
References: <20081112131806.GA1461854@hiwaay.net>	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>	<491AED13.8050204@comcast.net>	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>	<491AF259.40907@comcast.net>
	<20081112191551.GC1461854@hiwaay.net>	<1226517797.5295.13.camel@luminos.localdomain>	<20081112200750.GF1461854@hiwaay.net>	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
	<20081113095455.GB25904@mokona.greysector.net>
Message-ID: <491C2E0B.1060305@conversis.de>

On 11/13/2008 10:54 AM, Dominik 'Rathann' Mierzejewski wrote:
> On Thursday, 13 November 2008 at 10:00, Enrico Scholz wrote:
>> Chris Adams<cmadams at hiwaay.net>  writes:
>>
>>> If I explicitly add "plymouth-text-and-details-only" to my install,
>>> it satisfies the system-plymouth-plugin dependency, and I don't get
>>> libX11 and such.
>>>
>>> Maybe plymouth-text-and-details-only should be in @core and
>>> plymouth-plugin-solar in @base?
>> Maybe 'yum' should be fixed to handle ambiguous situations better?
>> E.g. fail, warn and/or prompt when multiple packages satisfy a (virtual)
>> dependency?
>
> +1 for prompting, i.e.
>
> 2 packages found satisfying "system-plymouth-plugin" dependency:
> 1: plymouth-graphics-solar
> 2: plymouth-text-and-details-only
> Enter number to select [1]:
>
> Of course, the usual select-the-one-with-the-shortest-name behaviour would
> occur when using -y.

I think a better way would be to choose a plugin based on the Spin i.e. the 
desktop spin should prefer plymouth-graphics-solar and the server spin 
should prefer plymouth-text-and-details-only. I'm not sure if something 
like this is possible right now though. A second alternative would be to 
simply remove the graphical plugins from the server spin after all they 
merely fancy up the boot process but don't add any fundamental functionality.

Regards,
   Dennis



From cra at WPI.EDU  Thu Nov 13 13:49:47 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 13 Nov 2008 08:49:47 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
Message-ID: <20081113134947.GF24297@angus.ind.WPI.EDU>

On Thu, Nov 13, 2008 at 02:27:42PM +0100, Adam Tkac wrote:
> Crucial thing is static IPs which NM can't handle.

False.



From atkac at redhat.com  Thu Nov 13 14:00:19 2008
From: atkac at redhat.com (Adam Tkac)
Date: Thu, 13 Nov 2008 15:00:19 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <20081113134947.GF24297@angus.ind.WPI.EDU>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
Message-ID: <20081113140019.GA3952@traged.atkac.englab.brq.redhat.com>

On Thu, Nov 13, 2008 at 08:49:47AM -0500, Chuck Anderson wrote:
> On Thu, Nov 13, 2008 at 02:27:42PM +0100, Adam Tkac wrote:
> > Crucial thing is static IPs which NM can't handle.
> 
> False.
> 

Interesting, could you please point me how can I assign static IP to
interface handled by NM?

Thanks, Adam

-- 
Adam Tkac, Red Hat, Inc.



From cmadams at hiwaay.net  Thu Nov 13 14:01:53 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 13 Nov 2008 08:01:53 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <20081113134947.GF24297@angus.ind.WPI.EDU>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
Message-ID: <20081113140153.GA1538120@hiwaay.net>

Once upon a time, Chuck Anderson <cra at WPI.EDU> said:
> On Thu, Nov 13, 2008 at 02:27:42PM +0100, Adam Tkac wrote:
> > Crucial thing is static IPs which NM can't handle.
> 
> False.

Whether it can handle them (what about aliases, ranges, etc.) or not;
why would I want a daemon running to handle a static config?

There seems to be a proliferation of "standard" daemons these days, with
no good documentation of how they fit together, when they are really
required, etc.  Can I disable haldaemon on my servers?  What about dbus?
Now you want to add NM?

-- 
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 schaiba at gmail.com  Thu Nov 13 14:07:58 2008
From: schaiba at gmail.com (Aioanei Rares)
Date: Thu, 13 Nov 2008 16:07:58 +0200
Subject: starting Fedora Server SIG
In-Reply-To: <20081113140153.GA1538120@hiwaay.net>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
Message-ID: <778179b00811130607n4d1b90e2v8c46f9b06e4752bf@mail.gmail.com>

On Thu, Nov 13, 2008 at 4:01 PM, Chris Adams <cmadams at hiwaay.net> wrote:

> Once upon a time, Chuck Anderson <cra at WPI.EDU> said:
> > On Thu, Nov 13, 2008 at 02:27:42PM +0100, Adam Tkac wrote:
> > > Crucial thing is static IPs which NM can't handle.
> >
> > False.
>
> Whether it can handle them (what about aliases, ranges, etc.) or not;
> why would I want a daemon running to handle a static config?
>
> There seems to be a proliferation of "standard" daemons these days, with
> no good documentation of how they fit together, when they are really
> required, etc.  Can I disable haldaemon on my servers?  What about dbus?
> Now you want to add NM?
>
> --
> 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.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


I really agree.
-- 
Aioanei Rares
schaiba at fedoraproject.org
"China is a big country, inhabited by many Chinese." --Charles de Gaulle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081113/d448159e/attachment.htm>

From lesmikesell at gmail.com  Thu Nov 13 14:09:36 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 13 Nov 2008 08:09:36 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <d00e55646459538ac6359ab855f52989.squirrel@mail.jcomserv.net>
References: <1226429441.3593.77.camel@eagle.danny.cz>	<200811111317.15198.dennis@ausil.us>
	<4919DC9C.1030009@gmail.com>	<1226480816.3638.19.camel@eagle.danny.cz>	<1226485422.3638.22.camel@eagle.danny.cz>	<20081112111712.GB3142@free.fr>	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>	<778179b00811120400s5fda1277y2130ceddeb9d0422@mail.gmail.com>	<1226491831.3752.298.camel@beck.corsepiu.local>	<491AE00F.5010703@gmail.com>	<1226515548.31982.403.camel@atropine.boston.devel.redhat.com>	<1226515988.5295.5.camel@luminos.localdomain>	<71051a5a7ff9f9bc8da6c383a4ba235c.squirrel@mail.jcomserv.net>	<491B2B27.1060703@gmail.com>	<32227dfa84e9d3f2337a10682cd87685.squirrel@mail.jcomserv.net>	<491B6B8B.5040201@gmail.com>
	<d00e55646459538ac6359ab855f52989.squirrel@mail.jcomserv.net>
Message-ID: <491C3520.2030504@gmail.com>

Jon Ciesla wrote:
>> Jon Ciesla wrote:
>>>>>>> Yes, they are.  On an install without any X components, 'yum install
>>>>>>> gnome-terminal' will pull in X libs but not an X server.
>>>>>>>
>>>>>> In fact, if you install the gnome desktop group, but don't check the
>>>>>> X
>>>>>> group, you get gnome but not X server to run it on.
>>>>> Perfect for ssh tunneling or a freenx server.
>>>> Will you be missing any authentication or device ownership magic if you
>>>> use freenx exclusively instead of the console?
>>> I would expect to add those bits manually if authconfig didn't provide
>>> them.  Kickstart FTW!
>> I thought these days certain things were changed dynamically depending
>> on who logged into the console.
> 
> Such as?  Not sure I follow you.

I thought the audio device and perhaps some other things are now 
magically owned by the user logged in at the console.  If everyone logs 
in with freenx, they may want their audio diverted to their display 
connection or not.  How do you manage the server audio for the case 
where it is actually an audio server not really tied to any user 
session, or a freenx desktop user happens to be nearby and wants his 
session-related audio to go to the server-connected speakers?

Note also that desktop and server activities aren't clearly defined and 
are not mutually exclusive.  What should happen to a server-type audio 
manager (say a web-controlled music player) when a GUI session does log 
in at the console or someone does fast user switching there?


-- 
   Les Mikesell
    lesmikesell at gmail.com



From cra at WPI.EDU  Thu Nov 13 14:11:07 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 13 Nov 2008 09:11:07 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <20081113140019.GA3952@traged.atkac.englab.brq.redhat.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140019.GA3952@traged.atkac.englab.brq.redhat.com>
Message-ID: <20081113141107.GG24297@angus.ind.WPI.EDU>

On Thu, Nov 13, 2008 at 03:00:19PM +0100, Adam Tkac wrote:
> On Thu, Nov 13, 2008 at 08:49:47AM -0500, Chuck Anderson wrote:
> > On Thu, Nov 13, 2008 at 02:27:42PM +0100, Adam Tkac wrote:
> > > Crucial thing is static IPs which NM can't handle.
> > 
> > False.
> > 
> 
> Interesting, could you please point me how can I assign static IP to
> interface handled by NM?

Well, for system-wide connections which you would presumably want for 
a server, you edit /etc/sysconfig/network-scripts/ifcfg-* as usual and 
NM will bring the interface up at boot.

>From the desktop, you can Edit Connections and create a new static 
connection and select it instead of the System or Auto connection 
which is very handy when moving between networks that don't support 
DHCP.



From lesmikesell at gmail.com  Thu Nov 13 14:12:24 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 13 Nov 2008 08:12:24 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <20081113134947.GF24297@angus.ind.WPI.EDU>
References: <1226429441.3593.77.camel@eagle.danny.cz>	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
Message-ID: <491C35C8.5060207@gmail.com>

Chuck Anderson wrote:
> On Thu, Nov 13, 2008 at 02:27:42PM +0100, Adam Tkac wrote:
>> Crucial thing is static IPs which NM can't handle.
> 
> False.

If you bring up a mix of static and dynamically assigned interfaces, can 
you control which gets to assign the default route and DNS servers?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From cra at WPI.EDU  Thu Nov 13 14:20:41 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 13 Nov 2008 09:20:41 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <491C35C8.5060207@gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<491C35C8.5060207@gmail.com>
Message-ID: <20081113142041.GH24297@angus.ind.WPI.EDU>

On Thu, Nov 13, 2008 at 08:12:24AM -0600, Les Mikesell wrote:
> Chuck Anderson wrote:
>> On Thu, Nov 13, 2008 at 02:27:42PM +0100, Adam Tkac wrote:
>>> Crucial thing is static IPs which NM can't handle.
>>
>> False.
>
> If you bring up a mix of static and dynamically assigned interfaces, can  
> you control which gets to assign the default route and DNS servers?

The last time I looked at the code, NM had a hard-coded policy for how 
it assigns the default route and DNS servers.  If you only have one 
interface with a default route and the other interfaces don't have a 
default route, then the DNS and default route for that interface is 
set.  If you have more than one, I believe it picks based on the 
hard-coded policy, which I believe is wired first, then wireless, then 
dialup/mobile broadband.  In the face of multiple wired connections, 
I'm not sure what the policy is.

Yes, NM needs to grow the ability to specify policy outside of the 
code.

It also needs IPv6 support (coming soon I hear), alias support, 
bridging support, bonding support, VLANs, etc. if it is to replace the 
"network" service on servers.



From walters at verbum.org  Thu Nov 13 14:23:50 2008
From: walters at verbum.org (Colin Walters)
Date: Thu, 13 Nov 2008 09:23:50 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.1.10.0811130059100.23693@newtla.xelerance.com>
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226518090.3638.37.camel@eagle.danny.cz>
	<20081112192954.GC12723@nostromo.devel.redhat.com>
	<87iqqsiubm.fsf@sheridan.bigo.ensc.de>
	<1226520557.5295.20.camel@luminos.localdomain>
	<491B6440.6050609@gmail.com>
	<1226532175.5295.36.camel@luminos.localdomain>
	<alpine.LFD.1.10.0811130059100.23693@newtla.xelerance.com>
Message-ID: <faa16b610811130623rdde59dg7d73e535ce80d17e@mail.gmail.com>

On Thu, Nov 13, 2008 at 12:59 AM, Paul Wouters <paul at xelerance.com> wrote:
>
>> A normal reboot is needed at least as often as you push new kernels (we
>
> kexec?

(I have no dog in this thread, but:)

kexec is just a faster reboot, not a way to avoid reboots as is often
people's mistaken impression.

Now, ksplice does let you avoid reboots but has tradeoffs.



From berrange at redhat.com  Thu Nov 13 14:24:15 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Thu, 13 Nov 2008 14:24:15 +0000
Subject: starting Fedora Server SIG
In-Reply-To: <20081113142041.GH24297@angus.ind.WPI.EDU>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<491C35C8.5060207@gmail.com>
	<20081113142041.GH24297@angus.ind.WPI.EDU>
Message-ID: <20081113142415.GI8200@redhat.com>

On Thu, Nov 13, 2008 at 09:20:41AM -0500, Chuck Anderson wrote:
> On Thu, Nov 13, 2008 at 08:12:24AM -0600, Les Mikesell wrote:
> > Chuck Anderson wrote:
> >> On Thu, Nov 13, 2008 at 02:27:42PM +0100, Adam Tkac wrote:
> >>> Crucial thing is static IPs which NM can't handle.
> >>
> >> False.
> >
> > If you bring up a mix of static and dynamically assigned interfaces, can  
> > you control which gets to assign the default route and DNS servers?
> 
> The last time I looked at the code, NM had a hard-coded policy for how 
> it assigns the default route and DNS servers.  If you only have one 
> interface with a default route and the other interfaces don't have a 
> default route, then the DNS and default route for that interface is 
> set.  If you have more than one, I believe it picks based on the 
> hard-coded policy, which I believe is wired first, then wireless, then 
> dialup/mobile broadband.  In the face of multiple wired connections, 
> I'm not sure what the policy is.
> 
> Yes, NM needs to grow the ability to specify policy outside of the 
> code.
> 
> It also needs IPv6 support (coming soon I hear)

Unless it has been broken again, IPv6 'just works' in NM if you are using
IPv6 auto-configuration. NM ensures every interface has a link local
address for IPv6, so the moment any interface is up and on a network
with IPv6 enabled it'll automatically get suitable addressing. 

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 cra at WPI.EDU  Thu Nov 13 14:28:17 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 13 Nov 2008 09:28:17 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <20081113142415.GI8200@redhat.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<491C35C8.5060207@gmail.com>
	<20081113142041.GH24297@angus.ind.WPI.EDU>
	<20081113142415.GI8200@redhat.com>
Message-ID: <20081113142817.GI24297@angus.ind.WPI.EDU>

On Thu, Nov 13, 2008 at 02:24:15PM +0000, Daniel P. Berrange wrote:
> > It also needs IPv6 support (coming soon I hear)
> 
> Unless it has been broken again, IPv6 'just works' in NM if you are using
> IPv6 auto-configuration. NM ensures every interface has a link local
> address for IPv6, so the moment any interface is up and on a network
> with IPv6 enabled it'll automatically get suitable addressing. 

Agreed.  I'm doing that myself.  However, I believe it is 
"ship-in-the-night", i.e. NM knows nothing of the IPv6 auto-configured 
and link-local addresses.  And then there's DHCPv6 and static 
addressing support which is needed.



From skvidal at fedoraproject.org  Thu Nov 13 14:56:04 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 13 Nov 2008 09:56:04 -0500 (EST)
Subject: starting Fedora Server SIG
In-Reply-To: <87ej1ghufu.fsf@sheridan.bigo.ensc.de>
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr>
	<20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
Message-ID: <alpine.LFD.2.00.0811130954360.19678@localhost.localdomain>



On Thu, 13 Nov 2008, Enrico Scholz wrote:

> Chris Adams <cmadams at hiwaay.net> writes:
>
>> If I explicitly add "plymouth-text-and-details-only" to my install,
>> it satisfies the system-plymouth-plugin dependency, and I don't get
>> libX11 and such.
>>
>> Maybe plymouth-text-and-details-only should be in @core and
>> plymouth-plugin-solar in @base?
>
> Maybe 'yum' should be fixed to handle ambiguous situations better?
> E.g. fail, warn and/or prompt when multiple packages satisfy a (virtual)
> dependency?
>

why did you put yum in quotes?

with regard to your suggestion:

If we don't have a good default course of action, why do you think the 
user is going to know better?

If we do have a good default course of action, why are we prompting the 
user?

-sv



From skvidal at fedoraproject.org  Thu Nov 13 14:57:31 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 13 Nov 2008 09:57:31 -0500 (EST)
Subject: starting Fedora Server SIG
In-Reply-To: <20081113095455.GB25904@mokona.greysector.net>
References: <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
	<20081113095455.GB25904@mokona.greysector.net>
Message-ID: <alpine.LFD.2.00.0811130956190.19678@localhost.localdomain>



On Thu, 13 Nov 2008, Dominik 'Rathann' Mierzejewski wrote:

> On Thursday, 13 November 2008 at 10:00, Enrico Scholz wrote:
>> Chris Adams <cmadams at hiwaay.net> writes:
>>
>>> If I explicitly add "plymouth-text-and-details-only" to my install,
>>> it satisfies the system-plymouth-plugin dependency, and I don't get
>>> libX11 and such.
>>>
>>> Maybe plymouth-text-and-details-only should be in @core and
>>> plymouth-plugin-solar in @base?
>>
>> Maybe 'yum' should be fixed to handle ambiguous situations better?
>> E.g. fail, warn and/or prompt when multiple packages satisfy a (virtual)
>> dependency?
>
> +1 for prompting, i.e.
>
> 2 packages found satisfying "system-plymouth-plugin" dependency:
> 1: plymouth-graphics-solar
> 2: plymouth-text-and-details-only
> Enter number to select [1]:
>
> Of course, the usual select-the-one-with-the-shortest-name behaviour would
> occur when using -y.

shortest-name has not been the sole distinguishing characteristic between 
two providing pkgs for a while now. We determine the best provider by 
scoring the providers based on a series of tests. The one with the best 
score wins.


-sv



From dcbw at redhat.com  Thu Nov 13 15:02:52 2008
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 13 Nov 2008 10:02:52 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <20081113140153.GA1538120@hiwaay.net>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
Message-ID: <1226588572.4714.4.camel@localhost.localdomain>

On Thu, 2008-11-13 at 08:01 -0600, Chris Adams wrote:
> Once upon a time, Chuck Anderson <cra at WPI.EDU> said:
> > On Thu, Nov 13, 2008 at 02:27:42PM +0100, Adam Tkac wrote:
> > > Crucial thing is static IPs which NM can't handle.
> > 
> > False.
> 
> Whether it can handle them (what about aliases, ranges, etc.) or not;
> why would I want a daemon running to handle a static config?

Aliases yes, by adding multiple IP addresses to the same interface,
which is also exactly what you can do with /sbin/ip.  ethX:X is
generally deprecated AFAICT simply because it's ugly, and because it's
an artifact of ifconfig/ioctl not being able to handle multiple
addresses natively.  You should be able to add more than one address in
the ifcfg file, or you can use the connection editor to add as many
addresses as you like from the GUI.

Ranges will have to be added, but wouldn't be horribly hard to do.  I
know that functionality is present in the ifcfg files.

> There seems to be a proliferation of "standard" daemons these days, with
> no good documentation of how they fit together, when they are really
> required, etc.  Can I disable haldaemon on my servers?  What about dbus?
> Now you want to add NM?

You can certainly disable NetworkManager and use manual configuration of
your network devices.

Dan




From dcbw at redhat.com  Thu Nov 13 15:07:35 2008
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 13 Nov 2008 10:07:35 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <20081113142041.GH24297@angus.ind.WPI.EDU>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU> <491C35C8.5060207@gmail.com>
	<20081113142041.GH24297@angus.ind.WPI.EDU>
Message-ID: <1226588855.4714.10.camel@localhost.localdomain>

On Thu, 2008-11-13 at 09:20 -0500, Chuck Anderson wrote:
> On Thu, Nov 13, 2008 at 08:12:24AM -0600, Les Mikesell wrote:
> > Chuck Anderson wrote:
> >> On Thu, Nov 13, 2008 at 02:27:42PM +0100, Adam Tkac wrote:
> >>> Crucial thing is static IPs which NM can't handle.
> >>
> >> False.
> >
> > If you bring up a mix of static and dynamically assigned interfaces, can  
> > you control which gets to assign the default route and DNS servers?
> 
> The last time I looked at the code, NM had a hard-coded policy for how 
> it assigns the default route and DNS servers.  If you only have one 
> interface with a default route and the other interfaces don't have a 
> default route, then the DNS and default route for that interface is 
> set.  If you have more than one, I believe it picks based on the 
> hard-coded policy, which I believe is wired first, then wireless, then 
> dialup/mobile broadband.  In the face of multiple wired connections, 
> I'm not sure what the policy is.
> 
> Yes, NM needs to grow the ability to specify policy outside of the 
> code.

The current policy is this.  If the device gets a gateway from anything
(either DHCP or the GUI or the ifcfg files) then it becomes a candidate
for the default route.  If you don't enter a gateway for any of that
device's IP addresses in the GUI, it shouldn't ever get the default
route.

Yes, there's room for improvement.  If you check "Ignore automatically
provided routes" and you're using DHCP, NM should probably ignore the
gateway for that device when deciding which device gets the default
route.

> It also needs IPv6 support (coming soon I hear), alias support, 

IPv6: target for next version
Alias: you can already add multiple IPs to an interface
bridging: planned
bonding: planned
VLANs: good to have, needs more investigation

Dan




From dcbw at redhat.com  Thu Nov 13 15:08:29 2008
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 13 Nov 2008 10:08:29 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <20081113142817.GI24297@angus.ind.WPI.EDU>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU> <491C35C8.5060207@gmail.com>
	<20081113142041.GH24297@angus.ind.WPI.EDU>
	<20081113142415.GI8200@redhat.com>
	<20081113142817.GI24297@angus.ind.WPI.EDU>
Message-ID: <1226588909.4714.12.camel@localhost.localdomain>

On Thu, 2008-11-13 at 09:28 -0500, Chuck Anderson wrote:
> On Thu, Nov 13, 2008 at 02:24:15PM +0000, Daniel P. Berrange wrote:
> > > It also needs IPv6 support (coming soon I hear)
> > 
> > Unless it has been broken again, IPv6 'just works' in NM if you are using
> > IPv6 auto-configuration. NM ensures every interface has a link local
> > address for IPv6, so the moment any interface is up and on a network
> > with IPv6 enabled it'll automatically get suitable addressing. 
> 
> Agreed.  I'm doing that myself.  However, I believe it is 
> "ship-in-the-night", i.e. NM knows nothing of the IPv6 auto-configured 
> and link-local addresses.  And then there's DHCPv6 and static 
> addressing support which is needed.

Yes, Dave Cantrell and I have already worked on that but the support
wasn't finished for 0.7/F10.  It's targeted for the next version of NM
and _must_ be present by F11.

Dan



From vonbrand at inf.utfsm.cl  Thu Nov 13 13:01:42 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Thu, 13 Nov 2008 10:01:42 -0300
Subject: Proposal: Rolling Release
In-Reply-To: <491B4E37.30706@gmail.com>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<20081111204717.GB15724@orient.maison.lan>
	<4919F7C5.1090705@gmail.com>
	<1226439740.10458.15.camel@luminos.localdomain>
	<491A6E59.3070803@leemhuis.info> <491B0873.50503@gmail.com>
	<604aa7910811120851u361eac4sc4c05c2baf57fda4@mail.gmail.com>
	<491B145E.3020900@gmail.com>
	<604aa7910811120944r81e6b8bsc23ef3ef60d2bd69@mail.gmail.com>
	<491B19B6.40509@gmail.com>
	<604aa7910811121233l40705289q9478607a66762549@mail.gmail.com>
	<491B4E37.30706@gmail.com>
Message-ID: <200811131301.mADD1gJm004624@laptop14.inf.utfsm.cl>

Les Mikesell <lesmikesell at gmail.com> wrote:
> Jeff Spaleta wrote:

[...]

> > Are you suggesting that we should never provide an unstable interface
> > in any of the libraries or scripting modules that we package?

> No, I'm saying that necessary changes should be planned, and to the
> extent possible, batched at version releases.

That means even more of the bureaucracy that people are so quick to
disparage here...

>                                                And where that isn't
> possible, interface and command line changes to expect should be
> published before the update so users and 3rd parties know how to work
> around the breakage.

That isn't always obvious to the packager of some piece of infrastructure.
Change GCC, the "normal" applications continue compiling fine (or get fixed
as part of the update in the distributin), but some strange package
somewhere was relying on a GCC bug (or misfeature, or sloppiness) and blows
up when you try to build it. Has happened dozens of times to me, and I'm
still grateful GCC moves forward and becomes more standards-conforming.

> > And
> > that we only provide technologies that upstream has committed to API
> > stability between subsequent releases?

> I'd like that very much but given what you have to work with, I'll
> agree it is impossible.  However, like any other QA aspect, I'm
> suggesting that you do the best you can not to break local

That is done, albeit imperfectly. It usually gets caught and fixed quickly.

>                                                            or 3rd
> party programs built on the platform you just shipped.

That is impossible, and besides the point anyway: Part of the benefit of
being part of the distribution is the previous point.

[...]

> > At best you could maybe hope for a subset of available technologies to
> > be identified as upstream interface stable, and get a subset of
> > maintainers to pledge to keep interfaces stable inside a release
> > timeframe in conjunction with those upstream projects.

> Who forces you to push interface-changing updates out of rawhide?

New upstream versions... go talk to them ;-)

>                                                                   If
> I wanted today's bugs from an upstream project I'd grab it from there
> instead of using a distribution's release version of the code.   The
> fedora major release cycle is already fast enough anyway.

It is fast /because/ it integrates upstream changes as early as
possible. Can't have fast advances and no change at the same time.

>                                                            If some
> upstream project can't settle on an interface you are doing your users
> a favor by keeping it away from them.

OK. Leave out the kernel, ...

> > There is no
> > coherent initiative towards what could be generously termed a 'Fedora
> > SDK'. I've seen no interest from a group of active
> > maintainers..ever..to take on that problem space and commit to seeing
> > it happen.  Something like this would require a community member to
> > step forward and be a strong, active, persuasive leader on the effort.

> I'm not sure what that even means.  If fedora has something unique, I
> don't particularly want it

Choose something else and leave us in peace then.

>                            and don't understand why anyone would
> develop for something intentionally non-standard.

Some people do so even if you don't understand them. That would mean your
understanding of what and why people do as they do is flawed, not
(necessarily) said developers.

[A standard is developed by consensus among people trying various
 non-standard approaches on what the best way to do something is. This
 means exploring non-standard approaches (even ones going against said
 standards at times).]

>                                                    What I'd really
> want is for LSB-compliance to someday get to the point where programs
> running on Fedora would never need to know that it is fedora at all,
> much less the version and last-update-date underneath.

LSB and similar standards mean aiming at the lowest common denominator.
I.e., it might work just fine, but it will certainly waste much of what
Fedora (or any other particular distribution) is all about

> > I very much doubt that you are the right person to lead such an
> > effort, even if you did decide this is the issue that would finally
> > get you off the fence and working on something constructively.  So my
> > advice to you is, dial back the rhetoric and see if you can get other
> > people talking about this and identify the person you think can lead
> > this initiative.

> Is there someone involved in development that eats his own dog food
> (i.e. uses fedora with current updates as infrastructure for some
> large project or even in a lab setting with many users)?

I'm using Fedora rawhide daily. Our labs (several hundred users) are
running latest Fedora most of the time (except when the releases fall at
awkward times in our terms).
-- 
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 galibert at pobox.com  Thu Nov 13 15:28:38 2008
From: galibert at pobox.com (Olivier Galibert)
Date: Thu, 13 Nov 2008 16:28:38 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <1226588855.4714.10.camel@localhost.localdomain>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<491C35C8.5060207@gmail.com>
	<20081113142041.GH24297@angus.ind.WPI.EDU>
	<1226588855.4714.10.camel@localhost.localdomain>
Message-ID: <20081113152838.GA48391@dspnet.fr.eu.org>

On Thu, Nov 13, 2008 at 10:07:35AM -0500, Dan Williams wrote:
> IPv6: target for next version
> Alias: you can already add multiple IPs to an interface
> bridging: planned
> bonding: planned
> VLANs: good to have, needs more investigation

Static routes ?

  OG.



From loganjerry at gmail.com  Thu Nov 13 15:33:48 2008
From: loganjerry at gmail.com (Jerry James)
Date: Thu, 13 Nov 2008 08:33:48 -0700
Subject: starting Fedora Server SIG
In-Reply-To: <20081113141107.GG24297@angus.ind.WPI.EDU>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140019.GA3952@traged.atkac.englab.brq.redhat.com>
	<20081113141107.GG24297@angus.ind.WPI.EDU>
Message-ID: <870180fe0811130733i43070df5q14d861f813db87d@mail.gmail.com>

On Thu, Nov 13, 2008 at 7:11 AM, Chuck Anderson <cra at wpi.edu> wrote:
> Well, for system-wide connections which you would presumably want for
> a server, you edit /etc/sysconfig/network-scripts/ifcfg-* as usual and
> NM will bring the interface up at boot.
>
> >From the desktop, you can Edit Connections and create a new static
> connection and select it instead of the System or Auto connection
> which is very handy when moving between networks that don't support
> DHCP.

Then could you tell me, please, how to fix an issue I've got with a
server running F-9 that has a static IP address?  I've edited
/etc/sysconfig/network-scripts/ifcfg-eth0.  It contains (among other
settings):

DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
NM_CONTROLLED=no
IPADDR=xx.xx.xx.xx

Everything works fine *except* that ONBOOT=yes is not honored.  On
boot, eth0 is not up.  I have to go login to the machine's console and
"ifup eth0" before I get a network connection.  After that it behaves
perfectly.  This wasn't so much of a problem when the machine in
question was 50 feet from my desk, but it is currently 45 miles from
my desk and that IS a problem.  Thanks,
-- 
Jerry James
http://loganjerry.googlepages.com/



From alsadi at gmail.com  Thu Nov 13 15:38:08 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Thu, 13 Nov 2008 17:38:08 +0200
Subject: a trivial fix makes a big change
In-Reply-To: <491B70A4.6090102@fedoraproject.org>
References: <385866f0811121507y228eb82egb77544b3edccae3f@mail.gmail.com>
	<491B70A4.6090102@fedoraproject.org>
Message-ID: <385866f0811130738s67a1be18r858313887b4e02d8@mail.gmail.com>

> You can volunteer to maintain it.
I proposed to for a packager in FAS but I'm still waiting for the acceptance

> The RPM philosophy is that installation and configuration should be separate activities.  There
good policy
yes but the rpm already ships with a config file

rpm -qf /etc/samba/smb.conf
samba-common-3.2.4-0.22.fc10.i386

so I ask for that file in that package to be modified to have a line like this

usershare path = /var/lib/samba/usershare

BTW: I forget that we have system-config-samba

we can put a checkbox [ ]  enable nautilus-share



From galibert at pobox.com  Thu Nov 13 15:37:09 2008
From: galibert at pobox.com (Olivier Galibert)
Date: Thu, 13 Nov 2008 16:37:09 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <870180fe0811130733i43070df5q14d861f813db87d@mail.gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140019.GA3952@traged.atkac.englab.brq.redhat.com>
	<20081113141107.GG24297@angus.ind.WPI.EDU>
	<870180fe0811130733i43070df5q14d861f813db87d@mail.gmail.com>
Message-ID: <20081113153709.GC48391@dspnet.fr.eu.org>

On Thu, Nov 13, 2008 at 08:33:48AM -0700, Jerry James wrote:
> Then could you tell me, please, how to fix an issue I've got with a
> server running F-9 that has a static IP address?  I've edited
> /etc/sysconfig/network-scripts/ifcfg-eth0.  It contains (among other
> settings):
> 
> DEVICE=eth0
> BOOTPROTO=none
> ONBOOT=yes
> NM_CONTROLLED=no
> IPADDR=xx.xx.xx.xx
> 
> Everything works fine *except* that ONBOOT=yes is not honored.  On
> boot, eth0 is not up.  I have to go login to the machine's console and
> "ifup eth0" before I get a network connection.  After that it behaves
> perfectly.  This wasn't so much of a problem when the machine in
> question was 50 feet from my desk, but it is currently 45 miles from
> my desk and that IS a problem.  Thanks,

Try a "chkconfig --list network".  It should be on for levels 2-5.  If
it isn't, you haven't enabled the old-style networking, explaining
your problem.

  OG.



From cra at WPI.EDU  Thu Nov 13 15:49:35 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 13 Nov 2008 10:49:35 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <870180fe0811130733i43070df5q14d861f813db87d@mail.gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140019.GA3952@traged.atkac.englab.brq.redhat.com>
	<20081113141107.GG24297@angus.ind.WPI.EDU>
	<870180fe0811130733i43070df5q14d861f813db87d@mail.gmail.com>
Message-ID: <20081113154935.GJ23749@angus.ind.WPI.EDU>

On Thu, Nov 13, 2008 at 08:33:48AM -0700, Jerry James wrote:
> Then could you tell me, please, how to fix an issue I've got with a
> server running F-9 that has a static IP address?  I've edited
> /etc/sysconfig/network-scripts/ifcfg-eth0.  It contains (among other
> settings):
> 
> DEVICE=eth0
> BOOTPROTO=none
> ONBOOT=yes
> NM_CONTROLLED=no
> IPADDR=xx.xx.xx.xx
> 
> Everything works fine *except* that ONBOOT=yes is not honored.  On
> boot, eth0 is not up.  I have to go login to the machine's console and
> "ifup eth0" before I get a network connection.  After that it behaves
> perfectly.  This wasn't so much of a problem when the machine in
> question was 50 feet from my desk, but it is currently 45 miles from
> my desk and that IS a problem.  Thanks,

Are you using NetworkManager or network service?

chkconfig --list NetworkManager
chkconfig --list network

If NetworkManger is enabled and network is not, then you need to 
change ifcfg-eth0:

NM_CONTROLLED=yes



From james.antill at redhat.com  Thu Nov 13 15:52:52 2008
From: james.antill at redhat.com (James Antill)
Date: Thu, 13 Nov 2008 10:52:52 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <20081112200750.GF1461854@hiwaay.net>
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr> <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
Message-ID: <1226591572.22230.141.camel@code.and.org>

On Wed, 2008-11-12 at 14:07 -0600, Chris Adams wrote:

> Doing a "yum install kernel" from rawhide in an empty install root
> gives:

[...]

> It looks like the dep chain to the X libraries is:
> 
> cairo requires libX11.so.6
> plymouth-plugin-label requires libcairo.so.2

 This is probably a good time to repoint people to:

http://james.fedorapeople.org/yum/commands/pkg-deps-tree-view.py
http://skvidal.fedorapeople.org/misc/pkg-provs-tree-view.py

...which will take all the work/guessing out of this.

-- 
James Antill <james.antill at redhat.com>
Red Hat
-------------- next part --------------
A 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/20081113/6ecf5919/attachment.sig>

From cmadams at hiwaay.net  Thu Nov 13 16:02:03 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 13 Nov 2008 10:02:03 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1226588572.4714.4.camel@localhost.localdomain>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
Message-ID: <20081113160203.GD1538120@hiwaay.net>

Once upon a time, Dan Williams <dcbw at redhat.com> said:
> You can certainly disable NetworkManager and use manual configuration of
> your network devices.

For how long?  I thought I'd read that the plan was to use NM for
everything and eliminate /etc/init.d/network.
-- 
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 enrico.scholz at informatik.tu-chemnitz.de  Thu Nov 13 16:04:11 2008
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Thu, 13 Nov 2008 17:04:11 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811130954360.19678@localhost.localdomain> (Seth
	Vidal's message of "Thu, 13 Nov 2008 09:56:04 -0500 (EST)")
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr> <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
	<alpine.LFD.2.00.0811130954360.19678@localhost.localdomain>
Message-ID: <87ej1fhatg.fsf@fc5.bigo.ensc.de>

Seth Vidal <skvidal at fedoraproject.org> writes:

>> Maybe 'yum' should be fixed to handle ambiguous situations better?
>> E.g. fail, warn and/or prompt when multiple packages satisfy a (virtual)
>> dependency?
>>
>
> why did you put yum in quotes?

I put product names usually into quotes.


> If we don't have a good default course of action, why do you think the
> user is going to know better?

Why do you think, that 'yum' knows which choice is the best one? E.g. the
'plymouth' case shows that the wrong decision was taken and that the user
would have made the right one.


> If we do have a good default course of action, why are we prompting
> the user?

How do you define/configure a "good default course"? Prompting is
probably easier to implement than such a logic.


Enrico



From dan at danny.cz  Thu Nov 13 16:13:22 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Thu, 13 Nov 2008 17:13:22 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <20081113160203.GD1538120@hiwaay.net>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
Message-ID: <1226592802.3651.30.camel@eagle.danny.cz>


Chris Adams p??e v ?t 13. 11. 2008 v 10:02 -0600:
> Once upon a time, Dan Williams <dcbw at redhat.com> said:
> > You can certainly disable NetworkManager and use manual configuration of
> > your network devices.
> 
> For how long?  I thought I'd read that the plan was to use NM for
> everything and eliminate /etc/init.d/network.

We will keep/maintain /etc/init.d/network forever :-) They don't
conflict, so there is no reason to completely drop the old method.


		Dan




From loganjerry at gmail.com  Thu Nov 13 16:15:33 2008
From: loganjerry at gmail.com (Jerry James)
Date: Thu, 13 Nov 2008 09:15:33 -0700
Subject: starting Fedora Server SIG
In-Reply-To: <20081113153709.GC48391@dspnet.fr.eu.org>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140019.GA3952@traged.atkac.englab.brq.redhat.com>
	<20081113141107.GG24297@angus.ind.WPI.EDU>
	<870180fe0811130733i43070df5q14d861f813db87d@mail.gmail.com>
	<20081113153709.GC48391@dspnet.fr.eu.org>
Message-ID: <870180fe0811130815l7091190fob13cf45e409c35a6@mail.gmail.com>

On Thu, Nov 13, 2008 at 8:37 AM, Olivier Galibert <galibert at pobox.com> wrote:
> Try a "chkconfig --list network".  It should be on for levels 2-5.  If
> it isn't, you haven't enabled the old-style networking, explaining
> your problem.

/me smacks self in forehead

That was it.  Thanks!
-- 
Jerry James
http://loganjerry.googlepages.com/



From loganjerry at gmail.com  Thu Nov 13 16:19:27 2008
From: loganjerry at gmail.com (Jerry James)
Date: Thu, 13 Nov 2008 09:19:27 -0700
Subject: starting Fedora Server SIG
In-Reply-To: <20081113154935.GJ23749@angus.ind.WPI.EDU>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140019.GA3952@traged.atkac.englab.brq.redhat.com>
	<20081113141107.GG24297@angus.ind.WPI.EDU>
	<870180fe0811130733i43070df5q14d861f813db87d@mail.gmail.com>
	<20081113154935.GJ23749@angus.ind.WPI.EDU>
Message-ID: <870180fe0811130819geefff8ufbeae1b6cd95c01d@mail.gmail.com>

On Thu, Nov 13, 2008 at 8:49 AM, Chuck Anderson <cra at wpi.edu> wrote:
> Are you using NetworkManager or network service?
>
> chkconfig --list NetworkManager
> chkconfig --list network

Yes, that was the problem.  D'oh!

> If NetworkManger is enabled and network is not, then you need to
> change ifcfg-eth0:
>
> NM_CONTROLLED=yes

I don't remember now why I turned NetworkManager off in the first
place; that was just a couple of weeks after F-9 was released.  I
think I remember it querying DHCP instead of using the supplied IP
address.  Unfortunately, the DHCP server doesn't know about this
machine, and the network admins don't want to fix that since it is a
test machine.

In any case, turning on the network service fixed the problem.  Thanks!
-- 
Jerry James
http://loganjerry.googlepages.com/



From tmraz at redhat.com  Thu Nov 13 16:20:00 2008
From: tmraz at redhat.com (Tomas Mraz)
Date: Thu, 13 Nov 2008 17:20:00 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <20081112171037.GD6260@nostromo.devel.redhat.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us> <4919DC9C.1030009@gmail.com>
	<1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<5256d0b0811120353y4b3d076bra38ffcbf71a021b5@mail.gmail.com>
	<20081112171037.GD6260@nostromo.devel.redhat.com>
Message-ID: <1226593200.4383.5.camel@zaphne.frost.loc>

On Wed, 2008-11-12 at 12:10 -0500, Bill Nottingham wrote:
> Peter Robinson (pbrobinson at gmail.com) said: 
> > For some reason redhat-lsb pulls in qt, qt-X11 and qt3. redhat-lsb is
> > certainly something you'd probably want in a server environment but no
> > idea why it would need qt. Its also a 'default' in base. I'm also not
> > quite sure why old not often used tools like ypbind, rsh, rdate, rdate
> > are set as default either. Anyone that would need to use those style
> > systems would also know how to install them.
> 
> I wonder if authconfig could be taught to install packages; at
> the moment, it expects the components it configures to be installed,
> and simply disables the configuration bits for those components that
> aren't.

Patches welcome. I suppose they would be for the GUI only? As I don't
want the command line utility depend on PK.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From dcbw at redhat.com  Thu Nov 13 16:21:56 2008
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 13 Nov 2008 11:21:56 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <870180fe0811130733i43070df5q14d861f813db87d@mail.gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140019.GA3952@traged.atkac.englab.brq.redhat.com>
	<20081113141107.GG24297@angus.ind.WPI.EDU>
	<870180fe0811130733i43070df5q14d861f813db87d@mail.gmail.com>
Message-ID: <1226593316.4714.25.camel@localhost.localdomain>

On Thu, 2008-11-13 at 08:33 -0700, Jerry James wrote:
> On Thu, Nov 13, 2008 at 7:11 AM, Chuck Anderson <cra at wpi.edu> wrote:
> > Well, for system-wide connections which you would presumably want for
> > a server, you edit /etc/sysconfig/network-scripts/ifcfg-* as usual and
> > NM will bring the interface up at boot.
> >
> > >From the desktop, you can Edit Connections and create a new static
> > connection and select it instead of the System or Auto connection
> > which is very handy when moving between networks that don't support
> > DHCP.
> 
> Then could you tell me, please, how to fix an issue I've got with a
> server running F-9 that has a static IP address?  I've edited
> /etc/sysconfig/network-scripts/ifcfg-eth0.  It contains (among other
> settings):
> 
> DEVICE=eth0
> BOOTPROTO=none
> ONBOOT=yes
> NM_CONTROLLED=no
> IPADDR=xx.xx.xx.xx
> 
> Everything works fine *except* that ONBOOT=yes is not honored.  On
> boot, eth0 is not up.  I have to go login to the machine's console and
> "ifup eth0" before I get a network connection.  After that it behaves
> perfectly.  This wasn't so much of a problem when the machine in
> question was 50 feet from my desk, but it is currently 45 miles from
> my desk and that IS a problem.  Thanks,

Is it a bridged device or a member of a bridge?  What version of NM is
installed?

What happens if you stop NM, 'killall -TERM nm-system-settings', and
run:

/usr/sbin/nm-system-settings --debug --plugins=ifcfg-fedora

What's the output?

Dan



From katzj at redhat.com  Thu Nov 13 16:24:20 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 13 Nov 2008 11:24:20 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <1226592802.3651.30.camel@eagle.danny.cz>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
Message-ID: <1226593460.13077.91.camel@aglarond.local>

On Thu, 2008-11-13 at 17:13 +0100, Dan Hor?k wrote:
> Chris Adams p??e v ?t 13. 11. 2008 v 10:02 -0600:
> > Once upon a time, Dan Williams <dcbw at redhat.com> said:
> > > You can certainly disable NetworkManager and use manual configuration of
> > > your network devices.
> > 
> > For how long?  I thought I'd read that the plan was to use NM for
> > everything and eliminate /etc/init.d/network.
> 
> We will keep/maintain /etc/init.d/network forever :-) They don't
> conflict, so there is no reason to completely drop the old method.

Sure there is.  Having multiple methods means more things that have to
be tested, more things that have to be updated for system changes, etc.

Jeremy



From dcbw at redhat.com  Thu Nov 13 16:25:05 2008
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 13 Nov 2008 11:25:05 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <20081113152838.GA48391@dspnet.fr.eu.org>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU> <491C35C8.5060207@gmail.com>
	<20081113142041.GH24297@angus.ind.WPI.EDU>
	<1226588855.4714.10.camel@localhost.localdomain>
	<20081113152838.GA48391@dspnet.fr.eu.org>
Message-ID: <1226593505.4714.30.camel@localhost.localdomain>

On Thu, 2008-11-13 at 16:28 +0100, Olivier Galibert wrote:
> On Thu, Nov 13, 2008 at 10:07:35AM -0500, Dan Williams wrote:
> > IPv6: target for next version
> > Alias: you can already add multiple IPs to an interface
> > bridging: planned
> > bonding: planned
> > VLANs: good to have, needs more investigation
> 
> Static routes ?

Already there, in the connection editor see the "Routes..." button in
the IPv4 tab.  Routes from ifcfg files aren't yet supported, but could
be.  Routes from keyfile-based system connections (ie, prelogin) are
supported.

Dan




From cra at WPI.EDU  Thu Nov 13 16:28:36 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 13 Nov 2008 11:28:36 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <1226593505.4714.30.camel@localhost.localdomain>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<491C35C8.5060207@gmail.com>
	<20081113142041.GH24297@angus.ind.WPI.EDU>
	<1226588855.4714.10.camel@localhost.localdomain>
	<20081113152838.GA48391@dspnet.fr.eu.org>
	<1226593505.4714.30.camel@localhost.localdomain>
Message-ID: <20081113162836.GK23749@angus.ind.WPI.EDU>

On Thu, Nov 13, 2008 at 11:25:05AM -0500, Dan Williams wrote:
> On Thu, 2008-11-13 at 16:28 +0100, Olivier Galibert wrote:
> > Static routes ?
> 
> Already there, in the connection editor see the "Routes..." button in
> the IPv4 tab.  Routes from ifcfg files aren't yet supported, but could
> be.  Routes from keyfile-based system connections (ie, prelogin) are
> supported.

Can you tell us more about this "keyfile-based system connections" 
thing?  Sounds interesting.



From berrange at redhat.com  Thu Nov 13 16:33:46 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Thu, 13 Nov 2008 16:33:46 +0000
Subject: starting Fedora Server SIG
In-Reply-To: <1226588855.4714.10.camel@localhost.localdomain>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<491C35C8.5060207@gmail.com>
	<20081113142041.GH24297@angus.ind.WPI.EDU>
	<1226588855.4714.10.camel@localhost.localdomain>
Message-ID: <20081113163346.GL8200@redhat.com>

On Thu, Nov 13, 2008 at 10:07:35AM -0500, Dan Williams wrote:
> On Thu, 2008-11-13 at 09:20 -0500, Chuck Anderson wrote:
> > On Thu, Nov 13, 2008 at 08:12:24AM -0600, Les Mikesell wrote:
> > > Chuck Anderson wrote:
> > >> On Thu, Nov 13, 2008 at 02:27:42PM +0100, Adam Tkac wrote:
> > >>> Crucial thing is static IPs which NM can't handle.
> > >>
> > >> False.
> > >
> > > If you bring up a mix of static and dynamically assigned interfaces, can  
> > > you control which gets to assign the default route and DNS servers?
> > 
> > The last time I looked at the code, NM had a hard-coded policy for how 
> > it assigns the default route and DNS servers.  If you only have one 
> > interface with a default route and the other interfaces don't have a 
> > default route, then the DNS and default route for that interface is 
> > set.  If you have more than one, I believe it picks based on the 
> > hard-coded policy, which I believe is wired first, then wireless, then 
> > dialup/mobile broadband.  In the face of multiple wired connections, 
> > I'm not sure what the policy is.
> > 
> > Yes, NM needs to grow the ability to specify policy outside of the 
> > code.
> 
> The current policy is this.  If the device gets a gateway from anything
> (either DHCP or the GUI or the ifcfg files) then it becomes a candidate
> for the default route.  If you don't enter a gateway for any of that
> device's IP addresses in the GUI, it shouldn't ever get the default
> route.
> 
> Yes, there's room for improvement.  If you check "Ignore automatically
> provided routes" and you're using DHCP, NM should probably ignore the
> gateway for that device when deciding which device gets the default
> route.
> 
> > It also needs IPv6 support (coming soon I hear), alias support, 
> 
> IPv6: target for next version
> Alias: you can already add multiple IPs to an interface
> bridging: planned
> bonding: planned
> VLANs: good to have, needs more investigation

The combo of last 3 is key for many virtualization deployments. 
eg, we want to put eth0 + eth1 into a bonding device bond0, then 
create 10 vlans bond0.0, bond0.1.... devices ontop of bond0, and 
finally put each of these vlan devices into its own bridge. The
guests' tap devices are then connected to various bridges according
to which VLAN you want the guest to see.

AFAIK, its not even possible to get this config working with regular
networking initscripts in all cases, let alone networkmanager. So
people currently use horrible shell scripts to configure it, eg as
per this doc

  http://www.certifried.com/files/Xen_networking.pdf

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 dcbw at redhat.com  Thu Nov 13 16:34:15 2008
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 13 Nov 2008 11:34:15 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <20081113162836.GK23749@angus.ind.WPI.EDU>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU> <491C35C8.5060207@gmail.com>
	<20081113142041.GH24297@angus.ind.WPI.EDU>
	<1226588855.4714.10.camel@localhost.localdomain>
	<20081113152838.GA48391@dspnet.fr.eu.org>
	<1226593505.4714.30.camel@localhost.localdomain>
	<20081113162836.GK23749@angus.ind.WPI.EDU>
Message-ID: <1226594055.4714.40.camel@localhost.localdomain>

On Thu, 2008-11-13 at 11:28 -0500, Chuck Anderson wrote:
> On Thu, Nov 13, 2008 at 11:25:05AM -0500, Dan Williams wrote:
> > On Thu, 2008-11-13 at 16:28 +0100, Olivier Galibert wrote:
> > > Static routes ?
> > 
> > Already there, in the connection editor see the "Routes..." button in
> > the IPv4 tab.  Routes from ifcfg files aren't yet supported, but could
> > be.  Routes from keyfile-based system connections (ie, prelogin) are
> > supported.
> 
> Can you tell us more about this "keyfile-based system connections" 
> thing?  Sounds interesting.

Since ifcfg files will probably never support things like VPN, 3G, WPA,
etc, NM has a system settings 'keyfile' plugin that allows editing
system connections from the connection editor, or your favorite text
editor if you don't use a GUI at all.  Add ",keyfile" to the --plugins
argument in
the /usr/share/dbus-1/system-services/org.freedesktop.NetworkManagerSystemSettings.service file, and then 'killall -TERM nm-system-settings'.

The format for some of the options isn't yet optimal, and it needs more
documentation, but it supports all options that NM supports.  Yes, you
can have mobile broadband before boot with NM if you like.

Dan




From lesmikesell at gmail.com  Thu Nov 13 16:36:07 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 13 Nov 2008 10:36:07 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1226592802.3651.30.camel@eagle.danny.cz>
References: <1226429441.3593.77.camel@eagle.danny.cz>	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>	<20081113134947.GF24297@angus.ind.WPI.EDU>	<20081113140153.GA1538120@hiwaay.net>	<1226588572.4714.4.camel@localhost.localdomain>	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
Message-ID: <491C5777.3090402@gmail.com>

Dan Hor?k wrote:
> Chris Adams p??e v ?t 13. 11. 2008 v 10:02 -0600:
>> Once upon a time, Dan Williams <dcbw at redhat.com> said:
>>> You can certainly disable NetworkManager and use manual configuration of
>>> your network devices.
>> For how long?  I thought I'd read that the plan was to use NM for
>> everything and eliminate /etc/init.d/network.
> 
> We will keep/maintain /etc/init.d/network forever :-) They don't
> conflict, so there is no reason to completely drop the old method.

Who wins if they both want to set the default route and DNS servers? 
Chances are that if you have a working statically assigned interface you 
would not want to switch them to subsequent DHCP assigned NIC - but on 
the other hand if you bring up a VPN tunnel, you might.  And does NM 
know enough to drop routes through an interface that is physically down 
(no link, not ifdown) statically assigned or not?

-- 
   Les Mikesell
    lesmikesell at gmail.com




From cra at WPI.EDU  Thu Nov 13 16:59:22 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 13 Nov 2008 11:59:22 -0500
Subject: PackageKit 0.3.10 in Fedora 9
In-Reply-To: <20081111192408.GB23749@angus.ind.WPI.EDU>
References: <1226421464.3033.80.camel@hughsie-laptop>
	<20081111192408.GB23749@angus.ind.WPI.EDU>
Message-ID: <20081113165922.GL23749@angus.ind.WPI.EDU>

On Tue, Nov 11, 2008 at 02:24:08PM -0500, Chuck Anderson wrote:
> On Tue, Nov 11, 2008 at 04:37:44PM +0000, Richard Hughes wrote:
> > I've just built 0.3.10 for F10 and pushed it to updates-testing:
> > 
> > https://admin.fedoraproject.org/updates/PackageKit-0.3.10-1.fc9,gnome-packagekit-0.3.10-1.fc9
> > 
> > I would appreciate some feedback. If you can test the preupgrade
> > notification, that would be even better. Thanks.
> 
> I updated my F9 system to this then used the PK GUI to enable the 
> updates-testing-newkey software repo (I don't know how/why I had that 
> disabled--I must have been testing something a long time ago, disabled 
> it, and forgot to re-enable it.  Doh.).  I got a bunch of testing 
> updates and applied them successfully.  So far so good.
> 
> How are we supposed to test the preupgrade notification?  I enabled 
> checking for updates every hour, and major upgrades daily.  If I wait 
> a day should I see the F10 upgrade appear?

The gpk-update-icon isn't appearing even though I have updates that 
show up when I manually run "yum update".  I cancelled the yum update, 
and the icon still doesn't appear.  I have these packages installed:

gnome-packagekit-0.3.10-1.fc9.x86_64
gnome-packagekit-extra-0.3.10-1.fc9.x86_64
PackageKit-0.3.10-1.fc9.x86_64
PackageKit-browser-plugin-0.3.10-1.fc9.x86_64
PackageKit-docs-0.3.10-1.fc9.x86_64
PackageKit-glib-0.3.10-1.fc9.x86_64
PackageKit-gstreamer-plugin-0.3.10-1.fc9.x86_64
PackageKit-udev-helper-0.3.10-1.fc9.x86_64
PackageKit-yum-0.3.10-1.fc9.x86_64
PackageKit-yum-plugin-0.3.10-1.fc9.x86_64



From rdieter at math.unl.edu  Thu Nov 13 17:19:56 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 13 Nov 2008 11:19:56 -0600
Subject: a trivial fix makes a big change
References: <385866f0811121507y228eb82egb77544b3edccae3f@mail.gmail.com>
	<491B70A4.6090102@fedoraproject.org>
	<385866f0811130738s67a1be18r858313887b4e02d8@mail.gmail.com>
Message-ID: <gfhmdb$9jt$1@ger.gmane.org>

Muayyad AlSadi wrote:


> yes but the rpm already ships with a config file
> 
> rpm -qf /etc/samba/smb.conf
> samba-common-3.2.4-0.22.fc10.i386
> 
> so I ask for that file in that package to be modified to have a line like
> this
> 
> usershare path = /var/lib/samba/usershare
> BTW: I forget that we have system-config-samba
> we can put a checkbox [ ]  enable nautilus-share

I'd suggest you contact the maintainers of these packages (samba, system-config-samba) to work on the implementation details.

-- Rex





From dan at danny.cz  Thu Nov 13 17:01:53 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Thu, 13 Nov 2008 18:01:53 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <1226593460.13077.91.camel@aglarond.local>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
Message-ID: <1226595713.3651.35.camel@eagle.danny.cz>


Jeremy Katz p??e v ?t 13. 11. 2008 v 11:24 -0500:
> On Thu, 2008-11-13 at 17:13 +0100, Dan Hor?k wrote:
> > Chris Adams p??e v ?t 13. 11. 2008 v 10:02 -0600:
> > > Once upon a time, Dan Williams <dcbw at redhat.com> said:
> > > > You can certainly disable NetworkManager and use manual configuration of
> > > > your network devices.
> > > 
> > > For how long?  I thought I'd read that the plan was to use NM for
> > > everything and eliminate /etc/init.d/network.
> > 
> > We will keep/maintain /etc/init.d/network forever :-) They don't
> > conflict, so there is no reason to completely drop the old method.
> 
> Sure there is.  Having multiple methods means more things that have to
> be tested, more things that have to be updated for system changes, etc.

That can be true, but there exist both demand and testing/development
capacity for the classic configuration.


		Dan




From hughsient at gmail.com  Thu Nov 13 17:05:56 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 13 Nov 2008 17:05:56 +0000
Subject: PackageKit 0.3.10 in Fedora 9
In-Reply-To: <20081113165922.GL23749@angus.ind.WPI.EDU>
References: <1226421464.3033.80.camel@hughsie-laptop>
	<20081111192408.GB23749@angus.ind.WPI.EDU>
	<20081113165922.GL23749@angus.ind.WPI.EDU>
Message-ID: <1226595956.7076.125.camel@hughsie-laptop>

On Thu, 2008-11-13 at 11:59 -0500, Chuck Anderson wrote:
> The gpk-update-icon isn't appearing even though I have updates that 
> show up when I manually run "yum update".  I cancelled the yum update,
> and the icon still doesn't appear.  I have these packages installed:
> 
> gnome-packagekit-0.3.10-1.fc9.x86_64
> gnome-packagekit-extra-0.3.10-1.fc9.x86_64
> PackageKit-0.3.10-1.fc9.x86_64
> PackageKit-browser-plugin-0.3.10-1.fc9.x86_64
> PackageKit-docs-0.3.10-1.fc9.x86_64
> PackageKit-glib-0.3.10-1.fc9.x86_64
> PackageKit-gstreamer-plugin-0.3.10-1.fc9.x86_64
> PackageKit-udev-helper-0.3.10-1.fc9.x86_64
> PackageKit-yum-0.3.10-1.fc9.x86_64
> PackageKit-yum-plugin-0.3.10-1.fc9.x86_64

It'll only check once per day by default. If you set it to hourly, do
you get an icon appear after waiting a little?

Richard.




From jkeating at redhat.com  Thu Nov 13 17:07:30 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 13 Nov 2008 09:07:30 -0800
Subject: starting Fedora Server SIG
In-Reply-To: <faa16b610811130623rdde59dg7d73e535ce80d17e@mail.gmail.com>
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226518090.3638.37.camel@eagle.danny.cz>
	<20081112192954.GC12723@nostromo.devel.redhat.com>
	<87iqqsiubm.fsf@sheridan.bigo.ensc.de>
	<1226520557.5295.20.camel@luminos.localdomain>
	<491B6440.6050609@gmail.com>
	<1226532175.5295.36.camel@luminos.localdomain>
	<alpine.LFD.1.10.0811130059100.23693@newtla.xelerance.com>
	<faa16b610811130623rdde59dg7d73e535ce80d17e@mail.gmail.com>
Message-ID: <1226596050.5295.55.camel@luminos.localdomain>

On Thu, 2008-11-13 at 09:23 -0500, Colin Walters wrote:
> Now, ksplice does let you avoid reboots but has tradeoffs.

Such as our kernel team completely ignoring any bugs that come from
ksplice usage.

-- 
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/20081113/4ac861af/attachment.sig>

From skvidal at fedoraproject.org  Thu Nov 13 17:10:07 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 13 Nov 2008 12:10:07 -0500 (EST)
Subject: starting Fedora Server SIG
In-Reply-To: <87ej1fhatg.fsf@fc5.bigo.ensc.de>
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr>
	<20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
	<alpine.LFD.2.00.0811130954360.19678@localhost.localdomain>
	<87ej1fhatg.fsf@fc5.bigo.ensc.de>
Message-ID: <alpine.LFD.2.00.0811131207550.19678@localhost.localdomain>



On Thu, 13 Nov 2008, Enrico Scholz wrote:
>
>> If we don't have a good default course of action, why do you think the
>> user is going to know better?
>
> Why do you think, that 'yum' knows which choice is the best one? E.g. the
> 'plymouth' case shows that the wrong decision was taken and that the user
> would have made the right one.

But we still have to have a good default for the -y case. We can't stop 
and prompt when they've passed -y.


>> If we do have a good default course of action, why are we prompting
>> the user?
>
> How do you define/configure a "good default course"? Prompting is
> probably easier to implement than such a logic.

Except we have to have a default. -y and non-interactive installs require 
it.

-sv



From cra at WPI.EDU  Thu Nov 13 17:12:28 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 13 Nov 2008 12:12:28 -0500
Subject: PackageKit 0.3.10 in Fedora 9
In-Reply-To: <1226595956.7076.125.camel@hughsie-laptop>
References: <1226421464.3033.80.camel@hughsie-laptop>
	<20081111192408.GB23749@angus.ind.WPI.EDU>
	<20081113165922.GL23749@angus.ind.WPI.EDU>
	<1226595956.7076.125.camel@hughsie-laptop>
Message-ID: <20081113171228.GM23749@angus.ind.WPI.EDU>

On Thu, Nov 13, 2008 at 05:05:56PM +0000, Richard Hughes wrote:
> On Thu, 2008-11-13 at 11:59 -0500, Chuck Anderson wrote:
> > The gpk-update-icon isn't appearing even though I have updates that 
> > show up when I manually run "yum update".  I cancelled the yum update,
> > and the icon still doesn't appear.  I have these packages installed:
> > 
> > gnome-packagekit-0.3.10-1.fc9.x86_64
> > gnome-packagekit-extra-0.3.10-1.fc9.x86_64
> > PackageKit-0.3.10-1.fc9.x86_64
> > PackageKit-browser-plugin-0.3.10-1.fc9.x86_64
> > PackageKit-docs-0.3.10-1.fc9.x86_64
> > PackageKit-glib-0.3.10-1.fc9.x86_64
> > PackageKit-gstreamer-plugin-0.3.10-1.fc9.x86_64
> > PackageKit-udev-helper-0.3.10-1.fc9.x86_64
> > PackageKit-yum-0.3.10-1.fc9.x86_64
> > PackageKit-yum-plugin-0.3.10-1.fc9.x86_64
> 
> It'll only check once per day by default. If you set it to hourly, do
> you get an icon appear after waiting a little?

I set it to hourly.  I haven't yet waited an hour, but the issue here 
is that I resumed from suspend-to-ram, and it didn't immedately check.  
I would expect it to immediately check when it first got a network 
connection and it had been at least an Hour (or Day) since it last 
checked.  Also, I thought it would force a check when yum finishes due 
to PackageKit-yum-plugin-0.3.10-1.fc9.x86_64.



From jkeating at redhat.com  Thu Nov 13 17:15:33 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 13 Nov 2008 09:15:33 -0800
Subject: starting Fedora Server SIG
In-Reply-To: <1226594055.4714.40.camel@localhost.localdomain>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU> <491C35C8.5060207@gmail.com>
	<20081113142041.GH24297@angus.ind.WPI.EDU>
	<1226588855.4714.10.camel@localhost.localdomain>
	<20081113152838.GA48391@dspnet.fr.eu.org>
	<1226593505.4714.30.camel@localhost.localdomain>
	<20081113162836.GK23749@angus.ind.WPI.EDU>
	<1226594055.4714.40.camel@localhost.localdomain>
Message-ID: <1226596533.5295.56.camel@luminos.localdomain>

On Thu, 2008-11-13 at 11:34 -0500, Dan Williams wrote:
> Since ifcfg files will probably never support things like VPN, 3G, WPA,
> etc, NM has a system settings 'keyfile' plugin that allows editing
> system connections from the connection editor, or your favorite text
> editor if you don't use a GUI at all.  Add ",keyfile" to the --plugins
> argument in
> the /usr/share/dbus-1/system-services/org.freedesktop.NetworkManagerSystemSettings.service file, and then 'killall -TERM nm-system-settings'.
> 
> The format for some of the options isn't yet optimal, and it needs more
> documentation, but it supports all options that NM supports.  Yes, you
> can have mobile broadband before boot with NM if you like.

Dan, when/where might this be documented?

-- 
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/20081113/d7914d74/attachment.sig>

From hughsient at gmail.com  Thu Nov 13 17:22:05 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 13 Nov 2008 17:22:05 +0000
Subject: PackageKit 0.3.10 in Fedora 9
In-Reply-To: <20081113171228.GM23749@angus.ind.WPI.EDU>
References: <1226421464.3033.80.camel@hughsie-laptop>
	<20081111192408.GB23749@angus.ind.WPI.EDU>
	<20081113165922.GL23749@angus.ind.WPI.EDU>
	<1226595956.7076.125.camel@hughsie-laptop>
	<20081113171228.GM23749@angus.ind.WPI.EDU>
Message-ID: <1226596925.7076.150.camel@hughsie-laptop>

On Thu, 2008-11-13 at 12:12 -0500, Chuck Anderson wrote:
> I set it to hourly.  I haven't yet waited an hour, but the issue here 
> is that I resumed from suspend-to-ram, and it didn't immedately check.

Right, by default it waits 10 minutes in this case. You can change this
number by editing /apps/gnome-packagekit/session_startup_timeout.

> I would expect it to immediately check when it first got a network 
> connection and it had been at least an Hour (or Day) since it last 
> checked.  Also, I thought it would force a check when yum finishes due
> to PackageKit-yum-plugin-0.3.10-1.fc9.x86_64.

Right, it still obays the timeout even in these cases - the logic being
when you resume you want to do something like check for email, and
checking for updates can be defered until you don't care.

You can edit the startup setting
using /apps/gnome-packagekit/force_get_updates_login -- this will ensure
you'll get notified as soon as you get network connectivity.

Richard.




From dcbw at redhat.com  Thu Nov 13 17:20:51 2008
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 13 Nov 2008 12:20:51 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <491C5777.3090402@gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz> <491C5777.3090402@gmail.com>
Message-ID: <1226596851.4714.58.camel@localhost.localdomain>

On Thu, 2008-11-13 at 10:36 -0600, Les Mikesell wrote:
> Dan Hor?k wrote:
> > Chris Adams p??e v ?t 13. 11. 2008 v 10:02 -0600:
> >> Once upon a time, Dan Williams <dcbw at redhat.com> said:
> >>> You can certainly disable NetworkManager and use manual configuration of
> >>> your network devices.
> >> For how long?  I thought I'd read that the plan was to use NM for
> >> everything and eliminate /etc/init.d/network.
> > 
> > We will keep/maintain /etc/init.d/network forever :-) They don't
> > conflict, so there is no reason to completely drop the old method.
> 
> Who wins if they both want to set the default route and DNS servers? 

If two equal class devices (ethernet > wifi > mobile broadband) are
capable of being the default route, the one detected earliest from HAL
wins.

The default device's DNS information gets added first, and each active
device's DNS information is appended.  Thus you can certainly get more
than 3 nameservers in /etc/resolv.conf, but 3 is all that the glibc
resolver allows.  In the future we can resurrect caching nameserver to
support split DNS, but that's based on _domain name_, not IP address, so
the best solution there, by default (but allow manual override) is to
use the DHCP-returned search domains (if any) as the domains to split
DNS for.

> Chances are that if you have a working statically assigned interface you 
> would not want to switch them to subsequent DHCP assigned NIC - but on 
> the other hand if you bring up a VPN tunnel, you might.  And does NM 

Why's that?

> know enough to drop routes through an interface that is physically down 
> (no link, not ifdown) statically assigned or not?

If the interface is physically down, NM will deactivate the connection
and addresses and routes get flushed.  Fine-grained modification of
device parameters and configuration while the interface is
down/disconnected isn't supported and likely won't be.

I tend to think there will be a place for manual network configuration
for a long time (no matter what jeremy says :), because there are some
situations that are just too borderline to support in the short term, or
are sufficiently borderline that the maintenance cost of adding the
feature outweighs the benefit of the feature in the first place.
There's always a tradeoff to feature addition.

Dan




From dcbw at redhat.com  Thu Nov 13 17:22:03 2008
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 13 Nov 2008 12:22:03 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <1226596533.5295.56.camel@luminos.localdomain>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU> <491C35C8.5060207@gmail.com>
	<20081113142041.GH24297@angus.ind.WPI.EDU>
	<1226588855.4714.10.camel@localhost.localdomain>
	<20081113152838.GA48391@dspnet.fr.eu.org>
	<1226593505.4714.30.camel@localhost.localdomain>
	<20081113162836.GK23749@angus.ind.WPI.EDU>
	<1226594055.4714.40.camel@localhost.localdomain>
	<1226596533.5295.56.camel@luminos.localdomain>
Message-ID: <1226596923.4714.61.camel@localhost.localdomain>

On Thu, 2008-11-13 at 09:15 -0800, Jesse Keating wrote:
> On Thu, 2008-11-13 at 11:34 -0500, Dan Williams wrote:
> > Since ifcfg files will probably never support things like VPN, 3G, WPA,
> > etc, NM has a system settings 'keyfile' plugin that allows editing
> > system connections from the connection editor, or your favorite text
> > editor if you don't use a GUI at all.  Add ",keyfile" to the --plugins
> > argument in
> > the /usr/share/dbus-1/system-services/org.freedesktop.NetworkManagerSystemSettings.service file, and then 'killall -TERM nm-system-settings'.
> > 
> > The format for some of the options isn't yet optimal, and it needs more
> > documentation, but it supports all options that NM supports.  Yes, you
> > can have mobile broadband before boot with NM if you like.
> 
> Dan, when/where might this be documented?

When I struggle up for air from the tarpit that is the concurrent
release of NM 0.7 + F10 + RHEL 5.3? :)

Dan




From dan at danny.cz  Thu Nov 13 17:30:45 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Thu, 13 Nov 2008 18:30:45 +0100
Subject: minimal install - was Re: starting Fedora Server SIG
In-Reply-To: <1226429441.3593.77.camel@eagle.danny.cz>
References: <1226429441.3593.77.camel@eagle.danny.cz>
Message-ID: <1226597445.3651.52.camel@eagle.danny.cz>

I have successfully tested booting a minimal Fedora system that should
be able to install more packages. Here are the steps for "bootstrapping"
such system:

- use USB flashdisk > cca 600MB (installed pkgs + yum cache), format a
partition as ext3, mount as /mnt
- yum --installroot=/mnt --disablerepo=* --enablerepo=development
install grub kernel initscripts yum plymouth-text-and-details-only
- install grub to the MBR of the flashdisk
- create /etc/fstab (/ + /proc + /sys)
- run mkinitrd --with-usb
- set password for root
- boot


		Dan




From lesmikesell at gmail.com  Thu Nov 13 17:36:28 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 13 Nov 2008 11:36:28 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1226596050.5295.55.camel@luminos.localdomain>
References: <1226485422.3638.22.camel@eagle.danny.cz>	<491AF259.40907@comcast.net>
	<20081112191551.GC1461854@hiwaay.net>	<1226518090.3638.37.camel@eagle.danny.cz>	<20081112192954.GC12723@nostromo.devel.redhat.com>	<87iqqsiubm.fsf@sheridan.bigo.ensc.de>	<1226520557.5295.20.camel@luminos.localdomain>	<491B6440.6050609@gmail.com>	<1226532175.5295.36.camel@luminos.localdomain>	<alpine.LFD.1.10.0811130059100.23693@newtla.xelerance.com>	<faa16b610811130623rdde59dg7d73e535ce80d17e@mail.gmail.com>
	<1226596050.5295.55.camel@luminos.localdomain>
Message-ID: <491C659C.2090806@gmail.com>

Jesse Keating wrote:
> On Thu, 2008-11-13 at 09:23 -0500, Colin Walters wrote:
>> Now, ksplice does let you avoid reboots but has tradeoffs.
> 
> Such as our kernel team completely ignoring any bugs that come from
> ksplice usage.

And more to the point, the reason you are replacing the kernel is very 
likely that you found out about some bugs in it.  Now, do you trust the 
old version with bugs you know and the new replacement with bugs you 
don't know yet (and perhaps even different device initialization 
requirements and maybe even a different device naming strategy) to 
handle a clean transition on the fly with a process that hardly anyone 
has tested?  I'll pass.  There might be some chance in the more 
constrained RHEL world.

-- 
    Les Mikesell
     lesmikesell at gmail.com



From mcepl at redhat.com  Thu Nov 13 17:57:40 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 13 Nov 2008 18:57:40 +0100
Subject: Who moved my bug?
References: <200811061243.49188.opensource@till.name>
	<1226017819.5758.11.camel@kennedy>
	<20081107111727.GA10541@mokona.greysector.net>
	<200811081419.20620.sgrubb@redhat.com>
	<tarlu5x85q.ln2@ppp1053.in.ipex.cz>
	<3170f42f0811111126y4868f99bj9fca37934c880bf0@mail.gmail.com>
Message-ID: <kd6uu5x84u.ln2@ppp1053.in.ipex.cz>

On 2008-11-11, 19:26 GMT, Debarshi Ray wrote:
> Now that I started using ON_DEV, I find that the "my front 
> page" link does not list bugs in this state. However, "my bugs" 
> does work. Is there any reason for this to be so? This is not 
> a major irritation, but I am curios.

Probably BZ maintainers didn't expet anybody to use ON_DEV 
anymore. PLease, file a bug against the Bugzilla product.

Mat?j



From enrico.scholz at informatik.tu-chemnitz.de  Thu Nov 13 18:06:32 2008
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Thu, 13 Nov 2008 19:06:32 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811131207550.19678@localhost.localdomain> (Seth
	Vidal's message of "Thu, 13 Nov 2008 12:10:07 -0500 (EST)")
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr> <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
	<alpine.LFD.2.00.0811130954360.19678@localhost.localdomain>
	<87ej1fhatg.fsf@fc5.bigo.ensc.de>
	<alpine.LFD.2.00.0811131207550.19678@localhost.localdomain>
Message-ID: <87abc3h55j.fsf@fc5.bigo.ensc.de>

Seth Vidal <skvidal at fedoraproject.org> writes:

>>> If we don't have a good default course of action, why do you think the
>>> user is going to know better?
>>
>> Why do you think, that 'yum' knows which choice is the best one? 
>> E.g. the 'plymouth' case shows that the wrong decision was taken and
>> that the user would have made the right one.
>
> But we still have to have a good default for the -y case. We can't
> stop and prompt when they've passed -y.

Add a configuration option which defines the "good default" for '-y'
operations.  Possible choices are 'fail' (abort on ambiguities) and
'shortest-wins' where I suggest 'fail' as the preconfigured value for
F11+ and 'shortest-wins' for legacy installations.


Enrico



From jonathan at jonmasters.org  Thu Nov 13 18:15:14 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Thu, 13 Nov 2008 13:15:14 -0500
Subject: db-compat
In-Reply-To: <1226395109.26647.30.camel@arekh.okg>
References: <1226293343.30170.4.camel@jcmlaptop>
	<20081110171712.GH8850@nostromo.devel.redhat.com>
	<1226351611.18109.15.camel@londonpacket.bos.redhat.com>
	<20081110213030.GB13633@nostromo.devel.redhat.com>
	<4918B44D.4050904@nobugconsulting.ro>
	<1226380574.23813.5.camel@perihelion.int.jonmasters.org>
	<1226395109.26647.30.camel@arekh.okg>
Message-ID: <1226600115.8114.15.camel@perihelion.int.jonmasters.org>

On Tue, 2008-11-11 at 10:18 +0100, Nicolas Mailhot wrote:
> Le mardi 11 novembre 2008 ? 00:16 -0500, Jon Masters a ?crit :
> > On Tue, 2008-11-11 at 00:23 +0200, Manuel Wolfshant wrote:
> 
> > > > db-4.1 was last the system DB library in RHEL 3/FC1.
> > 
> > What's the point of a "compat" library if not to support software built
> > for such systems? 

> Compat libraries are here to help transitions within the repository

Wow. That's a complete definition of what I take as the meaning of
"compatibility". So it's only compatibility with ourselves that we care
about now then? Cool! Let's throw out any libraries not used in Fedora,
and while we're at it, let's throw out any symbols those libraries
provide that we're not using - after all, we don't need them :)

> ? as long as they're available there's the risk someone adds a new
> package depending on them in the repo, making the transition go
> backwards

I love this kind of argument being used in Free Software communities. It
gives me the warm and fuzzies. I'm strongly against smoking too, but I'm
not going to ban the sale of cigarettes. I (strangely) take the view
that people can know for themselves what is good and bad for them. I
think most people know if they're (intentionally) using a compat lib.

> Thus compat libraries represent a grace period for everyone to
> transition gracefully. That some ISVs do not want to understand this and
> wait till the grace period is over to realise they need to do some work
> is something you should take with those ISVs. Fedora/RHEL provided a
> grace period, they chose not to use it.

To be fair, the entire world doesn't move at the same pace as a
distribution like Fedora. Yes, maybe it should, but maybe we shouldn't
make it overly difficult for software that works just fine to be used.
If keeping userspace compatibility isn't too difficult, it's generally
something Linux has always favored doing.

> It's the same problem as users wanting to block xorg releases till
> nvidia supported the new APIs, while nvidia waits for new releases to be
> official to start working on those APIs.

Er, no it's not. This has no semblance of a resemblance to that
situation - we're talking purely about an optional compat lib.

> Bad service from ISVs that do proprietary software, nothing less.

Cool. Let's blame the non-Free sofrware ISVs at every turn!

(sorry, overly sarky email...nothing personal, just in that kind of
mood, probably too much decaf coffee...)

Jon.





From jonathan at jonmasters.org  Thu Nov 13 18:18:33 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Thu, 13 Nov 2008 13:18:33 -0500
Subject: db-compat
In-Reply-To: <49198736.9050100@nobugconsulting.ro>
References: <1226293343.30170.4.camel@jcmlaptop>
	<20081110171712.GH8850@nostromo.devel.redhat.com>
	<1226351611.18109.15.camel@londonpacket.bos.redhat.com>
	<20081110213030.GB13633@nostromo.devel.redhat.com>
	<4918B44D.4050904@nobugconsulting.ro>
	<1226380574.23813.5.camel@perihelion.int.jonmasters.org>
	<1226395109.26647.30.camel@arekh.okg>
	<49198736.9050100@nobugconsulting.ro>
Message-ID: <1226600313.8114.19.camel@perihelion.int.jonmasters.org>

On Tue, 2008-11-11 at 15:23 +0200, Manuel Wolfshant wrote:
> Nicolas Mailhot wrote:

> > Bad service from ISVs that do proprietary software, nothing less.
> >   
> That is correct. Try convincing the hardware industry to not use the 
> tools from the above vendors, in the context where there are only 3 
> major players and 2 of them have their own agenda.

Yeah. I'd love to use a Free (or even a free) software place and route
or synthesis tool for VHDL, but the reality is that these companies
still believe that making information available to do that will
materially hurt them. So, like you, I'm forced to rely upon an abstract
notion of "userspace compatibility". Crazy idea, I know :)

Jon.




From nicolas.mailhot at laposte.net  Thu Nov 13 18:20:09 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 13 Nov 2008 19:20:09 +0100
Subject: db-compat
In-Reply-To: <1226600115.8114.15.camel@perihelion.int.jonmasters.org>
References: <1226293343.30170.4.camel@jcmlaptop>
	<20081110171712.GH8850@nostromo.devel.redhat.com>
	<1226351611.18109.15.camel@londonpacket.bos.redhat.com>
	<20081110213030.GB13633@nostromo.devel.redhat.com>
	<4918B44D.4050904@nobugconsulting.ro>
	<1226380574.23813.5.camel@perihelion.int.jonmasters.org>
	<1226395109.26647.30.camel@arekh.okg>
	<1226600115.8114.15.camel@perihelion.int.jonmasters.org>
Message-ID: <1226600409.15313.1.camel@arekh.okg>

Le jeudi 13 novembre 2008 ? 13:15 -0500, Jon Masters a ?crit :

> > Bad service from ISVs that do proprietary software, nothing less.
> 
> Cool. Let's blame the non-Free sofrware ISVs at every turn!
> 
> (sorry, overly sarky email...nothing personal, just in that kind of
> mood, probably too much decaf coffee...)

For the record, I spent 4 years of my life working at a Linux ISV.

-- 
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/20081113/5a11cea9/attachment.sig>

From nicolas.mailhot at laposte.net  Thu Nov 13 18:22:17 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 13 Nov 2008 19:22:17 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <1226593460.13077.91.camel@aglarond.local>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
Message-ID: <1226600537.15313.2.camel@arekh.okg>

Le jeudi 13 novembre 2008 ? 11:24 -0500, Jeremy Katz a ?crit :
> On Thu, 2008-11-13 at 17:13 +0100, Dan Hor?k wrote:
> > Chris Adams p??e v ?t 13. 11. 2008 v 10:02 -0600:
> > > Once upon a time, Dan Williams <dcbw at redhat.com> said:
> > > > You can certainly disable NetworkManager and use manual configuration of
> > > > your network devices.
> > > 
> > > For how long?  I thought I'd read that the plan was to use NM for
> > > everything and eliminate /etc/init.d/network.
> > 
> > We will keep/maintain /etc/init.d/network forever :-) They don't
> > conflict, so there is no reason to completely drop the old method.
> 
> Sure there is.  Having multiple methods means more things that have to
> be tested, more things that have to be updated for system changes, etc.

And removing the incentive to get the corner cases working on the new
system, leaving it perpetually unfinished.

-- 
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/20081113/3b65c618/attachment.sig>

From poelstra at redhat.com  Thu Nov 13 18:32:39 2008
From: poelstra at redhat.com (John Poelstra)
Date: Thu, 13 Nov 2008 10:32:39 -0800
Subject: F8 EOL messaging
In-Reply-To: <20081112010144.GE8501@localhost.localdomain>
References: <20081112010144.GE8501@localhost.localdomain>
Message-ID: <491C72C7.9020402@redhat.com>

Paul W. Frields wrote:
> It seems really wrong to EOL F8 on Christmas Day.  Can we make that
> December 26th? :-)
> 
> 

I suggest that we extend the EOL of F8 to January 5, 2009.  We will not 
be able to auto-close the open Fedora 8 bugs until this date as many Red 
Hat people will be on holiday until that time.

John



From mike at miketc.net  Thu Nov 13 18:30:19 2008
From: mike at miketc.net (Mike Chambers)
Date: Thu, 13 Nov 2008 12:30:19 -0600
Subject: rawhide report: 20081113 changes
In-Reply-To: <20081113124307.5CB291F8258@releng2.fedora.phx.redhat.com>
References: <20081113124307.5CB291F8258@releng2.fedora.phx.redhat.com>
Message-ID: <1226601019.2514.1.camel@scrappy.miketc.net>

On Thu, 2008-11-13 at 12:43 +0000, Rawhide Report wrote:
> Compose started at Thu Nov 13 06:01:34 UTC 2008
> 
> Updated Packages:

Are these (and more?) going into F10 GA or just updates and may
eventually end up as those once the release is out?  

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



From tdiehl at rogueind.com  Thu Nov 13 18:12:28 2008
From: tdiehl at rogueind.com (Tom Diehl)
Date: Thu, 13 Nov 2008 13:12:28 -0500 (EST)
Subject: starting Fedora Server SIG
In-Reply-To: <1226596851.4714.58.camel@localhost.localdomain>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<491C5777.3090402@gmail.com>
	<1226596851.4714.58.camel@localhost.localdomain>
Message-ID: <alpine.LFD.2.00.0811131306000.32076@tigger.tntechs.com>

On Thu, 13 Nov 2008, Dan Williams wrote:

> I tend to think there will be a place for manual network configuration
> for a long time (no matter what jeremy says :), because there are some
> situations that are just too borderline to support in the short term, or
> are sufficiently borderline that the maintenance cost of adding the
> feature outweighs the benefit of the feature in the first place.
> There's always a tradeoff to feature addition.

I sure hope so. I routinely have an embedded device plugged into the Ethernet
port on my laptop and have wireless connected to the internal network. The
embedded devices do not always have a dhcp server on them. If I cannot configure
the network manually, now I cannot do my job.

NM in F9 handles this surprisingly well (Thank You). I hope no one decides 
to break this behavior because they do not happen to use this feature.

Just my $.02.

Regards,

-- 
Tom Diehl		tdiehl at rogueind.com		Spamtrap address mtd123 at rogueind.com



From galibert at pobox.com  Thu Nov 13 18:40:17 2008
From: galibert at pobox.com (Olivier Galibert)
Date: Thu, 13 Nov 2008 19:40:17 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <1226593505.4714.30.camel@localhost.localdomain>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<491C35C8.5060207@gmail.com>
	<20081113142041.GH24297@angus.ind.WPI.EDU>
	<1226588855.4714.10.camel@localhost.localdomain>
	<20081113152838.GA48391@dspnet.fr.eu.org>
	<1226593505.4714.30.camel@localhost.localdomain>
Message-ID: <20081113184017.GA71368@dspnet.fr.eu.org>

On Thu, Nov 13, 2008 at 11:25:05AM -0500, Dan Williams wrote:
> On Thu, 2008-11-13 at 16:28 +0100, Olivier Galibert wrote:
> > Static routes ?
> 
> Already there, in the connection editor see the "Routes..." button in
> the IPv4 tab.  Routes from ifcfg files aren't yet supported, but could
> be.  Routes from keyfile-based system connections (ie, prelogin) are
> supported.

Neat.  Is there a way to add them through a kickstart script in a
readable way?  And is the static ip/gw/dns information introduced at
install time kept by NM now?  In F8 NM trashes resolv.conf, dunno
about F9.

Nice to see NM seriously getting out of the way nowadays, kudos.

  OG.



From jkeating at redhat.com  Thu Nov 13 18:40:48 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 13 Nov 2008 10:40:48 -0800
Subject: rawhide report: 20081113 changes
In-Reply-To: <1226601019.2514.1.camel@scrappy.miketc.net>
References: <20081113124307.5CB291F8258@releng2.fedora.phx.redhat.com>
	<1226601019.2514.1.camel@scrappy.miketc.net>
Message-ID: <1226601648.5295.68.camel@luminos.localdomain>

On Thu, 2008-11-13 at 12:30 -0600, Mike Chambers wrote:
> 
> Are these (and more?) going into F10 GA or just updates and may
> eventually end up as those once the release is out?  

GA

-- 
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/20081113/fb37aaab/attachment.sig>

From caillon at redhat.com  Thu Nov 13 18:58:31 2008
From: caillon at redhat.com (Christopher Aillon)
Date: Thu, 13 Nov 2008 13:58:31 -0500
Subject: F8 EOL messaging
In-Reply-To: <20081112010144.GE8501@localhost.localdomain>
References: <20081112010144.GE8501@localhost.localdomain>
Message-ID: <491C78D7.1000209@redhat.com>

Paul W. Frields wrote:
> It seems really wrong to EOL F8 on Christmas Day.  Can we make that
> December 26th? :-)

I'd actually consider not having to support F8 and the old version of 
Firefox and stack a nice Christmas gift.  But that's just me...



From skvidal at fedoraproject.org  Thu Nov 13 19:01:13 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 13 Nov 2008 14:01:13 -0500 (EST)
Subject: F8 EOL messaging
In-Reply-To: <491C78D7.1000209@redhat.com>
References: <20081112010144.GE8501@localhost.localdomain>
	<491C78D7.1000209@redhat.com>
Message-ID: <alpine.LFD.2.00.0811131400520.19678@localhost.localdomain>



On Thu, 13 Nov 2008, Christopher Aillon wrote:

> Paul W. Frields wrote:
>> It seems really wrong to EOL F8 on Christmas Day.  Can we make that
>> December 26th? :-)
>
> I'd actually consider not having to support F8 and the old version of Firefox 
> and stack a nice Christmas gift.  But that's just me...
>

Wow talk about tough shopping for the guy  who has everything... ;)

-sv



From cra at WPI.EDU  Thu Nov 13 19:29:04 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 13 Nov 2008 14:29:04 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811131306000.32076@tigger.tntechs.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<491C5777.3090402@gmail.com>
	<1226596851.4714.58.camel@localhost.localdomain>
	<alpine.LFD.2.00.0811131306000.32076@tigger.tntechs.com>
Message-ID: <20081113192904.GP23749@angus.ind.WPI.EDU>

On Thu, Nov 13, 2008 at 01:12:28PM -0500, Tom Diehl wrote:
> On Thu, 13 Nov 2008, Dan Williams wrote:
>
>> I tend to think there will be a place for manual network configuration
>> for a long time (no matter what jeremy says :), because there are some
>> situations that are just too borderline to support in the short term, or
>> are sufficiently borderline that the maintenance cost of adding the
>> feature outweighs the benefit of the feature in the first place.
>> There's always a tradeoff to feature addition.
>
> I sure hope so. I routinely have an embedded device plugged into the Ethernet
> port on my laptop and have wireless connected to the internal network. The
> embedded devices do not always have a dhcp server on them. If I cannot configure
> the network manually, now I cannot do my job.
>
> NM in F9 handles this surprisingly well (Thank You). I hope no one 
> decides to break this behavior because they do not happen to use this 
> feature.


With NM managing both connections, it will alow both interfaces to be 
active at the same time.  One could have a static config that you can 
edit/change easily through the Connection Editor, while the other 
could be using DHCP.  In my experience with 2 ethernets in my desktop 
system , this works great as long as only one of the devices 
supplies/is configured with a default route.



From lesmikesell at gmail.com  Thu Nov 13 19:29:17 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 13 Nov 2008 13:29:17 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1226596851.4714.58.camel@localhost.localdomain>
References: <1226429441.3593.77.camel@eagle.danny.cz>	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>	<20081113134947.GF24297@angus.ind.WPI.EDU>	<20081113140153.GA1538120@hiwaay.net>	<1226588572.4714.4.camel@localhost.localdomain>	<20081113160203.GD1538120@hiwaay.net>	<1226592802.3651.30.camel@eagle.danny.cz>
	<491C5777.3090402@gmail.com>
	<1226596851.4714.58.camel@localhost.localdomain>
Message-ID: <491C800D.3010606@gmail.com>

Dan Williams wrote:
> 
>> Dan Hor?k wrote:
>>> Chris Adams p??e v ?t 13. 11. 2008 v 10:02 -0600:
>>>> Once upon a time, Dan Williams <dcbw at redhat.com> said:
>>>>> You can certainly disable NetworkManager and use manual configuration of
>>>>> your network devices.
>>>> For how long?  I thought I'd read that the plan was to use NM for
>>>> everything and eliminate /etc/init.d/network.
>>> We will keep/maintain /etc/init.d/network forever :-) They don't
>>> conflict, so there is no reason to completely drop the old method.
>> Who wins if they both want to set the default route and DNS servers? 
> 
> If two equal class devices (ethernet > wifi > mobile broadband) are
> capable of being the default route, the one detected earliest from HAL
> wins.

OK, what does HAL know about multi-homed servers?  And by the way, a 
common scenario with servers is to clone them with image copies.  How do 
I establish which interface is which when the drive boots in hardware 
that is identical except for the NIC mac addresses?

> The default device's DNS information gets added first, and each active
> device's DNS information is appended.

That sounds like the worst possible scenario.  I'd more likely want the 
latest device activated to be the first choice or not included at all, 
depending on what is really going on.

> Thus you can certainly get more
> than 3 nameservers in /etc/resolv.conf, but 3 is all that the glibc
> resolver allows. 

If these are dynamically added, are they tracked and removed as the 
corresponding interfaces go down?

> In the future we can resurrect caching nameserver to
> support split DNS, but that's based on _domain name_, not IP address, so
> the best solution there, by default (but allow manual override) is to
> use the DHCP-returned search domains (if any) as the domains to split
> DNS for.

There are too many possibilities to even guess at how to intertwine 
multiple DNS servers.  The main thing I'd want is a yes or no option on 
whether to install them if offered by DHCP.  The DNS servers themselves 
may need local zone files and forwarders specified for public lookups.

>> Chances are that if you have a working statically assigned interface you 
>> would not want to switch them to subsequent DHCP assigned NIC - but on 
>> the other hand if you bring up a VPN tunnel, you might.  And does NM 
> 
> Why's that?

My scenario is where servers have multiple NICs to talk to the direct 
neighbors on each subnet that intentionally don't route to each other or 
where you want to isolate the traffic.  For example, I run OpenNMS on an 
internal server that has static routing on the interfaces where I want 
it, but it also picks up a DHCP address from an otherwise isolated 
subnet so it can monitor those devices.  The DHCP server offers a 
default route and DNS servers but if those are installed, I can't reach 
my internal network.

>> know enough to drop routes through an interface that is physically down 
>> (no link, not ifdown) statically assigned or not?
> 
> If the interface is physically down, NM will deactivate the connection
> and addresses and routes get flushed.  Fine-grained modification of
> device parameters and configuration while the interface is
> down/disconnected isn't supported and likely won't be.

So you can alternate between several ethernet and wireless interfaces 
and as long as one is active everything will be happy?  That's not a 
typical server scenario, but a good thing to have.  Does route removal 
for down interface propagate so routing protocols (quagga) know to 
remove them from the advertised set?

> I tend to think there will be a place for manual network configuration
> for a long time (no matter what jeremy says :), because there are some
> situations that are just too borderline to support in the short term, or
> are sufficiently borderline that the maintenance cost of adding the
> feature outweighs the benefit of the feature in the first place.
> There's always a tradeoff to feature addition.

There is no way any software could guess the correct configuration for 
my multihomed machines and I don't think my dns servers could be 
automatically constructed either.  If you think otherwise, consider 
situations where everything is firewalled and you have a lot of wires 
connected.  But I'd be happy if I knew how to pre-configure some file 
that would be associated with a known interface when I swap disks among 
different servers or image copy and ship them out.

-- 
    Les Mikesell
      lesmikesell at gmail.com



From dominik at greysector.net  Thu Nov 13 20:26:09 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 13 Nov 2008 21:26:09 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <1226591572.22230.141.camel@code.and.org>
References: <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<1226591572.22230.141.camel@code.and.org>
Message-ID: <20081113202608.GA30171@mokona.greysector.net>

On Thursday, 13 November 2008 at 16:52, James Antill wrote:
> On Wed, 2008-11-12 at 14:07 -0600, Chris Adams wrote:
> 
> > Doing a "yum install kernel" from rawhide in an empty install root
> > gives:
> 
> [...]
> 
> > It looks like the dep chain to the X libraries is:
> > 
> > cairo requires libX11.so.6
> > plymouth-plugin-label requires libcairo.so.2
> 
>  This is probably a good time to repoint people to:
> 
> http://james.fedorapeople.org/yum/commands/pkg-deps-tree-view.py
> http://skvidal.fedorapeople.org/misc/pkg-provs-tree-view.py
> 
> ...which will take all the work/guessing out of this.

Or yum install rpmreaper. Great tool indeed.

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 cra at WPI.EDU  Thu Nov 13 20:33:33 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 13 Nov 2008 15:33:33 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <20081113202608.GA30171@mokona.greysector.net>
References: <778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<1226591572.22230.141.camel@code.and.org>
	<20081113202608.GA30171@mokona.greysector.net>
Message-ID: <20081113203333.GT23749@angus.ind.WPI.EDU>

On Thu, Nov 13, 2008 at 09:26:09PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Thursday, 13 November 2008 at 16:52, James Antill wrote:
> > On Wed, 2008-11-12 at 14:07 -0600, Chris Adams wrote:
> > 
> > > Doing a "yum install kernel" from rawhide in an empty install root
> > > gives:
> > 
> > [...]
> > 
> > > It looks like the dep chain to the X libraries is:
> > > 
> > > cairo requires libX11.so.6
> > > plymouth-plugin-label requires libcairo.so.2
> > 
> >  This is probably a good time to repoint people to:
> > 
> > http://james.fedorapeople.org/yum/commands/pkg-deps-tree-view.py
> > http://skvidal.fedorapeople.org/misc/pkg-provs-tree-view.py
> > 
> > ...which will take all the work/guessing out of this.
> 
> Or yum install rpmreaper. Great tool indeed.

Cool.  How do you type F1 from gnome-terminal such that the ncurses 
application can receive it?



From dominik at greysector.net  Thu Nov 13 20:44:41 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 13 Nov 2008 21:44:41 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <20081113203333.GT23749@angus.ind.WPI.EDU>
References: <5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<1226591572.22230.141.camel@code.and.org>
	<20081113202608.GA30171@mokona.greysector.net>
	<20081113203333.GT23749@angus.ind.WPI.EDU>
Message-ID: <20081113204441.GB30171@mokona.greysector.net>

On Thursday, 13 November 2008 at 21:33, Chuck Anderson wrote:
> On Thu, Nov 13, 2008 at 09:26:09PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> > On Thursday, 13 November 2008 at 16:52, James Antill wrote:
> > > On Wed, 2008-11-12 at 14:07 -0600, Chris Adams wrote:
> > > 
> > > > Doing a "yum install kernel" from rawhide in an empty install root
> > > > gives:
> > > 
> > > [...]
> > > 
> > > > It looks like the dep chain to the X libraries is:
> > > > 
> > > > cairo requires libX11.so.6
> > > > plymouth-plugin-label requires libcairo.so.2
> > > 
> > >  This is probably a good time to repoint people to:
> > > 
> > > http://james.fedorapeople.org/yum/commands/pkg-deps-tree-view.py
> > > http://skvidal.fedorapeople.org/misc/pkg-provs-tree-view.py
> > > 
> > > ...which will take all the work/guessing out of this.
> > 
> > Or yum install rpmreaper. Great tool indeed.
> 
> Cool.  How do you type F1 from gnome-terminal such that the ncurses 
> application can receive it?

Edit -> Keyboard Shortcuts -> scroll to the bottom, click the right side,
and tap Backspace to delete the binding. Or just use man rpmreaper from
another terminal.

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 cmadams at hiwaay.net  Thu Nov 13 21:09:03 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 13 Nov 2008 15:09:03 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1226593460.13077.91.camel@aglarond.local>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
Message-ID: <20081113210903.GG1538120@hiwaay.net>

Once upon a time, Jeremy Katz <katzj at redhat.com> said:
> On Thu, 2008-11-13 at 17:13 +0100, Dan Hor??k wrote:
> > Chris Adams p????e v ??t 13. 11. 2008 v 10:02 -0600:
> > > Once upon a time, Dan Williams <dcbw at redhat.com> said:
> > > > You can certainly disable NetworkManager and use manual configuration of
> > > > your network devices.
> > > 
> > > For how long?  I thought I'd read that the plan was to use NM for
> > > everything and eliminate /etc/init.d/network.
> > 
> > We will keep/maintain /etc/init.d/network forever :-) They don't
> > conflict, so there is no reason to completely drop the old method.
> 
> Sure there is.  Having multiple methods means more things that have to
> be tested, more things that have to be updated for system changes, etc.

That gets back to my previous question: why would I want one or more
daemons required for a static server configuration?  That is just more
things to break.  We already have udev, dbus, hald, and console-kit (I
have an F9 firewall where something starts console-kit; I don't know
what or why) for example, without any good docs about which can be
disabled and when; please don't add NM.

-- 
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 poelstra at redhat.com  Thu Nov 13 21:14:02 2008
From: poelstra at redhat.com (John Poelstra)
Date: Thu, 13 Nov 2008 13:14:02 -0800
Subject: Plan for tomorrows (20081112) FESCO meeting
In-Reply-To: <20081112090223.GA24778@amd.home.annexia.org>
References: <1226438839.26212.2.camel@kennedy>
	<4919FE3B.1070602@redhat.com>	<1226445382.3255.10.camel@kennedy>
	<20081112090223.GA24778@amd.home.annexia.org>
Message-ID: <491C989A.5070001@redhat.com>

Richard W.M. Jones wrote:
> On Tue, Nov 11, 2008 at 06:16:22PM -0500, Brian Pepple wrote:
>> On Tue, 2008-11-11 at 13:50 -0800, John Poelstra wrote:
>>> I would like to discuss 
>>> https://fedoraproject.org/wiki/Features/F11PolicyReview and propose that 
>>> FESCo start review Fedora 11 features next week, time permitting.
>> Added to the schedule.  Also, I don't think it will be a problem
>> starting the F11 feature reviews next week.
> 
> One of the proposed features is
> https://fedoraproject.org/wiki/Features/Windows_cross_compiler, but
> I'm not going to be around this evening to discuss it.  Next week is
> probably OK.
> 
> Rich.
> 

The page appears to be only partially complete and in Category: 
FeaturePageIncomplete

John



From sundaram at fedoraproject.org  Thu Nov 13 21:16:03 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 14 Nov 2008 02:46:03 +0530
Subject: Alpha, Beta, Snapshots, Preview and RC
Message-ID: <491C9913.9090409@fedoraproject.org>

Hi,

Is there a explanation of what a tester can expect from these 
milestones. I think we haven't communicate much of say, where the 
preview release stands in the grand scheme of release management.


Rahul



From notting at redhat.com  Thu Nov 13 21:47:31 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 13 Nov 2008 16:47:31 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <20081113210903.GG1538120@hiwaay.net>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
Message-ID: <20081113214731.GA4498@nostromo.devel.redhat.com>

Chris Adams (cmadams at hiwaay.net) said: 
> That gets back to my previous question: why would I want one or more
> daemons required for a static server configuration?  That is just more
> things to break.

Things NM gives you, as part of having that daemon (note: may not be
relevant to all usage cases, including desktops, servers, etc.):

- Consistently queryable for all various network settings, via dbus
  (as opposed to the conglomeration of ifconfig, ip, route, iwconfig,
  and 'cat <config file here>')
- Better scriptability of actions when you join and leave networks,
  links go up and down, etc. (netreport is not a good interface.)
- Support for both user-specific and system-wide configurations
- Sane WPA, mobile broadband, etc. support

This is above and beyond the GUI-related stuff, such as easily
switching between wireless networks, connection sharing, etc.

> We already have udev, dbus, hald, and console-kit (I
> have an F9 firewall where something starts console-kit; I don't know
> what or why) for example, without any good docs about which can be
> disabled and when; please don't add NM.

So, I'm not really sure what you mean here by 'we already have
udev'... after all, having device nodes is good. udev is also
the mechanism to load drivers on startup, which is obviously a
system requirement. It also provides a mechanism to run commands
on device initialization at startup, so it's used for things like
setting the clock, configuring the console, etc.

D-Bus is a systemwide IPC bus. It's not exactly interesting on its
own, but it's an underlying detail. The short answer is "if things
you need are linked against the dbus libraries, don't turn off
the daemon."

HAL is an interface for querying available hardware over the system;
it runs on top of d-bus. It's used by things like NetworkManager
and anaconda to enumerate devices, and by the desktop systems as the
underlying framework for handling PDAs, music players, hotpluggable
and removable devices, etc. It's also what parcels out suspend/resume
quirks for the pm-utils framework to read and use, and what's used
by X.org to detect input devices.

ConsoleKit is a d-bus available daemon that tracks 'sessions' (the
combination of a login and a 'seat' - a display/keyboard/mouse combo.)
It's done that way because just trawling through utmp isn't the most
reliable mechanism. It's used by GDM for tracking who's logged in and
providing shutdown/restart functionalty, and by HAL for implementing
device access for users logged in on the console.

Bill



From notting at redhat.com  Thu Nov 13 20:48:26 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 13 Nov 2008 15:48:26 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <1226592802.3651.30.camel@eagle.danny.cz>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
Message-ID: <20081113204826.GB3454@nostromo.devel.redhat.com>

Dan Hor?k (dan at danny.cz) said: 
> > For how long?  I thought I'd read that the plan was to use NM for
> > everything and eliminate /etc/init.d/network.
> 
> We will keep/maintain /etc/init.d/network forever :-) They don't
> conflict, so there is no reason to completely drop the old method.

That's like saying there's no reason to drop pam_console because it
doesn't conflict with ACLs on devices. There are always costs to maintaining
multiple interfaces to systems.

Bill



From notting at redhat.com  Thu Nov 13 20:45:12 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 13 Nov 2008 15:45:12 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <870180fe0811130733i43070df5q14d861f813db87d@mail.gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140019.GA3952@traged.atkac.englab.brq.redhat.com>
	<20081113141107.GG24297@angus.ind.WPI.EDU>
	<870180fe0811130733i43070df5q14d861f813db87d@mail.gmail.com>
Message-ID: <20081113204512.GA3454@nostromo.devel.redhat.com>

Jerry James (loganjerry at gmail.com) said: 
> Then could you tell me, please, how to fix an issue I've got with a
> server running F-9 that has a static IP address?  I've edited
> /etc/sysconfig/network-scripts/ifcfg-eth0.  It contains (among other
> settings):
> 
> DEVICE=eth0
> BOOTPROTO=none
> ONBOOT=yes
> NM_CONTROLLED=no
> IPADDR=xx.xx.xx.xx
> 
> Everything works fine *except* that ONBOOT=yes is not honored.

You need to either set NM_CONTROLLED to something other than 'no', or
enable the 'network' service. In either case, NM's static network
support is not your problem.

Bill



From skvidal at fedoraproject.org  Thu Nov 13 22:24:54 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 13 Nov 2008 17:24:54 -0500 (EST)
Subject: starting Fedora Server SIG
In-Reply-To: <20081113214731.GA4498@nostromo.devel.redhat.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
Message-ID: <alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>



On Thu, 13 Nov 2008, Bill Nottingham wrote:

> Chris Adams (cmadams at hiwaay.net) said:
>> That gets back to my previous question: why would I want one or more
>> daemons required for a static server configuration?  That is just more
>> things to break.
>
> Things NM gives you, as part of having that daemon (note: may not be
> relevant to all usage cases, including desktops, servers, etc.):
>
> - Consistently queryable for all various network settings, via dbus
>  (as opposed to the conglomeration of ifconfig, ip, route, iwconfig,
>  and 'cat <config file here>')
> - Better scriptability of actions when you join and leave networks,
>  links go up and down, etc. (netreport is not a good interface.)
> - Support for both user-specific and system-wide configurations
> - Sane WPA, mobile broadband, etc. support
>
> This is above and beyond the GUI-related stuff, such as easily
> switching between wireless networks, connection sharing, etc.

You might notice that all of the above are features that are good for
developers working on enhancing other software and good for desktop 
users but not so much features that a sysadmin worried only about keeping 
systems running and using as few resources as possible will care about.

Its just complexity where it isn't needed (in the case of a server).

-sv






From lesmikesell at gmail.com  Thu Nov 13 22:29:50 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 13 Nov 2008 16:29:50 -0600
Subject: Proposal: Rolling Release
In-Reply-To: <200811131301.mADD1gJm004624@laptop14.inf.utfsm.cl>
References: <16de708d0811101931i270af4d1ycf28eee723bce798@mail.gmail.com>
	<20081111204717.GB15724@orient.maison.lan>
	<4919F7C5.1090705@gmail.com>
	<1226439740.10458.15.camel@luminos.localdomain>
	<491A6E59.3070803@leemhuis.info> <491B0873.50503@gmail.com>
	<604aa7910811120851u361eac4sc4c05c2baf57fda4@mail.gmail.com>
	<491B145E.3020900@gmail.com>
	<604aa7910811120944r81e6b8bsc23ef3ef60d2bd69@mail.gmail.com>
	<491B19B6.40509@gmail.com>
	<604aa7910811121233l40705289q9478607a66762549@mail.gmail.com>
	<491B4E37.30706@gmail.com>
	<200811131301.mADD1gJm004624@laptop14.inf.utfsm.cl>
Message-ID: <491CAA5E.6040607@gmail.com>

Horst H. von Brand wrote:
> 
>>> Are you suggesting that we should never provide an unstable interface
>>> in any of the libraries or scripting modules that we package?
> 
>> No, I'm saying that necessary changes should be planned, and to the
>> extent possible, batched at version releases.
> 
> That means even more of the bureaucracy that people are so quick to
> disparage here...

But just regarding timing the move from rawhide to release, and it would 
be less arbitrary if the answer was always 'release at a version 
release' unless you are fixing something horribly broken as shipped.

>>                                                And where that isn't
>> possible, interface and command line changes to expect should be
>> published before the update so users and 3rd parties know how to work
>> around the breakage.
> 
> That isn't always obvious to the packager of some piece of infrastructure.
> Change GCC, the "normal" applications continue compiling fine (or get fixed
> as part of the update in the distributin), but some strange package
> somewhere was relying on a GCC bug (or misfeature, or sloppiness) and blows
> up when you try to build it. Has happened dozens of times to me, and I'm
> still grateful GCC moves forward and becomes more standards-conforming.

Being grateful it moves is one thing.  Being surprised when it regresses 
mid distro-version is something else.  The problem is that every update 
is not 'forward'.

> 
>> Who forces you to push interface-changing updates out of rawhide?
> 
> New upstream versions... go talk to them ;-)

That makes sense as a reason to go into rawhide.  Why do they have to go 
into production before a release point?

>>                                                                   If
>> I wanted today's bugs from an upstream project I'd grab it from there
>> instead of using a distribution's release version of the code.   The
>> fedora major release cycle is already fast enough anyway.
> 
> It is fast /because/ it integrates upstream changes as early as
> possible. Can't have fast advances and no change at the same time.

If you want rawhide you can run rawhide.  Otherwise what's so important 
that it can't wait for a release point?

>>                                                            If some
>> upstream project can't settle on an interface you are doing your users
>> a favor by keeping it away from them.
> 
> OK. Leave out the kernel, ...

If there were a nexenta-like flavor of fedora (our familiar userland on 
top of opensolaris) I'd certainly give it a shot.  Otherwise the 
overwhelming need to constrain and manage Linux kernel changes keeps 
several large corporations in business.

>>                                                    What I'd really
>> want is for LSB-compliance to someday get to the point where programs
>> running on Fedora would never need to know that it is fedora at all,
>> much less the version and last-update-date underneath.
> 
> LSB and similar standards mean aiming at the lowest common denominator.
> I.e., it might work just fine, but it will certainly waste much of what
> Fedora (or any other particular distribution) is all about

If people can't agree that the interfaces/libraries are the right way to 
do things, then there's a pretty good chance that they aren't, and that 
they will probably change or go away soon.  I don't have time to waste 
chasing a lot of things that are going to change and break underneath 
the things that might depend on them.

>> Is there someone involved in development that eats his own dog food
>> (i.e. uses fedora with current updates as infrastructure for some
>> large project or even in a lab setting with many users)?
> 
> I'm using Fedora rawhide daily. Our labs (several hundred users) are
> running latest Fedora most of the time (except when the releases fall at
> awkward times in our terms).

Do the users ever have things break because libraries changed under 
them?  Is this the sort of lab where work progresses over years or 
decades or where the universe is re-created every semester?  The latter 
doesn't exactly match the real world.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From notting at redhat.com  Thu Nov 13 22:32:42 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 13 Nov 2008 17:32:42 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
Message-ID: <20081113223242.GB4498@nostromo.devel.redhat.com>

Seth Vidal (skvidal at fedoraproject.org) said: 
>> - Consistently queryable for all various network settings, via dbus
>>  (as opposed to the conglomeration of ifconfig, ip, route, iwconfig,
>>  and 'cat <config file here>')
>> - Better scriptability of actions when you join and leave networks,
>>  links go up and down, etc. (netreport is not a good interface.)
>> - Support for both user-specific and system-wide configurations
>> - Sane WPA, mobile broadband, etc. support
>>
>> This is above and beyond the GUI-related stuff, such as easily
>> switching between wireless networks, connection sharing, etc.
>
> You might notice that all of the above are features that are good for
> developers working on enhancing other software and good for desktop  
> users but not so much features that a sysadmin worried only about keeping 
> systems running and using as few resources as possible will care about.

How is NM-dispatcher a developer service? Similarly, nm-tool is
at least quicker than 'ip addr ls ; ip route ls ; cat /etc/resolv.conf'.

As for resources... just to point out that NM (at least on my laptop)
uses 2.5MB resident... pretty much exactly the same amount as the 5
unused mingetty processes that many 'server' admins screamed needed to be
kept always.

Bill



From walters at verbum.org  Thu Nov 13 22:33:57 2008
From: walters at verbum.org (Colin Walters)
Date: Thu, 13 Nov 2008 17:33:57 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
Message-ID: <faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>

On Thu, Nov 13, 2008 at 5:24 PM, Seth Vidal <skvidal at fedoraproject.org> wrote:
>
> You might notice that all of the above are features that are good for
> developers working on enhancing other software and good for desktop users
> but not so much features that a sysadmin worried only about keeping systems
> running and using as few resources as possible will care about.

If any part of the core freedesktop.org stack uses an unreasonable
amount of memory, please file a bug and we will fix it.



From orion at cora.nwra.com  Thu Nov 13 22:47:31 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Thu, 13 Nov 2008 15:47:31 -0700
Subject: Macros in %files
Message-ID: <491CAE83.50303@cora.nwra.com>

I'm reworking my plplot.spec and seeing the following build failure:

Processing files: plplot-5.9.0-2.svn8985.fc11
+ exit 0
error: File must begin with "/": %{python_sitearch}/_plplotcmodule.so

spec has:

%{!?python_sitearch: %define python_sitearch %(%{__python} -c "from 
distutils.sysconfig import get_python_lib; print get_python_lib(1)")}

at the top, and then:

%files
%defattr(-,root,root,-)
%{_docdir}/plplot-%{version}/
%{_bindir}/plm2gif
%{_bindir}/plpr
%{_bindir}/pltek
%{_bindir}/pstex2eps
%{python_sitearch}/_plplotcmodule.so

This has always worked before.

Problems started showing up after I started using %bcond_without 
directives.  Any weirdness to watch out for there?

This is all in plplot/devel cvs.  scratch build:

http://koji.fedoraproject.org/koji/taskinfo?taskID=932396

-- 
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  Thu Nov 13 23:16:59 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 13 Nov 2008 17:16:59 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <20081113214731.GA4498@nostromo.devel.redhat.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>	<20081113134947.GF24297@angus.ind.WPI.EDU>	<20081113140153.GA1538120@hiwaay.net>	<1226588572.4714.4.camel@localhost.localdomain>	<20081113160203.GD1538120@hiwaay.net>	<1226592802.3651.30.camel@eagle.danny.cz>	<1226593460.13077.91.camel@aglarond.local>	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
Message-ID: <491CB56B.7090304@gmail.com>

Bill Nottingham wrote:
> 
> HAL is an interface for querying available hardware over the system;
> it runs on top of d-bus. It's used by things like NetworkManager
> and anaconda to enumerate devices, and by the desktop systems as the
> underlying framework for handling PDAs, music players, hotpluggable
> and removable devices, etc.

I'd really prefer my device names to be predictable.  That is, the NIC 
in the same motherboard or slot position gets the same eth? name across 
any number of identical machines, the same controller/cable/drive-select 
gets the same /dev/sd? name, etc.  Is there still any way to make that 
happen?

  > ConsoleKit is a d-bus available daemon that tracks 'sessions' (the
> combination of a login and a 'seat' - a display/keyboard/mouse combo.)
> It's done that way because just trawling through utmp isn't the most
> reliable mechanism. It's used by GDM for tracking who's logged in and
> providing shutdown/restart functionalty, and by HAL for implementing
> device access for users logged in on the console.

Anything tied to console logins is almost certainly wrong for unattended 
servers that may not have anything resembling a console, or unused if 
they do.

-- 
   Les Mikesell
    lesmikesell at gmail.com





From chasd at silveroaks.com  Thu Nov 13 23:25:30 2008
From: chasd at silveroaks.com (chasd)
Date: Thu, 13 Nov 2008 17:25:30 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <20081113221204.2C7CB61B6E5@hormel.redhat.com>
References: <20081113221204.2C7CB61B6E5@hormel.redhat.com>
Message-ID: <34927B51-A1D7-442F-849F-8A74C78FE8D0@silveroaks.com>


On Nov 13, 2008, at 4:12 PM, Bill N. wrote:

> D-Bus is a systemwide IPC bus. It's not exactly interesting on its
> own

<snip>

> HAL is an interface for querying available hardware over the system;
> it runs on top of d-bus.

<snip>

> ConsoleKit is a d-bus available daemon that tracks 'sessions'

Those three paragraphs did more to help me understand what those  
technologies are and how they interrelate than any other research I  
had consumed previously.

Thank you so very much.



-- 
Charles Dostale




From notting at redhat.com  Thu Nov 13 23:47:08 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 13 Nov 2008 18:47:08 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <491CB56B.7090304@gmail.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<491CB56B.7090304@gmail.com>
Message-ID: <20081113234708.GB6227@nostromo.devel.redhat.com>

Les Mikesell (lesmikesell at gmail.com) said: 
>> HAL is an interface for querying available hardware over the system;
>> it runs on top of d-bus. It's used by things like NetworkManager
>> and anaconda to enumerate devices, and by the desktop systems as the
>> underlying framework for handling PDAs, music players, hotpluggable
>> and removable devices, etc.
>
> I'd really prefer my device names to be predictable.  That is, the NIC  
> in the same motherboard or slot position gets the same eth? name across  
> any number of identical machines, the same controller/cable/drive-select  
> gets the same /dev/sd? name, etc.  Is there still any way to make that  
> happen?

By slot name or motherboard position? Not without custom udev rules,
at this point. The biggest issue is that disk devices you have actual
device nodes, so you can make as many /dev/disk/by-path or by-id or
by-label symlinks that you want, without affecting something that
wants to access it by another name.

Since network devices don't have actual backing device nodes, they
can only be accessed by a single name. Which makes grand unified
device naming schemes for network hard. (Not to mention that attempting
to get consistent motherboard or slot position out of BIOSes across
all manufacturers is a boatload of fun.)

>  > ConsoleKit is a d-bus available daemon that tracks 'sessions' (the
>> combination of a login and a 'seat' - a display/keyboard/mouse combo.)
>> It's done that way because just trawling through utmp isn't the most
>> reliable mechanism. It's used by GDM for tracking who's logged in and
>> providing shutdown/restart functionalty, and by HAL for implementing
>> device access for users logged in on the console.
>
> Anything tied to console logins is almost certainly wrong for unattended  
> servers that may not have anything resembling a console, or unused if  
> they do.

.... wrong? It's not 'wrong', in the same way that tcsh isn't wrong if
you're using bash. If someone's logged in on the console, it will be
recorded that way.

Bill



From martin.langhoff at gmail.com  Thu Nov 13 23:50:44 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Thu, 13 Nov 2008 18:50:44 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <1226588572.4714.4.camel@localhost.localdomain>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
Message-ID: <46a038f90811131550l34af2a88g45ab969cb5b85b82@mail.gmail.com>

On Thu, Nov 13, 2008 at 10:02 AM, Dan Williams <dcbw at redhat.com> wrote:
> You can certainly disable NetworkManager and use manual configuration of
> your network devices.

Correct. That's what we do for the OLPC School Server. NM is a good
fit for the XO laptop, but not so much for the server.

All you need to do is notinclude NM in your spin, and make sure the
chkconfig is told that the network service should be on. Works a
charm.

If/when NM is apt for server roles, I may reconsider, but you should
see the crazy network scripts I use - unless NM is as scriptable as
the oldstyle network scripts, I can't use it here.

In related new, I would really appreciate a few howtos on how to get
replace the desktop-oriented daemons with the old tools. For example,
right now there's console-kit-daemon running on my test School Server,
complaining about something.

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 jspaleta at gmail.com  Thu Nov 13 23:51:31 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 13 Nov 2008 14:51:31 -0900
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
Message-ID: <604aa7910811131551s74a418afv24a5a5401e5ba0bb@mail.gmail.com>

On Thu, Nov 13, 2008 at 1:24 PM, Seth Vidal <skvidal at fedoraproject.org> wrote:
> You might notice that all of the above are features that are good for
> developers working on enhancing other software and good for desktop users
> but not so much features that a sysadmin worried only about keeping systems
> running and using as few resources as possible will care about.
>
> Its just complexity where it isn't needed (in the case of a server).


I think dbus as a useful sysadmin tool is still relatively unexplored.
I think Nalin's oddjob concept could have gotten more attention and
feedback as a dbus based admin helper.

-jef



From notting at redhat.com  Thu Nov 13 23:52:50 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 13 Nov 2008 18:52:50 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <20081113234708.GB6227@nostromo.devel.redhat.com>
References: <20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<491CB56B.7090304@gmail.com>
	<20081113234708.GB6227@nostromo.devel.redhat.com>
Message-ID: <20081113235250.GC6227@nostromo.devel.redhat.com>

Bill Nottingham (notting at redhat.com) said: 
> (Not to mention that attempting
> to get consistent motherboard or slot position out of BIOSes across
> all manufacturers is a boatload of fun.)

So, we *do* at this point have the /sys/bus/pci/slots directory,
which is maintained by the ACPI PCI slot driver. But, just to give
an example -

On my laptop:
$ ls /sys/bus/pci/slots/
1

This corresponds to the expresscard slot, IIRC.

On a random (recent, Core2Duo) mid-tower:

$ ls /sys/bus/pci/slots/
<nothing>

despite the fact that the box actually has three slots. So, not only
does this not help with identifying onboard cards/adapters, for *actual*
slots, you're still at the whim of the ACPI bios authors to put the
info there.

Bill



From lesmikesell at gmail.com  Fri Nov 14 00:03:50 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 13 Nov 2008 18:03:50 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <604aa7910811131551s74a418afv24a5a5401e5ba0bb@mail.gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>	<20081113134947.GF24297@angus.ind.WPI.EDU>	<20081113140153.GA1538120@hiwaay.net>	<1226588572.4714.4.camel@localhost.localdomain>	<20081113160203.GD1538120@hiwaay.net>	<1226592802.3651.30.camel@eagle.danny.cz>	<1226593460.13077.91.camel@aglarond.local>	<20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<604aa7910811131551s74a418afv24a5a5401e5ba0bb@mail.gmail.com>
Message-ID: <491CC066.9000808@gmail.com>

Jeff Spaleta wrote:
> On Thu, Nov 13, 2008 at 1:24 PM, Seth Vidal <skvidal at fedoraproject.org> wrote:
>> You might notice that all of the above are features that are good for
>> developers working on enhancing other software and good for desktop users
>> but not so much features that a sysadmin worried only about keeping systems
>> running and using as few resources as possible will care about.
>>
>> Its just complexity where it isn't needed (in the case of a server).
> 
> 
> I think dbus as a useful sysadmin tool is still relatively unexplored.
> I think Nalin's oddjob concept could have gotten more attention and
> feedback as a dbus based admin helper.

Will ifconfig and route be modified internally to talk to dbus so the 
scripts and commands that have worked for eons continue to work?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From notting at redhat.com  Fri Nov 14 00:07:23 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 13 Nov 2008 19:07:23 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <491CC066.9000808@gmail.com>
References: <20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<604aa7910811131551s74a418afv24a5a5401e5ba0bb@mail.gmail.com>
	<491CC066.9000808@gmail.com>
Message-ID: <20081114000723.GA6635@nostromo.devel.redhat.com>

Les Mikesell (lesmikesell at gmail.com) said: 
> Will ifconfig and route be modified internally to talk to dbus so the  
> scripts and commands that have worked for eons continue to work?

I really don't know what you mean by this. For displaying devices,
addresses, and routes, they will work like they always have. If you
use it to change the configuration of a device out from under NetworkManager,
well, then you've causes your own issue. (Much like if you change 
the address out from whatever /etc/init.d/network configured it
as, actually.)

Bill



From martin.langhoff at gmail.com  Fri Nov 14 00:17:17 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Thu, 13 Nov 2008 19:17:17 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <604aa7910811131551s74a418afv24a5a5401e5ba0bb@mail.gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<604aa7910811131551s74a418afv24a5a5401e5ba0bb@mail.gmail.com>
Message-ID: <46a038f90811131617y4e33980cw20b4b1fd62903e57@mail.gmail.com>

On Thu, Nov 13, 2008 at 6:51 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> I think dbus as a useful sysadmin tool is still relatively unexplored.
> I think Nalin's oddjob concept could have gotten more attention and
> feedback as a dbus based admin helper.

Here at OLPC we use dbus quite a bit on the laptop side, and from a
server perspective... it sucks.

The key thing is that to have dbus listeners you have to have the
processes alive and running waiting for an interesting event. That's
just not efficient -- even if you have lots of hw, it's definitely not
smart use of your kit.

An excellent counterexample is incrond - I pass 'events' to scripts
using incrond's hooks into inotify. The scripts themselves are not
running, I only have one tiny tiny daemon listening. I can rig it to
handle thousands of specific different events and scripts, and still
the footprint is small (and if I monitor directories smartly, it
doesn't need to burden the kernel much either).

I tried to do the same thing with dbus. Right - every script had to be
running all the time. With any modern dynamic language, that's a ton
of RAM that goes to waste.

On the desktop side the same problem exists, but people unfortunately
care less - otherwise dbus wouldn't be so hot :-)

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 jspaleta at gmail.com  Fri Nov 14 00:24:37 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 13 Nov 2008 15:24:37 -0900
Subject: starting Fedora Server SIG
In-Reply-To: <46a038f90811131617y4e33980cw20b4b1fd62903e57@mail.gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<604aa7910811131551s74a418afv24a5a5401e5ba0bb@mail.gmail.com>
	<46a038f90811131617y4e33980cw20b4b1fd62903e57@mail.gmail.com>
Message-ID: <604aa7910811131624m69f8ae11v85c87f657659acfa@mail.gmail.com>

On Thu, Nov 13, 2008 at 3:17 PM, Martin Langhoff
<martin.langhoff at gmail.com> wrote:
> I tried to do the same thing with dbus. Right - every script had to be
> running all the time. With any modern dynamic language, that's a ton
> of RAM that goes to waste.

Did you look at oddjob for that?


-jef



From dbn.lists at gmail.com  Fri Nov 14 00:38:53 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Thu, 13 Nov 2008 16:38:53 -0800
Subject: Macros in %files
In-Reply-To: <491CAE83.50303@cora.nwra.com>
References: <491CAE83.50303@cora.nwra.com>
Message-ID: <91705d080811131638y32d60aa7rf73fadcdab05262f@mail.gmail.com>

On Thu, Nov 13, 2008 at 2:47 PM, Orion Poplawski <orion at cora.nwra.com> wrote:
> I'm reworking my plplot.spec and seeing the following build failure:
>
> Processing files: plplot-5.9.0-2.svn8985.fc11
> + exit 0
> error: File must begin with "/": %{python_sitearch}/_plplotcmodule.so
>
> spec has:
>
> %{!?python_sitearch: %define python_sitearch %(%{__python} -c "from
> distutils.sysconfig import get_python_lib; print get_python_lib(1)")}
>
> at the top, and then:
>
> %files
> %defattr(-,root,root,-)
> %{_docdir}/plplot-%{version}/
> %{_bindir}/plm2gif
> %{_bindir}/plpr
> %{_bindir}/pltek
> %{_bindir}/pstex2eps
> %{python_sitearch}/_plplotcmodule.so
>
> This has always worked before.
>
> Problems started showing up after I started using %bcond_without directives.

You can try adding %trace to the top of the spec file and see if
everything is expanding the way you'd expect.

--
Dan



From lesmikesell at gmail.com  Fri Nov 14 01:00:18 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 13 Nov 2008 19:00:18 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <20081114000723.GA6635@nostromo.devel.redhat.com>
References: <20081113140153.GA1538120@hiwaay.net>	<1226588572.4714.4.camel@localhost.localdomain>	<20081113160203.GD1538120@hiwaay.net>	<1226592802.3651.30.camel@eagle.danny.cz>	<1226593460.13077.91.camel@aglarond.local>	<20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>	<604aa7910811131551s74a418afv24a5a5401e5ba0bb@mail.gmail.com>	<491CC066.9000808@gmail.com>
	<20081114000723.GA6635@nostromo.devel.redhat.com>
Message-ID: <491CCDA2.4040801@gmail.com>

Bill Nottingham wrote:
> Les Mikesell (lesmikesell at gmail.com) said: 
>> Will ifconfig and route be modified internally to talk to dbus so the  
>> scripts and commands that have worked for eons continue to work?
> 
> I really don't know what you mean by this. For displaying devices,
> addresses, and routes, they will work like they always have. If you
> use it to change the configuration of a device out from under NetworkManager,
> well, then you've causes your own issue.

ifconfig has been the way to set/change addresses, netmasks, etc. since, 
well, forever.

> (Much like if you change 
> the address out from whatever /etc/init.d/network configured it
> as, actually.)

Those aren't bothered by on the fly changes - they just apply the saved 
settings the next time you boot or ifup/down.   I need to be able to do 
address/netmask/route changes, preferably by running the same commands 
as always.  And the stuff ethtool does too.  And I expect SNMP to report 
the same stuff under the same interface names.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From martin.langhoff at gmail.com  Fri Nov 14 01:10:52 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Thu, 13 Nov 2008 20:10:52 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <604aa7910811131624m69f8ae11v85c87f657659acfa@mail.gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<604aa7910811131551s74a418afv24a5a5401e5ba0bb@mail.gmail.com>
	<46a038f90811131617y4e33980cw20b4b1fd62903e57@mail.gmail.com>
	<604aa7910811131624m69f8ae11v85c87f657659acfa@mail.gmail.com>
Message-ID: <46a038f90811131710x5a552385l853cfa0255d697ab@mail.gmail.com>

On Thu, Nov 13, 2008 at 7:24 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Thu, Nov 13, 2008 at 3:17 PM, Martin Langhoff
> <martin.langhoff at gmail.com> wrote:
>> I tried to do the same thing with dbus. Right - every script had to be
>> running all the time. With any modern dynamic language, that's a ton
>> of RAM that goes to waste.
>
> Did you look at oddjob for that?

No - and the manpage isn't particularly helpful. I assume it could be
a replacement for incrond using dbus? Even if it was, inotify+files
seems far better than dbus messages:

 - The creation and move/rename events are very efficient and well
suited events to trigger actions.

 - Permissions fit the classic posix + ACL file/dir permission model
everyone understands.

 - Events can be handled synchronously or asynchronously (with old
fashioned cron). The message (file) does not go away.

 - The is minimal penalty if I'm dealing with large chunks of data.
The event handler can stream or mmap the file or do whatever crazy
efficient scheme it wants.

Initially, I wasn't so certain about incrond, but seeing dbus usage
and incrond usage over time... let's say that I'm not running to dbus
anytime soon ;-)

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 lesmikesell at gmail.com  Fri Nov 14 01:53:43 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 13 Nov 2008 19:53:43 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <20081113234708.GB6227@nostromo.devel.redhat.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>	<20081113134947.GF24297@angus.ind.WPI.EDU>	<20081113140153.GA1538120@hiwaay.net>	<1226588572.4714.4.camel@localhost.localdomain>	<20081113160203.GD1538120@hiwaay.net>	<1226592802.3651.30.camel@eagle.danny.cz>	<1226593460.13077.91.camel@aglarond.local>	<20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<491CB56B.7090304@gmail.com>
	<20081113234708.GB6227@nostromo.devel.redhat.com>
Message-ID: <491CDA27.7020300@gmail.com>

Bill Nottingham wrote:
>  
>>> HAL is an interface for querying available hardware over the system;
>>> it runs on top of d-bus. It's used by things like NetworkManager
>>> and anaconda to enumerate devices, and by the desktop systems as the
>>> underlying framework for handling PDAs, music players, hotpluggable
>>> and removable devices, etc.
>> I'd really prefer my device names to be predictable.  That is, the NIC  
>> in the same motherboard or slot position gets the same eth? name across  
>> any number of identical machines, the same controller/cable/drive-select  
>> gets the same /dev/sd? name, etc.  Is there still any way to make that  
>> happen?
> 
> By slot name or motherboard position? Not without custom udev rules,
> at this point. The biggest issue is that disk devices you have actual
> device nodes, so you can make as many /dev/disk/by-path or by-id or
> by-label symlinks that you want, without affecting something that
> wants to access it by another name.

Nearly all the machines I manage have hot-swap bays, and I want to mount 
the contents by a name related to its bay position which I know (or can 
easily be told over the phone), not by something related to the contents 
of the disk which I may not know when it is first put in place.  With 
old style scsi/sca drives this was nice and simple.   Newer machines 
with aacraid controllers already make this difficult by trying to 
logically map the newly inserted disk into the position where it was on 
some other machine.

> Since network devices don't have actual backing device nodes, they
> can only be accessed by a single name. Which makes grand unified
> device naming schemes for network hard. (Not to mention that attempting
> to get consistent motherboard or slot position out of BIOSes across
> all manufacturers is a boatload of fun.)
> 
>>  > ConsoleKit is a d-bus available daemon that tracks 'sessions' (the
>>> combination of a login and a 'seat' - a display/keyboard/mouse combo.)
>>> It's done that way because just trawling through utmp isn't the most
>>> reliable mechanism. It's used by GDM for tracking who's logged in and
>>> providing shutdown/restart functionalty, and by HAL for implementing
>>> device access for users logged in on the console.
>> Anything tied to console logins is almost certainly wrong for unattended  
>> servers that may not have anything resembling a console, or unused if  
>> they do.
> 
> .... wrong? It's not 'wrong', in the same way that tcsh isn't wrong if
> you're using bash. If someone's logged in on the console, it will be
> recorded that way.

It's wrong if you need someone at the console to start anything on a 
server and wrong if someone logging in at the console can affect 
anything the server is already doing - even things like playing audio.

-- 
    Les Mikesell
      lesmikesell at gmail.com



From cmadams at hiwaay.net  Fri Nov 14 01:59:38 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 13 Nov 2008 19:59:38 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <20081113223242.GB4498@nostromo.devel.redhat.com>
References: <20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
Message-ID: <20081114015938.GA1418333@hiwaay.net>

Once upon a time, Bill Nottingham <notting at redhat.com> said:
> How is NM-dispatcher a developer service? Similarly, nm-tool is
> at least quicker than 'ip addr ls ; ip route ls ; cat /etc/resolv.conf'.

Funny; when I opened my notebook just now, hald segfaulted and died and
NM died for some unknown reason.  Because of that, nm-tool was useless,
but ifconfig still worked.

The output of nm-tool is also not particularly parseable with a script,
while ip has a good clean list.

How would a system admin even configure NM?  Where do I go to add an
alias, a new route, or a new GRE tunnel?

> As for resources... just to point out that NM (at least on my laptop)
> uses 2.5MB resident... pretty much exactly the same amount as the 5
> unused mingetty processes that many 'server' admins screamed needed to be
> kept always.

I turn off unused gettys anyway, but that's not what I'm concerned
about.  The more daemons I have to have running, the more bugs that can
break things, the more possible security issues there are, etc.

How is a daemon (or set of daemons) useful for a static configuration
that does not change?  For the vast majority of my servers, the network
config is set in the kickstart %post and not touched for the life of the
server (which is typically many years; I've got a RHEL 3 server that
hasn't had a network change since Feb 2004 for example).

For servers, the simpler solution (that meets the needs) is always
better, and running multiple daemons to configure the network is
definately not simpler than a text file and "ifup".

-- 
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 csnook at redhat.com  Fri Nov 14 02:32:35 2008
From: csnook at redhat.com (Chris Snook)
Date: Thu, 13 Nov 2008 21:32:35 -0500
Subject: a trivial fix makes a big change
In-Reply-To: <385866f0811130738s67a1be18r858313887b4e02d8@mail.gmail.com>
References: <385866f0811121507y228eb82egb77544b3edccae3f@mail.gmail.com>	<491B70A4.6090102@fedoraproject.org>
	<385866f0811130738s67a1be18r858313887b4e02d8@mail.gmail.com>
Message-ID: <491CE343.9050303@redhat.com>

Muayyad AlSadi wrote:
>> You can volunteer to maintain it.
> I proposed to for a packager in FAS but I'm still waiting for the acceptance
> 
>> The RPM philosophy is that installation and configuration should be separate activities.  There
> good policy
> yes but the rpm already ships with a config file
> 
> rpm -qf /etc/samba/smb.conf
> samba-common-3.2.4-0.22.fc10.i386

Yes, and the configuration file is owned by *one* package.  When multiple 
packages try to own the same file, very bad things happen, as evidenced by this 
incident:

http://it.slashdot.org/article.pl?sid=08/07/18/1210257

> so I ask for that file in that package to be modified to have a line like this
> 
> usershare path = /var/lib/samba/usershare
> 
> BTW: I forget that we have system-config-samba
> 
> we can put a checkbox [ ]  enable nautilus-share
> 

That's exactly how we should do it.

-- Chris



From jonathan at jonmasters.org  Fri Nov 14 03:31:53 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Thu, 13 Nov 2008 22:31:53 -0500
Subject: db-compat
In-Reply-To: <1226600409.15313.1.camel@arekh.okg>
References: <1226293343.30170.4.camel@jcmlaptop>
	<20081110171712.GH8850@nostromo.devel.redhat.com>
	<1226351611.18109.15.camel@londonpacket.bos.redhat.com>
	<20081110213030.GB13633@nostromo.devel.redhat.com>
	<4918B44D.4050904@nobugconsulting.ro>
	<1226380574.23813.5.camel@perihelion.int.jonmasters.org>
	<1226395109.26647.30.camel@arekh.okg>
	<1226600115.8114.15.camel@perihelion.int.jonmasters.org>
	<1226600409.15313.1.camel@arekh.okg>
Message-ID: <1226633513.8114.85.camel@perihelion.int.jonmasters.org>

On Thu, 2008-11-13 at 19:20 +0100, Nicolas Mailhot wrote:
> Le jeudi 13 novembre 2008 ? 13:15 -0500, Jon Masters a ?crit :
> 
> > > Bad service from ISVs that do proprietary software, nothing less.
> > 
> > Cool. Let's blame the non-Free sofrware ISVs at every turn!
> > 
> > (sorry, overly sarky email...nothing personal, just in that kind of
> > mood, probably too much decaf coffee...)
> 
> For the record, I spent 4 years of my life working at a Linux ISV.

Yeah. I get it. Still, I wonder if there's a need for a policy on this
stuff - or if in fact, there is one and I don't know about it :)

Jon.





From walters at verbum.org  Fri Nov 14 03:36:09 2008
From: walters at verbum.org (Colin Walters)
Date: Thu, 13 Nov 2008 22:36:09 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <46a038f90811131617y4e33980cw20b4b1fd62903e57@mail.gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<604aa7910811131551s74a418afv24a5a5401e5ba0bb@mail.gmail.com>
	<46a038f90811131617y4e33980cw20b4b1fd62903e57@mail.gmail.com>
Message-ID: <faa16b610811131936h508234a0s104e720fdae25eab@mail.gmail.com>

On Thu, Nov 13, 2008 at 7:17 PM, Martin Langhoff
<martin.langhoff at gmail.com> wrote:
>
> Here at OLPC we use dbus quite a bit on the laptop side, and from a
> server perspective... it sucks.

No one has ever said dbus is appropriate for everything - you didn't
give any details of what you're doing, but there are plenty of things
it *doesn't* make sense to use dbus for, or at least there are better
choices.  However, it is very appropriate for implementing long
running core system services, because that's what it was designed for.



From stickster at gmail.com  Fri Nov 14 04:22:13 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Thu, 13 Nov 2008 23:22:13 -0500
Subject: F8 EOL messaging
In-Reply-To: <alpine.LFD.2.00.0811131400520.19678@localhost.localdomain>
References: <20081112010144.GE8501@localhost.localdomain>
	<491C78D7.1000209@redhat.com>
	<alpine.LFD.2.00.0811131400520.19678@localhost.localdomain>
Message-ID: <20081114042213.GA27370@localhost.localdomain>

On Thu, Nov 13, 2008 at 02:01:13PM -0500, Seth Vidal wrote:
> On Thu, 13 Nov 2008, Christopher Aillon wrote:
>
>> Paul W. Frields wrote:
>>> It seems really wrong to EOL F8 on Christmas Day.  Can we make that
>>> December 26th? :-)
>>
>> I'd actually consider not having to support F8 and the old version of 
>> Firefox and stack a nice Christmas gift.  But that's just me...
>>
>
> Wow talk about tough shopping for the guy  who has everything... ;)

So is a late Christmas present OK for you then, Chris? ;-)

+1 to January 5th, 2009.

-- 
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/20081113/5425e81d/attachment.sig>

From rdieter at math.unl.edu  Fri Nov 14 05:05:50 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 13 Nov 2008 23:05:50 -0600
Subject: Macros in %files
References: <491CAE83.50303@cora.nwra.com>
	<91705d080811131638y32d60aa7rf73fadcdab05262f@mail.gmail.com>
Message-ID: <gfivov$ank$1@ger.gmane.org>

Dan Nicholson wrote:

> On Thu, Nov 13, 2008 at 2:47 PM, Orion Poplawski <orion at cora.nwra.com>
> wrote:
>> I'm reworking my plplot.spec and seeing the following build failure:
>>
>> Processing files: plplot-5.9.0-2.svn8985.fc11
>> + exit 0
>> error: File must begin with "/": %{python_sitearch}/_plplotcmodule.so
>>
>> spec has:
>>
>> %{!?python_sitearch: %define python_sitearch %(%{__python} -c "from
>> distutils.sysconfig import get_python_lib; print get_python_lib(1)")}

Take out the space between : %define

-- Rex



From skvidal at fedoraproject.org  Fri Nov 14 05:15:45 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 14 Nov 2008 00:15:45 -0500 (EST)
Subject: F8 EOL messaging
In-Reply-To: <20081114042213.GA27370@localhost.localdomain>
References: <20081112010144.GE8501@localhost.localdomain>
	<491C78D7.1000209@redhat.com>
	<alpine.LFD.2.00.0811131400520.19678@localhost.localdomain>
	<20081114042213.GA27370@localhost.localdomain>
Message-ID: <alpine.LFD.2.00.0811140014000.19678@localhost.localdomain>

On Thu, 13 Nov 2008, Paul W. Frields wrote:

> On Thu, Nov 13, 2008 at 02:01:13PM -0500, Seth Vidal wrote:
>> On Thu, 13 Nov 2008, Christopher Aillon wrote:
>>
>>> Paul W. Frields wrote:
>>>> It seems really wrong to EOL F8 on Christmas Day.  Can we make that
>>>> December 26th? :-)
>>>
>>> I'd actually consider not having to support F8 and the old version of
>>> Firefox and stack a nice Christmas gift.  But that's just me...
>>>
>>
>> Wow talk about tough shopping for the guy  who has everything... ;)
>
> So is a late Christmas present OK for you then, Chris? ;-)
>
> +1 to January 5th, 2009.
>

which really just means they get updates until dec 23rd b/c no one is 
going to do any substantive work until after the holidays are good and 
gone.

seriously...

-sv



From orion at cora.nwra.com  Fri Nov 14 05:17:23 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Thu, 13 Nov 2008 22:17:23 -0700 (MST)
Subject: Macros in %files
In-Reply-To: <gfivov$ank$1@ger.gmane.org>
References: <491CAE83.50303@cora.nwra.com>
	<91705d080811131638y32d60aa7rf73fadcdab05262f@mail.gmail.com>
	<gfivov$ank$1@ger.gmane.org>
Message-ID: <2149.71.208.51.222.1226639843.squirrel@www.cora.nwra.com>


On Thu, November 13, 2008 10:05 pm, Rex Dieter wrote:
> Dan Nicholson wrote:
>
>> On Thu, Nov 13, 2008 at 2:47 PM, Orion Poplawski <orion at cora.nwra.com>
>> wrote:
>>> I'm reworking my plplot.spec and seeing the following build failure:
>>>
>>> Processing files: plplot-5.9.0-2.svn8985.fc11
>>> + exit 0
>>> error: File must begin with "/": %{python_sitearch}/_plplotcmodule.so
>>>
>>> spec has:
>>>
>>> %{!?python_sitearch: %define python_sitearch %(%{__python} -c "from
>>> distutils.sysconfig import get_python_lib; print get_python_lib(1)")}
>
> Take out the space between : %define

No help.

-- 
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 Nov 14 05:19:51 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Thu, 13 Nov 2008 22:19:51 -0700 (MST)
Subject: Macros in %files
In-Reply-To: <91705d080811131638y32d60aa7rf73fadcdab05262f@mail.gmail.com>
References: <491CAE83.50303@cora.nwra.com>
	<91705d080811131638y32d60aa7rf73fadcdab05262f@mail.gmail.com>
Message-ID: <2167.71.208.51.222.1226639991.squirrel@www.cora.nwra.com>


On Thu, November 13, 2008 5:38 pm, Dan Nicholson wrote:
> You can try adding %trace to the top of the spec file and see if
> everything is expanding the way you'd expect.

Log here:

http://koji.fedoraproject.org/koji/getfile?taskID=933170&name=build.log

if anyone can make sense of it....

-- 
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 jonstanley at gmail.com  Fri Nov 14 05:21:52 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Fri, 14 Nov 2008 00:21:52 -0500
Subject: F8 EOL messaging
In-Reply-To: <alpine.LFD.2.00.0811140014000.19678@localhost.localdomain>
References: <20081112010144.GE8501@localhost.localdomain>
	<491C78D7.1000209@redhat.com>
	<alpine.LFD.2.00.0811131400520.19678@localhost.localdomain>
	<20081114042213.GA27370@localhost.localdomain>
	<alpine.LFD.2.00.0811140014000.19678@localhost.localdomain>
Message-ID: <da159fda0811132121q6b8df6a6u583fc74479251371@mail.gmail.com>

On Fri, Nov 14, 2008 at 12:15 AM, Seth Vidal <skvidal at fedoraproject.org> wrote:

> which really just means they get updates until dec 23rd b/c no one is going
> to do any substantive work until after the holidays are good and gone.

Oh, definitely agreed. More a matter of when someone's around to do
the last push, and when RHT eng-ops is around to do the attendant
bugzilla activities.



From mtasaka at ioa.s.u-tokyo.ac.jp  Fri Nov 14 05:36:31 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Fri, 14 Nov 2008 14:36:31 +0900
Subject: Macros in %files
In-Reply-To: <491CAE83.50303@cora.nwra.com>
References: <491CAE83.50303@cora.nwra.com>
Message-ID: <491D0E5F.3030604@ioa.s.u-tokyo.ac.jp>

Orion Poplawski wrote, at 11/14/2008 07:47 AM +9:00:
> I'm reworking my plplot.spec and seeing the following build failure:
> 
> Processing files: plplot-5.9.0-2.svn8985.fc11
> + exit 0
> error: File must begin with "/": %{python_sitearch}/_plplotcmodule.so
> 
> spec has:
> 
> %{!?python_sitearch: %define python_sitearch %(%{__python} -c "from 
> distutils.sysconfig import get_python_lib; print get_python_lib(1)")}
> 
> at the top, and then:

Changing to %{!?python_sitearch: %global python_....}
works?

Regards,
Mamoru



From orion at cora.nwra.com  Fri Nov 14 05:50:04 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Thu, 13 Nov 2008 22:50:04 -0700 (MST)
Subject: Macros in %files
In-Reply-To: <491D0E5F.3030604@ioa.s.u-tokyo.ac.jp>
References: <491CAE83.50303@cora.nwra.com>
	<491D0E5F.3030604@ioa.s.u-tokyo.ac.jp>
Message-ID: <2383.71.208.51.222.1226641804.squirrel@www.cora.nwra.com>


On Thu, November 13, 2008 10:36 pm, Mamoru Tasaka wrote:
>
> Changing to %{!?python_sitearch: %global python_....}
> works?

That's the ticket.  Some rpm change I guess I didn't quite pick up on...

Thank you!

-- 
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 Nov 14 06:09:45 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Thu, 13 Nov 2008 23:09:45 -0700 (MST)
Subject: Network Manager - good and still needs work
In-Reply-To: <20081113214731.GA4498@nostromo.devel.redhat.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
Message-ID: <2525.71.208.51.222.1226642985.squirrel@www.cora.nwra.com>


On Thu, November 13, 2008 2:47 pm, Bill Nottingham wrote:
> Things NM gives you, as part of having that daemon (note: may not be
> relevant to all usage cases, including desktops, servers, etc.):
>
[...]
> - Better scriptability of actions when you join and leave networks,
>   links go up and down, etc. (netreport is not a good interface.)

Still need a pre-down script run. 
https://bugzilla.redhat.com/show_bug.cgi?id=354341

Note that I'm really getting to like NM.  Just can't resist a chance to
plug my particular itch.  Also, I think NM may need to delay the
suspend/hibernate sequence a bit more for scripts to complete, but that
needs more investigation....


-- 
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 skvidal at fedoraproject.org  Fri Nov 14 06:24:20 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 14 Nov 2008 01:24:20 -0500 (EST)
Subject: starting Fedora Server SIG
In-Reply-To: <20081113223242.GB4498@nostromo.devel.redhat.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
Message-ID: <alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>



On Thu, 13 Nov 2008, Bill Nottingham wrote:

>
> How is NM-dispatcher a developer service? Similarly, nm-tool is
> at least quicker than 'ip addr ls ; ip route ls ; cat /etc/resolv.conf'.

and ifconfig -a works on multiple platforms, so it's the one that will 
win.


> As for resources... just to point out that NM (at least on my laptop)
> uses 2.5MB resident... pretty much exactly the same amount as the 5
> unused mingetty processes that many 'server' admins screamed needed to be
> kept always.


nm, dbus in particular:
dbus: 3M
NM: 17M here

that's 20M vs 9M total for all the gettys running here.

And I don't have to run the gettys, I'd have to run NM.

Look, for the desktop in particular NM makes a lot of sense, I am not 
arguing otherwise.

For the server it is a solution looking for a problem.

The reaction you're seeing is people who don't care about the desktop 
trying to figure out why desktop and/or developer oriented features are 
causing them to have to change their server deployment/config habits.

You can't tell me you're surprised by the pushback, Bill.

-sv




From skvidal at fedoraproject.org  Fri Nov 14 06:26:20 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 14 Nov 2008 01:26:20 -0500 (EST)
Subject: starting Fedora Server SIG
In-Reply-To: <20081114015938.GA1418333@hiwaay.net>
References: <20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<20081114015938.GA1418333@hiwaay.net>
Message-ID: <alpine.LFD.2.00.0811140125280.19678@localhost.localdomain>



On Thu, 13 Nov 2008, Chris Adams wrote:

> I turn off unused gettys anyway, but that's not what I'm concerned
> about.  The more daemons I have to have running, the more bugs that can
> break things, the more possible security issues there are, etc.

I believe the quote you're looking for here is:
"The only line of code that's bug free is the line you didn't write."

The mantra of the less code movement, I think.

-sv



From skvidal at fedoraproject.org  Fri Nov 14 06:30:24 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 14 Nov 2008 01:30:24 -0500 (EST)
Subject: starting Fedora Server SIG
In-Reply-To: <faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>
Message-ID: <alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>



On Thu, 13 Nov 2008, Colin Walters wrote:

> On Thu, Nov 13, 2008 at 5:24 PM, Seth Vidal <skvidal at fedoraproject.org> wrote:
>>
>> You might notice that all of the above are features that are good for
>> developers working on enhancing other software and good for desktop users
>> but not so much features that a sysadmin worried only about keeping systems
>> running and using as few resources as possible will care about.
>
> If any part of the core freedesktop.org stack uses an unreasonable
> amount of memory, please file a bug and we will fix it.

It uses ANY memory. That's more than is reasonable considering that the 
former solution (ifconfig) uses none.

Colin, let me very clear, I think what NM does for the desktop is very 
good, indeed.  I like not having to fiddle around to make WEP stuff work 
using iwconfig anymore. I appreciate what's been achieved.

That doesn't make it a more useful thing on a server.


  -sv



From jamundso at gmail.com  Fri Nov 14 06:34:39 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Fri, 14 Nov 2008 00:34:39 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>
	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>
Message-ID: <6d06ce20811132234l3581cc39re3577707ebda7d3f@mail.gmail.com>

On Fri, Nov 14, 2008 at 12:30 AM, Seth Vidal <skvidal at fedoraproject.org> wrote:
>
> On Thu, 13 Nov 2008, Colin Walters wrote:
>
>> On Thu, Nov 13, 2008 at 5:24 PM, Seth Vidal <skvidal at fedoraproject.org>
>> wrote:
>>>
>>> You might notice that all of the above are features that are good for
>>> developers working on enhancing other software and good for desktop users
>>> but not so much features that a sysadmin worried only about keeping
>>> systems
>>> running and using as few resources as possible will care about.
>>
>> If any part of the core freedesktop.org stack uses an unreasonable
>> amount of memory, please file a bug and we will fix it.
>
> It uses ANY memory. That's more than is reasonable considering that the
> former solution (ifconfig) uses none.
>
> Colin, let me very clear, I think what NM does for the desktop is very good,
> indeed.  I like not having to fiddle around to make WEP stuff work using
> iwconfig anymore. I appreciate what's been achieved.
>
> That doesn't make it a more useful thing on a server.

+1

jerry

-- 
There's plenty of youth in America - it's time we find the "fountain of smart".



From dan at danny.cz  Fri Nov 14 06:43:10 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Fri, 14 Nov 2008 07:43:10 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <20081114015938.GA1418333@hiwaay.net>
References: <20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<20081114015938.GA1418333@hiwaay.net>
Message-ID: <1226644990.3639.9.camel@eagle.danny.cz>


Chris Adams p??e v ?t 13. 11. 2008 v 19:59 -0600:

> How is a daemon (or set of daemons) useful for a static configuration
> that does not change?  For the vast majority of my servers, the network
> config is set in the kickstart %post and not touched for the life of the
> server (which is typically many years; I've got a RHEL 3 server that
> hasn't had a network change since Feb 2004 for example).
> 
> For servers, the simpler solution (that meets the needs) is always
> better, and running multiple daemons to configure the network is
> definately not simpler than a text file and "ifup".

That's 100% true and maintaining "/etc/init.d/network" for the future
will be our SIG's job. When there is a "link down" event on the server
then you call the network administrator :-)


		Dan



From kevin.kofler at chello.at  Fri Nov 14 06:45:46 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 14 Nov 2008 07:45:46 +0100
Subject: F8 EOL messaging
References: <20081112010144.GE8501@localhost.localdomain>
	<491C78D7.1000209@redhat.com>
	<alpine.LFD.2.00.0811131400520.19678@localhost.localdomain>
	<20081114042213.GA27370@localhost.localdomain>
	<alpine.LFD.2.00.0811140014000.19678@localhost.localdomain>
Message-ID: <gfj6qr$ocv$1@ger.gmane.org>

Seth Vidal wrote:
> which really just means they get updates until dec 23rd b/c no one is
> going to do any substantive work until after the holidays are good and
> gone.

Don't say "no one". I could very well be queuing up some updates in those 2
weeks. How about Dolphin from KDE 4.1.4 (and kdelibs4, kdepimlibs and
kdebase-runtime too)? :-) Or maybe fixes for some bugs which come up to fix
before EOL? I'm ready to build stuff over the holiday period in any case,
it wouldn't be a first:
https://www.redhat.com/archives/fedora-extras-commits/2007-December/msg06158.html
https://www.redhat.com/archives/fedora-extras-commits/2007-December/msg06159.html
https://www.redhat.com/archives/fedora-extras-commits/2007-December/msg06235.html
https://www.redhat.com/archives/fedora-extras-commits/2007-December/msg06236.html
https://www.redhat.com/archives/fedora-extras-commits/2007-December/msg06243.html
https://www.redhat.com/archives/fedora-extras-commits/2007-December/msg06725.html
https://www.redhat.com/archives/fedora-extras-commits/2007-December/msg06908.html
https://www.redhat.com/archives/fedora-extras-commits/2007-December/msg06995.html
https://www.redhat.com/archives/fedora-extras-commits/2007-December/msg06996.html
https://www.redhat.com/archives/fedora-extras-commits/2007-December/msg06998.html
https://www.redhat.com/archives/fedora-extras-commits/2008-January/msg00284.html
https://www.redhat.com/archives/fedora-extras-commits/2008-January/msg00285.html
https://www.redhat.com/archives/fedora-extras-commits/2008-January/msg00286.html
https://www.redhat.com/archives/fedora-extras-commits/2008-January/msg00287.html
https://www.redhat.com/archives/fedora-extras-commits/2008-January/msg00573.html
https://www.redhat.com/archives/fedora-extras-commits/2008-January/msg00598.html
https://www.redhat.com/archives/fedora-extras-commits/2008-January/msg00806.html
https://www.redhat.com/archives/fedora-extras-commits/2008-January/msg00807.html
https://www.redhat.com/archives/fedora-extras-commits/2008-January/msg00865.html
https://www.redhat.com/archives/fedora-extras-commits/2008-January/msg01097.html
https://www.redhat.com/archives/fedora-extras-commits/2008-January/msg01101.html
:-)

        Kevin Kofler



From skvidal at fedoraproject.org  Fri Nov 14 06:51:33 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 14 Nov 2008 01:51:33 -0500 (EST)
Subject: F8 EOL messaging
In-Reply-To: <gfj6qr$ocv$1@ger.gmane.org>
References: <20081112010144.GE8501@localhost.localdomain>
	<491C78D7.1000209@redhat.com>
	<alpine.LFD.2.00.0811131400520.19678@localhost.localdomain>
	<20081114042213.GA27370@localhost.localdomain>
	<alpine.LFD.2.00.0811140014000.19678@localhost.localdomain>
	<gfj6qr$ocv$1@ger.gmane.org>
Message-ID: <alpine.LFD.2.00.0811140150280.26126@localhost.localdomain>



On Fri, 14 Nov 2008, Kevin Kofler wrote:

> Seth Vidal wrote:
>> which really just means they get updates until dec 23rd b/c no one is
>> going to do any substantive work until after the holidays are good and
>> gone.
>
> Don't say "no one". I could very well be queuing up some updates in those 2
> weeks. How about Dolphin from KDE 4.1.4 (and kdelibs4, kdepimlibs and
> kdebase-runtime too)? :-) Or maybe fixes for some bugs which come up to fix
> before EOL? I'm ready to build stuff over the holiday period in any case,
> it wouldn't be a first:

Great, so you'll release them just to annoy the sysadmins out there who 
now have to test and apply them when they'd normally be spending time with 
family and friends?

There are very few people benefited by releasing updates over the 
holidays. Not zero, but very few.

-sv



From jspaleta at gmail.com  Fri Nov 14 07:02:50 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 13 Nov 2008 22:02:50 -0900
Subject: F8 EOL messaging
In-Reply-To: <alpine.LFD.2.00.0811140150280.26126@localhost.localdomain>
References: <20081112010144.GE8501@localhost.localdomain>
	<491C78D7.1000209@redhat.com>
	<alpine.LFD.2.00.0811131400520.19678@localhost.localdomain>
	<20081114042213.GA27370@localhost.localdomain>
	<alpine.LFD.2.00.0811140014000.19678@localhost.localdomain>
	<gfj6qr$ocv$1@ger.gmane.org>
	<alpine.LFD.2.00.0811140150280.26126@localhost.localdomain>
Message-ID: <604aa7910811132302q38d2a14eq722a96a24acbb192@mail.gmail.com>

On Thu, Nov 13, 2008 at 9:51 PM, Seth Vidal <skvidal at fedoraproject.org> wrote:
> Great, so you'll release them just to annoy the sysadmins out there who now
> have to test and apply them when they'd normally be spending time with
> family and friends?
>
> There are very few people benefited by releasing updates over the holidays.
> Not zero, but very few.

But aren't vacations of this sort an opportunity for volunteers to
spend more time on Fedora exactly because they have more free time
then?
Do people work on Fedora as a job or as a hobby. Do they work during
free time or during business hours like staffed professionals?

Some of the most important questions a volunteer organisation can ask
itself are about the volunteer relationship is how to accommodate the
fact that volunteers can be more productive during leisure hours.

-jef



From rc040203 at freenet.de  Fri Nov 14 07:11:30 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 14 Nov 2008 08:11:30 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
Message-ID: <1226646690.3752.436.camel@beck.corsepiu.local>

On Fri, 2008-11-14 at 01:24 -0500, Seth Vidal wrote:
> 
> On Thu, 13 Nov 2008, Bill Nottingham wrote:

> Look, for the desktop in particular NM makes a lot of sense, I am not 
> arguing otherwise.
Well, I would not key NM to separating desktops vs. servers.

IMO, NM is addressing "machines w/ dynamic network connections", but
it's ineffective/unnecessary overhead on machines with permanent/static
connections, independently if these are servers or desktops (e.g.
classic workstation desktop machine pools).

Closely connected is another aspect, where I feel NM (and other tools in
Fedora) has conceptional weaknesses:
It doesn't take into account "user roles" and "machine roles", but only
considers "personal machines", i.e. the classic "personal laptop".
In practice, this clashes with concepts of central vs. decentral
administration and with user roles.

> For the server it is a solution looking for a problem.
Agreed.

> The reaction you're seeing is people who don't care about the desktop 
> trying to figure out why desktop and/or developer oriented features are 
> causing them to have to change their server deployment/config habits.
Not necessarily. 

IMO, if NM was as easy to use as some people try to advertise it, people
weren't complaining. Fact is: People are complaining for years.

To me, the reasons to complain about NM are quite simple:
I have too often been confronted with situations, where NM didn't not
work as advertised. Worse, due to the fact "NM is wanting to be clever"
and it's total lack of documentation, it often left me clueless about
the causes.

Ralf




From walters at verbum.org  Fri Nov 14 07:21:16 2008
From: walters at verbum.org (Colin Walters)
Date: Fri, 14 Nov 2008 02:21:16 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>
	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>
Message-ID: <faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>

On Fri, Nov 14, 2008 at 1:30 AM, Seth Vidal <skvidal at fedoraproject.org> wrote:
>
> It uses ANY memory. That's more than is reasonable considering that the
> former solution (ifconfig) uses none.

NM and ifconfig are not comparable.  Now I think saying that NM
shouldn't use very much in the way of resources in the static routing
case is a reasonable request; certainly with the push for
virtualization and running lots of OS instances it makes sense.  But
it's just not reasonable to say "ANY" memory; that's not a reasonable
constraint to operate under.  We're trying to build an operating
system; that necessitates adding APIs and features, for example
network status change notification which is useful everywhere.

It's perfectly fine though if someone's "create mediawiki appliance
image" tool strips out stuff; but we should be moving the core OS to
be more unified and featureful in general.



From skvidal at fedoraproject.org  Fri Nov 14 07:36:44 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 14 Nov 2008 02:36:44 -0500 (EST)
Subject: starting Fedora Server SIG
In-Reply-To: <faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>
	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>
	<faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>
Message-ID: <alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>



On Fri, 14 Nov 2008, Colin Walters wrote:

> On Fri, Nov 14, 2008 at 1:30 AM, Seth Vidal <skvidal at fedoraproject.org> wrote:
>>
>> It uses ANY memory. That's more than is reasonable considering that the
>> former solution (ifconfig) uses none.
>
> NM and ifconfig are not comparable.  Now I think saying that NM
> shouldn't use very much in the way of resources in the static routing
> case is a reasonable request; certainly with the push for
> virtualization and running lots of OS instances it makes sense.  But
> it's just not reasonable to say "ANY" memory; that's not a reasonable
> constraint to operate under.  We're trying to build an operating
> system; that necessitates adding APIs and features, for example
> network status change notification which is useful everywhere.
>
> It's perfectly fine though if someone's "create mediawiki appliance
> image" tool strips out stuff; but we should be moving the core OS to
> be more unified and featureful in general.

Featureful is exciting for desktops and for a smaller subset of servers 
with special needs. For the vast majority of fairly boring servers it is 
not exciting, it's just time consuming.

I've got no problem saying that people who use servers should have a 
custom ks that strips out all the stuff they don't need. In fact, I 
believe I've ALWAYS said that. I just don't want us to take steps that 
make setting up that custom ks outrageously difficult. If we end up 
tying the dependencies on these daemons very very low into the distro then 
we end up making a lot of fairly boring server admins' lives difficult for no 
good reason. All I'm saying is that the features that make NM useful 
should not preclude someone from yum removing it w/o losing their whole 
os.

Oh and my general opinion is that the features we should be working on 
more than anything else are simplicity, security and stability.


-sv





From skvidal at fedoraproject.org  Fri Nov 14 07:48:44 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 14 Nov 2008 02:48:44 -0500 (EST)
Subject: F8 EOL messaging
In-Reply-To: <604aa7910811132302q38d2a14eq722a96a24acbb192@mail.gmail.com>
References: <20081112010144.GE8501@localhost.localdomain>
	<491C78D7.1000209@redhat.com>
	<alpine.LFD.2.00.0811131400520.19678@localhost.localdomain>
	<20081114042213.GA27370@localhost.localdomain>
	<alpine.LFD.2.00.0811140014000.19678@localhost.localdomain>
	<gfj6qr$ocv$1@ger.gmane.org>
	<alpine.LFD.2.00.0811140150280.26126@localhost.localdomain>
	<604aa7910811132302q38d2a14eq722a96a24acbb192@mail.gmail.com>
Message-ID: <alpine.LFD.2.00.0811140247240.26126@localhost.localdomain>



On Thu, 13 Nov 2008, Jeff Spaleta wrote:

> On Thu, Nov 13, 2008 at 9:51 PM, Seth Vidal <skvidal at fedoraproject.org> wrote:
>> Great, so you'll release them just to annoy the sysadmins out there who now
>> have to test and apply them when they'd normally be spending time with
>> family and friends?
>>
>> There are very few people benefited by releasing updates over the holidays.
>> Not zero, but very few.
>
> But aren't vacations of this sort an opportunity for volunteers to
> spend more time on Fedora exactly because they have more free time
> then?
> Do people work on Fedora as a job or as a hobby. Do they work during
> free time or during business hours like staffed professionals?
>
> Some of the most important questions a volunteer organisation can ask
> itself are about the volunteer relationship is how to accommodate the
> fact that volunteers can be more productive during leisure hours.
>

Most folks have a day job. Their day job might not be working on 
fedora, but it is a day job. I don't feel bad about not asking volunteers to 
sacrifice a common holiday.

-sv



From rjones at redhat.com  Fri Nov 14 08:50:57 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 14 Nov 2008 08:50:57 +0000
Subject: Plan for tomorrows (20081112) FESCO meeting
In-Reply-To: <491C989A.5070001@redhat.com>
References: <1226438839.26212.2.camel@kennedy> <4919FE3B.1070602@redhat.com>
	<1226445382.3255.10.camel@kennedy>
	<20081112090223.GA24778@amd.home.annexia.org>
	<491C989A.5070001@redhat.com>
Message-ID: <20081114085057.GA10744@amd.home.annexia.org>

On Thu, Nov 13, 2008 at 01:14:02PM -0800, John Poelstra wrote:
> Richard W.M. Jones wrote:
>> https://fedoraproject.org/wiki/Features/Windows_cross_compiler
>
> The page appears to be only partially complete and in Category:  
> FeaturePageIncomplete

Yes because, erm, it's not complete.

Partly I have no idea what's supposed to go in the Test Plan section.
An actual test plan covering the features of all the libraries would
be huge and take weeks to run.  In addition, we have to disable %check
sections in MinGW packages because wine cannot run inside the mock/
koji environment.  Wine needs an X server and a writable $HOME.

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 dan at danny.cz  Fri Nov 14 10:14:25 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Fri, 14 Nov 2008 11:14:25 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>
	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>
	<faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>
	<alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>
Message-ID: <1226657665.3639.41.camel@eagle.danny.cz>


Seth Vidal p??e v P? 14. 11. 2008 v 02:36 -0500:
> 
> On Fri, 14 Nov 2008, Colin Walters wrote:
> 
> > On Fri, Nov 14, 2008 at 1:30 AM, Seth Vidal <skvidal at fedoraproject.org> wrote:
> >>
> >> It uses ANY memory. That's more than is reasonable considering that the
> >> former solution (ifconfig) uses none.
> >
> > NM and ifconfig are not comparable.  Now I think saying that NM
> > shouldn't use very much in the way of resources in the static routing
> > case is a reasonable request; certainly with the push for
> > virtualization and running lots of OS instances it makes sense.  But
> > it's just not reasonable to say "ANY" memory; that's not a reasonable
> > constraint to operate under.  We're trying to build an operating
> > system; that necessitates adding APIs and features, for example
> > network status change notification which is useful everywhere.
> >
> > It's perfectly fine though if someone's "create mediawiki appliance
> > image" tool strips out stuff; but we should be moving the core OS to
> > be more unified and featureful in general.
> 
> Featureful is exciting for desktops and for a smaller subset of servers 
> with special needs. For the vast majority of fairly boring servers it is 
> not exciting, it's just time consuming.
> 
> I've got no problem saying that people who use servers should have a 
> custom ks that strips out all the stuff they don't need. In fact, I 
> believe I've ALWAYS said that. I just don't want us to take steps that 
> make setting up that custom ks outrageously difficult. If we end up 
> tying the dependencies on these daemons very very low into the distro then 
> we end up making a lot of fairly boring server admins' lives difficult for no 
> good reason. All I'm saying is that the features that make NM useful 
> should not preclude someone from yum removing it w/o losing their whole 
> os.
> 
> Oh and my general opinion is that the features we should be working on 
> more than anything else are simplicity, security and stability.

It is really time to look back at the roots of Unix systems. It should
be a combination of small pieces with well defined interfaces doing well
their tasks. Only the time had changed those pieces from simple command
line utilities to more complex ones.


		Dan




From alsadi at gmail.com  Fri Nov 14 10:40:40 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Fri, 14 Nov 2008 12:40:40 +0200
Subject: a trivial fix makes a big change
In-Reply-To: <491CE343.9050303@redhat.com>
References: <385866f0811121507y228eb82egb77544b3edccae3f@mail.gmail.com>
	<491B70A4.6090102@fedoraproject.org>
	<385866f0811130738s67a1be18r858313887b4e02d8@mail.gmail.com>
	<491CE343.9050303@redhat.com>
Message-ID: <385866f0811140240t6d69d816l3dbb354cc54cf760@mail.gmail.com>

I did not say that the sm.conf should be provided by two packages
I said the single one shipped by samba-common should be ready to work
with nautilus-share ie. it should have a line like this

usershare path = /var/lib/samba/usershare

because this has no bad effects if nautilus-share is not installed

>>
>> BTW: I forget that we have system-config-samba
>>
>> we can put a checkbox [ ]  enable nautilus-share
>>
>
> That's exactly how we should do it.
>
that's ok for me too
I like any of the two solutions



From mschwendt at gmail.com  Fri Nov 14 10:40:58 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 14 Nov 2008 11:40:58 +0100
Subject: Macros in %files
In-Reply-To: <2383.71.208.51.222.1226641804.squirrel@www.cora.nwra.com>
References: <491CAE83.50303@cora.nwra.com>
	<491D0E5F.3030604@ioa.s.u-tokyo.ac.jp>
	<2383.71.208.51.222.1226641804.squirrel@www.cora.nwra.com>
Message-ID: <20081114114058.09486f11.mschwendt@gmail.com>

On Thu, 13 Nov 2008 22:50:04 -0700 (MST), Orion Poplawski wrote:

> 
> On Thu, November 13, 2008 10:36 pm, Mamoru Tasaka wrote:
> >
> > Changing to %{!?python_sitearch: %global python_....}
> > works?
> 
> That's the ticket.  Some rpm change I guess I didn't quite pick up on...

Alternatively, simply override it without any nested macros:

%define python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")

-- 
Nested macro usage like  %{!?foo: %define foo ...}  is error-prone anyway.
It quickly leads to confusing scenarios in spec files where you check for
%!?foo in several places, but that would fail if the redefinition were
global implicitly.



From benny+usenet at amorsen.dk  Fri Nov 14 11:04:41 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Fri, 14 Nov 2008 12:04:41 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811140127580.19678@localhost.localdomain> (Seth
	Vidal's message of "Fri\, 14 Nov 2008 01\:30\:24 -0500 \(EST\)")
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>
	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>
Message-ID: <m3skpulgae.fsf@ursa.amorsen.dk>

Seth Vidal <skvidal at fedoraproject.org> writes:

> Colin, let me very clear, I think what NM does for the desktop is very
> good, indeed.  I like not having to fiddle around to make WEP stuff
> work using iwconfig anymore. I appreciate what's been achieved.

> That doesn't make it a more useful thing on a server.

I think you will find that servers will have more complicated
requirements in the future. Things like dynamic interface/routing
failover, 802.1x authentication, and vrrp/hsrp.

Personally I would be very happy if NetworkManager integrated with
Quagga.


/Benny



From benny+usenet at amorsen.dk  Fri Nov 14 11:12:43 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Fri, 14 Nov 2008 12:12:43 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <1226596851.4714.58.camel@localhost.localdomain> (Dan Williams's
	message of "Thu\, 13 Nov 2008 12\:20\:51 -0500")
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz> <491C5777.3090402@gmail.com>
	<1226596851.4714.58.camel@localhost.localdomain>
Message-ID: <m3od0ilfx0.fsf@ursa.amorsen.dk>

Dan Williams <dcbw at redhat.com> writes:

> The default device's DNS information gets added first, and each active
> device's DNS information is appended.

In the near future when most providers close their DNS relays, this
probably won't work very well. At that point you can only reach the
DNS of a provider if your source address is from that provider.

I don't see a way around implementing a DNS relay daemon. DNS is
getting too complicated for a resolver library (and the limit of 3 DNS
servers is way too low.)


/Benny



From hughsient at gmail.com  Fri Nov 14 12:54:22 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 14 Nov 2008 12:54:22 +0000
Subject: PackageKit 0.3.10 in Fedora 9
In-Reply-To: <f6ca9fed0811111011sdec3ac0te208a77a43604e90@mail.gmail.com>
References: <1226421464.3033.80.camel@hughsie-laptop>
	<f6ca9fed0811110953i9f5a83ds42a7d338147a9e71@mail.gmail.com>
	<f6ca9fed0811111011sdec3ac0te208a77a43604e90@mail.gmail.com>
Message-ID: <1226667262.3332.97.camel@hughsie-laptop>

On Tue, 2008-11-11 at 19:11 +0100, drago01 wrote:
> On Tue, Nov 11, 2008 at 6:53 PM, drago01 <drago01 at gmail.com> wrote:
> > On Tue, Nov 11, 2008 at 5:37 PM, Richard Hughes <hughsient at gmail.com> wrote:
> >> I've just built 0.3.10 for F10 and pushed it to updates-testing:
> >>
> >> https://admin.fedoraproject.org/updates/PackageKit-0.3.10-1.fc9,gnome-packagekit-0.3.10-1.fc9
> >>
> >> I would appreciate some feedback. If you can test the preupgrade
> >> notification, that would be even better. Thanks.
> >>
> >> Richard.
> >
> > gpk-application.desktop
> >
> > has
> >
> > Icon=system-software-install
> >
> > while it should be
> >
> > Icon=system-software-installer
> >
> > (It shows no icon in the menu because there is no such file)
> >
> 
> Removing packages fails with
> "TID already set to /46_cadabccd_data"

Found a typo, thanks. Fixed in git. New RPMs are uploaded here
http://www.packagekit.org/packages/ -- you can trivially rebuild the
srpms for F9.

If there are no other issues in the next few hours I'll do a new build
for F9 using koji.

Thanks.

Richard.




From martin.langhoff at gmail.com  Fri Nov 14 13:03:39 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Fri, 14 Nov 2008 08:03:39 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>
	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>
	<faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>
	<alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>
Message-ID: <46a038f90811140503q298c8f62p823125626451f0a@mail.gmail.com>

On Fri, Nov 14, 2008 at 2:36 AM, Seth Vidal <skvidal at fedoraproject.org> wrote:
> Featureful is exciting for desktops and for a smaller subset of servers with
> special needs. For the vast majority of fairly boring servers it is not
> exciting, it's just time consuming.

+1

> I've got no problem saying that people who use servers should have a custom
> ks that strips out all the stuff they don't need. In fact, I believe I've
> ALWAYS said that. I just don't want us to take steps that make setting up
> that custom ks outrageously difficult.

It's already a bit of a black art to know what things to tweak to turn
Fedora into a server-style configuration without breaking things. And
it's growing -- in this thread I've learned about how to get the
text-mode plymouth plugin. I'm sure there's lots more.

Kickstarts and howtos in a wiki around this subject are sorely needed.

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 lesmikesell at gmail.com  Fri Nov 14 13:55:29 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 14 Nov 2008 07:55:29 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>	<1226588572.4714.4.camel@localhost.localdomain>	<20081113160203.GD1538120@hiwaay.net>	<1226592802.3651.30.camel@eagle.danny.cz>	<1226593460.13077.91.camel@aglarond.local>	<20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>
	<faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>
Message-ID: <491D8351.7090909@gmail.com>

Colin Walters wrote:
> On Fri, Nov 14, 2008 at 1:30 AM, Seth Vidal <skvidal at fedoraproject.org> wrote:
>> It uses ANY memory. That's more than is reasonable considering that the
>> former solution (ifconfig) uses none.
> 
> NM and ifconfig are not comparable.  Now I think saying that NM
> shouldn't use very much in the way of resources in the static routing
> case is a reasonable request; certainly with the push for
> virtualization and running lots of OS instances it makes sense.  But
> it's just not reasonable to say "ANY" memory; that's not a reasonable
> constraint to operate under.  We're trying to build an operating
> system; that necessitates adding APIs and features, for example
> network status change notification which is useful everywhere.

A server operating system needs to be more predictable than dynamic. How 
does SNMP deal with these changes?  It screws things up in general if an 
SNMP index ever changes.

> It's perfectly fine though if someone's "create mediawiki appliance
> image" tool strips out stuff; but we should be moving the core OS to
> be more unified and featureful in general.

The server side of Linux has been fairly feature-complete for years and 
is responsible for most Linux usage.  Don't break that to get a desktop 
that still might never be popular.

-- 
   Les Mikesell
     lesmikesell at gmail.com




From lesmikesell at gmail.com  Fri Nov 14 14:26:06 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 14 Nov 2008 08:26:06 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <m3od0ilfx0.fsf@ursa.amorsen.dk>
References: <1226429441.3593.77.camel@eagle.danny.cz>	<20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>	<20081113134947.GF24297@angus.ind.WPI.EDU>	<20081113140153.GA1538120@hiwaay.net>	<1226588572.4714.4.camel@localhost.localdomain>	<20081113160203.GD1538120@hiwaay.net>	<1226592802.3651.30.camel@eagle.danny.cz>
	<491C5777.3090402@gmail.com>	<1226596851.4714.58.camel@localhost.localdomain>
	<m3od0ilfx0.fsf@ursa.amorsen.dk>
Message-ID: <491D8A7E.1070804@gmail.com>

Benny Amorsen wrote:
> 
>> The default device's DNS information gets added first, and each active
>> device's DNS information is appended.
> 
> In the near future when most providers close their DNS relays, this
> probably won't work very well. At that point you can only reach the
> DNS of a provider if your source address is from that provider.

It's just the wrong thing to do in any case.  One set of servers may 
resolve your private zones and there's no way for anything to guess 
which one.

> I don't see a way around implementing a DNS relay daemon. DNS is
> getting too complicated for a resolver library (and the limit of 3 DNS
> servers is way too low.)

We already have a dns relay daemon...  But again there is no information 
that would tell you how to splice the forwarders in dynamically.  And 
you have the same situation with routing.  DHCP can only provide a 
default gateway which isn't sufficient for multiple connections and 
particularly for a mix of public and private subnets that require 
specific routes toward additional private subnets.  I think the best you 
can do in this regard is to provide the tools to easily create stable 
fixed servers that understand your private topology and DNS views that 
can then offer DNS and NAT forwarding to any desktops plugged in behind 
them.

-- 
    Les Mikesell
     lesmikesell at gmail.com



From lesmikesell at gmail.com  Fri Nov 14 14:30:07 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 14 Nov 2008 08:30:07 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>
References: <1226429441.3593.77.camel@eagle.danny.cz>	<1226588572.4714.4.camel@localhost.localdomain>	<20081113160203.GD1538120@hiwaay.net>	<1226592802.3651.30.camel@eagle.danny.cz>	<1226593460.13077.91.camel@aglarond.local>	<20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>	<faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>
	<alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>
Message-ID: <491D8B6F.3040107@gmail.com>

Seth Vidal wrote:
> 
> Oh and my general opinion is that the features we should be working on 
> more than anything else are simplicity, security and stability.

Yes, why does adding features need to break old ones any more than 
adding new filesystems or device types would?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From rawhide at fedoraproject.org  Fri Nov 14 14:46:08 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri, 14 Nov 2008 14:46:08 +0000 (UTC)
Subject: rawhide report: 20081114 changes
Message-ID: <20081114144608.EC47D1F8258@releng2.fedora.phx.redhat.com>

Compose started at Fri Nov 14 06:01:04 UTC 2008

New package wraplinux
        Utility to wrap a Linux kernel and initrd into an ELF or NBI file
Updated Packages:

anaconda-11.4.1.58-1.fc10
-------------------------
* Wed Nov 12 17:00:00 2008 Chris Lumens <clumens at redhat.com> - 11.4.1.58-1
- Add comps groups for new repos that are added (#470653) (katzj)
- Support upgrades of systems whose rootfs is on an LV. (#471288) (dlehman)
- Use hasPassphrase() instead of directly accessing passphrase member.
  (dlehman)
- Don't dump private class members (those with leading "__") (dlehman)
- Explicitly close the CD drive after the user hits "continue" (#375011)
  (pjones)
- Fix shell syntax error (#471090) (ivazqueznet)
- Save the /etc/fstab before overwriting it on upgrades (#452768, #470392).
  (clumens)


ekiga-3.0.1-4.fc10
------------------
* Thu Nov 13 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> - 3.0.1-4
- Fix spec file error

* Thu Nov 13 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> - 3.0.1-3
- Patch to fix libnotify's breakage of its api


kernel-2.6.27.5-109.fc10
------------------------
* Thu Nov 13 17:00:00 2008 Dave Jones <davej at redhat.com> 2.6.27.5-107
- Disable CONFIG_PM_TEST_SUSPEND

* Thu Nov 13 17:00:00 2008 Dave Jones <davej at redhat.com> 2.6.27.5-106
- Increase CONFIG_FORCE_MAX_ZONEORDER to 13 on ppc64. (#468982)

* Thu Nov 13 17:00:00 2008 Dave Jones <davej at redhat.com>
- Change CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR to 4096 on PPC64. (#471478)


ldm-2.0.18-1.fc10
-----------------
* Thu Nov 13 17:00:00 2008 Warren Togami <wtogami at redhat.com> - 2.0.18-1
- Fix race condition in a clean way without the ugly hack.
- Improve logging.
- Many little bug fixes and code cleanups.


ltsp-5.1.34-2.fc10
------------------
* Thu Nov 13 17:00:00 2008 Warren Togami <wtogami at redhat.com> - 5.1.34-2
- Enable plymouth support if supported hardware is detected
- jetpipe supports serial printers
- TIMEZONE and TIMESERVER options for thin clients
- Move LDM to VT1 by default
- Prevent error during client chroot config
- Many other little bug fixes


plymouth-0.6.0-0.2008.11.12.4.fc10
----------------------------------
* Thu Nov 13 17:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.11.12.4
- Move Obsoletes: plymouth-text-and-details-only to base package
  so people who had it installed don't end up solar on upgrade

* Wed Nov 12 17:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.11.12.3
- Redo packaging to work better with minimal installs
  (bug 471314)

* Wed Nov 12 17:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.11.12.2
- Fix plymouth-set-default-plugin to allow external $LIB

* Wed Nov 12 17:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.11.12.1
- Fix star image (Charlie, bug 471113)

* Tue Nov 11 17:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.11.11.2
- Improve solar flares (Charlie)
- redirect tty again on --show-splash
- ignore subsequent --hide-splash calls after the first one
- turn off kernel printks during boot up

* Tue Nov 11 17:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.11.11.1
- Disconnect from tty when init=/bin/bash (bug 471007)


pykickstart-1.47-1.fc10
-----------------------
* Thu Oct 30 18:00:00 2008 Chris Lumens <clumens at redhat.com> - 1.47-1
- Fix enabling services we specify by specific options.


system-config-samba-1.2.67-1.fc10
---------------------------------
* Wed Nov 12 17:00:00 2008 Nils Philippsen <nils at redhat.com> - 1.2.67-1
- use different defaults for PolicyKit authorizations (#470330)


system-config-services-0.99.27-1.fc10
-------------------------------------
* Thu Nov 13 17:00:00 2008 Nils Philippsen <nils at redhat.com> - 0.99.27-1
- fix runlevels hookable set updates (custom runlevels dialog)

* Wed Nov 12 17:00:00 2008 Nils Philippsen <nils at redhat.com>
- use different defaults for PolicyKit authorizations (#470329)

* Mon Nov 10 17:00:00 2008 Nils Philippsen <nils at redhat.com> - 0.99.26-1
- make XinetdService._set_enabled() work for the first time
- fix GUI upon disabled services (#470722)


Summary:
Added Packages: 1
Removed Packages: 0
Modified Packages: 9














From james at fedoraproject.org  Fri Nov 14 15:31:13 2008
From: james at fedoraproject.org (James Antill)
Date: Fri, 14 Nov 2008 10:31:13 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <87ej1fhatg.fsf@fc5.bigo.ensc.de>
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr> <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
	<alpine.LFD.2.00.0811130954360.19678@localhost.localdomain>
	<87ej1fhatg.fsf@fc5.bigo.ensc.de>
Message-ID: <1226676673.22230.212.camel@code.and.org>

On Thu, 2008-11-13 at 17:04 +0100, Enrico Scholz wrote:
> Seth Vidal <skvidal at fedoraproject.org> writes:
> 
> >> Maybe 'yum' should be fixed to handle ambiguous situations better?
> >> E.g. fail, warn and/or prompt when multiple packages satisfy a (virtual)
> >> dependency?
> >>
> >
> > why did you put yum in quotes?
> 
> I put product names usually into quotes.
>
> > If we don't have a good default course of action, why do you think the
> > user is going to know better?
> 
> Why do you think, that 'yum' knows which choice is the best one? E.g. the
> 'plymouth' case shows that the wrong decision was taken and that the user
> would have made the right one.

 You mean an extremely well informed user might have made the better
choice. I'm not sure _I_ would have, I guess if I had the package
summaries I could work out what -solar was by reading what
-text-and-details-only did and assuming it was the opposite.

 But other problems we have in this space like "install java-devel" are
pretty much guaranteed to confuse the user unless they really know what
they are doing, and have almost universally correct answers.

> > If we do have a good default course of action, why are we prompting
> > the user?
> 
> How do you define/configure a "good default course"?

 I've recently posted a patch to the yum ML which would allow Fedora (or
any active repo.) to configure these choices manually. We could then
also easily have different defaults for the desktop vs. the server
spins.

-- 
James Antill <james at fedoraproject.org>
Fedora



From karsten at redhat.com  Fri Nov 14 15:31:12 2008
From: karsten at redhat.com (Karsten Hopp)
Date: Fri, 14 Nov 2008 16:31:12 +0100
Subject: rawhide report: 20081114 changes
In-Reply-To: <20081114144608.EC47D1F8258@releng2.fedora.phx.redhat.com>
References: <20081114144608.EC47D1F8258@releng2.fedora.phx.redhat.com>
Message-ID: <491D99C0.7000803@redhat.com>

Rawhide Report schrieb:
> Compose started at Fri Nov 14 06:01:04 UTC 2008
> 
> New package wraplinux
>         Utility to wrap a Linux kernel and initrd into an ELF or NBI file
> Updated Packages:
> 
> anaconda-11.4.1.58-1.fc10
> -------------------------
> * Wed Nov 12 17:00:00 2008 Chris Lumens <clumens at redhat.com> - 11.4.1.58-1
> - Add comps groups for new repos that are added (#470653) (katzj)
> - Support upgrades of systems whose rootfs is on an LV. (#471288) (dlehman)
> - Use hasPassphrase() instead of directly accessing passphrase member.
>   (dlehman)
> - Don't dump private class members (those with leading "__") (dlehman)
> - Explicitly close the CD drive after the user hits "continue" (#375011)
>   (pjones)
> - Fix shell syntax error (#471090) (ivazqueznet)
> - Save the /etc/fstab before overwriting it on upgrades (#452768, #470392).
>   (clumens)
> 
> 
> ekiga-3.0.1-4.fc10
> ------------------
> * Thu Nov 13 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> - 3.0.1-4
> - Fix spec file error
> 
> * Thu Nov 13 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> - 3.0.1-3
> - Patch to fix libnotify's breakage of its api


When will the F-11 packages be included in Rawhide ? The listed packages are all F-10,
but there a quite a few early F-11 packages available in the meantime.

    Karsten



From karsten at redhat.com  Fri Nov 14 15:32:43 2008
From: karsten at redhat.com (Karsten Hopp)
Date: Fri, 14 Nov 2008 16:32:43 +0100
Subject: rawhide report: 20081114 changes
In-Reply-To: <20081114144608.EC47D1F8258@releng2.fedora.phx.redhat.com>
References: <20081114144608.EC47D1F8258@releng2.fedora.phx.redhat.com>
Message-ID: <491D9A1B.1090503@redhat.com>

Rawhide Report schrieb:
> Compose started at Fri Nov 14 06:01:04 UTC 2008
> 
> New package wraplinux
>         Utility to wrap a Linux kernel and initrd into an ELF or NBI file
> Updated Packages:
> 
> anaconda-11.4.1.58-1.fc10
> -------------------------
> * Wed Nov 12 17:00:00 2008 Chris Lumens <clumens at redhat.com> - 11.4.1.58-1
> - Add comps groups for new repos that are added (#470653) (katzj)
> - Support upgrades of systems whose rootfs is on an LV. (#471288) (dlehman)
> - Use hasPassphrase() instead of directly accessing passphrase member.
>   (dlehman)
> - Don't dump private class members (those with leading "__") (dlehman)
> - Explicitly close the CD drive after the user hits "continue" (#375011)
>   (pjones)
> - Fix shell syntax error (#471090) (ivazqueznet)
> - Save the /etc/fstab before overwriting it on upgrades (#452768, #470392).
>   (clumens)
> 
> 
> ekiga-3.0.1-4.fc10
> ------------------
> * Thu Nov 13 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> - 3.0.1-4
> - Fix spec file error
> 
> * Thu Nov 13 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> - 3.0.1-3
> - Patch to fix libnotify's breakage of its api


When will the F-11 packages be included in Rawhide ? The listed packages are all F-10,
but there a quite a few early F-11 packages available in the meantime.

    Karsten



From jwboyer at gmail.com  Fri Nov 14 15:37:33 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Fri, 14 Nov 2008 10:37:33 -0500
Subject: rawhide report: 20081114 changes
In-Reply-To: <491D9A1B.1090503@redhat.com>
References: <20081114144608.EC47D1F8258@releng2.fedora.phx.redhat.com>
	<491D9A1B.1090503@redhat.com>
Message-ID: <20081114153733.GB20645@yoda.jdub.homelinux.org>

On Fri, Nov 14, 2008 at 04:32:43PM +0100, Karsten Hopp wrote:
> Rawhide Report schrieb:
>> Compose started at Fri Nov 14 06:01:04 UTC 2008
>>
>> New package wraplinux
>>         Utility to wrap a Linux kernel and initrd into an ELF or NBI file
>> Updated Packages:
>>
>> anaconda-11.4.1.58-1.fc10
>> -------------------------
>> * Wed Nov 12 17:00:00 2008 Chris Lumens <clumens at redhat.com> - 11.4.1.58-1
>> - Add comps groups for new repos that are added (#470653) (katzj)
>> - Support upgrades of systems whose rootfs is on an LV. (#471288) (dlehman)
>> - Use hasPassphrase() instead of directly accessing passphrase member.
>>   (dlehman)
>> - Don't dump private class members (those with leading "__") (dlehman)
>> - Explicitly close the CD drive after the user hits "continue" (#375011)
>>   (pjones)
>> - Fix shell syntax error (#471090) (ivazqueznet)
>> - Save the /etc/fstab before overwriting it on upgrades (#452768, #470392).
>>   (clumens)
>>
>>
>> ekiga-3.0.1-4.fc10
>> ------------------
>> * Thu Nov 13 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> - 3.0.1-4
>> - Fix spec file error
>>
>> * Thu Nov 13 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> - 3.0.1-3
>> - Patch to fix libnotify's breakage of its api
>
>
> When will the F-11 packages be included in Rawhide ? The listed packages are all F-10,
> but there a quite a few early F-11 packages available in the meantime.

Shortly before F-10 GAs.  Rawhide tracks a release almost until the very end of the cycle.

josh



From vonbrand at inf.utfsm.cl  Fri Nov 14 15:37:54 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Fri, 14 Nov 2008 12:37:54 -0300
Subject: starting Fedora Server SIG
In-Reply-To: <20081114000723.GA6635@nostromo.devel.redhat.com>
References: <20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<604aa7910811131551s74a418afv24a5a5401e5ba0bb@mail.gmail.com>
	<491CC066.9000808@gmail.com>
	<20081114000723.GA6635@nostromo.devel.redhat.com>
Message-ID: <200811141537.mAEFbsTH004020@laptop14.inf.utfsm.cl>

Bill Nottingham <notting at redhat.com> wrote:
> Les Mikesell (lesmikesell at gmail.com) said: 
> > Will ifconfig and route be modified internally to talk to dbus so the  
> > scripts and commands that have worked for eons continue to work?

> I really don't know what you mean by this. For displaying devices,
> addresses, and routes, they will work like they always have. If you
> use it to change the configuration of a device out from under NetworkManager,
> well, then you've causes your own issue. (Much like if you change 
> the address out from whatever /etc/init.d/network configured it
> as, actually.)

The question is to make NM aware of such changes (or even do them through
NM).
-- 
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 skvidal at fedoraproject.org  Fri Nov 14 15:52:02 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 14 Nov 2008 10:52:02 -0500 (EST)
Subject: starting Fedora Server SIG
In-Reply-To: <m3skpulgae.fsf@ursa.amorsen.dk>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>
	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>
	<m3skpulgae.fsf@ursa.amorsen.dk>
Message-ID: <alpine.LFD.2.00.0811141051330.26126@localhost.localdomain>



On Fri, 14 Nov 2008, Benny Amorsen wrote:

> Seth Vidal <skvidal at fedoraproject.org> writes:
>
>> Colin, let me very clear, I think what NM does for the desktop is very
>> good, indeed.  I like not having to fiddle around to make WEP stuff
>> work using iwconfig anymore. I appreciate what's been achieved.
>
>> That doesn't make it a more useful thing on a server.
>
> I think you will find that servers will have more complicated
> requirements in the future. Things like dynamic interface/routing
> failover, 802.1x authentication, and vrrp/hsrp.
>
> Personally I would be very happy if NetworkManager integrated with
> Quagga.

I think you'll find the above is not the common webserver/fileserver in a 
corner, either.

-sv



From orion at cora.nwra.com  Fri Nov 14 15:55:57 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 14 Nov 2008 08:55:57 -0700
Subject: Macros in %files
In-Reply-To: <20081114114058.09486f11.mschwendt@gmail.com>
References: <491CAE83.50303@cora.nwra.com>	<491D0E5F.3030604@ioa.s.u-tokyo.ac.jp>	<2383.71.208.51.222.1226641804.squirrel@www.cora.nwra.com>
	<20081114114058.09486f11.mschwendt@gmail.com>
Message-ID: <491D9F8D.7020703@cora.nwra.com>

Michael Schwendt wrote:
> On Thu, 13 Nov 2008 22:50:04 -0700 (MST), Orion Poplawski wrote:
> 
>> On Thu, November 13, 2008 10:36 pm, Mamoru Tasaka wrote:
>>> Changing to %{!?python_sitearch: %global python_....}
>>> works?
>> That's the ticket.  Some rpm change I guess I didn't quite pick up on...
> 
> Alternatively, simply override it without any nested macros:
> 
> %define python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")
> 

Well, it's take directly from:

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

If that doesn't work any more, it seems many spec templates may need to 
get changed.

I also count 1089 occurrences of this construct in current fedora spec 
files.

-- 
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 pbrobinson at gmail.com  Fri Nov 14 16:01:42 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Fri, 14 Nov 2008 16:01:42 +0000
Subject: rawhide report: 20081114 changes
In-Reply-To: <491D99C0.7000803@redhat.com>
References: <20081114144608.EC47D1F8258@releng2.fedora.phx.redhat.com>
	<491D99C0.7000803@redhat.com>
Message-ID: <5256d0b0811140801t5060b866m11f1f2aacb7f60c2@mail.gmail.com>

>> New package wraplinux
>>        Utility to wrap a Linux kernel and initrd into an ELF or NBI file
>> Updated Packages:
>>
>> anaconda-11.4.1.58-1.fc10
>> -------------------------
>> * Wed Nov 12 17:00:00 2008 Chris Lumens <clumens at redhat.com> - 11.4.1.58-1
>> - Add comps groups for new repos that are added (#470653) (katzj)
>> - Support upgrades of systems whose rootfs is on an LV. (#471288)
>> (dlehman)
>> - Use hasPassphrase() instead of directly accessing passphrase member.
>>  (dlehman)
>> - Don't dump private class members (those with leading "__") (dlehman)
>> - Explicitly close the CD drive after the user hits "continue" (#375011)
>>  (pjones)
>> - Fix shell syntax error (#471090) (ivazqueznet)
>> - Save the /etc/fstab before overwriting it on upgrades (#452768,
>> #470392).
>>  (clumens)
>>
>>
>> ekiga-3.0.1-4.fc10
>> ------------------
>> * Thu Nov 13 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> - 3.0.1-4
>> - Fix spec file error
>>
>> * Thu Nov 13 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> - 3.0.1-3
>> - Patch to fix libnotify's breakage of its api
>
>
> When will the F-11 packages be included in Rawhide ? The listed packages are
> all F-10,
> but there a quite a few early F-11 packages available in the meantime.

I pushed the changes to CVS, thought I'd sent a  build to koji but may
have missed it. Will check when I get home.

Peter



From dan at danny.cz  Fri Nov 14 15:51:17 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Fri, 14 Nov 2008 16:51:17 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <1226676673.22230.212.camel@code.and.org>
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr> <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
	<alpine.LFD.2.00.0811130954360.19678@localhost.localdomain>
	<87ej1fhatg.fsf@fc5.bigo.ensc.de>
	<1226676673.22230.212.camel@code.and.org>
Message-ID: <1226677877.3639.80.camel@eagle.danny.cz>


James Antill p??e v P? 14. 11. 2008 v 10:31 -0500:
> On Thu, 2008-11-13 at 17:04 +0100, Enrico Scholz wrote:
> > Seth Vidal <skvidal at fedoraproject.org> writes:
> > 
> > Why do you think, that 'yum' knows which choice is the best one? E.g. the
> > 'plymouth' case shows that the wrong decision was taken and that the user
> > would have made the right one.
> 
>  You mean an extremely well informed user might have made the better
> choice. I'm not sure _I_ would have, I guess if I had the package
> summaries I could work out what -solar was by reading what
> -text-and-details-only did and assuming it was the opposite.
> 
>  But other problems we have in this space like "install java-devel" are
> pretty much guaranteed to confuse the user unless they really know what
> they are doing, and have almost universally correct answers.
> 
> > > If we do have a good default course of action, why are we prompting
> > > the user?
> > 
> > How do you define/configure a "good default course"?
> 
>  I've recently posted a patch to the yum ML which would allow Fedora (or
> any active repo.) to configure these choices manually. We could then
> also easily have different defaults for the desktop vs. the server
> spins.

That looks really promising.


		Dan




From lfarkas at lfarkas.org  Fri Nov 14 16:09:50 2008
From: lfarkas at lfarkas.org (Farkas Levente)
Date: Fri, 14 Nov 2008 17:09:50 +0100
Subject: why koji try to build on ppc when ExcludeArch ppc?
Message-ID: <491DA2CE.70600@lfarkas.org>

hi,
i try to build gstreamer-java for F-10. the spec file contians the lines:
----------------------------
# for ExcludeArch see bug: 468831
ExcludeArch:    ppc, ppc64
----------------------------
but koji still try to build for ppc:
http://koji.fedoraproject.org/koji/taskinfo?taskID=933620
and of course this build fails.
why try to build on ppc? it's a koji bug?
thanks in advance.

-- 
  Levente                               "Si vis pacem para bellum!"



From wtogami at redhat.com  Fri Nov 14 16:11:17 2008
From: wtogami at redhat.com (Warren Togami)
Date: Fri, 14 Nov 2008 11:11:17 -0500
Subject: F11: OSS and pulseaudio conflict
Message-ID: <491DA325.3010305@redhat.com>

I ran into an application yesterday that seemed to make pulseaudio
daemon fail.  After a lot of digging, someone else realized that this
application was actually using OSS output.  OSS currently grabs /dev/dsp
(provided by snd-pcm-oss), making it appear that pulseaudio has "failed".

OSS applications are so rare these days, I did not even consider that it
was using OSS.  This is likely to be a rare but repetitive source of
confusion in the future.

Removing snd-pcm-oss makes /dev/dsp disappear (which is a good thing).
Even with /dev/dsp gone, padsp wrapper allows an OSS app to output to
pulseaudio.  Only this isn't a good permanent solution because we do not
want LD_PRELOAD wrapping everything.

I think perhaps during F11 we should do the following:

1) alsa-plugins-pulseaudio seems to be the key package someone must
remove if they really want to disable pulseaudio on their system.  This
package could ship a /etc/modprobe.d/blacklist-oss file listing
snd-*-oss modules.  This way OSS comes back if pulseaudio is disabled.

2) If someone REALLY wants OSS mixed in their pulseaudio desktop, they
can use padsp.  This should be documented loudly in release notes.  This
is no different from F9 and F10.

3) Later make /dev/dsp redirection to pulseaudio permanent without LD
hacks with the proposed FUSD?  What is the status of this?

Warren Togami
wtogami at redhat.com



From dan at danny.cz  Fri Nov 14 16:14:00 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Fri, 14 Nov 2008 17:14:00 +0100
Subject: why koji try to build on ppc when ExcludeArch ppc?
In-Reply-To: <491DA2CE.70600@lfarkas.org>
References: <491DA2CE.70600@lfarkas.org>
Message-ID: <1226679240.3639.83.camel@eagle.danny.cz>


Farkas Levente p??e v P? 14. 11. 2008 v 17:09 +0100:
> hi,
> i try to build gstreamer-java for F-10. the spec file contians the lines:
> ----------------------------
> # for ExcludeArch see bug: 468831
> ExcludeArch:    ppc, ppc64

use
ExcludeArch:    ppc ppc64
with no comma?

> ----------------------------
> but koji still try to build for ppc:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=933620
> and of course this build fails.
> why try to build on ppc? it's a koji bug?
> thanks in advance.


		Dan




From sgros.ml at gmail.com  Fri Nov 14 16:14:12 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Fri, 14 Nov 2008 17:14:12 +0100
Subject: network install and stage2.img: what i'm missing?
Message-ID: <4d7b043c0811140814p19750c95r5386ba04ee93c69a@mail.gmail.com>

Hi all!

I'm trying to do PXE boot and network install of F10, but I can not
pass the step where I have to enter URL from which installation should
be done. Every time installer complains that it can not download
stage2.img. Looking into rawhide, as well as all F10 snapshots that
were released, there is no stage2.img to be found anywhere.

So, what am I missing here?

Stjepan



From tibbs at math.uh.edu  Fri Nov 14 16:18:58 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 14 Nov 2008 10:18:58 -0600
Subject: why koji try to build on ppc when ExcludeArch ppc?
In-Reply-To: <491DA2CE.70600@lfarkas.org>
References: <491DA2CE.70600@lfarkas.org>
Message-ID: <ufaiqqquvpp.fsf@epithumia.math.uh.edu>

>>>>> "FL" == Farkas Levente <lfarkas at lfarkas.org> writes:

FL> why try to build on ppc? it's a koji bug?

It's a noarch package, so it just gets assigned randomly to the pool.
I thought that koji did check excludearch lines even for noarch
packages, but maybe that's just the compose tools.

 - J<



From notting at redhat.com  Fri Nov 14 16:26:10 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 14 Nov 2008 11:26:10 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <1226676673.22230.212.camel@code.and.org>
References: <491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
	<alpine.LFD.2.00.0811130954360.19678@localhost.localdomain>
	<87ej1fhatg.fsf@fc5.bigo.ensc.de>
	<1226676673.22230.212.camel@code.and.org>
Message-ID: <20081114162610.GA30721@nostromo.devel.redhat.com>

James Antill (james at fedoraproject.org) said: 
> > > If we do have a good default course of action, why are we prompting
> > > the user?
> > 
> > How do you define/configure a "good default course"?
> 
>  I've recently posted a patch to the yum ML which would allow Fedora (or
> any active repo.) to configure these choices manually. We could then
> also easily have different defaults for the desktop vs. the server
> spins.

Where would you store per-spin defaults, as they all point to the
same repo?

Bill



From bruno at wolff.to  Fri Nov 14 16:25:14 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Fri, 14 Nov 2008 10:25:14 -0600
Subject: rawhide report: 20081114 changes
In-Reply-To: <5256d0b0811140801t5060b866m11f1f2aacb7f60c2@mail.gmail.com>
References: <20081114144608.EC47D1F8258@releng2.fedora.phx.redhat.com>
	<491D99C0.7000803@redhat.com>
	<5256d0b0811140801t5060b866m11f1f2aacb7f60c2@mail.gmail.com>
Message-ID: <20081114162514.GA6642@wolff.to>

On Fri, Nov 14, 2008 at 16:01:42 +0000,
  Peter Robinson <pbrobinson at gmail.com> wrote:
> 
> I pushed the changes to CVS, thought I'd sent a  build to koji but may
> have missed it. Will check when I get home.

ekiga-3.0.1-4.fc10 is tagged f10-final so it should be showing up in rawhide.



From konrad at tylerc.org  Fri Nov 14 16:31:10 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Fri, 14 Nov 2008 09:31:10 -0700
Subject: why koji try to build on ppc when ExcludeArch ppc?
In-Reply-To: <ufaiqqquvpp.fsf@epithumia.math.uh.edu>
References: <491DA2CE.70600@lfarkas.org>
	<ufaiqqquvpp.fsf@epithumia.math.uh.edu>
Message-ID: <200811140831.10970.konrad@tylerc.org>

On Friday 14 November 2008 08:18:58 am Jason L Tibbitts III wrote:
> >>>>> "FL" == Farkas Levente <lfarkas at lfarkas.org> writes:
>
> FL> why try to build on ppc? it's a koji bug?
>
> It's a noarch package, so it just gets assigned randomly to the pool.
> I thought that koji did check excludearch lines even for noarch
> packages, but maybe that's just the compose tools.
>
>  - J<

Don't believe so -- I've run into this in the past.

-- 
Conrad Meyer <konrad at tylerc.org>




From tibbs at math.uh.edu  Fri Nov 14 16:36:13 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 14 Nov 2008 10:36:13 -0600
Subject: why koji try to build on ppc when ExcludeArch ppc?
In-Reply-To: <ufaiqqquvpp.fsf@epithumia.math.uh.edu>
References: <491DA2CE.70600@lfarkas.org>
	<ufaiqqquvpp.fsf@epithumia.math.uh.edu>
Message-ID: <ufaej1euuwy.fsf@epithumia.math.uh.edu>

Actually, the problem is pretty clear: you simply cannot do what
you're trying to do.

If your package won't even build on PPC, it simply can't be noarch.
The ExcludeArch: case for noarch packages is for those with runtime
dependencies that aren't available for all architectures.  That's not
the case you're seeing.

Your options are either to wait until the JRE bug is fixed or make
your package arch-specific.

 - J<



From mschwendt at gmail.com  Fri Nov 14 16:39:07 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 14 Nov 2008 17:39:07 +0100
Subject: Macros in %files
In-Reply-To: <491D9F8D.7020703@cora.nwra.com>
References: <491CAE83.50303@cora.nwra.com>
	<491D0E5F.3030604@ioa.s.u-tokyo.ac.jp>
	<2383.71.208.51.222.1226641804.squirrel@www.cora.nwra.com>
	<20081114114058.09486f11.mschwendt@gmail.com>
	<491D9F8D.7020703@cora.nwra.com>
Message-ID: <20081114173907.e1e30eca.mschwendt@gmail.com>

On Fri, 14 Nov 2008 08:55:57 -0700, Orion Poplawski wrote:

> Michael Schwendt wrote:
> > On Thu, 13 Nov 2008 22:50:04 -0700 (MST), Orion Poplawski wrote:
> > 
> >> On Thu, November 13, 2008 10:36 pm, Mamoru Tasaka wrote:
> >>> Changing to %{!?python_sitearch: %global python_....}
> >>> works?
> >> That's the ticket.  Some rpm change I guess I didn't quite pick up on...
> > 
> > Alternatively, simply override it without any nested macros:
> > 
> > %define python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")
> > 
> 
> Well, it's take directly from:
> 
> http://fedoraproject.org/wiki/Packaging/Python#System_Architecture
> 
> If that doesn't work any more, it seems many spec templates may need to 
> get changed.

True.
 
> I also count 1089 occurrences of this construct in current fedora spec 
> files.

:)

I've searched a bit:
https://fedoraproject.org/wiki/Packaging/Minutes20070424



From jkeating at redhat.com  Fri Nov 14 16:46:25 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 14 Nov 2008 08:46:25 -0800
Subject: starting Fedora Server SIG
In-Reply-To: <20081114162610.GA30721@nostromo.devel.redhat.com>
References: <491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
	<alpine.LFD.2.00.0811130954360.19678@localhost.localdomain>
	<87ej1fhatg.fsf@fc5.bigo.ensc.de>
	<1226676673.22230.212.camel@code.and.org>
	<20081114162610.GA30721@nostromo.devel.redhat.com>
Message-ID: <1226681186.11393.26.camel@luminos.localdomain>

On Fri, 2008-11-14 at 11:26 -0500, Bill Nottingham wrote:
> > > How do you define/configure a "good default course"?
> > 
> >  I've recently posted a patch to the yum ML which would allow Fedora (or
> > any active repo.) to configure these choices manually. We could then
> > also easily have different defaults for the desktop vs. the server
> > spins.
> 
> Where would you store per-spin defaults, as they all point to the
> same repo?


And how would you account for multiple repos providing this
information... differently?  Which repo wins?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeatingng
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081114/fe1eecfe/attachment.sig>

From clumens at redhat.com  Fri Nov 14 16:48:49 2008
From: clumens at redhat.com (Chris Lumens)
Date: Fri, 14 Nov 2008 11:48:49 -0500
Subject: network install and stage2.img: what i'm missing?
In-Reply-To: <4d7b043c0811140814p19750c95r5386ba04ee93c69a@mail.gmail.com>
References: <4d7b043c0811140814p19750c95r5386ba04ee93c69a@mail.gmail.com>
Message-ID: <20081114164848.GA31216@localhost.localdomain>

> I'm trying to do PXE boot and network install of F10, but I can not
> pass the step where I have to enter URL from which installation should
> be done. Every time installer complains that it can not download
> stage2.img. Looking into rawhide, as well as all F10 snapshots that
> were released, there is no stage2.img to be found anywhere.
> 
> So, what am I missing here?

Can you show what messages are on tty3?  The only place "stage2.img"
exists in the anaconda source anymore is in the spec file's %changelog
and in some outdated documentation.  Perhaps you have an old version of
the initrd on your pxe boot server, like maybe from way back in F9
times?

- Chris



From notting at redhat.com  Fri Nov 14 16:49:43 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 14 Nov 2008 11:49:43 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <20081114015938.GA1418333@hiwaay.net>
References: <20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<20081114015938.GA1418333@hiwaay.net>
Message-ID: <20081114164943.GB30721@nostromo.devel.redhat.com>

Chris Adams (cmadams at hiwaay.net) said: 
> > How is NM-dispatcher a developer service? Similarly, nm-tool is
> > at least quicker than 'ip addr ls ; ip route ls ; cat /etc/resolv.conf'.
> 
> Funny; when I opened my notebook just now, hald segfaulted and died and
> NM died for some unknown reason.  Because of that, nm-tool was useless,
> but ifconfig still worked.

And I tried to update yesterday and yum failed, but RPM still worked.
So yum is obviously useless for a user environment, and just extra code
that gets in the way.

(Not that I actually believe that, but there's a fallacy here of
conflating anecdotes and the existence of bugs with 'never use this'.)

Frankly, the part of this discussion that confuses me is the insistence
that "NetworkManager is not useful for some server-based configs" yields
the conclusion that "NetworkManager is not useful for any server-based
configs" (complete with FUD about what it actually supports doing, which
is a lot of this thread as well.) And it's not just NetworkManager that
this applies to - the same discussion came up in this thread about
encrypted filesystems.

In fact, here's a list of things that I've had server admins complain
about, with respect to 'bloat', or 'added code', or 'functionality that
I don't need, why is it installed' at one point or another over the
past few years.

- NetworkManager
- Encrypted filesystems
- udev
- Administration utilities using python (or perl, or ruby, or...)
- yum (as a corollary to the above, and other reasons)
- Kerberos authentication support, and krb5-libs dependencies
- cyrus-sasl library dependencies
- LDAP library dependencies
- X11 libraries
- I'd like an administration desktop, but why GNOME instead of
  xfce/lxde/fvwm/twm
- puppet/cfengine/etc.
- fontconfig
- UTF-8 support
- I don't like having this binary installed! It's over 1MB in size!

Heck, if you go back far enough, people complained about why PAM
needed to be added. And I'm sure I'm missing others. It gets to a point
where the only solution that would seem to be able to placate all the
diverse admin users would be to never change anything, and we could
just ship the equivalent of Slackware 3.2 with security fixes and go home.

Of course, if we actually did that, then each disparate group would then
complain about not including whichever of those features above they
*did* care about, and no one would be happy.

Sorry... on to your other question...

> How would a system admin even configure NM?  Where do I go to add an
> alias, a new route, or a new GRE tunnel?

The ifcfg files, or the network manager config tool. (GRE isn't
supported yet.)

> How is a daemon (or set of daemons) useful for a static configuration
> that does not change?  For the vast majority of my servers, the network
> config is set in the kickstart %post and not touched for the life of the
> server (which is typically many years; I've got a RHEL 3 server that
> hasn't had a network change since Feb 2004 for example).

I tried to give some examples above, such as ways to give notification
to other apps/services when network devices go up and down that don't
rely on them catching SIGIO and then trying to guess what happened.
(That's the notification mechanism currently provided by the initscripts.)
While it may not be useful for all service cases, it certainly can
be useful for some.

Bill



From orion at cora.nwra.com  Fri Nov 14 16:51:58 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 14 Nov 2008 09:51:58 -0700
Subject: network install and stage2.img: what i'm missing?
In-Reply-To: <4d7b043c0811140814p19750c95r5386ba04ee93c69a@mail.gmail.com>
References: <4d7b043c0811140814p19750c95r5386ba04ee93c69a@mail.gmail.com>
Message-ID: <491DACAE.40303@cora.nwra.com>

Stjepan Gros wrote:
> Hi all!
> 
> I'm trying to do PXE boot and network install of F10, but I can not
> pass the step where I have to enter URL from which installation should
> be done. Every time installer complains that it can not download
> stage2.img. Looking into rawhide, as well as all F10 snapshots that
> were released, there is no stage2.img to be found anywhere.
> 
> So, what am I missing here?
> 
> Stjepan
> 

Are you specifying a stage2 location in your pxe boot config or boot 
command line?  That was my problem....

-- 
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 notting at redhat.com  Fri Nov 14 16:56:22 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 14 Nov 2008 11:56:22 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <46a038f90811140503q298c8f62p823125626451f0a@mail.gmail.com>
References: <1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>
	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>
	<faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>
	<alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>
	<46a038f90811140503q298c8f62p823125626451f0a@mail.gmail.com>
Message-ID: <20081114165622.GC30721@nostromo.devel.redhat.com>

Martin Langhoff (martin.langhoff at gmail.com) said: 
> It's already a bit of a black art to know what things to tweak to turn
> Fedora into a server-style configuration without breaking things. And
> it's growing -- in this thread I've learned about how to get the
> text-mode plymouth plugin. I'm sure there's lots more.

Don't worry, we made that knowledge obsolete. (As of today, unless
you install something else, you get a base plymouth on install
that only has text & details.)

Bill



From notting at redhat.com  Fri Nov 14 16:58:16 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 14 Nov 2008 11:58:16 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <200811141537.mAEFbsTH004020@laptop14.inf.utfsm.cl>
References: <20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<604aa7910811131551s74a418afv24a5a5401e5ba0bb@mail.gmail.com>
	<491CC066.9000808@gmail.com>
	<20081114000723.GA6635@nostromo.devel.redhat.com>
	<200811141537.mAEFbsTH004020@laptop14.inf.utfsm.cl>
Message-ID: <20081114165816.GD30721@nostromo.devel.redhat.com>

Horst H. von Brand (vonbrand at inf.utfsm.cl) said: 
> > I really don't know what you mean by this. For displaying devices,
> > addresses, and routes, they will work like they always have. If you
> > use it to change the configuration of a device out from under NetworkManager,
> > well, then you've causes your own issue. (Much like if you change 
> > the address out from whatever /etc/init.d/network configured it
> > as, actually.)
> 
> The question is to make NM aware of such changes (or even do them through
> NM).

I'm curious - why is 'make <blah> aware of me changing things out from under
it and handling it across up/down/reboot' more of a prority for NM than
for the old network scripts?

Bill



From notting at redhat.com  Fri Nov 14 16:59:47 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 14 Nov 2008 11:59:47 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <46a038f90811131617y4e33980cw20b4b1fd62903e57@mail.gmail.com>
References: <20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<604aa7910811131551s74a418afv24a5a5401e5ba0bb@mail.gmail.com>
	<46a038f90811131617y4e33980cw20b4b1fd62903e57@mail.gmail.com>
Message-ID: <20081114165947.GE30721@nostromo.devel.redhat.com>

Martin Langhoff (martin.langhoff at gmail.com) said: 
> An excellent counterexample is incrond - I pass 'events' to scripts
> using incrond's hooks into inotify. The scripts themselves are not
> running, I only have one tiny tiny daemon listening. I can rig it to
> handle thousands of specific different events and scripts, and still
> the footprint is small (and if I monitor directories smartly, it
> doesn't need to burden the kernel much either).

Honestly, they're different usage cases. dbus is for exposing
services and objects through a simple IPC interface - if you're
exposing an object, you sort of need a backing for it.

It honestly sounds like you're using incrond for something that
would fit into upstart's usage model.

Bill



From sgros.ml at gmail.com  Fri Nov 14 17:09:05 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Fri, 14 Nov 2008 18:09:05 +0100
Subject: network install and stage2.img: what i'm missing?
In-Reply-To: <491DACAE.40303@cora.nwra.com>
References: <4d7b043c0811140814p19750c95r5386ba04ee93c69a@mail.gmail.com>
	<491DACAE.40303@cora.nwra.com>
Message-ID: <4d7b043c0811140909y6d731b99h8d11aeda476f465d@mail.gmail.com>

On Fri, Nov 14, 2008 at 5:51 PM, Orion Poplawski <orion at cora.nwra.com> wrote:
> Stjepan Gros wrote:
>>
>> Hi all!
>>
>> I'm trying to do PXE boot and network install of F10, but I can not
>> pass the step where I have to enter URL from which installation should
>> be done. Every time installer complains that it can not download
>> stage2.img. Looking into rawhide, as well as all F10 snapshots that
>> were released, there is no stage2.img to be found anywhere.
>>
>> So, what am I missing here?
>>
>> Stjepan
>>
>
> Are you specifying a stage2 location in your pxe boot config or boot command
> line?  That was my problem....

Well, I messed up. It turns out that the problem was tftp server's
configuration that was pointing to another directory than the one I
was preparing. Sorry for the false alarm!

Stjepan



From katzj at redhat.com  Fri Nov 14 15:50:37 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 14 Nov 2008 10:50:37 -0500
Subject: rawhide report: 20081114 changes
In-Reply-To: <491D9A1B.1090503@redhat.com>
References: <20081114144608.EC47D1F8258@releng2.fedora.phx.redhat.com>
	<491D9A1B.1090503@redhat.com>
Message-ID: <1226677837.636.10.camel@aglarond.local>

On Fri, 2008-11-14 at 16:32 +0100, Karsten Hopp wrote:
> When will the F-11 packages be included in Rawhide ? The listed packages are all F-10,
> but there a quite a few early F-11 packages available in the meantime.

As soon as we can wrap up Fedora 10 -- think of it as motivation to help
fix blockers :-)   If we switch rawhide over earlier, then we make it
somewhere between very hard and impossible to get testing of the final
bits for F10

Jeremy



From katzj at redhat.com  Fri Nov 14 16:07:50 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 14 Nov 2008 11:07:50 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>
	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>
	<faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>
	<alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>
Message-ID: <1226678870.636.37.camel@aglarond.local>

On Fri, 2008-11-14 at 02:36 -0500, Seth Vidal wrote:
> I've got no problem saying that people who use servers should have a 
> custom ks that strips out all the stuff they don't need. In fact, I 
> believe I've ALWAYS said that. I just don't want us to take steps that 
> make setting up that custom ks outrageously difficult. If we end up 
> tying the dependencies on these daemons very very low into the distro then 
> we end up making a lot of fairly boring server admins' lives difficult for no 
> good reason. All I'm saying is that the features that make NM useful 
> should not preclude someone from yum removing it w/o losing their whole 
> os.

But trying to preserve that modularity combinatorially adds to the
testing matrix and also makes it significantly more difficult to write
code since you can no longer depend on functionality.  It also makes
things slower as you have to conditionally check for things constantly.

> Oh and my general opinion is that the features we should be working on 
> more than anything else are simplicity, security and stability.

Hey, guess what -- that's what a lot of these new fangled things are
actually working on.

Jeremy



From katzj at redhat.com  Fri Nov 14 16:08:52 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 14 Nov 2008 11:08:52 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
Message-ID: <1226678932.636.40.camel@aglarond.local>

On Fri, 2008-11-14 at 01:24 -0500, Seth Vidal wrote:
> On Thu, 13 Nov 2008, Bill Nottingham wrote:
> > How is NM-dispatcher a developer service? Similarly, nm-tool is
> > at least quicker than 'ip addr ls ; ip route ls ; cat /etc/resolv.conf'.
> 
> and ifconfig -a works on multiple platforms, so it's the one that will 
> win.

ifconfig -a doesn't show all the information if you're doing multiple
addresses on an adapter.  

> > As for resources... just to point out that NM (at least on my laptop)
> > uses 2.5MB resident... pretty much exactly the same amount as the 5
> > unused mingetty processes that many 'server' admins screamed needed to be
> > kept always.
> 
> 
> nm, dbus in particular:
> dbus: 3M
> NM: 17M here
> 
> that's 20M vs 9M total for all the gettys running here.

You're looking at VSZ, not RSS. 

> Look, for the desktop in particular NM makes a lot of sense, I am not 
> arguing otherwise.
> 
> For the server it is a solution looking for a problem.
> 
> The reaction you're seeing is people who don't care about the desktop 
> trying to figure out why desktop and/or developer oriented features are 
> causing them to have to change their server deployment/config habits.
> 
> You can't tell me you're surprised by the pushback, Bill.

Let me change the wording of your argument a little...

"Look, for the desktop in particular Linux makes a lot of sense, I am
not arguing otherwise.

For the server it is a solution looking for a problem.  Solaris works
just fine thank you very much."

It's *exactly* the arguments I heard with switching out Solaris stuff
when I was at NCSU.


One of the things about progress and getting to a more mature *platform*
that is suitable across a wide range of uses is change.  I'm not saying
that NetworkManager is perfect yet for the server needs.  But having
people that want to run a server say "pound sand, go the hell away, we
don't want to run your new-fangled stuff" doesn't help us get to where
it is.  Maintaining two systems in parallel is very much a long-run
losing position.  

Jeremy



From katzj at redhat.com  Fri Nov 14 16:09:24 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 14 Nov 2008 11:09:24 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <1226644990.3639.9.camel@eagle.danny.cz>
References: <20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<20081114015938.GA1418333@hiwaay.net>
	<1226644990.3639.9.camel@eagle.danny.cz>
Message-ID: <1226678964.636.42.camel@aglarond.local>

On Fri, 2008-11-14 at 07:43 +0100, Dan Hor?k wrote:
> Chris Adams p??e v ?t 13. 11. 2008 v 19:59 -0600:
> > How is a daemon (or set of daemons) useful for a static configuration
> > that does not change?  For the vast majority of my servers, the network
> > config is set in the kickstart %post and not touched for the life of the
> > server (which is typically many years; I've got a RHEL 3 server that
> > hasn't had a network change since Feb 2004 for example).
> > 
> > For servers, the simpler solution (that meets the needs) is always
> > better, and running multiple daemons to configure the network is
> > definately not simpler than a text file and "ifup".
> 
> That's 100% true and maintaining "/etc/init.d/network" for the future
> will be our SIG's job. When there is a "link down" event on the server
> then you call the network administrator :-)

It's more than just /etc/init.d/network that has to be maintained.
There's oodles of stuff in install-time configuration that will have to
be maintained, tested, and have things fixed when people report them.
There will be a need to maintain a separate initrd infrastructure[1].
And those are the two things that are closest to what I'm thinking about
today and by no means an exhaustive list.

Jeremy

[1] Currently, we use libdhcp in the initrd for things like iscsi,
nfsroot, and nbdroot.  libdhcp is going away in F11 so we're going to
have to rework the network config code and the sensible thing is to move
to using NetworkManager like the rest of the distro so that we don't
have to maintain another codebase.  Note that there's still a fair bit
of handwaving involved here since we haven't sat down to really figure
out how to make some of the trickier parts work yet :)



From lesmikesell at gmail.com  Fri Nov 14 17:30:32 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 14 Nov 2008 11:30:32 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <20081114165622.GC30721@nostromo.devel.redhat.com>
References: <1226592802.3651.30.camel@eagle.danny.cz>	<1226593460.13077.91.camel@aglarond.local>	<20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>	<faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>	<alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>	<46a038f90811140503q298c8f62p823125626451f0a@mail.gmail.com>
	<20081114165622.GC30721@nostromo.devel.redhat.com>
Message-ID: <491DB5B8.6070600@gmail.com>

Bill Nottingham wrote:
> Martin Langhoff (martin.langhoff at gmail.com) said: 
>> It's already a bit of a black art to know what things to tweak to turn
>> Fedora into a server-style configuration without breaking things. And
>> it's growing -- in this thread I've learned about how to get the
>> text-mode plymouth plugin. I'm sure there's lots more.
> 
> Don't worry, we made that knowledge obsolete.

That's the real problem...  Managing unix-like systems has always been 
something of a specialized art, but typically worth learning because you 
can re-use the knowledge for years/decades even though different vendors 
have always tried to make it difficult to use their training with 
anything else.  But that doesn't seem to apply any more.  How do you 
expect places that manage servers to keep their 24x7 operations staff 
(in several locations...) aware of all the administrative differences 
from day to day and among versions likely to be running concurrently? 
If you can completely automate something, fine, but I do not believe 
there is any chance of doing that correctly for anything but trivial 
(and client...) configurations.  So how do we get the dynamic gunk out 
of the way on the more complex machines providing the services?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From skvidal at fedoraproject.org  Fri Nov 14 17:32:47 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 14 Nov 2008 12:32:47 -0500 (EST)
Subject: starting Fedora Server SIG
In-Reply-To: <1226678870.636.37.camel@aglarond.local>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>
	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>
	<faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>
	<alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>
	<1226678870.636.37.camel@aglarond.local>
Message-ID: <alpine.LFD.2.00.0811141227290.26126@localhost.localdomain>



On Fri, 14 Nov 2008, Jeremy Katz wrote:

>
> But trying to preserve that modularity combinatorially adds to the
> testing matrix and also makes it significantly more difficult to write
> code since you can no longer depend on functionality.  It also makes
> things slower as you have to conditionally check for things constantly.

I don't disagree, but it is a lot better to acknowledge this situation 
than it is to simply attribute some kind of neo-luddite perspective to 
those suggesting we do anything else.

I'm not saying we keep everything forever, I am saying we might consider 
thinking a bit more before deciding to implement a brand new system 
as solution to an existing problem.

-sv



From debarshi.ray at gmail.com  Fri Nov 14 17:42:38 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Fri, 14 Nov 2008 23:12:38 +0530
Subject: libgnomecanvas owns %{_libdir}/libglade
In-Reply-To: <3170f42f0811081224p9e6e7ffpfca6970eee4015e6@mail.gmail.com>
References: <3170f42f0811062012v135f1766s4c8152cd26811383@mail.gmail.com>
	<20081107114035.0402300d@metropolis.intra.city-fan.org>
	<3170f42f0811070413g7e90fddq989ff28dfb05b964@mail.gmail.com>
	<1226067740.3417.1.camel@localhost.localdomain>
	<3170f42f0811081101u82c56c3mb821282eaa8d16b2@mail.gmail.com>
	<1226171714.3881.0.camel@localhost.localdomain>
	<3170f42f0811081224p9e6e7ffpfca6970eee4015e6@mail.gmail.com>
Message-ID: <3170f42f0811140942j526758dbhde86cf50a9e74b62@mail.gmail.com>

>>> I made the changes in Rawhide. Can we have the fix in Fedora 9 & 10 as
>>> updates? Fedora 8 would be a bit too much, I guess?

>> If you do the builds, I won't object...

> Tagged and built for F-8, F-9 and F-10 now. I put in a versioned
> Requires on libglade2 in libgnomecanvas to avoid %{_libdir}/libglade
> from becoming unowned if someone only updated libgnomecanvas. However
> I did not bump the BuildRequires on libglade2-devel since the new
> libglade2 packages are not yet in the buildroots and the directory
> issue won't make any difference.

Just a gentle reminder. Did you push the updates in Bodhi?

Thanks,
Debarshi



From dominik at greysector.net  Fri Nov 14 17:45:14 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Fri, 14 Nov 2008 18:45:14 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <1226681186.11393.26.camel@luminos.localdomain>
References: <491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
	<alpine.LFD.2.00.0811130954360.19678@localhost.localdomain>
	<87ej1fhatg.fsf@fc5.bigo.ensc.de>
	<1226676673.22230.212.camel@code.and.org>
	<20081114162610.GA30721@nostromo.devel.redhat.com>
	<1226681186.11393.26.camel@luminos.localdomain>
Message-ID: <20081114174513.GA6394@mokona.greysector.net>

On Friday, 14 November 2008 at 17:46, Jesse Keating wrote:
> On Fri, 2008-11-14 at 11:26 -0500, Bill Nottingham wrote:
> > > > How do you define/configure a "good default course"?
> > > 
> > >  I've recently posted a patch to the yum ML which would allow Fedora (or
> > > any active repo.) to configure these choices manually. We could then
> > > also easily have different defaults for the desktop vs. the server
> > > spins.
> > 
> > Where would you store per-spin defaults, as they all point to the
> > same repo?
> 
> 
> And how would you account for multiple repos providing this
> information... differently?  Which repo wins?

That's easy, just make per-spin packages with the appropriate config
files (for some yum plugin, perhaps?). Make them conflict with each
other explicitly, too.

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 james.antill at redhat.com  Fri Nov 14 17:46:52 2008
From: james.antill at redhat.com (James Antill)
Date: Fri, 14 Nov 2008 12:46:52 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <1226681186.11393.26.camel@luminos.localdomain>
References: <491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
	<alpine.LFD.2.00.0811130954360.19678@localhost.localdomain>
	<87ej1fhatg.fsf@fc5.bigo.ensc.de>
	<1226676673.22230.212.camel@code.and.org>
	<20081114162610.GA30721@nostromo.devel.redhat.com>
	<1226681186.11393.26.camel@luminos.localdomain>
Message-ID: <1226684812.4355.10.camel@code.and.org>

On Fri, 2008-11-14 at 08:46 -0800, Jesse Keating wrote:
> On Fri, 2008-11-14 at 11:26 -0500, Bill Nottingham wrote:
> > > > How do you define/configure a "good default course"?
> > > 
> > >  I've recently posted a patch to the yum ML which would allow Fedora (or
> > > any active repo.) to configure these choices manually. We could then
> > > also easily have different defaults for the desktop vs. the server
> > > spins.
> > 
> > Where would you store per-spin defaults, as they all point to the
> > same repo?

 Ahh, I didn't think the spins did that (they are just different sets of
default packages then?) ... atm. that wouldn't be trivial to work
around, but it could be done by providing a repo. just for the extra
repometadata ... or we could change the proposed metadata syntax to
solve this?

> And how would you account for multiple repos providing this
> information... differently?  Which repo wins?

 Atm. it works a lot like comps.? ... the repodata is merged (so if one
repo. prefers FOO and one BAR, then both/either are preferred over BAZ
but are equal against each other).
 With the caveat. that atm. the implementation prefers the data from
repo. X when we are installing a dependency of a package from repo. X.
So if you "yum install java-devel" it'll use the global/merged data, but
if you do "yum install totem" then "libbaconvideowidget.so.0()" could go
to either totem-xine or totem-gstreamer based on just what the repo.
totem comes from specifies.


? But, yeh, that's one of the things I asked for comments about.

-- 
James Antill <james.antill at redhat.com>
Red Hat
-------------- next part --------------
A 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/20081114/faf410ee/attachment.sig>

From lesmikesell at gmail.com  Fri Nov 14 17:46:28 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 14 Nov 2008 11:46:28 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <20081114164943.GB30721@nostromo.devel.redhat.com>
References: <20081113140153.GA1538120@hiwaay.net>	<1226588572.4714.4.camel@localhost.localdomain>	<20081113160203.GD1538120@hiwaay.net>	<1226592802.3651.30.camel@eagle.danny.cz>	<1226593460.13077.91.camel@aglarond.local>	<20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>	<20081113223242.GB4498@nostromo.devel.redhat.com>	<20081114015938.GA1418333@hiwaay.net>
	<20081114164943.GB30721@nostromo.devel.redhat.com>
Message-ID: <491DB974.202@gmail.com>

Bill Nottingham wrote:
> 
> (Not that I actually believe that, but there's a fallacy here of
> conflating anecdotes and the existence of bugs with 'never use this'.)

I've tried to avoid doing that.  Stuff happens.  But conversely, don't 
use that as an excuse for shipping a bad design.

> Frankly, the part of this discussion that confuses me is the insistence
> that "NetworkManager is not useful for some server-based configs" yields
> the conclusion that "NetworkManager is not useful for any server-based
> configs" (complete with FUD about what it actually supports doing, which
> is a lot of this thread as well.) And it's not just NetworkManager that
> this applies to - the same discussion came up in this thread about
> encrypted filesystems.

The reason the discussion comes up is that it is not clear how the new 
stuff is layered on top of standard interfaces and how to avoid using it 
when you don't want it.  And how to keep user-session related stuff from 
getting intertwined with things that are really server/services (like 
needing a session to interactively provide an encryption key on a server 
where this is likely to be impossible).

> Heck, if you go back far enough, people complained about why PAM
> needed to be added. And I'm sure I'm missing others. It gets to a point
> where the only solution that would seem to be able to placate all the
> diverse admin users would be to never change anything, and we could
> just ship the equivalent of Slackware 3.2 with security fixes and go home.

I still have quite a few machines running a 2.4 kernel. Nothing fedora 
currently adds would improve the services they provide.  What are you 
suggesting as the benefit to the incompatible changes where they aren't 
needed.  And what excuse is there to not provide backward interface and 
command line compatibility when adding new things?  If you can't support 
the old functionality, the change is probably not an improvement.

> I tried to give some examples above, such as ways to give notification
> to other apps/services when network devices go up and down that don't
> rely on them catching SIGIO and then trying to guess what happened.
> (That's the notification mechanism currently provided by the initscripts.)
> While it may not be useful for all service cases, it certainly can
> be useful for some.

How have snmp traps worked all these years? It isn't just things with 
access to dbus on the local machine that need to know about interface 
issues.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From enrico.scholz at informatik.tu-chemnitz.de  Fri Nov 14 17:49:02 2008
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Fri, 14 Nov 2008 18:49:02 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <1226676673.22230.212.camel@code.and.org> (James Antill's message
	of "Fri, 14 Nov 2008 10:31:13 -0500")
References: <1226485422.3638.22.camel@eagle.danny.cz>
	<20081112110506.GA3142@free.fr> <20081112131806.GA1461854@hiwaay.net>
	<778179b00811120529t486e437dwb03891765bf8137b@mail.gmail.com>
	<5256d0b0811120635g6bd83d14if04c2ec2771ee760@mail.gmail.com>
	<491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
	<alpine.LFD.2.00.0811130954360.19678@localhost.localdomain>
	<87ej1fhatg.fsf@fc5.bigo.ensc.de>
	<1226676673.22230.212.camel@code.and.org>
Message-ID: <87k5b6ci5t.fsf@fc5.bigo.ensc.de>

James Antill <james at fedoraproject.org> writes:

>> > If we don't have a good default course of action, why do you think the
>> > user is going to know better?
>> 
>> Why do you think, that 'yum' knows which choice is the best one? E.g. the
>> 'plymouth' case shows that the wrong decision was taken and that the user
>> would have made the right one.
>
> You mean an extremely well informed user might have made the better
> choice.

Chances are much higher that a user (who knows his needs) makes a better
choice than 'yum' which follows a shorter-wins strategy.


> I'm not sure _I_ would have, I guess if I had the package summaries I
> could work out what -solar was by reading what -text-and-details-only
> did and assuming it was the opposite.

A user friendly prompting would be:

----
'yum' encountered an ambiguous situation while trying to resolve the
'foo-bar' dependency. Do you want to continue with the builtin strategy
([Y])? When not, you can install

[1] foo-blub (15KiB size, 8 direct dependencies)
[2] bar-blub (42MiB size, 23 direct dependencies)
[A] all of the packages above

or show the

[S] summary
[D] full description

of these packages? Please enter your choice (separate multiple packages
by ',' or by space):
----


>  I've recently posted a patch to the yum ML which would allow Fedora (or
> any active repo.) to configure these choices manually. We could then
> also easily have different defaults for the desktop vs. the server
> spins.

Idea of spins is ok when creating CD/DVD images but pretty useless for
online installations/upgrades.


Enrico



From skvidal at fedoraproject.org  Fri Nov 14 17:52:24 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 14 Nov 2008 12:52:24 -0500 (EST)
Subject: starting Fedora Server SIG
In-Reply-To: <1226678932.636.40.camel@aglarond.local>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
Message-ID: <alpine.LFD.2.00.0811141242170.26126@localhost.localdomain>



On Fri, 14 Nov 2008, Jeremy Katz wrote:

> On Fri, 2008-11-14 at 01:24 -0500, Seth Vidal wrote:
>> On Thu, 13 Nov 2008, Bill Nottingham wrote:
>>> How is NM-dispatcher a developer service? Similarly, nm-tool is
>>> at least quicker than 'ip addr ls ; ip route ls ; cat /etc/resolv.conf'.
>>
>> and ifconfig -a works on multiple platforms, so it's the one that will
>> win.
>
> ifconfig -a doesn't show all the information if you're doing multiple
> addresses on an adapter.

it doesn't show binding but it will show virtual interfaces, eth0:1, etc.

but that's a side issue...


> Let me change the wording of your argument a little...
>
> "Look, for the desktop in particular Linux makes a lot of sense, I am
> not arguing otherwise.
>
> For the server it is a solution looking for a problem.  Solaris works
> just fine thank you very much."
>
> It's *exactly* the arguments I heard with switching out Solaris stuff
> when I was at NCSU.

Interesting, when I was in the same situation at duke the arguments I 
heard was that linux wasn't tested enough and open source software wasn't 
supported. It had nothing to do with it being too featureful. The 
featureset b/t solaris servers and linux servers in 1999 were almost 
identical. Most of the tools were actually the SAME CODE.


>
> One of the things about progress and getting to a more mature *platform*
> that is suitable across a wide range of uses is change.  I'm not saying
> that NetworkManager is perfect yet for the server needs.  But having
> people that want to run a server say "pound sand, go the hell away, we
> don't want to run your new-fangled stuff" doesn't help us get to where
> it is.  Maintaining two systems in parallel is very much a long-run
> losing position.

I think you're confused as to what I'm saying. You're hoisting up this 
straw man that's neo-luddite and that's not me.

I think I'm tired of both of these perspectives:
  'ALL NEW IS GOOD'
  'ALL NEW IS BAD'

I'd like a bit more of:
  "not all this new shit works and some of it should not have been started"
  "sometimes you do have to throw one away"

And finally a bit more patience that changing systems which have been in 
place for over a decade is going to cause some angst. That angst can be 
minimized if the response to it is not so vehement and impatient. We have 
a lot of vocal people who seem to think any resistance to change means you 
want nothing to change. And we have a lot of vocal people who seem to 
think that rethinking how we're doing thing is akin to heresy.

It's just not that simple.

-sv



From skvidal at fedoraproject.org  Fri Nov 14 17:53:28 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 14 Nov 2008 12:53:28 -0500 (EST)
Subject: starting Fedora Server SIG
In-Reply-To: <1226681186.11393.26.camel@luminos.localdomain>
References: <491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
	<alpine.LFD.2.00.0811130954360.19678@localhost.localdomain>
	<87ej1fhatg.fsf@fc5.bigo.ensc.de>
	<1226676673.22230.212.camel@code.and.org>
	<20081114162610.GA30721@nostromo.devel.redhat.com>
	<1226681186.11393.26.camel@luminos.localdomain>
Message-ID: <alpine.LFD.2.00.0811141252500.26126@localhost.localdomain>



On Fri, 14 Nov 2008, Jesse Keating wrote:

> On Fri, 2008-11-14 at 11:26 -0500, Bill Nottingham wrote:
>>>> How do you define/configure a "good default course"?
>>>
>>>  I've recently posted a patch to the yum ML which would allow Fedora (or
>>> any active repo.) to configure these choices manually. We could then
>>> also easily have different defaults for the desktop vs. the server
>>> spins.
>>
>> Where would you store per-spin defaults, as they all point to the
>> same repo?
>
>
> And how would you account for multiple repos providing this
> information... differently?  Which repo wins?

Magic? :)

We've not worked out all the details, yet. Still trying to sort out what 
mechanisms will cause the least pain.

-sv



From fedora at leemhuis.info  Fri Nov 14 17:54:19 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Fri, 14 Nov 2008 18:54:19 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811141227290.26126@localhost.localdomain>
References: <1226429441.3593.77.camel@eagle.danny.cz>	<1226588572.4714.4.camel@localhost.localdomain>	<20081113160203.GD1538120@hiwaay.net>	<1226592802.3651.30.camel@eagle.danny.cz>	<1226593460.13077.91.camel@aglarond.local>	<20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>	<faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>	<alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>	<1226678870.636.37.camel@aglarond.local>
	<alpine.LFD.2.00.0811141227290.26126@localhost.localdomain>
Message-ID: <491DBB4B.3090602@leemhuis.info>

/me bites

On 14.11.2008 18:32, Seth Vidal wrote:
> On Fri, 14 Nov 2008, Jeremy Katz wrote:
>> But trying to preserve that modularity combinatorially adds to the
>> testing matrix and also makes it significantly more difficult to write
>> code since you can no longer depend on functionality.  It also makes
>> things slower as you have to conditionally check for things constantly.
 >
> I don't disagree, but it is a lot better to acknowledge this situation 
> than it is to simply attribute some kind of neo-luddite perspective to 
> those suggesting we do anything else.
> 
> I'm not saying we keep everything forever, I am saying we might consider 
> thinking a bit more before deciding to implement a brand new system 
> as solution to an existing problem.

That IMHO is a general problem in Fedora and IMHO one of the biggest 
problems of Fedora.

One examples from the last two years: the new firewire stack JuJu. It 
afaics is a improvement now, but it was a bit to early when we shipped 
it as the "one and only" Firewire stack.

Fedora as a whole IMHO should act a bit more like the kernel developers 
that have that "no regressions in new kernels" as goal -- they don't 
reach that goal completely but they are quite close afaics.

CU
knurd



From mosonkonrad at gmail.com  Fri Nov 14 17:56:27 2008
From: mosonkonrad at gmail.com (=?ISO-8859-2?Q?Konrad_Moso=F1?=)
Date: Fri, 14 Nov 2008 18:56:27 +0100
Subject: sound skipping in F10
In-Reply-To: <385866f0811100621w3410f3bp1b111e4890ad7d33@mail.gmail.com>
References: <385866f0811091311q31e1a367u9de08b054a9e0989@mail.gmail.com>
	<4917652E.3020004@gmail.com> <4917A540.7050108@fedoraproject.org>
	<4917F695.2040005@gmail.com>
	<385866f0811100619u55d9bce8rcb3bae30c8ec09b4@mail.gmail.com>
	<385866f0811100621w3410f3bp1b111e4890ad7d33@mail.gmail.com>
Message-ID: <62b1552c0811140956s412b937cmacd4c6bcdbde292b@mail.gmail.com>

I have the same problem on my Realtek HighDefinition Audio.
Skipping stopped when you boot Fedora with "nomodeset" parameter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081114/dad2156c/attachment.htm>

From dennis at ausil.us  Fri Nov 14 17:56:53 2008
From: dennis at ausil.us (Dennis Gilmore)
Date: Fri, 14 Nov 2008 11:56:53 -0600
Subject: rawhide report: 20081114 changes
In-Reply-To: <491D99C0.7000803@redhat.com>
References: <20081114144608.EC47D1F8258@releng2.fedora.phx.redhat.com>
	<491D99C0.7000803@redhat.com>
Message-ID: <200811141156.53764.dennis@ausil.us>

On Friday 14 November 2008 09:31:12 am Karsten Hopp wrote:
> Rawhide Report schrieb:

> When will the F-11 packages be included in Rawhide ? The listed packages
> are all F-10, but there a quite a few early F-11 packages available in the
> meantime.

Same as it has always been When the current release is done. The day after 
F-10 is out the flood of builds for F-11 will be released. 

Dennis



From jspaleta at gmail.com  Fri Nov 14 17:56:54 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 14 Nov 2008 08:56:54 -0900
Subject: starting Fedora Server SIG
In-Reply-To: <20081114174513.GA6394@mokona.greysector.net>
References: <491AF259.40907@comcast.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
	<alpine.LFD.2.00.0811130954360.19678@localhost.localdomain>
	<87ej1fhatg.fsf@fc5.bigo.ensc.de>
	<1226676673.22230.212.camel@code.and.org>
	<20081114162610.GA30721@nostromo.devel.redhat.com>
	<1226681186.11393.26.camel@luminos.localdomain>
	<20081114174513.GA6394@mokona.greysector.net>
Message-ID: <604aa7910811140956v2f3ab9e7iebd0ab3188cd0340@mail.gmail.com>

On Fri, Nov 14, 2008 at 8:45 AM, Dominik 'Rathann' Mierzejewski
<dominik at greysector.net> wrote:
> That's easy, just make per-spin packages with the appropriate config
> files (for some yum plugin, perhaps?). Make them conflict with each
> other explicitly, too.

Having a client side indication, like an installed package with what
the original install configuration would be helpful for other
reasons...like community based support initiatives. If defaults are
going to diverge significantly knowing what the install type was
original could help form a baseline to move forward from when trying
to help someone with a problem.

-jef



From skvidal at fedoraproject.org  Fri Nov 14 17:57:03 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 14 Nov 2008 12:57:03 -0500 (EST)
Subject: starting Fedora Server SIG
In-Reply-To: <1226684812.4355.10.camel@code.and.org>
References: <491AED13.8050204@comcast.net>
	<5256d0b0811120700q785b12c3v859bc58d12d4fc9c@mail.gmail.com>
	<491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
	<alpine.LFD.2.00.0811130954360.19678@localhost.localdomain>
	<87ej1fhatg.fsf@fc5.bigo.ensc.de>
	<1226676673.22230.212.camel@code.and.org>
	<20081114162610.GA30721@nostromo.devel.redhat.com>
	<1226681186.11393.26.camel@luminos.localdomain>
	<1226684812.4355.10.camel@code.and.org>
Message-ID: <alpine.LFD.2.00.0811141256010.26126@localhost.localdomain>



On Fri, 14 Nov 2008, James Antill wrote:

> On Fri, 2008-11-14 at 08:46 -0800, Jesse Keating wrote:
>> On Fri, 2008-11-14 at 11:26 -0500, Bill Nottingham wrote:
>>>>> How do you define/configure a "good default course"?
>>>>
>>>>  I've recently posted a patch to the yum ML which would allow Fedora (or
>>>> any active repo.) to configure these choices manually. We could then
>>>> also easily have different defaults for the desktop vs. the server
>>>> spins.
>>>
>>> Where would you store per-spin defaults, as they all point to the
>>> same repo?
>
> Ahh, I didn't think the spins did that (they are just different sets of
> default packages then?) ... atm. that wouldn't be trivial to work
> around, but it could be done by providing a repo. just for the extra
> repometadata ... or we could change the proposed metadata syntax to
> solve this?

Curiously enough you could make a fedora spin repodata now with 
mergerepo and then modifyrepo to add the spin-specific comps and 
provider-selection metadata all pointing back to 'everything' for the 
actual packages.

-sv



From jkeating at redhat.com  Fri Nov 14 18:00:01 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 14 Nov 2008 10:00:01 -0800
Subject: starting Fedora Server SIG
In-Reply-To: <20081114174513.GA6394@mokona.greysector.net>
References: <491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
	<alpine.LFD.2.00.0811130954360.19678@localhost.localdomain>
	<87ej1fhatg.fsf@fc5.bigo.ensc.de>
	<1226676673.22230.212.camel@code.and.org>
	<20081114162610.GA30721@nostromo.devel.redhat.com>
	<1226681186.11393.26.camel@luminos.localdomain>
	<20081114174513.GA6394@mokona.greysector.net>
Message-ID: <1226685601.11393.55.camel@luminos.localdomain>

On Fri, 2008-11-14 at 18:45 +0100, Dominik 'Rathann' Mierzejewski wrote:
> That's easy, just make per-spin packages with the appropriate config
> files (for some yum plugin, perhaps?). Make them conflict with each
> other explicitly, too.

Conflicts are rarely the answer.  Conflicts result in an error box to
the user with essentially "You picked wrong and I cannot continue.  Go
back and try it 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/20081114/4cf16d08/attachment.sig>

From katzj at redhat.com  Fri Nov 14 18:09:40 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 14 Nov 2008 13:09:40 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811141227290.26126@localhost.localdomain>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>
	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>
	<faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>
	<alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>
	<1226678870.636.37.camel@aglarond.local>
	<alpine.LFD.2.00.0811141227290.26126@localhost.localdomain>
Message-ID: <1226686180.13086.33.camel@aglarond.local>

On Fri, 2008-11-14 at 12:32 -0500, Seth Vidal wrote:
> On Fri, 14 Nov 2008, Jeremy Katz wrote:
> > But trying to preserve that modularity combinatorially adds to the
> > testing matrix and also makes it significantly more difficult to write
> > code since you can no longer depend on functionality.  It also makes
> > things slower as you have to conditionally check for things constantly.
> 
> I don't disagree, but it is a lot better to acknowledge this situation 
> than it is to simply attribute some kind of neo-luddite perspective to 
> those suggesting we do anything else.
> 
> I'm not saying we keep everything forever, I am saying we might consider 
> thinking a bit more before deciding to implement a brand new system 
> as solution to an existing problem.

Some changes are a flag day (udev, pam, ConsoleKit) just because the
cost of otherwise is very high.  Others can be spread out over time
(we've only been working on getting NetworkManager into shape and in use
for the better part of five years now).

I think we're actually in violent agreement :)

Jeremy





From katzj at redhat.com  Fri Nov 14 18:09:43 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 14 Nov 2008 13:09:43 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <491DBB4B.3090602@leemhuis.info>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>
	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>
	<faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>
	<alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>
	<1226678870.636.37.camel@aglarond.local>
	<alpine.LFD.2.00.0811141227290.26126@localhost.localdomain>
	<491DBB4B.3090602@leemhuis.info>
Message-ID: <1226686183.13086.34.camel@aglarond.local>

On Fri, 2008-11-14 at 18:54 +0100, Thorsten Leemhuis wrote:
> > I'm not saying we keep everything forever, I am saying we might consider 
> > thinking a bit more before deciding to implement a brand new system 
> > as solution to an existing problem.
> 
> That IMHO is a general problem in Fedora and IMHO one of the biggest 
> problems of Fedora.

But it's also one of the often-posited strengths of Fedora -- we push
the edge forward which in the end benefits everyone

> One examples from the last two years: the new firewire stack JuJu. It 
> afaics is a improvement now, but it was a bit to early when we shipped 
> it as the "one and only" Firewire stack.
> 
> Fedora as a whole IMHO should act a bit more like the kernel developers 
> that have that "no regressions in new kernels" as goal -- they don't 
> reach that goal completely but they are quite close afaics.

Kernel developers might argue about the success there.  It definitely
doesn't match a lot of experiences I see from blogs, bugzilla, random
other reading of the internets :/

Jeremy



From martin.langhoff at gmail.com  Fri Nov 14 18:13:00 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Fri, 14 Nov 2008 13:13:00 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <1226678932.636.40.camel@aglarond.local>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
Message-ID: <46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>

On Fri, Nov 14, 2008 at 11:08 AM, Jeremy Katz <katzj at redhat.com> wrote:
> One of the things about progress and getting to a more mature *platform*
> that is suitable across a wide range of uses is change.  I'm not saying
> that NetworkManager is perfect yet for the server needs.  But having
> people that want to run a server say "pound sand, go the hell away, we
> don't want to run your new-fangled stuff" doesn't help us get to where
> it is.  Maintaining two systems in parallel is very much a long-run
> losing position.

I agree with the desire to maintain only one tool. However, NM is
extremely desktop oriented, and there seems to include no hint of an
intention to support the complex setups that are possible with the old
ifcfg infra.

Scripting is actually a great fit for network config policies. All the
NM goodies could be built into a much _much_ leaner program that can
orchestrate different network configurations dynamically (ifcfg
style). Right now it's a monolith -- I'm not tracking it closely, but
nm-tool is slowly getting some very basic functions, and there's no
scripting supported AFAICS.

So I suspect that the NM design is specifically for a '2 solutions'
world. Ignore the server role (with all its needs of automation and
odd configs), address only the mainstream desktop (with a pre-cooked
set of rules that can be baked into the binary). To have a single tool
that can handle both, it'd have to be a design goal.

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 katzj at redhat.com  Fri Nov 14 18:14:03 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 14 Nov 2008 13:14:03 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811141242170.26126@localhost.localdomain>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<alpine.LFD.2.00.0811141242170.26126@localhost.localdomain>
Message-ID: <1226686443.13086.39.camel@aglarond.local>

On Fri, 2008-11-14 at 12:52 -0500, Seth Vidal wrote:
> On Fri, 14 Nov 2008, Jeremy Katz wrote:
> > One of the things about progress and getting to a more mature *platform*
> > that is suitable across a wide range of uses is change.  I'm not saying
> > that NetworkManager is perfect yet for the server needs.  But having
> > people that want to run a server say "pound sand, go the hell away, we
> > don't want to run your new-fangled stuff" doesn't help us get to where
> > it is.  Maintaining two systems in parallel is very much a long-run
> > losing position.
> 
> I think you're confused as to what I'm saying. You're hoisting up this 
> straw man that's neo-luddite and that's not me.
> 
> I think I'm tired of both of these perspectives:
>   'ALL NEW IS GOOD'
>   'ALL NEW IS BAD'

That's fair enough.  I'm the first to sometimes say new is bad and
sometimes it's good.  And sometimes (actually, many or most times I'd
say) it starts bad and through a concerted effort and some getting
pissed off at the bad, it gets to good. :)

> I'd like a bit more of:
>   "not all this new shit works and some of it should not have been started"
>   "sometimes you do have to throw one away"
> 
> And finally a bit more patience that changing systems which have been in 
> place for over a decade is going to cause some angst. That angst can be 
> minimized if the response to it is not so vehement and impatient. We have 
> a lot of vocal people who seem to think any resistance to change means you 
> want nothing to change. And we have a lot of vocal people who seem to 
> think that rethinking how we're doing thing is akin to heresy.

I don't think that "should not have been started" is really ever the
right answer.  Like you said, sometimes you have to throw one away.  And
the only way you learn that is by starting, trying things out, and
finding the problems.  

And unfortunately, sometimes the only way you get people to pay
attention and start pointing out problems is to force the issue :/
There's also the problem of doing something new, having people adjust to
it, and then realizing it needs to change and then having people
complain about that :-)

Jeremy



From katzj at redhat.com  Fri Nov 14 18:22:28 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 14 Nov 2008 13:22:28 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>
Message-ID: <1226686948.13086.44.camel@aglarond.local>

On Fri, 2008-11-14 at 13:13 -0500, Martin Langhoff wrote:
> On Fri, Nov 14, 2008 at 11:08 AM, Jeremy Katz <katzj at redhat.com> wrote:
> > One of the things about progress and getting to a more mature *platform*
> > that is suitable across a wide range of uses is change.  I'm not saying
> > that NetworkManager is perfect yet for the server needs.  But having
> > people that want to run a server say "pound sand, go the hell away, we
> > don't want to run your new-fangled stuff" doesn't help us get to where
> > it is.  Maintaining two systems in parallel is very much a long-run
> > losing position.
> 
> I agree with the desire to maintain only one tool. However, NM is
> extremely desktop oriented, and there seems to include no hint of an
> intention to support the complex setups that are possible with the old
> ifcfg infra.

Really?  Most of the work over the past couple of years in NM seems to
be aimed at trying to support these cases as opposed to just the
"simple" desktop case

> Scripting is actually a great fit for network config policies. All the
> NM goodies could be built into a much _much_ leaner program that can
> orchestrate different network configurations dynamically (ifcfg
> style). Right now it's a monolith -- I'm not tracking it closely, but
> nm-tool is slowly getting some very basic functions, and there's no
> scripting supported AFAICS.

The NetworkManager dispatcher stuff has existed forever and is all about
scripting.  Not necessarily pre-interface bringup, but post.  And
depending on scripting slows things down and makes it a lot harder to
have a deterministic view of what's been done.

And rather than focusing on nm-tool and exactly what it exposes, it's
probably more interesting to look at the dbus interfaces/daemon
capabilities.  Yes, I'll be one of the first to say it's painful to
write code interacting with dbus :-) -- but, it is very flexible and
then as what the real use cases that people care about become clearer,
it's easier to write very lean, very specific tools to do what they need
as long as the backend and dbus interfaces are sufficient

Jeremy



From a.badger at gmail.com  Fri Nov 14 18:44:31 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 14 Nov 2008 10:44:31 -0800
Subject: Plan for tomorrows (20081112) FESCO meeting
In-Reply-To: <20081114085057.GA10744@amd.home.annexia.org>
References: <1226438839.26212.2.camel@kennedy>
	<4919FE3B.1070602@redhat.com>	<1226445382.3255.10.camel@kennedy>	<20081112090223.GA24778@amd.home.annexia.org>	<491C989A.5070001@redhat.com>
	<20081114085057.GA10744@amd.home.annexia.org>
Message-ID: <491DC70F.1050905@gmail.com>

Richard W.M. Jones wrote:
> On Thu, Nov 13, 2008 at 01:14:02PM -0800, John Poelstra wrote:
>> Richard W.M. Jones wrote:
>>> https://fedoraproject.org/wiki/Features/Windows_cross_compiler
>> The page appears to be only partially complete and in Category:  
>> FeaturePageIncomplete
> 
> Yes because, erm, it's not complete.
> 
I think poelcat means, it's incomplete so won't be discussed yet :-)

> Partly I have no idea what's supposed to go in the Test Plan section.
> An actual test plan covering the features of all the libraries would
> be huge and take weeks to run.  In addition, we have to disable %check
> sections in MinGW packages because wine cannot run inside the mock/
> koji environment.  Wine needs an X server and a writable $HOME.
> 
The test plan needs to tell people how to tell if the Feature is
complete and whether it's reasonable to tell people it's ready to use
when the next Fedora release comes out.  If the feature passes the test
plan then the Feature is announced.  If it fails the test plan, then
whatever is in the Contingency Plan would go into effect.

For MinGW, I'd ask, how do you know that the libraries you produce are
working?  What basic goals should someone be able to achieve when using
them?  What tasks can a tester do to show that someone wanting to
utilize the feature is not going to be frustrated and disappointed?

-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/20081114/9b08c392/attachment.sig>

From notting at redhat.com  Fri Nov 14 18:48:49 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 14 Nov 2008 13:48:49 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811141256010.26126@localhost.localdomain>
References: <1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
	<alpine.LFD.2.00.0811130954360.19678@localhost.localdomain>
	<87ej1fhatg.fsf@fc5.bigo.ensc.de>
	<1226676673.22230.212.camel@code.and.org>
	<20081114162610.GA30721@nostromo.devel.redhat.com>
	<1226681186.11393.26.camel@luminos.localdomain>
	<1226684812.4355.10.camel@code.and.org>
	<alpine.LFD.2.00.0811141256010.26126@localhost.localdomain>
Message-ID: <20081114184849.GH30721@nostromo.devel.redhat.com>

Seth Vidal (skvidal at fedoraproject.org) said: 
> Curiously enough you could make a fedora spin repodata now with  
> mergerepo and then modifyrepo to add the spin-specific comps and  
> provider-selection metadata all pointing back to 'everything' for the  
> actual packages.

Or (sick thought of the day) have a package that drops a unchanging
repo definition, comps file, preferred app, metadata all on the local
disk, to define defaults for that install.

Bill



From notting at redhat.com  Fri Nov 14 18:51:01 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 14 Nov 2008 13:51:01 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <491DB5B8.6070600@gmail.com>
References: <20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>
	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>
	<faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>
	<alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>
	<46a038f90811140503q298c8f62p823125626451f0a@mail.gmail.com>
	<20081114165622.GC30721@nostromo.devel.redhat.com>
	<491DB5B8.6070600@gmail.com>
Message-ID: <20081114185101.GI30721@nostromo.devel.redhat.com>

Les Mikesell (lesmikesell at gmail.com) said: 
>>> It's already a bit of a black art to know what things to tweak to turn
>>> Fedora into a server-style configuration without breaking things. And
>>> it's growing -- in this thread I've learned about how to get the
>>> text-mode plymouth plugin. I'm sure there's lots more.
>>
>> Don't worry, we made that knowledge obsolete.
>
> That's the real problem...

The problem is that we listened to the complaint about solar being
installed by default, and fixed the bug before we released?

Bill, confused...



From notting at redhat.com  Fri Nov 14 18:55:12 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 14 Nov 2008 13:55:12 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <491CDA27.7020300@gmail.com>
References: <20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<491CB56B.7090304@gmail.com>
	<20081113234708.GB6227@nostromo.devel.redhat.com>
	<491CDA27.7020300@gmail.com>
Message-ID: <20081114185512.GJ30721@nostromo.devel.redhat.com>

Les Mikesell (lesmikesell at gmail.com) said: 
> Nearly all the machines I manage have hot-swap bays, and I want to mount  
> the contents by a name related to its bay position which I know (or can  
> easily be told over the phone), 

/dev/disk/by-path/pci-<domain>:<bus>:<dev>.<fn>-scsi-<host>:<channel>:<id>:<lun>-part<number>

It's long, but it works now.

Bill



From fedora at leemhuis.info  Fri Nov 14 19:04:30 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Fri, 14 Nov 2008 20:04:30 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <1226686183.13086.34.camel@aglarond.local>
References: <1226429441.3593.77.camel@eagle.danny.cz>	<1226588572.4714.4.camel@localhost.localdomain>	<20081113160203.GD1538120@hiwaay.net>	<1226592802.3651.30.camel@eagle.danny.cz>	<1226593460.13077.91.camel@aglarond.local>	<20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>	<faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>	<alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>	<1226678870.636.37.camel@aglarond.local>	<alpine.LFD.2.00.0811141227290.26126@localhost.localdomain>	<491DBB4B.3090602@leemhuis.info>
	<1226686183.13086.34.camel@aglarond.local>
Message-ID: <491DCBBE.6030500@leemhuis.info>

On 14.11.2008 19:09, Jeremy Katz wrote:
> On Fri, 2008-11-14 at 18:54 +0100, Thorsten Leemhuis wrote:
>>> I'm not saying we keep everything forever, I am saying we might consider 
>>> thinking a bit more before deciding to implement a brand new system 
>>> as solution to an existing problem.
>> That IMHO is a general problem in Fedora and IMHO one of the biggest 
>> problems of Fedora.
> But it's also one of the often-posited strengths of Fedora -- we push
> the edge forward which in the end benefits everyone

Well, I don't think or meant that we should slow down. But we afaics 
should sometimes offer the old known to working stuff as alternative 
when new shiny long term replacement is not a fully working replacement 
yet for 99.5 % of the users.

But yeah, it's hard to draw a line where a "alternative" is wise/needed 
and how much work it's worth to keep it running. I for one would have 
said that in the Juju case a alternative would have been wise and worth 
the work for one release. Otoh is imho was good that we didn't offer a 
alternative for the X-Server 1.5 to make the proprietary drivers work -- 
but I'm sure a lot of people will disagree with the latter.

>> One examples from the last two years: the new firewire stack JuJu. It 
>> afaics is a improvement now, but it was a bit to early when we shipped 
>> it as the "one and only" Firewire stack.
>>
>> Fedora as a whole IMHO should act a bit more like the kernel developers 
>> that have that "no regressions in new kernels" as goal -- they don't 
>> reach that goal completely but they are quite close afaics.
> 
> Kernel developers might argue about the success there.  It definitely
> doesn't match a lot of experiences I see from blogs, bugzilla, random
> other reading of the internets :/

Well, you have a good point, but they are afaics noticeable better then 
Fedora.

Cu
knurd



From mschwendt at gmail.com  Fri Nov 14 19:10:17 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 14 Nov 2008 19:10:17 -0000
Subject: Broken dependencies in Fedora 8 - 2008-11-14
Message-ID: <20081114191017.18656.33218@faldor.intranet>

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

    lxtnow AT gmail.com
        gspiceui

    nigjones AT redhat.com
        mediawiki-SpecialInterwiki

    oliver AT linux-kernel.at
        syck

    rmeggins AT redhat.com
        idm-console-framework

    silfreed AT silfreed.net
        pytrainer

    tcallawa AT redhat.com
        R-bigmemory


======================================================================
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:

    R-bigmemory-2.3-3.fc8.i386  requires  texlive-latex
    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
    pytrainer-1.6.0.5-4.fc8.noarch  requires  firefox = 0:2.0.0.17


======================================================================
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
    pytrainer-1.6.0.5-4.fc8.noarch  requires  firefox = 0:2.0.0.17


======================================================================
Broken packages in fedora-updates-8-ppc64:

    gspiceui-0.9.65-2.fc8.ppc64  requires  gwave
    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
    pytrainer-1.6.0.5-4.fc8.noarch  requires  firefox = 0:2.0.0.17


======================================================================
Broken packages in fedora-updates-8-x86_64:

    R-bigmemory-2.3-3.fc8.x86_64  requires  texlive-latex
    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
    pytrainer-1.6.0.5-4.fc8.noarch  requires  firefox = 0:2.0.0.17



From mschwendt at gmail.com  Fri Nov 14 19:24:50 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 14 Nov 2008 19:24:50 -0000
Subject: Broken dependencies in Fedora 9 - 2008-11-14
Message-ID: <20081114192450.18827.51863@faldor.intranet>

Summary of broken packages (by owner):

    alexl AT users.sourceforge.net
        blam

    berrange AT redhat.com
        perl-Test-AutoBuild

    debarshi.ray AT gmail.com
        anjuta

    dhuff AT redhat.com
        appliance-tools

    ebmunson AT us.ibm.com
        libhugetlbfs
        lsvpd

    fedora AT deadbabylon.de
        kcoloredit
        kiconedit

    gauret AT free.fr
        basket
        grisbi

    katzj AT redhat.com
        livecd-tools

    lxtnow AT gmail.com
        gspiceui

    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

    roozbeh AT farsiweb.info
        translate-toolkit

    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
    grisbi-0.5.9-5.fc9.i386  requires  tetex-unicode
    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
    grisbi-0.5.9-5.fc9.ppc  requires  tetex-unicode
    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
    grisbi-0.5.9-5.fc9.ppc64  requires  tetex-unicode
    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
    grisbi-0.5.9-5.fc9.x86_64  requires  tetex-unicode
    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:

    basket-kontact-1.0.3.1-2.fc9.i386  requires  kontact
    blam-1.8.5-2.fc9.i386  requires  gecko-libs = 0:1.9.0.2
    cyphesis-0.5.15-8.fc9.i386  requires  libmercator-0.2.so.4
    lsvpd-1.6.4-1.fc9.i386  requires  libvpd_cxx-2.0.so.1
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11


======================================================================
Broken packages in fedora-updates-9-ppc:

    basket-kontact-1.0.3.1-2.fc9.ppc  requires  kontact
    blam-1.8.5-2.fc9.ppc  requires  gecko-libs = 0:1.9.0.2
    cyphesis-0.5.15-8.fc9.ppc  requires  libmercator-0.2.so.4
    lsvpd-1.6.4-1.fc9.ppc  requires  libvpd_cxx-2.0.so.1
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11


======================================================================
Broken packages in fedora-updates-9-ppc64:

    basket-kontact-1.0.3.1-2.fc9.ppc64  requires  kontact
    cyphesis-0.5.15-8.fc9.ppc64  requires  libmercator-0.2.so.4()(64bit)
    gspiceui-0.9.65-2.fc9.ppc64  requires  gwave
    livecd-tools-017.1-1.fc9.ppc64  requires  yaboot
    lsvpd-1.6.4-1.fc9.ppc64  requires  libvpd_cxx-2.0.so.1()(64bit)
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11


======================================================================
Broken packages in fedora-updates-9-x86_64:

    basket-kontact-1.0.3.1-2.fc9.x86_64  requires  kontact
    blam-1.8.5-2.fc9.x86_64  requires  gecko-libs = 0:1.9.0.2
    cyphesis-0.5.15-8.fc9.x86_64  requires  libmercator-0.2.so.4()(64bit)
    lsvpd-1.6.4-1.fc9.x86_64  requires  libvpd_cxx-2.0.so.1()(64bit)
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11


======================================================================
Broken packages in fedora-updates-testing-9-i386:

    1:anjuta-2.4.2-2.fc9.i386  requires  libglade2 >= 0:2.6.2-6
    1:anjuta-devel-2.4.2-2.fc9.i386  requires  libglade2-devel >= 0:2.6.2-6
    kcoloredit-4.1.3-1.fc9.i386  requires  kdelibs4 >= 0:4.1.3
    kiconedit-4.1.3-1.fc9.i386  requires  kdelibs4 >= 0:4.1.3


======================================================================
Broken packages in fedora-updates-testing-9-ppc:

    1:anjuta-2.4.2-2.fc9.ppc  requires  libglade2 >= 0:2.6.2-6
    1:anjuta-2.4.2-2.fc9.ppc64  requires  libglade2 >= 0:2.6.2-6
    1:anjuta-devel-2.4.2-2.fc9.ppc  requires  libglade2-devel >= 0:2.6.2-6
    1:anjuta-devel-2.4.2-2.fc9.ppc64  requires  libglade2-devel >= 0:2.6.2-6
    kcoloredit-4.1.3-1.fc9.ppc  requires  kdelibs4 >= 0:4.1.3
    kiconedit-4.1.3-1.fc9.ppc  requires  kdelibs4 >= 0:4.1.3
    translate-toolkit-1.2.0-1.fc9.noarch  requires  python-psyco


======================================================================
Broken packages in fedora-updates-testing-9-ppc64:

    1:anjuta-2.4.2-2.fc9.ppc64  requires  libglade2 >= 0:2.6.2-6
    1:anjuta-devel-2.4.2-2.fc9.ppc64  requires  libglade2-devel >= 0:2.6.2-6
    appliance-tools-002.6-1.fc9.noarch  requires  qemu-img
    kcoloredit-4.1.3-1.fc9.ppc64  requires  kdelibs4 >= 0:4.1.3
    kiconedit-4.1.3-1.fc9.ppc64  requires  kdelibs4 >= 0:4.1.3
    translate-toolkit-1.2.0-1.fc9.noarch  requires  python-psyco


======================================================================
Broken packages in fedora-updates-testing-9-x86_64:

    1:anjuta-2.4.2-2.fc9.i386  requires  libglade2 >= 0:2.6.2-6
    1:anjuta-2.4.2-2.fc9.x86_64  requires  libglade2 >= 0:2.6.2-6
    1:anjuta-devel-2.4.2-2.fc9.i386  requires  libglade2-devel >= 0:2.6.2-6
    1:anjuta-devel-2.4.2-2.fc9.x86_64  requires  libglade2-devel >= 0:2.6.2-6
    kcoloredit-4.1.3-1.fc9.x86_64  requires  kdelibs4 >= 0:4.1.3
    kiconedit-4.1.3-1.fc9.x86_64  requires  kdelibs4 >= 0:4.1.3
    translate-toolkit-1.2.0-1.fc9.noarch  requires  python-psyco



From lesmikesell at gmail.com  Fri Nov 14 19:32:05 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 14 Nov 2008 13:32:05 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <20081114184849.GH30721@nostromo.devel.redhat.com>
References: <1226517797.5295.13.camel@luminos.localdomain>	<20081112200750.GF1461854@hiwaay.net>	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>	<alpine.LFD.2.00.0811130954360.19678@localhost.localdomain>	<87ej1fhatg.fsf@fc5.bigo.ensc.de>	<1226676673.22230.212.camel@code.and.org>	<20081114162610.GA30721@nostromo.devel.redhat.com>	<1226681186.11393.26.camel@luminos.localdomain>	<1226684812.4355.10.camel@code.and.org>	<alpine.LFD.2.00.0811141256010.26126@localhost.localdomain>
	<20081114184849.GH30721@nostromo.devel.redhat.com>
Message-ID: <491DD235.1080807@gmail.com>

Bill Nottingham wrote:
> Seth Vidal (skvidal at fedoraproject.org) said: 
>> Curiously enough you could make a fedora spin repodata now with  
>> mergerepo and then modifyrepo to add the spin-specific comps and  
>> provider-selection metadata all pointing back to 'everything' for the  
>> actual packages.
> 
> Or (sick thought of the day) have a package that drops a unchanging
> repo definition, comps file, preferred app, metadata all on the local
> disk, to define defaults for that install.

I'm still conviced that what is needed is a simple way to export a 
complete installed list from any working machine along with repo and 
version information that the machine repeating the install can use or 
ignore.  That way there is no guesswork in the installer and it works 
the same for a spin providing some extra stuff in  an additional repo 
and a local shop with local packages in a local repo.

-- 
   Les Mikesell
    lesmikesell at gmail.com




From vonbrand at inf.utfsm.cl  Fri Nov 14 19:28:38 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Fri, 14 Nov 2008 16:28:38 -0300
Subject: starting Fedora Server SIG
In-Reply-To: <20081114174513.GA6394@mokona.greysector.net>
References: <491AF259.40907@comcast.net> <20081112191551.GC1461854@hiwaay.net>
	<1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
	<alpine.LFD.2.00.0811130954360.19678@localhost.localdomain>
	<87ej1fhatg.fsf@fc5.bigo.ensc.de>
	<1226676673.22230.212.camel@code.and.org>
	<20081114162610.GA30721@nostromo.devel.redhat.com>
	<1226681186.11393.26.camel@luminos.localdomain>
	<20081114174513.GA6394@mokona.greysector.net>
Message-ID: <200811141928.mAEJScK0007822@laptop14.inf.utfsm.cl>

Dominik 'Rathann' Mierzejewski <dominik at greysector.net> wrote:
> On Friday, 14 November 2008 at 17:46, Jesse Keating wrote:
> > On Fri, 2008-11-14 at 11:26 -0500, Bill Nottingham wrote:
> > > > > How do you define/configure a "good default course"?
> > > > 
> > > >  I've recently posted a patch to the yum ML which would allow Fedora (or
> > > > any active repo.) to configure these choices manually. We could then
> > > > also easily have different defaults for the desktop vs. the server
> > > > spins.
> > > 
> > > Where would you store per-spin defaults, as they all point to the
> > > same repo?
> > 
> > 
> > And how would you account for multiple repos providing this
> > information... differently?  Which repo wins?

> That's easy, just make per-spin packages with the appropriate config
> files (for some yum plugin, perhaps?). Make them conflict with each
> other explicitly, too.

How on earth would I know with which packages from /other/ spins to clash?
-- 
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 silfreed at silfreed.net  Fri Nov 14 19:39:28 2008
From: silfreed at silfreed.net (Douglas E. Warner)
Date: Fri, 14 Nov 2008 14:39:28 -0500
Subject: Broken dependencies in Fedora 8 - 2008-11-14
In-Reply-To: <20081114191017.18656.33218@faldor.intranet>
References: <20081114191017.18656.33218@faldor.intranet>
Message-ID: <491DD3F0.2040301@silfreed.net>

Michael Schwendt wrote:
>     silfreed AT silfreed.net
>         pytrainer
[snip]
>     pytrainer-1.6.0.5-4.fc8.noarch  requires  firefox = 0:2.0.0.17

Update pushed.

-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/20081114/53fab6e1/attachment.sig>

From choeger at cs.tu-berlin.de  Fri Nov 14 19:41:17 2008
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Fri, 14 Nov 2008 20:41:17 +0100
Subject: fedora 10 avahi & firewall weirdness
Message-ID: <1226691677.2910.36.camel@choeger5.umpa.netz>

Hi,

I hope someone can clearify this for me.

I have avahi activated on my desktop and wanted to discover services
from my notebook (e.g. conduit). Both avahi servers use the default
configuration (local domain).
Running avahi-discover from my notebook worked with activated firewall
on the host.
On the host itself _no_ services were discovered while the fw was
activated - deactivating fixed it.
Why that? A normal fw configuration (my fw runs fedora default config)
should not deny any packets from the inside, that are accepted from the
outside. But obviously it does.

any thoughts?

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/20081114/f86e0552/attachment.sig>

From dominik at greysector.net  Fri Nov 14 19:45:13 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Fri, 14 Nov 2008 20:45:13 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <200811141928.mAEJScK0007822@laptop14.inf.utfsm.cl>
References: <1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
	<alpine.LFD.2.00.0811130954360.19678@localhost.localdomain>
	<87ej1fhatg.fsf@fc5.bigo.ensc.de>
	<1226676673.22230.212.camel@code.and.org>
	<20081114162610.GA30721@nostromo.devel.redhat.com>
	<1226681186.11393.26.camel@luminos.localdomain>
	<20081114174513.GA6394@mokona.greysector.net>
	<200811141928.mAEJScK0007822@laptop14.inf.utfsm.cl>
Message-ID: <20081114194512.GA6699@mokona.greysector.net>

On Friday, 14 November 2008 at 20:28, Horst H. von Brand wrote:
> Dominik 'Rathann' Mierzejewski <dominik at greysector.net> wrote:
> > On Friday, 14 November 2008 at 17:46, Jesse Keating wrote:
> > > On Fri, 2008-11-14 at 11:26 -0500, Bill Nottingham wrote:
> > > > > > How do you define/configure a "good default course"?
> > > > > 
> > > > >  I've recently posted a patch to the yum ML which would allow Fedora (or
> > > > > any active repo.) to configure these choices manually. We could then
> > > > > also easily have different defaults for the desktop vs. the server
> > > > > spins.
> > > > 
> > > > Where would you store per-spin defaults, as they all point to the
> > > > same repo?
> > > 
> > > 
> > > And how would you account for multiple repos providing this
> > > information... differently?  Which repo wins?
> 
> > That's easy, just make per-spin packages with the appropriate config
> > files (for some yum plugin, perhaps?). Make them conflict with each
> > other explicitly, too.
> 
> How on earth would I know with which packages from /other/ spins to clash?

These packages could be built from one src.rpm, making it easy to keep
a central list.

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 dhuff at redhat.com  Fri Nov 14 19:45:57 2008
From: dhuff at redhat.com (David Huff)
Date: Fri, 14 Nov 2008 14:45:57 -0500
Subject: Broken dependencies in Fedora 9 - 2008-11-14
In-Reply-To: <20081114192450.18827.51863@faldor.intranet>
References: <20081114192450.18827.51863@faldor.intranet>
Message-ID: <491DD575.1070200@redhat.com>

Michael Schwendt wrote:
> Broken packages in fedora-updates-testing-9-ppc64:
> 
>     appliance-tools-002.6-1.fc9.noarch  requires  qemu-img

To address this I added "ExclusiveArch: %{ix86} x86_64 ppc alpha sparc 
armv4l noarch", to the spec [1] which matches the qemu package.  I was 
told that this would prevent the compose tools form adding the 
appliance-tools rpm to the ppc64 tree.

-D

[1] 
http://cvs.fedoraproject.org/viewvc/rpms/appliance-tools/F-9/appliance-tools.spec?revision=1.4&view=markup



From lesmikesell at gmail.com  Fri Nov 14 19:50:51 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 14 Nov 2008 13:50:51 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <20081114185101.GI30721@nostromo.devel.redhat.com>
References: <20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>	<faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>	<alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>	<46a038f90811140503q298c8f62p823125626451f0a@mail.gmail.com>	<20081114165622.GC30721@nostromo.devel.redhat.com>	<491DB5B8.6070600@gmail.com>
	<20081114185101.GI30721@nostromo.devel.redhat.com>
Message-ID: <491DD69B.2020101@gmail.com>

Bill Nottingham wrote:
> Les Mikesell (lesmikesell at gmail.com) said: 
>>>> It's already a bit of a black art to know what things to tweak to turn
>>>> Fedora into a server-style configuration without breaking things. And
>>>> it's growing -- in this thread I've learned about how to get the
>>>> text-mode plymouth plugin. I'm sure there's lots more.
>>> Don't worry, we made that knowledge obsolete.
>> That's the real problem...
> 
> The problem is that we listened to the complaint about solar being
> installed by default, and fixed the bug before we released?
> 

The problem is making any esoteric knowledge required and then making it 
obsolete.  If you start without any unix experience it may all look the 
same, but for someone who runs large existing server farms (and remember 
that is where the bulk of linux systems are) any change in 
administration procedures or interaction with other systems (monitoring, 
snmp management, etc.) is a big cost.  If learning the new approach 
provides some improvement and can be expected to be useful for a long 
time is may be worth it, but in general things that can't provide 
complete backwards emulation are not improvements at all.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From alsadi at gmail.com  Fri Nov 14 19:53:54 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Fri, 14 Nov 2008 21:53:54 +0200
Subject: sound skipping in F10
In-Reply-To: <62b1552c0811140956s412b937cmacd4c6bcdbde292b@mail.gmail.com>
References: <385866f0811091311q31e1a367u9de08b054a9e0989@mail.gmail.com>
	<4917652E.3020004@gmail.com> <4917A540.7050108@fedoraproject.org>
	<4917F695.2040005@gmail.com>
	<385866f0811100619u55d9bce8rcb3bae30c8ec09b4@mail.gmail.com>
	<385866f0811100621w3410f3bp1b111e4890ad7d33@mail.gmail.com>
	<62b1552c0811140956s412b937cmacd4c6bcdbde292b@mail.gmail.com>
Message-ID: <385866f0811141153o1c84f4f1h72565602062c55ad@mail.gmail.com>

are you sure!! AFAIK modeset is about video not audio

after the last update to the kernel I hear lesser skips
(you may thought it's the nomodeset thing)
but the problem is still there



From cmadams at hiwaay.net  Fri Nov 14 20:08:42 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 14 Nov 2008 14:08:42 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1226678932.636.40.camel@aglarond.local>
References: <1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
Message-ID: <20081114200842.GD1142545@hiwaay.net>

Once upon a time, Jeremy Katz <katzj at redhat.com> said:
> One of the things about progress and getting to a more mature *platform*
> that is suitable across a wide range of uses is change.  I'm not saying
> that NetworkManager is perfect yet for the server needs.  But having
> people that want to run a server say "pound sand, go the hell away, we
> don't want to run your new-fangled stuff" doesn't help us get to where
> it is.

Having developers say "pound sand, go the hell away, we don't want you
to be able to do things the way you've been doing them for 10+ years"
doesn't help either.

A stack of daemons cannot be as reliable as ifconfig/route.  Having a
stack of daemons running for something that will not change is useless.

I do care about the desktop, and I use NM on my notebook (not on my
workstations that have a single interface with a single static IP).  I
have to shut it down on my notebook sometimes because it doesn't handle
some of my normal usage (multiple wired NICs, wired and wireless to
different networks, etc.).

I just don't see it as being useful or desired on my servers.  Any
daemon that isn't useful should be disabled (that is sysadmin 101).

-- 
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 skvidal at fedoraproject.org  Fri Nov 14 20:12:11 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 14 Nov 2008 15:12:11 -0500 (EST)
Subject: starting Fedora Server SIG
In-Reply-To: <20081114200842.GD1142545@hiwaay.net>
References: <1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<20081114200842.GD1142545@hiwaay.net>
Message-ID: <alpine.LFD.2.00.0811141511210.825@localhost.localdomain>



On Fri, 14 Nov 2008, Chris Adams wrote:

>
> I just don't see it as being useful or desired on my servers.  Any
> daemon that isn't useful should be disabled (that is sysadmin 101).

s/useful/necessary/

NM is useful, there's no mistaking that, it's just not necessary and 
therefore it is a place where errors can happen.

-sv



From martin.langhoff at gmail.com  Fri Nov 14 20:17:21 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Fri, 14 Nov 2008 15:17:21 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <1226686948.13086.44.camel@aglarond.local>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>
	<1226686948.13086.44.camel@aglarond.local>
Message-ID: <46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>

On Fri, Nov 14, 2008 at 1:22 PM, Jeremy Katz <katzj at redhat.com> wrote:
> On Fri, 2008-11-14 at 13:13 -0500, Martin Langhoff wrote:
>> I agree with the desire to maintain only one tool. However, NM is
>> extremely desktop oriented, and there seems to include no hint of an
>> intention to support the complex setups that are possible with the old
>> ifcfg infra.
>
> Really?  Most of the work over the past couple of years in NM seems to
> be aimed at trying to support these cases as opposed to just the
> "simple" desktop case

That's odd -- I've never seen any of it. Are there good examples of
how you configure a server to do special stuff with it? Or a
'scripting network-manager' guide somewhere?

> The NetworkManager dispatcher stuff has existed forever and is all about
> scripting.  Not necessarily pre-interface bringup, but post.  And
> depending on scripting slows things down and makes it a lot harder to
> have a deterministic view of what's been done.

Network-related events happen very seldom -- so scripting is a good
fit. My ifup/ifdown experience is not dominated by bash startup time.

> And rather than focusing on nm-tool and exactly what it exposes, it's
> probably more interesting to look at the dbus interfaces/daemon
> capabilities.  Yes, I'll be one of the first to say it's painful to
> write code interacting with dbus :-) -- but, it is very flexible and

And
 - it's very far removed from the stuff that a unix sysadmin deals with
 - it forces me to have a script running to listen to dbus events :-/

 > then as what the real use cases that people care about become clearer,
> it's easier to write very lean, very specific tools to do what they need
> as long as the backend and dbus interfaces are sufficient

I'm keen on learning more about the hooks and scriptability, mostly
thinking of desktop cases. From a server perspective, running the nm
daemon _plus_ running a daemon of my own to listen to dbus events...
is not a winning proposition.

If the API design of NM is better laid out to do things in a more
deterministic way, then great, let's learn those tricks and apply them
to a solution that doesn't require fat daemons spinning in the bg all
the time (running as root!), and that can hopefully be implemented in
shell scripts or something similar.

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 vonbrand at inf.utfsm.cl  Fri Nov 14 20:17:40 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Fri, 14 Nov 2008 17:17:40 -0300
Subject: starting Fedora Server SIG
In-Reply-To: <20081114194512.GA6699@mokona.greysector.net>
References: <1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
	<alpine.LFD.2.00.0811130954360.19678@localhost.localdomain>
	<87ej1fhatg.fsf@fc5.bigo.ensc.de>
	<1226676673.22230.212.camel@code.and.org>
	<20081114162610.GA30721@nostromo.devel.redhat.com>
	<1226681186.11393.26.camel@luminos.localdomain>
	<20081114174513.GA6394@mokona.greysector.net>
	<200811141928.mAEJScK0007822@laptop14.inf.utfsm.cl>
	<20081114194512.GA6699@mokona.greysector.net>
Message-ID: <200811142017.mAEKHe9X003800@laptop14.inf.utfsm.cl>

Dominik 'Rathann' Mierzejewski <dominik at greysector.net> wrote:
> On Friday, 14 November 2008 at 20:28, Horst H. von Brand wrote:
> > Dominik 'Rathann' Mierzejewski <dominik at greysector.net> wrote:
> > > On Friday, 14 November 2008 at 17:46, Jesse Keating wrote:
> > > > On Fri, 2008-11-14 at 11:26 -0500, Bill Nottingham wrote:
> > > > > > > How do you define/configure a "good default course"?
> > > > > > 
> > > > > >  I've recently posted a patch to the yum ML which would allow Fedora (or
> > > > > > any active repo.) to configure these choices manually. We could then
> > > > > > also easily have different defaults for the desktop vs. the server
> > > > > > spins.
> > > > > 
> > > > > Where would you store per-spin defaults, as they all point to the
> > > > > same repo?
> > > > 
> > > > 
> > > > And how would you account for multiple repos providing this
> > > > information... differently?  Which repo wins?
> > 
> > > That's easy, just make per-spin packages with the appropriate config
> > > files (for some yum plugin, perhaps?). Make them conflict with each
> > > other explicitly, too.
> > 
> > How on earth would I know with which packages from /other/ spins to clash?

> These packages could be built from one src.rpm, making it easy to keep
> a central list.

Then they aren't spin-local anymore, and make little sense.
-- 
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 pbrobinson at gmail.com  Fri Nov 14 20:19:53 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Fri, 14 Nov 2008 20:19:53 +0000
Subject: fedora 10 avahi & firewall weirdness
In-Reply-To: <1226691677.2910.36.camel@choeger5.umpa.netz>
References: <1226691677.2910.36.camel@choeger5.umpa.netz>
Message-ID: <5256d0b0811141219w15975ad5va30ee2f4deee31b7@mail.gmail.com>

> I hope someone can clearify this for me.
>
> I have avahi activated on my desktop and wanted to discover services
> from my notebook (e.g. conduit). Both avahi servers use the default
> configuration (local domain).
> Running avahi-discover from my notebook worked with activated firewall
> on the host.
> On the host itself _no_ services were discovered while the fw was
> activated - deactivating fixed it.
> Why that? A normal fw configuration (my fw runs fedora default config)
> should not deny any packets from the inside, that are accepted from the
> outside. But obviously it does.
>
> any thoughts?

I think Fedora 9 firewall would allow avahi discovery packets through
by default, Fedora 10 doesn't. You'd need to add the appropriate rules
back to allow the avahi traffic through.

Peter



From dmalcolm at redhat.com  Fri Nov 14 20:25:37 2008
From: dmalcolm at redhat.com (David Malcolm)
Date: Fri, 14 Nov 2008 15:25:37 -0500
Subject: Manpages for DBus services?  was Re: starting Fedora Server SIG
In-Reply-To: <46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>
	<1226686948.13086.44.camel@aglarond.local>
	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>
Message-ID: <1226694337.20390.58.camel@radiator.bos.redhat.com>


On Fri, 2008-11-14 at 15:17 -0500, Martin Langhoff wrote:
> On Fri, Nov 14, 2008 at 1:22 PM, Jeremy Katz <katzj at redhat.com> wrote:
> > On Fri, 2008-11-14 at 13:13 -0500, Martin Langhoff wrote:
> >> I agree with the desire to maintain only one tool. However, NM is
> >> extremely desktop oriented, and there seems to include no hint of an
> >> intention to support the complex setups that are possible with the old
> >> ifcfg infra.
> >
> > Really?  Most of the work over the past couple of years in NM seems to
> > be aimed at trying to support these cases as opposed to just the
> > "simple" desktop case
> 
> That's odd -- I've never seen any of it. Are there good examples of
> how you configure a server to do special stuff with it? Or a
> 'scripting network-manager' guide somewhere?
> 
> > The NetworkManager dispatcher stuff has existed forever and is all about
> > scripting.  Not necessarily pre-interface bringup, but post.  And
> > depending on scripting slows things down and makes it a lot harder to
> > have a deterministic view of what's been done.
> 
> Network-related events happen very seldom -- so scripting is a good
> fit. My ifup/ifdown experience is not dominated by bash startup time.
> 
> > And rather than focusing on nm-tool and exactly what it exposes, it's
> > probably more interesting to look at the dbus interfaces/daemon
> > capabilities.  Yes, I'll be one of the first to say it's painful to
> > write code interacting with dbus :-) -- but, it is very flexible and
> 
> And
>  - it's very far removed from the stuff that a unix sysadmin deals with
>  - it forces me to have a script running to listen to dbus events :-/
> 
>  > then as what the real use cases that people care about become clearer,
> > it's easier to write very lean, very specific tools to do what they need
> > as long as the backend and dbus interfaces are sufficient
> 
> I'm keen on learning more about the hooks and scriptability, mostly
> thinking of desktop cases. From a server perspective, running the nm
> daemon _plus_ running a daemon of my own to listen to dbus events...
> is not a winning proposition.
> 
> If the API design of NM is better laid out to do things in a more
> deterministic way, then great, let's learn those tricks and apply them
> to a solution that doesn't require fat daemons spinning in the bg all
> the time (running as root!), and that can hopefully be implemented in
> shell scripts or something similar.
> 

Brainstorming here, but do DBus services come with some form of
documentation format?  If so, it it possible to generate a man page per
service, and ship it in the rpm, as one step towards making DBus more
accessible to old-school Unix types?

Hope this helps
Dave



From mschwendt at gmail.com  Fri Nov 14 20:33:52 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 14 Nov 2008 21:33:52 +0100
Subject: Broken dependencies in Fedora 9 - 2008-11-14
In-Reply-To: <491DD575.1070200@redhat.com>
References: <20081114192450.18827.51863@faldor.intranet>
	<491DD575.1070200@redhat.com>
Message-ID: <20081114213352.2f073127.mschwendt@gmail.com>

On Fri, 14 Nov 2008 14:45:57 -0500, David Huff wrote:

> Michael Schwendt wrote:
> > Broken packages in fedora-updates-testing-9-ppc64:
> > 
> >     appliance-tools-002.6-1.fc9.noarch  requires  qemu-img
> 
> To address this I added "ExclusiveArch: %{ix86} x86_64 ppc alpha sparc 
> armv4l noarch", to the spec [1] which matches the qemu package.  I was 
> told that this would prevent the compose tools form adding the 
> appliance-tools rpm to the ppc64 tree.

Why not "ExcludeArch: ppc64"?



From dhuff at redhat.com  Fri Nov 14 20:37:30 2008
From: dhuff at redhat.com (David Huff)
Date: Fri, 14 Nov 2008 15:37:30 -0500
Subject: Broken dependencies in Fedora 9 - 2008-11-14
In-Reply-To: <20081114213352.2f073127.mschwendt@gmail.com>
References: <20081114192450.18827.51863@faldor.intranet>	<491DD575.1070200@redhat.com>
	<20081114213352.2f073127.mschwendt@gmail.com>
Message-ID: <491DE18A.5060403@redhat.com>

Michael Schwendt wrote:
> On Fri, 14 Nov 2008 14:45:57 -0500, David Huff wrote:
> 
>> Michael Schwendt wrote:
>>> Broken packages in fedora-updates-testing-9-ppc64:
>>>
>>>     appliance-tools-002.6-1.fc9.noarch  requires  qemu-img
>> To address this I added "ExclusiveArch: %{ix86} x86_64 ppc alpha sparc 
>> armv4l noarch", to the spec [1] which matches the qemu package.  I was 
>> told that this would prevent the compose tools form adding the 
>> appliance-tools rpm to the ppc64 tree.
> 
> Why not "ExcludeArch: ppc64"?
> 
b/c qemu is also not in s390 and s390x.

-D



From martin.langhoff at gmail.com  Fri Nov 14 20:41:37 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Fri, 14 Nov 2008 15:41:37 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>
	<1226686948.13086.44.camel@aglarond.local>
	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>
Message-ID: <46a038f90811141241w2f3f8dcbqffa470bc53427987@mail.gmail.com>

On Fri, Nov 14, 2008 at 3:17 PM, Martin Langhoff
<martin.langhoff at gmail.com> wrote:
> On Fri, Nov 14, 2008 at 1:22 PM, Jeremy Katz <katzj at redhat.com> wrote:
>> On Fri, 2008-11-14 at 13:13 -0500, Martin Langhoff wrote:
>>> I agree with the desire to maintain only one tool. However, NM is
>>> extremely desktop oriented, and there seems to include no hint of an
>>> intention to support the complex setups that are possible with the old
>>> ifcfg infra.
>>
>> Really?  Most of the work over the past couple of years in NM seems to
>> be aimed at trying to support these cases as opposed to just the
>> "simple" desktop case
>
> That's odd -- I've never seen any of it. Are there good examples of
> how you configure a server to do special stuff with it? Or a
> 'scripting network-manager' guide somewhere?

A bit of reading of the NM website and published docs makes me think
that Jeremy is probably overoptimistic about the applicability of NM
to server roles, and any intentions of scriptability.

The design goals don't include scriptability or anything that would
resonate with sysadmins:
http://projects.gnome.org/NetworkManager/developers/design_goals.html

The page for administrators doesn't provide anything useful
http://projects.gnome.org/NetworkManager/admins/

And looking for an API leads me to this page (which is probably
outdated) - a very limited API that won't do any of the things I need
in the School Server.
http://people.redhat.com/dcbw/NetworkManager/NetworkManager%20DBUS%20API.txt

In summary I don't think NM is designed for this. OTOH, it does the
desktop thing well...




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 jspaleta at gmail.com  Fri Nov 14 20:43:49 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 14 Nov 2008 11:43:49 -0900
Subject: Manpages for DBus services? was Re: starting Fedora Server SIG
In-Reply-To: <1226694337.20390.58.camel@radiator.bos.redhat.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>
	<1226686948.13086.44.camel@aglarond.local>
	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>
	<1226694337.20390.58.camel@radiator.bos.redhat.com>
Message-ID: <604aa7910811141243l20f25e4cwdad8ea6ffd875038@mail.gmail.com>

On Fri, Nov 14, 2008 at 11:25 AM, David Malcolm <dmalcolm at redhat.com> wrote:
> Brainstorming here, but do DBus services come with some form of
> documentation format?  If so, it it possible to generate a man page per
> service, and ship it in the rpm, as one step towards making DBus more
> accessible to old-school Unix types?

doesn't dbus support some type of introspection for running
services... so something like pydoc command would works for python
modules for running dbus services?

-jef



From walters at verbum.org  Fri Nov 14 20:51:49 2008
From: walters at verbum.org (Colin Walters)
Date: Fri, 14 Nov 2008 15:51:49 -0500
Subject: Manpages for DBus services? was Re: starting Fedora Server SIG
In-Reply-To: <1226694337.20390.58.camel@radiator.bos.redhat.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>
	<1226686948.13086.44.camel@aglarond.local>
	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>
	<1226694337.20390.58.camel@radiator.bos.redhat.com>
Message-ID: <faa16b610811141251q492e9b76x22c2bdf246dd6686@mail.gmail.com>

On Fri, Nov 14, 2008 at 3:25 PM, David Malcolm <dmalcolm at redhat.com> wrote:
>
> Brainstorming here, but do DBus services come with some form of
> documentation format?

Not intrinsically, we decided it would be a bad idea to put docs in
the introspection XML.  However,

> If so, it it possible to generate a man page per
> service, and ship it in the rpm, as one step towards making DBus more
> accessible to old-school Unix types?

Various projects do different things for interface documentation; for
NetworkManager in particular see here:
http://live.gnome.org/NetworkManagerDBusInterface

The documentation is not yet shipped in the package that I see though
(it probably should be in NetworkManager-devel).

For ConsoleKit there are docs in the shipped introspection XML:
/usr/share/dbus-1/interfaces/org.freedesktop.ConsoleKit.Manager.xml

Eventually we'll straighten this out and probably have some sort of
standard IDL and associated documentation, and probably have -devel
packages build and ship HTML formatted docs.  Up until now mostly
these interfaces have been for freedesktop/GNOME/KDE hackers to use
internally, not really for 3rd party developers.



From mschwendt at gmail.com  Fri Nov 14 20:53:35 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 14 Nov 2008 21:53:35 +0100
Subject: Broken dependencies in Fedora 9 - 2008-11-14
In-Reply-To: <491DE18A.5060403@redhat.com>
References: <20081114192450.18827.51863@faldor.intranet>
	<491DD575.1070200@redhat.com>
	<20081114213352.2f073127.mschwendt@gmail.com>
	<491DE18A.5060403@redhat.com>
Message-ID: <20081114215335.62ff72ab.mschwendt@gmail.com>

On Fri, 14 Nov 2008 15:37:30 -0500, David Huff wrote:

> Michael Schwendt wrote:
> > On Fri, 14 Nov 2008 14:45:57 -0500, David Huff wrote:
> > 
> >> Michael Schwendt wrote:
> >>> Broken packages in fedora-updates-testing-9-ppc64:
> >>>
> >>>     appliance-tools-002.6-1.fc9.noarch  requires  qemu-img
> >> To address this I added "ExclusiveArch: %{ix86} x86_64 ppc alpha sparc 
> >> armv4l noarch", to the spec [1] which matches the qemu package.  I was 
> >> told that this would prevent the compose tools form adding the 
> >> appliance-tools rpm to the ppc64 tree.
> > 
> > Why not "ExcludeArch: ppc64"?
> > 
> b/c qemu is also not in s390 and s390x.

"ExcludeArch: ppc64 s390 s390x" is still shorter than your ExclusiveArch
list, ... but I see qemu also doesn't use ExcludeArch.



From konrad at tylerc.org  Fri Nov 14 20:54:33 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Fri, 14 Nov 2008 13:54:33 -0700
Subject: Plan for tomorrows (20081112) FESCO meeting
In-Reply-To: <491DC70F.1050905@gmail.com>
References: <1226438839.26212.2.camel@kennedy>
	<20081114085057.GA10744@amd.home.annexia.org>
	<491DC70F.1050905@gmail.com>
Message-ID: <200811141254.33748.konrad@tylerc.org>

On Friday 14 November 2008 10:44:31 am Toshio Kuratomi wrote:
> Richard W.M. Jones wrote:
> > On Thu, Nov 13, 2008 at 01:14:02PM -0800, John Poelstra wrote:
> >> Richard W.M. Jones wrote:
> >>> https://fedoraproject.org/wiki/Features/Windows_cross_compiler
> >>
> >> The page appears to be only partially complete and in Category:
> >> FeaturePageIncomplete
> >
> > Yes because, erm, it's not complete.
>
> I think poelcat means, it's incomplete so won't be discussed yet :-)
>
> > Partly I have no idea what's supposed to go in the Test Plan section.
> > An actual test plan covering the features of all the libraries would
> > be huge and take weeks to run.  In addition, we have to disable %check
> > sections in MinGW packages because wine cannot run inside the mock/
> > koji environment.  Wine needs an X server and a writable $HOME.
>
> The test plan needs to tell people how to tell if the Feature is
> complete and whether it's reasonable to tell people it's ready to use
> when the next Fedora release comes out.  If the feature passes the test
> plan then the Feature is announced.  If it fails the test plan, then
> whatever is in the Contingency Plan would go into effect.
>
> For MinGW, I'd ask, how do you know that the libraries you produce are
> working?  What basic goals should someone be able to achieve when using
> them?  What tasks can a tester do to show that someone wanting to
> utilize the feature is not going to be frustrated and disappointed?
>
> -Toshio

Well, if you set PKG_CONFIG_PATH correctly it's pretty easy to compile an 
example a.exe of (just for example, again) a GTK application, that will 
(given appropriate dlls) run on Windows (or under Wine).

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




From sundaram at fedoraproject.org  Fri Nov 14 21:17:52 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 15 Nov 2008 02:47:52 +0530
Subject: starting Fedora Server SIG
In-Reply-To: <491DBB4B.3090602@leemhuis.info>
References: <1226429441.3593.77.camel@eagle.danny.cz>	<1226588572.4714.4.camel@localhost.localdomain>	<20081113160203.GD1538120@hiwaay.net>	<1226592802.3651.30.camel@eagle.danny.cz>	<1226593460.13077.91.camel@aglarond.local>	<20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>	<faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>	<alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>	<1226678870.636.37.camel@aglarond.local>	<alpine.LFD.2.00.0811141227290.26126@localhost.localdomain>
	<491DBB4B.3090602@leemhuis.info>
Message-ID: <491DEB00.5090206@fedoraproject.org>

Thorsten Leemhuis wrote:

> One examples from the last two years: the new firewire stack JuJu. It 
> afaics is a improvement now, but it was a bit to early when we shipped 
> it as the "one and only" Firewire stack.
> 
> Fedora as a whole IMHO should act a bit more like the kernel developers 
> that have that "no regressions in new kernels" as goal -- they don't 
> reach that goal completely but they are quite close afaics.

I might agree with the general idea but using the kernel as a example, 
leaves me in doubt especially since the firewire stack is part of the 
kernel.

Rahul



From debarshi.ray at gmail.com  Fri Nov 14 21:22:56 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Sat, 15 Nov 2008 02:52:56 +0530
Subject: Broken dependencies in Fedora 9 - 2008-11-14
In-Reply-To: <20081114192450.18827.51863@faldor.intranet>
References: <20081114192450.18827.51863@faldor.intranet>
Message-ID: <3170f42f0811141322r662aac98y73252fe6912fa062@mail.gmail.com>

> Broken packages in fedora-updates-testing-9-i386:
>
>    1:anjuta-2.4.2-2.fc9.i386  requires  libglade2 >= 0:2.6.2-6
>    1:anjuta-devel-2.4.2-2.fc9.i386  requires  libglade2-devel >= 0:2.6.2-6
>
> [...]
>
> Broken packages in fedora-updates-testing-9-ppc:
>
>    1:anjuta-2.4.2-2.fc9.ppc  requires  libglade2 >= 0:2.6.2-6
>    1:anjuta-2.4.2-2.fc9.ppc64  requires  libglade2 >= 0:2.6.2-6
>    1:anjuta-devel-2.4.2-2.fc9.ppc  requires  libglade2-devel >= 0:2.6.2-6
>    1:anjuta-devel-2.4.2-2.fc9.ppc64  requires  libglade2-devel >= 0:2.6.2-6
>
> [...]
>
> Broken packages in fedora-updates-testing-9-ppc64:
>
>    1:anjuta-2.4.2-2.fc9.ppc64  requires  libglade2 >= 0:2.6.2-6
>    1:anjuta-devel-2.4.2-2.fc9.ppc64  requires  libglade2-devel >= 0:2.6.2-6
>
> [...]
>
> Broken packages in fedora-updates-testing-9-x86_64:
>
>    1:anjuta-2.4.2-2.fc9.i386  requires  libglade2 >= 0:2.6.2-6
>    1:anjuta-2.4.2-2.fc9.x86_64  requires  libglade2 >= 0:2.6.2-6
>    1:anjuta-devel-2.4.2-2.fc9.i386  requires  libglade2-devel >= 0:2.6.2-6
>    1:anjuta-devel-2.4.2-2.fc9.x86_64  requires  libglade2-devel >= 0:2.6.2-6

Now that the libglade2 update has been pushed in Bodhi, this is taken care of.

Cheerio,
Debarshi



From mw_triad at users.sourceforge.net  Fri Nov 14 21:23:37 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Fri, 14 Nov 2008 15:23:37 -0600
Subject: Broken dependencies in Fedora 9 - 2008-11-14
In-Reply-To: <20081114213352.2f073127.mschwendt@gmail.com>
References: <20081114192450.18827.51863@faldor.intranet>	<491DD575.1070200@redhat.com>
	<20081114213352.2f073127.mschwendt@gmail.com>
Message-ID: <gfkq8p$bms$1@ger.gmane.org>

Michael Schwendt wrote:
> On Fri, 14 Nov 2008 14:45:57 -0500, David Huff wrote:
> 
>> Michael Schwendt wrote:
>>> Broken packages in fedora-updates-testing-9-ppc64:
>>>
>>>     appliance-tools-002.6-1.fc9.noarch  requires  qemu-img
>> To address this I added "ExclusiveArch: %{ix86} x86_64 ppc alpha sparc 
>> armv4l noarch", to the spec [1] which matches the qemu package.  I was 
>> told that this would prevent the compose tools form adding the 
>> appliance-tools rpm to the ppc64 tree.
> 
> Why not "ExcludeArch: ppc64"?

Just to offer an outside perspective... IMO ExcludeArch makes sense when 
a package is generically expected to work, but is known to have problems 
on specific architectures (i.e. not working is the exception, not the 
rule). For things like qemu (or valgrind, to give another example) that 
are highly arch-specific, it makes more sense to list the arches that 
are supported, even if that results in a longer list.

IOW, use whichever is more likely to DTRT when built on a totally novel 
arch (e.g. arm, sparc, whatever) ;-).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Person A: It's an ISO standard.
Person B: ...And that means what?
   -- mal (http://theangryadmin.blogspot.com/2008/04/future.html)



From tcallawa at redhat.com  Fri Nov 14 21:33:18 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 14 Nov 2008 16:33:18 -0500
Subject: Broken dependencies in Fedora 8 - 2008-11-14
In-Reply-To: <20081114191017.18656.33218@faldor.intranet>
References: <20081114191017.18656.33218@faldor.intranet>
Message-ID: <1226698398.3816.17.camel@localhost.localdomain>

On Fri, 2008-11-14 at 19:10 +0000, Michael Schwendt wrote:
> tcallawa AT redhat.com
>         R-bigmemory

Just pushed an update to resolve this, apologies.

~spot



From orion at cora.nwra.com  Fri Nov 14 21:42:51 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 14 Nov 2008 14:42:51 -0700
Subject: perl-PDL-owner@fedoraproject.org
Message-ID: <491DF0DB.1050309@cora.nwra.com>

I've started work on packaging perl-PDL 2.4.4.  Got a src.rpm that 
compiles, but some tests are segfaulting.  Just a heads up....

-- 
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 dhuff at redhat.com  Fri Nov 14 21:44:16 2008
From: dhuff at redhat.com (David Huff)
Date: Fri, 14 Nov 2008 16:44:16 -0500
Subject: Broken dependencies in Fedora 9 - 2008-11-14
In-Reply-To: <gfkq8p$bms$1@ger.gmane.org>
References: <20081114192450.18827.51863@faldor.intranet>	<491DD575.1070200@redhat.com>	<20081114213352.2f073127.mschwendt@gmail.com>
	<gfkq8p$bms$1@ger.gmane.org>
Message-ID: <491DF130.7040403@redhat.com>

Matthew Woehlke wrote:
> Michael Schwendt wrote:
>> On Fri, 14 Nov 2008 14:45:57 -0500, David Huff wrote:
>>
>>> Michael Schwendt wrote:
>>>> Broken packages in fedora-updates-testing-9-ppc64:
>>>>
>>>>     appliance-tools-002.6-1.fc9.noarch  requires  qemu-img
>>> To address this I added "ExclusiveArch: %{ix86} x86_64 ppc alpha 
>>> sparc armv4l noarch", to the spec [1] which matches the qemu 
>>> package.  I was told that this would prevent the compose tools form 
>>> adding the appliance-tools rpm to the ppc64 tree.
>>
>> Why not "ExcludeArch: ppc64"?
> 
> Just to offer an outside perspective... IMO ExcludeArch makes sense when 
> a package is generically expected to work, but is known to have problems 
> on specific architectures (i.e. not working is the exception, not the 
> rule). For things like qemu (or valgrind, to give another example) that 
> are highly arch-specific, it makes more sense to list the arches that 
> are supported, even if that results in a longer list.
> 

either way, it was my understanding that both ExclusinveArch and 
ExcludeArch would work, ie the compose tools will check the srpm and not 
include the package in a tree if specified in either of these feilds.

Im not sure if switching form ExclusinveArch to ExcludeArch will fix the 
issue at had.

Any comments, as I would like to run a new build to try and resolve this 
issue.

-D






From dcbw at redhat.com  Fri Nov 14 21:43:36 2008
From: dcbw at redhat.com (Dan Williams)
Date: Fri, 14 Nov 2008 16:43:36 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <491D8B6F.3040107@gmail.com>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>
	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>
	<faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>
	<alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>
	<491D8B6F.3040107@gmail.com>
Message-ID: <1226699016.27057.16.camel@localhost.localdomain>

On Fri, 2008-11-14 at 08:30 -0600, Les Mikesell wrote:
> Seth Vidal wrote:
> > 
> > Oh and my general opinion is that the features we should be working on 
> > more than anything else are simplicity, security and stability.
> 
> Yes, why does adding features need to break old ones any more than 
> adding new filesystems or device types would?

Because when you have to account for two codepaths that do the same
thing, it's quite a bit more maintenance and QA burden.  More code ==
more effort to maintain, and 2x more effort to test.

Dan




From dcbw at redhat.com  Fri Nov 14 21:47:22 2008
From: dcbw at redhat.com (Dan Williams)
Date: Fri, 14 Nov 2008 16:47:22 -0500
Subject: Manpages for DBus services? was Re: starting Fedora Server SIG
In-Reply-To: <faa16b610811141251q492e9b76x22c2bdf246dd6686@mail.gmail.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>
	<1226686948.13086.44.camel@aglarond.local>
	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>
	<1226694337.20390.58.camel@radiator.bos.redhat.com>
	<faa16b610811141251q492e9b76x22c2bdf246dd6686@mail.gmail.com>
Message-ID: <1226699242.27057.19.camel@localhost.localdomain>

On Fri, 2008-11-14 at 15:51 -0500, Colin Walters wrote:
> On Fri, Nov 14, 2008 at 3:25 PM, David Malcolm <dmalcolm at redhat.com> wrote:
> >
> > Brainstorming here, but do DBus services come with some form of
> > documentation format?
> 
> Not intrinsically, we decided it would be a bad idea to put docs in
> the introspection XML.  However,
> 
> > If so, it it possible to generate a man page per
> > service, and ship it in the rpm, as one step towards making DBus more
> > accessible to old-school Unix types?
> 
> Various projects do different things for interface documentation; for
> NetworkManager in particular see here:
> http://live.gnome.org/NetworkManagerDBusInterface

Actually, the docs are autogenerated from the introspection XML.  For
the moment, see:

http://people.redhat.com/dcbw/NetworkManager/spec.html

Yes, all the docs need improvement and cleanup.

Dan

> 
> The documentation is not yet shipped in the package that I see though
> (it probably should be in NetworkManager-devel).
> 
> For ConsoleKit there are docs in the shipped introspection XML:
> /usr/share/dbus-1/interfaces/org.freedesktop.ConsoleKit.Manager.xml
> 
> Eventually we'll straighten this out and probably have some sort of
> standard IDL and associated documentation, and probably have -devel
> packages build and ship HTML formatted docs.  Up until now mostly
> these interfaces have been for freedesktop/GNOME/KDE hackers to use
> internally, not really for 3rd party developers.
> 



From choeger at cs.tu-berlin.de  Fri Nov 14 21:49:44 2008
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Fri, 14 Nov 2008 22:49:44 +0100
Subject: fedora 10 avahi & firewall weirdness
In-Reply-To: <5256d0b0811141219w15975ad5va30ee2f4deee31b7@mail.gmail.com>
References: <1226691677.2910.36.camel@choeger5.umpa.netz>
	<5256d0b0811141219w15975ad5va30ee2f4deee31b7@mail.gmail.com>
Message-ID: <1226699384.2910.38.camel@choeger5.umpa.netz>

> I think Fedora 9 firewall would allow avahi discovery packets through
> by default, Fedora 10 doesn't. You'd need to add the appropriate rules
> back to allow the avahi traffic through.

That would be totally sane, and I would understand that, but why are
packets from the outside allowed and not from the inside? Looks pretty
useless in a security point of view to me.

-------------- 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/20081114/682e8d2c/attachment.sig>

From dcbw at redhat.com  Fri Nov 14 21:48:31 2008
From: dcbw at redhat.com (Dan Williams)
Date: Fri, 14 Nov 2008 16:48:31 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <46a038f90811141241w2f3f8dcbqffa470bc53427987@mail.gmail.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>
	<1226686948.13086.44.camel@aglarond.local>
	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>
	<46a038f90811141241w2f3f8dcbqffa470bc53427987@mail.gmail.com>
Message-ID: <1226699311.27057.20.camel@localhost.localdomain>

On Fri, 2008-11-14 at 15:41 -0500, Martin Langhoff wrote:
> On Fri, Nov 14, 2008 at 3:17 PM, Martin Langhoff
> <martin.langhoff at gmail.com> wrote:
> > On Fri, Nov 14, 2008 at 1:22 PM, Jeremy Katz <katzj at redhat.com> wrote:
> >> On Fri, 2008-11-14 at 13:13 -0500, Martin Langhoff wrote:
> >>> I agree with the desire to maintain only one tool. However, NM is
> >>> extremely desktop oriented, and there seems to include no hint of an
> >>> intention to support the complex setups that are possible with the old
> >>> ifcfg infra.
> >>
> >> Really?  Most of the work over the past couple of years in NM seems to
> >> be aimed at trying to support these cases as opposed to just the
> >> "simple" desktop case
> >
> > That's odd -- I've never seen any of it. Are there good examples of
> > how you configure a server to do special stuff with it? Or a
> > 'scripting network-manager' guide somewhere?
> 
> A bit of reading of the NM website and published docs makes me think
> that Jeremy is probably overoptimistic about the applicability of NM
> to server roles, and any intentions of scriptability.
> 
> The design goals don't include scriptability or anything that would
> resonate with sysadmins:
> http://projects.gnome.org/NetworkManager/developers/design_goals.html
> 
> The page for administrators doesn't provide anything useful
> http://projects.gnome.org/NetworkManager/admins/
> 
> And looking for an API leads me to this page (which is probably
> outdated) - a very limited API that won't do any of the things I need
> in the School Server.
> http://people.redhat.com/dcbw/NetworkManager/NetworkManager%20DBUS%20API.txt
> 
> In summary I don't think NM is designed for this. OTOH, it does the
> desktop thing well...

It goes back to documentation.  While the project as a whole is pretty
good at code, we're horrible at documentation.  We do have D-Bus
interface documentation however.  The project site desperately needs to
updated for NM 0.7.

Dan




From dcbw at redhat.com  Fri Nov 14 21:49:20 2008
From: dcbw at redhat.com (Dan Williams)
Date: Fri, 14 Nov 2008 16:49:20 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>
	<1226686948.13086.44.camel@aglarond.local>
	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>
Message-ID: <1226699360.27057.22.camel@localhost.localdomain>

On Fri, 2008-11-14 at 15:17 -0500, Martin Langhoff wrote:
> On Fri, Nov 14, 2008 at 1:22 PM, Jeremy Katz <katzj at redhat.com> wrote:
> > On Fri, 2008-11-14 at 13:13 -0500, Martin Langhoff wrote:
> >> I agree with the desire to maintain only one tool. However, NM is
> >> extremely desktop oriented, and there seems to include no hint of an
> >> intention to support the complex setups that are possible with the old
> >> ifcfg infra.
> >
> > Really?  Most of the work over the past couple of years in NM seems to
> > be aimed at trying to support these cases as opposed to just the
> > "simple" desktop case
> 
> That's odd -- I've never seen any of it. Are there good examples of
> how you configure a server to do special stuff with it? Or a
> 'scripting network-manager' guide somewhere?

Static IP, multiple interfaces, custom routes, custom DNS servers,
custom DNS search domains, etc.

Dan




From dcbw at redhat.com  Fri Nov 14 21:51:14 2008
From: dcbw at redhat.com (Dan Williams)
Date: Fri, 14 Nov 2008 16:51:14 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811141242170.26126@localhost.localdomain>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<alpine.LFD.2.00.0811141242170.26126@localhost.localdomain>
Message-ID: <1226699474.27057.25.camel@localhost.localdomain>

On Fri, 2008-11-14 at 12:52 -0500, Seth Vidal wrote:
> 
> On Fri, 14 Nov 2008, Jeremy Katz wrote:
> 
> > On Fri, 2008-11-14 at 01:24 -0500, Seth Vidal wrote:
> >> On Thu, 13 Nov 2008, Bill Nottingham wrote:
> >>> How is NM-dispatcher a developer service? Similarly, nm-tool is
> >>> at least quicker than 'ip addr ls ; ip route ls ; cat /etc/resolv.conf'.
> >>
> >> and ifconfig -a works on multiple platforms, so it's the one that will
> >> win.
> >
> > ifconfig -a doesn't show all the information if you're doing multiple
> > addresses on an adapter.
> 
> it doesn't show binding but it will show virtual interfaces, eth0:1, etc.

Use /sbin/ip already :)  AFAIK virtual interfaces are completely
obsoleted by mutiple addresses per interface, which /sbin/ip (via
netlink) makes entirely available.

Is there some reason the ethX:X configuration is desirable over just
adding multiple addresses to the interface?

dan


> but that's a side issue...
> 
> 
> > Let me change the wording of your argument a little...
> >
> > "Look, for the desktop in particular Linux makes a lot of sense, I am
> > not arguing otherwise.
> >
> > For the server it is a solution looking for a problem.  Solaris works
> > just fine thank you very much."
> >
> > It's *exactly* the arguments I heard with switching out Solaris stuff
> > when I was at NCSU.
> 
> Interesting, when I was in the same situation at duke the arguments I 
> heard was that linux wasn't tested enough and open source software wasn't 
> supported. It had nothing to do with it being too featureful. The 
> featureset b/t solaris servers and linux servers in 1999 were almost 
> identical. Most of the tools were actually the SAME CODE.
> 
> 
> >
> > One of the things about progress and getting to a more mature *platform*
> > that is suitable across a wide range of uses is change.  I'm not saying
> > that NetworkManager is perfect yet for the server needs.  But having
> > people that want to run a server say "pound sand, go the hell away, we
> > don't want to run your new-fangled stuff" doesn't help us get to where
> > it is.  Maintaining two systems in parallel is very much a long-run
> > losing position.
> 
> I think you're confused as to what I'm saying. You're hoisting up this 
> straw man that's neo-luddite and that's not me.
> 
> I think I'm tired of both of these perspectives:
>   'ALL NEW IS GOOD'
>   'ALL NEW IS BAD'
> 
> I'd like a bit more of:
>   "not all this new shit works and some of it should not have been started"
>   "sometimes you do have to throw one away"
> 
> And finally a bit more patience that changing systems which have been in 
> place for over a decade is going to cause some angst. That angst can be 
> minimized if the response to it is not so vehement and impatient. We have 
> a lot of vocal people who seem to think any resistance to change means you 
> want nothing to change. And we have a lot of vocal people who seem to 
> think that rethinking how we're doing thing is akin to heresy.
> 
> It's just not that simple.
> 
> -sv
> 



From jkeating at redhat.com  Fri Nov 14 21:54:56 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 14 Nov 2008 13:54:56 -0800
Subject: Broken dependencies in Fedora 9 - 2008-11-14
In-Reply-To: <491DF130.7040403@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>
Message-ID: <1226699696.11393.65.camel@luminos.localdomain>

On Fri, 2008-11-14 at 16:44 -0500, David Huff wrote:
> either way, it was my understanding that both ExclusinveArch and 
> ExcludeArch would work, ie the compose tools will check the srpm and not 
> include the package in a tree if specified in either of these feilds.

That is correct.

> Im not sure if switching form ExclusinveArch to ExcludeArch will fix the 
> issue at had.
> 
> Any comments, as I would like to run a new build to try and resolve this 
> issue.

Er, what exactly is the issue at 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/20081114/fc7c868c/attachment.sig>

From jkeating at redhat.com  Fri Nov 14 21:56:09 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 14 Nov 2008 13:56:09 -0800
Subject: perl-PDL-owner@fedoraproject.org
In-Reply-To: <491DF0DB.1050309@cora.nwra.com>
References: <491DF0DB.1050309@cora.nwra.com>
Message-ID: <1226699769.11393.66.camel@luminos.localdomain>

On Fri, 2008-11-14 at 14:42 -0700, Orion Poplawski wrote:
> 
> I've started work on packaging perl-PDL 2.4.4.  Got a src.rpm that 
> compiles, but some tests are segfaulting.  Just a heads up....

Erm, did the address in Subject need to go to the to or cc field?

-- 
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/20081114/4e2fa0cc/attachment.sig>

From skvidal at fedoraproject.org  Fri Nov 14 21:55:14 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 14 Nov 2008 16:55:14 -0500 (EST)
Subject: starting Fedora Server SIG
In-Reply-To: <1226699474.27057.25.camel@localhost.localdomain>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<alpine.LFD.2.00.0811141242170.26126@localhost.localdomain>
	<1226699474.27057.25.camel@localhost.localdomain>
Message-ID: <alpine.LFD.2.00.0811141654180.825@localhost.localdomain>



On Fri, 14 Nov 2008, Dan Williams wrote:

>
> Use /sbin/ip already :)  AFAIK virtual interfaces are completely
> obsoleted by mutiple addresses per interface, which /sbin/ip (via
> netlink) makes entirely available.
>
> Is there some reason the ethX:X configuration is desirable over just
> adding multiple addresses to the interface?
>

Sure - b/c I could just drop an ifcfg-eth0:0 file in 
/etc/sysconfig/network-scripts and it just worked. :)

I didn't say it was the only way to do it just that it worked well and 
afaict still works well.

-sv



From orion at cora.nwra.com  Fri Nov 14 21:57:32 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 14 Nov 2008 14:57:32 -0700
Subject: perl-PDL-owner@fedoraproject.org
In-Reply-To: <1226699769.11393.66.camel@luminos.localdomain>
References: <491DF0DB.1050309@cora.nwra.com>
	<1226699769.11393.66.camel@luminos.localdomain>
Message-ID: <491DF44C.2010302@cora.nwra.com>

Jesse Keating wrote:
> On Fri, 2008-11-14 at 14:42 -0700, Orion Poplawski wrote:
>> I've started work on packaging perl-PDL 2.4.4.  Got a src.rpm that 
>> compiles, but some tests are segfaulting.  Just a heads up....
> 
> Erm, did the address in Subject need to go to the to or cc field?

Yeah, my bad...


-- 
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 katzj at redhat.com  Fri Nov 14 22:01:56 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 14 Nov 2008 17:01:56 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>
	<1226686948.13086.44.camel@aglarond.local>
	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>
Message-ID: <1226700116.13086.116.camel@aglarond.local>

On Fri, 2008-11-14 at 15:17 -0500, Martin Langhoff wrote:
> On Fri, Nov 14, 2008 at 1:22 PM, Jeremy Katz <katzj at redhat.com> wrote:
> > On Fri, 2008-11-14 at 13:13 -0500, Martin Langhoff wrote:
> >> I agree with the desire to maintain only one tool. However, NM is
> >> extremely desktop oriented, and there seems to include no hint of an
> >> intention to support the complex setups that are possible with the old
> >> ifcfg infra.
> >
> > Really?  Most of the work over the past couple of years in NM seems to
> > be aimed at trying to support these cases as opposed to just the
> > "simple" desktop case
> 
> That's odd -- I've never seen any of it. Are there good examples of
> how you configure a server to do special stuff with it? Or a
> 'scripting network-manager' guide somewhere?

Much of the work going from NM 0.6 -> 0.7 has been around things like
multiple interfaces up at once, static configs and system settings.  All
of which are things which matter far more for your typical server than a
desktop.

> > And rather than focusing on nm-tool and exactly what it exposes, it's
> > probably more interesting to look at the dbus interfaces/daemon
> > capabilities.  Yes, I'll be one of the first to say it's painful to
> > write code interacting with dbus :-) -- but, it is very flexible and
> 
> And
>  - it's very far removed from the stuff that a unix sysadmin deals with
>  - it forces me to have a script running to listen to dbus events :-/

Lots of things in a modern system are far removed from the stuff a unix
sysadmin has traditionally dealt with.  That doesn't make it necessarily
"bad".  And as Seth pointed out, this "all new is bad" or "all new is
good" dichotomy is a part of the problem

Jeremy



From katzj at redhat.com  Fri Nov 14 22:02:08 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 14 Nov 2008 17:02:08 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <46a038f90811141241w2f3f8dcbqffa470bc53427987@mail.gmail.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>
	<1226686948.13086.44.camel@aglarond.local>
	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>
	<46a038f90811141241w2f3f8dcbqffa470bc53427987@mail.gmail.com>
Message-ID: <1226700128.13086.117.camel@aglarond.local>

On Fri, 2008-11-14 at 15:41 -0500, Martin Langhoff wrote:
> On Fri, Nov 14, 2008 at 3:17 PM, Martin Langhoff
> <martin.langhoff at gmail.com> wrote:
> > On Fri, Nov 14, 2008 at 1:22 PM, Jeremy Katz <katzj at redhat.com> wrote:
> >> On Fri, 2008-11-14 at 13:13 -0500, Martin Langhoff wrote:
> >>> I agree with the desire to maintain only one tool. However, NM is
> >>> extremely desktop oriented, and there seems to include no hint of an
> >>> intention to support the complex setups that are possible with the old
> >>> ifcfg infra.
> >>
> >> Really?  Most of the work over the past couple of years in NM seems to
> >> be aimed at trying to support these cases as opposed to just the
> >> "simple" desktop case
> >
> > That's odd -- I've never seen any of it. Are there good examples of
> > how you configure a server to do special stuff with it? Or a
> > 'scripting network-manager' guide somewhere?
> 
> A bit of reading of the NM website and published docs makes me think
> that Jeremy is probably overoptimistic about the applicability of NM
> to server roles, and any intentions of scriptability.

I was going to say "didn't this thread already cover that there's a need
for some people to help with documentation", but I think that was
actually on the other NM thread :)  

So I'll instead just say "be cautious on believing too much of what's
documented; it's often a good way to mislead yourself about the state of
a project" :-)

Jeremy



From katzj at redhat.com  Fri Nov 14 22:02:18 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 14 Nov 2008 17:02:18 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <20081114200842.GD1142545@hiwaay.net>
References: <1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<20081114200842.GD1142545@hiwaay.net>
Message-ID: <1226700138.13086.119.camel@aglarond.local>

On Fri, 2008-11-14 at 14:08 -0600, Chris Adams wrote:
> Once upon a time, Jeremy Katz <katzj at redhat.com> said:
> > One of the things about progress and getting to a more mature *platform*
> > that is suitable across a wide range of uses is change.  I'm not saying
> > that NetworkManager is perfect yet for the server needs.  But having
> > people that want to run a server say "pound sand, go the hell away, we
> > don't want to run your new-fangled stuff" doesn't help us get to where
> > it is.
> 
> Having developers say "pound sand, go the hell away, we don't want you
> to be able to do things the way you've been doing them for 10+ years"
> doesn't help either.

I'm saying (... and have been saying for years) "let's find the gaps in
_functionality_ and get them fixed so we can have one way in the
future".  I also say that just because it's the way it's always been
done doesn't mean it's the way it should be done.

> A stack of daemons cannot be as reliable as ifconfig/route.  Having a
> stack of daemons running for something that will not change is useless.

... a modular kernel cannot be as reliable as a monolithic one.  Having
modules loaded at boot-time for something that will not change is
useless.

A dynamically generate /dev cannot be as reliable as a static one.
Having /dev generated at boot-time for something that will not change is
useless.

A dynamically configured authentication stack cannot be as reliable as
one compiled into my program.  Using PAM for auth configs that will not
change is useless.

</snark>

Seriously, there is ZERO reason that it "cannot be as reliable".  Is it
newer and maybe has some bugs?  Sure.  But that doesn't fundamentally
say anything about the reliability.

> I do care about the desktop, and I use NM on my notebook (not on my
> workstations that have a single interface with a single static IP).  I
> have to shut it down on my notebook sometimes because it doesn't handle
> some of my normal usage (multiple wired NICs, wired and wireless to
> different networks, etc.).
> 
> I just don't see it as being useful or desired on my servers.  Any
> daemon that isn't useful should be disabled (that is sysadmin 101).

And *this* is the crux of it -- the definition of "useful".  Given that
we have a general, multi-purpose system for things that include both
desktops *and* servers, there is a lot of value in having one method of
doing things.  And ultimately, the cost of a daemon (to me) isn't
something that I perceive as high enough to be worth the cost of
maintaining two entirely separate systems in parallel.  Especially when
you take into account the (continuously growing) stack of feature
requests for it.

Also, there's this weird "running daemons are bad" mentality which I'm
not really sure what the right way to approach is.  But it's one that
I'm not sure how true it is in our current world of increasingly moving
functionality out of the kernel and into userspace in which case you
have to have something running in addition to the kernel.  

Maybe to try some examples -- irqbalance is a daemon and not in the
kernel anymore[1], does that make it "not useful"?  Or for another side,
various kernel threads are really just daemons... maybe we shouldn't run
them either?  

Would it make the sysadmin in you feel better if 
  a) the "daemon" were in the kernel as a kernel thread
  b) the daemon were auto-started in rc.sysinit (or equivalent) and thus
wasn't seen as a "enable-able/disable-able service" and more "system
functionality"?

Jeremy



From mschwendt at gmail.com  Fri Nov 14 22:08:19 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 14 Nov 2008 23:08:19 +0100
Subject: Broken dependencies in Fedora 9 - 2008-11-14
In-Reply-To: <491DF130.7040403@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>
Message-ID: <20081114230819.c3dfbaaf.mschwendt@gmail.com>

On Fri, 14 Nov 2008 16:44:16 -0500, David Huff wrote:

> either way, it was my understanding that both ExclusinveArch and 
> ExcludeArch would work, ie the compose tools will check the srpm and not 
> include the package in a tree if specified in either of these feilds.

That's somewhat unrelated. Checking the src.rpm is only necessary for
noarch builds. For binary builds, the buildsys (= koji) evaluates these
two fields already and requests the right arch-specific build-jobs. Then,
with no ppc64 build done, the compose tools have nothing they can push to
the ppc64 repo.
 
> Im not sure if switching form ExclusinveArch to ExcludeArch will fix the 
> issue at had.

Rule of thumb: prefer ExcludeArch (selectively excluding archs that are
known to be broken/unsupported -- with the Fedora guideline to add a
bugzilla ticket for each arch that's excluded). Second choice is
ExclusiveArch for software where you can start with a list of what archs
the software is made for, e.g. due to explicitly non-portable features.



From skvidal at fedoraproject.org  Fri Nov 14 22:10:29 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 14 Nov 2008 17:10:29 -0500 (EST)
Subject: starting Fedora Server SIG
In-Reply-To: <1226700138.13086.119.camel@aglarond.local>
References: <1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<20081114200842.GD1142545@hiwaay.net>
	<1226700138.13086.119.camel@aglarond.local>
Message-ID: <alpine.LFD.2.00.0811141708470.825@localhost.localdomain>



On Fri, 14 Nov 2008, Jeremy Katz wrote:

>
> Also, there's this weird "running daemons are bad" mentality which I'm
> not really sure what the right way to approach is.  But it's one that
> I'm not sure how true it is in our current world of increasingly moving
> functionality out of the kernel and into userspace in which case you
> have to have something running in addition to the kernel.
>
> Maybe to try some examples -- irqbalance is a daemon and not in the
> kernel anymore[1], does that make it "not useful"?  Or for another side,
> various kernel threads are really just daemons... maybe we shouldn't run
> them either?
>

if you replace useful with necessary in his argument I think it ends up 
making more sense.

If the daemon is not NECESSARY for the task it is fulfilling then why have 
it running?

And I think you do understand quite well the rule that any thing that is 
not necessary to the functioning of a server should be off.

-sv



From dcbw at redhat.com  Fri Nov 14 22:16:56 2008
From: dcbw at redhat.com (Dan Williams)
Date: Fri, 14 Nov 2008 17:16:56 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811141708470.825@localhost.localdomain>
References: <1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<20081114200842.GD1142545@hiwaay.net>
	<1226700138.13086.119.camel@aglarond.local>
	<alpine.LFD.2.00.0811141708470.825@localhost.localdomain>
Message-ID: <1226701016.27057.44.camel@localhost.localdomain>

On Fri, 2008-11-14 at 17:10 -0500, Seth Vidal wrote:
> 
> On Fri, 14 Nov 2008, Jeremy Katz wrote:
> 
> >
> > Also, there's this weird "running daemons are bad" mentality which I'm
> > not really sure what the right way to approach is.  But it's one that
> > I'm not sure how true it is in our current world of increasingly moving
> > functionality out of the kernel and into userspace in which case you
> > have to have something running in addition to the kernel.
> >
> > Maybe to try some examples -- irqbalance is a daemon and not in the
> > kernel anymore[1], does that make it "not useful"?  Or for another side,
> > various kernel threads are really just daemons... maybe we shouldn't run
> > them either?
> >
> 
> if you replace useful with necessary in his argument I think it ends up 
> making more sense.
> 
> If the daemon is not NECESSARY for the task it is fulfilling then why have 
> it running?

So I guess it boils down to how you define "task" then...

Dan




From skvidal at fedoraproject.org  Fri Nov 14 22:23:39 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 14 Nov 2008 17:23:39 -0500 (EST)
Subject: starting Fedora Server SIG
In-Reply-To: <1226701016.27057.44.camel@localhost.localdomain>
References: <1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<20081114200842.GD1142545@hiwaay.net>
	<1226700138.13086.119.camel@aglarond.local>
	<alpine.LFD.2.00.0811141708470.825@localhost.localdomain>
	<1226701016.27057.44.camel@localhost.localdomain>
Message-ID: <alpine.LFD.2.00.0811141720170.825@localhost.localdomain>



On Fri, 14 Nov 2008, Dan Williams wrote:

> On Fri, 2008-11-14 at 17:10 -0500, Seth Vidal wrote:
>>
>> On Fri, 14 Nov 2008, Jeremy Katz wrote:
>>
>>>
>>> Also, there's this weird "running daemons are bad" mentality which I'm
>>> not really sure what the right way to approach is.  But it's one that
>>> I'm not sure how true it is in our current world of increasingly moving
>>> functionality out of the kernel and into userspace in which case you
>>> have to have something running in addition to the kernel.
>>>
>>> Maybe to try some examples -- irqbalance is a daemon and not in the
>>> kernel anymore[1], does that make it "not useful"?  Or for another side,
>>> various kernel threads are really just daemons... maybe we shouldn't run
>>> them either?
>>>
>>
>> if you replace useful with necessary in his argument I think it ends up
>> making more sense.
>>
>> If the daemon is not NECESSARY for the task it is fulfilling then why have
>> it running?
>
> So I guess it boils down to how you define "task" then...

Actually it boils down to what the task is.

If the task is:
  - setup ip/bcast/network
  - setup default route
  - setup static route

(which is the task on a MASSIVE number of server systems)

Then everything else is unnecessary to have running.

If the task is to deal with complicated dhcp and wireless configurations, 
multiple and complicated vpn configurations and notify the 
console/desktop user about all of these things (which a lot of laptops 
fall into that category) then NM is extremely useful and I'd argue 
necessary for a convenient computing experience.

-sv



From lfarkas at lfarkas.org  Fri Nov 14 22:25:07 2008
From: lfarkas at lfarkas.org (Farkas Levente)
Date: Fri, 14 Nov 2008 23:25:07 +0100
Subject: why koji try to build on ppc when ExcludeArch ppc?
In-Reply-To: <ufaej1euuwy.fsf@epithumia.math.uh.edu>
References: <491DA2CE.70600@lfarkas.org>	<ufaiqqquvpp.fsf@epithumia.math.uh.edu>
	<ufaej1euuwy.fsf@epithumia.math.uh.edu>
Message-ID: <491DFAC3.9060002@lfarkas.org>

Jason L Tibbitts III wrote:
> Actually, the problem is pretty clear: you simply cannot do what
> you're trying to do.
> 
> If your package won't even build on PPC, it simply can't be noarch.
> The ExcludeArch: case for noarch packages is for those with runtime
> dependencies that aren't available for all architectures.  That's not
> the case you're seeing.
> 
> Your options are either to wait until the JRE bug is fixed or make
> your package arch-specific.

no it's not that easy. the question is:
what the noarch means?
- it should have to be run on any arch?
or
- it should have to be run _AND_ build on any arch?
this package is a pure java package which is noarch the the result
gstreamer-java-1.0-1.fc10.noarch.rpm can be run on any arch,
BUT as there is a bug in #468831 in     	
java-1.6.0-openjdk on ppc it can't be compiled on ppc.
so if eg. there is a bug in python compiler or in the python interpreter
on ppc then the python packages no longer noarch packages?

-- 
  Levente                               "Si vis pacem para bellum!"



From katzj at redhat.com  Fri Nov 14 22:24:27 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 14 Nov 2008 17:24:27 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811141708470.825@localhost.localdomain>
References: <1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<20081114200842.GD1142545@hiwaay.net>
	<1226700138.13086.119.camel@aglarond.local>
	<alpine.LFD.2.00.0811141708470.825@localhost.localdomain>
Message-ID: <1226701467.13086.132.camel@aglarond.local>

On Fri, 2008-11-14 at 17:10 -0500, Seth Vidal wrote:
> On Fri, 14 Nov 2008, Jeremy Katz wrote:
> > Also, there's this weird "running daemons are bad" mentality which I'm
> > not really sure what the right way to approach is.  But it's one that
> > I'm not sure how true it is in our current world of increasingly moving
> > functionality out of the kernel and into userspace in which case you
> > have to have something running in addition to the kernel.
> >
> > Maybe to try some examples -- irqbalance is a daemon and not in the
> > kernel anymore[1], does that make it "not useful"?  Or for another side,
> > various kernel threads are really just daemons... maybe we shouldn't run
> > them either?
>
> if you replace useful with necessary in his argument I think it ends up 
> making more sense.

I'm really not convinced that it does, though.  Because it's really not
necessary to run anything at all.  We could stick everything hard-coded
into the kernel and be done with it.  You wouldn't have a very useful
system at the end though.  At least, not for any things other than the
explicit purpose you built your kernel for.  

> If the daemon is not NECESSARY for the task it is fulfilling then why have 
> it running?

It's NECESSARY because the task is more complex than just one need and
so the design of the system includes a running daemon.  Just like
there's a separate kernel thread for some network devices now.  The only
difference is that the "daemon" is in the kernel and you have no real
control over it.

> And I think you do understand quite well the rule that any thing that is 
> not necessary to the functioning of a server should be off.

I'm not hung up with this "daemons are bad.  turn them all off"
mentality, though.  And so I look at "thing that is not necessary to the
functioning of a server" not as system things like dbus or hal or
NetworkManager or irqbalance or ...  If the implementation is that these
are daemons, then hey, so be it.  The upside is that it means that they
*can* have functionality to deal with dynamic environments.  Which
actually are a concern at some point for most machines which don't end
up in a closet with the door dry-walled shut.

For "things that is not necessary to the functioning of a server", I
would look at things like cups on a machine that's never going to have a
need to print[1], or httpd on a machine that's not serving http.

Jeremy

[1] Well, arguably, we should start the printing bits on demand if
you're not running an actual print server.  But that's another
discussion entirely :)



From sundaram at fedoraproject.org  Fri Nov 14 22:26:25 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 15 Nov 2008 03:56:25 +0530
Subject: starting Fedora Server SIG
In-Reply-To: <491DD69B.2020101@gmail.com>
References: <20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>	<faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>	<alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>	<46a038f90811140503q298c8f62p823125626451f0a@mail.gmail.com>	<20081114165622.GC30721@nostromo.devel.redhat.com>	<491DB5B8.6070600@gmail.com>	<20081114185101.GI30721@nostromo.devel.redhat.com>
	<491DD69B.2020101@gmail.com>
Message-ID: <491DFB11.6000802@fedoraproject.org>

Les Mikesell wrote:
> Bill Nottingham wrote:
>> Les Mikesell (lesmikesell at gmail.com) said:
>>>>> It's already a bit of a black art to know what things to tweak to turn
>>>>> Fedora into a server-style configuration without breaking things. And
>>>>> it's growing -- in this thread I've learned about how to get the
>>>>> text-mode plymouth plugin. I'm sure there's lots more.
>>>> Don't worry, we made that knowledge obsolete.
>>> That's the real problem...
>>
>> The problem is that we listened to the complaint about solar being
>> installed by default, and fixed the bug before we released?
>>
> 
> The problem is making any esoteric knowledge required and then making it 
> obsolete. 

What you are talking about, does not apply to bug fixes within rawhide 
itself. Don't use this as your soapbox.

Rahul



From katzj at redhat.com  Fri Nov 14 22:28:39 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 14 Nov 2008 17:28:39 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811141720170.825@localhost.localdomain>
References: <1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<20081114200842.GD1142545@hiwaay.net>
	<1226700138.13086.119.camel@aglarond.local>
	<alpine.LFD.2.00.0811141708470.825@localhost.localdomain>
	<1226701016.27057.44.camel@localhost.localdomain>
	<alpine.LFD.2.00.0811141720170.825@localhost.localdomain>
Message-ID: <1226701719.13086.136.camel@aglarond.local>

On Fri, 2008-11-14 at 17:23 -0500, Seth Vidal wrote:
> On Fri, 14 Nov 2008, Dan Williams wrote:
> > On Fri, 2008-11-14 at 17:10 -0500, Seth Vidal wrote:
> >>
> >> On Fri, 14 Nov 2008, Jeremy Katz wrote:
> >>
> >>>
> >>> Also, there's this weird "running daemons are bad" mentality which I'm
> >>> not really sure what the right way to approach is.  But it's one that
> >>> I'm not sure how true it is in our current world of increasingly moving
> >>> functionality out of the kernel and into userspace in which case you
> >>> have to have something running in addition to the kernel.
> >>>
> >>> Maybe to try some examples -- irqbalance is a daemon and not in the
> >>> kernel anymore[1], does that make it "not useful"?  Or for another side,
> >>> various kernel threads are really just daemons... maybe we shouldn't run
> >>> them either?
> >>>
> >>
> >> if you replace useful with necessary in his argument I think it ends up
> >> making more sense.
> >>
> >> If the daemon is not NECESSARY for the task it is fulfilling then why have
> >> it running?
> >
> > So I guess it boils down to how you define "task" then...
> 
> Actually it boils down to what the task is.
> 
> If the task is:
[snip]
> Then everything else is unnecessary to have running.
> 
> If the task is to deal with complicated dhcp and wireless configurations, 
> multiple and complicated vpn configurations and notify the 
> console/desktop user about all of these things (which a lot of laptops 
> fall into that category) then NM is extremely useful and I'd argue 
> necessary for a convenient computing experience.

But there's a cost to maintaining two systems that are entirely
divergent and with little sharing/modularity.  I don't see the value of
"don't run a daemon" as outweighing the cost of "keep another system
maintained".  

Jeremy



From mmcgrath at redhat.com  Fri Nov 14 22:39:06 2008
From: mmcgrath at redhat.com (Mike McGrath)
Date: Fri, 14 Nov 2008 16:39:06 -0600 (CST)
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811141654180.825@localhost.localdomain>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<20081113134947.GF24297@angus.ind.WPI.EDU>
	<20081113140153.GA1538120@hiwaay.net>
	<1226588572.4714.4.camel@localhost.localdomain>
	<20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<alpine.LFD.2.00.0811141242170.26126@localhost.localdomain>
	<1226699474.27057.25.camel@localhost.localdomain>
	<alpine.LFD.2.00.0811141654180.825@localhost.localdomain>
Message-ID: <alpine.LFD.2.00.0811141637580.7419@laptop.mmcgrath.net>

On Fri, 14 Nov 2008, Seth Vidal wrote:
> On Fri, 14 Nov 2008, Dan Williams wrote:
>
> >
> > Use /sbin/ip already :)  AFAIK virtual interfaces are completely
> > obsoleted by mutiple addresses per interface, which /sbin/ip (via
> > netlink) makes entirely available.
> >
> > Is there some reason the ethX:X configuration is desirable over just
> > adding multiple addresses to the interface?
> >
>
> Sure - b/c I could just drop an ifcfg-eth0:0 file in
> /etc/sysconfig/network-scripts and it just worked. :)
>
> I didn't say it was the only way to do it just that it worked well and afaict
> still works well.
>

I'd like to note that when you're in a configuration managed environment
like Fedora Infrastructure is (via puppet).  This is an easy and simple
thing to do.  If anything goes wrong, you either look to the logs to find
out why the file isn't there, or you look in the file to see why its
malformed.

Config files are quite nice in managed or large environments.

	-Mike



From bnocera at redhat.com  Fri Nov 14 22:42:29 2008
From: bnocera at redhat.com (Bastien Nocera)
Date: Fri, 14 Nov 2008 23:42:29 +0100
Subject: F11: OSS and pulseaudio conflict
In-Reply-To: <491DA325.3010305@redhat.com>
References: <491DA325.3010305@redhat.com>
Message-ID: <1226702549.29933.2.camel@snoogens.fab.redhat.com>

On Fri, 2008-11-14 at 11:11 -0500, Warren Togami wrote:
> I ran into an application yesterday that seemed to make pulseaudio
> daemon fail.  After a lot of digging, someone else realized that this
> application was actually using OSS output.  OSS currently grabs /dev/dsp
> (provided by snd-pcm-oss), making it appear that pulseaudio has "failed".
> 
> OSS applications are so rare these days, I did not even consider that it
> was using OSS.  This is likely to be a rare but repetitive source of
> confusion in the future.

Just remove OSS support from the kernel. ALSA has been the default since
the 2.6.0 kernel (that's 5 years ago), and even apps that use OSS
emulation through ALSA will block any other use of the sound card
(whether PulseAudio is present or not).

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).



From mw_triad at users.sourceforge.net  Fri Nov 14 22:53:37 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Fri, 14 Nov 2008 16:53:37 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1226701719.13086.136.camel@aglarond.local>
References: <1226588572.4714.4.camel@localhost.localdomain>	<20081113160203.GD1538120@hiwaay.net>	<1226592802.3651.30.camel@eagle.danny.cz>	<1226593460.13077.91.camel@aglarond.local>	<20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>	<20081113223242.GB4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>	<1226678932.636.40.camel@aglarond.local>	<20081114200842.GD1142545@hiwaay.net>	<1226700138.13086.119.camel@aglarond.local>	<alpine.LFD.2.00.0811141708470.825@localhost.localdomain>	<1226701016.27057.44.camel@localhost.localdomain>	<alpine.LFD.2.00.0811141720170.825@localhost.localdomain>
	<1226701719.13086.136.camel@aglarond.local>
Message-ID: <gfkvhh$rhq$1@ger.gmane.org>

Jeremy Katz wrote:
> On Fri, 2008-11-14 at 17:23 -0500, Seth Vidal wrote:
>> If the task is:
> [snip]
>> Then everything else is unnecessary to have running.
>>
>> If the task is to deal with complicated dhcp and wireless configurations, 
>> multiple and complicated vpn configurations and notify the 
>> console/desktop user about all of these things (which a lot of laptops 
>> fall into that category) then NM is extremely useful and I'd argue 
>> necessary for a convenient computing experience.
> 
> But there's a cost to maintaining two systems that are entirely
> divergent and with little sharing/modularity.  I don't see the value of
> "don't run a daemon" as outweighing the cost of "keep another system
> maintained".  

So... have an 'exit after initial configuration' option for NM?
/me runs and hides now

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Person A: It's an ISO standard.
Person B: ...And that means what?
   -- mal (http://theangryadmin.blogspot.com/2008/04/future.html)



From martin.langhoff at gmail.com  Fri Nov 14 23:07:06 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Fri, 14 Nov 2008 18:07:06 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <gfkvhh$rhq$1@ger.gmane.org>
References: <1226588572.4714.4.camel@localhost.localdomain>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<20081114200842.GD1142545@hiwaay.net>
	<1226700138.13086.119.camel@aglarond.local>
	<alpine.LFD.2.00.0811141708470.825@localhost.localdomain>
	<1226701016.27057.44.camel@localhost.localdomain>
	<alpine.LFD.2.00.0811141720170.825@localhost.localdomain>
	<1226701719.13086.136.camel@aglarond.local>
	<gfkvhh$rhq$1@ger.gmane.org>
Message-ID: <46a038f90811141507u430bd3b5x89b48a748f210fb9@mail.gmail.com>

On Fri, Nov 14, 2008 at 5:53 PM, Matthew Woehlke
<mw_triad at users.sourceforge.net> wrote:
> So... have an 'exit after initial configuration' option for NM?
> /me runs and hides now

And support for bridges, bonding devices and lots of odd config rules
that you can do with the ifcfg scripts.

I want to like NM, and it's great that Dan's posted good links to
current API docs, but it's not a good match for a moderately complex
server role. In tight memory conditions -- OLPC's School Server, but
also UMPCs -- a large daemon running as root is hard to justify.

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 mw_triad at users.sourceforge.net  Fri Nov 14 23:16:12 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Fri, 14 Nov 2008 17:16:12 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <46a038f90811141507u430bd3b5x89b48a748f210fb9@mail.gmail.com>
References: <1226588572.4714.4.camel@localhost.localdomain>	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>	<1226678932.636.40.camel@aglarond.local>	<20081114200842.GD1142545@hiwaay.net>	<1226700138.13086.119.camel@aglarond.local>	<alpine.LFD.2.00.0811141708470.825@localhost.localdomain>	<1226701016.27057.44.camel@localhost.localdomain>	<alpine.LFD.2.00.0811141720170.825@localhost.localdomain>	<1226701719.13086.136.camel@aglarond.local>	<gfkvhh$rhq$1@ger.gmane.org>
	<46a038f90811141507u430bd3b5x89b48a748f210fb9@mail.gmail.com>
Message-ID: <gfl0rs$uvk$1@ger.gmane.org>

Martin Langhoff wrote:
> On Fri, Nov 14, 2008 at 5:53 PM, Matthew Woehlke
> <mw_triad at users.sourceforge.net> wrote:
>> So... have an 'exit after initial configuration' option for NM?
>> /me runs and hides now
> 
> And support for bridges, bonding devices and lots of odd config rules
> that you can do with the ifcfg scripts.
> 
> I want to like NM, and it's great that Dan's posted good links to
> current API docs, but it's not a good match for a moderately complex
> server role. In tight memory conditions -- OLPC's School Server, but
> also UMPCs -- a large daemon running as root is hard to justify.

So... have an 'exit after initial configuration' option for NM?

I didn't say it's perfect (note: I'm also one of those still using if* 
scripts). I'm just contesting that "it's a daemon" is an insurmountable 
problem.

If the other stuff you mentioned were fixed, and NM could be run in 
'setup-and-exit' mode (as opposed to daemon mode), would that make it an 
adequate replacement in server environments?

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Person A: It's an ISO standard.
Person B: ...And that means what?
   -- mal (http://theangryadmin.blogspot.com/2008/04/future.html)



From ivazqueznet at gmail.com  Fri Nov 14 23:18:10 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 14 Nov 2008 18:18:10 -0500
Subject: fedora 10 avahi & firewall weirdness
In-Reply-To: <1226699384.2910.38.camel@choeger5.umpa.netz>
References: <1226691677.2910.36.camel@choeger5.umpa.netz>
	<5256d0b0811141219w15975ad5va30ee2f4deee31b7@mail.gmail.com>
	<1226699384.2910.38.camel@choeger5.umpa.netz>
Message-ID: <1226704690.16027.235.camel@ignacio.lan>

On Fri, 2008-11-14 at 22:49 +0100, Christoph H?ger wrote:
> > I think Fedora 9 firewall would allow avahi discovery packets through
> > by default, Fedora 10 doesn't. You'd need to add the appropriate rules
> > back to allow the avahi traffic through.
> 
> That would be totally sane, and I would understand that, but why are
> packets from the outside allowed and not from the inside? Looks pretty
> useless in a security point of view to me.

mDNS uses a "push" architecture, not a "pull" architecture. Systems
broadcast service availability instead of being polled for it. So when
you query your local mDNS resolver, it checks to see if any services
have been pushed for a given host/service. A non-firewalled system will
see all pushes; a firewalled system will see none.

-- 
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/20081114/fb33d9c1/attachment.sig>

From lfarkas at lfarkas.org  Fri Nov 14 23:37:03 2008
From: lfarkas at lfarkas.org (Farkas Levente)
Date: Sat, 15 Nov 2008 00:37:03 +0100
Subject: RFC: definition of noarch [was Re: why koji try to build on ppc when
 ExcludeArch ppc?]
In-Reply-To: <491DFAC3.9060002@lfarkas.org>
References: <491DA2CE.70600@lfarkas.org>	<ufaiqqquvpp.fsf@epithumia.math.uh.edu>
	<ufaej1euuwy.fsf@epithumia.math.uh.edu>
	<491DFAC3.9060002@lfarkas.org>
Message-ID: <491E0B9F.70803@lfarkas.org>

Farkas Levente wrote:
> Jason L Tibbitts III wrote:
>> Actually, the problem is pretty clear: you simply cannot do what
>> you're trying to do.
>>
>> If your package won't even build on PPC, it simply can't be noarch.
>> The ExcludeArch: case for noarch packages is for those with runtime
>> dependencies that aren't available for all architectures.  That's not
>> the case you're seeing.
>>
>> Your options are either to wait until the JRE bug is fixed or make
>> your package arch-specific.
> 
> no it's not that easy. the question is:
> what the noarch means?
> - it should have to be run on any arch?
> or
> - it should have to be run _AND_ build on any arch?
> this package is a pure java package which is noarch the the result
> gstreamer-java-1.0-1.fc10.noarch.rpm can be run on any arch,
> BUT as there is a bug in #468831 in     	
> java-1.6.0-openjdk on ppc it can't be compiled on ppc.
> so if eg. there is a bug in python compiler or in the python interpreter
> on ppc then the python packages no longer noarch packages?

ok so according to the comment in
https://bugzilla.redhat.com/show_bug.cgi?id=471602
the bug is in my definition of noarch:-(

but as i'm not agree with you, the only thing what can i do to try to
change this rules:-)

according to your definition:
- a noarch package can't contain ExcludeArch in it's spec file (if it's
really the case it should have to be documented and put into rpmlint).
- if a package can build on i386, x86_64 then (even if it's not an arch
dependent package) should have to be i386, x86_64 packages. or otherwise
we've to wait (may be even years) to be fixed the compiler or the
runtime or ... on ppc.
- and then an i386 package can be repackage as noarch!?

what will happened if more archs from secondary architectures (arm,
ia64, s390, sparc) will be added to fedora's primary arch? then we've to
wait for all bugs in all arch independent language's compiler, runtime,
interpreter, etc. for a noarch packages?

imho: the definition of noarch should have to be:
- can be build and run on all arch except on the ExcludeArch's arch.

imho: the koji should have to work as:
all package should have to be build on it own arch and if it's noarch
then it can be build on any buildhost if it's arch not among the
ExcludeArch's arch.


-- 
  Levente                               "Si vis pacem para bellum!"



From jkeating at redhat.com  Fri Nov 14 23:57:36 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 14 Nov 2008 15:57:36 -0800
Subject: Fedora 10 and dmraid
Message-ID: <1226707056.3473.7.camel@luminos.localdomain>

One of the last sets of blocker bugs for Fedora 10 involve dmraid.  It
appears that some classes of dmraid capable systems (maybe just intel)
are not working well, or at all.  If any of you out there have dmraid
systems, please give Fedora 10 Preview or later an install attempt, or
even just boot the installer to see if anaconda correctly assembles your
dmraid arrays.  You don't have to go through with the installation, we
just want to see if you /could/.

The relevant bugs are:

468649
467904
470634
470543

and possibly more.  If you already know of existing dmraid bugs that are
not listed above, please bring them to my attention.

We have very little time left in the 10 development cycle, and I really
would not want to slip 2~ weeks (to get around holidays) just for dmraid
on some platforms.

-- 
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/20081114/184902d0/attachment.sig>

From choeger at cs.tu-berlin.de  Fri Nov 14 23:58:53 2008
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Sat, 15 Nov 2008 00:58:53 +0100
Subject: fedora 10 avahi & firewall weirdness
In-Reply-To: <1226704690.16027.235.camel@ignacio.lan>
References: <1226691677.2910.36.camel@choeger5.umpa.netz>
	<5256d0b0811141219w15975ad5va30ee2f4deee31b7@mail.gmail.com>
	<1226699384.2910.38.camel@choeger5.umpa.netz>
	<1226704690.16027.235.camel@ignacio.lan>
Message-ID: <1226707133.2910.40.camel@choeger5.umpa.netz>

> mDNS uses a "push" architecture, not a "pull" architecture. Systems
> broadcast service availability instead of being polled for it. So when
> you query your local mDNS resolver, it checks to see if any services
> have been pushed for a given host/service. A non-firewalled system will
> see all pushes; a firewalled system will see none.

Ok, that explains, why my non firewalled notebook saw all services, but
why did I not see any localhost services? A push from localhgost should
not be firewalled!
-------------- 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/20081115/4ffdeb2e/attachment.sig>

From ivazqueznet at gmail.com  Sat Nov 15 00:25:17 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 14 Nov 2008 19:25:17 -0500
Subject: fedora 10 avahi & firewall weirdness
In-Reply-To: <1226707133.2910.40.camel@choeger5.umpa.netz>
References: <1226691677.2910.36.camel@choeger5.umpa.netz>
	<5256d0b0811141219w15975ad5va30ee2f4deee31b7@mail.gmail.com>
	<1226699384.2910.38.camel@choeger5.umpa.netz>
	<1226704690.16027.235.camel@ignacio.lan>
	<1226707133.2910.40.camel@choeger5.umpa.netz>
Message-ID: <1226708717.16027.238.camel@ignacio.lan>

On Sat, 2008-11-15 at 00:58 +0100, Christoph H?ger wrote:
> > mDNS uses a "push" architecture, not a "pull" architecture. Systems
> > broadcast service availability instead of being polled for it. So when
> > you query your local mDNS resolver, it checks to see if any services
> > have been pushed for a given host/service. A non-firewalled system will
> > see all pushes; a firewalled system will see none.
> 
> Ok, that explains, why my non firewalled notebook saw all services, but
> why did I not see any localhost services? A push from localhgost should
> not be firewalled!

Ah, but you see, the push isn't to localhost, it's to the broadcast
address, which *is* firewalled.

As to why avahi doesn't just enumerate them internally... that I don't
know.

-- 
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/20081114/b7670483/attachment.sig>

From mschwendt at gmail.com  Sat Nov 15 00:44:26 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sat, 15 Nov 2008 01:44:26 +0100
Subject: why koji try to build on ppc when ExcludeArch ppc?
In-Reply-To: <491DFAC3.9060002@lfarkas.org>
References: <491DA2CE.70600@lfarkas.org>
	<ufaiqqquvpp.fsf@epithumia.math.uh.edu>
	<ufaej1euuwy.fsf@epithumia.math.uh.edu>
	<491DFAC3.9060002@lfarkas.org>
Message-ID: <20081115014426.178213df.mschwendt@gmail.com>

On Fri, 14 Nov 2008 23:25:07 +0100, Farkas Levente wrote:

> what the noarch means?
> - it should have to be run on any arch?
> or
> - it should have to be run _AND_ build on any arch?

The tag is "BuildArch", which refers to the target arch as in "build for".

"noarch" means the built package is not specific to a particular arch. It
may be used on any arch.

Imagine that any of your build requirements (including many core tools
like "install", "mkdir", "patch", "sed", "bash", "rpmbuild", "dos2unix",
"convert", "iconv") may break on any platform and temporarily make it
impossible to build your noarch pkg on that platform. Just that with
Java you cannot simply replace the build tool.

> this package is a pure java package which is noarch the the result
> gstreamer-java-1.0-1.fc10.noarch.rpm can be run on any arch,
> BUT as there is a bug in #468831 in     	
> java-1.6.0-openjdk on ppc it can't be compiled on ppc.
> so if eg. there is a bug in python compiler or in the python interpreter
> on ppc then the python packages no longer noarch packages?

Yes. Noarch packages with strict [build/run-time] dependencies on
arch-specific packages are contaminative ("poisonous"). Any
arch-specific package, which is needed to rebuild the noarch package,
must be available and must work on _any_ platform supported by the
buildsys. Even if you don't need an interpreter at build-time, you
likely need it at run-time. If you drop the run-time dependency, you
may win, and the package may become installable, but the package would
not work if the interpreter is missing/broken. Under the hood, the
noarch package becomes arch-specific -- in the worst-case, it becomes
unusable (or even uninstallable and not rebuildable).



From seg at haxxed.com  Sat Nov 15 01:46:20 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 14 Nov 2008 19:46:20 -0600
Subject: sound skipping in F10
In-Reply-To: <385866f0811141153o1c84f4f1h72565602062c55ad@mail.gmail.com>
References: <385866f0811091311q31e1a367u9de08b054a9e0989@mail.gmail.com>
	<4917652E.3020004@gmail.com> <4917A540.7050108@fedoraproject.org>
	<4917F695.2040005@gmail.com>
	<385866f0811100619u55d9bce8rcb3bae30c8ec09b4@mail.gmail.com>
	<385866f0811100621w3410f3bp1b111e4890ad7d33@mail.gmail.com>
	<62b1552c0811140956s412b937cmacd4c6bcdbde292b@mail.gmail.com>
	<385866f0811141153o1c84f4f1h72565602062c55ad@mail.gmail.com>
Message-ID: <1226713581.14512.10.camel@localhost.localdomain>

On Fri, 2008-11-14 at 21:53 +0200, Muayyad AlSadi wrote:
> are you sure!! AFAIK modeset is about video not audio

I have had all sorts of problems with audio skipping while graphics are
happening going back to F9, and still happening in F10. Playing music in
rhythmbox is flawless. Until I end up on a web page with craptons of
animated ads. Or try and watch youtube videos. Skip studder skip.

After 11 years, VGA still kills:

http://alsa.linux.or.jp/misc/vgakills.txt

This is with a Radeon 9600XT with the Fedora r300 drivers. Although I
don't seem to have problems if I bypass pulseaudio...

> after the last update to the kernel I hear lesser skips
> (you may thought it's the nomodeset thing)
> but the problem is still there
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081114/62791c84/attachment.sig>

From seg at haxxed.com  Sat Nov 15 03:37:10 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 14 Nov 2008 21:37:10 -0600
Subject: F11: OSS and pulseaudio conflict
In-Reply-To: <1226702549.29933.2.camel@snoogens.fab.redhat.com>
References: <491DA325.3010305@redhat.com>
	<1226702549.29933.2.camel@snoogens.fab.redhat.com>
Message-ID: <1226720230.14512.14.camel@localhost.localdomain>

On Fri, 2008-11-14 at 23:42 +0100, Bastien Nocera wrote:
> On Fri, 2008-11-14 at 11:11 -0500, Warren Togami wrote:
> > I ran into an application yesterday that seemed to make pulseaudio
> > daemon fail.  After a lot of digging, someone else realized that this
> > application was actually using OSS output.  OSS currently grabs /dev/dsp
> > (provided by snd-pcm-oss), making it appear that pulseaudio has "failed".
> > 
> > OSS applications are so rare these days, I did not even consider that it
> > was using OSS.  This is likely to be a rare but repetitive source of
> > confusion in the future.
> 
> Just remove OSS support from the kernel. ALSA has been the default since
> the 2.6.0 kernel (that's 5 years ago), and even apps that use OSS
> emulation through ALSA will block any other use of the sound card
> (whether PulseAudio is present or not).
> 
> 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).

The proprietary Flash plugin was the main justification for keeping OSS
the last time this came up. This is no longer the case.

Kill OSS emulation, kill it dead. A Fedora 11 feature perhaps?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081114/4a24a6e1/attachment.sig>

From choeger at cs.tu-berlin.de  Sat Nov 15 09:23:48 2008
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Sat, 15 Nov 2008 10:23:48 +0100
Subject: fedora 10 avahi & firewall weirdness
In-Reply-To: <1226708717.16027.238.camel@ignacio.lan>
References: <1226691677.2910.36.camel@choeger5.umpa.netz>
	<5256d0b0811141219w15975ad5va30ee2f4deee31b7@mail.gmail.com>
	<1226699384.2910.38.camel@choeger5.umpa.netz>
	<1226704690.16027.235.camel@ignacio.lan>
	<1226707133.2910.40.camel@choeger5.umpa.netz>
	<1226708717.16027.238.camel@ignacio.lan>
Message-ID: <1226741028.2819.2.camel@choeger5.umpa.netz>

Wait, a _broadcast_ push? Strange. Multicast would fit much better.

But ok, that means local avahi daemon is blind and dumb when it comes to
local services and waits for it's own broadcast push to fly in. Ok, that
solves the mystique.

thanks
-------------- 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/20081115/bdedcb7e/attachment.sig>

From ivazqueznet at gmail.com  Sat Nov 15 10:45:41 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Sat, 15 Nov 2008 05:45:41 -0500
Subject: fedora 10 avahi & firewall weirdness
In-Reply-To: <1226741028.2819.2.camel@choeger5.umpa.netz>
References: <1226691677.2910.36.camel@choeger5.umpa.netz>
	<5256d0b0811141219w15975ad5va30ee2f4deee31b7@mail.gmail.com>
	<1226699384.2910.38.camel@choeger5.umpa.netz>
	<1226704690.16027.235.camel@ignacio.lan>
	<1226707133.2910.40.camel@choeger5.umpa.netz>
	<1226708717.16027.238.camel@ignacio.lan>
	<1226741028.2819.2.camel@choeger5.umpa.netz>
Message-ID: <1226745941.16027.247.camel@ignacio.lan>

On Sat, 2008-11-15 at 10:23 +0100, Christoph H?ger wrote:
> Wait, a _broadcast_ push? Strange. Multicast would fit much better.

Sorry, yes, I meant multicast. That's what the "m" in mDNS stands for.

-- 
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/20081115/39ff8c40/attachment.sig>

From steve at nexusuk.org  Sat Nov 15 12:11:10 2008
From: steve at nexusuk.org (Steve Hill)
Date: Sat, 15 Nov 2008 12:11:10 +0000 (GMT)
Subject: Rawhide: pulseaudio and emu10k1 problems
Message-ID: <alpine.LRH.1.10.0811151152140.23012@persephone.nexusuk.org>


I've just installed Monday's rawhide on a machine with a SB Live 
(emu10k1) sound card and have stumbled across several sound problems:

1. Pulseaudio only sees the front 2 speakers of the emu10k1 - the 
workaround for this is to add "default-sample-channels = 4" to 
/etc/pulse/daemon.conf, but this changes the number of channels seen on 
all the other sound cards in the machine too, which may not be what you 
want.  "aplay -L" does list a 4 channel "surround40:CARD=Live,DEV=0" 
subdevice - if we can't reliably auto-select the right subdevice, how 
about at least letting the user select it from the GUI?

2. The EMU10K1 mixer routing is rather broken - the "Master" mixer channel 
only controls the front speakers, leaving the rear speakers to be 
controlled by the "Surround" channel.  Thus the "Master" channel should 
really be renamed to "Front" and a real "Master" channel that controls 
everything should be added.  It is a bit of a pain having to adjust 2 
channels at the same time in order to change the volume.  Similarly, the 
PCM channel only controls the front channels - surely this should control 
*all* the PCM channels?

3. gnome-sound-properties allows configuration of the "Default Mixer 
Tracks", but this does not affect which tracks mixer_applet2 (which is 
present in the system tray by default) controls.  mixer_applet2 has its 
own configuration - some unification is needed here.

4. gnome-sound-properties is accessed under System -> Prefs -> Hardware -> 
Sound but it allows configuration of the system sounds.  The system sounds 
have as little to do with your sound hardware as the desktop background 
has to do with your video hardware so it seems rather non-intuitive.  The 
system sounds configuration should really be separated from the devices 
configuration and moved into somewhere like Look & Feel.

  - Steve
    xmpp:steve at nexusuk.org   sip:steve at nexusuk.org   http://www.nexusuk.org/

      Servatis a periculum, servatis a maleficum - Whisper, Evanescence



From rawhide at fedoraproject.org  Sat Nov 15 12:32:30 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sat, 15 Nov 2008 12:32:30 +0000 (UTC)
Subject: rawhide report: 20081115 changes
Message-ID: <20081115123230.2D6B11F8258@releng2.fedora.phx.redhat.com>

Compose started at Sat Nov 15 06:01:14 UTC 2008

Removed package libflashsupport
Removed package mknbi
Updated Packages:

glibc-2.9-2
-----------
* Thu Nov 13 17:00:00 2008 Jakub Jelinek <jakub at redhat.com> 2.9-2
- glibc 2.9 release
- fix CPU_ALLOC_SIZE on 32-bit arches (BZ#7029)

* Wed Nov 12 17:00:00 2008 Jakub Jelinek <jakub at redhat.com> 2.8.90-17
- update from trunk
  - don't abort on broken DNS replies (#469299, BZ#7009)
  - misc fixes (BZ#6966, BZ#7008, BZ#6955, BZ#6843)


initscripts-8.86-1
------------------
* Tue Nov 11 17:00:00 2008 Bill Nottingham <notting at redhat.com> - 8.86-1
- stop plymouth before stopping the runlevel (#467207)
- fix get_config_by_subchannel (#459044, <harald at redhat.com>)
- use blkid -l to pick a single most appropriate device (#470027)
- don't mkswap on halt, as it breaks swap-by-label/UUID (#469823)


ipa-1.2.0-3.fc10
----------------
* Fri Nov 14 17:00:00 2008 Simo Sorce <ssorce at redhat.com> - 1.2.0-3
- Respin after the tarball has been re-released upstream
  New hash is 506c9c92dcaf9f227cba5030e999f177

* Thu Nov 13 17:00:00 2008 Simo Sorce <ssorce at redhat.com> - 1.2.0-2
- Conditionally restart also dirsrv and httpd when upgrading

* Wed Oct 29 18:00:00 2008 Rob Crittenden <rcritten at redhat.com> - 1.2.0-1
- Update to upstream version 1.2.0
- Set fedora-ds-base minimum version to 1.1.3 for winsync header
- Set the minimum version for SELinux policy
- Remove references to Fedora 7


valgrind-3.3.0-4
----------------
* Sun Nov 16 17:00:00 2008 Jakub Jelinek <jakub at redhat.com> 3.3.0-4
- add suppressions for glibc 2.9


Summary:
Added Packages: 0
Removed Packages: 2
Modified Packages: 4














From orcanbahri at yahoo.com  Sat Nov 15 16:11:07 2008
From: orcanbahri at yahoo.com (Orcan Ogetbil)
Date: Sat, 15 Nov 2008 08:11:07 -0800 (PST)
Subject: Rawhide: pulseaudio and emu10k1 problems
In-Reply-To: <alpine.LRH.1.10.0811151152140.23012@persephone.nexusuk.org>
Message-ID: <113803.84811.qm@web32807.mail.mud.yahoo.com>

> 2. The EMU10K1 mixer routing is rather broken - the
> "Master" mixer channel only controls the front
> speakers, leaving the rear speakers to be controlled by the
> "Surround" channel.  Thus the "Master"
> channel should really be renamed to "Front" and a
> real "Master" channel that controls everything
> should be added.  It is a bit of a pain having to adjust 2
> channels at the same time in order to change the volume. 
> Similarly, the PCM channel only controls the front channels
> - surely this should control *all* the PCM channels?
> 

I have this problem for a couple years now. I have a SB Audigy Pro 4. Mixer channel controls never controlled what they supposed to. I sent multiple emails to alsa-devel list, filed a bug in their tracking system, poked them on IRC...

Nope, they don't care to fix it.

But I didn't give up. I started learning C, so one day I can fix this myself.

-oget


      



From kvantanet at seznam.cz  Sat Nov 15 17:18:49 2008
From: kvantanet at seznam.cz (kvantanet at seznam.cz)
Date: Sat, 15 Nov 2008 18:18:49 +0100 (CET)
Subject: dmraid problems - Intel ICH9R raid not recognized by Fedora
	10	Preview
Message-ID: <750.1287-12012-1691267120-1226769529@seznam.cz>

Hi everyone,

Posting another dmraid bug in Fedora 10 preview. As requested by Jesse Keating.

https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01108.html


Server: PRIMERGY RX100 S5
Make: Fujitsu Siemens Computers
Processor: 1x Xenon Quad Core/ 2xSATAII 500GB / RAID chip Intel ICHR9
/motherboard FSC
Will be affecting also PRIMERGY Econel Servers with RAID chip Intel ICHR9


We have configured a RAID 1 array on Intel ICH9R raid. Which in fact uses LSI
firmware and appear like LSI Software SATA RAID Bios Version: A.06.05071459R

This is a fakeRAID so dmraid is used to deal with it.

A) Using Fedora 10 Preview the RAID array is not recognized at all.
In the anaconda installer just appear 2 separate SATA disks.

B) Using Fedora 9 and Fedora 10 Beta the RAID array is recognized but when
booting appears an error message which is actually not affecting the
functionality of the OS (The system boots up OK). Not sure of dmraid (RAID) functionality in case of a crash.

Error:
<SNIP>
Setting hostname localhost.localdomain [OK]
/etc/rc.d/rc.sysinit: line 350: 1336 Segmentation fault /sbin/dmraid.static -ay
-i -p
"$dmname" > /dev/null 2>&1
Setting up Logical Volume Management : 2 logical volumes........
</SNIP>

Version-Release number of selected component (if applicable):
F10 Preview x86_64 DVD
F10 Beta x86_64 DVD
F9 Release x86_64 DVD

I thing there is something seriously wrong with dmraid in F10. Anybody out there with similar experience.
We have planned to use F10 on our servers if solution would be provided.

I have posted a bug: https://bugzilla.redhat.com/show_bug.cgi?id=471737

Best Regards

Tomas Lanik
KvantaNet 



From galibert at pobox.com  Sat Nov 15 17:30:32 2008
From: galibert at pobox.com (Olivier Galibert)
Date: Sat, 15 Nov 2008 18:30:32 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <20081114165816.GD30721@nostromo.devel.redhat.com>
References: <1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<604aa7910811131551s74a418afv24a5a5401e5ba0bb@mail.gmail.com>
	<491CC066.9000808@gmail.com>
	<20081114000723.GA6635@nostromo.devel.redhat.com>
	<200811141537.mAEFbsTH004020@laptop14.inf.utfsm.cl>
	<20081114165816.GD30721@nostromo.devel.redhat.com>
Message-ID: <20081115173032.GA65599@dspnet.fr.eu.org>

On Fri, Nov 14, 2008 at 11:58:16AM -0500, Bill Nottingham wrote:
> Horst H. von Brand (vonbrand at inf.utfsm.cl) said: 
> > > I really don't know what you mean by this. For displaying devices,
> > > addresses, and routes, they will work like they always have. If you
> > > use it to change the configuration of a device out from under NetworkManager,
> > > well, then you've causes your own issue. (Much like if you change 
> > > the address out from whatever /etc/init.d/network configured it
> > > as, actually.)
> > 
> > The question is to make NM aware of such changes (or even do them through
> > NM).
> 
> I'm curious - why is 'make <blah> aware of me changing things out from under
> it and handling it across up/down/reboot' more of a prority for NM than
> for the old network scripts?

I suspect it's more of a "don't change it back under my feet, don't
destroy the config at shutdown", which are things NM was prone to do
under F8 at least.  Dunno it that changed.

  OG.



From alsadi at gmail.com  Sat Nov 15 17:44:47 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Sat, 15 Nov 2008 19:44:47 +0200
Subject: sound skipping in F10
In-Reply-To: <1226713581.14512.10.camel@localhost.localdomain>
References: <385866f0811091311q31e1a367u9de08b054a9e0989@mail.gmail.com>
	<4917652E.3020004@gmail.com> <4917A540.7050108@fedoraproject.org>
	<4917F695.2040005@gmail.com>
	<385866f0811100619u55d9bce8rcb3bae30c8ec09b4@mail.gmail.com>
	<385866f0811100621w3410f3bp1b111e4890ad7d33@mail.gmail.com>
	<62b1552c0811140956s412b937cmacd4c6bcdbde292b@mail.gmail.com>
	<385866f0811141153o1c84f4f1h72565602062c55ad@mail.gmail.com>
	<1226713581.14512.10.camel@localhost.localdomain>
Message-ID: <385866f0811150944r743e6230y8fb30b32e0ef8198@mail.gmail.com>

> I have had all sorts of problems with audio skipping while graphics are
> happening going back to F9, and still happening in F10
no, then that's a different issue
as I did not have any audio skipping problems in F9



From fedora at shmuelhome.mine.nu  Sat Nov 15 18:13:12 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Sat, 15 Nov 2008 20:13:12 +0200
Subject: starting Fedora Server SIG
In-Reply-To: <20081114185101.GI30721@nostromo.devel.redhat.com>
References: <20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>	<faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>	<alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>	<46a038f90811140503q298c8f62p823125626451f0a@mail.gmail.com>	<20081114165622.GC30721@nostromo.devel.redhat.com>	<491DB5B8.6070600@gmail.com>
	<20081114185101.GI30721@nostromo.devel.redhat.com>
Message-ID: <491F1138.6090103@shmuelhome.mine.nu>

Bill Nottingham wrote:
> The problem is that we listened to the complaint about solar being
> installed by default, and fixed the bug before we released?
>
>   
In this thread, the shock was just too much to bear.



From skvidal at fedoraproject.org  Sat Nov 15 18:35:55 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Sat, 15 Nov 2008 13:35:55 -0500 (EST)
Subject: starting Fedora Server SIG
In-Reply-To: <491F1138.6090103@shmuelhome.mine.nu>
References: <20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>
	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>
	<faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>
	<alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>
	<46a038f90811140503q298c8f62p823125626451f0a@mail.gmail.com>
	<20081114165622.GC30721@nostromo.devel.redhat.com>
	<491DB5B8.6070600@gmail.com>
	<20081114185101.GI30721@nostromo.devel.redhat.com>
	<491F1138.6090103@shmuelhome.mine.nu>
Message-ID: <alpine.LFD.2.00.0811151335270.2885@localhost.localdomain>



On Sat, 15 Nov 2008, shmuel siegel wrote:

> Bill Nottingham wrote:
>> The problem is that we listened to the complaint about solar being
>> installed by default, and fixed the bug before we released?
>>
>> 
> In this thread, the shock was just too much to bear.
>

Don't be hateful, that's not cool.

-sv



From fedora at shmuelhome.mine.nu  Sat Nov 15 18:56:47 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Sat, 15 Nov 2008 20:56:47 +0200
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811151335270.2885@localhost.localdomain>
References: <20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>	<faa16b610811131433t3db24c84kd47f77333d61e5fe@mail.gmail.com>	<alpine.LFD.2.00.0811140127580.19678@localhost.localdomain>	<faa16b610811132321m5480e53k53943426e636e6ab@mail.gmail.com>	<alpine.LFD.2.00.0811140230350.26126@localhost.localdomain>	<46a038f90811140503q298c8f62p823125626451f0a@mail.gmail.com>	<20081114165622.GC30721@nostromo.devel.redhat.com>	<491DB5B8.6070600@gmail.com>	<20081114185101.GI30721@nostromo.devel.redhat.com>	<491F1138.6090103@shmuelhome.mine.nu>
	<alpine.LFD.2.00.0811151335270.2885@localhost.localdomain>
Message-ID: <491F1B6F.4090801@shmuelhome.mine.nu>

Seth Vidal wrote:
>
>
> On Sat, 15 Nov 2008, shmuel siegel wrote:
>
>> Bill Nottingham wrote:
>>> The problem is that we listened to the complaint about solar being
>>> installed by default, and fixed the bug before we released?
>>>
>>>
>> In this thread, the shock was just too much to bear.
>>
>
> Don't be hateful, that's not cool.
>
> -sv
>
Sorry if it came across as that. I was trying to be funny. I guess I 
should have added a smiley.
Interestingly enough, every time I get frustrated about comments being 
ignored on this list, along comes a message like Bill's announcement 
that they took criticism seriously and fixed the issue. I need things 
like that to encourage me to follow some of these long threads dealing 
with fundamental issues.



From jamatos at fc.up.pt  Sat Nov 15 19:31:23 2008
From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=)
Date: Sat, 15 Nov 2008 19:31:23 +0000
Subject: starting Fedora Server SIG
In-Reply-To: <alpine.LFD.2.00.0811151335270.2885@localhost.localdomain>
References: <20081113210903.GG1538120@hiwaay.net>
	<491F1138.6090103@shmuelhome.mine.nu>
	<alpine.LFD.2.00.0811151335270.2885@localhost.localdomain>
Message-ID: <200811151931.23697.jamatos@fc.up.pt>

On Saturday 15 November 2008 18:35:55 Seth Vidal wrote:
> > In this thread, the shock was just too much to bear.
>
> Don't be hateful, that's not cool.

If you would have ever been near a solar flare you would understand the irony. 
;-)

And even the coolness BTW. The places where the magnetic field returns are 
cooler than the surrounding. :-)

> -sv

-- 
Jos? Ab?lio



From cmadams at hiwaay.net  Sat Nov 15 21:32:08 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Sat, 15 Nov 2008 15:32:08 -0600
Subject: Rawhide boot failure (2008-11-15)
Message-ID: <20081115213208.GA883445@hiwaay.net>

Is it just me, or does today's i386 rawhide not boot?  I tried booting
from boot.iso in a KVM and PXE booting, and in both cases I get:

Failed to execute /init
Kernel panic - not syncing: No init found.  Try passing init= option to kernel.

The x86_64 image appears to work (anaconda starts up anyway).
-- 
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 cdahlin at redhat.com  Sat Nov 15 22:04:56 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Sat, 15 Nov 2008 17:04:56 -0500
Subject: Notifications not showing up
Message-ID: <491F4788.6000509@redhat.com>

I recently noticed some problems getting libnotify notifications to show 
up. I've isolated the problem:

If you have a full-screen gnome terminal on /any/ workspace, be it the 
current one, or one not presently in view, notifications are not displayed.

Bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=469755

This is a really annoying behaviour for me. I can understand not showing 
notifications _over_ a full-screened app, but I have a full-screened 
terminal open 24/7, and I like using scripts with notify-send to tell me 
when something happens in that terminal while I'm on another workspace 
checking my email or whatnot.

Has anyone else been hit by this?

--CJD



From jreiser at BitWagon.com  Sat Nov 15 23:17:34 2008
From: jreiser at BitWagon.com (John Reiser)
Date: Sat, 15 Nov 2008 15:17:34 -0800
Subject: Rawhide boot failure (2008-11-15)
In-Reply-To: <20081115213208.GA883445@hiwaay.net>
References: <20081115213208.GA883445@hiwaay.net>
Message-ID: <491F588E.5080700@BitWagon.com>

Chris Adams wrote:
> Is it just me, or does today's i386 rawhide not boot? 

The DVD that I made using pungi boots and displays the graphical splash screen.
   ananconda-11.4.1.58
   initscripts-8.86-1.i386
   kernel-2.6.27.5-109.fc10.i586 (Thu Nov 13).

-- 



From cmadams at hiwaay.net  Sun Nov 16 00:17:30 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Sat, 15 Nov 2008 18:17:30 -0600
Subject: Rawhide boot failure (2008-11-15)
In-Reply-To: <491F588E.5080700@BitWagon.com>
References: <20081115213208.GA883445@hiwaay.net>
	<491F588E.5080700@BitWagon.com>
Message-ID: <20081116001730.GB883445@hiwaay.net>

Once upon a time, John Reiser <jreiser at BitWagon.com> said:
> Chris Adams wrote:
> >Is it just me, or does today's i386 rawhide not boot? 
> 
> The DVD that I made using pungi boots and displays the graphical splash 
> screen.
>   ananconda-11.4.1.58
>   initscripts-8.86-1.i386
>   kernel-2.6.27.5-109.fc10.i586 (Thu Nov 13).

Have you tried booting the provided boot.iso or vmlinuz/initrd.img?
Also, which glibc did you use?  It was updated last night.

Anyway, it looks like the problem is that the initrd.img has
/lib/ld-linux.so.2 as a symlink to itself, rather than ld-2.9.so, so
/sbin/init fails to load (no dynamic loader).  I'm not sure how that
happened; the glibc RPM has it right.

-- 
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 bruno at postle.net  Sun Nov 16 00:53:50 2008
From: bruno at postle.net (Bruno Postle)
Date: Sun, 16 Nov 2008 00:53:50 +0000
Subject: Looking for hugin/libpano13 co-maintainers
Message-ID: <20081116005349.GH4428@postle.net>

Now I wish I'd paid more attention to co-maintainer and 
provenpackager discussions...

Due to hardware failures I'm without a fedora system at the moment, 
so of course I get a report of a problem with one of my packages.  

Apparently something has changed in fedora breaking hugin (a 
panorama stitcher), at least on fc9 x86_64.  Simply rebuilding 
the libpano13 dependency fixes the problem.

Since I can't track this down, I just need to bump the libpano13 
release and resubmit.  So I'm asking for one or other of these:

- a 'provenpackager' to bump and rebuild libpano13 fc9
- a co-maintainer so this doesn't happen again
- help finding the cause, I have a simple test case and libpano13 
itself doesn't depend on very much in fedora

-- 
Bruno



From wolfy at nobugconsulting.ro  Sun Nov 16 02:33:20 2008
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Sun, 16 Nov 2008 04:33:20 +0200
Subject: Looking for hugin/libpano13 co-maintainers
In-Reply-To: <20081116005349.GH4428@postle.net>
References: <20081116005349.GH4428@postle.net>
Message-ID: <491F8670.60605@nobugconsulting.ro>

On 11/16/2008 02:53 AM, Bruno Postle wrote:
> Now I wish I'd paid more attention to co-maintainer and provenpackager 
> discussions...
>
> Due to hardware failures I'm without a fedora system at the moment, so 
> of course I get a report of a problem with one of my packages. 
> Apparently something has changed in fedora breaking hugin (a panorama 
> stitcher), at least on fc9 x86_64.  Simply rebuilding the libpano13 
> dependency fixes the problem.
>
> Since I can't track this down, I just need to bump the libpano13 
> release and resubmit.  So I'm asking for one or other of these:
>
> - a 'provenpackager' to bump and rebuild libpano13 fc9
I am doing it right now.

> - a co-maintainer so this doesn't happen again
> - help finding the cause, I have a simple test case and libpano13 
> itself doesn't depend on very much in fedora
>


-- 
     Manuel Wolfshant       linux registered user #131416
        IT manager    NoBug Consulting SRL
  A: Yes.
  >Q: Are you sure?
  >>A: Because it reverses the logical flow of conversation.
  >>>Q: Why is top posting frowned upon? 



From wolfy at nobugconsulting.ro  Sun Nov 16 02:41:19 2008
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Sun, 16 Nov 2008 04:41:19 +0200
Subject: Looking for hugin/libpano13 co-maintainers
In-Reply-To: <491F8670.60605@nobugconsulting.ro>
References: <20081116005349.GH4428@postle.net>
	<491F8670.60605@nobugconsulting.ro>
Message-ID: <491F884F.7060705@nobugconsulting.ro>

On 11/16/2008 04:33 AM, Manuel Wolfshant wrote:
> On 11/16/2008 02:53 AM, Bruno Postle wrote:
>> Now I wish I'd paid more attention to co-maintainer and 
>> provenpackager discussions...
>>
>> Due to hardware failures I'm without a fedora system at the moment, 
>> so of course I get a report of a problem with one of my packages. 
>> Apparently something has changed in fedora breaking hugin (a panorama 
>> stitcher), at least on fc9 x86_64.  Simply rebuilding the libpano13 
>> dependency fixes the problem.
>>
>> Since I can't track this down, I just need to bump the libpano13 
>> release and resubmit.  So I'm asking for one or other of these:
>>
>> - a 'provenpackager' to bump and rebuild libpano13 fc9
> I am doing it right now.
>
Done. http://koji.fedoraproject.org/koji/taskinfo?taskID=934803
Feel free to push it via bodhi if you are satisfied.

>> - a co-maintainer so this doesn't happen again
>> - help finding the cause, I have a simple test case and libpano13 
>> itself doesn't depend on very much in fedora
>>
>
>


-- 
     Manuel Wolfshant       linux registered user #131416
        IT manager    NoBug Consulting SRL
  A: Yes.
  >Q: Are you sure?
  >>A: Because it reverses the logical flow of conversation.
  >>>Q: Why is top posting frowned upon? 



From lesmikesell at gmail.com  Sun Nov 16 05:57:36 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 15 Nov 2008 23:57:36 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1226700138.13086.119.camel@aglarond.local>
References: <1226588572.4714.4.camel@localhost.localdomain>	<20081113160203.GD1538120@hiwaay.net>	<1226592802.3651.30.camel@eagle.danny.cz>	<1226593460.13077.91.camel@aglarond.local>	<20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>	<20081113223242.GB4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>	<1226678932.636.40.camel@aglarond.local>	<20081114200842.GD1142545@hiwaay.net>
	<1226700138.13086.119.camel@aglarond.local>
Message-ID: <491FB650.90803@gmail.com>

Jeremy Katz wrote:
> Seriously, there is ZERO reason that it "cannot be as reliable".  Is it
> newer and maybe has some bugs?  Sure.  But that doesn't fundamentally
> say anything about the reliability.
>
>   
Exactly - you _can't_ say anything about the reliability of a new 
design.   I've had 2.4 kernels with uptimes of over 4 years.  What are 
the odds that you are really going to match that - or how many attempts 
will it take?   New isn't necessarily bad, but untested is very likely 
not as good as tested and proven.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From lesmikesell at gmail.com  Sun Nov 16 06:13:34 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 16 Nov 2008 00:13:34 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1226700116.13086.116.camel@aglarond.local>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>	<1226593460.13077.91.camel@aglarond.local>	<20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>	<20081113223242.GB4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>	<1226678932.636.40.camel@aglarond.local>	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>	<1226686948.13086.44.camel@aglarond.local>	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>
	<1226700116.13086.116.camel@aglarond.local>
Message-ID: <491FBA0E.2070003@gmail.com>

Jeremy Katz wrote:
> Much of the work going from NM 0.6 -> 0.7 has been around things like
> multiple interfaces up at once, static configs and system settings.  All
> of which are things which matter far more for your typical server than a
> desktop.
>
>   
What typical server tasks aren't possible without NM?  Will it do vlan 
trunk management making it possible to individually restrict users, 
applications, or virtual machines to specific vlans?  Will it do dynamic 
multicast routing?   If it offers new features instead of just  a 
different way of configuring that things already possible the change 
might make sense.

> Lots of things in a modern system are far removed from the stuff a unix
> sysadmin has traditionally dealt with.  That doesn't make it necessarily
> "bad".  And as Seth pointed out, this "all new is bad" or "all new is
> good" dichotomy is a part of the problem
>
>   
But if a system claiming to be new/better can't provide more or less 
exact emulation of the system it wants to replace, it probably really 
isn't better.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From dave at rimini.com  Sun Nov 16 09:17:00 2008
From: dave at rimini.com (Davide Moretti)
Date: Sun, 16 Nov 2008 10:17:00 +0100
Subject: tzdata in FC10 is older than the one in FC9
Message-ID: <20081116101700.123f2y19t3bio8oc@mail.rimini.com>

In fc9 we have tzdata-2008i while in fc10 there is tzdata-2008h...

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



From chitlesh.goorah at gmail.com  Sun Nov 16 11:18:27 2008
From: chitlesh.goorah at gmail.com (Chitlesh GOORAH)
Date: Sun, 16 Nov 2008 12:18:27 +0100
Subject: F-10 repo ? for livecd-creator
Message-ID: <50baabb30811160318h31784cf1m4c7a41ddbe132ed7@mail.gmail.com>

Hello there,

Is there any repo specific to packages which are tagged with F-10-final ?

I wish to create livedvd with those packages (the ones tagged with F10-final)

Kind regards,
Chitlesh



From m.a.young at durham.ac.uk  Sun Nov 16 13:00:34 2008
From: m.a.young at durham.ac.uk (M A Young)
Date: Sun, 16 Nov 2008 13:00:34 +0000 (GMT)
Subject: dmraid problems - Intel ICH9R raid not recognized by Fedora 10
 Preview
In-Reply-To: <750.1287-12012-1691267120-1226769529@seznam.cz>
References: <750.1287-12012-1691267120-1226769529@seznam.cz>
Message-ID: <alpine.LFD.2.00.0811161250340.31837@vega3.dur.ac.uk>

On Sat, 15 Nov 2008, kvantanet at seznam.cz wrote:

> B) Using Fedora 9 and Fedora 10 Beta the RAID array is recognized but when
> booting appears an error message which is actually not affecting the
> functionality of the OS (The system boots up OK). Not sure of dmraid (RAID) functionality in case of a crash.
>
> Error:
> <SNIP>
> Setting hostname localhost.localdomain [OK]
> /etc/rc.d/rc.sysinit: line 350: 1336 Segmentation fault /sbin/dmraid.static -ay
> -i -p
> "$dmname" > /dev/null 2>&1
> Setting up Logical Volume Management : 2 logical volumes........
> </SNIP>

The segfault sounds similar to
https://bugzilla.redhat.com/show_bug.cgi?id=427550
The problem with the card I had was that the raid appeared with a very 
long name that changes from boot to boot, with the consequence that, as 
well as the segfault, the initrd referred to a a raid id that was no 
longer valid, and the system booted off half of the raid, breaking the 
mirroring.
The segfault was fixed in RHEL/Centos 5, and I worked around the changing 
name by hacking the initrd.img .

 	Michael Young



From rawhide at fedoraproject.org  Sun Nov 16 13:24:39 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sun, 16 Nov 2008 13:24:39 +0000 (UTC)
Subject: rawhide report: 20081116 changes
Message-ID: <20081116132439.E64A01F81D0@releng2.fedora.phx.redhat.com>

Compose started at Sun Nov 16 06:01:08 UTC 2008

Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 0














From rjones at redhat.com  Sun Nov 16 14:49:44 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sun, 16 Nov 2008 14:49:44 +0000
Subject: Plan for tomorrows (20081112) FESCO meeting
In-Reply-To: <491DC70F.1050905@gmail.com>
References: <1226438839.26212.2.camel@kennedy> <4919FE3B.1070602@redhat.com>
	<1226445382.3255.10.camel@kennedy>
	<20081112090223.GA24778@amd.home.annexia.org>
	<491C989A.5070001@redhat.com>
	<20081114085057.GA10744@amd.home.annexia.org>
	<491DC70F.1050905@gmail.com>
Message-ID: <20081116144944.GA13389@amd.home.annexia.org>

On Fri, Nov 14, 2008 at 10:44:31AM -0800, Toshio Kuratomi wrote:
> The test plan needs to tell people how to tell if the Feature is
> complete and whether it's reasonable to tell people it's ready to use
> when the next Fedora release comes out.  If the feature passes the test
> plan then the Feature is announced.  If it fails the test plan, then
> whatever is in the Contingency Plan would go into effect.
> 
> For MinGW, I'd ask, how do you know that the libraries you produce are
> working?  What basic goals should someone be able to achieve when using
> them?  What tasks can a tester do to show that someone wanting to
> utilize the feature is not going to be frustrated and disappointed?

OK - I'll have to think of something that doesn't involve needing
Windows.

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 icon at fedoraproject.org  Sun Nov 16 14:59:08 2008
From: icon at fedoraproject.org (Konstantin Ryabitsev)
Date: Sun, 16 Nov 2008 09:59:08 -0500
Subject: X crashes during suspend/resume
Message-ID: <f8f6300f0811160659p79202feeh33873158dc0242b6@mail.gmail.com>

Hello:

I'm wondering if anyone is seeing the same problem as me (F10 x86 on a
Thinkpad x31). After I resume from suspend, X crashes and I get back
to the GDM login screen. I tried to search bugzilla, but "Xorg suspend
resume crash" does not return anything useful, so I figured I'd ask
first in case I'm missing something obvious.

The card is ATI Technologies Inc Radeon Mobility M6 LY.

Cheers,
-- 
Konstantin Ryabitsev
Montr?al, Qu?bec



From orion at cora.nwra.com  Sun Nov 16 15:13:56 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Sun, 16 Nov 2008 08:13:56 -0700 (MST)
Subject: X crashes during suspend/resume
In-Reply-To: <f8f6300f0811160659p79202feeh33873158dc0242b6@mail.gmail.com>
References: <f8f6300f0811160659p79202feeh33873158dc0242b6@mail.gmail.com>
Message-ID: <1973.71.208.51.222.1226848436.squirrel@www.cora.nwra.com>

I just saw this running off of a live usb stick.  HP athlon desktop with
nvidia card using nv driver.

On Sun, November 16, 2008 7:59 am, Konstantin Ryabitsev wrote:
> Hello:
>
> I'm wondering if anyone is seeing the same problem as me (F10 x86 on a
> Thinkpad x31). After I resume from suspend, X crashes and I get back
> to the GDM login screen. I tried to search bugzilla, but "Xorg suspend
> resume crash" does not return anything useful, so I figured I'd ask
> first in case I'm missing something obvious.
>
> The card is ATI Technologies Inc Radeon Mobility M6 LY.
>
> Cheers,
> --
> Konstantin Ryabitsev
> Montr??al, Qu??bec
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
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 pertusus at free.fr  Sun Nov 16 16:08:39 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 16 Nov 2008 17:08:39 +0100
Subject: BugZappers/HouseKeeping is a policy and seems incomplete
Message-ID: <20081116160839.GC2933@free.fr>

Hello,

https://fedoraproject.org/wiki/BugZappers/HouseKeeping
should certainly be in 
https://fedoraproject.org/wiki/PackageMaintainers/Policy
currently it is very hard to find. Maybe it should be rerwrited to be
presented as a policy, but currently putting it in Policy should be
better than the current situation.

And also I didn't found anything on this page telling that EOL version
bugs are automatically closed although I think that it is the case.

--
Pat



From pertusus at free.fr  Sun Nov 16 16:10:09 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 16 Nov 2008 17:10:09 +0100
Subject: PackageMaintainers/Policy/EOL out of date
In-Reply-To: <20081025102343.GB2608@free.fr>
References: <20081025102343.GB2608@free.fr>
Message-ID: <20081116161009.GD2933@free.fr>

On Sat, Oct 25, 2008 at 12:23:43PM +0200, Patrice Dumas wrote:
> Hello,
> 
> The page 
> https://fedoraproject.org/wiki/PackageMaintainers/Policy/EOL
> is out of date, pre-merge.

I fixed it. There is no expanded version anymore, since I didn't know 
what more to add.

--
Pat



From tgl at redhat.com  Sun Nov 16 17:07:35 2008
From: tgl at redhat.com (Tom Lane)
Date: Sun, 16 Nov 2008 12:07:35 -0500
Subject: tzdata in FC10 is older than the one in FC9 
In-Reply-To: <20081116101700.123f2y19t3bio8oc@mail.rimini.com> 
References: <20081116101700.123f2y19t3bio8oc@mail.rimini.com>
Message-ID: <648.1226855255@sss.pgh.pa.us>

Davide Moretti <dave at rimini.com> writes:
> In fc9 we have tzdata-2008i while in fc10 there is tzdata-2008h...

Most likely it's queued for a zero-day update.  I've got a couple
packages that are in similar states --- it's not worth trying to
persuade the release honchos to respin F10 for minor updates.

			regards, tom lane



From seg at haxxed.com  Sun Nov 16 17:15:43 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Sun, 16 Nov 2008 11:15:43 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <491DD235.1080807@gmail.com>
References: <1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
	<alpine.LFD.2.00.0811130954360.19678@localhost.localdomain>
	<87ej1fhatg.fsf@fc5.bigo.ensc.de>	<1226676673.22230.212.camel@code.and.org>
	<20081114162610.GA30721@nostromo.devel.redhat.com>
	<1226681186.11393.26.camel@luminos.localdomain>
	<1226684812.4355.10.camel@code.and.org>
	<alpine.LFD.2.00.0811141256010.26126@localhost.localdomain>
	<20081114184849.GH30721@nostromo.devel.redhat.com>
	<491DD235.1080807@gmail.com>
Message-ID: <1226855743.14512.36.camel@localhost.localdomain>

On Fri, 2008-11-14 at 13:32 -0600, Les Mikesell wrote:
> Bill Nottingham wrote:
> > Seth Vidal (skvidal at fedoraproject.org) said: 
> >> Curiously enough you could make a fedora spin repodata now with  
> >> mergerepo and then modifyrepo to add the spin-specific comps and  
> >> provider-selection metadata all pointing back to 'everything' for the  
> >> actual packages.
> > 
> > Or (sick thought of the day) have a package that drops a unchanging
> > repo definition, comps file, preferred app, metadata all on the local
> > disk, to define defaults for that install.
> 
> I'm still conviced that what is needed is a simple way to export a 
> complete installed list from any working machine along with repo and 
> version information that the machine repeating the install can use or 
> ignore.  That way there is no guesswork in the installer and it works 
> the same for a spin providing some extra stuff in  an additional repo 
> and a local shop with local packages in a local repo.

So develop one. You can start with:

rpm -qa --queryformat %{NAME}-%{version}-%{release}.%{arch}\\n | sort > packagelist.txt

Then on the destination:

xargs yum install < packagelist.txt

There, you're 90% there with just two trivial lines of shellscript.

The repo part is problematic because rpm doesn't keep track of what
repos stuff came from. Also, how do you tell the destination machine to
use the same repos? I suppose you could just serialize the entire yum
configuration from the source machine, and dump it on the destination.
Brute force but effective.

Then there's the problem of what to do with differing archs. If they're
both x86_64, you probably want the multilib configuration mirrored too.
On the other hand, if the destination is *not* the same arch as the
source, it's going to barf unless you strip out the arch first.

The fact that Fedora doesn't keep old packages around is going to cause
you problems as updates come out the firehose, unless you maintain your
own Fedora mirror that you control, which you really ought to be doing
if you're doing mission critical deployments...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081116/5da1feba/attachment.sig>

From pertusus at free.fr  Sun Nov 16 17:20:41 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 16 Nov 2008 18:20:41 +0100
Subject: PackageMaintainers/Policy/EOL pages and FESCo responsibilities
Message-ID: <20081116172041.GE2933@free.fr>

Hello,

I think that the PackageMaintainers/Policy pages should be under FESCo 
responsibility, such that
* they are updated when policies are updated
* new policies are added

FESCo should not necessarily take care of the actual writing, but at
least oblige packagers who proposed a new policy that was accepted to
update the Policy page, and similarly when a policy is changed.

I think that FESCo should also oblige Infra/Releng/documentation/BugZappers 
(and other similar groups) to modify the Policy pages when they introduce 
changes that modify policies. I don't know how exactly is FESCo aware of 
what changes in other groups, but at least should try to act such that
packagers are aware of policies that are important for them. This could
simply be redirections to pages maintained by those other groups.

Examples of policies that may be (or not) missing are release notes,
bugzilla handling, features. And PackageMaintainers/MaintainerResponsibility 
should certainly be a policy too.



Of course FESCo is somehow responsible for all that is in the wiki, but
for policies it is even more important since these are meant to be
mandatory things. 

However, currently the Policies pages are in a very bad state, which is
pretty bad, in my opinion, for new packagers, especially those who don't
read through all that goes along in fedora-devel-list.

--
Pat



From pertusus at free.fr  Sun Nov 16 17:22:34 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 16 Nov 2008 18:22:34 +0100
Subject: PackageMaintainers/Policy pages and FESCo responsibilities
In-Reply-To: <20081116172041.GE2933@free.fr>
References: <20081116172041.GE2933@free.fr>
Message-ID: <20081116172234.GF2933@free.fr>

On Sun, Nov 16, 2008 at 06:20:41PM +0100, Patrice Dumas wrote:
> Hello,

The subject should have been 
PackageMaintainers/Policy pages and FESCo responsibilities

--
Pat



From nicolas.mailhot at laposte.net  Sun Nov 16 17:25:46 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 16 Nov 2008 18:25:46 +0100
Subject: tzdata in FC10 is older than the one in FC9
In-Reply-To: <648.1226855255@sss.pgh.pa.us>
References: <20081116101700.123f2y19t3bio8oc@mail.rimini.com>
	<648.1226855255@sss.pgh.pa.us>
Message-ID: <1226856346.20645.4.camel@arekh.okg>

Le dimanche 16 novembre 2008 ? 12:07 -0500, Tom Lane a ?crit :
> Davide Moretti <dave at rimini.com> writes:
> > In fc9 we have tzdata-2008i while in fc10 there is tzdata-2008h...
> 
> Most likely it's queued for a zero-day update. 

It's not in Fedora 11 rawhide either.

Most likely the tzdata maintainer did not update rawhide first, with the
usual "updates for Fedora X are newer than stuff in Fedora X+1) effects.

Please always push packages in fedora-devel first. Thanks.

-- 
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/20081116/7ff1727b/attachment.sig>

From pertusus at free.fr  Sun Nov 16 17:31:46 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 16 Nov 2008 18:31:46 +0100
Subject: PackageMaintainers/Policy/EncourageComaintainership is out of date
Message-ID: <20081116173146.GG2933@free.fr>

Hello,

https://fedoraproject.org/wiki/PackageMaintainers/Policy/EncourageComaintainership
is badly out of date. It doesn't incorporate changes corresponding with
changes in infra (bohdi, packageDB, ACL) and more recent changes with
provenpackager and packager split and corresponding ACL opening.

Also there are things that looks old in that page, like
https://fedoraproject.org/wiki/PackageMaintainers/Policy/EncourageComaintainership#Coordination_between_maintainers

--
Pat



From ndbecker2 at gmail.com  Sun Nov 16 18:03:10 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sun, 16 Nov 2008 13:03:10 -0500
Subject: howto update dependent packages
Message-ID: <gfpn8v$3qe$1@ger.gmane.org>

I have a pair of packages, igraph and python-igraph.  python-igraph requires a matching version of igraph.

I build igraph-0.5.1 on F-9.

Trying to build python-igraph on F-9:
http://koji.fedoraproject.org/koji/taskinfo?taskID=935253

DEBUG util.py:250:  No Package Found for igraph-devel = 0.5.1

What do I need to do so that igraph-devel-0.5.1 is available (without committing igraph-0.5.1 to testing)?



From orcanbahri at yahoo.com  Sun Nov 16 18:14:30 2008
From: orcanbahri at yahoo.com (Orcan Ogetbil)
Date: Sun, 16 Nov 2008 10:14:30 -0800 (PST)
Subject: howto update dependent packages
In-Reply-To: <gfpn8v$3qe$1@ger.gmane.org>
Message-ID: <789009.48920.qm@web32808.mail.mud.yahoo.com>

--- On Sun, 11/16/08, Neal Becker wrote:
> 
> What do I need to do so that igraph-devel-0.5.1 is
> available (without committing igraph-0.5.1 to testing)?
> 
I came across the same issue the other day and I found out that it is not documented very well. You need to file a ticket to the release engineering team (rel-eng), and ask them to tag the first build so you can make subsequent builds against it.

https://fedoraproject.org/wiki/ReleaseEngineering#Contact_Information

This page needs to be linked from appropriate places in the wiki so people don't get confused. I might do that sometime this week.

-oget


      



From ndbecker2 at gmail.com  Sun Nov 16 18:18:49 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sun, 16 Nov 2008 13:18:49 -0500
Subject: howto update dependent packages
References: <gfpn8v$3qe$1@ger.gmane.org>
	<789009.48920.qm@web32808.mail.mud.yahoo.com>
Message-ID: <gfpo69$6bf$1@ger.gmane.org>

Orcan Ogetbil wrote:

> --- On Sun, 11/16/08, Neal Becker wrote:
>> 
>> What do I need to do so that igraph-devel-0.5.1 is
>> available (without committing igraph-0.5.1 to testing)?
>> 
> I came across the same issue the other day and I found out that it is not
> documented very well. You need to file a ticket to the release engineering
> team (rel-eng), and ask them to tag the first build so you can make
> subsequent builds against it.
> 
> https://fedoraproject.org/wiki/ReleaseEngineering#Contact_Information
> 
> This page needs to be linked from appropriate places in the wiki so people
> don't get confused. I might do that sometime this week.
> 
> -oget
> 

Is this a 1-time thing, or will I need to repeat this for each update?



From orcanbahri at yahoo.com  Sun Nov 16 18:22:13 2008
From: orcanbahri at yahoo.com (Orcan Ogetbil)
Date: Sun, 16 Nov 2008 10:22:13 -0800 (PST)
Subject: howto update dependent packages
In-Reply-To: <gfpo69$6bf$1@ger.gmane.org>
Message-ID: <574520.10261.qm@web32806.mail.mud.yahoo.com>


--- On Sun, 11/16/08, Neal Becker wrote:
> Orcan Ogetbil wrote:
> 
> > --- On Sun, 11/16/08, Neal Becker wrote:
> >> 
> >> What do I need to do so that igraph-devel-0.5.1 is
> >> available (without committing igraph-0.5.1 to
> testing)?
> >> 
> > I came across the same issue the other day and I found
> out that it is not
> > documented very well. You need to file a ticket to the
> release engineering
> > team (rel-eng), and ask them to tag the first build so
> you can make
> > subsequent builds against it.
> > 
> >
> https://fedoraproject.org/wiki/ReleaseEngineering#Contact_Information
> > 
> > This page needs to be linked from appropriate places
> in the wiki so people
> > don't get confused. I might do that sometime this
> week.
> > 
> > -oget
> > 
> 
> Is this a 1-time thing, or will I need to repeat this for
> each update?
> 
As far as I understood, you'll need to repeat it everytime (even for the same packages).

-oget


      



From jdieter at gmail.com  Sun Nov 16 18:30:43 2008
From: jdieter at gmail.com (Jonathan Dieter)
Date: Sun, 16 Nov 2008 20:30:43 +0200
Subject: starting Fedora Server SIG
In-Reply-To: <1226855743.14512.36.camel@localhost.localdomain>
References: <1226517797.5295.13.camel@luminos.localdomain>
	<20081112200750.GF1461854@hiwaay.net>
	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>
	<alpine.LFD.2.00.0811130954360.19678@localhost.localdomain>
	<87ej1fhatg.fsf@fc5.bigo.ensc.de>	<1226676673.22230.212.camel@code.and.org>
	<20081114162610.GA30721@nostromo.devel.redhat.com>
	<1226681186.11393.26.camel@luminos.localdomain>
	<1226684812.4355.10.camel@code.and.org>
	<alpine.LFD.2.00.0811141256010.26126@localhost.localdomain>
	<20081114184849.GH30721@nostromo.devel.redhat.com>
	<491DD235.1080807@gmail.com>
	<1226855743.14512.36.camel@localhost.localdomain>
Message-ID: <1226860243.15675.15.camel@jdlaptop.lesbg.loc>

On Sun, 2008-11-16 at 11:15 -0600, Callum Lerwick wrote:
> On Fri, 2008-11-14 at 13:32 -0600, Les Mikesell wrote:
> > I'm still conviced that what is needed is a simple way to export a 
> > complete installed list from any working machine along with repo and 
> > version information that the machine repeating the install can use or 
> > ignore.  That way there is no guesswork in the installer and it works 
> > the same for a spin providing some extra stuff in  an additional repo 
> > and a local shop with local packages in a local repo.
> 
> So develop one. You can start with:
> 
> rpm -qa --queryformat %{NAME}-%{version}-%{release}.%{arch}\\n | sort > packagelist.txt
> 
> Then on the destination:
> 
> xargs yum install < packagelist.txt
> 
> There, you're 90% there with just two trivial lines of shellscript.
<snip>

Here's a little python script I wrote that will give you a minimum
package list based on the current install's yum setup.  The idea is that
you can use this to work out a kickstart file based on your current
setup.

(Please note that despite the name, it doesn't actually *build* the
kickstart file; just the packages section.  Also note that it requires
yum-utils.)

Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build_ks.py
Type: text/x-python
Size: 3941 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081116/885ac99f/attachment.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081116/885ac99f/attachment.sig>

From jonstanley at gmail.com  Mon Nov 17 00:21:39 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Sun, 16 Nov 2008 19:21:39 -0500
Subject: BugZappers/HouseKeeping is a policy and seems incomplete
In-Reply-To: <20081116160839.GC2933@free.fr>
References: <20081116160839.GC2933@free.fr>
Message-ID: <da159fda0811161621y4847991bn8a87c1807d0fec29@mail.gmail.com>

On Sun, Nov 16, 2008 at 11:08 AM, Patrice Dumas <pertusus at free.fr> wrote:

> And also I didn't found anything on this page telling that EOL version
> bugs are automatically closed although I think that it is the case.

That's mentioned on this page:

https://fedoraproject.org/wiki/BugZappers/HouseKeeping/MonthAfterRelease

And I'm not sure about linking it from the policy page, since it's not
a policy that FPC mandated. But I'll leave that to the FPC members
(who I think control that page).



From jonstanley at gmail.com  Mon Nov 17 00:24:30 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Sun, 16 Nov 2008 19:24:30 -0500
Subject: BugZappers/HouseKeeping is a policy and seems incomplete
In-Reply-To: <da159fda0811161621y4847991bn8a87c1807d0fec29@mail.gmail.com>
References: <20081116160839.GC2933@free.fr>
	<da159fda0811161621y4847991bn8a87c1807d0fec29@mail.gmail.com>
Message-ID: <da159fda0811161624s272c974flb362062f75f18d62@mail.gmail.com>

On Sun, Nov 16, 2008 at 7:21 PM, Jon Stanley <jonstanley at gmail.com> wrote:

> And I'm not sure about linking it from the policy page, since it's not
> a policy that FPC mandated. But I'll leave that to the FPC members
> (who I think control that page).

Sorry, it's already linked from there:

https://fedoraproject.org/wiki/PackageMaintainers/Policy/EOL



From henriquecsj at gmail.com  Mon Nov 17 03:04:18 2008
From: henriquecsj at gmail.com (Henrique Junior)
Date: Sun, 16 Nov 2008 19:04:18 -0800 (PST)
Subject: Fedora and Delta RPM
Message-ID: <548424.62441.qm@web45410.mail.sp1.yahoo.com>

Hi folks,
There is a plan for an extensive use of Delta RPMs in Fedora in the near future, making it a standard, as already happens in SuSE?

 Henrique "LonelySpooky" Junior
------------------------------
"In a world without walls and fences, who needs windows and gates?!"



      Veja quais s?o os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com




From itamar at ispbrasil.com.br  Mon Nov 17 03:33:05 2008
From: itamar at ispbrasil.com.br (Itamar - IspBrasil)
Date: Mon, 17 Nov 2008 01:33:05 -0200
Subject: Fedora and Delta RPM
In-Reply-To: <548424.62441.qm@web45410.mail.sp1.yahoo.com>
References: <548424.62441.qm@web45410.mail.sp1.yahoo.com>
Message-ID: <4920E5F1.7060107@ispbrasil.com.br>

may be in fc11 ?

http://fedoraproject.org/wiki/Releases/FeaturePresto


On 11/17/2008 1:04 AM, Henrique Junior wrote:
> Hi folks,
> There is a plan for an extensive use of Delta RPMs in Fedora in the near future, making it a standard, as already happens in SuSE?
>
>   Henrique "LonelySpooky" Junior
> ------------------------------
> "In a world without walls and fences, who needs windows and gates?!"
>
>
>
>        Veja quais s?o os assuntos do momento no Yahoo! +Buscados
> http://br.maisbuscados.yahoo.com
>
>
>    


-- 
------------

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 lesmikesell at gmail.com  Mon Nov 17 06:46:23 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 17 Nov 2008 00:46:23 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1226855743.14512.36.camel@localhost.localdomain>
References: <1226517797.5295.13.camel@luminos.localdomain>	<20081112200750.GF1461854@hiwaay.net>	<87ej1ghufu.fsf@sheridan.bigo.ensc.de>	<alpine.LFD.2.00.0811130954360.19678@localhost.localdomain>	<87ej1fhatg.fsf@fc5.bigo.ensc.de>	<1226676673.22230.212.camel@code.and.org>	<20081114162610.GA30721@nostromo.devel.redhat.com>	<1226681186.11393.26.camel@luminos.localdomain>	<1226684812.4355.10.camel@code.and.org>	<alpine.LFD.2.00.0811141256010.26126@localhost.localdomain>	<20081114184849.GH30721@nostromo.devel.redhat.com>	<491DD235.1080807@gmail.com>
	<1226855743.14512.36.camel@localhost.localdomain>
Message-ID: <4921133F.8000005@gmail.com>

Callum Lerwick wrote:
> 
>> I'm still conviced that what is needed is a simple way to export a 
>> complete installed list from any working machine along with repo and 
>> version information that the machine repeating the install can use or 
>> ignore.  That way there is no guesswork in the installer and it works 
>> the same for a spin providing some extra stuff in  an additional repo 
>> and a local shop with local packages in a local repo.
> 
> So develop one. You can start with:
> 
> rpm -qa --queryformat %{NAME}-%{version}-%{release}.%{arch}\\n | sort > packagelist.txt
> 
> Then on the destination:
> 
> xargs yum install < packagelist.txt
> 
> There, you're 90% there with just two trivial lines of shellscript.

That's a start for a single user to copy his machine.  I was thinking 
more of a way to publish the lists so that anyone could create the 
equivalent of a spin at the push of a button.

> The repo part is problematic because rpm doesn't keep track of what
> repos stuff came from.

That seems like a major design flaw, given an environment where it is 
impossible to pre-configure and coordinate repositories containing all 
possible packages - and expecting that situation to ever change seems 
unreasonable.

> Also, how do you tell the destination machine to
> use the same repos? I suppose you could just serialize the entire yum
> configuration from the source machine, and dump it on the destination.
> Brute force but effective.

You just need to propagate the non-standard ones.

> Then there's the problem of what to do with differing archs. If they're
> both x86_64, you probably want the multilib configuration mirrored too.
> On the other hand, if the destination is *not* the same arch as the
> source, it's going to barf unless you strip out the arch first.

That should be up to the installing client.

> The fact that Fedora doesn't keep old packages around is going to cause
> you problems as updates come out the firehose, unless you maintain your
> own Fedora mirror that you control, which you really ought to be doing
> if you're doing mission critical deployments...

It's probably impossible to turn fedora into the sort of thing you'd run 
where you need predictability.  But the same scheme should work where 
the repositories are maintained to meed this user need.

-- 
    Les Mikesell
     lesmikesell at gmail.com



From yanmin_zhang at linux.intel.com  Mon Nov 17 08:19:55 2008
From: yanmin_zhang at linux.intel.com (Zhang, Yanmin)
Date: Mon, 17 Nov 2008 16:19:55 +0800
Subject: system fails to boot
In-Reply-To: <1226644196.2866.83.camel@ymzhang>
References: <1226639781.2866.77.camel@ymzhang>
	<20081114061847.GB2227@x200.localdomain>
	<1226644196.2866.83.camel@ymzhang>
Message-ID: <1226909995.2866.116.camel@ymzhang>


On Fri, 2008-11-14 at 14:29 +0800, Zhang, Yanmin wrote:
> On Fri, 2008-11-14 at 09:18 +0300, Alexey Dobriyan wrote:
> > On Fri, Nov 14, 2008 at 01:16:21PM +0800, Zhang, Yanmin wrote:
> > > Jens,
> > > 
> > > We run into system boot failure with kernel 2.6.28-rc. We found it on a couple of
> > > machines, including T61 notebook, nehalem machine, and another HPC NX6325 notebook.
> > > All the machines use FedoraCore 8 or FedoraCore 9. With kernel prior to 2.6.28-rc,
> > > system boot doesn't fail.
> > > 
> > > I debug it and locate the root cause. Pls. see
> > > http://bugzilla.kernel.org/show_bug.cgi?id=11899
> > > https://bugzilla.redhat.com/show_bug.cgi?id=471517
> > > 
> > > As a matter of fact, there are 2 bugs.
> > > 
> > > 2) root=LABEL=/, system always can't boot. initrd init reports
> > > switchroot fails. Here is an executation branch of nash when booting:
> > >     (1) nash read /sys/block/sda/dev; Assume major is 8 (on my desktop)
> > >     (2) nash query /proc/devices with the major number; It found line  "8 sd";
> > >     (3) nash use 'sd' to search its own probe table to find device (DISK) type for the device
> > >        and add it to its own list;
> > >     (4) Later on, it probes all devices in its list to get filesystem labels;
> > >        scsi register "8 sd" always.
> > > When major is 259, nash fails to find the device(DISK) type. I enables CONFIG_DEBUG_BLOCK_EXT_DEVT=y
> > > when compiling kernel, so 259 is picked up for device /dev/sda1, which causes nash to fail
> > > to find device (DISK) type.
> > > To fixing issue 2), I create a patch for nash and another patch for kernel.
> > > http://bugzilla.kernel.org/attachment.cgi?id=18859
> > > http://bugzilla.kernel.org/attachment.cgi?id=18837
As for issue 2) with root=LABEL=/, I double-checked nash codes. That's really beyond what I imagined. I'm not
an expert of nash. kernel might allocate MINOR number from MAX_EXT_DEVT (259) for any type of disk
(cciss/ataraid/sd/ide/floppy/md ...), while nash assumes a MAJOR number is used by one of them exclusively.
In the other hand, nash probes scsi/ide/usb serially as long as the type is DEV_TYPE_DISK. I won't say
nash codes are not perfect, but nash is growing.

Peter Jones,

You maintain nash. What's your opinion?

-yanmin




From valent.turkovic at gmail.com  Mon Nov 17 08:38:28 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Mon, 17 Nov 2008 09:38:28 +0100
Subject: Automatic WEP key type/lenght recognition?
Message-ID: <64b14b300811170038k61282d70vdbe7d2daf3ba023c@mail.gmail.com>

NetworkManager currently has these menues for entering WEP:
"WEP 40/128-bit Key"
"WEP 128 bit passphase"
I'm leaving out others that are not commonly used in home environment (802.1x).

I saw lots of users having issues with "WEP 40/128-bit Key" being the
default option and when using ASCII keys.
I would suggest to use one simple but very effective mechanism for
determining if key entered is 40/104-bit, HEX or ASCII.
HEX keys have length of 10 characters for 40-bit, and 26 characters
for 104-bit keys. ASCII keys have length of 5 or 13 characters.

Could this be incoroprated into NetworkManager so that the menu
chooses appropriate type and length of key by the length of characters
that users enters?

Here is RFE: https://bugzilla.redhat.com/show_bug.cgi?id=471859

Do you see any obvious faults why this would not work or do you think
this would be a good idea?

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 debarshi.ray at gmail.com  Mon Nov 17 09:03:27 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Mon, 17 Nov 2008 14:33:27 +0530
Subject: Who moved my bug?
In-Reply-To: <kd6uu5x84u.ln2@ppp1053.in.ipex.cz>
References: <200811061243.49188.opensource@till.name>
	<1226017819.5758.11.camel@kennedy>
	<20081107111727.GA10541@mokona.greysector.net>
	<200811081419.20620.sgrubb@redhat.com>
	<tarlu5x85q.ln2@ppp1053.in.ipex.cz>
	<3170f42f0811111126y4868f99bj9fca37934c880bf0@mail.gmail.com>
	<kd6uu5x84u.ln2@ppp1053.in.ipex.cz>
Message-ID: <3170f42f0811170103w458622e2tf8ec0468f5cec076@mail.gmail.com>

> Probably BZ maintainers didn't expet anybody to use ON_DEV
> anymore. PLease, file a bug against the Bugzilla product.

Done: https://bugzilla.redhat.com/471855

Cheerio,
Debarshi



From steve at nexusuk.org  Mon Nov 17 10:18:38 2008
From: steve at nexusuk.org (Steve Hill)
Date: Mon, 17 Nov 2008 10:18:38 +0000 (GMT)
Subject: Rawhide: pulseaudio and emu10k1 problems
In-Reply-To: <113803.84811.qm@web32807.mail.mud.yahoo.com>
References: <113803.84811.qm@web32807.mail.mud.yahoo.com>
Message-ID: <alpine.LRH.1.10.0811171016260.25677@persephone.nexusuk.org>

On Sat, 15 Nov 2008, Orcan Ogetbil wrote:

> I have this problem for a couple years now. I have a SB Audigy Pro 4. 
> Mixer channel controls never controlled what they supposed to. I sent 
> multiple emails to alsa-devel list, filed a bug in their tracking 
> system, poked them on IRC...

I have to admit that the mixer isn't a new problem - I've had it ever 
since the switch from OSS to ALSA.  To be honest, the ALSA EMU10K1 driver 
has always been a huge step backwards from the OSS driver, it's a shame 
they still haven't caught up.

  - Steve
    xmpp:steve at nexusuk.org   sip:steve at nexusuk.org   http://www.nexusuk.org/

      Servatis a periculum, servatis a maleficum - Whisper, Evanescence



From steve at nexusuk.org  Mon Nov 17 10:55:10 2008
From: steve at nexusuk.org (Steve Hill)
Date: Mon, 17 Nov 2008 10:55:10 +0000 (GMT)
Subject: Audacious crashes with "Illegal instruction" on startup
Message-ID: <alpine.LRH.1.10.0811171053450.25677@persephone.nexusuk.org>


As documented in https://bugzilla.redhat.com/show_bug.cgi?id=471868

Is anyone able to use Audacious in F10 on i386?  I presume this must be a 
packaging bug?

  - Steve
    xmpp:steve at nexusuk.org   sip:steve at nexusuk.org   http://www.nexusuk.org/

      Servatis a periculum, servatis a maleficum - Whisper, Evanescence



From mschwendt at gmail.com  Mon Nov 17 11:15:42 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 17 Nov 2008 12:15:42 +0100
Subject: Audacious crashes with "Illegal instruction" on startup
In-Reply-To: <alpine.LRH.1.10.0811171053450.25677@persephone.nexusuk.org>
References: <alpine.LRH.1.10.0811171053450.25677@persephone.nexusuk.org>
Message-ID: <20081117121542.0e753d84.mschwendt@gmail.com>

On Mon, 17 Nov 2008 10:55:10 +0000 (GMT), Steve Hill wrote:

> 
> As documented in https://bugzilla.redhat.com/show_bug.cgi?id=471868
> 
> Is anyone able to use Audacious in F10 on i386?  I presume this must be a 
> packaging bug?

As a regular user of Audacious I will try to reproduce it, but right
now cannot access my Rawhide installation.

In case it is not easily reproducible, please gather the missing details
after running "debuginfo-install -y audacious" as root. More details
on how to install the debuginfo packages and how to capture backtraces
are documented here: http://fedoraproject.org/wiki/StackTraces



From kmaraas at broadpark.no  Mon Nov 17 12:20:39 2008
From: kmaraas at broadpark.no (Kjartan Maraas)
Date: Mon, 17 Nov 2008 13:20:39 +0100
Subject: Audacious crashes with "Illegal instruction" on startup
In-Reply-To: <alpine.LRH.1.10.0811171053450.25677@persephone.nexusuk.org>
References: <alpine.LRH.1.10.0811171053450.25677@persephone.nexusuk.org>
Message-ID: <1226924439.9167.0.camel@localhost.localdomain>

ma., 17.11.2008 kl. 10.55 +0000, skrev Steve Hill:
> As documented in https://bugzilla.redhat.com/show_bug.cgi?id=471868
> 
> Is anyone able to use Audacious in F10 on i386?  I presume this must be a 
> packaging bug?
> 
I just installed it and it works here.

Cheers
Kjartan




From steve at nexusuk.org  Mon Nov 17 12:35:02 2008
From: steve at nexusuk.org (Steve Hill)
Date: Mon, 17 Nov 2008 12:35:02 +0000 (GMT)
Subject: Audacious crashes with "Illegal instruction" on startup
In-Reply-To: <20081117121542.0e753d84.mschwendt@gmail.com>
References: <alpine.LRH.1.10.0811171053450.25677@persephone.nexusuk.org>
	<20081117121542.0e753d84.mschwendt@gmail.com>
Message-ID: <alpine.LRH.1.10.0811171221050.25677@persephone.nexusuk.org>

On Mon, 17 Nov 2008, Michael Schwendt wrote:

>> https://bugzilla.redhat.com/show_bug.cgi?id=471868
>
> As a regular user of Audacious I will try to reproduce it, but right
> now cannot access my Rawhide installation.

Thanks.  I've added a stack trace to bugzilla.  Disassembling the code 
tells me that it is using the cvttsd2si instruction, which is SSE2. 
Unfortunately, many i386 compatible processors don't do SSE2 (the Athlon 
XP doesn't).

  - Steve
    xmpp:steve at nexusuk.org   sip:steve at nexusuk.org   http://www.nexusuk.org/

      Servatis a periculum, servatis a maleficum - Whisper, Evanescence



From rawhide at fedoraproject.org  Mon Nov 17 13:56:29 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Mon, 17 Nov 2008 13:56:29 +0000 (UTC)
Subject: rawhide report: 20081117 changes
Message-ID: <20081117135629.CD2251F8252@releng2.fedora.phx.redhat.com>

Compose started at Mon Nov 17 06:01:09 UTC 2008

Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 0














From debarshi.ray at gmail.com  Mon Nov 17 14:22:15 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Mon, 17 Nov 2008 19:52:15 +0530
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <20081108234812.6b327e4f@laposte.net>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
	<20081108234812.6b327e4f@laposte.net>
Message-ID: <3170f42f0811170622q34247bd6u3dd410ff898c00d6@mail.gmail.com>

Sorry, I missed your mail in the mess that is my inbox.

> It's useless, he has change his email some time ago. As he cames
> sporadically on the french fedora channel, I could contact him : he

Okay, fine. I am planning to freshen up the 'pessulus' and 'gnubiff'
packages during FOSS.in, which is coming up next week.

Rakesh (CC'ed) had expressed his wish to take up gtksourceviewmm, so
hopefully that will also be taken care of.

> completely give up his contribution for fedora (he was a great geek,
> he decided to came back to the real live, you know :-));

That is very unfortunate. Would you want to look after some of the
packages Damien had?

Happy hacking,
Debarshi



From fedora at camperquake.de  Mon Nov 17 15:07:31 2008
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 17 Nov 2008 16:07:31 +0100
Subject: Audacious crashes with "Illegal instruction" on startup
In-Reply-To: <alpine.LRH.1.10.0811171221050.25677@persephone.nexusuk.org>
References: <alpine.LRH.1.10.0811171053450.25677@persephone.nexusuk.org>
	<20081117121542.0e753d84.mschwendt@gmail.com>
	<alpine.LRH.1.10.0811171221050.25677@persephone.nexusuk.org>
Message-ID: <20081117160731.7152a7dc@dhcp03.addix.net>

Hi.

On Mon, 17 Nov 2008 12:35:02 +0000 (GMT), Steve Hill wrote:

> Thanks.  I've added a stack trace to bugzilla.  Disassembling the
> code tells me that it is using the cvttsd2si instruction, which is
> SSE2. Unfortunately, many i386 compatible processors don't do SSE2
> (the Athlon XP doesn't).

The most fascinating thing about this is that you seem to be the first
to notice that. Either noone cares enough to file a bug, or there are
fewer SSE2 incapable processors out there than I thought, or GCC did not
emit that instruction in earlier releases.



From dominik at greysector.net  Mon Nov 17 15:11:48 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Mon, 17 Nov 2008 16:11:48 +0100
Subject: Audacious crashes with "Illegal instruction" on startup
In-Reply-To: <20081117160731.7152a7dc@dhcp03.addix.net>
References: <alpine.LRH.1.10.0811171053450.25677@persephone.nexusuk.org>
	<20081117121542.0e753d84.mschwendt@gmail.com>
	<alpine.LRH.1.10.0811171221050.25677@persephone.nexusuk.org>
	<20081117160731.7152a7dc@dhcp03.addix.net>
Message-ID: <20081117151148.GA22995@mokona.greysector.net>

On Monday, 17 November 2008 at 16:07, Ralf Ertzinger wrote:
> Hi.
> 
> On Mon, 17 Nov 2008 12:35:02 +0000 (GMT), Steve Hill wrote:
> 
> > Thanks.  I've added a stack trace to bugzilla.  Disassembling the
> > code tells me that it is using the cvttsd2si instruction, which is
> > SSE2. Unfortunately, many i386 compatible processors don't do SSE2
> > (the Athlon XP doesn't).
> 
> The most fascinating thing about this is that you seem to be the first
> to notice that. Either noone cares enough to file a bug, or there are
> fewer SSE2 incapable processors out there than I thought, or GCC did not
> emit that instruction in earlier releases.

GCC shouldn't be emitting SSE2 if you pass -march=i386 -mtune=generic.
If it does, it's a bug.

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 notting at redhat.com  Mon Nov 17 15:16:13 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 17 Nov 2008 10:16:13 -0500
Subject: Audacious crashes with "Illegal instruction" on startup
In-Reply-To: <20081117151148.GA22995@mokona.greysector.net>
References: <alpine.LRH.1.10.0811171053450.25677@persephone.nexusuk.org>
	<20081117121542.0e753d84.mschwendt@gmail.com>
	<alpine.LRH.1.10.0811171221050.25677@persephone.nexusuk.org>
	<20081117160731.7152a7dc@dhcp03.addix.net>
	<20081117151148.GA22995@mokona.greysector.net>
Message-ID: <20081117151610.GA3026@nostromo.devel.redhat.com>

Dominik 'Rathann' Mierzejewski (dominik at greysector.net) said: 
> > The most fascinating thing about this is that you seem to be the first
> > to notice that. Either noone cares enough to file a bug, or there are
> > fewer SSE2 incapable processors out there than I thought, or GCC did not
> > emit that instruction in earlier releases.
> 
> GCC shouldn't be emitting SSE2 if you pass -march=i386 -mtune=generic.
> If it does, it's a bug.

Looking briefly at the code, it's conditionally including asm based
on the configure check - it's not relying on the compiler to emit
it automatically.

Bill



From notting at redhat.com  Mon Nov 17 15:21:14 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 17 Nov 2008 10:21:14 -0500
Subject: [Fedora-packaging] f11 build error
In-Reply-To: <49218B42.7010305@redhat.com>
References: <49218B42.7010305@redhat.com>
Message-ID: <20081117152114.GB3026@nostromo.devel.redhat.com>

Gregory Hosler (ghosler at redhat.com) said: 
> not sure if this is the correct fedora mailing list or not to bring this up on...

fedora-devel-list may be better, CC'ing it.

> I came across a build error on X64, in F-11
> 
> I have been seeing this exact bug report my other distso users that have been building my
> package on other distro x64 platforms, and so far I do not know what the solution might be.
> 
> When i do a libtool build on a library, I am seeing the following:
> 
> /bin/sh ../libtool --tag=CC   --mode=link gcc  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
> - -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
> - -Wno-pointer-sign -funsigned-char -shared -fpic -fPIC  -o libgyachi.so gytreeview.o
> gy_config.o gyachi_lib.o parsecfg.o theme_support.o sound_plugin.o plugins.o -lgtk-x11-2.0
> - -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo
> - -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0   -lltdl
> - -lX11  -lpthread
> libtool: link: gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> - -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wno-pointer-sign
> - -funsigned-char -fpic -fPIC -o libgyachi.so gytreeview.o gy_config.o gyachi_lib.o
> parsecfg.o theme_support.o sound_plugin.o plugins.o  -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
> - -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype
> - -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lltdl -lX11 -lpthread
> /usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../lib64/crt1.o: In function `_start':
> (.text+0x20): undefined reference to `main'
> collect2: ld returned 1 exit status
> 
> ld is not treating this as a shared library, rather it is treating this as a main program.

The F-11 tree has libtool-2.2.6, instead of libtool-1.5 as in Fedora 10 and
earlier. I suspect that's what's tripping you up.

There were people who had done mass rebuilds with the new libtool - they might
be able to point out common problems are and what the fixes are.

Bill



From dcbw at redhat.com  Mon Nov 17 15:28:32 2008
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 17 Nov 2008 10:28:32 -0500
Subject: Automatic WEP key type/lenght recognition?
In-Reply-To: <64b14b300811170038k61282d70vdbe7d2daf3ba023c@mail.gmail.com>
References: <64b14b300811170038k61282d70vdbe7d2daf3ba023c@mail.gmail.com>
Message-ID: <1226935712.10028.10.camel@localhost.localdomain>

On Mon, 2008-11-17 at 09:38 +0100, Valent Turkovic wrote:
> NetworkManager currently has these menues for entering WEP:
> "WEP 40/128-bit Key"
> "WEP 128 bit passphase"
> I'm leaving out others that are not commonly used in home environment (802.1x).
> 
> I saw lots of users having issues with "WEP 40/128-bit Key" being the
> default option and when using ASCII keys.
> I would suggest to use one simple but very effective mechanism for
> determining if key entered is 40/104-bit, HEX or ASCII.
> HEX keys have length of 10 characters for 40-bit, and 26 characters
> for 104-bit keys. ASCII keys have length of 5 or 13 characters.
> 
> Could this be incoroprated into NetworkManager so that the menu
> chooses appropriate type and length of key by the length of characters
> that users enters?
> 
> Here is RFE: https://bugzilla.redhat.com/show_bug.cgi?id=471859

Replied to the bug report...

The short answer is that NM already autodetects what the key type is for
Hex and ASCII keys, but for passphrases, it's simply impossible to
distinguish them from Hex/ASCII keys.  WEP simply sucks.  WPA fixed this
by mandating that the hex key (64-characters) did not intersect with the
passphrase (8 to 63 characters).

There's probably room to improve the NM applet UI and make it clear what
to enter where.

Dan




From dbn.lists at gmail.com  Mon Nov 17 15:47:41 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Mon, 17 Nov 2008 07:47:41 -0800
Subject: [Fedora-packaging] f11 build error
In-Reply-To: <20081117152114.GB3026@nostromo.devel.redhat.com>
References: <49218B42.7010305@redhat.com>
	<20081117152114.GB3026@nostromo.devel.redhat.com>
Message-ID: <91705d080811170747s1f739243q696019571e7b987f@mail.gmail.com>

On Mon, Nov 17, 2008 at 7:21 AM, Bill Nottingham <notting at redhat.com> wrote:
> Gregory Hosler (ghosler at redhat.com) said:
>> not sure if this is the correct fedora mailing list or not to bring this up on...
>
> fedora-devel-list may be better, CC'ing it.
>
>> I came across a build error on X64, in F-11
>>
>> I have been seeing this exact bug report my other distso users that have been building my
>> package on other distro x64 platforms, and so far I do not know what the solution might be.
>>
>> When i do a libtool build on a library, I am seeing the following:
>>
>> /bin/sh ../libtool --tag=CC   --mode=link gcc  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
>> - -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
>> - -Wno-pointer-sign -funsigned-char -shared -fpic -fPIC  -o libgyachi.so gytreeview.o
>> gy_config.o gyachi_lib.o parsecfg.o theme_support.o sound_plugin.o plugins.o -lgtk-x11-2.0
>> - -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo
>> - -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0   -lltdl
>> - -lX11  -lpthread
>> libtool: link: gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
>> - -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wno-pointer-sign
>> - -funsigned-char -fpic -fPIC -o libgyachi.so gytreeview.o gy_config.o gyachi_lib.o
>> parsecfg.o theme_support.o sound_plugin.o plugins.o  -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
>> - -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype
>> - -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lltdl -lX11 -lpthread
>> /usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../lib64/crt1.o: In function `_start':
>> (.text+0x20): undefined reference to `main'
>> collect2: ld returned 1 exit status
>>
>> ld is not treating this as a shared library, rather it is treating this as a main program.
>
> The F-11 tree has libtool-2.2.6, instead of libtool-1.5 as in Fedora 10 and
> earlier. I suspect that's what's tripping you up.

Is automake being used? How are you invoking libtool? I would suspect
the correct way to do this in automake is:

wherever_LTLIBRARIES = libgyachi.la
libgyachi_la_LDFLAGS = -avoid-version

--
Dan



From Lam at Lam.pl  Mon Nov 17 16:22:52 2008
From: Lam at Lam.pl (Leszek Matok)
Date: Mon, 17 Nov 2008 17:22:52 +0100
Subject: F11: OSS and pulseaudio conflict
In-Reply-To: <1226720230.14512.14.camel@localhost.localdomain>
References: <491DA325.3010305@redhat.com>
	<1226702549.29933.2.camel@snoogens.fab.redhat.com>
	<1226720230.14512.14.camel@localhost.localdomain>
Message-ID: <20081117172252.344b76ed@pensja.lam.pl>

Dnia 2008-11-14, o godz. 21:37:10 Callum Lerwick <seg at haxxed.com> napisa?(a):

> On Fri, 2008-11-14 at 23:42 +0100, Bastien Nocera wrote:
> > Just remove OSS support from the kernel.
(...)
> > Kill it (and file a bug against the app).
> The proprietary Flash plugin was the main justification for keeping OSS
> the last time this came up. This is no longer the case.
> 
> Kill OSS emulation, kill it dead. A Fedora 11 feature perhaps?
Please don't kill it dead. Just disable by default, remove auto-loading magic,
but allow me to modprobe snd_pcm_oss if I want. Flash is one thing, but don't
forget about my Doom 3! :)

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/20081117/84f9a722/attachment.sig>

From mike at cchtml.com  Mon Nov 17 16:26:47 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Mon, 17 Nov 2008 10:26:47 -0600
Subject: F11: OSS and pulseaudio conflict
In-Reply-To: <20081117172252.344b76ed@pensja.lam.pl>
References: <491DA325.3010305@redhat.com>	<1226702549.29933.2.camel@snoogens.fab.redhat.com>	<1226720230.14512.14.camel@localhost.localdomain>
	<20081117172252.344b76ed@pensja.lam.pl>
Message-ID: <49219B47.6050007@cchtml.com>

-------- Original Message --------
Subject: Re: F11: OSS and pulseaudio conflict
From: Leszek Matok <Lam at Lam.pl>
To: fedora-devel-list at redhat.com
Date: 11/17/2008 10:22 AM


> but allow me to modprobe snd_pcm_oss if I want. Flash is one thing, but don't
> forget about my Doom 3! :)
> 
> Lam
> 


Doom 3 has ALSA support.

http://zerowing.idsoftware.com/linux/doom/#head-8c36163f1dfc3a253ef72c0f821b0b0dd2fc17b1



From gilboad at gmail.com  Mon Nov 17 16:53:53 2008
From: gilboad at gmail.com (Gilboa Davara)
Date: Mon, 17 Nov 2008 18:53:53 +0200
Subject: F11: OSS and pulseaudio conflict
In-Reply-To: <20081117172252.344b76ed@pensja.lam.pl>
References: <491DA325.3010305@redhat.com>
	<1226702549.29933.2.camel@snoogens.fab.redhat.com>
	<1226720230.14512.14.camel@localhost.localdomain>
	<20081117172252.344b76ed@pensja.lam.pl>
Message-ID: <1226940833.25705.9.camel@gilboa-work-dev.localdomain>

On Mon, 2008-11-17 at 17:22 +0100, Leszek Matok wrote:
> Dnia 2008-11-14, o godz. 21:37:10 Callum Lerwick <seg at haxxed.com> napisa?(a):
> 
> > On Fri, 2008-11-14 at 23:42 +0100, Bastien Nocera wrote:
> > > Just remove OSS support from the kernel.
> (...)
> > > Kill it (and file a bug against the app).
> > The proprietary Flash plugin was the main justification for keeping OSS
> > the last time this came up. This is no longer the case.
> > 
> > Kill OSS emulation, kill it dead. A Fedora 11 feature perhaps?
> Please don't kill it dead. Just disable by default, remove auto-loading magic,
> but allow me to modprobe snd_pcm_oss if I want. Flash is one thing, but don't
> forget about my Doom 3! :)
> 
> Lam

At least on my Audigy 2SZ (which uses the same emu10k1 driver), Doom3,
Quake4 and ETQW works just fine (@surround 5.1) w/ the alsa driver.

- Gilboa



From mw_triad at users.sourceforge.net  Mon Nov 17 16:56:28 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Mon, 17 Nov 2008 10:56:28 -0600
Subject: F11: OSS and pulseaudio conflict
In-Reply-To: <20081117172252.344b76ed@pensja.lam.pl>
References: <491DA325.3010305@redhat.com>	<1226702549.29933.2.camel@snoogens.fab.redhat.com>	<1226720230.14512.14.camel@localhost.localdomain>
	<20081117172252.344b76ed@pensja.lam.pl>
Message-ID: <gfs7ns$8sr$1@ger.gmane.org>

Leszek Matok wrote:
> Callum Lerwick wrote:
>> Kill OSS emulation, kill it dead. A Fedora 11 feature perhaps?
> Please don't kill it dead. Just disable by default, remove auto-loading magic,
> but allow me to modprobe snd_pcm_oss if I want. Flash is one thing, but don't
> forget about my Doom 3! :)

I'm confused. Earlier in the thread it was said to use padspa to provide 
an OSS interface via PA.

But Callum said "kill OSS emulation". I /think/ that means something 
other than providing "OSS" via padspa, but I'm not sure? Clarification 
would be nice.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Sendmail administration is not black magic. There are legitimate 
technical reasons why it requires the sacrifice of a live chicken. -- 
Unknown



From ivazqueznet at gmail.com  Mon Nov 17 17:15:28 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Mon, 17 Nov 2008 12:15:28 -0500
Subject: F11: OSS and pulseaudio conflict
In-Reply-To: <gfs7ns$8sr$1@ger.gmane.org>
References: <491DA325.3010305@redhat.com>
	<1226702549.29933.2.camel@snoogens.fab.redhat.com>
	<1226720230.14512.14.camel@localhost.localdomain>
	<20081117172252.344b76ed@pensja.lam.pl>  <gfs7ns$8sr$1@ger.gmane.org>
Message-ID: <1226942128.736.36.camel@ignacio.lan>

On Mon, 2008-11-17 at 10:56 -0600, Matthew Woehlke wrote:
> I'm confused. Earlier in the thread it was said to use padspa to provide 
> an OSS interface via PA.
> 
> But Callum said "kill OSS emulation". I /think/ that means something 
> other than providing "OSS" via padspa, but I'm not sure? Clarification 
> would be nice.

Removing/blocking ALSA's OSS emulation, i.e., the
snd-{pcm,seq,mixer}-oss modules.

-- 
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/20081117/0dea1ec1/attachment.sig>

From martin.langhoff at gmail.com  Mon Nov 17 19:23:00 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Mon, 17 Nov 2008 14:23:00 -0500
Subject: Tidy up of the xs-0.5 yum repo - what differentiates OLPC's XS from
	vanilla Fedora?
Message-ID: <46a038f90811171123q7a99ceb2l16c85739b30d6d7d@mail.gmail.com>

A useful bit of info, and a chance ot say thanks :-) The composition
on the XS release 0.5 breaks down like this.

A couple of packages that are in Fedora rawhide (or making a beeline
for it), but we needed ahead of time - thanks to the many Fedorans
that jumped in and helped!:

./pam_sotp-0.3.3-3.fc9.i386.rpm
./rssh-2.3.2-1.fc7.i386.rpm
./rssh-2.3.2-5.fc7.i386.rpm
./rssh-debuginfo-2.3.2-1.fc7.i386.rpm
./rssh-debuginfo-2.3.2-5.fc7.i386.rpm
./usbmount-0.15.6.olpc-1.xs7.noarch.rpm
./fakeroot-1.9.6-16.fc7.i386.rpm (an old, buggy version is in F9)
./fakeroot-debuginfo-1.9.6-16.fc7.i386.rpm

A couple packages with custom patches...
./ejabberd-xs-2.0.1-10.xs9.olpc.i386.rpm
./ejabberd-xs-2.0.1-11.fc9.olpc.i386.rpm
./moodle-xs-1.9.2.xs2.13.gdeb43cf-1.xs9.noarch.rpm

And some written-from-scratch packages -

./ds-backup-server-0.8.1-1.olpc3.noarch.rpm
./idmgr-0.7-1.xs9.noarch.rpm
./xs-activation-0.2.7.geb968d2-1.xs9.noarch.rpm
./xs-activity-server-0.2.9.g60b6827-1.xs9.noarch.rpm
./xs-callhome-0.1.0-4.noarch.rpm
./xs-config-0.5.6.gb81ed4d-1.noarch.rpm
./xs-otp-0.4.7.g0a0d328-1.xs9.noarch.rpm
./xs-pkgs-0.10-1.noarch.rpm
./xs-release-9-0.4.13.noarch.rpm
./xs-rsync-0.5.2.gb8bf5d4-1.xs7.noarch.rpm
./xs-tools-0.4.5.g40d79c0-1.xs9.noarch.rpm

Luckily, the OLPC XS delta isn't as large or as punishing as the XO
delta. We do use anaconda and yum in perhaps new and unexpected ways
-- we're right now hurting a bit on those fronts. OTOH, just like the
XO, we need smaller memory and disk footprints, through
less/better/smaller daemons and smarter, tighter dependencies (which
have improved quite a bit lately - thanks!).

cheers,



martin
-- 
 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 mike.cloaked at gmail.com  Mon Nov 17 20:24:15 2008
From: mike.cloaked at gmail.com (Mike)
Date: Mon, 17 Nov 2008 20:24:15 +0000 (UTC)
Subject: iproute - Error: an inet prefix is expected rather than "0/0"
References: <68720af30811120819w33e6cc16r8c14b33623bcee34@mail.gmail.com>
	<68720af30811121013p49a81788xe080e1640084f8b@mail.gmail.com>
Message-ID: <loom.20081117T202250-382@post.gmane.org>

Paulo Cavalcanti <promac <at> gmail.com> writes:

> In fact it has been fixed in initscripts 0.82* 
>Wed Sep 10 2008 Bill Nottingham <notting <at> redhat.com> - 8.82-1

On checking koji it seems that no build for F8 has been made for initscripts
8.82 as far as I can tell? Certainly builds for F10 tag are there...





From katzj at redhat.com  Mon Nov 17 20:47:36 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 17 Nov 2008 15:47:36 -0500
Subject: Tidy up of the xs-0.5 yum repo - what differentiates OLPC's XS
 from vanilla Fedora?
In-Reply-To: <46a038f90811171123q7a99ceb2l16c85739b30d6d7d@mail.gmail.com>
References: <46a038f90811171123q7a99ceb2l16c85739b30d6d7d@mail.gmail.com>
Message-ID: <1226954856.13086.154.camel@aglarond.local>

On Mon, 2008-11-17 at 14:23 -0500, Martin Langhoff wrote:
> A couple packages with custom patches...
> ./ejabberd-xs-2.0.1-10.xs9.olpc.i386.rpm
> ./ejabberd-xs-2.0.1-11.fc9.olpc.i386.rpm
> ./moodle-xs-1.9.2.xs2.13.gdeb43cf-1.xs9.noarch.rpm

For these, what's the path to getting the patches available upstream?
Especially as I know I've seen ejbabberd now mentioned in a few
different contexts for OLPC related patches.  Is upstream fundamentally
against the changes or is it just there's not a newer release?  If the
latter, then (with some agreement from the Fedora ejabberd maintainer),
it's something that could be considered being carried in Fedora until
there's a new upstream release.

Jeremy



From Lam at Lam.pl  Mon Nov 17 20:50:01 2008
From: Lam at Lam.pl (Leszek Matok)
Date: Mon, 17 Nov 2008 21:50:01 +0100
Subject: F11: OSS and pulseaudio conflict
In-Reply-To: <1226940833.25705.9.camel@gilboa-work-dev.localdomain>
References: <491DA325.3010305@redhat.com>
	<1226702549.29933.2.camel@snoogens.fab.redhat.com>
	<1226720230.14512.14.camel@localhost.localdomain>
	<20081117172252.344b76ed@pensja.lam.pl>
	<1226940833.25705.9.camel@gilboa-work-dev.localdomain>
Message-ID: <20081117215001.35571146@pensja.lam.pl>

Dnia 2008-11-17, o godz. 18:53:53 Gilboa Davara <gilboad at gmail.com> napisa?(a):

> At least on my Audigy 2SZ (which uses the same emu10k1 driver), Doom3,
> Quake4 and ETQW works just fine (@surround 5.1) w/ the alsa driver.
It doesn't work at all on my ENS1371 (according to ALSA, it has 44099 Hz
output ;)) and produces the "metallic" sound on my on-board HDA Intel. There
are some non-working tricks using dmix (which I can't be bothered to learn to
use), but the only working and at the same time easy to configure (like one
click in the in-game GUI) solution is to use OSS emulation.

Quake 4, on the other hand, claims to use OpenAL and works properly.

Please don't kill snd_pcm_oss completely :)

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/20081117/51ac7836/attachment.sig>

From wtogami at redhat.com  Mon Nov 17 21:04:10 2008
From: wtogami at redhat.com (Warren Togami)
Date: Mon, 17 Nov 2008 16:04:10 -0500
Subject: F11: OSS and pulseaudio conflict
In-Reply-To: <1226720230.14512.14.camel@localhost.localdomain>
References: <491DA325.3010305@redhat.com>	<1226702549.29933.2.camel@snoogens.fab.redhat.com>
	<1226720230.14512.14.camel@localhost.localdomain>
Message-ID: <4921DC4A.8020102@redhat.com>

Callum Lerwick wrote:
> 
> The proprietary Flash plugin was the main justification for keeping OSS
> the last time this came up. This is no longer the case.
> 
> Kill OSS emulation, kill it dead. A Fedora 11 feature perhaps?
> 

How long ago was this?  Flash 7 did esd output by default before it fell 
back to OSS.

Warren



From fedora at matbooth.co.uk  Mon Nov 17 21:13:19 2008
From: fedora at matbooth.co.uk (Mat Booth)
Date: Mon, 17 Nov 2008 21:13:19 +0000
Subject: Adobe Releases 64bit Flash Plugin for Linux
Message-ID: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>

FYI

http://blogs.adobe.com/penguin.swf/2008/11/now_supporting_16_exabytes.html

-- 
Mat Booth
www.matbooth.co.uk



From dominik at greysector.net  Mon Nov 17 21:31:16 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Mon, 17 Nov 2008 22:31:16 +0100
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>
Message-ID: <20081117213116.GA25672@mokona.greysector.net>

On Monday, 17 November 2008 at 22:13, Mat Booth wrote:
> FYI
> 
> http://blogs.adobe.com/penguin.swf/2008/11/now_supporting_16_exabytes.html

And here's a proper (spec for) rpm package, not the crap that Adobe
is distributing:
http://rathann.fedorapeople.org/scratch/flash-plugin.spec

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 jonathan at jonmasters.org  Mon Nov 17 21:35:27 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Mon, 17 Nov 2008 16:35:27 -0500
Subject: F11 Proposal: Stabilization
Message-ID: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>

Yo,

Can I make a proposal for a major theme for an upcoming Fedora (whether
F11 or F12): Stabilization.

Rather than the latest bells and whistles, I would personally much
prefer that stuff that used to work didn't break randomly, and that
stable Fedora updates wouldn't result in me wondering whether suspend,
graphics, SELinux, or some other feature that was working was going to
break today. This isn't actually a rant, more pointing out a necessity.

Discuss.

Jon.




From notting at redhat.com  Mon Nov 17 21:37:42 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 17 Nov 2008 16:37:42 -0500
Subject: F11 Proposal: Stabilization
In-Reply-To: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
Message-ID: <20081117213742.GB5603@nostromo.devel.redhat.com>

Jon Masters (jonathan at jonmasters.org) said: 
> Can I make a proposal for a major theme for an upcoming Fedora (whether
> F11 or F12): Stabilization.
> 
> Rather than the latest bells and whistles, I would personally much
> prefer that stuff that used to work didn't break randomly, and that
> stable Fedora updates wouldn't result in me wondering whether suspend,
> graphics, SELinux, or some other feature that was working was going to
> break today. This isn't actually a rant, more pointing out a necessity.

Well, 'stable updates' wouldn't apply to F11 for quite a while now. :)

Bill



From cdahlin at redhat.com  Mon Nov 17 21:47:47 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Mon, 17 Nov 2008 16:47:47 -0500
Subject: F11 Proposal: Stabilization
In-Reply-To: <20081117213742.GB5603@nostromo.devel.redhat.com>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<20081117213742.GB5603@nostromo.devel.redhat.com>
Message-ID: <4921E683.30407@redhat.com>

Bill Nottingham wrote:
> Jon Masters (jonathan at jonmasters.org) said: 
>   
>> Can I make a proposal for a major theme for an upcoming Fedora (whether
>> F11 or F12): Stabilization.
>>
>> Rather than the latest bells and whistles, I would personally much
>> prefer that stuff that used to work didn't break randomly, and that
>> stable Fedora updates wouldn't result in me wondering whether suspend,
>> graphics, SELinux, or some other feature that was working was going to
>> break today. This isn't actually a rant, more pointing out a necessity.
>>     
>
> Well, 'stable updates' wouldn't apply to F11 for quite a while now. :)
>
> Bill
>
>   
Its never too early to start implementing the necessary bureaucracy :)

If John is volunteering to own it I'd like to see where this goes. I'd 
be interested to know what beyond "don't break stuff" is necessary to 
make this work.

--CJD



From tcallawa at redhat.com  Mon Nov 17 21:47:19 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 17 Nov 2008 16:47:19 -0500
Subject: F11 Proposal: Stabilization
In-Reply-To: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
Message-ID: <1226958439.3814.6.camel@localhost.localdomain>

On Mon, 2008-11-17 at 16:35 -0500, Jon Masters wrote:
> Yo,
> 
> Can I make a proposal for a major theme for an upcoming Fedora (whether
> F11 or F12): Stabilization.
> 
> Rather than the latest bells and whistles, I would personally much
> prefer that stuff that used to work didn't break randomly, and that
> stable Fedora updates wouldn't result in me wondering whether suspend,
> graphics, SELinux, or some other feature that was working was going to
> break today. This isn't actually a rant, more pointing out a necessity.

I'm not sure what magic fairy we'll have to sacrifice for this. We're
always going to be moving forward and things are going to break.

If you're volunteering to help QA, then I applaud you.

~spot



From orion at cora.nwra.com  Mon Nov 17 21:52:06 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Mon, 17 Nov 2008 14:52:06 -0700
Subject: Dependency loop with pcre
Message-ID: <4921E786.8010408@cora.nwra.com>

It appears that there is an rpm dependency loop (or something) involving 
pcre in current rawhide so that during install you can get the following:

   Installing: tcsh                         ################### [ 413/1262]
grep: error while loading shared libraries: libpcre.so.0: cannot open 
shared object file: No such file or directory
   Installing: mlocate                      ################### [ 424/1262]
/bin/grep: error while loading shared libraries: libpcre.so.0: cannot 
open shared object file: No such file or directory
   Installing: coreutils                    ################### [ 442/1262]
/bin/grep: error while loading shared libraries: libpcre.so.0: cannot 
open shared object file: No such file or directory
   Installing: fontconfig                   ################### [ 443/1262]
grep: error while loading shared libraries: libpcre.so.0: cannot open 
shared object file: No such file or directory
   Installing: pcre                         ################### [ 453/1262]

Any idea how to fix this?


-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com



From jspaleta at gmail.com  Mon Nov 17 21:54:47 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 17 Nov 2008 12:54:47 -0900
Subject: F11 Proposal: Stabilization
In-Reply-To: <4921E683.30407@redhat.com>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<20081117213742.GB5603@nostromo.devel.redhat.com>
	<4921E683.30407@redhat.com>
Message-ID: <604aa7910811171354h26c8eb30r72280cc95ba9a976@mail.gmail.com>

On Mon, Nov 17, 2008 at 12:47 PM, Casey Dahlin <cdahlin at redhat.com> wrote:
>> Well, 'stable updates' wouldn't apply to F11 for quite a while now. :)

The proposal is more emotive than actionable so there isn't much to
discuss really.

But as a matainer, here's what I'll do.  If Jon builds a set of
automated test scripts and integrates them into the build environment
and update-testing system, I will promise to make an effort to read
the resulting bugzilla tickets produced when the scripts find a
deficiency that would have resulted in a regression.  Can you really
expect me to do more than that?

-jef



From jonathan at jonmasters.org  Mon Nov 17 22:16:59 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Mon, 17 Nov 2008 17:16:59 -0500
Subject: F11 Proposal: Stabilization
In-Reply-To: <604aa7910811171354h26c8eb30r72280cc95ba9a976@mail.gmail.com>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<20081117213742.GB5603@nostromo.devel.redhat.com>
	<4921E683.30407@redhat.com>
	<604aa7910811171354h26c8eb30r72280cc95ba9a976@mail.gmail.com>
Message-ID: <1226960219.4098.20.camel@perihelion.bos.jonmasters.org>

On Mon, 2008-11-17 at 12:54 -0900, Jeff Spaleta wrote:
> On Mon, Nov 17, 2008 at 12:47 PM, Casey Dahlin <cdahlin at redhat.com> wrote:
> >> Well, 'stable updates' wouldn't apply to F11 for quite a while now. :)
> 
> The proposal is more emotive than actionable so there isn't much to
> discuss really.

I disagree. Various other communities (and distributions) have made a
point out of "stable" releases where the "big ticket" feature is
stabilization, so I think it would be a win to consider that. It's
harder to recommend Fedora to friends when they see stuff break.

Cheers,

Jon.




From jspaleta at gmail.com  Mon Nov 17 22:30:12 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 17 Nov 2008 13:30:12 -0900
Subject: F11 Proposal: Stabilization
In-Reply-To: <1226960219.4098.20.camel@perihelion.bos.jonmasters.org>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<20081117213742.GB5603@nostromo.devel.redhat.com>
	<4921E683.30407@redhat.com>
	<604aa7910811171354h26c8eb30r72280cc95ba9a976@mail.gmail.com>
	<1226960219.4098.20.camel@perihelion.bos.jonmasters.org>
Message-ID: <604aa7910811171430p43e0c946x32db75692e7e2fa4@mail.gmail.com>

On Mon, Nov 17, 2008 at 1:16 PM, Jon Masters <jonathan at jonmasters.org> wrote:
> I disagree. Various other communities (and distributions) have made a
> point out of "stable" releases where the "big ticket" feature is
> stabilization, so I think it would be a win to consider that. It's
> harder to recommend Fedora to friends when they see stuff break.

I'm not hearing any concrete action items on how you think we could do
better inside of our process.  I gave you a hint as to where you could
be focusing your effort to drive improvment.


-jef"really wants to drill down into the unspoken assumption that
underlines the line of reasoning expressed here. Just because someone
says they make stability a high priority does not mean they are doing
better at it.  But that is for another time, after I've had a chance
to deep dive into bug data from which rationale conclusions can be
drawn."spaleta



From pablo.martin-gomez at laposte.net  Mon Nov 17 22:57:23 2008
From: pablo.martin-gomez at laposte.net (Martin-Gomez Pablo)
Date: Mon, 17 Nov 2008 23:57:23 +0100
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <3170f42f0811170622q34247bd6u3dd410ff898c00d6@mail.gmail.com>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
	<20081108234812.6b327e4f@laposte.net>
	<3170f42f0811170622q34247bd6u3dd410ff898c00d6@mail.gmail.com>
Message-ID: <20081117235723.1feca5d1@laposte.net>

Le Mon, 17 Nov 2008 19:52:15 +0530,
"Debarshi Ray" <debarshi.ray at gmail.com> a ?crit :

> 
> Sorry, I missed your mail in the mess that is my inbox.
No prob' :-)
> 
> > It's useless, he has change his email some time ago. As he cames
> > sporadically on the french fedora channel, I could contact him : he
> 
> Okay, fine. I am planning to freshen up the 'pessulus' and 'gnubiff'
> packages during FOSS.in, which is coming up next week.
> 
> Rakesh (CC'ed) had expressed his wish to take up gtksourceviewmm, so
> hopefully that will also be taken care of.
> 
> > completely give up his contribution for fedora (he was a great geek,
> > he decided to came back to the real live, you know :-));
> 
> That is very unfortunate. Would you want to look after some of the
> packages Damien had?
Yes, "gnome-specimen" and "macchanger" look interesting, i'll take
them. For information, firestarter and musicbox seem to have no more
upstream, they should follow the EOL policy, no ? 
> 
> Happy hacking,
> Debarshi
> 



From dwmw2 at infradead.org  Mon Nov 17 23:14:43 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 17 Nov 2008 23:14:43 +0000
Subject: Automatic WEP key type/lenght recognition?
In-Reply-To: <1226935712.10028.10.camel@localhost.localdomain>
References: <64b14b300811170038k61282d70vdbe7d2daf3ba023c@mail.gmail.com>
	<1226935712.10028.10.camel@localhost.localdomain>
Message-ID: <1226963683.27728.314.camel@macbook.infradead.org>

On Mon, 2008-11-17 at 10:28 -0500, Dan Williams wrote:
> There's probably room to improve the NM applet UI and make it clear
> what to enter where.

If you haven't done so already, you could at least remove steps #3 and
#4 of the following process, which seems to be the one I follow _every_
time...

 #1. Enter WEP key.
 #2. Select key type.
 #3. Swear profusely.
 #4. Enter WEP key again, since it got wiped from where you entered it.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From martin.langhoff at gmail.com  Mon Nov 17 23:14:49 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Mon, 17 Nov 2008 18:14:49 -0500
Subject: Tidy up of the xs-0.5 yum repo - what differentiates OLPC's XS
	from vanilla Fedora?
In-Reply-To: <1226954856.13086.154.camel@aglarond.local>
References: <46a038f90811171123q7a99ceb2l16c85739b30d6d7d@mail.gmail.com>
	<1226954856.13086.154.camel@aglarond.local>
Message-ID: <46a038f90811171514w74f2329dra1b18c71a62777dc@mail.gmail.com>

On Mon, Nov 17, 2008 at 3:47 PM, Jeremy Katz <katzj at redhat.com> wrote:
> On Mon, 2008-11-17 at 14:23 -0500, Martin Langhoff wrote:
>> A couple packages with custom patches...
>> ./ejabberd-xs-2.0.1-10.xs9.olpc.i386.rpm
>> ./ejabberd-xs-2.0.1-11.fc9.olpc.i386.rpm
>> ./moodle-xs-1.9.2.xs2.13.gdeb43cf-1.xs9.noarch.rpm
>
> For these, what's the path to getting the patches available upstream?

In the case of ejabberd, I think the current set of patches are
upstream or will soon be. But we're very likely to have another round
of patches for the next release cycle of the XS, so likely that we'll
keep rebuilding ejabberd-xs for a while. Some of them are backports
and might be Fedora material, I'll ping the maintainer. Medium-term I
guess we can converge.

With moodle-xs, I am about to do serious OLPC-specific customisations
to it. I'm part of the upstream team in this case, so lots/most of it
I hope will apear in a future release of Moodle as configurable
options. And again, by the time these are in a release upstream I'll
probably have even more patches in my moodle-xs.

But I doubt moodle-xs will converge with a moodle package -- we're
goingto be carrying a custom version of it, perhaps forever. Maybe I
should have listed it in the "xs specific" set.

So in short I don't mind carrying these custom packages at all. They
are very much at the heart of what makes the School Server special,
codebases where we're pushing forward with new development so from a
Fedora perspective  I would say what we're doing with ejabberd-xs and
moodle-xs is too risky and not appropriate for a general purpose
distro.

So my path to happiness and high productivity with Fedora looks like

 - if the first set of packages I mentioned earlier can find its way
into a Fedora release (this looks easy, and mostly underway)

 - old-style network scripts are not deprecated ;-)

 - the anaconda-yum-rpm-revisor toolchain gets its many kinks sorted
out (I have to say thanks to many people in the buildsys and anaconda
lists for the many suggestions and workarounds)

 - the crystal ball tells me which Fedora release is likely to turn
into the base for a RHEL so I can base my LTS release on that...

and we'll continue innovating daringly on top of Fedora. That's what
we're here for :-)

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 petersen at redhat.com  Tue Nov 18 02:57:10 2008
From: petersen at redhat.com (Jens Petersen)
Date: Mon, 17 Nov 2008 21:57:10 -0500 (EST)
Subject: Broken dependencies in Fedora 9 - 2008-11-14
In-Reply-To: <20081114192441.18827.28993@faldor.intranet>
Message-ID: <75936848.429541226977030417.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

----- "Michael Schwendt" <mschwendt at gmail.com> wrote:
> package: scim-bridge-qt-0.4.15-5.fc9.i386 from fedora-9-x86_64
>   unresolved deps:
>      scim-bridge = 0:0.4.15-5.fc9

This is due to scim-bridge-0.4.15-8.fc9 in updates-newkey not being multilib.

Can we request that now to releng?

Jens



From poelstra at redhat.com  Tue Nov 18 04:59:02 2008
From: poelstra at redhat.com (John Poelstra)
Date: Mon, 17 Nov 2008 20:59:02 -0800
Subject: MinGW Feature Page (was Re: Plan for tomorrows (20081112) FESCO
	meeting)
In-Reply-To: <491DC70F.1050905@gmail.com>
References: <1226438839.26212.2.camel@kennedy>	<4919FE3B.1070602@redhat.com>	<1226445382.3255.10.camel@kennedy>	<20081112090223.GA24778@amd.home.annexia.org>	<491C989A.5070001@redhat.com>	<20081114085057.GA10744@amd.home.annexia.org>
	<491DC70F.1050905@gmail.com>
Message-ID: <49224B96.3060604@redhat.com>

Toshio Kuratomi wrote:
> Richard W.M. Jones wrote:
>> On Thu, Nov 13, 2008 at 01:14:02PM -0800, John Poelstra wrote:
>>> Richard W.M. Jones wrote:
>>>> https://fedoraproject.org/wiki/Features/Windows_cross_compiler
>>> The page appears to be only partially complete and in Category:  
>>> FeaturePageIncomplete
>> Yes because, erm, it's not complete.
>>
> I think poelcat means, it's incomplete so won't be discussed yet :-)
> 
>> Partly I have no idea what's supposed to go in the Test Plan section.
>> An actual test plan covering the features of all the libraries would
>> be huge and take weeks to run.  In addition, we have to disable %check
>> sections in MinGW packages because wine cannot run inside the mock/
>> koji environment.  Wine needs an X server and a writable $HOME.
>>
> The test plan needs to tell people how to tell if the Feature is
> complete and whether it's reasonable to tell people it's ready to use
> when the next Fedora release comes out.  If the feature passes the test
> plan then the Feature is announced.  If it fails the test plan, then
> whatever is in the Contingency Plan would go into effect.
> 
> For MinGW, I'd ask, how do you know that the libraries you produce are
> working?  What basic goals should someone be able to achieve when using
> them?  What tasks can a tester do to show that someone wanting to
> utilize the feature is not going to be frustrated and disappointed?
> 
> -Toshio
> 
> 

Yes, I meant, but failed to say, "it won't be discussed because it isn't 
done" :) The comments in this section (click edit) explain which 
category the page needs to be in: 
https://fedoraproject.org/wiki/Features/EmptyTemplate#Comments_and_Discussion

Will added some more details to the template and has renamed that 
section "How To Test".  Click "edit" for that section to see the 
suggestions.

https://fedoraproject.org/wiki/Features/EmptyTemplate#How_To_Test

John



From foss.mailinglists at gmail.com  Tue Nov 18 05:45:35 2008
From: foss.mailinglists at gmail.com (=?UTF-8?B?IlNhbmthcnNoYW4gKOCmuOCmmeCnjeCmleCmsOCnjeCmt+Cmoyki?=)
Date: Tue, 18 Nov 2008 11:15:35 +0530
Subject: F11 Proposal: Stabilization
In-Reply-To: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
Message-ID: <4922567F.6020000@gmail.com>

Jon Masters wrote:

> Can I make a proposal for a major theme for an upcoming Fedora (whether
> F11 or F12): Stabilization.

What would that cover ? And, how would one arrive at it ?


-- 

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 pemboa at gmail.com  Tue Nov 18 05:56:21 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Mon, 17 Nov 2008 23:56:21 -0600
Subject: plymouthd taking ~5s on machine
Message-ID: <16de708d0811172156w590af7b4hf70d9d7c95552599@mail.gmail.com>

Just doing some work on a laptop machine for a friend and thought to
run bootchart on it. I was surprised to see that plymouthd seemed to
be blocking for 5 seconds. I have attached the data and rendered svg
in case anyone is interested in this data.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bootchart.svgz
Type: image/svg+xml-compressed
Size: 12238 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081117/fc50d7c9/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bootchart.tgz
Type: application/x-gzip
Size: 75783 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081117/fc50d7c9/attachment-0001.bin>

From airlied at redhat.com  Tue Nov 18 06:10:21 2008
From: airlied at redhat.com (Dave Airlie)
Date: Tue, 18 Nov 2008 16:10:21 +1000
Subject: F11 Proposal: Stabilization
In-Reply-To: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
Message-ID: <1226988621.6155.1.camel@clockmaker.usersys.redhat.com>

On Mon, 2008-11-17 at 16:35 -0500, Jon Masters wrote:
> Yo,
> 
> Can I make a proposal for a major theme for an upcoming Fedora (whether
> F11 or F12): Stabilization.
> 
> Rather than the latest bells and whistles, I would personally much
> prefer that stuff that used to work didn't break randomly, and that
> stable Fedora updates wouldn't result in me wondering whether suspend,
> graphics, SELinux, or some other feature that was working was going to
> break today. This isn't actually a rant, more pointing out a necessity.
> 

really short of everyone stopping developing, moving to QA, and only
fixing bugs from QA, I think its not going to be something we can really
do.

All programmers believe their new code is stabler and better than their
old code, even when they know it isn't. They are interested in fixing
bug in the new code, not in the old code, etc...

So really unless we block all the features for F11 and focus on fixing
just QA bugs, I'm not sure what else we can do.

Dave.



From james at fedoraproject.org  Tue Nov 18 06:24:48 2008
From: james at fedoraproject.org (James Antill)
Date: Tue, 18 Nov 2008 01:24:48 -0500
Subject: Fedora and Delta RPM
In-Reply-To: <4920E5F1.7060107@ispbrasil.com.br>
References: <548424.62441.qm@web45410.mail.sp1.yahoo.com>
	<4920E5F1.7060107@ispbrasil.com.br>
Message-ID: <1226989488.4355.87.camel@code.and.org>

On Mon, 2008-11-17 at 01:33 -0200, Itamar - IspBrasil wrote:
> may be in fc11 ?
> 
> http://fedoraproject.org/wiki/Releases/FeaturePresto

 AIUI the backend code will be live for Fedora 10 GA, although to use it
on the client side you'll need to manually "yum install yum-presto".
After this large scale testing I'd guess taht yum-presto will be in the
default install for Fedora 11.

-- 
James Antill <james at fedoraproject.org>
Fedora



From fedora at leemhuis.info  Tue Nov 18 06:41:07 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 18 Nov 2008 07:41:07 +0100
Subject: F11 Proposal: Stabilization
In-Reply-To: <1226960219.4098.20.camel@perihelion.bos.jonmasters.org>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>	<20081117213742.GB5603@nostromo.devel.redhat.com>	<4921E683.30407@redhat.com>	<604aa7910811171354h26c8eb30r72280cc95ba9a976@mail.gmail.com>
	<1226960219.4098.20.camel@perihelion.bos.jonmasters.org>
Message-ID: <49226383.3010800@leemhuis.info>

On 17.11.2008 23:16, Jon Masters wrote:
 >
> Various other communities (and distributions) have made a
> point out of "stable" releases where the "big ticket" feature is
> stabilization, so I think it would be a win to consider that.

I disagree: It seems to me a lot of the current Fedora users like the 
"latest bells and whistles" style (like you called it in the mail that 
started this discussion) I for one really like the steady stream of 
kernel-updates, as that greatly improves hardware support over time! On 
OpenSuse or Ubuntu you are often forced to run the development branches 
when you need newer driver (just like it was in the early Fedora days 
and in the RHL days).

Those users otoh that don't like the steady updates stream are likely 
using other distributions already, as Fedora is doing it for quite a 
while already.

So I fear that a lot of our current users will be unhappy if Fedora gets 
closer to a updates style like those from opensuse or ubuntu. And at the 
same time we likely don't attract that many new people, as most of the 
opensuse and ubuntu users are likely glad with the distribution they use 
right now. Further: we have a fame for shipping "the latest bells and 
whistles". I suppose getting rid of that would take years...

Quoting from the mail that started this discussion:

> I would personally much
> prefer that stuff that used to work didn't break randomly, and that
> stable Fedora updates wouldn't result in me wondering whether suspend,
> graphics, SELinux, or some other feature that was working was going to
> break today. This isn't actually a rant, more pointing out a necessity.

Agreed, but I tend to say we should work towards a solution where we can 
ship the "latest bells and whistles" and nevertheless provide stability.

I for one think we need something like that:
https://www.redhat.com/archives/fedora-advisory-board/2008-August/msg00025.html

The relevant part:

"""
I more and more think that we should consider to switch to a more 
rolling release scheme with different usage levels. Roughly something 
like the following maybe:


Level 1 -- rawhide, similar to how it is today (a bit more stable and 
less breakage would be nice, but that's in the works already)

Level 2pre -- things that got tested in rawhide, that are still young, 
but known to work well in rawhide; similar to what updates-testing for 
F9 is today;

Level 2 -- things that worked fine for some time in 2pre; similar to 
what F9 is today

Level 3pre -- things that worked fine for some time in 2

Level 3 -- things that worked fine for some time in 2pre


Level 3pre and 3 are like F8-updates-testing and F8, but with the 
difference that everything has to be tested and shipped in level 2 (aka 
F9) first.
"""

CU
knurd



From dtimms at iinet.net.au  Tue Nov 18 07:28:06 2008
From: dtimms at iinet.net.au (David Timms)
Date: Tue, 18 Nov 2008 18:28:06 +1100
Subject: Segfault with alliance on liveDVD
In-Reply-To: <200811100743.04888.thibault.north@gmail.com>
References: <200811091924.06581.tnorth@fedoraproject.org>	<50baabb30811100156pe30841cw1acaada5b0f784df@mail.gmail.com>	<50baabb30811100243i260437cdja5de55c310c38ace@mail.gmail.com>
	<200811100743.04888.thibault.north@gmail.com>
Message-ID: <49226E86.8050106@iinet.net.au>

Thibault North wrote:
> Le Monday, 10. November 2008 05:43:39 am Chitlesh GOORAH, vous avez ?crit :
>> On Mon, Nov 10, 2008 at 10:56 AM, Chitlesh GOORAH wrote:
>>
>> I guess I found it : xorg-x11-fonts-misc-7.2-6.fc9.noarch
>> Without xorg-x11-fonts-misc, graal crashes. I'll spin to verify it.
>>
>> Chitlesh
> 
> I can confirm that installing xorg-x11-fonts-misc fixes the problem on the 
> liveDVD !
Would you be able to install yum-utils and then
package-cleanup --problems to find if the package management system is 
doing it's job ? ie built a live cd without needed requires ?

Or does graal have a missing Requires ?

DaveT.



From paul at city-fan.org  Tue Nov 18 07:46:40 2008
From: paul at city-fan.org (Paul Howarth)
Date: Tue, 18 Nov 2008 07:46:40 +0000
Subject: [Fedora-packaging] f11 build error
In-Reply-To: <49226978.4080006@redhat.com>
References: <49218B42.7010305@redhat.com>
	<20081117152114.GB3026@nostromo.devel.redhat.com>
	<49226978.4080006@redhat.com>
Message-ID: <20081118074640.44cbe43a@metropolis.intra.city-fan.org>

On Tue, 18 Nov 2008 15:06:32 +0800
Gregory Hosler <ghosler at redhat.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Bill Nottingham wrote:
> > Gregory Hosler (ghosler at redhat.com) said: 
> >> not sure if this is the correct fedora mailing list or not to
> >> bring this up on...
> > 
> > fedora-devel-list may be better, CC'ing it.
> 
> I actually am subscribed to fedora-devel-list, and my first
> inclination was to post to THAT list, but my post never showed up
> (and neither did your cross post reply).
> 
> Any idea on THAT ?
> 
> All the best,
> 
> - -Greg

I don't see your post there, but Bill's reply made it:

https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01173.html

Paul.



From petersen at redhat.com  Tue Nov 18 08:08:03 2008
From: petersen at redhat.com (Jens Petersen)
Date: Tue, 18 Nov 2008 03:08:03 -0500 (EST)
Subject: [LONG] The fonts SIG irregular status report
In-Reply-To: <1226394172.26647.19.camel@arekh.okg>
Message-ID: <591311043.457331226995683132.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

> As I wrote before, I don't think we could win a lot by automating.

Well I tend to agree now: a good set of templates and rpm macros seems the right way to go.

Jens



From rc040203 at freenet.de  Tue Nov 18 08:32:33 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 18 Nov 2008 09:32:33 +0100
Subject: [LONG] The fonts SIG irregular status report
In-Reply-To: <591311043.457331226995683132.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
References: <591311043.457331226995683132.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <1226997153.3752.572.camel@beck.corsepiu.local>

On Tue, 2008-11-18 at 03:08 -0500, Jens Petersen wrote:
> > As I wrote before, I don't think we could win a lot by automating.
> 
> Well I tend to agree now: a good set of templates and rpm macros seems the right way to go.
No, rpm macros are the road to ruin a distro.

Once they are used in a distro, they impose major portability issues and
are close to impossible to get rid.

Ralf





From gnomeuser at gmail.com  Tue Nov 18 08:33:05 2008
From: gnomeuser at gmail.com (David Nielsen)
Date: Tue, 18 Nov 2008 09:33:05 +0100
Subject: F11 Proposal: Stabilization
In-Reply-To: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
Message-ID: <1dedbbfc0811180033p452c02c3yfe7e4bc232a76556@mail.gmail.com>

2008/11/17 Jon Masters <jonathan at jonmasters.org>

> Yo,
>
> Can I make a proposal for a major theme for an upcoming Fedora (whether
> F11 or F12): Stabilization.
>
> Rather than the latest bells and whistles, I would personally much
> prefer that stuff that used to work didn't break randomly, and that
> stable Fedora updates wouldn't result in me wondering whether suspend,
> graphics, SELinux, or some other feature that was working was going to
> break today. This isn't actually a rant, more pointing out a necessity.


That would essencially rely on piling up code for 6 months considering we
can't do anything but backport fixes. Imagine opening the floodgates for F12
then, 6 months of new code plus whatever comes in that cycle. Also imagine
the userbase we will lose by not providing the latest GNOME, kernel, X as
well, people really do care that their new hardware is supported or that we
ship the latest OpenOffice.

What we really desperately need though is more automation in our
bugreporting, we need something like apport to catch crashers earlier, get
developers the information required to fix them without spending time
repeating instructions and increasing the feedback loop unneededly. Yes we
need to do better, but better is not achieved by ceasing development.
Automatic gathering of SELinux failures is also possible, we need to make it
happen, the sooner then better.

If we can find people willing to work on suspend, starting by writing up a
good guide for users on the wiki on how to gather the information needed
would be great. I primarily haven't filed suspend bugs because I directly
expect it not to work from experience, I assume there is a lot of work to be
done. Tell me where to start and I will test all my machines for suspend.

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081118/4848ff7b/attachment.htm>

From mmaslano at redhat.com  Tue Nov 18 09:48:20 2008
From: mmaslano at redhat.com (Marcela Maslanova)
Date: Tue, 18 Nov 2008 10:48:20 +0100
Subject: iproute - Error: an inet prefix is expected rather than "0/0"
In-Reply-To: <68720af30811120819w33e6cc16r8c14b33623bcee34@mail.gmail.com>
References: <68720af30811120819w33e6cc16r8c14b33623bcee34@mail.gmail.com>
Message-ID: <49228F64.7000708@redhat.com>

Paulo Cavalcanti wrote:
> Hi,
> 
> I updated iproute (2.6.26) today (F8), and every time I restart my network,
> I get:
> 
> Shutting down interface eth0:  Error: an inet prefix is expected rather than
> "0/0".
> Error: an inet prefix is expected rather than "0/0".
>                                                            [  OK  ]
> Shutting down loopback interface:  Error: an inet prefix is expected rather
> than "0/0".
> Error: an inet prefix is expected rather than "0/0".
>                                                            [  OK  ]
> Disabling IPv4 packet forwarding:  net.ipv4.ip_forward = 0
>                                                            [  OK  ]
> Bringing up loopback interface:                            [  OK  ]
> Bringing up interface eth0:
> 
> According to this post, it seems to be fixed with
> initscripts-8.80:
> 
> http://www.nabble.com/-Bug-42503--initscripts,-NEW:-Strange-error-messages-on-shutdown-td18824867.html
> 
> Can anyone confirm this?
> 
> Thanks.
> 
> 
I fixed it today. Please update
http://koji.fedoraproject.org/koji/buildinfo?buildID=70088

-- 
Marcela Ma?l??ov?
BaseOS team Brno



From nicolas.mailhot at laposte.net  Tue Nov 18 10:11:12 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 18 Nov 2008 11:11:12 +0100 (CET)
Subject: [LONG] The fonts SIG irregular status report
In-Reply-To: <1226997153.3752.572.camel@beck.corsepiu.local>
References: <591311043.457331226995683132.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1226997153.3752.572.camel@beck.corsepiu.local>
Message-ID: <663f4d4e204db4fa888f52000cf0f47c.squirrel@arekh.dyndns.org>



Le Mar 18 novembre 2008 09:32, Ralf Corsepius a ?crit :
>
> On Tue, 2008-11-18 at 03:08 -0500, Jens Petersen wrote:
>> > As I wrote before, I don't think we could win a lot by automating.
>>
>> Well I tend to agree now: a good set of templates and rpm macros
>> seems the right way to go.
> No, rpm macros are the road to ruin a distro.
>
> Once they are used in a distro, they impose major portability issues
> and are close to impossible to get rid.

Unfortunately, deploying fonts requires scriptlets to manage
thefontconfig cache, font packages are often huge and need splitting,
and sriplets + subpackages = boom without a minimal automation.

Please review
http://nim.fedorapeople.org/rpm-fonts/rpm-fonts-1.8-1.fc11.src.rpm
and the other files in this directory, and propose ameliorations
before we make it the backbone of our Fedora 11 font packages.

-- 
Nicolas Mailhot



From rc040203 at freenet.de  Tue Nov 18 10:33:51 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 18 Nov 2008 11:33:51 +0100
Subject: [LONG] The fonts SIG irregular status report
In-Reply-To: <663f4d4e204db4fa888f52000cf0f47c.squirrel@arekh.dyndns.org>
References: <591311043.457331226995683132.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1226997153.3752.572.camel@beck.corsepiu.local>
	<663f4d4e204db4fa888f52000cf0f47c.squirrel@arekh.dyndns.org>
Message-ID: <1227004431.3752.579.camel@beck.corsepiu.local>

On Tue, 2008-11-18 at 11:11 +0100, Nicolas Mailhot wrote:
> 
> Le Mar 18 novembre 2008 09:32, Ralf Corsepius a ?crit :
> >
> > On Tue, 2008-11-18 at 03:08 -0500, Jens Petersen wrote:
> >> > As I wrote before, I don't think we could win a lot by automating.
> >>
> >> Well I tend to agree now: a good set of templates and rpm macros
> >> seems the right way to go.
> > No, rpm macros are the road to ruin a distro.
> >
> > Once they are used in a distro, they impose major portability issues
> > and are close to impossible to get rid.
> 
> Unfortunately, deploying fonts requires scriptlets to manage
> thefontconfig cache, font packages are often huge and need splitting,
> and sriplets + subpackages = boom without a minimal automation.
> 
> Please review
> http://nim.fedorapeople.org/rpm-fonts/rpm-fonts-1.8-1.fc11.src.rpm
> and the other files in this directory, and propose ameliorations
> before we make it the backbone of our Fedora 11 font packages.
I will vote against this proposal and this package.

Rationale: 
All these macros do is causing further pollution of the rpm macros,
break many details (try rpmbuild --define '_datadir /opt/foo' and add
further cross distro-portability issues (Consider RHEL3 or rpm's from
other distros).

May be you recall the issues with Mandrake / Mandriva macros and with
SuSE-macros, now you seem to be wanting to conduct Fedora into the same
direction. 


Ralf





From nicolas.mailhot at laposte.net  Tue Nov 18 10:46:49 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 18 Nov 2008 11:46:49 +0100 (CET)
Subject: [LONG] The fonts SIG irregular status report
In-Reply-To: <1227004431.3752.579.camel@beck.corsepiu.local>
References: <591311043.457331226995683132.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1226997153.3752.572.camel@beck.corsepiu.local>
	<663f4d4e204db4fa888f52000cf0f47c.squirrel@arekh.dyndns.org>
	<1227004431.3752.579.camel@beck.corsepiu.local>
Message-ID: <43859aca04f6673c579c06b4dee9d37b.squirrel@arekh.dyndns.org>



Le Mar 18 novembre 2008 11:33, Ralf Corsepius a ?crit :
>
> On Tue, 2008-11-18 at 11:11 +0100, Nicolas Mailhot wrote:
>>
>> Le Mar 18 novembre 2008 09:32, Ralf Corsepius a ?crit :

>> Please review
>> http://nim.fedorapeople.org/rpm-fonts/rpm-fonts-1.8-1.fc11.src.rpm
>> and the other files in this directory, and propose ameliorations
>> before we make it the backbone of our Fedora 11 font packages.
> I will vote against this proposal and this package.
>
> Rationale:
> All these macros do is causing further pollution of the rpm macros,
> break many details (try rpmbuild --define '_datadir /opt/foo' and add
> further cross distro-portability issues (Consider RHEL3 or rpm's from
> other distros).
>
> May be you recall the issues with Mandrake / Mandriva macros and with
> SuSE-macros, now you seem to be wanting to conduct Fedora into the
> same direction.

What I've seen last year is:
1. packagers reinvent those independently (usually with bugs), so
there's no drawbacks and lots of benefits in providing them a clean
audited centralised version instead.
2. when you push too much logic in individual packages, this logic is
not updated (when fc-cache arguments change)
3. the current guidelines are not easy enough for most packagers.

If you don't agree with my solution to those problems please be
constructive and propose another better one.

-- 
Nicolas Mailhot



From sundaram at fedoraproject.org  Tue Nov 18 10:51:55 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 18 Nov 2008 16:21:55 +0530
Subject: F11 Proposal: Stabilization
In-Reply-To: <1226960219.4098.20.camel@perihelion.bos.jonmasters.org>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>	<20081117213742.GB5603@nostromo.devel.redhat.com>	<4921E683.30407@redhat.com>	<604aa7910811171354h26c8eb30r72280cc95ba9a976@mail.gmail.com>
	<1226960219.4098.20.camel@perihelion.bos.jonmasters.org>
Message-ID: <49229E4B.8030204@fedoraproject.org>

Jon Masters wrote:
> On Mon, 2008-11-17 at 12:54 -0900, Jeff Spaleta wrote:
>> On Mon, Nov 17, 2008 at 12:47 PM, Casey Dahlin <cdahlin at redhat.com> wrote:
>>>> Well, 'stable updates' wouldn't apply to F11 for quite a while now. :)
>> The proposal is more emotive than actionable so there isn't much to
>> discuss really.
> 
> I disagree. Various other communities (and distributions) have made a
> point out of "stable" releases where the "big ticket" feature is
> stabilization, 

Can you point out such communities and distros and tell us what they 
have done?

Rahul



From nicolas.mailhot at laposte.net  Tue Nov 18 10:58:00 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 18 Nov 2008 11:58:00 +0100 (CET)
Subject: [LONG] The fonts SIG irregular status report
In-Reply-To: <43859aca04f6673c579c06b4dee9d37b.squirrel@arekh.dyndns.org>
References: <591311043.457331226995683132.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1226997153.3752.572.camel@beck.corsepiu.local>
	<663f4d4e204db4fa888f52000cf0f47c.squirrel@arekh.dyndns.org>
	<1227004431.3752.579.camel@beck.corsepiu.local>
	<43859aca04f6673c579c06b4dee9d37b.squirrel@arekh.dyndns.org>
Message-ID: <8e893a7933fbae5ce0e1e394c9bf6823.squirrel@arekh.dyndns.org>



> Le Mar 18 novembre 2008 11:33, Ralf Corsepius a ?crit :

>> I will vote against this proposal and this package.
>>
>> Rationale:
>> All these macros do is causing further pollution of the rpm macros,
>> break many details (try rpmbuild --define '_datadir /opt/foo' and
>> add
>> further cross distro-portability issues (Consider RHEL3 or rpm's
>> from
>> other distros).
>>
>> May be you recall the issues with Mandrake / Mandriva macros and
>> with
>> SuSE-macros, now you seem to be wanting to conduct Fedora into the
>> same direction.

Also if you would just look at it you'd see the whole thing is totally
autonomous from the rpm package, and could be deployed as-is on other
distributions releases (or plain other distributions)

Taking of course into account all fontconfig versions are not equal
and one needs to adapt the base package to the capabilities of the
fontconfig provided by the distro he targets.

-- 
Nicolas Mailhot



From promac at gmail.com  Tue Nov 18 11:10:39 2008
From: promac at gmail.com (Paulo Cavalcanti)
Date: Tue, 18 Nov 2008 09:10:39 -0200
Subject: iproute - Error: an inet prefix is expected rather than "0/0"
In-Reply-To: <49228F64.7000708@redhat.com>
References: <68720af30811120819w33e6cc16r8c14b33623bcee34@mail.gmail.com>
	<49228F64.7000708@redhat.com>
Message-ID: <68720af30811180310w1eec7c87xc1b02b5dc4b78387@mail.gmail.com>

On Tue, Nov 18, 2008 at 7:48 AM, Marcela Maslanova <mmaslano at redhat.com>wrote:

> Paulo Cavalcanti wrote:
> > Hi,
> >
> > I updated iproute (2.6.26) today (F8), and every time I restart my
> network,
> > I get:
> >
> > Shutting down interface eth0:  Error: an inet prefix is expected rather
> than
> > "0/0".
> > Error: an inet prefix is expected rather than "0/0".
> >                                                            [  OK  ]
> > Shutting down loopback interface:  Error: an inet prefix is expected
> rather
> > than "0/0".
> > Error: an inet prefix is expected rather than "0/0".
> >                                                            [  OK  ]
> > Disabling IPv4 packet forwarding:  net.ipv4.ip_forward = 0
> >                                                            [  OK  ]
> > Bringing up loopback interface:                            [  OK  ]
> > Bringing up interface eth0:
> >
> > According to this post, it seems to be fixed with
> > initscripts-8.80:
> >
> >
> http://www.nabble.com/-Bug-42503--initscripts,-NEW:-Strange-error-messages-on-shutdown-td18824867.html
> >
> > Can anyone confirm this?
> >
> > Thanks.
> >
> >
> I fixed it today. Please update
> http://koji.fedoraproject.org/koji/buildinfo?buildID=70088
>
>

Thanks,

but I thought you would change/update initscripts, and
not apply iproute-2.6.26-ip-abbreviation.patch
to iproute.


-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081118/73f2a07f/attachment.htm>

From ghosler at redhat.com  Tue Nov 18 11:52:22 2008
From: ghosler at redhat.com (Gregory Hosler)
Date: Tue, 18 Nov 2008 19:52:22 +0800
Subject: f11 build error
Message-ID: <4922AC76.8080904@redhat.com>

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

> On Mon, Nov 17, 2008 at 7:21 AM, Bill Nottingham <notting redhat com> wrote:
>> Gregory Hosler (ghosler redhat com) said:
>>> not sure if this is the correct fedora mailing list or not to bring this up on...
>>
>> fedora-devel-list may be better, CC'ing it.
>>
>>> I came across a build error on X64, in F-11
>>>
>>> I have been seeing this exact bug report my other distso users that have been building my
>>> package on other distro x64 platforms, and so far I do not know what the solution might be.
>>>
>>> When i do a libtool build on a library, I am seeing the following:
>>>
>>> /bin/sh ../libtool --tag=CC   --mode=link gcc  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
>>> - -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
>>> - -Wno-pointer-sign -funsigned-char -shared -fpic -fPIC  -o libgyachi.so gytreeview.o
>>> gy_config.o gyachi_lib.o parsecfg.o theme_support.o sound_plugin.o plugins.o -lgtk-x11-2.0
>>> - -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo
>>> - -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0   -lltdl
>>> - -lX11  -lpthread
>>> libtool: link: gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
>>> - -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wno-pointer-sign
>>> - -funsigned-char -fpic -fPIC -o libgyachi.so gytreeview.o gy_config.o gyachi_lib.o
>>> parsecfg.o theme_support.o sound_plugin.o plugins.o  -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
>>> - -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype
>>> - -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lltdl -lX11 -lpthread
>>> /usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../lib64/crt1.o: In function `_start':
>>> (.text+0x20): undefined reference to `main'
>>> collect2: ld returned 1 exit status
>>>
>>> ld is not treating this as a shared library, rather it is treating this as a main program.
>>
>> The F-11 tree has libtool-2.2.6, instead of libtool-1.5 as in Fedora 10 and
>> earlier. I suspect that's what's tripping you up.
> 
> Is automake being used?

Yes

> How are you invoking libtool?

in my autogen.sh script (which runs the automake tool set) i do:

	libtoolize --copy --force --automake

which generates a libtool script.

> I would suspect the correct way to do this in automake is:
> 
> wherever_LTLIBRARIES = libgyachi.la
> libgyachi_la_LDFLAGS = -avoid-version

hmm... My libtool script does not have any references to anything *_LTLIBRARIES
so i'm kinda at a loss as to the above 2 statements, or how to make them happen


I'm attaching my autogen.sh, as well as my generated libtool script (generated on a x86
platform. Note that I'm only having the problem on X86_64, and only on F-11)

I'd really like to fix my autogen.sh script. I've looked into the libtool info, but I'm
not sure where in that to start. Any hints would be greatly appreciated!

All the best,

- -Greg

> --
> Dan


- --
+---------------------------------------------------------------------+

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.7 (GNU/Linux)

iD8DBQFJIqxz404fl/0CV/QRAncgAKDaE6c0qCZltV7jmI3bxuWc+WB+4gCfXriP
SrXu0JITvNHoZ9vgIytKcJw=
=0BU2
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: autogen.sh
Type: application/x-shellscript
Size: 2543 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081118/8774581a/attachment.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: libtool
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081118/8774581a/attachment.ksh>

From dbn.lists at gmail.com  Tue Nov 18 12:07:45 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Tue, 18 Nov 2008 04:07:45 -0800
Subject: f11 build error
In-Reply-To: <4922AC76.8080904@redhat.com>
References: <4922AC76.8080904@redhat.com>
Message-ID: <91705d080811180407k3199841bm111a61c0a46651da@mail.gmail.com>

2008/11/18 Gregory Hosler <ghosler at redhat.com>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> On Mon, Nov 17, 2008 at 7:21 AM, Bill Nottingham <notting redhat com> wrote:
>>> Gregory Hosler (ghosler redhat com) said:
>>>> not sure if this is the correct fedora mailing list or not to bring this up on...
>>>
>>> fedora-devel-list may be better, CC'ing it.
>>>
>>>> I came across a build error on X64, in F-11
>>>>
>>>> I have been seeing this exact bug report my other distso users that have been building my
>>>> package on other distro x64 platforms, and so far I do not know what the solution might be.
>>>>
>>>> When i do a libtool build on a library, I am seeing the following:
>>>>
>>>> /bin/sh ../libtool --tag=CC   --mode=link gcc  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
>>>> - -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
>>>> - -Wno-pointer-sign -funsigned-char -shared -fpic -fPIC  -o libgyachi.so gytreeview.o
>>>> gy_config.o gyachi_lib.o parsecfg.o theme_support.o sound_plugin.o plugins.o -lgtk-x11-2.0
>>>> - -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo
>>>> - -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0   -lltdl
>>>> - -lX11  -lpthread
>>>> libtool: link: gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
>>>> - -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wno-pointer-sign
>>>> - -funsigned-char -fpic -fPIC -o libgyachi.so gytreeview.o gy_config.o gyachi_lib.o
>>>> parsecfg.o theme_support.o sound_plugin.o plugins.o  -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
>>>> - -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype
>>>> - -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lltdl -lX11 -lpthread
>>>> /usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../lib64/crt1.o: In function `_start':
>>>> (.text+0x20): undefined reference to `main'
>>>> collect2: ld returned 1 exit status
>>>>
>>>> ld is not treating this as a shared library, rather it is treating this as a main program.
>>>
>>> The F-11 tree has libtool-2.2.6, instead of libtool-1.5 as in Fedora 10 and
>>> earlier. I suspect that's what's tripping you up.
>>
>> Is automake being used?
>
> Yes
>
>> How are you invoking libtool?
>
> in my autogen.sh script (which runs the automake tool set) i do:
>
>        libtoolize --copy --force --automake
>
> which generates a libtool script.
>
>> I would suspect the correct way to do this in automake is:
>>
>> wherever_LTLIBRARIES = libgyachi.la
>> libgyachi_la_LDFLAGS = -avoid-version
>
> hmm... My libtool script does not have any references to anything *_LTLIBRARIES
> so i'm kinda at a loss as to the above 2 statements, or how to make them happen

Not in the libtool script, in Makefile.am. I.e., how is libgyachi
being defined to be built by libtool. In most autotooled packages,
you'd do this in Makefile.am, and automake would expand it to
something usable:

lib_LTLIBRARIES = libfoo.la
libfoo_la_SOURCES = foo.c bar.c

That will make a libtool library installed to $(libdir). Since
libgyachi appears to be a module without an soversion (correct me if
I'm wrong), you can tell libtool to do that by adding "-avoid-version"
to the LDFLAGS.

--
Dan



From pmachata at redhat.com  Tue Nov 18 12:29:14 2008
From: pmachata at redhat.com (Petr Machata)
Date: Tue, 18 Nov 2008 13:29:14 +0100
Subject: tzdata in FC10 is older than the one in FC9
In-Reply-To: <1226856346.20645.4.camel@arekh.okg>
References: <20081116101700.123f2y19t3bio8oc@mail.rimini.com>	<648.1226855255@sss.pgh.pa.us>
	<1226856346.20645.4.camel@arekh.okg>
Message-ID: <4922B51A.7060404@redhat.com>

Nicolas Mailhot wrote:
> Le dimanche 16 novembre 2008 ? 12:07 -0500, Tom Lane a ?crit :
>> Davide Moretti <dave at rimini.com> writes:
>>> In fc9 we have tzdata-2008i while in fc10 there is tzdata-2008h...
>> Most likely it's queued for a zero-day update. 
> 
> It's not in Fedora 11 rawhide either.

I've done the devel build sometime back, when F-10 was already frozen 
and F-11 not yet forked (unless you asked explicitly I guess).  So devel 
build went into F-10, which I scheduled for update as soon as bodhi was 
capable of that.  I never did true rawhide build, but am doing it now.

PM



From rawhide at fedoraproject.org  Tue Nov 18 12:58:34 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Tue, 18 Nov 2008 12:58:34 +0000 (UTC)
Subject: rawhide report: 20081118 changes
Message-ID: <20081118125835.187CB1F8252@releng2.fedora.phx.redhat.com>

Compose started at Tue Nov 18 06:01:19 UTC 2008

Updated Packages:

Miro-1.2.7-2.fc10
-----------------
* Wed Nov 12 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 1.2.7-2
- Rebuild against newer gecko


anaconda-11.4.1.59-1
--------------------
* Mon Nov 17 17:00:00 2008 Chris Lumens <clumens at redhat.com> - 11.4.1.59-1
- Disable BETANAG.  It's release time! (clumens)
- 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)


azureus-3.0.4.2-18.fc10
-----------------------
* Wed Nov 12 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 3.0.4.2-18
- Rebuild against newer gecko


blam-1.8.5-4.fc10
-----------------
* Wed Nov 12 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 1.8.5-4
- Rebuild against newer gecko


devhelp-0.21-3.fc10
-------------------
* Wed Nov 12 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 0.21-3
- Rebuild against newer gecko


dosfstools-3.0.0-2.fc10
-----------------------
* Mon Nov 17 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 3.0.0-2
- apply vfat timing fix


epiphany-2.24.1-2.fc10
----------------------
* Wed Nov 12 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 2.24.1-2
- Rebuild against newer gecko


epiphany-extensions-2.24.0-2.fc10
---------------------------------
* Thu Nov 13 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 2.24.0-2
- Rebuild against newer gecko


evolution-rss-0.1.1-4.fc10
--------------------------
* Wed Nov 12 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 0.1.1-4
- Rebuild against newer gecko


fedora-release-notes-10.0.0-1
-----------------------------
* Sun Nov 16 17:00:00 2008 Paul W. Frields <stickster at gmail.com> - 10.0.0-1
- Updates for F10 GA release


firefox-3.0.4-1.fc10
--------------------
* Wed Nov 12 17:00:00 2008 Christopher Aillon <caillon at redhat.com> 3.0.4-1
- Update to 3.0.4


galeon-2.0.7-3.fc10
-------------------
* Wed Nov 12 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 2.0.7-3
- Rebuild against newer gecko


gecko-sharp2-0.13-2.fc10
------------------------
* Wed Nov 12 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 0.13-2
- Rebuild against newer gecko


gnome-python2-extras-2.19.1-24.fc10
-----------------------------------
* Wed Nov 12 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 2.19.1-24
- Rebuild against newer gecko


gnome-web-photo-0.3-12.fc10
---------------------------
* Wed Nov 12 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 0.3-12
- Rebuild against newer gecko


google-gadgets-0.10.1-5.fc10
----------------------------
* Wed Nov 12 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 0.10.1-5
- Rebuild against newer gecko


kazehakase-0.5.6-1.fc10.1
-------------------------
* Wed Nov 12 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 0.5.6-1.1
- Rebuild against newer gecko

* Fri Oct 31 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.5.6-1
- 0.5.6
- -UGTK_DISABLE_DEPRECATED hack removed (hack introduced in upstream)

* Wed Sep 24 18:00:00 2008 Christopher Aillon <caillon at redhat.com>
- Rebuild against newer gecko (F-9/8)


kernel-2.6.27.5-113.fc10
------------------------
* Mon Nov 17 17:00:00 2008 Dave Airlie <airlied at redhat.com> 2.6.27.5-113
- drm - intel rebase from upstream - radeon fix memory sizing and zeroing

* Fri Nov 14 17:00:00 2008 Dave Airlie <airlied at redhat.com> 2.6.27.5-112
- radeon - backout patch is over zealous in error handling

* Fri Nov 14 17:00:00 2008 Dave Airlie <airlied at redhat.com> 2.6.27.5-111
- radeon - fix low memory issues and locking oops causer


mozvoikko-0.9.5-4.fc10
----------------------
* Wed Nov 12 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 0.9.5-4
- Rebuild against newer gecko


mugshot-1.2.2-3.fc10
--------------------
* Wed Nov 12 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 1.2.2-3
- Rebuild against newer gecko


nautilus-share-0.7.2-13.fc10
----------------------------
* Wed Nov 12 17:00:00 2008 Muayyad Saleh Alsadi <alsadi at ojuba.org> - 0.7.2-13
- set icon to "folder-remote"
- don't use extensions-1.0 directory (fixes #447072)


pcmanx-gtk2-0.3.8-3.fc10
------------------------
* Wed Nov 12 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 0.3.8-3
- Rebuild against newer gecko


plymouth-0.6.0-0.2008.11.17.3.fc10
----------------------------------
* Mon Nov 17 17:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.11.17.3
- don't give error about missing default.so
- rework packaging of boot-duration to prevent .rpmnew droppings
  (bug 469752)

* Mon Nov 17 17:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.11.17.2
- Don't tell gdm to transition unless booting into runlevel 3
  (bug 471785)

* Mon Nov 17 17:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.11.17.1
- Crawl progress bar if boot is way off course (Charlie, bug 471089)

* Fri Nov 14 17:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.11.14.3
- Allow NULL to ply_image_free

* Fri Nov 14 17:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.11.14.2
- Don't loop forever when tty returns NUL byte (bug 471498)

* Fri Nov 14 17:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.11.14.1
- Generate solar background dynamically to reduce ondisk size, and
  look better at various resolutions (Charlie, bug 471227)


ruby-gnome2-0.18.0-2.fc10
-------------------------
* Wed Nov 12 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 0.18.0-2
- Rebuild against newer gecko


seamonkey-1.1.13-1.fc10
-----------------------
* Wed Nov 12 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 1.1.13-1
- Update to 1.1.13


solar-kde-theme-0.1.16-2.fc10
-----------------------------
* Thu Nov 13 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.1.16-2
- list 1920x1080, 1366x768 and 1280x720 (16:9/HDTV) as widescreen

* Mon Nov 10 17:00:00 2008 Than Ngo <than at redhat.com> 0.1.16-1
- uses hostname instead welcome-label
- fixes font issue


sugar-0.82.9-2.fc10
-------------------
* Mon Nov 17 17:00:00 2008 Simon Schampijer <simon at laptop.org> - 0.82.9-2
- NM07 support


sugar-base-0.82.2-2.fc10
------------------------
* Mon Nov 17 17:00:00 2008 Simon Schampijer <simon at schampijer.de> - 0.82.2-2
- add sugar dispatcher (needed by NM 0.7 support)


system-config-kickstart-2.7.20-1.fc10
-------------------------------------
* Mon Nov 17 17:00:00 2008 Chris Lumens <clumens at redhat.com> 2.7.20-1
- Don't make the open dialog tiny.
- Fix a traceback caused by methods moving out of GroupSelector.py in anaconda.
- Don't remove the byte-compiled python files from a scriptlet.


xorg-x11-server-1.5.3-5.fc10
----------------------------
* Mon Nov 17 17:00:00 2008 Dave Airlie <airlied at redhat.com> 1.5.3-5
- xserver-1.5.3-exa-fix-unneeded-copies.patch: fix logic error

* Mon Nov 17 17:00:00 2008 Dave Airlie <airlied at redhat.com> 1.5.3-4
- xserver-1.5.3-exa-fix-unneeded-copies.patch: fix some unneeded calls to drivers

* Thu Nov 13 17:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 1.5.3-3
- xserver-1.5.3-AEI-on-by-default.patch: ensure AEI on if there is no
  xorg.conf. (#471221)

* Wed Nov 12 17:00:00 2008 Dave Airlie <airlied at redhat.com> 1.5.3-2
- xserver-1.5.3-exa-fix-composite-rects.patch - backport (#470638)
- xserver-1.5.3-exa-fix-x-y-src-dst.patch - backport

* Wed Nov  5 17:00:00 2008 Adam Jackson <ajax at redhat.com> 1.5.3-1
- xserver 1.5.3


xulrunner-1.9.0.4-1.fc10
------------------------
* Wed Nov 12 17:00:00 2008 Christopher Aillon <caillon at redhat.com> 1.9.0.4-1
- Update to 1.9.0.4


yelp-2.24.0-3.fc10
------------------
* Wed Nov 12 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 2.24.0-3
- Rebuild against newer gecko


Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 32














From pmachata at redhat.com  Tue Nov 18 13:19:17 2008
From: pmachata at redhat.com (Petr Machata)
Date: Tue, 18 Nov 2008 14:19:17 +0100
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <20081117213116.GA25672@mokona.greysector.net>
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>
	<20081117213116.GA25672@mokona.greysector.net>
Message-ID: <4922C0D5.4070209@redhat.com>

Dominik 'Rathann' Mierzejewski wrote:
> And here's a proper (spec for) rpm package, not the crap that Adobe
> is distributing:
> http://rathann.fedorapeople.org/scratch/flash-plugin.spec

Smoke test passed: youtube works, sound plays, seems to be operative. 
Thanks for the package!

PM



From rakesh at fedoraproject.org  Tue Nov 18 13:22:14 2008
From: rakesh at fedoraproject.org (Rakesh Pandit)
Date: Tue, 18 Nov 2008 18:52:14 +0530
Subject: report: package reviews this week - 2008/11/10 to 2008/11/17
Message-ID: <b401d2530811180522o8b8789dy58947f26891177b5@mail.gmail.com>

Top three FAS account holders who have completed reviewing "Package
review" components on bugzilla this week are:
Jason Tibbitts, Brian Pepple, Mamoru Tasaka

Below is detailed report. It has names and number of reviews done by
that person. There where 38 reviews done this week.

Start Date: 2008-11-10 23:34:40.694816
End Date: 2008-11-17 23:34:40.694816

Jason Tibbitts - 7
Brian Pepple - 6
Mamoru Tasaka - 4
Orcan 'oget' Ogetbil - 3
Chris Weyl - 2
Parag AN(????) - 2
manuel wolfshant - 2
Charles R. Anderson - 1
David Nielsen - 1
Fabian Affolter - 1
Jussi Lehtola - 1
Kevin Fenzi - 1
Lucian Langa - 1
Michael Schwendt - 1
Nicolas Mailhot - 1
Peter Lemenkov - 1
Rex Dieter - 1
Simon Schampijer - 1
Till Maas - 1

-- 
Rakesh Pandit



From mark.bidewell at alumni.clemson.edu  Tue Nov 18 13:41:05 2008
From: mark.bidewell at alumni.clemson.edu (Mark Bidewell)
Date: Tue, 18 Nov 2008 08:41:05 -0500
Subject: F11 Proposal: Stabilization
In-Reply-To: <49229E4B.8030204@fedoraproject.org>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<20081117213742.GB5603@nostromo.devel.redhat.com>
	<4921E683.30407@redhat.com>
	<604aa7910811171354h26c8eb30r72280cc95ba9a976@mail.gmail.com>
	<1226960219.4098.20.camel@perihelion.bos.jonmasters.org>
	<49229E4B.8030204@fedoraproject.org>
Message-ID: <bfdeacfa0811180541j338f4c2ah6aaaa0403ba5e2d9@mail.gmail.com>

On Tue, Nov 18, 2008 at 5:51 AM, Rahul Sundaram
<sundaram at fedoraproject.org>wrote:

> Jon Masters wrote:
>
>> On Mon, 2008-11-17 at 12:54 -0900, Jeff Spaleta wrote:
>>
>>> On Mon, Nov 17, 2008 at 12:47 PM, Casey Dahlin <cdahlin at redhat.com>
>>> wrote:
>>>
>>>> Well, 'stable updates' wouldn't apply to F11 for quite a while now. :)
>>>>>
>>>> The proposal is more emotive than actionable so there isn't much to
>>> discuss really.
>>>
>>
>> I disagree. Various other communities (and distributions) have made a
>> point out of "stable" releases where the "big ticket" feature is
>> stabilization,
>>
>
> Can you point out such communities and distros and tell us what they have
> done?
>
> Rahul
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


Of the top of my head, CentOS and Debian come to mind.  Some might also put
Ubuntu LTS and OpenSUSE in that list as well.

Mark Bidewell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081118/21175d30/attachment.htm>

From wolfy at nobugconsulting.ro  Tue Nov 18 14:19:40 2008
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Tue, 18 Nov 2008 16:19:40 +0200
Subject: F11 Proposal: Stabilization
In-Reply-To: <bfdeacfa0811180541j338f4c2ah6aaaa0403ba5e2d9@mail.gmail.com>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>	<20081117213742.GB5603@nostromo.devel.redhat.com>	<4921E683.30407@redhat.com>	<604aa7910811171354h26c8eb30r72280cc95ba9a976@mail.gmail.com>	<1226960219.4098.20.camel@perihelion.bos.jonmasters.org>	<49229E4B.8030204@fedoraproject.org>
	<bfdeacfa0811180541j338f4c2ah6aaaa0403ba5e2d9@mail.gmail.com>
Message-ID: <4922CEFC.8050304@nobugconsulting.ro>

Mark Bidewell wrote:
>
>
> On Tue, Nov 18, 2008 at 5:51 AM, Rahul Sundaram 
> <sundaram at fedoraproject.org <mailto:sundaram at fedoraproject.org>> wrote:
>
>     Jon Masters wrote:
>
>         On Mon, 2008-11-17 at 12:54 -0900, Jeff Spaleta wrote:
>
>             On Mon, Nov 17, 2008 at 12:47 PM, Casey Dahlin
>             <cdahlin at redhat.com <mailto:cdahlin at redhat.com>> wrote:
>
>                     Well, 'stable updates' wouldn't apply to F11 for
>                     quite a while now. :)
>
>             The proposal is more emotive than actionable so there
>             isn't much to
>             discuss really.
>
>
>         I disagree. Various other communities (and distributions) have
>         made a
>         point out of "stable" releases where the "big ticket" feature is
>         stabilization,
>
>
>     Can you point out such communities and distros and tell us what
>     they have done?
>
>     Rahul
>
>
>     -- 
>     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
>
>
>
> Of the top of my head, CentOS and Debian come to mind.  Some might 
> also put Ubuntu LTS and OpenSUSE in that list as well.
I am sorry to say it, but you make a strong confusion between the 
targets of different distros.


>
> Mark Bidewell



From jeff at ocjtech.us  Tue Nov 18 14:48:01 2008
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Tue, 18 Nov 2008 08:48:01 -0600
Subject: Trac 0.11
Message-ID: <935ead450811180648m1549a1cbi858bc22c6c5d3d6f@mail.gmail.com>

Thanks to some spec updates from Ryan Lynch I've build Trac 0.11.2.1
for F11 _only_.  There are some significant changes in Trac 0.11 and I
wanted to get the kinks worked out before even thinking of updating
Trac for any versions earlier than F11.  Until rawhide is unfrozen you
can find the RPMS in koji:

http://koji.fedoraproject.org/koji/taskinfo?taskID=937926

I have not updated any of the various Trac plugins yet, those will
likely be busted.

-- 
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 james at fedoraproject.org  Tue Nov 18 14:59:09 2008
From: james at fedoraproject.org (James Antill)
Date: Tue, 18 Nov 2008 09:59:09 -0500
Subject: F11 Proposal: Stabilization
In-Reply-To: <49226383.3010800@leemhuis.info>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<20081117213742.GB5603@nostromo.devel.redhat.com>
	<4921E683.30407@redhat.com>
	<604aa7910811171354h26c8eb30r72280cc95ba9a976@mail.gmail.com>
	<1226960219.4098.20.camel@perihelion.bos.jonmasters.org>
	<49226383.3010800@leemhuis.info>
Message-ID: <1227020349.4355.116.camel@code.and.org>

On Tue, 2008-11-18 at 07:41 +0100, Thorsten Leemhuis wrote:
> On 17.11.2008 23:16, Jon Masters wrote:
>  >
> > Various other communities (and distributions) have made a
> > point out of "stable" releases where the "big ticket" feature is
> > stabilization, so I think it would be a win to consider that.
> 
> I disagree: It seems to me a lot of the current Fedora users like the 
> "latest bells and whistles" style (like you called it in the mail that 
> started this discussion) I for one really like the steady stream of 
> kernel-updates, as that greatly improves hardware support over time! On 
> OpenSuse or Ubuntu you are often forced to run the development branches 
> when you need newer driver (just like it was in the early Fedora days 
> and in the RHL days).

 Indeed, and someone else wants the latest transmission and someone else
the latest pidgin and someone else...
 So you either need 100x distributions, or the latest stuff of
everything.

> > I would personally much
> > prefer that stuff that used to work didn't break randomly, and that
> > stable Fedora updates wouldn't result in me wondering whether suspend,
> > graphics, SELinux, or some other feature that was working was going to
> > break today. This isn't actually a rant, more pointing out a necessity.
> 
> Agreed, but I tend to say we should work towards a solution where we can 
> ship the "latest bells and whistles" and nevertheless provide stability.
> 
> I for one think we need something like that:
> https://www.redhat.com/archives/fedora-advisory-board/2008-August/msg00025.html
> 
> The relevant part:
> 
> """
> I more and more think that we should consider to switch to a more 
> rolling release scheme with different usage levels. Roughly something 
> like the following maybe:
> 
> 
> Level 1 -- rawhide, similar to how it is today (a bit more stable and 
> less breakage would be nice, but that's in the works already)
> 
> Level 2pre -- things that got tested in rawhide, that are still young, 
> but known to work well in rawhide; similar to what updates-testing for 
> F9 is today;
> 
> Level 2 -- things that worked fine for some time in 2pre; similar to 
> what F9 is today
> 
> Level 3pre -- things that worked fine for some time in 2
> 
> Level 3 -- things that worked fine for some time in 2pre
> 
> 
> Level 3pre and 3 are like F8-updates-testing and F8, but with the 
> difference that everything has to be tested and shipped in level 2 (aka 
> F9) first.
> """

 Ok, the above _only_ works if you can convince all the packagers that
they should backport fixes ... or you end up with things broken in
"Level 2+" until a newer "fixed"? package manages to come up through the
levels.

 This "rolling relases" is roughly what we do with yum releases now, but
manually and so doesn't have the backport requirements problems. So if
we know that version 123 is pretty good but has a couple of annoying
edge case bugs ... we don't release into Fedora 8. Although even then
sometimes things get through.
 If someone thinks there is something magic that can be done to make
releases bug free, they should speak to someone involved in something
that was released into Fedora 9 and will be in RHEL-5.3. I know there
are a couple of packages that did that. It wasn't magic, but it sure
wasn't anything you can easily get people to do for Fedora (IMNSHO).


? May contain other bugs.

-- 
James Antill <james at fedoraproject.org>
Fedora



From dcbw at redhat.com  Tue Nov 18 15:33:11 2008
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 18 Nov 2008 10:33:11 -0500
Subject: Automatic WEP key type/lenght recognition?
In-Reply-To: <1226963683.27728.314.camel@macbook.infradead.org>
References: <64b14b300811170038k61282d70vdbe7d2daf3ba023c@mail.gmail.com>
	<1226935712.10028.10.camel@localhost.localdomain>
	<1226963683.27728.314.camel@macbook.infradead.org>
Message-ID: <1227022391.3938.5.camel@localhost.localdomain>

On Mon, 2008-11-17 at 23:14 +0000, David Woodhouse wrote:
> On Mon, 2008-11-17 at 10:28 -0500, Dan Williams wrote:
> > There's probably room to improve the NM applet UI and make it clear
> > what to enter where.
> 
> If you haven't done so already, you could at least remove steps #3 and
> #4 of the following process, which seems to be the one I follow _every_
> time...
> 
>  #1. Enter WEP key.
>  #2. Select key type.
>  #3. Swear profusely.
>  #4. Enter WEP key again, since it got wiped from where you entered it.

Yeah, a bug.

Dan




From rjones at redhat.com  Tue Nov 18 17:49:07 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 18 Nov 2008 17:49:07 +0000
Subject: ANNOUNCE: Smock (simpler mock) - a mock wrapper for chain building
Message-ID: <20081118174907.GA27568@amd.home.annexia.org>


'Smock' stands for 'simpler mock'.  It's a script that runs on top of
mock, allowing you to chain-build a series of RPMs from a single
command.

  smock.pl --arch=i386 --arch=x86_64 \
      --distro=fedora-9 --distro=fedora-10 \
      *.src.rpm

The above command would arrange the SRPMs into the correct order
according to their BuildRequires, then build each in the four separate
mock environments Fedora {9,10} {i386,x86_64}.  It makes the result of
each previous package build available to subsequent packages, and in
case of error it is fully restartable (it skips packages which have
already been built).

The script was written by Dan Berrange and extensively hacked on by
me.  This is how we've been building the MinGW & OCaml packages for
quite a while.

Available from:

  http://hg.et.redhat.com/misc/fedora-mingw--devel/
  (click 'manifest' then 'smock')

Please read the README file!

Example output:

  http://www.annexia.org/tmp/mingw/fedora-9/

Example wrapper script we use for MinGW:

  http://hg.et.redhat.com/misc/fedora-mingw--devel/?f=d3dc6fa7cddd;file=build-everything-in-mock.sh

Commands we use for OCaml:

  cd fedora
  for f in ocaml*; do (cd $f/devel && make srpm); done
  smock.pl --arch=i386 --arch=x86_64 --distro=fedora-rawhide \
    ocaml*/devel/*.src.rpm

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  Tue Nov 18 17:49:14 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 18 Nov 2008 17:49:14 +0000
Subject: Heads up: OCaml 3.11.0 rebuild for Fedora 11
Message-ID: <20081118174914.GA27575@amd.home.annexia.org>


Just a note that I'll be building OCaml 3.11.0+beta1 in Fedora 11
(future Rawhide).  This will break everything OCaml-related for a
little while, since it's known that some packages don't build with the
new OCaml compiler yet.

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 halfline at gmail.com  Tue Nov 18 18:02:00 2008
From: halfline at gmail.com (Ray Strode)
Date: Tue, 18 Nov 2008 13:02:00 -0500
Subject: plymouthd taking ~5s on machine
In-Reply-To: <16de708d0811172156w590af7b4hf70d9d7c95552599@mail.gmail.com>
References: <16de708d0811172156w590af7b4hf70d9d7c95552599@mail.gmail.com>
Message-ID: <45abe7d80811181002o7c2929cbrc27d1761ce788d12@mail.gmail.com>

Hi,

2008/11/18 Arthur Pemberton <pemboa at gmail.com>:
> Just doing some work on a laptop machine for a friend and thought to
> run bootchart on it. I was surprised to see that plymouthd seemed to
> be blocking for 5 seconds. I have attached the data and rendered svg
> in case anyone is interested in this data.
That's just the initrd doing it's thing before / is mounted.  It's not
plymouthd blocking boot up.  plymouthd is just running in the
background while that stuff is happening.

--Ray



From opensource at till.name  Tue Nov 18 18:02:57 2008
From: opensource at till.name (Till Maas)
Date: Tue, 18 Nov 2008 19:02:57 +0100
Subject: ANNOUNCE: Smock (simpler mock) - a mock wrapper for chain
	building
In-Reply-To: <20081118174907.GA27568@amd.home.annexia.org>
References: <20081118174907.GA27568@amd.home.annexia.org>
Message-ID: <200811181903.09563.opensource@till.name>

On Tue November 18 2008, Richard W.M. Jones wrote:
> 'Smock' stands for 'simpler mock'.  It's a script that runs on top of
> mock, allowing you to chain-build a series of RPMs from a single
> command.
>
>   smock.pl --arch=i386 --arch=x86_64 \
>       --distro=fedora-9 --distro=fedora-10 \
>       *.src.rpm
>
> The above command would arrange the SRPMs into the correct order
> according to their BuildRequires, then build each in the four separate
> mock environments Fedora {9,10} {i386,x86_64}.  It makes the result of
> each previous package build available to subsequent packages, and in
> case of error it is fully restartable (it skips packages which have
> already been built).

Thanks a lot, this looks very helpful. To make it even more simplier, you can 
also use "file:///" urls in the mock config file for repositories. Then do 
not need a webserver. Another issue I noticed is, that there is no license 
information.

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/20081118/c2d645b1/attachment.sig>

From pemboa at gmail.com  Tue Nov 18 18:11:17 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Tue, 18 Nov 2008 12:11:17 -0600
Subject: plymouthd taking ~5s on machine
In-Reply-To: <45abe7d80811181002o7c2929cbrc27d1761ce788d12@mail.gmail.com>
References: <16de708d0811172156w590af7b4hf70d9d7c95552599@mail.gmail.com>
	<45abe7d80811181002o7c2929cbrc27d1761ce788d12@mail.gmail.com>
Message-ID: <16de708d0811181011h39b51c5bub9feac940403595c@mail.gmail.com>

On Tue, Nov 18, 2008 at 12:02 PM, Ray Strode <halfline at gmail.com> wrote:
> Hi,
>
> 2008/11/18 Arthur Pemberton <pemboa at gmail.com>:
>> Just doing some work on a laptop machine for a friend and thought to
>> run bootchart on it. I was surprised to see that plymouthd seemed to
>> be blocking for 5 seconds. I have attached the data and rendered svg
>> in case anyone is interested in this data.
> That's just the initrd doing it's thing before / is mounted.  It's not
> plymouthd blocking boot up.  plymouthd is just running in the
> background while that stuff is happening.


Thanks for the explanation.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From ghosler at redhat.com  Tue Nov 18 18:20:11 2008
From: ghosler at redhat.com (Gregory Hosler)
Date: Wed, 19 Nov 2008 02:20:11 +0800
Subject: f11 build error
In-Reply-To: <91705d080811180407k3199841bm111a61c0a46651da@mail.gmail.com>
References: <4922AC76.8080904@redhat.com>
	<91705d080811180407k3199841bm111a61c0a46651da@mail.gmail.com>
Message-ID: <4923075B.70101@redhat.com>

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

Dan Nicholson wrote:
> 2008/11/18 Gregory Hosler <ghosler at redhat.com>:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>> On Mon, Nov 17, 2008 at 7:21 AM, Bill Nottingham <notting redhat com> wrote:
>>>> Gregory Hosler (ghosler redhat com) said:
>>>>> not sure if this is the correct fedora mailing list or not to bring this up on...
>>>> fedora-devel-list may be better, CC'ing it.
>>>>
>>>>> I came across a build error on X64, in F-11
>>>>>
>>>>> I have been seeing this exact bug report my other distso users that have been building my
>>>>> package on other distro x64 platforms, and so far I do not know what the solution might be.
>>>>>
>>>>> When i do a libtool build on a library, I am seeing the following:
>>>>>
>>>>> /bin/sh ../libtool --tag=CC   --mode=link gcc  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
>>>>> - -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
>>>>> - -Wno-pointer-sign -funsigned-char -shared -fpic -fPIC  -o libgyachi.so gytreeview.o
>>>>> gy_config.o gyachi_lib.o parsecfg.o theme_support.o sound_plugin.o plugins.o -lgtk-x11-2.0
>>>>> - -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo
>>>>> - -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0   -lltdl
>>>>> - -lX11  -lpthread
>>>>> libtool: link: gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
>>>>> - -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wno-pointer-sign
>>>>> - -funsigned-char -fpic -fPIC -o libgyachi.so gytreeview.o gy_config.o gyachi_lib.o
>>>>> parsecfg.o theme_support.o sound_plugin.o plugins.o  -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
>>>>> - -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype
>>>>> - -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lltdl -lX11 -lpthread
>>>>> /usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../lib64/crt1.o: In function `_start':
>>>>> (.text+0x20): undefined reference to `main'
>>>>> collect2: ld returned 1 exit status
>>>>>
>>>>> ld is not treating this as a shared library, rather it is treating this as a main program.
>>>> The F-11 tree has libtool-2.2.6, instead of libtool-1.5 as in Fedora 10 and
>>>> earlier. I suspect that's what's tripping you up.
>>> Is automake being used?
>> Yes
>>
>>> How are you invoking libtool?
>> in my autogen.sh script (which runs the automake tool set) i do:
>>
>>        libtoolize --copy --force --automake
>>
>> which generates a libtool script.
>>
>>> I would suspect the correct way to do this in automake is:
>>>
>>> wherever_LTLIBRARIES = libgyachi.la
>>> libgyachi_la_LDFLAGS = -avoid-version
>> hmm... My libtool script does not have any references to anything *_LTLIBRARIES
>> so i'm kinda at a loss as to the above 2 statements, or how to make them happen
> 
> Not in the libtool script, in Makefile.am.

ah.

> I.e., how is libgyachi
> being defined to be built by libtool. In most autotooled packages,
> you'd do this in Makefile.am, and automake would expand it to
> something usable:
> 
> lib_LTLIBRARIES = libfoo.la
> libfoo_la_SOURCES = foo.c bar.c
> 
> That will make a libtool library installed to $(libdir). Since
> libgyachi appears to be a module without an soversion (correct me if
> I'm wrong), you can tell libtool to do that by adding "-avoid-version"
> to the LDFLAGS.

libgyachi is defined in the Makefile.am (attached) as follows:

gyachilib_PROGRAMS = libgyachi.so

gyachilibdir = @libdir@

libgyachi_so_SOURCES =  gytreeview.c gytreeview.h \
	.
	.
	.

and ...

now that you mention it, I think I understand what's happening. I was using a _PROGRAMS as
opposed to a _LTLIBRARIES.

I'm mostly all set now.

Remind me again, what is the purpose of the ".la" file. If my package's .so file is not
intended to be linked against, then i believe that there is no point to distribute the
".la" file, correct? (la is "link archive" I think).


> --
> Dan
> 


- --
+---------------------------------------------------------------------+

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.7 (GNU/Linux)

iD8DBQFJIwdZ404fl/0CV/QRAuYsAKDF96oZG97WFLMpPRyxkIzYBislbACePx3c
Ldx49V5GUPOq/Jd8hhTyu6E=
=9i6d
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Makefile.am
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081119/087ed0ff/attachment.ksh>

From jkeating at redhat.com  Tue Nov 18 18:21:11 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 18 Nov 2008 10:21:11 -0800
Subject: tzdata in FC10 is older than the one in FC9
In-Reply-To: <1226856346.20645.4.camel@arekh.okg>
References: <20081116101700.123f2y19t3bio8oc@mail.rimini.com>
	<648.1226855255@sss.pgh.pa.us>  <1226856346.20645.4.camel@arekh.okg>
Message-ID: <1227032471.28543.3.camel@luminos.localdomain>

On Sun, 2008-11-16 at 18:25 +0100, Nicolas Mailhot wrote:
> It's not in Fedora 11 rawhide either.
> 
> Most likely the tzdata maintainer did not update rawhide first, with the
> usual "updates for Fedora X are newer than stuff in Fedora X+1) effects.

Even more likely was that the build /was/ done on devel first, and devel
was F-10.  But we were frozen and the build didn't automatically go into
rawhide.  Once the update goes out for F-10, it'll be inherited into F11
(rawhide).

In the future, the window where we are frozen but not branched will
either be extremely small or non-existent.  The improvements we've made
to the speed of the branching make it a far less costly task and more
suitable to do during the crunch time that is just before or just after
the final freeze.

-- 
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/20081118/34e63452/attachment.sig>

From rjones at redhat.com  Tue Nov 18 18:17:05 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 18 Nov 2008 18:17:05 +0000
Subject: ANNOUNCE: Smock (simpler mock) - a mock wrapper for chain
	building
In-Reply-To: <200811181903.09563.opensource@till.name>
References: <20081118174907.GA27568@amd.home.annexia.org>
	<200811181903.09563.opensource@till.name>
Message-ID: <20081118181705.GA27734@amd.home.annexia.org>

On Tue, Nov 18, 2008 at 07:02:57PM +0100, Till Maas wrote:
> Thanks a lot, this looks very helpful. To make it even more
> simplier, you can also use "file:///" urls in the mock config file
> for repositories.  Then do not need a webserver.

Does this work?  I'll take your word for it -- it would definitely be
simpler if we didn't need to run a web server :-)

> Another issue I noticed is, that there is no license information.

Ah, a simple oversight.  I'll check with Dan and drop the license info
into that directory.  I'm sure it'll be GPLv2+.

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 jkeating at redhat.com  Tue Nov 18 18:23:00 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 18 Nov 2008 10:23:00 -0800
Subject: F-10 repo ? for livecd-creator
In-Reply-To: <50baabb30811160318h31784cf1m4c7a41ddbe132ed7@mail.gmail.com>
References: <50baabb30811160318h31784cf1m4c7a41ddbe132ed7@mail.gmail.com>
Message-ID: <1227032580.28543.4.camel@luminos.localdomain>

On Sun, 2008-11-16 at 12:18 +0100, Chitlesh GOORAH wrote:
> 
> Is there any repo specific to packages which are tagged with
> F-10-final ?
> 
> I wish to create livedvd with those packages (the ones tagged with
> F10-final)

I'm not sure I understand this question.  All the packages that are
tagged for f10-final are the packages you see show up in rawhide each
night.

-- 
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/20081118/cff0fea1/attachment.sig>

From skvidal at fedoraproject.org  Tue Nov 18 18:23:55 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Tue, 18 Nov 2008 13:23:55 -0500 (EST)
Subject: ANNOUNCE: Smock (simpler mock) - a mock wrapper for chain
 building
In-Reply-To: <20081118181705.GA27734@amd.home.annexia.org>
References: <20081118174907.GA27568@amd.home.annexia.org>
	<200811181903.09563.opensource@till.name>
	<20081118181705.GA27734@amd.home.annexia.org>
Message-ID: <alpine.LFD.2.00.0811181323230.1236@localhost.localdomain>



On Tue, 18 Nov 2008, Richard W.M. Jones wrote:

> On Tue, Nov 18, 2008 at 07:02:57PM +0100, Till Maas wrote:
>> Thanks a lot, this looks very helpful. To make it even more
>> simplier, you can also use "file:///" urls in the mock config file
>> for repositories.  Then do not need a webserver.
>
> Does this work?  I'll take your word for it -- it would definitely be
> simpler if we didn't need to run a web server :-)
>
>> Another issue I noticed is, that there is no license information.
>
> Ah, a simple oversight.  I'll check with Dan and drop the license info
> into that directory.  I'm sure it'll be GPLv2+.
>

why not make this work as a function of mock instead of a wrapper around 
it?

-sv



From rjones at redhat.com  Tue Nov 18 18:22:04 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 18 Nov 2008 18:22:04 +0000
Subject: ANNOUNCE: Smock (simpler mock) - a mock wrapper for chain
	building
In-Reply-To: <alpine.LFD.2.00.0811181323230.1236@localhost.localdomain>
References: <20081118174907.GA27568@amd.home.annexia.org>
	<200811181903.09563.opensource@till.name>
	<20081118181705.GA27734@amd.home.annexia.org>
	<alpine.LFD.2.00.0811181323230.1236@localhost.localdomain>
Message-ID: <20081118182204.GB27734@amd.home.annexia.org>

On Tue, Nov 18, 2008 at 01:23:55PM -0500, Seth Vidal wrote:
> why not make this work as a function of mock instead of a wrapper around  
> it?

Yes, we should do 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 berrange at redhat.com  Tue Nov 18 18:29:09 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Tue, 18 Nov 2008 18:29:09 +0000
Subject: ANNOUNCE: Smock (simpler mock) - a mock wrapper for chain
	building
In-Reply-To: <20081118181705.GA27734@amd.home.annexia.org>
References: <20081118174907.GA27568@amd.home.annexia.org>
	<200811181903.09563.opensource@till.name>
	<20081118181705.GA27734@amd.home.annexia.org>
Message-ID: <20081118182909.GE22772@redhat.com>

On Tue, Nov 18, 2008 at 06:17:05PM +0000, Richard W.M. Jones wrote:
> On Tue, Nov 18, 2008 at 07:02:57PM +0100, Till Maas wrote:
> > Thanks a lot, this looks very helpful. To make it even more
> > simplier, you can also use "file:///" urls in the mock config file
> > for repositories.  Then do not need a webserver.
> 
> Does this work?  I'll take your word for it -- it would definitely be
> simpler if we didn't need to run a web server :-)

It didn't work when I tried it originally. Perhaps its needs a newer
mock than I had originally, or maybe I just did it wrong. Still worth
trying again if it is expected to actually work...

> > Another issue I noticed is, that there is no license information.
> 
> Ah, a simple oversight.  I'll check with Dan and drop the license info
> into that directory.  I'm sure it'll be GPLv2+.

Yes, I was just about to say  GPLv2+

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 opensource at till.name  Tue Nov 18 18:30:25 2008
From: opensource at till.name (Till Maas)
Date: Tue, 18 Nov 2008 19:30:25 +0100
Subject: ANNOUNCE: Smock (simpler mock) - a mock wrapper for chain
	building
In-Reply-To: <20081118181705.GA27734@amd.home.annexia.org>
References: <20081118174907.GA27568@amd.home.annexia.org>
	<200811181903.09563.opensource@till.name>
	<20081118181705.GA27734@amd.home.annexia.org>
Message-ID: <200811181930.36885.opensource@till.name>

On Tue November 18 2008, Richard W.M. Jones wrote:
> On Tue, Nov 18, 2008 at 07:02:57PM +0100, Till Maas wrote:
> > Thanks a lot, this looks very helpful. To make it even more
> > simplier, you can also use "file:///" urls in the mock config file
> > for repositories.  Then do not need a webserver.
>
> Does this work?  I'll take your word for it -- it would definitely be
> simpler if we didn't need to run a web server :-)

I already use these for a while, but don't forget to use enough slashes, two 
for the protocol and one for the root of the filesystem. :-)

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/20081118/b8bb65f3/attachment.sig>

From bnocera at redhat.com  Tue Nov 18 18:44:56 2008
From: bnocera at redhat.com (Bastien Nocera)
Date: Tue, 18 Nov 2008 18:44:56 +0000
Subject: Heads up: libfprint bumped in rawhide
Message-ID: <1227033896.3094.1758.camel@cookie.hadess.net>

Heya,

I updated libfprint in rawhide to 0.1.0-pre1, so fprintd can be built.
pam_fprint and fprint_demo will probably need updating from the current
git.

Cheers

PS: It would be nice if you used your real name in the spec file
changelogs.



From cdahlin at redhat.com  Tue Nov 18 18:53:37 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Tue, 18 Nov 2008 13:53:37 -0500
Subject: Proposal - "Slow updates" repo
Message-ID: <49230F31.4030409@redhat.com>

There's been a lot of talk about a stable release lately. Most agree 
that its not what Fedora does best and not something that would be 
natural for us to do. I have a sort of middle-ground proposal that might 
be easy enough to implement that we could try it out.

Currently, when a packager has an update, he runs "make update," and 
bodhi goes and grabs the package out of koji and places it in the next 
mash of the updates-testing repo (Luke, please shout when I start 
getting this wrong). Then, bold subscribers to updates-testing install 
it, check it out, and if two people report in that it didn't eat their 
brane, it goes into the regular updates repo. That slim sanity check 
prevents a whole helluva lot of breakage, but isn't a very broad testing 
of the package.

What I propose is having another repo called updates-slow. Like updates 
testing this repo ships with Fedora but is disabled and hidden by 
default. Interested parties would have to manually enable it, and 
disable the regular updates repo. updates-slow would relate to updates 
in a similar way that updates relates to updates-testing: packages would 
go into it after people getting the general Fedora updates seem to be 
ok. The criteria here would have to be much harder than the two karma 
points it takes to move out of testing, I would suggest the people 
interested in this feature form a group that decides what the entry 
policy should be.

The advantage is that this is fairly cheap to set up. Bodhi would need 
some level of changes (Luke, what do you think?) but there's no 
branching. We're basically just taking the ability which already exists 
in yum to selectively take updates and providing a system to 
collaboratively exploit this mechanism.

Not branching, however, also creates a disadvantage: with no ability to 
create new packages, the slow repo can't take newer fixes without taking 
an entire update. The slow repo must consume updates from Fedora in 
whole packages; they don't have patch-level control over incoming 
changes. Also, the slow repo has to synchronize at release time; you 
can't have a late-F9-with-bits-of-F10 offering (hopefully though the 
base set is the peak of mainline Fedora's QA).

If the people interested in a stability feature are willing to help 
govern and maintain this repo, and help with the bug load (we can't just 
dump bugs against backdated versions directly on the maintainers), then 
it could go a long way to meeting their needs.

Thoughts?

--CJD



From silfreed at silfreed.net  Tue Nov 18 18:57:22 2008
From: silfreed at silfreed.net (Douglas E. Warner)
Date: Tue, 18 Nov 2008 13:57:22 -0500
Subject: Proposal - "Slow updates" repo
In-Reply-To: <49230F31.4030409@redhat.com>
References: <49230F31.4030409@redhat.com>
Message-ID: <49231012.8090109@silfreed.net>

Casey Dahlin wrote:
> There's been a lot of talk about a stable release lately. Most agree 
> that its not what Fedora does best and not something that would be 
> natural for us to do. I have a sort of middle-ground proposal that might 
> be easy enough to implement that we could try it out.
> 
> Currently, when a packager has an update, he runs "make update," and 
> bodhi goes and grabs the package out of koji and places it in the next 
> mash of the updates-testing repo (Luke, please shout when I start 
> getting this wrong). Then, bold subscribers to updates-testing install 
> it, check it out, and if two people report in that it didn't eat their 
> brane, it goes into the regular updates repo. That slim sanity check 
> prevents a whole helluva lot of breakage, but isn't a very broad testing 
> of the package.
> 
> What I propose is having another repo called updates-slow. Like updates 
> testing this repo ships with Fedora but is disabled and hidden by 
> default. Interested parties would have to manually enable it, and 
> disable the regular updates repo. updates-slow would relate to updates 
> in a similar way that updates relates to updates-testing: packages would 
> go into it after people getting the general Fedora updates seem to be 
> ok. The criteria here would have to be much harder than the two karma 
> points it takes to move out of testing, I would suggest the people 
> interested in this feature form a group that decides what the entry 
> policy should be.
> 
> The advantage is that this is fairly cheap to set up. Bodhi would need 
> some level of changes (Luke, what do you think?) but there's no 
> branching. We're basically just taking the ability which already exists 
> in yum to selectively take updates and providing a system to 
> collaboratively exploit this mechanism.
> 
> Not branching, however, also creates a disadvantage: with no ability to 
> create new packages, the slow repo can't take newer fixes without taking 
> an entire update. The slow repo must consume updates from Fedora in 
> whole packages; they don't have patch-level control over incoming 
> changes. Also, the slow repo has to synchronize at release time; you 
> can't have a late-F9-with-bits-of-F10 offering (hopefully though the 
> base set is the peak of mainline Fedora's QA).
> 
> If the people interested in a stability feature are willing to help 
> govern and maintain this repo, and help with the bug load (we can't just 
> dump bugs against backdated versions directly on the maintainers), then 
> it could go a long way to meeting their needs.
> 
> Thoughts?

This almost runs into EPEL's agenda, and on the flip side there are people 
that would like to see EPEL's updates come in a little more frequently. 
Perhaps this 3-repo structure would work well for both groups ("testing", 
"normal", "stable").

-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/20081118/0ec78c4d/attachment.sig>

From Jochen at herr-schmitt.de  Tue Nov 18 18:58:21 2008
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Tue, 18 Nov 2008 19:58:21 +0100
Subject: Proposal - "Slow updates" repo
In-Reply-To: <49230F31.4030409@redhat.com>
References: <49230F31.4030409@redhat.com>
Message-ID: <4923104D.5080604@herr-schmitt.de>

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

Casey Dahlin schrieb:
> There's been a lot of talk about a stable release lately. Most agree
> that its not what Fedora does best and not something that would be
> natural for us to do. I have a sort of middle-ground proposal that
> might be easy enough to implement that we could try it out.
I see the following issue:

If a maintainer publish a security update, which depends of one of the
package which are in the 'slow updates' repository, how do you want to
handle this case?

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkjECgACgkQT2AHK6txfgylDwCgugxmoct+pW6KQA002R2Hpt2q
Y/sAoMlMYSAreaaw4X6NLtTJXIDc2Woj
=AdjS
-----END PGP SIGNATURE-----



From cdahlin at redhat.com  Tue Nov 18 19:02:26 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Tue, 18 Nov 2008 14:02:26 -0500
Subject: Proposal - "Slow updates" repo
In-Reply-To: <4923104D.5080604@herr-schmitt.de>
References: <49230F31.4030409@redhat.com> <4923104D.5080604@herr-schmitt.de>
Message-ID: <49231142.9010804@redhat.com>

Jochen Schmitt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Casey Dahlin schrieb:
>   
>> There's been a lot of talk about a stable release lately. Most agree
>> that its not what Fedora does best and not something that would be
>> natural for us to do. I have a sort of middle-ground proposal that
>> might be easy enough to implement that we could try it out.
>>     
> I see the following issue:
>
> If a maintainer publish a security update, which depends of one of the
> package which are in the 'slow updates' repository, how do you want to
> handle this case?
>
>   

This is the one drawback to this strategy. Here a human judgement call 
would have to be made: Take the package and all its deps or run the 
risk. The right answer would depend on the case, and on what the stable 
group decides their use case is best served by.

--CJD

> Best Regards:
>
> Jochen Schmitt
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkkjECgACgkQT2AHK6txfgylDwCgugxmoct+pW6KQA002R2Hpt2q
> Y/sAoMlMYSAreaaw4X6NLtTJXIDc2Woj
> =AdjS
> -----END PGP SIGNATURE-----
>
>   



From jspaleta at gmail.com  Tue Nov 18 19:06:59 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 18 Nov 2008 10:06:59 -0900
Subject: Proposal - "Slow updates" repo
In-Reply-To: <49231142.9010804@redhat.com>
References: <49230F31.4030409@redhat.com> <4923104D.5080604@herr-schmitt.de>
	<49231142.9010804@redhat.com>
Message-ID: <604aa7910811181106n3b30d9b5nbdef29ad334bda92@mail.gmail.com>

On Tue, Nov 18, 2008 at 10:02 AM, Casey Dahlin <cdahlin at redhat.com> wrote:
> This is the one drawback to this strategy. Here a human judgement call would
> have to be made: Take the package and all its deps or run the risk. The
> right answer would depend on the case, and on what the stable group decides
> their use case is best served by.

Security updates break the model for testing to. This is a known problem space.

If you take your idea...but also make it so client side users can
specifically know what is tagged as security and what is
not...regardless of repo "speed" then you probably have something
robust enough for everyone.

Give client side the option to pull ALL security updates...from any
repo "speed." That way the "slow" update repo doesn't have to be
burdened with dealing with security updates as part of their mission
as a special case.

-jef



From cdahlin at redhat.com  Tue Nov 18 19:11:04 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Tue, 18 Nov 2008 14:11:04 -0500
Subject: Proposal - "Slow updates" repo
In-Reply-To: <604aa7910811181106n3b30d9b5nbdef29ad334bda92@mail.gmail.com>
References: <49230F31.4030409@redhat.com>
	<4923104D.5080604@herr-schmitt.de>	<49231142.9010804@redhat.com>
	<604aa7910811181106n3b30d9b5nbdef29ad334bda92@mail.gmail.com>
Message-ID: <49231348.2060700@redhat.com>

Jeff Spaleta wrote:
> On Tue, Nov 18, 2008 at 10:02 AM, Casey Dahlin <cdahlin at redhat.com> wrote:
>   
>> This is the one drawback to this strategy. Here a human judgement call would
>> have to be made: Take the package and all its deps or run the risk. The
>> right answer would depend on the case, and on what the stable group decides
>> their use case is best served by.
>>     
>
> Security updates break the model for testing to. This is a known problem space.
>
> If you take your idea...but also make it so client side users can
> specifically know what is tagged as security and what is
> not...regardless of repo "speed" then you probably have something
> robust enough for everyone.
>
> Give client side the option to pull ALL security updates...from any
> repo "speed." That way the "slow" update repo doesn't have to be
> burdened with dealing with security updates as part of their mission
> as a special case.
>
> -jef
>
>   
Not a bad idea.

--CJD



From pertusus at free.fr  Tue Nov 18 19:16:43 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 18 Nov 2008 20:16:43 +0100
Subject: BugZappers/HouseKeeping is a policy and seems incomplete
In-Reply-To: <da159fda0811161624s272c974flb362062f75f18d62@mail.gmail.com>
References: <20081116160839.GC2933@free.fr>
	<da159fda0811161621y4847991bn8a87c1807d0fec29@mail.gmail.com>
	<da159fda0811161624s272c974flb362062f75f18d62@mail.gmail.com>
Message-ID: <20081118191643.GA2610@free.fr>

On Sun, Nov 16, 2008 at 07:24:30PM -0500, Jon Stanley wrote:
> On Sun, Nov 16, 2008 at 7:21 PM, Jon Stanley <jonstanley at gmail.com> wrote:
> 
> > And I'm not sure about linking it from the policy page, since it's not
> > a policy that FPC mandated. But I'll leave that to the FPC members
> > (who I think control that page).
> 
> Sorry, it's already linked from there:
> 
> https://fedoraproject.org/wiki/PackageMaintainers/Policy/EOL

I've just linked it, indeed. But it is a policy as such, in my opinion.

--
Pat



From skvidal at fedoraproject.org  Tue Nov 18 19:20:57 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Tue, 18 Nov 2008 14:20:57 -0500 (EST)
Subject: Proposal - "Slow updates" repo
In-Reply-To: <49231348.2060700@redhat.com>
References: <49230F31.4030409@redhat.com> <4923104D.5080604@herr-schmitt.de>
	<49231142.9010804@redhat.com>
	<604aa7910811181106n3b30d9b5nbdef29ad334bda92@mail.gmail.com>
	<49231348.2060700@redhat.com>
Message-ID: <alpine.LFD.2.00.0811181413520.1236@localhost.localdomain>



On Tue, 18 Nov 2008, Casey Dahlin wrote:

> Jeff Spaleta wrote:
>> On Tue, Nov 18, 2008 at 10:02 AM, Casey Dahlin <cdahlin at redhat.com> wrote:
>> 
>>> This is the one drawback to this strategy. Here a human judgement call 
>>> would
>>> have to be made: Take the package and all its deps or run the risk. The
>>> right answer would depend on the case, and on what the stable group 
>>> decides
>>> their use case is best served by.
>>> 
>> 
>> Security updates break the model for testing to. This is a known problem 
>> space.
>> 
>> If you take your idea...but also make it so client side users can
>> specifically know what is tagged as security and what is
>> not...regardless of repo "speed" then you probably have something
>> robust enough for everyone.
>> 
>> Give client side the option to pull ALL security updates...from any
>> repo "speed." That way the "slow" update repo doesn't have to be
>> burdened with dealing with security updates as part of their mission
>> as a special case.
>> 
>> -jef
>>
>> 
> Not a bad idea.

you mean like the already existing yum security plugin and the update info 
that bodhi generates?

-sv



From ndbecker2 at gmail.com  Tue Nov 18 19:21:29 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Tue, 18 Nov 2008 14:21:29 -0500
Subject: Adobe Releases 64bit Flash Plugin for Linux
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>
	<20081117213116.GA25672@mokona.greysector.net>
	<4922C0D5.4070209@redhat.com>
Message-ID: <gfv4jp$abq$1@ger.gmane.org>

Petr Machata wrote:

> Dominik 'Rathann' Mierzejewski wrote:
>> And here's a proper (spec for) rpm package, not the crap that Adobe
>> is distributing:
>> http://rathann.fedorapeople.org/scratch/flash-plugin.spec
> 
> Smoke test passed: youtube works, sound plays, seems to be operative.
> Thanks for the package!
> 
> PM
> 

Should nspluginwrapper be banned from wrapping this?  If so, should this be included in flash-plugin.spec?



From joshuacov at googlemail.com  Tue Nov 18 19:27:32 2008
From: joshuacov at googlemail.com (Joshua C.)
Date: Tue, 18 Nov 2008 20:27:32 +0100
Subject: F11 Proposal: Stabilization
In-Reply-To: <1227020349.4355.116.camel@code.and.org>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<20081117213742.GB5603@nostromo.devel.redhat.com>
	<4921E683.30407@redhat.com>
	<604aa7910811171354h26c8eb30r72280cc95ba9a976@mail.gmail.com>
	<1226960219.4098.20.camel@perihelion.bos.jonmasters.org>
	<49226383.3010800@leemhuis.info>
	<1227020349.4355.116.camel@code.and.org>
Message-ID: <5f6f8c5f0811181127u30953ae5ybd1195072df313d3@mail.gmail.com>

2008/11/18 James Antill <james at fedoraproject.org>:
> On Tue, 2008-11-18 at 07:41 +0100, Thorsten Leemhuis wrote:
>> On 17.11.2008 23:16, Jon Masters wrote:
>>  >
>> > Various other communities (and distributions) have made a
>> > point out of "stable" releases where the "big ticket" feature is
>> > stabilization, so I think it would be a win to consider that.
>>
>> I disagree: It seems to me a lot of the current Fedora users like the
>> "latest bells and whistles" style (like you called it in the mail that
>> started this discussion) I for one really like the steady stream of
>> kernel-updates, as that greatly improves hardware support over time! On
>> OpenSuse or Ubuntu you are often forced to run the development branches
>> when you need newer driver (just like it was in the early Fedora days
>> and in the RHL days).
>
>  Indeed, and someone else wants the latest transmission and someone else
> the latest pidgin and someone else...
>  So you either need 100x distributions, or the latest stuff of
> everything.
>
>> > I would personally much
>> > prefer that stuff that used to work didn't break randomly, and that
>> > stable Fedora updates wouldn't result in me wondering whether suspend,
>> > graphics, SELinux, or some other feature that was working was going to
>> > break today. This isn't actually a rant, more pointing out a necessity.
>>
>> Agreed, but I tend to say we should work towards a solution where we can
>> ship the "latest bells and whistles" and nevertheless provide stability.
>>
>> I for one think we need something like that:
>> https://www.redhat.com/archives/fedora-advisory-board/2008-August/msg00025.html
>>
>> The relevant part:
>>
>> """
>> I more and more think that we should consider to switch to a more
>> rolling release scheme with different usage levels. Roughly something
>> like the following maybe:
>>
>>
>> Level 1 -- rawhide, similar to how it is today (a bit more stable and
>> less breakage would be nice, but that's in the works already)
>>
>> Level 2pre -- things that got tested in rawhide, that are still young,
>> but known to work well in rawhide; similar to what updates-testing for
>> F9 is today;
>>
>> Level 2 -- things that worked fine for some time in 2pre; similar to
>> what F9 is today
>>
>> Level 3pre -- things that worked fine for some time in 2
>>
>> Level 3 -- things that worked fine for some time in 2pre
>>
>>
>> Level 3pre and 3 are like F8-updates-testing and F8, but with the
>> difference that everything has to be tested and shipped in level 2 (aka
>> F9) first.
>> """
>
>  Ok, the above _only_ works if you can convince all the packagers that
> they should backport fixes ... or you end up with things broken in
> "Level 2+" until a newer "fixed"? package manages to come up through the
> levels.
>
>  This "rolling relases" is roughly what we do with yum releases now, but
> manually and so doesn't have the backport requirements problems. So if
> we know that version 123 is pretty good but has a couple of annoying
> edge case bugs ... we don't release into Fedora 8. Although even then
> sometimes things get through.
>  If someone thinks there is something magic that can be done to make
> releases bug free, they should speak to someone involved in something
> that was released into Fedora 9 and will be in RHEL-5.3. I know there
> are a couple of packages that did that. It wasn't magic, but it sure
> wasn't anything you can easily get people to do for Fedora (IMNSHO).
>
>
> ? May contain other bugs.
>
> --
> James Antill <james at fedoraproject.org>
> Fedora
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
maybe these 2 threads should be merged:
1. F11 Proposal: Stabilization
2. Proposal - "Slow updates" repo



From jspaleta at gmail.com  Tue Nov 18 19:29:55 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 18 Nov 2008 10:29:55 -0900
Subject: Proposal - "Slow updates" repo
In-Reply-To: <49231348.2060700@redhat.com>
References: <49230F31.4030409@redhat.com> <4923104D.5080604@herr-schmitt.de>
	<49231142.9010804@redhat.com>
	<604aa7910811181106n3b30d9b5nbdef29ad334bda92@mail.gmail.com>
	<49231348.2060700@redhat.com>
Message-ID: <604aa7910811181129m1979beefjd60917b5721d3778@mail.gmail.com>

On Tue, Nov 18, 2008 at 10:11 AM, Casey Dahlin <cdahlin at redhat.com> wrote:
> Not a bad idea.

I've reach my "not crap" idea quota for today.  Everyone can now
safely ignore the remaining 300 posts I'm contracted to make to earn
my "stay at home at earn up to $1 an hour" income.

But as seth points out..before I could write a new email.... there is
some client side tooling in place to deal with security tagged updates
specifically.  Now to support what you are talking about they may need
to be modified to support the usage case of "Slow updates except for
Security updates which I want as soon as possible".


-jef



From dbn.lists at gmail.com  Tue Nov 18 19:30:23 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Tue, 18 Nov 2008 11:30:23 -0800
Subject: f11 build error
In-Reply-To: <4923075B.70101@redhat.com>
References: <4922AC76.8080904@redhat.com>
	<91705d080811180407k3199841bm111a61c0a46651da@mail.gmail.com>
	<4923075B.70101@redhat.com>
Message-ID: <91705d080811181130j3ba5b7eet18443b66a908a310@mail.gmail.com>

2008/11/18 Gregory Hosler <ghosler at redhat.com>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dan Nicholson wrote:
>> 2008/11/18 Gregory Hosler <ghosler at redhat.com>:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>>> On Mon, Nov 17, 2008 at 7:21 AM, Bill Nottingham <notting redhat com> wrote:
>>>>> Gregory Hosler (ghosler redhat com) said:
>>>>>> not sure if this is the correct fedora mailing list or not to bring this up on...
>>>>> fedora-devel-list may be better, CC'ing it.
>>>>>
>>>>>> I came across a build error on X64, in F-11
>>>>>>
>>>>>> I have been seeing this exact bug report my other distso users that have been building my
>>>>>> package on other distro x64 platforms, and so far I do not know what the solution might be.
>>>>>>
>>>>>> When i do a libtool build on a library, I am seeing the following:
>>>>>>
>>>>>> /bin/sh ../libtool --tag=CC   --mode=link gcc  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
>>>>>> - -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
>>>>>> - -Wno-pointer-sign -funsigned-char -shared -fpic -fPIC  -o libgyachi.so gytreeview.o
>>>>>> gy_config.o gyachi_lib.o parsecfg.o theme_support.o sound_plugin.o plugins.o -lgtk-x11-2.0
>>>>>> - -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo
>>>>>> - -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0   -lltdl
>>>>>> - -lX11  -lpthread
>>>>>> libtool: link: gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
>>>>>> - -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wno-pointer-sign
>>>>>> - -funsigned-char -fpic -fPIC -o libgyachi.so gytreeview.o gy_config.o gyachi_lib.o
>>>>>> parsecfg.o theme_support.o sound_plugin.o plugins.o  -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
>>>>>> - -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype
>>>>>> - -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lltdl -lX11 -lpthread
>>>>>> /usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../lib64/crt1.o: In function `_start':
>>>>>> (.text+0x20): undefined reference to `main'
>>>>>> collect2: ld returned 1 exit status
>>>>>>
>>>>>> ld is not treating this as a shared library, rather it is treating this as a main program.
>>>>> The F-11 tree has libtool-2.2.6, instead of libtool-1.5 as in Fedora 10 and
>>>>> earlier. I suspect that's what's tripping you up.
>>>> Is automake being used?
>>> Yes
>>>
>>>> How are you invoking libtool?
>>> in my autogen.sh script (which runs the automake tool set) i do:
>>>
>>>        libtoolize --copy --force --automake
>>>
>>> which generates a libtool script.
>>>
>>>> I would suspect the correct way to do this in automake is:
>>>>
>>>> wherever_LTLIBRARIES = libgyachi.la
>>>> libgyachi_la_LDFLAGS = -avoid-version
>>> hmm... My libtool script does not have any references to anything *_LTLIBRARIES
>>> so i'm kinda at a loss as to the above 2 statements, or how to make them happen
>>
>> Not in the libtool script, in Makefile.am.
>
> ah.
>
>> I.e., how is libgyachi
>> being defined to be built by libtool. In most autotooled packages,
>> you'd do this in Makefile.am, and automake would expand it to
>> something usable:
>>
>> lib_LTLIBRARIES = libfoo.la
>> libfoo_la_SOURCES = foo.c bar.c
>>
>> That will make a libtool library installed to $(libdir). Since
>> libgyachi appears to be a module without an soversion (correct me if
>> I'm wrong), you can tell libtool to do that by adding "-avoid-version"
>> to the LDFLAGS.
>
> libgyachi is defined in the Makefile.am (attached) as follows:
>
> gyachilib_PROGRAMS = libgyachi.so
>
> gyachilibdir = @libdir@
>
> libgyachi_so_SOURCES =  gytreeview.c gytreeview.h \
>        .
>        .
>        .
>
> and ...
>
> now that you mention it, I think I understand what's happening. I was using a _PROGRAMS as
> opposed to a _LTLIBRARIES.

Exactly. You're creating an executable instead of a shared object.

> I'm mostly all set now.
>
> Remind me again, what is the purpose of the ".la" file. If my package's .so file is not
> intended to be linked against, then i believe that there is no point to distribute the
> ".la" file, correct? (la is "link archive" I think).

.la is "libtool archive". It keeps some metadata for libtool that
allows it to portably create and link to shared or static libraries.
If you're planning on dlopening this module (I'm guessing that's what
you want to do), it needs to be a shared object. On an ELF system, the
installed .la file doesn't help much, but during the build it allows
libtool to "do the right thing". See the automake documentation on
building libraries:

http://www.gnu.org/software/automake/manual/automake.html#A-Library

--
Dan



From jkeating at redhat.com  Tue Nov 18 19:31:07 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 18 Nov 2008 11:31:07 -0800
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <gfv4jp$abq$1@ger.gmane.org>
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>
	<20081117213116.GA25672@mokona.greysector.net>
	<4922C0D5.4070209@redhat.com>  <gfv4jp$abq$1@ger.gmane.org>
Message-ID: <1227036667.28543.7.camel@luminos.localdomain>

On Tue, 2008-11-18 at 14:21 -0500, Neal Becker wrote:
> Should nspluginwrapper be banned from wrapping this?  If so, should
> this be included in flash-plugin.spec?

Oh, I'm pretty sure you still want to keep flash separated from your
browser, regardless of the arch.

-- 
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/20081118/fa1e4244/attachment.sig>

From jamatos at fc.up.pt  Tue Nov 18 19:37:20 2008
From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=)
Date: Tue, 18 Nov 2008 19:37:20 +0000
Subject: Proposal - "Slow updates" repo
In-Reply-To: <49230F31.4030409@redhat.com>
References: <49230F31.4030409@redhat.com>
Message-ID: <200811181937.20825.jamatos@fc.up.pt>

On Tuesday 18 November 2008 18:53:37 Casey Dahlin wrote:
> Currently, when a packager has an update, he runs "make update," and
> bodhi goes and grabs the package out of koji and places it in the next
> mash of the updates-testing repo (Luke, please shout when I start
> getting this wrong).

IIRC you must explicitly require a push to testing-updates. The upgrade is not 
automatic.
-- 
Jos? Ab?lio



From joshuacov at googlemail.com  Tue Nov 18 19:43:11 2008
From: joshuacov at googlemail.com (Joshua C.)
Date: Tue, 18 Nov 2008 20:43:11 +0100
Subject: F11 Proposal: Stabilization
In-Reply-To: <5f6f8c5f0811181127u30953ae5ybd1195072df313d3@mail.gmail.com>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<20081117213742.GB5603@nostromo.devel.redhat.com>
	<4921E683.30407@redhat.com>
	<604aa7910811171354h26c8eb30r72280cc95ba9a976@mail.gmail.com>
	<1226960219.4098.20.camel@perihelion.bos.jonmasters.org>
	<49226383.3010800@leemhuis.info>
	<1227020349.4355.116.camel@code.and.org>
	<5f6f8c5f0811181127u30953ae5ybd1195072df313d3@mail.gmail.com>
Message-ID: <5f6f8c5f0811181143k5598591ftf7237e54835f67d4@mail.gmail.com>

2008/11/18 Joshua C. <joshuacov at googlemail.com>:
> 2008/11/18 James Antill <james at fedoraproject.org>:
>> On Tue, 2008-11-18 at 07:41 +0100, Thorsten Leemhuis wrote:
>>> On 17.11.2008 23:16, Jon Masters wrote:
>>>  >
>>> > Various other communities (and distributions) have made a
>>> > point out of "stable" releases where the "big ticket" feature is
>>> > stabilization, so I think it would be a win to consider that.
>>>
>>> I disagree: It seems to me a lot of the current Fedora users like the
>>> "latest bells and whistles" style (like you called it in the mail that
>>> started this discussion) I for one really like the steady stream of
>>> kernel-updates, as that greatly improves hardware support over time! On
>>> OpenSuse or Ubuntu you are often forced to run the development branches
>>> when you need newer driver (just like it was in the early Fedora days
>>> and in the RHL days).
>>
>>  Indeed, and someone else wants the latest transmission and someone else
>> the latest pidgin and someone else...
>>  So you either need 100x distributions, or the latest stuff of
>> everything.
>>
>>> > I would personally much
>>> > prefer that stuff that used to work didn't break randomly, and that
>>> > stable Fedora updates wouldn't result in me wondering whether suspend,
>>> > graphics, SELinux, or some other feature that was working was going to
>>> > break today. This isn't actually a rant, more pointing out a necessity.
>>>
>>> Agreed, but I tend to say we should work towards a solution where we can
>>> ship the "latest bells and whistles" and nevertheless provide stability.
>>>
>>> I for one think we need something like that:
>>> https://www.redhat.com/archives/fedora-advisory-board/2008-August/msg00025.html
>>>
>>> The relevant part:
>>>
>>> """
>>> I more and more think that we should consider to switch to a more
>>> rolling release scheme with different usage levels. Roughly something
>>> like the following maybe:
>>>
>>>
>>> Level 1 -- rawhide, similar to how it is today (a bit more stable and
>>> less breakage would be nice, but that's in the works already)
>>>
>>> Level 2pre -- things that got tested in rawhide, that are still young,
>>> but known to work well in rawhide; similar to what updates-testing for
>>> F9 is today;
>>>
>>> Level 2 -- things that worked fine for some time in 2pre; similar to
>>> what F9 is today
>>>
>>> Level 3pre -- things that worked fine for some time in 2
>>>
>>> Level 3 -- things that worked fine for some time in 2pre
>>>
>>>
>>> Level 3pre and 3 are like F8-updates-testing and F8, but with the
>>> difference that everything has to be tested and shipped in level 2 (aka
>>> F9) first.
>>> """
>>
>>  Ok, the above _only_ works if you can convince all the packagers that
>> they should backport fixes ... or you end up with things broken in
>> "Level 2+" until a newer "fixed"? package manages to come up through the
>> levels.
>>
>>  This "rolling relases" is roughly what we do with yum releases now, but
>> manually and so doesn't have the backport requirements problems. So if
>> we know that version 123 is pretty good but has a couple of annoying
>> edge case bugs ... we don't release into Fedora 8. Although even then
>> sometimes things get through.
>>  If someone thinks there is something magic that can be done to make
>> releases bug free, they should speak to someone involved in something
>> that was released into Fedora 9 and will be in RHEL-5.3. I know there
>> are a couple of packages that did that. It wasn't magic, but it sure
>> wasn't anything you can easily get people to do for Fedora (IMNSHO).
>>
>>
>> ? May contain other bugs.
>>
>> --
>> James Antill <james at fedoraproject.org>
>> Fedora
>>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
> maybe these 2 threads should be merged:
> 1. F11 Proposal: Stabilization
> 2. Proposal - "Slow updates" repo
>

 I like fedora because of the "latest bells and whistles". If
something breaks (and it often does), then it reminds me why i chose
fedora. every new code will always be full of bugs but there are also
other linux distros - (just some of them) opensuse and ubuntu.

this (IMHO) contradicts to the goal of fedora: the "latest bells and whistles".



From joshuacov at googlemail.com  Tue Nov 18 19:26:58 2008
From: joshuacov at googlemail.com (Joshua C.)
Date: Tue, 18 Nov 2008 20:26:58 +0100
Subject: Proposal - "Slow updates" repo
In-Reply-To: <alpine.LFD.2.00.0811181413520.1236@localhost.localdomain>
References: <49230F31.4030409@redhat.com> <4923104D.5080604@herr-schmitt.de>
	<49231142.9010804@redhat.com>
	<604aa7910811181106n3b30d9b5nbdef29ad334bda92@mail.gmail.com>
	<49231348.2060700@redhat.com>
	<alpine.LFD.2.00.0811181413520.1236@localhost.localdomain>
Message-ID: <5f6f8c5f0811181126n4f4a195as5fb9e05e2b49a084@mail.gmail.com>

2008/11/18 Seth Vidal <skvidal at fedoraproject.org>:
>
>
> On Tue, 18 Nov 2008, Casey Dahlin wrote:
>
>> Jeff Spaleta wrote:
>>>
>>> On Tue, Nov 18, 2008 at 10:02 AM, Casey Dahlin <cdahlin at redhat.com>
>>> wrote:
>>>
>>>> This is the one drawback to this strategy. Here a human judgement call
>>>> would
>>>> have to be made: Take the package and all its deps or run the risk. The
>>>> right answer would depend on the case, and on what the stable group
>>>> decides
>>>> their use case is best served by.
>>>>
>>>
>>> Security updates break the model for testing to. This is a known problem
>>> space.
>>>
>>> If you take your idea...but also make it so client side users can
>>> specifically know what is tagged as security and what is
>>> not...regardless of repo "speed" then you probably have something
>>> robust enough for everyone.
>>>
>>> Give client side the option to pull ALL security updates...from any
>>> repo "speed." That way the "slow" update repo doesn't have to be
>>> burdened with dealing with security updates as part of their mission
>>> as a special case.
>>>
>>> -jef
>>>
>>>
>> Not a bad idea.
>
> you mean like the already existing yum security plugin and the update info
> that bodhi generates?
>
> -sv
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-


maybe these 2 threads should be merged:
1. F11 Proposal: Stabilization
2. Proposal - "Slow updates" repo



From dennisml at conversis.de  Tue Nov 18 19:45:47 2008
From: dennisml at conversis.de (Dennis J.)
Date: Tue, 18 Nov 2008 20:45:47 +0100
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <1227036667.28543.7.camel@luminos.localdomain>
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>	<20081117213116.GA25672@mokona.greysector.net>	<4922C0D5.4070209@redhat.com>
	<gfv4jp$abq$1@ger.gmane.org>
	<1227036667.28543.7.camel@luminos.localdomain>
Message-ID: <49231B6B.20809@conversis.de>

On 11/18/2008 08:31 PM, Jesse Keating wrote:
> On Tue, 2008-11-18 at 14:21 -0500, Neal Becker wrote:
>> Should nspluginwrapper be banned from wrapping this?  If so, should
>> this be included in flash-plugin.spec?
>
> Oh, I'm pretty sure you still want to keep flash separated from your
> browser, regardless of the arch.

The problem is that nspluginwrapper actually can make problems worse. For 
me flash on it's own works perfectly fine but as soon as I wrap it I often 
get the "grey box of death". In fact I used to blame the various problems I 
had on flash when they were really nspluginwrappers fault.

Regards,
   Dennis



From jspaleta at gmail.com  Tue Nov 18 19:52:26 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 18 Nov 2008 10:52:26 -0900
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <49231B6B.20809@conversis.de>
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>
	<20081117213116.GA25672@mokona.greysector.net>
	<4922C0D5.4070209@redhat.com> <gfv4jp$abq$1@ger.gmane.org>
	<1227036667.28543.7.camel@luminos.localdomain>
	<49231B6B.20809@conversis.de>
Message-ID: <604aa7910811181152k6202a49bi70e6c2c227ca0703@mail.gmail.com>

On Tue, Nov 18, 2008 at 10:45 AM, Dennis J. <dennisml at conversis.de> wrote:
> The problem is that nspluginwrapper actually can make problems worse. For me
> flash on it's own works perfectly fine but as soon as I wrap it I often get
> the "grey box of death". In fact I used to blame the various problems I had
> on flash when they were really nspluginwrappers fault.

Works perfectly fine? Or appears to work perfectly fine?  What if
flash is behaving badly and doing something...not malicious..but wrong
and potentially damaging...that nspluginwrapper stops?

-jef



From pertusus at free.fr  Tue Nov 18 19:19:39 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 18 Nov 2008 20:19:39 +0100
Subject: BugZappers/HouseKeeping is a policy and seems incomplete
In-Reply-To: <da159fda0811161621y4847991bn8a87c1807d0fec29@mail.gmail.com>
References: <20081116160839.GC2933@free.fr>
	<da159fda0811161621y4847991bn8a87c1807d0fec29@mail.gmail.com>
Message-ID: <20081118191939.GB2610@free.fr>

On Sun, Nov 16, 2008 at 07:21:39PM -0500, Jon Stanley wrote:
> On Sun, Nov 16, 2008 at 11:08 AM, Patrice Dumas <pertusus at free.fr> wrote:
> 
> > And also I didn't found anything on this page telling that EOL version
> > bugs are automatically closed although I think that it is the case.
> 
> That's mentioned on this page:
> 
> https://fedoraproject.org/wiki/BugZappers/HouseKeeping/MonthAfterRelease


Not really what I was searching after... This seems more like an
internal procedure, not reallly something that informs packagers.

> And I'm not sure about linking it from the policy page, since it's not
> a policy that FPC mandated. But I'll leave that to the FPC members
> (who I think control that page).

Nope, these pages are more under the FESCo responsibility, though they
are opened to anybody for modification. 

What I asked for was to setup a page in the Policy group that would
explain the bugzilla policy.

--
Pat



From dennisml at conversis.de  Tue Nov 18 20:59:41 2008
From: dennisml at conversis.de (Dennis J.)
Date: Tue, 18 Nov 2008 21:59:41 +0100
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <604aa7910811181152k6202a49bi70e6c2c227ca0703@mail.gmail.com>
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>	<20081117213116.GA25672@mokona.greysector.net>	<4922C0D5.4070209@redhat.com>
	<gfv4jp$abq$1@ger.gmane.org>	<1227036667.28543.7.camel@luminos.localdomain>	<49231B6B.20809@conversis.de>
	<604aa7910811181152k6202a49bi70e6c2c227ca0703@mail.gmail.com>
Message-ID: <49232CBD.9070008@conversis.de>

On 11/18/2008 08:52 PM, Jeff Spaleta wrote:
> On Tue, Nov 18, 2008 at 10:45 AM, Dennis J.<dennisml at conversis.de>  wrote:
>> The problem is that nspluginwrapper actually can make problems worse. For me
>> flash on it's own works perfectly fine but as soon as I wrap it I often get
>> the "grey box of death". In fact I used to blame the various problems I had
>> on flash when they were really nspluginwrappers fault.
>
> Works perfectly fine? Or appears to work perfectly fine?  What if
> flash is behaving badly and doing something...not malicious..but wrong
> and potentially damaging...that nspluginwrapper stops?

I'm not saying that using nspluginwrapper is a bad idea but the current 
implementation doesn't work very well. How does introducing a well known 
problem provide a good solution to preventing a potential one?

Regards,
   Dennis



From mdehaan at redhat.com  Tue Nov 18 21:07:21 2008
From: mdehaan at redhat.com (Michael DeHaan)
Date: Tue, 18 Nov 2008 16:07:21 -0500
Subject: F11 Proposal: Stabilization
In-Reply-To: <1226958439.3814.6.camel@localhost.localdomain>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
Message-ID: <49232E89.6020400@redhat.com>

Tom "spot" Callaway wrote:
> On Mon, 2008-11-17 at 16:35 -0500, Jon Masters wrote:
>   
>> Yo,
>>
>> Can I make a proposal for a major theme for an upcoming Fedora (whether
>> F11 or F12): Stabilization.
>>
>> Rather than the latest bells and whistles, I would personally much
>> prefer that stuff that used to work didn't break randomly, and that
>> stable Fedora updates wouldn't result in me wondering whether suspend,
>> graphics, SELinux, or some other feature that was working was going to
>> break today. This isn't actually a rant, more pointing out a necessity.
>>     
>
> I'm not sure what magic fairy we'll have to sacrifice for this. We're
> always going to be moving forward and things are going to break.
>
> If you're volunteering to help QA, then I applaud you.
>
> ~spot
>
>   

One thing that comes to mind -- Debian style stable, testing, unstable, 
and experimental is kind of an interesting policy that gets halfway 
there, but it's probably wrong for us.   Rather, don't think of those 
particular time frames, but the idea of having different levels of 
repos.      This is closer to Casey's proposal a few threads down.

However he suggests something that might be a bit too close to EPEL -- 
EPEL doesn't work because a package can easily slip from testing to EPEL 
because it's just a monthly roll -- some packages are just a week old 
and there is no voting.  For some packages, voting would be hard to get.

Perhaps this discussion would be better framed around use cases of 
problems it is trying to solve, and then we can find solutions that fit 
those use cases:

Use case --- I have no desire to update my desktop, but I want newer 
virt tools, and I want security updates.

Use case -- my friend wants newer Open Office but that's it, and doesn't 
want to update ImportNetworkThingy until many people say it's ok.

How do we compare against the above already, and how might we take small 
actionable steps to get closer to them?

The above use cases almost seems to imply Debian pin priorities, and 
that makes me afraid.

Hard problem.

--Michael
   





From paul at city-fan.org  Tue Nov 18 21:07:36 2008
From: paul at city-fan.org (Paul Howarth)
Date: Tue, 18 Nov 2008 21:07:36 +0000
Subject: ANNOUNCE: Smock (simpler mock) - a mock wrapper for chain
 building
In-Reply-To: <20081118182909.GE22772@redhat.com>
References: <20081118174907.GA27568@amd.home.annexia.org>
	<200811181903.09563.opensource@till.name>
	<20081118181705.GA27734@amd.home.annexia.org>
	<20081118182909.GE22772@redhat.com>
Message-ID: <20081118210736.3af75d1a@metropolis.intra.city-fan.org>

On Tue, 18 Nov 2008 18:29:09 +0000
"Daniel P. Berrange" <berrange at redhat.com> wrote:

> On Tue, Nov 18, 2008 at 06:17:05PM +0000, Richard W.M. Jones wrote:
> > On Tue, Nov 18, 2008 at 07:02:57PM +0100, Till Maas wrote:
> > > Thanks a lot, this looks very helpful. To make it even more
> > > simplier, you can also use "file:///" urls in the mock config file
> > > for repositories.  Then do not need a webserver.
> > 
> > Does this work?  I'll take your word for it -- it would definitely
> > be simpler if we didn't need to run a web server :-)
> 
> It didn't work when I tried it originally. Perhaps its needs a newer
> mock than I had originally, or maybe I just did it wrong. Still worth
> trying again if it is expected to actually work...

I've been using it like this for *years* with loopback-mounted ISO
images for a low-cost source for the base repo. It definitely works.

Paul.



From chitlesh.goorah at gmail.com  Tue Nov 18 21:08:21 2008
From: chitlesh.goorah at gmail.com (Chitlesh GOORAH)
Date: Tue, 18 Nov 2008 22:08:21 +0100
Subject: Segfault with alliance on liveDVD
In-Reply-To: <49226E86.8050106@iinet.net.au>
References: <200811091924.06581.tnorth@fedoraproject.org>
	<50baabb30811100156pe30841cw1acaada5b0f784df@mail.gmail.com>
	<50baabb30811100243i260437cdja5de55c310c38ace@mail.gmail.com>
	<200811100743.04888.thibault.north@gmail.com>
	<49226E86.8050106@iinet.net.au>
Message-ID: <50baabb30811181308v190b9d9k822d8d59f4578bda@mail.gmail.com>

On Tue, Nov 18, 2008 at 8:28 AM, David Timms <dtimms at iinet.net.au> wrote:

> Or does graal have a missing Requires ?

graal(alliance) had a missing requires.

Kind regards,
Chitlesh



From itamar at ispbrasil.com.br  Tue Nov 18 21:14:23 2008
From: itamar at ispbrasil.com.br (Itamar - IspBrasil)
Date: Tue, 18 Nov 2008 19:14:23 -0200
Subject: apt-get segfault
Message-ID: <4923302F.2060303@ispbrasil.com.br>

[root at linux ~]# apt-get update
Segmentation fault


I am using lasted apt and fedora-package-config-apt for F10

any help ?



-- 
------------

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 chitlesh.goorah at gmail.com  Tue Nov 18 21:16:02 2008
From: chitlesh.goorah at gmail.com (Chitlesh GOORAH)
Date: Tue, 18 Nov 2008 22:16:02 +0100
Subject: F-10 repo ? for livecd-creator
In-Reply-To: <1227032580.28543.4.camel@luminos.localdomain>
References: <50baabb30811160318h31784cf1m4c7a41ddbe132ed7@mail.gmail.com>
	<1227032580.28543.4.camel@luminos.localdomain>
Message-ID: <50baabb30811181316v13e93ad1i116d2a443e862423@mail.gmail.com>

2008/11/18 Jesse Keating <jkeating at redhat.com>:
> I'm not sure I understand this question.  All the packages that are
> tagged for f10-final are the packages you see show up in rawhide each
> night.

I just don't want to pull up xxx.fc11, but the exact packages that
will be on F-10 livecds.

Kind regards,
Chitlesh



From lmacken at redhat.com  Tue Nov 18 21:22:21 2008
From: lmacken at redhat.com (Luke Macken)
Date: Tue, 18 Nov 2008 16:22:21 -0500
Subject: Proposal - "Slow updates" repo
In-Reply-To: <49230F31.4030409@redhat.com>
References: <49230F31.4030409@redhat.com>
Message-ID: <20081118212221.GB3459@x300.bos.redhat.com>

On Tue, Nov 18, 2008 at 01:53:37PM -0500, Casey Dahlin wrote:
> There's been a lot of talk about a stable release lately. Most agree  
> that its not what Fedora does best and not something that would be  
> natural for us to do. I have a sort of middle-ground proposal that might  
> be easy enough to implement that we could try it out.
>
> Currently, when a packager has an update, he runs "make update," and  
> bodhi goes and grabs the package out of koji and places it in the next  
> mash of the updates-testing repo (Luke, please shout when I start  
> getting this wrong). Then, bold subscribers to updates-testing install  
> it, check it out, and if two people report in that it didn't eat their  
> brane, it goes into the regular updates repo. That slim sanity check  
> prevents a whole helluva lot of breakage, but isn't a very broad testing  
> of the package.

Nope, the karma thresholds are completely configurable, and it defaults
to 3.  Yes, I agree that this is not a sufficient enough metric to
ensure that a package will not break anything.

> What I propose is having another repo called updates-slow. Like updates  
> testing this repo ships with Fedora but is disabled and hidden by  
> default. Interested parties would have to manually enable it, and  
> disable the regular updates repo. updates-slow would relate to updates  
> in a similar way that updates relates to updates-testing: packages would  
> go into it after people getting the general Fedora updates seem to be  
> ok. The criteria here would have to be much harder than the two karma  
> points it takes to move out of testing, I would suggest the people  
> interested in this feature form a group that decides what the entry  
> policy should be.
>
> The advantage is that this is fairly cheap to set up. Bodhi would need  
> some level of changes (Luke, what do you think?) but there's no  
> branching. We're basically just taking the ability which already exists  
> in yum to selectively take updates and providing a system to  
> collaboratively exploit this mechanism.

>From a bodhi perspective, I think it would be a minimally invasive
procedure.  It is currently written so that every release has a
Release.dist_tag + '-updates-testing' repo as well.  So, aside from a new koji
tag and mash config, and whatever interface changes the slowrepo policy
requires, it doesn't sound very difficult to implement.

However, all of this hinges on a policy that has yet to be created.  I
agree with you that we need an improved updates testing policy.  I don't
think we need a new SIG to provide it, as it sounds like a job for the
QA team.

> Not branching, however, also creates a disadvantage: with no ability to  
> create new packages, the slow repo can't take newer fixes without taking  
> an entire update. The slow repo must consume updates from Fedora in  
> whole packages; they don't have patch-level control over incoming  
> changes. Also, the slow repo has to synchronize at release time; you  
> can't have a late-F9-with-bits-of-F10 offering (hopefully though the  
> base set is the peak of mainline Fedora's QA).
>
> If the people interested in a stability feature are willing to help  
> govern and maintain this repo, and help with the bug load (we can't just  
> dump bugs against backdated versions directly on the maintainers), then  
> it could go a long way to meeting their needs.
>
> Thoughts?

I'm not quite sure that yet-another-repo will solve the actual problem at
hand, which is: we constantly break things in our stable releases.

Bodhi's karma system provides a very basic community-driven workflow for
"testing" updates.  The problem is that this "testing" is ambiguous,
unpredictable, and not documented.

Ok, so lets step back and figure out how we are actually breaking stuff.

    - Packaging issues.  Broken deps, %post, etc.
    - Bugs from new code in 'enhancement' updates.
    - Infrastructure->client-tool breakage 
      Bugs in infrastructure causing issues in the repos that the clients
      consume, causing bugs in their tools.  (Bug #471873 is a good example)
    - ...

So, how do we minimize that breakage?

    - Automated package sanity-checking.
      http://fedoraproject.org/wiki/QA/Beaker looks like it was the
      closest to solving that problem, but that initiative looks like it
      has since fizzled out.
    - Ensure that new features are tested, by humans and ideally a test suite.
    - Infrastructure bugs tend to decrease over time by nature, so we
      just need more developers to help out.
    - Having all upstream projects maintain a stable bugfix-only release
      would be great, but it's not going to happen.  Thus, we need to do
      the dirty work.

Once those issues are addressed, then it's a matter of letting our users
choose if they want 'incremental features' or 'a rock-solid slow
moving system'.  If we wanted to granularize our update repositories
even more, we could potentially make our 'stable' repository bug & security
fix only, and have a separate repo for new packages and enhancements....

luke



From giallu at gmail.com  Tue Nov 18 21:23:07 2008
From: giallu at gmail.com (Gianluca Sforna)
Date: Tue, 18 Nov 2008 22:23:07 +0100
Subject: F-10 repo ? for livecd-creator
In-Reply-To: <50baabb30811181316v13e93ad1i116d2a443e862423@mail.gmail.com>
References: <50baabb30811160318h31784cf1m4c7a41ddbe132ed7@mail.gmail.com>
	<1227032580.28543.4.camel@luminos.localdomain>
	<50baabb30811181316v13e93ad1i116d2a443e862423@mail.gmail.com>
Message-ID: <d5ad21470811181323l452159fk162391c032a54f6f@mail.gmail.com>

On Tue, Nov 18, 2008 at 10:16 PM, Chitlesh GOORAH
<chitlesh.goorah at gmail.com> wrote:
> 2008/11/18 Jesse Keating <jkeating at redhat.com>:
>> I'm not sure I understand this question.  All the packages that are
>> tagged for f10-final are the packages you see show up in rawhide each
>> night.
>
> I just don't want to pull up xxx.fc11, but the exact packages that
> will be on F-10 livecds.

AFAIK, no .fc11 packages landed in rawhide yet, that is, rawhide is still F10


-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna



From kazen at redhat.com  Tue Nov 18 21:26:17 2008
From: kazen at redhat.com (Karlos Smith)
Date: Tue, 18 Nov 2008 16:26:17 -0500
Subject: sudo and secure-path
Message-ID: <492332F9.2010705@redhat.com>

I'm not usually one to reopen cans of worms, but I must say that I'm not
happy about the way that secure-path is working in the new sudo build.

As I mention in the BZ I filed
(https://bugzilla.redhat.com/show_bug.cgi?id=471603), *adding* /sbin
/usr/sbin and /usr/local/sbin to the path when sudoing root makes sense,
but hardcoding the path has messed me up.  I have scripts that I allow
non-root users to execute through sudo without a password,  I don't put
those scripts in any of the *bin dirs, but the script dir is in the
users $PATH.

So in order to prevent people from having to type the occasional
"/sbin/", my users (and I, for I use these scripts as well) now have to
frequently type much longer paths to execute these scripts.

And while it was possible for people to add to their path to work around
the previous issue, I'm SOL, because there's no way to work around
"secure-path".

Is this really the right thing to do?

-- 
Karlos Smith
Red Hat Global Services
kasmith at redhat.com
+1 361 649-6255 c.




From dledford at redhat.com  Tue Nov 18 21:26:32 2008
From: dledford at redhat.com (Doug Ledford)
Date: Tue, 18 Nov 2008 16:26:32 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <491FBA0E.2070003@gmail.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>
	<1226686948.13086.44.camel@aglarond.local>
	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>
	<1226700116.13086.116.camel@aglarond.local>
	<491FBA0E.2070003@gmail.com>
Message-ID: <1227043592.4687.9.camel@firewall.xsintricity.com>

On Sun, 2008-11-16 at 00:13 -0600, Les Mikesell wrote:
> Jeremy Katz wrote:
> > Lots of things in a modern system are far removed from the stuff a unix
> > sysadmin has traditionally dealt with.  That doesn't make it necessarily
> > "bad".  And as Seth pointed out, this "all new is bad" or "all new is
> > good" dichotomy is a part of the problem
> >
> >   
> But if a system claiming to be new/better can't provide more or less 
> exact emulation of the system it wants to replace, it probably really 
> isn't better.

That statement is based on the incorrect assumption that the way things
used to be is/will be sane for the way things are going.  Sometimes you
just need to do things differently because what we grew up doing just
doesn't work any more.

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081118/c7aeb2ee/attachment.sig>

From stransky at redhat.com  Tue Nov 18 21:31:38 2008
From: stransky at redhat.com (Martin Stransky)
Date: Tue, 18 Nov 2008 22:31:38 +0100
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <49232CBD.9070008@conversis.de>
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>	<20081117213116.GA25672@mokona.greysector.net>	<4922C0D5.4070209@redhat.com>	<gfv4jp$abq$1@ger.gmane.org>	<1227036667.28543.7.camel@luminos.localdomain>	<49231B6B.20809@conversis.de>	<604aa7910811181152k6202a49bi70e6c2c227ca0703@mail.gmail.com>
	<49232CBD.9070008@conversis.de>
Message-ID: <4923343A.3080007@redhat.com>

Dennis J. wrote:
> On 11/18/2008 08:52 PM, Jeff Spaleta wrote:
>> On Tue, Nov 18, 2008 at 10:45 AM, Dennis J.<dennisml at conversis.de>  
>> wrote:
>>> The problem is that nspluginwrapper actually can make problems worse. 
>>> For me
>>> flash on it's own works perfectly fine but as soon as I wrap it I 
>>> often get
>>> the "grey box of death". In fact I used to blame the various problems 
>>> I had
>>> on flash when they were really nspluginwrappers fault.
>>
>> Works perfectly fine? Or appears to work perfectly fine?  What if
>> flash is behaving badly and doing something...not malicious..but wrong
>> and potentially damaging...that nspluginwrapper stops?
> 
> I'm not saying that using nspluginwrapper is a bad idea but the current 
> implementation doesn't work very well. How does introducing a well known 
> problem provide a good solution to preventing a potential one?

I think you'll appreciate nspluginwrapper when flash plugin crashes and 
takes whole browser to hell...It's definitely your choose ;-)

The current nspluginwrapper implementation is not perfect but some 
people prefer browser stability...

ma.



From ivazqueznet at gmail.com  Tue Nov 18 21:31:26 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Tue, 18 Nov 2008 16:31:26 -0500
Subject: apt-get segfault
In-Reply-To: <4923302F.2060303@ispbrasil.com.br>
References: <4923302F.2060303@ispbrasil.com.br>
Message-ID: <1227043886.736.68.camel@ignacio.lan>

On Tue, 2008-11-18 at 19:14 -0200, Itamar - IspBrasil wrote:
> [root at linux ~]# apt-get update
> Segmentation fault
> 
> 
> I am using lasted apt and fedora-package-config-apt for F10
> 
> any help ?

http://fedoraproject.org/wiki/StackTraces

-- 
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/20081118/e0314a48/attachment.sig>

From jkeating at redhat.com  Tue Nov 18 21:31:30 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 18 Nov 2008 13:31:30 -0800
Subject: F11 Proposal: Stabilization
In-Reply-To: <49232E89.6020400@redhat.com>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
Message-ID: <1227043890.28543.18.camel@luminos.localdomain>

On Tue, 2008-11-18 at 16:07 -0500, Michael DeHaan wrote:
> Use case --- I have no desire to update my desktop, but I want newer 
> virt tools, and I want security updates.
> 
> Use case -- my friend wants newer Open Office but that's it, and doesn't 
> want to update ImportNetworkThingy until many people say it's ok.
> 
> How do we compare against the above already, and how might we take small 
> actionable steps to get closer to them?
> 
> The above use cases almost seems to imply Debian pin priorities, and 
> that makes me afraid.
> 
> Hard problem.

Couldn't both the above be solved by 'subscribing' to those sets of
packages via say PackageKit?  That way when PackageKit goes to look for
updates, it only asks for updates for those particular packages.  When
you update, if anything else is needed to satisfy newer builds of those
packages they can be pulled in.

Of course, what we'd likely see is a combo of "Give me all security
updates" and also "Give me updates only for these sets of packages".
The interesting question is how to design UI around the subscriptions.

-- 
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/20081118/ee3c4abf/attachment.sig>

From s-t-rhbugzilla at wwwdotorg.org  Tue Nov 18 21:34:41 2008
From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren)
Date: Tue, 18 Nov 2008 14:34:41 -0700 (MST)
Subject: Heads up: OCaml 3.11.0 rebuild for Fedora 11
In-Reply-To: <20081118174914.GA27575@amd.home.annexia.org>
References: <20081118174914.GA27575@amd.home.annexia.org>
Message-ID: <1227044082.19833.TMDA@tmda.severn.wwwdotorg.org>

On Tue, November 18, 2008 10:49 am, Richard W.M. Jones wrote:
>
> Just a note that I'll be building OCaml 3.11.0+beta1 in Fedora 11
> (future Rawhide).  This will break everything OCaml-related for a
> little while, since it's known that some packages don't build with the
> new OCaml compiler yet.

Will you be initiating rebuilds of all the built-with-OCaml packages, or
is this a heads-up that individual maintainers need to, once the base
compiler build is done/tagged/pushed?

Thanks.



From itamar at ispbrasil.com.br  Tue Nov 18 21:41:00 2008
From: itamar at ispbrasil.com.br (Itamar - IspBrasil)
Date: Tue, 18 Nov 2008 19:41:00 -0200
Subject: apt-get segfault
In-Reply-To: <1227043886.736.68.camel@ignacio.lan>
References: <4923302F.2060303@ispbrasil.com.br>
	<1227043886.736.68.camel@ignacio.lan>
Message-ID: <4923366C.5070402@ispbrasil.com.br>

(gdb) run
Starting program: /usr/bin/apt-get
[Thread debugging using libthread_db enabled]
[New Thread 0x7ffff4bd0790 (LWP 24151)]
Detaching after fork from child process 24160.
Detaching after fork from child process 24161.
Detaching after fork from child process 24162.
Detaching after fork from child process 24163.
Detaching after fork from child process 24164.
Detaching after fork from child process 24165.

Program received signal SIGSEGV, Segmentation fault.
traversestack (st=0x7fffffffdc30, L1=0xe2b) at lgc.c:245
245       markobject(st, gt(L1));
Current language:  auto; currently c
Missing separate debuginfos, use: debuginfo-install 
bzip2-libs-1.0.5-3.fc10.x86_64 compat-db45-4.5.20-5.fc10.x86_64 
elfutils-libelf-0.137-3.fc10.x86_64 file-libs-4.26-3.fc10.x86_64 
glibc-2.9-2.x86_64 libgcc-4.3.2-7.x86_64 libselinux-2.0.73-1.fc10.x86_64 
libstdc++-4.3.2-7.x86_64 libxml2-2.7.2-1.fc10.x86_64 
lua-5.1.4-1.fc10.x86_64 nspr-4.7.2-2.fc10.x86_64 
nss-3.12.2.0-3.fc10.x86_64 popt-1.13-4.fc10.x86_64 
rpm-libs-4.6.0-0.rc1.7.x86_64 sqlite-3.5.9-2.fc10.x86_64 
zlib-1.2.3-18.fc9.x86_64

On 11/18/2008 7:31 PM, Ignacio Vazquez-Abrams wrote:
> On Tue, 2008-11-18 at 19:14 -0200, Itamar - IspBrasil wrote:
>    
>> [root at linux ~]# apt-get update
>> Segmentation fault
>>
>>
>> I am using lasted apt and fedora-package-config-apt for F10
>>
>> any help ?
>>      
>
> http://fedoraproject.org/wiki/StackTraces
>
>    


-- 
------------

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 bpepple at fedoraproject.org  Tue Nov 18 21:48:15 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 18 Nov 2008 16:48:15 -0500
Subject: Plan for tomorrows (20081119) FESCO meeting
Message-ID: <1227044895.28822.10.camel@kennedy>

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 - F11/F12 Schedule -
https://www.redhat.com/archives/fedora-advisory-board/2008-November/msg00037.html - f13, all

/topic FESCO-Meeting -- Features --
https://fedoraproject.org/wiki/Features/DeviceKit 

/topic FESCO-Meeting -- Features --
https://fedoraproject.org/wiki/Features/VolumeControl

/topic FESCO-Meeting -- Features --
https://fedoraproject.org/wiki/Features/Windows_cross_compiler

/topic FESCO-Meeting -- Features -- pushed from F10 to F11
https://fedoraproject.org/wiki/Features/Presto -- everything still
relevant?

/topic FESCO-Meeting -- Features
--https://fedoraproject.org/wiki/Features/Multiseat

/topic FESCo-Meeting - Fedora representative to LSB? -
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00763.html - bpepple

/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/20081118/febb9415/attachment.sig>

From rjones at redhat.com  Tue Nov 18 21:50:05 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 18 Nov 2008 21:50:05 +0000
Subject: Heads up: OCaml 3.11.0 rebuild for Fedora 11
In-Reply-To: <1227044082.19833.TMDA@tmda.severn.wwwdotorg.org>
References: <20081118174914.GA27575@amd.home.annexia.org>
	<1227044082.19833.TMDA@tmda.severn.wwwdotorg.org>
Message-ID: <20081118215005.GA28727@amd.home.annexia.org>

On Tue, Nov 18, 2008 at 02:34:41PM -0700, Stephen Warren wrote:
> On Tue, November 18, 2008 10:49 am, Richard W.M. Jones wrote:
> >
> > Just a note that I'll be building OCaml 3.11.0+beta1 in Fedora 11
> > (future Rawhide).  This will break everything OCaml-related for a
> > little while, since it's known that some packages don't build with the
> > new OCaml compiler yet.
> 
> Will you be initiating rebuilds of all the built-with-OCaml packages, or
> is this a heads-up that individual maintainers need to, once the base
> compiler build is done/tagged/pushed?

I will try to rebuild all dependent packages as well.  Not ones out of
the Fedora tree though obviously ..  I'm actually going to test the
upgrade on my local machine [using smock!] first so hopefully I won't
be committing anything catastrophically bad.

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 Lam at Lam.pl  Tue Nov 18 22:02:46 2008
From: Lam at Lam.pl (Leszek Matok)
Date: Tue, 18 Nov 2008 23:02:46 +0100
Subject: apt-get segfault
In-Reply-To: <1227043886.736.68.camel@ignacio.lan>
References: <4923302F.2060303@ispbrasil.com.br>
	<1227043886.736.68.camel@ignacio.lan>
Message-ID: <20081118230246.6339d4e5@pensja.lam.pl>

Dnia 2008-11-18, o godz. 16:31:26 Ignacio Vazquez-Abrams
<ivazqueznet at gmail.com> napisa?(a):

> On Tue, 2008-11-18 at 19:14 -0200, Itamar - IspBrasil wrote:
> > [root at linux ~]# apt-get update
> > Segmentation fault
> http://fedoraproject.org/wiki/StackTraces
No need:
https://bugzilla.redhat.com/show_bug.cgi?id=470728

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/20081118/8000158f/attachment.sig>

From mdehaan at redhat.com  Tue Nov 18 22:04:22 2008
From: mdehaan at redhat.com (Michael DeHaan)
Date: Tue, 18 Nov 2008 17:04:22 -0500
Subject: F11 Proposal: Stabilization
In-Reply-To: <1227043890.28543.18.camel@luminos.localdomain>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>	<1226958439.3814.6.camel@localhost.localdomain>	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
Message-ID: <49233BE6.3080808@redhat.com>

Jesse Keating wrote:
> On Tue, 2008-11-18 at 16:07 -0500, Michael DeHaan wrote:
>   
>> Use case --- I have no desire to update my desktop, but I want newer 
>> virt tools, and I want security updates.
>>
>> Use case -- my friend wants newer Open Office but that's it, and doesn't 
>> want to update ImportNetworkThingy until many people say it's ok.
>>
>> How do we compare against the above already, and how might we take small 
>> actionable steps to get closer to them?
>>
>> The above use cases almost seems to imply Debian pin priorities, and 
>> that makes me afraid.
>>
>> Hard problem.
>>     
>
> Couldn't both the above be solved by 'subscribing' to those sets of
> packages via say PackageKit?  That way when PackageKit goes to look for
> updates, it only asks for updates for those particular packages.  When
> you update, if anything else is needed to satisfy newer builds of those
> packages they can be pulled in.
>
> Of course, what we'd likely see is a combo of "Give me all security
> updates" and also "Give me updates only for these sets of packages".
> The interesting question is how to design UI around the subscriptions.
>
>   

I think I like this.

In the case of "I just want a newer OpenOffice" and don't touch 
everything else, that's already covered by a yum install today -- but we 
do need something for the update case(s).

--Michael



From nicolas.mailhot at laposte.net  Tue Nov 18 22:07:04 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 18 Nov 2008 23:07:04 +0100
Subject: New Fedora fonts packaging guidelines
Message-ID: <1227046025.29090.7.camel@arekh.okg>

Hi,

After several public and private discussions, I'm now formally proposing
http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation

for approval by FPC.

Behdad Esfahbod and Jens Petersen have kindly reviewed this proposal and
agree with it.

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/20081118/9f1d6547/attachment.sig>

From jkeating at redhat.com  Tue Nov 18 22:08:17 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 18 Nov 2008 14:08:17 -0800
Subject: F11 Proposal: Stabilization
In-Reply-To: <49233BE6.3080808@redhat.com>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
Message-ID: <1227046097.28543.21.camel@luminos.localdomain>

On Tue, 2008-11-18 at 17:04 -0500, Michael DeHaan wrote:
> > Couldn't both the above be solved by 'subscribing' to those sets of
> > packages via say PackageKit?  That way when PackageKit goes to look for
> > updates, it only asks for updates for those particular packages.  When
> > you update, if anything else is needed to satisfy newer builds of those
> > packages they can be pulled in.
> >
> > Of course, what we'd likely see is a combo of "Give me all security
> > updates" and also "Give me updates only for these sets of packages".
> > The interesting question is how to design UI around the subscriptions.
> >
> >   
> 
> I think I like this.
> 
> In the case of "I just want a newer OpenOffice" and don't touch 
> everything else, that's already covered by a yum install today -- but we 
> do need something for the update case(s).

The upside here is that it's purely client side code.  We don't have to
change anything about how we prepare and publish updates.

-- 
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/20081118/1c9531ef/attachment.sig>

From skvidal at fedoraproject.org  Tue Nov 18 22:12:07 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Tue, 18 Nov 2008 17:12:07 -0500 (EST)
Subject: F11 Proposal: Stabilization
In-Reply-To: <1227046097.28543.21.camel@luminos.localdomain>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
Message-ID: <alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>



On Tue, 18 Nov 2008, Jesse Keating wrote:

> On Tue, 2008-11-18 at 17:04 -0500, Michael DeHaan wrote:
>>> Couldn't both the above be solved by 'subscribing' to those sets of
>>> packages via say PackageKit?  That way when PackageKit goes to look for
>>> updates, it only asks for updates for those particular packages.  When
>>> you update, if anything else is needed to satisfy newer builds of those
>>> packages they can be pulled in.
>>>
>>> Of course, what we'd likely see is a combo of "Give me all security
>>> updates" and also "Give me updates only for these sets of packages".
>>> The interesting question is how to design UI around the subscriptions.
>>>
>>>
>>
>> I think I like this.
>>
>> In the case of "I just want a newer OpenOffice" and don't touch
>> everything else, that's already covered by a yum install today -- but we
>> do need something for the update case(s).
>
> The upside here is that it's purely client side code.  We don't have to
> change anything about how we prepare and publish updates.

Just to be clear I'm understanding:

we want to update openoffice and whatever it needs, but nothing else.


or you want to list a set of apps you want newer versions of and as little 
else as possible?

is that correct?

so it would be like an alias that says:

yum update really means yum update openoffice\* somestuff\*  \
      my_favorite_pkg\*


?

-sv



From dennisml at conversis.de  Tue Nov 18 22:17:46 2008
From: dennisml at conversis.de (Dennis J.)
Date: Tue, 18 Nov 2008 23:17:46 +0100
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <4923343A.3080007@redhat.com>
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>	<20081117213116.GA25672@mokona.greysector.net>	<4922C0D5.4070209@redhat.com>	<gfv4jp$abq$1@ger.gmane.org>	<1227036667.28543.7.camel@luminos.localdomain>	<49231B6B.20809@conversis.de>	<604aa7910811181152k6202a49bi70e6c2c227ca0703@mail.gmail.com>	<49232CBD.9070008@conversis.de>
	<4923343A.3080007@redhat.com>
Message-ID: <49233F0A.7040408@conversis.de>

On 11/18/2008 10:31 PM, Martin Stransky wrote:
> Dennis J. wrote:
>> On 11/18/2008 08:52 PM, Jeff Spaleta wrote:
>>> On Tue, Nov 18, 2008 at 10:45 AM, Dennis J.<dennisml at conversis.de>
>>> wrote:
>>>> The problem is that nspluginwrapper actually can make problems
>>>> worse. For me
>>>> flash on it's own works perfectly fine but as soon as I wrap it I
>>>> often get
>>>> the "grey box of death". In fact I used to blame the various
>>>> problems I had
>>>> on flash when they were really nspluginwrappers fault.
>>>
>>> Works perfectly fine? Or appears to work perfectly fine? What if
>>> flash is behaving badly and doing something...not malicious..but wrong
>>> and potentially damaging...that nspluginwrapper stops?
>>
>> I'm not saying that using nspluginwrapper is a bad idea but the
>> current implementation doesn't work very well. How does introducing a
>> well known problem provide a good solution to preventing a potential one?
>
> I think you'll appreciate nspluginwrapper when flash plugin crashes and
> takes whole browser to hell...It's definitely your choose ;-)
>
> The current nspluginwrapper implementation is not perfect but some
> people prefer browser stability...

But that's the point. For quite a few people browser stability actually 
*decreases* when nspluginwrapper is installed.

Regards,
   Dennis



From lesmikesell at gmail.com  Tue Nov 18 22:27:05 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 18 Nov 2008 16:27:05 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1227043592.4687.9.camel@firewall.xsintricity.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>	<1226593460.13077.91.camel@aglarond.local>	<20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>	<20081113223242.GB4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>	<1226678932.636.40.camel@aglarond.local>	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>	<1226686948.13086.44.camel@aglarond.local>	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>	<1226700116.13086.116.camel@aglarond.local>	<491FBA0E.2070003@gmail.com>
	<1227043592.4687.9.camel@firewall.xsintricity.com>
Message-ID: <49234139.1050400@gmail.com>

Doug Ledford wrote:
> On Sun, 2008-11-16 at 00:13 -0600, Les Mikesell wrote:
>> Jeremy Katz wrote:
>>> Lots of things in a modern system are far removed from the stuff a unix
>>> sysadmin has traditionally dealt with.  That doesn't make it necessarily
>>> "bad".  And as Seth pointed out, this "all new is bad" or "all new is
>>> good" dichotomy is a part of the problem
>>>
>>>   
>> But if a system claiming to be new/better can't provide more or less 
>> exact emulation of the system it wants to replace, it probably really 
>> isn't better.
> 
> That statement is based on the incorrect assumption that the way things
> used to be is/will be sane for the way things are going.  Sometimes you
> just need to do things differently because what we grew up doing just
> doesn't work any more.

Maybe - when tcp is replaced with some other protocol - or name and 
number assignment are no longer parceled out through a hierarchical 
process.  Until then, servers need a way to assign  the addresses 
manually in ways that are easy to relate to the physical wires that you 
plug into them, and it needs to be done by a person with authorization 
passed down the appropriate hierarchy.  It's not something a daemon can 
guess at.   If you want to make things easier for people who haven't 
already automated their processes, you could build a gui that deals with 
with configuring the separate programs that need to be tied together for 
related concepts.  That is, you could have a gui form where you fill in 
a name, ip, and mac address and have the tool build the forward and 
reverse DNS zone entries and either the local interface configuration 
tied to that nic or the dhcp entry to assign it to a different machine.

For people who have already automated these processes, try not to screw 
it up too badly.  If the way it is done now didn't work, we wouldn't 
have an internet.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From thomas.moschny at gmail.com  Tue Nov 18 22:25:52 2008
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Tue, 18 Nov 2008 23:25:52 +0100
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <49233F0A.7040408@conversis.de>
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>
	<20081117213116.GA25672@mokona.greysector.net>
	<4922C0D5.4070209@redhat.com> <gfv4jp$abq$1@ger.gmane.org>
	<1227036667.28543.7.camel@luminos.localdomain>
	<49231B6B.20809@conversis.de>
	<604aa7910811181152k6202a49bi70e6c2c227ca0703@mail.gmail.com>
	<49232CBD.9070008@conversis.de> <4923343A.3080007@redhat.com>
	<49233F0A.7040408@conversis.de>
Message-ID: <a9d183c80811181425s6f3bc808wd8a46fba7ef736d3@mail.gmail.com>

2008/11/18 Dennis J. <dennisml at conversis.de>:
> But that's the point. For quite a few people browser stability actually
> *decreases* when nspluginwrapper is installed.

To be honest, the grey box is annoying, but better than FF crashing
completely, which happened to me two times within 10 minutes after
(temporarily) deinstalling nspluginwrapper (on F9).

Regards,
Thomas


-- 
Thomas Moschny <thomas.moschny at gmail.com>



From jkeating at redhat.com  Tue Nov 18 22:36:09 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 18 Nov 2008 14:36:09 -0800
Subject: F11 Proposal: Stabilization
In-Reply-To: <alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
Message-ID: <1227047769.28543.24.camel@luminos.localdomain>

On Tue, 2008-11-18 at 17:12 -0500, Seth Vidal wrote:
> 
> so it would be like an alias that says:
> 
> yum update really means yum update openoffice\* somestuff\*  \
>       my_favorite_pkg\*

Pretty much.  I don't know how this would look/work at the yum level
where we can already just do what you said 'yum update foo\* bar\*', the
graphical level could just be some UI around this.

Essentially instead of subscribing to the firehose that is "update
everything possible from these repos" that is the default, to "only
consider these package sets as update targets, pull in whatever else you
need".

I personally don't see this as very useful, but then again I'm on a
decent internet connection, I have a fairly sparse install as it is, and
I want the firehose.

-- 
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/20081118/04d9e0d6/attachment.sig>

From skvidal at fedoraproject.org  Tue Nov 18 22:42:49 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Tue, 18 Nov 2008 17:42:49 -0500 (EST)
Subject: F11 Proposal: Stabilization
In-Reply-To: <1227047769.28543.24.camel@luminos.localdomain>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<1227047769.28543.24.camel@luminos.localdomain>
Message-ID: <alpine.LFD.2.00.0811181740360.1236@localhost.localdomain>



On Tue, 18 Nov 2008, Jesse Keating wrote:

> On Tue, 2008-11-18 at 17:12 -0500, Seth Vidal wrote:
>>
>> so it would be like an alias that says:
>>
>> yum update really means yum update openoffice\* somestuff\*  \
>>       my_favorite_pkg\*
>
> Pretty much.  I don't know how this would look/work at the yum level
> where we can already just do what you said 'yum update foo\* bar\*', the
> graphical level could just be some UI around this.
>
> Essentially instead of subscribing to the firehose that is "update
> everything possible from these repos" that is the default, to "only
> consider these package sets as update targets, pull in whatever else you
> need".

Right - in some of these cases the last bit "pull in whatever else you 
need" is the same as 'twist the firehose nozzle all the way as far as it 
will go, hold tight!'

>
> I personally don't see this as very useful, but then again I'm on a
> decent internet connection, I have a fairly sparse install as it is, and



> I want the firehose.

That's a Quote of the Day.

-sv





From thomas.moschny at gmail.com  Tue Nov 18 22:45:57 2008
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Tue, 18 Nov 2008 23:45:57 +0100
Subject: Heads up: waf 1.5
Message-ID: <a9d183c80811181445h421c1f7dq58f7b08248091c08@mail.gmail.com>

Hi!

I'd like to update waf [1] to version 1.5.0 (which has been released
only recently, and changes apis) for rawhide, and also as an update
for f10. As far as I can see, only midori depends on it (although some
more packages probably should, like kdissert).

Any objections?

Regards,
Thomas

[1] http://code.google.com/p/waf/

-- 
Thomas Moschny <thomas.moschny at gmail.com>



From jkeating at redhat.com  Tue Nov 18 22:50:21 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 18 Nov 2008 14:50:21 -0800
Subject: F11 Proposal: Stabilization
In-Reply-To: <alpine.LFD.2.00.0811181740360.1236@localhost.localdomain>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<1227047769.28543.24.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181740360.1236@localhost.localdomain>
Message-ID: <1227048621.28543.26.camel@luminos.localdomain>

On Tue, 2008-11-18 at 17:42 -0500, Seth Vidal wrote:
> 
> Right - in some of these cases the last bit "pull in whatever else you 
> need" is the same as 'twist the firehose nozzle all the way as far as it 
> will go, hold tight!'

Hardly.  Much of the time updates are pretty self contained and
independent of other updates.  Just because I want say pidgin updated
doesn't mean I have to get OpenOffice.org updated too, or just because I
want newer emacs doesn't mean I have to get newer eclipse+java, so on
and so forth.  There really is a difference between targeted updates
+deps and the firehose.

-- 
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/20081118/c3df8fad/attachment.sig>

From skvidal at fedoraproject.org  Tue Nov 18 23:08:21 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Tue, 18 Nov 2008 18:08:21 -0500 (EST)
Subject: F11 Proposal: Stabilization
In-Reply-To: <1227048621.28543.26.camel@luminos.localdomain>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<1227047769.28543.24.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181740360.1236@localhost.localdomain>
	<1227048621.28543.26.camel@luminos.localdomain>
Message-ID: <alpine.LFD.2.00.0811181808030.1236@localhost.localdomain>



On Tue, 18 Nov 2008, Jesse Keating wrote:

> On Tue, 2008-11-18 at 17:42 -0500, Seth Vidal wrote:
>>
>> Right - in some of these cases the last bit "pull in whatever else you
>> need" is the same as 'twist the firehose nozzle all the way as far as it
>> will go, hold tight!'
>
> Hardly.  Much of the time updates are pretty self contained and
> independent of other updates.  Just because I want say pidgin updated
> doesn't mean I have to get OpenOffice.org updated too, or just because I
> want newer emacs doesn't mean I have to get newer eclipse+java, so on
> and so forth.  There really is a difference between targeted updates
> +deps and the firehose.
>

sure, that's why I said 'some'.

That's all.

-sv



From lesmikesell at gmail.com  Tue Nov 18 23:16:54 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 18 Nov 2008 17:16:54 -0600
Subject: F11 Proposal: Stabilization
In-Reply-To: <alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>	<1226958439.3814.6.camel@localhost.localdomain>	<49232E89.6020400@redhat.com>	<1227043890.28543.18.camel@luminos.localdomain>	<49233BE6.3080808@redhat.com>	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
Message-ID: <49234CE6.7050805@gmail.com>

Seth Vidal wrote:
> 
>>> In the case of "I just want a newer OpenOffice" and don't touch
>>> everything else, that's already covered by a yum install today -- but we
>>> do need something for the update case(s).
>>
>> The upside here is that it's purely client side code.  We don't have to
>> change anything about how we prepare and publish updates.
> 
> Just to be clear I'm understanding:
> 
> we want to update openoffice and whatever it needs, but nothing else.
> 
> 
> or you want to list a set of apps you want newer versions of and as 
> little else as possible?
> 
> is that correct?
> 
> so it would be like an alias that says:
> 
> yum update really means yum update openoffice\* somestuff\*  \
>      my_favorite_pkg\*
> 

I think what people really want is 'updates that fix the things that are 
already broken' but not 'updates that break something new'.  Can you 
come up with a way to 'crowdsource' this statistic?  Perhaps an optional 
poll where people could rate the health of their system and individual 
apps, preferably tied somehow to the smolt hardware reports so someone 
could see how the current updates run on hardware like their own or 
which update triggered a flurry of problems.  Or maybe this could be 
automated - but the absence of problem reports for an update could mean 
that no machines survived to send them...

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jspaleta at gmail.com  Tue Nov 18 23:24:14 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 18 Nov 2008 14:24:14 -0900
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <49233F0A.7040408@conversis.de>
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>
	<20081117213116.GA25672@mokona.greysector.net>
	<4922C0D5.4070209@redhat.com> <gfv4jp$abq$1@ger.gmane.org>
	<1227036667.28543.7.camel@luminos.localdomain>
	<49231B6B.20809@conversis.de>
	<604aa7910811181152k6202a49bi70e6c2c227ca0703@mail.gmail.com>
	<49232CBD.9070008@conversis.de> <4923343A.3080007@redhat.com>
	<49233F0A.7040408@conversis.de>
Message-ID: <604aa7910811181524i361d5978lc61905e0b4614fb2@mail.gmail.com>

On Tue, Nov 18, 2008 at 1:17 PM, Dennis J. <dennisml at conversis.de> wrote:
> But that's the point. For quite a few people browser stability actually
> *decreases* when nspluginwrapper is installed.

No... your browser lives... the flash plugin dies.

Without the wrapper... if the flash plugin does something crash-worthy
it crashes firefox completely. The way the wrapper works..flash
dies..the browser lives.

-jef



From jkeating at redhat.com  Tue Nov 18 23:30:26 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 18 Nov 2008 15:30:26 -0800
Subject: F11 Proposal: Stabilization
In-Reply-To: <49234CE6.7050805@gmail.com>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<49234CE6.7050805@gmail.com>
Message-ID: <1227051027.28543.27.camel@luminos.localdomain>

On Tue, 2008-11-18 at 17:16 -0600, Les Mikesell wrote:
> I think what people really want is 'updates that fix the things that are 
> already broken' but not 'updates that break something new'.  Can you 
> come up with a way to 'crowdsource' this statistic?  Perhaps an optional 
> poll where people could rate the health of their system and individual 
> apps, preferably tied somehow to the smolt hardware reports so someone 
> could see how the current updates run on hardware like their own or 
> which update triggered a flurry of problems.  Or maybe this could be 
> automated - but the absence of problem reports for an update could mean 
> that no machines survived to send them...

This is the role that bodhi karma is trying to play.

-- 
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/20081118/514c68b0/attachment.sig>

From opensource at till.name  Tue Nov 18 23:39:43 2008
From: opensource at till.name (Till Maas)
Date: Wed, 19 Nov 2008 00:39:43 +0100
Subject: ANNOUNCE: Smock (simpler mock) - a mock wrapper for chain
	building
In-Reply-To: <20081118174907.GA27568@amd.home.annexia.org>
References: <20081118174907.GA27568@amd.home.annexia.org>
Message-ID: <200811190039.47991.opensource@till.name>

On Tue November 18 2008, Richard W.M. Jones wrote:
> 'Smock' stands for 'simpler mock'.  It's a script that runs on top of
> mock, allowing you to chain-build a series of RPMs from a single
> command.
>
>   smock.pl --arch=i386 --arch=x86_64 \
>       --distro=fedora-9 --distro=fedora-10 \
>       *.src.rpm
>
> The above command would arrange the SRPMs into the correct order
> according to their BuildRequires, then build each in the four separate
> mock environments Fedora {9,10} {i386,x86_64}.  It makes the result of
> each previous package build available to subsequent packages, and in
> case of error it is fully restartable (it skips packages which have
> already been built).

Sadly it seems not to work with only srpm or if the only BRs that several 
srpms connect are of the type "%{name}-devel", because it seems to assume 
that every srpm only provides it's name as a package.

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/20081119/3cd04f07/attachment.sig>

From wtogami at redhat.com  Tue Nov 18 23:42:48 2008
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 18 Nov 2008 18:42:48 -0500
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <604aa7910811181524i361d5978lc61905e0b4614fb2@mail.gmail.com>
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>	<20081117213116.GA25672@mokona.greysector.net>	<4922C0D5.4070209@redhat.com>
	<gfv4jp$abq$1@ger.gmane.org>	<1227036667.28543.7.camel@luminos.localdomain>	<49231B6B.20809@conversis.de>	<604aa7910811181152k6202a49bi70e6c2c227ca0703@mail.gmail.com>	<49232CBD.9070008@conversis.de>
	<4923343A.3080007@redhat.com>	<49233F0A.7040408@conversis.de>
	<604aa7910811181524i361d5978lc61905e0b4614fb2@mail.gmail.com>
Message-ID: <492352F8.1060807@redhat.com>

Jeff Spaleta wrote:
> On Tue, Nov 18, 2008 at 1:17 PM, Dennis J. <dennisml at conversis.de> wrote:
>> But that's the point. For quite a few people browser stability actually
>> *decreases* when nspluginwrapper is installed.
> 
> No... your browser lives... the flash plugin dies.
> 
> Without the wrapper... if the flash plugin does something crash-worthy
> it crashes firefox completely. The way the wrapper works..flash
> dies..the browser lives.
> 
> -jef
> 

nspluginwrapper development is still important. This is because 
nspluginwrapper runs plugins in a separate process, enabling the browser 
to survive inevitable plugin bugs, and also the possibility of 
additional security through security policy isolation of that separate 
process. Fedora 8+ has run all plugins, even native 32bit-on-32bit, 
wrapped in nspluginwrapper for this purpose.

https://www.redhat.com/mailman/listinfo/nspluginwrapper-d...
nspluginwrapper development discussion here. Please report your problems 
running the latest nspluginwrapper (currently 1.1.4) here. Gwenole is 
very good about responding to reports, often with patches to try.

If you don't want to deal with reporting bugs, you are free to remove 
nspluginwrapper.  But then you have to live with the browser crashes.

http://macromedia.mplug.org/
I maintain a list of tips and workarounds to workaround Flash problems here.

Warren Togami
wtogami at redhat.com



From jspaleta at gmail.com  Tue Nov 18 23:54:29 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 18 Nov 2008 14:54:29 -0900
Subject: F11 Proposal: Stabilization
In-Reply-To: <49234CE6.7050805@gmail.com>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<49234CE6.7050805@gmail.com>
Message-ID: <604aa7910811181554q238d59ber63bf99565a37558e@mail.gmail.com>

On Tue, Nov 18, 2008 at 2:16 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> I think what people really want is 'updates that fix the things that are
> already broken' but not 'updates that break something new'.  Can you come up
> with a way to 'crowdsource' this statistic?  Perhaps an optional poll where
> people could rate the health of their system and individual apps, preferably
> tied somehow to the smolt hardware reports so someone could see how the
> current updates run on hardware like their own or which update triggered a
> flurry of problems.  Or maybe this could be automated - but the absence of
> problem reports for an update could mean that no machines survived to send
> them...

Uhm.... in order to get "crowdsource" stats.. which will help you
prevent the releasing of updates to the crowd...there has to be a
crowd of people using the updates. How do yuou get feedback from the
crowd without exposing the crowd to the updates?

-jef



From bashton at brennanashton.com  Tue Nov 18 23:55:02 2008
From: bashton at brennanashton.com (Brennan Ashton)
Date: Tue, 18 Nov 2008 15:55:02 -0800
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <1227036667.28543.7.camel@luminos.localdomain>
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>
	<20081117213116.GA25672@mokona.greysector.net>
	<4922C0D5.4070209@redhat.com> <gfv4jp$abq$1@ger.gmane.org>
	<1227036667.28543.7.camel@luminos.localdomain>
Message-ID: <981da310811181555o3b4f0a7die4a4df37a5f7ecba@mail.gmail.com>

2008/11/18 Jesse Keating <jkeating at redhat.com>:
> On Tue, 2008-11-18 at 14:21 -0500, Neal Becker wrote:
>> Should nspluginwrapper be banned from wrapping this?  If so, should
>> this be included in flash-plugin.spec?
>
> Oh, I'm pretty sure you still want to keep flash separated from your
> browser, regardless of the arch.

Not according to the developer of the 64bit plugin.

"
Talking about nspluginwrapper: I strongly suggest not to use it. I
know that some distros are thinking of even wrapping 64-bit plugins
including Ubuntu with the thought that it will improve security and
stability of the browser. This is a very bad idea in the state
nspluginwrapper is in today. We have done some internal testing and
discovered that several features in the Flash Player are broken when
the plugin is wrapped. More importantly performance and user
experience is pretty bad when the plugin is wrapped. Why? Lots of data
needs to be transfered through IPC channels. I hope that browser
vendors will eventually come up with a better architecture to wrap
plugins without sacrificing performance, stability and functionality.
"
http://www.kaourantin.net/2008/11/64-bits.html


I am not advocating one way or another, just wanted to get the voice
out of one of the few who really knows what is going on behind the
plugin.

--Brennan Ashton



From jspaleta at gmail.com  Wed Nov 19 00:00:30 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 18 Nov 2008 15:00:30 -0900
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <981da310811181555o3b4f0a7die4a4df37a5f7ecba@mail.gmail.com>
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>
	<20081117213116.GA25672@mokona.greysector.net>
	<4922C0D5.4070209@redhat.com> <gfv4jp$abq$1@ger.gmane.org>
	<1227036667.28543.7.camel@luminos.localdomain>
	<981da310811181555o3b4f0a7die4a4df37a5f7ecba@mail.gmail.com>
Message-ID: <604aa7910811181600s6774eed3o1d7a4924e62bbe0a@mail.gmail.com>

On Tue, Nov 18, 2008 at 2:55 PM, Brennan Ashton
<bashton at brennanashton.com> wrote:
> I am not advocating one way or another, just wanted to get the voice
> out of one of the few who really knows what is going on behind the
> plugin.

Hey wouldn't it be great if we had as much access to their code as
they have access to examine nspluginwrapper so we could find the
optimal solution and fix ALL the codepaths?


-jef"I'll show you mine... if you show me yours"spaleta



From lesmikesell at gmail.com  Wed Nov 19 00:11:30 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 18 Nov 2008 18:11:30 -0600
Subject: F11 Proposal: Stabilization
In-Reply-To: <604aa7910811181554q238d59ber63bf99565a37558e@mail.gmail.com>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>	<1226958439.3814.6.camel@localhost.localdomain>	<49232E89.6020400@redhat.com>	<1227043890.28543.18.camel@luminos.localdomain>	<49233BE6.3080808@redhat.com>	<1227046097.28543.21.camel@luminos.localdomain>	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>	<49234CE6.7050805@gmail.com>
	<604aa7910811181554q238d59ber63bf99565a37558e@mail.gmail.com>
Message-ID: <492359B2.2010008@gmail.com>

Jeff Spaleta wrote:
> On Tue, Nov 18, 2008 at 2:16 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
>> I think what people really want is 'updates that fix the things that are
>> already broken' but not 'updates that break something new'.  Can you come up
>> with a way to 'crowdsource' this statistic?  Perhaps an optional poll where
>> people could rate the health of their system and individual apps, preferably
>> tied somehow to the smolt hardware reports so someone could see how the
>> current updates run on hardware like their own or which update triggered a
>> flurry of problems.  Or maybe this could be automated - but the absence of
>> problem reports for an update could mean that no machines survived to send
>> them...
> 
> Uhm.... in order to get "crowdsource" stats.. which will help you
> prevent the releasing of updates to the crowd...there has to be a
> crowd of people using the updates. How do yuou get feedback from the
> crowd without exposing the crowd to the updates?

Every time anyone mentions slowing down the feature changes in favor of 
fixing the brokenness there are a flurry of postings from people saying 
they want all the new features they can get.  There has to be a way to 
take advantage of these willing guinea pigs (or is it canaries in a mine 
shaft?) and let their experience determine when it is safe for everyone 
else to follow.  But, you either need an intermediate repository with 
things moved on to the safer one at some point, or a client-driven 
mechanism that knows how to request the degree of vetting desired along 
with some way to accumulate the statistics.  I'd personally be much more 
interested in keeping an up to date test box running if I knew that 
experiencing problems on it would have any eventual benefits.

-- 
    Les Mikesell
     lesmikesell at gmail.com



From jwilliam at xmission.com  Wed Nov 19 00:15:03 2008
From: jwilliam at xmission.com (Jerry Williams)
Date: Tue, 18 Nov 2008 17:15:03 -0700
Subject: F11 Proposal: Stabilization
In-Reply-To: <1227048621.28543.26.camel@luminos.localdomain>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org><1226958439.3814.6.camel@localhost.localdomain><49232E89.6020400@redhat.com><1227043890.28543.18.camel@luminos.localdomain><49233BE6.3080808@redhat.com><1227046097.28543.21.camel@luminos.localdomain><alpine.LFD.2.00.0811181710530.1236@localhost.localdomain><1227047769.28543.24.camel@luminos.localdomain><alpine.LFD.2.00.0811181740360.1236@localhost.localdomain>
	<1227048621.28543.26.camel@luminos.localdomain>
Message-ID: <CAF6B2EEFF4940E98BB7CFA8CA4B2952@Q9450>

I am not sure if this exists with yum now or not.
My experience has been if something has been around for a while it usually
doesn't break things.  Or maybe the correct thing to say is that if it does
break things then there is a newer version fairly soon.
So is there a way to say that I only want updates that are 2 weeks old?

Jerry Williams

> -----Original Message-----
> From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-
> bounces at redhat.com] On Behalf Of Jesse Keating
> Sent: Tuesday, November 18, 2008 3:50 PM
> To: fedora-devel-list at redhat.com
> Subject: Re: F11 Proposal: Stabilization
> 
> On Tue, 2008-11-18 at 17:42 -0500, Seth Vidal wrote:
> >
> > Right - in some of these cases the last bit "pull in whatever else you
> > need" is the same as 'twist the firehose nozzle all the way as far as it
> > will go, hold tight!'
> 
> Hardly.  Much of the time updates are pretty self contained and
> independent of other updates.  Just because I want say pidgin updated
> doesn't mean I have to get OpenOffice.org updated too, or just because I
> want newer emacs doesn't mean I have to get newer eclipse+java, so on
> and so forth.  There really is a difference between targeted updates
> +deps and the firehose.
> 
> --
> Jesse Keating
> Fedora -- Freedom? is a feature!
> identi.ca: http://identi.ca/jkeating





From jkeating at redhat.com  Wed Nov 19 00:19:06 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 18 Nov 2008 16:19:06 -0800
Subject: F11 Proposal: Stabilization
In-Reply-To: <CAF6B2EEFF4940E98BB7CFA8CA4B2952@Q9450>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<1227047769.28543.24.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181740360.1236@localhost.localdomain>
	<1227048621.28543.26.camel@luminos.localdomain>
	<CAF6B2EEFF4940E98BB7CFA8CA4B2952@Q9450>
Message-ID: <1227053946.28543.28.camel@luminos.localdomain>

On Tue, 2008-11-18 at 17:15 -0700, Jerry Williams wrote:
> 
> I am not sure if this exists with yum now or not.
> My experience has been if something has been around for a while it usually
> doesn't break things.  Or maybe the correct thing to say is that if it does
> break things then there is a newer version fairly soon.
> So is there a way to say that I only want updates that are 2 weeks old?

This has come up a number of times, and each time the discussion kind of
fizzles out when you start to talk about what 'age' means.  The archives
should be a good read on this.

-- 
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/20081118/6d16afca/attachment.sig>

From jkeating at redhat.com  Wed Nov 19 00:19:54 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 18 Nov 2008 16:19:54 -0800
Subject: F11 Proposal: Stabilization
In-Reply-To: <492359B2.2010008@gmail.com>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<49234CE6.7050805@gmail.com>
	<604aa7910811181554q238d59ber63bf99565a37558e@mail.gmail.com>
	<492359B2.2010008@gmail.com>
Message-ID: <1227053994.28543.29.camel@luminos.localdomain>

On Tue, 2008-11-18 at 18:11 -0600, Les Mikesell wrote:
> But, you either need an intermediate repository with 
> things moved on to the safer one at some point,

You mean like updates-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/20081118/77fbecda/attachment.sig>

From jspaleta at gmail.com  Wed Nov 19 00:22:22 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 18 Nov 2008 15:22:22 -0900
Subject: F11 Proposal: Stabilization
In-Reply-To: <492359B2.2010008@gmail.com>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<49234CE6.7050805@gmail.com>
	<604aa7910811181554q238d59ber63bf99565a37558e@mail.gmail.com>
	<492359B2.2010008@gmail.com>
Message-ID: <604aa7910811181622q6d2b7f92kf20853a6c9f8c2f1@mail.gmail.com>

On Tue, Nov 18, 2008 at 3:11 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Every time anyone mentions slowing down the feature changes in favor of
> fixing the brokenness there are a flurry of postings from people saying they
> want all the new features they can get.


Are you talking about known brokenness that exists and has been
reported already.. or new brokenness that we don't know about yet that
is introduced in updates that our current ability to test failed to
catch? Holding back isn't going to magically help us prevent new
brokenness of any variety.

-jef



From fedora at shmuelhome.mine.nu  Wed Nov 19 00:55:20 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Wed, 19 Nov 2008 02:55:20 +0200
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <981da310811181555o3b4f0a7die4a4df37a5f7ecba@mail.gmail.com>
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>	<20081117213116.GA25672@mokona.greysector.net>	<4922C0D5.4070209@redhat.com>
	<gfv4jp$abq$1@ger.gmane.org>	<1227036667.28543.7.camel@luminos.localdomain>
	<981da310811181555o3b4f0a7die4a4df37a5f7ecba@mail.gmail.com>
Message-ID: <492363F8.30409@shmuelhome.mine.nu>

Brennan Ashton wrote:
> Not according to the developer of the 64bit plugin.
>
> "
> Talking about nspluginwrapper: I strongly suggest not to use it. I
> know that some distros are thinking of even wrapping 64-bit plugins
> including Ubuntu with the thought that it will improve security and
> stability of the browser. This is a very bad idea in the state
> nspluginwrapper is in today. We have done some internal testing and
> discovered that several features in the Flash Player are broken when
> the plugin is wrapped. More importantly performance and user
> experience is pretty bad when the plugin is wrapped. Why? Lots of data
> needs to be transfered through IPC channels. I hope that browser
> vendors will eventually come up with a better architecture to wrap
> plugins without sacrificing performance, stability and functionality.
> "
> http://www.kaourantin.net/2008/11/64-bits.html
>
>   
His statement that the wrapper breaks features of the player needs to be 
expanded. What features? Are they deliberately blocked for security or 
stability reasons? We aren't given any information information that 
indicates that the wrapper's architecture is wrong but the player's is 
right. He might be right but he certainly hasn't proven his case. All we 
know at this point is that his coding of the player is incompatible with 
the wrapper.



From ndbecker2 at gmail.com  Wed Nov 19 01:10:51 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Tue, 18 Nov 2008 20:10:51 -0500
Subject: Adobe Releases 64bit Flash Plugin for Linux
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>
	<20081117213116.GA25672@mokona.greysector.net>
	<4922C0D5.4070209@redhat.com> <gfv4jp$abq$1@ger.gmane.org>
	<1227036667.28543.7.camel@luminos.localdomain>
	<49231B6B.20809@conversis.de>
	<604aa7910811181152k6202a49bi70e6c2c227ca0703@mail.gmail.com>
	<49232CBD.9070008@conversis.de> <4923343A.3080007@redhat.com>
	<49233F0A.7040408@conversis.de>
	<604aa7910811181524i361d5978lc61905e0b4614fb2@mail.gmail.com>
	<492352F8.1060807@redhat.com>
Message-ID: <gfvp2s$foj$1@ger.gmane.org>

Warren Togami wrote:

> Jeff Spaleta wrote:
>> On Tue, Nov 18, 2008 at 1:17 PM, Dennis J. <dennisml at conversis.de> wrote:
>>> But that's the point. For quite a few people browser stability actually
>>> *decreases* when nspluginwrapper is installed.
>> 
>> No... your browser lives... the flash plugin dies.
>> 
>> Without the wrapper... if the flash plugin does something crash-worthy
>> it crashes firefox completely. The way the wrapper works..flash
>> dies..the browser lives.
>> 
>> -jef
>> 
> 
> nspluginwrapper development is still important. This is because
> nspluginwrapper runs plugins in a separate process, enabling the browser
> to survive inevitable plugin bugs, and also the possibility of
> additional security through security policy isolation of that separate
> process. Fedora 8+ has run all plugins, even native 32bit-on-32bit,
> wrapped in nspluginwrapper for this purpose.
> 
> https://www.redhat.com/mailman/listinfo/nspluginwrapper-d...
> nspluginwrapper development discussion here. Please report your problems
> running the latest nspluginwrapper (currently 1.1.4) here. Gwenole is
> very good about responding to reports, often with patches to try.
> 
> If you don't want to deal with reporting bugs, you are free to remove
> nspluginwrapper.  But then you have to live with the browser crashes.
> 
> http://macromedia.mplug.org/
> I maintain a list of tips and workarounds to workaround Flash problems
> here.
> 

Does 32-bit flash-plugin have to be removed?  I like to use a 32-bit flock around.  Can I have both 32-bit flash and 64-bit flash?  And, what will nspluginwrapper think of this? (I hope it will wrap the 64-bit version for 64 bit and the 32-bit version for 32 bit)




From dledford at redhat.com  Wed Nov 19 01:18:40 2008
From: dledford at redhat.com (Doug Ledford)
Date: Tue, 18 Nov 2008 20:18:40 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <49234139.1050400@gmail.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>
	<1226686948.13086.44.camel@aglarond.local>
	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>
	<1226700116.13086.116.camel@aglarond.local>	<491FBA0E.2070003@gmail.com>
	<1227043592.4687.9.camel@firewall.xsintricity.com>
	<49234139.1050400@gmail.com>
Message-ID: <1227057520.4687.45.camel@firewall.xsintricity.com>

On Tue, 2008-11-18 at 16:27 -0600, Les Mikesell wrote:
> Doug Ledford wrote:
> > On Sun, 2008-11-16 at 00:13 -0600, Les Mikesell wrote:
> >> Jeremy Katz wrote:
> >>> Lots of things in a modern system are far removed from the stuff a unix
> >>> sysadmin has traditionally dealt with.  That doesn't make it necessarily
> >>> "bad".  And as Seth pointed out, this "all new is bad" or "all new is
> >>> good" dichotomy is a part of the problem
> >>>
> >>>   
> >> But if a system claiming to be new/better can't provide more or less 
> >> exact emulation of the system it wants to replace, it probably really 
> >> isn't better.
> > 
> > That statement is based on the incorrect assumption that the way things
> > used to be is/will be sane for the way things are going.  Sometimes you
> > just need to do things differently because what we grew up doing just
> > doesn't work any more.
> 
> Maybe - when tcp is replaced with some other protocol - or name and 
> number assignment are no longer parceled out through a hierarchical 
> process.  Until then, servers need a way to assign  the addresses 
> manually in ways that are easy to relate to the physical wires that you 
> plug into them,

That's not true.  The relating of numbers/names to wires is an arbitrary
abstraction, and one that need not be the *only* possible abstraction.
I admit it's handy and common, especially with servers.  And certainly
you want a server to get the same address from boot to boot, especially
if it's a live server on the internet with people coming to it (or live
server on an intranet).  But, the eth0 naming is really
irrelevant...it's the hardware mac address that matters.  Being able to
go from wire to mac address matters, and going from mac address to
configuration matters.  Whether that configuration is called eth0 or
pr0n_serv0 doesn't really matter.  To use a similar situation that we've
already changed, back in the day, the only way to mount your root
filesystem was by device major:minor.  Eventually, we figured out that
since file systems have unique identifiers, we could screw the
major:minor pair and mount by label instead.  Now, that switch required
changes to mount, changes to fstab symantics, changes to initrd, etc.
But, it happened, and I doubt many people would say we are the worse off
for it.  I think there's definitely more to be done before we are ready
to make the same sort of switch in regards to networking, but I prophesy
that eventually we will get there and the old days of static ifcfg-eth0
files may go the way of the dinosaur.

>  and it needs to be done by a person with authorization 
> passed down the appropriate hierarchy.  It's not something a daemon can 
> guess at.   If you want to make things easier for people who haven't 
> already automated their processes, you could build a gui that deals with 
> with configuring the separate programs that need to be tied together for 
> related concepts.  That is, you could have a gui form where you fill in 
> a name, ip, and mac address and have the tool build the forward and 
> reverse DNS zone entries and either the local interface configuration 
> tied to that nic or the dhcp entry to assign it to a different machine.
> 
> For people who have already automated these processes, try not to screw 
> it up too badly.  If the way it is done now didn't work, we wouldn't 
> have an internet.

I'm sure it won't screw existing setups unless there is an overwhelming
compelling reason.  But, sometimes it's worth letting go of the old way
of doing things.  And I'm not saying this is even one of those cases,
just that your statement that it can't be better if it doesn't exactly
emulate the current way of doing things is a patently false straw man
and that each case needs to be evaluated individually and objectively.

For my own purposes, what would make dealing with udev/hal/etc. on a
server system much easier would be some concise guides in terms of how
these layers dealt with dynamic devices and how to achieve what you used
to do with modprobe.conf in udev land for example.  One of the things
the server SIG can do is come up with exactly that sort of
documentation.

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081118/ed10f8f4/attachment.sig>

From mattdm at mattdm.org  Wed Nov 19 01:54:36 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 18 Nov 2008 20:54:36 -0500
Subject: sudo and secure-path
In-Reply-To: <492332F9.2010705@redhat.com>
References: <492332F9.2010705@redhat.com>
Message-ID: <20081119015436.GA10662@jadzia.bu.edu>

On Tue, Nov 18, 2008 at 04:26:17PM -0500, Karlos Smith wrote:
> (https://bugzilla.redhat.com/show_bug.cgi?id=471603), *adding* /sbin
> /usr/sbin and /usr/local/sbin to the path when sudoing root makes sense,
> but hardcoding the path has messed me up.  I have scripts that I allow
> non-root users to execute through sudo without a password,  I don't put
> those scripts in any of the *bin dirs, but the script dir is in the
> users $PATH.
[...]
> And while it was possible for people to add to their path to work around
> the previous issue, I'm SOL, because there's no way to work around
> "secure-path".
> Is this really the right thing to do?

Yes. The tab-completion thing working is a side-effect -- the more important
thing is no surprises. How about a compromise -- add /usr/local/sbin to the
secure path?

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From jonstanley at gmail.com  Wed Nov 19 02:23:50 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Tue, 18 Nov 2008 21:23:50 -0500
Subject: sudo and secure-path
In-Reply-To: <20081119015436.GA10662@jadzia.bu.edu>
References: <492332F9.2010705@redhat.com>
	<20081119015436.GA10662@jadzia.bu.edu>
Message-ID: <da159fda0811181823n4d615206kb63272f39416ff1f@mail.gmail.com>

On Tue, Nov 18, 2008 at 8:54 PM, Matthew Miller <mattdm at mattdm.org> wrote:

> Yes. The tab-completion thing working is a side-effect -- the more important
> thing is no surprises. How about a compromise -- add /usr/local/sbin to the
> secure path?

You can't be guaranteed that path is in fact secure. Lots of systems
mount /usr/local from somewhere outside of their domain of control,
and I don't want to blindly trust stuff in there.

Users have a PATH for a reason. Let them keep it.



From lesmikesell at gmail.com  Wed Nov 19 02:24:07 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 18 Nov 2008 20:24:07 -0600
Subject: F11 Proposal: Stabilization
In-Reply-To: <604aa7910811181622q6d2b7f92kf20853a6c9f8c2f1@mail.gmail.com>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>	<1226958439.3814.6.camel@localhost.localdomain>	<49232E89.6020400@redhat.com>	<1227043890.28543.18.camel@luminos.localdomain>	<49233BE6.3080808@redhat.com>	<1227046097.28543.21.camel@luminos.localdomain>	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>	<49234CE6.7050805@gmail.com>	<604aa7910811181554q238d59ber63bf99565a37558e@mail.gmail.com>	<492359B2.2010008@gmail.com>
	<604aa7910811181622q6d2b7f92kf20853a6c9f8c2f1@mail.gmail.com>
Message-ID: <492378C7.6050408@gmail.com>

Jeff Spaleta wrote:
> On Tue, Nov 18, 2008 at 3:11 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
>> Every time anyone mentions slowing down the feature changes in favor of
>> fixing the brokenness there are a flurry of postings from people saying they
>> want all the new features they can get.
> 
> 
> Are you talking about known brokenness that exists and has been
> reported already.. or new brokenness that we don't know about yet that
> is introduced in updates that our current ability to test failed to
> catch?

There will always be some of both and some large number of real-world 
users are what it takes to sort them out.

> Holding back isn't going to magically help us prevent new
> brokenness of any variety.

No, but it would be nice to have a way to avoid most of the 'new 
brokenness' at times when it might be inconvenient even while others are 
taking advantage (and their chances) with new features.   The kernel 
update late in FC6's life that crashed with many scsi controllers (and 
was quickly fixed) would be a good example of the type of thing that 
could have been avoided on some machines with some mechanism to delay 
updates for a bit on the machines where you care.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Wed Nov 19 02:17:37 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 18 Nov 2008 20:17:37 -0600
Subject: F11 Proposal: Stabilization
In-Reply-To: <1227053994.28543.29.camel@luminos.localdomain>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>	<1226958439.3814.6.camel@localhost.localdomain>	<49232E89.6020400@redhat.com>	<1227043890.28543.18.camel@luminos.localdomain>	<49233BE6.3080808@redhat.com>	<1227046097.28543.21.camel@luminos.localdomain>	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>	<49234CE6.7050805@gmail.com>	<604aa7910811181554q238d59ber63bf99565a37558e@mail.gmail.com>	<492359B2.2010008@gmail.com>
	<1227053994.28543.29.camel@luminos.localdomain>
Message-ID: <49237741.7000807@gmail.com>

Jesse Keating wrote:
> On Tue, 2008-11-18 at 18:11 -0600, Les Mikesell wrote:
>> But, you either need an intermediate repository with 
>> things moved on to the safer one at some point,
> 
> You mean like updates-testing ?

Slightly different.  More like updates and updates-tested.  Something 
you might opt-into after your machine was working the way you want and 
you don't want to take unnecessary chances.  But it might be even better 
to have some sort of per-package risk rating that would go down with age 
unless problems were reported and a per-client choice of how 
bleeding-edge to go.  And packages being pushed to fix security or 
serious known problems could be added with a negative risk rating if the 
packager is sure that it will make things better instead of worse.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From seg at haxxed.com  Wed Nov 19 03:03:44 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 18 Nov 2008 21:03:44 -0600
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <981da310811181555o3b4f0a7die4a4df37a5f7ecba@mail.gmail.com>
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>
	<20081117213116.GA25672@mokona.greysector.net>
	<4922C0D5.4070209@redhat.com> <gfv4jp$abq$1@ger.gmane.org>
	<1227036667.28543.7.camel@luminos.localdomain>
	<981da310811181555o3b4f0a7die4a4df37a5f7ecba@mail.gmail.com>
Message-ID: <1227063824.7387.7.camel@localhost.localdomain>

On Tue, 2008-11-18 at 15:55 -0800, Brennan Ashton wrote:
> I am not advocating one way or another, just wanted to get the voice
> out of one of the few who really knows what is going on behind the
> plugin.

I don't give a crap, I don't want my browser crashing when flash does.
Youtube and Beatport seem to work and that's all I need.

Not to mention you can "killall npviewer.bin" when you want flash to
stop eating all your !@#$ing CPU time.

Well actually it doesn't work ever since I upgraded to F10. I get some
weird selinux denial and the plugin crashes:

node=bigtime type=AVC msg=audit(1227062474.331:276): avc: denied
{ sendto } for pid=8792 comm="npviewer.bin"
scontext=unconfined_u:unconfined_r:nsplugin_t:s0
tcontext=unconfined_u:unconfined_r:nsplugin_t:s0
tclass=unix_dgram_socket

node=bigtime type=SYSCALL msg=audit(1227062474.331:276): arch=c000003e
syscall=44 success=no exit=-13 a0=16 a1=7fffe87a92d0 a2=47 a3=4000
items=0 ppid=30833 pid=8792 auid=500 uid=500 gid=500 euid=500 suid=500
fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1
comm="npviewer.bin" exe="/usr/lib64/nspluginwrapper/npviewer.bin"
subj=unconfined_u:unconfined_r:nsplugin_t:s0 key=(null) 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081118/c8021268/attachment.sig>

From icon at fedoraproject.org  Wed Nov 19 03:07:47 2008
From: icon at fedoraproject.org (Konstantin Ryabitsev)
Date: Tue, 18 Nov 2008 22:07:47 -0500
Subject: Python tb trying to run sugar
Message-ID: <f8f6300f0811181907r1ff8504ambea0bbfb9091c7ab@mail.gmail.com>

Wanted to try running Sugar on my up-to-date F10 install, but it
crashes right away:

Traceback (most recent call last):
  File "/usr/bin/sugar-shell", line 30, in <module>
    from main import main
  File "/usr/share/sugar/shell/main.py", line 32, in <module>
    import view.Shell
  File "/usr/share/sugar/shell/view/Shell.py", line 38, in <module>
    from view.frame import frame
  File "/usr/share/sugar/shell/view/frame/frame.py", line 29, in <module>
    from view.frame.activitiestray import ActivitiesTray
  File "/usr/share/sugar/shell/view/frame/activitiestray.py", line 33,
in <module>
    from model import shellmodel
  File "/usr/share/sugar/shell/model/shellmodel.py", line 24, in <module>
    from model.devices.devicesmodel import DevicesModel
  File "/usr/share/sugar/shell/model/devices/devicesmodel.py", line
25, in <module>
    from model import network
  File "/usr/share/sugar/shell/model/network.py", line 23, in <module>
    from sugar import dispatch
ImportError: cannot import name dispatch

Installed via yum groupinstall "SUGAR Desktop Environment"

Anything obvious that I'm missing?

Cheers,
-- 
Konstantin Ryabitsev
Montr?al, Qu?bec



From lesmikesell at gmail.com  Wed Nov 19 03:09:31 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 18 Nov 2008 21:09:31 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1227057520.4687.45.camel@firewall.xsintricity.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>	<1226593460.13077.91.camel@aglarond.local>	<20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>	<20081113223242.GB4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>	<1226678932.636.40.camel@aglarond.local>	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>	<1226686948.13086.44.camel@aglarond.local>	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>	<1226700116.13086.116.camel@aglarond.local>	<491FBA0E.2070003@gmail.com>	<1227043592.4687.9.camel@firewall.xsintricity.com>	<49234139.1050400@gmail.com>
	<1227057520.4687.45.camel@firewall.xsintricity.com>
Message-ID: <4923836B.1090309@gmail.com>

Doug Ledford wrote:
> >>>   
>>>> But if a system claiming to be new/better can't provide more or less 
>>>> exact emulation of the system it wants to replace, it probably really 
>>>> isn't better.
>>> That statement is based on the incorrect assumption that the way things
>>> used to be is/will be sane for the way things are going.  Sometimes you
>>> just need to do things differently because what we grew up doing just
>>> doesn't work any more.
>> Maybe - when tcp is replaced with some other protocol - or name and 
>> number assignment are no longer parceled out through a hierarchical 
>> process.  Until then, servers need a way to assign  the addresses 
>> manually in ways that are easy to relate to the physical wires that you 
>> plug into them,
> 
> That's not true.  The relating of numbers/names to wires is an arbitrary
> abstraction, and one that need not be the *only* possible abstraction.
> I admit it's handy and common, especially with servers.  And certainly
> you want a server to get the same address from boot to boot, especially
> if it's a live server on the internet with people coming to it (or live
> server on an intranet).  But, the eth0 naming is really
> irrelevant...

It's not irrelevant in the context of a unix-like system where devices 
are identified by name and you want to clone a bazillion copies of a 
machine.

> it's the hardware mac address that matters.

It is now.  In the 2.4 kernel days I could copy a system disk from an 
identical machine, change the hostname and IP address for eth0, eth1, 
etc. and ship a box of them to remote locations where anyone could 
insert them into a chassis and have them come up working.  Now it 
doesn't work and I either have to know every target mac address and 
match up the disks or talk some 'hands-on' operator through the setup 
with a console on a crash cart to get the address assignment done.  Is 
that an improvement?

>  Being able to
> go from wire to mac address matters, and going from mac address to
> configuration matters.  Whether that configuration is called eth0 or
> pr0n_serv0 doesn't really matter.  To use a similar situation that we've
> already changed, back in the day, the only way to mount your root
> filesystem was by device major:minor.  Eventually, we figured out that
> since file systems have unique identifiers, we could screw the
> major:minor pair and mount by label instead.

That sucked too, if you recall what happened when you tried to re-use a 
disk, putting one you had used before into the same chassis as a current 
one.  For the first year or so after this change was made, this scenario 
would result in a machine that _would not even boot_.

> Now, that switch required
> changes to mount, changes to fstab symantics, changes to initrd, etc.
> But, it happened, and I doubt many people would say we are the worse off
> for it.

I do.  My machines often have disks cloned from elsewhere, or that have 
been previously used and have duplicate labels but are not exact copies. 
  I find it hard to believe that this doesn't happen to anyone with a 
reasonable number of machines or who re-uses parts.  I always undo any 
labels the installer puts in fstab so I know what partitions will 
actually be mounted.

> I think there's definitely more to be done before we are ready
> to make the same sort of switch in regards to networking, but I prophesy
> that eventually we will get there and the old days of static ifcfg-eth0
> files may go the way of the dinosaur.

And I think you are entirely off-base in terms of making it harder for 
someone who knows which device is which to actually identify it to the 
OS. I won't say it would be impossible to make things better but so far 
it has just created more work.

>>  and it needs to be done by a person with authorization 
>> passed down the appropriate hierarchy.  It's not something a daemon can 
>> guess at.   If you want to make things easier for people who haven't 
>> already automated their processes, you could build a gui that deals with 
>> with configuring the separate programs that need to be tied together for 
>> related concepts.  That is, you could have a gui form where you fill in 
>> a name, ip, and mac address and have the tool build the forward and 
>> reverse DNS zone entries and either the local interface configuration 
>> tied to that nic or the dhcp entry to assign it to a different machine.
>>
>> For people who have already automated these processes, try not to screw 
>> it up too badly.  If the way it is done now didn't work, we wouldn't 
>> have an internet.
> 
> I'm sure it won't screw existing setups unless there is an overwhelming
> compelling reason.

But the changes you mentioned already have.

>  But, sometimes it's worth letting go of the old way
> of doing things.  And I'm not saying this is even one of those cases,
> just that your statement that it can't be better if it doesn't exactly
> emulate the current way of doing things is a patently false straw man
> and that each case needs to be evaluated individually and objectively.

Please think through the way you would clone a large number of servers, 
particularly when you swap disks around and ship to remote locations 
before you consider some change to be for the better.  Or what happens 
when you take several previously used disks and put them together in the 
same box for one purpose or another.

> For my own purposes, what would make dealing with udev/hal/etc. on a
> server system much easier would be some concise guides in terms of how
> these layers dealt with dynamic devices and how to achieve what you used
> to do with modprobe.conf in udev land for example.  One of the things
> the server SIG can do is come up with exactly that sort of
> documentation.

I don't want dynamic devices on my servers.  I want to know exactly what 
they are and how they are named by the OS.  And I want a hundred of them 
with image-copied disks to all work the same way.  Some tools to deal 
with the changes being made could help with this but so far I haven't 
seen any.

-- 
    Les Mikesell
     lesmikesell at gmail.com




From jkeating at redhat.com  Wed Nov 19 03:15:11 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 18 Nov 2008 19:15:11 -0800
Subject: F11 Proposal: Stabilization
In-Reply-To: <49237741.7000807@gmail.com>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<49234CE6.7050805@gmail.com>
	<604aa7910811181554q238d59ber63bf99565a37558e@mail.gmail.com>
	<492359B2.2010008@gmail.com>
	<1227053994.28543.29.camel@luminos.localdomain>
	<49237741.7000807@gmail.com>
Message-ID: <1227064511.28543.33.camel@luminos.localdomain>

On Tue, 2008-11-18 at 20:17 -0600, Les Mikesell wrote:
> Slightly different.  More like updates and updates-tested.  Something 
> you might opt-into after your machine was working the way you want and 
> you don't want to take unnecessary chances.  But it might be even better 
> to have some sort of per-package risk rating that would go down with age 
> unless problems were reported and a per-client choice of how 
> bleeding-edge to go.  And packages being pushed to fix security or 
> serious known problems could be added with a negative risk rating if the 
> packager is sure that it will make things better instead of worse.

Given that we have a hard enough time keeping things straight and
getting feedback for updates-testing, what makes you think we'll do a
better job by adding a 3rd repo into the mix?  And what are 3rd party
repos supposed to target?

-- 
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/20081118/ce48d798/attachment.sig>

From jkeating at redhat.com  Wed Nov 19 03:16:30 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 18 Nov 2008 19:16:30 -0800
Subject: F11 Proposal: Stabilization
In-Reply-To: <492378C7.6050408@gmail.com>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<49234CE6.7050805@gmail.com>
	<604aa7910811181554q238d59ber63bf99565a37558e@mail.gmail.com>
	<492359B2.2010008@gmail.com>
	<604aa7910811181622q6d2b7f92kf20853a6c9f8c2f1@mail.gmail.com>
	<492378C7.6050408@gmail.com>
Message-ID: <1227064591.28543.34.camel@luminos.localdomain>

On Tue, 2008-11-18 at 20:24 -0600, Les Mikesell wrote:
> 
> No, but it would be nice to have a way to avoid most of the 'new 
> brokenness' at times when it might be inconvenient even while others are 
> taking advantage (and their chances) with new features.   The kernel 
> update late in FC6's life that crashed with many scsi controllers (and 
> was quickly fixed) would be a good example of the type of thing that 
> could have been avoided on some machines with some mechanism to delay 
> updates for a bit on the machines where you care.

So again, why wouldn't people using updates-testing have caught this?
Oh probably because the people who had systems that would have triggered
this bug wouldn't want to use the risky repo.  Which means they would
all fall back to the updates-tested repo you talk about and history
would repeat itself, but maybe then you'd ask for a
updates-tested-no-really-I-mean-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/20081118/81aa7e4c/attachment.sig>

From wtogami at redhat.com  Wed Nov 19 03:18:04 2008
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 18 Nov 2008 22:18:04 -0500
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <1227063824.7387.7.camel@localhost.localdomain>
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>	<20081117213116.GA25672@mokona.greysector.net>	<4922C0D5.4070209@redhat.com>
	<gfv4jp$abq$1@ger.gmane.org>	<1227036667.28543.7.camel@luminos.localdomain>	<981da310811181555o3b4f0a7die4a4df37a5f7ecba@mail.gmail.com>
	<1227063824.7387.7.camel@localhost.localdomain>
Message-ID: <4923856C.5030509@redhat.com>

Callum Lerwick wrote:
> On Tue, 2008-11-18 at 15:55 -0800, Brennan Ashton wrote:
>> I am not advocating one way or another, just wanted to get the voice
>> out of one of the few who really knows what is going on behind the
>> plugin.
> 
> I don't give a crap, I don't want my browser crashing when flash does.
> Youtube and Beatport seem to work and that's all I need.
> 
> Not to mention you can "killall npviewer.bin" when you want flash to
> stop eating all your !@#$ing CPU time.
> 
> Well actually it doesn't work ever since I upgraded to F10. I get some
> weird selinux denial and the plugin crashes:
> 
> node=bigtime type=AVC msg=audit(1227062474.331:276): avc: denied
> { sendto } for pid=8792 comm="npviewer.bin"
> scontext=unconfined_u:unconfined_r:nsplugin_t:s0
> tcontext=unconfined_u:unconfined_r:nsplugin_t:s0
> tclass=unix_dgram_socket
> 
> node=bigtime type=SYSCALL msg=audit(1227062474.331:276): arch=c000003e
> syscall=44 success=no exit=-13 a0=16 a1=7fffe87a92d0 a2=47 a3=4000
> items=0 ppid=30833 pid=8792 auid=500 uid=500 gid=500 euid=500 suid=500
> fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1
> comm="npviewer.bin" exe="/usr/lib64/nspluginwrapper/npviewer.bin"
> subj=unconfined_u:unconfined_r:nsplugin_t:s0 key=(null) 
> 

restorecon -R /usr/lib64/mozilla/plugins/

Any better?

Warren



From cmadams at hiwaay.net  Wed Nov 19 03:20:03 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 18 Nov 2008 21:20:03 -0600
Subject: Rawhide boot failure (2008-11-15)
In-Reply-To: <20081115213208.GA883445@hiwaay.net>
References: <20081115213208.GA883445@hiwaay.net>
Message-ID: <20081119032003.GA1375334@hiwaay.net>

Once upon a time, Chris Adams <cmadams at hiwaay.net> said:
> Is it just me, or does today's i386 rawhide not boot?  I tried booting
> from boot.iso in a KVM and PXE booting, and in both cases I get:
> 
> Failed to execute /init
> Kernel panic - not syncing: No init found.  Try passing init= option to kernel.

Am I the only one seeing this?  I still get this trying to boot from
rawhide-i386 boot.iso (2008-11-18).
-- 
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 ivazqueznet at gmail.com  Wed Nov 19 03:20:49 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Tue, 18 Nov 2008 22:20:49 -0500
Subject: Python tb trying to run sugar
In-Reply-To: <f8f6300f0811181907r1ff8504ambea0bbfb9091c7ab@mail.gmail.com>
References: <f8f6300f0811181907r1ff8504ambea0bbfb9091c7ab@mail.gmail.com>
Message-ID: <1227064849.736.72.camel@ignacio.lan>

On Tue, 2008-11-18 at 22:07 -0500, Konstantin Ryabitsev wrote:
> Wanted to try running Sugar on my up-to-date F10 install, but it
> crashes right away:

> ImportError: cannot import name dispatch
> 
> Installed via yum groupinstall "SUGAR Desktop Environment"
> 
> Anything obvious that I'm missing?

Nope. Someone forgot a dep on python-ruledispatch.

-- 
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/20081118/07aaf25a/attachment.sig>

From katzj at redhat.com  Wed Nov 19 03:26:58 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 18 Nov 2008 22:26:58 -0500
Subject: Rawhide boot failure (2008-11-15)
In-Reply-To: <20081119032003.GA1375334@hiwaay.net>
References: <20081115213208.GA883445@hiwaay.net>
	<20081119032003.GA1375334@hiwaay.net>
Message-ID: <1227065218.13047.8.camel@aglarond.local>

On Tue, 2008-11-18 at 21:20 -0600, Chris Adams wrote:
> Once upon a time, Chris Adams <cmadams at hiwaay.net> said:
> > Is it just me, or does today's i386 rawhide not boot?  I tried booting
> > from boot.iso in a KVM and PXE booting, and in both cases I get:
> > 
> > Failed to execute /init
> > Kernel panic - not syncing: No init found.  Try passing init= option to kernel.
> 
> Am I the only one seeing this?  I still get this trying to boot from
> rawhide-i386 boot.iso (2008-11-18).

No, it was seen and fixed up this morning

Jeremy



From icon at fedoraproject.org  Wed Nov 19 03:31:59 2008
From: icon at fedoraproject.org (Konstantin Ryabitsev)
Date: Tue, 18 Nov 2008 22:31:59 -0500
Subject: Python tb trying to run sugar
In-Reply-To: <1227064849.736.72.camel@ignacio.lan>
References: <f8f6300f0811181907r1ff8504ambea0bbfb9091c7ab@mail.gmail.com>
	<1227064849.736.72.camel@ignacio.lan>
Message-ID: <f8f6300f0811181931k58e825c6udc4bca9625bceac0@mail.gmail.com>

2008/11/18 Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> On Tue, 2008-11-18 at 22:07 -0500, Konstantin Ryabitsev wrote:
>> Wanted to try running Sugar on my up-to-date F10 install, but it
>> crashes right away:
>
>> ImportError: cannot import name dispatch
>>
>> Installed via yum groupinstall "SUGAR Desktop Environment"
>>
>> Anything obvious that I'm missing?
>
> Nope. Someone forgot a dep on python-ruledispatch.

I don't think that's it -- the actual line is "from sugar import
dispatch", not just "import dispatch". It seems that a chunk of sugar
is missing (or something). "yum provides
/usr/lib/python2.5/site-packages/sugar/dispatch.py" doesn't find
anything, so I think something got left out.


-- 
Konstantin Ryabitsev
Montr?al, Qu?bec



From bruno at wolff.to  Wed Nov 19 04:20:22 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Tue, 18 Nov 2008 22:20:22 -0600
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <981da310811181555o3b4f0a7die4a4df37a5f7ecba@mail.gmail.com>
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>
	<20081117213116.GA25672@mokona.greysector.net>
	<4922C0D5.4070209@redhat.com> <gfv4jp$abq$1@ger.gmane.org>
	<1227036667.28543.7.camel@luminos.localdomain>
	<981da310811181555o3b4f0a7die4a4df37a5f7ecba@mail.gmail.com>
Message-ID: <20081119042022.GA19589@wolff.to>

On Tue, Nov 18, 2008 at 15:55:02 -0800,
  Brennan Ashton <bashton at brennanashton.com> wrote:
> needs to be transfered through IPC channels. I hope that browser
> vendors will eventually come up with a better architecture to wrap
> plugins without sacrificing performance, stability and functionality.

How about getting the people in charge of deciding what format to publish
content in, to not use crappy, security hole ridden, propietary formats.



From bruno at wolff.to  Wed Nov 19 04:20:22 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Tue, 18 Nov 2008 22:20:22 -0600
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <981da310811181555o3b4f0a7die4a4df37a5f7ecba@mail.gmail.com>
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>
	<20081117213116.GA25672@mokona.greysector.net>
	<4922C0D5.4070209@redhat.com> <gfv4jp$abq$1@ger.gmane.org>
	<1227036667.28543.7.camel@luminos.localdomain>
	<981da310811181555o3b4f0a7die4a4df37a5f7ecba@mail.gmail.com>
Message-ID: <20081119042022.GA19589@wolff.to>

On Tue, Nov 18, 2008 at 15:55:02 -0800,
  Brennan Ashton <bashton at brennanashton.com> wrote:
> needs to be transfered through IPC channels. I hope that browser
> vendors will eventually come up with a better architecture to wrap
> plugins without sacrificing performance, stability and functionality.

How about getting the people in charge of deciding what format to publish
content in, to not use crappy, security hole ridden, propietary formats.



From rc040203 at freenet.de  Wed Nov 19 04:49:45 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 19 Nov 2008 05:49:45 +0100
Subject: F11 Proposal: Stabilization
In-Reply-To: <alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
Message-ID: <1227070185.3752.639.camel@beck.corsepiu.local>

On Tue, 2008-11-18 at 17:12 -0500, Seth Vidal wrote:
> 
> On Tue, 18 Nov 2008, Jesse Keating wrote:
> 
> > On Tue, 2008-11-18 at 17:04 -0500, Michael DeHaan wrote:
> >>> Couldn't both the above be solved by 'subscribing' to those sets of
> >>> packages via say PackageKit?  That way when PackageKit goes to look for
> >>> updates, it only asks for updates for those particular packages.  When
> >>> you update, if anything else is needed to satisfy newer builds of those
> >>> packages they can be pulled in.
> >>>
> >>> Of course, what we'd likely see is a combo of "Give me all security
> >>> updates" and also "Give me updates only for these sets of packages".
> >>> The interesting question is how to design UI around the subscriptions.
> >>>
> >>>
> >>
> >> I think I like this.
> >>
> >> In the case of "I just want a newer OpenOffice" and don't touch
> >> everything else, that's already covered by a yum install today -- but we
> >> do need something for the update case(s).
> >
> > The upside here is that it's purely client side code.  We don't have to
> > change anything about how we prepare and publish updates.

> or you want to list a set of apps you want newer versions of and as little 
> else as possible?

> yum update really means yum update openoffice\* somestuff\*  \
>       my_favorite_pkg\*
I feel, you just discovered what apt/apt-get calls "package pinning"

Ralf




From sundaram at fedoraproject.org  Wed Nov 19 04:59:30 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 19 Nov 2008 10:29:30 +0530
Subject: F11 Proposal: Stabilization
In-Reply-To: <1227070185.3752.639.camel@beck.corsepiu.local>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>	<1226958439.3814.6.camel@localhost.localdomain>	<49232E89.6020400@redhat.com>	<1227043890.28543.18.camel@luminos.localdomain>	<49233BE6.3080808@redhat.com>	<1227046097.28543.21.camel@luminos.localdomain>	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<1227070185.3752.639.camel@beck.corsepiu.local>
Message-ID: <49239D32.6070407@fedoraproject.org>

Ralf Corsepius wrote:

> I feel, you just discovered what apt/apt-get calls "package pinning"

You got to give people more credit than that. First hit on "yum pinning" 
leads to

https://lists.dulug.duke.edu/pipermail/yum/2003-August/001730.html

Also look up versionlock plugin in Yum.

Rahul



From lesmikesell at gmail.com  Wed Nov 19 05:14:24 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 18 Nov 2008 23:14:24 -0600
Subject: F11 Proposal: Stabilization
In-Reply-To: <1227064511.28543.33.camel@luminos.localdomain>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>	<1226958439.3814.6.camel@localhost.localdomain>	<49232E89.6020400@redhat.com>	<1227043890.28543.18.camel@luminos.localdomain>	<49233BE6.3080808@redhat.com>	<1227046097.28543.21.camel@luminos.localdomain>	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>	<49234CE6.7050805@gmail.com>	<604aa7910811181554q238d59ber63bf99565a37558e@mail.gmail.com>	<492359B2.2010008@gmail.com>	<1227053994.28543.29.camel@luminos.localdomain>	<49237741.7000807@gmail.com>
	<1227064511.28543.33.camel@luminos.localdomain>
Message-ID: <4923A0B0.20608@gmail.com>

Jesse Keating wrote:
> On Tue, 2008-11-18 at 20:17 -0600, Les Mikesell wrote:
>> Slightly different.  More like updates and updates-tested.  Something 
>> you might opt-into after your machine was working the way you want and 
>> you don't want to take unnecessary chances.  But it might be even better 
>> to have some sort of per-package risk rating that would go down with age 
>> unless problems were reported and a per-client choice of how 
>> bleeding-edge to go.  And packages being pushed to fix security or 
>> serious known problems could be added with a negative risk rating if the 
>> packager is sure that it will make things better instead of worse.
> 
> Given that we have a hard enough time keeping things straight and
> getting feedback for updates-testing, what makes you think we'll do a
> better job by adding a 3rd repo into the mix?  And what are 3rd party
> repos supposed to target?

So what about the risk-factor rating concept?  Suppose users had an 
option that would ignore updates for about a week, then take them if 
there were no new bugzilla reports, longer if there were, with 
everything in one repo and some override options for special 
circumstances?  3rd party repos could match the technique or not. 
Updates  or installs of new packages that would pull dependencies higher 
than your acceptable risk factor could just fail.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jkeating at redhat.com  Wed Nov 19 05:24:14 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 18 Nov 2008 21:24:14 -0800
Subject: F11 Proposal: Stabilization
In-Reply-To: <4923A0B0.20608@gmail.com>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<49234CE6.7050805@gmail.com>
	<604aa7910811181554q238d59ber63bf99565a37558e@mail.gmail.com>
	<492359B2.2010008@gmail.com>
	<1227053994.28543.29.camel@luminos.localdomain>
	<49237741.7000807@gmail.com>
	<1227064511.28543.33.camel@luminos.localdomain>
	<4923A0B0.20608@gmail.com>
Message-ID: <1227072254.28543.50.camel@luminos.localdomain>

On Tue, 2008-11-18 at 23:14 -0600, Les Mikesell wrote:
> So what about the risk-factor rating concept?  Suppose users had an 
> option that would ignore updates for about a week, then take them if 
> there were no new bugzilla reports, longer if there were, with 
> everything in one repo and some override options for special 
> circumstances?  3rd party repos could match the technique or not. 
> Updates  or installs of new packages that would pull dependencies higher 
> than your acceptable risk factor could just fail.

That makes it somewhat easier infrastructure wise, would be interesting
to see what kind of states that would leave a user in.  Whip up a yum
plugin and see what happens.

-- 
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/20081118/85a6f8a6/attachment.sig>

From rc040203 at freenet.de  Wed Nov 19 05:36:38 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 19 Nov 2008 06:36:38 +0100
Subject: F11 Proposal: Stabilization
In-Reply-To: <49239D32.6070407@fedoraproject.org>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<1227070185.3752.639.camel@beck.corsepiu.local>
	<49239D32.6070407@fedoraproject.org>
Message-ID: <1227072998.3752.643.camel@beck.corsepiu.local>

On Wed, 2008-11-19 at 10:29 +0530, Rahul Sundaram wrote:
> Ralf Corsepius wrote:
> 
> > I feel, you just discovered what apt/apt-get calls "package pinning"
> 
> You got to give people more credit than that. First hit on "yum pinning" 
> leads to
> 
> https://lists.dulug.duke.edu/pipermail/yum/2003-August/001730.html
And? Nothing new.

> Also look up versionlock plugin in Yum.
apt's pinning is much more than version locking.




From sundaram at fedoraproject.org  Wed Nov 19 06:04:23 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 19 Nov 2008 11:34:23 +0530
Subject: F11 Proposal: Stabilization
In-Reply-To: <1227072998.3752.643.camel@beck.corsepiu.local>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>	<1226958439.3814.6.camel@localhost.localdomain>	<49232E89.6020400@redhat.com>	<1227043890.28543.18.camel@luminos.localdomain>	<49233BE6.3080808@redhat.com>	<1227046097.28543.21.camel@luminos.localdomain>	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>	<1227070185.3752.639.camel@beck.corsepiu.local>	<49239D32.6070407@fedoraproject.org>
	<1227072998.3752.643.camel@beck.corsepiu.local>
Message-ID: <4923AC67.5010606@fedoraproject.org>

Ralf Corsepius wrote:
> On Wed, 2008-11-19 at 10:29 +0530, Rahul Sundaram wrote:
>> Ralf Corsepius wrote:
>>
>>> I feel, you just discovered what apt/apt-get calls "package pinning"
>> You got to give people more credit than that. First hit on "yum pinning" 
>> leads to
>>
>> https://lists.dulug.duke.edu/pipermail/yum/2003-August/001730.html
> And? Nothing new.

Yes, it not a new discovery which is my point.

Rahul









From fedora at shmuelhome.mine.nu  Wed Nov 19 08:03:12 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Wed, 19 Nov 2008 10:03:12 +0200
Subject: F11 Proposal: Stabilization
In-Reply-To: <1227064591.28543.34.camel@luminos.localdomain>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>	<1226958439.3814.6.camel@localhost.localdomain>	<49232E89.6020400@redhat.com>	<1227043890.28543.18.camel@luminos.localdomain>	<49233BE6.3080808@redhat.com>	<1227046097.28543.21.camel@luminos.localdomain>	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>	<49234CE6.7050805@gmail.com>	<604aa7910811181554q238d59ber63bf99565a37558e@mail.gmail.com>	<492359B2.2010008@gmail.com>	<604aa7910811181622q6d2b7f92kf20853a6c9f8c2f1@mail.gmail.com>	<492378C7.6050408@gmail.com>
	<1227064591.28543.34.camel@luminos.localdomain>
Message-ID: <4923C840.30101@shmuelhome.mine.nu>

Jesse Keating wrote:
> On Tue, 2008-11-18 at 20:24 -0600, Les Mikesell wrote:
>   
>> No, but it would be nice to have a way to avoid most of the 'new 
>> brokenness' at times when it might be inconvenient even while others are 
>> taking advantage (and their chances) with new features.   The kernel 
>> update late in FC6's life that crashed with many scsi controllers (and 
>> was quickly fixed) would be a good example of the type of thing that 
>> could have been avoided on some machines with some mechanism to delay 
>> updates for a bit on the machines where you care.
>>     
>
> So again, why wouldn't people using updates-testing have caught this?
> Oh probably because the people who had systems that would have triggered
> this bug wouldn't want to use the risky repo.  Which means they would
> all fall back to the updates-tested repo you talk about and history
> would repeat itself, but maybe then you'd ask for a
> updates-tested-no-really-I-mean-it
>
>   
I am not sure that you are right. The audience for updates tested might 
very well be bigger than the one for updates testing. For example, I 
always started using rawhide at test2, never at test1. Test1 was viewed 
as pre-alpha and just too raw for someone who wanted a system that 
basically worked but had some bugs.



From stransky at redhat.com  Wed Nov 19 08:21:27 2008
From: stransky at redhat.com (Martin Stransky)
Date: Wed, 19 Nov 2008 09:21:27 +0100
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <49233F0A.7040408@conversis.de>
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>	<20081117213116.GA25672@mokona.greysector.net>	<4922C0D5.4070209@redhat.com>	<gfv4jp$abq$1@ger.gmane.org>	<1227036667.28543.7.camel@luminos.localdomain>	<49231B6B.20809@conversis.de>	<604aa7910811181152k6202a49bi70e6c2c227ca0703@mail.gmail.com>	<49232CBD.9070008@conversis.de>	<4923343A.3080007@redhat.com>
	<49233F0A.7040408@conversis.de>
Message-ID: <4923CC87.5090108@redhat.com>

Dennis J. wrote:
> But that's the point. For quite a few people browser stability actually 
> *decreases* when nspluginwrapper is installed.

Please file bugzilla bug when you find a page where browser crashes 
because of nspluginwrapper. I'll happily debug it.



From stransky at redhat.com  Wed Nov 19 08:28:26 2008
From: stransky at redhat.com (Martin Stransky)
Date: Wed, 19 Nov 2008 09:28:26 +0100
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <981da310811181555o3b4f0a7die4a4df37a5f7ecba@mail.gmail.com>
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>	<20081117213116.GA25672@mokona.greysector.net>	<4922C0D5.4070209@redhat.com>
	<gfv4jp$abq$1@ger.gmane.org>	<1227036667.28543.7.camel@luminos.localdomain>
	<981da310811181555o3b4f0a7die4a4df37a5f7ecba@mail.gmail.com>
Message-ID: <4923CE2A.9020707@redhat.com>

Brennan Ashton wrote:
> 2008/11/18 Jesse Keating <jkeating at redhat.com>:
>> On Tue, 2008-11-18 at 14:21 -0500, Neal Becker wrote:
>>> Should nspluginwrapper be banned from wrapping this?  If so, should
>>> this be included in flash-plugin.spec?
>> Oh, I'm pretty sure you still want to keep flash separated from your
>> browser, regardless of the arch.
> 
> Not according to the developer of the 64bit plugin.
> 
> "
> Talking about nspluginwrapper: I strongly suggest not to use it. I
> know that some distros are thinking of even wrapping 64-bit plugins
> including Ubuntu with the thought that it will improve security and
> stability of the browser. This is a very bad idea in the state
> nspluginwrapper is in today. We have done some internal testing and
> discovered that several features in the Flash Player are broken when
> the plugin is wrapped. More importantly performance and user
> experience is pretty bad when the plugin is wrapped. Why? Lots of data
> needs to be transfered through IPC channels. I hope that browser
> vendors will eventually come up with a better architecture to wrap
> plugins without sacrificing performance, stability and functionality.
> "
> http://www.kaourantin.net/2008/11/64-bits.html
> 
> 
> I am not advocating one way or another, just wanted to get the voice
> out of one of the few who really knows what is going on behind the
> plugin.

For instance, NPAPI plugins can share memory with browser and operate 
with internal browser memory (like DOM tree) and this "feature" is 
blocked by nspluginwrapper because of it's simple architecture.

Full browser-side emulation will be extremely complex and is close to 
chrome model where one process holds one browser page...

ma.




From benny+usenet at amorsen.dk  Wed Nov 19 08:37:56 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Wed, 19 Nov 2008 09:37:56 +0100
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <20081119042022.GA19589@wolff.to> (Bruno Wolff,
	III's message of "Tue\, 18 Nov 2008 22\:20\:22 -0600")
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>
	<20081117213116.GA25672@mokona.greysector.net>
	<4922C0D5.4070209@redhat.com> <gfv4jp$abq$1@ger.gmane.org>
	<1227036667.28543.7.camel@luminos.localdomain>
	<981da310811181555o3b4f0a7die4a4df37a5f7ecba@mail.gmail.com>
	<20081119042022.GA19589@wolff.to>
Message-ID: <m3fxloqfff.fsf@ursa.amorsen.dk>

Bruno Wolff III <bruno at wolff.to> writes:

> How about getting the people in charge of deciding what format to publish
> content in, to not use crappy, security hole ridden, propietary formats.

The main competitors are Java and Silverlight. Neither seems
particularly appealing.

Some things you can replace with either plain embedded video or AJAX,
but not everything.


/Benny



From christof at damian.net  Wed Nov 19 08:50:53 2008
From: christof at damian.net (Christof Damian)
Date: Wed, 19 Nov 2008 09:50:53 +0100
Subject: F11 Proposal: Stabilization
In-Reply-To: <1227020349.4355.116.camel@code.and.org>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<20081117213742.GB5603@nostromo.devel.redhat.com>
	<4921E683.30407@redhat.com>
	<604aa7910811171354h26c8eb30r72280cc95ba9a976@mail.gmail.com>
	<1226960219.4098.20.camel@perihelion.bos.jonmasters.org>
	<49226383.3010800@leemhuis.info>
	<1227020349.4355.116.camel@code.and.org>
Message-ID: <f7c6719a0811190050x1ecc4fesbbaad531fb9fbaa2@mail.gmail.com>

On Tue, Nov 18, 2008 at 15:59, James Antill <james at fedoraproject.org> wrote:
>
>  Indeed, and someone else wants the latest transmission and someone else
> the latest pidgin and someone else...
>  So you either need 100x distributions, or the latest stuff of
> everything.
>
>> > I would personally much
>> > prefer that stuff that used to work didn't break randomly, and that
>> > stable Fedora updates wouldn't result in me wondering whether suspend,
>> > graphics, SELinux, or some other feature that was working was going to
>> > break today. This isn't actually a rant, more pointing out a necessity.
>>
>> Agreed, but I tend to say we should work towards a solution where we can
>> ship the "latest bells and whistles" and nevertheless provide stability.

What I would like is that updates for the current fedora release only
contain security fixes. updates/9/SRPMS.newkey currently contains 2257
files, which seems to be too much. It also means that a lot of new
features which will be in f10 already trickled down to f9.

During fedora 9 I had these things breaking: sound, keyboard / mouse
combination, wlan and rhgb. Probably more I can't remember. My guess
is that every fedora user is by now used to do "rpm --oldversion ..."
and going to bugzilla first to check for bug reports of the day.

If someone really wants to live on the edge he can always (and
probably already does) use rawhide.

It also would make me look forward to fedora 10 even more because it
would give me a lot more new stuff.

Christof



From kevin.kofler at chello.at  Wed Nov 19 09:08:28 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 19 Nov 2008 10:08:28 +0100
Subject: Proposal - "Slow updates" repo
References: <49230F31.4030409@redhat.com> <4923104D.5080604@herr-schmitt.de>
	<49231142.9010804@redhat.com>
	<604aa7910811181106n3b30d9b5nbdef29ad334bda92@mail.gmail.com>
	<49231348.2060700@redhat.com>
	<alpine.LFD.2.00.0811181413520.1236@localhost.localdomain>
Message-ID: <gg0l2d$e9l$1@ger.gmane.org>

Seth Vidal wrote:
> you mean like the already existing yum security plugin and the update info
> that bodhi generates?

Except it just doesn't work... 2 big problems there:
1. Security updates can be obsoleted by non-security updates. So if you
didn't install the security update in time, you'll never get it.
2. Sometimes security updates cause regressions. Usually these are fixed
very quickly... in a regular bugfix update. With the result that users of
yum-security will be stuck with the regression (or if they didn't update in
time, with situation 1., i.e. without the security update).

To solve 2., fixes for regressions from security updates would have to be
marked security as well, or (probably better) use a new category ("bugfix
for security update") which is also pulled in by yum-security.

To solve 1., the metadata would have to carry the information for the
security update even after it is obsoleted, and yum-security would have to
understand that if foo-1.2.3 is a security update, the currently installed
package is foo-1.2.2 and the current version in the repo is the bugfix
update foo-1.2.4, it should install foo-1.2.4. Or alternatively, the latest
security (or "bugfix for security", see above) update would have to be
carried in the repos in addition to the latest overall.

In its current state, yum-security is very unreliable and outright
dangerous.

An additional issue is that updates are rarely tested in isolation. Usually,
packagers and testers are up to date with all their packages. And it
happens quite a few times that an update to one package uncovers a bug in
another package, which is then (or ideally, at the same time, using a
grouped update) fixed by an update to that other package. (For example, K3b
crashed after a KDE 3.4->3.5 upgrade and needed to be updated, likewise for
KTorrent and KDE 4.0->4.1. KDE upgrades are normally backwards-compatible
(and thus the soname mechanism won't drag in application updates), but
sometimes they trigger bugs in individual applications. But there are many
examples of this problem outside of KDE as well.) This is why all RHL
updates used to carry the following notice:
> Before applying this update, make sure all previously released errata
> relevant to your system have been applied.
which is still sound advice.

        Kevin Kofler



From benny+usenet at amorsen.dk  Wed Nov 19 09:23:00 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Wed, 19 Nov 2008 10:23:00 +0100
Subject: F11 Proposal: Stabilization
In-Reply-To: <1227064591.28543.34.camel@luminos.localdomain> (Jesse Keating's
	message of "Tue\, 18 Nov 2008 19\:16\:30 -0800")
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<49234CE6.7050805@gmail.com>
	<604aa7910811181554q238d59ber63bf99565a37558e@mail.gmail.com>
	<492359B2.2010008@gmail.com>
	<604aa7910811181622q6d2b7f92kf20853a6c9f8c2f1@mail.gmail.com>
	<492378C7.6050408@gmail.com>
	<1227064591.28543.34.camel@luminos.localdomain>
Message-ID: <m38wrgqdcb.fsf@ursa.amorsen.dk>

Jesse Keating <jkeating at redhat.com> writes:

> So again, why wouldn't people using updates-testing have caught this?
> Oh probably because the people who had systems that would have triggered
> this bug wouldn't want to use the risky repo.  Which means they would
> all fall back to the updates-tested repo you talk about and history
> would repeat itself, but maybe then you'd ask for a
> updates-tested-no-really-I-mean-it

I would be willing to run with updates-testing on by default on
several machines if I was sure that faulty packages didn't just go
away. The problem is that you're stuck with the upgraded package which
turned out to be buggy, unless you do something manually to get rid of
it. The alternative is to reissue the original package with a higher
evra.

I don't have a good solution for this problem. As it is I just test
packages which are directly relevant to my systems, and that is not
very many packages.


/Benny



From fedora at shmuelhome.mine.nu  Wed Nov 19 09:38:44 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Wed, 19 Nov 2008 11:38:44 +0200
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <4923CE2A.9020707@redhat.com>
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>	<20081117213116.GA25672@mokona.greysector.net>	<4922C0D5.4070209@redhat.com>	<gfv4jp$abq$1@ger.gmane.org>	<1227036667.28543.7.camel@luminos.localdomain>	<981da310811181555o3b4f0a7die4a4df37a5f7ecba@mail.gmail.com>
	<4923CE2A.9020707@redhat.com>
Message-ID: <4923DEA4.5080509@shmuelhome.mine.nu>

Martin Stransky wrote:
> For instance, NPAPI plugins can share memory with browser and operate 
> with internal browser memory (like DOM tree) and this "feature" is 
> blocked by nspluginwrapper because of it's simple architecture.
>
> Full browser-side emulation will be extremely complex and is close to 
> chrome model where one process holds one browser page...
>
> ma.
>
 From both a security and privacy point of view you actually want to 
sandbox plugins. Many of the security fixes to IE over the past 3 years 
(which weren't pure bug fixes) was to limit what you can do from 
javascript. The last thing that you want to do is to give a scripting 
engine unbridled access to the DOM tree and the browser's internal 
memory. The chrome model does not solve this problem.





From rjones at redhat.com  Wed Nov 19 09:59:02 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 19 Nov 2008 09:59:02 +0000
Subject: ANNOUNCE: Smock (simpler mock) - a mock wrapper for chain
	building
In-Reply-To: <200811190039.47991.opensource@till.name>
References: <20081118174907.GA27568@amd.home.annexia.org>
	<200811190039.47991.opensource@till.name>
Message-ID: <20081119095902.GA31559@amd.home.annexia.org>

On Wed, Nov 19, 2008 at 12:39:43AM +0100, Till Maas wrote:
> Sadly it seems not to work with only srpm or if the only BRs that several 
> srpms connect are of the type "%{name}-devel", because it seems to assume 
> that every srpm only provides it's name as a package.

Ah yes, should be easy to fix.  It didn't affect any mingw32 packages
as it happens because they don't use -devel.

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 fedora at matbooth.co.uk  Wed Nov 19 10:20:12 2008
From: fedora at matbooth.co.uk (Mat Booth)
Date: Wed, 19 Nov 2008 10:20:12 +0000
Subject: Proposal - "Slow updates" repo
In-Reply-To: <20081118212221.GB3459@x300.bos.redhat.com>
References: <49230F31.4030409@redhat.com>
	<20081118212221.GB3459@x300.bos.redhat.com>
Message-ID: <9497e9990811190220i1301f5d1t24b1c88e7cb0d90c@mail.gmail.com>

On Tue, Nov 18, 2008 at 9:22 PM, Luke Macken <lmacken at redhat.com> wrote:
> So, how do we minimize that breakage?
>
>    - Ensure that new features are tested, by humans and ideally a test suite.

I have a brief test plan for some of my packages on my wiki page:
https://fedoraproject.org/wiki/User:Mbooth#Package_Maintenance

Although it's more of a personal /aide memoire/ rather than actual
test procedure, I'm sure it would also be useful to others who are
interested in testing my packages. It only takes a few minutes to go
through and if any of the things on that list do not work, I consider
it a bug. :-)

Would it be useful to mandate that maintainers provide a similar test
plan for all packages going through updates-testing in order to make
sure all the features are covered?

-- 
Mat Booth
www.matbooth.co.uk



From karsten at redhat.com  Wed Nov 19 11:14:36 2008
From: karsten at redhat.com (Karsten Hopp)
Date: Wed, 19 Nov 2008 12:14:36 +0100
Subject: Plan for tomorrows (20081119) FESCO meeting
In-Reply-To: <1227044895.28822.10.camel@kennedy>
References: <1227044895.28822.10.camel@kennedy>
Message-ID: <4923F51C.90700@redhat.com>

Brian Pepple schrieb:
> 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 - F11/F12 Schedule -
> https://www.redhat.com/archives/fedora-advisory-board/2008-November/msg00037.html - f13, all
> 
> /topic FESCO-Meeting -- Features --
> https://fedoraproject.org/wiki/Features/DeviceKit 
> 
> /topic FESCO-Meeting -- Features --
> https://fedoraproject.org/wiki/Features/VolumeControl
> 
> /topic FESCO-Meeting -- Features --
> https://fedoraproject.org/wiki/Features/Windows_cross_compiler
> 
> /topic FESCO-Meeting -- Features -- pushed from F10 to F11
> https://fedoraproject.org/wiki/Features/Presto -- everything still
> relevant?
> 
> /topic FESCO-Meeting -- Features
> --https://fedoraproject.org/wiki/Features/Multiseat
> 
> /topic FESCo-Meeting - Fedora representative to LSB? -
> https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00763.html - bpepple
> 
> /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
> 

Can we take a look at bugzillas 461926 and 472061 ? This can get us into lots of trouble
and I think we should have a policy that such a behaviour needs to be patched out/disabled
from any binaries shipped with Fedora.

    Karsten



From dan at danny.cz  Wed Nov 19 11:34:10 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Wed, 19 Nov 2008 12:34:10 +0100
Subject: Plan for tomorrows (20081119) FESCO meeting
In-Reply-To: <4923F51C.90700@redhat.com>
References: <1227044895.28822.10.camel@kennedy>  <4923F51C.90700@redhat.com>
Message-ID: <1227094450.3640.19.camel@eagle.danny.cz>


Karsten Hopp p??e v St 19. 11. 2008 v 12:14 +0100:
> Brian Pepple schrieb:
> > 
> > /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
> > 
> 
> Can we take a look at bugzillas 461926 and 472061 ? This can get us into lots of trouble
> and I think we should have a policy that such a behaviour needs to be patched out/disabled
> from any binaries shipped with Fedora.

I think we can use
https://fedoraproject.org/wiki/Packaging/Guidelines#Code_Vs_Content


		Dan




From ndbecker2 at gmail.com  Wed Nov 19 12:16:13 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Wed, 19 Nov 2008 07:16:13 -0500
Subject: Adobe Releases 64bit Flash Plugin for Linux
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>
	<20081117213116.GA25672@mokona.greysector.net>
	<4922C0D5.4070209@redhat.com> <gfv4jp$abq$1@ger.gmane.org>
	<1227036667.28543.7.camel@luminos.localdomain>
	<49231B6B.20809@conversis.de>
	<604aa7910811181152k6202a49bi70e6c2c227ca0703@mail.gmail.com>
	<49232CBD.9070008@conversis.de> <4923343A.3080007@redhat.com>
	<49233F0A.7040408@conversis.de> <4923CC87.5090108@redhat.com>
Message-ID: <gg102d$get$1@ger.gmane.org>

Martin Stransky wrote:

> Dennis J. wrote:
>> But that's the point. For quite a few people browser stability actually
>> *decreases* when nspluginwrapper is installed.
> 
> Please file bugzilla bug when you find a page where browser crashes
> because of nspluginwrapper. I'll happily debug it.
> 

Here's a bit of nspluginwrapper strangeness.  In /usr/lib/mozilla/plugins-wrapped I have:

 nswrapper_32_32.libflashplayer.so (file, not a link)

Even though I have removed libflashplayer.so 32-bit.  There is no flash in /usr/lib/mozilla/plugins.

I have re-rerun mozilla-plugin-config -c -v.  It doesn't even mention the above file.  There is nothing in /etc/sysconfig/nspluginwrapper telling it to ignore this.  I thought after uninstalling flash 32bit and re-running mozilla-plugin-config it would clean up the old wrapper.



From rawhide at fedoraproject.org  Wed Nov 19 14:33:46 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Wed, 19 Nov 2008 14:33:46 +0000 (UTC)
Subject: rawhide report: 20081119 changes
Message-ID: <20081119143346.D06891F8252@releng2.fedora.phx.redhat.com>

Compose started at Wed Nov 19 06:01:10 UTC 2008

Updated Packages:

anaconda-11.4.1.61-1
--------------------
* Tue Nov 18 17:00:00 2008 Jeremy Katz <katzj at redhat.com> - 11.4.1.61-1
- Fix death on login of an OLPC on a live image (#472097)

* Tue Nov 18 17:00:00 2008 Chris Lumens <clumens at redhat.com> - 11.4.1.60-1
- Fix ld-*.so globbing for glibc-2.9. (pjones)


booty-0.107-1.fc10
------------------
* Tue Nov 18 17:00:00 2008 Peter Jones <pjones at redhat.com> - 0.107-1
- Fix an inverted test in the logic in the fix for #468526

* Tue Nov 18 17:00:00 2008 Peter Jones <pjones at redhat.com> - 0.106-1
- Set the grub.conf timeout to 5 if we're using serial console (#468461)
- Remove chaintimeout in favor of setting the normal timeout if we've got
  chainloader entries (#468526)


dbus-glib-0.76-3.fc10
---------------------
* Mon Nov 17 17:00:00 2008 Dan Williams <dcbw at redhat.com> - 0.76-3
- Fix crashes when a tracked service restarts too quickly (fdo #18573)


dmraid-1.0.0.rc15-2.fc10
------------------------
* Tue Nov 18 17:00:00 2008 Bill Nottingham <notting at redhat.com> - 1.0.0.rc15-2
- Re-add upstream whitespace removal patch (#468649, #470634)


grub-0.97-38.fc10
-----------------
* Tue Nov 18 17:00:00 2008 Peter Jones <pjones at redhat.com> - 0.97-38
- Put back the accidentally removed fix for rhbz#458576 .

* Tue Nov 18 17:00:00 2008 Peter Jones <pjones at redhat.com> - 0.97-37
- Remove chainloader timeout patch; fixing it in booty instead in order to
  address rhbz#468526 .


kernel-2.6.27.5-117.fc10
------------------------
* Tue Nov 18 17:00:00 2008 Dave Airlie <airlied at redhat.com> 2.6.27.5-116
- rebase to intel proper set of patches + test patch fix.

* Tue Nov 18 17:00:00 2008 Chuck Ebbert <cebbert at redhat.com> 2.6.27.5-117
- Disable ath9k when swiotlb is in use (#471329)


lyx-1.6.0-1.fc10
----------------
* Fri Nov  7 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1.6.0-1
- lyx-1.6.0(final)

* Tue Oct 28 18:00:00 2008 Jos?? Matos <jamatos at fc.up.pt> - 1.6.0-0.11.rc5
- lyx-1.6.0rc5


pdns-2.9.21.2-1.fc10
--------------------
* Mon Nov 17 17:00:00 2008 Ruben Kerkhof <ruben at rubenkerkhof.com> 2.9.21.2-1
- Upstream released new version


pixman-0.12.0-2.fc10
--------------------
* Tue Nov 18 17:00:00 2008 Dan Williams <dcbw at redhat.com> 0.12.0-2
- Actually build with the altivec detection fix (rh #472000, #451831)


spin-kickstarts-0.10.3-1.fc10
-----------------------------
* Wed Nov 19 17:00:00 2008 Jeroen van Meeuwen <kanarip a fedoraunity.org> 0.10.3-1
- Latest and final rebuild for Fedora 10

* Sat Nov  8 17:00:00 2008 Jeroen van Meeuwen <kanarip a fedoraunity.org> 0.10.2-1
- Package updates to kickstarts into F-10 package

* Fri Nov  7 17:00:00 2008 Jeroen van Meeuwen <kanarip a fedoraunity.org> 0.10.1-1
- Second build for review #448072


sugar-0.82.9-4.fc10
-------------------

sugar-toolkit-0.82.11-2.fc10
----------------------------
* Tue Nov 18 17:00:00 2008 Simon Schampijer <simon at laptop.org> - 0.82.11-2
- fix russion po #469160


systemtap-0.8-1.fc10
--------------------
* Thu Nov 13 17:00:00 2008 Frank Ch. Eigler <fche at redhat.com> - 0.8-1
- Upstream release.


xorg-x11-drv-ati-6.9.0-54.fc10
------------------------------
* Tue Nov 18 17:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-54
- radeon attempt to fix suspend/resume

* Tue Nov 18 17:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-53
- radeon - more issues in space check

* Tue Nov 18 17:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-52
- radeon - fix typo

* Tue Nov 18 17:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-51
- radeon - even better space checks + prefer glitches + debug over exiting

* Tue Nov 18 17:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-50
- radeon - don't fail at integer division

* Tue Nov 18 17:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-49
- modeset - fix O(wtf) operation in post_bufmgr_submit

* Mon Nov 17 17:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-48
- limit to 90% of VRAM for modeset command submission

* Mon Nov 17 17:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-47
- add set/drop master ioctls

* Fri Nov 14 17:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-46
- fix rebooting on low memory cards.

* Fri Nov 14 17:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-45
- try and speed up fallback cases a bit


Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 14














From kazen at redhat.com  Wed Nov 19 14:49:11 2008
From: kazen at redhat.com (Karlos Smith)
Date: Wed, 19 Nov 2008 09:49:11 -0500
Subject: sudo and secure-path
In-Reply-To: <da159fda0811181823n4d615206kb63272f39416ff1f@mail.gmail.com>
References: <492332F9.2010705@redhat.com>	<20081119015436.GA10662@jadzia.bu.edu>
	<da159fda0811181823n4d615206kb63272f39416ff1f@mail.gmail.com>
Message-ID: <49242767.4080302@redhat.com>

Jon Stanley wrote:
> On Tue, Nov 18, 2008 at 8:54 PM, Matthew Miller <mattdm at mattdm.org> wrote:
>
>   
>> Yes. The tab-completion thing working is a side-effect -- the more important
>> thing is no surprises. How about a compromise -- add /usr/local/sbin to the
>> secure path?
>>     
--secure-path wasn't added for security reasons as far as I can tell. 
It was added so people could type "sudo ifconfig" instead of "sudo
/sbin/ifconfig".

So as it stands, we are saving people from occasionally having to type
'/sbin/', and forcing others to *frequently* type '/usr/local/sbin/'.
That's not a fair trade-off.  But, I wouldn't complain if there were a
work around.

/usr/local/  isn't one of the paths I preserve across installs, so
adding /usr/local/sbin to the secure path wouldn't solve my problem
anyway (I make heavy use of ~/bin/).
>
> You can't be guaranteed that path is in fact secure. Lots of systems
> mount /usr/local from somewhere outside of their domain of control,
> and I don't want to blindly trust stuff in there.
>   
I thought the whole point of /usr/local was for *locally* installed
programs.

OK from FHS2.3:
"The /usr/local hierarchy is for use by the system administrator when
installing software locally. [...]It may be used for programs and data
that are shareable amongst a group of hosts, but not found in /usr." 

Seems odd to me.  However /usr/local/sbin, is no *less* secure than
/usr/sbin!
/usr/sbin "should" be sharable
/usr/local/bin "may" be sharable

And btw  /usr/local/sbin is in the default path for root in a default
install of Fedora, so it seems we already implicitly trust /usr/local/sbin.

Having said all that, I reiterate that adding /usr/local/sbin to the
secure-path, is a deficient workaround.
> Users have a PATH for a reason. Let them keep it.
>   
Exactly.  However, I see nothing wrong with *adding*  /sbin /usr/sbin
and /usr/local/sbin when sudoing to root.
I don't mind making things easier, that's what a computer is for, but
removing functionality from experienced users, to add ease to newer
users is a bad idea.

-- 
Karlos Smith
Red Hat Global Services
kasmith at redhat.com
+1 361 649-6255 c.



From notting at redhat.com  Wed Nov 19 14:50:13 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 19 Nov 2008 09:50:13 -0500
Subject: Plan for tomorrows (20081119) FESCO meeting
In-Reply-To: <1227094450.3640.19.camel@eagle.danny.cz>
References: <1227044895.28822.10.camel@kennedy> <4923F51C.90700@redhat.com>
	<1227094450.3640.19.camel@eagle.danny.cz>
Message-ID: <20081119145013.GB20326@nostromo.devel.redhat.com>

Dan Hor?k (dan at danny.cz) said: 
> > Can we take a look at bugzillas 461926 and 472061 ? This can get us into lots of trouble
> > and I think we should have a policy that such a behaviour needs to be patched out/disabled
> > from any binaries shipped with Fedora.
> 
> I think we can use
> https://fedoraproject.org/wiki/Packaging/Guidelines#Code_Vs_Content

Ah, webcollage. I don't think that guideline specifically covers it,
as it isn't shipping the content; it's just using a random image
search using various net locations. (Haven't looked at it recently,
but presumably yahoo, ogoogle, etc.)

That being said, I'm fairly sure it's been removed from the random list,
if not from the package itself, multiple times already.

Bill



From james at fedoraproject.org  Wed Nov 19 15:08:09 2008
From: james at fedoraproject.org (James Antill)
Date: Wed, 19 Nov 2008 10:08:09 -0500
Subject: Proposal - "Slow updates" repo
In-Reply-To: <gg0l2d$e9l$1@ger.gmane.org>
References: <49230F31.4030409@redhat.com> <4923104D.5080604@herr-schmitt.de>
	<49231142.9010804@redhat.com>
	<604aa7910811181106n3b30d9b5nbdef29ad334bda92@mail.gmail.com>
	<49231348.2060700@redhat.com>
	<alpine.LFD.2.00.0811181413520.1236@localhost.localdomain>
	<gg0l2d$e9l$1@ger.gmane.org>
Message-ID: <1227107289.4355.134.camel@code.and.org>

On Wed, 2008-11-19 at 10:08 +0100, Kevin Kofler wrote:
> Seth Vidal wrote:
> > you mean like the already existing yum security plugin and the update info
> > that bodhi generates?
> 
> Except it just doesn't work... 2 big problems there:
> 1. Security updates can be obsoleted by non-security updates. So if you
> didn't install the security update in time, you'll never get it.
> 2. Sometimes security updates cause regressions. Usually these are fixed
> very quickly... in a regular bugfix update. With the result that users of
> yum-security will be stuck with the regression (or if they didn't update in
> time, with situation 1., i.e. without the security update).
> 
> To solve 2., fixes for regressions from security updates would have to be
> marked security as well, or (probably better) use a new category ("bugfix
> for security update") which is also pulled in by yum-security.

 This seems very dodgy to me, yes in Fedora you are likely to get a
security errata with extra changes ... and sometimes those extra changes
contain bugs. That doesn't mean the bugs are magically different from
normal bugs.
 We already have bugfix and enhancement ... and we already have "yum
update --bz 1234", for specific problems. I don't think we need/want to
mangle what a security fix is for this.

> To solve 1., the metadata would have to carry the information for the
> security update even after it is obsoleted, and 

 Yes, at the minimum the updateinfo.xml would have to never remove
security data ... at best each package could also contain the latest
security update.

> yum-security would have to
> understand that if foo-1.2.3 is a security update, the currently installed
> package is foo-1.2.2 and the current version in the repo is the bugfix
> update foo-1.2.4, it should install foo-1.2.4. Or alternatively, the latest
> security (or "bugfix for security", see above) update would have to be
> carried in the repos in addition to the latest overall.

 yum-security already does this, and adds a "yum update-minimal" command
so that if you have X-1 installed, X-2 as a security update and X-3 as
an enhancement update "yum update-minimal --security" will move you from
X-1 to X-2.

> In its current state, yum-security is very unreliable and outright
> dangerous.

 You are free to hold this opinion, however I've had machines running
"yum --security update" in cron for a long time ... and it has worked
perfectly.

-- 
James Antill <james at fedoraproject.org>
Fedora



From bpepple at fedoraproject.org  Wed Nov 19 15:10:23 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 19 Nov 2008 10:10:23 -0500
Subject: Plan for tomorrows (20081119) FESCO meeting
In-Reply-To: <4923F51C.90700@redhat.com>
References: <1227044895.28822.10.camel@kennedy>  <4923F51C.90700@redhat.com>
Message-ID: <1227107423.2671.0.camel@truman>

On Wed, 2008-11-19 at 12:14 +0100, Karsten Hopp wrote:
> Can we take a look at bugzillas 461926 and 472061 ? This can get us into lots of trouble
> and I think we should have a policy that such a behaviour needs to be patched out/disabled
> from any binaries shipped with Fedora.

Yup, added to 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/20081119/fde36cac/attachment.sig>

From jkeating at redhat.com  Wed Nov 19 15:14:58 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 19 Nov 2008 07:14:58 -0800
Subject: F11 Proposal: Stabilization
In-Reply-To: <4923C840.30101@shmuelhome.mine.nu>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<49234CE6.7050805@gmail.com>
	<604aa7910811181554q238d59ber63bf99565a37558e@mail.gmail.com>
	<492359B2.2010008@gmail.com>
	<604aa7910811181622q6d2b7f92kf20853a6c9f8c2f1@mail.gmail.com>
	<492378C7.6050408@gmail.com>
	<1227064591.28543.34.camel@luminos.localdomain>
	<4923C840.30101@shmuelhome.mine.nu>
Message-ID: <1227107699.28543.52.camel@luminos.localdomain>

On Wed, 2008-11-19 at 10:03 +0200, shmuel siegel wrote:
> I am not sure that you are right. The audience for updates tested might 
> very well be bigger than the one for updates testing. For example, I 
> always started using rawhide at test2, never at test1. Test1 was viewed 
> as pre-alpha and just too raw for someone who wanted a system that 
> basically worked but had some bugs.

I think you just described the problem again.  The audience for "updates
tested" is going to be far larger than the audience for 'updates' or
'updates-testing', meaning that stuff isn't /really/ going to be tested
until it gets to that 'updates-tested' set of folks, which kind of
defeats the purpose.

-- 
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/20081119/a6b46460/attachment.sig>

From jkeating at redhat.com  Wed Nov 19 15:16:18 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 19 Nov 2008 07:16:18 -0800
Subject: F11 Proposal: Stabilization
In-Reply-To: <m38wrgqdcb.fsf@ursa.amorsen.dk>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<49234CE6.7050805@gmail.com>
	<604aa7910811181554q238d59ber63bf99565a37558e@mail.gmail.com>
	<492359B2.2010008@gmail.com>
	<604aa7910811181622q6d2b7f92kf20853a6c9f8c2f1@mail.gmail.com>
	<492378C7.6050408@gmail.com>
	<1227064591.28543.34.camel@luminos.localdomain>
	<m38wrgqdcb.fsf@ursa.amorsen.dk>
Message-ID: <1227107778.28543.53.camel@luminos.localdomain>

On Wed, 2008-11-19 at 10:23 +0100, Benny Amorsen wrote:
> I would be willing to run with updates-testing on by default on
> several machines if I was sure that faulty packages didn't just go
> away. The problem is that you're stuck with the upgraded package which
> turned out to be buggy, unless you do something manually to get rid of
> it. The alternative is to reissue the original package with a higher
> evra.

How often have you ran into bad updates that are just thrown away,
rather than fixed?  (and by fixed I mean either the bug caused in the
update has been fixed with even newer bits, or the old bits were
re-issued with higher e:n-v-r)

-- 
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/20081119/ec220c87/attachment.sig>

From jkeating at redhat.com  Wed Nov 19 15:20:19 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 19 Nov 2008 07:20:19 -0800
Subject: Proposal - "Slow updates" repo
In-Reply-To: <gg0l2d$e9l$1@ger.gmane.org>
References: <49230F31.4030409@redhat.com> <4923104D.5080604@herr-schmitt.de>
	<49231142.9010804@redhat.com>
	<604aa7910811181106n3b30d9b5nbdef29ad334bda92@mail.gmail.com>
	<49231348.2060700@redhat.com>
	<alpine.LFD.2.00.0811181413520.1236@localhost.localdomain>
	<gg0l2d$e9l$1@ger.gmane.org>
Message-ID: <1227108019.28543.55.camel@luminos.localdomain>

On Wed, 2008-11-19 at 10:08 +0100, Kevin Kofler wrote:
> 
> To solve 1., the metadata would have to carry the information for the
> security update even after it is obsoleted, and yum-security would have to
> understand that if foo-1.2.3 is a security update, the currently installed
> package is foo-1.2.2 and the current version in the repo is the bugfix
> update foo-1.2.4, it should install foo-1.2.4. Or alternatively, the latest
> security (or "bugfix for security", see above) update would have to be
> carried in the repos in addition to the latest overall.

Another way to solve 1 is to assign unique IDs to security issues (I
think we do that already) and have a perpetual list per package of
security issues that the packages resolve, regardless of the current
update reason.  This way the security plugin could check to see if the
version of the package they have already resolves the listed issues, and
if it doesn't, pull down whatever is there.  If it does, ignore 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/20081119/9e7a29b8/attachment.sig>

From jkeating at redhat.com  Wed Nov 19 15:25:39 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 19 Nov 2008 07:25:39 -0800
Subject: F11 Proposal: Stabilization
In-Reply-To: <f7c6719a0811190050x1ecc4fesbbaad531fb9fbaa2@mail.gmail.com>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<20081117213742.GB5603@nostromo.devel.redhat.com>
	<4921E683.30407@redhat.com>
	<604aa7910811171354h26c8eb30r72280cc95ba9a976@mail.gmail.com>
	<1226960219.4098.20.camel@perihelion.bos.jonmasters.org>
	<49226383.3010800@leemhuis.info>
	<1227020349.4355.116.camel@code.and.org>
	<f7c6719a0811190050x1ecc4fesbbaad531fb9fbaa2@mail.gmail.com>
Message-ID: <1227108340.28543.56.camel@luminos.localdomain>

On Wed, 2008-11-19 at 09:50 +0100, Christof Damian wrote:
> What I would like is that updates for the current fedora release only
> contain security fixes. updates/9/SRPMS.newkey currently contains 2257
> files, which seems to be too much. It also means that a lot of new
> features which will be in f10 already trickled down to f9.

Not even Red Hat Enterprise Linux does security only updates, at least
not until a release has been out there for a few years.

This is why the security plugin exists within yum.

-- 
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/20081119/18491719/attachment.sig>

From ggw at wolves.durham.nc.us  Wed Nov 19 15:42:34 2008
From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury)
Date: Wed, 19 Nov 2008 10:42:34 -0500
Subject: Release Candidates?
Message-ID: <492433EA.8010000@wolves.durham.nc.us>

I can see several spins set up for release candidate status.  Just no
checksums yet.

Is there a page/list somewhere that shows these statuses?

-- 
G.Wolfe Woodbury



From lesmikesell at gmail.com  Wed Nov 19 15:51:47 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 19 Nov 2008 09:51:47 -0600
Subject: F11 Proposal: Stabilization
In-Reply-To: <1227107699.28543.52.camel@luminos.localdomain>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>	<1226958439.3814.6.camel@localhost.localdomain>	<49232E89.6020400@redhat.com>	<1227043890.28543.18.camel@luminos.localdomain>	<49233BE6.3080808@redhat.com>	<1227046097.28543.21.camel@luminos.localdomain>	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>	<49234CE6.7050805@gmail.com>	<604aa7910811181554q238d59ber63bf99565a37558e@mail.gmail.com>	<492359B2.2010008@gmail.com>	<604aa7910811181622q6d2b7f92kf20853a6c9f8c2f1@mail.gmail.com>	<492378C7.6050408@gmail.com>	<1227064591.28543.34.camel@luminos.localdomain>	<4923C840.30101@shmuelhome.mine.nu>
	<1227107699.28543.52.camel@luminos.localdomain>
Message-ID: <49243613.1050901@gmail.com>

Jesse Keating wrote:
> On Wed, 2008-11-19 at 10:03 +0200, shmuel siegel wrote:
>> I am not sure that you are right. The audience for updates tested might 
>> very well be bigger than the one for updates testing. For example, I 
>> always started using rawhide at test2, never at test1. Test1 was viewed 
>> as pre-alpha and just too raw for someone who wanted a system that 
>> basically worked but had some bugs.
> 
> I think you just described the problem again.  The audience for "updates
> tested" is going to be far larger than the audience for 'updates' or
> 'updates-testing', meaning that stuff isn't /really/ going to be tested
> until it gets to that 'updates-tested' set of folks, which kind of
> defeats the purpose.

That may or may not be true and it may or may not matter.  All you need 
is some large representative sample doing the early testing and a way to 
ensure feedback to improve everyone's experience.  And letting users 
control their exposure to new bugs might increase the user base in both 
categories.  This choice should not be made and fixed at install time, 
though. My experience with fedora is that for the first few months after 
a release you want updates immediately since there are a lot of old 
known bugs being fixed, but at some point there is a crossover where new 
bugs are being introduced by the changes faster than the old ones are 
fixed.  Do you have any metrics regarding new bugzilla entries after 
updates or updates that immediately replace a prior buggy update that 
might quantify this impression or find an appropriate delay to have a 
good chance of avoiding those quickly-replaced updates?

Also, when installing on new hardware you might want to have the very 
latest updates until you are convinced that everything is stable, at 
which point you will not be interested in any kernel or driver changes 
which introduce risk for no benefit on that machine.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From dledford at redhat.com  Wed Nov 19 15:56:38 2008
From: dledford at redhat.com (Doug Ledford)
Date: Wed, 19 Nov 2008 10:56:38 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <4923836B.1090309@gmail.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>
	<1226686948.13086.44.camel@aglarond.local>
	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>
	<1226700116.13086.116.camel@aglarond.local>	<491FBA0E.2070003@gmail.com>
	<1227043592.4687.9.camel@firewall.xsintricity.com>
	<49234139.1050400@gmail.com>
	<1227057520.4687.45.camel@firewall.xsintricity.com>
	<4923836B.1090309@gmail.com>
Message-ID: <1227110198.4687.108.camel@firewall.xsintricity.com>

Note: I always use my Red Hat email address, but in this case, I
specifically note that I'm speaking for myself as a Fedora community
member, and not on behalf of Red Hat.

On Tue, 2008-11-18 at 21:09 -0600, Les Mikesell wrote:
> Doug Ledford wrote:
> > >>>   
> >>>> But if a system claiming to be new/better can't provide more or less 
> >>>> exact emulation of the system it wants to replace, it probably really 
> >>>> isn't better.
> >>> That statement is based on the incorrect assumption that the way things
> >>> used to be is/will be sane for the way things are going.  Sometimes you
> >>> just need to do things differently because what we grew up doing just
> >>> doesn't work any more.
> >> Maybe - when tcp is replaced with some other protocol - or name and 
> >> number assignment are no longer parceled out through a hierarchical 
> >> process.  Until then, servers need a way to assign  the addresses 
> >> manually in ways that are easy to relate to the physical wires that you 
> >> plug into them,
> > 
> > That's not true.  The relating of numbers/names to wires is an arbitrary
> > abstraction, and one that need not be the *only* possible abstraction.
> > I admit it's handy and common, especially with servers.  And certainly
> > you want a server to get the same address from boot to boot, especially
> > if it's a live server on the internet with people coming to it (or live
> > server on an intranet).  But, the eth0 naming is really
> > irrelevant...
> 
> It's not irrelevant in the context of a unix-like system where devices 
> are identified by name and you want to clone a bazillion copies of a 
> machine.

This is a circular argument.  I argued that the eth0 naming is arbitrary
and could be done differently, you say it can't be done differently
because you do it that way now.

> > it's the hardware mac address that matters.
> 
> It is now.  In the 2.4 kernel days I could copy a system disk from an 
> identical machine, change the hostname and IP address for eth0, eth1, 
> etc.

At the point you clone a disk and then manually edit the eth0, eth1,
etc. addresses, you are no longer strictly cloning.  You are
customizing.  The choice of customization is arbitrary.  Whether you
customize the disk by cloning and editing, or by using something like
cobbler to clone the install via a profile and then have cobbler
customize the addresses based upon its database is merely
implementation.  And that's my point, there are better implementations
to be had.

>  and ship a box of them to remote locations where anyone could 
> insert them into a chassis and have them come up working.  Now it 
> doesn't work and I either have to know every target mac address and 
> match up the disks or talk some 'hands-on' operator through the setup 
> with a console on a crash cart to get the address assignment done.  Is 
> that an improvement?

Failure to use tools that automate this sort of thing is not a valid
indictment of the infrastructure that's been put in place.

> >  Being able to
> > go from wire to mac address matters, and going from mac address to
> > configuration matters.  Whether that configuration is called eth0 or
> > pr0n_serv0 doesn't really matter.  To use a similar situation that we've
> > already changed, back in the day, the only way to mount your root
> > filesystem was by device major:minor.  Eventually, we figured out that
> > since file systems have unique identifiers, we could screw the
> > major:minor pair and mount by label instead.
> 
> That sucked too, if you recall what happened when you tried to re-use a 
> disk, putting one you had used before into the same chassis as a current 
> one.  For the first year or so after this change was made, this scenario 
> would result in a machine that _would not even boot_.

Anaconda uses default labels for devices.  You could have done a small
post script during a kickstart install to rectify this.  One loop to
modify all the device labels of filesystems to a unique label based
upon, say, hostname + mount point, eg. firewall-10.0.1-root as a
filesystem label combined with modifying the entries in fstab, then a
final line to rebuild the initrd image.  This sort of thing can be
automated easily in cobbler such that the default kickstart template
need not know about each machines name/purpose, you can use variable
substitution to do what you want.

> > Now, that switch required
> > changes to mount, changes to fstab symantics, changes to initrd, etc.
> > But, it happened, and I doubt many people would say we are the worse off
> > for it.
> 
> I do.  My machines often have disks cloned from elsewhere, or that have 
> been previously used and have duplicate labels but are not exact copies. 
>   I find it hard to believe that this doesn't happen to anyone with a 
> reasonable number of machines or who re-uses parts.  I always undo any 
> labels the installer puts in fstab so I know what partitions will 
> actually be mounted.
> 
> > I think there's definitely more to be done before we are ready
> > to make the same sort of switch in regards to networking, but I prophesy
> > that eventually we will get there and the old days of static ifcfg-eth0
> > files may go the way of the dinosaur.
> 
> And I think you are entirely off-base in terms of making it harder for 
> someone who knows which device is which to actually identify it to the 
> OS. I won't say it would be impossible to make things better but so far 
> it has just created more work.

Actually, it has created less work for those people that utilized the
tools that have been created to automate these things.  In your case,
you already mention having to go in and hand edit network settings any
time you clone a disk for a new machine.  That's not 0 work.  Yet, with
things like cobbler, there is a certain amount of work to get things set
up initially, but once that's done, the amount of work goes down.  Your
real complaint is that your work has gone up *because* you choose not to
make use of these tools or better methods of doing things.  I don't know
what to say to that.  If your going to do things the 1980s way and no
other, then I'm not sure there's anything that anyone can do to make
your life easier.

> >>  and it needs to be done by a person with authorization 
> >> passed down the appropriate hierarchy.  It's not something a daemon can 
> >> guess at.   If you want to make things easier for people who haven't 
> >> already automated their processes, you could build a gui that deals with 
> >> with configuring the separate programs that need to be tied together for 
> >> related concepts.  That is, you could have a gui form where you fill in 
> >> a name, ip, and mac address and have the tool build the forward and 
> >> reverse DNS zone entries and either the local interface configuration 
> >> tied to that nic or the dhcp entry to assign it to a different machine.
> >>
> >> For people who have already automated these processes, try not to screw 
> >> it up too badly.  If the way it is done now didn't work, we wouldn't 
> >> have an internet.
> > 
> > I'm sure it won't screw existing setups unless there is an overwhelming
> > compelling reason.
> 
> But the changes you mentioned already have.

Not for those of us doing things in any way other than the old way.

> >  But, sometimes it's worth letting go of the old way
> > of doing things.  And I'm not saying this is even one of those cases,
> > just that your statement that it can't be better if it doesn't exactly
> > emulate the current way of doing things is a patently false straw man
> > and that each case needs to be evaluated individually and objectively.
> 
> Please think through the way you would clone a large number of servers, 
> particularly when you swap disks around and ship to remote locations 
> before you consider some change to be for the better.  Or what happens 
> when you take several previously used disks and put them together in the 
> same box for one purpose or another.
> 
> > For my own purposes, what would make dealing with udev/hal/etc. on a
> > server system much easier would be some concise guides in terms of how
> > these layers dealt with dynamic devices and how to achieve what you used
> > to do with modprobe.conf in udev land for example.  One of the things
> > the server SIG can do is come up with exactly that sort of
> > documentation.
> 
> I don't want dynamic devices on my servers.  I want to know exactly what 
> they are and how they are named by the OS.  And I want a hundred of them 
> with image-copied disks to all work the same way.

But that's the fallacy of your argument, things *didn't* work that way,
ever.  At least not under linux.  A device failure could cause sdb to
become sda, or a BIOS or kernel update could cause eth0 and eth1 to flip
flop.  The changes that were made were to deal with real world
situations that you get to ignore because you tightly control your
setups.  If you embraced some of these changes and worked *with* them
instead of disabling them, then you might be able to loosen up some of
that control and find that things still work like they are supposed to.

>   Some tools to deal 
> with the changes being made could help with this but so far I haven't 
> seen any.

I'm sorry, but you must not have looked very hard.  The tools are there,
and they do a damn fine job.

I really think this all boils down to one simple fact: Fedora is
supposed to bleeding edge, and that includes improving upon old, tired
ways of doing things for better ways, and that seems to be anathema to
you.  I hate to say it, but it sounds like what you really want is not
Fedora, but OpenSolaris.  I'm afraid that as long as you want to
maintain your setup the same as it has been for decades, that Fedora and
the direction Fedora is heading in is going to continue to frustrate
you.  And I really hate to say that, because I *want* Fedora to be all
things to all people, but realistically it can't.  And in this
particular conflict, it's a case of "we have real world problems from
some users so we fix those problems with a better way of doing things"
versus your case of "in my particular world, these problems don't exist,
so don't change things around" and I just don't know how to rectify
those two positions.  In the end, Fedora is going to be true to its
goals, including being bleeding edge and fixing things that are broken,
and I don't think it's even possible to stop the march of that progress
for the sake of your particular setup and working habits.  We can
attempt to, but sometimes things simply must be changed in order to deal
with other people's reality.

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081119/9ce9109c/attachment.sig>

From rjones at redhat.com  Wed Nov 19 15:55:29 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 19 Nov 2008 15:55:29 +0000
Subject: ANNOUNCE: Smock (simpler mock) - a mock wrapper for chain
	building
In-Reply-To: <20081119095902.GA31559@amd.home.annexia.org>
References: <20081118174907.GA27568@amd.home.annexia.org>
	<200811190039.47991.opensource@till.name>
	<20081119095902.GA31559@amd.home.annexia.org>
Message-ID: <20081119155529.GA1148@amd.home.annexia.org>

On Wed, Nov 19, 2008 at 09:59:02AM +0000, Richard W.M. Jones wrote:
> On Wed, Nov 19, 2008 at 12:39:43AM +0100, Till Maas wrote:
> > Sadly it seems not to work with only srpm or if the only BRs that several 
> > srpms connect are of the type "%{name}-devel", because it seems to assume 
> > that every srpm only provides it's name as a package.
> 
> Ah yes, should be easy to fix.  It didn't affect any mingw32 packages
> as it happens because they don't use -devel.

I pushed this change which appears to fix the problem:

  http://hg.et.redhat.com/misc/fedora-mingw--devel?cs=b11d7b1283d8

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 kazen at redhat.com  Wed Nov 19 16:02:04 2008
From: kazen at redhat.com (Karlos Smith)
Date: Wed, 19 Nov 2008 11:02:04 -0500
Subject: sudo and secure-path
In-Reply-To: <49242767.4080302@redhat.com>
References: <492332F9.2010705@redhat.com>	<20081119015436.GA10662@jadzia.bu.edu>	<da159fda0811181823n4d615206kb63272f39416ff1f@mail.gmail.com>
	<49242767.4080302@redhat.com>
Message-ID: <4924387C.8030601@redhat.com>

Karlos Smith wrote:
> --secure-path wasn't added for security reasons as far as I can tell. 
> It was added so people could type "sudo ifconfig" instead of "sudo
> /sbin/ifconfig".
>   
Quick Clarification:  Yes the "--secure-path" was added to sudo as a
security feature.  But it would appear that the main reason that
*security* feature was enabled in Fedora was for ease of use, *not*
security.

carry on...

-- 
Karlos Smith
Red Hat Global Services
kasmith at redhat.com
+1 361 649-6255 c.



From lmacken at redhat.com  Wed Nov 19 16:26:39 2008
From: lmacken at redhat.com (Luke Macken)
Date: Wed, 19 Nov 2008 11:26:39 -0500
Subject: Proposal - "Slow updates" repo
In-Reply-To: <1227107289.4355.134.camel@code.and.org>
References: <49230F31.4030409@redhat.com> <4923104D.5080604@herr-schmitt.de>
	<49231142.9010804@redhat.com>
	<604aa7910811181106n3b30d9b5nbdef29ad334bda92@mail.gmail.com>
	<49231348.2060700@redhat.com>
	<alpine.LFD.2.00.0811181413520.1236@localhost.localdomain>
	<gg0l2d$e9l$1@ger.gmane.org>
	<1227107289.4355.134.camel@code.and.org>
Message-ID: <20081119162639.GB3493@x300.bos.redhat.com>

On Wed, Nov 19, 2008 at 10:08:09AM -0500, James Antill wrote:
> On Wed, 2008-11-19 at 10:08 +0100, Kevin Kofler wrote:
> > Seth Vidal wrote:
> > > you mean like the already existing yum security plugin and the update info
> > > that bodhi generates?
> > 
> > Except it just doesn't work... 2 big problems there:
> > 1. Security updates can be obsoleted by non-security updates. So if you
> > didn't install the security update in time, you'll never get it.
> > 2. Sometimes security updates cause regressions. Usually these are fixed
> > very quickly... in a regular bugfix update. With the result that users of
> > yum-security will be stuck with the regression (or if they didn't update in
> > time, with situation 1., i.e. without the security update).
> > 
> > To solve 2., fixes for regressions from security updates would have to be
> > marked security as well, or (probably better) use a new category ("bugfix
> > for security update") which is also pulled in by yum-security.
> 
>  This seems very dodgy to me, yes in Fedora you are likely to get a
> security errata with extra changes ... and sometimes those extra changes
> contain bugs. That doesn't mean the bugs are magically different from
> normal bugs.
>  We already have bugfix and enhancement ... and we already have "yum
> update --bz 1234", for specific problems. I don't think we need/want to
> mangle what a security fix is for this.
> 
> > To solve 1., the metadata would have to carry the information for the
> > security update even after it is obsoleted, and 
> 
>  Yes, at the minimum the updateinfo.xml would have to never remove
> security data ... at best each package could also contain the latest
> security update.

https://fedorahosted.org/bodhi/ticket/259


luke



From seg at haxxed.com  Wed Nov 19 16:31:30 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Wed, 19 Nov 2008 10:31:30 -0600
Subject: F11 Proposal: Stabilization
In-Reply-To: <1227070185.3752.639.camel@beck.corsepiu.local>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<1227070185.3752.639.camel@beck.corsepiu.local>
Message-ID: <1227112290.7387.27.camel@localhost.localdomain>

On Wed, 2008-11-19 at 05:49 +0100, Ralf Corsepius wrote:
> > yum update really means yum update openoffice\* somestuff\*  \
> >       my_favorite_pkg\*
> I feel, you just discovered what apt/apt-get calls "package pinning"

No actually it's simpler than that. What we want is more like package
holds. More precisely, we want the *opposite* of package holds.

What we're talking about here is a mode where no packages are updated,
except for security fixes, and a list of packages I know I want the
latest and greatest of.

Which is pretty much that command line up there, plus security updates.
Except it's sticky. Really that's something that annoys the hell out of
me about yum, nothing sticks. If a repo is broken and needs to be
disabled, or if I want to 'hold' a package I know is broken, I have to
go mucking about in config files. And that results in my repo files no
longer being updated because they've been modified and RPM so helpfully
starts spewing .rpmnew files all over...

When are we going to get the ability to store arbitrary bits of
information about packages in the RPM database? We just need a simple
generic key=value system. So front ends can store stuff like what repo
the package came from, 'is-dep' flags, hold flags, dont-hold flags, and
so on, but RPM itself doesn't have to actually know or care what they
mean.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081119/853207c0/attachment.sig>

From james at fedoraproject.org  Wed Nov 19 16:34:25 2008
From: james at fedoraproject.org (James Antill)
Date: Wed, 19 Nov 2008 11:34:25 -0500
Subject: F11 Proposal: Stabilization
In-Reply-To: <49243613.1050901@gmail.com>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<49234CE6.7050805@gmail.com>
	<604aa7910811181554q238d59ber63bf99565a37558e@mail.gmail.com>
	<492359B2.2010008@gmail.com>
	<604aa7910811181622q6d2b7f92kf20853a6c9f8c2f1@mail.gmail.com>
	<492378C7.6050408@gmail.com>
	<1227064591.28543.34.camel@luminos.localdomain>
	<4923C840.30101@shmuelhome.mine.nu>
	<1227107699.28543.52.camel@luminos.localdomain>
	<49243613.1050901@gmail.com>
Message-ID: <1227112465.4355.146.camel@code.and.org>

On Wed, 2008-11-19 at 09:51 -0600, Les Mikesell wrote:
> Jesse Keating wrote:
> > On Wed, 2008-11-19 at 10:03 +0200, shmuel siegel wrote:
> >> I am not sure that you are right. The audience for updates tested might 
> >> very well be bigger than the one for updates testing. For example, I 
> >> always started using rawhide at test2, never at test1. Test1 was viewed 
> >> as pre-alpha and just too raw for someone who wanted a system that 
> >> basically worked but had some bugs.
> > 
> > I think you just described the problem again.  The audience for "updates
> > tested" is going to be far larger than the audience for 'updates' or
> > 'updates-testing', meaning that stuff isn't /really/ going to be tested
> > until it gets to that 'updates-tested' set of folks, which kind of
> > defeats the purpose.
> 
> That may or may not be true and it may or may not matter.  All you need 
> is some large representative sample doing the early testing and a way to 
> ensure feedback to improve everyone's experience.  And letting users 
> control their exposure to new bugs might increase the user base in both 
> categories.

 This is what updates-testing _already does_. As Jesse has already said,
there are two big problems:

1. Too many people want to be consumers of the testing but not the
providers of it.
 Indeed IMO the whole updates-tested argument seems to devolve to "I'm
going to be clever and switch to this, but I'm pretty sure a bunch of
other people aren't going to know immediately and so will become my
unwilling testers".

2. The people who are the providers of the testing, aren't necessarily
running the same kinds of workloads as the people who want to just be
consumers of the testing.

...and to be fair, there are certainly improvements that could be done
on the tools side to help people test and report, and the limited
resources currently available are working to make that better. But,
personally, I don't see how an updates-tested or updates-after-1-month
etc. etc. is going to help in the long run. Sure, in the short term.
it'll help all the people that know about it at the expense of those
that don't ... but that isn't a good feature, IMO.

-- 
James Antill <james at fedoraproject.org>
Fedora



From lmacken at redhat.com  Wed Nov 19 16:40:33 2008
From: lmacken at redhat.com (Luke Macken)
Date: Wed, 19 Nov 2008 11:40:33 -0500
Subject: Proposal - "Slow updates" repo
In-Reply-To: <9497e9990811190220i1301f5d1t24b1c88e7cb0d90c@mail.gmail.com>
References: <49230F31.4030409@redhat.com>
	<20081118212221.GB3459@x300.bos.redhat.com>
	<9497e9990811190220i1301f5d1t24b1c88e7cb0d90c@mail.gmail.com>
Message-ID: <20081119164033.GC3493@x300.bos.redhat.com>

On Wed, Nov 19, 2008 at 10:20:12AM +0000, Mat Booth wrote:
> On Tue, Nov 18, 2008 at 9:22 PM, Luke Macken <lmacken at redhat.com> wrote:
> > So, how do we minimize that breakage?
> >
> >    - Ensure that new features are tested, by humans and ideally a test suite.
> 
> I have a brief test plan for some of my packages on my wiki page:
> https://fedoraproject.org/wiki/User:Mbooth#Package_Maintenance
> 
> Although it's more of a personal /aide memoire/ rather than actual
> test procedure, I'm sure it would also be useful to others who are
> interested in testing my packages. It only takes a few minutes to go
> through and if any of the things on that list do not work, I consider
> it a bug. :-)
> 
> Would it be useful to mandate that maintainers provide a similar test
> plan for all packages going through updates-testing in order to make
> sure all the features are covered?

I think it would be extremely useful.  It looks like the QA team has
already started the initiative, but not many people have been helping.

    https://fedoraproject.org/wiki/Category:Test_Cases
    https://fedoraproject.org/wiki/QA/HowToTestTemplate

luke



From skvidal at fedoraproject.org  Wed Nov 19 16:45:15 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 19 Nov 2008 11:45:15 -0500 (EST)
Subject: F11 Proposal: Stabilization
In-Reply-To: <1227112290.7387.27.camel@localhost.localdomain>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<1227070185.3752.639.camel@beck.corsepiu.local>
	<1227112290.7387.27.camel@localhost.localdomain>
Message-ID: <alpine.LFD.2.00.0811191145010.10340@localhost.localdomain>

i

On Wed, 19 Nov 2008, Callum Lerwick wrote:

> No actually it's simpler than that. What we want is more like package
> holds. More precisely, we want the *opposite* of package holds.
>
> What we're talking about here is a mode where no packages are updated,
> except for security fixes, and a list of packages I know I want the
> latest and greatest of.
>
> Which is pretty much that command line up there, plus security updates.
> Except it's sticky. Really that's something that annoys the hell out of
> me about yum, nothing sticks. If a repo is broken and needs to be
> disabled, or if I want to 'hold' a package I know is broken, I have to
> go mucking about in config files. And that results in my repo files no
> longer being updated because they've been modified and RPM so helpfully
> starts spewing .rpmnew files all over...
>
> When are we going to get the ability to store arbitrary bits of
> information about packages in the RPM database? We just need a simple
> generic key=value system. So front ends can store stuff like what repo
> the package came from, 'is-dep' flags, hold flags, dont-hold flags, and
> so on, but RPM itself doesn't have to actually know or care what they
> mean.

If you want to do this now, you can, via plugins. What you're describing 
above is fairly painful, though. It ultimately works out to be a mechanism 
for excluding updates, though.

-sv



From dhollis at davehollis.com  Wed Nov 19 16:57:26 2008
From: dhollis at davehollis.com (David Hollis)
Date: Wed, 19 Nov 2008 11:57:26 -0500
Subject: F11 Proposal: Stabilization
In-Reply-To: <alpine.LFD.2.00.0811191145010.10340@localhost.localdomain>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<1227070185.3752.639.camel@beck.corsepiu.local>
	<1227112290.7387.27.camel@localhost.localdomain>
	<alpine.LFD.2.00.0811191145010.10340@localhost.localdomain>
Message-ID: <1227113846.4419.150.camel@dhollis-lnx>

On Wed, 2008-11-19 at 11:45 -0500, Seth Vidal wrote:
> i
> 
> On Wed, 19 Nov 2008, Callum Lerwick wrote:
> 
> > No actually it's simpler than that. What we want is more like package
> > holds. More precisely, we want the *opposite* of package holds.
> >
> > What we're talking about here is a mode where no packages are updated,
> > except for security fixes, and a list of packages I know I want the
> > latest and greatest of.
> >
> > Which is pretty much that command line up there, plus security updates.
> > Except it's sticky. Really that's something that annoys the hell out of
> > me about yum, nothing sticks. If a repo is broken and needs to be
> > disabled, or if I want to 'hold' a package I know is broken, I have to
> > go mucking about in config files. And that results in my repo files no
> > longer being updated because they've been modified and RPM so helpfully
> > starts spewing .rpmnew files all over...
> >
> > When are we going to get the ability to store arbitrary bits of
> > information about packages in the RPM database? We just need a simple
> > generic key=value system. So front ends can store stuff like what repo
> > the package came from, 'is-dep' flags, hold flags, dont-hold flags, and
> > so on, but RPM itself doesn't have to actually know or care what they
> > mean.
> 
> If you want to do this now, you can, via plugins. What you're describing 
> above is fairly painful, though. It ultimately works out to be a mechanism 
> for excluding updates, though.


Generally, if a package update is just a release-level bump, it's fairly
minor change and isn't likely to affect anything.  If the actual version
portion changes (such as with the kernel, firefox, openoffice), there is
a lot room for things to be affected.  What if yum/PackageKit had a flag
to only update packages that only have a release bump.  

I'm sure everyone can come up with a case where package-3.1.2-4 broke
stuff that worked with package-3.1.2-3 though those would be fringe
cases.

I could be wrong.

In all reality of course, and as a lot of the folks on this thread
already realize, is that if an effort to maintain stability is going to
take considerable time and resources, it just isn't going to happen.
That's why a lot of people don't like running EL5 or CentOS on their
desktop, the bits don't get updated and you want all the new gee-whiz
stuff.  I've converted all of my servers over to CentOS over the last
year or so not so much out of stability issues, but rather not wanting
to hvae to upgrade them every 6-12 months to stay current when
everything is working just fine.

It really seems like that is pretty much how it's supposed to work to
me.  Desktop/bleeding edge - go Fedora.  Stable, long-term support,
servers doing standard server stuff - EL/CentOS.





From fedora at matbooth.co.uk  Wed Nov 19 17:05:11 2008
From: fedora at matbooth.co.uk (Mat Booth)
Date: Wed, 19 Nov 2008 17:05:11 +0000
Subject: Proposal - "Slow updates" repo
In-Reply-To: <20081119164033.GC3493@x300.bos.redhat.com>
References: <49230F31.4030409@redhat.com>
	<20081118212221.GB3459@x300.bos.redhat.com>
	<9497e9990811190220i1301f5d1t24b1c88e7cb0d90c@mail.gmail.com>
	<20081119164033.GC3493@x300.bos.redhat.com>
Message-ID: <9497e9990811190905t4794b549ub086e22e751bddf4@mail.gmail.com>

On Wed, Nov 19, 2008 at 4:40 PM, Luke Macken <lmacken at redhat.com> wrote:
> On Wed, Nov 19, 2008 at 10:20:12AM +0000, Mat Booth wrote:
>> I have a brief test plan for some of my packages on my wiki page:
>> https://fedoraproject.org/wiki/User:Mbooth#Package_Maintenance
>>
>> Although it's more of a personal /aide memoire/ rather than actual
>> test procedure, I'm sure it would also be useful to others who are
>> interested in testing my packages. It only takes a few minutes to go
>> through and if any of the things on that list do not work, I consider
>> it a bug. :-)
>>
>> Would it be useful to mandate that maintainers provide a similar test
>> plan for all packages going through updates-testing in order to make
>> sure all the features are covered?
>
> I think it would be extremely useful.  It looks like the QA team has
> already started the initiative, but not many people have been helping.
>
>    https://fedoraproject.org/wiki/Category:Test_Cases
>    https://fedoraproject.org/wiki/QA/HowToTestTemplate
>
> luke
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

I wasn't aware, thanks for the links. I might as well convert my notes
into some proper Eclipse/Eclipse-Plugin test cases using their
templates when I get some time.

-- 
Mat Booth
www.matbooth.co.uk



From skvidal at fedoraproject.org  Wed Nov 19 17:15:53 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 19 Nov 2008 12:15:53 -0500 (EST)
Subject: F11 Proposal: Stabilization
In-Reply-To: <1227113846.4419.150.camel@dhollis-lnx>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<1227070185.3752.639.camel@beck.corsepiu.local>
	<1227112290.7387.27.camel@localhost.localdomain>
	<alpine.LFD.2.00.0811191145010.10340@localhost.localdomain>
	<1227113846.4419.150.camel@dhollis-lnx>
Message-ID: <alpine.LFD.2.00.0811191215080.10340@localhost.localdomain>



On Wed, 19 Nov 2008, David Hollis wrote:

> On Wed, 2008-11-19 at 11:45 -0500, Seth Vidal wrote:
>> i
>>
>> On Wed, 19 Nov 2008, Callum Lerwick wrote:
>>
>>> No actually it's simpler than that. What we want is more like package
>>> holds. More precisely, we want the *opposite* of package holds.
>>>
>>> What we're talking about here is a mode where no packages are updated,
>>> except for security fixes, and a list of packages I know I want the
>>> latest and greatest of.
>>>
>>> Which is pretty much that command line up there, plus security updates.
>>> Except it's sticky. Really that's something that annoys the hell out of
>>> me about yum, nothing sticks. If a repo is broken and needs to be
>>> disabled, or if I want to 'hold' a package I know is broken, I have to
>>> go mucking about in config files. And that results in my repo files no
>>> longer being updated because they've been modified and RPM so helpfully
>>> starts spewing .rpmnew files all over...
>>>
>>> When are we going to get the ability to store arbitrary bits of
>>> information about packages in the RPM database? We just need a simple
>>> generic key=value system. So front ends can store stuff like what repo
>>> the package came from, 'is-dep' flags, hold flags, dont-hold flags, and
>>> so on, but RPM itself doesn't have to actually know or care what they
>>> mean.
>>
>> If you want to do this now, you can, via plugins. What you're describing
>> above is fairly painful, though. It ultimately works out to be a mechanism
>> for excluding updates, though.
>
>
> Generally, if a package update is just a release-level bump, it's fairly
> minor change and isn't likely to affect anything.  If the actual version
> portion changes (such as with the kernel, firefox, openoffice), there is
> a lot room for things to be affected.  What if yum/PackageKit had a flag
> to only update packages that only have a release bump.
>
> I'm sure everyone can come up with a case where package-3.1.2-4 broke
> stuff that worked with package-3.1.2-3 though those would be fringe
> cases.
>
> I could be wrong.

In general, drawing conclusions based on the type of change in the e-v-r 
of any package is a bad plan. There is just too much diversity in why or 
how someone changes those.


-sv



From rjones at redhat.com  Wed Nov 19 17:11:14 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 19 Nov 2008 17:11:14 +0000
Subject: Heads up: OCaml 3.11.0 rebuild for Fedora 11
In-Reply-To: <20081118174914.GA27575@amd.home.annexia.org>
References: <20081118174914.GA27575@amd.home.annexia.org>
Message-ID: <20081119171114.GA1584@amd.home.annexia.org>

The complete rebuild went surprisingly well.  Out of 48 packages named
'ocaml*', these are the 9 packages which _failed_ to build on my local
(x86-64) machine:

  ocaml-type-conv   camlp4 problem, already fixed upstream
  ocaml-gsl         strange problem in String.index_from function
  ocaml-gettext        "
  ocaml-pxp            "
  ocaml-cil         some sort of build system problem
  ocaml-omake       undefined reference to caml_sync
  ocaml-pa-monad    tighter module naming restrictions in 3.11 breaks this
  ocaml-sexplib     requires ocaml-type-conv, see above
  ocaml-bitstring   requires ocaml-cil, also has a known camlp4 problem

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 rc040203 at freenet.de  Wed Nov 19 17:21:09 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 19 Nov 2008 18:21:09 +0100
Subject: F11 Proposal: Stabilization
In-Reply-To: <1227113846.4419.150.camel@dhollis-lnx>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<1227070185.3752.639.camel@beck.corsepiu.local>
	<1227112290.7387.27.camel@localhost.localdomain>
	<alpine.LFD.2.00.0811191145010.10340@localhost.localdomain>
	<1227113846.4419.150.camel@dhollis-lnx>
Message-ID: <1227115269.3752.707.camel@beck.corsepiu.local>

On Wed, 2008-11-19 at 11:57 -0500, David Hollis wrote:
> On Wed, 2008-11-19 at 11:45 -0500, Seth Vidal wrote:
> > i
> > 
> > On Wed, 19 Nov 2008, Callum Lerwick wrote:
> > 
> > > No actually it's simpler than that. What we want is more like package
> > > holds. More precisely, we want the *opposite* of package holds.
> > >
> > > What we're talking about here is a mode where no packages are updated,
> > > except for security fixes, and a list of packages I know I want the
> > > latest and greatest of.
> > >
> > > Which is pretty much that command line up there, plus security updates.
> > > Except it's sticky. Really that's something that annoys the hell out of
> > > me about yum, nothing sticks. If a repo is broken and needs to be
> > > disabled, or if I want to 'hold' a package I know is broken, I have to
> > > go mucking about in config files. And that results in my repo files no
> > > longer being updated because they've been modified and RPM so helpfully
> > > starts spewing .rpmnew files all over...
> > >
> > > When are we going to get the ability to store arbitrary bits of
> > > information about packages in the RPM database? We just need a simple
> > > generic key=value system. So front ends can store stuff like what repo
> > > the package came from, 'is-dep' flags, hold flags, dont-hold flags, and
> > > so on, but RPM itself doesn't have to actually know or care what they
> > > mean.
> > 
> > If you want to do this now, you can, via plugins. What you're describing 
> > above is fairly painful, though. It ultimately works out to be a mechanism 
> > for excluding updates, though.
> 
> 
> Generally, if a package update is just a release-level bump, it's fairly
> minor change and isn't likely to affect anything.
Pardon, but that's not true. 

Any guess on a package update's severity based on a package's EVR is
just a random guess.

>   If the actual version
> portion changes (such as with the kernel, firefox, openoffice), there is
> a lot room for things to be affected.  What if yum/PackageKit had a flag
> to only update packages that only have a release bump.  

I fail to see the usefulness for this.

> I'm sure everyone can come up with a case where package-3.1.2-4 broke
> stuff that worked with package-3.1.2-3 though those would be fringe
> cases.
Exactly. You'd be missing all those tiny fixes packagers typically apply
to their packages. Sometimes, these may fix severe issues - You simply
don't know.

> I could be wrong.
> 
> In all reality of course, and as a lot of the folks on this thread
> already realize, is that if an effort to maintain stability is going to
> take considerable time and resources, it just isn't going to happen.
> That's why a lot of people don't like running EL5 or CentOS on their
> desktop, the bits don't get updated and you want all the new gee-whiz
> stuff.  I've converted all of my servers over to CentOS over the last
> year or so not so much out of stability issues, but rather not wanting
> to hvae to upgrade them every 6-12 months to stay current when
> everything is working just fine.
> 
> It really seems like that is pretty much how it's supposed to work to
> me.  Desktop/bleeding edge - go Fedora.  Stable, long-term support,
> servers doing standard server stuff - EL/CentOS.
I still think, people involved into this thread are mixing up things and
are using different definitions of "stable".

To me, "stable" means "run-time stable"/"applications work"/"system
doesn't break down", it doesn't mean "API/ABI stable" (such as CentOS),
nor choking package update streams/package maintenance workflow (What
others seem to be having in mind).

Ralf




From bruno at wolff.to  Wed Nov 19 17:25:35 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 19 Nov 2008 11:25:35 -0600
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <m3fxloqfff.fsf@ursa.amorsen.dk>
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>
	<20081117213116.GA25672@mokona.greysector.net>
	<4922C0D5.4070209@redhat.com> <gfv4jp$abq$1@ger.gmane.org>
	<1227036667.28543.7.camel@luminos.localdomain>
	<981da310811181555o3b4f0a7die4a4df37a5f7ecba@mail.gmail.com>
	<20081119042022.GA19589@wolff.to> <m3fxloqfff.fsf@ursa.amorsen.dk>
Message-ID: <20081119172535.GA31677@wolff.to>

On Wed, Nov 19, 2008 at 09:37:56 +0100,
  Benny Amorsen <benny+usenet at amorsen.dk> wrote:
> Bruno Wolff III <bruno at wolff.to> writes:
> 
> > How about getting the people in charge of deciding what format to publish
> > content in, to not use crappy, security hole ridden, propietary formats.
> 
> The main competitors are Java and Silverlight. Neither seems
> particularly appealing.
> 
> Some things you can replace with either plain embedded video or AJAX,
> but not everything.

For normal web browsing, you shouldn't need to use Java, Silverlight or
Javascript. All of those are too powerful to let random web sites execute
on your local machine.

It's different if a trusted server is using your browser as an app platform.
I am not a great fan of that either because there aren't great tools in
Firefox to separate sites into ones that are providing trusted apps as
opposed to everyone else. (Noscript comes close, but seems a bit fragile
to me.) This can be an inexpensive way to provide apps that run on a lot
of platforms, so I see why people do it.



From cmadams at hiwaay.net  Wed Nov 19 18:03:16 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 19 Nov 2008 12:03:16 -0600
Subject: Rawhide boot failure (2008-11-15)
In-Reply-To: <1227065218.13047.8.camel@aglarond.local>
References: <20081115213208.GA883445@hiwaay.net>
	<20081119032003.GA1375334@hiwaay.net>
	<1227065218.13047.8.camel@aglarond.local>
Message-ID: <20081119180316.GE1505324@hiwaay.net>

Once upon a time, Jeremy Katz <katzj at redhat.com> said:
> > Am I the only one seeing this?  I still get this trying to boot from
> > rawhide-i386 boot.iso (2008-11-18).
> 
> No, it was seen and fixed up this morning

Thanks.
-- 
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 orion at cora.nwra.com  Wed Nov 19 18:32:36 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Wed, 19 Nov 2008 11:32:36 -0700
Subject: Heads up: OCaml 3.11.0 rebuild for Fedora 11
In-Reply-To: <20081119171114.GA1584@amd.home.annexia.org>
References: <20081118174914.GA27575@amd.home.annexia.org>
	<20081119171114.GA1584@amd.home.annexia.org>
Message-ID: <49245BC4.8040001@cora.nwra.com>

Richard W.M. Jones wrote:
> The complete rebuild went surprisingly well.  Out of 48 packages named
> 'ocaml*', these are the 9 packages which _failed_ to build on my local
> (x86-64) machine:
> 
>   ocaml-type-conv   camlp4 problem, already fixed upstream
>   ocaml-gsl         strange problem in String.index_from function
>   ocaml-gettext        "
>   ocaml-pxp            "
>   ocaml-cil         some sort of build system problem
>   ocaml-omake       undefined reference to caml_sync
>   ocaml-pa-monad    tighter module naming restrictions in 3.11 breaks this
>   ocaml-sexplib     requires ocaml-type-conv, see above
>   ocaml-bitstring   requires ocaml-cil, also has a known camlp4 problem
> 
> Rich.
> 

Can you test plplot?

-- 
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 seg at haxxed.com  Wed Nov 19 18:38:16 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Wed, 19 Nov 2008 12:38:16 -0600
Subject: F11 Proposal: Stabilization
In-Reply-To: <alpine.LFD.2.00.0811191145010.10340@localhost.localdomain>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<1227070185.3752.639.camel@beck.corsepiu.local>
	<1227112290.7387.27.camel@localhost.localdomain>
	<alpine.LFD.2.00.0811191145010.10340@localhost.localdomain>
Message-ID: <1227119897.7387.136.camel@localhost.localdomain>

On Wed, 2008-11-19 at 11:45 -0500, Seth Vidal wrote:
> It ultimately works out to be a mechanism for excluding updates, though.

That's kind of the point. What you call "excluding updates" I call
"Holding the system in a known good state".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081119/6b60169d/attachment.sig>

From seg at haxxed.com  Wed Nov 19 18:38:26 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Wed, 19 Nov 2008 12:38:26 -0600
Subject: My roadmap for a better Fedora
Message-ID: <1227119906.7387.138.camel@localhost.localdomain>

So, many pieces of this have been blabbed about by me and others
recently and in the past, but I think a lot of people aren't seeing the
big picture. I think it's time I fit it all together.

Problem: Fedora is buggy, and updates are rife with regressions.

Solution: We need more and wider testing.

Problem: We need more and wider testing. Why don't we get more testing?
Thw reason *I* don't go out of my way to test updates, is if there's a
regression, it's such a pain in the ass to get the system back to a
known good state and keep it that way, and report a bug. If it's a pain
in the ass for me, it's impossible for Aunt Tillie.

Solution:

1) Make it easy to report bugs. Bugzilla is complex, slow, and
inscrutable. We need to put a simpler layer on top of it. Reporting a
bug should require just a few clicks. It should automatically include
all the information needed for the bug report, the distro version,
package version, arch, and things such as how the Xorg team demands your
xorg.conf and Xorg.0.log. Make finding dupes easier. Collect stack
traces system wide and enter them in a database, which bugzilla can
reference and from which bugzilla bugs can be derived. A system wide
kerneloops. (I know this has been talked about, what's the status?)

2) Make it simple to roll back to a known good state. We need a "system
restore". I know what you're thinking, but our vastly superior,
centralized, system-wide package management (and lack of a whole
seperate "system registry" namespace) allows us to make this actually
work. We need per-package rollback. Period.

3) Make it so yum will refuse to upgrade the package rolled back in step
2 until the bug reported in step 1 is fixed.

4) For when things go really wrong, we need a rescue image in /boot. All
the above functionality must be available inside the rescue environment.

5) So how do bugs get fixed? Make it easy to cherry pick updates from
updates-testing or even direct from bodhi. How useful is it to blindly
follow every update in updates testing? For most users, it's useless.
Such adventurous people should probably just run rawhide... What we
really need is to make it easy to pick a specific release of an update
to try, such as if a user is directed to in a bug report. A user should
just be able to click on a link given in the bug report and have the
update installed. Available updates and the reasons for them needs to be
more discoverable. Don't forget step #2.

See how these things build upon and support each other?

Notice here I'm talking purely about user interface, about the end user
experience. The technical infrastructure follows from this, and I'll
save that discussion for another message. Infrastructure supports
functionality, not the other way around. I don't want to hear any "Oh
but we can't do this because blah blah technical objection blah makes
this hard". I hereby dub this the "Hard problem fallacy". Engineers
solve hard problems, that's what we do. I want to hear "To do this we
need to do x y z". The only objections I will accept are of the form
"You are an idiot and your ideas are stupid. We're not doing this."

I should probably put this on the Wiki so it doesn't get lost...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081119/2d88a28b/attachment.sig>

From rjones at redhat.com  Wed Nov 19 18:34:25 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 19 Nov 2008 18:34:25 +0000
Subject: Heads up: OCaml 3.11.0 rebuild for Fedora 11
In-Reply-To: <49245BC4.8040001@cora.nwra.com>
References: <20081118174914.GA27575@amd.home.annexia.org>
	<20081119171114.GA1584@amd.home.annexia.org>
	<49245BC4.8040001@cora.nwra.com>
Message-ID: <20081119183425.GA2239@amd.home.annexia.org>

On Wed, Nov 19, 2008 at 11:32:36AM -0700, Orion Poplawski wrote:
> Richard W.M. Jones wrote:
>> The complete rebuild went surprisingly well.  Out of 48 packages named
>> 'ocaml*', these are the 9 packages which _failed_ to build on my local
>> (x86-64) machine:
>>
>>   ocaml-type-conv   camlp4 problem, already fixed upstream
>>   ocaml-gsl         strange problem in String.index_from function
>>   ocaml-gettext        "
>>   ocaml-pxp            "
>>   ocaml-cil         some sort of build system problem
>>   ocaml-omake       undefined reference to caml_sync
>>   ocaml-pa-monad    tighter module naming restrictions in 3.11 breaks this
>>   ocaml-sexplib     requires ocaml-type-conv, see above
>>   ocaml-bitstring   requires ocaml-cil, also has a known camlp4 problem
>>
>> Rich.
>
> Can you test plplot?

Yes don't worry, I will test everything!  I was just doing the ocaml-*
(ie. library) packages first because they're the most essential :-)

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 dledford at redhat.com  Wed Nov 19 18:43:02 2008
From: dledford at redhat.com (Doug Ledford)
Date: Wed, 19 Nov 2008 13:43:02 -0500
Subject: My roadmap for a better Fedora
In-Reply-To: <1227119906.7387.138.camel@localhost.localdomain>
References: <1227119906.7387.138.camel@localhost.localdomain>
Message-ID: <1227120182.4687.137.camel@firewall.xsintricity.com>

On Wed, 2008-11-19 at 12:38 -0600, Callum Lerwick wrote:
> So, many pieces of this have been blabbed about by me and others
> recently and in the past, but I think a lot of people aren't seeing the
> big picture. I think it's time I fit it all together.
> 
> Problem: Fedora is buggy, and updates are rife with regressions.
> 
> Solution: We need more and wider testing.
> 
> Problem: We need more and wider testing. Why don't we get more testing?
> Thw reason *I* don't go out of my way to test updates, is if there's a
> regression, it's such a pain in the ass to get the system back to a
> known good state and keep it that way, and report a bug. If it's a pain
> in the ass for me, it's impossible for Aunt Tillie.
> 
> Solution:
> 
> 1) Make it easy to report bugs. Bugzilla is complex, slow, and
> inscrutable. We need to put a simpler layer on top of it. Reporting a
> bug should require just a few clicks. It should automatically include
> all the information needed for the bug report, the distro version,
> package version, arch, and things such as how the Xorg team demands your
> xorg.conf and Xorg.0.log. Make finding dupes easier. Collect stack
> traces system wide and enter them in a database, which bugzilla can
> reference and from which bugzilla bugs can be derived. A system wide
> kerneloops. (I know this has been talked about, what's the status?)
> 
> 2) Make it simple to roll back to a known good state. We need a "system
> restore". I know what you're thinking, but our vastly superior,
> centralized, system-wide package management (and lack of a whole
> seperate "system registry" namespace) allows us to make this actually
> work. We need per-package rollback. Period.
> 
> 3) Make it so yum will refuse to upgrade the package rolled back in step
> 2 until the bug reported in step 1 is fixed.
> 
> 4) For when things go really wrong, we need a rescue image in /boot. All
> the above functionality must be available inside the rescue environment.
> 
> 5) So how do bugs get fixed? Make it easy to cherry pick updates from
> updates-testing or even direct from bodhi. How useful is it to blindly
> follow every update in updates testing? For most users, it's useless.
> Such adventurous people should probably just run rawhide... What we
> really need is to make it easy to pick a specific release of an update
> to try, such as if a user is directed to in a bug report. A user should
> just be able to click on a link given in the bug report and have the
> update installed. Available updates and the reasons for them needs to be
> more discoverable. Don't forget step #2.
> 
> See how these things build upon and support each other?
> 
> Notice here I'm talking purely about user interface, about the end user
> experience. The technical infrastructure follows from this, and I'll
> save that discussion for another message. Infrastructure supports
> functionality, not the other way around. I don't want to hear any "Oh
> but we can't do this because blah blah technical objection blah makes
> this hard". I hereby dub this the "Hard problem fallacy". Engineers
> solve hard problems, that's what we do. I want to hear "To do this we
> need to do x y z". The only objections I will accept are of the form
> "You are an idiot and your ideas are stupid. We're not doing this."
> 
> I should probably put this on the Wiki so it doesn't get lost...

Agreed.

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081119/7d6a3d7f/attachment.sig>

From skvidal at fedoraproject.org  Wed Nov 19 18:42:09 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 19 Nov 2008 13:42:09 -0500 (EST)
Subject: F11 Proposal: Stabilization
In-Reply-To: <1227119897.7387.136.camel@localhost.localdomain>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<1227070185.3752.639.camel@beck.corsepiu.local>
	<1227112290.7387.27.camel@localhost.localdomain>
	<alpine.LFD.2.00.0811191145010.10340@localhost.localdomain>
	<1227119897.7387.136.camel@localhost.localdomain>
Message-ID: <alpine.LFD.2.00.0811191341180.10340@localhost.localdomain>



On Wed, 19 Nov 2008, Callum Lerwick wrote:

> On Wed, 2008-11-19 at 11:45 -0500, Seth Vidal wrote:
>> It ultimately works out to be a mechanism for excluding updates, though.
>
> That's kind of the point. What you call "excluding updates" I call
> "Holding the system in a known good state".

My point, however, is that all the bits already exist for excluding 
updates.

Whatever criteria or mechanism you want to use to create that list of 
excluded pkgs is up to you and completely fine.

-sv



From jspaleta at gmail.com  Wed Nov 19 19:07:26 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 19 Nov 2008 10:07:26 -0900
Subject: My roadmap for a better Fedora
In-Reply-To: <1227119906.7387.138.camel@localhost.localdomain>
References: <1227119906.7387.138.camel@localhost.localdomain>
Message-ID: <604aa7910811191107u4dc41d6eubdc634e14174ede8@mail.gmail.com>

2008/11/19 Callum Lerwick <seg at haxxed.com>:
> 1) Make it easy to report bugs. Bugzilla is complex, slow, and
> inscrutable. We need to put a simpler layer on top of it. Reporting a
> bug should require just a few clicks. It should automatically include
> all the information needed for the bug report, the distro version,
> package version, arch, and things such as how the Xorg team demands your
> xorg.conf and Xorg.0.log. Make finding dupes easier. Collect stack
> traces system wide and enter them in a database, which bugzilla can
> reference and from which bugzilla bugs can be derived. A system wide
> kerneloops. (I know this has been talked about, what's the status?)

Maybe you can help do what's necessary to get apport integrated into
our infrastructure.
http://fedoraproject.org/wiki/Releases/FeatureApport
>
> 2) Make it simple to roll back to a known good state. We need a "system
> restore". I know what you're thinking, but our vastly superior,
> centralized, system-wide package management (and lack of a whole
> seperate "system registry" namespace) allows us to make this actually
> work. We need per-package rollback. Period.

Let me point out that rollback itself would require testing.
Obsoletes, triggers, (un)post/pre scripts, config file handling... all
this rpm functionality complicates how successful rollbacks are to get
you back to a restored system state. How are we going to test if a
rollback works before you ask people to perform the rollback?

Just start with obsoletes... describe to me how we rollback after an
obsolete calculation has occurred as part of an update transaction.

-jef



From lesmikesell at gmail.com  Wed Nov 19 19:24:06 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 19 Nov 2008 13:24:06 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1227110198.4687.108.camel@firewall.xsintricity.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>	<1226593460.13077.91.camel@aglarond.local>	<20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>	<20081113223242.GB4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>	<1226678932.636.40.camel@aglarond.local>	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>	<1226686948.13086.44.camel@aglarond.local>	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>	<1226700116.13086.116.camel@aglarond.local>	<491FBA0E.2070003@gmail.com>	<1227043592.4687.9.camel@firewall.xsintricity.com>	<49234139.1050400@gmail.com>	<1227057520.4687.45.camel@firewall.xsintricity.com>	<4923836B.1090309@gmail.com>
	<1227110198.4687.108.camel@firewall.xsintricity.com>
Message-ID: <492467D6.7050803@gmail.com>

Doug Ledford wrote:
>
>>> That's not true.  The relating of numbers/names to wires is an arbitrary
>>> abstraction, and one that need not be the *only* possible abstraction.
>>> I admit it's handy and common, especially with servers.  And certainly
>>> you want a server to get the same address from boot to boot, especially
>>> if it's a live server on the internet with people coming to it (or live
>>> server on an intranet).  But, the eth0 naming is really
>>> irrelevant...
>> It's not irrelevant in the context of a unix-like system where devices 
>> are identified by name and you want to clone a bazillion copies of a 
>> machine.
> 
> This is a circular argument.  I argued that the eth0 naming is arbitrary
> and could be done differently, you say it can't be done differently
> because you do it that way now.

No, what I'm saying is that to manage servers you need a way to identify 
NICs that is not arbitrary.  And that changing the convention, 
particularly in arbitrary ways, is expensive.  All previously working 
procedures have to be re-invented and re-tested.  And this is 
particularly a problem when the differences in new behavior are subtle 
and only appear randomly after the copied disk is moved to its remote 
location.

>>> it's the hardware mac address that matters.
>> It is now.  In the 2.4 kernel days I could copy a system disk from an 
>> identical machine, change the hostname and IP address for eth0, eth1, 
>> etc.
> 
> At the point you clone a disk and then manually edit the eth0, eth1,
> etc. addresses, you are no longer strictly cloning.  You are
> customizing.  The choice of customization is arbitrary.

Agreed, but when the kernel hardware detection order was predictable, 
this was simple.  Now it isn't.

>  hether you
> customize the disk by cloning and editing, or by using something like
> cobbler to clone the install via a profile and then have cobbler
> customize the addresses based upon its database is merely
> implementation.  And that's my point, there are better implementations
> to be had.

Errr, doesn't having to build server to run cobbler before you can 
install your real server make this a circular argument too?  Assuming I 
wanted a cobbler server at every remote location instead of shipping a 
pre-configured disk, how would I build it when it needs a cobbler server 
first?

> 
>>  and ship a box of them to remote locations where anyone could 
>> insert them into a chassis and have them come up working.  Now it 
>> doesn't work and I either have to know every target mac address and 
>> match up the disks or talk some 'hands-on' operator through the setup 
>> with a console on a crash cart to get the address assignment done.  Is 
>> that an improvement?
> 
> Failure to use tools that automate this sort of thing is not a valid
> indictment of the infrastructure that's been put in place.

What tools don't involve the bootstrap problem - or are suitable for 
isolated remote servers?  Or maintaining a diverse set of OS's?

>>>  Being able to
>>> go from wire to mac address matters, and going from mac address to
>>> configuration matters.  Whether that configuration is called eth0 or
>>> pr0n_serv0 doesn't really matter.  To use a similar situation that we've
>>> already changed, back in the day, the only way to mount your root
>>> filesystem was by device major:minor.  Eventually, we figured out that
>>> since file systems have unique identifiers, we could screw the
>>> major:minor pair and mount by label instead.
>> That sucked too, if you recall what happened when you tried to re-use a 
>> disk, putting one you had used before into the same chassis as a current 
>> one.  For the first year or so after this change was made, this scenario 
>> would result in a machine that _would not even boot_.
> 
> Anaconda uses default labels for devices. 

Which is obviously an unrealistic design, knowing that disks can be 
re-used and moved around (and if they weren't there was nothing wrong 
with the old way of identifying them by partition name).  The change 
doesn't solve the real problem and breaks anything using prior 
documented behavior.

> You could have done a small
> post script during a kickstart install to rectify this.  One loop to
> modify all the device labels of filesystems to a unique label based
> upon, say, hostname + mount point, eg. firewall-10.0.1-root as a
> filesystem label combined with modifying the entries in fstab, then a
> final line to rebuild the initrd image.  This sort of thing can be
> automated easily in cobbler such that the default kickstart template
> need not know about each machines name/purpose, you can use variable
> substitution to do what you want.

Lovely.  I just sit around waiting for extra work like that - especially 
version-specific stuff.  And it misses the point that I want to be able 
to shove a disk into chassis slots in a certain order and know what to 
call a partition on a particular physical disk regardless of where it 
was used before.  Plus,  the concepts are wildly different when you use 
md devices (and probably LVM's too but I've avoided those completely).

>> And I think you are entirely off-base in terms of making it harder for 
>> someone who knows which device is which to actually identify it to the 
>> OS. I won't say it would be impossible to make things better but so far 
>> it has just created more work.
> 
> Actually, it has created less work for those people that utilized the
> tools that have been created to automate these things.  In your case,
> you already mention having to go in and hand edit network settings any
> time you clone a disk for a new machine.  That's not 0 work.

It is the minimal amount of work to get a correct setup.  The 
information needed to set the hostname and IP addresses has to be known 
and entered somewhere.

> Yet, with
> things like cobbler, there is a certain amount of work to get things set
> up initially, but once that's done, the amount of work goes down.

Please start from scratch here.  How does that cobbler server get 
installed?  How does it make it less work to get from the person who 
knows the hostname and IP addresses to the machine than entering it 
directly?  What if you want to replace the OS with a platform cobbler 
won't install?

> Your
> real complaint is that your work has gone up *because* you choose not to
> make use of these tools or better methods of doing things.

Yes, I choose not to use them because they aren't appropriate for my 
usage.  They require a large amount of infrastructure work and only 
serve a specific OS - and probably only one or a few versions before you 
have to rebuild your infrastructure again.

> I don't know
> what to say to that.  If your going to do things the 1980s way and no
> other, then I'm not sure there's anything that anyone can do to make
> your life easier.

What can possibly be easier than typing 'dd'?  I like unix-like systems 
because everything is a file or a stream of bytes and those don't take 
specialized tools to manage.  If you want a copy of something, you copy 
it, including the raw disk containing the whole system.  If it becomes 
something that takes specialized tools to touch every specialized device 
in its own special way, I won't be interested any more.

Actually I use drbl and clonezilla to make most copies because it really 
is easier than typing 'dd', but that's a practical, not a philosophical 
choice - the effect is the same.  The tool simply has to be able to 
handle multiple OS versions and the bulk of our systems are still 
running windows.

>>>> For people who have already automated these processes, try not to screw 
>>>> it up too badly.  If the way it is done now didn't work, we wouldn't 
>>>> have an internet.
>>> I'm sure it won't screw existing setups unless there is an overwhelming
>>> compelling reason.
>> But the changes you mentioned already have.
> 
> Not for those of us doing things in any way other than the old way.

How do you deal with overlap?  How much human time did it take to 
maintain working services on a large set of machines across the changes 
from, say RH7.3 (probably the first really reliable version) up through 
current?  How much of that 'other way' is useful in a mixed OS environment?

>> I don't want dynamic devices on my servers.  I want to know exactly what 
>> they are and how they are named by the OS.  And I want a hundred of them 
>> with image-copied disks to all work the same way.
> 
> But that's the fallacy of your argument, things *didn't* work that way,
> ever.  At least not under linux.  A device failure could cause sdb to
> become sda,

Ummm, OK - so are you implying that having a label on a partition on sda 
is useful in that circumstance?  Things that break just have to be 
replaced before they work again.  The way md devices work is sort-of ok, 
if you've handled the special case for booting, but they worked that way 
all along.   I'll agree that linux got most of the things it didn't copy 
from sysvr4 wrong in the first place including scsi drive naming, but 
changing 'detection order' naming to 'labels likely to be duplicates' 
isn't a good fix.

> or a BIOS or kernel update could cause eth0 and eth1 to flip
> flop. 

Kernel updates didn't do that until the 2.6 series.  And bios updates 
usually don't take me by surprise.

> The changes that were made were to deal with real world
> situations that you get to ignore because you tightly control your
> setups. 

Yes, I'm running servers.  You know - the big use for Linux...  I have 
old systems and new systems running simultaneously.  I want procedures 
that don't require changing everything at once or training operators to 
know the difference between versions for concepts that have not really 
changed - like mounting a disk partition or assigning an IP address to 
an interface.

> If you embraced some of these changes and worked *with* them
> instead of disabling them, then you might be able to loosen up some of
> that control and find that things still work like they are supposed to.

I have very little interest in converting to procedures that only work 
with one or a few versions of one distribution of one OS.  I'd be 
_slightly_ more interested if there were a clear development path toward 
those procedures as there once was before the RHEL/fedora split.  For 
example, back in the old days I could work on procedures and local 
applications on RHX.0 and not have too many surprises by the time it was 
production-ready around X.2.  With current fedora, there's no way to 
know what to expect to flow into an EL version or prepare for it.

>>   Some tools to deal 
>> with the changes being made could help with this but so far I haven't 
>> seen any.
> 
> I'm sorry, but you must not have looked very hard.  The tools are there,
> and they do a damn fine job.

Which tool besides clonezilla is good for cross platform work?  Are 
there even tools for a specific purpose like replacing a set of RHEL3 
servers with RHEL5 equivalents, maintaining the existing IP addresses on 
several interfaces each?  I eventually came up with something to scarf 
all the old ones from the running systems along with the corresponding 
mac addresses and included them in the clonezilla image with a script to 
patch things up but it wasn't pretty.

> I really think this all boils down to one simple fact: Fedora is
> supposed to bleeding edge, and that includes improving upon old, tired
> ways of doing things for better ways, and that seems to be anathema to
> you.  I hate to say it, but it sounds like what you really want is not
> Fedora, but OpenSolaris.

Agreed - I'd switch in a second if someone packaged it with drivers for 
all my hardware and the same userland we've been using for years.  You 
can see a history of understanding servers there that is missing in Linux.

> I'm afraid that as long as you want to
> maintain your setup the same as it has been for decades, that Fedora and
> the direction Fedora is heading in is going to continue to frustrate
> you.

When something has been working for decades why would anyone want to 
change it?  And if it hasn't been working, why even look at a unix-like 
system in the first place?

 > And I really hate to say that, because I *want* Fedora to be all
> things to all people, but realistically it can't.  And in this
> particular conflict, it's a case of "we have real world problems from
> some users so we fix those problems with a better way of doing things"
> versus your case of "in my particular world, these problems don't exist,
> so don't change things around" and I just don't know how to rectify
> those two positions.

The way to do it is to have the kernel and the hardware use predictable 
but unfriendly conventions for the 'real' names that connect drivers to 
hardware and some optional intermediate user level daemon that maps them 
to a friendly name in case there is a human involved instead of a script 
- like the old /dev/cdrom symlink.  In any case you need to look at some 
worst-case scenarios before applying any change to decide if it really 
helps anything or not.

Will any of the changes involving friendly identifiers for partitions 
help me when I connect a new unformatted drive?  Will any help with 
mounts that are done over nfs or cifs?  What about iscsi?  If I have to 
identify a new raw disk myself to make the partitions and filesystems 
when adding it, why do you think I need different terminology to 
identify the partitions  after that step is done?

Likewise with network interfaces: when what I want is some particular 
vlan from a trunk, will the changes help with that?

> In the end, Fedora is going to be true to its
> goals, including being bleeding edge and fixing things that are broken,
> and I don't think it's even possible to stop the march of that progress
> for the sake of your particular setup and working habits.  We can
> attempt to, but sometimes things simply must be changed in order to deal
> with other people's reality.

OK, but if you make server management harder or more specialized as a 
result of changes that only matter to desktop clients, don't expect 
anyone to run them.  I think you were on to something with OpenSolaris.

-- 
   Les Mikesell
     lesmikesell at gmail.com





From alsadi at gmail.com  Wed Nov 19 19:29:19 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Wed, 19 Nov 2008 21:29:19 +0200
Subject: a feature request: offline pkg installation from media
Message-ID: <385866f0811191129j2a3af544na19d4976a288ac03@mail.gmail.com>

I followed the in http://fedoraproject.org/wiki/Features/Policy/Ideas
and submitted this page
https://fedoraproject.org/wiki/Features/MediaRepos



From Jochen at herr-schmitt.de  Wed Nov 19 19:38:45 2008
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Wed, 19 Nov 2008 20:38:45 +0100
Subject: a feature request: offline pkg installation from media
In-Reply-To: <385866f0811191129j2a3af544na19d4976a288ac03@mail.gmail.com>
References: <385866f0811191129j2a3af544na19d4976a288ac03@mail.gmail.com>
Message-ID: <49246B45.90505@herr-schmitt.de>

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

Muayyad AlSadi schrieb:
> I followed the in
> http://fedoraproject.org/wiki/Features/Policy/Ideas and submitted
> this page https://fedoraproject.org/wiki/Features/MediaRepos
>
Here my mindflashes:

1.) It may be nice to have a frontend for createrepo to create a
repository on a media
for offline installation/updates.

2.) yum should be able to unterstand uri likes file://...

3.) It shoulb be able to put i yum.repo file on a media and specified
this file as

# yum --repo <repofile> ...

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkkazwACgkQT2AHK6txfgxPXQCg4AoLtXPYxA7uLbHUErN6UiKX
urQAn2eSlczcYbigDA5myNsWZ9lgj3a2
=f64n
-----END PGP SIGNATURE-----



From jkeating at redhat.com  Wed Nov 19 19:46:44 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 19 Nov 2008 11:46:44 -0800
Subject: a feature request: offline pkg installation from media
In-Reply-To: <49246B45.90505@herr-schmitt.de>
References: <385866f0811191129j2a3af544na19d4976a288ac03@mail.gmail.com>
	<49246B45.90505@herr-schmitt.de>
Message-ID: <1227124005.28543.290.camel@luminos.localdomain>

On Wed, 2008-11-19 at 20:38 +0100, Jochen Schmitt wrote:
> Here my mindflashes:
> 
> 1.) It may be nice to have a frontend for createrepo to create a
> repository on a media
> for offline installation/updates.

by frontend, do you mean graphical tool?  createrepo is a frontend to
itself, and has the ability to create repodata on media.  It's how we
create the repodata on CDs/DVDs.

> 
> 2.) yum should be able to unterstand uri likes file://...

It does.


-- 
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/20081119/53bc7a4a/attachment.sig>

From skvidal at fedoraproject.org  Wed Nov 19 19:49:19 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 19 Nov 2008 14:49:19 -0500 (EST)
Subject: a feature request: offline pkg installation from media
In-Reply-To: <1227124005.28543.290.camel@luminos.localdomain>
References: <385866f0811191129j2a3af544na19d4976a288ac03@mail.gmail.com>
	<49246B45.90505@herr-schmitt.de>
	<1227124005.28543.290.camel@luminos.localdomain>
Message-ID: <alpine.LFD.2.00.0811191448420.10340@localhost.localdomain>



On Wed, 19 Nov 2008, Jesse Keating wrote:

> On Wed, 2008-11-19 at 20:38 +0100, Jochen Schmitt wrote:
>> Here my mindflashes:
>>
>> 1.) It may be nice to have a frontend for createrepo to create a
>> repository on a media
>> for offline installation/updates.
>
> by frontend, do you mean graphical tool?  createrepo is a frontend to
> itself, and has the ability to create repodata on media.  It's how we
> create the repodata on CDs/DVDs.

If you want to see how to make a repo it's a pretty simple process and 
documented here:

http://yum.baseurl.org/wiki/RepoCreate


-sv



From jkeating at redhat.com  Wed Nov 19 19:51:06 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 19 Nov 2008 11:51:06 -0800
Subject: starting Fedora Server SIG
In-Reply-To: <492467D6.7050803@gmail.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>
	<1226686948.13086.44.camel@aglarond.local>
	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>
	<1226700116.13086.116.camel@aglarond.local>	<491FBA0E.2070003@gmail.com>
	<1227043592.4687.9.camel@firewall.xsintricity.com>
	<49234139.1050400@gmail.com>
	<1227057520.4687.45.camel@firewall.xsintricity.com>
	<4923836B.1090309@gmail.com>
	<1227110198.4687.108.camel@firewall.xsintricity.com>
	<492467D6.7050803@gmail.com>
Message-ID: <1227124266.28543.296.camel@luminos.localdomain>

On Wed, 2008-11-19 at 13:24 -0600, Les Mikesell wrote:
> Agreed, but when the kernel hardware detection order was predictable, 
> this was simple.  Now it isn't.

When was it predictable?  Even in the 2.4 era, we'd get one chassis
barebones from a vender like supermicro and the nic order would be one
way, then next month we'd order the same chassis barebones and the nics
would be picked up in a different order.  Even more fun is when they'd
change with a kernel update, so that the kernel we installed with had
one order, and the kernel we updated to and rebooted to had it in a
different order.

-- 
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/20081119/a0b2e35c/attachment.sig>

From seg at haxxed.com  Wed Nov 19 20:01:06 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Wed, 19 Nov 2008 14:01:06 -0600
Subject: My roadmap for a better Fedora
In-Reply-To: <604aa7910811191107u4dc41d6eubdc634e14174ede8@mail.gmail.com>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<604aa7910811191107u4dc41d6eubdc634e14174ede8@mail.gmail.com>
Message-ID: <1227124866.7387.157.camel@localhost.localdomain>

On Wed, 2008-11-19 at 10:07 -0900, Jeff Spaleta wrote:
> Maybe you can help do what's necessary to get apport integrated into
> our infrastructure.
> http://fedoraproject.org/wiki/Releases/FeatureApport

Meh, I was kind of thinking of working on the "rescue image in /boot"
first.

> > 2) Make it simple to roll back to a known good state. We need a "system
> > restore". I know what you're thinking, but our vastly superior,
> > centralized, system-wide package management (and lack of a whole
> > seperate "system registry" namespace) allows us to make this actually
> > work. We need per-package rollback. Period.
> 
> Let me point out that rollback itself would require testing.
> Obsoletes, triggers, (un)post/pre scripts, config file handling... all
> this rpm functionality complicates how successful rollbacks are to get
> you back to a restored system state. How are we going to test if a
> rollback works before you ask people to perform the rollback?

You do it in such a fundamentally simple manner as to be obviously
correct. You do it in a way that makes the system provably in the exact
same state as before, bit for bit. Think versioning filesystems. Think
distributed source control, applied to the entire filesystem. Think git.

There are many options here.

1) Ban everything that breaks rollbacks. Find some other way to do it.

2) Just refuse to rollback the packages that break rollback.

3) A combination of both

This is an example of where we need specific examples of scripts and
such that break rollback to get any farther on this.

First, could you please do something for me. Forget implementation.
Forget the details. Just answer this simple yes or no question:

Is rollback a desireable feature?

> Just start with obsoletes... describe to me how we rollback after an
> obsolete calculation has occurred as part of an update transaction.

I never said I have all the answers. I can't do this alone. "Many eyes
makes all engineering challenges shallow"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081119/6bd4da93/attachment.sig>

From lesmikesell at gmail.com  Wed Nov 19 20:01:23 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 19 Nov 2008 14:01:23 -0600
Subject: F11 Proposal: Stabilization
In-Reply-To: <alpine.LFD.2.00.0811191341180.10340@localhost.localdomain>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>	<1226958439.3814.6.camel@localhost.localdomain>	<49232E89.6020400@redhat.com>	<1227043890.28543.18.camel@luminos.localdomain>	<49233BE6.3080808@redhat.com>	<1227046097.28543.21.camel@luminos.localdomain>	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>	<1227070185.3752.639.camel@beck.corsepiu.local>	<1227112290.7387.27.camel@localhost.localdomain>	<alpine.LFD.2.00.0811191145010.10340@localhost.localdomain>	<1227119897.7387.136.camel@localhost.localdomain>
	<alpine.LFD.2.00.0811191341180.10340@localhost.localdomain>
Message-ID: <49247093.9020802@gmail.com>

Seth Vidal wrote:
> 
  >> On Wed, 2008-11-19 at 11:45 -0500, Seth Vidal wrote:
>>> It ultimately works out to be a mechanism for excluding updates, though.
>>
>> That's kind of the point. What you call "excluding updates" I call
>> "Holding the system in a known good state".
> 
> My point, however, is that all the bits already exist for excluding 
> updates.
> 
> Whatever criteria or mechanism you want to use to create that list of 
> excluded pkgs is up to you and completely fine.

Is it possible to give the client most of the control here?  That is, 
have something like a risk-scoring system where a new update going into 
a repo would have a default score of (say) 100 with this dropping over 
time to 0 unless new bugzilla entries are made for the package or 
someone explicitly bumps it up (or down to push security updates with 
little expected new risk).  That way engineering ultimately has control 
but under most circumstances could let people choose which of their 
machines is the bleeding-edge test and which waits for more testing.

The user could then select an acceptable risk level that would exclude 
updates with a higher score.   The default should probably be to take 
everything, but once users had stable systems doing important work, they 
could back off and give others a chance to report the problems.  Or, 
test themselves on a different machine, all working from a common 
repository.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From Jochen at herr-schmitt.de  Wed Nov 19 20:07:56 2008
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Wed, 19 Nov 2008 21:07:56 +0100
Subject: a feature request: offline pkg installation from media
In-Reply-To: <alpine.LFD.2.00.0811191448420.10340@localhost.localdomain>
References: <385866f0811191129j2a3af544na19d4976a288ac03@mail.gmail.com>	<49246B45.90505@herr-schmitt.de>	<1227124005.28543.290.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811191448420.10340@localhost.localdomain>
Message-ID: <4924721C.5050904@herr-schmitt.de>

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

Seth Vidal schrieb:
>> by frontend, do you mean graphical tool?  createrepo is a
>> frontend to itself, and has the ability to create repodata on
>> media.  It's how we create the repodata on CDs/DVDs.
>
Yes
> If you want to see how to make a repo it's a pretty simple process
> and documented here:
>
> http://yum.baseurl.org/wiki/RepoCreate
>
After I have read this page, I sure that yum support file:// uri. But
it may be nice, if you may
able to specifed relative pathes, so we have the follow file layout:

<mount point>
              !
              !-----------------> yum.repo
              1
              ------------------> <repo dir>

in the yum.repo file you have a reletive refernce to <repo dir>

If yum run the relas base uri may be build be the path of the mount point
and the relative bas uri specification from the yum.repo file.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkkchMACgkQT2AHK6txfgx9ywCfd7JuWqVv+IWIUnD0AZH9KoKp
jzQAoIj/57FbUagR5wNRdYtiUgzcEyr+
=6gIZ
-----END PGP SIGNATURE-----



From cdahlin at redhat.com  Wed Nov 19 20:15:54 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 19 Nov 2008 15:15:54 -0500
Subject: a feature request: offline pkg installation from media
In-Reply-To: <385866f0811191129j2a3af544na19d4976a288ac03@mail.gmail.com>
References: <385866f0811191129j2a3af544na19d4976a288ac03@mail.gmail.com>
Message-ID: <492473FA.4090007@redhat.com>

Muayyad AlSadi wrote:
> I followed the in http://fedoraproject.org/wiki/Features/Policy/Ideas
> and submitted this page
> https://fedoraproject.org/wiki/Features/MediaRepos
>
>   
Is this really a new feature? I could have sworn this was already 
possible. In fact I seem to remember systems installed from live CDs 
refusing to install any packages from /any/ source if the media wasn't 
in the drive as of a few releases back, due to the media being 
configured as a package source.

--CJD



From alsadi at gmail.com  Wed Nov 19 20:16:21 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Wed, 19 Nov 2008 22:16:21 +0200
Subject: a feature request: offline pkg installation from media
In-Reply-To: <alpine.LFD.2.00.0811191448420.10340@localhost.localdomain>
References: <385866f0811191129j2a3af544na19d4976a288ac03@mail.gmail.com>
	<49246B45.90505@herr-schmitt.de>
	<1227124005.28543.290.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811191448420.10340@localhost.localdomain>
Message-ID: <385866f0811191216y673662eq3406563c1bdd81fc@mail.gmail.com>

> 2.) yum should be able to unterstand uri likes file://...
that's something different
take this scenario, you have 3 installation CDs
KDE on CD2 needs libfoo on CD3
no createrepo or file:// could help you them

and yum API already support what I request, it's called media://
but package kit does not support it

> It may be nice to have a frontend for createrepo to create a
yes I made a hal/dbus/pynotify that creates a file in
/etc/yum.repos.d/ having file:// that points to the inserted media and
remove it when the media is ejected

but that is not the real solution



From alsadi at gmail.com  Wed Nov 19 20:21:02 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Wed, 19 Nov 2008 22:21:02 +0200
Subject: a feature request: offline pkg installation from media
In-Reply-To: <385866f0811191216y673662eq3406563c1bdd81fc@mail.gmail.com>
References: <385866f0811191129j2a3af544na19d4976a288ac03@mail.gmail.com>
	<49246B45.90505@herr-schmitt.de>
	<1227124005.28543.290.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811191448420.10340@localhost.localdomain>
	<385866f0811191216y673662eq3406563c1bdd81fc@mail.gmail.com>
Message-ID: <385866f0811191221h4df727d2p272152c87c5a1986@mail.gmail.com>

> I could have sworn this was already possible.

this **was** possible with F8 and its package manager which is dropped
and replaced with package kit

no other package manager support this feature now
take my word, I have tried them all GUI and CLI (smart, yumex,
apt-get, synaptic ...etc.)



From seg at haxxed.com  Wed Nov 19 20:24:32 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Wed, 19 Nov 2008 14:24:32 -0600
Subject: F11 Proposal: Stabilization
In-Reply-To: <bfdeacfa0811180541j338f4c2ah6aaaa0403ba5e2d9@mail.gmail.com>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<20081117213742.GB5603@nostromo.devel.redhat.com>
	<4921E683.30407@redhat.com>
	<604aa7910811171354h26c8eb30r72280cc95ba9a976@mail.gmail.com>
	<1226960219.4098.20.camel@perihelion.bos.jonmasters.org>
	<49229E4B.8030204@fedoraproject.org>
	<bfdeacfa0811180541j338f4c2ah6aaaa0403ba5e2d9@mail.gmail.com>
Message-ID: <1218b5bc0811191224m138358e5w2529ea9a564eb675@mail.gmail.com>

2008/11/18 Mark Bidewell <mark.bidewell at alumni.clemson.edu>:
> On Tue, Nov 18, 2008 at 5:51 AM, Rahul Sundaram <sundaram at fedoraproject.org>
> wrote:
>> Jon Masters wrote:
>>> I disagree. Various other communities (and distributions) have made a
>>> point out of "stable" releases where the "big ticket" feature is
>>> stabilization,
>>
>> Can you point out such communities and distros and tell us what they have
>
> Of the top of my head, CentOS and Debian come to mind.  Some might also put
> Ubuntu LTS and OpenSUSE in that list as well.

I find it amusing you give CentOS as your first example. Given it's
based directly on Fedora.

All those other distributions are able to give stability because WE
gave it to them. WE blazed the trail, and in turn WE take the shit for
it. Without us, they would either become us or stagnate and die.
Someone has to do it.

Fedora is the Mercedes S-Class of distributions. (Car analogy alert!)

http://en.wikipedia.org/wiki/Mercedes-Benz_S-Class

Regressions are inevitable. Why are people afraid of regressions?
Because it breaks their system. Why are people so afraid of breaking
their system? Because they're afraid they can't fix it.

Solution: Make recovery from regressions easy. So easy a trained
monkey could do it. Make it routine. Make it familiar and
non-threatening. Make it a normal part of everyone's daily life.

Embrace change. Embrace regressions, instability and bugs. Fedora is
Extreme Linux. I posted my roadmap for doing this in the "My roadmap
for a better Fedora" thread.

http://www.redhat.com/archives/fedora-devel-list/2008-November/msg01370.html



From dledford at redhat.com  Wed Nov 19 20:25:22 2008
From: dledford at redhat.com (Doug Ledford)
Date: Wed, 19 Nov 2008 15:25:22 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <492467D6.7050803@gmail.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>
	<1226686948.13086.44.camel@aglarond.local>
	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>
	<1226700116.13086.116.camel@aglarond.local>	<491FBA0E.2070003@gmail.com>
	<1227043592.4687.9.camel@firewall.xsintricity.com>
	<49234139.1050400@gmail.com>
	<1227057520.4687.45.camel@firewall.xsintricity.com>
	<4923836B.1090309@gmail.com>
	<1227110198.4687.108.camel@firewall.xsintricity.com>
	<492467D6.7050803@gmail.com>
Message-ID: <1227126323.4687.178.camel@firewall.xsintricity.com>

On Wed, 2008-11-19 at 13:24 -0600, Les Mikesell wrote:
> Doug Ledford wrote:
> No, what I'm saying is that to manage servers you need a way to identify 
> NICs that is not arbitrary.  And that changing the convention, 
> particularly in arbitrary ways, is expensive.  All previously working 
> procedures have to be re-invented and re-tested.  And this is 
> particularly a problem when the differences in new behavior are subtle 
> and only appear randomly after the copied disk is moved to its remote 
> location.

As I pointed out, mac addresses aren't arbitrary.  For example, on
certain boxen that have two embedded nics, the box will label one as the
first and as the second interface, and generally will tell you the mac
address for each.  Depending on the kernel version or kernel pci
options, they might be found in the right order or swapped.  But
assigning them by mac always gets it right.

> Agreed, but when the kernel hardware detection order was predictable, 
> this was simple.  Now it isn't.

The detection order was only predictable in the sense that it didn't
change, not that it was always right.  The 2.4 kernel got some of them
swapped, we just never corrected it in the 2.4 kernel series.  Note:
this isn't to refute what Jesse wrote, BIOS updates could cause a flip
flop, but we didn't alter sorting order in the kernel in the 2.4 series.
On the other hand, I *did* alter sorting order for aic7xxx adapters
during the 2.4 kernel series, but I included a kernel module option to
revert the change as needed.

> >  hether you
> > customize the disk by cloning and editing, or by using something like
> > cobbler to clone the install via a profile and then have cobbler
> > customize the addresses based upon its database is merely
> > implementation.  And that's my point, there are better implementations
> > to be had.
> 
> Errr, doesn't having to build server to run cobbler before you can 
> install your real server make this a circular argument too?  Assuming I 
> wanted a cobbler server at every remote location instead of shipping a 
> pre-configured disk, how would I build it when it needs a cobbler server 
> first?

No, this goes to the statement I made about some amount of setup cost
that then is made up for in time savings in the future.  And you only
need one cobbler server.  You can install the image on a local machine
and then ship the disc off (or if you can't, the concept of a local
install box used to create disc images destined for a remote box that
has a different mac address than the local install box wouldn't be a
hard thing to add to cobbler, but since you haven't tried it and haven't
brought up this need, it might not be in there yet).

> >>  and ship a box of them to remote locations where anyone could 
> >> insert them into a chassis and have them come up working.  Now it 
> >> doesn't work and I either have to know every target mac address and 
> >> match up the disks or talk some 'hands-on' operator through the setup 
> >> with a console on a crash cart to get the address assignment done.  Is 
> >> that an improvement?
> > 
> > Failure to use tools that automate this sort of thing is not a valid
> > indictment of the infrastructure that's been put in place.
> 
> What tools don't involve the bootstrap problem - or are suitable for 
> isolated remote servers?  Or maintaining a diverse set of OS's?

See above.  And cobbler has experimental support for SuSE and debian
systems.  I'm sure the authors would correct any bugs you might run
across in trying to use cobbler with those.  As for non-linux OSes,
especially windows, cloning is probably the right call.

> > You could have done a small
> > post script during a kickstart install to rectify this.  One loop to
> > modify all the device labels of filesystems to a unique label based
> > upon, say, hostname + mount point, eg. firewall-10.0.1-root as a
> > filesystem label combined with modifying the entries in fstab, then a
> > final line to rebuild the initrd image.  This sort of thing can be
> > automated easily in cobbler such that the default kickstart template
> > need not know about each machines name/purpose, you can use variable
> > substitution to do what you want.
> 
> Lovely.  I just sit around waiting for extra work like that - especially 
> version-specific stuff.

Like I said, it's a one time setup cost that is amortized over its
reuse.

>   And it misses the point that I want to be able 
> to shove a disk into chassis slots in a certain order and know what to 
> call a partition on a particular physical disk regardless of where it 
> was used before.

The unique filesystem labels I mentioned previously would achieve this
result too.

>   Plus,  the concepts are wildly different when you use 
> md devices (and probably LVM's too but I've avoided those completely).

md devices are 100% discover by label, not by disk partition.  It scans
the partitions and assembles based upon the labels therein.

> > Actually, it has created less work for those people that utilized the
> > tools that have been created to automate these things.  In your case,
> > you already mention having to go in and hand edit network settings any
> > time you clone a disk for a new machine.  That's not 0 work.
> 
> It is the minimal amount of work to get a correct setup.  The 
> information needed to set the hostname and IP addresses has to be known 
> and entered somewhere.

Yes, and it has to be redone every time you reimage a disk for that
machine.  On the other hand, when you enter the same information in
cobbler, it can (optionally) enter the information in your dhcpd.conf or
dnsmasq.conf, enter the information into your named zone file, and the
machine is now permanently in the database so any time you reimage that
same machine, it's all there ready to go.

> > Yet, with
> > things like cobbler, there is a certain amount of work to get things set
> > up initially, but once that's done, the amount of work goes down.
> 
> Please start from scratch here.  How does that cobbler server get 
> installed?  How does it make it less work to get from the person who 
> knows the hostname and IP addresses to the machine than entering it 
> directly?  What if you want to replace the OS with a platform cobbler 
> won't install?

See above.

> > Your
> > real complaint is that your work has gone up *because* you choose not to
> > make use of these tools or better methods of doing things.
> 
> Yes, I choose not to use them because they aren't appropriate for my 
> usage.  They require a large amount of infrastructure work and only 
> serve a specific OS - and probably only one or a few versions before you 
> have to rebuild your infrastructure again.

Not true.

> > I don't know
> > what to say to that.  If your going to do things the 1980s way and no
> > other, then I'm not sure there's anything that anyone can do to make
> > your life easier.
> 
> What can possibly be easier than typing 'dd'? 

Not having to type dd and then edit the results to get the right image?

>  I like unix-like systems 
> because everything is a file or a stream of bytes and those don't take 
> specialized tools to manage.

Nor do they fill in the right information for you.

>   If you want a copy of something, you copy 
> it, including the raw disk containing the whole system.  If it becomes 
> something that takes specialized tools to touch every specialized device 
> in its own special way, I won't be interested any more.
> 
> Actually I use drbl and clonezilla to make most copies because it really 
> is easier than typing 'dd', but that's a practical, not a philosophical 
> choice - the effect is the same.  The tool simply has to be able to 
> handle multiple OS versions and the bulk of our systems are still 
> running windows.
> 
> >>>> For people who have already automated these processes, try not to screw 
> >>>> it up too badly.  If the way it is done now didn't work, we wouldn't 
> >>>> have an internet.
> >>> I'm sure it won't screw existing setups unless there is an overwhelming
> >>> compelling reason.
> >> But the changes you mentioned already have.
> > 
> > Not for those of us doing things in any way other than the old way.
> 
> How do you deal with overlap?  How much human time did it take to 
> maintain working services on a large set of machines across the changes 
> from, say RH7.3 (probably the first really reliable version) up through 
> current?  How much of that 'other way' is useful in a mixed OS environment?

In a mixed linux environment, pretty much all of it.  For other OSes,
not so much.

> >> I don't want dynamic devices on my servers.  I want to know exactly what 
> >> they are and how they are named by the OS.  And I want a hundred of them 
> >> with image-copied disks to all work the same way.
> > 
> > But that's the fallacy of your argument, things *didn't* work that way,
> > ever.  At least not under linux.  A device failure could cause sdb to
> > become sda,
> 
> Ummm, OK - so are you implying that having a label on a partition on sda 
> is useful in that circumstance?  Things that break just have to be 
> replaced before they work again.

Except that this isn't the only situation.  You brought up the other one
yourself in that putting more than one disk in a machine is a valid use
case too.  As I pointed out, unique device labels eliminates the need to
know for certain if the two disks you added went in as sdb and sdc or
sdc and sdb.

>   The way md devices work is sort-of ok, 
> if you've handled the special case for booting, but they worked that way 
> all along.   I'll agree that linux got most of the things it didn't copy 
> from sysvr4 wrong in the first place including scsi drive naming, but 
> changing 'detection order' naming to 'labels likely to be duplicates' 
> isn't a good fix.

Unique labels is though.

> > or a BIOS or kernel update could cause eth0 and eth1 to flip
> > flop. 
> 
> Kernel updates didn't do that until the 2.6 series.  And bios updates 
> usually don't take me by surprise.
> 
> > The changes that were made were to deal with real world
> > situations that you get to ignore because you tightly control your
> > setups. 
> 
> Yes, I'm running servers.  You know - the big use for Linux...  I have 
> old systems and new systems running simultaneously.  I want procedures 
> that don't require changing everything at once or training operators to 
> know the difference between versions for concepts that have not really 
> changed - like mounting a disk partition or assigning an IP address to 
> an interface.
> 
> > If you embraced some of these changes and worked *with* them
> > instead of disabling them, then you might be able to loosen up some of
> > that control and find that things still work like they are supposed to.
> 
> I have very little interest in converting to procedures that only work 
> with one or a few versions of one distribution of one OS.

As I mentioned before, this isn't an accurate assessment of the support
cobbler provides.

>   I'd be 
> _slightly_ more interested if there were a clear development path toward 
> those procedures as there once was before the RHEL/fedora split.  For 
> example, back in the old days I could work on procedures and local 
> applications on RHX.0 and not have too many surprises by the time it was 
> production-ready around X.2.  With current fedora, there's no way to 
> know what to expect to flow into an EL version or prepare for it.
> 
> >>   Some tools to deal 
> >> with the changes being made could help with this but so far I haven't 
> >> seen any.
> > 
> > I'm sorry, but you must not have looked very hard.  The tools are there,
> > and they do a damn fine job.
> 
> Which tool besides clonezilla is good for cross platform work?  Are 
> there even tools for a specific purpose like replacing a set of RHEL3 
> servers with RHEL5 equivalents, maintaining the existing IP addresses on 
> several interfaces each?  I eventually came up with something to scarf 
> all the old ones from the running systems along with the corresponding 
> mac addresses and included them in the clonezilla image with a script to 
> patch things up but it wasn't pretty.

Yes.  Cobbler allows you to retarget a machine.  If a specific system
was registered as a rhel3 system you can simply change it's parent
profile to rhel5 and it will preserve all the ethernet information, etc.

> > I really think this all boils down to one simple fact: Fedora is
> > supposed to bleeding edge, and that includes improving upon old, tired
> > ways of doing things for better ways, and that seems to be anathema to
> > you.  I hate to say it, but it sounds like what you really want is not
> > Fedora, but OpenSolaris.
> 
> Agreed - I'd switch in a second if someone packaged it with drivers for 
> all my hardware and the same userland we've been using for years.  You 
> can see a history of understanding servers there that is missing in Linux.
> 
> > I'm afraid that as long as you want to
> > maintain your setup the same as it has been for decades, that Fedora and
> > the direction Fedora is heading in is going to continue to frustrate
> > you.
> 
> When something has been working for decades why would anyone want to 
> change it?  And if it hasn't been working, why even look at a unix-like 
> system in the first place?

Seriously?  It has to be 100% right the first time or move on?  Don't
try to fix anything that's not right?

>  > And I really hate to say that, because I *want* Fedora to be all
> > things to all people, but realistically it can't.  And in this
> > particular conflict, it's a case of "we have real world problems from
> > some users so we fix those problems with a better way of doing things"
> > versus your case of "in my particular world, these problems don't exist,
> > so don't change things around" and I just don't know how to rectify
> > those two positions.
> 
> The way to do it is to have the kernel and the hardware use predictable 
> but unfriendly conventions for the 'real' names that connect drivers to 
> hardware

Done.  For eth0 on my machine lspci reports:
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)

I can use that to go to /sys/bus/pci/devices/0000:04:00.0 and in there I
find a directory call net and in that directory is a directory named to
match the system name of the device (in my case eth0).  So no matter
what device name this would have gotten, if I want the ethernet device
in the particular pci slot this device occupies, going into the net
directory gives me that name.  A similar convention can be used to get
to any scsi device by pci device, then scsi controller, then host
number, channel number, target number, lun.

>  and some optional intermediate user level daemon that maps them 
> to a friendly name in case there is a human involved instead of a script 
> - like the old /dev/cdrom symlink.  In any case you need to look at some 
> worst-case scenarios before applying any change to decide if it really 
> helps anything or not.

Done.  udev does this.

> Will any of the changes involving friendly identifiers for partitions 
> help me when I connect a new unformatted drive?  Will any help with 
> mounts that are done over nfs or cifs?  What about iscsi?  If I have to 
> identify a new raw disk myself to make the partitions and filesystems 
> when adding it, why do you think I need different terminology to 
> identify the partitions  after that step is done?

See above about putting two disks in a machine to do whatever to them,
one of your use case scenarios.

> Likewise with network interfaces: when what I want is some particular 
> vlan from a trunk, will the changes help with that?

Going by mac address helps, certainly.  The eth names can flip flop all
day long, but in the end you know that cable X  with vlan Z is plugged
into the eth port with mac Y and you can set things up that way.

> > In the end, Fedora is going to be true to its
> > goals, including being bleeding edge and fixing things that are broken,
> > and I don't think it's even possible to stop the march of that progress
> > for the sake of your particular setup and working habits.  We can
> > attempt to, but sometimes things simply must be changed in order to deal
> > with other people's reality.
> 
> OK, but if you make server management harder or more specialized as a 
> result of changes that only matter to desktop clients, don't expect 
> anyone to run them.  I think you were on to something with OpenSolaris.

Harder, I don't think so.  Different, yes.  Requires learning, yes.  But
I don't think it's truly harder.  If anything, it requires less
specialized knowledge and custom hackery to get things done.

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081119/08e9489f/attachment.sig>

From lesmikesell at gmail.com  Wed Nov 19 20:26:19 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 19 Nov 2008 14:26:19 -0600
Subject: F11 Proposal: Stabilization
In-Reply-To: <1227112465.4355.146.camel@code.and.org>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>	<1226958439.3814.6.camel@localhost.localdomain>	<49232E89.6020400@redhat.com>	<1227043890.28543.18.camel@luminos.localdomain>	<49233BE6.3080808@redhat.com>	<1227046097.28543.21.camel@luminos.localdomain>	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>	<49234CE6.7050805@gmail.com>	<604aa7910811181554q238d59ber63bf99565a37558e@mail.gmail.com>	<492359B2.2010008@gmail.com>	<604aa7910811181622q6d2b7f92kf20853a6c9f8c2f1@mail.gmail.com>	<492378C7.6050408@gmail.com>	<1227064591.28543.34.camel@luminos.localdomain>	<4923C840.30101@shmuelhome.mine.nu>	<1227107699.28543.52.camel@luminos.localdomain>	<49243613.1050901@gmail.com>
	<1227112465.4355.146.camel@code.and.org>
Message-ID: <4924766B.80703@gmail.com>

James Antill wrote:
> 
>> That may or may not be true and it may or may not matter.  All you need 
>> is some large representative sample doing the early testing and a way to 
>> ensure feedback to improve everyone's experience.  And letting users 
>> control their exposure to new bugs might increase the user base in both 
>> categories.
> 
>  This is what updates-testing _already does_. As Jesse has already said,
> there are two big problems:
> 
> 1. Too many people want to be consumers of the testing but not the
> providers of it.

I think that's an unwarranted assumption.  How many people even know 
about updates-testing compared to people that never change defaults? 
How does someone using updates-testing ensure that their usage 
'provides' something?

>  Indeed IMO the whole updates-tested argument seems to devolve to "I'm
> going to be clever and switch to this, but I'm pretty sure a bunch of
> other people aren't going to know immediately and so will become my
> unwilling testers".

No, the argument is this:
If I had a way to be moderately sure that my main work machine would be 
usable every day running fedora and I could test things on a less 
important machine, I'd be much more likely to run fedora more of the 
time and on more machines.

> 2. The people who are the providers of the testing, aren't necessarily
> running the same kinds of workloads as the people who want to just be
> consumers of the testing.

Exactly - it doesn't work that well as is.  And even if I wanted to test 
exactly the same work on exactly the same kind of machine, I don't think 
I could predictably 'consume' that testing value - that is, there is no 
way for me to know when or if a 'yum update' on my production machine is 
going to reproduce exactly the software installed on my test machine. 
(Personally I think this is a generic yum problem and it should provide 
an option for reproducible installs regardless of what is going on in 
the repositories, but that's a slightly different issue...).

> ...and to be fair, there are certainly improvements that could be done
> on the tools side to help people test and report, and the limited
> resources currently available are working to make that better. But,
> personally, I don't see how an updates-tested or updates-after-1-month
> etc. etc. is going to help in the long run. Sure, in the short term.
> it'll help all the people that know about it at the expense of those
> that don't ... but that isn't a good feature, IMO.

I think there will always be a mix of machines where testing is 
appropriate and desired and ones where more predictability is a 
requirement and often the same people will have have some of both types. 
  The question is whether it is possible for fedora to be appropriate to 
run on both.  If it isn't, I don't see much value to be obtained from 
the testing part.  If it is possible to manage the repos or updating 
tool to do the right thing for both environments without a lot of extra 
work, I think you'd see a big increase in both usage types.

-- 
   Les Mikesell
    lesmikesell at gmail.com




From Jochen at herr-schmitt.de  Wed Nov 19 20:26:16 2008
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Wed, 19 Nov 2008 21:26:16 +0100
Subject: a feature request: offline pkg installation from media
In-Reply-To: <385866f0811191216y673662eq3406563c1bdd81fc@mail.gmail.com>
References: <385866f0811191129j2a3af544na19d4976a288ac03@mail.gmail.com>	<49246B45.90505@herr-schmitt.de>	<1227124005.28543.290.camel@luminos.localdomain>	<alpine.LFD.2.00.0811191448420.10340@localhost.localdomain>
	<385866f0811191216y673662eq3406563c1bdd81fc@mail.gmail.com>
Message-ID: <49247668.80101@herr-schmitt.de>

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

Muayyad AlSadi schrieb:
> that's something different take this scenario, you have 3
> installation CDs KDE on CD2 needs libfoo on CD3 no createrepo or
> file:// could help you them
>
I think this scenario may get difficuilt because yo want to avoid
that the used allway change the CD in the CD-ROM drive.
> and yum API already support what I request, it's called media://
> but package kit does not support it
That sound interesting.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkkdkUACgkQT2AHK6txfgy0owCgzKoLApBSKVZyubgizfabxWI6
JXgAnRH6F6QUJBmBjZAlKsZMGuf4xt3O
=3C+4
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081119/f0e5ac0a/attachment.htm>

From cdahlin at redhat.com  Wed Nov 19 20:35:12 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 19 Nov 2008 15:35:12 -0500
Subject: F11 Proposal: Stabilization
In-Reply-To: <1227112465.4355.146.camel@code.and.org>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>	<1226958439.3814.6.camel@localhost.localdomain>	<49232E89.6020400@redhat.com>	<1227043890.28543.18.camel@luminos.localdomain>	<49233BE6.3080808@redhat.com>	<1227046097.28543.21.camel@luminos.localdomain>	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>	<49234CE6.7050805@gmail.com>	<604aa7910811181554q238d59ber63bf99565a37558e@mail.gmail.com>	<492359B2.2010008@gmail.com>	<604aa7910811181622q6d2b7f92kf20853a6c9f8c2f1@mail.gmail.com>	<492378C7.6050408@gmail.com>	<1227064591.28543.34.camel@luminos.localdomain>	<4923C840.30101@shmuelhome.mine.nu>	<1227107699.28543.52.camel@luminos.localdomain>	<49243613.1050901@gmail.com>
	<1227112465.4355.146.camel@code.and.org>
Message-ID: <49247880.6030509@redhat.com>

James Antill wrote:
>
> 1. Too many people want to be consumers of the testing but not the
> providers of it.
>  Indeed IMO the whole updates-tested argument seems to devolve to "I'm
> going to be clever and switch to this, but I'm pretty sure a bunch of
> other people aren't going to know immediately and so will become my
> unwilling testers".
>   
One of Fedora's goals is to turn users into contributors. What better 
way to do that than to make every default-retaining user an unwitting 
brick in a colossal meat wall?

--CJD



From Jochen at herr-schmitt.de  Wed Nov 19 20:41:29 2008
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Wed, 19 Nov 2008 21:41:29 +0100
Subject: a feature request: offline pkg installation from media
In-Reply-To: <385866f0811191221h4df727d2p272152c87c5a1986@mail.gmail.com>
References: <385866f0811191129j2a3af544na19d4976a288ac03@mail.gmail.com>	<49246B45.90505@herr-schmitt.de>	<1227124005.28543.290.camel@luminos.localdomain>	<alpine.LFD.2.00.0811191448420.10340@localhost.localdomain>	<385866f0811191216y673662eq3406563c1bdd81fc@mail.gmail.com>
	<385866f0811191221h4df727d2p272152c87c5a1986@mail.gmail.com>
Message-ID: <492479F9.3020302@herr-schmitt.de>

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

Muayyad AlSadi schrieb:
> this **was** possible with F8 and its package manager which is
> dropped and replaced with package kit

I have got a look on the sources of you and have something about a
mediafunc
on yumRepo.py.

I assume the issue is, that we need a callback function on the fontend
which
allow the user to chage the media.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkked0ACgkQT2AHK6txfgxxDACgySisdvFGtDfo2wk8SdBAPqAG
57MAoJ4aWWZQgaL58jIytBqz67diKi4n
=cjfW
-----END PGP SIGNATURE-----



From lesmikesell at gmail.com  Wed Nov 19 20:44:24 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 19 Nov 2008 14:44:24 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1227124266.28543.296.camel@luminos.localdomain>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>	<1226593460.13077.91.camel@aglarond.local>	<20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>	<20081113223242.GB4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>	<1226678932.636.40.camel@aglarond.local>	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>	<1226686948.13086.44.camel@aglarond.local>	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>	<1226700116.13086.116.camel@aglarond.local>	<491FBA0E.2070003@gmail.com>	<1227043592.4687.9.camel@firewall.xsintricity.com>	<49234139.1050400@gmail.com>	<1227057520.4687.45.camel@firewall.xsintricity.com>	<4923836B.1090309@gmail.com>	<1227110198.4687.108.camel@firewall.xsintricity.com>	<492467D6.7050803@gmail.com>
	<1227124266.28543.296.camel@luminos.localdomain>
Message-ID: <49247AA8.6030506@gmail.com>

Jesse Keating wrote:
> On Wed, 2008-11-19 at 13:24 -0600, Les Mikesell wrote:
>> Agreed, but when the kernel hardware detection order was predictable, 
>> this was simple.  Now it isn't.
> 
> When was it predictable?  Even in the 2.4 era, we'd get one chassis
> barebones from a vender like supermicro and the nic order would be one
> way, then next month we'd order the same chassis barebones and the nics
> would be picked up in a different order.  Even more fun is when they'd
> change with a kernel update, so that the kernel we installed with had
> one order, and the kernel we updated to and rebooted to had it in a
> different order.

I'm pretty sure I cloned Centos 3.x across at least 50 IBM 336's with 
the NICs always being chosen in the same order.  The thing that really 
took me by surprise, though, was some mid-rev update (and I can't 
remember now if this was still 3.x or a later version) where the 
previously ignored HWADDR entries in the ifcfg-eth? files started being 
observed just to the point of not bringing up an interface that didn't 
match.  This was fun when the local test box didn't exhibit the problem 
but all of the remote headless boxes that previously worked fell off the 
network when rebooted.  I just happened to be in the right place by a 
console that happened to be connected to catch it one of the first times 
it happened.   I suppose that change was really a bugfix and it was 
supposed to work that way from the beginning but it wasn't what I 
expected in an update from an 'enterprise' version.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From jspaleta at gmail.com  Wed Nov 19 20:46:28 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 19 Nov 2008 11:46:28 -0900
Subject: My roadmap for a better Fedora
In-Reply-To: <1227124866.7387.157.camel@localhost.localdomain>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<604aa7910811191107u4dc41d6eubdc634e14174ede8@mail.gmail.com>
	<1227124866.7387.157.camel@localhost.localdomain>
Message-ID: <604aa7910811191246hfa33f4gf1a5c7aa1029d59a@mail.gmail.com>

2008/11/19 Callum Lerwick <seg at haxxed.com>:
> There are many options here.
>
> 1) Ban everything that breaks rollbacks. Find some other way to do it.

these features were implemented for a reason. You grossly oversimplify
the problem by saying "find some other way to do it."
>
> 2) Just refuse to rollback the packages that break rollback.

How do you know they will break roll back? How do you test rollback in
an organized way?

>
> 3) A combination of both
>
> This is an example of where we need specific examples of scripts and
> such that break rollback to get any farther on this.

Since noone tests for rollback there are no obvious examples of known
rollback breakage. We don't look..we don't test... so we don't know
what currently breaks. You'd have to take each special case...and
attempt to trigger the condition and test for differences.  But since
we are talking about scripted actions which could literally do pretty
much anything...how do you set up a test which attempts to measure
whether rollback across a trigger boundary put you back to where you
were? How much of a different in state counts as 'break rollback'?

rpm -qa --qf "%{NAME}:\n %{TRIGGERSCRIPTS}\n"

If for example the conditions are met which fire off hal's triggered
scripts... if you rolled back hal across that condition
boundary..would things get reverted? That's probably not relevant for
current, expected, update needs. But until we test all triggers for
rollbacks we don't know where we stand.

And then there are obsoletes. How many new obsoletes do we introduce
in updates? Any idea? a run of repoquery against the f9 release and f9
updates tree would be able to tell us that. When an obsolete is
introduced in an update... can we rollback and get what we had?

> First, could you please do something for me. Forget implementation.
> Forget the details. Just answer this simple yes or no question:

>
> Is rollback a desireable feature?

That's a horrible pointless question.  There are many features which
are desirable..but not necessary easily compatible with each other.
Drop dead easy smooth upgrades are not necesssarily going to be
compatible with rollback.  So the right question is.... is rollback
more desirable than other packaging features. What packaging
mechanisms are we willing to give up in order to make rollback at the
individual package level easier to achieve?  I honestly don't think
there is a single mechanism that we are willing to give up.  So if
rollback is going to be a compatible its going to take a much more
clever monkey than myself to figure out the "details" which work.


> I never said I have all the answers. I can't do this alone. "Many eyes
> makes all engineering challenges shallow"

I'm pointing out known complications to the problem.  I suggest you
read up on Carrier Grade Linux which I think attempts to makes
rollback an important specification deliverable..but my knowledge is
somewhat dated.  If there is a group that has thought hard about
rollback...its them. Whether or not what they've come up with is at
all applicable is another question entirely.

-jef



From skvidal at fedoraproject.org  Wed Nov 19 20:52:15 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 19 Nov 2008 15:52:15 -0500 (EST)
Subject: F11: things to check in a release tree before a release
Message-ID: <alpine.LFD.2.00.0811191547010.10340@localhost.localdomain>

Going through a variety of checks for things that could be broken in a 
release tree, I decided to type up a list of the things we should be 
checking for.

? metadata matches
? comps correct
? file conflicts
? normal conflicts
? no obsoleted pkgs in tree
? report all triggers
? look for all postrans/pretrans things
? unresolveable requires
? self-provided filedeps
? self-provided normal deps
? old versions of pkgs left over


Some of them are not explicitly things which are broken in a release, just 
things it would be wise to make sure are sane. Triggers,pretrans and 
posttrans are good examples of that.

Can anyone think of any others that we should report/check for?


-sv

From skvidal at fedoraproject.org  Wed Nov 19 20:53:58 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 19 Nov 2008 15:53:58 -0500 (EST)
Subject: My roadmap for a better Fedora
In-Reply-To: <604aa7910811191246hfa33f4gf1a5c7aa1029d59a@mail.gmail.com>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<604aa7910811191107u4dc41d6eubdc634e14174ede8@mail.gmail.com>
	<1227124866.7387.157.camel@localhost.localdomain>
	<604aa7910811191246hfa33f4gf1a5c7aa1029d59a@mail.gmail.com>
Message-ID: <alpine.LFD.2.00.0811191553330.10340@localhost.localdomain>



On Wed, 19 Nov 2008, Jeff Spaleta wrote:

>
>> I never said I have all the answers. I can't do this alone. "Many eyes
>> makes all engineering challenges shallow"
>
> I'm pointing out known complications to the problem.  I suggest you
> read up on Carrier Grade Linux which I think attempts to makes
> rollback an important specification deliverable..but my knowledge is
> somewhat dated.  If there is a group that has thought hard about
> rollback...its them. Whether or not what they've come up with is at
> all applicable is another question entirely.
>


I'm pretty sure the rollback functionality the CGL wanted was removed from 
rpm recently.

-sv



From lesmikesell at gmail.com  Wed Nov 19 20:54:34 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 19 Nov 2008 14:54:34 -0600
Subject: F11 Proposal: Stabilization
In-Reply-To: <1218b5bc0811191224m138358e5w2529ea9a564eb675@mail.gmail.com>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>	<20081117213742.GB5603@nostromo.devel.redhat.com>	<4921E683.30407@redhat.com>	<604aa7910811171354h26c8eb30r72280cc95ba9a976@mail.gmail.com>	<1226960219.4098.20.camel@perihelion.bos.jonmasters.org>	<49229E4B.8030204@fedoraproject.org>	<bfdeacfa0811180541j338f4c2ah6aaaa0403ba5e2d9@mail.gmail.com>
	<1218b5bc0811191224m138358e5w2529ea9a564eb675@mail.gmail.com>
Message-ID: <49247D0A.1020803@gmail.com>

Callum Lerwick wrote:
> 
> Regressions are inevitable. Why are people afraid of regressions?
> Because it breaks their system. Why are people so afraid of breaking
> their system? Because they're afraid they can't fix it.
> 
> Solution: Make recovery from regressions easy. So easy a trained
> monkey could do it. Make it routine. Make it familiar and
> non-threatening. Make it a normal part of everyone's daily life.

The problem is that the reason you want to recover is that there were 
bugs in what you installed.  The same reason for having bugs in what you 
installed is going to cause you to have bugs in your recovery mechanism. 
  So, while this is a reasonable thing to want, it is not reasonable to 
depend on it to work every time.  Something like a clonezilla image copy 
off to an external disk or network storage might be safe, but not always 
convenient.

> Embrace change. Embrace regressions, instability and bugs. Fedora is
> Extreme Linux. I posted my roadmap for doing this in the "My roadmap
> for a better Fedora" thread.

It's only really extreme when you are the first one running a particular 
package in a particular environment.  If I had a handy way to run 
updates on a test machine a week or two before getting exactly that same 
update on a more critical machine (and bailing completely when problems 
are found) I'd be a lot less concerned about regressions.

-- 
    Les Mikesell
     lesmikesell at gmail.com



From lemenkov at gmail.com  Wed Nov 19 20:57:29 2008
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Wed, 19 Nov 2008 23:57:29 +0300
Subject: My roadmap for a better Fedora
In-Reply-To: <1227119906.7387.138.camel@localhost.localdomain>
References: <1227119906.7387.138.camel@localhost.localdomain>
Message-ID: <adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>

2008/11/19, Callum Lerwick <seg at haxxed.com>:
>  1) Make it easy to report bugs. Bugzilla is complex, slow, and
>  inscrutable.

Agree. I told it thousands times in many different places. Bugzilla is
the ugly monster. Btw recently NASA chosed bugzilla for their space
programs ( http://news.cnet.com/8301-13772_3-10097880-52.html ) - poor
astronauts on Endeavour!

Very few users will decide to report bugs utilizing Bugzilla, even
less of them will do actual bugreports. Even some developers (like me)
sometimes don't know how to describe problem correctly (assign to
proper component, for example).

BTW why we are enforcing users to register on bugzilla, just to be
able to tell us that something wrong with Fedora?

-- 
With best regards!



From notting at redhat.com  Wed Nov 19 20:59:50 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 19 Nov 2008 15:59:50 -0500
Subject: My roadmap for a better Fedora
In-Reply-To: <adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>
Message-ID: <20081119205950.GA4961@nostromo.devel.redhat.com>

Peter Lemenkov (lemenkov at gmail.com) said: 
> BTW why we are enforcing users to register on bugzilla, just to be
> able to tell us that something wrong with Fedora?

Because it's not a one-way communication (at least, not if you want it
to be effective.)

Bill



From berrange at redhat.com  Wed Nov 19 21:12:09 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Wed, 19 Nov 2008 21:12:09 +0000
Subject: F11: things to check in a release tree before a release
In-Reply-To: <alpine.LFD.2.00.0811191547010.10340@localhost.localdomain>
References: <alpine.LFD.2.00.0811191547010.10340@localhost.localdomain>
Message-ID: <20081119211202.GC26527@redhat.com>

On Wed, Nov 19, 2008 at 03:52:15PM -0500, Seth Vidal wrote:
> Going through a variety of checks for things that could be broken in a 
> release tree, I decided to type up a list of the things we should be 
> checking for.
> 
> ??? metadata matches
> ??? comps correct
> ??? file conflicts
> ??? normal conflicts
> ??? no obsoleted pkgs in tree
> ??? report all triggers
> ??? look for all postrans/pretrans things
> ??? unresolveable requires
> ??? self-provided filedeps
> ??? self-provided normal deps
> ??? old versions of pkgs left over
> 
> 
> Some of them are not explicitly things which are broken in a release, just 
> things it would be wise to make sure are sane. Triggers,pretrans and 
> posttrans are good examples of that.
> 
> Can anyone think of any others that we should report/check for?

All files in the .treeinfo file actually exist, and that the .treeinfo
has entries for baremetal & xen kernels (xen may or may not point to
the same kernels as baremetal). We now rely on .treeinfo files for
virtualization provisioning needs, so brokenness is a show-stopper.

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 jkeating at redhat.com  Wed Nov 19 21:20:11 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 19 Nov 2008 13:20:11 -0800
Subject: F11: things to check in a release tree before a release
In-Reply-To: <alpine.LFD.2.00.0811191547010.10340@localhost.localdomain>
References: <alpine.LFD.2.00.0811191547010.10340@localhost.localdomain>
Message-ID: <1227129611.28543.307.camel@luminos.localdomain>

On Wed, 2008-11-19 at 15:52 -0500, Seth Vidal wrote:
> Can anyone think of any others that we should report/check for?

Not sure if early things catch it, but packages that obsolete themselves
(usually due to unversioned provides)

-- 
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/20081119/9c607028/attachment.sig>

From skvidal at fedoraproject.org  Wed Nov 19 21:21:58 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 19 Nov 2008 16:21:58 -0500 (EST)
Subject: F11: things to check in a release tree before a release
In-Reply-To: <20081119211202.GC26527@redhat.com>
References: <alpine.LFD.2.00.0811191547010.10340@localhost.localdomain>
	<20081119211202.GC26527@redhat.com>
Message-ID: <alpine.LFD.2.00.0811191621370.10340@localhost.localdomain>



On Wed, 19 Nov 2008, Daniel P. Berrange wrote:

> On Wed, Nov 19, 2008 at 03:52:15PM -0500, Seth Vidal wrote:
>> Going through a variety of checks for things that could be broken in a
>> release tree, I decided to type up a list of the things we should be
>> checking for.
>>
>> ??? metadata matches
>> ??? comps correct
>> ??? file conflicts
>> ??? normal conflicts
>> ??? no obsoleted pkgs in tree
>> ??? report all triggers
>> ??? look for all postrans/pretrans things
>> ??? unresolveable requires
>> ??? self-provided filedeps
>> ??? self-provided normal deps
>> ??? old versions of pkgs left over
>>
>>
>> Some of them are not explicitly things which are broken in a release, just
>> things it would be wise to make sure are sane. Triggers,pretrans and
>> posttrans are good examples of that.
>>
>> Can anyone think of any others that we should report/check for?
>
> All files in the .treeinfo file actually exist, and that the .treeinfo
> has entries for baremetal & xen kernels (xen may or may not point to
> the same kernels as baremetal). We now rely on .treeinfo files for
> virtualization provisioning needs, so brokenness is a show-stopper.


verifytree already does that. but yes, correct.

-sv



From mschwendt at gmail.com  Wed Nov 19 21:22:35 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 19 Nov 2008 22:22:35 +0100
Subject: F11: things to check in a release tree before a release
In-Reply-To: <alpine.LFD.2.00.0811191547010.10340@localhost.localdomain>
References: <alpine.LFD.2.00.0811191547010.10340@localhost.localdomain>
Message-ID: <20081119222235.699e4437.mschwendt@gmail.com>

On Wed, 19 Nov 2008 15:52:15 -0500 (EST), Seth Vidal wrote:

> Going through a variety of checks for things that could be broken in a 
> release tree, I decided to type up a list of the things we should be 
> checking for.
> 
> ? metadata matches
> ? comps correct
> ? file conflicts

Conflicts between a file and a symlink. Can only be checked with access
to the .rpm package and is not listed in the metadata (afaik).

Optionally: permission/ownership conflicts

> ? normal conflicts
> ? no obsoleted pkgs in tree
> ? report all triggers
> ? look for all postrans/pretrans things
> ? unresolveable requires
> ? self-provided filedeps
> ? self-provided normal deps
> ? old versions of pkgs left over
 
? SONAME-provides conflicts



From skvidal at fedoraproject.org  Wed Nov 19 21:24:01 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 19 Nov 2008 16:24:01 -0500 (EST)
Subject: F11: things to check in a release tree before a release
In-Reply-To: <1227129611.28543.307.camel@luminos.localdomain>
References: <alpine.LFD.2.00.0811191547010.10340@localhost.localdomain>
	<1227129611.28543.307.camel@luminos.localdomain>
Message-ID: <alpine.LFD.2.00.0811191623570.10340@localhost.localdomain>



On Wed, 19 Nov 2008, Jesse Keating wrote:

> On Wed, 2008-11-19 at 15:52 -0500, Seth Vidal wrote:
>> Can anyone think of any others that we should report/check for?
>
> Not sure if early things catch it, but packages that obsolete themselves
> (usually due to unversioned provides)
>

added.
-sv



From skvidal at fedoraproject.org  Wed Nov 19 21:29:37 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 19 Nov 2008 16:29:37 -0500 (EST)
Subject: F11: things to check in a release tree before a release
In-Reply-To: <20081119222235.699e4437.mschwendt@gmail.com>
References: <alpine.LFD.2.00.0811191547010.10340@localhost.localdomain>
	<20081119222235.699e4437.mschwendt@gmail.com>
Message-ID: <alpine.LFD.2.00.0811191628050.10340@localhost.localdomain>



On Wed, 19 Nov 2008, Michael Schwendt wrote:

> On Wed, 19 Nov 2008 15:52:15 -0500 (EST), Seth Vidal wrote:
>
>> Going through a variety of checks for things that could be broken in a
>> release tree, I decided to type up a list of the things we should be
>> checking for.
>>
>> ? metadata matches
>> ? comps correct
>> ? file conflicts
>
> Conflicts between a file and a symlink. Can only be checked with access
> to the .rpm package and is not listed in the metadata (afaik).

Right, Which is what I'm doing here:
http://skvidal.fedorapeople.org/misc/potential_conflict.py

check for filename clashes, then pull the headers from the packages 
involved and check the checksum against each.

>
> Optionally: permission/ownership conflicts

>
>
> ? SONAME-provides conflicts

explain more about what we check for here?
Is this like multiple things providing libfoo.so() and one of them being a 
bogon autodep?

-sv

From mschwendt at gmail.com  Wed Nov 19 21:22:35 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 19 Nov 2008 22:22:35 +0100
Subject: F11: things to check in a release tree before a release
In-Reply-To: <alpine.LFD.2.00.0811191547010.10340@localhost.localdomain>
References: <alpine.LFD.2.00.0811191547010.10340@localhost.localdomain>
Message-ID: <20081119222235.699e4437.mschwendt@gmail.com>

On Wed, 19 Nov 2008 15:52:15 -0500 (EST), Seth Vidal wrote:

> Going through a variety of checks for things that could be broken in a 
> release tree, I decided to type up a list of the things we should be 
> checking for.
> 
> ? metadata matches
> ? comps correct
> ? file conflicts

Conflicts between a file and a symlink. Can only be checked with access
to the .rpm package and is not listed in the metadata (afaik).

Optionally: permission/ownership conflicts

> ? normal conflicts
> ? no obsoleted pkgs in tree
> ? report all triggers
> ? look for all postrans/pretrans things
> ? unresolveable requires
> ? self-provided filedeps
> ? self-provided normal deps
> ? old versions of pkgs left over
 
? SONAME-provides conflicts



From mschwendt at gmail.com  Wed Nov 19 21:38:10 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 19 Nov 2008 22:38:10 +0100
Subject: F11: things to check in a release tree before a release
In-Reply-To: <alpine.LFD.2.00.0811191628050.10340@localhost.localdomain>
References: <alpine.LFD.2.00.0811191547010.10340@localhost.localdomain>
	<20081119222235.699e4437.mschwendt@gmail.com>
	<alpine.LFD.2.00.0811191628050.10340@localhost.localdomain>
Message-ID: <20081119223810.a43dfa41.mschwendt@gmail.com>

On Wed, 19 Nov 2008 16:29:37 -0500 (EST), Seth Vidal wrote:

> > ? SONAME-provides conflicts
> 
> explain more about what we check for here?
> Is this like multiple things providing libfoo.so() and one of them being a 
> bogon autodep?

Exactly. :)



From skvidal at fedoraproject.org  Wed Nov 19 21:39:15 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 19 Nov 2008 16:39:15 -0500 (EST)
Subject: F11: things to check in a release tree before a release
In-Reply-To: <20081119223810.a43dfa41.mschwendt@gmail.com>
References: <alpine.LFD.2.00.0811191547010.10340@localhost.localdomain>
	<20081119222235.699e4437.mschwendt@gmail.com>
	<alpine.LFD.2.00.0811191628050.10340@localhost.localdomain>
	<20081119223810.a43dfa41.mschwendt@gmail.com>
Message-ID: <alpine.LFD.2.00.0811191639060.10340@localhost.localdomain>



On Wed, 19 Nov 2008, Michael Schwendt wrote:

> On Wed, 19 Nov 2008 16:29:37 -0500 (EST), Seth Vidal wrote:
>
>>> ? SONAME-provides conflicts
>>
>> explain more about what we check for here?
>> Is this like multiple things providing libfoo.so() and one of them being a
>> bogon autodep?
>
> Exactly. :)

added.

thanks
-sv

From lemenkov at gmail.com  Wed Nov 19 21:23:42 2008
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Thu, 20 Nov 2008 00:23:42 +0300
Subject: My roadmap for a better Fedora
In-Reply-To: <20081119205950.GA4961@nostromo.devel.redhat.com>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>
	<20081119205950.GA4961@nostromo.devel.redhat.com>
Message-ID: <adf480660811191323i552f933dy156a8416e22561ad@mail.gmail.com>

2008/11/19, Bill Nottingham <notting at redhat.com>:
> Because it's not a one-way communication (at least, not if you want it
>  to be effective.)

I think you misundestood something. If order to effectively hunt
issues, we definitely need HUGE number of bugreports (remember
Necrosoft's "Send crash dump" utility). That definitely means one-way
communication. I'm insisting - one-way communication (e.g. user will
send bugreport to invisible-to-him blackhole, w/o answer, with some
handy tool).

Bugzilla is (probably) suitable for large ineffective  developer's
teams with large amounts of old, dying, poorly maintained code.

Bugzilla is in no way suitable to help hear crying of users (because,
as I said before, it's too complex). That means we have no tools and
communication channels, to track down enduser's problems, at all. Some
of us sometimes will fill bugreports (in some extraordinary cases),
but  it's not enough.

Mediawiki will be easier to enduser in case of reporting bugs. However
some easiest utility (with appropriate server side, of course) would
be more appropriate.

-- 
With best regards!



From gilboad at gmail.com  Wed Nov 19 21:42:22 2008
From: gilboad at gmail.com (Gilboa Davara)
Date: Wed, 19 Nov 2008 23:42:22 +0200
Subject: My roadmap for a better Fedora
In-Reply-To: <1227119906.7387.138.camel@localhost.localdomain>
References: <1227119906.7387.138.camel@localhost.localdomain>
Message-ID: <1227130942.2889.15.camel@gilboa-home-dev.localdomain>

On Wed, 2008-11-19 at 12:38 -0600, Callum Lerwick wrote:
> So, many pieces of this have been blabbed about by me and others
> recently and in the past, but I think a lot of people aren't seeing the
> big picture. I think it's time I fit it all together.
> 
> Problem: Fedora is buggy, and updates are rife with regressions.
> 
> Solution: We need more and wider testing.
> 
> Problem: We need more and wider testing. Why don't we get more testing?
> Thw reason *I* don't go out of my way to test updates, is if there's a
> regression, it's such a pain in the ass to get the system back to a
> known good state and keep it that way, and report a bug. If it's a pain
> in the ass for me, it's impossible for Aunt Tillie.
> 
> Solution:
> 
> 1) Make it easy to report bugs. Bugzilla is complex, slow, and
> inscrutable. We need to put a simpler layer on top of it. Reporting a
> bug should require just a few clicks. It should automatically include
> all the information needed for the bug report, the distro version,
> package version, arch, and things such as how the Xorg team demands your
> xorg.conf and Xorg.0.log. Make finding dupes easier. Collect stack
> traces system wide and enter them in a database, which bugzilla can
> reference and from which bugzilla bugs can be derived. A system wide
> kerneloops. (I know this has been talked about, what's the status?)

Agreed.
Though you're missing thing - automated bug report system generate
-huge- amount of noise. Lowering the signal-to-noise ratio to something
usable is -very- labor intensive.
Far worse, people (who send such report) tend to forget about them (as
opposed to manual bug reports) making them far less effective.

So, question is:
A. Who will do the heavy lifting of developing such system?
B. Who will triage 1000's of orphaned bug reports.


> 
> 2) Make it simple to roll back to a known good state. We need a "system
> restore". I know what you're thinking, but our vastly superior,
> centralized, system-wide package management (and lack of a whole
> seperate "system registry" namespace) allows us to make this actually
> work. We need per-package rollback. Period.

Assuming, of course, that you can pin-point what exactly broken
evolution within the 150 package update push.
Will you roll back all the updates? Only updates that had -something- to
do with the breakage? (Let alone kernel updates that can more-or-less
break everything in sight...)
Oh, and what do you do when at least 50% of these updates are
high-priority security updates?

> 
> 3) Make it so yum will refuse to upgrade the package rolled back in step
> 2 until the bug reported in step 1 is fixed.

Say-what?!?
Are we building a second Vista here?

> 
> 4) For when things go really wrong, we need a rescue image in /boot. All
> the above functionality must be available inside the rescue environment.

/+100.
Though this idea has come up a number of times before. AFAIR it was
dropped due to space considerations and possible kernel-version
problems. (In theory, you may need a different rescue image for each
installed kernel - unless you plan to keep the original kernel)

> 
> 5) So how do bugs get fixed? Make it easy to cherry pick updates from
> updates-testing or even direct from bodhi. How useful is it to blindly
> follow every update in updates testing? For most users, it's useless.
> Such adventurous people should probably just run rawhide... What we
> really need is to make it easy to pick a specific release of an update
> to try, such as if a user is directed to in a bug report. A user should
> just be able to click on a link given in the bug report and have the
> update installed. Available updates and the reasons for them needs to be
> more discoverable. Don't forget step #2.

Not sure what that means.
You can always enable updates-testing and selectively install what you
need.

> 
> See how these things build upon and support each other?
> 
> Notice here I'm talking purely about user interface, about the end user
> experience. The technical infrastructure follows from this, and I'll
> save that discussion for another message. Infrastructure supports
> functionality, not the other way around. I don't want to hear any "Oh
> but we can't do this because blah blah technical objection blah makes
> this hard". I hereby dub this the "Hard problem fallacy". Engineers
> solve hard problems, that's what we do. I want to hear "To do this we
> need to do x y z". The only objections I will accept are of the form
> "You are an idiot and your ideas are stupid. We're not doing this."

Yes, but in the is case, the UI has a profound influence on the why
Fedora works.

On a side note, I'm not sure what you're trying to achieve by this last
paragraph. But if you intention was to start yet-another-flame-war, I
have a bad feeling you're on the right track.

- Gilboa


> 
> I should probably put this on the Wiki so it doesn't get lost...
> -- 




From james at fedoraproject.org  Wed Nov 19 21:45:03 2008
From: james at fedoraproject.org (James Antill)
Date: Wed, 19 Nov 2008 16:45:03 -0500
Subject: F11 Proposal: Stabilization
In-Reply-To: <49247880.6030509@redhat.com>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<49234CE6.7050805@gmail.com>
	<604aa7910811181554q238d59ber63bf99565a37558e@mail.gmail.com>
	<492359B2.2010008@gmail.com>
	<604aa7910811181622q6d2b7f92kf20853a6c9f8c2f1@mail.gmail.com>
	<492378C7.6050408@gmail.com>
	<1227064591.28543.34.camel@luminos.localdomain>
	<4923C840.30101@shmuelhome.mine.nu>
	<1227107699.28543.52.camel@luminos.localdomain>
	<49243613.1050901@gmail.com> <1227112465.4355.146.camel@code.and.org>
	<49247880.6030509@redhat.com>
Message-ID: <1227131103.4355.184.camel@code.and.org>

On Wed, 2008-11-19 at 15:35 -0500, Casey Dahlin wrote:
> James Antill wrote:
> >
> > 1. Too many people want to be consumers of the testing but not the
> > providers of it.
> >  Indeed IMO the whole updates-tested argument seems to devolve to "I'm
> > going to be clever and switch to this, but I'm pretty sure a bunch of
> > other people aren't going to know immediately and so will become my
> > unwilling testers".
> >   
> One of Fedora's goals is to turn users into contributors. What better 
> way to do that than to make every default-retaining user an unwitting 
> brick in a colossal meat wall?

 If you want to ask Jesse to enable updates-testing by default, feel
free to do so. It's certainly better in many ways than creating an
updates-tested repo.

 However I think there is a big difference between wanting people to
opt-in to contributions and doing it for them.

-- 
James Antill <james at fedoraproject.org>
Fedora



From fedora at matbooth.co.uk  Wed Nov 19 21:44:34 2008
From: fedora at matbooth.co.uk (Mat Booth)
Date: Wed, 19 Nov 2008 21:44:34 +0000
Subject: My roadmap for a better Fedora
In-Reply-To: <adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>
Message-ID: <9497e9990811191344s694d3a57w801e31a83908041a@mail.gmail.com>

On Wed, Nov 19, 2008 at 8:57 PM, Peter Lemenkov <lemenkov at gmail.com> wrote:
> 2008/11/19, Callum Lerwick <seg at haxxed.com>:
>>  1) Make it easy to report bugs. Bugzilla is complex, slow, and
>>  inscrutable.
>
> Agree. I told it thousands times in many different places. Bugzilla is
> the ugly monster. Btw recently NASA chosed bugzilla for their space
> programs ( http://news.cnet.com/8301-13772_3-10097880-52.html ) - poor
> astronauts on Endeavour!
>

You're not wrong, that search page is just plain scary!

https://bugzilla.redhat.com/query.cgi


-- 
Mat Booth
www.matbooth.co.uk



From gilboad at gmail.com  Wed Nov 19 21:47:52 2008
From: gilboad at gmail.com (Gilboa Davara)
Date: Wed, 19 Nov 2008 23:47:52 +0200
Subject: My roadmap for a better Fedora
In-Reply-To: <1227130942.2889.15.camel@gilboa-home-dev.localdomain>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<1227130942.2889.15.camel@gilboa-home-dev.localdomain>
Message-ID: <1227131272.2889.21.camel@gilboa-home-dev.localdomain>

On Wed, 2008-11-19 at 23:42 +0200, Gilboa Davara wrote:

> Assuming, of course, that you can pin-point what exactly broken
> evolution within the 150 package update push.

/broken fedora/broke fedora/

> Yes, but in the is case, the UI has a profound influence on the why
> Fedora works.

/on the why/on the way/.


Sorry for the bad English day. I'm suffering from a mild case of common
flu. :(

- Gilboa



From alan at redhat.com  Wed Nov 19 21:49:44 2008
From: alan at redhat.com (Alan Cox)
Date: Wed, 19 Nov 2008 16:49:44 -0500
Subject: My roadmap for a better Fedora
In-Reply-To: <adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>
Message-ID: <20081119214944.GA13706@shell.devel.redhat.com>

On Wed, Nov 19, 2008 at 11:57:29PM +0300, Peter Lemenkov wrote:
> BTW why we are enforcing users to register on bugzilla, just to be
> able to tell us that something wrong with Fedora?

Because otherwise it would have a billion spambots all over it.

Also someone who can't be bothered to register won't be contactable for
feedback, questions and to try things so their report is probably useless.



From skvidal at fedoraproject.org  Wed Nov 19 21:49:41 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 19 Nov 2008 16:49:41 -0500 (EST)
Subject: My roadmap for a better Fedora
In-Reply-To: <9497e9990811191344s694d3a57w801e31a83908041a@mail.gmail.com>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>
	<9497e9990811191344s694d3a57w801e31a83908041a@mail.gmail.com>
Message-ID: <alpine.LFD.2.00.0811191648340.10340@localhost.localdomain>



On Wed, 19 Nov 2008, Mat Booth wrote:

> On Wed, Nov 19, 2008 at 8:57 PM, Peter Lemenkov <lemenkov at gmail.com> wrote:
>> 2008/11/19, Callum Lerwick <seg at haxxed.com>:
>>>  1) Make it easy to report bugs. Bugzilla is complex, slow, and
>>>  inscrutable.
>>
>> Agree. I told it thousands times in many different places. Bugzilla is
>> the ugly monster. Btw recently NASA chosed bugzilla for their space
>> programs ( http://news.cnet.com/8301-13772_3-10097880-52.html ) - poor
>> astronauts on Endeavour!
>>
>
> You're not wrong, that search page is just plain scary!
>
> https://bugzilla.redhat.com/query.cgi

If you know the package where you think the bug is you can use bugz:)

http://bugz.fedoraproject.org/$name

for example
http://bugz.fedoraproject.org/yum/


not a solution but it's a start.
-sv



From alan at redhat.com  Wed Nov 19 21:51:34 2008
From: alan at redhat.com (Alan Cox)
Date: Wed, 19 Nov 2008 16:51:34 -0500
Subject: My roadmap for a better Fedora
In-Reply-To: <adf480660811191323i552f933dy156a8416e22561ad@mail.gmail.com>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>
	<20081119205950.GA4961@nostromo.devel.redhat.com>
	<adf480660811191323i552f933dy156a8416e22561ad@mail.gmail.com>
Message-ID: <20081119215134.GB13706@shell.devel.redhat.com>

On Thu, Nov 20, 2008 at 12:23:42AM +0300, Peter Lemenkov wrote:
> I think you misundestood something. If order to effectively hunt
> issues, we definitely need HUGE number of bugreports (remember

No. You need one clear and accurate bug report that happens to contain
the right information and the user willing to help.

For large numbers of mostly content free reports the best you can do is
throw them at a statistical analysis tool and spot patterns to see what looks
most important to work on.

We do that - see kerneloops.org



From cdahlin at redhat.com  Wed Nov 19 21:54:59 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 19 Nov 2008 16:54:59 -0500
Subject: My roadmap for a better Fedora
In-Reply-To: <9497e9990811191344s694d3a57w801e31a83908041a@mail.gmail.com>
References: <1227119906.7387.138.camel@localhost.localdomain>	<adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>
	<9497e9990811191344s694d3a57w801e31a83908041a@mail.gmail.com>
Message-ID: <49248B33.904@redhat.com>

Mat Booth wrote:
> On Wed, Nov 19, 2008 at 8:57 PM, Peter Lemenkov <lemenkov at gmail.com> wrote:
>   
>> 2008/11/19, Callum Lerwick <seg at haxxed.com>:
>>     
>>>  1) Make it easy to report bugs. Bugzilla is complex, slow, and
>>>  inscrutable.
>>>       
>> Agree. I told it thousands times in many different places. Bugzilla is
>> the ugly monster. Btw recently NASA chosed bugzilla for their space
>> programs ( http://news.cnet.com/8301-13772_3-10097880-52.html ) - poor
>> astronauts on Endeavour!
>>
>>     
>
> You're not wrong, that search page is just plain scary!
>
> https://bugzilla.redhat.com/query.cgi
>
>
>   
I think rh-bugzilla's advanced search page is some kind of acid3-esque 
test for javascript engines.

--CJD



From james at fedoraproject.org  Wed Nov 19 21:55:40 2008
From: james at fedoraproject.org (James Antill)
Date: Wed, 19 Nov 2008 16:55:40 -0500
Subject: F11 Proposal: Stabilization
In-Reply-To: <4924766B.80703@gmail.com>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<49234CE6.7050805@gmail.com>
	<604aa7910811181554q238d59ber63bf99565a37558e@mail.gmail.com>
	<492359B2.2010008@gmail.com>
	<604aa7910811181622q6d2b7f92kf20853a6c9f8c2f1@mail.gmail.com>
	<492378C7.6050408@gmail.com>
	<1227064591.28543.34.camel@luminos.localdomain>
	<4923C840.30101@shmuelhome.mine.nu>
	<1227107699.28543.52.camel@luminos.localdomain>
	<49243613.1050901@gmail.com> <1227112465.4355.146.camel@code.and.org>
	<4924766B.80703@gmail.com>
Message-ID: <1227131740.4355.193.camel@code.and.org>

On Wed, 2008-11-19 at 14:26 -0600, Les Mikesell wrote:
> James Antill wrote:
> > 
> >> That may or may not be true and it may or may not matter.  All you need 
> >> is some large representative sample doing the early testing and a way to 
> >> ensure feedback to improve everyone's experience.  And letting users 
> >> control their exposure to new bugs might increase the user base in both 
> >> categories.
> > 
> >  This is what updates-testing _already does_. As Jesse has already said,
> > there are two big problems:
> > 
> > 1. Too many people want to be consumers of the testing but not the
> > providers of it.
> 
> I think that's an unwarranted assumption.  How many people even know 
> about updates-testing compared to people that never change defaults? 

 Certainly everyone in this thread knows about it.

> How does someone using updates-testing ensure that their usage 
> 'provides' something?

 bodhi -k +1 -c 'pkg FOO, works for me'

...or even just leave the comment.

> >  Indeed IMO the whole updates-tested argument seems to devolve to "I'm
> > going to be clever and switch to this, but I'm pretty sure a bunch of
> > other people aren't going to know immediately and so will become my
> > unwilling testers".
> 
> No, the argument is this:
> If I had a way to be moderately sure that my main work machine would be 
> usable every day running fedora and I could test things on a less 
> important machine, I'd be much more likely to run fedora more of the 
> time and on more machines.

 So subscribe your work machine to just updates, and your test machine
to updates-testing ... what is the problem here?

> > 2. The people who are the providers of the testing, aren't necessarily
> > running the same kinds of workloads as the people who want to just be
> > consumers of the testing.
> 
> Exactly - it doesn't work that well as is.  And even if I wanted to test 
> exactly the same work on exactly the same kind of machine, I don't think 
> I could predictably 'consume' that testing value - that is, there is no 
> way for me to know when or if a 'yum update' on my production machine is 
> going to reproduce exactly the software installed on my test machine. 
> (Personally I think this is a generic yum problem and it should provide 
> an option for reproducible installs regardless of what is going on in 
> the repositories, but that's a slightly different issue...).

 Sure, it's one of the many things on the TODO list to fix ... and with
yum-debug-dump / yum shell / etc. there are a couple of ways of hacking
this kind of thing in.
 However if you were running updates-testing refreshes fairly often then
anything going into updates would be fine for you, by definition.

-- 
James Antill <james at fedoraproject.org>
Fedora



From cmadams at hiwaay.net  Wed Nov 19 22:03:28 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 19 Nov 2008 16:03:28 -0600
Subject: F11: things to check in a release tree before a release
In-Reply-To: <20081119223810.a43dfa41.mschwendt@gmail.com>
References: <alpine.LFD.2.00.0811191547010.10340@localhost.localdomain>
	<20081119222235.699e4437.mschwendt@gmail.com>
	<alpine.LFD.2.00.0811191628050.10340@localhost.localdomain>
	<20081119223810.a43dfa41.mschwendt@gmail.com>
Message-ID: <20081119220328.GA1371485@hiwaay.net>

Once upon a time, Michael Schwendt <mschwendt at gmail.com> said:
> On Wed, 19 Nov 2008 16:29:37 -0500 (EST), Seth Vidal wrote:
> > > ??? SONAME-provides conflicts
> > 
> > explain more about what we check for here?
> > Is this like multiple things providing libfoo.so() and one of them being a 
> > bogon autodep?
> 
> Exactly. :)

I'd suggest expanding that to check perl (and other language) module
provides as well.

For example, for a while MRTG included a private copy of the RRD perl
modules, and "mrtg" was shorter than "rrdtool-perl", so anything using
the RRD modules would auto-dep pull in MRTG (which didn't solve the
dep).

-- 
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 skvidal at fedoraproject.org  Wed Nov 19 22:06:47 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 19 Nov 2008 17:06:47 -0500 (EST)
Subject: F11: things to check in a release tree before a release
In-Reply-To: <20081119220328.GA1371485@hiwaay.net>
References: <alpine.LFD.2.00.0811191547010.10340@localhost.localdomain>
	<20081119222235.699e4437.mschwendt@gmail.com>
	<alpine.LFD.2.00.0811191628050.10340@localhost.localdomain>
	<20081119223810.a43dfa41.mschwendt@gmail.com>
	<20081119220328.GA1371485@hiwaay.net>
Message-ID: <alpine.LFD.2.00.0811191706180.10340@localhost.localdomain>



On Wed, 19 Nov 2008, Chris Adams wrote:

> Once upon a time, Michael Schwendt <mschwendt at gmail.com> said:
>> On Wed, 19 Nov 2008 16:29:37 -0500 (EST), Seth Vidal wrote:
>>>> ??? SONAME-provides conflicts
>>>
>>> explain more about what we check for here?
>>> Is this like multiple things providing libfoo.so() and one of them being a
>>> bogon autodep?
>>
>> Exactly. :)
>
> I'd suggest expanding that to check perl (and other language) module
> provides as well.
>
> For example, for a while MRTG included a private copy of the RRD perl
> modules, and "mrtg" was shorter than "rrdtool-perl", so anything using
> the RRD modules would auto-dep pull in MRTG (which didn't solve the
> dep).

so in general we need to produce lists of all multiple providers of any 
single provide. Then they can be verified manually?

-sv

From clumens at redhat.com  Wed Nov 19 22:13:15 2008
From: clumens at redhat.com (Chris Lumens)
Date: Wed, 19 Nov 2008 17:13:15 -0500
Subject: My roadmap for a better Fedora
In-Reply-To: <adf480660811191323i552f933dy156a8416e22561ad@mail.gmail.com>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>
	<20081119205950.GA4961@nostromo.devel.redhat.com>
	<adf480660811191323i552f933dy156a8416e22561ad@mail.gmail.com>
Message-ID: <20081119221311.GD31216@localhost.localdomain>

> I think you misundestood something. If order to effectively hunt
> issues, we definitely need HUGE number of bugreports (remember
> Necrosoft's "Send crash dump" utility). That definitely means one-way
> communication. I'm insisting - one-way communication (e.g. user will
> send bugreport to invisible-to-him blackhole, w/o answer, with some
> handy tool).

As someone who actually has to fix bugs, this is completely useless to
me.  I want a bug with good information on how to reproduce it, good
logs or tracebacks, and a reporter who's going to be able to answer my
questions about what they were doing.

A drive-by bug assault is going to do nothing but bury me in useless bug
reports that someone will have to spend time picking through and duping
to one that might actually be useful.  Such bug reports are better off
never existing.

- Chris



From clumens at redhat.com  Wed Nov 19 22:15:45 2008
From: clumens at redhat.com (Chris Lumens)
Date: Wed, 19 Nov 2008 17:15:45 -0500
Subject: My roadmap for a better Fedora
In-Reply-To: <1227119906.7387.138.camel@localhost.localdomain>
References: <1227119906.7387.138.camel@localhost.localdomain>
Message-ID: <20081119221544.GE31216@localhost.localdomain>

I'd like to add a step (0) before we make bugs easier to file and really
crank up the number of reports we're getting:

(0) More people FIXING the bug, not just reporting them.  You can have a
giant user base of people filing tons of bugs, and you can have a
motivated and effective QA/Triaging team whittling them down to the
really important and reproducable bugs.  But without more people fixing
them, the backlog is just going to continue to build.

- Chris



From berrange at redhat.com  Wed Nov 19 22:17:21 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Wed, 19 Nov 2008 22:17:21 +0000
Subject: My roadmap for a better Fedora
In-Reply-To: <adf480660811191323i552f933dy156a8416e22561ad@mail.gmail.com>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>
	<20081119205950.GA4961@nostromo.devel.redhat.com>
	<adf480660811191323i552f933dy156a8416e22561ad@mail.gmail.com>
Message-ID: <20081119221721.GH26527@redhat.com>

On Thu, Nov 20, 2008 at 12:23:42AM +0300, Peter Lemenkov wrote:
> 2008/11/19, Bill Nottingham <notting at redhat.com>:
> > Because it's not a one-way communication (at least, not if you want it
> >  to be effective.)
> 
> I think you misundestood something. If order to effectively hunt
> issues, we definitely need HUGE number of bugreports (remember
> Necrosoft's "Send crash dump" utility). That definitely means one-way
> communication. I'm insisting - one-way communication (e.g. user will
> send bugreport to invisible-to-him blackhole, w/o answer, with some
> handy tool).

Utterly useless. I already have a HUGE number of bug reports. The problem
is that 90% of them are essentially useless when first reported. It requires
several back/forth interactions between myself & the bug reporter to get 
enough information to diagnose & resolve the problem. If we create a system
where we bombard maintainers with bugreports & no scope for user interaction
they'll end up directly in /dev/null, and further discourage maintainers
from addressing even bugs with enough info.

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 pertusus at free.fr  Wed Nov 19 22:19:28 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 19 Nov 2008 23:19:28 +0100
Subject: F11: things to check in a release tree before a release
In-Reply-To: <alpine.LFD.2.00.0811191706180.10340@localhost.localdomain>
References: <alpine.LFD.2.00.0811191547010.10340@localhost.localdomain>
	<20081119222235.699e4437.mschwendt@gmail.com>
	<alpine.LFD.2.00.0811191628050.10340@localhost.localdomain>
	<20081119223810.a43dfa41.mschwendt@gmail.com>
	<20081119220328.GA1371485@hiwaay.net>
	<alpine.LFD.2.00.0811191706180.10340@localhost.localdomain>
Message-ID: <20081119221928.GB2890@free.fr>

On Wed, Nov 19, 2008 at 05:06:47PM -0500, Seth Vidal wrote:
>
> so in general we need to produce lists of all multiple providers of any  
> single provide. Then they can be verified manually?

That would be nice, indeed, and also could help to make some sanity
checking and documentation of virtual provides.

--
Pat



From lesmikesell at gmail.com  Wed Nov 19 22:24:09 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 19 Nov 2008 16:24:09 -0600
Subject: F11 Proposal: Stabilization
In-Reply-To: <1227131740.4355.193.camel@code.and.org>
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>	<1226958439.3814.6.camel@localhost.localdomain>	<49232E89.6020400@redhat.com>	<1227043890.28543.18.camel@luminos.localdomain>	<49233BE6.3080808@redhat.com>	<1227046097.28543.21.camel@luminos.localdomain>	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>	<49234CE6.7050805@gmail.com>	<604aa7910811181554q238d59ber63bf99565a37558e@mail.gmail.com>	<492359B2.2010008@gmail.com>	<604aa7910811181622q6d2b7f92kf20853a6c9f8c2f1@mail.gmail.com>	<492378C7.6050408@gmail.com>	<1227064591.28543.34.camel@luminos.localdomain>	<4923C840.30101@shmuelhome.mine.nu>	<1227107699.28543.52.camel@luminos.localdomain>	<49243613.1050901@gmail.com>
	<1227112465.4355.146.camel@code.and.org>	<4924766B.80703@gmail.com>
	<1227131740.4355.193.camel@code.and.org>
Message-ID: <49249209.2020407@gmail.com>

James Antill wrote:
> 
>>> 1. Too many people want to be consumers of the testing but not the
>>> providers of it.
>> I think that's an unwarranted assumption.  How many people even know 
>> about updates-testing compared to people that never change defaults? 
> 
>  Certainly everyone in this thread knows about it.

So maybe a dozen people...

>> How does someone using updates-testing ensure that their usage 
>> 'provides' something?
> 
>  bodhi -k +1 -c 'pkg FOO, works for me'
> 
> ...or even just leave the comment.

That's (a) not something many people are likely to do, and (b) not quite 
what I want to know.  I want to know that the combination of packages 
installed on machine X at time Y worked together correctly (including 
the kernel and base libs that may affect but not be specifically tied to 
the package in question) before I install that same set on machine Z at 
time Y + something.

>>>  Indeed IMO the whole updates-tested argument seems to devolve to "I'm
>>> going to be clever and switch to this, but I'm pretty sure a bunch of
>>> other people aren't going to know immediately and so will become my
>>> unwilling testers".
>> No, the argument is this:
>> If I had a way to be moderately sure that my main work machine would be 
>> usable every day running fedora and I could test things on a less 
>> important machine, I'd be much more likely to run fedora more of the 
>> time and on more machines.
> 
>  So subscribe your work machine to just updates, and your test machine
> to updates-testing ... what is the problem here?

Is the flow exactly predictable?  That is, can I know that the package 
set I get from updates will correspond exactly to what I tested earlier? 
What is the process for problems detected in testing?

>>> 2. The people who are the providers of the testing, aren't necessarily
>>> running the same kinds of workloads as the people who want to just be
>>> consumers of the testing.
>> Exactly - it doesn't work that well as is.  And even if I wanted to test 
>> exactly the same work on exactly the same kind of machine, I don't think 
>> I could predictably 'consume' that testing value - that is, there is no 
>> way for me to know when or if a 'yum update' on my production machine is 
>> going to reproduce exactly the software installed on my test machine. 
>> (Personally I think this is a generic yum problem and it should provide 
>> an option for reproducible installs regardless of what is going on in 
>> the repositories, but that's a slightly different issue...).
> 
>  Sure, it's one of the many things on the TODO list to fix ... and with
> yum-debug-dump / yum shell / etc. there are a couple of ways of hacking
> this kind of thing in.
>  However if you were running updates-testing refreshes fairly often then
> anything going into updates would be fine for you, by definition.

Are sets of updates moved atomically from one repo to the next, holding 
back the whole set for a problem in one package, or will I really get an 
unpredictable grouping out of updates?

-- 
   Les Mikesell
    lesmikesell at gmail.com




From jspaleta at gmail.com  Wed Nov 19 22:26:06 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 19 Nov 2008 13:26:06 -0900
Subject: My roadmap for a better Fedora
In-Reply-To: <20081119221721.GH26527@redhat.com>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>
	<20081119205950.GA4961@nostromo.devel.redhat.com>
	<adf480660811191323i552f933dy156a8416e22561ad@mail.gmail.com>
	<20081119221721.GH26527@redhat.com>
Message-ID: <604aa7910811191426x7a59c984x3e0721fa69ae7887@mail.gmail.com>

On Wed, Nov 19, 2008 at 1:17 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> Utterly useless. I already have a HUGE number of bug reports. The problem
> is that 90% of them are essentially useless when first reported. It requires
> several back/forth interactions between myself & the bug reporter to get
> enough information to diagnose & resolve the problem. If we create a system
> where we bombard maintainers with bugreports & no scope for user interaction
> they'll end up directly in /dev/null, and further discourage maintainers
> from addressing even bugs with enough info.

Is the upstream automated kerneloops stuff a counter example
methodology? Or does that only work because they get sooooooo many
more crash reports that the statistics become a useful way to sort?

-jef



From lesmikesell at gmail.com  Wed Nov 19 22:31:06 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 19 Nov 2008 16:31:06 -0600
Subject: My roadmap for a better Fedora
In-Reply-To: <20081119221544.GE31216@localhost.localdomain>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<20081119221544.GE31216@localhost.localdomain>
Message-ID: <492493AA.30108@gmail.com>

Chris Lumens wrote:
> I'd like to add a step (0) before we make bugs easier to file and really
> crank up the number of reports we're getting:
> 
> (0) More people FIXING the bug, not just reporting them.  You can have a
> giant user base of people filing tons of bugs, and you can have a
> motivated and effective QA/Triaging team whittling them down to the
> really important and reproducable bugs.  But without more people fixing
> them, the backlog is just going to continue to build.

Except for fedora-specific quirks, fixing should be an upstream issue. 
What a distribution needs to know is whether upstream had a bad day or 
not before pushing some drek to unsuspecting users.  If you had 
sufficient testing before release, or a place for user testing/reporting 
before full release that can expose the fact that a particular update is 
not ready for prime time just don't do that update.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From fedora at shmuelhome.mine.nu  Wed Nov 19 22:40:53 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Thu, 20 Nov 2008 00:40:53 +0200
Subject: My roadmap for a better Fedora
In-Reply-To: <20081119221311.GD31216@localhost.localdomain>
References: <1227119906.7387.138.camel@localhost.localdomain>	<adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>	<20081119205950.GA4961@nostromo.devel.redhat.com>	<adf480660811191323i552f933dy156a8416e22561ad@mail.gmail.com>
	<20081119221311.GD31216@localhost.localdomain>
Message-ID: <492495F5.10908@shmuelhome.mine.nu>

Chris Lumens wrote:
> A drive-by bug assault is going to do nothing but bury me in useless bug
> reports that someone will have to spend time picking through and duping
> to one that might actually be useful.  Such bug reports are better off
> never existing.
>
> - Chris
>   
Given a big enough triage staff, they can try to take these bug reports 
and turn them into something useful to maintainers. Without such a 
staff, I would agree with you.




From gnomeuser at gmail.com  Wed Nov 19 22:39:47 2008
From: gnomeuser at gmail.com (David Nielsen)
Date: Wed, 19 Nov 2008 23:39:47 +0100
Subject: My roadmap for a better Fedora
In-Reply-To: <20081119221721.GH26527@redhat.com>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>
	<20081119205950.GA4961@nostromo.devel.redhat.com>
	<adf480660811191323i552f933dy156a8416e22561ad@mail.gmail.com>
	<20081119221721.GH26527@redhat.com>
Message-ID: <1dedbbfc0811191439h4a3d322aof6f30d79c0f0088f@mail.gmail.com>

2008/11/19 Daniel P. Berrange <berrange at redhat.com>

> On Thu, Nov 20, 2008 at 12:23:42AM +0300, Peter Lemenkov wrote:
> > 2008/11/19, Bill Nottingham <notting at redhat.com>:
> > > Because it's not a one-way communication (at least, not if you want it
> > >  to be effective.)
> >
> > I think you misundestood something. If order to effectively hunt
> > issues, we definitely need HUGE number of bugreports (remember
> > Necrosoft's "Send crash dump" utility). That definitely means one-way
> > communication. I'm insisting - one-way communication (e.g. user will
> > send bugreport to invisible-to-him blackhole, w/o answer, with some
> > handy tool).
>
> Utterly useless. I already have a HUGE number of bug reports. The problem
> is that 90% of them are essentially useless when first reported. It
> requires
> several back/forth interactions between myself & the bug reporter to get
> enough information to diagnose & resolve the problem. If we create a system
> where we bombard maintainers with bugreports & no scope for user
> interaction
> they'll end up directly in /dev/null, and further discourage maintainers
> from addressing even bugs with enough info.


One of the ideas with something like apport is that you can get it to send
you the log files you need and other related information. I would think
something like this would at least reduce the amount of time you spend
asking for log files and other information or at least compensate for the
increased bug report count. I don't know how apport+launchpad does this but
when a bug is filed through apport, it gives you the top reported bugs and
the ones most similar to the one you are reporting to avoid duplicates. User
interaction is done though the launchpad account, we could simply offer to
help the user open a bugzilla account in the same fashion.

All of this sounds like what we want, not having such programs certain
doesn't stop applications from crashing, it just lets us know how bad we
really are.

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081119/43eae0e2/attachment.htm>

From pemboa at gmail.com  Wed Nov 19 22:43:45 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 19 Nov 2008 16:43:45 -0600
Subject: My roadmap for a better Fedora
In-Reply-To: <1227119906.7387.138.camel@localhost.localdomain>
References: <1227119906.7387.138.camel@localhost.localdomain>
Message-ID: <16de708d0811191443m72e364bcu645655c617776f94@mail.gmail.com>

2008/11/19 Callum Lerwick <seg at haxxed.com>:
> So, many pieces of this have been blabbed about by me and others
> recently and in the past, but I think a lot of people aren't seeing the
> big picture. I think it's time I fit it all together.

A lot of critiques end up quickly deteriorating into whiners, sad but true.

> Problem: Fedora is buggy, and updates are rife with regressions.
>
> Solution: We need more and wider testing.
>
> Problem: We need more and wider testing. Why don't we get more testing?

[ snip ]

My only issue why I do not test a lot more is the lack of requests.
There is too much software to just "test'. If there was an RSS
fees/email alert/etc system which alerted me every time someone wanted
something tested. I would do a lot more testing. I have box dedicated
to rawhide which I will glad screw over in the name of testing. But it
is not my primary machines, I am not using it every day.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From pemboa at gmail.com  Wed Nov 19 22:47:54 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 19 Nov 2008 16:47:54 -0600
Subject: What do we need from Bugzilla? (was: My roadmap for a better Fedora)
Message-ID: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>

This question is (for now) most a question of interest and curiosity.
Maybe one day I may be bored and try to rewrite Bugzilla, who knows.

My question is, what do we need/want/like from Bugzilla? There are
several competing products, and I doubt we engineer type people use it
"just because". I'm also assuming that we use it for reasons other
than because of RedHat.

Can the unique features be enumerated for me?

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From mschwendt at gmail.com  Wed Nov 19 23:24:09 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 20 Nov 2008 00:24:09 +0100
Subject: F11: things to check in a release tree before a release
In-Reply-To: <20081119220328.GA1371485@hiwaay.net>
References: <alpine.LFD.2.00.0811191547010.10340@localhost.localdomain>
	<20081119222235.699e4437.mschwendt@gmail.com>
	<alpine.LFD.2.00.0811191628050.10340@localhost.localdomain>
	<20081119223810.a43dfa41.mschwendt@gmail.com>
	<20081119220328.GA1371485@hiwaay.net>
Message-ID: <20081120002409.16768218.mschwendt@gmail.com>

On Wed, 19 Nov 2008 16:03:28 -0600, Chris Adams wrote:

> I'd suggest expanding that to check perl (and other language) module
> provides as well.
> 
> For example, for a while MRTG included a private copy of the RRD perl
> modules, and "mrtg" was shorter than "rrdtool-perl", so anything using
> the RRD modules would auto-dep pull in MRTG (which didn't solve the
> dep).

Yes, useful.

Example:

perl-SOAP-Lite  from  perl-SOAP-Lite
    provides perl(LWP::Protocol)
perl-libwww-perl  from  perl-libwww-perl
    provides perl(LWP::Protocol) EQ 0 1.46
    required by: 1:perl-LDAP-0.34-4.fc9.noarch
    required by: perl-libwww-perl-5.808-7.fc9.noarch

Several of such conflicts have been fixed. Others have become victims of
the early bug-triaging madness. Such conflicts pop up like mushrooms (Mono
also adds several suspicious ones). Sometimes one can find obsolete Perl
packages:

perl  from  perl
    provides perl(TAP::Parser::Source) EQ 0 3.12
perl-TAP-Harness  from  perl-TAP-Harness
    provides perl(TAP::Parser::Source) EQ 0 3.10
    required by: perl-TAP-Harness-3.10-1.fc9.noarch
    required by: 4:perl-5.10.0-38.fc10.i386

If you really want to check all sorts of multiple Provides, that'll be
a long list with a lot that must be white-listed.



From skvidal at fedoraproject.org  Wed Nov 19 23:51:43 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 19 Nov 2008 18:51:43 -0500 (EST)
Subject: F11: things to check in a release tree before a release
In-Reply-To: <20081120002409.16768218.mschwendt@gmail.com>
References: <alpine.LFD.2.00.0811191547010.10340@localhost.localdomain>
	<20081119222235.699e4437.mschwendt@gmail.com>
	<alpine.LFD.2.00.0811191628050.10340@localhost.localdomain>
	<20081119223810.a43dfa41.mschwendt@gmail.com>
	<20081119220328.GA1371485@hiwaay.net>
	<20081120002409.16768218.mschwendt@gmail.com>
Message-ID: <alpine.LFD.2.00.0811191851130.10340@localhost.localdomain>



On Thu, 20 Nov 2008, Michael Schwendt wrote:

> On Wed, 19 Nov 2008 16:03:28 -0600, Chris Adams wrote:
>
>> I'd suggest expanding that to check perl (and other language) module
>> provides as well.
>>
>> For example, for a while MRTG included a private copy of the RRD perl
>> modules, and "mrtg" was shorter than "rrdtool-perl", so anything using
>> the RRD modules would auto-dep pull in MRTG (which didn't solve the
>> dep).
>
> Yes, useful.
>
> Example:
>
> perl-SOAP-Lite  from  perl-SOAP-Lite
>    provides perl(LWP::Protocol)
> perl-libwww-perl  from  perl-libwww-perl
>    provides perl(LWP::Protocol) EQ 0 1.46
>    required by: 1:perl-LDAP-0.34-4.fc9.noarch
>    required by: perl-libwww-perl-5.808-7.fc9.noarch
>
> Several of such conflicts have been fixed. Others have become victims of
> the early bug-triaging madness. Such conflicts pop up like mushrooms (Mono
> also adds several suspicious ones). Sometimes one can find obsolete Perl
> packages:
>
> perl  from  perl
>    provides perl(TAP::Parser::Source) EQ 0 3.12
> perl-TAP-Harness  from  perl-TAP-Harness
>    provides perl(TAP::Parser::Source) EQ 0 3.10
>    required by: perl-TAP-Harness-3.10-1.fc9.noarch
>    required by: 4:perl-5.10.0-38.fc10.i386
>
> If you really want to check all sorts of multiple Provides, that'll be
> a long list with a lot that must be white-listed.

I was thinking along the lines of we generate the list, manually check.

Then we work on generating diffs vs past lists for the future.

so we aren't constantly seeing the same stream of data.

-sv



From kevin at scrye.com  Thu Nov 20 00:09:09 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Wed, 19 Nov 2008 17:09:09 -0700
Subject: source file audit - 2008-11-14
Message-ID: <20081119170909.29694973@ohm.scrye.com>

Here's attached another run of my sources/patches url checker. 
Sorry for the delay in re-running this. 

Hopefully I will start running it again at the first of each month. 

- There are 912 lines in this run. Up from 662 last run.
This is a pretty sad increase. ;( 

   700 sourcecheck-20070826.txt
   620 sourcecheck-20070917.txt
   561 sourcecheck-20071017.txt
   775 sourcecheck-20080206.txt
   685 sourcecheck-20080214.txt
   674 sourcecheck-20080301.txt
   666 sourcecheck-20080401.txt
   660 sourcecheck-20080501.txt
   642 sourcecheck-20080603.txt
   649 sourcecheck-20080705.txt
   662 sourcecheck-20080801.txt
   912 sourcecheck-20081114.txt

- I hope to email maintainers this time about their packages. 
I didn't get to it last time. 

You can find the results file at: 

http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20081114.txt

And also attached to this mail. 

Lines in the output are of three forms: 

- BADURL:base-file-name:$PACKAGENAME

This means that the URI provided in the Source(s) line didn't result in
a download of the source. This could be any of: URL changed, version
changed and URL wasn't updated, Site is down, Site is gone, etc. 
Also there are a number of packages with incorrect sourceforge links. 
(BTW, there are still some packages with ftp://people.redhat.com/
URLs). 

- BADSOURCE:$SOURCENAME:$PACKAGENAME

This means that the source was downloaded ok from the upstream site,
but doesn't match the md5sum given in the sources file. 
This could be due to needing to strip out content that fedora cannot
ship (but in that case you shouldn't have the full URI in the Source
line). Or upstream following poor release practices and updating
without changing their release.

- BAD_CVS_SOURCE:$SOURCENAME:$PACKAGENAME

This means that the file was downloaded from the URI given, and the
md5sum did not match the file thats present in CVS (not the lookaside).
This might be due to timestamps, or any of the above reasons. 

kevin
--
abompard:BADSOURCE:cryptopp552.zip:cryptopp
abompard:BADSOURCE:libvisual-0.4.0.tar.gz:libvisual
abompard:BADURL:pdftohtml-0.36.tar.gz:pdftohtml
adalloz:BADURL:pan-0.133.tar.bz2:pan
adrian:BADSOURCE:libcdio-0.80.tar.gz.sig:libcdio
ajax:BADURL:powertop-1.10.tar.gz:powertop
akahl:BADURL:bmpx-0.40.14.tar.bz2:bmpx
allisson:BADURL:amora-server-1.1.tar.gz:amora
amdunn:BADSOURCE:alt-ergo-0.8.tar.gz:alt-ergo
andriy:BAD_CVS_SOURCE:fmio-gq-wrapper.py:fmio
ascii:BADURL:fish-1.23.0.tar.bz2:fish
asheesh:BADURL:liblicense-0.8.tar.gz:liblicense
ashokdas:BADURL:elfinfo-1.0.tar.gz:elfinfo
ashokdas:BADURL:greadelf-0.4.tar.gz:greadelf
athimm:BADURL:chrpath-0.13.tar.gz:chrpath
athimm:BADURL:fakeroot_1.9.7.tar.gz:fakeroot
athimm:BADURL:greylistd_0.8.7.tar.gz:greylistd
athimm:BADURL:po4a-0.34.tar.gz:po4a
atkac:BADURL:adns-python-1.2.1.tar.gz:python-adns
atkac:BADURL:rexec-1.5.tar.gz:rsh
atkac:BADURL:vnc-4_1_2-unixsrc.tar.gz:vnc
atkac:BADURL:xdelta-1.1.4.tar.gz:xdelta
ausil:BADSOURCE:elftoaout-2.3.tgz:elftoaout
ausil:BADSOURCE:silo-1.4.13.tar.bz2:silo
ausil:BADSOURCE:usb8388-5.110.22.p14.bin.md5:libertas-usb8388-firmware
ausil:BADURL:mysql-gui-tools-5.0r12.tar.gz:mysql-gui-tools
ausil:BADURL:snort-2.8.1.tar.gz:snort
awjb:BAD_CVS_SOURCE:wmweather+-2.9.tar.gz:wmweather+
awjb:BADSOURCE:claws-mail-3.6.0.tar.bz2:claws-mail
awjb:BADSOURCE:libpolyxmass-0.9.1.tar.gz:libpolyxmass
awjb:BADSOURCE:polyxmass-bin-0.9.7.tar.gz:polyxmass-bin
awjb:BADURL:freealut-1.1.0.tar.gz:freealut
awjb:BADURL:httplib2-0.4.0.tar.gz:python-httplib2
awjb:BADURL:koffice-1.9.98.2.tar.bz2:koffice
awjb:BADURL:libAfterImage-1.18.tar.bz2:libAfterImage
awjb:BADURL:libmimedir-0.4.tar.gz:libmimedir
awjb:BADURL:libytnef-1.5.tar.bz:libytnef
awjb:BADURL:synce-serial-0.11.tar.gz:synce-serial
awjb:BADURL:treecc-0.3.8.tar.gz:treecc
awjb:BADURL:WindowMaker-0.92.0.tar.bz2:WindowMaker
awjb:BADURL:WindowMaker-extra-0.1.tar.gz:WindowMaker
belegdol:BADSOURCE:qsa-x11-free-1.1.5.tar.gz:qt-qsa
belegdol:BADURL:gnome-chemistry-utils-0.10.0.tar.bz2:gnome-chemistry-utils
belegdol:BADURL:goffice-0.4.3.tar.bz2:goffice04
belegdol:BADURL:museek+-0.1.13.tar.bz2:museek+
bellet:BAD_CVS_SOURCE:fg-16.png:FlightGear
ben:BADSOURCE:ketchup-0.9.8.tar.bz2:ketchup
bjensen:BADSOURCE:demorse-0.9.tar.gz:demorse
bjensen:BADSOURCE:lpsk31-1.1.tar.gz:lpsk31
bjensen:BADSOURCE:xnec2c-1.0b5.tar.gz:xnec2c
bjensen:BADURL:fldigi-3.01.tar.gz:fldigi
bjensen:BADURL:xfhell-1.4.tar.gz:xfhell
bkearney:BADURL:Moon-8.tar.bz2:sugar-moon
bkearney:BADURL:TurtleArt-14.tar.bz2:sugar-turtleart
bochecha:BADURL:adonthell-0.3.5.tar.gz:adonthell
bojan:BADURL:libapreq2-2.10-RC1.tar.gz:libapreq2
bos:BADURL:alex-2.3.tar.gz:alex
bouska:BADURL:kitsune2.0.tar.gz:kitsune
bpeck:BADURL:conmux-493svn.tar.gz:conmux
bpepple:BADURL:freeciv-2.1.6.tar.bz2:freeciv
bpepple:BADURL:ggz-gtk-client-0.0.14.1.tar.gz:ggz-gtk-client
bpepple:BADURL:meld-1.2.tar.bz2:meld
bpepple:BADURL:nautilus-image-converter-0.3.0.tar.bz2:nautilus-image-converter
bpepple:BADURL:nautilus-sound-converter-0.7.0.tar.bz2:nautilus-sound-converter
bpepple:BADURL:swfdec-gnome-2.24.0.tar.bz2:swfdec-gnome
bradbell:BADSOURCE:cppad-20080826.0.gpl.tgz:cppad
buc:BADURL:enca-1.9.tar.bz2:enca
caolanm:BADSOURCE:icu4c-4_0-src.tgz:icu
caolanm:BADSOURCE:myspell-af_ZA-20060117.zip:hunspell-af
caolanm:BADSOURCE:myspell-nr_ZA-20060120.zip:hunspell-nr
caolanm:BADSOURCE:OOo-Thesaurus2-sk_SK.zip:mythes-sk
caolanm:BADSOURCE:thes_de_DE_v2.zip:mythes-de
caolanm:BADSOURCE:writer2latex0502.zip:writer2latex
caolanm:BADURL:evolocal.odb:openoffice.org
caolanm:BADURL:sjp-myspell-pl-20080823.zip:hunspell-pl
caolanm:BADURL:vi_VN.zip:hunspell-vi
cchance:BADURL:nhpf-1.42.tar.gz:nhpf
cgrau:BADURL:frotz-2.43.tar.gz:frotz
cgrau:BADURL:ifm-5.1.tar.gz:ifm
cheekyboinc:BADURL:xpad-3.0.tar.bz2:xpad
chitlesh:BADSOURCE:crystal_project.tar.gz:crystal-project
chitlesh:BADSOURCE:kpolynome-0.1-2.tar.gz:kpolynome
chitlesh:BADURL:CrystalClear.tar.gz:crystal-clear
chitlesh:BADURL:crystal-kwin4-1.0.5.tar.bz2:crystal
chitlesh:BADURL:geda-docs-1.4.1.tar.gz:geda-docs
chitlesh:BADURL:geda-examples-1.4.1.tar.gz:geda-examples
chitlesh:BADURL:geda-gattrib-1.4.1.tar.gz:geda-gattrib
chitlesh:BADURL:geda-gnetlist-1.4.1.tar.gz:geda-gnetlist
chitlesh:BADURL:geda-gschem-1.4.1.tar.gz:geda-gschem
chitlesh:BADURL:geda-gsymcheck-1.4.1.tar.gz:geda-gsymcheck
chitlesh:BADURL:geda-symbols-1.4.1.tar.gz:geda-symbols
chitlesh:BADURL:geda-utils-1.4.1.tar.gz:geda-utils
chitlesh:BADURL:keurocalc-1.0.0.tgz:keurocalc
chitlesh:BADURL:libgeda-1.4.1.tar.gz:libgeda
chitlesh:BADURL:liborigin-20080225.tar.gz:liborigin
chrisw:BADSOURCE:cogito-0.18.2.tar.gz:cogito
chrisw:BADURL:asciidoc-8.2.5.tar.gz:asciidoc
cjb:BADURL:ohm-0.1.1-1.20080921git.tar.gz:ohm
clumens:BADURL:gnu-efi-3.0e.tar.bz2:gnu-efi
ctrl-center-team:BADURL:gnome-control-center-2.25.1.tar.bz2:control-center
cweyl:BAD_CVS_SOURCE:apsl-2.0.txt:hfsplus-tools
cweyl:BADURL:cpan-upload-2.2.tar.gz:cpan-upload
cweyl:BADURL:diskdev_cmds-332.14.tar.gz:hfsplus-tools
cweyl:BADURL:gaim-2.0.0beta4.tar.gz:gaim-gaym
cweyl:BADURL:JSON-XS-2.2222.tar.gz:perl-JSON-XS
cweyl:BADURL:POE-Filter-IRCD-2.2.tar.gz:perl-POE-Filter-IRCD
cweyl:BADURL:qrc-0.96-293svn.tar.gz:gaim-gaym
cwickert:BADURL:thunar-shares-0.16.tar.gz:thunar-shares
cwickert:BADURL:xfce4-dev-tools-4.4.0.1.tar.bz2:xfce4-dev-tools
danken:BADURL:bidiv-1.5.tgz:bidiv
danken:BADURL:hspell-1.0.tar.gz:hspell
danms:BADSOURCE:libcmpiutil-0.4.tar.gz:libcmpiutil
davidz:BADURL:festvox_nitech_us_awb_arctic_hts.tar.bz2:festival
davidz:BADURL:festvox_nitech_us_bdl_arctic_hts.tar.bz2:festival
davidz:BADURL:festvox_nitech_us_clb_arctic_hts.tar.bz2:festival
davidz:BADURL:festvox_nitech_us_jmk_arctic_hts.tar.bz2:festival
davidz:BADURL:festvox_nitech_us_rms_arctic_hts.tar.bz2:festival
davidz:BADURL:festvox_nitech_us_slt_arctic_hts.tar.bz2:festival
davidz:BADURL:notification-daemon-0.3.7.90.tar.bz2:notification-daemon
dbhole:BADURL:commons-validator-1.1.4-src.tar.gz:jakarta-commons-validator
dbhole:BADURL:lucene-2.3.1-src.tar.gz:lucene
dbhole:BADURL:ow_util_ant_tasks_1.3.2.zip:objectweb-anttask
dbhole:BADURL:wrapper_3.2.3_src.tar.gz:tanukiwrapper
dcantrel:BADURL:repoman-0.9.tar.gz:repoman
dcbw:BADURL:Csound5.03.0_src-cvs20061108.tar.bz2:csound
dchen:BADSOURCE:libUnihan-0.5.3-Source.tar.gz:libUnihan
dchen:BADSOURCE:scim-array-1.0.0.tar.gz:scim-array
dchen:BADSOURCE:WritRecogn-0.1.9.tar.gz:WritRecogn
dchen:BADSOURCE:zhcon_0.2.6-4.1.diff.gz:zhcon
dchen:BADURL:fbterm-1.1.tar.gz:fbterm
dchen:BADURL:libchewing-0.3.1.tar.bz2:libchewing
dchen:BADURL:scim-chewing-0.3.2.tar.bz2:scim-chewing
deebs:BADSOURCE:GREYCstoration-2.8.zip:GREYCstoration
deji:BADURL:file-browser-applet-0.5.9.tar.gz:file-browser-applet
denis:BADURL:ghasher-1.2.1.tar.gz:ghasher
denis:BADURL:goocanvasmm-0.9.0.tar.bz2:goocanvasmm
denis:BADURL:hamlib-1.2.7.tar.gz:hamlib
denis:BADURL:libgnomedb-3.1.2.tar.bz2:libgnomedb
denis:BADURL:libpanelappletmm-2.22.0.tar.bz2:libpanelappletmm
denis:BADURL:libsigc++-1.2.7.tar.bz2:libsigc++
denis:BADURL:pangomm-2.14.0.tar.bz2:pangomm
denis:BADURL:pstoedit-3.45.tar.gz:pstoedit
desi:BADSOURCE:cwrite-0.1.24.tar.gz:cwrite
devrim:BADSOURCE:postgis-1.3.3.tar.gz:postgis
devrim:BADURL:pgpoolAdmin-1.0.0.tar.gz:postgresql-pgpoolAdmin
devrim:BADURL:saxon6-5-5.zip:saxon
dgoodwin:BADURL:wuja-0.0.8.tar.gz:wuja
drago01:BADURL:linkage-0.2.0.tar.gz:linkage
dwalluck:BAD_CVS_SOURCE:hamcrest-parent-1.1.pom:hamcrest
dwalluck:BADURL:hamcrest-1.1.tgz:hamcrest
dwalsh:BADSOURCE:checkpolicy-2.0.16.tgz:checkpolicy
dwalsh:BADURL:libselinux-2.0.75.tgz:libselinux
dwalsh:BADURL:libsemanage-2.0.29.tgz:libsemanage
dwalsh:BADURL:libsepol-2.0.34.tgz:libsepol
dwalsh:BADURL:mcstrans-0.2.11.tgz:mcstrans
dwalsh:BADURL:policycoreutils-2.0.59.tgz:policycoreutils
dwalsh:BADURL:selinux-doc-1.26.tgz:selinux-doc
dwalsh:BADURL:sepolgen-1.0.13.tgz:policycoreutils
dwmw2:BADSOURCE:yaboot-1.3.14.tar.gz:yaboot
dwmw2:BADURL:apmud-1.0.0.tgz:apmud
dwmw2:BADURL:config.samples-20050415.tar.bz2:exim-doc
dwmw2:BADURL:FAQ-html-20050415.tar.bz2:exim-doc
dwmw2:BADURL:hfsplus_1.0.4.src.tar.bz2:hfsplusutils
dwmw2:BADURL:libpng-1.2.16.tar.bz2:petitboot
dwmw2:BADURL:nano-2.0.6.tar.gz:nano
dwmw2:BADURL:qemu-0.9.1.tar.gz:qemu
ecik:BADSOURCE:mx610_notify-0.3.1.tar.bz2:kadu
ecik:BADSOURCE:water_notify-0.1.1-try2.tar.bz2:kadu
ecik:BADURL:dcopexport-0.11.3-20071129-0.6.0.tar.bz2:kadu
ecik:BADURL:ZSI-2.0.tar.gz:python-ZSI
edhill:BADSOURCE:cdo.pdf:cdo
edhill:BADSOURCE:cdo_refcard.pdf:cdo
edhill:BADURL:libctl-3.0.2.tar.gz:libctl
edhill:BADURL:wifiroamd-1.14.tar.gz:wifiroamd
ensc:BAD_CVS_SOURCE:libtasn1-1.5.tar.gz.sig:libtasn1
ensc:BADSOURCE:ip-sentinel-0.12.tar.bz2.sig:ip-sentinel
ensc:BADURL:dhcp-forwarder-0.7.tar.bz2.asc:dhcp-forwarder
ensc:BADURL:dhcp-forwarder-0.7.tar.bz2:dhcp-forwarder
ensc:BADURL:hunt-1.5.tgz:hunt
ensc:BADURL:libtasn1-1.5.tar.gz:libtasn1
eponyme:BADSOURCE:printoxx-1.6.tar.gz:printoxx
eponyme:BADSOURCE:trustyrc-0.1.2.tar.gz:trustyrc
eponyme:BADURL:fotoxx-5.5.tar.gz:fotoxx
erikos:BADURL:Browse-99.tar.bz2:sugar-browse
erikos:BADURL:Log-16.tar.bz2:sugar-log
errr:BADURL:tenr-de-styles-pkg-1.1.tar.bz2:tenr-de-styles-pkg
fab:BADURL:weplab-0.1.5.tar.gz:weplab
faucamp:BAD_CVS_SOURCE:tetrinetx-1.13.16+qirc-1.40c.tar.gz:tetrinetx
firewing:BADSOURCE:fwfstab-0.03.tar.gz:fwfstab
fnasser:BAD_CVS_SOURCE:asm-3.1.pom:objectweb-asm
fnasser:BADSOURCE:inetlib-1.1.1.tar.gz:classpathx-mail
frankb:BAD_CVS_SOURCE:nasd.init:nas
frankb:BADURL:nas-1.9.1.src.tar.gz:nas
gemi:BADSOURCE:curry-0.9.11.tar.gz:curry
gemi:BADSOURCE:HTMLmanual.tar.gz:pl
gemi:BADSOURCE:pl-5.6.60.tar.gz:pl
gemi:BADURL:ffcall-20080704cvs.tar.bz2:ffcall
gemi:BADURL:Gauche-gl-0.4.4.tgz:gauche-gl
gemi:BADURL:qcad-manual-en-2.0.4.0-1.html.zip:qcad
gemi:BADURL:SmartEiffel-2-3.tar.bz2:smarteiffel
gilboa:BAD_CVS_SOURCE:cgdb.png:cgdb
gilboa:BADSOURCE:kdebluetooth4-0.2.tar.bz2:kdebluetooth
green:BADURL:common-lisp-controller_6.15.tar.gz:common-lisp-controller
green:BADURL:libffi-3.0.5.tar.gz:libffi
green:BADURL:liblo-0.24.tar.gz:liblo
green:BADURL:liblrdf-0.4.0.tar.gz:liblrdf
green:BADURL:whysynth-20080412.tar.bz2:whysynth-dssi
guthrie:BADURL:dxpc-3.9.1.tgz:dxpc
hadess:BADURL:gdata.py-1.2.2.tar.gz:python-gdata
hadess:BADURL:gnome-lirc-properties-0.3.1.tar.gz:gnome-lirc-properties
hadess:BADURL:nautilus-sendto-1.1.0.tar.bz2:nautilus-sendto
hadess:BADURL:totem-2.24.3.tar.bz2:totem
homeless:BADSOURCE:rudecgi-5.1.0.tar.bz2:rudecgi
huzaifas:BADSOURCE:libnova-0.12.1.tar.gz:libnova
huzaifas:BADSOURCE:python-lzo-1.08.tar.gz:python-lzo
ianweller:BADURL:flam3-2.7.16.tar.gz:flam3
ianweller:BADURL:qosmic-1.4.2.tar.bz2:qosmic
iburrell:BADURL:Path-Class-0.16.tar.gz:perl-Path-Class
icon:BADURL:cvs2svn-2.1.1.tar.gz:cvs2svn
icon:BADURL:epylog-1.0.3.tar.gz:epylog
icon:BADURL:feedparser-4.1.zip:python-feedparser
icon:BADURL:kodos-2.4.9.tar.gz:kodos
icon:BADURL:libxml++-2.23.2.tar.bz2:libxml++
icon:BADURL:poedit-1.3.9.tar.gz:poedit
icon:BADURL:twitux-0.65.tar.bz2:twitux
icon:BADURL:verbiste-0.1.23.tar.gz:verbiste
ivazquez:BADURL:purple-plugin_pack-2.4.0.tar.bz2:purple-plugin_pack
ivazquez:BADURL:pywebkitgtk-1.0.1.tar.gz:pywebkitgtk
ixs:BADURL:bacula-2.4.3.tar.gz:bacula
ixs:BADURL:commoncpp2-1.6.1.tar.gz:commoncpp2
ixs:BADURL:DBM-Deep-0.983.tar.gz:perl-DBM-Deep
ixs:BADURL:GraphicsMagick-1.1.14.tar.bz2:GraphicsMagick
ixs:BADURL:gsynaptics-0.9.14.tar.gz:gsynaptics
ixs:BADURL:MD5-2.03.tar.gz:perl-MD5
ixs:BADURL:metapixel-1.0.2.tar.gz:metapixel
ixs:BADURL:ser-0.9.6_src.tar.gz:ser
jakub:BADURL:prelink-20071009.tar.bz2:prelink
jamatos:BADURL:HTMLgen.tar.gz:python-HTMLgen
jamatos:BADURL:t1lib_5.1.1-3.diff.gz:t1lib
james:BADURL:zsh-4.3.6.tar.bz2:zsh
jbowes:BADURL:Elixir-0.6.1.tar.gz:python-elixir
jbowes:BADURL:mod_wsgi-2.3.tar.gz:mod_wsgi
jcollie:BADURL:iksemel-1.3.tar.gz:iksemel
jcollie:BADURL:lxml-2.1.2.tar.gz:python-lxml
jeckersb:BADURL:netaddr-0.5.2.tar.gz:python-netaddr
jeffg:BADSOURCE:pbzip2-1.0.2.tar.gz:pbzip2
jgarzik:BADURL:reiserfsprogs-3.6.19.tar.gz:reiserfs-utils
jgu:BADURL:dvipdfmx-20080617.tar.gz:dvipdfmx
jhrozek:BADURL:pv-1.1.4.tar.gz:pv
jima:BADURL:libdnet-1.12.tgz:libdnet
jima:BADURL:rblcheck-1.5.tar.gz:rblcheck
jima:BADURL:videodog0.31.tar.gz:videodog
jjames:BADURL:check-0.9.5.tar.gz:check
jjames:BADURL:latexmk-401.zip:latexmk
jjh:BADURL:crypt-1.17.tar.bz2:libtomcrypt
jjh:BADURL:ltm-0.41.tar.bz2:libtommath
jjh:BADURL:tinyproxy-1.6.4.tar.gz:tinyproxy
jjohnstn:BADURL:eclipse-cdt-fetched-src-autotools-1_0_1.tar.gz:eclipse-cdt
jjohnstn:BADURL:eclipse-cdt-fetched-src-libhover-1_0_0.tar.gz:eclipse-cdt
jjohnstn:BADURL:eclipse-changelog-src-2.6.3.zip:eclipse-changelog
jkeating:BAD_CVS_SOURCE:rpm-spec-mode.el:emacs
jkeating:BADSOURCE:email2trac.tar.gz:email2trac
jlaska:BADURL:snake-0.11-0.9.tar.bz2:snake
jlayton:BADSOURCE:ez-ipupdate-3.0.11b8.tar.gz:ez-ipupdate
jlayton:BADURL:ez-ipupdate_3.0.11b8-10.diff.gz:ez-ipupdate
jmoskovc:BAD_CVS_SOURCE:rdist-eu-license.txt:rdist
jmoskovc:BADURL:gnome-bluetooth-0.11.0.tar.bz2:gnome-bluetooth
jmoskovc:BADURL:lynx2.8.6.tar.bz2:lynx
jmoskovc:BADURL:rarpd-ss981107.tar.gz:rarpd
jmoskovc:BADURL:rdate-1.4.tar.gz:rdate
jmoskovc:BADURL:xferstats-2.16.tar.gz:xferstats
jmrcpn:BADURL:clement-2.1-241.tar.gz:clement
jnovy:BADSOURCE:envlab.tar.lzma:texlive-texmf
jnovy:BADSOURCE:multican-0.0.5.tar.gz:multican
jnovy:BADURL:dvipsk-jpatch-p1.7a.tar.bz2:texlive
jnovy:BADURL:mc-4.6.2-pre1.tar.gz:mc
jnovy:BADURL:platex209.tar.bz2:texlive-texmf
joost:BADURL:lazarus-0.9.26-0.tgz:lazarus
jorge:BADSOURCE:mimetex.zip:mimetex
jorton:BADURL:libidn-0.6.14.tar.gz:libidn
jorton:BADURL:webalizer-2.01-10-src.tar.bz2:webalizer
jpmahowa:BADSOURCE:numlockx-1.0.tar.gz:numlockx
jreznik:BADURL:arora-0.4.tar.gz:arora
jreznik:BADURL:pmpu-0.2.tar.bz2:pmpu
jroth:BADSOURCE:libspe2-2.3.0.135.tar.gz:libspe2
jsafrane:BADURL:net-snmp-5.4.2.1.tar.gz:net-snmp
jsanders:BADURL:veusz-1.1.tar.gz:veusz
jskala:BADURL:lftp-3.7.4.tar.gz:lftp
jspaleta:BADURL:pytz-2008i.tar.gz:pytz
jspaleta:BADURL:ScientificPython-2.6.1.tar.gz:ScientificPython
jwb:BAD_CVS_SOURCE:squid-getlist.html:squidGuard
jwb:BADSOURCE:blacklists.tar.gz:squidGuard
jwboyer:BADURL:ctrlproxy-3.0.7.tar.gz:ctrlproxy
jwboyer:BADURL:gquilt-0.20.tar.gz:gquilt
jwrdegoede:BADURL:ballz-1.0.1.tar.gz:ballz
jwrdegoede:BADURL:labysource_3.2.1.tar.gz:lostlabyrinth
jwrdegoede:BADURL:worminator-data-3.0R2.1.tar.gz:worminator-data
kanarip:BADSOURCE:attributes-5.0.1.gem:rubygem-attributes
kanarip:BADURL:publican-genome-1.0.tgz:publican-genome
kanarip:BADURL:pyjigdo-0.3.0.tar.gz:pyjigdo
kanarip:BADURL:spin-kickstarts-0.10.2.tar.gz:spin-kickstarts
karlik:BADURL:tesseract-2.00.deu.tar.gz:tesseract-langpack
karlik:BADURL:tesseract-2.00.eng.tar.gz:tesseract
karlik:BADURL:tesseract-2.00.fra.tar.gz:tesseract-langpack
karlik:BADURL:tesseract-2.00.ita.tar.gz:tesseract-langpack
karlik:BADURL:tesseract-2.00.nld.tar.gz:tesseract-langpack
karlik:BADURL:tesseract-2.00.spa.tar.gz:tesseract-langpack
karlik:BADURL:tesseract-2.03.tar.gz:tesseract
karlik:BADURL:warzone2100-2.1_beta5.tar.bz2:warzone2100
karsten:BADSOURCE:vim-7.2.tar.bz2:vim
karsten:BADURL:libcap-2.10.tar.bz2:libcap
kasal:BADURL:Business-ISBN-Data-1.15.tar.gz:perl-Business-ISBN-Data
kasal:BADURL:Date-Manip-5.48.tar.gz:perl-Date-Manip
kasal:BADURL:DBD-Pg-2.11.2.tar.gz:perl-DBD-Pg
kasal:BADURL:gdbm-1.8.0.tar.gz:gdbm
kasal:BADURL:libwww-perl-5.817.tar.gz:perl-libwww-perl
kasal:BADURL:transfig.3.2.5.tar.gz:transfig
kasal:BADURL:xfig.3.2.5.full.tar.gz:xfig
katzj:BADSOURCE:pyusb-0.4.1.tar.gz:pyusb
katzj:BADURL:Calculate-23.tar.bz2:sugar-calculator
katzj:BADURL:Chat-47.tar.bz2:sugar-chat
katzj:BADURL:Terminal-16.tar.bz2:sugar-terminal
katzj:BADURL:Write-59.tar.bz2:sugar-write
kevin:BADURL:gdk-pixbuf-0.22.0.tar.bz2:gdk-pixbuf
kevin:BADURL:gtk-xfce-engine-2.4.3.tar.bz2:gtk-xfce-engine
kevin:BADURL:mousepad-0.2.14.tar.bz2:mousepad
kevin:BADURL:Terminal-0.2.8.3.tar.bz2:Terminal
kevin:BADURL:Thunar-0.9.3.tar.bz2:Thunar
konradm:BADSOURCE:jruby-src-1.1.3.tar.gz:jruby
konradm:BADURL:jvyamlb-src-0.2.2.tar.gz:jvyamlb
konradm:BADURL:sympy-0.6.2.tar.gz:sympy
kraxel:BADURL:pngnq-0.5-src.tar.gz:pngnq
kushal:BADSOURCE:mediascrapper-0.1.tar.gz:mediascrapper
kwizart:BADURL:AnyEvent-4.3.tar.gz:perl-AnyEvent
kwizart:BADURL:oyranos-repack-0.1.7.tar.bz2:oyranos
kwizart:BADURL:PythonCAD-DS1-R36.tar.bz2:PythonCAD
kzak:BADURL:lslk_1.29_W.tar.gz:lslk
kzak:BADURL:vlock-1.3.tar.gz:vlock
langel:BADURL:icedtea6-1.4-b259b240929b353ed45c9a5a3eb641ee08a4829c.tar.gz:java-1.6.0-openjdk
laxathom:BADURL:gtk-sharp-2.12.5.tar.bz2:gtk-sharp2
laxathom:BADURL:specto-0.2.2.tar.gz:specto
lfarkas:BADURL:gstreamer-java-src-1.0.zip:gstreamer-java
lfarkas:BADURL:rxtx-2.1-7r2.zip:rxtx
limb:BADURL:kicad-sources--2007-07-09.zip:kicad
limb:BADURL:lilypond-2.11.57.tar.gz:lilypond
limb:BADURL:numpy-1.2.0.tar.gz:numpy
limb:BADURL:wesnoth-1.4.5.tar.bz2:wesnoth
limb:BADURL:xgalaga_2.0.34-44.diff.gz:xgalaxy
linville:BADURL:b43-fwcutter-011.tar.bz2:b43-fwcutter
liquidat:BADURL:Rsibreak-0.8.0.tar.bz2:rsibreak
liquidat:BADURL:speedcrunch-0.10.tar.gz:speedcrunch
lkundrak:BADSOURCE:lightning-sunbird-0.9-source.tar.bz2:sunbird
lkundrak:BADSOURCE:starlab-4.4.3.tar.gz:starlab
lkundrak:BADURL:netbsd-iscsi-20080207.tar.gz:netbsd-iscsi
lkundrak:BADURL:s3cmd-0.9.8.4.tar.gz:s3cmd
lkundrak:BADURL:String-Random-0.22.tar.gz:perl-String-Random
lkundrak:BADURL:TAP-Harness-JUnit-0.25.tar.gz:perl-TAP-Harness-JUnit
lmacken:BADSOURCE:PEAK-Rules-0.5a1.dev-r2581.tar.gz:python-peak-rules
lmacken:BADSOURCE:TurboFlot-0.1.1.tar.bz2:python-turboflot
lmacken:BADURL:DecoratorTools-1.7.zip:python-decoratortools
lmacken:BADURL:deskbar-applet-2.25.1.tar.bz2:deskbar-applet
lmacken:BADURL:FormEncode-1.0.1.tar.gz:python-formencode
lmacken:BADURL:naim-0.11.8.3.1.tar.bz2:naim
lmacken:BADURL:Paste-1.7.1.tar.gz:python-paste
lmacken:BADURL:PasteDeploy-1.3.2.tar.gz:python-paste-deploy
lmacken:BADURL:PasteScript-1.6.3.tar.gz:python-paste-script
lmacken:BADURL:python-irclib-0.4.6.tar.gz:python-irclib
lmacken:BADURL:simplejson-2.0.3.tar.gz:python-simplejson
lmacken:BADURL:SQLObject-0.10.2.tar.gz:python-sqlobject
lmacken:BADURL:TestGears-0.2.tar.gz:python-TestGears
lmacken:BADURL:TGCaptcha-0.11.tar.gz:python-tgcaptcha
lmacken:BADURL:TurboCheetah-1.0.tar.gz:python-turbocheetah
lmacken:BADURL:TurboMail-2.1.tar.gz:python-TurboMail
lucilanga:BADURL:tqsllib-2.0.tar.gz:tqsllib
lutter:BADSOURCE:gem2rpm-0.6.0.gem:rubygem-gem2rpm
lutter:BADURL:ruby-postgres-0.7.1.tar.gz:ruby-postgres
lvm-team:BADURL:dmraid-1.0.0.rc15.tar.bz2:dmraid
lyosnorezel:BADURL:ksensors_0.7.3-15.diff.gz:ksensors
mattdm:BADURL:calc-2.12.2.1.tar.gz:calc
maxx:BADSOURCE:pdfcube-0.0.2.tar.gz:pdfcube
maxx:BADURL:39179-rezlooks-0.6.tar.gz:gtk-rezlooks-engine
maxx:BADURL:Rezlooks-candy.tar.gz:gtk-rezlooks-engine
maxx:BADURL:Rezlooks-dark.tar.gz:gtk-rezlooks-engine
maxx:BADURL:Rezlooks-Gilouche.tar.gz:gtk-rezlooks-engine
maxx:BADURL:Rezlooks-graphite.tar.gz:gtk-rezlooks-engine
maxx:BADURL:Rezlooks-Snow.tar.gz:gtk-rezlooks-engine
mbarabas:BADURL:system-config-vsftpd-0.5.1.tar.gz:system-config-vsftpd
mbarnes:BADSOURCE:yelp-2.24.0.tar.bz2:yelp
mbarnes:BADURL:evolution-data-server-2.25.1.tar.bz2:evolution-data-server
mbarnes:BADURL:evolution-exchange-2.25.1.tar.bz2:evolution-exchange
mbarnes:BADURL:evolution-sharp-0.18.0.tar.bz2:evolution-sharp
mbarnes:BADURL:evolution-webcal-2.23.91.tar.bz2:evolution-webcal
mbarnes:BADURL:libsoup-2.25.1.tar.bz2:libsoup
mbarnes:BADURL:pygtk-2.13.0.tar.bz2:pygtk2
mbarnes:BADURL:pyorbit-2.24.0.tar.bz2:pyorbit
mbarnes:BADURL:python-ldap-2.3.5.tar.gz:python-ldap
mclasen:BADURL:cheese-2.25.1.tar.bz2:cheese
mclasen:BADURL:icon-naming-utils-0.8.7.tar.gz:icon-naming-utils
mcpierce:BADURL:cobbler-0.1.3.gem:rubygem-cobbler
mdomsch:BADURL:IPy-0.60.tar.gz:python-IPy
mebourne:BADURL:cambozola-0.68.tar.gz:zoneminder
mebrown:BADSOURCE:libsmbios-2.0.1.tar.gz:libsmbios
meme:BADURL:vultures-2.1.0-full.tar.bz2:nethack-vultures
mfleming:BADURL:mod-cband-0.9.7.5.tgz:mod_cband
mfleming:BADURL:pyicq-t-0.8b.tar.gz:pyicq-t
michaelc:BADURL:tgt-20080805.tar.bz2:scsi-target-utils
mikeb:BADURL:python-krbV-1.0.13.tar.gz:python-krbV
mitr:BADURL:4Suite-XML-1.0.2.tar.bz2:python-4Suite-XML
mitr:BADURL:stunnel-4.26.tar.gz.asc:stunnel
mitr:BADURL:stunnel-4.26.tar.gz:stunnel
mjakubicek:BADSOURCE:raytracer.tar.bz2:opticalraytracer
mjakubicek:BADURL:ext3grep-0.10.0.tar.gz:ext3grep
mlichvar:BADSOURCE:setlayout.c:openbox
mmahut:BADSOURCE:grc_0.70.tar.gz:grc
mmahut:BADURL:cmunipack-1.1.24.tar.gz:munipack
mmahut:BADURL:spacechart-0.9.5.tar.gz:spacechart
mmaslano:BADURL:Padre-0.14.tar.gz:perl-Padre
mmcgrath:BADURL:nagios-plugins-1.4.13.tar.gz:nagios-plugins
mmcgrath:BADURL:nrpe-2.7.tar.gz:nrpe
mmcgrath:BADURL:phpMyAdmin-3.0.1.1-all-languages.tar.bz2:phpMyAdmin
mmcgrath:BADURL:SOAP-Lite-0.710.07.tar.gz:perl-SOAP-Lite
mmcgrath:BADURL:ytalk-3.3.0.tar.gz:ytalk
mnowak:BADURL:id3-py_1.2.tar.gz:python-id3
mpg:BADURL:hulahop-0.4.7.tar.bz2:hulahop
mpg:BADURL:Journal-99.tar.bz2:sugar-journal
mschwendt:BADURL:audacious-plugin-fc-0.3.tar.bz2:audacious-plugin-fc
mso:BADURL:subtitleeditor-0.22.3.tar.gz:subtitleeditor
mtasaka:BADSOURCE:tempest.tar.gz:tempest
mtasaka:BADURL:gnome-commander-1.2.8-svn2274_trunk.tar.bz2:gnome-commander
mtasaka:BADURL:wallpapoz-0.4.1-svn87_trunk.tar.bz2:wallpapoz
mtruch:BADURL:kst-1.7.0.tar.gz:kst
muerte:BADURL:qcomicbook-0.4.0.tar.gz:qcomicbook
mwiriadi:BADURL:gnome-themes-extras-2.22.0.tar.gz:gnome-themes-extras
mwiriadi:BADURL:gpicview-0.1.10.tar.gz:gpicview
mwringe:BADSOURCE:jdepend-2.6-RHCLEAN.zip:jdepend
mwringe:BADURL:commons-digester-1.7-src.tar.gz:jakarta-commons-digester
mwringe:BADURL:commons-modeler-2.0-src.tar.gz:jakarta-commons-modeler
mwringe:BADURL:httpunit-1.6.2.zip:httpunit
mwringe:BADURL:nekohtml-0.9.5.tar.gz:nekohtml
nalin:BADURL:nss_db-2.2.tar.gz:nss_db
nalin:BADURL:nss_ldap-263.tar.gz:nss_ldap
nalin:BADURL:pam_ldap-184.tar.gz:nss_ldap
nbecker:BADSOURCE:Cython-0.10.tar.gz:Cython
nbecker:BADURL:igraph-0.5.tar.gz:igraph
nbecker:BADURL:unuran-1.2.4p1.tar.gz:unuran
nhorman:BADURL:cscope-15.6.tar.gz:cscope
nigelj:BADURL:RSQLite_0.7-0.tar.gz:R-RSQLite
nixaff4:BADURL:knotify-plugin_0.1.tar.gz:pidgin-knotify
nmurray:BADURL:giflib-4.1.3.tar.bz2:giflib
nomis80:BADURL:camstream-0.26.3.tar.gz:camstream
notting:BADURL:aqbanking-3.7.2.tar.gz:aqbanking
notting:BADURL:gwenhywfar-3.4.1.tar.gz:gwenhywfar
notting:BADURL:initscripts-8.85.tar.bz2:initscripts
nphilipp:BADURL:python-slip-0.1.15.tar.bz2:python-slip
nsantos:BADURL:gnu.regexp-1.1.4.tar.gz:gnu-regexp
olea:BADURL:mbpurple-0.2.0.tar.gz:purple-microblog
olea:BADURL:pidgin-facebookchat-source-1.38.tar.bz2:purple-facebookchat
ondrejj:BADURL:sagator-1.1.1-0.beta1.tar.bz2:sagator
orion:BADSOURCE:systemfit_1.0-7.tar.gz:R-systemfit
orion:BADURL:numarray-1.5.2.tar.gz:python-numarray
orphan:BADSOURCE:gst-plugins-0.8.12.tar.bz2:gstreamer08-plugins
orphan:BADSOURCE:kbiof-0.3.tar.gz:kbiof
orphan:BADURL:gaim-galago-0.5.1.tar.bz2:purple-galago
orphan:BADURL:gnome-blog-0.9.1.tar.bz2:gnome-blog
orphan:BADURL:gnome-yum-0.1.4.tar.gz:gnome-yum
orphan:BADURL:kbackup-0.5.4.tar.bz2:kbackup
orphan:BADURL:moomps-5.8.tar.bz2:moomps
orphan:BADURL:new-1.3.9.tar.gz:new
orphan:BADURL:pam-script-0.1.7.tar.gz:pam_script
orphan:BADURL:pam_usb-0.4.0.tar.gz:pam_usb
orphan:BADURL:pekwm-0.1.5.tar.bz2:pekwm
orphan:BADURL:TPG-3.1.2.tar.gz:python-tpg
orphan:BADURL:tvn24_0.2.8-1.tar.gz:gnome-applet-tvn24
otaylor:BADURL:mugshot-1.2.2.tar.gz:mugshot
ovasik:BADSOURCE:docbook-slides-3.4.0.tar.gz:docbook-slides
ovasik:BADURL:coreutils-7.0.tar.lzma:coreutils
ovasik:BADURL:OpenSP-1.5.2.tar.gz:opensp
ovasik:BADURL:passivetex-1.25.zip:passivetex
ovasik:BADURL:wvstreams-4.4.1.tar.gz:libwvstreams
ovasik:BADURL:xmltex-1.9.tar.gz:xmltex
pali:BADURL:cherokee-0.10.0.tar.gz:cherokee
pcheung:BAD_CVS_SOURCE:ant-1.7.1.pom:ant
pcheung:BAD_CVS_SOURCE:xmlunit-1.0.pom:xmlunit
pertusus:BADURL:tex4ht-1.0.2008_09_16_1413.tar.gz:tetex-tex4ht
peter:BAD_CVS_SOURCE:encfs-1.5-2.tgz.asc:fuse-encfs
peter:BAD_CVS_SOURCE:rlog-1.4.tar.gz.asc:rlog
peter:BADURL:encfs-1.5-2.tgz:fuse-encfs
peter:BADURL:rlog-1.4.tar.gz:rlog
peter:BADURL:stratagus-2.2.4-src.tar.gz:stratagus
petersen:BADURL:ddskk-12.2.0.tar.bz2:ddskk
petersen:BADURL:emacspeak-28.0.tar.bz2:emacspeak
petersen:BADURL:libhangul-0.0.8.tar.gz:libhangul
petersen:BADURL:scim-hangul-0.3.2.tar.gz:scim-hangul
pfj:BADSOURCE:db4o-6.1-mono.tar.gz:db4o
pfj:BADSOURCE:gDeskCal-1.01.tar.gz:gdeskcal
pfj:BADURL:CastPodder-5.0.tar.bz2:CastPodder
pfj:BADURL:gtksourceview2-sharp-89788.tar.bz2:gtksourceview2-sharp
pfj:BADURL:gtksourceview-sharp-2.0-0.12.tar.bz2:gtksourceview-sharp
pfj:BADURL:ikvm-0.22.tar.gz:ikvm
pfj:BADURL:mono-debugger-2.0.tar.bz2:mono-debugger
pfj:BADURL:monodoc-2.0.zip:monodoc
pfj:BADURL:pyOpenSSL-0.7.tar.gz:pyOpenSSL
pghmcfc:BADSOURCE:lat-1.2.3.tar.gz:lat
pghmcfc:BADURL:db.1.85.tar.gz:gnome-libs
pghmcfc:BADURL:GTorrentViewer-0.2b.tar.gz:gtorrentviewer
pghmcfc:BADURL:Mail-Mbox-MessageParser-1.5000.tar.gz:perl-Mail-Mbox-MessageParser
pgordon:BADSOURCE:curvylooks-0.3.gtp:gnome-theme-curvylooks
pgordon:BADURL:empathy-2.24.1.tar.bz2:empathy
pgordon:BADURL:labyrinth-0.4.0.tar.bz2:labyrinth
pgordon:BADURL:libtorrent-rasterbar-0.13.1.tar.gz:rb_libtorrent
phuang:BADSOURCE:scim-1.4.7.tar.gz:scim
phuang:BADURL:ibus-0.1.1.20081023.tar.gz:ibus
phuang:BADURL:ibus-anthy-0.1.1.20080912.tar.gz:ibus-anthy
phuang:BADURL:ibus-chewing-0.1.1.20081023.tar.gz:ibus-chewing
phuang:BADURL:ibus-hangul-0.1.1.20081023.tar.gz:ibus-hangul
phuang:BADURL:ibus-m17n-0.1.1.20081013.tar.gz:ibus-m17n
phuang:BADURL:ibus-pinyin-0.1.1.20081004.tar.gz:ibus-pinyin
phuang:BADURL:ibus-table-0.1.1.20081014.tar.gz:ibus-table
phuang:BADURL:pinyin-database-0.1.10.5.tar.bz2:scim-python
phuang:BADURL:pinyin-database-0.1.10.6.tar.bz2:ibus-pinyin
phuang:BADURL:scim-python-0.1.13rc1.tar.gz:scim-python
phuang:BADURL:xingma-cangjie5-0.1.10.1.tar.bz2:scim-python
phuang:BADURL:xingma-erbi-qingsong-0.1.10.1.tar.bz2:scim-python
phuang:BADURL:xingma-wubi86-0.1.10.1.tar.bz2:scim-python
phuang:BADURL:xingma-zhengma-0.1.10.1.tar.bz2:scim-python
pilcher:BADURL:wifi-radar-1.9.9.tar.bz2:wifi-radar
pingou:BADURL:affyio_1.10.0.tar.gz:R-affyio
pingou:BADURL:Biobase_2.2.0.tar.gz:R-Biobase
pingou:BADURL:guake-0.3.1.tar.gz:guake
pmachata:BADSOURCE:tbb21_20080605oss_src.tgz:tbb
pnemade:BADSOURCE:ne_NP_dict.zip:hunspell-ne
pwouters:BADURL:ldns-1.4.0.tar.gz:ldns
pwouters:BADURL:s3ssrc.zip:s3switch
pwouters:BADURL:unbound-1.1.0.tar.gz:unbound
qspencer:BADURL:atlas3_3.6.0-20.diff.gz:atlas
qspencer:BADURL:autotrace-0.31.1.tar.gz:autotrace
rajeeshknambiar:BADSOURCE:ooo-hunspell-ml-0.1.tar.bz2:hunspell-ml
rakesh:BADURL:bunny-0.93.tgz:bunny
rakesh:BADURL:coredumper-1.2.1.tar.gz:coredumper
rakesh:BADURL:ctemplate-0.91.tar.gz:ctemplate
rakesh:BADURL:fuse-zip-0.2.6.tar.gz:fuse-zip
rakesh:BADURL:gflags-0.9.tar.gz:gflags
rakesh:BADURL:pdf2djvu_0.4.13.tar.gz:pdf2djvu
rakesh:BADURL:txt2rss-01.tar.bz2:txt2rss
rakesh:BADURL:xmpphp-0.1beta-r50.tar.gz:php-xmpphp
rathann:BADURL:crm114-20080703-BlameVT.src.tar.gz:crm114
rathann:BADURL:libEMF-1.0.3.tar.gz:libEMF
rathann:BADURL:libnemesi-0.6.4-rc2.tar.bz2:libnemesi
rathann:BADURL:newsx-1.6.tar.gz:newsx
rathann:BADURL:tachyon20070319.tar.gz:tachyon
rbhalera:BADURL:ISO8859-2-bdf.tar.gz:fonts-ISO8859-2
rbhalera:BADURL:Madan.ttf:madan-fonts
rdieter:BADSOURCE:geomview-1.9.4.tar.bz2:geomview
rdieter:BADSOURCE:Macaulay2-1.1-src.tar.gz:Macaulay2
rdieter:BADURL:kdeplasma-addons-4.1.2.tar.bz2:kdeplasma-addons
rdieter:BADURL:kdetoys-4.1.2.tar.bz2:kdetoys
rdieter:BADURL:libofa-0.9.3.tar.gz:libofa
rdieter:BADURL:macref.pdf:maxima
rdieter:BADURL:mtextralic.htm:mathml-fonts
rdieter:BADURL:pinentry-0.7.4.tar.gz:pinentry
rdieter:BADURL:pinentry-0.7.4.tar.gz.sig:pinentry
rdieter:BADURL:PyKDE-3.16.1.tar.bz2:PyKDE
rdieter:BADURL:PyQt-x11-gpl-4.4.3.tar.gz:PyQt4
rdieter:BADURL:QScintilla-gpl-2.3.tar.gz:qscintilla
rezso:BADSOURCE:OpenLayers-2.7.tar.gz:openlayers
rezso:BADURL:fet-5.7.0.tar.bz2:fet
rezso:BADURL:geos-3.0.1.tar.bz2:geos
rezso:BADURL:mapnik_src-0.5.2.svn738.tar.gz:mapnik
rhughes:BADURL:DeviceKit-power-002.tar.gz:DeviceKit-power
rhughes:BADURL:hal-0.5.12-20081027git.tar.gz:hal
rishi:BADURL:freetalk-3.1.tar.gz:freetalk
rishi:BADURL:httrack-3.43-BETA-4.tar.gz:httrack
rishi:BADURL:isight-firmware-tools-1.0.2.tar.gz:isight-firmware-tools
rjones:BADURL:binutils-2.18.50-20080109-2-src.tar.gz:mingw32-binutils
rjones:BADURL:deriving-0.1.1a.tar.gz:ocaml-deriving
rjones:BADURL:extlib-1.5.1.tar.gz:ocaml-extlib
rjones:BADURL:ocaml-bitstring-2.0.0.tar.gz:ocaml-bitstring
rjones:BADURL:xmlrpc-light-0.6.tar.gz:ocaml-xmlrpc-light
rmeggins:BADSOURCE:mozldap-6.0.5.tar.gz:mozldap
rmeggins:BADURL:Makefile.PL.rpm:perl-Mozilla-LDAP
rmeggins:BADURL:perl-mozldap-1.5.2.tar.gz:perl-Mozilla-LDAP
rnorwood:BADSOURCE:olpc-netutils-0.4.tar.bz2:olpc-netutils
robert:BADSOURCE:sip-redirect-0.1.2.tar.gz:sip-redirect
robert:BADURL:boto-1.2a.tar.gz:python-boto
robert:BADURL:idn_1.2b.tar.gz:php-idn
robmv:BADSOURCE:dirvish-1.2.1.tgz:dirvish
robmv:BADURL:org.tmatesoft.svn_1.1.4.src.zip:svnkit
roland:BADURL:strace-4.5.18.tar.bz2:strace
rrakus:BADSOURCE:netkit-bootparamd-0.17.tar.gz:bootparamd
rrakus:BADURL:udftools-1.0.0b3.tar.gz:udftools
rrelyea:BADURL:ccid-1.3.8.tar.bz2:ccid
rrelyea:BADURL:pam_pkcs11-0.5.3.tar.gz:pam_pkcs11
rrelyea:BADURL:pcsc-lite-1.4.102.tar.bz2:pcsc-lite
rstrode:BADURL:GConf-2.24.0.tar.bz2:GConf2
rstrode:BADURL:gnome-games-2.25.1.tar.bz2:gnome-games
rstrode:BADURL:plymouth-0.6.0.tar.bz2:plymouth
ruben:BADSOURCE:pdns-2.9.21.1.tar.gz:pdns
rvinyard:BADSOURCE:IEEEtran.zip:tetex-IEEEtran
rvinyard:BADURL:3CCP.pdf:clips
rvinyard:BADURL:abstract.pdf:clips
rvinyard:BADURL:AllExamples.tar.Z:clips
rvinyard:BADURL:apg.pdf:clips
rvinyard:BADURL:arch5-1.pdf:clips
rvinyard:BADURL:bpg.pdf:clips
rvinyard:BADURL:clipssrc.tar.Z:clips
rvinyard:BADURL:DR0873.txt:clips
rvinyard:BADURL:FunctionContext.zip:clips
rvinyard:BADURL:ig.pdf:clips
rvinyard:BADURL:objrtmch.c:clips
rvinyard:BADURL:papyrus-0.7.1.tar.bz2:papyrus
rvinyard:BADURL:usrguide.pdf:clips
rvinyard:BADURL:x-prjct.tar.Z:clips
ryo:BADSOURCE:scim-skk-0.5.2.tar.gz:scim-skk
s4504kr:BAD_CVS_SOURCE:import-3ds-0.7.py:blender
s4504kr:BADSOURCE:open-cobol-1.1.tar.gz:open-cobol
s4504kr:BADURL:inadyn.v1.96.2.zip:inadyn
s4504kr:BADURL:stellarium_user_guide-0.9.1-1.pdf:stellarium
s4504kr:BADURL:suck-4.3.2.tar.gz:suck
salimma:BADSOURCE:Falcon-0.8.10.tar.gz:Falcon
salimma:BADSOURCE:gnome-keyring-sharp.tar.gz:gnome-keyring-sharp
salimma:BADURL:bti-005.tar.bz2:bti
salimma:BADURL:google-gadgets-for-linux-0.10.1.tar.gz:google-gadgets
salimma:BADURL:libipoddevice-0.5.3.tar.gz:libipoddevice
salimma:BADURL:waf-1.4.4.tar.bz2:waf
sandeen:BADURL:xfsdump_2.2.48-1.tar.gz:xfsdump
sandeen:BADURL:xfsprogs_2.10.1-1.tar.gz:xfsprogs
sbehera:BADURL:nabi-0.99.2.tar.gz:nabi
scop:BAD_CVS_SOURCE:ccache-2.4-md.patch:ccache
scop:BADURL:cd-discid_0.9.orig.tar.gz:cd-discid
sdake:BADURL:openais-0.91.tar.gz:openais
sergiopr:BADURL:cloudy_v07_02_01.tar.gz:cloudy
sergiopr:BADURL:cpl-4.1.0.tar.gz:cpl
sergiopr:BADURL:ds9.5.4.tar.gz:ds9
sergiopr:BADURL:esorex-3.6.8.tar.gz:esorex
sergiopr:BADURL:LaTeXPlugin-0.1.3.2.tar.gz:gedit-latex-plugin
sergiopr:BADURL:wcstools-3.7.0.tar.gz:wcstools
sgrubb:BADURL:prewikka-0.9.14.tar.gz:prewikka
sharkcz:BADURL:mm3d-1.3.7.tar.gz:mm3d
sharkcz:BADURL:openhpi-subagent-2.3.4.tar.gz:openhpi-subagent
sharkcz:BADURL:tinyerp-client-4.2.3.3.tar.gz:tinyerp
sharkcz:BADURL:tinyerp-server-4.2.3.3.tar.gz:tinyerp
sheltren:BADURL:cfengine-2.2.8.tar.gz:cfengine
sheltren:BADURL:fortune-hitchhiker.tgz:fortune-mod
sheltren:BADURL:fortune-mod-1.99.1.tar.gz:fortune-mod
sheltren:BADURL:fortune-tao.tar.gz:fortune-mod
sheltren:BADURL:osfortune.tar.gz:fortune-mod
simo:BADURL:rsync-3.0.4.tar.gz:rsync
simo:BADURL:rsync-patches-3.0.4.tar.gz:rsync
simo:BADURL:samba-3.2.4.tar.gz:samba
sindrepb:BADURL:gnome-do-0.6.1.0.tar.gz:gnome-do
sindrepb:BADURL:muine-0.8.9.tar.gz:muine
sindrepb:BADURL:nikto-1.36.tar.bz2:nikto
sindrepb:BADURL:pychess-0.8.2.tar.gz:pychess
sindrepb:BADURL:scratchpad-0.3.0.tar.bz2:scratchpad
smccann:BADSOURCE:shapelib-1.2.10.tar.gz:shapelib
smilner:BADURL:Pygments-0.11.1.tar.gz:python-pygments
snecker:BADURL:jokosher-20081012svn.tar.gz:jokosher
snecker:BADURL:libflaim-4.9.1052.tar.gz:libflaim
splinux:BADURL:libgtksourceviewmm-0.3.1.tar.bz2:libgtksourceviewmm
spot:BADSOURCE:daa2iso.zip:daa2iso
spot:BADSOURCE:lout-3.37.tar.gz:lout
spot:BADSOURCE:ql2300_fw.bin:ql23xx-firmware
spot:BADSOURCE:ql2322_fw.bin:ql23xx-firmware
spot:BADSOURCE:ql2400_fw.bin:ql2400-firmware
spot:BADSOURCE:ql2500_fw.bin:ql2500-firmware
spot:BADSOURCE:srecord-1.39.tar.gz:srecord
spot:BADURL:alsamixergui-0.9.0rc1-2.tar.gz:alsamixergui
spot:BADURL:amanith_03.tar.gz:amanith
spot:BADURL:Class-DBI-Loader-Relationship-1.3.tar.gz:perl-Class-DBI-Loader-Relationship
spot:BADURL:Class-DBI-Pg-0.09.tar.gz:perl-Class-DBI-Pg
spot:BADURL:Config-IniFiles-2.39.tar.gz:perl-Config-IniFiles
spot:BADURL:google-perftools-0.99.1.tar.gz:google-perftools
spot:BADURL:hdf5_1.6.7.tar.gz:R-hdf5
spot:BADURL:HTML-Tree-3.23.tar.gz:perl-HTML-Tree
spot:BADURL:HTTP-Body-0.9.tar.gz:perl-HTTP-Body
spot:BADURL:Ima-DBI-0.35.tar.gz:perl-Ima-DBI
spot:BADURL:IO-CaptureOutput-1.06.tar.gz:perl-IO-CaptureOutput
spot:BADURL:kscope-1.6.2.tar.gz:kscope
spot:BADURL:libgdamm-3.0.1.tar.bz2:libgdamm
spot:BADURL:libmcrypt-2.5.8.tar.gz:libmcrypt
spot:BADURL:MARC-Record-2.0.0.tar.gz:perl-MARC-Record
spot:BADURL:MIME-Types-1.23.tar.gz:perl-MIME-Types
spot:BADURL:pydot-1.0.2.tar.gz:pydot
spot:BADURL:QuantLib-0.9.0.tar.gz:QuantLib
spot:BADURL:rx-1.5.tar.bz2:librx
spot:BADURL:Scalar-Properties-0.13.tar.gz:perl-Scalar-Properties
spot:BADURL:ser2net-2.5.tar.gz:ser2net
spot:BADURL:SimGear-1.0.0.tar.gz:SimGear
spot:BADURL:Test-MockObject-1.08.tar.gz:perl-Test-MockObject
spot:BADURL:Tree-DAG_Node-1.06.tar.gz:perl-Tree-DAG_Node
spot:BADURL:UNIVERSAL-isa-0.06.tar.gz:perl-UNIVERSAL-isa
spot:BADURL:winpdb-1.4.0.tar.gz:winpdb
srini:BADURL:sblim-sfcc-2.1.0.tar.bz2:sblim-sfcc
srini:BADURL:wsmancli-2.1.0.tar.bz2:wsmancli
ssp:BADURL:libxkbfile-1.0.4.tar.bz2:libxkbfile
steve:BADURL:gl-117-1.3.2-src.tar.bz2:gl-117
steve:BADURL:sqlgrey-1.7.6.tar.bz2:sqlgrey
steve:BADURL:tuxpaint-0.9.20.tar.gz:tuxpaint
steve:BADURL:tuxpaint-stamps-2008.06.30.tar.gz:tuxpaint-stamps
steve:BADURL:tuxtype_w_fonts-1.5.17.tar.gz:tuxtype2
steved:BADURL:nfs.doc.tar.gz:nfs-utils
stingray:BADURL:pyflowtools-0.3.4.tar.gz:pyflowtools
svahl:BADURL:kcoloredit-2.0.0-kde4.1.2.tar.bz2:kcoloredit
svahl:BADURL:kgrab-0.1.1-kde4.1.2.tar.bz2:kgrab
svahl:BADURL:konq-plugins-4.1.2.tar.bz2:konq-plugins
svahl:BADURL:polyester-1.9.0.tar.gz:polyester
sxw:BADURL:kstart-3.11.tar.gz:kstart
sxw:BADURL:remctl-2.11.tar.gz:remctl
tagoh:BADSOURCE:anthy-9100e.tar.gz:anthy
tagoh:BADSOURCE:Canna37p3.tar.bz2:Canna
tagoh:BADSOURCE:mplus_bitmap_fonts-2.2.4.tar.gz:japanese-bitmap-fonts
tagoh:BADSOURCE:nkf-2.0.8b.tar.gz:nkf
tagoh:BADSOURCE:scim-anthy-1.2.6.tar.gz:scim-anthy
tagoh:BADURL:imsettings-0.105.1.tar.bz2:imsettings
tagoh:BADURL:k14-oldkanji.tar.gz:japanese-bitmap-fonts
tagoh:BADURL:libgcroots-0.2.1.tar.bz2:libgcroots
tagoh:BADURL:libgxim-0.3.1.tar.bz2:libgxim
tagoh:BADURL:mew-6.1.50.tar.gz:mew
tagoh:BADURL:sigscheme-0.8.3.tar.bz2:sigscheme
tagoh:BADURL:uim-1.5.3.tar.bz2:uim
tbzatek:BADSOURCE:tuxcmd-modules-0.6.50.tar.bz2:tuxcmd
tbzatek:BADURL:gnome-keyring-2.25.1.tar.bz2:gnome-keyring
terjeros:BADURL:bainonline-teamgit-6082d0a73cfedc6b38adbbf4b6cc98929f052a29.tar.gz:teamgit
terjeros:BADURL:logstalgia-0.9.1.tar.gz:logstalgia
terjeros:BADURL:tcpflow-0.21.tar.gz:tcpflow
tgl:BADSOURCE:pgtcl1.6.2.tar.gz:postgresql
tgl:BADSOURCE:pgtcldocs-20070115.zip:postgresql
tgl:BADURL:mysql-5.0.67.tar.gz:mysql
tgl:BADURL:mysql-connector-odbc-3.51.26r1127.tar.gz:mysql-connector-odbc
tgl:BADURL:pg_filedump-8.3.0.tar:rhdb-utils
tgl:BADURL:postgresql-8.3.5-US.pdf:postgresql
tgl:BADURL:psqlodbc-08.03.0200.tar.gz:postgresql-odbc
than:BAD_CVS_SOURCE:French.txt:wordtrans
than:BADSOURCE:css.tar.bz2:kdewebdev
than:BADSOURCE:javascript.tar.bz2:kdewebdev
than:BADSOURCE:lancelot-1.0.3.tar.bz2:kde-plasma-lancelot
than:BADURL:arts-1.5.10.tar.bz2:arts
than:BADURL:cyr-rfx-koi8-ub-1.1.bdfs.tar.bz2:fonts-KOI8-R
than:BADURL:efax-0.9a-001114.tar.gz:efax
than:BADURL:html.tar.bz2:kdewebdev
than:BADURL:isdn4k-utils-CVS-2006-07-20.tar.bz2:isdn4k-utils
than:BADURL:kdeaccessibility-4.1.2.tar.bz2:kdeaccessibility
than:BADURL:kdeadmin-4.1.2.tar.bz2:kdeadmin
than:BADURL:kdeartwork-4.1.2.tar.bz2:kdeartwork
than:BADURL:kdebase-3.5.10.tar.bz2:kdebase3
than:BADURL:kdebase-4.1.2.tar.bz2:kdebase
than:BADURL:kdebase-runtime-4.1.2.tar.bz2:kdebase-runtime
than:BADURL:kdebase-workspace-4.1.2.tar.bz2:kdebase-workspace
than:BADURL:kdebindings-4.1.2.tar.bz2:kdebindings
than:BADURL:kdeedu-4.1.2.tar.bz2:kdeedu
than:BADURL:kdegames-4.1.2.tar.bz2:kdegames
than:BADURL:kdegraphics-4.1.2.tar.bz2:kdegraphics
than:BADURL:kde-i18n-ar-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-bg-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-bn-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-ca-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-cs-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-da-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-de-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-el-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-en_GB-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-es-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-et-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-fi-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-fr-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-he-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-hi-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-hu-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-is-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-it-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-ja-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-ko-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-lt-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-nb-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-nl-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-nn-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-pa-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-pl-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-pt-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-pt_BR-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-ro-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-ru-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-sk-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-sl-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-sr-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-sv-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-ta-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-tr-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-uk-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-zh_CN-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-i18n-zh_TW-3.5.10.tar.bz2:kde-i18n
than:BADURL:kde-l10n-bg-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-ca-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-cs-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-csb-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-da-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-de-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-el-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-en_GB-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-eo-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-es-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-et-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-fi-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-fr-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-fy-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-ga-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-gl-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-hi-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-hu-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-it-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-ja-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-kk-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-km-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-ko-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-ku-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-lt-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-lv-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-mk-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-ml-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-nb-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-nds-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-nl-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-nn-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-pa-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-pl-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-pt-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-pt_BR-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-ru-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-sl-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-sr-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-sv-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-ta-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-th-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-tr-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-uk-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-wa-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-zh_CN-4.1.2.tar.bz2:kde-l10n
than:BADURL:kde-l10n-zh_TW-4.1.2.tar.bz2:kde-l10n
than:BADURL:kdemultimedia-4.1.2.tar.bz2:kdemultimedia
than:BADURL:kdenetwork-4.1.2.tar.bz2:kdenetwork
than:BADURL:kdepimlibs-4.1.2.tar.bz2:kdepimlibs
than:BADURL:kdesdk-4.1.2.tar.bz2:kdesdk
than:BADURL:kdevelop-3.5.3.tar.bz2:kdevelop
than:BADURL:kdewebdev-3.5.10.tar.bz2:kdewebdev
than:BADURL:ksi-XFree86-cyrillic-fonts.tar.bz2:fonts-KOI8-R
than:BADURL:mozplugger-1.10.1.tar.gz:mozplugger
than:BADURL:PyQt-x11-gpl-3.17.4.tar.gz:PyQt
than:BADURL:rp-pppoe-3.10.tar.gz:rp-pppoe
than:BADURL:sip-4.7.7.tar.gz:sip
than:BADURL:urw-fonts-1.0.7pre44.tar.bz2:urw-fonts
than:BADURL:wordtrans_1.1pre13.tar.gz:wordtrans
theinric:BADSOURCE:picviz-0.4.tar.gz:picviz
thias:BADSOURCE:ncftp-3.2.2-src.tar.bz2:ncftp
thias:BADSOURCE:Nevow-0.9.31.tar.gz:python-nevow
thias:BADSOURCE:pymetar-0.14.tar.gz:pymetar
thias:BADSOURCE:wxsvg-1.0.tar.bz2:wxsvg
thias:BADURL:csmash-0.6.6.tar.gz:csmash
thias:BADURL:cssutils-0.9.5.1.zip:python-cssutils
thias:BADURL:gTweakUI-0.4.0.tar.bz2:gtweakui
thias:BADURL:iwlwifi-3945-ucode-15.28.2.8.tgz:iwl3945-firmware
thias:BADURL:Louie-1.1.tar.gz:python-louie
thias:BADURL:postgrey-1.31.tar.gz:postgrey
thias:BADURL:tagpy-0.94.1.tar.gz:python-tag
thias:BADURL:xar-1.5.1.tar.gz:xar
thias:BADURL:zziplib-0.13.49.tar.bz2:zziplib
thm:BADURL:ikiwiki_2.64.tar.gz:ikiwiki
thm:BADURL:textile-2.0.11.tar.gz:python-textile
thomasvs:BADSOURCE:libannodex-0.7.3.tar.gz:libannodex
thomasvs:BADSOURCE:libcmml-0.9.1.tar.gz:libcmml
thomasvs:BADSOURCE:mod_annodex-ap20-0.2.2.tar.gz:mod_annodex
till:BADURL:aircrack-ng-1.0-20081109.tar.gz:aircrack-ng
timlau:BADURL:iniparse-0.2.3.tar.gz:python-iniparse
tjikkun:BADURL:tls1.6-src.tar.gz:tcltls
tmoertel:BADURL:Matrix_0.999375-14.tar.gz:R-Matrix
toshio:BADURL:pygpgme-0.1.tar.gz:pygpgme
toshio:BADURL:PyProtocols-1.0a0dev-r2302.zip:python-protocols
turki:BADURL:libgsasl-0.2.27.tar.gz:libgsasl
tuxbrewr:BADURL:powerman-2.2.tar.bz2:powerman
twaugh:BADURL:cups-1.4b1-source.tar.bz2:cups
twaugh:BADURL:foomatic-db-3.0-20080904.tar.gz:foomatic
twaugh:BADURL:foomatic-db-engine-3.0-20080904.tar.gz:foomatic
twaugh:BADURL:foomatic-db-hpijs-20080904.tar.gz:foomatic
twaugh:BADURL:foomatic-filters-3.0-20080904.tar.gz:foomatic
twaugh:BADURL:libieee1284-0.2.11.tar.bz2:libieee1284
twaugh:BADURL:pnm2ppa-1.04.tar.gz:pnm2ppa
twaugh:BADURL:ppa-0.8.6.tar.gz:pnm2ppa
varekova:BADURL:acct-6.3.2.tar.gz:psacct
varekova:BADURL:gzip-1.3.12.tar.gz:gzip
varekova:BADURL:manpages-ru-0.7.tar.gz:man-pages-ru
varekova:BADURL:man-PL24-10-2005.tar.gz:man-pages-pl
varekova:BADURL:unzip552.tar.gz:unzip
varekova:BADURL:zcrypt29.tar.gz:zip
varekova:BADURL:zip231.tar.gz:zip
vcrhonek:BADSOURCE:expect-5.43.0.tar.gz:expect
vcrhonek:BADURL:ncpfs-2.2.6.tar.gz:ncpfs
vcrhonek:BADURL:pegasus-2.7.2.tar.gz:tog-pegasus
vcrhonek:BADURL:pychecker-0.8.17.tar.gz:pychecker
veillard:BADURL:ekiga-3.0.1.tar.bz2:ekiga
veillard:BADURL:libxml2-2.7.2.tar.gz:libxml2
vlg:BADURL:granule-1.4.0.tar.gz:granule
walters:BADURL:desktop-data-model-1.2.5.tar.gz:desktop-data-model
walters:BADURL:hippo-canvas-0.3.0.tar.gz:hippo-canvas
wtogami:BADURL:IO-Socket-INET6-2.54.tar.gz:perl-IO-Socket-INET6
wtogami:BADURL:mkelfImage-2.7.tar.gz:mkelfimage
wwoods:BADURL:PyBluez-0.15.tar.gz:pybluez
xgl-maint:BADURL:dri2proto-1.99.1.tar.bz2:xorg-x11-proto-devel
xris:BADURL:orpie-1.5.1.tar.gz:orpie
xulchris:BADURL:Smarty-2.6.20.tar.gz:php-Smarty
zkota:BADURL:bazaar_1.4.2.tar.gz:bazaar
zkota:BADURL:bazaar-doc_1.4.tar.gz:bazaar
zprikryl:BADURL:eject-2.1.5.tar.gz:eject
zprikryl:BADURL:vorbis-tools-1.2.0.tar.gz:vorbis-tools
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081119/458a7ce3/attachment.sig>

From ianweller at gmail.com  Thu Nov 20 00:22:37 2008
From: ianweller at gmail.com (Ian Weller)
Date: Wed, 19 Nov 2008 18:22:37 -0600
Subject: source file audit - 2008-11-14
In-Reply-To: <20081119170909.29694973@ohm.scrye.com>
References: <20081119170909.29694973@ohm.scrye.com>
Message-ID: <20081120002237.GA7640@gmail.com>

On Wed, Nov 19, 2008 at 05:09:09PM -0700, Kevin Fenzi wrote:
> ianweller:BADURL:flam3-2.7.16.tar.gz:flam3
404 because of recent update.

> ianweller:BADURL:qosmic-1.4.2.tar.bz2:qosmic
This works just fine for me (spectool -g straight from cvs).

Thought I'd just report that.

-- 
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/20081119/b1c69a5d/attachment.sig>

From loganjerry at gmail.com  Thu Nov 20 00:37:43 2008
From: loganjerry at gmail.com (Jerry James)
Date: Wed, 19 Nov 2008 17:37:43 -0700
Subject: source file audit - 2008-11-14
In-Reply-To: <20081119170909.29694973@ohm.scrye.com>
References: <20081119170909.29694973@ohm.scrye.com>
Message-ID: <870180fe0811191637q372240f6w893781e4b0d7fce5@mail.gmail.com>

On 2008/11/19 Kevin Fenzi <kevin at scrye.com> wrote:
> jjames:BADURL:check-0.9.5.tar.gz:check

Sure enough, I'm getting an HTTP 403 on this.  Will investigate.

> jjames:BADURL:latexmk-401.zip:latexmk

This one works for me.  I tried it just now.
-- 
Jerry James
http://loganjerry.googlepages.com/



From konrad at tylerc.org  Thu Nov 20 00:46:18 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Wed, 19 Nov 2008 16:46:18 -0800
Subject: source file audit - 2008-11-14
In-Reply-To: <20081119170909.29694973@ohm.scrye.com>
References: <20081119170909.29694973@ohm.scrye.com>
Message-ID: <200811191646.18367.konrad@tylerc.org>

On Wednesday 19 November 2008 04:09:09 pm Kevin Fenzi wrote:
> konradm:BADSOURCE:jruby-src-1.1.3.tar.gz:jruby
> konradm:BADURL:jvyamlb-src-0.2.2.tar.gz:jvyamlb
> konradm:BADURL:sympy-0.6.2.tar.gz:sympy

Jruby changed their 1.1.3 tarball without a new release; I'm more concerned 
about going to the new version (1.1.4 and soon 1.1.5).

Jvyamlb's Source0 works fine here, I don't know why your script seems broken.

Sympy's Source0 works here as well. Maybe googlecode (hoster of both jvyamlb 
and sympy) is blocking your ip after you've fetched lots of files from them? 
(Thus increasing the number of false source file audit results.)

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




From poelstra at redhat.com  Thu Nov 20 01:18:15 2008
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 19 Nov 2008 17:18:15 -0800
Subject: Fedora Release Engineering Meeting Recap 2008-11-17 
Message-ID: <4924BAD7.4010206@redhat.com>

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

Please make corrections and clarifications to the wiki page.


== Summary ==
* Discussion about upcoming GA and blocker bugs

== IRC Transcript ==



From bpepple at fedoraproject.org  Thu Nov 20 01:33:55 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 19 Nov 2008 20:33:55 -0500
Subject: FESCo Meeting Summary for 2008-11-19
Message-ID: <1227144835.3187.9.camel@kennedy>

=== FESCo Members Present ===
* Brian Pepple          (bpepple)
* Jarod Wilson          (j-rod)
* Bill Nottingham       (notting)
* Jon Stanley           (jds2001)
* Karsten Hopp          (kick_)
* Kevin Fenzi           (nirik)
* Josh Boyer            (jwb)
* David Woodhouse       (dwmw2)
* Dennis Gilmore        (dgilmore)

== Summary ==
=== F11 Schedule ===
      * FESCo approved the schedule proposed by Release-Engineering
        after a long discussion.
        https://www.redhat.com/archives/fedora-advisory-board/2008-November/msg00037.html

=== Features ===
      * FESCo approved the following features for F11:
              * https://fedoraproject.org/wiki/Features/DeviceKit
              * https://fedoraproject.org/wiki/Features/VolumeControl
              * https://fedoraproject.org/wiki/Features/Windows_cross_compiler
                      * This feature is dependent on a significant
                        number of packages that needs to be reviewed, so
                        FESCo will organize some package review days for
                        it, but if folks want to help out beforehand.
                        Here is a list of packages currently ready to be
                        reviewed:
                        https://bugzilla.redhat.com/buglist.cgi?quicksearch=mingw32
              * https://fedoraproject.org/wiki/Features/Presto
              * https://fedoraproject.org/wiki/Features/Multiseat
      * FESCo (with some input from the QA lead) refined the
        requirements for the Feature page.  It requires a fleshed-out
        Scope section by Alpha, and the Test plan section to be
        completed by Feature Freeze.  If those sections are not
        completed by those deadlines, a feature can be dropped.

=== Webcollage displaying inappropriate material ===
      * FESCo discussed webcollage showing pornographic images.  kick_
        will verify that webcollage has been fixed in our stable
        branches. https://bugzilla.redhat.com/show_bug.cgi?id=472061

=== Fedora representative to LSB ===
      * bpepple will contact the Server SIG to see if they were
        interested in taking up the offer from Russ Herrold.
        https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00763.html

=== FESCo Meeting on Nov. 26 ===
      * FESCo chose not to cancel the November 26th meeting, since the
        majority of FESCo would be available.

IRC log can be found at:
http://bpepple.fedorapeople.org/fesco/FESCo-2008-11-19.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/20081119/62b285b6/attachment.sig>

From a.badger at gmail.com  Thu Nov 20 01:55:10 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 19 Nov 2008 17:55:10 -0800
Subject: source file audit - 2008-11-14
In-Reply-To: <20081119170909.29694973@ohm.scrye.com>
References: <20081119170909.29694973@ohm.scrye.com>
Message-ID: <4924C37E.9090604@gmail.com>

Kevin Fenzi wrote:
> Here's attached another run of my sources/patches url checker. 
> Sorry for the delay in re-running this. 
> 
> Hopefully I will start running it again at the first of each month. 
> 
> - There are 912 lines in this run. Up from 662 last run.
> This is a pretty sad increase. ;( 
> 
> toshio:BADURL:pygpgme-0.1.tar.gz:pygpgme

This one works.  It's hosted on pypi.  If they start blocking IP
addresses that would really suck for us.

> toshio:BADURL:PyProtocols-1.0a0dev-r2302.zip:python-protocols

Fixed.

-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/20081119/c50fbc8b/attachment.sig>

From emmanuel.seyman at club-internet.fr  Thu Nov 20 02:29:43 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Thu, 20 Nov 2008 03:29:43 +0100
Subject: My roadmap for a better Fedora
In-Reply-To: <604aa7910811191426x7a59c984x3e0721fa69ae7887@mail.gmail.com>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>
	<20081119205950.GA4961@nostromo.devel.redhat.com>
	<adf480660811191323i552f933dy156a8416e22561ad@mail.gmail.com>
	<20081119221721.GH26527@redhat.com>
	<604aa7910811191426x7a59c984x3e0721fa69ae7887@mail.gmail.com>
Message-ID: <20081120022943.GA3280@orient.maison.lan>

* Jeff Spaleta [20/11/2008 02:30] :
>
> Is the upstream automated kerneloops stuff a counter example
> methodology? Or does that only work because they get sooooooo many
> more crash reports that the statistics become a useful way to sort?

Quote the kerneloops web site :

"kerneloops.org is a website that tries to help the developers of the
 Linux kernel by collecting so-called oopses, which are the crash
 signatures of the Linux kernel. The collected oopses are processed
 statistically to present information for the kernel developers, such
 as ..."

Emmanuel



From ianweller at gmail.com  Thu Nov 20 02:46:44 2008
From: ianweller at gmail.com (Ian Weller)
Date: Wed, 19 Nov 2008 20:46:44 -0600
Subject: source file audit - 2008-11-14
In-Reply-To: <4924C37E.9090604@gmail.com>
References: <20081119170909.29694973@ohm.scrye.com>
	<4924C37E.9090604@gmail.com>
Message-ID: <20081120024644.GA13652@gmail.com>

On Wed, Nov 19, 2008 at 05:55:10PM -0800, Toshio Kuratomi wrote:
> Kevin Fenzi wrote:
> > toshio:BADURL:pygpgme-0.1.tar.gz:pygpgme
> 
> This one works.  It's hosted on pypi.  If they start blocking IP
> addresses that would really suck for us.
> 
For the record, I have a couple of pypi packages that worked fine.

-- 
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/20081119/a92f4e3f/attachment.sig>

From rc040203 at freenet.de  Thu Nov 20 03:33:30 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 20 Nov 2008 04:33:30 +0100
Subject: My roadmap for a better Fedora
In-Reply-To: <604aa7910811191107u4dc41d6eubdc634e14174ede8@mail.gmail.com>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<604aa7910811191107u4dc41d6eubdc634e14174ede8@mail.gmail.com>
Message-ID: <1227152010.3752.767.camel@beck.corsepiu.local>

On Wed, 2008-11-19 at 10:07 -0900, Jeff Spaleta wrote:
> 2008/11/19 Callum Lerwick <seg at haxxed.com>:
> > 1) Make it easy to report bugs. Bugzilla is complex, slow, and
> > inscrutable. We need to put a simpler layer on top of it. Reporting a
> > bug should require just a few clicks. It should automatically include
> > all the information needed for the bug report, the distro version,
> > package version, arch, and things such as how the Xorg team demands your
> > xorg.conf and Xorg.0.log. Make finding dupes easier. Collect stack
> > traces system wide and enter them in a database, which bugzilla can
> > reference and from which bugzilla bugs can be derived. A system wide
> > kerneloops. (I know this has been talked about, what's the status?)
> 
> Maybe you can help do what's necessary to get apport integrated into
> our infrastructure.
> http://fedoraproject.org/wiki/Releases/FeatureApport
> >
> > 2) Make it simple to roll back to a known good state. We need a "system
> > restore". I know what you're thinking, but our vastly superior,
> > centralized, system-wide package management (and lack of a whole
> > seperate "system registry" namespace) allows us to make this actually
> > work. We need per-package rollback. Period.
> 
> Let me point out that rollback itself would require testing.
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).

> Obsoletes, triggers, (un)post/pre scripts, config file handling... all
> this rpm functionality complicates how successful rollbacks are to get
> you back to a restored system state. How are we going to test if a
> rollback works before you ask people to perform the rollback?
This problem is not restricted to rpm. It's a general package installer
problem. IMO, the installer is the wrong layer of addressing this issue.

Ralf




From sundaram at fedoraproject.org  Thu Nov 20 03:47:24 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 20 Nov 2008 09:17:24 +0530
Subject: starting Fedora Server SIG
In-Reply-To: <49247AA8.6030506@gmail.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>	<1226593460.13077.91.camel@aglarond.local>	<20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>	<20081113223242.GB4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>	<1226678932.636.40.camel@aglarond.local>	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>	<1226686948.13086.44.camel@aglarond.local>	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>	<1226700116.13086.116.camel@aglarond.local>	<491FBA0E.2070003@gmail.com>	<1227043592.4687.9.camel@firewall.xsintricity.com>	<49234139.1050400@gmail.com>	<1227057520.4687.45.camel@firewall.xsintricity.com>	<4923836B.1090309@gmail.com>	<1227110198.4687.108.camel@firewall.xsintricity.com>	<492467D6.7050803@gmail.com>	<1227124266.28543.296.camel@luminos.localdomain>
	<49247AA8.6030506@gmail.com>
Message-ID: <4924DDCC.4090603@fedoraproject.org>

Les Mikesell wrote:
> Jesse Keating wrote:
>> On Wed, 2008-11-19 at 13:24 -0600, Les Mikesell wrote:
>>> Agreed, but when the kernel hardware detection order was predictable, 
>>> this was simple.  Now it isn't.
>>
>> When was it predictable?  Even in the 2.4 era, we'd get one chassis
>> barebones from a vender like supermicro and the nic order would be one
>> way, then next month we'd order the same chassis barebones and the nics
>> would be picked up in a different order.  Even more fun is when they'd
>> change with a kernel update, so that the kernel we installed with had
>> one order, and the kernel we updated to and rebooted to had it in a
>> different order.
> 
> I'm pretty sure I cloned Centos 3.x across at least 50 IBM 336's with 
> the NICs always being chosen in the same order. 

That is just being lucky. Even in 2.4 kernel the order wasn't always 
predictable. It changed and there was a post from Linus in LKML about 
considering making it deliberately random to avoid any misconceptions 
that it can always be predictable. It includes details on why it isn't 
as well. I am sure you can find good references.

Rahul



From jamundso at gmail.com  Thu Nov 20 04:10:53 2008
From: jamundso at gmail.com (Jerry Amundson)
Date: Wed, 19 Nov 2008 22:10:53 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <4924DDCC.4090603@fedoraproject.org>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<1227043592.4687.9.camel@firewall.xsintricity.com>
	<49234139.1050400@gmail.com>
	<1227057520.4687.45.camel@firewall.xsintricity.com>
	<4923836B.1090309@gmail.com>
	<1227110198.4687.108.camel@firewall.xsintricity.com>
	<492467D6.7050803@gmail.com>
	<1227124266.28543.296.camel@luminos.localdomain>
	<49247AA8.6030506@gmail.com> <4924DDCC.4090603@fedoraproject.org>
Message-ID: <6d06ce20811192010s73f27534n761f2f553186db1b@mail.gmail.com>

On Wed, Nov 19, 2008 at 9:47 PM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> Les Mikesell wrote:
>>
>> Jesse Keating wrote:
>>>
>>> On Wed, 2008-11-19 at 13:24 -0600, Les Mikesell wrote:
>>>>
>>>> Agreed, but when the kernel hardware detection order was predictable,
>>>> this was simple.  Now it isn't.
>>>
>>> When was it predictable?  Even in the 2.4 era, we'd get one chassis
>>> barebones from a vender like supermicro and the nic order would be one
>>> way, then next month we'd order the same chassis barebones and the nics
>>> would be picked up in a different order.  Even more fun is when they'd
>>> change with a kernel update, so that the kernel we installed with had
>>> one order, and the kernel we updated to and rebooted to had it in a
>>> different order.
>>
>> I'm pretty sure I cloned Centos 3.x across at least 50 IBM 336's with the
>> NICs always being chosen in the same order.
>
> That is just being lucky. Even in 2.4 kernel the order wasn't always
> predictable. It changed and there was a post from Linus in LKML about
> considering making it deliberately random to avoid any misconceptions that
> it can always be predictable. It includes details on why it isn't as well. I
> am sure you can find good references.

Black.
No kool-aid drinkers need reply.
The rest of us know your answer.

jerry

-- 
There's plenty of youth in America - it's time we find the "fountain of smart".



From orion at cora.nwra.com  Thu Nov 20 04:43:37 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Wed, 19 Nov 2008 21:43:37 -0700 (MST)
Subject: source file audit - 2008-11-14
In-Reply-To: <20081119170909.29694973@ohm.scrye.com>
References: <20081119170909.29694973@ohm.scrye.com>
Message-ID: <3216.71.208.51.222.1227156217.squirrel@www.cora.nwra.com>


On Wed, November 19, 2008 5:09 pm, Kevin Fenzi wrote:
> orion:BADSOURCE:systemfit_1.0-7.tar.gz:R-systemfit
> orion:BADURL:numarray-1.5.2.tar.gz:python-numarray

Fixed in cvs/devel.

-- 
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  Thu Nov 20 04:58:27 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Wed, 19 Nov 2008 21:58:27 -0700 (MST)
Subject: My roadmap for a better Fedora
In-Reply-To: <alpine.LFD.2.00.0811191648340.10340@localhost.localdomain>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>
	<9497e9990811191344s694d3a57w801e31a83908041a@mail.gmail.com>
	<alpine.LFD.2.00.0811191648340.10340@localhost.localdomain>
Message-ID: <3343.71.208.51.222.1227157107.squirrel@www.cora.nwra.com>


On Wed, November 19, 2008 2:49 pm, Seth Vidal wrote:
>
> If you know the package where you think the bug is you can use bugz:)
>
> http://bugz.fedoraproject.org/$name
>
> for example
> http://bugz.fedoraproject.org/yum/
>
>
> not a solution but it's a start.

I use ":<package> <text>" and "ALL :<package> <text>" (searches closed
bugs) in the search form at the top of the bugzilla page.

-- 
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 jkeating at redhat.com  Thu Nov 20 05:39:19 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 19 Nov 2008 21:39:19 -0800
Subject: requires(post) on coreutils
Message-ID: <1227159559.28543.644.camel@luminos.localdomain>

I just attempted to compose the Games spin for Fedora 10, and ran into a
number of packages that fail their %post scripts due to missing one
thing or another out of coreutils (such as ln, rm, file, etc..) and it
has me wondering what might have changed in recent time so that
coreutils wouldn't be installed earlier in the transaction.  This seems
like something that would have been noticed before, but maybe it's just
in the particular package set that the games spin has.

Either way, if anybody wants to look into this, that'd be good.

-- 
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/20081119/1fc88efe/attachment.sig>

From kevin at scrye.com  Thu Nov 20 05:43:42 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Wed, 19 Nov 2008 22:43:42 -0700
Subject: source file audit - 2008-11-14
In-Reply-To: <20081120002237.GA7640@gmail.com>
References: <20081119170909.29694973@ohm.scrye.com>
	<20081120002237.GA7640@gmail.com>
Message-ID: <20081119224342.0a647e15@ohm.scrye.com>

On Wed, 19 Nov 2008 18:22:37 -0600
ianweller at gmail.com (Ian Weller) wrote:

> On Wed, Nov 19, 2008 at 05:09:09PM -0700, Kevin Fenzi wrote:
> > ianweller:BADURL:flam3-2.7.16.tar.gz:flam3
> 404 because of recent update.
> 
> > ianweller:BADURL:qosmic-1.4.2.tar.bz2:qosmic
> This works just fine for me (spectool -g straight from cvs).
> 
> Thought I'd just report that.

Strange. 

I got: 

--11:54:44--  http://qosmic.googlecode.com/files/qosmic-1.4.2.tar.bz2
Resolving qosmic.googlecode.com... 74.125.47.82
Connecting to qosmic.googlecode.com|74.125.47.82|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
11:54:45 ERROR 404: Not Found.

when I ran the script... but now it's working. 
Perhaps a transitory issue with googlecode. ;( 

Sorry for the false positive. 

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/20081119/c9d0c90a/attachment.sig>

From kevin at scrye.com  Thu Nov 20 05:46:02 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Wed, 19 Nov 2008 22:46:02 -0700
Subject: source file audit - 2008-11-14
In-Reply-To: <870180fe0811191637q372240f6w893781e4b0d7fce5@mail.gmail.com>
References: <20081119170909.29694973@ohm.scrye.com>
	<870180fe0811191637q372240f6w893781e4b0d7fce5@mail.gmail.com>
Message-ID: <20081119224602.01d369a5@ohm.scrye.com>

On Wed, 19 Nov 2008 17:37:43 -0700
loganjerry at gmail.com ("Jerry James") wrote:

> On 2008/11/19 Kevin Fenzi <kevin at scrye.com> wrote:
> > jjames:BADURL:check-0.9.5.tar.gz:check
> 
> Sure enough, I'm getting an HTTP 403 on this.  Will investigate.
> 
> > jjames:BADURL:latexmk-401.zip:latexmk
> 
> This one works for me.  I tried it just now.

My script got: 

--20:43:04--  http://www.phys.psu.edu/~collins/software/latexmk-jcc/latexmk-401.zip
Connecting to www.phys.psu.edu|128.118.49.14|:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
20:43:05 ERROR 403: Forbidden.

Again, it seems to be working now. ;( 
Sorry for the false positive... 

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/20081119/13a77301/attachment.sig>

From kevin at scrye.com  Thu Nov 20 05:48:52 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Wed, 19 Nov 2008 22:48:52 -0700
Subject: source file audit - 2008-11-14
In-Reply-To: <200811191646.18367.konrad@tylerc.org>
References: <20081119170909.29694973@ohm.scrye.com>
	<200811191646.18367.konrad@tylerc.org>
Message-ID: <20081119224852.0790e6c8@ohm.scrye.com>

On Wed, 19 Nov 2008 16:46:18 -0800
konrad at tylerc.org (Conrad Meyer) wrote:

> On Wednesday 19 November 2008 04:09:09 pm Kevin Fenzi wrote:
> > konradm:BADSOURCE:jruby-src-1.1.3.tar.gz:jruby
> > konradm:BADURL:jvyamlb-src-0.2.2.tar.gz:jvyamlb
> > konradm:BADURL:sympy-0.6.2.tar.gz:sympy
> 
> Jruby changed their 1.1.3 tarball without a new release; I'm more
> concerned about going to the new version (1.1.4 and soon 1.1.5).

Yeah. ;( 
> 
> Jvyamlb's Source0 works fine here, I don't know why your script seems
> broken.

Looks like googlecode was broken when the script hit this package: 

--12:14:51--  http://jvyamlb.googlecode.com/files/jvyamlb-src-0.2.2.tar.gz
Resolving jvyamlb.googlecode.com... 74.125.47.82
Connecting to jvyamlb.googlecode.com|74.125.47.82|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
12:14:52 ERROR 404: Not Found.

Seems fine now. 

> Sympy's Source0 works here as well. Maybe googlecode (hoster of both
> jvyamlb and sympy) is blocking your ip after you've fetched lots of
> files from them? (Thus increasing the number of false source file
> audit results.)

--17:22:25--  http://sympy.googlecode.com/files/sympy-0.6.2.tar.gz
Resolving sympy.googlecode.com... 74.125.47.82
Connecting to sympy.googlecode.com|74.125.47.82|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
17:22:25 ERROR 404: Not Found.

Well, it seems like it was giving 404's for some time... 
It does seem working now... 

> Regards,

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/20081119/8c5366e5/attachment.sig>

From kevin at scrye.com  Thu Nov 20 05:53:40 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Wed, 19 Nov 2008 22:53:40 -0700
Subject: source file audit - 2008-11-14
In-Reply-To: <4924C37E.9090604@gmail.com>
References: <20081119170909.29694973@ohm.scrye.com>
	<4924C37E.9090604@gmail.com>
Message-ID: <20081119225340.35d26afb@ohm.scrye.com>

On Wed, 19 Nov 2008 17:55:10 -0800
a.badger at gmail.com (Toshio Kuratomi) wrote:

> Kevin Fenzi wrote:
> > Here's attached another run of my sources/patches url checker. 
> > Sorry for the delay in re-running this. 
> > 
> > Hopefully I will start running it again at the first of each month. 
> > 
> > - There are 912 lines in this run. Up from 662 last run.
> > This is a pretty sad increase. ;( 
> > 
> > toshio:BADURL:pygpgme-0.1.tar.gz:pygpgme
> 
> This one works.  It's hosted on pypi.  If they start blocking IP
> addresses that would really suck for us.
> 

--10:38:57--  http://cheeseshop.python.org/packages/source/p/pygpgme/pygpgme-0.1.tar.gz
Resolving cheeseshop.python.org... 82.94.164.163
Connecting to cheeseshop.python.org|82.94.164.163|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
10:38:58 ERROR 404: Not Found.

Odd. Still doing this here. 
However, it's working fine with a wget... perhaps they are blocking the
agent that spectool -g uses? (which I am not sure what it reports). 

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/20081119/1756fad1/attachment.sig>

From ivazqueznet at gmail.com  Thu Nov 20 06:07:23 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Thu, 20 Nov 2008 01:07:23 -0500
Subject: source file audit - 2008-11-14
In-Reply-To: <20081119170909.29694973@ohm.scrye.com>
References: <20081119170909.29694973@ohm.scrye.com>
Message-ID: <1227161243.736.107.camel@ignacio.lan>

On Wed, 2008-11-19 at 17:09 -0700, Kevin Fenzi wrote:
> ivazquez:BADURL:purple-plugin_pack-2.4.0.tar.bz2:purple-plugin_pack

This is upstream being... something. I'll have to have a chat with them.

> ivazquez:BADURL:pywebkitgtk-1.0.1.tar.gz:pywebkitgtk

GoogleCode failure.

-- 
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/20081120/da0eb18a/attachment.sig>

From lesmikesell at gmail.com  Thu Nov 20 07:00:24 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 20 Nov 2008 01:00:24 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <1227126323.4687.178.camel@firewall.xsintricity.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>	<1226593460.13077.91.camel@aglarond.local>	<20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>	<20081113223242.GB4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>	<1226678932.636.40.camel@aglarond.local>	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>	<1226686948.13086.44.camel@aglarond.local>	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>	<1226700116.13086.116.camel@aglarond.local>	<491FBA0E.2070003@gmail.com>	<1227043592.4687.9.camel@firewall.xsintricity.com>	<49234139.1050400@gmail.com>	<1227057520.4687.45.camel@firewall.xsintricity.com>	<4923836B.1090309@gmail.com>	<1227110198.4687.108.camel@firewall.xsintricity.com>	<492467D6.7050803@gmail.com>
	<1227126323.4687.178.camel@firewall.xsintricity.com>
Message-ID: <49250B08.4080206@gmail.com>

Doug Ledford wrote:
> 
>> Errr, doesn't having to build server to run cobbler before you can 
>> install your real server make this a circular argument too?  Assuming I 
>> wanted a cobbler server at every remote location instead of shipping a 
>> pre-configured disk, how would I build it when it needs a cobbler server 
>> first?
> 
> No, this goes to the statement I made about some amount of setup cost
> that then is made up for in time savings in the future.

That's assuming that (a) the same  OS is reused in the future and (b) 
that the configuration technique doesn't change in the next rev.  I'm 
not making any commitments about (a) and you aren't giving me a warm 
fuzzy feeling about (b).

> And you only
> need one cobbler server.

Per location?

> You can install the image on a local machine
> and then ship the disc off (or if you can't, the concept of a local
> install box used to create disc images destined for a remote box that
> has a different mac address than the local install box wouldn't be a
> hard thing to add to cobbler, but since you haven't tried it and haven't
> brought up this need, it might not be in there yet).

Yes, I swap disks around, both locally and shipped elsewhere.  It is 
very inconvenient if the OS doesn't handle this gracefully.  And 
everyone needs to be able to restore a backup into a similar machine and 
come up working, something that presents approximately the same issues.


>> What tools don't involve the bootstrap problem - or are suitable for 
>> isolated remote servers?  Or maintaining a diverse set of OS's?
> 
> See above.  And cobbler has experimental support for SuSE and debian
> systems.  I'm sure the authors would correct any bugs you might run
> across in trying to use cobbler with those.  As for non-linux OSes,
> especially windows, cloning is probably the right call.

The larger set is currently windows but things are juggled around 
regularly to match the need for services.

>>   And it misses the point that I want to be able 
>> to shove a disk into chassis slots in a certain order and know what to 
>> call a partition on a particular physical disk regardless of where it 
>> was used before.
> 
> The unique filesystem labels I mentioned previously would achieve this
> result too.

With a lot of extra work to track the labels or discover them after the 
disk is moved.

>>   Plus,  the concepts are wildly different when you use 
>> md devices (and probably LVM's too but I've avoided those completely).
> 
> md devices are 100% discover by label, not by disk partition.  It scans
> the partitions and assembles based upon the labels therein.

Yes, the assembly portion is OK, assuming the disk wasn't cloned (i.e. 
the auto-created identifiers are unique when created), but at least 
older versions would get confused if you put disks that used to have the 
same md device name together in the same box.  I haven't tried that 
lately, but it is another inconvenience to have to avoid it.

>>> Actually, it has created less work for those people that utilized the
>>> tools that have been created to automate these things.  In your case,
>>> you already mention having to go in and hand edit network settings any
>>> time you clone a disk for a new machine.  That's not 0 work.
>> It is the minimal amount of work to get a correct setup.  The 
>> information needed to set the hostname and IP addresses has to be known 
>> and entered somewhere.
> 
> Yes, and it has to be redone every time you reimage a disk for that
> machine. 

As it must, because the information will probably be different for the 
new machine usage.  Or the new load on the disk may be a different OS.

 > On the other hand, when you enter the same information in
> cobbler, it can (optionally) enter the information in your dhcpd.conf or
> dnsmasq.conf, enter the information into your named zone file, and the
> machine is now permanently in the database so any time you reimage that
> same machine, it's all there ready to go.

How does that work in a mixed environment?  Some zones have windows DNS 
servers.  And does it understand split views of DNS?  Is the dns/dhcp 
config-writer a separate piece that can be used where cobbler doesn't 
build the machines?

>> Yes, I choose not to use them because they aren't appropriate for my 
>> usage.  They require a large amount of infrastructure work and only 
>> serve a specific OS - and probably only one or a few versions before you 
>> have to rebuild your infrastructure again.
> 
> Not true.

How many years/OS revs have you spanned with a single cobbler install?

>>> I don't know
>>> what to say to that.  If your going to do things the 1980s way and no
>>> other, then I'm not sure there's anything that anyone can do to make
>>> your life easier.
>> What can possibly be easier than typing 'dd'? 
> 
> Not having to type dd and then edit the results to get the right image?

Black magic hasn't worked out that well for me.

>>  I like unix-like systems 
>> because everything is a file or a stream of bytes and those don't take 
>> specialized tools to manage.
> 
> Nor do they fill in the right information for you.

Nothing is going to fill in the right information for me. Nothing can 
possibly already know the right information - or even the OS type I will 
want on the next disk.

>>>> I don't want dynamic devices on my servers.  I want to know exactly what 
>>>> they are and how they are named by the OS.  And I want a hundred of them 
>>>> with image-copied disks to all work the same way.
>>> But that's the fallacy of your argument, things *didn't* work that way,
>>> ever.  At least not under linux.  A device failure could cause sdb to
>>> become sda,
>> Ummm, OK - so are you implying that having a label on a partition on sda 
>> is useful in that circumstance?  Things that break just have to be 
>> replaced before they work again.
> 
> Except that this isn't the only situation.  You brought up the other one
> yourself in that putting more than one disk in a machine is a valid use
> case too.  As I pointed out, unique device labels eliminates the need to
> know for certain if the two disks you added went in as sdb and sdc or
> sdc and sdb.

But now you have to know every unique label instead.


>>   The way md devices work is sort-of ok, 
>> if you've handled the special case for booting, but they worked that way 
>> all along.   I'll agree that linux got most of the things it didn't copy 
>> from sysvr4 wrong in the first place including scsi drive naming, but 
>> changing 'detection order' naming to 'labels likely to be duplicates' 
>> isn't a good fix.
> 
> Unique labels is though.

Maybe - but it isn't a real solution.  You still have to deal with 
identifying the device before and during the labeling process.  If you 
can do that, you didn't really need the label.

>>> If you embraced some of these changes and worked *with* them
>>> instead of disabling them, then you might be able to loosen up some of
>>> that control and find that things still work like they are supposed to.
>> I have very little interest in converting to procedures that only work 
>> with one or a few versions of one distribution of one OS.
> 
> As I mentioned before, this isn't an accurate assessment of the support
> cobbler provides.

It's close enough in a mostly-windows environment.

>> Which tool besides clonezilla is good for cross platform work?  Are 
>> there even tools for a specific purpose like replacing a set of RHEL3 
>> servers with RHEL5 equivalents, maintaining the existing IP addresses on 
>> several interfaces each?  I eventually came up with something to scarf 
>> all the old ones from the running systems along with the corresponding 
>> mac addresses and included them in the clonezilla image with a script to 
>> patch things up but it wasn't pretty.
> 
> Yes.  Cobbler allows you to retarget a machine.  If a specific system
> was registered as a rhel3 system you can simply change it's parent
> profile to rhel5 and it will preserve all the ethernet information, etc.

But can it pick up the info from a machine it didn't create?  I didn't 
know about cobbler when rolling out the initial set of machines and 
probably wouldn't have trusted it even if it existed back then.


>> When something has been working for decades why would anyone want to 
>> change it?  And if it hasn't been working, why even look at a unix-like 
>> system in the first place?
> 
> Seriously?  It has to be 100% right the first time or move on?  Don't
> try to fix anything that's not right?

What a unix-like OS is supposed to do has been pretty well understood 
for decades.  Changing it isn't likely to be a fix.  Drivers and 
schedulers can probably always be improved, but those changes are mostly 
invisible.

>>  > And I really hate to say that, because I *want* Fedora to be all
>>> things to all people, but realistically it can't.  And in this
>>> particular conflict, it's a case of "we have real world problems from
>>> some users so we fix those problems with a better way of doing things"
>>> versus your case of "in my particular world, these problems don't exist,
>>> so don't change things around" and I just don't know how to rectify
>>> those two positions.
>> The way to do it is to have the kernel and the hardware use predictable 
>> but unfriendly conventions for the 'real' names that connect drivers to 
>> hardware
> 
> Done.  For eth0 on my machine lspci reports:
> 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
> 
> I can use that to go to /sys/bus/pci/devices/0000:04:00.0 and in there I
> find a directory call net and in that directory is a directory named to
> match the system name of the device (in my case eth0).  So no matter
> what device name this would have gotten, if I want the ethernet device
> in the particular pci slot this device occupies, going into the net
> directory gives me that name.  A similar convention can be used to get
> to any scsi device by pci device, then scsi controller, then host
> number, channel number, target number, lun.

OK, but is that documented to the point that scripts can be easily 
written to set up known hardware predictably without arbitrary 
naming/ordering done by the kernel or other places (like something 
renaming the eth?s later).

>> Will any of the changes involving friendly identifiers for partitions 
>> help me when I connect a new unformatted drive?  Will any help with 
>> mounts that are done over nfs or cifs?  What about iscsi?  If I have to 
>> identify a new raw disk myself to make the partitions and filesystems 
>> when adding it, why do you think I need different terminology to 
>> identify the partitions  after that step is done?
> 
> See above about putting two disks in a machine to do whatever to them,
> one of your use case scenarios.

What do you do for the cases where there is no hardware associated in 
the first place?  Iscsi disk connections would be an example. I don't 
see how having the kernel make up friendly names and guess at which name 
goes where will help you in this case.

>> Likewise with network interfaces: when what I want is some particular 
>> vlan from a trunk, will the changes help with that?
> 
> Going by mac address helps, certainly.  The eth names can flip flop all
> day long, but in the end you know that cable X  with vlan Z is plugged
> into the eth port with mac Y and you can set things up that way.

Vlan trunks have one associated NIC and hardware address but may carry 
many logically separate subnets.  I believe the kernel is capable of 
dealing with them, but I've never seen any detailed documentation on how 
to configure them so I've only used windows where they were needed.  I'd 
consider changes to be worthwhile if they make it easy to manage 
technology like vlan trunking and iscsi connections. Can cobbler set 
these up for you?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From ville.skytta at iki.fi  Thu Nov 20 07:01:20 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Thu, 20 Nov 2008 09:01:20 +0200
Subject: source file audit - 2008-11-14
In-Reply-To: <20081119225340.35d26afb@ohm.scrye.com>
References: <20081119170909.29694973@ohm.scrye.com>
	<4924C37E.9090604@gmail.com>
	<20081119225340.35d26afb@ohm.scrye.com>
Message-ID: <200811200901.21035.ville.skytta@iki.fi>

On Thursday 20 November 2008, Kevin Fenzi wrote:

> --10:38:57-- 
> http://cheeseshop.python.org/packages/source/p/pygpgme/pygpgme-0.1.tar.gz
> Resolving cheeseshop.python.org... 82.94.164.163
> Connecting to cheeseshop.python.org|82.94.164.163|:80... connected.
> HTTP request sent, awaiting response... 404 Not Found
> 10:38:58 ERROR 404: Not Found.
>
> Odd. Still doing this here.
> However, it's working fine with a wget... perhaps they are blocking the
> agent that spectool -g uses? (which I am not sure what it reports).

spectool -g uses plain wget, with configuration file /etc/fedora/wgetrc if it 
exists, otherwise usual system wget configs.



From mcepl at redhat.com  Thu Nov 20 08:13:57 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 20 Nov 2008 09:13:57 +0100
Subject: My roadmap for a better Fedora
References: <1227119906.7387.138.camel@localhost.localdomain>
	<adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>
	<9497e9990811191344s694d3a57w801e31a83908041a@mail.gmail.com>
	<alpine.LFD.2.00.0811191648340.10340@localhost.localdomain>
Message-ID: <5rifv5x6kn.ln2@ppp1053.in.ipex.cz>

On 2008-11-19, 21:49 GMT, Seth Vidal wrote:
> If you know the package where you think the bug is you can use 
> bugz:)
>
> http://bugz.fedoraproject.org/$name
>
> for example
> http://bugz.fedoraproject.org/yum/

Looks good! And especially that it has solution for
https://bugzilla.redhat.com/show_bug.cgi?id=213915

Thanks a lot for mentioning it,

Mat?j



From mcepl at redhat.com  Thu Nov 20 08:05:49 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 20 Nov 2008 09:05:49 +0100
Subject: reportbug? [Was: Re: My roadmap for a better Fedora]
References: <1227119906.7387.138.camel@localhost.localdomain>
Message-ID: <tbifv5x6kn.ln2@ppp1053.in.ipex.cz>

On 2008-11-19, 18:38 GMT, Callum Lerwick wrote:
> 1) Make it easy to report bugs. Bugzilla is complex, slow, and
> inscrutable. We need to put a simpler layer on top of it. Reporting a
> bug should require just a few clicks.

In my checkerd past is a long streak of using Debian. There 
I really liked reportbug script -- in my opinion, reporting bug 
should not include any clicks at all.

The beauty of such script is that it is able to collect all 
necessary information itself and it could theoretically carry 
some database of information needed for the particular component.  
Or it could do even some light pre-processing of the information?

Still it could do much more than whatever we can even dream about 
with the web form no matter how many clicks we require -- I am 
afraid that in case of web forms there is a direct relationship
between usefulness of information and number of clicks required.

Comments?

Mat?j



From mcepl at redhat.com  Thu Nov 20 08:23:14 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 20 Nov 2008 09:23:14 +0100
Subject: My roadmap for a better Fedora
References: <1227119906.7387.138.camel@localhost.localdomain>
	<adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>
	<20081119205950.GA4961@nostromo.devel.redhat.com>
	<adf480660811191323i552f933dy156a8416e22561ad@mail.gmail.com>
Message-ID: <icjfv5xcvq.ln2@ppp1053.in.ipex.cz>

On 2008-11-19, 21:23 GMT, Peter Lemenkov wrote:
> I think you misundestood something. If order to effectively 
> hunt issues, we definitely need HUGE number of bugreports 
> (remember Necrosoft's "Send crash dump" utility). That 
> definitely means one-way communication. I'm insisting - one-way 
> communication (e.g. user will send bugreport to 
> invisible-to-him blackhole, w/o answer, with some handy tool).

Pardon me for interrupting here, but in my humble opinion the 
previous paragraph is the very good example of the thing which we 
should avoid by any means legally permissible.

Such tool might be useful for crashes (because there it is highly 
probable that victim of crash files a bug and then you have 
choice between poorly filed bug or well filed one (and even there 
I would question the utility of such thing -- ask Gnome and 
Mozilla folks about their experience).

However, most bugs are not crashes (or at least in the world of 
Xorg and gecko where I spent my working hours) and there the 
communication with reporter is absolutely essential.

> Mediawiki will be easier to enduser in case of reporting bugs.  

Why?

If the reporters are not able to complete prefiled form, why do 
you think they would be doing any better to compose the text 
themselves?

Mat?j



From dan at danny.cz  Thu Nov 20 08:33:17 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Thu, 20 Nov 2008 09:33:17 +0100
Subject: My roadmap for a better Fedora
In-Reply-To: <5rifv5x6kn.ln2@ppp1053.in.ipex.cz>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>
	<9497e9990811191344s694d3a57w801e31a83908041a@mail.gmail.com>
	<alpine.LFD.2.00.0811191648340.10340@localhost.localdomain>
	<5rifv5x6kn.ln2@ppp1053.in.ipex.cz>
Message-ID: <1227169997.3635.9.camel@eagle.danny.cz>


Matej Cepl p??e v ?t 20. 11. 2008 v 09:13 +0100:
> On 2008-11-19, 21:49 GMT, Seth Vidal wrote:
> > If you know the package where you think the bug is you can use 
> > bugz:)
> >
> > http://bugz.fedoraproject.org/$name
> >
> > for example
> > http://bugz.fedoraproject.org/yum/
> 
> Looks good! And especially that it has solution for
> https://bugzilla.redhat.com/show_bug.cgi?id=213915
> 
> Thanks a lot for mentioning it,

I think it would useful to add a possibility to show closed bugs too,
e.g. via a checkbox "Include closed bugs".


		Dan




From thomas.moschny at gmail.com  Thu Nov 20 08:42:27 2008
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Thu, 20 Nov 2008 09:42:27 +0100
Subject: source file audit - 2008-11-14
In-Reply-To: <200811200901.21035.ville.skytta@iki.fi>
References: <20081119170909.29694973@ohm.scrye.com>
	<4924C37E.9090604@gmail.com> <20081119225340.35d26afb@ohm.scrye.com>
	<200811200901.21035.ville.skytta@iki.fi>
Message-ID: <a9d183c80811200042j1ee8807bne05e2fdb88961d32@mail.gmail.com>

2008/11/20 Ville Skytt? <ville.skytta at iki.fi>:
> spectool -g uses plain wget, with configuration file /etc/fedora/wgetrc if it
> exists, otherwise usual system wget configs.

spectool uses -N, which seems to cause 404 erros with googlecode:
% spectool -g -v -v python-textile.spec
Getting http://pytextile.googlecode.com/files/textile-2.0.11.tar.gz to .
--> wget -N --retr-symlinks -P .
http://pytextile.googlecode.com/files/textile-2.0.11.tar.gz
--2008-11-20 09:39:42--
http://pytextile.googlecode.com/files/textile-2.0.11.tar.gz
Resolving pytextile.googlecode.com... 74.125.47.82
Connecting to pytextile.googlecode.com|74.125.47.82|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2008-11-20 09:39:42 ERROR 404: Not Found.

Without -N, it works:

% LC_ALL=C wget http://pytextile.googlecode.com/files/textile-2.0.11.tar.gz
--2008-11-20 09:40:40--
http://pytextile.googlecode.com/files/textile-2.0.11.tar.gz
Resolving pytextile.googlecode.com... 74.125.47.82
Connecting to pytextile.googlecode.com|74.125.47.82|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 28727 (28K) [application/x-gzip]
Saving to: `textile-2.0.11.tar.gz'

100%[===========================================================================================>]
28,727       106K/s   in 0.3s

2008-11-20 09:40:41 (106 KB/s) - `textile-2.0.11.tar.gz' saved [28727/28727]

- Thomas

-- 
Thomas Moschny <thomas.moschny at gmail.com>



From mcepl at redhat.com  Thu Nov 20 08:37:04 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 20 Nov 2008 09:37:04 +0100
Subject: My roadmap for a better Fedora
References: <1227119906.7387.138.camel@localhost.localdomain>
	<adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>
	<20081119205950.GA4961@nostromo.devel.redhat.com>
	<adf480660811191323i552f933dy156a8416e22561ad@mail.gmail.com>
	<20081119221721.GH26527@redhat.com>
	<1dedbbfc0811191439h4a3d322aof6f30d79c0f0088f@mail.gmail.com>
Message-ID: <g6kfv5xt6r.ln2@ppp1053.in.ipex.cz>

On 2008-11-19, 22:39 GMT, David Nielsen wrote:
> One of the ideas with something like apport is that you can get 
> it to send you the log files you need and other related 
> information.

http://packages.debian.org/sid/reportbug and I am really sorry 
that we don't have anything like that (with some GUI-love 
possibly) available at Fedora.

> I would think something like this would at least reduce the 
> amount of time you spend asking for log files and other 
> information or at least compensate for the increased bug report 
> count.

Preach it, brother!

> when a bug is filed through apport, it gives you the top 
> reported bugs and the ones most similar to the one you are 
> reporting to avoid duplicates.

bugzilla.mozilla.org has something like that as well and even 
I found it quite difficult to use -- I would expect normal people 
when meeting a list of incomprehensible bug summaries to do 
exactly the same, what I would -- just skip it and hope that 
mozilla bug triagers will close possible duplicate better than 
myself.

Mat?j



From mcepl at redhat.com  Thu Nov 20 08:39:46 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 20 Nov 2008 09:39:46 +0100
Subject: My roadmap for a better Fedora
References: <1227119906.7387.138.camel@localhost.localdomain>
	<adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>
	<20081119205950.GA4961@nostromo.devel.redhat.com>
	<adf480660811191323i552f933dy156a8416e22561ad@mail.gmail.com>
	<20081119221311.GD31216@localhost.localdomain>
	<492495F5.10908@shmuelhome.mine.nu>
Message-ID: <ibkfv5xt6r.ln2@ppp1053.in.ipex.cz>

On 2008-11-19, 22:40 GMT, shmuel siegel wrote:
> Given a big enough triage staff, they can try to take these bug 
> reports and turn them into something useful to maintainers. 
> Without such a staff, I would agree with you.

Given that to the best of my knowledge I am the only paid bug 
triager around bugzilla.redhat.com and the bug zapping community 
is still rather developing than developed, consider solutions 
which don't require substantial human intervention only.

Mat?j



From mcepl at redhat.com  Thu Nov 20 08:57:49 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 20 Nov 2008 09:57:49 +0100
Subject: starting Fedora Server SIG
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>
	<1226686948.13086.44.camel@aglarond.local>
	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>
	<1226700116.13086.116.camel@aglarond.local>
	<491FBA0E.2070003@gmail.com>
	<1227043592.4687.9.camel@firewall.xsintricity.com>
	<49234139.1050400@gmail.com>
	<1227057520.4687.45.camel@firewall.xsintricity.com> <4923836B.109030
	9@gmail.com> <1227110198.4687.108.camel@firewall.xsintricity.com>
	<492467D6.7050803@gmail.com>
	<1227126323.4687.178.camel@firewall.xsintricity.com>
	<49250B08.4080206@gmail.com>
Message-ID: <ddlfv5x4hr.ln2@ppp1053.in.ipex.cz>

On 2008-11-20, 07:00 GMT, Les Mikesell wrote:
> Maybe - but it isn't a real solution.  You still have to deal 
> with identifying the device before and during the labeling 
> process.  If you can do that, you didn't really need the label.

Sorry, maybe I don't understand, but what's so difficult on the 
following?

tune2fs -l /dev/sda1 |awk '/UUID/ {print $3}'

Mat?j



From mcepl at redhat.com  Thu Nov 20 09:03:09 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 20 Nov 2008 10:03:09 +0100
Subject: Adobe Releases 64bit Flash Plugin for Linux
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>
	<20081117213116.GA25672@mokona.greysector.net>
	<4922C0D5.4070209@redhat.com> <gfv4jp$abq$1@ger.gmane.org>
	<1227036667.28543.7.camel@luminos.localdomain>
	<981da310811181555o3b4f0a7die4a4df37a5f7ecba@mail.gmail.com>
	<4923CE2A.9020707@redhat.com>
Message-ID: <dnlfv5x4hr.ln2@ppp1053.in.ipex.cz>

On 2008-11-19, 08:28 GMT, Martin Stransky wrote:
> Full browser-side emulation will be extremely complex and is 
> close to chrome model where one process holds one browser 
> page...

OK, I may be wrong then.

Mat?j



From mcepl at redhat.com  Thu Nov 20 09:01:41 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 20 Nov 2008 10:01:41 +0100
Subject: Adobe Releases 64bit Flash Plugin for Linux
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>
	<20081117213116.GA25672@mokona.greysector.net>
	<4922C0D5.4070209@redhat.com> <gfv4jp$abq$1@ger.gmane.org>
Message-ID: <lklfv5x4hr.ln2@ppp1053.in.ipex.cz>

On 2008-11-18, 19:21 GMT, Neal Becker wrote:
> Should nspluginwrapper be banned from wrapping this?  If so, 
> should this be included in flash-plugin.spec?

NO! We want to keep flash-plugin separate from the firefox 
process, moreover we confine nspluginwrapper (and thus 
flash-plugin as well) with SELinux in Fedora >=9, so we need to 
have nspluginwrapper around.

Mat?j



From dan at danny.cz  Thu Nov 20 09:20:12 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Thu, 20 Nov 2008 10:20:12 +0100
Subject: source file audit - 2008-11-14
In-Reply-To: <20081119170909.29694973@ohm.scrye.com>
References: <20081119170909.29694973@ohm.scrye.com>
Message-ID: <1227172812.3635.25.camel@eagle.danny.cz>

> sharkcz:BADURL:mm3d-1.3.7.tar.gz:mm3d

works for me

[dan at eagle devel]$ wget http://downloads.sourceforge.net/misfitmodel3d/mm3d-1.3.7.tar.gz
--2008-11-20 09:54:24--  http://downloads.sourceforge.net/misfitmodel3d/mm3d-1.3.7.tar.gz
P?ekl?d?m localhost? 127.0.0.1, ::1
Navazuje se spojen? s localhost|127.0.0.1|:3128? spojeno.
Proxy po?adavek odesl?n, program ?ek? na odpov??? 302 Moved Temporarily
P?esm?rov?no na: http://garr.dl.sourceforge.net/sourceforge/misfitmodel3d/mm3d-1.3.7.tar.gz [n?sleduji]
--2008-11-20 09:54:24--  http://garr.dl.sourceforge.net/sourceforge/misfitmodel3d/mm3d-1.3.7.tar.gz
Navazuje se spojen? s localhost|127.0.0.1|:3128? spojeno.
Proxy po?adavek odesl?n, program ?ek? na odpov??? 200 OK
D?lka: 1267651 (1,2M) [application/x-tar]
Ukl?d?m do: ?mm3d-1.3.7.tar.gz?.

100%[==========================================================>] 1 267 651    600K/s   za 2,1s    

2008-11-20 09:54:45 (600 KB/s) ? ?mm3d-1.3.7.tar.gz? ulo?eno [1267651/1267651]

but sometimes it is failing, must be sf.net issues

> sharkcz:BADURL:openhpi-subagent-2.3.4.tar.gz:openhpi-subagent

bug in sf.net url, will be updated

> sharkcz:BADURL:tinyerp-client-4.2.3.3.tar.gz:tinyerp
> sharkcz:BADURL:tinyerp-server-4.2.3.3.tar.gz:tinyerp

new version 4.2.3.4 was released and 4.2.3.3 moved to an archive
location


		Dan




From jreznik at redhat.com  Thu Nov 20 09:28:59 2008
From: jreznik at redhat.com (Jaroslav Reznik)
Date: Thu, 20 Nov 2008 04:28:59 -0500 (EST)
Subject: source file audit - 2008-11-14
In-Reply-To: <a9d183c80811200042j1ee8807bne05e2fdb88961d32@mail.gmail.com>
Message-ID: <4062121.1297871227173339126.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

----- "Thomas Moschny" <thomas.moschny at gmail.com> wrote:

> 2008/11/20 Ville Skytt? <ville.skytta at iki.fi>:
> > spectool -g uses plain wget, with configuration file
> /etc/fedora/wgetrc if it
> > exists, otherwise usual system wget configs.
> 
> spectool uses -N, which seems to cause 404 erros with googlecode:
> % spectool -g -v -v python-textile.spec
> Getting http://pytextile.googlecode.com/files/textile-2.0.11.tar.gz to
> .
> --> wget -N --retr-symlinks -P .
> http://pytextile.googlecode.com/files/textile-2.0.11.tar.gz
> --2008-11-20 09:39:42--
> http://pytextile.googlecode.com/files/textile-2.0.11.tar.gz
> Resolving pytextile.googlecode.com... 74.125.47.82
> Connecting to pytextile.googlecode.com|74.125.47.82|:80... connected.
> HTTP request sent, awaiting response... 404 Not Found
> 2008-11-20 09:39:42 ERROR 404: Not Found.
> 
> Without -N, it works:
> 
> % LC_ALL=C wget
> http://pytextile.googlecode.com/files/textile-2.0.11.tar.gz
> --2008-11-20 09:40:40--
> http://pytextile.googlecode.com/files/textile-2.0.11.tar.gz
> Resolving pytextile.googlecode.com... 74.125.47.82
> Connecting to pytextile.googlecode.com|74.125.47.82|:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 28727 (28K) [application/x-gzip]
> Saving to: `textile-2.0.11.tar.gz'
> 
> 100%[===========================================================================================>]
> 28,727       106K/s   in 0.3s
> 
> 2008-11-20 09:40:41 (106 KB/s) - `textile-2.0.11.tar.gz' saved
> [28727/28727]

Same for me - it's not working for googlecode downloads. Wget with -N param
sends HEAD instead GET - these two are same, but HEADs response are only 
headers - it's used for links validation etc... But looks is it misconfiguration
on server side?

But still thanks for check, arora's URL is OK, but pmpu's is really BAD,
download is no longer available :(

R.

> - Thomas
> 
> -- 
> Thomas Moschny <thomas.moschny at gmail.com>
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From caolanm at redhat.com  Thu Nov 20 09:47:53 2008
From: caolanm at redhat.com (=?ISO-8859-1?Q?Caol=E1n?= McNamara)
Date: Thu, 20 Nov 2008 09:47:53 +0000
Subject: source file audit - 2008-11-14
In-Reply-To: <20081119170909.29694973@ohm.scrye.com>
References: <20081119170909.29694973@ohm.scrye.com>
Message-ID: <1227174473.1241.2539.camel@vain.rhgalway>

On Wed, 2008-11-19 at 17:09 -0700, Kevin Fenzi wrote:

> caolanm:BADSOURCE:writer2latex0502.zip:writer2latex
> caolanm:BADSOURCE:icu4c-4_0-src.tgz:icu
> caolanm:BADSOURCE:myspell-af_ZA-20060117.zip:hunspell-af
> caolanm:BADSOURCE:myspell-nr_ZA-20060120.zip:hunspell-nr

With these ones upstream repacked the sources (bah), so it's great
to get the notification that they changed.

> caolanm:BADSOURCE:OOo-Thesaurus2-sk_SK.zip:mythes-sk
> caolanm:BADSOURCE:thes_de_DE_v2.zip:mythes-de
> caolanm:BADURL:sjp-myspell-pl-20080823.zip:hunspell-pl

With these ones though, the problem is that (with many dictionary and
thesaurus projects) upstream either rolls along continuously making
(sometimes daily) refreshes with new words and meanings, either 
reusing the same tarball name (BADSOURCE), or a date based one where
after a certain time the old one is removed (BADURL). 

So is it better practice for me in these cases to keep a full Source:
link correct as to the time of packaging, or better to chop off the path
and just leave the basename so they get skipped from the audit test ?
FWIW in my own "see if there have been newer releases" script I have
them tagged as date-base releases with a one month window before they
are marked as having a newer release available.

C.



From opensource at till.name  Thu Nov 20 09:54:43 2008
From: opensource at till.name (Till Maas)
Date: Thu, 20 Nov 2008 10:54:43 +0100
Subject: source file audit - 2008-11-14
In-Reply-To: <20081119170909.29694973@ohm.scrye.com>
References: <20081119170909.29694973@ohm.scrye.com>
Message-ID: <200811201054.48829.opensource@till.name>

On Thu November 20 2008, Kevin Fenzi wrote:

> orphan:BADSOURCE:gst-plugins-0.8.12.tar.bz2:gstreamer08-plugins
> orphan:BADSOURCE:kbiof-0.3.tar.gz:kbiof
> orphan:BADURL:gaim-galago-0.5.1.tar.bz2:purple-galago
> orphan:BADURL:gnome-blog-0.9.1.tar.bz2:gnome-blog
> orphan:BADURL:gnome-yum-0.1.4.tar.gz:gnome-yum
> orphan:BADURL:kbackup-0.5.4.tar.bz2:kbackup
> orphan:BADURL:moomps-5.8.tar.bz2:moomps
> orphan:BADURL:new-1.3.9.tar.gz:new
> orphan:BADURL:pam-script-0.1.7.tar.gz:pam_script
> orphan:BADURL:pam_usb-0.4.0.tar.gz:pam_usb
> orphan:BADURL:pekwm-0.1.5.tar.bz2:pekwm
> orphan:BADURL:TPG-3.1.2.tar.gz:python-tpg
> orphan:BADURL:tvn24_0.2.8-1.tar.gz:gnome-applet-tvn24

Are these maybe orphaned?

> till:BADURL:aircrack-ng-1.0-20081109.tar.gz:aircrack-ng

This is a svn snapshot, therefore there is no URL available. Is there some way 
to indicate this to your script? Another SourceX of this package is 
aircrack-ng-tarball which is a script that can be used to generate the 
snapshot. I spotted some more packages in the list that contain a date in 
their tarball and therefore are probably snapshot releases.

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/20081120/dea7423b/attachment.sig>

From twaugh at redhat.com  Thu Nov 20 10:11:22 2008
From: twaugh at redhat.com (Tim Waugh)
Date: Thu, 20 Nov 2008 10:11:22 +0000
Subject: My roadmap for a better Fedora
In-Reply-To: <20081119221721.GH26527@redhat.com>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>
	<20081119205950.GA4961@nostromo.devel.redhat.com>
	<adf480660811191323i552f933dy156a8416e22561ad@mail.gmail.com>
	<20081119221721.GH26527@redhat.com>
Message-ID: <1227175882.4643.14.camel@cyberelk.elk>

On Wed, 2008-11-19 at 22:17 +0000, Daniel P. Berrange wrote:
> Utterly useless. I already have a HUGE number of bug reports. The problem
> is that 90% of them are essentially useless when first reported. It requires
> several back/forth interactions between myself & the bug reporter to get 
> enough information to diagnose & resolve the problem.

I've found that too, with Bugzilla.  For system-config-printer which is
also distributed by Ubuntu, I've found that the Launchpad bug reports
usually contain most of the information I need to fix the problem: the
package version number, and (usually) the Python traceback for example.
This gets added to the bug report automatically using apport, without
the user knowing how to do any of it.

Of course there are plenty of Launchpad bug reports for
system-config-printer that can't be solved that way. (I just ignore
those.)

I do think that having one-way crash reporting is useful to a certain
degree, but implementing it in Bugzilla doesn't seem to be the right
approach.  A Bugzilla bug entry is quite a heavy-weight thing compared
to just a entry in a database of crashes like kerneloops.

The point is that software (never mind the user) is capable of reporting
problems in enough details for fixes to be made in a lot of cases.

In fact, I wrote the printing troubleshooter to do just that for the
limited case of printing problems, and it helps *enormously* when
someone attaches the troubleshoot.txt file from a printing problem.

Tim.
*/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081120/dbe912af/attachment.sig>

From mcepl at redhat.com  Thu Nov 20 11:29:42 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 20 Nov 2008 12:29:42 +0100
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
Message-ID: <6aufv5xi4u.ln2@ppp1053.in.ipex.cz>

On 2008-11-19, 22:47 GMT, Arthur Pemberton wrote:
> There are several competing products, and I doubt we engineer 
> type people use it "just because". I'm also assuming that we 
> use it for reasons other than because of RedHat.

Well, to make your list shorter (i.e., with one item):

* To be able to support number of products, components, users, 
  hits per second as Bugzilla does. Problem I heard of all 
  competing products (trac, jira, etc.) is that they are lovely 
  when you are talking about one project with few components, but 
  when you get to clustering databases and similar magic, all of 
  them fail pretty badly.
* of course, open source -- just to be safe that there isn't some 
  Microsoft/Oracle/whatever closed source thing, which can manage 
  it.

Mat?j



From dtimms at iinet.net.au  Thu Nov 20 11:34:47 2008
From: dtimms at iinet.net.au (David Timms)
Date: Thu, 20 Nov 2008 22:34:47 +1100
Subject: Proposal - "Slow updates" repo
In-Reply-To: <49231012.8090109@silfreed.net>
References: <49230F31.4030409@redhat.com> <49231012.8090109@silfreed.net>
Message-ID: <49254B57.8050603@iinet.net.au>

Douglas E. Warner wrote:
> frequently. Perhaps this 3-repo structure would work well for both 
> groups ("testing", "normal", "stable").
'stable' -> 'glacial' ?

DaveT.



From mschwendt at gmail.com  Thu Nov 20 11:42:52 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 20 Nov 2008 12:42:52 +0100
Subject: F11: things to check in a release tree before a release
In-Reply-To: <alpine.LFD.2.00.0811191851130.10340@localhost.localdomain>
References: <alpine.LFD.2.00.0811191547010.10340@localhost.localdomain>
	<20081119222235.699e4437.mschwendt@gmail.com>
	<alpine.LFD.2.00.0811191628050.10340@localhost.localdomain>
	<20081119223810.a43dfa41.mschwendt@gmail.com>
	<20081119220328.GA1371485@hiwaay.net>
	<20081120002409.16768218.mschwendt@gmail.com>
	<alpine.LFD.2.00.0811191851130.10340@localhost.localdomain>
Message-ID: <20081120124252.885c1847.mschwendt@gmail.com>

On Wed, 19 Nov 2008 18:51:43 -0500 (EST), Seth Vidal wrote:

> > If you really want to check all sorts of multiple Provides, that'll be
> > a long list with a lot that must be white-listed.
> 
> I was thinking along the lines of we generate the list, manually check.
> 
> Then we work on generating diffs vs past lists for the future.
> 
> so we aren't constantly seeing the same stream of data.

Which is roughly what I've done: using "diff against previous" and a
whitelist of package names for "valid virtual provides".

That worked fine till bug-triagers threatened to close bugzilla tickets
because of dist EOL and then mass-closed them later. Too much extra burden
-- having to revisit tickets and verify the issues and likely doing it
again next EOL is reached.

What was missing is a script to maintain the bugzilla ticket numbers,
to detect fixed packages (which no longer appear on the list), to help with
closing tickets, and to add reminders to the tickets automatically.

And, of course, official backup from FESCo would be nice and helpful,
too. Else it's not worthwhile to file such tickets. Because packagers may
decide for themselves whether they consider an issue important enough
(even if it causes real problems, which are reproducible in Yum
installation scenarios).



From mschwendt at gmail.com  Thu Nov 20 11:49:19 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 20 Nov 2008 12:49:19 +0100
Subject: source file audit - 2008-11-14
In-Reply-To: <20081119170909.29694973@ohm.scrye.com>
References: <20081119170909.29694973@ohm.scrye.com>
Message-ID: <20081120124919.da168a5f.mschwendt@gmail.com>

On Wed, 19 Nov 2008 17:09:09 -0700, Kevin Fenzi wrote:

> mschwendt:BADURL:audacious-plugin-fc-0.3.tar.bz2:audacious-plugin-fc

Here I see room for improving the script. As the SourceForge download
locations change often, could you check the Source URL against a template
that is recommended somewhere in the depths of the Fedora Project Wiki?

wget http://download.sourceforge.net/xmms-fc/audacious-plugin-fc-0.3.tar.bz2
used to work in round-robin fashion, but currently hangs because it cannot
connect.



From kanarip at kanarip.com  Thu Nov 20 12:03:52 2008
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Thu, 20 Nov 2008 13:03:52 +0100
Subject: Games spin is out for F10
Message-ID: <49255228.3040208@kanarip.com>

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

Regrettably, we have to drop the Games spin for a release with F10 GA.

There has been problems composing this spin for F10-Preview, and there's
problems popping up real close to release (which is right now). It's
actually caused by a missing package (simple fix) but the real problem
is whether the maintainer(s) fix(es) the problem and actually test(s)
the spin.

This seems to have not been the case for the Games spin over the course
of the last few weeks, and once we hand over a couple of kickstarts for
Release Engineering to compose, we need to be sure they do not run into
problems for they lack the ability to take over the maintainers work and
fix the kickstart -a workflow related thing.

We (as the Spin SIG) could step in and nurture the kickstart, but not
this close to final GA, and not if it causes Rel. Eng. to need to
through compose/fail/feedback/re-compose loops for every fix that should
have been committed by the maintainer already.

Kind regards,

Jeroen van Meeuwen
- -kanarip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkklUigACgkQKN6f2pNCvwj9zACg1JECHQE/cYEQ1WpDLBYjG2CZ
qV4AmgKoMr9o2MibR3JA4oeS8MW/Kl/X
=ysjp
-----END PGP SIGNATURE-----



From dtimms at iinet.net.au  Thu Nov 20 12:06:16 2008
From: dtimms at iinet.net.au (David Timms)
Date: Thu, 20 Nov 2008 23:06:16 +1100
Subject: My roadmap for a better Fedora
In-Reply-To: <1227119906.7387.138.camel@localhost.localdomain>
References: <1227119906.7387.138.camel@localhost.localdomain>
Message-ID: <492552B8.1040703@iinet.net.au>

Callum Lerwick wrote:
> 1) Make it easy to report bugs. Bugzilla is complex, slow, and

> 2) Make it simple to roll back to a known good state. We need a "system
How about, you can roll back if and only if you report the bug... ;-)

Otherwise it is too easy for every bug finder to ignore and just go back 
to what was working for them....

DaveT.



From dtimms at iinet.net.au  Thu Nov 20 13:17:54 2008
From: dtimms at iinet.net.au (David Timms)
Date: Fri, 21 Nov 2008 00:17:54 +1100
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
In-Reply-To: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
Message-ID: <49256382.3080506@iinet.net.au>

Arthur Pemberton wrote:
> My question is, what do we need/want/like from Bugzilla?
wishes:
- be able to note a weirdity, failure to configure correctly etc, that 
is listed firstly as an issue, and could progress to a bug = triaged to 
repeatable steps. alternately, it moves to a FAQ (solve it with a few 
simple steps), or a detailed config howto page (ie user just wants free 
config help).

- prompt the reporter for symptom, with clear examples:
   - box wouldn't start in normal graphical desktop
   - box wouldn't get to boot
   - service failed to start
   - app failed to start at all
   - text application stopped, saying SEGFAULT
   - application showed a bug/crash dialog
   - application disappeared from my screen
   - app function didn't work as it previously did
   - app function didn't work as expected
   - desktop stopped responding
   - box stopped responding
ie: to a person of basic computer knowledge, what did the issue look like

   - a separate by-line for me-too comments (eg I got that on x86_64, I 
got it on a "piece of old carpet" things that people tend to add to 
bugzilla / bugs.launchpad etc. These can server as breadth of issue 
marker, but aren't really clarifying a bug, with option to add hardware 
id from smolt. [ x ] I experienced this symptom and my smolt hardware 
dsecription is [http://smotls.y.z/12345656]

     - a way to mark a me-too comment as "me-too".

- a link to a workaround eg in wiki or similar

- text to flow properly when you don't have the browser window full 
screen width; currently especially the top fields in the window.
- comment body to be able to flow to the full width of the window, not 
restricted by invisible right hand side images/columns whatever.
- auto wrap for long <pre> lines, perhaps inserting  " \" at end of each 
line.

- helper for what the bug component might be, perhaps drilling down 
through queries like [at boot, before login, after login, running 
program]...

- once a component is selected, provide fedoraproject links {open in new 
tab} like:
   - bug.r.c open bugs for that component
   - bug.r.c all most recent 25 bugs for that component
   - link to viewcvs toplevel for the package  {devel links with pretty 
icons}
   - link to most recent commits for the package
   - list to all koji builds for package.
   - list to bodhi info for package, especially comment/karma page
   - show most recent updates and updates-testing packages, with recent 
changelogs
   - a way to trigger yum/PK check for update and offer to install it.
   - "  "   "   "       "  "   "     "  update-testing and offer to install
   - "  "   "   "       "  "   "     "  rawhide and offer to install

Just some thought, DaveT.



From nicolas.mailhot at laposte.net  Thu Nov 20 13:41:44 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 20 Nov 2008 14:41:44 +0100 (CET)
Subject: What do we need from Bugzilla? (was: My roadmap for a better 
 Fedora)
In-Reply-To: <6aufv5xi4u.ln2@ppp1053.in.ipex.cz>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<6aufv5xi4u.ln2@ppp1053.in.ipex.cz>
Message-ID: <7deeb2190ab5fc7bff30a343cc9e5c49.squirrel@arekh.dyndns.org>



Le Jeu 20 novembre 2008 12:29, Matej Cepl a ?crit :
>
> On 2008-11-19, 22:47 GMT, Arthur Pemberton wrote:
>> There are several competing products, and I doubt we engineer
>> type people use it "just because". I'm also assuming that we
>> use it for reasons other than because of RedHat.
>
> Well, to make your list shorter (i.e., with one item):
>
> * To be able to support number of products, components, users,
>   hits per second as Bugzilla does. Problem I heard of all
>   competing products (trac, jira, etc.) is that they are lovely
>   when you are talking about one project with few components, but
>   when you get to clustering databases and similar magic, all of
>   them fail pretty badly.
> * of course, open source -- just to be safe that there isn't some
>   Microsoft/Oracle/whatever closed source thing, which can manage
>   it.

Add to this
- feature completeness
- familiar UI
- integration with upstream issue trackers (which are often bugzilla too)

For all its cranks bugzilla is familiar to a lot of bug reporters that
use all the features added over time.

Any replacement must be at least as feature-full as bugzilla (not
simpler because it forgets to do some stuff) and offer a bugzilla-like
mode for existing reporters that do not have the time to learn yet
another reporting UI.

-- 
Nicolas Mailhot



From ndbecker2 at gmail.com  Thu Nov 20 13:44:06 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 20 Nov 2008 08:44:06 -0500
Subject: ipa conflicts with mod_ssl (F9)
Message-ID: <gg3pj6$dhb$1@ger.gmane.org>

sudo yum install ipa-server ipa-client ipa-admintools
...
ipa-server-1.2.0-1.fc9.x86_64 from updates-newkey has depsolving problems
  --> ipa-server conflicts with mod_ssl
Error: ipa-server conflicts with mod_ssl

rpm -q mod_ssl
mod_ssl-2.2.9-1.fc9.x86_64




From pingou at pingoured.fr  Thu Nov 20 13:45:59 2008
From: pingou at pingoured.fr (Pierre-Yves)
Date: Thu, 20 Nov 2008 14:45:59 +0100
Subject: ipa conflicts with mod_ssl (F9)
In-Reply-To: <gg3pj6$dhb$1@ger.gmane.org>
References: <gg3pj6$dhb$1@ger.gmane.org>
Message-ID: <49256A17.1060204@pingoured.fr>

Neal Becker wrote:
> sudo yum install ipa-server ipa-client ipa-admintools
> ...
> ipa-server-1.2.0-1.fc9.x86_64 from updates-newkey has depsolving problems
>   --> ipa-server conflicts with mod_ssl
> Error: ipa-server conflicts with mod_ssl
> 
> rpm -q mod_ssl
> mod_ssl-2.2.9-1.fc9.x86_64
> 
http://bugzilla.redhat.com

Regards,
P.



From berrange at redhat.com  Thu Nov 20 13:46:57 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Thu, 20 Nov 2008 13:46:57 +0000
Subject: ipa conflicts with mod_ssl (F9)
In-Reply-To: <gg3pj6$dhb$1@ger.gmane.org>
References: <gg3pj6$dhb$1@ger.gmane.org>
Message-ID: <20081120134655.GB19614@redhat.com>

On Thu, Nov 20, 2008 at 08:44:06AM -0500, Neal Becker wrote:
> sudo yum install ipa-server ipa-client ipa-admintools
> ...
> ipa-server-1.2.0-1.fc9.x86_64 from updates-newkey has depsolving problems
>   --> ipa-server conflicts with mod_ssl
> Error: ipa-server conflicts with mod_ssl

IPA requires  mod_nss, and mod_nss & mod_ssl are unable to co-exist
in apache, so IPA has a conflict with mod_ssl. That said, its a little
od that the Conflicts: is not in the mod_nss RPM itself.

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  Thu Nov 20 13:53:42 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 20 Nov 2008 13:53:42 +0000
Subject: Heads up: OCaml 3.11.0 rebuild for Fedora 11
In-Reply-To: <49245BC4.8040001@cora.nwra.com>
References: <20081118174914.GA27575@amd.home.annexia.org>
	<20081119171114.GA1584@amd.home.annexia.org>
	<49245BC4.8040001@cora.nwra.com>
Message-ID: <20081120135342.GA6816@amd.home.annexia.org>

On Wed, Nov 19, 2008 at 11:32:36AM -0700, Orion Poplawski wrote:
> Can you test plplot?

Works fine under 3.11.0.

BTW I would strongly recommend that the plplot-ocaml* subpackages
should include the correct OCaml dependencies, as required by the
guidelines and as produced by the custom ocaml-find-requires script.

  https://fedoraproject.org/wiki/Packaging/OCaml#Requires_and_provides

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 lesmikesell at gmail.com  Thu Nov 20 14:05:58 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 20 Nov 2008 08:05:58 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <ddlfv5x4hr.ln2@ppp1053.in.ipex.cz>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>	<20081113210903.GG1538120@hiwaay.net>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>	<20081113223242.GB4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>	<1226678932.636.40.camel@aglarond.local>	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>	<1226686948.13086.44.camel@aglarond.local>	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>	<1226700116.13086.116.camel@aglarond.local>	<491FBA0E.2070003@gmail.com>	<1227043592.4687.9.camel@firewall.xsintricity.com>	<49234139.1050400@gmail.com>	<1227057520.4687.45.camel@firewall.xsintricity.com>
	<4923836B.109030	9@gmail.com>
	<1227110198.4687.108.camel@firewall.xsintricity.com>	<492467D6.7050803@gmail.com>	<1227126323.4687.178.camel@firewall.xsintricity.com>	<49250B08.4080206@gmail.com>
	<ddlfv5x4hr.ln2@ppp1053.in.ipex.cz>
Message-ID: <49256EC6.9070000@gmail.com>

Matej Cepl wrote:
> On 2008-11-20, 07:00 GMT, Les Mikesell wrote:
>> Maybe - but it isn't a real solution.  You still have to deal 
>> with identifying the device before and during the labeling 
>> process.  If you can do that, you didn't really need the label.
> 
> Sorry, maybe I don't understand, but what's so difficult on the 
> following?
> 
> tune2fs -l /dev/sda1 |awk '/UUID/ {print $3}'
> 

The disk may be unformatted at this point and not have a UUID.  Or if it 
has filesystems, they may be types that don't support labels or UUID's 
(vfat, etc.).   But the point is that if you already knew it was 
/dev/sda1, why do you need to care about anything else?

There are at least two different use cases here.  One is that you have a 
single machine where you move a known small set of drives around to 
different positions (or they are usb/firewire, etc. where you don't have 
a concept of position) and you always want the same partition mounted in 
the same place regardless of where it ends up in the physical order.  I 
do have a machine like that and understand why the concept of labels or 
uuids is useful - but in that case I made all of the partitions into 
raid1 md devices (some mirrored, some with the 2nd member specified as 
'missing' which accomplishes the same thing and lets me plug in a disk 
with a matching partition and make a backup by adding it to the raid.

The other use case is where you have a large number of servers with 
swappable drives and regularly swap them around.  Scsi/sca backplanes 
are usually predictable as to drive ordering so if you physically insert 
a disk you automatically know the /dev/sd? name for it.  This may not be 
true for newer sas/sata controllers with raid logic that hides the 
physical drives behind 'volumes' even if you configure one drive per 
volume, though.  But in any case you need a way to discover and identify 
devices before and during the partitioning and filesystem creation 
steps, and labels can't help you then.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From emmanuel.seyman at club-internet.fr  Thu Nov 20 14:10:55 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Thu, 20 Nov 2008 15:10:55 +0100
Subject: What do we need from Bugzilla? (was: My roadmap for a better
	Fedora)
In-Reply-To: <7deeb2190ab5fc7bff30a343cc9e5c49.squirrel@arekh.dyndns.org>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<6aufv5xi4u.ln2@ppp1053.in.ipex.cz>
	<7deeb2190ab5fc7bff30a343cc9e5c49.squirrel@arekh.dyndns.org>
Message-ID: <20081120141055.GA6732@orient.maison.lan>

* Nicolas Mailhot [20/11/2008 15:04] :
>
> Any replacement must be at least as feature-full as bugzilla (not
> simpler because it forgets to do some stuff) and offer a bugzilla-like
> mode for existing reporters that do not have the time to learn yet
> another reporting UI.

And as an encore : it has to contain 109900+ bugs of existing data so
that we don't lose any history.

Emmanuel



From hughsient at gmail.com  Thu Nov 20 14:33:27 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 20 Nov 2008 14:33:27 +0000
Subject: RFC: fix summary text for lots of packages
Message-ID: <1227191607.4076.29.camel@hughsie-laptop>

The packaging guidelines have a single sentence on package summaries:
https://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description

"The summary should be a short and concise description of the package"

Broken packages are a problem as PackageKit shows the summary first (in
bold) in preference to the package name. This is by design.

Quite a lot of packages have summary text that is overly verbose, and
this makes the GUI and output from pkcon look rubbish.

For instance, I've filed
https://bugzilla.redhat.com/show_bug.cgi?id=472365 where the oggconvert
package has a summary of:

"A simple GNOME application that converts media files to Free formats"

First, we don't need to say it's an application, not that it's GNOME
specific. Surely something like this would be better:

"Simple media converter"
or
"Simple conversion to free media formats"
or
"Simple media converter using free formats"

The guidelines also don't say if it should be Title Case or if the
summary should include the application name. If we come to some
guidelines (or working practices) on this email thread, I'll update the
wiki page with more details.

It would also be a good idea to have a few "shining examples" for people
to copy when creating new packages. When we've done that, I'll start
filing bugs.

Thanks,

Richard.




From opensource at till.name  Thu Nov 20 14:49:20 2008
From: opensource at till.name (Till Maas)
Date: Thu, 20 Nov 2008 15:49:20 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227191607.4076.29.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
Message-ID: <200811201549.36055.opensource@till.name>

On Thu November 20 2008, Richard Hughes wrote:

> "A simple GNOME application that converts media files to Free formats"
>
> First, we don't need to say it's an application, not that it's GNOME
> specific. Surely something like this would be better:

If I understand you correctly, you say that the summary should not mention, 
that it is GNOME specific, but in the bug report you write that this is a 
good summary:

| GNOME Power Manager

Imho it is not bad to mention that an applications is GNOME / KDE / whatever 
specific unless it is obvious from the package name. Also iirc the package 
for the GNOME power manager is also named gnome-power-manager, so imho above 
summary does not contain any additional useful information imho.

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081120/8bcaf377/attachment.sig>

From gilboad at gmail.com  Thu Nov 20 14:50:32 2008
From: gilboad at gmail.com (Gilboa Davara)
Date: Thu, 20 Nov 2008 16:50:32 +0200
Subject: Adobe Releases 64bit Flash Plugin for Linux
In-Reply-To: <4923CE2A.9020707@redhat.com>
References: <9497e9990811171313h7eacc6b0k9aec1401675494d@mail.gmail.com>
	<20081117213116.GA25672@mokona.greysector.net>
	<4922C0D5.4070209@redhat.com> <gfv4jp$abq$1@ger.gmane.org>
	<1227036667.28543.7.camel@luminos.localdomain>
	<981da310811181555o3b4f0a7die4a4df37a5f7ecba@mail.gmail.com>
	<4923CE2A.9020707@redhat.com>
Message-ID: <1227192632.6018.6.camel@gilboa-work-dev.localdomain>

On Wed, 2008-11-19 at 09:28 +0100, Martin Stransky wrote:
> Brennan Ashton wrote:
> > 2008/11/18 Jesse Keating <jkeating at redhat.com>:
> >> On Tue, 2008-11-18 at 14:21 -0500, Neal Becker wrote:
> >>> Should nspluginwrapper be banned from wrapping this?  If so, should
> >>> this be included in flash-plugin.spec?
> >> Oh, I'm pretty sure you still want to keep flash separated from your
> >> browser, regardless of the arch.
> > 
> > Not according to the developer of the 64bit plugin.
> > 
> > "
> > Talking about nspluginwrapper: I strongly suggest not to use it. I
> > know that some distros are thinking of even wrapping 64-bit plugins
> > including Ubuntu with the thought that it will improve security and
> > stability of the browser. This is a very bad idea in the state
> > nspluginwrapper is in today. We have done some internal testing and
> > discovered that several features in the Flash Player are broken when
> > the plugin is wrapped. More importantly performance and user
> > experience is pretty bad when the plugin is wrapped. Why? Lots of data
> > needs to be transfered through IPC channels. I hope that browser
> > vendors will eventually come up with a better architecture to wrap
> > plugins without sacrificing performance, stability and functionality.
> > "
> > http://www.kaourantin.net/2008/11/64-bits.html
> > 
> > 
> > I am not advocating one way or another, just wanted to get the voice
> > out of one of the few who really knows what is going on behind the
> > plugin.
> 
> For instance, NPAPI plugins can share memory with browser and operate 
> with internal browser memory (like DOM tree) and this "feature" is 
> blocked by nspluginwrapper because of it's simple architecture.
> 
> Full browser-side emulation will be extremely complex and is close to 
> chrome model where one process holds one browser page...
> 
> ma.

... And the last thing you'll want (from both stability and privacy
viewpoint) is to have a random plugin running code from some random
website have access to your browser memory space.

As for using multiple processes instead of multi-threading, I fully
agree. (though I can't really comment about Chrome as I never tested it)

- Gilboa




From jwboyer at gmail.com  Thu Nov 20 14:53:28 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 20 Nov 2008 09:53:28 -0500
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227191607.4076.29.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
Message-ID: <20081120145328.GB2410@yoda.jdub.homelinux.org>

On Thu, Nov 20, 2008 at 02:33:27PM +0000, Richard Hughes wrote:
>The guidelines also don't say if it should be Title Case or if the
>summary should include the application name. If we come to some
>guidelines (or working practices) on this email thread, I'll update the
>wiki page with more details.

So, while I think packaging guidelines are good to have, I don't think
everything needs to be codified there.  It just makes a reviewer's job
harder, and writing a guideline for this is going to be fairly tedious.

>It would also be a good idea to have a few "shining examples" for people
>to copy when creating new packages. When we've done that, I'll start
>filing bugs.

Just file bugs for packages you think are overly verbose.  Offer
alternate summaries in the bug, and a URL to your email for
rationale.

josh



From skvidal at fedoraproject.org  Thu Nov 20 14:59:22 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 20 Nov 2008 09:59:22 -0500 (EST)
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081120145328.GB2410@yoda.jdub.homelinux.org>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<20081120145328.GB2410@yoda.jdub.homelinux.org>
Message-ID: <alpine.LFD.2.00.0811200959170.16994@localhost.localdomain>



On Thu, 20 Nov 2008, Josh Boyer wrote:

> On Thu, Nov 20, 2008 at 02:33:27PM +0000, Richard Hughes wrote:
>> The guidelines also don't say if it should be Title Case or if the
>> summary should include the application name. If we come to some
>> guidelines (or working practices) on this email thread, I'll update the
>> wiki page with more details.
>
> So, while I think packaging guidelines are good to have, I don't think
> everything needs to be codified there.  It just makes a reviewer's job
> harder, and writing a guideline for this is going to be fairly tedious.
>
>> It would also be a good idea to have a few "shining examples" for people
>> to copy when creating new packages. When we've done that, I'll start
>> filing bugs.
>
> Just file bugs for packages you think are overly verbose.  Offer
> alternate summaries in the bug, and a URL to your email for
> rationale.

+1
-sv



From notting at redhat.com  Thu Nov 20 14:56:28 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 20 Nov 2008 09:56:28 -0500
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081120145328.GB2410@yoda.jdub.homelinux.org>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<20081120145328.GB2410@yoda.jdub.homelinux.org>
Message-ID: <20081120145628.GB28357@nostromo.devel.redhat.com>

Josh Boyer (jwboyer at gmail.com) said: 
> >It would also be a good idea to have a few "shining examples" for people
> >to copy when creating new packages. When we've done that, I'll start
> >filing bugs.
> 
> Just file bugs for packages you think are overly verbose.  Offer
> alternate summaries in the bug, and a URL to your email for
> rationale.

I'm not sure this scales across 5000 packages. So it would be good
to have at least *something* in the guidelines.

Bill



From rc040203 at freenet.de  Thu Nov 20 15:12:53 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 20 Nov 2008 16:12:53 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081120145628.GB28357@nostromo.devel.redhat.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<20081120145328.GB2410@yoda.jdub.homelinux.org>
	<20081120145628.GB28357@nostromo.devel.redhat.com>
Message-ID: <1227193973.3752.858.camel@beck.corsepiu.local>

On Thu, 2008-11-20 at 09:56 -0500, Bill Nottingham wrote:
> Josh Boyer (jwboyer at gmail.com) said: 
> > >It would also be a good idea to have a few "shining examples" for people
> > >to copy when creating new packages. When we've done that, I'll start
> > >filing bugs.
> > 
> > Just file bugs for packages you think are overly verbose.  Offer
> > alternate summaries in the bug, and a URL to your email for
> > rationale.
> 
> I'm not sure this scales across 5000 packages. So it would be good
> to have at least *something* in the guidelines.

Well, the FPG is intentionally lax on %summary's, because we had wanted
to avoid getting lot in endless discussions on something which is
technically widely meaningness.

Ralf






From hughsient at gmail.com  Thu Nov 20 15:19:52 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 20 Nov 2008 15:19:52 +0000
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227193973.3752.858.camel@beck.corsepiu.local>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<20081120145328.GB2410@yoda.jdub.homelinux.org>
	<20081120145628.GB28357@nostromo.devel.redhat.com>
	<1227193973.3752.858.camel@beck.corsepiu.local>
Message-ID: <1227194392.4076.31.camel@hughsie-laptop>

On Thu, 2008-11-20 at 16:12 +0100, Ralf Corsepius wrote:
> On Thu, 2008-11-20 at 09:56 -0500, Bill Nottingham wrote:
> > Josh Boyer (jwboyer at gmail.com) said: 
> > > >It would also be a good idea to have a few "shining examples" for people
> > > >to copy when creating new packages. When we've done that, I'll start
> > > >filing bugs.
> > > 
> > > Just file bugs for packages you think are overly verbose.  Offer
> > > alternate summaries in the bug, and a URL to your email for
> > > rationale.
> > 
> > I'm not sure this scales across 5000 packages. So it would be good
> > to have at least *something* in the guidelines.
> 
> Well, the FPG is intentionally lax on %summary's, because we had wanted
> to avoid getting lot in endless discussions on something which is
> technically widely meaningness.

Right, but maybe we could have a soft guideline such as:

* Summary should aim to be less than 8 words

Richard.




From james at fedoraproject.org  Thu Nov 20 15:41:26 2008
From: james at fedoraproject.org (James Antill)
Date: Thu, 20 Nov 2008 10:41:26 -0500
Subject: reportbug? [Was: Re: My roadmap for a better Fedora]
In-Reply-To: <tbifv5x6kn.ln2@ppp1053.in.ipex.cz>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<tbifv5x6kn.ln2@ppp1053.in.ipex.cz>
Message-ID: <1227195686.4355.203.camel@code.and.org>

On Thu, 2008-11-20 at 09:05 +0100, Matej Cepl wrote:
> On 2008-11-19, 18:38 GMT, Callum Lerwick wrote:
> > 1) Make it easy to report bugs. Bugzilla is complex, slow, and
> > inscrutable. We need to put a simpler layer on top of it. Reporting a
> > bug should require just a few clicks.
> 
> In my checkerd past is a long streak of using Debian. There 
> I really liked reportbug script -- in my opinion, reporting bug 
> should not include any clicks at all.
> 
> The beauty of such script is that it is able to collect all 
> necessary information itself and it could theoretically carry 
> some database of information needed for the particular component.  
> Or it could do even some light pre-processing of the information?
> 
> Still it could do much more than whatever we can even dream about 
> with the web form no matter how many clicks we require -- I am 
> afraid that in case of web forms there is a direct relationship
> between usefulness of information and number of clicks required.
> 
> Comments?

 I don't remember reportbug being that userfriendly, but yeh some
graphical tool that can get local data and screenshots etc. would be
nice.
 _But_ as others have said in this thread, if someone wants to do some
easy/quick to use tools for BZ the first ones they should be writing are
for the developers/packagers. I won't mind getting 666 dups, or dealing
with 10x as many bugs in general, as long as I have a decent local tool
that can manage that number of bugs. Atm. lots of TABs of open bugs, and
giant folders of BZ email are the best tools I've seen.

-- 
James Antill <james at fedoraproject.org>
Fedora



From dwmw2 at infradead.org  Thu Nov 20 16:14:39 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 20 Nov 2008 16:14:39 +0000
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227194392.4076.31.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<20081120145328.GB2410@yoda.jdub.homelinux.org>
	<20081120145628.GB28357@nostromo.devel.redhat.com>
	<1227193973.3752.858.camel@beck.corsepiu.local>
	<1227194392.4076.31.camel@hughsie-laptop>
Message-ID: <1227197679.4901.29.camel@macbook.infradead.org>

On Thu, 2008-11-20 at 15:19 +0000, Richard Hughes wrote:
> Right, but maybe we could have a soft guideline such as:
> 
> * Summary should aim to be less than 8 words

Or even fewer than 8 words?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From jwboyer at gmail.com  Thu Nov 20 16:19:52 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 20 Nov 2008 11:19:52 -0500
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081120145628.GB28357@nostromo.devel.redhat.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<20081120145328.GB2410@yoda.jdub.homelinux.org>
	<20081120145628.GB28357@nostromo.devel.redhat.com>
Message-ID: <20081120161952.GC2410@yoda.jdub.homelinux.org>

On Thu, Nov 20, 2008 at 09:56:28AM -0500, Bill Nottingham wrote:
>Josh Boyer (jwboyer at gmail.com) said: 
>> >It would also be a good idea to have a few "shining examples" for people
>> >to copy when creating new packages. When we've done that, I'll start
>> >filing bugs.
>> 
>> Just file bugs for packages you think are overly verbose.  Offer
>> alternate summaries in the bug, and a URL to your email for
>> rationale.
>
>I'm not sure this scales across 5000 packages. So it would be good
>to have at least *something* in the guidelines.

You're assuming that all 5000 packages need fixing.  I doubt that's
the case.

Also, the bugs need to be filed either way.  So the scaling argument
still applies and adding a guideline for this is really just unneeded
work...

josh



From a.badger at gmail.com  Thu Nov 20 16:17:43 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 20 Nov 2008 08:17:43 -0800
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227194392.4076.31.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>	<20081120145328.GB2410@yoda.jdub.homelinux.org>	<20081120145628.GB28357@nostromo.devel.redhat.com>	<1227193973.3752.858.camel@beck.corsepiu.local>
	<1227194392.4076.31.camel@hughsie-laptop>
Message-ID: <49258DA7.5050808@gmail.com>

Richard Hughes wrote:
> On Thu, 2008-11-20 at 16:12 +0100, Ralf Corsepius wrote:
>> On Thu, 2008-11-20 at 09:56 -0500, Bill Nottingham wrote:
>>> Josh Boyer (jwboyer at gmail.com) said: 
>>>>> It would also be a good idea to have a few "shining examples" for people
>>>>> to copy when creating new packages. When we've done that, I'll start
>>>>> filing bugs.
>>>> Just file bugs for packages you think are overly verbose.  Offer
>>>> alternate summaries in the bug, and a URL to your email for
>>>> rationale.
>>> I'm not sure this scales across 5000 packages. So it would be good
>>> to have at least *something* in the guidelines.
>> Well, the FPG is intentionally lax on %summary's, because we had wanted
>> to avoid getting lot in endless discussions on something which is
>> technically widely meaningness.
> 
> Right, but maybe we could have a soft guideline such as:
> 
> * Summary should aim to be less than 8 words
> 
I generally dislike soft guidelines.  Instead of the Packaging Committee
making a controversial decisions that contributors argue about, it
becomes the individual reviewers and packagers arguing about it on many
separate bugs....

Which is not to say that I wouldn't vote for such a thing, just that I
usually ask:
1) Why can this not be a hard guideline?  (In this case, because it's
something that's better left to the packager).

2) Why should this be part of the review guidelines, then?  (So one GUI
tool can better support its interface).

3) Does number 2 justify the arguments that packagers and reviewers are
going to get into and the bugs that will be opened about them?  I'm not
so certain about this one... then again, I haven't opened up a GUI
package manager for over 6 months so....

What I would put into the Guidelines are the best practices and
suggestions you talk about.  That way the review guidelines stay pretty
much the same but people can refer to the best practices for things that
make a good summary.

So instead of:
*Should*: a summary should aim to be less than eight words

we'd have a paragraph or page that describes the summary:

The summary is used by many GUI tools.  Our main supported GUI tool
makes the summary more prominent than the package name because it is
often a better description for the end user to make a decision about
installing.  To make the user's experience better here, we try to have
short, succinct summaries that don't repeat information in the name.

For instance, a good summary for gnome-power-manager would be "Gnome
Applets for setting power saving features"
The repetition of GNOME is good in this case because the applets *only*
run on the gnome panel.

A good summary for: [continue with other examples]

-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/20081120/4f18bd62/attachment.sig>

From notting at redhat.com  Thu Nov 20 16:28:50 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 20 Nov 2008 11:28:50 -0500
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081120161952.GC2410@yoda.jdub.homelinux.org>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<20081120145328.GB2410@yoda.jdub.homelinux.org>
	<20081120145628.GB28357@nostromo.devel.redhat.com>
	<20081120161952.GC2410@yoda.jdub.homelinux.org>
Message-ID: <20081120162850.GA30445@nostromo.devel.redhat.com>

Josh Boyer (jwboyer at gmail.com) said: 
> >I'm not sure this scales across 5000 packages. So it would be good
> >to have at least *something* in the guidelines.
> 
> You're assuming that all 5000 packages need fixing.  I doubt that's
> the case.

No, but it's not something you can easily automate (unlike
FTBFS, or broken deps.)

> Also, the bugs need to be filed either way.  So the scaling argument
> still applies and adding a guideline for this is really just unneeded
> work...

If you get it fixed in the guidelines and at the review point, you
eliminate having to scan & file all those bugs later - always fix
issues as early as possible.

Bill



From hughsient at gmail.com  Thu Nov 20 16:29:38 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 20 Nov 2008 16:29:38 +0000
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <49258DA7.5050808@gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<20081120145328.GB2410@yoda.jdub.homelinux.org>
	<20081120145628.GB28357@nostromo.devel.redhat.com>
	<1227193973.3752.858.camel@beck.corsepiu.local>
	<1227194392.4076.31.camel@hughsie-laptop> <49258DA7.5050808@gmail.com>
Message-ID: <1227198578.4076.37.camel@hughsie-laptop>

On Thu, 2008-11-20 at 08:17 -0800, Toshio Kuratomi wrote:
> The summary is used by many GUI tools.  Our main supported GUI tool
> makes the summary more prominent than the package name because it is
> often a better description for the end user to make a decision about
> installing.  To make the user's experience better here, we try to have
> short, succinct summaries that don't repeat information in the name.

Works for me.

Richard.




From ivazqueznet at gmail.com  Thu Nov 20 16:34:57 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Thu, 20 Nov 2008 11:34:57 -0500
Subject: source file audit - 2008-11-14
In-Reply-To: <1227161243.736.107.camel@ignacio.lan>
References: <20081119170909.29694973@ohm.scrye.com>
	<1227161243.736.107.camel@ignacio.lan>
Message-ID: <1227198897.736.132.camel@ignacio.lan>

On Thu, 2008-11-20 at 01:07 -0500, Ignacio Vazquez-Abrams wrote:
> On Wed, 2008-11-19 at 17:09 -0700, Kevin Fenzi wrote:
> > ivazquez:BADURL:purple-plugin_pack-2.4.0.tar.bz2:purple-plugin_pack
> 
> This is upstream being... something. I'll have to have a chat with them.

*sigh* They've decided that it's WONTFIX, so spectool is hosed unless
it's modified to pass --content-disposition to wget.

-- 
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/20081120/c4fb2e82/attachment.sig>

From a.badger at gmail.com  Thu Nov 20 16:38:13 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 20 Nov 2008 08:38:13 -0800
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227198578.4076.37.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>	<20081120145328.GB2410@yoda.jdub.homelinux.org>	<20081120145628.GB28357@nostromo.devel.redhat.com>	<1227193973.3752.858.camel@beck.corsepiu.local>	<1227194392.4076.31.camel@hughsie-laptop>
	<49258DA7.5050808@gmail.com>
	<1227198578.4076.37.camel@hughsie-laptop>
Message-ID: <49259275.3000201@gmail.com>

Richard Hughes wrote:
> On Thu, 2008-11-20 at 08:17 -0800, Toshio Kuratomi wrote:
>> The summary is used by many GUI tools.  Our main supported GUI tool
>> makes the summary more prominent than the package name because it is
>> often a better description for the end user to make a decision about
>> installing.  To make the user's experience better here, we try to have
>> short, succinct summaries that don't repeat information in the name.
> 
> Works for me.
> 
Okay.  Please fill in other examples so packagers and reviewers can get
a feel for what to cut and when it's good to depart from the general
rules and put it on the wiki under PackagingDrafts.  Then add it to the
list of things for the Packaging Committee to discuss.

We can link it from this portion of the full Guidelines:
http://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description

-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/20081120/dab56117/attachment.sig>

From mhlavink at redhat.com  Thu Nov 20 16:46:42 2008
From: mhlavink at redhat.com (Michal Hlavinka)
Date: Thu, 20 Nov 2008 17:46:42 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227191607.4076.29.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
Message-ID: <49259472.7010103@redhat.com>

Richard Hughes wrote:
> The packaging guidelines have a single sentence on package summaries:
> https://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description
>
> "The summary should be a short and concise description of the package"
>
> Broken packages are a problem as PackageKit shows the summary first (in
> bold) in preference to the package name. This is by design.
>
> Quite a lot of packages have summary text that is overly verbose, and
> this makes the GUI and output from pkcon look rubbish.
>
> For instance, I've filed
> https://bugzilla.redhat.com/show_bug.cgi?id=472365 where the oggconvert
> package has a summary of:
>
> "A simple GNOME application that converts media files to Free formats"
>
> First, we don't need to say it's an application, not that it's GNOME
> specific. Surely something like this would be better:
>
> "Simple media converter"
> or
> "Simple conversion to free media formats"
> or
> "Simple media converter using free formats"
>
> The guidelines also don't say if it should be Title Case or if the
> summary should include the application name. If we come to some
> guidelines (or working practices) on this email thread, I'll update the
> wiki page with more details.
>
> It would also be a good idea to have a few "shining examples" for people
> to copy when creating new packages. When we've done that, I'll start
> filing bugs.
>
> Thanks,
>
> Richard.
Guidelines? Maybe, but...

If PackageKit has some troubles with displaying long summaries, you 
should fill bug against PackageKit not against every package with long 
summary

Usually, if I need something, I use yum search keyword and choose what I 
will install thx summary, so I prefer useful and descriptive summary 
against a few words

btw... oggconvert :
A simple GNOME application that converts media files to Free formats

lets see PackageKit :
System daemon that is a DBUS abstraction layer for package management

its even longer... :)



From loganjerry at gmail.com  Thu Nov 20 16:51:51 2008
From: loganjerry at gmail.com (Jerry James)
Date: Thu, 20 Nov 2008 09:51:51 -0700
Subject: source file audit - 2008-11-14
In-Reply-To: <20081119224602.01d369a5@ohm.scrye.com>
References: <20081119170909.29694973@ohm.scrye.com>
	<870180fe0811191637q372240f6w893781e4b0d7fce5@mail.gmail.com>
	<20081119224602.01d369a5@ohm.scrye.com>
Message-ID: <870180fe0811200851r1c6b0273p36cea25a000c2305@mail.gmail.com>

On 2008/11/19 Kevin Fenzi <kevin at scrye.com> wrote:
> On Wed, 19 Nov 2008 17:37:43 -0700
> loganjerry at gmail.com ("Jerry James") wrote:
>
>> On 2008/11/19 Kevin Fenzi <kevin at scrye.com> wrote:
>> > jjames:BADURL:check-0.9.5.tar.gz:check
>>
>> Sure enough, I'm getting an HTTP 403 on this.  Will investigate.

And this one is working today.  Temporary sourceforge hiccup?
-- 
Jerry James
http://loganjerry.googlepages.com/



From jkeating at redhat.com  Thu Nov 20 16:56:12 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 20 Nov 2008 08:56:12 -0800
Subject: [Fedora-spins] Games spin is out for F10
In-Reply-To: <49255228.3040208@kanarip.com>
References: <49255228.3040208@kanarip.com>
Message-ID: <1227200172.28543.649.camel@luminos.localdomain>

On Thu, 2008-11-20 at 13:03 +0100, Jeroen van Meeuwen wrote:
> There has been problems composing this spin for F10-Preview, and there's
> problems popping up real close to release (which is right now). It's
> actually caused by a missing package (simple fix) but the real problem
> is whether the maintainer(s) fix(es) the problem and actually test(s)
> the spin.

I should note that I tried to be the "good guy" and just fix it myself,
however fixing that led to another problem where the initial chroot
created was too small, fixing that led to the whole thing being
oversized and invalid for mkisofs.  That was the final straw.

-- 
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/20081120/0ca313fe/attachment.sig>

From debarshi.ray at gmail.com  Thu Nov 20 17:02:47 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Thu, 20 Nov 2008 22:32:47 +0530
Subject: [Fedora-spins] Games spin is out for F10
In-Reply-To: <1227200172.28543.649.camel@luminos.localdomain>
References: <49255228.3040208@kanarip.com>
	<1227200172.28543.649.camel@luminos.localdomain>
Message-ID: <3170f42f0811200902g148a7f05gdaebfe322b45cd5@mail.gmail.com>

> I should note that I tried to be the "good guy" and just fix it myself,
> however fixing that led to another problem where the initial chroot
> created was too small, fixing that led to the whole thing being
> oversized and invalid for mkisofs.  That was the final straw.

Coincidentally I was playing with it a bit with Rakesh (CC'ed) and we
also hit the same blockade about the small chroot. Maybe Rakesh went a
bit further.

Cheers,
Debarshi



From stickster at gmail.com  Thu Nov 20 17:05:16 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Thu, 20 Nov 2008 12:05:16 -0500
Subject: [Fedora-spins] Games spin is out for F10
In-Reply-To: <1227200172.28543.649.camel@luminos.localdomain>
References: <49255228.3040208@kanarip.com>
	<1227200172.28543.649.camel@luminos.localdomain>
Message-ID: <20081120170516.GA16720@localhost.localdomain>

On Thu, Nov 20, 2008 at 08:56:12AM -0800, Jesse Keating wrote:
> On Thu, 2008-11-20 at 13:03 +0100, Jeroen van Meeuwen wrote:
> > There has been problems composing this spin for F10-Preview, and there's
> > problems popping up real close to release (which is right now). It's
> > actually caused by a missing package (simple fix) but the real problem
> > is whether the maintainer(s) fix(es) the problem and actually test(s)
> > the spin.
> 
> I should note that I tried to be the "good guy" and just fix it myself,
> however fixing that led to another problem where the initial chroot
> created was too small, fixing that led to the whole thing being
> oversized and invalid for mkisofs.  That was the final straw.

It was good of you to try in any case.  Sad that we'll be missing this
spin, but the nice thing about a ~6-month cycle is that it won't be
long before we have the potential to see it again.

-- 
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/20081120/e2f9b92b/attachment.sig>

From subhodip at fedoraproject.org  Thu Nov 20 17:10:36 2008
From: subhodip at fedoraproject.org (subhodip biswas)
Date: Thu, 20 Nov 2008 22:40:36 +0530
Subject: Straw comaintainer needed
Message-ID: <539333cb0811200910j180badb9wce4188c7d93cb4f8@mail.gmail.com>

hi !

A FTBFS bug is assigned against straw for quite a amount of time . I
really didnt able to dedicate the time necessary to fix it .
I will be grateful , if someone co maintains straw and help in fixing the bug .

https://bugzilla.redhat.com/show_bug.cgi?id=465038

-- 
Regards
Subhodip Biswas

GPG key : FAEA34AB
Server : pgp.mit.edu
http://subhodipbiswas.wordpress.com
http:/www.fedoraproject.org/wiki/SubhodipBiswas



From katzj at redhat.com  Thu Nov 20 17:25:59 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 20 Nov 2008 12:25:59 -0500
Subject: requires(post) on coreutils
In-Reply-To: <1227159559.28543.644.camel@luminos.localdomain>
References: <1227159559.28543.644.camel@luminos.localdomain>
Message-ID: <1227201959.13169.40.camel@aglarond.local>

On Wed, 2008-11-19 at 21:39 -0800, Jesse Keating wrote:
> I just attempted to compose the Games spin for Fedora 10, and ran into a
> number of packages that fail their %post scripts due to missing one
> thing or another out of coreutils (such as ln, rm, file, etc..) and it
> has me wondering what might have changed in recent time so that
> coreutils wouldn't be installed earlier in the transaction.  This seems
> like something that would have been noticed before, but maybe it's just
> in the particular package set that the games spin has.

It's actually a pretty common phenomenon related to packagers thinking
they're "always" there because they are except in the case of new
installs.  coreutils is actually surprisingly late in install order and
so there are pretty frequent packages which pop up expecting otherwise
(and there always have been; I've been filing bugs about them for longer
than I like to remember :-)

Jeremy



From hughsient at gmail.com  Thu Nov 20 17:29:39 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 20 Nov 2008 17:29:39 +0000
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227191607.4076.29.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
Message-ID: <1227202179.4076.70.camel@hughsie-laptop>

On Thu, 2008-11-20 at 14:33 +0000, Richard Hughes wrote:
> The packaging guidelines have a single sentence on package summaries:
> https://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description
> 
> "The summary should be a short and concise description of the package"

I've attached a list of packages that are very long or have large number
of words in the summary text. 

Worst affected packages are:

atomix
atop
bouml
cohoba
crash
crash-devel
curlftpfs
ddrescue
devede
DivFix++
dwdiff
dxcc
efax
escape
gens
gens
GLC_Player
gmrun
gpsd-devel
gstreamer-plugins-bad-extras
gtk-sharp2-gapi
htdig-web
khmeros-fonts-handwritten
liblicense-cli
libnjb
libsvm-devel
mod_suphp
nautilus-search-tool
node
perl-Bit-Vector
perl-Carp-Clan
perl-GO-TermFinder
perl-HTTP-BrowserDetect
perl-IPC-Run3
perl-Lingua-EN-Numbers-Ordinate
perl-Object-MultiType
perl-Schedule-Cron-Events
php-pear-PHP-CompatInfo
ppl-gprolog-static
ppl-yap-static
rmap
R-RScaLAPACK
rss2email
smc
smstools
tcldom
tclxml
twolame
wraplinux
xmlsec1
xqilla
xqilla10
yum-remove-with-leaves
yum-rpm-warm-cache

Most important from a desktop point of view (likely to be shown in the
deps dialog) are:

atomix
bouml
cohoba
devede
DivFix++
fslint
gens
gmrun
nautilus-search-tool

Is there an automated way to get the maintainer email address for a
package? Then I can email the maintainers semi-automatically rather than
create ~60 bug reports.

Richard.

-------------- next part --------------
len:63 words:13 package:gens text:'Gens is a win32/unix Sega Genesis / Sega CD / Sega 32X emulator'
len:67 words:13 package:smc text:'2D platform game that uses OpenGL in a style similar to Super Mario'
len:61 words:13 package:gstreamer-plugins-bad-extras text:'Extra GStreamer  bad  plugins (less often used  bad  plugins)'
len:67 words:14 package:devede text:'DeVeDe is a program to create video DVDs and CDs (VCD, sVCD or CVD)'
len:76 words:13 package:twolame text:'TwoLAME is an optimised MPEG Audio Layer 2 encoding library based on tooLAME'
len:67 words:13 package:smc text:'2D platform game that uses OpenGL in a style similar to Super Mario'
len:61 words:13 package:gstreamer-plugins-bad-extras text:'Extra GStreamer  bad  plugins (less often used  bad  plugins)'
len:67 words:14 package:devede text:'DeVeDe is a program to create video DVDs and CDs (VCD, sVCD or CVD)'
len:76 words:13 package:twolame text:'TwoLAME is an optimised MPEG Audio Layer 2 encoding library based on tooLAME'
len:76 words:13 package:atop text:'An advanced interactive monitor to view the load on system and process level'
len:64 words:13 package:perl-Bit-Vector text:'Efficient bit vector, set of integers and  big int  math library'
len:78 words:13 package:ppl-gprolog-static text:'The static archive for the GNU Prolog interface of the Parma Polyhedra Library'
len:70 words:15 package:yum-rpm-warm-cache text:'Yum plugin to access the rpmdb files early to warm up access to the db'
len:67 words:13 package:php-pear-PHP-CompatInfo text:'Find out version and extensions required for a piece of code to run'
len:76 words:14 package:escape text:'A fun puzzle game in the tradition of Adventures of Lolo or Chip's Challenge'
len:76 words:14 package:atomix text:'Little mind game where you have to build molecules out of atoms lying around'
len:75 words:13 package:gmrun text:'Lightweight  Run program  dialog box with search history and tab completion'
len:67 words:13 package:xqilla-devel text:'XQilla is an XQuery and XPath 2.0 library, built on top of Xerces-C'
len:78 words:13 package:ppl-yap-static text:'The static archive for the YAP Prolog interface of the Parma Polyhedra Library'
len:68 words:14 package:rss2email text:'Deliver news from RSS feeds to your smtp server as text or html mail'
len:79 words:14 package:yum-remove-with-leaves text:'Yum plugin to remove dependencies which are no longer used because of a removal'
len:64 words:13 package:perl-IPC-Run3 text:'Run a subprocess in batch mode (a la system) on Unix, Win32, etc'
len:75 words:13 package:curlftpfs text:'CurlFtpFS is a filesystem for accessing FTP hosts based on FUSE and libcurl'
len:67 words:13 package:perl-Object-MultiType text:'Perl Objects as Hash, Array, Scalar, Code and Glob at the same time'
len:79 words:14 package:perl-Lingua-EN-Numbers-Ordinate text:'Perl functions for giving the ordinal form of a number given its cardinal value'
len:65 words:14 package:wraplinux text:'Utility to wrap a Linux kernel and initrd into an ELF or NBI file'
len:79 words:13 package:perl-HTTP-BrowserDetect text:'Determine the Web browser, version, and platform from an HTTP user agent string'
len:62 words:13 package:dwdiff text:'Front end to diff for comparing files on a word per word basis'
len:76 words:14 package:DivFix++ text:'A program to repair broken AVI file streams by rebuilding index part of file'
len:105 words:14 package:xmlsec1-devel text:'Libraries, includes, etc. to develop applications with XML Digital Signatures and XML Encryption support.'
len:63 words:13 package:perl-Carp-Clan text:'Report errors from perspective of caller of a  clan  of modules'
len:73 words:13 package:GLC_Player text:'GLC_Player is an Open Source software used to view 3d models (OBJ Format)'
len:67 words:13 package:xqilla10 text:'XQilla is an XQuery and XPath 2.0 library, built on top of Xerces-C'
len:75 words:13 package:dxcc text:'Small utility which determines the ARRL DXCC entity of a ham radio callsign'
len:87 words:12 package:R-RScaLAPACK text:'An interface to perform parallel computation on linear algebra problems using ScaLAPACK'
len:81 words:12 package:crash text:'crash utility for live systems; netdump, diskdump, kdump, LKCD or mcore dumpfiles'
len:68 words:13 package:ddrescue text:'Data recovery tool trying hard to rescue data in case of read errors'
len:78 words:14 package:tcldom text:'TclDOM is a package that provides a DOM binding for the Tcl scripting language'
len:57 words:13 package:efax text:'A program for faxing using a Class 1, 2 or 2.0 fax modem.'
len:77 words:16 package:nautilus-search-tool text:'A Nautilus extension to put  Search for Files  on the context menu of folders'
len:67 words:13 package:xqilla10-devel text:'XQilla is an XQuery and XPath 2.0 library, built on top of Xerces-C'
len:70 words:13 package:htdig-web text:'Scripts and HTML code needed for using ht://Dig as a web search engine'
len:76 words:13 package:smstools text:'Tools to send and receive short messages through GSM modems or mobile phones'
len:76 words:14 package:xmlsec1 text:'Library providing support for  XML Signature  and  XML Encryption  standards'
len:75 words:13 package:libnjb text:'A software library for talking to the Creative Nomad Jukeboxes and Dell DJs'
len:80 words:13 package:mod_suphp text:'An apache2 module for executing PHP scripts with the permissions of their owners'
len:76 words:13 package:tclxml text:'TclXML is a package that provides XML parsing for the Tcl scripting language'
len:62 words:13 package:perl-Schedule-Cron-Events text:'Take a line from a crontab and find out when events will occur'
len:71 words:14 package:libsvm-devel text:'Header file, object file, and source files of libsvm in C, C++ and Java'
len:119 words:21 package:gtk-sharp2-gapi text:'Glib and GObject C source parser and C generator for the creation and maintenance of managed bindings for Mono and .NET'
len:81 words:12 package:crash-devel text:'crash utility for live systems; netdump, diskdump, kdump, LKCD or mcore dumpfiles'
len:78 words:14 package:cohoba text:'Cohoba is a GNOME interface for Telepathy. It aims to be innovative and simple'
len:79 words:14 package:node text:'Simple node front end, modelled after the node shells of TheNet and G8BPQ nodes'
len:78 words:16 package:rmap text:'Rmap is a package that is able to generate images of the earth from a distance'
len:75 words:13 package:perl-GO-TermFinder text:'Identify GO nodes that annotate a group of genes with a significant p-value'
len:76 words:15 package:bouml text:'UML2 tool box to specify and generate code in C++, Java, IDL, PHP and Python'
len:69 words:14 package:liblicense-cli text:'CLI tool for choosing a user default license or the license of a file'
len:79 words:13 package:khmeros-fonts-handwritten text:'Handwritten Khmer font set created by Danh Hong of the Cambodian Open Institute'
len:69 words:14 package:gpsd-devel text:'Client libraries in C and Python for talking to a running gpsd or GPS'
len:67 words:13 package:xqilla text:'XQilla is an XQuery and XPath 2.0 library, built on top of Xerces-C'
len:63 words:13 package:gens text:'Gens is a win32/unix Sega Genesis / Sega CD / Sega 32X emulator'

From skvidal at fedoraproject.org  Thu Nov 20 17:40:25 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 20 Nov 2008 12:40:25 -0500 (EST)
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227202179.4076.70.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227202179.4076.70.camel@hughsie-laptop>
Message-ID: <alpine.LFD.2.00.0811201239140.16994@localhost.localdomain>



On Thu, 20 Nov 2008, Richard Hughes wrote:

> On Thu, 2008-11-20 at 14:33 +0000, Richard Hughes wrote:
>> The packaging guidelines have a single sentence on package summaries:
>> https://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description
>>
>> "The summary should be a short and concise description of the package"
>
> I've attached a list of packages that are very long or have large number
> of words in the summary text.
>
> Worst affected packages are:
>
> atomix
> atop
> bouml
> cohoba
> crash
> crash-devel
> curlftpfs
> ddrescue
> devede
> DivFix++
> dwdiff
> dxcc
> efax
> escape
> gens
> gens
> GLC_Player
> gmrun
> gpsd-devel
> gstreamer-plugins-bad-extras
> gtk-sharp2-gapi
> htdig-web
> khmeros-fonts-handwritten
> liblicense-cli
> libnjb
> libsvm-devel
> mod_suphp
> nautilus-search-tool
> node
> perl-Bit-Vector
> perl-Carp-Clan
> perl-GO-TermFinder
> perl-HTTP-BrowserDetect
> perl-IPC-Run3
> perl-Lingua-EN-Numbers-Ordinate
> perl-Object-MultiType
> perl-Schedule-Cron-Events
> php-pear-PHP-CompatInfo
> ppl-gprolog-static
> ppl-yap-static
> rmap
> R-RScaLAPACK
> rss2email
> smc
> smstools
> tcldom
> tclxml
> twolame
> wraplinux
> xmlsec1
> xqilla
> xqilla10
> yum-remove-with-leaves
> yum-rpm-warm-cache
>
> Most important from a desktop point of view (likely to be shown in the
> deps dialog) are:
>
> atomix
> bouml
> cohoba
> devede
> DivFix++
> fslint
> gens
> gmrun
> nautilus-search-tool
>
> Is there an automated way to get the maintainer email address for a
> package? Then I can email the maintainers semi-automatically rather than
> create ~60 bug reports.

email to:

  pkgname-owner at fedoraproject.org


-sv



From hughsient at gmail.com  Thu Nov 20 17:40:29 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 20 Nov 2008 17:40:29 +0000
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <49259275.3000201@gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<20081120145328.GB2410@yoda.jdub.homelinux.org>
	<20081120145628.GB28357@nostromo.devel.redhat.com>
	<1227193973.3752.858.camel@beck.corsepiu.local>
	<1227194392.4076.31.camel@hughsie-laptop> <49258DA7.5050808@gmail.com>
	<1227198578.4076.37.camel@hughsie-laptop> <49259275.3000201@gmail.com>
Message-ID: <1227202829.4076.72.camel@hughsie-laptop>

On Thu, 2008-11-20 at 08:38 -0800, Toshio Kuratomi wrote:
> Okay.  Please fill in other examples so packagers and reviewers can
> get
> a feel for what to cut and when it's good to depart from the general
> rules and put it on the wiki under PackagingDrafts.  Then add it to
> the
> list of things for the Packaging Committee to discuss.
> 
> We can link it from this portion of the full Guidelines:
> http://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description

Okay, I'll do that when we've got more agreement on the wording:

Many GUI packaging tools make the summary more prominent than the
package name. The summary is often a better description for the end user
when making a decision about installing. To make the user's experience
better here, we try to have short succinct summaries that don't repeat
information in the name.

For instance, the following are over long, or repeat the program name:

* System daemon that is a DBUS abstraction layer for package management
* XQilla is an XQuery and XPath 2.0 library, built on top of Xerces-C
* DeVeDe is a program to create video DVDs and CDs (VCD, sVCD or CVD)

The following would be good replacements:

* Package management framework
* XQuery and XPath 2.0 library
* Create video DVDs and CDs

How does that sound? Anyone got any better words?

Richard.




From mschwendt at gmail.com  Thu Nov 20 17:44:45 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 20 Nov 2008 18:44:45 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <49259472.7010103@redhat.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<49259472.7010103@redhat.com>
Message-ID: <20081120184445.afbf6777.mschwendt@gmail.com>

On Thu, 20 Nov 2008 17:46:42 +0100, Michal Hlavinka wrote:

> Usually, if I need something, I use yum search keyword and choose what I 
> will install thx summary, so I prefer useful and descriptive summary 
> against a few words

"yum search" also searches the package %description. And the description
is the place where to be much more verbose than in the summary. The
%summary is not made for searching, but for enabling the installer and
packaging tools to to display a brief and concise package description or a
list thereof. That means, put a few relevant keywords in the summary
(newspaper headline-style at most), but avoid long/complete sentences as
often as possible. That also makes it easier to fit into one line.
 
> btw... oggconvert :
> A simple GNOME application that converts media files to Free formats

"GNOME media file converter" would be enough to raise user's interest
in clicking to look up the longer description.

> lets see PackageKit :
> System daemon that is a DBUS abstraction layer for package management
> 
> its even longer... :)

Because it tries to squeeze too many low-level details into the
summary instead of expanding in the description.



From mtasaka at ioa.s.u-tokyo.ac.jp  Thu Nov 20 17:45:20 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Fri, 21 Nov 2008 02:45:20 +0900
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227202179.4076.70.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227202179.4076.70.camel@hughsie-laptop>
Message-ID: <4925A230.2020308@ioa.s.u-tokyo.ac.jp>

Richard Hughes wrote, at 11/21/2008 02:29 AM +9:00:
> On Thu, 2008-11-20 at 14:33 +0000, Richard Hughes wrote:
>> The packaging guidelines have a single sentence on package summaries:
>> https://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description
>>
>> "The summary should be a short and concise description of the package"
> 
> I've attached a list of packages that are very long or have large number
> of words in the summary text. 

Current rpmlint complains if %description has more than "79 characters".
i.e. The packages you listed as worst all meet rpmlint criterion.

If you have a reasonable reason you want to have these packages modified,
file against rpmlint first with showing good reason, otherwise your bug
reports will surely confuse many reviewers and maintainers.

Mamoru



From mschwendt at gmail.com  Thu Nov 20 17:47:18 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 20 Nov 2008 18:47:18 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227202829.4076.72.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<20081120145328.GB2410@yoda.jdub.homelinux.org>
	<20081120145628.GB28357@nostromo.devel.redhat.com>
	<1227193973.3752.858.camel@beck.corsepiu.local>
	<1227194392.4076.31.camel@hughsie-laptop>
	<49258DA7.5050808@gmail.com>
	<1227198578.4076.37.camel@hughsie-laptop>
	<49259275.3000201@gmail.com>
	<1227202829.4076.72.camel@hughsie-laptop>
Message-ID: <20081120184718.7e2262cd.mschwendt@gmail.com>

On Thu, 20 Nov 2008 17:40:29 +0000, Richard Hughes wrote:

> For instance, the following are over long, or repeat the program name:
> 
> * System daemon that is a DBUS abstraction layer for package management
> * XQilla is an XQuery and XPath 2.0 library, built on top of Xerces-C
> * DeVeDe is a program to create video DVDs and CDs (VCD, sVCD or CVD)
> 
> The following would be good replacements:
> 
> * Package management framework
> * XQuery and XPath 2.0 library
> * Create video DVDs and CDs
> 
> How does that sound? Anyone got any better words?

Sounds good. I think you've understood the purpose of %summary. :)



From james at fedoraproject.org  Thu Nov 20 17:47:51 2008
From: james at fedoraproject.org (James Antill)
Date: Thu, 20 Nov 2008 12:47:51 -0500
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227191607.4076.29.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
Message-ID: <1227203271.4355.219.camel@code.and.org>

On Thu, 2008-11-20 at 14:33 +0000, Richard Hughes wrote:
> The packaging guidelines have a single sentence on package summaries:
> https://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description
> 
> "The summary should be a short and concise description of the package"
> 
> Broken packages are a problem as PackageKit shows the summary first (in
> bold) in preference to the package name. This is by design.

 What is the rationale for this design? Just a guess that it's better?

> Quite a lot of packages have summary text that is overly verbose, and
> this makes the GUI and output from pkcon look rubbish.
> 
> For instance, I've filed
> https://bugzilla.redhat.com/show_bug.cgi?id=472365 where the oggconvert
> package has a summary of:
> 
> "A simple GNOME application that converts media files to Free formats"
> 
> First, we don't need to say it's an application, not that it's GNOME
> specific. Surely something like this would be better:
> 
> "Simple media converter"
> or
> "Simple conversion to free media formats"
> or
> "Simple media converter using free formats"

 Why is "simple" a useful word, but GNOME isn't? For someone using a
GNOME desktop I could see the later being much more helpful.
 Also, as someone else mentioned:

PackageKit.x86_64 : System daemon that is a DBUS abstraction layer for package
                  : management

..."abstraction layer" seems more wordy than needed, also "system
daemon" seems redundant:

PackageKit.x86_64 : DBUS daemon for package management

...a list of stop words like that, might be useful ... or even better
someone should get a librarian involved in Fedora :)

-- 
James Antill <james at fedoraproject.org>
Fedora



From cra at WPI.EDU  Thu Nov 20 18:00:07 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 20 Nov 2008 13:00:07 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <20081114200842.GD1142545@hiwaay.net>
References: <20081113160203.GD1538120@hiwaay.net>
	<1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<20081114200842.GD1142545@hiwaay.net>
Message-ID: <20081120180007.GO24297@angus.ind.WPI.EDU>

On Fri, Nov 14, 2008 at 02:08:42PM -0600, Chris Adams wrote:
> I do care about the desktop, and I use NM on my notebook (not on my
> workstations that have a single interface with a single static IP).  I
> have to shut it down on my notebook sometimes because it doesn't handle
> some of my normal usage (multiple wired NICs, wired and wireless to
> different networks, etc.).

Why do you have to shutdown NM sometimes?  I use NM with multiple 
wired NICs, and wired + wireless to different networks without 
problem.



From galibert at pobox.com  Thu Nov 20 18:13:23 2008
From: galibert at pobox.com (Olivier Galibert)
Date: Thu, 20 Nov 2008 19:13:23 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227202829.4076.72.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<20081120145328.GB2410@yoda.jdub.homelinux.org>
	<20081120145628.GB28357@nostromo.devel.redhat.com>
	<1227193973.3752.858.camel@beck.corsepiu.local>
	<1227194392.4076.31.camel@hughsie-laptop>
	<49258DA7.5050808@gmail.com>
	<1227198578.4076.37.camel@hughsie-laptop>
	<49259275.3000201@gmail.com>
	<1227202829.4076.72.camel@hughsie-laptop>
Message-ID: <20081120181323.GA2713@dspnet.fr.eu.org>

On Thu, Nov 20, 2008 at 05:40:29PM +0000, Richard Hughes wrote:
> For instance, the following are over long, or repeat the program name:
> 
> * System daemon that is a DBUS abstraction layer for package management
> * XQilla is an XQuery and XPath 2.0 library, built on top of Xerces-C
> * DeVeDe is a program to create video DVDs and CDs (VCD, sVCD or CVD)
> 
> The following would be good replacements:
> 
> * Package management framework
> * XQuery and XPath 2.0 library
> * Create video DVDs and CDs
> 
> How does that sound? Anyone got any better words?

For XQilla the "Xerces-C" part is a first-order discrimination
information because it tells you whether you will be able to use the
library.  You can still shorten it to "XQuery and XPath 2.0 library
for Xerces-C".  I mean, it could be "java", "python", or
"lambda-prolog" instead, and that changes everything :-)

  OG.



From pemboa at gmail.com  Thu Nov 20 18:16:42 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 20 Nov 2008 12:16:42 -0600
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227203271.4355.219.camel@code.and.org>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227203271.4355.219.camel@code.and.org>
Message-ID: <16de708d0811201016y6f351c0u1ffd8d9b61a36291@mail.gmail.com>

On Thu, Nov 20, 2008 at 11:47 AM, James Antill <james at fedoraproject.org> wrote:
> On Thu, 2008-11-20 at 14:33 +0000, Richard Hughes wrote:
>> The packaging guidelines have a single sentence on package summaries:
>> https://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description
>>
>> "The summary should be a short and concise description of the package"
>>
>> Broken packages are a problem as PackageKit shows the summary first (in
>> bold) in preference to the package name. This is by design.
>
>  What is the rationale for this design? Just a guess that it's better?
>
>> Quite a lot of packages have summary text that is overly verbose, and
>> this makes the GUI and output from pkcon look rubbish.
>>
>> For instance, I've filed
>> https://bugzilla.redhat.com/show_bug.cgi?id=472365 where the oggconvert
>> package has a summary of:
>>
>> "A simple GNOME application that converts media files to Free formats"
>>
>> First, we don't need to say it's an application, not that it's GNOME
>> specific. Surely something like this would be better:
>>
>> "Simple media converter"
>> or
>> "Simple conversion to free media formats"
>> or
>> "Simple media converter using free formats"
>
>  Why is "simple" a useful word, but GNOME isn't? For someone using a
> GNOME desktop I could see the later being much more helpful.
>  Also, as someone else mentioned:

Well a user may want a simple tool, as opposed to an advanced tool.
And for said user, Gnome may be irrelevant.

Also, uses GTK doesn't necessarily mean Gnome. However, if a package
is going to pull in Gnome libs, would be nice to know that in the
summary.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From ajax at redhat.com  Thu Nov 20 18:18:59 2008
From: ajax at redhat.com (Adam Jackson)
Date: Thu, 20 Nov 2008 13:18:59 -0500
Subject: source file audit - 2008-11-14
In-Reply-To: <20081119170909.29694973@ohm.scrye.com>
References: <20081119170909.29694973@ohm.scrye.com>
Message-ID: <1227205139.31982.619.camel@atropine.boston.devel.redhat.com>

On Wed, 2008-11-19 at 17:09 -0700, Kevin Fenzi wrote:

> ajax:BADURL:powertop-1.10.tar.gz:powertop

Fixed, thank you upstream for breaking your URL scheme.

> xgl-maint:BADURL:dri2proto-1.99.1.tar.bz2:xorg-x11-proto-devel

Fixed.

- 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/20081120/e4978ab1/attachment.sig>

From jwboyer at gmail.com  Thu Nov 20 18:18:16 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 20 Nov 2008 13:18:16 -0500
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081120162850.GA30445@nostromo.devel.redhat.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<20081120145328.GB2410@yoda.jdub.homelinux.org>
	<20081120145628.GB28357@nostromo.devel.redhat.com>
	<20081120161952.GC2410@yoda.jdub.homelinux.org>
	<20081120162850.GA30445@nostromo.devel.redhat.com>
Message-ID: <20081120181816.GA4059@yoda.jdub.homelinux.org>

On Thu, Nov 20, 2008 at 11:28:50AM -0500, Bill Nottingham wrote:
>Josh Boyer (jwboyer at gmail.com) said: 
>> >I'm not sure this scales across 5000 packages. So it would be good
>> >to have at least *something* in the guidelines.
>> 
>> You're assuming that all 5000 packages need fixing.  I doubt that's
>> the case.
>
>No, but it's not something you can easily automate (unlike
>FTBFS, or broken deps.)
>
>> Also, the bugs need to be filed either way.  So the scaling argument
>> still applies and adding a guideline for this is really just unneeded
>> work...
>
>If you get it fixed in the guidelines and at the review point, you
>eliminate having to scan & file all those bugs later - always fix
>issues as early as possible.

The guidelines already say 'brief'.  Quantifying what that means is all
that a new guideline would be doing.

And you're also assuming that packages strictly adhere to the guidelines
after they are reviewed, but that is a whole different can of worms.

josh



From jkeating at redhat.com  Thu Nov 20 18:27:22 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 20 Nov 2008 10:27:22 -0800
Subject: requires(post) on coreutils
In-Reply-To: <1227201959.13169.40.camel@aglarond.local>
References: <1227159559.28543.644.camel@luminos.localdomain>
	<1227201959.13169.40.camel@aglarond.local>
Message-ID: <1227205642.28543.651.camel@luminos.localdomain>

On Thu, 2008-11-20 at 12:25 -0500, Jeremy Katz wrote:
> It's actually a pretty common phenomenon related to packagers thinking
> they're "always" there because they are except in the case of new
> installs.  coreutils is actually surprisingly late in install order and
> so there are pretty frequent packages which pop up expecting otherwise
> (and there always have been; I've been filing bugs about them for longer
> than I like to remember :-)

Fair enough.  I didn't see any such messages in my other installs, so
these packages are probably far enough off the radar that this isn't
typically seen.

Would this be something to check for during package review?  Init a
chroot @core <package> listed in the init call and see what errors pop
up?

-- 
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/20081120/b192520d/attachment.sig>

From notting at redhat.com  Thu Nov 20 18:33:06 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 20 Nov 2008 13:33:06 -0500
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227202829.4076.72.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<20081120145328.GB2410@yoda.jdub.homelinux.org>
	<20081120145628.GB28357@nostromo.devel.redhat.com>
	<1227193973.3752.858.camel@beck.corsepiu.local>
	<1227194392.4076.31.camel@hughsie-laptop>
	<49258DA7.5050808@gmail.com>
	<1227198578.4076.37.camel@hughsie-laptop>
	<49259275.3000201@gmail.com>
	<1227202829.4076.72.camel@hughsie-laptop>
Message-ID: <20081120183306.GA32047@nostromo.devel.redhat.com>

Richard Hughes (hughsient at gmail.com) said: 
> The following would be good replacements:
> 
> * Package management framework
> * XQuery and XPath 2.0 library
> * Create video DVDs and CDs
> 
> How does that sound? Anyone got any better words?

My one concern is that with something like the last one, you're likely
to run into summary collision.

Bill



From pemboa at gmail.com  Thu Nov 20 18:36:42 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 20 Nov 2008 12:36:42 -0600
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081120183306.GA32047@nostromo.devel.redhat.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<20081120145328.GB2410@yoda.jdub.homelinux.org>
	<20081120145628.GB28357@nostromo.devel.redhat.com>
	<1227193973.3752.858.camel@beck.corsepiu.local>
	<1227194392.4076.31.camel@hughsie-laptop> <49258DA7.5050808@gmail.com>
	<1227198578.4076.37.camel@hughsie-laptop> <49259275.3000201@gmail.com>
	<1227202829.4076.72.camel@hughsie-laptop>
	<20081120183306.GA32047@nostromo.devel.redhat.com>
Message-ID: <16de708d0811201036p8f4989qe4d840ef7ad38d34@mail.gmail.com>

On Thu, Nov 20, 2008 at 12:33 PM, Bill Nottingham <notting at redhat.com> wrote:
> Richard Hughes (hughsient at gmail.com) said:
>> The following would be good replacements:
>>
>> * Package management framework
>> * XQuery and XPath 2.0 library
>> * Create video DVDs and CDs
>>
>> How does that sound? Anyone got any better words?
>
> My one concern is that with something like the last one, you're likely
> to run into summary collision.


True. It isn't immediately clear to me if that is a bad thing though.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From rcritten at redhat.com  Thu Nov 20 18:37:12 2008
From: rcritten at redhat.com (Rob Crittenden)
Date: Thu, 20 Nov 2008 13:37:12 -0500
Subject: ipa conflicts with mod_ssl (F9)
In-Reply-To: <20081120134655.GB19614@redhat.com>
References: <gg3pj6$dhb$1@ger.gmane.org> <20081120134655.GB19614@redhat.com>
Message-ID: <4925AE58.3020509@redhat.com>

Daniel P. Berrange wrote:
> On Thu, Nov 20, 2008 at 08:44:06AM -0500, Neal Becker wrote:
>> sudo yum install ipa-server ipa-client ipa-admintools
>> ...
>> ipa-server-1.2.0-1.fc9.x86_64 from updates-newkey has depsolving problems
>>   --> ipa-server conflicts with mod_ssl
>> Error: ipa-server conflicts with mod_ssl
> 
> IPA requires  mod_nss, and mod_nss & mod_ssl are unable to co-exist
> in apache, so IPA has a conflict with mod_ssl. That said, its a little
> od that the Conflicts: is not in the mod_nss RPM itself.

mod_nss and mod_ssl can co-exist ok. The problem is when you also want 
to use mod_proxy. mod_proxy doesn't have a generic way to register SSL 
callbacks. It has a single API. Both mod_ssl and mod_nss can register 
those callbacks but mod_nss will defer to mod_ssl if it is already 
loaded. Hence if you are using mod_nss and mod_proxy together, as IPA 
does, then mod_ssl will conflict.

And unfortunately it is the mere loading of mod_ssl that registers these 
functions, so even having it installed, even if you aren't using it, 
will cause problems. Simply renaming ssl.conf isn't enough either 
because the next time that mod_ssl gets updated a new ssl.conf will be 
written by rpm, causing a previously working system to mysteriously break.

The Conflict isn't ideal but it's the only sure-fire way we've found.

rob



From clumens at redhat.com  Thu Nov 20 18:37:14 2008
From: clumens at redhat.com (Chris Lumens)
Date: Thu, 20 Nov 2008 13:37:14 -0500
Subject: My roadmap for a better Fedora
In-Reply-To: <492493AA.30108@gmail.com>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<20081119221544.GE31216@localhost.localdomain>
	<492493AA.30108@gmail.com>
Message-ID: <20081120183713.GF31216@localhost.localdomain>

> Except for fedora-specific quirks, fixing should be an upstream issue.  

We ARE upstream for plenty of things, and we could definitely use bug
fixing help on them.

- Chris



From cdahlin at redhat.com  Thu Nov 20 18:46:31 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Thu, 20 Nov 2008 13:46:31 -0500
Subject: requires(post) on coreutils
In-Reply-To: <1227201959.13169.40.camel@aglarond.local>
References: <1227159559.28543.644.camel@luminos.localdomain>
	<1227201959.13169.40.camel@aglarond.local>
Message-ID: <4925B087.6000501@redhat.com>

Jeremy Katz wrote:
> On Wed, 2008-11-19 at 21:39 -0800, Jesse Keating wrote:
>   
>> I just attempted to compose the Games spin for Fedora 10, and ran into a
>> number of packages that fail their %post scripts due to missing one
>> thing or another out of coreutils (such as ln, rm, file, etc..) and it
>> has me wondering what might have changed in recent time so that
>> coreutils wouldn't be installed earlier in the transaction.  This seems
>> like something that would have been noticed before, but maybe it's just
>> in the particular package set that the games spin has.
>>     
>
> It's actually a pretty common phenomenon related to packagers thinking
> they're "always" there because they are except in the case of new
> installs.  coreutils is actually surprisingly late in install order and
> so there are pretty frequent packages which pop up expecting otherwise
> (and there always have been; I've been filing bugs about them for longer
> than I like to remember :-)
>
> Jeremy
>
>   
We can look at binaries to see what libs they need, can we not look at 
%post scripts and figure out if coreutils is required?

--CjD



From mschwendt at gmail.com  Thu Nov 20 18:52:40 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 20 Nov 2008 19:52:40 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <16de708d0811201016y6f351c0u1ffd8d9b61a36291@mail.gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227203271.4355.219.camel@code.and.org>
	<16de708d0811201016y6f351c0u1ffd8d9b61a36291@mail.gmail.com>
Message-ID: <20081120195240.a132f4bd.mschwendt@gmail.com>

On Thu, 20 Nov 2008 12:16:42 -0600, Arthur Pemberton wrote:

> >> Quite a lot of packages have summary text that is overly verbose, and
> >> this makes the GUI and output from pkcon look rubbish.
> >>
> >> For instance, I've filed
> >> https://bugzilla.redhat.com/show_bug.cgi?id=472365 where the oggconvert
> >> package has a summary of:
> >>
> >> "A simple GNOME application that converts media files to Free formats"
> >>
> >> First, we don't need to say it's an application, not that it's GNOME
> >> specific. Surely something like this would be better:
> >>
> >> "Simple media converter"
> >> or
> >> "Simple conversion to free media formats"
> >> or
> >> "Simple media converter using free formats"
> >
> >  Why is "simple" a useful word, but GNOME isn't? For someone using a
> > GNOME desktop I could see the later being much more helpful.
> >  Also, as someone else mentioned:
> 
> Well a user may want a simple tool, as opposed to an advanced tool.
> And for said user, Gnome may be irrelevant.

This is splitting-hairs. A user with special requirements (= low resource
usage, short dependency chain) could query details about a package or
attempt installation and stop as soon as the total size is known.  Btw, an
application could be simple and still use various frameworks which result
in a long dependency chain.

> Also, uses GTK doesn't necessarily mean Gnome. However, if a package
> is going to pull in Gnome libs, would be nice to know that in the
> summary.

It's a pain to maintain such summaries, though. Imagine, first it uses a
standalone library. Later the library is developed further and enhanced
to communicate with desktop services.

It's much more important to sum up what a package does than to sum up
what frameworks it is built with. Details can go into description blocks
and may be examined with package resolvers.



From katzj at redhat.com  Thu Nov 20 18:53:47 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 20 Nov 2008 13:53:47 -0500
Subject: requires(post) on coreutils
In-Reply-To: <4925B087.6000501@redhat.com>
References: <1227159559.28543.644.camel@luminos.localdomain>
	<1227201959.13169.40.camel@aglarond.local>
	<4925B087.6000501@redhat.com>
Message-ID: <1227207227.13169.43.camel@aglarond.local>

On Thu, 2008-11-20 at 13:46 -0500, Casey Dahlin wrote:
> Jeremy Katz wrote:
> > On Wed, 2008-11-19 at 21:39 -0800, Jesse Keating wrote:
> >> I just attempted to compose the Games spin for Fedora 10, and ran into a
> >> number of packages that fail their %post scripts due to missing one
> >> thing or another out of coreutils (such as ln, rm, file, etc..) and it
> >> has me wondering what might have changed in recent time so that
> >> coreutils wouldn't be installed earlier in the transaction.  This seems
> >> like something that would have been noticed before, but maybe it's just
> >> in the particular package set that the games spin has.
> >
> > It's actually a pretty common phenomenon related to packagers thinking
> > they're "always" there because they are except in the case of new
> > installs.  coreutils is actually surprisingly late in install order and
> > so there are pretty frequent packages which pop up expecting otherwise
> > (and there always have been; I've been filing bugs about them for longer
> > than I like to remember :-)
> >   
> We can look at binaries to see what libs they need, can we not look at 
> %post scripts and figure out if coreutils is required?

Scripts (assuming not using a different interpreter) are run via bash
which means that in theory you could use bash --rpm-requires.  But that
has a lot of holes and problems

Jeremy



From ivazqueznet at gmail.com  Thu Nov 20 18:55:43 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Thu, 20 Nov 2008 13:55:43 -0500
Subject: ipa conflicts with mod_ssl (F9)
In-Reply-To: <4925AE58.3020509@redhat.com>
References: <gg3pj6$dhb$1@ger.gmane.org> <20081120134655.GB19614@redhat.com>
	<4925AE58.3020509@redhat.com>
Message-ID: <1227207343.736.138.camel@ignacio.lan>

On Thu, 2008-11-20 at 13:37 -0500, Rob Crittenden wrote:
> mod_nss and mod_ssl can co-exist ok. The problem is when you also want 
> to use mod_proxy. mod_proxy doesn't have a generic way to register SSL 
> callbacks. It has a single API. Both mod_ssl and mod_nss can register 
> those callbacks but mod_nss will defer to mod_ssl if it is already 
> loaded.

Is there any advantage in mod_proxy using mod_ssl versus mod_nss?

-- 
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/20081120/ace4cb04/attachment.sig>

From cdahlin at redhat.com  Thu Nov 20 18:57:02 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Thu, 20 Nov 2008 13:57:02 -0500
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
In-Reply-To: <7deeb2190ab5fc7bff30a343cc9e5c49.squirrel@arekh.dyndns.org>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>	<6aufv5xi4u.ln2@ppp1053.in.ipex.cz>
	<7deeb2190ab5fc7bff30a343cc9e5c49.squirrel@arekh.dyndns.org>
Message-ID: <4925B2FE.2030408@redhat.com>

Nicolas Mailhot wrote:
> Le Jeu 20 novembre 2008 12:29, Matej Cepl a ?crit :
>   
>> On 2008-11-19, 22:47 GMT, Arthur Pemberton wrote:
>>     
>>> There are several competing products, and I doubt we engineer
>>> type people use it "just because". I'm also assuming that we
>>> use it for reasons other than because of RedHat.
>>>       
>> Well, to make your list shorter (i.e., with one item):
>>
>> * To be able to support number of products, components, users,
>>   hits per second as Bugzilla does. Problem I heard of all
>>   competing products (trac, jira, etc.) is that they are lovely
>>   when you are talking about one project with few components, but
>>   when you get to clustering databases and similar magic, all of
>>   them fail pretty badly.
>> * of course, open source -- just to be safe that there isn't some
>>   Microsoft/Oracle/whatever closed source thing, which can manage
>>   it.
>>     
>
> Add to this
> - feature completeness
>   

True, but kind of redundant. This thread seems purposed to define what 
"feature completeness" means for us.

> - familiar UI
>   

I've always hated these sorts of requirements. "Its wrong, but we should 
keep it because its always been wrong." WTF?! Let them adapt and 
survive. If we were always worried about this sort of thing we'd still 
be using Windows, and most of the reason Windows is crap largely because 
of its insistence on stone-age-compliance.

> - integration with upstream issue trackers (which are often bugzilla too)
>
>   

Does Bugzilla really do much in this regard? It doesn't seem to. 
Launchpad is supposed to grow good cross-site integration features just 
before it goes open source, but we've been waiting on both of those 
things for awhile now (and also Launchpad sucks. A lot.) Either way I 
think a new bug tracker would be an opportunity to improve on this point.

> For all its cranks bugzilla is familiar to a lot of bug reporters that
> use all the features added over time.
>
> Any replacement must be at least as feature-full as bugzilla (not
> simpler because it forgets to do some stuff) and offer a bugzilla-like
> mode for existing reporters that do not have the time to learn yet
> another reporting UI.
>
>   
I'll add another bulletpoint.
- Must be something we can talk RHEL in to using.

Fedora and RHEL need to be in the same bug tracker. That's probably the 
biggest obstacle.

--CJD



From walters at verbum.org  Thu Nov 20 18:56:24 2008
From: walters at verbum.org (Colin Walters)
Date: Thu, 20 Nov 2008 13:56:24 -0500
Subject: requires(post) on coreutils
In-Reply-To: <4925B087.6000501@redhat.com>
References: <1227159559.28543.644.camel@luminos.localdomain>
	<1227201959.13169.40.camel@aglarond.local>
	<4925B087.6000501@redhat.com>
Message-ID: <faa16b610811201056p565b8488q6214731bba98c61b@mail.gmail.com>

On Thu, Nov 20, 2008 at 1:46 PM, Casey Dahlin <cdahlin at redhat.com> wrote:
>
>
> We can look at binaries to see what libs they need, can we not look at %post
> scripts and figure out if coreutils is required?

Or have a two phase install, one where we put the minimum OS down, and
the second where we install your apps.  Come on - coreutils isn't an
addon package.



From mschwendt at gmail.com  Thu Nov 20 18:57:11 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 20 Nov 2008 19:57:11 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081120183306.GA32047@nostromo.devel.redhat.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<20081120145328.GB2410@yoda.jdub.homelinux.org>
	<20081120145628.GB28357@nostromo.devel.redhat.com>
	<1227193973.3752.858.camel@beck.corsepiu.local>
	<1227194392.4076.31.camel@hughsie-laptop>
	<49258DA7.5050808@gmail.com>
	<1227198578.4076.37.camel@hughsie-laptop>
	<49259275.3000201@gmail.com>
	<1227202829.4076.72.camel@hughsie-laptop>
	<20081120183306.GA32047@nostromo.devel.redhat.com>
Message-ID: <20081120195711.e68d8926.mschwendt@gmail.com>

On Thu, 20 Nov 2008 13:33:06 -0500, Bill Nottingham wrote:

> Richard Hughes said: 
> > The following would be good replacements:
> > 
> > * Package management framework
> > * XQuery and XPath 2.0 library
> > * Create video DVDs and CDs
> > 
> > How does that sound? Anyone got any better words?
> 
> My one concern is that with something like the last one, you're likely
> to run into summary collision.

Really? In lists where %name and %summary are displayed next to eachother?

  devede : Create video DVDs and CDs

instead of:

  devede : DeVeDe is a program to create video DVDs and CDs (VCD, sVCD or CVD)



From hughsient at gmail.com  Thu Nov 20 17:24:43 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 20 Nov 2008 17:24:43 +0000
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <49259472.7010103@redhat.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<49259472.7010103@redhat.com>
Message-ID: <1227201883.4076.64.camel@hughsie-laptop>

On Thu, 2008-11-20 at 17:46 +0100, Michal Hlavinka wrote:
> If PackageKit has some troubles with displaying long summaries, you 
> should fill bug against PackageKit not against every package with long 
> summary

Ohh, it's not got a problem with long names (well, the web plugin has,
but that's a design problem) -- it's mainly that different packages
treat the summary as different things and are overly verbose.

> lets see PackageKit :
> System daemon that is a DBUS abstraction layer for package management
> 
> its even longer... :)

Guilty as charged. I've fixed up the name now.

Richard.




From ivazqueznet at gmail.com  Thu Nov 20 18:58:46 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Thu, 20 Nov 2008 13:58:46 -0500
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227202829.4076.72.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<20081120145328.GB2410@yoda.jdub.homelinux.org>
	<20081120145628.GB28357@nostromo.devel.redhat.com>
	<1227193973.3752.858.camel@beck.corsepiu.local>
	<1227194392.4076.31.camel@hughsie-laptop> <49258DA7.5050808@gmail.com>
	<1227198578.4076.37.camel@hughsie-laptop> <49259275.3000201@gmail.com>
	<1227202829.4076.72.camel@hughsie-laptop>
Message-ID: <1227207526.736.142.camel@ignacio.lan>

On Thu, 2008-11-20 at 17:40 +0000, Richard Hughes wrote:
> * Create video DVDs and CDs

This is a verb phrase. Summaries should probably be a noun phrase:

* Simple video DVD and CD authoring software

-- 
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/20081120/9f803e05/attachment.sig>

From cdahlin at redhat.com  Thu Nov 20 19:01:37 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Thu, 20 Nov 2008 14:01:37 -0500
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
In-Reply-To: <49256382.3080506@iinet.net.au>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<49256382.3080506@iinet.net.au>
Message-ID: <4925B411.3080400@redhat.com>

David Timms wrote:
>   - a way to trigger yum/PK check for update and offer to install it.
>   - "  "   "   "       "  "   "     "  update-testing and offer to 
> install
>   - "  "   "   "       "  "   "     "  rawhide and offer to install
The greatest bug report experience I ever witnessed was when a friend 
reported a kernel bug. After a short exchange a maintainer came back 
with a koji link and said "here, try this." The new package worked.

I'd like to see more of that kind of thing, and automating it would be a 
good way to go.

--CJD



From james at fedoraproject.org  Thu Nov 20 19:02:23 2008
From: james at fedoraproject.org (James Antill)
Date: Thu, 20 Nov 2008 14:02:23 -0500
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <16de708d0811201016y6f351c0u1ffd8d9b61a36291@mail.gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227203271.4355.219.camel@code.and.org>
	<16de708d0811201016y6f351c0u1ffd8d9b61a36291@mail.gmail.com>
Message-ID: <1227207743.4355.224.camel@code.and.org>

On Thu, 2008-11-20 at 12:16 -0600, Arthur Pemberton wrote:
> On Thu, Nov 20, 2008 at 11:47 AM, James Antill
> <james at fedoraproject.org> wrote:
> >  Why is "simple" a useful word, but GNOME isn't? For someone using a
> > GNOME desktop I could see the later being much more helpful.
> >  Also, as someone else mentioned:
> 
> Well a user may want a simple tool, as opposed to an advanced tool.
> And for said user, Gnome may be irrelevant.

 I had assumed "simple" here meant "simple to use", and I've just seen a
lot of applications that use words like "simple", "fast" or "secure"
based on nothing more than the authors opinion.

-- 
James Antill <james at fedoraproject.org>
Fedora



From pemboa at gmail.com  Thu Nov 20 19:02:04 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 20 Nov 2008 13:02:04 -0600
Subject: What do we need from Bugzilla? (was: My roadmap for a better
	Fedora)
In-Reply-To: <4925B2FE.2030408@redhat.com>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<6aufv5xi4u.ln2@ppp1053.in.ipex.cz>
	<7deeb2190ab5fc7bff30a343cc9e5c49.squirrel@arekh.dyndns.org>
	<4925B2FE.2030408@redhat.com>
Message-ID: <16de708d0811201102x33182e70wcba145890f61209c@mail.gmail.com>

On Thu, Nov 20, 2008 at 12:57 PM, Casey Dahlin <cdahlin at redhat.com> wrote:
>  Launchpad
> is supposed to grow good cross-site integration features just before it goes
> open source, but we've been waiting on both of those things for awhile now
> (and also Launchpad sucks. A lot.) Either way I think a new bug tracker
> would be an opportunity to improve on this point.

Maybe this changed, but I am pretty sure that LaunchPad is closed source.

> I'll add another bulletpoint.
> - Must be something we can talk RHEL in to using.
>
> Fedora and RHEL need to be in the same bug tracker. That's probably the
> biggest obstacle.

Agreed. Which is one of the major driving factors for this
questionnaire thread. I figure Bugzilla must be doing some things
right.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From jspaleta at gmail.com  Thu Nov 20 19:01:14 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 20 Nov 2008 10:01:14 -0900
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <16de708d0811201036p8f4989qe4d840ef7ad38d34@mail.gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<20081120145628.GB28357@nostromo.devel.redhat.com>
	<1227193973.3752.858.camel@beck.corsepiu.local>
	<1227194392.4076.31.camel@hughsie-laptop> <49258DA7.5050808@gmail.com>
	<1227198578.4076.37.camel@hughsie-laptop> <49259275.3000201@gmail.com>
	<1227202829.4076.72.camel@hughsie-laptop>
	<20081120183306.GA32047@nostromo.devel.redhat.com>
	<16de708d0811201036p8f4989qe4d840ef7ad38d34@mail.gmail.com>
Message-ID: <604aa7910811201101q2e2dc74cx5f450b25e67db47@mail.gmail.com>

On Thu, Nov 20, 2008 at 9:36 AM, Arthur Pemberton <pemboa at gmail.com> wrote:
> True. It isn't immediately clear to me if that is a bad thing though.

Well that's the underlying question what is the summary really meant
to convey.  Is it meant to differentiate? or is it meant to aggregate?
 At  duplicate summaries just trying to be more fine-grained "groups."
 At some point however, people have to be shown the choice among peers
for any functionality. If the summary doesn't attempt to differentiate
at all, then you'll have to expose differentiation at yet another
level of detail...so people can comparison shop.  Is the package name
enough of a differentiator?

Grocery store analogy time.

I have a terrible headache and I'm on vacation in Hungary  for the
first time and I go to the store looking for a society approved mind
altering chemical substance to relieve my distress.  I walk into the
store see a clerk and what do I ask them? Do I ask them details or do
I ask them "where is the headache medicine."

Once I get to the Aisle where the first-aid stuff collectively sits I
see 14 different brands of medicine, none of which I've heard of
before because I'm in a foreign territory. I might see a brandname I
know, but I've never before associated that brand with headache pills.
"Uncle Ben's" branded extra strength gel-caps really doesn't call to
me. So which one do I pick? Do I really care? Are they all just
equally usable variants of "headache medicine" to me?  If I do care,
like I have a specific allergic reaction that I need to avoid... I'd
have to pick up the bottle and try to read the details...in
Hungarian...which will ultimately result in my death because I will
make the wrong choice unless I happen to have a translator who can
help me read the fine print.

PackageKit is the store
the Package groups are the Aisle
The package name is the brand of headache medince
The package description is the fine print on the bottle

What's the summary?

-jef



From cdahlin at redhat.com  Thu Nov 20 19:12:03 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Thu, 20 Nov 2008 14:12:03 -0500
Subject: requires(post) on coreutils
In-Reply-To: <faa16b610811201056p565b8488q6214731bba98c61b@mail.gmail.com>
References: <1227159559.28543.644.camel@luminos.localdomain>	<1227201959.13169.40.camel@aglarond.local>	<4925B087.6000501@redhat.com>
	<faa16b610811201056p565b8488q6214731bba98c61b@mail.gmail.com>
Message-ID: <4925B683.2000404@redhat.com>

Colin Walters wrote:
> On Thu, Nov 20, 2008 at 1:46 PM, Casey Dahlin <cdahlin at redhat.com> wrote:
>   
>> We can look at binaries to see what libs they need, can we not look at %post
>> scripts and figure out if coreutils is required?
>>     
>
> Or have a two phase install, one where we put the minimum OS down, and
> the second where we install your apps.  Come on - coreutils isn't an
> addon package.
>
>   
Special cases are the enemy of all good design. We shouldn't solve a 
problem by adding one.

--CJD



From walters at verbum.org  Thu Nov 20 19:19:03 2008
From: walters at verbum.org (Colin Walters)
Date: Thu, 20 Nov 2008 14:19:03 -0500
Subject: requires(post) on coreutils
In-Reply-To: <4925B683.2000404@redhat.com>
References: <1227159559.28543.644.camel@luminos.localdomain>
	<1227201959.13169.40.camel@aglarond.local>
	<4925B087.6000501@redhat.com>
	<faa16b610811201056p565b8488q6214731bba98c61b@mail.gmail.com>
	<4925B683.2000404@redhat.com>
Message-ID: <faa16b610811201119o14f0268x441c6c96f6230200@mail.gmail.com>

On Thu, Nov 20, 2008 at 2:12 PM, Casey Dahlin <cdahlin at redhat.com> wrote:

> Special cases are the enemy of all good design. We shouldn't solve a problem
> by adding one.

How could one even propose using shell script without coreutils
installed?  What are you going to do in that script?

Requires(post): coreutils strikes me as just an exercise in bloating
the dependency graph.  This mindset of putting core OS bits and random
third party applications in the same mental category of "package" and
applying the exact same rules to them is just wrong.



From cdahlin at redhat.com  Thu Nov 20 19:26:02 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Thu, 20 Nov 2008 14:26:02 -0500
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
In-Reply-To: <16de708d0811201102x33182e70wcba145890f61209c@mail.gmail.com>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>	<6aufv5xi4u.ln2@ppp1053.in.ipex.cz>	<7deeb2190ab5fc7bff30a343cc9e5c49.squirrel@arekh.dyndns.org>	<4925B2FE.2030408@redhat.com>
	<16de708d0811201102x33182e70wcba145890f61209c@mail.gmail.com>
Message-ID: <4925B9CA.4020200@redhat.com>

Arthur Pemberton wrote:
> On Thu, Nov 20, 2008 at 12:57 PM, Casey Dahlin <cdahlin at redhat.com> wrote:
>   
>>  Launchpad
>> is supposed to grow good cross-site integration features just before it goes
>> open source, but we've been waiting on both of those things for awhile now
>> (and also Launchpad sucks. A lot.) Either way I think a new bug tracker
>> would be an opportunity to improve on this point.
>>     
>
> Maybe this changed, but I am pretty sure that LaunchPad is closed source.
>
>   
Its supposed to become open source, but they want to complete the 
inter-instance integration stuff first (because there should never ever 
ever be two independent sets of launchpad data ever, according to their 
philosophy).

--CJD



From seandarcy2 at gmail.com  Thu Nov 20 19:27:01 2008
From: seandarcy2 at gmail.com (sean darcy)
Date: Thu, 20 Nov 2008 14:27:01 -0500
Subject: where's the wish list for F11?
Message-ID: <gg4dm5$ts1$1@ger.gmane.org>

How do users put forward a wish list/feature request for F11.

Being a user from os/x I'm surprised there's no simple method for 
installing system wide Type1 fonts ( same for TT ? ). FWIW, I've been 
unable to find instructions on how to do it from command line. The 
Fedora Users list just suggested I install using yum (sigh).

In any event, IMHO, it's a major oversight that we can't install 3rd 
party fonts, which would nice to see fixed in F11. So where do I make my 
plea?

sean



From lesmikesell at gmail.com  Thu Nov 20 19:28:32 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 20 Nov 2008 13:28:32 -0600
Subject: My roadmap for a better Fedora
In-Reply-To: <20081120183713.GF31216@localhost.localdomain>
References: <1227119906.7387.138.camel@localhost.localdomain>	<20081119221544.GE31216@localhost.localdomain>	<492493AA.30108@gmail.com>
	<20081120183713.GF31216@localhost.localdomain>
Message-ID: <4925BA60.6040703@gmail.com>

Chris Lumens wrote:
>> Except for fedora-specific quirks, fixing should be an upstream issue.  
> 
> We ARE upstream for plenty of things, and we could definitely use bug
> fixing help on them.
> 

OK, but it shouldn't be fedora-specific, then.  If the same bugs are 
going to hit people building from tarballs or installing from other 
distribution's packaging, the bug reporting mechanism should accommodate 
those equally.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From dbn.lists at gmail.com  Thu Nov 20 19:28:04 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Thu, 20 Nov 2008 11:28:04 -0800
Subject: requires(post) on coreutils
In-Reply-To: <1227207227.13169.43.camel@aglarond.local>
References: <1227159559.28543.644.camel@luminos.localdomain>
	<1227201959.13169.40.camel@aglarond.local>
	<4925B087.6000501@redhat.com>
	<1227207227.13169.43.camel@aglarond.local>
Message-ID: <91705d080811201128k7be84616g96a44131de226a1c@mail.gmail.com>

On Thu, Nov 20, 2008 at 10:53 AM, Jeremy Katz <katzj at redhat.com> wrote:
> On Thu, 2008-11-20 at 13:46 -0500, Casey Dahlin wrote:
>> Jeremy Katz wrote:
>> > On Wed, 2008-11-19 at 21:39 -0800, Jesse Keating wrote:
>> >> I just attempted to compose the Games spin for Fedora 10, and ran into a
>> >> number of packages that fail their %post scripts due to missing one
>> >> thing or another out of coreutils (such as ln, rm, file, etc..) and it
>> >> has me wondering what might have changed in recent time so that
>> >> coreutils wouldn't be installed earlier in the transaction.  This seems
>> >> like something that would have been noticed before, but maybe it's just
>> >> in the particular package set that the games spin has.
>> >
>> > It's actually a pretty common phenomenon related to packagers thinking
>> > they're "always" there because they are except in the case of new
>> > installs.  coreutils is actually surprisingly late in install order and
>> > so there are pretty frequent packages which pop up expecting otherwise
>> > (and there always have been; I've been filing bugs about them for longer
>> > than I like to remember :-)
>> >
>> We can look at binaries to see what libs they need, can we not look at
>> %post scripts and figure out if coreutils is required?
>
> Scripts (assuming not using a different interpreter) are run via bash
> which means that in theory you could use bash --rpm-requires.  But that
> has a lot of holes and problems

This may only be in rpm5, but if you use full paths to the programs
(/bin/rm, etc.), aren't the dependencies resolved by rpm?

--
Dan



From jkeating at redhat.com  Thu Nov 20 19:34:45 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 20 Nov 2008 11:34:45 -0800
Subject: requires(post) on coreutils
In-Reply-To: <faa16b610811201119o14f0268x441c6c96f6230200@mail.gmail.com>
References: <1227159559.28543.644.camel@luminos.localdomain>
	<1227201959.13169.40.camel@aglarond.local>
	<4925B087.6000501@redhat.com>
	<faa16b610811201056p565b8488q6214731bba98c61b@mail.gmail.com>
	<4925B683.2000404@redhat.com>
	<faa16b610811201119o14f0268x441c6c96f6230200@mail.gmail.com>
Message-ID: <1227209685.28543.653.camel@luminos.localdomain>

On Thu, 2008-11-20 at 14:19 -0500, Colin Walters wrote:
> How could one even propose using shell script without coreutils
> installed?  What are you going to do in that script?
> 
> Requires(post): coreutils strikes me as just an exercise in bloating
> the dependency graph.  This mindset of putting core OS bits and random
> third party applications in the same mental category of "package" and
> applying the exact same rules to them is just wrong.

That's the fun thing about %post, it doesn't have to be bash.  The fact
that it is for most people is just implementation details.  People could
write their post scripts in csh, lua, whatever.  The point is that the
package installation system needs to know what your package needs before
it's scripts can be ran.  Trying to set some arbitrary level of "OS
bits" and "applications" is doomed to fail.  We have a system that
handles the ordering for us, it just needs a few hints along 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/20081120/feec28e8/attachment.sig>

From rjones at redhat.com  Thu Nov 20 19:30:33 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 20 Nov 2008 19:30:33 +0000
Subject: where's the wish list for F11?
In-Reply-To: <gg4dm5$ts1$1@ger.gmane.org>
References: <gg4dm5$ts1$1@ger.gmane.org>
Message-ID: <20081120193033.GA8549@amd.home.annexia.org>

On Thu, Nov 20, 2008 at 02:27:01PM -0500, sean darcy wrote:
> How do users put forward a wish list/feature request for F11.

If you want to implement the feature yourself, then:

https://fedoraproject.org/wiki/Features/Policy

> Being a user from os/x I'm surprised there's no simple method for  
> installing system wide Type1 fonts ( same for TT ? ). FWIW, I've been  
> unable to find instructions on how to do it from command line. The  
> Fedora Users list just suggested I install using yum (sigh).
>
> In any event, IMHO, it's a major oversight that we can't install 3rd  
> party fonts, which would nice to see fixed in F11. So where do I make my  
> plea?

I think you just drop them into .fonts in your home directory.  At
least, that was how it was about 10 years ago when I last worried
about such things.

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 cdahlin at redhat.com  Thu Nov 20 19:40:41 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Thu, 20 Nov 2008 14:40:41 -0500
Subject: where's the wish list for F11?
In-Reply-To: <20081120193033.GA8549@amd.home.annexia.org>
References: <gg4dm5$ts1$1@ger.gmane.org>
	<20081120193033.GA8549@amd.home.annexia.org>
Message-ID: <4925BD39.7010501@redhat.com>

Richard W.M. Jones wrote:
> On Thu, Nov 20, 2008 at 02:27:01PM -0500, sean darcy wrote:
>   
>> How do users put forward a wish list/feature request for F11.
>>     
>
> If you want to implement the feature yourself, then:
>
> https://fedoraproject.org/wiki/Features/Policy
>
>   
>> Being a user from os/x I'm surprised there's no simple method for  
>> installing system wide Type1 fonts ( same for TT ? ). FWIW, I've been  
>> unable to find instructions on how to do it from command line. The  
>> Fedora Users list just suggested I install using yum (sigh).
>>
>> In any event, IMHO, it's a major oversight that we can't install 3rd  
>> party fonts, which would nice to see fixed in F11. So where do I make my  
>> plea?
>>     
>
> I think you just drop them into .fonts in your home directory.  At
> least, that was how it was about 10 years ago when I last worried
> about such things.
>
> Rich.
>
>   
He specified "system-wide" though, which makes life more fun.

--CJD



From jkeating at redhat.com  Thu Nov 20 19:44:24 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 20 Nov 2008 11:44:24 -0800
Subject: My roadmap for a better Fedora
In-Reply-To: <4925BA60.6040703@gmail.com>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<20081119221544.GE31216@localhost.localdomain>	<492493AA.30108@gmail.com>
	<20081120183713.GF31216@localhost.localdomain>
	<4925BA60.6040703@gmail.com>
Message-ID: <1227210265.28543.654.camel@luminos.localdomain>

On Thu, 2008-11-20 at 13:28 -0600, Les Mikesell wrote:
> 
> OK, but it shouldn't be fedora-specific, then.

Except for when very very few people outside of Fedora use the things
we're upstream for.

-- 
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/20081120/40100857/attachment.sig>

From jkeating at redhat.com  Thu Nov 20 19:45:38 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 20 Nov 2008 11:45:38 -0800
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
In-Reply-To: <16de708d0811201102x33182e70wcba145890f61209c@mail.gmail.com>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<6aufv5xi4u.ln2@ppp1053.in.ipex.cz>
	<7deeb2190ab5fc7bff30a343cc9e5c49.squirrel@arekh.dyndns.org>
	<4925B2FE.2030408@redhat.com>
	<16de708d0811201102x33182e70wcba145890f61209c@mail.gmail.com>
Message-ID: <1227210339.28543.655.camel@luminos.localdomain>

On Thu, 2008-11-20 at 13:02 -0600, Arthur Pemberton wrote:
> Agreed. Which is one of the major driving factors for this
> questionnaire thread. I figure Bugzilla must be doing some things
> right.

It's not that it's doing things right, it's just too cost prohibitive to
create something else to do the same things in the same predictably
wrong 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/20081120/1cf1567b/attachment.sig>

From nicolas.mailhot at laposte.net  Thu Nov 20 19:47:19 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 20 Nov 2008 20:47:19 +0100
Subject: where's the wish list for F11?
In-Reply-To: <gg4dm5$ts1$1@ger.gmane.org>
References: <gg4dm5$ts1$1@ger.gmane.org>
Message-ID: <1227210439.28736.0.camel@arekh.okg>

Le jeudi 20 novembre 2008 ? 14:27 -0500, sean darcy a ?crit :

> In any event, IMHO, it's a major oversight that we can't install 3rd 
> party fonts, which would nice to see fixed in F11. So where do I make my 
> plea?

http://bugzilla.redhat.com/show_bug.cgi?id=468598

-- 
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/20081120/6113d3eb/attachment.sig>

From fedora at camperquake.de  Thu Nov 20 19:48:04 2008
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Thu, 20 Nov 2008 20:48:04 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227207743.4355.224.camel@code.and.org>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227203271.4355.219.camel@code.and.org>
	<16de708d0811201016y6f351c0u1ffd8d9b61a36291@mail.gmail.com>
	<1227207743.4355.224.camel@code.and.org>
Message-ID: <20081120204804.2a082c0e@lain.camperquake.de>

Moin.

On Thu, 20 Nov 2008 14:02:23 -0500, James Antill wrote

>  I had assumed "simple" here meant "simple to use", and I've just
> seen a lot of applications that use words like "simple", "fast" or
> "secure" based on nothing more than the authors opinion.

SNMP and LDAP spring to mind :)



From cra at WPI.EDU  Thu Nov 20 19:48:14 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 20 Nov 2008 14:48:14 -0500
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <604aa7910811201101q2e2dc74cx5f450b25e67db47@mail.gmail.com>
References: <20081120145628.GB28357@nostromo.devel.redhat.com>
	<1227193973.3752.858.camel@beck.corsepiu.local>
	<1227194392.4076.31.camel@hughsie-laptop>
	<49258DA7.5050808@gmail.com>
	<1227198578.4076.37.camel@hughsie-laptop>
	<49259275.3000201@gmail.com>
	<1227202829.4076.72.camel@hughsie-laptop>
	<20081120183306.GA32047@nostromo.devel.redhat.com>
	<16de708d0811201036p8f4989qe4d840ef7ad38d34@mail.gmail.com>
	<604aa7910811201101q2e2dc74cx5f450b25e67db47@mail.gmail.com>
Message-ID: <20081120194814.GQ24297@angus.ind.WPI.EDU>

On Thu, Nov 20, 2008 at 10:01:14AM -0900, Jeff Spaleta wrote:
> PackageKit is the store
> the Package groups are the Aisle
> The package name is the brand of headache medince
> The package description is the fine print on the bottle
> 
> What's the summary?

The sign above the aisle that says "headache medicine"?  Or perhaps 
the sign on the shelf itself?

Or, it could be the smaller title below the brand name on the bottle 
that says "headache and pain relief".  Generally the brand name is the 
most prominent title, which would suggest that the Package Name should 
be larger/more prominent in PackageKit than the Summary.

This smells similar to the GenericName vs. Name argument in desktop 
files.



From nicolas.mailhot at laposte.net  Thu Nov 20 19:49:42 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 20 Nov 2008 20:49:42 +0100
Subject: where's the wish list for F11?
In-Reply-To: <4925BD39.7010501@redhat.com>
References: <gg4dm5$ts1$1@ger.gmane.org>
	<20081120193033.GA8549@amd.home.annexia.org>
	<4925BD39.7010501@redhat.com>
Message-ID: <1227210582.28736.2.camel@arekh.okg>

Le jeudi 20 novembre 2008 ? 14:40 -0500, Casey Dahlin a ?crit :
>    
> He specified "system-wide" though, which makes life more fun.

System-wide means making a proper font package and using yum

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

-- 
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/20081120/18a2bf38/attachment.sig>

From walters at verbum.org  Thu Nov 20 19:49:56 2008
From: walters at verbum.org (Colin Walters)
Date: Thu, 20 Nov 2008 14:49:56 -0500
Subject: requires(post) on coreutils
In-Reply-To: <1227209685.28543.653.camel@luminos.localdomain>
References: <1227159559.28543.644.camel@luminos.localdomain>
	<1227201959.13169.40.camel@aglarond.local>
	<4925B087.6000501@redhat.com>
	<faa16b610811201056p565b8488q6214731bba98c61b@mail.gmail.com>
	<4925B683.2000404@redhat.com>
	<faa16b610811201119o14f0268x441c6c96f6230200@mail.gmail.com>
	<1227209685.28543.653.camel@luminos.localdomain>
Message-ID: <faa16b610811201149r67bff80q3f8115329483f894@mail.gmail.com>

2008/11/20 Jesse Keating <jkeating at redhat.com>:
> On Thu, 2008-11-20 at 14:19 -0500, Colin Walters wrote:
>> How could one even propose using shell script without coreutils
>> installed?  What are you going to do in that script?
>>
>> Requires(post): coreutils strikes me as just an exercise in bloating
>> the dependency graph.  This mindset of putting core OS bits and random
>> third party applications in the same mental category of "package" and
>> applying the exact same rules to them is just wrong.
>
> That's the fun thing about %post, it doesn't have to be bash.  The fact
> that it is for most people is just implementation details.  People could
> write their post scripts in csh, lua, whatever.

But there's clearly a default, which is shell script.  And in
particular bash.  In any case do we really want to encourage people
writing their %post scripts in lua or whatever random language they
like?  I don't think we do.  That will fragment the community of
people who can modify a package.

> The point is that the
> package installation system needs to know what your package needs before
> it's scripts can be ran.  Trying to set some arbitrary level of "OS
> bits" and "applications" is doomed to fail.

We have that in comps, in particular say everything in core/mandatory.
 In the first phase, lay all that stuff down since it's not optional.
I'd be shocked if there weren't circular dependencies here that took
special handling in the installer anyways.

> We have a system that
> handles the ordering for us, it just needs a few hints along the way.

Yes, but the problem is that we're *introducing bugs* and wasting the
time of the people who are trying to package things higher up in the
stack.

I wouldn't care at all about this if people wanted to mess around with
the core OS packages and add dependencies, but if I get a bug about
this in one of my packages it'll be 5 minutes down the drain that
could have been spent somewhere more useful.



From a.badger at gmail.com  Thu Nov 20 19:48:42 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 20 Nov 2008 11:48:42 -0800
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227202829.4076.72.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>	<20081120145328.GB2410@yoda.jdub.homelinux.org>	<20081120145628.GB28357@nostromo.devel.redhat.com>	<1227193973.3752.858.camel@beck.corsepiu.local>	<1227194392.4076.31.camel@hughsie-laptop>
	<49258DA7.5050808@gmail.com>	<1227198578.4076.37.camel@hughsie-laptop>
	<49259275.3000201@gmail.com>
	<1227202829.4076.72.camel@hughsie-laptop>
Message-ID: <4925BF1A.9040007@gmail.com>

Richard Hughes wrote:
> On Thu, 2008-11-20 at 08:38 -0800, Toshio Kuratomi wrote:
>> Okay.  Please fill in other examples so packagers and reviewers can
>> get
>> a feel for what to cut and when it's good to depart from the general
>> rules and put it on the wiki under PackagingDrafts.  Then add it to
>> the
>> list of things for the Packaging Committee to discuss.
>>
>> We can link it from this portion of the full Guidelines:
>> http://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description
> 
> Okay, I'll do that when we've got more agreement on the wording:
> 
> Many GUI packaging tools make the summary more prominent than the
> package name. The summary is often a better description for the end user
> when making a decision about installing. To make the user's experience
> better here, we try to have short succinct summaries that don't repeat
> information in the name.
> 
Is many accurate?  the rest of this text sounds good.

> For instance, the following are over long, or repeat the program name:
> 
> * System daemon that is a DBUS abstraction layer for package management
> * XQilla is an XQuery and XPath 2.0 library, built on top of Xerces-C
> * DeVeDe is a program to create video DVDs and CDs (VCD, sVCD or CVD)
> 
> The following would be good replacements:
> 
> * Package management framework
> * XQuery and XPath 2.0 library
> * Create video DVDs and CDs
> 
* It would be good to have the program name mentioned here as well.

* I find it easier to see what's happening with the before and after
next to each other.

* A few words about rationale would be good too:

Why is Xerces-C not important to mention?  is that something that would
be important for one class of packages (libraries) but not another
(applications)?

Why would differentiators like VCD, sVCD,and CVD not be good?  If that's
the program's claim to fame, would "Creator for many types of video DVDs
and CDs" be better?

-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/20081120/20b730a6/attachment.sig>

From skvidal at fedoraproject.org  Thu Nov 20 19:57:24 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 20 Nov 2008 14:57:24 -0500 (EST)
Subject: where's the wish list for F11?
In-Reply-To: <gg4dm5$ts1$1@ger.gmane.org>
References: <gg4dm5$ts1$1@ger.gmane.org>
Message-ID: <alpine.LFD.2.00.0811201455510.16994@localhost.localdomain>



On Thu, 20 Nov 2008, sean darcy wrote:

> Being a user from os/x I'm surprised there's no simple method for installing 
> system wide Type1 fonts ( same for TT ? ). FWIW, I've been unable to find 
> instructions on how to do it from command line. The Fedora Users list just 
> suggested I install using yum (sigh).

What's wrong with using yum?

yum search type1
yum install any_of_the_things_returned_by_that_search


and there a bunch returned by that search

> In any event, IMHO, it's a major oversight that we can't install 3rd party 
> fonts, which would nice to see fixed in F11. So where do I make my plea?

Oh, I see you want  3rd party fonts. Then make a package and install them 
the same way.

-sv



From mhlavink at redhat.com  Thu Nov 20 19:58:57 2008
From: mhlavink at redhat.com (Michal Hlavinka)
Date: Thu, 20 Nov 2008 14:58:57 -0500 (EST)
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1274542974.1556651227211114704.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <1542747735.1556741227211137110.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>


> > Usually, if I need something, I use yum search keyword and choose what I 
> > will install thx summary, so I prefer useful and descriptive summary 
> > against a few words
>
> "yum search" also searches the package %description. And the description
> is the place where to be much more verbose than in the summary. The
> %summary is not made for searching, but for enabling the installer and
> packaging tools to to display a brief and concise package description or a
> list thereof. That means, put a few relevant keywords in the summary
> (newspaper headline-style at most), but avoid long/complete sentences as
> often as possible. That also makes it easier to fit into one line.

yes, but... example: you need some email client, so...
yum search mail
and you get:
evolution-email client
kmail-client for email
mutt-mail agent
squirrelmail-mail client

these summaries will be really short but really useless. You can't choose any package just from summary but you need to go one by one with yum info package. IMHO summary should be descriptive enough to tell you not only difference between mutt and nut.

Personally, I have no problem with "one sentence summary". If there is any packaging client (or anything else) who has problem, it's not package's fault, client is broken.

So again, if PackageKit is broken fix PackageKit, not everything else.

btw, yum search oggconvert gives me line with 75 characters
yum search 'a' gives me
2744 packages/lines with 75 or more characters (it's 16 %)
the longest line has 82 characters

Do you really want to fix all these because of... what exactly? because summary is "too" descriptive?



From mcepl at redhat.com  Thu Nov 20 19:58:39 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 20 Nov 2008 20:58:39 +0100
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<6aufv5xi4u.ln2@ppp1053.in.ipex.cz>
	<7deeb2190ab5fc7bff30a343cc9e5c49.squirrel@arekh.dyndns.org>
	<4925B2FE.2030408@redhat.com>
Message-ID: <f4sgv5x6h7.ln2@ppp1053.in.ipex.cz>

On 2008-11-20, 18:57 GMT, Casey Dahlin wrote:
> Either way I think a new bug tracker would be an opportunity to 
> improve on this point.

Great, write one ;-).

Mat?j



From skvidal at fedoraproject.org  Thu Nov 20 20:05:05 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 20 Nov 2008 15:05:05 -0500 (EST)
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1542747735.1556741227211137110.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
References: <1542747735.1556741227211137110.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <alpine.LFD.2.00.0811201502080.16994@localhost.localdomain>



On Thu, 20 Nov 2008, Michal Hlavinka wrote:

>
>>> Usually, if I need something, I use yum search keyword and choose what I
>>> will install thx summary, so I prefer useful and descriptive summary
>>> against a few words
>>
>> "yum search" also searches the package %description. And the description
>> is the place where to be much more verbose than in the summary. The
>> %summary is not made for searching, but for enabling the installer and
>> packaging tools to to display a brief and concise package description or a
>> list thereof. That means, put a few relevant keywords in the summary
>> (newspaper headline-style at most), but avoid long/complete sentences as
>> often as possible. That also makes it easier to fit into one line.
>
> yes, but... example: you need some email client, so...
> yum search mail
> and you get:
> evolution-email client
> kmail-client for email
> mutt-mail agent
> squirrelmail-mail client
>
> these summaries will be really short but really useless. You can't choose any package just from summary but you need to go one by one with yum info package. IMHO summary should be descriptive enough to tell you not only difference between mutt and nut.

Not actually.
You can do:

yum info pkg1 pkg2 pkg3 pkg4

and it'll do them all at once.

you can also do yum search -v mail

and then you'll get the description, too

worth mentioning if you know more about what you want you can group yum 
search terms

yum search mail client gnome

and the top of the output will be the packages you most likely want

=================== Matched: client, gnome, mail =====================
balsa.i386 : Mail Client
evolution.i386 : Mail and calendar client for GNOME
evolution-rspam.i386 : Evolution Plugin for reporting spam


-sv



From jkeating at redhat.com  Thu Nov 20 20:05:17 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 20 Nov 2008 12:05:17 -0800
Subject: requires(post) on coreutils
In-Reply-To: <faa16b610811201149r67bff80q3f8115329483f894@mail.gmail.com>
References: <1227159559.28543.644.camel@luminos.localdomain>
	<1227201959.13169.40.camel@aglarond.local>
	<4925B087.6000501@redhat.com>
	<faa16b610811201056p565b8488q6214731bba98c61b@mail.gmail.com>
	<4925B683.2000404@redhat.com>
	<faa16b610811201119o14f0268x441c6c96f6230200@mail.gmail.com>
	<1227209685.28543.653.camel@luminos.localdomain>
	<faa16b610811201149r67bff80q3f8115329483f894@mail.gmail.com>
Message-ID: <1227211518.28543.659.camel@luminos.localdomain>

On Thu, 2008-11-20 at 14:49 -0500, Colin Walters wrote:
> 
> But there's clearly a default, which is shell script.  And in
> particular bash.  In any case do we really want to encourage people
> writing their %post scripts in lua or whatever random language they
> like?  I don't think we do.  That will fragment the community of
> people who can modify a package.

Actually yes, lua would be a good forced default, since rpm contains an
internal lua interpreter and would need no external deps to process the
script.  Of course, regardless of what /language/ the script is written
in, the script could call upon things that are both "core os" utilities,
as well as "applications".  We have to account for both in the ordering,
so why not just account for both, instead of trying to draw some fuzzy
line in the sand?

> 
> > The point is that the
> > package installation system needs to know what your package needs before
> > it's scripts can be ran.  Trying to set some arbitrary level of "OS
> > bits" and "applications" is doomed to fail.
> 
> We have that in comps, in particular say everything in core/mandatory.
>  In the first phase, lay all that stuff down since it's not optional.
> I'd be shocked if there weren't circular dependencies here that took
> special handling in the installer anyways.

Very very few things require special handling, rpm handles that for us.
And yeah, you can assume that those things will be installed, but not in
what order, which is why you have to give the system that installs the
software ordering hints.

> 
> > We have a system that
> > handles the ordering for us, it just needs a few hints along the way.
> 
> Yes, but the problem is that we're *introducing bugs* and wasting the
> time of the people who are trying to package things higher up in the
> stack.
> 
> I wouldn't care at all about this if people wanted to mess around with
> the core OS packages and add dependencies, but if I get a bug about
> this in one of my packages it'll be 5 minutes down the drain that
> could have been spent somewhere more useful.

Or you could have done it right in the first place and we wouldn't be
filing a bug against your 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/20081120/e9dff21a/attachment.sig>

From nicolas.mailhot at laposte.net  Thu Nov 20 20:08:00 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 20 Nov 2008 21:08:00 +0100
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
In-Reply-To: <4925B2FE.2030408@redhat.com>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<6aufv5xi4u.ln2@ppp1053.in.ipex.cz>
	<7deeb2190ab5fc7bff30a343cc9e5c49.squirrel@arekh.dyndns.org>
	<4925B2FE.2030408@redhat.com>
Message-ID: <1227211680.28736.15.camel@arekh.okg>

Le jeudi 20 novembre 2008 ? 13:57 -0500, Casey Dahlin a ?crit :

> I've always hated these sorts of requirements. "Its wrong, but we
> should 
> keep it because its always been wrong." WTF?! Let them adapt and 
> survive. If we were always worried about this sort of thing we'd
> still 
> be using Windows, and most of the reason Windows is crap largely because 
> of its insistence on stone-age-compliance.

Bugzilla is used by 10s of other open source projects. Any experienced
Fedora bug reporter will have used the issue trackers of those project
and be used to their interface.

You can offer a "better" fa?ade for new users but if you don't *also*
offer the fa?ade experienced bug reporters are used to you will
instantly lose reports from all the people most suceptible to write
something useable.

That's what the projects that use the sf POS or launchpad do not
understand

-- 
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/20081120/0c80d52c/attachment.sig>

From Jochen at herr-schmitt.de  Thu Nov 20 20:08:58 2008
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Thu, 20 Nov 2008 21:08:58 +0100
Subject: Straw comaintainer needed
In-Reply-To: <539333cb0811200910j180badb9wce4188c7d93cb4f8@mail.gmail.com>
References: <539333cb0811200910j180badb9wce4188c7d93cb4f8@mail.gmail.com>
Message-ID: <4925C3DA.5000800@herr-schmitt.de>

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

subhodip biswas schrieb:
> hi !
>
> A FTBFS bug is assigned against straw for quite a amount of time . I
> really didnt able to dedicate the time necessary to fix it .
> I will be grateful , if someone co maintains straw and help in fixing
the bug .
>
> https://bugzilla.redhat.com/show_bug.cgi?id=465038
>
Should be fixed on straw-0.27-14

The issues was:

* Add the egg-info files into the package
* Add gnome-python2-gnome as BR and Req.

I have checked in and built the modified version for rawhide.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkklw9AACgkQT2AHK6txfgzftgCggm/nWNs2MyPQxrRlubHJGCNp
wOoAoJexbCESxsHGw/YGjT2w+tJkOSj3
=ZWkP
-----END PGP SIGNATURE-----



From ville.skytta at iki.fi  Thu Nov 20 20:13:37 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Thu, 20 Nov 2008 22:13:37 +0200
Subject: Removing "minimal buildroot" dependencies from rpmdevtools
In-Reply-To: <1226356301.12953.12.camel@luminos.localdomain>
References: <200811102351.47926.ville.skytta@iki.fi>
	<1226356301.12953.12.camel@luminos.localdomain>
Message-ID: <200811202213.38033.ville.skytta@iki.fi>

On Tuesday 11 November 2008, Jesse Keating wrote:
> On Mon, 2008-11-10 at 23:51 +0200, Ville Skytt? wrote:
> > so
> > this possibility should IMO be preserved somewhere else when/if this
> > dependency set gets removed from rpmdevtools.  Maybe the fedora-packager
> > package or a subpackage of it?
>
> groupinstall buildsys-build  It's already tracked in comps.

Ok, that's good.  Even better in my opinion would be a solution that works 
also with other depsolvers than yum (IIRC smart and apt don't support comps) 
but I suppose this will do at least for now; and because nobody yelled in 
general about the plan, I'll go ahead with purging the deps from rpmdevtools.



From mschwendt at gmail.com  Thu Nov 20 20:16:50 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 20 Nov 2008 21:16:50 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <4925BF1A.9040007@gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<20081120145328.GB2410@yoda.jdub.homelinux.org>
	<20081120145628.GB28357@nostromo.devel.redhat.com>
	<1227193973.3752.858.camel@beck.corsepiu.local>
	<1227194392.4076.31.camel@hughsie-laptop>
	<49258DA7.5050808@gmail.com>
	<1227198578.4076.37.camel@hughsie-laptop>
	<49259275.3000201@gmail.com>
	<1227202829.4076.72.camel@hughsie-laptop>
	<4925BF1A.9040007@gmail.com>
Message-ID: <20081120211650.7a1c001e.mschwendt@gmail.com>

On Thu, 20 Nov 2008 11:48:42 -0800, Toshio Kuratomi wrote:

> > For instance, the following are over long, or repeat the program name:
> > 
> > * System daemon that is a DBUS abstraction layer for package management
> > * XQilla is an XQuery and XPath 2.0 library, built on top of Xerces-C
> > * DeVeDe is a program to create video DVDs and CDs (VCD, sVCD or CVD)
> > 
> > The following would be good replacements:
> > 
> > * Package management framework
> > * XQuery and XPath 2.0 library
> > * Create video DVDs and CDs
> > 
> * It would be good to have the program name mentioned here as well.

Please don't. That has lead to many summaries, which look ugly
if displayed next to the package name:

  name - name is a...

Especially ugly if package name and program name are even written in
the same case. Many many users don't care what name a program is given
as long as it does what they want.

Better make sure that hardly any packager does the following in a spec

%description
%summary

to reuse the summary as the description.



From pertusus at free.fr  Thu Nov 20 20:23:01 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 20 Nov 2008 21:23:01 +0100
Subject: requires(post) on coreutils
In-Reply-To: <1227205642.28543.651.camel@luminos.localdomain>
References: <1227159559.28543.644.camel@luminos.localdomain>
	<1227201959.13169.40.camel@aglarond.local>
	<1227205642.28543.651.camel@luminos.localdomain>
Message-ID: <20081120202301.GA2868@free.fr>

On Thu, Nov 20, 2008 at 10:27:22AM -0800, Jesse Keating wrote:
> 
> Fair enough.  I didn't see any such messages in my other installs, so
> these packages are probably far enough off the radar that this isn't
> typically seen.
> 
> Would this be something to check for during package review?  Init a
> chroot @core <package> listed in the init call and see what errors pop
> up?

Not a chroot @core <package>, but a chroot with only the <package>
should work well.

--
Pat



From lesmikesell at gmail.com  Thu Nov 20 20:23:09 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 20 Nov 2008 14:23:09 -0600
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
In-Reply-To: <1227210339.28543.655.camel@luminos.localdomain>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>	<6aufv5xi4u.ln2@ppp1053.in.ipex.cz>	<7deeb2190ab5fc7bff30a343cc9e5c49.squirrel@arekh.dyndns.org>	<4925B2FE.2030408@redhat.com>	<16de708d0811201102x33182e70wcba145890f61209c@mail.gmail.com>
	<1227210339.28543.655.camel@luminos.localdomain>
Message-ID: <4925C72D.9030605@gmail.com>

Jesse Keating wrote:
> On Thu, 2008-11-20 at 13:02 -0600, Arthur Pemberton wrote:
>> Agreed. Which is one of the major driving factors for this
>> questionnaire thread. I figure Bugzilla must be doing some things
>> right.
> 
> It's not that it's doing things right, it's just too cost prohibitive to
> create something else to do the same things in the same predictably
> wrong way (:

That's actually pretty funny when compared to the reaction I get here to 
comments regarding API and functional changes in fedora itself.

But, lots of people like trac these days.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jkeating at redhat.com  Thu Nov 20 20:24:16 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 20 Nov 2008 12:24:16 -0800
Subject: Removing "minimal buildroot" dependencies from rpmdevtools
In-Reply-To: <200811202213.38033.ville.skytta@iki.fi>
References: <200811102351.47926.ville.skytta@iki.fi>
	<1226356301.12953.12.camel@luminos.localdomain>
	<200811202213.38033.ville.skytta@iki.fi>
Message-ID: <1227212656.28543.660.camel@luminos.localdomain>

On Thu, 2008-11-20 at 22:13 +0200, Ville Skytt? wrote:
> 
> Ok, that's good.  Even better in my opinion would be a solution that works 
> also with other depsolvers than yum (IIRC smart and apt don't support comps) 
> but I suppose this will do at least for now; and because nobody yelled in 
> general about the plan, I'll go ahead with purging the deps from rpmdevtools.

If the other depsolvers don't handle comps, they're rather useless in
the Fedora world, where are grouping is done exclusively via comps.

-- 
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/20081120/6720073a/attachment.sig>

From pemboa at gmail.com  Thu Nov 20 20:25:45 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 20 Nov 2008 14:25:45 -0600
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <604aa7910811201101q2e2dc74cx5f450b25e67db47@mail.gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227193973.3752.858.camel@beck.corsepiu.local>
	<1227194392.4076.31.camel@hughsie-laptop> <49258DA7.5050808@gmail.com>
	<1227198578.4076.37.camel@hughsie-laptop> <49259275.3000201@gmail.com>
	<1227202829.4076.72.camel@hughsie-laptop>
	<20081120183306.GA32047@nostromo.devel.redhat.com>
	<16de708d0811201036p8f4989qe4d840ef7ad38d34@mail.gmail.com>
	<604aa7910811201101q2e2dc74cx5f450b25e67db47@mail.gmail.com>
Message-ID: <16de708d0811201225l186016day516b24a10d8b708d@mail.gmail.com>

On Thu, Nov 20, 2008 at 1:01 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Thu, Nov 20, 2008 at 9:36 AM, Arthur Pemberton <pemboa at gmail.com> wrote:
>> True. It isn't immediately clear to me if that is a bad thing though.
>
[ snip ]

> PackageKit is the store
> the Package groups are the Aisle
> The package name is the brand of headache medince
> The package description is the fine print on the bottle
>
> What's the summary?

I believe that it should be the "Pain Killers" label often included in
the aisles.

Good analogy by the way.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From tibbs at math.uh.edu  Thu Nov 20 20:25:37 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 20 Nov 2008 14:25:37 -0600
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081120145328.GB2410@yoda.jdub.homelinux.org>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<20081120145328.GB2410@yoda.jdub.homelinux.org>
Message-ID: <ufamyfum9fi.fsf@epithumia.math.uh.edu>

>>>>> "JB" == Josh Boyer <jwboyer at gmail.com> writes:

JB> So, while I think packaging guidelines are good to have, I don't
JB> think everything needs to be codified there.

Actually I have tried to get docs folks involved in working up some
reasonable tips and pointers for package summaries and descriptions.
So far, i haven't found interest.

I always check summaries and descriptions as part of my package
reviews, but I know that not everyone is a native speaker of English
and I wouldn't want to exclude them from the review process, so
perhaps some periodic review of these things would be useful.

 - J<



From jkeating at redhat.com  Thu Nov 20 20:26:32 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 20 Nov 2008 12:26:32 -0800
Subject: requires(post) on coreutils
In-Reply-To: <20081120202301.GA2868@free.fr>
References: <1227159559.28543.644.camel@luminos.localdomain>
	<1227201959.13169.40.camel@aglarond.local>
	<1227205642.28543.651.camel@luminos.localdomain>
	<20081120202301.GA2868@free.fr>
Message-ID: <1227212792.28543.662.camel@luminos.localdomain>

On Thu, 2008-11-20 at 21:23 +0100, Patrice Dumas wrote:
> 
> Not a chroot @core <package>, but a chroot with only the <package>
> should work well.

I'm not entirely sure that's valid, as you can't opt-out of @core in
Fedora.  You'll always have it.  You may be installing it in the same
transaction as your package in question though, and that's the bare
minimum ordering clarity that we really care about.

-- 
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/20081120/247db679/attachment.sig>

From a.badger at gmail.com  Thu Nov 20 20:25:32 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 20 Nov 2008 12:25:32 -0800
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <604aa7910811201101q2e2dc74cx5f450b25e67db47@mail.gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>	<20081120145628.GB28357@nostromo.devel.redhat.com>	<1227193973.3752.858.camel@beck.corsepiu.local>	<1227194392.4076.31.camel@hughsie-laptop>
	<49258DA7.5050808@gmail.com>	<1227198578.4076.37.camel@hughsie-laptop>
	<49259275.3000201@gmail.com>	<1227202829.4076.72.camel@hughsie-laptop>	<20081120183306.GA32047@nostromo.devel.redhat.com>	<16de708d0811201036p8f4989qe4d840ef7ad38d34@mail.gmail.com>
	<604aa7910811201101q2e2dc74cx5f450b25e67db47@mail.gmail.com>
Message-ID: <4925C7BC.2010508@gmail.com>

Jeff Spaleta wrote:
> I have a terrible headache and I'm on vacation in Hungary  for the
> first time and I go to the store looking for a society approved mind
> altering chemical substance to relieve my distress.  I walk into the
> store see a clerk and what do I ask them? Do I ask them details or do
> I ask them "where is the headache medicine."
> 
> Once I get to the Aisle where the first-aid stuff collectively sits I
> see 14 different brands of medicine, none of which I've heard of
> before because I'm in a foreign territory. I might see a brandname I
> know, but I've never before associated that brand with headache pills.
> "Uncle Ben's" branded extra strength gel-caps really doesn't call to
> me. So which one do I pick? Do I really care? Are they all just
> equally usable variants of "headache medicine" to me?  If I do care,
> like I have a specific allergic reaction that I need to avoid... I'd
> have to pick up the bottle and try to read the details...in
> Hungarian...which will ultimately result in my death because I will
> make the wrong choice unless I happen to have a translator who can
> help me read the fine print.
> 
> PackageKit is the store
> the Package groups are the Aisle
> The package name is the brand of headache medince
> The package description is the fine print on the bottle
> 
> What's the summary?

I think this is actually a great analogy.  And to me the summary is the
little advertising gimicks seen on and alongside the other things on the
bottle.

Things like: "New!",  "Larger size",  [Picture of grapes and smiling
child], etc.

They're differentiators that "help" you choose one product over another.

In our summaries, we want the advertising gimick to actually be
informative and factual so we'd automatically reject some of these as
not helpful.  But others are incredibly useful.  For instance, if I open
up PackageKit and go to the Sound and Video group, is it helpful to see:

[Sound and Video]
MPlayer -- *Media Player*
SongBird -- *Media Player*
Totem -- *Media Player*
Xine -- *Media Player*

No....  The summary needs to show differentiators that help the user
choose which one to take a look at the fine print on.  Depending on the
type of package we're looking at some of these should have different
information than others.

MPlayer -- *Feature rich media player*
SongBird -- *Media Player from the Mozilla Foundation*
Totem -- *Gstreamer based media player*
Xine -- *Customizable media player*

What's the claim to fame of each of these media players?  That piece of
identity should go in the summary.

Libraries should also make clear what programming language they're
useful for in addition to their claim to fame.  This can be done in
their name, though:

bouncycastle -- java cryptography library
m2crypto -- python library for calling OpenSSL
nss -- FIPSX.Y certified cryptography library
OpenSSL -- certificate management and cryptography library
perl-Crypt-SSLeay -- LWP https support library for OpenSSL
python-crypto -- cryptography library

There's likely other ways to make up differentiators that should be
added here as well.  That's why I requested examples with reasoning.

-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/20081120/e60babc6/attachment.sig>

From tibbs at math.uh.edu  Thu Nov 20 20:28:09 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 20 Nov 2008 14:28:09 -0600
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227202829.4076.72.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<20081120145328.GB2410@yoda.jdub.homelinux.org>
	<20081120145628.GB28357@nostromo.devel.redhat.com>
	<1227193973.3752.858.camel@beck.corsepiu.local>
	<1227194392.4076.31.camel@hughsie-laptop> <49258DA7.5050808@gmail.com>
	<1227198578.4076.37.camel@hughsie-laptop> <49259275.3000201@gmail.com>
	<1227202829.4076.72.camel@hughsie-laptop>
Message-ID: <ufaiqqim9ba.fsf@epithumia.math.uh.edu>

>>>>> "RH" == Richard Hughes <hughsient at gmail.com> writes:

RH> XQilla is an XQuery and XPath 2.0 library, built on top
RH> DeVeDe is a program to create video DVDs and CDs (VCD,

Note that I always block reviews where the package name occurs at the
beginning of the summary.  I occasionally get pushback from this,
too.  Is there any tool we have that makes the assumption that it can
just print the summary and have the package name be obvious from that?

 - J<



From cra at WPI.EDU  Thu Nov 20 20:31:23 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 20 Nov 2008 15:31:23 -0500
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <ufaiqqim9ba.fsf@epithumia.math.uh.edu>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<20081120145328.GB2410@yoda.jdub.homelinux.org>
	<20081120145628.GB28357@nostromo.devel.redhat.com>
	<1227193973.3752.858.camel@beck.corsepiu.local>
	<1227194392.4076.31.camel@hughsie-laptop>
	<49258DA7.5050808@gmail.com>
	<1227198578.4076.37.camel@hughsie-laptop>
	<49259275.3000201@gmail.com>
	<1227202829.4076.72.camel@hughsie-laptop>
	<ufaiqqim9ba.fsf@epithumia.math.uh.edu>
Message-ID: <20081120203123.GB9514@angus.ind.WPI.EDU>

On Thu, Nov 20, 2008 at 02:28:09PM -0600, Jason L Tibbitts III wrote:
> >>>>> "RH" == Richard Hughes <hughsient at gmail.com> writes:
> 
> RH> XQilla is an XQuery and XPath 2.0 library, built on top
> RH> DeVeDe is a program to create video DVDs and CDs (VCD,
> 
> Note that I always block reviews where the package name occurs at the
> beginning of the summary.  I occasionally get pushback from this,
> too.  Is there any tool we have that makes the assumption that it can
> just print the summary and have the package name be obvious from that?

I think for some packages it is helpful to expand the package 
name that is an acronym.



From pertusus at free.fr  Thu Nov 20 20:32:18 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 20 Nov 2008 21:32:18 +0100
Subject: requires(post) on coreutils
In-Reply-To: <1227212792.28543.662.camel@luminos.localdomain>
References: <1227159559.28543.644.camel@luminos.localdomain>
	<1227201959.13169.40.camel@aglarond.local>
	<1227205642.28543.651.camel@luminos.localdomain>
	<20081120202301.GA2868@free.fr>
	<1227212792.28543.662.camel@luminos.localdomain>
Message-ID: <20081120203218.GC2868@free.fr>

On Thu, Nov 20, 2008 at 12:26:32PM -0800, Jesse Keating wrote:
> On Thu, 2008-11-20 at 21:23 +0100, Patrice Dumas wrote:
> > 
> > Not a chroot @core <package>, but a chroot with only the <package>
> > should work well.
> 
> I'm not entirely sure that's valid, as you can't opt-out of @core in
> Fedora.  You'll always have it.  You may be installing it in the same
> transaction as your package in question though, and that's the bare
> minimum ordering clarity that we really care about.

Using 
yum --installroot=/some/where install package
you can have something much more minimal than @core. It may not be
fedora per se, and indeed cannot boot, but it is an install of fedora 
packages and can be useful as chroot building.

--
Pat



From a.badger at gmail.com  Thu Nov 20 20:35:19 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 20 Nov 2008 12:35:19 -0800
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081120211650.7a1c001e.mschwendt@gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>	<20081120145328.GB2410@yoda.jdub.homelinux.org>	<20081120145628.GB28357@nostromo.devel.redhat.com>	<1227193973.3752.858.camel@beck.corsepiu.local>	<1227194392.4076.31.camel@hughsie-laptop>	<49258DA7.5050808@gmail.com>	<1227198578.4076.37.camel@hughsie-laptop>	<49259275.3000201@gmail.com>	<1227202829.4076.72.camel@hughsie-laptop>	<4925BF1A.9040007@gmail.com>
	<20081120211650.7a1c001e.mschwendt@gmail.com>
Message-ID: <4925CA07.7010008@gmail.com>

Michael Schwendt wrote:
> On Thu, 20 Nov 2008 11:48:42 -0800, Toshio Kuratomi wrote:
> 
>>> For instance, the following are over long, or repeat the program name:
>>>
>>> * System daemon that is a DBUS abstraction layer for package management
>>> * XQilla is an XQuery and XPath 2.0 library, built on top of Xerces-C
>>> * DeVeDe is a program to create video DVDs and CDs (VCD, sVCD or CVD)
>>>
>>> The following would be good replacements:
>>>
>>> * Package management framework
>>> * XQuery and XPath 2.0 library
>>> * Create video DVDs and CDs
>>>
>> * It would be good to have the program name mentioned here as well.
> 
> Please don't. That has lead to many summaries, which look ugly
> if displayed next to the package name:
> 
>   name - name is a...
> 
Sorry.  I meant, mention the name in the Guideline.  Not mention the
name in the Summary:.  I agree with you 100% that package name in
summary is extraneous.

The examples in the Guideline should contain this information:

Name: XQilla
Verbose Summary: XQilla is an XQuery and XPath 2.0 library, built on top
of Xerces-C
Nice Summary: XQuery and XPath 2.0 library using Xerces-C
Notes:
* Putting package name in the summary was redundant
* Since this is a library, specifying this requires Xerces-C is a point
of differentiation.

-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/20081120/17e178a3/attachment.sig>

From mschwendt at gmail.com  Thu Nov 20 20:41:02 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 20 Nov 2008 21:41:02 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081120203123.GB9514@angus.ind.WPI.EDU>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<20081120145328.GB2410@yoda.jdub.homelinux.org>
	<20081120145628.GB28357@nostromo.devel.redhat.com>
	<1227193973.3752.858.camel@beck.corsepiu.local>
	<1227194392.4076.31.camel@hughsie-laptop>
	<49258DA7.5050808@gmail.com>
	<1227198578.4076.37.camel@hughsie-laptop>
	<49259275.3000201@gmail.com>
	<1227202829.4076.72.camel@hughsie-laptop>
	<ufaiqqim9ba.fsf@epithumia.math.uh.edu>
	<20081120203123.GB9514@angus.ind.WPI.EDU>
Message-ID: <20081120214102.2c00a745.mschwendt@gmail.com>

On Thu, 20 Nov 2008 15:31:23 -0500, Chuck Anderson wrote:

> On Thu, Nov 20, 2008 at 02:28:09PM -0600, Jason L Tibbitts III wrote:
> > >>>>> "RH" == Richard Hughes writes:
> > 
> > RH> XQilla is an XQuery and XPath 2.0 library, built on top
> > RH> DeVeDe is a program to create video DVDs and CDs (VCD,
> > 
> > Note that I always block reviews where the package name occurs at the
> > beginning of the summary.  I occasionally get pushback from this,
> > too.  Is there any tool we have that makes the assumption that it can
> > just print the summary and have the package name be obvious from that?
> 
> I think for some packages it is helpful to expand the package 
> name that is an acronym.

Of course. I'd bet that often the expanded acronym is a good or
sufficient summary. Such as:

  gimp - GNU Image Manipulation Program



From a.badger at gmail.com  Thu Nov 20 20:28:02 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 20 Nov 2008 12:28:02 -0800
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081120194814.GQ24297@angus.ind.WPI.EDU>
References: <20081120145628.GB28357@nostromo.devel.redhat.com>	<1227193973.3752.858.camel@beck.corsepiu.local>	<1227194392.4076.31.camel@hughsie-laptop>	<49258DA7.5050808@gmail.com>	<1227198578.4076.37.camel@hughsie-laptop>	<49259275.3000201@gmail.com>	<1227202829.4076.72.camel@hughsie-laptop>	<20081120183306.GA32047@nostromo.devel.redhat.com>	<16de708d0811201036p8f4989qe4d840ef7ad38d34@mail.gmail.com>	<604aa7910811201101q2e2dc74cx5f450b25e67db47@mail.gmail.com>
	<20081120194814.GQ24297@angus.ind.WPI.EDU>
Message-ID: <4925C852.1040904@gmail.com>

Chuck Anderson wrote:
> On Thu, Nov 20, 2008 at 10:01:14AM -0900, Jeff Spaleta wrote:
>> PackageKit is the store
>> the Package groups are the Aisle
>> The package name is the brand of headache medince
>> The package description is the fine print on the bottle
>>
>> What's the summary?
> 
> The sign above the aisle that says "headache medicine"?  Or perhaps 
> the sign on the shelf itself?
> 
> Or, it could be the smaller title below the brand name on the bottle 
> that says "headache and pain relief".  Generally the brand name is the 
> most prominent title, which would suggest that the Package Name should 
> be larger/more prominent in PackageKit than the Summary.
> 

I'd argue that's what Groups are for.  In jef's analogy, it's the Aisle
which your "sign above the aisle" reflects.

-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/20081120/614afd23/attachment.sig>

From kevin.kofler at chello.at  Thu Nov 20 20:44:37 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 20 Nov 2008 21:44:37 +0100
Subject: RFC: fix summary text for lots of packages
References: <1227191607.4076.29.camel@hughsie-laptop>
Message-ID: <gg4i7l$ek6$1@ger.gmane.org>

Richard Hughes wrote:
> Broken packages are a problem as PackageKit shows the summary first (in
> bold) in preference to the package name. This is by design.

s/PackageKit/gnome-packagekit/
FYI, KPackageKit does the exact opposite (at least the version now in F9
updates-testing).
This is a UI design decision, not a decision at the PackageKit level.
Different PackageKit frontends show things differently.

        Kevin Kofler



From skvidal at fedoraproject.org  Thu Nov 20 20:48:41 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 20 Nov 2008 15:48:41 -0500 (EST)
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <gg4i7l$ek6$1@ger.gmane.org>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<gg4i7l$ek6$1@ger.gmane.org>
Message-ID: <alpine.LFD.2.00.0811201547270.16994@localhost.localdomain>



On Thu, 20 Nov 2008, Kevin Kofler wrote:

> Richard Hughes wrote:
>> Broken packages are a problem as PackageKit shows the summary first (in
>> bold) in preference to the package name. This is by design.
>
> s/PackageKit/gnome-packagekit/
> FYI, KPackageKit does the exact opposite (at least the version now in F9
> updates-testing).
> This is a UI design decision, not a decision at the PackageKit level.
> Different PackageKit frontends show things differently.


you know, we really need an abstraction layer above gnome-PK and KPK that 
allows us to provide a unified, common interface to 
installing/updating/etc pkgs. ;)

</snark>

-sv



From jkeating at redhat.com  Thu Nov 20 20:50:22 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 20 Nov 2008 12:50:22 -0800
Subject: requires(post) on coreutils
In-Reply-To: <20081120203218.GC2868@free.fr>
References: <1227159559.28543.644.camel@luminos.localdomain>
	<1227201959.13169.40.camel@aglarond.local>
	<1227205642.28543.651.camel@luminos.localdomain>
	<20081120202301.GA2868@free.fr>
	<1227212792.28543.662.camel@luminos.localdomain>
	<20081120203218.GC2868@free.fr>
Message-ID: <1227214222.28543.663.camel@luminos.localdomain>

On Thu, 2008-11-20 at 21:32 +0100, Patrice Dumas wrote:
> Using 
> yum --installroot=/some/where install package
> you can have something much more minimal than @core. It may not be
> fedora per se, and indeed cannot boot, but it is an install of fedora 
> packages and can be useful as chroot building.

*shrug* try it on a few packages and see what kind of fallout you 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/20081120/c447a1af/attachment.sig>

From pertusus at free.fr  Thu Nov 20 20:56:43 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 20 Nov 2008 21:56:43 +0100
Subject: requires(post) on coreutils
In-Reply-To: <1227214222.28543.663.camel@luminos.localdomain>
References: <1227159559.28543.644.camel@luminos.localdomain>
	<1227201959.13169.40.camel@aglarond.local>
	<1227205642.28543.651.camel@luminos.localdomain>
	<20081120202301.GA2868@free.fr>
	<1227212792.28543.662.camel@luminos.localdomain>
	<20081120203218.GC2868@free.fr>
	<1227214222.28543.663.camel@luminos.localdomain>
Message-ID: <20081120205643.GE2868@free.fr>

On Thu, Nov 20, 2008 at 12:50:22PM -0800, Jesse Keating wrote:
> On Thu, 2008-11-20 at 21:32 +0100, Patrice Dumas wrote:
> > Using 
> > yum --installroot=/some/where install package
> > you can have something much more minimal than @core. It may not be
> > fedora per se, and indeed cannot boot, but it is an install of fedora 
> > packages and can be useful as chroot building.
> 
> *shrug* try it on a few packages and see what kind of fallout you get.

I did and it was quite right. Some packages don't bring in a shell at
all, mostly doc packages, but otherwise packages requiring glibc
requires bash, and, if I recall well also coreutils. But no need for
rpm, for example which is nice in a chroot.

--
Pat



From ivazqueznet at gmail.com  Thu Nov 20 21:02:14 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Thu, 20 Nov 2008 16:02:14 -0500
Subject: source file audit - 2008-11-14
In-Reply-To: <1227161243.736.107.camel@ignacio.lan>
References: <20081119170909.29694973@ohm.scrye.com>
	<1227161243.736.107.camel@ignacio.lan>
Message-ID: <1227214934.736.152.camel@ignacio.lan>

On Thu, 2008-11-20 at 01:07 -0500, Ignacio Vazquez-Abrams wrote:
> On Wed, 2008-11-19 at 17:09 -0700, Kevin Fenzi wrote:
> > ivazquez:BADURL:purple-plugin_pack-2.4.0.tar.bz2:purple-plugin_pack
> 
> This is upstream being... something. I'll have to have a chat with them.

Fixed thanks to Stu Tomlinson.

-- 
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/20081120/ac4ad0c7/attachment.sig>

From a.badger at gmail.com  Thu Nov 20 21:05:59 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 20 Nov 2008 13:05:59 -0800
Subject: What do we need from Bugzilla?
In-Reply-To: <4925C72D.9030605@gmail.com>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>	<6aufv5xi4u.ln2@ppp1053.in.ipex.cz>	<7deeb2190ab5fc7bff30a343cc9e5c49.squirrel@arekh.dyndns.org>	<4925B2FE.2030408@redhat.com>	<16de708d0811201102x33182e70wcba145890f61209c@mail.gmail.com>	<1227210339.28543.655.camel@luminos.localdomain>
	<4925C72D.9030605@gmail.com>
Message-ID: <4925D137.4010004@gmail.com>

Les Mikesell wrote:
> Jesse Keating wrote:
>> On Thu, 2008-11-20 at 13:02 -0600, Arthur Pemberton wrote:
>>> Agreed. Which is one of the major driving factors for this
>>> questionnaire thread. I figure Bugzilla must be doing some things
>>> right.
>>
>> It's not that it's doing things right, it's just too cost prohibitive to
>> create something else to do the same things in the same predictably
>> wrong way (:
> 
> That's actually pretty funny when compared to the reaction I get here to
> comments regarding API and functional changes in fedora itself.
> 
> But, lots of people like trac these days.
> 
trac has some good features and some bad ones too:

It's UI is poor because it hides things like "new ticket" unless you're
logged in.

It has no protection against mid-air collisions.

If you hit the back button or a link by mistake, you can't go back to
the previous page and have your painstakingly entered comment still be
there.

yadda yadda.
-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/20081120/e325005c/attachment.sig>

From a.badger at gmail.com  Thu Nov 20 21:12:57 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 20 Nov 2008 13:12:57 -0800
Subject: requires(post) on coreutils
In-Reply-To: <4925B087.6000501@redhat.com>
References: <1227159559.28543.644.camel@luminos.localdomain>	<1227201959.13169.40.camel@aglarond.local>
	<4925B087.6000501@redhat.com>
Message-ID: <4925D2D9.3000301@gmail.com>

Casey Dahlin wrote:
> Jeremy Katz wrote:
>> On Wed, 2008-11-19 at 21:39 -0800, Jesse Keating wrote:
>>  
>>> I just attempted to compose the Games spin for Fedora 10, and ran into a
>>> number of packages that fail their %post scripts due to missing one
>>> thing or another out of coreutils (such as ln, rm, file, etc..) and it
>>> has me wondering what might have changed in recent time so that
>>> coreutils wouldn't be installed earlier in the transaction.  This seems
>>> like something that would have been noticed before, but maybe it's just
>>> in the particular package set that the games spin has.
>>>     
>>
>> It's actually a pretty common phenomenon related to packagers thinking
>> they're "always" there because they are except in the case of new
>> installs.  coreutils is actually surprisingly late in install order and
>> so there are pretty frequent packages which pop up expecting otherwise
>> (and there always have been; I've been filing bugs about them for longer
>> than I like to remember :-)
>>
>> Jeremy
>>
>>   
> We can look at binaries to see what libs they need, can we not look at
> %post scripts and figure out if coreutils is required?
> 
conditionals mess things up in %post scripts.

-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/20081120/e7fd1aea/attachment.sig>

From skvidal at fedoraproject.org  Thu Nov 20 21:15:54 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 20 Nov 2008 16:15:54 -0500 (EST)
Subject: What do we need from Bugzilla?
In-Reply-To: <4925D137.4010004@gmail.com>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<6aufv5xi4u.ln2@ppp1053.in.ipex.cz>
	<7deeb2190ab5fc7bff30a343cc9e5c49.squirrel@arekh.dyndns.org>
	<4925B2FE.2030408@redhat.com>
	<16de708d0811201102x33182e70wcba145890f61209c@mail.gmail.com>
	<1227210339.28543.655.camel@luminos.localdomain>
	<4925C72D.9030605@gmail.com> <4925D137.4010004@gmail.com>
Message-ID: <alpine.LFD.2.00.0811201615271.16994@localhost.localdomain>



On Thu, 20 Nov 2008, Toshio Kuratomi wrote:

> Les Mikesell wrote:
>> Jesse Keating wrote:
>>> On Thu, 2008-11-20 at 13:02 -0600, Arthur Pemberton wrote:
>>>> Agreed. Which is one of the major driving factors for this
>>>> questionnaire thread. I figure Bugzilla must be doing some things
>>>> right.
>>>
>>> It's not that it's doing things right, it's just too cost prohibitive to
>>> create something else to do the same things in the same predictably
>>> wrong way (:
>>
>> That's actually pretty funny when compared to the reaction I get here to
>> comments regarding API and functional changes in fedora itself.
>>
>> But, lots of people like trac these days.
>>
> trac has some good features and some bad ones too:
>
> It's UI is poor because it hides things like "new ticket" unless you're
> logged in.

or if you edit the perms to allow anon users to add tickets.


-sv



From ville.skytta at iki.fi  Thu Nov 20 21:19:22 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Thu, 20 Nov 2008 23:19:22 +0200
Subject: Removing "minimal buildroot" dependencies from rpmdevtools
In-Reply-To: <1227212656.28543.660.camel@luminos.localdomain>
References: <200811102351.47926.ville.skytta@iki.fi>
	<200811202213.38033.ville.skytta@iki.fi>
	<1227212656.28543.660.camel@luminos.localdomain>
Message-ID: <200811202319.23089.ville.skytta@iki.fi>

On Thursday 20 November 2008, Jesse Keating wrote:
>
> If the other depsolvers don't handle comps, they're rather useless in
> the Fedora world, 

I don't think support for any kind of special grouping is a prerequisite for a 
depsolver to be useful.  I don't remember ever missing that feature when I 
used apt/smart, and now that I've been using mostly yum for a while, I don't 
remember ever invoking any of its group* commands.  Plain old metapackages 
have worked well for me in the (quite rare) cases where I've needed something 
like that.  comps/yum grouping have their own valid purposes for different 
use cases, but saying a depsolver without support for that is rather useless 
is in my opinion more than a little extreme.

> where are grouping is done exclusively via comps.

Not really - we also have metapackages for grouping and new ones do get 
introduced every now and then.  See for example git-all, perl-core, R.



From pertusus at free.fr  Thu Nov 20 20:26:43 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 20 Nov 2008 21:26:43 +0100
Subject: requires(post) on coreutils
In-Reply-To: <faa16b610811201056p565b8488q6214731bba98c61b@mail.gmail.com>
References: <1227159559.28543.644.camel@luminos.localdomain>
	<1227201959.13169.40.camel@aglarond.local>
	<4925B087.6000501@redhat.com>
	<faa16b610811201056p565b8488q6214731bba98c61b@mail.gmail.com>
Message-ID: <20081120202643.GB2868@free.fr>

On Thu, Nov 20, 2008 at 01:56:24PM -0500, Colin Walters wrote:
> On Thu, Nov 20, 2008 at 1:46 PM, Casey Dahlin <cdahlin at redhat.com> wrote:
> >
> >
> > We can look at binaries to see what libs they need, can we not look at %post
> > scripts and figure out if coreutils is required?
> 
> Or have a two phase install, one where we put the minimum OS down, and
> the second where we install your apps.  Come on - coreutils isn't an
> addon package.

Install of any single package in a chroot should not be broken.
It even should be functional in most cases. Like
yum --installroot=/some/where package
with an empty /some/where

--
Pat



From jspaleta at gmail.com  Thu Nov 20 21:20:47 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 20 Nov 2008 12:20:47 -0900
Subject: What do we need from Bugzilla?
In-Reply-To: <alpine.LFD.2.00.0811201615271.16994@localhost.localdomain>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<6aufv5xi4u.ln2@ppp1053.in.ipex.cz>
	<7deeb2190ab5fc7bff30a343cc9e5c49.squirrel@arekh.dyndns.org>
	<4925B2FE.2030408@redhat.com>
	<16de708d0811201102x33182e70wcba145890f61209c@mail.gmail.com>
	<1227210339.28543.655.camel@luminos.localdomain>
	<4925C72D.9030605@gmail.com> <4925D137.4010004@gmail.com>
	<alpine.LFD.2.00.0811201615271.16994@localhost.localdomain>
Message-ID: <604aa7910811201320p2284bb35w6372237b7b85197c@mail.gmail.com>

On Thu, Nov 20, 2008 at 12:15 PM, Seth Vidal <skvidal at fedoraproject.org> wrote:
> or if you edit the perms to allow anon users to add tickets.

i think the point was from a UI standpoint...even if you want people
to login before letting their ticket in the system..its still a good
idea to expose the new ticket button even if the new ticket button
then throws you to a login/registration screen.

-jef



From jkeating at redhat.com  Thu Nov 20 21:25:57 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 20 Nov 2008 13:25:57 -0800
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <alpine.LFD.2.00.0811201547270.16994@localhost.localdomain>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<gg4i7l$ek6$1@ger.gmane.org>
	<alpine.LFD.2.00.0811201547270.16994@localhost.localdomain>
Message-ID: <1227216357.28543.664.camel@luminos.localdomain>

On Thu, 2008-11-20 at 15:48 -0500, Seth Vidal wrote:
> 
> you know, we really need an abstraction layer above gnome-PK and KPK that 
> allows us to provide a unified, common interface to 
> installing/updating/etc pkgs. ;)

PackageKitUIKitKit

-- 
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/20081120/01f5c860/attachment.sig>

From notting at redhat.com  Thu Nov 20 21:33:16 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 20 Nov 2008 16:33:16 -0500
Subject: What do we need from Bugzilla?
In-Reply-To: <4925D137.4010004@gmail.com>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<6aufv5xi4u.ln2@ppp1053.in.ipex.cz>
	<7deeb2190ab5fc7bff30a343cc9e5c49.squirrel@arekh.dyndns.org>
	<4925B2FE.2030408@redhat.com>
	<16de708d0811201102x33182e70wcba145890f61209c@mail.gmail.com>
	<1227210339.28543.655.camel@luminos.localdomain>
	<4925C72D.9030605@gmail.com> <4925D137.4010004@gmail.com>
Message-ID: <20081120213316.GA25015@nostromo.devel.redhat.com>

Toshio Kuratomi (a.badger at gmail.com) said: 
> It's UI is poor because it hides things like "new ticket" unless you're
> logged in.
> 
> It has no protection against mid-air collisions.

Its comment widget expects raw HTML. 

IMO, bugzilla's much like democracy - it's the worst form
of bug trackers, except for all the others.

Bill



From dcbw at redhat.com  Thu Nov 20 21:39:45 2008
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 20 Nov 2008 16:39:45 -0500
Subject: What do we need from Bugzilla?
In-Reply-To: <4925D137.4010004@gmail.com>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<6aufv5xi4u.ln2@ppp1053.in.ipex.cz>
	<7deeb2190ab5fc7bff30a343cc9e5c49.squirrel@arekh.dyndns.org>
	<4925B2FE.2030408@redhat.com>
	<16de708d0811201102x33182e70wcba145890f61209c@mail.gmail.com>
	<1227210339.28543.655.camel@luminos.localdomain>
	<4925C72D.9030605@gmail.com>  <4925D137.4010004@gmail.com>
Message-ID: <1227217185.15582.47.camel@localhost.localdomain>

On Thu, 2008-11-20 at 13:05 -0800, Toshio Kuratomi wrote:
> Les Mikesell wrote:
> > Jesse Keating wrote:
> >> On Thu, 2008-11-20 at 13:02 -0600, Arthur Pemberton wrote:
> >>> Agreed. Which is one of the major driving factors for this
> >>> questionnaire thread. I figure Bugzilla must be doing some things
> >>> right.
> >>
> >> It's not that it's doing things right, it's just too cost prohibitive to
> >> create something else to do the same things in the same predictably
> >> wrong way (:
> > 
> > That's actually pretty funny when compared to the reaction I get here to
> > comments regarding API and functional changes in fedora itself.
> > 
> > But, lots of people like trac these days.
> > 
> trac has some good features and some bad ones too:
> 
> It's UI is poor because it hides things like "new ticket" unless you're
> logged in.
> 
> It has no protection against mid-air collisions.
> 
> If you hit the back button or a link by mistake, you can't go back to
> the previous page and have your painstakingly entered comment still be
> there.

It's search is great for new users, but horrible when you are trying to
track down something specific that may not be listed in the bug's
content.

For many people, wiki formatting of the text is rarely what they want,
and for others, it's just what they want.  I can't tell you how many
times I've forgotten to {{{ ... }}} to ensure the text I paste in isn't
re-formatted.  But sometimes I do want wiki format.  Maybe if Trac had a
user preference for your default format connected to your login ID.

Dan



From pingou at pingoured.fr  Thu Nov 20 21:34:41 2008
From: pingou at pingoured.fr (Pierre-Yves)
Date: Thu, 20 Nov 2008 22:34:41 +0100
Subject: source file audit - 2008-11-14
In-Reply-To: <20081119170909.29694973@ohm.scrye.com>
References: <20081119170909.29694973@ohm.scrye.com>
Message-ID: <4925D7F1.9010801@pingoured.fr>

Kevin Fenzi wrote:

> pingou:BADURL:affyio_1.10.0.tar.gz:R-affyio
> pingou:BADURL:Biobase_2.2.0.tar.gz:R-Biobase
> pingou:BADURL:guake-0.3.1.tar.gz:guake

Fixed all three :)

Regards,

Pierre



From benny+usenet at amorsen.dk  Thu Nov 20 21:46:23 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Thu, 20 Nov 2008 22:46:23 +0100
Subject: F11 Proposal: Stabilization
In-Reply-To: <1227107778.28543.53.camel@luminos.localdomain> (Jesse Keating's
	message of "Wed\, 19 Nov 2008 07\:16\:18 -0800")
References: <1226957727.4098.15.camel@perihelion.bos.jonmasters.org>
	<1226958439.3814.6.camel@localhost.localdomain>
	<49232E89.6020400@redhat.com>
	<1227043890.28543.18.camel@luminos.localdomain>
	<49233BE6.3080808@redhat.com>
	<1227046097.28543.21.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811181710530.1236@localhost.localdomain>
	<49234CE6.7050805@gmail.com>
	<604aa7910811181554q238d59ber63bf99565a37558e@mail.gmail.com>
	<492359B2.2010008@gmail.com>
	<604aa7910811181622q6d2b7f92kf20853a6c9f8c2f1@mail.gmail.com>
	<492378C7.6050408@gmail.com>
	<1227064591.28543.34.camel@luminos.localdomain>
	<m38wrgqdcb.fsf@ursa.amorsen.dk>
	<1227107778.28543.53.camel@luminos.localdomain>
Message-ID: <m3d4gqkr4g.fsf@ursa.amorsen.dk>

Jesse Keating <jkeating at redhat.com> writes:

> How often have you ran into bad updates that are just thrown away,
> rather than fixed?  (and by fixed I mean either the bug caused in the
> update has been fixed with even newer bits, or the old bits were
> re-issued with higher e:n-v-r)

>From that question I gather that this is uncommon. Very well, I am
enabling updates-testing now in a few places. We'll see how it goes.


/Benny



From mschwendt at gmail.com  Thu Nov 20 22:16:46 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 20 Nov 2008 23:16:46 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1542747735.1556741227211137110.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
References: <1274542974.1556651227211114704.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1542747735.1556741227211137110.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <20081120231646.715d2cf7.mschwendt@gmail.com>

On Thu, 20 Nov 2008 14:58:57 -0500 (EST), Michal Hlavinka wrote:

> yes, but... example: you need some email client, so...
> yum search mail
> and you get:
> evolution-email client
> kmail-client for email
> mutt-mail agent
> squirrelmail-mail client
> 
> these summaries will be really short but really useless. 

No, your example is useless. "yum search mail" is way too generic to
even return anything useful.

$ sudo yum search mail|wc -l
368

And  yum search "mail client"  is too specific and only finds 23 packages,
missing kmail and evolution. ;-p

The query answer you've posted is not matching reality. Some 
examples:

  compface.i386 : Utilities for handling X-Faces
  mutt.i386 : A text mode mail user agent
  squirrelmail.noarch : SquirrelMail webmail client
  sylpheed.i386 : GTK+ based, lightweight, and fast email client

> You can't choose any package just from summary but you
> need to go one by one with yum info package.

Aha, and just because Yum's searching capabilities are so basic, you
want to squeeze more stuff into the summaries? Mind you, Yum also
searches the package _descriptions_, so naturally it hits more packages
the more strings you search for.

> IMHO summary should be descriptive enough to tell you not only difference between mutt and nut.
>

How far can we go? What details do you want to squeeze into the
summary? Imagine that with end-user GUI tools, the description and
other package details are just a click away.
 
> So again, if PackageKit is broken fix PackageKit, not everything else.

That applies to the length of the lines, yes. Being able to display
at most 80 chars per line is not asked too much. If PackageKit thinks
it must truncate pkg summaries, then let it do that instead of trying
to impose more restrictions on the packages. That discussion is
independent from trying to improve our guidelines, IMO.

> Do you really want to fix all these because of... what exactly? because summary is "too" descriptive?
> 

No, but there are summaries which are less useful because they are
too descriptive. :)



From skvidal at fedoraproject.org  Thu Nov 20 22:23:59 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 20 Nov 2008 17:23:59 -0500 (EST)
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081120231646.715d2cf7.mschwendt@gmail.com>
References: <1274542974.1556651227211114704.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1542747735.1556741227211137110.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<20081120231646.715d2cf7.mschwendt@gmail.com>
Message-ID: <alpine.LFD.2.00.0811201723190.21794@localhost.localdomain>



On Thu, 20 Nov 2008, Michael Schwendt wrote:

>
>> You can't choose any package just from summary but you
>> need to go one by one with yum info package.
>
> Aha, and just because Yum's searching capabilities are so basic, you
> want to squeeze more stuff into the summaries? Mind you, Yum also
> searches the package _descriptions_, so naturally it hits more packages
> the more strings you search for.

what other features would you want to advance yum's searching?

-sv



From jkeating at redhat.com  Thu Nov 20 22:45:12 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 20 Nov 2008 14:45:12 -0800
Subject: Tie a bow on it!
Message-ID: <1227221113.28543.678.camel@luminos.localdomain>

Folks, I've just set the directory permissions
on /pub/fedora/linux/releases/10 so that our mirror system can sync it.
This is it, 10 is in the can!  On Tuesday we'll set the permissions so
that the whole world can get their hands on Fedora 10.

It has been a long and strange road, with unexpected bumps and detours,
but we've gotten through it and produced yet another rockin' release.
Everybody should take a moment or three and collectively pat yourselves
on the back.  You've earned it.

So what happens now?  Tomorrow I'll be attempting to do the first push
of Fedora 10 updates.  This will let us ensure that particular system is
working, and get you folks still running "rawhide" first crack at the
0-day updates.  The redirect in place that sends requests for Fedora 10
updates to rawhide will be disabled in mirromanager so that you can
consume the real Fedora 10 updates.  Shortly before 10 goes live, we'll
let loose all the F11 packages into rawhide and disable that redirect as
well.  Folks may have a day or 3 where they don't have yum access to the
whole of Fedora 10 content, but that's fine.

Then we start this whole she-bang all over again with Fedora 11.  A full
Fedora 11 schedule should be coming soon, and we've got some interesting
proposals for that which will hopefully make the ride smoother (as we
always try).

Thanks again for all your work, have a frosty beverage of our choice in
the name of Fedora!

-- 
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/20081120/1512d7f6/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 mschwendt at gmail.com  Thu Nov 20 22:55:57 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 20 Nov 2008 23:55:57 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <alpine.LFD.2.00.0811201723190.21794@localhost.localdomain>
References: <1274542974.1556651227211114704.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1542747735.1556741227211137110.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<20081120231646.715d2cf7.mschwendt@gmail.com>
	<alpine.LFD.2.00.0811201723190.21794@localhost.localdomain>
Message-ID: <20081120235557.7472e5a5.mschwendt@gmail.com>

On Thu, 20 Nov 2008 17:23:59 -0500 (EST), Seth Vidal wrote:

> what other features would you want to advance yum's searching?

To print context also for matches where the search strings are found in
the description -- and print the 1-2 first lines of the description for
all listed packages. That would make it more obvious which results are
relevant. Here it highlights the matched string in the summaries, but
descriptions that match are not printed.

$ yum search "mail client"
Loaded plugins: refresh-packagekit
============================= Matched: mail client =============================
mutt.i386 : A text mode mail user agent
kdepim.i386 : PIM (Personal Information Manager) applications
abook.i386 : Text-based addressbook program for mutt
balsa.i386 : Mail Client
claws-mail.i386 : The extended version of Sylpheed
claws-mail-plugins-perl.i386 : Extended filtering engine
compface.i386 : Utilities for handling X-Faces
cone-devel.i386 : LibMAIL mail client development library
cone-doc.i386 : Documentation for the CONE email client
evolution-rspam.i386 : Evolution Plugin for reporting spam
fetchmail.i386 : A remote mail retrieval and forwarding utility
ksig.i386 : A graphical application to manage multiple email signatures
phpwapmail.noarch : WAP-based e-mail client
roundcubemail.noarch : Round Cube Webmail is a browser-based multilingual IMAP
                     : client
ruby-revolution.i386 : Ruby binding for the Evolution email client
squirrelmail.noarch : SquirrelMail webmail client
sylpheed.i386 : GTK+ based, lightweight, and fast email client
thunderbird-lightning.i386 : The calendar extension to Thunderbird
tmda-ofmipd.noarch : Tagged Message Delivery Agent - ofmipd server
up-imapproxy.i386 : University of Pittsburgh IMAP Proxy



From nicolas.mailhot at laposte.net  Thu Nov 20 22:57:56 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 20 Nov 2008 23:57:56 +0100
Subject: What do we need from Bugzilla?
In-Reply-To: <4925D137.4010004@gmail.com>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<6aufv5xi4u.ln2@ppp1053.in.ipex.cz>
	<7deeb2190ab5fc7bff30a343cc9e5c49.squirrel@arekh.dyndns.org>
	<4925B2FE.2030408@redhat.com>
	<16de708d0811201102x33182e70wcba145890f61209c@mail.gmail.com>
	<1227210339.28543.655.camel@luminos.localdomain>
	<4925C72D.9030605@gmail.com>  <4925D137.4010004@gmail.com>
Message-ID: <1227221876.31247.1.camel@arekh.okg>

Le jeudi 20 novembre 2008 ? 13:05 -0800, Toshio Kuratomi a ?crit :
> Les Mikesell wrote:
> lots of people like trac these days.
> > 
> trac has some good features and some bad ones too:
> 
> It's UI is poor because it hides things like "new ticket" unless you're
> logged in.

Trac is fine for a small project. For a big project? It does not even
have an easy way for reporters to list the tickets they've submitted
before.

-- 
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/20081120/fd1318c9/attachment.sig>

From skvidal at fedoraproject.org  Thu Nov 20 22:58:46 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 20 Nov 2008 17:58:46 -0500 (EST)
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081120235557.7472e5a5.mschwendt@gmail.com>
References: <1274542974.1556651227211114704.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1542747735.1556741227211137110.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<20081120231646.715d2cf7.mschwendt@gmail.com>
	<alpine.LFD.2.00.0811201723190.21794@localhost.localdomain>
	<20081120235557.7472e5a5.mschwendt@gmail.com>
Message-ID: <alpine.LFD.2.00.0811201758250.21794@localhost.localdomain>



On Thu, 20 Nov 2008, Michael Schwendt wrote:

> On Thu, 20 Nov 2008 17:23:59 -0500 (EST), Seth Vidal wrote:
>
>> what other features would you want to advance yum's searching?
>
> To print context also for matches where the search strings are found in
> the description -- and print the 1-2 first lines of the description for
> all listed packages. That would make it more obvious which results are
> relevant. Here it highlights the matched string in the summaries, but
> descriptions that match are not printed.


yum search -v mail client


-sv



From stickster at gmail.com  Thu Nov 20 23:09:50 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Thu, 20 Nov 2008 18:09:50 -0500
Subject: Thank you and congratulations
Message-ID: <20081120230950.GK10192@localhost.localdomain>

Now that the bits are on their way to the tubes, I want to say a word
or three of thanks to our contributors for an exceptional release, and
all of the thought, discussion, and action that went into it.  Ten
releases in five years is a huge achievement, and we all have great
reasons to be proud of it.  Let's look forward to next Tuesday's
release of Fedora 10 with a sense of both pride and promise, and an
understanding that there is more and better to come.

I have more to say about this, but I'll save it for the planet so as
not to clog up this channel.  Congratulations to the entire Fedora
community!

-- 
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/20081120/09a78f5f/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 qixi17998 at gmail.com  Thu Nov 20 23:31:13 2008
From: qixi17998 at gmail.com (=?gb2312?Q?=D0=FB=D4=C6=BB=D4?=)
Date: Fri, 21 Nov 2008 07:31:13 +0800
Subject: when plan add python2.6 or python3.0
Message-ID: <1227223873.3732.1.camel@localhost.localdomain>

when plan add python2.6 or python3.0
in fedora 11 or fedora 12?



From mschwendt at gmail.com  Thu Nov 20 23:46:22 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 21 Nov 2008 00:46:22 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <alpine.LFD.2.00.0811201758250.21794@localhost.localdomain>
References: <1274542974.1556651227211114704.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1542747735.1556741227211137110.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<20081120231646.715d2cf7.mschwendt@gmail.com>
	<alpine.LFD.2.00.0811201723190.21794@localhost.localdomain>
	<20081120235557.7472e5a5.mschwendt@gmail.com>
	<alpine.LFD.2.00.0811201758250.21794@localhost.localdomain>
Message-ID: <20081121004622.ddde2925.mschwendt@gmail.com>

On Thu, 20 Nov 2008 17:58:46 -0500 (EST), Seth Vidal wrote:

> 
> 
> On Thu, 20 Nov 2008, Michael Schwendt wrote:
> 
> > On Thu, 20 Nov 2008 17:23:59 -0500 (EST), Seth Vidal wrote:
> >
> >> what other features would you want to advance yum's searching?
> >
> > To print context also for matches where the search strings are found in
> > the description -- and print the 1-2 first lines of the description for
> > all listed packages. That would make it more obvious which results are
> > relevant. Here it highlights the matched string in the summaries, but
> > descriptions that match are not printed.
> 
> 
> yum search -v mail client

The quotes are important here (or else you get output for almost 400
pkgs). I tried: yum search -v "mail client"

It prints _full_ (!) descriptions, lots of empty lines (probably trying to
improve readability), superfluous "Matched from:" lines (which make it
less readable), a "Description" column that makes it less readable,
debug output at the top.

| thunderbird-lightning.i386 : The calendar extension to Thunderbird
| Matched from:
| Description : Lightning brings the Sunbird calendar to the popular email
|             : client, Mozilla Thunderbird. Since it's an extension,
|             : Lightning is tightly integrated with Thunderbird, allowing it to
|             : easily perform email-related calendaring tasks.

Better IMO would be something similar to:

thunderbird-lightning.i386 : The calendar extension to Thunderbird

          Lightning brings the Sunbird calendar to the popular email
          client, Mozilla Thunderbird. Since it's an extension, [...]

tmda-ofmipd.noarch : Tagged Message Delivery Agent - ofmipd server

          TMDA is an open source anti-spam system and local mail delivery
          agent.  tmda-ofmipd is an async I/O based authenticated ofmip
          proxy for TMDA. This allows users of any mail client [...]



From dr.diesel at gmail.com  Thu Nov 20 23:55:14 2008
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Thu, 20 Nov 2008 18:55:14 -0500
Subject: Thank you and congratulations
In-Reply-To: <20081120230950.GK10192@localhost.localdomain>
References: <20081120230950.GK10192@localhost.localdomain>
Message-ID: <2a28d2ab0811201555nc144972o8966e023b731dc28@mail.gmail.com>

2008/11/20 Paul W. Frields <stickster at gmail.com>

> Now that the bits are on their way to the tubes, I want to say a word
> or three of thanks to our contributors for an exceptional release, and
> all of the thought, discussion, and action that went into it.  Ten
> releases in five years is a huge achievement, and we all have great
> reasons to be proud of it.  Let's look forward to next Tuesday's
> release of Fedora 10 with a sense of both pride and promise, and an
> understanding that there is more and better to come.
>
> I have more to say about this, but I'll save it for the planet so as
> not to clog up this channel.  Congratulations to the entire Fedora
> community!
>

I must agree!  My first experience with Linux was Fedora Core 1 as a simple
curiosity, today it is an absolute passion, all due to the Fedora project!

Many many thanks to all involved..

Andy



-- 
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/20081120/f9f9eb61/attachment.htm>

From tcallawa at redhat.com  Fri Nov 21 00:01:13 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 20 Nov 2008 19:01:13 -0500
Subject: source file audit - 2008-11-14
In-Reply-To: <20081119170909.29694973@ohm.scrye.com>
References: <20081119170909.29694973@ohm.scrye.com>
Message-ID: <1227225673.26058.187.camel@localhost.localdomain>

On Wed, 2008-11-19 at 17:09 -0700, Kevin Fenzi wrote:
> spot:BADSOURCE:daa2iso.zip:daa2iso

Upstream doesn't embed version in their zip file, they just do new
releases with the same filename, which causes this. I emailed them to
ask them not to do that, but they replied that they like it like that.
This also pointed out that upstream had done a new release, so I pushed
an update.

> spot:BADSOURCE:lout-3.37.tar.gz:lout

Not sure why this one failed, but 3.38 is out, so I did an update.

> spot:BADSOURCE:ql2300_fw.bin:ql23xx-firmware
> spot:BADSOURCE:ql2322_fw.bin:ql23xx-firmware
> spot:BADSOURCE:ql2400_fw.bin:ql2400-firmware
> spot:BADSOURCE:ql2500_fw.bin:ql2500-firmware

Qlogic did a new firmware drop. I made updates.

> spot:BADSOURCE:srecord-1.39.tar.gz:srecord

Upstream did a new release, so I made an update.

> spot:BADURL:alsamixergui-0.9.0rc1-2.tar.gz:alsamixergui

upstream website is gone.

> spot:BADURL:amanith_03.tar.gz:amanith

upstream is no longer working on this code and has taken it down.

> spot:BADURL:Class-DBI-Loader-Relationship-1.3.tar.gz:perl-Class-DBI-Loader-Relationship

Umm. I'm not sure how I ended up with a version that CPAN doesn't know
about, but it seems legit.

> spot:BADURL:Class-DBI-Pg-0.09.tar.gz:perl-Class-DBI-Pg

CPAN owner changed, thus, sourceurl changed. Fixed in rawhide.

> spot:BADURL:Config-IniFiles-2.39.tar.gz:perl-Config-IniFiles

Since I can't figure this one out, I migrated rawhide to a SVN checkout.

> spot:BADURL:google-perftools-0.99.1.tar.gz:google-perftools

I'm guessing this was due to your googlecode burping.

> spot:BADURL:hdf5_1.6.7.tar.gz:R-hdf5

New version released, made an update.

> spot:BADURL:HTML-Tree-3.23.tar.gz:perl-HTML-Tree

Fixed source url in rawhide.

> spot:BADURL:HTTP-Body-0.9.tar.gz:perl-HTTP-Body

New version, new CPAN maintainer, rawhide gets an update.

> spot:BADURL:Ima-DBI-0.35.tar.gz:perl-Ima-DBI

Fixed source url in rawhide.

> spot:BADURL:IO-CaptureOutput-1.06.tar.gz:perl-IO-CaptureOutput

Updated in rawhide (new CPAN maintainer, new release)

> spot:BADURL:kscope-1.6.2.tar.gz:kscope

Dunno why this one flagged, it all looks good to me.

> spot:BADURL:libgdamm-3.0.1.tar.bz2:libgdamm

Fixed source url in rawhide.

> spot:BADURL:libmcrypt-2.5.8.tar.gz:libmcrypt

Not sure why this failed, it all looks good on my end.

> spot:BADURL:MARC-Record-2.0.0.tar.gz:perl-MARC-Record

Fixed source url in rawhide.

> spot:BADURL:MIME-Types-1.23.tar.gz:perl-MIME-Types

Updated to 1.24 in rawhide.

> spot:BADURL:pydot-1.0.2.tar.gz:pydot

Googlecode, looks fine on my end.

> spot:BADURL:QuantLib-0.9.0.tar.gz:QuantLib

Updated to 0.9.7 in rawhide.

> spot:BADURL:rx-1.5.tar.bz2:librx

The FSF was hosting this but they pulled it down for some reason. Guess
upstream is dead.

> spot:BADURL:Scalar-Properties-0.13.tar.gz:perl-Scalar-Properties

Fixed source url in rawhide.

> spot:BADURL:ser2net-2.5.tar.gz:ser2net

Dunno why this one flagged, it all looks good to me.

> spot:BADURL:SimGear-1.0.0.tar.gz:SimGear

Their ftp server has ... issues. Took several tries to wget the file,
but everything is okay.

> spot:BADURL:Test-MockObject-1.08.tar.gz:perl-Test-MockObject

Updated to 1.09 in rawhide.

> spot:BADURL:Tree-DAG_Node-1.06.tar.gz:perl-Tree-DAG_Node

Fixed source url in rawhide.

> spot:BADURL:UNIVERSAL-isa-0.06.tar.gz:perl-UNIVERSAL-isa

Updated to 1.01, fixed source url, in rawhide.

> spot:BADURL:winpdb-1.4.0.tar.gz:winpdb

Updated to 1.4.2, source moved to google code.

Thanks,

~spot



From ivazqueznet at gmail.com  Fri Nov 21 00:07:17 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Thu, 20 Nov 2008 19:07:17 -0500
Subject: when plan add python2.6 or python3.0
In-Reply-To: <1227223873.3732.1.camel@localhost.localdomain>
References: <1227223873.3732.1.camel@localhost.localdomain>
Message-ID: <1227226037.736.157.camel@ignacio.lan>

On Fri, 2008-11-21 at 07:31 +0800, ??? wrote:
> when plan add python2.6 or python3.0
> in fedora 11 or fedora 12?

2.6 will probably be in Fedora 11. We're not sure when 3.0 will get in.

-- 
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/20081120/3068a10a/attachment.sig>

From aa.lucelio at hotmail.com  Fri Nov 21 00:35:33 2008
From: aa.lucelio at hotmail.com (=?iso-8859-1?Q?Luc=E9lio_Freitas?=)
Date: Fri, 21 Nov 2008 00:35:33 +0000
Subject: Thank you and congratulations
In-Reply-To: <20081120230950.GK10192@localhost.localdomain>
References: <20081120230950.GK10192@localhost.localdomain>
Message-ID: <COL101-W838D85E3BA3E8A401433DA940F0@phx.gbl>


Many thanks and congratulations to the entire Fedora community!
Yes it's true!   The dream is becaming reality.   All of you involved, are responsable for this.
I know that I can count on all of you.   Keep on.

Lucelio

> Date: Thu, 20 Nov 2008 18:09:50 -0500
> From: stickster at gmail.com
> To: fedora-devel-announce at redhat.com
> CC: 
> Subject: Thank you and congratulations
> 
> Now that the bits are on their way to the tubes, I want to say a word
> or three of thanks to our contributors for an exceptional release, and
> all of the thought, discussion, and action that went into it.  Ten
> releases in five years is a huge achievement, and we all have great
> reasons to be proud of it.  Let's look forward to next Tuesday's
> release of Fedora 10 with a sense of both pride and promise, and an
> understanding that there is more and better to come.
> 
> I have more to say about this, but I'll save it for the planet so as
> not to clog up this channel.  Congratulations to the entire Fedora
> community!
> 
> -- 
> 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

_________________________________________________________________
Receba GR?TIS as mensagens do Messenger no seu celular quando voc? estiver offline. Conhe?a  o MSN Mobile!
http://mobile.live.com/signup/signup2.aspx?lc=pt-br
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081121/e3d877c2/attachment.htm>

From andrew.cagney at gmail.com  Fri Nov 21 01:20:06 2008
From: andrew.cagney at gmail.com (Andrew Cagney)
Date: Thu, 20 Nov 2008 20:20:06 -0500
Subject: What do we need from Bugzilla? (was: My roadmap for a better
	Fedora)
In-Reply-To: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
Message-ID: <c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>

I'd like a "push upstream" button, as in create a corresponding bug in
the master upstream bug database.  Bonus points if it then keeps them
somewhat in sync :-)

On Wed, Nov 19, 2008 at 5:47 PM, Arthur Pemberton <pemboa at gmail.com> wrote:
> This question is (for now) most a question of interest and curiosity.
> Maybe one day I may be bored and try to rewrite Bugzilla, who knows.



From peter at thecodergeek.com  Fri Nov 21 02:00:33 2008
From: peter at thecodergeek.com (Peter Gordon)
Date: Thu, 20 Nov 2008 18:00:33 -0800
Subject: source file audit - 2008-11-14
In-Reply-To: <20081119170909.29694973@ohm.scrye.com>
References: <20081119170909.29694973@ohm.scrye.com>
Message-ID: <1227232833.3202.19.camel@tuxhugs>

On Wed, 2008-11-19 at 17:09 -0700, Kevin Fenzi wrote:
> pgordon:BADSOURCE:curvylooks-0.3.gtp:gnome-theme-curvylooks

Oops; this is my own project and I pulled a no-no a while back when I
re-spun the tarball without changing the name (a minor fix to the
Katakana spelling of "theme"). This is now fixed in CVS (all branches).

> pgordon:BADURL:empathy-2.24.1.tar.bz2:empathy

Fixed in CVS (devel)

> pgordon:BADURL:labyrinth-0.4.0.tar.bz2:labyrinth

Fixed in CVS (devel)

> pgordon:BADURL:libtorrent-rasterbar-0.13.1.tar.gz:rb_libtorrent

This is now moved to SourceForge's file hosting, but it only has the
0.14 tarball available. Upstream no longer has a 0.13.1 tarball
available. I'm working through pushing a version bump for Rawhide (and
potentially, release branches); but for the time being I've mirrored the
older file on my personal webspace and changed the Source URLs in CVS
(devel, F-10 branches) to point there instead of at upstream's
now-defunct download location. I hope that will suffice, at least
temporarily. 

Thanks and regards for the wonderful script! :)
-- 
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/20081120/1702de03/attachment.sig>

From seandarcy2 at gmail.com  Fri Nov 21 02:07:12 2008
From: seandarcy2 at gmail.com (sean darcy)
Date: Thu, 20 Nov 2008 21:07:12 -0500
Subject: where's the wish list for F11?
In-Reply-To: <alpine.LFD.2.00.0811201455510.16994@localhost.localdomain>
References: <gg4dm5$ts1$1@ger.gmane.org>
	<alpine.LFD.2.00.0811201455510.16994@localhost.localdomain>
Message-ID: <gg554h$6mi$1@ger.gmane.org>

Seth Vidal wrote:
> 
> 
> On Thu, 20 Nov 2008, sean darcy wrote:
> 
>> Being a user from os/x I'm surprised there's no simple method for 
>> installing system wide Type1 fonts ( same for TT ? ). FWIW, I've been 
>> unable to find instructions on how to do it from command line. The 
>> Fedora Users list just suggested I install using yum (sigh).
> 
> What's wrong with using yum?
> 
> yum search type1
> yum install any_of_the_things_returned_by_that_search
> 
> 
> and there a bunch returned by that search
> 
>> In any event, IMHO, it's a major oversight that we can't install 3rd 
>> party fonts, which would nice to see fixed in F11. So where do I make 
>> my plea?
> 
> Oh, I see you want  3rd party fonts. Then make a package and install 
> them the same way.
> 
> -sv
> 

First, I'm a great yum fan. And you are the man. No irony or sarcasm.

But... I use a lot of 3rd party fonts that aren't open, like most 
designers. It's weird/strange/peculiar there's no system-config-fonts 
that would allow us to install them.

So no disrespect to yum ( or you).

sean



From cmadams at hiwaay.net  Fri Nov 21 04:16:32 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 20 Nov 2008 22:16:32 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <20081120180007.GO24297@angus.ind.WPI.EDU>
References: <1226592802.3651.30.camel@eagle.danny.cz>
	<1226593460.13077.91.camel@aglarond.local>
	<20081113210903.GG1538120@hiwaay.net>
	<20081113214731.GA4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>
	<20081113223242.GB4498@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>
	<1226678932.636.40.camel@aglarond.local>
	<20081114200842.GD1142545@hiwaay.net>
	<20081120180007.GO24297@angus.ind.WPI.EDU>
Message-ID: <20081121041632.GD941487@hiwaay.net>

Once upon a time, Chuck Anderson <cra at WPI.EDU> said:
> On Fri, Nov 14, 2008 at 02:08:42PM -0600, Chris Adams wrote:
> > I do care about the desktop, and I use NM on my notebook (not on my
> > workstations that have a single interface with a single static IP).  I
> > have to shut it down on my notebook sometimes because it doesn't handle
> > some of my normal usage (multiple wired NICs, wired and wireless to
> > different networks, etc.).
> 
> Why do you have to shutdown NM sometimes?  I use NM with multiple 
> wired NICs, and wired + wireless to different networks without 
> problem.

Sometimes I'm using the wireless for "real" network access (default
route) and the wired to access a router for configuration or something.
NM takes a default route from wired before wireless (unless this has
changed recently and I missed something), so the only way to do this is
to shut down NM (and configure things manually).

I periodically use two or three wired interfaces, and again, I might see
a default route on more than one, but I need to control which one is
really default.  Also, sometimes I bridge between two wired interfaces
for traffic monitoring (since the cheapest gigabit switch with port
mirroring is ~$100).

My notebook (Thinkpad Z60m) has built-in gigabit and ABG wireless.  I
then have an ExpressCard gigabit and USB 100 megabit NICs for debugging,
routing, etc. when connecting to multiple networks.

-- 
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 rajeeshknambiar at gmail.com  Fri Nov 21 05:01:21 2008
From: rajeeshknambiar at gmail.com (Rajeesh K Nambiar)
Date: Fri, 21 Nov 2008 10:31:21 +0530
Subject: source file audit - 2008-11-14
In-Reply-To: <20081119170909.29694973@ohm.scrye.com>
References: <20081119170909.29694973@ohm.scrye.com>
Message-ID: <815462c80811202101y1044b562sca94c58a507e0366@mail.gmail.com>

Hi,

2008/11/20 Kevin Fenzi <kevin at scrye.com>:
> Here's attached another run of my sources/patches url checker.
> rajeeshknambiar:BADSOURCE:ooo-hunspell-ml-0.1.tar.bz2:hunspell-ml

Fixed, by retrieving the latest upstream tar ball.

-- 
Cheers,
Rajeesh



From yersinia.spiros at gmail.com  Fri Nov 21 08:31:36 2008
From: yersinia.spiros at gmail.com (yersinia)
Date: Fri, 21 Nov 2008 09:31:36 +0100
Subject: What do we need from Bugzilla? (was: My roadmap for a better
	Fedora)
In-Reply-To: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
Message-ID: <b086760e0811210031k788d49b4td55f96f9026e82e1@mail.gmail.com>

Well, also otrs (http://otrs.org/) is a very good bug tracking system, it is
distribuited with GPL licence, have ITIL complaince (
http://www.otrs.com/en/tools/faq/  ) . It is also possible to integrate with
Nagios or openNMS. Can be useful to follow also this link
http://www.novell.com/partnerguide/product/201509.html (just for another ref
- not for  other thing :=)  ). The "Remedy" to OTRS migration could be of
interest to someone.

Regards

On Wed, Nov 19, 2008 at 11:47 PM, Arthur Pemberton <pemboa at gmail.com> wrote:

> This question is (for now) most a question of interest and curiosity.
> Maybe one day I may be bored and try to rewrite Bugzilla, who knows.
>
> My question is, what do we need/want/like from Bugzilla? There are
> several competing products, and I doubt we engineer type people use it
> "just because". I'm also assuming that we use it for reasons other
> than because of RedHat.
>
> Can the unique features be enumerated for me?
>
> --
> Fedora 9 : sulphur is good for the skin
> ( www.pembo13.com )
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081121/f60c09ba/attachment.htm>

From mcepl at redhat.com  Fri Nov 21 09:22:39 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 21 Nov 2008 10:22:39 +0100
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>
Message-ID: <v7biv5xg17.ln2@ppp1053.in.ipex.cz>

On 2008-11-21, 01:20 GMT, Andrew Cagney wrote:
> I'd like a "push upstream" button, as in create a corresponding bug in
> the master upstream bug database.  Bonus points if it then keeps them
> somewhat in sync :-)

AMEN!!! And I think we should concentrate on this rather than 
doing stupid bugzilla rewrites. Sorry, for being harsh, but it is 
so IMNSHO.

Mat?j



From opensource at till.name  Fri Nov 21 09:28:57 2008
From: opensource at till.name (Till Maas)
Date: Fri, 21 Nov 2008 10:28:57 +0100
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
In-Reply-To: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
Message-ID: <200811211029.18051.opensource@till.name>

On Wed November 19 2008, Arthur Pemberton wrote:
> This question is (for now) most a question of interest and curiosity.
> Maybe one day I may be bored and try to rewrite Bugzilla, who knows.

If you want to write a Bugtracker for Fedora, it would be nice to support the 
special needs of Fedora. What I am missing is the possibility of having 
several people beeing responsible for a Component, which is currently only 
partly possible. There is the initial CC list, but when a bug is reassigned 
to a different component, the members of the initial CC list of the old 
component are not removed from the list.

Also it is not easily possible store within one bug report which Fedora 
release and which package versions are affected. The NEVR of the package is 
only added by some reporters in the initial comment, but not within some 
dedicated field. Also having several bug reports for the same bug but on 
different Fedora releases would mean to create up to four bug reports, with 
independend CC lists and independant comment flows, but most of the comments 
would be normally relevant to all Fedora releases.

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/20081121/d2ed0ab6/attachment.sig>

From hughsient at gmail.com  Fri Nov 21 09:31:45 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 21 Nov 2008 09:31:45 +0000
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <16de708d0811201016y6f351c0u1ffd8d9b61a36291@mail.gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227203271.4355.219.camel@code.and.org>
	<16de708d0811201016y6f351c0u1ffd8d9b61a36291@mail.gmail.com>
Message-ID: <1227259905.3359.0.camel@hughsie-laptop>

On Thu, 2008-11-20 at 12:16 -0600, Arthur Pemberton wrote:
> Also, uses GTK doesn't necessarily mean Gnome. However, if a package
> is going to pull in Gnome libs, would be nice to know that in the
> summary.

No, the summary isn't the best place to put dependency information.

Richard.




From dominik at greysector.net  Fri Nov 21 09:40:44 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Fri, 21 Nov 2008 10:40:44 +0100
Subject: where's the wish list for F11?
In-Reply-To: <gg554h$6mi$1@ger.gmane.org>
References: <gg4dm5$ts1$1@ger.gmane.org>
	<alpine.LFD.2.00.0811201455510.16994@localhost.localdomain>
	<gg554h$6mi$1@ger.gmane.org>
Message-ID: <20081121094044.GA24555@mokona.greysector.net>

On Friday, 21 November 2008 at 03:07, sean darcy wrote:
[...]
> First, I'm a great yum fan. And you are the man. No irony or sarcasm.
> 
> But... I use a lot of 3rd party fonts that aren't open, like most 
> designers. It's weird/strange/peculiar there's no system-config-fonts 
> that would allow us to install them.

This calls for some font2spec script that'd create a spec file for your
font and let you build a package from it easily, much like R2spec or
cpan2rpm.

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 emmanuel.seyman at club-internet.fr  Fri Nov 21 09:50:53 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Fri, 21 Nov 2008 10:50:53 +0100
Subject: What do we need from Bugzilla? (was: My roadmap for a better
	Fedora)
In-Reply-To: <c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>
Message-ID: <20081121095053.GA15636@orient.maison.lan>

* Andrew Cagney [21/11/2008 09:56] :
>
> I'd like a "push upstream" button, as in create a corresponding bug in
> the master upstream bug database.  Bonus points if it then keeps them
> somewhat in sync :-)

Things to keep in mind :

- Users have to be pushed upstream as well. The reporter of the bug in
  bugzilla.redhat.com must stay the reporter in the upstreamed bug
  report.

- You need to check for dupes and not blindly open a bug in the upstream
  bug tracker.

- Even if most upstreams use bugzilla, their notions of products and
  components is different from Red Hat/Fedora's. You'll need to work out
  a mapping from one to the other.

Emmanuel



From dominik at greysector.net  Fri Nov 21 10:09:18 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Fri, 21 Nov 2008 11:09:18 +0100
Subject: What do we need from Bugzilla? (was: My roadmap for a better
	Fedora)
In-Reply-To: <20081121095053.GA15636@orient.maison.lan>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>
	<20081121095053.GA15636@orient.maison.lan>
Message-ID: <20081121100917.GB24555@mokona.greysector.net>

On Friday, 21 November 2008 at 10:50, Emmanuel Seyman wrote:
> * Andrew Cagney [21/11/2008 09:56] :
> >
> > I'd like a "push upstream" button, as in create a corresponding bug in
> > the master upstream bug database.  Bonus points if it then keeps them
> > somewhat in sync :-)
> 
> Things to keep in mind :
> 
> - Users have to be pushed upstream as well. The reporter of the bug in
>   bugzilla.redhat.com must stay the reporter in the upstreamed bug
>   report.
> 
> - You need to check for dupes and not blindly open a bug in the upstream
>   bug tracker.
> 
> - Even if most upstreams use bugzilla, their notions of products and
>   components is different from Red Hat/Fedora's. You'll need to work out
>   a mapping from one to the other.

I'm beginning to see why Canonical thinks their Launchpad has to have only
one global instance.

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 hughsient at gmail.com  Fri Nov 21 10:17:00 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 21 Nov 2008 10:17:00 +0000
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <gg4i7l$ek6$1@ger.gmane.org>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<gg4i7l$ek6$1@ger.gmane.org>
Message-ID: <1227262620.3359.41.camel@hughsie-laptop>

On Thu, 2008-11-20 at 21:44 +0100, Kevin Kofler wrote:
> s/PackageKit/gnome-packagekit/
> FYI, KPackageKit does the exact opposite (at least the version now in
> F9 updates-testing).
> This is a UI design decision, not a decision at the PackageKit level.
> Different PackageKit frontends show things differently.

Didn't know this - thanks. I still stand by my other points tho.

Richard.




From nicolas.mailhot at laposte.net  Fri Nov 21 10:34:13 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 21 Nov 2008 11:34:13 +0100
Subject: where's the wish list for F11?
In-Reply-To: <20081121094044.GA24555@mokona.greysector.net>
References: <gg4dm5$ts1$1@ger.gmane.org>
	<alpine.LFD.2.00.0811201455510.16994@localhost.localdomain>
	<gg554h$6mi$1@ger.gmane.org>
	<20081121094044.GA24555@mokona.greysector.net>
Message-ID: <1227263653.9545.18.camel@arekh.okg>

Le vendredi 21 novembre 2008 ? 10:40 +0100, Dominik 'Rathann'
Mierzejewski a ?crit :
> On Friday, 21 November 2008 at 03:07, sean darcy wrote:
> [...]
> > First, I'm a great yum fan. And you are the man. No irony or sarcasm.
> > 
> > But... I use a lot of 3rd party fonts that aren't open, like most 
> > designers. It's weird/strange/peculiar there's no system-config-fonts 
> > that would allow us to install them.
> 
> This calls for some font2spec script that'd create a spec file for your
> font and let you build a package from it easily, much like R2spec or
> cpan2rpm.

R2spec or cpan2rpm work by converting existing metadata. Raw font files
do not have the kind of metadata which could be used to generate
complete spec files. You have significant packager involvment to fill
the info that wouldn't be there otherwise.

But anyway you're invited like everyone else on the list to review,
comment on and complete the current font packaging guideline change
proposal on
http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation

-- 
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/20081121/f5896ef3/attachment.sig>

From tagoh at redhat.com  Fri Nov 21 10:38:54 2008
From: tagoh at redhat.com (Akira TAGOH)
Date: Fri, 21 Nov 2008 19:38:54 +0900 (JST)
Subject: source file audit - 2008-11-14
In-Reply-To: <20081119170909.29694973@ohm.scrye.com>
References: <20081119170909.29694973@ohm.scrye.com>
Message-ID: <20081121.193854.860470336651371543.tagoh@redhat.com>

>>>>> On Wed, 19 Nov 2008 17:09:09 -0700,
>>>>> "KF" == Kevin Fenzi <kevin at scrye.com> wrote:

KF> tagoh:BADSOURCE:anthy-9100e.tar.gz:anthy
KF> tagoh:BADSOURCE:Canna37p3.tar.bz2:Canna
KF> tagoh:BADSOURCE:mplus_bitmap_fonts-2.2.4.tar.gz:japanese-bitmap-fonts
KF> tagoh:BADSOURCE:nkf-2.0.8b.tar.gz:nkf
KF> tagoh:BADSOURCE:scim-anthy-1.2.6.tar.gz:scim-anthy
KF> tagoh:BADURL:k14-oldkanji.tar.gz:japanese-bitmap-fonts
KF> tagoh:BADURL:mew-6.1.50.tar.gz:mew

Fixed in devel.

KF> tagoh:BADURL:imsettings-0.105.1.tar.bz2:imsettings
KF> tagoh:BADURL:libgcroots-0.2.1.tar.bz2:libgcroots
KF> tagoh:BADURL:libgxim-0.3.1.tar.bz2:libgxim
KF> tagoh:BADURL:sigscheme-0.8.3.tar.bz2:sigscheme
KF> tagoh:BADURL:uim-1.5.3.tar.bz2:uim

google code issue.

--
Akira TAGOH
-------------- 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/20081121/4bd35d15/attachment.sig>

From mcepl at redhat.com  Fri Nov 21 10:44:17 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 21 Nov 2008 11:44:17 +0100
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>
	<20081121095053.GA15636@orient.maison.lan>
Message-ID: <11giv5xecm.ln2@ppp1053.in.ipex.cz>

On 2008-11-21, 09:50 GMT, Emmanuel Seyman wrote:
>> I'd like a "push upstream" button, as in create 
>> a corresponding bug in
>> the master upstream bug database.  Bonus points if it then keeps them
>> somewhat in sync :-)

I have written about this a little bit before
http://article.gmane.org/gmane.linux.redhat.fedora.devel/79936

> - Users have to be pushed upstream as well. The reporter of the
>   bug in bugzilla.redhat.com must stay the reporter in the 
>   upstreamed bug report.

No, they shouldn't and they shouldn't need to. We cannot force 
our reporters to crete accounts in the upstream bugzillas. We 
should deliver comments from the upstream bugzilla to our one 
(via XML-RPC I guess).

> - You need to check for dupes and not blindly open a bug in the upstream
>   bug tracker.

This is difficult -- yes, probably we could open the query from 
the upstream bugzilla in other tab. However, I have to admit that 
after brief query in the upstream database (e.g., in mozilla with 
the query tool in the new bug page) I just dump the bug there and 
let upstream triagers show that they know much better what's in 
their bugzilla.

> - Even if most upstreams use bugzilla, their notions of products and
>   components is different from Red Hat/Fedora's. You'll need to work out
>   a mapping from one to the other.

Of course.

Mat?j



From mcepl at redhat.com  Fri Nov 21 10:47:08 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 21 Nov 2008 11:47:08 +0100
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>
	<20081121095053.GA15636@orient.maison.lan>
	<20081121100917.GB24555@mokona.greysector.net>
Message-ID: <c6giv5xecm.ln2@ppp1053.in.ipex.cz>

On 2008-11-21, 10:09 GMT, Dominik 'Rathann' Mierzejewski wrote:
> I'm beginning to see why Canonical thinks their Launchpad has 
> to have only one global instance.

I think it IS doable -- just some programmer has to sit on his 
butt and do it. And communicate a lot with the bugzilla upstream.

Mat?j



From emmanuel.seyman at club-internet.fr  Fri Nov 21 11:15:16 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Fri, 21 Nov 2008 12:15:16 +0100
Subject: What do we need from Bugzilla? (was: My roadmap for a better
	Fedora)
In-Reply-To: <20081121100917.GB24555@mokona.greysector.net>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>
	<20081121095053.GA15636@orient.maison.lan>
	<20081121100917.GB24555@mokona.greysector.net>
Message-ID: <20081121111516.GA15877@orient.maison.lan>

* Dominik 'Rathann' Mierzejewski [21/11/2008 11:27] :
>
> I'm beginning to see why Canonical thinks their Launchpad has to have only
> one global instance.

[ Disclaimer : I'm a contributor to upstream Bugzilla ]

Moving bugs is hard and getting harder, IMHO.

It wasn't easy to do back in the early days and, since then, Bugzilla
has gained the abilty to customize statuses and resolutions, making it
even harder to push bugs from one bugzilla to another with prompting for
user interaction.

At this point, we're basically reduced to pushing a summary and
description (which may depend on information from other fields to be
pertinent and asking the user to fill in the rest). Which doesn't strike
me as a huge improvement over asking the reporter to open an account in
the upstream Bugzilla and copy/paste the summary and description himself
in the bug entry form.

That said, the "one bug tracker to rule them all" approach has a huge
number of problems as well.

Emmanuel



From emmanuel.seyman at club-internet.fr  Fri Nov 21 11:25:43 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Fri, 21 Nov 2008 12:25:43 +0100
Subject: What do we need from Bugzilla? (was: My roadmap for a better
	Fedora)
In-Reply-To: <11giv5xecm.ln2@ppp1053.in.ipex.cz>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>
	<20081121095053.GA15636@orient.maison.lan>
	<11giv5xecm.ln2@ppp1053.in.ipex.cz>
Message-ID: <20081121112543.GB15943@orient.maison.lan>

* Matej Cepl [21/11/2008 12:15] :
>
> No, they shouldn't and they shouldn't need to. We cannot force 
> our reporters to crete accounts in the upstream bugzillas. We 
> should deliver comments from the upstream bugzilla to our one 
> (via XML-RPC I guess).

This has the inconvenience that :

a) Two (or more) conversations are taking place in the bug report.
b) Comments like "the fix proposed in comment #7 looks good" lose
   all meaning, unless you know what comments come from which bug
   tracker.

I suppose we can live with it, though.

> the upstream bugzilla in other tab. However, I have to admit that 
> after brief query in the upstream database (e.g., in mozilla with 
> the query tool in the new bug page) I just dump the bug there and 
> let upstream triagers show that they know much better what's in 
> their bugzilla.

Thanks for making their work more difficult, I guess.

Emmanuel



From dominik at greysector.net  Fri Nov 21 11:28:30 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Fri, 21 Nov 2008 12:28:30 +0100
Subject: where's the wish list for F11?
In-Reply-To: <1227263653.9545.18.camel@arekh.okg>
References: <gg4dm5$ts1$1@ger.gmane.org>
	<alpine.LFD.2.00.0811201455510.16994@localhost.localdomain>
	<gg554h$6mi$1@ger.gmane.org>
	<20081121094044.GA24555@mokona.greysector.net>
	<1227263653.9545.18.camel@arekh.okg>
Message-ID: <20081121112829.GC24555@mokona.greysector.net>

On Friday, 21 November 2008 at 11:34, Nicolas Mailhot wrote:
> Le vendredi 21 novembre 2008 ? 10:40 +0100, Dominik 'Rathann'
> Mierzejewski a ?crit :
> > On Friday, 21 November 2008 at 03:07, sean darcy wrote:
> > [...]
> > > First, I'm a great yum fan. And you are the man. No irony or sarcasm.
> > > 
> > > But... I use a lot of 3rd party fonts that aren't open, like most 
> > > designers. It's weird/strange/peculiar there's no system-config-fonts 
> > > that would allow us to install them.
> > 
> > This calls for some font2spec script that'd create a spec file for your
> > font and let you build a package from it easily, much like R2spec or
> > cpan2rpm.
> 
> R2spec or cpan2rpm work by converting existing metadata. Raw font files
> do not have the kind of metadata which could be used to generate
> complete spec files. You have significant packager involvment to fill
> the info that wouldn't be there otherwise.
> 
> But anyway you're invited like everyone else on the list to review,
> comment on and complete the current font packaging guideline change
> proposal on
> http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation

It looks mostly sane (I applied some grammar and punctuation fixes, I hope
you don't mind), but I don't like the naming of "rpm-fonts-filesystem". This
has nothing to do with rpm itself, hence it shouldn't look like a subpackage
of rpm. Instead, I suggest "fonts-filesystem".

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 dtimms at iinet.net.au  Fri Nov 21 12:12:05 2008
From: dtimms at iinet.net.au (David Timms)
Date: Fri, 21 Nov 2008 23:12:05 +1100
Subject: source file audit - 2008-11-14
In-Reply-To: <1227225673.26058.187.camel@localhost.localdomain>
References: <20081119170909.29694973@ohm.scrye.com>
	<1227225673.26058.187.camel@localhost.localdomain>
Message-ID: <4926A595.1090503@iinet.net.au>

Tom "spot" Callaway wrote:
> On Wed, 2008-11-19 at 17:09 -0700, Kevin Fenzi wrote:
> Upstream doesn't embed version in their zip file, they just do new
> releases with the same filename, which causes this. I emailed them to
> ask them not to do that, but they replied that they like it like that.
I wonder if they would be open to providing the current release as they 
like to do alongside a versioned filename copy of the file, that 
preferably stays on their site for at least some time.

DaveT.



From nicolas.mailhot at laposte.net  Fri Nov 21 12:24:45 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 21 Nov 2008 13:24:45 +0100
Subject: where's the wish list for F11?
In-Reply-To: <20081121112829.GC24555@mokona.greysector.net>
References: <gg4dm5$ts1$1@ger.gmane.org>
	<alpine.LFD.2.00.0811201455510.16994@localhost.localdomain>
	<gg554h$6mi$1@ger.gmane.org>
	<20081121094044.GA24555@mokona.greysector.net>
	<1227263653.9545.18.camel@arekh.okg>
	<20081121112829.GC24555@mokona.greysector.net>
Message-ID: <1227270285.9545.27.camel@arekh.okg>

Le vendredi 21 novembre 2008 ? 12:28 +0100, Dominik 'Rathann'
Mierzejewski a ?crit :
> On Friday, 21 November 2008 at 11:34, Nicolas Mailhot wrote:

> > But anyway you're invited like everyone else on the list to review,
> > comment on and complete the current font packaging guideline change
> > proposal on
> > http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation
> 
> It looks mostly sane (I applied some grammar and punctuation fixes, I hope
> you don't mind), 

Thank you for the review and the fixes, I don't mind at all, quite the
contrary, you're very welcome. Please post any remarks you may have
about the packages themselves, that's where the long-term value is.

> but I don't like the naming of "rpm-fonts-filesystem". This
> has nothing to do with rpm itself, hence it shouldn't look like a subpackage
> of rpm. Instead, I suggest "fonts-filesystem".

I fear that by the time I had written the macros, templates, specs, wiki
pages, and all, my inspiration had quite dried out. I don't like
rpm-fonts much, but I feel fonts would be too generic a name for the
base package. If anyone has great naming ideas, I'm all ears.

-- 
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/20081121/1540e7ce/attachment.sig>

From pbrobinson at gmail.com  Fri Nov 21 13:27:40 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Fri, 21 Nov 2008 13:27:40 +0000
Subject: problems updating glibc
Message-ID: <5256d0b0811210527k2fcf1c46k2997c358cb1a3e07@mail.gmail.com>

Hi All,

I've seen mention of this (and actually saw it on another system of
mine but it settled down) where glibc-common can't update due to
glibc.

The machine is a Fit-PC which runs on an AMD Geode. It currently has
the glibc version 2.8.90-14 i686 rpm and attempting to update to 2.9-2
it errors with "package glibc-2.9-2.i686 is intended for a i686
architecture" which seems weird given that its already running the
i686 version. Any ideas?

Peter

[root at cypher ~]# rpm -Uvh glibc-*
Preparing...                ########################################### [100%]
	package glibc-2.9-2.i686 is intended for a i686 architecture
[root at cypher ~]# cat /proc/cpuinfo
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 5
model		: 10
model name	: Geode(TM) Integrated Processor by AMD PCS
stepping	: 2
cpu MHz		: 499.900
cache size	: 128 KB
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu de pse tsc msr cx8 pge cmov clflush mmx mmxext 3dnowext 3dnow up
bogomips	: 999.80
clflush size	: 32
power management:

[root at cypher ~]# rpm -qa| grep glibc
glibc-2.8.90-14.i686
glibc-common-2.8.90-14.i386



From rawhide at fedoraproject.org  Fri Nov 21 13:54:51 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri, 21 Nov 2008 13:54:51 +0000 (UTC)
Subject: rawhide report: 20081121 changes
Message-ID: <20081121135451.5B2F91F8257@releng2.fedora.phx.redhat.com>

Compose started at Fri Nov 21 06:01:10 UTC 2008

Updated Packages:

anaconda-11.4.1.62-1
--------------------
* Wed Nov 19 17:00:00 2008 Jeremy Katz <katzj at redhat.com> - 11.4.1.62-1
- Do not show disabled repos such as rawhide during the install. (jkeating)


Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 1














From lesmikesell at gmail.com  Fri Nov 21 14:05:24 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 21 Nov 2008 08:05:24 -0600
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
In-Reply-To: <20081121112543.GB15943@orient.maison.lan>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>	<c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>	<20081121095053.GA15636@orient.maison.lan>	<11giv5xecm.ln2@ppp1053.in.ipex.cz>
	<20081121112543.GB15943@orient.maison.lan>
Message-ID: <4926C024.7050303@gmail.com>

Emmanuel Seyman wrote:
> * Matej Cepl [21/11/2008 12:15] :
>> No, they shouldn't and they shouldn't need to. We cannot force 
>> our reporters to crete accounts in the upstream bugzillas. We 
>> should deliver comments from the upstream bugzilla to our one 
>> (via XML-RPC I guess).
> 
> This has the inconvenience that :
> 
> a) Two (or more) conversations are taking place in the bug report.
> b) Comments like "the fix proposed in comment #7 looks good" lose
>    all meaning, unless you know what comments come from which bug
>    tracker.
> 
> I suppose we can live with it, though.
> 
>> the upstream bugzilla in other tab. However, I have to admit that 
>> after brief query in the upstream database (e.g., in mozilla with 
>> the query tool in the new bug page) I just dump the bug there and 
>> let upstream triagers show that they know much better what's in 
>> their bugzilla.
> 
> Thanks for making their work more difficult, I guess.

If someone does this right, maybe it would be possible to cascade all 
the way up from user/site/enterprise instances and a working version 
included in the distribution would have templates for all the packages 
and a checkbox for whether or not to push a specific entry upstream or 
not.  That way everyone could track their own problems, their local or 
company helpdesk could be added as the next escalation, and on to the 
distribution if it wasn't a local problem without having to deal with 
different interfaces or creating new logins.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From dennis at ausil.us  Fri Nov 21 14:13:28 2008
From: dennis at ausil.us (Dennis Gilmore)
Date: Fri, 21 Nov 2008 08:13:28 -0600
Subject: problems updating glibc
In-Reply-To: <5256d0b0811210527k2fcf1c46k2997c358cb1a3e07@mail.gmail.com>
References: <5256d0b0811210527k2fcf1c46k2997c358cb1a3e07@mail.gmail.com>
Message-ID: <200811210817.43276.dennis@ausil.us>

On Friday 21 November 2008 07:27:40 am Peter Robinson wrote:
> Hi All,
>
> I've seen mention of this (and actually saw it on another system of
> mine but it settled down) where glibc-common can't update due to
> glibc.
>
> The machine is a Fit-PC which runs on an AMD Geode. It currently has
> the glibc version 2.8.90-14 i686 rpm and attempting to update to 2.9-2
> it errors with "package glibc-2.9-2.i686 is intended for a i686
> architecture" which seems weird given that its already running the
> i686 version. Any ideas?
a geode is not i686 compatiable,  it is a i586 cpu + cmov it really needs its 
own arch for glibc.  rpm and yum both now how to deal with .geode packages.  
openssl likely needs a .geode rpm also.  olpc has the same issue.  the images 
they use have i686 versions installed.  


Dennis



From lesmikesell at gmail.com  Fri Nov 21 14:20:14 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 21 Nov 2008 08:20:14 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <49256EC6.9070000@gmail.com>
References: <20081113132742.GB2803@traged.atkac.englab.brq.redhat.com>	<20081113214731.GA4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811131722270.19678@localhost.localdomain>	<20081113223242.GB4498@nostromo.devel.redhat.com>	<alpine.LFD.2.00.0811140119350.19678@localhost.localdomain>	<1226678932.636.40.camel@aglarond.local>	<46a038f90811141013hde79db2s6925931de06b75d2@mail.gmail.com>	<1226686948.13086.44.camel@aglarond.local>	<46a038f90811141217i2018253cn4add2fc677162222@mail.gmail.com>	<1226700116.13086.116.camel@aglarond.local>	<491FBA0E.2070003@gmail.com>	<1227043592.4687.9.camel@firewall.xsintricity.com>	<49234139.1050400@gmail.com>	<1227057520.4687.45.camel@firewall.xsintricity.com>	<4923836B.109030	9@gmail.com>	<1227110198.4687.108.camel@firewall.xsintricity.com>	<492467D6.7050803@gmail.com>	<1227126323.4687.178.camel@firewall.xsintricity.com>	<49250B08.4080206@gmail.com>	<ddlfv5x4hr.ln2@ppp1053.in.ipex.cz>
	<49256EC6.9070000@gmail.com>
Message-ID: <4926C39E.4030507@gmail.com>

Les Mikesell wrote:
> Matej Cepl wrote:
>> On 2008-11-20, 07:00 GMT, Les Mikesell wrote:
>>> Maybe - but it isn't a real solution.  You still have to deal with 
>>> identifying the device before and during the labeling process.  If 
>>> you can do that, you didn't really need the label.
>>
>> Sorry, maybe I don't understand, but what's so difficult on the 
>> following?
>>
>> tune2fs -l /dev/sda1 |awk '/UUID/ {print $3}'
>>
> 
> The disk may be unformatted at this point and not have a UUID. 

I know it is bad form to follow up to my own posting, but I think I've 
been making my argument in the wrong way so far.  I'm not really against 
changes in the way things are done or even the details of those changes 
as long as they are exposed somehow.  What I am against is hiding those 
changes in anaconda or other parts of the installer process so that the 
only reasonable way to build several machines is to automate the way you 
interact with anaconda with another tool like cobbler, and after it is 
built you can't change anything.

We need a way to do the things that only anaconda knows how to do at 
times other than the initial install.  For example, you want to move a 
working system disk to another machine, or replace the booting disk 
controller, or restore your backups onto a similar system.  Or clone a 
bunch of copies of the same boot/system disk and expect them to run in 
different machines.  It doesn't really matter how this is accomplished, 
just that there is a plan for it and hopefully it doesn't involve a 
human needing to know every possible thing that anaconda knows about 
hardware.   Could there be a way to re-run anaconda after moving a 
system to new hardware and do an automatic fix-up?

-- 
   Les Mikesell
     lesmikesell at gmail.com



From pbrobinson at gmail.com  Fri Nov 21 14:22:57 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Fri, 21 Nov 2008 14:22:57 +0000
Subject: problems updating glibc
In-Reply-To: <200811210817.43276.dennis@ausil.us>
References: <5256d0b0811210527k2fcf1c46k2997c358cb1a3e07@mail.gmail.com>
	<200811210817.43276.dennis@ausil.us>
Message-ID: <5256d0b0811210622v3d6cb21dme6c824850bf5c23d@mail.gmail.com>

>> Hi All,
>>
>> I've seen mention of this (and actually saw it on another system of
>> mine but it settled down) where glibc-common can't update due to
>> glibc.
>>
>> The machine is a Fit-PC which runs on an AMD Geode. It currently has
>> the glibc version 2.8.90-14 i686 rpm and attempting to update to 2.9-2
>> it errors with "package glibc-2.9-2.i686 is intended for a i686
>> architecture" which seems weird given that its already running the
>> i686 version. Any ideas?
> a geode is not i686 compatiable,  it is a i586 cpu + cmov it really needs its
> own arch for glibc.  rpm and yum both now how to deal with .geode packages.
> openssl likely needs a .geode rpm also.  olpc has the same issue.  the images
> they use have i686 versions installed.

So OLPC uses i686 or some other package? This one was running i686
probably because I installed it from a LiveCD but has been running
fine, that's probably where the issue came from.

Peter



From tcallawa at redhat.com  Fri Nov 21 14:24:19 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 21 Nov 2008 09:24:19 -0500
Subject: source file audit - 2008-11-14
In-Reply-To: <4926A595.1090503@iinet.net.au>
References: <20081119170909.29694973@ohm.scrye.com>
	<1227225673.26058.187.camel@localhost.localdomain>
	<4926A595.1090503@iinet.net.au>
Message-ID: <1227277459.3625.2.camel@localhost.localdomain>

On Fri, 2008-11-21 at 23:12 +1100, David Timms wrote:
> I wonder if they would be open to providing the current release as
> they 
> like to do alongside a versioned filename copy of the file, that 
> preferably stays on their site for at least some time.

I asked, and they said no. I think upstream is 12 years old. :/

~spot



From emmanuel.seyman at club-internet.fr  Fri Nov 21 14:46:20 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Fri, 21 Nov 2008 15:46:20 +0100
Subject: What do we need from Bugzilla? (was: My roadmap for a better
	Fedora)
In-Reply-To: <4926C024.7050303@gmail.com>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>
	<20081121095053.GA15636@orient.maison.lan>
	<11giv5xecm.ln2@ppp1053.in.ipex.cz>
	<20081121112543.GB15943@orient.maison.lan>
	<4926C024.7050303@gmail.com>
Message-ID: <20081121144620.GA16263@orient.maison.lan>

* Les Mikesell [21/11/2008 15:16] :
>
> If someone does this right, maybe it would be possible to cascade all  
> the way up from user/site/enterprise instances and a working version  

It could be done. This is why so much work has been done on the XML-RPC
workings for Bugzilla 3.2.

> included in the distribution would have templates for all the packages  
> and a checkbox for whether or not to push a specific entry upstream or  
> not.

Deciding to push a bug upstream or not cannot be reduced to checking a
box or pushing a button. You need to search the upstream bug tracker
before submitting and link your bug to an already existing bug in
upstream if it already exists, fill in new fields and make sure that
the fields that are dropped don't make the bug incomprehensible.

Emmanuel



From seandarcy2 at gmail.com  Fri Nov 21 15:00:58 2008
From: seandarcy2 at gmail.com (sean darcy)
Date: Fri, 21 Nov 2008 10:00:58 -0500
Subject: where's the wish list for F11?
In-Reply-To: <1227270285.9545.27.camel@arekh.okg>
References: <gg4dm5$ts1$1@ger.gmane.org>	<alpine.LFD.2.00.0811201455510.16994@localhost.localdomain>	<gg554h$6mi$1@ger.gmane.org>	<20081121094044.GA24555@mokona.greysector.net>	<1227263653.9545.18.camel@arekh.okg>	<20081121112829.GC24555@mokona.greysector.net>
	<1227270285.9545.27.camel@arekh.okg>
Message-ID: <gg6ifb$490$1@ger.gmane.org>

Nicolas Mailhot wrote:
> Le vendredi 21 novembre 2008 ? 12:28 +0100, Dominik 'Rathann'
> Mierzejewski a ?crit :
>> On Friday, 21 November 2008 at 11:34, Nicolas Mailhot wrote:
> 
>>> But anyway you're invited like everyone else on the list to review,
>>> comment on and complete the current font packaging guideline change
>>> proposal on
>>> http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation
>> It looks mostly sane (I applied some grammar and punctuation fixes, I hope
>> you don't mind), 
> 
> Thank you for the review and the fixes, I don't mind at all, quite the
> contrary, you're very welcome. Please post any remarks you may have
> about the packages themselves, that's where the long-term value is.
> 
>> but I don't like the naming of "rpm-fonts-filesystem". This
>> has nothing to do with rpm itself, hence it shouldn't look like a subpackage
>> of rpm. Instead, I suggest "fonts-filesystem".
> 
> I fear that by the time I had written the macros, templates, specs, wiki
> pages, and all, my inspiration had quite dried out. I don't like
> rpm-fonts much, but I feel fonts would be too generic a name for the
> base package. If anyone has great naming ideas, I'm all ears.
> 

But can't this be done without making an rpm package ( which may or may 
not raise legal issues).

I'm looking for something much simpler: I go buy/get a font;  I open 
fonts-filesystem/system-config-fonts/whatever ; I point it to the font ( 
Type1, TT, etc); and the font is installed.

Making an rpm package of the font first seems to make this more involved 
than it needs to be.

sean



From skvidal at fedoraproject.org  Fri Nov 21 15:04:50 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 21 Nov 2008 10:04:50 -0500 (EST)
Subject: where's the wish list for F11?
In-Reply-To: <gg6ifb$490$1@ger.gmane.org>
References: <gg4dm5$ts1$1@ger.gmane.org>
	<alpine.LFD.2.00.0811201455510.16994@localhost.localdomain>
	<gg554h$6mi$1@ger.gmane.org>
	<20081121094044.GA24555@mokona.greysector.net>
	<1227263653.9545.18.camel@arekh.okg>
	<20081121112829.GC24555@mokona.greysector.net>
	<1227270285.9545.27.camel@arekh.okg> <gg6ifb$490$1@ger.gmane.org>
Message-ID: <alpine.LFD.2.00.0811211004050.26301@localhost.localdomain>



On Fri, 21 Nov 2008, sean darcy wrote:

>
> But can't this be done without making an rpm package ( which may or may not 
> raise legal issues).
>
> I'm looking for something much simpler: I go buy/get a font;  I open 
> fonts-filesystem/system-config-fonts/whatever ; I point it to the font ( 
> Type1, TT, etc); and the font is installed.
>
> Making an rpm package of the font first seems to make this more involved than 
> it needs to be.
>

If you're only trying to install it on one machine it is SOMEWHAT more 
complicated but it will save you the pain of recovering those files the 
next time you reinstall/upgrade/etc.

-sv



From rjones at redhat.com  Fri Nov 21 15:09:55 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 21 Nov 2008 15:09:55 +0000
Subject: problems updating glibc
In-Reply-To: <200811210817.43276.dennis@ausil.us>
References: <5256d0b0811210527k2fcf1c46k2997c358cb1a3e07@mail.gmail.com>
	<200811210817.43276.dennis@ausil.us>
Message-ID: <20081121150955.GA16736@amd.home.annexia.org>

On Fri, Nov 21, 2008 at 08:13:28AM -0600, Dennis Gilmore wrote:
> On Friday 21 November 2008 07:27:40 am Peter Robinson wrote:
> > Hi All,
> >
> > I've seen mention of this (and actually saw it on another system of
> > mine but it settled down) where glibc-common can't update due to
> > glibc.
> >
> > The machine is a Fit-PC which runs on an AMD Geode. It currently has
> > the glibc version 2.8.90-14 i686 rpm and attempting to update to 2.9-2
> > it errors with "package glibc-2.9-2.i686 is intended for a i686
> > architecture" which seems weird given that its already running the
> > i686 version. Any ideas?
> a geode is not i686 compatiable,  it is a i586 cpu + cmov it really needs its 
> own arch for glibc.  rpm and yum both now how to deal with .geode packages.  
> openssl likely needs a .geode rpm also.  olpc has the same issue.  the images 
> they use have i686 versions installed.  

I've got one of these crazy boxes too.  Although i686 packages can't
be installed, they _do_ seem to work if you force them.  Certainly all
the simple ones I tried anyway, although maybe I didn't try openssl.

(It's also worth noting that there are at least two somewhat different
variations of the Geode.)

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 cra at WPI.EDU  Fri Nov 21 15:20:33 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Fri, 21 Nov 2008 10:20:33 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <4926C39E.4030507@gmail.com>
References: <49234139.1050400@gmail.com>
	<1227057520.4687.45.camel@firewall.xsintricity.com>
	<4923836B.1090309@gmail.com>
	<1227110198.4687.108.camel@firewall.xsintricity.com>
	<492467D6.7050803@gmail.com>
	<1227126323.4687.178.camel@firewall.xsintricity.com>
	<49250B08.4080206@gmail.com> <ddlfv5x4hr.ln2@ppp1053.in.ipex.cz>
	<49256EC6.9070000@gmail.com> <4926C39E.4030507@gmail.com>
Message-ID: <20081121152033.GB20122@angus.ind.WPI.EDU>

On Fri, Nov 21, 2008 at 08:20:14AM -0600, Les Mikesell wrote:
> Les Mikesell wrote:
>> Matej Cepl wrote:
>>> On 2008-11-20, 07:00 GMT, Les Mikesell wrote:
>>>> Maybe - but it isn't a real solution.  You still have to deal with  
>>>> identifying the device before and during the labeling process.  If  
>>>> you can do that, you didn't really need the label.
>>>
>>> Sorry, maybe I don't understand, but what's so difficult on the  
>>> following?
>>>
>>> tune2fs -l /dev/sda1 |awk '/UUID/ {print $3}'
>>>
>>
>> The disk may be unformatted at this point and not have a UUID. 
>
> I know it is bad form to follow up to my own posting, but I think I've  
> been making my argument in the wrong way so far.  I'm not really against  
> changes in the way things are done or even the details of those changes  
> as long as they are exposed somehow.  What I am against is hiding those  
> changes in anaconda or other parts of the installer process so that the  
> only reasonable way to build several machines is to automate the way you  
> interact with anaconda with another tool like cobbler, and after it is  
> built you can't change anything.
>
> We need a way to do the things that only anaconda knows how to do at  
> times other than the initial install.  For example, you want to move a  
> working system disk to another machine, or replace the booting disk  
> controller, or restore your backups onto a similar system.  Or clone a  
> bunch of copies of the same boot/system disk and expect them to run in  
> different machines.  It doesn't really matter how this is accomplished,  
> just that there is a plan for it and hopefully it doesn't involve a  
> human needing to know every possible thing that anaconda knows about  
> hardware.   Could there be a way to re-run anaconda after moving a  
> system to new hardware and do an automatic fix-up?

I thought good disks had built-in UUIDs in the firmware (perhaps this 
is only for Fibre Channel).  Or you could use the serial number which 
shows up under "smartctl -a" to identify physical disks.  And some 
fancy disk shelves have "identify disk" commands which blinks some LED 
on the front of the disk.

Once you know which physical disk is the one you want, you can clone 
to that disk and then reset the UUIDs or LABELs to unique values.



From d.lesca at solinos.it  Fri Nov 21 15:31:51 2008
From: d.lesca at solinos.it (Dario Lesca)
Date: Fri, 21 Nov 2008 16:31:51 +0100
Subject: mod_mono: /var/run access denied
Message-ID: <1227281511.5504.133.camel@lesca>

Hi Paul,

I have just discover a bug using the last version of mod_mono

> * Sat Oct 11 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-6
> - use var run instead of tmp
> - added additional Requires

On my system (f10 and f9) the folder /var/run is not accessible in write
mode for user apache then when apache loads the mod_mono module I've got
this error:

> [Fri Nov 21 16:02:11 2008] [crit] (13)Permission denied: Failed to
> create shared memory segment for backend 'XXGLOBAL' at
> '/var/run/mod_mono_dashboard_XXGLOBAL_1'.

then the module is not loaded.

If I "chmod 777 /var/run" the module is loaded and all works fine, but I
do not want to "chmod 777 /var/run"!!

I have tried to set some module variables like these
    MonoWapiDir "/tmp"
    MonoUnixSocket "/tmp/monosochek"
but the DASHBOARD_FILE is not a changeable value. 

Then i have produce a little patch to these 2 files:
 - SPECS/mod_mono.spec
 - SOURCES/mod_mono-2.0-varrun.patch
(see attach)

I have also fill this bug into bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=472529

Take care of this patch, please evaluate it and eventually release it.

Many Thanks

Best Regards 

-- 
Dario Lesca <d.lesca at solinos.it>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mod_mono-2.0-7.tar.gz
Type: application/x-compressed-tar
Size: 1906 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081121/0927add8/attachment.bin>

From hughsient at gmail.com  Fri Nov 21 15:43:14 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 21 Nov 2008 15:43:14 +0000
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227191607.4076.29.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
Message-ID: <1227282194.3359.83.camel@hughsie-laptop>

On Thu, 2008-11-20 at 14:33 +0000, Richard Hughes wrote:
> The packaging guidelines have a single sentence on package summaries:
> https://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description
> 
> "The summary should be a short and concise description of the package"

Sorry to keep going on about this,  but this is the contents of the
email I'm about to send to ~50 package maintainers.
_______________________________________________________________

Hi!

You've received this email because you're listed as a maintainer of one
or more packages in Fedora with a "bad summary"[1]. We've been talking
recently about perhaps adding clarification to the package guidelines,
specifically about what a package summary should contain:

Many GUI packaging tools make the summary more prominent than the
package name. The summary is often a better description for the end user
when making a decision about installing. To make the user's experience
better here, we try to have short succinct summaries that don't repeat
information in the name.

The summary needs to show differentiators that help the user choose
which package to take a look at in more detail. Depending on the type of
package we're looking at some of these should have different
information than others. Libraries should also make clear what
programming language they're useful for in addition to their claim to
fame.

The summary should also be a verb phrase, for example "DVD and CD
authoring software" rather than "Create video DVDs and CDs". For some
packages it may be helpful to expand the package name that is an
acronym, e.g. for the package "gimp", the summary could be "GNU Image
Manipulation Program".

Good summaries:

* Package management framework
* XQuery and XPath 2.0 library for Xerces-C
* Simple video DVD and CD authoring software
* Feature rich media player
* Media Player from the Mozilla Foundation
* Gstreamer based media player
* Customizable media player

Bad summaries:

* System daemon that is a DBUS abstraction layer for package management
(too verbose)
* XQilla is an XQuery and XPath 2.0 library, built on top of Xerces-C
(repeating the program name)
* DeVeDe is a program to create video DVDs and CDs (VCD, sVCD or CVD)
(to much detail)

If you have any questions or just want me to commit a fix and leave you
alone, please feel free to email me back.

Thanks,

Richard

[1] where "bad" is defined by a simple tool written by me, and isn't a
reflection on you as a maintainer. :-)
_______________________________________________________________________

What do you think of that?

Richard.




From sandeen at redhat.com  Fri Nov 21 15:52:42 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Fri, 21 Nov 2008 09:52:42 -0600
Subject: source file audit - 2008-11-14
In-Reply-To: <20081119170909.29694973@ohm.scrye.com>
References: <20081119170909.29694973@ohm.scrye.com>
Message-ID: <4926D94A.1020404@redhat.com>

Kevin Fenzi wrote:
> Here's attached another run of my sources/patches url checker. 
> Sorry for the delay in re-running this. 
> 
> Hopefully I will start running it again at the first of each month. 
> 
> - There are 912 lines in this run. Up from 662 last run.
> This is a pretty sad increase. ;( 

Just an idea; should rpmlint check for bad source URLs?  And should that
maybe get tied in to the commit/tag/build process somehow so you get
more direct feedback?

I'm most likely to fix this stuff if I'm in the middle of making some
other change, and an automatic check while I'm working on a package that
says "hey your source URL is no longer valid" would probably provoke me
to fix it quickly.  :)

-Eric



From naheemzaffar at gmail.com  Fri Nov 21 15:52:28 2008
From: naheemzaffar at gmail.com (Naheem Zaffar)
Date: Fri, 21 Nov 2008 15:52:28 +0000
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227282194.3359.83.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
Message-ID: <3adc77210811210752s64d445f1x49874677b40361c@mail.gmail.com>

Considering that the package name is not given much prominence in the UI, is
it really a bad thing to repeat it in the summary?


> * XQilla is an XQuery and XPath 2.0 library, built on top of Xerces-C
> (repeating the program name)
> * DeVeDe is a program to create video DVDs and CDs (VCD, sVCD or CVD)
> (to much detail)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081121/e6933b37/attachment.htm>

From musuruan at gmail.com  Fri Nov 21 15:56:32 2008
From: musuruan at gmail.com (Andrea Musuruane)
Date: Fri, 21 Nov 2008 16:56:32 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227282194.3359.83.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
Message-ID: <29fee02b0811210756r37bfc46fqa3301df097f5adf5@mail.gmail.com>

2008/11/21 Richard Hughes <hughsient at gmail.com>:
> What do you think of that?

First of all, I'd like to point out that many of the package you are
talking about are in RPM Fusion and not in Fedora.

I think that a packager has every right to make the best summary that
he can think of in less than 80 characters. Therefore statements like
"to much detail" for "DeVeDe is a program to create video DVDs and CDs
(VCD, sVCD or CVD)" are nonsense for me.

I can agree that the summary should not contain the package name -
because it is already written in another field.

I am not willing to make any other changes. Sorry. I think that
packagers have much more *serious* activities to do in their _limited
time_.

Regards,

Andrea.



From pemboa at gmail.com  Fri Nov 21 16:00:55 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 21 Nov 2008 10:00:55 -0600
Subject: What do we need from Bugzilla? (was: My roadmap for a better
	Fedora)
In-Reply-To: <20081121144620.GA16263@orient.maison.lan>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>
	<20081121095053.GA15636@orient.maison.lan>
	<11giv5xecm.ln2@ppp1053.in.ipex.cz>
	<20081121112543.GB15943@orient.maison.lan>
	<4926C024.7050303@gmail.com>
	<20081121144620.GA16263@orient.maison.lan>
Message-ID: <16de708d0811210800t3c146aear35c6b48248d5c172@mail.gmail.com>

On Fri, Nov 21, 2008 at 8:46 AM, Emmanuel Seyman
<emmanuel.seyman at club-internet.fr> wrote:
> * Les Mikesell [21/11/2008 15:16] :
>>
>> If someone does this right, maybe it would be possible to cascade all
>> the way up from user/site/enterprise instances and a working version
>
> It could be done. This is why so much work has been done on the XML-RPC
> workings for Bugzilla 3.2.
>
>> included in the distribution would have templates for all the packages
>> and a checkbox for whether or not to push a specific entry upstream or
>> not.
>
> Deciding to push a bug upstream or not cannot be reduced to checking a
> box or pushing a button. You need to search the upstream bug tracker
> before submitting and link your bug to an already existing bug in
> upstream if it already exists, fill in new fields and make sure that
> the fields that are dropped don't make the bug incomprehensible.
>
> Emmanuel


Wait, there is already an XML-RPC extension? My (possible) time may be
better spent building a UI then?

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From ivazqueznet at gmail.com  Fri Nov 21 16:02:33 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 21 Nov 2008 11:02:33 -0500
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <29fee02b0811210756r37bfc46fqa3301df097f5adf5@mail.gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<29fee02b0811210756r37bfc46fqa3301df097f5adf5@mail.gmail.com>
Message-ID: <1227283353.736.187.camel@ignacio.lan>

On Fri, 2008-11-21 at 16:56 +0100, Andrea Musuruane wrote:
> 2008/11/21 Richard Hughes <hughsient at gmail.com>:
> > What do you think of that?
> 
> First of all, I'd like to point out that many of the package you are
> talking about are in RPM Fusion and not in Fedora.

I think that point is irrelevant as RPM Fusion follows the same
packaging guidelines as Fedora with a few legislation- and
license-related exceptions.

-- 
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/20081121/bb5e0b81/attachment.sig>

From opensource at till.name  Fri Nov 21 16:10:49 2008
From: opensource at till.name (Till Maas)
Date: Fri, 21 Nov 2008 17:10:49 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227282194.3359.83.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
Message-ID: <200811211710.57942.opensource@till.name>

On Fri November 21 2008, Richard Hughes wrote:

> Good summaries:
>
> * Package management framework
> * XQuery and XPath 2.0 library for Xerces-C
> * Simple video DVD and CD authoring software
> * Feature rich media player
> * Media Player from the Mozilla Foundation
> * Gstreamer based media player
> * Customizable media player
>
> Bad summaries:
>
> * System daemon that is a DBUS abstraction layer for package management
> (too verbose)

I disagree that "Package management framework" would be a better summary 
instead of above, because imho it is a useful information that it is a daemon 
and uses DBUS.

> * XQilla is an XQuery and XPath 2.0 library, built on top of Xerces-C
> (repeating the program name)

In contradiction to above, the reworked summary for this still contains all 
the information. Here the alternative is a good improvement.

Also all the differen summaries for media players above do not really provide 
much information that allows to distinguish them, e.g. is the gstreamer based 
media player or the player from Mozilla not feature rich or customizable? I 
don't know, but the summary does not really help here.

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/20081121/4a03ffe0/attachment.sig>

From nicolas.mailhot at laposte.net  Fri Nov 21 16:13:21 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 21 Nov 2008 17:13:21 +0100
Subject: where's the wish list for F11?
In-Reply-To: <gg6ifb$490$1@ger.gmane.org>
References: <gg4dm5$ts1$1@ger.gmane.org>
	<alpine.LFD.2.00.0811201455510.16994@localhost.localdomain>
	<gg554h$6mi$1@ger.gmane.org>	<20081121094044.GA24555@mokona.greysector.net>
	<1227263653.9545.18.camel@arekh.okg>
	<20081121112829.GC24555@mokona.greysector.net>
	<1227270285.9545.27.camel@arekh.okg>  <gg6ifb$490$1@ger.gmane.org>
Message-ID: <1227284001.13179.14.camel@arekh.okg>

Le vendredi 21 novembre 2008 ? 10:00 -0500, sean darcy a ?crit :

> But can't this be done without making an rpm package ( which may or may 
> not raise legal issues).

Installing anything via an rpm will be just as legal (or not) as
installing it by other means

> I'm looking for something much simpler: I go buy/get a font;  I open 
> fonts-filesystem/system-config-fonts/whatever ; I point it to the font ( 
> Type1, TT, etc); and the font is installed.

So you're asking for a font-specific installation method.
Why not add a clipart-specific one? And a templates-specific one? And a
palette-specific one?

This quickly ends up an unmanageable mess wasting the time of everyone
involved.

You already have a limited user-level font installation method for
casual users (or had, a bug is open to resurect it). Anything more
complex, such as a system-wide method needing to replicate all the work
we already do in rpm, is a waste of resources.

> Making an rpm package of the font first seems to make this more involved 
> than it needs to be.

The key word here is seems. Like many other "shortcuts", trying to avoid
making an rpm will end up a lot more work unless you really know what
you're doing (which you only will after having made a few rpms).

-- 
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/20081121/c1a04969/attachment.sig>

From musuruan at gmail.com  Fri Nov 21 16:13:33 2008
From: musuruan at gmail.com (Andrea Musuruane)
Date: Fri, 21 Nov 2008 17:13:33 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227283353.736.187.camel@ignacio.lan>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<29fee02b0811210756r37bfc46fqa3301df097f5adf5@mail.gmail.com>
	<1227283353.736.187.camel@ignacio.lan>
Message-ID: <29fee02b0811210813o5e2dc6fax7063159020ba4c42@mail.gmail.com>

2008/11/21 Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> I think that point is irrelevant as RPM Fusion follows the same
> packaging guidelines as Fedora with a few legislation- and
> license-related exceptions.

I perfectly know that RPM Fusion follows almost the same guidelines. I
was just pointing out that some of the package Richard was talking
about are not in Fedora.

And, as a matter of fact, I don't see a guideline that forbids what
this thread is discussing.

Andrea.



From mhlavink at redhat.com  Fri Nov 21 16:18:38 2008
From: mhlavink at redhat.com (Michal Hlavinka)
Date: Fri, 21 Nov 2008 17:18:38 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <29fee02b0811210813o5e2dc6fax7063159020ba4c42@mail.gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>	<1227282194.3359.83.camel@hughsie-laptop>	<29fee02b0811210756r37bfc46fqa3301df097f5adf5@mail.gmail.com>	<1227283353.736.187.camel@ignacio.lan>
	<29fee02b0811210813o5e2dc6fax7063159020ba4c42@mail.gmail.com>
Message-ID: <4926DF5E.5070008@redhat.com>

Andrea Musuruane wrote:
> 2008/11/21 Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
>   
>> I think that point is irrelevant as RPM Fusion follows the same
>> packaging guidelines as Fedora with a few legislation- and
>> license-related exceptions.
>>     
>
> I perfectly know that RPM Fusion follows almost the same guidelines. I
> was just pointing out that some of the package Richard was talking
> about are not in Fedora.
>   

This is also good point. What about third party packages?
For example:
java, acroread, flash-plugin, ...

They probably won't change their summary if it is too long.




From cdahlin at redhat.com  Fri Nov 21 16:20:39 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Fri, 21 Nov 2008 11:20:39 -0500
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
In-Reply-To: <f4sgv5x6h7.ln2@ppp1053.in.ipex.cz>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>	<6aufv5xi4u.ln2@ppp1053.in.ipex.cz>	<7deeb2190ab5fc7bff30a343cc9e5c49.squirrel@arekh.dyndns.org>	<4925B2FE.2030408@redhat.com>
	<f4sgv5x6h7.ln2@ppp1053.in.ipex.cz>
Message-ID: <4926DFD7.9090700@redhat.com>

Matej Cepl wrote:
> On 2008-11-20, 18:57 GMT, Casey Dahlin wrote:
>   
>> Either way I think a new bug tracker would be an opportunity to 
>> improve on this point.
>>     
>
> Great, write one ;-).
>   
I'm forcefully restraining myself from doing so. :)

--CJD



From opensource at till.name  Fri Nov 21 16:22:56 2008
From: opensource at till.name (Till Maas)
Date: Fri, 21 Nov 2008 17:22:56 +0100
Subject: where's the wish list for F11?
In-Reply-To: <1227284001.13179.14.camel@arekh.okg>
References: <gg4dm5$ts1$1@ger.gmane.org> <gg6ifb$490$1@ger.gmane.org>
	<1227284001.13179.14.camel@arekh.okg>
Message-ID: <200811211723.07134.opensource@till.name>

On Fri November 21 2008, Nicolas Mailhot wrote:
> Le vendredi 21 novembre 2008 ? 10:00 -0500, sean darcy a ?crit :
> > But can't this be done without making an rpm package ( which may or may
> > not raise legal issues).
>
> Installing anything via an rpm will be just as legal (or not) as
> installing it by other means
>
> > I'm looking for something much simpler: I go buy/get a font;  I open
> > fonts-filesystem/system-config-fonts/whatever ; I point it to the font (
> > Type1, TT, etc); and the font is installed.
>
> So you're asking for a font-specific installation method.
> Why not add a clipart-specific one? And a templates-specific one? And a
> palette-specific one?

I guess everybody would be happy if the system-config-font tool would just 
create a simple rpm for the font a user points to the tool and install it via 
rpm.

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/20081121/48561e98/attachment.sig>

From pertusus at free.fr  Fri Nov 21 16:26:38 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 21 Nov 2008 17:26:38 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <29fee02b0811210813o5e2dc6fax7063159020ba4c42@mail.gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<29fee02b0811210756r37bfc46fqa3301df097f5adf5@mail.gmail.com>
	<1227283353.736.187.camel@ignacio.lan>
	<29fee02b0811210813o5e2dc6fax7063159020ba4c42@mail.gmail.com>
Message-ID: <20081121162638.GI2642@free.fr>

On Fri, Nov 21, 2008 at 05:13:33PM +0100, Andrea Musuruane wrote:
> 2008/11/21 Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> > I think that point is irrelevant as RPM Fusion follows the same
> > packaging guidelines as Fedora with a few legislation- and
> > license-related exceptions.
> 
> I perfectly know that RPM Fusion follows almost the same guidelines. I
> was just pointing out that some of the package Richard was talking
> about are not in Fedora.
> 
> And, as a matter of fact, I don't see a guideline that forbids what
> this thread is discussing.

No guideline doesn't mean that things cannot be improved. The fact that
it is not mandatory doesn't make it less important.

--
Pat



From cdahlin at redhat.com  Fri Nov 21 16:41:03 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Fri, 21 Nov 2008 11:41:03 -0500
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <4925C852.1040904@gmail.com>
References: <20081120145628.GB28357@nostromo.devel.redhat.com>	<1227193973.3752.858.camel@beck.corsepiu.local>	<1227194392.4076.31.camel@hughsie-laptop>	<49258DA7.5050808@gmail.com>	<1227198578.4076.37.camel@hughsie-laptop>	<49259275.3000201@gmail.com>	<1227202829.4076.72.camel@hughsie-laptop>	<20081120183306.GA32047@nostromo.devel.redhat.com>	<16de708d0811201036p8f4989qe4d840ef7ad38d34@mail.gmail.com>	<604aa7910811201101q2e2dc74cx5f450b25e67db47@mail.gmail.com>	<20081120194814.GQ24297@angus.ind.WPI.EDU>
	<4925C852.1040904@gmail.com>
Message-ID: <4926E49F.5050600@redhat.com>

Toshio Kuratomi wrote:
> Chuck Anderson wrote:
>   
>> On Thu, Nov 20, 2008 at 10:01:14AM -0900, Jeff Spaleta wrote:
>>     
>>> PackageKit is the store
>>> the Package groups are the Aisle
>>> The package name is the brand of headache medince
>>> The package description is the fine print on the bottle
>>>
>>> What's the summary?
>>>       
>> The sign above the aisle that says "headache medicine"?  Or perhaps 
>> the sign on the shelf itself?
>>
>> Or, it could be the smaller title below the brand name on the bottle 
>> that says "headache and pain relief".  Generally the brand name is the 
>> most prominent title, which would suggest that the Package Name should 
>> be larger/more prominent in PackageKit than the Summary.
>>
>>     
>
> I'd argue that's what Groups are for.  In jef's analogy, it's the Aisle
> which your "sign above the aisle" reflects.
>
> -Toshio
>
>   
Those are different though. An aisle, and likewise a group, contains a 
relatively broad group of semi-related products. A more accurate way to 
say it would be it is /one particular entry/ in the sign above the aisle.

--CJD



From musuruan at gmail.com  Fri Nov 21 16:43:50 2008
From: musuruan at gmail.com (Andrea Musuruane)
Date: Fri, 21 Nov 2008 17:43:50 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081121162638.GI2642@free.fr>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<29fee02b0811210756r37bfc46fqa3301df097f5adf5@mail.gmail.com>
	<1227283353.736.187.camel@ignacio.lan>
	<29fee02b0811210813o5e2dc6fax7063159020ba4c42@mail.gmail.com>
	<20081121162638.GI2642@free.fr>
Message-ID: <29fee02b0811210843w681ff78kddeca5398566fc14@mail.gmail.com>

2008/11/21 Patrice Dumas <pertusus at free.fr>:
> No guideline doesn't mean that things cannot be improved.

Sure.

> The fact that it is not mandatory doesn't make it less important.

We have a set of guidelines that are common ground for reviews. What
it is proposed here is not yet included.

IMHO this proposal is not useful at all. As someone else already
pointed, following Richard's advice, xine, totem, mplayer, vlc would
all have the same description. Is this an improvement for the end
user? I don't think so. Is this an improvement for the packager? Not
at all.

Therefore, Summary is something that the packager should choose on his
own. It must be less than 80 characters and _maybe_ it should not
contain the package name. Everything else is just marketing. If
someone thinks that adding the fact that the application is based on
Gnome, it is fine for me. If someone else thinks that mentioning that
other application uses DBUS it is fine for me too.

Regards,

Andrea.



From hughsient at gmail.com  Fri Nov 21 16:47:12 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 21 Nov 2008 16:47:12 +0000
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <29fee02b0811210843w681ff78kddeca5398566fc14@mail.gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<29fee02b0811210756r37bfc46fqa3301df097f5adf5@mail.gmail.com>
	<1227283353.736.187.camel@ignacio.lan>
	<29fee02b0811210813o5e2dc6fax7063159020ba4c42@mail.gmail.com>
	<20081121162638.GI2642@free.fr>
	<29fee02b0811210843w681ff78kddeca5398566fc14@mail.gmail.com>
Message-ID: <1227286032.3359.84.camel@hughsie-laptop>

On Fri, 2008-11-21 at 17:43 +0100, Andrea Musuruane wrote:
> IMHO this proposal is not useful at all. As someone else already
> pointed, following Richard's advice, xine, totem, mplayer, vlc would
> all have the same description. Is this an improvement for the end
> user? I don't think so. Is this an improvement for the packager? Not
> at all.

I don't think that's true at all, please re-read my email.

Richard.




From hughsient at gmail.com  Fri Nov 21 16:48:30 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 21 Nov 2008 16:48:30 +0000
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <29fee02b0811210756r37bfc46fqa3301df097f5adf5@mail.gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<29fee02b0811210756r37bfc46fqa3301df097f5adf5@mail.gmail.com>
Message-ID: <1227286110.3359.86.camel@hughsie-laptop>

On Fri, 2008-11-21 at 16:56 +0100, Andrea Musuruane wrote:
> I am not willing to make any other changes. Sorry. I think that
> packagers have much more *serious* activities to do in their _limited
> time_.

I'm _not_ saying "change your summary or we'll drop your package" I'm
asking them to come into line with 90% of the other packages in the
distro.

I'm even offering to do the cvs commit myself, if they give me the new
summary line.

Richard.




From pertusus at free.fr  Fri Nov 21 16:49:56 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 21 Nov 2008 17:49:56 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <29fee02b0811210843w681ff78kddeca5398566fc14@mail.gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<29fee02b0811210756r37bfc46fqa3301df097f5adf5@mail.gmail.com>
	<1227283353.736.187.camel@ignacio.lan>
	<29fee02b0811210813o5e2dc6fax7063159020ba4c42@mail.gmail.com>
	<20081121162638.GI2642@free.fr>
	<29fee02b0811210843w681ff78kddeca5398566fc14@mail.gmail.com>
Message-ID: <20081121164956.GK2642@free.fr>

On Fri, Nov 21, 2008 at 05:43:50PM +0100, Andrea Musuruane wrote:
> 
> Therefore, Summary is something that the packager should choose on his
> own. It must be less than 80 characters and _maybe_ it should not
> contain the package name. Everything else is just marketing. If

It should be legible, as short as possible while still being
informative. This is not only marketing. That being said I agree that
putting more in guideline is unuseful, trying to enhance summaries is
useful. Point is that a human should check that the sumary can indeed be
enhanced. And it should better be on review time.

--
Pat



From a.badger at gmail.com  Fri Nov 21 16:53:22 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 21 Nov 2008 08:53:22 -0800
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <3adc77210811210752s64d445f1x49874677b40361c@mail.gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>	<1227282194.3359.83.camel@hughsie-laptop>
	<3adc77210811210752s64d445f1x49874677b40361c@mail.gmail.com>
Message-ID: <4926E782.6080308@gmail.com>

Naheem Zaffar wrote:
> Considering that the package name is not given much prominence in the
> UI, is it really a bad thing to repeat it in the summary?
>  
Yes.

As I understand it, the name is shown in the UI, just that the
description is made bold to highlight it.  So if you repeat the name in
the summary you end up with something like this:

gnome-packagekit *gnome-packagekit is an application for installing
packages*
XQilla *XQilla is an XQuery and XPath 2.0 library built on top of Xerces-C*

Pretty silly.

-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/20081121/737d7014/attachment.sig>

From hughsient at gmail.com  Fri Nov 21 16:51:24 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 21 Nov 2008 16:51:24 +0000
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <200811211710.57942.opensource@till.name>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<200811211710.57942.opensource@till.name>
Message-ID: <1227286284.3359.89.camel@hughsie-laptop>

On Fri, 2008-11-21 at 17:10 +0100, Till Maas wrote:
> On Fri November 21 2008, Richard Hughes wrote:
> > * System daemon that is a DBUS abstraction layer for package management
> > (too verbose)
> 
> I disagree that "Package management framework" would be a better summary 
> instead of above, because imho it is a useful information that it is a daemon 
> and uses DBUS.

Right, framework just sounded a more complete word than daemon. Maybe
"Package management service" might be a better name.

> > * XQilla is an XQuery and XPath 2.0 library, built on top of Xerces-C
> > (repeating the program name)
> 
> In contradiction to above, the reworked summary for this still contains all 
> the information. Here the alternative is a good improvement.

Right.

> Also all the differen summaries for media players above do not really provide 
> much information that allows to distinguish them, e.g. is the gstreamer based 
> media player or the player from Mozilla not feature rich or customizable? I 
> don't know, but the summary does not really help here.

I don't think it matters; the user will click on it and read the
description if they are that interested.

Richard.




From pbrobinson at gmail.com  Fri Nov 21 17:14:46 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Fri, 21 Nov 2008 17:14:46 +0000
Subject: problems updating glibc
In-Reply-To: <20081121150955.GA16736@amd.home.annexia.org>
References: <5256d0b0811210527k2fcf1c46k2997c358cb1a3e07@mail.gmail.com>
	<200811210817.43276.dennis@ausil.us>
	<20081121150955.GA16736@amd.home.annexia.org>
Message-ID: <5256d0b0811210914q758498fbxffe215edad4c8436@mail.gmail.com>

>> > Hi All,
>> >
>> > I've seen mention of this (and actually saw it on another system of
>> > mine but it settled down) where glibc-common can't update due to
>> > glibc.
>> >
>> > The machine is a Fit-PC which runs on an AMD Geode. It currently has
>> > the glibc version 2.8.90-14 i686 rpm and attempting to update to 2.9-2
>> > it errors with "package glibc-2.9-2.i686 is intended for a i686
>> > architecture" which seems weird given that its already running the
>> > i686 version. Any ideas?
>> a geode is not i686 compatiable,  it is a i586 cpu + cmov it really needs its
>> own arch for glibc.  rpm and yum both now how to deal with .geode packages.
>> openssl likely needs a .geode rpm also.  olpc has the same issue.  the images
>> they use have i686 versions installed.
>
> I've got one of these crazy boxes too.  Although i686 packages can't
> be installed, they _do_ seem to work if you force them.  Certainly all
> the simple ones I tried anyway, although maybe I didn't try openssl.

I'm not sure, openSSH seems to use nss  now instead of openssl, but I
would have thought they would both use similar CPU ops.

> (It's also worth noting that there are at least two somewhat different
> variations of the Geode.)

Yea, these are the LX which I think is the same or similar to the
OLPC. They also have a crypto/RNG processor too that seems to work
nicely.

Peter



From a.badger at gmail.com  Fri Nov 21 17:15:55 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 21 Nov 2008 09:15:55 -0800
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227282194.3359.83.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
Message-ID: <4926ECCB.6000007@gmail.com>

Richard Hughes wrote:
> On Thu, 2008-11-20 at 14:33 +0000, Richard Hughes wrote:
>> The packaging guidelines have a single sentence on package summaries:
>> https://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description
>>
>> "The summary should be a short and concise description of the package"
> 
> Sorry to keep going on about this,  but this is the contents of the
> email I'm about to send to ~50 package maintainers.
> _______________________________________________________________
> 
> Hi!
> 
> You've received this email because you're listed as a maintainer of one
> or more packages in Fedora with a "bad summary"[1]. We've been talking
> recently about perhaps adding clarification to the package guidelines,
> specifically about what a package summary should contain:
> 
Rather than "what a package summary should contain" I'd write "what
makes a good package summary"

> Many GUI packaging tools make the summary more prominent than the
> package name.

I still want to know if "many" is really true.  At least KPackageKit and
yumex do not do this.  "Our default GUI packaging tool" would be
accurate if "many" is not.

> The summary is often a better description for the end user
> when making a decision about installing. To make the user's experience
> better here, we try to have short succinct summaries that don't repeat
> information in the name.
> 
> The summary needs to show differentiators that help the user choose
> which package to take a look at in more detail. Depending on the type of
> package we're looking at some of these should have different
> information than others. Libraries should also make clear what
> programming language they're useful for in addition to their claim to
> fame.
> 
> The summary should also be a verb phrase, for example "DVD and CD

s/verb/noun/

> authoring software" rather than "Create video DVDs and CDs". For some
> packages it may be helpful to expand the package name that is an
> acronym, e.g. for the package "gimp", the summary could be "GNU Image
> Manipulation Program".
> 
> Good summaries:
> 
s/Good Summaries/Examples/

Add package name as a separate field.  "Package management framework"
might be a good summary for conary but a horrible summary for
createrepo.  I still would like to see individual good summaries next to
bad summaries to show before and after more clearly.

> * Package management framework
> * XQuery and XPath 2.0 library for Xerces-C
> * Simple video DVD and CD authoring software
> * Feature rich media player
> * Media Player from the Mozilla Foundation
> * Gstreamer based media player
> * Customizable media player
> 
> Bad summaries:
> 
> * System daemon that is a DBUS abstraction layer for package management
> (too verbose)
> * XQilla is an XQuery and XPath 2.0 library, built on top of Xerces-C
> (repeating the program name)
> * DeVeDe is a program to create video DVDs and CDs (VCD, sVCD or CVD)
> (to much detail)
> 
I think some of your examples could use some work.

* System daemon that is a DBUS abstraction layer for package management
* Package management framework

What is a "Package management framework"?  Is it createrepo?  Is it yum,
smart, apt? Is it .rpm or .deb?  In fact, it's none of these.  It's a
service (daemon).  It provides a way for a normal user to install
packages.  It's a backend to GUI front-ends.  That seems to be a
security framework for installing packages.  Or a service allowing
end-users to install packages

* Simple video DVD and CD authoring software
* DeVeDe is a program to create video DVDs and CDs (VCD, sVCD or CVD)

The original summary doesn't mention simple.  Does the program aim for
simplicity?  It mentions VCD, sVCD, and CVD.  Is it aiming for
completeness?  Multiple output formats?  Also, "authoring" is ambiguous.
 Is this a program to create video?  Or is it a program to put video
onto media?

-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/20081121/fbee6c19/attachment.sig>

From a.badger at gmail.com  Fri Nov 21 17:20:53 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 21 Nov 2008 09:20:53 -0800
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <200811211710.57942.opensource@till.name>
References: <1227191607.4076.29.camel@hughsie-laptop>	<1227282194.3359.83.camel@hughsie-laptop>
	<200811211710.57942.opensource@till.name>
Message-ID: <4926EDF5.2040906@gmail.com>

Till Maas wrote:
> 
> Also all the differen summaries for media players above do not really provide 
> much information that allows to distinguish them, e.g. is the gstreamer based 
> media player or the player from Mozilla not feature rich or customizable? I 
> don't know, but the summary does not really help here.
> 

I agree with your other points.  This one is tough, though.  If all of
the media players are customizable and feature rich then what sets yours
apart?  That it comes from a recognizable brand name (Mozilla). That the
goal of the project upstream is to be "customizable".  You can't encode
a complete user-experience in the Summary but you can try to encode
enough that someone will read the description to find out more.

-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/20081121/4785917c/attachment.sig>

From mschwendt at gmail.com  Fri Nov 21 18:09:35 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 21 Nov 2008 19:09:35 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <29fee02b0811210756r37bfc46fqa3301df097f5adf5@mail.gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<29fee02b0811210756r37bfc46fqa3301df097f5adf5@mail.gmail.com>
Message-ID: <20081121190935.eadcc5f3.mschwendt@gmail.com>

On Fri, 21 Nov 2008 16:56:32 +0100, Andrea Musuruane wrote:

> 2008/11/21 Richard Hughes:
> > What do you think of that?
> 
> First of all, I'd like to point out that many of the package you are
> talking about are in RPM Fusion and not in Fedora.
> 
> I think that a packager has every right to make the best summary that
> he can think of in less than 80 characters. Therefore statements like
> "to much detail" for "DeVeDe is a program to create video DVDs and CDs
> (VCD, sVCD or CVD)" are nonsense for me.

Nah, it's nonsense to even try listing the supported video formats
in the summary if you can list them in the longer and detailed
description. What about MVCD,XVCD,XSVCD,RSVCD,TVCD,TSVCD and others?
The short summary simply cannot answer a lot of questions the user
might have.

I'd go even further than Richard and cut

   Simple video DVD and CD authoring software

to 

   Simple video DVD and CD authoring

;) because it doesn't matter that it's "software" or "a program".
Way too many packages contain "programs". It's nothing special that
must be highlighted in a summary, which is supposed to be short and
to the point. On the contrary, a "framework" or "development kit"
is special enough to emphasize it, for example.

> I am not willing to make any other changes. Sorry. I think that
> packagers have much more *serious* activities to do in their _limited
> time_.

True. You'll find that the shorter the summary (which is approved during
review), the longer it will stay accurate (and short and to the point).
Not so with too much details, such as mentioning that an app is written
in C++ or Python.



From pemboa at gmail.com  Fri Nov 21 18:46:51 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 21 Nov 2008 12:46:51 -0600
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227286032.3359.84.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<29fee02b0811210756r37bfc46fqa3301df097f5adf5@mail.gmail.com>
	<1227283353.736.187.camel@ignacio.lan>
	<29fee02b0811210813o5e2dc6fax7063159020ba4c42@mail.gmail.com>
	<20081121162638.GI2642@free.fr>
	<29fee02b0811210843w681ff78kddeca5398566fc14@mail.gmail.com>
	<1227286032.3359.84.camel@hughsie-laptop>
Message-ID: <16de708d0811211046k3757695ey8e4681992624d2bf@mail.gmail.com>

On Fri, Nov 21, 2008 at 10:47 AM, Richard Hughes <hughsient at gmail.com> wrote:
> On Fri, 2008-11-21 at 17:43 +0100, Andrea Musuruane wrote:
>> IMHO this proposal is not useful at all. As someone else already
>> pointed, following Richard's advice, xine, totem, mplayer, vlc would
>> all have the same description. Is this an improvement for the end
>> user? I don't think so. Is this an improvement for the packager? Not
>> at all.
>
> I don't think that's true at all, please re-read my email.
>
> Richard.


How would that be bad though.

Would it really be bad if the summaries of xine, totem, mplayer and
VLC all read 'multi-codec media player'?


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From opensource at till.name  Fri Nov 21 19:03:44 2008
From: opensource at till.name (Till Maas)
Date: Fri, 21 Nov 2008 20:03:44 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <4926EDF5.2040906@gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<200811211710.57942.opensource@till.name> <4926EDF5.2040906@gmail.com>
Message-ID: <200811212003.53974.opensource@till.name>

On Fri November 21 2008, Toshio Kuratomi wrote:
> Till Maas wrote:
> > Also all the differen summaries for media players above do not really
> > provide much information that allows to distinguish them, e.g. is the
> > gstreamer based media player or the player from Mozilla not feature rich
> > or customizable? I don't know, but the summary does not really help here.
>
> I agree with your other points.  This one is tough, though.  If all of
> the media players are customizable and feature rich then what sets yours
> apart?  That it comes from a recognizable brand name (Mozilla). That the
> goal of the project upstream is to be "customizable".  You can't encode
> a complete user-experience in the Summary but you can try to encode
> enough that someone will read the description to find out more.

I don't know which media player was meant by each description, but here are 
some sample features that may make it easier to distinguish media players:

- For commandline usage (mplayer)
- lightweight (e.g. an XFCE media player, if there is one)
- only for audio (afaik this matches amarok)
- support for protable media devices / podcasts (feature of amarok)
- frontend for mplayer
- manager for audio files (amarok)
- is it for GNOME / KDE / XFCE / whatever?
- Remote control support
- support for DJing, e.g. mixing from one file into another
- intended to be used with touchscreens or on home entertainment systems

Here are some examples of summaries I would like:

amarok:
- Audio player and manager for KDE with podcast support

mplayer:
- commandline audio and video player

kmplayer (does it exist?):
- KDE frontend for mplayer, an audio and video player

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/20081121/a3e7ad11/attachment.sig>

From opensource at till.name  Fri Nov 21 19:11:54 2008
From: opensource at till.name (Till Maas)
Date: Fri, 21 Nov 2008 20:11:54 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227286284.3359.89.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<200811211710.57942.opensource@till.name>
	<1227286284.3359.89.camel@hughsie-laptop>
Message-ID: <200811212011.55524.opensource@till.name>

On Fri November 21 2008, Richard Hughes wrote:
> On Fri, 2008-11-21 at 17:10 +0100, Till Maas wrote:
> > On Fri November 21 2008, Richard Hughes wrote:
> > > * System daemon that is a DBUS abstraction layer for package management
> > > (too verbose)
> >
> > I disagree that "Package management framework" would be a better summary
> > instead of above, because imho it is a useful information that it is a
> > daemon and uses DBUS.
>
> Right, framework just sounded a more complete word than daemon. Maybe
> "Package management service" might be a better name.

How about "DBUS-based package management service"?

> > Also all the differen summaries for media players above do not really
> > provide much information that allows to distinguish them, e.g. is the
> > gstreamer based media player or the player from Mozilla not feature rich
> > or customizable? I don't know, but the summary does not really help here.
>
> I don't think it matters; the user will click on it and read the
> description if they are that interested.

If one uses "yum search", then there is no easy clicking. Also it is imho a 
better user experience, if the different players are easier to distinguish 
with a GUI, if they all have more or less only the information "this is an 
media player", it would be probably better to only display a category summary 
for them on the GUI.

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/20081121/b0c41733/attachment.sig>

From lesmikesell at gmail.com  Fri Nov 21 19:14:01 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 21 Nov 2008 13:14:01 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <20081121152033.GB20122@angus.ind.WPI.EDU>
References: <49234139.1050400@gmail.com>	<1227057520.4687.45.camel@firewall.xsintricity.com>	<4923836B.1090309@gmail.com>	<1227110198.4687.108.camel@firewall.xsintricity.com>	<492467D6.7050803@gmail.com>	<1227126323.4687.178.camel@firewall.xsintricity.com>	<49250B08.4080206@gmail.com>
	<ddlfv5x4hr.ln2@ppp1053.in.ipex.cz>	<49256EC6.9070000@gmail.com>
	<4926C39E.4030507@gmail.com>
	<20081121152033.GB20122@angus.ind.WPI.EDU>
Message-ID: <49270879.6010605@gmail.com>

Chuck Anderson wrote:
> On Fri, Nov 21, 2008 at 08:20:14AM -0600, Les Mikesell wrote:
>> Les Mikesell wrote:
>>> Matej Cepl wrote:
>>>> On 2008-11-20, 07:00 GMT, Les Mikesell wrote:
>>>>> Maybe - but it isn't a real solution.  You still have to deal with  
>>>>> identifying the device before and during the labeling process.  If  
>>>>> you can do that, you didn't really need the label.
>>>> Sorry, maybe I don't understand, but what's so difficult on the  
>>>> following?
>>>>
>>>> tune2fs -l /dev/sda1 |awk '/UUID/ {print $3}'
>>>>
>>> The disk may be unformatted at this point and not have a UUID. 
>> I know it is bad form to follow up to my own posting, but I think I've  
>> been making my argument in the wrong way so far.  I'm not really against  
>> changes in the way things are done or even the details of those changes  
>> as long as they are exposed somehow.  What I am against is hiding those  
>> changes in anaconda or other parts of the installer process so that the  
>> only reasonable way to build several machines is to automate the way you  
>> interact with anaconda with another tool like cobbler, and after it is  
>> built you can't change anything.
>>
>> We need a way to do the things that only anaconda knows how to do at  
>> times other than the initial install.  For example, you want to move a  
>> working system disk to another machine, or replace the booting disk  
>> controller, or restore your backups onto a similar system.  Or clone a  
>> bunch of copies of the same boot/system disk and expect them to run in  
>> different machines.  It doesn't really matter how this is accomplished,  
>> just that there is a plan for it and hopefully it doesn't involve a  
>> human needing to know every possible thing that anaconda knows about  
>> hardware.   Could there be a way to re-run anaconda after moving a  
>> system to new hardware and do an automatic fix-up?
> 
> I thought good disks had built-in UUIDs in the firmware (perhaps this 
> is only for Fibre Channel).  Or you could use the serial number which 
> shows up under "smartctl -a" to identify physical disks.  And some 
> fancy disk shelves have "identify disk" commands which blinks some LED 
> on the front of the disk.
> 
> Once you know which physical disk is the one you want, you can clone 
> to that disk and then reset the UUIDs or LABELs to unique values.

There are several different layers to this problem - and it isn't really 
restricted to servers.  Everyone needs to know that if their machine 
dies they can move the system disk to a similar box or restore their 
backups and keep working.  So, consider the simple where you move a scsi 
boot drive to a new machine that has a different scsi controller and 
different ethernet adapters.  You can boot in rescue mode from the 
install CD and have your old partitions automatically mounted, so 
obviously it is possible to figure the driver issues out - but the thing 
that can figure it out won't fix things for you.  So first you have to 
get the right drivers to be included and get rid of the old ones by 
twiddling modprobe.conf in some magic ways, build a new initrd, and 
perhaps re-configure grub to use it.  And if you restored from a backup, 
add in making sure the partition identifiers (whatever they might be 
this week) match the identifiers in /etc/fstab or you won't even get to 
the point where the rescue boot will mount the system to fix it.  You 
also have  much the same problem when adding new hardware after the 
initial install or if you swap NIC or disk controller cards.  Everyone 
needs this basic capability.  Server admins just need to be able to 
repeat it predictably across a lot of machines.

Once you have the machine in bootable condition with the right drivers 
connected to the available hardware, you need a way to interactively 
explore the new hardware without a gui, sort of like running 'fdisk -l' 
will enumerate the drives and current partitioning, but this tool has to 
be adapted to any new ways of describing mountable objects.  Similarly a 
tool like mii-tool should enumerate your NICs and show which have link 
established - and any other useful information they can detect.  Then, 
once you understand the setup for any hardware type you need to be able 
to script it repeatably for any number of instances with a way to supply 
whatever variables it might need (i.e. mac addresses, UUID's, etc.).

My objections to the changes in fedora are not so much related to any 
details of a change but that they aren't encompassed by scriptable text 
based tools that list and set the options or if those exist they are 
fragmented into a bunch of choices that have to match whatever anaconda 
did that you may not know about.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From emmanuel.seyman at club-internet.fr  Fri Nov 21 19:18:21 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Fri, 21 Nov 2008 20:18:21 +0100
Subject: What do we need from Bugzilla? (was: My roadmap for a better
	Fedora)
In-Reply-To: <16de708d0811210800t3c146aear35c6b48248d5c172@mail.gmail.com>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>
	<20081121095053.GA15636@orient.maison.lan>
	<11giv5xecm.ln2@ppp1053.in.ipex.cz>
	<20081121112543.GB15943@orient.maison.lan>
	<4926C024.7050303@gmail.com>
	<20081121144620.GA16263@orient.maison.lan>
	<16de708d0811210800t3c146aear35c6b48248d5c172@mail.gmail.com>
Message-ID: <20081121191821.GA16752@orient.maison.lan>

* Arthur Pemberton [21/11/2008 17:02] :
>
> Wait, there is already an XML-RPC extension?

The XML-RPC work first appeared in Bugzilla 3.0:
http://www.bugzilla.org/releases/3.0/release-notes.html#v30_feat_xml

Bugzilla 3.2 final should be released at the end of the month and
extends the existing code considerably.

We'll give credit to everyone involved at release time but I want to
point that Red Hat's Bugzilla team contributed heavily to Bugzilla's
XML-RPC codebase, submitting their modifications back to upstream,
helping with QA, ...

>                                              My (possible) time may be
> better spent building a UI then?

Probably.
We'ld like to have more users of the Bugzilla XML-RPC methods, so that
we can extend the code in ways the users wish them.
Please don't hesitate to join us on irc or our mailing lists if you need
help building on Bugzilla or if you want to talk about it.

Emmanuel



From jspaleta at gmail.com  Fri Nov 21 19:22:12 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 21 Nov 2008 10:22:12 -0900
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081121190935.eadcc5f3.mschwendt@gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<29fee02b0811210756r37bfc46fqa3301df097f5adf5@mail.gmail.com>
	<20081121190935.eadcc5f3.mschwendt@gmail.com>
Message-ID: <604aa7910811211122o1d0423c6u88ba2dcdb6833294@mail.gmail.com>

On Fri, Nov 21, 2008 at 9:09 AM, Michael Schwendt <mschwendt at gmail.com> wrote:
> Nah, it's nonsense to even try listing the supported video formats
> in the summary if you can list them in the longer and detailed
> description. What about MVCD,XVCD,XSVCD,RSVCD,TVCD,TSVCD and others?
> The short summary simply cannot answer a lot of questions the user
> might have.

yes... this level of detail is part of the ingredient and side effects
listing on the side of the medicine bottle.

You know what would be interesting.  What if each character in the
summary had a real cost associated with it... but the description did
not... and it was in the packagers and users benefit to use the space
sparingly.   What if for example the UI deliberately tried to put
packages with the shortest Summary first in a search listing.  Would
that put enough value on a concise summary without stripping it of
essential meaning or value as a text string?

-jef



From cra at WPI.EDU  Fri Nov 21 19:27:59 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Fri, 21 Nov 2008 14:27:59 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <49270879.6010605@gmail.com>
References: <4923836B.1090309@gmail.com>
	<1227110198.4687.108.camel@firewall.xsintricity.com>
	<492467D6.7050803@gmail.com>
	<1227126323.4687.178.camel@firewall.xsintricity.com>
	<49250B08.4080206@gmail.com> <ddlfv5x4hr.ln2@ppp1053.in.ipex.cz>
	<49256EC6.9070000@gmail.com> <4926C39E.4030507@gmail.com>
	<20081121152033.GB20122@angus.ind.WPI.EDU>
	<49270879.6010605@gmail.com>
Message-ID: <20081121192759.GB23648@angus.ind.WPI.EDU>

On Fri, Nov 21, 2008 at 01:14:01PM -0600, Les Mikesell wrote:
> Chuck Anderson wrote:
>> On Fri, Nov 21, 2008 at 08:20:14AM -0600, Les Mikesell wrote:
> different ethernet adapters.  You can boot in rescue mode from the  
> install CD and have your old partitions automatically mounted, so  
> obviously it is possible to figure the driver issues out - but the thing  
> that can figure it out won't fix things for you.  So first you have to  
> get the right drivers to be included and get rid of the old ones by  
> twiddling modprobe.conf in some magic ways, build a new initrd, and  
> perhaps re-configure grub to use it.  And if you restored from a backup,  
> add in making sure the partition identifiers (whatever they might be  
> this week) match the identifiers in /etc/fstab or you won't even get to  
> the point where the rescue boot will mount the system to fix it.  You  
> also have  much the same problem when adding new hardware after the  
> initial install or if you swap NIC or disk controller cards.  Everyone  
> needs this basic capability.  Server admins just need to be able to  
> repeat it predictably across a lot of machines.
>
> Once you have the machine in bootable condition with the right drivers  
> connected to the available hardware, you need a way to interactively  
> explore the new hardware without a gui, sort of like running 'fdisk -l'  
> will enumerate the drives and current partitioning, but this tool has to  
> be adapted to any new ways of describing mountable objects.  Similarly a  

blkid ?

> tool like mii-tool should enumerate your NICs and show which have link  
> established - and any other useful information they can detect.  Then,  

ethtool ?

> once you understand the setup for any hardware type you need to be able  
> to script it repeatably for any number of instances with a way to supply  
> whatever variables it might need (i.e. mac addresses, UUID's, etc.).
>
> My objections to the changes in fedora are not so much related to any  
> details of a change but that they aren't encompassed by scriptable text  
> based tools that list and set the options or if those exist they are  
> fragmented into a bunch of choices that have to match whatever anaconda  
> did that you may not know about.

It probably wouldn't take too much to write a script around blkid and 
ethtool to do this.



From lesmikesell at gmail.com  Fri Nov 21 19:33:02 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 21 Nov 2008 13:33:02 -0600
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
In-Reply-To: <20081121144620.GA16263@orient.maison.lan>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>	<c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>	<20081121095053.GA15636@orient.maison.lan>	<11giv5xecm.ln2@ppp1053.in.ipex.cz>	<20081121112543.GB15943@orient.maison.lan>	<4926C024.7050303@gmail.com>
	<20081121144620.GA16263@orient.maison.lan>
Message-ID: <49270CEE.70000@gmail.com>

Emmanuel Seyman wrote:

>> If someone does this right, maybe it would be possible to cascade all  
>> the way up from user/site/enterprise instances and a working version  
> 
> It could be done. This is why so much work has been done on the XML-RPC
> workings for Bugzilla 3.2.

xml-rpc may be workable for close-coupled systems, like distro-specific 
and an upstream package or branch offices or teams to a central office, 
but it's not going to work for large scale fanout.

>> included in the distribution would have templates for all the packages  
>> and a checkbox for whether or not to push a specific entry upstream or  
>> not.
> 
> Deciding to push a bug upstream or not cannot be reduced to checking a
> box or pushing a button.

Wrong answer, if anyone actually wants those bug reports.

> You need to search the upstream bug tracker
> before submitting and link your bug to an already existing bug in
> upstream if it already exists, fill in new fields and make sure that
> the fields that are dropped don't make the bug incomprehensible.

Then you haven't made anything easier.  It really does have to be a 
'check this box' choice if you want to get them.  What if you had a mail 
transport option, hooked to something resembling a moderated mailman 
list upstream for every pre-configured category where you would like 
reports?  The 'send upstream' option would send something both 
human-readable and machine-parsable to the list.  The receiving list 
would have the option to auto-reply with instructions to the user as to 
where and how to manually re-enter this bug, or to auto-create a new bug 
for the package (that might need to be merged with lots of others 
later), or something in between that the moderator(s) could choose. It 
might even be possible for such a thing to exist as a real mail list 
answered by humans or that it could attract volunteers for moderating 
the input into the right places.   In any case an approach like this 
sounds feasible whereas expecting an end user with a problem to figure 
out what some upstream tracker's peculiar fields means is not.  But, 
once someone arbitrated the inbound message to the right place, 
subsequent correspondence would just work, more or less.

And, of course you would want this mechanism to be able to cascade 
downstream too, so any organization could use it to track local problems 
with the option to push it up to the next level, whatever that might be, 
without having to be completely aware of how to do that correctly.

-- 
    Les Mikesell
     lesmikesell at gmail.com



From emmanuel.seyman at club-internet.fr  Fri Nov 21 19:49:07 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Fri, 21 Nov 2008 20:49:07 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227282194.3359.83.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
Message-ID: <20081121194906.GA17123@orient.maison.lan>

* Richard Hughes [21/11/2008 16:44] :
>
> Many GUI packaging tools make the summary more prominent than the
> package name.

Out of curiosity, how much is "Many"?

Emmanuel



From ville.skytta at iki.fi  Fri Nov 21 19:52:46 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Fri, 21 Nov 2008 21:52:46 +0200
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <4926E782.6080308@gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<3adc77210811210752s64d445f1x49874677b40361c@mail.gmail.com>
	<4926E782.6080308@gmail.com>
Message-ID: <200811212152.48078.ville.skytta@iki.fi>

On Friday 21 November 2008, Toshio Kuratomi wrote:
> Naheem Zaffar wrote:
> > Considering that the package name is not given much prominence in the
> > UI, is it really a bad thing to repeat it in the summary?
>
> Yes.
>
> As I understand it, the name is shown in the UI, [...]

Leaving gnome-packagekit's current UI aside, is repeating the package name in 
summary something that people would rather not see done in any case?  I tend 
to think that it'd be better to not repeat it myself.  Just asking in case 
there's clear consensus on this - this is something that would be trivial to 
check in rpmlint.



From lesmikesell at gmail.com  Fri Nov 21 20:00:34 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 21 Nov 2008 14:00:34 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <20081121192759.GB23648@angus.ind.WPI.EDU>
References: <4923836B.1090309@gmail.com>	<1227110198.4687.108.camel@firewall.xsintricity.com>	<492467D6.7050803@gmail.com>	<1227126323.4687.178.camel@firewall.xsintricity.com>	<49250B08.4080206@gmail.com>
	<ddlfv5x4hr.ln2@ppp1053.in.ipex.cz>	<49256EC6.9070000@gmail.com>
	<4926C39E.4030507@gmail.com>	<20081121152033.GB20122@angus.ind.WPI.EDU>	<49270879.6010605@gmail.com>
	<20081121192759.GB23648@angus.ind.WPI.EDU>
Message-ID: <49271362.5020002@gmail.com>

Chuck Anderson wrote:
> 
>> Once you have the machine in bootable condition with the right drivers  
>> connected to the available hardware, you need a way to interactively  
>> explore the new hardware without a gui, sort of like running 'fdisk -l'  
>> will enumerate the drives and current partitioning, but this tool has to  
>> be adapted to any new ways of describing mountable objects.  Similarly a  
> 
> blkid ?

What does that do for unformatted disks? If it reports an md device, how 
do I know that I shouldn't separately use the things it separately also 
reports that might be the underlying elements?  Same for lvm if it shows 
them, or lvm on top of md?

>> tool like mii-tool should enumerate your NICs and show which have link  
>> established - and any other useful information they can detect.  Then,  
> 
> ethtool ?

How do I enumerate the devices with ethtool?

>> once you understand the setup for any hardware type you need to be able  
>> to script it repeatably for any number of instances with a way to supply  
>> whatever variables it might need (i.e. mac addresses, UUID's, etc.).
>>
>> My objections to the changes in fedora are not so much related to any  
>> details of a change but that they aren't encompassed by scriptable text  
>> based tools that list and set the options or if those exist they are  
>> fragmented into a bunch of choices that have to match whatever anaconda  
>> did that you may not know about.
> 
> It probably wouldn't take too much to write a script around blkid and 
> ethtool to do this.

Don't forget these steps are already a level up from where we need to 
start.  We may be moving an installed system to one where the drivers 
don't match current hardware, or we may have added new NICs or disk 
controllers and have to get the appropriate drivers loaded.

And the scripts need to accommodate things that can't be enumerated too, 
like nfs/iscsi mounts and multiple vlans on an interface.

-- 
   Les Mikesell
    lesmikesell at gmail.com




From ivazqueznet at gmail.com  Fri Nov 21 20:01:33 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 21 Nov 2008 15:01:33 -0500
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <16de708d0811211046k3757695ey8e4681992624d2bf@mail.gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<29fee02b0811210756r37bfc46fqa3301df097f5adf5@mail.gmail.com>
	<1227283353.736.187.camel@ignacio.lan>
	<29fee02b0811210813o5e2dc6fax7063159020ba4c42@mail.gmail.com>
	<20081121162638.GI2642@free.fr>
	<29fee02b0811210843w681ff78kddeca5398566fc14@mail.gmail.com>
	<1227286032.3359.84.camel@hughsie-laptop>
	<16de708d0811211046k3757695ey8e4681992624d2bf@mail.gmail.com>
Message-ID: <1227297693.736.204.camel@ignacio.lan>

On Fri, 2008-11-21 at 12:46 -0600, Arthur Pemberton wrote:
> Would it really be bad if the summaries of xine, totem, mplayer and
> VLC all read 'multi-codec media player'?

For xine, totem, and VLC, no. mplayer is a different sort of beast that
needs further clarification.

-- 
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/20081121/e2ad861f/attachment.sig>

From a.badger at gmail.com  Fri Nov 21 20:01:38 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 21 Nov 2008 12:01:38 -0800
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <200811212152.48078.ville.skytta@iki.fi>
References: <1227191607.4076.29.camel@hughsie-laptop>	<3adc77210811210752s64d445f1x49874677b40361c@mail.gmail.com>	<4926E782.6080308@gmail.com>
	<200811212152.48078.ville.skytta@iki.fi>
Message-ID: <492713A2.8060101@gmail.com>

Ville Skytt? wrote:
> On Friday 21 November 2008, Toshio Kuratomi wrote:
>> Naheem Zaffar wrote:
>>> Considering that the package name is not given much prominence in the
>>> UI, is it really a bad thing to repeat it in the summary?
>> Yes.
>>
>> As I understand it, the name is shown in the UI, [...]
> 
> Leaving gnome-packagekit's current UI aside, is repeating the package name in 
> summary something that people would rather not see done in any case?  I tend 
> to think that it'd be better to not repeat it myself.  Just asking in case 
> there's clear consensus on this - this is something that would be trivial to 
> check in rpmlint.
> 
+1

-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/20081121/a2efb5fd/attachment.sig>

From ivazqueznet at gmail.com  Fri Nov 21 20:03:34 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 21 Nov 2008 15:03:34 -0500
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <200811212011.55524.opensource@till.name>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<200811211710.57942.opensource@till.name>
	<1227286284.3359.89.camel@hughsie-laptop>
	<200811212011.55524.opensource@till.name>
Message-ID: <1227297814.736.205.camel@ignacio.lan>

On Fri, 2008-11-21 at 20:11 +0100, Till Maas wrote:
> On Fri November 21 2008, Richard Hughes wrote:
> > On Fri, 2008-11-21 at 17:10 +0100, Till Maas wrote:
> > > On Fri November 21 2008, Richard Hughes wrote:
> > > > * System daemon that is a DBUS abstraction layer for package management
> > > > (too verbose)
> > >
> > > I disagree that "Package management framework" would be a better summary
> > > instead of above, because imho it is a useful information that it is a
> > > daemon and uses DBUS.
> >
> > Right, framework just sounded a more complete word than daemon. Maybe
> > "Package management service" might be a better name.
> 
> How about "DBUS-based package management service"?

Is the fact that it uses D-Bus *really* that important to an end user to
warrant putting it in the summary?

-- 
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/20081121/73b253e8/attachment.sig>

From ville.skytta at iki.fi  Fri Nov 21 20:07:10 2008
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Fri, 21 Nov 2008 22:07:10 +0200
Subject: source file audit - 2008-11-14
In-Reply-To: <4926D94A.1020404@redhat.com>
References: <20081119170909.29694973@ohm.scrye.com>
	<4926D94A.1020404@redhat.com>
Message-ID: <200811212207.12121.ville.skytta@iki.fi>

On Friday 21 November 2008, Eric Sandeen wrote:

> Just an idea; should rpmlint check for bad source URLs?

I think that's something worth looking into sometime.  Filed upstream along 
with some additional thoughts as 
http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/165



From emmanuel.seyman at club-internet.fr  Fri Nov 21 20:36:39 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Fri, 21 Nov 2008 21:36:39 +0100
Subject: What do we need from Bugzilla? (was: My roadmap for a better
	Fedora)
In-Reply-To: <49270CEE.70000@gmail.com>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>
	<20081121095053.GA15636@orient.maison.lan>
	<11giv5xecm.ln2@ppp1053.in.ipex.cz>
	<20081121112543.GB15943@orient.maison.lan>
	<4926C024.7050303@gmail.com>
	<20081121144620.GA16263@orient.maison.lan>
	<49270CEE.70000@gmail.com>
Message-ID: <20081121203639.GA17197@orient.maison.lan>

* Les Mikesell [21/11/2008 20:49] :
>
>> Deciding to push a bug upstream or not cannot be reduced to checking a
>> box or pushing a button.
>
> Wrong answer, if anyone actually wants those bug reports.

Sheer volume of bug reports will not improve development, especially
if the increase is only in the form of duplicate bugs. In fact, this
will slow down development because more time will have to be spent on
bug triage, taking time away from bug fixing.

Emmanuel



From alan at redhat.com  Fri Nov 21 20:43:23 2008
From: alan at redhat.com (Alan Cox)
Date: Fri, 21 Nov 2008 15:43:23 -0500
Subject: problems updating glibc
In-Reply-To: <200811210817.43276.dennis@ausil.us>
References: <5256d0b0811210527k2fcf1c46k2997c358cb1a3e07@mail.gmail.com>
	<200811210817.43276.dennis@ausil.us>
Message-ID: <20081121204323.GB16492@shell.devel.redhat.com>

On Fri, Nov 21, 2008 at 08:13:28AM -0600, Dennis Gilmore wrote:
> a geode is not i686 compatiable,  it is a i586 cpu + cmov it really needs its 

That depends which geode. The GX varies from 486 to 686-ish and the NX is
basically an Athlon



From jspaleta at gmail.com  Fri Nov 21 20:44:31 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 21 Nov 2008 11:44:31 -0900
Subject: What do we need from Bugzilla? (was: My roadmap for a better
	Fedora)
In-Reply-To: <20081121203639.GA17197@orient.maison.lan>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>
	<20081121095053.GA15636@orient.maison.lan>
	<11giv5xecm.ln2@ppp1053.in.ipex.cz>
	<20081121112543.GB15943@orient.maison.lan>
	<4926C024.7050303@gmail.com>
	<20081121144620.GA16263@orient.maison.lan> <49270CEE.70000@gmail.com>
	<20081121203639.GA17197@orient.maison.lan>
Message-ID: <604aa7910811211244t157ba490t1c72ae25a5f8cf22@mail.gmail.com>

On Fri, Nov 21, 2008 at 11:36 AM, Emmanuel Seyman <emmanuel.seyman at club-
> Sheer volume of bug reports will not improve development, especially
> if the increase is only in the form of duplicate bugs. In fact, this
> will slow down development because more time will have to be spent on
> bug triage, taking time away from bug fixing.


There really is no way of getting around the fact that for a lot of
bugs (other than crash reports like kerneloops) triage by an actual
human being may be the pacing item.  If we were going to make a
concerted effort to bring more people in to do triage can we stand up
a target? Do we know how many new bugs we have filed in a typical
week? Can we make a statement that we'd like to see individual
triagers triage X number of bugs in a day or a week on average?  Can
we those sort of numbers to put a target together for a triage
recruitment push? How many people do we need triaging for our current
bug ticket churn rate right now?

-jef



From lesmikesell at gmail.com  Fri Nov 21 20:53:59 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 21 Nov 2008 14:53:59 -0600
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
In-Reply-To: <20081121203639.GA17197@orient.maison.lan>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>	<c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>	<20081121095053.GA15636@orient.maison.lan>	<11giv5xecm.ln2@ppp1053.in.ipex.cz>	<20081121112543.GB15943@orient.maison.lan>	<4926C024.7050303@gmail.com>	<20081121144620.GA16263@orient.maison.lan>	<49270CEE.70000@gmail.com>
	<20081121203639.GA17197@orient.maison.lan>
Message-ID: <49271FE7.3070309@gmail.com>

Emmanuel Seyman wrote:
> * Les Mikesell [21/11/2008 20:49] :
>>> Deciding to push a bug upstream or not cannot be reduced to checking a
>>> box or pushing a button.
>> Wrong answer, if anyone actually wants those bug reports.
> 
> Sheer volume of bug reports will not improve development, especially
> if the increase is only in the form of duplicate bugs.

I'd assume a model where some small percentage are valuable so 
increasing the volume will bring in more meaningful ones.  The hard part 
is filtering them without losing the good ones.

> In fact, this
> will slow down development because more time will have to be spent on
> bug triage, taking time away from bug fixing.

That's something that less specialized volunteers could do.  They would 
only need to understand the bugzilla structure and how to determine if a 
new entry was a duplicate or not.  Maybe that could even be automated. 
If you can't describe the process well enough to automate it, you can't 
expect a new user with a problem to be able to understand what you want 
them to do.  Even the worst case of replying with a mailman 
auto-response that has a FAQ for the bugzilla and list of currently 
known problems would be better than no contact at all and would leave 
you with a database of user experiences that you could mine if you 
decide it is worthwhile.  And the better case gets the email of an 
affected user that will provide the details you need to solve a problem 
into the tracking ticket.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From james at fedoraproject.org  Fri Nov 21 21:37:05 2008
From: james at fedoraproject.org (James Antill)
Date: Fri, 21 Nov 2008 16:37:05 -0500
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <604aa7910811211122o1d0423c6u88ba2dcdb6833294@mail.gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<29fee02b0811210756r37bfc46fqa3301df097f5adf5@mail.gmail.com>
	<20081121190935.eadcc5f3.mschwendt@gmail.com>
	<604aa7910811211122o1d0423c6u88ba2dcdb6833294@mail.gmail.com>
Message-ID: <1227303425.4355.266.camel@code.and.org>

On Fri, 2008-11-21 at 10:22 -0900, Jeff Spaleta wrote:
> On Fri, Nov 21, 2008 at 9:09 AM, Michael Schwendt <mschwendt at gmail.com> wrote:
> > Nah, it's nonsense to even try listing the supported video formats
> > in the summary if you can list them in the longer and detailed
> > description. What about MVCD,XVCD,XSVCD,RSVCD,TVCD,TSVCD and others?
> > The short summary simply cannot answer a lot of questions the user
> > might have.
> 
> yes... this level of detail is part of the ingredient and side effects
> listing on the side of the medicine bottle.
> 
> You know what would be interesting.  What if each character in the
> summary had a real cost associated with it... but the description did
> not... and it was in the packagers and users benefit to use the space
> sparingly.   What if for example the UI deliberately tried to put
> packages with the shortest Summary first in a search listing.  Would
> that put enough value on a concise summary without stripping it of
> essential meaning or value as a text string?

 Yes, because the best possible end game is if all summaries say "does
stuff".

 Now sure, I think there are probably some packages that have less than
optimal summaries ... but I'm not sure length is the most significant
factor. For instance the yum package summary could probably be better,
but I'd bet that'll be by _adding_ characters.
 The fact that a single tool decided that summaries should be used
instead of names, and so summaries should be roughly the same size of
names shouldn't make Fedora packages break their summaries for other
tools ... all IMO.

-- 
James Antill <james at fedoraproject.org>
Fedora



From james at fedoraproject.org  Fri Nov 21 21:58:29 2008
From: james at fedoraproject.org (James Antill)
Date: Fri, 21 Nov 2008 16:58:29 -0500
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <200811212152.48078.ville.skytta@iki.fi>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<3adc77210811210752s64d445f1x49874677b40361c@mail.gmail.com>
	<4926E782.6080308@gmail.com> <200811212152.48078.ville.skytta@iki.fi>
Message-ID: <1227304709.4355.270.camel@code.and.org>

On Fri, 2008-11-21 at 21:52 +0200, Ville Skytt? wrote:
> On Friday 21 November 2008, Toshio Kuratomi wrote:
> > Naheem Zaffar wrote:
> > > Considering that the package name is not given much prominence in the
> > > UI, is it really a bad thing to repeat it in the summary?
> >
> > Yes.
> >
> > As I understand it, the name is shown in the UI, [...]
> 
> Leaving gnome-packagekit's current UI aside, is repeating the package name in 
> summary something that people would rather not see done in any case?  I tend 
> to think that it'd be better to not repeat it myself.  Just asking in case 
> there's clear consensus on this - this is something that would be trivial to 
> check in rpmlint.

 I think most of the hard and fast rules about this are going to fail,
as we are talking about human language. For instance:

% yum search fedora-release
=========================== Matched: fedora-release ============================
fedora-release.noarch : Fedora release files
fedora-release-notes.noarch : Release Notes for Fedora 9.0.0

...now technically both of these fail the "repeat package name in
summary" rule, I'm not sure either of them needs to be "fixed" though.

-- 
James Antill <james at fedoraproject.org>
Fedora



From opensource at till.name  Fri Nov 21 22:06:44 2008
From: opensource at till.name (Till Maas)
Date: Fri, 21 Nov 2008 23:06:44 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227297814.736.205.camel@ignacio.lan>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<200811212011.55524.opensource@till.name>
	<1227297814.736.205.camel@ignacio.lan>
Message-ID: <200811212306.55994.opensource@till.name>

On Fri November 21 2008, Ignacio Vazquez-Abrams wrote:
> On Fri, 2008-11-21 at 20:11 +0100, Till Maas wrote:
> > On Fri November 21 2008, Richard Hughes wrote:
> > > On Fri, 2008-11-21 at 17:10 +0100, Till Maas wrote:
> > > > On Fri November 21 2008, Richard Hughes wrote:
> > > > > * System daemon that is a DBUS abstraction layer for package
> > > > > management (too verbose)
> > > >
> > > > I disagree that "Package management framework" would be a better
> > > > summary instead of above, because imho it is a useful information
> > > > that it is a daemon and uses DBUS.
> > >
> > > Right, framework just sounded a more complete word than daemon. Maybe
> > > "Package management service" might be a better name.
> >
> > How about "DBUS-based package management service"?
>
> Is the fact that it uses D-Bus *really* that important to an end user to
> warrant putting it in the summary?

It is the only fact I know about it that makes it special. I do not really 
know what it does, but as far as I understand it is like yum-cron, except 
that it triggers an action not periodically but via an dbus-event, e.g. when 
the yum metadata was refreshed or when the system got network access. But I 
do not really know which package is it, but this is what I experienced on 
live systems and it seems to match the description.

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/20081121/03a93295/attachment.sig>

From jspaleta at gmail.com  Fri Nov 21 22:10:24 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 21 Nov 2008 13:10:24 -0900
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227303425.4355.266.camel@code.and.org>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<29fee02b0811210756r37bfc46fqa3301df097f5adf5@mail.gmail.com>
	<20081121190935.eadcc5f3.mschwendt@gmail.com>
	<604aa7910811211122o1d0423c6u88ba2dcdb6833294@mail.gmail.com>
	<1227303425.4355.266.camel@code.and.org>
Message-ID: <604aa7910811211410o6ad7b29cke68edf3b71ad7bb@mail.gmail.com>

On Fri, Nov 21, 2008 at 12:37 PM, James Antill <james at fedoraproject.org> wrote:
>  Now sure, I think there are probably some packages that have less than
> optimal summaries ... but I'm not sure length is the most significant
> factor.

I'm coming at this from the point of view that there are different
pressures on the content that needs to be summaries and we aren't
going to find any policy that fits all the packages, or even a
majority of packages.  I don't think we are going to come to a rough
consencous any more concrete than "be aware of summary length"  We can
nitpick individual package summary language to death on a package by
package basis.

Putting a cost on length provides a downward pressure on summary
content without telling any particular packager what they should or
should not provide.

> For instance the yum package summary could probably be better,
> but I'd bet that'll be by _adding_ characters.

So be it.... different pressure balances for different packages.  How
important that the yum package summary really in the scope of end user
oriented UI? Is it ever gonna bubble up in front of a user as part of
a software install selection process?  For something like music player
applications however..where we have multiple peer choices.. multiple
brands on the shelf...position on the shelf can matter..and so can
summary optimization.

We are NOT going to decide on optimal summaries for all packages in a
big group think.  Not going to happen. But if summary length is
important for end-user UI, if "short" really does matter, then the UI
should cost the length and packages which really do matter in the UI
should incorporate that costing as part of jockeying for shelf
position.

>  The fact that a single tool decided that summaries should be used
> instead of names, and so summaries should be roughly the same size of
> names shouldn't make Fedora packages break their summaries for other
> tools ... all IMO.

Who said anything about break their summaries?  I'm talking about
explicitly exposing length of information text as a cost metric. Just
like real world brick and mortar advertising does.  if all 80
characters are of equal cost...there's very little downward pressure
to act as an incentive to make things consice.  Think of it as
character cost as an analog to the dirty socialist hippie notion of a
carbon credits.

-jef



From ivazqueznet at gmail.com  Fri Nov 21 22:25:42 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 21 Nov 2008 17:25:42 -0500
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <200811212306.55994.opensource@till.name>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<200811212011.55524.opensource@till.name>
	<1227297814.736.205.camel@ignacio.lan>
	<200811212306.55994.opensource@till.name>
Message-ID: <1227306342.736.213.camel@ignacio.lan>

On Fri, 2008-11-21 at 23:06 +0100, Till Maas wrote:
> On Fri November 21 2008, Ignacio Vazquez-Abrams wrote:
> > On Fri, 2008-11-21 at 20:11 +0100, Till Maas wrote:
> > > How about "DBUS-based package management service"?
> >
> > Is the fact that it uses D-Bus *really* that important to an end user to
> > warrant putting it in the summary?
> 
> It is the only fact I know about it that makes it special. I do not really 
> know what it does, but as far as I understand it is like yum-cron, except 
> that it triggers an action not periodically but via an dbus-event, e.g. when 
> the yum metadata was refreshed or when the system got network access. But I 
> do not really know which package is it, but this is what I experienced on 
> live systems and it seems to match the description.

Then perhaps it's not special at all. Maybe it *shouldn't* really
"exist" in the end-user's mind outside of gnome-packagekit and/or
KPackageKit.

That's not to say that enterprising/adventurous users shouldn't look
closer, but that sometimes the distinctions just aren't all that
important.

-- 
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/20081121/a1a37a85/attachment.sig>

From opensource at till.name  Fri Nov 21 22:39:52 2008
From: opensource at till.name (Till Maas)
Date: Fri, 21 Nov 2008 23:39:52 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227306342.736.213.camel@ignacio.lan>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<200811212306.55994.opensource@till.name>
	<1227306342.736.213.camel@ignacio.lan>
Message-ID: <200811212340.03580.opensource@till.name>

On Fri November 21 2008, Ignacio Vazquez-Abrams wrote:
> On Fri, 2008-11-21 at 23:06 +0100, Till Maas wrote:
> > On Fri November 21 2008, Ignacio Vazquez-Abrams wrote:
> > > On Fri, 2008-11-21 at 20:11 +0100, Till Maas wrote:
> > > > How about "DBUS-based package management service"?
> > >
> > > Is the fact that it uses D-Bus *really* that important to an end user
> > > to warrant putting it in the summary?
> >
> > It is the only fact I know about it that makes it special. I do not
> > really know what it does, but as far as I understand it is like yum-cron,
> > except that it triggers an action not periodically but via an dbus-event,
> > e.g. when the yum metadata was refreshed or when the system got network
> > access. But I do not really know which package is it, but this is what I
> > experienced on live systems and it seems to match the description.
>
> Then perhaps it's not special at all. Maybe it *shouldn't* really
> "exist" in the end-user's mind outside of gnome-packagekit and/or
> KPackageKit.

If the package should not exist in the end-user's minde, then don't show it to 
them.

> That's not to say that enterprising/adventurous users shouldn't look
> closer, but that sometimes the distinctions just aren't all that
> important.

If the package in question really is part of the process I described above, 
then the usefulness of mentioning DBUS in the summary was already shown. I 
doubt very much that I would have found the connection between this 
beheaviour and a package with the summary "package management service" very 
fast.

Also the summary including "DBUS" is already very short, therefore I see no 
added value in removing it from the summary. If users need to be protected 
from this word in summaries, because they do not know it, then they should 
probably get the software installed anyways to keep their system uptodate. 
And this is the only possible argument that comes to my mind, why it should 
be removed.

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/20081121/0a0ef3f5/attachment.sig>

From opensource at till.name  Fri Nov 21 22:57:16 2008
From: opensource at till.name (Till Maas)
Date: Fri, 21 Nov 2008 23:57:16 +0100
Subject: starting Fedora Server SIG
In-Reply-To: <49271362.5020002@gmail.com>
References: <4923836B.1090309@gmail.com>
	<20081121192759.GB23648@angus.ind.WPI.EDU> <49271362.5020002@gmail.com>
Message-ID: <200811212357.30324.opensource@till.name>

On Fri November 21 2008, Les Mikesell wrote:

> How do I enumerate the devices with ethtool?

This may make eth0 blink, if it supports it:

ethtool --identify eth0 

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/20081121/460a7988/attachment.sig>

From mcepl at redhat.com  Fri Nov 21 22:58:56 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 21 Nov 2008 23:58:56 +0100
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>
	<20081121095053.GA15636@orient.maison.lan>
	<11giv5xecm.ln2@ppp1053.in.ipex.cz>
	<20081121112543.GB15943@orient.maison.lan>
Message-ID: <g2rjv5x04d.ln2@ppp1053.in.ipex.cz>

On 2008-11-21, 11:25 GMT, Emmanuel Seyman wrote:
> Thanks for making their work more difficult, I guess.

I am a bugmaster for the desktop team, so I know a little bit 
what I am doing -- if you are sitting on the email getting all 
NEW bugs into your desktop, catching duplicates is not that big 
problem. After some time, you have some handle on what's the 
current bug-of-the-week, which helps you to quickly eliminate 
many bugs just in the beginning.

Mat?j



From ob.system at gmail.com  Fri Nov 21 23:01:00 2008
From: ob.system at gmail.com (Oscar Victorio Calixto Bacho)
Date: Fri, 21 Nov 2008 17:01:00 -0600
Subject: Python-config no help
Message-ID: <6a28481b0811211501m2eb00a93j149a2d173410a604@mail.gmail.com>

Hi Guys

One python newby question

why /usr/bin/python-config --help say this

Traceback (most recent call last):
  File "/usr/bin/python2.5-config", line 26, in <module>
    pyver = sysconfig.get_config_var('VERSION')
  File "/usr/lib/python2.5/distutils/sysconfig.py", line 535, in
get_config_var
    return get_config_vars().get(name)
  File "/usr/lib/python2.5/distutils/sysconfig.py", line 493, in
get_config_vars
    func()
  File "/usr/lib/python2.5/distutils/sysconfig.py", line 352, in _init_posix
    raise DistutilsPlatformError(my_msg)
distutils.errors.DistutilsPlatformError: invalid Python installation: unable
to open /usr/lib/python2.5/config/Makefile (No such file or directory)

This is correct

Thanks

Oscar Bacho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081121/d593c50c/attachment.htm>

From mcepl at redhat.com  Fri Nov 21 23:01:03 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Sat, 22 Nov 2008 00:01:03 +0100
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>
	<20081121095053.GA15636@orient.maison.lan>
	<11giv5xecm.ln2@ppp1053.in.ipex.cz>
	<20081121112543.GB15943@orient.maison.lan> <4926C024.7050303@gmail.com>
	<20081121144620.GA16263@orient.maison.lan> <49270CEE.70000@gmail.com>
	<20081121203639.GA17197@orient.maison.lan> <49271FE7.3070309@gmail.com>
Message-ID: <f6rjv5x04d.ln2@ppp1053.in.ipex.cz>

On 2008-11-21, 20:53 GMT, Les Mikesell wrote:
> That's something that less specialized volunteers could do.  

Yes, but there is severe lack of them -- it is not that sexy as 
hacking on kernel, I suppose.

Mat?j



From ivazqueznet at gmail.com  Fri Nov 21 23:19:57 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 21 Nov 2008 18:19:57 -0500
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <200811212340.03580.opensource@till.name>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<200811212306.55994.opensource@till.name>
	<1227306342.736.213.camel@ignacio.lan>
	<200811212340.03580.opensource@till.name>
Message-ID: <1227309597.736.226.camel@ignacio.lan>

On Fri, 2008-11-21 at 23:39 +0100, Till Maas wrote:
> On Fri November 21 2008, Ignacio Vazquez-Abrams wrote:
> > On Fri, 2008-11-21 at 23:06 +0100, Till Maas wrote:
> > > On Fri November 21 2008, Ignacio Vazquez-Abrams wrote:
> > > > On Fri, 2008-11-21 at 20:11 +0100, Till Maas wrote:
> > > > > How about "DBUS-based package management service"?
> > > >
> > > > Is the fact that it uses D-Bus *really* that important to an end user
> > > > to warrant putting it in the summary?
> > >
> > > It is the only fact I know about it that makes it special. I do not
> > > really know what it does, but as far as I understand it is like yum-cron,
> > > except that it triggers an action not periodically but via an dbus-event,
> > > e.g. when the yum metadata was refreshed or when the system got network
> > > access. But I do not really know which package is it, but this is what I
> > > experienced on live systems and it seems to match the description.
> >
> > Then perhaps it's not special at all. Maybe it *shouldn't* really
> > "exist" in the end-user's mind outside of gnome-packagekit and/or
> > KPackageKit.
> 
> If the package should not exist in the end-user's minde, then don't show it to 
> them.

I find this idea both intriguing and insightful. But I'll leave the
heuristics and implementation to you.

> > That's not to say that enterprising/adventurous users shouldn't look
> > closer, but that sometimes the distinctions just aren't all that
> > important.
> 
> If the package in question really is part of the process I described above, 
> then the usefulness of mentioning DBUS in the summary was already shown. I 
> doubt very much that I would have found the connection between this 
> beheaviour and a package with the summary "package management service" very 
> fast.

Why does a user care how their packages are managed? I mean, the
technical details are cute, but so what?

> Also the summary including "DBUS" is already very short, therefore I see no 
> added value in removing it from the summary. 

"Perfection is achieved, not when there is nothing more to add, but when
there is nothing left to take away."
- Antoine de Saint-Exupery

> If users need to be protected 
> from this word in summaries, because they do not know it, then they should 
> probably get the software installed anyways to keep their system uptodate.

But they already do, in a default install, so this point is moot.

> And this is the only possible argument that comes to my mind, why it should 
> be removed.

-- 
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/20081121/5e256118/attachment.sig>

From lesmikesell at gmail.com  Sat Nov 22 00:00:04 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 21 Nov 2008 18:00:04 -0600
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
In-Reply-To: <f6rjv5x04d.ln2@ppp1053.in.ipex.cz>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>	<c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>	<20081121095053.GA15636@orient.maison.lan>	<11giv5xecm.ln2@ppp1053.in.ipex.cz>	<20081121112543.GB15943@orient.maison.lan>
	<4926C024.7050303@gmail.com>	<20081121144620.GA16263@orient.maison.lan>
	<49270CEE.70000@gmail.com>	<20081121203639.GA17197@orient.maison.lan>
	<49271FE7.3070309@gmail.com> <f6rjv5x04d.ln2@ppp1053.in.ipex.cz>
Message-ID: <49274B84.7080509@gmail.com>

Matej Cepl wrote:
> On 2008-11-21, 20:53 GMT, Les Mikesell wrote:
>> That's something that less specialized volunteers could do.  
> 
> Yes, but there is severe lack of them -- it is not that sexy as 
> hacking on kernel, I suppose.

If it were as easy as moderating a mailman list there might be more 
takers.  What's the current workflow and where have you requested 
volunteer help?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Sat Nov 22 00:21:32 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 21 Nov 2008 18:21:32 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <200811212357.30324.opensource@till.name>
References: <4923836B.1090309@gmail.com>	<20081121192759.GB23648@angus.ind.WPI.EDU>
	<49271362.5020002@gmail.com>
	<200811212357.30324.opensource@till.name>
Message-ID: <4927508C.1070403@gmail.com>

Till Maas wrote:
> On Fri November 21 2008, Les Mikesell wrote:
> 
>> How do I enumerate the devices with ethtool?
> 
> This may make eth0 blink, if it supports it:
> 
> ethtool --identify eth0 

That's handy if you happen to be within driving distance of the server, 
but not what I meant.  I can run mii-tool with no arguements and it will 
give me a list of the names the kernel chose for all of the NICs it 
found and which ones have an active link.  Ethtool looks like it should 
be a replacement for mii-tool, but doesn't provide quite the same 
things.  Is there another device-identifier tool?

-- 
   Les Mikesell
    lesmikesell at gmail.com




From kzak at redhat.com  Sat Nov 22 00:38:31 2008
From: kzak at redhat.com (Karel Zak)
Date: Sat, 22 Nov 2008 01:38:31 +0100
Subject: My roadmap for a better Fedora
In-Reply-To: <1227119906.7387.138.camel@localhost.localdomain>
References: <1227119906.7387.138.camel@localhost.localdomain>
Message-ID: <20081122003831.GN2961@nb.net.home>

On Wed, Nov 19, 2008 at 12:38:26PM -0600, Callum Lerwick wrote:
> Problem: We need more and wider testing. Why don't we get more testing?

 .. because this work is not attractive. It's boring work without
 proper credit in open source community. It's very simple to found
 list of top-ten kernel developers, but who knows the most active
 bug reporters or QA around kernel? Nobody.

 People who are testing a software are real contributors. Our THANKS
 to them should be more visible!

    Karel

-- 
 Karel Zak  <kzak at redhat.com>



From cra at WPI.EDU  Sat Nov 22 01:20:09 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Fri, 21 Nov 2008 20:20:09 -0500
Subject: starting Fedora Server SIG
In-Reply-To: <49271362.5020002@gmail.com>
References: <492467D6.7050803@gmail.com>
	<1227126323.4687.178.camel@firewall.xsintricity.com>
	<49250B08.4080206@gmail.com> <ddlfv5x4hr.ln2@ppp1053.in.ipex.cz>
	<49256EC6.9070000@gmail.com> <4926C39E.4030507@gmail.com>
	<20081121152033.GB20122@angus.ind.WPI.EDU>
	<49270879.6010605@gmail.com>
	<20081121192759.GB23648@angus.ind.WPI.EDU>
	<49271362.5020002@gmail.com>
Message-ID: <20081122012009.GA27160@angus.ind.WPI.EDU>

On Fri, Nov 21, 2008 at 02:00:34PM -0600, Les Mikesell wrote:
>> blkid ?
>
> What does that do for unformatted disks? If it reports an md device, how  
> do I know that I shouldn't separately use the things it separately also  
> reports that might be the underlying elements?  Same for lvm if it shows  
> them, or lvm on top of md?

I don't follow what you are trying to accomplish here.  All the data 
is available to link the devices together in the stack via the already 
existing tools.  It may not be convenient, but it is there.

>>> tool like mii-tool should enumerate your NICs and show which have 
>>> link  established - and any other useful information they can detect. 
>>>  Then,  
>>
>> ethtool ?
>
> How do I enumerate the devices with ethtool?

Ok, this isn't so great:

for i in `ifconfig -a | cut -d' ' -f1 | sort -u`; do ethtool $i| grep 
-E '^Settings|Link detected'; done

but this works, and I verified that it shows the hardware link status 
(in addition to the ifconfig UP/DOWN status).

ip link show

>> It probably wouldn't take too much to write a script around blkid and  
>> ethtool to do this.
>
> Don't forget these steps are already a level up from where we need to  
> start.  We may be moving an installed system to one where the drivers  
> don't match current hardware, or we may have added new NICs or disk  
> controllers and have to get the appropriate drivers loaded.

I'm not sure I follow what you are saying here.  What was once kudzu's 
job is now handled by hal/udev, which handle hardware changes 
automatically, and the drivers are always there since they are all 
compiled as modules for the kernel...easy of automatic hardware 
detection and driver loading is one reason why Fedora has resisted 
trying to split up the kernel modules into separate packages, and why 
all the X11 video card drivers are installed by default.  Are you 
against running hal/udev because they are userspace daemons that take 
up memory?

> And the scripts need to accommodate things that can't be enumerated too,  
> like nfs/iscsi mounts and multiple vlans on an interface.

Again, I'm not sure what you want from this.  NFS/iSCSI mounts can't 
be automatically discovered from within the installed system 
image--the information about what to mount from where and to where 
needs to come from somewhere.  Perhaps what you want is a centralized 
configuration management system like Puppet or bcfg2?  How does this 
relate to the kernel namespace <--> physical device issue we've been 
discussing above?  How should it work in an ideal world?



From cra at WPI.EDU  Sat Nov 22 01:26:30 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Fri, 21 Nov 2008 20:26:30 -0500
Subject: What do we need from Bugzilla? (was: My roadmap for a better
	Fedora)
In-Reply-To: <g2rjv5x04d.ln2@ppp1053.in.ipex.cz>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>
	<20081121095053.GA15636@orient.maison.lan>
	<11giv5xecm.ln2@ppp1053.in.ipex.cz>
	<20081121112543.GB15943@orient.maison.lan>
	<g2rjv5x04d.ln2@ppp1053.in.ipex.cz>
Message-ID: <20081122012630.GB27160@angus.ind.WPI.EDU>

On Fri, Nov 21, 2008 at 11:58:56PM +0100, Matej Cepl wrote:
> On 2008-11-21, 11:25 GMT, Emmanuel Seyman wrote:
> > Thanks for making their work more difficult, I guess.
> 
> I am a bugmaster for the desktop team, so I know a little bit 
> what I am doing -- if you are sitting on the email getting all 
> NEW bugs into your desktop, catching duplicates is not that big 
> problem. After some time, you have some handle on what's the 
> current bug-of-the-week, which helps you to quickly eliminate 
> many bugs just in the beginning.

How does one sign up to get all NEW bugs for a certain component?



From lesmikesell at gmail.com  Sat Nov 22 03:02:10 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 21 Nov 2008 21:02:10 -0600
Subject: starting Fedora Server SIG
In-Reply-To: <20081122012009.GA27160@angus.ind.WPI.EDU>
References: <492467D6.7050803@gmail.com>	<1227126323.4687.178.camel@firewall.xsintricity.com>	<49250B08.4080206@gmail.com>
	<ddlfv5x4hr.ln2@ppp1053.in.ipex.cz>	<49256EC6.9070000@gmail.com>
	<4926C39E.4030507@gmail.com>	<20081121152033.GB20122@angus.ind.WPI.EDU>	<49270879.6010605@gmail.com>	<20081121192759.GB23648@angus.ind.WPI.EDU>	<49271362.5020002@gmail.com>
	<20081122012009.GA27160@angus.ind.WPI.EDU>
Message-ID: <49277632.4050709@gmail.com>

Chuck Anderson wrote:
> On Fri, Nov 21, 2008 at 02:00:34PM -0600, Les Mikesell wrote:
>>> blkid ?
>> What does that do for unformatted disks? If it reports an md device, how  
>> do I know that I shouldn't separately use the things it separately also  
>> reports that might be the underlying elements?  Same for lvm if it shows  
>> them, or lvm on top of md?
> 
> I don't follow what you are trying to accomplish here.  All the data 
> is available to link the devices together in the stack via the already 
> existing tools.  It may not be convenient, but it is there.

I want to be able to do anything that I might need to do to maintain a 
server or copy it to a new one. For example, add a new scsi controller 
of a different type than was there when the OS was installed and add 
some new disk drives.  How do I (a) know the driver module that needs to 
be added and (b) identify the new blank disks attached?   Or I might 
encounter the same problem if  a motherboard dies and I have to move the 
disks to a different chassis that is not quite the same.

>>>> tool like mii-tool should enumerate your NICs and show which have 
>>>> link  established - and any other useful information they can detect. 
>>>>  Then,  
>>> ethtool ?
>> How do I enumerate the devices with ethtool?
> 
> Ok, this isn't so great:
> 
> for i in `ifconfig -a | cut -d' ' -f1 | sort -u`; do ethtool $i| grep 
> -E '^Settings|Link detected'; done
> but this works, and I verified that it shows the hardware link status 
> (in addition to the ifconfig UP/DOWN status).
> 
> ip link show

I only have a centos 5 handy, but if mii-tool says this:
# mii-tool
eth0: negotiated 100baseTx-FD, link ok
SIOCGMIIPHY on 'eth1' failed: Resource temporarily unavailable
eth2: negotiated 100baseTx-FD, link ok
eth3: no link

shouldn't eth2 be UP here (it isn't, but link is):
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 
qlen 1000
     link/ether 00:14:5e:17:05:10 brd ff:ff:ff:ff:ff:ff
3: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
     link/ether 00:04:23:d8:df:00 brd ff:ff:ff:ff:ff:ff
4: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
     link/ether 00:04:23:d8:df:01 brd ff:ff:ff:ff:ff:ff
5: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
     link/ether 00:14:5e:17:05:12 brd ff:ff:ff:ff:ff:ff
6: sit0: <NOARP> mtu 1480 qdisc noop
     link/sit 0.0.0.0 brd 0.0.0.0

And I wouldn't have guessed the ip command would be the thing to check 
interfaces that aren't configured for IP.

>>> It probably wouldn't take too much to write a script around blkid and  
>>> ethtool to do this.
>> Don't forget these steps are already a level up from where we need to  
>> start.  We may be moving an installed system to one where the drivers  
>> don't match current hardware, or we may have added new NICs or disk  
>> controllers and have to get the appropriate drivers loaded.
> 
> I'm not sure I follow what you are saying here.  What was once kudzu's 
> job is now handled by hal/udev, which handle hardware changes 
> automatically, and the drivers are always there since they are all 
> compiled as modules for the kernel...easy of automatic hardware 
> detection and driver loading is one reason why Fedora has resisted 
> trying to split up the kernel modules into separate packages, and why 
> all the X11 video card drivers are installed by default.

OK, but I may have moved the disk or replaced the motherboard and 
controller, and now need to boot from a module that wasn't included in 
initrd.

> Are you 
> against running hal/udev because they are userspace daemons that take 
> up memory?

No, memory is cheap enough.  And disk is cheap enough that I wouldn't 
mind have an initrd with all drivers available if that's one of the 
choices.

>> And the scripts need to accommodate things that can't be enumerated too,  
>> like nfs/iscsi mounts and multiple vlans on an interface.
> 
> Again, I'm not sure what you want from this.  NFS/iSCSI mounts can't 
> be automatically discovered from within the installed system 
> image--the information about what to mount from where and to where 
> needs to come from somewhere.

I want a mechanism that handles things consistently.  If I have to 
identify and specify the nfs and iscsi targets, then I want to do it the 
same for local devices.

 > Perhaps what you want is a centralized
> configuration management system like Puppet or bcfg2?  How does this 
> relate to the kernel namespace <--> physical device issue we've been 
> discussing above?  How should it work in an ideal world?

Mostly what I want is the ability to ship a disk to a remote location, 
have someone there plug it into a chassis I haven't seen but is similar 
to the one where the disk was made and have it come up automatically 
with at least one IP address on a predictable interface.  Or if that is 
completely impossible, have commands appropriate for describing over the 
phone to someone who has not seen linux before find the correct 
interface both physically and logically and assign the address.  I 
hadn't seen bcfg2 but that's not quite what I want.  A closer 'central' 
model would be drbl/clonezilla but the machines aren't always cloned 
directly in their target host and the eventual hosts don't generally use 
dhcp.  There are variations involving adding and moving things but 
coming up running after something changes is the starting point.

-- 
   Les Mikesell
    lesmikesell at gmail.com




From tmus at tmus.dk  Sat Nov 22 03:18:50 2008
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Sat, 22 Nov 2008 00:18:50 -0300
Subject: where's the wish list for F11?
In-Reply-To: <1227284001.13179.14.camel@arekh.okg>
References: <gg4dm5$ts1$1@ger.gmane.org>	<alpine.LFD.2.00.0811201455510.16994@localhost.localdomain>	<gg554h$6mi$1@ger.gmane.org>	<20081121094044.GA24555@mokona.greysector.net>	<1227263653.9545.18.camel@arekh.okg>	<20081121112829.GC24555@mokona.greysector.net>	<1227270285.9545.27.camel@arekh.okg>
	<gg6ifb$490$1@ger.gmane.org> <1227284001.13179.14.camel@arekh.okg>
Message-ID: <gg7tnl$481$1@ger.gmane.org>

Nicolas Mailhot wrote:
> Le vendredi 21 novembre 2008 ? 10:00 -0500, sean darcy a ?crit :
> 
>> But can't this be done without making an rpm package ( which may or may 
>> not raise legal issues).
> 
> Installing anything via an rpm will be just as legal (or not) as
> installing it by other means
> 
>> I'm looking for something much simpler: I go buy/get a font;  I open 
>> fonts-filesystem/system-config-fonts/whatever ; I point it to the font ( 
>> Type1, TT, etc); and the font is installed.
> 
> So you're asking for a font-specific installation method.
> Why not add a clipart-specific one? And a templates-specific one? And a
> palette-specific one?
> 
> This quickly ends up an unmanageable mess wasting the time of everyone
> involved.
> 
> You already have a limited user-level font installation method for
> casual users (or had, a bug is open to resurect it). Anything more
> complex, such as a system-wide method needing to replicate all the work
> we already do in rpm, is a waste of resources.
> 
>> Making an rpm package of the font first seems to make this more involved 
>> than it needs to be.
> 
> The key word here is seems. Like many other "shortcuts", trying to avoid
> making an rpm will end up a lot more work unless you really know what
> you're doing (which you only will after having made a few rpms).
> 
> 

I don't make RPMS for every wallpaper I download and intend to use on my 
machine. And in my world, fonts are not too different in that respect.

Why not simply provide the default fontconfig package, with the ability 
to load fonts from say "/usr/local/share/fonts" ?

People with this kind of need could simple become root and copy their 
fonts into that directory and be done with it...

Why not?

/THomas







From mclasen at redhat.com  Sat Nov 22 04:47:21 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 21 Nov 2008 23:47:21 -0500
Subject: where's the wish list for F11?
In-Reply-To: <gg7tnl$481$1@ger.gmane.org>
References: <gg4dm5$ts1$1@ger.gmane.org>
	<alpine.LFD.2.00.0811201455510.16994@localhost.localdomain>
	<gg554h$6mi$1@ger.gmane.org>	<20081121094044.GA24555@mokona.greysector.net>
	<1227263653.9545.18.camel@arekh.okg>
	<20081121112829.GC24555@mokona.greysector.net>
	<1227270285.9545.27.camel@arekh.okg> <gg6ifb$490$1@ger.gmane.org>
	<1227284001.13179.14.camel@arekh.okg>  <gg7tnl$481$1@ger.gmane.org>
Message-ID: <1227329241.4618.28.camel@localhost.localdomain>

On Sat, 2008-11-22 at 00:18 -0300, Thomas M Steenholdt wrote:

> Why not simply provide the default fontconfig package, with the ability 
> to load fonts from say "/usr/local/share/fonts" ?
> 
> People with this kind of need could simple become root and copy their 
> fonts into that directory and be done with it...
> 
> Why not?
> 

Because it is even easier to just copy the font to ~/.fonts. No need to
become root. If you want a graphical way to do this, install
nautilus-actions, and look at http://www.grumz.net/?q=node/334


Matthias



From bashton at brennanashton.com  Sat Nov 22 05:03:24 2008
From: bashton at brennanashton.com (Brennan Ashton)
Date: Fri, 21 Nov 2008 21:03:24 -0800
Subject: What do we need from Bugzilla? (was: My roadmap for a better
	Fedora)
In-Reply-To: <20081122012630.GB27160@angus.ind.WPI.EDU>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>
	<20081121095053.GA15636@orient.maison.lan>
	<11giv5xecm.ln2@ppp1053.in.ipex.cz>
	<20081121112543.GB15943@orient.maison.lan>
	<g2rjv5x04d.ln2@ppp1053.in.ipex.cz>
	<20081122012630.GB27160@angus.ind.WPI.EDU>
Message-ID: <981da310811212103t15305259l1d9082d89d5ba45e@mail.gmail.com>

On Fri, Nov 21, 2008 at 5:26 PM, Chuck Anderson <cra at wpi.edu> wrote:
> On Fri, Nov 21, 2008 at 11:58:56PM +0100, Matej Cepl wrote:
>> On 2008-11-21, 11:25 GMT, Emmanuel Seyman wrote:
>> > Thanks for making their work more difficult, I guess.
>>
>> I am a bugmaster for the desktop team, so I know a little bit
>> what I am doing -- if you are sitting on the email getting all
>> NEW bugs into your desktop, catching duplicates is not that big
>> problem. After some time, you have some handle on what's the
>> current bug-of-the-week, which helps you to quickly eliminate
>> many bugs just in the beginning.
>
> How does one sign up to get all NEW bugs for a certain component?

Depends on what you want, if you just want a list to look at, I have
found creating a live bookmark with the rss feed or using google rss
tools to be very helpful.
For instance this would give you the bugs that are in state NEW or
ASSIGNED for component anaconda in fedora 9 and rawhide. I still have
not been able to use the query to order the bugs by date, as I recall
this is done with some cookie magic.

https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&component=anaconda&field-1-0-0=classification&field-1-1-0=product&field-1-2-0=component&field-1-3-0=version&field-1-4-0=bug_status&product=Fedora&query_format=advanced&remaction=&type-1-0-0=anyexact&type-1-1-0=anyexact&type-1-2-0=anyexact&type-1-3-0=anyexact&type-1-4-0=anyexact&value-1-0-0=Fedora&value-1-1-0=Fedora&value-1-2-0=anaconda&value-1-3-0=9%2Crawhide&value-1-4-0=NEW%2CASSIGNED&version=9&version=rawhide&title=Bug%20List&ctype=atom

otherwise I think you have to be in the group for that component,
others know more about this then I do.

--Brennan Ashton



From tmus at tmus.dk  Sat Nov 22 05:03:22 2008
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Sat, 22 Nov 2008 02:03:22 -0300
Subject: where's the wish list for F11?
In-Reply-To: <1227329241.4618.28.camel@localhost.localdomain>
References: <gg4dm5$ts1$1@ger.gmane.org>	<alpine.LFD.2.00.0811201455510.16994@localhost.localdomain>	<gg554h$6mi$1@ger.gmane.org>	<20081121094044.GA24555@mokona.greysector.net>	<1227263653.9545.18.camel@arekh.okg>	<20081121112829.GC24555@mokona.greysector.net>	<1227270285.9545.27.camel@arekh.okg>
	<gg6ifb$490$1@ger.gmane.org>	<1227284001.13179.14.camel@arekh.okg>
	<gg7tnl$481$1@ger.gmane.org>
	<1227329241.4618.28.camel@localhost.localdomain>
Message-ID: <gg83rk$duq$1@ger.gmane.org>

Matthias Clasen wrote:
> On Sat, 2008-11-22 at 00:18 -0300, Thomas M Steenholdt wrote:
> 
>> Why not simply provide the default fontconfig package, with the ability 
>> to load fonts from say "/usr/local/share/fonts" ?
>>
>> People with this kind of need could simple become root and copy their 
>> fonts into that directory and be done with it...
>>
>> Why not?
>>
> 
> Because it is even easier to just copy the font to ~/.fonts. No need to
> become root. If you want a graphical way to do this, install
> nautilus-actions, and look at http://www.grumz.net/?q=node/334
> 
> 
> Matthias
> 

I know there's been mention of graphical tools, but that's not what I'm 
suggesting here.

What I'm suggesting is a system-wide equivalent of ~/.fonts.

/Thomas



From bashton at brennanashton.com  Sat Nov 22 05:07:14 2008
From: bashton at brennanashton.com (Brennan Ashton)
Date: Fri, 21 Nov 2008 21:07:14 -0800
Subject: What do we need from Bugzilla? (was: My roadmap for a better
	Fedora)
In-Reply-To: <49274B84.7080509@gmail.com>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<11giv5xecm.ln2@ppp1053.in.ipex.cz>
	<20081121112543.GB15943@orient.maison.lan>
	<4926C024.7050303@gmail.com>
	<20081121144620.GA16263@orient.maison.lan> <49270CEE.70000@gmail.com>
	<20081121203639.GA17197@orient.maison.lan>
	<49271FE7.3070309@gmail.com> <f6rjv5x04d.ln2@ppp1053.in.ipex.cz>
	<49274B84.7080509@gmail.com>
Message-ID: <981da310811212107h3dd99282l9151b3a6ddd342b3@mail.gmail.com>

On Fri, Nov 21, 2008 at 4:00 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Matej Cepl wrote:
>>
>> On 2008-11-21, 20:53 GMT, Les Mikesell wrote:
>>>
>>> That's something that less specialized volunteers could do.
>>
>> Yes, but there is severe lack of them -- it is not that sexy as hacking on
>> kernel, I suppose.
>
> If it were as easy as moderating a mailman list there might be more takers.
>  What's the current workflow and where have you requested volunteer help?

Where we are really in need of more volunteers is in BugTriage,
especially after the start of the new year.  What people need to do to
help is documented on the BugZappers section of the wiki
https://fedoraproject.org/wiki/BugZappers  while I would much rather
then hacking away on the kernel as I did for a while on a different
project, this is in some ways just as important.

--Brennan Ashton



From pmatilai at laiskiainen.org  Sat Nov 22 07:37:12 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Sat, 22 Nov 2008 09:37:12 +0200 (EET)
Subject: requires(post) on coreutils
In-Reply-To: <1227211518.28543.659.camel@luminos.localdomain>
References: <1227159559.28543.644.camel@luminos.localdomain>
	<1227201959.13169.40.camel@aglarond.local>
	<4925B087.6000501@redhat.com>
	<faa16b610811201056p565b8488q6214731bba98c61b@mail.gmail.com>
	<4925B683.2000404@redhat.com>
	<faa16b610811201119o14f0268x441c6c96f6230200@mail.gmail.com>
	<1227209685.28543.653.camel@luminos.localdomain>
	<faa16b610811201149r67bff80q3f8115329483f894@mail.gmail.com>
	<1227211518.28543.659.camel@luminos.localdomain>
Message-ID: <alpine.LFD.2.00.0811220838350.20903@turre.koti.laiskiainen.org>

On Thu, 20 Nov 2008, Jesse Keating wrote:

> On Thu, 2008-11-20 at 14:49 -0500, Colin Walters wrote:
>>
>> But there's clearly a default, which is shell script.  And in
>> particular bash.  In any case do we really want to encourage people
>> writing their %post scripts in lua or whatever random language they
>> like?  I don't think we do.  That will fragment the community of
>> people who can modify a package.
>
> Actually yes, lua would be a good forced default, since rpm contains an
> internal lua interpreter and would need no external deps to process the
> script.  Of course, regardless of what /language/ the script is written
> in, the script could call upon things that are both "core os" utilities,
> as well as "applications".

Yup... and with internal Lua, the need for those core os utilities is much 
reduced as you can do lots of things directly from Lua, without forking a 
single extra process. This is particularly useful for things that happen 
very early in the transaction where a shell might not be even installed 
yet. Another, perhaps not so obvious advantage of Lua scriptlets is that 
syntax errors are caught at build time.

Lua in rpm has been pretty much undocumented and as such largely 
misunderstood and dismissed with "well I'm not interested in some oddball 
niche programming language." It's not about Lua the language, it's about 
the possibilities that having a fairly powerful programming language 
embedded in rpm opens up, things that would be completely impossible 
otherwise. Beginnings of documentation can be now found here: 
http://rpm.org/wiki/PackagerDocs/RpmLua

Enough Lua rant for this morning,

 	- Panu -



From a.badger at gmail.com  Sat Nov 22 08:03:33 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sat, 22 Nov 2008 00:03:33 -0800
Subject: Python-config no help
In-Reply-To: <6a28481b0811211501m2eb00a93j149a2d173410a604@mail.gmail.com>
References: <6a28481b0811211501m2eb00a93j149a2d173410a604@mail.gmail.com>
Message-ID: <4927BCD5.5010109@gmail.com>

Oscar Victorio Calixto Bacho wrote:
> Hi Guys
> 
> One python newby question
> 
> why /usr/bin/python-config --help say this
> 
> Traceback (most recent call last):
>   File "/usr/bin/python2.5-config", line 26, in <module>
>     pyver = sysconfig.get_config_var('VERSION')
>   File "/usr/lib/python2.5/distutils/sysconfig.py", line 535, in
> get_config_var
>     return get_config_vars().get(name)
>   File "/usr/lib/python2.5/distutils/sysconfig.py", line 493, in
> get_config_vars
>     func()
>   File "/usr/lib/python2.5/distutils/sysconfig.py", line 352, in _init_posix
>     raise DistutilsPlatformError(my_msg)
> distutils.errors.DistutilsPlatformError: invalid Python installation:
> unable to open /usr/lib/python2.5/config/Makefile (No such file or
> directory)
> 
> This is correct
> 
You need to
yum -y install python-devel

Unless upstream python fixes:
  http://bugs.python.org/issue4359

-Toshi

-------------- 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/20081122/e186d544/attachment.sig>

From nicolas.mailhot at laposte.net  Sat Nov 22 08:55:40 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 22 Nov 2008 09:55:40 +0100
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
In-Reply-To: <981da310811212107h3dd99282l9151b3a6ddd342b3@mail.gmail.com>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<11giv5xecm.ln2@ppp1053.in.ipex.cz>
	<20081121112543.GB15943@orient.maison.lan> <4926C024.7050303@gmail.com>
	<20081121144620.GA16263@orient.maison.lan> <49270CEE.70000@gmail.com>
	<20081121203639.GA17197@orient.maison.lan> <49271FE7.3070309@gmail.com>
	<f6rjv5x04d.ln2@ppp1053.in.ipex.cz> <49274B84.7080509@gmail.com>
	<981da310811212107h3dd99282l9151b3a6ddd342b3@mail.gmail.com>
Message-ID: <1227344140.4773.1.camel@arekh.okg>


What this all tells me is that the requests for a newbie-friendly
bugzilla fa?ade are low prio and people hacking in bugzilla or
replacements should focus on triager needs.

-- 
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/20081122/269ceaa0/attachment.sig>

From nicolas.mailhot at laposte.net  Sat Nov 22 08:57:25 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 22 Nov 2008 09:57:25 +0100
Subject: where's the wish list for F11?
In-Reply-To: <gg7tnl$481$1@ger.gmane.org>
References: <gg4dm5$ts1$1@ger.gmane.org>
	<alpine.LFD.2.00.0811201455510.16994@localhost.localdomain>
	<gg554h$6mi$1@ger.gmane.org>	<20081121094044.GA24555@mokona.greysector.net>
	<1227263653.9545.18.camel@arekh.okg>
	<20081121112829.GC24555@mokona.greysector.net>
	<1227270285.9545.27.camel@arekh.okg> <gg6ifb$490$1@ger.gmane.org>
	<1227284001.13179.14.camel@arekh.okg>  <gg7tnl$481$1@ger.gmane.org>
Message-ID: <1227344245.4773.2.camel@arekh.okg>

Le samedi 22 novembre 2008 ? 00:18 -0300, Thomas M Steenholdt a ?crit :

> I don't make RPMS for every wallpaper I download and intend to use on my 
> machine. And in my world, fonts are not too different in that respect.

Please look at what our font packages actually do before stating this.

-- 
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/20081122/1d9eb4d9/attachment.sig>

From pbrobinson at gmail.com  Sat Nov 22 10:32:08 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Sat, 22 Nov 2008 10:32:08 +0000
Subject: problems updating glibc
In-Reply-To: <20081121204323.GB16492@shell.devel.redhat.com>
References: <5256d0b0811210527k2fcf1c46k2997c358cb1a3e07@mail.gmail.com>
	<200811210817.43276.dennis@ausil.us>
	<20081121204323.GB16492@shell.devel.redhat.com>
Message-ID: <5256d0b0811220232s53822215x89f160b898c6f16e@mail.gmail.com>

On Fri, Nov 21, 2008 at 8:43 PM, Alan Cox <alan at redhat.com> wrote:
> On Fri, Nov 21, 2008 at 08:13:28AM -0600, Dennis Gilmore wrote:
>> a geode is not i686 compatiable,  it is a i586 cpu + cmov it really needs its
>
> That depends which geode. The GX varies from 486 to 686-ish and the NX is
> basically an Athlon

Where does the LX fit into this?

http://www.fit-pc.com/new/fit-pc-1-0-specifications.html
http://wiki.laptop.org/go/Hardware_specification



From tmus at tmus.dk  Sat Nov 22 12:02:36 2008
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Sat, 22 Nov 2008 09:02:36 -0300
Subject: where's the wish list for F11?
In-Reply-To: <1227344245.4773.2.camel@arekh.okg>
References: <gg4dm5$ts1$1@ger.gmane.org>	<alpine.LFD.2.00.0811201455510.16994@localhost.localdomain>	<gg554h$6mi$1@ger.gmane.org>	<20081121094044.GA24555@mokona.greysector.net>	<1227263653.9545.18.camel@arekh.okg>	<20081121112829.GC24555@mokona.greysector.net>	<1227270285.9545.27.camel@arekh.okg>
	<gg6ifb$490$1@ger.gmane.org>	<1227284001.13179.14.camel@arekh.okg>
	<gg7tnl$481$1@ger.gmane.org> <1227344245.4773.2.camel@arekh.okg>
Message-ID: <gg8sdn$v1k$1@ger.gmane.org>

Nicolas Mailhot wrote:
> Le samedi 22 novembre 2008 ? 00:18 -0300, Thomas M Steenholdt a ?crit :
> 
>> I don't make RPMS for every wallpaper I download and intend to use on my 
>> machine. And in my world, fonts are not too different in that respect.
> 
> Please look at what our font packages actually do before stating this.
> 
> 
This is an oppinion, not an attempt to document current behaviour.

/Thomas



From rc040203 at freenet.de  Sat Nov 22 12:14:33 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sat, 22 Nov 2008 13:14:33 +0100
Subject: My roadmap for a better Fedora
In-Reply-To: <20081122003831.GN2961@nb.net.home>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<20081122003831.GN2961@nb.net.home>
Message-ID: <1227356073.5833.12.camel@beck.corsepiu.local>

On Sat, 2008-11-22 at 01:38 +0100, Karel Zak wrote:
> On Wed, Nov 19, 2008 at 12:38:26PM -0600, Callum Lerwick wrote:
> > Problem: We need more and wider testing. Why don't we get more testing?
>
>  .. because this work is not attractive. It's boring work without
>  proper credit in open source community.
Right. Furthermore, testing implies finding bugs, discussing, struggling
and arguing with package maintainers and upstreams. Not necessarily a
way to make friends :)

However, I think the primary cause in is Fedora's work-flow and Fedora's
infrastructure. I find them not to be really helpful to such endeavors.

Ralf





From rc040203 at freenet.de  Sat Nov 22 12:21:11 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sat, 22 Nov 2008 13:21:11 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <49258DA7.5050808@gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<20081120145328.GB2410@yoda.jdub.homelinux.org>
	<20081120145628.GB28357@nostromo.devel.redhat.com>
	<1227193973.3752.858.camel@beck.corsepiu.local>
	<1227194392.4076.31.camel@hughsie-laptop> <49258DA7.5050808@gmail.com>
Message-ID: <1227356472.5833.18.camel@beck.corsepiu.local>

On Thu, 2008-11-20 at 08:17 -0800, Toshio Kuratomi wrote:
> Richard Hughes wrote:
> > On Thu, 2008-11-20 at 16:12 +0100, Ralf Corsepius wrote:
> >> On Thu, 2008-11-20 at 09:56 -0500, Bill Nottingham wrote:
> >>> Josh Boyer (jwboyer at gmail.com) said: 
> >>>>> It would also be a good idea to have a few "shining examples" for people
> >>>>> to copy when creating new packages. When we've done that, I'll start
> >>>>> filing bugs.
> >>>> Just file bugs for packages you think are overly verbose.  Offer
> >>>> alternate summaries in the bug, and a URL to your email for
> >>>> rationale.
> >>> I'm not sure this scales across 5000 packages. So it would be good
> >>> to have at least *something* in the guidelines.
> >> Well, the FPG is intentionally lax on %summary's, because we had wanted
> >> to avoid getting lot in endless discussions on something which is
> >> technically widely meaningness.
> > 
> > Right, but maybe we could have a soft guideline such as:
> > 
> > * Summary should aim to be less than 8 words
> > 
> I generally dislike soft guidelines.  Instead of the Packaging Committee
> making a controversial decisions that contributors argue about, it
> becomes the individual reviewers and packagers arguing about it on many
> separate bugs....
Correct.

> Which is not to say that I wouldn't vote for such a thing, just that I
> usually ask:
> 1) Why can this not be a hard guideline?  (In this case, because it's
> something that's better left to the packager).
Because %summary's are technically irrelevant. 

It's free form one-liner text - Not more, not less.

> 2) Why should this be part of the review guidelines, then?  (So one GUI
> tool can better support its interface).
Any GUI tools must take %summary's as what they are: A one-liner string.

Any GUI tool treating it as something else is simply overinterpreting 
%summary.

Ralf




From hughsient at gmail.com  Sat Nov 22 14:31:24 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Sat, 22 Nov 2008 14:31:24 +0000
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081121194906.GA17123@orient.maison.lan>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<20081121194906.GA17123@orient.maison.lan>
Message-ID: <1227364284.3167.28.camel@hughsie-laptop>

On Fri, 2008-11-21 at 20:49 +0100, Emmanuel Seyman wrote:
> Out of curiosity, how much is "Many"?

At the moment, one. But to a user this "framework" shows up in lots of
different places. For instance in F10 it'll show:

* Add remove programs
* Update viewer
* Log viewer
* Progress window
* Service pack creator

And in F11:

* When installing fonts for new languages
* When a program is required to open a mimetype
* When installing development files in anjunta
* When installing dictionaries in abiword

So it's not just a case of it being shown prominently in "one"
application at all.

Richard.




From rawhide at fedoraproject.org  Sat Nov 22 14:49:50 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sat, 22 Nov 2008 14:49:50 +0000 (UTC)
Subject: rawhide report: 20081122 changes
Message-ID: <20081122144951.265941F825C@releng2.fedora.phx.redhat.com>

Compose started at Sat Nov 22 06:01:10 UTC 2008

Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 0














From sgrubb at redhat.com  Sat Nov 22 15:29:57 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Sat, 22 Nov 2008 10:29:57 -0500
Subject: source file audit - 2008-11-14
In-Reply-To: <20081119170909.29694973@ohm.scrye.com>
References: <20081119170909.29694973@ohm.scrye.com>
Message-ID: <200811221029.57423.sgrubb@redhat.com>

On Wednesday 19 November 2008 19:09:09 Kevin Fenzi wrote:
> sgrubb:BADURL:prewikka-0.9.14.tar.gz:prewikka

Fixed in cvs. Upstream reorganized the web site.

-Steve



From fedora at leemhuis.info  Sat Nov 22 16:34:41 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sat, 22 Nov 2008 17:34:41 +0100
Subject: Hint regarding the "Requesting your help fixing up some package
 summaries" mails
In-Reply-To: <1227282194.3359.83.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
Message-ID: <492834A1.7070506@leemhuis.info>

On 21.11.2008 16:43, Richard Hughes wrote:
> On Thu, 2008-11-20 at 14:33 +0000, Richard Hughes wrote:
>> The packaging guidelines have a single sentence on package
>> summaries: 
>> https://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description
>>  "The summary should be a short and concise description of the
>> package"
> Sorry to keep going on about this,  but this is the contents of the 
> email I'm about to send to ~50 package maintainers.

To all those that got that mail: if you want to know which of you
packages have problems check the headers of the mails you got. You'll 
find something like this:

> [...] Received: by qw-out-2122.google.com with SMTP id
> 3so259690qwe.47 for <rss2email-owner at fedoraproject.org>; Sat, 22 Nov
> 2008 07:43:09 -0800 (PST)
> [...]

E.g. in this case it was rss2email that needs work.

@Richard, do you really expect that those people with more than (say) 5 
packages check all those 419 lines in the files you attached to look 
which of their packages need to be changed (reminder: some people own 
even more than 200 packages iirc)?

Cu
knurd




From hughsient at gmail.com  Sat Nov 22 16:43:24 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Sat, 22 Nov 2008 16:43:24 +0000
Subject: Hint regarding the "Requesting your help fixing up some
 package summaries" mails
In-Reply-To: <492834A1.7070506@leemhuis.info>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<492834A1.7070506@leemhuis.info>
Message-ID: <1227372204.3167.177.camel@hughsie-laptop>

On Sat, 2008-11-22 at 17:34 +0100, Thorsten Leemhuis wrote:
> E.g. in this case it was rss2email that needs work.
> 
> @Richard, do you really expect that those people with more than (say)
> 5 
> packages check all those 419 lines in the files you attached to look 
> which of their packages need to be changed (reminder: some people own 
> even more than 200 packages iirc)?

No, I didn't think of this case, apologies. I'll send an email following
up from the original with a mapping from FAS usernames to packages.

Thanks,

Richard.




From zaitcev at redhat.com  Sat Nov 22 17:35:52 2008
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Sat, 22 Nov 2008 10:35:52 -0700
Subject: "nousb" poll
Message-ID: <20081122103552.86a26420.zaitcev@redhat.com>

Hi, Everyone:

Kernel upstream again had some build issues related to the "nousb"
parameter (it's being switched to core_param() API now). This got me
wondering if it's still useful now that we have kernels unified for
installation and normal work. It was introduced initially to work
around the issues with the crippled i386 kernel. So, the question:
does anyone still use "nousb"? If yes, please let me know. Maybe
I can just fix something in ACPI table parsing for you. My goal is
to drop "nousb" in Fedora 11.

Yours,
-- Pete



From lesmikesell at gmail.com  Sat Nov 22 17:46:47 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 22 Nov 2008 11:46:47 -0600
Subject: My roadmap for a better Fedora
In-Reply-To: <1227356073.5833.12.camel@beck.corsepiu.local>
References: <1227119906.7387.138.camel@localhost.localdomain>	<20081122003831.GN2961@nb.net.home>
	<1227356073.5833.12.camel@beck.corsepiu.local>
Message-ID: <49284587.3000100@gmail.com>

Ralf Corsepius wrote:
> On Sat, 2008-11-22 at 01:38 +0100, Karel Zak wrote:
>> On Wed, Nov 19, 2008 at 12:38:26PM -0600, Callum Lerwick wrote:
>>> Problem: We need more and wider testing. Why don't we get more testing?
>>  .. because this work is not attractive. It's boring work without
>>  proper credit in open source community.
> Right. Furthermore, testing implies finding bugs, discussing, struggling
> and arguing with package maintainers and upstreams. Not necessarily a
> way to make friends :)
> 
> However, I think the primary cause in is Fedora's work-flow and Fedora's
> infrastructure. I find them not to be really helpful to such endeavors.

I do think Windows has improved a lot since they added the crash 
reporter.  OS X has one - and I though Ubuntu included one too although 
I haven't seen anything trip it.

-- 
   Les Mikesell
     lesmikesell at gmail.com




From rc040203 at freenet.de  Sat Nov 22 17:52:30 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sat, 22 Nov 2008 18:52:30 +0100
Subject: "nousb" poll
In-Reply-To: <20081122103552.86a26420.zaitcev@redhat.com>
References: <20081122103552.86a26420.zaitcev@redhat.com>
Message-ID: <1227376350.5833.30.camel@beck.corsepiu.local>

On Sat, 2008-11-22 at 10:35 -0700, Pete Zaitcev wrote:
> Hi, Everyone:
> 
> Kernel upstream again had some build issues related to the "nousb"
> parameter (it's being switched to core_param() API now). This got me
> wondering if it's still useful now that we have kernels unified for
> installation and normal work. It was introduced initially to work
> around the issues with the crippled i386 kernel. So, the question:
> does anyone still use "nousb"? If yes, please let me know.
Yes, I am.

Typically on older machines,
* which don't have USB.
* on which USB is too uneffective to be useful (e.g. only have USB-1.x)
* on which USB is not supposed to be used.

>  Maybe
> I can just fix something in ACPI table parsing for you. My goal is
> to drop "nousb" in Fedora 11.

<sigh/> another nail in Fedora's coffin on low end platforms?

Ralf




From christoph.wickert at googlemail.com  Sat Nov 22 17:56:59 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Sat, 22 Nov 2008 18:56:59 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227191607.4076.29.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
Message-ID: <1227376619.3852.76.camel@wicktop.localdomain>

Am Donnerstag, den 20.11.2008, 14:33 +0000 schrieb Richard Hughes:
> The packaging guidelines have a single sentence on package summaries:
> https://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description
> 
> "The summary should be a short and concise description of the package"
> 
> Broken packages are a problem as PackageKit shows the summary first (in
> bold) in preference to the package name. This is by design.

And IMO this is wrong by design. Why?
     1. Because packages are still sorted by name and not by
        description. This makes it very hard to find something.
     2. Because in most package managers (at least their GUIs) only
        allow to search for name and not for summary.

> Quite a lot of packages have summary text that is overly verbose, and
> this makes the GUI and output from pkcon look rubbish.

+1, so I agree with Michael and Toshio that we should care about the
"foo is a ..." or "is the ..." descriptions first. This will help us to
save space without removing any information. IMO "is a" in summary
should be strictly forbidden by a "hard" guideline.

> For instance, I've filed
> https://bugzilla.redhat.com/show_bug.cgi?id=472365 where the oggconvert
> package has a summary of:
> 
> "A simple GNOME application that converts media files to Free formats"
> 
> First, we don't need to say it's an application, not that it's GNOME
> specific. Surely something like this would be better:
> 
> "Simple media converter"
> or
> "Simple conversion to free media formats"
> or
> "Simple media converter using free formats"

OK, but as others already pointed out we have a couple of "simple media
converters" then and the user will have to read the description to get
an idea of the differences between them.

Today you mailed me because Thunar (which I'm not owning but only
co-maintaining) has the following summary:
        Thunar File Manager
So if we remove thunar, nautilus, pcmanfm, ... only "file manager"
remains and I have no idea how to improve this summary.
      * "File manager for the Xfce desktop environment"? Not really,
        because it's not Xfce specific.
      * "Lightweight File Manager"? No, pcmanfm is even more lightweight
      * "GTK based File Manager"? We have at least 5 GTK based file
        managers

The three file managers are very similar in design and function, so to
me it's almost logical that the descriptions are too. Can you tell me
what to improve in this case?

> The guidelines also don't say if it should be Title Case or if the
> summary should include the application name. 

So your are suggesting to forbid the name in summary? Back in those
pirut days I would have agreed to you, but now with PackageKit I'm not
sure if I can still subscribe to your POV. Example:

      * abiword 	The AbiWord word processor

We have a couple of word processors and having the application's name in
the description helps to distinguish between them. What is so bad in
having descriptions like "The exim mail transfer agent", "The postfix
mail transfer agent" and "The sendmail mail transfer agent"?

Also your "simple hacky tool" produces a lot of false positives:
      * acpi	Command-line ACPI client (try to remove ACPI from summary)
      * barcode	generates barcodes from text strings
      * ccid	Generic USB CCID smart card reader driver
      * contacts	Contacts addressbook
      * dialog	A utility for creating TTY dialog boxes
The problem with these packages it not the summary but the generic name
of the package. This is something we cannot change.

More examples of false positives:
      * asylum	SDL port of the game Asylum, originally for the
        Archimedes (try to remove the name here: A port of what?)
      * audit	User space tools for 2.6 kernel auditing
      * calc	Arbitrary precision arithmetic system and calculator
      * dia	Diagram drawing program
      * ed	The GNU line editor
      * eject	A program that ejects removable media using software
        control.

I'm not criticizing your script, I just want to point out that it's not
as many packages as you might think and for others there is nothing we
can do about it.

> If we come to some
> guidelines (or working practices) on this email thread, I'll update the
> wiki page with more details.

OK, so as a start let's forbid "... is a ...". Furthermore as Ignacio
and Toshio pointed out we should get rid of verb phrases. Verb phrases
are ok for descriptions (both in spec and in desktop files) but for
summary we should use nouns. 

> It would also be a good idea to have a few "shining examples" for people
> to copy when creating new packages. When we've done that, I'll start
> filing bugs.
> 
> Thanks,
> 
> Richard.

Regards,
Christoph



From rc040203 at freenet.de  Sat Nov 22 18:02:08 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sat, 22 Nov 2008 19:02:08 +0100
Subject: My roadmap for a better Fedora
In-Reply-To: <49284587.3000100@gmail.com>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<20081122003831.GN2961@nb.net.home>
	<1227356073.5833.12.camel@beck.corsepiu.local>
	<49284587.3000100@gmail.com>
Message-ID: <1227376928.5833.35.camel@beck.corsepiu.local>

On Sat, 2008-11-22 at 11:46 -0600, Les Mikesell wrote:
> Ralf Corsepius wrote:
> > On Sat, 2008-11-22 at 01:38 +0100, Karel Zak wrote:
> >> On Wed, Nov 19, 2008 at 12:38:26PM -0600, Callum Lerwick wrote:
> >>> Problem: We need more and wider testing. Why don't we get more testing?
> >>  .. because this work is not attractive. It's boring work without
> >>  proper credit in open source community.
> > Right. Furthermore, testing implies finding bugs, discussing, struggling
> > and arguing with package maintainers and upstreams. Not necessarily a
> > way to make friends :)
> > 
> > However, I think the primary cause in is Fedora's work-flow and Fedora's
> > infrastructure. I find them not to be really helpful to such endeavors.
> 
> I do think Windows has improved a lot since they added the crash 
> reporter.  OS X has one 

These are closed source OSes - They don't have any alternative but such
"user participation programs" - OSS has alternatives.

> - and I though Ubuntu included one too although 
> I haven't seen anything trip it.
Gnome had one for many years (bug-buddy), ... I don't recall having seen
it providing any substantial improvement to Gnome.

Now the kernel also has one (kerneloops) ... We'll see if it will
provide improvements.

My expectations on such tools are very low. Many users switch them off
and developers/maintainers tend to ignore them as noise.

Ralf




From lesmikesell at gmail.com  Sat Nov 22 18:28:54 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 22 Nov 2008 12:28:54 -0600
Subject: My roadmap for a better Fedora
In-Reply-To: <1227376928.5833.35.camel@beck.corsepiu.local>
References: <1227119906.7387.138.camel@localhost.localdomain>	<20081122003831.GN2961@nb.net.home>	<1227356073.5833.12.camel@beck.corsepiu.local>	<49284587.3000100@gmail.com>
	<1227376928.5833.35.camel@beck.corsepiu.local>
Message-ID: <49284F66.4080009@gmail.com>

Ralf Corsepius wrote:

>>>>> Problem: We need more and wider testing. Why don't we get more testing?
>>>>  .. because this work is not attractive. It's boring work without
>>>>  proper credit in open source community.
>>> Right. Furthermore, testing implies finding bugs, discussing, struggling
>>> and arguing with package maintainers and upstreams. Not necessarily a
>>> way to make friends :)
>>>
>>> However, I think the primary cause in is Fedora's work-flow and Fedora's
>>> infrastructure. I find them not to be really helpful to such endeavors.
>> I do think Windows has improved a lot since they added the crash 
>> reporter.  OS X has one 
> 
> These are closed source OSes - They don't have any alternative but such
> "user participation programs" - OSS has alternatives.

Beg your pardon, but having the option (requirement?) to fix broken 
stuff myself has never been all that appealing to me as an aspect of 
open source.  I look to it more for the benefits of re-using code that 
is already well tested.  Of course that doesn't work out all that well 
in a project that keeps changing things...

>> - and I though Ubuntu included one too although 
>> I haven't seen anything trip it.
> Gnome had one for many years (bug-buddy), ... I don't recall having seen
> it providing any substantial improvement to Gnome.
> 
> Now the kernel also has one (kerneloops) ... We'll see if it will
> provide improvements.

How does that work?  I'd think a dead kernel or one that doesn't boot 
would have a hard time reporting it's problems.

> My expectations on such tools are very low. Many users switch them off
> and developers/maintainers tend to ignore them as noise.

If the developers ignore the information, then at least they should stop 
blaming the lack of testers for the lingering bugs.

-- 
    Les Mikesell
     lesmikesell at gmail.com



From emmanuel.seyman at club-internet.fr  Sat Nov 22 18:33:29 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Sat, 22 Nov 2008 19:33:29 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227364284.3167.28.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<20081121194906.GA17123@orient.maison.lan>
	<1227364284.3167.28.camel@hughsie-laptop>
Message-ID: <20081122183329.GA23447@orient.maison.lan>

* Richard Hughes [22/11/2008 15:38] :
>
> On Fri, 2008-11-21 at 20:49 +0100, Emmanuel Seyman wrote:
>
> > Out of curiosity, how much is "Many"?
> 
> At the moment, one.

FWIW, I don't appreciate our maintainers being lied to. The vast
majority of them work hard to make their packages and I believe that a
minimum of respect should be shown.

> So it's not just a case of it being shown prominently in "one"
> application at all.

But it is a case of changing one application versus changing 500.

Emmanuel



From mail at robertoragusa.it  Sat Nov 22 18:42:27 2008
From: mail at robertoragusa.it (Roberto Ragusa)
Date: Sat, 22 Nov 2008 19:42:27 +0100
Subject: where's the wish list for F11?
In-Reply-To: <gg7tnl$481$1@ger.gmane.org>
References: <gg4dm5$ts1$1@ger.gmane.org>	<alpine.LFD.2.00.0811201455510.16994@localhost.localdomain>	<gg554h$6mi$1@ger.gmane.org>	<20081121094044.GA24555@mokona.greysector.net>	<1227263653.9545.18.camel@arekh.okg>	<20081121112829.GC24555@mokona.greysector.net>	<1227270285.9545.27.camel@arekh.okg>	<gg6ifb$490$1@ger.gmane.org>
	<1227284001.13179.14.camel@arekh.okg> <gg7tnl$481$1@ger.gmane.org>
Message-ID: <49285293.4060305@robertoragusa.it>

Thomas M Steenholdt wrote:

> Why not simply provide the default fontconfig package, with the ability
> to load fonts from say "/usr/local/share/fonts" ?
> 

Good idea.
This is exactly what I've done to add some unpackaged fonts
to my system.
A comment in /etc/fonts/fonts.conf says you should have local
modifications in /etc/fonts/local.conf.

This is the content of my local.conf:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <dir>/usr/local/share/fonts</dir>
</fontconfig>

Best regards.
-- 
   Roberto Ragusa    mail at robertoragusa.it



From schaiba at gmail.com  Sat Nov 22 18:42:31 2008
From: schaiba at gmail.com (Aioanei Rares)
Date: Sat, 22 Nov 2008 20:42:31 +0200
Subject: My roadmap for a better Fedora
In-Reply-To: <49284F66.4080009@gmail.com>
References: <1227119906.7387.138.camel@localhost.localdomain>	<20081122003831.GN2961@nb.net.home>	<1227356073.5833.12.camel@beck.corsepiu.local>	<49284587.3000100@gmail.com>	<1227376928.5833.35.camel@beck.corsepiu.local>
	<49284F66.4080009@gmail.com>
Message-ID: <49285297.2050406@gmail.com>

Les Mikesell wrote:
> Ralf Corsepius wrote:
>
>>>>>> Problem: We need more and wider testing. Why don't we get more 
>>>>>> testing?
>>>>>  .. because this work is not attractive. It's boring work without
>>>>>  proper credit in open source community.
>>>> Right. Furthermore, testing implies finding bugs, discussing, 
>>>> struggling
>>>> and arguing with package maintainers and upstreams. Not necessarily a
>>>> way to make friends :)
>>>>
>>>> However, I think the primary cause in is Fedora's work-flow and 
>>>> Fedora's
>>>> infrastructure. I find them not to be really helpful to such 
>>>> endeavors.
>>> I do think Windows has improved a lot since they added the crash 
>>> reporter.  OS X has one 
>>
>> These are closed source OSes - They don't have any alternative but such
>> "user participation programs" - OSS has alternatives.
>
> Beg your pardon, but having the option (requirement?) to fix broken 
> stuff myself has never been all that appealing to me as an aspect of 
> open source.  I look to it more for the benefits of re-using code that 
> is already well tested.  Of course that doesn't work out all that well 
> in a project that keeps changing things...
>
>>> - and I though Ubuntu included one too although I haven't seen 
>>> anything trip it.
>> Gnome had one for many years (bug-buddy), ... I don't recall having seen
>> it providing any substantial improvement to Gnome.
>>
>> Now the kernel also has one (kerneloops) ... We'll see if it will
>> provide improvements.
>
> How does that work?  I'd think a dead kernel or one that doesn't boot 
> would have a hard time reporting it's problems.
>
A kernel oops is not a crash and it doesn't render the kernel 
unbootable. See http://en.wikipedia.org/wiki/Linux_kernel_oops .
>> My expectations on such tools are very low. Many users switch them off
>> and developers/maintainers tend to ignore them as noise.
>
> If the developers ignore the information, then at least they should 
> stop blaming the lack of testers for the lingering bugs.
>



From alan at redhat.com  Sat Nov 22 19:34:23 2008
From: alan at redhat.com (Alan Cox)
Date: Sat, 22 Nov 2008 14:34:23 -0500
Subject: "nousb" poll
In-Reply-To: <1227376350.5833.30.camel@beck.corsepiu.local>
References: <20081122103552.86a26420.zaitcev@redhat.com>
	<1227376350.5833.30.camel@beck.corsepiu.local>
Message-ID: <20081122193423.GA11208@shell.devel.redhat.com>

On Sat, Nov 22, 2008 at 06:52:30PM +0100, Ralf Corsepius wrote:
> On Sat, 2008-11-22 at 10:35 -0700, Pete Zaitcev wrote:
> > Hi, Everyone:
> > 
> > Kernel upstream again had some build issues related to the "nousb"
> > parameter (it's being switched to core_param() API now). This got me
> > wondering if it's still useful now that we have kernels unified for
> > installation and normal work. It was introduced initially to work
> > around the issues with the crippled i386 kernel. So, the question:
> > does anyone still use "nousb"? If yes, please let me know.
> Yes, I am.

And me - on boxes with buggy BIOS SMM.

> > I can just fix something in ACPI table parsing for you. My goal is
> > to drop "nousb" in Fedora 11.
> 
> <sigh/> another nail in Fedora's coffin on low end platforms?

And some high end ones where you need a BIOS upgrade and it isn't ACPI
failures.

My low end ones are all fine with USB ;)



From zaitcev at redhat.com  Sat Nov 22 19:47:35 2008
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Sat, 22 Nov 2008 12:47:35 -0700
Subject: "nousb" poll
In-Reply-To: <20081122193423.GA11208@shell.devel.redhat.com>
References: <20081122103552.86a26420.zaitcev@redhat.com>
	<1227376350.5833.30.camel@beck.corsepiu.local>
	<20081122193423.GA11208@shell.devel.redhat.com>
Message-ID: <20081122124735.79095ca8.zaitcev@redhat.com>

On Sat, 22 Nov 2008 14:34:23 -0500, Alan Cox <alan at redhat.com> wrote:

> And me - on boxes with buggy BIOS SMM.

Eww, I forgot about those. BTW, what's the console on them?

-- Pete



From nicolas.mailhot at laposte.net  Sat Nov 22 19:49:15 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 22 Nov 2008 20:49:15 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081122183329.GA23447@orient.maison.lan>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<20081121194906.GA17123@orient.maison.lan>
	<1227364284.3167.28.camel@hughsie-laptop>
	<20081122183329.GA23447@orient.maison.lan>
Message-ID: <1227383355.10434.16.camel@arekh.okg>

Le samedi 22 novembre 2008 ? 19:33 +0100, Emmanuel Seyman a ?crit :
> * Richard Hughes [22/11/2008 15:38] :
> >
> > On Fri, 2008-11-21 at 20:49 +0100, Emmanuel Seyman wrote:
> >
> > > Out of curiosity, how much is "Many"?
> > 
> > At the moment, one.
> 
> FWIW, I don't appreciate our maintainers being lied to. The vast
> majority of them work hard to make their packages and I believe that a
> minimum of respect should be shown.

I believe this is a case of either creating and animating a SIG that
performs *sustained* *human* review of packages summaries and
descriptions, or convincing FPC and FESCO to approve a one-shot action.

There are lots of stuff that could be improved in packages matadata,
(like killing the funny camelcase names), and others did go the hard FPC
route before firing XXX mails.

FPC is also there to moderate the PHB impulses in us.

-- 
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/20081122/e511a326/attachment.sig>

From paul at all-the-johnsons.co.uk  Sat Nov 22 20:50:15 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Sat, 22 Nov 2008 20:50:15 +0000
Subject: Games packaging
Message-ID: <1227387015.21103.425.camel@PB3.Linux>

Hi,

I'm trying to package prboom (a doom port) for inclusion, but it places
the executable in /usr/game. Is this an acceptable place and if it is,
what do I put in files for /usr/game (for example, %{_bindir} goes
to /usr/bin).

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/20081122/40f6addc/attachment.sig>

From cdahlin at redhat.com  Sat Nov 22 21:55:49 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Sat, 22 Nov 2008 16:55:49 -0500
Subject: Games packaging
In-Reply-To: <1227387015.21103.425.camel@PB3.Linux>
References: <1227387015.21103.425.camel@PB3.Linux>
Message-ID: <49287FE5.5040708@redhat.com>

Paul wrote:
> Hi,
>
> I'm trying to package prboom (a doom port) for inclusion, but it places
> the executable in /usr/game. Is this an acceptable place and if it is,
> what do I put in files for /usr/game (for example, %{_bindir} goes
> to /usr/bin).
>
> TTFN
>
> Paul
>   
You should be able to give flags to the build script to make it put the 
executable where it belongs.

--CJD



From mschwendt at gmail.com  Sun Nov 23 00:32:05 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 23 Nov 2008 01:32:05 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227376619.3852.76.camel@wicktop.localdomain>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227376619.3852.76.camel@wicktop.localdomain>
Message-ID: <20081123013205.0ee6c6f7.mschwendt@gmail.com>

On Sat, 22 Nov 2008 18:56:59 +0100, Christoph Wickert wrote:

> [...] Thunar (which I'm not owning but only
> co-maintaining) has the following summary:
>         Thunar File Manager

Forget for a moment that package name and summary are displayed close to
eachother -- or ought to be displayed like that.

Many, *many* people (except for fan-boys and people who are told to search
for a specific brand) don't care at all about the name of a program when
searching for a program. When they see the word "Thunar" it doesn't ring
any bell. Instead, it makes them nervous as they don't know whether it
matters to know what "Thunar". It could also be a special environment
which they don't know and don't want. Adding the program name makes such a
summary (and in turn the package) less attractive to these people. With
the shorter summary "File manager" they are more willing to try out the
software they don't know yet.

[This is similar to the design of desktop menus. Ordinary users would
rather choose a "Web browser" menu item (and newbies even an "Internet"
menu item) than a "Mozilla Firefox Web Browser". Sure, over time they
will learn about the name of the program they use, but that doesn't
make the original system user-friendly.]

[While writing this I remember that I need to look at the current state
of the Fedora desktop file guidelines, because our menus are still a
mess WRT Name/GenericName usage.]

> So if we remove thunar, nautilus, pcmanfm, ... only "file manager"
> remains and I have no idea how to improve this summary.
>       * "File manager for the Xfce desktop environment"? Not really,
>         because it's not Xfce specific.

Not specific, but its FAQ says "... with a special focus on the Xfce
DE". And the first line of the description says:

  Thunar is a new modern file manager for the Xfce Desktop Environment.

>       * "Lightweight File Manager"? No, pcmanfm is even more lightweight
>       * "GTK based File Manager"? We have at least 5 GTK based file
>         managers

IMO, it would be relevant to describe it as "File manager for graphical
desktop environments". Or to mention Xfce: "File manager with special
focus on Xfce".

> The three file managers are very similar in design and function, so to
> me it's almost logical that the descriptions are too. Can you tell me
> what to improve in this case?

Just "File manager" is fine, too.

>       * abiword 	The AbiWord word processor
> 
> We have a couple of word processors and having the application's name in
> the description helps to distinguish between them.

Redundancy, which makes the package summary less clear unless you know
already what "AbiWord" is. As explained above. Acronyms, brand-names and
trademarks make ordinary users nervous. Have you ever met users who would
ask "What is an AbiWord word processor?" while looking for a "normal" word
processor? Or users who know how to surf the Internet in a web browser
that is started automatically, but the "Mozilla Firefox" icon on the
deskop confuses them and they would not click it if they wanted to start a
web browser manually (until they learn and remember the "Mozilla Firefox"
name).

> What is so bad in
> having descriptions like "The exim mail transfer agent", "The postfix
> mail transfer agent" and "The sendmail mail transfer agent"?

It's a matter of perspective. Do you think the branding is so important as
to use it also in the summary? Does it make a package more attractive?
AbiWord is a trademark, for example. Users, who know that name, also know
how to search for it in the Fedora package collection.

  sendmail : A widely used Mail Transport Agent (MTA)

is the current summary for this MTA. Expand your list of examples of "The
%name ..."  summaries. You can do it with all other packages for a bad
precedent and decrease the S/N ratio:

  k3b : The K3b CD/DVD burning application for KDE
  gthumb : The gThumb image viewer, editor, organizer
  audacious : The Audacious GTK2 based media player similar to XMMS
  ...



From tgl at redhat.com  Sun Nov 23 02:53:46 2008
From: tgl at redhat.com (Tom Lane)
Date: Sat, 22 Nov 2008 21:53:46 -0500
Subject: RFC: fix summary text for lots of packages 
In-Reply-To: <20081123013205.0ee6c6f7.mschwendt@gmail.com> 
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227376619.3852.76.camel@wicktop.localdomain>
	<20081123013205.0ee6c6f7.mschwendt@gmail.com>
Message-ID: <19279.1227408826@sss.pgh.pa.us>

[ many people wrote a lot of stuff about this already... ]

I'm generally in favor of publishing some stylistic suggestions for
package Summary-writing.  We already have a "hard guideline" enforced by
rpmlint that summaries not end with periods, so it's hard to see how
anyone could argue with style guidelines that suggest "avoid repeating
the package name in the summary", "use (or not) initial cap", "avoid
filler like 'the' or 'is a'", etc etc.  At the same time this is
ultimately about human language and so I don't like having hard rules
about it.

But to get onto something concrete: there's been no consideration at all
in this thread about what to do with packages that have multiple
sub-RPMs.  I got an auto-gripe from Richard about my packages mysql and
postgresql.  Well, those have main and sub-packages with summaries like so:

mysql: MySQL client programs and shared libraries
mysql-libs: The shared libraries required for MySQL clients
mysql-server: The MySQL server and related files
mysql-cluster: MySQL Cluster daemons and related files
mysql-devel: Files for development of MySQL applications
mysql-embedded: MySQL as an embeddable library
mysql-embedded-devel: Development files for MySQL as an embeddable library
mysql-bench: MySQL benchmark scripts and data
mysql-test: The test suite distributed with MySQL

postgresql: PostgreSQL client programs and libraries
postgresql-libs: The shared libraries required for any PostgreSQL clients
postgresql-server: The programs needed to create and run a PostgreSQL server
postgresql-docs: Extra documentation for PostgreSQL
postgresql-contrib: Contributed source and binaries distributed with PostgreSQL
postgresql-devel: PostgreSQL development header files and libraries
postgresql-plperl: The Perl procedural language for PostgreSQL
postgresql-plpython: The Python procedural language for PostgreSQL
postgresql-pltcl: The Tcl procedural language for PostgreSQL
postgresql-tcl: A Tcl client library for PostgreSQL
postgresql-python: Development module for Python code to access a PostgreSQL DB
postgresql-test: The test suite distributed with PostgreSQL

The "base" package is not (IMHO) the most interesting part of these
packages, and it really can't have a description that implies it brings
in the entire fileset.  I think if someone were to click on a "MySQL"
item in a long list of packages, they'd probably at least be expecting
the equivalent of mysql + mysql-libs + mysql-server to get installed.

You might argue that the problem could be solved by drastically reducing
the number of subpackages, but there are a whole lot of pressures
forcing things in the direction you see here; if you don't want to
savage a bunch of *other* packaging guidelines you won't get far with
that solution.

So there are at least a couple of points here: first, we lack any
infrastructure for identifying a "core" group of subpackages that might
be reasonable to install if the user just clicks on "MySQL", and second,
if we're going to have summary-writing guidelines then they'd better
address how to describe subpackages.  I'm less than convinced that
it would be productive to avoid using "MySQL" in the subpackage
descriptions.

			regards, tom lane



From kevin.kofler at chello.at  Sun Nov 23 04:58:36 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 23 Nov 2008 05:58:36 +0100
Subject: Games packaging
References: <1227387015.21103.425.camel@PB3.Linux>
Message-ID: <ggants$i83$1@ger.gmane.org>

Paul wrote:
> I'm trying to package prboom (a doom port) for inclusion

prboom is already in Fedora!
https://admin.fedoraproject.org/pkgdb/packages/name/prboom

        Kevin Kofler



From a.badger at gmail.com  Sun Nov 23 07:26:31 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sat, 22 Nov 2008 23:26:31 -0800
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <19279.1227408826@sss.pgh.pa.us>
References: <1227191607.4076.29.camel@hughsie-laptop>	<1227376619.3852.76.camel@wicktop.localdomain>	<20081123013205.0ee6c6f7.mschwendt@gmail.com>
	<19279.1227408826@sss.pgh.pa.us>
Message-ID: <492905A7.9030905@gmail.com>

Tom Lane wrote:

Note: these comments also apply to the postgresql packages.
> 
> But to get onto something concrete: there's been no consideration at all
> in this thread about what to do with packages that have multiple
> sub-RPMs.  I got an auto-gripe from Richard about my packages mysql and
> postgresql.  Well, those have main and sub-packages with summaries like so:
> 
> mysql: MySQL client programs and shared libraries

Tangent: this one looks dated.  I see client programs but not shared libs.

> mysql-libs: The shared libraries required for MySQL clients
> mysql-server: The MySQL server and related files

This one could be "Database server" or "Fast database server" or
"Popular database server"... whatever MySQL's claim to fame is.

> mysql-cluster: MySQL Cluster daemons and related files
> mysql-devel: Files for development of MySQL applications
> mysql-embedded: MySQL as an embeddable library
> mysql-embedded-devel: Development files for MySQL as an embeddable library
> mysql-bench: MySQL benchmark scripts and data
> mysql-test: The test suite distributed with MySQL
> 
I agree with you on the core point.  MySQL is a building block on which
these packages depend.  Just like a library of code can justify putting
the language in the name or a gnome-panel applet can justify putting
GNOME in the name, I think subpackages can often justify putting the
name of the base package in the summary.

Looked at from this angle, it seems like the server binary should live
in the base package (as everything is built around an interaction with
the specific database server) and the clients should be in a *-clients
package... but that's probably something that isn't that big a deal
compared to people having gotten used to the current scheme.

> 
> So there are at least a couple of points here: first, we lack any
> infrastructure for identifying a "core" group of subpackages that might
> be reasonable to install if the user just clicks on "MySQL",

This gets us off into comps.xml and metapackages which should allow this
to happen.  That might be a tangent, though.

> and second,
> if we're going to have summary-writing guidelines then they'd better
> address how to describe subpackages.  I'm less than convinced that
> it would be productive to avoid using "MySQL" in the subpackage
> descriptions.

Yeah... I'd like to see best practices that include an example of
subpackages using the base package name and an explanation like:  When a
package is meant to work only with a specific other package, it may be
good to mention it in the summary.  This is often the case with subpackages:

  mysql-libs: Shared libraries required for MySQL clients

The libraries in this package work specifically with MySQL, not any
generic SQL database, so it's appropriate to mention that in the summary.

-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/20081122/e0bb5955/attachment.sig>

From nicolas.mailhot at laposte.net  Sun Nov 23 08:40:20 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 23 Nov 2008 09:40:20 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <19279.1227408826@sss.pgh.pa.us>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227376619.3852.76.camel@wicktop.localdomain>
	<20081123013205.0ee6c6f7.mschwendt@gmail.com>
	<19279.1227408826@sss.pgh.pa.us>
Message-ID: <1227429621.30117.7.camel@arekh.okg>

Le samedi 22 novembre 2008 ? 21:53 -0500, Tom Lane a ?crit :

> So there are at least a couple of points here: first, we lack any
> infrastructure for identifying a "core" group of subpackages that might
> be reasonable to install if the user just clicks on "MySQL",

Of course we have, that's called comps groups and we've even pressured
the PK author to add comps support to his stuff recently.

However while I'm personnaly in favour of creating groups for any set of
closely related packages we can identify (even if they're just a
handful), FPC and FESCO have resisted attempts to get them to look at
our comps files. They've dumped it all on Bill Nottingham and he's of
the "less groups = less anaconda work" camp.

-- 
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/20081123/ae585daf/attachment.sig>

From mcepl at redhat.com  Sun Nov 23 08:43:49 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Sun, 23 Nov 2008 09:43:49 +0100
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>
	<20081121095053.GA15636@orient.maison.lan>
	<11giv5xecm.ln2@ppp1053.in.ipex.cz>
	<20081121112543.GB15943@orient.maison.lan> <4926C024.7050303@gmail.com>
	<20081121144620.GA16263@orient.maison.lan> <49270CEE.70000@gmail.com>
	<20081121203639.GA17197@orient.maison.lan> <49271FE7.3070309@gmail.com>
	<f6rjv5x04d.ln2@ppp1053.in.ipex.cz> <49274B84.7080509@gmail.com>
Message-ID: <5nhnv5xt3b.ln2@ppp1053.in.ipex.cz>

On 2008-11-22, 00:00 GMT, Les Mikesell wrote:
> What's the current workflow and where have you requested 
> volunteer help?

https://fedoraproject.org/wiki/BugZappers and fedora-test list.

Mat?j



From mcepl at redhat.com  Sun Nov 23 08:39:04 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Sun, 23 Nov 2008 09:39:04 +0100
Subject: My roadmap for a better Fedora
References: <1227119906.7387.138.camel@localhost.localdomain>
	<20081122003831.GN2961@nb.net.home>
	<1227356073.5833.12.camel@beck.corsepiu.local>
Message-ID: <8ehnv5xt3b.ln2@ppp1053.in.ipex.cz>

On 2008-11-22, 12:14 GMT, Ralf Corsepius wrote:
> Right. Furthermore, testing implies finding bugs, discussing, 
> struggling and arguing with package maintainers and upstreams.  
> Not necessarily a way to make friends :)

Yeah :)

> However, I think the primary cause in is Fedora's work-flow and Fedora's
> infrastructure. I find them not to be really helpful to such endeavors.

Could you be more specific, please? Any particular suggestions, 
ideas?

Mat?j



From mcepl at redhat.com  Sun Nov 23 08:42:46 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Sun, 23 Nov 2008 09:42:46 +0100
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<c51b944b0811201720y1150997w4b0ddb123e0aac8d@mail.gmail.com>
	<20081121095053.GA15636@orient.maison.lan>
	<11giv5xecm.ln2@ppp1053.in.ipex.cz>
	<20081121112543.GB15943@orient.maison.lan>
	<g2rjv5x04d.ln2@ppp1053.in.ipex.cz>
	<20081122012630.GB27160@angus.ind.WPI.EDU>
Message-ID: <6lhnv5xt3b.ln2@ppp1053.in.ipex.cz>

On 2008-11-22, 01:26 GMT, Chuck Anderson wrote:
> How does one sign up to get all NEW bugs for a certain 
> component?

Create a query and read it via RSS.

But no, that's not what I do. I am cursed by reading ALL bugmails 
regarding some particular components (a lots of them).

And of course, you can follow all emails to the package 
maintainer.

Mat?j



From hughsient at gmail.com  Sun Nov 23 09:15:03 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 23 Nov 2008 09:15:03 +0000
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227383355.10434.16.camel@arekh.okg>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<20081121194906.GA17123@orient.maison.lan>
	<1227364284.3167.28.camel@hughsie-laptop>
	<20081122183329.GA23447@orient.maison.lan>
	<1227383355.10434.16.camel@arekh.okg>
Message-ID: <1227431703.3188.12.camel@hughsie-laptop>

On Sat, 2008-11-22 at 20:49 +0100, Nicolas Mailhot wrote:
> There are lots of stuff that could be improved in packages matadata,
> (like killing the funny camelcase names), and others did go the hard
> FPC route before firing XXX mails.

I just went ahead painted the bike shed. Apologies if this cause
offence.

Richard.




From hughsient at gmail.com  Sun Nov 23 09:17:03 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 23 Nov 2008 09:17:03 +0000
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081122183329.GA23447@orient.maison.lan>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<20081121194906.GA17123@orient.maison.lan>
	<1227364284.3167.28.camel@hughsie-laptop>
	<20081122183329.GA23447@orient.maison.lan>
Message-ID: <1227431823.3188.14.camel@hughsie-laptop>

On Sat, 2008-11-22 at 19:33 +0100, Emmanuel Seyman wrote:
> * Richard Hughes [22/11/2008 15:38] :
> >
> > On Fri, 2008-11-21 at 20:49 +0100, Emmanuel Seyman wrote:
> >
> > > Out of curiosity, how much is "Many"?
> > 
> > At the moment, one.
> 
> FWIW, I don't appreciate our maintainers being lied to.

<snip>

> > So it's not just a case of it being shown prominently in "one"
> > application at all.
> 
> But it is a case of changing one application versus changing 500.

That's not the point. PackageKit isn't going to change to show the name
more prominently than the description. PackageKit _is_ going to be
integrated more places, and the user _is_ going to see PackageKit
dialogs in more places than they see it now.

Richard.




From j.w.r.degoede at hhs.nl  Sun Nov 23 09:29:47 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sun, 23 Nov 2008 10:29:47 +0100
Subject: Games packaging
In-Reply-To: <1227387015.21103.425.camel@PB3.Linux>
References: <1227387015.21103.425.camel@PB3.Linux>
Message-ID: <4929228B.10008@hhs.nl>



Paul wrote:
> Hi,
> 
> I'm trying to package prboom (a doom port) for inclusion, but it places
> the executable in /usr/game. Is this an acceptable place and if it is,
> what do I put in files for /usr/game (for example, %{_bindir} goes
> to /usr/bin).
> 

As already mentioned prboom is already packaged, if you are looking for new
games to package take a look at:
http://fedoraproject.org/wiki/SIGs/Games/WishList

Regards,

Hans



From hughsient at gmail.com  Sun Nov 23 09:26:47 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 23 Nov 2008 09:26:47 +0000
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227376619.3852.76.camel@wicktop.localdomain>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227376619.3852.76.camel@wicktop.localdomain>
Message-ID: <1227432407.3188.23.camel@hughsie-laptop>

On Sat, 2008-11-22 at 18:56 +0100, Christoph Wickert wrote:
> Also your "simple hacky tool" produces a lot of false positives:
>       * acpi    Command-line ACPI client (try to remove ACPI from
> summary)
>       * barcode generates barcodes from text strings
>       * ccid    Generic USB CCID smart card reader driver
>       * contacts        Contacts addressbook
>       * dialog  A utility for creating TTY dialog boxes
> The problem with these packages it not the summary but the generic
> name of the package. This is something we cannot change.

Right, some of those are false positives, but "Contacts addressbook"
could quite easily become "Easy to use address book" -- I guess it's
mainly preference.

> More examples of false positives:
>       * asylum  SDL port of the game Asylum, originally for the

What's so important about SDL? What is the game? What if i've never
played Asylum? Is is a platform game or a shoot-em-up?

>         Archimedes (try to remove the name here: A port of what?)
>       * audit   User space tools for 2.6 kernel auditing
>       * calc    Arbitrary precision arithmetic system and calculator
>       * dia     Diagram drawing program
>       * ed      The GNU line editor
>       * eject   A program that ejects removable media using software
>         control.

"A program that ejects removable media" -- but I agree the others are
false positives.

> I'm not criticizing your script, I just want to point out that it's
> not as many packages as you might think and for others there is
> nothing we can do about it.

You've every right to complain about my script, it is a cheap hack, and
the first (and probably last time) I'll try to contact package
maintainers directly.

Before I sent the emails, I followed all the giudelines people gave me.
For reference, nobody told me before in any of the 200+ posts to include
the FAS username, and I was told to email pkname-owner rather than the
fas owner email address.

If I spammed people; I apologise. As a point of interest, _tons_ of
people have modified spec files in the last 24 hours, so I consider the
activity worthwhile, even if some people are pretty pissed off at me.

Richard.




From musuruan at gmail.com  Sun Nov 23 10:04:13 2008
From: musuruan at gmail.com (Andrea Musuruane)
Date: Sun, 23 Nov 2008 11:04:13 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081123013205.0ee6c6f7.mschwendt@gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227376619.3852.76.camel@wicktop.localdomain>
	<20081123013205.0ee6c6f7.mschwendt@gmail.com>
Message-ID: <29fee02b0811230204v621b6378maecd1a92054f51b6@mail.gmail.com>

2008/11/23 Michael Schwendt <mschwendt at gmail.com>:
> Many, *many* people (except for fan-boys and people who are told to search
> for a specific brand) don't care at all about the name of a program when
> searching for a program. When they see the word "Thunar" it doesn't ring
> any bell. Instead, it makes them nervous as they don't know whether it
> matters to know what "Thunar". It could also be a special environment
> which they don't know and don't want. Adding the program name makes such a
> summary (and in turn the package) less attractive to these people. With
> the shorter summary "File manager" they are more willing to try out the
> software they don't know yet.

If what you say was true nobody would search and use Microsoft Office,
Adobe Photoshop, Internet Explorer, Oracle and even Coca Cola.

Sorry, you are plain wrong about this. We live in a world of branding,
where branding recognition is important and it starts from the name.

Many Open Source organization do branding too! Firefox, Samba, Fedora
and MySQL and brands and their controlling organizations promote these
brands.

Regards,

Andrea.



From ville.skytta at iki.fi  Sun Nov 23 10:21:42 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Sun, 23 Nov 2008 12:21:42 +0200
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <492713A2.8060101@gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<200811212152.48078.ville.skytta@iki.fi>
	<492713A2.8060101@gmail.com>
Message-ID: <200811231221.43014.ville.skytta@iki.fi>

On Friday 21 November 2008, Toshio Kuratomi wrote:
> Ville Skytt? wrote:
> > Leaving gnome-packagekit's current UI aside, is repeating the package
> > name in summary something that people would rather not see done in any
> > case?  I tend to think that it'd be better to not repeat it myself.  Just
> > asking in case there's clear consensus on this - this is something that
> > would be trivial to check in rpmlint.
>
> +1

The consensus doesn't seem to be entirely clear but I added the check anyway 
in upstream rpmlint svn.  Its output can always be filtered out later if 
needed.



From nicolas.mailhot at laposte.net  Sun Nov 23 10:22:21 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 23 Nov 2008 11:22:21 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227431703.3188.12.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<20081121194906.GA17123@orient.maison.lan>
	<1227364284.3167.28.camel@hughsie-laptop>
	<20081122183329.GA23447@orient.maison.lan>
	<1227383355.10434.16.camel@arekh.okg>
	<1227431703.3188.12.camel@hughsie-laptop>
Message-ID: <1227435741.10396.1.camel@arekh.okg>

Le dimanche 23 novembre 2008 ? 09:15 +0000, Richard Hughes a ?crit :
> On Sat, 2008-11-22 at 20:49 +0100, Nicolas Mailhot wrote:
> > There are lots of stuff that could be improved in packages matadata,
> > (like killing the funny camelcase names), and others did go the hard
> > FPC route before firing XXX mails.
> 
> I just went ahead painted the bike shed. Apologies if this cause
> offence.

No offense, it's human, but please go through FPC before asking a lot of
packagers to do changes.

-- 
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/20081123/a922b27a/attachment.sig>

From nicolas.mailhot at laposte.net  Sun Nov 23 10:39:11 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 23 Nov 2008 11:39:11 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <200811231221.43014.ville.skytta@iki.fi>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<200811212152.48078.ville.skytta@iki.fi> <492713A2.8060101@gmail.com>
	<200811231221.43014.ville.skytta@iki.fi>
Message-ID: <1227436751.10396.4.camel@arekh.okg>

Le dimanche 23 novembre 2008 ? 12:21 +0200, Ville Skytt? a ?crit :

> The consensus doesn't seem to be entirely clear

Meaning there are none

>  but I added the check anyway 

Please do not add checks to rpmlint which have not been reviewed by FPC.
Packagers are taking rpmlint output as authoritative and I don't see why
we should bother with FPC at all if you're taking policy in your hands.

-- 
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/20081123/502320ad/attachment.sig>

From alan at redhat.com  Sun Nov 23 10:47:39 2008
From: alan at redhat.com (Alan Cox)
Date: Sun, 23 Nov 2008 05:47:39 -0500
Subject: "nousb" poll
In-Reply-To: <20081122124735.79095ca8.zaitcev@redhat.com>
References: <20081122103552.86a26420.zaitcev@redhat.com>
	<1227376350.5833.30.camel@beck.corsepiu.local>
	<20081122193423.GA11208@shell.devel.redhat.com>
	<20081122124735.79095ca8.zaitcev@redhat.com>
Message-ID: <20081123104739.GA18290@shell.devel.redhat.com>

On Sat, Nov 22, 2008 at 12:47:35PM -0700, Pete Zaitcev wrote:
> > And me - on boxes with buggy BIOS SMM.
> 
> Eww, I forgot about those. BTW, what's the console on them?

Not sure I understand the question ?



From christoph.wickert at googlemail.com  Sun Nov 23 11:18:38 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Sun, 23 Nov 2008 12:18:38 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081122183329.GA23447@orient.maison.lan>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<20081121194906.GA17123@orient.maison.lan>
	<1227364284.3167.28.camel@hughsie-laptop>
	<20081122183329.GA23447@orient.maison.lan>
Message-ID: <1227439118.3557.14.camel@wicktop.localdomain>

Am Samstag, den 22.11.2008, 19:33 +0100 schrieb Emmanuel Seyman:
> * Richard Hughes [22/11/2008 15:38] :
> >
> > On Fri, 2008-11-21 at 20:49 +0100, Emmanuel Seyman wrote:
> >
> > > Out of curiosity, how much is "Many"?
> > 
> > At the moment, one.
> 
> FWIW, I don't appreciate our maintainers being lied to. The vast
> majority of them work hard to make their packages and I believe that a
> minimum of respect should be shown.

Sorry, but so should you. Richard is one of the most productive Fedora
developers, so "working hard" also applies to him. It is ridiculous to
accuse him of lying, especially because he was right: From a user's POV
there are several apps. Not only (gnome-)packagekit, think of synaptic
for example. 

> > So it's not just a case of it being shown prominently in "one"
> > application at all.
> 
> But it is a case of changing one application versus changing 500.

Although I disagree with Richard in some details, he is right that we
need better summaries. A lot of summaries start "foo is a...." wich is
just useless. The summaries should be unified and it does not really
matter how much packages are affected. The larger the number is, the
more important it is.

> Emmanuel

Regards,
Christoph

[1]
http://upload.wikimedia.org/wikipedia/commons/8/87/Synaptic_Package_Manager.png



From rawhide at fedoraproject.org  Sun Nov 23 12:43:03 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sun, 23 Nov 2008 12:43:03 +0000 (UTC)
Subject: rawhide report: 20081123 changes
Message-ID: <20081123124303.D51D41F823B@releng2.fedora.phx.redhat.com>

Compose started at Sun Nov 23 06:01:06 UTC 2008

Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 0














From behdad at behdad.org  Sun Nov 23 12:49:42 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Sun, 23 Nov 2008 07:49:42 -0500
Subject: My roadmap for a better Fedora
In-Reply-To: <1227376928.5833.35.camel@beck.corsepiu.local>
References: <1227119906.7387.138.camel@localhost.localdomain>	<20081122003831.GN2961@nb.net.home>	<1227356073.5833.12.camel@beck.corsepiu.local>	<49284587.3000100@gmail.com>
	<1227376928.5833.35.camel@beck.corsepiu.local>
Message-ID: <49295166.3030709@behdad.org>

Ralf Corsepius wrote:
>> - and I though Ubuntu included one too although 
>> I haven't seen anything trip it.
>
> Gnome had one for many years (bug-buddy), ... I don't recall having seen
> it providing any substantial improvement to Gnome.


The GNOME bugsquad team routinely sorts the incoming crash reports and
identifies the frequent ones and pushes the maintainers to fix them.

behdad



From mschwendt at gmail.com  Sun Nov 23 12:53:47 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 23 Nov 2008 13:53:47 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <19279.1227408826@sss.pgh.pa.us>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227376619.3852.76.camel@wicktop.localdomain>
	<20081123013205.0ee6c6f7.mschwendt@gmail.com>
	<19279.1227408826@sss.pgh.pa.us>
Message-ID: <20081123135347.e7a924c7.mschwendt@gmail.com>

On Sat, 22 Nov 2008 21:53:46 -0500, Tom Lane wrote:

> address how to describe subpackages.  I'm less than convinced that
> it would be productive to avoid using "MySQL" in the subpackage
> descriptions.

Yes, known thing. Sub-packages usually create a reference to a main package.
And then it's hard to not mention the package %{name} or program name.

With "postgresql" (albeit not limited to postgresql) the added difficulty
is that the main package contains only parts of the suite. The server files
are in another package. Else the main package could be have the summary:

  Advanced Object-Relational database management system using SQL

Yeah, have fun with finding multiple summaries that describe the
sub-packages then. ;)



From mschwendt at gmail.com  Sun Nov 23 12:59:07 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 23 Nov 2008 13:59:07 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <29fee02b0811230204v621b6378maecd1a92054f51b6@mail.gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227376619.3852.76.camel@wicktop.localdomain>
	<20081123013205.0ee6c6f7.mschwendt@gmail.com>
	<29fee02b0811230204v621b6378maecd1a92054f51b6@mail.gmail.com>
Message-ID: <20081123135907.c53ac121.mschwendt@gmail.com>

On Sun, 23 Nov 2008 11:04:13 +0100, Andrea Musuruane wrote:

> > Many, *many* people (except for fan-boys and people who are told to search
> > for a specific brand) don't care at all about the name of a program when
> > searching for a program. When they see the word "Thunar" it doesn't ring
> > any bell. Instead, it makes them nervous as they don't know whether it
> > matters to know what "Thunar". It could also be a special environment
> > which they don't know and don't want. Adding the program name makes such a
> > summary (and in turn the package) less attractive to these people. With
> > the shorter summary "File manager" they are more willing to try out the
> > software they don't know yet.
> 
> If what you say was true nobody would search and use Microsoft Office,
> Adobe Photoshop, Internet Explorer, Oracle and even Coca Cola.
> 
> Sorry, you are plain wrong about this. We live in a world of branding,
> where branding recognition is important and it starts from the name.
> 
> Many Open Source organization do branding too! Firefox, Samba, Fedora
> and MySQL and brands and their controlling organizations promote these
> brands.

You're missing the point, however. I don't say branding isn't done.
I don't say that brand recognition is unimportant to some vendors.
I don't say that users never learn all the different names and brands.

I'm talking about beginners, the newbie-friendliness of Fedora, and
the interface to the growing number of packages in the repositories.
About [Fedora] Linux newbies, who are confronted with (1) the task of
finding the counter-piece for every program they are familiar with on the
platform they've used before and (2) the task of finding new programs in
an overwhelming collection of several thousand packages or in a default
installation.

Give them a task, such as resizing an image. They won't search for a
specific program name, but for generic terms and phrases. "Image viewer",
"resize images", "image manipulation". They won't find "Photoshop" or
"IrfanView" anyway. "AbiWord" (which is a trademark) is advertised
upstream as "a free word processing program similar to Microsoft? Word".
They won't find it with a %summary that doesn't mention "Microsoft Word",
but they find it when searching for "word processing". For many types of
programs, the Open Source solution has a different name than what users,
who come from other platforms, are used to. Don't hide in the small world,
where you know all the sometimes weird names and acronyms for lots of
packages.

Samba -- a great example. Its summary says "The Samba Suite of programs",
which won't be found by any user who wants to set up "a network share" or
"share a printer". Only by searching and reading the package description,
which expands on what the Samba suite does, they would recognise this
package as one they might want.

It's all different the more experienced [and or knowledgeable] a user is.
Indeed, an experienced user would search for specific database suites,
such as PostgreSQL or MySQL. These users would be satisfied with a simple
mapping of package names to program names/acronyms:

  firefox : Mozilla Firefox
  gcc : GCC
  gedit : gedit
  gthumb : gThumb
  mysql : MySQL
  postgresql : PostgreSQL

:) 

It isn't trivial to come up with good one-line summaries that do more than
repeating the program name. It's nothing packagers like to spend time on.
Reducing a packager's freedom even further won't be a good thing. The
size limit is hard enough already for some packages and sub-packages.
Why is 

  gedit : gEdit is a small but powerful text editor for GNOME

better than
  
  gedit : Small but powerful text editor for the GNOME desktop

? (btw, upstream calls it "gedit" not "gEdit")

I think with some people one could argue endlessly about pkg summaries.
And during pkg reviews that's wasted time. Still, with very old repositories
it has been noticed [and agreed on, mostly] that some types of summaries
simply look poor in Anaconda and package management tools. That was the
rationale for some of the recommendations.



From rc040203 at freenet.de  Sun Nov 23 13:01:37 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sun, 23 Nov 2008 14:01:37 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227432407.3188.23.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227376619.3852.76.camel@wicktop.localdomain>
	<1227432407.3188.23.camel@hughsie-laptop>
Message-ID: <1227445297.5833.38.camel@beck.corsepiu.local>

On Sun, 2008-11-23 at 09:26 +0000, Richard Hughes wrote:
> On Sat, 2008-11-22 at 18:56 +0100, Christoph Wickert wrote:
> > Also your "simple hacky tool" produces a lot of false positives:
> >       * acpi    Command-line ACPI client (try to remove ACPI from
> > summary)
> >       * barcode generates barcodes from text strings
> >       * ccid    Generic USB CCID smart card reader driver
> >       * contacts        Contacts addressbook
> >       * dialog  A utility for creating TTY dialog boxes
> > The problem with these packages it not the summary but the generic
> > name of the package. This is something we cannot change.
> 
> Right, some of those are false positives, but "Contacts addressbook"
> could quite easily become "Easy to use address book"
Any program claims to be "easy to use", no matter how broken it's UI may
be.


> As a point of interest, _tons_ of
> people have modified spec files in the last 24 hours, so I consider the
> activity worthwhile, even if some people are pretty pissed off at me.
IMO, you are painting bike sheds and wasting people's time.





From mschwendt at gmail.com  Sun Nov 23 13:09:21 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 23 Nov 2008 14:09:21 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <200811231221.43014.ville.skytta@iki.fi>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<200811212152.48078.ville.skytta@iki.fi>
	<492713A2.8060101@gmail.com>
	<200811231221.43014.ville.skytta@iki.fi>
Message-ID: <20081123140921.638f6cb6.mschwendt@gmail.com>

On Sun, 23 Nov 2008 12:21:42 +0200, Ville Skytt? wrote:

> On Friday 21 November 2008, Toshio Kuratomi wrote:
> > Ville Skytt? wrote:
> > > Leaving gnome-packagekit's current UI aside, is repeating the package
> > > name in summary something that people would rather not see done in any
> > > case?  I tend to think that it'd be better to not repeat it myself.  Just
> > > asking in case there's clear consensus on this - this is something that
> > > would be trivial to check in rpmlint.
> >
> > +1
> 
> The consensus doesn't seem to be entirely clear but I added the check anyway 
> in upstream rpmlint svn.  Its output can always be filtered out later if 
> needed.

There's a difference between

   foo : Foo is a ...

and

   foo : Clients and shared libraries for Foo

in particular for sub-packages and big package splits.

In other words, _starting_ the summary with the program name should
be avoided. Especially in Anaconda (but also other lists of packages)
where the N-V-R is displayed and cryptic already, it is much more readable
to present a summary that starts with what is contained within a package.

   foo-1.0-4.fc10
   Image viewer
   
   bar-2.5-7.fc10
   Text editor

   fubar-0.9-0.3.rc3.fc10
   Download accellerator



From christoph.wickert at googlemail.com  Sun Nov 23 13:18:53 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Sun, 23 Nov 2008 14:18:53 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081123013205.0ee6c6f7.mschwendt@gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227376619.3852.76.camel@wicktop.localdomain>
	<20081123013205.0ee6c6f7.mschwendt@gmail.com>
Message-ID: <1227446333.3557.77.camel@wicktop.localdomain>

Am Sonntag, den 23.11.2008, 01:32 +0100 schrieb Michael Schwendt:
> On Sat, 22 Nov 2008 18:56:59 +0100, Christoph Wickert wrote:
> 
> > [...] Thunar (which I'm not owning but only
> > co-maintaining) has the following summary:
> >         Thunar File Manager
> 
> Forget for a moment that package name and summary are displayed close to
> eachother -- or ought to be displayed like that.
> 
> Many, *many* people (except for fan-boys and people who are told to search
> for a specific brand) don't care at all about the name of a program when
> searching for a program. 

Sorry to interrupt you here, but this is an important point: Searching.
IMO the main problem in design is that PK only allows to search for
names, so unlike you said people _do_ care about the name when they
search something, just because they have to.

In a perfect world (TM) you could also search for "file manger" or "word
processor" and then select one from the results given. And then it would
IMO perfectly make sense to have the app name in the summary because
otherwise a search for "file manger" would most likely return a bunch
of ... well... "file managers".

> When they see the word "Thunar" it doesn't ring
> any bell. Instead, it makes them nervous as they don't know whether it
> matters to know what "Thunar". It could also be a special environment
> which they don't know and don't want. Adding the program name makes such a
> summary (and in turn the package) less attractive to these people. With
> the shorter summary "File manager" they are more willing to try out the
> software they don't know yet.

I don't think so. I don't think that a name or brand scares anybody. I
could argue that with a lot of "file managers" they are afraid of
choosing the wrong one.

> [This is similar to the design of desktop menus. Ordinary users would
> rather choose a "Web browser" menu item (and newbies even an "Internet"
> menu item) than a "Mozilla Firefox Web Browser". Sure, over time they
> will learn about the name of the program they use, but that doesn't
> make the original system user-friendly.]
> 
> [While writing this I remember that I need to look at the current state
> of the Fedora desktop file guidelines, because our menus are still a
> mess WRT Name/GenericName usage.]

+10!

> > So if we remove thunar, nautilus, pcmanfm, ... only "file manager"
> > remains and I have no idea how to improve this summary.
> >       * "File manager for the Xfce desktop environment"? Not really,
> >         because it's not Xfce specific.
> 
> Not specific, but its FAQ says "... with a special focus on the Xfce
> DE". And the first line of the description says:
> 
>   Thunar is a new modern file manager for the Xfce Desktop Environment.

<bikeshed> I guess we could argue about the words "new" and "modern"
</bikeshed>


> >       * "Lightweight File Manager"? No, pcmanfm is even more lightweight
> >       * "GTK based File Manager"? We have at least 5 GTK based file
> >         managers
> 
> IMO, it would be relevant to describe it as "File manager for graphical
> desktop environments". Or to mention Xfce: "File manager with special
> focus on Xfce".

Ok, I will discuss a new description with the owner then. Thanks for
your suggestions.

> > The three file managers are very similar in design and function, so
> to
> > me it's almost logical that the descriptions are too. Can you tell
> me
> > what to improve in this case?
> 
> Just "File manager" is fine, too.

But then we are over-simplifying the summaries. If we carry on like
this, one day we only have "text editors" "file managers" and "word
processors" left.

> >       * abiword 	The AbiWord word processor
> > 
> > We have a couple of word processors and having the application's
> name in
> > the description helps to distinguish between them.
> 
> Redundancy, which makes the package summary less clear unless you know
> already what "AbiWord" is. As explained above. Acronyms, brand-names
> and
> trademarks make ordinary users nervous. Have you ever met users who
> would
> ask "What is an AbiWord word processor?" while looking for a "normal"
> word
> processor? 

No, but I'm sure everybody recognizes AbiWord as a name and not as a
general term. We live in a world of names and brands, as Andrea already
said.

> Or users who know how to surf the Internet in a web browser
> that is started automatically, but the "Mozilla Firefox" icon on the
> deskop confuses them and they would not click it if they wanted to start a
> web browser manually (until they learn and remember the "Mozilla Firefox"
> name).

Most people I know _do_ (at least) know Mozilla and/or the
Internet-Explorer. I think that applies to 90% of all computer users and
99,99% of the Fedora audience. People who don't have a clue what Firefox
is are not our target audience, I guess they would have more severe
problems with our distribution than to remember and click the proper
icon.
Sorry to say that, but I think your examples are a very quixotic. I have
never seen someone who has been surfing the internet with web browser
that is started automatically. I know there are internet kiosks, but do
you think that someone who has never used a computer before will go up
to one of those kiosks and start his internet career there?

> > What is so bad in
> > having descriptions like "The exim mail transfer agent", "The postfix
> > mail transfer agent" and "The sendmail mail transfer agent"?
> 
> It's a matter of perspective. Do you think the branding is so important as
> to use it also in the summary? Does it make a package more attractive?

Not on the command line, but in the current PK UI, because you can focus
on the big bold text then.

> AbiWord is a trademark, for example. Users, who know that name, also know
> how to search for it in the Fedora package collection.

As I stated above: Only people who know the name can search in PK.

>   sendmail : A widely used Mail Transport Agent (MTA)
> 
> is the current summary for this MTA. Expand your list of examples of "The
> %name ..."  summaries. You can do it with all other packages for a bad
> precedent and decrease the S/N ratio:
> 
>   k3b : The K3b CD/DVD burning application for KDE
>   gthumb : The gThumb image viewer, editor, organizer
>   audacious : The Audacious GTK2 based media player similar to XMMS

If you list them that way it is indeed more noise, but IMO no one will
ever see the examples you mention listed together that way. I was
thinking of the PK UI (because it was the reason for this discussion),
for example when you select the "server" group and are presented a list
of available MTAs. Also you should keep in mind that app name not
necessarily is package name.

Regards,
Christoph



From lsof at nodata.co.uk  Sun Nov 23 13:33:52 2008
From: lsof at nodata.co.uk (nodata)
Date: Sun, 23 Nov 2008 14:33:52 +0100
Subject: NetworkManager cli docs
Message-ID: <1227447232.3721.1.camel@sb-home>

Hi,

Can anyone point me at the docs for configuring NetworkManager without
the tray applet?

I've tried google, the gnome.org nm page, and the man pages. I can't
find a thing.

Thanks.



From k.georgiou at imperial.ac.uk  Sun Nov 23 14:50:24 2008
From: k.georgiou at imperial.ac.uk (Kostas Georgiou)
Date: Sun, 23 Nov 2008 14:50:24 +0000
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227431823.3188.14.camel@hughsie-laptop>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<20081121194906.GA17123@orient.maison.lan>
	<1227364284.3167.28.camel@hughsie-laptop>
	<20081122183329.GA23447@orient.maison.lan>
	<1227431823.3188.14.camel@hughsie-laptop>
Message-ID: <20081123145021.GA18760@imperial.ac.uk>

On Sun, Nov 23, 2008 at 09:17:03AM +0000, Richard Hughes wrote:

> That's not the point. PackageKit isn't going to change to show the name
> more prominently than the description. PackageKit _is_ going to be
> integrated more places, and the user _is_ going to see PackageKit
> dialogs in more places than they see it now.

I am a bit worried by this. The users in my systems will be really
annoyed if they start getting bombarded by PackageKit dialogs, it's not
like they have a root password so they can do anything usefull with such
a dialog.

Kostas



From dominik at greysector.net  Sun Nov 23 14:57:25 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Sun, 23 Nov 2008 15:57:25 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081123140921.638f6cb6.mschwendt@gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<200811212152.48078.ville.skytta@iki.fi>
	<492713A2.8060101@gmail.com>
	<200811231221.43014.ville.skytta@iki.fi>
	<20081123140921.638f6cb6.mschwendt@gmail.com>
Message-ID: <20081123145725.GC11019@mokona.greysector.net>

On Sunday, 23 November 2008 at 14:09, Michael Schwendt wrote:
> On Sun, 23 Nov 2008 12:21:42 +0200, Ville Skytt? wrote:
> 
> > On Friday 21 November 2008, Toshio Kuratomi wrote:
> > > Ville Skytt? wrote:
> > > > Leaving gnome-packagekit's current UI aside, is repeating the package
> > > > name in summary something that people would rather not see done in any
> > > > case?  I tend to think that it'd be better to not repeat it myself.  Just
> > > > asking in case there's clear consensus on this - this is something that
> > > > would be trivial to check in rpmlint.
> > >
> > > +1
> > 
> > The consensus doesn't seem to be entirely clear but I added the check anyway 
> > in upstream rpmlint svn.  Its output can always be filtered out later if 
> > needed.

-1

> There's a difference between
> 
>    foo : Foo is a ...
> 
> and
> 
>    foo : Clients and shared libraries for Foo
> 
> in particular for sub-packages and big package splits.
> 
> In other words, _starting_ the summary with the program name should
> be avoided. Especially in Anaconda (but also other lists of packages)
> where the N-V-R is displayed and cryptic already, it is much more readable
> to present a summary that starts with what is contained within a package.
> 
>    foo-1.0-4.fc10
>    Image viewer
>    
>    bar-2.5-7.fc10
>    Text editor
> 
>    fubar-0.9-0.3.rc3.fc10
>    Download accellerator

+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 christoph.wickert at googlemail.com  Sun Nov 23 15:01:05 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Sun, 23 Nov 2008 16:01:05 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <3adc77210811210752s64d445f1x49874677b40361c@mail.gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<3adc77210811210752s64d445f1x49874677b40361c@mail.gmail.com>
Message-ID: <1227452465.3557.87.camel@wicktop.localdomain>

Am Freitag, den 21.11.2008, 15:52 +0000 schrieb Naheem Zaffar:
> Considering that the package name is not given much prominence in the
> UI, is it really a bad thing to repeat it in the summary?
>  
>         * XQilla is an XQuery and XPath 2.0 library, built on top of
>         Xerces-C
>         (repeating the program name)
>         * DeVeDe is a program to create video DVDs and CDs (VCD, sVCD
>         or CVD)
>         (to much detail)

These are good examples of how _not_ to do it. We have not reached
consensus on not repeating the program name or on how detailed
descriptions should be, but I think we all agree that "foo is a ..." is
completely useless and should thus should be avoided. 

Christoph



From mschwendt at gmail.com  Sun Nov 23 15:53:40 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 23 Nov 2008 16:53:40 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227446333.3557.77.camel@wicktop.localdomain>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227376619.3852.76.camel@wicktop.localdomain>
	<20081123013205.0ee6c6f7.mschwendt@gmail.com>
	<1227446333.3557.77.camel@wicktop.localdomain>
Message-ID: <20081123165340.ae9291bb.mschwendt@gmail.com>

On Sun, 23 Nov 2008 14:18:53 +0100, Christoph Wickert wrote:

> IMO the main problem in design is that PK only allows to search for
> names,

The it ought to get fixed.

> In a perfect world (TM) you could also search for "file manger" or "word
> processor" and then select one from the results given.

Great! :)

> And then it would
> IMO perfectly make sense to have the app name in the summary because
> otherwise a search for "file manger" would most likely return a bunch
> of ... well... "file managers".

Not so great anymore, because (1) the pkg name usually bears a striking
resemblance with the app name, and (2) there have been cases already where
users failed to find an app when searching for the app name in package
names. Example: kmail and other KDE apps, which are found in packages that
have a completely different name. You cannot squeeze the name of all apps
into the summary just to serve those users who search for app names.

> I don't think that a name or brand scares anybody. I
> could argue that with a lot of "file managers" they are afraid of
> choosing the wrong one.

Perhaps because it comes with a text-based interface only and the
summary doesn't mention that? ;)

[Thunar]

> > Not specific, but its FAQ says "... with a special focus on the Xfce
> > DE". And the first line of the description says:
> > 
> >   Thunar is a new modern file manager for the Xfce Desktop Environment.
> 
> <bikeshed> I guess we could argue about the words "new" and "modern"
> </bikeshed>

Certainly. ;) This the the current %description of the Fedora pkg, however.

> > Just "File manager" is fine, too.
> 
> But then we are over-simplifying the summaries. If we carry on like
> this, one day we only have "text editors" "file managers" and "word
> processors" left.

What's wrong with that?

There will still be some apps that don't offer a GUI, and that would be a
good reason to mention that in the summary.  Don't forget that for more
verbosity, the user could display the description. There are other package
details a package management GUI might hide by default (%version and
%release, for example),

  mc : User-friendly text console file manager and visual shell

A "visual shell", haha!

> > trademarks make ordinary users nervous. Have you ever met users who
> > would
> > ask "What is an AbiWord word processor?" while looking for a "normal"
> > word
> > processor? 
> 
> No, but I'm sure everybody recognizes AbiWord as a name and not as a
> general term. We live in a world of names and brands, as Andrea already
> said.

Sure, but what makes it so special as to mention it? Do you need to
know what AbiWord is?

  texlive - Binaries for the TeX formatting system

You better stay away from it unless you have an idea what TeX and/or
LaTeX are.

  emacs - GNU Emacs text editor

Can it edit only Emacs text files? I would change the summary to
  Versatile text editor
or
  Customizable text editor


  vim - A version of the VIM editor which includes recent enhancements

Only the description explains what "VIM" means. Without that knowledge,
this summary is less helpful, as VIM could be a special data file format,
for example.

> Sorry to say that, but I think your examples are a very quixotic. I have
> never seen someone who has been surfing the internet with web browser
> that is started automatically.

This is splitting-hairs. Let them switch between IE and Firefox and Opera,
change the desktop icon and title, which they click usually to start the
browser - there are enough ways to confuse non-geeks or newbies.



From icon at fedoraproject.org  Sun Nov 23 16:28:33 2008
From: icon at fedoraproject.org (Konstantin Ryabitsev)
Date: Sun, 23 Nov 2008 11:28:33 -0500
Subject: Orphaning: MochiKit
Message-ID: <f8f6300f0811230828j19fec277le121e2b0f8904fc9@mail.gmail.com>

Hi, all:

I no longer use MochiKit, so I am not a good maintainer. There is a
new release, which is quite different from the old one, so it's best
if someone can thoroughly test it before updating packages.

If you use MochiKit in your projects, please feel free to pick it up.

Cheers,
-- 
Konstantin Ryabitsev
Montr?al, Qu?bec



From hughsient at gmail.com  Sun Nov 23 16:36:18 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 23 Nov 2008 16:36:18 +0000
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081123165340.ae9291bb.mschwendt@gmail.com>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227376619.3852.76.camel@wicktop.localdomain>
	<20081123013205.0ee6c6f7.mschwendt@gmail.com>
	<1227446333.3557.77.camel@wicktop.localdomain>
	<20081123165340.ae9291bb.mschwendt@gmail.com>
Message-ID: <1227458178.3185.0.camel@hughsie-laptop>

On Sun, 2008-11-23 at 16:53 +0100, Michael Schwendt wrote:
> > IMO the main problem in design is that PK only allows to search for
> > names,
> 
> The it ought to get fixed.

Change the search type to "detail" -- this is the icon next to the
search text entry.

Richard.




From hughsient at gmail.com  Sun Nov 23 16:38:18 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 23 Nov 2008 16:38:18 +0000
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227445297.5833.38.camel@beck.corsepiu.local>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227376619.3852.76.camel@wicktop.localdomain>
	<1227432407.3188.23.camel@hughsie-laptop>
	<1227445297.5833.38.camel@beck.corsepiu.local>
Message-ID: <1227458298.3185.2.camel@hughsie-laptop>

On Sun, 2008-11-23 at 14:01 +0100, Ralf Corsepius wrote:
> IMO, you are painting bike sheds and wasting people's time.

Yes, guilty as charged. I would rather paint the bike shed blue, rather
than argue forever about what kind of blue we should paint it. If I've
wasted people's time I apologise, but the number of commits I've seen
over the last 48 hours seems to suggest otherwise.

Richard.




From hughsient at gmail.com  Sun Nov 23 16:40:48 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 23 Nov 2008 16:40:48 +0000
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <20081123145021.GA18760@imperial.ac.uk>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227282194.3359.83.camel@hughsie-laptop>
	<20081121194906.GA17123@orient.maison.lan>
	<1227364284.3167.28.camel@hughsie-laptop>
	<20081122183329.GA23447@orient.maison.lan>
	<1227431823.3188.14.camel@hughsie-laptop>
	<20081123145021.GA18760@imperial.ac.uk>
Message-ID: <1227458448.3185.3.camel@hughsie-laptop>

On Sun, 2008-11-23 at 14:50 +0000, Kostas Georgiou wrote:
> 
> I am a bit worried by this. The users in my systems will be really
> annoyed if they start getting bombarded by PackageKit dialogs, it's
> not like they have a root password so they can do anything usefull
> with such a dialog.

Right, as an admin you can either change the default gconf policy for
groups of users in tools like sabayon, or even just change the PolicyKit
defaults. It's designed to fall back nicely in this case.

Richard.




From ville.skytta at iki.fi  Sun Nov 23 16:44:33 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Sun, 23 Nov 2008 18:44:33 +0200
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <1227436751.10396.4.camel@arekh.okg>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<200811231221.43014.ville.skytta@iki.fi>
	<1227436751.10396.4.camel@arekh.okg>
Message-ID: <200811231844.34387.ville.skytta@iki.fi>

On Sunday 23 November 2008, Nicolas Mailhot wrote:

> Please do not add checks to rpmlint which have not been reviewed by FPC.

Of course I and others do and will.

1) rpmlint is not a project governed by FPC or any other Fedora entity.  There 
are no FPC members actively involved with rpmlint upstream development as far 
as I can tell.  The rpmlint community or anyone who can find convince them of 
a check's usefulness can get checks they find useful added to it.

2) I'm pretty sure FPC has not reviewed the existing set of enabled checks in 
rpmlint and I'm not aware of them planning to do so.

3) rpmlint does not exist exclusively for enforcing Fedora packaging 
guidelines.  It does and will always check things that are not in Fedora 
packaging guidelines as well as does not and will not check everything in 
them.  Fedora packaging guidelines are one positive driver for rpmlint's 
development but they are not nor will be something that slows down its 
development upstream at least as long as I'm involved there.  Especially 
something that is not mentioned at all in Fedora packaging guidelines (such 
as what we're discussing now) will not slow rpmlint's development down, and 
chances are that there are even some cases where checks that are actually 
against Fedora packaging guidelines will be added to it by someone.  In those 
cases, see 4) below.

4) If a check does not exist in rpmlint, it can't check that no matter how 
useful the check it is to someone.  If a check exists and you thinks it's 
harmful or produces too many false positives etc, there are a number of 
config files where you can use addFilter() and forget about it.  This can be 
done on project level too.  Who knows, it could be that the check I just 
added ends up being filtered in Fedora rpmlint's default config, but I know I 
(and from what I've read, probably others as well) want it to be done in my 
rpmlint runs nevertheless.  There's some work to be done in rpmlint to make 
things setups like this easier to configure but it can be done already today.  
Just to clarify, I am not going to filter the just added check out in the 
next rpmlint release unless "forced" by FPC.

Now, if FPC is not happy with the way I maintain the rpmlint package in 
Fedora, I'm sure they will contact me about it and we'll work it out some 
way.

> Packagers are taking rpmlint output as authoritative

Well, either those packagers are or I am mistaken.  The Fedora packaging 
guidelines don't say anything explicitly about rpmlint's authority but I 
think reading the rpmlint chapter in them makes its position pretty clear.

> and I don't see why 
> we should bother with FPC at all if you're taking policy in your hands.

Ahh, trolling again?  Sorry, I won't bite this time.  Or in case you're one of 
those packagers who I think are mistaken about what's 
policy/guidelines/authority and what's not, apologies for the troll 
accusation and see above.



From nicolas.mailhot at laposte.net  Sun Nov 23 16:59:47 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 23 Nov 2008 17:59:47 +0100
Subject: RFC: fix summary text for lots of packages
In-Reply-To: <200811231844.34387.ville.skytta@iki.fi>
References: <1227191607.4076.29.camel@hughsie-laptop>
	<200811231221.43014.ville.skytta@iki.fi>
	<1227436751.10396.4.camel@arekh.okg>
	<200811231844.34387.ville.skytta@iki.fi>
Message-ID: <1227459587.25325.19.camel@arekh.okg>

Le dimanche 23 novembre 2008 ? 18:44 +0200, Ville Skytt? a ?crit :

> > and I don't see why 
> > we should bother with FPC at all if you're taking policy in your hands.
> 
> Ahh, trolling again?  

I happen to be one of the people who waste their evenings doing package
reviews, and having to explain that a rpmlint warning packagers
religiously follow is just someone's bikeshedding added without
consultation, and sometimes even *contrary* to FPC decisions, is not fun
at all.

You can call that trolling is it makes you feel better.

-- 
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/20081123/9bcb657a/attachment.sig>

From bashton at brennanashton.com  Sun Nov 23 17:05:33 2008
From: bashton at brennanashton.com (Brennan Ashton)
Date: Sun, 23 Nov 2008 09:05:33 -0800
Subject: Orphaning: MochiKit
In-Reply-To: <f8f6300f0811230828j19fec277le121e2b0f8904fc9@mail.gmail.com>
References: <f8f6300f0811230828j19fec277le121e2b0f8904fc9@mail.gmail.com>
Message-ID: <981da310811230905w2890feb2pdb18d9359ce5a1a8@mail.gmail.com>

On Sun, Nov 23, 2008 at 8:28 AM, Konstantin Ryabitsev
<icon at fedoraproject.org> wrote:
> Hi, all:
>
> I no longer use MochiKit, so I am not a good maintainer. There is a
> new release, which is quite different from the old one, so it's best
> if someone can thoroughly test it before updating packages.
>
> If you use MochiKit in your projects, please feel free to pick it up.
I would be interested in doing this, as I use it for work (did not
know there was a Fedora package for it).  I am not currently
sponsored, so how would I go about this for a package that is not new,
but orphaned?

--Brennan Ashton



From tgl at redhat.com  Sun Nov 23 17:32:54 2008
From: tgl at redhat.com (Tom Lane)
Date: Sun, 23 Nov 2008 12:32:54 -0500
Subject: RFC: fix summary text for lots of packages 
In-Reply-To: <20081123135347.e7a924c7.mschwendt@gmail.com> 
References: <1227191607.4076.29.camel@hughsie-laptop>
	<1227376619.3852.76.camel@wicktop.localdomain>
	<20081123013205.0ee6c6f7.mschwendt@gmail.com>
	<19279.1227408826@sss.pgh.pa.us>
	<20081123135347.e7a924c7.mschwendt@gmail.com>
Message-ID: <25560.1227461574@sss.pgh.pa.us>

Michael Schwendt <mschwendt at gmail.com> writes:
> With "postgresql" (albeit not limited to postgresql) the added difficulty
> is that the main package contains only parts of the suite. The server files
> are in another package.

Right, and the same is true of mysql.  These decisions were made before
I took over the packages, but I think the reasoning is that the client
programs are useful without the server (because you might be installing
them just to talk to a remote database server), but the server isn't
very useful without the clients (because they are essential management
tools for a server).  So the client programs form the "base" package
and the -server subpackage depends on that, not the other way around.

This means that there really isn't *any* single package on which it's
useful to hang a self-contained description like
>   Advanced Object-Relational database management system using SQL
The base package really has to say that it's just clients for the
DBMS, or it's misleading.  I suppose I could attach such a description
to the -server subpackage, but it looks a tad weird in context.

If I had a way to declare a "meta-package" in the specfile then I'd
attach the core description to it.

			regards, tom lane



From zaitcev at redhat.com  Sun Nov 23 19:03:16 2008
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Sun, 23 Nov 2008 12:03:16 -0700
Subject: "nousb" poll
In-Reply-To: <20081123104739.GA18290@shell.devel.redhat.com>
References: <20081122103552.86a26420.zaitcev@redhat.com>
	<1227376350.5833.30.camel@beck.corsepiu.local>
	<20081122193423.GA11208@shell.devel.redhat.com>
	<20081122124735.79095ca8.zaitcev@redhat.com>
	<20081123104739.GA18290@shell.devel.redhat.com>
Message-ID: <20081123120316.371a9815.zaitcev@redhat.com>

On Sun, 23 Nov 2008 05:47:39 -0500, Alan Cox <alan at redhat.com> wrote:

> On Sat, Nov 22, 2008 at 12:47:35PM -0700, Pete Zaitcev wrote:
> > > And me - on boxes with buggy BIOS SMM.
> > 
> > Eww, I forgot about those. BTW, what's the console on them?
> 
> Not sure I understand the question ?

Sorry. I meant to ask: if the USB does not work, how is the
console input arranged?

-- Pete



From giallu at gmail.com  Sun Nov 23 20:14:48 2008
From: giallu at gmail.com (Gianluca Sforna)
Date: Sun, 23 Nov 2008 21:14:48 +0100
Subject: Orphaning: MochiKit
In-Reply-To: <981da310811230905w2890feb2pdb18d9359ce5a1a8@mail.gmail.com>
References: <f8f6300f0811230828j19fec277le121e2b0f8904fc9@mail.gmail.com>
	<981da310811230905w2890feb2pdb18d9359ce5a1a8@mail.gmail.com>
Message-ID: <d5ad21470811231214v6b35b93bwa59c84f0b86e931d@mail.gmail.com>

On Sun, Nov 23, 2008 at 6:05 PM, Brennan Ashton
<bashton at brennanashton.com> wrote:
> I am not currently
> sponsored, so how would I go about this for a package that is not new,
> but orphaned?

You just need to find a sponsor by the usual means: do reviews and/or
submit other packages.

http://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored

-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna



From bashton at brennanashton.com  Sun Nov 23 21:31:56 2008
From: bashton at brennanashton.com (Brennan Ashton)
Date: Sun, 23 Nov 2008 13:31:56 -0800
Subject: Orphaning: MochiKit
In-Reply-To: <d5ad21470811231214v6b35b93bwa59c84f0b86e931d@mail.gmail.com>
References: <f8f6300f0811230828j19fec277le121e2b0f8904fc9@mail.gmail.com>
	<981da310811230905w2890feb2pdb18d9359ce5a1a8@mail.gmail.com>
	<d5ad21470811231214v6b35b93bwa59c84f0b86e931d@mail.gmail.com>
Message-ID: <981da310811231331x2e77eb96ub5aa81018e90a5f3@mail.gmail.com>

On Sun, Nov 23, 2008 at 12:14 PM, Gianluca Sforna <giallu at gmail.com> wrote:
> On Sun, Nov 23, 2008 at 6:05 PM, Brennan Ashton
> <bashton at brennanashton.com> wrote:
>> I am not currently
>> sponsored, so how would I go about this for a package that is not new,
>> but orphaned?
>
> You just need to find a sponsor by the usual means: do reviews and/or
> submit other packages.

I figured as much, but just wanted to check, I am submitting a
ReviewRequest today for another package for sponsorship, once that
happens, I am still interested in taking over this package.

--Brennan Ashton



From seandarcy2 at gmail.com  Sun Nov 23 21:45:17 2008
From: seandarcy2 at gmail.com (sean darcy)
Date: Sun, 23 Nov 2008 16:45:17 -0500
Subject: where's the wish list for F11?
In-Reply-To: <49285293.4060305@robertoragusa.it>
References: <gg4dm5$ts1$1@ger.gmane.org>	<alpine.LFD.2.00.0811201455510.16994@localhost.localdomain>	<gg554h$6mi$1@ger.gmane.org>	<20081121094044.GA24555@mokona.greysector.net>	<1227263653.9545.18.camel@arekh.okg>	<20081121112829.GC24555@mokona.greysector.net>	<1227270285.9545.27.camel@arekh.okg>	<gg6ifb$490$1@ger.gmane.org>	<1227284001.13179.14.camel@arekh.okg>
	<gg7tnl$481$1@ger.gmane.org> <49285293.4060305@robertoragusa.it>
Message-ID: <ggcitd$bm8$1@ger.gmane.org>

Roberto Ragusa wrote:
> Thomas M Steenholdt wrote:
> 
>> Why not simply provide the default fontconfig package, with the ability
>> to load fonts from say "/usr/local/share/fonts" ?
>>
> 
> Good idea.
> This is exactly what I've done to add some unpackaged fonts
> to my system.
> A comment in /etc/fonts/fonts.conf says you should have local
> modifications in /etc/fonts/local.conf.
> 
> This is the content of my local.conf:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE fontconfig SYSTEM "fonts.dtd">
> <fontconfig>
>   <dir>/usr/local/share/fonts</dir>
> </fontconfig>
> 

OK, so I set up local.conf in /etc/fonts. Then what? It just works? 
Reboot? Restart some service?  Restart X? Does  it work for Type1 as 
well as TT?

I'm stunned it could be so easy. It as though there's cabalistic 
knowledge on Fedora only the initiates know.

sean

sean



From kevin at scrye.com  Sun Nov 23 22:07:43 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Sun, 23 Nov 2008 15:07:43 -0700
Subject: PackageMaintainers/Policy/EOL pages and FESCo responsibilities
In-Reply-To: <20081116172041.GE2933@free.fr>
References: <20081116172041.GE2933@free.fr>
Message-ID: <20081123150743.13cf1475@ohm.scrye.com>

On Sun, 16 Nov 2008 18:20:41 +0100
pertusus at free.fr (Patrice Dumas) wrote:

> Hello,

Sorry for the delay here. I meant to reply to this sooner. 

> I think that the PackageMaintainers/Policy pages should be under
> FESCo responsibility, such that
> * they are updated when policies are updated
> * new policies are added
> 
> FESCo should not necessarily take care of the actual writing, but at
> least oblige packagers who proposed a new policy that was accepted to
> update the Policy page, and similarly when a policy is changed.

I would agree. Perhaps we can address it at the next meeting. 

> I think that FESCo should also oblige
> Infra/Releng/documentation/BugZappers (and other similar groups) to
> modify the Policy pages when they introduce changes that modify
> policies. I don't know how exactly is FESCo aware of what changes in
> other groups, but at least should try to act such that packagers are
> aware of policies that are important for them. This could simply be
> redirections to pages maintained by those other groups.

Yes, as that page is now. 

> Examples of policies that may be (or not) missing are release notes,
> bugzilla handling, features. And

True. 

> PackageMaintainers/MaintainerResponsibility should certainly be a
> policy too.

Yes, although I don't know if that was finished and formally
approved... 

> Of course FESCo is somehow responsible for all that is in the wiki,
> but for policies it is even more important since these are meant to be
> mandatory things. 
> 
> However, currently the Policies pages are in a very bad state, which
> is pretty bad, in my opinion, for new packagers, especially those who
> don't read through all that goes along in fedora-devel-list.

Agreed. I removed the kmod section there as it no longer applies. 

> 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/20081123/c04afb74/attachment.sig>

From kevin at scrye.com  Sun Nov 23 22:15:41 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Sun, 23 Nov 2008 15:15:41 -0700
Subject: BugZappers/HouseKeeping is a policy and seems incomplete
In-Reply-To: <20081118191939.GB2610@free.fr>
References: <20081116160839.GC2933@free.fr>
	<da159fda0811161621y4847991bn8a87c1807d0fec29@mail.gmail.com>
	<20081118191939.GB2610@free.fr>
Message-ID: <20081123151541.5332b42c@ohm.scrye.com>

On Tue, 18 Nov 2008 20:19:39 +0100
pertusus at free.fr (Patrice Dumas) wrote:

> What I asked for was to setup a page in the Policy group that would
> explain the bugzilla policy.

Yes, if someone from Bugzappers could add a section on it to 
https://fedoraproject.org/wiki/PackageMaintainers/Policy
I think that would be great. Possibly near/on the EOL policy area?

> 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/20081123/2f0f544f/attachment.sig>

From nicolas.mailhot at laposte.net  Sun Nov 23 22:17:42 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 23 Nov 2008 23:17:42 +0100
Subject: where's the wish list for F11?
In-Reply-To: <ggcitd$bm8$1@ger.gmane.org>
References: <gg4dm5$ts1$1@ger.gmane.org>
	<alpine.LFD.2.00.0811201455510.16994@localhost.localdomain>
	<gg554h$6mi$1@ger.gmane.org>	<20081121094044.GA24555@mokona.greysector.net>
	<1227263653.9545.18.camel@arekh.okg>
	<20081121112829.GC24555@mokona.greysector.net>
	<1227270285.9545.27.camel@arekh.okg>	<gg6ifb$490$1@ger.gmane.org>
	<1227284001.13179.14.camel@arekh.okg> <gg7tnl$481$1@ger.gmane.org>
	<49285293.4060305@robertoragusa.it>  <ggcitd$bm8$1@ger.gmane.org>
Message-ID: <1227478662.27594.2.camel@arekh.okg>

Le dimanche 23 novembre 2008 ? 16:45 -0500, sean darcy a ?crit :

> OK, so I set up local.conf in /etc/fonts. Then what? 

Then you need to rebuild your fontconfig cache or you'll have very weird
effects in apps.

Then you need to tell fontconfig how to classify each font if you want
apps like firefox to use them in the right place

Then you probably need nothing else, except you've done 80% of the work
creating a proper package without getting something you can reinstall or
tweak at need.

-- 
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/20081123/b812a23e/attachment.sig>

From kevin at scrye.com  Sun Nov 23 22:36:15 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Sun, 23 Nov 2008 15:36:15 -0700
Subject: PackageMaintainers/Policy/EncourageComaintainership is out of
 date
In-Reply-To: <20081116173146.GG2933@free.fr>
References: <20081116173146.GG2933@free.fr>
Message-ID: <20081123153615.5a16a993@ohm.scrye.com>

On Sun, 16 Nov 2008 18:31:46 +0100
pertusus at free.fr (Patrice Dumas) wrote:

> Hello,
> 
> https://fedoraproject.org/wiki/PackageMaintainers/Policy/EncourageComaintainership
> is badly out of date. It doesn't incorporate changes corresponding
> with changes in infra (bohdi, packageDB, ACL) and more recent changes
> with provenpackager and packager split and corresponding ACL opening.

I made a stab at cleaning it up some. 
Comments welcome. 

> 
> Also there are things that looks old in that page, like
> https://fedoraproject.org/wiki/PackageMaintainers/Policy/EncourageComaintainership#Coordination_between_maintainers

Well, it surely doesn't seem like anyone is using that that I know
of...  I don't know that it's old, just not used much. 

> 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/20081123/f967b24c/attachment.sig>

From kevin at scrye.com  Sun Nov 23 22:49:56 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Sun, 23 Nov 2008 15:49:56 -0700
Subject: F11: things to check in a release tree before a release
In-Reply-To: <20081120124252.885c1847.mschwendt@gmail.com>
References: <alpine.LFD.2.00.0811191547010.10340@localhost.localdomain>
	<20081119222235.699e4437.mschwendt@gmail.com>
	<alpine.LFD.2.00.0811191628050.10340@localhost.localdomain>
	<20081119223810.a43dfa41.mschwendt@gmail.com>
	<20081119220328.GA1371485@hiwaay.net>
	<20081120002409.16768218.mschwendt@gmail.com>
	<alpine.LFD.2.00.0811191851130.10340@localhost.localdomain>
	<20081120124252.885c1847.mschwendt@gmail.com>
Message-ID: <20081123154956.1c610716@ohm.scrye.com>

On Thu, 20 Nov 2008 12:42:52 +0100
mschwendt at gmail.com (Michael Schwendt) wrote:

> That worked fine till bug-triagers threatened to close bugzilla
> tickets because of dist EOL and then mass-closed them later. Too much
> extra burden -- having to revisit tickets and verify the issues and
> likely doing it again next EOL is reached.
> 
> What was missing is a script to maintain the bugzilla ticket numbers,
> to detect fixed packages (which no longer appear on the list), to
> help with closing tickets, and to add reminders to the tickets
> automatically.
> 
> And, of course, official backup from FESCo would be nice and helpful,
> too. Else it's not worthwhile to file such tickets. Because packagers
> may decide for themselves whether they consider an issue important
> enough (even if it causes real problems, which are reproducible in Yum
> installation scenarios).

Thinking about this, and with recent events, I wonder if we shouldn't
have some kind of standard way to treat mass issues like: 

- FTBFS

- Source url issues

- Provides/Requires issues. 

- Conflicting files. 

- Broken EVR between releases. 

- Initscripts enabled by default. 

- Summary needs re-writing. 

- Spec otherwise not up to current specs. 

Currently, these sorts of things take several tacks:

- Just post to devel list and hope maintainer fixes them. 
* Many maintainers don't read or notice their package in the sea of
other posts. 

- Mail maintainer directly and hope they fix them. 
* Maintainers might ignore, drop, mean to fix later but forget, etc. 

- File bugzilla bugs. 
* Have to keep maintaining them so they don't drop off EOL
* Lots of overhead in filing and managing. 

It seems that we go through this kind of thing every once in a while,
and some kind of standard way might be worth figuring out. 
Perhaps there is a scale where we might have something like FESCo
decide: 

A) This is a simple, needed fix, it's clear how to fix it with a script.
Just mass fix all packages in CVS. 

B) This fix is minor, collect all minor issues and mail
maintainers/devel list once a month or something with a summary of
them. One email with all issues and clearly indicating the package,
etc. Perhaps have just a pointer to a web page listing all the issues
for each package?

C) This fix is complicated, needs maintainer to deal with. File bug and
make sure it's tracked. if not fixed by needed time, drop package or
escalate. 

D) Tie checks where they can be automated into the cvs commits or other
points, so notifications are emailed out to maintainers right after
they do a checkin. This would only work with minor items that are easy
to catch in a script. 

E) Your clever idea here. 

I know how much people hate more red tape, but having a policy to
follow for these should prevent maintainers from being annoyed by mass
mailings and other such things. 

thoughts?

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/20081123/9efafbc2/attachment.sig>

From kevin at scrye.com  Sun Nov 23 22:51:32 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Sun, 23 Nov 2008 15:51:32 -0700
Subject: source file audit - 2008-11-14
In-Reply-To: <870180fe0811200851r1c6b0273p36cea25a000c2305@mail.gmail.com>
References: <20081119170909.29694973@ohm.scrye.com>
	<870180fe0811191637q372240f6w893781e4b0d7fce5@mail.gmail.com>
	<20081119224602.01d369a5@ohm.scrye.com>
	<870180fe0811200851r1c6b0273p36cea25a000c2305@mail.gmail.com>
Message-ID: <20081123155132.2b17ef56@ohm.scrye.com>

On Thu, 20 Nov 2008 09:51:51 -0700
loganjerry at gmail.com ("Jerry James") wrote:

> On 2008/11/19 Kevin Fenzi <kevin at scrye.com> wrote:
> > On Wed, 19 Nov 2008 17:37:43 -0700
> > loganjerry at gmail.com ("Jerry James") wrote:
> >
> >> On 2008/11/19 Kevin Fenzi <kevin at scrye.com> wrote:
> >> > jjames:BADURL:check-0.9.5.tar.gz:check
> >>
> >> Sure enough, I'm getting an HTTP 403 on this.  Will investigate.
> 
> And this one is working today.  Temporary sourceforge hiccup?

--21:40:05--  http://download.sourceforge.net/check/check-0.9.5.tar.gz
Resolving download.sourceforge.net... 128.101.240.209, 150.65.7.130, 213.186.33.91, ...
Connecting to download.sourceforge.net|128.101.240.209|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 520625 (508K) [application/x-gzip]
Remote file is newer, retrieving.

--21:42:01--  http://download.sourceforge.net/check/check-0.9.5.tar.gz
Connecting to download.sourceforge.net|128.101.240.209|:80... connected.
HTTP request sent, awaiting response... 504 Gateway Time-out
21:45:01 ERROR 504: Gateway Time-out.

Yep. Looks like. ;( 
Sorry for the false positive. 

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/20081123/f638ac93/attachment.sig>

From kevin at scrye.com  Sun Nov 23 22:54:21 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Sun, 23 Nov 2008 15:54:21 -0700
Subject: source file audit - 2008-11-14
In-Reply-To: <1227174473.1241.2539.camel@vain.rhgalway>
References: <20081119170909.29694973@ohm.scrye.com>
	<1227174473.1241.2539.camel@vain.rhgalway>
Message-ID: <20081123155421.22371dda@ohm.scrye.com>

On Thu, 20 Nov 2008 09:47:53 +0000
caolanm at redhat.com (Caol?n McNamara) wrote:

> On Wed, 2008-11-19 at 17:09 -0700, Kevin Fenzi wrote:
> 
> > caolanm:BADSOURCE:writer2latex0502.zip:writer2latex
> > caolanm:BADSOURCE:icu4c-4_0-src.tgz:icu
> > caolanm:BADSOURCE:myspell-af_ZA-20060117.zip:hunspell-af
> > caolanm:BADSOURCE:myspell-nr_ZA-20060120.zip:hunspell-nr
> 
> With these ones upstream repacked the sources (bah), so it's great
> to get the notification that they changed.

Good. ;) 

> > caolanm:BADSOURCE:OOo-Thesaurus2-sk_SK.zip:mythes-sk
> > caolanm:BADSOURCE:thes_de_DE_v2.zip:mythes-de
> > caolanm:BADURL:sjp-myspell-pl-20080823.zip:hunspell-pl
> 
> With these ones though, the problem is that (with many dictionary and
> thesaurus projects) upstream either rolls along continuously making
> (sometimes daily) refreshes with new words and meanings, either 
> reusing the same tarball name (BADSOURCE), or a date based one where
> after a certain time the old one is removed (BADURL). 
> 
> So is it better practice for me in these cases to keep a full Source:
> link correct as to the time of packaging, or better to chop off the
> path and just leave the basename so they get skipped from the audit
> test ? FWIW in my own "see if there have been newer releases" script
> I have them tagged as date-base releases with a one month window
> before they are marked as having a newer release available.

Well, not sure. I can also blacklist them from being checked if you
like. I guess it depends on if you want me to nag you next time so you
can go and check and see whats going on, or want me to leave you alone
since you have your own script. ;) 

I don't suppose upstream might change practices here?

> C.

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/20081123/77cb8c8e/attachment.sig>

From kevin at scrye.com  Sun Nov 23 22:58:07 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Sun, 23 Nov 2008 15:58:07 -0700
Subject: source file audit - 2008-11-14
In-Reply-To: <20081120124919.da168a5f.mschwendt@gmail.com>
References: <20081119170909.29694973@ohm.scrye.com>
	<20081120124919.da168a5f.mschwendt@gmail.com>
Message-ID: <20081123155807.16e57e01@ohm.scrye.com>

On Thu, 20 Nov 2008 12:49:19 +0100
mschwendt at gmail.com (Michael Schwendt) wrote:

> On Wed, 19 Nov 2008 17:09:09 -0700, Kevin Fenzi wrote:
> 
> > mschwendt:BADURL:audacious-plugin-fc-0.3.tar.bz2:audacious-plugin-fc
> 
> Here I see room for improving the script. As the SourceForge download
> locations change often, could you check the Source URL against a
> template that is recommended somewhere in the depths of the Fedora
> Project Wiki?

Yeah, I could try and do so... good idea. 
The script is currently a hacky litting shell script. 
You can find it at: 
http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck

It probibly should just be reimplemented at some point, but it does
work now. Changes/patches/reimplemented scripts welcome. ;)

> wget
> http://download.sourceforge.net/xmms-fc/audacious-plugin-fc-0.3.tar.bz2
> used to work in round-robin fashion, but currently hangs because it
> cannot connect.

Yeah, the script got: 

--18:49:02--  http://download.sourceforge.net/xmms-fc/audacious-plugin-fc-0.3.tar.bz2
Resolving download.sourceforge.net... 150.65.7.130, 128.101.240.209, 193.1.219.87, ...
Connecting to download.sourceforge.net|150.65.7.130|:80... connected.
HTTP request sent, awaiting response... 504 Gateway Time-out
18:52:02 ERROR 504: Gateway Time-out.

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/20081123/53adfd8f/attachment.sig>

From kevin at scrye.com  Sun Nov 23 23:03:45 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Sun, 23 Nov 2008 16:03:45 -0700
Subject: source file audit - 2008-11-14
In-Reply-To: <200811201054.48829.opensource@till.name>
References: <20081119170909.29694973@ohm.scrye.com>
	<200811201054.48829.opensource@till.name>
Message-ID: <20081123160345.33951850@ohm.scrye.com>

On Thu, 20 Nov 2008 10:54:43 +0100
opensource at till.name (Till Maas) wrote:

> On Thu November 20 2008, Kevin Fenzi wrote:
> 
> > orphan:BADSOURCE:gst-plugins-0.8.12.tar.bz2:gstreamer08-plugins
> > orphan:BADSOURCE:kbiof-0.3.tar.gz:kbiof
> > orphan:BADURL:gaim-galago-0.5.1.tar.bz2:purple-galago
> > orphan:BADURL:gnome-blog-0.9.1.tar.bz2:gnome-blog
> > orphan:BADURL:gnome-yum-0.1.4.tar.gz:gnome-yum
> > orphan:BADURL:kbackup-0.5.4.tar.bz2:kbackup
> > orphan:BADURL:moomps-5.8.tar.bz2:moomps
> > orphan:BADURL:new-1.3.9.tar.gz:new
> > orphan:BADURL:pam-script-0.1.7.tar.gz:pam_script
> > orphan:BADURL:pam_usb-0.4.0.tar.gz:pam_usb
> > orphan:BADURL:pekwm-0.1.5.tar.bz2:pekwm
> > orphan:BADURL:TPG-3.1.2.tar.gz:python-tpg
> > orphan:BADURL:tvn24_0.2.8-1.tar.gz:gnome-applet-tvn24
> 
> Are these maybe orphaned?

Yes. :) 
However, they have not been marked 'dead.package'. 
So, either the maintainer who orphaned them didn't do that, or the
expectation was that someone would pick them up soon. 

> > till:BADURL:aircrack-ng-1.0-20081109.tar.gz:aircrack-ng
> 
> This is a svn snapshot, therefore there is no URL available. Is there
> some way to indicate this to your script? Another SourceX of this
> package is aircrack-ng-tarball which is a script that can be used to
> generate the snapshot. I spotted some more packages in the list that
> contain a date in their tarball and therefore are probably snapshot
> releases.

if it's a snapshot, why does it have a URL?
It currently is: 
Source0:
http://download.aircrack-ng.org/aircrack-ng-%{version}-%{alphatag}.tar.gz

But it should just be: 
Source0: aircrack-ng-%{version}-%{alphatag}.tar.gz

And have a commented section above describing how it was generated. 

> Regards,
> Till

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/20081123/571bf150/attachment.sig>

From kevin at scrye.com  Sun Nov 23 23:15:43 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Sun, 23 Nov 2008 16:15:43 -0700
Subject: source file audit - 2008-11-14
In-Reply-To: <1227225673.26058.187.camel@localhost.localdomain>
References: <20081119170909.29694973@ohm.scrye.com>
	<1227225673.26058.187.camel@localhost.localdomain>
Message-ID: <20081123161543.47283eb0@ohm.scrye.com>

On Thu, 20 Nov 2008 19:01:13 -0500
tcallawa at redhat.com ("Tom \"spot\" Callaway") wrote:

> On Wed, 2008-11-19 at 17:09 -0700, Kevin Fenzi wrote:
> > spot:BADSOURCE:daa2iso.zip:daa2iso
> 
> Upstream doesn't embed version in their zip file, they just do new
> releases with the same filename, which causes this. I emailed them to
> ask them not to do that, but they replied that they like it like that.
> This also pointed out that upstream had done a new release, so I
> pushed an update.

:( 

...snipp...

> > spot:BADURL:alsamixergui-0.9.0rc1-2.tar.gz:alsamixergui
> 
> upstream website is gone.

I guess the Source0 should just be a filename now?

> > spot:BADURL:amanith_03.tar.gz:amanith
> 
> upstream is no longer working on this code and has taken it down.

Same here... no url, just a file now?

> > spot:BADURL:Class-DBI-Loader-Relationship-1.3.tar.gz:perl-Class-DBI-Loader-Relationship
> 
> Umm. I'm not sure how I ended up with a version that CPAN doesn't know
> about, but it seems legit.

ok. 

...snip...

> > spot:BADURL:google-perftools-0.99.1.tar.gz:google-perftools
> 
> I'm guessing this was due to your googlecode burping.

yep. I need to get spectool to not use wget -N it seems. ;( 

...snipp..

> > spot:BADURL:kscope-1.6.2.tar.gz:kscope
> 
> Dunno why this one flagged, it all looks good to me.

Looks like a sourceforge redirecting to some other site: 

--20:25:02--  http://download.sourceforge.net/kscope/kscope-1.6.2.tar.gz
Resolving download.sourceforge.net... 128.101.240.209, 150.65.7.130, 212.219.56.167, ...
Connecting to download.sourceforge.net|128.101.240.209|:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: http://mir1.ovh.net/kscope/kscope-1.6.2.tar.gz [following]
--20:25:03--  http://mir1.ovh.net/kscope/kscope-1.6.2.tar.gz
Resolving mir1.ovh.net... 213.186.33.37
Connecting to mir1.ovh.net|213.186.33.37|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
20:25:03 ERROR 404: Not Found.

...snipp...

> > spot:BADURL:libmcrypt-2.5.8.tar.gz:libmcrypt
> 
> Not sure why this failed, it all looks good on my end.

Another sourceforge hiccup. ;( 
--22:25:25--  http://download.sourceforge.net/mcrypt/libmcrypt-2.5.8.tar.gz
Resolving download.sourceforge.net... 128.101.240.209, 150.65.7.130, 198.142.1.17, ...
Connecting to download.sourceforge.net|128.101.240.209|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
22:25:26 ERROR 404: Not Found.

...snipp...

> > spot:BADURL:pydot-1.0.2.tar.gz:pydot
> 
> Googlecode, looks fine on my end.

yep. 

...snipp...

> > spot:BADURL:ser2net-2.5.tar.gz:ser2net
> 
> Dunno why this one flagged, it all looks good to me.

Sourceforge hiccup: 
--15:01:27--  http://download.sourceforge.net/ser2net/ser2net-2.5.tar.gz
Resolving download.sourceforge.net... 128.101.240.209, 150.65.7.130, 193.1.219.87, ...
Connecting to download.sourceforge.net|128.101.240.209|:80... connected.
HTTP request sent, awaiting response... 504 Gateway Time-out
15:04:26 ERROR 504: Gateway Time-out.

> Thanks,

Thanks for fixing so many things so quickly. ;) 

> ~spot

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/20081123/5caf538b/attachment.sig>

From bashton at brennanashton.com  Sun Nov 23 23:19:00 2008
From: bashton at brennanashton.com (Brennan Ashton)
Date: Sun, 23 Nov 2008 15:19:00 -0800
Subject: BugZappers/HouseKeeping is a policy and seems incomplete
In-Reply-To: <20081123151541.5332b42c@ohm.scrye.com>
References: <20081116160839.GC2933@free.fr>
	<da159fda0811161621y4847991bn8a87c1807d0fec29@mail.gmail.com>
	<20081118191939.GB2610@free.fr>
	<20081123151541.5332b42c@ohm.scrye.com>
Message-ID: <981da310811231519i58b2f9b8t68c31ab769aff8d1@mail.gmail.com>

2008/11/23 Kevin Fenzi <kevin at scrye.com>:
> On Tue, 18 Nov 2008 20:19:39 +0100
> pertusus at free.fr (Patrice Dumas) wrote:
>
>> What I asked for was to setup a page in the Policy group that would
>> explain the bugzilla policy.
>
> Yes, if someone from Bugzappers could add a section on it to
> https://fedoraproject.org/wiki/PackageMaintainers/Policy
> I think that would be great. Possibly near/on the EOL policy area?

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?

--Brennan Ashton



From kevin at scrye.com  Sun Nov 23 23:20:34 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Sun, 23 Nov 2008 16:20:34 -0700
Subject: source file audit - 2008-11-14
In-Reply-To: <1227232833.3202.19.camel@tuxhugs>
References: <20081119170909.29694973@ohm.scrye.com>
	<1227232833.3202.19.camel@tuxhugs>
Message-ID: <20081123162034.11532864@ohm.scrye.com>

On Thu, 20 Nov 2008 18:00:33 -0800
peter at thecodergeek.com (Peter Gordon) wrote:

> On Wed, 2008-11-19 at 17:09 -0700, Kevin Fenzi wrote:
> > pgordon:BADSOURCE:curvylooks-0.3.gtp:gnome-theme-curvylooks
> 
> Oops; this is my own project and I pulled a no-no a while back when I
> re-spun the tarball without changing the name (a minor fix to the
> Katakana spelling of "theme"). This is now fixed in CVS (all
> branches).

Great. 

> > pgordon:BADURL:empathy-2.24.1.tar.bz2:empathy
> 
> Fixed in CVS (devel)
> 
> > pgordon:BADURL:labyrinth-0.4.0.tar.bz2:labyrinth
> 
> Fixed in CVS (devel)
> 
> > pgordon:BADURL:libtorrent-rasterbar-0.13.1.tar.gz:rb_libtorrent
> 
> This is now moved to SourceForge's file hosting, but it only has the
> 0.14 tarball available. Upstream no longer has a 0.13.1 tarball
> available. I'm working through pushing a version bump for Rawhide (and
> potentially, release branches); but for the time being I've mirrored
> the older file on my personal webspace and changed the Source URLs in
> CVS (devel, F-10 branches) to point there instead of at upstream's
> now-defunct download location. I hope that will suffice, at least
> temporarily. 

Sure, or you can simply remove the URL part and just point to the
version in the cvs lookaside cache. 

> Thanks and regards for the wonderful script! :)

Thanks for fixing things. 

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/20081123/ae6649a1/attachment.sig>

From kevin at scrye.com  Sun Nov 23 23:22:19 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Sun, 23 Nov 2008 16:22:19 -0700
Subject: source file audit - 2008-11-14
In-Reply-To: <4926D94A.1020404@redhat.com>
References: <20081119170909.29694973@ohm.scrye.com>
	<4926D94A.1020404@redhat.com>
Message-ID: <20081123162219.24eddd30@ohm.scrye.com>

On Fri, 21 Nov 2008 09:52:42 -0600
sandeen at redhat.com (Eric Sandeen) wrote:

> Kevin Fenzi wrote:
> > Here's attached another run of my sources/patches url checker. 
> > Sorry for the delay in re-running this. 
> > 
> > Hopefully I will start running it again at the first of each month. 
> > 
> > - There are 912 lines in this run. Up from 662 last run.
> > This is a pretty sad increase. ;( 
> 
> Just an idea; should rpmlint check for bad source URLs?  And should
> that maybe get tied in to the commit/tag/build process somehow so you
> get more direct feedback?

Yeah, I would love to tie it into the checkin hooks. 
Hopefully we can have some means of doing this sometime. 

> I'm most likely to fix this stuff if I'm in the middle of making some
> other change, and an automatic check while I'm working on a package
> that says "hey your source URL is no longer valid" would probably
> provoke me to fix it quickly.  :)

Yeah, agreed. Ideally a pre-checkin check, but even a email after you
did a checkin would be nice and better than just running it once a
month. 

> -Eric

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/20081123/cd9e426b/attachment.sig>

From opensource at till.name  Sun Nov 23 23:29:14 2008
From: opensource at till.name (Till Maas)
Date: Mon, 24 Nov 2008 00:29:14 +0100
Subject: source file audit - 2008-11-14
In-Reply-To: <20081123160345.33951850@ohm.scrye.com>
References: <20081119170909.29694973@ohm.scrye.com>
	<200811201054.48829.opensource@till.name>
	<20081123160345.33951850@ohm.scrye.com>
Message-ID: <200811240029.21389.opensource@till.name>

On Mon November 24 2008, Kevin Fenzi wrote:
> On Thu, 20 Nov 2008 10:54:43 +0100
>
> opensource at till.name (Till Maas) wrote:

> However, they have not been marked 'dead.package'.
> So, either the maintainer who orphaned them didn't do that, or the
> expectation was that someone would pick them up soon.

A dead.package file only needs to be created for retired packages[1]. The 
orphaning procedures do no tell to create it:
https://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages#Orphaning_Procedure

> > > till:BADURL:aircrack-ng-1.0-20081109.tar.gz:aircrack-ng
> >
> > This is a svn snapshot, therefore there is no URL available. Is there
> > some way to indicate this to your script? Another SourceX of this
> > package is aircrack-ng-tarball which is a script that can be used to
> > generate the snapshot. I spotted some more packages in the list that
> > contain a date in their tarball and therefore are probably snapshot
> > releases.
>
> if it's a snapshot, why does it have a URL?
> It currently is:
> Source0:
> http://download.aircrack-ng.org/aircrack-ng-%{version}-%{alphatag}.tar.gz
>
> But it should just be:
> Source0: aircrack-ng-%{version}-%{alphatag}.tar.gz

Good catch. It was left over, because it used a snapshot from upstream before.

> And have a commented section above describing how it was generated.

I will add this, too. I believed that adding a appropriate script to generate 
the snapshot is enough, but there is no good default way to do so, therefore 
I will add a comment.

Regards,
Till

[1] https://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife
-------------- 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/20081124/f31fb76b/attachment.sig>

From Matt_Domsch at dell.com  Mon Nov 24 00:38:29 2008
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Sun, 23 Nov 2008 18:38:29 -0600
Subject: F11: things to check in a release tree before a release
In-Reply-To: <20081120124252.885c1847.mschwendt@gmail.com>
References: <alpine.LFD.2.00.0811191547010.10340@localhost.localdomain>
	<20081119222235.699e4437.mschwendt@gmail.com>
	<alpine.LFD.2.00.0811191628050.10340@localhost.localdomain>
	<20081119223810.a43dfa41.mschwendt@gmail.com>
	<20081119220328.GA1371485@hiwaay.net>
	<20081120002409.16768218.mschwendt@gmail.com>
	<alpine.LFD.2.00.0811191851130.10340@localhost.localdomain>
	<20081120124252.885c1847.mschwendt@gmail.com>
Message-ID: <20081124003829.GA30416@auslistsprd01.us.dell.com>

On Thu, Nov 20, 2008 at 12:42:52PM +0100, Michael Schwendt wrote:
> On Wed, 19 Nov 2008 18:51:43 -0500 (EST), Seth Vidal wrote:
> 
> > > If you really want to check all sorts of multiple Provides, that'll be
> > > a long list with a lot that must be white-listed.
> > 
> > I was thinking along the lines of we generate the list, manually check.
> > 
> > Then we work on generating diffs vs past lists for the future.
> > 
> > so we aren't constantly seeing the same stream of data.
> 
> Which is roughly what I've done: using "diff against previous" and a
> whitelist of package names for "valid virtual provides".
> 
> That worked fine till bug-triagers threatened to close bugzilla tickets
> because of dist EOL and then mass-closed them later. Too much extra burden
> -- having to revisit tickets and verify the issues and likely doing it
> again next EOL is reached.
> 
> What was missing is a script to maintain the bugzilla ticket numbers,
> to detect fixed packages (which no longer appear on the list), to help with
> closing tickets, and to add reminders to the tickets automatically.

FTBFS does this. :-)  The trick is, to have a tracking bug, against
which you have filed all the actual bugs.  Then you can ask bugzilla
for the tracking bug and those it is "blocked_on".  If you have bugs
show up on that list that your tool does not believe are bugs anymore,
those are your candidates for closure.

My FTBFS scripts are (mostly) posted at 
http://linux.dell.com/files/fedora/FixBuildRequires/
though I note that tarball is a bit stale.  If people are interested
in borrowing from these, I'll get an updated version posted.

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From debarshi.ray at gmail.com  Mon Nov 24 05:54:45 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Mon, 24 Nov 2008 11:24:45 +0530
Subject: libical: dropping C++ bindings
Message-ID: <3170f42f0811232154k149b225au1b641a3c25eb63a9@mail.gmail.com>

I am planning to disable the C++ bindings from libical-0.41 onwards.
The last time I had asked upstream, which was couple of months back,
they said that they knew of no user of the bindings and are not very
keen to maintain them. Moreover the Makefiles are broken causing a
number of undefined symbols to be present in the C++ bindings' shared
libraries. Patching the Makefile.ins with every release is not very
enjoyable, especially since upstream is not interested.

If someone is using or plans to use libical's C++ bindings then please
let me know.

Thanks,
Debarshi



From fedora at leemhuis.info  Mon Nov 24 06:43:43 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Mon, 24 Nov 2008 07:43:43 +0100
Subject: rawhide report: 20081123 changes
In-Reply-To: <20081123124303.D51D41F823B@releng2.fedora.phx.redhat.com>
References: <20081123124303.D51D41F823B@releng2.fedora.phx.redhat.com>
Message-ID: <492A4D1F.4060805@leemhuis.info>

On 23.11.2008 13:43, Rawhide Report wrote:
> Compose started at Sun Nov 23 06:01:06 UTC 2008
> 
> Summary:
> Added Packages: 0
> Removed Packages: 0
> Modified Packages: 0

Not sure, but once F10 was finished maybe it's would have been better to 
disable the rawhide pushes temporary until rawhide moves on again, as 
right now this happens when you enable the F10 updates repo on your 
rawhide system (which is a F10 right now; and I plan to stick to F10 for 
now):

> updates                                                                                | 2.3 kB     00:00     
> Not using downloaded repomd.xml because it is older than what we have:
>   Current   : Sun Nov 23 13:04:27 2008
>   Downloaded: Sat Nov 22 15:56:21 2008

I guess something similar will happen with the base repo.

In addition: Why does
http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f$releasever&arch=$basearch
still point to the rawhide repos? There are a lot of proper and test 
updates that IMHO could benefit from some testing before F10 hits the 
streets.

CU
knurd



From benjavalero at gmail.com  Mon Nov 24 08:38:21 2008
From: benjavalero at gmail.com (=?UTF-8?Q?Benjam=C3=ADn_Valero_Espinosa?=)
Date: Mon, 24 Nov 2008 09:38:21 +0100
Subject: Translating summary text of packages
Message-ID: <a7804a540811240038p72f15e65qcd76d21c28bf4831@mail.gmail.com>

About the need of reducing the size of the summary texts and giving that
info in the descriptions (and hoping PackageKit can search in them), what
about the translation of this texts? Uff, I know this would be a huge task
and I suppose it has been talked before, but as I see no summary translated
to Spanish... Perhaps that would make the database grow, but we could
translate just the summaries, that will soon be shorter and shorter :D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081124/47935e59/attachment.htm>

From tmraz at redhat.com  Mon Nov 24 10:14:25 2008
From: tmraz at redhat.com (Tomas Mraz)
Date: Mon, 24 Nov 2008 11:14:25 +0100
Subject: problems updating glibc
In-Reply-To: <5256d0b0811210914q758498fbxffe215edad4c8436@mail.gmail.com>
References: <5256d0b0811210527k2fcf1c46k2997c358cb1a3e07@mail.gmail.com>
	<200811210817.43276.dennis@ausil.us>
	<20081121150955.GA16736@amd.home.annexia.org>
	<5256d0b0811210914q758498fbxffe215edad4c8436@mail.gmail.com>
Message-ID: <1227521665.15714.103.camel@vespa.frost.loc>

On Fri, 2008-11-21 at 17:14 +0000, Peter Robinson wrote:
> >> > Hi All,
> >> >
> >> > I've seen mention of this (and actually saw it on another system of
> >> > mine but it settled down) where glibc-common can't update due to
> >> > glibc.
> >> >
> >> > The machine is a Fit-PC which runs on an AMD Geode. It currently has
> >> > the glibc version 2.8.90-14 i686 rpm and attempting to update to 2.9-2
> >> > it errors with "package glibc-2.9-2.i686 is intended for a i686
> >> > architecture" which seems weird given that its already running the
> >> > i686 version. Any ideas?
> >> a geode is not i686 compatiable,  it is a i586 cpu + cmov it really needs its
> >> own arch for glibc.  rpm and yum both now how to deal with .geode packages.
> >> openssl likely needs a .geode rpm also.  olpc has the same issue.  the images
> >> they use have i686 versions installed.
> >
> > I've got one of these crazy boxes too.  Although i686 packages can't
> > be installed, they _do_ seem to work if you force them.  Certainly all
> > the simple ones I tried anyway, although maybe I didn't try openssl.
> 
> I'm not sure, openSSH seems to use nss  now instead of openssl, but I
> would have thought they would both use similar CPU ops.

Small correction - s/instead of/in addition to/ in the previous
sentence.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From rodd at clarkson.id.au  Mon Nov 24 10:20:15 2008
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Mon, 24 Nov 2008 21:20:15 +1100
Subject: where's the wish list for F11?
In-Reply-To: <20081121094044.GA24555@mokona.greysector.net>
References: <gg4dm5$ts1$1@ger.gmane.org>
	<alpine.LFD.2.00.0811201455510.16994@localhost.localdomain>
	<gg554h$6mi$1@ger.gmane.org>
	<20081121094044.GA24555@mokona.greysector.net>
Message-ID: <1227522015.5353.5.camel@moose>

On Fri, 2008-11-21 at 10:40 +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Friday, 21 November 2008 at 03:07, sean darcy wrote:
> [...]
> > First, I'm a great yum fan. And you are the man. No irony or sarcasm.
> > 
> > But... I use a lot of 3rd party fonts that aren't open, like most 
> > designers. It's weird/strange/peculiar there's no system-config-fonts 
> > that would allow us to install them.
> 
> This calls for some font2spec script that'd create a spec file for your
> font and let you build a package from it easily, much like R2spec or
> cpan2rpm.

Can you still just copy the font files into ~/.fonts/ ?

This works (worked) for ttf fonts, but may or may not for type1 fonts.


R.
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From bnocera at redhat.com  Mon Nov 24 10:30:29 2008
From: bnocera at redhat.com (Bastien Nocera)
Date: Mon, 24 Nov 2008 10:30:29 +0000
Subject: F11: OSS and pulseaudio conflict
In-Reply-To: <1226702549.29933.2.camel@snoogens.fab.redhat.com>
References: <491DA325.3010305@redhat.com>
	<1226702549.29933.2.camel@snoogens.fab.redhat.com>
Message-ID: <1227522629.3675.2625.camel@cookie.hadess.net>

On Fri, 2008-11-14 at 23:42 +0100, Bastien Nocera wrote:
> On Fri, 2008-11-14 at 11:11 -0500, Warren Togami wrote:
> > I ran into an application yesterday that seemed to make pulseaudio
> > daemon fail.  After a lot of digging, someone else realized that this
> > application was actually using OSS output.  OSS currently grabs /dev/dsp
> > (provided by snd-pcm-oss), making it appear that pulseaudio has "failed".
> > 
> > OSS applications are so rare these days, I did not even consider that it
> > was using OSS.  This is likely to be a rare but repetitive source of
> > confusion in the future.
> 
> Just remove OSS support from the kernel. ALSA has been the default since
> the 2.6.0 kernel (that's 5 years ago), and even apps that use OSS
> emulation through ALSA will block any other use of the sound card
> (whether PulseAudio is present or not).
> 
> 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



From rawhide at fedoraproject.org  Mon Nov 24 11:22:40 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Mon, 24 Nov 2008 11:22:40 +0000 (UTC)
Subject: rawhide report: 20081124 changes
Message-ID: <20081124112240.7FBEA1F8252@releng2.fedora.phx.redhat.com>

Compose started at Mon Nov 24 06:01:09 UTC 2008

Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 0














From j.w.r.degoede at hhs.nl  Mon Nov 24 12:38:55 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Mon, 24 Nov 2008 13:38:55 +0100
Subject: Games SIG looking for new contributers
Message-ID: <492AA05F.7030404@hhs.nl>

Hi all,

Once up on a time I (and quite a few others) started out as Fedora contributor 
working mostly on games. Now I (and most others) have moved on contributing to 
other (more "serious") areas of Fedora. But there is still plenty to do on the 
Games front:
* The Games Spin which is looking for a maintainer,
* A growing list of games waiting to be packaged:
   http://fedoraproject.org/wiki/SIGs/Games/WishList
* Some game packages which could use some love, for example from some
   games the sound effects were removed because they are non free, there are
   plenty of free replacement sounds out there, but we need someone to go and
   search for a set of them matching the requirements for the game (blobwars,
   blobAndConquer and others)

I'm hereby offering help to anyone who wants to start contributing to the Games 
SIG (new or exising contributers), this help includes reviewing new packages, 
sponsoring, etc.

Regards,

Hans



From jani at mikkonen.biz  Mon Nov 24 12:48:17 2008
From: jani at mikkonen.biz (Jani Mikkonen)
Date: Mon, 24 Nov 2008 14:48:17 +0200
Subject: Games SIG looking for new contributers
In-Reply-To: <492AA05F.7030404@hhs.nl>
References: <492AA05F.7030404@hhs.nl>
Message-ID: <a36741370811240448o6ef8fea7g486760f493b2eb8@mail.gmail.com>

As i've talked to Hans already about this, i want to mention that  i
got some games packaged already from the wishlist and due to work
related time restraints havent had the time to yet put the stuff thru
to review cycle.  I have no time to commit to take full maintainer
status nor i dont think i have enough expertice either but just fyi,
if there will be new maintainer, i've volunteered to start submitting
packages.



From musuruan at gmail.com  Mon Nov 24 13:10:25 2008
From: musuruan at gmail.com (Andrea Musuruane)
Date: Mon, 24 Nov 2008 14:10:25 +0100
Subject: Games SIG looking for new contributers
In-Reply-To: <a36741370811240448o6ef8fea7g486760f493b2eb8@mail.gmail.com>
References: <492AA05F.7030404@hhs.nl>
	<a36741370811240448o6ef8fea7g486760f493b2eb8@mail.gmail.com>
Message-ID: <29fee02b0811240510n5415df26kde1f12aebe7e2d0a@mail.gmail.com>

2008/11/24 Jani Mikkonen <jani at mikkonen.biz>:
> As i've talked to Hans already about this, i want to mention that  i
> got some games packaged already from the wishlist and due to work
> related time restraints havent had the time to yet put the stuff thru
> to review cycle.  I have no time to commit to take full maintainer
> status nor i dont think i have enough expertice either but just fyi,
> if there will be new maintainer, i've volunteered to start submitting
> packages.

What games have you packages? Can you upload src.rpm somewhere on the
net? Thus maybe some other developers can use these as a base and they
won't start from scratch.

Regards,

Andrea.



From limb at jcomserv.net  Mon Nov 24 13:40:32 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Mon, 24 Nov 2008 07:40:32 -0600 (CST)
Subject: Games SIG looking for new contributers
In-Reply-To: <29fee02b0811240510n5415df26kde1f12aebe7e2d0a@mail.gmail.com>
References: <492AA05F.7030404@hhs.nl>
	<a36741370811240448o6ef8fea7g486760f493b2eb8@mail.gmail.com>
	<29fee02b0811240510n5415df26kde1f12aebe7e2d0a@mail.gmail.com>
Message-ID: <922f91d0e205cb268a726d1add8019a9.squirrel@mail.jcomserv.net>


> 2008/11/24 Jani Mikkonen <jani at mikkonen.biz>:
>> As i've talked to Hans already about this, i want to mention that  i
>> got some games packaged already from the wishlist and due to work
>> related time restraints havent had the time to yet put the stuff thru
>> to review cycle.  I have no time to commit to take full maintainer
>> status nor i dont think i have enough expertice either but just fyi,
>> if there will be new maintainer, i've volunteered to start submitting
>> packages.
>
> What games have you packages? Can you upload src.rpm somewhere on the
> net? Thus maybe some other developers can use these as a base and they
> won't start from scratch.

I'd be glad to see this too.  I'd be happy to polish, submit and maintain
some.

> Regards,
>
> Andrea.
>
> --
> 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 mike at miketc.net  Mon Nov 24 15:05:11 2008
From: mike at miketc.net (Mike Chambers)
Date: Mon, 24 Nov 2008 09:05:11 -0600
Subject: Rawhide = F10?
Message-ID: <1227539111.3333.3.camel@scrappy.miketc.net>

If you install rawhide as of today, and then run updates and/or testing
would you have F10?

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



From jos at xos.nl  Mon Nov 24 15:11:13 2008
From: jos at xos.nl (Jos Vos)
Date: Mon, 24 Nov 2008 16:11:13 +0100
Subject: No X on F9/F10 with Intel 82915G/GV/910GL
Message-ID: <200811241511.mAOFBDo0019062@jasmine.xos.nl>

Hi,

On a somewhat special piece of hardware (point-of-sale hardware) where
I can successfully run RHEL4 and RHEL5, I can't get F9 or F10 working
w.r.t. graphics.  That is, I just get a black screen, X doesn't die!
I've now installed F10 (text mode installer).

I did not try Fedora on that hardware until recently and after it failed,
I decided to wait till F10, without luck.

The "lspci -v" output for the VGA card is:

00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL Integrated Graphics Controller (rev 0e) (prog-if 00 [VGA controller])
        Subsystem: Intel Corporation 82915G/GV/910GL Integrated Graphics Controller
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at fdf00000 (32-bit, non-prefetchable) [size=512K]
        I/O ports at ff00 [size=8]
        Memory at d0000000 (32-bit, prefetchable) [size=256M]
        Memory at fdf80000 (32-bit, non-prefetchable) [size=256K]
        Capabilities: [d0] Power Management version 2
        Kernel modules: intelfb

The last "(EE)" message from Xorg.0.log is:

    (EE) intel(0): Bad VBT signature

I can send the full Xorg.0.log if needed, but I didn't want to spam
the list with that right now.

Any suggestions?  

Thanks,

--
--    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 bruno at wolff.to  Mon Nov 24 15:14:39 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Mon, 24 Nov 2008 09:14:39 -0600
Subject: Rawhide = F10?
In-Reply-To: <1227539111.3333.3.camel@scrappy.miketc.net>
References: <1227539111.3333.3.camel@scrappy.miketc.net>
Message-ID: <20081124151439.GA1298@wolff.to>

On Mon, Nov 24, 2008 at 09:05:11 -0600,
  Mike Chambers <mike at miketc.net> wrote:
> If you install rawhide as of today, and then run updates and/or testing
> would you have F10?

Today's rawhide is still F10.



From schaiba at gmail.com  Mon Nov 24 15:16:52 2008
From: schaiba at gmail.com (Aioanei Rares)
Date: Mon, 24 Nov 2008 17:16:52 +0200
Subject: No X on F9/F10 with Intel 82915G/GV/910GL
In-Reply-To: <200811241511.mAOFBDo0019062@jasmine.xos.nl>
References: <200811241511.mAOFBDo0019062@jasmine.xos.nl>
Message-ID: <778179b00811240716l1331e4afga6f742b87cfd42f3@mail.gmail.com>

On Mon, Nov 24, 2008 at 5:11 PM, Jos Vos <jos at xos.nl> wrote:

> Hi,
>
> On a somewhat special piece of hardware (point-of-sale hardware) where
> I can successfully run RHEL4 and RHEL5, I can't get F9 or F10 working
> w.r.t. graphics.  That is, I just get a black screen, X doesn't die!
> I've now installed F10 (text mode installer).
>
> I did not try Fedora on that hardware until recently and after it failed,
> I decided to wait till F10, without luck.
>
> The "lspci -v" output for the VGA card is:
>
> 00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL
> Integrated Graphics Controller (rev 0e) (prog-if 00 [VGA controller])
>        Subsystem: Intel Corporation 82915G/GV/910GL Integrated Graphics
> Controller
>        Flags: bus master, fast devsel, latency 0, IRQ 16
>        Memory at fdf00000 (32-bit, non-prefetchable) [size=512K]
>        I/O ports at ff00 [size=8]
>        Memory at d0000000 (32-bit, prefetchable) [size=256M]
>        Memory at fdf80000 (32-bit, non-prefetchable) [size=256K]
>        Capabilities: [d0] Power Management version 2
>        Kernel modules: intelfb
>
> The last "(EE)" message from Xorg.0.log is:
>
>    (EE) intel(0): Bad VBT signature
>
> I can send the full Xorg.0.log if needed, but I didn't want to spam
> the list with that right now.
>
> Any suggestions?
>
> Thanks,
>
> --
> --    Jos Vos <jos at xos.nl>
> --    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
> --    Amsterdam, The Netherlands        |     Fax: +31 20 6948204
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


Try vesa.
-- 
Aioanei Rares
schaiba at fedoraproject.org
"China is a big country, inhabited by many Chinese." --Charles de Gaulle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081124/3e7ee3ff/attachment.htm>

From jos at xos.nl  Mon Nov 24 15:43:43 2008
From: jos at xos.nl (Jos Vos)
Date: Mon, 24 Nov 2008 16:43:43 +0100
Subject: No X on F9/F10 with Intel 82915G/GV/910GL
In-Reply-To: <778179b00811240716l1331e4afga6f742b87cfd42f3@mail.gmail.com>
References: <200811241511.mAOFBDo0019062@jasmine.xos.nl>
	<778179b00811240716l1331e4afga6f742b87cfd42f3@mail.gmail.com>
Message-ID: <20081124154343.GA16527@jasmine.xos.nl>

On Mon, Nov 24, 2008 at 05:16:52PM +0200, Aioanei Rares wrote:

> Try vesa.

Does not work either:

(II) Loading /usr/lib64/xorg/modules//libint10.so
(II) Module int10: vendor="X.Org Foundation"
        compiled for 1.5.3, module version = 1.0.0
        ABI class: X.Org Video Driver, version 4.1
(II) VESA(0): initializing int10
(WW) VESA(0): Bad V_BIOS checksum
(II) VESA(0): Primary V_BIOS segment is: 0xc000
c000:2719: 01 ILLEGAL EXTENDED X86 OPCODE!
(II) VESA(0): VESA BIOS not detected

This remembers me to the fact that I had once submitted 

   https://bugzilla.redhat.com/show_bug.cgi?id=339361

That was closed because I didn't have HW free for further testing.
This is similar, although at that time it gave this problem for
the i810 driver.

I tried to install 32-bit F10, but the graphical installer doesn't
work either.  I can install that in text mode, to see what happens
afterwards.

-- 
--    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 dcbw at redhat.com  Mon Nov 24 16:00:37 2008
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 24 Nov 2008 11:00:37 -0500
Subject: NetworkManager cli docs
In-Reply-To: <1227447232.3721.1.camel@sb-home>
References: <1227447232.3721.1.camel@sb-home>
Message-ID: <1227542437.564.24.camel@localhost.localdomain>

On Sun, 2008-11-23 at 14:33 +0100, nodata wrote:
> Hi,
> 
> Can anyone point me at the docs for configuring NetworkManager without
> the tray applet?
> 
> I've tried google, the gnome.org nm page, and the man pages. I can't
> find a thing.

NetworkManager provides a D-Bus API for controlling network connections,
as seen here:  http://people.redhat.com/dcbw/NetworkManager/spec.html .

For setting up network connections without a user settings service,
NetworkManager provides a system-wide settings service which reads
ifcfg-* files like you'd normally create on Fedora.  Be sure to set
NM_CONTROLLED=yes, and NetworkManager should pick them up and use them
as long as ONBOOT=yes (which means bring it up automatically).

Dan




From davidz at redhat.com  Mon Nov 24 16:35:18 2008
From: davidz at redhat.com (David Zeuthen)
Date: Mon, 24 Nov 2008 11:35:18 -0500
Subject: orphaning gnome-volume-manager
Message-ID: <1227544518.11161.19.camel@x61.fubar.dk>

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.

This has been a public service announcement.

     David




From ajax at redhat.com  Mon Nov 24 16:50:24 2008
From: ajax at redhat.com (Adam Jackson)
Date: Mon, 24 Nov 2008 11:50:24 -0500
Subject: No X on F9/F10 with Intel 82915G/GV/910GL
In-Reply-To: <200811241511.mAOFBDo0019062@jasmine.xos.nl>
References: <200811241511.mAOFBDo0019062@jasmine.xos.nl>
Message-ID: <1227545424.23765.19.camel@atropine.boston.devel.redhat.com>

On Mon, 2008-11-24 at 16:11 +0100, Jos Vos wrote:

> The last "(EE)" message from Xorg.0.log is:
> 
>     (EE) intel(0): Bad VBT signature
> 
> I can send the full Xorg.0.log if needed, but I didn't want to spam
> the list with that right now.

Typically the VBT signature doesn't mean much.  But yes, full log would
be interesting.

- 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/20081124/684f928c/attachment.sig>

From jos at xos.nl  Mon Nov 24 16:57:46 2008
From: jos at xos.nl (Jos Vos)
Date: Mon, 24 Nov 2008 17:57:46 +0100
Subject: No X on F9/F10 with Intel 82915G/GV/910GL
In-Reply-To: <1227545424.23765.19.camel@atropine.boston.devel.redhat.com>
References: <200811241511.mAOFBDo0019062@jasmine.xos.nl>
	<1227545424.23765.19.camel@atropine.boston.devel.redhat.com>
Message-ID: <20081124165746.GA20250@jasmine.xos.nl>

On Mon, Nov 24, 2008 at 11:50:24AM -0500, Adam Jackson wrote:

> Typically the VBT signature doesn't mean much.  But yes, full log would
> be interesting.

I tried with 32-bit: still no graphics.

Attached:
- Xorg.0.log.vesa (no xorg.conf or xorg.conf specifying "vesa") and
- Xorg.0.log.intel (with xorg.conf specifying "intel").

This is all on 32-bit F10 (final release).

-- 
--    Jos Vos <jos at xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204
-------------- next part --------------

X.Org X Server 1.5.3
Release Date: 5 November 2008
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.18-92.1.10.el5 i686 
Current Operating System: Linux louie.xos.nl 2.6.27.5-117.fc10.i686 #1 SMP Tue Nov 18 12:19:59 EST 2008 i686
Build Date: 16 November 2008  08:29:02PM
Build ID: xorg-x11-server 1.5.3-5.fc10 
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Mon Nov 24 17:08:18 2008
(==) Using config file: "/etc/X11/xorg.conf"
(==) No Layout section.  Using the first Screen section.
(==) No screen section available. Using defaults.
(**) |-->Screen "Default Screen Section" (0)
(**) |   |-->Monitor "<default monitor>"
(==) No device specified for screen "Default Screen Section".
	Using the first device section listed.
(**) |   |-->Device "Videocard0"
(==) No monitor specified for screen "Default Screen Section".
	Using a default monitor configuration.
(==) Automatically adding devices
(==) Automatically enabling devices
(==) No FontPath specified.  Using compiled-in default.
(==) FontPath set to:
	catalogue:/etc/X11/fontpath.d,
	built-ins
(==) ModulePath set to "/usr/lib/xorg/modules"
(II) Cannot locate a core pointer device.
(II) Cannot locate a core keyboard device.
(II) The server relies on HAL to provide the list of input devices.
	If no devices become available, reconfigure HAL or disable AllowEmptyInput.
(II) Open ACPI successful (/var/run/acpid.socket)
(II) Loader magic: 0x81f4400
(II) Module ABI versions:
	X.Org ANSI C Emulation: 0.4
	X.Org Video Driver: 4.1
	X.Org XInput driver : 2.1
	X.Org Server Extension : 1.1
	X.Org Font Renderer : 0.6
(II) Loader running on linux
(--) using VT number 7

(--) PCI:*(0 at 0:2:0) Intel Corporation 82915G/GV/910GL Integrated Graphics Controller rev 14, Mem @ 0xfdf00000/0, 0xd0000000/0, 0xfdf80000/0, I/O @ 0x0000ff00/0
(II) System resource ranges:
	[0] -1	0	0xffffffff - 0xffffffff (0x1) MX[B]
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[5] -1	0	0x00000000 - 0x00000000 (0x1) IX[B]
(II) LoadModule: "extmod"

(II) Loading /usr/lib/xorg/modules/extensions//libextmod.so
(II) Module extmod: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 1.0.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 1.1
(II) Loading extension SELinux
(II) Loading extension SHAPE
(II) Loading extension MIT-SUNDRY-NONSTANDARD
(II) Loading extension BIG-REQUESTS
(II) Loading extension SYNC
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XC-MISC
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-Misc
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension TOG-CUP
(II) Loading extension Extended-Visual-Information
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: "dbe"

(II) Loading /usr/lib/xorg/modules/extensions//libdbe.so
(II) Module dbe: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 1.0.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 1.1
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "glx"

(II) Loading /usr/lib/xorg/modules/extensions//libglx.so
(II) Module glx: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 1.0.0
	ABI class: X.Org Server Extension, version 1.1
(==) AIGLX enabled
(==) Exporting typical set of GLX visuals
(II) Loading extension GLX
(II) LoadModule: "freetype"

(II) Loading /usr/lib/xorg/modules/fonts//libfreetype.so
(II) Module freetype: vendor="X.Org Foundation & the After X-TT Project"
	compiled for 1.5.3, module version = 2.1.0
	Module class: X.Org Font Renderer
	ABI class: X.Org Font Renderer, version 0.6
(II) Loading font FreeType
(II) LoadModule: "dri"

(II) Loading /usr/lib/xorg/modules/extensions//libdri.so
(II) Module dri: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 1.0.0
	ABI class: X.Org Server Extension, version 1.1
(II) Loading extension XFree86-DRI
(II) LoadModule: "vesa"

(II) Loading /usr/lib/xorg/modules/drivers//vesa_drv.so
(II) Module vesa: vendor="X.Org Foundation"
	compiled for 1.4.99.905, module version = 1.3.0
	Module class: X.Org Video Driver
	ABI class: X.Org Video Driver, version 4.1
(II) VESA: driver for VESA chipsets: vesa
(II) Primary Device is: PCI 00 at 00:02:0
(II) resource ranges after probing:
	[0] -1	0	0xffffffff - 0xffffffff (0x1) MX[B]
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[5] -1	0	0x00000000 - 0x00000000 (0x1) IX[B]
(II) Loading sub module "vbe"
(II) LoadModule: "vbe"

(II) Loading /usr/lib/xorg/modules//libvbe.so
(II) Module vbe: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 1.1.0
	ABI class: X.Org Video Driver, version 4.1
(II) Loading sub module "int10"
(II) LoadModule: "int10"

(II) Loading /usr/lib/xorg/modules//libint10.so
(II) Module int10: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 1.0.0
	ABI class: X.Org Video Driver, version 4.1
(II) VESA(0): initializing int10
(WW) VESA(0): Bad V_BIOS checksum
(II) VESA(0): Primary V_BIOS segment is: 0xc000
c000:2719: 01 ILLEGAL EXTENDED X86 OPCODE!
(II) VESA(0): VESA BIOS not detected
(II) UnloadModule: "vesa"
(II) UnloadModule: "int10"
(II) Unloading /usr/lib/xorg/modules//libint10.so
(II) UnloadModule: "vbe"
(II) Unloading /usr/lib/xorg/modules//libvbe.so
(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found
-------------- next part --------------

X.Org X Server 1.5.3
Release Date: 5 November 2008
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.18-92.1.10.el5 i686 
Current Operating System: Linux louie.xos.nl 2.6.27.5-117.fc10.i686 #1 SMP Tue Nov 18 12:19:59 EST 2008 i686
Build Date: 16 November 2008  08:29:02PM
Build ID: xorg-x11-server 1.5.3-5.fc10 
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Mon Nov 24 17:07:11 2008
(==) Using config file: "/etc/X11/xorg.conf"
(==) No Layout section.  Using the first Screen section.
(==) No screen section available. Using defaults.
(**) |-->Screen "Default Screen Section" (0)
(**) |   |-->Monitor "<default monitor>"
(==) No device specified for screen "Default Screen Section".
	Using the first device section listed.
(**) |   |-->Device "Videocard0"
(==) No monitor specified for screen "Default Screen Section".
	Using a default monitor configuration.
(==) Automatically adding devices
(==) Automatically enabling devices
(==) No FontPath specified.  Using compiled-in default.
(==) FontPath set to:
	catalogue:/etc/X11/fontpath.d,
	built-ins
(==) ModulePath set to "/usr/lib/xorg/modules"
(II) Cannot locate a core pointer device.
(II) Cannot locate a core keyboard device.
(II) The server relies on HAL to provide the list of input devices.
	If no devices become available, reconfigure HAL or disable AllowEmptyInput.
(II) Open ACPI successful (/var/run/acpid.socket)
(II) Loader magic: 0x81f4400
(II) Module ABI versions:
	X.Org ANSI C Emulation: 0.4
	X.Org Video Driver: 4.1
	X.Org XInput driver : 2.1
	X.Org Server Extension : 1.1
	X.Org Font Renderer : 0.6
(II) Loader running on linux
(--) using VT number 7

(--) PCI:*(0 at 0:2:0) Intel Corporation 82915G/GV/910GL Integrated Graphics Controller rev 14, Mem @ 0xfdf00000/0, 0xd0000000/0, 0xfdf80000/0, I/O @ 0x0000ff00/0
(II) System resource ranges:
	[0] -1	0	0xffffffff - 0xffffffff (0x1) MX[B]
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[5] -1	0	0x00000000 - 0x00000000 (0x1) IX[B]
(II) LoadModule: "extmod"

(II) Loading /usr/lib/xorg/modules/extensions//libextmod.so
(II) Module extmod: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 1.0.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 1.1
(II) Loading extension SELinux
(II) Loading extension SHAPE
(II) Loading extension MIT-SUNDRY-NONSTANDARD
(II) Loading extension BIG-REQUESTS
(II) Loading extension SYNC
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XC-MISC
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-Misc
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension TOG-CUP
(II) Loading extension Extended-Visual-Information
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: "dbe"

(II) Loading /usr/lib/xorg/modules/extensions//libdbe.so
(II) Module dbe: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 1.0.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 1.1
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "glx"

(II) Loading /usr/lib/xorg/modules/extensions//libglx.so
(II) Module glx: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 1.0.0
	ABI class: X.Org Server Extension, version 1.1
(==) AIGLX enabled
(==) Exporting typical set of GLX visuals
(II) Loading extension GLX
(II) LoadModule: "freetype"

(II) Loading /usr/lib/xorg/modules/fonts//libfreetype.so
(II) Module freetype: vendor="X.Org Foundation & the After X-TT Project"
	compiled for 1.5.3, module version = 2.1.0
	Module class: X.Org Font Renderer
	ABI class: X.Org Font Renderer, version 0.6
(II) Loading font FreeType
(II) LoadModule: "dri"

(II) Loading /usr/lib/xorg/modules/extensions//libdri.so
(II) Module dri: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 1.0.0
	ABI class: X.Org Server Extension, version 1.1
(II) Loading extension XFree86-DRI
(II) LoadModule: "intel"

(II) Loading /usr/lib/xorg/modules/drivers//intel_drv.so
(II) Module intel: vendor="X.Org Foundation"
	compiled for 1.5.2, module version = 2.5.0
	Module class: X.Org Video Driver
	ABI class: X.Org Video Driver, version 4.1
(II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
	i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
	E7221 (i915), 915GM, 945G, 945GM, 945GME, 965G, G35, 965Q, 946GZ,
	965GM, 965GME/GLE, G33, Q35, Q33,
	Mobile Intel? GM45 Express Chipset,
	Intel Integrated Graphics Device, G45/G43, Q45/Q43, G41
(II) Primary Device is: PCI 00 at 00:02:0
(II) resource ranges after xf86ClaimFixedResources() call:
	[0] -1	0	0xffffffff - 0xffffffff (0x1) MX[B]
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[5] -1	0	0x00000000 - 0x00000000 (0x1) IX[B]
(II) resource ranges after probing:
	[0] -1	0	0xffffffff - 0xffffffff (0x1) MX[B]
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] 0	0	0x000a0000 - 0x000affff (0x10000) MS[B]
	[5] 0	0	0x000b0000 - 0x000b7fff (0x8000) MS[B]
	[6] 0	0	0x000b8000 - 0x000bffff (0x8000) MS[B]
	[7] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[8] -1	0	0x00000000 - 0x00000000 (0x1) IX[B]
	[9] 0	0	0x000003b0 - 0x000003bb (0xc) IS[B]
	[10] 0	0	0x000003c0 - 0x000003df (0x20) IS[B]
(II) Loading sub module "vgahw"
(II) LoadModule: "vgahw"

(II) Loading /usr/lib/xorg/modules//libvgahw.so
(II) Module vgahw: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 0.1.0
	ABI class: X.Org Video Driver, version 4.1
(II) intel(0): Creating default Display subsection in Screen section
	"Default Screen Section" for depth/fbbpp 24/32
(==) intel(0): Depth 24, (==) framebuffer bpp 32
(==) intel(0): RGB weight 888
(==) intel(0): Default visual is TrueColor
(II) intel(0): Integrated Graphics Chipset: Intel(R) 915G
(--) intel(0): Chipset: "915G"
(--) intel(0): Linear framebuffer at 0xD0000000
(--) intel(0): IO registers at addr 0xFDF00000
(WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB
(EE) intel(0): Bad VBT signature
(WW) intel(0): VBIOS initialization failed.
(==) intel(0): Using EXA for acceleration
(II) intel(0): 2 display pipes available.
(II) Loading sub module "ddc"
(II) LoadModule: "ddc"
(II) Module "ddc" already built-in
(II) Loading sub module "i2c"
(II) LoadModule: "i2c"
(II) Module "i2c" already built-in
(II) intel(0): Output VGA has no monitor section
(II) intel(0): I2C bus "SDVOCTRL_E for SDVOB" initialized.
(II) intel(0): I2C device "SDVOCTRL_E for SDVOB:SDVO Controller B" registered at address 0x70.
(II) intel(0): I2C bus "SDVOB DDC Bus" initialized.
(WW) intel(0): SDVOB: Unknown SDVO output type (0x4000)
(II) intel(0): Output Unknown-1 has no monitor section
(II) intel(0): SDVOB: device VID/DID: 02:41.01, clock range 25.0MHz - 200.0MHz
(II) intel(0): SDVOB: 1 input channel
(II) intel(0): SDVOB: LVDS0 output reported
(II) intel(0): Current clock rate multiplier: 2
(II) intel(0): I2C bus "CRTDDC_A" initialized.
(II) intel(0): I2C bus "CRTDDC_A" removed.
(II) intel(0): EDID for output VGA
(II) intel(0): I2C device "SDVOB DDC Bus:E-EDID segment register" registered at address 0x60.
(II) intel(0): I2C device "SDVOB DDC Bus:ddc2" registered at address 0xA0.
(II) intel(0): EDID for output Unknown-1
(II) intel(0): I2C bus "CRTDDC_A" initialized.
(II) intel(0): I2C bus "CRTDDC_A" removed.
(II) intel(0): I2C bus "CRTDDC_A" initialized.
(II) intel(0): I2C device "CRTDDC_A:E-EDID segment register" registered at address 0x60.
(II) intel(0): I2C device "CRTDDC_A:ddc2" registered at address 0xA0.
(II) intel(0): I2C device "CRTDDC_A:ddc2" removed.
(II) intel(0): I2C device "CRTDDC_A:E-EDID segment register" removed.
(II) intel(0): I2C bus "CRTDDC_A" removed.
(II) intel(0): Not using default mode "640x350" (vrefresh out of range)
(II) intel(0): Not using default mode "640x400" (vrefresh out of range)
(II) intel(0): Not using default mode "720x400" (vrefresh out of range)
(II) intel(0): Not using default mode "640x480" (vrefresh out of range)
(II) intel(0): Not using default mode "640x480" (vrefresh out of range)
(II) intel(0): Not using default mode "640x480" (vrefresh out of range)
(II) intel(0): Not using default mode "800x600" (vrefresh out of range)
(II) intel(0): Not using default mode "800x600" (vrefresh out of range)
(II) intel(0): Not using default mode "800x600" (vrefresh out of range)
(II) intel(0): Not using default mode "800x600" (vrefresh out of range)
(II) intel(0): Not using default mode "1024x768" (vrefresh out of range)
(II) intel(0): Not using default mode "1024x768" (vrefresh out of range)
(II) intel(0): Not using default mode "1024x768" (vrefresh out of range)
(II) intel(0): Not using default mode "1152x864" (vrefresh out of range)
(II) intel(0): Not using default mode "1280x960" (hsync out of range)
(II) intel(0): Not using default mode "1280x960" (vrefresh out of range)
(II) intel(0): Not using default mode "1280x1024" (hsync out of range)
(II) intel(0): Not using default mode "1280x1024" (vrefresh out of range)
(II) intel(0): Not using default mode "1280x1024" (vrefresh out of range)
(II) intel(0): Not using default mode "1600x1200" (hsync out of range)
(II) intel(0): Not using default mode "1600x1200" (vrefresh out of range)
(II) intel(0): Not using default mode "1600x1200" (vrefresh out of range)
(II) intel(0): Not using default mode "1600x1200" (vrefresh out of range)
(II) intel(0): Not using default mode "1600x1200" (vrefresh out of range)
(II) intel(0): Not using default mode "1792x1344" (hsync out of range)
(II) intel(0): Not using default mode "1792x1344" (vrefresh out of range)
(II) intel(0): Not using default mode "1856x1392" (hsync out of range)
(II) intel(0): Not using default mode "1856x1392" (vrefresh out of range)
(II) intel(0): Not using default mode "1920x1440" (hsync out of range)
(II) intel(0): Not using default mode "1920x1440" (vrefresh out of range)
(II) intel(0): Not using default mode "832x624" (vrefresh out of range)
(II) intel(0): Not using default mode "1400x1050" (hsync out of range)
(II) intel(0): Not using default mode "1400x1050" (vrefresh out of range)
(II) intel(0): Not using default mode "1920x1440" (vrefresh out of range)
(II) intel(0): Not using default mode "2048x1536" (hsync out of range)
(II) intel(0): Not using default mode "2048x1536" (vrefresh out of range)
(II) intel(0): Not using default mode "2048x1536" (vrefresh out of range)
(II) intel(0): Printing probed modes for output Unknown-1
(II) intel(0): Modeline "1024x768"x60.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
(II) intel(0): Modeline "800x600"x60.3   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
(II) intel(0): Modeline "640x480"x59.9   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz)
(II) intel(0): Output VGA disconnected
(II) intel(0): Output Unknown-1 connected
(II) intel(0): Using fuzzy aspect match for initial modes
(II) intel(0): Output Unknown-1 using initial mode 1024x768
(II) intel(0): detected 256 kB GTT.
(II) intel(0): detected 7932 kB stolen memory.
(==) intel(0): video overlay key set to 0x101fe
(==) intel(0): Intel XvMC decoder disabled
(==) intel(0): Will not try to enable page flipping
(==) intel(0): Triple buffering disabled
(==) intel(0): Using gamma correction (1.0, 1.0, 1.0)
(==) intel(0): DPI set to (96, 96)
(II) Loading sub module "fb"
(II) LoadModule: "fb"

(II) Loading /usr/lib/xorg/modules//libfb.so
(II) Module fb: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 1.0.0
	ABI class: X.Org ANSI C Emulation, version 0.4
(II) Loading sub module "exa"
(II) LoadModule: "exa"

(II) Loading /usr/lib/xorg/modules//libexa.so
(II) Module exa: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 2.4.0
	ABI class: X.Org Video Driver, version 4.1
(II) Loading sub module "ramdac"
(II) LoadModule: "ramdac"
(II) Module "ramdac" already built-in
(II) intel(0): Comparing regs from server start up to After PreInit
(==) Depth 24 pixmap format is 32 bpp
(II) do I need RAC?  No, I don't.
(II) resource ranges after preInit:
	[0] -1	0	0xffffffff - 0xffffffff (0x1) MX[B]
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] 0	0	0x000a0000 - 0x000affff (0x10000) MS[B](OprD)
	[5] 0	0	0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD)
	[6] 0	0	0x000b8000 - 0x000bffff (0x8000) MS[B](OprD)
	[7] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[8] -1	0	0x00000000 - 0x00000000 (0x1) IX[B]
	[9] 0	0	0x000003b0 - 0x000003bb (0xc) IS[B](OprU)
	[10] 0	0	0x000003c0 - 0x000003df (0x20) IS[B](OprU)
(II) intel(0): Kernel reported 110080 total, 1 used
(II) intel(0): I830CheckAvailableMemory: 440316 kB available
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 12, (OK)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 12, (OK)
drmOpenByBusid: Searching for BusID pci:0000:00:02.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 12, (OK)
drmOpenByBusid: drmOpenMinor returns 12
drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
(II) [drm] DRM interface version 1.3
(II) [drm] DRM open master succeeded.
(II) intel(0): [drm] Using the DRM lock SAREA also for drawables.
(II) intel(0): [drm] framebuffer mapped by ddx driver
(II) intel(0): [drm] added 1 reserved context for kernel
(II) intel(0): X context handle = 0x1
(II) intel(0): [drm] installed DRM signal handler
(**) intel(0): Framebuffer compression disabled
(**) intel(0): Tiling enabled
(==) intel(0): VideoRam: 262144 KB
(II) intel(0): Attempting memory allocation with tiled buffers.
(II) intel(0): Tiled allocation successful.
(II) intel(0): [drm] Registers = 0x2fbe1000
(II) intel(0): [dri] visual configs initialized
(II) intel(0): Page Flipping disabled
(II) intel(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
(II) EXA(0): Offscreen pixmap area of 12582912 bytes
(II) EXA(0): Driver registered support for the following operations:
(II)         Solid
(II)         Copy
(II)         Composite (RENDER acceleration)
(==) intel(0): Backing store disabled
(==) intel(0): Silken mouse enabled
(II) intel(0): Initializing HW Cursor
(II) intel(0): [DRI] installation complete
(II) intel(0): Current clock rate multiplier: 2
(II) intel(0): xf86BindGARTMemory: bind key 0 at 0x0f3f5000 (pgoffset 62453)
(II) intel(0): Fixed memory allocation layout:
(II) intel(0): 0x00000000-0x00009fff: HW cursors (40 kB, 0x000000001f800000 physical
)
(II) intel(0): 0x0000a000-0x0000afff: overlay registers (4 kB, 0x000000001f80a000 physical
)
(II) intel(0): 0x007bf000:            end of stolen memory
(II) intel(0): 0x007bf000-0x0f3f4fff: DRI memory manager (241880 kB)
(II) intel(0): 0x0f3f5000-0x0fff4fff: exa offscreen (12288 kB)
(II) intel(0): 0x10000000:            end of aperture
(II) intel(0): BO memory allocation layout:
(II) intel(0): 0x007bf000:            start of memory manager
(II) intel(0): 0x00800000-0x00bfffff: depth buffer (4096 kB) X tiled
(II) intel(0): 0x00c00000-0x00ffffff: back buffer (4096 kB) X tiled
(II) intel(0): 0x01000000-0x013fffff: front buffer (4096 kB) X tiled
(II) intel(0): 0x007df000-0x007e6fff: logical 3D context (32 kB)
(II) intel(0): 0x0f3f5000:            end of memory manager
(WW) intel(0): ESR is 0x00000011, page table error, instruction error
(WW) intel(0): PGTBL_ER is 0x00000002, host pte data
(WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled
(WW) intel(0): Existing errors found in hardware state.
(II) intel(0): Output configuration:
(II) intel(0):   Pipe A is on
(II) intel(0):   Display plane A is now enabled and connected to pipe A.
(II) intel(0):   Pipe B is off
(II) intel(0):   Display plane B is now disabled and connected to pipe A.
(II) intel(0):   Output VGA is connected to pipe none
(II) intel(0):   Output Unknown-1 is connected to pipe A
(II) intel(0): [drm] mapped front buffer at 0xd1000000, handle = 0x2a201000
(II) intel(0): [drm] mapped back buffer at 0xd0c00000, handle = 0x2a181000
(II) intel(0): [drm] mapped depth buffer at 0xd0800000, handle = 0x2a101000
(II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message.
(II) intel(0): DPMS enabled
(II) intel(0): Set up textured video
(II) intel(0): Set up overlay video
(II) intel(0): direct rendering: Enabled
(--) RandR disabled
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension
(II) Initializing built-in extension XTEST
(II) Initializing built-in extension XKEYBOARD
(II) Initializing built-in extension XINERAMA
(II) Initializing built-in extension XFIXES
(II) Initializing built-in extension RENDER
(II) Initializing built-in extension RANDR
(II) Initializing built-in extension COMPOSITE
(II) Initializing built-in extension DAMAGE
(II) Initializing built-in extension XEVIE
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 13, (OK)
drmOpenByBusid: Searching for BusID pci:0000:00:02.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 13, (OK)
drmOpenByBusid: drmOpenMinor returns 13
drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
(II) AIGLX: enabled GLX_MESA_copy_sub_buffer
(II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
(II) AIGLX: enabled GLX_texture_from_pixmap with driver support
(II) AIGLX: Loaded and initialized /usr/lib/dri/i915_dri.so
(II) GLX: Initialized DRI GL provider for screen 0
(II) intel(0): Setting screen physical size to 270 x 203
(II) config/hal: Adding input device Power Button (FF)
(II) LoadModule: "evdev"

(II) Loading /usr/lib/xorg/modules/input//evdev_drv.so
(II) Module evdev: vendor="X.Org Foundation"
	compiled for 1.5.2, module version = 2.0.7
	Module class: X.Org XInput Driver
	ABI class: X.Org XInput driver, version 2.1
(**) Power Button (FF): always reports core events
(**) Power Button (FF): Device: "/dev/input/event0"
(II) Power Button (FF): Found keys
(II) Power Button (FF): Configuring as keyboard
(II) XINPUT: Adding extended input device "Power Button (FF)" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Power Button (FF): xkb_rules: "evdev"
(**) Option "xkb_model" "pc105+inet"
(**) Power Button (FF): xkb_model: "pc105+inet"
(**) Option "xkb_layout" "us"
(**) Power Button (FF): xkb_layout: "us"
(II) config/hal: Adding input device Power Button (CM)
(**) Power Button (CM): always reports core events
(**) Power Button (CM): Device: "/dev/input/event1"
(II) Power Button (CM): Found keys
(II) Power Button (CM): Configuring as keyboard
(II) XINPUT: Adding extended input device "Power Button (CM)" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Power Button (CM): xkb_rules: "evdev"
(**) Option "xkb_model" "pc105+inet"
(**) Power Button (CM): xkb_model: "pc105+inet"
(**) Option "xkb_layout" "us"
(**) Power Button (CM): xkb_layout: "us"
(II) config/hal: Adding input device HID 046a:0001
(**) HID 046a:0001: always reports core events
(**) HID 046a:0001: Device: "/dev/input/event4"
(II) HID 046a:0001: Found keys
(II) HID 046a:0001: Configuring as keyboard
(II) XINPUT: Adding extended input device "HID 046a:0001" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) HID 046a:0001: xkb_rules: "evdev"
(**) Option "xkb_model" "pc105+inet"
(**) HID 046a:0001: xkb_model: "pc105+inet"
(**) Option "xkb_layout" "us"
(**) HID 046a:0001: xkb_layout: "us"
(II) config/hal: Adding input device Macintosh mouse button emulation
(**) Macintosh mouse button emulation: always reports core events
(**) Macintosh mouse button emulation: Device: "/dev/input/event2"
(II) Macintosh mouse button emulation: Found x and y relative axes
(II) Macintosh mouse button emulation: Found mouse buttons
(II) Macintosh mouse button emulation: Configuring as mouse
(II) XINPUT: Adding extended input device "Macintosh mouse button emulation" (type: MOUSE)
(II) config/hal: Adding input device Logitech USB-PS/2 Optical Mouse
(**) Logitech USB-PS/2 Optical Mouse: always reports core events
(**) Logitech USB-PS/2 Optical Mouse: Device: "/dev/input/event3"
(II) Logitech USB-PS/2 Optical Mouse: Found x and y relative axes
(II) Logitech USB-PS/2 Optical Mouse: Found mouse buttons
(II) Logitech USB-PS/2 Optical Mouse: Configuring as mouse
(II) XINPUT: Adding extended input device "Logitech USB-PS/2 Optical Mouse" (type: MOUSE)
(II) intel(0): I2C bus "CRTDDC_A" initialized.
(II) intel(0): I2C bus "CRTDDC_A" removed.
(II) intel(0): EDID for output VGA
(II) intel(0): EDID for output Unknown-1
(II) intel(0): I2C bus "CRTDDC_A" initialized.
(II) intel(0): I2C bus "CRTDDC_A" removed.
(II) intel(0): I2C bus "CRTDDC_A" initialized.
(II) intel(0): I2C device "CRTDDC_A:E-EDID segment register" registered at address 0x60.
(II) intel(0): I2C device "CRTDDC_A:ddc2" registered at address 0xA0.
(II) intel(0): I2C device "CRTDDC_A:ddc2" removed.
(II) intel(0): I2C device "CRTDDC_A:E-EDID segment register" removed.
(II) intel(0): I2C bus "CRTDDC_A" removed.
(II) intel(0): Not using default mode "640x350" (vrefresh out of range)
(II) intel(0): Not using default mode "640x400" (vrefresh out of range)
(II) intel(0): Not using default mode "720x400" (vrefresh out of range)
(II) intel(0): Not using default mode "640x480" (vrefresh out of range)
(II) intel(0): Not using default mode "640x480" (vrefresh out of range)
(II) intel(0): Not using default mode "640x480" (vrefresh out of range)
(II) intel(0): Not using default mode "800x600" (vrefresh out of range)
(II) intel(0): Not using default mode "800x600" (vrefresh out of range)
(II) intel(0): Not using default mode "800x600" (vrefresh out of range)
(II) intel(0): Not using default mode "800x600" (vrefresh out of range)
(II) intel(0): Not using default mode "1024x768" (vrefresh out of range)
(II) intel(0): Not using default mode "1024x768" (vrefresh out of range)
(II) intel(0): Not using default mode "1024x768" (vrefresh out of range)
(II) intel(0): Not using default mode "1152x864" (width too large for virtual size)
(II) intel(0): Not using default mode "1280x960" (width too large for virtual size)
(II) intel(0): Not using default mode "1280x960" (width too large for virtual size)
(II) intel(0): Not using default mode "1280x1024" (width too large for virtual size)
(II) intel(0): Not using default mode "1280x1024" (width too large for virtual size)
(II) intel(0): Not using default mode "1280x1024" (width too large for virtual size)
(II) intel(0): Not using default mode "1600x1200" (height too large for virtual size)
(II) intel(0): Not using default mode "1600x1200" (height too large for virtual size)
(II) intel(0): Not using default mode "1600x1200" (height too large for virtual size)
(II) intel(0): Not using default mode "1600x1200" (height too large for virtual size)
(II) intel(0): Not using default mode "1600x1200" (height too large for virtual size)
(II) intel(0): Not using default mode "1792x1344" (height too large for virtual size)
(II) intel(0): Not using default mode "1792x1344" (height too large for virtual size)
(II) intel(0): Not using default mode "1856x1392" (height too large for virtual size)
(II) intel(0): Not using default mode "1856x1392" (height too large for virtual size)
(II) intel(0): Not using default mode "1920x1440" (height too large for virtual size)
(II) intel(0): Not using default mode "1920x1440" (height too large for virtual size)
(II) intel(0): Not using default mode "832x624" (vrefresh out of range)
(II) intel(0): Not using default mode "1400x1050" (height too large for virtual size)
(II) intel(0): Not using default mode "1400x1050" (height too large for virtual size)
(II) intel(0): Not using default mode "1920x1440" (height too large for virtual size)
(II) intel(0): Not using default mode "2048x1536" (height too large for virtual size)
(II) intel(0): Not using default mode "2048x1536" (height too large for virtual size)
(II) intel(0): Not using default mode "2048x1536" (height too large for virtual size)
(II) intel(0): Printing probed modes for output Unknown-1
(II) intel(0): Modeline "1024x768"x60.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
(II) intel(0): Modeline "800x600"x60.3   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
(II) intel(0): Modeline "640x480"x59.9   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz)
(II) intel(0): I2C bus "CRTDDC_A" initialized.
(II) intel(0): I2C bus "CRTDDC_A" removed.
(II) intel(0): EDID for output VGA
(II) intel(0): EDID for output Unknown-1
(II) intel(0): I2C bus "CRTDDC_A" initialized.
(II) intel(0): I2C bus "CRTDDC_A" removed.
(II) intel(0): I2C bus "CRTDDC_A" initialized.
(II) intel(0): I2C device "CRTDDC_A:E-EDID segment register" registered at address 0x60.
(II) intel(0): I2C device "CRTDDC_A:ddc2" registered at address 0xA0.
(II) intel(0): I2C device "CRTDDC_A:ddc2" removed.
(II) intel(0): I2C device "CRTDDC_A:E-EDID segment register" removed.
(II) intel(0): I2C bus "CRTDDC_A" removed.
(II) intel(0): Not using default mode "640x350" (vrefresh out of range)
(II) intel(0): Not using default mode "640x400" (vrefresh out of range)
(II) intel(0): Not using default mode "720x400" (vrefresh out of range)
(II) intel(0): Not using default mode "640x480" (vrefresh out of range)
(II) intel(0): Not using default mode "640x480" (vrefresh out of range)
(II) intel(0): Not using default mode "640x480" (vrefresh out of range)
(II) intel(0): Not using default mode "800x600" (vrefresh out of range)
(II) intel(0): Not using default mode "800x600" (vrefresh out of range)
(II) intel(0): Not using default mode "800x600" (vrefresh out of range)
(II) intel(0): Not using default mode "800x600" (vrefresh out of range)
(II) intel(0): Not using default mode "1024x768" (vrefresh out of range)
(II) intel(0): Not using default mode "1024x768" (vrefresh out of range)
(II) intel(0): Not using default mode "1024x768" (vrefresh out of range)
(II) intel(0): Not using default mode "1152x864" (width too large for virtual size)
(II) intel(0): Not using default mode "1280x960" (width too large for virtual size)
(II) intel(0): Not using default mode "1280x960" (width too large for virtual size)
(II) intel(0): Not using default mode "1280x1024" (width too large for virtual size)
(II) intel(0): Not using default mode "1280x1024" (width too large for virtual size)
(II) intel(0): Not using default mode "1280x1024" (width too large for virtual size)
(II) intel(0): Not using default mode "1600x1200" (height too large for virtual size)
(II) intel(0): Not using default mode "1600x1200" (height too large for virtual size)
(II) intel(0): Not using default mode "1600x1200" (height too large for virtual size)
(II) intel(0): Not using default mode "1600x1200" (height too large for virtual size)
(II) intel(0): Not using default mode "1600x1200" (height too large for virtual size)
(II) intel(0): Not using default mode "1792x1344" (height too large for virtual size)
(II) intel(0): Not using default mode "1792x1344" (height too large for virtual size)
(II) intel(0): Not using default mode "1856x1392" (height too large for virtual size)
(II) intel(0): Not using default mode "1856x1392" (height too large for virtual size)
(II) intel(0): Not using default mode "1920x1440" (height too large for virtual size)
(II) intel(0): Not using default mode "1920x1440" (height too large for virtual size)
(II) intel(0): Not using default mode "832x624" (vrefresh out of range)
(II) intel(0): Not using default mode "1400x1050" (height too large for virtual size)
(II) intel(0): Not using default mode "1400x1050" (height too large for virtual size)
(II) intel(0): Not using default mode "1920x1440" (height too large for virtual size)
(II) intel(0): Not using default mode "2048x1536" (height too large for virtual size)
(II) intel(0): Not using default mode "2048x1536" (height too large for virtual size)
(II) intel(0): Not using default mode "2048x1536" (height too large for virtual size)
(II) intel(0): Printing probed modes for output Unknown-1
(II) intel(0): Modeline "1024x768"x60.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
(II) intel(0): Modeline "800x600"x60.3   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
(II) intel(0): Modeline "640x480"x59.9   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz)
(II) intel(0): I2C bus "CRTDDC_A" initialized.
(II) intel(0): I2C bus "CRTDDC_A" removed.
(II) intel(0): EDID for output VGA
(II) intel(0): EDID for output Unknown-1
(II) intel(0): I2C bus "CRTDDC_A" initialized.
(II) intel(0): I2C bus "CRTDDC_A" removed.
(II) intel(0): I2C bus "CRTDDC_A" initialized.
(II) intel(0): I2C device "CRTDDC_A:E-EDID segment register" registered at address 0x60.
(II) intel(0): I2C device "CRTDDC_A:ddc2" registered at address 0xA0.
(II) intel(0): I2C device "CRTDDC_A:ddc2" removed.
(II) intel(0): I2C device "CRTDDC_A:E-EDID segment register" removed.
(II) intel(0): I2C bus "CRTDDC_A" removed.
(II) intel(0): Not using default mode "640x350" (vrefresh out of range)
(II) intel(0): Not using default mode "640x400" (vrefresh out of range)
(II) intel(0): Not using default mode "720x400" (vrefresh out of range)
(II) intel(0): Not using default mode "640x480" (vrefresh out of range)
(II) intel(0): Not using default mode "640x480" (vrefresh out of range)
(II) intel(0): Not using default mode "640x480" (vrefresh out of range)
(II) intel(0): Not using default mode "800x600" (vrefresh out of range)
(II) intel(0): Not using default mode "800x600" (vrefresh out of range)
(II) intel(0): Not using default mode "800x600" (vrefresh out of range)
(II) intel(0): Not using default mode "800x600" (vrefresh out of range)
(II) intel(0): Not using default mode "1024x768" (vrefresh out of range)
(II) intel(0): Not using default mode "1024x768" (vrefresh out of range)
(II) intel(0): Not using default mode "1024x768" (vrefresh out of range)
(II) intel(0): Not using default mode "1152x864" (width too large for virtual size)
(II) intel(0): Not using default mode "1280x960" (width too large for virtual size)
(II) intel(0): Not using default mode "1280x960" (width too large for virtual size)
(II) intel(0): Not using default mode "1280x1024" (width too large for virtual size)
(II) intel(0): Not using default mode "1280x1024" (width too large for virtual size)
(II) intel(0): Not using default mode "1280x1024" (width too large for virtual size)
(II) intel(0): Not using default mode "1600x1200" (height too large for virtual size)
(II) intel(0): Not using default mode "1600x1200" (height too large for virtual size)
(II) intel(0): Not using default mode "1600x1200" (height too large for virtual size)
(II) intel(0): Not using default mode "1600x1200" (height too large for virtual size)
(II) intel(0): Not using default mode "1600x1200" (height too large for virtual size)
(II) intel(0): Not using default mode "1792x1344" (height too large for virtual size)
(II) intel(0): Not using default mode "1792x1344" (height too large for virtual size)
(II) intel(0): Not using default mode "1856x1392" (height too large for virtual size)
(II) intel(0): Not using default mode "1856x1392" (height too large for virtual size)
(II) intel(0): Not using default mode "1920x1440" (height too large for virtual size)
(II) intel(0): Not using default mode "1920x1440" (height too large for virtual size)
(II) intel(0): Not using default mode "832x624" (vrefresh out of range)
(II) intel(0): Not using default mode "1400x1050" (height too large for virtual size)
(II) intel(0): Not using default mode "1400x1050" (height too large for virtual size)
(II) intel(0): Not using default mode "1920x1440" (height too large for virtual size)
(II) intel(0): Not using default mode "2048x1536" (height too large for virtual size)
(II) intel(0): Not using default mode "2048x1536" (height too large for virtual size)
(II) intel(0): Not using default mode "2048x1536" (height too large for virtual size)
(II) intel(0): Printing probed modes for output Unknown-1
(II) intel(0): Modeline "1024x768"x60.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
(II) intel(0): Modeline "800x600"x60.3   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
(II) intel(0): Modeline "640x480"x59.9   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz)
(II) intel(0): I2C bus "CRTDDC_A" initialized.
(II) intel(0): I2C bus "CRTDDC_A" removed.
(II) intel(0): EDID for output VGA
(II) intel(0): EDID for output Unknown-1
(II) intel(0): I2C bus "CRTDDC_A" initialized.
(II) intel(0): I2C bus "CRTDDC_A" removed.
(II) intel(0): I2C bus "CRTDDC_A" initialized.
(II) intel(0): I2C device "CRTDDC_A:E-EDID segment register" registered at address 0x60.
(II) intel(0): I2C device "CRTDDC_A:ddc2" registered at address 0xA0.
(II) intel(0): I2C device "CRTDDC_A:ddc2" removed.
(II) intel(0): I2C device "CRTDDC_A:E-EDID segment register" removed.
(II) intel(0): I2C bus "CRTDDC_A" removed.
(II) intel(0): Not using default mode "640x350" (vrefresh out of range)
(II) intel(0): Not using default mode "640x400" (vrefresh out of range)
(II) intel(0): Not using default mode "720x400" (vrefresh out of range)
(II) intel(0): Not using default mode "640x480" (vrefresh out of range)
(II) intel(0): Not using default mode "640x480" (vrefresh out of range)
(II) intel(0): Not using default mode "640x480" (vrefresh out of range)
(II) intel(0): Not using default mode "800x600" (vrefresh out of range)
(II) intel(0): Not using default mode "800x600" (vrefresh out of range)
(II) intel(0): Not using default mode "800x600" (vrefresh out of range)
(II) intel(0): Not using default mode "800x600" (vrefresh out of range)
(II) intel(0): Not using default mode "1024x768" (vrefresh out of range)
(II) intel(0): Not using default mode "1024x768" (vrefresh out of range)
(II) intel(0): Not using default mode "1024x768" (vrefresh out of range)
(II) intel(0): Not using default mode "1152x864" (width too large for virtual size)
(II) intel(0): Not using default mode "1280x960" (width too large for virtual size)
(II) intel(0): Not using default mode "1280x960" (width too large for virtual size)
(II) intel(0): Not using default mode "1280x1024" (width too large for virtual size)
(II) intel(0): Not using default mode "1280x1024" (width too large for virtual size)
(II) intel(0): Not using default mode "1280x1024" (width too large for virtual size)
(II) intel(0): Not using default mode "1600x1200" (height too large for virtual size)
(II) intel(0): Not using default mode "1600x1200" (height too large for virtual size)
(II) intel(0): Not using default mode "1600x1200" (height too large for virtual size)
(II) intel(0): Not using default mode "1600x1200" (height too large for virtual size)
(II) intel(0): Not using default mode "1600x1200" (height too large for virtual size)
(II) intel(0): Not using default mode "1792x1344" (height too large for virtual size)
(II) intel(0): Not using default mode "1792x1344" (height too large for virtual size)
(II) intel(0): Not using default mode "1856x1392" (height too large for virtual size)
(II) intel(0): Not using default mode "1856x1392" (height too large for virtual size)
(II) intel(0): Not using default mode "1920x1440" (height too large for virtual size)
(II) intel(0): Not using default mode "1920x1440" (height too large for virtual size)
(II) intel(0): Not using default mode "832x624" (vrefresh out of range)
(II) intel(0): Not using default mode "1400x1050" (height too large for virtual size)
(II) intel(0): Not using default mode "1400x1050" (height too large for virtual size)
(II) intel(0): Not using default mode "1920x1440" (height too large for virtual size)
(II) intel(0): Not using default mode "2048x1536" (height too large for virtual size)
(II) intel(0): Not using default mode "2048x1536" (height too large for virtual size)
(II) intel(0): Not using default mode "2048x1536" (height too large for virtual size)
(II) intel(0): Printing probed modes for output Unknown-1
(II) intel(0): Modeline "1024x768"x60.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
(II) intel(0): Modeline "800x600"x60.3   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
(II) intel(0): Modeline "640x480"x59.9   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz)

From ivazqueznet at gmail.com  Mon Nov 24 17:54:00 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Mon, 24 Nov 2008 12:54:00 -0500
Subject: It's all ASPLODY!
Message-ID: <1227549240.6715.44.camel@ignacio.lan>

Sorry for the overdramatic subject, but this is important.

Within the next few days Python 2.6 will be imported into Rawhide. This
means that EVERY single Python-based package in Rawhide will be broken,
and that we'll need to slog our way through rebuilding it package by
package. I'm going to forgo the customary list of packages this time
since they number in the hundreds. You can see them for yourself by
using the following:

repoquery --disablerepo=\* --enablerepo={development,rawhide} \
  --whatrequires "python(abi)" | sort | less

Good luck, and godspeed.

-- 
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/20081124/8603b166/attachment.sig>

From skvidal at fedoraproject.org  Mon Nov 24 17:57:47 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 24 Nov 2008 12:57:47 -0500 (EST)
Subject: It's all ASPLODY!
In-Reply-To: <1227549240.6715.44.camel@ignacio.lan>
References: <1227549240.6715.44.camel@ignacio.lan>
Message-ID: <alpine.LFD.2.00.0811241256420.13683@localhost.localdomain>



On Mon, 24 Nov 2008, Ignacio Vazquez-Abrams wrote:

> Sorry for the overdramatic subject, but this is important.
>
> Within the next few days Python 2.6 will be imported into Rawhide. This
> means that EVERY single Python-based package in Rawhide will be broken,
> and that we'll need to slog our way through rebuilding it package by
> package. I'm going to forgo the customary list of packages this time
> since they number in the hundreds. You can see them for yourself by
> using the following:
>
> repoquery --disablerepo=\* --enablerepo={development,rawhide} \
>  --whatrequires "python(abi)" | sort | less
>
> Good luck, and godspeed.

So, unless everyone is comfy with rawhide being broken for most of the 
rest of the week, I'd suggest we delay the import of python 2.6 until 
after the weekend and a huge portion of the americans in working on fedora 
get back from thanksgiving food comas.

-sv



From notting at redhat.com  Mon Nov 24 18:09:09 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 24 Nov 2008 13:09:09 -0500
Subject: It's all ASPLODY!
In-Reply-To: <alpine.LFD.2.00.0811241256420.13683@localhost.localdomain>
References: <1227549240.6715.44.camel@ignacio.lan>
	<alpine.LFD.2.00.0811241256420.13683@localhost.localdomain>
Message-ID: <20081124180909.GB3145@nostromo.devel.redhat.com>

Seth Vidal (skvidal at fedoraproject.org) said: 
> So, unless everyone is comfy with rawhide being broken for most of the  
> rest of the week, I'd suggest we delay the import of python 2.6 until  
> after the weekend and a huge portion of the americans in working on 
> fedora get back from thanksgiving food comas.

I'm taking it from the original mail that the python maintainers do
not want to trigger the rebuilds?

Bill



From ajax at redhat.com  Mon Nov 24 18:14:56 2008
From: ajax at redhat.com (Adam Jackson)
Date: Mon, 24 Nov 2008 13:14:56 -0500
Subject: No X on F9/F10 with Intel 82915G/GV/910GL
In-Reply-To: <20081124165746.GA20250@jasmine.xos.nl>
References: <200811241511.mAOFBDo0019062@jasmine.xos.nl>
	<1227545424.23765.19.camel@atropine.boston.devel.redhat.com>
	<20081124165746.GA20250@jasmine.xos.nl>
Message-ID: <1227550496.23765.24.camel@atropine.boston.devel.redhat.com>

On Mon, 2008-11-24 at 17:57 +0100, Jos Vos wrote:
> On Mon, Nov 24, 2008 at 11:50:24AM -0500, Adam Jackson wrote:
> 
> > Typically the VBT signature doesn't mean much.  But yes, full log would
> > be interesting.
> 
> I tried with 32-bit: still no graphics.
> 
> Attached:
> - Xorg.0.log.vesa (no xorg.conf or xorg.conf specifying "vesa") and
> - Xorg.0.log.intel (with xorg.conf specifying "intel").

Very strange.  What kind of display is it?  Are you using an SDVO card
(pseudo-PCIE looking thing with a tiny chip on one side and a DVI or
whatever connector on the other)?

- 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/20081124/91c8d83f/attachment.sig>

From ivazqueznet at gmail.com  Mon Nov 24 18:16:14 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Mon, 24 Nov 2008 13:16:14 -0500
Subject: It's all ASPLODY!
In-Reply-To: <20081124180909.GB3145@nostromo.devel.redhat.com>
References: <1227549240.6715.44.camel@ignacio.lan>
	<alpine.LFD.2.00.0811241256420.13683@localhost.localdomain>
	<20081124180909.GB3145@nostromo.devel.redhat.com>
Message-ID: <1227550574.6715.45.camel@ignacio.lan>

On Mon, 2008-11-24 at 13:09 -0500, Bill Nottingham wrote:
> Seth Vidal (skvidal at fedoraproject.org) said: 
> > So, unless everyone is comfy with rawhide being broken for most of the  
> > rest of the week, I'd suggest we delay the import of python 2.6 until  
> > after the weekend and a huge portion of the americans in working on 
> > fedora get back from thanksgiving food comas.
> 
> I'm taking it from the original mail that the python maintainers do
> not want to trigger the rebuilds?

I don't mind doing some of them, but there are almost 700 total and
there's no way I can get that many done in a timely fashion.

-- 
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/20081124/eab73ae4/attachment.sig>

From tcallawa at redhat.com  Mon Nov 24 18:18:33 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 24 Nov 2008 13:18:33 -0500
Subject: It's all ASPLODY!
In-Reply-To: <1227550574.6715.45.camel@ignacio.lan>
References: <1227549240.6715.44.camel@ignacio.lan>
	<alpine.LFD.2.00.0811241256420.13683@localhost.localdomain>
	<20081124180909.GB3145@nostromo.devel.redhat.com>
	<1227550574.6715.45.camel@ignacio.lan>
Message-ID: <1227550713.4519.52.camel@localhost.localdomain>

On Mon, 2008-11-24 at 13:16 -0500, Ignacio Vazquez-Abrams wrote:
> On Mon, 2008-11-24 at 13:09 -0500, Bill Nottingham wrote:
> > Seth Vidal (skvidal at fedoraproject.org) said: 
> > > So, unless everyone is comfy with rawhide being broken for most of the  
> > > rest of the week, I'd suggest we delay the import of python 2.6 until  
> > > after the weekend and a huge portion of the americans in working on 
> > > fedora get back from thanksgiving food comas.
> > 
> > I'm taking it from the original mail that the python maintainers do
> > not want to trigger the rebuilds?
> 
> I don't mind doing some of them, but there are almost 700 total and
> there's no way I can get that many done in a timely fashion.

You might consider a separate koji tag for this effort, similar to what
I did for perl in the F9 timeframe.

~spot



From katzj at redhat.com  Mon Nov 24 18:23:01 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 24 Nov 2008 13:23:01 -0500
Subject: It's all ASPLODY!
In-Reply-To: <1227550713.4519.52.camel@localhost.localdomain>
References: <1227549240.6715.44.camel@ignacio.lan>
	<alpine.LFD.2.00.0811241256420.13683@localhost.localdomain>
	<20081124180909.GB3145@nostromo.devel.redhat.com>
	<1227550574.6715.45.camel@ignacio.lan>
	<1227550713.4519.52.camel@localhost.localdomain>
Message-ID: <1227550981.13169.58.camel@aglarond.local>

On Mon, 2008-11-24 at 13:18 -0500, Tom "spot" Callaway wrote:
> On Mon, 2008-11-24 at 13:16 -0500, Ignacio Vazquez-Abrams wrote:
> > On Mon, 2008-11-24 at 13:09 -0500, Bill Nottingham wrote:
> > > Seth Vidal (skvidal at fedoraproject.org) said: 
> > > > So, unless everyone is comfy with rawhide being broken for most of the  
> > > > rest of the week, I'd suggest we delay the import of python 2.6 until  
> > > > after the weekend and a huge portion of the americans in working on 
> > > > fedora get back from thanksgiving food comas.
> > > 
> > > I'm taking it from the original mail that the python maintainers do
> > > not want to trigger the rebuilds?
> > 
> > I don't mind doing some of them, but there are almost 700 total and
> > there's no way I can get that many done in a timely fashion.
> 
> You might consider a separate koji tag for this effort, similar to what
> I did for perl in the F9 timeframe.

It's also what we've done for python in the past.  It's good to at least
get the stack up through yum and friends building and working before
thrusting the new python upon everyone as otherwise it's quite difficult
for people to even try to fix things on their own.

Jeremy



From icon at fedoraproject.org  Mon Nov 24 18:30:29 2008
From: icon at fedoraproject.org (Konstantin Ryabitsev)
Date: Mon, 24 Nov 2008 13:30:29 -0500
Subject: pgadmin3 gone from F10
Message-ID: <f8f6300f0811241030n20653930uf7a6107584d1f496@mail.gmail.com>

Hello:

The pgadmin3 package is not built for F10. I searched through the
lists, but I couldn't find the reason -- it was just removed back in
September and never added again.

It builds and runs just fine on F10, so I'm quite perplexed about
what's going on. Anyone has any clues?

Regards,
-- 
Konstantin Ryabitsev
Montr?al, Qu?bec



From skvidal at fedoraproject.org  Mon Nov 24 18:33:24 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 24 Nov 2008 13:33:24 -0500 (EST)
Subject: It's all ASPLODY!
In-Reply-To: <1227550981.13169.58.camel@aglarond.local>
References: <1227549240.6715.44.camel@ignacio.lan>
	<alpine.LFD.2.00.0811241256420.13683@localhost.localdomain>
	<20081124180909.GB3145@nostromo.devel.redhat.com>
	<1227550574.6715.45.camel@ignacio.lan>
	<1227550713.4519.52.camel@localhost.localdomain>
	<1227550981.13169.58.camel@aglarond.local>
Message-ID: <alpine.LFD.2.00.0811241328020.13683@localhost.localdomain>



On Mon, 24 Nov 2008, Jeremy Katz wrote:

> It's also what we've done for python in the past.  It's good to at least
> get the stack up through yum and friends building and working before
> thrusting the new python upon everyone as otherwise it's quite difficult
> for people to even try to fix things on their own.

So we'll need:

- pygpgme
- python-iniparse
- python-urlgrabber
- rpm-python
- yum-metadata-parser (python module)


-sv



From tcallawa at redhat.com  Mon Nov 24 18:33:26 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 24 Nov 2008 13:33:26 -0500
Subject: pgadmin3 gone from F10
In-Reply-To: <f8f6300f0811241030n20653930uf7a6107584d1f496@mail.gmail.com>
References: <f8f6300f0811241030n20653930uf7a6107584d1f496@mail.gmail.com>
Message-ID: <1227551606.4519.54.camel@localhost.localdomain>

On Mon, 2008-11-24 at 13:30 -0500, Konstantin Ryabitsev wrote:
> Hello:
> 
> The pgadmin3 package is not built for F10. I searched through the
> lists, but I couldn't find the reason -- it was just removed back in
> September and never added again.
> 
> It builds and runs just fine on F10, so I'm quite perplexed about
> what's going on. Anyone has any clues?

Licensing. It was under Artistic 1.0 only, and while upstream was
working towards relicensing, due to a variety of legal concerns, they
were not able to get it done in the F10 timeframe. As soon as they
manage to relicense, we should be able to push it as an update.

See: http://fedoraproject.org/wiki/Features/Artistic1Removal#pgadmin3

~spot



From icon at fedoraproject.org  Mon Nov 24 18:37:13 2008
From: icon at fedoraproject.org (Konstantin Ryabitsev)
Date: Mon, 24 Nov 2008 13:37:13 -0500
Subject: It's all ASPLODY!
In-Reply-To: <alpine.LFD.2.00.0811241328020.13683@localhost.localdomain>
References: <1227549240.6715.44.camel@ignacio.lan>
	<alpine.LFD.2.00.0811241256420.13683@localhost.localdomain>
	<20081124180909.GB3145@nostromo.devel.redhat.com>
	<1227550574.6715.45.camel@ignacio.lan>
	<1227550713.4519.52.camel@localhost.localdomain>
	<1227550981.13169.58.camel@aglarond.local>
	<alpine.LFD.2.00.0811241328020.13683@localhost.localdomain>
Message-ID: <f8f6300f0811241037m4ccc434ex97c21b115da0ac74@mail.gmail.com>

On Mon, Nov 24, 2008 at 1:33 PM, Seth Vidal <skvidal at fedoraproject.org> wrote:
> On Mon, 24 Nov 2008, Jeremy Katz wrote:
>
>> It's also what we've done for python in the past.  It's good to at least
>> get the stack up through yum and friends building and working before
>> thrusting the new python upon everyone as otherwise it's quite difficult
>> for people to even try to fix things on their own.
>
> So we'll need:
>
> - pygpgme
> - python-iniparse
> - python-urlgrabber
> - rpm-python
> - yum-metadata-parser (python module)

python-setuptools will need to work for most other python packages to build.

Cheers,
-- 
Konstantin Ryabitsev
Montr?al, Qu?bec



From skvidal at fedoraproject.org  Mon Nov 24 18:41:35 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 24 Nov 2008 13:41:35 -0500 (EST)
Subject: It's all ASPLODY!
In-Reply-To: <f8f6300f0811241037m4ccc434ex97c21b115da0ac74@mail.gmail.com>
References: <1227549240.6715.44.camel@ignacio.lan>
	<alpine.LFD.2.00.0811241256420.13683@localhost.localdomain>
	<20081124180909.GB3145@nostromo.devel.redhat.com>
	<1227550574.6715.45.camel@ignacio.lan>
	<1227550713.4519.52.camel@localhost.localdomain>
	<1227550981.13169.58.camel@aglarond.local>
	<alpine.LFD.2.00.0811241328020.13683@localhost.localdomain>
	<f8f6300f0811241037m4ccc434ex97c21b115da0ac74@mail.gmail.com>
Message-ID: <alpine.LFD.2.00.0811241341010.13683@localhost.localdomain>



On Mon, 24 Nov 2008, Konstantin Ryabitsev wrote:

> On Mon, Nov 24, 2008 at 1:33 PM, Seth Vidal <skvidal at fedoraproject.org> wrote:
>> On Mon, 24 Nov 2008, Jeremy Katz wrote:
>>
>>> It's also what we've done for python in the past.  It's good to at least
>>> get the stack up through yum and friends building and working before
>>> thrusting the new python upon everyone as otherwise it's quite difficult
>>> for people to even try to fix things on their own.
>>
>> So we'll need:
>>
>> - pygpgme
>> - python-iniparse
>> - python-urlgrabber
>> - rpm-python
>> - yum-metadata-parser (python module)
>
> python-setuptools will need to work for most other python packages to build.

Good point. Shouldn't be too much beyond that, though.

-sv





From ivazqueznet at gmail.com  Mon Nov 24 18:41:18 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Mon, 24 Nov 2008 13:41:18 -0500
Subject: It's all ASPLODY!
In-Reply-To: <1227550713.4519.52.camel@localhost.localdomain>
References: <1227549240.6715.44.camel@ignacio.lan>
	<alpine.LFD.2.00.0811241256420.13683@localhost.localdomain>
	<20081124180909.GB3145@nostromo.devel.redhat.com>
	<1227550574.6715.45.camel@ignacio.lan>
	<1227550713.4519.52.camel@localhost.localdomain>
Message-ID: <1227552078.6715.47.camel@ignacio.lan>

On Mon, 2008-11-24 at 13:18 -0500, Tom "spot" Callaway wrote:
> You might consider a separate koji tag for this effort, similar to what
> I did for perl in the F9 timeframe.

I can do that. Just point me in the right direction please.

-- 
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/20081124/20568427/attachment.sig>

From ivazqueznet at gmail.com  Mon Nov 24 18:43:10 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Mon, 24 Nov 2008 13:43:10 -0500
Subject: It's all ASPLODY!
In-Reply-To: <alpine.LFD.2.00.0811241328020.13683@localhost.localdomain>
References: <1227549240.6715.44.camel@ignacio.lan>
	<alpine.LFD.2.00.0811241256420.13683@localhost.localdomain>
	<20081124180909.GB3145@nostromo.devel.redhat.com>
	<1227550574.6715.45.camel@ignacio.lan>
	<1227550713.4519.52.camel@localhost.localdomain>
	<1227550981.13169.58.camel@aglarond.local>
	<alpine.LFD.2.00.0811241328020.13683@localhost.localdomain>
Message-ID: <1227552190.6715.50.camel@ignacio.lan>

On Mon, 2008-11-24 at 13:33 -0500, Seth Vidal wrote:
> On Mon, 24 Nov 2008, Jeremy Katz wrote:
> 
> > It's also what we've done for python in the past.  It's good to at least
> > get the stack up through yum and friends building and working before
> > thrusting the new python upon everyone as otherwise it's quite difficult
> > for people to even try to fix things on their own.
> 
> So we'll need:
> 
> - pygpgme
> - python-iniparse
> - python-urlgrabber
> - rpm-python
> - yum-metadata-parser (python module)

I got all those but python-iniparse (and y-m-p, which I didn't try)
built locally, and it only failed because of local reasons (i.e., I
didn't bump the release, I just rebuilt the SRPM as-is).

-- 
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/20081124/3e56ef79/attachment.sig>

From tcallawa at redhat.com  Mon Nov 24 18:58:04 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 24 Nov 2008 13:58:04 -0500
Subject: It's all ASPLODY!
In-Reply-To: <1227552078.6715.47.camel@ignacio.lan>
References: <1227549240.6715.44.camel@ignacio.lan>
	<alpine.LFD.2.00.0811241256420.13683@localhost.localdomain>
	<20081124180909.GB3145@nostromo.devel.redhat.com>
	<1227550574.6715.45.camel@ignacio.lan>
	<1227550713.4519.52.camel@localhost.localdomain>
	<1227552078.6715.47.camel@ignacio.lan>
Message-ID: <1227553084.4519.55.camel@localhost.localdomain>

On Mon, 2008-11-24 at 13:41 -0500, Ignacio Vazquez-Abrams wrote:
> On Mon, 2008-11-24 at 13:18 -0500, Tom "spot" Callaway wrote:
> > You might consider a separate koji tag for this effort, similar to what
> > I did for perl in the F9 timeframe.
> 
> I can do that. Just point me in the right direction please.

Rel-eng should be able to make the tag for you and setup the
inheritance. Just open a trac ticket: https://fedorahosted.org/rel-eng/

~spot





From jos at xos.nl  Mon Nov 24 19:17:38 2008
From: jos at xos.nl (Jos Vos)
Date: Mon, 24 Nov 2008 20:17:38 +0100
Subject: No X on F9/F10 with Intel 82915G/GV/910GL
In-Reply-To: <1227550496.23765.24.camel@atropine.boston.devel.redhat.com>
References: <200811241511.mAOFBDo0019062@jasmine.xos.nl>
	<1227545424.23765.19.camel@atropine.boston.devel.redhat.com>
	<20081124165746.GA20250@jasmine.xos.nl>
	<1227550496.23765.24.camel@atropine.boston.devel.redhat.com>
Message-ID: <20081124191738.GA22039@jasmine.xos.nl>

On Mon, Nov 24, 2008 at 01:14:56PM -0500, Adam Jackson wrote:

> Very strange.  What kind of display is it?  Are you using an SDVO card
> (pseudo-PCIE looking thing with a tiny chip on one side and a DVI or
> whatever connector on the other)?

It's a completely integrated system with a 15" LCD display (with serial
Elo touchscreen option), the IBM SurePOS 565:

http://www-03.ibm.com/products/retail/products/pos/500/specs_eu.html
http://www-03.ibm.com/products/retail/products/pos/500/prodview.html

AFAIK the graphic chip is on the mainboard, but I'm not sure.

On RHEL4 (currently used in production) and RHEL5 (tested a few times)
I had to do some small tweaking to make it all work, like specifying
"nofb" as kernel option, turning off acceleration ("NoAccel" "yes"),
turning of acpi (mainly because of disk/USB problems), etc.

I didn't try all combinations of tweaks yet, but AFAIK I never had a
full black screen in RHELx, only other strange effects (like a display
that 30% shifted vertically).

-- 
--    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 lsof at nodata.co.uk  Mon Nov 24 19:21:54 2008
From: lsof at nodata.co.uk (nodata)
Date: Mon, 24 Nov 2008 20:21:54 +0100
Subject: NetworkManager cli docs
In-Reply-To: <1227542437.564.24.camel@localhost.localdomain>
References: <1227447232.3721.1.camel@sb-home>
	<1227542437.564.24.camel@localhost.localdomain>
Message-ID: <1227554514.7267.1.camel@sb-home>

Am Montag, den 24.11.2008, 11:00 -0500 schrieb Dan Williams:
> On Sun, 2008-11-23 at 14:33 +0100, nodata wrote:
> > Hi,
> > 
> > Can anyone point me at the docs for configuring NetworkManager without
> > the tray applet?
> > 
> > I've tried google, the gnome.org nm page, and the man pages. I can't
> > find a thing.
> 
> NetworkManager provides a D-Bus API for controlling network connections,
> as seen here:  http://people.redhat.com/dcbw/NetworkManager/spec.html .
> 
> For setting up network connections without a user settings service,
> NetworkManager provides a system-wide settings service which reads
> ifcfg-* files like you'd normally create on Fedora.  Be sure to set
> NM_CONTROLLED=yes, and NetworkManager should pick them up and use them
> as long as ONBOOT=yes (which means bring it up automatically).
> 
> Dan
> 
> 

Thanks for this. I've got two more questions:

1. How will users find out about this? I can't find any documentation
without using the magic NM_CONTROLLED search term.
2. Is there a cli network manager tool planned for Fedora?




From ville.skytta at iki.fi  Mon Nov 24 19:25:20 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Mon, 24 Nov 2008 21:25:20 +0200
Subject: It's all ASPLODY!
In-Reply-To: <1227549240.6715.44.camel@ignacio.lan>
References: <1227549240.6715.44.camel@ignacio.lan>
Message-ID: <200811242125.20930.ville.skytta@iki.fi>

On Monday 24 November 2008, Ignacio Vazquez-Abrams wrote:

> Within the next few days Python 2.6 will be imported into Rawhide. This
> means that EVERY single Python-based package in Rawhide will be broken,

Hmm, to clarify: really every one, or "just" every one that installs files 
into versioned python dirs and/or depends on versioned python(abi)?

If a package installs some *.py, *.pyc, *.pyo somewhere else than in versioned 
python dirs, and the source *.py is python 2.6 compatible, will the *.pyc and 
*.pyo compiled with 2.5 break with 2.6?  For example, is it 
necessary/beneficial to rebuild packages like rpmlint (all its python code is 
either in /usr/bin or /usr/share/rpmlint)?



From notting at redhat.com  Mon Nov 24 19:48:15 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 24 Nov 2008 14:48:15 -0500
Subject: "nousb" poll
In-Reply-To: <1227376350.5833.30.camel@beck.corsepiu.local>
References: <20081122103552.86a26420.zaitcev@redhat.com>
	<1227376350.5833.30.camel@beck.corsepiu.local>
Message-ID: <20081124194815.GC3145@nostromo.devel.redhat.com>

Ralf Corsepius (rc040203 at freenet.de) said: 
> Yes, I am.
> 
> Typically on older machines,
> * which don't have USB.

... in which case nousb does nothing.

> * on which USB is too uneffective to be useful (e.g. only have USB-1.x)

... in which case nousb only saves a bit of time on boot initializing
the controller.

> <sigh/> another nail in Fedora's coffin on low end platforms?

Given that all it does is tell a built-in module to not initialize,
I don't see how it afffects low end at all - it certainly doesn't
save you any memory.

Bill



From lesmikesell at gmail.com  Mon Nov 24 19:48:34 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 24 Nov 2008 13:48:34 -0600
Subject: It's all ASPLODY!
In-Reply-To: <1227550713.4519.52.camel@localhost.localdomain>
References: <1227549240.6715.44.camel@ignacio.lan>	<alpine.LFD.2.00.0811241256420.13683@localhost.localdomain>	<20081124180909.GB3145@nostromo.devel.redhat.com>	<1227550574.6715.45.camel@ignacio.lan>
	<1227550713.4519.52.camel@localhost.localdomain>
Message-ID: <492B0512.5010506@gmail.com>

Tom "spot" Callaway wrote:
> 
> 
> You might consider a separate koji tag for this effort, similar to what
> I did for perl in the F9 timeframe.
> 

What perl regression was introduced in F9?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From notting at redhat.com  Mon Nov 24 19:51:57 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 24 Nov 2008 14:51:57 -0500
Subject: rawhide report: 20081123 changes
In-Reply-To: <492A4D1F.4060805@leemhuis.info>
References: <20081123124303.D51D41F823B@releng2.fedora.phx.redhat.com>
	<492A4D1F.4060805@leemhuis.info>
Message-ID: <20081124195157.GD3145@nostromo.devel.redhat.com>

Thorsten Leemhuis (fedora at leemhuis.info) said: 
> In addition: Why does
> http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f$releasever&arch=$basearch
> still point to the rawhide repos? There are a lot of proper and test  
> updates that IMHO could benefit from some testing before F10 hits the  
> streets.

This should be fixed now.

Bill



From jkeating at redhat.com  Mon Nov 24 19:53:01 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 24 Nov 2008 11:53:01 -0800
Subject: It's all ASPLODY!
In-Reply-To: <492B0512.5010506@gmail.com>
References: <1227549240.6715.44.camel@ignacio.lan>
	<alpine.LFD.2.00.0811241256420.13683@localhost.localdomain>
	<20081124180909.GB3145@nostromo.devel.redhat.com>
	<1227550574.6715.45.camel@ignacio.lan>
	<1227550713.4519.52.camel@localhost.localdomain>
	<492B0512.5010506@gmail.com>
Message-ID: <1227556381.28543.711.camel@luminos.localdomain>

On Mon, 2008-11-24 at 13:48 -0600, Les Mikesell wrote:
> 
> What perl regression was introduced in F9?

Perl was updated from 5.8 to 5.10 for Fedora 9.  If you want to call
that a regression, have fun in your little fantasy 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/20081124/509d969c/attachment.sig>

From notting at redhat.com  Mon Nov 24 19:56:20 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 24 Nov 2008 14:56:20 -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: <20081124195620.GE3145@nostromo.devel.redhat.com>

David Zeuthen (davidz at redhat.com) said: 
> 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.
> 
> This has been a public service announcement.

Does it actually serve a purpose? Should it just be removed?

Bill



From bkoz at redhat.com  Mon Nov 24 20:05:49 2008
From: bkoz at redhat.com (Benjamin Kosnik)
Date: Mon, 24 Nov 2008 12:05:49 -0800
Subject: f11 boost-1.37.0 upgrade: notice of intent, and best way to
Message-ID: <20081124120549.5107aced@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

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.

best,
benjamin



From mclasen at redhat.com  Mon Nov 24 20:07:31 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Mon, 24 Nov 2008 15:07:31 -0500
Subject: orphaning gnome-volume-manager
In-Reply-To: <20081124195620.GE3145@nostromo.devel.redhat.com>
References: <1227544518.11161.19.camel@x61.fubar.dk>
	<20081124195620.GE3145@nostromo.devel.redhat.com>
Message-ID: <1227557251.3275.16.camel@localhost.localdomain>

On Mon, 2008-11-24 at 14:56 -0500, Bill Nottingham wrote:
> David Zeuthen (davidz at redhat.com) said: 
> > 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.
> > 
> > This has been a public service announcement.
> 
> Does it actually serve a purpose? Should it just be removed?

We don't think it serves a useful purpose, but it doesn't do any harm.
So, if people want to keep using it, there is nothing wrong with taking
over the maintainership of the package. Otherwise, it'll just silently
vanish in F11.



From dcbw at redhat.com  Mon Nov 24 20:14:01 2008
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 24 Nov 2008 15:14:01 -0500
Subject: NetworkManager cli docs
In-Reply-To: <1227554514.7267.1.camel@sb-home>
References: <1227447232.3721.1.camel@sb-home>
	<1227542437.564.24.camel@localhost.localdomain>
	<1227554514.7267.1.camel@sb-home>
Message-ID: <1227557641.25089.10.camel@localhost.localdomain>

On Mon, 2008-11-24 at 20:21 +0100, nodata wrote:
> Am Montag, den 24.11.2008, 11:00 -0500 schrieb Dan Williams:
> > On Sun, 2008-11-23 at 14:33 +0100, nodata wrote:
> > > Hi,
> > > 
> > > Can anyone point me at the docs for configuring NetworkManager without
> > > the tray applet?
> > > 
> > > I've tried google, the gnome.org nm page, and the man pages. I can't
> > > find a thing.
> > 
> > NetworkManager provides a D-Bus API for controlling network connections,
> > as seen here:  http://people.redhat.com/dcbw/NetworkManager/spec.html .
> > 
> > For setting up network connections without a user settings service,
> > NetworkManager provides a system-wide settings service which reads
> > ifcfg-* files like you'd normally create on Fedora.  Be sure to set
> > NM_CONTROLLED=yes, and NetworkManager should pick them up and use them
> > as long as ONBOOT=yes (which means bring it up automatically).
> > 
> > Dan
> > 
> > 
> 
> Thanks for this. I've got two more questions:
> 
> 1. How will users find out about this? I can't find any documentation
> without using the magic NM_CONTROLLED search term.

What exactly are you trying to find out?  For the most part, if you have
an ifcfg file that doesn't use bridges or aliases, NM will just pick it
up and handle it provided NM_CONTROLLED=yes or is absent.  NM_CONTROLLED
is about as well documented as any of the other options in ifcfg files.

> 2. Is there a cli network manager tool planned for Fedora?

Yes.

Dan




From lesmikesell at gmail.com  Mon Nov 24 20:15:34 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 24 Nov 2008 14:15:34 -0600
Subject: It's all ASPLODY!
In-Reply-To: <1227556381.28543.711.camel@luminos.localdomain>
References: <1227549240.6715.44.camel@ignacio.lan>	<alpine.LFD.2.00.0811241256420.13683@localhost.localdomain>	<20081124180909.GB3145@nostromo.devel.redhat.com>	<1227550574.6715.45.camel@ignacio.lan>	<1227550713.4519.52.camel@localhost.localdomain>	<492B0512.5010506@gmail.com>
	<1227556381.28543.711.camel@luminos.localdomain>
Message-ID: <492B0B66.3040901@gmail.com>

Jesse Keating wrote:
> On Mon, 2008-11-24 at 13:48 -0600, Les Mikesell wrote:
>> What perl regression was introduced in F9?
> 
> Perl was updated from 5.8 to 5.10 for Fedora 9.  If you want to call
> that a regression, have fun in your little fantasy world.

Did that trigger a need to rebuild anything? The only 
non-backwards-compatible change I've ever seen in perl was when it 
started to interpolate @ in double-quoted strings between 4.x and 5.x.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jkeating at redhat.com  Mon Nov 24 20:19:40 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 24 Nov 2008 12:19:40 -0800
Subject: It's all ASPLODY!
In-Reply-To: <492B0B66.3040901@gmail.com>
References: <1227549240.6715.44.camel@ignacio.lan>
	<alpine.LFD.2.00.0811241256420.13683@localhost.localdomain>
	<20081124180909.GB3145@nostromo.devel.redhat.com>
	<1227550574.6715.45.camel@ignacio.lan>
	<1227550713.4519.52.camel@localhost.localdomain>
	<492B0512.5010506@gmail.com>
	<1227556381.28543.711.camel@luminos.localdomain>
	<492B0B66.3040901@gmail.com>
Message-ID: <1227557980.28543.712.camel@luminos.localdomain>

On Mon, 2008-11-24 at 14:15 -0600, Les Mikesell wrote:
> 
> > Perl was updated from 5.8 to 5.10 for Fedora 9.  If you want to call
> > that a regression, have fun in your little fantasy world.
> 
> Did that trigger a need to rebuild anything? The only 
> non-backwards-compatible change I've ever seen in perl was when it 
> started to interpolate @ in double-quoted strings between 4.x and 5.x.

Yes, for a variety of reasons the packages needed to be rebuilt.  Many
had to be altered too, as many things were brought into perl core that
were addons previously, and rpm spec files had to be adjusted.  Spot can
fill you in on the more technical details.

-- 
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/20081124/9317ec52/attachment.sig>

From ivazqueznet at gmail.com  Mon Nov 24 20:04:20 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Mon, 24 Nov 2008 15:04:20 -0500
Subject: It's all ASPLODY!
In-Reply-To: <200811242125.20930.ville.skytta@iki.fi>
References: <1227549240.6715.44.camel@ignacio.lan>
	<200811242125.20930.ville.skytta@iki.fi>
Message-ID: <1227557060.6715.54.camel@ignacio.lan>

On Mon, 2008-11-24 at 21:25 +0200, Ville Skytt? wrote:
> On Monday 24 November 2008, Ignacio Vazquez-Abrams wrote:
> 
> > Within the next few days Python 2.6 will be imported into Rawhide. This
> > means that EVERY single Python-based package in Rawhide will be broken,
> 
> Hmm, to clarify: really every one, or "just" every one that installs files 
> into versioned python dirs and/or depends on versioned python(abi)?
> 
> If a package installs some *.py, *.pyc, *.pyo somewhere else than in versioned 
> python dirs, and the source *.py is python 2.6 compatible, will the *.pyc and 
> *.pyo compiled with 2.5 break with 2.6?  For example, is it 
> necessary/beneficial to rebuild packages like rpmlint (all its python code is 
> either in /usr/bin or /usr/share/rpmlint)?

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.

-- 
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/20081124/86369a9a/attachment.sig>

From ajax at redhat.com  Mon Nov 24 20:40:47 2008
From: ajax at redhat.com (Adam Jackson)
Date: Mon, 24 Nov 2008 15:40:47 -0500
Subject: No X on F9/F10 with Intel 82915G/GV/910GL
In-Reply-To: <20081124191738.GA22039@jasmine.xos.nl>
References: <200811241511.mAOFBDo0019062@jasmine.xos.nl>
	<1227545424.23765.19.camel@atropine.boston.devel.redhat.com>
	<20081124165746.GA20250@jasmine.xos.nl>
	<1227550496.23765.24.camel@atropine.boston.devel.redhat.com>
	<20081124191738.GA22039@jasmine.xos.nl>
Message-ID: <1227559247.23765.54.camel@atropine.boston.devel.redhat.com>

On Mon, 2008-11-24 at 20:17 +0100, Jos Vos wrote:
> On Mon, Nov 24, 2008 at 01:14:56PM -0500, Adam Jackson wrote:
> 
> > Very strange.  What kind of display is it?  Are you using an SDVO card
> > (pseudo-PCIE looking thing with a tiny chip on one side and a DVI or
> > whatever connector on the other)?
> 
> It's a completely integrated system with a 15" LCD display (with serial
> Elo touchscreen option), the IBM SurePOS 565:
> 
> http://www-03.ibm.com/products/retail/products/pos/500/specs_eu.html
> http://www-03.ibm.com/products/retail/products/pos/500/prodview.html
> 
> AFAIK the graphic chip is on the mainboard, but I'm not sure.
> 
> On RHEL4 (currently used in production) and RHEL5 (tested a few times)
> I had to do some small tweaking to make it all work, like specifying
> "nofb" as kernel option, turning off acceleration ("NoAccel" "yes"),
> turning of acpi (mainly because of disk/USB problems), etc.
> 
> I didn't try all combinations of tweaks yet, but AFAIK I never had a
> full black screen in RHELx, only other strange effects (like a display
> that 30% shifted vertically).

In RHEL5 you'd still be using the old BIOS-based i810 driver (assuming
you installed with 5.1 or older), which might work through blind luck.

The current theory is that it's trying to do LVDS over SDVO, which is a
bit insane since it has LVDS on the board already, and that's a path
that the driver currently doesn't support.  If we could get copies of
the video BIOS (and some testing time, if you're up for it) we can
probably work with intel to get it going.  Probably best to do that in a
bug, either in fedora or freedesktop bugzilla.

- 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/20081124/c7e162ec/attachment.sig>

From tcallawa at redhat.com  Mon Nov 24 20:41:02 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 24 Nov 2008 15:41:02 -0500
Subject: It's all ASPLODY!
In-Reply-To: <1227557980.28543.712.camel@luminos.localdomain>
References: <1227549240.6715.44.camel@ignacio.lan>
	<alpine.LFD.2.00.0811241256420.13683@localhost.localdomain>
	<20081124180909.GB3145@nostromo.devel.redhat.com>
	<1227550574.6715.45.camel@ignacio.lan>
	<1227550713.4519.52.camel@localhost.localdomain>
	<492B0512.5010506@gmail.com>
	<1227556381.28543.711.camel@luminos.localdomain>
	<492B0B66.3040901@gmail.com>
	<1227557980.28543.712.camel@luminos.localdomain>
Message-ID: <1227559262.4519.62.camel@localhost.localdomain>

On Mon, 2008-11-24 at 12:19 -0800, Jesse Keating wrote:
> On Mon, 2008-11-24 at 14:15 -0600, Les Mikesell wrote:
> > 
> > > Perl was updated from 5.8 to 5.10 for Fedora 9.  If you want to call
> > > that a regression, have fun in your little fantasy world.
> > 
> > Did that trigger a need to rebuild anything? The only 
> > non-backwards-compatible change I've ever seen in perl was when it 
> > started to interpolate @ in double-quoted strings between 4.x and 5.x.
> 
> Yes, for a variety of reasons the packages needed to be rebuilt.  Many
> had to be altered too, as many things were brought into perl core that
> were addons previously, and rpm spec files had to be adjusted.  Spot can
> fill you in on the more technical details.

Perl is extremely major version dependent. Every perl module (basically,
anything more complex than a script) had to be rebuilt, and in many
cases, upstream bugs had to be filed and fixed before we could retain
functionality. I worked aggressively with upstream to both submit the
majority of our Fedora only perl patches into the 5.10 tree and to work
through the issues discovered during the migration.

End result: We're closer to perl upstream than we've ever been, and we
have most of the long-standing perl bugs resolved (and we fixed the
"RHEL slow perl" bug without even being aware of it as a byproduct of
the methodology).

The fact that you just noticed it means that we must have done some
things properly, you're welcome. :)

~spot



From stickster at gmail.com  Mon Nov 24 20:51:06 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Mon, 24 Nov 2008 15:51:06 -0500
Subject: NetworkManager cli docs
In-Reply-To: <1227557641.25089.10.camel@localhost.localdomain>
References: <1227447232.3721.1.camel@sb-home>
	<1227542437.564.24.camel@localhost.localdomain>
	<1227554514.7267.1.camel@sb-home>
	<1227557641.25089.10.camel@localhost.localdomain>
Message-ID: <20081124205106.GR22173@salma.internal.frields.org>

On Mon, Nov 24, 2008 at 03:14:01PM -0500, Dan Williams wrote:
> On Mon, 2008-11-24 at 20:21 +0100, nodata wrote:
> > Am Montag, den 24.11.2008, 11:00 -0500 schrieb Dan Williams:
> > > On Sun, 2008-11-23 at 14:33 +0100, nodata wrote:
> > > > 
> > > > Can anyone point me at the docs for configuring NetworkManager without
> > > > the tray applet?
> > > > 
> > > > I've tried google, the gnome.org nm page, and the man pages. I can't
> > > > find a thing.
> > > 
> > > NetworkManager provides a D-Bus API for controlling network connections,
> > > as seen here:  http://people.redhat.com/dcbw/NetworkManager/spec.html .
> > > 
> > > For setting up network connections without a user settings service,
> > > NetworkManager provides a system-wide settings service which reads
> > > ifcfg-* files like you'd normally create on Fedora.  Be sure to set
> > > NM_CONTROLLED=yes, and NetworkManager should pick them up and use them
> > > as long as ONBOOT=yes (which means bring it up automatically).
> > 
> > Thanks for this. I've got two more questions:
> > 
> > 1. How will users find out about this? I can't find any documentation
> > without using the magic NM_CONTROLLED search term.
> 
> What exactly are you trying to find out?  For the most part, if you have
> an ifcfg file that doesn't use bridges or aliases, NM will just pick it
> up and handle it provided NM_CONTROLLED=yes or is absent.  NM_CONTROLLED
> is about as well documented as any of the other options in ifcfg files.

That's a bug maybe worth filing against initscripts; the
/usr/share/doc/initscripts-*/sysconfig.txt file is fairly useful but
may have slipped out of currency.

-- 
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/20081124/5a0b4b1f/attachment.sig>

From notting at redhat.com  Mon Nov 24 20:57:32 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 24 Nov 2008 15:57:32 -0500
Subject: NetworkManager cli docs
In-Reply-To: <20081124205106.GR22173@salma.internal.frields.org>
References: <1227447232.3721.1.camel@sb-home>
	<1227542437.564.24.camel@localhost.localdomain>
	<1227554514.7267.1.camel@sb-home>
	<1227557641.25089.10.camel@localhost.localdomain>
	<20081124205106.GR22173@salma.internal.frields.org>
Message-ID: <20081124205732.GB6522@nostromo.devel.redhat.com>

Paul W. Frields (stickster at gmail.com) said: 
> That's a bug maybe worth filing against initscripts; the
> /usr/share/doc/initscripts-*/sysconfig.txt file is fairly useful but
> may have slipped out of currency.

It wasn't documented because it was inveted late and actually has no
bearing on the old network ifup/ifdown scripts at all. Hence, if
you're configuring by hand, it serves no purpose.

Bill



From seg at haxxed.com  Mon Nov 24 21:19:35 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Mon, 24 Nov 2008 15:19:35 -0600
Subject: My roadmap for a better Fedora
In-Reply-To: <1227152010.3752.767.camel@beck.corsepiu.local>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<604aa7910811191107u4dc41d6eubdc634e14174ede8@mail.gmail.com>
	<1227152010.3752.767.camel@beck.corsepiu.local>
Message-ID: <1227561575.4755.206.camel@localhost.localdomain>

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.

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.

IMHO I think discrete releases are one of our most powerful features. We
can make drastic changes across the distribution, in an atomic manner.
We want to preserve this feature. It allows us to make a clean break
with previous releases. It allows us to make irreversible changes.

Although no change to a filesystem is truly irreversible, as long as you
have enough storage space... :)

For rollback of distribution release updates, a lower level filesystem
rollback is much more suitable, via LVM snapshots or Btrfs...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081124/ec137599/attachment.sig>

From seg at haxxed.com  Mon Nov 24 21:33:33 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Mon, 24 Nov 2008 15:33:33 -0600
Subject: My roadmap for a better Fedora
In-Reply-To: <1227130942.2889.15.camel@gilboa-home-dev.localdomain>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<1227130942.2889.15.camel@gilboa-home-dev.localdomain>
Message-ID: <1227562413.4755.234.camel@localhost.localdomain>

On Wed, 2008-11-19 at 23:42 +0200, Gilboa Davara wrote:
> Though you're missing thing - automated bug report system generate
> -huge- amount of noise. Lowering the signal-to-noise ratio to something
> usable is -very- labor intensive.
> Far worse, people (who send such report) tend to forget about them (as
> opposed to manual bug reports) making them far less effective.

I don't even think we should be sending people directly to bugzilla in
the first place. That's a whole other rant for another message... :)

> So, question is:
> A. Who will do the heavy lifting of developing such system?

Dunno. Whoever feels motivated to do so. :) If I'm the only one who
thinks this all is a good idea, so be it.

> B. Who will triage 1000's of orphaned bug reports.

We already have that problem... Stale bugs get auto closed when the
release goes EOL...
 
> > 2) Make it simple to roll back to a known good state. We need a "system
> > restore". I know what you're thinking, but our vastly superior,
> > centralized, system-wide package management (and lack of a whole
> > seperate "system registry" namespace) allows us to make this actually
> > work. We need per-package rollback. Period.
> 
> Assuming, of course, that you can pin-point what exactly broken
> evolution within the 150 package update push.

You *already* have to do that to get a bug fixed. It's not a new
problem.

> Will you roll back all the updates?

The "Aunt Tillie" answer would be yes.

> Only updates that had -something- to do with the breakage?

If the user has some idea of such, they should have this option.

>  (Let alone kernel updates that can more-or-less
> break everything in sight...)

How do you mean? There's a reason I said we need a rescue image
in /boot... :)

> Oh, and what do you do when at least 50% of these updates are
> high-priority security updates?

Only rollback the non-security updates. If that doesn't work, then roll
those back too.

Yes, security updates are a bit of a confounding issue, but this is
exactly why I say it needs to be per-package rollback. So you can have
this kind of selectivity, rather than being forced to roll back the
entire transaction.

We could split the transaction in the first place. First do only
security updates, then upgrade everything else. Then you have two clear
points to roll back to.

Think of this as a "git bisect" for your entire system. Roll the system
back and forth until you figure out what update broke things...

> > 3) Make it so yum will refuse to upgrade the package rolled back in step
> > 2 until the bug reported in step 1 is fixed.
> 
> Say-what?!?
> Are we building a second Vista here?

I avoid vista like the plague so I don't know what you mean here.

The idea is to hold the system in a known good state, avoiding a known
bad state.

As it is now, if I manually "roll back" a package, yum will gleefully
upgrade it again unless I remember to put an --exclude on every yum
command line or go muck about in the repo files.

This is all about simplifying and automating laborious crap I'm
*already* doing manually.

> > 4) For when things go really wrong, we need a rescue image in /boot. All
> > the above functionality must be available inside the rescue environment.
> 
> /+100.
> Though this idea has come up a number of times before. AFAIR it was
> dropped due to space considerations and possible kernel-version
> problems. (In theory, you may need a different rescue image for each
> installed kernel - unless you plan to keep the original kernel)

I do believe it was my idea. :)

I don't know what you mean by kernel compatability. My whole idea behind
the rescue image in /boot is to be exactly like booting a rescue CD.
Ideally they should be byte-for-byte identical. The rescue image is set
in stone at the beginning of a release.

The advantages are:

- It's automatically kept up to date with the distribution version.

- It's automatically matches the architecture.

- A number of my systems don't even have CDROMS, and aren't capable of
booting from USB.

It would be so nice for a rescue image to just BE THERE when I need
it...

> > 5) So how do bugs get fixed? Make it easy to cherry pick updates from
> > updates-testing or even direct from bodhi. How useful is it to blindly
> > follow every update in updates testing? For most users, it's useless.
> > Such adventurous people should probably just run rawhide... What we
> > really need is to make it easy to pick a specific release of an update
> > to try, such as if a user is directed to in a bug report. A user should
> > just be able to click on a link given in the bug report and have the
> > update installed. Available updates and the reasons for them needs to be
> > more discoverable. Don't forget step #2.
> 
> Not sure what that means.
> You can always enable updates-testing and selectively install what you
> need.

Yeah, it's technically possible but the user interface needs integration
and improvement. :)

> Yes, but in the is case, the UI has a profound influence on the why
> Fedora works.

PARSE ERROR?

> On a side note, I'm not sure what you're trying to achieve by this last
> paragraph. But if you intention was to start yet-another-flame-war, I
> have a bad feeling you're on the right track.

Actually it was intended to anticipate certain unproductive tangents and
nip them in the bud. It seems to have worked.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081124/a0d72f9e/attachment.sig>

From seg at haxxed.com  Mon Nov 24 21:31:43 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Mon, 24 Nov 2008 15:31:43 -0600
Subject: My roadmap for a better Fedora
In-Reply-To: <604aa7910811191246hfa33f4gf1a5c7aa1029d59a@mail.gmail.com>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<604aa7910811191107u4dc41d6eubdc634e14174ede8@mail.gmail.com>
	<1227124866.7387.157.camel@localhost.localdomain>
	<604aa7910811191246hfa33f4gf1a5c7aa1029d59a@mail.gmail.com>
Message-ID: <1227562303.4755.231.camel@localhost.localdomain>

On Wed, 2008-11-19 at 11:46 -0900, Jeff Spaleta wrote:
> 2008/11/19 Callum Lerwick <seg at haxxed.com>:
> > There are many options here.
> >
> > 1) Ban everything that breaks rollbacks. Find some other way to do it.
> 
> these features were implemented for a reason. You grossly oversimplify
> the problem by saying "find some other way to do it."

And I think you're making things out to more complex than necessary.

> > 2) Just refuse to rollback the packages that break rollback.
> 
> How do you know they will break roll back? How do you test rollback in
> an organized way?

With automated regression tests.

> >
> > 3) A combination of both
> >
> > This is an example of where we need specific examples of scripts and
> > such that break rollback to get any farther on this.
> 
> Since noone tests for rollback there are no obvious examples of known
> rollback breakage. We don't look..we don't test... so we don't know
> what currently breaks. You'd have to take each special case...and
> attempt to trigger the condition and test for differences.  But since
> we are talking about scripted actions which could literally do pretty
> much anything...how do you set up a test which attempts to measure
> whether rollback across a trigger boundary put you back to where you
> were? How much of a different in state counts as 'break rollback'?

Well then we start testing...

Make up a copy-on-write VM image containing a stock Fedora release,
upgrade it with all current updates, then roll it all back. Diff the
filesystems before and after. Analyse the differences. Do this test
between release and updates-testing, updates and updates-testing, etc...

This will quickly give us a pretty good idea of the true extent of the
problem.  Of course, this requires developing a rollback mechanism to
test in the first place...

If this ever goes anywhere, we could have an automated system to test
rollback of all updates before they even get pushed in to
updates-testing.

Also note my reply to Ralf, I do not expect this mechanism to work
across releases.

> And then there are obsoletes. How many new obsoletes do we introduce
> in updates? Any idea? a run of repoquery against the f9 release and f9
> updates tree would be able to tell us that. When an obsolete is
> introduced in an update... can we rollback and get what we had?

Well presumably the rollback mechanism would have to keep some kind of
transaction journal anyway, log the obsoletes in the journal, and
reverse them upon rollback. "Undo" is not a new area of computer
science.

> > Is rollback a desireable feature?
> 
> That's a horrible pointless question.

On the contrary, it gives me insight into your motivations. Going in to
technical detail is an unproductive sidetrack if you're not even
understanding why I think it's such a vital feature. Such a feature is
going to require a coordinated effort across the distribution, without
the unanimous support of FESCo and board members like you, the effort is
doomed to failure...

I posted my motivations here:

http://www.redhat.com/archives/fedora-devel-list/2008-November/msg01387.html

I don't know what more I can say than that...

> There are many features which
> are desirable..but not necessary easily compatible with each other.
> Drop dead easy smooth upgrades are not necesssarily going to be
> compatible with rollback.  So the right question is.... is rollback
> more desirable than other packaging features.

Well my argument here is the alternative is getting stuck with a broken
system. A broken system is as undesirable as it gets. A broken system
makes any other feature you can name a rather moot point...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081124/b0644d45/attachment.sig>

From pertusus at free.fr  Mon Nov 24 22:14:43 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 24 Nov 2008 23:14:43 +0100
Subject: orphaning gnome-volume-manager
In-Reply-To: <20081124195620.GE3145@nostromo.devel.redhat.com>
References: <1227544518.11161.19.camel@x61.fubar.dk>
	<20081124195620.GE3145@nostromo.devel.redhat.com>
Message-ID: <20081124221443.GA2743@free.fr>

On Mon, Nov 24, 2008 at 02:56:20PM -0500, Bill Nottingham wrote:
> 
> Does it actually serve a purpose? Should it just be removed?

It is up to fedora packagers to decide to maintain it or not.

--
Pat



From notting at redhat.com  Mon Nov 24 22:18:13 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 24 Nov 2008 17:18:13 -0500
Subject: orphaning gnome-volume-manager
In-Reply-To: <20081124221443.GA2743@free.fr>
References: <1227544518.11161.19.camel@x61.fubar.dk>
	<20081124195620.GE3145@nostromo.devel.redhat.com>
	<20081124221443.GA2743@free.fr>
Message-ID: <20081124221813.GA7701@nostromo.devel.redhat.com>

Patrice Dumas (pertusus at free.fr) said: 
> > Does it actually serve a purpose? Should it just be removed?
> 
> It is up to fedora packagers to decide to maintain it or not.

To an extent. We block packages every release that serve no purpose
any more.

Bill



From skvidal at fedoraproject.org  Mon Nov 24 22:19:44 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 24 Nov 2008 17:19:44 -0500 (EST)
Subject: orphaning gnome-volume-manager
In-Reply-To: <20081124221813.GA7701@nostromo.devel.redhat.com>
References: <1227544518.11161.19.camel@x61.fubar.dk>
	<20081124195620.GE3145@nostromo.devel.redhat.com>
	<20081124221443.GA2743@free.fr>
	<20081124221813.GA7701@nostromo.devel.redhat.com>
Message-ID: <alpine.LFD.2.00.0811241719210.13683@localhost.localdomain>



On Mon, 24 Nov 2008, Bill Nottingham wrote:

> Patrice Dumas (pertusus at free.fr) said:
>>> Does it actually serve a purpose? Should it just be removed?
>>
>> It is up to fedora packagers to decide to maintain it or not.
>
> To an extent. We block packages every release that serve no purpose
> any more.

Does anything obsolete gnome-volume-manager or will people just have crap 
dangling around in their rpmdbs?

-sv



From pertusus at free.fr  Mon Nov 24 22:23:48 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 24 Nov 2008 23:23:48 +0100
Subject: orphaning gnome-volume-manager
In-Reply-To: <20081124221813.GA7701@nostromo.devel.redhat.com>
References: <1227544518.11161.19.camel@x61.fubar.dk>
	<20081124195620.GE3145@nostromo.devel.redhat.com>
	<20081124221443.GA2743@free.fr>
	<20081124221813.GA7701@nostromo.devel.redhat.com>
Message-ID: <20081124222348.GB2743@free.fr>

On Mon, Nov 24, 2008 at 05:18:13PM -0500, Bill Nottingham wrote:
> Patrice Dumas (pertusus at free.fr) said: 
> > > Does it actually serve a purpose? Should it just be removed?
> > 
> > It is up to fedora packagers to decide to maintain it or not.
> 
> To an extent. We block packages every release that serve no purpose
> any more.

You should not, they should be orphaned.

--
Pat



From jos at xos.nl  Mon Nov 24 22:45:31 2008
From: jos at xos.nl (Jos Vos)
Date: Mon, 24 Nov 2008 23:45:31 +0100
Subject: No X on F9/F10 with Intel 82915G/GV/910GL
In-Reply-To: <1227559247.23765.54.camel@atropine.boston.devel.redhat.com>
References: <200811241511.mAOFBDo0019062@jasmine.xos.nl>
	<1227545424.23765.19.camel@atropine.boston.devel.redhat.com>
	<20081124165746.GA20250@jasmine.xos.nl>
	<1227550496.23765.24.camel@atropine.boston.devel.redhat.com>
	<20081124191738.GA22039@jasmine.xos.nl>
	<1227559247.23765.54.camel@atropine.boston.devel.redhat.com>
Message-ID: <20081124224531.GA24278@jasmine.xos.nl>

On Mon, Nov 24, 2008 at 03:40:47PM -0500, Adam Jackson wrote:

> In RHEL5 you'd still be using the old BIOS-based i810 driver (assuming
> you installed with 5.1 or older), which might work through blind luck.

Yes, in my RHEL5 notes I wrote that I should use the "i810" driver (maybe
there the "intel" driver was chosen by default).

I see that it's still there (/usr/lib/xorg/modules/drivers/i810_drv.so),
but it does not seem to work (I only tried it remotely, I'm not in the
office anymore):

(II) Loading /usr/lib/xorg/modules/drivers//i810_drv.so
(II) Module i810: vendor="X.Org Foundation"
        compiled for 1.5.2, module version = 2.5.0
        Module class: X.Org Video Driver
        ABI class: X.Org Video Driver, version 4.1
(II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
        i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
        E7221 (i915), 915GM, 945G, 945GM, 945GME, 965G, G35, 965Q, 946GZ,
        965GM, 965GME/GLE, G33, Q35, Q33,
        Mobile Intel? GM45 Express Chipset,
        Intel Integrated Graphics Device, G45/G43, Q45/Q43, G41
(II) Primary Device is: PCI 00 at 00:02:0
(EE) No devices detected.

> The current theory is that it's trying to do LVDS over SDVO, which is a
> bit insane since it has LVDS on the board already, and that's a path
> that the driver currently doesn't support.  If we could get copies of
> the video BIOS (and some testing time, if you're up for it) we can
> probably work with intel to get it going.  Probably best to do that in a
> bug, either in fedora or freedesktop bugzilla.

I see that I can't file bugs against F10 yet (I'm using the final F10
media already ;-)).  Will try again tomorrow and post the bug # here,
as a reference.

-- 
--    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 bashton at brennanashton.com  Mon Nov 24 23:44:38 2008
From: bashton at brennanashton.com (Brennan Ashton)
Date: Mon, 24 Nov 2008 15:44:38 -0800
Subject: Java Packaging build-classpath
Message-ID: <981da310811241544ndbb3b9h9aa0575dea555422@mail.gmail.com>

Java packagers,
I was working on packaging a java application last night,  I was
having all kinds of trouble, until I was pointed to the
build-classpath script.  This is not really documented in
https://fedoraproject.org/wiki/Packaging/Java and it would appear to
be very important.  Soon after I got my package someone else came to
#fedora-devel asking the same thing.  Overall the packaging experience
was great, the tools that you have all set up seem to place any kind
of information I need quickly at my finger tips.  Thank you all.

--Brennan Ashton



From davej at redhat.com  Tue Nov 25 01:32:54 2008
From: davej at redhat.com (Dave Jones)
Date: Mon, 24 Nov 2008 20:32:54 -0500
Subject: My roadmap for a better Fedora
In-Reply-To: <604aa7910811191426x7a59c984x3e0721fa69ae7887@mail.gmail.com>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<adf480660811191257v451d9580xcd8b38edcfe27420@mail.gmail.com>
	<20081119205950.GA4961@nostromo.devel.redhat.com>
	<adf480660811191323i552f933dy156a8416e22561ad@mail.gmail.com>
	<20081119221721.GH26527@redhat.com>
	<604aa7910811191426x7a59c984x3e0721fa69ae7887@mail.gmail.com>
Message-ID: <20081125013254.GC10996@redhat.com>

On Wed, Nov 19, 2008 at 01:26:06PM -0900, Jeff Spaleta wrote:
 > On Wed, Nov 19, 2008 at 1:17 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
 > > Utterly useless. I already have a HUGE number of bug reports. The problem
 > > is that 90% of them are essentially useless when first reported. It requires
 > > several back/forth interactions between myself & the bug reporter to get
 > > enough information to diagnose & resolve the problem. If we create a system
 > > where we bombard maintainers with bugreports & no scope for user interaction
 > > they'll end up directly in /dev/null, and further discourage maintainers
 > > from addressing even bugs with enough info.
 > 
 > Is the upstream automated kerneloops stuff a counter example
 > methodology? Or does that only work because they get sooooooo many
 > more crash reports that the statistics become a useful way to sort?

kerneloops is an awesome tool, but it's not a silver bullet replacement
for bug reporting for the kernel.  For one thing, it doesn't track the
many kernel bugs we get where there isn't a backtrace. (which are the majority)

Most are of the form "my wireless stopped working" "suspend doesn't work" etc.
These kinds of bugs need back and forth that only bugzilla or email can provide.
A drive-by "my suspend broke" report would be utterly useless.

	Dave

-- 
http://www.codemonkey.org.uk



From pertusus at free.fr  Mon Nov 24 22:24:36 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 24 Nov 2008 23:24:36 +0100
Subject: orphaning gnome-volume-manager
In-Reply-To: <alpine.LFD.2.00.0811241719210.13683@localhost.localdomain>
References: <1227544518.11161.19.camel@x61.fubar.dk>
	<20081124195620.GE3145@nostromo.devel.redhat.com>
	<20081124221443.GA2743@free.fr>
	<20081124221813.GA7701@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811241719210.13683@localhost.localdomain>
Message-ID: <20081124222436.GC2743@free.fr>

On Mon, Nov 24, 2008 at 05:19:44PM -0500, Seth Vidal wrote:
>
>
> On Mon, 24 Nov 2008, Bill Nottingham wrote:
>
>> Patrice Dumas (pertusus at free.fr) said:
>>>> Does it actually serve a purpose? Should it just be removed?
>>>
>>> It is up to fedora packagers to decide to maintain it or not.
>>
>> To an extent. We block packages every release that serve no purpose
>> any more.
>
> Does anything obsolete gnome-volume-manager or will people just have crap 
> dangling around in their rpmdbs?

Maybe somebody will take it. Obsoletes should only be added if nobody
wants to take the package.

--
Pat



From jonstanley at gmail.com  Tue Nov 25 01:56:28 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Mon, 24 Nov 2008 20:56:28 -0500
Subject: My roadmap for a better Fedora
In-Reply-To: <16de708d0811191443m72e364bcu645655c617776f94@mail.gmail.com>
References: <1227119906.7387.138.camel@localhost.localdomain>
	<16de708d0811191443m72e364bcu645655c617776f94@mail.gmail.com>
Message-ID: <da159fda0811241756r57d4f280ke0f454080abd54ed@mail.gmail.com>

Sorry, just catching up on this thread

On Wed, Nov 19, 2008 at 5:43 PM, Arthur Pemberton <pemboa at gmail.com> wrote:

> My only issue why I do not test a lot more is the lack of requests.
> There is too much software to just "test'. If there was an RSS
> fees/email alert/etc system which alerted me every time someone wanted
> something tested. I would do a lot more testing. I have box dedicated

There is, see http://feeds.feedburner.com/NeedsRetesting. Nice thing
about feedburner is it lets me see stats (though that's not the
primary purpose of having those in feedburner, it's more along the
lines of making it readable).  Looking just to verify the URL, I see
that there are a total of 2 subscribers to that feed (and one of them
is me).

You get your bug into that feed by using the status whiteboard of
'NeedsRetesting'. See
http://www.redhat.com/archives/fedora-devel-announce/2008-April/msg00000.html
for more details.  I'd love to see more people actually use it.



From dbhole at redhat.com  Tue Nov 25 02:37:29 2008
From: dbhole at redhat.com (Deepak Bhole)
Date: Mon, 24 Nov 2008 21:37:29 -0500
Subject: Java Packaging build-classpath
In-Reply-To: <981da310811241544ndbb3b9h9aa0575dea555422@mail.gmail.com>
References: <981da310811241544ndbb3b9h9aa0575dea555422@mail.gmail.com>
Message-ID: <20081125023728.GM11872@redhat.com>

* Brennan Ashton <bashton at brennanashton.com> [2008-11-24 18:45]:
> Java packagers,
> I was working on packaging a java application last night,  I was
> having all kinds of trouble, until I was pointed to the
> build-classpath script.  This is not really documented in
> https://fedoraproject.org/wiki/Packaging/Java and it would appear to
> be very important.  Soon after I got my package someone else came to
> #fedora-devel asking the same thing.  Overall the packaging experience
> was great, the tools that you have all set up seem to place any kind
> of information I need quickly at my finger tips.  Thank you all.
> 
> --Brennan Ashton
> 

Hmm, I can see build-classpath covered in section 1.2.5.. granted it is only 
one sentence.. but that pretty much covers the functionality and usage
:)

Deepak

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



From bashton at brennanashton.com  Tue Nov 25 02:55:57 2008
From: bashton at brennanashton.com (Brennan Ashton)
Date: Mon, 24 Nov 2008 18:55:57 -0800
Subject: Java Packaging build-classpath
In-Reply-To: <20081125023728.GM11872@redhat.com>
References: <981da310811241544ndbb3b9h9aa0575dea555422@mail.gmail.com>
	<20081125023728.GM11872@redhat.com>
Message-ID: <981da310811241855h573360a2lb725c698561aa449@mail.gmail.com>

On Mon, Nov 24, 2008 at 6:37 PM, Deepak Bhole <dbhole at redhat.com> wrote:
> Hmm, I can see build-classpath covered in section 1.2.5.. granted it is only
> one sentence.. but that pretty much covers the functionality and usage
> :)

I did see that, I guess what I feel is missing is when to use it. I
get it now after building my package and using it, but I spent a very
long time before I found that this is what I needed.  Other then that
the java package docs are really good IMHO.
--Brennan Ashton



From orcanbahri at yahoo.com  Tue Nov 25 03:18:21 2008
From: orcanbahri at yahoo.com (Orcan Ogetbil)
Date: Mon, 24 Nov 2008 19:18:21 -0800 (PST)
Subject: Java Packaging build-classpath
In-Reply-To: <981da310811241855h573360a2lb725c698561aa449@mail.gmail.com>
Message-ID: <240102.46429.qm@web32804.mail.mud.yahoo.com>

--- On Mon, 11/24/08, Brennan Ashton wrote:
> Deepak Bhole wrote:
> > Hmm, I can see build-classpath covered in section
> 1.2.5.. granted it is only
> > one sentence.. but that pretty much covers the
> functionality and usage
> > :)
> 
> I did see that, I guess what I feel is missing is when to
> use it. I
> get it now after building my package and using it, but I
> spent a very
> long time before I found that this is what I needed.  Other
> then that
> the java package docs are really good IMHO.
> --Brennan Ashton

Yes, this is something that I missed when I built my first java package too. I think it would be better if there was a brief explanation.

Please add this to the "suggestions" list I made in a previous email. Any information about when the wiki page will be unlocked so that those fixes can be made?


      



From panemade at gmail.com  Tue Nov 25 04:10:38 2008
From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=)
Date: Tue, 25 Nov 2008 09:40:38 +0530
Subject: Emacs build with Indic rendering support
Message-ID: <f4586a2e0811242010x7236ac25ica68b99370c8582c@mail.gmail.com>

Hi all,
    We have now got Indic rendering support in new emacs-23.0.60 cvs
snapshot version which is yet not built in Fedora. I have done new emacs
test build with Indic rendering support. For F11, you can download binary
test rpms from http://paragn.fedorapeople.org/emacs-23.0.60/i386/  or you
can even build binary test rpms for F10/F9 using
http://paragn.fedorapeople.org/emacs-23.0.60/emacs-23.0.60-20081124.fc10.src.rpm.


Note:- This new emacs package build contains modified spec which is based on
original spec written by coldwell(Fedora emacs package maintainer)

Thanks & Regards,
Parag.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081125/e04096c6/attachment.htm>

From rc040203 at freenet.de  Tue Nov 25 04:34:54 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 25 Nov 2008 05:34:54 +0100
Subject: "nousb" poll
In-Reply-To: <20081124194815.GC3145@nostromo.devel.redhat.com>
References: <20081122103552.86a26420.zaitcev@redhat.com>
	<1227376350.5833.30.camel@beck.corsepiu.local>
	<20081124194815.GC3145@nostromo.devel.redhat.com>
Message-ID: <1227587695.21853.28.camel@beck.corsepiu.local>

On Mon, 2008-11-24 at 14:48 -0500, Bill Nottingham wrote:
> Ralf Corsepius (rc040203 at freenet.de) said: 
> > Yes, I am.
> > 
> > Typically on older machines,
> > * which don't have USB.
> 
> ... in which case nousb does nothing.
It avoids potential errors

> > * on which USB is too uneffective to be useful (e.g. only have USB-1.x)
> 
> ... in which case nousb only saves a bit of time on boot initializing
> the controller.
... and poking around into BIOS/registers etc.

> > <sigh/> another nail in Fedora's coffin on low end platforms?
> 
> Given that all it does is tell a built-in module
Note this                          ^^^^^^^^

>  to not initialize,
> 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.




From dtimms at iinet.net.au  Tue Nov 25 12:39:46 2008
From: dtimms at iinet.net.au (David Timms)
Date: Tue, 25 Nov 2008 23:39:46 +1100
Subject: Java Packaging build-classpath
In-Reply-To: <240102.46429.qm@web32804.mail.mud.yahoo.com>
References: <240102.46429.qm@web32804.mail.mud.yahoo.com>
Message-ID: <492BF212.4090000@iinet.net.au>

Orcan Ogetbil wrote:
> --- On Mon, 11/24/08, Brennan Ashton wrote:

>> I did see that, I guess what I feel is missing is when to use it. I
>>  get it now after building my package and using it, but I spent a
>> very long time before I found that this is what I needed.  Other 
>> then that the java package docs are really good IMHO. --Brennan
>> Ashton
> 
> Yes, this is something that I missed when I built my first java
> package too. I think it would be better if there was a brief
> explanation.
> 
> Please add this to the "suggestions" list I made in a previous email.
> Any information about when the wiki page will be unlocked so that
> those fixes can be made?
Is the best place for suggestions about a wiki page the discussions tab ?
https://fedoraproject.org/wiki/Talk:Packaging/Java

Allows edit, so I suggest make your mark...

DaveT.



From paul at all-the-johnsons.co.uk  Tue Nov 25 12:44:26 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Tue, 25 Nov 2008 12:44:26 +0000
Subject: Heads up for mono-2.2
Message-ID: <1227617066.21103.456.camel@PB3.Linux>

Hi,

I'm in the middle of rebuilding mono-2.2. As is usual with these things,
Mono 2.2 has a pile of fixes and new additions to packages.

Can packagers please be aware that monodoc is no longer going to be in
rawhide as it has been integrated now into mono itself. The new
subpackage is called mono-monodoc (and mono-monodoc-devel). All of the
monodoc files go exactly where they used to with the old monodoc
packages, but you will need to rebuild all packages which use monodoc to
point the BR to mono-monodoc-devel rather than just monodoc-devel.

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/20081125/a2e567d3/attachment.sig>

From pbrobinson at gmail.com  Tue Nov 25 12:57:19 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Tue, 25 Nov 2008 12:57:19 +0000
Subject: Heads up for mono-2.2
In-Reply-To: <1227617066.21103.456.camel@PB3.Linux>
References: <1227617066.21103.456.camel@PB3.Linux>
Message-ID: <5256d0b0811250457s4988ce3diacacff079639140@mail.gmail.com>

> I'm in the middle of rebuilding mono-2.2. As is usual with these things,
> Mono 2.2 has a pile of fixes and new additions to packages.
>
> Can packagers please be aware that monodoc is no longer going to be in
> rawhide as it has been integrated now into mono itself. The new
> subpackage is called mono-monodoc (and mono-monodoc-devel). All of the
> monodoc files go exactly where they used to with the old monodoc
> packages, but you will need to rebuild all packages which use monodoc to
> point the BR to mono-monodoc-devel rather than just monodoc-devel.

Can the new mono-monodoc provide the old package names to make
transition easier?

Peter



From rawhide at fedoraproject.org  Tue Nov 25 13:00:03 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Tue, 25 Nov 2008 13:00:03 +0000 (UTC)
Subject: rawhide report: 20081125 changes
Message-ID: <20081125130003.929AA1F823B@releng2.fedora.phx.redhat.com>

Compose started at Tue Nov 25 06:01:12 UTC 2008

Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 0














From dan at danny.cz  Tue Nov 25 13:08:32 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Tue, 25 Nov 2008 14:08:32 +0100
Subject: Heads up for mono-2.2
In-Reply-To: <5256d0b0811250457s4988ce3diacacff079639140@mail.gmail.com>
References: <1227617066.21103.456.camel@PB3.Linux>
	<5256d0b0811250457s4988ce3diacacff079639140@mail.gmail.com>
Message-ID: <1227618512.3627.22.camel@eagle.danny.cz>


Peter Robinson p??e v ?t 25. 11. 2008 v 12:57 +0000:
> > I'm in the middle of rebuilding mono-2.2. As is usual with these things,
> > Mono 2.2 has a pile of fixes and new additions to packages.
> >
> > Can packagers please be aware that monodoc is no longer going to be in
> > rawhide as it has been integrated now into mono itself. The new
> > subpackage is called mono-monodoc (and mono-monodoc-devel). All of the
> > monodoc files go exactly where they used to with the old monodoc
> > packages, but you will need to rebuild all packages which use monodoc to
> > point the BR to mono-monodoc-devel rather than just monodoc-devel.
> 
> Can the new mono-monodoc provide the old package names to make
> transition easier?

I expect that old monodoc will be obsoleted, so there must exist an
upgrade path to be compliant with the guidelines.


		Dan




From paul at all-the-johnsons.co.uk  Tue Nov 25 13:11:28 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Tue, 25 Nov 2008 13:11:28 +0000
Subject: Heads up for mono-2.2
In-Reply-To: <1227617066.21103.456.camel@PB3.Linux>
References: <1227617066.21103.456.camel@PB3.Linux>
Message-ID: <1227618688.21103.460.camel@PB3.Linux>

Hi,

> Can packagers please be aware that monodoc is no longer going to be in
> rawhide as it has been integrated now into mono itself. The new
> subpackage is called mono-monodoc (and mono-monodoc-devel). All of the
> monodoc files go exactly where they used to with the old monodoc
> packages, but you will need to rebuild all packages which use monodoc to
> point the BR to mono-monodoc-devel rather than just monodoc-devel.

Sorry - brain fart there... Ignore the above - monodoc is part of the
mono core distribution, but all I need is the magic of -n to call it
monodoc again!

Silly me...

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/20081125/9c255e90/attachment.sig>

From billcrawford1970 at gmail.com  Tue Nov 25 13:06:39 2008
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Tue, 25 Nov 2008 13:06:39 +0000
Subject: Heads up for mono-2.2
In-Reply-To: <1227617066.21103.456.camel@PB3.Linux>
References: <1227617066.21103.456.camel@PB3.Linux>
Message-ID: <200811251306.39500.billcrawford1970@gmail.com>

On Tuesday 25 November 2008 12:44:26 Paul wrote:

> Can packagers please be aware that monodoc is no longer going to be in
> rawhide as it has been integrated now into mono itself. The new
> subpackage is called mono-monodoc (and mono-monodoc-devel). All of the
> monodoc files go exactly where they used to with the old monodoc
> packages, but you will need to rebuild all packages which use monodoc to
> point the BR to mono-monodoc-devel rather than just monodoc-devel.

Couldn't the monodoc subpackage be specified as %package -n monodoc ?



From paul at all-the-johnsons.co.uk  Tue Nov 25 13:13:28 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Tue, 25 Nov 2008 13:13:28 +0000
Subject: Rawhide reopen date?
Message-ID: <1227618808.21103.461.camel@PB3.Linux>

Hi,

When will rawhide start shipping f11 rpms?

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/20081125/9c7e63ef/attachment.sig>

From opensource at till.name  Tue Nov 25 13:14:51 2008
From: opensource at till.name (Till Maas)
Date: Tue, 25 Nov 2008 14:14:51 +0100
Subject: Translating summary text of packages
In-Reply-To: <a7804a540811240038p72f15e65qcd76d21c28bf4831@mail.gmail.com>
References: <a7804a540811240038p72f15e65qcd76d21c28bf4831@mail.gmail.com>
Message-ID: <200811251414.57424.opensource@till.name>

On Mon November 24 2008, Benjam?n Valero Espinosa wrote:
> About the need of reducing the size of the summary texts and giving that
> info in the descriptions (and hoping PackageKit can search in them), what
> about the translation of this texts? Uff, I know this would be a huge task

If you want to translate them, you should probably coordinate with the Fedora 
Localization Project:
https://fedoraproject.org/wiki/L10N

I guess there is no reason, that there are no spanish translations, other than 
a lack of manpower. :-)

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/20081125/4b312d0f/attachment.sig>

From notting at redhat.com  Tue Nov 25 13:17:02 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 25 Nov 2008 08:17:02 -0500
Subject: Rawhide reopen date?
In-Reply-To: <1227618808.21103.461.camel@PB3.Linux>
References: <1227618808.21103.461.camel@PB3.Linux>
Message-ID: <20081125131702.GA26394@nostromo.devel.redhat.com>

Paul (paul at all-the-johnsons.co.uk) said: 
> When will rawhide start shipping f11 rpms?

Likely tomorrow - we didn't want to flip it the past couple of days because
that would be a lot of churn to drop on the mirrors when they're trying to
sync the actual release.

Bill



From rjones at redhat.com  Tue Nov 25 13:19:42 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 25 Nov 2008 13:19:42 +0000
Subject: Rawhide reopen date?
In-Reply-To: <20081125131702.GA26394@nostromo.devel.redhat.com>
References: <1227618808.21103.461.camel@PB3.Linux>
	<20081125131702.GA26394@nostromo.devel.redhat.com>
Message-ID: <20081125131942.GA27747@amd.home.annexia.org>

On Tue, Nov 25, 2008 at 08:17:02AM -0500, Bill Nottingham wrote:
> Paul (paul at all-the-johnsons.co.uk) said: 
> > When will rawhide start shipping f11 rpms?
> 
> Likely tomorrow - we didn't want to flip it the past couple of days because
> that would be a lot of churn to drop on the mirrors when they're trying to
> sync the actual release.

Will we get "Rawhide report" referring to F-11 tomorrow too?

There's a lot of broken OCaml packages (as expected), and once I know
which ones are broken, I'll be able to rebuild and/or fix them.

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 opensource at till.name  Tue Nov 25 13:22:11 2008
From: opensource at till.name (Till Maas)
Date: Tue, 25 Nov 2008 14:22:11 +0100
Subject: Rawhide reopen date?
In-Reply-To: <1227618808.21103.461.camel@PB3.Linux>
References: <1227618808.21103.461.camel@PB3.Linux>
Message-ID: <200811251422.12272.opensource@till.name>

On Tue November 25 2008, Paul wrote:

> When will rawhide start shipping f11 rpms?

According to this announcement, it will be today:
https://www.redhat.com/archives/fedora-devel-announce/2008-November/msg00011.html

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/20081125/3169c751/attachment.sig>

From nicolas.mailhot at laposte.net  Tue Nov 25 13:22:58 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 25 Nov 2008 14:22:58 +0100 (CET)
Subject: Translating summary text of packages
In-Reply-To: <200811251414.57424.opensource@till.name>
References: <a7804a540811240038p72f15e65qcd76d21c28bf4831@mail.gmail.com>
	<200811251414.57424.opensource@till.name>
Message-ID: <686ad03bbbe15b64bf6492a4010c8de9.squirrel@arekh.dyndns.org>



Le Mar 25 novembre 2008 14:14, Till Maas a ?crit :

> If you want to translate them, you should probably coordinate with the
> Fedora
> Localization Project:
> https://fedoraproject.org/wiki/L10N

BTW would it be possible for some native speakers to set up a *en_US*
localisation group that reviews and edits the base summaries and
descriptions *before* all the other l10n groups have to deal with
them?

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Tue Nov 25 13:24:31 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 25 Nov 2008 14:24:31 +0100 (CET)
Subject: Heads up for mono-2.2
In-Reply-To: <1227618688.21103.460.camel@PB3.Linux>
References: <1227617066.21103.456.camel@PB3.Linux>
	<1227618688.21103.460.camel@PB3.Linux>
Message-ID: <3d44afb117e282abe3246c50869c60fa.squirrel@arekh.dyndns.org>



Le Mar 25 novembre 2008 14:11, Paul a ?crit :

> Sorry - brain fart there... Ignore the above - monodoc is part of the
> mono core distribution, but all I need is the magic of -n to call it
> monodoc again!

The magic of -n will mean confused bug reporters that waste time
searching for an srpm that does not exist anymore

-- 
Nicolas Mailhot



From dtimms at iinet.net.au  Tue Nov 25 12:06:40 2008
From: dtimms at iinet.net.au (David Timms)
Date: Tue, 25 Nov 2008 23:06:40 +1100
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
In-Reply-To: <49256382.3080506@iinet.net.au>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<49256382.3080506@iinet.net.au>
Message-ID: <492BEA50.1090604@iinet.net.au>

David Timms wrote:
> Arthur Pemberton wrote:
>> My question is, what do we need/want/like from Bugzilla?
> wishes:
>   - a separate by-line for me-too comments (eg I got that on x86_64, I 
> got it on a "piece of old carpet" things that people tend to add to 
> bugzilla / bugs.launchpad etc. These can server as breadth of issue 
> marker, but aren't really clarifying a bug, with option to add hardware 
> id from smolt. [ x ] I experienced this symptom and my smolt hardware 
> dsecription is [http://smotls.y.z/12345656]
> 
>     - a way to mark a me-too comment as "me-too".

Just came across following which provides another viewpoint:
http://linuxhaters.blogspot.com/2008/08/one-bug-report-to-rule-them-all.html

DaveT.



From trever.adams at gmail.com  Tue Nov 25 13:39:23 2008
From: trever.adams at gmail.com (Trever L. Adams)
Date: Tue, 25 Nov 2008 06:39:23 -0700
Subject: Software without tarballs (SVN or CVS only)
Message-ID: <492C000B.6090200@gmail.com>

Is it acceptable to package (officially) projects that do not release 
tarballs, but can be downloaded via SVN or CVS and tarballed from there?

I have two packages in mind, one of which I have packaged, but not 
tested, the other I used a few years ago and would like to package.

These are PyKota and DSPAM. DSPAM may eventually release a tarball, but 
currently has not done so since the project being sold. Both are FOSS 
according to Fedora guidelines.

If these are acceptable, once I have tested them a bit, would anyone 
mind sponsoring me and helping me get started?

I had mentioned bedework before (bedework.org). Currently, I do not know 
enough about java building to make a package work. Also, the tarball 
situation would be similar due to them also shipping the binaries and 
several Fedora included packages in the tarball.

Thank you,
Trever Adams

-------------- 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/20081125/0439032b/attachment.sig>

From jreznik at redhat.com  Tue Nov 25 13:45:03 2008
From: jreznik at redhat.com (Jaroslav Reznik)
Date: Tue, 25 Nov 2008 08:45:03 -0500 (EST)
Subject: Software without tarballs (SVN or CVS only)
In-Reply-To: <492C000B.6090200@gmail.com>
Message-ID: <1622482270.2899921227620703624.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

----- "Trever L. Adams" <trever.adams at gmail.com> wrote:

> Is it acceptable to package (officially) projects that do not release
> 
> tarballs, but can be downloaded via SVN or CVS and tarballed from
> there?

Follow these guidelines:
https://fedoraproject.org/wiki/Packaging/SourceURL#Using_Revision_Control

R.

> Thank you,
> Trever Adams
> 
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From paul at all-the-johnsons.co.uk  Tue Nov 25 14:15:42 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Tue, 25 Nov 2008 14:15:42 +0000
Subject: Heads up for mono-2.2
In-Reply-To: <3d44afb117e282abe3246c50869c60fa.squirrel@arekh.dyndns.org>
References: <1227617066.21103.456.camel@PB3.Linux>
	<1227618688.21103.460.camel@PB3.Linux>
	<3d44afb117e282abe3246c50869c60fa.squirrel@arekh.dyndns.org>
Message-ID: <1227622542.21103.463.camel@PB3.Linux>

Hi,

> > Sorry - brain fart there... Ignore the above - monodoc is part of the
> > mono core distribution, but all I need is the magic of -n to call it
> > monodoc again!
> 
> The magic of -n will mean confused bug reporters that waste time
> searching for an srpm that does not exist anymore

True, but it's really six of one, half a dozen of the other. I've
packaged it as monodoc and monodoc-devel as it'll probably cause fewer
problems than it will solve to have folks looking for monodoc.

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/20081125/bf5578c7/attachment.sig>

From opensource at till.name  Tue Nov 25 14:27:56 2008
From: opensource at till.name (Till Maas)
Date: Tue, 25 Nov 2008 15:27:56 +0100
Subject: Heads up for mono-2.2
In-Reply-To: <3d44afb117e282abe3246c50869c60fa.squirrel@arekh.dyndns.org>
References: <1227617066.21103.456.camel@PB3.Linux>
	<1227618688.21103.460.camel@PB3.Linux>
	<3d44afb117e282abe3246c50869c60fa.squirrel@arekh.dyndns.org>
Message-ID: <200811251528.07267.opensource@till.name>

On Tue November 25 2008, Nicolas Mailhot wrote:
> Le Mar 25 novembre 2008 14:11, Paul a ?crit :
> > Sorry - brain fart there... Ignore the above - monodoc is part of the
> > mono core distribution, but all I need is the magic of -n to call it
> > monodoc again!
>
> The magic of -n will mean confused bug reporters that waste time
> searching for an srpm that does not exist anymore

Why should people search for this srpm? If they do, why should they not use 
use "yumdownloader --source monodoc" or to use "rpm -qi monodoc" to determine 
the name of the srpm. I belive that if people need the srpm, they should be 
skilled enough to use the right tools to get a srpm. And if there are not, 
then they will at least learn how to search for an srpm the right way, after 
they reported a bug.

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/20081125/38ee5795/attachment.sig>

From jani at mikkonen.biz  Tue Nov 25 14:31:30 2008
From: jani at mikkonen.biz (Jani Mikkonen)
Date: Tue, 25 Nov 2008 16:31:30 +0200
Subject: Games SIG looking for new contributers
In-Reply-To: <922f91d0e205cb268a726d1add8019a9.squirrel@mail.jcomserv.net>
References: <492AA05F.7030404@hhs.nl>
	<a36741370811240448o6ef8fea7g486760f493b2eb8@mail.gmail.com>
	<29fee02b0811240510n5415df26kde1f12aebe7e2d0a@mail.gmail.com>
	<922f91d0e205cb268a726d1add8019a9.squirrel@mail.jcomserv.net>
Message-ID: <a36741370811250631u39a9f691w1a2398d7e93b2412@mail.gmail.com>

>> What games have you packages? Can you upload src.rpm somewhere on the
>> net? Thus maybe some other developers can use these as a base and they
>> won't start from scratch.
>
> I'd be glad to see this too.  I'd be happy to polish, submit and maintain
> some.


Soon Come :)

Packaging is not really the issue here but i can pass the stuff before
end of this week to public.

Biggest issue with most of the games on the wishlist is that they are
pretty poorly coded when it comes to actually "packaging" those. 4
games (which  i do not remember currently as im still in the office
and cant access my build box at home) that i did where "hardcoded" to
use datafiles from either same directory as the game binary itself OR
even worse, from current working  directory..



From chasd at silveroaks.com  Tue Nov 25 15:10:30 2008
From: chasd at silveroaks.com (chasd)
Date: Tue, 25 Nov 2008 09:10:30 -0600
Subject: Software without tarballs (SVN or CVS only)
In-Reply-To: <20081125142926.47CF3619A6F@hormel.redhat.com>
References: <20081125142926.47CF3619A6F@hormel.redhat.com>
Message-ID: <A8EF1E43-13DD-42E4-8AD5-A3B1C34AB8B9@silveroaks.com>


Trever L. Adams wrote:

> DSPAM may eventually release a tarball, but currently has not done  
> so since the project being sold.

There was a recent ( October ) thread on the DSPAM users list  
questioning if DSPAM is alive, as well as a thread a year ago. The  
project really needs developers since Sensory Networks is not  
spending any time on it. I know there are a couple of users that  
have .spec files to roll their own RPMs, not sure if that would help  
you. One used Gentoo patches, which cause some debate.

I'm still using 3.6.8 since I have no issues with the way I  
configured DSPAM, using SQLite not MySQL.


-- 
Charles Dostale



From notting at redhat.com  Tue Nov 25 15:14:01 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 25 Nov 2008 10:14:01 -0500
Subject: orphaning gnome-volume-manager
In-Reply-To: <20081124222348.GB2743@free.fr>
References: <1227544518.11161.19.camel@x61.fubar.dk>
	<20081124195620.GE3145@nostromo.devel.redhat.com>
	<20081124221443.GA2743@free.fr>
	<20081124221813.GA7701@nostromo.devel.redhat.com>
	<20081124222348.GB2743@free.fr>
Message-ID: <20081125151401.GC27916@nostromo.devel.redhat.com>

Patrice Dumas (pertusus at free.fr) said: 
> > To an extent. We block packages every release that serve no purpose
> > any more.
> 
> You should not, they should be orphaned.

If a package's entire function has been subsumed by another package, there's
no point in going through an orphan cycle.

Bill



From skvidal at fedoraproject.org  Tue Nov 25 15:15:24 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Tue, 25 Nov 2008 10:15:24 -0500 (EST)
Subject: orphaning gnome-volume-manager
In-Reply-To: <20081125151401.GC27916@nostromo.devel.redhat.com>
References: <1227544518.11161.19.camel@x61.fubar.dk>
	<20081124195620.GE3145@nostromo.devel.redhat.com>
	<20081124221443.GA2743@free.fr>
	<20081124221813.GA7701@nostromo.devel.redhat.com>
	<20081124222348.GB2743@free.fr>
	<20081125151401.GC27916@nostromo.devel.redhat.com>
Message-ID: <alpine.LFD.2.00.0811251015150.13683@localhost.localdomain>



On Tue, 25 Nov 2008, Bill Nottingham wrote:

> Patrice Dumas (pertusus at free.fr) said:
>>> To an extent. We block packages every release that serve no purpose
>>> any more.
>>
>> You should not, they should be orphaned.
>
> If a package's entire function has been subsumed by another package, there's
> no point in going through an orphan cycle.

but it  should be obsoleted by _something_.

-sv



From hughsient at gmail.com  Tue Nov 25 15:26:35 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Tue, 25 Nov 2008 15:26:35 +0000
Subject: orphaning gnome-volume-manager
In-Reply-To: <alpine.LFD.2.00.0811251015150.13683@localhost.localdomain>
References: <1227544518.11161.19.camel@x61.fubar.dk>
	<20081124195620.GE3145@nostromo.devel.redhat.com>
	<20081124221443.GA2743@free.fr>
	<20081124221813.GA7701@nostromo.devel.redhat.com>
	<20081124222348.GB2743@free.fr>
	<20081125151401.GC27916@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811251015150.13683@localhost.localdomain>
Message-ID: <1227626795.4408.15.camel@hughsie-laptop>

On Tue, 2008-11-25 at 10:15 -0500, Seth Vidal wrote:
> but it  should be obsoleted by _something_.

Nautilus seems like the obvious choice.

Richard.




From denis at poolshark.org  Tue Nov 25 16:08:43 2008
From: denis at poolshark.org (Denis Leroy)
Date: Tue, 25 Nov 2008 17:08:43 +0100
Subject: orphaning gnome-volume-manager
In-Reply-To: <alpine.LFD.2.00.0811251015150.13683@localhost.localdomain>
References: <1227544518.11161.19.camel@x61.fubar.dk>	<20081124195620.GE3145@nostromo.devel.redhat.com>	<20081124221443.GA2743@free.fr>	<20081124221813.GA7701@nostromo.devel.redhat.com>	<20081124222348.GB2743@free.fr>	<20081125151401.GC27916@nostromo.devel.redhat.com>
	<alpine.LFD.2.00.0811251015150.13683@localhost.localdomain>
Message-ID: <492C230B.1000702@poolshark.org>

Seth Vidal wrote:
> 
> 
> On Tue, 25 Nov 2008, Bill Nottingham wrote:
> 
>> Patrice Dumas (pertusus at free.fr) said:
>>>> To an extent. We block packages every release that serve no purpose
>>>> any more.
>>>
>>> You should not, they should be orphaned.
>>
>> If a package's entire function has been subsumed by another package, 
>> there's
>> no point in going through an orphan cycle.
> 
> but it  should be obsoleted by _something_.

fedora-release ?

Although I agree with Patrice, it seems more natural to orphan it and 
let Darwin's law do its job...

-denis



From itamar at ispbrasil.com.br  Tue Nov 25 10:43:12 2008
From: itamar at ispbrasil.com.br (Itamar - IspBrasil)
Date: Tue, 25 Nov 2008 08:43:12 -0200
Subject: error compiling postgresql with fedora mingw 
Message-ID: <492BD6C0.5030602@ispbrasil.com.br>

any help ?

make[1]: Entering directory 
`/home/itamar/fedora/mingw-postgresql/postgresql-8.3.5/src'
make -C port all
make[2]: Entering directory 
`/home/itamar/fedora/mingw-postgresql/postgresql-8.3.5/src/port'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory 
`/home/itamar/fedora/mingw-postgresql/postgresql-8.3.5/src/port'
make -C timezone all
make[2]: Entering directory 
`/home/itamar/fedora/mingw-postgresql/postgresql-8.3.5/src/timezone'
make -C ../../src/port all
make[3]: Entering directory 
`/home/itamar/fedora/mingw-postgresql/postgresql-8.3.5/src/port'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/home/itamar/fedora/mingw-postgresql/postgresql-8.3.5/src/port'
i686-pc-mingw32-gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
-fexceptions --param=ssp-buffer-size=4 -mms-bitfields -Wall 
-Wmissing-prototypes -Wpointer-arith -Winline 
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing 
-fwrapv zic.o ialloc.o scheck.o localtime.o -L../../src/port 
-Wl,--allow-multiple-definition   -lpgport -lz -lm  -lws2_32 -lshfolder 
-o zic.exe
../../src/port/libpgport.a: could not read symbols: Archive has no 
index; run ranlib to add one
collect2: ld returned 1 exit status
make[2]: *** [zic] Error 1
make[2]: Leaving directory 
`/home/itamar/fedora/mingw-postgresql/postgresql-8.3.5/src/timezone'
make[1]: *** [all] Error 2
make[1]: Leaving directory 
`/home/itamar/fedora/mingw-postgresql/postgresql-8.3.5/src'
make: *** [all] Error 2


-- 
------------

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 limb at jcomserv.net  Tue Nov 25 16:38:10 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Tue, 25 Nov 2008 10:38:10 -0600 (CST)
Subject: Games SIG looking for new contributers
In-Reply-To: <a36741370811250631u39a9f691w1a2398d7e93b2412@mail.gmail.com>
References: <492AA05F.7030404@hhs.nl>
	<a36741370811240448o6ef8fea7g486760f493b2eb8@mail.gmail.com>
	<29fee02b0811240510n5415df26kde1f12aebe7e2d0a@mail.gmail.com>
	<922f91d0e205cb268a726d1add8019a9.squirrel@mail.jcomserv.net>
	<a36741370811250631u39a9f691w1a2398d7e93b2412@mail.gmail.com>
Message-ID: <95498856bb8c8678ba26a01cb1dd7261.squirrel@mail.jcomserv.net>


>>> What games have you packages? Can you upload src.rpm somewhere on the
>>> net? Thus maybe some other developers can use these as a base and they
>>> won't start from scratch.
>>
>> I'd be glad to see this too.  I'd be happy to polish, submit and
>> maintain
>> some.
>
>
> Soon Come :)
>
> Packaging is not really the issue here but i can pass the stuff before
> end of this week to public.
>
> Biggest issue with most of the games on the wishlist is that they are
> pretty poorly coded when it comes to actually "packaging" those. 4
> games (which  i do not remember currently as im still in the office
> and cant access my build box at home) that i did where "hardcoded" to
> use datafiles from either same directory as the game binary itself OR
> even worse, from current working  directory..
>
There are lots of those in Fedora.  We Have Ways. :)))

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

-d. bowie



From jameshubbard at gmail.com  Tue Nov 25 17:28:42 2008
From: jameshubbard at gmail.com (James Hubbard)
Date: Tue, 25 Nov 2008 12:28:42 -0500
Subject: Heads up for mono-2.2
In-Reply-To: <200811251528.07267.opensource@till.name>
References: <1227617066.21103.456.camel@PB3.Linux>
	<1227618688.21103.460.camel@PB3.Linux>
	<3d44afb117e282abe3246c50869c60fa.squirrel@arekh.dyndns.org>
	<200811251528.07267.opensource@till.name>
Message-ID: <f3ddc6d30811250928u4e16410dudae854774a726946@mail.gmail.com>

2008/11/25 Till Maas <opensource at till.name>:
> On Tue November 25 2008, Nicolas Mailhot wrote:
>> The magic of -n will mean confused bug reporters that waste time
>> searching for an srpm that does not exist anymore
>
> Why should people search for this srpm? If they do, why should they not use
> use "yumdownloader --source monodoc" or to use "rpm -qi monodoc" to determine
> the name of the srpm. I belive that if people need the srpm, they should be
> skilled enough to use the right tools to get a srpm. And if there are not,
> then they will at least learn how to search for an srpm the right way, after
> they reported a bug.

Why does anyone go searching for a srpm?  Everyone has their reasons.
You are assuming that the user has those tools.  What if the user is
on another system or  does not have net connectivity?  I will go back
to older versions of fedora to download srpms.  However, I usually
know the package name.

I do not believe that not having a separate srpm for this will be a
problem.  Anyone that needs it will probably figure it out.  I think
that having packages where there are multiple applications in one rpm
is more of a problem from the end user stand point.  The example that
sticks out my head is the kdeskd rpm.  I think that topic has already
been discussed so there is no need to go over it again.



From opensource at till.name  Tue Nov 25 17:39:46 2008
From: opensource at till.name (Till Maas)
Date: Tue, 25 Nov 2008 18:39:46 +0100
Subject: orphaning gnome-volume-manager
In-Reply-To: <492C230B.1000702@poolshark.org>
References: <1227544518.11161.19.camel@x61.fubar.dk>
	<alpine.LFD.2.00.0811251015150.13683@localhost.localdomain>
	<492C230B.1000702@poolshark.org>
Message-ID: <200811251839.54485.opensource@till.name>

On Tue November 25 2008, Denis Leroy wrote:

> Although I agree with Patrice, it seems more natural to orphan it and
> let Darwin's law do its job...

But who will after which timeframe retire the package? The current best 
practices are to retire packages that are considered not to be useful anymore 
to make this obvious for other interested maintainers. E.g. then the 
package's devel CVS directory will contain a dead.package file that explains 
why it is not useful anymore. If a package is only orphaned, then this means, 
that there is currently nobody available that want's to maintain the package, 
but the package would still be 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/20081125/bda884e1/attachment.sig>

From tgl at redhat.com  Tue Nov 25 17:52:50 2008
From: tgl at redhat.com (Tom Lane)
Date: Tue, 25 Nov 2008 12:52:50 -0500
Subject: error compiling postgresql with fedora mingw 
In-Reply-To: <492BD6C0.5030602@ispbrasil.com.br> 
References: <492BD6C0.5030602@ispbrasil.com.br>
Message-ID: <29573.1227635570@sss.pgh.pa.us>

Itamar - IspBrasil <itamar at ispbrasil.com.br> writes:
> any help ?

What version of fedora/mingw exactly?

> i686-pc-mingw32-gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
> -fexceptions --param=ssp-buffer-size=4 -mms-bitfields -Wall 
> -Wmissing-prototypes -Wpointer-arith -Winline 
> -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing 
> -fwrapv zic.o ialloc.o scheck.o localtime.o -L../../src/port 
> -Wl,--allow-multiple-definition   -lpgport -lz -lm  -lws2_32 -lshfolder 
> -o zic.exe
> ../../src/port/libpgport.a: could not read symbols: Archive has no 
> index; run ranlib to add one

Hmm, anything interesting in the part of the build log where libpgport.a
gets made?

Postgres is known to build on mingw
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
so one way to attack the problem is to figure out what's different
between your installation and the ones on those mingw buildfarm machines.

			regards, tom lane



From mhuhtala at abo.fi  Tue Nov 25 17:57:25 2008
From: mhuhtala at abo.fi (Mikko Huhtala)
Date: Tue, 25 Nov 2008 19:57:25 +0200
Subject: Flash trouble on F10 / VESA 
Message-ID: <18732.15493.946560.391993@volvox1.sbl>


I've an up-to-date F10 installation on an old laptop with a very poor
graphics card. lspci says

01:00.0 VGA compatible controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266]

Xorg uses the Savage driver with DRI. I've configured X to run at 16
bit color depth, otherwise a lot of things, especially playing video,
become painfully slow.

For some reason Flash refuses to work at all. I've tried both Adobe's
flash-plugin package and gnash (all 32 bit). Flash elements appear as
blank boxes on web pages in Firefox and X uses 100% of CPU trying to
do something, but the Flash animation/video never appears. Both
flash-plugin and gnash do work on another machine that has Nvidia
drivers and the same versions of all the other relevant packages. Is
this a know problem?

Packages:
kernel-2.6.27.5-117.fc10.i686
xorg-x11-server-Xorg-1.5.3-5.fc10.i386
xorg-x11-drv-savage-2.2.0-2.fc9.i386
firefox-3.0.4-1.fc10.i386
flash-plugin-10.0.12.36-release.i386



From mcepl at redhat.com  Tue Nov 25 17:46:44 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Tue, 25 Nov 2008 18:46:44 +0100
Subject: NetworkManager cli docs
References: <1227447232.3721.1.camel@sb-home>
	<1227542437.564.24.camel@localhost.localdomain>
	<1227554514.7267.1.camel@sb-home>
	<1227557641.25089.10.camel@localhost.localdomain>
	<20081124205106.GR22173@salma.internal.frields.org>
Message-ID: <49qtv5xv1j.ln2@ppp1053.in.ipex.cz>

On 2008-11-24, 20:51 GMT, Paul W. Frields wrote:
> That's a bug maybe worth filing against initscripts; the
> /usr/share/doc/initscripts-*/sysconfig.txt file is fairly useful but
> may have slipped out of currency.

And if somebody converted that into manpage(s) she would be my 
personal hero.

Mat?j



From bpepple at fedoraproject.org  Tue Nov 25 18:22:21 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 25 Nov 2008 13:22:21 -0500
Subject: Plan for tomorrows (20081126) FESCO meeting
Message-ID: <1227637341.29945.2.camel@kennedy>

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 -- sponsor nominations -- David Woodhouse (dwmw2)

/topic FESCo-Meeting -- sponsor nominations -- Jon Stanley (jds2001)

/topic FESCo-Meeting - EOL date for F8 - jds2001

/topic FESCo-Meeting - Person responsible for making sure features have
test plan scope are in compliance by deadlines - 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/20081125/f1eb9812/attachment.sig>

From itamar at ispbrasil.com.br  Tue Nov 25 18:34:07 2008
From: itamar at ispbrasil.com.br (Itamar - IspBrasil)
Date: Tue, 25 Nov 2008 16:34:07 -0200
Subject: error compiling postgresql with fedora mingw
In-Reply-To: <29573.1227635570@sss.pgh.pa.us>
References: <492BD6C0.5030602@ispbrasil.com.br>
	<29573.1227635570@sss.pgh.pa.us>
Message-ID: <492C451F.1010709@ispbrasil.com.br>

I am using lasted version from

http://www.annexia.org/tmp/mingw/fedora-10/x86_64/

I need only client library's (mysql and postgresql), to rebuild Qt using 
mingw with mysql and postgresql support


On 11/25/2008 3:52 PM, Tom Lane wrote:
> Itamar - IspBrasil<itamar at ispbrasil.com.br>  writes:
>    
>> any help ?
>>      
>
> What version of fedora/mingw exactly?
>
>    
>> i686-pc-mingw32-gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
>> -fexceptions --param=ssp-buffer-size=4 -mms-bitfields -Wall
>> -Wmissing-prototypes -Wpointer-arith -Winline
>> -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing
>> -fwrapv zic.o ialloc.o scheck.o localtime.o -L../../src/port
>> -Wl,--allow-multiple-definition   -lpgport -lz -lm  -lws2_32 -lshfolder
>> -o zic.exe
>> ../../src/port/libpgport.a: could not read symbols: Archive has no
>> index; run ranlib to add one
>>      
>
> Hmm, anything interesting in the part of the build log where libpgport.a
> gets made?
>
> Postgres is known to build on mingw
> http://www.pgbuildfarm.org/cgi-bin/show_status.pl
> so one way to attack the problem is to figure out what's different
> between your installation and the ones on those mingw buildfarm machines.
>
> 			regards, tom lane
>
>    


-- 
------------

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 stickster at gmail.com  Tue Nov 25 18:44:49 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Tue, 25 Nov 2008 13:44:49 -0500
Subject: Flash trouble on F10 / VESA
In-Reply-To: <18732.15493.946560.391993@volvox1.sbl>
References: <18732.15493.946560.391993@volvox1.sbl>
Message-ID: <20081125184449.GC26284@salma.internal.frields.org>

On Tue, Nov 25, 2008 at 07:57:25PM +0200, Mikko Huhtala wrote:
> 
> I've an up-to-date F10 installation on an old laptop with a very poor
> graphics card. lspci says
> 
> 01:00.0 VGA compatible controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266]
> 
> Xorg uses the Savage driver with DRI. I've configured X to run at 16
> bit color depth, otherwise a lot of things, especially playing video,
> become painfully slow.
> 
> For some reason Flash refuses to work at all. I've tried both Adobe's
> flash-plugin package and gnash (all 32 bit). Flash elements appear as
> blank boxes on web pages in Firefox and X uses 100% of CPU trying to
> do something, but the Flash animation/video never appears. Both
> flash-plugin and gnash do work on another machine that has Nvidia
> drivers and the same versions of all the other relevant packages. Is
> this a know problem?
> 
> Packages:
> kernel-2.6.27.5-117.fc10.i686
> xorg-x11-server-Xorg-1.5.3-5.fc10.i386
> xorg-x11-drv-savage-2.2.0-2.fc9.i386
> firefox-3.0.4-1.fc10.i386
> flash-plugin-10.0.12.36-release.i386

Have you tried the instructions on this wiki page?

http://fedoraproject.org/wiki/Flash 

I would suggest that if that page doesn't solve your problems, you
should try posting to our specific user assistance list for best
results:

http://redhat.com/mailman/listinfo/fedora-list 

-- 
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/20081125/893bf702/attachment.sig>

From jburgess777 at googlemail.com  Tue Nov 25 19:05:00 2008
From: jburgess777 at googlemail.com (Jon Burgess)
Date: Tue, 25 Nov 2008 19:05:00 +0000
Subject: error compiling postgresql with fedora mingw
In-Reply-To: <492C451F.1010709@ispbrasil.com.br>
References: <492BD6C0.5030602@ispbrasil.com.br>
	<29573.1227635570@sss.pgh.pa.us>  <492C451F.1010709@ispbrasil.com.br>
Message-ID: <1227639900.23644.51.camel@localhost.localdomain>

On Tue, 2008-11-25 at 16:34 -0200, Itamar - IspBrasil wrote:
> I am using lasted version from
> 
> http://www.annexia.org/tmp/mingw/fedora-10/x86_64/
> 
> I need only client library's (mysql and postgresql), to rebuild Qt using 
> mingw with mysql and postgresql support
> 
> 
> On 11/25/2008 3:52 PM, Tom Lane wrote:
> > Itamar - IspBrasil<itamar at ispbrasil.com.br>  writes:
> >    
> >> any help ?
> >>      
> >
> > What version of fedora/mingw exactly?
> >
> >    
> >> i686-pc-mingw32-gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
> >> -fexceptions --param=ssp-buffer-size=4 -mms-bitfields -Wall
> >> -Wmissing-prototypes -Wpointer-arith -Winline
> >> -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing
> >> -fwrapv zic.o ialloc.o scheck.o localtime.o -L../../src/port
> >> -Wl,--allow-multiple-definition   -lpgport -lz -lm  -lws2_32 -lshfolder
> >> -o zic.exe
> >> ../../src/port/libpgport.a: could not read symbols: Archive has no
> >> index; run ranlib to add one
> >>      
> >
> > Hmm, anything interesting in the part of the build log where libpgport.a
> > gets made?
> >
> > Postgres is known to build on mingw
> > http://www.pgbuildfarm.org/cgi-bin/show_status.pl
> > so one way to attack the problem is to figure out what's different
> > between your installation and the ones on those mingw buildfarm machines.
> >
> > 			regards, tom lane
> >
> >    
> 

I think the problem with the .a above is due to the default 'ar' failing
to process the Windows style object symbols.

I managed to build PostgreSQL a couple of weeks back with MinGW on F9. I
had to override a few of the default tools, e.g.

$ make AR=i686-pc-mingw32-ar DLLTOOL=/usr/i686-pc-mingw32/bin/dlltool
DLLWRAP=i686-pc-mingw32-dllwrap

I also needed some tweaks to make it use i686-pc-mingw32-windres
and to execute the compiled "zic.exe" instead of just "./zic" (though in
the end I just skipped the whole timezone installation). I also ran into
a problem with a missing definition of UNICODE_STRING. Let me know if
you run into any more problems and I'll see if I can help.

	Jon






From mhuhtala at abo.fi  Tue Nov 25 19:10:39 2008
From: mhuhtala at abo.fi (Mikko Huhtala)
Date: Tue, 25 Nov 2008 21:10:39 +0200
Subject: Flash trouble on F10 / VESA 
Message-ID: <18732.19887.374505.78654@volvox1.sbl>


> Have you tried the instructions on this wiki page?
>
> http://fedoraproject.org/wiki/Flash 
>
> I would suggest that if that page doesn't solve your problems, you
> should try posting to our specific user assistance list for best
> results:

I can install both flash-plugin and gnash-plugin and get them to
appear in about:plugins with no problems. It seems to me that both
somehow interact poorly with the Savage driver, because either works
on other machines that have other graphics hardware/driver, that's
all. Playing video with mplayer works on the Savage-equipped laptop,
so the problem is not triggered by video outside the browser. I'll try
a couple of things still and then submit a bug report if I can't get
it to work.

Mikko



From tgl at redhat.com  Tue Nov 25 19:19:27 2008
From: tgl at redhat.com (Tom Lane)
Date: Tue, 25 Nov 2008 14:19:27 -0500
Subject: error compiling postgresql with fedora mingw 
In-Reply-To: <1227639900.23644.51.camel@localhost.localdomain> 
References: <492BD6C0.5030602@ispbrasil.com.br>
	<29573.1227635570@sss.pgh.pa.us>
	<492C451F.1010709@ispbrasil.com.br>
	<1227639900.23644.51.camel@localhost.localdomain>
Message-ID: <3880.1227640767@sss.pgh.pa.us>

Jon Burgess <jburgess777 at googlemail.com> writes:
> I think the problem with the .a above is due to the default 'ar' failing
> to process the Windows style object symbols.

> I managed to build PostgreSQL a couple of weeks back with MinGW on F9. I
> had to override a few of the default tools, e.g.

> $ make AR=i686-pc-mingw32-ar DLLTOOL=/usr/i686-pc-mingw32/bin/dlltool
> DLLWRAP=i686-pc-mingw32-dllwrap

That makes sense.  Could you have simplified matters by just prepending
/usr/i686-pc-mingw32/bin to your PATH?

> I also needed some tweaks to make it use i686-pc-mingw32-windres
> and to execute the compiled "zic.exe" instead of just "./zic" (though in
> the end I just skipped the whole timezone installation).

Agreed on skipping the timezone installation --- if you have
/usr/share/zoneinfo that's being kept reasonably up2date then it's
better to use that.

> I also ran into
> a problem with a missing definition of UNICODE_STRING.

UNICODE_STRING?  I don't see anything like that in the Postgres sources.

			regards, tom lane



From jburgess777 at googlemail.com  Tue Nov 25 19:42:44 2008
From: jburgess777 at googlemail.com (Jon Burgess)
Date: Tue, 25 Nov 2008 19:42:44 +0000
Subject: error compiling postgresql with fedora mingw
In-Reply-To: <3880.1227640767@sss.pgh.pa.us>
References: <492BD6C0.5030602@ispbrasil.com.br>
	<29573.1227635570@sss.pgh.pa.us> <492C451F.1010709@ispbrasil.com.br>
	<1227639900.23644.51.camel@localhost.localdomain>
	<3880.1227640767@sss.pgh.pa.us>
Message-ID: <1227642164.23644.69.camel@localhost.localdomain>

On Tue, 2008-11-25 at 14:19 -0500, Tom Lane wrote:
> Jon Burgess <jburgess777 at googlemail.com> writes:
> > I think the problem with the .a above is due to the default 'ar' failing
> > to process the Windows style object symbols.
> 
> > I managed to build PostgreSQL a couple of weeks back with MinGW on F9. I
> > had to override a few of the default tools, e.g.
> 
> > $ make AR=i686-pc-mingw32-ar DLLTOOL=/usr/i686-pc-mingw32/bin/dlltool
> > DLLWRAP=i686-pc-mingw32-dllwrap
> 
> That makes sense.  Could you have simplified matters by just prepending
> /usr/i686-pc-mingw32/bin to your PATH?

That seems to work OK but you still need the
DLLTOOL=/usr/i686-pc-mingw32/bin/dlltool

I forgot to mention that some of the Makefiles have hard coded
references to windres which need replacing
with /usr/bin/i686-pc-mingw32-windres

> > I also needed some tweaks to make it use i686-pc-mingw32-windres
> > and to execute the compiled "zic.exe" instead of just "./zic" (though in
> > the end I just skipped the whole timezone installation).
> 
> Agreed on skipping the timezone installation --- if you have
> /usr/share/zoneinfo that's being kept reasonably up2date then it's
> better to use that.
> 
> > I also ran into
> > a problem with a missing definition of UNICODE_STRING.
> 
> UNICODE_STRING?  I don't see anything like that in the Postgres sources.

The problem looked like it was in the MinGW header files. Some PG code
was pulling in sspi.h which includes the line:

typedef UNICODE_STRING SECURITY_STRING, *PSECURITY_STRING;

I tweked a few things to #include <ntdef.h> which fixed it but I'm not
sure this is the right fix. The subauth.h headers file addresses this by
having an alternate definition of UNICODE_STRING which with an #ifdef
wrapper.

  Jon




From pertusus at free.fr  Tue Nov 25 20:00:20 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 25 Nov 2008 21:00:20 +0100
Subject: orphaning gnome-volume-manager
In-Reply-To: <20081125151401.GC27916@nostromo.devel.redhat.com>
References: <1227544518.11161.19.camel@x61.fubar.dk>
	<20081124195620.GE3145@nostromo.devel.redhat.com>
	<20081124221443.GA2743@free.fr>
	<20081124221813.GA7701@nostromo.devel.redhat.com>
	<20081124222348.GB2743@free.fr>
	<20081125151401.GC27916@nostromo.devel.redhat.com>
Message-ID: <20081125200020.GA2591@free.fr>

On Tue, Nov 25, 2008 at 10:14:01AM -0500, Bill Nottingham wrote:
> Patrice Dumas (pertusus at free.fr) said: 
> > > To an extent. We block packages every release that serve no purpose
> > > any more.
> > 
> > You should not, they should be orphaned.
> 
> If a package's entire function has been subsumed by another package, there's
> no point in going through an orphan cycle.

There can be different packages providing the same functionality in
fedora. The criterion is the presence of a maintainer (and passing the 
review).

--
Pat



From pertusus at free.fr  Tue Nov 25 20:03:45 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 25 Nov 2008 21:03:45 +0100
Subject: orphaning gnome-volume-manager
In-Reply-To: <200811251839.54485.opensource@till.name>
References: <1227544518.11161.19.camel@x61.fubar.dk>
	<alpine.LFD.2.00.0811251015150.13683@localhost.localdomain>
	<492C230B.1000702@poolshark.org>
	<200811251839.54485.opensource@till.name>
Message-ID: <20081125200345.GB2591@free.fr>

On Tue, Nov 25, 2008 at 06:39:46PM +0100, Till Maas wrote:
> On Tue November 25 2008, Denis Leroy wrote:
> 
> > Although I agree with Patrice, it seems more natural to orphan it and
> > let Darwin's law do its job...
> 
> But who will after which timeframe retire the package? The current best 
> practices are to retire packages that are considered not to be useful anymore 
> to make this obvious for other interested maintainers. E.g. then the 
> package's devel CVS directory will contain a dead.package file that explains 
> why it is not useful anymore. If a package is only orphaned, then this means, 
> that there is currently nobody available that want's to maintain the package, 
> but the package would still be useful.

A package should only be retired if it is orphaned. For example, in that
case, if nobody answers within a reasonable time frame (2 weeks?), it could 
be retired in addition to being orphaned, and obsoleted by nautilus.

--
Pat



From poelstra at redhat.com  Tue Nov 25 20:17:38 2008
From: poelstra at redhat.com (John Poelstra)
Date: Tue, 25 Nov 2008 12:17:38 -0800
Subject: Fedora Release Engineering Meeting Recap 2008-11-24
Message-ID: <492C5D62.4030304@redhat.com>

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

Please make corrections and clarifications to the wiki page.

== Fedora 10 ==
* In good shape for release of Fedora 10 tomorrow
* Fedora 10 zero day updates are ready to go
* f13: one thing I was toying with is when we branch and freeze, making 
the development/ path continue on with say F12 content, and start 
publishing the F11 content to releases/11/Everything/

== Fedora 11 Schedule ==
* need to make sure F12 branching is visible
* finding ways to reduce package churn
* QA team monitoring status of features during release
* proposal at 
http://poelstra.fedorapeople.org/schedules/f-11/f-11-standard.html
* poelcat to make adjustments to proposed schedule and republish
*# move alpha freeze forward one week
*# move alpha release forward one week
*# remove critical package freeze from schedule
*# offset feature freeze and beta freeze by one week
* vote on schedule to present to FESCo next week

== IRC Transcript ==



From notting at redhat.com  Tue Nov 25 21:10:12 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 25 Nov 2008 16:10:12 -0500
Subject: orphaning gnome-volume-manager
In-Reply-To: <20081125200020.GA2591@free.fr>
References: <1227544518.11161.19.camel@x61.fubar.dk>
	<20081124195620.GE3145@nostromo.devel.redhat.com>
	<20081124221443.GA2743@free.fr>
	<20081124221813.GA7701@nostromo.devel.redhat.com>
	<20081124222348.GB2743@free.fr>
	<20081125151401.GC27916@nostromo.devel.redhat.com>
	<20081125200020.GA2591@free.fr>
Message-ID: <20081125211012.GD31416@nostromo.devel.redhat.com>

Patrice Dumas (pertusus at free.fr) said: 
> > If a package's entire function has been subsumed by another package, there's
> > no point in going through an orphan cycle.
> 
> There can be different packages providing the same functionality in
> fedora. The criterion is the presence of a maintainer (and passing the 
> review).

Not always. For example, we have obsoletes in perl for modules that moved
into the base perl distribution. There's no reason to go through an orphan
cycle for that. Similarly, if the entirety of gnome-volume-manager is poking
interfaces that no longer exist, there's really no point to orphaning it.

Bill



From tgl at redhat.com  Tue Nov 25 21:36:16 2008
From: tgl at redhat.com (Tom Lane)
Date: Tue, 25 Nov 2008 16:36:16 -0500
Subject: error compiling postgresql with fedora mingw 
In-Reply-To: <1227642164.23644.69.camel@localhost.localdomain> 
References: <492BD6C0.5030602@ispbrasil.com.br>
	<29573.1227635570@sss.pgh.pa.us>
	<492C451F.1010709@ispbrasil.com.br>
	<1227639900.23644.51.camel@localhost.localdomain>
	<3880.1227640767@sss.pgh.pa.us>
	<1227642164.23644.69.camel@localhost.localdomain>
Message-ID: <6442.1227648976@sss.pgh.pa.us>

Jon Burgess <jburgess777 at googlemail.com> writes:
> On Tue, 2008-11-25 at 14:19 -0500, Tom Lane wrote:
>> That makes sense.  Could you have simplified matters by just prepending
>> /usr/i686-pc-mingw32/bin to your PATH?

> That seems to work OK but you still need the
> DLLTOOL=/usr/i686-pc-mingw32/bin/dlltool

Hmm ... I see a "dlltool" that should probably be "$(DLLTOOL)" in 
src/pl/plpython/Makefile ... are there other omissions?

> I forgot to mention that some of the Makefiles have hard coded
> references to windres which need replacing
> with /usr/bin/i686-pc-mingw32-windres

Again, seems like tweaking the PATH should have taken care of that.

I think that upstream would be willing to take any patches needed to
make this work with just the PATH tweak.  I'm not in a position to
test it myself though, so if you'd put together a tested patch I'd
be much obliged.


>> UNICODE_STRING?  I don't see anything like that in the Postgres sources.

> The problem looked like it was in the MinGW header files. Some PG code
> was pulling in sspi.h which includes the line:

> typedef UNICODE_STRING SECURITY_STRING, *PSECURITY_STRING;

> I tweked a few things to #include <ntdef.h> which fixed it but I'm not
> sure this is the right fix.

Hmm, that sounds familiar all of a sudden.  [ digs in archives... ]
Is this proposed patch addressing the same thing?

http://archives.postgresql.org/pgsql-hackers/2008-11/msg00367.php

It hasn't gotten applied, probably because no one else confirmed it
was needed, but if you can confirm it ...

			regards, tom lane



From jburgess777 at googlemail.com  Tue Nov 25 21:50:23 2008
From: jburgess777 at googlemail.com (Jon Burgess)
Date: Tue, 25 Nov 2008 21:50:23 +0000
Subject: error compiling postgresql with fedora mingw
In-Reply-To: <6442.1227648976@sss.pgh.pa.us>
References: <492BD6C0.5030602@ispbrasil.com.br>
	<29573.1227635570@sss.pgh.pa.us> <492C451F.1010709@ispbrasil.com.br>
	<1227639900.23644.51.camel@localhost.localdomain>
	<3880.1227640767@sss.pgh.pa.us>
	<1227642164.23644.69.camel@localhost.localdomain>
	<6442.1227648976@sss.pgh.pa.us>
Message-ID: <1227649823.23644.80.camel@localhost.localdomain>

On Tue, 2008-11-25 at 16:36 -0500, Tom Lane wrote:
> Jon Burgess <jburgess777 at googlemail.com> writes:
> > On Tue, 2008-11-25 at 14:19 -0500, Tom Lane wrote:
> >> That makes sense.  Could you have simplified matters by just prepending
> >> /usr/i686-pc-mingw32/bin to your PATH?
> 
> > That seems to work OK but you still need the
> > DLLTOOL=/usr/i686-pc-mingw32/bin/dlltool

Sorry I pasted the wrong one. I meant to say:
DLLWRAP=i686-pc-mingw32-dllwrap

There is no 'dllwrap' executable in the MinGW bin directory.

> Hmm ... I see a "dlltool" that should probably be "$(DLLTOOL)" in 
> src/pl/plpython/Makefile ... are there other omissions?

I suspect I didn't build any of the language bindings so I didn't see
that.

> > I forgot to mention that some of the Makefiles have hard coded
> > references to windres which need replacing
> > with /usr/bin/i686-pc-mingw32-windres
> 
> Again, seems like tweaking the PATH should have taken care of that.

There is no 'windres' executable, perhaps there should be.


> I think that upstream would be willing to take any patches needed to
> make this work with just the PATH tweak.  I'm not in a position to
> test it myself though, so if you'd put together a tested patch I'd
> be much obliged.
> 
> 
> >> UNICODE_STRING?  I don't see anything like that in the Postgres sources.
> 
> > The problem looked like it was in the MinGW header files. Some PG code
> > was pulling in sspi.h which includes the line:
> 
> > typedef UNICODE_STRING SECURITY_STRING, *PSECURITY_STRING;
> 
> > I tweked a few things to #include <ntdef.h> which fixed it but I'm not
> > sure this is the right fix.
> 
> Hmm, that sounds familiar all of a sudden.  [ digs in archives... ]
> Is this proposed patch addressing the same thing?
> 
> http://archives.postgresql.org/pgsql-hackers/2008-11/msg00367.php
> 
> It hasn't gotten applied, probably because no one else confirmed it
> was needed, but if you can confirm it ...

The patches probably would address the issue. OTOH, if they are not
required on Windows then it suggests to me that the problem is with
mingw32-w32api and not PostgreSQL.

	Jon




From ajax at redhat.com  Tue Nov 25 21:57:28 2008
From: ajax at redhat.com (Adam Jackson)
Date: Tue, 25 Nov 2008 16:57:28 -0500
Subject: No X on F9/F10 with Intel 82915G/GV/910GL
In-Reply-To: <20081124224531.GA24278@jasmine.xos.nl>
References: <200811241511.mAOFBDo0019062@jasmine.xos.nl>
	<1227545424.23765.19.camel@atropine.boston.devel.redhat.com>
	<20081124165746.GA20250@jasmine.xos.nl>
	<1227550496.23765.24.camel@atropine.boston.devel.redhat.com>
	<20081124191738.GA22039@jasmine.xos.nl>
	<1227559247.23765.54.camel@atropine.boston.devel.redhat.com>
	<20081124224531.GA24278@jasmine.xos.nl>
Message-ID: <1227650248.14746.1.camel@localhost.localdomain>

On Mon, 2008-11-24 at 23:45 +0100, Jos Vos wrote:
> On Mon, Nov 24, 2008 at 03:40:47PM -0500, Adam Jackson wrote:
> 
> > In RHEL5 you'd still be using the old BIOS-based i810 driver (assuming
> > you installed with 5.1 or older), which might work through blind luck.
> 
> Yes, in my RHEL5 notes I wrote that I should use the "i810" driver (maybe
> there the "intel" driver was chosen by default).
> 
> I see that it's still there (/usr/lib/xorg/modules/drivers/i810_drv.so),
> but it does not seem to work (I only tried it remotely, I'm not in the
> office anymore):

It's not really still there, it's just a symlink, the intel driver
responds to both names so people with i810 in their config file get
working X across upgrades.  We should probably just munge the config
file and drop the symlink at this point.

- ajax



From chitlesh.goorah at gmail.com  Tue Nov 25 22:19:08 2008
From: chitlesh.goorah at gmail.com (Chitlesh GOORAH)
Date: Tue, 25 Nov 2008 23:19:08 +0100
Subject: spins maintainers, content please
Message-ID: <50baabb30811251419t4e5b9cc7qdd6ffe48bc018bba@mail.gmail.com>

Hello there,

There is still the spins release announcement missing. In order to
solve, together with PaulFrields, RexDieter and I setup this page:

https://fedoraproject.org/wiki/SIGs/Spins/10

to describe basic things about the spins, thus reminding people about
the existence of such spins. This announcement should be done by
spin-SIG. Can anyone do it please ? If the wikipage's location isn't
correct, please rectify and post the new urls.

Spin maintainers please update your content, especially those working
behind the developer spin.

Kind regards,
Chitlesh



From vonbrand at inf.utfsm.cl  Tue Nov 25 22:42:43 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 25 Nov 2008 19:42:43 -0300
Subject: My roadmap for a better Fedora
In-Reply-To: <1227561575.4755.206.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>
Message-ID: <200811252242.mAPMghOd009940@laptop14.inf.utfsm.cl>

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...

> 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.

> 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".

> 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.
-- 
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 ivazqueznet at gmail.com  Tue Nov 25 23:44:52 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Tue, 25 Nov 2008 18:44:52 -0500
Subject: orphaning gnome-volume-manager
In-Reply-To: <20081125211012.GD31416@nostromo.devel.redhat.com>
References: <1227544518.11161.19.camel@x61.fubar.dk>
	<20081124195620.GE3145@nostromo.devel.redhat.com>
	<20081124221443.GA2743@free.fr>
	<20081124221813.GA7701@nostromo.devel.redhat.com>
	<20081124222348.GB2743@free.fr>
	<20081125151401.GC27916@nostromo.devel.redhat.com>
	<20081125200020.GA2591@free.fr>
	<20081125211012.GD31416@nostromo.devel.redhat.com>
Message-ID: <1227656692.6715.318.camel@ignacio.lan>

On Tue, 2008-11-25 at 16:10 -0500, Bill Nottingham wrote:
> Patrice Dumas (pertusus at free.fr) said: 
> > > If a package's entire function has been subsumed by another package, there's
> > > no point in going through an orphan cycle.
> > 
> > There can be different packages providing the same functionality in
> > fedora. The criterion is the presence of a maintainer (and passing the 
> > review).
> 
> Not always. For example, we have obsoletes in perl for modules that moved
> into the base perl distribution. There's no reason to go through an orphan
> cycle for that. Similarly, if the entirety of gnome-volume-manager is poking
> interfaces that no longer exist, there's really no point to orphaning it.

But the interfaces do exist, they're just being frobbed by another
application. Should someone decide to not have that application
(strange, yet possible) they'd have to resort to ivman or some other app
like that.

-- 
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/20081125/57184b64/attachment.sig>

From trever.adams at gmail.com  Wed Nov 26 00:50:44 2008
From: trever.adams at gmail.com (Trever L. Adams)
Date: Tue, 25 Nov 2008 17:50:44 -0700
Subject: Software without tarballs (SVN or CVS only)
In-Reply-To: <A8EF1E43-13DD-42E4-8AD5-A3B1C34AB8B9@silveroaks.com>
References: <20081125142926.47CF3619A6F@hormel.redhat.com>
	<A8EF1E43-13DD-42E4-8AD5-A3B1C34AB8B9@silveroaks.com>
Message-ID: <492C9D64.2030605@gmail.com>

chasd wrote:
> There was a recent ( October ) thread on the DSPAM users list 
> questioning if DSPAM is alive, as well as a thread a year ago. The 
> project really needs developers since Sensory Networks is not spending 
> any time on it. I know there are a couple of users that have .spec 
> files to roll their own RPMs, not sure if that would help you. One 
> used Gentoo patches, which cause some debate.
>
> I'm still using 3.6.8 since I have no issues with the way I configured 
> DSPAM, using SQLite not MySQL.
>
>
Sensory Networks has done some patching, but it is only in the CVS tree. 
The tree even shows the release of 3.8.1, but there is no tarball, hence 
my question about acceptance of such in a Fedora package.

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/20081125/73b76a7d/attachment.sig>

From konrad at tylerc.org  Wed Nov 26 04:18:14 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Tue, 25 Nov 2008 20:18:14 -0800
Subject: Orphaning azureus
In-Reply-To: <49082091.4090206@gmail.com>
References: <20081024190916.A41D98E0003@hormel.redhat.com>
	<20081028171711.3c1f1cc9@cheeky> <49082091.4090206@gmail.com>
Message-ID: <200811252018.15095.konrad@tylerc.org>

On Wednesday 29 October 2008 01:36:33 am Alphonse Van Assche wrote:
> Stefan Posdzich a ?crit :
> > I have tried now some days with this package and i cant get warm with it
> > (+ java).
> > I will orphan it again, i hope it will find someone who can handle
> > this kind of apps!
> >
> > https://admin.fedoraproject.org/pkgdb/packages/name/azureus
> >
> > https://bugzilla.redhat.com/buglist.cgi?quicksearch=azureus
> >
> > best regards
> > Stefan
>
> If nobody want it, I would like to take care of it.
>
> Alphonse

Do you still want this? If so please take it in pkgdb. If not I have an 
interest.

-- 
Conrad Meyer <konrad at tylerc.org>





From lakshmipathi.g at gmail.com  Wed Nov 26 04:41:41 2008
From: lakshmipathi.g at gmail.com (lakshmi pathi)
Date: Wed, 26 Nov 2008 10:11:41 +0530
Subject: Question on inode - Ext3 FS
Message-ID: <ae2f51270811252041q3c9b798fy7e6c03bd0250ab52@mail.gmail.com>

I have noticed that whenever you edit a file content,a new inode
number is assigned with the File.
But Sometime file changes the inode number,Sometimes it remains as older inode.

Can anyone please let know the concept behind this - modifing content
changes the file's inode but not all the time?

I'm using Fedora 7  with ext3 file system. (Kernel : 2.6.25.4)

Cheers,
Lakshmipathi.G



From fedora at leemhuis.info  Wed Nov 26 05:53:40 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 26 Nov 2008 06:53:40 +0100
Subject: Fedora Release Engineering Meeting Recap 2008-11-24
In-Reply-To: <492C5D62.4030304@redhat.com>
References: <492C5D62.4030304@redhat.com>
Message-ID: <492CE464.5060003@leemhuis.info>

On 25.11.2008 21:17, John Poelstra wrote:
 > [...]
> * f13: one thing I was toying with is when we branch and freeze, making 
> the development/ path continue on with say F12 content, and start 
> publishing the F11 content to releases/11/Everything/

Not the first time that idea comes up -- but I really think something 
like that is way overdue, as getting most of our development to a halt 
for 28 days seems bad as that together with the other freezes beforehand 
is more than 1/6 of the time a development cycle has.

So +1 to this.

CU
knurd



From gbuday at gmail.com  Wed Nov 26 07:12:40 2008
From: gbuday at gmail.com (Gergely Buday)
Date: Wed, 26 Nov 2008 08:12:40 +0100
Subject: NetworkManager cli docs
In-Reply-To: <49qtv5xv1j.ln2@ppp1053.in.ipex.cz>
References: <1227447232.3721.1.camel@sb-home>
	<1227542437.564.24.camel@localhost.localdomain>
	<1227554514.7267.1.camel@sb-home>
	<1227557641.25089.10.camel@localhost.localdomain>
	<20081124205106.GR22173@salma.internal.frields.org>
	<49qtv5xv1j.ln2@ppp1053.in.ipex.cz>
Message-ID: <90d975d30811252312l2479a583ve7cd3dfdaf06c8bc@mail.gmail.com>

Matej wrote:

>> That's a bug maybe worth filing against initscripts; the
>> /usr/share/doc/initscripts-*/sysconfig.txt file is fairly useful but
>> may have slipped out of currency.
>
> And if somebody converted that into manpage(s) she would be my
> personal hero.

I am not a hero type but this is certainly an itch to scratch for me.
I have taken a search for the initscripts project but got results only
for initscripts-ipv6. What I got is the home page for the rpm package:

https://admin.fedoraproject.org/pkgdb/packages/name/initscripts

Is this a fedora-only package? What is the way to sign up as a volunteer?

- Gergely



From valent.turkovic at gmail.com  Wed Nov 26 08:05:51 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Wed, 26 Nov 2008 09:05:51 +0100
Subject: kernel-devel in "Fedora" spin?
In-Reply-To: <778179b00811110654v235fb883l8245a4e9ab4a7ef7@mail.gmail.com>
References: <1221522171.2102.6.camel@luminos.localdomain>
	<48CF04A1.7020801@redhat.com>
	<20080916020742.GA11480@yoda.jdub.homelinux.org>
	<48D0232E.7080101@redhat.com>
	<64b14b300811110648m54e6e5fdwf67b9f21462732a4@mail.gmail.com>
	<778179b00811110654v235fb883l8245a4e9ab4a7ef7@mail.gmail.com>
Message-ID: <64b14b300811260005u2ce568fdja73e41422ca3cbaf@mail.gmail.com>

Has this made it for Fedora 10? Is fedora-devel on install and live media?

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 j.w.r.degoede at hhs.nl  Wed Nov 26 08:33:52 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 26 Nov 2008 09:33:52 +0100
Subject: Cross-distro games packaging mailing list
Message-ID: <492D09F0.9020906@hhs.nl>

Hi all,

if you are a games packager or have a general interest in FLOSS
games, let me point you to games at lists.freedesktop.org

The Debian and Ubuntu games teams have merged completely
and I've been working together with them to reduce duplicated work.
We have been using the Debian games mailing list until now, but we decided that
a distro-agnostic would be better.

As Games are somewhat special in that they in general need more patches then
usual packages and that they often have a dead upstream, we plan to discuss
some ways there to try and collaborate more on the front of games.

So to everyone interested, please subscribe!

Regards,

Hans



From alcapcom at gmail.com  Wed Nov 26 08:37:36 2008
From: alcapcom at gmail.com (Alphonse Van Assche)
Date: Wed, 26 Nov 2008 09:37:36 +0100
Subject: Orphaning azureus
In-Reply-To: <200811252018.15095.konrad@tylerc.org>
References: <20081024190916.A41D98E0003@hormel.redhat.com>	<20081028171711.3c1f1cc9@cheeky>
	<49082091.4090206@gmail.com> <200811252018.15095.konrad@tylerc.org>
Message-ID: <492D0AD0.5070408@gmail.com>

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



From alcapcom at gmail.com  Wed Nov 26 08:41:09 2008
From: alcapcom at gmail.com (Alphonse Van Assche)
Date: Wed, 26 Nov 2008 09:41:09 +0100
Subject: FAS reset pwd down
Message-ID: <492D0BA5.5050405@gmail.com>

Hi there,

Just to let you know that reseting password on FAS give a http 500.

Regards,
Alphonse



From pertusus at free.fr  Wed Nov 26 08:42:12 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 26 Nov 2008 09:42:12 +0100
Subject: orphaning gnome-volume-manager
In-Reply-To: <20081125211012.GD31416@nostromo.devel.redhat.com>
References: <1227544518.11161.19.camel@x61.fubar.dk>
	<20081124195620.GE3145@nostromo.devel.redhat.com>
	<20081124221443.GA2743@free.fr>
	<20081124221813.GA7701@nostromo.devel.redhat.com>
	<20081124222348.GB2743@free.fr>
	<20081125151401.GC27916@nostromo.devel.redhat.com>
	<20081125200020.GA2591@free.fr>
	<20081125211012.GD31416@nostromo.devel.redhat.com>
Message-ID: <20081126084212.GB2780@free.fr>

On Tue, Nov 25, 2008 at 04:10:12PM -0500, Bill Nottingham wrote:
> Patrice Dumas (pertusus at free.fr) said: 
> > > If a package's entire function has been subsumed by another package, there's
> > > no point in going through an orphan cycle.
> > 
> > There can be different packages providing the same functionality in
> > fedora. The criterion is the presence of a maintainer (and passing the 
> > review).
> 
> Not always. For example, we have obsoletes in perl for modules that moved
> into the base perl distribution. There's no reason to go through an orphan
> cycle for that. 

Agreed, renaming and merging of packages doesn't need to go through the
orphan process, and there are also certainly other cases, like fedora
specific packages that are not needed anymore, but it doesn't seems to 
be the case here.

> Similarly, if the entirety of gnome-volume-manager is poking
> interfaces that no longer exist, there's really no point to orphaning it.

It depends. If these interfaces can be brought up with a compat package,
it may make sense.

--
Pat



From konrad at tylerc.org  Wed Nov 26 08:48:49 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Wed, 26 Nov 2008 00:48:49 -0800
Subject: Orphaning azureus
In-Reply-To: <492D0AD0.5070408@gmail.com>
References: <20081024190916.A41D98E0003@hormel.redhat.com>
	<200811252018.15095.konrad@tylerc.org> <492D0AD0.5070408@gmail.com>
Message-ID: <200811260048.49879.konrad@tylerc.org>

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!

-- 
Conrad Meyer <konrad at tylerc.org>





From dwmw2 at infradead.org  Wed Nov 26 09:34:19 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 26 Nov 2008 09:34:19 +0000
Subject: Question on inode - Ext3 FS
In-Reply-To: <ae2f51270811252041q3c9b798fy7e6c03bd0250ab52@mail.gmail.com>
References: <ae2f51270811252041q3c9b798fy7e6c03bd0250ab52@mail.gmail.com>
Message-ID: <1227692059.978.2.camel@macbook.infradead.org>

On Wed, 2008-11-26 at 10:11 +0530, lakshmi pathi wrote:
> I have noticed that whenever you edit a file content,a new inode
> number is assigned with the File.
> But Sometime file changes the inode number,Sometimes it remains as older inode.
> 
> Can anyone please let know the concept behind this - modifing content
> changes the file's inode but not all the time?

It depends on your editor. If it just truncates and overwrites the
existing file, the inode number will be the same. If it writes a new
file and then renames it over the old one, it'll get a new inode number.

[dwmw2 at macbook ~]$ ls -i foo.c
2506954 foo.c
[dwmw2 at macbook ~]$ nano foo.c
[dwmw2 at macbook ~]$ ls -i foo.c
2506954 foo.c
[dwmw2 at macbook ~]$ emacs foo.c
[dwmw2 at macbook ~]$ ls -i foo.c
2506950 foo.c
[dwmw2 at macbook ~]$ 

-- 
dwmw2



From dominik at greysector.net  Wed Nov 26 10:54:18 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 26 Nov 2008 11:54:18 +0100
Subject: Heads up for mono-2.2
In-Reply-To: <f3ddc6d30811250928u4e16410dudae854774a726946@mail.gmail.com>
References: <1227617066.21103.456.camel@PB3.Linux>
	<1227618688.21103.460.camel@PB3.Linux>
	<3d44afb117e282abe3246c50869c60fa.squirrel@arekh.dyndns.org>
	<200811251528.07267.opensource@till.name>
	<f3ddc6d30811250928u4e16410dudae854774a726946@mail.gmail.com>
Message-ID: <20081126105417.GA2785@mokona.greysector.net>

On Tuesday, 25 November 2008 at 18:28, James Hubbard wrote:
> 2008/11/25 Till Maas <opensource at till.name>:
> > On Tue November 25 2008, Nicolas Mailhot wrote:
> >> The magic of -n will mean confused bug reporters that waste time
> >> searching for an srpm that does not exist anymore
> >
> > Why should people search for this srpm? If they do, why should they not use
> > use "yumdownloader --source monodoc" or to use "rpm -qi monodoc" to determine
> > the name of the srpm. I belive that if people need the srpm, they should be
> > skilled enough to use the right tools to get a srpm. And if there are not,
> > then they will at least learn how to search for an srpm the right way, after
> > they reported a bug.
> 
> Why does anyone go searching for a srpm?  Everyone has their reasons.
> You are assuming that the user has those tools.  What if the user is
> on another system or  does not have net connectivity?  I will go back
> to older versions of fedora to download srpms.  However, I usually
> know the package name.
> 
> I do not believe that not having a separate srpm for this will be a
> problem.  Anyone that needs it will probably figure it out.  I think
> that having packages where there are multiple applications in one rpm
> is more of a problem from the end user stand point.

You can always check which src.rpm a package was built from with rpm -qi.

> The example that
> sticks out my head is the kdeskd rpm.

yum search kdeskd returns no results.

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 rjones at redhat.com  Wed Nov 26 11:00:17 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 26 Nov 2008 11:00:17 +0000
Subject: error compiling postgresql with fedora mingw
In-Reply-To: <492BD6C0.5030602@ispbrasil.com.br>
References: <492BD6C0.5030602@ispbrasil.com.br>
Message-ID: <20081126110017.GA947@amd.home.annexia.org>

On Tue, Nov 25, 2008 at 08:43:12AM -0200, Itamar - IspBrasil wrote:
> `/home/itamar/fedora/mingw-postgresql/postgresql-8.3.5/src/port'
> i686-pc-mingw32-gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2  
> -fexceptions --param=ssp-buffer-size=4 -mms-bitfields -Wall  
> -Wmissing-prototypes -Wpointer-arith -Winline  
> -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing  
> -fwrapv zic.o ialloc.o scheck.o localtime.o -L../../src/port  
> -Wl,--allow-multiple-definition   -lpgport -lz -lm  -lws2_32 -lshfolder  
> -o zic.exe
> ../../src/port/libpgport.a: could not read symbols: Archive has no  
> index; run ranlib to add one

Probably best to ask Fedora MinGW questions on the Fedora MinGW list
next time ...

https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw

In this case the error is that the script uses 'ar' to create a static
library.  Either use 'i686-pc-mingw32-ar rcs' to make the library, or
run 'i686-pc-mingw32-ranlib' on the library generated above by 'ar'.

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 rjones at redhat.com  Wed Nov 26 11:03:31 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 26 Nov 2008 11:03:31 +0000
Subject: error compiling postgresql with fedora mingw
In-Reply-To: <6442.1227648976@sss.pgh.pa.us>
References: <492BD6C0.5030602@ispbrasil.com.br>
	<29573.1227635570@sss.pgh.pa.us>
	<492C451F.1010709@ispbrasil.com.br>
	<1227639900.23644.51.camel@localhost.localdomain>
	<3880.1227640767@sss.pgh.pa.us>
	<1227642164.23644.69.camel@localhost.localdomain>
	<6442.1227648976@sss.pgh.pa.us>
Message-ID: <20081126110331.GB947@amd.home.annexia.org>

On Tue, Nov 25, 2008 at 04:36:16PM -0500, Tom Lane wrote:
> Jon Burgess <jburgess777 at googlemail.com> writes:
> > I forgot to mention that some of the Makefiles have hard coded
> > references to windres which need replacing
> > with /usr/bin/i686-pc-mingw32-windres
> 
> Again, seems like tweaking the PATH should have taken care of that.
> 
> I think that upstream would be willing to take any patches needed to
> make this work with just the PATH tweak.  I'm not in a position to
> test it myself though, so if you'd put together a tested patch I'd
> be much obliged.

Hmm .. Tweaking $PATH hasn't been necessary on any of the other 50+
libraries we've done.  The Makefiles should allow you to override key
programs by using ${WINDRES) instead of 'windres' (etc.)  In this case
there is no path that contains an executable called 'windres' anyway.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v



From berrange at redhat.com  Wed Nov 26 11:05:59 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Wed, 26 Nov 2008 11:05:59 +0000
Subject: error compiling postgresql with fedora mingw
In-Reply-To: <3880.1227640767@sss.pgh.pa.us>
References: <492BD6C0.5030602@ispbrasil.com.br>
	<29573.1227635570@sss.pgh.pa.us>
	<492C451F.1010709@ispbrasil.com.br>
	<1227639900.23644.51.camel@localhost.localdomain>
	<3880.1227640767@sss.pgh.pa.us>
Message-ID: <20081126110559.GH16540@redhat.com>

On Tue, Nov 25, 2008 at 02:19:27PM -0500, Tom Lane wrote:
> Jon Burgess <jburgess777 at googlemail.com> writes:
> > I think the problem with the .a above is due to the default 'ar' failing
> > to process the Windows style object symbols.
> 
> > I managed to build PostgreSQL a couple of weeks back with MinGW on F9. I
> > had to override a few of the default tools, e.g.
> 
> > $ make AR=i686-pc-mingw32-ar DLLTOOL=/usr/i686-pc-mingw32/bin/dlltool
> > DLLWRAP=i686-pc-mingw32-dllwrap
> 
> That makes sense.  Could you have simplified matters by just prepending
> /usr/i686-pc-mingw32/bin to your PATH?

That is a possibility, but we recommend against doing that where posible
in Mingw RPM builds and cannot do it by default, because a number of
programs need to be able to use both the native & mingw versions of 'ar'
in their configure script. eg, they use native toolchain to build a
helper program, that they then use in their build process. So we can't
simply point 'ar' to the mingw version. In autotool'd apps configure
will generally do the right thing & find i6868-pc-mingw32-ae, for other
apps, having a makefile variable AR=ar will at least allow for easy
override when doing a mingw build by adding AR=i686-pc-mingw32-ar to
the make flags.

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 itamar at ispbrasil.com.br  Wed Nov 26 11:14:54 2008
From: itamar at ispbrasil.com.br (Itamar - IspBrasil)
Date: Wed, 26 Nov 2008 09:14:54 -0200
Subject: error compiling postgresql with fedora mingw
In-Reply-To: <6442.1227648976@sss.pgh.pa.us>
References: <492BD6C0.5030602@ispbrasil.com.br>	<29573.1227635570@sss.pgh.pa.us>	<492C451F.1010709@ispbrasil.com.br>	<1227639900.23644.51.camel@localhost.localdomain>	<3880.1227640767@sss.pgh.pa.us>	<1227642164.23644.69.camel@localhost.localdomain>
	<6442.1227648976@sss.pgh.pa.us>
Message-ID: <492D2FAE.10701@ispbrasil.com.br>

this patch works for me,

postgresql stop after some lines about a missing windres file, but this 
is another problem

> Hmm, that sounds familiar all of a sudden.  [ digs in archives... ]
> Is this proposed patch addressing the same thing?
>
> http://archives.postgresql.org/pgsql-hackers/2008-11/msg00367.php
>
> It hasn't gotten applied, probably because no one else confirmed it
> was needed, but if you can confirm it ...
>
> 			regards, tom lane
>
>    
-- 
------------

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 kulbirsaini at students.iiit.ac.in  Wed Nov 26 11:53:55 2008
From: kulbirsaini at students.iiit.ac.in (Kulbir Saini)
Date: Wed, 26 Nov 2008 17:23:55 +0530
Subject: New users confused about Spins' Names
Message-ID: <492D38D3.1050303@students.iiit.ac.in>

Hi list,

    Yesterday, I posted a blog entry[1] about Fedora 10 Release on my 
blog and mentioned the Fedora 10 Spins availability with link to Fedora 
Project page[2]. I have received a comment[3] which says,

    "I might be interested in some of the spins, but it's hard to tell. 
The names contain acronyms, and the description simply repeats the 
acronym. Unless I recognize what that acronym is, the name is useless. 
What's FEL, AOS or broffice? XFCE is the only one I know, though others 
might not even know that.

    Since the table has a description field for each spin, why not (at 
least) expand the acronyms so folks have a clue as to whether or not it 
might be useful? Even better, a link to a page describing the spin in 
more detail. If it's worth the time and effort to create, it should be 
worth the time it takes to write a paragraph describing it."

    Well, I also got confused by the acronyms, but quick googling 
suggested the Fedora Project Wiki already has pages describing the 
acronyms in details. I request people maintaining the spins to link the 
description to their respective wiki pages.

[1] http://fedora.co.in/content/fedora-10-cambridge-released
[2] http://spins.fedoraproject.org/
[3] http://fedora.co.in/content/fedora-10-cambridge-released#comment-573

---------------------------------------------------
Thank you,
Kulbir Saini,
Computer Science and Engineering,
International Institute of Information Technology,
Hyderbad, India - 500032.

My Home-Page: http://saini.co.in/
My Project : http://cachevideos.com/
My Web-Blog: http://fedora.co.in/

IRC nick : generalBordeaux
Channels : #fedora, #fedora-devel, #yum on freenode

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



From nicu_fedora at nicubunu.ro  Wed Nov 26 11:55:46 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Wed, 26 Nov 2008 13:55:46 +0200
Subject: New users confused about Spins' Names
In-Reply-To: <492D38D3.1050303@students.iiit.ac.in>
References: <492D38D3.1050303@students.iiit.ac.in>
Message-ID: <492D3942.1020106@nicubunu.ro>

Kulbir Saini wrote:
>    Well, I also got confused by the acronyms, but quick googling 
> suggested the Fedora Project Wiki already has pages describing the 
> acronyms in details. I request people maintaining the spins to link the 
> description to their respective wiki pages.

Or better stick to the plan and make the spins page into something 
usable and friendly, like those old mockups: 
http://fedoraproject.org/wiki/Websites/Spins/Mockups

-- 
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 nicolas.mailhot at laposte.net  Wed Nov 26 11:56:27 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 26 Nov 2008 12:56:27 +0100 (CET)
Subject: Heads up for mono-2.2
In-Reply-To: <20081126105417.GA2785@mokona.greysector.net>
References: <1227617066.21103.456.camel@PB3.Linux>
	<1227618688.21103.460.camel@PB3.Linux>
	<3d44afb117e282abe3246c50869c60fa.squirrel@arekh.dyndns.org>
	<200811251528.07267.opensource@till.name>
	<f3ddc6d30811250928u4e16410dudae854774a726946@mail.gmail.com>
	<20081126105417.GA2785@mokona.greysector.net>
Message-ID: <28ba7d38affef39789dd161bcb1e5115.squirrel@arekh.dyndns.org>



Le Mer 26 novembre 2008 11:54, Dominik 'Rathann' Mierzejewski a ?crit :
>
> On Tuesday, 25 November 2008 at 18:28, James Hubbard wrote:
>> 2008/11/25 Till Maas <opensource at till.name>:
>> > On Tue November 25 2008, Nicolas Mailhot wrote:
>> >> The magic of -n will mean confused bug reporters that waste time
>> >> searching for an srpm that does not exist anymore
>> >
>> > Why should people search for this srpm?

Because all our tools including bugzilla list srpm names, not rpm names.

>> > And if there
>> are not,
>> > then they will at least learn how to search for an srpm the right
>> way, after
>> > they reported a bug.

To report a bug they need to know the srpm name

>> I do not believe that not having a separate srpm for this will be a
>> problem.  Anyone that needs it will probably figure it out.

> You can always check which src.rpm a package was built from with rpm
> -qi.

You can do a lot of things, but my point is
1. most people won't bother and therefore
2. magic packages where the rpm -> srpm relation is not obvious are
just introducing drag and problems in the Fedora workflows.

-- 
Nicolas Mailhot



From rc040203 at freenet.de  Wed Nov 26 12:15:51 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 26 Nov 2008 13:15:51 +0100
Subject: error compiling postgresql with fedora mingw
In-Reply-To: <20081126110559.GH16540@redhat.com>
References: <492BD6C0.5030602@ispbrasil.com.br>
	<29573.1227635570@sss.pgh.pa.us> <492C451F.1010709@ispbrasil.com.br>
	<1227639900.23644.51.camel@localhost.localdomain>
	<3880.1227640767@sss.pgh.pa.us>  <20081126110559.GH16540@redhat.com>
Message-ID: <1227701751.4300.5.camel@beck.corsepiu.local>

On Wed, 2008-11-26 at 11:05 +0000, Daniel P. Berrange wrote:
> On Tue, Nov 25, 2008 at 02:19:27PM -0500, Tom Lane wrote:
> > Jon Burgess <jburgess777 at googlemail.com> writes:
> > > I think the problem with the .a above is due to the default 'ar' failing
> > > to process the Windows style object symbols.
> > 
> > > I managed to build PostgreSQL a couple of weeks back with MinGW on F9. I
> > > had to override a few of the default tools, e.g.
> > 
> > > $ make AR=i686-pc-mingw32-ar DLLTOOL=/usr/i686-pc-mingw32/bin/dlltool
> > > DLLWRAP=i686-pc-mingw32-dllwrap
> > 
> > That makes sense.  Could you have simplified matters by just prepending
> > /usr/i686-pc-mingw32/bin to your PATH?
> 
> That is a possibility, but we recommend against doing that where posible
> in Mingw RPM builds
More important: /usr/i686-pc-mingw32/bin in $PATH breaks building
packages which contain both native and "to be cross-compiled" packages
(e.g. two or tripple leaf Canadian Cross built packages).

That said, I also recommend against this habit - In case of properly
packaged autoconf/automake-based packages it definitely wrong.

>  and cannot do it by default, because a number of
> programs need to be able to use both the native & mingw versions of 'ar'
> in their configure script. eg, they use native toolchain to build a
> helper program, that they then use in their build process. So we can't
> simply point 'ar' to the mingw version. In autotool'd apps configure
> will generally do the right thing & find i6868-pc-mingw32-ae, for other
> apps, having a makefile variable AR=ar

Only for "single target" packages. For packages with multiple targets,
this won't work, at least not without very careful analysis of the a
package's configury.

>  will at least allow for easy
> override when doing a mingw build by adding AR=i686-pc-mingw32-ar to
> the make flags.

Ralf




From dominik at greysector.net  Wed Nov 26 12:18:43 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 26 Nov 2008 13:18:43 +0100
Subject: Heads up for mono-2.2
In-Reply-To: <28ba7d38affef39789dd161bcb1e5115.squirrel@arekh.dyndns.org>
References: <1227617066.21103.456.camel@PB3.Linux>
	<1227618688.21103.460.camel@PB3.Linux>
	<3d44afb117e282abe3246c50869c60fa.squirrel@arekh.dyndns.org>
	<200811251528.07267.opensource@till.name>
	<f3ddc6d30811250928u4e16410dudae854774a726946@mail.gmail.com>
	<20081126105417.GA2785@mokona.greysector.net>
	<28ba7d38affef39789dd161bcb1e5115.squirrel@arekh.dyndns.org>
Message-ID: <20081126121842.GA3865@mokona.greysector.net>

On Wednesday, 26 November 2008 at 12:56, Nicolas Mailhot wrote:
> 
> 
> Le Mer 26 novembre 2008 11:54, Dominik 'Rathann' Mierzejewski a ?crit :
> >
> > On Tuesday, 25 November 2008 at 18:28, James Hubbard wrote:
> >> 2008/11/25 Till Maas <opensource at till.name>:
> >> > On Tue November 25 2008, Nicolas Mailhot wrote:
> >> >> The magic of -n will mean confused bug reporters that waste time
> >> >> searching for an srpm that does not exist anymore
> >> >
> >> > Why should people search for this srpm?
> 
> Because all our tools including bugzilla list srpm names, not rpm names.

That's something that could be changed. Why can't bugzilla map rpm names
to srpm names automagically? Also see below.

> >> > And if there
> >> are not,
> >> > then they will at least learn how to search for an srpm the right
> >> way, after
> >> > they reported a bug.
> 
> To report a bug they need to know the srpm name

That shouldn't be a requirement. In fact, I remember some discussion around
here about providing some bug-reporting aid tool that would provide some
of the necessary details automagically (srpm name being one of them).

> >> I do not believe that not having a separate srpm for this will be a
> >> problem.  Anyone that needs it will probably figure it out.
> 
> > You can always check which src.rpm a package was built from with rpm
> > -qi.
> 
> You can do a lot of things, but my point is
> 1. most people won't bother and therefore
> 2. magic packages where the rpm -> srpm relation is not obvious are
> just introducing drag and problems in the Fedora workflows.

That should not be an argument to force packagers to use convoluted
rpm names. Building monodoc.rpm from mono.src.rpm is perfectly fine
if they come from a single tarball.

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 rawhide at fedoraproject.org  Wed Nov 26 12:36:31 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Wed, 26 Nov 2008 12:36:31 +0000 (UTC)
Subject: rawhide report: 20081126 changes
Message-ID: <20081126123631.8BB4F1F823B@releng2.fedora.phx.redhat.com>

Compose started at Wed Nov 26 06:01:11 UTC 2008

New package 0xFFFF
        The Open Free Fiasco Firmware Flasher
New package Ajaxterm
        A web-based terminal
New package R-bigmemory
        Manage massive matrices in R using C++, with support for shared memory
New package ace
        Appliance Configuration Engine
New package apanov-heuristica-fonts
        Heuristica font
New package atari++
        Unix based emulator of the Atari eight bit computers
New package balance
        TCP load-balancing proxy server with round robin and failover mechanisms
New package bam
        A build-system
New package barrage
        Kill and destroy as many targets as possible within 3 minutes
New package barry
        BlackBerry Desktop for Linux
New package biniax
        A unique arcade logic game
New package bunny
        Instrumented C code security fuzzer
New package cave9
        3d game of cave exploration
New package cfdg-fe
        A front end to cfdg
New package chrony
        An NTP client/server
New package clipper
        Clipper C++ crystallographic library
New package corrida
        Application for archivation of meteor observations
New package cpuid
        Dumps information about the CPU(s)
New package dnsperf
        Benchmarking authorative and recursing DNS servers
New package dopewars
        A drug dealing game
New package edb
        A debugger based on the ptrace API and Qt4
New package fedora-business-cards
        A tool for rendering Fedora contributor business cards
New package fuse-zip
        Fuse-zip is a fs to navigate, extract, create and modify ZIP archives
New package g2ipmsg
        IP Messenger for GNOME 2
New package garmindev
        Drivers for communication with Garmin GPS devices
New package ghc-gtk2hs
        Haskell binding for gtk2
New package gnome-gmail-notifier
        A simple application that monitors Gmail inboxes
New package gnome-rdp
        Remote Desktop Protocol client for the GNOME desktop environment
New package gpp4
        Library providing specific CCP4 functionality
New package gstreamer-java
        Java interface to the gstreamer framework
New package hanazono-fonts
        Japanese Mincho-typeface TrueType font
New package homestead
        3D real-time network visualiser
New package ht
        File editor/viewer/analyzer for executables
New package hunspell-cop
        Coptic hunspell dictionaries
New package hunspell-eo
        Esperanto hunspell dictionaries
New package hunspell-no
        Norwegian hunspell dictionaries
New package hunspell-tet
        Tetum hunspell dictionaries
New package ibp
        A tool to show which IBP beacons are transmitting
New package ifstat
        Interface statistics
New package jabberpy
        Python xmlstream and jabber IM protocol libs
New package kcirbshooter
        A small puzzle game
New package kde-plasma-runcommand
        Simple plasmoid to run commands without using terminal or KRunner
New package ladvd
        CDP/LLDP sender for unix
New package laf-plugin
        Generic plugin framework for Java look-and-feels
New package lensfun
        A library to rectify the defects introduced by your photographic equipment
New package libev
        High-performance event loop/event model with lots of features
New package libfplll
        LLL-reduces euclidian lattices
New package libglfw
        An OpenGl framework
New package libprojectM
        The libraries for the projectM music visualization plugin
New package libprojectM-qt
        The Qt frontend to the projectM visualization plugin
New package libsqlite3x
        A C++ Wrapper for the SQLite3 embeddable SQL database engine
New package libtopology
        CPU Topology library
New package lordsawar
        Turn-based strategy game in a fantasy setting
New package lynis
        Security and system auditing tool
New package mingw32-binutils
        MinGW Windows binutils
New package mingw32-filesystem
        MinGW base filesystem and environment
New package mmdb
        Macromolecular coordinate library
New package mpfi
        An interval arithmetic library based on MPFR
New package nebula
        Intrusion signature generator
New package nettee
        Network "tee" program
New package ocp
        Open Cubic Player for MOD/S3M/XM/IT/SID/MIDI music files
New package ohm
        Open Hardware Manager
New package olpc-utils
        OLPC utilities
New package olpcsound
        Csound - sound synthesis language and library, OLPC subset
New package otl
        OTL is a C++ template library for Oracle/OCI, ODBC, and DB2/CLI connectivity
New package parprouted
        Proxy ARP IP bridging daemon
New package perl-App-Cmd
        Write command line apps with less suffering
New package perl-Cache-FastMmap
        Uses an mmap'ed file to act as a shared memory interprocess cache
New package perl-Catalyst-Engine-Apache
        Catalyst Apache Engines
New package perl-Catalyst-Plugin-Session-Store-FastMmap
        FastMmap session storage backend
New package perl-Check-ISA
        DWIM, correct checking of an object's class
New package perl-Devel-GlobalDestruction
        Expose PL_dirty, the flag which marks global destruction
New package perl-File-Comments
        Recognizes file formats and extracts format-specific comments
New package perl-File-ShareDir-PAR
        File::ShareDir with PAR support
New package perl-HTML-Tiny
        Lightweight, dependency free HTML/XML generation
New package perl-IO-TieCombine
        Produce tied (and other) separate but combined variables
New package perl-Module-Util
        Module name tools and transformations
New package perl-MooseX-Log-Log4perl
        A Logging Role for Moose based on Log::Log4perl
New package perl-MooseX-Types-Path-Class
        A Path::Class type library for Moose
New package perl-Regexp-Assemble
        Assemble multiple Regular Expressions into a single RE
New package perl-Regexp-Copy
        Copy Regexp objects
New package perl-Sort-Naturally
        Sort lexically, but sort numeral parts numerically
New package perl-Sub-Override
        Perl extension for easily overriding subroutines
New package perl-TAP-Harness-JUnit
        Generate JUnit compatible output from TAP results
New package perl-Term-Size
        Simple way to get terminal size
New package perl-Test-Block
        Specify fine granularity test plans
New package perl-Test-Strict
        Check syntax, presence of use strict/warnings, and test coverage
New package perl-URI-FromHash
        Build a URI from a set of named parameters
New package perl-asa
        Lets your class/object say it works like something else
New package perl-boolean
        Boolean support for Perl
New package php-pecl-ssh2
        Bindings for the libssh2 library
New package pngcrush
        Optimizer for PNG (Portable Network Graphics) files
New package pngnq
        Pngnq is a tool for quantizing PNG images in RGBA format
New package projectM-jack
        The projectM visualization plugin for jack
New package projectM-libvisual
        The projectM visualization plugin for libvisual
New package projectM-pulseaudio
        The projectM visualization plugin for pulseaudio
New package pstreams-devel
        POSIX Process Control in C++
New package pystatgrab
        Python bindings for libstatgrab
New package python-Levenshtein
        Python extension computing string distances and similarities
New package python-dbsprockets
        A package for creation of web widgets directly from database definitions
New package python-feedcache
        Wrapper for Mark Pilgrim's FeedParser module which caches feed content
New package python-flickrapi
        Python module for interfacing with the Flickr API
New package python-rabbyt
        Sprite library for Python
New package python-repoze-tm2
        Zope-like transaction manager via WSGI middleware
New package python-suds
        A python SOAP client
New package python-transaction
        Transaction management for Python
New package python-twitter
        A python wrapper around the Twitter API
New package python-wikimarkup
        Formats text to Mediawiki syntax
New package python-zope-sqlalchemy
        Minimal Zope/SQLAlchemy transaction integration
New package qdevelop
        Development environment dedicated to Qt4
New package qlandkartegt
        GPS device mapping tool
New package qle
        A QSO Logger and log Editor
New package quickfix
        QuickFIX is a full-featured open source FIX engine
New package rmanage
        Remotely monitoring machines on network
New package ruby-rpm
        Ruby bindings for RPM
New package rubygem-facets
        The single most extensive additions and extensions library available for Ruby
New package rubygem-gruff
        Beautiful graphs for one or multiple datasets
New package rubygem-rspec
        Behaviour driven development (BDD) framework for Ruby
New package saoimage
        Utility for displaying astronomical images
New package scummvm-tools
        Tools for scummVM / S.C.U.M.M scripting language
New package sfxr
        Sound effect generator
New package shed
        Easy to use hex editor
New package sip-redirect
        Tiny IPv4 and IPv6 SIP redirect server written in Perl
New package skychart
        Planetarium software for the advanced amateur astronomer
New package snmp++
        SNMP++v3.x is based on SNMP++v2.8 from HP* and extends it by support for SNMPv3
New package ssm
        Macromolecular coordinate superposition library
New package sugar-analyze
        Analysing tool for Sugar
New package sugar-jukebox
        Media player activity for Sugar
New package sugar-turtleart
        Turtle Art activity for sugar
New package sympy
        A Python library for symbolic mathematics
New package taginfo
        Printer of Tag Information from Media Files
New package tasque
        A simple task management app (TODO list) for the Linux Desktop
New package tcl-tktreectrl
        Multi-column hierarchical listbox widget for Tk
New package tightvnc
        A TightVNC remote display system
New package ttf2pt1
        TrueType to Adobe Type 1 font converter
New package ufiformat
        Disk formatting utility for USB floppy devices
New package unbound
        Validating, recursive, and caching DNS(SEC) resolver
New package unikurd-web-font
        A widely used Kurdish font
New package vdr-remote
        Extended remote control plugin for VDR
New package virt-ctrl
        Graphical management app for virtual machines
New package vtun
        Virtual tunnel over TCP/IP networks
New package wput
        A utility for uploading files or whole directories to remote ftp-servers
New package xlcrack
        Recover lost and forgotten passwords from XLS files
New package xmp
        A multi-format module player
New package xwota
        Who's On the Air Database interface
New package zfs-fuse
        ZFS ported to Linux FUSE
Removed package gtk2hs
Removed package haddock
Removed package perl-TAP-Harness
Removed package rcssbase
Removed package s390utils
Updated Packages:

BackupPC-3.1.0-3.fc11
---------------------

Canna-3.7p3-26.fc11
-------------------
* Fri Nov 21 17:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 3.7p3-26
- Fix a source URL.


Cython-0.10.1-1.fc11
--------------------
* Wed Nov 19 17:00:00 2008 Neal Becker <ndbecker2 at gmail.com> - 0.10.1-1
- Update to 0.10.1

* Sun Nov  9 17:00:00 2008 Neal Becker <ndbecker2 at gmail.com> - 0.10-3
- Fix typo

* Sun Nov  9 17:00:00 2008 Neal Becker <ndbecker2 at gmail.com> - 0.10-1
- Update to 0.10


DeviceKit-002-3
---------------
* Thu Nov 13 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 002-3
- Update to 002


DeviceKit-power-002-1.fc11
--------------------------
* Thu Nov 13 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> 002-1
- Update to 002


DivFix++-0.30-3.fc11
--------------------

ImageMagick-6.4.5.5-3.fc11
--------------------------
* Wed Nov 19 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 6.4.5.5-3
- Remove --without-windows-font-dir from configure args, specifying it
  makes ImageMagick search for windows fonts in the "no/" dir (rh 472244)

* Fri Nov 14 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 6.4.5.5-2
- Enable djvu support, put the new djvu plugin into a separate -djvu
  subpackage because of deps (rh 225897)

* Fri Nov 14 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 6.4.5.5-1
- New upstream release 6.4.5-5
- Various specfile fixes from merge review (rh 225897)
- Fix building with new libtool (rh 471468)

* Thu Nov 13 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 6.4.0.10-3
- Rebuild for new libtool (rh 471468)


LabPlot-1.6.0.2-3.fc11
----------------------
* Sun Nov 16 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 1.6.0.2-3
- handle libLabPlotnetCDF.so* on F-8 and F-9


NetworkManager-0.7.0-0.12.svn4326.fc11
--------------------------------------
* Fri Nov 21 17:00:00 2008 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.12.svn4326
- API and documentation updates
- Fix PIN handling on 'hso' mobile broadband devices

* Tue Nov 18 17:00:00 2008 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.12.svn4296
- Fix PIN/PUK issues with high-speed Option HSDPA mobile broadband cards
- Fix desensitized OK button when asking for wireless keys

* Mon Nov 17 17:00:00 2008 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.12.svn4295
- Fix issues reading ifcfg files
- Previously fixed:
- Doesn't send DHCP hostname (rh #469336)
- 'Auto eth0' forgets settings (rh #468612)
- DHCP renewal sometimes breaks VPN (rh #471852)
- Connection editor menu item in the wrong place (rh #471495)
- Cannot make system-wide connections (rh #471308)

* Fri Nov 14 17:00:00 2008 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.12.svn4293
- Update to NetworkManager 0.7.0 RC2
- Handle gateways on a different subnet from the interface
- Clear VPN secrets on connection failure to ensure they are requested again (rh #429287)
- Add support for PKCS#12 private keys (rh #462705)
- Fix mangling of VPN's default route on DHCP renew
- Fix type detection of qemu/kvm network devices (rh #466340)
- Clear up netmask/prefix confusion in the connection editor
- Make the secrets dialog go away when it's not needed
- Fix inability to add system connections (rh #471308)


NetworkManager-openvpn-0.7.0-16.svn4326.fc11
--------------------------------------------
* Fri Nov 21 17:00:00 2008 Dan Williams <dcbw at redhat.com> 1:0.7.0-16.svn4326
- Rebuild for updated NetworkManager


NetworkManager-pptp-0.7.0-0.12.svn4326.fc11
-------------------------------------------
* Fri Nov 21 17:00:00 2008 Dan Williams <dcbw at redhat.com> 1:0.7.0-12.svn4326
- Rebuild for updated NetworkManager


NetworkManager-vpnc-0.7.0-0.11.svn4326.fc11
-------------------------------------------
* Fri Nov 21 17:00:00 2008 Dan Williams <dcbw at redhat.com> 1:0.7.0-0.11.svn4326
- Rebuild for updated NetworkManager

* Tue Nov 18 17:00:00 2008 Dan Williams <dcbw at redhat.com> 1:0.7.0-0.11.svn4296
- Rebuild for updated NetworkManager

* Mon Nov 17 17:00:00 2008 Dan Williams <dcbw at redhat.com> 1:0.7.0-0.11.svn4293
- Ensure errors are shown when connection fails (rh #331141)
- Fix failures to ask for passwords on connect (rh #429287)
- Fix routing when concentrator specifies routes (rh #449283)
- Pull in upstream support for tokens and not saving passwords


OmegaT-1.7.3_04-2.fc11
----------------------
* Fri Nov 21 17:00:00 2008 Ismael Olea <ismael at olea.org> 1.7.3_04-2
- stupid new release caused by my fault

* Fri Nov 21 17:00:00 2008 Ismael Olea <ismael at olea.org> 1.7.3_04-1
- updating to 1.7.3_04

* Tue Nov 18 17:00:00 2008 Ismael Olea <ismael at olea.org> 1.7.3_03-6
- Fixing htmlparser non-present dependency (bug #471573)


PackageKit-0.3.11-1.fc11
------------------------
* Mon Nov 24 17:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.11-1
- New upstream version
- http://gitweb.freedesktop.org/?p=packagekit.git;a=blob;f=NEWS

* Thu Nov 20 17:00:00 2008 Richard Hughes <rhughes at redhat.com> - 0.3.10-2
- Update the summary to be more terse.

* Tue Nov 11 17:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.10-1
- New upstream version
- Drop all upstreamed patches


PyKDE-3.16.2-1.fc11
-------------------
* Mon Nov 17 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 3.16.2-1
- PyKDE-3.16.2


PyQt-3.17.6-1.fc11
------------------
* Mon Nov 17 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 3.17.6-1
- PyQt-3.17.6

* Mon Nov 10 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 3.17.5-1
- PyQt-3.17.5


PyQt4-4.4.4-1.fc11
------------------
* Mon Nov 10 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.4.4-1
- PyQt-4.4.4


QuantLib-0.9.7-3.fc11
---------------------
* Mon Nov 24 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 0.9.7-3
- rename conflicting man pages (bz 472615)

* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 0.9.7-2
- missing man pages

* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 0.9.7-1
- update to 0.9.7


R-hdf5-1.6.8-1.fc11
-------------------
* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.6.8-1
- update to 1.6.8


SDL_gfx-2.0.17-1.fc11
---------------------
* Mon Nov 24 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 2.0.17-1
- Update to 2.0.17.


Zim-0.27-1.fc11
---------------
* Fri Nov 21 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.27-1
- update to 0.27


abiword-2.6.5-9.fc11
--------------------
* Sun Nov 23 17:00:00 2008 Marc Maurer <uwog at abisource.com> - 1:2.6.5-1
- New upstream release

* Thu Nov 20 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> - 1:2.6.4-9
- Remove unused script to drop perl dependency


acpid-1.0.8-1.fc11
------------------

alex-2.3-2.fc11
---------------
* Tue Nov 25 17:00:00 2008 Jens Petersen <petersen at redhat.com> - 2.3-2
- build with new macros
- update urls to point to hackage
- add alex-2.3-base3.patch to build with base-3 for ghc-6.10.1


alliance-5.0-23.20070718snap.fc11
---------------------------------

altermime-0.3.10-1.fc11
-----------------------
* Sat Nov 22 17:00:00 2008 Tim Jackson <rpm at timj.co.uk> 0.3.10-1
- Update to version 0.3.10


amanda-2.6.0p2-4.fc11
---------------------
* Thu Nov 20 17:00:00 2008 Daniel Novotny <dnovotny at redhat.com> 2.6.0p2-4
.usernameupdate extension changed to .rpmsave (#472349)


amqp-1.0.720585-1.fc11
----------------------
* Tue Nov 25 17:00:00 2008 Nuno Santos <nsantos at redhat.com> - 0:1.0.720585-1
- Rebased to svn rev 705858


anaconda-11.4.1.58-1
--------------------

anjuta-2.24.1-2.fc11
--------------------
* Sun Nov  9 17:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 1:2.24.1-2
- Added 'Requires: libglade2 >= 2.6.3-2' and a symlink to libanjuta.so.0 for
  some plugins to work. Closes Red Hat Bugzilla bug #467894.


anthy-9100e-4.fc11
------------------
* Fri Nov 21 17:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 9100e-4
- Fix a source URL.


anyremote-4.12-1.fc11
---------------------
* Thu Nov 13 17:00:00 2008 Mikhail Fedotov <anyremote at mail.ru> - 4.12-1
- Added configuration file for XBMC (thanks to Everthon Valadao), Okular 
  Gwenview/KDE4 and Amarok2/KDE4. Support nonn-UTF8 encodings in 
  configurational files. Intergrated FreeBSD patch by Alex Samorukov.


aplus-fsf-4.22.4-5.fc11
-----------------------
* Mon Nov 17 17:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> 4.22.4-5
- Try to fix build issue agains libtools-2


archimedes-0.8.0-1.fc11
-----------------------
* Wed Nov 12 17:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 0.8.0-1
- Version bump to 0.8.0. Closes Red Hat Bugzilla bug #464360.


ardour-2.7-1.fc11
-----------------
* Fri Nov 21 17:00:00 2008 Anthony Green <green at redhat.com> 2.7-1
- New upstream release 2.7.


artwiz-aleczapka-fonts-1.3-6.fc11
---------------------------------
* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 1.3-6
- font cleanup on fkp font (bz 472220)


aspell-is-0.51.1-5.fc11
-----------------------
* Mon Nov 10 17:00:00 2008 Ivana Varekova <varekova at redhat.com> - 50:0.51.1-5
- fix encoding problem (#470526)


asterisk-1.6.1-0.5beta2.fc11
----------------------------
* Fri Nov  7 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.6.1-0.5.beta2
- Add patch to fix missing variable on PPC.

* Fri Nov  7 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.6.1-0.4.beta2
- Update PPC systems don't have sys/io.h patch.

* Fri Nov  7 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.6.1-0.3.beta2
- PPC systems don't have sys/io.h

* Fri Nov  7 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.6.1-0.2.beta2
- Update to 1.6.1 beta 2

* Wed Nov  5 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.6.0.1-3
- Fix issue with init script giving wrong path to config file.


asymptote-1.52-1.fc11
---------------------
* Tue Nov 25 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.52-1
- 1.52

* Tue Nov 11 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.51-1
- update to 1.51

* Mon Nov  3 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.49-1
- update to 1.49


at-spi-1.25.1-1.fc11
--------------------
* Wed Nov 12 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1.25.1-1
- Update to 1.25.1


atanks-3.2-1.fc11
-----------------
* Sun Nov 23 17:00:00 2008 Konstantin Ryabitsev <icon at fedoraproject.org> - 3.2-1
- Upstream 3.2
- Use upstream atanks.png


audacious-1.5.1-5.fc11
----------------------
* Mon Nov 17 17:00:00 2008 Ralf Ertzinger <ralf at skytale.net> 1.5.1-5
- Disable SSE2


augeas-0.3.4-1.fc11
-------------------
* Wed Nov  5 17:00:00 2008 David Lutterkort <lutter at redhat.com> - 0.3.4-1
- New version


autofs-5.0.4-2
--------------
* Tue Nov 11 17:00:00 2008 Ian Kent <kent at redhat.com> - 5.0.4-2
- Fix tag confusion.

* Tue Nov 11 17:00:00 2008 Ian Kent <kent at redhat.com> - 5.0.4-1
- Upstream source version 5.0.4.

* Tue Nov 11 17:00:00 2008 Ian Kent <kent at redhat.com> - 5.0.3-32
- correct buffer length setting in autofs-5.0.3-fix-ifc-buff-size-fix.patch.


bacula-2.4.3-3.fc11
-------------------
* Mon Nov 17 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 2.4.3-3
- Added upstream orphaned jobs patch.
- Fixed logrotate file.

* Mon Nov 10 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 2.4.3-2
- Added bat.  BZ 470800.


banshee-1.4.0.1-1.fc11
----------------------

basket-1.0.3.1-2.fc11
---------------------
* Mon Nov 10 17:00:00 2008 Christopher D. Stover <quantumburnz at hotmail.com> 1.0.3.1-2
- added a requires for hicolor-icon-theme
- removed -p from the main package /sbin/ldconfig

* Sat Oct 25 18:00:00 2008 Christopher D. Stover <quantumburnz at hotmail.com> 1.0.3.1-1
- version 1.0.3.1
- gcc43 patch is no longer needed


bcfg2-0.9.6-1.fc11
------------------
* Tue Nov 18 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.9.6-1
- Update to 0.9.6 final.

* Tue Oct 14 18:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.9.6-0.8.pre3
- Update to 0.9.6pre3

* Sat Aug  9 18:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.9.6-0.2.pre2
- Update to 0.9.6pre2

* Wed May 28 18:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.9.6-0.1.pre1
- Update to 0.9.6pre1


beagle-0.3.8-13.fc11
--------------------

bind-9.6.0-0.2.b1.fc11
----------------------
* Tue Nov 11 17:00:00 2008 Adam Tkac <atkac redhat com> 32:9.6.0-0.2.b1
- make statistics http server working, patch backported from 9.6 HEAD

* Mon Nov 10 17:00:00 2008 Adam Tkac <atkac redhat com> 32:9.6.0-0.1.b1
- 9.6.0b1 release
- don't build ODBC and Berkeley DB DLZ drivers
- end of bind-chroot-admin script, copy config files to chroot manually
- /proc doesn't have to be mounted to chroot
- temporary use libbind from 9.5 series, noone has been released for 9.6 yet

* Mon Nov  3 17:00:00 2008 Adam Tkac <atkac redhat com> 32:9.5.1-0.8.4.b2
- dig/host: use only IPv4 addresses when -4 option is specified (#469440)

* Thu Oct 30 18:00:00 2008 Adam Tkac <atkac redhat com> 32:9.5.1-0.8.2.b2
- removed unneeded bind-9.4.1-ldap-api.patch

* Thu Oct 30 18:00:00 2008 Adam Tkac <atkac redhat com> 32:9.5.1-0.8.1.b2
- ship dns/{s,}dlz.h and isc/radix.h in bind-devel


binutils-2.19.50.0.1-7.fc11
---------------------------
* Fri Nov 21 17:00:00 2008 Nick Clifton <nickc at redhat.com> 2.19.50.0.1
- Rebase sources on 2.19.50.0.1 tarball.  Update all patches, trimming
  those that are no longer needed.


bison-2.4-2.fc11
----------------
* Wed Nov 12 17:00:00 2008 Petr Machata <pmachata at redhat.com> - 2.4-2
- Rebase to 2.4
- Resolves: #471183

* Mon Sep 15 18:00:00 2008 Petr Machata <pmachata at redhat.com> - 2.3-6
- Merge review:
  - Drop terminating dot from Summary
  - Escape macros inadvertently left in changelog
  - Explain why are there source files in the main package


bit-0.4.90-2.fc9
----------------
* Mon Nov  3 17:00:00 2008 Rick L Vinyard Jr <rvinyard at cs.nmsu.edu> - 0.4.90-2
- Excluded ppc and ppc64 arches

* Mon Nov  3 17:00:00 2008 Rick L Vinyard Jr <rvinyard at cs.nmsu.edu> - 0.4.90-1
- New release
- Add bit-gtkmm subpackages
- Added bit-gtkmm docs to gtk-doc
- Added glib2 dependency
- License change
- Expand -devel description
- Fix capitalization warning on brief description

* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.4.1-4
- Fix Patch0:/%patch mismatch.


blktrace-1.0.0-1.fc11
---------------------
* Sun Nov  2 17:00:00 2008 Eric Sandeen <sandeen at redhat.com> - 1.0.0-1
- New upstream version (now with actual versioning!)


bluez-4.19-1.fc11
-----------------
* Fri Nov 21 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 4.19-1
- Update to 4.19

* Mon Nov 17 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 4.18-1
- Update to 4.18


booty-0.107-1.fc11
------------------

bouml-4.8.3-1.fc11
------------------
* Sat Nov 22 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 #472408.
- Shortened summary to suit PackageKit's UI.


bouncycastle-1.41-2.fc11
------------------------
* Tue Nov 11 17:00:00 2008 Orcan Ogetbil <orcanbahri [AT] yahoo [DOT] com> 1.41-2
- Fixed license tag (BSD -> MIT).
- Minor improvements in the SPEC file for better compatibility with the 
  Fedora Java Packaging Guidelines.
- Added "Provides: bcprov == %{version}-%{release}".


brazil-2.3-3.fc11
-----------------

bug-buddy-2.25.1-1.fc11
-----------------------
* Wed Nov 12 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.25.1-1
- Update to 2.25.1


busybox-1.12.1-1.fc11
---------------------
* Mon Nov 10 17:00:00 2008 Ivana Varekova <varekova at redhat.com> - 1:1.12.1-1
- update to 1.12.1


bzr-1.9-1.fc11
--------------
* Thu Nov 13 17:00:00 2008 Toshio Kuratomi <toshio at fedoraproject.org> - 1.9-1
- Update to 1.9


bzrtools-1.9.1-1.fc11
---------------------
* Thu Nov 13 17:00:00 2008 Toshio Kuratomi <toshio at fedoraproject.org> 1.9.1-1
- Update to 1.9.1


cairo-dock-1.6.3.1-1.fc11
-------------------------
* Wed Nov 12 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.6.3.1-1
- 1.6.3.1

* Wed Nov  5 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.6.3-1
- 1.6.3

* Wed Oct 29 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.6.3-0.3.rc2
- 1.6.3 rc2


cheese-2.25.1-3.fc11
--------------------
* Thu Nov 13 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> 2.25.1-3
- Update to 2.25.1


chntpw-0.99.6-5.fc11
--------------------

cjkunifonts-0.2.20080216.1-9.2.fc11
-----------------------------------
* Wed Oct 29 18:00:00 2008 Caius Chance <cchance at redhat.com> - 0.2.20080216.1-9.2.fc11
- Resolves: rhbz#466667 (Reverted to 0.2.20080216.1-4 without conf.avail.)


claws-mail-3.6.1-1.fc11
-----------------------
* Fri Nov 21 17:00:00 2008 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 3.6.1-1
- version upgrade
- replace openssl by gnutls
- provide spell checking support via enchant


claws-mail-plugins-3.6.1-1.fc11
-------------------------------
* Fri Nov 21 17:00:00 2008 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 3.6.1-1
- version upgrade


clisp-2.47-1.fc11
-----------------
* Sat Nov 22 17:00:00 2008 Gerard Milmeister <gemi at bluewin.ch> - 2.47-1
- new release 2.47


cobbler-1.2.9-1.fc11
--------------------
* Fri Nov 14 17:00:00 2008 Michael DeHaan <mdehaan at redhat.com> - 1.3.0-1
- Upstream changes (see CHANGELOG)


collectl-3.1.1-1.fc11
---------------------
* Sat Nov  8 17:00:00 2008 Dan Horak <dan[at]danny.cz> 3.1.1-1
- upgrade to upstream version 3.1.1


compiz-0.7.8-3.fc11
-------------------
* Sat Nov  8 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> - 0.7.8-3
- Add obs plugin

* Sat Nov  8 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> - 0.7.8-2
- Fix sources file

* Sat Nov  8 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> - 0.7.8-1
- Update to 0.7.8
- Dropped patches:
	compiz-0.7.6-decoration-size.patch
	compiz-0.7.6-metacity-spacer.patch
	compiz-0.7.6-utility-windows.patch
	compiz-0.7.6-multi-screen-fix.patch


compiz-bcop-0.7.8-1.fc11
------------------------
* Sat Nov  8 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> 0.7.8-1
- Update to 0.7.8


compiz-fusion-0.7.8-3.fc11
--------------------------
* Sat Nov  8 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> 0.7.8-3
- BR intltool

* Sat Nov  8 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> 0.7.8-2
- Really remove patches

* Sat Nov  8 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> 0.7.8-1
- Update to 0.7.8
- Dropped patches now upstream


compiz-fusion-extras-0.7.8-3.fc11
---------------------------------
* Sat Nov  8 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> 0.7.8-3
- Add devel subpackage

* Sat Nov  8 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> 0.7.8-2
- BR intltool

* Sat Nov  8 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> 0.7.8-1
- Update to 0.7.8


conduit-0.3.15-2.fc11
---------------------
* Wed Nov 12 17:00:00 2008 Bernard Johnson <bjohnson at symetrix.com> - 0.3.15-2
- add intltool build dependency

* Wed Nov 12 17:00:00 2008 Bernard Johnson <bjohnson at symetrix.com> - 0.3.15-1
- v 0.3.15


control-center-2.25.1-5.fc11
----------------------------
* Thu Nov 13 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.1-5
- Update to 2.25.1


coreutils-7.0-3.fc11
--------------------
* Tue Nov 25 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> - 7.0-3
- package summary tuning

* Fri Nov 21 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> - 7.0-2
- added requirements for util-linux-ng >= 2.14
  because of file conflict in update from F-8/F-9(#472445)
- some sed cleanup, df totaltests patch changes (not working
  correctly yet :( )

* Wed Nov 12 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> - 7.0-1
- new upstream release
- modification/removal of related patches
- use automake 1.10.1 instead of 1.10a
- temporarily skip df --total tests (failures),
  timeout-paramaters (failure on ppc64)


cpqarrayd-2.3-7.fc11
--------------------
* Mon Nov 24 17:00:00 2008 David Juran <djuran at redhat.com> - 2.3-7
- Summary updated


cproto-4.7g-1.fc11
------------------
* Thu Nov 20 17:00:00 2008 Jindrich Novy <jnovy at redhat.com> 4.7g-1
- update to 4.7g


crack-5.0a-9.fc11
-----------------
* Tue Nov 25 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 5.0a-9
- rework spec file so that it meets FHS


cracklib-2.8.13-1
-----------------
* Tue Oct 28 18:00:00 2008 Nalin Dahyabhai <nalin at redhat.com> - 2.8.13-1
- update to 2.8.13, which overhauls the python bindings and revises
  FascistCheck()'s behavior:
  2.8.12 success: returns None, fail: returns error text, other: exceptions
  2.8.13 success: returns candidate, fail: throws ValueError, other: exceptions

* Tue Oct 28 18:00:00 2008 Nalin Dahyabhai <nalin at redhat.com> - 2.8.12-3
- fix errors rebuilding with libtool that's newer than the one upstream
  has (#467364)


cups-1.4-0.b1.3.fc11
--------------------
* Tue Nov 11 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 1:1.4-0.b1.3
- 1.4b1.
- No longer need ext, includeifexists, foomatic-recommended,
  getnameddest, str2101, str2536 patches.
- Require poppler-utils at runtime and for build.  No longer need
  pdftops.conf.
- Obsolete cupsddk.

* Thu Oct 30 18:00:00 2008 Tim Waugh <twaugh at redhat.com> 1:1.3.9-3
- Fixed LSPP labels (bug #468442).


cyphesis-0.5.17-1.fc11
----------------------
* Tue Nov  4 17:00:00 2008 Alexey Torkhov <atorkhov at gmail.com> 0.5.17-1
- Update to 0.5.17
- Add patch for libgcrypt proper initialisation
- Specify unix socket path in config without full path so cyphesis could
  be called by regular user. Instead of this, specify it in init script.
- Unit tests actually do the checks


daa2iso-0.1.7a-1.fc11
---------------------
* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 0.1.7a-1
- update to 0.1.7a


dahdi-tools-2.0.0-4.fc11
------------------------
* Thu Nov 20 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 2.0.0-4
- Fix zaptel-lib(s) conflicts

* Sat Oct 25 18:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 2.0.0-3
- Add conflicts/requires to help make sure that we get dahdi-tools-libs and not zaptel-libs

* Fri Oct 10 18:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 2.0.0-2
- Don't package sethdlc even if it gets built.


darcs-2.1.1-0.1.rc2.fc11
------------------------
* Tue Nov 11 17:00:00 2008 Jens Petersen <petersen at redhat.com> - 2.1.1-0.1.rc2
- update to 2.1.1rc2 which builds with ghc-6.10.1
- try to run all tests again


darkice-0.19-3.fc11
-------------------
* Wed Nov  5 17:00:00 2008 Clint Savage <herlo at fedoraproject.org> 0.19-3
- Fixed the licensing to GPLv2+


db4-4.7.25-6.fc11
-----------------
* Sun Nov 16 17:00:00 2008 Jindrich Novy <jnovy at redhat.com> 4.7.25-6
- package complete db4 documentation in db4-devel (#471633)
- add fix for the new libtool


dbus-glib-0.76-4.fc11
---------------------
* Tue Nov 25 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.76-4
- Avoid some spurious linkage


dbxml-2.4.16-0.1.fc11
---------------------
* Mon Nov 24 17:00:00 2008 Milan Zazrivec <mzazrivec at redhat.com> - 2.4.16-0.1
- Rebased to latest upstream version 2.4.16


decibel-audio-player-0.11-1.fc11
--------------------------------
* Fri Nov 14 17:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 0.11-1
- Version bump to 0.11. Closes Red Hat Bugzilla bug #464479.
- Replaced 'Requires: gnome-python2' with 'Requires: gnome-python2-gnome' on
  all distributions starting from Fedora 10.
- Added 'Requires: python-CDDB'.


dejavu-fonts-2.26-6.fc11
------------------------
* Sun Nov  9 17:00:00 2008 Nicolas Mailhot <nicolas.mailhot at laposte.net>
- 2.26-6
??? Package split reorganisation, following font family lines
??? Create compat packages to ease switchover at F11 time (to be discontinued
  for F12)
??? compress status file


deluge-1.0.5-1.fc11
-------------------
* Thu Nov 13 17:00:00 2008 Peter Gordon <peter at thecodergeek.com> - 1.0.5-1
- Update to new upstream release (1.0.5)

* Fri Oct 31 18:00:00 2008 Peter Gordon <peter at thecodergeek.com> - 1.0.4-1
- Update to new upstream release (1.0.4).


diveintopython-5.4-14.fc9
-------------------------
* Tue Nov  4 17:00:00 2008 Paul W. Frields <stickster at gmail.com> - 5.4-14
- Fix file location problem that breaks HTML version

* Tue Sep  2 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 5.4-13
- Include /usr/share/doc/diveintopython-5.4 directory (in all pkgs)


docbook-slides-3.4.0-5.fc11
---------------------------
* Fri Nov 21 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> - 3.4.0-5
- move tests subdir from tarball (sourceaudit check md5sum
  failure)
- license should be MIT


ds9-5.4-1.fc11
--------------
* Thu Nov 13 17:00:00 2008 Sergio Pascual <sergiopr at fedoraproject.org> - 5.4-1
- New upstream source


e2fsprogs-1.41.3-2.fc11
-----------------------

eclipse-3.4.1-7.fc11
--------------------
* Thu Nov 20 17:00:00 2008 Andrew Overholt <overholt at redhat.com> 3.4.1-7
- Update and re-enable patch for always generating debuginfo for class files
  when doing an RPM build.
- Resolves rh#472292.

* Mon Oct 27 18:00:00 2008 Andrew Overholt <overholt at redhat.com> 3.4.1-6
- Keep Provides: eclipse on -pde (different than Fedora 9 but probably
  more correct).


eclipse-epic-0.6.27-1.fc11
--------------------------
* Sat Nov 15 17:00:00 2008 Mat Booth <fedora at matbooth.co.uk> 0.6.27-1
- Updated to verion 0.6.27.
- Add perl-Module-Starter dependency.
- Fixes shift left works inconsistently (#2059660).
- Fixes global variables can not be displayed (#2188379).
- New features: Display package-scope variables in debugger and enable
  variable substitution for Perl executable in prefs.


eclipse-gef-3.4.1-1.fc11
------------------------
* Thu Nov 20 17:00:00 2008 Mat Booth <fedora at matbooth.co.uk> 3.4.1-1
- New maintainer.
- Updated to verion 3.4.1.
- Update package for new Eclipse plugin guidelines.
- Own the gcj/%{name} directory.
- The 'examples.ui.pde' plugin is actually part of the SDK feature.

* Thu Jul 17 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 3.3.0-3
- fix license tag


eclipse-mylyn-3.0.3-4.fc11
--------------------------
* Wed Nov 12 17:00:00 2008 Andrew Overholt <overholt at redhat.com> 3.0.3-4
- Add patch for e.o#239435 (rhbz#470356).


eclipse-phpeclipse-1.2.1-2.fc11
-------------------------------
* Sun Nov 16 17:00:00 2008 Mat Booth <fedora at matbooth.co.uk> 1.2.1-2
- Add php-pecl-xdebug dependency.

* Fri Nov 14 17:00:00 2008 Mat Booth <fedora at matbooth.co.uk> 1.2.1-1
- Update to 1.2.1 and rebase patches.
- Fixes mark occurances bug in Eclipse 3.4 (#706).
- Fix NPE on shutdown if external tools are not used.


eel2-2.24.1-7.fc11
------------------
* Tue Nov 25 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.24.1-7
- Reduce unneeded direct libary deps

* Fri Nov 21 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.24.1-6
- Tweak descriptions

* Thu Nov 13 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.24.1-5
- Rebuild against new gnome-desktop


ekiga-3.0.1-4.fc11
------------------

elice-0.323-1.fc11
------------------
* Mon Nov 24 17:00:00 2008 Hans de Goede <j.w.r.degoede at hhs.nl> 0.323-1
- New upstream release 0.323


emacs-22.3-1.fc11
-----------------
* Sat Nov  8 17:00:00 2008 Jens Petersen <petersen at redhat.com> - 1:22.3-1
- update to 22.3 (#461448)
- emacs-22.1.50-sparc64.patch and emacs-22.1.50-regex.patch no longer needed
- update rpm-spec-mode.el to look for fields at bol (#466407)


emacs-bbdb-2.35-1.fc11
----------------------
* Sun Nov  9 17:00:00 2008 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 1:2.35-1
- Revert to 2.35 release in order to address BZ 467909 and 467911
- Add bbdb-2.35-fix_lisp_makefile.patch in order to fix build problems
- Add epoch to avoid problems with package updating

* Thu Nov  6 17:00:00 2008 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 2.36-0.1.20080928cvs
- Rename snapshot to reflect the fact that it is a 2.36 pre-release rather than
  a post 2.35 snapshot
- Fix day of previous spec file changelog entry
- Added a patch to revert upstream SVN revision 106 (which is suitable for
  emacs>=23) (BZ 467909)

* Mon Sep 29 18:00:00 2008 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 2.35-9.20080928cvs
- Update to current CVS snapshot, fixing several bugs
- Ensure that bbdb-vm.elc is built and installed (BZ 462875)
- Add --enable-developer to configure for more verbose build info


emacs-vm-8.0.12-2.fc11
----------------------
* Wed Nov 19 17:00:00 2008 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 8.0.12-2
- Re-add u-vm-color.el to lisp/Makefile.in
- Fix spec file typo in install command that installs the uncompiled lisp files

* Fri Nov  7 17:00:00 2008 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 8.0.12-1
- Update to version 8.0.12
- Remove u-vm-color.el (now included with upstream VM)
- Remove hack to add vm-revno.el to lisp files
- Drop devo number stuff, since upstream seems to have stopped using the
  revision number in the release tarball name (finally!)


ember-0.5.4-4.fc11
------------------
* Tue Nov  4 17:00:00 2008 Alexey Torkhov <atorkhov at gmail.com> 0.5.4-4
- Rebuild for new OGRE
- Including lost entityrecipes and sounddefinitions to media
- Running unit checks during build

* Thu Oct 23 18:00:00 2008 Alexey Torkhov <atorkhov at gmail.com> 0.5.4-3
- Workaround of crash in Caelum with new OGRE


ember-media-0.5.4-4
-------------------
* Mon Nov  3 17:00:00 2008 Alexey Torkhov <atorkhov at gmail.com> 0.5.4-4
- Including license text in documentation
- Fixing materials to be loadable by new OGRE


eog-2.25.1-3.fc11
-----------------
* Wed Nov 12 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.1-3
- Update to 2.25.1


epic-2.10-1.fc11
----------------
* Tue Nov 25 17:00:00 2008 Vitezslav Crhonek <vcrhonek at redhat.com> - 4:2.10-1
- Update to upstream epic4-2.10


epiphany-2.24.1-3.fc11
----------------------
* Thu Nov 13 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.1-3
- Rebuild against newer gecko

* Thu Nov 13 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.1-2
- Rebuild


eric-4.2.3-1.fc11
-----------------
* Wed Nov 19 17:00:00 2008 Johan Cwiklinski <johan AT x-tnd DOT be> 4.2.3-1
- 4.2.3


esmtp-1.0-2.fc11
----------------
* Mon Nov 24 17:00:00 2008 Patrice Dumas <pertusus at free.fr> 1.0-2
- update to 1.0
- add a subpackage with local delivery enabled and dependency on procmail


eterm-0.9.5-2.fc11
------------------
* Mon Nov 10 17:00:00 2008 Terje R??sten <terje.rosten at ntnu.no> - 0.9.5-2
- Add patch to remove KDE cut-paste patch


etherboot-5.4.4-4.fc11
----------------------

evince-2.25.1-3.fc11
--------------------
* Tue Nov 11 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.25.1-3
- Update to 2.25.1


evolution-2.25.1-2.fc11
-----------------------
* Thu Nov 20 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.25.1-2.fc11
- Fix a typo (RH bug #472358).

* Mon Nov  3 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.25.1-1.fc11
- Update to 2.25.1
- Bump evo_major to 2.26.
- Bump eds_version to 2.25.1.


evolution-data-server-2.25.1-1.fc11
-----------------------------------
* Mon Nov  3 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.25.1-1.fc11
- Update to 2.25.1
- Bump eds_base_version to 2.26.
- Remove patch for RH bug #467804 (fixed upstream).


evolution-exchange-2.25.1-1.fc11
--------------------------------
* Mon Nov  3 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.25.1-1.fc11
- Update to 2.25.1
- Bump evo_major to 2.26.
- Bump evo_version and eds_version to 2.25.1.


evolution-rss-0.1.2-2.fc11
--------------------------
* Wed Nov 19 17:00:00 2008 Lucian Langa <cooly at gnome.eu.org> - 0.1.2-2
- add intltool as buildrequires

* Wed Nov 19 17:00:00 2008 Lucian Langa <cooly at gnome.eu.org> - 0.1.2-1
- new upstream 0.1.2


expendable-0.0.7-1.fc11
-----------------------
* Tue Nov 11 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 0.0.7-1
- 0.0.7.


fbterm-1.2-1.fc11
-----------------
* Fri Nov 21 17:00:00 2008 Ding-Yi Chen <dchen at redhat dot com> - 1.2-1
- Upstream update, see 
 http://code.google.com/p/fbterm/
 for details.


fedora-release-10.90-1
----------------------

file-browser-applet-0.6.0-1.fc11
--------------------------------
* Thu Nov 20 17:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 0.6.0-1
- New upstream version


filezilla-3.1.5.1-1.fc11
------------------------
* Tue Nov 18 17:00:00 2008 kwizart < kwizart at gmail.com > - 3.1.5.1-1
- Update to 3.1.5.1


fio-1.23-1.fc11
---------------
* Thu Nov 20 17:00:00 2008 Eric Sandeen <sandeen at redhat.com> 1.23-1
- New upstream version, several bugs fixed.


flam3-2.7.17-1.fc11
-------------------
* Sun Nov 16 17:00:00 2008 Ian Weller <ianweller at gmail.com> 2.7.17-1
- Upstream updated:
    Add error checking on the numbers in the input genome.  Do
    not exit on read errors, fail gracefully. Changed sin/cos = tan in
    the tangent variation. Added polar to list of variations that use
    the inverted linear identity. Bugfix: temporal_filter_exp was not
    set properly in template. Apply interpolation attribute in
    templates. Add/publish datarootdir with pkg-config so the palette
    file is easy to find (for qosmic). Copyright by Spotworks LLC
    instead of Spot and Erik.  Add fuzz checks to the regression
    suite.  include LNX/OSX/WIN in the version string.  In
    flam3-genome animate command, added one to last flame time, so the
    end time is inclusive.  Release as 2.7.17.


fontforge-20080927-1.fc11
-------------------------
* Sat Nov  8 17:00:00 2008 Nicolas Mailhot <nicolas.mailhot at laposte.net>
- 20080927-1
??? quick & dirty version bump to start working on F11 font packages
??? time to forget about pfaedit
??? take care of rpmlint warnings


fotoxx-5.6-1.fc11
-----------------
* Sun Nov 16 17:00:00 2008 Nicoleau Fabien <nicoleau.fabien at gmail.com> - 5.6-1
- Rebuild for 5.6

* Tue Nov  4 17:00:00 2008 Nicoleau Fabien <nicoleau.fabien at gmail.com> - 5.5-1
- Rebuild for 5.5


freecol-0.7.4-3.fc11
--------------------
* Mon Nov 24 17:00:00 2008 Hans de Goede <j.w.r.degoede at hhs.nl> 0.7.4-3
- Fixup Summary


freetalk-3.2-1.fc11
-------------------
* Fri Nov 21 17:00:00 2008 Matej Cepl <mcepl at redhat.com> 3.2-1
- Update to the new upstream release.


fwbuilder-3.0.1-1.fc11
----------------------
* Wed Nov 19 17:00:00 2008 Ralf Ertzinger <ralf at skytale.net> 3.0.1-1
- Update to 3.0.1


fwknop-1.9.9-1
--------------
* Mon Nov 17 17:00:00 2008 Miloslav Trma?? <mitr at redhat.com> - 1.9.9-1
- Update to fwknop-1.9.9


gajim-0.11.4-6.fc11
-------------------

gamin-0.1.10-1.fc11
-------------------
* Mon Nov 24 17:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> - 0.1.10-1
- Update to 0.1.10
- Drop upstreamed patches


ganyremote-5.4.1-1.fc11
-----------------------
* Wed Nov 12 17:00:00 2008 Mikhail Fedotov <anyremote at mail.ru> - 5.4.1-1
- Small corrections


gawk-3.1.6-1.fc11
-----------------
* Tue Nov 25 17:00:00 2008 Stepan Kasal <skasal at redhat.com> - 3.1.6-1
- new upstream version
- drop Patch1: gawk-3.1.3-getpgrp_void.patch, it seems to be a workaround
  for a bug in gcc that seemed to exist at Fedora Core 1 times, see #114246
- drop patches 2-13, they have been integrated upstream


gbrainy-1.00-3.fc11
-------------------
* Sat Nov 22 17:00:00 2008 Beno??t Marcelin <sereinity at online.fr> 1.00-3
- Fix Summary


gcalctool-5.25.1-2.fc11
-----------------------
* Wed Nov 12 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 5.25.1-2
- Update to 5.25.1


gcompris-8.4.8-1.fc11
---------------------

gdb-6.8-29.fc11
---------------

gdesklets-0.36.1-1.fc11
-----------------------
* Thu Nov 20 17:00:00 2008 Luya Tshimbalanga <luya at fedoraproject.org> - 0.36.1-1
- Updated from upstream
- Removed autogenerated-mime data for integrating check
  courtesy of Christian Krause (chkr at plauener.de)


geda-docs-20080929-1.fc11
-------------------------
* Tue Nov 11 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20080929-1
- New upstream release


geda-examples-20080929-1.fc11
-----------------------------
* Tue Nov 11 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20080929-1
- New upstream release


geda-gattrib-20080929-1.fc11
----------------------------
* Tue Nov 11 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20080929-1
- New upstream release


geda-gnetlist-20080929-2.fc11
-----------------------------
* Tue Nov 18 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20080929-2
- Security bug patched:  Bug 472114 - CVE-2008-5148 geda-gnetlist insecure temporary file use

* Tue Nov 11 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20080929-1
- New upstream release


geda-gschem-20080929-1.fc11
---------------------------
* Tue Nov 11 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20080929-1
- New upstream release


geda-gsymcheck-20080929-1.fc11
------------------------------
* Tue Nov 11 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20080929-1
- New upstream release


geda-symbols-20080929-1.fc11
----------------------------
* Tue Nov 11 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20080929-1
- New upstream release


geda-utils-20080929-1.fc11
--------------------------
* Tue Nov 11 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20080929-1
- New upstream release


generic-release-10.90-1
-----------------------
* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 10.90-1
- 10.90

* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 10-1
- Bump to 10, update repos


geoclue-0.11.1-13.fc11
----------------------
* Sat Nov 22 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> 0.11.1-13
- Fix summary


geoqo-0.99-1.fc11
-----------------
* Wed Nov 19 17:00:00 2008 Wes Hardaker <wjhns174 at hardakers.net> - 0.99-1
- Update to version 0.99


gerbv-2.1.0-2.fc11
------------------
* Thu Nov 13 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 2.1.0-2
- BR ImageMagick-devel added

* Thu Nov 13 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 2.1.0-1
- New upstream release and split into -devel package


getdata-0.4.2-1.fc11
--------------------
* Tue Nov 18 17:00:00 2008 Matthew Truch <matt at truch.net> - 0.4.2-1
- Upstream 0.4.2.
-   Includes several bugfixes, especially to the legacy interface.

* Sat Nov  1 18:00:00 2008 Matthew Truch <matt at truch.net> - 0.4.0-1
- Upstream 0.4.0.


getmail-4.8.4-1.fc11
--------------------
* Mon Nov 10 17:00:00 2008 <knolderpoor at gmail.com> - 4.8.4-1
- Update to release 4.8.4


gforth-0.7.0-1.fc9
------------------
* Wed Nov  5 17:00:00 2008 Gerard Milmeister <gemi at bluewin.ch> - 0.7.0-1
- new release 0.7.0


ghc-6.10.1-5.fc11
-----------------
* Tue Nov 25 17:00:00 2008 Jens Petersen <petersen at redhat.com> - 6.10.1-5
- add cabal2spec and template files for easy cabal hackage packaging
- simplify script macros: make ghc_preinst_script and ghc_postun_script no-ops
  and ghc_preun_script only unregister for uninstall

* Tue Nov 11 17:00:00 2008 Jens Petersen <petersen at redhat.com> - 6.10.1-4
- fix broken urls to haddock docs created by gen_contents_index script
- avoid haddock errors when upgrading by making doc post script posttrans

* Wed Nov  5 17:00:00 2008 Bryan O'Sullivan <bos at serpentine.com> - 6.10.1-3
- libraries/prologue.txt should not have been ghosted

* Tue Nov  4 17:00:00 2008 Bryan O'Sullivan <bos at serpentine.com> - 6.10.1-2
- Fix a minor packaging glitch

* Tue Nov  4 17:00:00 2008 Bryan O'Sullivan <bos at serpentine.com> - 6.10.1-1
- Update to 6.10.1 in observance of President Obama


gimmix-0.5.2-1.fc11
-------------------
* Sun Nov 23 17:00:00 2008 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.5.2-1
- version upgrade
- build against libnxml


gimp-2.6.3-1.fc11
-----------------
* Mon Nov 24 17:00:00 2008 Nils Philippsen <nils at redhat.com> - 2:2.6.3-1
- version 2.6.3

  Overview of Changes from GIMP 2.6.2 to GIMP 2.6.3
  =================================================

  * Bugs fixed:

   558454 ??? Plugin Map Color Range disappears from GIMP
   559239 ??? Error while loading psd-data
   560903 ??? Explicit zooming with e.g. '1' should handle
            zoom-focus better
   560245 ??? Zoom selection always centered in the Navigation tab
   559490 ??? Wrong lang tags for 'no'
   559292 ??? SOTA Chrome cannot accept different textures
   560375 ??? Clearing an already empty document history crashes GIMP
   559580 ??? Image windows need better default locations
   560283 ??? "Scale image..." causes distortion around edges
   559716 ??? Changing crop size in Crop Tool Options can make UI
            unresponsive
   558549 ??? Stroking a single-point path with a paint tool
            crashes GIMP
   559015 ??? Move tool gives bad information about px moved
   558660 ??? help behavior for locales without manual translation

  * Updated translations:

   Belarusian (be)
   Dutch (nl)
   German (de)
   Japanese (ja)
   Lithuanian (lt)
   Norwegian Bokm??l (nb)
   Norwegian Nynorsk (nn)
   Polish (pl)
   Romanian (ro)

* Fri Nov 14 17:00:00 2008 Nils Philippsen <nils at redhat.com> - 2:2.6.2-3
- bump release

* Tue Nov 11 17:00:00 2008 Nils Philippsen <nils at redhat.com> - 2:2.6.2-2
- backport: use size units in JPEG save preview (#469551)


git-1.6.0.4-1.fc11
------------------
* Fri Nov 14 17:00:00 2008 Josh Boyer <jwboyer at gmail.com> 1.6.0.4-1
- git-1.6.0.4


gjots2-2.3.8-1.fc11
-------------------
* Fri Nov  7 17:00:00 2008 Radek Vok??l <rvokal at redhat.com> 2.3.8-1
- update to 2.3.8
- fix for gpg encrypted file handling  (#464476)
- fixed vulnerability when processing a gpg password  (#464510)


glew-1.5.1-1.fc11
-----------------
* Thu Nov 13 17:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> - 1.5.1-1
- New upstream release (#469639)
- Fix licenseing issue with developer documentation


glibc-2.8.90-17
---------------

global-5.7.3-1.fc11
-------------------
* Fri Nov 21 17:00:00 2008 Gerard Milmeister <gemi at bluewin.ch> - 5.7.3-1
- new release 5.7.3


gmp-4.2.4-1.fc11
----------------
* Mon Nov 10 17:00:00 2008 Ivana Varekova <varekova at redhat.com> 4.2.4-1
- update to 4.2.4

* Fri Nov  7 17:00:00 2008 Ivana Varekova <varekova at redhat.com> 4.2.2-9
- remove useless patch (#470200)


gnash-0.8.4-5.fc11
------------------
* Thu Nov 13 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.8.4-5
- add missing portions of KDE 4 port from upstream kde4 branch

* Thu Nov 13 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.8.4-4
- add 3 more patches from bero to fix the KDE 4 viewer executable
- disable use_kde3_executable hack


gnome-applet-sensors-2.2.1-1.fc11
---------------------------------
* Mon Nov  3 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 2.2.1-1
- New upstream release 2.2.1
- Update license tag to include icons license


gnome-applets-2.25.1-3.fc11
---------------------------
* Fri Nov 21 17:00:00 2008 Ray Strode <rstrode at redhat.com> - 1:2.25.1-3
- Install modemlights schema (bug 417031)

* Thu Nov 13 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.25.1-2
- Rebuild

* Wed Nov 12 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.25.1-1
- Update to 2.25.1


gnome-chemistry-utils-0.10.1-1.fc11
-----------------------------------
* Sat Nov 15 17:00:00 2008 Julian Sikorski <belegdol[at]gmail[dot]com> - 0.10.1-1
- Updated to 0.10.1


gnome-commander-1.2.8-0.1.svn2274_trunk.fc11
--------------------------------------------
* Thu Nov 13 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2274

* Mon Oct 20 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- 1.2.8 branch
- rev 2221


gnome-desktop-2.25.1.1-4.fc11
-----------------------------
* Thu Nov 13 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.1.1-4
- Install gnome-bg-crossfade.h

* Thu Nov 13 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.1.1-3
- Update to 2.25.1.1


gnome-games-2.25.1-2.fc11
-------------------------
* Thu Nov 13 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.25.1-2
- Update to 2.25.1


gnome-hearts-0.3-1.fc11
-----------------------
* Fri Nov  7 17:00:00 2008 Christopher Aillon <caillon at redhat.com> - 0.3-1
- Update to 0.3


gnome-keyring-2.25.1-1.fc11
---------------------------
* Mon Nov 10 17:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> - 2.25.1-1
- Update to 2.25.1


gnome-libs-1.4.2-11.fc11
------------------------
* Thu Nov 20 17:00:00 2008 Paul Howarth <paul at city-fan.org> 1:1.4.2-11
- Specify Instruction Set Architecture (%{?_isa}) in devel package requires
  (where available)
- BerkeleyDB source moved to download.oracle.com


gnome-mag-0.15.4-4.fc11
-----------------------
* Sun Nov 23 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.15.4-4
- Remove an unnecessary dependency

* Sun Nov 23 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.15.4-2
- Tweak description


gnome-packagekit-0.3.11-1.fc11
------------------------------
* Mon Nov 24 17:00:00 2008 Richard Hughes <rhughes at redhat.com> - 0.3.11-1
- New upstream version

* Tue Nov 11 17:00:00 2008 Richard Hughes <rhughes at redhat.com> - 0.3.10-1
- New upstream version
- Drop all upstreamed patches


gnome-panel-2.24.1-6.fc11
-------------------------
* Thu Nov 13 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.1-6
- Rebuild

* Sun Nov  9 17:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.1-4
- Don't unhide drawers by default.  Patch from
  Leszek Matok <lam at lac.pl> (bug 470719)


gnome-password-generator-1.6-2.fc11
-----------------------------------
* Fri Nov  7 17:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 1.6-2
- Replaced 'Requires: gnome-python2' with 'Requires: gnome-python2-gnome' on
  all distributions starting from Fedora 10. Closes Red Hat Bugzilla bug
  - Trimmed the 'Requires' list.


gnome-power-manager-2.24.2-2.fc11
---------------------------------
* Tue Nov 18 17:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 2.24.2-2
- Update to 2.24.2
- Duplicate button presses should now be detected
- Drop upstreamed patches


gnome-python2-desktop-2.24.0-4.fc11
-----------------------------------
* Fri Nov 14 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.24.0-4.fc11
- Update subpackage requirements, since gnome-python2 no longer drags in
  the world.

* Thu Nov 13 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0-3
- Rebuild

* Sun Sep 21 18:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.24.0-2.fc10
- Change gnome-python2 requirement to gnome-python2-canvas.

* Sun Sep 21 18:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.24.0-1.fc10
- Update to 2.24.0

* Sun Aug 31 18:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.23.1-1.fc10
- Update to 2.23.1
- Update version requirements.


gnome-screensaver-2.24.1-2.fc11
-------------------------------
* Mon Nov 24 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.1-2
- Update to 2.24.1

* Thu Nov 13 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0-4
- Rebuild


gnome-session-2.24.1-4.fc11
---------------------------
* Mon Nov 10 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.24.1-4
- Fix client registration in some cases


gnome-settings-daemon-2.25.1-4.fc11
-----------------------------------
* Thu Nov 13 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.1-4
- Rebuild

* Wed Nov 12 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.1-2
- Update to 2.25.1


gnome-terminal-2.24.2-2.fc11
----------------------------
* Tue Nov 25 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.2-2
- Update to 2.24.2

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

* Thu Nov 20 17:00:00 2008 Behdad Esfahbod <besfahbo at redhat.com> - 2.24.1-3
- Require vte >= 0.17.0
- Resolves: #472330


gnome-themes-2.25.1-2.fc11
--------------------------
* Wed Nov 12 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.1-2
- Update to 2.25.1


gnome-utils-2.24.1-2.fc11
-------------------------
* Thu Nov 13 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.24.1-2
- Rebuild


gnomesword-2.4.1-1.fc11
-----------------------
* Thu Nov 20 17:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 2.4.1-1
- Update to 2.4.1


gnomint-0.5.4-2.fc11
--------------------

gnuplot-4.2.4-1.fc11
--------------------
* Fri Nov  7 17:00:00 2008 Ivana Varekova <varekova at redhat.com> - 4.2.4-1
- update to 4.2.4


gnutls-2.4.2-3.fc11
-------------------
* Tue Nov 11 17:00:00 2008 Tomas Mraz <tmraz at redhat.com> 2.4.2-3
- fix chain verification issue CVE-2008-4989 (#470079)


gob2-2.0.15-3.fc11
------------------
* Mon Nov 24 17:00:00 2008 Daniel Novotny <dnovotny at redhat.com> - 2.0.15-3
- summary fix


gok-2.25.1-1.fc11
-----------------
* Wed Nov 12 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.1-1
- Update to 2.25.1


google-gadgets-0.10.3-1.fc11
----------------------------
* Sun Nov 23 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 0.10.3-1
- Update to 0.10.3


gramps-3.0.3-0.fc11
-------------------
* Thu Nov 20 17:00:00 2008 Russell Harrison <rharrison at fedoraproject.org> - 3.0.3-0
- Update to 3.0.3.
- Changed build arguments to "--enable-packager-mode" from "--disable-schemas-install --disable-scrollkeeper --disable-mime-install".
- Removed scrollkeeper commands and dependencies.
- Removed GCONF schema commands as schema files are no longer created by the build. pre and preun sections are no longer needed.
- Help files are now stored on the gramps wiki instead of created durring the build.
- Changed gnome-python2 dependency to gnome-python2-gnome for F10 and above per bug #460006
- Included a patch to allow gramps to work with BerkeleyDB 4.7 in F10


graphviz-2.20.3-1.fc11
----------------------
* Mon Nov 24 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 2.20.3-1
- update to 2.20.3

* Sat Nov 22 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 2.16.1-0.7
- respin (libtool)


grep-2.5.3-1.fc11
-----------------
* Thu Nov 20 17:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> 2.5.3-1
- Update to latest upstream version
- Drop upstreamed patches
- Add a couple of regression tests
- Temporarily disable tests
- Minor cleanup


gridengine-6.2-5.fc11
---------------------
* Mon Nov 17 17:00:00 2008 - Orion Poplawski <orion at cora.nwra.com> - 6.2-5
- Leave qmake-ge in /usr/bin
- Use system db_* utils in bdb_checkpoint script
- Fix xterm path in default setup
- Change java BR to >= 1.6.0 to allow building with other 1.6 javas


grip-3.2.0-25.fc11
------------------
* Mon Nov 10 17:00:00 2008 Adrian Reber <adrian at lisas.de> - 1:3.2.0-25
- fixed "grip breaks utf-8 sequences up when writing xmcd CD database file"
  (#466656)

* Sun Nov  9 17:00:00 2008 Adrian Reber <adrian at lisas.de> - 1:3.2.0-24
- fixed "buffer overflow caused by large amount of CDDB replies" (#470552)
  (CVE-2005-0706)


gromacs-4.0.2-6.fc11
--------------------
* Mon Nov 10 17:00:00 2008 Jussi Lehtola - 4.0.2-6
- Update to 4.0.2.

* Sun Nov  9 17:00:00 2008 Jussi Lehtola - 4.0.1-5
- Add Requires: blas too.

* Sun Nov  9 17:00:00 2008 Jussi Lehtola - 4.0.1-4
- Update to 4.0.1.
- Add Requires: lapack and openmpi to prevent yum from pulling atlas and lam
instead.


gspiceui-0.9.65-3.fc11
----------------------

gssdp-0.6.3-2.fc11
------------------
* Sat Nov 22 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> 0.6.3-2
- Fix summary


gstreamer-0.10.21-2.fc11
------------------------

gtk-doc-1.11-2.fc11
-------------------
* Fri Nov 21 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1.11-2
- Update to 1.11


gtk-sharp2-2.12.5-1.fc11
------------------------
* Sat Nov  8 17:00:00 2008 Xavier Lamien <lxtnow[at]gmail.com> - 2.12.5-1
- Update release.


gtk2-2.14.5-3.fc11
------------------
* Mon Nov 24 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.14.5-3
- Update to 2.14.5
- Drop obsolete patches
- Update descriptions

* Sun Nov 23 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.14.4-4
- Reduce rpmlint warnings produced by the ia64 multilib hack
- Fight unnecessary library dependencies


gtk2-engines-2.17.0-1.fc11
--------------------------
* Wed Nov 12 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.17.0-1
- Update to 2.17.0


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


gtksourceview-sharp-2.0.12-7.fc11
---------------------------------
* Wed Nov 19 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2.0-0.12-7
- fix broken urls


gtksourceview2-2.4.1-1.fc11
---------------------------
* Wed Nov 12 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.4.1-1
- Update to 2.4.1


gtorrentviewer-0.2b-16.fc11
---------------------------
* Thu Nov 20 17:00:00 2008 Paul Howarth <paul at city-fan.org> 0.2b-16
- Use downloads.sf.net rather than dl.sf.net for source URL


guile-1.8.5-2.fc11
------------------
* Wed Nov 19 17:00:00 2008 Miroslav Lichvar <mlichvar at redhat.com> - 5:1.8.5-2
- fix building with new libtool


gupnp-0.12.4-2.fc11
-------------------
* Sat Nov 22 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> 0.12.4-2
- Fix summary

* Mon Nov 17 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> 0.12.4-1
- New upstream release


gupnp-av-0.2.1-5.fc11
---------------------
* Sat Nov 22 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> 0.2.1-5
- Update package summary


gupnp-tools-0.7-3.fc11
----------------------
* Sat Nov 22 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> 0.7-3
- Fix package summary

* Tue Oct 28 18:00:00 2008 Peter Robinson <pbrobinson at gmail.com> 0.7-2
- Add missing files

* Tue Oct 28 18:00:00 2008 Peter Robinson <pbrobinson at gmail.com> 0.7-1
- New upstream release


gutenprint-5.2.2-1.fc11
-----------------------
* Thu Nov 20 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 5.2.2-1
- 5.2.2.
- Restore SELinux file contexts of modified PPDs.

* Mon Aug  4 18:00:00 2008 Tim Waugh <twaugh at redhat.com>
- Fixed summary for foomatic sub-package.


gwibber-0.7.1-1.134bzr.fc11
---------------------------
* Sun Nov 16 17:00:00 2008 Ian Weller <ianweller at gmail.com> 0.7.1-1.134bzr
- Update upstream
- Remove patch from J. Katz, fixed upstream


gxemul-0.4.6.6-1.fc11
---------------------
* Tue Nov 18 17:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> - 0.4.6.6-1
- update to 0.4.6.6


gyachi-1.1.59-5.fc11
--------------------
* Tue Nov 25 17:00:00 2008 Gregory D Hosler <ghosler at users.sourceforge.net> - 1.1.59.5
- Upstream updates. Added gtkspell spellchecker.

* Sat Nov 22 17:00:00 2008 Gregory D Hosler <ghosler at users.sourceforge.net> - 1.1.58.5
- Upstream updates - added a [Revert] button to webcam upload, to revert cam
- settings to saved rc settings.

* Fri Nov 21 17:00:00 2008 Gregory D Hosler <ghosler at users.sourceforge.net> - 1.1.57.5
- Upstream updates - better support of webcam features.

* Fri Nov 21 17:00:00 2008 Gregory D Hosler <ghosler at users.sourceforge.net> - 1.1.56-5
- Upstream updates - webcam viewer/uploader fix for segfault. Cache "custom
- away message" between runs, convert the systray icon to a GtkStatusIcon

* Wed Nov 19 17:00:00 2008 Gregory D Hosler <ghosler at users.sourceforge.net> - 1.1.55-5
- Upstream fix for Y15 login seg fault.

* Wed Nov 19 17:00:00 2008 Gregory D Hosler <ghosler at users.sourceforge.net> - 1.1.53-14
- obsoleted photo_album plugin.

* Mon Nov 17 17:00:00 2008 Gregory D Hosler <ghosler at users.sourceforge.net> - 1.1.53-10
- updated from upstream.

* Thu Nov  6 17:00:00 2008 Gregory D Hosler <ghosler at users.sourceforge.net> - 1.1.50-10
- updated from upstream.


gypsy-0.6-5.fc11
----------------
* Sat Nov 22 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> 0.6-5
- Rebuild


hal-info-20081022-2.fc11
------------------------
* Wed Nov 12 17:00:00 2008 Richard Hughes <rhughes at redhat.com> - 20081022-2
- Add a OLPC keymap file, based from one by Ignacio Vazquez-Abrams.


hamcrest-1.1-7.1.fc11
---------------------
* Mon Nov 24 17:00:00 2008 David Walluck <dwalluck at redhat.com> 0:1.1-7.1
- Fedora-specific: enable GCJ support
- Fedora-specific: build with java 1.6.0
- Fedora-specific: disable integration and tests

* Mon Nov 24 17:00:00 2008 David Walluck <dwalluck at redhat.com> 0:1.1-7
- update summary and description


happy-1.18.2-1.fc11
-------------------
* Wed Nov 12 17:00:00 2008 Jens Petersen <petersen at redhat.com> - 1.18.2-1
- update to 1.18.2 release from hackage
- update to new packaging macros
- turn off debuginfo


haproxy-1.3.15.6-2.fc11
-----------------------
* Sat Nov 22 17:00:00 2008 Jeremy Hinegardner <jeremy at hinegardner dot org> - 1.3.15.6-2
- apply upstream patches

* Sat Nov 15 17:00:00 2008 Jeremy Hinegardner <jeremy at hinegardner dot org> - 1.3.15.6-1
- update to 1.3.15.6
- use new build targets from upstream
- add in recommended build options for x86 from upstream


hdhomerun-0.0-0.8.20081002.fc11
-------------------------------
* Thu Nov 20 17:00:00 2008 Jarod Wilson <jarod at redhat.com> 0.0-0.8.20081002
- Update to 20081002 release

* Tue Aug 19 18:00:00 2008 Jarod Wilson <jarod at redhat.com> 0.0-0.7.20080727
- Update to 20080727 release


homebank-4.0-1.fc11
-------------------
* Mon Nov 24 17:00:00 2008 Johan Cwiklinski <johan AT x-tnd DOT be> 4.0-1
- 4.0


html-xml-utils-3.7-7.fc11
-------------------------
* Fri Nov 21 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 3.7-7
- Add explicit "Conflicts: surfraw" (#208781).
  Add explicit "Conflicts: normalize" (#208781). 
  Both are fixed in upstream releases >= 5.0 (!)


htop-0.8.1-2.fc11
-----------------
* Tue Nov 18 17:00:00 2008 Rafa?? Psota <rafalzaq at gmail.com> - 0.8.1-2
- non-printable character filter patch (#504144)


hunspell-1.2.8-3.fc11
---------------------
* Sun Nov 23 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 1.2.8-3
- tweak summary

* Wed Nov 19 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 1.2.8-2
- Resolves: rhbz#471085 in ispell compatible mode (-a), ignore
  -m option which means something different to ispell

* Sun Nov  2 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 1.2.8-1
- latest version


hunspell-af-0.20060117-3.fc11
-----------------------------
* Thu Nov 20 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20060117-3
- mysteriously upstream tarball of same version has extra words in it
  than our cached one

* Fri Aug  3 18:00:00 2007 Caolan McNamara <caolanm at redhat.com> - 0.20060117-2
- clarify license version


hunspell-da-1.7.26-1.fc11
-------------------------
* Sun Nov 23 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 1.7.26-1
- latest version


hunspell-en-0.20081124-1.fc11
-----------------------------
* Tue Nov 25 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20081124-1
- latest version, i.e +Barack +Obama and co.


hunspell-fo-0.2.35-1.fc11
-------------------------
* Sun Nov 23 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.2.35-1
- latest version


hunspell-hu-1.4-1.fc11
----------------------
* Sun Nov 23 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 1.4-1
- latest version


hunspell-nr-0.20060120-2.fc11
-----------------------------
* Thu Nov 20 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20060120-2
- mysteriously, upstream tarball no longer matches our tarball


hunspell-pt-0.20081113-1.fc11
-----------------------------
* Sun Nov 23 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20081113-1
- latest pt_PT version


hyphen-hu-0.20081106-1.fc11
---------------------------
* Sun Nov  9 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20081106-1
- latest version


ibus-0.1.1.20081023-2.fc11
--------------------------
* Wed Nov 19 17:00:00 2008 Huang Peng <shawn.p.huang at gmail.com> - 0.1.1.20081023-2
- Move libibus-gtk.so from ibus.rpm to ibus-gtk.rpm to fix bug 472146.


icu-4.0-4.fc11
--------------
* Thu Nov 20 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 4.0-4
- annoyingly upstream tarball was repacked apparently to remove 
  some unused/cached dirs


id3v2-0.1.11-7.fc11
-------------------
* Sat Nov 22 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.1.11-7
- Improve summary and description.


ikiwiki-2.70-1.fc11
-------------------
* Thu Nov 20 17:00:00 2008 Thomas Moschny <thomas.moschny at gmx.de> - 2.70-1
- Update to 2.70.
- Install and enable the external rst plugin.
- Stop filtering perl(RPC::XML*) requires.

* Fri Oct 10 18:00:00 2008 Thomas Moschny <thomas.moschny at gmx.de> - 2.66-1
- Update to 2.66.


iml-1.0.2-4.fc11
----------------

imlib2-1.4.2-2.fc11
-------------------
* Sun Nov 23 17:00:00 2008 Tomas Smetana <tsmetana at redhat.com> 1.4.2-2
- patch for CVE-2008-5187


immix-1.3.2-4.fc11
------------------
* Sat Nov 22 17:00:00 2008 Nicoleau Fabien <nicoleau.fabien at gmail.com> - 1.3.2-4
- Fix package summary


inn-2.4.5-4.fc11
----------------
* Tue Nov 25 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> - 2.4.5-4
- package summary tuning


insight-6.8-4.fc11
------------------

ipa-1.2.0-3.fc11
----------------

ipmitool-1.8.10-2.fc11
----------------------

iprutils-2.2.13-1.fc11
----------------------
* Fri Nov 21 17:00:00 2008 Roman Rakus <rrakus at redhat.com> - 2.2.13-1
- New upstream version


ipsec-tools-0.7.1-6.fc11
------------------------
* Mon Nov 10 17:00:00 2008 Tomas Mraz <tmraz at redhat.com> - 0.7.1-6
- fix patch porting error in the dpd-fixes patch (#470575)


iscsi-initiator-utils-6.2.0.870-0.2.rc1.fc11
--------------------------------------------
* Thu Nov  6 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 6.2.0.870-0.2.rc1
- Add force-start iscsid initscript option and use that in "patch to make
  iscsiadm start iscsid when needed" so that iscsid will actual be started
  even if there are no iscsi disks configured yet (rh 470437)
- Do not start iscsid when not running when iscsiadm -k 0 gets executed
  (rh 470438)


isomd5sum-1.0.4-3.fc11
----------------------
* Wed Nov  5 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> - 1:1.0.4-3
- Fix permission on installed manpages (#469936)

* Thu Apr 24 18:00:00 2008 Dennis Gilmore <dennis at ausil.us> - 1:1.0.4-2
- add patch for making libdir /usr/lib64 for sparc64


itaka-0.2.1-3.fc11
------------------
* Sat Nov 22 17:00:00 2008 Nicoleau Fabien <nicoleau.fabien at gmail.com> - 0.2.1-3
- Fix package summary


jabberd-2.2.4-1.fc11
--------------------

japanese-bitmap-fonts-0.20080710-3.fc11
---------------------------------------
* Fri Nov 21 17:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 0.20080710-3
- Get rid of the unreachable URL in source.
- Fix a source URL.


java-1.6.0-openjdk-1.6.0.0-6.b13.fc11
-------------------------------------
* Mon Nov 24 17:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-6.b13
- Updated icedteasnapshot.
- Updated openjdkver to b13.
- Updated openjdkdate.
- Resolves: rhbz#471987
- Resolves: rhbz#465531
- Resolves: rhbz#470551

* Thu Nov 20 17:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-6.b12
- Redirect error from removing gcjwebplugin link.
- Resolves: rhbz#471568

* Thu Nov 13 17:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-5.b12
- Added java-fonts to Provides for base package.
- Resolves: rhbz#469893

* Wed Nov 12 17:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-4.b12
- Fixed pulse audio build requirements.
- Updated release.
- Resolves: rhbz#471229

* Fri Nov  7 17:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-3.b12
- Updated icedteasnapshot.
- Resolves: rhbz#453290
- Resolves: rhbz#469361

* Wed Nov  5 17:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-3.b12
- Re-enabled pulse java. Fix committed upstream to prevent TCK failures.
- Updated release.
- Updated icedteasnapshot.
- Updated icedteaver.
- Updated visualvm source.

* Thu Oct 30 18:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-2.b12
- Fixed post plugin scriptlet to work for install, as well as upgrade.

* Wed Oct 29 18:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-2.b12
- Fixed release string.


jd-2.1.0-0.1.svn2508_trunk.fc11
-------------------------------
* Wed Nov 26 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2508

* Mon Nov 24 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.0.3-1
- 2.0.3

* Tue Nov 18 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.0.3-0.3.rc081117
- 2.0.3 rc 081117

* Mon Nov 10 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.0.3-0.2.beta081110
- 2.0.3 beta 081110


jmol-11.6-5.10137svn.fc11
-------------------------

kawa-1.9.1-6.fc11
-----------------
* Mon Nov 10 17:00:00 2008 Anthony Green <green at redhat.com> - 1:1.9.1-6
- The -javadoc package should Require the main package. (#451861)


kchmviewer-4.0-0.3.beta3.fc9
----------------------------
* Sun Nov 16 17:00:00 2008 Patrice Dumas <pertusus at free.fr> 4.0-0.3.beta3
- update to 4.0beta3, should fix #458573


kde-plasma-quickaccess-0.7.1-2.fc11
-----------------------------------
* Thu Nov  6 17:00:00 2008 Jaroslav Reznik <jreznik at redhat.com> 0.7.1-2
- default size patch
- fix URL


kdeadmin-4.1.2-4.fc11
---------------------

kdegraphics-4.1.2-4.fc11.1
--------------------------

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

* Tue Nov 25 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.80-5
- remove workaround BR on phonon-backend-gstreamer, it's ineffective since
  phonon now explicitly Requires: phonon-backend-xine and the dependency is no
  longer circular anyway
- update parallel_devel patch
- fix minimum strigi version (only 0.5.9 needed)

* 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: Provides: plasma-devel

* Thu Nov 20 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 6:4.1.80-1
- 4.1.80
- BR strigi 0.60
- BR cmake 2.6
- make install/fast
- rebase policykit patch
- rebase cmake patch
- rebase a couple of patches and drop _default_patch_fuzz 2

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

* Fri Nov  7 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1.2-6
- backport http_cache_cleaner fix (kdebug:172182)


kdepimlibs-4.1.80-2.fc11
------------------------
* 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
- make install/fast

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


kdesvn-1.2.2-1.fc11
-------------------
* Mon Nov 24 17:00:00 2008 - Orion Poplawski <orion at cora.nwra.com> - 1.2.2-1
- Update to 1.2.2
- Drop upstreamed patches


koffice-1.9.98.2-2.fc11
-----------------------
* Fri Nov 14 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 1:1.9.98.2-2
- fix conflicts with oxygen-icon-theme

* Tue Nov 11 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 1:1.9.98.2-1
- koffice-1.9.98.2 (koffice2 beta2)
- kchart awol


kover-4-1.fc11
--------------
* Thu Nov 13 17:00:00 2008 Adrian Reber <adrian at lisas.de> - 4-1
- updated to 4

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


ksplice-0.9.3-2.fc11
--------------------
* Tue Nov 11 17:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> 0.9.3-2
- New upstream release

* Thu Oct 30 18:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> 0.9.2-3
- Change upstream URI and Source location

* Wed Oct 29 18:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> 0.9.2-2
- Rebase config patch
- New upstream release


kvm-79-1.fc11
-------------
* Wed Nov 12 17:00:00 2008 Glauber Costa <glommer at redhat.com> - 79-1
- Updated to kvm-79.
- you guess: upstream changed, and kvm-62-block-rw-range-check
  had to be chnged too.

* Mon Nov  3 17:00:00 2008 Glauber Costa <glommer at redhat.com> - 78-3
- Add kvmtrace and kvmtrace_format binaries.

* Sun Nov  2 17:00:00 2008 Glauber Costa <glommer at redhat.com> - 78-3
- Execute kvm.modules script as part of post install

* Sun Nov  2 17:00:00 2008 Glauber Costa <glommer at redhat.com> - 78-1
- Update to kvm-78
- Changed patch kvm-62-block-rw-range-check. Flag value changed
  because upstream added a new flag.

* Mon Oct 27 18:00:00 2008 Glauber Costa <glommer at redhat.com> - 77-1
- Update to kvm-77
- dropped kvm-bootmenu.patch - upstream, but uses a slightly
  different interface now (F12 key)
- dropped kvm-74-page-find.patch - upstream
- dropped kvm-74-pxe-boot.patch - upstream


lat-1.2.3-5.fc11
----------------
* Thu Nov 20 17:00:00 2008 Paul Howarth <paul at city-fan.org> 1.2.3-5
- Upstream has moved to sourceforge


lcdproc-0.5.2-7.fc11
--------------------
* Fri Nov  7 17:00:00 2008 Jarod Wilson <jarod at redhat.com> - 0.5.2-7
- Add SoundGraph iMon and Antec Veris LCD device support
- Replace start_daemon w/daemon in initscripts (#468611)


ldns-1.4.0-1.fc11
-----------------
* Fri Nov  7 17:00:00 2008 Paul Wouters <paul at xelerance.com> - 1.4.0-1
- Updated to 1.4.0


libUnihan-0.5.3-3.fc11
----------------------

libX11-1.1.4-6.fc11
-------------------
* Tue Nov 18 17:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 1.1.4-6
- libX11-1.1.4-XF86Suspend.patch: add XF86Suspend and XF86Hibernate keysyms.


libXcomposite-0.4.0-6.fc11
--------------------------
* Mon Nov 10 17:00:00 2008 Adam Jackson <ajax at redhat.com> 0.4.0-6
- Fix BuildRequires.


libXrandr-1.2.3-3.fc11
----------------------
* Tue Nov 11 17:00:00 2008 Adam Jackson <ajax at redhat.com> 1.2.3-3
- Fix Requires in -devel subpackage

* Mon Nov 10 17:00:00 2008 Adam Jackson <ajax at redhat.com> 1.2.3-2
- Fix BuildRequires.


libapreq2-2.10-0.rc1.1.fc11
---------------------------
* Thu Nov 13 17:00:00 2008 Bojan Smojver <bojan at rexursive.com> - 2.10-0.rc1.1
- bump up to 2.10-RC1


libcanberra-0.10-3.fc11
-----------------------
* Thu Nov 13 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> 0.10-3
- Rebuild


libcapseo-0.3.0-0.1.20081031git431a293.fc11
-------------------------------------------
* Fri Nov 14 17:00:00 2008 Shawn Starr <spstarr at fedoraproject.org> 0.3.0-0.1.20081031git431a293
- New upstream snapshot release 0.3.0


libertas-usb8388-firmware-5.110.22.p18-1.fc11
---------------------------------------------
* Thu Nov 20 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> - 2:5.110.22.p18-1
- update to 5.110.22.p18


libetpan-0.57-1.fc11
--------------------
* Fri Nov 21 17:00:00 2008 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.57-1
- version upgrade
- switch to gnutls (fixed upstream)


libfprint-0.1.0-3.pre1.fc11
---------------------------
* Tue Nov 25 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.1.0-3.pre1
- Fix possible crasher in libfprint when setting up the fds for polling

* Mon Nov 24 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.1.0-2.pre1
- And add some API docs

* Tue Nov 18 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.1.0-1.pre1
- Fix build

* Tue Nov  4 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.1.0-0.pre1
- Update to 0.1.0-pre1


libfwbuilder-3.0.1-1.fc11
-------------------------
* Wed Nov 19 17:00:00 2008 Ralf Ertzinger <ralf at skytale.net> 3.0.1-1
- Update to 3.0.1


libgdamm-3.0.1-2.fc11
---------------------
* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 3.0.1-2
- fix source url


libgdiplus-2.2-1.pre1.fc11
--------------------------
* Tue Nov 18 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-1.pre1
- Update to 2.2 preview 1

* Sat Oct 18 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-5
- fix the long standing symlink problem


libgeda-20080929-1.fc11
-----------------------
* Tue Nov 11 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20080929-1
- New upstream release
- cleaned rpmlint warnings : unused-direct-shlib-dependencies


libglade2-2.6.3-2.fc11
----------------------
* Sun Nov  9 17:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> 2.6.3-2
- Create and own %{_libdir}/libglade and %{_libdir}/libglade/2.0.


libgnomecanvas-2.20.1.1-4.fc11
------------------------------
* Sun Nov  9 17:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> 2.20.1.1-4
- Use 'Requires: libglade2 >= 2.6.3-2' to prevent unowned
  %{_libdir}/libglade and %{_libdir}/libglade/2.0.

* Sun Nov  9 17:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> 2.20.1.1-3
- Disown %{_libdir}/libglade and %{_libdir}/libglade/2.0, and add
  'Requires: libglade2' instead.


libgnomeui-2.24.0-3.fc11
------------------------
* Tue Nov 25 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0-3
- Reduce unneeded direct library deps


libgphoto2-2.4.3-2.fc11
-----------------------
* Thu Nov 13 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 2.4.3-2
- respin (libtool)


libgtop2-2.24.0-3.fc11
----------------------
* Sun Nov  9 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0-3
- Read /proc/cpuinfo completely (#467455)


libical-0.41-1.fc11
-------------------
* Sun Nov 23 17:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 0.41-1
- Version bump to 0.41. Closes Red Hat Bugzilla bug #469252.
- Disabled C++ bindings.


libmtp-0.3.4-1.fc11
-------------------
* Fri Nov  7 17:00:00 2008 Linus Walleij <triad at df.lth.se> 0.3.4-1
- New upstream bugfix release.
- Bastiens patch is upstreamed, dropping that patch.


libnasl-2.2.11-1.fc11
---------------------
* Sun Nov 23 17:00:00 2008 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 2.2.11-1
- version upgrade
- fix #465106


libnotify-0.4.5-1.fc11
----------------------
* Sat Nov 22 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.4.5-1
- Update to 0.4.5
- Drop obsolete patches
- Tweak %summary and %description


libraw1394-2.0.0-3.fc11
-----------------------
* Thu Nov 20 17:00:00 2008 Jarod Wilson <jarod at redhat.com> - 2.0.0-3
- Address some compiler warnings
- Reduce nesting depth in new_handle dispatches
- Fix segfault in handle_arm_request


libselinux-2.0.76-1.fc11
------------------------
* Mon Nov 17 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> - 2.0.76-1
- Update to Upstream
	* Allow shell-style wildcards in x_contexts file.

* Mon Nov 17 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> - 2.0.75-2
- Eamon Walsh Patch - libselinux: allow shell-style wildcarding in X names
- Add Restorecon/Install python functions from Luke Macken

* Fri Nov  7 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> - 2.0.75-1
- Update to Upstream
	* Correct message types in AVC log messages.
	* Make matchpathcon -V pass mode from Dan Walsh.
	* Add man page for selinux_file_context_cmp from Dan Walsh.


libsemanage-2.0.29-1.fc11
-------------------------

libsepol-2.0.34-1.fc11
----------------------
* Tue Oct 14 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> 2.0.34-1
- Upgrade to latest from NSA
	* Add bounds support from KaiGai Kohei.
	* Fix invalid aliases bug from Joshua Brindle.


libsoup-2.25.1-3.fc11
---------------------
* Wed Nov 12 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.25.1-3
- Fix BuildRequires

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


libss7-1.0.1-3.fc11
-------------------

libsvm-2.88-2.fc11
------------------
* Mon Nov 10 17:00:00 2008 Ding-Yi Chen <dchen at redhat.com> - 2.88-2
- Fix java BuildRequire and Build

* Wed Nov  5 17:00:00 2008 Ding-Yi Chen <dchen at redhat.com> - 2.88-0
- Note:
  + SO version now follows upstream, i.e. SHVER=1, as upstream start to build shared library now.
    Be aware that previously SO version of libsvm.so is libsvm.so.2.86, which looks higher than
    the current SO version libsvm.so.1.
  + Replaced java-1.5.0-gcj-devel with  java-1.6.0-openjdk-devel.
  + java sub-package now have javadoc.
- Upstream update
  + From 2.87: 2008/10/13
    * svm-toy/qt updated to qt4 from qt3
    * fix a bug in svm-scale.c
    * max feature index of -r file is considered
    * Makefile: add make lib; add -Wconversion and -fPIC in Makefile
    * Add "rb" in load_model of svm.cpp
    * Simplify do_shrinking of svm.cpp
    * Change the order of loops in reconstrict_gradient of svm.cpp
    * save the number of kernel evaluations
    * Add python/setup.py
  + From 2.88: 2008/10/30
    * better gradient reconstructions
    * issue a warning when -h 0 may be faster


libtasn1-1.7-1.fc11
-------------------
* Fri Nov 21 17:00:00 2008 Tomas Mraz <tmraz at redhat.com> - 1.7-1
- updated to new upstream version


libtirpc-0.1.10-1.fc11
----------------------
* Thu Nov 20 17:00:00 2008 Steve Dickson  <steved at redhat.com> 0.1.10-1
- Updated to latest upstream version: 0.1.10

* Tue Oct 28 18:00:00 2008 Steve Dickson  <steved at redhat.com> 0.1.9-7
- Fixed some incorrect function declarations (bz468815)


libtool-2.2.6-1.fc11
--------------------
* Thu Nov 13 17:00:00 2008 Karsten Hopp <karsten at redhat.com> 2.2.6-1
- update to 2.2.6a


libtorrent-0.12.3-1.fc11
------------------------
* Tue Nov 18 17:00:00 2008 Conrad Meyer <konrad at tylerc.org> - 0.12.3-1
- Bump to 0.12.3.


libusb1-0.9.4-1.fc11
--------------------
* Fri Nov 21 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.9.4-1
- Update to 0.9.4


libv4l-0.5.6-1.fc11
-------------------
* Fri Nov 21 17:00:00 2008 Hans de Goede <j.w.r.degoede at hhs.nl> 0.5.6-1
- New upstream release 0.5.6, working around rh 472468

* Thu Nov 20 17:00:00 2008 Hans de Goede <j.w.r.degoede at hhs.nl> 0.5.5-1
- New upstream release 0.5.5, fixing rh 472217

* Mon Nov 17 17:00:00 2008 Hans de Goede <j.w.r.degoede at hhs.nl> 0.5.4-1
- New upstream release 0.5.4


libwvstreams-4.5-1.fc11
-----------------------
* Sat Nov 22 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> - 4.5-1
- new upstream release
- fixed issue with missing install-xplc target and std::sort
  missing gcc-4.3 error
- updated optional configure options list in spec file


libxklavier-3.8-2.fc11
----------------------
* Mon Nov 24 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 3.8-2
- Update to 3.8


libxml2-2.7.2-2.fc11
--------------------
* Wed Nov 12 17:00:00 2008 Daniel Veillard <veillard at redhat.com> - 2.7.2-2.fc11
- two patches for size overflows problems CVE-2008-4225 and CVE-2008-4226


liferea-1.4.22d-1.fc11
----------------------
* Sat Nov 22 17:00:00 2008 Steven M. Parrish <smparrish at shallowcreek.net> 1.4.22d-1
- New upstream release
- should fix #472636 #469351 #467083 #467874 #468214


linux-libertine-fonts-4.1.8-1.fc11
----------------------------------
* Fri Nov 21 17:00:00 2008 Frank Arnold <frank at scirocco-5v-turbo.de> 4.1.8-1
- Updated to 4.1.8
- Modified build procedure according to GENERATING.txt


logrotate-3.7.7-4.fc11
----------------------
* Fri Nov 21 17:00:00 2008 Daniel Novotny <dnovotny at redhat.com> 3.7.7-4
- fix #468926 (segfault with very large /var/log/messages)

* Thu Nov 20 17:00:00 2008 Daniel Novotny <dnovotny at redhat.com> 3.7.7-3
- less aggressive approach to the fix

* Thu Nov 20 17:00:00 2008 Daniel Novotny <dnovotny at redhat.com> 3.7.7-2
- fix #471463 (selinux problems with logrotate)


logwatch-7.3.6-35.fc11
----------------------
* Thu Nov 13 17:00:00 2008 Ivana Varekova <varekova at redhat.com> 7.3.6-35
- fix exim script

* Tue Nov 11 17:00:00 2008 Ivana Varekova <varekova at redhat.com> 7.3.6-34
- fix pam-unix script patches

* Thu Oct 30 18:00:00 2008 Ivana Varekova <varekova at redhat.com> 7.3.6-33
- mark logwatch.conf as a configure file (#468655)

* Wed Oct 29 18:00:00 2008 Ivana Varekova <varekova at redhat.com> 7.3.6-32
- parse another postfix log, do postfix patches cleanup


lostlabyrinth-3.3.5-1.fc11
--------------------------
* Mon Nov 24 17:00:00 2008 Hans de Goede <j.w.r.degoede at hhs.nl> 3.3.5-1
- New upstream release 3.3.5


lostlabyrinth-graphics-3.3.5-1.fc11
-----------------------------------

loudmouth-1.4.3-2.fc11
----------------------
* Sat Nov 22 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 1.4.3-2
- Simplify sumary & description.

* Sun Nov  9 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 1.4.3-1
- Update to 1.4.3.


lout-3.38-1.fc11
----------------
* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 3.38-1
- 3.38

* Thu Oct 16 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 3.37-4
- enable makedocs


lsscsi-0.21-2.fc9
-----------------
* Tue Nov  4 17:00:00 2008 Dan Horak <dan[at]danny.cz> - 0.21-2
- add disttag

* Tue Nov  4 17:00:00 2008 Dan Horak <dan[at]danny.cz> - 0.21-1
- update to 0.21
- update urls

* Thu May 22 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.17-6
- fix license tag


lvm2-2.02.43-1.fc11
-------------------
* Mon Nov 10 17:00:00 2008 Alasdair Kergon <agk at redhat.com>> - 2.02.43-1
- Upstream merge of device-mapper and lvm2 source.
- Correct prototype for --permission on lvchange and lvcreate man pages.
- Exit with non-zero status from vgdisplay if couldn't show any requested VG.
- libdevmapper.pc: Use simplified x.y.z version number.
- Accept locking fallback_to_* options in the global section as documented.
- Several fixes to lvconvert involving mirrors.
- Avoid overwriting in-use on-disk text metadata when metadataarea fills up.
- Generate man pages from templates and include version.
- Fix misleading error message when there are no allocatable extents in VG.
- Fix handling of PVs which reappeared with old metadata version.
- Fix validation of --minor and --major in lvcreate to require -My always.
- Allow lvremove to remove LVs from VGs with missing PVs.
- In VG with PVs missing, by default allow activation of LVs that are complete.
- Require --force with --removemissing in vgreduce to remove partial LVs.
- No longer write out PARTIAL flag into metadata backups.
- Treat new default activation/missing_stripe_filler "error" as an error target.
- Add devices/md_chunk_alignment to lvm.conf.
- Pass struct physical_volume to pe_align and adjust for md chunk size.
- Avoid shuffling remaining mirror images when removing one, retaining primary.
- Prevent resizing an LV while lvconvert is using it.
- Avoid repeatedly wiping cache while VG_GLOBAL is held in vgscan & pvscan.
- Fix pvresize to not allow resize if PV has two metadata areas.
- Fix setting of volume limit count if converting to lvm1 format.
- Fix vgconvert logical volume id metadata validation.
- Fix lvmdump metadata gather option (-m) to work correctly.
- Fix allocation bug in text metadata format write error path.
- Fix vgcfgbackup to properly check filename if template is used.
- vgremove tries to remove lv snapshot first.
- Improve file descriptor leak detection to display likely culprit and filename.
- Avoid looping forever in _pv_analyze_mda_raw used by pvck.
- Change lvchange exit status to indicate if any part of the operation failed.
- Fix pvchange and pvremove to handle PVs without mdas.
- Fix pvchange -M1 -u to preserve existing extent locations when there's a VG.
- Cease recognising snapshot-in-use percentages returned by early devt kernels.
- Add backward-compatible flags field to on-disk format_text metadata.
- libdevmapper: Only resume devices in dm_tree_preload_children if size changes.
- libdevmapper: Extend deptree buffers so the largest possible device numbers fit.
- libdevmapper: Underline longer report help text headings.


m2crypto-0.19.1-2
-----------------
* Mon Nov 10 17:00:00 2008 Miloslav Trma?? <mitr at redhat.com> - 0.19.1-2
- Import all gcc-defined macros into SWIG (recommended by Adam Tkac)


m4-1.4.12-1.fc11
----------------
* Wed Nov  5 17:00:00 2008 Vitezslav Crhonek <vcrhonek at redhat.com> - 1.4.12-1
- Update to m4-1.4.12
  Resolves: #469944
- Merge review
  Resolves: #226115


man-1.6f-14.fc11
----------------
* Fri Nov 21 17:00:00 2008 Ivana Varekova <varekova at redhat.com> - 1.6f-14
- Resolves: #456162
  locale settings problem

* Thu Nov 20 17:00:00 2008 Ivana Varekova <varekova at redhat.com> - 1.6f-13
- Resolves: #458042
  makewhatis error on file name with shell meta-characters

* Tue Nov 18 17:00:00 2008 Ivana Varekova <varekova at redhat.com> - 1.6f-12
- Resolves: #471784
  makewhatis problem with man-pages with dash in its name


man-pages-3.13-1.fc11
---------------------
* Thu Nov 13 17:00:00 2008 Ivana Varekova <varekova at redhat.com> - 3.13-1
- update to 3.13


man-pages-ko-20050219-7.fc11
----------------------------

mcrypt-2.6.8-1.fc11
-------------------
* Mon Nov 24 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2.6.8-1
- update to 2.6.8


mdbtools-0.6-0.5.cvs20051109.fc11
---------------------------------
* Mon Nov 24 17:00:00 2008 Hans de Goede <j.w.r.degoede at hhs.nl> 0.6-0.5.cvs20051109
- Fix several issues with the odbc interface (rh 472692)


meld-1.2.1-1.fc11
-----------------
* Sun Nov 23 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 1.2.1-1
- Update to 1.2.1.
- Drop desktop file patch.  Fixed upstream.


metacity-2.25.8-4.fc11
----------------------
* Mon Nov 24 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.25.8-4
- Update to 2.25.8

* Sat Nov 22 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.25.5-4
- Tweak %summary and %description
- Fix BuildRequires

* Wed Nov 12 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.25.5-1
- Update to 2.25.5

* Fri Oct 31 18:00:00 2008 Soren Sandmann <sandmann at redhat.com> - 2.24.0-3
- Don't spam .xsession-errors so hard (bug 467802)


mew-6.1.51-1.fc11
-----------------
* Fri Nov 21 17:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 6.1.51-1
- New upstream release.


mfiler3-2.1.3-1.fc11
--------------------
* Sun Nov  9 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.1.3-1
- 2.1.3

* Sun Nov  2 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.1.2-1
- 2.1.2


mkinitrd-6.0.71-1.fc11
----------------------

mod_fcgid-2.2-7.fc11
--------------------

mono-2.2-2.pre1.fc11
--------------------
* Tue Nov 25 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-2.pre1
- fix monodoc libdir issues

* Tue Nov 25 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-1.1.pre1
- rebuild

* Tue Nov 18 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-1.pre1
- Bump to 2.2 preview 1
- remove old patches
- add build information for monodoc

* Sun Nov  2 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0.13
- Add in mono-api-diff and mono-api-info


mono-cecil-flowanalysis-0.1-0.6.20080409svn100264.fc11
------------------------------------------------------
* Tue Nov 25 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 0.1-0.6.20080409svn100264
- bump release correctly

* Tue Nov 25 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 0.1-0.5.20080409svn100264.1
- rebuild against mono 2.2


moodle-1.9.3-3.fc11
-------------------
* Fri Nov  7 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 1.9.3-3
- Moved to weekly downloaded 11/7/08 to fix Snoopy CVE-2008-4796.

* Fri Oct 31 18:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 1.9.3-2
- Fix for BZ 468929, overactive cron job.


mousetweaks-2.25.1-1.fc11
-------------------------
* Wed Nov 12 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.1-1
- Update to 2.25.1


mtools-4.0.0-0.1.pre2.fc11
--------------------------
* Wed Nov 19 17:00:00 2008 Adam Tkac <atkac redhat com> 4.0.0-0.1.pre2
- updated to 4.0.0_pre2

* Tue Nov 11 17:00:00 2008 Adam Tkac <atkac redhat com> 4.0.0-0.1.pre1
- updated to 4.0.0_pre1


mx4j-3.0.1-7.9.fc11
-------------------
* Fri Nov 21 17:00:00 2008 David Walluck <dwalluck at redhat.com> 1:3.0.1-7.9
- fix file permissions
- own directories


mysql++-3.0.7-1.fc11
--------------------
* Thu Nov 20 17:00:00 2008 Remi Collet <Fedora at FamilleCollet.com> 3.0.7-1
- update to 3.0.7


mythes-de-0.20081123-1.fc11
---------------------------
* Sun Nov 23 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20081123-1
- latest version


nagios-3.0.5-1.fc11
-------------------
* Mon Nov 24 17:00:00 2008 Mike McGrath <mmcgrath at redhat.com> 3.0.5-1
- Upstream released a new version


nasm-2.05.01-1.fc11
-------------------
* Wed Nov 12 17:00:00 2008 Zdenek Prikryl <zprikryl at redhat.com> - 2.05.01-1
- updated to 2.05.01


nautilus-2.24.1-4.fc11
----------------------
* Thu Nov 13 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.24.1-4
- Rebuild


nautilus-open-terminal-0.9-10.fc11
----------------------------------
* Thu Nov 13 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.9-10
- Rebuild against latest gnome-desktop


nessus-core-2.2.11-1.fc11
-------------------------
* Sun Nov 23 17:00:00 2008 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 2.2.11-1
- fix #465113 FTBFS


nessus-libraries-2.2.11-1.fc11
------------------------------
* Sun Nov 23 17:00:00 2008 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 2.2.11-1
- version upgrade


netbeans-6.1-10.fc11
--------------------
* Tue Nov 25 17:00:00 2008 Victor G. Vasilyev <victor.vasilyev at sun.com> 6.1-10
- Explicit dependencies on the jakarta-commons-logging package are added (#472825).
- Summary is fixed according to the request of the Richard Hughes <hughsient at gmail.com>.
- Call of the brp-java-repack-jars script is disabled.
- The deprecated key "Encoding" is removed from the desktop file template.


nfs-utils-1.1.4-3.fc11
----------------------
* Tue Nov 25 17:00:00 2008 Steve Dickson <steved at redhat.com> 1.1.4-3
- Give showmount support for querying via rpcbindv3/v4

* Tue Nov 18 17:00:00 2008 Steve Dickson <steved at redhat.com> 1.1.4-2
- Add AF_INET6-capable API to acquire an RPC CLIENT
- Introduce rpcbind client utility functions


nginx-0.6.33-1.fc11
-------------------
* Sun Nov 23 17:00:00 2008 Jeremy Hinegardner <jeremy at hinegardner dot org> - 0.6.33-1
- update to 0.6.33


nkf-2.0.8b-4.fc11
-----------------
* Fri Nov 21 17:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 1:2.0.8b-4
- Fix a source URL.


nntpgrab-0.4.0-1.fc11
---------------------
* Sun Nov 23 17:00:00 2008 Erik van Pienbroek <info at nntpgrab.nl> - 0.4.0-1
- Update to 0.4.0


notification-daemon-0.4.0-1.fc11
--------------------------------
* Sat Nov 22 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.4.0-1
- Update to 0.4.0
- Drop obosolete patches
- Tweak description


notification-daemon-engine-nodoka-0.1.0-4.fc11
----------------------------------------------
* Sun Nov 23 17:00:00 2008 Martin Sourada <mso at fedoraproject.org> - 0.1.0-4
- Make version check less strict (mclasen, rhbz #472661)


notify-sharp-0.4.0-0.5.20080912svn.fc11
---------------------------------------

nsd-3.2.0-3.fc11
----------------
* Mon Nov 24 17:00:00 2008 Paul Wouters <paul at xelerance.com> - 3.2.0-3
- Updates summary as per Richard Hughes guidelines

* Mon Nov 10 17:00:00 2008 Paul Wouters <paul at xelerance.com> - 3.2.0-2
- Bump version after pre-release version correction.

* Mon Nov 10 17:00:00 2008 Paul Wouters <paul at xelerance.com> - 3.2.0-1
- 3.2.0-1


nspluginwrapper-1.1.4-1.fc11
----------------------------
* Wed Nov 12 17:00:00 2008 Martin Stransky <stransky at redhat.com> 1.1.4-1
- Updated to 1.1.4
- Consolidated build patches


nspr-4.7.3-2.fc11
-----------------
* Wed Nov 19 17:00:00 2008 Kai Engert <kaie at redhat.com> - 4.7.3-2
- update to 4.7.3


nted-1.4.15-1.fc11
------------------
* Tue Nov 11 17:00:00 2008 Hans Ulrich Niedermann <hun at n-dimensional.de> - 1.4.15-1
- Update to upstream's 1.4.15 release.


obby-0.4.6-1.fc11
-----------------
* Thu Sep 11 18:00:00 2008 Luke Macken <lmacken at redhat.com> - 0.4.6-1
- Update to the latest upstream release


obexd-0.8-1.fc11
----------------
* Thu Nov 20 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.8-1
- Update to 0.8

* Mon Nov 17 17:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.7-1
- Update to 0.7


ocaml-3.11.0-0.4.beta1.fc11
---------------------------
* Mon Nov 24 17:00:00 2008 Richard W.M. Jones <rjnes at redhat.com> - 3.11.0-0.4.beta1
- Rebuild.

* Thu Nov 20 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 3.11.0+beta1-2
- Fix Invalid_argument("String.index_from") with patch from upstream.

* Thu Nov 20 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 3.11.0-0.3.beta1
- fix NVR to match packaging guidelines

* Tue Nov 18 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 3.11.0+beta1-1
- Rebuild for major new upstream release of 3.11.0 for Fedora 11.


ocaml-augeas-0.4-2.fc11
-----------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.4-2
- Rebuild for OCaml 3.11.0


ocaml-bisect-1.0-0.2.alpha.fc11
-------------------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.0-0.2.alpha
- Rebuild for OCaml 3.11.0


ocaml-bitstring-2.0.0-5.fc11
----------------------------
* Thu Nov 20 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 2.0.0-5
- Disable CIL tools.
- Patch for OCaml 3.11.0.

* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 2.0.0-3
- Rebuild for OCaml 3.11.0


ocaml-calendar-2.0.4-2.fc11
---------------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 2.0.4-2
- Rebuild for OCaml 3.11.0


ocaml-camlidl-1.05-6.fc11
-------------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.05-6
- Rebuild for OCaml 3.11.0


ocaml-camlp5-5.10-1.fc11
------------------------
* Thu Nov 20 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 5.10-1
- New upstream version 5.10.

* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 5.09-2
- Rebuild for OCaml 3.11.0


ocaml-camomile-0.7.1-8.fc11
---------------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.7.1-8
- Rebuild for OCaml 3.11.0


ocaml-cmigrep-1.5-7.fc11
------------------------
* Thu Nov 20 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.5-7
- Apply string-index-from patch from OCaml package.

* Thu Nov 20 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.5-6
- Fix for OCaml 3.11.0+beta1.

* Tue Nov 18 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.5-5
- Rebuild against OCaml 3.11.0+beta1.


ocaml-cryptokit-1.3-6.fc11
--------------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.3-6
- Rebuild for OCaml 3.11.0


ocaml-curl-0.5.0-2.fc11
-----------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.5.0-2
- Rebuild for OCaml 3.11.0


ocaml-curses-1.0.3-2.fc11
-------------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.0.3-2
- Rebuild for OCaml 3.11.0

* Mon Nov 17 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.0.3-1
- Major version leap to the latest, supported, released version.


ocaml-dbus-0.07-2.fc11
----------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.07-2
- Rebuild for OCaml 3.11.0


ocaml-deriving-0.1.1a-4.fc11
----------------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.1.1a-4
- Rebuild for OCaml 3.11.0


ocaml-expat-0.9.1-13.fc11
-------------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.9.1-13
- Rebuild for OCaml 3.11.0


ocaml-extlib-1.5.1-4.fc11
-------------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.5.1-4
- Rebuild for OCaml 3.11.0


ocaml-facile-1.1-6.fc11
-----------------------
* Tue Nov 25 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> - 1.1-6
- rebuild for new ocaml (3.11.0 beta1)


ocaml-fileutils-0.3.0-7.fc11
----------------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.3.0-7
- Rebuild for OCaml 3.11.0


ocaml-findlib-1.2.3-2.fc11
--------------------------
* Thu Nov 20 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.2.3-2
- Force rebuild.

* Thu Nov 20 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.2.3-1
- New upstream version 1.2.3.

* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.2.2-2
- Rebuild for OCaml 3.11.0


ocaml-gettext-0.3.2-4.fc11
--------------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.3.2-4
- Rebuild for OCaml 3.11.0


ocaml-json-static-0.9.6-6.fc11
------------------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.9.6-6
- Rebuild for OCaml 3.11.0


ocaml-lablgl-1.03-5.fc11
------------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.03-5
- Rebuild for OCaml 3.11.0


ocaml-lablgtk-2.10.1-6.fc11
---------------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 2.10.1-6
- Rebuild for OCaml 3.11.0


ocaml-libvirt-0.4.4.2-2.fc11
----------------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.4.4.2-2
- Rebuild for OCaml 3.11.0


ocaml-ounit-1.0.3-2.fc11
------------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.0.3-2
- Rebuild for OCaml 3.11.0


ocaml-pcre-5.15.0-2.fc11
------------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 5.15.0-2
- Rebuild for OCaml 3.11.0


ocaml-perl4caml-0.9.5-6.fc11
----------------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.9.5-6
- Rebuild for OCaml 3.11.0


ocaml-postgresql-1.9.2-2.fc11
-----------------------------
* Mon Nov 24 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.9.2-2
- Rebuild.

* Thu Nov 20 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.9.2-1
- New upstream release 1.9.2.

* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.8.2-5
- Rebuild for OCaml 3.11.0


ocaml-res-3.0.0-1.fc11
----------------------
* Thu Nov 20 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 3.0.0-1
- New upstream version 3.0.0.

* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 2.2.6-2
- Rebuild for OCaml 3.11.0


ocaml-sqlite-1.2.0-2.fc11
-------------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.2.0-2
- Rebuild for OCaml 3.11.0


ocaml-ssl-0.4.2-11.fc11
-----------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 0.4.2-11
- Rebuild for OCaml 3.11.0


ocaml-type-conv-1.6.4-2.fc11
----------------------------
* Mon Nov 24 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.6.4-2
- Rebuild.

* Thu Nov 20 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.6.4-1
- New upstream version 1.6.4.

* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.6.1-2
- Rebuild for OCaml 3.11.0


ocaml-ulex-1.1-4.fc11
---------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.1-4
- Rebuild for OCaml 3.11.0


ocaml-xml-light-2.2.cvs20070817-9.fc11
--------------------------------------
* Wed Nov 19 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 2.2.cvs20070817-9
- Rebuild for OCaml 3.11.0


ochusha-0.5.99.68-0.4.cvs20081126T1300.fc11
-------------------------------------------
* Wed Nov 26 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- Use latest CVS


ocspd-1.5.1-0.3.rc1.fc11
------------------------

oggconvert-0.3.2-2.fc11
-----------------------
* Thu Nov 20 17:00:00 2008 Richard Hughes <rhughes at redhat.com> - 0.3.2-2
- Update the summary to be more terse.
- Fixes #472365


ogre-1.6.0-1.fc11
-----------------
* Thu Nov  6 17:00:00 2008 Alexey Torkhov <atorkhov at gmail.com> 1.6.0-1
- New upstream release 1.6.0
- Updated samples running script
- Removed non-free quake map from samples media
- Added docs license in License tag


olpc-netutils-0.7-2.fc11
------------------------
* Mon Nov 17 17:00:00 2008 Peter Robinson <pbrobinson at gmail.com> - 0.7-2
- Rebuild for Fedora 10 rebase

* Fri Sep 12 18:00:00 2008 Michael Stone <michael at laptop.org> - 0.7-1
- Michael Stone (1):
    Capture disk and process status.

* Fri Sep 12 18:00:00 2008 Michael Stone <michael at laptop.org> - 0.6-2
- Michael Stone (1):
    Pull in tcpdump for olpc-netcapture.

* Fri Sep 12 18:00:00 2008 Michael Stone <michael at laptop.org> - 0.6-1
- Michael Stone (1):
    Dirty hack to make sugar-telepathies work on XOs.

* Fri Sep 12 18:00:00 2008 Michael Stone <michael at laptop.org> - 0.5-1
- Guillaume Desmottes (2):
    Print the quantity of buddies we see.
    Use /tmp/olpc-session-bus if available; otherwise, read the sugar-xos command-line.
- Michael Stone (2):
    Cosmetic fixups to whitespace, comments, and the specfile.
    Makefile improvements.


opengl-games-utils-0.1-6.fc11
-----------------------------
* Thu Nov 13 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 0.1-6
- Handle glxinfo output not containing any dri info at all (rh 471374)


openhpi-2.13.1-2.fc11
---------------------
* Tue Nov 25 17:00:00 2008 Dan Horak <dan[at]danny.cz> - 2.13.1-2
- shorten Summary

* Thu Nov 20 17:00:00 2008 Dan Horak <dan[at]danny.cz> - 2.13.1-1
- update to 2.13.1

* Mon Nov 17 17:00:00 2008 Dan Horak <dan[at]danny.cz> - 2.12.0-2
- rebuild for new libtool


openhpi-subagent-2.3.4-3.fc11
-----------------------------
* Fri Nov 21 17:00:00 2008 Dan Horak <dan[at]danny.cz> - 2.3.4-3
- fix Source0 URL


openobex-1.4-1.fc11
-------------------
* Tue Nov 18 17:00:00 2008 Jiri Moskovcak <jmoskovc at redhat.com> 1.4.1
- New upstream version
- Spec file cleanup
- Removed unneeded patches


openoffice.org-voikko-3.0-4.fc11
--------------------------------
* Wed Nov 19 17:00:00 2008 Ville-Pekka Vainio <vpivaini AT cs.helsinki.fi> - 3.0-4
- Add Epoch 1 to all openoffice.org-core pre-/post-Requires to avoid bugs such
  as rhbz #472093 (incorrect openoffice.org-core dependency)


openswan-2.6.19-1.fc11
----------------------
* Tue Nov 25 17:00:00 2008 Avesh Agarwal <avagarwa at redhat.com> - 2.6.19-1
- new upstream release


optipng-0.6.2-1.fc11
--------------------

orca-2.25.1-1.fc11
------------------
* Wed Nov 12 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.1-1
- Update to 2.25.1


osmo-0.2.4-1.fc11
-----------------
* Mon Nov 24 17:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 0.2.4-1
- Version bump to 0.2.4. Closes Red Hat Bugzilla bug #464484.
- Timezone information fix accepted by upstream.


pango-1.22.3-1.fc11
-------------------
* Mon Nov 24 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1.22.3-1
- U[date to 1.22.3

* Wed Nov 12 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1.22.2-1
- Update to 1.22.2


paps-0.6.8-8.fc11
-----------------
* Mon Nov 17 17:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 0.6.8-8
- Courier font to be a default font for texttopaps. (#469325)


parcellite-0.9-1.fc11
---------------------
* Sun Nov 23 17:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.9-1
- Update to 0.9
- Fix Control+Click behaviour
- Small corrections to German translation


patch-2.5.4-36.fc11
-------------------
* Mon Nov 24 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 2.5.4-36
- Better summary.


pdns-2.9.21.2-1.fc11
--------------------

perl-Business-ISBN-2.04_01-1.fc11
---------------------------------
* Mon Nov 24 17:00:00 2008 Stepan Kasal <skasal at redhat.com> - 2.04_01-1
- new upstream version
- drop integrated patch


perl-Business-ISBN-Data-20081020-1.fc11
---------------------------------------
* Mon Nov 24 17:00:00 2008 Stepan Kasal <skasal at redhat.com> - 20081020-1
- new upstream version


perl-Carp-Clan-6.00-1.fc9
-------------------------
* Tue Nov 18 17:00:00 2008 Marcela Maslanova <mmaslano at redhat.com> - 6.00-1
- remove patch, update to 6.00 for MooseX::Types
- Resolves: rhbz#470846


perl-Catalyst-Manual-5.7014-1.fc11
----------------------------------
* Sat Nov  8 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 5.7014-1
- update to 5.7014


perl-Class-DBI-Pg-0.09-5.fc11
-----------------------------
* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.09-5
- fix source url for new CPAN owner


perl-Class-MOP-0.70-1.fc11
--------------------------
* Fri Nov 14 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.70-1
- update to 0.70

* Sat Nov  8 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.69-2
- add Devel::GlobalDestruction and Sub::Name as explicit requires (not
  automagically picked up!)

* Fri Nov  7 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.69-1
- 0.69

* Thu Nov  6 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.68-1
- update to 0.68

* Sun Oct 19 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.67-1
- update to 0.67
- reenable all br's, as tests are run for pp and xs now


perl-Config-Augeas-0.304-1.fc11
-------------------------------
* Tue Nov 25 17:00:00 2008 Alan Pevec <apevec at redhat.com> 0.304-1
- new upstream release 0.304
  * lib/Config/Augeas.pm (print): Improved print method.
  * lib/Config/Augeas.pm (set): no longer dies when trying to set a
    value to 0. Only dies when the value to set is undefined.


perl-Config-IniFiles-2.40-0.1.20081120svn88.fc11
------------------------------------------------
* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2.40-0.1.20081120svn88
- Update to svn checkout, since 2.39 doesn't appear to be accurate.


perl-Crypt-DH-0.06-9.fc11
-------------------------
* Tue Nov  4 17:00:00 2008 Paul Howarth <paul at city-fan.org> 0.06-9
- BuildRequire and Require a GMP support module, either Math::GMP or
  Math::BigInt::GMP depending on how recent Math::BigInt is


perl-Crypt-DSA-0.14-7.fc11
--------------------------
* Mon Nov  3 17:00:00 2008 Paul Howarth <paul at city-fan.org> 0.14-7
- BuildRequire and Require a GMP support module, either Math::GMP or
  Math::BigInt::GMP depending on how recent Math::BigInt is
- BuildRequire openssl, which significantly speeds up the keygen test


perl-Data-Visitor-0.21-1.fc11
-----------------------------
* Wed Nov 12 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.21-1
- update to 0.21

* Sat Sep  6 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.19-1
- update to 0.19


perl-HTML-Tree-3.23-5.fc11
--------------------------
* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1:3.23-5
- fix source url


perl-HTTP-Body-1.04-1.fc11
--------------------------
* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 1.04-1
- update to 1.04


perl-Hook-LexWrap-0.21-1.fc11
-----------------------------
* Mon Nov 10 17:00:00 2008 Paul Howarth <paul at city-fan.org> - 0.21-1
- Update to 0.21
- New upstream maintainer => new source URL
- Add buildreqs perl(Test::More) and perl(Test::Pod)
- Update patch for CPAN RT#38892 to apply without fuzz
- Fix argument order for find with -depth


perl-IO-AIO-3.16-1.fc11
-----------------------
* Sun Nov  9 17:00:00 2008 Ruben Kerkhof <ruben at rubenkerkhof.com> 3.16-1
- Upstream release new version


perl-IO-CaptureOutput-1.10-1.fc11
---------------------------------
* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 1.10-1
- update to 1.10


perl-IO-Socket-SSL-1.18-1.fc11
------------------------------
* Tue Nov 18 17:00:00 2008 Paul Howarth <paul at city-fan.org> - 1.18-1
- Update to latest upstream version: 1.18
- BR: perl(IO::Socket::INET6) for extra test coverage


perl-Ima-DBI-0.35-4.fc11
------------------------
* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.35-4
- fix source url


perl-MARC-Record-2.0.0-3.fc11
-----------------------------
* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2.0.0-3
- fix source url


perl-MIME-Types-1.24-1.fc11
---------------------------
* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.24-1
- update to 1.24


perl-Mail-Mbox-MessageParser-1.5000-6.fc11
------------------------------------------
* Thu Nov 20 17:00:00 2008 Paul Howarth <paul at city-fan.org> 1.5000-6
- Project upstream has moved from Sourceforge to Google Code but Google Code
  site is content-free so use standard CPAN URLs instead


perl-Moose-0.61-4.fc11
----------------------
* Sat Nov  8 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.61-4
- aaaand drop them again, as it was really perl-Class-MOP's issue.

* Sat Nov  8 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.61-3
- same with Devel::GlobalDestruction (same RT as below)

* Sat Nov  8 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.61-2
- add Sub::Name as a build dep (RT#40772)

* Sat Nov  8 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.61-1
- update to 0.61
- update BR's


perl-MooseX-AttributeHelpers-0.14-1.fc11
----------------------------------------
* Sat Nov  8 17:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.14-1
- updating to 0.14
- POD tests are now explicitly for author/maintainers only; removing deps


perl-Net-Daemon-0.44-5.fc11
---------------------------

perl-Net-SMTP-SSL-1.01-1.fc11
-----------------------------

perl-Net-SSH-Perl-1.33-2.fc9
----------------------------
* Tue Nov  4 17:00:00 2008 Paul Howarth <paul at city-fan.org> 1.33-2
- Run tests in en_US locale, so spell checker doesn't complain about the use of
  American English when the host is in a non-US locale

* Mon Nov  3 17:00:00 2008 Paul Howarth <paul at city-fan.org> 1.33-1
- Update to 1.33 (#469612), fixes various upstream bugs:
  * Fix open() calls (rt.cpan.org #40020)
  * Fix non-shell problem (rt.cpan.org #39980)
  * Allow full agent forwarding (rt.cpan.org #32190)
  * Handle hashed known_hosts files (rt.cpan.org #25175)
  * Add IO::Handle to Perl.pm (rt.cpan.org #40057, #35985)
  * Prevent t/03-packet.t from hanging due to high file descriptor
  | (rt.cpan.org #6101)
  * If ENV{HOME} is not set, use getpwuid. If both fail and the dir 
  | is needed, we croak (rt.cpan.org #25174)
  * Fix incorrect logical/bitwise AND mixup (rt.cpan.org #31490)
  * Allow empty stdin for SSH2 (rt.cpan.org #32730)
  * Adjust terminal dimensions dynamically if Term::ReadKey is available
  | (rt.cpan.org #34874)
- New upstream (co-)maintainer, new source URL
- t/03-packet.t re-enabled as it should no longer hang
- Add buildreqs Module::Signature, Test::Pod, Test::Pod::Coverage,
  Perl::Critic, Test::YAML::Meta, Text::SpellChecker for additional test
  coverage
- Add dependency on Term::ReadKey to provide dynamic terminal resizing
- Include upstream maintainer's GPG key for signature checking


perl-Net-eBay-0.51-1.fc11
-------------------------
* Sat Nov 22 17:00:00 2008 Xavier Bachelot <xavier at bachelot.org> - 0.51-1
- Update to 0.51.


perl-ORLite-0.15-1.fc11
-----------------------
* Wed Oct 29 18:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> 0.15-1
- update to 0.15


perl-PDF-API2-0.72-1.fc11
-------------------------
* Wed Nov 12 17:00:00 2008 Bernard Johnson <bjohnson at symetrix.com> - 0.72-1
- v 0.72


perl-Padre-0.16-1.fc11
----------------------
* Tue Nov 18 17:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> 0.16-1
- update to 0.16

* Mon Nov  3 17:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> 0.14-1
- update to 0.14
- add new requires
- remove patch for handling ORLite, with updated ORLite it's ok


perl-Scalar-Properties-0.13-3.fc11
----------------------------------
* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.13-3
- fix source url


perl-Test-MockObject-1.09-1.fc11
--------------------------------
* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.09-1
- update to 1.09


perl-Tree-DAG_Node-1.06-4.fc11
------------------------------
* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.06-4
- fix source url


perl-UNIVERSAL-isa-1.01-1.fc11
------------------------------
* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.01-1
- update to 1.01


phonon-4.2.80-2.fc11
--------------------
* Tue Nov 25 17:00:00 2008 Than Ngo <than at redhat.com> 4.2.80-1
- 4.2.80

* Tue Nov 25 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.2.80-2
- phonon-backend-xine: don't Obsolete/Provide itself, Provides: phonon-backend

* Fri Nov 21 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 4.2.80-0.1.20081121svn887051
- Use subversion (4.2.80) snapshot
- phonon-backend-xine subpkg
- make VERBOSE=1
- make install/fast
- Xine backend is in phonon now, add xine-lib-devel as BR
- BR cmake >= 2.6.0
- forward-port xine pulseaudio patch


php-ZendFramework-1.7.0-3.fc11
------------------------------
* Wed Nov 19 17:00:00 2008 Alexander Kahl <akahl at iconmobile.com> - 1.7.0-3
- fix to use internal docbook

* Wed Nov 19 17:00:00 2008 Alexander Kahl <akahl at iconmobile.com> - 1.7.0-2
- bump for rawhide (Zend_Tool activated)

* Tue Nov 18 17:00:00 2008 Alexander Kahl <akahl at iconmobile.com> - 1.7.0-1
- update to 1.7.0

* Wed Nov 12 17:00:00 2008 Alexander Kahl <akahl at iconmobile.com> - 1.6.2-2
- last tag failed, bump

* Wed Nov 12 17:00:00 2008 Alexander Kahl <akahl at iconmobile.com> - 1.6.2-1
- update to 1.6.2

* Tue Sep 16 18:00:00 2008 Alexander Kahl <akahl at iconmobile.com> - 1.6.1-1
- update to 1.6.1


php-pear-HTTP-Client-1.2.1-1.fc11
---------------------------------
* Sat Nov  8 17:00:00 2008 Christopher Stone <chris.stone at gmail.com> 1.2.1-1
- Upstream sync
- Now Requires HTTP_Request 1.4.0


php-pear-Log-1.11.3-1.fc11
--------------------------
* Sat Nov 22 17:00:00 2008 Remi Collet <Fedora at FamilleCollet.com> 1.11.3-1
- update to 1.11.3


php-pear-PHPUnit-3.3.4-1.fc11
-----------------------------
* Sat Nov  8 17:00:00 2008 Christopher Stone <chris.stone at gmail.com> 3.3.4-1
- Upstream sync


picviz-0.4-1.fc11
-----------------

piklab-0.15.3-2.fc11
--------------------
* Mon Nov 10 17:00:00 2008 Thibault North <tnorth [AT] fedoraproject DOT org> - 0.15.3-2
- Fix %patch3


pixman-0.12.0-2.fc11
--------------------

plplot-5.9.0-2.svn8985.fc11
---------------------------
* Thu Nov 13 17:00:00 2008 - Orion Poplawski <orion at cora.nwra.com> - 5.9.0-2.svn8985
- Update to svn revision 8985
- Rebuild for libtool 2.2
- Change to use %bcond_with/without
- Bootstrap build - without PDL


plt-scheme-4.1.2-1.fc11
-----------------------
* Sun Nov  9 17:00:00 2008 Gerard Milmeister <gemi at bluewin.ch> - 1:4.1.2-1
- new release 4.1.2


plymouth-0.6.0-0.2008.11.17.3.fc11
----------------------------------

podsleuth-0.6.3-1.fc11
----------------------

policycoreutils-2.0.59-1.fc11
-----------------------------
* Tue Nov 11 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 2.0.59-1
- Update to upstream
	* fcontext add checked local records twice, fix from Dan Walsh.

* Mon Nov 10 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 2.0.58-1
- Update to upstream
	* Allow local file context entries to override policy entries in
	semanage from Dan Walsh.
	* Newrole error message corrections from Dan Walsh.
	* Add exception to audit2why call in audit2allow from Dan Walsh.

* Fri Nov  7 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 2.0.57-12
- add compression


poppler-0.10.1-1.fc11
---------------------
* Tue Nov 11 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.10.1-1
- Update to 0.10.1 and  -data 0.2.1

* Tue Sep 16 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 0.8.7-2
- cleanup qt3 hack
- %description cosmetics


postfix-2.5.5-2.fc11
--------------------
* Thu Nov 20 17:00:00 2008 Miroslav Lichvar <mlichvar at redhat.com> 2:2.5.5-2
- enable Large file support on 32-bit archs (#428996)
- fix mailq(1) and newaliases(1) man pages (#429501)
- move pflogsumm and qshape to -perl-scripts subpackage (#467529)
- update pflogsumm to 1.1.1
- fix large-fs patch
- drop open_define patch
- add -Wno-comment to CFLAGS


ppl-0.10-3.fc11
---------------
* Tue Nov  4 17:00:00 2008 Roberto Bagnara <bagnara at cs.unipr.it> 0.10-3
- Fixed the requirements of the `ppl-java' package.

* Tue Nov  4 17:00:00 2008 Roberto Bagnara <bagnara at cs.unipr.it> 0.10-2
- Added m4 >= 1.4.8 to build requirements.

* Tue Nov  4 17:00:00 2008 Roberto Bagnara <bagnara at cs.unipr.it> 0.10-1
- Updated and extended for PPL 0.10.  In particular, the `ppl-config'
  program, being useful also for non-development activities, has been
  brought back to the main package.


preupgrade-1.0.0-1.fc11
-----------------------
* Fri Nov 21 17:00:00 2008 Will Woods <wwoods at redhat.com> - 1.0.0-1
- Minor UI fixes
- Add --clean flag
- Use checksums to verify boot image integrity
- Clean up bootloader config when cleaning an interrupted run
- Use 'ybin --bootonce' on ppc rather than changing default boot target
- Be more careful about picking a keymap (bug 471515)
- Add Fedora 10 (Cambridge) to releases.txt

* Mon Nov  3 17:00:00 2008 Will Woods <wwoods at redhat.com> - 0.9.9-1
- Fetch release data from http://mirrors.fedoraproject.org/releases.txt
- Recognize new metadata filenames
- Generate kickstart for all installs
- Automatically upgrade bootloader config during upgrade
- preupgrade-cli: Add --vnc for headless remote installs
- preupgrade-cli: Properly set locale so we don't crash on non-en_US
- preupgrade-cli: Fix --help


privoxy-3.0.10-2.fc11
---------------------
* Mon Nov 24 17:00:00 2008 Karsten Hopp <karsten at redhat.com> 3.0.10-2
- fix summary


psacct-6.3.2-52.fc11
--------------------
* Thu Nov 13 17:00:00 2008 Ivana Varekova <varekova at redhat.com> - 6.3.2-52
- remove link to nonexisting page from sa man-page


pulseaudio-0.9.13-7.fc11
------------------------
* Thu Nov 13 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> 0.9.13-7
- Rebuild


purple-microblog-0.2.0-1.fc11
-----------------------------
* Sun Nov  9 17:00:00 2008 Mat??j Cepl <mcepl at redhat.com> - 0.2.0-1
- New upstream release.

* Wed Oct 29 18:00:00 2008 Mat??j Cepl <mcepl at redhat.com> 0.1.2-2.20081023svn174.fc10
- New checkout from SVN.


pyke-0.5-1.fc11
---------------
* Tue Nov 11 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 0.5-1
- update to 0.5


pymol-1.1-12.20081015svn3468.fc11
---------------------------------
* Wed Oct 29 18:00:00 2008 Tim Fenn <fenn at stanford.edu> - 1.1-12-20081015svn3468
- fix vendor flag, remove space from pymol.desktop

* Tue Oct 28 18:00:00 2008 Tim Fenn <fenn at stanford.edu> - 1.1-11-20081015svn3468
- add vendor flag to desktop-file-install


python-IPy-0.62-1.fc11
----------------------
* Sat Nov 22 17:00:00 2008 Matt Domsch <mdomsch at fedoraproject.org> - 0.62-1
- new upstream version
  - Fix reverse DNS of IPv6 address: use ".ip6.arpa." suffix instead of deprecated ".ip6.int." suffix
  - Patch from Aras Vaichas allowing the [-1] operator to work with an IP object of size 1.


python-fedora-0.3.8-1.fc11
--------------------------
* Thu Nov 20 17:00:00 2008 Toshio Kuratomi <toshio at fedoraproject.org> - 0.3.8-1
- New upstream with pycurl client backend, more fas methods, and bodhi bugfix.

* Thu Oct 30 18:00:00 2008 Toshio Kuratomi <toshio at fedoraproject.org> - 0.3.7-1
- New upstream has more complete pkgdb integration.


python-lxml-2.2-0.2.alpha1.fc11
-------------------------------
* Mon Nov 24 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 2.2-0.2.alpha1.fc11
- Don't forget to upload the sources!

* Mon Nov 24 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 2.2-0.1.alpha1
- 2.2alpha1 (2008-11-23)
- Features added
- 
-    * Support for XSLT result tree fragments in XPath/XSLT extension
-      functions.
-    * QName objects have new properties namespace and localname.
-    * New options for exclusive C14N and C14N without comments.
-    * Instantiating a custom Element classes creates a new Element.
- 
- Bugs fixed
- 
-    * XSLT didn't inherit the parse options of the input document.
-    * 0-bytes could slip through the API when used inside of Unicode
-      strings.
-    * With lxml.html.clean.autolink, links with balanced parenthesis, that
-      end in a parenthesis, will be linked in their entirety (typical with
-      Wikipedia links).

* Mon Nov 17 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 2.1.3-1
- 2.1.3 (2008-11-17)
- Bugs fixed
- 
-    * Ref-count leaks when lxml enters a try-except statement while an
-      outside exception lives in sys.exc_*(). This was due to a problem
-      in Cython, not lxml itself.
-    * Parser Unicode decoding errors could get swallowed by other
-      exceptions.
-    * Name/import errors in some Python modules.
-    * Internal DTD subsets that did not specify a system or public ID
-      were not serialised and did not appear in the docinfo property
-      of ElementTrees.
-    * Fix a pre-Py3k warning when parsing from a gzip file in Py2.6.
-    * Test suite fixes for libxml2 2.7.
-    * Resolver.resolve_string() did not work for non-ASCII byte strings.
-    * Resolver.resolve_file() was broken.
-    * Overriding the parser encoding didn't work for many encodings.


python-pmw-1.3.2-5.fc11
-----------------------

python-qpid-0.3.720585-1.fc11
-----------------------------
* Tue Nov 25 17:00:00 2008 Nuno Santos <nsantos at redhat.com> - 0.3.720585-1
- Rebased to svn rev 720585

* Tue Nov 18 17:00:00 2008 Nuno Santos <nsantos at redhat.com> - 0.3.718718-1
- Rebased to svn rev 718718


python-sphinx-0.5-1.fc11
------------------------
* Mon Nov 24 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 0.5-1
- Update to 0.5


python-zope-interface-3.5.0-1.fc11
----------------------------------
* Sat Nov 15 17:00:00 2008 Felix Schwarz <felix.schwarz at oss.schwarz.eu> 3.5.0-1
- update to 3.5.0


pytz-2008i-3.fc11
-----------------
* Tue Nov 18 17:00:00 2008 Jef Spaleta <jspaleta at fedoraproject dot org> 2008i-3
- Apply patch correctly.

* Thu Nov 13 17:00:00 2008 Jef Spaleta <jspaleta at fedoraproject dot org> 2008i-2
- Updated tzdata patch from Petr Machata bug 471014

* Tue Nov 11 17:00:00 2008 Jef Spaleta <jspaleta at fedoraproject dot org> 2008i-1
- Update to latest, now using timezone files provided by tzdata package


qgit-2.2-2.fc11
---------------
* Tue Nov 25 17:00:00 2008 Dan Horak <dan[at]danny.cz> 2.2-2
- shorten Summary


ql23xx-firmware-3.03.27-1.fc11
------------------------------
* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 3.03.27-1
- update to 3.03.27


ql2400-firmware-4.04.05-1.fc11
------------------------------
* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 4.04.05-1
- update to 4.04.05


ql2500-firmware-4.04.05-1.fc11
------------------------------
* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 4.04.05-1
- update to 4.04.05


qscintilla-2.3.2-1.fc11
-----------------------
* Mon Nov 17 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 2.3.2-1
- Qscintilla-gpl-2.3.2
- soname bump 4->5

* Mon Nov 10 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 2.3.1-1
- Qscintilla-gpl-2.3.1


quassel-0.3.0.3-1.fc11
----------------------

quota-3.16-7.fc11
-----------------
* Fri Nov 14 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> 1:3.16-7
- fix quotaoff --help output (was same as quotaon output)

* Thu Oct 30 18:00:00 2008 Ondrej Vasik <ovasik at redhat.com> 1:3.16-6
- fix implementation of ext4 support
  (by Mingming Cao, #469127)


rarian-0.8.1-3.fc11
-------------------
* Sat Nov 22 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 0.8.1-3
- Shorten the summary.

* Mon Nov 10 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 0.8.1-2
- Add patch for RH bug #453342 (OMF category parsing).


rcssserver-13.0.1-1.fc11
------------------------
* Wed Nov 19 17:00:00 2008 Hedayat Vatankhah <hedayat at grad.com> 13.0.1-1
- Bump to 13.0.1 version.

* Wed Nov  5 17:00:00 2008 Hedayat Vatankhah <hedayat at grad.com> 13.0.0-1
- Update the package to the new versoin
- Obsoletes rcssbase as it is included in rcssserver


redet-doc-8.25-1
----------------
* Sun Oct 12 18:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 8.25-1
- Version bump to 8.25.

* Sun Nov 25 17:00:00 2007 Debarshi Ray <rishi at fedoraproject.org> - 8.23-2
- Removed dist tag.
- Removed 'Requires: redet ...'.

* Sun Nov 25 17:00:00 2007 Debarshi Ray <rishi at fedoraproject.org> - 8.23-1
- Initial build.


redhat-menus-10.0.1-1.fc11
--------------------------

referencer-1.1.5-2.fc11
-----------------------
* Thu Nov 20 17:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 1.1.5-2
- BR intltool

* Thu Nov 20 17:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 1.1.5-1
- Update to 1.1.5


rootfiles-8.1-2.fc11
--------------------
* Fri Oct 31 18:00:00 2008 Ondrej Vasik <ovasik at redhat.com> - 8.1-2
- Add dist tag, fix a few rpmlint issues, rebuild due to
  wrong vendor (#451229)
- Added ncurses requirement(#469390)


roundup-1.4.6-1.fc11
--------------------

rp-pppoe-3.10-1.fc11
--------------------
* Tue Nov 11 17:00:00 2008 Than Ngo <than at redhat.com> 3.10-1
- 3.10


rpcbind-0.1.7-1.fc11
--------------------
* Wed Nov 19 17:00:00 2008 Steve Dickson <steved at redhat.com>  0.1.7-1
- Update to latest upstream release: 0.1.7

* Tue Sep 30 18:00:00 2008 Steve Dickson <steved at redhat.com>  0.1.6-3
- Fixed a typo in the rpcbind.init script that stop warm starts
  from happening with conrestarts
- Fixed scriptlet failure (bz 462533)


rtorrent-0.8.3-1.fc11
---------------------
* Tue Nov 18 17:00:00 2008 Conrad Meyer <konrad at tylerc.org> - 0.8.3-1
- Bump version.


ruby-RMagick-2.7.2-1.fc11
-------------------------
* Wed Nov 19 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.7.2-1
- 2.7.2

* Wed Nov  5 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.7.1-1
- 2.7.1


ruby-gnome2-0.18.1-1.fc11
-------------------------
* Thu Nov 13 17:00:00 2008 Allisson Azevedo <allisson at gmail.com> 0.18.1-1
- Update to 0.18.1


ruby-libvirt-0.1.0-2.fc11
-------------------------
* Tue Nov 18 17:00:00 2008 David Lutterkort <lutter at redhat.com> - 0.1.0-2
- Added test-sort-list.patch to fix fragile test

* Tue Nov 18 17:00:00 2008 David Lutterkort <lutter at redhat.com> - 0.1.0-1
- Remove no-capabilities-test.patch, since it's upstream now


ruby-mechanize-0.8.5-1.fc11
---------------------------
* Wed Nov 26 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.8.5-1
- 0.8.5


ruby-qpid-0.3.720585-1.fc11
---------------------------
* Tue Nov 25 17:00:00 2008 Nuno Santos <nsantos at redhat.com> - 0.3.720585-1
- Rebased to svn rev 720585

* Fri Nov 14 17:00:00 2008 Rafael Schloming <rafaels at redhat.com> - 0.2-1
- Updated to work with qpid M4.


rubygem-activerecord-2.2.2-1.fc11
---------------------------------
* Mon Nov 24 17:00:00 2008 Jeroen van Meeuwen <kanarip at fedoraproject.org> - 2.2.2-1
- New upstream version
- Fixed rpmlint errors zero-length files and script-without-shebang

* Thu Nov 20 17:00:00 2008 David Lutterkort <lutter at redhat.com> - 2.1.1-2
- Do not mark lib/ as doc


rubygem-activesupport-2.2.2-1.fc11
----------------------------------
* Mon Nov 24 17:00:00 2008 Jeroen van Meeuwen <kanarip at fedoraproject.org> - 2.2.2-1
- New upstream version


rubygem-fastthread-1.0.1-1.fc11
-------------------------------
* Sat Nov  8 17:00:00 2008 Jeroen van Meeuwen <j.van.meeuwen at ogd.nl> - 1.0.1-1
- New upstream version


rubygem-gem_plugin-0.2.3-1.fc11
-------------------------------
* Sat Nov  8 17:00:00 2008 Jeroen van Meeuwen <j.van.meeuwen at ogd.nl> - 0.2.3-1
- New upstream version


rubygem-mongrel-1.1.5-1.fc11
----------------------------
* Sat Nov  8 17:00:00 2008 Jeroen van Meeuwen <j.van.meeuwen at ogd.nl> - 1.1.5-1
- New upstream version (bugfixes)


rubygem-pam-1.5.3-1.fc11
------------------------

rxtx-2.1-0.2.7r2.fc11
---------------------

rxvt-unicode-9.06-1.fc11
------------------------
* Sun Nov 23 17:00:00 2008 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 9.06-1
- version upgrade


s3cmd-0.9.8.4-1.fc11
--------------------
* Tue Nov 11 17:00:00 2008 Lubomir Rintel (Good Data) <lubo.rintel at gooddata.com> - 0.9.8.4.1
- New upstream release, URI encoding patch upstreamed


sblim-cmpi-devel-1.0.5-2.fc11
-----------------------------
* Tue Nov  4 17:00:00 2008 Vitezslav Crhonek <vcrhonek at redhat.com> - 1.0.5-2
- Fix License
- Spec file cleanup, rpmlint check


sblim-testsuite-1.2.5-2.fc11
----------------------------
* Tue Nov  4 17:00:00 2008 Vitezslav Crhonek <vcrhonek at redhat.com> - 1.2.5-2
- Remove debug package, fix URL, make setup quiet
- Spec file cleanup, rpmlint check


sblim-wbemcli-1.6.0-2.fc11
--------------------------
* Tue Nov  4 17:00:00 2008 Vitezslav Crhonek <vcrhonek at redhat.com> - 1.6.0-2
- Fix License
- Spec file cleanup, rpmlint check


scala-2.7.2-1.fc11
------------------
* Sun Nov  9 17:00:00 2008 Geoff Reedy <geoff at programmer-monk.net> - 2.7.2-1
- update to 2.7.2 final

* Mon Nov  3 17:00:00 2008 Geoff Reedy <geoff at programmer-monk.net> - 2.7.2-0.3.RC6
- bump release to fix upgrade path

* Sat Nov  1 18:00:00 2008 Geoff Reedy <geoff at programmer-monk.net> - 2.7.2-0.1.RC6
- update to 2.7.2-RC6

* Thu Oct 30 18:00:00 2008 Geoff Reedy <geoff at programmer-monk.net> - 2.7.2-0.1.RC5
- update to 2.7.2-RC5


scim-anthy-1.2.6-2.fc11
-----------------------
* Fri Nov 21 17:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 1.2.6-2
- Fix a source URL.


scim-array-1.0.1-0.fc11
-----------------------
* Wed Nov 26 17:00:00 2008 Ding-Yi Chen <dchen at redhat dot com> - 1.0.1-0
- Upstream update to 1.0.1


scim-bridge-0.4.15-8.fc11
-------------------------

scim-chewing-0.3.2-1.fc11
-------------------------
* Tue Nov 11 17:00:00 2008 Ding-Yi Chen <dchen at redhat dot com> - 0.3.2-1
- Upstream update.


scrub-2.1-1.fc11
----------------
* Fri Nov 14 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2.1-1
- update to 2.1


sdcc-2.8.0-3.fc11
-----------------
* Thu Nov 13 17:00:00 2008 Conrad Meyer <konrad at tylerc.org> - 2.8.0-3
- Separate out emacs-sdcc subpackage.


seahorse-2.25.1-1.fc11
----------------------
* Thu Nov 13 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> 2.25.1-1
- Update to 2.25.1


seahorse-plugins-2.25.1-1.fc11
------------------------------
* Thu Nov 13 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> 2.25.1-1
- Update to 2.25.1


sed-4.1.5-11.fc11
-----------------
* Thu Nov 13 17:00:00 2008 Jiri Moskovcak <jmoskovc at redhat.com> 4.1.5-11
- improved follow.patch (thanks to Arkadiusz Miskiewicz for initial patch)
- Resolves: #470912


setup-2.7.4-3.fc11
------------------
* Wed Nov 19 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> 2.7.4-3
- update protocols to latest IANA list (2008-04-18)
- update services to latest IANA list (2008-11-17)
- mark /etc/protocols and /etc/inputrc %config(noreplace)
- added URL, fixed few rpmlint warnings
- do own audio and video group (#458843), create it in default
  /etc/group

* Tue Nov 18 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> 2.7.4-2
- again process profile.d scripts in noninteractive shells,
  but do not display stderr/stdout messages(#457243)
- fix wrong prompt for csh/tcsh (#443854)
- don't show error message about missing hostname in profile
  (#301481)
- reserve rquotad port 875 in /etc/services (#455859)
- export PATH after processing profile.d scripts (#449286)
- assign gid's for audio (:63) and video (:39) group(#458843),
  assign uidgid pair (52:52) for puppet (#471918)
- fix /etc/services duplicities to pass serviceslint


shorewall-4.2.2-1.fc11
----------------------
* Mon Nov 24 17:00:00 2008 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 4.2.2-1
- Update to version 4.2.2
- Remove patch patch-perl-4.2.1.1

* Fri Oct 31 18:00:00 2008 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 4.2.1-2
- Added upstream patch patch-perl-4.2.1.1

* Sun Oct 26 18:00:00 2008 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 4.2.1-1
- Update to version 4.2.1
- Correct source URLs


sip-4.7.9-1.fc11
----------------
* Mon Nov 17 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.7.9-1
- sip-4.7.9

* Mon Nov 10 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.7.8-1
- sip-4.7.8


sl-3.03-7.fc11
--------------
* Tue Nov 18 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 3.03-7
- fix license tag (Freely redistributable without restriction is only 
  for firmware)


slapi-nis-0.9-1.fc11
--------------------
* Fri Nov  7 17:00:00 2008 Nalin Dahyabhai <nalin at redhat.com> - 0.9-1
- update to 0.9


smolt-1.1.1.1-9.fc11
--------------------

snobol-4.1.1-7.fc11
-------------------
* Mon Nov 24 17:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> 4.1.1-7
- Reworking the summary of the package


sound-juicer-2.25.1-1.fc11
--------------------------
* Sun Nov 23 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.25.1-1
- Update to 2.25.1


sox-14.2.0-1.fc11
-----------------
* Mon Nov 24 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 14.2.0-1
- 14.2.0

* Mon Nov 24 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 14.1.0-7.20081105cvs
- patch for newer libtool

* Mon Nov 24 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 14.1.0-6.20081105cvs
- rebuild for libtool


spin-kickstarts-0.10.2-1.fc11
-----------------------------

sqlite-3.6.4-1.fc11
-------------------
* Sat Nov  8 17:00:00 2008 Panu Matilainen <pmatilai at redhat.com> - 3.6.4-1
- update to 3.6.4
- drop patches already upstream


srecord-1.45-1.fc11
-------------------
* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.45-1
- update to 1.45


stratagus-2.2.4-5.fc11
----------------------
* Thu Nov 20 17:00:00 2008 Peter Lemenkov <lemenkov at gmail.com> 2.2.4-5
- Fixed links
- Cosmetic cleanups


straw-0.27-14.fc11
------------------
* Thu Nov 20 17:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> - 0.27-14
- Include egg-info file into package
- Add gnome-python2-gnome as BR and Req.

* Mon Jul  7 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.27-13
- fix conditional comparison


subversion-api-docs-1.5.4-1.fc11
--------------------------------
* Mon Nov  3 17:00:00 2008 Bojan Smojver <bojan at rexursive.com> 1.5.4-1
- bump up to 1.5.4


sugar-0.83.2-4.fc11
-------------------

sugar-artwork-0.83.1-1.fc11
---------------------------
* Tue Nov  4 17:00:00 2008 Marco Pesenti Gritti <mpg at redhat.com> - 0.83.1-1
- Update to 0.83.1


sugar-base-0.83.1-1.fc11
------------------------

sugar-datastore-0.83.0-1.fc11
-----------------------------
* Tue Nov  4 17:00:00 2008 Marco Pesenti Gritti <mpg at redhat.com> - 0.83.1-1
- Update to 0.83.1


sugar-moon-8-2.fc11
-------------------

sugar-presence-service-0.83.1-1.fc11
------------------------------------
* Tue Nov  4 17:00:00 2008 Marco Pesenti Gritti <mpg at redhat.com> - 0.83.1-1
- Update to 0.83.1


sugar-toolkit-0.83.1-2.fc11
---------------------------

sunbird-0.9-4.fc11
------------------
* Mon Nov 24 17:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> 0.9-4
- Disable lightning on EL-5 ppc, since there's no Desktop with thunderbird
- Fix summary


swfdec-0.9.2-1.fc11
-------------------
* Tue Nov 11 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.9.2-1
- Update to 0.9.2.


swfdec-mozilla-0.9.2-1.fc11
---------------------------
* Tue Nov 11 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.9.2-1
- Update to 0.8.2.


swig-1.3.36-1.fc11
------------------
* Mon Nov 10 17:00:00 2008 Adam Tkac <atkac redhat com> 1.3.36-1
- updated to 1.3.36
- finally dropped swig-arch.patch
- temporary workaround rpm bug #470811


sylpheed-2.6.0-0.1.beta2.fc11
-----------------------------
* Mon Nov 17 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 2.6.0-0.1.beta2
- update to 2.6.0beta2

* Tue Sep 30 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 2.6.0-0.1.beta1
- update to 2.6.0beta1


system-config-keyboard-1.2.15-5.fc11
------------------------------------
* Wed Nov 12 17:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> - 1.2.15-5
- Include icon in anaconda keyboard selection screen (#469165)
- Remove extension from desktop entry icon


system-config-printer-1.0.11-1.fc11
-----------------------------------
* Fri Nov 21 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 1.0.11-1
- Updated to 1.0.11.
- Updated pycups to 1.9.43.

* Wed Nov 12 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 1.0.10-2
- Updated to 1.0.10.  Applied patch from git.
- Applied pycups patch from git.


system-config-samba-1.2.67-1.fc11
---------------------------------

system-config-services-0.99.28-1.fc11
-------------------------------------
* Thu Nov 20 17:00:00 2008 Nils Philippsen <nils at redhat.com> - 0.99.28-1
- improve fixing runlevels hookable set updates
- pick up updated translations


systemtap-0.8-1.fc11
--------------------

taglib-sharp-2.0.3.0-7.fc11
---------------------------

tar-1.20-5.fc11
---------------
* Fri Nov 21 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> 2:1.20-5
- fix off-by-one errors in xattrs patch (#472355)

* Mon Nov 10 17:00:00 2008 Kamil Dudka <kdudka at redhat.com> 2:1.20-4
- fixed bug #465803: labels with --multi-volume (upstream patch)


tasks-0.14-2.fc11
-----------------
* Mon Nov 24 17:00:00 2008 Dan Young <dyoung at mesd.k12.or.us> - 0.14-2
- Fix poor summary and description

* Tue Sep 30 18:00:00 2008 Dan Young <dyoung at mesd.k12.or.us> - 0.14-1
- New upstream release


tcl-8.5.5-1.fc11
----------------
* Wed Nov 19 17:00:00 2008 Marcela Maslanova <mmaslano at redhat.com> - 1:8.5.5-1
- update to 8.5.5


tcl-html-8.5.5-1.fc11
---------------------
* Wed Nov 19 17:00:00 2008 Marcela Maslanova <mmaslano at redhat.com> - 8.5.5-1
- update to 8.5.5


teamgit-0.0.8-1.fc11
--------------------
* Sun Nov 23 17:00:00 2008 Terje Rosten <terje.rosten at ntnu.no> - 0.0.8-1
- 0.0.8
- add man page
- icon has moved
- remove %post scripts


telepathy-gabble-0.7.15-1.fc11
------------------------------
* Fri Nov  7 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.7.15-1
- Update to 0.7.15.


telepathy-glib-0.7.18-1.fc11
----------------------------
* Fri Nov  7 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.7.18-1
- Update to 0.7.18.


telepathy-sofiasip-0.5.11-1.fc11
--------------------------------
* Fri Nov  7 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.5.11-1
- Update to 0.5.11.


tempest-0-0.7.20081027.fc11
---------------------------
* Fri Nov 21 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0-0.7.20081027
- Upstream tarball slightly changed


texinfo-4.13a-1.fc11
--------------------
* Thu Nov 20 17:00:00 2008 Vitezslav Crhonek <vcrhonek at redhat.com> - 4.13-1
- Update to texinfo-4.13a
  Resolves: #471194
  Resolves: #208511


texlive-2007-39.fc11
--------------------
* Tue Nov 11 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2007-39
- Rebuild against new poppler
- Update poppler patch to remove references to xpdfVersion


texmaker-1.8-1.fc11
-------------------
* Thu Nov 20 17:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 1.8-1
- New Release


tftp-0.49-1.fc11
----------------
* Tue Nov 25 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.49-1
- update to 0.49


tgif-4.1.45-8.fc11
------------------
* Sat Nov 15 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 4.1.45-8
- Add fonts Requirement against xorg-x11-fonts-ISO8859-1-75dpi


tinyproxy-1.6.4-3.fc11
----------------------
* Sat Nov 22 17:00:00 2008 Jeremy Hinegardner <jeremy at hinegardner dot org> - 1.6.4-3
- add --enable-transparent-proxy option (#466808)


tk-8.5.5-4.fc11
---------------
* Wed Nov 19 17:00:00 2008 Marcela Maslanova <mmaslano at redhat.com> - 1:8.5.5-1
- update to 8.5.5


tkimg-1.4-0.1.20081115svn.fc11
------------------------------
* Sat Nov 15 17:00:00 2008 Sergio Pascual <sergiopr at fedoraproject.org>  1.4-0.1.20081115svn
- New upstream source, version 173 from trunk, release 1.4
- Relative links in libdir
- Removed ignored disable-static option in configure
- Patches simplified and separated by library


tog-pegasus-2.7.2-2.fc11
------------------------
* Tue Nov 11 17:00:00 2008 Vitezslav Crhonek <vcrhonek at redhat.com> - 2:2.7.2-2
- Fix local or remote auth patch to work correctly with new code base
  Related: #459217

* Thu Nov  6 17:00:00 2008 Vitezslav Crhonek <vcrhonek at redhat.com> - 2:2.7.2-1
- Update to upstream version 2.7.2
  (remove patches added in 2.7.1-1 - they're upstream now)
- Enable out-of-process providers
  Resolves: #455109


toped-0.9.2-2.fc11
------------------
* Mon Nov 10 17:00:00 2008 Chitlesh Goorah <chitlesh at fedoraproject.org> - 0.9.2-2
- disabling rpath
- fixing rpmlint warning: unused-direct-shlib-dependencies
- fixed multiple menu entries

* Mon Nov 10 17:00:00 2008 Chitlesh Goorah <chitlesh at fedoraproject.org> - 0.9.2-1
- New upstream release


totem-pl-parser-2.24.2-2.fc11
-----------------------------
* Fri Nov 14 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.24.2-2
- Rebuild


trac-0.11.2.1-2.fc11
--------------------
* Tue Nov 18 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.11.2.1-2
- Upload new sources
- Add new files to CVS

* Tue Nov 18 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.11.2.1-0.1
- Update to 0.11.2.1

* Mon Jun 23 18:00:00 2008 Ryan B. Lynch <ryan.b.lynch at gmail.com> - 0.11-1
- Update to 0.11


translate-toolkit-1.2.0-3.fc11
------------------------------
* Mon Nov 17 17:00:00 2008 Dwayne Bailey <dwayne at translate.org.za> - 1.2.0-3
- Rebuild using %{ix86} instead of i386

* Mon Nov 17 17:00:00 2008 Dwayne Bailey <dwayne at translate.org.za> - 1.2.0-2
- python-psyco is only available on i386

* Wed Nov 12 17:00:00 2008 Dwayne Bailey <dwayne at translate.org.za> - 1.2.0-1
- Update to 1.2.0
- Patch poterminology to read stoplist-en from /usr/share/
- Add devel package to include generated Translate Toolkit API documentation
- Add dependencies: python-iniparse, python-Levenshtein, python-lxml,
  python-psyco, python-vobject, gettext-libs


tree-1.5.2.1-2.fc11
-------------------
* Mon Nov 24 17:00:00 2008 Tim Waugh <twaugh at redhat.com> 1.5.2.1-2
- Better summary.


tsclient-2.0.1-9.fc11
---------------------
* Thu Nov 13 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.0.1-9
- Rebuild


twitux-0.65-1.fc11
------------------
* Tue Nov 11 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.65-1
- Update to 0.65.


tzdata-2008i-1.fc11
-------------------
* Thu Oct 30 18:00:00 2008 Petr Machata <pmachata at redhat.com> - 2008i-1
- Upstream 2008i
  - Updates for Argentina: Drop DST in zones America/Argentina/Jujuy,
    La_Rioja, San_Juan, Catamarca, Mendoza, Rio_Gallegos, Ushuaia; new
    zone America/Argentina/Salta (for provinces SA, LP, NQ, RN).


ucblogo-6.0-3.fc11
------------------
* Sat Nov 22 17:00:00 2008 Gerard Milmeister <gemi at bluewin.ch> - 6.0-2
- re-add emacs logo-mode from previous release as a separate package

* Thu Nov 20 17:00:00 2008 Gerard Milmeister <gemi at bluewin.ch> - 6.0-1
- new release 6.0


udev-133-1.fc11
---------------
* Wed Nov 19 17:00:00 2008 Harald Hoyer <harald at redhat.com> 133-1
- version 133


ultimatestunts-0.7.5-2.fc11
---------------------------
* Tue Nov 25 17:00:00 2008 Dan Horak <dan[at]danny.cz> 0.7.5-2
- shorten Summary


unique-1.0.4-1.fc11
-------------------
* Mon Nov 24 17:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 1.0.4-1
- Update to latest upstream version
 * Plug a leak in UniqueMessageData
 * Fix linking with --as-needed
 * Do not export private functions symbols

* Sat Nov 22 17:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 1.0.0-2
- Fix up summary text


usermode-1.99-1
---------------
* Tue Nov 11 17:00:00 2008 Miloslav Trma?? <mitr at redhat.com> - 1.99-1
- Update to usermode-1.99
  Resolves: #470834

* Thu Nov  6 17:00:00 2008 Miloslav Trma?? <mitr at redhat.com> - 1.98.1-2
- Hide usermount from GNOME and KDE menus
  Resolves: #440029
- Only hide userinfo and userpasswd in GNOME and KDE


util-linux-ng-2.14.1-5.fc11
---------------------------
* Fri Nov 21 17:00:00 2008 Karel Zak <kzak at redhat.com> 2.14.1-5
- fix #472502 - problem with fdisk and use +sectors for the end of partition


uucp-1.07-18.fc11
-----------------
* Tue Nov 25 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> 1.07-18
- remove uucp name from summary, generalize summary as there
  are other utilities in uucp set


vala-0.5.1-1.fc11
-----------------
* Sun Nov 23 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 0.5.1-1
- Update to 0.5.1


varnish-2.0.2-1.fc11
--------------------
* Mon Nov 10 17:00:00 2008 Ingvar Hagelund <ingvar at linpro.no> - 2.0.2-1
New upstream release 2.0.2. A bugfix release

* Sun Nov  2 17:00:00 2008 Ingvar Hagelund <ingvar at linpro.no> - 2.0.1-2
- Removed the requirement for kernel => 2.6.0. All supported
  platforms meets this, and it generates strange errors in EPEL


vdr-1.6.0-15.fc11
-----------------
* Sun Nov 23 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 1.6.0-15
- Reorganize dir structure for better Fedora guidelines compliance (#443706):
  /var/lib/vdr/* -> /var/lib/vdr/data, /srv/video -> /var/lib/vdr/video.
- Drop audiodir and ownership of /srv/audio, examples still point to it.

* Sat Nov 22 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 1.6.0-8
- Fix setting wakeup time via rtc0 when hardware clock is localtime.
- Drop remote plugin examples from udev rules, they're in vdr-remote now.

* Tue Oct 28 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 1.6.0-7
- Fix setting wakeup time via /proc/acpi/alarm when hardware clock is UTC.

* Thu Sep 25 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 1.6.0-6
- README.package updates.
- Specfile micro-cleanups.


vdr-skins-20081124-1.fc11
-------------------------
* Mon Nov 24 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 20081124-1
- Update enElchi to 0.7.2.
- Catch up again with latest dejavu-fonts changes.


vdr-skinsoppalusikka-1.6.2-2.fc11
---------------------------------
* Mon Nov 24 17:00:00 2008 - Ville-Pekka Vainio <vpivaini AT cs.helsinki.fi> 1.6.2-2
- Rebuild for VDR 1.6.0-15.fc11


vdr-ttxtsubs-0.0.5-6.fc11
-------------------------
* Mon Nov 24 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.0.5-6
- Rebuild.


veusz-1.2-3.fc11
----------------
* Tue Nov 25 17:00:00 2008 Jeremy Sanders <jeremy at jeremysanders.net> - 1.2-3
- Fix bug in icon symlink

* Tue Nov 25 17:00:00 2008 Jeremy Sanders <jeremy at jeremysanders.net> - 1.2-2
- Fix move of icon location

* Tue Nov 25 17:00:00 2008 Jeremy Sanders <jeremy at jeremysanders.net> - 1.2-1
- Move to Veusz 1.2


viewvc-1.1.0-0.beta1.1.fc11
---------------------------
* Thu Nov  6 17:00:00 2008 Bojan Smojver <bojan at rexursive.com> - 1.1.0-0.beta1.1
- Rebase to 1.1.x


vpnc-0.5.3-2.fc11
-----------------
* Thu Nov 20 17:00:00 2008 Tomas Mraz <tmraz at redhat.com> - 0.5.3-2
- upgrade to new version
- fix race in vpnc-cleanup (#465315)


w3c-markup-validator-0.8.4-1
----------------------------
* Sat Nov 22 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.8.4-1
- 0.8.4 + upstream doctype override fix.
- types.conf and error log trash patches applied upstream.


warzone2100-2.1.0-0.7.rc1.fc11
------------------------------
* Sun Nov 16 17:00:00 2008 Karol Trzcionka <karlikt at gmail.com> - 2.1.0-0.7.rc1
- Update to v2.1.0-rc1
- Fix typo in changelog
- Update License tag
- Fix game-crash while saving and loading (svn revision 6283)


widelands-0-0.12.Build13rc.fc11
-------------------------------
* Sun Nov 16 17:00:00 2008 Karol Trzcionka <karlikt at gmail.com> - 0-0.12.Build13rc
- Update to Build13rc
- Add %{?_smp_mflags}


wildmidi-0.2.2-6.fc11
---------------------
* Mon Nov 24 17:00:00 2008 Hans de Goede <j.w.r.degoede at hhs.nl> 0.2.2-6
- Fixup Summary


wine-1.1.9-2.fc11
-----------------
* Mon Nov 24 17:00:00 2008 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 1.1.9-2
- fix #469907

* Sun Nov 23 17:00:00 2008 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 1.1.9-1
- version upgrade


winpdb-1.4.2-1.fc11
-------------------
* Thu Nov 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.4.2-1
- update to 1.4.2, source moved to google code


wireshark-1.1.1-0.pre1.fc11
---------------------------
* Thu Nov 13 17:00:00 2008 Radek Vok??l <rvokal at redhat.com> 1.1.1-1
- upgrade to 1.1.1 development branch


wormux-0.8.2-1.fc11
-------------------
* Fri Nov  7 17:00:00 2008 Wart <wart at kobold.org> 0.8.2-1
- Update to 0.8.2


writer2latex-0.5.0.2-4.fc11
---------------------------
* Sun Nov 23 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> 0.5.0.2-4
- tweak summary

* Thu Nov 20 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> 0.5.0.2-3
- upstream repacked tarballs to replace 0.5.0.1 with 0.5.0.2


wvdial-1.60-7.fc11
------------------
* Tue Nov 25 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> - 1.60-7
- new libwvstreams rebuild, removed -fno-rtti CPP_FLAG to
  compile correctly with new libwvstreams


xarchiver-0.5.2-2.fc11
----------------------
* Tue Nov 25 17:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.5.2-2
- Include HTML documentation

* Tue Nov 25 17:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.5.2-1
- Update to 0.5.2

* Sun Nov  9 17:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.5.1-1
- Update to 0.5.1 stable release

* Sun Oct 26 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.5.0-0.1.rc1
- Update to 0.5.0rc1
- Fix crash when opening zipped PDF files (#467619)
- Update gtk-icon-cache scriptlets

* Sat Oct 11 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.5.0-0.1.beta2
- Update to 0.5.0beta2

* Sun Aug 31 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.5.0-0.1.beta1
- Update to 0.5.0beta1
- Remove xdg-open.patch as xarchiver now uses xdg-open by default


xblast-data-2.10.0-4.fc11
-------------------------
* Sat Nov  8 17:00:00 2008 Hans de Goede <j.w.r.degoede at hhs.nl> 2.10.0-4
- Fix some filenames having iso-8859-1 enconding (rh 470527)


xchat-gnome-0.24.1-1.fc11
-------------------------
* Fri Nov 14 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.24.1-1
- Update to 0.24.1.
- Update Source URL.


xdg-utils-1.0.2-5.20081121cvs.fc11
----------------------------------
* Fri Nov 21 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 1.0.2-5.20081121cvs
- upstreamed a few more patches, rebase to cvs snapshot


xdvik-22.84.14-4.fc11
---------------------
* Wed Nov 12 17:00:00 2008 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 22.84.14-4
- Add patch to fix zero key handling (BZ 470942)
- Remove texlive-2007-xprint.patch which actually hasn't been applied during
  22.84.14 packaging


xfce4-mixer-4.4.3-2.fc11
------------------------
* Mon Oct 27 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 4.4.3-2
- Fix desktop file (bugzilla.xfce.org #4538)

* Mon Oct 27 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 4.4.3-1
- Update to 4.4.3
- Update gtk-update-icon-cache scriptlets
- Add xfce4-mixer menu entry in the Xfce menu


xfig-3.2.5-12.fc11
------------------
* Tue Nov  4 17:00:00 2008 Hans de Goede <hdegoede at redhat.com> 3.2.5-12
- Various small specfile cleanups from merge review


xfsdump-2.2.48-2.fc11
---------------------
* Wed Nov 12 17:00:00 2008 Eric Sandeen <sandeen at redhat.com> 2.2.48-2
- Enable parallel builds


xfsprogs-2.10.1-2.fc11
----------------------
* Wed Nov 12 17:00:00 2008 Eric Sandeen <sandeen at redhat.com> 2.10.1-2
- Recognize gfs/gfs2 in libdisk
- Enable parallel builds


xgridfit-1.11-1.a.fc11
----------------------
* Fri Nov 14 17:00:00 2008 <nicolas.mailhot at laposte.net>
- 1.11-1.a
??? update for F11 cycle


xkeyboard-config-1.4-7.fc11
---------------------------
* Mon Nov 24 17:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> - 1.4-7
- Switch to using git patches, modelled after xorg-x11-server.
- CVS remove unused patches.

* Sat Nov 22 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1.4-6
- Improve %summary and %description
- Better URL

* Thu Nov 13 17:00:00 2008 Peter Hutterer  <peter.hutterer at redhat.com> - 1.4-5
- xkeyboard-config-1.4-jp-tilde.patch: TLDE in jp is Zenkaku/Hankaku, and BKSL
  should be bracket right/brace right (#469537).


xlog-1.8.1-2.fc11
-----------------
* Sun Nov 23 17:00:00 2008 Lucian Langa <cooly at gnome.eu.org> - 1.8.1-2
- fix for RH #472619: drop mimeinfo.cache


xmlrpc-c-1.16.4-2.1567.fc11
---------------------------
* Sat Nov 15 17:00:00 2008 Enrico Scholz <enrico.scholz at informatik.tu-chemnitz.de> - 1.16.4.1567-2
- updated to 1.16.4
- rediffed/updated patches
- splitted some subpackages (c++, client) out of main package as they
  introduce additional dependencies (c++, curl)


xorg-x11-drv-evdev-2.1.0-1.fc11
-------------------------------
* Wed Nov 19 17:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 2.1.0-1
- evdev 2.1.0

* Tue Nov  4 17:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 2.0.99.3-1
- evdev 2.0.99.3 (evdev 2.1 RC 3)

* Fri Oct 24 18:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 2.0.99.2-1
- evdev 2.0.99.2 (evdev 2.1 RC 2)


xorg-x11-drv-i810-2.5.0-3.fc11
------------------------------

xorg-x11-drv-openchrome-0.2.903-2.fc11
--------------------------------------
* Fri Nov  7 17:00:00 2008 Xavier Bachelot <xavier AT bachelot DOT org> - 0.2.903-2
- Update to latest snapshot (svn 685), most notably add basic VX800 support.
- Turn on full debugging.


xorg-x11-drv-radeonhd-1.2.3-1.5.20081112git.fc11
------------------------------------------------
* Wed Nov 12 17:00:00 2008 Hans Ulrich Niedermann <hun at n-dimensional.de> - 1.2.3-1.5.20081112git
- New snapshot (upstream commit 53dd35cb766138c879c926a8374380174e876d35):
  - 53dd35cb: DRI: Exit RHDDRIScreenInit() with FALSE when init failed.
  - a2fa612c: RandR: Bracket block properly.
  - fe4356ce: DRI: SwapContext: Stop wanton XAA syncs.
  - bb14c00c: Add RV730/710 PCI Ids.
  - ac56b4c8: ASIC_Support: Add AtomBIOS support for RV730/710 chipsets.
  - 57f11067: I2C: Add additional I2C lines for for DCE3.2 support.
  - 30f4bf2b: MC: RV770 code also supports generations beyond this.
  - 680f05ac: AtomBIOS/Backlight Control: Fix AtomBIOS based BL control for hardcoded outputs.
  - d125c0fa: DIG: Add debug output for EncoderPower().
  - 264a8b5f: DIG: Fix SEGFAULT with new coherent option.
  - db72b6a5: Coherent: Update man page to match Christian Koenig's fixes to the option parser.
  - 36657dc3: Use RhdParseBooleanOption for ignoreconnector config option
  - 2e3590da: Use RhdParseBooleanOption for HDMI config option
  - 908fabd6: DIG: Add RHD_OPTION_NOT_SET to dig outputs.
  - 08fedbb6: Fix and improve RhdParseBooleanOption.
  - 3036b40f: Output/Coherent: Fix bug in parser, add man page.
  - 75b4f1d2: Don't allocate framebuffer for cursor images if software cursor is used.
  - f29a3d2f: DIG: Don't disable encoders which are assigned to active connectors.
  - 72aaf9bd: DRI: Keep rhdDri struct for server lifetime.
  - c3e4ef7f: MC: Consolidate rhdAllIdle() and RHDModePrepare().
  - ec67c56c: Move MC setup before DRI init. Fixes issues DRI issues on some systems.
  - 8676c233: DIG: Add debug output to inform about probed encoder mappings.
  - 6e40d3b9: Add config option for coherent settings on digital outputs.
  - 6b76953c: Option: Add handling for option containing a string of boolean settings.
  - 9ca2384d: BIOSScratch: Treat DAC SENSED_NONE as CRTC output.
  - 1292ab01: Option: Add handling for option containing a string of boolean settings.

* Wed Oct 29 18:00:00 2008 Hans Ulrich Niedermann <hun at n-dimensional.de> - 1.2.3-1.3.20081029git
- README.fedora: How to adapt xorg.conf to use radeonhd
- New snapshot (upstream commit a36896dd0b44a26816ac0a401c0d9918a100d624):
  - a36896dd: AtomBIOS/Output: consolidated handling on UNIPHYA and UNIPHYB.
  - e3c56962: EXA: Move inlcusion of exa.h before xf86_ansic.h.
  - c38be243: DCE3.0: Properly map DCE3.0 DIG encoders.
  - 9e81b2cc: ID: Add PCI ID 0x95C6.
  - e589cc35: Update README and man page only if sed is OK
  - 7880b5a9: Manpage: Add Christian Koenig to the list of authors.
  - d88f685c: Fix README update on FreeBSD (sed substitution)
  - 01152def: Imake: Fix build for xvideo and hdmi audio.
  - 1e26e7a7: Autoconf: Fix RandR12 changes.
  - 0ea65a3a: Reorder source file list alphabetically
  - 3ac30d19: HDMI: Add HDMI support.
  - 69d4dabe: Autoconf: Fix build on Ubuntu Feisty Fawn.
  - 15f0b2a8: [PATCH] Link with -lpciaccess and -ldrm as needed
  - b77f9a77: autoconf: Add glproto as a dependency for DRI.
  - dff3e283: gitignore: Add some distcheck files.
  - efaebb70: Cleanup SEGV_ON_ASSERT in HAVE_XF86_ANSIC_H case.
  - 29cd7382: R5xx3D: Disable XHas3DEngineState upon VT switch.
  - 0a9a206a: CS: Remove Mask member.
  - 3f558efc: AtomBIOS: Make deviceID override table actually work.


xorg-x11-drv-synaptics-0.99.1-1.fc11
------------------------------------
* Fri Nov 14 17:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 0.99.1-1
- synaptics 1.0 RC 1

* Tue Oct 14 18:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 0.15.99-0.2
- add the make-git-snapshot script.

* Tue Oct 14 18:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 0.15.99-0.1
- Today's git snapshot.
- Add devel subpackage.
- remove xf86-input-synaptics-0.15.2-maxtapmove.patch: driver autoscales now.


xorg-x11-drv-vmmouse-12.6.2-1.fc11
----------------------------------
* Mon Nov 17 17:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 12.6.2-1
- vmmouse 12.6.2


xorg-x11-proto-devel-7.4-7.fc11
-------------------------------
* Thu Nov 20 17:00:00 2008 Adam Jackson <ajax at redhat.com> 7.4-7
- Fix (delete) dri2proto URL.

* Tue Nov 18 17:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 7.4-5
- x11proto-7.0.14-XF86XK_Suspend.patch: add XF86XK_Suspend and
  XF86XK_Hibernate to keysyms.

* Mon Nov 10 17:00:00 2008 Adam Jackson <ajax at redhat.com> 7.4-5
- Drop explicit virtual Provides, we get them for free from pkgconfig
- Drop some ancient upgrade Prov/Req/Obs


xscreensaver-5.07-3.fc11
------------------------
* Wed Nov 19 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1:5.07-3
- Create wrapper script for webcollage to use nonet option
  by default, and rename the original webcollage (bug 472061)


xvarstar-0.9-4.fc11
-------------------

ypbind-1.20.4-10.fc11
---------------------
* Mon Nov 24 17:00:00 2008 Vitezslav Crhonek <vcrhonek at redhat.com> - 3:1.20.4-10
- Last few Merge Review related changes
- Fix init script arguments and return values
  Resolves: #247104, #467861


yum-utils-1.1.18-2.fc11
-----------------------
* Tue Nov 25 17:00:00 2008 James Antill <james at fedoraproject.org>
- Fix the development/rawhide difference.


yumex-2.0.5-3.fc11
------------------
* Sun Nov 16 17:00:00 2008 Tim Lauridsen <tla at rasmil.dk> - 2.0.5-3
- bump release to make tag happy :(

* Sun Nov 16 17:00:00 2008 Tim Lauridsen <tla at rasmil.dk> - 2.0.5-2
- Forgot to change the version string :)

* Sat Nov 15 17:00:00 2008 Tim Lauridsen <tla at rasmil.dk> - 2.0.5-1
- Release 2.0.5


zhcon-0.2.6-12.fc11
-------------------
* Tue Nov 25 17:00:00 2008 Ding-Yi Chen <dchen at redhat dot com> - 0.2.6-12
- Debian provide patch of zhcon_0.2.6-5.2.diff.gz


zvbi-0.2.33-1.fc11
------------------
* Fri Nov 14 17:00:00 2008 Subhodip Biswas <subhodip at fedoraproject.org > -0.2.33-1
- Package update .

* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.2.30-2
- Fix Patch0:/%patch mismatch.


Summary:
Added Packages: 146
Removed Packages: 5
Modified Packages: 642
Broken deps for i386
----------------------------------------------------------
	autodir-0.99.9-5.fc9.i386 requires libltdl.so.3
	avant-window-navigator-0.2.6-9.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	bigboard-0.6.4-2.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(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	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(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	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(Random) = 0:9936935480b36bcbc716ee513f37876c
	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-gnome-0.7.8-3.fc11.i386 requires libgnome-desktop-2.so.7
	db4o-6.1-4.fc9.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	deskbar-applet-2.24.0-2.fc10.i386 requires libgnome-desktop-2.so.7
	desktop-data-model-1.2.5-1.fc10.i386 requires libgnome-desktop-2.so.7
	epdfview-0.1.6-4.fc10.i386 requires libpoppler-glib.so.3
	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-zimbra-0.1.1-3.fc10.i386 requires libcamel-1.2.so.14
	evolution-zimbra-0.1.1-3.fc10.i386 requires libcamel-provider-1.2.so.14
	foobillard-3.0a-8.fc10.i386 requires dejavu-fonts
	freeradius-2.1.1-2.fc10.i386 requires libltdl.so.3
	galeon-2.0.7-3.fc10.i386 requires libgnome-desktop-2.so.7
	gambas2-devel-2.9.0-1.fc10.i386 requires libltdl.so.3
	gambas2-gb-pdf-2.9.0-1.fc10.i386 requires libpoppler.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
	gnome-compiz-manager-0.10.4-4.fc10.i386 requires libgnome-desktop-2.so.7
	gnome-launch-box-0.4-10.fc10.i386 requires libgnome-desktop-2.so.7
	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
	inkscape-0.46-6.fc10.i386 requires libpoppler.so.3
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	kdebindings-4.1.2-2.fc10.i386 requires libqscintilla2.so.4
	kpackagekit-0.3.1-4.fc10.i386 requires libpackagekit-qt.so.10
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libp11-0.2.3-3.fc10.i386 requires libltdl.so.3
	mail-notification-evolution-plugin-5.4-4.fc10.i386 requires libcamel-1.2.so.14
	mail-notification-evolution-plugin-5.4-4.fc10.i386 requires libcamel-provider-1.2.so.14
	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
	mono-cecil-flowanalysis-0.1-0.6.20080409svn100264.fc11.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	mono-debugger-0.60-3.fc9.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	mono-tools-2.0-8.fc10.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	mysql-connector-odbc-3.51.26r1127-1.fc10.i386 requires libltdl.so.3
	mythes-nb-2.0.10-1.fc11.noarch requires mythes
	mythes-nn-2.0.10-1.fc11.noarch requires mythes
	nautilus-search-tool-0.2.2-4.fc10.i386 requires libgnome-desktop-2.so.7
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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(runtime) = 0:3.10.2
	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(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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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.10.fc10.i386 requires dejavu-fonts
	1:openoffice.org-pdfimport-3.0.0-9.10.fc10.i386 requires libpoppler.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
	padevchooser-0.9.4-0.6.svn20070925.fc10.i386 requires libgnome-desktop-2.so.7
	pdfcube-0.0.2-8.fc9.i386 requires libpoppler.so.3
	pdfcube-0.0.2-8.fc9.i386 requires libpoppler-glib.so.3
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts-experimental
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts
	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
	planner-eds-0.14.3-6.fc10.i386 requires libcamel-1.2.so.14
	planner-eds-0.14.3-6.fc10.i386 requires libcamel-provider-1.2.so.14
	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
	tellico-1.3.4-1.fc10.i386 requires libpoppler.so.3
	tracker-0.6.6-3.fc10.i386 requires libpoppler-glib.so.3
	tracker-search-tool-0.6.6-3.fc10.i386 requires libgnome-desktop-2.so.7
	wput-0.6.1-4.fc9.i386 requires libgnutls-openssl.so.13



Broken deps for x86_64
----------------------------------------------------------
	autodir-0.99.9-5.fc9.x86_64 requires libltdl.so.3()(64bit)
	avant-window-navigator-0.2.6-9.fc10.i386 requires libgnome-desktop-2.so.7
	avant-window-navigator-0.2.6-9.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	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)
	bigboard-0.6.4-2.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(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(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	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(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	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(Random) = 0:9936935480b36bcbc716ee513f37876c
	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-gnome-0.7.8-3.fc11.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	db4o-6.1-4.fc9.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	deskbar-applet-2.24.0-2.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	desktop-data-model-1.2.5-1.fc10.i386 requires libgnome-desktop-2.so.7
	desktop-data-model-1.2.5-1.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	epdfview-0.1.6-4.fc10.x86_64 requires libpoppler-glib.so.3()(64bit)
	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-zimbra-0.1.1-3.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	evolution-zimbra-0.1.1-3.fc10.x86_64 requires libcamel-provider-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)
	galeon-2.0.7-3.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	gambas2-devel-2.9.0-1.fc10.i386 requires libltdl.so.3
	gambas2-devel-2.9.0-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	gambas2-gb-pdf-2.9.0-1.fc10.x86_64 requires libpoppler.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)
	gnome-compiz-manager-0.10.4-4.fc10.i386 requires libgnome-desktop-2.so.7
	gnome-compiz-manager-0.10.4-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	gnome-launch-box-0.4-10.fc10.x86_64 requires libgnome-desktop-2.so.7()(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)
	inkscape-0.46-6.fc10.x86_64 requires libpoppler.so.3()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	kdebindings-4.1.2-2.fc10.i386 requires libqscintilla2.so.4
	kdebindings-4.1.2-2.fc10.x86_64 requires libqscintilla2.so.4()(64bit)
	kpackagekit-0.3.1-4.fc10.x86_64 requires libpackagekit-qt.so.10()(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)
	libp11-0.2.3-3.fc10.i386 requires libltdl.so.3
	libp11-0.2.3-3.fc10.x86_64 requires libltdl.so.3()(64bit)
	mail-notification-evolution-plugin-5.4-4.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	mail-notification-evolution-plugin-5.4-4.fc10.x86_64 requires libcamel-provider-1.2.so.14()(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)
	mono-cecil-flowanalysis-0.1-0.6.20080409svn100264.fc11.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	mono-debugger-0.60-3.fc9.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	mono-debugger-0.60-3.fc9.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	mono-tools-2.0-8.fc10.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	mysql-connector-odbc-3.51.26r1127-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	mythes-nb-2.0.10-1.fc11.noarch requires mythes
	mythes-nn-2.0.10-1.fc11.noarch requires mythes
	nautilus-search-tool-0.2.2-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(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(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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.10.fc10.x86_64 requires dejavu-fonts
	1:openoffice.org-pdfimport-3.0.0-9.10.fc10.x86_64 requires libpoppler.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)
	padevchooser-0.9.4-0.6.svn20070925.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	pdfcube-0.0.2-8.fc9.x86_64 requires libpoppler-glib.so.3()(64bit)
	pdfcube-0.0.2-8.fc9.x86_64 requires libpoppler.so.3()(64bit)
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts-experimental
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts
	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)
	planner-eds-0.14.3-6.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	planner-eds-0.14.3-6.fc10.x86_64 requires libcamel-provider-1.2.so.14()(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)
	tellico-1.3.4-1.fc10.x86_64 requires libpoppler.so.3()(64bit)
	tracker-0.6.6-3.fc10.i386 requires libpoppler-glib.so.3
	tracker-0.6.6-3.fc10.x86_64 requires libpoppler-glib.so.3()(64bit)
	tracker-search-tool-0.6.6-3.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	wput-0.6.1-4.fc9.x86_64 requires libgnutls-openssl.so.13()(64bit)



Broken deps for ppc
----------------------------------------------------------
	autodir-0.99.9-5.fc9.ppc requires libltdl.so.3
	avant-window-navigator-0.2.6-9.fc10.ppc requires libgnome-desktop-2.so.7
	avant-window-navigator-0.2.6-9.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	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)
	bigboard-0.6.4-2.fc10.ppc requires libgnome-desktop-2.so.7
	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(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	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(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	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(Random) = 0:9936935480b36bcbc716ee513f37876c
	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-gnome-0.7.8-3.fc11.ppc requires libgnome-desktop-2.so.7
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	deskbar-applet-2.24.0-2.fc10.ppc requires libgnome-desktop-2.so.7
	desktop-data-model-1.2.5-1.fc10.ppc requires libgnome-desktop-2.so.7
	desktop-data-model-1.2.5-1.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	epdfview-0.1.6-4.fc10.ppc requires libpoppler-glib.so.3
	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-zimbra-0.1.1-3.fc10.ppc requires libcamel-1.2.so.14
	evolution-zimbra-0.1.1-3.fc10.ppc requires libcamel-provider-1.2.so.14
	foobillard-3.0a-8.fc10.ppc requires dejavu-fonts
	freeradius-2.1.1-2.fc10.ppc requires libltdl.so.3
	galeon-2.0.7-3.fc10.ppc requires libgnome-desktop-2.so.7
	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)
	gnome-compiz-manager-0.10.4-4.fc10.ppc requires libgnome-desktop-2.so.7
	gnome-compiz-manager-0.10.4-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	gnome-launch-box-0.4-10.fc10.ppc requires libgnome-desktop-2.so.7
	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
	inkscape-0.46-6.fc10.ppc requires libpoppler.so.3
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	kdebindings-4.1.2-2.fc10.ppc requires libqscintilla2.so.4
	kdebindings-4.1.2-2.fc10.ppc64 requires libqscintilla2.so.4()(64bit)
	kpackagekit-0.3.1-4.fc10.ppc requires libpackagekit-qt.so.10
	libextractor-0.5.20b-2.fc10.ppc requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libp11-0.2.3-3.fc10.ppc requires libltdl.so.3
	libp11-0.2.3-3.fc10.ppc64 requires libltdl.so.3()(64bit)
	mail-notification-evolution-plugin-5.4-4.fc10.ppc requires libcamel-1.2.so.14
	mail-notification-evolution-plugin-5.4-4.fc10.ppc requires libcamel-provider-1.2.so.14
	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)
	mono-cecil-flowanalysis-0.1-0.6.20080409svn100264.fc11.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc requires libltdl.so.3
	mythes-nb-2.0.10-1.fc11.noarch requires mythes
	mythes-nn-2.0.10-1.fc11.noarch requires mythes
	nautilus-search-tool-0.2.2-4.fc10.ppc requires libgnome-desktop-2.so.7
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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(runtime) = 0:3.10.2
	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(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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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.10.fc10.ppc requires dejavu-fonts
	1:openoffice.org-pdfimport-3.0.0-9.10.fc10.ppc requires libpoppler.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)
	padevchooser-0.9.4-0.6.svn20070925.fc10.ppc requires libgnome-desktop-2.so.7
	pdfcube-0.0.2-8.fc9.ppc requires libpoppler.so.3
	pdfcube-0.0.2-8.fc9.ppc requires libpoppler-glib.so.3
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts-experimental
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts
	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
	planner-eds-0.14.3-6.fc10.ppc requires libcamel-1.2.so.14
	planner-eds-0.14.3-6.fc10.ppc requires libcamel-provider-1.2.so.14
	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
	tellico-1.3.4-1.fc10.ppc requires libpoppler.so.3
	tracker-0.6.6-3.fc10.ppc requires libpoppler-glib.so.3
	tracker-0.6.6-3.fc10.ppc64 requires libpoppler-glib.so.3()(64bit)
	tracker-search-tool-0.6.6-3.fc10.ppc requires libgnome-desktop-2.so.7
	wput-0.6.1-4.fc9.ppc requires libgnutls-openssl.so.13



Broken deps for ppc64
----------------------------------------------------------
	autodir-0.99.9-5.fc9.ppc64 requires libltdl.so.3()(64bit)
	avant-window-navigator-0.2.6-9.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	bigboard-0.6.4-2.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-gnome-0.7.8-3.fc11.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	deskbar-applet-2.24.0-2.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	desktop-data-model-1.2.5-1.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	epdfview-0.1.6-4.fc10.ppc64 requires libpoppler-glib.so.3()(64bit)
	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-zimbra-0.1.1-3.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	evolution-zimbra-0.1.1-3.fc10.ppc64 requires libcamel-provider-1.2.so.14()(64bit)
	foobillard-3.0a-8.fc10.ppc64 requires dejavu-fonts
	freeradius-2.1.1-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	galeon-2.0.7-3.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	gift-0.11.8.1-10.fc9.ppc64 requires libltdl.so.3()(64bit)
	gnome-compiz-manager-0.10.4-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	gnome-launch-box-0.4-10.fc10.ppc64 requires libgnome-desktop-2.so.7()(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)
	inkscape-0.46-6.fc10.ppc64 requires libpoppler.so.3()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	kdebindings-4.1.2-2.fc10.ppc64 requires libqscintilla2.so.4()(64bit)
	kpackagekit-0.3.1-4.fc10.ppc64 requires libpackagekit-qt.so.10()(64bit)
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libp11-0.2.3-3.fc10.ppc64 requires libltdl.so.3()(64bit)
	mail-notification-evolution-plugin-5.4-4.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	mail-notification-evolution-plugin-5.4-4.fc10.ppc64 requires libcamel-provider-1.2.so.14()(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)
	mythes-nb-2.0.10-1.fc11.noarch requires mythes
	mythes-nn-2.0.10-1.fc11.noarch requires mythes
	nautilus-search-tool-0.2.2-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(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(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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(Stream) = 0:21a833e12efd34ea0c87d8d9da959809
	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(Set) = 0:7da14e671a035f12386ace3890018ef3
	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(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(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(Camlp4_config) = 0:cb716b4361f43326c6ad695c7a1bb5c0
	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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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.10.fc10.ppc64 requires dejavu-fonts
	1:openoffice.org-pdfimport-3.0.0-9.10.fc10.ppc64 requires libpoppler.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)
	padevchooser-0.9.4-0.6.svn20070925.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	pdfcube-0.0.2-8.fc9.ppc64 requires libpoppler-glib.so.3()(64bit)
	pdfcube-0.0.2-8.fc9.ppc64 requires libpoppler.so.3()(64bit)
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts-experimental
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts
	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)
	planner-eds-0.14.3-6.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	planner-eds-0.14.3-6.fc10.ppc64 requires libcamel-provider-1.2.so.14()(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)
	tellico-1.3.4-1.fc10.ppc64 requires libpoppler.so.3()(64bit)
	tracker-0.6.6-3.fc10.ppc64 requires libpoppler-glib.so.3()(64bit)
	tracker-search-tool-0.6.6-3.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	wput-0.6.1-4.fc9.ppc64 requires libgnutls-openssl.so.13()(64bit)





From stickster at gmail.com  Wed Nov 26 12:49:37 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Wed, 26 Nov 2008 07:49:37 -0500
Subject: NetworkManager cli docs
In-Reply-To: <90d975d30811252312l2479a583ve7cd3dfdaf06c8bc@mail.gmail.com>
References: <1227447232.3721.1.camel@sb-home>
	<1227542437.564.24.camel@localhost.localdomain>
	<1227554514.7267.1.camel@sb-home>
	<1227557641.25089.10.camel@localhost.localdomain>
	<20081124205106.GR22173@salma.internal.frields.org>
	<49qtv5xv1j.ln2@ppp1053.in.ipex.cz>
	<90d975d30811252312l2479a583ve7cd3dfdaf06c8bc@mail.gmail.com>
Message-ID: <20081126124937.GG26873@localhost.localdomain>

On Wed, Nov 26, 2008 at 08:12:40AM +0100, Gergely Buday wrote:
> Matej wrote:
> 
> >> That's a bug maybe worth filing against initscripts; the
> >> /usr/share/doc/initscripts-*/sysconfig.txt file is fairly useful but
> >> may have slipped out of currency.
> >
> > And if somebody converted that into manpage(s) she would be my
> > personal hero.
> 
> I am not a hero type but this is certainly an itch to scratch for me.
> I have taken a search for the initscripts project but got results only
> for initscripts-ipv6. What I got is the home page for the rpm package:
> 
> https://admin.fedoraproject.org/pkgdb/packages/name/initscripts
> 
> Is this a fedora-only package? What is the way to sign up as a volunteer?

http://git.fedorahosted.org/git/?p=initscripts.git;a=summary

It's a Fedora Hosted project, so you could talk to the owner about how
to get involved with its specific documentation.

-- 
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/20081126/a21847c5/attachment.sig>

From stickster at gmail.com  Wed Nov 26 12:45:25 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Wed, 26 Nov 2008 07:45:25 -0500
Subject: kernel-devel in "Fedora" spin?
In-Reply-To: <64b14b300811260005u2ce568fdja73e41422ca3cbaf@mail.gmail.com>
References: <1221522171.2102.6.camel@luminos.localdomain>
	<48CF04A1.7020801@redhat.com>
	<20080916020742.GA11480@yoda.jdub.homelinux.org>
	<48D0232E.7080101@redhat.com>
	<64b14b300811110648m54e6e5fdwf67b9f21462732a4@mail.gmail.com>
	<778179b00811110654v235fb883l8245a4e9ab4a7ef7@mail.gmail.com>
	<64b14b300811260005u2ce568fdja73e41422ca3cbaf@mail.gmail.com>
Message-ID: <20081126124515.GF26873@localhost.localdomain>

On Wed, Nov 26, 2008 at 09:05:51AM +0100, Valent Turkovic wrote:
> Has this made it for Fedora 10? Is fedora-devel on install and live media?

http://download.fedora.redhat.com/pub/fedora/linux/releases/10/Fedora/i386/os/Packages/

-- 
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/20081126/5b04f0e0/attachment.sig>

From rdieter at math.unl.edu  Wed Nov 26 13:05:13 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 26 Nov 2008 07:05:13 -0600
Subject: New users confused about Spins' Names
References: <492D38D3.1050303@students.iiit.ac.in>
Message-ID: <ggjhi9$34r$1@ger.gmane.org>

Kulbir Saini wrote:

> Hi list,
> 
>     Yesterday, I posted a blog entry[1] about Fedora 10 Release on my
> blog and mentioned the Fedora 10 Spins availability with link to Fedora
> Project page[2]. I have received a comment[3] which says,
> 
>     "I might be interested in some of the spins, but it's hard to tell.
> The names contain acronyms, and the description simply repeats the
> acronym. Unless I recognize what that acronym is, the name is useless.
> What's FEL, AOS or broffice? XFCE is the only one I know, though others
> might not even know that.

Chitlesh threw this together yesterday:
https://fedoraproject.org/wiki/SIGs/Spins/10

-- Rex




From jameshubbard at gmail.com  Wed Nov 26 13:10:38 2008
From: jameshubbard at gmail.com (James Hubbard)
Date: Wed, 26 Nov 2008 08:10:38 -0500
Subject: Heads up for mono-2.2
In-Reply-To: <20081126105417.GA2785@mokona.greysector.net>
References: <1227617066.21103.456.camel@PB3.Linux>
	<1227618688.21103.460.camel@PB3.Linux>
	<3d44afb117e282abe3246c50869c60fa.squirrel@arekh.dyndns.org>
	<200811251528.07267.opensource@till.name>
	<f3ddc6d30811250928u4e16410dudae854774a726946@mail.gmail.com>
	<20081126105417.GA2785@mokona.greysector.net>
Message-ID: <f3ddc6d30811260510l5f8b3139nd5fe5704b050834a@mail.gmail.com>

On Wed, Nov 26, 2008 at 5:54 AM, Dominik 'Rathann' Mierzejewski
<dominik at greysector.net> wrote:
> On Tuesday, 25 November 2008 at 18:28, James Hubbard wrote:
>> Why does anyone go searching for a srpm?  Everyone has their reasons.
>> You are assuming that the user has those tools.  What if the user is
>> on another system or  does not have net connectivity?  I will go back
>> to older versions of fedora to download srpms.  However, I usually
>> know the package name.
>>
>> I do not believe that not having a separate srpm for this will be a
>> problem.  Anyone that needs it will probably figure it out.  I think
>> that having packages where there are multiple applications in one rpm
>> is more of a problem from the end user stand point.
>
> You can always check which src.rpm a package was built from with rpm -qi.

The post by Till Maas that I was responding to made that point.  Did
you miss my point about being on a system that does not have rpm
installed?  I have frequently downloaded rpms and occasionally srpms
while using a windows machine.   In many U.S. government facilities,
it would be impossible to get a linux box onto a network with Internet
connectivity.  There are corporate networks where it would be
forbidden to connect a linux system.

>> The example that sticks out my head is the kdeskd rpm.
>
> yum search kdeskd returns no results.

My mistake.  The package name is kdesdk instead of kdeskd.  There have
been times when I wanted to install Umbrello only.  Unfortunately, it
installs all of the kde software development packages such as
kdevelop.



From dominik at greysector.net  Wed Nov 26 14:02:19 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 26 Nov 2008 15:02:19 +0100
Subject: Heads up for mono-2.2
In-Reply-To: <f3ddc6d30811260510l5f8b3139nd5fe5704b050834a@mail.gmail.com>
References: <1227617066.21103.456.camel@PB3.Linux>
	<1227618688.21103.460.camel@PB3.Linux>
	<3d44afb117e282abe3246c50869c60fa.squirrel@arekh.dyndns.org>
	<200811251528.07267.opensource@till.name>
	<f3ddc6d30811250928u4e16410dudae854774a726946@mail.gmail.com>
	<20081126105417.GA2785@mokona.greysector.net>
	<f3ddc6d30811260510l5f8b3139nd5fe5704b050834a@mail.gmail.com>
Message-ID: <20081126140218.GB3865@mokona.greysector.net>

On Wednesday, 26 November 2008 at 14:10, James Hubbard wrote:
> On Wed, Nov 26, 2008 at 5:54 AM, Dominik 'Rathann' Mierzejewski
> <dominik at greysector.net> wrote:
> > On Tuesday, 25 November 2008 at 18:28, James Hubbard wrote:
> >> Why does anyone go searching for a srpm?  Everyone has their reasons.
> >> You are assuming that the user has those tools.  What if the user is
> >> on another system or  does not have net connectivity?  I will go back
> >> to older versions of fedora to download srpms.  However, I usually
> >> know the package name.
> >>
> >> I do not believe that not having a separate srpm for this will be a
> >> problem.  Anyone that needs it will probably figure it out.  I think
> >> that having packages where there are multiple applications in one rpm
> >> is more of a problem from the end user stand point.
> >
> > You can always check which src.rpm a package was built from with rpm -qi.
> 
> The post by Till Maas that I was responding to made that point.  Did
> you miss my point about being on a system that does not have rpm
> installed?  I have frequently downloaded rpms and occasionally srpms
> while using a windows machine.   In many U.S. government facilities,
> it would be impossible to get a linux box onto a network with Internet
> connectivity.  There are corporate networks where it would be
> forbidden to connect a linux system.

But it's fine to connect a Windows box? How idiotic. Anyway, I believe
koji lets you search for rpms and files.

> >> The example that sticks out my head is the kdeskd rpm.
> >
> > yum search kdeskd returns no results.
> 
> My mistake.  The package name is kdesdk instead of kdeskd.  There have
> been times when I wanted to install Umbrello only.  Unfortunately, it
> installs all of the kde software development packages such as
> kdevelop.

No, it doesn't:
# yum install /usr/bin/umbrello
...
Dependencies Resolved

================================================================================
 Package              Arch        Version          Repository             Size 
================================================================================
Installing:
 kdesdk               x86_64      4.1.2-3.fc9      updates-newkey         6.9 M
Installing for dependencies:
 kdesdk-libs          x86_64      4.1.2-3.fc9      updates-newkey         281 k
 kdesdk-utils         x86_64      4.1.2-3.fc9      updates-newkey         259 k
 perl-XML-DOM         noarch      1.44-4.fc9       fedora                 138 k
 perl-XML-Parser      x86_64      2.36-3.fc9       fedora                 295 k
 perl-XML-RegExp      noarch      0.03-4.fc9       fedora                 8.5 k

Transaction Summary
================================================================================
Install      6 Package(s)         
Update       0 Package(s)         
Remove       0 Package(s)         

Total download size: 7.8 M
Is this ok [y/N]: N
Exiting on user Command
Complete!

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 rjones at redhat.com  Wed Nov 26 14:07:16 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 26 Nov 2008 14:07:16 +0000
Subject: rawhide report: 20081126 changes
In-Reply-To: <20081126123631.8BB4F1F823B@releng2.fedora.phx.redhat.com>
References: <20081126123631.8BB4F1F823B@releng2.fedora.phx.redhat.com>
Message-ID: <20081126140716.GA2045@amd.home.annexia.org>

On Wed, Nov 26, 2008 at 12:36:31PM +0000, Rawhide Report wrote:
> Broken deps for i386
> ----------------------------------------------------------
> 	cduce-0.5.2.1-9.fc10.i386 requires ocaml(Stream) = 0:21a833e12efd34ea0c87d8d9da959809

As explained before, all these OCaml broken deps are to be expected,
and I'll fix them over the next few days by fixing and rebuilding
packages as required.

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 tgl at redhat.com  Wed Nov 26 14:14:55 2008
From: tgl at redhat.com (Tom Lane)
Date: Wed, 26 Nov 2008 09:14:55 -0500
Subject: error compiling postgresql with fedora mingw 
In-Reply-To: <1227701751.4300.5.camel@beck.corsepiu.local> 
References: <492BD6C0.5030602@ispbrasil.com.br>
	<29573.1227635570@sss.pgh.pa.us>
	<492C451F.1010709@ispbrasil.com.br>
	<1227639900.23644.51.camel@localhost.localdomain>
	<3880.1227640767@sss.pgh.pa.us> <20081126110559.GH16540@redhat.com>
	<1227701751.4300.5.camel@beck.corsepiu.local>
Message-ID: <7364.1227708895@sss.pgh.pa.us>

Ralf Corsepius <rc040203 at freenet.de> writes:
> On Wed, 2008-11-26 at 11:05 +0000, Daniel P. Berrange wrote:
>> On Tue, Nov 25, 2008 at 02:19:27PM -0500, Tom Lane wrote:
>>> That makes sense.  Could you have simplified matters by just prepending
>>> /usr/i686-pc-mingw32/bin to your PATH?

> That said, I also recommend against this habit - In case of properly
> packaged autoconf/automake-based packages it definitely wrong.

Seems like these choices are carefully calculated to cause the maximum
amount of pain to *both* the upstream projects and the poor sods trying
to build them.

Anyway, as I said before, I'd be interested to see a tested patch to
get the Postgres sources building cleanly on Fedora-mingw; but whatever
tiny interest I had in doing it myself has vanished utterly.

			regards, tom lane



From rc040203 at freenet.de  Wed Nov 26 14:20:06 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 26 Nov 2008 15:20:06 +0100
Subject: error compiling postgresql with fedora mingw
In-Reply-To: <7364.1227708895@sss.pgh.pa.us>
References: <492BD6C0.5030602@ispbrasil.com.br>
	<29573.1227635570@sss.pgh.pa.us> <492C451F.1010709@ispbrasil.com.br>
	<1227639900.23644.51.camel@localhost.localdomain>
	<3880.1227640767@sss.pgh.pa.us> <20081126110559.GH16540@redhat.com>
	<1227701751.4300.5.camel@beck.corsepiu.local>
	<7364.1227708895@sss.pgh.pa.us>
Message-ID: <1227709206.4300.8.camel@beck.corsepiu.local>

On Wed, 2008-11-26 at 09:14 -0500, Tom Lane wrote:
> Ralf Corsepius <rc040203 at freenet.de> writes:
> > On Wed, 2008-11-26 at 11:05 +0000, Daniel P. Berrange wrote:
> >> On Tue, Nov 25, 2008 at 02:19:27PM -0500, Tom Lane wrote:
> >>> That makes sense.  Could you have simplified matters by just prepending
> >>> /usr/i686-pc-mingw32/bin to your PATH?
> 
> > That said, I also recommend against this habit - In case of properly
> > packaged autoconf/automake-based packages it definitely wrong.
> 
> Seems like these choices are carefully calculated to cause the maximum
> amount of pain to *both* the upstream projects and the poor sods trying
> to build them.
The logic actually is very simple:

configure --host=i686-pc-mingw32
will search for i686-pc-mingw32-prefixed tools (such as
i686-pc-mingw32-gcc) in $PATH.

Ralf




From jameshubbard at gmail.com  Wed Nov 26 14:30:05 2008
From: jameshubbard at gmail.com (James Hubbard)
Date: Wed, 26 Nov 2008 09:30:05 -0500
Subject: Heads up for mono-2.2
In-Reply-To: <20081126140218.GB3865@mokona.greysector.net>
References: <1227617066.21103.456.camel@PB3.Linux>
	<1227618688.21103.460.camel@PB3.Linux>
	<3d44afb117e282abe3246c50869c60fa.squirrel@arekh.dyndns.org>
	<200811251528.07267.opensource@till.name>
	<f3ddc6d30811250928u4e16410dudae854774a726946@mail.gmail.com>
	<20081126105417.GA2785@mokona.greysector.net>
	<f3ddc6d30811260510l5f8b3139nd5fe5704b050834a@mail.gmail.com>
	<20081126140218.GB3865@mokona.greysector.net>
Message-ID: <f3ddc6d30811260630l4381daefs53a6fb6764e26acb@mail.gmail.com>

On Wed, Nov 26, 2008 at 9:02 AM, Dominik 'Rathann' Mierzejewski
<dominik at greysector.net> wrote:
> On Wednesday, 26 November 2008 at 14:10, James Hubbard wrote:
>> On Wed, Nov 26, 2008 at 5:54 AM, Dominik 'Rathann' Mierzejewski
>> <dominik at greysector.net> wrote:
>> > On Tuesday, 25 November 2008 at 18:28, James Hubbard wrote:
>> >> Why does anyone go searching for a srpm?  Everyone has their reasons.
>> >> You are assuming that the user has those tools.  What if the user is
>> >> on another system or  does not have net connectivity?  I will go back
>> >> to older versions of fedora to download srpms.  However, I usually
>> >> know the package name.
>> >>
>> >> I do not believe that not having a separate srpm for this will be a
>> >> problem.  Anyone that needs it will probably figure it out.  I think
>> >> that having packages where there are multiple applications in one rpm
>> >> is more of a problem from the end user stand point.
>> >
>> > You can always check which src.rpm a package was built from with rpm -qi.
>>
>> The post by Till Maas that I was responding to made that point.  Did
>> you miss my point about being on a system that does not have rpm
>> installed?  I have frequently downloaded rpms and occasionally srpms
>> while using a windows machine.   In many U.S. government facilities,
>> it would be impossible to get a linux box onto a network with Internet
>> connectivity.  There are corporate networks where it would be
>> forbidden to connect a linux system.
>
> But it's fine to connect a Windows box? How idiotic. Anyway, I believe
> koji lets you search for rpms and files.
>
>> >> The example that sticks out my head is the kdeskd rpm.
>> >
>> > yum search kdeskd returns no results.
>>
>> My mistake.  The package name is kdesdk instead of kdeskd.  There have
>> been times when I wanted to install Umbrello only.  Unfortunately, it
>> installs all of the kde software development packages such as
>> kdevelop.
>
> No, it doesn't:
> # yum install /usr/bin/umbrello
> ...
[snip]

I see that kdevelop is it's own package, so I mispoke when I included
it.  However if you look at the included applications you'll see a
list of items. Most of them are things that I don't even care about.

yum info kdesdk
Name       : kdesdk
....
Description: A collection of applications and tools used by developers,
           : including: * cervisia: a CVS frontend * kate: advanced text editor
           : * kbugbuster: a tool to manage the KDE bug report system *
           : kcachegrind: a browser for data produced by profiling tools (e.g.
           : cachegrind) * kompare: diff tool * kuiviewer: displays designer's
           : UI files * lokalize: computer-aided translation system focusing on
           : productivity and performance * umbrello: UML modeller and UML
           : diagram tool



From nicolas.mailhot at laposte.net  Wed Nov 26 14:34:23 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 26 Nov 2008 15:34:23 +0100 (CET)
Subject: Heads up for mono-2.2
In-Reply-To: <20081126121842.GA3865@mokona.greysector.net>
References: <1227617066.21103.456.camel@PB3.Linux>
	<1227618688.21103.460.camel@PB3.Linux>
	<3d44afb117e282abe3246c50869c60fa.squirrel@arekh.dyndns.org>
	<200811251528.07267.opensource@till.name>
	<f3ddc6d30811250928u4e16410dudae854774a726946@mail.gmail.com>
	<20081126105417.GA2785@mokona.greysector.net>
	<28ba7d38affef39789dd161bcb1e5115.squirrel@arekh.dyndns.org>
	<20081126121842.GA3865@mokona.greysector.net>
Message-ID: <c78c5933e4af8890fe160c738ef14f32.squirrel@arekh.dyndns.org>



Le Mer 26 novembre 2008 13:18, Dominik 'Rathann' Mierzejewski a ?crit :
>
> On Wednesday, 26 November 2008 at 12:56, Nicolas Mailhot wrote:

>> You can do a lot of things, but my point is
>> 1. most people won't bother and therefore
>> 2. magic packages where the rpm -> srpm relation is not obvious are
>> just introducing drag and problems in the Fedora workflows.
>
> That should not be an argument to force packagers to use convoluted
> rpm names.

Maybe it should be otherwise, but the current situation is the one I
described, and out packaging must work with current tools, not
hypothetical better tools which may appear next month or in ten years.

-- 
Nicolas Mailhot



From lfarkas at lfarkas.org  Wed Nov 26 14:42:56 2008
From: lfarkas at lfarkas.org (Farkas Levente)
Date: Wed, 26 Nov 2008 15:42:56 +0100
Subject: error compiling postgresql with fedora mingw
In-Reply-To: <1227709206.4300.8.camel@beck.corsepiu.local>
References: <492BD6C0.5030602@ispbrasil.com.br>	<29573.1227635570@sss.pgh.pa.us>
	<492C451F.1010709@ispbrasil.com.br>	<1227639900.23644.51.camel@localhost.localdomain>	<3880.1227640767@sss.pgh.pa.us>
	<20081126110559.GH16540@redhat.com>	<1227701751.4300.5.camel@beck.corsepiu.local>	<7364.1227708895@sss.pgh.pa.us>
	<1227709206.4300.8.camel@beck.corsepiu.local>
Message-ID: <492D6070.2040504@lfarkas.org>

Ralf Corsepius wrote:
> On Wed, 2008-11-26 at 09:14 -0500, Tom Lane wrote:
>> Ralf Corsepius <rc040203 at freenet.de> writes:
>>> On Wed, 2008-11-26 at 11:05 +0000, Daniel P. Berrange wrote:
>>>> On Tue, Nov 25, 2008 at 02:19:27PM -0500, Tom Lane wrote:
>>>>> That makes sense.  Could you have simplified matters by just prepending
>>>>> /usr/i686-pc-mingw32/bin to your PATH?
>>> That said, I also recommend against this habit - In case of properly
>>> packaged autoconf/automake-based packages it definitely wrong.
>> Seems like these choices are carefully calculated to cause the maximum
>> amount of pain to *both* the upstream projects and the poor sods trying
>> to build them.
> The logic actually is very simple:
> 
> configure --host=i686-pc-mingw32
> will search for i686-pc-mingw32-prefixed tools (such as
> i686-pc-mingw32-gcc) in $PATH.

there is a fedora-mingw list which is the right place to ask.
anyway in the latest mingw32-filesystem there is a script
mingw32-configure which do it right.

-- 
  Levente                               "Si vis pacem para bellum!"



From rjones at redhat.com  Wed Nov 26 14:42:29 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 26 Nov 2008 14:42:29 +0000
Subject: error compiling postgresql with fedora mingw
In-Reply-To: <7364.1227708895@sss.pgh.pa.us>
References: <492BD6C0.5030602@ispbrasil.com.br>
	<29573.1227635570@sss.pgh.pa.us>
	<492C451F.1010709@ispbrasil.com.br>
	<1227639900.23644.51.camel@localhost.localdomain>
	<3880.1227640767@sss.pgh.pa.us> <20081126110559.GH16540@redhat.com>
	<1227701751.4300.5.camel@beck.corsepiu.local>
	<7364.1227708895@sss.pgh.pa.us>
Message-ID: <20081126144229.GA2143@amd.home.annexia.org>

On Wed, Nov 26, 2008 at 09:14:55AM -0500, Tom Lane wrote:
> Ralf Corsepius <rc040203 at freenet.de> writes:
> > On Wed, 2008-11-26 at 11:05 +0000, Daniel P. Berrange wrote:
> >> On Tue, Nov 25, 2008 at 02:19:27PM -0500, Tom Lane wrote:
> >>> That makes sense.  Could you have simplified matters by just prepending
> >>> /usr/i686-pc-mingw32/bin to your PATH?
> 
> > That said, I also recommend against this habit - In case of properly
> > packaged autoconf/automake-based packages it definitely wrong.
> 
> Seems like these choices are carefully calculated to cause the maximum
> amount of pain to *both* the upstream projects and the poor sods trying
> to build them.

I'm not sure if adding:

  WINDRES = windres

  ... $(WINDRES) ...

to a Makefile constitutes "maximum amount of pain", but in any case
we've successfully ported 50+ libraries to MinGW using similar
techniques, and without impacting upstream negatively.

http://hg.et.redhat.com/misc/fedora-mingw--devel?mf=ac270e95b1e4;path=/

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 pertusus at free.fr  Wed Nov 26 14:44:15 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 26 Nov 2008 15:44:15 +0100
Subject: BugZappers/HouseKeeping is a policy and seems incomplete
In-Reply-To: <981da310811231519i58b2f9b8t68c31ab769aff8d1@mail.gmail.com>
References: <20081116160839.GC2933@free.fr>
	<da159fda0811161621y4847991bn8a87c1807d0fec29@mail.gmail.com>
	<20081118191939.GB2610@free.fr>
	<20081123151541.5332b42c@ohm.scrye.com>
	<981da310811231519i58b2f9b8t68c31ab769aff8d1@mail.gmail.com>
Message-ID: <20081126144415.GC2780@free.fr>

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.

--
Pat



From pertusus at free.fr  Wed Nov 26 15:04:40 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 26 Nov 2008 16:04:40 +0100
Subject: shortening time passed in bodhi?
Message-ID: <20081126150440.GD2780@free.fr>

Hello,

Most of the time I push to stable when reminded by a mail (nice feature)
since nobody cares to give feedback on my updates and they are not
urgent. However recently I had an update I wanted to have in as soon as 
possible since the app was broken without it. It took 8 days to have it 
pushed, something like 2-3 days for the push to testing and the remaining 
for the push and signing.

Could this be improved?

I guess that the signing server should help, but I don't think it could
remove all the delays.

What are the reasons for holding updates? Is there somebody actually
verifying that the package works, doesn't break the distro or the like?
What exactly do releng/QA people with updates, ie what checks?

Reason I can think of justifying holding the release would be issues that 
can affect distro as a whole. Some of those issues should be
tracked automatically:
* nevr issue (leading to upgrade issues)
* missing dependencies (as BuildRequires or Requires) be it as a removed 
  require that is needed by a package, or a new provide that is not 
  provided by any package
* providing redundant Provides leading to the wrong package being used
  as provide

Are those issues actually checked today? Are there other issues that 
releng/QA test/check?

--
Pat



From kevin.kofler at chello.at  Wed Nov 26 15:09:11 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 26 Nov 2008 16:09:11 +0100
Subject: ace name conflict (was: Re: rawhide report: 20081126 changes)
References: <20081126123631.8BB4F1F823B@releng2.fedora.phx.redhat.com>
Message-ID: <ggjoqn$uft$1@ger.gmane.org>

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.

So what is the way out of this mess? Right now the packages trip on each
other and they're completely different.

By the way, there's also a proprietary packer called "ace", but it has no
GNU/Linux version (only unace is available), so that one is unlikely to be
a problem.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Nov 26 15:12:06 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 26 Nov 2008 16:12:06 +0100
Subject: shortening time passed in bodhi?
References: <20081126150440.GD2780@free.fr>
Message-ID: <ggjp06$uft$2@ger.gmane.org>

Patrice Dumas wrote:
> Most of the time I push to stable when reminded by a mail (nice feature)
> since nobody cares to give feedback on my updates and they are not
> urgent. However recently I had an update I wanted to have in as soon as
> possible since the app was broken without it. It took 8 days to have it
> pushed, something like 2-3 days for the push to testing and the remaining
> for the push and signing.

If you want it out as soon as possible, skip testing and push directly to
stable.

        Kevin Kofler



From rjones at redhat.com  Wed Nov 26 15:19:06 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 26 Nov 2008 15:19:06 +0000
Subject: error compiling postgresql with fedora mingw
In-Reply-To: <492D6070.2040504@lfarkas.org>
References: <492BD6C0.5030602@ispbrasil.com.br>
	<29573.1227635570@sss.pgh.pa.us>
	<492C451F.1010709@ispbrasil.com.br>
	<1227639900.23644.51.camel@localhost.localdomain>
	<3880.1227640767@sss.pgh.pa.us> <20081126110559.GH16540@redhat.com>
	<1227701751.4300.5.camel@beck.corsepiu.local>
	<7364.1227708895@sss.pgh.pa.us>
	<1227709206.4300.8.camel@beck.corsepiu.local>
	<492D6070.2040504@lfarkas.org>
Message-ID: <20081126151906.GA2321@amd.home.annexia.org>

On Wed, Nov 26, 2008 at 03:42:56PM +0100, Farkas Levente wrote:
> Ralf Corsepius wrote:
> > On Wed, 2008-11-26 at 09:14 -0500, Tom Lane wrote:
> >> Ralf Corsepius <rc040203 at freenet.de> writes:
> >>> On Wed, 2008-11-26 at 11:05 +0000, Daniel P. Berrange wrote:
> >>>> On Tue, Nov 25, 2008 at 02:19:27PM -0500, Tom Lane wrote:
> >>>>> That makes sense.  Could you have simplified matters by just prepending
> >>>>> /usr/i686-pc-mingw32/bin to your PATH?
> >>> That said, I also recommend against this habit - In case of properly
> >>> packaged autoconf/automake-based packages it definitely wrong.
> >> Seems like these choices are carefully calculated to cause the maximum
> >> amount of pain to *both* the upstream projects and the poor sods trying
> >> to build them.
> > The logic actually is very simple:
> > 
> > configure --host=i686-pc-mingw32
> > will search for i686-pc-mingw32-prefixed tools (such as
> > i686-pc-mingw32-gcc) in $PATH.
> 
> there is a fedora-mingw list which is the right place to ask.
> anyway in the latest mingw32-filesystem there is a script
> mingw32-configure which do it right.

Yes, to be clearer what Levente means is that you should use:

  %{_mingw32_configure}

in RPM specfiles, and if just building from the command line use:

  mingw32-configure

Both are merely wrappers around this basic command:

  ./configure --host=i686-pc-mingw32

except that they set a lot more paths and a environment variables,
which are needed in rarer / corner cases.

The full expansion is below for anyone who is interested, although
only PKG_CONFIG_PATH is needed in 95% of cases.

Rich.

  HOST_CC=gcc; export HOST_CC; 
  AS="i686-pc-mingw32-as"; export AS; 
  AR="i686-pc-mingw32-ar"; export AR; 
  NM="i686-pc-mingw32-nm"; export NM; 
  OBJDUMP="i686-pc-mingw32-objdump"; export OBJDUMP; 
  PKG_CONFIG_PATH="/usr/i686-pc-mingw32/sys-root/mingw/lib/pkgconfig"; export PKG_CONFIG_PATH; 
  CC="${MINGW32_CC:-i686-pc-mingw32-gcc}"; export CC; 
  CXX="${MINGW32_CXX:-i686-pc-mingw32-g++}"; export CXX; 
  CFLAGS="${MINGW32_CFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -mms-bitfields}"; export CFLAGS; 
  CXXFLAGS="${MINGW32_CXXFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -mms-bitfields}"; export CXXFLAGS; 
  for i in `ls /usr/i686-pc-mingw32/sys-root/mingw/bin|grep -- "-config$"` ; do 
    CONFIG_NAME=`echo $i|tr "a-z-" "A-Z_"`; 
    declare -x $CONFIG_NAME="/usr/i686-pc-mingw32/sys-root/mingw/bin/$i" ; export $CONFIG_NAME; 
  done ; 
  ./configure --cache-file=mingw32-config.cache \
        --host=i686-pc-mingw32 \
        --build=x86_64-unknown-linux-gnu \
        --target=i686-pc-mingw32 \
        --prefix=/usr/i686-pc-mingw32/sys-root/mingw \
        --exec-prefix=/usr/i686-pc-mingw32/sys-root/mingw \
        --bindir=/usr/i686-pc-mingw32/sys-root/mingw/bin \
        --sbindir=/usr/i686-pc-mingw32/sys-root/mingw/sbin \
        --sysconfdir=/usr/i686-pc-mingw32/sys-root/mingw/etc \
        --datadir=/usr/i686-pc-mingw32/sys-root/mingw/share \
        --includedir=/usr/i686-pc-mingw32/sys-root/mingw/include \
        --libdir=/usr/i686-pc-mingw32/sys-root/mingw/lib \
        --libexecdir=/usr/i686-pc-mingw32/sys-root/mingw/libexec \
        --localstatedir=/usr/i686-pc-mingw32/sys-root/mingw/var \
        --sharedstatedir=/usr/i686-pc-mingw32/sys-root/mingw/com \
        --mandir=/usr/i686-pc-mingw32/sys-root/mingw/share/man \
        --infodir=/usr/i686-pc-mingw32/sys-root/mingw/share/info


-- 
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 jos at xos.nl  Wed Nov 26 15:19:54 2008
From: jos at xos.nl (Jos Vos)
Date: Wed, 26 Nov 2008 16:19:54 +0100
Subject: No X on F9/F10 with Intel 82915G/GV/910GL
In-Reply-To: <1227559247.23765.54.camel@atropine.boston.devel.redhat.com>
References: <200811241511.mAOFBDo0019062@jasmine.xos.nl>
	<1227545424.23765.19.camel@atropine.boston.devel.redhat.com>
	<20081124165746.GA20250@jasmine.xos.nl>
	<1227550496.23765.24.camel@atropine.boston.devel.redhat.com>
	<20081124191738.GA22039@jasmine.xos.nl>
	<1227559247.23765.54.camel@atropine.boston.devel.redhat.com>
Message-ID: <20081126151954.GA18959@jasmine.xos.nl>

On Mon, Nov 24, 2008 at 03:40:47PM -0500, Adam Jackson wrote:

> The current theory is that it's trying to do LVDS over SDVO, which is a
> bit insane since it has LVDS on the board already, and that's a path
> that the driver currently doesn't support.  If we could get copies of
> the video BIOS (and some testing time, if you're up for it) we can
> probably work with intel to get it going.  Probably best to do that in a
> bug, either in fedora or freedesktop bugzilla.

I filed it as: https://bugzilla.redhat.com/show_bug.cgi?id=473101

-- 
--    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 dominik at greysector.net  Wed Nov 26 15:08:18 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 26 Nov 2008 16:08:18 +0100
Subject: Heads up for mono-2.2
In-Reply-To: <c78c5933e4af8890fe160c738ef14f32.squirrel@arekh.dyndns.org>
References: <1227617066.21103.456.camel@PB3.Linux>
	<1227618688.21103.460.camel@PB3.Linux>
	<3d44afb117e282abe3246c50869c60fa.squirrel@arekh.dyndns.org>
	<200811251528.07267.opensource@till.name>
	<f3ddc6d30811250928u4e16410dudae854774a726946@mail.gmail.com>
	<20081126105417.GA2785@mokona.greysector.net>
	<28ba7d38affef39789dd161bcb1e5115.squirrel@arekh.dyndns.org>
	<20081126121842.GA3865@mokona.greysector.net>
	<c78c5933e4af8890fe160c738ef14f32.squirrel@arekh.dyndns.org>
Message-ID: <20081126150817.GC3865@mokona.greysector.net>

On Wednesday, 26 November 2008 at 15:34, Nicolas Mailhot wrote:
> 
> 
> Le Mer 26 novembre 2008 13:18, Dominik 'Rathann' Mierzejewski a ?crit :
> >
> > On Wednesday, 26 November 2008 at 12:56, Nicolas Mailhot wrote:
> 
> >> You can do a lot of things, but my point is
> >> 1. most people won't bother and therefore
> >> 2. magic packages where the rpm -> srpm relation is not obvious are
> >> just introducing drag and problems in the Fedora workflows.
> >
> > That should not be an argument to force packagers to use convoluted
> > rpm names.
> 
> Maybe it should be otherwise, but the current situation is the one I
> described, and out packaging must work with current tools, not
> hypothetical better tools which may appear next month or in ten years.

If people can't be bothered to look up srpm name when reporting bugs
then we must either live with that or remove the need to look it up
by automating this task. A half-baked solution like not allowing rpms
to have different names from their srpms is simply wrong, because
it unnecessarily restricts package maintainers without solving the
real problem.

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  Wed Nov 26 15:22:34 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 26 Nov 2008 16:22:34 +0100
Subject: shortening time passed in bodhi?
In-Reply-To: <ggjp06$uft$2@ger.gmane.org>
References: <20081126150440.GD2780@free.fr> <ggjp06$uft$2@ger.gmane.org>
Message-ID: <20081126152234.GE2780@free.fr>

On Wed, Nov 26, 2008 at 04:12:06PM +0100, Kevin Kofler wrote:
> Patrice Dumas wrote:
> > Most of the time I push to stable when reminded by a mail (nice feature)
> > since nobody cares to give feedback on my updates and they are not
> > urgent. However recently I had an update I wanted to have in as soon as
> > possible since the app was broken without it. It took 8 days to have it
> > pushed, something like 2-3 days for the push to testing and the remaining
> > for the push and signing.
> 
> If you want it out as soon as possible, skip testing and push directly to
> stable.

I didn't noticed that. In that case it goes straight to stable, without
neing in a pending state at all?

--
Pat



From notting at redhat.com  Wed Nov 26 15:23:06 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 26 Nov 2008 10:23:06 -0500
Subject: ace name conflict (was: Re: rawhide report: 20081126 changes)
In-Reply-To: <ggjoqn$uft$1@ger.gmane.org>
References: <20081126123631.8BB4F1F823B@releng2.fedora.phx.redhat.com>
	<ggjoqn$uft$1@ger.gmane.org>
Message-ID: <20081126152306.GC8169@nostromo.devel.redhat.com>

Kevin Kofler (kevin.kofler at chello.at) said: 
> 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.
> 
> So what is the way out of this mess? Right now the packages trip on each
> other and they're completely different.

Is there a reason the other ACE isn't in Fedora (no volunteers is
a valid reason). It certainly predates the just added one.

Bill



From mtasaka at ioa.s.u-tokyo.ac.jp  Wed Nov 26 15:25:34 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Thu, 27 Nov 2008 00:25:34 +0900
Subject: ace name conflict
In-Reply-To: <ggjoqn$uft$1@ger.gmane.org>
References: <20081126123631.8BB4F1F823B@releng2.fedora.phx.redhat.com>
	<ggjoqn$uft$1@ger.gmane.org>
Message-ID: <492D6A6E.7010205@ioa.s.u-tokyo.ac.jp>

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



From rjones at redhat.com  Wed Nov 26 15:25:41 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 26 Nov 2008 15:25:41 +0000
Subject: shortening time passed in bodhi?
In-Reply-To: <20081126152234.GE2780@free.fr>
References: <20081126150440.GD2780@free.fr> <ggjp06$uft$2@ger.gmane.org>
	<20081126152234.GE2780@free.fr>
Message-ID: <20081126152541.GA2408@amd.home.annexia.org>

On Wed, Nov 26, 2008 at 04:22:34PM +0100, Patrice Dumas wrote:
> On Wed, Nov 26, 2008 at 04:12:06PM +0100, Kevin Kofler wrote:
> > Patrice Dumas wrote:
> > > Most of the time I push to stable when reminded by a mail (nice feature)
> > > since nobody cares to give feedback on my updates and they are not
> > > urgent. However recently I had an update I wanted to have in as soon as
> > > possible since the app was broken without it. It took 8 days to have it
> > > pushed, something like 2-3 days for the push to testing and the remaining
> > > for the push and signing.
> > 
> > If you want it out as soon as possible, skip testing and push directly to
> > stable.
> 
> I didn't noticed that. In that case it goes straight to stable, without
> neing in a pending state at all?

Yes - I've used it a few times.

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 pertusus at free.fr  Wed Nov 26 15:29:38 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 26 Nov 2008 16:29:38 +0100
Subject: shortening time passed in bodhi?
In-Reply-To: <20081126152541.GA2408@amd.home.annexia.org>
References: <20081126150440.GD2780@free.fr> <ggjp06$uft$2@ger.gmane.org>
	<20081126152234.GE2780@free.fr>
	<20081126152541.GA2408@amd.home.annexia.org>
Message-ID: <20081126152938.GF2780@free.fr>

On Wed, Nov 26, 2008 at 03:25:41PM +0000, Richard W.M. Jones wrote:
> > I didn't noticed that. In that case it goes straight to stable, without
> > neing in a pending state at all?
> 
> Yes - I've used it a few times.

Right, that removes one delay.

Still the delay for being in testing may be unwarranted, and other
delays certainly remain.

--
Pat



From rc040203 at freenet.de  Wed Nov 26 15:49:48 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 26 Nov 2008 16:49:48 +0100
Subject: shortening time passed in bodhi?
In-Reply-To: <20081126152234.GE2780@free.fr>
References: <20081126150440.GD2780@free.fr> <ggjp06$uft$2@ger.gmane.org>
	<20081126152234.GE2780@free.fr>
Message-ID: <1227714589.4300.31.camel@beck.corsepiu.local>

On Wed, 2008-11-26 at 16:22 +0100, Patrice Dumas wrote:
> On Wed, Nov 26, 2008 at 04:12:06PM +0100, Kevin Kofler wrote:
> > Patrice Dumas wrote:
> > > Most of the time I push to stable when reminded by a mail (nice feature)
> > > since nobody cares to give feedback on my updates and they are not
> > > urgent. However recently I had an update I wanted to have in as soon as
> > > possible since the app was broken without it. It took 8 days to have it
> > > pushed, something like 2-3 days for the push to testing and the remaining
> > > for the push and signing.
> > 
> > If you want it out as soon as possible, skip testing and push directly to
> > stable.
> 
> I didn't noticed that. In that case it goes straight to stable, without
> neing in a pending state at all?
Right, but the delays until a final push happens typically still is in
the order of several days, occasionally more, sometimes much more :)

Ralf




From nicolas.mailhot at laposte.net  Wed Nov 26 16:01:22 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 26 Nov 2008 17:01:22 +0100 (CET)
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: <f7b9b84c6f7bd9e38e9bf05ecd622a22.squirrel@arekh.dyndns.org>



Le Mer 26 novembre 2008 15:44, Patrice Dumas a ?crit :

> 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 bugs that already block a future target.

I've seen rawhide bugs blocking F11Target requalified as F10 bugs
recently. Madness.

-- 
Nicolas Mailhot



From kevin.kofler at chello.at  Wed Nov 26 16:04:44 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 26 Nov 2008 17:04:44 +0100
Subject: shortening time passed in bodhi?
References: <20081126150440.GD2780@free.fr> <ggjp06$uft$2@ger.gmane.org>
	<20081126152234.GE2780@free.fr>
Message-ID: <ggjs2s$b1t$1@ger.gmane.org>

Patrice Dumas wrote:
> I didn't noticed that. In that case it goes straight to stable, without
> neing in a pending state at all?

Well, it's still in pending until the next push, but it doesn't go through
testing (from where you have to request another push to stable). This means
you only have to wait for 1 push instead of 2.

        Kevin Kofler



From jkeating at redhat.com  Wed Nov 26 16:33:21 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 26 Nov 2008 08:33:21 -0800
Subject: Fedora Release Engineering Meeting Recap 2008-11-24
In-Reply-To: <492CE464.5060003@leemhuis.info>
References: <492C5D62.4030304@redhat.com>  <492CE464.5060003@leemhuis.info>
Message-ID: <1227717201.5276.49.camel@luminos.localdomain>

On Wed, 2008-11-26 at 06:53 +0100, Thorsten Leemhuis wrote:
> On 25.11.2008 21:17, John Poelstra wrote:
>  > [...]
> > * f13: one thing I was toying with is when we branch and freeze, making 
> > the development/ path continue on with say F12 content, and start 
> > publishing the F11 content to releases/11/Everything/
> 
> Not the first time that idea comes up -- but I really think something 
> like that is way overdue, as getting most of our development to a halt 
> for 28 days seems bad as that together with the other freezes beforehand 
> is more than 1/6 of the time a development cycle has.
> 
> So +1 to this.
> 
> CU
> knurd
> 

My continued main concern with this though is fracturing the testing
pool, and not capturing enough eyes/minds on the frozen content for the
release.  The sad fact of many releases is that many people seem to not
start looking at overall polish and bugfixing until the final freeze is
hit.  They treat the final freeze as the last development day and expect
to have time after that to do bugfixing.  Combining that with taking
users away from the QA on those frozen bits could lead to an even worse
release.  So I think there are two problems to solve 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/20081126/2c75c0ce/attachment.sig>

From jkeating at redhat.com  Wed Nov 26 16:35:55 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 26 Nov 2008 08:35:55 -0800
Subject: New users confused about Spins' Names
In-Reply-To: <492D38D3.1050303@students.iiit.ac.in>
References: <492D38D3.1050303@students.iiit.ac.in>
Message-ID: <1227717355.5276.51.camel@luminos.localdomain>

On Wed, 2008-11-26 at 17:23 +0530, Kulbir Saini wrote:
>     Since the table has a description field for each spin, why not (at 
> least) expand the acronyms so folks have a clue as to whether or not it 
> might be useful? Even better, a link to a page describing the spin in 
> more detail. If it's worth the time and effort to create, it should be 
> worth the time it takes to write a paragraph describing it."

In my opinion, if the user is driven to the torrent page in the raw,
we've already lost.  Fedora is providing resources to compose and host
the spins, but in my opinion it is up to the SIG behind each spin to
take on the advertisement and driving of users to that particular spin.
They best know the content, the audience, etc.. and are best suited to
create page content and advertise 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/20081126/51fbca46/attachment.sig>

From jkeating at redhat.com  Wed Nov 26 16:40:09 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 26 Nov 2008 08:40:09 -0800
Subject: shortening time passed in bodhi?
In-Reply-To: <20081126150440.GD2780@free.fr>
References: <20081126150440.GD2780@free.fr>
Message-ID: <1227717609.5276.54.camel@luminos.localdomain>

On Wed, 2008-11-26 at 16:04 +0100, Patrice Dumas wrote:
> Most of the time I push to stable when reminded by a mail (nice feature)
> since nobody cares to give feedback on my updates and they are not
> urgent. However recently I had an update I wanted to have in as soon as 
> possible since the app was broken without it. It took 8 days to have it 
> pushed, something like 2-3 days for the push to testing and the remaining 
> for the push and signing.
> 
> Could this be improved?

Yes.  The compose process (particularly now that we're pushing out
updates for 8, 9, and 10) takes almost all of one work day, with only an
hour or two of prep time before the push, so at best you'll likely get
one per day.  I've been trying to do one at least every other day,
except for on weekends.  However the last couple pushes were spaced out
a bit, as we were trying to get bodhi ready for pushing F10 updates, and
then we didn't want to land a bunch more updates at the same time that
mirrors were trying to get the bitflip change to release F10.

We have a holiday week for a large number of US folks this week so the
updates pushes may get a bit delayed this week 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/20081126/a3938d4d/attachment.sig>

From skvidal at fedoraproject.org  Wed Nov 26 16:46:33 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 26 Nov 2008 11:46:33 -0500 (EST)
Subject: New users confused about Spins' Names
In-Reply-To: <1227717355.5276.51.camel@luminos.localdomain>
References: <492D38D3.1050303@students.iiit.ac.in>
	<1227717355.5276.51.camel@luminos.localdomain>
Message-ID: <alpine.LFD.2.00.0811261145180.12357@localhost.localdomain>



On Wed, 26 Nov 2008, Jesse Keating wrote:

> On Wed, 2008-11-26 at 17:23 +0530, Kulbir Saini wrote:
>>     Since the table has a description field for each spin, why not (at
>> least) expand the acronyms so folks have a clue as to whether or not it
>> might be useful? Even better, a link to a page describing the spin in
>> more detail. If it's worth the time and effort to create, it should be
>> worth the time it takes to write a paragraph describing it."
>
> In my opinion, if the user is driven to the torrent page in the raw,
> we've already lost.  Fedora is providing resources to compose and host
> the spins, but in my opinion it is up to the SIG behind each spin to
> take on the advertisement and driving of users to that particular spin.
> They best know the content, the audience, etc.. and are best suited to
> create page content and advertise it.
>

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.


-sv



From jkeating at redhat.com  Wed Nov 26 17:00:27 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 26 Nov 2008 09:00:27 -0800
Subject: New users confused about Spins' Names
In-Reply-To: <alpine.LFD.2.00.0811261145180.12357@localhost.localdomain>
References: <492D38D3.1050303@students.iiit.ac.in>
	<1227717355.5276.51.camel@luminos.localdomain>
	<alpine.LFD.2.00.0811261145180.12357@localhost.localdomain>
Message-ID: <1227718827.5276.56.camel@luminos.localdomain>

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.

-- 
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/20081126/bf253bd0/attachment.sig>

From jonstanley at gmail.com  Wed Nov 26 17:19:47 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Wed, 26 Nov 2008 12:19:47 -0500
Subject: Question on inode - Ext3 FS
In-Reply-To: <ae2f51270811252041q3c9b798fy7e6c03bd0250ab52@mail.gmail.com>
References: <ae2f51270811252041q3c9b798fy7e6c03bd0250ab52@mail.gmail.com>
Message-ID: <da159fda0811260919k10e750f1vb3d78381d441771b@mail.gmail.com>

On Tue, Nov 25, 2008 at 11:41 PM, lakshmi pathi
<lakshmipathi.g at gmail.com> wrote:

> I'm using Fedora 7  with ext3 file system. (Kernel : 2.6.25.4)

Also, as a public service announcement, I'm obligated to remind you
that Fedora 7 is no longer maintained and will not receive updates,
even security fixes.  Therefore, I'd urge you to upgrade to Fedora 10
ASAP, or at least Fedora 9.



From pertusus at free.fr  Wed Nov 26 17:28:37 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 26 Nov 2008 18:28:37 +0100
Subject: shortening time passed in bodhi?
In-Reply-To: <1227717609.5276.54.camel@luminos.localdomain>
References: <20081126150440.GD2780@free.fr>
	<1227717609.5276.54.camel@luminos.localdomain>
Message-ID: <20081126172837.GJ2780@free.fr>

On Wed, Nov 26, 2008 at 08:40:09AM -0800, Jesse Keating wrote:
> 
> Yes.  The compose process (particularly now that we're pushing out
> updates for 8, 9, and 10) takes almost all of one work day, with only an
> hour or two of prep time before the push, so at best you'll likely get
> one per day.  I've been trying to do one at least every other day,

What is exactly a 'compose'? Is it what forces to go first in pending?

What about the other questions?

> We have a holiday week for a large number of US folks this week so the
> updates pushes may get a bit delayed this week as well.

That kind of delay is not problematic, since I guess it should be fixed by
having more people trusted to do the pushes and a signing server, I am
more worried about the unneeded delays.

--
Pat



From mschwendt at gmail.com  Wed Nov 26 17:32:53 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 26 Nov 2008 18:32:53 +0100
Subject: shortening time passed in bodhi?
In-Reply-To: <20081126152541.GA2408@amd.home.annexia.org>
References: <20081126150440.GD2780@free.fr> <ggjp06$uft$2@ger.gmane.org>
	<20081126152234.GE2780@free.fr>
	<20081126152541.GA2408@amd.home.annexia.org>
Message-ID: <20081126183253.8fcb0d98.mschwendt@gmail.com>

On Wed, 26 Nov 2008 15:25:41 +0000, Richard W.M. Jones wrote:

> On Wed, Nov 26, 2008 at 04:22:34PM +0100, Patrice Dumas wrote:
> > On Wed, Nov 26, 2008 at 04:12:06PM +0100, Kevin Kofler wrote:
> > > Patrice Dumas wrote:
> > > > Most of the time I push to stable when reminded by a mail (nice feature)
> > > > since nobody cares to give feedback on my updates and they are not
> > > > urgent. However recently I had an update I wanted to have in as soon as
> > > > possible since the app was broken without it. It took 8 days to have it
> > > > pushed, something like 2-3 days for the push to testing and the remaining
> > > > for the push and signing.
> > > 
> > > If you want it out as soon as possible, skip testing and push directly to
> > > stable.
> > 
> > I didn't noticed that. In that case it goes straight to stable, without
> > neing in a pending state at all?
> 
> Yes - I've used it a few times.

Not right. You can skip "testing", but you cannot skip "pending".



From jkeating at redhat.com  Wed Nov 26 17:47:43 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 26 Nov 2008 09:47:43 -0800
Subject: shortening time passed in bodhi?
In-Reply-To: <20081126172837.GJ2780@free.fr>
References: <20081126150440.GD2780@free.fr>
	<1227717609.5276.54.camel@luminos.localdomain>
	<20081126172837.GJ2780@free.fr>
Message-ID: <1227721663.5276.69.camel@luminos.localdomain>

On Wed, 2008-11-26 at 18:28 +0100, Patrice Dumas wrote:
> > Yes.  The compose process (particularly now that we're pushing out
> > updates for 8, 9, and 10) takes almost all of one work day, with only an
> > hour or two of prep time before the push, so at best you'll likely get
> > one per day.  I've been trying to do one at least every other day,
> 
> What is exactly a 'compose'? 

The compose is the process that:

1) gets a list of pending requests
2) signs them accordingly
3) asks bodhi to push the pending requests
4) moves packages within tags accordingly in koji
5) uses mash to create new repos for:
  5.1) dist-f8-updates
  5.2) dist-f8-updates-testing
  5.3) dist-f9-updates
  5.4) dist-f9-updates-testing
  5.5) dist-f10-updates
  5.6) dist-f10-updates-testing
6) makes those repos multilib (still mash here)
7) generates update metadata for the above repos (which updates are
bugfix, security, need reboot, etc...)
8) touch appropriate bugs in bugzilla based on bodhi requests
9) wait for rsync to finish
10) send mails to fedora-package-announce
11) set all states correct in bodhi itself for the pending requests

That's the rough outline, and I likely have a few of the steps out of
order, and some of that is done in parallel.  The more package updates
added (that is unique packages, not unique updates for a given package),
the longer the compose process takes as there is more to consider for
multilib, more packages for createrepo to fiddle with, etc...


> Is it what forces to go first in pending?

I'm not sure what you mean by this question.

> 
> What about the other questions?

I'll look 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/20081126/5a693f8d/attachment.sig>

From jkeating at redhat.com  Wed Nov 26 17:52:08 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 26 Nov 2008 09:52:08 -0800
Subject: shortening time passed in bodhi?
In-Reply-To: <20081126150440.GD2780@free.fr>
References: <20081126150440.GD2780@free.fr>
Message-ID: <1227721928.5276.73.camel@luminos.localdomain>

On Wed, 2008-11-26 at 16:04 +0100, Patrice Dumas wrote:
> What are the reasons for holding updates? Is there somebody actually
> verifying that the package works, doesn't break the distro or the like?
> What exactly do releng/QA people with updates, ie what checks?

At this point we haven't inserted any automated QA into the system.  I
have some plans, but they will mostly be post-build, rather than
post-bodhi request, although we could do it both times.

The main reason we haven't inserted any automated QA is that to get a
correct picture of what the distro would look like with that update
added takes a full compose, to ensure we get the right view of multilib,
and that we don't have an older copy of the package update floating in
repos resolving deps it shouldn't, etc...  The compose process itself is
extremely time and resource consuming and it unfortunately hasn't been
as high of a priority to tackle as it should have been.

I feel pretty confident that we've solved many of our other major
problems and can now focus attention on better QA through automation and
that will be one of my main focuses during the F11/F12 cycles.

-- 
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/20081126/1add223b/attachment.sig>

From mike at miketc.net  Wed Nov 26 18:00:59 2008
From: mike at miketc.net (Mike Chambers)
Date: Wed, 26 Nov 2008 12:00:59 -0600
Subject: NetworkManager doesn't email log files
Message-ID: <1227722459.21729.8.camel@scrappy.miketc.net>

When using NetworkManager, none of my log files (such as from epylog,
logwatch, crons, etc..) get emailed to my server (local network here at
home), all using static network.  When I go to the *old* network, they
are sent just fine.

Little example below...

Workstation - Using NetworkManager, log files are created but not sent,
such as from using epylog and logwatch, both run from cron.daily. They
are *tried* to be sent, but get Message delivery errors as I can see
from the mailq command. Turn off NM and turn on network, and the mailq
is sent right off the bat, and log files are sent like they are suppose
to from here on out.

Server - Configured the exact same no matter what is used and accepts no
matter what the workstation is using.  All using dnsmasq and /etc/hosts
for my local dns.

Any ideas?

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



From cra at WPI.EDU  Wed Nov 26 18:03:56 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Wed, 26 Nov 2008 13:03:56 -0500
Subject: NetworkManager doesn't email log files
In-Reply-To: <1227722459.21729.8.camel@scrappy.miketc.net>
References: <1227722459.21729.8.camel@scrappy.miketc.net>
Message-ID: <20081126180356.GH17030@angus.ind.WPI.EDU>

On Wed, Nov 26, 2008 at 12:00:59PM -0600, Mike Chambers wrote:
> When using NetworkManager, none of my log files (such as from epylog,
> logwatch, crons, etc..) get emailed to my server (local network here at
> home), all using static network.  When I go to the *old* network, they
> are sent just fine.

Probably related to NetworkManager not changing the system hostname 
and leaving it at the default localhost.localdomain.



From mike at miketc.net  Wed Nov 26 18:06:15 2008
From: mike at miketc.net (Mike Chambers)
Date: Wed, 26 Nov 2008 12:06:15 -0600
Subject: NetworkManager doesn't email log files
In-Reply-To: <20081126180356.GH17030@angus.ind.WPI.EDU>
References: <1227722459.21729.8.camel@scrappy.miketc.net>
	<20081126180356.GH17030@angus.ind.WPI.EDU>
Message-ID: <1227722775.21729.9.camel@scrappy.miketc.net>

On Wed, 2008-11-26 at 13:03 -0500, Chuck Anderson wrote:
> On Wed, Nov 26, 2008 at 12:00:59PM -0600, Mike Chambers wrote:
> > When using NetworkManager, none of my log files (such as from epylog,
> > logwatch, crons, etc..) get emailed to my server (local network here at
> > home), all using static network.  When I go to the *old* network, they
> > are sent just fine.
> 
> Probably related to NetworkManager not changing the system hostname 
> and leaving it at the default localhost.localdomain.

I looked and "hostname" reports it as correct.  Maybe there is a place
that I didn't see that might be it?

I did fine on an install  before that the hostname was the problem, but
it is correct from what I can see.

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



From jkeating at redhat.com  Tue Nov 25 14:45:18 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 25 Nov 2008 06:45:18 -0800
Subject: Cambridge Launched to Explore Solar System (Fedora 10)
Message-ID: <1227624318.5276.18.camel@luminos.localdomain>

DATELINE: 2008-11-25

KEY FINGERPRINT: 61A8 ABE0 91FF 9FBB F4B0 7709 BF22 6FCC 4EBF C273

LOCATION: GEOSYNC ORBIT, FEDORA SPACE STATION VIA GLOBAL IRC NETWORK

BROADCASTING: FREEDOM FRIENDS FEATURES FIRST

(Cue J. Strauss' "Blue Danube.")

THIS IS FEDORA SPACE OPERATIONS ANNOUNCING with great pleasure the
successful launch of the new ship, Fedora 10: "Cambridge."

Strapped into the pilot seats are the latest GNOME (2.24) and KDE (4.1),
accompanied on their amazing journey by an all star crew of glitch free
audio, better printing and webcam support, and a new faster graphical
startup.

Also on this ride are wireless connection sharing and the next evolution
in PackageKit, hooking through your multimedia applications to help
install supporting software (codecs).

For developers and system administrators on this mission, we have built
in appliance tools, Eclipse 3.4, NetBeans IDE, improved virtualization
management with remote installation and storage capabilities, RPM 4.6,
and new security auditing toolsets.

Please remember to polarize viewports to properly enjoy Cambridge's
brand new graphics theme, "Solar," shining on the desktop. Also on this
flight is a new lightweight desktop environment, LXDE, joining the more
recent desktop envionment crew member, Sugar (from the starship OLPC
XO), and the venerable GNOME, KDE, and XFCE.

We are now leaving drydock for a 13-month mission of innovation and
exploration. Crew members and guests are invited to the forward lounge
to use, study, modify, and redistribute.

Get your copy of Fedora 10 today:

http://get.fedoraproject.org/

Join the many thousands of Fedora particpants and contributors:

http://join.fedoraproject.org/

If you missed the official launch, attend a Fedora 10 Launch Party near
you:

http://fedoraproject.org/wiki/FedoraEvents/ReleaseParty




[ This message was created by the Fedora Documentation Project ]

-- 
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/20081125/e6a248b0/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  Wed Nov 26 18:08:20 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 26 Nov 2008 19:08:20 +0100
Subject: shortening time passed in bodhi?
In-Reply-To: <1227721663.5276.69.camel@luminos.localdomain>
References: <20081126150440.GD2780@free.fr>
	<1227717609.5276.54.camel@luminos.localdomain>
	<20081126172837.GJ2780@free.fr>
	<1227721663.5276.69.camel@luminos.localdomain>
Message-ID: <20081126180820.GM2780@free.fr>

On Wed, Nov 26, 2008 at 09:47:43AM -0800, Jesse Keating wrote:
> 
> The compose is the process that:
> 
> 1) gets a list of pending requests
> 2) signs them accordingly
> 3) asks bodhi to push the pending requests
> 4) moves packages within tags accordingly in koji
> 5) uses mash to create new repos for:
>   5.1) dist-f8-updates
>   5.2) dist-f8-updates-testing
>   5.3) dist-f9-updates
>   5.4) dist-f9-updates-testing
>   5.5) dist-f10-updates
>   5.6) dist-f10-updates-testing
> 6) makes those repos multilib (still mash here)
> 7) generates update metadata for the above repos (which updates are
> bugfix, security, need reboot, etc...)
> 8) touch appropriate bugs in bugzilla based on bodhi requests
> 9) wait for rsync to finish
> 10) send mails to fedora-package-announce
> 11) set all states correct in bodhi itself for the pending requests
> 
> That's the rough outline, and I likely have a few of the steps out of
> order, and some of that is done in parallel. 

Indeed, that's a lot of steps. But what steps take so long? There are
some steps that I don't really understand, but I can't see which one
would take more than some minutes, except maybe 9) if there are a lot of
packages -- and 4) if 4) involves transferring the packages. In any case
I guess that you know what you are doing, so my questions are certainly
very naive.

Also I am not really knowledgable, but maybe 9) could be done right 
after 7), if it is a long step?

> > Is it what forces to go first in pending?
> 
> I'm not sure what you mean by this question.

You answered above.

--
Pat



From pertusus at free.fr  Wed Nov 26 18:12:08 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 26 Nov 2008 19:12:08 +0100
Subject: shortening time passed in bodhi?
In-Reply-To: <1227721928.5276.73.camel@luminos.localdomain>
References: <20081126150440.GD2780@free.fr>
	<1227721928.5276.73.camel@luminos.localdomain>
Message-ID: <20081126181208.GN2780@free.fr>

On Wed, Nov 26, 2008 at 09:52:08AM -0800, Jesse Keating wrote:
> On Wed, 2008-11-26 at 16:04 +0100, Patrice Dumas wrote:
> > What are the reasons for holding updates? Is there somebody actually
> > verifying that the package works, doesn't break the distro or the like?
> > What exactly do releng/QA people with updates, ie what checks?
> 
> At this point we haven't inserted any automated QA into the system.  I
> have some plans, but they will mostly be post-build, rather than
> post-bodhi request, although we could do it both times.

Ok. You still haven't explained what checks were done, especially
between pending and stable or testing.

> The main reason we haven't inserted any automated QA is that to get a
> correct picture of what the distro would look like with that update
> added takes a full compose, to ensure we get the right view of multilib,
> and that we don't have an older copy of the package update floating in
> repos resolving deps it shouldn't, etc...  The compose process itself is
> extremely time and resource consuming and it unfortunately hasn't been
> as high of a priority to tackle as it should have been.

Right. This is a good reason, especially if compose takes one day. Still
it doesn't explain the other delays. I still can't see what takes time
besides composing, nor why there is a pending state.

--
Pat



From bl0ngo067 at aim.com  Wed Nov 26 18:14:58 2008
From: bl0ngo067 at aim.com (bl0ngo067 at aim.com)
Date: Wed, 26 Nov 2008 13:14:58 -0500
Subject: libdvdcss - where did it go?
Message-ID: <8CB1E0A06D7FF0A-1044-B9D@MBLK-M01.sysops.aol.com>

I cannot play dvd's without libdvdcss, and when I searched for it in the repos it did not show up.  Is this packaged abandoned, or has it been replaced by something else?  If it was replaced, totem still has a window that pops up informing the user that they need to install libdvdcss to play dvds.

FYI I am using Fedora 10.

Brad Longo


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081126/7646ddf7/attachment.htm>

From dennis at ausil.us  Wed Nov 26 18:19:45 2008
From: dennis at ausil.us (Dennis Gilmore)
Date: Wed, 26 Nov 2008 12:19:45 -0600
Subject: Reminder:  no new F-8 cvs branches
Message-ID: <200811261219.45611.dennis@ausil.us>

Hi All,

Since Fedora 10 was released yesterday new CVS branches for F-8 will be 
allowed.  http://fedoraproject.org/wiki/PackageMaintainers/Policy/EOL list the 
policy in effect this means that F-8 is now in a maintenance only cycle,  with 
EOL fast approaching,  the exact EOL date will be set at the FESCo meeting  
Today.


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/20081126/c75736a6/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 Jochen at herr-schmitt.de  Wed Nov 26 18:23:25 2008
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Wed, 26 Nov 2008 19:23:25 +0100
Subject: libdvdcss - where did it go?
In-Reply-To: <8CB1E0A06D7FF0A-1044-B9D@MBLK-M01.sysops.aol.com>
References: <8CB1E0A06D7FF0A-1044-B9D@MBLK-M01.sysops.aol.com>
Message-ID: <492D941D.8020908@herr-schmitt.de>

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

bl0ngo067 at aim.com schrieb:
> I cannot play dvd's without libdvdcss, and when I searched for it in
the repos it did not show up.  Is this packaged abandoned, or has it
been replaced by something else?  If it was replaced, totem still has a
window that pops up informing the user that they need to install
libdvdcss to play dvds.
1.) libdvdcss was never been an official part of Fedora. It ware
distribute via the livan repository, which never exist
anymore.

2.) AFAIK RPMFusion has decided not th distribute libdvdcss based on
legal issues.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkktlBQACgkQT2AHK6txfgwzwwCgybywbSHw5cHD9+/MTbldMdxM
YxIAn2jOqQh1VF0ZZacg+l3C/A7A+nkl
=NKnF
-----END PGP SIGNATURE-----



From rdieter at math.unl.edu  Wed Nov 26 18:29:45 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 26 Nov 2008 12:29:45 -0600
Subject: libdvdcss - where did it go?
References: <8CB1E0A06D7FF0A-1044-B9D@MBLK-M01.sysops.aol.com>
	<492D941D.8020908@herr-schmitt.de>
Message-ID: <ggk4ip$b1k$1@ger.gmane.org>

Jochen Schmitt wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> bl0ngo067 at aim.com schrieb:
>> I cannot play dvd's without libdvdcss, and when I searched for it in
> the repos it did not show up.  Is this packaged abandoned, or has it
> been replaced by something else?  If it was replaced, totem still has a
> window that pops up informing the user that they need to install
> libdvdcss to play dvds.
> 1.) libdvdcss was never been an official part of Fedora. It ware
> distribute via the livan repository, which never exist
> anymore.

livna still exists, and still distributes libdvdcss (but that's about it).

> 2.) AFAIK RPMFusion has decided not th distribute libdvdcss based on
> legal issues.

everything else has gone to rpmfusion.

-- Rex



From dcbw at redhat.com  Wed Nov 26 18:31:54 2008
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 26 Nov 2008 13:31:54 -0500
Subject: NetworkManager doesn't email log files
In-Reply-To: <20081126180356.GH17030@angus.ind.WPI.EDU>
References: <1227722459.21729.8.camel@scrappy.miketc.net>
	<20081126180356.GH17030@angus.ind.WPI.EDU>
Message-ID: <1227724314.25339.24.camel@localhost.localdomain>

On Wed, 2008-11-26 at 13:03 -0500, Chuck Anderson wrote:
> On Wed, Nov 26, 2008 at 12:00:59PM -0600, Mike Chambers wrote:
> > When using NetworkManager, none of my log files (such as from epylog,
> > logwatch, crons, etc..) get emailed to my server (local network here at
> > home), all using static network.  When I go to the *old* network, they
> > are sent just fine.
> 
> Probably related to NetworkManager not changing the system hostname 
> and leaving it at the default localhost.localdomain.

NM will change the hostname just like dhclient-script does, if you have
not set a persistent hostname in /etc/sysconfig/network.  If you have
set a persistent hostname in /etc/sysconfig/network, NM will *always*
use that hostname.

It may be the issue where sendmail is happily unaware of network changes
including hostname changes.  If, after connecting, you do '/sbin/service
sendmail restart' does that start things working?  The real fix here is
to hit stupid services that don't handle network changes in the face
with a nail-studded board, and repeat if they get back up, until they
stop getting up and just lie there.  But failing that, forcing them to
restart via a dispatcher script when network changes occur may be the
quickest alternative.

Dan




From dennis at ausil.us  Wed Nov 26 18:31:04 2008
From: dennis at ausil.us (Dennis Gilmore)
Date: Wed, 26 Nov 2008 12:31:04 -0600
Subject: Reminder:  no new F-8 cvs branches
Message-ID: <200811261231.04591.dennis@ausil.us>

On Wednesday 26 November 2008 12:19:45 pm Dennis Gilmore wrote:
> Hi All,
>
> Since Fedora 10 was released yesterday new CVS branches for F-8 will be
> allowed.  http://fedoraproject.org/wiki/PackageMaintainers/Policy/EOL list
> the policy in effect this means that F-8 is now in a maintenance only
> cycle,  with EOL fast approaching,  the exact EOL date will be set at the
> FESCo meeting Today.

sorry  the first sentence should read "Since Fedora 10 was released yesterday 
new CVS branches for F-8 will not be allowed."

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/20081126/69aea3ed/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 Jochen at herr-schmitt.de  Wed Nov 26 18:34:13 2008
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Wed, 26 Nov 2008 19:34:13 +0100
Subject: libdvdcss - where did it go?
In-Reply-To: <ggk4ip$b1k$1@ger.gmane.org>
References: <8CB1E0A06D7FF0A-1044-B9D@MBLK-M01.sysops.aol.com>	<492D941D.8020908@herr-schmitt.de>
	<ggk4ip$b1k$1@ger.gmane.org>
Message-ID: <492D96A5.9090302@herr-schmitt.de>

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

Rex Dieter schrieb:
> Jochen Schmitt wrote:
Thats are good news.
>
> livna still exists, and still distributes libdvdcss (but that's
> about it). 2.) AFAIK RPMFusion has decided not th distribute
> libdvdcss based on legal issues.
>
> everything else has gone to rpmfusion.
>
Yes I have prefered if libdvdcss were gone into non-free of rpmfusion.
But if
livna will still exist in the future thats is a acceptable solution.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkktlpoACgkQT2AHK6txfgwf6ACgiP77pF8ElPlf0+t1YnXDfv8q
f8IAn0waLdNwijdrk2hwUgIavDi1v83y
=UZfQ
-----END PGP SIGNATURE-----



From orcanbahri at yahoo.com  Wed Nov 26 18:40:32 2008
From: orcanbahri at yahoo.com (Orcan Ogetbil)
Date: Wed, 26 Nov 2008 10:40:32 -0800 (PST)
Subject: libdvdcss - where did it go?
In-Reply-To: <492D96A5.9090302@herr-schmitt.de>
Message-ID: <834776.66002.qm@web32804.mail.mud.yahoo.com>

--- On Wed, 11/26/08, Jochen Schmitt  wrote:
> 
> Rex Dieter schrieb:
> > 2.) AFAIK RPMFusion has decided not th
> distribute
> > libdvdcss based on legal issues.
> >
> > everything else has gone to rpmfusion.
> >
> Yes I have prefered if libdvdcss were gone into non-free of
> rpmfusion.

Yes, many people do too, and many people don't. To follow the heated discussions, please visit the mailing list archives of rpmfusion.

-oget


      



From mike at miketc.net  Wed Nov 26 18:40:50 2008
From: mike at miketc.net (Mike Chambers)
Date: Wed, 26 Nov 2008 12:40:50 -0600
Subject: NetworkManager doesn't email log files
In-Reply-To: <1227724314.25339.24.camel@localhost.localdomain>
References: <1227722459.21729.8.camel@scrappy.miketc.net>
	<20081126180356.GH17030@angus.ind.WPI.EDU>
	<1227724314.25339.24.camel@localhost.localdomain>
Message-ID: <1227724850.2921.2.camel@scrappy.miketc.net>

On Wed, 2008-11-26 at 13:31 -0500, Dan Williams wrote:
> O
> NM will change the hostname just like dhclient-script does, if you have
> not set a persistent hostname in /etc/sysconfig/network.  If you have
> set a persistent hostname in /etc/sysconfig/network, NM will *always*
> use that hostname.

The hostname was there and listed the whole time, from install (I used
askmethod during install so I could get NM to use static, as GUI didn't
allow me to).
> 
> It may be the issue where sendmail is happily unaware of network changes
> including hostname changes.  If, after connecting, you do '/sbin/service
> sendmail restart' does that start things working?  The real fix here is
> to hit stupid services that don't handle network changes in the face
> with a nail-studded board, and repeat if they get back up, until they
> stop getting up and just lie there.  But failing that, forcing them to
> restart via a dispatcher script when network changes occur may be the
> quickest alternative.

No, sendmail wouldn't still send it.  I did go to network service and
relooked at files (ifcfg-eth0 mainly), saw any differences with
NetworkManger and with network.  Went back to NM just now and ran epylog
cron manually and it got sent.  Sooo, it *might* be working now.  So
maybe something in ifcfg helped and allows it to go now?

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



From jkeating at redhat.com  Wed Nov 26 19:05:40 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 26 Nov 2008 11:05:40 -0800
Subject: shortening time passed in bodhi?
In-Reply-To: <20081126180820.GM2780@free.fr>
References: <20081126150440.GD2780@free.fr>
	<1227717609.5276.54.camel@luminos.localdomain>
	<20081126172837.GJ2780@free.fr>
	<1227721663.5276.69.camel@luminos.localdomain>
	<20081126180820.GM2780@free.fr>
Message-ID: <1227726340.5276.83.camel@luminos.localdomain>

On Wed, 2008-11-26 at 19:08 +0100, Patrice Dumas wrote:
> Indeed, that's a lot of steps. But what steps take so long? There are
> some steps that I don't really understand, but I can't see which one
> would take more than some minutes, except maybe 9) if there are a lot of
> packages -- and 4) if 4) involves transferring the packages. In any case
> I guess that you know what you are doing, so my questions are certainly
> very naive.

The parts that take the longest are sorting out the signed packages from
koji output into a directory structure that is suitable for updates via
hardlinks, and then the createrepo runs.  Sorting the package takes a
little time as koji puts packages into dirs of just <arch>, which can
include noarch.  debuginfo is put along side the other arch packages.
We have to sort out the debuginfo, copy around any noarch, but also
examine the srpm the noarch package came from to determine if the noarch
package has any Exclude or ExclusiveArch settings.  This involves a lot
of filesystem work and tends to be a lengthy process, as is just the
mere querying of koji for the 'latest-tagged' for each of the tags.

As for repodata, for each tag (dist-f{8,9,10}-{updates,updates-testing})
we have to create repodata for:

i386, x86_64, ppc, pp64
  debuginfo
source

that's 6 repos worth of packages to run createrepo on, across an NFS
mount.  For two of those repos (x86_64, ppc) in order to make multilib
we first copy in all the compat arch packages (i386, ppc64), run
createrepo, run through an algorithm to select certain ones as being
"multilib" and then depsolve the rest, throwing out what's not needed,
and then running createrepo again.

So to recap, for each tag, we have 11 createrepo calls, and since we're
doing 6 tags at this point, that's 66 calls to createrepo, again all
over NFS (since we don't want to put the software that pushes updates on
the same machine that holds the filesystem that koji uses, and we want
to use hardlinks to avoid adding time to copy all those packages over
NFS).

Right now, I do believe there is a faulty switch between the machine(s)
capable of doing the repo creations and the nfs server, which is capping
bandwidth around 100mb/s rather than 1000mb/s.  We've been trying to get
that fixed for nearly a year, and will continue trying, Mike McGrath is
scheduled to be onsite in the colo to do various things such as fixing
this in December. 

As stated in the previous email, there are steps that are done in
parallel, like many of the createrepo calls.  But there is only so much
bandwidth between the caller and the NFS share, and there is only so
much memory in the caller, and there are only so many tasks that can
truly be done in parallel.

-- 
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/20081126/afda196a/attachment.sig>

From jkeating at redhat.com  Wed Nov 26 19:08:01 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 26 Nov 2008 11:08:01 -0800
Subject: shortening time passed in bodhi?
In-Reply-To: <20081126181208.GN2780@free.fr>
References: <20081126150440.GD2780@free.fr>
	<1227721928.5276.73.camel@luminos.localdomain>
	<20081126181208.GN2780@free.fr>
Message-ID: <1227726481.5276.85.camel@luminos.localdomain>

On Wed, 2008-11-26 at 19:12 +0100, Patrice Dumas wrote:
> 
> Ok. You still haven't explained what checks were done, especially
> between pending and stable or testing.
> 
> > The main reason we haven't inserted any automated QA is that to get a
> > correct picture of what the distro would look like with that update
> > added takes a full compose, to ensure we get the right view of multilib,
> > and that we don't have an older copy of the package update floating in
> > repos resolving deps it shouldn't, etc...  The compose process itself is
> > extremely time and resource consuming and it unfortunately hasn't been
> > as high of a priority to tackle as it should have been.
> 
> Right. This is a good reason, especially if compose takes one day. Still
> it doesn't explain the other delays. I still can't see what takes time
> besides composing, nor why there is a pending state.


I guess I'm not fully understanding your question.

A user submits an update to bodhi, and when they are satisfied that they
have all the builds added correctly and that the text is right, they
request it be pushed either to testing, or to stable.  After that the
only delay is the time it takes for me, the pusher, to handle the
pending requests.

The checks are quite simple in bodhi I do believe, I think it just
checks to make sure what you requested is tagged appropriately at the
time of request.  The rest of it is left up to users of updates-testing
to report any problems to the maintainer, either through bugzilla or
bodhi karma, or both.

-- 
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/20081126/019a9c38/attachment.sig>

From jonstanley at gmail.com  Wed Nov 26 19:07:40 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Wed, 26 Nov 2008 14:07:40 -0500
Subject: BugZappers/HouseKeeping is a policy and seems incomplete
In-Reply-To: <f7b9b84c6f7bd9e38e9bf05ecd622a22.squirrel@arekh.dyndns.org>
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>
	<f7b9b84c6f7bd9e38e9bf05ecd622a22.squirrel@arekh.dyndns.org>
Message-ID: <da159fda0811261107w1646b877u84271faa29d533a5@mail.gmail.com>

On Wed, Nov 26, 2008 at 11:01 AM, Nicolas Mailhot
<nicolas.mailhot at laposte.net> wrote:

> I've seen rawhide bugs blocking F11Target requalified as F10 bugs
> recently. Madness.

Ouch, that's not supposed to be that way, entirely my fault (I
provided the queries to be used, and it seems I forgot those, though
the intention was to exclude them). :(

I can go manually fix all of those. Sorry for the noise.

Twenty lashings for me :)



From pertusus at free.fr  Wed Nov 26 19:19:26 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 26 Nov 2008 20:19:26 +0100
Subject: shortening time passed in bodhi?
In-Reply-To: <1227726481.5276.85.camel@luminos.localdomain>
References: <20081126150440.GD2780@free.fr>
	<1227721928.5276.73.camel@luminos.localdomain>
	<20081126181208.GN2780@free.fr>
	<1227726481.5276.85.camel@luminos.localdomain>
Message-ID: <20081126191926.GP2780@free.fr>

On Wed, Nov 26, 2008 at 11:08:01AM -0800, Jesse Keating wrote:
> On Wed, 2008-11-26 at 19:12 +0100, Patrice Dumas wrote:
> > 
> > Right. This is a good reason, especially if compose takes one day. Still
> > it doesn't explain the other delays. I still can't see what takes time
> > besides composing, nor why there is a pending state.
> 
> request it be pushed either to testing, or to stable.  After that the
> only delay is the time it takes for me, the pusher, to handle the
> pending requests.
> 
> The checks are quite simple in bodhi I do believe, I think it just
> checks to make sure what you requested is tagged appropriately at the
> time of request. 

I guess that it is that part that I would like to be skipped, such that
there is no need of any checking, and the update goes straigth to
testing or stable, without being even in pending state.

I know that not all packages have dist tags, but shouldn't dist tag be
enough to discriminate faulty tags? Packages without dist tag would then
be checked manually.

--
Pat



From bruno at wolff.to  Wed Nov 26 19:23:35 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 26 Nov 2008 13:23:35 -0600
Subject: Fedora Release Engineering Meeting Recap 2008-11-24
In-Reply-To: <1227717201.5276.49.camel@luminos.localdomain>
References: <492C5D62.4030304@redhat.com> <492CE464.5060003@leemhuis.info>
	<1227717201.5276.49.camel@luminos.localdomain>
Message-ID: <20081126192335.GA26562@wolff.to>

On Wed, Nov 26, 2008 at 08:33:21 -0800,
  Jesse Keating <jkeating at redhat.com> wrote:
> 
> My continued main concern with this though is fracturing the testing
> pool, and not capturing enough eyes/minds on the frozen content for the
> release.  The sad fact of many releases is that many people seem to not
> start looking at overall polish and bugfixing until the final freeze is
> hit.  They treat the final freeze as the last development day and expect
> to have time after that to do bugfixing.  Combining that with taking
> users away from the QA on those frozen bits could lead to an even worse
> release.  So I think there are two problems to solve there.

I didn't find continual testing of the frozen bits all that useful. I wanted
to continue tracking F10 bugfixes especially xorg-x11-drv-ati and kernel
fixes since Dave Airlie was trying really hard to get KMS in shape for the
release and rapid feedback seemed help.

So I think there are three tracks that should be under consideration, not just
two. One is tracking the release, another release plus potential zero day
updates and the last the next rawhide.



From jkeating at redhat.com  Wed Nov 26 19:32:02 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 26 Nov 2008 11:32:02 -0800
Subject: shortening time passed in bodhi?
In-Reply-To: <20081126191926.GP2780@free.fr>
References: <20081126150440.GD2780@free.fr>
	<1227721928.5276.73.camel@luminos.localdomain>
	<20081126181208.GN2780@free.fr>
	<1227726481.5276.85.camel@luminos.localdomain>
	<20081126191926.GP2780@free.fr>
Message-ID: <1227727922.5276.90.camel@luminos.localdomain>

On Wed, 2008-11-26 at 20:19 +0100, Patrice Dumas wrote:
> I guess that it is that part that I would like to be skipped, such that
> there is no need of any checking, and the update goes straigth to
> testing or stable, without being even in pending state.
> 
> I know that not all packages have dist tags, but shouldn't dist tag be
> enough to discriminate faulty tags? Packages without dist tag would then
> be checked manually.

er, this time period is I do believe less than a second, and it's done
automatically by bodhi when you make the request.  It just fails the
request if the tag isn't correct.

The pending state is there because people often work on an update
request at multiple times, and want to be able to add to it and adjust
it before doing the final push request, and also from a app code point
of view I think the update object has to have one form of existence
outside of either push requested or pushed.

So again, I think we're misunderstanding each other.  What problem are
you trying to solve?

-- 
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/20081126/ce32cd30/attachment.sig>

From drago01 at gmail.com  Wed Nov 26 20:06:09 2008
From: drago01 at gmail.com (drago01)
Date: Wed, 26 Nov 2008 21:06:09 +0100
Subject: shortening time passed in bodhi?
In-Reply-To: <1227727922.5276.90.camel@luminos.localdomain>
References: <20081126150440.GD2780@free.fr>
	<1227721928.5276.73.camel@luminos.localdomain>
	<20081126181208.GN2780@free.fr>
	<1227726481.5276.85.camel@luminos.localdomain>
	<20081126191926.GP2780@free.fr>
	<1227727922.5276.90.camel@luminos.localdomain>
Message-ID: <f6ca9fed0811261206v56d46cf2pebb683521aca0853@mail.gmail.com>

2008/11/26 Jesse Keating <jkeating at redhat.com>:
> On Wed, 2008-11-26 at 20:19 +0100, Patrice Dumas wrote:

> So again, I think we're misunderstanding each other.  What problem are
> you trying to solve?
If I got it correctly then he wants that packages hit the repo as soon
as possible without any delays. That means that he bodhi should start
the compose process right after the update has been submitted.



From bruno at wolff.to  Wed Nov 26 20:22:24 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 26 Nov 2008 14:22:24 -0600
Subject: libdvdcss - where did it go?
In-Reply-To: <492D96A5.9090302@herr-schmitt.de>
References: <8CB1E0A06D7FF0A-1044-B9D@MBLK-M01.sysops.aol.com>
	<492D941D.8020908@herr-schmitt.de> <ggk4ip$b1k$1@ger.gmane.org>
	<492D96A5.9090302@herr-schmitt.de>
Message-ID: <20081126202224.GA29161@wolff.to>

On Wed, Nov 26, 2008 at 19:34:13 +0100,
  Jochen Schmitt <Jochen at herr-schmitt.de> wrote:
> Yes I have prefered if libdvdcss were gone into non-free of rpmfusion.
> But if
> livna will still exist in the future thats is a acceptable solution.

The problem isn't its freeness, but rather it is a DMCA violation to provide
it in the US. RPMFusion has US based mirrors, so including it would be a
problem for them.



From konrad at tylerc.org  Wed Nov 26 20:25:37 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Wed, 26 Nov 2008 12:25:37 -0800
Subject: libdvdcss - where did it go?
In-Reply-To: <20081126202224.GA29161@wolff.to>
References: <8CB1E0A06D7FF0A-1044-B9D@MBLK-M01.sysops.aol.com>
	<492D96A5.9090302@herr-schmitt.de>
	<20081126202224.GA29161@wolff.to>
Message-ID: <200811261225.37813.konrad@tylerc.org>

On Wednesday 26 November 2008 12:22:24 pm Bruno Wolff III wrote:
> On Wed, Nov 26, 2008 at 19:34:13 +0100,
>
>   Jochen Schmitt <Jochen at herr-schmitt.de> wrote:
> > Yes I have prefered if libdvdcss were gone into non-free of rpmfusion.
> > But if
> > livna will still exist in the future thats is a acceptable solution.
>
> The problem isn't its freeness, but rather it is a DMCA violation to
> provide it in the US. RPMFusion has US based mirrors, so including it would
> be a problem for them.

So did Livna but that didn't exactly stop them. The problem is that including 
it loses RPM Fusion some free promotion and so they've chosen to tell users 
to get the rpm from somewhere else if they need it (for example, Livna still 
has it).

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




From jkeating at redhat.com  Wed Nov 26 20:26:07 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 26 Nov 2008 12:26:07 -0800
Subject: shortening time passed in bodhi?
In-Reply-To: <f6ca9fed0811261206v56d46cf2pebb683521aca0853@mail.gmail.com>
References: <20081126150440.GD2780@free.fr>
	<1227721928.5276.73.camel@luminos.localdomain>
	<20081126181208.GN2780@free.fr>
	<1227726481.5276.85.camel@luminos.localdomain>
	<20081126191926.GP2780@free.fr>
	<1227727922.5276.90.camel@luminos.localdomain>
	<f6ca9fed0811261206v56d46cf2pebb683521aca0853@mail.gmail.com>
Message-ID: <1227731167.5276.91.camel@luminos.localdomain>

On Wed, 2008-11-26 at 21:06 +0100, drago01 wrote:
> If I got it correctly then he wants that packages hit the repo as soon
> as possible without any delays. That means that he bodhi should start
> the compose process right after the update has been submitted.

Why should it do that and make every other update wait?  Also, that's
not possible until we have some form of automated signing.

-- 
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/20081126/de3ed152/attachment.sig>

From lemenkov at gmail.com  Wed Nov 26 20:38:02 2008
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Wed, 26 Nov 2008 23:38:02 +0300
Subject: libdvdcss - where did it go?
In-Reply-To: <492D96A5.9090302@herr-schmitt.de>
References: <8CB1E0A06D7FF0A-1044-B9D@MBLK-M01.sysops.aol.com>
	<492D941D.8020908@herr-schmitt.de> <ggk4ip$b1k$1@ger.gmane.org>
	<492D96A5.9090302@herr-schmitt.de>
Message-ID: <adf480660811261238j39c0bf7cn6eea7424dc88dfdc@mail.gmail.com>

> Yes I have prefered if libdvdcss were gone into non-free of rpmfusion.

There is no reason to move libdvdcss into rpmfusion-non-free.

* It's opensourced
* It's freely distributable

-- 
With best regards!



From sgrubb at redhat.com  Wed Nov 26 20:32:25 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Wed, 26 Nov 2008 15:32:25 -0500
Subject: No way to shut down from, gdm in F-10
Message-ID: <200811261539.31233.sgrubb@redhat.com>

Hi,

I booted F-10 up into run level 3. Logged in as root. Did some things and ran 
init 5. After I was done using the computer, I wanted to shut it down. There 
is absolutely nothing that I can click on that will let me shutdown the 
computer. (Try it.) What I ended up doing is logging in and opening a terminal 
and typing poweroff, but I don't think that is the right way for a gdm session 
to end. 

Why are we doing it like this?

-Steve



From skvidal at fedoraproject.org  Wed Nov 26 20:44:47 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 26 Nov 2008 15:44:47 -0500 (EST)
Subject: No way to shut down from, gdm in F-10
In-Reply-To: <200811261539.31233.sgrubb@redhat.com>
References: <200811261539.31233.sgrubb@redhat.com>
Message-ID: <alpine.LFD.2.00.0811261544290.15608@localhost.localdomain>



On Wed, 26 Nov 2008, Steve Grubb wrote:

> Hi,
>
> I booted F-10 up into run level 3. Logged in as root. Did some things and ran
> init 5. After I was done using the computer, I wanted to shut it down. There
> is absolutely nothing that I can click on that will let me shutdown the
> computer. (Try it.) What I ended up doing is logging in and opening a terminal
> and typing poweroff, but I don't think that is the right way for a gdm session
> to end.
>
> Why are we doing it like this?
>

The restart/shutdown buttons aren't at the bottom of the login box in gdm?

-sv



From notting at redhat.com  Wed Nov 26 20:52:53 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 26 Nov 2008 15:52:53 -0500
Subject: No way to shut down from, gdm in F-10
In-Reply-To: <200811261539.31233.sgrubb@redhat.com>
References: <200811261539.31233.sgrubb@redhat.com>
Message-ID: <20081126205253.GA13998@nostromo.devel.redhat.com>

Steve Grubb (sgrubb at redhat.com) said: 
> I booted F-10 up into run level 3. Logged in as root. Did some things and ran 
> init 5. After I was done using the computer, I wanted to shut it down. There 
> is absolutely nothing that I can click on that will let me shutdown the 
> computer. (Try it.) What I ended up doing is logging in and opening a terminal 
> and typing poweroff, but I don't think that is the right way for a gdm session 
> to end. 
> 
> Why are we doing it like this?

It's handled via ConsoleKit - is it running? Is it functioning correctly?

Bill



From ivazqueznet at gmail.com  Wed Nov 26 21:20:04 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Wed, 26 Nov 2008 16:20:04 -0500
Subject: No way to shut down from, gdm in F-10
In-Reply-To: <200811261539.31233.sgrubb@redhat.com>
References: <200811261539.31233.sgrubb@redhat.com>
Message-ID: <1227734404.3891.23.camel@ignacio.lan>

On Wed, 2008-11-26 at 15:32 -0500, Steve Grubb wrote:
> I booted F-10 up into run level 3. Logged in as root. Did some things and ran 
> init 5. After I was done using the computer, I wanted to shut it down. There 
> is absolutely nothing that I can click on that will let me shutdown the 
> computer.

Did you try cancelling the login?

-- 
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/20081126/46cb01a7/attachment.sig>

From sgrubb at redhat.com  Wed Nov 26 21:48:31 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Wed, 26 Nov 2008 16:48:31 -0500
Subject: No way to shut down from, gdm in F-10
In-Reply-To: <alpine.LFD.2.00.0811261544290.15608@localhost.localdomain>
References: <200811261539.31233.sgrubb@redhat.com>
	<alpine.LFD.2.00.0811261544290.15608@localhost.localdomain>
Message-ID: <200811261648.31271.sgrubb@redhat.com>

On Wednesday 26 November 2008 15:44:47 Seth Vidal wrote:
> > I booted F-10 up into run level 3. Logged in as root. Did some things and
> > ran init 5. After I was done using the computer, I wanted to shut it
> > down. There is absolutely nothing that I can click on that will let me
> > shutdown the computer. (Try it.) What I ended up doing is logging in and
> > opening a terminal and typing poweroff, but I don't think that is the
> > right way for a gdm session to end.
> >
> > Why are we doing it like this?
>
> The restart/shutdown buttons aren't at the bottom of the login box in gdm?

Yep they sure are. Clicking on it says it can't shutdown. Try it.

-Steve



From sgrubb at redhat.com  Wed Nov 26 21:50:53 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Wed, 26 Nov 2008 16:50:53 -0500
Subject: No way to shut down from, gdm in F-10
In-Reply-To: <20081126205253.GA13998@nostromo.devel.redhat.com>
References: <200811261539.31233.sgrubb@redhat.com>
	<20081126205253.GA13998@nostromo.devel.redhat.com>
Message-ID: <200811261650.53746.sgrubb@redhat.com>

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.

-Steve



From skvidal at fedoraproject.org  Wed Nov 26 21:56:34 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 26 Nov 2008 16:56:34 -0500 (EST)
Subject: No way to shut down from, gdm in F-10
In-Reply-To: <200811261648.31271.sgrubb@redhat.com>
References: <200811261539.31233.sgrubb@redhat.com>
	<alpine.LFD.2.00.0811261544290.15608@localhost.localdomain>
	<200811261648.31271.sgrubb@redhat.com>
Message-ID: <alpine.LFD.2.00.0811261656240.15608@localhost.localdomain>



On Wed, 26 Nov 2008, Steve Grubb wrote:

> On Wednesday 26 November 2008 15:44:47 Seth Vidal wrote:
>>> I booted F-10 up into run level 3. Logged in as root. Did some things and
>>> ran init 5. After I was done using the computer, I wanted to shut it
>>> down. There is absolutely nothing that I can click on that will let me
>>> shutdown the computer. (Try it.) What I ended up doing is logging in and
>>> opening a terminal and typing poweroff, but I don't think that is the
>>> right way for a gdm session to end.
>>>
>>> Why are we doing it like this?
>>
>> The restart/shutdown buttons aren't at the bottom of the login box in gdm?
>
> Yep they sure are. Clicking on it says it can't shutdown. Try it.

worked for me on the live image.

-sv




From sgrubb at redhat.com  Wed Nov 26 22:15:18 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Wed, 26 Nov 2008 17:15:18 -0500
Subject: No way to shut down from, gdm in F-10
In-Reply-To: <alpine.LFD.2.00.0811261656240.15608@localhost.localdomain>
References: <200811261539.31233.sgrubb@redhat.com>
	<200811261648.31271.sgrubb@redhat.com>
	<alpine.LFD.2.00.0811261656240.15608@localhost.localdomain>
Message-ID: <200811261715.18821.sgrubb@redhat.com>

On Wednesday 26 November 2008 16:56:34 Seth Vidal wrote:
> >>> Why are we doing it like this?
> >>
> >> The restart/shutdown buttons aren't at the bottom of the login box in
> >> gdm?
> >
> > Yep they sure are. Clicking on it says it can't shutdown. Try it.
>
> worked for me on the live image.

Hmm...this is strange and I can't reproduce it now. Shutting down dumped me to 
the gdm login screen. Nothing there would let me shutdown. There were buttons 
to click on, but it said that it couldn't when I clicked on things. Next time 
I see this I'll try to gather more info.

-Steve



From mark.bidewell at alumni.clemson.edu  Wed Nov 26 23:11:50 2008
From: mark.bidewell at alumni.clemson.edu (Mark Bidewell)
Date: Wed, 26 Nov 2008 18:11:50 -0500
Subject: Fedora 10 and YUM
Message-ID: <bfdeacfa0811261511x7f3d4356v977c2ec138a8636d@mail.gmail.com>

I installed F10 (great job BTW) however  when I try to install software with
YUM I get the following error:

Downloading Packages:
http://linuxdownload.adobe.com/linux/i386/flash-plugin-10.0.12.36-release.i386.rpm:
[Errno 4] IOError: <urlopen error (-2, 'Name or service not known')>
Trying other mirror.


Error Downloading Packages:
  flash-plugin-10.0.12.36-release.i386: failure:
flash-plugin-10.0.12.36-release.i386.rpm from adobe-linux-i386: [Errno 256]
No more mirrors to try.

pasting:
http://linuxdownload.adobe.com/linux/i386/flash-plugin-10.0.12.36-release.i386.rpminto
firefox downloads the file without issue.

Is this a known issue with YUM?

Mark Bidewell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081126/a97708a2/attachment.htm>

From stickster at gmail.com  Wed Nov 26 23:16:15 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Wed, 26 Nov 2008 18:16:15 -0500
Subject: libdvdcss - where did it go?
In-Reply-To: <adf480660811261238j39c0bf7cn6eea7424dc88dfdc@mail.gmail.com>
References: <8CB1E0A06D7FF0A-1044-B9D@MBLK-M01.sysops.aol.com>
	<492D941D.8020908@herr-schmitt.de> <ggk4ip$b1k$1@ger.gmane.org>
	<492D96A5.9090302@herr-schmitt.de>
	<adf480660811261238j39c0bf7cn6eea7424dc88dfdc@mail.gmail.com>
Message-ID: <20081126231615.GJ6272@localhost.localdomain>

On Wed, Nov 26, 2008 at 11:38:02PM +0300, Peter Lemenkov wrote:
> > Yes I have prefered if libdvdcss were gone into non-free of rpmfusion.
> 
> There is no reason to move libdvdcss into rpmfusion-non-free.
> 
> * It's opensourced
> * It's freely distributable

This is not the forum to discuss issues with rpmfusion.  They have
their own mailing lists for this, and archives where you can see all
the discussion that's happened in the past.

-- 
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/20081126/c2d56dbb/attachment.sig>

From cdahlin at redhat.com  Wed Nov 26 23:18:42 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 26 Nov 2008 18:18:42 -0500
Subject: Fedora 10 and YUM
In-Reply-To: <bfdeacfa0811261511x7f3d4356v977c2ec138a8636d@mail.gmail.com>
References: <bfdeacfa0811261511x7f3d4356v977c2ec138a8636d@mail.gmail.com>
Message-ID: <492DD952.8090108@redhat.com>

Mark Bidewell wrote:
> I installed F10 (great job BTW) however  when I try to install 
> software with YUM I get the following error:
>
> Downloading Packages:
> http://linuxdownload.adobe.com/linux/i386/flash-plugin-10.0.12.36-release.i386.rpm: 
> [Errno 4] IOError: <urlopen error (-2, 'Name or service not known')>
> Trying other mirror.
>
>
> Error Downloading Packages:
>   flash-plugin-10.0.12.36-release.i386: failure: 
> flash-plugin-10.0.12.36-release.i386.rpm from adobe-linux-i386: [Errno 
> 256] No more mirrors to try.
>
> pasting:  
> http://linuxdownload.adobe.com/linux/i386/flash-plugin-10.0.12.36-release.i386.rpm 
> into firefox downloads the file without issue.
>
> Is this a known issue with YUM?
>
> Mark Bidewell
You have the adobe flash repo installed, and its down, so yum is failing 
to connect to it. Try with --disablerepo=adobe until their systems get 
sorted.

--CJD



From opensource at till.name  Wed Nov 26 23:29:06 2008
From: opensource at till.name (Till Maas)
Date: Thu, 27 Nov 2008 00:29:06 +0100
Subject: shortening time passed in bodhi?
In-Reply-To: <20081126191926.GP2780@free.fr>
References: <20081126150440.GD2780@free.fr>
	<1227726481.5276.85.camel@luminos.localdomain>
	<20081126191926.GP2780@free.fr>
Message-ID: <200811270029.24190.opensource@till.name>

On Wed November 26 2008, Patrice Dumas wrote:

> I guess that it is that part that I would like to be skipped, such that
> there is no need of any checking, and the update goes straigth to
> testing or stable, without being even in pending state.

I hope I understood everything correctly: The pending state indicates that 
either the composing process currently runs or that it needs to be started. 
Does this help you?

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/20081127/f2064f3b/attachment.sig>

From nathanael at gnat.ca  Wed Nov 26 23:32:58 2008
From: nathanael at gnat.ca (Nathanael D. Noblet)
Date: Wed, 26 Nov 2008 16:32:58 -0700
Subject: Fedora 10 and YUM
In-Reply-To: <492DD952.8090108@redhat.com>
References: <bfdeacfa0811261511x7f3d4356v977c2ec138a8636d@mail.gmail.com>
	<492DD952.8090108@redhat.com>
Message-ID: <492DDCAA.1080704@gnat.ca>

Casey Dahlin wrote:
> You have the adobe flash repo installed, and its down, so yum is failing 
> to connect to it. Try with --disablerepo=adobe until their systems get 
> sorted.

That would be a great plugin... Repo is down... continue with it 
disabled? [y/n]

Just a thought... Not that I could program it. But its happened to me 
before that I had to do that, so automatically doing it or asking me 
would be awesome.

-- 
Nathanael d. Noblet
Gnat Solutions, Inc
T: 403.875.4613



From choeger at cs.tu-berlin.de  Wed Nov 26 23:38:34 2008
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Thu, 27 Nov 2008 00:38:34 +0100
Subject: Feature proposal: Community Translation Tool
Message-ID: <1227742714.2822.19.camel@choeger5.umpa.netz>

Hi,

did you ever want to use fedora in your own Non-English language and saw
strings which where simple to translate floating around untranslated?
I did. The best example is packagekit-gui's update dialog which has a
'review' button which was translated into german for f10, but remained
untranslated in f9 although it was really easy to do. 
Why did I not contact upstream/fedora bz with a translation? Well, look
how translation works for such simple strings (and normal users):

1. find out which package that string belongs to
2. download the source (and figure out how to do that)
3. edit that translation file in that weird format with that weird tool
and create a thing called a "patch"
4. send that patch to bz (have a registered account!)

The point is: Joe Average User will not even consider doing that! If he
considers creating a bz account he can read english and will not have a
very big problem understanding some untranslated strings here and
there. 
I would like to make that process automagic by providing
a) a simple app that allows users to make a "one string" contribution
b) write a backend, that would store all proposals and update all .po
files fedora has on a regular basis and send the generated patches
upstream or to a fedora translator.

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?

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/20081127/549e15ae/attachment.sig>

From opensource at till.name  Wed Nov 26 23:45:08 2008
From: opensource at till.name (Till Maas)
Date: Thu, 27 Nov 2008 00:45:08 +0100
Subject: Fedora 8 and 9 updates re-enabled
In-Reply-To: <1223912036.3327.16.camel@luminos.localdomain>
References: <1221028475.3388.132.camel@luminos.localdomain>
	<200810121813.36870.opensource@till.name>
	<1223912036.3327.16.camel@luminos.localdomain>
Message-ID: <200811270045.14631.opensource@till.name>

On Mon October 13 2008, Jesse Keating wrote:
> On Sun, 2008-10-12 at 18:13 +0200, Till Maas wrote:
> > Is there a schedule when the Everything repo will be resigned with the
> > new key, so that the old gpg key can be purged?
>
> I've been working on this over the past week or two.  Hopefully within
> the next week we'll have the new stuff staged.

Now that F10 is released, is there a new schedule available? I guess the 
Fedora 8 rpms will not be resigned. :-( Btw. are the old keys removed for 
people who update to F10?

Is there also an estimation available when the details of the incident will be 
revealed?

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/20081127/b8452b2c/attachment.sig>

From kevin.kofler at chello.at  Wed Nov 26 23:55:04 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 27 Nov 2008 00:55:04 +0100
Subject: Feature proposal: Community Translation Tool
References: <1227742714.2822.19.camel@choeger5.umpa.netz>
Message-ID: <ggknko$b9e$1@ger.gmane.org>

Christoph H?ger wrote:
> I would like to make that process automagic by providing
> a) a simple app that allows users to make a "one string" contribution
> b) write a backend, that would store all proposals and update all .po
> files fedora has on a regular basis and send the generated patches
> upstream or to a fedora translator.

Isn't that what Transifex is about?

        Kevin Kofler



From pertusus at free.fr  Wed Nov 26 21:32:15 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 26 Nov 2008 22:32:15 +0100
Subject: shortening time passed in bodhi?
In-Reply-To: <1227727922.5276.90.camel@luminos.localdomain>
References: <20081126150440.GD2780@free.fr>
	<1227721928.5276.73.camel@luminos.localdomain>
	<20081126181208.GN2780@free.fr>
	<1227726481.5276.85.camel@luminos.localdomain>
	<20081126191926.GP2780@free.fr>
	<1227727922.5276.90.camel@luminos.localdomain>
Message-ID: <20081126213215.GQ2780@free.fr>

On Wed, Nov 26, 2008 at 11:32:02AM -0800, Jesse Keating wrote:
> > be checked manually.
> 
> er, this time period is I do believe less than a second, and it's done
> automatically by bodhi when you make the request.  It just fails the
> request if the tag isn't correct.

Ok.

> The pending state is there because people often work on an update
> request at multiple times, and want to be able to add to it and adjust
> it before doing the final push request, 

Who want that? In any case it should be optional. My update waited in
pending state for 2 days. These are 2 days wasted.

> and also from a app code point
> of view I think the update object has to have one form of existence
> outside of either push requested or pushed.

But it could be instantaneous.

> So again, I think we're misunderstanding each other.  What problem are
> you trying to solve?

When I ask for pushing to testing (or directly to stable), it should land 
into testing or stable as soon as possible without ever being pending.

Or maybe I misunderstood something, and the pending state is there until
compose was finished?

--
Pat



From stickster at gmail.com  Thu Nov 27 00:13:48 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Wed, 26 Nov 2008 19:13:48 -0500
Subject: Feature proposal: Community Translation Tool
In-Reply-To: <ggknko$b9e$1@ger.gmane.org>
References: <1227742714.2822.19.camel@choeger5.umpa.netz>
	<ggknko$b9e$1@ger.gmane.org>
Message-ID: <20081127001348.GA9042@localhost.localdomain>

On Thu, Nov 27, 2008 at 12:55:04AM +0100, Kevin Kofler wrote:
> Christoph H?ger wrote:
> > I would like to make that process automagic by providing
> > a) a simple app that allows users to make a "one string" contribution
> > b) write a backend, that would store all proposals and update all .po
> > files fedora has on a regular basis and send the generated patches
> > upstream or to a fedora translator.
> 
> Isn't that what Transifex is about?

Transifex is indeed all about making translations easier to
contribute.  It also has a command-line client and libraries under
development, so it would be completely plausible for someone to write
a "l10n-buddy" that could be pointed at a GUI to enable one-off
translations, and have them transmitted to transifex for filing in the
upstream repository.

Christoph, you should absolutely get in touch with the Transifex
developers for more information and to volunteer to help with this
piece.  cc'ing Dimitris for good measure.

-- 
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/20081126/3bf1dd20/attachment.sig>

From pertusus at free.fr  Thu Nov 27 00:30:36 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 27 Nov 2008 01:30:36 +0100
Subject: shortening time passed in bodhi?
In-Reply-To: <200811270029.24190.opensource@till.name>
References: <20081126150440.GD2780@free.fr>
	<1227726481.5276.85.camel@luminos.localdomain>
	<20081126191926.GP2780@free.fr>
	<200811270029.24190.opensource@till.name>
Message-ID: <20081127003036.GR2780@free.fr>

On Thu, Nov 27, 2008 at 12:29:06AM +0100, Till Maas wrote:
> On Wed November 26 2008, Patrice Dumas wrote:
> 
> > I guess that it is that part that I would like to be skipped, such that
> > there is no need of any checking, and the update goes straigth to
> > testing or stable, without being even in pending state.
> 
> I hope I understood everything correctly: The pending state indicates that 
> either the composing process currently runs or that it needs to be started. 
> Does this help you?

Indeed. So right after pending, the update pushed to stable should be in
stable. While if passing through testing it is once in pending while
testing is composing, then the maintainer can push it to stable, then it
is waiting for the next compose, and is then in a (hidden) pending
state before reaching stable.

So in the end the time of entering in a repo from a state to another is
about 2 days, one day waiting for the previous compose and another for
the compose the package is in itself.

For my package it should then have lasted about 4 days, but it was
streched to 8 for the reasons Jesse explained.

Still 2 days is quite a long time to wait, but I can't see a way
to shorten that time, except with a shortened compose time.

I guess there is no other way than taking koji builds for pepople in a
hurry.

--
Pat



From michael at laptop.org  Thu Nov 27 00:39:05 2008
From: michael at laptop.org (Michael Stone)
Date: Wed, 26 Nov 2008 19:39:05 -0500
Subject: Feature proposal: Community Translation Tool
In-Reply-To: <20081127001348.GA9042@localhost.localdomain>
References: <1227742714.2822.19.camel@choeger5.umpa.netz>
	<ggknko$b9e$1@ger.gmane.org>
	<20081127001348.GA9042@localhost.localdomain>
Message-ID: <20081127003905.GQ11828@didacte.laptop.org>

On Wed, Nov 26, 2008 at 07:13:48PM -0500, Paul W. Frields wrote:
>On Thu, Nov 27, 2008 at 12:55:04AM +0100, Kevin Kofler wrote:
>> Christoph H?ger wrote:
>> > I would like to make that process automagic by providing
>> > a) a simple app that allows users to make a "one string" contribution
>> > b) write a backend, that would store all proposals and update all .po
>> > files fedora has on a regular basis and send the generated patches
>> > upstream or to a fedora translator.
>> 
>> Isn't that what Transifex is about?
>
>Transifex is indeed all about making translations easier to
>contribute.  It also has a command-line client and libraries under
>development, so it would be completely plausible for someone to write
>a "l10n-buddy" that could be pointed at a GUI to enable one-off
>translations, and have them transmitted to transifex for filing in the
>upstream repository.
>
>Christoph, you should absolutely get in touch with the Transifex
>developers for more information and to volunteer to help with this
>piece.  cc'ing Dimitris for good measure.

Enabling better translation workflows, especially for people who are
only locally connected (i.e. who participate in local networks but who
have no regular internet access) is a big deal for OLPC/SugarLabs
because we're obligated by our mission to bring our software to people
in regions with many languages and to empower those people, as best we
can, to adapt our software to suit their needs. 

To this end, Scott Ananian gave a talk on a 'click to translate' [1, 2]
technology that he has prototyped for us at last week's SugarCamp [3].
This technology and the ideas underlying it may be of particular
interesting to readers of this thread.

Regards,

Michael

[1]: http://sugarlabs.org/wiki/images/0/00/Sugarcamp-cscott-i18n.pdf
[2]: http://dev.laptop.org/git/users/cscott/click2trans
[3]: http://sugarlabs.org/go/Sugarcamp



From bpepple at fedoraproject.org  Thu Nov 27 01:04:06 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 26 Nov 2008 20:04:06 -0500
Subject: FESCo Meeting Summary for 2008-11-26
Message-ID: <1227747846.8102.3.camel@localhost.localdomain>

=== Members Present ===
* Brian Pepple          (bpepple)
* Jarod Wilson          (j-rod)
* Jon Stanley           (jds2001)
* Karsten Hopp          (kick_)
* Kevin Fenzi           (nirik)
* Josh Boyer            (jwb)
* Dennis Gilmore        (dgilmore)

=== Absent ===
* Bill Nottingham       (notting)
* David Woodhouse       (dwmw2)

== Summary ==
=== Sponsor Nominations ===
      * FESCo has approved the sponsor requests for:
              * David Woodhouse (dwmw2)
              * Jon Stanley (jds2001)
      * Note: any Fedora packager that wishes to become a sponsor, can
        contact me or go directly to:
        http://fedoraproject.org/wiki/Extras/Schedule/NewSponsors

=== EOL date for F8 ===
      * FESCo decided that January 7th, 2009 would be the EOL date for
        Fedora 8, contingent on Rel-Eng not objecting.

=== Features ===
      * jds2001 volunteered to be responsible for keeping track of
        features, so that their test plans and scopes are in compliance
        by the necessary deadlines.

IRC log can be found at:
http://bpepple.fedorapeople.org/fesco/FESCo-2008-11-26.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/20081126/1730f00d/attachment.sig>

From mike at cchtml.com  Thu Nov 27 02:28:55 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Wed, 26 Nov 2008 20:28:55 -0600
Subject: Feature proposal: New, Standard Documentation System
Message-ID: <492E05E7.2080708@cchtml.com>

Far too often I find myself looking for non-existent man pages, Google 
results, or help menus in GNU/Linux software. What's the problem? There 
is no single, reliable, standardized documentation system that is 
universally accepted or appreciated. Yes, what I'm about to describe 
should obsolete man, info, and all the other dozen "help" documentation 
found in all the Fedora packages.

Problem case out of the way: Fedora should pioneer a GNU/Linux 
documentation system that meets these criteria:
1. Lightweight
   The entire system should not demand hundreds of megs of fonts, 
images, or other non-reusable requirements. I'm looking at you texlive. 
Recommendations: SQLite, ncurses, GTK. Existing toolkits; not new ones.
2. CLI and GUI front-ends
   Allow users to be presented to a universal and familiar front-end no 
matter where they are. The parts should also be separable so that, for 
instance, if there is no X requirement in a said environment, the help 
packages should not require QT, GTK, etc.
3. Universal formatting
   Obvious criteria, however, application specific formatting should be 
allowed as an optional addition after a standard format has been met.
4. Easy to use creation tools
   It shouldn't take a programmer background to write help 
documentation. Be it WYSIWYG tools or a simple XML-like (hey, or even 
XML) language to create documentation pages.
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.

Optional criteria:
1. Platform independence (for use on non-GNU/Linux systems)

Feel free to rip me apart. To me, and I'm sure most standard Linux 
users, documentation for /any/ piece of software is a nightmare, even if 
you are the original author. It should not be that way!

Regards,
Michael



From abu_hurayrah at hidayahonline.org  Thu Nov 27 04:44:54 2008
From: abu_hurayrah at hidayahonline.org (Basil Mohamed Gohar)
Date: Thu, 27 Nov 2008 06:44:54 +0200
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <492E05E7.2080708@cchtml.com>
References: <492E05E7.2080708@cchtml.com>
Message-ID: <1227761096.31656.50.camel@beta>

Michael,

What would a new system's advantage over man be?  For example, if a new
interface to manpages were created, that might eliminate some of the
initial learning curve some might say manpages present to users.

Actually, I think manpages already solve your 5 points without need
anything new.  Perhaps a manpage-to-X/HTML solution that allows reading
them on the fly in a browser could be used to make accessing them
easier.

So, what this comes down to is creating an easier way to make manpages,
if what I am suggesting makes sense.

________________________________________________________________________

Basil Mohamed Gohar
abu_hurayrah at hidayahonline.org
www.basilgohar.com




On Wed, 2008-11-26 at 20:28 -0600, Michael Cronenworth wrote:
> Far too often I find myself looking for non-existent man pages, Google 
> results, or help menus in GNU/Linux software. What's the problem? There 
> is no single, reliable, standardized documentation system that is 
> universally accepted or appreciated. Yes, what I'm about to describe 
> should obsolete man, info, and all the other dozen "help" documentation 
> found in all the Fedora packages.
> 
> Problem case out of the way: Fedora should pioneer a GNU/Linux 
> documentation system that meets these criteria:
> 1. Lightweight
>    The entire system should not demand hundreds of megs of fonts, 
> images, or other non-reusable requirements. I'm looking at you texlive. 
> Recommendations: SQLite, ncurses, GTK. Existing toolkits; not new ones.
> 2. CLI and GUI front-ends
>    Allow users to be presented to a universal and familiar front-end no 
> matter where they are. The parts should also be separable so that, for 
> instance, if there is no X requirement in a said environment, the help 
> packages should not require QT, GTK, etc.
> 3. Universal formatting
>    Obvious criteria, however, application specific formatting should be 
> allowed as an optional addition after a standard format has been met.
> 4. Easy to use creation tools
>    It shouldn't take a programmer background to write help 
> documentation. Be it WYSIWYG tools or a simple XML-like (hey, or even 
> XML) language to create documentation pages.
> 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.
> 
> Optional criteria:
> 1. Platform independence (for use on non-GNU/Linux systems)
> 
> Feel free to rip me apart. To me, and I'm sure most standard Linux 
> users, documentation for /any/ piece of software is a nightmare, even if 
> you are the original author. It should not be that way!
> 
> Regards,
> Michael
> 



From konrad at tylerc.org  Thu Nov 27 05:36:40 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Wed, 26 Nov 2008 21:36:40 -0800
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <1227761096.31656.50.camel@beta>
References: <492E05E7.2080708@cchtml.com> <1227761096.31656.50.camel@beta>
Message-ID: <200811262136.40430.konrad@tylerc.org>

On Wednesday 26 November 2008 08:44:54 pm Basil Mohamed Gohar wrote:
> Michael,
>
> What would a new system's advantage over man be?  For example, if a new
> interface to manpages were created, that might eliminate some of the
> initial learning curve some might say manpages present to users.
>
> Actually, I think manpages already solve your 5 points without need
> anything new.  Perhaps a manpage-to-X/HTML solution that allows reading
> them on the fly in a browser could be used to make accessing them
> easier.
>
> So, what this comes down to is creating an easier way to make manpages,
> if what I am suggesting makes sense.
>
> ________________________________________________________________________
>
> Basil Mohamed Gohar
> abu_hurayrah at hidayahonline.org
> www.basilgohar.com

Konqueror already has one such "manpage-to-HTML" solution when you browse 
manpages with "man:foobar" URLs (or something like that, it's been a while 
since I've used konqueror).

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




From mike at cchtml.com  Thu Nov 27 06:41:13 2008
From: mike at cchtml.com (Michael Cronenworth)
Date: Thu, 27 Nov 2008 00:41:13 -0600
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <200811262136.40430.konrad@tylerc.org>
References: <492E05E7.2080708@cchtml.com> <1227761096.31656.50.camel@beta>
	<200811262136.40430.konrad@tylerc.org>
Message-ID: <492E4109.4000909@cchtml.com>

Conrad Meyer wrote:
>
> Konqueror already has one such "manpage-to-HTML" solution when you browse 
> manpages with "man:foobar" URLs (or something like that, it's been a while 
> since I've used konqueror).
>
> Regards,
>   

Before this "manpage-to-HTML" idea goes any further, I'd like to stop it.

This is not what I have envisioned. An HTML rendering engine is too 
beefy. I'm going on previous Fedora requirements of lighter 
documentation engines, particularly the release notes in anaconda.

I'll follow up with more detail after the holidays.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081127/09bd23c5/attachment.htm>

From gbuday at gmail.com  Thu Nov 27 06:45:46 2008
From: gbuday at gmail.com (Gergely Buday)
Date: Thu, 27 Nov 2008 07:45:46 +0100
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <492E05E7.2080708@cchtml.com>
References: <492E05E7.2080708@cchtml.com>
Message-ID: <90d975d30811262245x31b20fd8if3d86738b971d93b@mail.gmail.com>

2008/11/27 Michael Cronenworth <mike at cchtml.com>:
> Far too often I find myself looking for non-existent man pages, Google
> results, or help menus in GNU/Linux software. What's the problem? There is
> no single, reliable, standardized documentation system that is universally
> accepted or appreciated. Yes, what I'm about to describe should obsolete
> man, info, and all the other dozen "help" documentation found in all the
> Fedora packages.

Hi Michael,

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



From tgl at redhat.com  Thu Nov 27 06:53:18 2008
From: tgl at redhat.com (Tom Lane)
Date: Thu, 27 Nov 2008 01:53:18 -0500
Subject: Feature proposal: New, Standard Documentation System 
In-Reply-To: <492E05E7.2080708@cchtml.com> 
References: <492E05E7.2080708@cchtml.com>
Message-ID: <1188.1227768798@sss.pgh.pa.us>

Michael Cronenworth <mike at cchtml.com> writes:
> ... Yes, what I'm about to describe 
> should obsolete man, info, and all the other dozen "help" documentation 
> found in all the Fedora packages.

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



From pekkas at netcore.fi  Thu Nov 27 06:54:38 2008
From: pekkas at netcore.fi (Pekka Savola)
Date: Thu, 27 Nov 2008 08:54:38 +0200 (EET)
Subject: yum upgrade from F-9 to F-10
In-Reply-To: <alpine.LFD.2.00.0811012257430.30198@vega2.dur.ac.uk>
References: <5256d0b0811011137ye3910fco1a0726c96c3a4c65@mail.gmail.com>
	<alpine.LFD.2.00.0811012257430.30198@vega2.dur.ac.uk>
Message-ID: <alpine.LRH.2.00.0811270851270.20197@netcore.fi>

On Sat, 1 Nov 2008, M A Young wrote:
> On Sat, 1 Nov 2008, Peter Robinson wrote:
>>  I've done a? yum upgrade to F-10 rawhide using the method below. All
>>  seemed
>>  to go OK but on reboot GDM doesn't work. The user list just lists "Other"
>>  and the shutdown and reboot buttons are in operable. Any one seen this,
>>  any
>>  idea?
>>  https://fedoraproject.org/wiki/YumUpgradeFaq
>
> Clicking other should get you a login prompt. If that doesn't work either, do 
> you have an intel graphics card? X is broken for some intel graphics cards in 
> rawhide.

In F-9 -> F-10 upgrade, I got the following error, which I worked 
around by removing pidgin.  Could someone add that to YumUpgradeFaq 
under F-10 specifics?

pidgin-2.5.2-2.fc9.i386 from installed has depsolving problems
   --> Missing Dependency: libedataserver-1.2.so.9 is needed by package pidgin-2.5.2-2.fc9.i386 (installed)
Error: Missing Dependency: libedataserver-1.2.so.9 is needed by package pidgin-2.5.2-2.fc9.i386 (installed)

BTW: IMHO it's annoying that a login is needed for wiki edits.  A lot 
of people might be interested in contributing like this but if they do 
so only once a year or two, they don't want to mess with logins.

From denis at poolshark.org  Thu Nov 27 08:19:49 2008
From: denis at poolshark.org (Denis Leroy)
Date: Thu, 27 Nov 2008 09:19:49 +0100
Subject: NM 0.7.0
Message-ID: <492E5825.1060204@poolshark.org>

I swear I just saw a flock of pigs flying by :-)

Congratulations to the NetworkManager team!



From rjones at redhat.com  Thu Nov 27 09:32:26 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 27 Nov 2008 09:32:26 +0000
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <492E05E7.2080708@cchtml.com>
References: <492E05E7.2080708@cchtml.com>
Message-ID: <20081127093226.GA6829@amd.home.annexia.org>

On Wed, Nov 26, 2008 at 08:28:55PM -0600, Michael Cronenworth wrote:
> Far too often I find myself looking for non-existent man pages, Google  
> results, or help menus in GNU/Linux software. What's the problem? There  
> is no single, reliable, standardized documentation system that is  
> universally accepted or appreciated. Yes, what I'm about to describe  
> should obsolete man, info, and all the other dozen "help" documentation  
> found in all the Fedora packages.

Debian forces all programs to come with a man page.  If one is
missing, this is considered a bug and packagers have to write one.

http://www.debian.org/doc/debian-policy/ch-docs.html

This would be an excellent idea for Fedora to follow (and we can,
license permitting, use the Debian man pages).

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 fedora at leemhuis.info  Thu Nov 27 10:06:19 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Thu, 27 Nov 2008 11:06:19 +0100
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <20081127093226.GA6829@amd.home.annexia.org>
References: <492E05E7.2080708@cchtml.com>
	<20081127093226.GA6829@amd.home.annexia.org>
Message-ID: <492E711B.2010803@leemhuis.info>

On 27.11.2008 10:32, Richard W.M. Jones wrote:
> On Wed, Nov 26, 2008 at 08:28:55PM -0600, Michael Cronenworth wrote:
>> Far too often I find myself looking for non-existent man pages, Google  
>> results, or help menus in GNU/Linux software. What's the problem? There  
>> is no single, reliable, standardized documentation system that is  
>> universally accepted or appreciated. Yes, what I'm about to describe  
>> should obsolete man, info, and all the other dozen "help" documentation  
>> found in all the Fedora packages.
> 
> Debian forces all programs to come with a man page.  If one is
> missing, this is considered a bug and packagers have to write one.
> 
> http://www.debian.org/doc/debian-policy/ch-docs.html
> 
> This would be an excellent idea for Fedora to follow (and we can,
> license permitting, use the Debian man pages).

My 2 cent: It would be way better for everyone to get those man pages 
upstream.

One reason for that: If you add man pages from debian to a fedora 
package then you have to recheck every now and then if the man pages are 
still up2date. That afaics often tends to be forgotten (I'm guilty 
myself here).

CU
knurd



From pertusus at free.fr  Thu Nov 27 10:15:36 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 27 Nov 2008 11:15:36 +0100
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <20081127093226.GA6829@amd.home.annexia.org>
References: <492E05E7.2080708@cchtml.com>
	<20081127093226.GA6829@amd.home.annexia.org>
Message-ID: <20081127101536.GC2935@free.fr>

On Thu, Nov 27, 2008 at 09:32:26AM +0000, Richard W.M. Jones wrote:
> 
> Debian forces all programs to come with a man page.  If one is
> missing, this is considered a bug and packagers have to write one.
> 
> http://www.debian.org/doc/debian-policy/ch-docs.html

I don't think that making a man page should be a guideline in fedora. If
th efedora contributor wants to work a man page with upstream, fine, but
it should be optional.

> This would be an excellent idea for Fedora to follow (and we can,
> license permitting, use the Debian man pages).

If there is a good debian man page and nothing upstream, I think it is
best practice for a packager to use the debian man page. But I don't
think that it needs a guideline, it is fairly obvious that it is right.

Maybe you could add something on
https://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks
stating that it is good to work a man page with upstream like debian
does and reusing debian manpage is also worth it.

--
Pat



From dominik at greysector.net  Thu Nov 27 10:20:23 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 27 Nov 2008 11:20:23 +0100
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <492E711B.2010803@leemhuis.info>
References: <492E05E7.2080708@cchtml.com>
	<20081127093226.GA6829@amd.home.annexia.org>
	<492E711B.2010803@leemhuis.info>
Message-ID: <20081127102022.GA13129@mokona.greysector.net>

On Thursday, 27 November 2008 at 11:06, Thorsten Leemhuis wrote:
> On 27.11.2008 10:32, Richard W.M. Jones wrote:
> >On Wed, Nov 26, 2008 at 08:28:55PM -0600, Michael Cronenworth wrote:
> >>Far too often I find myself looking for non-existent man pages, Google  
> >>results, or help menus in GNU/Linux software. What's the problem? There  
> >>is no single, reliable, standardized documentation system that is  
> >>universally accepted or appreciated. Yes, what I'm about to describe  
> >>should obsolete man, info, and all the other dozen "help" documentation  
> >>found in all the Fedora packages.
> >
> >Debian forces all programs to come with a man page.  If one is
> >missing, this is considered a bug and packagers have to write one.
> >
> >http://www.debian.org/doc/debian-policy/ch-docs.html
> >
> >This would be an excellent idea for Fedora to follow (and we can,
> >license permitting, use the Debian man pages).
> 
> My 2 cent: It would be way better for everyone to get those man pages 
> upstream.
> 
> One reason for that: If you add man pages from debian to a fedora 
> package then you have to recheck every now and then if the man pages are 
> still up2date. That afaics often tends to be forgotten (I'm guilty 
> myself here).

+1. Also I'd make it a SHOULD item in review guidelines.

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  Thu Nov 27 10:24:23 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 27 Nov 2008 11:24:23 +0100
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <20081127102022.GA13129@mokona.greysector.net>
References: <492E05E7.2080708@cchtml.com>
	<20081127093226.GA6829@amd.home.annexia.org>
	<492E711B.2010803@leemhuis.info>
	<20081127102022.GA13129@mokona.greysector.net>
Message-ID: <20081127102423.GD2935@free.fr>

On Thu, Nov 27, 2008 at 11:20:23AM +0100, Dominik 'Rathann' Mierzejewski wrote:
> 
> +1. Also I'd make it a SHOULD item in review guidelines.

I don't think it should be at all in the guidelines, they are big
enough.

--
Pat



From schaiba at gmail.com  Thu Nov 27 10:24:23 2008
From: schaiba at gmail.com (Aioanei Rares)
Date: Thu, 27 Nov 2008 12:24:23 +0200
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <20081127102022.GA13129@mokona.greysector.net>
References: <492E05E7.2080708@cchtml.com>
	<20081127093226.GA6829@amd.home.annexia.org>
	<492E711B.2010803@leemhuis.info>
	<20081127102022.GA13129@mokona.greysector.net>
Message-ID: <778179b00811270224x706446c5qec4fdd751994715a@mail.gmail.com>

On Thu, Nov 27, 2008 at 12:20 PM, Dominik 'Rathann' Mierzejewski <
dominik at greysector.net> wrote:

> On Thursday, 27 November 2008 at 11:06, Thorsten Leemhuis wrote:
> > On 27.11.2008 10:32, Richard W.M. Jones wrote:
> > >On Wed, Nov 26, 2008 at 08:28:55PM -0600, Michael Cronenworth wrote:
> > >>Far too often I find myself looking for non-existent man pages, Google
> > >>results, or help menus in GNU/Linux software. What's the problem? There
> > >>is no single, reliable, standardized documentation system that is
> > >>universally accepted or appreciated. Yes, what I'm about to describe
> > >>should obsolete man, info, and all the other dozen "help" documentation
> > >>found in all the Fedora packages.
> > >
> > >Debian forces all programs to come with a man page.  If one is
> > >missing, this is considered a bug and packagers have to write one.
> > >
> > >http://www.debian.org/doc/debian-policy/ch-docs.html
> > >
> > >This would be an excellent idea for Fedora to follow (and we can,
> > >license permitting, use the Debian man pages).
> >
> > My 2 cent: It would be way better for everyone to get those man pages
> > upstream.
> >
> > One reason for that: If you add man pages from debian to a fedora
> > package then you have to recheck every now and then if the man pages are
> > still up2date. That afaics often tends to be forgotten (I'm guilty
> > myself here).
>
> +1. Also I'd make it a SHOULD item in review guidelines.
>
> 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"
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


I agree, sometimes Fedora isn't regarded as the best documented distro out
there, and
that's bad.
-- 
Aioanei Rares
schaiba at fedoraproject.org
"China is a big country, inhabited by many Chinese." --Charles de Gaulle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081127/af533423/attachment.htm>

From mcepl at redhat.com  Thu Nov 27 10:28:49 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 27 Nov 2008 11:28:49 +0100
Subject: Feature proposal: New, Standard Documentation System
References: <492E05E7.2080708@cchtml.com> <1227761096.31656.50.camel@beta>
Message-ID: <1c9206xjvb.ln2@ppp1053.in.ipex.cz>

On 2008-11-27, 04:44 GMT, Basil Mohamed Gohar wrote:
> Actually, I think manpages already solve your 5 points without 
> need anything new.  Perhaps a manpage-to-X/HTML solution that 
> allows reading them on the fly in a browser could be used to 
> make accessing them easier.

In both KDE and Gnome get the "Run application" dialog up and run 
man:bash.

Mat?j



From mcepl at redhat.com  Thu Nov 27 10:27:46 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 27 Nov 2008 11:27:46 +0100
Subject: Feature proposal: New, Standard Documentation System
References: <492E05E7.2080708@cchtml.com>
	<20081127093226.GA6829@amd.home.annexia.org>
	<492E711B.2010803@leemhuis.info>
Message-ID: <2a9206xjvb.ln2@ppp1053.in.ipex.cz>

On 2008-11-27, 10:06 GMT, Thorsten Leemhuis wrote:
> My 2 cent: It would be way better for everyone to get those man 
> pages upstream.
>
> One reason for that: If you add man pages from debian to a fedora 
> package then you have to recheck every now and then if the man pages are 
> still up2date. That afaics often tends to be forgotten (I'm guilty 
> myself here).

+10000 (both on making manpages mandatory and sending them 
upstream)

Mat?j



From pingou at pingoured.fr  Thu Nov 27 10:40:03 2008
From: pingou at pingoured.fr (Pierre-Yves)
Date: Thu, 27 Nov 2008 11:40:03 +0100
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <1c9206xjvb.ln2@ppp1053.in.ipex.cz>
References: <492E05E7.2080708@cchtml.com> <1227761096.31656.50.camel@beta>
	<1c9206xjvb.ln2@ppp1053.in.ipex.cz>
Message-ID: <492E7903.7020603@pingoured.fr>

Matej Cepl wrote:
> On 2008-11-27, 04:44 GMT, Basil Mohamed Gohar wrote:
>> Actually, I think manpages already solve your 5 points without 
>> need anything new.  Perhaps a manpage-to-X/HTML solution that 
>> allows reading them on the fly in a browser could be used to 
>> make accessing them easier.
> 
> In both KDE and Gnome get the "Run application" dialog up and run 
> man:bash.

'The requested URI "man:///mans" is invalid'

Regards,

Pierre



From pingou at pingoured.fr  Thu Nov 27 10:42:33 2008
From: pingou at pingoured.fr (Pierre-Yves)
Date: Thu, 27 Nov 2008 11:42:33 +0100
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <492E7903.7020603@pingoured.fr>
References: <492E05E7.2080708@cchtml.com>
	<1227761096.31656.50.camel@beta>	<1c9206xjvb.ln2@ppp1053.in.ipex.cz>
	<492E7903.7020603@pingoured.fr>
Message-ID: <492E7999.3070100@pingoured.fr>

Pierre-Yves wrote:
> Matej Cepl wrote:
>> On 2008-11-27, 04:44 GMT, Basil Mohamed Gohar wrote:
>>> Actually, I think manpages already solve your 5 points without need 
>>> anything new.  Perhaps a manpage-to-X/HTML solution that allows 
>>> reading them on the fly in a browser could be used to make accessing 
>>> them easier.
>>
>> In both KDE and Gnome get the "Run application" dialog up and run 
>> man:bash.
> 
> 'The requested URI "man:///mans" is invalid'
err "man:///man"
> 
> Regards,
> 
> Pierre
> 



From camilo at mesias.co.uk  Thu Nov 27 11:37:31 2008
From: camilo at mesias.co.uk (Camilo Mesias)
Date: Thu, 27 Nov 2008 11:37:31 +0000
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <778179b00811270224x706446c5qec4fdd751994715a@mail.gmail.com>
References: <492E05E7.2080708@cchtml.com>
	<20081127093226.GA6829@amd.home.annexia.org>
	<492E711B.2010803@leemhuis.info>
	<20081127102022.GA13129@mokona.greysector.net>
	<778179b00811270224x706446c5qec4fdd751994715a@mail.gmail.com>
Message-ID: <d551e0e20811270337x15254646h8eab89535b86465e@mail.gmail.com>

Hi,

>> > >Debian forces all programs to come with a man page.  If one is
>> > >missing, this is considered a bug and packagers have to write one.
>> > >
>> > >http://www.debian.org/doc/debian-policy/ch-docs.html
>> > >
>> > >This would be an excellent idea for Fedora to follow (and we can,
>> > >license permitting, use the Debian man pages).
>> >
>> > My 2 cent: It would be way better for everyone to get those man pages
>> > upstream.
>> >
>> > One reason for that: If you add man pages from debian to a fedora
>> > package then you have to recheck every now and then if the man pages are
>> > still up2date. That afaics often tends to be forgotten (I'm guilty
>> > myself here).
>>
>> +1. Also I'd make it a SHOULD item in review guidelines.

I agree with this. Fedora has a lot of good new technology that is let
down by the lack of readily available documentation. Examples include
pm-suspend (no man page but pretty webpages) the greatly understood
selinux (manpages but not enough FAQs or accessible tutorials),
NetworkManager (what does it do in this release?), packagekit, dbus,
etc. Wouldn't it be great if there was a guaranteed way to find
relevant docs for every bit of software in the distro?

I think Michael's mistake is to think that a new tool is the way to
achieve this. Even the most impressive shiny new tool would not make
people create new documentation. What's needed IMO is procedures,
standards and a bit more linking between existing documentation. What
if we had some metrics for documentation, and a league table where
maintainers could see how they are doing wrt. their peers?

-Cam



From opensource at till.name  Thu Nov 27 11:55:07 2008
From: opensource at till.name (Till Maas)
Date: Thu, 27 Nov 2008 12:55:07 +0100
Subject: automatically include files in %doc only if they are not empty
Message-ID: <200811271255.12657.opensource@till.name>

Hiyas,

on a package I recently packaged for Fedora, there is an empty TODO file 
included. Is there an easy way to mark this file in %files to be included 
only if it is not empty? This would make it easier to not forget to add the 
file in case it will be filed with some contents in a future release.

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/20081127/244b4293/attachment.sig>

From rawhide at fedoraproject.org  Thu Nov 27 12:07:25 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Thu, 27 Nov 2008 12:07:25 +0000 (UTC)
Subject: rawhide report: 20081127 changes
Message-ID: <20081127120725.8B1FF1F8252@releng2.fedora.phx.redhat.com>

Compose started at Thu Nov 27 06:01:10 UTC 2008

New package openvas-libraries
        Support libraries for Open Vulnerability Assessment (OpenVAS) Server
New package perl-Captcha-reCAPTCHA
        Perl implementation of the reCAPTCHA API
New package perl-Catalyst-Component-InstancePerContext
        Return a new instance a component on each request
New package perl-DateTime-Format-Natural
        Create machine readable date/time with natural parsing logic
New package perl-HTML-TokeParser-Simple
        Easy to use HTML::TokeParser interface
Updated Packages:

akonadi-1.0.80-1.fc11
---------------------
* Wed Nov 26 17:00:00 2008 Than Ngo <than at redhat.com> -  1.0.80-1
- 1.0.80


beagle-0.3.8-14.fc11
--------------------
* Wed Nov 26 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> - 0.3.8-14
- Update for new gnome-desktop


bind-9.6.0-0.4.b1.fc11
----------------------
* Wed Nov 26 17:00:00 2008 Adam Tkac <atkac redhat com> 32:9.6.0-0.4.b1
- reverted previous change, koji doesn't like it

* Wed Nov 26 17:00:00 2008 Adam Tkac <atkac redhat com> 32:9.6.0-0.3.b1
- build bind-chroot as noarch

* Mon Nov 24 17:00:00 2008 Adam Tkac <atkac redhat com> 32:9.6.0-0.2.1.b1
- updates due libtool 2.2.6
- don't pass -DLDAP_DEPRECATED to cpp, handle it directly in sources


compiz-0.7.8-4.fc11
-------------------
* Wed Nov 26 17:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> - 0.7.8-4
- Rebuild against new gnome-desktop


freeciv-2.1.7-1.fc11
--------------------
* Wed Nov 26 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 2.1.7-1
- Update to 2.1.7.

* Sat Nov 22 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 2.1.6-2
- Simplify summary.


gawk-3.1.6-2.fc11
-----------------
* Wed Nov 26 17:00:00 2008 Stepan Kasal <skasal at redhat.com> - 3.1.6-2
- test-lc_num1.patch submitted upstream, link added


gtkmm24-2.14.3-1.fc11
---------------------
* Wed Nov 26 17:00:00 2008 Denis Leroy <denis at poolshark.org> - 2.14.3-1
- Update to 2.14.3 version
- Devhelp patch upstreamed


guake-0.3.1-4.fc11
------------------
* Wed Nov 26 17:00:00 2008 pingou <pingoufc at yahoo.fr> - 0.3.1-4
- Quick and dirty trick before upstream patch

* Thu Nov 20 17:00:00 2008 pingou <pingoufc at yahoo.fr> - 0.3.1-3
- Correct the Source0


jaxen-1.1.1-1.1.fc11
--------------------
* Tue Nov 25 17:00:00 2008 Devrim GUNDUZ <devrim at gunduz.org> - 0:1.1.1-1
- Update to 1.1.1, to fix #465987 .


jd-2.1.0-0.1.svn2513_trunk.fc11
-------------------------------
* Thu Nov 27 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2513


libAfterImage-1.18-2.fc11
-------------------------
* Thu Nov 27 17:00:00 2008 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 1.18-2
- add glx context patch (suggested by Frank Schmitt)


libtorrent-0.12.4-1.fc11
------------------------
* Wed Nov 26 17:00:00 2008 Conrad Meyer <konrad at tylerc.org> - 0.12.4-1
- Bump to 0.12.4.


libvirt-0.5.0-1.fc11
--------------------
* Wed Nov 26 17:00:00 2008 Daniel Veillard <veillard at redhat.com> - 0.5.0-1.fc11
- upstream release 0.5.0
- domain lifecycle event support
- node device enumeration
- KVM/QEmu migration support
- improved LXC support
- SDL display configuration
- User Mode Linux driver (Daniel Berrange)


mod_mono-2.2-1.pre1.fc11
------------------------
* Tue Nov 25 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-1.pre1
- Bump to 2.2 preview 1
- incorporate fix to the var-run patch (thanks to Dario Lesca)


mono-2.2-4.pre1.fc11
--------------------
* Wed Nov 26 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-4.pre1
- mono.pc libfile fix


mono-basic-2.2-1.pre1.fc11
--------------------------
* Tue Nov 25 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-1.1.pre1
- rebuild

* Thu Nov 20 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-1.pre1
- bump to 2.2 preview 1


mono-debugger-2.2-1.pre1.fc11
-----------------------------
* Tue Nov 25 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-1.pre1
- bump to 2.2 preview 1

* Fri Oct  3 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-8
- bump to RC4
- now requires xsp-devel

* Wed Sep 10 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-7
- another configure patch
- rebuild against Mono 2.0 RC 1

* Wed Aug 27 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-6
- argh!!!! fixed the configure patch file

* Wed Aug 27 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-5
- more patches and actually apply the damned things

* Tue Aug 26 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-4
- libdir fixes

* Sun Aug 17 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-3
- paul learns how to count...
- spec fixes

* Thu Aug 14 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-2
- libdir clean
- spec file fix

* Sun Aug  3 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-1
- bump to preview 1
- patch fixes


nfs-utils-1.1.4-4.fc11
----------------------
* Wed Nov 26 17:00:00 2008 Steve Dickson <steved at redhat.com> 1.1.4-4
- gssd: unblock DNOTIFY_SIGNAL in case it was blocked
- Ensure statd gets started if required when non-root
  user mounts an NFS filesystem


openoffice.org-3.0.0-9.11.fc11
------------------------------
* Wed Nov 19 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.0-9.11
- Resolves: rhbz#471103 improve font-settings
- Resolves: ooo#96279 mediawiki proxies problem
- reenable -fasynchronous-unwind-tables for F-11 as gcc#36419 is marked as fixed
- add openoffice.org-3.0.0.ooo96391.sw.prefsalwaysmodified.patch

* Fri Nov 14 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.0-9.10
- rhbz#248401 extend the title page dialog to create title pages at
  arbitrary positions
- rhbz#470302 g_file_input_stream_query_info doesn't do anything remotely
- window manager hatred
- Resolves: rhbz#471485 openoffice.org-3.0.0.ooo96203.sfx2.3layer-qstart.patch
- Resolves: rhbz#471724 own the share dir too


pangomm-2.14.1-1.fc11
---------------------
* Wed Nov 26 17:00:00 2008 Denis Leroy <denis at poolshark.org> - 2.14.1-1
- Update to 2.14.1
- Devhelp patch upstreamed


shared-mime-info-0.51-5.fc11
----------------------------
* Wed Nov 26 17:00:00 2008 - Julian Sikorski <belegdol[at]gmail[dot]com> - 0.51-5
- Fix text/plain, gedit installs gedit.desktop and not gnome-gedit.desktop


ssmtp-2.61-11.7.fc11
--------------------
* Wed Nov 26 17:00:00 2008 Manuel "lonely wolf" Wolfshant <wolfy at nobugconsulting.ro> 2.61-11.7
- integrate patch from Andreas Dilger, fixes https://bugzilla.redhat.com/show_bug.cgi?id=430608


switchdesk-4.0.9-3.fc11
-----------------------
* Wed Nov 26 17:00:00 2008 Than Ngo <than at redhat.com> -  4.0.9-3
- add better advice for kde install (#440670)


wordpress-2.6.5-2.fc11
----------------------
* Wed Nov 26 17:00:00 2008 Adrian Reber <adrian at lisas.de> - 2.6.5-2
- updated to 2.6.5


xfsprogs-2.10.1-4.fc11
----------------------
* Wed Nov 26 17:00:00 2008 Eric Sandeen <sandeen at redhat.com> 2.10.1-4
- Add protection from borken sys_ustat
- Add final upstream versions of gfs2 & parallel build patches


xsp-2.2-1.pre1.fc11
-------------------
* Tue Nov 25 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-1.pre1
- bump to 2.2 preview 1


yaboot-1.3.14-7.fc11
--------------------
* Fri Nov 21 17:00:00 2008 David Woodhouse <David.Woodhouse at intel.com> - 1.3.14-7
- Fix 'ybin --bootonce' (#471425)
- Fix maximum token length, to fix preupgrade (#471321)


yum-3.2.20-4.fc11
-----------------
* Wed Nov 26 17:00:00 2008 Seth Vidal <skvidal at fedoraproject.org> - 3.2.20-4
- update head patch


Summary:
Added Packages: 5
Removed Packages: 0
Modified Packages: 28
Broken deps for i386
----------------------------------------------------------
	autodir-0.99.9-5.fc9.i386 requires libltdl.so.3
	avant-window-navigator-0.2.6-9.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	bigboard-0.6.4-2.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(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	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(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(Stack) = 0:132c3f280681fcc39900477f79c7096b
	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(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
	db4o-6.1-4.fc9.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	deskbar-applet-2.24.0-2.fc10.i386 requires libgnome-desktop-2.so.7
	desktop-data-model-1.2.5-1.fc10.i386 requires libgnome-desktop-2.so.7
	epdfview-0.1.6-4.fc10.i386 requires libpoppler-glib.so.3
	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-zimbra-0.1.1-3.fc10.i386 requires libcamel-1.2.so.14
	evolution-zimbra-0.1.1-3.fc10.i386 requires libcamel-provider-1.2.so.14
	foobillard-3.0a-8.fc10.i386 requires dejavu-fonts
	freeradius-2.1.1-2.fc10.i386 requires libltdl.so.3
	galeon-2.0.7-3.fc10.i386 requires libgnome-desktop-2.so.7
	gambas2-devel-2.9.0-1.fc10.i386 requires libltdl.so.3
	gambas2-gb-pdf-2.9.0-1.fc10.i386 requires libpoppler.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
	gnome-compiz-manager-0.10.4-4.fc10.i386 requires libgnome-desktop-2.so.7
	gnome-launch-box-0.4-10.fc10.i386 requires libgnome-desktop-2.so.7
	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
	inkscape-0.46-6.fc10.i386 requires libpoppler.so.3
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	kdebindings-4.1.2-2.fc10.i386 requires libqscintilla2.so.4
	kpackagekit-0.3.1-4.fc10.i386 requires libpackagekit-qt.so.10
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libp11-0.2.3-3.fc10.i386 requires libltdl.so.3
	mail-notification-evolution-plugin-5.4-4.fc10.i386 requires libcamel-1.2.so.14
	mail-notification-evolution-plugin-5.4-4.fc10.i386 requires libcamel-provider-1.2.so.14
	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
	mono-cecil-flowanalysis-0.1-0.6.20080409svn100264.fc11.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	mono-tools-2.0-8.fc10.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	mysql-connector-odbc-3.51.26r1127-1.fc10.i386 requires libltdl.so.3
	mythes-nb-2.0.10-1.fc11.noarch requires mythes
	mythes-nn-2.0.10-1.fc11.noarch requires mythes
	nautilus-search-tool-0.2.2-4.fc10.i386 requires libgnome-desktop-2.so.7
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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(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(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	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(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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
	padevchooser-0.9.4-0.6.svn20070925.fc10.i386 requires libgnome-desktop-2.so.7
	pdfcube-0.0.2-8.fc9.i386 requires libpoppler.so.3
	pdfcube-0.0.2-8.fc9.i386 requires libpoppler-glib.so.3
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts-experimental
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts
	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
	planner-eds-0.14.3-6.fc10.i386 requires libcamel-1.2.so.14
	planner-eds-0.14.3-6.fc10.i386 requires libcamel-provider-1.2.so.14
	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
	tellico-1.3.4-1.fc10.i386 requires libpoppler.so.3
	tracker-0.6.6-3.fc10.i386 requires libpoppler-glib.so.3
	tracker-search-tool-0.6.6-3.fc10.i386 requires libgnome-desktop-2.so.7
	wput-0.6.1-4.fc9.i386 requires libgnutls-openssl.so.13



Broken deps for x86_64
----------------------------------------------------------
	autodir-0.99.9-5.fc9.x86_64 requires libltdl.so.3()(64bit)
	avant-window-navigator-0.2.6-9.fc10.i386 requires libgnome-desktop-2.so.7
	avant-window-navigator-0.2.6-9.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	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)
	bigboard-0.6.4-2.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(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	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(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	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(CamlinternalMod) = 0:dc6994f75cfd14f73e718f81aa215803
	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(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(Random) = 0:9936935480b36bcbc716ee513f37876c
	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(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
	deskbar-applet-2.24.0-2.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	desktop-data-model-1.2.5-1.fc10.i386 requires libgnome-desktop-2.so.7
	desktop-data-model-1.2.5-1.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	epdfview-0.1.6-4.fc10.x86_64 requires libpoppler-glib.so.3()(64bit)
	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-zimbra-0.1.1-3.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	evolution-zimbra-0.1.1-3.fc10.x86_64 requires libcamel-provider-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)
	galeon-2.0.7-3.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	gambas2-devel-2.9.0-1.fc10.i386 requires libltdl.so.3
	gambas2-devel-2.9.0-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	gambas2-gb-pdf-2.9.0-1.fc10.x86_64 requires libpoppler.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)
	gnome-compiz-manager-0.10.4-4.fc10.i386 requires libgnome-desktop-2.so.7
	gnome-compiz-manager-0.10.4-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	gnome-launch-box-0.4-10.fc10.x86_64 requires libgnome-desktop-2.so.7()(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)
	inkscape-0.46-6.fc10.x86_64 requires libpoppler.so.3()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	kdebindings-4.1.2-2.fc10.i386 requires libqscintilla2.so.4
	kdebindings-4.1.2-2.fc10.x86_64 requires libqscintilla2.so.4()(64bit)
	kpackagekit-0.3.1-4.fc10.x86_64 requires libpackagekit-qt.so.10()(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)
	libp11-0.2.3-3.fc10.i386 requires libltdl.so.3
	libp11-0.2.3-3.fc10.x86_64 requires libltdl.so.3()(64bit)
	mail-notification-evolution-plugin-5.4-4.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	mail-notification-evolution-plugin-5.4-4.fc10.x86_64 requires libcamel-provider-1.2.so.14()(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)
	mono-cecil-flowanalysis-0.1-0.6.20080409svn100264.fc11.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	mono-tools-2.0-8.fc10.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	mysql-connector-odbc-3.51.26r1127-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	mythes-nb-2.0.10-1.fc11.noarch requires mythes
	mythes-nn-2.0.10-1.fc11.noarch requires mythes
	nautilus-search-tool-0.2.2-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(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(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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(Parsing) = 0:62cca107e4e88af303516459a87c3e9a
	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(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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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(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(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	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(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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)
	padevchooser-0.9.4-0.6.svn20070925.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	pdfcube-0.0.2-8.fc9.x86_64 requires libpoppler-glib.so.3()(64bit)
	pdfcube-0.0.2-8.fc9.x86_64 requires libpoppler.so.3()(64bit)
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts-experimental
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts
	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)
	planner-eds-0.14.3-6.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	planner-eds-0.14.3-6.fc10.x86_64 requires libcamel-provider-1.2.so.14()(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)
	tellico-1.3.4-1.fc10.x86_64 requires libpoppler.so.3()(64bit)
	tracker-0.6.6-3.fc10.i386 requires libpoppler-glib.so.3
	tracker-0.6.6-3.fc10.x86_64 requires libpoppler-glib.so.3()(64bit)
	tracker-search-tool-0.6.6-3.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	wput-0.6.1-4.fc9.x86_64 requires libgnutls-openssl.so.13()(64bit)



Broken deps for ppc
----------------------------------------------------------
	autodir-0.99.9-5.fc9.ppc requires libltdl.so.3
	avant-window-navigator-0.2.6-9.fc10.ppc requires libgnome-desktop-2.so.7
	avant-window-navigator-0.2.6-9.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	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)
	bigboard-0.6.4-2.fc10.ppc requires libgnome-desktop-2.so.7
	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(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	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(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(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(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
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	deskbar-applet-2.24.0-2.fc10.ppc requires libgnome-desktop-2.so.7
	desktop-data-model-1.2.5-1.fc10.ppc requires libgnome-desktop-2.so.7
	desktop-data-model-1.2.5-1.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	epdfview-0.1.6-4.fc10.ppc requires libpoppler-glib.so.3
	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-zimbra-0.1.1-3.fc10.ppc requires libcamel-1.2.so.14
	evolution-zimbra-0.1.1-3.fc10.ppc requires libcamel-provider-1.2.so.14
	foobillard-3.0a-8.fc10.ppc requires dejavu-fonts
	freeradius-2.1.1-2.fc10.ppc requires libltdl.so.3
	galeon-2.0.7-3.fc10.ppc requires libgnome-desktop-2.so.7
	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)
	gnome-compiz-manager-0.10.4-4.fc10.ppc requires libgnome-desktop-2.so.7
	gnome-compiz-manager-0.10.4-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	gnome-launch-box-0.4-10.fc10.ppc requires libgnome-desktop-2.so.7
	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
	inkscape-0.46-6.fc10.ppc requires libpoppler.so.3
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	kdebindings-4.1.2-2.fc10.ppc requires libqscintilla2.so.4
	kdebindings-4.1.2-2.fc10.ppc64 requires libqscintilla2.so.4()(64bit)
	kpackagekit-0.3.1-4.fc10.ppc requires libpackagekit-qt.so.10
	libextractor-0.5.20b-2.fc10.ppc requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libp11-0.2.3-3.fc10.ppc requires libltdl.so.3
	libp11-0.2.3-3.fc10.ppc64 requires libltdl.so.3()(64bit)
	mail-notification-evolution-plugin-5.4-4.fc10.ppc requires libcamel-1.2.so.14
	mail-notification-evolution-plugin-5.4-4.fc10.ppc requires libcamel-provider-1.2.so.14
	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)
	mono-cecil-flowanalysis-0.1-0.6.20080409svn100264.fc11.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc requires libltdl.so.3
	mythes-nb-2.0.10-1.fc11.noarch requires mythes
	mythes-nn-2.0.10-1.fc11.noarch requires mythes
	nautilus-search-tool-0.2.2-4.fc10.ppc requires libgnome-desktop-2.so.7
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	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(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(Toploop) = 0:ead8879d71c4d5137fe5100fdd682a0b
	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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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(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(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	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(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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)
	padevchooser-0.9.4-0.6.svn20070925.fc10.ppc requires libgnome-desktop-2.so.7
	pdfcube-0.0.2-8.fc9.ppc requires libpoppler.so.3
	pdfcube-0.0.2-8.fc9.ppc requires libpoppler-glib.so.3
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts-experimental
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts
	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
	planner-eds-0.14.3-6.fc10.ppc requires libcamel-1.2.so.14
	planner-eds-0.14.3-6.fc10.ppc requires libcamel-provider-1.2.so.14
	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
	tellico-1.3.4-1.fc10.ppc requires libpoppler.so.3
	tracker-0.6.6-3.fc10.ppc requires libpoppler-glib.so.3
	tracker-0.6.6-3.fc10.ppc64 requires libpoppler-glib.so.3()(64bit)
	tracker-search-tool-0.6.6-3.fc10.ppc requires libgnome-desktop-2.so.7
	wput-0.6.1-4.fc9.ppc requires libgnutls-openssl.so.13



Broken deps for ppc64
----------------------------------------------------------
	autodir-0.99.9-5.fc9.ppc64 requires libltdl.so.3()(64bit)
	avant-window-navigator-0.2.6-9.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	bigboard-0.6.4-2.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
	deskbar-applet-2.24.0-2.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	desktop-data-model-1.2.5-1.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	epdfview-0.1.6-4.fc10.ppc64 requires libpoppler-glib.so.3()(64bit)
	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-zimbra-0.1.1-3.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	evolution-zimbra-0.1.1-3.fc10.ppc64 requires libcamel-provider-1.2.so.14()(64bit)
	foobillard-3.0a-8.fc10.ppc64 requires dejavu-fonts
	freeradius-2.1.1-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	galeon-2.0.7-3.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	gift-0.11.8.1-10.fc9.ppc64 requires libltdl.so.3()(64bit)
	gnome-compiz-manager-0.10.4-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	gnome-launch-box-0.4-10.fc10.ppc64 requires libgnome-desktop-2.so.7()(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)
	inkscape-0.46-6.fc10.ppc64 requires libpoppler.so.3()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	kdebindings-4.1.2-2.fc10.ppc64 requires libqscintilla2.so.4()(64bit)
	kpackagekit-0.3.1-4.fc10.ppc64 requires libpackagekit-qt.so.10()(64bit)
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libp11-0.2.3-3.fc10.ppc64 requires libltdl.so.3()(64bit)
	mail-notification-evolution-plugin-5.4-4.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	mail-notification-evolution-plugin-5.4-4.fc10.ppc64 requires libcamel-provider-1.2.so.14()(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)
	mythes-nb-2.0.10-1.fc11.noarch requires mythes
	mythes-nn-2.0.10-1.fc11.noarch requires mythes
	nautilus-search-tool-0.2.2-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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-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(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(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	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(Lexing) = 0:b1793496643444d3762dd42bebe2cfe3
	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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(Set) = 0:7da14e671a035f12386ace3890018ef3
	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(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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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)
	padevchooser-0.9.4-0.6.svn20070925.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	pdfcube-0.0.2-8.fc9.ppc64 requires libpoppler-glib.so.3()(64bit)
	pdfcube-0.0.2-8.fc9.ppc64 requires libpoppler.so.3()(64bit)
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts-experimental
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts
	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)
	planner-eds-0.14.3-6.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	planner-eds-0.14.3-6.fc10.ppc64 requires libcamel-provider-1.2.so.14()(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)
	tellico-1.3.4-1.fc10.ppc64 requires libpoppler.so.3()(64bit)
	tracker-0.6.6-3.fc10.ppc64 requires libpoppler-glib.so.3()(64bit)
	tracker-search-tool-0.6.6-3.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	wput-0.6.1-4.fc9.ppc64 requires libgnutls-openssl.so.13()(64bit)





From rajeeshknambiar at gmail.com  Thu Nov 27 12:08:51 2008
From: rajeeshknambiar at gmail.com (Rajeesh K Nambiar)
Date: Thu, 27 Nov 2008 17:38:51 +0530
Subject: NM 0.7.0
In-Reply-To: <492E5825.1060204@poolshark.org>
References: <492E5825.1060204@poolshark.org>
Message-ID: <815462c80811270408t2803cb0av7142e1b85528487f@mail.gmail.com>

Well, I just wanted to join the chorus. Awesome work !

On Thu, Nov 27, 2008 at 1:49 PM, Denis Leroy <denis at poolshark.org> wrote:

> I swear I just saw a flock of pigs flying by :-)
>
> Congratulations to the NetworkManager team!
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
Cheers,
Rajeesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081127/c248d57b/attachment.htm>

From rc040203 at freenet.de  Thu Nov 27 12:22:07 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 27 Nov 2008 13:22:07 +0100
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <492E711B.2010803@leemhuis.info>
References: <492E05E7.2080708@cchtml.com>
	<20081127093226.GA6829@amd.home.annexia.org>
	<492E711B.2010803@leemhuis.info>
Message-ID: <1227788527.4300.394.camel@beck.corsepiu.local>

On Thu, 2008-11-27 at 11:06 +0100, Thorsten Leemhuis wrote:
> On 27.11.2008 10:32, Richard W.M. Jones wrote:
> > On Wed, Nov 26, 2008 at 08:28:55PM -0600, Michael Cronenworth wrote:
> >> Far too often I find myself looking for non-existent man pages, Google  
> >> results, or help menus in GNU/Linux software. What's the problem? There  
> >> is no single, reliable, standardized documentation system that is  
> >> universally accepted or appreciated. Yes, what I'm about to describe  
> >> should obsolete man, info, and all the other dozen "help" documentation  
> >> found in all the Fedora packages.
> > 
> > Debian forces all programs to come with a man page.  If one is
> > missing, this is considered a bug and packagers have to write one.
> > 
> > http://www.debian.org/doc/debian-policy/ch-docs.html
> > 
> > This would be an excellent idea for Fedora to follow (and we can,
> > license permitting, use the Debian man pages).
> 
> My 2 cent: It would be way better for everyone to get those man pages 
> upstream.
> 
> One reason for that: If you add man pages from debian to a fedora 
> package then you have to recheck every now and then if the man pages are 
> still up2date. That afaics often tends to be forgotten (I'm guilty 
> myself here).
Well, pressurize upstreams or learn to use help2man?

Ralf




From rc040203 at freenet.de  Thu Nov 27 12:22:14 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 27 Nov 2008 13:22:14 +0100
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <20081127093226.GA6829@amd.home.annexia.org>
References: <492E05E7.2080708@cchtml.com>
	<20081127093226.GA6829@amd.home.annexia.org>
Message-ID: <1227788534.4300.395.camel@beck.corsepiu.local>

On Thu, 2008-11-27 at 09:32 +0000, Richard W.M. Jones wrote:
> On Wed, Nov 26, 2008 at 08:28:55PM -0600, Michael Cronenworth wrote:
> > Far too often I find myself looking for non-existent man pages, Google  
> > results, or help menus in GNU/Linux software. What's the problem? There  
> > is no single, reliable, standardized documentation system that is  
> > universally accepted or appreciated. Yes, what I'm about to describe  
> > should obsolete man, info, and all the other dozen "help" documentation  
> > found in all the Fedora packages.
> 
> Debian forces all programs to come with a man page.  If one is
> missing, this is considered a bug and packagers have to write one.
> 
> http://www.debian.org/doc/debian-policy/ch-docs.html
> 
> This would be an excellent idea for Fedora to follow (and we can,
> license permitting, use the Debian man pages).
+1 from me, excellent proposal! 

Ralf




From mcepl at redhat.com  Thu Nov 27 12:31:50 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 27 Nov 2008 13:31:50 +0100
Subject: Feature proposal: New, Standard Documentation System
References: <492E05E7.2080708@cchtml.com> <1227761096.31656.50.camel@beta>
	<1c9206xjvb.ln2@ppp1053.in.ipex.cz> <492E7903.7020603@pingoured.fr>
	<492E7999.3070100@pingoured.fr>
Message-ID: <mig206xu2h.ln2@ppp1053.in.ipex.cz>

On 2008-11-27, 10:42 GMT, Pierre-Yves wrote:
>> 'The requested URI "man:///mans" is invalid'
> err "man:///man"

KDE or Gnome? If Gnome (where it works for me) which version of 
yelp is installed?

Mat?j



From pingou at pingoured.fr  Thu Nov 27 12:54:23 2008
From: pingou at pingoured.fr (Pierre-Yves)
Date: Thu, 27 Nov 2008 13:54:23 +0100
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <mig206xu2h.ln2@ppp1053.in.ipex.cz>
References: <492E05E7.2080708@cchtml.com>
	<1227761096.31656.50.camel@beta>	<1c9206xjvb.ln2@ppp1053.in.ipex.cz>
	<492E7903.7020603@pingoured.fr>	<492E7999.3070100@pingoured.fr>
	<mig206xu2h.ln2@ppp1053.in.ipex.cz>
Message-ID: <492E987F.5040909@pingoured.fr>

Matej Cepl wrote:
> On 2008-11-27, 10:42 GMT, Pierre-Yves wrote:
>>> 'The requested URI "man:///mans" is invalid'
>> err "man:///man"
> 
> KDE or Gnome? If Gnome (where it works for me) which version of 
> yelp is installed?
yelp-2.24.0-3.fc10.x86_64
Gnome
F10 fresh from 2 days :)

Thanks,

Pierre



From bmr at redhat.com  Thu Nov 27 13:06:19 2008
From: bmr at redhat.com (Bryn M. Reeves)
Date: Thu, 27 Nov 2008 13:06:19 +0000
Subject: PulseAudio info needed
In-Reply-To: <200811271301.11802.cannewilson@googlemail.com>
References: <200811271301.11802.cannewilson@googlemail.com>
Message-ID: <492E9B4B.4000206@redhat.com>

Anne Wilson wrote:
> There is a lot of FUD and general mistrust of PA.  It seems to me that it 
> would help a great deal if someone would write a short statement about what PA 
> is and how it should work.  If there is known readable references, they would 
> help too, as would noting any known work-arounds for problem.
> 
> It would be a great help to those of us who try to give user support.  I'd 
> even put it on my own web space and direct folk to it, if that would help.

There's a lot of good information on the PulseAudio project pages 
themselves:

http://www.pulseaudio.org/wiki/AboutPulseAudio
http://www.pulseaudio.org/wiki/FirstSteps
http://www.pulseaudio.org/wiki/PerfectSetup
http://www.pulseaudio.org/wiki/FAQ

Maybe someone would be interested in summarising some of this and adding 
Fedora-specifics on the Fedora wiki to make it a bit less intimidating 
for novice users?

Regards,
Bryn.



From galibert at pobox.com  Thu Nov 27 13:10:17 2008
From: galibert at pobox.com (Olivier Galibert)
Date: Thu, 27 Nov 2008 14:10:17 +0100
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <492E4109.4000909@cchtml.com>
References: <492E05E7.2080708@cchtml.com> <1227761096.31656.50.camel@beta>
	<200811262136.40430.konrad@tylerc.org>
	<492E4109.4000909@cchtml.com>
Message-ID: <20081127131016.GA77161@dspnet.fr.eu.org>

On Thu, Nov 27, 2008 at 12:41:13AM -0600, Michael Cronenworth wrote:
> Before this "manpage-to-HTML" idea goes any further, I'd like to stop it.
> 
> This is not what I have envisioned. An HTML rendering engine is too 
> beefy. I'm going on previous Fedora requirements of lighter 
> documentation engines, particularly the release notes in anaconda.

If you think than groff (man), tex/makeinfo (info), docbook and their
friends are significantly lighter than an html rendering engine,
you're deluded.  Some of them only seem lighter because the files are
pre-rendered to slightly enriched text at installation time.

Now, if you'd manage to come up with a xterm/console and a graphical
tool that could find what documentation is available for a particular
command (be it man, texinfo, docbook or whatever kde, gnome, qt,
java... uses) and show it on the text or graphical interface the best
it can with unified navigation commands (including search), you would
make a lot of people happy.

But a unification of documentation formats is something that just will
not happen *even* if you make converters available.

  OG.



From mcepl at redhat.com  Thu Nov 27 13:03:08 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 27 Nov 2008 14:03:08 +0100
Subject: Feature proposal: New, Standard Documentation System
References: <492E05E7.2080708@cchtml.com> <1227761096.31656.50.camel@beta>
	<1c9206xjvb.ln2@ppp1053.in.ipex.cz> <492E7903.7020603@pingoured.fr>
	<492E7999.3070100@pingoured.fr> <mig206xu2h.ln2@ppp1053.in.ipex.cz>
	<492E987F.5040909@pingoured.fr>
Message-ID: <cdi206xt3j.ln2@ppp1053.in.ipex.cz>

On 2008-11-27, 12:54 GMT, Pierre-Yves wrote:
> Matej Cepl wrote:
>> On 2008-11-27, 10:42 GMT, Pierre-Yves wrote:
>>>> 'The requested URI "man:///mans" is invalid'
>>> err "man:///man"
>> 
>> KDE or Gnome? If Gnome (where it works for me) which version of 
>> yelp is installed?
> yelp-2.24.0-3.fc10.x86_64
> Gnome
> F10 fresh from 2 days :)

yes, you are right. Sorry, 
https://bugzilla.redhat.com/show_bug.cgi?id=473257

Mat?j



From lemenkov at gmail.com  Thu Nov 27 13:33:55 2008
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Thu, 27 Nov 2008 16:33:55 +0300
Subject: PulseAudio info needed
In-Reply-To: <492E9B4B.4000206@redhat.com>
References: <200811271301.11802.cannewilson@googlemail.com>
	<492E9B4B.4000206@redhat.com>
Message-ID: <adf480660811270533m7ba4be5ctd1e98359ed8800dd@mail.gmail.com>

2008/11/27 Bryn M. Reeves <bmr at redhat.com>:
> Anne Wilson wrote:
>>
>> There is a lot of FUD and general mistrust of PA.  It seems to me that it
>> would help a great deal if someone would write a short statement about what
>> PA is and how it should work.  If there is known readable references, they
>> would help too, as would noting any known work-arounds for problem.
>>
>> It would be a great help to those of us who try to give user support.  I'd
>> even put it on my own web space and direct folk to it, if that would help.
>
> There's a lot of good information on the PulseAudio project pages
> themselves:
>
> http://www.pulseaudio.org/wiki/AboutPulseAudio
> http://www.pulseaudio.org/wiki/FirstSteps
> http://www.pulseaudio.org/wiki/PerfectSetup
> http://www.pulseaudio.org/wiki/FAQ
>
> Maybe someone would be interested in summarising some of this and adding
> Fedora-specifics on the Fedora wiki to make it a bit less intimidating for
> novice users?

My advice to all novices is to remove pulseaudio (as yet, it's still
possible to remove almost completely this useless and buggy
component). I wonder how it was decided (and whom) to push in as a
default soundsystem?

Most amazing feature of F-10 is "glitch-free sound with PulseAudio".
Just think about - it's 2008 (almost 2009), and Fedora finally
promises that its default soundserver would sometimes works.

The most obscure part of PulseAudio story (except numerous "help!
pulseaudio doesn't work for me" posts in various russian linux forums)
is how it was chosen among other stable and mature alternatives. I
really don't understant it.

We got some soundservers already - namely, JACK, NAS, MAS (which was
developed under Freedesktop umbrella) and even ALSA native interface,
but someone choose solution which (even after long period of
development) still not ready for daily work and does not provide any
significant benefit to user even in long-term perspective.

-- 
With best regards!



From tim at niemueller.de  Thu Nov 27 14:56:47 2008
From: tim at niemueller.de (Tim Niemueller)
Date: Thu, 27 Nov 2008 15:56:47 +0100
Subject: No way to shut down from, gdm in F-10
In-Reply-To: <1227734404.3891.23.camel@ignacio.lan>
References: <200811261539.31233.sgrubb@redhat.com>
	<1227734404.3891.23.camel@ignacio.lan>
Message-ID: <492EB52F.7090608@niemueller.de>

Ignacio Vazquez-Abrams schrieb:
> On Wed, 2008-11-26 at 15:32 -0500, Steve Grubb wrote:
>> I booted F-10 up into run level 3. Logged in as root. Did some things and ran 
>> init 5. After I was done using the computer, I wanted to shut it down. There 
>> is absolutely nothing that I can click on that will let me shutdown the 
>> computer.
> 
> Did you try cancelling the login?

That's required on boxes that have the user list disabled to get the
buttons at all. They should probably be buttons in the status panel.

	Tim

-- 
    Tim Niemueller <tim at niemueller.de>      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)



From mschwendt at gmail.com  Thu Nov 27 14:58:03 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 27 Nov 2008 15:58:03 +0100
Subject: automatically include files in %doc only if they are not empty
In-Reply-To: <200811271255.12657.opensource@till.name>
References: <200811271255.12657.opensource@till.name>
Message-ID: <20081127155803.885118a2.mschwendt@gmail.com>

On Thu, 27 Nov 2008 12:55:07 +0100, Till Maas wrote:

> Hiyas,
> 
> on a package I recently packaged for Fedora, there is an empty TODO file 
> included. Is there an easy way to mark this file in %files to be included 
> only if it is not empty? This would make it easier to not forget to add the 
> file in case it will be filed with some contents in a future release.

%prep and %check : easy enough to add a bash conditional expression
(e.g. which exits with failure if the file exists and has a size greater
than zero -- or the opposite, a zero size, for files you want to exclude).



From mjg at redhat.com  Thu Nov 27 15:33:27 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Thu, 27 Nov 2008 15:33:27 +0000
Subject: RFC: Changing default filesystem parameters for power management
	reasons
Message-ID: <20081127153327.GA21300@srcf.ucam.org>

I'd like F11 to be more useful for disk power management. This involves 
tuning various parameters in order to reduce disk access. There are some 
tradeoffs involved, so I'd like feedback before pushing much of this.

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.

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.

The combination of these features should result in (on average) fewer 
disk accesses and so (on average) should provide better performance. 
There's a chance that some usage patterns will fall foul of this and 
lose performance, so if we do this I'd like to do it sufficiently early 
in the cycle that we can get real-world feedback.

Any thoughts?
-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From sandeen at redhat.com  Thu Nov 27 15:59:08 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Thu, 27 Nov 2008 09:59:08 -0600
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: <492EC3CC.9080105@redhat.com>

Matthew Garrett wrote:
> I'd like F11 to be more useful for disk power management. This involves 
> tuning various parameters in order to reduce disk access. There are some 
> tradeoffs involved, so I'd like feedback before pushing much of this.
> 
> 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.

I could be convinced of this, I think, although there were a few nagging
bugs w/ older Fedoras that seemed related to this change, and honestly
never got to the bottom of them.  But by and large Fedora already ran
this way w/ few problems in the past.

> 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 

s/paranoid/proper/ :)

> 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'll need to ponder these changes a bit more (and take another look at
laptop mode, it's been a while).

> The combination of these features should result in (on average) fewer 
> disk accesses and so (on average) should provide better performance. 

What are your plans to measure the results of these changes from power &
performance perspectives?  Also, tools to monitor what is causing disk
accesses might be good (see also Bug 454582 -  Tracker bug for
over-eager apps that won't let disks spin down).

Do you also have any plans for changing default disk spin-down times, or
would that be left to bios settings?  And if so, we should probably
monitor this for how it jives with the expected lifetime of a disk vs.
lifetime rating for spindown cycles.

The original laptop mode kit included specific knowledge about some
filesystem tuning parameters (commit times etc), is that part of your
plan?  Which filesystems will be recognized?

Thanks,
-Eric

> There's a chance that some usage patterns will fall foul of this and 
> lose performance, so if we do this I'd like to do it sufficiently early 
> in the cycle that we can get real-world feedback.
> 
> Any thoughts?



From P at draigBrady.com  Thu Nov 27 16:16:03 2008
From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=)
Date: Thu, 27 Nov 2008 16:16:03 +0000
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: <492EC7C3.5070408@draigBrady.com>

Matthew Garrett wrote:
> I'd like F11 to be more useful for disk power management. This involves 
> tuning various parameters in order to reduce disk access.
> 
> The first is relatime.
> The second is to increase the value of dirty_writeback_centisecs.
> Thirdly, I'd like to enable laptop mode by default.

Does the kernel export whether dev is an SSD.
If so, it would allow us to do a different combination of the above.

Generally userspace should do lots of things
differently/more efficiently if it knows a dev is an SSD.

P?draig.



From rjones at redhat.com  Thu Nov 27 16:23:28 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 27 Nov 2008 16:23:28 +0000
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <492E711B.2010803@leemhuis.info>
References: <492E05E7.2080708@cchtml.com>
	<20081127093226.GA6829@amd.home.annexia.org>
	<492E711B.2010803@leemhuis.info>
Message-ID: <20081127162328.GA8714@amd.home.annexia.org>

On Thu, Nov 27, 2008 at 11:06:19AM +0100, Thorsten Leemhuis wrote:
> On 27.11.2008 10:32, Richard W.M. Jones wrote:
>> Debian forces all programs to come with a man page.  If one is
>> missing, this is considered a bug and packagers have to write one.
>>
>> http://www.debian.org/doc/debian-policy/ch-docs.html
>
> My 2 cent: It would be way better for everyone to get those man pages  
> upstream.

I should clarify three points.

+1 to the suggestion that man pages should go upstream.  They should
be treated just like any other patch.  We should encourage Debian to
do the same, but if they don't we take Debian's man pages and push
them upstream ourselves.

My second point is that it's a really useful feature of Debian that
_any_ command, any many configuration files and other files, are
documented using 'man'.  I find it a big negative against Fedora that
things aren't so consistently documented.

And lastly I'm not suggesting that beginners should have to type 'man
foo'.  Once everything is available as a man page, it should be
relatively easy to present those in the UI through some suitable
mechanism, whether that is groff->HTML conversion or whatever.

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 mjg at redhat.com  Thu Nov 27 16:38:24 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Thu, 27 Nov 2008 16:38:24 +0000
Subject: RFC: Changing default filesystem parameters for power
	management reasons
In-Reply-To: <492EC7C3.5070408@draigBrady.com>
References: <20081127153327.GA21300@srcf.ucam.org>
	<492EC7C3.5070408@draigBrady.com>
Message-ID: <20081127163824.GA22963@srcf.ucam.org>

On Thu, Nov 27, 2008 at 04:16:03PM +0000, P?draig Brady wrote:

> Does the kernel export whether dev is an SSD.
> If so, it would allow us to do a different combination of the above.

It can do, but I'd need to check if it does. You're right that the 
tradeoffs are different there, so I'd want to spend a while looking at 
that.

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



From mjg at redhat.com  Thu Nov 27 16:44:06 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Thu, 27 Nov 2008 16:44:06 +0000
Subject: RFC: Changing default filesystem parameters for power
	management reasons
In-Reply-To: <492EC3CC.9080105@redhat.com>
References: <20081127153327.GA21300@srcf.ucam.org>
	<492EC3CC.9080105@redhat.com>
Message-ID: <20081127164406.GB22963@srcf.ucam.org>

On Thu, Nov 27, 2008 at 09:59:08AM -0600, Eric Sandeen wrote:

> What are your plans to measure the results of these changes from power &
> performance perspectives?  Also, tools to monitor what is causing disk
> accesses might be good (see also Bug 454582 -  Tracker bug for
> over-eager apps that won't let disks spin down).

Power-wise, I have measuring equipment here. Performance is obviously 
harder - I suspect synthetic benchmarks will get much the same 
performance as usual, so that might be down to waiting to see if users 
complain.

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. I had a handwavy patch to do that, but we 
probably want a good way of exposing that information to userspace.

> Do you also have any plans for changing default disk spin-down times, or
> would that be left to bios settings?  And if so, we should probably
> monitor this for how it jives with the expected lifetime of a disk vs.
> lifetime rating for spindown cycles.

Yes, the long-term plan involves allowing drive spindown. I'm hoping to 
do this adaptively to let us avoid the spinup/down tendancies a static 
timeout provides, but you're right that monitoring SMART information 
would be a pretty important part of that. I lean towards offering it on 
desktops and servers, but not enabled by default.

> The original laptop mode kit included specific knowledge about some
> filesystem tuning parameters (commit times etc), is that part of your
> plan?  Which filesystems will be recognized?

Mm. My recollection is that ext3 and xfs had easy to access tuning to 
help in this respect. Changing the kernel defaults would be one option 
there, or alternatively we could update fstab?

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



From trond.danielsen at gmail.com  Thu Nov 27 17:12:04 2008
From: trond.danielsen at gmail.com (Trond Danielsen)
Date: Thu, 27 Nov 2008 18:12:04 +0100
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <20081127162328.GA8714@amd.home.annexia.org>
References: <492E05E7.2080708@cchtml.com>
	<20081127093226.GA6829@amd.home.annexia.org>
	<492E711B.2010803@leemhuis.info>
	<20081127162328.GA8714@amd.home.annexia.org>
Message-ID: <409676c70811270912q21f099e1p36ba2a6b5bb6e6d1@mail.gmail.com>

2008/11/27 Richard W.M. Jones <rjones at redhat.com>:
> And lastly I'm not suggesting that beginners should have to type 'man
> foo'.  Once everything is available as a man page, it should be
> relatively easy to present those in the UI through some suitable
> mechanism, whether that is groff->HTML conversion or whatever.

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



From mschwendt at gmail.com  Thu Nov 27 17:19:45 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 27 Nov 2008 17:19:45 -0000
Subject: Broken dependencies in Fedora 10 - 2008-11-27
Message-ID: <20081127171945.12430.50732@faldor.intranet>

Summary of broken packages (by owner):

    dhuff AT redhat.com
        appliance-tools

    jdennis AT redhat.com
        freeradius

    smparrish AT shallowcreek.net
        kpackagekit

    sundaram AT redhat.com
        gyachi
        olpc-utils


======================================================================
Broken packages in fedora-10-i386:

    freeradius-dialupadmin-ldap-2.1.1-2.fc10.i386  requires  freeradius-ldap = 0:2.1.1-2.fc10
    freeradius-dialupadmin-mysql-2.1.1-2.fc10.i386  requires  freeradius-mysql = 0:2.1.1-2.fc10
    freeradius-dialupadmin-postgresql-2.1.1-2.fc10.i386  requires  freeradius-postgresql = 0:2.1.1-2.fc10
    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
    kpackagekit-0.3.1-4.fc10.i386  requires  libpackagekit-qt.so.10


======================================================================
Broken packages in fedora-10-ppc:

    freeradius-dialupadmin-ldap-2.1.1-2.fc10.ppc  requires  freeradius-ldap = 0:2.1.1-2.fc10
    freeradius-dialupadmin-mysql-2.1.1-2.fc10.ppc  requires  freeradius-mysql = 0:2.1.1-2.fc10
    freeradius-dialupadmin-postgresql-2.1.1-2.fc10.ppc  requires  freeradius-postgresql = 0:2.1.1-2.fc10
    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
    kpackagekit-0.3.1-4.fc10.ppc  requires  libpackagekit-qt.so.10


======================================================================
Broken packages in fedora-10-ppc64:

    freeradius-dialupadmin-ldap-2.1.1-2.fc10.ppc64  requires  freeradius-ldap = 0:2.1.1-2.fc10
    freeradius-dialupadmin-mysql-2.1.1-2.fc10.ppc64  requires  freeradius-mysql = 0:2.1.1-2.fc10
    freeradius-dialupadmin-postgresql-2.1.1-2.fc10.ppc64  requires  freeradius-postgresql = 0:2.1.1-2.fc10
    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
    kpackagekit-0.3.1-4.fc10.ppc64  requires  libpackagekit-qt.so.10()(64bit)


======================================================================
Broken packages in fedora-10-x86_64:

    freeradius-dialupadmin-ldap-2.1.1-2.fc10.x86_64  requires  freeradius-ldap = 0:2.1.1-2.fc10
    freeradius-dialupadmin-mysql-2.1.1-2.fc10.x86_64  requires  freeradius-mysql = 0:2.1.1-2.fc10
    freeradius-dialupadmin-postgresql-2.1.1-2.fc10.x86_64  requires  freeradius-postgresql = 0:2.1.1-2.fc10
    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
    kpackagekit-0.3.1-4.fc10.x86_64  requires  libpackagekit-qt.so.10()(64bit)


======================================================================
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



From seg at haxxed.com  Thu Nov 27 17:28:05 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Thu, 27 Nov 2008 11:28:05 -0600
Subject: What do we need from Bugzilla? (was: My roadmap for a better
 Fedora)
In-Reply-To: <492BEA50.1090604@iinet.net.au>
References: <16de708d0811191447v2a42e584sda71761a46dfc0a9@mail.gmail.com>
	<49256382.3080506@iinet.net.au>  <492BEA50.1090604@iinet.net.au>
Message-ID: <1227806885.4755.242.camel@localhost.localdomain>

On Tue, 2008-11-25 at 23:06 +1100, David Timms wrote:
> David Timms wrote:
> > Arthur Pemberton wrote:
> >> My question is, what do we need/want/like from Bugzilla?
> > wishes:
> >   - a separate by-line for me-too comments (eg I got that on x86_64, I 
> > got it on a "piece of old carpet" things that people tend to add to 
> > bugzilla / bugs.launchpad etc. These can server as breadth of issue 
> > marker, but aren't really clarifying a bug, with option to add hardware 
> > id from smolt. [ x ] I experienced this symptom and my smolt hardware 
> > dsecription is [http://smotls.y.z/12345656]
> > 
> >     - a way to mark a me-too comment as "me-too".
> 
> Just came across following which provides another viewpoint:
> http://linuxhaters.blogspot.com/2008/08/one-bug-report-to-rule-them-all.html

What would be useful is something like comments on Slashdot or Digg,
useless comments can be folded out of the way. Also a way to just move
comments from one bug to another.

Hey why not bite the bullet and go to fully threaded comments. :P Noisy
conversations aren't exactly a new area of software engineering. We just
need to be mindful of the proven designs that have existed for decades.
(Mail readers, mailing lists, usenet...)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081127/aa04407f/attachment.sig>

From tmz at pobox.com  Thu Nov 27 17:53:09 2008
From: tmz at pobox.com (Todd Zullinger)
Date: Thu, 27 Nov 2008 12:53:09 -0500
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: <20081127175309.GI20204@inocybe.teonanacatl.org>

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

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Happiness, n.: An agreeable sensation arising from contemplating the
misery of another.
    -- 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/20081127/4a539dc3/attachment.sig>

From seg at haxxed.com  Thu Nov 27 18:03:02 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Thu, 27 Nov 2008 12:03:02 -0600
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <492E4109.4000909@cchtml.com>
References: <492E05E7.2080708@cchtml.com> <1227761096.31656.50.camel@beta>
	<200811262136.40430.konrad@tylerc.org>  <492E4109.4000909@cchtml.com>
Message-ID: <1227808982.4755.276.camel@localhost.localdomain>

On Thu, 2008-11-27 at 00:41 -0600, Michael Cronenworth wrote:
> Before this "manpage-to-HTML" idea goes any further, I'd like to stop
> it.
> 
> This is not what I have envisioned. An HTML rendering engine is too
> beefy. I'm going on previous Fedora requirements of lighter
> documentation engines, particularly the release notes in anaconda.

Anything but HTML is insane in this day and age. If a full HTML engine
is too heavy, use a simple subset. There's plenty of options, Gecko,
WebKit, GtkHTML, Dillo, Lynx, Links...

You don't have to write in HTML, you can derive it from just about
anything else. Man pages, GNU info, docbook, Doxygen, Javadoc,
OpenOffice Writer... No need to force all upstreams to one format.

Really the problem here is front end UI. There's yelp, but I wish I
could just browse documentation inside Firefox...

Hell, carrying around documentation is one of the major disk eaters in a
Fedora install.

$ du -sh /usr/share/doc/
377M	/usr/share/doc/

What would be neat is if we could transparently grab documentation from
online instead of having it eat up disk space even though you probably
only ever need a fraction of it... Hmmmm...

What say we hack up a script to pull all documentation out of every RPM
in a release, convert all man and info pages to HTML, and put it all up
on docs.fedoraproject.org? Then embed a Google search on top of it. Ta
da, a one stop shop for all documentation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081127/80b0408b/attachment.sig>

From mschwendt at gmail.com  Thu Nov 27 18:45:45 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 27 Nov 2008 19:45:45 +0100
Subject: yum upgrade from F-9 to F-10
In-Reply-To: <alpine.LRH.2.00.0811270851270.20197@netcore.fi>
References: <5256d0b0811011137ye3910fco1a0726c96c3a4c65@mail.gmail.com>
	<alpine.LFD.2.00.0811012257430.30198@vega2.dur.ac.uk>
	<alpine.LRH.2.00.0811270851270.20197@netcore.fi>
Message-ID: <20081127194545.f4b0c1d5.mschwendt@gmail.com>

On Thu, 27 Nov 2008 08:54:38 +0200 (EET), Pekka Savola wrote:

> In F-9 -> F-10 upgrade, I got the following error, which I worked 
> around by removing pidgin.  Could someone add that to YumUpgradeFaq 
> under F-10 specifics?
> 
> pidgin-2.5.2-2.fc9.i386 from installed has depsolving problems
>    --> Missing Dependency: libedataserver-1.2.so.9 is needed by package pidgin-2.5.2-2.fc9.i386 (installed)
> Error: Missing Dependency: libedataserver-1.2.so.9 is needed by package pidgin-2.5.2-2.fc9.i386 (installed)
> 

It's a typical upgrade path issue. F-10 comes with 2.5.2-1.fc10 which is
seen as "older than" 2.5.2-2.fc9 because of the higher "2" release in the F-9 pkg.
You would need the newer piding from updates-testing to resolve this.



From sandeen at redhat.com  Thu Nov 27 19:16:54 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Thu, 27 Nov 2008 13:16:54 -0600
Subject: RFC: Changing default filesystem parameters for power	management
 reasons
In-Reply-To: <20081127164406.GB22963@srcf.ucam.org>
References: <20081127153327.GA21300@srcf.ucam.org>	<492EC3CC.9080105@redhat.com>
	<20081127164406.GB22963@srcf.ucam.org>
Message-ID: <492EF226.5000203@redhat.com>

Matthew Garrett wrote:
> On Thu, Nov 27, 2008 at 09:59:08AM -0600, Eric Sandeen wrote:
> 
>> What are your plans to measure the results of these changes from power &
>> performance perspectives?  Also, tools to monitor what is causing disk
>> accesses might be good (see also Bug 454582 -  Tracker bug for
>> over-eager apps that won't let disks spin down).
> 
> Power-wise, I have measuring equipment here. Performance is obviously 
> harder - I suspect synthetic benchmarks will get much the same 
> performance as usual, so that might be down to waiting to see if users 
> complain.
> 
> 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. I had a handwavy patch to do that, but we 
> probably want a good way of exposing that information to userspace.

Yeah.  Although you can tune things so that the block_dump stuff doesn't
go to /var/log/messages, but I'd played tricks in the past with saving
to ramdisks etc for this reason.  :)

It'd also be nice if we could reliably query drives for their state, but
in the past the query itself has spun up some of my drives.  :)

>> Do you also have any plans for changing default disk spin-down times, or
>> would that be left to bios settings?  And if so, we should probably
>> monitor this for how it jives with the expected lifetime of a disk vs.
>> lifetime rating for spindown cycles.
> 
> Yes, the long-term plan involves allowing drive spindown. I'm hoping to 
> do this adaptively to let us avoid the spinup/down tendancies a static 
> timeout provides, but you're right that monitoring SMART information 
> would be a pretty important part of that. I lean towards offering it on 
> desktops and servers, but not enabled by default.

Sounds good.  We don't want a "Fedora kills hard drives!" thread.  :)

>> The original laptop mode kit included specific knowledge about some
>> filesystem tuning parameters (commit times etc), is that part of your
>> plan?  Which filesystems will be recognized?
> 
> Mm. My recollection is that ext3 and xfs had easy to access tuning to 
> help in this respect. Changing the kernel defaults would be one option 
> there, or alternatively we could update fstab?

Yep, they do.  xfs even has a bit of code specifically to work w/ laptop
mode.  Looks like the current laptop tools do handle ext3 & xfs from a
cursory glance.  Should probably make sure that ext4 is properly handled
too.

-Eric



From opensource at till.name  Thu Nov 27 19:25:45 2008
From: opensource at till.name (Till Maas)
Date: Thu, 27 Nov 2008 20:25:45 +0100
Subject: Strange ext3 problem
In-Reply-To: <200811011409.09809.konrad@tylerc.org>
References: <5f6f8c5f0810311525s4a1ddd31y49527359340190b6@mail.gmail.com>
	<m3zlkjii6d.fsf@ursa.amorsen.dk> <200811011409.09809.konrad@tylerc.org>
Message-ID: <200811272025.51525.opensource@till.name>

On Sat November 1 2008, Conrad Meyer wrote:
> On Saturday 01 November 2008 08:23:38 am Benny Amorsen wrote:
> > Till Maas <opensource at till.name> writes:
> > > The last time I tested my setup, free showed more memory from my 4GB
> > > with 32-bit PAE than with x86_64.
> >
> > About time we got that kind of issue debugged then.
>
> I think the point he was getting at is that 64-bit uses more memory than
> 32-bit.

I only described my observations. But still on Fedora 8 i686 PAE more memory 
is recognized than on Fedora 10 GA:

i686 PAE | x86_64
4022 MB  | 3933 MB

But I agree that is has improved since 2008-10-08, where I only got 3715 MB 
with x86_64 from Fedora 9.

Btw. also x86_64 seems to be slower than i686, e.g. aes-128-cbc encryption is 
for block sizes greater than 16 around 20 % faster with i686 than with 
x86_64. This is also true for a i686 kvm machine on a x86_64 host.

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/20081127/4de347b4/attachment.sig>

From mschwendt at gmail.com  Thu Nov 27 19:42:38 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 27 Nov 2008 20:42:38 +0100
Subject: shortening time passed in bodhi?
In-Reply-To: <20081126213215.GQ2780@free.fr>
References: <20081126150440.GD2780@free.fr>
	<1227721928.5276.73.camel@luminos.localdomain>
	<20081126181208.GN2780@free.fr>
	<1227726481.5276.85.camel@luminos.localdomain>
	<20081126191926.GP2780@free.fr>
	<1227727922.5276.90.camel@luminos.localdomain>
	<20081126213215.GQ2780@free.fr>
Message-ID: <20081127204239.aa29f0b7.mschwendt@gmail.com>

On Wed, 26 Nov 2008 22:32:15 +0100, Patrice Dumas wrote:

> On Wed, Nov 26, 2008 at 11:32:02AM -0800, Jesse Keating wrote:
> > > be checked manually.
> > 
> > er, this time period is I do believe less than a second, and it's done
> > automatically by bodhi when you make the request.  It just fails the
> > request if the tag isn't correct.
> 
> Ok.
> 
> > The pending state is there because people often work on an update
> > request at multiple times, and want to be able to add to it and adjust
> > it before doing the final push request, 
> 
> Who want that? In any case it should be optional. My update waited in
> pending state for 2 days. These are 2 days wasted.
> 
> > and also from a app code point
> > of view I think the update object has to have one form of existence
> > outside of either push requested or pushed.
> 
> But it could be instantaneous.

Only on the master download server. For the world-wide mirrors (and their
users), it still won't be instantaneous.  Unless you create a system
where the master can call back to mirrors and request them to sync. ;)

I see the benefit of being able to publish [security] updates quickly
(such as with the old extras/epel scripts, although the createrepo time
added up there, too), but the more packagers push pkgs instantly, the more
often the master repo (and the metadata) changes, and the more quickly the
entire distribution moves under the feet of our users. I don't think it is
a good idea to do that. A queue that controls the flow of non-security
packages creates less mirroring chaos.



From triad at df.lth.se  Thu Nov 27 20:36:17 2008
From: triad at df.lth.se (Linus Walleij)
Date: Thu, 27 Nov 2008 21:36:17 +0100
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: <1227818177.2968.10.camel@c83-254-42-244.bredband.comhem.se>

tor 2008-11-27 klockan 15:33 +0000 skrev Matthew Garrett:

> I'd like F11 to be more useful for disk power management.

Cool!

> The first is relatime. I've just pushed Ingo's smarter relatime code 
> towards upstream again.

Go for it!

> Thirdly, I'd like to enable laptop mode by default.

Are we talking of writing "5" into /proc/sys/vm/laptop_mode like for
desktops, servers, and laptops on mains power?

IIRC gnome-power-manager automatically enables this when the system goes
to run from battery, so I recon the idea is to make the laptop mode a
generic power-conservative mode, then should that be reflected in the
mainline kernel somehow by renaming said interface to ecosystem_mode or
something.

Is this really good for datacenter machines like database servers and
such, if we make it default?

> Any thoughts?

Great initiative!

You're mainly planning for kernel-level features for the whole line of
use cases and not at the level of userland tools like
gnome-power-manager that we currently rely on quite extensively to
manage power for desktops and laptops?

Linus



From opensource at till.name  Thu Nov 27 20:56:46 2008
From: opensource at till.name (Till Maas)
Date: Thu, 27 Nov 2008 21:56:46 +0100
Subject: Translating summary text of packages
In-Reply-To: <686ad03bbbe15b64bf6492a4010c8de9.squirrel@arekh.dyndns.org>
References: <a7804a540811240038p72f15e65qcd76d21c28bf4831@mail.gmail.com>
	<200811251414.57424.opensource@till.name>
	<686ad03bbbe15b64bf6492a4010c8de9.squirrel@arekh.dyndns.org>
Message-ID: <200811272156.57402.opensource@till.name>

On Tue November 25 2008, Nicolas Mailhot wrote:
> Le Mar 25 novembre 2008 14:14, Till Maas a ?crit :
> > If you want to translate them, you should probably coordinate with the
> > Fedora
> > Localization Project:
> > https://fedoraproject.org/wiki/L10N
>
> BTW would it be possible for some native speakers to set up a *en_US*
> localisation group that reviews and edits the base summaries and
> descriptions *before* all the other l10n groups have to deal with
> them?

I guess you should ask this some member of the Localozation Project, too. But 
it sounds like a good idea to me.

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/20081127/4883e301/attachment.sig>

From mschwendt at gmail.com  Thu Nov 27 21:24:22 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 27 Nov 2008 21:24:22 -0000
Subject: Broken dependencies in Fedora 9 - 2008-11-27
Message-ID: <20081127212422.17454.57488@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
        lsvpd

    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

    paul AT all-the-johnsons.co.uk
        mono-tools

    phuang AT redhat.com
        scim-bridge

    sundaram AT redhat.com
        gyachi

    twaugh AT redhat.com
        system-config-printer

    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-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-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-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-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
    lsvpd-1.6.4-1.fc9.i386  requires  libvpd_cxx-2.0.so.1
    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
    lsvpd-1.6.4-1.fc9.ppc  requires  libvpd_cxx-2.0.so.1
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11
    mono-tools-1.9-3.fc9.ppc  requires  mono(glade-sharp) = 0:2.10.0.0
    mono-tools-1.9-3.fc9.ppc  requires  mono(gdk-sharp) = 0:2.10.0.0
    mono-tools-1.9-3.fc9.ppc  requires  mono(pango-sharp) = 0:2.10.0.0
    mono-tools-1.9-3.fc9.ppc  requires  mono(glib-sharp) = 0:2.10.0.0
    mono-tools-1.9-3.fc9.ppc  requires  mono(gtk-sharp) = 0:2.10.0.0
    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:

    cyphesis-0.5.15-8.fc9.ppc64  requires  libmercator-0.2.so.4()(64bit)
    livecd-tools-017.1-1.fc9.ppc64  requires  yaboot
    lsvpd-1.6.4-1.fc9.ppc64  requires  libvpd_cxx-2.0.so.1()(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)


======================================================================
Broken packages in fedora-updates-9-x86_64:

    cyphesis-0.5.15-8.fc9.x86_64  requires  libmercator-0.2.so.4()(64bit)
    lsvpd-1.6.4-1.fc9.x86_64  requires  libvpd_cxx-2.0.so.1()(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)


======================================================================
Broken packages in fedora-updates-testing-9-i386:

    system-config-printer-1.0.11-1.fc9.i386  requires  gnome-python2-gnome


======================================================================
Broken packages in fedora-updates-testing-9-ppc:

    system-config-printer-1.0.11-1.fc9.ppc  requires  gnome-python2-gnome


======================================================================
Broken packages in fedora-updates-testing-9-ppc64:

    appliance-tools-002.8-1.fc9.noarch  requires  qemu-img
    system-config-printer-1.0.11-1.fc9.ppc64  requires  gnome-python2-gnome


======================================================================
Broken packages in fedora-updates-testing-9-x86_64:

    system-config-printer-1.0.11-1.fc9.x86_64  requires  gnome-python2-gnome



From mclasen at redhat.com  Thu Nov 27 21:51:42 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 27 Nov 2008 16:51:42 -0500
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: <1227822702.3285.7.camel@localhost.localdomain>

On Thu, 2008-11-27 at 12:53 -0500, Todd Zullinger wrote:
> 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
> 

It works, more or less. Try entering 'fdisk' in the search entry. It
shows the man page just fine. It doesn't work perfectly for all man
pages, but then man pages are not exactly structured documentation that
is friendly for indexing or reformatting...





From mschwendt at gmail.com  Thu Nov 27 22:16:12 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 27 Nov 2008 22:16:12 -0000
Subject: Broken dependencies in Fedora 8 - 2008-11-27
Message-ID: <20081127221612.18567.88569@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 pertusus at free.fr  Thu Nov 27 22:26:30 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 27 Nov 2008 23:26:30 +0100
Subject: shortening time passed in bodhi?
In-Reply-To: <20081127204239.aa29f0b7.mschwendt@gmail.com>
References: <20081126150440.GD2780@free.fr>
	<1227721928.5276.73.camel@luminos.localdomain>
	<20081126181208.GN2780@free.fr>
	<1227726481.5276.85.camel@luminos.localdomain>
	<20081126191926.GP2780@free.fr>
	<1227727922.5276.90.camel@luminos.localdomain>
	<20081126213215.GQ2780@free.fr>
	<20081127204239.aa29f0b7.mschwendt@gmail.com>
Message-ID: <20081127222630.GC2659@free.fr>

On Thu, Nov 27, 2008 at 08:42:38PM +0100, Michael Schwendt wrote:
> 
> Only on the master download server. For the world-wide mirrors (and their
> users), it still won't be instantaneous.  Unless you create a system
> where the master can call back to mirrors and request them to sync. ;)

I was only referring to the time between push to stable and repo ready
with package in it.

> I see the benefit of being able to publish [security] updates quickly
> (such as with the old extras/epel scripts, although the createrepo time
> added up there, too), but the more packagers push pkgs instantly, the more
> often the master repo (and the metadata) changes, and the more quickly the
> entire distribution moves under the feet of our users. I don't think it is
> a good idea to do that. A queue that controls the flow of non-security
> packages creates less mirroring chaos.

At the same time it may add time when an urgent update arrives and a
large queue of non urgent updates is being composed.

--
Pat



From mschwendt at gmail.com  Thu Nov 27 22:35:35 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 27 Nov 2008 23:35:35 +0100
Subject: Broken dependencies in Fedora 10 - 2008-11-27
In-Reply-To: <20081127171945.12430.50732@faldor.intranet>
References: <20081127171945.12430.50732@faldor.intranet>
Message-ID: <20081127233535.6c0134f0.mschwendt@gmail.com>

To clarify: This report was about F10 plus updates and updates-testing (!).



From alsadi at gmail.com  Thu Nov 27 22:41:51 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Fri, 28 Nov 2008 00:41:51 +0200
Subject: better internationalization in docbook-style-xsl
Message-ID: <385866f0811271441t5162598cxfc8062cda79b41e7@mail.gmail.com>

hi,
I made some patches into docbook-style-xsl-1.74.0-3.fc10.noarch
to make it better for international environment

before you ask me why in devel ML why not doc-ML why not upstream ?
I say because I want to make it better
so that when we upstream it we won't find any issue


for example the file html/docbook.xsl have a header like this
<xsl:output method="html"
            encoding="ISO-8859-1"
            indent="no"/>

while the xhtml/docbook.xsl uses utf-8

changing the first one to be just like the second ie. utf-8 encoding
won't drop any feature but it will produce better files
(if a non-ASCII non-Latin-1 is used with ISO-8859-1 encoding it will
be encoded like this &xxxx; for each char)

second thing,
left and right are not what we want, we want here and there
(in right to left languages left and right are mirrored)
in the ODF standard they call it start and end (start is the same
direction as the current script ie. left for English and right for
Arabic)

I patched the xsl with a script (to make sure they are all fixed
because a diff patch will be broken if the upstream make any change)

for i in html xhtml
do
perl -i -wpe 's/align="left"/align="{\$directions.align.start}"/g' ${i}/*
perl -i -wpe 's/align="right"/align="{\$directions.align.end}"/g' ${i}/*
done

this way all the align="left" will be substituted with the value of
the param directions.align.start ..etc.

we need to declare this param somewhere depending on the locale
so I edited html/param.xml to have something like

<xsl:param name="directions.align.start">
<xsl:choose>
<xsl:when test="$direction='rtl'">right</xsl:when>
<xsl:otherwise>left</xsl:otherwise>
</xsl:choose>
</xsl:param>

<xsl:param name="directions.align.end">
<xsl:choose>
<xsl:when test="$direction='rtl'">left</xsl:when>
<xsl:otherwise>right</xsl:otherwise>
</xsl:choose>
</xsl:param>

which mean if I cant to make a RTL right-to-left document a set a
param called direction to the value rtl
other wise left to right direction will be assumed

I need a better automated way for doing this
I want the direction to be guessed from the language of the document
if it's in the list of right-to-left languages (Arabic, Parisian,
Urdu, Hebrew, ..etc.)
ie. when there
<article id="my_article" lang="ar_JO"> or <book id="my_book" lang="ar_JO">
direction param should be set to rtl

how can I do this last step instead of passing --stringparam direction
rtl to xsltproc



From casimiro.barreto at gmail.com  Thu Nov 27 22:44:24 2008
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Thu, 27 Nov 2008 20:44:24 -0200
Subject: ccedilla & Ccedilla migrated to c' and C' after upgrading to Fedora
 Rel 10
Message-ID: <492F22C8.4090901@gmail.com>

Hello,

Today I migrated one of my computers to Fedora 10. Everything was smooth
and I didn't have problems except that now I lost ccedilla and Ccedilla.

Configurations are:

LANG=pt_BR.UTF-8
LC_CTYPE=pt_BR.UTF-8
Keyboard: PC101 US
Layout: US-INTL (dead keys)

Original ccedilla: ' c
Original Ccedilla: 'C

What's the best way (one that won't be lost when I update the system) to
correct this problem?

Best regards,

Casimiro

-------------- 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/20081127/d3ae7570/attachment.sig>

From Christian.Iseli at unil.ch  Thu Nov 27 23:37:05 2008
From: Christian.Iseli at unil.ch (Christian Iseli)
Date: Fri, 28 Nov 2008 00:37:05 +0100
Subject: Fedora 10 and YUM
In-Reply-To: <bfdeacfa0811261511x7f3d4356v977c2ec138a8636d@mail.gmail.com>
References: <bfdeacfa0811261511x7f3d4356v977c2ec138a8636d@mail.gmail.com>
Message-ID: <20081128003705.230cc4ff@ludwig-alpha.unil.ch>

On Wed, 26 Nov 2008 18:11:50 -0500, Mark Bidewell wrote:
> Downloading Packages:
> http://linuxdownload.adobe.com/linux/i386/flash-plugin-10.0.12.36-release.i386.rpm:
> [Errno 4] IOError: <urlopen error (-2, 'Name or service not known')>
> Trying other mirror.
> 
> 
> Error Downloading Packages:
>   flash-plugin-10.0.12.36-release.i386: failure:
> flash-plugin-10.0.12.36-release.i386.rpm from adobe-linux-i386:
> [Errno 256] No more mirrors to try.
> 
> pasting:
> http://linuxdownload.adobe.com/linux/i386/flash-plugin-10.0.12.36-release.i386.rpminto
> firefox downloads the file without issue.
> 
> Is this a known issue with YUM?

FWIW I have a similar issue which seems to be due to some sort of DNS
lookup problem.  In my case I'd get the 'Name or service not known' for
download1.rpmfusion.org.

My /etc/nsswitch.conf file says to use files and dns

The /etc/resolv.conf is setup properly

I tried disabling ipv6 completely but the symptoms stay the same

ping and firefox seem to resolve the addresses correctly, but wget and
ssh do not

The failures occur for only some sites (like linuxdownload.adobe.com
and download1.rpmfusion.org) but do not occur with others
(like download.fedoraproject.org iirc).  The failures consistently
occur for the same sites
 
Putting the IP addresses in /etc/hosts "works around" the problem

No idea what's going on...

Cheers,
					Christian



From Christian.Iseli at unil.ch  Thu Nov 27 23:40:12 2008
From: Christian.Iseli at unil.ch (Christian Iseli)
Date: Fri, 28 Nov 2008 00:40:12 +0100
Subject: Fedora 10 and YUM
In-Reply-To: <492DD952.8090108@redhat.com>
References: <bfdeacfa0811261511x7f3d4356v977c2ec138a8636d@mail.gmail.com>
	<492DD952.8090108@redhat.com>
Message-ID: <20081128004012.5067f7cd@ludwig-alpha.unil.ch>

On Wed, 26 Nov 2008 18:18:42 -0500, Casey Dahlin wrote:
> > pasting:  
> > http://linuxdownload.adobe.com/linux/i386/flash-plugin-10.0.12.36-release.i386.rpm 
> > into firefox downloads the file without issue.
> >
> > Is this a known issue with YUM?
> >
> > Mark Bidewell  
> You have the adobe flash repo installed, and its down, so yum is
> failing to connect to it. Try with --disablerepo=adobe until their
> systems get sorted.

No, reread what the OP said: "pasting: <url> into firefox downloads the
file without issue".

This is not a "site is down" issue...



From gbuday at gmail.com  Fri Nov 28 00:05:39 2008
From: gbuday at gmail.com (Gergely Buday)
Date: Fri, 28 Nov 2008 01:05:39 +0100
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <1227808982.4755.276.camel@localhost.localdomain>
References: <492E05E7.2080708@cchtml.com> <1227761096.31656.50.camel@beta>
	<200811262136.40430.konrad@tylerc.org> <492E4109.4000909@cchtml.com>
	<1227808982.4755.276.camel@localhost.localdomain>
Message-ID: <90d975d30811271605g5d5ae5ey5d13bdb46fac8eb@mail.gmail.com>

Callum Lerwick wrote:

> Anything but HTML is insane in this day and age.

and

> Hell, carrying around documentation is one of the major disk eaters in a
> Fedora install.
>
> $ du -sh /usr/share/doc/
> 377M    /usr/share/doc/

I guess not the man pages eat that disk space. Their hunger for
storage is quite minimal. That documentation should be html with
images and pdf/ps.

- Gergely



From opensource at till.name  Fri Nov 28 00:21:32 2008
From: opensource at till.name (Till Maas)
Date: Fri, 28 Nov 2008 01:21:32 +0100
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <90d975d30811271605g5d5ae5ey5d13bdb46fac8eb@mail.gmail.com>
References: <492E05E7.2080708@cchtml.com>
	<1227808982.4755.276.camel@localhost.localdomain>
	<90d975d30811271605g5d5ae5ey5d13bdb46fac8eb@mail.gmail.com>
Message-ID: <200811280121.38781.opensource@till.name>

On Fri November 28 2008, Gergely Buday wrote:
> Callum Lerwick wrote:
> > Anything but HTML is insane in this day and age.
>
> and
>
> > Hell, carrying around documentation is one of the major disk eaters in a
> > Fedora install.
> >
> > $ du -sh /usr/share/doc/
> > 377M    /usr/share/doc/
>
> I guess not the man pages eat that disk space. Their hunger for
> storage is quite minimal. That documentation should be html with
> images and pdf/ps.

And I know it, because manpages live in /usr/share/man:
$ du -hs /usr/share/man
59M     /usr/share/man
$ du -hs /usr/share/doc
604M    /usr/share/doc

Manpages have the big advantage of beeing gziped.

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/20081128/72988634/attachment.sig>

From alsadi at gmail.com  Fri Nov 28 00:27:18 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Fri, 28 Nov 2008 02:27:18 +0200
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <200811280121.38781.opensource@till.name>
References: <492E05E7.2080708@cchtml.com>
	<1227808982.4755.276.camel@localhost.localdomain>
	<90d975d30811271605g5d5ae5ey5d13bdb46fac8eb@mail.gmail.com>
	<200811280121.38781.opensource@till.name>
Message-ID: <385866f0811271627i4959b17cq2c58ce1a15c482e3@mail.gmail.com>

if you are going to consider docbook or a multiformat front end like
yelp please consider this

https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02069.html



From kwhiskerz at gmail.com  Fri Nov 28 00:57:45 2008
From: kwhiskerz at gmail.com (Petrus de Calguarium)
Date: Thu, 27 Nov 2008 17:57:45 -0700
Subject: ccedilla & Ccedilla migrated to c' and C' after upgrading to
	Fedora Rel 10
References: <492F22C8.4090901@gmail.com>
Message-ID: <ggnfmb$roj$1@ger.gmane.org>

Casimiro de Almeida Barreto wrote:
> Configurations are:
> 
> LANG=pt_BR.UTF-8
> LC_CTYPE=pt_BR.UTF-8
> Keyboard: PC101 US
> Layout: US-INTL (dead keys)
> 
> Original ccedilla: ' c
> Original Ccedilla: 'C
> 
My lang is en_US.UTF-8 and the keyboardtype is simply pc (as shown in /etc/sysconfig/keyboard).

In kde's system configurations, define the keyboard as evdev-managed keyboard (this is necessary to get it to work, as there is no longer an /etc/X11/xorg.conf), with us international layout (us-acentos -- in your case, perhaps some kind of Brazillian Portuguese setting, I guess). All I need do is type right alt (alt-gr) followed by comma for ccedilla and shift right alt (alt-gr) followed by comma for Ccedilla.

If this doesn't work, you could try, in the xkb options, to define the right win key to be compose (the menu key is used by kde). With this setup, just type the , (comma), then either a c or C to make ccedilla and Ccedilla respectively.

These are 2 ways to do it. I don't know how your Portuguese keyboard will respond. This is all I know.

> What's the best way (one that won't be lost when I update the system) to
> correct this problem?
> 
I don't have a clue what you mean by this.



From skvidal at fedoraproject.org  Fri Nov 28 05:42:28 2008
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 28 Nov 2008 00:42:28 -0500 (EST)
Subject: Fedora 10 and YUM
In-Reply-To: <20081128003705.230cc4ff@ludwig-alpha.unil.ch>
References: <bfdeacfa0811261511x7f3d4356v977c2ec138a8636d@mail.gmail.com>
	<20081128003705.230cc4ff@ludwig-alpha.unil.ch>
Message-ID: <alpine.LFD.2.00.0811280041300.27923@localhost.localdomain>


On Fri, 28 Nov 2008, Christian Iseli wrote:

>
> My /etc/nsswitch.conf file says to use files and dns
>
> The /etc/resolv.conf is setup properly
>
> I tried disabling ipv6 completely but the symptoms stay the same
>
> ping and firefox seem to resolve the addresses correctly, but wget and
> ssh do not
>
> The failures occur for only some sites (like linuxdownload.adobe.com
> and download1.rpmfusion.org) but do not occur with others
> (like download.fedoraproject.org iirc).  The failures consistently
> occur for the same sites
>
> Putting the IP addresses in /etc/hosts "works around" the problem
>
> No idea what's going on...
>

1. Do you have any proxies setup?
2. What are the nameserver entries in /etc/resolv.conf?

-sv



From fedora at leemhuis.info  Fri Nov 28 05:49:55 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Fri, 28 Nov 2008 06:49:55 +0100
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: <492F8683.9090603@leemhuis.info>

On 27.11.2008 16:33, Matthew Garrett wrote:
> [...] 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.
> [...]
> Any thoughts?

Is there a "disktop" we could use to fine those app that generating 
dirty pages without need? E.g. something as easy to use as powertop, 
just for disks? If not I'd tend to say it might make sense to create 
one, as finding and reporting the culprits that spin up the disks might 
help this whole effort a lot.

CU
knurd



From mclasen at redhat.com  Fri Nov 28 05:54:42 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 28 Nov 2008 00:54:42 -0500
Subject: RFC: Changing default filesystem parameters for power
 management reasons
In-Reply-To: <492F8683.9090603@leemhuis.info>
References: <20081127153327.GA21300@srcf.ucam.org>
	<492F8683.9090603@leemhuis.info>
Message-ID: <1227851682.3285.10.camel@localhost.localdomain>

On Fri, 2008-11-28 at 06:49 +0100, Thorsten Leemhuis wrote:
> On 27.11.2008 16:33, Matthew Garrett wrote:
> > [...] 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.
> > [...]
> > Any thoughts?
> 
> Is there a "disktop" we could use to fine those app that generating 
> dirty pages without need? E.g. something as easy to use as powertop, 
> just for disks? If not I'd tend to say it might make sense to create 
> one, as finding and reporting the culprits that spin up the disks might 
> help this whole effort a lot.

There is something called iotop.



From fedora at leemhuis.info  Fri Nov 28 06:01:37 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Fri, 28 Nov 2008 07:01:37 +0100
Subject: RFC: Changing default filesystem parameters for power management
 reasons
In-Reply-To: <1227851682.3285.10.camel@localhost.localdomain>
References: <20081127153327.GA21300@srcf.ucam.org>	<492F8683.9090603@leemhuis.info>
	<1227851682.3285.10.camel@localhost.localdomain>
Message-ID: <492F8941.4070000@leemhuis.info>

On 28.11.2008 06:54, Matthias Clasen wrote:
> On Fri, 2008-11-28 at 06:49 +0100, Thorsten Leemhuis wrote:
>> On 27.11.2008 16:33, Matthew Garrett wrote:
>>> [...] 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.
>>> [...]
>>> Any thoughts?
>> Is there a "disktop" we could use to fine those app that generating 
>> dirty pages without need? E.g. something as easy to use as powertop, 
>> just for disks? If not I'd tend to say it might make sense to create 
>> one, as finding and reporting the culprits that spin up the disks might 
>> help this whole effort a lot.
> There is something called iotop.

I wouldn't call iotop as easy to use at powertop. And the latter afaics 
was such a success mainly because it was so easy to use.

CU
knurd



From pekkas at netcore.fi  Fri Nov 28 06:15:36 2008
From: pekkas at netcore.fi (Pekka Savola)
Date: Fri, 28 Nov 2008 08:15:36 +0200 (EET)
Subject: yum upgrade from F-9 to F-10
In-Reply-To: <20081127194545.f4b0c1d5.mschwendt@gmail.com>
References: <5256d0b0811011137ye3910fco1a0726c96c3a4c65@mail.gmail.com>
	<alpine.LFD.2.00.0811012257430.30198@vega2.dur.ac.uk>
	<alpine.LRH.2.00.0811270851270.20197@netcore.fi>
	<20081127194545.f4b0c1d5.mschwendt@gmail.com>
Message-ID: <alpine.LRH.2.00.0811280812521.12213@netcore.fi>

On Thu, 27 Nov 2008, Michael Schwendt wrote:
>> In F-9 -> F-10 upgrade, I got the following error, which I worked
>> around by removing pidgin.  Could someone add that to YumUpgradeFaq
>> under F-10 specifics?
>>
>> pidgin-2.5.2-2.fc9.i386 from installed has depsolving problems
>>    --> Missing Dependency: libedataserver-1.2.so.9 is needed by package pidgin-2.5.2-2.fc9.i386 (installed)
>> Error: Missing Dependency: libedataserver-1.2.so.9 is needed by package pidgin-2.5.2-2.fc9.i386 (installed)
>>
>
> It's a typical upgrade path issue. F-10 comes with 2.5.2-1.fc10 which is
> seen as "older than" 2.5.2-2.fc9 because of the higher "2" release in the F-9 pkg.
> You would need the newer piding from updates-testing to resolve this.

Yes, I realized this later.  This always seems to come up at upgrade 
-- if you previously used updates-testing, its yum repo config gets 
replaced, and you have to remember to re-enable it.

This "remember to re-enable updates-testing after installing new 
fedora-release packages" is something that should also be mentioned in 
the FAQ.

Or even better, we should figure out how to preserve the previous 
configuration in this respect.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From Christian.Iseli at unil.ch  Fri Nov 28 08:14:50 2008
From: Christian.Iseli at unil.ch (Christian Iseli)
Date: Fri, 28 Nov 2008 09:14:50 +0100
Subject: Fedora 10 and YUM
In-Reply-To: <alpine.LFD.2.00.0811280041300.27923@localhost.localdomain>
References: <bfdeacfa0811261511x7f3d4356v977c2ec138a8636d@mail.gmail.com>
	<20081128003705.230cc4ff@ludwig-alpha.unil.ch>
	<alpine.LFD.2.00.0811280041300.27923@localhost.localdomain>
Message-ID: <20081128091450.01790757@ludwig-alpha.unil.ch>

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



From david at hlacik.eu  Fri Nov 28 08:16:49 2008
From: david at hlacik.eu (=?ISO-8859-2?Q?David_Hl=E1=E8ik?=)
Date: Fri, 28 Nov 2008 09:16:49 +0100
Subject: Fwd: problem with suspend - F10
In-Reply-To: <cba415ca0811280011n2c436e32m650b26c0b22e2878@mail.gmail.com>
References: <cba415ca0811280011n2c436e32m650b26c0b22e2878@mail.gmail.com>
Message-ID: <cba415ca0811280016i222fa23dofc310471c6c1cd65@mail.gmail.com>

Kernel failure message 1:
BUG: unable to handle kernel paging request at ff4cefea
IP: [<c06aaf92>] iret_exc+0x6aa/0x97e
*pde = 0000f067 *pte = 55520720
Oops: 0002 [#8] SMP
Modules linked in: ip6table_filter ip6_tables aes_i586 aes_generic
nls_utf8 fuse rfcomm bridge stp bnep sco l2cap sunrpc ip6t_REJECT
nf_conntrack_ipv6 ipv6 cpufreq_ondemand acpi_cpufreq dm_multipath
uinput snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event
snd_seq snd_seq_device arc4 ecb snd_pcm_oss crypto_blkcipher
snd_mixer_oss snd_pcm iwlagn uvcvideo sdhci_pci iwlcore sdhci
firewire_ohci pcspkr compat_ioctl32 firewire_core mmc_core videodev
snd_timer ricoh_mmc btusb snd_page_alloc crc_itu_t serio_raw joydev
snd_hwdep video v4l1_compat rfkill bluetooth snd mac80211 iTCO_wdt
atl1 iTCO_vendor_support output mii asus_laptop soundcore cfg80211
[last unloaded: ip6_tables]

Pid: 7817, comm: ntpd Tainted: G      D   (2.6.27.5-117.fc10.i686 #1)
EIP: 0060:[<c06aaf92>] EFLAGS: 00010246 CPU: 1
EIP is at iret_exc+0x6aa/0x97e
EAX: 00000000 EBX: 00000012 ECX: 00000012 EDX: 00000003
ESI: f336e000 EDI: ff4cefea EBP: f3a92f30 ESP: f3a92f1c
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process ntpd (pid: 7817, ti=f3a92000 task=f78e0cd0 task.ti=f3a92000)
Stack: 0000000c 00000012 00000fea 00000012 bfffffea f3a92f68 c0493f04 f31d2700
       00000000 c1aaa5c0 ff4ce000 bffff000 f336e000 00000012 c1aaa5c0 f31d27b4
       f3a92000 c0000000 086184ec f3a92f78 c0493f6d 00000080 f31d2700 f3a92f9c
Call Trace:
 [<c0493f04>] ? copy_strings+0x113/0x160
 [<c0493f6d>] ? copy_strings_kernel+0x1c/0x2b
 [<c0495057>] ? do_execve+0x12c/0x215
 [<c04023a3>] ? sys_execve+0x29/0x50
 [<c0403c76>] ? syscall_call+0x7/0xb
 [<c06a007b>] ? init_intel_cacheinfo+0x0/0x421
 =======================
Code: ff 01 c1 e9 e9 2a e7 ff 8d 0c 88 e9 e1 2a e7 ff 8d 0c 88 51 50
31 c0 f3 aa 58 59 e9 b4 2b e7 ff 01 c1 eb 03 8d 0c 88 51 50 31 c0 <f3>
aa 58 59 e9 e1 2b e7 ff 8d 0c 88 e9 ba 2c e7 ff 01 c1 e9 de
EIP: [<c06aaf92>] iret_exc+0x6aa/0x97e SS:ESP 0068:f3a92f1c
---[ end trace 586b319e7572c8a4 ]---


Kernel failure message 2:
BUG: unable to handle kernel paging request at ff4a8fe7
IP: [<c06aaf92>] iret_exc+0x6aa/0x97e
*pde = 0000f067 *pte = 00000720
Oops: 0002 [#7] SMP
Modules linked in: ip6table_filter ip6_tables aes_i586 aes_generic
nls_utf8 fuse rfcomm bridge stp bnep sco l2cap sunrpc ip6t_REJECT
nf_conntrack_ipv6 ipv6 cpufreq_ondemand acpi_cpufreq dm_multipath
uinput snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event
snd_seq snd_seq_device arc4 ecb snd_pcm_oss crypto_blkcipher
snd_mixer_oss snd_pcm iwlagn uvcvideo sdhci_pci iwlcore sdhci
firewire_ohci pcspkr compat_ioctl32 firewire_core mmc_core videodev
snd_timer ricoh_mmc btusb snd_page_alloc crc_itu_t serio_raw joydev
snd_hwdep video v4l1_compat rfkill bluetooth snd mac80211 iTCO_wdt
atl1 iTCO_vendor_support output mii asus_laptop soundcore cfg80211
[last unloaded: ip6_tables]

Pid: 7794, comm: pm-powersave Tainted: G      D   (2.6.27.5-117.fc10.i686 #1)
EIP: 0060:[<c06aaf92>] EFLAGS: 00010246 CPU: 1
EIP is at iret_exc+0x6aa/0x97e
EAX: 00000000 EBX: 00000015 ECX: 00000015 EDX: 00000003
ESI: f4958000 EDI: ff4a8fe7 EBP: f3a79f30 ESP: f3a79f1c
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process pm-powersave (pid: 7794, ti=f3a79000 task=f7876680 task.ti=f3a79000)
Stack: 00000014 00000015 00000fe7 00000015 bfffffe7 f3a79f68 c0493f04 f33c0e00
       00000000 c18dc680 ff4a8000 bffff000 f4958000 00000015 c18dc680 f33c0eb4
       f3a79000 c0000000 088cd0ec f3a79f78 c0493f6d 00000080 f33c0e00 f3a79f9c
Call Trace:
 [<c0493f04>] ? copy_strings+0x113/0x160
 [<c0493f6d>] ? copy_strings_kernel+0x1c/0x2b
 [<c0495057>] ? do_execve+0x12c/0x215
 [<c04023a3>] ? sys_execve+0x29/0x50
 [<c0403c76>] ? syscall_call+0x7/0xb
 =======================
Code: ff 01 c1 e9 e9 2a e7 ff 8d 0c 88 e9 e1 2a e7 ff 8d 0c 88 51 50
31 c0 f3 aa 58 59 e9 b4 2b e7 ff 01 c1 eb 03 8d 0c 88 51 50 31 c0 <f3>
aa 58 59 e9 e1 2b e7 ff 8d 0c 88 e9 ba 2c e7 ff 01 c1 e9 de
EIP: [<c06aaf92>] iret_exc+0x6aa/0x97e SS:ESP 0068:f3a79f1c
---[ end trace 586b319e7572c8a4 ]---





---------- Forwarded message ----------
From: David Hl??ik <david at hlacik.eu>
Date: Fri, Nov 28, 2008 at 9:11 AM
Subject: problem with suspend - F10
To: Fedora <fedora-list at redhat.com>


Hello guys,

suspend worked just well on my Asus F3Sr laptop with F9.
Current status with F10 is, that it is working only once. On the
second time, laptop will freeze with black screen turned on. SO i have
just a 1 try to suspend, then i have to restart.
I have SELinux disabled.


[boss at david Download]$ uname -r
2.6.27.5-117.fc10.i686

00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory
Controller Hub (rev 03)
00:01.0 PCI bridge: Intel Corporation Mobile PM965/GM965/GL960 PCI
Express Root Port (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB
UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB
UHCI Controller #5 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2
EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio
Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express
Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express
Port 2 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express
Port 3 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express
Port 4 (rev 03)
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express
Port 5 (rev 03)
00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express
Port 6 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB
UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB
UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB
UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2
EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface
Controller (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E)
IDE Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM
(ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)
01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 2400
02:00.0 Ethernet controller: Attansic Technology Corp. L1 Gigabit
Ethernet Adapter (rev b0)
03:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or
AGN Network Connection (rev 61)
04:00.0 SATA controller: JMicron Technologies, Inc. JMicron
20360/20363 AHCI Controller (rev 02)
08:00.0 Memory controller: Intel Corporation Turbo Memory Controller (rev 01)
09:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 05)
09:01.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro
Host Adapter (rev 22)
09:01.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 12)
09:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host
Adapter (rev 12)
09:01.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev ff)

Can you please help me?

Thanks in advance!

PS : Kernel is responsible for proper suspend  / hibernate ?

David



From fedora at camperquake.de  Fri Nov 28 09:00:48 2008
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Fri, 28 Nov 2008 10:00:48 +0100
Subject: RFC: Changing default filesystem parameters for power
 management reasons
In-Reply-To: <492F8941.4070000@leemhuis.info>
References: <20081127153327.GA21300@srcf.ucam.org>
	<492F8683.9090603@leemhuis.info>
	<1227851682.3285.10.camel@localhost.localdomain>
	<492F8941.4070000@leemhuis.info>
Message-ID: <20081128100048.5c2e2e7b@dhcp03.addix.net>

Hi.

On Fri, 28 Nov 2008 07:01:37 +0100, Thorsten Leemhuis wrote:

> I wouldn't call iotop as easy to use at powertop. And the latter
> afaics was such a success mainly because it was so easy to use.

And because it had those nice 'press X to turn off Y' hints.



From opensource at till.name  Fri Nov 28 10:14:29 2008
From: opensource at till.name (Till Maas)
Date: Fri, 28 Nov 2008 11:14:29 +0100
Subject: automatically include files in %doc only if they are not empty
In-Reply-To: <20081127155803.885118a2.mschwendt@gmail.com>
References: <200811271255.12657.opensource@till.name>
	<20081127155803.885118a2.mschwendt@gmail.com>
Message-ID: <200811281115.19506.opensource@till.name>

On Thu November 27 2008, Michael Schwendt wrote:
> On Thu, 27 Nov 2008 12:55:07 +0100, Till Maas wrote:

> > on a package I recently packaged for Fedora, there is an empty TODO file
> > included. Is there an easy way to mark this file in %files to be included
> > only if it is not empty? This would make it easier to not forget to add
> > the file in case it will be filed with some contents in a future release.
>
> %prep and %check : easy enough to add a bash conditional expression
> (e.g. which exits with failure if the file exists and has a size greater
> than zero -- or the opposite, a zero size, for files you want to exclude).

I would like to avoid breaking the build in this case. I hoped there was some 
macro, e.g. named exclude_empty, that would allow to exclude files only if 
they are empty. This is what I came up with:

%define exclude_empty() %(test -s %1 && echo %1)

It should then be used somehow like this:
%files
%doc %exclude_empty TODO

But it seems to always exclude the file.

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/20081128/724b9370/attachment.sig>

From mschwendt at gmail.com  Fri Nov 28 10:20:55 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 28 Nov 2008 11:20:55 +0100
Subject: autofs - patches in %doc?
Message-ID: <20081128112055.7692379c.mschwendt@gmail.com>

$ 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?



From rawhide at fedoraproject.org  Fri Nov 28 11:54:50 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri, 28 Nov 2008 11:54:50 +0000 (UTC)
Subject: rawhide report: 20081128 changes
Message-ID: <20081128115450.991D61F8252@releng2.fedora.phx.redhat.com>

Compose started at Fri Nov 28 06:01:10 UTC 2008

New package ghc-zlib
        Haskell compression and decompression in the zlib and gzip formats
New package hunspell-az
        Azerbaijani hunspell dictionaries
New package hunspell-csb
        Kashubian hunspell dictionaries
New package hunspell-fa
        Farsi hunspell dictionaries
New package hunspell-fj
        Fijian hunspell dictionaries
New package hunspell-gv
        Manx hunspell dictionaries
New package hunspell-hil
        Hiligaynon hunspell dictionaries
New package hunspell-ia
        Interlingua hunspell dictionaries
New package hunspell-la
        Latin hunspell dictionaries
New package hunspell-mn
        Mongolian hunspell dictionaries
New package hunspell-mt
        Maltese hunspell dictionaries
New package hunspell-ny
        Chichewa hunspell dictionaries
New package hunspell-sc
        Sardinian hunspell dictionaries
New package hunspell-sw
        Swahili hunspell dictionaries
New package protobuf
        Protocol Buffers - Google's data interchange format
Updated Packages:

authconfig-5.4.5-1.fc11
-----------------------
* Thu Nov 27 17:00:00 2008 Tomas Mraz <tmraz at redhat.com> - 5.4.5-1
- improved cacertdir_rehash to be more robust
- add fingerprint reader support (original patch by Bastien Nocera) (#469418)
- remove pam_smb support from GUI and TUI
- fix nscd pid file path (#471642)


banshee-1.4.1-1.fc11
--------------------
* Thu Nov 27 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 1.4.1-1
- Update to 1.4.1


dcraw-8.89-1.fc11
-----------------
* Thu Nov 27 17:00:00 2008 Nils Philippsen <nphilipp at redhat.com> - 8.89-1
- version 8.89
- remove obsolete gps patch


evolution-data-server-2.25.1-2.fc11
-----------------------------------
* Thu Nov 27 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.25.1-2.fc11
- Obsolete the evolution-webcal package (RH bug #468855).


firstaidkit-0.2.2-1.fc11
------------------------
* Thu Nov 20 17:00:00 2008 Joel Granados <jgranado at redhat.com> 0.2.2-1
- Update to new version.

* Thu Aug 28 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> 0.2.1-2
- Include unowned directories.


gyachi-1.1.59-6.fc11
--------------------
* Fri Nov 28 17:00:00 2008 Gregory D Hosler <ghosler at users.sourceforge.net> - 1.1.59.6
- Added Obsoletes for previous versions of modules no longer being built.


hping3-0.0.20051105-12.fc11
---------------------------
* Thu Nov 27 17:00:00 2008 Paul Wouters <paul at xelerance.com> - 0.0.20051105-12
- Fix for "sh" arch, see https://bugzilla.redhat.com/show_bug.cgi?id=471709

* Fri Nov  7 17:00:00 2008 Paul Wouters <paul at xelerance.com> - 0.0.20051105-11
- Fix for man page, see https://bugzilla.redhat.com/show_bug.cgi?id=456675


hunspell-ca-0.20081027-1.fc11
-----------------------------
* Tue Oct 28 18:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20081027-1
- latest version


hunspell-no-2.0.10-2.fc11
-------------------------
* Thu Nov 27 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 2.0.10-2
- silly require


hunspell-tet-0.20050108-2.fc11
------------------------------
* Thu Nov 27 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20050108-2
- East Timor also


jd-2.1.0-0.1.svn2515_trunk.fc11
-------------------------------
* Fri Nov 28 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2515


kdebase-4.1.80-4.fc11
---------------------
* Thu Nov 27 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 6:4.1.80-4
- BR plasma-devel instead of kdebase-workspace-devel

* Sun Nov 23 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 6:4.1.80-3
- rebase nsplugins-path patch

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

* Wed Nov 19 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 6:4.1.80-1
- 4.1.80
- patch100 was backported from 4.2 (4.1.6x), removed from patch list
- ported 4.1.2 konsole patches
- drop the second konsole patch (upstreamed)
- using make install/fast
- BR cmake >= 2.6.2

* Wed Nov 12 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.3-2
- readd kde#156636 patch (Konsole keyboard actions backport)

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


kdebase-runtime-4.1.80-4.fc11
-----------------------------
* Thu Nov 27 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.80-4
- BR strigi-devel >= 0.5.11.1 because 0.5.11 is broken

* Thu Nov 20 17:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.80-3
- readd still relevant part of the Phonon PulseAudio patch (for the KCM)

* Wed Nov 19 17:00:00 2008 Than Ngo <than at redhat.com> 4.1.80-2
- drop kdebase-runtime-4.0.72-pulseaudio.patch/icons, it's part of phonon

* Wed Nov 19 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 4.1.80-1
- 4.1.80
- Drop upstreamed patch kdebase-runtime-4.1.2-kioexec.patch
- BR cmake >= 2.6.2
- Use 'make install/fast'
- Drop subpkg phonon-backend-xine and related file entries: this has to be
  part of phonon now that it moved there
- Drop xine-lib-devel BR
- Add libkwalletbackend to files list
- Drop _default_patch_fuzz 2

* 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


kpackagekit-0.3.1-6.fc11
------------------------
* Wed Nov 26 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 0.3.1-6
- respin (PackageKit)
- spec cleanup

* Sat Nov  1 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 0.3.1-5
- use PackageKit's FindQPackageKit.cmake


libHX-1.25-2.fc11
-----------------
* Thu Nov 27 17:00:00 2008 Till Maas <opensource at till.name> - 1.25-2
- Move libHX.so.* to /%{_lib} because of /sbin/mount.crypt from pam_mount


mythes-sk-0.20081121-1.fc11
---------------------------
* Thu Nov 27 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20081121-1
- latest version


perl-Log-Dispatch-2.22-1.fc11
-----------------------------
* Wed Nov 26 17:00:00 2008 Ralf Cors??pius <corsepiu at fedoraproject.org> - 2.22-1
- Upstream update.


planner-0.14.3-7.fc11
---------------------
* Thu Nov 27 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 0.14.3-7
- rebuild for e-d-s


python-pygments-1.0-1.fc11
--------------------------
* Thu Nov 27 17:00:00 2008 Steve 'Ashcrow' Milner <me at stevemilner.org> - 1.0-1
- Updated for upstream 1.0.


python-virtualenv-1.3.1-1.fc11
------------------------------
* Fri Nov 28 17:00:00 2008 Steve 'Ashcrow' Milner <me at stevemilner.org> - 1.3.1-1
- Updated for upstream release


ristretto-0.0.21-1.fc11
-----------------------
* Thu Nov 27 17:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.0.21-1
- Update to 0.0.21
- Remove marshaller fix, included upstream now


samba-3.2.5-0.23.fc11
---------------------
* Thu Nov 27 17:00:00 2008 Simo Sorce <ssorce at redhat.com> - 3.2.5-0.23
- Security Release, fixes CVE-2008-4314


setup-2.7.5-1.fc11
------------------
* Thu Nov 27 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> 2.7.5-1
- Modified upstream URL, synchronized with upstream git


shed-1.14-1.fc11
----------------
* Thu Nov 27 17:00:00 2008 Adam Miller <maxamillion [AT] gmail.com> - 1.14-1
- New upstream release.


strigi-0.5.11.1-1.fc11
----------------------
* Thu Nov 27 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 0.5.11.1-1
- drop _default_patch_fuzz
- rebase strigi-multilib patch
- No official 0.5.11.1 tarballs were released but we need 0.5.11.1, apply a
  diff between 0.5.11 and 0.5.11.1 svn tags


sugar-0.83.3-1.fc11
-------------------
* Fri Nov 28 17:00:00 2008 Marco Pesenti Gritti <mpg at redhat.com> - 0.83.3-1
- Update to 0.83.3


sugar-toolkit-0.83.2-1.fc11
---------------------------
* Fri Nov 28 17:00:00 2008 Marco Pesenti Gritti <mpg at redhat.com> - 0.83.2-1
- Update to 0.83.2


transmission-1.40-1.fc11
------------------------
* Fri Nov 21 17:00:00 2008 Denis Leroy <denis at poolshark.org> - 1.40-1
- Update to upstream 1.40
- Ported patches to 1.40


xfce4-datetime-plugin-0.6.1-1.fc11
----------------------------------
* Thu Nov 27 17:00:00 2008 Christoph Wickert <fedora christoph-wickert de> - 0.6.1-1
- Update to 0.6.1
- Include NEWS and THANKS docs


xfce4-dict-0.5.1-1.fc11
-----------------------
* Thu Nov 27 17:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.5.1-1
- Update to 0.5.1
- Update gtk-update-icon-cache scriptlets

* Tue Nov 11 17:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.5.0-1
- Update to 0.5.0
- Only show in Xfce menu


xfce4-fsguard-plugin-0.4.2-1.fc11
---------------------------------
* Thu Nov 27 17:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.4.2-1
- Update to 0.4.2
- BR intltool
- Update gtk-update-icon-cache scriptlets


xfce4-notes-plugin-1.6.3-1.fc11
-------------------------------
* Thu Nov 27 17:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 1.6.3-1
- Update to 1.6.3
- BR intltool
- Update gtk-update-icon-cache scriptlets


xfce4-timer-plugin-0.6.1-1.fc11
-------------------------------
* Thu Nov 27 17:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.6.1-1
- Update to 0.6.1
- BR intltool


xfce4-verve-plugin-0.3.6-1.fc11
-------------------------------
* Thu Nov 27 17:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.3.6-1
- Update to 0.3.6
- Remove "verve-plugin" provides because package name now matches upstream


xfce4-xkb-plugin-0.5.2-1.fc11
-----------------------------
* Thu Nov 27 17:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.5.2-1
- Update to 0.5.2


xscreensaver-5.07-4.fc11
------------------------
* Fri Nov 28 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1:5.07-4
- Fix fireworkx segfault (bug 473355)


yaboot-1.3.14-8.fc11
--------------------
* Thu Nov 27 17:00:00 2008 Roman Rakus <rrakus at redhat.com> - 1.3.14-8
- Bumped release, so preupgrade is now silent and go through


Summary:
Added Packages: 15
Removed Packages: 0
Modified Packages: 37
Broken deps for i386
----------------------------------------------------------
	autodir-0.99.9-5.fc9.i386 requires libltdl.so.3
	avant-window-navigator-0.2.6-9.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	bigboard-0.6.4-2.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(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(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	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(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	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(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(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	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
	db4o-6.1-4.fc9.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	deskbar-applet-2.24.0-2.fc10.i386 requires libgnome-desktop-2.so.7
	desktop-data-model-1.2.5-1.fc10.i386 requires libgnome-desktop-2.so.7
	epdfview-0.1.6-4.fc10.i386 requires libpoppler-glib.so.3
	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-zimbra-0.1.1-3.fc10.i386 requires libcamel-1.2.so.14
	evolution-zimbra-0.1.1-3.fc10.i386 requires libcamel-provider-1.2.so.14
	foobillard-3.0a-8.fc10.i386 requires dejavu-fonts
	freeradius-2.1.1-2.fc10.i386 requires libltdl.so.3
	galeon-2.0.7-3.fc10.i386 requires libgnome-desktop-2.so.7
	gambas2-devel-2.9.0-1.fc10.i386 requires libltdl.so.3
	gambas2-gb-pdf-2.9.0-1.fc10.i386 requires libpoppler.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
	gnome-compiz-manager-0.10.4-4.fc10.i386 requires libgnome-desktop-2.so.7
	gnome-launch-box-0.4-10.fc10.i386 requires libgnome-desktop-2.so.7
	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
	inkscape-0.46-6.fc10.i386 requires libpoppler.so.3
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	kdebindings-4.1.2-2.fc10.i386 requires libqscintilla2.so.4
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	libp11-0.2.3-3.fc10.i386 requires libltdl.so.3
	mail-notification-evolution-plugin-5.4-4.fc10.i386 requires libcamel-1.2.so.14
	mail-notification-evolution-plugin-5.4-4.fc10.i386 requires libcamel-provider-1.2.so.14
	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
	mono-cecil-flowanalysis-0.1-0.6.20080409svn100264.fc11.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	mono-tools-2.0-8.fc10.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	mysql-connector-odbc-3.51.26r1127-1.fc10.i386 requires libltdl.so.3
	nautilus-search-tool-0.2.2-4.fc10.i386 requires libgnome-desktop-2.so.7
	ocaml-SDL-0.7.2-14.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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-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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlimages-2.2.0-13.fc10.i386 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-csv-1.1.7-1.fc10.i386 requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	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(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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	ocaml-pgocaml-1.1-4.fc10.i386 requires ocaml(Unix) = 0:9a46a8db115947409e54686ada118599
	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(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	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(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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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(Unix) = 0:9a46a8db115947409e54686ada118599
	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
	padevchooser-0.9.4-0.6.svn20070925.fc10.i386 requires libgnome-desktop-2.so.7
	pdfcube-0.0.2-8.fc9.i386 requires libpoppler.so.3
	pdfcube-0.0.2-8.fc9.i386 requires libpoppler-glib.so.3
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts-experimental
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts
	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
	tellico-1.3.4-1.fc10.i386 requires libpoppler.so.3
	tracker-0.6.6-3.fc10.i386 requires libpoppler-glib.so.3
	tracker-search-tool-0.6.6-3.fc10.i386 requires libgnome-desktop-2.so.7
	wput-0.6.1-4.fc9.i386 requires libgnutls-openssl.so.13



Broken deps for x86_64
----------------------------------------------------------
	autodir-0.99.9-5.fc9.x86_64 requires libltdl.so.3()(64bit)
	avant-window-navigator-0.2.6-9.fc10.i386 requires libgnome-desktop-2.so.7
	avant-window-navigator-0.2.6-9.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	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)
	bigboard-0.6.4-2.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(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(Queue) = 0:caa3a209bfc63d23a30f573541a88fec
	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
	deskbar-applet-2.24.0-2.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	desktop-data-model-1.2.5-1.fc10.i386 requires libgnome-desktop-2.so.7
	desktop-data-model-1.2.5-1.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	epdfview-0.1.6-4.fc10.x86_64 requires libpoppler-glib.so.3()(64bit)
	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-zimbra-0.1.1-3.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	evolution-zimbra-0.1.1-3.fc10.x86_64 requires libcamel-provider-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)
	galeon-2.0.7-3.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	gambas2-devel-2.9.0-1.fc10.i386 requires libltdl.so.3
	gambas2-devel-2.9.0-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	gambas2-gb-pdf-2.9.0-1.fc10.x86_64 requires libpoppler.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)
	gnome-compiz-manager-0.10.4-4.fc10.i386 requires libgnome-desktop-2.so.7
	gnome-compiz-manager-0.10.4-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	gnome-launch-box-0.4-10.fc10.x86_64 requires libgnome-desktop-2.so.7()(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)
	inkscape-0.46-6.fc10.x86_64 requires libpoppler.so.3()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	kdebindings-4.1.2-2.fc10.i386 requires libqscintilla2.so.4
	kdebindings-4.1.2-2.fc10.x86_64 requires libqscintilla2.so.4()(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)
	libp11-0.2.3-3.fc10.i386 requires libltdl.so.3
	libp11-0.2.3-3.fc10.x86_64 requires libltdl.so.3()(64bit)
	mail-notification-evolution-plugin-5.4-4.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	mail-notification-evolution-plugin-5.4-4.fc10.x86_64 requires libcamel-provider-1.2.so.14()(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)
	mono-cecil-flowanalysis-0.1-0.6.20080409svn100264.fc11.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	mono-tools-2.0-8.fc10.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	mysql-connector-odbc-3.51.26r1127-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	nautilus-search-tool-0.2.2-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(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(Obj) = 0:5cfae708052c692ea39d23ed930fd64d
	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(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.x86_64 requires ocaml(Pango) = 0:b5403be8d9b1c0fb2807ac3675dd0323
	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(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(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(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	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(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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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(Unix) = 0:9a46a8db115947409e54686ada118599
	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)
	padevchooser-0.9.4-0.6.svn20070925.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	pdfcube-0.0.2-8.fc9.x86_64 requires libpoppler-glib.so.3()(64bit)
	pdfcube-0.0.2-8.fc9.x86_64 requires libpoppler.so.3()(64bit)
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts-experimental
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts
	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)
	tellico-1.3.4-1.fc10.x86_64 requires libpoppler.so.3()(64bit)
	tracker-0.6.6-3.fc10.i386 requires libpoppler-glib.so.3
	tracker-0.6.6-3.fc10.x86_64 requires libpoppler-glib.so.3()(64bit)
	tracker-search-tool-0.6.6-3.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	wput-0.6.1-4.fc9.x86_64 requires libgnutls-openssl.so.13()(64bit)



Broken deps for ppc
----------------------------------------------------------
	autodir-0.99.9-5.fc9.ppc requires libltdl.so.3
	avant-window-navigator-0.2.6-9.fc10.ppc requires libgnome-desktop-2.so.7
	avant-window-navigator-0.2.6-9.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	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)
	bigboard-0.6.4-2.fc10.ppc requires libgnome-desktop-2.so.7
	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(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(Marshal) = 0:b7e47558bc02738dea90d6bd22a06c7b
	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(Sort) = 0:089a51dd8ddc078e57acf2f80b7c06f6
	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(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(Nativeint) = 0:e79cdc4d3575c2ed044955cb7ef49aca
	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
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	deskbar-applet-2.24.0-2.fc10.ppc requires libgnome-desktop-2.so.7
	desktop-data-model-1.2.5-1.fc10.ppc requires libgnome-desktop-2.so.7
	desktop-data-model-1.2.5-1.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	epdfview-0.1.6-4.fc10.ppc requires libpoppler-glib.so.3
	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-zimbra-0.1.1-3.fc10.ppc requires libcamel-1.2.so.14
	evolution-zimbra-0.1.1-3.fc10.ppc requires libcamel-provider-1.2.so.14
	firstaidkit-plugin-grub-0.2.2-1.fc11.noarch requires grub
	foobillard-3.0a-8.fc10.ppc requires dejavu-fonts
	freeradius-2.1.1-2.fc10.ppc requires libltdl.so.3
	galeon-2.0.7-3.fc10.ppc requires libgnome-desktop-2.so.7
	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)
	gnome-compiz-manager-0.10.4-4.fc10.ppc requires libgnome-desktop-2.so.7
	gnome-compiz-manager-0.10.4-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	gnome-launch-box-0.4-10.fc10.ppc requires libgnome-desktop-2.so.7
	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
	inkscape-0.46-6.fc10.ppc requires libpoppler.so.3
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	kdebindings-4.1.2-2.fc10.ppc requires libqscintilla2.so.4
	kdebindings-4.1.2-2.fc10.ppc64 requires libqscintilla2.so.4()(64bit)
	libextractor-0.5.20b-2.fc10.ppc requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libp11-0.2.3-3.fc10.ppc requires libltdl.so.3
	libp11-0.2.3-3.fc10.ppc64 requires libltdl.so.3()(64bit)
	mail-notification-evolution-plugin-5.4-4.fc10.ppc requires libcamel-1.2.so.14
	mail-notification-evolution-plugin-5.4-4.fc10.ppc requires libcamel-provider-1.2.so.14
	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)
	mono-cecil-flowanalysis-0.1-0.6.20080409svn100264.fc11.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	mysql-connector-odbc-3.51.26r1127-1.fc10.ppc requires libltdl.so.3
	nautilus-search-tool-0.2.2-4.fc10.ppc requires libgnome-desktop-2.so.7
	ocaml-SDL-0.7.2-14.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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-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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlimages-2.2.0-13.fc10.ppc requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-csv-1.1.7-1.fc10.ppc requires ocaml(Array) = 0:aa8e3cd5824f9bb40b93fcd38d0c95b5
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	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(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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(Warnings) = 0:abcb1589615da86f20f475b0ed3bbabc
	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(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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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(Unix) = 0:9a46a8db115947409e54686ada118599
	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)
	padevchooser-0.9.4-0.6.svn20070925.fc10.ppc requires libgnome-desktop-2.so.7
	pdfcube-0.0.2-8.fc9.ppc requires libpoppler.so.3
	pdfcube-0.0.2-8.fc9.ppc requires libpoppler-glib.so.3
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts-experimental
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts
	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
	tellico-1.3.4-1.fc10.ppc requires libpoppler.so.3
	tracker-0.6.6-3.fc10.ppc requires libpoppler-glib.so.3
	tracker-0.6.6-3.fc10.ppc64 requires libpoppler-glib.so.3()(64bit)
	tracker-search-tool-0.6.6-3.fc10.ppc requires libgnome-desktop-2.so.7
	wput-0.6.1-4.fc9.ppc requires libgnutls-openssl.so.13



Broken deps for ppc64
----------------------------------------------------------
	autodir-0.99.9-5.fc9.ppc64 requires libltdl.so.3()(64bit)
	avant-window-navigator-0.2.6-9.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	bigboard-0.6.4-2.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
	deskbar-applet-2.24.0-2.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	desktop-data-model-1.2.5-1.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	epdfview-0.1.6-4.fc10.ppc64 requires libpoppler-glib.so.3()(64bit)
	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-zimbra-0.1.1-3.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	evolution-zimbra-0.1.1-3.fc10.ppc64 requires libcamel-provider-1.2.so.14()(64bit)
	firstaidkit-plugin-grub-0.2.2-1.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)
	galeon-2.0.7-3.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	gift-0.11.8.1-10.fc9.ppc64 requires libltdl.so.3()(64bit)
	gnome-compiz-manager-0.10.4-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	gnome-launch-box-0.4-10.fc10.ppc64 requires libgnome-desktop-2.so.7()(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)
	inkscape-0.46-6.fc10.ppc64 requires libpoppler.so.3()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	kdebindings-4.1.2-2.fc10.ppc64 requires libqscintilla2.so.4()(64bit)
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	libp11-0.2.3-3.fc10.ppc64 requires libltdl.so.3()(64bit)
	mail-notification-evolution-plugin-5.4-4.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	mail-notification-evolution-plugin-5.4-4.fc10.ppc64 requires libcamel-provider-1.2.so.14()(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)
	nautilus-search-tool-0.2.2-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(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(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	ocaml-SDL-0.7.2-14.fc10.ppc64 requires ocaml(String) = 0:2c162ab314b2f0a2cfd22d471b2e21ab
	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(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(Callback) = 0:e5ca1fb5990fac2b7b17cbb1712cffe2
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(Glib) = 0:39c579079161658673ebd1ea3a5d3ab9
	ocaml-cairo-1.2.0.cvs20080301-3.fc10.ppc64 requires ocaml(Printf) = 0:5dbbf45a03b54e6dbfcf39178d0d6341
	ocaml-camlimages-2.2.0-13.fc10.ppc64 requires ocaml(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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-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(Complex) = 0:bb333e8e4cda78107ccf27048ca40492
	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(Pervasives) = 0:8ba3d1faa24d659525c9025f41fd0c57
	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(Outcometree) = 0:6674fbd870cb2522aca4d851f3559202
	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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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(Unix) = 0:9a46a8db115947409e54686ada118599
	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(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(Unix) = 0:9a46a8db115947409e54686ada118599
	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)
	padevchooser-0.9.4-0.6.svn20070925.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	pdfcube-0.0.2-8.fc9.ppc64 requires libpoppler-glib.so.3()(64bit)
	pdfcube-0.0.2-8.fc9.ppc64 requires libpoppler.so.3()(64bit)
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts-experimental
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts
	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)
	tellico-1.3.4-1.fc10.ppc64 requires libpoppler.so.3()(64bit)
	tracker-0.6.6-3.fc10.ppc64 requires libpoppler-glib.so.3()(64bit)
	tracker-search-tool-0.6.6-3.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	wput-0.6.1-4.fc9.ppc64 requires libgnutls-openssl.so.13()(64bit)





From rjones at redhat.com  Fri Nov 28 12:09:26 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 28 Nov 2008 12:09:26 +0000
Subject: rawhide report: 20081128 changes
In-Reply-To: <20081128115450.991D61F8252@releng2.fedora.phx.redhat.com>
References: <20081128115450.991D61F8252@releng2.fedora.phx.redhat.com>
Message-ID: <20081128120926.GA12663@amd.home.annexia.org>


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

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 pknirsch at redhat.com  Fri Nov 28 12:16:36 2008
From: pknirsch at redhat.com (Phil Knirsch)
Date: Fri, 28 Nov 2008 13:16:36 +0100
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: <492FE124.3030400@redhat.com>

Matthew Garrett wrote:
> I'd like F11 to be more useful for disk power management. This involves 
> tuning various parameters in order to reduce disk access. There are some 
> tradeoffs involved, so I'd like feedback before pushing much of this.
> 

Great idea, i'm working quite a bit in that direction at them moment as 
well.

> 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.
> 

+1000. I've done a few tests here with my systems, and although the 
really bad offenders related to disk io are of course processes that do 
write access there are quite a few cases where read access happens which 
then has to update the atime and result in a write to the disc. :/

> 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.
> 

Sounds like a good idea. It's also something i've been looking at a bit. 
Take e.g. something like xchat. If you enable logging there you 
basically keep your disc active all the time as xchat itself doesn't use 
a large internal cache to write the data out every X MB or so.

> 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.
> 

Agree as well, though i'm not sure if we should make it enabled by 
default as the risk of data loss in case of a system failure is quite 
high then.

> The combination of these features should result in (on average) fewer 
> disk accesses and so (on average) should provide better performance. 
> There's a chance that some usage patterns will fall foul of this and 
> lose performance, so if we do this I'd like to do it sufficiently early 
> in the cycle that we can get real-world feedback.
> 

Sounds like a great idea and something i've been working on myself 
lately, too. I even went a bit further and thought about the idea if a 
combination of a monitoring backend and a tuning engine could provide an 
automatic adoption of the system to the current use. E.g. during daytime 
when a user works with his machine we would typically see quite a few 
reads and write all the time. Drive spindowns or other power saving 
features could during that time be reduced so that the user will have 
the best performance. During the night (in case he didn't turn of the 
machine) only very few read and even fewer write operations should 
happen, at which time the disk could then be powered down most of the 
time. And of course this can be extended to not only disk drivces but 
other tunable hardware components.

Reagards, Phil

-- 
Philipp Knirsch              | Tel.:  +49-711-96437-470
Team Lead Core Services      | Fax.:  +49-711-96437-111
Red Hat GmbH                 | Email: Phil Knirsch <pknirsch at redhat.com>
Hauptstaetterstr. 58         | Web:   http://www.redhat.com/
D-70178 Stuttgart, Germany
Motd:  You're only jealous cos the little penguins are talking to me.



From pknirsch at redhat.com  Fri Nov 28 12:20:49 2008
From: pknirsch at redhat.com (Phil Knirsch)
Date: Fri, 28 Nov 2008 13:20:49 +0100
Subject: RFC: Changing default filesystem parameters for power management
 reasons
In-Reply-To: <20081128100048.5c2e2e7b@dhcp03.addix.net>
References: <20081127153327.GA21300@srcf.ucam.org>	<492F8683.9090603@leemhuis.info>	<1227851682.3285.10.camel@localhost.localdomain>	<492F8941.4070000@leemhuis.info>
	<20081128100048.5c2e2e7b@dhcp03.addix.net>
Message-ID: <492FE221.8050802@redhat.com>

Ralf Ertzinger wrote:
> Hi.
> 
> On Fri, 28 Nov 2008 07:01:37 +0100, Thorsten Leemhuis wrote:
> 
>> I wouldn't call iotop as easy to use at powertop. And the latter
>> afaics was such a success mainly because it was so easy to use.
> 
> And because it had those nice 'press X to turn off Y' hints.
> 

I've been looking at the existing system tap scripts lately for that and 
most of them weren't aimed at that from what i could tell. I'm probably 
going to rework one of them to basically do what powertop does for disk 
io as i'm less interested in kb/sec reads and writes but more in 
read/write operations per minute per process.

Regards, Phil

-- 
Philipp Knirsch              | Tel.:  +49-711-96437-470
Team Lead Core Services      | Fax.:  +49-711-96437-111
Red Hat GmbH                 | Email: Phil Knirsch <pknirsch at redhat.com>
Hauptstaetterstr. 58         | Web:   http://www.redhat.com/
D-70178 Stuttgart, Germany
Motd:  You're only jealous cos the little penguins are talking to me.



From dwmw2 at infradead.org  Fri Nov 28 12:33:53 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 28 Nov 2008 12:33:53 +0000
Subject: RFC: Changing default filesystem parameters for power
 management reasons
In-Reply-To: <20081127164406.GB22963@srcf.ucam.org>
References: <20081127153327.GA21300@srcf.ucam.org>
	<492EC3CC.9080105@redhat.com>  <20081127164406.GB22963@srcf.ucam.org>
Message-ID: <1227875633.3636.7.camel@macbook.infradead.org>

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?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From sundaram at fedoraproject.org  Fri Nov 28 12:56:47 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 28 Nov 2008 18:26:47 +0530
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <1227808982.4755.276.camel@localhost.localdomain>
References: <492E05E7.2080708@cchtml.com>
	<1227761096.31656.50.camel@beta>	<200811262136.40430.konrad@tylerc.org>
	<492E4109.4000909@cchtml.com>
	<1227808982.4755.276.camel@localhost.localdomain>
Message-ID: <492FEA8F.10801@fedoraproject.org>

Callum Lerwick wrote:
.
> 
> What say we hack up a script to pull all documentation out of every RPM
> in a release, convert all man and info pages to HTML, and put it all up
> on docs.fedoraproject.org? Then embed a Google search on top of it. Ta
> da, a one stop shop for all documentation.

That was the idea behind Mitwi

http://code.google.com/soc/2007/fedora/appinfo.html?csaid=7F7557C310F189A8

Ria is working on it again. Let's see.

Rahul



From mjg at redhat.com  Fri Nov 28 13:18:16 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Fri, 28 Nov 2008 13:18:16 +0000
Subject: RFC: Changing default filesystem parameters for power
	management reasons
In-Reply-To: <1227875633.3636.7.camel@macbook.infradead.org>
References: <20081127153327.GA21300@srcf.ucam.org>
	<492EC3CC.9080105@redhat.com>
	<20081127164406.GB22963@srcf.ucam.org>
	<1227875633.3636.7.camel@macbook.infradead.org>
Message-ID: <20081128131816.GA4434@srcf.ucam.org>

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.

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



From sandeen at redhat.com  Fri Nov 28 13:19:19 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Fri, 28 Nov 2008 07:19:19 -0600
Subject: RFC: Changing default filesystem parameters for power management
 reasons
In-Reply-To: <1227875633.3636.7.camel@macbook.infradead.org>
References: <20081127153327.GA21300@srcf.ucam.org>	<492EC3CC.9080105@redhat.com>
	<20081127164406.GB22963@srcf.ucam.org>
	<1227875633.3636.7.camel@macbook.infradead.org>
Message-ID: <492FEFD7.4070609@redhat.com>

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?

shouldn't... but then it doesn't tell you what file was written to,
either (just blocks) because it's working lower down the stack.  It
gives you a process name though at least.

One of the things I've found fairly often is applications which re-write
the same litle log or config file over and over, with unchanged
contents.  It'd be nice if any disktop-like thing could check for that.
 But that would require knowledge of what files were being accessed.

-Eric



From mjg at redhat.com  Fri Nov 28 13:20:15 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Fri, 28 Nov 2008 13:20:15 +0000
Subject: RFC: Changing default filesystem parameters for power
	management reasons
In-Reply-To: <1227818177.2968.10.camel@c83-254-42-244.bredband.comhem.se>
References: <20081127153327.GA21300@srcf.ucam.org>
	<1227818177.2968.10.camel@c83-254-42-244.bredband.comhem.se>
Message-ID: <20081128132015.GB4434@srcf.ucam.org>

On Thu, Nov 27, 2008 at 09:36:17PM +0100, Linus Walleij wrote:

> You're mainly planning for kernel-level features for the whole line of
> use cases and not at the level of userland tools like
> gnome-power-manager that we currently rely on quite extensively to
> manage power for desktops and laptops?

I'm looking at making sure that we have sane defaults from a power 
management perspective. Once that's done we can make sure that userland 
can reconfigure stuff sensibly in response to various events, but I'm 
hoping that for the most part we can find a solution that works without 
needing that.

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



From mjg at redhat.com  Fri Nov 28 13:21:02 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Fri, 28 Nov 2008 13:21:02 +0000
Subject: RFC: Changing default filesystem parameters for power
	management reasons
In-Reply-To: <492F8683.9090603@leemhuis.info>
References: <20081127153327.GA21300@srcf.ucam.org>
	<492F8683.9090603@leemhuis.info>
Message-ID: <20081128132102.GC4434@srcf.ucam.org>

On Fri, Nov 28, 2008 at 06:49:55AM +0100, Thorsten Leemhuis wrote:

> Is there a "disktop" we could use to fine those app that generating 
> dirty pages without need? E.g. something as easy to use as powertop, 
> just for disks? If not I'd tend to say it might make sense to create 
> one, as finding and reporting the culprits that spin up the disks might 
> help this whole effort a lot.

blktrace produces the information, but I wouldn't currently call it 
"friendly".

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



From fedora at camperquake.de  Fri Nov 28 13:22:09 2008
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Fri, 28 Nov 2008 14:22:09 +0100
Subject: RFC: Changing default filesystem parameters for power
 management reasons
In-Reply-To: <492FE124.3030400@redhat.com>
References: <20081127153327.GA21300@srcf.ucam.org>
	<492FE124.3030400@redhat.com>
Message-ID: <20081128142209.758238c5@dhcp03.addix.net>

Hi.

On Fri, 28 Nov 2008 13:16:36 +0100, Phil Knirsch wrote:

> Sounds like a good idea. It's also something i've been looking at a
> bit. Take e.g. something like xchat. If you enable logging there you 
> basically keep your disc active all the time as xchat itself doesn't
> use a large internal cache to write the data out every X MB or so.

And why should it, honestly? Bufffering data ist the OSes job 99% of
the time. As long as xchat does not use fsync() after each write we
should be good.



From mjg at redhat.com  Fri Nov 28 13:24:23 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Fri, 28 Nov 2008 13:24:23 +0000
Subject: RFC: Changing default filesystem parameters for power
	management reasons
In-Reply-To: <492FE124.3030400@redhat.com>
References: <20081127153327.GA21300@srcf.ucam.org>
	<492FE124.3030400@redhat.com>
Message-ID: <20081128132423.GD4434@srcf.ucam.org>

On Fri, Nov 28, 2008 at 01:16:36PM +0100, Phil Knirsch wrote:

> Sounds like a great idea and something i've been working on myself 
> lately, too. I even went a bit further and thought about the idea if a 
> combination of a monitoring backend and a tuning engine could provide an 
> automatic adoption of the system to the current use. E.g. during daytime 
> when a user works with his machine we would typically see quite a few 
> reads and write all the time. Drive spindowns or other power saving 
> features could during that time be reduced so that the user will have 
> the best performance. During the night (in case he didn't turn of the 
> machine) only very few read and even fewer write operations should 
> happen, at which time the disk could then be powered down most of the 
> time. And of course this can be extended to not only disk drivces but 
> other tunable hardware components.

Indeed. There's been a fair amount of research into this - see 
http://www.soe.ucsc.edu/~tbisson/papers/bisson-fast04.pdf for instance. 
Some laptop drives will behave this way if APM settings are set 
appropriately, but a decent implementation of this in userspace would be 
very nice.

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



From pknirsch at redhat.com  Fri Nov 28 13:55:43 2008
From: pknirsch at redhat.com (Phil Knirsch)
Date: Fri, 28 Nov 2008 14:55:43 +0100
Subject: RFC: Changing default filesystem parameters for power management
 reasons
In-Reply-To: <20081128142209.758238c5@dhcp03.addix.net>
References: <20081127153327.GA21300@srcf.ucam.org>	<492FE124.3030400@redhat.com>
	<20081128142209.758238c5@dhcp03.addix.net>
Message-ID: <492FF85F.6060709@redhat.com>

Ralf Ertzinger wrote:
> Hi.
> 
> On Fri, 28 Nov 2008 13:16:36 +0100, Phil Knirsch wrote:
> 
>> Sounds like a good idea. It's also something i've been looking at a
>> bit. Take e.g. something like xchat. If you enable logging there you 
>> basically keep your disc active all the time as xchat itself doesn't
>> use a large internal cache to write the data out every X MB or so.
> 
> And why should it, honestly? Bufffering data ist the OSes job 99% of
> the time. As long as xchat does not use fsync() after each write we
> should be good.
> 

Maybe i wasn't clear enough. But take for example the difference between 
xchat and say, syslog. I'd be really unhappy if i'd loose 1 hour of 
syslog data in the event of a system crash, but i couldn't care less if 
i'd loose 1 hour of xchatlogs during that time. So it is in that case 
application specific in a way, and the kernel can't (and shouldn't) 
semantically know how important your data is that you write with it. And 
currently you can either do a write() and let the data be flushed to 
disk automatically by the kernel every dirty_writeback_centisecs or 
directly use a flush() after your write to make sure data is written 
immediately. So the only way an application can currently "delay" those 
writes is by using internal buffers that fill up and get written once 
they are full. And the difference between 1 write every minute due to 
dirty_writeback_centisecs and 1 write every hour because the buffer 
takes that long to get filled is quite large imo.

Regards, Phil

-- 
Philipp Knirsch              | Tel.:  +49-711-96437-470
Team Lead Core Services      | Fax.:  +49-711-96437-111
Red Hat GmbH                 | Email: Phil Knirsch <pknirsch at redhat.com>
Hauptstaetterstr. 58         | Web:   http://www.redhat.com/
D-70178 Stuttgart, Germany
Motd:  You're only jealous cos the little penguins are talking to me.



From lesmikesell at gmail.com  Fri Nov 28 14:43:59 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 28 Nov 2008 08:43:59 -0600
Subject: Feature proposal: New, Standard Documentation System
In-Reply-To: <1227761096.31656.50.camel@beta>
References: <492E05E7.2080708@cchtml.com> <1227761096.31656.50.camel@beta>
Message-ID: <493003AF.1070705@gmail.com>

Basil Mohamed Gohar wrote:
> Michael,
>
> What would a new system's advantage over man be?  For example, if a new
> interface to manpages were created, that might eliminate some of the
> initial learning curve some might say manpages present to users.
>
> Actually, I think manpages already solve your 5 points without need
> anything new.  Perhaps a manpage-to-X/HTML solution that allows reading
> them on the fly in a browser could be used to make accessing them
> easier.
>
> So, what this comes down to is creating an easier way to make manpages,
> if what I am suggesting makes sense.
>
> ________________________________________________________________________
>
> Basil Mohamed Gohar
> abu_hurayrah at hidayahonline.org
> www.basilgohar.com
>
>
>
>
> On Wed, 2008-11-26 at 20:28 -0600, Michael Cronenworth wrote:
>   
>> Far too often I find myself looking for non-existent man pages, Google 
>> results, or help menus in GNU/Linux software. What's the problem? There 
>> is no single, reliable, standardized documentation system that is 
>> universally accepted or appreciated. Yes, what I'm about to describe 
>> should obsolete man, info, and all the other dozen "help" documentation 
>> found in all the Fedora packages.
>>
>> Problem case out of the way: Fedora should pioneer a GNU/Linux 
>> documentation system that meets these criteria:
>> 1. Lightweight
>>    The entire system should not demand hundreds of megs of fonts, 
>> images, or other non-reusable requirements. I'm looking at you texlive. 
>> Recommendations: SQLite, ncurses, GTK. Existing toolkits; not new ones.
>> 2. CLI and GUI front-ends
>>    Allow users to be presented to a universal and familiar front-end no 
>> matter where they are. The parts should also be separable so that, for 
>> instance, if there is no X requirement in a said environment, the help 
>> packages should not require QT, GTK, etc.
>> 3. Universal formatting
>>    Obvious criteria, however, application specific formatting should be 
>> allowed as an optional addition after a standard format has been met.
>> 4. Easy to use creation tools
>>    It shouldn't take a programmer background to write help 
>> documentation. Be it WYSIWYG tools or a simple XML-like (hey, or even 
>> XML) language to create documentation pages.
>> 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.
>>
>> Optional criteria:
>> 1. Platform independence (for use on non-GNU/Linux systems)
>>
>> Feel free to rip me apart. To me, and I'm sure most standard Linux 
>> users, documentation for /any/ piece of software is a nightmare, even if 
>> you are the original author. It should not be that way!
>>     
>
Back in the old days when there weren't so many programs I always liked 
xman in split-screen view so you could see the index of available 
commands in one pane, click on a name, and get the man page in the other 
pane.   However, now that there are thousands of programs with mostly 
meaningless names, the index isn't very useful and the list is too big 
to just browse through everything to see what it does.   If you are 
going to come up with something new, it should provide a way to 
browse/search the short description that 'yum info' would have for a 
package, then view the man/info pages of the associated program(s), 
preferably without having to have the package installed first.  That is, 
you need a way to find which program you want, then the details of how 
to use it.  Man pages only provide the latter (a good thing, because 
you'll need the detail reference often but you'll probably remember the 
overview and not want it to clutter the reference).

-- 
   Les Mikesell
     lesmikesell at gmail.com



From mschwendt at gmail.com  Fri Nov 28 14:53:24 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 28 Nov 2008 15:53:24 +0100
Subject: automatically include files in %doc only if they are not empty
In-Reply-To: <200811281115.19506.opensource@till.name>
References: <200811271255.12657.opensource@till.name>
	<20081127155803.885118a2.mschwendt@gmail.com>
	<200811281115.19506.opensource@till.name>
Message-ID: <20081128155324.61b603f2.mschwendt@gmail.com>

On Fri, 28 Nov 2008 11:14:29 +0100, Till Maas wrote:

> I would like to avoid breaking the build in this case. I hoped there was some 
> macro, e.g. named exclude_empty, that would allow to exclude files only if 
> they are empty. This is what I came up with:
> 
> %define exclude_empty() %(test -s %1 && echo %1)
> 
> It should then be used somehow like this:
> %files
> %doc %exclude_empty TODO
> 
> But it seems to always exclude the file.

That's because the -s check happens in %_sourcedir not $RPM_BUILD_DIR.

Constructing a %files list file in %install would require more than
one line, but there you are inside the build dir. I dunno whether
that's worth it. %doc files don't toggle between empty/not-empty so
often.



From promac at gmail.com  Fri Nov 28 15:09:20 2008
From: promac at gmail.com (Paulo Cavalcanti)
Date: Fri, 28 Nov 2008 10:09:20 -0500
Subject: PulseAudio info needed
In-Reply-To: <adf480660811270533m7ba4be5ctd1e98359ed8800dd@mail.gmail.com>
References: <200811271301.11802.cannewilson@googlemail.com>
	<492E9B4B.4000206@redhat.com>
	<adf480660811270533m7ba4be5ctd1e98359ed8800dd@mail.gmail.com>
Message-ID: <68720af30811280709w1b73b23aq603ceb8e00924d07@mail.gmail.com>

On Thu, Nov 27, 2008 at 8:33 AM, Peter Lemenkov <lemenkov at gmail.com> wrote:

> 2008/11/27 Bryn M. Reeves <bmr at redhat.com>:
> > Anne Wilson wrote:
> >>
> >> There is a lot of FUD and general mistrust of PA.  It seems to me that
> it
> >> would help a great deal if someone would write a short statement about
> what
> >> PA is and how it should work.  If there is known readable references,
> they
> >> would help too, as would noting any known work-arounds for problem.
> >>
> >> It would be a great help to those of us who try to give user support.
>  I'd
> >> even put it on my own web space and direct folk to it, if that would
> help.
> >
> > There's a lot of good information on the PulseAudio project pages
> > themselves:
> >
> > http://www.pulseaudio.org/wiki/AboutPulseAudio
> > http://www.pulseaudio.org/wiki/FirstSteps
> > http://www.pulseaudio.org/wiki/PerfectSetup
> > http://www.pulseaudio.org/wiki/FAQ
> >
> > Maybe someone would be interested in summarising some of this and adding
> > Fedora-specifics on the Fedora wiki to make it a bit less intimidating
> for
> > novice users?
>
> My advice to all novices is to remove pulseaudio (as yet, it's still
> possible to remove almost completely this useless and buggy
> component). I wonder how it was decided (and whom) to push in as a
> default soundsystem?
>
> Most amazing feature of F-10 is "glitch-free sound with PulseAudio".
> Just think about - it's 2008 (almost 2009), and Fedora finally
> promises that its default soundserver would sometimes works.
>
> The most obscure part of PulseAudio story (except numerous "help!
> pulseaudio doesn't work for me" posts in various russian linux forums)
> is how it was chosen among other stable and mature alternatives. I
> really don't understant it.
>
> We got some soundservers already - namely, JACK, NAS, MAS (which was
> developed under Freedesktop umbrella) and even ALSA native interface,
> but someone choose solution which (even after long period of
> development) still not ready for daily work and does not provide any
> significant benefit to user even in long-term perspective.
>
>
I disagree. I am running Fedora 10 installed on a 8GB USB stick,
and my two sound cards were detected and can be controlled
via pulse audio. Speakers connected to the onboard soundcard
and headphones to an additional PCI card.

Literally, zero work.  mplayer, vlc, mpg123, gnormalize,
everything working. I can switch the sound from one card to
the other on the fly.

I must confess I know very little about alsa, but this time
I did not have to do anything at all. modprobe.conf
is empty and no .asoundrc

In fact, pulseaudio is one of the components that never gave any trouble.
On the other hand, things like compiz are a nightmare to configure, but
a lot of people seem to like it.

Everything depends on the referencial ...


-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081128/cfbe611b/attachment.htm>

From drago01 at gmail.com  Fri Nov 28 15:14:45 2008
From: drago01 at gmail.com (drago01)
Date: Fri, 28 Nov 2008 16:14:45 +0100
Subject: PulseAudio info needed
In-Reply-To: <adf480660811270533m7ba4be5ctd1e98359ed8800dd@mail.gmail.com>
References: <200811271301.11802.cannewilson@googlemail.com>
	<492E9B4B.4000206@redhat.com>
	<adf480660811270533m7ba4be5ctd1e98359ed8800dd@mail.gmail.com>
Message-ID: <f6ca9fed0811280714j40846429o2930d127b232c15e@mail.gmail.com>

On Thu, Nov 27, 2008 at 2:33 PM, Peter Lemenkov <lemenkov at gmail.com> wrote:

> We got some soundservers already - namely, JACK, NAS, MAS (which was
> developed under Freedesktop umbrella) and even ALSA native interface,
> but someone choose solution which (even after long period of
> development) still not ready for daily work and does not provide any
> significant benefit to user even in long-term perspective.

Per stream/app volume control, audio device hotplug, networked sound,
combined output on multiple soundcards, moving streams between
devices,....



From lemenkov at gmail.com  Fri Nov 28 15:14:53 2008
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Fri, 28 Nov 2008 18:14:53 +0300
Subject: PulseAudio info needed
In-Reply-To: <68720af30811280709w1b73b23aq603ceb8e00924d07@mail.gmail.com>
References: <200811271301.11802.cannewilson@googlemail.com>
	<492E9B4B.4000206@redhat.com>
	<adf480660811270533m7ba4be5ctd1e98359ed8800dd@mail.gmail.com>
	<68720af30811280709w1b73b23aq603ceb8e00924d07@mail.gmail.com>
Message-ID: <adf480660811280714q1a37626cq384540354f733514@mail.gmail.com>

2008/11/28, Paulo Cavalcanti <promac at gmail.com>:
> I disagree. I am running Fedora 10 installed on a 8GB USB stick,
> and my two sound cards were detected and can be controlled
> via pulse audio. Speakers connected to the onboard soundcard
>  and headphones to an additional PCI card.

That definitely looks like the special case. I still don't see why it
should be the default audio server for the majority of users.

-- 
With best regards!



From fedora at camperquake.de  Fri Nov 28 15:19:10 2008
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Fri, 28 Nov 2008 16:19:10 +0100
Subject: RFC: Changing default filesystem parameters for power
 management reasons
In-Reply-To: <492FF85F.6060709@redhat.com>
References: <20081127153327.GA21300@srcf.ucam.org>
	<492FE124.3030400@redhat.com>
	<20081128142209.758238c5@dhcp03.addix.net>
	<492FF85F.6060709@redhat.com>
Message-ID: <20081128161910.014578f9@dhcp03.addix.net>

i.

On Fri, 28 Nov 2008 14:55:43 +0100, Phil Knirsch wrote:

> Maybe i wasn't clear enough. But take for example the difference
> between xchat and say, syslog. I'd be really unhappy if i'd loose 1
> hour of syslog data in the event of a system crash, but i couldn't
> care less if i'd loose 1 hour of xchatlogs during that time. So it is
> in that case application specific in a way, and the kernel can't (and
> shouldn't) semantically know how important your data is that you
> write with it.

Well, it does, in a way. If you absolutely want to have your data on
the disk you have to call flush(). If you do not you're at the mercy
of, well, whatever governs data storage these days. But that has
always been the case.

If the kernel default is to flush un-flush()-ed data only every hour
then, well, then that's that. Nobody ever guaranteed writes every
few seconds.

Retrofitting buffering into every application (or into glibc) does not
strike me as an elegant solution. Besides, it wastes memory.



From fasteliteprogrammer at yahoo.com  Fri Nov 28 15:22:22 2008
From: fasteliteprogrammer at yahoo.com (Craig Petty)
Date: Fri, 28 Nov 2008 07:22:22 -0800 (PST)
Subject: python 2.6 prob
Message-ID: <311187.83928.qm@web36502.mail.mud.yahoo.com>

hi


I try compile python 2.6 with this ./configure --prefix=/usr/local and got this message

Failed to find the necessary bits to build these modules:
_bsddb _curses _curses_panel
_hashlib _sqlite3 _ssl
_tkinter bsddb185 bz2
dbm gdbm readline
sunaudiodev zlib
To find the necessary bits, look in setup.py in detect_modules() for the module's name. 


      



From lemenkov at gmail.com  Fri Nov 28 15:28:23 2008
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Fri, 28 Nov 2008 18:28:23 +0300
Subject: PulseAudio info needed
In-Reply-To: <f6ca9fed0811280714j40846429o2930d127b232c15e@mail.gmail.com>
References: <200811271301.11802.cannewilson@googlemail.com>
	<492E9B4B.4000206@redhat.com>
	<adf480660811270533m7ba4be5ctd1e98359ed8800dd@mail.gmail.com>
	<f6ca9fed0811280714j40846429o2930d127b232c15e@mail.gmail.com>
Message-ID: <adf480660811280728v17ff6d4ah9b0ca9b8bf5513b2@mail.gmail.com>

2008/11/28, drago01 <drago01 at gmail.com>:

> Per stream/app volume control, audio device hotplug, networked sound,
>  combined output on multiple soundcards, moving streams between
>  devices,....

No need to repeat again and again those advertisments.

And, again - that's not a majority of use cases. If someone would play
in funny games with routing mediastreams back and forth, he should use
its own distro, not a community's one.

BTW you should learn someting about those stable and mature
soundservers before replying to me - networked sound and combined
output were already implemented years ago.

-- 
With best regards!



From drago01 at gmail.com  Fri Nov 28 15:48:30 2008
From: drago01 at gmail.com (drago01)
Date: Fri, 28 Nov 2008 16:48:30 +0100
Subject: PulseAudio info needed
In-Reply-To: <adf480660811280728v17ff6d4ah9b0ca9b8bf5513b2@mail.gmail.com>
References: <200811271301.11802.cannewilson@googlemail.com>
	<492E9B4B.4000206@redhat.com>
	<adf480660811270533m7ba4be5ctd1e98359ed8800dd@mail.gmail.com>
	<f6ca9fed0811280714j40846429o2930d127b232c15e@mail.gmail.com>
	<adf480660811280728v17ff6d4ah9b0ca9b8bf5513b2@mail.gmail.com>
Message-ID: <f6ca9fed0811280748h4bdc363aoe591de4f2fdd78c@mail.gmail.com>

On Fri, Nov 28, 2008 at 4:28 PM, Peter Lemenkov <lemenkov at gmail.com> wrote:
> 2008/11/28, drago01 <drago01 at gmail.com>:
>
>> Per stream/app volume control, audio device hotplug, networked sound,
>>  combined output on multiple soundcards, moving streams between
>>  devices,....
>
> No need to repeat again and again those advertisments.
>
> And, again - that's not a majority of use cases. If someone would play
> in funny games with routing mediastreams back and forth, he should use
> its own distro, not a community's one.

For example device hotplug is something that people expect from a
modern operating system.

> BTW you should learn someting about those stable and mature
> soundservers before replying to me - networked sound and combined
> output were already implemented years ago.

they support a subset of what pa is doing besides they have a
different goal than pa (pa isn't "just another sound server")

btw you are trying to solve the problem in the wrong way:
"app A has bugs, don't ship it" vs "app A has bugs, find the causes
and fix them"



From jkeating at redhat.com  Thu Nov 27 04:07:16 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 26 Nov 2008 20:07:16 -0800
Subject: shortening time passed in bodhi?
In-Reply-To: <20081126213215.GQ2780@free.fr>
References: <20081126150440.GD2780@free.fr>
	<1227721928.5276.73.camel@luminos.localdomain>
	<20081126181208.GN2780@free.fr>
	<1227726481.5276.85.camel@luminos.localdomain>
	<20081126191926.GP2780@free.fr>
	<1227727922.5276.90.camel@luminos.localdomain>
	<20081126213215.GQ2780@free.fr>
Message-ID: <1227758837.5276.92.camel@luminos.localdomain>

On Wed, 2008-11-26 at 22:32 +0100, Patrice Dumas wrote:
> 
> Or maybe I misunderstood something, and the pending state is there until
> compose was finished?

Pending state is there until the compose is finished.  The compose
starts when I manually start it, which I'm trying to do once a day or
once every other day.

-- 
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/20081126/12850789/attachment.sig>

From jkeating at redhat.com  Fri Nov 28 17:45:19 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 28 Nov 2008 09:45:19 -0800
Subject: shortening time passed in bodhi?
In-Reply-To: <20081127222630.GC2659@free.fr>
References: <20081126150440.GD2780@free.fr>
	<1227721928.5276.73.camel@luminos.localdomain>
	<20081126181208.GN2780@free.fr>
	<1227726481.5276.85.camel@luminos.localdomain>
	<20081126191926.GP2780@free.fr>
	<1227727922.5276.90.camel@luminos.localdomain>
	<20081126213215.GQ2780@free.fr>
	<20081127204239.aa29f0b7.mschwendt@gmail.com>
	<20081127222630.GC2659@free.fr>
Message-ID: <1227894319.16222.1.camel@luminos.localdomain>

On Thu, 2008-11-27 at 23:26 +0100, Patrice Dumas wrote:
> 
> At the same time it may add time when an urgent update arrives and a
> large queue of non urgent updates is being composed.

The compose time doesn't necessarily get quicker if there are less
updates being pushed in that particular update.  The repos are created
from scratch each time an updates push is done.  This ensures we get all
the right pieces of new updates and remove pieces of old updates and get
a fresh calculation of multilib.  A compose of 10 new updates will take
roughly the same amount of time as a compose of 50 new updates.

-- 
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/20081128/96a48eea/attachment.sig>

From ssorce at redhat.com  Fri Nov 28 18:19:12 2008
From: ssorce at redhat.com (Simo Sorce)
Date: Fri, 28 Nov 2008 13:19:12 -0500
Subject: RFC: Changing default filesystem parameters for power
	management reasons
In-Reply-To: <492FF85F.6060709@redhat.com>
References: <20081127153327.GA21300@srcf.ucam.org>
	<492FE124.3030400@redhat.com>
	<20081128142209.758238c5@dhcp03.addix.net>
	<492FF85F.6060709@redhat.com>
Message-ID: <1227896352.2081.17.camel@localhost.localdomain>

On Fri, 2008-11-28 at 14:55 +0100, Phil Knirsch wrote:
> Ralf Ertzinger wrote:
> > Hi.
> > 
> > On Fri, 28 Nov 2008 13:16:36 +0100, Phil Knirsch wrote:
> > 
> >> Sounds like a good idea. It's also something i've been looking at a
> >> bit. Take e.g. something like xchat. If you enable logging there you 
> >> basically keep your disc active all the time as xchat itself doesn't
> >> use a large internal cache to write the data out every X MB or so.
> > 
> > And why should it, honestly? Bufffering data ist the OSes job 99% of
> > the time. As long as xchat does not use fsync() after each write we
> > should be good.
> > 
> 
> Maybe i wasn't clear enough. But take for example the difference between 
> xchat and say, syslog. I'd be really unhappy if i'd loose 1 hour of 
> syslog data in the event of a system crash, but i couldn't care less if 
> i'd loose 1 hour of xchatlogs during that time. So it is in that case 
> application specific in a way, and the kernel can't (and shouldn't) 
> semantically know how important your data is that you write with it. And 
> currently you can either do a write() and let the data be flushed to 
> disk automatically by the kernel every dirty_writeback_centisecs or 
> directly use a flush() after your write to make sure data is written 
> immediately. So the only way an application can currently "delay" those 
> writes is by using internal buffers that fill up and get written once 
> they are full. And the difference between 1 write every minute due to 
> dirty_writeback_centisecs and 1 write every hour because the buffer 
> takes that long to get filled is quite large imo.

Oh, but the kernel knows, the write() semantics clearly state that if
you want to make sure data is on disk you call flush(). If you don't
call flush() the kernel can delay flushing to disk indefinitely. So the
kernel have a very well defined way to know what apps want.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



From ivazqueznet at gmail.com  Fri Nov 28 18:34:53 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 28 Nov 2008 13:34:53 -0500
Subject: python 2.6 prob
In-Reply-To: <311187.83928.qm@web36502.mail.mud.yahoo.com>
References: <311187.83928.qm@web36502.mail.mud.yahoo.com>
Message-ID: <1227897293.3835.20.camel@ignacio.lan>

On Fri, 2008-11-28 at 07:22 -0800, Craig Petty wrote:
> I try compile python 2.6 with this ./configure --prefix=/usr/local and
> got this message
> 
> Failed to find the necessary bits to build these modules:
> _bsddb _curses _curses_panel
> _hashlib _sqlite3 _ssl
> _tkinter bsddb185 bz2
> dbm gdbm readline
> sunaudiodev zlib
> To find the necessary bits, look in setup.py in detect_modules() for
> the module's name. 

Which of the bits given in setup.py have you been unable to find? They
should all be in Fedora, except the bits for bsddb185 and sunaudiodev.

-- 
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/20081128/3c1656cd/attachment.sig>

From mcepl at redhat.com  Fri Nov 28 18:52:55 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 28 Nov 2008 19:52:55 +0100
Subject: PulseAudio info needed
References: <200811271301.11802.cannewilson@googlemail.com>
	<492E9B4B.4000206@redhat.com>
	<adf480660811270533m7ba4be5ctd1e98359ed8800dd@mail.gmail.com>
	<f6ca9fed0811280714j40846429o2930d127b232c15e@mail.gmail.com>
	<adf480660811280728v17ff6d4ah9b0ca9b8bf5513b2@mail.gmail.com>
Message-ID: <79r506xajr.ln2@ppp1053.in.ipex.cz>

On 2008-11-28, 15:28 GMT, Peter Lemenkov wrote:
> And, again - that's not a majority of use cases. If someone 
> would play in funny games with routing mediastreams back and 
> forth, he should use its own distro, not a community's one.

Actually, I do switch between headphones and speakers all the 
time and I found it pretty useful.

Mat?j



From fasteliteprogrammer at yahoo.com  Fri Nov 28 19:02:45 2008
From: fasteliteprogrammer at yahoo.com (Craig Petty)
Date: Fri, 28 Nov 2008 11:02:45 -0800 (PST)
Subject: python 2.6 prob
In-Reply-To: <1227897293.3835.20.camel@ignacio.lan>
Message-ID: <843086.51881.qm@web36508.mail.mud.yahoo.com>

where can i find the package call bsddb185 and sunaudiodev?Or maybe i should stay with python 2.5.2.


--- On Fri, 11/28/08, Ignacio Vazquez-Abrams <ivazqueznet at gmail.com> wrote:

> From: Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>
> Subject: Re: python 2.6 prob
> To: "Development discussions related to Fedora" <fedora-devel-list at redhat.com>
> Date: Friday, November 28, 2008, 12:34 PM
> On Fri, 2008-11-28 at 07:22 -0800, Craig Petty wrote:
> > I try compile python 2.6 with this ./configure
> --prefix=/usr/local and
> > got this message
> > 
> > Failed to find the necessary bits to build these
> modules:
> > _bsddb _curses _curses_panel
> > _hashlib _sqlite3 _ssl
> > _tkinter bsddb185 bz2
> > dbm gdbm readline
> > sunaudiodev zlib
> > To find the necessary bits, look in setup.py in
> detect_modules() for
> > the module's name. 
> 
> Which of the bits given in setup.py have you been unable to
> find? They
> should all be in Fedora, except the bits for bsddb185 and
> sunaudiodev.
> 
> -- 
> Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>
> 
> PLEASE don't CC me; I'm already subscribed
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


      



From jfm512 at free.fr  Fri Nov 28 19:44:08 2008
From: jfm512 at free.fr (Jean Francois Martinez)
Date: Fri, 28 Nov 2008 20:44:08 +0100
Subject: Status of driver ov511 based cameras
Message-ID: <1227901448.3603.17.camel@agnes.fremen.dune>

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




From cra at WPI.EDU  Fri Nov 28 19:58:41 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Fri, 28 Nov 2008 14:58:41 -0500
Subject: Status of driver ov511 based cameras
In-Reply-To: <1227901448.3603.17.camel@agnes.fremen.dune>
References: <1227901448.3603.17.camel@agnes.fremen.dune>
Message-ID: <20081128195841.GA12987@angus.ind.WPI.EDU>

On Fri, Nov 28, 2008 at 08:44:08PM +0100, Jean Francois Martinez wrote:
> 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.

No, only if it ends up in upstream kernel will it be in Fedora.

You might try submitting the driver and fixes to Greg K-H's "Linux 
Staging" tree:

http://lkml.org/lkml/2008/6/10/329



From cra at WPI.EDU  Fri Nov 28 20:06:43 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Fri, 28 Nov 2008 15:06:43 -0500
Subject: Status of driver ov511 based cameras
In-Reply-To: <20081128195841.GA12987@angus.ind.WPI.EDU>
References: <1227901448.3603.17.camel@agnes.fremen.dune>
	<20081128195841.GA12987@angus.ind.WPI.EDU>
Message-ID: <20081128200643.GB12987@angus.ind.WPI.EDU>

On Fri, Nov 28, 2008 at 02:58:41PM -0500, Chuck Anderson wrote:
> On Fri, Nov 28, 2008 at 08:44:08PM +0100, Jean Francois Martinez wrote:
> > 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.
> 
> No, only if it ends up in upstream kernel will it be in Fedora.
> 
> You might try submitting the driver and fixes to Greg K-H's "Linux 
> Staging" tree:
> 
> http://lkml.org/lkml/2008/6/10/329

See also LinuxDriverProject:

http://www.linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers?sortcol=table;up=#Web_Cams

http://www.rastageeks.org/ov51x-jpeg/index.php/Main_Page



From dominik at greysector.net  Fri Nov 28 20:44:01 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Fri, 28 Nov 2008 21:44:01 +0100
Subject: PulseAudio info needed
In-Reply-To: <79r506xajr.ln2@ppp1053.in.ipex.cz>
References: <200811271301.11802.cannewilson@googlemail.com>
	<492E9B4B.4000206@redhat.com>
	<adf480660811270533m7ba4be5ctd1e98359ed8800dd@mail.gmail.com>
	<f6ca9fed0811280714j40846429o2930d127b232c15e@mail.gmail.com>
	<adf480660811280728v17ff6d4ah9b0ca9b8bf5513b2@mail.gmail.com>
	<79r506xajr.ln2@ppp1053.in.ipex.cz>
Message-ID: <20081128204400.GA23162@mokona.greysector.net>

On Friday, 28 November 2008 at 19:52, Matej Cepl wrote:
> On 2008-11-28, 15:28 GMT, Peter Lemenkov wrote:
> > And, again - that's not a majority of use cases. If someone 
> > would play in funny games with routing mediastreams back and 
> > forth, he should use its own distro, not a community's one.
> 
> Actually, I do switch between headphones and speakers all the 
> time and I found it pretty useful.

I don't know about your setup, but both my stereo and my laptop
disable the speakers when I plug in the headphones. I don't know
where PulseAudio comes in here.

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 drago01 at gmail.com  Fri Nov 28 21:35:11 2008
From: drago01 at gmail.com (drago01)
Date: Fri, 28 Nov 2008 22:35:11 +0100
Subject: PulseAudio info needed
In-Reply-To: <20081128204400.GA23162@mokona.greysector.net>
References: <200811271301.11802.cannewilson@googlemail.com>
	<492E9B4B.4000206@redhat.com>
	<adf480660811270533m7ba4be5ctd1e98359ed8800dd@mail.gmail.com>
	<f6ca9fed0811280714j40846429o2930d127b232c15e@mail.gmail.com>
	<adf480660811280728v17ff6d4ah9b0ca9b8bf5513b2@mail.gmail.com>
	<79r506xajr.ln2@ppp1053.in.ipex.cz>
	<20081128204400.GA23162@mokona.greysector.net>
Message-ID: <f6ca9fed0811281335y3c51e8r790658e27605df28@mail.gmail.com>

On Fri, Nov 28, 2008 at 9:44 PM, Dominik 'Rathann' Mierzejewski
<dominik at greysector.net> wrote:
> On Friday, 28 November 2008 at 19:52, Matej Cepl wrote:
>> On 2008-11-28, 15:28 GMT, Peter Lemenkov wrote:
>> > And, again - that's not a majority of use cases. If someone
>> > would play in funny games with routing mediastreams back and
>> > forth, he should use its own distro, not a community's one.
>>
>> Actually, I do switch between headphones and speakers all the
>> time and I found it pretty useful.
>
> I don't know about your setup, but both my stereo and my laptop
> disable the speakers when I plug in the headphones. I don't know
> where PulseAudio comes in here.

if you are using usb or bluetooth* headphones you need pa for
hotplugging to work.

* should work but I never tested it, usb works fine



From ivazqueznet at gmail.com  Fri Nov 28 21:43:22 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 28 Nov 2008 16:43:22 -0500
Subject: python 2.6 prob
In-Reply-To: <843086.51881.qm@web36508.mail.mud.yahoo.com>
References: <843086.51881.qm@web36508.mail.mud.yahoo.com>
Message-ID: <1227908602.3835.26.camel@ignacio.lan>

On Fri, 2008-11-28 at 11:02 -0800, Craig Petty wrote:
> where can i find the package call bsddb185 and sunaudiodev?Or maybe i should stay with python 2.5.2.

You can find the bits for bsddb185 on... I don't know, a RHL6 machine?

You can find the bits for sunaudiodev on Solaris.

But are yo sure you even need those? Or that you can build 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/20081128/a372ce0b/attachment.sig>

From kevin.kofler at chello.at  Sat Nov 29 00:04:39 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 29 Nov 2008 01:04:39 +0100
Subject: shortening time passed in bodhi?
References: <20081126150440.GD2780@free.fr>
	<1227721928.5276.73.camel@luminos.localdomain>
	<20081126181208.GN2780@free.fr>
	<1227726481.5276.85.camel@luminos.localdomain>
	<20081126191926.GP2780@free.fr>
	<1227727922.5276.90.camel@luminos.localdomain>
	<20081126213215.GQ2780@free.fr>
	<20081127204239.aa29f0b7.mschwendt@gmail.com>
	<20081127222630.GC2659@free.fr>
	<1227894319.16222.1.camel@luminos.localdomain>
Message-ID: <ggq0un$p4f$1@ger.gmane.org>

Jesse Keating wrote:
> The compose time doesn't necessarily get quicker if there are less
> updates being pushed in that particular update.  The repos are created
> from scratch each time an updates push is done.

But isn't there a potential to cut down the time significantly there, by
using createrepo --update?

        Kevin Kofler



From carl at five-ten-sg.com  Sat Nov 29 00:15:28 2008
From: carl at five-ten-sg.com (Carl Byington)
Date: Fri, 28 Nov 2008 16:15:28 -0800
Subject: how to add fc10-update branch?
Message-ID: <1227917728.26993.32.camel@ns.five-ten-sg.com>

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

I have a package (libpst) that I was building for f10 by:

cd fedora/$NAME/devel
cvs update
make new-sources FILES=$BALL
cvs commit -m "update to $VER"
make tag
make build

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?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFJMImFL6j7milTFsERAnrHAJ47yzIi6TyGxLg5SaJFzthFApqFAwCfQLEJ
vXQoRtl4BJi2/nlgbKQfcGQ=
=2ghG
-----END PGP SIGNATURE-----




From konrad at tylerc.org  Sat Nov 29 00:21:00 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Fri, 28 Nov 2008 16:21:00 -0800
Subject: how to add fc10-update branch?
In-Reply-To: <1227917728.26993.32.camel@ns.five-ten-sg.com>
References: <1227917728.26993.32.camel@ns.five-ten-sg.com>
Message-ID: <200811281621.00146.konrad@tylerc.org>

On Friday 28 November 2008 04:15:28 pm Carl Byington wrote:
> I have a package (libpst) that I was building for f10 by:
>
> cd fedora/$NAME/devel
> cvs update
> make new-sources FILES=$BALL
> cvs commit -m "update to $VER"
> make tag
> make build
>
> 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

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




From laxathom at fedoraproject.org  Sat Nov 29 00:29:16 2008
From: laxathom at fedoraproject.org (Xavier Lamien)
Date: Sat, 29 Nov 2008 01:29:16 +0100
Subject: how to add fc10-update branch?
In-Reply-To: <1227917728.26993.32.camel@ns.five-ten-sg.com>
References: <1227917728.26993.32.camel@ns.five-ten-sg.com>
Message-ID: <62bc09df0811281629n519ef495g4164a98249e63305@mail.gmail.com>

On Sat, Nov 29, 2008 at 1:15 AM, Carl Byington <carl at five-ten-sg.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I have a package (libpst) that I was building for f10 by:
>
> cd fedora/$NAME/devel
> cvs update
> make new-sources FILES=$BALL
> cvs commit -m "update to $VER"
> make tag
> make build
>
> 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?

Sounds you need a fresh 'cvs co' of your package instead of 'cvs up'

-- 
Xavier.t Lamien
--
http://fedoraproject.org/wiki/XavierLamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB



From promac at gmail.com  Sat Nov 29 00:33:31 2008
From: promac at gmail.com (Paulo Cavalcanti)
Date: Fri, 28 Nov 2008 22:33:31 -0200
Subject: PulseAudio info needed
In-Reply-To: <20081128204400.GA23162@mokona.greysector.net>
References: <200811271301.11802.cannewilson@googlemail.com>
	<492E9B4B.4000206@redhat.com>
	<adf480660811270533m7ba4be5ctd1e98359ed8800dd@mail.gmail.com>
	<f6ca9fed0811280714j40846429o2930d127b232c15e@mail.gmail.com>
	<adf480660811280728v17ff6d4ah9b0ca9b8bf5513b2@mail.gmail.com>
	<79r506xajr.ln2@ppp1053.in.ipex.cz>
	<20081128204400.GA23162@mokona.greysector.net>
Message-ID: <68720af30811281633qcae1650o4f50ba2e90abaafa@mail.gmail.com>

On Fri, Nov 28, 2008 at 6:44 PM, Dominik 'Rathann' Mierzejewski <
dominik at greysector.net> wrote:

> On Friday, 28 November 2008 at 19:52, Matej Cepl wrote:
> > On 2008-11-28, 15:28 GMT, Peter Lemenkov wrote:
> > > And, again - that's not a majority of use cases. If someone
> > > would play in funny games with routing mediastreams back and
> > > forth, he should use its own distro, not a community's one.
> >
> > Actually, I do switch between headphones and speakers all the
> > time and I found it pretty useful.
>
> I don't know about your setup, but both my stereo and my laptop
> disable the speakers when I plug in the headphones. I don't know
> where PulseAudio comes in here.
>
>

You need two sound cards.


-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081128/1296b7f5/attachment.htm>

From ivazqueznet at gmail.com  Sat Nov 29 01:57:01 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 28 Nov 2008 20:57:01 -0500
Subject: Python 2.6 clear for Rawhide
Message-ID: <1227923821.3835.39.camel@ignacio.lan>

Alright, the Rawhide Python packages have had time to flush through, so
we're going to go ahead and commit 2.6 to Rawhide and start the rebuild
of all Python packages in Rawhide. So please keep your hands off any
packages that require python(abi) until we're done. Or if you like, you
can help out by bumping the release and building against the
dist-f11-python tag.

See you on the flipside.

-- 
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/20081128/766194e2/attachment.sig>

From fasteliteprogrammer at yahoo.com  Sat Nov 29 03:02:06 2008
From: fasteliteprogrammer at yahoo.com (Craig Petty)
Date: Fri, 28 Nov 2008 19:02:06 -0800 (PST)
Subject: Python 2.6 clear for Rawhide
In-Reply-To: <1227923821.3835.39.camel@ignacio.lan>
Message-ID: <727908.44882.qm@web36507.mail.mud.yahoo.com>

I look on rawhide and didn't seepython 2.6.


--- On Fri, 11/28/08, Ignacio Vazquez-Abrams <ivazqueznet at gmail.com> wrote:

> From: Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>
> Subject: Python 2.6 clear for Rawhide
> To: "Development discussions related to Fedora" <fedora-devel-list at redhat.com>
> Date: Friday, November 28, 2008, 7:57 PM
> Alright, the Rawhide Python packages have had time to flush
> through, so
> we're going to go ahead and commit 2.6 to Rawhide and
> start the rebuild
> of all Python packages in Rawhide. So please keep your
> hands off any
> packages that require python(abi) until we're done. Or
> if you like, you
> can help out by bumping the release and building against
> the
> dist-f11-python tag.
> 
> See you on the flipside.
> 
> -- 
> Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>
> 
> PLEASE don't CC me; I'm already subscribed
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


      



From ivazqueznet at gmail.com  Sat Nov 29 03:15:41 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 28 Nov 2008 22:15:41 -0500
Subject: Python 2.6 clear for Rawhide
In-Reply-To: <727908.44882.qm@web36507.mail.mud.yahoo.com>
References: <727908.44882.qm@web36507.mail.mud.yahoo.com>
Message-ID: <1227928541.3835.47.camel@ignacio.lan>

On Fri, 2008-11-28 at 19:02 -0800, Craig Petty wrote:
> I look on rawhide and didn't seepython 2.6.

That's because it won't be going into Rawhide until all the packages
that need it are rebuilt for 2.6.

-- 
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/20081128/5f026e6d/attachment.sig>

From fasteliteprogrammer at yahoo.com  Sat Nov 29 03:21:07 2008
From: fasteliteprogrammer at yahoo.com (Craig Petty)
Date: Fri, 28 Nov 2008 19:21:07 -0800 (PST)
Subject: Python 2.6 clear for Rawhide
In-Reply-To: <1227928541.3835.47.camel@ignacio.lan>
Message-ID: <989244.81885.qm@web36501.mail.mud.yahoo.com>

When will that be?Sorry i  must miss understand you.


--- On Fri, 11/28/08, Ignacio Vazquez-Abrams <ivazqueznet at gmail.com> wrote:

> From: Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>
> Subject: Re: Python 2.6 clear for Rawhide
> To: "Development discussions related to Fedora" <fedora-devel-list at redhat.com>
> Date: Friday, November 28, 2008, 9:15 PM
> On Fri, 2008-11-28 at 19:02 -0800, Craig Petty wrote:
> > I look on rawhide and didn't seepython 2.6.
> 
> That's because it won't be going into Rawhide until
> all the packages
> that need it are rebuilt for 2.6.
> 
> -- 
> Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>
> 
> PLEASE don't CC me; I'm already subscribed
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


      



From ivazqueznet at gmail.com  Sat Nov 29 03:26:59 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 28 Nov 2008 22:26:59 -0500
Subject: Python 2.6 clear for Rawhide
In-Reply-To: <989244.81885.qm@web36501.mail.mud.yahoo.com>
References: <989244.81885.qm@web36501.mail.mud.yahoo.com>
Message-ID: <1227929219.3835.52.camel@ignacio.lan>

On Fri, 2008-11-28 at 19:21 -0800, Craig Petty wrote:
> When will that be?Sorry i  must miss understand you.
> 
> 
> --- On Fri, 11/28/08, Ignacio Vazquez-Abrams <ivazqueznet at gmail.com> wrote:
> 
> > From: Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>
> > Subject: Re: Python 2.6 clear for Rawhide
> > To: "Development discussions related to Fedora" <fedora-devel-list at redhat.com>
> > Date: Friday, November 28, 2008, 9:15 PM
> > On Fri, 2008-11-28 at 19:02 -0800, Craig Petty wrote:
> > > I look on rawhide and didn't seepython 2.6.
> > 
> > That's because it won't be going into Rawhide until
> > all the packages
> > that need it are rebuilt for 2.6.
> > 
> > -- 
> > Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>
> > 
> > PLEASE don't CC me; I'm already subscribed
> > -- 
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> 
> 
>       
> 

I expect to have them ready within 10 days if all goes well. Then releng
will need to fold the tag back into f11-dist.

-- 
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/20081128/d39f362e/attachment.sig>

From carl at five-ten-sg.com  Sat Nov 29 03:28:57 2008
From: carl at five-ten-sg.com (Carl Byington)
Date: Fri, 28 Nov 2008 19:28:57 -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: <1227929337.26993.48.camel@ns.five-ten-sg.com>

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


> 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

Thanks! That should work in the future. Now I have a slightly different
problem. While my fedora/$NAME/devel was setup to build for f-10, I
managed to do a 'make tag', so I created both libpst-0_6_22-1_fc10 and
libpst-0_6_22-1_fc11 tags in the devel branch. Now I am trying to build
in the F-10 branch, and of course it complains:

ERROR: The tag libpst-0_6_22-1_fc10 is already applied on a different
branch
ERROR: You can not forcibly move tags between branches

It would be nice to 
    cvs tag -d libpst-0_6_22-1_fc10
in the devel branch, but that is not allowed. One recovery path is to
bump the version, and just build f-10 and devel again. Or is there a
way to force the removal of that incorrect f-10 tag from the devel(now
f11) branch?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFJMLbgL6j7milTFsERArHeAKCCHOTGsTOoT6DdVOYXoUerJefdeACfW784
ruc7/yRVXzDor65dNWJSmrU=
=jtU/
-----END PGP SIGNATURE-----




From konrad at tylerc.org  Sat Nov 29 03:44:42 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Fri, 28 Nov 2008 19:44:42 -0800
Subject: how to add fc10-update branch?
In-Reply-To: <1227929337.26993.48.camel@ns.five-ten-sg.com>
References: <1227917728.26993.32.camel@ns.five-ten-sg.com>
	<200811281621.00146.konrad@tylerc.org>
	<1227929337.26993.48.camel@ns.five-ten-sg.com>
Message-ID: <200811281944.43062.konrad@tylerc.org>

On Friday 28 November 2008 07:28:57 pm Carl Byington wrote:
> > 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
>
> Thanks! That should work in the future. Now I have a slightly different
> problem. While my fedora/$NAME/devel was setup to build for f-10, I
> managed to do a 'make tag', so I created both libpst-0_6_22-1_fc10 and
> libpst-0_6_22-1_fc11 tags in the devel branch. Now I am trying to build
> in the F-10 branch, and of course it complains:
>
> ERROR: The tag libpst-0_6_22-1_fc10 is already applied on a different
> branch
> ERROR: You can not forcibly move tags between branches
>
> It would be nice to
>     cvs tag -d libpst-0_6_22-1_fc10
> in the devel branch, but that is not allowed. One recovery path is to
> bump the version, and just build f-10 and devel again. Or is there a
> way to force the removal of that incorrect f-10 tag from the devel(now
> f11) branch?

Here you must bump the R and re-tag, unfortunately.

-- 
Conrad Meyer <konrad at tylerc.org>




From pemboa at gmail.com  Sat Nov 29 05:59:07 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 28 Nov 2008 23:59:07 -0600
Subject: Python 2.6 clear for Rawhide
In-Reply-To: <1227923821.3835.39.camel@ignacio.lan>
References: <1227923821.3835.39.camel@ignacio.lan>
Message-ID: <16de708d0811282159u5265f09bwf22d770910fbdbf7@mail.gmail.com>

2008/11/28 Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> Alright, the Rawhide Python packages have had time to flush through, so
> we're going to go ahead and commit 2.6 to Rawhide and start the rebuild
> of all Python packages in Rawhide. So please keep your hands off any
> packages that require python(abi) until we're done. Or if you like, you
> can help out by bumping the release and building against the
> dist-f11-python tag.
>
> See you on the flipside.


Are there any documents of Fedora's roadmap for Python 2.6 and Python 3?



-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From jkeating at redhat.com  Sat Nov 29 06:13:01 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 28 Nov 2008 22:13:01 -0800
Subject: shortening time passed in bodhi?
In-Reply-To: <ggq0un$p4f$1@ger.gmane.org>
References: <20081126150440.GD2780@free.fr>
	<1227721928.5276.73.camel@luminos.localdomain>
	<20081126181208.GN2780@free.fr>
	<1227726481.5276.85.camel@luminos.localdomain>
	<20081126191926.GP2780@free.fr>
	<1227727922.5276.90.camel@luminos.localdomain>
	<20081126213215.GQ2780@free.fr>
	<20081127204239.aa29f0b7.mschwendt@gmail.com>
	<20081127222630.GC2659@free.fr>
	<1227894319.16222.1.camel@luminos.localdomain>
	<ggq0un$p4f$1@ger.gmane.org>
Message-ID: <1227939181.5065.2.camel@localhost.localdomain>

On Sat, 2008-11-29 at 01:04 +0100, Kevin Kofler wrote:
> 
> But isn't there a potential to cut down the time significantly there, by
> using createrepo --update?

--update is used in some parts, but even that requires a stat of every
file to make sure the file itself hasn't changed.  Also, coding into
mash where to look at for repodata to update for the initial run has
been... challenging.  

It may cut the time down from 6 hours to 4~ hours, but we're still not
likely to do more than one push a day so it's not a super high priority
to make this faster.

-- 
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/20081128/68f0914d/attachment.sig>

From mathstuf at gmail.com  Sat Nov 29 06:23:53 2008
From: mathstuf at gmail.com (Ben Boeckel)
Date: Sat, 29 Nov 2008 01:23:53 -0500
Subject: Unowned directories
Message-ID: <200811290123.53933.MathStuf@gmail.com>

Hi,

I did the following command to find unowned directories (edited from my actual 
command to get rid of stuff like tmp that came up with lots of false-positives?
though it is quite possible there still are some here):

# rpm -q --whatprovides `find /{{,s}bin,boot,dev,etc,lib{,64},usr} -type d` | 
grep -v -e .x86_64 -e noarch -e i386 -e i686 -e ppc

There were too many to consider doing a bug report for each, so I'm posting here 
with the list I get on my machine to start. I got rid of things that seemed like 
false positives (things under /tmp, /var/cache, and /dev/.udev). Is this 
something for review-o-matic to handle and post about or should some other 
service check for unowned directories and files on a clean system and send out 
emails to fedora-devel-announce and CC maintainers of suspected owners (looking 
at owners of files in the directory, sibling files)?

To start, on my machine, I got the following output:

file /lib/alsa is not owned by any package
file /lib/alsa/init is not owned by any package
file /etc/selinux is not owned by any package
file /etc/selinux/targeted is not owned by any package
file /etc/selinux/targeted/contexts is not owned by any package
file /etc/selinux/targeted/contexts/files is not owned by any package
file /etc/selinux/targeted/modules is not owned by any package
file /etc/selinux/targeted/modules/active is not owned by any package
file /etc/selinux/targeted/modules/active/modules is not owned by any package
file /etc/selinux/targeted/policy is not owned by any package
file /etc/hotplug.d is not owned by any package
file /etc/hotplug.d/usb is not owned by any package
file /etc/.sdp is not owned by any package
file /etc/.sdp/license is not owned by any package
file /etc/snmp is not owned by any package
file /etc/vga is not owned by any package
file /etc/xdg/menus/kde-applications-merged is not owned by any package
file /etc/.ibm is not owned by any package
file /etc/.ibm/registry is not owned by any package
file /boot/efi is not owned by any package
file /boot/efi/EFI is not owned by any package
file /boot/lost+found is not owned by any package
file /dev/snd is not owned by any package
file /dev/disk is not owned by any package
file /dev/disk/by-label is not owned by any package
file /dev/disk/by-uuid is not owned by any package
file /dev/disk/by-id is not owned by any package
file /dev/disk/by-path is not owned by any package
file /dev/input is not owned by any package
file /dev/input/by-path is not owned by any package
file /dev/raw is not owned by any package
file /dev/cpu is not owned by any package
file /dev/cpu/1 is not owned by any package
file /dev/cpu/0 is not owned by any package
file /dev/bsg is not owned by any package
file /dev/bus is not owned by any package
file /dev/bus/usb is not owned by any package
file /dev/bus/usb/002 is not owned by any package
file /dev/bus/usb/007 is not owned by any package
file /dev/bus/usb/006 is not owned by any package
file /dev/bus/usb/005 is not owned by any package
file /dev/bus/usb/001 is not owned by any package
file /dev/bus/usb/004 is not owned by any package
file /dev/bus/usb/003 is not owned by any package
file /dev/.udev is not owned by any package
file /dev/net is not owned by any package
file /dev/mapper is not owned by any package
file /dev/shm is not owned by any package
file /dev/pts is not owned by any package
file /net is not owned by any package
file /usr/share/redhat is not owned by any package
file /usr/share/locale/sr at Latn is not owned by any package
file /usr/share/locale/sr at Latn/LC_MESSAGES is not owned by any package
file /usr/share/locale/ca at valencia is not owned by any package
file /usr/share/locale/ca at valencia/LC_MESSAGES is not owned by any package
file /usr/share/locale/uz at cyrillic is not owned by any package
file /usr/share/locale/uz at cyrillic/LC_MESSAGES is not owned by any package
file /usr/share/locale/twi is not owned by any package
file /usr/share/locale/twi/LC_MESSAGES is not owned by any package
file /usr/share/locale/default is not owned by any package
file /usr/share/locale/default/LC_MESSAGES is not owned by any package
file /usr/share/locale/xx is not owned by any package
file /usr/share/locale/xx/LC_MESSAGES is not owned by any package
file /usr/share/locale/l10n is not owned by any package
file /usr/share/locale/l10n/gy is not owned by any package
file /usr/share/locale/l10n/bt is not owned by any package
file /usr/share/locale/l10n/pa is not owned by any package
file /usr/share/locale/l10n/ky is not owned by any package
file /usr/share/locale/l10n/ng is not owned by any package
file /usr/share/locale/l10n/sd is not owned by any package
file /usr/share/locale/l10n/pe is not owned by any package
file /usr/share/locale/l10n/C is not owned by any package
file /usr/share/locale/l10n/ni is not owned by any package
file /usr/share/locale/l10n/dj is not owned by any package
file /usr/share/locale/l10n/cx is not owned by any package
file /usr/share/locale/l10n/at is not owned by any package
file /usr/share/locale/l10n/pw is not owned by any package
file /usr/share/locale/l10n/bi is not owned by any package
file /usr/share/locale/l10n/tv is not owned by any package
file /usr/share/locale/l10n/lb is not owned by any package
file /usr/share/locale/l10n/gd is not owned by any package
file /usr/share/locale/l10n/zm is not owned by any package
file /usr/share/locale/l10n/ao is not owned by any package
file /usr/share/locale/l10n/ir is not owned by any package
file /usr/share/locale/l10n/kg is not owned by any package
file /usr/share/locale/l10n/ci is not owned by any package
file /usr/share/locale/l10n/sv is not owned by any package
file /usr/share/locale/l10n/my is not owned by any package
file /usr/share/locale/l10n/mo is not owned by any package
file /usr/share/locale/l10n/ly is not owned by any package
file /usr/share/locale/l10n/st is not owned by any package
file /usr/share/locale/l10n/sz is not owned by any package
file /usr/share/locale/l10n/dm is not owned by any package
file /usr/share/locale/l10n/gt is not owned by any package
file /usr/share/locale/l10n/tm is not owned by any package
file /usr/share/locale/l10n/id is not owned by any package
file /usr/share/locale/l10n/mq is not owned by any package
file /usr/share/locale/l10n/za is not owned by any package
file /usr/share/locale/l10n/mc is not owned by any package
file /usr/share/locale/l10n/nz is not owned by any package
file /usr/share/locale/l10n/mv is not owned by any package
file /usr/share/locale/l10n/li is not owned by any package
file /usr/share/locale/l10n/ro is not owned by any package
file /usr/share/locale/l10n/mg is not owned by any package
file /usr/share/locale/l10n/ie is not owned by any package
file /usr/share/locale/l10n/sa is not owned by any package
file /usr/share/locale/l10n/ga is not owned by any package
file /usr/share/locale/l10n/kh is not owned by any package
file /usr/share/locale/l10n/si is not owned by any package
file /usr/share/locale/l10n/ax is not owned by any package
file /usr/share/locale/l10n/kr is not owned by any package
file /usr/share/locale/l10n/gr is not owned by any package
file /usr/share/locale/l10n/lt is not owned by any package
file /usr/share/locale/l10n/ls is not owned by any package
file /usr/share/locale/l10n/bz is not owned by any package
file /usr/share/locale/l10n/la is not owned by any package
file /usr/share/locale/l10n/aw is not owned by any package
file /usr/share/locale/l10n/va is not owned by any package
file /usr/share/locale/l10n/km is not owned by any package
file /usr/share/locale/l10n/to is not owned by any package
file /usr/share/locale/l10n/fj is not owned by any package
file /usr/share/locale/l10n/mh is not owned by any package
file /usr/share/locale/l10n/tj is not owned by any package
file /usr/share/locale/l10n/ck is not owned by any package
file /usr/share/locale/l10n/lc is not owned by any package
file /usr/share/locale/l10n/bn is not owned by any package
file /usr/share/locale/l10n/cn is not owned by any package
file /usr/share/locale/l10n/nl is not owned by any package
file /usr/share/locale/l10n/fo is not owned by any package
file /usr/share/locale/l10n/td is not owned by any package
file /usr/share/locale/l10n/kw is not owned by any package
file /usr/share/locale/l10n/cl is not owned by any package
file /usr/share/locale/l10n/dz is not owned by any package
file /usr/share/locale/l10n/us is not owned by any package
file /usr/share/locale/l10n/es is not owned by any package
file /usr/share/locale/l10n/sc is not owned by any package
file /usr/share/locale/l10n/er is not owned by any package
file /usr/share/locale/l10n/nu is not owned by any package
file /usr/share/locale/l10n/de is not owned by any package
file /usr/share/locale/l10n/pk is not owned by any package
file /usr/share/locale/l10n/vc is not owned by any package
file /usr/share/locale/l10n/mt is not owned by any package
file /usr/share/locale/l10n/pf is not owned by any package
file /usr/share/locale/l10n/cz is not owned by any package
file /usr/share/locale/l10n/ht is not owned by any package
file /usr/share/locale/l10n/sr is not owned by any package
file /usr/share/locale/l10n/cd is not owned by any package
file /usr/share/locale/l10n/tk is not owned by any package
file /usr/share/locale/l10n/mm is not owned by any package
file /usr/share/locale/l10n/ma is not owned by any package
file /usr/share/locale/l10n/so is not owned by any package
file /usr/share/locale/l10n/lu is not owned by any package
file /usr/share/locale/l10n/gq is not owned by any package
file /usr/share/locale/l10n/fi is not owned by any package
file /usr/share/locale/l10n/by is not owned by any package
file /usr/share/locale/l10n/cv is not owned by any package
file /usr/share/locale/l10n/cc is not owned by any package
file /usr/share/locale/l10n/np is not owned by any package
file /usr/share/locale/l10n/ae is not owned by any package
file /usr/share/locale/l10n/hk is not owned by any package
file /usr/share/locale/l10n/dk is not owned by any package
file /usr/share/locale/l10n/jo is not owned by any package
file /usr/share/locale/l10n/tr is not owned by any package
file /usr/share/locale/l10n/mr is not owned by any package
file /usr/share/locale/l10n/hu is not owned by any package
file /usr/share/locale/l10n/jp is not owned by any package
file /usr/share/locale/l10n/hn is not owned by any package
file /usr/share/locale/l10n/gi is not owned by any package
file /usr/share/locale/l10n/ve is not owned by any package
file /usr/share/locale/l10n/mn is not owned by any package
file /usr/share/locale/l10n/eh is not owned by any package
file /usr/share/locale/l10n/al is not owned by any package
file /usr/share/locale/l10n/me is not owned by any package
file /usr/share/locale/l10n/gu is not owned by any package
file /usr/share/locale/l10n/vu is not owned by any package
file /usr/share/locale/l10n/gb is not owned by any package
file /usr/share/locale/l10n/ne is not owned by any package
file /usr/share/locale/l10n/fk is not owned by any package
file /usr/share/locale/l10n/ai is not owned by any package
file /usr/share/locale/l10n/zw is not owned by any package
file /usr/share/locale/l10n/co is not owned by any package
file /usr/share/locale/l10n/bf is not owned by any package
file /usr/share/locale/l10n/bj is not owned by any package
file /usr/share/locale/l10n/an is not owned by any package
file /usr/share/locale/l10n/gl is not owned by any package
file /usr/share/locale/l10n/ye is not owned by any package
file /usr/share/locale/l10n/se is not owned by any package
file /usr/share/locale/l10n/kz is not owned by any package
file /usr/share/locale/l10n/ca is not owned by any package
file /usr/share/locale/l10n/as is not owned by any package
file /usr/share/locale/l10n/mu is not owned by any package
file /usr/share/locale/l10n/au is not owned by any package
file /usr/share/locale/l10n/pt is not owned by any package
file /usr/share/locale/l10n/af is not owned by any package
file /usr/share/locale/l10n/sy is not owned by any package
file /usr/share/locale/l10n/fm is not owned by any package
file /usr/share/locale/l10n/mw is not owned by any package
file /usr/share/locale/l10n/bo is not owned by any package
file /usr/share/locale/l10n/ms is not owned by any package
file /usr/share/locale/l10n/bg is not owned by any package
file /usr/share/locale/l10n/om is not owned by any package
file /usr/share/locale/l10n/th is not owned by any package
file /usr/share/locale/l10n/ch is not owned by any package
file /usr/share/locale/l10n/rw is not owned by any package
file /usr/share/locale/l10n/uz is not owned by any package
file /usr/share/locale/l10n/ad is not owned by any package
file /usr/share/locale/l10n/sb is not owned by any package
file /usr/share/locale/l10n/bh is not owned by any package
file /usr/share/locale/l10n/gh is not owned by any package
file /usr/share/locale/l10n/vi is not owned by any package
file /usr/share/locale/l10n/cf is not owned by any package
file /usr/share/locale/l10n/iq is not owned by any package
file /usr/share/locale/l10n/hr is not owned by any package
file /usr/share/locale/l10n/ws is not owned by any package
file /usr/share/locale/l10n/ee is not owned by any package
file /usr/share/locale/l10n/cr is not owned by any package
file /usr/share/locale/l10n/ag is not owned by any package
file /usr/share/locale/l10n/tg is not owned by any package
file /usr/share/locale/l10n/tn is not owned by any package
file /usr/share/locale/l10n/fr is not owned by any package
file /usr/share/locale/l10n/pg is not owned by any package
file /usr/share/locale/l10n/py is not owned by any package
file /usr/share/locale/l10n/sn is not owned by any package
file /usr/share/locale/l10n/nr is not owned by any package
file /usr/share/locale/l10n/ec is not owned by any package
file /usr/share/locale/l10n/in is not owned by any package
file /usr/share/locale/l10n/pm is not owned by any package
file /usr/share/locale/l10n/sg is not owned by any package
file /usr/share/locale/l10n/bd is not owned by any package
file /usr/share/locale/l10n/wf is not owned by any package
file /usr/share/locale/l10n/sm is not owned by any package
file /usr/share/locale/l10n/no is not owned by any package
file /usr/share/locale/l10n/br is not owned by any package
file /usr/share/locale/l10n/md is not owned by any package
file /usr/share/locale/l10n/gp is not owned by any package
file /usr/share/locale/l10n/bb is not owned by any package
file /usr/share/locale/l10n/eg is not owned by any package
file /usr/share/locale/l10n/lr is not owned by any package
file /usr/share/locale/l10n/ru is not owned by any package
file /usr/share/locale/l10n/tw is not owned by any package
file /usr/share/locale/l10n/ua is not owned by any package
file /usr/share/locale/l10n/ar is not owned by any package
file /usr/share/locale/l10n/vn is not owned by any package
file /usr/share/locale/l10n/uy is not owned by any package
file /usr/share/locale/l10n/bw is not owned by any package
file /usr/share/locale/l10n/sk is not owned by any package
file /usr/share/locale/l10n/bs is not owned by any package
file /usr/share/locale/l10n/ge is not owned by any package
file /usr/share/locale/l10n/mz is not owned by any package
file /usr/share/locale/l10n/rs is not owned by any package
file /usr/share/locale/l10n/nc is not owned by any package
file /usr/share/locale/l10n/tt is not owned by any package
file /usr/share/locale/l10n/pl is not owned by any package
file /usr/share/locale/l10n/il is not owned by any package
file /usr/share/locale/l10n/am is not owned by any package
file /usr/share/locale/l10n/ki is not owned by any package
file /usr/share/locale/l10n/gw is not owned by any package
file /usr/share/locale/l10n/kp is not owned by any package
file /usr/share/locale/l10n/ml is not owned by any package
file /usr/share/locale/l10n/pn is not owned by any package
file /usr/share/locale/l10n/mk is not owned by any package
file /usr/share/locale/l10n/tz is not owned by any package
file /usr/share/locale/l10n/az is not owned by any package
file /usr/share/locale/l10n/lk is not owned by any package
file /usr/share/locale/l10n/na is not owned by any package
file /usr/share/locale/l10n/mx is not owned by any package
file /usr/share/locale/l10n/jm is not owned by any package
file /usr/share/locale/l10n/qa is not owned by any package
file /usr/share/locale/l10n/gm is not owned by any package
file /usr/share/locale/l10n/nf is not owned by any package
file /usr/share/locale/l10n/vg is not owned by any package
file /usr/share/locale/l10n/lv is not owned by any package
file /usr/share/locale/l10n/et is not owned by any package
file /usr/share/locale/l10n/ps is not owned by any package
file /usr/share/locale/l10n/ba is not owned by any package
file /usr/share/locale/l10n/cy is not owned by any package
file /usr/share/locale/l10n/bm is not owned by any package
file /usr/share/locale/l10n/be is not owned by any package
file /usr/share/locale/l10n/ph is not owned by any package
file /usr/share/locale/l10n/ug is not owned by any package
file /usr/share/locale/l10n/cg is not owned by any package
file /usr/share/locale/l10n/cu is not owned by any package
file /usr/share/locale/l10n/tp is not owned by any package
file /usr/share/locale/l10n/gn is not owned by any package
file /usr/share/locale/l10n/pr is not owned by any package
file /usr/share/locale/l10n/kn is not owned by any package
file /usr/share/locale/l10n/ke is not owned by any package
file /usr/share/locale/l10n/do is not owned by any package
file /usr/share/locale/l10n/cm is not owned by any package
file /usr/share/locale/l10n/sh is not owned by any package
file /usr/share/locale/l10n/is is not owned by any package
file /usr/share/locale/l10n/tc is not owned by any package
file /usr/share/locale/l10n/it is not owned by any package
file /usr/share/locale/en_US at piglatin is not owned by any package
file /usr/share/locale/en_US at piglatin/LC_MESSAGES is not owned by any package
file /usr/share/locale/nds_DE is not owned by any package
file /usr/share/locale/nds_DE/LC_MESSAGES is not owned by any package
file /usr/share/locale/sp is not owned by any package
file /usr/share/locale/sp/LC_MESSAGES is not owned by any package
file /usr/share/locale/zh_TW.Big5 is not owned by any package
file /usr/share/locale/zh_TW.Big5/LC_MESSAGES is not owned by any package
file /usr/share/locale/zh_CN.GB2312 is not owned by any package
file /usr/share/locale/zh_CN.GB2312/LC_MESSAGES is not owned by any package
file /usr/share/locale/en_ZA is not owned by any package
file /usr/share/locale/en_ZA/LC_MESSAGES is not owned by any package
file /usr/share/locale/gos is not owned by any package
file /usr/share/locale/gos/LC_MESSAGES is not owned by any package
file /usr/share/maxima/5.15.0 is not owned by any package
file /usr/share/akonadi is not owned by any package
file /usr/share/akonadi/agents is not owned by any package
file /usr/share/selinux is not owned by any package
file /usr/share/selinux/packages is not owned by any package
file /usr/share/selinux/packages/BackupPC is not owned by any package
file /usr/share/idl is not owned by any package
file /usr/share/rhgb is not owned by any package
file /usr/share/xml/docbook is not owned by any package
file /usr/share/kde4/apps/konqueror/icons/oxygen is not owned by any package
file /usr/share/kde4/apps/konqueror/icons/oxygen/scalable is not owned by any 
package
file /usr/share/kde4/apps/konqueror/icons/oxygen/scalable/actions is not owned by 
any package
file /usr/share/kde4/apps/konqueror/icons/oxygen/48x48 is not owned by any 
package
file /usr/share/kde4/apps/konqueror/icons/oxygen/48x48/actions is not owned by 
any package
file /usr/share/kde4/apps/konqueror/icons/oxygen/64x64 is not owned by any 
package
file /usr/share/kde4/apps/konqueror/icons/oxygen/64x64/actions is not owned by 
any package
file /usr/share/kde4/apps/konqueror/icons/oxygen/16x16 is not owned by any 
package
file /usr/share/kde4/apps/konqueror/icons/oxygen/16x16/actions is not owned by 
any package
file /usr/share/kde4/apps/konqueror/icons/oxygen/22x22 is not owned by any 
package
file /usr/share/kde4/apps/konqueror/icons/oxygen/22x22/actions is not owned by 
any package
file /usr/share/kde4/apps/konqueror/icons/oxygen/32x32 is not owned by any 
package
file /usr/share/kde4/apps/konqueror/icons/oxygen/32x32/actions is not owned by 
any package
file /usr/share/kde4/apps/konqueror/kpartplugins is not owned by any package
file /usr/share/kde4/apps/kuiviewerpart is not owned by any package
file /usr/share/kde4/apps/webkitpart is not owned by any package
file /usr/share/kde4/apps/webkitpart/kpartplugins is not owned by any package
file /usr/share/kde4/apps/cervisiapart is not owned by any package
file /usr/share/kde4/apps/svgpart is not owned by any package
file /usr/share/kde4/apps/profiles is not owned by any package
file /usr/share/kde4/apps/kuiviewer is not owned by any package
file /usr/share/kde4/apps/kcachegrind is not owned by any package
file /usr/share/wallpapers/Solar is not owned by any package
file /usr/share/gtk-doc/html/gstreamer-plugins-0.10 is not owned by any package
file /usr/share/gtk-doc/html/gstreamer-libs-0.10 is not owned by any package
file /usr/share/gtk-doc/html/gstreamer-0.10 is not owned by any package
file /usr/share/man/pt_BR is not owned by any package
file /usr/share/man/pt_BR/man5 is not owned by any package
file /usr/share/man/pt_BR/man1 is not owned by any package
file /usr/share/man/pt_BR/man8 is not owned by any package
file /usr/share/man/sv is not owned by any package
file /usr/share/man/sv/man5 is not owned by any package
file /usr/share/man/sv/man3 is not owned by any package
file /usr/share/man/sv/man1 is not owned by any package
file /usr/share/man/sv/man8 is not owned by any package
file /usr/share/man/id is not owned by any package
file /usr/share/man/id/man8 is not owned by any package
file /usr/share/man/it.ISO8859-1 is not owned by any package
file /usr/share/man/it.ISO8859-1/man1 is not owned by any package
file /usr/share/man/pl.ISO8859-2 is not owned by any package
file /usr/share/man/pl.ISO8859-2/man1 is not owned by any package
file /usr/share/man/tr is not owned by any package
file /usr/share/man/tr/man5 is not owned by any package
file /usr/share/man/tr/man1 is not owned by any package
file /usr/share/man/tr/man8 is not owned by any package
file /usr/share/man/hu is not owned by any package
file /usr/share/man/hu/man4 is not owned by any package
file /usr/share/man/hu/man1 is not owned by any package
file /usr/share/man/hu/man8 is not owned by any package
file /usr/share/man/ru.KOI8-R is not owned by any package
file /usr/share/man/ru.KOI8-R/man1 is not owned by any package
file /usr/share/man/zh_CN is not owned by any package
file /usr/share/man/zh_CN/man1 is not owned by any package
file /usr/share/man/zh_CN/man8 is not owned by any package
file /usr/share/man/fr.UTF-8 is not owned by any package
file /usr/share/man/fr.UTF-8/man1 is not owned by any package
file /usr/share/man/ru.UTF-8 is not owned by any package
file /usr/share/man/ru.UTF-8/man1 is not owned by any package
file /usr/share/man/fr/man3 is not owned by any package
file /usr/share/man/pl.UTF-8 is not owned by any package
file /usr/share/man/pl.UTF-8/man1 is not owned by any package
file /usr/share/man/ru/man5 is not owned by any package
file /usr/share/man/ru/man3 is not owned by any package
file /usr/share/man/eo is not owned by any package
file /usr/share/man/eo/man1 is not owned by any package
file /usr/share/man/sk is not owned by any package
file /usr/share/man/sk/man8 is not owned by any package
file /usr/share/man/it.UTF-8 is not owned by any package
file /usr/share/man/it.UTF-8/man1 is not owned by any package
file /usr/share/man/fr.ISO8859-1 is not owned by any package
file /usr/share/man/fr.ISO8859-1/man1 is not owned by any package
file /usr/share/man/zh_TW is not owned by any package
file /usr/share/man/zh_TW/man1 is not owned by any package
file /usr/share/man/zh_TW/man8 is not owned by any package
file /usr/share/man/it/man3 is not owned by any package
file /usr/share/pam_pkcs11 is not owned by any package
file /usr/share/pygtk is not owned by any package
file /usr/share/pygtk/2.0 is not owned by any package
file /usr/share/apps/konqsidebartng is not owned by any package
file /usr/share/apps/konqsidebartng/virtual_folders is not owned by any package
file /usr/share/apps/konqsidebartng/virtual_folders/services is not owned by any 
package
file /usr/share/apps/kdeui.BAK is not owned by any package
file /usr/share/apps/kdeui.BAK/pics is not owned by any package
file /usr/share/apps/kdeui.BAK/about is not owned by any package
file /usr/share/apps/kbtobexclient is not owned by any package
file /usr/share/apps/kyum is not owned by any package
file /usr/share/apps/kyum/icons is not owned by any package
file /usr/share/apps/kontact is not owned by any package
file /usr/share/apps/kontact/ksettingsdialog is not owned by any package
file /usr/share/apps/kdebluetooth is not owned by any package
file /usr/share/firstboot is not owned by any package
file /usr/share/firstboot/themes is not owned by any package
file /usr/share/firstboot/themes/default is not owned by any package
file /usr/share/firstboot/modules is not owned by any package
file /usr/share/icons/mono is not owned by any package
file /usr/share/icons/Fedora/96x96 is not owned by any package
file /usr/share/icons/Fedora/96x96/places is not owned by any package
file /usr/share/icons/Fedora/48x48/places is not owned by any package
file /usr/share/icons/Fedora/16x16/places is not owned by any package
file /usr/share/icons/Fedora/32x32/places is not owned by any package
file /usr/share/icons/Fedora/24x24/places is not owned by any package
file /usr/share/icons/Fedora/36x36 is not owned by any package
file /usr/share/icons/Fedora/36x36/places is not owned by any package
file /usr/share/icons/Bluecurve/96x96 is not owned by any package
file /usr/share/icons/Bluecurve/96x96/apps is not owned by any package
file /usr/share/icons/Bluecurve/48x48 is not owned by any package
file /usr/share/icons/Bluecurve/48x48/apps is not owned by any package
file /usr/share/icons/Bluecurve/16x16 is not owned by any package
file /usr/share/icons/Bluecurve/16x16/apps is not owned by any package
file /usr/share/icons/Bluecurve/32x32 is not owned by any package
file /usr/share/icons/Bluecurve/32x32/apps is not owned by any package
file /usr/share/icons/Bluecurve/24x24 is not owned by any package
file /usr/share/icons/Bluecurve/24x24/apps is not owned by any package
file /usr/share/icons/Bluecurve/36x36 is not owned by any package
file /usr/share/icons/Bluecurve/36x36/apps is not owned by any package
file /usr/share/desktop-menu-patches is not owned by any package
file /usr/share/maven2/default_poms is not owned by any package
file /usr/share/java/mx4j/boa is not owned by any package
file /usr/share/lyx is not owned by any package
file /usr/share/lyx/clipart is not owned by any package
file /usr/share/gnome-vpn-properties is not owned by any package
file /usr/share/gnome-vpn-properties/openvpn is not owned by any package
file /usr/share/gnome-vpn-properties/vpnc is not owned by any package
file /usr/share/qt4/mkspecs is not owned by any package
file /usr/share/qt4/mkspecs/features is not owned by any package
file /usr/share/doc/vlc is not owned by any package
file /usr/share/doc/python-iniparse-0.2.3 is not owned by any package
file /usr/share/doc/HTML/en/kyum is not owned by any package
file /usr/share/doc/qt-devel-3.3.8b is not owned by any package
file /usr/share/doc/check is not owned by any package
file /usr/share/doc/pcre is not owned by any package
file /usr/share/doc/jetty-5.1.14 is not owned by any package
file /usr/share/doc/presto-0.1.3 is not owned by any package
file /usr/share/doc/presto-0.1.3/examples is not owned by any package
file /usr/share/doc/jakarta-commons-net-1.4.1 is not owned by any package
file /usr/share/applications/screensavers is not owned by any package
file /usr/share/opensync-1.0/defaults is not owned by any package
file /usr/share/gnome/html is not owned by any package
file /usr/share/gnome/shutdown is not owned by any package
file /usr/share/gnome/help is not owned by any package
file /usr/share/gnome/autostart is not owned by any package
file /usr/share/vim/vimfiles/after/syntax is not owned by any package
file /usr/share/mime/inode is not owned by any package
file /usr/share/mime/video is not owned by any package
file /usr/share/mime/message is not owned by any package
file /usr/share/mime/uri is not owned by any package
file /usr/share/mime/model is not owned by any package
file /usr/share/mime/x-content is not owned by any package
file /usr/share/mime/fonts is not owned by any package
file /usr/share/mime/all is not owned by any package
file /usr/share/mime/application is not owned by any package
file /usr/share/mime/image is not owned by any package
file /usr/share/mime/text is not owned by any package
file /usr/share/mime/audio is not owned by any package
file /usr/share/mime/print is not owned by any package
file /usr/share/mime/x-epoc is not owned by any package
file /usr/share/mime/multipart is not owned by any package
file /usr/share/mime/interface is not owned by any package
file /usr/share/services/kformdesigner is not owned by any package
file /usr/share/gnome-control-center/default-apps is not owned by any package
file /usr/share/snmp is not owned by any package
file /usr/share/gnome-screensaver is not owned by any package
file /usr/share/config/magic is not owned by any package
file /usr/share/texmf/tex/latex/misc is not owned by any package
file /usr/share/texmf/web2c/etex is not owned by any package
file /usr/share/texmf/web2c/pdfetex is not owned by any package
file /usr/share/netbeans is not owned by any package
file /usr/lib/mozilla/plugins-wrapped is not owned by any package
file /usr/lib/perl5/site_perl is not owned by any package
file /usr/lib/perl5/site_perl/5.8.8 is not owned by any package
file /usr/lib/perl5/site_perl/5.8.8/LocaleData is not owned by any package
file /usr/lib/perl5/site_perl/5.8.8/LocaleData/sr at Latn is not owned by any 
package
file /usr/lib/perl5/site_perl/5.8.8/LocaleData/sr at Latn/LC_MESSAGES is not owned 
by any package
file /usr/lib/perl5/site_perl/5.8.8/LocaleData/cs is not owned by any package
file /usr/lib/perl5/site_perl/5.8.8/LocaleData/cs/LC_MESSAGES is not owned by any 
package
file /usr/lib/perl5/site_perl/5.8.8/LocaleData/es is not owned by any package
file /usr/lib/perl5/site_perl/5.8.8/LocaleData/es/LC_MESSAGES is not owned by any 
package
file /usr/lib/perl5/site_perl/5.8.8/LocaleData/de is not owned by any package
file /usr/lib/perl5/site_perl/5.8.8/LocaleData/de/LC_MESSAGES is not owned by any 
package
file /usr/lib/perl5/site_perl/5.8.8/LocaleData/sr is not owned by any package
file /usr/lib/perl5/site_perl/5.8.8/LocaleData/sr/LC_MESSAGES is not owned by any 
package
file /usr/lib/perl5/site_perl/5.8.8/LocaleData/fr is not owned by any package
file /usr/lib/perl5/site_perl/5.8.8/LocaleData/fr/LC_MESSAGES is not owned by any 
package
file /usr/lib/perl5/site_perl/5.8.8/LocaleData/it is not owned by any package
file /usr/lib/perl5/site_perl/5.8.8/LocaleData/it/LC_MESSAGES is not owned by any 
package
file /usr/lib/perl5/vendor_perl/5.10.0/LocaleData is not owned by any package
file /usr/lib/perl5/vendor_perl/5.10.0/LocaleData/sr at Latn is not owned by any 
package
file /usr/lib/perl5/vendor_perl/5.10.0/LocaleData/sr at Latn/LC_MESSAGES is not 
owned by any package
file /usr/lib/perl5/vendor_perl/5.10.0/LocaleData/cs is not owned by any package
file /usr/lib/perl5/vendor_perl/5.10.0/LocaleData/cs/LC_MESSAGES is not owned by 
any package
file /usr/lib/perl5/vendor_perl/5.10.0/LocaleData/es is not owned by any package
file /usr/lib/perl5/vendor_perl/5.10.0/LocaleData/es/LC_MESSAGES is not owned by 
any package
file /usr/lib/perl5/vendor_perl/5.10.0/LocaleData/de is not owned by any package
file /usr/lib/perl5/vendor_perl/5.10.0/LocaleData/de/LC_MESSAGES is not owned by 
any package
file /usr/lib/perl5/vendor_perl/5.10.0/LocaleData/sr is not owned by any package
file /usr/lib/perl5/vendor_perl/5.10.0/LocaleData/sr/LC_MESSAGES is not owned by 
any package
file /usr/lib/perl5/vendor_perl/5.10.0/LocaleData/fr is not owned by any package
file /usr/lib/perl5/vendor_perl/5.10.0/LocaleData/fr/LC_MESSAGES is not owned by 
any package
file /usr/lib/perl5/vendor_perl/5.10.0/LocaleData/it is not owned by any package
file /usr/lib/perl5/vendor_perl/5.10.0/LocaleData/it/LC_MESSAGES is not owned by 
any package
file /usr/lib/perl5/vendor_perl/5.8.8 is not owned by any package
file /usr/lib/gconv is not owned by any package
file /usr/lib/udev is not owned by any package
file /usr/src/debug is not owned by any package
file /usr/include/captury is not owned by any package
file /usr/include/gstreamer-0.10 is not owned by any package
file /usr/include/gstreamer-0.10/gst is not owned by any package
file /usr/include/presto is not owned by any package
file /usr/lib64/ruby_lib is not owned by any package
file /usr/lib64/firefox-3.0.2 is not owned by any package
file /usr/lib64/firefox-3.0.2/updates is not owned by any package
file /usr/lib64/firefox-3.0.2/updates/0 is not owned by any package
file /usr/lib64/kde4/plugins/script is not owned by any package
file /usr/lib64/pam_pkcs11 is not owned by any package
file /usr/lib64/kconf_update_bin is not owned by any package
file /usr/lib64/pkcs11 is not owned by any package
file /usr/lib64/exim is not owned by any package
file /usr/lib64/exim/4.69-7.fc10 is not owned by any package
file /usr/lib64/java is not owned by any package
file /usr/lib64/qt4/mkspecs/win32-cross-g++ is not owned by any package
file /usr/lib64/gimp is not owned by any package
file /usr/lib64/gimp/2.0 is not owned by any package
file /usr/lib64/gimp/2.0/interpreters is not owned by any package
file /usr/lib64/xine/plugins/1.20 is not owned by any package
file /usr/lib64/gcj-4.3.0 is not owned by any package
file /usr/lib64/python2.5/site-packages/picard is not owned by any package
file /usr/lib64/python2.5/site-packages/picard/browser is not owned by any 
package
file /usr/lib64/python2.5/site-packages/picard/formats is not owned by any 
package
file /usr/lib64/python2.5/site-packages/picard/formats/mutagenext is not owned by 
any package
file /usr/lib64/python2.5/site-packages/picard/musicdns is not owned by any 
package
file /usr/lib64/python2.5/site-packages/picard/plugins is not owned by any 
package
file /usr/lib64/python2.5/site-packages/picard/plugins/lastfm is not owned by any 
package
file /usr/lib64/python2.5/site-packages/picard/util is not owned by any package
file /usr/lib64/python2.5/site-packages/picard/ui is not owned by any package
file /usr/lib64/python2.5/site-packages/picard/ui/options is not owned by any 
package
file /usr/lib64/python2.5/site-packages/simplejson/tests is not owned by any 
package
file /usr/lib64/rpm is not owned by any package
file /usr/lib64/perl5/vendor_perl/5.8.8 is not owned by any package
file /usr/lib64/udev is not owned by any package
file /usr/lib64/gcj/jakarta-commons-discovery is not owned by any package
file /usr/lib64/gcj/eclipse is not owned by any package
file /usr/lib64/gcj/tomcat5 is not owned by any package
file /usr/lib64/gcj/jdepend is not owned by any package
file /usr/lib64/gcj/jakarta-commons-dbcp is not owned by any package
file /usr/lib64/gcj/xerces-j2 is not owned by any package
file /usr/lib64/gcj/classpathx-jaf is not owned by any package
file /usr/lib64/gcj/jakarta-commons-collections is not owned by any package
file /usr/lib64/gcj/jzlib is not owned by any package
file /usr/lib64/gcj/icu4j is not owned by any package
file /usr/lib64/gcj/log4j is not owned by any package
file /usr/lib64/gcj/classpathx-mail is not owned by any package
file /usr/lib64/php is not owned by any package
file /usr/lib64/php/modules is not owned by any package
file /var/log/mail is not owned by any package
file /var/log/gdm is not owned by any package
file /var/log/setroubleshoot is not owned by any package
file /var/run/sudo/root is not owned by any package
file /var/run/sudo/boeckb is not owned by any package
file /var/run/xdmctl is not owned by any package
file /var/run/xdmctl/dmctl-:0 is not owned by any package
file /var/run/xdmctl/dmctl is not owned by any package
file /var/run/gdm is not owned by any package
file /var/run/pm-utils/pm-powersave is not owned by any package
file /var/run/pm-utils/pm-powersave/storage is not owned by any package
file /var/run/pm-utils/pm-suspend is not owned by any package
file /var/run/pm-utils/pm-suspend/storage is not owned by any package
file /var/run/xauth is not owned by any package
file /var/lib/jetty is not owned by any package
file /var/lib/nfs/rpc_pipefs/statd is not owned by any package
file /var/lib/nfs/rpc_pipefs/portmap is not owned by any package
file /var/lib/nfs/rpc_pipefs/nfs is not owned by any package
file /var/lib/nfs/rpc_pipefs/mount is not owned by any package
file /var/lib/nfs/rpc_pipefs/lockd is not owned by any package
file /var/lib/PackageKit is not owned by any package
file /var/lib/mock/cache is not owned by any package
file /var/lib/authconfig/last is not owned by any package
file /var/lib/kdm is not owned by any package
file /var/lib/gdm is not owned by any package
file /var/lib/gdm/.dbus is not owned by any package
file /var/lib/gdm/.dbus/session-bus is not owned by any package
file /var/lib/gdm/.gconf is not owned by any package
file /var/lib/gdm/.gconf/apps is not owned by any package
file /var/lib/gdm/.gconf/apps/gdm is not owned by any package
file /var/lib/gdm/.gconf/apps/gdm/simple-greeter is not owned by any package
file /var/lib/gdm/.gnome2_private is not owned by any package
file /var/lib/gdm/.gconfd is not owned by any package
file /var/lib/gdm/.gnome2 is not owned by any package
file /var/lib/gdm/.gnome2/accels is not owned by any package
file /var/lib/bluetooth is not owned by any package
file /var/lib/bluetooth/00:1C:26:F7:19:F7 is not owned by any package
file /var/lib/texmf/tex is not owned by any package
file /var/lib/texmf/fonts/map/pdftex is not owned by any package
file /var/lib/texmf/fonts/map/dvips is not owned by any package
file /var/lib/texmf/web2c/metafont is not owned by any package
file /var/lib/texmf/web2c/tex is not owned by any package
file /var/lib/texmf/web2c/pdftex is not owned by any package
file /var/lib/texmf/web2c/xetex is not owned by any package
file /var/lib/texmf/web2c/metapost is not owned by any package
file /var/lib/texmf/web2c/omega is not owned by any package
file /var/lib/texmf/web2c/aleph is not owned by any package




From ivazqueznet at gmail.com  Sat Nov 29 07:01:32 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Sat, 29 Nov 2008 02:01:32 -0500
Subject: Python 2.6 clear for Rawhide
In-Reply-To: <16de708d0811282159u5265f09bwf22d770910fbdbf7@mail.gmail.com>
References: <1227923821.3835.39.camel@ignacio.lan>
	<16de708d0811282159u5265f09bwf22d770910fbdbf7@mail.gmail.com>
Message-ID: <1227942092.3835.54.camel@ignacio.lan>

On Fri, 2008-11-28 at 23:59 -0600, Arthur Pemberton wrote:
> Are there any documents of Fedora's roadmap for Python 2.6 and Python 3?

Nothing written down. 2.6 will be in F11, and 3.0... we'll cross that
particular bridge when we get there.

-- 
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/20081129/0c94e41e/attachment.sig>

From thuforuk at yahoo.co.uk  Sat Nov 29 07:05:12 2008
From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski)
Date: Sat, 29 Nov 2008 00:05:12 -0700
Subject: RFC: Changing default filesystem parameters for power management
 reasons
In-Reply-To: <492FF85F.6060709@redhat.com>
References: <20081127153327.GA21300@srcf.ucam.org>	<492FE124.3030400@redhat.com>	<20081128142209.758238c5@dhcp03.addix.net>
	<492FF85F.6060709@redhat.com>
Message-ID: <4930E9A8.1090803@yahoo.co.uk>

On 11/28/2008 06:55 AM, Phil Knirsch wrote:
> Ralf Ertzinger wrote:
>> Hi.
>>
>> On Fri, 28 Nov 2008 13:16:36 +0100, Phil Knirsch wrote:
>>
>>> Sounds like a good idea. It's also something i've been looking at a
>>> bit. Take e.g. something like xchat. If you enable logging there you 
>>> basically keep your disc active all the time as xchat itself doesn't
>>> use a large internal cache to write the data out every X MB or so.
>>
>> And why should it, honestly? Bufffering data ist the OSes job 99% of
>> the time. As long as xchat does not use fsync() after each write we
>> should be good.
>>
>
> Maybe i wasn't clear enough. But take for example the difference 
> between xchat and say, syslog. I'd be really unhappy if i'd loose 1 
> hour of syslog data in the event of a system crash, but i couldn't 
> care less if i'd loose 1 hour of xchatlogs during that time.

Depends on the point of view -- take Joe The User who carries "Important 
Conversation" of which he wants to have a log. He cares a lot that he 
lost last hour of his xchat (or whatever he uses) logs. He quite likely 
doesn't care about last hour of syslog messages (he may not even be 
aware they exist in the first place)...

Regards,
Dariusz



		
___________________________________________________________ 
Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html



From lemenkov at gmail.com  Sat Nov 29 07:53:35 2008
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Sat, 29 Nov 2008 10:53:35 +0300
Subject: PulseAudio info needed
In-Reply-To: <f6ca9fed0811280748h4bdc363aoe591de4f2fdd78c@mail.gmail.com>
References: <200811271301.11802.cannewilson@googlemail.com>
	<492E9B4B.4000206@redhat.com>
	<adf480660811270533m7ba4be5ctd1e98359ed8800dd@mail.gmail.com>
	<f6ca9fed0811280714j40846429o2930d127b232c15e@mail.gmail.com>
	<adf480660811280728v17ff6d4ah9b0ca9b8bf5513b2@mail.gmail.com>
	<f6ca9fed0811280748h4bdc363aoe591de4f2fdd78c@mail.gmail.com>
Message-ID: <adf480660811282353r50af38d7wbc35878e00d6ec5a@mail.gmail.com>

2008/11/28, drago01 <drago01 at gmail.com>:

> For example device hotplug is something that people expect from a
>  modern operating system.

Modern operating system is sometimes installed on modern hardware
platform, that means that there is no need in hotplugging of devices
which functionality is already included in 99% of cases (except the
case with bluetooth audio - bluetooth phone sets is the different
case). Yes, I repeat - PA need in a very little amount of cases (I
mean - you should use different distro).

> they support a subset of what pa is doing besides they have a
>  different goal than pa (pa isn't "just another sound server")

I still insist - you should learn more about already shipped and
stable solutions.

>  btw you are trying to solve the problem in the wrong way:
>  "app A has bugs, don't ship it" vs "app A has bugs, find the causes
>  and fix them"

More than 5 years ago I've got a experience in deploying
multimedia-server for multiroom systems, and I still remember
something regarding this development area. Even in 2002 JACK already
has a ability to combine different audio cards into one or split into
many. Since then it receives the ability of networking sound.

>From my PoV, there is no need to create something from the ground
(thus repeating numerous error, which already fixed many times) except
the case then you're not the guy with NIH syndrome. More easiest way
is to help to  add some functionality to already existed mature
project (btw JACK included in Fedora).

I believe is that Fedora may have great benefits from JACK as a
defauld soundserver. Too sad, that Fedora heads decided to write
something from scratch. I still wonder why (probably - it's another
example of poor development management).

However its still not too late to drop this semi-working student's
cheap stuff in favor of something more reliable.


-- 
With best regards!



From lemenkov at gmail.com  Sat Nov 29 07:55:06 2008
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Sat, 29 Nov 2008 10:55:06 +0300
Subject: PulseAudio info needed
In-Reply-To: <68720af30811281633qcae1650o4f50ba2e90abaafa@mail.gmail.com>
References: <200811271301.11802.cannewilson@googlemail.com>
	<492E9B4B.4000206@redhat.com>
	<adf480660811270533m7ba4be5ctd1e98359ed8800dd@mail.gmail.com>
	<f6ca9fed0811280714j40846429o2930d127b232c15e@mail.gmail.com>
	<adf480660811280728v17ff6d4ah9b0ca9b8bf5513b2@mail.gmail.com>
	<79r506xajr.ln2@ppp1053.in.ipex.cz>
	<20081128204400.GA23162@mokona.greysector.net>
	<68720af30811281633qcae1650o4f50ba2e90abaafa@mail.gmail.com>
Message-ID: <adf480660811282355l4c1d383egeecac85e54915a2e@mail.gmail.com>

2008/11/29, Paulo Cavalcanti <promac at gmail.com>:

> > > Actually, I do switch between headphones and speakers all the
> > > time and I found it pretty useful.

> > I don't know about your setup, but both my stereo and my laptop
> > disable the speakers when I plug in the headphones. I don't know
> > where PulseAudio comes in here.

> You need two sound cards.

That's not a prevailing configuration.

-- 
With best regards!



From wolfy at nobugconsulting.ro  Sat Nov 29 08:53:44 2008
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Sat, 29 Nov 2008 10:53:44 +0200
Subject: Unowned directories
In-Reply-To: <200811290123.53933.MathStuf@gmail.com>
References: <200811290123.53933.MathStuf@gmail.com>
Message-ID: <49310318.3070309@nobugconsulting.ro>

On 11/29/2008 08:23 AM, Ben Boeckel wrote:
> Hi,
>
> I did the following command to find unowned directories (edited from my actual 
> command to get rid of stuff like tmp that came up with lots of false-positives?
> though it is quite possible there still are some here):
>
> # rpm -q --whatprovides `find /{{,s}bin,boot,dev,etc,lib{,64},usr} -type d` | 
> grep -v -e .x86_64 -e noarch -e i386 -e i686 -e ppc
>   
I suggest repeating the test but filtering out symlinks. And especially 
stuff managed by alternatives.




From pemboa at gmail.com  Sat Nov 29 09:10:17 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Sat, 29 Nov 2008 03:10:17 -0600
Subject: Python 2.6 clear for Rawhide
In-Reply-To: <1227942092.3835.54.camel@ignacio.lan>
References: <1227923821.3835.39.camel@ignacio.lan>
	<16de708d0811282159u5265f09bwf22d770910fbdbf7@mail.gmail.com>
	<1227942092.3835.54.camel@ignacio.lan>
Message-ID: <16de708d0811290110y2fa1593eo6c1d6ef5888d6404@mail.gmail.com>

2008/11/29 Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> On Fri, 2008-11-28 at 23:59 -0600, Arthur Pemberton wrote:
>> Are there any documents of Fedora's roadmap for Python 2.6 and Python 3?
>
> Nothing written down. 2.6 will be in F11, and 3.0... we'll cross that
> particular bridge when we get there.


Okay, sweet. Was actually expecting it in F10. But i guess the timing
was too close.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From mschwendt at gmail.com  Sat Nov 29 09:21:45 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sat, 29 Nov 2008 10:21:45 +0100
Subject: Unowned directories
In-Reply-To: <200811290123.53933.MathStuf@gmail.com>
References: <200811290123.53933.MathStuf@gmail.com>
Message-ID: <20081129102145.b4d83f21.mschwendt@gmail.com>

On Sat, 29 Nov 2008 01:23:53 -0500, Ben Boeckel wrote:

> Hi,
> 
> I did the following command to find unowned directories (edited from my actual 
> command to get rid of stuff like tmp that came up with lots of false-positives?
> though it is quite possible there still are some here):
> 
> # rpm -q --whatprovides `find /{{,s}bin,boot,dev,etc,lib{,64},usr} -type d` | 
> grep -v -e .x86_64 -e noarch -e i386 -e i686 -e ppc
> 
> There were too many to consider doing a bug report for each,

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.

Some in your list most likely are false positives, however:

  $ rpm -qf /etc/selinux/targeted/contexts
  selinux-policy-targeted-3.3.1-107.fc9.noarch

My last check of unowned dirs didn't flag that one (note that I examine
the repo metadata under consideration of basic depsolving, but not
including any core group yet).

Other findings are false positives because a directory itself _is_ owned
by a package, but during package upgrade/removal RPM refuses to remove
the directory if it isn't empty:

> file /usr/lib64/firefox-3.0.2 is not owned by any package

That happens if (1) other packages store files in it without owning the
directory or without requiring a package that owns it, or (2) files in it
are created at run-time and don't belong into any package. Advanced packages
mark any such files as %ghost.

> emails to fedora-devel-announce and CC maintainers of suspected owners (looking 
> at owners of files in the directory, sibling files)?

Will give mixed results. Some package owners are very good at ignoring
private mail, because they insist on receiving problem reports in bugzilla.
Others cannot handle all their bz tickets. Also be prepared that some simply
don't understand the problem or refuse to think about it.

It would be good if we could use bugzilla for tracking these issue (and
not be disturbed by triagers), because recently I've simply gone into
cvs to fix aging issues myself in the devel tree.

Anyway, quite a lot are valid findings I think, and I believe there are
more, because my list seems longer+different. ;) I compared some with
my list, not limited to:

> file /etc/hotplug.d is not owned by any package
> file /etc/hotplug.d/usb is not owned by any package

=> gpsd-2.37-2.fc9.i386 (rawhide-development-i386)
/etc/hotplug.d
/etc/hotplug.d/usb

> file /usr/share/doc/jetty-5.1.14 is not owned by any package
> file /var/lib/jetty is not owned by any package

=> jetty-5.1.14-1.6.fc10.i386 (rawhide-development-i386)
/var/cache/jetty
/var/lib/jetty
/etc/logrotate.d
/usr/share/doc/jetty-5.1.14

=> jetty-javadoc-5.1.14-1.6.fc10.i386 (rawhide-development-i386)
/var/lib/jetty
/var/lib/jetty/webapps



From drago01 at gmail.com  Sat Nov 29 09:41:36 2008
From: drago01 at gmail.com (drago01)
Date: Sat, 29 Nov 2008 10:41:36 +0100
Subject: PulseAudio info needed
In-Reply-To: <adf480660811282353r50af38d7wbc35878e00d6ec5a@mail.gmail.com>
References: <200811271301.11802.cannewilson@googlemail.com>
	<492E9B4B.4000206@redhat.com>
	<adf480660811270533m7ba4be5ctd1e98359ed8800dd@mail.gmail.com>
	<f6ca9fed0811280714j40846429o2930d127b232c15e@mail.gmail.com>
	<adf480660811280728v17ff6d4ah9b0ca9b8bf5513b2@mail.gmail.com>
	<f6ca9fed0811280748h4bdc363aoe591de4f2fdd78c@mail.gmail.com>
	<adf480660811282353r50af38d7wbc35878e00d6ec5a@mail.gmail.com>
Message-ID: <f6ca9fed0811290141h24c06857h7f759de76489fcf8@mail.gmail.com>

On Sat, Nov 29, 2008 at 8:53 AM, Peter Lemenkov <lemenkov at gmail.com> wrote:
> 2008/11/28, drago01 <drago01 at gmail.com>:
>
>> For example device hotplug is something that people expect from a
>>  modern operating system.
>
> Modern operating system is sometimes installed on modern hardware
> platform, that means that there is no need in hotplugging of devices
> which functionality is already included in 99% of cases (except the
> case with bluetooth audio - bluetooth phone sets is the different
> case). Yes, I repeat - PA need in a very little amount of cases (I
> mean - you should use different distro).

err what? people that want to use bluetooth audio devices should just
use another distro?
sorry but I disagree here, we can't tell people "your hardware is no
longer supported by fedora, go use a different distro"



From wolfy at nobugconsulting.ro  Sat Nov 29 09:57:25 2008
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Sat, 29 Nov 2008 11:57:25 +0200
Subject: wrong dependency chain ?
Message-ID: <49311205.2080504@nobugconsulting.ro>

    While trying to do review for 
https://bugzilla.redhat.com/show_bug.cgi?id=473218 I found out that mock 
builds for rawhides bail out because of

Error: Missing Dependency: dejavu-lgc-fonts is needed by package rrdtool

  The same error is triggered by a koi scratch build. OTOH, dist-f11 
works just fine. Any idea why is rrdtool pulled in the the first place 
and why are the fonts missing ?



From mcepl at redhat.com  Sat Nov 29 10:15:59 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Sat, 29 Nov 2008 11:15:59 +0100
Subject: PulseAudio info needed
References: <200811271301.11802.cannewilson@googlemail.com>
	<492E9B4B.4000206@redhat.com>
	<adf480660811270533m7ba4be5ctd1e98359ed8800dd@mail.gmail.com>
	<f6ca9fed0811280714j40846429o2930d127b232c15e@mail.gmail.com>
	<adf480660811280728v17ff6d4ah9b0ca9b8bf5513b2@mail.gmail.com>
	<f6ca9fed0811280748h4bdc363aoe591de4f2fdd78c@mail.gmail.com>
	<adf480660811282353r50af38d7wbc35878e00d6ec5a@mail.gmail.com>
Message-ID: <vbh706x7du.ln2@ppp1053.in.ipex.cz>

On 2008-11-29, 07:53 GMT, Peter Lemenkov wrote:
> I believe is that Fedora may have great benefits from JACK as a
> defauld soundserver. Too sad, that Fedora heads decided to write
> something from scratch. I still wonder why (probably - it's another
> example of poor development management).

What about reading about the reasons mezcalero many times 
provided in many fora instead of spreading the FUD?

Mat?j



From nicolas.mailhot at laposte.net  Sat Nov 29 10:36:39 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 29 Nov 2008 11:36:39 +0100
Subject: wrong dependency chain ?
In-Reply-To: <49311205.2080504@nobugconsulting.ro>
References: <49311205.2080504@nobugconsulting.ro>
Message-ID: <1227954999.18716.4.camel@arekh.okg>

Le samedi 29 novembre 2008 ? 11:57 +0200, Manuel Wolfshant a ?crit :
> While trying to do review for 
> https://bugzilla.redhat.com/show_bug.cgi?id=473218 I found out that mock 
> builds for rawhides bail out because of
> 
> Error: Missing Dependency: dejavu-lgc-fonts is needed by package rrdtool
> 
>   The same error is triggered by a koi scratch build. OTOH, dist-f11 
> works just fine. Any idea why is rrdtool pulled in the the first place 
> and why are the fonts missing ?

The dejavu-lgc-fonts package does not exist in F11 anymore. Since the
number of packages depending on it should be small (if not nill, you're
forcing install of LGC when most users will already have DejaVu full on
their system) it was obsoleted without providing the old packagename.

Please add the correct deps to your packages
http://koji.fedoraproject.org/koji/buildinfo?buildID=68927

PS the compat packages are only there to help users upgrade, they'll be
killed in F12 cycle and packagers that add deps on them will get what
they deserve.

-- 
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/20081129/fae05526/attachment.sig>

From mschwendt at gmail.com  Sat Nov 29 10:38:03 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sat, 29 Nov 2008 11:38:03 +0100
Subject: wrong dependency chain ?
In-Reply-To: <49311205.2080504@nobugconsulting.ro>
References: <49311205.2080504@nobugconsulting.ro>
Message-ID: <20081129113803.5f2a6093.mschwendt@gmail.com>

On Sat, 29 Nov 2008 11:57:25 +0200, Manuel Wolfshant wrote:

>     While trying to do review for 
> https://bugzilla.redhat.com/show_bug.cgi?id=473218 I found out that mock 
> builds for rawhides bail out because of
> 
> Error: Missing Dependency: dejavu-lgc-fonts is needed by package rrdtool
> 
>   The same error is triggered by a koi scratch build. OTOH, dist-f11 
> works just fine. Any idea why is rrdtool pulled in the the first place 
> and why are the fonts missing ?

You can examine that with "repoquery":

# sudo repoquery --enablerepo=rawhide --whatrequires rrdtool-perl --alldeps|grep perl
perl-RRD-Simple-0:1.43-3.fc9.noarch
perl-Collectd-0:4.4.4-1.fc9.i386
perl-Collectd-0:4.4.4-2.fc10.i386
perl-Log-Log4perl-0:1.13-2.fc9.noarch

Notice the last one.

dejavu-lgc-fonts is dead, and dejavu-fonts "Obsoletes" it, but doesn't "Provides" it.



From wolfy at nobugconsulting.ro  Sat Nov 29 10:54:56 2008
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Sat, 29 Nov 2008 12:54:56 +0200
Subject: wrong dependency chain ?
In-Reply-To: <1227954999.18716.4.camel@arekh.okg>
References: <49311205.2080504@nobugconsulting.ro>
	<1227954999.18716.4.camel@arekh.okg>
Message-ID: <49311F80.4040002@nobugconsulting.ro>

On 11/29/2008 12:36 PM, Nicolas Mailhot wrote:
> Le samedi 29 novembre 2008 ? 11:57 +0200, Manuel Wolfshant a ?crit :
>   
>> While trying to do review for 
>> https://bugzilla.redhat.com/show_bug.cgi?id=473218 I found out that mock 
>> builds for rawhides bail out because of
>>
>> Error: Missing Dependency: dejavu-lgc-fonts is needed by package rrdtool
>>
>>   The same error is triggered by a koi scratch build. OTOH, dist-f11 
>> works just fine. Any idea why is rrdtool pulled in the the first place 
>> and why are the fonts missing ?
>>     
>
> The dejavu-lgc-fonts package does not exist in F11 anymore. Since the
> number of packages depending on it should be small (if not nill, you're
> forcing install of LGC when most users will already have DejaVu full on
> their system) it was obsoleted without providing the old packagename.
>
> Please add the correct deps to your packages
> http://koji.fedoraproject.org/koji/buildinfo?buildID=68927
>
> PS the compat packages are only there to help users upgrade, they'll be
> killed in F12 cycle and packagers that add deps on them will get what
> they deserve.
>
>   
https://bugzilla.redhat.com/show_bug.cgi?id=473550
Thank you Nicholas and Michael





From paul at all-the-johnsons.co.uk  Sat Nov 29 11:07:37 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Sat, 29 Nov 2008 11:07:37 +0000
Subject: Before I do something silly, can someone give me some advice on an
 lvm partition?
Message-ID: <1227956857.31448.2.camel@PB3.Linux>

Hi,

I have a 149Gb lvm partition on /dev/sda2. I've no idea what's in there.
My /home directory is on a different drive. /dev/sda1 has the OS on it
(it's 200Mb). I have a feeling that the likes of /usr and /var are on
the lvm partition. Is there anything I can use to check 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/20081129/2f12710b/attachment.sig>

From wolfy at nobugconsulting.ro  Sat Nov 29 11:33:02 2008
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Sat, 29 Nov 2008 13:33:02 +0200
Subject: Before I do something silly, can someone give me some advice
 on an lvm partition?
In-Reply-To: <1227956857.31448.2.camel@PB3.Linux>
References: <1227956857.31448.2.camel@PB3.Linux>
Message-ID: <4931286E.7000703@nobugconsulting.ro>

On 11/29/2008 01:07 PM, Paul wrote:
> Hi,
>
> I have a 149Gb lvm partition on /dev/sda2. I've no idea what's in there.
> My /home directory is on a different drive. /dev/sda1 has the OS on it
> (it's 200Mb). I have a feeling that the likes of /usr and /var are on
> the lvm partition. Is there anything I can use to check this?
>   

lvdisplay, ls /dev/mapper ....
usually anaconda places the OS in a LVM and swap in another one , but 
since you claim that your root dir is on sda1, I do not know. Anyway, I 
doubt that all the OS is inside a 200 MB partition, more likely /boot is 
there while the rest of the OS is inside the LVM



From rjones at redhat.com  Sat Nov 29 12:19:57 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 29 Nov 2008 12:19:57 +0000
Subject: Unowned directories
In-Reply-To: <20081129102145.b4d83f21.mschwendt@gmail.com>
References: <200811290123.53933.MathStuf@gmail.com>
	<20081129102145.b4d83f21.mschwendt@gmail.com>
Message-ID: <20081129121957.GA17701@amd.home.annexia.org>

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.

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 rawhide at fedoraproject.org  Sat Nov 29 13:06:59 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sat, 29 Nov 2008 13:06:59 +0000 (UTC)
Subject: rawhide report: 20081129 changes
Message-ID: <20081129130700.1953D1F8252@releng2.fedora.phx.redhat.com>

Compose started at Sat Nov 29 06:01:07 UTC 2008

New package cddlib
        A library for generating all vertices in convex polyhedrons
Updated Packages:

GeoIP-1.4.5-2.fc11
------------------
* Sat Nov 29 17:00:00 2008 Michael Fleming <mfleming+rpm at enlartenment.com> 1.4.5-2
- Update to 1.4.5
- Fix database URL locations in Perl helper scripts


avant-window-navigator-0.2.6-10.fc11
------------------------------------
* Fri Nov 28 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com - 0.2.6-10
- rebuild for dependencies


batik-1.7-0.7
-------------
* Fri Nov 28 17:00:00 2008 Lillian Angel <langel at redhat.com> - 1.7-0.7
- Fixed BASE_JARS in batik.rasterizer.script.
- Resolves: rhbz#455397


bigboard-0.6.4-3.fc11
---------------------
* Fri Nov 28 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 0.6.4-3
- rebuild for dependancies


deskbar-applet-2.25.1-2.fc11
----------------------------
* Fri Nov 28 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 2.25.1-2
- rebuild for dependancies

* Mon Nov 10 17:00:00 2008 Luke Macken <lmacken at redhat.com> - 2.25.1-1
- Update to the latest development version.


desktop-data-model-1.2.5-2.fc11
-------------------------------
* Fri Nov 28 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1.2.5-2
- rebuild for dependancies


docbook-utils-0.6.14-15.fc11
----------------------------
* Fri Nov 28 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> 0.6.14-15
- require grep,gawk, fix jw script to find SGML_BASE_DIR even
  with grep with colors(#473278), finish funcsynopsis patch
  drop


epdfview-0.1.6-5.fc11
---------------------
* Fri Nov 28 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 0.1.6-5
- rebuild for dependencies


galeon-2.0.7-3.fc11
-------------------
* Fri Nov 28 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 2.0.7-3
- rebuild for dependencies


gdesklets-0.36.1-3.fc11
-----------------------

gforth-0.7.0-2.fc11
-------------------
* Fri Nov 28 17:00:00 2008 Gerard Milmeister <gemi at bluewin.ch> - 0.7.0-2
- fixed license


gnome-compiz-manager-0.10.4-6.fc11
----------------------------------
* Fri Nov 28 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> 0.10.4-6
- rebuild for dependencies

* Wed Jul 23 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.10.4-5
- fix license tag


gnome-launch-box-0.4-12.fc11
----------------------------
* Fri Nov 28 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 0.4-12
- rebuild for dependencies

* Wed Jul 23 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.4-11
- fix license tag


hunspell-en-0.20081127-2.fc11
-----------------------------
* Thu Nov 27 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20081127-2
- abbrevs are always stripped out from US/CA dicts
- some single characters are missing from en_GB

* Thu Nov 27 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20081127-1
- hardcoded path dropped upstream


hunspell-sc-0.20081101-1.fc11
-----------------------------
* Fri Nov 28 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20081101-1
- latest version


inkscape-0.46-7.fc11
--------------------
* Fri Nov 28 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 0.46-7
- rebuild for dependencies


libp11-0.2.3-4.fc11
-------------------
* Fri Nov 28 17:00:00 2008 Adam Tkac <atkac redhat com> - 0.2.3-4
- rebuild against new libltdl


libprojectM-qt-1.2.0-3.fc11
---------------------------

libpst-0.6.22-1.fc11
--------------------
* Fri Nov 28 17:00:00 2008 Carl Byington <carl at five-ten-sg.com> - 0.6.22-1
- patch from David Cuadrado to process emails with type PST_TYPE_OTHER
- base64_encode_multiple() may insert newline, needs larger malloc
- subject lines shorter than 2 bytes could segfault


loudmouth-1.4.3-3.fc11
----------------------
* Fri Nov 28 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 1.4.3-3
- Add patch to search correct location for ssl certs. (#473458)
- Add patch to fix async assertion. (#473436)


mlocate-0.21.1-2
----------------
* Fri Nov 28 17:00:00 2008 Miloslav Trma?? <mitr at redhat.com> - 0.21.1-2
- Add .git to PRUNENAMES
  Resolves: #473227
- Avoid a rpmlint warning


nautilus-search-tool-0.2.2-6.fc11
---------------------------------
* Fri Nov 28 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 0.2.2-6
- rebuild for dependancies

* Sat Nov 22 17:00:00 2008 Paul W. Frields <stickster at gmail.com> - 0.2.2-5
- Fix summary


nautilus-sound-converter-0.7.0-3.fc11
-------------------------------------
* Fri Nov 28 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.7.0-3
- Fix typo in patch.

* Fri Nov 28 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.7.0-2
- Add patch to use mime from *.oga files.


padevchooser-0.9.4-0.7.svn20070925.fc11
---------------------------------------
* Fri Nov 28 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 0.9.4-0.7.svn20070925
- rebuild for dependancies


pdfcube-0.0.2-9.fc11
--------------------
* Fri Nov 28 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 0.0.2-9
- rebuild for dependencies


perl-5.10.0-51.fc11
-------------------
* Fri Nov 28 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 4:5.10.0-51
- to fix Fedora bz 473223, which is really perl bug #54186 (http://rt.perl.org/rt3//Public/Bug/Display.html?id=54186)
  we apply Changes 33640, 33881, 33896, 33897

* Mon Nov 24 17:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> - 4:5.10.0-50
- change summary according to RFC fix summary discussion at fedora-devel :)


perl-BDB-1.81-1.fc11
--------------------
* Fri Nov 28 17:00:00 2008 kwizart < kwizart at gmail.com > - 1.81-1
- Update to 1.81


perl-Date-Manip-5.54-1.fc11
---------------------------
* Wed Nov 26 17:00:00 2008 Stepan Kasal <skasal at redhat.com> - 5.54-1
- new upstream version
- add BuildRequires so that testsuite can be fully executed


perl-Locale-Maketext-Lexicon-0.75-1.fc11
----------------------------------------
* Sat Nov 29 17:00:00 2008 Ralf Cors??pius <corsepiu at fedoraproject.org> - 0.75-1
- Upstream update.
- Reflect upstream maintainer having changed.
- BR: perl(Template), BR: perl(Test::Pod).


perl-Params-Util-0.35-1.fc11
----------------------------
* Sat Nov 29 17:00:00 2008 Ralf Cors??pius <corsepiu at fedoraproject.org> - 0.35-1
- Upstream update.
- Remove BuildArch: noarch (package now is arch'ed).
- Remove testsuite hack to accept perl(Test::CPAN::Meta) != 0.07.


phpMyAdmin-3.1.0-1.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Robert Scheck <robert at fedoraproject.org> 3.1.0-1
- Upstream released 3.1.0
- Replaced LocationMatch with Directory directive (#469451)


projectM-jack-1.2.0-4.fc11
--------------------------

projectM-libvisual-1.2.0-4.fc11
-------------------------------

pspp-0.6.1-1.fc11
-----------------
* Fri Nov 28 17:00:00 2008 Mat??j Cepl <mcepl at redhat.com> 0.6.1-1
- New upstream release.
- Added home made logo.
- Fix file permissions.

* Wed Nov 12 17:00:00 2008 Mat??j Cepl <mcepl at redhat.com> - 0.6.0-9
- Fix in the %preun script -- install-info wants only .info file
  as an argument.


python-kerberos-1.1-1.fc11
--------------------------
* Thu Nov 27 17:00:00 2008 Simo Sorce <ssorce at redhat.com> - 1.1-1
- New Upstream Release
- Remove patches as this version has them included already


quassel-0.3.1-1.fc11
--------------------
* Fri Nov 28 17:00:00 2008 Steven M. Parrish <smparrish at shallowcreek.net> 0.3.1-1
- New upstream release


sugar-0.83.3-3.fc11
-------------------

tagtool-0.12.3-5.fc11
---------------------
* Fri Nov 28 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.12.3-5
- Add patch to support *.oga files.


tellico-1.3.4-2.fc11
--------------------
* Fri Nov 28 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1.3.4-2
- rebuild for dependencies


tracker-0.6.6-4.fc11
--------------------
* Fri Nov 28 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 0.6.6-4
- rebuild for dependancies


ufraw-0.14.1-1.fc11
-------------------
* Fri Nov 28 17:00:00 2008 Nils Philippsen <nils at redhat.com> - 0.14.1-1
- version 0.14.1
- use %bcond_with/without macros
- enable building with lensfun from F11 on


unbound-1.1.1-2.fc11
--------------------
* Fri Nov 28 17:00:00 2008 Adam Tkac <atkac redhat com> - 1.1.1-2
- removed all obsolete chroot related stuff
- label control certs after generation correctly


xfce4-sensors-plugin-0.10.99.6-1.fc11
-------------------------------------
* Thu Nov 27 17:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.10.99.6-1
- Update to 0.10.99.6
- Remove obsolete lm_sensors patch
- BuildRequire hddtemp and make sure it's path is detected correctly
- Update gtk-update-icon-cache scriptlets


xorg-x11-drv-radeonhd-1.2.3-1.6.20081128git.fc11
------------------------------------------------
* Fri Nov 28 17:00:00 2008 Hans Ulrich Niedermann <hun at n-dimensional.de> - 1.2.3-1.6.20081128git
- New snapshot (upstream commit 8edc0c698bc225a0581d4e17820f28efb4db97df):
  - 8edc0c69: BugFix for RandR cursor interface
  - 48f9d1af: DIG: Remove stray ErrorFs
  - 078842c7: ID: 0x7187:0x1458:0x215C has a  DMS59 connector.
  - dc81290f: Rotation: document limitations in man page.
  - d4c49758: Rotation: NULL callbacks to rotation functions if no HW acceleration is enabled.
  - 66f4a3a6: Rotation: Don't allow to set a PANNING_AREA when rotated.
  - 5b9ef245: Rotation: Fix up Crtc base pointer.
  - 23bc497c: Rotation: Remove USE_XAA which had been left over from rebasing.
  - 24ba47d9: RandR: Some minor cleanup.
  - e304e561: HW Cursor: Add RandR cursor interface.
  - c1827740: RandR: Add screen rotation.
  - 41d4bf71: RandR: Initialise the LUT on a new CRTC.
  - c2dfeafe: DRI: Bail DRILeave/EnterVT() when drmFD == -1.
  - def3c1f5: DIG: Add debug code.
  - ad876362: rhd_conntest: Make rhd_conntest work on FreeBSD.
  - 10dc7797: ID: Add HPD_OFF flag for Foxconn A7GM-S (RS780) motherboard.
  - 4d65e4c6: DRI/CS: Set drmFD to -1 after closing the device.
  - 65f01922: AtomBIOS/BacklightControl: Add destroy function for data structure and fixes.


Summary:
Added Packages: 1
Removed Packages: 0
Modified Packages: 44
Broken deps for i386
----------------------------------------------------------
	autodir-0.99.9-5.fc9.i386 requires libltdl.so.3
	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
	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-zimbra-0.1.1-3.fc10.i386 requires libcamel-1.2.so.14
	evolution-zimbra-0.1.1-3.fc10.i386 requires libcamel-provider-1.2.so.14
	foobillard-3.0a-8.fc10.i386 requires dejavu-fonts
	freeradius-2.1.1-2.fc10.i386 requires libltdl.so.3
	gambas2-devel-2.9.0-1.fc10.i386 requires libltdl.so.3
	gambas2-gb-pdf-2.9.0-1.fc10.i386 requires libpoppler.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
	kdebindings-4.1.2-2.fc10.i386 requires libqscintilla2.so.4
	libextractor-0.5.20b-2.fc10.i386 requires libltdl.so.3
	mail-notification-evolution-plugin-5.4-4.fc10.i386 requires libcamel-1.2.so.14
	mail-notification-evolution-plugin-5.4-4.fc10.i386 requires libcamel-provider-1.2.so.14
	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
	mono-cecil-flowanalysis-0.1-0.6.20080409svn100264.fc11.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	mono-tools-2.0-8.fc10.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	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
	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-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts-experimental
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts
	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
----------------------------------------------------------
	autodir-0.99.9-5.fc9.x86_64 requires libltdl.so.3()(64bit)
	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
	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-zimbra-0.1.1-3.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	evolution-zimbra-0.1.1-3.fc10.x86_64 requires libcamel-provider-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)
	gambas2-devel-2.9.0-1.fc10.i386 requires libltdl.so.3
	gambas2-devel-2.9.0-1.fc10.x86_64 requires libltdl.so.3()(64bit)
	gambas2-gb-pdf-2.9.0-1.fc10.x86_64 requires libpoppler.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
	kdebindings-4.1.2-2.fc10.i386 requires libqscintilla2.so.4
	kdebindings-4.1.2-2.fc10.x86_64 requires libqscintilla2.so.4()(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)
	mail-notification-evolution-plugin-5.4-4.fc10.x86_64 requires libcamel-1.2.so.14()(64bit)
	mail-notification-evolution-plugin-5.4-4.fc10.x86_64 requires libcamel-provider-1.2.so.14()(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)
	mono-cecil-flowanalysis-0.1-0.6.20080409svn100264.fc11.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	mono-tools-2.0-8.fc10.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	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)
	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-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts-experimental
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts
	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
----------------------------------------------------------
	autodir-0.99.9-5.fc9.ppc requires libltdl.so.3
	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
	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-zimbra-0.1.1-3.fc10.ppc requires libcamel-1.2.so.14
	evolution-zimbra-0.1.1-3.fc10.ppc requires libcamel-provider-1.2.so.14
	firstaidkit-plugin-grub-0.2.2-1.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
	kdebindings-4.1.2-2.fc10.ppc requires libqscintilla2.so.4
	kdebindings-4.1.2-2.fc10.ppc64 requires libqscintilla2.so.4()(64bit)
	libextractor-0.5.20b-2.fc10.ppc requires libltdl.so.3
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	mail-notification-evolution-plugin-5.4-4.fc10.ppc requires libcamel-1.2.so.14
	mail-notification-evolution-plugin-5.4-4.fc10.ppc requires libcamel-provider-1.2.so.14
	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)
	mono-cecil-flowanalysis-0.1-0.6.20080409svn100264.fc11.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	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
	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-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts-experimental
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts
	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
----------------------------------------------------------
	autodir-0.99.9-5.fc9.ppc64 requires libltdl.so.3()(64bit)
	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
	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-zimbra-0.1.1-3.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	evolution-zimbra-0.1.1-3.fc10.ppc64 requires libcamel-provider-1.2.so.14()(64bit)
	firstaidkit-plugin-grub-0.2.2-1.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
	kdebindings-4.1.2-2.fc10.ppc64 requires libqscintilla2.so.4()(64bit)
	libextractor-0.5.20b-2.fc10.ppc64 requires libltdl.so.3()(64bit)
	mail-notification-evolution-plugin-5.4-4.fc10.ppc64 requires libcamel-1.2.so.14()(64bit)
	mail-notification-evolution-plugin-5.4-4.fc10.ppc64 requires libcamel-provider-1.2.so.14()(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)
	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-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts-experimental
	perl-PDF-API2-0.72-1.fc11.noarch requires dejavu-fonts
	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 mcepl at redhat.com  Sat Nov 29 13:37:20 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Sat, 29 Nov 2008 14:37:20 +0100
Subject: Before I do something silly, can someone give me some advice on
 an lvm partition?
References: <1227956857.31448.2.camel@PB3.Linux>
Message-ID: <g5t706xfm5.ln2@ppp1053.in.ipex.cz>

On 2008-11-29, 11:07 GMT, Paul wrote:
> I have a 149Gb lvm partition on /dev/sda2. I've no idea what's 
> in there.
> My /home directory is on a different drive. /dev/sda1 has the OS on it
> (it's 200Mb). I have a feeling that the likes of /usr and /var are on
> the lvm partition. Is there anything I can use to check this?

What's wrong with

mkdir /mnt/test-partition
mount /dev/mapper/<partition> /mnt/test-partition

and then take a look? (maybe mount --bind maybe in order, if the 
partition is mounted somewhere else)

Mat?j



From valent.turkovic at gmail.com  Sat Nov 29 13:51:33 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Sat, 29 Nov 2008 14:51:33 +0100
Subject: Fedora 10 on Asus eee 701 feedback
Message-ID: <64b14b300811290551xfdeda60oeec3b0e826a9563@mail.gmail.com>

I would just to drop a few comments on using Fedora 10 on my little Asus 701.

I'm impressed how well installation went and how it work nice in
fullscreen on eee's small 7" screen.

After installing I had issues with wireless and webcam. I can start
cheese and I can see the led turn on but I don't see anything in
cheese window.

Wireless worked out-of-the-box with new ath5k module and I could see
all networks and connected to my WPA network but I can't surf web
sites :(

I tried pinging my adls router and I get a lot of drop packages and
ping times over 2000ms :(

After compiling madwifi-hal and blacklisting ath5k wireless started
working perfectly.

I also tried "Connection sharing" with eee conected through wire and
created a new wireless connection for others to connect to. I tried
with one client to connect to asus eee AP but it also got a lot of
dropped packages :(

I posted a bug for this:
https://bugzilla.redhat.com/show_bug.cgi?id=473576

Are there any asus eee users that have similar experience? Any
tips/tricks for us eee users?

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 pbrobinson at gmail.com  Sat Nov 29 14:07:39 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Sat, 29 Nov 2008 14:07:39 +0000
Subject: Fedora 10 on Asus eee 701 feedback
In-Reply-To: <64b14b300811290551xfdeda60oeec3b0e826a9563@mail.gmail.com>
References: <64b14b300811290551xfdeda60oeec3b0e826a9563@mail.gmail.com>
Message-ID: <5256d0b0811290607x1775563aw7060e3829ed377b7@mail.gmail.com>

> Are there any asus eee users that have similar experience? Any
> tips/tricks for us eee users?

Does your SD card slot work?

Peter



From paul at all-the-johnsons.co.uk  Sat Nov 29 14:09:11 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Sat, 29 Nov 2008 14:09:11 +0000
Subject: Strange patch problem (not being fully applied)
Message-ID: <1227967751.31448.11.camel@PB3.Linux>

Hi,

I'm trying to get mono-tools-2.2 pre1 into rawhide but have hit a snag
with a patch which is not getting correctly applied. The daft thing is
that the second part it, but the first thing isn't!

Below is that patch (in part). The uninstall hook patch is applied, but
not the install hook part. This is happening on both my home box and on
koji. Nothing else is hitting this particular makefile.in. Any ideas?

2.2-5.pre1 is in cvs currently and has recently failed to build on koji
(ID=71568). I can't get monodevelop 1.9.1 into rawhide until mono-tools
is in.

--- mono-tools-2.2/gendarme/rules/Makefile.in	2008-11-17
17:01:20.000000000 +0000
+++ mono-tools-2.2/gendarme/rules/Makefile-new.in	2008-11-29
13:22:55.000000000 +0000
@@ -526,10 +526,10 @@
 
 
 install-data-hook:
-	$(INSTALL) -c -m 0644 $(addprefix $(srcdir)/, rules.xml)
$(DESTDIR)$(prefix)/lib/gendarme;
+	$(INSTALL) -c -m 0644 $(addprefix $(srcdir)/, rules.xml)
$(DESTDIR)$(libdir)/gendarme;
 
 uninstall-hook:
-	rm -f $(DESTDIR)$(prefix)/lib/gendarme/`basename rules.xml`;
+	rm -f $(DESTDIR)$(libdir)/gendarme/`basename rules.xml`;
 
 test:
 	for ASM in $(SUBDIRS); do \

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/20081129/6e503646/attachment.sig>

From laxathom at fedoraproject.org  Sat Nov 29 14:18:18 2008
From: laxathom at fedoraproject.org (Xavier Lamien)
Date: Sat, 29 Nov 2008 15:18:18 +0100
Subject: Strange patch problem (not being fully applied)
In-Reply-To: <1227967751.31448.11.camel@PB3.Linux>
References: <1227967751.31448.11.camel@PB3.Linux>
Message-ID: <62bc09df0811290618o642b2510jb01048efaca2f293@mail.gmail.com>

2008/11/29 Paul <paul at all-the-johnsons.co.uk>:
> Hi,
>
> I'm trying to get mono-tools-2.2 pre1 into rawhide but have hit a snag
> with a patch which is not getting correctly applied. The daft thing is
> that the second part it, but the first thing isn't!
>
> Below is that patch (in part). The uninstall hook patch is applied, but
> not the install hook part. This is happening on both my home box and on
> koji. Nothing else is hitting this particular makefile.in. Any ideas?
>
> 2.2-5.pre1 is in cvs currently and has recently failed to build on koji
> (ID=71568). I can't get monodevelop 1.9.1 into rawhide until mono-tools
> is in.
>

Could you point us to the build.log ?

-- 
Xavier.t Lamien
--
http://fedoraproject.org/wiki/XavierLamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB



From duck at duckland.org  Sat Nov 29 14:20:35 2008
From: duck at duckland.org (Don Harper)
Date: Sat, 29 Nov 2008 08:20:35 -0600
Subject: Fedora 10 on Asus eee 701 feedback
In-Reply-To: <5256d0b0811290607x1775563aw7060e3829ed377b7@mail.gmail.com>
References: <64b14b300811290551xfdeda60oeec3b0e826a9563@mail.gmail.com>
	<5256d0b0811290607x1775563aw7060e3829ed377b7@mail.gmail.com>
Message-ID: <20081129142035.GN4284@duckland.org>

On Sat, Nov 29, 2008 at 02:07:39PM +0000, Peter Robinson wrote to To Development discussions related to Fedora:
> > Are there any asus eee users that have similar experience? Any
> > tips/tricks for us eee users?

> Does your SD card slot work?

> Peter

Mine does.  eeePc-701, serial starts with 7C.  I have a 16G SD card in
now.

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.
 The key is not to prioritize what???s on your schedule, but to schedule
                                        your priorities. - Stephen Covey
-------------- 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/20081129/ee6a5e1c/attachment.sig>

From paul at all-the-johnsons.co.uk  Sat Nov 29 14:22:43 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Sat, 29 Nov 2008 14:22:43 +0000
Subject: Strange patch problem (not being fully applied)
In-Reply-To: <62bc09df0811290618o642b2510jb01048efaca2f293@mail.gmail.com>
References: <1227967751.31448.11.camel@PB3.Linux>
	<62bc09df0811290618o642b2510jb01048efaca2f293@mail.gmail.com>
Message-ID: <1227968563.31448.24.camel@PB3.Linux>

Hi,

> Could you point us to the build.log ?

http://koji.fedoraproject.org/koji/getfile?taskID=957876&name=build.log

It builds fine on x86. However when I check the makefile.in file
concerned, it has not been changed on my local system either. I don't
know if there is a problem with the patching operation.

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/20081129/8f8336f4/attachment.sig>

From fedora at leemhuis.info  Sat Nov 29 14:28:29 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sat, 29 Nov 2008 15:28:29 +0100
Subject: Fedora 10 on Asus eee 701 feedback
In-Reply-To: <64b14b300811290551xfdeda60oeec3b0e826a9563@mail.gmail.com>
References: <64b14b300811290551xfdeda60oeec3b0e826a9563@mail.gmail.com>
Message-ID: <4931518D.8090706@leemhuis.info>

On 29.11.2008 14:51, Valent Turkovic wrote:
> [...]
> After compiling madwifi-hal and blacklisting ath5k wireless started
> working perfectly.

FYI, in case you are not aware of it: You can get madwifi pre-compiled 
from RPM Fusion. Getting it from there might be the best for those that 
don't want to compile or blacklist manually.

CU
knurd



From valent.turkovic at gmail.com  Sat Nov 29 14:42:57 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Sat, 29 Nov 2008 15:42:57 +0100
Subject: Fedora 10 on Asus eee 701 feedback
In-Reply-To: <4931518D.8090706@leemhuis.info>
References: <64b14b300811290551xfdeda60oeec3b0e826a9563@mail.gmail.com>
	<4931518D.8090706@leemhuis.info>
Message-ID: <64b14b300811290642h730cdbf1kac8170b443acc99@mail.gmail.com>

On Sat, Nov 29, 2008 at 3:28 PM, Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> On 29.11.2008 14:51, Valent Turkovic wrote:
>>
>> [...]
>> After compiling madwifi-hal and blacklisting ath5k wireless started
>> working perfectly.
>
> FYI, in case you are not aware of it: You can get madwifi pre-compiled from
> RPM Fusion. Getting it from there might be the best for those that don't
> want to compile or blacklist manually.
>
> CU
> knurd
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


For Fedora 9 madwifi drivers from rpmfusion stopped working for me (I
believe I also posted a bug on your mailing list) so I started
manually compiling drivers. I'm using now the new madwifi-hal and not
madwifi drivers.

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  Sat Nov 29 14:45:44 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Sat, 29 Nov 2008 15:45:44 +0100
Subject: Fedora 10 on Asus eee 701 feedback
In-Reply-To: <5256d0b0811290607x1775563aw7060e3829ed377b7@mail.gmail.com>
References: <64b14b300811290551xfdeda60oeec3b0e826a9563@mail.gmail.com>
	<5256d0b0811290607x1775563aw7060e3829ed377b7@mail.gmail.com>
Message-ID: <64b14b300811290645j194b8854udc84ba0325de8ed8@mail.gmail.com>

On Sat, Nov 29, 2008 at 3:07 PM, Peter Robinson <pbrobinson at gmail.com> wrote:
>> Are there any asus eee users that have similar experience? Any
>> tips/tricks for us eee users?
>
> Does your SD card slot work?
>
> Peter
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


I had some strange issues while installing Fedora 10 with LVM and
encryption on external SD card and after few tries I gave up. Now I
have Fedora 10 installed on internal SDD disk and it works ok with LVM
and encryption. But I checked after installation of Fedora 10 that my
card isn't broken and I could delete partitions and create new ones. I
didn't go beyond that for now.

Do you have some issues with SD reader?

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 j.w.r.degoede at hhs.nl  Sat Nov 29 14:53:47 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sat, 29 Nov 2008 15:53:47 +0100
Subject: Status of driver ov511 based cameras
In-Reply-To: <1227901448.3603.17.camel@agnes.fremen.dune>
References: <1227901448.3603.17.camel@agnes.fremen.dune>
Message-ID: <4931577B.6060607@hhs.nl>



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

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

Regards,

Hans



From pbrobinson at gmail.com  Sat Nov 29 14:48:33 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Sat, 29 Nov 2008 14:48:33 +0000
Subject: Fedora 10 on Asus eee 701 feedback
In-Reply-To: <64b14b300811290645j194b8854udc84ba0325de8ed8@mail.gmail.com>
References: <64b14b300811290551xfdeda60oeec3b0e826a9563@mail.gmail.com>
	<5256d0b0811290607x1775563aw7060e3829ed377b7@mail.gmail.com>
	<64b14b300811290645j194b8854udc84ba0325de8ed8@mail.gmail.com>
Message-ID: <5256d0b0811290648h63ef54d6wa261ee388396b5ee@mail.gmail.com>

On Sat, Nov 29, 2008 at 2:45 PM, Valent Turkovic
<valent.turkovic at gmail.com> wrote:
> On Sat, Nov 29, 2008 at 3:07 PM, Peter Robinson <pbrobinson at gmail.com> wrote:
>>> Are there any asus eee users that have similar experience? Any
>>> tips/tricks for us eee users?
>>
>> Does your SD card slot work?
>>
>> Peter
>>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>
>
> I had some strange issues while installing Fedora 10 with LVM and
> encryption on external SD card and after few tries I gave up. Now I
> have Fedora 10 installed on internal SDD disk and it works ok with LVM
> and encryption. But I checked after installation of Fedora 10 that my
> card isn't broken and I could delete partitions and create new ones. I
> didn't go beyond that for now.
>
> Do you have some issues with SD reader?

I don't (I have a eee 901 and it uses a different reader) but some
people have had issues. There's some details in the following bug
https://bugzilla.redhat.com/show_bug.cgi?id=465405



From fedora at leemhuis.info  Sat Nov 29 14:49:15 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sat, 29 Nov 2008 15:49:15 +0100
Subject: Fedora 10 on Asus eee 701 feedback
In-Reply-To: <64b14b300811290642h730cdbf1kac8170b443acc99@mail.gmail.com>
References: <64b14b300811290551xfdeda60oeec3b0e826a9563@mail.gmail.com>	<4931518D.8090706@leemhuis.info>
	<64b14b300811290642h730cdbf1kac8170b443acc99@mail.gmail.com>
Message-ID: <4931566B.8040006@leemhuis.info>

On 29.11.2008 15:42, Valent Turkovic wrote:
> On Sat, Nov 29, 2008 at 3:28 PM, Thorsten Leemhuis <fedora at leemhuis.info> wrote:
>> On 29.11.2008 14:51, Valent Turkovic wrote:
>>> [...]
>>> After compiling madwifi-hal and blacklisting ath5k wireless started
>>> working perfectly.
>> FYI, in case you are not aware of it: You can get madwifi pre-compiled from
>> RPM Fusion. Getting it from there might be the best for those that don't
>> want to compile or blacklist manually.
> For Fedora 9 madwifi drivers from rpmfusion stopped working for me (I
> believe I also posted a bug on your mailing list) 

Not all package maintainer read the mailing lists. Hence please file a 
bug (http://bugzilla.rpmfusion.org) if you encounter a problem. That is 
the best way to get a problem fixed -- then it'll not only work for you, 
but also "just work" for everybody else. And that's what all of us want, 
isn't it?

> so I started
> manually compiling drivers. I'm using now the new madwifi-hal and not
> madwifi drivers.

RPM Fusion in the F-10 branch as well.

Cu
knurd



From mtasaka at ioa.s.u-tokyo.ac.jp  Sat Nov 29 15:06:34 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Sun, 30 Nov 2008 00:06:34 +0900
Subject: Strange patch problem (not being fully applied)
In-Reply-To: <1227967751.31448.11.camel@PB3.Linux>
References: <1227967751.31448.11.camel@PB3.Linux>
Message-ID: <49315A7A.3000305@ioa.s.u-tokyo.ac.jp>

Paul wrote, at 11/29/2008 11:09 PM +9:00:
> Hi,
> 
> I'm trying to get mono-tools-2.2 pre1 into rawhide but have hit a snag
> with a patch which is not getting correctly applied. The daft thing is
> that the second part it, but the first thing isn't!
> 
> Below is that patch (in part). The uninstall hook patch is applied, but
> not the install hook part. This is happening on both my home box and on
> koji. Nothing else is hitting this particular makefile.in. Any ideas?
>
> --- mono-tools-2.2/gendarme/rules/Makefile.in	2008-11-17
> 17:01:20.000000000 +0000
> +++ mono-tools-2.2/gendarme/rules/Makefile-new.in	2008-11-29
> 13:22:55.000000000 +0000
> @@ -526,10 +526,10 @@
>  
>  
>  install-data-hook:
> -	$(INSTALL) -c -m 0644 $(addprefix $(srcdir)/, rules.xml)
> $(DESTDIR)$(prefix)/lib/gendarme;
> +	$(INSTALL) -c -m 0644 $(addprefix $(srcdir)/, rules.xml)
> $(DESTDIR)$(libdir)/gendarme;
>  
>  uninstall-hook:
> -	rm -f $(DESTDIR)$(prefix)/lib/gendarme/`basename rules.xml`;
> +	rm -f $(DESTDIR)$(libdir)/gendarme/`basename rules.xml`;
>  
>  test:
>  	for ASM in $(SUBDIRS); do \
> 
> TTFN
> 
> Paul

This patch modifies Makefile.in, however mono-tools.spec says
after this patch is applied autoreconf is called, which 
perhaps regenerates Makefile.in from (unmodified) Makefile.am, 
which I guess is the reason.

Regards,
Mamoru



From laxathom at fedoraproject.org  Sat Nov 29 15:07:02 2008
From: laxathom at fedoraproject.org (Xavier Lamien)
Date: Sat, 29 Nov 2008 16:07:02 +0100
Subject: Strange patch problem (not being fully applied)
In-Reply-To: <1227968563.31448.24.camel@PB3.Linux>
References: <1227967751.31448.11.camel@PB3.Linux>
	<62bc09df0811290618o642b2510jb01048efaca2f293@mail.gmail.com>
	<1227968563.31448.24.camel@PB3.Linux>
Message-ID: <62bc09df0811290707l14582d4bnfe8e1e7784cef69e@mail.gmail.com>

2008/11/29 Paul <paul at all-the-johnsons.co.uk>:
> Hi,
>
>> Could you point us to the build.log ?
>
> http://koji.fedoraproject.org/koji/getfile?taskID=957876&name=build.log
>
> It builds fine on x86. However when I check the makefile.in file
> concerned, it has not been changed on my local system either. I don't
> know if there is a problem with the patching operation.
>
> TTFN

Have a closer look into both your patch and the Makefile.am
You forgot a '$(prefix)/lib' in the install method



-- 
Xavier.t Lamien
--
http://fedoraproject.org/wiki/XavierLamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB



From trever.adams at gmail.com  Sat Nov 29 15:42:50 2008
From: trever.adams at gmail.com (Trever L. Adams)
Date: Sat, 29 Nov 2008 08:42:50 -0700
Subject: Multiple packages from one tarball and spec file
Message-ID: <493162FA.6030705@gmail.com>

My questions concerning projects which are from SVN and not tarballs 
hasn't yet been answered. Some projects don't release tarballs or 
haven't released recent ones (and may not). Are this acceptable in Fedora?

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.

Thank you for any help on the first paragraph or the second.

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/20081129/e6a31c9a/attachment.sig>

From paul at all-the-johnsons.co.uk  Sat Nov 29 15:48:53 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Sat, 29 Nov 2008 15:48:53 +0000
Subject: Packaging mono hack - is there a way to do this?
Message-ID: <1227973733.31448.32.camel@PB3.Linux>

Hi,

As you all know, packaging mono apps involves a lot of makefile and pc
file patching so that instead of targeting /usr/lib, it targets
$(libdir). While I am actively trying to get Novell to stop being silly
and write their makefiles correctly, progress is slow there.

As a thought, is there a way to do something like this

for i in [alldirectories]/Makefile.{in,am} \
         [alldirectories]/*.pc.in \
; do
sed -i -e 's!$(prefix)/lib!%{_libdir}!' "$i"
done

where [alldirectories] is a recursive call into every directory within
the application.

It would certainly save a shed load of 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/20081129/021eca3b/attachment.sig>

From fedora at matbooth.co.uk  Sat Nov 29 15:51:16 2008
From: fedora at matbooth.co.uk (Mat Booth)
Date: Sat, 29 Nov 2008 15:51:16 +0000
Subject: Multiple packages from one tarball and spec file
In-Reply-To: <493162FA.6030705@gmail.com>
References: <493162FA.6030705@gmail.com>
Message-ID: <9497e9990811290751r77ab7475rec44982a4ff2e557@mail.gmail.com>

2008/11/29 Trever L. Adams <trever.adams at gmail.com>:
> My questions concerning projects which are from SVN and not tarballs hasn't
> yet been answered. Some projects don't release tarballs or haven't released
> recent ones (and may not). Are this acceptable in Fedora?
>


Yes. There are plenty of packages in Fedora built straight from source control.

(My package eclipse-epic does this, for example:
http://cvs.fedoraproject.org/viewvc/rpms/eclipse-epic/  Take a look
around Fedora's CVS for more examples.)

I believe Jaroslav Reznik implied this was the case by linking to
https://fedoraproject.org/wiki/Packaging/SourceURL#Using_Revision_Control

-- 
Mat Booth
www.matbooth.co.uk



From mtasaka at ioa.s.u-tokyo.ac.jp  Sat Nov 29 16:00:15 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Sun, 30 Nov 2008 01:00:15 +0900
Subject: Packaging mono hack - is there a way to do this?
In-Reply-To: <1227973733.31448.32.camel@PB3.Linux>
References: <1227973733.31448.32.camel@PB3.Linux>
Message-ID: <4931670F.6020907@ioa.s.u-tokyo.ac.jp>

Paul wrote, at 11/30/2008 12:48 AM +9:00:
> Hi,
>
> As a thought, is there a way to do something like this
> 
> for i in [alldirectories]/Makefile.{in,am} \
>          [alldirectories]/*.pc.in \
> ; do
> sed -i -e 's!$(prefix)/lib!%{_libdir}!' "$i"
> done
> 
> where [alldirectories] is a recursive call into every directory within
> the application.

find . -name Makefile.in -or -name Makefile.am -or -name \*.pc.in \
	| while read f ; do ... ; done

for example.

Mamoru



From tmus at tmus.dk  Sat Nov 29 16:17:47 2008
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Sat, 29 Nov 2008 13:17:47 -0300
Subject: Before I do something silly, can someone give me some advice
 on an   lvm partition?
In-Reply-To: <1227956857.31448.2.camel@PB3.Linux>
References: <1227956857.31448.2.camel@PB3.Linux>
Message-ID: <ggrq0n$1bv$1@ger.gmane.org>

Paul wrote:
> Hi,
> 
> I have a 149Gb lvm partition on /dev/sda2. I've no idea what's in there.
> My /home directory is on a different drive. /dev/sda1 has the OS on it
> (it's 200Mb). I have a feeling that the likes of /usr and /var are on
> the lvm partition. Is there anything I can use to check this?
> 
> TTFN
> 
> Paul
> 

You need to check your mountpoints "mount" and/or "cat /etc/fstab"... 
The "OS" on /dev/sda1 is most likely just your /boot partition. /, 
<swap> and such are most likely on logical volumes within the lvm partition.

Hope this helps.

/Thomas



From pmatilai at laiskiainen.org  Sat Nov 29 17:24:33 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Sat, 29 Nov 2008 19:24:33 +0200 (EET)
Subject: Heads-up: Enabling generation of pkg-config requires
Message-ID: <alpine.LFD.2.00.0811291856590.2808@turre.koti.laiskiainen.org>


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...

 	- Panu -



From dbn.lists at gmail.com  Sat Nov 29 17:59:06 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Sat, 29 Nov 2008 09:59:06 -0800
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: <91705d080811290959x199250e0t5a4af4fefbf98cf9@mail.gmail.com>

On Sat, Nov 29, 2008 at 9:24 AM, Panu Matilainen
<pmatilai at laiskiainen.org> 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...

Can I please take this opportunity to point out that the pkg-config in
fedora is broken specifically because of using pkgconfig autoreqprovs.
Specifically, this patch is used:

http://cvs.fedoraproject.org/viewvc/rpms/pkgconfig/devel/pkg-config-0.21-requires-private-fix.patch?view=log

This breaks the use of Requires.private in .pc files. The reason it
was added (as far as I can tell) is because the pkgconfig autoprovides
didn't take only added the Requires information. When package b has
package a in Requires.private, rpm does not add pkgconfig(a) as
required to package b. See this bug:

https://bugzilla.redhat.com/show_bug.cgi?id=224148

And a follow up I opened which has patches which fix this:

https://bugzilla.redhat.com/show_bug.cgi?id=426106

Please, please, take a look at this. What fedora is doing is broken
and making it difficult for people that really want to use
Requires.private in their projects.

--
Dan



From mlichvar at redhat.com  Sat Nov 29 19:12:02 2008
From: mlichvar at redhat.com (Miroslav Lichvar)
Date: Sat, 29 Nov 2008 20:12:02 +0100
Subject: Fedora 10 on Asus eee 701 feedback
In-Reply-To: <64b14b300811290551xfdeda60oeec3b0e826a9563@mail.gmail.com>
References: <64b14b300811290551xfdeda60oeec3b0e826a9563@mail.gmail.com>
Message-ID: <20081129191202.GB671@localhost>

On Sat, Nov 29, 2008 at 02:51:33PM +0100, Valent Turkovic wrote:
> Are there any asus eee users that have similar experience? Any
> tips/tricks for us eee users?

After installing F10 on a 4GB SD card I had the following problems:

- a cache (I suspect the one in the reader) wasn't flushed on
  reboot/poweroff, so there was always filesystem check on start. A
  sleep command added to the halt init script fixed it.
- wireless didn't work after suspend, I didn't try the madwifi driver
- Fn+F2 key (with rfkill-input module loaded) worked only after some
  time has passed, and wireless didn't work after turning it on again
- snd-hda-intel driver prevented CPU entering C3 state and sometimes
  the machine didn't power off. Using power_save=15 option for the
  driver fixed both problems.

I think I've seen all of this reported in bugzilla. Everything else I
tried worked fine.

-- 
Miroslav Lichvar



From pbrobinson at gmail.com  Sat Nov 29 19:24:20 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Sat, 29 Nov 2008 19:24:20 +0000
Subject: Fedora 10 on Asus eee 701 feedback
In-Reply-To: <20081129191202.GB671@localhost>
References: <64b14b300811290551xfdeda60oeec3b0e826a9563@mail.gmail.com>
	<20081129191202.GB671@localhost>
Message-ID: <5256d0b0811291124l74ecd63bu63970c9409ca0cea@mail.gmail.com>

> - wireless didn't work after suspend, I didn't try the madwifi driver
> - Fn+F2 key (with rfkill-input module loaded) worked only after some
>  time has passed, and wireless didn't work after turning it on again

The rfkill switch pci hotplugs the wifi, there's issues with it that I
think have been fixed recently upstream. If the patches aren't in the
current fedora kernel I suspect they will be soon.

peter



From valent.turkovic at gmail.com  Sat Nov 29 19:59:44 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Sat, 29 Nov 2008 20:59:44 +0100
Subject: new namespace?
Message-ID: <64b14b300811291159u7072cd6s3a79b283ada93762@mail.gmail.com>

Hi,
I'm wondering if there was a discussion about this already so excuse
my question if it was. Is there a namespace on Fedora wiki for guides,
howtos, tutorials and similar articles?

Where can and how see all tutorials, howtos and guides for Fedora on
Fedora wiki?

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 ewan at macmahon.me.uk  Sat Nov 29 20:24:07 2008
From: ewan at macmahon.me.uk (Ewan Mac Mahon)
Date: Sat, 29 Nov 2008 20:24:07 +0000
Subject: PulseAudio info needed
In-Reply-To: <adf480660811282355l4c1d383egeecac85e54915a2e@mail.gmail.com>
References: <200811271301.11802.cannewilson@googlemail.com>
	<492E9B4B.4000206@redhat.com>
	<adf480660811270533m7ba4be5ctd1e98359ed8800dd@mail.gmail.com>
	<f6ca9fed0811280714j40846429o2930d127b232c15e@mail.gmail.com>
	<adf480660811280728v17ff6d4ah9b0ca9b8bf5513b2@mail.gmail.com>
	<79r506xajr.ln2@ppp1053.in.ipex.cz>
	<20081128204400.GA23162@mokona.greysector.net>
	<68720af30811281633qcae1650o4f50ba2e90abaafa@mail.gmail.com>
	<adf480660811282355l4c1d383egeecac85e54915a2e@mail.gmail.com>
Message-ID: <20081129202406.GG19269@macmahon.me.uk>

On Sat, Nov 29, 2008 at 10:55:06AM +0300, Peter Lemenkov wrote:
> 2008/11/29, Paulo Cavalcanti <promac at gmail.com>:
> 
> > > > Actually, I do switch between headphones and speakers all the
> > > > time and I found it pretty useful.
> 
> > > I don't know about your setup, but both my stereo and my laptop
> > > disable the speakers when I plug in the headphones. I don't know
> > > where PulseAudio comes in here.
> 
> > You need two sound cards.
> 
> That's not a prevailing configuration.
> 
It's pretty common. Any set of USB headphones are essentially their own
separate sound card, and PA is great for being able to just plug them in
and switch the sound over. USB headphones are not a rarity, even if you
don't have any.

Ewan 
-------------- 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/20081129/375a2ff4/attachment.sig>

From forum at ru.bir.ru  Sat Nov 29 20:45:59 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Sat, 29 Nov 2008 23:45:59 +0300
Subject: How to pack cron jobs?
Message-ID: <ggs9m8$rsg$1@ger.gmane.org>

Hello.

I'm search documentation, how-to or guidelines how I can correctly pack 
cron job, needed by rpm package.

I'm spent big time, but do not find any useful description.

Off course I known about directories
/etc/cron.daily
/etc/cron.hourly
/etc/cron.monthly
/etc/cron.weekly
but what if I need start job every 20 minutes?

AFAIK, in cronie rpm presents /etc/cron.d especially for this purposes. 
But really it is only true way put cronie into requires? How I can pack 
jobs for standard (vixie) cron?

Very thanks for all answers.



From martin.langhoff at gmail.com  Sat Nov 29 21:04:59 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Sat, 29 Nov 2008 19:04:59 -0200
Subject: How to pack cron jobs?
In-Reply-To: <ggs9m8$rsg$1@ger.gmane.org>
References: <ggs9m8$rsg$1@ger.gmane.org>
Message-ID: <46a038f90811291304k1ae4269i57f9a1dd0fc605b6@mail.gmail.com>

On Sat, Nov 29, 2008 at 6:45 PM, Pavel Alexeev (aka Pahan-Hubbitus)
<forum at ru.bir.ru> wrote:
> Off course I known about directories
> /etc/cron.daily
> /etc/cron.hourly
> /etc/cron.monthly
> /etc/cron.weekly

/etc/cron.d is your friend :-)



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 konrad at tylerc.org  Sat Nov 29 21:22:11 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Sat, 29 Nov 2008 13:22:11 -0800
Subject: Multiple packages from one tarball and spec file
In-Reply-To: <493162FA.6030705@gmail.com>
References: <493162FA.6030705@gmail.com>
Message-ID: <200811291322.11215.konrad@tylerc.org>

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,
-- 
Conrad Meyer <konrad at tylerc.org>




From forum at ru.bir.ru  Sat Nov 29 21:46:33 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Sun, 30 Nov 2008 00:46:33 +0300
Subject: How to pack cron jobs?
In-Reply-To: <46a038f90811291304k1ae4269i57f9a1dd0fc605b6@mail.gmail.com>
References: <ggs9m8$rsg$1@ger.gmane.org>
	<46a038f90811291304k1ae4269i57f9a1dd0fc605b6@mail.gmail.com>
Message-ID: <ggsd7q$5tn$1@ger.gmane.org>

Martin Langhoff ?????:
> On Sat, Nov 29, 2008 at 6:45 PM, Pavel Alexeev (aka Pahan-Hubbitus)
> <forum at ru.bir.ru> wrote:
>> Off course I known about directories
>> /etc/cron.daily
>> /etc/cron.hourly
>> /etc/cron.monthly
>> /etc/cron.weekly
> 
> /etc/cron.d is your friend :-)
> 
> 
> 
> m
As I write above, /etc/cron.d provided only by cronie:
# repoquery --whatprovides /etc/cron.d
cronie-0:1.0-7.fc9.i386
cronie-0:1.0-7.fc9.i386
cronie-0:1.0-5.fc9.i386

But now we have several other crons in repositorys:
# repoquery '*cron*' | egrep -v '^(yum-cron|PackageKit-cron|cronolog)'
anacron-0:2.3-62.fc9.i386
cronie-0:1.0-5.fc9.i386
incron-0:0.5.7-1.fc9.i386
crontabs-0:1.10-19.fc9.noarch
cronie-0:1.0-7.fc9.i386
fcron-0:3.0.3-4.fc9.i386
anacron-0:2.3-59.fc9.i386



From ivazqueznet at gmail.com  Sat Nov 29 21:51:46 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Sat, 29 Nov 2008 16:51:46 -0500
Subject: How to pack cron jobs?
In-Reply-To: <ggsd7q$5tn$1@ger.gmane.org>
References: <ggs9m8$rsg$1@ger.gmane.org>
	<46a038f90811291304k1ae4269i57f9a1dd0fc605b6@mail.gmail.com>
	<ggsd7q$5tn$1@ger.gmane.org>
Message-ID: <1227995506.3835.69.camel@ignacio.lan>

On Sun, 2008-11-30 at 00:46 +0300, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
> But now we have several other crons in repositorys:
> # repoquery '*cron*' | egrep -v '^(yum-cron|PackageKit-cron|cronolog)'
> anacron-0:2.3-62.fc9.i386
> cronie-0:1.0-5.fc9.i386
> incron-0:0.5.7-1.fc9.i386
> crontabs-0:1.10-19.fc9.noarch
> cronie-0:1.0-7.fc9.i386
> fcron-0:3.0.3-4.fc9.i386
> anacron-0:2.3-59.fc9.i386

The only replacement for cronie in that list is fcron. Feel free to log
a bug against 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/20081129/4ac0672e/attachment.sig>

From opensource at till.name  Sat Nov 29 22:03:17 2008
From: opensource at till.name (Till Maas)
Date: Sat, 29 Nov 2008 23:03:17 +0100
Subject: How to pack cron jobs?
In-Reply-To: <1227995506.3835.69.camel@ignacio.lan>
References: <ggs9m8$rsg$1@ger.gmane.org> <ggsd7q$5tn$1@ger.gmane.org>
	<1227995506.3835.69.camel@ignacio.lan>
Message-ID: <200811292303.26003.opensource@till.name>

On Sat November 29 2008, Ignacio Vazquez-Abrams wrote:

> The only replacement for cronie in that list is fcron. Feel free to log
> a bug against it.

On my F8 system, the /etc/cron.* directories are provided by the package 
crontabs, maybe it should provide /etc/cron.d then, 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/20081129/b383858d/attachment.sig>

From forum at ru.bir.ru  Sat Nov 29 22:05:53 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Sun, 30 Nov 2008 01:05:53 +0300
Subject: How to pack cron jobs?
In-Reply-To: <1227995506.3835.69.camel@ignacio.lan>
References: <ggs9m8$rsg$1@ger.gmane.org>	<46a038f90811291304k1ae4269i57f9a1dd0fc605b6@mail.gmail.com>	<ggsd7q$5tn$1@ger.gmane.org>
	<1227995506.3835.69.camel@ignacio.lan>
Message-ID: <ggsec2$8uq$1@ger.gmane.org>

Ignacio Vazquez-Abrams ?????:
> On Sun, 2008-11-30 at 00:46 +0300, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
>> But now we have several other crons in repositorys:
>> # repoquery '*cron*' | egrep -v '^(yum-cron|PackageKit-cron|cronolog)'
>> anacron-0:2.3-62.fc9.i386
>> cronie-0:1.0-5.fc9.i386
>> incron-0:0.5.7-1.fc9.i386
>> crontabs-0:1.10-19.fc9.noarch
>> cronie-0:1.0-7.fc9.i386
>> fcron-0:3.0.3-4.fc9.i386
>> anacron-0:2.3-59.fc9.i386
> 
> The only replacement for cronie in that list is fcron. Feel free to log
> a bug against it.
> 
> 
Ok. Anacron is only for daily and weakly jobs. But what about fcron? Can 
I provide jobs available for both cronie and fcron? Or there is only one 
way - require cronie?

What you can say about using crontab command (or even directly 
manupulation with /etc/crontab) in %post/%postun macroses?



From lfarkas at lfarkas.org  Sat Nov 29 22:22:52 2008
From: lfarkas at lfarkas.org (Farkas Levente)
Date: Sat, 29 Nov 2008 23:22:52 +0100
Subject: upgrade f9->f10 with Promise pdc2027x hang forever
Message-ID: <4931C0BC.5010309@lfarkas.org>

hi,
i try to upgrade from f9->f10 the graphical installer simple hang (which
is imho a bug). when i start it in text mode i've got an error that it
can't find /dev/mapper/pdc_fbdiccjg and neither retry nor cancel help.
so currently on that machine it's not possible to upgrade.
while in the console the error:
-------------------------------------------
ERROR: Activating raid pdc_fbdiccjg failed:
       table: 0 0 linear /dev/mapper/pdc_fbdiccjg
       exception: size must be positive
CRITICAL: parted exception: Error:
       Could not start device /dev/mapper/pdc_fbdiccjg no such file or
directory
-------------------------------------------
the machine is an asus p4b533-e motherboard with promise pdc20276 fake raid
controller which is disabled in the bios and there is no disk on it, but the
kernel still find it. it has 2 pata disk with 2 partition which yield:
- md0 /boot
- md1 lvm vg (inside lv swap and /)
but as anaconda can't find the installed system i'm not able to upgrade.

with preupgrade failed beacuse can't find:
hd:UUID=a28359f7-e1e3-8e6c-7cea-f2167df41199
-------------------------------------------
# cat /proc/partitions
major minor  #blocks  name

   8     0   78184008 sda
   8     1     104391 sda1
   8     2   78075900 sda2
   8    16   78184008 sdb
   8    17     104391 sdb1
   8    18   78075900 sdb2
   9     1   78075776 md1
 253     0   15335424 dm-0
 253     1    2097152 dm-1
 253     2   60620800 dm-2
   9     0     104320 md0
 253     3   60619772 dm-3
# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md0 : active raid1 sda1[0] sdb1[1]
      104320 blocks [2/2] [UU]

md1 : active raid1 sda2[0] sdb2[1]
      78075776 blocks [2/2] [UU]

unused devices: <none>
# cat /etc/fstab
/dev/System/root        /                       ext3    defaults        1 1
/dev/md0                /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
/dev/System/swap        swap                    swap    defaults        0 0
# cat /etc/grub.conf
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/System/root
#          initrd /initrd-version.img
#boot=/dev/md0
default=1
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Upgrade to Fedora 10 (Cambridge)
	kernel /upgrade/vmlinuz preupgrade
repo=hd:UUID=a310d15b-4a9b-44a0-a50c-6f025004e0b5:/var/cache/yum/preupgrade
stage2=http://sunsite.informatik.rwth-aachen.de/ftp/pub/Linux/fedora/linux/releases/10/Fedora/i386/os/images/install.img
ks=hd:UUID=a28359f7-e1e3-8e6c-7cea-f2167df41199:/upgrade/ks.cfg
	initrd /upgrade/initrd.img
title Fedora (2.6.27.5-41.fc9.i686)
	root (hd0,0)
	kernel /vmlinuz-2.6.27.5-41.fc9.i686 ro root=/dev/System/root
	initrd /initrd-2.6.27.5-41.fc9.i686.img
title Memtest86+ (2.01)
	root (hd0,0)
	kernel /memtest86+-2.01 ro root=/dev/System/root
-------------------------------------------

-- 
  Levente                               "Si vis pacem para bellum!"



From forum at ru.bir.ru  Sat Nov 29 22:32:49 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Sun, 30 Nov 2008 01:32:49 +0300
Subject: How to pack cron jobs?
In-Reply-To: <200811292303.26003.opensource@till.name>
References: <ggs9m8$rsg$1@ger.gmane.org>
	<ggsd7q$5tn$1@ger.gmane.org>	<1227995506.3835.69.camel@ignacio.lan>
	<200811292303.26003.opensource@till.name>
Message-ID: <ggsfuh$c7r$1@ger.gmane.org>

Till Maas ?????:
> On Sat November 29 2008, Ignacio Vazquez-Abrams wrote:
> 
>> The only replacement for cronie in that list is fcron. Feel free to log
>> a bug against it.
> 
> On my F8 system, the /etc/cron.* directories are provided by the package 
> crontabs, maybe it should provide /etc/cron.d then, too.

On my Fedora 9 too:
$ rpm -qf /etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/
crontabs-1.10-19.fc9.noarch
crontabs-1.10-19.fc9.noarch
crontabs-1.10-19.fc9.noarch

$ rpm -qf /etc/cron.d
cronie-1.0-7.fc9.i386

And, I think it is not problem to make /etc/cron.d part of crontabs, but 
if fcron still ignore it, it is not solution anyway.

> 
> Regards,
> Till
> 



From jdennis at redhat.com  Sat Nov 29 22:46:51 2008
From: jdennis at redhat.com (John Dennis)
Date: Sat, 29 Nov 2008 17:46:51 -0500
Subject: Broken dependencies in Fedora 10 - 2008-11-27
In-Reply-To: <20081127171928.12430.79239@faldor.intranet>
References: <20081127171928.12430.79239@faldor.intranet>
Message-ID: <4931C65B.20204@redhat.com>

Michael Schwendt wrote:
> Your following packages in the repository suffer from broken dependencies:
>
> package: freeradius-dialupadmin-ldap-2.1.1-2.fc10.i386 from fedora-10-i386
>   unresolved deps:
>      freeradius-ldap = 0:2.1.1-2.fc10
>
> package: freeradius-dialupadmin-ldap-2.1.1-2.fc10.i386 from fedora-10-i386
>   unresolved deps:
>      freeradius-ldap = 0:2.1.1-2.fc10
>
> package: freeradius-dialupadmin-ldap-2.1.1-2.fc10.ppc from fedora-10-ppc
>   unresolved deps:
>      freeradius-ldap = 0:2.1.1-2.fc10
>
> package: freeradius-dialupadmin-ldap-2.1.1-2.fc10.ppc from fedora-10-ppc
>   unresolved deps:
>      freeradius-ldap = 0:2.1.1-2.fc10
>
> package: freeradius-dialupadmin-ldap-2.1.1-2.fc10.ppc64 from fedora-10-ppc64
>   unresolved deps:
>      freeradius-ldap = 0:2.1.1-2.fc10
>
> package: freeradius-dialupadmin-ldap-2.1.1-2.fc10.ppc64 from fedora-10-ppc64
>   unresolved deps:
>      freeradius-ldap = 0:2.1.1-2.fc10
>
> package: freeradius-dialupadmin-ldap-2.1.1-2.fc10.x86_64 from fedora-10-x86_64
>   unresolved deps:
>      freeradius-ldap = 0:2.1.1-2.fc10
>
> package: freeradius-dialupadmin-ldap-2.1.1-2.fc10.x86_64 from fedora-10-x86_64
>   unresolved deps:
>      freeradius-ldap = 0:2.1.1-2.fc10
>
> package: freeradius-dialupadmin-mysql-2.1.1-2.fc10.i386 from fedora-10-i386
>   unresolved deps:
>      freeradius-mysql = 0:2.1.1-2.fc10
>
> package: freeradius-dialupadmin-mysql-2.1.1-2.fc10.i386 from fedora-10-i386
>   unresolved deps:
>      freeradius-mysql = 0:2.1.1-2.fc10
>
> package: freeradius-dialupadmin-mysql-2.1.1-2.fc10.ppc from fedora-10-ppc
>   unresolved deps:
>      freeradius-mysql = 0:2.1.1-2.fc10
>
> package: freeradius-dialupadmin-mysql-2.1.1-2.fc10.ppc from fedora-10-ppc
>   unresolved deps:
>      freeradius-mysql = 0:2.1.1-2.fc10
>
> package: freeradius-dialupadmin-mysql-2.1.1-2.fc10.ppc64 from fedora-10-ppc64
>   unresolved deps:
>      freeradius-mysql = 0:2.1.1-2.fc10
>
> package: freeradius-dialupadmin-mysql-2.1.1-2.fc10.ppc64 from fedora-10-ppc64
>   unresolved deps:
>      freeradius-mysql = 0:2.1.1-2.fc10
>
> package: freeradius-dialupadmin-mysql-2.1.1-2.fc10.x86_64 from fedora-10-x86_64
>   unresolved deps:
>      freeradius-mysql = 0:2.1.1-2.fc10
>
> package: freeradius-dialupadmin-mysql-2.1.1-2.fc10.x86_64 from fedora-10-x86_64
>   unresolved deps:
>      freeradius-mysql = 0:2.1.1-2.fc10
>
> package: freeradius-dialupadmin-postgresql-2.1.1-2.fc10.i386 from fedora-10-i386
>   unresolved deps:
>      freeradius-postgresql = 0:2.1.1-2.fc10
>
> package: freeradius-dialupadmin-postgresql-2.1.1-2.fc10.i386 from fedora-10-i386
>   unresolved deps:
>      freeradius-postgresql = 0:2.1.1-2.fc10
>
> package: freeradius-dialupadmin-postgresql-2.1.1-2.fc10.ppc from fedora-10-ppc
>   unresolved deps:
>      freeradius-postgresql = 0:2.1.1-2.fc10
>
> package: freeradius-dialupadmin-postgresql-2.1.1-2.fc10.ppc from fedora-10-ppc
>   unresolved deps:
>      freeradius-postgresql = 0:2.1.1-2.fc10
>
> package: freeradius-dialupadmin-postgresql-2.1.1-2.fc10.ppc64 from fedora-10-ppc64
>   unresolved deps:
>      freeradius-postgresql = 0:2.1.1-2.fc10
>
> package: freeradius-dialupadmin-postgresql-2.1.1-2.fc10.ppc64 from fedora-10-ppc64
>   unresolved deps:
>      freeradius-postgresql = 0:2.1.1-2.fc10
>
> package: freeradius-dialupadmin-postgresql-2.1.1-2.fc10.x86_64 from fedora-10-x86_64
>   unresolved deps:
>      freeradius-postgresql = 0:2.1.1-2.fc10
>
> package: freeradius-dialupadmin-postgresql-2.1.1-2.fc10.x86_64 from fedora-10-x86_64
>   unresolved deps:
>      freeradius-postgresql = 0:2.1.1-2.fc10
>
>   
An update has been created (freeradius-2.1.1-7.fc10) which should 
correct the dependency problem. The previous package did not include the 
necessary obsoletes tag for several subpackages which had been removed 
(freeradius-dialupadmin*).

-- 
John Dennis <jdennis at redhat.com>



From stickster at gmail.com  Sat Nov 29 23:11:32 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Sat, 29 Nov 2008 18:11:32 -0500
Subject: new namespace?
In-Reply-To: <64b14b300811291159u7072cd6s3a79b283ada93762@mail.gmail.com>
References: <64b14b300811291159u7072cd6s3a79b283ada93762@mail.gmail.com>
Message-ID: <20081129231132.GB8426@localhost.localdomain>

On Sat, Nov 29, 2008 at 08:59:44PM +0100, Valent Turkovic wrote:
> Hi,
> I'm wondering if there was a discussion about this already so excuse
> my question if it was. Is there a namespace on Fedora wiki for guides,
> howtos, tutorials and similar articles?
> 
> Where can and how see all tutorials, howtos and guides for Fedora on
> Fedora wiki?

No, and there should not be.  The Docs team and the folks working on
wiki revitalization discussed this some time ago.  The wiki itself is
supposed to be the place for those guides, not a subset thereof.
Guides should not be kept in some "Howtos/Foobar" oddball hierarchy,
but rather as "How_to_do_foobar" which makes it easier for people to
find what they're looking for.

-- 
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/20081129/156e355c/attachment.sig>

From markg85 at gmail.com  Sun Nov 30 01:04:56 2008
From: markg85 at gmail.com (Mark)
Date: Sun, 30 Nov 2008 02:04:56 +0100
Subject: Logout sound ever gonna be fixed?
Message-ID: <6e24a8e80811291704o254ad060hdb01e789203b146e@mail.gmail.com>

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



From musuruan at gmail.com  Sun Nov 30 01:07:15 2008
From: musuruan at gmail.com (Andrea Musuruane)
Date: Sun, 30 Nov 2008 02:07:15 +0100
Subject: EVR problems in upgrading from F9 to F10
Message-ID: <29fee02b0811291707j550ddd16y14cf1ffcbe3bc972@mail.gmail.com>

Hi,
    after upgrading from F9 to F10, I had the following packages not
updated because of EVR problems:

# package-cleanup --orphans
Setting up yum
Plugin caricati:refresh-packagekit
bouncycastle-1.41-2.fc9.x86_64
gnome-spell-1.0.8-5.fc9.x86_64
qt-4.4.3-5.fc9.x86_64
qt-x11-4.4.3-5.fc9.x86_64
setroubleshoot-2.0.12-4.fc9.noarch
setroubleshoot-plugins-2.0.11-1.fc9.noarch
setroubleshoot-server-2.0.12-4.fc9.noarch
xorg-x11-drv-vmmouse-12.6.2-1.fc9.x86_64

For these packages it seems that F9 EVR > F10 EVR.

Regards,

Andrea



From musuruan at gmail.com  Sun Nov 30 01:16:58 2008
From: musuruan at gmail.com (Andrea Musuruane)
Date: Sun, 30 Nov 2008 02:16:58 +0100
Subject: EVR problems in upgrading from F9 to F10
In-Reply-To: <29fee02b0811291707j550ddd16y14cf1ffcbe3bc972@mail.gmail.com>
References: <29fee02b0811291707j550ddd16y14cf1ffcbe3bc972@mail.gmail.com>
Message-ID: <29fee02b0811291716o2fd4315bu6ab7aa6f93a4039e@mail.gmail.com>

2008/11/30 Andrea Musuruane <musuruan at gmail.com>:
> gnome-spell-1.0.8-5.fc9.x86_64

Omit this one. It has been retired.

Regards,

Andrea.



From orcanbahri at yahoo.com  Sun Nov 30 01:31:02 2008
From: orcanbahri at yahoo.com (Orcan Ogetbil)
Date: Sat, 29 Nov 2008 17:31:02 -0800 (PST)
Subject: EVR problems in upgrading from F9 to F10
In-Reply-To: <29fee02b0811291707j550ddd16y14cf1ffcbe3bc972@mail.gmail.com>
Message-ID: <193814.25370.qm@web32801.mail.mud.yahoo.com>

--- On Sat, 11/29/08, Andrea Musuruane  wrote:
> Hi,
>     after upgrading from F9 to F10, I had the following
> packages not
> updated because of EVR problems:
> 
> # package-cleanup --orphans
> Setting up yum
> Plugin caricati:refresh-packagekit
> bouncycastle-1.41-2.fc9.x86_64
> [cut]

Thanks for the warning. I thought I pushed this package to rawhide before the mass-branching happened. Apparently it's now in F-9 and F-11(rawhide), and F-10 is skipped. I'm fixing the issue right now.

-oget


      



From sundaram at fedoraproject.org  Sun Nov 30 05:22:49 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 30 Nov 2008 10:52:49 +0530
Subject: Fedora 9 Spins
Message-ID: <49322329.7060404@fedoraproject.org>

Hi

Can the Fedora 9 spins be not marked as beta anymore? One ticket doesn't 
get any response. The other one was closed as a dup of the first one.

http://spins.fedoraproject.org/


Rahul



From wtogami at redhat.com  Sun Nov 30 05:29:22 2008
From: wtogami at redhat.com (Warren Togami)
Date: Sun, 30 Nov 2008 00:29:22 -0500
Subject: F11: OSS and pulseaudio conflict
In-Reply-To: <1227522629.3675.2625.camel@cookie.hadess.net>
References: <491DA325.3010305@redhat.com>	<1226702549.29933.2.camel@snoogens.fab.redhat.com>
	<1227522629.3675.2625.camel@cookie.hadess.net>
Message-ID: <493224B2.60706@redhat.com>

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:

1) Disable building of the OSS kernel modules.
2) Provide cuse OSS proxy in its own package, that starts the OSS proxy 
upon user login after the user's pulseaudio daemon is running.
3) Do NOT install it by default, as it is yet another process that runs 
that few people actually need.  If people want OSS proxy they can 
install this optional package.

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.

In both cases the user has to manually do something to use OSS, which is 
fine by me.

https://bugzilla.redhat.com/show_bug.cgi?id=472741
Tracking this for F11 here.

Warren Togami
wtogami at redhat.com



From forum at ru.bir.ru  Sun Nov 30 11:20:45 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Sun, 30 Nov 2008 14:20:45 +0300
Subject: Fedora 9 Spins
In-Reply-To: <49322329.7060404@fedoraproject.org>
References: <49322329.7060404@fedoraproject.org>
Message-ID: <ggtsud$740$1@ger.gmane.org>

Rahul Sundaram ?????:
> Hi
> 
> Can the Fedora 9 spins be not marked as beta anymore? One ticket doesn't 
> get any response. The other one was closed as a dup of the first one.
> 
> http://spins.fedoraproject.org/
> 
> 
> Rahul
> 
I have asked this question before.
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02902.html

but without any success...



From trever.adams at gmail.com  Sun Nov 30 12:05:07 2008
From: trever.adams at gmail.com (Trever L. Adams)
Date: Sun, 30 Nov 2008 05:05:07 -0700
Subject: Multiple packages from one tarball and spec file
In-Reply-To: <9497e9990811290751r77ab7475rec44982a4ff2e557@mail.gmail.com>
References: <493162FA.6030705@gmail.com>
	<9497e9990811290751r77ab7475rec44982a4ff2e557@mail.gmail.com>
Message-ID: <49328173.6070204@gmail.com>

Mat Booth wrote:
> Yes. There are plenty of packages in Fedora built straight from source control.
>
> (My package eclipse-epic does this, for example:
> http://cvs.fedoraproject.org/viewvc/rpms/eclipse-epic/  Take a look
> around Fedora's CVS for more examples.)
>
> I believe Jaroslav Reznik implied this was the case by linking to
> https://fedoraproject.org/wiki/Packaging/SourceURL#Using_Revision_Control
>
>   
Thank you. I will definitely look at your spec files and the link provided.

Many thanks,
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/20081130/d2b54951/attachment.sig>

From pertusus at free.fr  Sun Nov 30 14:22:37 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 30 Nov 2008 15:22:37 +0100
Subject: How to pack cron jobs?
In-Reply-To: <ggsd7q$5tn$1@ger.gmane.org>
References: <ggs9m8$rsg$1@ger.gmane.org>
	<46a038f90811291304k1ae4269i57f9a1dd0fc605b6@mail.gmail.com>
	<ggsd7q$5tn$1@ger.gmane.org>
Message-ID: <20081130142237.GA16722@free.fr>

On Sun, Nov 30, 2008 at 12:46:33AM +0300, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
> As I write above, /etc/cron.d provided only by cronie:
> # repoquery --whatprovides /etc/cron.d
> cronie-0:1.0-7.fc9.i386
> cronie-0:1.0-7.fc9.i386
> cronie-0:1.0-5.fc9.i386

I am currently preparing a fcron sub-package that would be completly
compatible with cronie and would watch /etc/cron.d (using inotifywait).
I'll keep the list informed.

--
Pat



From debarshi.ray at gmail.com  Sun Nov 30 14:23:13 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Sun, 30 Nov 2008 19:53:13 +0530
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <3170f42f0811170622q34247bd6u3dd410ff898c00d6@mail.gmail.com>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
	<20081108234812.6b327e4f@laposte.net>
	<3170f42f0811170622q34247bd6u3dd410ff898c00d6@mail.gmail.com>
Message-ID: <3170f42f0811300623j6462528drac3ce824264e72cb@mail.gmail.com>

I just started Gnubiff 2.2.10 builds for F-9, F-10 and devel.

Happy hacking,
Debarshi



From jwboyer at gmail.com  Sun Nov 30 14:40:47 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Sun, 30 Nov 2008 09:40:47 -0500
Subject: Fedora 9 Spins
In-Reply-To: <49322329.7060404@fedoraproject.org>
References: <49322329.7060404@fedoraproject.org>
Message-ID: <20081130144047.GA7943@zod.rchland.ibm.com>

On Sun, Nov 30, 2008 at 10:52:49AM +0530, Rahul Sundaram wrote:
> Hi
>
> Can the Fedora 9 spins be not marked as beta anymore? One ticket doesn't  

This is now fixed.  Thank Nigel Jones.

josh



From ivazqueznet at gmail.com  Sun Nov 30 15:04:26 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Sun, 30 Nov 2008 10:04:26 -0500
Subject: First 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: <1228057466.3835.105.camel@ignacio.lan>

The first cycle of rebuilds is done, and here's the results.

There were 7 packages that I didn't have permission to modify. I trust
that the maintainers will be gracious enough to modify and build them
for me:

beecrypt
certmaster
duplicity
func
pexpect
rpm
xulrunner

There were libtool errors in 5 packages. I suspect that this is due to
the new libtool in Rawhide:

avahi
lcms
libbtctl
libtunepimp
player

There were pkgconfig dep problems with 4 packages. I suspect that this
is due to rpm's new pkconfig detection code:

bigboard
brltty
gnome-games
nautilus-python

There were SRPM build failures in 9 packages:

elisa
gpodder
newt
orca
python-BeautifulSoup
python-configobj
python-mako
snake
wammu

There were broken dependencies in 3 packages:

gnome-python2-extras
Miro
python-igraph

There were 3 packages that expected Python, but not 2.6:

ice
ntfs-config
pypoker-eval

There were 3 packages that never completed their build. No, I have no
idea why:

opencv
python-cherrypy
python-cherrypy2

There were 2 packages that built, but that had runtime issues:

mx
python-mechanize

There were 29 packages with non-trivial code or packaging issues:

alchemist
csound
gdal
kdebindings
libopensync
libprelude
librra
libzzub
linkchecker
mapnik
net-snmp
olpcsound
presto-utils
python-cheetah
python-nevow
python-openid
python-psycopg
python-sqlalchemy
python-storm
pywebkitgtk
qgis
qpidc
rekall
ScientificPython
scipy
syck
sympy
tcl-snack
xapian-bindings

And of course, all those packages above are just the tip of the iceberg,
preventing a large number of packages from building (the package
blocking follows the blocked package):

awn-extras-applets avahi
bodhi python-cherrypy2
bzr-gtk nautilus-python
cohoba avahi
deskbar-applet avahi
gimmie avahi
glipper avahi
glom gnome-python2-extras
gnome-applets avahi
gnome-bluetooth libbtctl
gnome-packagekit xulrunner
gnome-python2-desktop avahi
graphviz avahi
guidance-power-manager kdebindings
hamster-applet avahi
hulahop xulrunner
ipa python-cherrypy2
istanbul gnome-python2-extras
PackageKit xulrunner
picviz avahi
planner avahi
plplot avahi
poker2d pypoker-eval
poker3d pypoker-eval
poker-engine pypoker-eval
poker-network pypoker-eval
prewikka python-cheetah
pyabiword avahi
pyflowtools rrdtool
python-biopython python-psycopg
python-libgmail python-mechanize
python-psycopg mx
python-tgcaptcha python-cherrypy2
python-turboflot python-cherrypy2
python-TurboMail python-cherrypy2
revelation avahi
rpy avahi
tinyerp python-psycopg
TurboGears python-cherrypy2

I've attached my raw data in case someone wants to analyze it.

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

PLEASE don't CC me; I'm already subscribed
-------------- next part --------------
#P permissions
#L libtool
#K pkgconfig
#S SRPM build failure
#D dependencies
#V version not expected
#? never finished building
#
#C non-trivial code or package error
alchemist C
avahi L
awn-extras-applets avahi
beecrypt P
bigboard K
bodhi python-cherrypy2
brltty K
bzr-gtk nautilus-python
certmaster P
cohoba avahi
csound C
deskbar-applet avahi
duplicity P
elisa S
func P
gdal C
gimmie avahi
glipper avahi
glom gnome-python2-extras
gnome-applets avahi
gnome-bluetooth libbtctl
gnome-games K
gnome-packagekit xulrunner
gnome-python2-desktop avahi
gnome-python2-extras D
gpodder S
graphviz avahi
guidance-power-manager kdebindings
hamster-applet avahi
hulahop xulrunner
ice V
ipa python-cherrypy2
istanbul gnome-python2-extras
kdebindings C
lcms L
libbtctl L
libopensync C
libprelude C
librra C
libtunepimp L
libzzub C
linkchecker C
mapnik C
Miro D
nautilus-python K
net-snmp C
newt S
ntfs-config V
olpcsound C
opencv ?
orca S
PackageKit xulrunner
pexpect P
picviz avahi
planner avahi
player L
plplot avahi
poker2d pypoker-eval
poker3d pypoker-eval
poker-engine pypoker-eval
poker-network pypoker-eval
presto-utils C
prewikka python-cheetah
pyabiword avahi
pyflowtools rrdtool
pypoker-eval V
python-BeautifulSoup S
python-biopython python-psycopg
python-cheetah C
python-cherrypy2 ?
python-cherrypy ?
python-configobj S
python-igraph D
python-libgmail python-mechanize
python-mako S
python-nevow C
python-openid C
python-psycopg mx
python-sqlalchemy C
python-storm C
python-tgcaptcha python-cherrypy2
python-turboflot python-cherrypy2
python-TurboMail python-cherrypy2
pywebkitgtk C
qgis C
qpidc C
rekall C
revelation avahi
rpm P
rpy avahi
ScientificPython C
scipy C
snake S
syck C
sympy C
tcl-snack C
tinyerp python-psycopg
TurboGears python-cherrypy2
wammu S
xapian-bindings C
xulrunner 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/20081130/a8bb6f75/attachment.sig>

From rawhide at fedoraproject.org  Sun Nov 30 15:32:57 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sun, 30 Nov 2008 15:32:57 +0000 (UTC)
Subject: rawhide report: 20081130 changes
Message-ID: <20081130153257.BB02F1F8252@releng2.fedora.phx.redhat.com>

Compose started at Sun Nov 30 06:01:11 UTC 2008

Updated Packages:

GMT-coastlines-1.10-2.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Orion Poplawski <orion at cora.nwra.com> 1.10-2
- Add Requires: GMT to get needed directories (bug #473592)

* Mon May  5 18:00:00 2008 Orion Poplawski <orion at cora.nwra.com> 1.10-1
- Update to 1.10


binutils-2.19.50.0.1-8.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Nick Clifton <nickc at redhat.com> 2.19.50.0.1-8
- Add build-id patch to ensure that section contents are incorporated
  into a build id.  (BZ 472152)


bip-0.7.5-2.fc11
----------------
* Sat Nov 29 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 0.7.5-2
- rebuilt

* Sat Nov 29 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 0.7.5-1
- 0.7.5
- Added support for running bip as system daemon
  (patches from Tom Hughes, thanks! - BugID: 471791)


dbxml-perl-2.0040016-0.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Milan Zazrivec <mzazrivec at redhat.com> - 2.0040016-0
- Rebased to latest dbxml upstream version (ver. 2.4.16)


dopewars-1.5.12-5.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Jussi Lehtola <jussi.lehtola at iki.fi> - 1.5.12-5
- Also fix release tag.

* Sat Nov 29 17:00:00 2008 Jussi Lehtola <jussi.lehtola at iki.fi> - 1.5.12-4
- Fix bug 473644, unowned directory.


e_dbus-0.5.0.050-1.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Pavel "Stalwart" Shevchuk <stlwrt at gmail.com> - 0.5.0.050-1
- New upstream snapshot


ecore-0.9.9.050-1.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Pavel "Stalwart" Shevchuk <stlwrt at gmail.com> - 0.9.9.050-1
- New upstream snapshot


edje-0.9.9.050-1.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Pavel "Stalwart" Shevchuk <stlwrt at gmail.com> - 0.9.9.050-1
- New upstream snapshot

* Sat Nov 29 17:00:00 2008 Pavel "Stalwart" Shevchuk <stlwrt at gmail.com> - 0.9.9.043-2
- Fixed unowned directories


eet-1.1.0-1.fc11
----------------
* Sat Nov 29 17:00:00 2008 Pavel "Stalwart" Shevchuk <stlwrt at gmail.com> - 1.1.0-1
- New upstream snapshot


efreet-0.5.0.050-1.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Pavel "Stalwart" Shevchuk <stlwrt at gmail.com> - 0.5.0.050-1
- New upstream snapshot


embryo-0.9.9.050-1.fc11
-----------------------
* Sat Nov 29 17:00:00 2008 Pavel "Stalwart" Shevchuk <stlwrt at gmail.com> - 0.9.9.050-1
- New upstream snapshot

* Sat Nov 29 17:00:00 2008 Pavel "Stalwart" Shevchuk <stlwrt at gmail.com> - 0.9.9.043-2
- Fixed unowned directory


epsilon-0.3.0.012-5.fc11
------------------------
* Thu Aug 28 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 0.3.0.012-5
- include unowned directory


evas-0.9.9.050-1.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Pavel "Stalwart" Shevchuk <stlwrt at gmail.com> - 0.9.9.050-1
- New upstream snapshot


evolution-zimbra-0.1.1-4.fc11
-----------------------------
* Sat Nov 29 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 0.1.1-4
- rebuild for dependencies


gambas2-2.9.0-2.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> 2.9.0-2
- rebuild for dependencies


gmpc-0.16.1-1.fc11
------------------
* Sat Nov 29 17:00:00 2008 Adrian Reber <adrian at lisas.de> - 0.16.1-1
- updated to 0.16.1


gnome-chemistry-utils-0.10.2-1.fc11
-----------------------------------
* Sat Nov 29 17:00:00 2008 Julian Sikorski <belegdol[at]gmail[dot]com> - 0.10.2-1
- Updated to 0.10.2


gnome-doc-utils-0.14.0-3.fc11
-----------------------------
* Sat Nov 29 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 0.14.0-3
- Add patch for RH bug #438638 (monospace <package> elements).

* Sun Nov 23 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.14.0-2
- Tweak %summary and %description


hunspell-en-0.20081129-1.fc11
-----------------------------
* Sat Nov 29 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20081129-1
- mozilla blog ... webmistresses signature range integrated


jakarta-commons-collections-3.2.1-1.fc11
----------------------------------------
* Sat Nov 29 17:00:00 2008 Devrim GUNDUZ <devrim at commandprompt.com> - 0:3.2.1-1
- Updated to 3.2.1
- Updated patch #4
- Own %dir /usr/lib/gcj/jakarta-commons-collections, per #473612.


jd-2.1.0-0.1.svn2528_trunk.fc11
-------------------------------
* Sun Nov 30 17:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2528


libdiscid-0.2.2-1.fc11
----------------------
* Sat Nov 29 17:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 0.2.2-1
- Update to latest upstream (0.2.2)


libmpd-0.16.1-1.fc11
--------------------
* Thu Nov 27 17:00:00 2008 Adrian Reber <adrian at lisas.de> - 0.16.1-1
- updated to 0.16.1


mail-notification-5.4-5.fc11
----------------------------
* Sat Nov 29 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 5.4-5
- rebuild for dependencies


mingw32-binutils-2.18.50_20080109_2-10.fc11
-------------------------------------------
* Sat Nov 29 17:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 2.18.50_20080109_2-10
- Must runtime-require mingw32-filesystem.

* Fri Nov 21 17:00:00 2008 Levente Farkas <lfarkas at lfarkas.org> - 2.18.50_20080109_2-9
- BR mingw32-filesystem >= 38


mono-tools-2.2-5.pre1.1.fc11
----------------------------
* Sat Nov 29 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> - 2.2-5.pre1.1
- Dropped the last patch and sedded it instead

* Sat Nov 29 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> - 2.2-5.pre1
- More patches. Crumbs - why can't these guys just use $(libdir)?

* Sat Nov 29 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> - 2.2-4.pre1
- More patches

* Sat Nov 29 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> - 2.2-3.pre1
- actually apply the configure patch helps...

* Wed Nov 26 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> - 2.2-2.pre1
- added configure patch

* Thu Nov 20 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> - 2.2-1.pre1
- bump to 2.2 preview 1
- fix patch files
- branch off monodoc documentation


pcb-0.20081128-1.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 0.20081128-1
- new upstream release
- restructuring docs, tutorials and examples
- Fixed Bug 472618 -  Must not include /usr/share/applications/mimeinfo.cache

* Sat Feb  9 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 0.20080202-2
- added gettext-devel as BR
- treat locales properly


perl-Ace-1.92-1.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 1.92-1
- Update to latest upstream (1.92)


perl-IPC-Run3-0.042-3.fc11
--------------------------
* Sat Nov 29 17:00:00 2008 Ralf Cors??pius <corsepiu at fedoraproject.org> 0.042-3
- Change Run a subprocess in batch mode.


perl-PDF-API2-0.72-2.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Bernard Johnson <bjohnson at symetrix.com> - 0.72-2
- [Bug 473556] Fix dejavu-* dependencies


perl-PDL-2.4.4-1.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Orion Poplawski <orion at cora.nwra.com> - 2.4.4-1
- Update to 2.4.4
- New source URL
- Update cleanup, test, x86_64, and Xext patches for 2.4.4
- Drop gsl, perl510, noDISPLAY and missingfnc patches fixed upstream
- Add BR proj-nad needed for tests
- Add patch to fix plplot test with latest plplot


postgis-1.3.4-1.fc11
--------------------
* Sat Nov 29 17:00:00 2008 Devrim GUNDUZ <devrim at gunduz.org> - 1.3.4-1
- Update to 1.3.4


projectM-pulseaudio-1.2.0-3.fc11
--------------------------------

python-psycopg2-2.0.8-1.fc11
----------------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 2.0.7-3
- Rebuild for Python 2.6

* Sat Nov 29 17:00:00 2008 Devrim GUNDUZ <devrim at gunduz.org> - 2.0.8-1
- Update to 2.0.8

* Thu May 29 18:00:00 2008 Todd Zullinger <tmz at pobox.com> - 2.0.7-2
- fix license tags


rmap-1.2-4.fc11
---------------
* Fri Aug 29 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 1.2-4
- Include /usr/share/rmap directory


rpm-4.6.0-0.rc2.2
-----------------
* Sat Nov 29 17:00:00 2008 Panu Matilainen <pmatilai at redhat.com>
- update to 4.6.0-rc2
- fixes #471820, #473167, #469355, #468319, #472507, #247374, #426672, #444661
- enable automatic generation of pkg-config and libtool dependencies #465377


sqlite-3.6.6.2-1.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Panu Matilainen <pmatilai at redhat.com> - 3.6.6.2-1
- update to 3.6.6.2


sugar-toolkit-0.83.2-3.fc11
---------------------------
* Sat Nov 29 17:00:00 2008 Marco Pesenti Gritti <mpg at redhat.com> - 0.83.2-3
- Fix session shutdown


sugar-turtleart-19-1.fc11
-------------------------
* Sat Nov 29 17:00:00 2008 Marco Pesenti Gritti <mpg at redhat.com> - 19-1
- Rebased to fix crash on startup with sugar 0.83


xmms-1.2.11-3.20071117cvs.fc11
------------------------------
* Sat Nov 29 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 1.2.11-20071117cvs-3
- Fix multilib patch

* Thu Sep 18 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 1.2.11-20071117cvs-2
- Additional requires


Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 40
Broken deps for i386
----------------------------------------------------------
	autodir-0.99.9-5.fc9.i386 requires libltdl.so.3
	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
	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
	kdebindings-4.1.2-2.fc10.i386 requires libqscintilla2.so.4
	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
	mono-cecil-flowanalysis-0.1-0.6.20080409svn100264.fc11.i386 requires mono(Mono.Cecil) = 0:0.6.8.8607
	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
	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
----------------------------------------------------------
	autodir-0.99.9-5.fc9.x86_64 requires libltdl.so.3()(64bit)
	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
	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
	kdebindings-4.1.2-2.fc10.i386 requires libqscintilla2.so.4
	kdebindings-4.1.2-2.fc10.x86_64 requires libqscintilla2.so.4()(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)
	mono-cecil-flowanalysis-0.1-0.6.20080409svn100264.fc11.x86_64 requires mono(Mono.Cecil) = 0:0.6.8.8607
	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)
	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
----------------------------------------------------------
	autodir-0.99.9-5.fc9.ppc requires libltdl.so.3
	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-1.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
	kdebindings-4.1.2-2.fc10.ppc requires libqscintilla2.so.4
	kdebindings-4.1.2-2.fc10.ppc64 requires libqscintilla2.so.4()(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)
	mono-cecil-flowanalysis-0.1-0.6.20080409svn100264.fc11.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	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
	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
----------------------------------------------------------
	autodir-0.99.9-5.fc9.ppc64 requires libltdl.so.3()(64bit)
	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-1.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
	kdebindings-4.1.2-2.fc10.ppc64 requires libqscintilla2.so.4()(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(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)
	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 jamatos at fc.up.pt  Sun Nov 30 16:43:04 2008
From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=)
Date: Sun, 30 Nov 2008 16:43:04 +0000
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: <200811301643.04692.jamatos@fc.up.pt>

On Sunday 30 November 2008 15:04:26 Ignacio Vazquez-Abrams wrote:
> There were 29 packages with non-trivial code or packaging issues:
>
> ScientificPython
> scipy

AFAIR numpy still does not work well with python 2.6, the same applies to 
scipy.

It is expected a new release for numpy that will play well with 2.6 followed 
by a scipy release with the same purpose.

-- 
Jos? Ab?lio



From fedora at leemhuis.info  Sun Nov 30 16:54:38 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sun, 30 Nov 2008 17:54:38 +0100
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: <4932C54E.3000901@leemhuis.info>

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? Then packagers can easily search 
for their username in the report instead of reading it completely -- 
which I guess a lot of contributors won't do. And even if they do: 
Having the username lowers the chance they miss their packages (which I 
guess can easily happen as soon as you maintain more than 15 or 30 
packages).

CU
knurd



From valent.turkovic at gmail.com  Sun Nov 30 17:05:10 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Sun, 30 Nov 2008 18:05:10 +0100
Subject: new namespace?
In-Reply-To: <20081129231132.GB8426@localhost.localdomain>
References: <64b14b300811291159u7072cd6s3a79b283ada93762@mail.gmail.com>
	<20081129231132.GB8426@localhost.localdomain>
Message-ID: <64b14b300811300905l23ce587aq6d05c7055ddfc398@mail.gmail.com>

2008/11/30 Paul W. Frields <stickster at gmail.com>:
> On Sat, Nov 29, 2008 at 08:59:44PM +0100, Valent Turkovic wrote:
>> Hi,
>> I'm wondering if there was a discussion about this already so excuse
>> my question if it was. Is there a namespace on Fedora wiki for guides,
>> howtos, tutorials and similar articles?
>>
>> Where can and how see all tutorials, howtos and guides for Fedora on
>> Fedora wiki?
>
> No, and there should not be.  The Docs team and the folks working on
> wiki revitalization discussed this some time ago.  The wiki itself is
> supposed to be the place for those guides, not a subset thereof.
> Guides should not be kept in some "Howtos/Foobar" oddball hierarchy,
> but rather as "How_to_do_foobar" which makes it easier for people to
> find what they're looking for.

I understand you point but that is somebody doesn't want to search for
anything but wants to see what cool things can be done with Fedora. If
there would be someway of showing all howtos in one place that would
be great. Why? If somebody made some great Fedora tutorial or howto I
could follow that guide and learn. If I don't know what kind of guides
there are how am I supposed to search them?

You have an idea that people come to wiki only when then need to find
something, but what if they are coming on wiki for inspiration of for
some new thing to learn and not with definitive "I need to find how to
make printing work".

Hope this clarifies a bit why I still really strongly think that there
should be some way of categorising guides.

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 naheemzaffar at gmail.com  Sun Nov 30 17:15:27 2008
From: naheemzaffar at gmail.com (Naheem Zaffar)
Date: Sun, 30 Nov 2008 17:15:27 +0000
Subject: new namespace?
In-Reply-To: <64b14b300811300905l23ce587aq6d05c7055ddfc398@mail.gmail.com>
References: <64b14b300811291159u7072cd6s3a79b283ada93762@mail.gmail.com>
	<20081129231132.GB8426@localhost.localdomain>
	<64b14b300811300905l23ce587aq6d05c7055ddfc398@mail.gmail.com>
Message-ID: <3adc77210811300915q4a124827y74a42c48d6cd8fbd@mail.gmail.com>

I would use Google for the search. It is almost always better than any home
grown solution, and it will also show other tutorials.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081130/44b88270/attachment.htm>

From forum at ru.bir.ru  Sun Nov 30 17:46:20 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Sun, 30 Nov 2008 20:46:20 +0300
Subject: How to pack cron jobs?
In-Reply-To: <20081130142237.GA16722@free.fr>
References: <ggs9m8$rsg$1@ger.gmane.org>	<46a038f90811291304k1ae4269i57f9a1dd0fc605b6@mail.gmail.com>	<ggsd7q$5tn$1@ger.gmane.org>
	<20081130142237.GA16722@free.fr>
Message-ID: <ggujhc$68k$1@ger.gmane.org>

Patrice Dumas ?????:
> On Sun, Nov 30, 2008 at 12:46:33AM +0300, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
>> As I write above, /etc/cron.d provided only by cronie:
>> # repoquery --whatprovides /etc/cron.d
>> cronie-0:1.0-7.fc9.i386
>> cronie-0:1.0-7.fc9.i386
>> cronie-0:1.0-5.fc9.i386
> 
> I am currently preparing a fcron sub-package that would be completly
> compatible with cronie and would watch /etc/cron.d (using inotifywait).
> I'll keep the list informed.
> 
> --
> Pat
> 
Great news. In this case really may be best solution add /etc/cron.d 
into crontab package?



From jamatos at fc.up.pt  Sun Nov 30 17:45:38 2008
From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=)
Date: Sun, 30 Nov 2008 17:45:38 +0000
Subject: First Report (was: Re: Python 2.6 clear for Rawhide)
In-Reply-To: <200811301643.04692.jamatos@fc.up.pt>
References: <1227923821.3835.39.camel@ignacio.lan>
	<1228057466.3835.105.camel@ignacio.lan>
	<200811301643.04692.jamatos@fc.up.pt>
Message-ID: <200811301745.38286.jamatos@fc.up.pt>

On Sunday 30 November 2008 16:43:04 Jos? Matos wrote:
> It is expected a new release for numpy that will play well with 2.6
> followed by a scipy release with the same purpose.

FWIW the new numpy release is expected this year (only one more month missing) 
so the new scipy release will happen in January (with the usual caveats 
regarding release estimation).

-- 
Jos? Ab?lio



From chris.stone at gmail.com  Sun Nov 30 18:01:31 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Sun, 30 Nov 2008 10:01:31 -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: <d9c612bf0811301001h437eb0dbi8935b246ae4ab9cf@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

Hi, are you installing python as /usr/bin/python, or /usr/bin/python2.6?

The build.log for pypoker-eval has several lines that contain
sh: /usr/bin/python: No such file or directory

and the python.m4 file checks for python, but not python2.6.

So, I was just wondering if maybe you were installing it as
/usr/bin/python2.6 or something, and that is why it was failing the
checks.



From pmatilai at laiskiainen.org  Sun Nov 30 18:06:08 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Sun, 30 Nov 2008 20:06:08 +0200 (EET)
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: <alpine.LFD.2.00.0811302003090.10209@turre.koti.laiskiainen.org>

On Sun, 30 Nov 2008, Ignacio Vazquez-Abrams wrote:

> The first cycle of rebuilds is done, and here's the results.
>
> There were 7 packages that I didn't have permission to modify. I trust
> that the maintainers will be gracious enough to modify and build them
> for me:
>
> beecrypt
> certmaster
> duplicity
> func
> pexpect
> rpm

Hmm, I just rebuilt rpm but python 2.5 got pulled into the build, not 2.6.

 	- Panu -



From chris.stone at gmail.com  Sun Nov 30 18:27:55 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Sun, 30 Nov 2008 10:27:55 -0800
Subject: First Report (was: Re: Python 2.6 clear for Rawhide)
In-Reply-To: <alpine.LFD.2.00.0811302003090.10209@turre.koti.laiskiainen.org>
References: <1227923821.3835.39.camel@ignacio.lan>
	<1228057466.3835.105.camel@ignacio.lan>
	<alpine.LFD.2.00.0811302003090.10209@turre.koti.laiskiainen.org>
Message-ID: <d9c612bf0811301027raa8210bkca39f9cc9e2ef066@mail.gmail.com>

On Sun, Nov 30, 2008 at 10:06 AM, Panu Matilainen
<pmatilai at laiskiainen.org> wrote:
> On Sun, 30 Nov 2008, Ignacio Vazquez-Abrams wrote:
>
>> The first cycle of rebuilds is done, and here's the results.
>>
>> There were 7 packages that I didn't have permission to modify. I trust
>> that the maintainers will be gracious enough to modify and build them
>> for me:
>>
>> beecrypt
>> certmaster
>> duplicity
>> func
>> pexpect
>> rpm
>
> Hmm, I just rebuilt rpm but python 2.5 got pulled into the build, not 2.6.
>

Did you use dist-f11-python?



From dominik at greysector.net  Sun Nov 30 18:34:34 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Sun, 30 Nov 2008 19:34:34 +0100
Subject: new namespace?
In-Reply-To: <64b14b300811300905l23ce587aq6d05c7055ddfc398@mail.gmail.com>
References: <64b14b300811291159u7072cd6s3a79b283ada93762@mail.gmail.com>
	<20081129231132.GB8426@localhost.localdomain>
	<64b14b300811300905l23ce587aq6d05c7055ddfc398@mail.gmail.com>
Message-ID: <20081130183433.GA32002@mokona.greysector.net>

On Sunday, 30 November 2008 at 18:05, Valent Turkovic wrote:
> 2008/11/30 Paul W. Frields <stickster at gmail.com>:
> > On Sat, Nov 29, 2008 at 08:59:44PM +0100, Valent Turkovic wrote:
> >> Hi,
> >> I'm wondering if there was a discussion about this already so excuse
> >> my question if it was. Is there a namespace on Fedora wiki for guides,
> >> howtos, tutorials and similar articles?
> >>
> >> Where can and how see all tutorials, howtos and guides for Fedora on
> >> Fedora wiki?
> >
> > No, and there should not be.  The Docs team and the folks working on
> > wiki revitalization discussed this some time ago.  The wiki itself is
> > supposed to be the place for those guides, not a subset thereof.
> > Guides should not be kept in some "Howtos/Foobar" oddball hierarchy,
> > but rather as "How_to_do_foobar" which makes it easier for people to
> > find what they're looking for.
> 
> I understand you point but that is somebody doesn't want to search for
> anything but wants to see what cool things can be done with Fedora. If
> there would be someway of showing all howtos in one place that would
> be great. Why? If somebody made some great Fedora tutorial or howto I
> could follow that guide and learn. If I don't know what kind of guides
> there are how am I supposed to search them?

Isn't that what Category:Foo pages are for?

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 pmatilai at laiskiainen.org  Sun Nov 30 19:42:24 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Sun, 30 Nov 2008 21:42:24 +0200 (EET)
Subject: First Report (was: Re: Python 2.6 clear for Rawhide)
In-Reply-To: <d9c612bf0811301027raa8210bkca39f9cc9e2ef066@mail.gmail.com>
References: <1227923821.3835.39.camel@ignacio.lan>
	<1228057466.3835.105.camel@ignacio.lan>
	<alpine.LFD.2.00.0811302003090.10209@turre.koti.laiskiainen.org>
	<d9c612bf0811301027raa8210bkca39f9cc9e2ef066@mail.gmail.com>
Message-ID: <alpine.LFD.2.00.0811302140250.10209@turre.koti.laiskiainen.org>

On Sun, 30 Nov 2008, Christopher Stone wrote:

> On Sun, Nov 30, 2008 at 10:06 AM, Panu Matilainen
> <pmatilai at laiskiainen.org> wrote:
>> On Sun, 30 Nov 2008, Ignacio Vazquez-Abrams wrote:
>>
>>> The first cycle of rebuilds is done, and here's the results.
>>>
>>> There were 7 packages that I didn't have permission to modify. I trust
>>> that the maintainers will be gracious enough to modify and build them
>>> for me:
>>>
>>> beecrypt
>>> certmaster
>>> duplicity
>>> func
>>> pexpect
>>> rpm
>>
>> Hmm, I just rebuilt rpm but python 2.5 got pulled into the build, not 2.6.
>>
>
> Did you use dist-f11-python?

Duh, no. I saw something like "python 2.6 ready for rawhide" and a bunch 
of "rebuilt for python 2.6" messages and assumed 2.6 was already in 
rawhide. It would sometimes be useful to read more than a subject... :)

Anyway, rpm built for dist-f11-python now.

 	- Panu -



From Curtis at GreenKey.net  Sun Nov 30 20:22:07 2008
From: Curtis at GreenKey.net (Curtis Doty)
Date: Sun, 30 Nov 2008 12:22:07 -0800 (PST)
Subject: starting Fedora Server SIG
In-Reply-To: <1226491831.3752.298.camel@beck.corsepiu.local>
References: <1226429441.3593.77.camel@eagle.danny.cz>
	<200811111317.15198.dennis@ausil.us>
	<4919DC9C.1030009@gmail.com> <1226480816.3638.19.camel@eagle.danny.cz>
	<1226485422.3638.22.camel@eagle.danny.cz>
	<20081112111712.GB3142@free.fr>
	<385e751ee20fd7d39b74980459ab14f3.squirrel@arekh.dyndns.org>
	<778179b00811120400s5fda1277y2130ceddeb9d0422@mail.gmail.com>
	<1226491831.3752.298.camel@beck.corsepiu.local>
Message-ID: <20081130202208.658906F064@alopias.GreenKey.net>

Nov 12 Ralf Corsepius said:

> On Wed, 2008-11-12 at 14:00 +0200, Aioanei Rares wrote:
>>
>>
>> On Wed, Nov 12, 2008 at 1:58 PM, Nicolas Mailhot
>> <nicolas.mailhot at laposte.net> wrote:
>>
>> LSB requests qt?
>
> The LSB Desktop specs[1] requires them.
>
> The LSB Core specs[2] don't.
>
> I'd say this is a badly packaged package, which is in dire need of being
> split ;)
>
>
> Ralf
>
>
> [1]
> http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Desktop-generic/LSB-Desktop-generic/book1.html
>
> [2]
> http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/book1.html
>

Patch here. https://bugzilla.redhat.com/show_bug.cgi?id=245494#c3

Split off -desktop and -printing sub-packages. Not sure what else this 
might break.

../C



From mdehaan at redhat.com  Sun Nov 30 20:38:11 2008
From: mdehaan at redhat.com (Michael DeHaan)
Date: Sun, 30 Nov 2008 15:38:11 -0500
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: <4932F9B3.7060306@redhat.com>

Ignacio Vazquez-Abrams wrote:
> The first cycle of rebuilds is done, and here's the results.
>
> There were 7 packages that I didn't have permission to modify. I trust
> that the maintainers will be gracious enough to modify and build them
> for me:
>
> beecrypt
> certmaster
> duplicity
> func
> pexpect
> rpm
> xulrunner
>   

We can probably see about Func & certmaster rebuilds next week.

I am unclear on what you would have to modify as it seems you just need 
to rebuild all the packages.

--Michael

> There were libtool errors in 5 packages. I suspect that this is due to
> the new libtool in Rawhide:
>
> avahi
> lcms
> libbtctl
> libtunepimp
> player
>
> There were pkgconfig dep problems with 4 packages. I suspect that this
> is due to rpm's new pkconfig detection code:
>
> bigboard
> brltty
> gnome-games
> nautilus-python
>
> There were SRPM build failures in 9 packages:
>
> elisa
> gpodder
> newt
> orca
> python-BeautifulSoup
> python-configobj
> python-mako
> snake
> wammu
>
> There were broken dependencies in 3 packages:
>
> gnome-python2-extras
> Miro
> python-igraph
>
> There were 3 packages that expected Python, but not 2.6:
>
> ice
> ntfs-config
> pypoker-eval
>
> There were 3 packages that never completed their build. No, I have no
> idea why:
>
> opencv
> python-cherrypy
> python-cherrypy2
>
> There were 2 packages that built, but that had runtime issues:
>
> mx
> python-mechanize
>
> There were 29 packages with non-trivial code or packaging issues:
>
> alchemist
> csound
> gdal
> kdebindings
> libopensync
> libprelude
> librra
> libzzub
> linkchecker
> mapnik
> net-snmp
> olpcsound
> presto-utils
> python-cheetah
> python-nevow
> python-openid
> python-psycopg
> python-sqlalchemy
> python-storm
> pywebkitgtk
> qgis
> qpidc
> rekall
> ScientificPython
> scipy
> syck
> sympy
> tcl-snack
> xapian-bindings
>
> And of course, all those packages above are just the tip of the iceberg,
> preventing a large number of packages from building (the package
> blocking follows the blocked package):
>
> awn-extras-applets avahi
> bodhi python-cherrypy2
> bzr-gtk nautilus-python
> cohoba avahi
> deskbar-applet avahi
> gimmie avahi
> glipper avahi
> glom gnome-python2-extras
> gnome-applets avahi
> gnome-bluetooth libbtctl
> gnome-packagekit xulrunner
> gnome-python2-desktop avahi
> graphviz avahi
> guidance-power-manager kdebindings
> hamster-applet avahi
> hulahop xulrunner
> ipa python-cherrypy2
> istanbul gnome-python2-extras
> PackageKit xulrunner
> picviz avahi
> planner avahi
> plplot avahi
> poker2d pypoker-eval
> poker3d pypoker-eval
> poker-engine pypoker-eval
> poker-network pypoker-eval
> prewikka python-cheetah
> pyabiword avahi
> pyflowtools rrdtool
> python-biopython python-psycopg
> python-libgmail python-mechanize
> python-psycopg mx
> python-tgcaptcha python-cherrypy2
> python-turboflot python-cherrypy2
> python-TurboMail python-cherrypy2
> revelation avahi
> rpy avahi
> tinyerp python-psycopg
> TurboGears python-cherrypy2
>
> I've attached my raw data in case someone wants to analyze it.
>
>   



From pertusus at free.fr  Sun Nov 30 21:07:25 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 30 Nov 2008 22:07:25 +0100
Subject: How to pack cron jobs?
In-Reply-To: <ggujhc$68k$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>
Message-ID: <20081130210724.GA2649@free.fr>

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



From ivazqueznet at gmail.com  Sun Nov 30 21:23:19 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Sun, 30 Nov 2008 16:23:19 -0500
Subject: First Report
In-Reply-To: <4932C54E.3000901@leemhuis.info>
References: <1227923821.3835.39.camel@ignacio.lan>
	<1228057466.3835.105.camel@ignacio.lan>
	<4932C54E.3000901@leemhuis.info>
Message-ID: <1228080199.3835.115.camel@ignacio.lan>

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.

-- 
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/11847323/attachment.sig>

From ivazqueznet at gmail.com  Sun Nov 30 21:54:33 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Sun, 30 Nov 2008 16:54:33 -0500
Subject: First set of names (was: Re: First Report)
In-Reply-To: <1228080199.3835.115.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>
Message-ID: <1228082073.3835.122.camel@ignacio.lan>

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. Here we are:

#P permissions
#L libtool
#K pkgconfig
#S SRPM build failure
#D dependencies
#V version not expected
#? never finished building
#R runtime issues with other packages
#C non-trivial code or package error
#
aconway qpidc C
alexlan python-biopython python-psycopg
awjb lcms L
awjb libopensync C
awjb librra C
caolanm planner avahi
davidz orca S
dcbw csound C
deji gimmie avahi
denis glom gnome-python2-extras
devrim python-psycopg mx
gecko-maint xulrunner P
ivazquez pywebkitgtk C
jamatos rpy avahi
jcollie python-openid C
jdieter presto-utils C
jima graphviz avahi
jlaska snake S
jmoskovc gnome-bluetooth libbtctl
jmoskovc libbtctl L
jsafrane net-snmp C
jspaleta gpodder S
jspaleta istanbul gnome-python2-extras
jspaleta revelation avahi
jspaleta ScientificPython C
jspaleta scipy C
kasal brltty K
konradm sympy C
kwizart python-BeautifulSoup S
kylev python-mako S
laxathom ntfs-config V
laxathom wammu S
lennart avahi L
lmacken bodhi python-cherrypy2
lmacken deskbar-applet avahi
lmacken python-cherrypy ?
lmacken python-configobj S
lmacken python-mechanize R
lmacken python-tgcaptcha python-cherrypy2
lmacken python-turboflot python-cherrypy2
lmacken python-TurboMail python-cherrypy2
lmacken TurboGears python-cherrypy2
maxx hamster-applet avahi
mbarnes gnome-python2-desktop avahi
mbarnes gnome-python2-extras D
mdehaan certmaster P
mdehaan func P
mef ice V
mikeb python-cheetah C
mikep linkchecker C
mlichvar newt S
mpg hulahop xulrunner
mpg xapian-bindings C
nbecker python-igraph D
oliver syck C
orion plplot avahi
orphan libzzub C
pfj mx R
phuang awn-extras-applets avahi
pmatilai rpm P
rakesh opencv ?
rcritten ipa python-cherrypy2
rdieter guidance-power-manager kdebindings
rdieter libtunepimp L
rezso gdal C
rezso mapnik C
rhughes gnome-packagekit xulrunner
rhughes PackageKit xulrunner
robert beecrypt P
robert duplicity P
robert pexpect P
rstrode gnome-applets avahi
rstrode gnome-games K
salimma python-storm C
sgrubb libprelude C
sgrubb prewikka python-cheetah
sharkcz tinyerp python-psycopg
silfreed qgis C
splinux glipper avahi
spot rekall C
spot tcl-snack C
stingray pyflowtools rrdtool
than kdebindings C
theinric picviz avahi
thias elisa S
thias python-nevow C
timn player L
tjikkun cohoba avahi
toshio bzr-gtk nautilus-python
toshio python-cherrypy2 ?
toshio python-sqlalchemy C
trondd nautilus-python K
tscherf Miro D
turki python-libgmail python-mechanize
twaugh alchemist C
uwog pyabiword avahi
veplaini olpcsound C
walters bigboard K
xulchris poker2d pypoker-eval
xulchris poker3d pypoker-eval
xulchris poker-engine pypoker-eval
xulchris poker-network pypoker-eval
xulchris pypoker-eval 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/20081130/c1ee64af/attachment.sig>

From ivazqueznet at gmail.com  Sun Nov 30 21:57:55 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Sun, 30 Nov 2008 16:57:55 -0500
Subject: First Report
In-Reply-To: <4932F9B3.7060306@redhat.com>
References: <1227923821.3835.39.camel@ignacio.lan>
	<1228057466.3835.105.camel@ignacio.lan> <4932F9B3.7060306@redhat.com>
Message-ID: <1228082275.3835.125.camel@ignacio.lan>

On Sun, 2008-11-30 at 15:38 -0500, Michael DeHaan wrote:
> Ignacio Vazquez-Abrams wrote:
> > The first cycle of rebuilds is done, and here's the results.
> >
> > There were 7 packages that I didn't have permission to modify. I trust
> > that the maintainers will be gracious enough to modify and build them
> > for me:
> >
> > beecrypt
> > certmaster
> > duplicity
> > func
> > pexpect
> > rpm
> > xulrunner
> >   
> 
> We can probably see about Func & certmaster rebuilds next week.
> 
> I am unclear on what you would have to modify as it seems you just need 
> to rebuild all the packages.

The optimal case would be just a release bump. Just slightly more
difficult would be if the package hardcodes the egg-info path. Anything
else... may need more work. Especially if your Python code uses the new
reserved words in 2.6.

-- 
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/6b7fdd0c/attachment.sig>

From valent.turkovic at gmail.com  Sun Nov 30 22:02:34 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Sun, 30 Nov 2008 23:02:34 +0100
Subject: new namespace?
In-Reply-To: <20081130183433.GA32002@mokona.greysector.net>
References: <64b14b300811291159u7072cd6s3a79b283ada93762@mail.gmail.com>
	<20081129231132.GB8426@localhost.localdomain>
	<64b14b300811300905l23ce587aq6d05c7055ddfc398@mail.gmail.com>
	<20081130183433.GA32002@mokona.greysector.net>
Message-ID: <64b14b300811301402h52b3f19ds68e2fb64f201095@mail.gmail.com>

On Sun, Nov 30, 2008 at 7:34 PM, Dominik 'Rathann' Mierzejewski
<dominik at greysector.net> wrote:
> On Sunday, 30 November 2008 at 18:05, Valent Turkovic wrote:
>> 2008/11/30 Paul W. Frields <stickster at gmail.com>:
>> > On Sat, Nov 29, 2008 at 08:59:44PM +0100, Valent Turkovic wrote:
>> >> Hi,
>> >> I'm wondering if there was a discussion about this already so excuse
>> >> my question if it was. Is there a namespace on Fedora wiki for guides,
>> >> howtos, tutorials and similar articles?
>> >>
>> >> Where can and how see all tutorials, howtos and guides for Fedora on
>> >> Fedora wiki?
>> >
>> > No, and there should not be.  The Docs team and the folks working on
>> > wiki revitalization discussed this some time ago.  The wiki itself is
>> > supposed to be the place for those guides, not a subset thereof.
>> > Guides should not be kept in some "Howtos/Foobar" oddball hierarchy,
>> > but rather as "How_to_do_foobar" which makes it easier for people to
>> > find what they're looking for.
>>
>> I understand you point but that is somebody doesn't want to search for
>> anything but wants to see what cool things can be done with Fedora. If
>> there would be someway of showing all howtos in one place that would
>> be great. Why? If somebody made some great Fedora tutorial or howto I
>> could follow that guide and learn. If I don't know what kind of guides
>> there are how am I supposed to search them?
>
> Isn't that what Category:Foo pages are for?
>
> Regards,
> R.

Maybe categories is what I'm looking for :) Could somebody give me an
example how categories are user on Fedora wiki?

Thank you in advance,
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 nicolas.mailhot at laposte.net  Sun Nov 30 23:14:39 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 01 Dec 2008 00:14:39 +0100
Subject: new namespace?
In-Reply-To: <64b14b300811301402h52b3f19ds68e2fb64f201095@mail.gmail.com>
References: <64b14b300811291159u7072cd6s3a79b283ada93762@mail.gmail.com>
	<20081129231132.GB8426@localhost.localdomain>
	<64b14b300811300905l23ce587aq6d05c7055ddfc398@mail.gmail.com>
	<20081130183433.GA32002@mokona.greysector.net>
	<64b14b300811301402h52b3f19ds68e2fb64f201095@mail.gmail.com>
Message-ID: <1228086879.29458.18.camel@arekh.okg>

Le dimanche 30 novembre 2008 ? 23:02 +0100, Valent Turkovic a ?crit :

> Maybe categories is what I'm looking for :) Could somebody give me an
> example how categories are user on Fedora wiki?

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

-- 
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/fc425b8e/attachment.sig>

From kevin.kofler at chello.at  Sun Nov 30 23:34:32 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 01 Dec 2008 00:34:32 +0100
Subject: EVR problems in upgrading from F9 to F10
References: <29fee02b0811291707j550ddd16y14cf1ffcbe3bc972@mail.gmail.com>
Message-ID: <ggv7u8$3pq$1@ger.gmane.org>

Andrea Musuruane wrote:
> qt-4.4.3-5.fc9.x86_64
> qt-x11-4.4.3-5.fc9.x86_64

Oops... Fix queued for the next push:
https://admin.fedoraproject.org/updates/qt-4.4.3-6.fc10
Sorry for that in the name of the KDE SIG.

        Kevin Kofler



From forum at ru.bir.ru  Sun Nov 30 23:42:25 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Mon, 01 Dec 2008 02:42:25 +0300
Subject: How to pack cron jobs?
In-Reply-To: <20081130210724.GA2649@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>
Message-ID: <ggv8d5$539$1@ger.gmane.org>

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.

I thing in any way "Require crontabs" must be in both crons.
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)??



From stickster at gmail.com  Thu Nov 27 18:39:11 2008
From: stickster at gmail.com (Paul Frields)
Date: Thu, 27 Nov 2008 13:39:11 -0500
Subject: Fedora Board IRC meeting 1900 UTC 2008-12-02
Message-ID: <ef93afcf0811271039i38162429qc27a96060e3cedb4@mail.gmail.com>

The Board is holding its monthly public meeting on Tuesday, 2 December
2008, at 1900 UTC on IRC Freenode.  The Board has settled on a
schedule that puts these public IRC meetings on the first Tuesday of
each month.  Therefore, the next following public meeting will be on 6
January 2008.  For these meetings, the public is invited to do the
following:

* Join #fedora-board-meeting to see the Board's conversation.  This
channel is read-only for non-Board members.
* Join #fedora-board-public to discuss topics and post questions.
This channel is read/write for everyone.

The moderator will direct questions from the #fedora-board-public
channel to the Board members at #fedora-board-meeting.  This should
limit confusion and ensure our logs are useful to everyone.

We look forward to seeing you at the meeting.

Paul

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce