From christoph.wickert at googlemail.com Sun Nov 1 01:45:10 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Sun, 01 Nov 2009 02:45:10 +0100 Subject: Claudio Tomasoni is now MIA Message-ID: <1257039910.12503.59.camel@wicktop.localdomain> This is a follow-up to my mail from October 9th [1] As per unresponsive package maintainer policy, Claudio is now officially considered missing in action and his packages [2] will be orphaned. qtoctave - Frontend for Octave 1 Bug: 2 Menu entries https://bugzilla.redhat.com/show_bug.cgi?id=486753 octaviz - 3D visualization system for Octave no open bugs but fails to build with vtk > 5.0 https://www.redhat.com/archives/fedora-devel-list/2009-October/msg00657.html tennix - A simple tennis game 1 Open Bug: Update to 1.0 https://bugzilla.redhat.com/show_bug.cgi?id=500068 If you are interested in any of these packages, please go ahead and grab them at [2]. Regards, Christoph [1] https://www.redhat.com/archives/fedora-devel-list/2009-October/msg00416.html [2] https://admin.fedoraproject.org/pkgdb/users/packages/claudiotomasoni From jonstanley at gmail.com Sun Nov 1 05:55:13 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Sun, 1 Nov 2009 01:55:13 -0400 Subject: How to add upstream developer as a (co)maintainer of the existing application? In-Reply-To: References: Message-ID: On Sat, Oct 31, 2009 at 1:31 PM, Peter Lemenkov wrote: > I remember, that if Redhat hires someone from upstream, then no > additional procedures with review requests and sponsorship needed (at > least visible to others, outside Redhat) - (s)he just started to be a > (co)maintainer. Anyone that wishes to maintain a package in Fedora, regardless of their employer, has to be sponsored. It's up to the individual sponsor of an individual what procedures (or lack thereof) must be followed in order to sponsor a person, but one would hope that there's at least *some* sort of filter there. Just because someone is a great developer doesn't make them a good packager (and vice versa). All that said, provided this person demonstrated some basic knowledge of Fedora packaging guidelines, I'd be willing to sponsor them. In that case, I'd also want watch* on the package(s) in question just to keep an eye on them :) From rawhide at fedoraproject.org Sun Nov 1 10:26:25 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sun, 1 Nov 2009 10:26:25 +0000 Subject: rawhide report: 20091101 changes Message-ID: <20091101102625.GA28802@releng2.fedora.phx.redhat.com> Compose started at Sun Nov 1 06:15:07 UTC 2009 Broken deps for i386 ---------------------------------------------------------- 1:nant-0.85-30.fc12.i686 requires mono(NDoc.Core) = 0:1.3.3498.0 Broken deps for x86_64 ---------------------------------------------------------- 1:nant-0.85-30.fc12.x86_64 requires mono(NDoc.Core) = 0:1.3.3498.0 Updated Packages: kdepim-4.3.2-2.fc12 ------------------- * Fri Oct 30 2009 Kevin Kofler - 4.3.2-2 - unbreak ktimetracker (#532055, kde#209570, patch from upstream) Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 1 From sergio.pasra at gmail.com Sun Nov 1 13:56:19 2009 From: sergio.pasra at gmail.com (Sergio Pascual) Date: Sun, 1 Nov 2009 14:56:19 +0100 Subject: Strange dependency of cpl in rawhide Message-ID: <89b36810911010556j43469fd2kb93dee7878002628@mail.gmail.com> Hello, I have built a new release of cpl (an astronomical data processing library) in koji. In rawhide, I get an (incorrect) dependency on libcfitsio.so https://koji.fedoraproject.org/koji/rpminfo?rpmID=1637146 where as in fc12 I get the correct dependency on libcfitsio.so.0: https://koji.fedoraproject.org/koji/rpminfo?rpmID=1639093 cfitsio provides libcfitsio.so.0 in both rawhide and fc12: https://koji.fedoraproject.org/koji/rpminfo?rpmID=1621497 Any hint? From orion at cora.nwra.com Sun Nov 1 16:28:17 2009 From: orion at cora.nwra.com (Orion Poplawski) Date: Sun, 1 Nov 2009 09:28:17 -0700 (MST) Subject: Strange dependency of cpl in rawhide In-Reply-To: <89b36810911010556j43469fd2kb93dee7878002628@mail.gmail.com> References: <89b36810911010556j43469fd2kb93dee7878002628@mail.gmail.com> Message-ID: <1860.97.124.131.64.1257092897.squirrel@www.cora.nwra.com> On Sun, November 1, 2009 6:56 am, Sergio Pascual wrote: > Hello, I have built a new release of cpl (an astronomical data > processing library) in koji. In rawhide, I get an (incorrect) > dependency on libcfitsio.so > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=1637146 > > where as in fc12 I get the correct dependency on libcfitsio.so.0: > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=1639093 > > cfitsio provides libcfitsio.so.0 in both rawhide and fc12: > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=1621497 For some reason, 3.210 in f13 no longer sets the soname to libcfitsio.so.0 (which you can see in the cfitsio build logs). This should get fixed. -- 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 Sun Nov 1 16:57:48 2009 From: orion at cora.nwra.com (Orion Poplawski) Date: Sun, 1 Nov 2009 09:57:48 -0700 (MST) Subject: Strange dependency of cpl in rawhide In-Reply-To: <89b36810911010556j43469fd2kb93dee7878002628@mail.gmail.com> References: <89b36810911010556j43469fd2kb93dee7878002628@mail.gmail.com> Message-ID: <1927.97.124.131.64.1257094668.squirrel@www.cora.nwra.com> On Sun, November 1, 2009 6:56 am, Sergio Pascual wrote: > Hello, I have built a new release of cpl (an astronomical data > processing library) in koji. In rawhide, I get an (incorrect) > dependency on libcfitsio.so > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=1637146 > > where as in fc12 I get the correct dependency on libcfitsio.so.0: > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=1639093 > > cfitsio provides libcfitsio.so.0 in both rawhide and fc12: > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=1621497 For some reason, 3.210 in f13 no longer sets the soname to libcfitsio.so.0 (which you can see in the cfitsio build logs). This should get fixed. -- 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 awilliam at redhat.com Sun Nov 1 21:31:25 2009 From: awilliam at redhat.com (Adam Williamson) Date: Sun, 01 Nov 2009 13:31:25 -0800 Subject: How to add upstream developer as a (co)maintainer of the existing application? In-Reply-To: References: Message-ID: <1257111085.2314.154.camel@adam.local.net> On Sat, 2009-10-31 at 20:31 +0300, Peter Lemenkov wrote: > I remember, that if Redhat hires someone from upstream, then no > additional procedures with review requests and sponsorship needed (at > least visible to others, outside Redhat) - (s)he just started to be a > (co)maintainer. For the record, I wasn't hired from 'upstream' and I'm not in the development group so they may have different procedures, but I certainly didn't get any automatic packaging privileges when I joined, I went through the sponsorship process just like any other contributor. As other replies suggest, I think the procedure in this case doesn't differ from any other. Being a coder does not automatically make you a proficient packager, it's just the same as the converse (we wouldn't assume a good packager was a good hacker). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From steven at scc.hk Mon Nov 2 00:29:29 2009 From: steven at scc.hk (Steven James Drinnan) Date: Mon, 02 Nov 2009 08:29:29 +0800 Subject: Installing F12-Beta In-Reply-To: <1257111085.2314.154.camel@adam.local.net> References: <1257111085.2314.154.camel@adam.local.net> Message-ID: <1257121770.13416.3.camel@mylaptop.myhome> I have already submitted a bug report for this but it seems no one is looking into it. This is the problem. I have a 2.53 celeron with 1gb of Ram nvidia 5500 graphics card. When I put in the DVD (Install or Live) it starts but then I get a recursive error saying that it fixed but needs a restart. Of course when I restart the problem still persists. Please tell what you need to point in the right direction to fix this very serious issue. Thanks Steven -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bochecha at fedoraproject.org Mon Nov 2 00:40:33 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Mon, 2 Nov 2009 08:40:33 +0800 Subject: Installing F12-Beta In-Reply-To: <1257121770.13416.3.camel@mylaptop.myhome> References: <1257111085.2314.154.camel@adam.local.net> <1257121770.13416.3.camel@mylaptop.myhome> Message-ID: <2d319b780911011640y112fec04h23e0435e42153386@mail.gmail.com> Hi, > When I put in the DVD (Install or Live) it starts but then I get a > recursive error saying that it fixed but needs a restart. Of course when > I restart the problem still persists. > > > Please tell what you need to point in the right direction to fix this > very serious issue. Just to be sure, you did verify the ISO before burning it (with the SHA1SUM) and when booting it ? ---------- Mathieu Bridon (bochecha) From steven at scc.hk Mon Nov 2 00:58:17 2009 From: steven at scc.hk (Steven James Drinnan) Date: Mon, 02 Nov 2009 08:58:17 +0800 Subject: Installing F12-Beta In-Reply-To: <2d319b780911011640y112fec04h23e0435e42153386@mail.gmail.com> References: <1257111085.2314.154.camel@adam.local.net> <1257121770.13416.3.camel@mylaptop.myhome> <2d319b780911011640y112fec04h23e0435e42153386@mail.gmail.com> Message-ID: <1257123498.13416.6.camel@mylaptop.myhome> I did check and I used the same DVD to install on to a flash drive through my laptop. That drive boots on most other computers but not the Celeron PC. Steven On Mon, 2009-11-02 at 08:40 +0800, Mathieu Bridon (bochecha) wrote: > Hi, > > > When I put in the DVD (Install or Live) it starts but then I get a > > recursive error saying that it fixed but needs a restart. Of course when > > I restart the problem still persists. > > > > > > Please tell what you need to point in the right direction to fix this > > very serious issue. > > Just to be sure, you did verify the ISO before burning it (with the > SHA1SUM) and when booting it ? > > > ---------- > > Mathieu Bridon (bochecha) > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alekcejk at googlemail.com Mon Nov 2 02:00:04 2009 From: alekcejk at googlemail.com (alekcejk at googlemail.com) Date: Mon, 2 Nov 2009 04:00:04 +0200 Subject: Adding packages to comps.xml Message-ID: <200911020400.04076.alekcejk@googlemail.com> Hi all. I want to add to comps.xml for F10-F13 some optional packages which I not own. To kde-desktop group: kde-plasma-quickaccess kde-plasma-runcommand kde-plasma-translatoid kde-plasma-yawp qt-recordmydesktop skanlite To graphical-internet group: arora choqok mtr-gtk netactview rekonq To text-internet group: aria2 netstiff trickle youtube-dl whatmask To system-tools group: apcupsd-gui ddclient htop iftop iotop nethogs ntpdate fdupes nrg2iso To sound-and-video group: AcetoneISO2 subtitlecomposer To printing group: cups-pdf To web-server group: phpMyAdmin To engineering-and-scientific group: qtoctave scidavis Is there any objections to do this? Should packages maintainers add this packages or I can do this? From itamar at ispbrasil.com.br Mon Nov 2 02:11:49 2009 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Mon, 2 Nov 2009 00:11:49 -0200 Subject: Adding packages to comps.xml In-Reply-To: <200911020400.04076.alekcejk@googlemail.com> References: <200911020400.04076.alekcejk@googlemail.com> Message-ID: go ahead. Can you add qt-creator for me ? On Mon, Nov 2, 2009 at 12:00 AM, wrote: > Hi all. > > I want to add to comps.xml for F10-F13 ?some optional packages which I not > own. > > To kde-desktop group: > kde-plasma-quickaccess > kde-plasma-runcommand > kde-plasma-translatoid > kde-plasma-yawp > qt-recordmydesktop > skanlite > > To graphical-internet group: > arora > choqok > mtr-gtk > netactview > rekonq > > To text-internet group: > aria2 > netstiff > trickle > youtube-dl > whatmask > > To system-tools group: > apcupsd-gui > ddclient > htop > iftop > iotop > nethogs > ntpdate > fdupes > nrg2iso > > To sound-and-video group: > AcetoneISO2 > subtitlecomposer > > To printing group: > cups-pdf > > To web-server group: > phpMyAdmin > > To engineering-and-scientific group: > qtoctave > scidavis > > Is there any objections to do this? > Should packages maintainers add this packages or I can do this? > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- ------------ Itamar Reis Peixoto e-mail/msn/google talk/sip: itamar at ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 From kushaldas at gmail.com Mon Nov 2 06:41:05 2009 From: kushaldas at gmail.com (Kushal Das) Date: Mon, 2 Nov 2009 12:11:05 +0530 Subject: Getting intltool-update Permission denied error for a scratch build Message-ID: Hi, I am getting "unable to execute intltool-update: Permission denied" error in a scrach build. Details can be found here [1]. How to fix this ? [1] http://koji.fedoraproject.org/koji/getfile?taskID=1781935&name=build.log Kushal -- http://fedoraproject.org http://kushaldas.in From ville.skytta at iki.fi Mon Nov 2 07:16:43 2009 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Mon, 2 Nov 2009 09:16:43 +0200 Subject: Getting intltool-update Permission denied error for a scratch build In-Reply-To: References: Message-ID: <200911020916.43697.ville.skytta@iki.fi> On Monday 02 November 2009, Kushal Das wrote: > I am getting "unable to execute intltool-update: Permission denied" > error in a scrach build. > Details can be found here [1]. > How to fix this ? IIRC I've seen koji (or mock?) sometimes report missing commands like this instead of "command not found", and your root log doesn't appear to show intltool being installed so maybe "BuildRequires: intltool" would fix it. From dwmw2 at infradead.org Mon Nov 2 07:21:27 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 02 Nov 2009 07:21:27 +0000 Subject: Installing F12-Beta In-Reply-To: <1257121770.13416.3.camel@mylaptop.myhome> References: <1257111085.2314.154.camel@adam.local.net> <1257121770.13416.3.camel@mylaptop.myhome> Message-ID: <1257146487.5192.32.camel@macbook.infradead.org> On Mon, 2009-11-02 at 08:29 +0800, Steven James Drinnan wrote: > In-reply-to: <1257111085.2314.154.camel at adam.local.net> > References: > <1257111085.2314.154.camel at adam.local.net> Steven, please could you explain the relationship between your message on 'Installing F12-Beta' and the message to which you replied, which was about upstream developers becoming co-maintainers. If there is no relationship, then you've just hijacked an existing thread by posting your unrelated query as a reply to it -- please don't do that. You may also find that you'll get more help if you provide a more coherent bug report. You neglected to give any useful details about the error you see. Giving the full error message might have helped. Or even telling us at which stage of the boot it happens might have given a clue. I'd look in the bug you filed to see if you provided that information there... but you didn't even bother to tell us the bug number. My crystal ball isn't working today, so I _couldn't_ help you, even if I _didn't_ have a policy of not helping thread-hijackers until they post their problem politely ;) -- dwmw2 From kushaldas at gmail.com Mon Nov 2 07:24:29 2009 From: kushaldas at gmail.com (Kushal Das) Date: Mon, 2 Nov 2009 12:54:29 +0530 Subject: Getting intltool-update Permission denied error for a scratch build In-Reply-To: <200911020916.43697.ville.skytta@iki.fi> References: <200911020916.43697.ville.skytta@iki.fi> Message-ID: On Mon, Nov 2, 2009 at 12:46 PM, Ville Skytt? wrote: > On Monday 02 November 2009, Kushal Das wrote: > > IIRC I've seen koji (or mock?) sometimes report missing commands like this > instead of "command not found", and your root log doesn't appear to show > intltool being installed so maybe "BuildRequires: intltool" would fix it. > Thanks , trying now. Kushal -- http://fedoraproject.org http://kushaldas.in From steven at scc.hk Mon Nov 2 07:47:09 2009 From: steven at scc.hk (Steven James Drinnan) Date: Mon, 02 Nov 2009 15:47:09 +0800 Subject: Installing F12-Beta In-Reply-To: <1257146487.5192.32.camel@macbook.infradead.org> References: <1257111085.2314.154.camel@adam.local.net> <1257121770.13416.3.camel@mylaptop.myhome> <1257146487.5192.32.camel@macbook.infradead.org> Message-ID: <1257148030.19937.32.camel@mylaptop.myhome> David why you are so upset? No need to get nasty. I simply posted a message about my problems installing F12. I did not Hijack any thread (see the subject name). I thought this was a public forum. I sent this to the whole mailing list. My apologies if I offended you. All I can tell you is what happened. Which is I put the DVD in the drive and after a while it came up with a recursive error and said it was fixed but needed to restart the computer. I.E 1. The kernel failed to load 2. Anaconda did not start. The same DVD was used to install F12 Beta on a flash drive. So the DVD is fine. As I said I have posted a bug report at bugzilla (https://bugzilla.redhat.com/show_bug.cgi?id=531156) but no reply. I just thought you guys would be interested in a very serious problem that I am having. So I willing to put the effort to help whoever, if you point me in the right direction. Steven On Mon, 2009-11-02 at 07:21 +0000, David Woodhouse wrote: > On Mon, 2009-11-02 at 08:29 +0800, Steven James Drinnan wrote: > > In-reply-to: <1257111085.2314.154.camel at adam.local.net> > > References: > > <1257111085.2314.154.camel at adam.local.net> > > Steven, please could you explain the relationship between your message > on 'Installing F12-Beta' and the message to which you replied, which was > about upstream developers becoming co-maintainers. > > If there is no relationship, then you've just hijacked an existing > thread by posting your unrelated query as a reply to it -- please don't > do that. > > You may also find that you'll get more help if you provide a more > coherent bug report. You neglected to give any useful details about the > error you see. Giving the full error message might have helped. Or even > telling us at which stage of the boot it happens might have given a > clue. > > I'd look in the bug you filed to see if you provided that information > there... but you didn't even bother to tell us the bug number. > > My crystal ball isn't working today, so I _couldn't_ help you, even if I > _didn't_ have a policy of not helping thread-hijackers until they post > their problem politely ;) > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mschmidt at redhat.com Mon Nov 2 08:16:05 2009 From: mschmidt at redhat.com (Michal Schmidt) Date: Mon, 02 Nov 2009 09:16:05 +0100 Subject: Installing F12-Beta In-Reply-To: <1257148030.19937.32.camel@mylaptop.myhome> References: <1257111085.2314.154.camel@adam.local.net> <1257121770.13416.3.camel@mylaptop.myhome> <1257146487.5192.32.camel@macbook.infradead.org> <1257148030.19937.32.camel@mylaptop.myhome> Message-ID: <4AEE9545.7030007@redhat.com> Dne 2.11.2009 08:47, Steven James Drinnan napsal(a): > David why you are so upset? No need to get nasty. I simply posted a > message about my problems installing F12. I did not Hijack any thread > (see the subject name). You posted your message as a reply to the other thread. That's what David called hijacking. You're right that it's not a reason to get nasty. It's only a little mistake, not a crime :-) Just try to not repeat the mistake in the future. > As I said I have posted a bug report at bugzilla > (https://bugzilla.redhat.com/show_bug.cgi?id=531156) OK, thanks for the link. I put a reply there. Bugzilla is a better place to discuss specific bugs than fedora-devel-list. Thank you for testing the Beta release. Michal From dwmw2 at infradead.org Mon Nov 2 08:21:35 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 02 Nov 2009 08:21:35 +0000 Subject: Installing F12-Beta In-Reply-To: <1257148030.19937.32.camel@mylaptop.myhome> References: <1257111085.2314.154.camel@adam.local.net> <1257121770.13416.3.camel@mylaptop.myhome> <1257146487.5192.32.camel@macbook.infradead.org> <1257148030.19937.32.camel@mylaptop.myhome> Message-ID: <1257150095.5192.110.camel@macbook.infradead.org> On Mon, 2009-11-02 at 15:47 +0800, Steven James Drinnan wrote: > David why you are so upset? No need to get nasty. I simply posted a > message about my problems installing F12. I did not Hijack any thread > (see the subject name). I thought this was a public forum. I sent this > to the whole mailing list. My apologies if I offended you. I'm not upset, and wasn't nasty. I was just trying to help you communicate more effectively, and without adding noise to other discussions. You _did_ hijack the thread -- you replied to Adam's message, using your 'reply' button instead of composing a new message to the list. Your mail is clearly marked, in its headers which I quoted, as a reply to that previous message -- as part of that older thread. It should have been a _new_ thread, not a reply to the existing thread. Please don't do that. And, while we're at it, please don't top-post either. And please remember to quote only what you actually need for context rather than repeating the _whole_ of the message to which you're replying. You may find http://david.woodhou.se/email.html to be useful reading. > All I can tell you is what happened. > > Which is I put the DVD in the drive and after a while it came up with a > recursive error and said it was fixed but needed to restart the > computer. You _still_ didn't actually post the precise text of the error you saw, along with any output leading up to it. It's almost as if you don't _want_ people to be able to help you. Now that you posted the actual bug number rather than just teasing us with "I put it in bugzilla but I'm not telling you where" as you did in your previous mail, I can see that you didn't post the full error there, either. Please, show us the words you actually see on the screen -- or take a photo, perhaps. -- dwmw2 From steven at scc.hk Mon Nov 2 08:26:47 2009 From: steven at scc.hk (Steven James Drinnan) Date: Mon, 02 Nov 2009 16:26:47 +0800 Subject: Installing F12-Beta In-Reply-To: <4AEE9545.7030007@redhat.com> References: <1257111085.2314.154.camel@adam.local.net> <1257121770.13416.3.camel@mylaptop.myhome> <1257146487.5192.32.camel@macbook.infradead.org> <1257148030.19937.32.camel@mylaptop.myhome> <4AEE9545.7030007@redhat.com> Message-ID: <1257150408.19937.38.camel@mylaptop.myhome> On Mon, 2009-11-02 at 09:16 +0100, Michal Schmidt wrote: > OK, thanks for the link. I put a reply there. Bugzilla is a better > place > to discuss specific bugs than fedora-devel-list. > > Thank you for testing the Beta release. > Michal Ok and thanks a lot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From prajnoha at redhat.com Mon Nov 2 09:13:28 2009 From: prajnoha at redhat.com (Peter Rajnoha) Date: Mon, 02 Nov 2009 10:13:28 +0100 Subject: Udev support for device-mapper/LVM2 in rawhide Message-ID: <4AEEA2B8.9040304@redhat.com> Hi, this is just an announce that finally we will make a new rawhide release tomorrow with udev support enabled in device-mapper and LVM2 packages (upcoming device-mapper-1.02.39-2, lvm2-2.02.54-2). This is a scratch you can check and test if you would like to: https://koji.fedoraproject.org/koji/taskinfo?taskID=1774341 We will provide the rules as well as the udev synchronisation feature (udev_sync) in libdevmapper directly. We have extended its interface so it's possible to wait for udev to process the events that are related to actions done on DM devices (create, rename, resume, remove). This way we can prevent races between libdevmapper and udev itself. However, we had to change the layout in /dev based on comments from udev team: - /dev/mapper directory is now filled with symlinks (not nodes) with names given by actual DM device names - these symlinks point to /dev/dm-X nodes, X is a number. This is an internal kernel name that should not be visible in userspace, but there's this udev requirement that node names must match the kernel names so... - as for LVM - we use symlinks in /dev/ but now these ones point to /dev/dm-X not /dev/mapper/ Any other software using libdevmapper should work without any problems while still not using udev_sync feature (libdevmapper will detect this and it will fallback to old way of node creation under /dev - that is by libdevmapper itself, the rules will be selectively switched off automatically in these situations). However, we expect that everybody using libdevmapper will switch to using udev_sync interface as well gradually. There were some problems last time we brought this into the F12 rawhide a month ago (the most critical were dracut and anaconda). We have identified these problems and everything should be fixed now (there are proper hooks in dracut to install the new rules and we provided a quick workaround in libdevmapper for parted utility that caused the anaconda to fail, there's also a fix on its way to parted upstream itself). Maybe I should mention other known problems we track and we know about: - mount utility uses inappropriate DM names in mtab (because it follows the symlinks and takes the internal dm-X names). The consequence is that utilities reading mtab will show these dm-X names instead of actual DM names (like the output of "df"). The fix is in upstream util-linux-ng already (as of 26th October) so I hope it will propagate into rawhide soon. - since we create the nodes on "change" udev event (and we have to!) and suppress the node creation on "add" event, there's a problem while using "udevadm trigger". The trigger generates "add" events by default and when called, the DM nodes are removed (because of the node suppression on add and udev removes the nodes if we use the suppression and the nodes exist already). We have to work out a proper solution with udev team here, but if you run into this problem, you can have those DM nodes back by calling: udevadm trigger --action=change --property-match=DM_UDEV_RULES_VSN=* or (but this works for kernels >= 2.6.29 only): udevadm trigger --action=change --attr-match=dm/name or: udevadm control --env=STARTUP=1 udevadm trigger udevadm control --env=STARTUP= - there's a problem with GRUB2 that can't deal with the symlinks in /dev/mapper (it's the grub-probe that fails iirc). Since there are more things to fix in grub2 with respect to DM devices, we have to work more closely with grub team to solve this issue and other issues. Hopefully I've mentioned eveything that's important. If you have any questions, please, feel free to raise your comments here. The plan is to switch this on tomorrow, but if there's anyone who sees a problem here and who would like to test it more and needs more time, please, let me know. Thanks Peter From sundaram at fedoraproject.org Mon Nov 2 09:12:02 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 02 Nov 2009 14:42:02 +0530 Subject: Udev support for device-mapper/LVM2 in rawhide In-Reply-To: <4AEEA2B8.9040304@redhat.com> References: <4AEEA2B8.9040304@redhat.com> Message-ID: <4AEEA262.8030601@fedoraproject.org> On 11/02/2009 02:43 PM, Peter Rajnoha wrote: > > Hopefully I've mentioned eveything that's important. If you have any > questions, please, feel free to raise your comments here. The plan is > to switch this on tomorrow, but if there's anyone who sees a problem > here and who would like to test it more and needs more time, please, > let me know. May I ask why these changes are being pushed so late in the development cycle? Rahul From prajnoha at redhat.com Mon Nov 2 09:31:48 2009 From: prajnoha at redhat.com (Peter Rajnoha) Date: Mon, 02 Nov 2009 10:31:48 +0100 Subject: Udev support for device-mapper/LVM2 in rawhide In-Reply-To: <4AEEA262.8030601@fedoraproject.org> References: <4AEEA2B8.9040304@redhat.com> <4AEEA262.8030601@fedoraproject.org> Message-ID: <4AEEA704.5030506@redhat.com> On 11/02/2009 10:12 AM, Rahul Sundaram wrote: > On 11/02/2009 02:43 PM, Peter Rajnoha wrote: > >> >> Hopefully I've mentioned eveything that's important. If you have any >> questions, please, feel free to raise your comments here. The plan is >> to switch this on tomorrow, but if there's anyone who sees a problem >> here and who would like to test it more and needs more time, please, >> let me know. > > May I ask why these changes are being pushed so late in the development > cycle? > > Rahul > This is for F13 rawhide, I consider F12 closed for this... (I know that there's no official release for current F13 rawhide yet, but I think releng could help us here to do a private pre-rawhide release for us to test, but first we need to push it so a "snapshot" could be made for that "pre-release"). Peter From liangsuilong at gmail.com Mon Nov 2 10:23:38 2009 From: liangsuilong at gmail.com (Liang Suilong) Date: Mon, 2 Nov 2009 18:23:38 +0800 Subject: Fwd: Request to update ATi OSS driver for Fedora 12 In-Reply-To: References: Message-ID: To Adam Williamson Thank you for your command. Will RGB Gamma value be set 1.0 in the final release? I think it needs. And playing flashplayer in the web browser with Adobe Flash Player still has some blocks. Maybe flash player cause that problem. I just wait. To Tom 'spot' Callaway Thank you for hard work. Crhomium browser in Fedora 12 looks perfect. Is there any plan to push chromium into rawhide or updates-testing. I think chromium has enough stability to make more users test itself. -- http://www.liangsuilong.info Fight for freedom!!!!(3F? Ask not what your Linux distro can do for you! Ask what you can do for your Linux distro! -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanjay.ankur at gmail.com Mon Nov 2 10:29:07 2009 From: sanjay.ankur at gmail.com (Ankur Sinha) Date: Mon, 02 Nov 2009 15:59:07 +0530 Subject: Wodim trouble Message-ID: <1257157747.2767.2.camel@localhost> hi, I've filed a bug[1] against wodim not burning dvds correctly. While browsing through another bug[2] on wodim, I came across this comment[3]. "wodim is completely unmaintained since May 6th 2007, don't expect to see any fixes anytime soon as long as Redhat continues to distribute wodim instead of the original software." Can someone please clear this up? [1] https://bugzilla.redhat.com/show_bug.cgi?id=532293 [2] https://bugzilla.redhat.com/show_bug.cgi?id=519465 [3] https://bugzilla.redhat.com/show_bug.cgi?id=519465#c6 -- regards, Ankur From nicolas.mailhot at laposte.net Mon Nov 2 10:57:29 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 2 Nov 2009 11:57:29 +0100 Subject: Wodim trouble In-Reply-To: <1257157747.2767.2.camel@localhost> References: <1257157747.2767.2.camel@localhost> Message-ID: Le Lun 2 novembre 2009 11:29, Ankur Sinha a ?crit : > > hi, > > I've filed a bug[1] against wodim not burning dvds correctly. While > browsing through another bug[2] on wodim, I came across this comment[3]. > > "wodim is completely unmaintained since May 6th 2007, don't > expect to see any fixes anytime soon as long as Redhat > continues to distribute wodim instead of the original software." > > Can someone please clear this up? You can ignore J?rg Schilling. He managed to antagonize everyone else Linux-side?, and now complains no one wants to use his cdrecord versions. IIRC after burning bridges Linux-side he launched an OpenSolaris distro named Schillix. I think it was not a big success either for pretty much the same communication reasons. ? Adding ? informative ? messages such as ? Linux device naming is stupid, my tools use better conventions, why are not you installing a sane OS like Solaris instead ? (paraphrased from memory) -- Nicolas Mailhot From rrakus at redhat.com Mon Nov 2 11:15:07 2009 From: rrakus at redhat.com (Roman Rakus) Date: Mon, 02 Nov 2009 12:15:07 +0100 Subject: Wodim trouble In-Reply-To: References: <1257157747.2767.2.camel@localhost> Message-ID: <4AEEBF3B.5040904@redhat.com> On 11/02/2009 11:57 AM, Nicolas Mailhot wrote: > > Le Lun 2 novembre 2009 11:29, Ankur Sinha a ?crit : > >> hi, >> >> I've filed a bug[1] against wodim not burning dvds correctly. While >> browsing through another bug[2] on wodim, I came across this comment[3]. >> >> "wodim is completely unmaintained since May 6th 2007, don't >> expect to see any fixes anytime soon as long as Redhat >> continues to distribute wodim instead of the original software." >> >> Can someone please clear this up? >> > You can ignore J?rg Schilling. He managed to antagonize everyone else > Linux-side?, and now complains no one wants to use his cdrecord versions. > > IIRC after burning bridges Linux-side he launched an OpenSolaris distro named > Schillix. I think it was not a big success either for pretty much the same > communication reasons. > > ? Adding ? informative ? messages such as ? Linux device naming is stupid, my > tools use better conventions, why are not you installing a sane OS like > Solaris instead ? (paraphrased from memory) > > And the best is to ignore those comments. RR From sanjay.ankur at gmail.com Mon Nov 2 11:21:38 2009 From: sanjay.ankur at gmail.com (Ankur Sinha) Date: Mon, 02 Nov 2009 16:51:38 +0530 Subject: Wodim trouble In-Reply-To: <4AEEBF3B.5040904@redhat.com> References: <1257157747.2767.2.camel@localhost> <4AEEBF3B.5040904@redhat.com> Message-ID: <1257160898.2767.4.camel@localhost> On Mon, 2009-11-02 at 12:15 +0100, Roman Rakus wrote: > On 11/02/2009 11:57 AM, Nicolas Mailhot wrote: > > > > Le Lun 2 novembre 2009 11:29, Ankur Sinha a ?crit : > > > >> hi, > >> > >> I've filed a bug[1] against wodim not burning dvds correctly. While > >> browsing through another bug[2] on wodim, I came across this comment[3]. > >> > >> "wodim is completely unmaintained since May 6th 2007, don't > >> expect to see any fixes anytime soon as long as Redhat > >> continues to distribute wodim instead of the original software." > >> > >> Can someone please clear this up? > >> > > You can ignore J?rg Schilling. He managed to antagonize everyone else > > Linux-side?, and now complains no one wants to use his cdrecord versions. > > > > IIRC after burning bridges Linux-side he launched an OpenSolaris distro named > > Schillix. I think it was not a big success either for pretty much the same > > communication reasons. > > > > ? Adding ? informative ? messages such as ? Linux device naming is stupid, my > > tools use better conventions, why are not you installing a sane OS like > > Solaris instead ? (paraphrased from memory) > > > > > And the best is to ignore those comments. > RR > hi, Thank you for clearing that up. The comment had made me a little bit uncertain about what was going on. -- regards, Ankur From rawhide at fedoraproject.org Mon Nov 2 11:23:41 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Mon, 2 Nov 2009 11:23:41 +0000 Subject: rawhide report: 20091102 changes Message-ID: <20091102112341.GA10714@releng2.fedora.phx.redhat.com> Compose started at Mon Nov 2 06:15:07 UTC 2009 Broken deps for i386 ---------------------------------------------------------- 1:nant-0.85-30.fc12.i686 requires mono(NDoc.Core) = 0:1.3.3498.0 Broken deps for x86_64 ---------------------------------------------------------- 1:nant-0.85-30.fc12.x86_64 requires mono(NDoc.Core) = 0:1.3.3498.0 Updated Packages: perl-Razor-Agent-2.85-4.fc12 ---------------------------- * Sun Nov 01 2009 Warren Togami - 2.85-4 - Use Digest::SHA instead of Digest::SHA1 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 1 From dan at danny.cz Mon Nov 2 11:39:00 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Mon, 02 Nov 2009 12:39:00 +0100 Subject: disabling internal crash handler in wxGTK Message-ID: <1257161940.3755.249.camel@eagle.danny.cz> Hello, I plan to disable the internal crash handler in wxGTK for the the devel/F13 branch so we can use ABRT to report crashes. This will mean a rebuild of wxGTK with --disable-catch_segvs. This change affects all applications linked with wxGTK, because one symbol is removed from the "base" library. I will take care of rebuilding the packages, but the package owners should still check what is their implementation of the wxApp::OnFatalExpection() virtual method doing, because it will not be called anymore. Usually it is used to display the wxGTK-based crash report. Please let me know if you want to rebuild the package yourself or if you have some questions. This is the list of packages that are linked with the base wxWidgets/wxGTK library (libwx_baseu-2.8.so.0): audacity-0:1.3.9-0.4.beta.fc12.x86_64 bacula-console-wxwidgets-0:3.0.2-4.fc12.x86_64 boinc-manager-0:6.6.37-4.r18632svn.fc12.x86_64 codeblocks-contrib-libs-0:8.02-9.fc12.x86_64 codeblocks-libs-0:8.02-9.fc12.x86_64 codeblocks-0:8.02-9.fc12.x86_64 crystalspace-0:1.2.1-6.fc12.x86_64 DivFix++-0:0.30-8.fc12.x86_64 extrema-0:4.3.6-5.fc12.x86_64 fbg-0:0.9.1-4.fc12.x86_64 filezilla-0:3.2.8.1-1.fc12.x86_64 fityk-0:0.8.8-1.fc12.x86_64 flamerobin-0:0.9.2-1.fc12.x86_64 freedink-dfarc-0:3.4-1.fc12.x86_64 glest-0:3.2.2-1.fc12.x86_64 gnuplot-0:4.2.6-1.fc12.x86_64 grass-0:6.3.0-14.fc12.x86_64 gspiceui-0:0.9.97-1.fc12.x86_64 hugin-base-0:2009.2.0-1.fc12.x86_64 hugin-0:2009.2.0-1.fc12.x86_64 iaxclient-0:2.1-0.4.beta3.fc12.x86_64 kicad-0:2009.07.07-4.rev1863.fc12.x86_64 LuxRender-0:0.5-5.fc12.x86_64 mkvtoolnix-gui-0:2.9.8-2.fc12.x86_64 mrpt-apps-0:0.7.1-0.1.20090818svn1148.fc12.x86_64 mrpt-core-0:0.7.1-0.1.20090818svn1148.fc12.x86_64 mrpt-hwdrivers-0:0.7.1-0.1.20090818svn1148.fc12.x86_64 multiget-0:1.2.0-7.fc12.x86_64 nightview-gui-0:0.3.2-8.fc12.x86_64 OpenSceneGraph-examples-0:2.8.2-3.fc12.x86_64 panoglview-0:0.2.2-6.fc12.x86_64 perl-Wx-0:0.92-1.fc12.x86_64 pgadmin3-0:1.10.0-2.fc12.x86_64 plplot-wxGTK-0:5.9.5-1.fc12.x86_64 poedit-0:1.4.3-1.fc12.x86_64 rapidsvn-0:0.10.0-2.fc12.x86_64 scorched3d-0:42.1-3.fc12.x86_64 scummvm-tools-0:0.13.0-2.fc12.x86_64 simdock-0:1.2-7.fc12.x86_64 sooperlooper-0:1.6.13-4.fc12.x86_64 springlobby-0:0.27-1.fc12.x86_64 toped-0:0.9.5-1.fc12.x86_64 trustedqsl-0:1.11-5.fc12.x86_64 ucblogo-0:6.0-5.fc12.x86_64 vavoom-0:1.30-3.fc12.x86_64 wxBase-0:2.8.10-6.fc12.x86_64 wxGTK-devel-0:2.8.10-6.fc12.x86_64 wxGTK-gl-0:2.8.10-6.fc12.x86_64 wxGTK-media-0:2.8.10-6.fc12.x86_64 wxGTK-0:2.8.10-6.fc12.x86_64 wxiax-0:2.1-0.4.beta3.fc12.x86_64 wxMaxima-0:0.8.3a-1.fc12.x86_64 wxPython-0:2.8.9.2-3.fc12.x86_64 xchm-0:1.17-2.fc12.x86_64 xmlcopyeditor-0:1.2.0.2-2.fc12.x86_64 Dan From mail at robertoragusa.it Mon Nov 2 13:00:06 2009 From: mail at robertoragusa.it (Roberto Ragusa) Date: Mon, 02 Nov 2009 14:00:06 +0100 Subject: Font rendering slightly degraded in recent rawhide In-Reply-To: <1256838536.2314.30.camel@adam.local.net> References: <20091029092026.GB25682@mother.pipebreaker.pl> <1256838536.2314.30.camel@adam.local.net> Message-ID: <4AEED7D6.3050109@robertoragusa.it> Adam Williamson wrote: > And why the hell are you still using Luxi Mono, anyway? that thing went > out with the ark... I'm not the person you are posing your question to, but I use Luxi Mono and can give you an answer: "Because it is a wonderful serif mono font. Can you suggest me an alternative? It looks like mono => sans nowadays." Best regards. -- Roberto Ragusa mail at robertoragusa.it From rdieter at fedoraproject.org Mon Nov 2 13:49:45 2009 From: rdieter at fedoraproject.org (Rex Dieter) Date: Mon, 02 Nov 2009 07:49:45 -0600 Subject: Adding packages to comps.xml In-Reply-To: <200911020345.34050.alekcejk@googlemail.com> References: <200911020345.34050.alekcejk@googlemail.com> Message-ID: <4AEEE379.6000402@fedoraproject.org> alekcejk at googlemail.com wrote: > Hi all. > > I want to add to comps.xml for F10-F13 some optional packages which I not > own. > > To kde-desktop group: > kde-plasma-quickaccess > kde-plasma-runcommand > kde-plasma-translatoid > kde-plasma-yawp > qt-recordmydesktop > skanlite > > To graphical-internet group: > arora > choqok > mtr-gtk > netactview > rekonq > > To text-internet group: > aria2 > netstiff > trickle > youtube-dl > whatmask > > To system-tools group: > apcupsd-gui > ddclient > htop > iftop > iotop > nethogs > ntpdate > fdupes > nrg2iso > > To sound-and-video group: > AcetoneISO2 > subtitlecomposer > > To printing group: > cups-pdf > > To web-server group: > phpMyAdmin > > To engineering-and-scientific group: > qtoctave > scidavis > > Is there any objections to do this? > Should packages maintainers add this packages or I can do this? No objectiion, thanks for the comps' love. Normally, this is something maintainers should do, but as they've not done so yet, maybe it was oversight or an error. To simplify matters and minimize confusion, I'd say "just do it". -- Rex From bruno at wolff.to Mon Nov 2 14:19:18 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 2 Nov 2009 08:19:18 -0600 Subject: Wodim trouble In-Reply-To: <1257157747.2767.2.camel@localhost> References: <1257157747.2767.2.camel@localhost> Message-ID: <20091102141918.GA2569@wolff.to> On Mon, Nov 02, 2009 at 15:59:07 +0530, Ankur Sinha wrote: > hi, > > I've filed a bug[1] against wodim not burning dvds correctly. While > browsing through another bug[2] on wodim, I came across this comment[3]. > > "wodim is completely unmaintained since May 6th 2007, don't > expect to see any fixes anytime soon as long as Redhat > continues to distribute wodim instead of the original software." > > Can someone please clear this up? While that might be an exageration, I still wouldn't hold my breath waiting for fixes from the wodim guys. On the other hand trying to build J?rg's stuff isn't easy on Fedora. And might not even work as he likes to use a interface that was depreciated a while back for talking to the cd/dvd drives. J?rg seems to be watching for bug reports related to wodim and comments on them whenever someone new adds something. The whole situation is unfortunate as J?rg seems to have a good knowledge of the hardware and I think support (especially for older hardware) would be better if he worked with wodim cooperatively. From mschmidt at redhat.com Mon Nov 2 14:23:30 2009 From: mschmidt at redhat.com (Michal Schmidt) Date: Mon, 02 Nov 2009 15:23:30 +0100 Subject: Feature request: AMD K10 thermal sensors In-Reply-To: <1256989904.2630.0.camel@choeger5.umpa.netz> References: <1256816304.2552.3.camel@choeger5.umpa.netz> <4AE99DDB.80105@redhat.com> <1256989904.2630.0.camel@choeger5.umpa.netz> Message-ID: <4AEEEB62.7020703@redhat.com> Dne 31.10.2009 12:51, Christoph H?ger napsal(a): > Just one question: How are the lm_sensors names (10h, 11h) related to > current processors? 11h seems to be WIP. AMD codename "K10" refers to family 10h CPUs (Phenom, Phenom II). You can see your cpu family in /proc/cpuinfo. It's decimal there, so 10h will be shown as 16. Michal From ajax at redhat.com Mon Nov 2 14:43:30 2009 From: ajax at redhat.com (Adam Jackson) Date: Mon, 02 Nov 2009 09:43:30 -0500 Subject: What to do with package that wants to use sse? In-Reply-To: References: <20091031040724.GA22910@wolff.to> Message-ID: <1257173010.7251.91.camel@atropine.boston.devel.redhat.com> On Sat, 2009-10-31 at 09:25 +0100, Nicolas Chauvet wrote: > 2009/10/31 Bruno Wolff III : > > I am working on packaging pagedgeometry and I noticed that when building > > on gcc it passes -msse which I am guessing says to use sse instructions. > > I think that even in F12 we can't assume these instructions are available. > > The package may gain a lot of benefit from using those instructions. > > (I haven't tested that yet as I am still pretty early in the process.) > > Is there some relatively standard way to handle something like this? > -msse is fine for x86_64 and ia64 by default (but not for non-intel arches). > The only way to have sse enabled on ix86 is for a library to be built > twice, the provides the sse version in %{_libdir}/sse2. The linker > will then enable the appropriate library at runtime. Strictly, this is not true. Newer binutils has a feature called "indirect functions" that lets you do (logically, this is not what the syntax actually looks like): typedef void *(*memcpy_func)(void *, void *, size_t); static void *_mmx_memcpy(void *d, void *s, size_t n) { ... } static void *_sse_memcpy(void *d, void *s, size_t n) { ... } /* ... */ __attribute__((indirect)) memcpy_func *memcpy() { if (has_mmx()) return _mmx_memcpy; if (has_sse()) return _sse_memcpy; /* ... */ } The indirect function is called at symbol resolution time instead of the normal lookup rules, so you can build a single object with support for multiple ISA extensions, without the runtime lookup penalty. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From bruno at wolff.to Mon Nov 2 14:49:45 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 2 Nov 2009 08:49:45 -0600 Subject: What to do with package that wants to use sse? In-Reply-To: <1257173010.7251.91.camel@atropine.boston.devel.redhat.com> References: <20091031040724.GA22910@wolff.to> <1257173010.7251.91.camel@atropine.boston.devel.redhat.com> Message-ID: <20091102144945.GA28094@wolff.to> On Mon, Nov 02, 2009 at 09:43:30 -0500, Adam Jackson wrote: > > Strictly, this is not true. Newer binutils has a feature called > "indirect functions" that lets you do (logically, this is not what the > syntax actually looks like): Can you point us to some documentation on this? Is this something that is encouraged for use in Fedora? From ajax at redhat.com Mon Nov 2 15:28:47 2009 From: ajax at redhat.com (Adam Jackson) Date: Mon, 02 Nov 2009 10:28:47 -0500 Subject: What to do with package that wants to use sse? In-Reply-To: <20091102144945.GA28094@wolff.to> References: <20091031040724.GA22910@wolff.to> <1257173010.7251.91.camel@atropine.boston.devel.redhat.com> <20091102144945.GA28094@wolff.to> Message-ID: <1257175727.7251.125.camel@atropine.boston.devel.redhat.com> On Mon, 2009-11-02 at 08:49 -0600, Bruno Wolff III wrote: > On Mon, Nov 02, 2009 at 09:43:30 -0500, Adam Jackson wrote: > > > > Strictly, this is not true. Newer binutils has a feature called > > "indirect functions" that lets you do (logically, this is not what the > > syntax actually looks like): > > Can you point us to some documentation on this? > > Is this something that is encouraged for use in Fedora? Well, the best documentation I can find is the thread discussing the implementation: http://www.x86-64.org/pipermail/discuss/2009-June/010546.html and the testcase in binutils: http://github.com/jiez/binutils/blob/master/ld/testsuite/ld-ifunc/lib.c glibc seems to be using it in a few places in F12, so I can't imagine it's too broken. That said, I don't think it's the _recommended_ solution for Fedora yet. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From dledford at redhat.com Mon Nov 2 15:41:09 2009 From: dledford at redhat.com (Doug Ledford) Date: Mon, 02 Nov 2009 10:41:09 -0500 Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to happen In-Reply-To: <4AE9B222.2060905@RedHat.com> References: <4AE5B378.1000507@RedHat.com> <4AE89491.4030303@RedHat.com> <20091028190514.B7E231D3@magilla.sf.frob.com> <4AE9B222.2060905@RedHat.com> Message-ID: <4AEEFD95.60701@redhat.com> On 10/29/2009 11:17 AM, Steve Dickson wrote: > > > On 10/28/2009 03:05 PM, Roland McGrath wrote: >> It sounds like you are saying that there is no way to export the same >> host filesystems with the same client-perceived names under v4 as was >> being done before under v[23]. Is that really true? > With Pre-F12 servers... Yeah... > > The V4 protocol requires a 'pseudo root' to be defined. Other servers simply > make '/' the pseudo root which allows all exports just to work with all versions. > The Linux server have the feature of being able to define the pseudo root with > the use of the 'fsid=0' export option. A feature none of the other servers > have. Except that when the other servers create a pseudo root, they don't *also* expose that pseudo root. I'm fairly strongly of the opinion that our NFS server should do the same thing: don't expose the pseudo root as an actual mount. > Unfortunately, there was no forethought as to what happens when a > pseudo root is not defined, until recently... Patches in both the > F-12 kernel and rpc.mountd now dynamically allocate a pseudo root > when one is not defined... Basically meaning '/' becomes the pseudo > root when there is no fsid=0 export option. And does this explicitly export the / filesystem? I would certainly hope not as that could surprise the hell out of an admin when his / filesystem is now exposed when it didn't use to be. >> >> My old /etc/exports is: >> >> /mirror *(ro,insecure,sync,mp,all_squash) >> >> So clients mount server:/mirror to see my /mirror directory's contents. >> No other /foo directory is exported or visible at all to clients, and >> that's how it should stay. >> >> How do I get the same results for v4 clients? > Use a F-12 server or added the '/ *(ro,fsid=0)' export entry like: > > / *(ro,fsid=0) > /mirror *(ro,insecure,sync,mp,all_squash) I'm perfectly fine with adding the entry to the exports file, but I think the fsid=0 export entry should be a non-functioning entry other than setting the pseudo root. As you've described it so far, it also happens to be a live export and I think that's wrong and should be fixed. -- Doug Ledford 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: OpenPGP digital signature URL: From jeff at ocjtech.us Mon Nov 2 15:47:00 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Mon, 2 Nov 2009 09:47:00 -0600 Subject: Problem building Asterisk sounds In-Reply-To: <4ADE0600.6080109@ioa.s.u-tokyo.ac.jp> References: <935ead450910060723k7836e593ma7d0b418e4d2c2af@mail.gmail.com> <935ead450910200953p66826cb7t8430b0f7e68ba20d@mail.gmail.com> <4ADE0600.6080109@ioa.s.u-tokyo.ac.jp> Message-ID: <935ead450911020747l77c09825t91065baaeb68dfa3@mail.gmail.com> On Tue, Oct 20, 2009 at 12:48 PM, Mamoru Tasaka wrote: > Jeffrey Ollie wrote, at 10/21/2009 01:53 AM +9:00: >> >> On Tue, Oct 6, 2009 at 9:23 AM, Jeffrey Ollie wrote: >>> >>> I'm trying to build the latest Asterisk sounds package, but I'm >>> getting the following error: >>> >>> error: Recognition of file >>> >>> "/builddir/build/BUILDROOT/asterisk-sounds-core-1.4.16-1.fc13.noarch/usr/share/asterisk/sounds/fr/digits/1.g729" >>> failed: mode 100444 zlib: invalid stored block lengthsempty (gzip >>> compressed data, reserved method, encrypted, last modified: Tue Nov ?9 >>> 20:48:48 2010, max speed) >>> >>> The full build log is here: >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=1730585 >>> >>> The build fails in mock locally as well but koji actually gives me a >>> better error message. ?The file in question isn't gzip compressed, >>> it's an audio file compressed with G.729 audio compression. ?Can >>> anyone help me out here? >> >> I still haven't figured this out, and it hasn't fixed itself. ?Can >> anyone take a look and give me a hint? > > Well, > $ file ./usr/share/asterisk/sounds/fr/digits/1.g729 > ./usr/share/asterisk/sounds/fr/digits/1.g729: gzip compressed data, reserved > method, encrypted, last modified: Wed Nov 10 10:48:48 2010, max speed > > So it seems that this file is actually recognized as gzip compressed data, > perhaps > due to magic number, which seems to be causing a problem in rpm. > I don't know currently how to deal with this case as I don't know if we can > tell rpmbuild > that this file should not be treated as a gzipped file by some methods or > not, but for now > I guess it is better to contact rpm maintainer. Yes, this does appear to be a bug in file/libmagic. I've filed bug 532489[1]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=532489 In the meantime I'll remove the file as Asterisk should pick a recording encoded with another codec as a fallback. -- Jeff Ollie From kevin.kofler at chello.at Mon Nov 2 16:31:10 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 02 Nov 2009 17:31:10 +0100 Subject: Wodim trouble References: <1257157747.2767.2.camel@localhost> Message-ID: Ankur Sinha wrote: > "wodim is completely unmaintained since May 6th 2007, don't > expect to see any fixes anytime soon as long as Redhat > continues to distribute wodim instead of the original software." > > Can someone please clear this up? It's just the usual FUD from J?rg Schilling. Ignore it. The latest commit to cdrkit upstream was 3 weeks ago. Kevin Kofler From nathanael at gnat.ca Mon Nov 2 16:36:22 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Mon, 02 Nov 2009 09:36:22 -0700 Subject: Evolution Data Server... Message-ID: <4AEF0A86.2080200@gnat.ca> Hello, So this isn't a strictly development question, but based on the answer it very well could be. I don't use evolution, but the evolution-data-server is running. Is it used for anything else? If not, perhaps it would be good to not run it as part of the gnome session when the users default mail client isn't evolution. If it is used for other purposes then whatever. Otherwise I can file a bug report if desired... -- Nathanael noblet From awilliam at redhat.com Mon Nov 2 16:48:34 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 02 Nov 2009 08:48:34 -0800 Subject: Font rendering slightly degraded in recent rawhide In-Reply-To: <4AEED7D6.3050109@robertoragusa.it> References: <20091029092026.GB25682@mother.pipebreaker.pl> <1256838536.2314.30.camel@adam.local.net> <4AEED7D6.3050109@robertoragusa.it> Message-ID: <1257180514.2314.204.camel@adam.local.net> On Mon, 2009-11-02 at 14:00 +0100, Roberto Ragusa wrote: > Adam Williamson wrote: > > > And why the hell are you still using Luxi Mono, anyway? that thing went > > out with the ark... > > I'm not the person you are posing your question to, but I use Luxi Mono > and can give you an answer: > "Because it is a wonderful serif mono font. Can you suggest me an > alternative? It looks like mono => sans nowadays." I'm a big member of the 'fonts are subjective' bandwagon, but I'm _really_ surprised that anyone would consider the Luxi fonts to look better than the DejaVu ones. DejaVu is just a far more polished font set, which is why it was chosen by all major distros to replace Luxi years ago. You're literally the first person I've come across who seems to prefer the appearance of Luxi. Nothing wrong with that, I suppose, I'm just surprised =) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Mon Nov 2 16:52:52 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 02 Nov 2009 08:52:52 -0800 Subject: Evolution Data Server... In-Reply-To: <4AEF0A86.2080200@gnat.ca> References: <4AEF0A86.2080200@gnat.ca> Message-ID: <1257180772.2314.208.camel@adam.local.net> On Mon, 2009-11-02 at 09:36 -0700, Nathanael D. Noblet wrote: > Hello, > > So this isn't a strictly development question, but based on the > answer it very well could be. I don't use evolution, but the > evolution-data-server is running. Is it used for anything else? If not, > perhaps it would be good to not run it as part of the gnome session when > the users default mail client isn't evolution. If it is used for other > purposes then whatever. Otherwise I can file a bug report if desired... Yes, several other things use it. It's something of an unfortunate name; e-d-s is really a generic PIM information server. It's a sensible model: it lets multiple applications access and modify the information in question while they are all active. KDE, which did not used to use this model, had a problem where if anything other than KMail wanted to use contact data - say you wanted to synchronize it with another device via OpenSync - you had to close KMail first, or messiness could ensue (the sync would fail, or in a bad case KMail could fall over; I think in a really really bad case you could even lose or duplicate data). KDE is switching to the model of having a server for this information with Akonadi. GNOME's server for this information is e-d-s. The most common non-Evolution user of e-d-s data is the clock applet on the panel; it notifies you of impending appointments, and it does this by looking them up via e-d-s. But there are several others too. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From nathanael at gnat.ca Mon Nov 2 16:57:02 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Mon, 02 Nov 2009 09:57:02 -0700 Subject: Evolution Data Server... In-Reply-To: <1257180772.2314.208.camel@adam.local.net> References: <4AEF0A86.2080200@gnat.ca> <1257180772.2314.208.camel@adam.local.net> Message-ID: <4AEF0F5E.1000307@gnat.ca> On 11/02/2009 09:52 AM, Adam Williamson wrote: > On Mon, 2009-11-02 at 09:36 -0700, Nathanael D. Noblet wrote: >> Hello, >> >> So this isn't a strictly development question, but based on the >> answer it very well could be. I don't use evolution, but the >> evolution-data-server is running. Is it used for anything else? If not, >> perhaps it would be good to not run it as part of the gnome session when >> the users default mail client isn't evolution. If it is used for other >> purposes then whatever. Otherwise I can file a bug report if desired... > > Yes, several other things use it. It's something of an unfortunate name; > e-d-s is really a generic PIM information server. > > It's a sensible model: it lets multiple applications access and modify > the information in question while they are all active. KDE, which did > not used to use this model, had a problem where if anything other than > KMail wanted to use contact data - say you wanted to synchronize it with > another device via OpenSync - you had to close KMail first, or messiness > could ensue (the sync would fail, or in a bad case KMail could fall > over; I think in a really really bad case you could even lose or > duplicate data). KDE is switching to the model of having a server for > this information with Akonadi. GNOME's server for this information is > e-d-s. > > The most common non-Evolution user of e-d-s data is the clock applet on > the panel; it notifies you of impending appointments, and it does this > by looking them up via e-d-s. But there are several others too. > Good to know! ;) Thanks for the info. From jdy at cryregarder.com Mon Nov 2 17:15:05 2009 From: jdy at cryregarder.com (Joel) Date: Mon, 2 Nov 2009 17:15:05 +0000 (UTC) Subject: Getting Boost Caught-Up Message-ID: Folks, Boost 1.41 is going into Beta now. Can we please get boost caught-up to current release for FC13? Thanks, Joel From mschmidt at redhat.com Mon Nov 2 17:16:29 2009 From: mschmidt at redhat.com (Michal Schmidt) Date: Mon, 02 Nov 2009 18:16:29 +0100 Subject: Wodim trouble In-Reply-To: References: <1257157747.2767.2.camel@localhost> Message-ID: <4AEF13ED.60001@redhat.com> Dne 2.11.2009 17:31, Kevin Kofler napsal: > Ankur Sinha wrote: >> "wodim is completely unmaintained since May 6th 2007, don't >> expect to see any fixes anytime soon as long as Redhat >> continues to distribute wodim instead of the original software." >> >> Can someone please clear this up? > > It's just the usual FUD from J?rg Schilling. Ignore it. > > The latest commit to cdrkit upstream was 3 weeks ago. Although you are technically right, the commits for the last two years have been boring cleanups, typo fixes and warning silencers. They don't seem to be fixing any actual bugs in CD/DVD burning. The last commit that did something which looks like a technical change was indeed on 2007-05-06 ( http://svn.debian.org/wsvn/debburn/cdrkit/trunk/wodim/?rev=767&sc=1 ). Look here for the log and read the commit messages: http://svn.debian.org/wsvn/debburn/cdrkit/trunk/wodim/?op=log&rev=0&sc=0&isdir=1 So wodim does not look like a well maintained project to me. Michal From mail at robertoragusa.it Mon Nov 2 17:36:37 2009 From: mail at robertoragusa.it (Roberto Ragusa) Date: Mon, 02 Nov 2009 18:36:37 +0100 Subject: Font rendering slightly degraded in recent rawhide In-Reply-To: <1257180514.2314.204.camel@adam.local.net> References: <20091029092026.GB25682@mother.pipebreaker.pl> <1256838536.2314.30.camel@adam.local.net> <4AEED7D6.3050109@robertoragusa.it> <1257180514.2314.204.camel@adam.local.net> Message-ID: <4AEF18A5.8030202@robertoragusa.it> Adam Williamson wrote: > On Mon, 2009-11-02 at 14:00 +0100, Roberto Ragusa wrote: >> Adam Williamson wrote: >> >>> And why the hell are you still using Luxi Mono, anyway? that thing went >>> out with the ark... >> I'm not the person you are posing your question to, but I use Luxi Mono >> and can give you an answer: >> "Because it is a wonderful serif mono font. Can you suggest me an >> alternative? It looks like mono => sans nowadays." > > I'm a big member of the 'fonts are subjective' bandwagon, but I'm > _really_ surprised that anyone would consider the Luxi fonts to look > better than the DejaVu ones. DejaVu is just a far more polished font > set, which is why it was chosen by all major distros to replace Luxi > years ago. You're literally the first person I've come across who seems > to prefer the appearance of Luxi. Nothing wrong with that, I suppose, > I'm just surprised =) I've never said that Luxi fonts are better than DejaVu fonts. What I've said is that there is no alternative to Luxi Mono if one wants a serif monospaced font. I like to have a serif font in my shell; I find it more readable, even at small size. -- Roberto Ragusa mail at robertoragusa.it From awilliam at redhat.com Mon Nov 2 17:48:59 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 02 Nov 2009 09:48:59 -0800 Subject: Font rendering slightly degraded in recent rawhide In-Reply-To: <4AEF18A5.8030202@robertoragusa.it> References: <20091029092026.GB25682@mother.pipebreaker.pl> <1256838536.2314.30.camel@adam.local.net> <4AEED7D6.3050109@robertoragusa.it> <1257180514.2314.204.camel@adam.local.net> <4AEF18A5.8030202@robertoragusa.it> Message-ID: <1257184139.2314.213.camel@adam.local.net> On Mon, 2009-11-02 at 18:36 +0100, Roberto Ragusa wrote: > I've never said that Luxi fonts are better than DejaVu fonts. > What I've said is that there is no alternative to Luxi Mono > if one wants a serif monospaced font. > I like to have a serif font in my shell; I find it more readable, > even at small size. Ah, I missed the Serif wrinkle. Indeed DV doesn't provide a serif monospace font. I'm not aware of any one better than luxi there, maybe someone else is... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From matt at truch.net Mon Nov 2 17:49:46 2009 From: matt at truch.net (Matthew D Truch) Date: Mon, 2 Nov 2009 12:49:46 -0500 Subject: Strange dependency of cpl in rawhide In-Reply-To: <1860.97.124.131.64.1257092897.squirrel@www.cora.nwra.com> References: <89b36810911010556j43469fd2kb93dee7878002628@mail.gmail.com> <1860.97.124.131.64.1257092897.squirrel@www.cora.nwra.com> Message-ID: <20091102174946.GE17555@truch.net> > > Hello, I have built a new release of cpl (an astronomical data > > processing library) in koji. In rawhide, I get an (incorrect) > > dependency on libcfitsio.so > > > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=1637146 > > > > where as in fc12 I get the correct dependency on libcfitsio.so.0: > > > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=1639093 > > > > cfitsio provides libcfitsio.so.0 in both rawhide and fc12: > > > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=1621497 > > For some reason, 3.210 in f13 no longer sets the soname to libcfitsio.so.0 > (which you can see in the cfitsio build logs). This should get fixed. Yikes. Let me get on that. -- "299792458 m/s. It's not just a good idea, It's the law." -------------------------- Matthew Truch Department of Physics and Astronomy University of Pennsylvania matt at truch.net http://matt.truch.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mrmazda at earthlink.net Mon Nov 2 17:56:37 2009 From: mrmazda at earthlink.net (Felix Miata) Date: Mon, 02 Nov 2009 12:56:37 -0500 Subject: Font rendering slightly degraded in recent rawhide In-Reply-To: <1257180514.2314.204.camel@adam.local.net> References: <20091029092026.GB25682@mother.pipebreaker.pl> <1256838536.2314.30.camel@adam.local.net> <4AEED7D6.3050109@robertoragusa.it> <1257180514.2314.204.camel@adam.local.net> Message-ID: <4AEF1D55.7040506@earthlink.net> On 2009/11/02 08:48 (GMT-0800) Adam Williamson composed: > On Mon, 2009-11-02 at 14:00 +0100, Roberto Ragusa wrote: >> Adam Williamson wrote: >> > And why the hell are you still using Luxi Mono, anyway? that thing went >> > out with the ark... >> I'm not the person you are posing your question to, but I use Luxi Mono >> and can give you an answer: >> "Because it is a wonderful serif mono font. Can you suggest me an >> alternative? It looks like mono => sans nowadays." Have you looked at Consolas? > I'm a big member of the 'fonts are subjective' bandwagon, but I'm > _really_ surprised that anyone would consider the Luxi fonts to look > better than the DejaVu ones. DejaVu is just a far more polished font > set, which is why it was chosen by all major distros to replace Luxi > years ago. You're literally the first person I've come across who seems > to prefer the appearance of Luxi. Nothing wrong with that, I suppose, > I'm just surprised =) FWIW, of all the distros I've sampled, all but one puts DejaVu and/or Bitstream Vera at the top of the fontconfig alias lists. The odd one out is openSUSE, which places Arial, Times New Roman and Consolas firsts, and the Agfa fonts (no longer included on the DVD) seconds, ahead of DejaVus in third, and Liberations in fourth, followed oddly in fifth/sixth by SUSE/Bitstream Vera. openSUSE has another exception in putting Verdana between Agfa's Albany AMT and DejaVu Sans. IIRC, all put Nimbus ahead of Luxi -- The husband should fulfill his marital duty to his wife, and likewise the wife to her husband. 1 Corinthians 7:3 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ From dcbw at redhat.com Mon Nov 2 18:07:09 2009 From: dcbw at redhat.com (Dan Williams) Date: Mon, 02 Nov 2009 10:07:09 -0800 Subject: Fedora PPC for oldworld Mac? In-Reply-To: <1256818710.9814.150.camel@macbook.infradead.org> References: <1256783158.32634.0@localhost.localdomain> <1256818710.9814.150.camel@macbook.infradead.org> Message-ID: <1257185229.3151.29.camel@localhost.localdomain> On Thu, 2009-10-29 at 12:18 +0000, David Woodhouse wrote: > On Wed, 2009-10-28 at 22:25 -0400, Tony Nelson wrote: > > On 09-10-28 18:24:49, Josh Boyer wrote: > > > On Wed, Oct 28, 2009 at 06:17:31PM -0400, Tony Nelson wrote: > > > >Sorry to bug developers, but I didn't get any bites from PPC > > > >users on fedora-list. > > > > > > > >Does Fedora PPC work or install on oldworld PCI Macs, such as > > > >a beige G3 desktop? My impression is that no one has tried it > > > >on an oldworld > > > > > > > > > No, it doesn't. The ppc specific release notes cover that here: > > > > > > http://docs.fedoraproject.org/release-notes/f11/en-US/ > > > index.html#sect-Release_Notes-Hardware_Requirements > > > > I'd looked at the release notes. They says "Minimum CPU: PowerPC > > G3..." and "Although Old World machines should work, they require a > > special bootloader which is not included in the Fedora distribution." > > My question is whether anyone has tried it in any recent Fedora > > release and knows whether "should" means "do" or "don't". > > > > (FWIW, the special bootloader is BootX, and Debian Lenny is installing > > now, so /some/ form of Linux works. I just don't know anything but > > hearsay about Debian. I see it uses "apt".) > > I don't know of anyone who's tried it recently, but in the past we've > fixed things in the kernel to make it work properly on OldWorld Macs and > it _has_ been known to work fine. > > It _ought_ to work if you sort out the bootloader. oldworld topped out at 366MHz anyway right? (the 333 and 366 Beige G3 were only sold from 1998-08-12 -> 1999-01-01 too) That's pretty much the minimum you'd need to run Fedora anyway these days... Not sure it's really worth it, you'll need at least 256MB of RAM anyway, and those things used 168-pin 3.3V DIMMs which are pretty hard to find these days. The Blue & White G3 was the first New World machine I think. Remember too that you'll need your boot partition within the first 8GB of the drive as the firmware can't handle booting from a partition which ends anywhere past that. Dan From belegdol at gmail.com Mon Nov 2 18:14:53 2009 From: belegdol at gmail.com (Julian Sikorski) Date: Mon, 02 Nov 2009 19:14:53 +0100 Subject: Wodim trouble In-Reply-To: <4AEF13ED.60001@redhat.com> References: <1257157747.2767.2.camel@localhost> <4AEF13ED.60001@redhat.com> Message-ID: W dniu 02.11.2009 18:16, Michal Schmidt pisze: > Dne 2.11.2009 17:31, Kevin Kofler napsal: >> Ankur Sinha wrote: >>> "wodim is completely unmaintained since May 6th 2007, don't >>> expect to see any fixes anytime soon as long as Redhat >>> continues to distribute wodim instead of the original software." >>> >>> Can someone please clear this up? >> >> It's just the usual FUD from J?rg Schilling. Ignore it. >> >> The latest commit to cdrkit upstream was 3 weeks ago. > > Although you are technically right, the commits for the last two years > have been boring cleanups, typo fixes and warning silencers. They don't > seem to be fixing any actual bugs in CD/DVD burning. > > The last commit that did something which looks like a technical change > was indeed on 2007-05-06 ( > http://svn.debian.org/wsvn/debburn/cdrkit/trunk/wodim/?rev=767&sc=1 ). > > Look here for the log and read the commit messages: > http://svn.debian.org/wsvn/debburn/cdrkit/trunk/wodim/?op=log&rev=0&sc=0&isdir=1 > > > So wodim does not look like a well maintained project to me. > > Michal > I might be wrong, but I think it lacks UDF support. I was burning a DVD with insanely long filenames and I got bitten by that. Julian From ajax at redhat.com Mon Nov 2 18:18:19 2009 From: ajax at redhat.com (Adam Jackson) Date: Mon, 02 Nov 2009 13:18:19 -0500 Subject: Wodim trouble In-Reply-To: <4AEF13ED.60001@redhat.com> References: <1257157747.2767.2.camel@localhost> <4AEF13ED.60001@redhat.com> Message-ID: <1257185899.7251.212.camel@atropine.boston.devel.redhat.com> On Mon, 2009-11-02 at 18:16 +0100, Michal Schmidt wrote: > Dne 2.11.2009 17:31, Kevin Kofler napsal: > > Ankur Sinha wrote: > >> "wodim is completely unmaintained since May 6th 2007, don't > >> expect to see any fixes anytime soon as long as Redhat > >> continues to distribute wodim instead of the original software." > >> > >> Can someone please clear this up? > > > > It's just the usual FUD from J?rg Schilling. Ignore it. > > > > The latest commit to cdrkit upstream was 3 weeks ago. > > Although you are technically right, the commits for the last two years > have been boring cleanups, typo fixes and warning silencers. They don't > seem to be fixing any actual bugs in CD/DVD burning. > > The last commit that did something which looks like a technical change > was indeed on 2007-05-06 ( > http://svn.debian.org/wsvn/debburn/cdrkit/trunk/wodim/?rev=767&sc=1 ). > > Look here for the log and read the commit messages: > http://svn.debian.org/wsvn/debburn/cdrkit/trunk/wodim/?op=log&rev=0&sc=0&isdir=1 > > So wodim does not look like a well maintained project to me. That may be true, but since cdrecord is not shippable, it's a pretty vacuous truth. The solution is obviously to fix the bug and help revive upstream, or else host a development tree on fh if upstream stays idle. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From denis at poolshark.org Mon Nov 2 19:07:07 2009 From: denis at poolshark.org (Denis Leroy) Date: Mon, 02 Nov 2009 20:07:07 +0100 Subject: Wodim trouble In-Reply-To: <20091102141918.GA2569@wolff.to> References: <1257157747.2767.2.camel@localhost> <20091102141918.GA2569@wolff.to> Message-ID: <4AEF2DDB.7030503@poolshark.org> On 11/02/2009 03:19 PM, Bruno Wolff III wrote: > J?rg seems to be watching for bug reports related to wodim and comments > on them whenever someone new adds something. Same applies to brasero and cdrdao. From drago01 at gmail.com Mon Nov 2 19:11:12 2009 From: drago01 at gmail.com (drago01) Date: Mon, 2 Nov 2009 20:11:12 +0100 Subject: Wodim trouble In-Reply-To: <1257185899.7251.212.camel@atropine.boston.devel.redhat.com> References: <1257157747.2767.2.camel@localhost> <4AEF13ED.60001@redhat.com> <1257185899.7251.212.camel@atropine.boston.devel.redhat.com> Message-ID: On Mon, Nov 2, 2009 at 7:18 PM, Adam Jackson wrote: > On Mon, 2009-11-02 at 18:16 +0100, Michal Schmidt wrote: >> Dne 2.11.2009 17:31, Kevin Kofler napsal: >> > Ankur Sinha wrote: >> >> "wodim is completely unmaintained since May 6th 2007, don't >> >> expect to see any fixes anytime soon as long as Redhat >> >> continues to distribute wodim instead of the original software." >> >> >> >> Can someone please clear this up? >> > >> > It's just the usual FUD from J?rg Schilling. Ignore it. >> > >> > The latest commit to cdrkit upstream was 3 weeks ago. >> >> Although you are technically right, the commits for the last two years >> have been boring cleanups, typo fixes and warning silencers. They don't >> seem to be fixing any actual bugs in CD/DVD burning. >> >> The last commit that did something which looks like a technical change >> was indeed on 2007-05-06 ( >> http://svn.debian.org/wsvn/debburn/cdrkit/trunk/wodim/?rev=767&sc=1 ). >> >> Look here for the log and read the commit messages: >> http://svn.debian.org/wsvn/debburn/cdrkit/trunk/wodim/?op=log&rev=0&sc=0&isdir=1 >> >> So wodim does not look like a well maintained project to me. > > That may be true, but since cdrecord is not shippable, it's a pretty > vacuous truth. ?The solution is obviously to fix the bug and help revive > upstream, or else host a development tree on fh if upstream stays idle. Or switch to libburn and friends. From SteveD at redhat.com Mon Nov 2 19:23:40 2009 From: SteveD at redhat.com (Steve Dickson) Date: Mon, 02 Nov 2009 14:23:40 -0500 Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to happen In-Reply-To: <4AEEFD95.60701@redhat.com> References: <4AE5B378.1000507@RedHat.com> <4AE89491.4030303@RedHat.com> <20091028190514.B7E231D3@magilla.sf.frob.com> <4AE9B222.2060905@RedHat.com> <4AEEFD95.60701@redhat.com> Message-ID: <4AEF31BC.80205@RedHat.com> On 11/02/2009 10:41 AM, Doug Ledford wrote: > On 10/29/2009 11:17 AM, Steve Dickson wrote: >> >> >> On 10/28/2009 03:05 PM, Roland McGrath wrote: >>> It sounds like you are saying that there is no way to export the same >>> host filesystems with the same client-perceived names under v4 as was >>> being done before under v[23]. Is that really true? >> With Pre-F12 servers... Yeah... >> >> The V4 protocol requires a 'pseudo root' to be defined. Other servers simply >> make '/' the pseudo root which allows all exports just to work with all versions. >> The Linux server have the feature of being able to define the pseudo root with >> the use of the 'fsid=0' export option. A feature none of the other servers >> have. > > Except that when the other servers create a pseudo root, they don't > *also* expose that pseudo root. I'm fairly strongly of the opinion that > our NFS server should do the same thing: don't expose the pseudo root as > an actual mount. I believe the F-12 kernel does the right thing... just like the all the other servers do... > >> Unfortunately, there was no forethought as to what happens when a >> pseudo root is not defined, until recently... Patches in both the >> F-12 kernel and rpc.mountd now dynamically allocate a pseudo root >> when one is not defined... Basically meaning '/' becomes the pseudo >> root when there is no fsid=0 export option. > > And does this explicitly export the / filesystem? I would certainly > hope not as that could surprise the hell out of an admin when his / > filesystem is now exposed when it didn't use to be. Well the fsid=0 is documented in the man page but the answer to your question is yes... > >>> >>> My old /etc/exports is: >>> >>> /mirror *(ro,insecure,sync,mp,all_squash) >>> >>> So clients mount server:/mirror to see my /mirror directory's contents. >>> No other /foo directory is exported or visible at all to clients, and >>> that's how it should stay. >>> >>> How do I get the same results for v4 clients? >> Use a F-12 server or added the '/ *(ro,fsid=0)' export entry like: >> >> / *(ro,fsid=0) >> /mirror *(ro,insecure,sync,mp,all_squash) > > I'm perfectly fine with adding the entry to the exports file, but I > think the fsid=0 export entry should be a non-functioning entry other > than setting the pseudo root. As you've described it so far, it also > happens to be a live export and I think that's wrong and should be fixed. I'm not sure about this... Actually I like the fact we can define a pseudo root other than '/'... which means you really want a live exported directory with the fsid=0 option... If I am understanding what you are saying... steved. From SteveD at redhat.com Mon Nov 2 19:35:40 2009 From: SteveD at redhat.com (Steve Dickson) Date: Mon, 02 Nov 2009 14:35:40 -0500 Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to happen In-Reply-To: <4AE5B378.1000507@RedHat.com> References: <4AE5B378.1000507@RedHat.com> Message-ID: <4AEF348C.3060403@RedHat.com> On 10/26/2009 10:34 AM, Steve Dickson wrote: > [With the next nfs-utils rawhide build, I will be flipping the ] > [switch that will cause all NFS client mounts to try NFS v4 first ] > [At the bottom of this email has the workarounds if this change does ] > [indeed cause pain ] > > As part of the https://fedoraproject.org/wiki/Features/NFSv4Default feature > I am one commit away from changing the default protocol version NFS will > be using (or at least trying to use). > > What does this means to you? Hopefully nothing! In theory this should > be a very seamless transition but with all new technology there > will be (and are) some rough spots. > > Why are make the change? See the NFSv4Default wiki for details, > but in a nutshell: > * Better performance - V4 is now a stateful protocol. Meaning the server keeps > state on all the clients access a particular file or directory. This > allows the server to give out delegations (or leases) which in turn > allows the client to aggressive cache both data and meta data locally > > * Firewall Friendly- With v4 only one port is used 2049 for all traffic > including mounting and file locking. > > * Finally it enables us use upcoming minor releases of the the protocol. > NFS version 4.1 and pNFS are two example of upcoming minor releases. > > > FYI, V4 was introduced in Fedora Core 2 so it has been around for a while. I > personally have been using it for my home directory for a couple years now.. > For more of the nitty gritty details see > http://www.iaps.com/NFSv4-new-features.html > > That's the good news... Here is the bad.... > > Because the mount command will try NFS v4 first, mounts to older Linux servers > will start failing like: > > # mount linux-server:/export /mnt > mount.nfs: mounting linux-server:/export failed, reason given by server: > No such file or directory > > This is due to a defect in the Linux server exporting code, which is fixed > in F-12, *but* there are a number of workarounds > > On the server (Which is suggested): > * Add the following entry to the /etc/exports file: > / *(ro,fsid=0) Note: 'fsid=0' is explained in the exports(5) man pages. > > On the client, go back to v3 mounts by doing one of the following: > > * Add -o v3 to command line, similar to: > mount linux-server:/export /mnt > > * Change the default mount version in the new /etc/nfsmount.conf file by > uncommenting the Nfsvers=3 setting in the 'NFSMount_Global_Options' section. > See nfsmount.conf(5) man page for details. The diff would look like: > > --- /etc/nfsmount.conf.orig 2009-10-26 09:30:21.000000000 -0400 > +++ /etc/nfsmount.conf 2009-10-26 10:31:30.227443686 -0400 > @@ -31,7 +31,7 @@ > # Protocol Version [2,3,4] > # This defines the default protocol version which will > # be used to start the negotiation with the server. > -# Defaultvers=4 > +Defaultvers=3 > # > # Setting this option makes it mandatory the server supports the > # given version. The mount will fail if the given version is Update... With Build http://koji.fedoraproject.org/koji/taskinfo?taskID=1783028 the mount command will first try to do a v4 mount and then fall back to v3/v2 mounts if v4 is not support. This fall back will also happen if the server returns ENOENT, which will be the case with legacy Linux servers and possible Netapp servers... I hope to get the ENOENT-patch into F-12 as soon as it bakes a while in rawhide and once F-12 stabilizes... Thanks for all the input!!! steved. From nicolas.mailhot at laposte.net Mon Nov 2 19:45:45 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 2 Nov 2009 20:45:45 +0100 Subject: Font rendering slightly degraded in recent rawhide In-Reply-To: <4AEF18A5.8030202@robertoragusa.it> References: <20091029092026.GB25682@mother.pipebreaker.pl> <1256838536.2314.30.camel@adam.local.net> <4AEED7D6.3050109@robertoragusa.it> <1257180514.2314.204.camel@adam.local.net> <4AEF18A5.8030202@robertoragusa.it> Message-ID: <1ec9f87ec7fe136f3d6a85dd97939cb5.squirrel@arekh.dyndns.org> Le Lun 2 novembre 2009 18:36, Roberto Ragusa a ?crit : > I've never said that Luxi fonts are better than DejaVu fonts. > What I've said is that there is no alternative to Luxi Mono > if one wants a serif monospaced font. > I like to have a serif font in my shell; I find it more readable, > even at small size. It depends on how serify you want it of course. You have many monospace fonts that are more serify than DejaVu Sans Mono without using all the serifs you'd expect in a completely serif font (Anonymous Pro, Incosolata, etc). Monospace is pretty much the antithesis of serif, subtle serifs look good at high resolution on paper, monospace is used on computer screens at low res. Serif monos usually end up with courrier-like blocky serifs. And lastly, Verily shows DejaVu Serif could be mono-ified, if someone was willing to pour some energy in it (http://delubrum.org/) -- Nicolas Mailhot From fche at redhat.com Mon Nov 2 20:33:42 2009 From: fche at redhat.com (Frank Ch. Eigler) Date: Mon, 02 Nov 2009 15:33:42 -0500 Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to happen In-Reply-To: <4AEF348C.3060403@RedHat.com> (Steve Dickson's message of "Mon, 02 Nov 2009 14:35:40 -0500") References: <4AE5B378.1000507@RedHat.com> <4AEF348C.3060403@RedHat.com> Message-ID: Steve Dickson writes: > [...] > With Build http://koji.fedoraproject.org/koji/taskinfo?taskID=1783028 > the mount command will first try to do a v4 mount and then fall back > to v3/v2 mounts if v4 is not support. This fall back will also happen > if the server returns ENOENT, which will be the case with legacy Linux > servers and possible Netapp servers... > [...] Thank you! This looks like the Right Thing To Do(tm). - FChE From jarod at redhat.com Mon Nov 2 20:37:02 2009 From: jarod at redhat.com (Jarod Wilson) Date: Mon, 02 Nov 2009 15:37:02 -0500 Subject: Fedora PPC for oldworld Mac? In-Reply-To: <1257185229.3151.29.camel@localhost.localdomain> References: <1256783158.32634.0@localhost.localdomain> <1256818710.9814.150.camel@macbook.infradead.org> <1257185229.3151.29.camel@localhost.localdomain> Message-ID: <4AEF42EE.6070007@redhat.com> On 11/2/09 1:07 PM, Dan Williams wrote: > On Thu, 2009-10-29 at 12:18 +0000, David Woodhouse wrote: >> On Wed, 2009-10-28 at 22:25 -0400, Tony Nelson wrote: >>> On 09-10-28 18:24:49, Josh Boyer wrote: >>>> On Wed, Oct 28, 2009 at 06:17:31PM -0400, Tony Nelson wrote: ... >>>>> Does Fedora PPC work or install on oldworld PCI Macs, such as >>>>> a beige G3 desktop? My impression is that no one has tried it >>>>> on an oldworld ... >> It _ought_ to work if you sort out the bootloader. > > oldworld topped out at 366MHz anyway right? (the 333 and 366 Beige G3 > were only sold from 1998-08-12 -> 1999-01-01 too) That's pretty much > the minimum you'd need to run Fedora anyway these days... Not sure it's > really worth it, you'll need at least 256MB of RAM anyway, and those > things used 168-pin 3.3V DIMMs which are pretty hard to find these days. Stock might have topped out around there, but there were assorted aftermarket upgrades one could purchase. I had a Beige G3 tower running at 533MHz with 768MB of RAM at one point in time, iirc. -- Jarod Wilson jarod at redhat.com From denis at poolshark.org Mon Nov 2 20:47:47 2009 From: denis at poolshark.org (Denis Leroy) Date: Mon, 02 Nov 2009 21:47:47 +0100 Subject: Wodim trouble In-Reply-To: <1257185899.7251.212.camel@atropine.boston.devel.redhat.com> References: <1257157747.2767.2.camel@localhost> <4AEF13ED.60001@redhat.com> <1257185899.7251.212.camel@atropine.boston.devel.redhat.com> Message-ID: <4AEF4573.7090407@poolshark.org> On 11/02/2009 07:18 PM, Adam Jackson wrote: > That may be true, but since cdrecord is not shippable, it's a pretty > vacuous truth. Out of curiosity, was that just because of the GPL2-CDDL mix ? Or was there another reason ? Last I checked, only mkisofs is affected by that and the rest of cdrecord is pure CDDL. If we patched mkisofs away, would it be shippable ? Spot ? -denis From khc at pm.waw.pl Mon Nov 2 20:55:04 2009 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Mon, 02 Nov 2009 21:55:04 +0100 Subject: Installing F12-Beta In-Reply-To: <1257146487.5192.32.camel@macbook.infradead.org> (David Woodhouse's message of "Mon, 02 Nov 2009 07:21:27 +0000") References: <1257111085.2314.154.camel@adam.local.net> <1257121770.13416.3.camel@mylaptop.myhome> <1257146487.5192.32.camel@macbook.infradead.org> Message-ID: David Woodhouse writes: > My crystal ball isn't working today, so I _couldn't_ help you, even if I > _didn't_ have a policy of not helping thread-hijackers until they post > their problem politely ;) Oh, I guess it's time to consider installing a RAICB, a Redundant Array of Inexpensive Crystal Balls :-) Then it's clear the error is actually "Fixing recursive fault but reboot is needed!" and it's most probably a kernel or hardware problem. -- Krzysztof Halasa From matt at truch.net Mon Nov 2 21:13:53 2009 From: matt at truch.net (Matthew D Truch) Date: Mon, 2 Nov 2009 16:13:53 -0500 Subject: Strange dependency of cpl in rawhide In-Reply-To: <20091102174946.GE17555@truch.net> References: <89b36810911010556j43469fd2kb93dee7878002628@mail.gmail.com> <1860.97.124.131.64.1257092897.squirrel@www.cora.nwra.com> <20091102174946.GE17555@truch.net> Message-ID: <20091102211353.GK17555@truch.net> > > > Hello, I have built a new release of cpl (an astronomical data > > > processing library) in koji. In rawhide, I get an (incorrect) > > > dependency on libcfitsio.so > > > > > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=1637146 > > > > > > where as in fc12 I get the correct dependency on libcfitsio.so.0: > > > > > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=1639093 > > > > > > cfitsio provides libcfitsio.so.0 in both rawhide and fc12: > > > > > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=1621497 > > > > For some reason, 3.210 in f13 no longer sets the soname to libcfitsio.so.0 > > (which you can see in the cfitsio build logs). This should get fixed. > > Yikes. Let me get on that. This should be fixed now in 3.210-2 (just built). Let me know if there are still issues. -- "One in every seven days is a Thursday." -------------------------- Matthew Truch Department of Physics and Astronomy University of Pennsylvania matt at truch.net http://matt.truch.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rajeeshknambiar at gmail.com Mon Nov 2 21:26:24 2009 From: rajeeshknambiar at gmail.com (Rajeesh K Nambiar) Date: Tue, 3 Nov 2009 02:56:24 +0530 Subject: Font rendering slightly degraded in recent rawhide In-Reply-To: <1257180514.2314.204.camel@adam.local.net> References: <20091029092026.GB25682@mother.pipebreaker.pl> <1256838536.2314.30.camel@adam.local.net> <4AEED7D6.3050109@robertoragusa.it> <1257180514.2314.204.camel@adam.local.net> Message-ID: <815462c80911021326n6e10cdbata9ae9472604cc47a@mail.gmail.com> On Mon, Nov 2, 2009 at 10:18 PM, Adam Williamson wrote: > On Mon, 2009-11-02 at 14:00 +0100, Roberto Ragusa wrote: >> Adam Williamson wrote: >> >> > And why the hell are you still using Luxi Mono, anyway? that thing went >> > out with the ark... >> >> I'm not the person you are posing your question to, but I use Luxi Mono >> and can give you an answer: >> "Because it is a wonderful serif mono font. Can you suggest me an >> alternative? It looks like mono => sans nowadays." > > I'm a big member of the 'fonts are subjective' bandwagon, but I'm > _really_ surprised that anyone would consider the Luxi fonts to look > better than the DejaVu ones. DejaVu is just a far more polished font > set, which is why it was chosen by all major distros to replace Luxi > years ago. You're literally the first person I've come across who seems > to prefer the appearance of Luxi. Nothing wrong with that, I suppose, > I'm just surprised =) > Here's another one, if you like to :-) I've been a big fan of Luxi fonts from the days of RedHat 8.0. They make my day when I look at the terminal or glance through a code snippet. I did even contact Mr. Chuck Bigelow to find out any possibility of licensing Luxi fonts under an open source license, when Fedora decided to drop them. Today I use a locally built RPM (source files grabbed from Xorg website) with a custom fontconfig file. I must say, it's all a matter of preference :-) > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org > http://www.happyassassin.net > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Cheers, Rajeesh http://rajeeshknambiar.wordpress.com From bruno at wolff.to Mon Nov 2 21:42:42 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 2 Nov 2009 15:42:42 -0600 Subject: Wodim trouble In-Reply-To: <4AEF4573.7090407@poolshark.org> References: <1257157747.2767.2.camel@localhost> <4AEF13ED.60001@redhat.com> <1257185899.7251.212.camel@atropine.boston.devel.redhat.com> <4AEF4573.7090407@poolshark.org> Message-ID: <20091102214242.GA5340@wolff.to> On Mon, Nov 02, 2009 at 21:47:47 +0100, Denis Leroy wrote: > On 11/02/2009 07:18 PM, Adam Jackson wrote: > >That may be true, but since cdrecord is not shippable, it's a pretty > >vacuous truth. > > Out of curiosity, was that just because of the GPL2-CDDL mix ? Or > was there another reason ? Last I checked, only mkisofs is affected > by that and the rest of cdrecord is pure CDDL. If we patched mkisofs > away, would it be shippable ? There is also the issue that J?rg wants devices to be referenced in a particular way that most other developers don't want to do. So a fork may be needed even if licensing is resolved. It doesn't sound like fun work though. I get the impression that there are a lot of device quirks and without sample hardware and a fair amount of dedication it is going to be hard to do a good job. From craftjml at gmail.com Mon Nov 2 21:44:25 2009 From: craftjml at gmail.com (Jud Craft) Date: Mon, 2 Nov 2009 16:44:25 -0500 Subject: updating F11 GNOME release Message-ID: <20d6441a0911021344v66cd68f7w5f92b69b2d7069ca@mail.gmail.com> This is unfortunately not actually a helpful topic, but I am deathly curious. Will GNOME be stuck at 2.26 for the rest of the F11 cycle? Or are updates in the works, just not ready yet? From smooge at gmail.com Mon Nov 2 21:48:31 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 2 Nov 2009 14:48:31 -0700 Subject: updating F11 GNOME release In-Reply-To: <20d6441a0911021344v66cd68f7w5f92b69b2d7069ca@mail.gmail.com> References: <20d6441a0911021344v66cd68f7w5f92b69b2d7069ca@mail.gmail.com> Message-ID: <80d7e4090911021348q292a927csa6806a098ebdeb30@mail.gmail.com> On Mon, Nov 2, 2009 at 2:44 PM, Jud Craft wrote: > This is unfortunately not actually a helpful topic, but I am deathly curious. > > Will GNOME be stuck at 2.26 for the rest of the F11 cycle? ?Or are > updates in the works, just not ready yet? > Normally, the GNOME team normally stays with the same release for a cycle. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From mclasen at redhat.com Mon Nov 2 22:03:49 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 02 Nov 2009 17:03:49 -0500 Subject: updating F11 GNOME release In-Reply-To: <20d6441a0911021344v66cd68f7w5f92b69b2d7069ca@mail.gmail.com> References: <20d6441a0911021344v66cd68f7w5f92b69b2d7069ca@mail.gmail.com> Message-ID: <1257199429.1961.56.camel@planemask> On Mon, 2009-11-02 at 16:44 -0500, Jud Craft wrote: > This is unfortunately not actually a helpful topic, but I am deathly curious. > > Will GNOME be stuck at 2.26 for the rest of the F11 cycle? Or are > updates in the works, just not ready yet? We've updated GNOME in F11 to 2.26.3. We don't do jumps to the next major GNOME version within a released Fedora, that would be incompatible with our understanding of a released product. From bkearney at redhat.com Mon Nov 2 22:15:50 2009 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 02 Nov 2009 17:15:50 -0500 Subject: PPC not getting __WORDSIZE set Message-ID: <4AEF5A16.70604@redhat.com> Word of warning.. I am no too familiar with C across platforms. I am trying to package ruby-ffi (spec file is at [1]) and when I do a scratch build in Koji [2] it runs fine on x86 but is failing in ppc_64. It appears that __WORDSIZE is not being set [3]. I looked at the CFLags for the x86_64 and they are the same, so I assumed things would run fine. Can anyone point me at what to look at next? -- bk [1] Spec file: http://bkearney.fedorapeople.org/ruby-ffi.spec [2] Main Build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1783879 [3] Failing Build Log: http://koji.fedoraproject.org/koji/getfile?taskID=1783882&name=build.log [4] SRPM: http://bkearney.fedorapeople.org/ruby-ffi-0.5.1-1.fc11.src.rpm From jakub at redhat.com Mon Nov 2 22:34:26 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 2 Nov 2009 23:34:26 +0100 Subject: PPC not getting __WORDSIZE set In-Reply-To: <4AEF5A16.70604@redhat.com> References: <4AEF5A16.70604@redhat.com> Message-ID: <20091102223426.GW14664@tyan-ft48-01.lab.bos.redhat.com> On Mon, Nov 02, 2009 at 05:15:50PM -0500, Bryan Kearney wrote: > Word of warning.. I am no too familiar with C across platforms. I am > trying to package ruby-ffi (spec file is at [1]) and when I do a scratch > build in Koji [2] it runs fine on x86 but is failing in ppc_64. It > appears that __WORDSIZE is not being set [3]. I looked at the CFLags for > the x86_64 and they are the same, so I assumed things would run fine. > Can anyone point me at what to look at next? __WORDSIZE is a glibc internal macro, packages shouldn't be using it. Whether it is defined or not depends on whether any of the headers that are included needed to check that macro or not. You should be using __LP64__ or similar macros instead. Jakub From tcallawa at redhat.com Mon Nov 2 23:16:11 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 02 Nov 2009 18:16:11 -0500 Subject: Fwd: Request to update ATi OSS driver for Fedora 12 In-Reply-To: References: Message-ID: <4AEF683B.4030704@redhat.com> On 11/02/2009 05:23 AM, Liang Suilong wrote: > Thank you for hard work. Crhomium browser in Fedora 12 looks perfect. Is > there any plan to push chromium into rawhide or updates-testing. I think > chromium has enough stability to make more users test itself. Not until Chromium comes out of beta and has a sane release model. Even then, it will be an uphill battle, and I'll probably have to petition FESCo for an exception. Not sure when that will be, but if I had to guess, I'd say it is closer to the F13 timeframe. ~spot From tcallawa at redhat.com Mon Nov 2 23:19:53 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 02 Nov 2009 18:19:53 -0500 Subject: Wodim trouble In-Reply-To: <4AEF4573.7090407@poolshark.org> References: <1257157747.2767.2.camel@localhost> <4AEF13ED.60001@redhat.com> <1257185899.7251.212.camel@atropine.boston.devel.redhat.com> <4AEF4573.7090407@poolshark.org> Message-ID: <4AEF6919.8060506@redhat.com> On 11/02/2009 03:47 PM, Denis Leroy wrote: > On 11/02/2009 07:18 PM, Adam Jackson wrote: >> That may be true, but since cdrecord is not shippable, it's a pretty >> vacuous truth. > > Out of curiosity, was that just because of the GPL2-CDDL mix ? Or was > there another reason ? Last I checked, only mkisofs is affected by that > and the rest of cdrecord is pure CDDL. If we patched mkisofs away, would > it be shippable ? That would be a significantly notable fork. If someone did remove all the dependent GPLv2 code in the cdrecord source, I would probably be willing to audit the package for possible inclusion, but I could not in good conscience recommend that anyone maintain that forked code in Fedora, as the upstream author has a long and storied history of being... problematic. ~spot From Joerg.Schilling at fokus.fraunhofer.de Mon Nov 2 23:21:20 2009 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 03 Nov 2009 00:21:20 +0100 Subject: Wodim trouble Message-ID: <4aef6970.BiXJGthIdAQejisR%Joerg.Schilling@fokus.fraunhofer.de> >I've filed a bug[1] against wodim not burning dvds correctly. While >browsing through another bug[2] on wodim, I came across this comment[3]. >"wodim is completely unmaintained since May 6th 2007, don't >expect to see any fixes anytime soon as long as Redhat >continues to distribute wodim instead of the original software." >Can someone please clear this up? Wodim is a creation of a hostile packaging person from Debian. See: http://cdrecord.berlios.de/private/linux-dist.html for more information. Let me give you some facts: The fork did have less changes in the time between May 6th 2007 and today than the original source had in a lazy week. In the same time, the original software had a sustained average putback rate of 3 changes per day. Since May 2006 50% of the code was replaced or added. There is more than 30% new code since then and many many new features and bug fixes. In contrary to the fork, the orogonal project carefully listenes to the bug reports from the users and and reported bugs are typically fixed within a few hours. This is why there are no known bugs in the original software and why there are more than 100 bugs (well known since January 2007) in the fork that are not fixed. All known bugs in the fork will disappear if you just upgrade to recent original software. Roman Rakus and others did verify many times that he is not interested in the problems of the users. Please ignore comments from people like Roman Rakus as he is involved in the attacks against the OpenSource Project cdrtools and thus not interested in a discussion about the backgrounds on why Redhat started to distribute the proken fork instead of the original software. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From tcallawa at redhat.com Mon Nov 2 23:30:49 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 02 Nov 2009 18:30:49 -0500 Subject: Font rendering slightly degraded in recent rawhide In-Reply-To: <815462c80911021326n6e10cdbata9ae9472604cc47a@mail.gmail.com> References: <20091029092026.GB25682@mother.pipebreaker.pl> <1256838536.2314.30.camel@adam.local.net> <4AEED7D6.3050109@robertoragusa.it> <1257180514.2314.204.camel@adam.local.net> <815462c80911021326n6e10cdbata9ae9472604cc47a@mail.gmail.com> Message-ID: <4AEF6BA9.6060500@redhat.com> On 11/02/2009 04:26 PM, Rajeesh K Nambiar wrote: > I did even contact Mr. Chuck Bigelow to find out any > possibility of licensing Luxi fonts under an open source license, when > Fedora decided to drop them. For what it is worth, when we dropped them, I contacted the upstream copyright holder as well, and they opted not to relicense those fonts. Hopefully at some point they may revisit that decision. ~spot From Joerg.Schilling at fokus.fraunhofer.de Mon Nov 2 23:38:36 2009 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 03 Nov 2009 00:38:36 +0100 Subject: Wodim trouble Message-ID: <4aef6d7c.un9WTMYEmBVl8WPI%Joerg.Schilling@fokus.fraunhofer.de> >On the other hand trying to build J?rg's stuff isn't easy on Fedora. And >might not even work as he likes to use a interface that was depreciated >a while back for talking to the cd/dvd drives. I would guess that you are not informed correctly. My software easily compiles on more than 30 different OS platforms by just calling "make". Well, there are many well known bugs in gmake and gmake before 3.81 will not work at all. This is why I recommend to use my "smake". Note that smake is much older than gmake and works on more different platforms that gmake does. I know that some Linux distributions ship with the broken original Linux kernel include files. On such distros, you will have problems to compile any software that supports linux specific features.... If you have problems compiling cdrtools, I recommend you to first start with the complete Schily source distribution from: ftp://ftp.berlios.de/pub/schily/ as this will first compile a bootstrap "smake" and then use this "smake" to compile the rest. Note that I cannot check all platforms for oddities on a regular base as I don't own all the needed hardware. I however do regular full compiles and tests on the following platforms: SunOS-4.1 SunOS-5.x HP-UX 10.20 on HPPA HP-UX 11.11 Haiku (a BEOS clone) FragonFly BSD FreeBSD NetBSD OpenBSD Cygwin Linux (various flavors) Mac OS X All platform compiles are done in 32 _and_ 64 bit on platforms that support 64 bits. If you have proplems on your specific platform, I recommend that you make a bugreport. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling at fokus.fraunhofer.de Mon Nov 2 23:48:37 2009 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 03 Nov 2009 00:48:37 +0100 Subject: Wodim trouble Message-ID: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> >That may be true, but since cdrecord is not shippable, it's a pretty >vacuous truth. The solution is obviously to fix the bug and help revive >upstream, or else host a development tree on fh if upstream stays idle. Note that is is just the other way: It is cdrkit that is undistributable as it is cdrkit that in conflict with the Copyright law and the GPL. Cdrtools has been checked for legal problems by several lawyers including the Sun legal department and none could find any legal problem. Cdrkit was created by a hostile downstream, see: http://cdrecord.berlios.de/private/linux-dist.html and nobody so far was able to prove the claims about so called license problems spread by Eduard Bloch by using quotes from the GPL text. The problem with the existence is a social problem and we, the people in the OSS community need to fid a way to deal with this social problem. P.S.: Libburn is no alternative too: it misses most important features it is non-prtable and we recently learned that the Authors of libburn do not care much about where they take the software from. Note that they claimed not to use any bit from the original cdrtools project's source but they really did use code from cdrtools. I would call this a social problem.... J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From jkeating at redhat.com Mon Nov 2 20:02:17 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 02 Nov 2009 12:02:17 -0800 Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to happen In-Reply-To: <4AEF31BC.80205@RedHat.com> References: <4AE5B378.1000507@RedHat.com> <4AE89491.4030303@RedHat.com> <20091028190514.B7E231D3@magilla.sf.frob.com> <4AE9B222.2060905@RedHat.com> <4AEEFD95.60701@redhat.com> <4AEF31BC.80205@RedHat.com> Message-ID: <1257192137.2268.87.camel@localhost.localdomain> On Mon, 2009-11-02 at 14:23 -0500, Steve Dickson wrote: > I'm not sure about this... Actually I like the fact we can define a > pseudo root other than '/'... which means you really want a live exported > directory with the fsid=0 option... If I am understanding what you are > saying... No, that's not what he's saying. Even if you define a different psuedo root other than /, it's likely more common to /not/ want that root exported in whole, but rather smaller parts of it, just like you don't want / exported in whole, you only want subdirectories exported. I too see this as a major regression in NFS behavior. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From bnocera at redhat.com Tue Nov 3 00:17:33 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 03 Nov 2009 00:17:33 +0000 Subject: Wodim trouble In-Reply-To: <4aef6970.BiXJGthIdAQejisR%Joerg.Schilling@fokus.fraunhofer.de> References: <4aef6970.BiXJGthIdAQejisR%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <1257207453.23167.8.camel@localhost.localdomain> Hey Joerg, On Tue, 2009-11-03 at 00:21 +0100, Joerg Schilling wrote: > >I've filed a bug[1] against wodim not burning dvds correctly. While > >browsing through another bug[2] on wodim, I came across this comment[3]. > > >"wodim is completely unmaintained since May 6th 2007, don't > >expect to see any fixes anytime soon as long as Redhat > >continues to distribute wodim instead of the original software." > > >Can someone please clear this up? > > Wodim is a creation of a hostile packaging person from Debian. > > See: http://cdrecord.berlios.de/private/linux-dist.html > > for more information. > > Let me give you some facts: > > The fork did have less changes in the time between May 6th 2007 and today > than the original source had in a lazy week. I guess it wasn't good enough for you to get booted out of the GNOME Bugzilla? And please fix your mailer to respect threads. Cheers From Joerg.Schilling at fokus.fraunhofer.de Tue Nov 3 00:21:09 2009 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 03 Nov 2009 01:21:09 +0100 Subject: Wodim trouble In-Reply-To: <1257207453.23167.8.camel@localhost.localdomain> References: <4aef6970.BiXJGthIdAQejisR%Joerg.Schilling@fokus.fraunhofer.de> <1257207453.23167.8.camel@localhost.localdomain> Message-ID: <4aef7775.RphyRpRUFprHix4z%Joerg.Schilling@fokus.fraunhofer.de> Bastien Nocera wrote: > I guess it wasn't good enough for you to get booted out of the GNOME > Bugzilla? Well, there are always some bad guys who don't like to see people who help users. The person from the GNOME project just verified that he attacks people who are helpful. He does not seem to be important. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From bkearney at redhat.com Tue Nov 3 00:26:31 2009 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 02 Nov 2009 19:26:31 -0500 Subject: PPC not getting __WORDSIZE set In-Reply-To: <20091102223426.GW14664@tyan-ft48-01.lab.bos.redhat.com> References: <4AEF5A16.70604@redhat.com> <20091102223426.GW14664@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <4AEF78B7.2050102@redhat.com> On 11/02/2009 05:34 PM, Jakub Jelinek wrote: > On Mon, Nov 02, 2009 at 05:15:50PM -0500, Bryan Kearney wrote: >> Word of warning.. I am no too familiar with C across platforms. I am >> trying to package ruby-ffi (spec file is at [1]) and when I do a scratch >> build in Koji [2] it runs fine on x86 but is failing in ppc_64. It >> appears that __WORDSIZE is not being set [3]. I looked at the CFLags for >> the x86_64 and they are the same, so I assumed things would run fine. >> Can anyone point me at what to look at next? > > __WORDSIZE is a glibc internal macro, packages shouldn't be using it. > Whether it is defined or not depends on whether any of the headers that are > included needed to check that macro or not. > > You should be using __LP64__ or similar macros instead. > > Jakub > I saw the macro in the /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory So.. I am not setting it, I assume it is not being set correctly on my behalf. -- bk From jakub at redhat.com Tue Nov 3 00:42:20 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 3 Nov 2009 01:42:20 +0100 Subject: PPC not getting __WORDSIZE set In-Reply-To: <4AEF78B7.2050102@redhat.com> References: <4AEF5A16.70604@redhat.com> <20091102223426.GW14664@tyan-ft48-01.lab.bos.redhat.com> <4AEF78B7.2050102@redhat.com> Message-ID: <20091103004220.GX14664@tyan-ft48-01.lab.bos.redhat.com> On Mon, Nov 02, 2009 at 07:26:31PM -0500, Bryan Kearney wrote: > /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or > directory That means you don't have glibc-devel installed for the arch you need, on ppc you likely have installed glibc-devel.ppc64 but need also glibc-devel.ppc if you want to compile 32-bit programs. Jakub From kevin.kofler at chello.at Tue Nov 3 01:39:25 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 03 Nov 2009 02:39:25 +0100 Subject: Wodim trouble References: <4aef6970.BiXJGthIdAQejisR%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: Joerg Schilling wrote: > why Redhat started to distribute the proken fork instead of the original > software. The only thing that's "proken" (sic) is your spelling. Kevin Kofler From kevin.kofler at chello.at Tue Nov 3 01:41:58 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 03 Nov 2009 02:41:58 +0100 Subject: Wodim trouble References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: Joerg Schilling wrote: > It is cdrkit that is undistributable as it is cdrkit that in conflict with > the Copyright law and the GPL. Maybe under your reality distortion field. In the rest of the world, that's just not true. Kevin Kofler From belegdol at gmail.com Tue Nov 3 01:48:08 2009 From: belegdol at gmail.com (Julian Sikorski) Date: Tue, 03 Nov 2009 02:48:08 +0100 Subject: Wodim trouble In-Reply-To: <4AEF6919.8060506@redhat.com> References: <1257157747.2767.2.camel@localhost> <4AEF13ED.60001@redhat.com> <1257185899.7251.212.camel@atropine.boston.devel.redhat.com> <4AEF4573.7090407@poolshark.org> <4AEF6919.8060506@redhat.com> Message-ID: W dniu 03.11.2009 00:19, Tom "spot" Callaway pisze: > On 11/02/2009 03:47 PM, Denis Leroy wrote: >> On 11/02/2009 07:18 PM, Adam Jackson wrote: >>> That may be true, but since cdrecord is not shippable, it's a pretty >>> vacuous truth. >> >> Out of curiosity, was that just because of the GPL2-CDDL mix ? Or was >> there another reason ? Last I checked, only mkisofs is affected by that >> and the rest of cdrecord is pure CDDL. If we patched mkisofs away, would >> it be shippable ? > > That would be a significantly notable fork. If someone did remove all > the dependent GPLv2 code in the cdrecord source, I would probably be > willing to audit the package for possible inclusion, but I could not in > good conscience recommend that anyone maintain that forked code in > Fedora, as the upstream author has a long and storied history of > being... problematic. > > ~spot > opensuse are shipping cdrecord, maybe it would be worth checking what they changed, if at all? Julian From ngompa13 at gmail.com Tue Nov 3 01:55:49 2009 From: ngompa13 at gmail.com (King InuYasha) Date: Mon, 2 Nov 2009 19:55:49 -0600 Subject: Wodim trouble In-Reply-To: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> On Mon, Nov 2, 2009 at 5:48 PM, Joerg Schilling < Joerg.Schilling at fokus.fraunhofer.de> wrote: > >That may be true, but since cdrecord is not shippable, it's a pretty > >vacuous truth. The solution is obviously to fix the bug and help revive > >upstream, or else host a development tree on fh if upstream stays idle. > > Note that is is just the other way: > > It is cdrkit that is undistributable as it is cdrkit that in conflict with > the Copyright law and the GPL. > > Cdrtools has been checked for legal problems by several lawyers including > the Sun legal department and none could find any legal problem. > > Cdrkit was created by a hostile downstream, see: > > http://cdrecord.berlios.de/private/linux-dist.html > > and nobody so far was able to prove the claims about so called license > problems spread by Eduard Bloch by using quotes from the GPL text. > > The problem with the existence is a social problem and we, the people > in the OSS community need to fid a way to deal with this social problem. > > > P.S.: > Libburn is no alternative too: it misses most important features it is > non-prtable and we recently learned that the Authors of libburn do not > care much about where they take the software from. Note that they claimed > not > to use any bit from the original cdrtools project's source but they really > did > use code from cdrtools. I would call this a social problem.... > > J?rg > > What is going on here? I thought Fedora only shipped upstream code? What's all this business about having broken forks and licensing issues? The only thing I can figure out from this conversation is that the CDDL is supposed to be incompatible with the GPL. If that's the case, why not simply ask the original creator to kindly dual license it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnocera at redhat.com Tue Nov 3 02:06:00 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 03 Nov 2009 02:06:00 +0000 Subject: Wodim trouble In-Reply-To: <4aef7775.RphyRpRUFprHix4z%Joerg.Schilling@fokus.fraunhofer.de> References: <4aef6970.BiXJGthIdAQejisR%Joerg.Schilling@fokus.fraunhofer.de> <1257207453.23167.8.camel@localhost.localdomain> <4aef7775.RphyRpRUFprHix4z%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <1257213960.23167.10.camel@localhost.localdomain> On Tue, 2009-11-03 at 01:21 +0100, Joerg Schilling wrote: > Bastien Nocera wrote: > > > I guess it wasn't good enough for you to get booted out of the GNOME > > Bugzilla? > > Well, there are always some bad guys who don't like to see people who help > users. > > The person from the GNOME project just verified that he attacks people who are > helpful. He does not seem to be important. The person being Olav Vitters, one of the GNOME bugmasters, and that was at my request, after you polluted the GNOME Bugzilla with rants about your inadequately licensed software. Pur-lease. From jonstanley at gmail.com Tue Nov 3 04:08:53 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Mon, 2 Nov 2009 23:08:53 -0500 Subject: FESCo meeting summary for 20091030 Message-ID: Oops, I forgot to send this on Friday - sorry! ======================================= #fedora-meeting: FESCo meeting 20091030 ======================================= Meeting started by jds2001 at 17:00:16 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2009-10-30/fesco.2009-10-30-17.00.log.html . Meeting summary --------------- * quick DST question (jds2001, 17:01:37) * AGREED: meeting will stay 1700UTC (jds2001, 17:03:53) * fluidsynth and PA (jds2001, 17:04:44) * LINK: http://markmail.org/message/bovdqb7na3zor2ck - without comment. (mjg59, 17:17:07) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=500087#c13 (jds2001, 17:19:22) * AGREED: PA backend for fluidsynth must be built. If the current maintainer refuses, Kevin_Kofler will take over as maintainer. (jds2001, 17:32:01) * legally objectionable, binary and non-free items (jds2001, 17:33:34) * AGREED: spot's proposal is accpeted. (jds2001, 17:47:00) * open floor (jds2001, 17:50:47) * LINK: https://fedoraproject.org/wiki/FUDCon:Toronto_2009_Packaging_Guidelines_Hackfest (abadger1999, 17:58:29) * LINK: https://fedoraproject.org/wiki/FUDCon:Toronto_2009_Packaging_Guidelines_Hackfest (jds2001, 17:59:09) Meeting ended at 18:10:35 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * jds2001 (99) * skvidal (98) * Kevin_Kofler (79) * nirik (66) * dwmw2 (40) * drago01 (27) * abadger1999 (25) * j-rod (23) * dgilmore (17) * notting (13) * Oxf13 (12) * XulWork (7) * zodbot (7) * spot (4) * sharkcz (4) * mjg59 (2) * buggbot (2) * wwoods (1) * pingou (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot From sanjay.ankur at gmail.com Tue Nov 3 04:22:00 2009 From: sanjay.ankur at gmail.com (Ankur Sinha) Date: Tue, 03 Nov 2009 09:52:00 +0530 Subject: Wodim trouble In-Reply-To: <1257213960.23167.10.camel@localhost.localdomain> References: <4aef6970.BiXJGthIdAQejisR%Joerg.Schilling@fokus.fraunhofer.de> <1257207453.23167.8.camel@localhost.localdomain> <4aef7775.RphyRpRUFprHix4z%Joerg.Schilling@fokus.fraunhofer.de> <1257213960.23167.10.camel@localhost.localdomain> Message-ID: <1257222121.15471.2.camel@localhost> On Tue, 2009-11-03 at 02:06 +0000, Bastien Nocera wrote: > On Tue, 2009-11-03 at 01:21 +0100, Joerg Schilling wrote: > > Bastien Nocera wrote: > > > > > I guess it wasn't good enough for you to get booted out of the GNOME > > > Bugzilla? > > > > Well, there are always some bad guys who don't like to see people who help > > users. > > > > The person from the GNOME project just verified that he attacks people who are > > helpful. He does not seem to be important. > > The person being Olav Vitters, one of the GNOME bugmasters, and that was > at my request, after you polluted the GNOME Bugzilla with rants about > your inadequately licensed software. Pur-lease. > hi folks, Looks like another thread going the wrong way. I just wanted to know if wodim is usable (i mean without wasting dvds like its doing currently for me). From the discussion, I feel it's still buggy and therefore I'm going to shift to another program (maybe growisofs). Thank you all for your inputs :) -- regards, Ankur From awilliam at redhat.com Tue Nov 3 04:43:04 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 02 Nov 2009 20:43:04 -0800 Subject: FESCo meeting summary for 20091030 In-Reply-To: References: Message-ID: <1257223384.2388.9.camel@adam.local.net> On Mon, 2009-11-02 at 23:08 -0500, Jon Stanley wrote: > * legally objectionable, binary and non-free items (jds2001, > 17:33:34) > * AGREED: spot's proposal is accpeted. (jds2001, 17:47:00) Not the _best_ example of good meeting summary practice I've ever seen =) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From liangsuilong at gmail.com Tue Nov 3 04:46:39 2009 From: liangsuilong at gmail.com (Liang Suilong) Date: Tue, 3 Nov 2009 12:46:39 +0800 Subject: GRUB2 In Fedora Message-ID: Some Linux distros has migrated from grub-0.97 to grub2-1.97. Grub2 provides more useful features to users. And it is more easy to add a new file system support. But I can not see Fedora has any plan for GRUB2. I read a feature page on Fedora wiki. There is no progress on grub2. Now Fedora official repo offers grub2 package. However the version is quite strange. Fedora provides grub2-1.98. In fact, this version was 1.96 grabbed from svn repo on Aug 27th, 2008. Also, maintainer adds some patches to fix the bug. But GNU released grub2-1.97 just now. In addition, I try to write grub2 into MBR of the HDD. I do not know why. Is there a bug in grub2? -- http://www.liangsuilong.info Fight for freedom!!!!(3F? Ask not what your Linux distro can do for you! Ask what you can do for your Linux distro! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rakesh.pandit at gmail.com Tue Nov 3 04:50:04 2009 From: rakesh.pandit at gmail.com (Rakesh Pandit) Date: Tue, 3 Nov 2009 10:20:04 +0530 Subject: Package Review Stats for last 7 days ending 1st Nov Message-ID: Top three FAS account holders who have completed reviewing "Package review" components on bugzilla for last 7 days ending 1st Nov were Mamoru Tasaka, Thomas Spura and Peter Lemenkov. Mamoru Tasaka : 3 https://bugzilla.redhat.com/show_bug.cgi?id=509936 https://bugzilla.redhat.com/show_bug.cgi?id=530275 https://bugzilla.redhat.com/show_bug.cgi?id=531408 Thomas Spura : 3 https://bugzilla.redhat.com/show_bug.cgi?id=528010 https://bugzilla.redhat.com/show_bug.cgi?id=522613 https://bugzilla.redhat.com/show_bug.cgi?id=530568 Peter Lemenkov : 2 https://bugzilla.redhat.com/show_bug.cgi?id=529831 https://bugzilla.redhat.com/show_bug.cgi?id=509159 Alexander Kurtakov : 1 https://bugzilla.redhat.com/show_bug.cgi?id=530986 Christoph Wickert : 1 https://bugzilla.redhat.com/show_bug.cgi?id=530743 Emmanuel Seyman : 1 https://bugzilla.redhat.com/show_bug.cgi?id=530324 Ian Weller : 1 https://bugzilla.redhat.com/show_bug.cgi?id=521724 Jerry James : 1 https://bugzilla.redhat.com/show_bug.cgi?id=529084 Jon Stanley : 1 https://bugzilla.redhat.com/show_bug.cgi?id=524107 Jos?? Matos : 1 https://bugzilla.redhat.com/show_bug.cgi?id=519282 Nick Bebout : 1 https://bugzilla.redhat.com/show_bug.cgi?id=521723 Nicolas Mailhot : 1 https://bugzilla.redhat.com/show_bug.cgi?id=530857 Roman Rakus : 1 https://bugzilla.redhat.com/show_bug.cgi?id=502609 Total reviews modified: 18 Merge Reviews: 0 Review Requests: 18 This report by generated by bzReviewReport.py. The source is available at: https://fedorahosted.org/triage/browser/scripts/bzReviewReport.py Please submit patches or bug reports at: https://fedorahosted.org/triage/ -- Rakesh Pandit https://fedoraproject.org/ freedom, friends, features, first From josephine.tannhauser at googlemail.com Tue Nov 3 05:17:31 2009 From: josephine.tannhauser at googlemail.com (=?UTF-8?Q?Josephine_Tannh=C3=A4user?=) Date: Tue, 3 Nov 2009 06:17:31 +0100 Subject: updating F11 GNOME release In-Reply-To: <1257199429.1961.56.camel@planemask> References: <20d6441a0911021344v66cd68f7w5f92b69b2d7069ca@mail.gmail.com> <1257199429.1961.56.camel@planemask> Message-ID: <3668e9f50911022117y62262abbo9df7850d75e463c5@mail.gmail.com> 2009/11/2 Matthias Clasen > We don't do jumps to the next major GNOME version within a released > Fedora, that would be incompatible with our understanding of a released > product. > I hope the KDE-sig will take up this stance on her own releasecycles. @Judd, wait for the F12 release, it's the best 'update' and it is not ready yet! -- Josephine "Fine" Tannh?user 2.6.29.6-213.fc11.i586 -------------- next part -------------- An HTML attachment was scrubbed... URL: From craftjml at gmail.com Tue Nov 3 05:59:23 2009 From: craftjml at gmail.com (Jud Craft) Date: Tue, 3 Nov 2009 00:59:23 -0500 Subject: updating F11 GNOME release In-Reply-To: <3668e9f50911022117y62262abbo9df7850d75e463c5@mail.gmail.com> References: <20d6441a0911021344v66cd68f7w5f92b69b2d7069ca@mail.gmail.com> <1257199429.1961.56.camel@planemask> <3668e9f50911022117y62262abbo9df7850d75e463c5@mail.gmail.com> Message-ID: <20d6441a0911022159t2f8eca78k2995808872f36916@mail.gmail.com> > @Judd, wait for the F12 release, it's the best 'update' and it is not ready > yet! I hope so. I'm not sure anything can top Fedora 8. Hard to explain how much I enjoyed that distribution. From josephine.tannhauser at googlemail.com Tue Nov 3 06:08:56 2009 From: josephine.tannhauser at googlemail.com (=?UTF-8?Q?Josephine_Tannh=C3=A4user?=) Date: Tue, 3 Nov 2009 07:08:56 +0100 Subject: updating F11 GNOME release In-Reply-To: <20d6441a0911022159t2f8eca78k2995808872f36916@mail.gmail.com> References: <20d6441a0911021344v66cd68f7w5f92b69b2d7069ca@mail.gmail.com> <1257199429.1961.56.camel@planemask> <3668e9f50911022117y62262abbo9df7850d75e463c5@mail.gmail.com> <20d6441a0911022159t2f8eca78k2995808872f36916@mail.gmail.com> Message-ID: <3668e9f50911022208x3bb21d02yc11df44a64d7029@mail.gmail.com> 2009/11/3 Jud Craft > I hope so. I'm not sure anything can top Fedora 8. Hard to explain > how much I enjoyed that distribution. > mmh, the Gnome Desktop Live CD of F12 is really more gnomish since the CDs before. No qt, no openoffice, abiword gnumeric is still missing and epiphany should replace the firefox, but hey.... It's not perfect, but better than before! -- Josephine "Fine" Tannh?user 2.6.29.6-213.fc11.i586 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonynelson at georgeanelson.com Tue Nov 3 07:46:42 2009 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Tue, 03 Nov 2009 02:46:42 -0500 Subject: Fedora PPC for oldworld Mac? In-Reply-To: <1257185229.3151.29.camel@localhost.localdomain> (from dcbw@redhat.com on Mon Nov 2 13:07:09 2009) Message-ID: <1257234402.29277.0@localhost.localdomain> On 09-11-02 13:07:09, Dan Williams wrote: > oldworld topped out at 366MHz anyway right? (the 333 and 366 Beige > G3 were only sold from 1998-08-12 -> 1999-01-01 too) That's pretty > much the minimum you'd need to run Fedora anyway these days... Not > sure it's really worth it, you'll need at least 256MB of RAM anyway, > and those things used 168-pin 3.3V DIMMs which are pretty hard to > find these days. FWIW, my machine, a beige G3, is 233 MHz and has accumulated 416 MiB over the years. It handles Debian Lenny Iceweasel OK, but then, my main computer is a 1.2 GHz Athlon. > The Blue & White G3 was the first New World machine I think. Yes. > Remember too that you'll need your boot partition within the first > 8GB of the drive as the firmware can't handle booting from a > partition which ends anywhere past that. I'm using BootX, so it's not an issue. (Fiddling with buggy openfirmware seems like something to avoid, anyway.) -- ____________________________________________________________________ TonyN.:' ' From joshuacov at googlemail.com Tue Nov 3 08:25:30 2009 From: joshuacov at googlemail.com (Joshua C.) Date: Tue, 3 Nov 2009 09:25:30 +0100 Subject: GRUB2 In Fedora In-Reply-To: References: Message-ID: <5f6f8c5f0911030025x78526b69n98e21aafd9ef117b@mail.gmail.com> 2009/11/3 Liang Suilong : > Some Linux distros has migrated from grub-0.97 to grub2-1.97. Grub2 provides > more useful features to users. And it is more easy to add a new ?file system > support. But I can not see Fedora has any plan for GRUB2. I read a feature > page on Fedora wiki. There is no progress on grub2. > Now Fedora official repo offers grub2 package. However the version is quite > strange. Fedora provides grub2-1.98. In fact, this version was 1.96 grabbed > from svn?repo on Aug 27th, 2008. Also, maintainer adds some patches to fix > the bug. But GNU released grub2-1.97 just now. > In addition, I try to write grub2 into MBR of the HDD. I do not know why. Is > there a bug in grub2? > -- > http://www.liangsuilong.info > Fight for freedom!!!!(3F? > Ask not what your Linux distro can do for you! > Ask what you can do for your Linux distro! > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I don't see any need for this. The current grub (0.97) can boot from ext4, works fine with windows and other distros and has almost (no) other issues. why to fix it when it ain't broken? From cemeyer at u.washington.edu Tue Nov 3 08:26:39 2009 From: cemeyer at u.washington.edu (Conrad Meyer) Date: Tue, 3 Nov 2009 00:26:39 -0800 Subject: Wodim trouble In-Reply-To: <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> Message-ID: <200911030026.39420.cemeyer@u.washington.edu> On Monday 02 November 2009 05:55:49 pm King InuYasha wrote: > What is going on here? I thought Fedora only shipped upstream code? What's > all this business about having broken forks and licensing issues? > > The only thing I can figure out from this conversation is that the CDDL is > supposed to be incompatible with the GPL. If that's the case, why not > simply ask the original creator to kindly dual license it? In this case, upstream (wodim) is a fork of Joerg Schilling's project. Wodim was forked from cdrecord because Joerg is crazy. Joerg likes to call wodim "the broken fork" and cdrecord "the original software". Hope that helps, -- Conrad Meyer From josephine.tannhauser at googlemail.com Tue Nov 3 08:48:07 2009 From: josephine.tannhauser at googlemail.com (=?UTF-8?Q?Josephine_Tannh=C3=A4user?=) Date: Tue, 3 Nov 2009 09:48:07 +0100 Subject: Wodim trouble In-Reply-To: <200911030026.39420.cemeyer@u.washington.edu> References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> <200911030026.39420.cemeyer@u.washington.edu> Message-ID: <3668e9f50911030048k5e2aa5c8lef3b38d5f92c6a50@mail.gmail.com> 2009/11/3 Conrad Meyer > In this case, upstream (wodim) is a fork of Joerg Schilling's project. > Wodim > was forked from cdrecord because Joerg is crazy. Joerg likes to call wodim > "the broken fork" and cdrecord "the original software". > He visited all the booths of linux distributions at "Chemnitzer Linux Tage" and started some trouble. The ML and BZ of the Linuxdistros, which are using wodim is the outlet of J?rgs furious anger about the fork and the debian maintainer who is the upstream coder of wodim! There was already a 'wodim vs. cdrecord' discussion at fedora-legal-list. I have a big respect for J?rg, not for him as person, but for his attainments! -- Josephine "Fine" Tannh?user 2.6.29.6-213.fc11.i586 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joerg.Schilling at fokus.fraunhofer.de Tue Nov 3 09:08:48 2009 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 03 Nov 2009 10:08:48 +0100 Subject: Wodim trouble In-Reply-To: <1257222121.15471.2.camel@localhost> References: <4aef6970.BiXJGthIdAQejisR%Joerg.Schilling@fokus.fraunhofer.de> <1257207453.23167.8.camel@localhost.localdomain> <4aef7775.RphyRpRUFprHix4z%Joerg.Schilling@fokus.fraunhofer.de> <1257213960.23167.10.camel@localhost.localdomain> <1257222121.15471.2.camel@localhost> Message-ID: <4aeff320.VsnVvgDaehMsnwA/%Joerg.Schilling@fokus.fraunhofer.de> Ankur Sinha wrote: > Looks like another thread going the wrong way. > > I just wanted to know if wodim is usable (i mean without wasting dvds > like its doing currently for me). From the discussion, I feel it's still > buggy and therefore I'm going to shift to another program (maybe > growisofs). Well, people like you who try to use the fork know that it is just having too many bugs for being useful. Please note that growisofs is not the solution for a wider problem: growisofs of course needs mkisofs and redhat does not ship a working mkisofs bug the broken "genisoimage". Growisofs is also known to have problems with some DVD drives where cdrecord has no problem. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling at fokus.fraunhofer.de Tue Nov 3 09:12:14 2009 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 03 Nov 2009 10:12:14 +0100 Subject: Wodim trouble In-Reply-To: <1257213960.23167.10.camel@localhost.localdomain> References: <4aef6970.BiXJGthIdAQejisR%Joerg.Schilling@fokus.fraunhofer.de> <1257207453.23167.8.camel@localhost.localdomain> <4aef7775.RphyRpRUFprHix4z%Joerg.Schilling@fokus.fraunhofer.de> <1257213960.23167.10.camel@localhost.localdomain> Message-ID: <4aeff3ee.4NaoSIuG3NR8coUz%Joerg.Schilling@fokus.fraunhofer.de> Bastien Nocera wrote: > > The person from the GNOME project just verified that he attacks people who are > > helpful. He does not seem to be important. > > The person being Olav Vitters, one of the GNOME bugmasters, and that was > at my request, after you polluted the GNOME Bugzilla with rants about > your inadequately licensed software. Pur-lease. Everybody can check the GNOME bugtracking system himself and verify that I have been banned for explaining the _technical_ background of a reported bug and for giving instructions on how to work around the problem. It is obvious that Olav Vitters (and ayou??) made a social attack against an author of OpenSource software. You are not very convincing....... J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From kevin.kofler at chello.at Tue Nov 3 09:42:08 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 03 Nov 2009 10:42:08 +0100 Subject: updating F11 GNOME release References: <20d6441a0911021344v66cd68f7w5f92b69b2d7069ca@mail.gmail.com> <1257199429.1961.56.camel@planemask> <3668e9f50911022117y62262abbo9df7850d75e463c5@mail.gmail.com> Message-ID: Josephine Tannh?user wrote: > 2009/11/2 Matthias Clasen > >> We don't do jumps to the next major GNOME version within a released >> Fedora, that would be incompatible with our understanding of a released >> product. >> > I hope the KDE-sig will take up this stance on her own releasecycles. Uh, why? What's wrong with our updates (other than them being updates ;-) )? Any concrete complaints? Kevin Kofler From mschwendt at gmail.com Tue Nov 3 09:48:51 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 3 Nov 2009 10:48:51 +0100 Subject: libsndfile status? Message-ID: <20091103104851.571a717f@faldor.intranet> https://admin.fedoraproject.org/pkgdb/packages/bugs/libsndfile What's up with libsndfile in Fedora and EPEL? There are open tickets about CVEs filed in March. There are additional tickets without any reply. From kevin.kofler at chello.at Tue Nov 3 09:47:00 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 03 Nov 2009 10:47 +0100 Subject: Wodim trouble References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> Message-ID: King InuYasha wrote: > The only thing I can figure out from this conversation is that the CDDL is > supposed to be incompatible with the GPL. If that's the case, why not > simply ask the original creator to kindly dual license it? We did, many times. He refuses to acknowledge there's any problem at all and insists that mixing the CDDL and the GPL is legal (despite the FSF and many others clearly saying it's not), citing some Sun lawyers (who clearly have an agenda to push the CDDL). Kevin Kofler From che666 at gmail.com Tue Nov 3 10:02:20 2009 From: che666 at gmail.com (Rudolf Kastl) Date: Tue, 3 Nov 2009 11:02:20 +0100 Subject: GRUB2 In Fedora In-Reply-To: References: Message-ID: 2009/11/3 Liang Suilong : > Some Linux distros has migrated from grub-0.97 to grub2-1.97. Grub2 provides > more useful features to users. And it is more easy to add a new ?file system > support. But I can not see Fedora has any plan for GRUB2. I read a feature > page on Fedora wiki. There is no progress on grub2. > Now Fedora official repo offers grub2 package. However the version is quite > strange. Fedora provides grub2-1.98. In fact, this version was 1.96 grabbed > from svn?repo on Aug 27th, 2008. Also, maintainer adds some patches to fix > the bug. But GNU released grub2-1.97 just now. > In addition, I try to write grub2 into MBR of the HDD. I do not know why. Is > there a bug in grub2? > -- > http://www.liangsuilong.info > Fight for freedom!!!!(3F? > Ask not what your Linux distro can do for you! > Ask what you can do for your Linux distro! > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > see: http://fedoraproject.org/wiki/Features/Grub2 as for the outdated version... feel free to open a bug ticket and request an update to the latest stable version of grub2. kind regards, Rudolf Kastl From Joerg.Schilling at fokus.fraunhofer.de Tue Nov 3 10:15:51 2009 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 03 Nov 2009 11:15:51 +0100 Subject: Wodim trouble In-Reply-To: References: <1257157747.2767.2.camel@localhost> <4AEF13ED.60001@redhat.com> <1257185899.7251.212.camel@atropine.boston.devel.redhat.com> <4AEF4573.7090407@poolshark.org> <4AEF6919.8060506@redhat.com> Message-ID: <4af002d7.jgo4mm+gG17Y0pTi%Joerg.Schilling@fokus.fraunhofer.de> Julian Sikorski wrote: > > On 11/02/2009 03:47 PM, Denis Leroy wrote: > >> On 11/02/2009 07:18 PM, Adam Jackson wrote: > >>> That may be true, but since cdrecord is not shippable, it's a pretty > >>> vacuous truth. > >> > >> Out of curiosity, was that just because of the GPL2-CDDL mix ? Or was > >> there another reason ? Last I checked, only mkisofs is affected by that > >> and the rest of cdrecord is pure CDDL. If we patched mkisofs away, would > >> it be shippable ? ... > opensuse are shipping cdrecord, maybe it would be worth checking what > they changed, if at all? There is no legal problem with the original software, there is only a social problem caused by a hostile downstream (a Debian packager). See http://cdrecord.berlios.de/private/linux-dist.html for an overview. Let me give you some background on the legal situation: There are some people who claim that there is a legal problem with the original software but none of the persons who spread this claim (including people from redhat) did ever make a valid legal statement that could confirm a problem. As there are no valid legal arguments _against_ the situation in cdrtoools, there is obviously no way to discuss things and we need to rate the claims against cdrtools as libel. I even tried to discuss the social problem with some people from redhat but I was only given FUD instead of arguments. In return, I repeatedly asked for legal arguments that could be discussed, to no avail. So redhat also proves the same and it is obvious that there are no valid legal arguments that could confirm a problem with the original softare. Note that the GPL was designed to be compatible with all independently developed libraries under any license. This is a decision that was made in the late 1980s and I know the background of this diiscussion as I did take part in it. The GPL would have been completely unuaable if it was not made legally compatible with any independent library under any license. Even Eben Moglen confirmed that there is absolutely no problem with letting GPLd programs use CDDLs libs as this is of course no more then "mere aggregation", and permitted by the GPL. On the other side, there is Sun. Sun is the biggest Donator of OSS and Sun definitely runs a legal review on _every_ piece of OSS that is going to make it into Sun's Solaris distribution. This is needed because Sun also is the biggest target for atacks and legal cases and Sun for this reason is extremely careful with distributing OSS. I can confirm that Sun lawyers are also very effective with detecting legal problems as they did themself find that "libcdio" creates a legal problem in GNOME. Sun immediately stopped shipping "libcdio" and we did create a replacement library that calls "cdda2wav" in order to avoid legal problems and in order to give better audio results. Sun did make a legal review on cdrtools im May 2006 already, but in order to be very sure, I asked Sun legal to repeat the legal review on cdrtools last autumn. After doing the review, Sun legal confirmed again that there is no problem with the original software. It seems that the people who claim legal problems do not like to get into a discussion as with a fact based discussion, it would be easy to prove that they are wrong. As we have trustworthy confirmations from several sides, I propose to asume that there is no legal problem dist distributing cdrtools as long as nobody gives valid legal arguments. Note that Suse already ships cdrtools again and that even J?rg Jaspert, the FTP master from Debian in a legally binding way agreed on distributing the original cdrtools again for Debian as soon as possible. See also: http://cdrecord.berlios.de/private/linux-dist.html#Sun It would be interesting to hear _arguments_ from redhat on why redhat still only ships a broken fork with legal problems instead of the working original software that has no known legal problems.... J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From mcepl at redhat.com Tue Nov 3 10:37:50 2009 From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=) Date: Tue, 03 Nov 2009 11:37:50 +0100 Subject: Wodim trouble In-Reply-To: <1257222121.15471.2.camel@localhost> References: <4aef6970.BiXJGthIdAQejisR%Joerg.Schilling@fokus.fraunhofer.de> <1257207453.23167.8.camel@localhost.localdomain> <4aef7775.RphyRpRUFprHix4z%Joerg.Schilling@fokus.fraunhofer.de> <1257213960.23167.10.camel@localhost.localdomain> <1257222121.15471.2.camel@localhost> Message-ID: Dne 3.11.2009 05:22, Ankur Sinha napsal(a): > I just wanted to know if wodim is usable (i mean without wasting dvds > like its doing currently for me). From the discussion, I feel it's still > buggy and therefore I'm going to shift to another program (maybe > growisofs). Yes, wodim is perfect. Joerg is just spreading FUD. Mat?j -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Always make new mistakes -- Esther Dyson From mschwendt at gmail.com Tue Nov 3 10:55:31 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 3 Nov 2009 11:55:31 +0100 Subject: FESCo meeting summary for 20091030 In-Reply-To: References: Message-ID: <20091103115531.44dc3b99@faldor.intranet> On Mon, 2 Nov 2009 23:08:53 -0500, Jon wrote: > * fluidsynth and PA (jds2001, 17:04:44) > * LINK: http://markmail.org/message/bovdqb7na3zor2ck - without > comment. (mjg59, 17:17:07) > * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=500087#c13 > (jds2001, 17:19:22) > * AGREED: PA backend for fluidsynth must be built. If the current > maintainer refuses, Kevin_Kofler will take over as maintainer. > (jds2001, 17:32:01) 17:18:45 the package is a leafnode 17:18:47 NOTHING requires 17:18:48 it Not true. See: repoquery --whatrequires fluidsynth-libs --alldeps Building with PA support would add a dependency also to the backend library package, not just to the console ui. -- Btw, note that it could be built also with additional PortAudio support. ;?) From belegdol at gmail.com Tue Nov 3 10:58:06 2009 From: belegdol at gmail.com (Julian Sikorski) Date: Tue, 03 Nov 2009 11:58:06 +0100 Subject: Wodim trouble In-Reply-To: References: <4aef6970.BiXJGthIdAQejisR%Joerg.Schilling@fokus.fraunhofer.de> <1257207453.23167.8.camel@localhost.localdomain> <4aef7775.RphyRpRUFprHix4z%Joerg.Schilling@fokus.fraunhofer.de> <1257213960.23167.10.camel@localhost.localdomain> <1257222121.15471.2.camel@localhost> Message-ID: W dniu 03.11.2009 11:37, Mat?j Cepl pisze: > Dne 3.11.2009 05:22, Ankur Sinha napsal(a): >> I just wanted to know if wodim is usable (i mean without wasting dvds >> like its doing currently for me). From the discussion, I feel it's still >> buggy and therefore I'm going to shift to another program (maybe >> growisofs). > > Yes, wodim is perfect. Joerg is just spreading FUD. > > Mat?j > Ok, putting the ad personam arguments aside, there are two important facts: - cdrecord is still under active development, but there might be a problem with distributability (Sun lawyers say there is not, but I guess RH would like to make their own legal review to be on the safe side) - cdrkit is in sort of maintenance mode, and it does not support UDF filesystem for DVD discs correctly, and the situation is unlikely to improve - libburn is also developed actively, but it lacks UDF support as well [1] So, while waiting for libburn to improve, we could either take over cdrkit development, or do a(nother) legal review of cdrecord. It seems that the latter should be simpler, given that it's a one-time effort. Julian [1] http://libburnia-project.org/ticket/106 From giallu at gmail.com Tue Nov 3 11:15:33 2009 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 3 Nov 2009 12:15:33 +0100 Subject: Wodim trouble In-Reply-To: References: <4aef6970.BiXJGthIdAQejisR%Joerg.Schilling@fokus.fraunhofer.de> <1257207453.23167.8.camel@localhost.localdomain> <4aef7775.RphyRpRUFprHix4z%Joerg.Schilling@fokus.fraunhofer.de> <1257213960.23167.10.camel@localhost.localdomain> <1257222121.15471.2.camel@localhost> Message-ID: On Tue, Nov 3, 2009 at 11:58 AM, Julian Sikorski wrote: > So, while waiting for libburn to improve, we could either take over > cdrkit development, or do a(nother) legal review of cdrecord. It seems > that the latter should be simpler, given that it's a one-time effort. > Already done around June: http://thread.gmane.org/gmane.linux.redhat.fedora.legal/473 -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna From kevin.kofler at chello.at Tue Nov 3 11:17:00 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 03 Nov 2009 12:17 +0100 Subject: Wodim trouble References: <1257157747.2767.2.camel@localhost> <4AEF13ED.60001@redhat.com> <1257185899.7251.212.camel@atropine.boston.devel.redhat.com> <4AEF4573.7090407@poolshark.org> <4AEF6919.8060506@redhat.com> <4af002d7.jgo4mm+gG17Y0pTi%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: Joerg Schilling wrote: > There are some people who claim that there is a legal problem with the > original software but none of the persons who spread this claim (including > people from redhat) did ever make a valid legal statement that could > confirm a problem. As there are no valid legal arguments _against_ the > situation in cdrtoools, there is obviously no way to discuss things and we > need to rate the claims against cdrtools as libel. They are making a very concrete claim: if one piece of some program is under the GPL, the ENTIRE program, including all its libraries, MUST be under the GPL or a compatible license. This is confirmed e.g. by the FSF: http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean http://www.gnu.org/licenses/gpl-faq.html#MereAggregation http://www.gnu.org/licenses/gpl-faq.html#GPLModuleLicense http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs > I even tried to discuss the social problem with some people from redhat > but I was only given FUD instead of arguments. In return, I repeatedly > asked for legal arguments that could be discussed, to no avail. So redhat > also proves the same and it is obvious that there are no valid legal > arguments that could confirm a problem with the original softare. That's just false. You refused to take legal arguments from Fedora's legal contact (who is responsible for communication between RH Legal and the Fedora community) on the grounds that he's not a lawyer and demanded to speak directly to the lawyers. You ignored all the arguments he brought up, no matter how valid. > Note that the GPL was designed to be compatible with all independently > developed libraries under any license. This is a decision that was made in > the late 1980s and I know the background of this diiscussion as I did take > part in it. The GPL would have been completely unuaable if it was not made > legally compatible with any independent library under any license. Then I have a breaking news for you: the GPL *is* "completely unusable". Nevermind all those projects who can use it just fine while honoring these terms you refuse to accept. :-/ > Even Eben Moglen confirmed that there is absolutely no problem with > letting GPLd programs use CDDLs libs as this is of course no more then > "mere aggregation", and permitted by the GPL. You are misrepresenting Eben Moglen's position. The FSF's GPL FAQ, which he helped write, clearly says "If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program." So this is not "mere aggregation". > Sun did make a legal review on cdrtools im May 2006 already, but in order > to be very sure, I asked Sun legal to repeat the legal review on cdrtools > last autumn. After doing the review, Sun legal confirmed again that there > is no problem with the original software. Red Hat, like pretty much any other company, cannot trust other companies' legal departments. The relevant opinion is going to be Red Hat Legal's, sorry. (And FWIW, I have no idea why Sun is coming to that conclusion which directly contradicts the FSF's opinion, see the GPL FAQ.) > It seems that the people who claim legal problems do not like to get into > a discussion as with a fact based discussion, it would be easy to prove > that they are wrong. It is you who boycotted the fact-based discussion on ad hominem grounds (i.e. "you're not a lawyer, I won't listen to you", nevermind that you aren't one either). Kevin Kofler From Joerg.Schilling at fokus.fraunhofer.de Tue Nov 3 11:58:51 2009 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 03 Nov 2009 12:58:51 +0100 Subject: Wodim trouble In-Reply-To: <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> Message-ID: <4af01afb.Y3y/4AG0wa3tSTSL%Joerg.Schilling@fokus.fraunhofer.de> King InuYasha wrote: > The only thing I can figure out from this conversation is that the CDDL is > supposed to be incompatible with the GPL. If that's the case, why not simply > ask the original creator to kindly dual license it? First, it is definitely wrong that the CDDL was made incompatible with the GPL. The person who brouhgt this claim into public is a former Sun Employee who was disappointed that the restrictions in the GPL made the GPL impossible for use with OpenSolaris. In fact, the GPL is incompatible to nearly all licenses around and this is definitely an intended "feature" from the authors of the GPL. For our discussion, it is important to know whether a possible _general_ incompatibility between two licenses could affect a _special_ situation in a collective work, so let us have a look at the GPL: The GPL forbids to mix GPL and non-GPL within _one_ _single_ work and the GPL forbids to create a derived work from a GPLd work if the derived work is not put under GPL. Let us look at the "work" mkisofs. This work is a _pure_ GPLd work. It does not mix GPL and non-GPL code in a single work. With mkisofs, there is also no "derived work" that has to be taken into account. The fact that mkisofs links against CDDLd libs does not create a derived work but ist only a permitted collective work. For a more detailed review, please have a look at this book from Lawrence Rosen: http://www.rosenlaw.com/Rosen_Ch06.pdf who is an independent lawyer who counsels the OpenSource initiative. The relevent parts for the mkisofs case are on page 128. People wo claim that mkisofs has a problem usually missinterpret GPL section 3, the paragraph that is past 3 c): This special exception was introduced because the GPL precursor did contain an illegal claim that forced distributors of binaries from GPLd programs to distribute the source of the GPLd program _plus_ the libc from the Operating System the binary was compiled for. As this is a claim that is in conflict with the permissions that have been given with the OS license, the GPL tried to enforce something that was impossible. In the late 1980s, the so called OS library exception was added in order to prevent distributors of binaries to be forced to do illegal things. This section is obviously absolutely not related to any special license compatibility grant. It just allows to avoid being forced to ship libc. The conclusion of all lawyers I did talk to, is that there is no legal problem with original source. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From ndbecker2 at gmail.com Tue Nov 3 12:23:03 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 03 Nov 2009 07:23:03 -0500 Subject: texlive-2009 man & info Message-ID: I'm trying texlive-2009 packages for f11. I see man and info pages get installed (not in standard system locations, but into texlive tree), but man and info search paths don't seem to be setup to find them. From Joerg.Schilling at fokus.fraunhofer.de Tue Nov 3 12:28:17 2009 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 03 Nov 2009 13:28:17 +0100 Subject: Wodim trouble In-Reply-To: <3668e9f50911030048k5e2aa5c8lef3b38d5f92c6a50@mail.gmail.com> References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> <200911030026.39420.cemeyer@u.washington.edu> <3668e9f50911030048k5e2aa5c8lef3b38d5f92c6a50@mail.gmail.com> Message-ID: <4af021e1.x8Q1QbpuH3XxN9y8%Joerg.Schilling@fokus.fraunhofer.de> Josephine Tannh?user wrote: > 2009/11/3 Conrad Meyer > > > In this case, upstream (wodim) is a fork of Joerg Schilling's project. > > Wodim > > was forked from cdrecord because Joerg is crazy. Joerg likes to call wodim > > "the broken fork" and cdrecord "the original software". > > > He visited all the booths of linux distributions at "Chemnitzer Linux Tage" > and started some trouble. It seems that you have not been there..... I have a good relationship to Linux developers and projects and I did have nice conversations with many people in Chemnitz. Note that there was even a very good relationship with Debian _before_ Eduard Bloch became packetizer for cdrtools and started his attacks. It is obvious that the problems we are still wasting out time with is just one hostile person called Eduard Bloch. I hope that the OSS community finds a way to workaround the problems he created. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From SteveD at redhat.com Tue Nov 3 12:47:15 2009 From: SteveD at redhat.com (Steve Dickson) Date: Tue, 03 Nov 2009 07:47:15 -0500 Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to happen In-Reply-To: <1257192137.2268.87.camel@localhost.localdomain> References: <4AE5B378.1000507@RedHat.com> <4AE89491.4030303@RedHat.com> <20091028190514.B7E231D3@magilla.sf.frob.com> <4AE9B222.2060905@RedHat.com> <4AEEFD95.60701@redhat.com> <4AEF31BC.80205@RedHat.com> <1257192137.2268.87.camel@localhost.localdomain> Message-ID: <4AF02653.1020509@RedHat.com> On 11/02/2009 03:02 PM, Jesse Keating wrote: > On Mon, 2009-11-02 at 14:23 -0500, Steve Dickson wrote: >> I'm not sure about this... Actually I like the fact we can define a >> pseudo root other than '/'... which means you really want a live exported >> directory with the fsid=0 option... If I am understanding what you are >> saying... > > No, that's not what he's saying. Even if you define a different psuedo > root other than /, it's likely more common to /not/ want that root > exported in whole, but rather smaller parts of it, just like you don't > want / exported in whole, you only want subdirectories exported. Lets add some context to this since I *really* do want to understand what you guys are saying... /export *(ro,fsid=0) /export/home *(rw) With the above exports the only part of the server's real root ('/') that is exposed is the /export directory. So when a client does a 'mount -o v4 server:/ /mnt' The client will only be able to see /mnt/home (or the /export/home export). So as far as exposure, being able to define the root the client will see, I think, is good thing since it will protect (or hide) the rest of server's real root directories... So this is why I'm understanding why the '/export' of the '/export *(ro,fsid=0)' should not be a live export directory? steved. From josephine.tannhauser at googlemail.com Tue Nov 3 12:47:51 2009 From: josephine.tannhauser at googlemail.com (=?UTF-8?Q?Josephine_Tannh=C3=A4user?=) Date: Tue, 3 Nov 2009 13:47:51 +0100 Subject: Wodim trouble In-Reply-To: <4af021e1.x8Q1QbpuH3XxN9y8%Joerg.Schilling@fokus.fraunhofer.de> References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> <200911030026.39420.cemeyer@u.washington.edu> <3668e9f50911030048k5e2aa5c8lef3b38d5f92c6a50@mail.gmail.com> <4af021e1.x8Q1QbpuH3XxN9y8%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <3668e9f50911030447r13b647b7yf54b0b6ecb6a993b@mail.gmail.com> 2009/11/3, Joerg Schilling : > Josephine Tannh?user wrote: > It seems that you have not been there..... I was there and I was shocked about your behavior. -- Josephine "Fine" Tannh?user 2.6.29.6-213.fc11.i586 From Joerg.Schilling at fokus.fraunhofer.de Tue Nov 3 12:48:56 2009 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 03 Nov 2009 13:48:56 +0100 Subject: Wodim trouble In-Reply-To: References: <4aef6970.BiXJGthIdAQejisR%Joerg.Schilling@fokus.fraunhofer.de> <1257207453.23167.8.camel@localhost.localdomain> <4aef7775.RphyRpRUFprHix4z%Joerg.Schilling@fokus.fraunhofer.de> <1257213960.23167.10.camel@localhost.localdomain> <1257222121.15471.2.camel@localhost> Message-ID: <4af026b8.cvQv6ryQ7WLVJkhZ%Joerg.Schilling@fokus.fraunhofer.de> Mat??j Cepl wrote: > Dne 3.11.2009 05:22, Ankur Sinha napsal(a): > > I just wanted to know if wodim is usable (i mean without wasting dvds > > like its doing currently for me). From the discussion, I feel it's still > > buggy and therefore I'm going to shift to another program (maybe > > growisofs). > > Yes, wodim is perfect. Joerg is just spreading FUD. And Earth is a disk..... J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From rjones at redhat.com Tue Nov 3 12:56:06 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 3 Nov 2009 12:56:06 +0000 Subject: Including windows-binary files for cross compiling into package In-Reply-To: <1256582576.23821.193.camel@wsjoost.cnoc.lan> References: <1256579896.23821.186.camel@wsjoost.cnoc.lan> <20091026181502.919B02747@magilla.sf.frob.com> <1256582576.23821.193.camel@wsjoost.cnoc.lan> Message-ID: <20091103125606.GA15146@amd.home.annexia.org> On Mon, Oct 26, 2009 at 07:42:56PM +0100, Joost van der Sluis wrote: > On Mon, 2009-10-26 at 11:15 -0700, Roland McGrath wrote: > > If it's true cross support, then that should be a noarch package and the > > file names it uses should not depend on %{_lib} that way. > > Arguably it even belongs in %{_sharedir}, since it is fixed binary content > > across all host machines. > > Those files are not architecture independent. They are somewhat similar > to .o files. They contain the run time library for the language, > compiled to native windows object files. If you want to compile your own > program with them afterwards, they are linked together into a windows > executable. > > You could argue that they should belong in a -devel package. But since > this package is a compiler, we decided not to split it up into a devel > package and a non-devel package. As that would be pointless, as one will > not work without the other. Sorry, I'm late on this one. Yes the files *are* arch independent from the point of view of the host, so they should be noarch. The real problem is that RPM and the rest of the toolchain doesn't understand the cross-compilation situation at all. Anyway you may find the Fedora MinGW packaging guidelines to be helpful, and it would be useful to make your package compatible with the other ones, even if that deviates from upstream a little bit. http://fedoraproject.org/wiki/Packaging/MinGW http://fedoraproject.org/wiki/MinGW http://fedoraproject.org/wiki/MinGW/Packaging_issues We've also packaged some things, such as the OCaml cross-compiler, which sound very similar to the Pascal case you describe. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 Joerg.Schilling at fokus.fraunhofer.de Tue Nov 3 12:56:52 2009 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 03 Nov 2009 13:56:52 +0100 Subject: Wodim trouble In-Reply-To: References: <4aef6970.BiXJGthIdAQejisR%Joerg.Schilling@fokus.fraunhofer.de> <1257207453.23167.8.camel@localhost.localdomain> <4aef7775.RphyRpRUFprHix4z%Joerg.Schilling@fokus.fraunhofer.de> <1257213960.23167.10.camel@localhost.localdomain> <1257222121.15471.2.camel@localhost> Message-ID: <4af02894.ar/x+ZTFXlXRCXO8%Joerg.Schilling@fokus.fraunhofer.de> Julian Sikorski wrote: > Ok, putting the ad personam arguments aside, there are two important facts: > - cdrecord is still under active development, but there might be a > problem with distributability (Sun lawyers say there is not, but I guess There is no problem with distributibility as Sun would risk being sued if there legal department was wrong. I still do not understand why Companies like Redhat do not siply ask their lawyers for legal assistence. If they did, they would have better advise about cdrtools. > RH would like to make their own legal review to be on the safe side) > - cdrkit is in sort of maintenance mode, and it does not support UDF > filesystem for DVD discs correctly, and the situation is unlikely to improve Cdrkit is unmaitained and has legal problems. Companies who distribute cdrkit ignore the legal problems and need to be aware of legal consequences. > - libburn is also developed actively, but it lacks UDF support as well [1] > So, while waiting for libburn to improve, we could either take over > cdrkit development, or do a(nother) legal review of cdrecord. It seems > that the latter should be simpler, given that it's a one-time effort. Libburn is based on a wrong asumption: libburn only works partly on Linux in non-root mode and the vast majority of other OS needs root permissions to burn. Creating a burn library (well it is non-portable) based on these constraints will result in GUI applications that are non-portable and would require root permissions on most platforms. Installing a GUI suid root is an absolute no-go as GUIs are so compley that it is hard to audit the code for security problems. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling at fokus.fraunhofer.de Tue Nov 3 12:58:56 2009 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 03 Nov 2009 13:58:56 +0100 Subject: Wodim trouble In-Reply-To: References: <1257157747.2767.2.camel@localhost> <4AEF13ED.60001@redhat.com> <1257185899.7251.212.camel@atropine.boston.devel.redhat.com> <4AEF4573.7090407@poolshark.org> <4AEF6919.8060506@redhat.com> <4af002d7.jgo4mm+gG17Y0pTi%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <4af02910.cQB66iwtw/XoH4r0%Joerg.Schilling@fokus.fraunhofer.de> Kevin Kofler wrote: > Joerg Schilling wrote: > > There are some people who claim that there is a legal problem with the > > original software but none of the persons who spread this claim (including > > people from redhat) did ever make a valid legal statement that could > > confirm a problem. As there are no valid legal arguments _against_ the > > situation in cdrtoools, there is obviously no way to discuss things and we > > need to rate the claims against cdrtools as libel. > > They are making a very concrete claim: if one piece of some program is under > the GPL, the ENTIRE program, including all its libraries, MUST be under the > GPL or a compatible license. This is confirmed e.g. by the FSF: > http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean > http://www.gnu.org/licenses/gpl-faq.html#MereAggregation > http://www.gnu.org/licenses/gpl-faq.html#GPLModuleLicense > http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs You seem to miss that the license mkisofs is using is called "GPL" and not "GPL FAQ", so the quoting you mention do not apply. The GPL requires the entire work to be under GPL and the "entire work mkisofs" _is_ of course under GPL. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From hughsient at gmail.com Tue Nov 3 13:06:59 2009 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 3 Nov 2009 13:06:59 +0000 Subject: Wodim trouble In-Reply-To: <4af02894.ar/x+ZTFXlXRCXO8%Joerg.Schilling@fokus.fraunhofer.de> References: <4aef6970.BiXJGthIdAQejisR%Joerg.Schilling@fokus.fraunhofer.de> <1257207453.23167.8.camel@localhost.localdomain> <4aef7775.RphyRpRUFprHix4z%Joerg.Schilling@fokus.fraunhofer.de> <1257213960.23167.10.camel@localhost.localdomain> <1257222121.15471.2.camel@localhost> <4af02894.ar/x+ZTFXlXRCXO8%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <15e53e180911030506l59de3163x268597513af797d3@mail.gmail.com> 2009/11/3 Joerg Schilling : > if there legal department was wrong. I still do not understand why Companies > like Redhat do not siply ask their lawyers for legal assistence. If they did, > they would have better advise about cdrtools. Just a small thing that drives me crazy. The company name is "Red Hat" not Redhat. People don't write your name Joergschilling, do they? Thanks. Richard. From Joerg.Schilling at fokus.fraunhofer.de Tue Nov 3 13:08:55 2009 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 03 Nov 2009 14:08:55 +0100 Subject: Wodim trouble In-Reply-To: <3668e9f50911030447r13b647b7yf54b0b6ecb6a993b@mail.gmail.com> References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> <200911030026.39420.cemeyer@u.washington.edu> <3668e9f50911030048k5e2aa5c8lef3b38d5f92c6a50@mail.gmail.com> <4af021e1.x8Q1QbpuH3XxN9y8%Joerg.Schilling@fokus.fraunhofer.de> <3668e9f50911030447r13b647b7yf54b0b6ecb6a993b@mail.gmail.com> Message-ID: <4af02b67.PLMgiSqdDVNu5ZQe%Joerg.Schilling@fokus.fraunhofer.de> Josephine Tannh?user wrote: > 2009/11/3, Joerg Schilling : > > Josephine Tannh?user wrote: > > It seems that you have not been there..... > I was there and I was shocked about your behavior. Fortunately, you are of limited relevance and other people did not behave hostile but friendly ;-) J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From rawhide at fedoraproject.org Tue Nov 3 13:37:31 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Tue, 3 Nov 2009 13:37:31 +0000 Subject: rawhide report: 20091103 changes Message-ID: <20091103133731.GA28591@releng2.fedora.phx.redhat.com> Compose started at Tue Nov 3 06:15:13 UTC 2009 New package calibre E-book converter and library management New package intrace Traceroute-like application for network reconnaisance New package perl-Makefile-Parser Simple parser for Makefiles New package python-tornado Scalable, non-blocking web server and tools New package rubygem-abstract Allows you to define an abstract method in Ruby Removed package DeviceKit Removed package sublib Updated Packages: CGAL-3.5-1.fc12 --------------- * Sun Oct 18 2009 - 3.5-1 - New upstream release: finale version of CGAL-3.5. DeviceKit-disks-009-1.fc12 -------------------------- * Mon Nov 02 2009 David Zeuthen - 009-1.fc12 - Update to release 009 (bugfixes, #528874) PackageKit-0.5.4-0.1.20091029git.fc12 ------------------------------------- * Thu Oct 29 2009 Richard Hughes - 0.5.4-0.1.20091029git - Update to a newer git snapshot from the 0.5.x series. - Check the language code exists before we search for it. - Add the missing InstallSignature role from the backend auto-detection. - Disable repos that are not contactable at backend start. - Don't allow double clicking SRPM and fix the cryptic message. - Fixes #529349, #531105, #530945, #531306 and #530264 PyQwt-5.2.0-2.fc12 ------------------ * Wed Oct 28 2009 Tadej Jane? 5.2.0-2 - made qplt.py executable (to fix a rpmlint error) - removed html/.buildinfo from sphinx documentation (to fix a rpmlint error) - changed BuildRequires from numpy to numpy-f2py to cope with the numpy package split - temporarily removed qwt.py* files which conflict with the ones provided by the PyQt4 package anaconda-12.42-1.fc12 --------------------- * Fri Oct 30 2009 Chris Lumens - 12.42-1 - Use the new anaconda image in fedora-logos (#529267). (jkeating) - Also mark the Back button as translatable (#526925). (clumens) - Call udev_trigger with "change", not "add", to populate udev db. (#531052) (dlehman) - Allow callers of udev_trigger to specify the action string. (dlehman) - Add the bcm5974 kernel module needed for some touchpads (#474225). (clumens) - Fix "resize failed: 1" errors for ext2/ext3/ext4 (#517491). (dcantrell) - Put the icon back on the Back button on livecd installs (#526925). (clumens) - Use /dev/mapper/live-osimg-min instead of the old device node name (#526789). (clumens) asterisk-sounds-core-1.4.16-2.fc12 ---------------------------------- * Mon Nov 02 2009 Jeffrey C. Ollie - 1.4.16-2 - Remove fr/1.g729 as it's triggering an error in magic_file(3) (BZ#532489) * Mon Oct 05 2009 Jeffrey C. Ollie - 1.4.16-1 - Update to 1.4.16. at-spi-1.28.1-1.fc12 -------------------- * Mon Oct 19 2009 Matthias Clasen - 1.28.1-1 - Update to 1.28.1 bluez-4.57-2.fc12 ----------------- * Mon Nov 02 2009 Bastien Nocera 4.57-2 - Move the rfcomm.conf to the compat package, otherwise the comments at the top of it are confusing * Sun Nov 01 2009 Bastien Nocera 4.57-1 - Update to 4.57 brltty-4.1-3.fc12 ----------------- * Sun Nov 01 2009 Stepan Kasal - 4.1-3 - build the TTY driver (it was disabled since it first appered in 3.7.2-1) - build with speech-dispatcher, packed into a separate sub-package * Fri Oct 30 2009 Stepan Kasal - 4.1-2 - move data-directory back to default: /etc/brltty - move brltty to /bin and /lib, so that it can be used to repair the system without /usr mounted (#276181) - move vstp and libbrlttybba.so to brlapi - brltty no longer requires brlapi - brlapi now requires brltty from the same build celt-0.7.0-1.fc12 ----------------- * Fri Oct 30 2009 Peter Robinson 0.7.0-1 - New 0.7.0 upstream release cernlib-2006-34.fc12 -------------------- * Thu Oct 01 2009 Hans de Goede 2006-34 - Fix FTBFS * Fri Jul 24 2009 Fedora Release Engineering - 2006-33 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild dalston-0.1.11-1.fc12 --------------------- * Thu Oct 29 2009 Peter Robinson 0.1.11-1 - new upstream 0.1.11 release desktop-backgrounds-9.0.0-11 ---------------------------- * Tue Nov 03 2009 Christoph Wickert - 9.0.0-11 - Bump release for RC * Sun Nov 01 2009 Christoph Wickert - 9.0.0-10 - Update for F12 constantine artwork eclipse-3.5.1-4.fc12 -------------------- * Fri Oct 30 2009 Andrew Overholt 1:3.5.1-4 - Make /usr/bin/eclipse a wrapper script due to rhbz#531675 (e.o#290395). * Wed Oct 28 2009 Alexander Kurtakov 1:3.5.1-2 - Don't install 2 desktop files. (rhbz #530450) eclipse-photran-5.0.0-0.2.200910081739.fc12 ------------------------------------------- * Fri Oct 30 2009 Orion Poplawski - 5.0.0-0.2.200910081739 - Cleanup spec headers - Drop gcj support - Add needed Requires epiphany-extensions-2.28.1-2.fc12 --------------------------------- * Sun Nov 01 2009 Matthias Clasen - 2.28.1-2 - Don't require epiphany-devel (#529624) gbirthday-0.5.2-3.fc12 ---------------------- * Fri Oct 30 2009 Thomas Spura 0.5.2-1 - New Release * Fri Oct 30 2009 Thomas Spura 0.5.2-2 - little problem with 'make tag' * Fri Oct 30 2009 Thomas Spura 0.5.2-3 - missing BR intltool gdm-2.28.1-20.fc12 ------------------ * Sat Oct 31 2009 Matthias Clasen 2.28.1-18 - Actually set up statusicon padding * Sat Oct 31 2009 Matthias Clasen 2.28.1-20 - Don't show 'Lock Screen' in the user switcher if locked down * Fri Oct 30 2009 Ray Strode 2.28.1-17 - Make the user list slide animation smoother * Thu Oct 29 2009 Ray Strode 2.28.1-15 - Don't show fingerprint task button unless fingerprint is enabled - Don't show smartcard task button and list item unless pcscd is running. * Thu Oct 29 2009 Ray Strode 2.28.1-16 - Shrink autologin timer - Make language dialog not double spaced * Wed Oct 28 2009 Ray Strode 2.28.1-13 - Fix double free during user switching (might address bug 512944) * Wed Oct 28 2009 Ray Strode 2.28.1-14 - Don't show image on login button geany-plugins-0.18-1.fc12 ------------------------- * Sat Oct 31 2009 Dominic Hopf 0.18-1 - update to new upstream release generic-logos-12.2-1.fc12 ------------------------- * Fri Oct 30 2009 Tom "spot" Callaway - 12.1-1 - 12.1 (add generic versions of anaconda.png/svg) * Fri Oct 30 2009 Bill Nottingham - 12.2-1 - tweak anaconda.png/svg to match rest of icons () git-1.6.5.2-1.fc12 ------------------ * Mon Oct 26 2009 Todd Zullinger - 1.6.5.2-1 - git-1.6.5.2 - Drop asciidoc --unsafe option, it should not be needed anymore - Don't use install -t/-T, they're not compatible with older coreutils - Don't use -perm /a+x with find, it's incompatible with older findutils gnome-disk-utility-2.28.1-1.fc12 -------------------------------- * Mon Nov 02 2009 David Zeuthen - 2.28.1-1.fc12 - Update to 2.28.1 gnome-globalmenu-0.7.8-1.fc12 ----------------------------- gnome-packagekit-2.28.2-0.1.20091030git.fc12 -------------------------------------------- * Fri Oct 30 2009 Richard Hughes - 2.28.2-0.1.20091030git - New snapshot from the gnome-2-28 branch - Have a better stab at #530264 * Thu Oct 29 2009 Richard Hughes - 2.28.2-0.1.20091029git - New snapshot from the gnome-2-28 branch - Many updated translations. - Fixes #529960 and #530595 gnome-panel-2.28.0-13.fc12 -------------------------- * Mon Nov 02 2009 Matthias Clasen 2.28.0-13 - Don't add padding before the first and after the last applet (#532410) gnome-screensaver-2.28.0-6.fc12 ------------------------------- * Mon Nov 02 2009 Matthias Clasen 2.28.0-6 - Clean up session inhibitors if the owner falls off the bus gnome-subtitles-0.9.1-1.fc12 ---------------------------- * Sun Nov 01 2009 Julian Sikorski - 0.9.1-1 - Updated to 0.9.1 - Dropped the SMP build patch - Added desktop-database scriptlets - Re-enabled parallel make - Updated the License tag - Added intltool to BuildRequires, removed explicit gettext gnome-user-share-2.28.1-2.fc12 ------------------------------ * Tue Nov 03 2009 Bastien Nocera 2.28.1-2 - Update share bar code to use the same directories as the sharing code itself gnome-utils-2.28.1-3.fc12 ------------------------- * Sun Oct 25 2009 Matthias Clasen - 1:2.28.1-3 - Fxi the --version command (#516491) gnutls-2.8.5-1.fc12 ------------------- * Mon Nov 02 2009 Tomas Mraz 2.8.5-1 - upgrade to a new upstream version gtk2-2.18.3-19.fc12 ------------------- * Mon Nov 02 2009 Marek Kasik - 2.18.3-17 - Remove handling of "connecting-to-device" reason (#529364) * Mon Nov 02 2009 Marek Kasik - 2.18.3-18 - Show correct print preview (gnome bug #592582) * Mon Nov 02 2009 Marek Kasik - 2.18.3-19 - Correct rotation of number-up layout when printing landscape * Sat Oct 31 2009 Matthias Clasen - 2.18.3-16 - Handle screen changes for tooltips (#531568) inkscape-0.47-0.17.pre4.20091101svn.fc12 ---------------------------------------- ipmitool-1.8.11-4.fc12 ---------------------- * Mon Nov 02 2009 Jan Safranek 1.8.11-4 - fix ipmievd initscript 'condrestart' action (#532188) iso-codes-3.11-1.fc12 --------------------- * Fri Oct 23 2009 Parag Nemade - 3.11-1 - Update to 3.11 kipi-plugins-0.8.0-1.fc12 ------------------------- * Mon Nov 02 2009 Rex Dieter 0.8.0-1 - kipi-plugins-0.8.0 kpackagekit-0.5.0.3-1.fc12 -------------------------- * Sat Oct 31 2009 Steven M. Parrish - 0.5.0.3-1 - Official 0.5.0.3 release kphotoalbum-4.1-1.fc12 ---------------------- * Sun Oct 25 2009 Rex Dieter 4.1-1 - kphotoalbum-4.1 leafpad-0.8.17-1.fc12 --------------------- * Sun Nov 01 2009 Christoph Wickert - 0.8.17-1 - Update to 0.8.17 - Drop unnecessary BuildRequires for libgnomeprintui22-devel - Update icon-cache scriptlets libvorbis-1.2.3-3.fc12 ---------------------- * Mon Nov 02 2009 Jindrich Novy 1.2.3-3 - backport patches to fix CVE-2009-3379 (#531765) from upstream libxfcegui4-4.6.1-3.fc12 ------------------------ * Mon Nov 02 2009 Christoph Wickert - 4.6.1-3 - Fix SEGV inside disconnect() helper (#532179) - Update gtk-icon-cache scriptlets log4net-1.2.10-9.fc12 --------------------- * Fri Oct 30 2009 Tom "spot" Callaway - 1.2.10-9 - rebuild again for nant mono-nunit22-2.2.10-12.fc12 --------------------------- * Fri Oct 30 2009 Tom "spot" Callaway - 1:2.2.10-12 - rebuild * Mon Oct 26 2009 Dennis Gilmore - 1:2.2.10-11 - ExcludeArch sparc64 no mono mono-sharpcvslib-0.35-13.fc12 ----------------------------- * Fri Oct 30 2009 Tom "spot" Callaway - 0.35-13 - rebuild nant-0.85-32.fc12 ----------------- * Fri Oct 30 2009 Tom "spot" Callaway - 1:0.85-31.1 - bootstrapping again * Fri Oct 30 2009 Tom "spot" Callaway - 1:0.85-32 - aaaand, unbootstrap * Thu Oct 29 2009 Kevin Kofler - 1:0.85-31 - rebuild because mono-ndoc "cleverly" encodes its build date into its ABI ver nautilus-actions-1.12.2-1.fc12 ------------------------------ * Sun Nov 01 2009 Matthias Clasen - 1.12.2-1 - Update to 1.12.2 - Makes nautilus-actions-config-tool start again nautilus-search-tool-0.3.0-5.fc12 --------------------------------- * Mon Nov 02 2009 Paul W. Frields - 0.3.0-4 - Cope with missing --version in gnome-search-tool (#516491) * Mon Nov 02 2009 Paul W. Frields - 0.3.0-5 - Drop patch in favor of gnome-utils-2.28.1-3 nbtk-1.1.12-1.fc12 ------------------ * Sun Nov 01 2009 Peter Robinson 1.1.12-1 - New upstream 1.1.12 release nfs-utils-1.2.0-18.fc12 ----------------------- * Mon Nov 02 2009 Steve Dickson 1.2.0-18 - Reworked and remove some of the Default-Start/Stop stanzas in the init scripts (bz 531425) openssh-5.2p1-31.fc12 --------------------- * Mon Nov 02 2009 Jan F. Chadima - 5.2p1-31 - Repair canohost patch to allow gssapi to work when host is acessed via pipe proxy (#531849) pam-1.1.0-7.fc12 ---------------- * Mon Nov 02 2009 Tomas Mraz 1.1.0-7 - pam_console: fix memory corruption when executing handlers (patch by Stas Sergeev) and a few more fixes in the handler execution code (#532302) pcmanfm-0.5.2-1.fc12 -------------------- * Fri Oct 30 2009 Christoph Wickert - 0.5.2-1 - Update tp 0.5.2 (fixes sourceforge bug 2883172) perl-Cache-Memcached-1.28-1.fc12 -------------------------------- * Mon Nov 02 2009 Stepan Kasal - 1.28-1 - new upstream version perl-HTML-Parser-3.64-1.fc12 ---------------------------- * Mon Nov 02 2009 Stepan Kasal - 3.64-1 - new upstream version perl-MIME-Lite-3.027-1.fc12 --------------------------- * Mon Nov 02 2009 Stepan Kasal - 3.027-1 - new upstream version perl-Text-CSV_XS-0.69-1.fc12 ---------------------------- * Mon Nov 02 2009 Stepan Kasal - 0.69 - new upstream release plymouth-0.8.0-0.2009.29.09.16.fc12 ----------------------------------- * Fri Oct 30 2009 Ray Strode 0.8.0-0.2009.29.09.16 - Drop debug spew that snuck in * Thu Oct 29 2009 Ray Strode 0.8.0-0.2009.29.09.14 - Don't unlink /dev/null (bug 531740) * Thu Oct 29 2009 Ray Strode 0.8.0-0.2009.29.09.15 - Fix plymouth over ppc hyperviser console (bug 531581) * Mon Oct 19 2009 Ray Strode 0.8.0-0.2009.29.09.13 - Drop nash dep (bug 528706) * Wed Oct 14 2009 Ray Strode 0.8.0-0.2009.29.09.12 - Don't clear screen in text plugin immediately after displaying password prompt (bug 527426) publican-1.0-0.fc12 ------------------- * Mon Oct 26 2009 Jeff Fearn 1.0-0 - Add base langauge summary & descriptions to translated spec file. BZ #515573 - Fix translated package build failure. - Change tabs to spaces in generated spec files. - Fix Locale::Maketext::Gettext dep being missed on RHEL. - Fix common paths on Windows - Added docbook-style-xsl dep for version 1.75.1+ - POD fix from Mikhail Gusarov - Added processing file message to update_pot. BZ #518354 - add EPUB stub - Clean up Copyright in numerous files. - Add security callback for exslt:document. - Update XML::LibXML & XML::LibXSLT minimum versions to 1.67 - Fix rounded corners in HTML. BZ #509768 - Fix nested images breakin in PDF. BZ #491782 - Remove border from HTML table for simplelist. BZ #502126 - Fix remarks not being highlighted in PDF. BZ #509307 - Resize shade.verbatim font size. BZ #497462 - Change step page size limitation to para size limitation. BZ#492984 - Add warning message for missing images. BZ #495821 - Fix fuzzy images. BZ #479794 - swap from paths from Publican to publican and obsolete beta packages. - Fix large example PDF issue. BZ #531685 publican-fedora-1.0-0.fc12 -------------------------- * Fri Oct 30 2009 Jeff Fearn 1.0 - port to publican 1.0. python-lxml-2.2.3-1.fc12 ------------------------ * Fri Oct 30 2009 Jeffrey C. Ollie - 2.2.3-1 - 2.2.3 (2009-10-30) - Bugs fixed - - * The resolve_entities option did not work in the incremental feed - parser. - * Looking up and deleting attributes without a namespace could hit a - namespaced attribute of the same name instead. - * Late errors during calls to SubElement() (e.g. attribute related - ones) could leave a partially initialised element in the tree. - * Modifying trees that contain parsed entity references could result - in an infinite loop. - * ObjectifiedElement.__setattr__ created an empty-string child element - when the attribute value was rejected as a non-unicode/non-ascii - string - * Syntax errors in lxml.cssselect could result in misleading error - messages. - * Invalid syntax in CSS expressions could lead to an infinite loop in - the parser of lxml.cssselect. - * CSS special character escapes were not properly handled in - lxml.cssselect. - * CSS Unicode escapes were not properly decoded in lxml.cssselect. - * Select options in HTML forms that had no explicit value attribute - were not handled correctly. The HTML standard dictates that their - value is defined by their text content. This is now supported by - lxml.html. - * XPath raised a TypeError when finding CDATA sections. This is now - fully supported. - * Calling help(lxml.objectify) didn't work at the prompt. - * The ElementMaker in lxml.objectify no longer defines the default - namespaces when annotation is disabled. - * Feed parser failed to honour the 'recover' option on parse errors. - * Diverting the error logging to Python's logging system was broken. qtcurve-gtk2-0.69.2-1.fc12 -------------------------- * Sun Nov 01 2009 Thomas Janssen 0.69.2-1 - New upstream source 0.69.2 qtcurve-kde4-0.69.2-1.fc12 -------------------------- * Sun Nov 01 2009 Thomas Janssen 0.69.2-1 - Updated to source 0.69.2 redhat-lsb-3.2-7.fc12 --------------------- * Tue Oct 27 2009 Tom "spot" Callaway - 3.2-7 - apply fix from bz514760 (thanks to Jakub Jelinek) ruby-RMagick-2.12.2-1.fc12 -------------------------- * Sat Oct 31 2009 Mamoru Tasaka - 2.12.2-1 - 2.12.2 ruby-gnome2-0.19.3-3.fc12 ------------------------- * Sun Nov 01 2009 Mamoru Tasaka - release++ selinux-policy-3.6.32-37.fc12 ----------------------------- * Fri Oct 30 2009 Dan Walsh 3.6.32-37 - Allow consolekit to manage /var/run/console directory - Allow pcsd to r/w smartcard devices - Temporarily allow xauth to read/write user_home_t - Allow apache to read nagios log files - Fix execmem to work correctly - Stop transitioning from unconfined_t to iceauth * Thu Oct 29 2009 Dan Walsh 3.6.32-36 - Change labeling of /usr/share/yumex/yumex-yum-backend - Allow initrc_t to request loading kernel modules - Allow initrc_t to manage net_conf_t files - Allow prelink to manage tmp files for "delta rpm" - Allow livecd tool to transition to chfn and passwd - Allow cupsd to bind to howl port - dontaudit leaked userdomain sockets to xauth - Allow lircd to use pseudo terminal device - Allow sambagui to send syslog messages - dontaudit chrome using nfs and samba file systems if they are used for the homedir - Allow prelude-dispatch ipc_lock and setpcap - Change lircd /var/run specification - Define ports for dhcpcv6 snake-0.11-0.19.fc12 -------------------- * Mon Oct 26 2009 James Laska 0.11-0.19 - Correct install.py typo, use subprocess.call to gather arguments (wwoods) supertuxkart-0.6.2-1.fc12 ------------------------- * Thu Sep 10 2009 Jon Ciesla - 0.6.2-1 - Bugfix release. tangogps-0.9.8-1.fc12 --------------------- * Sun Nov 01 2009 Peter Robinson 0.9.8-1 - New upstream 0.9.8 release texmaker-1.9.2-3.fc12 --------------------- * Mon Nov 02 2009 Deji Akingunola - 1.9.2-3 - Update with a more complete patch to use system hunspell (Caolan McNamara) valgrind-3.5.0-8 ---------------- * Wed Oct 28 2009 Jakub Jelinek 3.5.0-8 - add preadv/pwritev syscall support * Tue Oct 27 2009 Jakub Jelinek 3.5.0-7 - add perf_counter_open syscall support (#531271) - add handling of some sbb/adc insn forms on x86_64 (KDE#211410) vhostmd-0.4-0.6.gite9db007b.fc12 -------------------------------- * Mon Nov 02 2009 Richard W.M. Jones - 0.4-0.6.gite9db007b - Some changes to the default configuration file suggested by SAP to make it more CIM standards compliant. virtuoso-opensource-5.0.12-1.fc12 --------------------------------- * Tue Oct 20 2009 Rex Dieter 5.0.12-1 - virtuoso-opensource-5.0.12 * Sun Oct 11 2009 Rex Dieter 5.0.12-0.1.rc9.20090916 - virtuoso-opensource-20090916 (5.0.12-rc9) webkitgtk-1.1.15.3-1.fc12 ------------------------- * Sat Oct 31 2009 Matthias Clasen - 1.1.15.3-1 - Update to 1.1.15.3, more crash fixes and important media player fixes - See https://lists.webkit.org/pipermail/webkit-gtk/2009-October/000047.html xfce4-power-manager-0.8.4.1-1.fc12 ---------------------------------- * Mon Nov 02 2009 Christoph Wickert - 0.8.4.1-1 - Update to 0.8.4.1 xfdesktop-4.6.1-3.fc12 ---------------------- * Sun Nov 01 2009 Christoph Wickert - 4.6.1-3 - Fix dependency for default background image xorg-x11-server-1.7.0-5.fc12 ---------------------------- * Sat Oct 24 2009 Ben Skeggs 1.7.0-5 - Fix unbalancing of Prepare/FinishAccess in EXA mixed pixmaps (rh#528005) * Fri Oct 16 2009 Dave Airlie 1.7.0-4 - update GLX for 1.4 version reporting * Fri Oct 09 2009 Ben Skeggs 1.7.0-3 - xserver-1.7.0-exa-looping-forever-is-evil.patch: Fix rendercheck hang * Thu Oct 08 2009 Adam Jackson 1.7.0-2 - xserver-1.7.0-randr-gamma-restore.patch: Restore CRTC gamma on EnterVT. Summary: Added Packages: 5 Removed Packages: 2 Modified Packages: 76 From mcepl at redhat.com Tue Nov 3 14:13:12 2009 From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=) Date: Tue, 03 Nov 2009 15:13:12 +0100 Subject: Wodim trouble In-Reply-To: <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> Message-ID: Dne 3.11.2009 02:55, King InuYasha napsal(a): > The only thing I can figure out from this conversation is that the CDDL > is supposed to be incompatible with the GPL. If that's the case, why not > simply ask the original creator to kindly dual license it? You must be new here :) Concerning legal issues with cdrkit, please, take a look at http://thread.gmane.org/gmane.linux.redhat.fedora.legal/473 and of course \|||/ (o o) |~~~~ooO~~(_)~~~~~~~| | Please | | don't feed the | | TROLLS ! | '~~~~~~~~~~~~~~Ooo~~' |__|__| || || ooO Ooo -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Faithful love is what people look for in a person; ... -- Proverbs 19:22 (NJB) From schaiba at gmail.com Tue Nov 3 14:18:13 2009 From: schaiba at gmail.com (Aioanei Rares) Date: Tue, 03 Nov 2009 16:18:13 +0200 Subject: Wodim trouble In-Reply-To: <4af02b67.PLMgiSqdDVNu5ZQe%Joerg.Schilling@fokus.fraunhofer.de> References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> <200911030026.39420.cemeyer@u.washington.edu> <3668e9f50911030048k5e2aa5c8lef3b38d5f92c6a50@mail.gmail.com> <4af021e1.x8Q1QbpuH3XxN9y8%Joerg.Schilling@fokus.fraunhofer.de> <3668e9f50911030447r13b647b7yf54b0b6ecb6a993b@mail.gmail.com> <4af02b67.PLMgiSqdDVNu5ZQe%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <4AF03BA5.90204@gmail.com> On 11/03/2009 03:08 PM, Joerg Schilling wrote: > Josephine Tannh?user wrote: > > >> 2009/11/3, Joerg Schilling: >> >>> Josephine Tannh?user wrote: >>> It seems that you have not been there..... >>> >> I was there and I was shocked about your behavior. >> > Fortunately, you are of limited relevance and other people did not behave > hostile but friendly ;-) > > J?rg > > Yeah, good way to expect any collaboration with that attitude. Keep up the good work. From ajax at redhat.com Tue Nov 3 14:28:45 2009 From: ajax at redhat.com (Adam Jackson) Date: Tue, 03 Nov 2009 09:28:45 -0500 Subject: PPC not getting __WORDSIZE set In-Reply-To: <20091102223426.GW14664@tyan-ft48-01.lab.bos.redhat.com> References: <4AEF5A16.70604@redhat.com> <20091102223426.GW14664@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <1257258525.7251.291.camel@atropine.boston.devel.redhat.com> On Mon, 2009-11-02 at 23:34 +0100, Jakub Jelinek wrote: > On Mon, Nov 02, 2009 at 05:15:50PM -0500, Bryan Kearney wrote: > > Word of warning.. I am no too familiar with C across platforms. I am > > trying to package ruby-ffi (spec file is at [1]) and when I do a scratch > > build in Koji [2] it runs fine on x86 but is failing in ppc_64. It > > appears that __WORDSIZE is not being set [3]. I looked at the CFLags for > > the x86_64 and they are the same, so I assumed things would run fine. > > Can anyone point me at what to look at next? > > __WORDSIZE is a glibc internal macro, packages shouldn't be using it. > Whether it is defined or not depends on whether any of the headers that are > included needed to check that macro or not. > > You should be using __LP64__ or similar macros instead. atropine:~% : | cpp -dM | grep -c LP 0 What header defines __ILP32__ or __LP64__? Of course there's also: atropine:~% : | cpp -dM | grep SIZEOF #define __SIZEOF_INT__ 4 #define __SIZEOF_POINTER__ 4 #define __SIZEOF_LONG__ 4 #define __SIZEOF_LONG_DOUBLE__ 12 #define __SIZEOF_SIZE_T__ 4 #define __SIZEOF_WINT_T__ 4 #define __SIZEOF_PTRDIFF_T__ 4 #define __SIZEOF_FLOAT__ 4 #define __SIZEOF_SHORT__ 2 #define __SIZEOF_WCHAR_T__ 4 #define __SIZEOF_DOUBLE__ 8 #define __SIZEOF_LONG_LONG__ 8 - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jakub at redhat.com Tue Nov 3 14:34:33 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 3 Nov 2009 15:34:33 +0100 Subject: PPC not getting __WORDSIZE set In-Reply-To: <1257258525.7251.291.camel@atropine.boston.devel.redhat.com> References: <4AEF5A16.70604@redhat.com> <20091102223426.GW14664@tyan-ft48-01.lab.bos.redhat.com> <1257258525.7251.291.camel@atropine.boston.devel.redhat.com> Message-ID: <20091103143433.GA14664@tyan-ft48-01.lab.bos.redhat.com> On Tue, Nov 03, 2009 at 09:28:45AM -0500, Adam Jackson wrote: > What header defines __ILP32__ or __LP64__? Nothing defines __ILP32__, only __LP64__: $ gcc -m64 -E -dD -xc /dev/null | grep LP64 #define _LP64 1 #define __LP64__ 1 $ gcc -m32 -E -dD -xc /dev/null | grep LP64 Jakub From tcallawa at redhat.com Tue Nov 3 14:34:31 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 03 Nov 2009 09:34:31 -0500 Subject: Wodim trouble In-Reply-To: References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> Message-ID: <4AF03F77.6060705@redhat.com> On 11/03/2009 09:13 AM, Mat?j Cepl wrote: > Dne 3.11.2009 02:55, King InuYasha napsal(a): >> The only thing I can figure out from this conversation is that the CDDL >> is supposed to be incompatible with the GPL. If that's the case, why not >> simply ask the original creator to kindly dual license it? > > You must be new here :) > Concerning legal issues with cdrkit, please, take a look at > http://thread.gmane.org/gmane.linux.redhat.fedora.legal/473 > > and of course > > \|||/ > (o o) > |~~~~ooO~~(_)~~~~~~~| > | Please | > | don't feed the | > | TROLLS ! | > '~~~~~~~~~~~~~~Ooo~~' > |__|__| > || || > ooO Ooo Indeed. Specifically, the formal stance of the Fedora Project (and Red Hat Legal) is contained within my original reply to Mr. Schilling here: http://article.gmane.org/gmane.linux.redhat.fedora.legal/528 Since nothing has changed, please consider this thread closed. Continued postings will be handled under the moderation policies. Thanks, ~spot From josephine.tannhauser at googlemail.com Tue Nov 3 14:43:52 2009 From: josephine.tannhauser at googlemail.com (=?UTF-8?Q?Josephine_Tannh=C3=A4user?=) Date: Tue, 3 Nov 2009 15:43:52 +0100 Subject: Wodim trouble In-Reply-To: <4af02b67.PLMgiSqdDVNu5ZQe%Joerg.Schilling@fokus.fraunhofer.de> References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> <200911030026.39420.cemeyer@u.washington.edu> <3668e9f50911030048k5e2aa5c8lef3b38d5f92c6a50@mail.gmail.com> <4af021e1.x8Q1QbpuH3XxN9y8%Joerg.Schilling@fokus.fraunhofer.de> <3668e9f50911030447r13b647b7yf54b0b6ecb6a993b@mail.gmail.com> <4af02b67.PLMgiSqdDVNu5ZQe%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <3668e9f50911030643q3217990cs4562e037d3a2c284@mail.gmail.com> 2009/11/3, Joerg Schilling : > Fortunately, you are of limited relevance and other people did not behave > hostile but friendly ;-) Sorry Joerg, but Imho it isn't friendly to come to a booth, thump the table and say: "Remove illegal software from fedora distribution, mature at the end of the year, or I will sue you." This isn't a friendly way. The booth-personnel and the bystanders didn't know with this action WHO you are or WHAT do you really want.. btw it's imho a little bit duffy to come with this request to a booth on an event like "Chemnitzer Linux Tage". The quality of the content of your Messages sometimes extremly differs from your behavior, your way how you tell it. Perhaps it is me (as a woman) who is very sensitive in that case. Perhaps this is sometimes the reason that differs the pov of your counterpart "you have the point" from "you are a troll". Think about it, perhaps twice! -- Josephine "Fine" Tannh?user 2.6.29.6-213.fc11.i586 From Joerg.Schilling at fokus.fraunhofer.de Tue Nov 3 14:46:15 2009 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 03 Nov 2009 15:46:15 +0100 Subject: Wodim trouble In-Reply-To: <4AF03F77.6060705@redhat.com> References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> <4AF03F77.6060705@redhat.com> Message-ID: <4af04237.cEqJFoLH7rjBUoBJ%Joerg.Schilling@fokus.fraunhofer.de> "Tom \"spot\" Callaway" wrote: > Since nothing has changed, please consider this thread closed. Continued > postings will be handled under the moderation policies. So let us conclude: - Redhat continues to distribute "cdrkit" although there are known legal problems with it and Redhat has been informed more that once about this fact. - Redhat still does not like to distribute the legal original software. - Redhat still ignores the demands of the users that like to have usable software. Is this what redhat understands by "living OpenSource"? J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From cmadams at hiwaay.net Tue Nov 3 14:52:03 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 3 Nov 2009 08:52:03 -0600 Subject: Wodim trouble In-Reply-To: <4af04237.cEqJFoLH7rjBUoBJ%Joerg.Schilling@fokus.fraunhofer.de> References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> <4AF03F77.6060705@redhat.com> <4af04237.cEqJFoLH7rjBUoBJ%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <20091103145203.GB1386107@hiwaay.net> Once upon a time, Joerg Schilling said: > - Redhat continues to distribute "cdrkit" although there are > known legal problems with it and Redhat has been informed more that > once about this fact. it is "Red Hat", not "Redhat" (and this is Fedora). You have refused to cite specific legal problems with cdrkit, so there are no "known legal problems" that anyone can see. The proper reporting method is bugzilla.redhat.com; can you point to where you reported them? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From dledford at redhat.com Tue Nov 3 14:53:10 2009 From: dledford at redhat.com (Doug Ledford) Date: Tue, 03 Nov 2009 09:53:10 -0500 Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to happen In-Reply-To: <4AF02653.1020509@RedHat.com> References: <4AE5B378.1000507@RedHat.com> <4AE89491.4030303@RedHat.com> <20091028190514.B7E231D3@magilla.sf.frob.com> <4AE9B222.2060905@RedHat.com> <4AEEFD95.60701@redhat.com> <4AEF31BC.80205@RedHat.com> <1257192137.2268.87.camel@localhost.localdomain> <4AF02653.1020509@RedHat.com> Message-ID: <4AF043D6.9050204@redhat.com> On 11/03/2009 07:47 AM, Steve Dickson wrote: > On 11/02/2009 03:02 PM, Jesse Keating wrote: >> On Mon, 2009-11-02 at 14:23 -0500, Steve Dickson wrote: >>> I'm not sure about this... Actually I like the fact we can define a >>> pseudo root other than '/'... which means you really want a live exported >>> directory with the fsid=0 option... If I am understanding what you are >>> saying... >> >> No, that's not what he's saying. Even if you define a different psuedo >> root other than /, it's likely more common to /not/ want that root >> exported in whole, but rather smaller parts of it, just like you don't >> want / exported in whole, you only want subdirectories exported. > Lets add some context to this since I *really* do want to understand > what you guys are saying... > > /export *(ro,fsid=0) > /export/home *(rw) > > With the above exports the only part of the server's real root ('/') > that is exposed is the /export directory. So when a client does a > 'mount -o v4 server:/ /mnt' > > The client will only be able to see /mnt/home (or the /export/home > export). > > So as far as exposure, being able to define the root the client > will see, I think, is good thing since it will protect (or hide) > the rest of server's real root directories... > > So this is why I'm understanding why the '/export' of the > '/export *(ro,fsid=0)' should not be a live export directory? I understand that, what I'm saying is that the setting of the pseudo root and the setting of an export *NEED* to be two different things. In the past, any NFS export was always a real export and the only pseudo root was always the / filesystem, *BUT* just because the / filesystem was the pseudo root did *NOT* mean that the / filesystem itself was mountable by clients unless it was exported in a separate export line (get the distinction here: pseudo root existed, but wasn't exported). Now you are telling us to create a pseudo root entry in the exports file, and that entry is indicated by fsid=0, but you are also telling us that simply the act of setting that entry will then add *both* a pseudo root and a live export of the pseudo root to the world. There are many situations I can imagine where I need the pseudo root to be something I don't actually export, the most common and immediate case being that I serve both NFSv4 and NFSv{3,2} where their pseudo root is always / and I want both to have the same namespace and therefore I need v4 to have a / pseudo root. So, what should an exports file look like if I want to have a shared v2/v3/v4 exports? Let's say I actually *do* want my / filesystem to be ro mountable, then it should look like this: / *(ro,fsid=0) # this to set the pseudo root for v4 / *(ro) # this to export / /home *(rw) # you get the point If, on the other hand, I have v2/v3/v4 enabled and I want them to have the same mount points, and / is not one of those mount points, it should look like this: / *(ro,fsid=0) # again, this should set the pseudo root *only* /home *(rw) # now all versions see this mount, and this mount only Now, are you saying that we should just leave out setting the pseudo root if we don't want / to be exported in this case and that will get us the same thing because the default pseudo root will be / anyway? If so, that's broken behavior (that leaving the pseudo root to be a default will set the root but not export it while setting the root will cause the root to be exported). As another scenario consider this: I serve out files to Windows, Mac, and Linux computers. The files are all located under /srv. It would be reasonable for me to define /srv as my pseudo root, especially as I have multiple linux specific directories immediately under /srv (/srv/Linux, /srv/Fedora, /srv/RHEL*, /srv/koji). However, I also have /srv/OS-X and /srv/Windows. So let's say I create the exports file as such: /srv *(ro,fsid=0) /srv/Linux *(rw) /srv/Fedora *(ro) /srv/RHEL4 *(ro) /srv/RHEL5 *(ro) /srv/koji *(ro) What I want out of this is on all of my clients, I want (expect) the following command to fail: mount server:/ /srv I want the following command to succeed: mount server:/Linux /srv/Linux So, my point in all of this is that for the entire existence of the pseudo root to date, it has always existed without also being exported unless explicitly exported aside from being set. You can not now change that so that setting the pseudo root also exports it. This would be a massive regression. More importantly though, there are any number of perfectly valid scenarios where one might want to set the pseudo root without also exporting it. Forcing those two acts to be one and the same more or less renders the whole feature so broken as to be impractical to use, by design. -- Doug Ledford 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: OpenPGP digital signature URL: From tcallawa at redhat.com Tue Nov 3 14:55:15 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 03 Nov 2009 09:55:15 -0500 Subject: Wodim trouble In-Reply-To: <20091103145203.GB1386107@hiwaay.net> References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> <4AF03F77.6060705@redhat.com> <4af04237.cEqJFoLH7rjBUoBJ%Joerg.Schilling@fokus.fraunhofer.de> <20091103145203.GB1386107@hiwaay.net> Message-ID: <4AF04453.7090107@redhat.com> On 11/03/2009 09:52 AM, Chris Adams wrote: > Once upon a time, Joerg Schilling said: >> - Redhat continues to distribute "cdrkit" although there are >> known legal problems with it and Redhat has been informed more that >> once about this fact. > > it is "Red Hat", not "Redhat" (and this is Fedora). > > You have refused to cite specific legal problems with cdrkit, so there > are no "known legal problems" that anyone can see. The proper reporting > method is bugzilla.redhat.com; can you point to where you reported them? Guys, this is a friendly pre-warning. This thread is now covered under the hall-monitor policy. Feel free to take this discussion to fedora-legal, or preferrably, off-list. Future posts on this thread will receive a formal warning. See: https://fedoraproject.org/wiki/Hall_Monitor_Policy ~spot From Joerg.Schilling at fokus.fraunhofer.de Tue Nov 3 14:53:40 2009 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 03 Nov 2009 15:53:40 +0100 Subject: Wodim trouble In-Reply-To: <20091103145203.GB1386107@hiwaay.net> References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> <4AF03F77.6060705@redhat.com> <4af04237.cEqJFoLH7rjBUoBJ%Joerg.Schilling@fokus.fraunhofer.de> <20091103145203.GB1386107@hiwaay.net> Message-ID: <4af043f4.fT5h4fXa/bMPNT7J%Joerg.Schilling@fokus.fraunhofer.de> Chris Adams wrote: > You have refused to cite specific legal problems with cdrkit, so there > are no "known legal problems" that anyone can see. The proper reporting > method is bugzilla.redhat.com; can you point to where you reported them? It seems that you did never check this as otherwise you did know the reports. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From ssorce at redhat.com Tue Nov 3 15:01:53 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 03 Nov 2009 10:01:53 -0500 Subject: Wodim trouble In-Reply-To: <4af01afb.Y3y/4AG0wa3tSTSL%Joerg.Schilling@fokus.fraunhofer.de> References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> <4af01afb.Y3y/4AG0wa3tSTSL%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <1257260513.3553.35.camel@willson.li.ssimo.org> On Tue, 2009-11-03 at 12:58 +0100, Joerg Schilling wrote: > > The conclusion of all lawyers I did talk to, is that there is no legal > problem > with original source. There is no problem with the **source**, but the binary results most probably cannot be distributed, because they combine in a single work 2 incompatible licenses. Have you thought about using GPLv3 instead ? It may be more compatible with CDDL (needs to be run through real lawyers first of course). Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Tue Nov 3 15:05:05 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 03 Nov 2009 10:05:05 -0500 Subject: Wodim trouble In-Reply-To: <3668e9f50911030643q3217990cs4562e037d3a2c284@mail.gmail.com> References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> <200911030026.39420.cemeyer@u.washington.edu> <3668e9f50911030048k5e2aa5c8lef3b38d5f92c6a50@mail.gmail.com> <4af021e1.x8Q1QbpuH3XxN9y8%Joerg.Schilling@fokus.fraunhofer.de> <3668e9f50911030447r13b647b7yf54b0b6ecb6a993b@mail.gmail.com> <4af02b67.PLMgiSqdDVNu5ZQe%Joerg.Schilling@fokus.fraunhofer.de> <3668e9f50911030643q3217990cs4562e037d3a2c284@mail.gmail.com> Message-ID: <1257260706.3553.36.camel@willson.li.ssimo.org> On Tue, 2009-11-03 at 15:43 +0100, Josephine Tannh?user wrote: > The quality of the content of your Messages sometimes extremly differs > from your behavior, your way how you tell it. Perhaps it is me (as a > woman) who is very sensitive in that case. Josephine, be reassured, it's definitely not you. J?rg is a known "personality" ... Simo. -- Simo Sorce * Red Hat, Inc * New York From ngompa13 at gmail.com Tue Nov 3 15:07:37 2009 From: ngompa13 at gmail.com (King InuYasha) Date: Tue, 3 Nov 2009 09:07:37 -0600 Subject: Wodim trouble In-Reply-To: <4af043f4.fT5h4fXa/bMPNT7J%Joerg.Schilling@fokus.fraunhofer.de> References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> <4AF03F77.6060705@redhat.com> <4af04237.cEqJFoLH7rjBUoBJ%Joerg.Schilling@fokus.fraunhofer.de> <20091103145203.GB1386107@hiwaay.net> <4af043f4.fT5h4fXa/bMPNT7J%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <8278b1b0911030707l7fc2eae2h8f71a76ac0fb191d@mail.gmail.com> On Tue, Nov 3, 2009 at 8:53 AM, Joerg Schilling < Joerg.Schilling at fokus.fraunhofer.de> wrote: > Chris Adams wrote: > > > You have refused to cite specific legal problems with cdrkit, so there > > are no "known legal problems" that anyone can see. The proper reporting > > method is bugzilla.redhat.com; can you point to where you reported them? > > It seems that you did never check this as otherwise you did know the > reports. > > J?rg > > Just with a quick search in the Red Hat Bugzilla, only though distro section Fedora, I found this: https://bugzilla.redhat.com/buglist.cgi?component=cdrkit&product=Fedora Listed 39 bugs. A quick look shows a disturbing amount of WONTFIX (ignoring rhbz#472924). But I also see things have still been progressing. However, what I want to know is what prompted the relicense to CDDL in the first place? From what I can see, J?rg Schilling, you are the maintainer and creator of the "original software" cdrtools. Also, why are you so hostile to cdrkit? The implicitly permits forking via its redistribution clause. If you wanted to be able to mix with proprietary code and non-Linux systems, the LGPL would have been just as good. While it is true that the GPL permits linking to CDDL libraries, that is only in the case if the library is a "system library," which is a library that is NECESSARY for working on a particular OS. This is usually how it is justified that GPL software can be built using Visual Studio on Windows, even if I personally don't like it. The runtime library in Windows is almost certainly not GPL compatible, as was the case for many other UNIX application runtime libraries at the time. That is what they built into the GPL, not a "free for all" library linking exception. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joerg.Schilling at fokus.fraunhofer.de Tue Nov 3 15:17:19 2009 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 03 Nov 2009 16:17:19 +0100 Subject: Wodim trouble In-Reply-To: <1257260513.3553.35.camel@willson.li.ssimo.org> References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> <4af01afb.Y3y/4AG0wa3tSTSL%Joerg.Schilling@fokus.fraunhofer.de> <1257260513.3553.35.camel@willson.li.ssimo.org> Message-ID: <4af0497f.jH03KEj8d9JsK9Yy%Joerg.Schilling@fokus.fraunhofer.de> Simo Sorce wrote: > On Tue, 2009-11-03 at 12:58 +0100, Joerg Schilling wrote: > > > > The conclusion of all lawyers I did talk to, is that there is no legal > > problem > > with original source. > > There is no problem with the **source**, but the binary results most > probably cannot be distributed, because they combine in a single work 2 > incompatible licenses. Mkisofs is fully under GPL and there is no single work created that combines licenses. For this reason, there is no problem with the binaries. Note that Sun of course distributes binaries and that Sun legal checked whether distributing binaries from cdrtools could cause problems. > Have you thought about using GPLv3 instead ? When the first GPLv3 draft was announced, the GPLv3 looked very interisting as GPLv3 was announced to be more permissive against OSS than GPLv2 but unfortunately, the final GPLv3 is a more restrictive license than GPLv2. > It may be more compatible with CDDL (needs to be run through real > lawyers first of course). While the GPLv2 gives explicit compatibility for GPLd programs to use any kind of independent library (as an independent library does not create a drived work from just linking against it), GPLv3 introduced a limitation against such combinations that is not in GPLv2. BTW: I am happy to see your post as this is the first post from a Red Hat person that looks respectful and interested in a solution. I hope we can find a solution for the current problem. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling at fokus.fraunhofer.de Tue Nov 3 15:19:44 2009 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 03 Nov 2009 16:19:44 +0100 Subject: Wodim trouble In-Reply-To: <8278b1b0911030707l7fc2eae2h8f71a76ac0fb191d@mail.gmail.com> References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> <4AF03F77.6060705@redhat.com> <4af04237.cEqJFoLH7rjBUoBJ%Joerg.Schilling@fokus.fraunhofer.de> <20091103145203.GB1386107@hiwaay.net> <4af043f4.fT5h4fXa/bMPNT7J%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911030707l7fc2eae2h8f71a76ac0fb191d@mail.gmail.com> Message-ID: <4af04a10.qwfH5TuhxSU3EBTt%Joerg.Schilling@fokus.fraunhofer.de> King InuYasha wrote: > While it is true that the GPL permits linking to CDDL libraries, that is > only in the case if the library is a "system library," which is a library > that is NECESSARY for working on a particular OS. This is usually how it is Please show me the exact place in the GPL text thatyou have in mind to prove your claim. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From ndbecker2 at gmail.com Tue Nov 3 16:19:56 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 03 Nov 2009 11:19:56 -0500 Subject: texlive-2009 breakage? Message-ID: I had texlive* installed. After today's update, I no longer have any /usr/share/texlive directory! I'm guessing some install script removed it?? From jreznik at redhat.com Tue Nov 3 16:33:18 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Tue, 3 Nov 2009 17:33:18 +0100 Subject: KDE-SIG weekly report (45/2009) Message-ID: <200911031733.19167.jreznik@redhat.com> This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. ---------------------------------------------------------------------------------- = Weekly KDE Summary = Week: 45/2009 Time: 2009-11-03 14:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-11-03 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2009-11-03/fedora-meeting.2009-11-03-14.08.txt Meeting log: http://meetbot.fedoraproject.org/fedora- meeting/2009-11-03/fedora-meeting.2009-11-03-14.08.log.html ---------------------------------------------------------------------------------- = Participants = BenBoeckel JaroslavReznik KevinKofler RexDieter StevenParrish ThanNgo ThomasJanssen Ryan Rix ---------------------------------------------------------------------------------- = Agenda = * topics to discuss: o KDE-4.3.3 state o Fedora 12 looming soon, remaining issues/blockers? o constantine-kde-theme-extras, aka packaging Mosaico kdm/ksplash theme? o VOIP meetings = Summary = o KDE-4.3.3 state * 4.3.3 is imported into devel/ branch * some remaining issues - kdebindings & kde-l10n doesn't build ** Kevin_Kofler suggest mathstuff hint how to fix kdebindings ** rdieter will fix kde-l10n issues o Fedora 12 looming soon, remaining issues/blockers? * a lot of KDE SIG members are using Fedora 12 already * beta still had the "install to hd link on desktop lacking execute permission" problem * "SELinux is preventing the /bin/loadkeys from using potentially mislabeled files (Documents)." bug [1] added to Fedora 12 blockers tracker o constantine-kde-theme-extras, aka packaging Mosaico kdm/ksplash theme? * we agreed we don't want it, if someone is willing to fix issues, we're not blocking it * issues: ** KDM colors do not match latest wallpaper ** KSplash rectangles have bad looking shaddows * jreznik will import old Constantine to SVN o VOIP meetings * not for regular meetings (at least for now) * we try to set conference call from FUDCon ---------------------------------------------------------------------------------- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-11-10 ---------------------------------------------------------------------------------- = Links = [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=529951 From tcallawa at redhat.com Tue Nov 3 16:45:58 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 03 Nov 2009 11:45:58 -0500 Subject: help debugging segfault with alienarena 7.32 Message-ID: <4AF05E46.5090404@redhat.com> I need to rebuild alienarena for all targets due to a security issue, so I decided to update to 7.32, but unfortunately, the 7.32 build segfaults immediately on Fedora 12 (x86_64), and gdb isn't much help (gdb output is at the bottom). Now, it is worth noting that the alienarena client does dlopen the openal-soft library by name: const char libopenal_name[] = "libopenal.so.1.9.563"; void *dynlib; dynlib = dlopen( libopenal_name, RTLD_LAZY | RTLD_GLOBAL ); However, I can't seem to find a breakpoint that gdb will hit before the app segfaults, and printfs never get triggered. Any and all help is appreciated, as I'd like to get this fixed before F-12. [spot at pterodactyl release]$ gdb ./crx GNU gdb (GDB) Fedora (7.0-3.fc12) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /home/spot/cvs/alienarena/F-12/alienarena-7.32/source/release/crx...done. (gdb) run Starting program: /home/spot/cvs/alienarena/F-12/alienarena-7.32/source/release/crx [Thread debugging using libthread_db enabled] [New Thread 0x7fffea1e0710 (LWP 18787)] [Thread 0x7fffea1e0710 (LWP 18787) exited] [New Thread 0x7fffea1e0710 (LWP 18788)] [Thread 0x7fffea1e0710 (LWP 18788) exited] [New Thread 0x7fffea1e0710 (LWP 18789)] [Thread 0x7fffea1e0710 (LWP 18789) exited] [New Thread 0x7fffea1e0710 (LWP 18790)] [Thread 0x7fffea1e0710 (LWP 18790) exited] [New Thread 0x7fffea1e0710 (LWP 18791)] Detaching after fork from child process 18792. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffea1e0710 (LWP 18791)] pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:170 170 LOCK Current language: auto The current source language is "auto; currently asm". (gdb) info threads * 6 Thread 0x7fffea1e0710 (LWP 18791) pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:170 1 Thread 0x7ffff7fb77e0 (LWP 18784) _dl_map_object (loader=0x7ffff7fcc4d0, name=0x7ffff660574a "libportaudio.so.2", preloaded=, type=, trace_mode=, mode=-1879048190, nsid=0) at dl-load.c:1981 (gdb) bt #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:170 #1 0x00007fffeff883bb in ?? () #2 0x00007fffea1e0710 in ?? () #3 0x00007ffff4f8696a in start_thread (arg=) at pthread_create.c:297 #4 0x00007ffff5aaa8bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #5 0x0000000000000000 in ?? () (gdb) thread 1 [Switching to thread 1 (Thread 0x7ffff7fb77e0 (LWP 18784))]#0 _dl_map_object (loader=0x7ffff7fcc4d0, name=0x7ffff660574a "libportaudio.so.2", preloaded=, type=, trace_mode=, mode=-1879048190, nsid=0) at dl-load.c:1981 1981 if (__builtin_expect (l->l_soname_added, 1) Current language: auto The current source language is "auto; currently c". (gdb) bt #0 _dl_map_object (loader=0x7ffff7fcc4d0, name=0x7ffff660574a "libportaudio.so.2", preloaded=, type=, trace_mode=, mode=-1879048190, nsid=0) at dl-load.c:1981 #1 0x00007ffff7df0299 in dl_open_worker (a=) at dl-open.c:254 #2 0x00007ffff7deb7c6 in _dl_catch_error (objname=, errstring=, mallocedp=, operate=, args=) at dl-error.c:178 #3 0x00007ffff7defca7 in _dl_open (file=0x7ffff660574a "libportaudio.so.2", mode=-2147483646, caller_dlopen=0x7ffff65ffaf1, nsid=-2, argc=1, argv=, env=0x7fffffffe0c8) at dl-open.c:583 #4 0x00007ffff7955f66 in dlopen_doit (a=) at dlopen.c:67 #5 0x00007ffff7deb7c6 in _dl_catch_error (objname=, errstring=, mallocedp=, operate=, args=) at dl-error.c:178 #6 0x00007ffff795629c in _dlerror_run (operate=0x7ffff7955f00 , args=0x7fffffffdeb0) at dlerror.c:164 #7 0x00007ffff7955ee1 in __dlopen (file=, mode=) at dlopen.c:88 #8 0x00007ffff65ffaf1 in pa_load () at /usr/src/debug/openal-soft/Alc/portaudio.c:66 #9 0x00007ffff65ffee8 in alc_pa_probe (type=1) at /usr/src/debug/openal-soft/Alc/portaudio.c:289 #10 0x00007ffff65e8bfe in alc_init () at /usr/src/debug/openal-soft/Alc/ALc.c:297 #11 0x00007ffff6602556 in __do_global_ctors_aux () from /usr/lib64/libopenal.so.1 #12 0x00007ffff65d8aeb in _init () from /usr/lib64/libopenal.so.1 #13 0x00007fffffffe0c8 in ?? () #14 0x00007ffff7debb29 in call_init (l=0x7ffff7fcc4d0, argc=-159341768, argv=0x7fffffffe0b8, env=0x7fffffffe0c8) at dl-init.c:70 #15 0x00007ffff7debcaf in _dl_init (main_map=0x7ffff7ffe0e8, argc=1, argv=0x7fffffffe0b8, env=0x7fffffffe0c8) at dl-init.c:134 #16 0x00007ffff7dddb2a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 #17 0x0000000000000001 in ?? () #18 0x00007fffffffe3d4 in ?? () #19 0x0000000000000000 in ?? () (gdb) From shakthimaan at gmail.com Tue Nov 3 16:51:13 2009 From: shakthimaan at gmail.com (Shakthi Kannan) Date: Tue, 3 Nov 2009 22:21:13 +0530 Subject: Web page for distro life cycle stage Message-ID: Hi, Is there a web-page or is it possible to have one that shows the Fedora distro release and its stage in the release cycle? For example, if a release such as Fedora 9, is not supported, one can have it shown with a red circle. If a release is in freeze, it can be in marked in an yellow circle, and when we can push packages to a release, it can be in a green circle, similar to traffic signal lights? While, we do receive e-mails on freeze updates, I thought it will be simpler to just check a web-page rather than having to go through mailing list archives? Suggestions welcome. SK -- Shakthi Kannan http://www.shakthimaan.com From dmalcolm at redhat.com Tue Nov 3 17:16:18 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Tue, 03 Nov 2009 12:16:18 -0500 Subject: help debugging segfault with alienarena 7.32 In-Reply-To: <4AF05E46.5090404@redhat.com> References: <4AF05E46.5090404@redhat.com> Message-ID: <1257268578.29719.17.camel@brick> On Tue, 2009-11-03 at 11:45 -0500, Tom "spot" Callaway wrote: > I need to rebuild alienarena for all targets due to a security issue, so > I decided to update to 7.32, but unfortunately, the 7.32 build segfaults > immediately on Fedora 12 (x86_64), and gdb isn't much help (gdb output > is at the bottom). FWIW, it looks like the backtrace is within the C++ start-up code that runs all non-empty constructors for global C++ variables, which gets called before "main" starts for a C++ program. Does (gdb) break call_init before (gdb) run give you a working breakpoint? [snip] Hope this is helpful Dave From tcallawa at redhat.com Tue Nov 3 17:30:50 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 03 Nov 2009 12:30:50 -0500 Subject: help debugging segfault with alienarena 7.32 In-Reply-To: <1257268578.29719.17.camel@brick> References: <4AF05E46.5090404@redhat.com> <1257268578.29719.17.camel@brick> Message-ID: <4AF068CA.2060600@redhat.com> On 11/03/2009 12:16 PM, David Malcolm wrote: > On Tue, 2009-11-03 at 11:45 -0500, Tom "spot" Callaway wrote: >> I need to rebuild alienarena for all targets due to a security issue, so >> I decided to update to 7.32, but unfortunately, the 7.32 build segfaults >> immediately on Fedora 12 (x86_64), and gdb isn't much help (gdb output >> is at the bottom). > > FWIW, it looks like the backtrace is within the C++ start-up code that > runs all non-empty constructors for global C++ variables, which gets > called before "main" starts for a C++ program. > > Does > (gdb) break call_init > before > (gdb) run > give you a working breakpoint? It does, but it doesn't seem to be terribly useful in debugging, as it keeps hitting that breakpoint over and over and over. I admit to being reasonably clueless with gdb. ~spot From ngompa13 at gmail.com Tue Nov 3 17:40:20 2009 From: ngompa13 at gmail.com (King InuYasha) Date: Tue, 3 Nov 2009 11:40:20 -0600 Subject: Wodim trouble In-Reply-To: <4af04a10.qwfH5TuhxSU3EBTt%Joerg.Schilling@fokus.fraunhofer.de> References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> <4AF03F77.6060705@redhat.com> <4af04237.cEqJFoLH7rjBUoBJ%Joerg.Schilling@fokus.fraunhofer.de> <20091103145203.GB1386107@hiwaay.net> <4af043f4.fT5h4fXa/bMPNT7J%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911030707l7fc2eae2h8f71a76ac0fb191d@mail.gmail.com> <4af04a10.qwfH5TuhxSU3EBTt%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <8278b1b0911030940t1eb98a4q22e62958117f12bc@mail.gmail.com> GPLv2: End of Section 3, middle of the paragraph right after clause 3c. GPLv3: Explicit separate definition in Section 1. GPLv2 Quote: "The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable." GPLv3 Quote: "The ?System Libraries? of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A ?Major Component?, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it." I hope this satisfies you. On Tue, Nov 3, 2009 at 9:19 AM, Joerg Schilling < Joerg.Schilling at fokus.fraunhofer.de> wrote: > King InuYasha wrote: > > > While it is true that the GPL permits linking to CDDL libraries, that is > > only in the case if the library is a "system library," which is a library > > that is NECESSARY for working on a particular OS. This is usually how it > is > > Please show me the exact place in the GPL text thatyou have in mind to > prove your claim. > > J?rg > > -- > EMail:joerg at schily.isdn.cs.tu-berlin.de(home) J?rg Schilling D-13353 Berlin > js at cs.tu-berlin.de (uni) > joerg.schilling at fokus.fraunhofer.de (work) Blog: > http://schily.blogspot.com/ > URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ngompa13 at gmail.com Tue Nov 3 17:40:20 2009 From: ngompa13 at gmail.com (King InuYasha) Date: Tue, 3 Nov 2009 11:40:20 -0600 Subject: Wodim trouble In-Reply-To: <4af04a10.qwfH5TuhxSU3EBTt%Joerg.Schilling@fokus.fraunhofer.de> References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> <4AF03F77.6060705@redhat.com> <4af04237.cEqJFoLH7rjBUoBJ%Joerg.Schilling@fokus.fraunhofer.de> <20091103145203.GB1386107@hiwaay.net> <4af043f4.fT5h4fXa/bMPNT7J%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911030707l7fc2eae2h8f71a76ac0fb191d@mail.gmail.com> <4af04a10.qwfH5TuhxSU3EBTt%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <8278b1b0911030940t1eb98a4q22e62958117f12bc@mail.gmail.com> GPLv2: End of Section 3, middle of the paragraph right after clause 3c. GPLv3: Explicit separate definition in Section 1. GPLv2 Quote: "The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable." GPLv3 Quote: "The ?System Libraries? of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A ?Major Component?, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it." I hope this satisfies you. On Tue, Nov 3, 2009 at 9:19 AM, Joerg Schilling < Joerg.Schilling at fokus.fraunhofer.de> wrote: > King InuYasha wrote: > > > While it is true that the GPL permits linking to CDDL libraries, that is > > only in the case if the library is a "system library," which is a library > > that is NECESSARY for working on a particular OS. This is usually how it > is > > Please show me the exact place in the GPL text thatyou have in mind to > prove your claim. > > J?rg > > -- > EMail:joerg at schily.isdn.cs.tu-berlin.de(home) J?rg Schilling D-13353 Berlin > js at cs.tu-berlin.de (uni) > joerg.schilling at fokus.fraunhofer.de (work) Blog: > http://schily.blogspot.com/ > URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at fedoraproject.org Tue Nov 3 17:44:12 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 3 Nov 2009 12:44:12 -0500 (EST) Subject: Wodim trouble In-Reply-To: <8278b1b0911030940t1eb98a4q22e62958117f12bc@mail.gmail.com> References: <4aef6fd5.YcSbk7UNq018PCjN%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911021755r31add92aj189088e96d687bef@mail.gmail.com> <4AF03F77.6060705@redhat.com> <4af04237.cEqJFoLH7rjBUoBJ%Joerg.Schilling@fokus.fraunhofer.de> <20091103145203.GB1386107@hiwaay.net> <4af043f4.fT5h4fXa/bMPNT7J%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911030707l7fc2eae2h8f71a76ac0fb191d@mail.gmail.com> <4af04a10.qwfH5TuhxSU3EBTt%Joerg.Schilling@fokus.fraunhofer.de> <8278b1b0911030940t1eb98a4q22e62958117f12bc@mail.gmail.com> Message-ID: On Tue, 3 Nov 2009, King InuYasha wrote: > GPLv2: End of Section 3, middle of the paragraph right after clause 3c.GPLv3: Explicit separate definition in Section 1. > > GPLv2 Quote: > > "The source code for a work means the preferred form of the work for making modifications to it. For an executable work, > complete source code means all the source code for all modules it contains, plus any associated interface definition > files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, > the source code distributed need not include anything that is normally distributed (in either source or binary form) with > the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that > component itself accompanies the executable." > > GPLv3 Quote: > > "The ?System Libraries? of an executable work include anything, other than the work as a whole, that (a) is included in > the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to > enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is > available to the public in source code form. A ?Major Component?, in this context, means a major essential component > (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a > compiler used to produce the work, or an object code interpreter used to run it." > > I hope this satisfies you. This thread is closed. please do not post any additional comments to it. -sv From oget.fedora at gmail.com Tue Nov 3 17:47:45 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Tue, 3 Nov 2009 12:47:45 -0500 Subject: libsndfile status? In-Reply-To: <20091103104851.571a717f@faldor.intranet> References: <20091103104851.571a717f@faldor.intranet> Message-ID: On Tue, Nov 3, 2009 at 4:48 AM, Michael Schwendt wrote: > https://admin.fedoraproject.org/pkgdb/packages/bugs/libsndfile > > What's up with libsndfile in Fedora and EPEL? > There are open tickets about CVEs filed in March. > There are additional tickets without any reply. > Yeah, things go a little slow with libsndfile. Because of the old version we have in < Fedora 12 we also are not able to update some of our audio packages. I requested for comaintainership to fix the bugs filed to Fedora. Orcan From mw_triad at users.sourceforge.net Tue Nov 3 18:03:49 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Tue, 03 Nov 2009 12:03:49 -0600 Subject: orphaning (eol) gtk-qt-engine In-Reply-To: References: Message-ID: Kevin Kofler wrote: > Petrus de Calguarium wrote: >> By the way, colours on old kde3 apps doesn't work, >> either, despite enabling for non-kde4 applications in >> system settings (kftpgrabber) - I can see it already: >> file a bug report :-) > > There's already an ages-old bug report, the upstream KDE developers don't > care. :-( ...or maybe the upstream developers don't know how to fix it. Help welcomed. (Actually, it's more accurate to say that I am not aware of anyone maintaining the 'export colors' functionality. Jeremy Whiting and I are - last I knew, anyway :-) - the nominal maintainers for color kcm stuff, and I certainly fix anything I can, but I know next to nothing about how the export colors stuff works. Ergo, I am not able to fix it.) FTR, exporting colors to GTK seems flaky also, but I'm not sure it's a KDE problem. I've noticed that after I force the export code to run (basically, make any change and apply it - even toggle a checkbox twice, you just need to be able to press 'apply'), the first app will be right, but the next one gets default colors. At least for Mozilla apps (FF, TB) and IIRC gitk. OTOH, Inkscape seems okay. > I might try to fix this somehow. If you are able to help, that would be /much/ appreciated. Please don't hesitate to work upstream, I would very much like to see these issues resolved. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- HIPPOS feel unacknowledged. HIPPOS get angry. > PRAISE HIPPOS HIPPOS seem somewhat placated. From kevin at scrye.com Tue Nov 3 18:14:18 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Tue, 3 Nov 2009 11:14:18 -0700 Subject: Claudio Tomasoni is now MIA In-Reply-To: <1257039910.12503.59.camel@wicktop.localdomain> References: <1257039910.12503.59.camel@wicktop.localdomain> Message-ID: <20091103111418.26501ea8@ohm.scrye.com> On Sun, 01 Nov 2009 02:45:10 +0100 Christoph Wickert wrote: > This is a follow-up to my mail from October 9th [1] > As per unresponsive package maintainer policy, Claudio is now > officially considered missing in action and his packages [2] will be > orphaned. I can ack this per the procedure as a FESCo member. I am going to orphan those packages now. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From limb at jcomserv.net Tue Nov 3 18:19:26 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 03 Nov 2009 12:19:26 -0600 Subject: Claudio Tomasoni is now MIA In-Reply-To: <20091103111418.26501ea8@ohm.scrye.com> References: <1257039910.12503.59.camel@wicktop.localdomain> <20091103111418.26501ea8@ohm.scrye.com> Message-ID: <4AF0742E.1060805@jcomserv.net> Kevin Fenzi wrote: > On Sun, 01 Nov 2009 02:45:10 +0100 > Christoph Wickert wrote: > > >> This is a follow-up to my mail from October 9th [1] >> As per unresponsive package maintainer policy, Claudio is now >> officially considered missing in action and his packages [2] will be >> orphaned. >> > > I can ack this per the procedure as a FESCo member. > > I am going to orphan those packages now. > > kevin > Thanks. Tennix (and it's bug) taken. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie From ndbecker2 at gmail.com Tue Nov 3 19:00:19 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 03 Nov 2009 14:00:19 -0500 Subject: texlive-2009 tlmgr Message-ID: tlmgr Can't locate TeXLive/TLPOBJ.pm in @INC (@INC contains: /usr/share/texlive/tlpkg /usr/local/lib64/perl5/site_perl/5.10.0/x86_64- linux-thread-multi /usr/local/lib/perl5/site_perl/5.10.0 /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi /usr/lib/perl5/5.10.0 /usr/lib/perl5/site_perl .) at /usr/bin/tlmgr line 36. BEGIN failed--compilation aborted at /usr/bin/tlmgr line 36. sure enough, /usr/share/texlive/tlpkg dir exists, but is empty. From loganjerry at gmail.com Tue Nov 3 19:16:37 2009 From: loganjerry at gmail.com (Jerry James) Date: Tue, 3 Nov 2009 12:16:37 -0700 Subject: help debugging segfault with alienarena 7.32 In-Reply-To: <4AF05E46.5090404@redhat.com> References: <4AF05E46.5090404@redhat.com> Message-ID: <870180fe0911031116l3c7af629o245bcae3c4a2c940@mail.gmail.com> On Tue, Nov 3, 2009 at 9:45 AM, Tom "spot" Callaway wrote: > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7fffea1e0710 (LWP 18791)] > pthread_cond_wait@@GLIBC_2.3.2 () at > ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:170 > 170 ? ? ? ? ? ? LOCK > Current language: ?auto > The current source language is "auto; currently asm". > (gdb) info threads > * 6 Thread 0x7fffea1e0710 (LWP 18791) ?pthread_cond_wait@@GLIBC_2.3.2 () > at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:170 > ?1 Thread 0x7ffff7fb77e0 (LWP 18784) ?_dl_map_object > (loader=0x7ffff7fcc4d0, name=0x7ffff660574a "libportaudio.so.2", > ? ?preloaded=, type=, > trace_mode=, mode=-1879048190, nsid=0) at > dl-load.c:1981 This seems to happen only when portaudio is installed. Uninstall portaudio and alienarena starts up. I'm not sure exactly what is going on here, but it seems that alienarena is both trying to dlopen libopenal, and is linked against it. Check it: ldd /usr/libexec/alienarena | grep -F openal My guess (and it is just a guess) is that this is triggering multiple initializations of portaudio. Try this patch: diff -dur alienarena-7.32.ORIG/source/Makefile alienarena-7.32/source/Makefile --- alienarena-7.32.ORIG/source/Makefile 2009-11-02 19:01:01.000000000 -0700 +++ alienarena-7.32/source/Makefile 2009-11-03 12:05:38.283115734 -0700 @@ -266,7 +266,7 @@ $(BUILDDIR)/crx : $(CODERED_OBJS) $(SOUND_OPENAL_OBJS) $(REF_GL_OBJS) $(REF_GL_GLX_OBJS) - $(CC) $(CFLAGS) -o $@ $(CODERED_OBJS) $(LDFLAGS) $(REF_GL_OBJS) $(REF_GL_GLX_OBJS) $(GLXLDFLAGS) $(OPENALLDFLAGS) $(VORBISLDFLAGS) $(CURLLDFLAGS) $(JPEGLDFLAGS) + $(CC) $(CFLAGS) -o $@ $(CODERED_OBJS) $(LDFLAGS) $(REF_GL_OBJS) $(REF_GL_GLX_OBJS) $(GLXLDFLAGS) $(VORBISLDFLAGS) $(CURLLDFLAGS) $(JPEGLDFLAGS) $(BUILDDIR)/client/cl_ents.o : $(CLIENT_DIR)/cl_ents.c $(DO_CC) -- Jerry James http://www.jamezone.org/ From jreiser at bitwagon.com Tue Nov 3 19:17:23 2009 From: jreiser at bitwagon.com (John Reiser) Date: Tue, 03 Nov 2009 11:17:23 -0800 Subject: help debugging segfault with alienarena 7.32 In-Reply-To: <4AF068CA.2060600@redhat.com> References: <4AF05E46.5090404@redhat.com> <1257268578.29719.17.camel@brick> <4AF068CA.2060600@redhat.com> Message-ID: <4AF081C3.6020401@bitwagon.com> >> FWIW, it looks like the backtrace is within the C++ start-up code that >> runs all non-empty constructors for global C++ variables, which gets >> called before "main" starts for a C++ program. >> >> Does >> (gdb) break call_init >> before >> (gdb) run >> give you a working breakpoint? > It does, but it doesn't seem to be terribly useful in debugging, as it > keeps hitting that breakpoint over and over and over. (gdb) set stop-on-solib-events 1 (gdb) run <> Stopped due to shared library event (gdb) info shared From To Syms Read Shared Object Library 0x00dc2830 0x00ddb27f Yes /lib/ld-linux.so.2 0x00ae4410 0x00ae45e8 Yes a.out (gdb) c Continuing. Stopped due to shared library event (gdb) info shared From To Syms Read Shared Object Library 0x00dc2830 0x00ddb27f Yes /lib/ld-linux.so.2 0x00ae4410 0x00ae45e8 Yes a.out 0x00e5a840 0x00f68c78 Yes /lib/libc.so.6 etc. You might run afoul of this years-old bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179072 Post the build, or a pointer to it, plus the needed environment? -- From tcallawa at redhat.com Tue Nov 3 20:23:32 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 03 Nov 2009 15:23:32 -0500 Subject: help debugging segfault with alienarena 7.32 In-Reply-To: <870180fe0911031116l3c7af629o245bcae3c4a2c940@mail.gmail.com> References: <4AF05E46.5090404@redhat.com> <870180fe0911031116l3c7af629o245bcae3c4a2c940@mail.gmail.com> Message-ID: <4AF09144.8070300@redhat.com> On 11/03/2009 02:16 PM, Jerry James wrote: > This seems to happen only when portaudio is installed. Uninstall > portaudio and alienarena starts up. I'm not sure exactly what is > going on here, but it seems that alienarena is both trying to dlopen > libopenal, and is linked against it. Check it: > > ldd /usr/libexec/alienarena | grep -F openal > > My guess (and it is just a guess) is that this is triggering multiple > initializations of portaudio. Try this patch: This gets me past the initial segfault, thanks! Of course, now the game won't actually start in single-player mode: ======== CRX Initialized ======== Received signal 11, exiting... Received signal 11, exiting... Received signal 11, exiting... Received signal 11, exiting... XIO: fatal IO error 0 (Success) on X server "?o?" after 2628 requests (2619 known processed) with 0 events remaining. AL lib: ALc.c:1641: exit(): closing 1 Device AL lib: ALc.c:1570: alcCloseDevice(): destroying 1 Context AL lib: ALc.c:1259: alcDestroyContext(): deleting 129 Source(s) ------- Loading game.so ------- AL lib: ALc.c:1579: alcCloseDevice(): deleting 256 Buffer(s) Running it again, I get: ======== CRX Initialized ======== Received signal 11, exiting... Received signal 11, exiting... XIO: fatal IO error 0 (Success) on X server "P?%" after 657 requests (654 known processed) with 0 events remaining. AL lib: ALc.c:1641: exit(): closing 1 Device AL lib: ALc.c:1570: alcCloseDevice(): destroying 1 Context Received signal 11, exiting... Received signal 11, exiting... *** glibc detected *** ./crx: free(): invalid pointer: 0x0000000007263c00 *** Received signal 11, exiting... *** glibc detected *** ./crx: free(): invalid pointer: 0x0000000007263c00 *** Segmentation fault Valgrind isn't much more help: ==22231== Process terminating with default action of signal 11 (SIGSEGV) ==22231== Bad permissions for mapped region at address 0xFA9CB20 ==22231== at 0xA1663E0: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.S:170) ==22231== by 0xF88B3BA: ??? (in /usr/lib64/libportaudio.so.2.0.0) The latest patched build is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1786476 It does work in multi-player mode, just not single player. Any more ideas? :) ~spot From ikem.krueger at googlemail.com Tue Nov 3 21:05:33 2009 From: ikem.krueger at googlemail.com (Ikem Krueger) Date: Tue, 3 Nov 2009 21:05:33 +0000 Subject: Web page for distro life cycle stage In-Reply-To: References: Message-ID: > Web page for distro life cycle stage > If a release is in freeze, it can be in marked in an yellow circle, and when we can push packages to a release, it can be in a green circle, similar to traffic signal lights I like this idea. :) From mike.cloaked at gmail.com Tue Nov 3 21:31:52 2009 From: mike.cloaked at gmail.com (Mike Cloaked) Date: Tue, 3 Nov 2009 21:31:52 +0000 (UTC) Subject: A question about allow_unconfined_mmap_low in f11 amd selinux Message-ID: For people running wine or Crossover and using MS Office 2003 and related codes it is necessary to do: # setsebool -P allow_unconfined_mmap_low 1 To prevent AVC denials. However there is recent publicity at http://www.theregister.co.uk/2009/11/03/linux_kernel_vulnerability/ which highlights that there is still a vulnerability in the kernel if this is set. For people running f11 with this boolean set how can one run wine and still remain secure? i.e. what should an admin do to protect the system? From ajax at redhat.com Tue Nov 3 21:35:13 2009 From: ajax at redhat.com (Adam Jackson) Date: Tue, 03 Nov 2009 16:35:13 -0500 Subject: A question about allow_unconfined_mmap_low in f11 amd selinux In-Reply-To: References: Message-ID: <1257284113.7251.330.camel@atropine.boston.devel.redhat.com> On Tue, 2009-11-03 at 21:31 +0000, Mike Cloaked wrote: > For people running wine or Crossover and using MS Office 2003 and related codes > it is necessary to do: > # setsebool -P allow_unconfined_mmap_low 1 > To prevent AVC denials. > > However there is recent publicity at > http://www.theregister.co.uk/2009/11/03/linux_kernel_vulnerability/ > which highlights that there is still a vulnerability in the kernel if this is > set. > > For people running f11 with this boolean set how can one run wine and still > remain secure? i.e. what should an admin do to protect the system? You can't. If I'm being slightly less flip: run wine in a kvm instance with selinux disabled, forward X to the host. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Tue Nov 3 22:17:17 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 03 Nov 2009 23:17:17 +0100 Subject: Wodim trouble References: <1257157747.2767.2.camel@localhost> <4AEF13ED.60001@redhat.com> <1257185899.7251.212.camel@atropine.boston.devel.redhat.com> <4AEF4573.7090407@poolshark.org> <4AEF6919.8060506@redhat.com> <4af002d7.jgo4mm+gG17Y0pTi%Joerg.Schilling@fokus.fraunhofer.de> <4af02910.cQB66iwtw/XoH4r0%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: Joerg Schilling wrote: > You seem to miss that the license mkisofs is using is called "GPL" and not > "GPL FAQ", so the quoting you mention do not apply. The FAQ is the legal interpretation of the GPL given by the FSF, who are the folks who wrote the license, so why would you trust them less than Sun's lawyers? And Eben Moglen, whom you misquoted as agreeing with your bizarre position, was actually involved in writing both the GPL itself and the FAQ. > The GPL requires the entire work to be under GPL and the "entire work > mkisofs" _is_ of course under GPL. The entire work includes any code which is linked into the same executable, statically or dynamically. A program is not complete without its required libraries, it doesn't work at all without them. Kevin Kofler From skvidal at fedoraproject.org Tue Nov 3 22:23:05 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 3 Nov 2009 17:23:05 -0500 (EST) Subject: Wodim trouble In-Reply-To: References: <1257157747.2767.2.camel@localhost> <4AEF13ED.60001@redhat.com> <1257185899.7251.212.camel@atropine.boston.devel.redhat.com> <4AEF4573.7090407@poolshark.org> <4AEF6919.8060506@redhat.com> <4af002d7.jgo4mm+gG17Y0pTi%Joerg.Schilling@fokus.fraunhofer.de> <4af02910.cQB66iwtw/XoH4r0%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: On Tue, 3 Nov 2009, Kevin Kofler wrote: > Joerg Schilling wrote: >> You seem to miss that the license mkisofs is using is called "GPL" and not >> "GPL FAQ", so the quoting you mention do not apply. > > The FAQ is the legal interpretation of the GPL given by the FSF, who are the > folks who wrote the license, so why would you trust them less than Sun's > lawyers? And Eben Moglen, whom you misquoted as agreeing with your bizarre > position, was actually involved in writing both the GPL itself and the FAQ. > >> The GPL requires the entire work to be under GPL and the "entire work >> mkisofs" _is_ of course under GPL. > > The entire work includes any code which is linked into the same executable, > statically or dynamically. A program is not complete without its required > libraries, it doesn't work at all without them. This thread is closed. Do not comment on it anymore. Sincerely, Your friendly neighborhood hall monitor. -sv From kevin.kofler at chello.at Tue Nov 3 22:21:41 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 03 Nov 2009 23:21:41 +0100 Subject: Wodim trouble References: <4aef6970.BiXJGthIdAQejisR%Joerg.Schilling@fokus.fraunhofer.de> <1257207453.23167.8.camel@localhost.localdomain> <4aef7775.RphyRpRUFprHix4z%Joerg.Schilling@fokus.fraunhofer.de> <1257213960.23167.10.camel@localhost.localdomain> <1257222121.15471.2.camel@localhost> <4af02894.ar/x+ZTFXlXRCXO8%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: Joerg Schilling wrote: > Libburn is based on a wrong asumption: libburn only works partly on Linux > in non-root mode Actually, burning as non-root works just fine on GNU/Linux. > and the vast majority of other OS needs root permissions to burn. Those OSes are broken and need to be fixed. > Installing a GUI suid root is an absolute no-go as GUIs are so compley > that it is hard to audit the code for security problems. We know this very well. All the Fedora system-config-* tools are being more or less rewritten to use PolicyKit to only do the parts as root which need to run as root instead of running the whole GUI config tool as root. The same is happening with KDE's System Settings and the KAuth framework (which is based on PolicyKit on GNU/Linux). But the point is that CD/DVD/BluRay burning does not and should not require root privileges at all! Kevin Kofler From skvidal at fedoraproject.org Tue Nov 3 22:55:09 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 3 Nov 2009 17:55:09 -0500 (EST) Subject: Wodim trouble In-Reply-To: References: <4aef6970.BiXJGthIdAQejisR%Joerg.Schilling@fokus.fraunhofer.de> <1257207453.23167.8.camel@localhost.localdomain> <4aef7775.RphyRpRUFprHix4z%Joerg.Schilling@fokus.fraunhofer.de> <1257213960.23167.10.camel@localhost.localdomain> <1257222121.15471.2.camel@localhost> <4af02894.ar/x+ZTFXlXRCXO8%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: On Tue, 3 Nov 2009, Kevin Kofler wrote: > Joerg Schilling wrote: >> Libburn is based on a wrong asumption: libburn only works partly on Linux >> in non-root mode > > Actually, burning as non-root works just fine on GNU/Linux. > >> and the vast majority of other OS needs root permissions to burn. > > Those OSes are broken and need to be fixed. > >> Installing a GUI suid root is an absolute no-go as GUIs are so compley >> that it is hard to audit the code for security problems. > > We know this very well. All the Fedora system-config-* tools are being more > or less rewritten to use PolicyKit to only do the parts as root which need > to run as root instead of running the whole GUI config tool as root. The > same is happening with KDE's System Settings and the KAuth framework (which > is based on PolicyKit on GNU/Linux). > > But the point is that CD/DVD/BluRay burning does not and should not require > root privileges at all! > Kevin, please. Stop responding. -sv From fedora at matbooth.co.uk Tue Nov 3 23:11:52 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Tue, 3 Nov 2009 23:11:52 +0000 Subject: Web page for distro life cycle stage In-Reply-To: References: Message-ID: <9497e9990911031511p36db4251w9f23cfd67d8de64f@mail.gmail.com> 2009/11/3 Ikem Krueger : >> Web page for distro life cycle stage > >> If a release is in freeze, it can be in marked in an yellow circle, and when we can push packages to a release, it can be in a green circle, similar to traffic signal lights > > I like this idea. :) > Can't this be inferred from https://admin.fedoraproject.org/updates ? -- Mat Booth A: Because it destroys the order of the conversation. Q: Why shouldn't you do it? A: Posting your reply above the original message. Q: What is top-posting? From bojan at rexursive.com Wed Nov 4 01:04:57 2009 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 04 Nov 2009 12:04:57 +1100 Subject: Mesa 7.6.0 bugs Message-ID: <1257296698.2488.90.camel@shrek.rexursive.com> New mesa (7.6.0) is causing trouble for people using F-11/12 code (see bugs #524338 and #509528 for instance). Are there fixes available for these problems? Last time 7.6.0 packages were built was Sept 21, which is a month and a half ago and it seems that concerns from the above bugs are not being addressed. Is it too late to revert to 7.5.x, which used to work fine? -- Bojan From shakthimaan at gmail.com Wed Nov 4 05:34:36 2009 From: shakthimaan at gmail.com (Shakthi Kannan) Date: Wed, 4 Nov 2009 11:04:36 +0530 Subject: Web page for distro life cycle stage In-Reply-To: <9497e9990911031511p36db4251w9f23cfd67d8de64f@mail.gmail.com> References: <9497e9990911031511p36db4251w9f23cfd67d8de64f@mail.gmail.com> Message-ID: Hi, --- On Wed, Nov 4, 2009 at 4:41 AM, Mat Booth wrote: | Can't this be inferred from https://admin.fedoraproject.org/updates ? \-- I was looking at something with less text, and having a pictorial representation. Sometimes, a picture is a thousand words! SK -- Shakthi Kannan http://www.shakthimaan.com From jnovy at redhat.com Wed Nov 4 08:09:00 2009 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 4 Nov 2009 09:09:00 +0100 Subject: texlive-2009 tlmgr In-Reply-To: References: Message-ID: <20091104080900.GA5888@dhcp-lab-133.englab.brq.redhat.com> On Tue, Nov 03, 2009 at 02:00:19PM -0500, Neal Becker wrote: > tlmgr > Can't locate TeXLive/TLPOBJ.pm in @INC (@INC contains: > /usr/share/texlive/tlpkg /usr/local/lib64/perl5/site_perl/5.10.0/x86_64- > linux-thread-multi /usr/local/lib/perl5/site_perl/5.10.0 > /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi > /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl > /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi /usr/lib/perl5/5.10.0 > /usr/lib/perl5/site_perl .) at /usr/bin/tlmgr line 36. > BEGIN failed--compilation aborted at /usr/bin/tlmgr line 36. > > sure enough, /usr/share/texlive/tlpkg dir exists, but is empty. > tlmgr seems to be useless with the Fedora TeX Live 2009 because we handle instalation/removal of TL packages ourselves. The perl classes needed to run tlmgr is removed but not the tlmgr binary yet. I will remove it in the next update. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From jnovy at redhat.com Wed Nov 4 08:17:21 2009 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 4 Nov 2009 09:17:21 +0100 Subject: texlive-2009 man & info In-Reply-To: References: Message-ID: <20091104081721.GB5888@dhcp-lab-133.englab.brq.redhat.com> On Tue, Nov 03, 2009 at 07:23:03AM -0500, Neal Becker wrote: > I'm trying texlive-2009 packages for f11. I see man and info pages get > installed (not in standard system locations, but into texlive tree), but man > and info search paths don't seem to be setup to find them. > Good point. The man and info pages are installed to texmf/doc/{info,man} by TeX Live and aren't actually visible to info/man. I'll fix it in the next update. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From jnovy at redhat.com Wed Nov 4 08:28:45 2009 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 4 Nov 2009 09:28:45 +0100 Subject: texlive-2009 breakage? In-Reply-To: References: Message-ID: <20091104082845.GD5888@dhcp-lab-133.englab.brq.redhat.com> On Tue, Nov 03, 2009 at 11:19:56AM -0500, Neal Becker wrote: > I had texlive* installed. > > After today's update, I no longer have any /usr/share/texlive directory! > > I'm guessing some install script removed it?? > There was a mistake in the previous release. The %postun scriptlet tried to remove the texlive directory after removal of the main package in order to not to leave empty directories in /usr/share/texlive RPM didn't remove itself for some reason. It is now fixed with the current packages in the repository. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From pbrobinson at gmail.com Wed Nov 4 09:32:16 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 4 Nov 2009 09:32:16 +0000 Subject: Mesa 7.6.0 bugs In-Reply-To: <1257296698.2488.90.camel@shrek.rexursive.com> References: <1257296698.2488.90.camel@shrek.rexursive.com> Message-ID: <5256d0b0911040132w11321d6bo1dca7bbcbd9c02a3@mail.gmail.com> On Wed, Nov 4, 2009 at 1:04 AM, Bojan Smojver wrote: > New mesa (7.6.0) is causing trouble for people using F-11/12 code (see > bugs #524338 and #509528 for instance). I've seen a couple of bugs in the 3D stuff with Moblin/clutter as well. RHBZ #521714 and #529372 come to mind. Peter From nicolas.mailhot at laposte.net Wed Nov 4 09:34:14 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 4 Nov 2009 10:34:14 +0100 Subject: texlive-2009 breakage? In-Reply-To: <20091104082845.GD5888@dhcp-lab-133.englab.brq.redhat.com> References: <20091104082845.GD5888@dhcp-lab-133.englab.brq.redhat.com> Message-ID: <0689d791c3e365f9091126902656c644.squirrel@arekh.dyndns.org> BTW Jindrich, I know you are very busy, and we never seem to be on irc at the same times, but how is progress on the texlive font packaging front? Font automation QA has progressed quite a bit since you started, you can self-check your progress with repo-font-audit now if you want: http://kojipkgs.fedoraproject.org/packages/fontpackages/1.31/2.fc13/noarch/fontpackages-tools-1.31-2.fc13.noarch.rpm -- Nicolas Mailhot From che666 at gmail.com Wed Nov 4 13:14:53 2009 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 4 Nov 2009 14:14:53 +0100 Subject: conflict between seedit <-> selinux-policy and qstat <-> torque-client Message-ID: Why do those packages have to conflict with each other? 1. seedit and selinux-policy-{targeted,mls} -> i dont see a single file conflicting atleast with the targeted policy... 2. qstat and torque-client both provide a qstat binary... is there anything done to get that resolved upstream? or is it a "conflicts and forget" scenario? from my personal pov conflicts should be resolved instead of just marked so things can be properly installed in parallel. everything else looks broken to me. kind regards, Rudolf Kastl From tibbs at math.uh.edu Wed Nov 4 14:07:31 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 04 Nov 2009 08:07:31 -0600 Subject: conflict between seedit <-> selinux-policy and qstat <-> torque-client In-Reply-To: (Rudolf Kastl's message of "Wed, 4 Nov 2009 14:14:53 +0100") References: Message-ID: >>>>> "RK" == Rudolf Kastl writes: RK> 2. qstat and torque-client both provide a qstat binary... is there RK> anything done to get that resolved upstream? or is it a "conflicts RK> and forget" scenario? This one, I think, should be easily resolvable with alternatives. Actually I think all but a small number of the currently conflicting packages could be fixed up pretty easily. Currently it doesn't seem that there's any sort of enforcement outside of the original package review. The way around this is, of course, for someone to spend some time generating the current list of conflicting packages, proposing solutions, and working with FESCo in the case that those solutions are not applied. - J< From dwalsh at redhat.com Wed Nov 4 14:45:46 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 04 Nov 2009 09:45:46 -0500 Subject: A question about allow_unconfined_mmap_low in f11 amd selinux In-Reply-To: <1257284113.7251.330.camel@atropine.boston.devel.redhat.com> References: <1257284113.7251.330.camel@atropine.boston.devel.redhat.com> Message-ID: <4AF1939A.9020709@redhat.com> On 11/03/2009 04:35 PM, Adam Jackson wrote: > On Tue, 2009-11-03 at 21:31 +0000, Mike Cloaked wrote: >> For people running wine or Crossover and using MS Office 2003 and related codes >> it is necessary to do: >> # setsebool -P allow_unconfined_mmap_low 1 >> To prevent AVC denials. >> >> However there is recent publicity at >> http://www.theregister.co.uk/2009/11/03/linux_kernel_vulnerability/ >> which highlights that there is still a vulnerability in the kernel if this is >> set. >> >> For people running f11 with this boolean set how can one run wine and still >> remain secure? i.e. what should an admin do to protect the system? > > You can't. > > If I'm being slightly less flip: run wine in a kvm instance with selinux > disabled, forward X to the host. > > - ajax > You can run with SELinux in enforcement. mmap_low_allowed is the name of the boolean moving forward. From rawhide at fedoraproject.org Wed Nov 4 14:47:21 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Wed, 4 Nov 2009 14:47:21 +0000 Subject: rawhide report: 20091104 changes Message-ID: <20091104144721.GA2687@releng2.fedora.phx.redhat.com> Compose started at Wed Nov 4 08:15:08 UTC 2009 Broken deps for ppc64 ---------------------------------------------------------- eclipse-photran-5.0.0-0.3.200910081739.fc12.noarch requires eclipse-cdt >= 1:6.0 New package globus-gram-job-manager-callout-error Globus Toolkit - Globus GRAM Jobmanager Callout Errors New package globus-scheduler-event-generator Globus Toolkit - Scheduler Event Generator Updated Packages: DeviceKit-disks-009-3.fc12 -------------------------- * Tue Nov 03 2009 David Zeuthen - 009-2.fc12 - Update udev rules to better cope with device-mapper (#528909) * Tue Nov 03 2009 David Zeuthen - 009-3.fc12 - Avoid automounting LVM LVs (fdobz #24885, rhbz #528909) abrt-0.0.11-1.fc12 ------------------ * Mon Nov 02 2009 Jiri Moskovcak 0.0.11-1 - re-enabled kerneloops - abrt-debuginfo-install: download packages one-by-one - better logging (vda.linux at googlemail.com) - do not report empty fields (vda.linux at googlemail.com) - Added abrt.png, fixed rhbz#531181 (jmoskovc at redhat.com) - added option DebugInfoCacheMB to limit size of unpacked debuginfos (vda.linux at googlemail.com) - fixed the problem with overwriting the default plugin settings (jmoskovc at redhat.com) - disabled kerneloops in config file (jmoskovc at redhat.com) - added dependency to gdb >= 7.0 (jmoskovc at redhat.com) - better format of report text (vda.linux at googlemail.com) - Python backtrace size limited to 1 MB (kklic at redhat.com) - lib/Plugins/Bugzilla: better message at login failure (vda.linux at googlemail.com) - build fixes, added plugin-logger to abrt-desktop (jmoskovc at redhat.com) - blacklisted nspluginwrapper, because it causes too many useless reports (jmoskovc at redhat.com) - GUI: Wrong settings window is not shown behind the reporter dialog rhbz#531119 (jmoskovc at redhat.com) - Normal user can see kerneloops and report it Bugzilla memory leaks fix (npajkovs at redhat.com) - dumpoops: add -s option to dump results to stdout (vda.linux at googlemail.com) - removed kerneloops from abrt-desktop rhbz#528395 (jmoskovc at redhat.com) - GUI: fixed exception when enabling plugin rhbz#530495 (jmoskovc at redhat.com) - Improved abrt-cli (kklic at redhat.com) - Added backtrace rating to CCpp analyzer (dnovotny at redhat.com) - GUI improvements (jmoskovc at redhat.com) - Added abrt-pyhook-helper (kklic at redhat.com) anaconda-12.43-1.fc12 --------------------- * Tue Nov 03 2009 Chris Lumens - 12.43-1 - Remove "anaconda" from attributes to skip (#532612, #532737). (clumens) - Fix status for and consolidate handling of '-' in vg/lv names. (#527302) (dlehman) cronie-1.4.3-1.fc12 ------------------- * Tue Nov 03 2009 Marcela Ma?l??ov? - 1.4.3-1 - 531963 and 532482 creating noanacron package * Mon Oct 19 2009 Marcela Ma?l??ov? - 1.4.2-2 - 529632 service crond stop returns appropriate value * Mon Oct 12 2009 Marcela Ma?l??ov? - 1.4.2-1 - new release cups-1.4.1-13.fc12 ------------------ * Tue Nov 03 2009 Tim Waugh 1:1.4.1-13 - Removed stale patch from STR #2831 which was causing problems with number-up (bug #532516). eclipse-photran-5.0.0-0.3.200910081739.fc12 ------------------------------------------- * Tue Nov 03 2009 Orion Poplawski - 5.0.0-0.3.200910081739 - Make noarch fedora-release-12-1 ------------------- * Mon Nov 02 2009 Jesse Keating - 12-1 - Set up for Fedora 12 gdm-2.28.1-22.fc12 ------------------ * Tue Nov 03 2009 Ray Strode 2.28.1-21 - Evict Log In button from its house * Tue Nov 03 2009 Ray Strode 2.28.1-22 - Hide search entry. It's too easy to show others your password. glibc-2.11-1 ------------ * Mon Nov 02 2009 Andreas Schwab - 2.11-1 - Update to 2.11 release. - Disable multi-arch support on PowerPC again since binutils is too old. - Fix crash in tzdata-update due to use of multi-arch symbol (#532128). * Fri Oct 30 2009 Andreas Schwab - 2.10.90-27 - Update from master. - Fix races in setXid implementation (BZ#3270). - Implement IFUNC for PPC and enable multi-arch support. - Implement mkstemps/mkstemps64 and mkostemps/mkostemps64 (BZ#10349). - Fix IA-64 and S390 sigevent definitions (BZ#10446). - Fix memory leak in NIS grp database handling (BZ#10713). - Print timestamp in nscd debug messages (BZ#10742). - Fix mixing IPv4 and IPv6 name server in resolv.conf. - Fix range checks in coshl. - Implement SSE4.2 optimized strchr and strrchr. - Handle IFUNC symbols in dlsym (#529965). - Misc fixes (BZ#10312, BZ#10315, BZ#10319, BZ#10391, BZ#10425, BZ#10540, BZ#10553, BZ#10564, BZ#10609, BZ#10692, BZ#10780, BZ#10717, BZ#10784, BZ#10789, BZ#10847 - No longer build with -fno-var-tracking-assignments. * Mon Oct 19 2009 Andreas Schwab - 2.10.90-26 - Update from master. - Add ____longjmp_chk for sparc. - Avoid installing the same libraries twice. gnome-system-monitor-2.28.0-3.fc12 ---------------------------------- * Tue Nov 03 2009 Matthias Clasen - 2.28.0-3 - Don't rely on lsb_release for sysinfo (#532860) gstreamer-plugins-base-0.10.25-5.fc12 ------------------------------------- * Tue Nov 03 2009 Bastien Nocera 0.10.25-5 - Update volume notification patch * Thu Oct 29 2009 Bastien Nocera 0.10.25-4 - Make playbin push volume changes to the front-end gstreamer-plugins-good-0.10.16-7.fc12 ------------------------------------- * Tue Nov 03 2009 Bastien Nocera 0.10.16-6 - Add patch from upstream to avoid volume lowering in PA < 0.9.20 * Tue Nov 03 2009 Bastien Nocera 0.10.16-7 - Really check for PA < 0.9.20 gvfs-1.4.1-3.fc12 ----------------- * Tue Nov 03 2009 Tomas Bzatek - 1.4.1-3 - gdu-volume-monitor: don't crash on NULL devices (#529982) * Mon Nov 02 2009 Tomas Bzatek - 1.4.1-2 - Reload .mount files when single package is installed hplip-3.9.8-21.fc12 ------------------- * Mon Nov 02 2009 Tim Waugh 3.9.8-21 - Added 'requires proprietary plugin' to appropriate model names (bug #513283). kernel-2.6.31.5-115.fc12 ------------------------ * Wed Nov 04 2009 Ben Skeggs 2.6.31.5-114 - nouveau: provide info userspace needs to handle low memory situations - nouveau: fix for rh#532711 - nouveau: add option to provide more debug info for rh#532579 - patch only so large because of included register rename * Wed Nov 04 2009 Kyle McMartin 2.6.31.5-115 - fs/pipe.c: fix null pointer dereference (CVE-2009-3547) * Tue Nov 03 2009 Dave Airlie 2.6.31.5-110 - r600: fix for ring setup RMW issue. * Tue Nov 03 2009 Dave Airlie 2.6.31.5-111 - drm-r600-lenovo-w500-fix.patch: fix lenovo w500 acpi video kill laptop dead - drop aspm r600 patch as correct fix should be in 110 * Tue Nov 03 2009 Dave Airlie 2.6.31.5-112 - drm-r600-lenovo-w500-fix.patch: add second patch from upstream fix * Tue Nov 03 2009 Adam Jackson 2.6.31.5-113 - drm-conservative-fallback-modes.patch: When an output is connected but fails EDID, only add modes with refresh rates <= 60 (#514600) * Mon Nov 02 2009 Dave Airlie 2.6.31.5-106 - r600: ring size guesswork fix. * Mon Nov 02 2009 Dave Airlie 2.6.31.5-107 - r600: back that out, thanks to yaneti for testing. * Mon Nov 02 2009 Chuck Ebbert 2.6.31.5-108 - Enable acerhdf driver for fan speed control on Acer Aspire One notebook (#532463) * Mon Nov 02 2009 John W. Linville 2.6.31.5-109 - prism54: remove pci modinfo device table (#447047) myproxy-4.9-3.fc12 ------------------ * Tue Oct 13 2009 Steve Traylen - 4.8-5 - Disable openldap support for el4 only since openldap to old. * Tue Oct 13 2009 Steve Traylen - 4.9-1 - New upstream 4.9. * Tue Oct 13 2009 Steve Traylen - 4.9-3 - Glob on .so.* files to future proof for upgrades. nautilus-2.28.1-2.fc12 ---------------------- * Mon Nov 02 2009 Tomas Bzatek - 2.28.1-2 - Don't crash in infopanel on invalid selection (#531826) nbtk-1.2.0-1.fc12 ----------------- * Tue Nov 03 2009 Peter Robinson 1.2.0-1 - New upstream 1.2.0 stable release plymouth-0.8.0-0.2009.29.09.17.fc12 ----------------------------------- * Tue Nov 03 2009 Ray Strode 0.8.0-0.2009.29.09.17 - Add nash dep for plymouth-set-default-theme publican-1.1-0.fc12 ------------------- * Mon Nov 02 2009 Jeff Fearn 1.1-0 - Fix brew failure. BZ #532383 - Fix distributed sets no packaging properly. python-4Suite-XML-1.0.2-8.fc12 ------------------------------ * Tue Nov 03 2009 Miloslav Trma? - 1.0.2-8 - Fix an expat DoS Related: #531697 python-meh-0.7-1.fc12 --------------------- * Tue Nov 03 2009 Chris Lumens - 0.7-1 - Add a test case framework. - Move src -> meh for ease of test case writing. - Another attempt at making the attrSkipList work (#532612, #532737). qemu-0.11.0-10.fc12 ------------------- * Tue Nov 03 2009 Justin M. Forbes - 2:0.11.0-10 - Default ksm and ksmtuned services on. rhythmbox-0.12.5-8.fc12 ----------------------- * Tue Nov 03 2009 Bastien Nocera 0.12.5-8 - Fix brasero project generation selinux-policy-3.6.32-40.fc12 ----------------------------- * Tue Nov 03 2009 Dan Walsh 3.6.32-40 - Abrt creates lnk_files * Mon Nov 02 2009 Dan Walsh 3.6.32-39 - Allow setroubleshoot-fix to signull user domains telepathy-sofiasip-0.5.18.1-0.9.20091102git.fc12 ------------------------------------------------ * Tue Nov 03 2009 Brian Pepple - 0.5.18.1-0.9.20091102git - Grab git snapshot that fixes sip support to the Fedora asterisk server. texlive-2007-47.fc12 -------------------- * Mon Nov 02 2009 Jindrich Novy 2007-47 - fix post/postun scriptlets (#532466) tog-pegasus-2.9.0-8.fc12 ------------------------ * Mon Nov 02 2009 Vitezlsav Crhonek - 2:2.9.0-8 - Fix wrong multilib flag for ix86 arch totem-2.28.2-2.fc12 ------------------- * Tue Nov 03 2009 Bastien Nocera 2.28.2-2 - Fix YouTube URLs regexp again xdg-user-dirs-0.11-2.fc12 ------------------------- * Tue Nov 03 2009 Matthias Clasen - 0.11-2 - Use fuzzy translations (for Downloads) (#532399) - Fix a typo in README xfwm4-theme-nodoka-0.2-1.fc12 ----------------------------- * Tue Nov 03 2009 Christoph Wickert - 0.2-1 - Update to 0.2 - License changed from GPLv2 to GPLv2+ Summary: Added Packages: 2 Removed Packages: 0 Modified Packages: 31 From dwalsh at redhat.com Wed Nov 4 14:48:23 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 04 Nov 2009 09:48:23 -0500 Subject: conflict between seedit <-> selinux-policy and qstat <-> torque-client In-Reply-To: References: Message-ID: <4AF19437.9020702@redhat.com> On 11/04/2009 08:14 AM, Rudolf Kastl wrote: > Why do those packages have to conflict with each other? > > 1. seedit and selinux-policy-{targeted,mls} -> i dont see a single > file conflicting atleast with the targeted policy... > > 2. qstat and torque-client both provide a qstat binary... is there > anything done to get that resolved upstream? or is it a "conflicts and > forget" scenario? > > from my personal pov conflicts should be resolved instead of just > marked so things can be properly installed in parallel. everything > else looks broken to me. > > kind regards, > Rudolf Kastl > Because seedit getting installed causes selinux-policy-targeted and friends to get screwed up. People installing everything installs accidentally get seedit installed and start reporting weird bugs to the selinux-policy package and a shocked that they are not in the default install. From Quentin at Armitage.org.uk Wed Nov 4 14:51:27 2009 From: Quentin at Armitage.org.uk (Quentin Armitage) Date: Wed, 04 Nov 2009 14:51:27 +0000 Subject: CVS daily checkout seeds Message-ID: <1257346287.2537.4.camel@samson.armitage.org.uk> The CVS daily checkout seeds at http://cvs.fedoraproject.org/webfiles/ don't contain a checkout for F-12. Would it be possible for someone to add that? I have also noted that a checkout seed for F-9 is still included, which seems somewhat superfluous. Many thanks, Quentin From steve.traylen at cern.ch Wed Nov 4 14:51:40 2009 From: steve.traylen at cern.ch (Steve Traylen) Date: Wed, 4 Nov 2009 15:51:40 +0100 Subject: conflict between seedit <-> selinux-policy and qstat <-> torque-client In-Reply-To: References: Message-ID: On Wed, Nov 4, 2009 at 3:07 PM, Jason L Tibbitts III wrote: >>>>>> "RK" == Rudolf Kastl writes: > > RK> 2. qstat and torque-client both provide a qstat binary... is there > RK> anything done to get that resolved upstream? or is it a "conflicts > RK> and forget" scenario? > > This one, I think, should be easily resolvable with alternatives. > Would be happy for an alternatives solution. I have yet another /usr/bin/qstat for a POSIX interface to batch on the way at some point. > Actually I think all but a small number of the currently conflicting > packages could be fixed up pretty easily. ?Currently it doesn't seem > that there's any sort of enforcement outside of the original package > review. > > The way around this is, of course, for someone to spend some time > generating the current list of conflicting packages, proposing > solutions, and working with FESCo in the case that those solutions are > not applied. > > ?- J< > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Steve Traylen From tibbs at math.uh.edu Wed Nov 4 15:08:45 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 04 Nov 2009 09:08:45 -0600 Subject: conflict between seedit <-> selinux-policy and qstat <-> torque-client In-Reply-To: (Steve Traylen's message of "Wed, 4 Nov 2009 15:51:40 +0100") References: Message-ID: >>>>> "ST" == Steve Traylen writes: ST> Would be happy for an alternatives solution. I have yet another ST> /usr/bin/qstat for a POSIX interface to batch on the way at some ST> point. Turns out that the other queuing systems (torque and gridengine) have already renamed their qstat binaries (to qstat-torque and qstat-ge). I would expect that other queuing packages should do the same. - J< From che666 at gmail.com Wed Nov 4 15:11:14 2009 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 4 Nov 2009 16:11:14 +0100 Subject: conflict between seedit <-> selinux-policy and qstat <-> torque-client In-Reply-To: References: Message-ID: 2009/11/4 Jason L Tibbitts III : >>>>>> "ST" == Steve Traylen writes: > > ST> Would be happy for an alternatives solution. I have yet another > ST> /usr/bin/qstat for a POSIX interface to batch on the way at some > ST> point. > > Turns out that the other queuing systems (torque and gridengine) have > already renamed their qstat binaries (to qstat-torque and qstat-ge). ?I > would expect that other queuing packages should do the same. that means that the conflict tags in the qemu and the torque-clients package are invalid. thanks for checking jason! kind regards, Rudolf Kastl > > ?- J< > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From steve.traylen at cern.ch Wed Nov 4 15:17:24 2009 From: steve.traylen at cern.ch (Steve Traylen) Date: Wed, 4 Nov 2009 16:17:24 +0100 Subject: conflict between seedit <-> selinux-policy and qstat <-> torque-client In-Reply-To: References: Message-ID: On Wed, Nov 4, 2009 at 4:11 PM, Rudolf Kastl wrote: > 2009/11/4 Jason L Tibbitts III : >>>>>>> "ST" == Steve Traylen writes: >> >> ST> Would be happy for an alternatives solution. I have yet another >> ST> /usr/bin/qstat for a POSIX interface to batch on the way at some >> ST> point. >> >> Turns out that the other queuing systems (torque and gridengine) have >> already renamed their qstat binaries (to qstat-torque and qstat-ge). ?I >> would expect that other queuing packages should do the same. > Yes a qstat-slurm with qstat as alternative across them. Good news. > that means that the conflict tags in the qemu and the torque-clients > package are invalid. > > thanks for checking jason! > > kind regards, > Rudolf Kastl >> >> ?- J< >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Steve Traylen From mike.cloaked at gmail.com Wed Nov 4 15:23:10 2009 From: mike.cloaked at gmail.com (mike cloaked) Date: Wed, 4 Nov 2009 15:23:10 +0000 Subject: A question about allow_unconfined_mmap_low in f11 amd selinux Message-ID: <3b8e57a80911040723x280abfd0jf6bab04bf4803390@mail.gmail.com> Daniel J Walsh redhat.com> writes: > You can run with SELinux in enforcement. > > mmap_low_allowed is the name of the boolean moving forward. > By "moving forward" do you mean that one can, in f11, reset the original boolean and set boolean mmap_low_allowed instead, in a forthcoming policy update? Or is this a planned change coming for f12 but not yet policy in earlier versions? Thanks -- mike From che666 at gmail.com Wed Nov 4 15:33:42 2009 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 4 Nov 2009 16:33:42 +0100 Subject: conflict between seedit <-> selinux-policy and qstat <-> torque-client In-Reply-To: References: Message-ID: 2009/11/4 Steve Traylen : > On Wed, Nov 4, 2009 at 4:11 PM, Rudolf Kastl wrote: >> 2009/11/4 Jason L Tibbitts III : >>>>>>>> "ST" == Steve Traylen writes: >>> >>> ST> Would be happy for an alternatives solution. I have yet another >>> ST> /usr/bin/qstat for a POSIX interface to batch on the way at some >>> ST> point. >>> >>> Turns out that the other queuing systems (torque and gridengine) have >>> already renamed their qstat binaries (to qstat-torque and qstat-ge). ?I >>> would expect that other queuing packages should do the same. >> > Yes a qstat-slurm with qstat as alternative across them. > Good news. but then the alternatives qstat conflicts with /usr/bin/qstat from the qstat rpm package, doesent it? kind regards, Rudolf Kastl > >> that means that the conflict tags in the qemu and the torque-clients >> package are invalid. >> >> thanks for checking jason! >> >> kind regards, >> Rudolf Kastl >>> >>> ?- J< >>> >>> -- >>> fedora-devel-list mailing list >>> fedora-devel-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-devel-list >>> >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > > > > -- > Steve Traylen > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From steve.traylen at cern.ch Wed Nov 4 15:40:27 2009 From: steve.traylen at cern.ch (Steve Traylen) Date: Wed, 4 Nov 2009 16:40:27 +0100 Subject: conflict between seedit <-> selinux-policy and qstat <-> torque-client In-Reply-To: References: Message-ID: On Wed, Nov 4, 2009 at 4:33 PM, Rudolf Kastl wrote: > 2009/11/4 Steve Traylen : >> On Wed, Nov 4, 2009 at 4:11 PM, Rudolf Kastl wrote: >>> 2009/11/4 Jason L Tibbitts III : >>>>>>>>> "ST" == Steve Traylen writes: >>>> >>>> ST> Would be happy for an alternatives solution. I have yet another >>>> ST> /usr/bin/qstat for a POSIX interface to batch on the way at some >>>> ST> point. >>>> >>>> Turns out that the other queuing systems (torque and gridengine) have >>>> already renamed their qstat binaries (to qstat-torque and qstat-ge). ?I >>>> would expect that other queuing packages should do the same. >>> >> Yes a qstat-slurm with qstat as alternative across them. >> Good news. > > but then the alternatives qstat ?conflicts with /usr/bin/qstat from > the qstat rpm package, doesent it? The torque spec is creating correctly /usr/bin/qstat as a symlink via alternatives mechanism (reading the .spec only, have not checked). The qstat pkg should do the same. Currently while the qstat pkg is creating a file at /usr/bin/qstat then it is conflicting in the RPM sense. Once qstat pkg uses alternatives as well it will no longer conflict. Two packages that contain alternatives for a single file don't conflct in the RPM sense. You can install both pkgs and then select one to be the real /usr/bin/qstat via the alternatives mechanism. Hope that makes sense. Steve > > kind regards, > Rudolf Kastl > >> >>> that means that the conflict tags in the qemu and the torque-clients >>> package are invalid. >>> >>> thanks for checking jason! >>> >>> kind regards, >>> Rudolf Kastl >>>> >>>> ?- J< >>>> >>>> -- >>>> fedora-devel-list mailing list >>>> fedora-devel-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-devel-list >>>> >>> >>> -- >>> fedora-devel-list mailing list >>> fedora-devel-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-devel-list >>> >> >> >> >> -- >> Steve Traylen >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Steve Traylen From che666 at gmail.com Wed Nov 4 15:43:51 2009 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 4 Nov 2009 16:43:51 +0100 Subject: conflict between seedit <-> selinux-policy and qstat <-> torque-client In-Reply-To: References: Message-ID: 2009/11/4 Steve Traylen : > On Wed, Nov 4, 2009 at 4:33 PM, Rudolf Kastl wrote: >> 2009/11/4 Steve Traylen : >>> On Wed, Nov 4, 2009 at 4:11 PM, Rudolf Kastl wrote: >>>> 2009/11/4 Jason L Tibbitts III : >>>>>>>>>> "ST" == Steve Traylen writes: >>>>> >>>>> ST> Would be happy for an alternatives solution. I have yet another >>>>> ST> /usr/bin/qstat for a POSIX interface to batch on the way at some >>>>> ST> point. >>>>> >>>>> Turns out that the other queuing systems (torque and gridengine) have >>>>> already renamed their qstat binaries (to qstat-torque and qstat-ge). ?I >>>>> would expect that other queuing packages should do the same. >>>> >>> Yes a qstat-slurm with qstat as alternative across them. >>> Good news. >> >> but then the alternatives qstat ?conflicts with /usr/bin/qstat from >> the qstat rpm package, doesent it? > > The torque ?spec is creating correctly /usr/bin/qstat as a symlink > via alternatives mechanism (reading the .spec only, have not checked). > > The qstat pkg should do the same. Currently while the qstat > pkg is creating a file at /usr/bin/qstat then it is conflicting in > the RPM sense. Once qstat pkg uses alternatives as well > it will no longer conflict. > > Two packages that contain alternatives for a single file > don't conflct in the RPM sense. You can install both pkgs > and then select one to be the real /usr/bin/qstat via > the alternatives mechanism. > Hope that makes sense. it does with one exception... the qstat rpm is basically "quake stat". so it does something completly different than the qstat of torque or gridengine and hmm the real resolution would maybe be to rename the binary of the qstat package then. kind regards, Rudolf Kastl p.s. thanks everyone for the replies and the effort done already. > > Steve > > >> >> kind regards, >> Rudolf Kastl >> >>> >>>> that means that the conflict tags in the qemu and the torque-clients >>>> package are invalid. >>>> >>>> thanks for checking jason! >>>> >>>> kind regards, >>>> Rudolf Kastl >>>>> >>>>> ?- J< >>>>> >>>>> -- >>>>> fedora-devel-list mailing list >>>>> fedora-devel-list at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/fedora-devel-list >>>>> >>>> >>>> -- >>>> fedora-devel-list mailing list >>>> fedora-devel-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-devel-list >>>> >>> >>> >>> >>> -- >>> Steve Traylen >>> >>> -- >>> fedora-devel-list mailing list >>> fedora-devel-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-devel-list >>> >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > > > > -- > Steve Traylen > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From steve.traylen at cern.ch Wed Nov 4 15:47:13 2009 From: steve.traylen at cern.ch (Steve Traylen) Date: Wed, 4 Nov 2009 16:47:13 +0100 Subject: conflict between seedit <-> selinux-policy and qstat <-> torque-client In-Reply-To: References: Message-ID: On Wed, Nov 4, 2009 at 4:43 PM, Rudolf Kastl wrote: > 2009/11/4 Steve Traylen : >> On Wed, Nov 4, 2009 at 4:33 PM, Rudolf Kastl wrote: >>> 2009/11/4 Steve Traylen : >>>> On Wed, Nov 4, 2009 at 4:11 PM, Rudolf Kastl wrote: >>>>> 2009/11/4 Jason L Tibbitts III : >>>>>>>>>>> "ST" == Steve Traylen writes: >>>>>> >>>>>> ST> Would be happy for an alternatives solution. I have yet another >>>>>> ST> /usr/bin/qstat for a POSIX interface to batch on the way at some >>>>>> ST> point. >>>>>> >>>>>> Turns out that the other queuing systems (torque and gridengine) have >>>>>> already renamed their qstat binaries (to qstat-torque and qstat-ge). ?I >>>>>> would expect that other queuing packages should do the same. >>>>> >>>> Yes a qstat-slurm with qstat as alternative across them. >>>> Good news. >>> >>> but then the alternatives qstat ?conflicts with /usr/bin/qstat from >>> the qstat rpm package, doesent it? >> >> The torque ?spec is creating correctly /usr/bin/qstat as a symlink >> via alternatives mechanism (reading the .spec only, have not checked). >> >> The qstat pkg should do the same. Currently while the qstat >> pkg is creating a file at /usr/bin/qstat then it is conflicting in >> the RPM sense. Once qstat pkg uses alternatives as well >> it will no longer conflict. >> >> Two packages that contain alternatives for a single file >> don't conflct in the RPM sense. You can install both pkgs >> and then select one to be the real /usr/bin/qstat via >> the alternatives mechanism. >> Hope that makes sense. > > it does with one exception... the qstat rpm is basically "quake stat". > so it does something completly different than the qstat of torque or > gridengine and hmm the real resolution would maybe be to rename the > binary of the qstat package then. Yes you are right, the qstat qstat package should rename since that location is reserved by POSIX and anyway torque got there first. > > kind regards, > Rudolf Kastl > > p.s. thanks everyone for the replies and the effort done already. > >> >> Steve >> >> >>> >>> kind regards, >>> Rudolf Kastl >>> >>>> >>>>> that means that the conflict tags in the qemu and the torque-clients >>>>> package are invalid. >>>>> >>>>> thanks for checking jason! >>>>> >>>>> kind regards, >>>>> Rudolf Kastl >>>>>> >>>>>> ?- J< >>>>>> >>>>>> -- >>>>>> fedora-devel-list mailing list >>>>>> fedora-devel-list at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/fedora-devel-list >>>>>> >>>>> >>>>> -- >>>>> fedora-devel-list mailing list >>>>> fedora-devel-list at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/fedora-devel-list >>>>> >>>> >>>> >>>> >>>> -- >>>> Steve Traylen >>>> >>>> -- >>>> fedora-devel-list mailing list >>>> fedora-devel-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-devel-list >>>> >>> >>> -- >>> fedora-devel-list mailing list >>> fedora-devel-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-devel-list >>> >> >> >> >> -- >> Steve Traylen >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Steve Traylen From dwalsh at redhat.com Wed Nov 4 15:49:50 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 04 Nov 2009 10:49:50 -0500 Subject: A question about allow_unconfined_mmap_low in f11 amd selinux In-Reply-To: <3b8e57a80911040723x280abfd0jf6bab04bf4803390@mail.gmail.com> References: <3b8e57a80911040723x280abfd0jf6bab04bf4803390@mail.gmail.com> Message-ID: <4AF1A29E.2090708@redhat.com> On 11/04/2009 10:23 AM, mike cloaked wrote: > Daniel J Walsh redhat.com> writes: > >> You can run with SELinux in enforcement. >> >> mmap_low_allowed is the name of the boolean moving forward. >> > > By "moving forward" do you mean that one can, in f11, reset the > original boolean and set boolean mmap_low_allowed instead, in a > forthcoming policy update? > > Or is this a planned change coming for f12 but not yet policy in > earlier versions? > > Thanks > allow_unconfined_mmap_zero boolean meant to allow unconfined_domains to mmap_zero. vbetool_exec_t and wine_exec_t have this capability without the boolean. We have removed that altogether. Now out of the box NO apps will have the ability to mmap_zero. If you want to run wine or vbetool(Hopefully fixed soon) You will have to set the boolean. All unconfined_domains will continue then also have this access. This access has proven to be a critical security feature, and several kernel/root vulnerabilities will be prevented by turning this boolean off, with the only down side, preventing old windows applications from running by default in wine. (If vbetool is fixed). From dwalsh at redhat.com Wed Nov 4 15:50:29 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 04 Nov 2009 10:50:29 -0500 Subject: A question about allow_unconfined_mmap_low in f11 amd selinux In-Reply-To: <3b8e57a80911040723x280abfd0jf6bab04bf4803390@mail.gmail.com> References: <3b8e57a80911040723x280abfd0jf6bab04bf4803390@mail.gmail.com> Message-ID: <4AF1A2C5.8010008@redhat.com> On 11/04/2009 10:23 AM, mike cloaked wrote: > Daniel J Walsh redhat.com> writes: > >> You can run with SELinux in enforcement. >> >> mmap_low_allowed is the name of the boolean moving forward. >> > > By "moving forward" do you mean that one can, in f11, reset the > original boolean and set boolean mmap_low_allowed instead, in a > forthcoming policy update? > > Or is this a planned change coming for f12 but not yet policy in > earlier versions? > > Thanks > We have setroubleshoot plugins that explain exactly to the users what they need to do to turn make their wine apps run. From orion at cora.nwra.com Wed Nov 4 15:57:29 2009 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 04 Nov 2009 08:57:29 -0700 Subject: rawhide report: 20091104 changes - excluding noarch packages In-Reply-To: <20091104144721.GA2687@releng2.fedora.phx.redhat.com> References: <20091104144721.GA2687@releng2.fedora.phx.redhat.com> Message-ID: <4AF1A469.7000108@cora.nwra.com> On 11/04/2009 07:47 AM, Rawhide Report wrote: > Compose started at Wed Nov 4 08:15:08 UTC 2009 > > Broken deps for ppc64 > ---------------------------------------------------------- > eclipse-photran-5.0.0-0.3.200910081739.fc12.noarch requires eclipse-cdt>= 1:6.0 > Is there any way to exclude a noarch package from certain arches? -- 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 overholt at redhat.com Wed Nov 4 16:04:55 2009 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 4 Nov 2009 11:04:55 -0500 Subject: rawhide report: 20091104 changes - excluding noarch packages In-Reply-To: <4AF1A469.7000108@cora.nwra.com> References: <20091104144721.GA2687@releng2.fedora.phx.redhat.com> <4AF1A469.7000108@cora.nwra.com> Message-ID: <20091104160455.GH2371@redhat.com> * Orion Poplawski [2009-11-04 10:58]: > On 11/04/2009 07:47 AM, Rawhide Report wrote: > >Compose started at Wed Nov 4 08:15:08 UTC 2009 > > > >Broken deps for ppc64 > >---------------------------------------------------------- > > eclipse-photran-5.0.0-0.3.200910081739.fc12.noarch requires eclipse-cdt>= 1:6.0 > > > > Is there any way to exclude a noarch package from certain arches? ExcludeArch From orion at cora.nwra.com Wed Nov 4 16:06:34 2009 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 04 Nov 2009 09:06:34 -0700 Subject: rawhide report: 20091104 changes - excluding noarch packages In-Reply-To: <20091104160455.GH2371@redhat.com> References: <20091104144721.GA2687@releng2.fedora.phx.redhat.com> <4AF1A469.7000108@cora.nwra.com> <20091104160455.GH2371@redhat.com> Message-ID: <4AF1A68A.8090108@cora.nwra.com> On 11/04/2009 09:04 AM, Andrew Overholt wrote: > * Orion Poplawski [2009-11-04 10:58]: >> On 11/04/2009 07:47 AM, Rawhide Report wrote: >>> Compose started at Wed Nov 4 08:15:08 UTC 2009 >>> >>> Broken deps for ppc64 >>> ---------------------------------------------------------- >>> eclipse-photran-5.0.0-0.3.200910081739.fc12.noarch requires eclipse-cdt>= 1:6.0 >>> >> >> Is there any way to exclude a noarch package from certain arches? > > ExcludeArch > I did ExcludeArch: ppc64 and submitted a build, but it attempted to build it on a ppc64 machine: http://koji.fedoraproject.org/koji/taskinfo?taskID=1787949 Should I just keep retrying until I get another arch? -- 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 steve.traylen at cern.ch Wed Nov 4 16:18:00 2009 From: steve.traylen at cern.ch (Steve Traylen) Date: Wed, 4 Nov 2009 17:18:00 +0100 Subject: rawhide report: 20091104 changes - excluding noarch packages In-Reply-To: <20091104160455.GH2371@redhat.com> References: <20091104144721.GA2687@releng2.fedora.phx.redhat.com> <4AF1A469.7000108@cora.nwra.com> <20091104160455.GH2371@redhat.com> Message-ID: On Wed, Nov 4, 2009 at 5:04 PM, Andrew Overholt wrote: > * Orion Poplawski [2009-11-04 10:58]: >> On 11/04/2009 07:47 AM, Rawhide Report wrote: >> >Compose started at Wed Nov ?4 08:15:08 UTC 2009 >> > >> >Broken deps for ppc64 >> >---------------------------------------------------------- >> > ? ? eclipse-photran-5.0.0-0.3.200910081739.fc12.noarch requires eclipse-cdt>= 1:6.0 >> > >> >> Is there any way to exclude a noarch package from certain arches? > > ExcludeArch > Maybe I am missing something here but if the architecture matters it's not a a noarch package by definition. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Steve Traylen From overholt at redhat.com Wed Nov 4 16:22:02 2009 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 4 Nov 2009 11:22:02 -0500 Subject: rawhide report: 20091104 changes - excluding noarch packages In-Reply-To: References: <20091104144721.GA2687@releng2.fedora.phx.redhat.com> <4AF1A469.7000108@cora.nwra.com> <20091104160455.GH2371@redhat.com> Message-ID: <20091104162202.GJ2371@redhat.com> * Steve Traylen [2009-11-04 11:18]: > On Wed, Nov 4, 2009 at 5:04 PM, Andrew Overholt wrote: > > * Orion Poplawski [2009-11-04 10:58]: > >> On 11/04/2009 07:47 AM, Rawhide Report wrote: > >> >Compose started at Wed Nov ?4 08:15:08 UTC 2009 > >> > > >> >Broken deps for ppc64 > >> >---------------------------------------------------------- > >> > ? ? eclipse-photran-5.0.0-0.3.200910081739.fc12.noarch requires eclipse-cdt>= 1:6.0 > >> > > >> > >> Is there any way to exclude a noarch package from certain arches? > > > > ExcludeArch > > > Maybe I am missing something here but if the architecture matters it's not a > a noarch package by definition. The architecture of a dependency matters. In the past, we've made packages such as this arch-dependent. Andrew From fedora at matbooth.co.uk Wed Nov 4 16:21:58 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Wed, 4 Nov 2009 16:21:58 +0000 Subject: rawhide report: 20091104 changes - excluding noarch packages In-Reply-To: References: <20091104144721.GA2687@releng2.fedora.phx.redhat.com> <4AF1A469.7000108@cora.nwra.com> <20091104160455.GH2371@redhat.com> Message-ID: <9497e9990911040821s6700f8c3i7e7a6f110be29305@mail.gmail.com> 2009/11/4 Steve Traylen : > On Wed, Nov 4, 2009 at 5:04 PM, Andrew Overholt wrote: >> * Orion Poplawski [2009-11-04 10:58]: >>> On 11/04/2009 07:47 AM, Rawhide Report wrote: >>> >Compose started at Wed Nov ?4 08:15:08 UTC 2009 >>> > >>> >Broken deps for ppc64 >>> >---------------------------------------------------------- >>> > ? ? eclipse-photran-5.0.0-0.3.200910081739.fc12.noarch requires eclipse-cdt>= 1:6.0 >>> > >>> >>> Is there any way to exclude a noarch package from certain arches? >> >> ExcludeArch >> > Maybe I am missing something here but if the architecture matters it's not a > a noarch package by definition. > It's a Java package, so it *is* effectively noarch, but it depends on an archful package that excludes ppc64. -- Mat Booth A: Because it destroys the order of the conversation. Q: Why shouldn't you do it? A: Posting your reply above the original message. Q: What is top-posting? From mschwendt at gmail.com Wed Nov 4 16:31:30 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 4 Nov 2009 17:31:30 +0100 Subject: rawhide report: 20091104 changes - excluding noarch packages In-Reply-To: <4AF1A68A.8090108@cora.nwra.com> References: <20091104144721.GA2687@releng2.fedora.phx.redhat.com> <4AF1A469.7000108@cora.nwra.com> <20091104160455.GH2371@redhat.com> <4AF1A68A.8090108@cora.nwra.com> Message-ID: <20091104173130.1ea87e06@faldor.intranet> On Wed, 04 Nov 2009 09:06:34 -0700, Orion wrote: > On 11/04/2009 09:04 AM, Andrew Overholt wrote: > > * Orion Poplawski [2009-11-04 10:58]: > >> On 11/04/2009 07:47 AM, Rawhide Report wrote: > >>> Compose started at Wed Nov 4 08:15:08 UTC 2009 > >>> > >>> Broken deps for ppc64 > >>> ---------------------------------------------------------- > >>> eclipse-photran-5.0.0-0.3.200910081739.fc12.noarch requires eclipse-cdt>= 1:6.0 > >>> > >> > >> Is there any way to exclude a noarch package from certain arches? > > > > ExcludeArch > > > > I did ExcludeArch: ppc64 and submitted a build, but it attempted to > build it on a ppc64 machine: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1787949 > > Should I just keep retrying until I get another arch? No. If it cannot be built on ppc64, it's not noarch, but arch-specific. However, the previous response was correct. You can use ExcludeArch for noarch packages, which can be built on an arbitrary arch, but would suffer from missing install-time dependencies on specific archs. From martind1111 at gmail.com Wed Nov 4 16:35:51 2009 From: martind1111 at gmail.com (Martin Dubuc) Date: Wed, 4 Nov 2009 11:35:51 -0500 Subject: rfkill Message-ID: <7a0107ba0911040835u3dc44b12m6015fde3e17f2b1f@mail.gmail.com> Addition of a working version of rfkill in Fedora 12 has been really welcomed. In my application, I would like to monitor the RF kill switch to detect when user enables/disables Wi-Fi on the system. I thought I could use the rfkill executable to do this, using "rfkill event", piping the output using popen in my process. However, rfkill outputs the events on standard output, but does not flush every time it reports an event. When I perform fgets to get the events, I get nothing. I am wondering if it would be possible to add a fflush on stdout when events are reported on stdout inside rfkill. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jreiser at bitwagon.com Wed Nov 4 16:38:24 2009 From: jreiser at bitwagon.com (John Reiser) Date: Wed, 04 Nov 2009 08:38:24 -0800 Subject: A question about allow_unconfined_mmap_low in f11 amd selinux In-Reply-To: <4AF1A29E.2090708@redhat.com> References: <3b8e57a80911040723x280abfd0jf6bab04bf4803390@mail.gmail.com> <4AF1A29E.2090708@redhat.com> Message-ID: <4AF1AE00.5010204@bitwagon.com> >>> mmap_low_allowed is the name of the boolean moving forward. > This access has proven to be a critical security feature, > and several kernel/root vulnerabilities will be prevented > by turning this boolean off, with the only down side, > preventing old windows applications from running by default in wine. > (If vbetool is fixed). It is a mistake to believe "the only down side is preventing old [W]indows applications from running by default in wine." The claim is not true. I have three applications that fundamentally fail to work if mmap(0,PAGE_SIZE,,MAP_FIXED,,) is disallowed. Addressing memory at address 0 is fundamental to the way that they work. Using "any other page" would totally prevent two of the apps from working at all, and would severely cripple the third. They are not "old [W]indows apps". They are every-day utilities and development tools written for Linux, and I object to them being broken. The kernel could remove 99.9% of the vulnerability, with no dynamic cost to processes that don't use page 0, by: 1. Reduce STACK_TOP by one page, and reserve the corresponding virtual page frame. 2. If a process does mmap(0,,,MAP_FIXED,,) then turn on the process status bit which forces "slow path" for kernel entry via system call from that process. In the slow path, check for a mapping at page 0 and if so then move that mapping to the reserved page at STACK_TOP, and turn off the mapping at page 0. Reverse the substitution when returning from the syscall. 3. Add the necessary check in the trap handler for copy_{to,from}_user() to handle intended kernel access to page 0 (including I/O) by substituting the reserved page instead. This would allow mmap(0,,,MAP_FIXED,,) yet still protect all synchronous kernel execution. The only remaining window of vulnerability is interrupt handlers. If an interrupt handler is touching *any* user address space then the problems are more serious than mmap(0). -- From bnocera at redhat.com Wed Nov 4 16:48:14 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Wed, 04 Nov 2009 16:48:14 +0000 Subject: rfkill In-Reply-To: <7a0107ba0911040835u3dc44b12m6015fde3e17f2b1f@mail.gmail.com> References: <7a0107ba0911040835u3dc44b12m6015fde3e17f2b1f@mail.gmail.com> Message-ID: <1257353294.23167.153.camel@localhost.localdomain> On Wed, 2009-11-04 at 11:35 -0500, Martin Dubuc wrote: > Addition of a working version of rfkill in Fedora 12 has been really > welcomed. In my application, I would like to monitor the RF kill > switch to detect when user enables/disables Wi-Fi on the system. I > thought I could use the rfkill executable to do this, using "rfkill > event", piping the output using popen in my process. However, rfkill > outputs the events on standard output, but does not flush every time > it reports an event. When I perform fgets to get the events, I get > nothing. I am wondering if it would be possible to add a fflush on > stdout when events are reported on stdout inside rfkill. You're probably better off monitoring /dev/rfkill yourself directly (for now[1]), there's example code in gnome-bluetooth, look at lib/bluetooth-killswitch.c. You'd basically just need to change the type of killswitch you're monitoring. Cheers [1]: We'd probably want a D-Busified rfkilld in the future. From rjones at redhat.com Wed Nov 4 16:50:30 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 4 Nov 2009 16:50:30 +0000 Subject: Ubuntu shows updates / security updates on shell logins Message-ID: <20091104165030.GA25940@amd.home.annexia.org> Newly installed Ubuntu 9.10, when you log in over ssh you may see: 34 packages can be updated. 10 updates are security updates. I think this is a nice feature, because many administrators will log in to servers remotely over ssh and never see the graphical indications from packagekit et al. Actually I was trying to work out how it's implemented. The text goes into /etc/motd, and as near as I can tell, the Ubuntu "update-manager" (roughly equivalent of PackageKit) rewrites it whenever packages become available or get installed. Is this something that PackageKit could also do? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 eparis at redhat.com Wed Nov 4 16:50:31 2009 From: eparis at redhat.com (Eric Paris) Date: Wed, 04 Nov 2009 11:50:31 -0500 Subject: A question about allow_unconfined_mmap_low in f11 amd selinux In-Reply-To: <4AF1AE00.5010204@bitwagon.com> References: <3b8e57a80911040723x280abfd0jf6bab04bf4803390@mail.gmail.com> <4AF1A29E.2090708@redhat.com> <4AF1AE00.5010204@bitwagon.com> Message-ID: <1257353431.2891.266.camel@dhcp231-106.rdu.redhat.com> On Wed, 2009-11-04 at 08:38 -0800, John Reiser wrote: > The kernel could remove 99.9% of the vulnerability, with > no dynamic cost to processes that don't use page 0, by: > 1. Reduce STACK_TOP by one page, and reserve the corresponding > virtual page frame. > 2. If a process does mmap(0,,,MAP_FIXED,,) then turn on the > process status bit which forces "slow path" for kernel entry > via system call from that process. In the slow path, check for > a mapping at page 0 and if so then move that mapping to the > reserved page at STACK_TOP, and turn off the mapping at page 0. > Reverse the substitution when returning from the syscall. > 3. Add the necessary check in the trap handler for > copy_{to,from}_user() to handle intended kernel access to page 0 > (including I/O) by substituting the reserved page instead. > > This would allow mmap(0,,,MAP_FIXED,,) yet still protect all > synchronous kernel execution. The only remaining window of > vulnerability is interrupt handlers. If an interrupt handler > is touching *any* user address space then the problems are more > serious than mmap(0). That's an interesting thought, do you think you could code something like that and post it to lkml? I certainly might get some traction. -Eric From rjones at redhat.com Wed Nov 4 16:55:24 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 4 Nov 2009 16:55:24 +0000 Subject: rawhide report: 20091104 changes - excluding noarch packages In-Reply-To: <4AF1A68A.8090108@cora.nwra.com> References: <20091104144721.GA2687@releng2.fedora.phx.redhat.com> <4AF1A469.7000108@cora.nwra.com> <20091104160455.GH2371@redhat.com> <4AF1A68A.8090108@cora.nwra.com> Message-ID: <20091104165524.GB25940@amd.home.annexia.org> On Wed, Nov 04, 2009 at 09:06:34AM -0700, Orion Poplawski wrote: > I did ExcludeArch: ppc64 and submitted a build, but it attempted to > build it on a ppc64 machine: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1787949 > > Should I just keep retrying until I get another arch? Koji / RPM doesn't understand this case. It occurs for Fedora MinGW too: if we want to run tests, we need Wine. Wine is an x86-only package, but all mingw32-* packages are built as noarch. It's pot-luck whether they get an x86 builder or not. As a sad result of this, we cannot run any tests in mingw32-* packages. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw From rjones at redhat.com Wed Nov 4 16:56:37 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 4 Nov 2009 16:56:37 +0000 Subject: rawhide report: 20091104 changes - excluding noarch packages In-Reply-To: References: <20091104144721.GA2687@releng2.fedora.phx.redhat.com> <4AF1A469.7000108@cora.nwra.com> <20091104160455.GH2371@redhat.com> Message-ID: <20091104165637.GC25940@amd.home.annexia.org> On Wed, Nov 04, 2009 at 05:18:00PM +0100, Steve Traylen wrote: > Maybe I am missing something here but if the architecture matters it's not a > a noarch package by definition. No. "noarch" describes the contents of the final RPM. But it doesn't take into account that arch-specific stuff might be required to build the package. This is a shortcoming of RPM / Koji -- see my other post in this thread. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 skvidal at fedoraproject.org Wed Nov 4 16:57:29 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 4 Nov 2009 11:57:29 -0500 (EST) Subject: Ubuntu shows updates / security updates on shell logins In-Reply-To: <20091104165030.GA25940@amd.home.annexia.org> References: <20091104165030.GA25940@amd.home.annexia.org> Message-ID: On Wed, 4 Nov 2009, Richard W.M. Jones wrote: > Newly installed Ubuntu 9.10, when you log in over ssh you may see: > > 34 packages can be updated. > 10 updates are security updates. > > I think this is a nice feature, because many administrators will log > in to servers remotely over ssh and never see the graphical > indications from packagekit et al. Administrators should not be relying on logging into a machine to know what is in need of updates. We have multiple mechanisms to notify admins about boxes needing updates. Adding it to the MOTD seems like an odd choice. > > Actually I was trying to work out how it's implemented. The text goes > into /etc/motd, and as near as I can tell, the Ubuntu "update-manager" > (roughly equivalent of PackageKit) rewrites it whenever packages > become available or get installed. Is this something that PackageKit > could also do? Look at yum-cron and how it is can send emails or other events when updates need to be applied. -sv From tibbs at math.uh.edu Wed Nov 4 17:02:11 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 04 Nov 2009 11:02:11 -0600 Subject: Ubuntu shows updates / security updates on shell logins In-Reply-To: <20091104165030.GA25940@amd.home.annexia.org> (Richard W. M. Jones's message of "Wed, 4 Nov 2009 16:50:30 +0000") References: <20091104165030.GA25940@amd.home.annexia.org> Message-ID: >>>>> "RWMJ" == Richard W M Jones writes: RWMJ> Newly installed Ubuntu 9.10, when you log in over ssh you may see: RWMJ> 34 packages can be updated. 10 updates are security updates. What a terrible idea. My users, who are welcome to ssh into a number of machines at my site, have no need to see that information. RWMJ> Actually I was trying to work out how it's implemented. Get information, append to /etc/motd. You could parse yum output in a cron job if you really wanted it. It would almost certainly be better to mail that information, though, if the admin really wants it. I often go some time without actually having to ssh into many of my server. - J< From rjones at redhat.com Wed Nov 4 17:04:33 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 4 Nov 2009 17:04:33 +0000 Subject: Ubuntu shows updates / security updates on shell logins In-Reply-To: References: <20091104165030.GA25940@amd.home.annexia.org> Message-ID: <20091104170433.GD25940@amd.home.annexia.org> On Wed, Nov 04, 2009 at 11:57:29AM -0500, Seth Vidal wrote: > On Wed, 4 Nov 2009, Richard W.M. Jones wrote: >> Newly installed Ubuntu 9.10, when you log in over ssh you may see: >> >> 34 packages can be updated. >> 10 updates are security updates. >> >> I think this is a nice feature, because many administrators will log >> in to servers remotely over ssh and never see the graphical >> indications from packagekit et al. > > Administrators should not be relying on logging into a machine to know > what is in need of updates. We have multiple mechanisms to notify admins > about boxes needing updates. Adding it to the MOTD seems like an odd > choice. Perhaps in the perfect world of Big Enterprise Installs, but I can assure in the real world that sysadmins do log in at ad hoc intervals to check if anything needs updating. In any case, what is the downside to displaying this? Your logging/ email mechanisms might have gone wrong, and this would be an indication that scheduled updates didn't happen. > Look at yum-cron and how it is can send emails or other events when > updates need to be applied. I'll take a look. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw From lemenkov at gmail.com Wed Nov 4 17:09:31 2009 From: lemenkov at gmail.com (Peter Lemenkov) Date: Wed, 4 Nov 2009 20:09:31 +0300 Subject: rawhide report: 20091104 changes - excluding noarch packages In-Reply-To: <4AF1A469.7000108@cora.nwra.com> References: <20091104144721.GA2687@releng2.fedora.phx.redhat.com> <4AF1A469.7000108@cora.nwra.com> Message-ID: 2009/11/4 Orion Poplawski : > Is there any way to exclude a noarch package from certain arches? If it does depends on arch, then it isn't a noarch. -- With best regards, Peter Lemenkov. From rjune at bravegnuworld.com Wed Nov 4 17:11:19 2009 From: rjune at bravegnuworld.com (Richard June) Date: Wed, 4 Nov 2009 11:11:19 -0600 Subject: Ubuntu shows updates / security updates on shell logins In-Reply-To: References: <20091104165030.GA25940@amd.home.annexia.org> Message-ID: On Wed, Nov 4, 2009 at 11:02 AM, Jason L Tibbitts III wrote: >>>>>> "RWMJ" == Richard W M Jones writes: > > RWMJ> Newly installed Ubuntu 9.10, when you log in over ssh you may see: > RWMJ> 34 packages can be updated. 10 updates are security updates. > > What a terrible idea. ?My users, who are welcome to ssh into a number of > machines at my site, have no need to see that information. It's a good idea for one off jobs where the primary user is also the admin, but not so good for shared systems. Personally I think a better plan would be to display that information *only* if the user is flagged as an administrator, group root, wheel, etc. > RWMJ> Actually I was trying to work out how it's implemented. > > Get information, append to /etc/motd. ?You could parse yum output in a > cron job if you really wanted it. ?It would almost certainly be better > to mail that information, though, if the admin really wants it. ?I often > go some time without actually having to ssh into many of my server. > > ?- J< > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Richard June Orion Technology Solutions 574.933.1576 http://www.oriontechnologysolutions.com From che666 at gmail.com Wed Nov 4 17:17:52 2009 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 4 Nov 2009 18:17:52 +0100 Subject: conflict between seedit <-> selinux-policy and qstat <-> torque-client In-Reply-To: References: Message-ID: bug against qstat filed: https://bugzilla.redhat.com/show_bug.cgi?id=533016 as for seedit: i am going to investigate it further. kind regards, Rudolf Kastl From paul at city-fan.org Wed Nov 4 17:20:37 2009 From: paul at city-fan.org (Paul Howarth) Date: Wed, 04 Nov 2009 17:20:37 +0000 Subject: rawhide report: 20091104 changes - excluding noarch packages In-Reply-To: References: <20091104144721.GA2687@releng2.fedora.phx.redhat.com> <4AF1A469.7000108@cora.nwra.com> Message-ID: <4AF1B7E5.5040407@city-fan.org> On 04/11/09 17:09, Peter Lemenkov wrote: > 2009/11/4 Orion Poplawski: > >> Is there any way to exclude a noarch package from certain arches? > > If it does depends on arch, then it isn't a noarch. So a noarch script package that depends on its arch script interpreter (e.g. all python and perl packages) should be arch packages? Paul. From jkeating at redhat.com Wed Nov 4 17:39:06 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 04 Nov 2009 09:39:06 -0800 Subject: rawhide report: 20091104 changes - excluding noarch packages In-Reply-To: <4AF1B7E5.5040407@city-fan.org> References: <20091104144721.GA2687@releng2.fedora.phx.redhat.com> <4AF1A469.7000108@cora.nwra.com> <4AF1B7E5.5040407@city-fan.org> Message-ID: <1257356346.2215.16.camel@localhost.localdomain> On Wed, 2009-11-04 at 17:20 +0000, Paul Howarth wrote: > So a noarch script package that depends on its arch script interpreter > (e.g. all python and perl packages) should be arch packages? > And bash for that matter. This is a known problem with rpm/koji. The distinction between "noarch" and "arch specific" is a difficult one to draw. We do have support in our compose tools to look up an srpm and determine whether or not a noarch rpm has Exclude/ExclusiveArch settings (since that data doesn't propagate to the noarch rpm itself). What we don't have just yet is code in koji to detect a noarch build that has Exclude/ExclusiveArch settings and avoid sending said build to one of those arches. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Wed Nov 4 18:12:10 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 04 Nov 2009 19:12:10 +0100 Subject: rawhide report: 20091104 changes References: <20091104144721.GA2687@releng2.fedora.phx.redhat.com> Message-ID: Rawhide Report wrote: > Broken deps for ppc64 > ---------------------------------------------------------- > eclipse-photran-5.0.0-0.3.200910081739.fc12.noarch requires eclipse-cdt >= > 1:6.0 [snip] > eclipse-photran-5.0.0-0.3.200910081739.fc12 > ------------------------------------------- > * Tue Nov 03 2009 Orion Poplawski - > 5.0.0-0.3.200910081739 - Make noarch Thank you for having introduced this broken dependency with this completely unnecessary change so late in F12's cycle. It was looking so boring without any broken dependencies! Now seriously, this dependency will normally be satisfied by the 32-bit ppc package (we don't really support pure ppc64 installations), so it's not a big deal, but why was this change made at this point in time? Making a package noarch is not a critical bugfix! Kevin Kofler From ikem.krueger at googlemail.com Wed Nov 4 18:18:03 2009 From: ikem.krueger at googlemail.com (Ikem Krueger) Date: Wed, 4 Nov 2009 18:18:03 +0000 Subject: Kernel using LZMA compression In-Reply-To: <4AEC97EA.8070603@bitwagon.com> References: <4AEC97EA.8070603@bitwagon.com> Message-ID: > The executive summary is: Xen does not let a kernel boot itself, because mimicking bare hardware is too tedious (and pointless.) Instead, Xen instantiates an instance of a kernel into the Xen environment. To do this instantiation, Xen does its own decompression, so Xen must know everything about the compression. I know you're right. But that sound stupid to me: The kernel itself has routines built-in for decompression. Why isn't it enough to let Xen use the same routines for decompression as the kernel? From bmr at redhat.com Wed Nov 4 18:24:17 2009 From: bmr at redhat.com (Bryn M. Reeves) Date: Wed, 04 Nov 2009 18:24:17 +0000 Subject: Kernel using LZMA compression In-Reply-To: References: <4AEC97EA.8070603@bitwagon.com> Message-ID: <4AF1C6D1.5060202@redhat.com> On 11/04/2009 06:18 PM, Ikem Krueger wrote: >> The executive summary is: Xen does not let a kernel boot itself, >> because mimicking bare hardware is too tedious (and pointless.) >> Instead, Xen instantiates an instance of a kernel into the Xen >> environment. To do this instantiation, Xen does its own >> decompression, so Xen must know everything about the compression. > > I know you're right. But that sound stupid to me: The kernel itself > has routines built-in for decompression. Why isn't it enough to let > Xen use the same routines for decompression as the kernel? > I am reading between the lines here (I have never looked at this stuff in Xen) but I would assume it's for the reason given above. The kernel's own decompression routines must run very early on in the boot process - well before the first line of C code runs and while the CPU (on x86) is still running in legacy real addressing mode (right after the handover from the bootloader and relocation of the kernel image). It's emulating this early-boot environment that is tedious and pointless and being able to use the in-kernel decompresser is not sufficient motivation to go down that route. Regards, Bryn. From bjorn at xn--rombobjrn-67a.se Wed Nov 4 18:31:13 2009 From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-15?q?Bj=F6rn_Persson?=) Date: Wed, 4 Nov 2009 19:31:13 +0100 Subject: rawhide report: 20091104 changes - excluding noarch packages In-Reply-To: <1257356346.2215.16.camel@localhost.localdomain> References: <20091104144721.GA2687@releng2.fedora.phx.redhat.com> <4AF1B7E5.5040407@city-fan.org> <1257356346.2215.16.camel@localhost.localdomain> Message-ID: <200911041931.31822.bjorn@xn--rombobjrn-67a.se> Jesse Keating wrote: > On Wed, 2009-11-04 at 17:20 +0000, Paul Howarth wrote: > > So a noarch script package that depends on its arch script interpreter > > (e.g. all python and perl packages) should be arch packages? > > And bash for that matter. Unless the interpreter is available on all of the architectures that Fedora supports, which Python, Perl and Bash are as far as I can see. Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From ikem.krueger at googlemail.com Wed Nov 4 18:37:29 2009 From: ikem.krueger at googlemail.com (Ikem Krueger) Date: Wed, 4 Nov 2009 18:37:29 +0000 Subject: Kernel using LZMA compression In-Reply-To: <4AF1C6D1.5060202@redhat.com> References: <4AEC97EA.8070603@bitwagon.com> <4AF1C6D1.5060202@redhat.com> Message-ID: > I am reading between the lines here (I have never looked at this stuff in Xen) but I would assume it's for the reason given above. The kernel's own decompression routines must run very early on in the boot process - well before the first line of C code runs and while the CPU (on x86) is still running in legacy real addressing mode (right after the handover from the bootloader and relocation of the kernel image). Ok. Sounds plausible. How is it to seperate the routines? Can they brought from "legacy mode" to "real mode"? From notting at redhat.com Wed Nov 4 18:38:36 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 4 Nov 2009 13:38:36 -0500 Subject: conflict between seedit <-> selinux-policy and qstat <-> torque-client In-Reply-To: <4AF19437.9020702@redhat.com> References: <4AF19437.9020702@redhat.com> Message-ID: <20091104183836.GC11436@nostromo.devel.redhat.com> > Because seedit getting installed causes selinux-policy-targeted and friends to get screwed up. That sounds like a reason to not ship seedit. Am I missing something? Bill From kevin.kofler at chello.at Wed Nov 4 18:38:04 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 04 Nov 2009 19:38:04 +0100 Subject: Ubuntu shows updates / security updates on shell logins References: <20091104165030.GA25940@amd.home.annexia.org> Message-ID: Richard June wrote: > It's a good idea for one off jobs where the primary user is also the > admin, but not so good for shared systems. Personally I think a better > plan would be to display that information *only* if the user is > flagged as an administrator, group root, wheel, etc. It's actually a security risk to display this to non-admin users. It's like putting a sticker on your door saying "This door is not locked because my keyhole is not working." Kevin Kofler From nushio at fedoraproject.org Wed Nov 4 18:49:39 2009 From: nushio at fedoraproject.org (Juan Rodriguez) Date: Wed, 4 Nov 2009 12:49:39 -0600 Subject: Ubuntu shows updates / security updates on shell logins In-Reply-To: References: <20091104165030.GA25940@amd.home.annexia.org> Message-ID: On Wed, Nov 4, 2009 at 12:38 PM, Kevin Kofler wrote: > It's actually a security risk to display this to non-admin users. It's like > putting a sticker on your door saying "This door is not locked because my > keyhole is not working." > By that logic, Packagekit displaying that to endusers is the same thing. I like the idea of showing that on admin login. I think its useful for server administrators. -- Ing. Juan M. Rodriguez Moreno Desarrollador de Sistemas Abiertos Sitio: http://proyectofedora.org/mexico -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Wed Nov 4 18:50:31 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 04 Nov 2009 10:50:31 -0800 Subject: rawhide report: 20091104 changes - excluding noarch packages In-Reply-To: <200911041931.31822.bjorn@xn--rombobjrn-67a.se> References: <20091104144721.GA2687@releng2.fedora.phx.redhat.com> <4AF1B7E5.5040407@city-fan.org> <1257356346.2215.16.camel@localhost.localdomain> <200911041931.31822.bjorn@xn--rombobjrn-67a.se> Message-ID: <1257360631.2215.19.camel@localhost.localdomain> On Wed, 2009-11-04 at 19:31 +0100, Bj?rn Persson wrote: > > Unless the interpreter is available on all of the architectures that Fedora > supports, which Python, Perl and Bash are as far as I can see. Until we add a new arch. But that still leaves things like java, mono, ruby, etc as problem areas where "noarch" may not actually be "noarch". -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From ajax at redhat.com Wed Nov 4 18:51:47 2009 From: ajax at redhat.com (Adam Jackson) Date: Wed, 04 Nov 2009 13:51:47 -0500 Subject: A question about allow_unconfined_mmap_low in f11 amd selinux In-Reply-To: <4AF1AE00.5010204@bitwagon.com> References: <3b8e57a80911040723x280abfd0jf6bab04bf4803390@mail.gmail.com> <4AF1A29E.2090708@redhat.com> <4AF1AE00.5010204@bitwagon.com> Message-ID: <1257360707.7251.345.camel@atropine.boston.devel.redhat.com> On Wed, 2009-11-04 at 08:38 -0800, John Reiser wrote: > I have three applications that fundamentally fail to work > if mmap(0,PAGE_SIZE,,MAP_FIXED,,) is disallowed. Addressing > memory at address 0 is fundamental to the way that they work. > Using "any other page" would totally prevent two of the apps > from working at all, and would severely cripple the third. > They are not "old [W]indows apps". They are every-day utilities > and development tools written for Linux, and I object to them > being broken. You're saying you have apps that rely on being able to dereference the zero page, and _not_ because the processor mode requires it? I thought the vax died long ago. > The kernel could remove 99.9% of the vulnerability, with > no dynamic cost to processes that don't use page 0, by: > 1. Reduce STACK_TOP by one page, and reserve the corresponding > virtual page frame. > 2. If a process does mmap(0,,,MAP_FIXED,,) then turn on the > process status bit which forces "slow path" for kernel entry > via system call from that process. In the slow path, check for > a mapping at page 0 and if so then move that mapping to the > reserved page at STACK_TOP, and turn off the mapping at page 0. > Reverse the substitution when returning from the syscall. > 3. Add the necessary check in the trap handler for > copy_{to,from}_user() to handle intended kernel access to page 0 > (including I/O) by substituting the reserved page instead. > > This would allow mmap(0,,,MAP_FIXED,,) yet still protect all > synchronous kernel execution. The only remaining window of > vulnerability is interrupt handlers. If an interrupt handler > is touching *any* user address space then the problems are more > serious than mmap(0). The problem is that the address space doesn't change when in the interrupt handler; the zero page will still be mapped, so if there's a bug in the interrupt handler that would normally oops, well, now it won't. Yes, bugs like that _have_ been found. Pretty sure they've been exploited in the wild too. You could probably fix this by checking if the zero page is mapped at any context switch into the kernel (including interrupt) and doing mprotect(PROT_NONE) on it if so. This adds a small but more or less fixed overhead on every interrupt, plus a fairly high overhead when an interrupt fires while the zero-mapping process is running. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From che666 at gmail.com Wed Nov 4 18:52:08 2009 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 4 Nov 2009 19:52:08 +0100 Subject: conflict between seedit <-> selinux-policy and qstat <-> torque-client In-Reply-To: <20091104183836.GC11436@nostromo.devel.redhat.com> References: <4AF19437.9020702@redhat.com> <20091104183836.GC11436@nostromo.devel.redhat.com> Message-ID: 2009/11/4 Bill Nottingham : >> Because seedit getting installed causes selinux-policy-targeted and friends to get screwed up. > > That sounds like a reason to not ship seedit. Am I missing something? on first start of the seedit-gui there is a popup: "you have to initialize before using selinux policy editor. and policy is replaced with seedits original policy. if ok press initialize button" there is no cancel button... but you can close that popup window. actually this looks like a bad idea and terrible design to me. why do i have to replace my workstations default policy to use the editor? *shrugs* kind regards, Rudolf Kastl > > Bill > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From orion at cora.nwra.com Wed Nov 4 18:53:30 2009 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 04 Nov 2009 11:53:30 -0700 Subject: rawhide report: 20091104 changes - excluding noarch packages In-Reply-To: <1257356346.2215.16.camel@localhost.localdomain> References: <20091104144721.GA2687@releng2.fedora.phx.redhat.com> <4AF1A469.7000108@cora.nwra.com> <4AF1B7E5.5040407@city-fan.org> <1257356346.2215.16.camel@localhost.localdomain> Message-ID: <4AF1CDAA.4070705@cora.nwra.com> On 11/04/2009 10:39 AM, Jesse Keating wrote: > On Wed, 2009-11-04 at 17:20 +0000, Paul Howarth wrote: >> So a noarch script package that depends on its arch script interpreter >> (e.g. all python and perl packages) should be arch packages? >> > > And bash for that matter. > > This is a known problem with rpm/koji. The distinction between "noarch" > and "arch specific" is a difficult one to draw. We do have support in > our compose tools to look up an srpm and determine whether or not a > noarch rpm has Exclude/ExclusiveArch settings (since that data doesn't > propagate to the noarch rpm itself). What we don't have just yet is > code in koji to detect a noarch build that has Exclude/ExclusiveArch > settings and avoid sending said build to one of those arches. > > So, I managed to do a build with: BuildArch: noarch ExcludeArch: ppc64 If that gets tagged, it will get excluded from the ppc64 repo? -- 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 loganjerry at gmail.com Wed Nov 4 19:00:28 2009 From: loganjerry at gmail.com (Jerry James) Date: Wed, 4 Nov 2009 12:00:28 -0700 Subject: rawhide report: 20091104 changes - excluding noarch packages In-Reply-To: <1257360631.2215.19.camel@localhost.localdomain> References: <20091104144721.GA2687@releng2.fedora.phx.redhat.com> <4AF1B7E5.5040407@city-fan.org> <1257356346.2215.16.camel@localhost.localdomain> <200911041931.31822.bjorn@xn--rombobjrn-67a.se> <1257360631.2215.19.camel@localhost.localdomain> Message-ID: <870180fe0911041100o5f57e721u30e2a7eb25cbe0e1@mail.gmail.com> On Wed, Nov 4, 2009 at 11:50 AM, Jesse Keating wrote: > Until we add a new arch. ?But that still leaves things like java, mono, > ruby, etc as problem areas where "noarch" may not actually be "noarch". We seem to be using "noarch" in two different senses: 1. Contains no machine code, other architecture-specific bits, or build-system-specific artifacts (like build timestamps, build machine names, etc.) 2. Can be built/installed/consumed on any architecture. Those aren't the same. Since the addition of a new arch can break #2, how can packagers mean anything other than #1 by "noarch"? -- Jerry James http://www.jamezone.org/ From rjune at bravegnuworld.com Wed Nov 4 19:09:41 2009 From: rjune at bravegnuworld.com (Richard June) Date: Wed, 4 Nov 2009 13:09:41 -0600 Subject: Ubuntu shows updates / security updates on shell logins In-Reply-To: References: <20091104165030.GA25940@amd.home.annexia.org> Message-ID: On Wed, Nov 4, 2009 at 12:38 PM, Kevin Kofler wrote: > Richard June wrote: >> It's a good idea for one off jobs where the primary user is also the >> admin, but not so good for shared systems. Personally I think a better >> plan would be to display that information *only* if the user is >> flagged as an administrator, group root, wheel, etc. > > It's actually a security risk to display this to non-admin users. It's like > putting a sticker on your door saying "This door is not locked because my > keyhole is not working." > > ? ? ? ?Kevin Kofler Perhaps I was unclear. It's a good idea to display this for administrative users. Somebody in the root or wheel group for example. But not so useful for normal users. -- Richard June Orion Technology Solutions 574.933.1576 http://www.oriontechnologysolutions.com From jreiser at bitwagon.com Wed Nov 4 19:16:26 2009 From: jreiser at bitwagon.com (John Reiser) Date: Wed, 04 Nov 2009 11:16:26 -0800 Subject: A question about allow_unconfined_mmap_low in f11 amd selinux In-Reply-To: <1257360707.7251.345.camel@atropine.boston.devel.redhat.com> References: <3b8e57a80911040723x280abfd0jf6bab04bf4803390@mail.gmail.com> <4AF1A29E.2090708@redhat.com> <4AF1AE00.5010204@bitwagon.com> <1257360707.7251.345.camel@atropine.boston.devel.redhat.com> Message-ID: <4AF1D30A.7020205@bitwagon.com> > You're saying you have apps that rely on being able to dereference the > zero page, and _not_ because the processor mode requires it? I thought > the vax died long ago. The apps were written intentionally to exploit being able to use page 0. It's significantly faster (a factor of 10 or more) and simpler (thousands of lines of code that aren't needed) and easier to use (x<==>y versus x<==>(y + k).) With an identity map the hardware already understands the app's abstraction. -- From skvidal at fedoraproject.org Wed Nov 4 19:28:26 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 4 Nov 2009 14:28:26 -0500 (EST) Subject: Ubuntu shows updates / security updates on shell logins In-Reply-To: References: <20091104165030.GA25940@amd.home.annexia.org> Message-ID: On Wed, 4 Nov 2009, Kevin Kofler wrote: > Richard June wrote: >> It's a good idea for one off jobs where the primary user is also the >> admin, but not so good for shared systems. Personally I think a better >> plan would be to display that information *only* if the user is >> flagged as an administrator, group root, wheel, etc. > > It's actually a security risk to display this to non-admin users. It's like > putting a sticker on your door saying "This door is not locked because my > keyhole is not working." > i don't think it is a security risk. Or rather - if it is then the rpmdb should not be readable by non-root users. -sv From bmr at redhat.com Wed Nov 4 19:33:40 2009 From: bmr at redhat.com (Bryn M. Reeves) Date: Wed, 04 Nov 2009 19:33:40 +0000 Subject: Kernel using LZMA compression In-Reply-To: References: <4AEC97EA.8070603@bitwagon.com> <4AF1C6D1.5060202@redhat.com> Message-ID: <4AF1D714.4010201@redhat.com> On 11/04/2009 06:37 PM, Ikem Krueger wrote: >> I am reading between the lines here (I have never looked at this >> stuff in Xen) but I would assume it's for the reason given above. >> The kernel's own decompression routines must run very early on in >> the boot process - well before the first line of C code runs and >> while the CPU (on x86) is still running in legacy real addressing >> mode (right after the handover from the bootloader and relocation >> of the kernel image). > > Ok. Sounds plausible. How is it to seperate the routines? Can they > brought from "legacy mode" to "real mode"? > Quite tricky I'd guess - it's chicken-and-egg. The code to switch the CPU from real mode to protected mode is in the kernel's startup routines *inside* the compressed image. I don't think anyone is going to want to reorganise things to move that code to the primitive early-boot period - the idea is to do as little as possible in that part of the kernel and leave everything else to later in the boot process when life gets easier. Decompressing the kernel is always going to be done in that part of the startup sequence because that's when it has to happen. Regards, Bryn. From icon at fedoraproject.org Wed Nov 4 19:49:58 2009 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Wed, 4 Nov 2009 14:49:58 -0500 Subject: Ubuntu shows updates / security updates on shell logins In-Reply-To: References: <20091104165030.GA25940@amd.home.annexia.org> Message-ID: 2009/11/4 Kevin Kofler : > Richard June wrote: >> It's a good idea for one off jobs where the primary user is also the >> admin, but not so good for shared systems. Personally I think a better >> plan would be to display that information *only* if the user is >> flagged as an administrator, group root, wheel, etc. > > It's actually a security risk to display this to non-admin users. It's like > putting a sticker on your door saying "This door is not locked because my > keyhole is not working." Well, in this case you're posting it on the *inside* of your door. :) If someone has shell access, they can always run "foo --version", so I don't think this introduces any security risks that aren't already posed by someone having a shell on your server. Cheers, -- McGill University IT Security Konstantin Ryabitsev Montr?al, Qu?bec From dcbw at redhat.com Wed Nov 4 19:50:09 2009 From: dcbw at redhat.com (Dan Williams) Date: Wed, 04 Nov 2009 11:50:09 -0800 Subject: rfkill In-Reply-To: <1257353294.23167.153.camel@localhost.localdomain> References: <7a0107ba0911040835u3dc44b12m6015fde3e17f2b1f@mail.gmail.com> <1257353294.23167.153.camel@localhost.localdomain> Message-ID: <1257364209.14545.50.camel@localhost.localdomain> On Wed, 2009-11-04 at 16:48 +0000, Bastien Nocera wrote: > On Wed, 2009-11-04 at 11:35 -0500, Martin Dubuc wrote: > > Addition of a working version of rfkill in Fedora 12 has been really > > welcomed. In my application, I would like to monitor the RF kill > > switch to detect when user enables/disables Wi-Fi on the system. I > > thought I could use the rfkill executable to do this, using "rfkill > > event", piping the output using popen in my process. However, rfkill > > outputs the events on standard output, but does not flush every time > > it reports an event. When I perform fgets to get the events, I get > > nothing. I am wondering if it would be possible to add a fflush on > > stdout when events are reported on stdout inside rfkill. > > You're probably better off monitoring /dev/rfkill yourself directly (for > now[1]), there's example code in gnome-bluetooth, look at > lib/bluetooth-killswitch.c. > > You'd basically just need to change the type of killswitch you're > monitoring. > > Cheers > > [1]: We'd probably want a D-Busified rfkilld in the future. johannes and marcel keep talking about this but haven't gotten there yet. Dan From ikem.krueger at googlemail.com Wed Nov 4 20:11:27 2009 From: ikem.krueger at googlemail.com (Ikem Krueger) Date: Wed, 4 Nov 2009 20:11:27 +0000 Subject: Boot from CD, safe changes to USB-Stick Message-ID: You don't wanna change something on the harddisks, but wanna safe the changes. So you boot from Live-CD and the changes are redirected to the USB-Stick. Puppy Linux does it that way*. I wanna see it in Fedora. :D *http://puppylinux.com/development/howpuppyworks.html *http://puppylinux.com/development/pup2layers.png From cmadams at hiwaay.net Wed Nov 4 20:15:04 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 4 Nov 2009 14:15:04 -0600 Subject: Ubuntu shows updates / security updates on shell logins In-Reply-To: References: <20091104165030.GA25940@amd.home.annexia.org> Message-ID: <20091104201504.GG1419067@hiwaay.net> Once upon a time, Seth Vidal said: > i don't think it is a security risk. Or rather - if it is then the rpmdb > should not be readable by non-root users. If knowing installed versions are a security risk, then so is "uname -r" and almost any command that takes "-v" to display the version. -- Chris Adams 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 4 20:17:34 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 4 Nov 2009 15:17:34 -0500 (EST) Subject: Ubuntu shows updates / security updates on shell logins In-Reply-To: <20091104201504.GG1419067@hiwaay.net> References: <20091104165030.GA25940@amd.home.annexia.org> <20091104201504.GG1419067@hiwaay.net> Message-ID: On Wed, 4 Nov 2009, Chris Adams wrote: > Once upon a time, Seth Vidal said: >> i don't think it is a security risk. Or rather - if it is then the rpmdb >> should not be readable by non-root users. > > If knowing installed versions are a security risk, then so is "uname -r" > and almost any command that takes "-v" to display the version. right. -sv From mike at cchtml.com Wed Nov 4 20:35:13 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Wed, 04 Nov 2009 14:35:13 -0600 Subject: Boot from CD, safe changes to USB-Stick In-Reply-To: References: Message-ID: <4AF1E581.4000006@cchtml.com> Duane Smith on 11/04/2009 02:13 PM wrote: > You don't wanna change something on the harddisks, but wanna safe the > changes. So you boot from Live-CD and the changes are redirected to > the USB-Stick. Puppy Linux does it that way*. I wanna see it in > Fedora. :D Already possible I believe. I think there's a persistent overlay kernel command argument that you can point to use a file on your USB drive if you're booting from CD. I may be wrong on this though. It's easier just to boot from USB though. Faster all the way around. CD/DVDs take ages to boot. I know persistant overlay works swell with this method. I use it personally. Is booting from USB not an option for you? From ikem.krueger at googlemail.com Wed Nov 4 20:44:27 2009 From: ikem.krueger at googlemail.com (Ikem Krueger) Date: Wed, 4 Nov 2009 20:44:27 +0000 Subject: Boot from CD, safe changes to USB-Stick In-Reply-To: <4AF1E581.4000006@cchtml.com> References: <4AF1E581.4000006@cchtml.com> Message-ID: > Already possible I believe. I think there's a persistent overlay kernel command argument that you can point to use a file on your USB drive if you're booting from CD. I may be wrong on this though. I research for that.. > It's easier just to boot from USB though. Faster all the way around. CD/DVDs take ages to boot. I know persistant overlay works swell with this method. I use it personally. Is booting from USB not an option for you? Nope. My pc won't boot from stick. :S From jkeating at j2solutions.net Wed Nov 4 20:49:10 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 04 Nov 2009 12:49:10 -0800 Subject: rawhide report: 20091104 changes - excluding noarch packages In-Reply-To: <4AF1CDAA.4070705@cora.nwra.com> References: <20091104144721.GA2687@releng2.fedora.phx.redhat.com> <4AF1A469.7000108@cora.nwra.com> <4AF1B7E5.5040407@city-fan.org> <1257356346.2215.16.camel@localhost.localdomain> <4AF1CDAA.4070705@cora.nwra.com> Message-ID: <1257367750.2215.21.camel@localhost.localdomain> On Wed, 2009-11-04 at 11:53 -0700, Orion Poplawski wrote: > If that gets tagged, it will get excluded from the ppc64 repo? Yes -- 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: 198 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Wed Nov 4 20:50:11 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 04 Nov 2009 12:50:11 -0800 Subject: rawhide report: 20091104 changes - excluding noarch packages In-Reply-To: <870180fe0911041100o5f57e721u30e2a7eb25cbe0e1@mail.gmail.com> References: <20091104144721.GA2687@releng2.fedora.phx.redhat.com> <4AF1B7E5.5040407@city-fan.org> <1257356346.2215.16.camel@localhost.localdomain> <200911041931.31822.bjorn@xn--rombobjrn-67a.se> <1257360631.2215.19.camel@localhost.localdomain> <870180fe0911041100o5f57e721u30e2a7eb25cbe0e1@mail.gmail.com> Message-ID: <1257367811.2215.22.camel@localhost.localdomain> On Wed, 2009-11-04 at 12:00 -0700, Jerry James wrote: > Those aren't the same. Since the addition of a new arch can break #2, > how can packagers mean anything other than #1 by "noarch"? They can't, but it was a historical assumption that if you indicate #1, you're implicitly indicating #2. This has proven to break down as of late, so we have to re-do the logic code around where a build can be done. It's no longer safe to assume that "noarch" means "anyarch". -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Wed Nov 4 21:12:40 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 04 Nov 2009 16:12:40 -0500 Subject: help debugging segfault with alienarena 7.32 In-Reply-To: <4AF09144.8070300@redhat.com> References: <4AF05E46.5090404@redhat.com> <870180fe0911031116l3c7af629o245bcae3c4a2c940@mail.gmail.com> <4AF09144.8070300@redhat.com> Message-ID: <4AF1EE48.7050102@redhat.com> On 11/03/2009 03:23 PM, Tom "spot" Callaway wrote: > On 11/03/2009 02:16 PM, Jerry James wrote: >> My guess (and it is just a guess) is that this is triggering multiple >> initializations of portaudio. Try this patch: Well, it turned out to be a lot more complicated than that. Alienarena uses OpenAL-soft, which dlopens portaudio if it is present. Portaudio is compiled with support for jack, and asks jack if there is a valid client available to use. On my system (default F-12), there isn't, so the jack call returns NULL. Unfortunately, when that jack function which checks on the client is run, it spawns a new thread, which wasn't getting closed. After portaudio finished its check, openal-soft dlclosed it, with that thread that jack spawned still alive. This caused the segfault. Your original suggestion merely delayed the issue, because openal was being dlopened later instead of loading on initial execution. Ray Strode helped me debug this, and I've updated jack with the fix for this. Patch is here: http://trac.jackaudio.org/ticket/140 Thanks to all who helped out here. ~spot From opensource at till.name Wed Nov 4 21:51:56 2009 From: opensource at till.name (Till Maas) Date: Wed, 04 Nov 2009 22:51:56 +0100 Subject: CVS daily checkout seeds In-Reply-To: <1257346287.2537.4.camel@samson.armitage.org.uk> References: <1257346287.2537.4.camel@samson.armitage.org.uk> Message-ID: <20091104215156.GA18450@genius.kawo2.rwth-aachen.de> On Wed, Nov 04, 2009 at 02:51:27PM +0000, Quentin Armitage wrote: > The CVS daily checkout seeds at http://cvs.fedoraproject.org/webfiles/ > don't contain a checkout for F-12. Would it be possible for someone to > add that? > > I have also noted that a checkout seed for F-9 is still included, which > seems somewhat superfluous. I have created a ticket for this in the infrastructure bug tracker: https://fedorahosted.org/fedora-infrastructure/ticket/1784 If you have an FAS account, you can also create tickets there by yourself, because this is not the right mailing list to report such issues. You can also add yourself on the CC list, if you have FAS account to get notified in case someone works on it. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From joshuacov at googlemail.com Wed Nov 4 22:18:51 2009 From: joshuacov at googlemail.com (Joshua C.) Date: Wed, 4 Nov 2009 23:18:51 +0100 Subject: Boot from CD, safe changes to USB-Stick In-Reply-To: References: <4AF1E581.4000006@cchtml.com> Message-ID: <5f6f8c5f0911041418s50412461g8ebbb1ac2f186ca4@mail.gmail.com> 2009/11/4 Ikem Krueger : >> Already possible I believe. I think there's a persistent overlay kernel command argument that you can point to use a file on your USB drive if you're booting from CD. I may be wrong on this though. > > I research for that.. > >> It's easier just to boot from USB though. Faster all the way around. CD/DVDs take ages to boot. I know persistant overlay works swell with this method. I use it personally. Is booting from USB not an option for you? > > Nope. My pc won't boot from stick. :S > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > This way you can make changes to your "home directory" on the usb stick. No changes to the iso image though. Otherwise you have to recreate the iso. From joshuacov at googlemail.com Wed Nov 4 22:20:35 2009 From: joshuacov at googlemail.com (Joshua C.) Date: Wed, 4 Nov 2009 23:20:35 +0100 Subject: Boot from CD, safe changes to USB-Stick In-Reply-To: References: <4AF1E581.4000006@cchtml.com> Message-ID: <5f6f8c5f0911041420y181abbc0x8b3d81b6c9e11655@mail.gmail.com> 2009/11/4 Ikem Krueger : >> Already possible I believe. I think there's a persistent overlay kernel command argument that you can point to use a file on your USB drive if you're booting from CD. I may be wrong on this though. > > I research for that.. > >> It's easier just to boot from USB though. Faster all the way around. CD/DVDs take ages to boot. I know persistant overlay works swell with this method. I use it personally. Is booting from USB not an option for you? > > Nope. My pc won't boot from stick. :S > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Look here: https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB and scroll down to data persistence From bruno at wolff.to Wed Nov 4 22:26:43 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 4 Nov 2009 16:26:43 -0600 Subject: help debugging segfault with alienarena 7.32 In-Reply-To: <4AF1EE48.7050102@redhat.com> References: <4AF05E46.5090404@redhat.com> <870180fe0911031116l3c7af629o245bcae3c4a2c940@mail.gmail.com> <4AF09144.8070300@redhat.com> <4AF1EE48.7050102@redhat.com> Message-ID: <20091104222643.GA2007@wolff.to> On Wed, Nov 04, 2009 at 16:12:40 -0500, Tom spot Callaway wrote: > On 11/03/2009 03:23 PM, Tom "spot" Callaway wrote: > > Well, it turned out to be a lot more complicated than that. Alienarena > uses OpenAL-soft, which dlopens portaudio if it is present. Portaudio is Are you able to adjust the volume when using pulse? I am having a problem with glest (that also uses OpenAL-soft), and I think it is probably an OpenAL-soft issue, but I don't know for sure. I also tried telling OpenAL-soft to use a pulse plugin and that just caused glest to hang. If the problem is with glest, I need to figure it out. If it is with OpenAL-soft I need to make sure proper bugs have been filed against it. From mmcgrath at redhat.com Wed Nov 4 22:40:03 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 4 Nov 2009 16:40:03 -0600 (CST) Subject: Outage Notification - 2009-11-05 13:00 UTC Message-ID: There will be an outage starting at 2009-11-05 13:00 UTC, which will last approximately 1 hour. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2009-11-05 13:00 UTC' Affected Services: Buildsystem DNS Torrent Translation Services Websites Unaffected Services: CVS / Source Control Database Fedora Hosted Fedora People Fedora Talk Mail Mirror System Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/1785 Reason for Outage: IBM wants us reseat the DIMMs and get FRU information off of them. Don is going to do this work for us (thanks ibiblio). Seth is going to do a graceful shutoff. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to trackthe status of this outage. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From tcallawa at redhat.com Wed Nov 4 23:12:42 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 04 Nov 2009 18:12:42 -0500 Subject: help debugging segfault with alienarena 7.32 In-Reply-To: <20091104222643.GA2007@wolff.to> References: <4AF05E46.5090404@redhat.com> <870180fe0911031116l3c7af629o245bcae3c4a2c940@mail.gmail.com> <4AF09144.8070300@redhat.com> <4AF1EE48.7050102@redhat.com> <20091104222643.GA2007@wolff.to> Message-ID: <4AF20A6A.8060200@redhat.com> On 11/04/2009 05:26 PM, Bruno Wolff III wrote: > On Wed, Nov 04, 2009 at 16:12:40 -0500, > Tom spot Callaway wrote: >> On 11/03/2009 03:23 PM, Tom "spot" Callaway wrote: >> >> Well, it turned out to be a lot more complicated than that. Alienarena >> uses OpenAL-soft, which dlopens portaudio if it is present. Portaudio is > > Are you able to adjust the volume when using pulse? I am having a problem > with glest (that also uses OpenAL-soft), and I think it is probably an > OpenAL-soft issue, but I don't know for sure. I also tried telling OpenAL-soft > to use a pulse plugin and that just caused glest to hang. If the problem > is with glest, I need to figure it out. If it is with OpenAL-soft I need to > make sure proper bugs have been filed against it. Looks like alienarena defaults to ALSA. When I tell it to tell OpenAL-soft to use "PulseAudio Software", it doesn't actually make any sound at all, even though PulseAudio sees the application trying to do so. ~spot From ikem.krueger at googlemail.com Wed Nov 4 23:22:14 2009 From: ikem.krueger at googlemail.com (Ikem Krueger) Date: Wed, 4 Nov 2009 23:22:14 +0000 Subject: Boot from CD, safe changes to USB-Stick In-Reply-To: References: <4AF1E581.4000006@cchtml.com> Message-ID: >> Already possible I believe. I think there's a persistent overlay kernel command argument that you can point to use a file on your USB drive if you're booting from CD. I may be wrong on this though. > I research for that.. I looked for "kernel command". The only sources I found where this* and this*. Both doesn't mention "persistent overlay". *http://fedoraproject.org/wiki/Anaconda/Options *http://docs.fedoraproject.org/install-guide/f11/en-US/html/ap-admin-options.html Only for USB-Sticks "persistent overlay" is mentioned. *http://fedoraproject.org/wiki/How_to_create_and_use_Live_USB And I found another guy who asked for the same feature. *https://www.redhat.com/archives/fedora-livecd-list/2008-October/msg00009.html From ikem.krueger at googlemail.com Wed Nov 4 23:28:14 2009 From: ikem.krueger at googlemail.com (Ikem Krueger) Date: Wed, 4 Nov 2009 23:28:14 +0000 Subject: Boot from CD, safe changes to USB-Stick In-Reply-To: <5f6f8c5f0911041420y181abbc0x8b3d81b6c9e11655@mail.gmail.com> References: <4AF1E581.4000006@cchtml.com> <5f6f8c5f0911041420y181abbc0x8b3d81b6c9e11655@mail.gmail.com> Message-ID: >> Look here: https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB and scroll down to data persistence > The primary usage of this feature is booting a USB stick with your live image as well as the persistent changes. Sorry. But that's not what I meant. From bioinfornatics at gmail.com Wed Nov 4 23:17:57 2009 From: bioinfornatics at gmail.com (Jonathan MERCIER) Date: Thu, 05 Nov 2009 00:17:57 +0100 Subject: Pyhton image Message-ID: <1257376677.31894.1.camel@localhost.localdomain> Dear sir, I have open a bug: https://bugzilla.redhat.com/show_bug.cgi?id=532248 But i have any answer! What can i do? Kind regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From tibbs at math.uh.edu Wed Nov 4 23:45:41 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 04 Nov 2009 17:45:41 -0600 Subject: Pyhton image In-Reply-To: <1257376677.31894.1.camel@localhost.localdomain> (Jonathan MERCIER's message of "Thu, 05 Nov 2009 00:17:57 +0100") References: <1257376677.31894.1.camel@localhost.localdomain> Message-ID: >>>>> "JM" == Jonathan MERCIER writes: JM> Dear sir, I have open a bug: JM> https://bugzilla.redhat.com/show_bug.cgi?id=532248 JM> But i have any answer! What can i do? Somehow acquire patience? Work on debugging the problem yourself? You haven't given much time at all for the volunteer on the other end of that bug report to look at it (not even three weekdays). - J< From kevin at scrye.com Thu Nov 5 00:18:16 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 4 Nov 2009 17:18:16 -0700 Subject: source file audit - 2009-11-01 Message-ID: <20091104171816.0ef2c0a5@ohm.scrye.com> Here's attached another run of my sources/patches url checker. - There are 932 lines in this run. Down from 1060 last run. 700 sourcecheck-20070826.txt 620 sourcecheck-20070917.txt 561 sourcecheck-20071017.txt 775 sourcecheck-20080206.txt 685 sourcecheck-20080214.txt 674 sourcecheck-20080301.txt 666 sourcecheck-20080401.txt 660 sourcecheck-20080501.txt 642 sourcecheck-20080603.txt 649 sourcecheck-20080705.txt 662 sourcecheck-20080801.txt 912 sourcecheck-20081114.txt 884 sourcecheck-20090215.txt 1060 sourcecheck-20090810.txt 932 sourcecheck-20091101.txt You can find the results file at: http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20091101.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 -- rmeggins:BADURL:389-ds-base-1.2.4.tar.bz2:389-ds-base jmoskovc:BADURL:abrt-0.0.10.tar.gz:abrt bkearney:BADURL:ace-0.0.7.tar.gz:ace spot:BADURL:acetoneiso_2.1.1.tar.gz:AcetoneISO2 nim:BADSOURCE:Tribun-Std.zip:adf-tribun-fonts jussilehtola:BADURL:agedu-r8642.tar.gz:agedu ruben:BADURL:Ajaxterm-0.10.tar.gz:Ajaxterm pcheung:BAD_CVS_SOURCE:ant-1.7.1.pom:ant tagoh:BADURL:anthy-9100h.tar.gz:anthy dwmw2:BADURL:apmud-1.0.0.tgz:apmud athimm:BADURL:apt-0.5.15lorg3.95.git416.tar.bz2:apt sherry151:BADSOURCE:archmage-0.2.4.tar.gz:archmage athimm:BAD_CVS_SOURCE:RiceBSD.doc:arpack than:BADURL:arts-1.5.10.tar.bz2:arts jstanley:BADSOURCE:asyropoulos_-_Asana_Math.otf:asana-math-fonts chrisw:BADURL:asciidoc-8.4.5.tar.gz:asciidoc spot:BADURL:asymptote-1.88.src.tgz:asymptote mschwendt:BADURL:audacious-plugin-fc-0.4.tar.bz2:audacious-plugin-fc tmraz:BADURL:authconfig-5.4.13.tar.bz2:authconfig pwouters:BADURL:autotrust-0.3.1.tar.gz:autotrust sindrepb:BADURL:avant-window-navigator-0.3.2.tar.gz:avant-window-navigator tnorth:BADSOURCE:gcc-core-4.3.3.tar.bz2:avr-gcc phuang:BADURL:awn-extras-applets-0.3.2.2.tar.gz:awn-extras-applets abompard:BADURL:awstats-6.9.tar.gz:awstats bjensen:BADURL:ax25-tools.tar.gz:ax25-tools overholt:BAD_CVS_SOURCE:backport-util-concurrent-3.1.pom:backport-util-concurrent ixs:BADURL:bacula-3.0.3.tar.gz:bacula ixs:BADURL:bacula-docs-3.0.3.tar.bz2:bacula zkota:BADURL:bazaar_1.4.2.tar.gz:bazaar zkota:BADURL:bazaar-doc_1.4.tar.gz:bazaar satyak:BADSOURCE:beacon-0.5.tar.gz:beacon danken:BADURL:bidiv-1.5.tgz:bidiv peter:BADSOURCE:bios_extract-17ca1c5e6a8df6b5663e899504d197862c286d1e.tar.bz2:bios_extract jskala:BADURL:bltk-1.0.9.tar.gz:bltk akahl:BADURL:bmpx-0.40.14.tar.bz2:bmpx rrakus:BADSOURCE:netkit-bootparamd-0.17.tar.gz:bootparamd langel:BAD_CVS_SOURCE:bcprov-jdk16-1.43.pom:bouncycastle oget:BAD_CVS_SOURCE:bcmail-jdk16-1.43.pom:bouncycastle-mail oget:BAD_CVS_SOURCE:bctsp-jdk16-1.43.pom:bouncycastle-tsp fab:BADURL:bournal-1.3.tar.gz:bournal mattdm:BADURL:calc-2.12.2.1.tar.gz:calc nomis80:BADURL:camstream-0.26.3.tar.gz:camstream rrelyea:BADSOURCE:ccid-1.3.9.tar.bz2:ccid pbrobinson:BADURL:ccss-0.5.0.tar.gz:ccss hubbitus:BADURL:ccze-0.2.1.tar.gz:ccze mmahut:BADSOURCE:cdk.tar.gz:cdk edhill:BADSOURCE:cdo.pdf:cdo edhill:BADSOURCE:cdo_refcard.pdf:cdo steve:BADURL:celestia-1.5.1.tar.gz:celestia sheltren:BADURL:cfengine-2.2.10.tar.gz:cfengine gilboa:BAD_CVS_SOURCE:cgdb.png:cgdb jortel:BADSOURCE:chameleon-0.2.tar.gz:chameleon dwalsh:BADURL:checkpolicy-2.0.19.tgz:checkpolicy pali:BADURL:cherokee-0.99.24.tar.gz:cherokee trasher:BADURL:childsplay-1.4.tgz:childsplay herlo:BADSOURCE:2bc.zip:chisholm-to-be-continued-fonts athimm:BADURL:chrpath-0.13.tar.gz:chrpath fnasser:BADSOURCE:inetlib-1.1.1.tar.gz:classpathx-mail jmrcpn:BADSOURCE:clement-2.1.320.tar.gz:clement walters:BADURL:clojure_20090320.zip:clojure sergiopr:BADURL:cloudy_v07_02_01.tar.gz:cloudy beekhof:BADSOURCE:b79635605337.tar.bz2:cluster-glue itamarjp:BADURL:clutter-gst-0.10.0.tar.bz2:clutter-gst orphan:BADURL:cluttermm-0.9.4.20090907git.tar.bz2:cluttermm rjones:BADURL:coccinelle-0.1.10.tgz:coccinelle green:BADURL:common-lisp-controller_6.15.tar.gz:common-lisp-controller markhla:BADSOURCE:comoonics-base-py-0.1.tar.gz:comoonics-base-py elcody02:BADSOURCE:comoonics-cdsl-py-0.2.tar.gz:comoonics-cdsl-py elcody02:BADSOURCE:comoonics-cluster-py-0.1.tar.gz:comoonics-cluster-py krh:BADURL:compiz-0.8.2.tar.bz2:compiz notting:BADURL:comps-extras-17.tar.gz:comps-extras steve:BADURL:cone-0.78.tar.bz2.sig:cone bpeck:BADURL:conmux-493svn.tar.gz:conmux gemi:BADSOURCE:cook-2.32.tar.gz:cook ovasik:BADURL:coreutils-8.0.tar.xz:coreutils cweyl:BADURL:cpan-upload-2.2.tar.gz:cpan-upload sergiopr:BADURL:cpl-5.0.1.tar.gz:cpl mmahut:BADURL:cpm-0.23beta.tar.gz:cpm bradbell:BADSOURCE:cppad-20090303.0.gpl.tgz:cppad sundaram:BADSOURCE:cryptopp560.zip:cryptopp chitlesh:BADURL:crystal-kwin4-1.0.5.tar.bz2:crystal chitlesh:BADURL:CrystalClear.tar.gz:crystal-clear chitlesh:BADSOURCE:crystal_project.tar.gz:crystal-project nhorman:BADURL:cscope-15.6.tar.gz:cscope jwilson:BADURL:ctrlproxy-3.0.8.tar.gz:ctrlproxy twaugh:BADURL:cups-1.4.1-source.tar.bz2:cups gemi:BADSOURCE:curry-0.9.11.tar.gz:curry desi:BADSOURCE:cwrite-0.1.24.tar.gz:cwrite nbecker:BADURL:Cython-0.11.3.tar.gz:Cython spot:BADSOURCE:daa2iso.zip:daa2iso jjh:BADURL:darcs-2.2.1.tar.gz:darcs fab:BADSOURCE:dateshift-1.1.tar.gz:dateshift pfj:BADSOURCE:db4o-6.1-mono.tar.gz:db4o davidz:BADSOURCE:dbus-1.2.16.tar.gz:dbus rdieter:BADSOURCE:dbus-1-qt3-0.9.tar.gz:dbus-qt3 limb:BADURL:ddd-3.3.12.tar.gz:ddd ixs:BADSOURCE:dd_rhelp-0.1.2.tar.gz:dd_rescue ruben:BADURL:debmirror_20090807.tar.gz:debmirror kasal:BADURL:debootstrap_1.0.19.tar.gz:debootstrap pgordon:BADURL:deluge-1.2.0_rc1.tar.bz2:deluge bjensen:BADSOURCE:demorse-0.9.tar.gz:demorse sharkcz:BADURL:devio-1.2.tar.gz:devio ensc:BADURL:dhcp-forwarder-0.8.tar.bz2:dhcp-forwarder ensc:BADURL:dhcp-forwarder-0.8.tar.bz2.asc:dhcp-forwarder fnasser:BAD_CVS_SOURCE:naming-resources-0.8.pom:directory-naming robmv:BADSOURCE:dirvish-1.2.1.tgz:dirvish lvm-team:BADURL:dmraid-1.0.0.rc16.tar.bz2:dmraid pwouters:BADURL:dnssec-conf-1.22.tar.gz:dnssec-conf awjb:BADURL:dosbox-0.73.tar.gz:dosbox sergiopr:BADURL:ds9.5.4.tar.gz:ds9 fkooman:BADSOURCE:dumpasn1.c:dumpasn1 pjones:BADURL:dumpet-2.0.tar.bz2:dumpet jgu:BADURL:dvipdfmx-20090708.tar.gz:dvipdfmx guthrie:BADURL:dxpc-3.9.1.tgz:dxpc till:BADURL:dzen2-latest.tar.gz:dzen2 fnasser:BAD_CVS_SOURCE:easymock-1.2_Java1.5.pom:easymock mmahut:BADURL:eboard-1.1.1.tar.bz2:eboard spot:BADURL:ebtables-v2.0.9-1.tar.gz:ebtables dbhole:BAD_CVS_SOURCE:core-3.3.0-v_771.pom:ecj overholt:BADURL:eclipse-build-0.4.0RC0.tar.gz:eclipse jjohnstn:BADURL:eclipse-cdt-fetched-src-autotools-v200910161608.tar.gz:eclipse-cdt jjohnstn:BADURL:eclipse-cdt-fetched-src-libhover-R0_3_0.tar.gz:eclipse-cdt anithra:BADSOURCE:com.ibm.systemtapgui.src.tar.gz:eclipse-systemtapgui than:BADURL:efax-0.9a-001114.tar.gz:efax davidz:BADURL:eggdbus-0.5.tar.gz:eggdbus rdieter:BADSOURCE:default.tar.bz2:eigen2 kdudka:BADURL:eject-2.1.5.tar.gz:eject veillard:BADURL:ekiga-3.2.6.tar.bz2:ekiga ausil:BADSOURCE:elftoaout-2.3.tgz:elftoaout dnovotny:BAD_CVS_SOURCE:rpm-spec-mode.el:emacs jkeating:BADSOURCE:email2trac.tar.gz:email2trac sharkcz:BADSOURCE:entertrack-1.2.6.tar.gz:entertrack icon:BADURL:epylog-1.0.3.tar.gz:epylog gemi:BADURL:esdl-1.0.1.src.tar.gz:erlang-esdl sergiopr:BADURL:esorex-3.7.2.tar.gz:esorex mbarnes:BADURL:evolution-2.28.0.tar.bz2:evolution bpepple:BADURL:evolution-brutus-1.2.35.tar.gz:evolution-brutus mbarnes:BADURL:evolution-data-server-2.29.1.tar.bz2:evolution-data-server mbarnes:BADURL:evolution-exchange-2.28.0.tar.bz2:evolution-exchange mbarnes:BADURL:evolution-mapi-0.28.0.tar.bz2:evolution-mapi mbarnes:BADURL:evolution-sharp-0.21.1.tar.bz2:evolution-sharp deji:BADURL:exaile-0.3.0.1.tar.gz:exaile dwmw2:BADURL:FAQ-html-20050415.tar.bz2:exim-doc dwmw2:BADURL:config.samples-20050415.tar.bz2:exim-doc itamarjp:BADSOURCE:ez-ipupdate-3.0.11b8.tar.gz:ez-ipupdate itamarjp:BADURL:ez-ipupdate_3.0.11b8-10.diff.gz:ez-ipupdate silas:BADSOURCE:fabric-0.9b1.tar.gz:fabric athimm:BADURL:fakeroot_1.12.2.tar.gz:fakeroot rjones:BADURL:febootstrap-2.5.tar.gz:febootstrap akurtakov:BADURL:org.osgi.core-1.2.0-project.tar.gz:felix-osgi-core 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 gemi:BADURL:ffcall-20080704cvs.tar.bz2:ffcall rineau:BADSOURCE:figtoipe-20080505.tar.gz:figtoipe nbecker:BADURL:filelight-1.9-rc2.tgz:filelight mebrown:BADURL:firmware-addon-dell-2.1.2.tar.gz:firmware-addon-dell mebrown:BADSOURCE:firmware-tools-2.1.5.tar.gz:firmware-tools deji:BADURL:flagpoll-0.9.1.tar.gz:flagpoll bellet:BAD_CVS_SOURCE:fg-16.png:FlightGear green:BADURL:fluidsynth-dssi-1.0.0.tar.gz:fluidsynth-dssi andriy:BAD_CVS_SOURCE:fmio-gq-wrapper.py:fmio than:BADURL:cyr-rfx-koi8-ub-1.1.bdfs.tar.bz2:fonts-KOI8-R than:BADURL:ksi-XFree86-cyrillic-fonts.tar.bz2:fonts-KOI8-R twaugh:BADURL:foomatic-db-4.0-20090819.tar.gz:foomatic-db sheltren:BADURL:fortune-mod-1.99.1.tar.gz:fortune-mod sheltren:BADURL:fortune-tao.tar.gz:fortune-mod sheltren:BADURL:fortune-hitchhiker.tgz:fortune-mod sheltren:BADURL:osfortune.tar.gz:fortune-mod hubbitus:BADURL:fotoxx-8.0.tar.gz:fotoxx joost:BADURL:fpcbuild-2.2.4.tar.gz:fpc awjb:BADURL:freealut-1.1.0.tar.gz:freealut tanguy:BADURL:freehdl-0.0.7.tar.gz:freehdl jdetaeye:BADSOURCE:frepple-0.7.1.tar.gz:frepple cgrau:BADURL:frotz-2.43.tar.gz:frotz lkundrak:BADURL:tex-fusecompress-4e07d3fe1c61f9a83732eb3021e3016feb008bdb.tar.gz:fusecompress ertzing:BADSOURCE:fwbuilder-3.0.5.tar.gz:fwbuilder firewing:BADSOURCE:fwfstab-0.03.tar.gz:fwfstab cweyl:BADURL:qrc-0.96-293svn.tar.gz:gaim-gaym cweyl:BADURL:gaim-2.0.0beta4.tar.gz:gaim-gaym laxathom:BADURL:gammu-1.25.92.tar.bz2:gammu pfj:BADSOURCE:gDeskCal-1.01.tar.gz:gdeskcal kevin:BADURL:gdk-pixbuf-0.22.0.tar.bz2:gdk-pixbuf chitlesh:BADURL:geda-gaf-1.6.0.tar.gz:geda-gaf chitlesh:BADURL:geda-gnetlist-1.4.3.tar.gz:geda-gnetlist sergiopr:BADURL:LaTeXPlugin-0.2rc2.tar.gz:gedit-latex-plugin thias:BADURL:gentoo-0.15.2.tar.gz:gentoo rdieter:BADSOURCE:geomview-1.9.4.tar.bz2:geomview nim:BADSOURCE:GFS_DECKER.zip:gfs-decker-fonts nim:BADSOURCE:GFS_GAZIS.zip:gfs-gazis-fonts nim:BADSOURCE:GFS_NEOHELLENIC_OT.zip:gfs-neohellenic-fonts nim:BADSOURCE:GFS_PYRSOS.zip:gfs-pyrsos-fonts bos:BADURL:ghc-6.12.0.20091010-src.tar.bz2:ghc petersen:BADURL:cgi-3001.1.7.1.tar.gz:ghc-cgi bos:BADURL:fgl-5.4.2.2.tar.gz:ghc-fgl bos:BADURL:GLUT-2.1.1.2.tar.gz:ghc-GLUT konradm:BADURL:haskell-src-exts-1.1.4.tar.gz:ghc-haskell-src-exts bos:BADURL:HUnit-1.2.0.3.tar.gz:ghc-HUnit petersen:BADURL:network-2.2.1.4.tar.gz:ghc-network bos:BADURL:OpenGL-2.2.1.1.tar.gz:ghc-OpenGL ynemoy:BADURL:tar-0.3.1.0.tar.gz:ghc-tar petersen:BADURL:time-1.1.2.4.tar.gz:ghc-time zoglesby:BADURL:X11-xft-0.3.tar.gz:ghc-X11-xft ynemoy:BADURL:xmonad-contrib-0.8.1.tar.gz:ghc-xmonad-contrib rakesh:BADURL:ginac-1.5.1.tar.bz2:ginac mycae:BADURL:givaro-3.3.0.tar.gz:givaro thias:BADSOURCE:gkrellm-gkfreq-1.0.tar.gz:gkrellm-freq bruno:BADURL:glest_data_3.2.1.zip:glest-data rafalzaq:BADURL:glob2-0.9.4.1.tar.gz:glob2 remi:BADURL:glpi-datainjection-1.7.0.tar.gz:glpi-data-injection adrian:BADURL:gmpc-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-alarm-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-lyricwiki-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-magnatune-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-mdcover-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-mserver-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-osd-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-shout-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-tagedit-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-wikipedia-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-avahi-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-coveramazon-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-extraplaylist-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-jamendo-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-last-fm-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-libnotify-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-lirc-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-lyrics-0.18.0.tar.gz:gmpc laxathom:BADURL:grandr_applet-0.4.1.tar.gz:gnome-applet-grandr cwickert:BADURL:timer-applet-2.1.2.tar.gz:gnome-applet-timer orphan:BADURL:tvn24_0.2.8-1.tar.gz:gnome-applet-tvn24 orphan:BADURL:gnome-blog-0.9.1.tar.bz2:gnome-blog mtasaka:BADURL:gnome-commander-1.3-git_D20090623T0316_13dev.tar.bz2:gnome-commander hadess:BADURL:gnome-lirc-properties-0.4.0.tar.gz:gnome-lirc-properties rhughes:BADURL:gnome-packagekit-2.28.1-20090928.tar.gz:gnome-packagekit rhughes:BADURL:gnome-power-manager-2.28.0.tar.bz2:gnome-power-manager mbarnes:BADURL:gnome-python-2.28.0.tar.bz2:gnome-python2 otaylor:BADURL:gnome-shell-2.28.0.tar.bz2:gnome-shell mwiriadi:BADURL:gnome-themes-extras-2.22.0.tar.gz:gnome-themes-extras orphan:BADURL:gnome-yum-0.1.4.tar.gz:gnome-yum clumens:BADURL:gnu-efi-3.0e.tar.bz2:gnu-efi nsantos:BADURL:gnu.regexp-1.1.4.tar.gz:gnu-regexp bjohnson:BADURL:goocanvas-0.14.tar.bz2:goocanvas denis:BADURL:goocanvasmm-0.14.0.tar.bz2:goocanvasmm nim:BAD_CVS_SOURCE:NOTICE:google-droid-fonts npajkovs:BADURL:gpm-1.20.6.tar.lzma:gpm bonii:BADURL:gquilt-0.20.tar.gz:gquilt jcollie:BADURL:gramps-3.1.2.tar.gz:gramps vlg:BADURL:granule-1.4.0.tar.gz:granule mmahut:BADSOURCE:grc_0.70.tar.gz:grc chitlesh:BADSOURCE:gresistor-0.0.1.tar.gz:gresistor deebs:BADSOURCE:GREYCstoration-2.8.zip:GREYCstoration athimm:BADURL:greylistd_0.8.7.tar.gz:greylistd orphan:BADSOURCE:gst-plugins-0.8.12.tar.bz2:gstreamer08-plugins denis:BADURL:gstreamermm-0.10.5.tar.bz2:gstreamermm ixs:BADURL:gsynaptics-0.9.16.tar.gz:gsynaptics rrankin:BAD_CVS_SOURCE:gtk+extra-2.1.1.tar.gz:gtk+extra buc:BADURL:gtk-gnutella-0.96.6.tar.bz2:gtk-gnutella mbarnes:BADURL:gtkhtml-3.29.1.tar.bz2:gtkhtml3 mso:BADURL:gtk-nodoka-engine-0.7.2.tar.gz:gtk-nodoka-engine maxx:BADURL:39179-rezlooks-0.6.tar.gz:gtk-rezlooks-engine maxx:BADSOURCE:Rezlooks-Gilouche.tar.gz:gtk-rezlooks-engine maxx:BADSOURCE:Rezlooks-Snow.tar.gz:gtk-rezlooks-engine maxx:BADSOURCE:Rezlooks-candy.tar.gz:gtk-rezlooks-engine maxx:BADSOURCE:Rezlooks-graphite.tar.gz:gtk-rezlooks-engine maxx:BADSOURCE:Rezlooks-dark.tar.gz:gtk-rezlooks-engine laxathom:BADURL:gtk-sharp-2.12.9.tar.bz2:gtk-sharp2 pfj:BADURL:gtksourceview2-sharp-89788.tar.bz2:gtksourceview2-sharp pfj:BADURL:gtksourceview-sharp-2.0-0.12.tar.bz2:gtksourceview-sharp twaugh:BADURL:gutenprint-5.2.4.tar.bz2:gutenprint dwalluck:BAD_CVS_SOURCE:hamcrest-parent-1.1.pom:hamcrest maxx:BADURL:hamster-applet-2.28.1.tar.bz2:hamster-applet petersen:BADURL:haskell-platform-2009.2.0.2.tar.gz:haskell-platform orion:BADURL:hdf5-1.8.3-snap12.tar.gz:hdf5 jwilson:BADURL:libhdhomerun_20090415.tgz:hdhomerun jwilson:BADURL:hdhomerun_config_gui_20090415.tgz:hdhomerun sharkcz:BADSOURCE:herculesstudio-1.0.0-src.tar.gz:hercstudio cweyl:BADURL:diskdev_cmds-332.14.tar.gz:hfsplus-tools cweyl:BAD_CVS_SOURCE:apsl-2.0.txt:hfsplus-tools dwmw2:BADURL:hfsplus_1.0.4.src.tar.bz2:hfsplusutils walters:BADURL:hippo-canvas-0.3.0.tar.gz:hippo-canvas petersen:BADURL:hscolour-1.15.tar.gz:hscolour jorton:BADURL:httpd-2.2.13.tar.gz:httpd rishi:BADSOURCE:httrack-3.43-2.tar.gz:httrack caolanm:BADURL:hunspell-hil-0.13.oxt:hunspell-hil caolanm:BADSOURCE:hu_HU-1.5.tar.gz:hunspell-hu caolanm:BADURL:sjp-myspell-pl-20090908.zip:hunspell-pl ensc:BADURL:hunt-1.5.tgz:hunt caolanm:BADURL:nagybence-huhyphn-aa3fc85f5ea7450f84f0cd3881a09ca065198dfc.tar.gz:hyphen-hu dchen:BADSOURCE:ibus-chewing-1.2.0.20091002-Source.tar.gz:ibus-chewing phuang:BADURL:pinyin-database-0.1.10.6.tar.bz2:ibus-pinyin cchance:BADURL:ibus-table-cangjie-1.2.0.20090831.tar.gz:ibus-table-cangjie gilboa:BAD_CVS_SOURCE:icewm-xdg-menu:icewm cgrau:BADURL:ifm-5.1.tar.gz:ifm pfj:BADURL:ikvm-0.22.tar.gz:ikvm rineau:BADSOURCE:ipe-6.0pre32patch1-src.tar.gz:ipe ensc:BADSOURCE:ip-sentinel-0.12.tar.bz2.sig:ip-sentinel lkundrak:BADURL:ircp-tray-0.7.3.tar.gz:ircp-tray karsten:BADURL:irda-utils-0.9.18.tar.gz:irda-utils than:BADURL:isdn4k-utils-CVS-2009-10-20.tar.bz2:isdn4k-utils rishi:BADURL:isight-firmware-tools-1.0.2.tar.gz:isight-firmware-tools anaconda-maint:BADURL:isomd5sum-1.0.5.tar.bz2:isomd5sum rezso:BADURL:verilog-0.9.1.tar.gz:iverilog jfch2222:BADURL:iwak-2.5.tgz:iwak fnasser:BAD_CVS_SOURCE:commons-configuration-1.4.pom:jakarta-commons-configuration dbhole:BAD_CVS_SOURCE:commons-dbcp-1.2.1.pom:jakarta-commons-dbcp mbooth:BADURL:commons-digester-1.7-src.tar.gz:jakarta-commons-digester fnasser:BAD_CVS_SOURCE:commons-el-1.0.pom:jakarta-commons-el fnasser:BAD_CVS_SOURCE:commons-jxpath-1.2.pom:jakarta-commons-jxpath mbooth:BADURL:commons-modeler-2.0-src.tar.gz:jakarta-commons-modeler dbhole:BADURL:commons-validator-1.1.4-src.tar.gz:jakarta-commons-validator tagoh:BAD_CVS_SOURCE:k14.patch:japanese-bitmap-fonts langel:BADSOURCE:icedtea6-1.6.tar.gz:java-1.6.0-openjdk bkearney:BADSOURCE:java-augeas-0.0.1.tar.gz:java-augeas mtasaka:BADURL:jd-2.5.0-svn3140_trunk.tgz:jd itamarjp:BADURL:jfsutils-1.1.13.tar.gz:jfsutils wolfy:BADURL:jnettop-0.13.0.tar.gz:jnettop snecker:BADURL:jokosher-20090604svn.tar.gz:jokosher overholt:BADURL:apache.zip:json gajownik:BADSOURCE:kadu-split_messages-0.3.tar.bz2:kadu orphan:BADSOURCE:kbiof-0.3.tar.gz:kbiof than:BADURL:kdbg-2.1.1.tar.gz:kdbg 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-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-nb-3.5.10.tar.bz2:kde-i18n than:BADURL:kde-i18n-bn-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-ca-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-i18n-lt-3.5.10.tar.bz2:kde-i18n than:BADURL:kde-i18n-ko-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-l10n-ar-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-es-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-et-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-eu-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-fi-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-fr-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-ga-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-gl-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-hi-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-hu-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-bg-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-it-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-ja-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-km-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-ko-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-ku-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-lv-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-lt-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-mk-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-ml-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-nb-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-ca-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-nds-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-nl-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-nn-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-pa-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-pl-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-pt-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-pt_BR-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-ru-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-cs-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-sk-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-sl-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-sv-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-th-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-tr-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-uk-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-wa-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-zh_CN-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-zh_TW-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-csb-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-sr-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-kk-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-he-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-bn_IN-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-gu-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-is-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-kn-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-mai-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-mr-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-da-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-ro-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-tg-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-hr-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-de-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-el-4.3.2.tar.bz2:kde-l10n than:BADURL:kde-l10n-en_GB-4.3.2.tar.bz2:kde-l10n rdieter:BADURL:kdelibs-experimental-4.3.2.tar.bz2:kdelibs-experimental than:BADURL:kdepim-runtime-4.3.2.tar.bz2:kdepim-runtime eliwap:BADURL:91009-iHateTheCashew-4.2.tbz:kde-plasma-ihatethecashew eliwap:BADURL:translatoid1.0.tar.gz:kde-plasma-translatoid than:BADSOURCE:css.tar.bz2:kdewebdev than:BADSOURCE:html.tar.bz2:kdewebdev than:BADSOURCE:javascript.tar.bz2:kdewebdev ben:BADSOURCE:ketchup-0.9.8.tar.bz2:ketchup chitlesh:BADURL:keurocalc-1.0.0.tgz:keurocalc jstanley:BADURL:keychecker-0.2.tar.gz:keychecker bouska:BADURL:kitsune2.0.tar.gz:kitsune awjb:BADURL:koffice-l10n-en_GB-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-es-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-et-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-fr-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-fy-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-gl-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-hne-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-it-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-ja-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-kk-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-nb-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-nds-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-nl-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-pl-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-pt-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-pt_BR-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-ca-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-sv-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-tr-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-uk-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-wa-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-zh_CN-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-zh_TW-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-da-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-de-2.0.91.tar.bz2:koffice-langpack awjb:BADURL:koffice-l10n-el-2.0.91.tar.bz2:koffice-langpack jkeating:BADSOURCE:koji-1.3.1.tar.bz2:koji ausil:BADURL:konversation-1.2.tar.bz2:konversation roma:BADURL:kradio4-4.0.0.tar.bz2:kradio4 ausil:BADURL:krecipes-1.0-beta2.tar.gz:krecipes kkofler:BADURL:ksensors_0.7.3-15.diff.gz:ksensors sxw:BADURL:kstart-3.11.tar.gz:kstart akurtakov:BADURL:kxml2-src-2.2.2.zip:kxml akurtakov:BAD_CVS_SOURCE:kxml2-2.2.2.pom:kxml pwouters:BADURL:ldns-1.6.1.tar.gz:ldns kevin:BADURL:leafnode-1.11.7.tar.bz2:leafnode konradm:BADURL:L-1.2.tar.gz:L-function thomasvs:BADSOURCE:libannodex-0.7.3.tar.gz:libannodex mso:BADURL:libass-0.9.8.tar.bz2:libass jmoskovc:BADURL:libbtctl-0.11.1.tar.bz2:libbtctl pbrobinson:BADURL:libccss-0.4.0.tar.gz:libccss thomasvs:BADSOURCE:libcmml-0.9.1.tar.gz:libcmml kaitlin:BADSOURCE:libcmpiutil-0.5.tar.gz:libcmpiutil edhill:BADURL:libctl-3.0.2.tar.gz:libctl mikep:BADURL:libdmapsharing-1.9.0.10.tar.gz:libdmapsharing green:BADURL:libffi-3.0.5.tar.gz:libffi snecker:BADURL:libflaim-4.9.1052.tar.gz:libflaim ertzing:BADSOURCE:libfwbuilder-3.0.5.tar.gz:libfwbuilder denis:BADURL:libgda-4.0.4.tar.bz2:libgda hadess:BADURL:libgdata-0.5.0.tar.bz2:libgdata turki:BADURL:libgsasl-0.2.29.tar.gz:libgsasl hguemar:BADURL:libgtksourceviewmm-0.3.1.tar.bz2:libgtksourceviewmm jorton:BADURL:libidn-1.9.tar.gz:libidn dajt:BADSOURCE:libiec61883-1.2.0.tar.gz:libiec61883 orphan:BADURL:libipoddevice-0.5.3.tar.gz:libipoddevice asheesh:BADURL:liblicense-0.8.1.tar.gz:liblicense green:BADURL:liblo-0.24.tar.gz:liblo adrian:BADURL:libmpd-0.18.0.tar.gz:libmpd snirkel:BADURL:libmtp-1.0.1.tar.gz:libmtp srini:BADURL:libnetdevname-0.0.3.tar.bz2:libnetdevname huzaifas:BADSOURCE:libnova-0.12.1.tar.gz:libnova chitlesh:BADURL:liborigin-20080225.tar.gz:liborigin denis:BADURL:libpanelappletmm-2.26.0.tar.bz2:libpanelappletmm tgl:BADURL:libpng-1.2.39.tar.bz2:libpng awjb:BADSOURCE:libpolyxmass-0.9.1.tar.gz:libpolyxmass dwalsh:BADURL:libselinux-2.0.88.tgz:libselinux dwalsh:BADURL:libsemanage-2.0.39.tgz:libsemanage dwalsh:BADURL:libsepol-2.0.39.tgz:libsepol denis:BADURL:libsigc++-1.2.7.tar.bz2:libsigc++ mebrown:BADSOURCE:libsmbios-2.2.16.tar.bz2:libsmbios jroth:BADSOURCE:libspe2-2.3.0.135.tar.gz:libspe2 heffer:BADURL:libsyncml-0.4.6.tar.bz2:libsyncml jjh:BADURL:crypt-1.17.tar.bz2:libtomcrypt jjh:BADURL:ltm-0.41.tar.bz2:libtommath kdudka:BADSOURCE:libtrash-3.2.tgz:libtrash dchen:BADSOURCE:libUnihan-0.5.3-Source.tar.gz:libUnihan jwrdegoede:BADURL:libv4l-0.6.3.tar.gz:libv4l kanarip:BADURL:libvmime-0.9.0.tar.bz2:libvmime denis:BADURL:libxml++-2.26.0.tar.bz2:libxml++ awjb:BADURL:libytnef-1.5.tar.bz:libytnef hguemar:BADSOURCE:listen-0.6.3.tar.gz:listen kushal:BADURL:liveusb-creator-3.7.3.tar.bz2:liveusb-creator bos:BADURL:llvm-2.6.tar.gz:llvm bos:BADURL:clang-2.6.tar.gz:llvm pravins:BADURL:lohit-kashmiri-2.4.3.tar.gz:lohit-kashmiri-fonts pravins:BADURL:lohit-maithili-2.4.3.tar.gz:lohit-maithili-fonts pravins:BADURL:lohit-oriya-2.4.3.tar.gz:lohit-oriya-fonts jwrdegoede:BADURL:labysource_3.5.1.tar.gz:lostlabyrinth bjensen:BADSOURCE:lpsk31-1.1.tar.gz:lpsk31 caolanm:BADSOURCE:lp_solve_5.5.0.15_source.tar.gz:lpsolve kzak:BADURL:lslk_1.29_W.tar.gz:lslk emunson:BADSOURCE:lsvpd-1.6.5.tar.gz:lsvpd dbhole:BADURL:lucene-2.3.1-src.tar.gz:lucene cwickert:BADURL:lxde-settings-daemon-0.4.tar.bz2:lxde-settings-daemon jmoskovc:BADURL:lynx2.8.6.tar.bz2:lynx varekova:BADURL:manpages-ru-0.7.tar.gz:man-pages-ru arjunroy:BADSOURCE:matahari-0.0.4.tar.gz:matahari akurtakov:BADURL:maven-bundle-plugin-2.0.0-project.tar.gz:maven-plugin-bundle dbhole:BAD_CVS_SOURCE:cvsclient-20060125.pom:maven-scm rdieter:BADURL:macref.pdf:maxima dwalsh:BADURL:mcstrans-0.3.1.tgz:mcstrans shakthimaan:BADSOURCE:mcu8051ide-1.3.1.tar.gz:mcu8051ide jwboyer:BADURL:meanwhile-1.1.0.tar.gz:meanwhile mtasaka:BAD_CVS_SOURCE:terms-and-conditions-for-IFS-J.html:mecab-ipadic mclasen:BADURL:media-player-info-3.tar.gz:media-player-info kushal:BADSOURCE:mediascrapper-0.1.tar.gz:mediascrapper plindner:BADURL:memcached-1.4.2.tar.gz:memcached slankes:BADURL:merkaartor-0.14.tar.bz2:merkaartor ixs:BADURL:metapixel-1.0.2.tar.gz:metapixel pgordon:BADURL:midori-0.2.0.tar.bz2:midori rjones:BADURL:libpng-1.2.37.tar.bz2:mingw32-libpng sailer:BADURL:pangomm-2.26.0.tar.bz2:mingw32-pangomm plouj:BADSOURCE:physfs-1.0.1.tar.gz:mingw32-physfs wtogami:BADURL:mkelfImage-2.7.tar.gz:mkelfimage robert:BADSOURCE:arc4random.c:mksh sharkcz:BADURL:mm3d-1.3.8.tar.gz:mm3d timfenn:BADSOURCE:mmdb-1.21.tar.gz:mmdb jkeating:BADURL:mock-0.9.17.tar.gz:mock robert:BADSOURCE:mod_log_post-0.1.0.tar.gz:mod_log_post laxathom:BADURL:mono-2.6.tar.bz2:mono buhochileno:BADSOURCE:monodevelop-debugger-mdb-2.1.0.tar.bz2:monodevelop-debugger-mdb pfj:BADURL:monodoc-2.0.zip:monodoc rmeggins:BADSOURCE:mozldap-6.0.5.tar.gz:mozldap tbzatek:BAD_CVS_SOURCE:mrxvt.desktop:mrxvt jnovy:BADSOURCE:multican-0.0.5.tar.gz:multican mmahut:BADURL:cmunipack-1.1.24.tar.gz:munipack belegdol:BADURL:museek+-0.2.tar.bz2:museek+ pbrobinson:BADURL:mutter-2.28.0.tar.bz2:mutter itamarjp:BADURL:mydns-1.2.8.27.tar.gz:mydns tgl:BADURL:mysql-5.1.39.tar.gz:mysql tgl:BADURL:mysql-connector-odbc-5.1.5r1144.tar.gz:mysql-connector-odbc ausil:BADURL:mysql-gui-tools-5.0r14.tar.gz:mysql-gui-tools caolanm:BADSOURCE:thes_de_DE_v2.zip:mythes-de caolanm:BADSOURCE:OOo2-thes_es_ES.tar.bz2:mythes-es caolanm:BADSOURCE:thes_nl_v2.zip:mythes-nl caolanm:BADSOURCE:OOo-Thesaurus2-sk_SK.zip:mythes-sk caolanm:BADSOURCE:thes_sl_SI_v2.zip:mythes-sl sbehera:BADURL:nabi-0.99.3.tar.gz:nabi mmcgrath:BADURL:nagios-plugins-1.4.13.tar.gz:nagios-plugins dwmw2:BADURL:nano-2.0.9.tar.gz:nano frankb:BADURL:nas-1.9.1.src.tar.gz:nas frankb:BAD_CVS_SOURCE:nasd.init:nas bpepple:BADURL:nautilus-image-converter-0.3.0.tar.bz2:nautilus-image-converter thias:BADSOURCE:ncftp-3.2.2-src.tar.bz2:ncftp vcrhonek:BADURL:ncpfs-2.2.6.tar.gz:ncpfs jspaleta:BADSOURCE:nec2c-0.8.tar.gz:nec2c fnasser:BADURL:nekohtml-0.9.5.tar.gz:nekohtml pgordon:BADURL:nemiver-0.7.2.tar.bz2:nemiver lkundrak:BADURL:netbsd-iscsi-20080207.tar.gz:netbsd-iscsi boodle:BADSOURCE:NetPIPE-3.7.1.tar.gz:NetPIPE orphan:BADURL:new-1.3.9.tar.gz:new rathann:BADSOURCE:newsx-1.6.tar.gz:newsx mlichvar:BADURL:newt-0.52.11.tar.gz:newt steved:BADURL:nfs.doc.tar.gz:nfs-utils orphan:BADURL:nhpf-1.42.tar.gz:nhpf sindrepb:BADURL:nikto-2.03.tar.bz2:nikto sandeen:BADSOURCE:nilfs-utils-2.0.14.tar.bz2:nilfs-utils agoode:BADURL:nip2-7.18.2.tar.gz:nip2 msuchy:BADURL:nocpulse-common-2.0.14.tar.gz:nocpulse-common jussilehtola:BADSOURCE:noip-duc-linux.tar.gz:noip davidz:BADURL:notification-daemon-0.4.1.tar.gz:notification-daemon mccann:BADURL:notification-daemon-engine-slider-0.2.0.tar.bz2:notification-daemon-engine-slider mmcgrath:BADURL:nrpe-2.12.tar.gz:nrpe rcritten:BADURL:nss_compat_ossl-0.9.5.tar.gz:nss_compat_ossl nalin:BADURL:nss_db-2.2.tar.gz:nss_db nalin:BADURL:nss_ldap-264.tar.gz:nss_ldap nalin:BADURL:pam_ldap-184.tar.gz:nss_ldap ndim:BADURL:nted-1.8.6.tar.gz:nted rakesh:BADSOURCE:GeoLiteCity.dat.gz:ntop rakesh:BADSOURCE:GeoIPASNum.dat.gz:ntop drago01:BADSOURCE:numlockx-1.0.tar.gz:numlockx mhlavink:BADURL:nut-2.4.1.tar.gz:nut gemi:BADURL:nyqsrc303.zip:nyquist rathann:BADURL:obexftp-0.23.tar.bz2:obexftp dbhole:BADURL:ow_util_ant_tasks_1.3.2.zip:objectweb-anttask fnasser:BAD_CVS_SOURCE:asm-3.1.pom:objectweb-asm gemi:BADSOURCE:ocaml-3.11-refman.html.tar.gz:ocaml gemi:BADSOURCE:ocaml-3.11-refman.pdf:ocaml gemi:BADSOURCE:ocaml-3.11-refman.info.tar.gz:ocaml rjones:BADURL:ocaml-autoconf-1.1.tar.gz:ocaml-autoconf rjones:BADSOURCE:pa_do-0.8.10.tar.gz:ocaml-pa-do jwrdegoede:BADSOURCE:ode-0.11.1.tar.bz2:ode spot:BADSOURCE:chemoelectric_-_Goudy_Bookletter_1.zip:oflb-goudy-bookletter-1911-fonts cjb:BADURL:ohm-0.1.1-1.20080921git.tar.gz:ohm gemi:BADURL:ooRexx-4.0.0-4801.source.tar.gz:oorexx gemi:BADSOURCE:ooRexx-4.0.0-beta-pdf.zip:oorexx sdake:BADURL:openais-1.1.0.tar.gz:openais s4504kr:BADSOURCE:open-cobol-1.1.tar.gz:open-cobol jmoskovc:BADURL:openobex-1.4.tar.gz:openobex dnglaze:BADSOURCE:openocd-0.2.0.tar.gz:openocd aleksey2005:BADURL:openscada-0.6.4.tar.gz:openscada heffer:BADURL:opengfx-0.1.1-source.tar.gz:openttd-opengfx steve:BADSOURCE:openvpn-2.1_rc20.tar.gz:openvpn steve:BADSOURCE:openvpn-2.1_rc20.tar.gz.asc:openvpn lkundrak:BADURL:ovaldi-5.5.25-src.zip:ovaldi rdieter:BADURL:oxygen-icons-4.3.2.tar.bz2:oxygen-icon-theme beekhof:BADSOURCE:ee19d8e83c2a.tar.bz2:pacemaker rrelyea:BADURL:pam_pkcs11-0.5.3.tar.gz:pam_pkcs11 orphan:BADURL:pam-script-0.1.7.tar.gz:pam_script adalloz:BADURL:pan-0.133.tar.bz2:pan behdad:BADURL:pango-1.26.0.tar.bz2:pango ovasik:BADURL:passivetex-1.25.zip:passivetex spot:BADURL:pdsh-2.18.tar.bz2:pdsh orphan:BADURL:pekwm-0.1.5.tar.bz2:pekwm kasal:BADURL:Carp-Clan-6.03.tar.gz:perl-Carp-Clan eseyman:BADURL:CGI-Application-Plugin-FillInForm-1.15.tar.gz:perl-CGI-Application-Plugin-FillInForm hvad:BADURL:Config-Model-0.638.tar.gz:perl-Config-Model ixs:BADURL:DBM-Deep-0.983.tar.gz:perl-DBM-Deep lkundrak:BADURL:HTML-Template-Pro-0.87.tar.gz:perl-HTML-Template-Pro wtogami:BADURL:IO-Socket-INET6-2.56.tar.gz:perl-IO-Socket-INET6 mmaslano:BADURL:JavaScript-Beautifier-0.13.tar.gz:perl-JavaScript-Beautifier ixs:BADURL:MD5-2.03.tar.gz:perl-MD5 rmeggins:BADURL:perl-mozldap-1.5.2.tar.gz:perl-Mozilla-LDAP rmeggins:BADURL:Makefile.PL.rpm:perl-Mozilla-LDAP jussilehtola:BADURL:Net-UPnP-1.41.tar.gz:perl-Net-UPnP mmaslano:BADURL:Padre-0.32.tar.gz:perl-Padre iburrell:BADURL:Path-Class-0.16.tar.gz:perl-Path-Class orion:BADURL:PDL-Graphics-PLplot-0.51.tar.gz:perl-PDL-Graphics-PLplot cweyl:BADURL:POE-1.269.tar.gz:perl-POE cweyl:BADURL:POE-Component-Client-DNS-1.050.tar.gz:perl-POE-Component-Client-DNS cweyl:BADURL:POE-Component-Client-HTTP-0.890.tar.gz:perl-POE-Component-Client-HTTP cweyl:BADURL:POE-Test-Loops-1.022.tar.gz:perl-POE-Test-Loops rakesh:BADURL:Search-Xapian-1.0.15.0.tar.gz:perl-Search-Xapian lkundrak:BADURL:String-Random-0.22.tar.gz:perl-String-Random lkundrak:BADURL:Test-WWW-Selenium-1.18.tar.gz:perl-Test-WWW-Selenium kasal:BADURL:XML-NamespaceSupport-1.10.tar.gz:perl-XML-NamespaceSupport kasal:BADURL:XML-Twig-3.33.tar.gz:perl-XML-Twig steve:BADURL:YAML-0.70.tar.gz:perl-YAML dwmw2:BADURL:libpng-1.2.16.tar.bz2:petitboot green:BADURL:phasex-0.12.0beta4.tar.gz:phasex robert:BADURL:idn_1.2b.tar.gz:php-idn buc:BADURL:phpldapadmin-1.2.0.3.tgz:phpldapadmin mmcgrath:BADURL:phpMyAdmin-3.2.2.1-all-languages.tar.bz2:phpMyAdmin cdamian:BADURL:PhpDocumentor-1.4.3.tgz:php-pear-PhpDocumentor orphan:BAD_CVS_SOURCE:shot1.png:pic2aa gemi:BADSOURCE:pl-5.7.11.tar.gz:pl gemi:BADSOURCE:SWI-Prolog-5.7.11.pdf:pl rstrode:BADURL:plymouth-0.8.0.tar.bz2:plymouth twaugh:BADURL:ppa-0.8.6.tar.gz:pnm2ppa cdamian:BADSOURCE:podcatcher-3.1.5.tar.gz:podcatcher xulchris:BAD_CVS_SOURCE:copyright:poker3d-data dwalsh:BADURL:policycoreutils-2.0.74.tgz:policycoreutils dwalsh:BADURL:sepolgen-1.0.17.tgz:policycoreutils davidz:BADURL:polkit-0.95.git20090913.tar.gz:polkit davidz:BADURL:polkit-gnome-0.95.git20090913.tar.bz2:polkit-gnome tgl:BADURL:postgresql-8.4.1-US.pdf:postgresql tgl:BADSOURCE:pgtcl1.6.2.tar.gz:postgresql tgl:BADSOURCE:pgtcldocs-20070115.zip:postgresql tgl:BADURL:psqlodbc-08.04.0100.tar.gz:postgresql-odbc devrim:BADURL:odbcng-0.99.101.tar.gz:postgresql-odbcng jakub:BADURL:prelink-20090925.tar.bz2:prelink skvidal:BADURL:preupgrade-1.1.2.tar.bz2:preupgrade hubbitus:BADURL:printoxx-1.8.1.tar.gz:printoxx varekova:BADURL:acct-6.3.2.tar.gz:psacct abompard:BADURL:psi-0.13.tar.bz2:psi kanarip:BADURL:publican-genome-1.0.tgz:publican-genome jkeating:BADURL:pungi-2.0.20.tar.bz2:pungi abompard:BADSOURCE:pure-ftpd-1.0.22.tar.bz2:pure-ftpd orphan:BADURL:gaim-galago-0.5.1.tar.bz2:purple-galago bogado:BADURL:puzzles-r8596.tar.gz:puzzles itamarjp:BADURL:pyclutter-0.9.2.tar.bz2:pyclutter bjohnson:BADURL:pygoocanvas-0.14.0.tar.bz2:pygoocanvas mbarnes:BADURL:pygtk-2.16.0.tar.bz2:pygtk2 kanarip:BADURL:pyjigdo-0.4.0.1.tar.gz:pyjigdo spot:BADURL:pyke-1.0.3.tar.gz:pyke spot:BAD_CVS_SOURCE:RELEASE_NOTES-1.0.3:pyke thias:BADSOURCE:pymetar-0.14.tar.gz:pymetar slankes:BADURL:pympdtouchgui-0.309.tgz:pympdtouchgui pfj:BADURL:pyOpenSSL-0.9.tar.gz:pyOpenSSL mbarnes:BADURL:pyorbit-2.24.0.tar.bz2:pyorbit orphan:BADURL:pyrenamer-0.6.0.1.tar.gz:pyrenamer sundaram:BADSOURCE:pyroom-0.4.1.tar.gz:pyroom kwizart:BADURL:PythonCAD-DS1-R36.tar.bz2:PythonCAD mikeb:BADURL:Cheetah-2.2.2.tar.gz:python-cheetah thias:BADURL:Coherence-0.6.4.tar.gz:python-Coherence lmacken:BADURL:configobj-4.6.0.zip:python-configobj dyoung:BADURL:Djblets-0.5rc1.tar.gz:python-djblets toshio:BADSOURCE:python-fedora-0.3.16.tar.gz:python-fedora jamatos:BADURL:HTMLgen.tar.gz:python-HTMLgen mdomsch:BADURL:IPy-0.63.tar.gz:python-IPy mikeb:BADURL:python-krbV-1.0.13.tar.gz:python-krbV huzaifas:BADSOURCE:python-lzo-1.08.tar.gz:python-lzo ianweller:BADSOURCE:e4adff8732c4.tar.bz2:python-mwlib thias:BADSOURCE:Nevow-0.9.32.tar.gz:python-nevow sergiopr:BADURL:numdisplay-1.5.4.tar.gz:python-numdisplay sharkcz:BADURL:openoffice-python-0.1-r34-20090228.tar.bz2:python-openoffice lmacken:BADSOURCE:PEAK-Rules-0.5a1.dev-r2582.tar.gz:python-peak-rules itamarjp:BADURL:Scriptaculous-1.8.2.tar.gz:python-Scriptaculous jortel:BADURL:python-suds-0.3.7.tar.gz:python-suds thias:BADURL:tagpy-0.94.5.tar.gz:python-tag lmacken:BADURL:TestGears-0.2.tar.gz:python-TestGears lmacken:BADSOURCE:TurboFlot-0.1.1.tar.bz2:python-turboflot thomasvs:BADURL:TwistedConch-8.2.0.tar.bz2:python-twisted-conch thomasvs:BADURL:TwistedCore-8.2.0.tar.bz2:python-twisted-core thomasvs:BADURL:TwistedLore-8.2.0.tar.bz2:python-twisted-lore thomasvs:BADURL:TwistedMail-8.2.0.tar.bz2:python-twisted-mail thomasvs:BADURL:TwistedNames-8.2.0.tar.bz2:python-twisted-names thomasvs:BADURL:TwistedNews-8.2.0.tar.bz2:python-twisted-news thomasvs:BADURL:TwistedRunner-8.2.0.tar.bz2:python-twisted-runner thomasvs:BADURL:TwistedWeb-8.2.0.tar.bz2:python-twisted-web thomasvs:BADURL:TwistedWords-8.2.0.tar.bz2:python-twisted-words lmacken:BADSOURCE:tw.jquery-0.9.5.tar.gz:python-tw-jquery fab:BADURL:upoints-0.11.0.tar.bz2:python-upoints lmacken:BADURL:wsgiref-0.1.2.zip:python-wsgiref jbowes:BADURL:ZSI-2.0.tar.gz:python-ZSI jspaleta:BADURL:pytz-2008i.tar.gz:pytz twaugh:BADSOURCE:pyusb-0.4.1.tar.gz:pyusb spot:BADURL:pyxdg-0.17.tar.gz:pyxdg gemi:BADURL:qcad-manual-en-2.0.4.0-1.html.zip:qcad muerte:BADURL:qcomicbook-0.4.0.tar.gz:qcomicbook nbecker:BADSOURCE:qct-1.7.tar.gz:qct john5342:BADSOURCE:0206ec8f2a802bf51455179933d8b7ab3e41a38b.tar.gz:qedje nando:BADURL:qjackctl-0.3.5.tar.gz:qjackctl silfreed:BADSOURCE:QLandkarte_final.tar.gz:qlandkarte stefan:BADURL:qmtest-2.4.1.tar.gz:qmtest chitlesh:BADSOURCE:qsa-x11-free-1.1.5.tar.gz:qt-qsa john5342:BADSOURCE:d32223eae1bba7f1b191c334668f3f7dd662f582.tar.gz:qzion kantrn:BADSOURCE:rainbow-0.8.1.tar.bz2:rainbow giesen:BADURL:rancid-2.3.2.tar.gz:rancid timj:BADURL:rapidsvn-0.10.0.tar.gz:rapidsvn jmoskovc:BADURL:rarpd-ss981107.tar.gz:rarpd spot:BADURL:bigmemory_3.10.tar.gz:R-bigmemory pingou:BADURL:Biostrings_2.12.9.tar.gz:R-Biostrings orion:BADURL:car_1.2-15.tar.gz:R-car jmoskovc:BADURL:rdate-1.4.tar.gz:rdate jmoskovc:BAD_CVS_SOURCE:rdist-eu-license.txt:rdist sindrepb:BADURL:recordmydesktop-0.3.8.1.tar.gz:recordmydesktop sxw:BADURL:remctl-2.11.tar.gz:remctl fabbione:BADSOURCE:e2338892f59f.tar.bz2:resource-agents kanarip:BADURL:revisor-2.1.8.tar.gz:revisor pingou:BADURL:hgu95av2probe_2.4.0.tar.gz:R-hgu95av2probe denisarnaud:BADURL:rmol-0.23.0.tar.gz:rmol denisarnaud:BADURL:msm_0.9.1.tar.gz:R-msm spot:BADURL:nws_2.0.0.3.tar.gz:R-nws than:BADURL:rp-pppoe-3.10.tar.gz:rp-pppoe spot:BADURL:RODBC_1.3-0.tar.gz:R-RODBC kanarip:BADURL:arrayfields-4.7.4.gem:rubygem-arrayfields kanarip:BADSOURCE:attributes-5.0.1.gem:rubygem-attributes lutter:BADSOURCE:gem2rpm-0.6.0.gem:rubygem-gem2rpm kanarip:BADSOURCE:highline-1.5.0.tgz:rubygem-highline kanarip:BADURL:main-4.0.0.gem:rubygem-main kanarip:BADSOURCE:picnic-0.8.1.gem:rubygem-picnic kanarip:BADURL:reststop-0.4.0.gem:rubygem-reststop lutter:BADURL:ruby-postgres-0.7.1.tar.gz:ruby-postgres homeless:BADSOURCE:rudecgi-5.1.0.tar.bz2:rudecgi pbrobinson:BADURL:rygel-0.4.4.tar.bz2:rygel pwouters:BADURL:s3ssrc.zip:s3switch ondrejj:BADURL:sagator-1.2.0-0.beta25.tar.bz2:sagator mbarnes:BADURL:samba-4.0.0alpha8_git20090916.tar.gz:samba4 srini:BADURL:sblim-sfcc-2.1.0.tar.bz2:sblim-sfcc dgoodwin:BADSOURCE:scapy-2.0.0.10.tar.gz:scapy jcollie:BADURL:schroedinger-1.0.8.tar.gz:schroedinger jspaleta:BADSOURCE:ScientificPython-2.8.tar.gz:ScientificPython phuang:BADURL:scim-bridge-0.4.16.tar.gz:scim-bridge sindrepb:BADURL:scratchpad-0.3.0.tar.bz2:scratchpad c4chris:BADURL:seaview_4.0.tar.gz:seaview stefansf:BADURL:sec-2.5.2.tar.gz:sec dwalsh:BADURL:selinux-doc-1.26.tgz:selinux-doc ixs:BADURL:ser-0.9.6_src.tar.gz:ser lucilanga:BADSOURCE:shapelib-1.2.10.tar.gz:shapelib jgu:BADURL:shorewall-4.4.1.tar.bz2:shorewall ausil:BADSOURCE:silo-1.4.14.tar.bz2:silo robert:BADSOURCE:sip-redirect-0.1.2.tar.gz:sip-redirect orphan:BADSOURCE:SmartEiffel-2-3.tar.bz2:smarteiffel jlaska:BADURL:snake-0.11-0.19.tar.bz2:snake ausil:BADURL:snort-2.8.5.1.tar.gz:snort jcollie:BADURL:sofsip-cli-0.16.tar.gz:sofsip-cli hguemar:BADSOURCE:sonata-1.6.2.1.tar.bz2:sonata astokes:BADSOURCE:sos-1.8.tar.gz:sos lennart:BADURL:sound-theme-freedesktop-0.7.tar.bz2:sound-theme-freedesktop mmahut:BADURL:spacechart-0.9.5.tar.gz:spacechart wtogami:BADURL:Mail-SpamAssassin-3.3.0-svn816416.tar.bz2:spamassassin kanarip:BADURL:spin-kickstarts-0.12.0.tar.gz:spin-kickstarts abompard:BADURL:spring_0.80.4.2_src.tar.lzma:spring abompard:BADURL:SmallDivide.sd7:spring-maps-default abompard:BADURL:Comet_Catcher_Redux.sd7:spring-maps-default abompard:BADURL:Sands_of_War_v2.sd7:spring-maps-default gavin:BADURL:Squeak-3.10-5.src.tar.gz:squeak-vm limb:BADSOURCE:blacklists.tgz:squidGuard limb:BAD_CVS_SOURCE:squid-getlist.html:squidGuard mhlavink:BADURL:squirrelmail-1.4.20-RC2_20090917.tar.bz2:squirrelmail ebrand:BADSOURCE:sslogger-0.9.tar.gz:sslogger psklenar:BADURL:stardict-english-czech-20081201.tar.gz:stardict-dic-cs_CZ lkundrak:BADSOURCE:starlab-4.4.3.tar.gz:starlab roland:BADURL:strace-4.5.19.tar.bz2:strace huzaifas:BADSOURCE:stund_0.96_Aug13.tgz:stun mso:BADURL:subtitleeditor-0.34.0.tar.gz:subtitleeditor s4504kr:BADURL:suck-4.3.2.tar.gz:suck mildew:BADURL:sudo-1.7.1.tar.gz:sudo tuxbrewr:BADURL:Terminal-26.tar.bz2:sugar-terminal limb:BADURL:supertuxkart-0.6.2-src.tar.bz2:supertuxkart bpepple:BADURL:swfdec-gnome-2.28.0.tar.bz2:swfdec-gnome deji:BADURL:sword-1.6.0.tar.gz:sword itamarjp:BADURL:sylpheed-2.7.0.tar.bz2:sylpheed awjb:BADURL:synce-sync-engine-0.14.tar.gz:synce-sync-engine awjb:BADURL:synce-trayicon-0.14.tar.gz:synce-trayicon silfreed:BADURL:syslog-ng-2.1.4.tar.gz:syslog-ng nphilipp:BADURL:system-config-date-docs-1.0.8.tar.bz2:system-config-date-docs ajax:BADSOURCE:system-config-display-2.2.tar.bz2:system-config-display nphilipp:BADURL:system-config-nfs-1.3.49.tar.bz2:system-config-nfs nphilipp:BADURL:system-config-nfs-docs-1.0.7.tar.bz2:system-config-nfs-docs nphilipp:BADURL:system-config-samba-1.2.83.tar.bz2:system-config-samba nphilipp:BADURL:system-config-samba-docs-1.0.7.tar.bz2:system-config-samba-docs nphilipp:BADURL:system-config-services-docs-1.1.7.tar.bz2:system-config-services-docs nphilipp:BADURL:system-config-users-1.2.94.tar.bz2:system-config-users nphilipp:BADURL:system-config-users-docs-1.0.7.tar.bz2:system-config-users-docs plautrba:BADURL:sysvinit-2.87dsf.tar.gz:sysvinit jamatos:BADURL:t1lib_5.1.1-3.diff.gz:t1lib pmachata:BADSOURCE:tbb21_20080605oss_src.tgz:tbb bpepple:BADURL:telepathy-sofiasip-0.5.18.tar.gz:telepathy-sofiasip errr:BADURL:tenr-de-styles-pkg-1.1.tar.bz2:tenr-de-styles-pkg rvinyard:BADSOURCE:IEEEtran.zip:tetex-IEEEtran mef:BADURL:tex4ht-1.0.2008_09_16_1413.tar.gz:tetex-tex4ht jnovy:BADURL:dvipsk-jpatch-p1.7a.tar.bz2:texlive jnovy:BADURL:platex209.tar.bz2:texlive-texmf jnovy:BADSOURCE:envlab.tar.lzma:texlive-texmf hman-it:BADURL:themonospot-0.7.3.1.tar.gz:themonospot cwickert:BADURL:thunar-volman-0.3.80.tar.bz2:thunar-volman jjh:BADURL:tinyproxy-1.6.5.tar.gz:tinyproxy deji:BADURL:tokyocabinet-1.4.33.tar.gz:tokyocabinet chitlesh:BADURL:toped-0.9.5.tar.bz2:toped awjb:BADURL:treecc-0.3.8.tar.gz:treecc ssp:BADURL:tsclient-2.0.2.tar.bz2:tsclient lmacken:BADURL:TurboGears-1.0.8.tar.gz:TurboGears lmacken:BADURL:TurboGears2-2.0.3.tar.gz:TurboGears2 trasher:BADURL:tuxmath_w_fonts-1.7.2.tar.gz:tuxmath steve:BADURL:tuxtype_w_fonts-1.7.5.tar.gz:tuxtype2 rakesh:BADURL:txt2rss-01.tar.bz2:txt2rss pmachata:BADURL:tzdata2009o.tar.gz:tzdata dyfet:BADURL:ucommon-2.0.5.tar.gz:ucommon akurtakov:BAD_CVS_SOURCE:doclet-5.1.pom:umlgraph jussilehtola:BADURL:unetbootin-source-358.tar.gz:unetbootin dchen:BADSOURCE:Unihan.zip:UnihanDb varekova:BADURL:unzip552.tar.gz:unzip kzak:BADURL:util-linux-ng-2.17-git5e51568.tar.bz2:util-linux-ng ensc:BADURL:util-vserver-0.30.215+svn2847.tar.bz2:util-vserver lmacken:BADURL:valknut-0.4.9-gnome-icons.tar.gz:valknut wart:BADURL:varconf-0.6.6.tar.bz2:varconf ajax:BADURL:vbetool-1.2.1.tar.bz2:vbetool icon:BADSOURCE:verbiste-0.1.26.tar.gz:verbiste dirjud:BADURL:verilator-3.712.tgz:verilator jima:BADSOURCE:videodog0.31.tar.gz:videodog karsten:BADSOURCE:vim-7.2.tar.bz2:vim agoode:BADURL:vips-7.18.2.tar.gz:vips dwayne:BADURL:virtaal-0.4.1.tar.bz2:virtaal kzak:BADURL:vlock-1.3.tar.gz:vlock kdudka:BADURL:vorbis-tools-1.2.0.tar.gz:vorbis-tools behdad:BADURL:vte-0.22.2.tar.bz2:vte athimm:BADURL:vtkdata-5.4.2.tar.gz:vtkdata limb:BADURL:vym-1.12.4.tar.bz2:vym tagoh:BADURL:emacs-w3m-1.4.367.tar.gz:w3m-el mtasaka:BADURL:wallpapoz-0.4.1-svn92_trunk.tar.bz2:wallpapoz laxathom:BADURL:wammu-0.30.1.tar.bz2:wammu karlik:BADURL:warzone2100-2.2.1.tar.bz2:warzone2100 karlik:BADURL:sequences.wz:warzone2100 fab:BADSOURCE:wavemon-0.6.7.tar.bz2:wavemon sergiopr:BADURL:wcslib-4.3.1.tar.gz:wcslib sergiopr:BADURL:wcstools-3.7.0.tar.gz:wcstools ruben:BADURL:whatsup-1.9.tar.gz:whatsup edhill:BADURL:wifiroamd-1.14.tar.gz:wifiroamd awjb:BADURL:WindowMaker-0.92.0.tar.bz2:WindowMaker awjb:BADURL:WindowMaker-extra-0.1.tar.gz:WindowMaker awjb:BAD_CVS_SOURCE:winepulse-0.32-configure.ac.patch:wine awjb:BAD_CVS_SOURCE:wmweather+-2.9.tar.gz:wmweather+ lonetwin:BADURL:WordNet-3.0.tar.bz2:wordnet ianweller:BADSOURCE:add-to-any.0.9.9.2.3.zip:wordpress-plugin-add-to-any ianweller:BADSOURCE:add-to-any-subscribe.0.9.6.4.1.zip:wordpress-plugin-add-to-any-subscribe kzak:BADURL:mwords.tar.Z:words than:BADURL:wordtrans_1.1pre13.tar.gz:wordtrans than:BAD_CVS_SOURCE:French.txt:wordtrans caolanm:BADURL:1.0.tar.gz:writer2latex dchen:BADSOURCE:WritRecogn-0.1.9.tar.gz:WritRecogn srini:BADURL:wsmancli-2.1.0.tar.bz2:wsmancli dgoodwin:BADURL:wuja-0.0.8.tar.gz:wuja dp67:BADSOURCE:wxapt-1.3.tar.gz:wxapt ensc:BADURL:xca-0.7.0.tar.gz:xca sindrepb:BADURL:xdotool-20090815.tar.gz:xdotool xen-maint:BADURL:xen-3.4.1.tar.gz:xen jmoskovc:BADURL:xferstats-2.16.tar.gz:xferstats bjensen:BADSOURCE:xfhell-1.9.tar.gz:xfhell sandeen:BADURL:xfsprogs-3.0.3.tar.gz:xfsprogs limb:BADURL:xgalaga_2.0.34-44.diff.gz:xgalaxy dwalsh:BADURL:xguest-1.0.7.tar.bz2:xguest spot:BAD_CVS_SOURCE:xmbdfed.png:xmbdfed ovasik:BADURL:xmltex-1.9.tar.gz:xmltex pcheung:BAD_CVS_SOURCE:xmlunit-1.0.pom:xmlunit rathann:BADURL:xmp-2.7.1-free.tar.gz:xmp bjensen:BADSOURCE:xnec2c-1.2.tar.gz:xnec2c terjeros:BAD_CVS_SOURCE:XOsview.png:xosview cassmodiah:BADURL:xpad-4.0.tar.bz2:xpad oget:BADURL:xsynth-dssi-0.9.2.tar.gz:xsynth-dssi dp67:BADSOURCE:xwxapt-1.2.tar.gz:xwxapt jnovy:BADURL:xz-4.999.9beta.20091007git.tar.xz:xz dwmw2:BADSOURCE:yaboot-1.3.14.tar.gz:yaboot rakesh:BADURL:yum-plugin-download-order-0.2.tar.gz:yum-plugin-download-order varekova:BADURL:zip231.tar.gz:zip varekova:BADURL:zcrypt29.tar.gz:zip varekova:BADURL:zlib-1.2.3.tar.bz2:zlib green:BADURL:ZynAddSubFX-2.4.0.tar.bz2:zynaddsubfx thias:BADURL:zziplib-0.13.49.tar.bz2:zziplib -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From sundaram at fedoraproject.org Thu Nov 5 00:18:31 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 05 Nov 2009 05:48:31 +0530 Subject: source file audit - 2009-11-01 In-Reply-To: <20091104171816.0ef2c0a5@ohm.scrye.com> References: <20091104171816.0ef2c0a5@ohm.scrye.com> Message-ID: <4AF219D7.4080206@fedoraproject.org> On 11/05/2009 05:48 AM, Kevin Fenzi wrote: > sundaram:BADSOURCE:cryptopp560.zip:cryptopp Upstream source modified to remove patent encumbered portions. Rahul From poelstra at redhat.com Thu Nov 5 00:33:57 2009 From: poelstra at redhat.com (John Poelstra) Date: Wed, 04 Nov 2009 16:33:57 -0800 Subject: Web page for distro life cycle stage In-Reply-To: References: Message-ID: <4AF21D75.9040302@redhat.com> Shakthi Kannan said the following on 11/03/2009 08:51 AM Pacific Time: > Hi, > > Is there a web-page or is it possible to have one that shows the > Fedora distro release and its stage in the release cycle? Would this page help? If so, setting a page watch might be helpful. https://fedoraproject.org/wiki/Releases John From poelstra at redhat.com Thu Nov 5 00:50:59 2009 From: poelstra at redhat.com (John Poelstra) Date: Wed, 04 Nov 2009 16:50:59 -0800 Subject: Upcoming schedule tasks Message-ID: <4AF22173.2070503@redhat.com> Start End Name Wed 04-Nov Wed 04-Nov Compose RC Wed 04-Nov Wed 04-Nov Enable Fedora 12 Updates Wed 04-Nov Wed 11-Nov Test RC Fri 06-Nov Fri 06-Nov Blocker Bug Day (F12Blocker) #3 Mon 09-Nov Mon 09-Nov F12 Blocker Review (go/no go) 1 PM EST Wed 11-Nov Wed 11-Nov F12 Project Wide Release Readiness Meeting Thu 12-Nov Thu 12-Nov Start Stage & Sync RC to Mirrors Thu 12-Nov Tue 17-Nov Stage & Sync RC to Mirrors Fri 13-Nov Fri 13-Nov Final Export Control Reporting Tue 17-Nov Tue 17-Nov GA Release From bruno at wolff.to Thu Nov 5 02:42:22 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 4 Nov 2009 20:42:22 -0600 Subject: help debugging segfault with alienarena 7.32 In-Reply-To: <4AF20A6A.8060200@redhat.com> References: <4AF05E46.5090404@redhat.com> <870180fe0911031116l3c7af629o245bcae3c4a2c940@mail.gmail.com> <4AF09144.8070300@redhat.com> <4AF1EE48.7050102@redhat.com> <20091104222643.GA2007@wolff.to> <4AF20A6A.8060200@redhat.com> Message-ID: <20091105024222.GA5782@wolff.to> On Wed, Nov 04, 2009 at 18:12:42 -0500, Tom spot Callaway wrote: > > Looks like alienarena defaults to ALSA. When I tell it to tell > OpenAL-soft to use "PulseAudio Software", it doesn't actually make any > sound at all, even though PulseAudio sees the application trying to do so. Thanks for checking. It looks like I should start by filing a bug or two against OpenAL-soft and see what the maintainer says. From bruno at wolff.to Thu Nov 5 02:57:42 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 4 Nov 2009 20:57:42 -0600 Subject: source file audit - 2009-11-01 In-Reply-To: <20091104171816.0ef2c0a5@ohm.scrye.com> References: <20091104171816.0ef2c0a5@ohm.scrye.com> Message-ID: <20091105025742.GB17486@wolff.to> On Wed, Nov 04, 2009 at 17:18:16 -0700, Kevin Fenzi wrote: > Here's attached another run of my sources/patches url checker. > > bruno:BADURL:glest_data_3.2.1.zip:glest-data I took over glest recently and hadn't had to worry about where the sources had come from yet. The next time I make a change I'll be sure to make sure that the source URLs are accurate. P.S. If the audiance for this report is developers, I think it would make more sense to sort on the FAS name and then on package name. From andre at bwh.harvard.edu Thu Nov 5 06:24:13 2009 From: andre at bwh.harvard.edu (Andre Robatino) Date: Thu, 05 Nov 2009 01:24:13 -0500 Subject: magic numbers for deltarpms and deltaisos Message-ID: <4AF26F8D.4080808@bwh.harvard.edu> The file command appears to detect deltarpms as the same type of file as regular RPMs. Deltaisos are only detected as "data". Is this normal behavior? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jdieter at gmail.com Thu Nov 5 07:00:52 2009 From: jdieter at gmail.com (Jonathan Dieter) Date: Thu, 05 Nov 2009 09:00:52 +0200 Subject: magic numbers for deltarpms and deltaisos In-Reply-To: <4AF26F8D.4080808@bwh.harvard.edu> References: <4AF26F8D.4080808@bwh.harvard.edu> Message-ID: <1257404452.2524.3.camel@jdlaptop.lesbg.loc> On Thu, 2009-11-05 at 01:24 -0500, Andre Robatino wrote: > The file command appears to detect deltarpms as the same type of file as > regular RPMs. Deltaisos are only detected as "data". Is this normal > behavior? A deltarpm's header is identical to a rpm's header (except that the payload format is "drpm"), so it will always be seen as an rpm by file. I'm not sure about deltaiso. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bioinfornatics at gmail.com Thu Nov 5 07:20:01 2009 From: bioinfornatics at gmail.com (Jonathan MERCIER) Date: Thu, 05 Nov 2009 08:20:01 +0100 Subject: Pyhton image In-Reply-To: References: <1257376677.31894.1.camel@localhost.localdomain> Message-ID: <1257405601.1781.5.camel@localhost.localdomain> Le mercredi 04 novembre 2009 ? 17:45 -0600, Jason L Tibbitts III a ?crit : > >>>>> "JM" == Jonathan MERCIER writes: > > JM> Dear sir, I have open a bug: > JM> https://bugzilla.redhat.com/show_bug.cgi?id=532248 > JM> But i have any answer! What can i do? > > Somehow acquire patience? Work on debugging the problem yourself? You > haven't given much time at all for the volunteer on the other end of > that bug report to look at it (not even three weekdays). > > - J< > Okay, for the moment i save the picture in hard disk and i use popen method. In other distribution like debian,ubuntu show method use xv, on fedora eog. It is just my very little contribution, i have no idea why eog fail sorry. Thanks for all -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcepl at redhat.com Thu Nov 5 08:06:50 2009 From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=) Date: Thu, 05 Nov 2009 09:06:50 +0100 Subject: Ubuntu shows updates / security updates on shell logins In-Reply-To: References: <20091104165030.GA25940@amd.home.annexia.org> Message-ID: <4AF2879A.3040306@redhat.com> Dne 4.11.2009 18:11, Richard June napsal(a): > It's a good idea for one off jobs where the primary user is also the > admin, but not so good for shared systems. Personally I think a better > plan would be to display that information *only* if the user is > flagged as an administrator, group root, wheel, etc. I guess, aren't Fedora admins supposed to write a procmail script which would filter out email from yum-cron with some particular subject to a file and then display it via /root/.profile? Mat?j -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC If Patrick Henry thought that taxation without representation was bad, he should see how bad it is with representation. From mcepl at redhat.com Thu Nov 5 08:06:50 2009 From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=) Date: Thu, 05 Nov 2009 09:06:50 +0100 Subject: Ubuntu shows updates / security updates on shell logins In-Reply-To: References: <20091104165030.GA25940@amd.home.annexia.org> Message-ID: <4AF2879A.3040306@redhat.com> Dne 4.11.2009 18:11, Richard June napsal(a): > It's a good idea for one off jobs where the primary user is also the > admin, but not so good for shared systems. Personally I think a better > plan would be to display that information *only* if the user is > flagged as an administrator, group root, wheel, etc. I guess, aren't Fedora admins supposed to write a procmail script which would filter out email from yum-cron with some particular subject to a file and then display it via /root/.profile? Mat?j -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC If Patrick Henry thought that taxation without representation was bad, he should see how bad it is with representation. From jnovy at redhat.com Thu Nov 5 08:26:47 2009 From: jnovy at redhat.com (Jindrich Novy) Date: Thu, 5 Nov 2009 09:26:47 +0100 Subject: texlive-2009 breakage? In-Reply-To: <0689d791c3e365f9091126902656c644.squirrel@arekh.dyndns.org> References: <20091104082845.GD5888@dhcp-lab-133.englab.brq.redhat.com> <0689d791c3e365f9091126902656c644.squirrel@arekh.dyndns.org> Message-ID: <20091105082647.GA7711@dhcp-lab-133.englab.brq.redhat.com> On Wed, Nov 04, 2009 at 10:34:14AM +0100, Nicolas Mailhot wrote: > > BTW Jindrich, I know you are very busy, and we never seem to be on irc at the > same times, but how is progress on the texlive font packaging front? > > Font automation QA has progressed quite a bit since you started, you can > self-check your progress with repo-font-audit now if you want: > > http://kojipkgs.fedoraproject.org/packages/fontpackages/1.31/2.fc13/noarch/fontpackages-tools-1.31-2.fc13.noarch.rpm > Thanks, the audit of the most recent TL repository is now available here: http://jnovy.fedorapeople.org/texlive/font-audit/ Some results would be interesting for upstream as well. It is good to hear from you because I have a proposal for the modification of macros.fonts in the "fontpackages". The reason is that I had to manually hack it in order to let the TeX Live auto-generation pass. The problem is that TeX Live provides a package "Asana-Math" which provides couple of fonts. Note that there are upper case letters in the name. In the macros.fonts you enforce conversion of the package name to lower case which breaks build and inter-package dependencies because you have: texlive-Asana-Math texlive-Asana-Math-doc and texlive-asana-math-fedora-fonts generated by %_font_pkg macro in macros.fonts. It requires texlive-asana-math package which doesn't exist due to erroneous conversion to lower case. Patch to fix macros.fonts is attached. Thanks, Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ -------------- next part -------------- --- macros.fonts 2009-11-01 20:06:41.000000000 +0100 +++ macros.fonts.new 2009-09-30 21:04:31.000000000 +0200 @@ -34,7 +34,7 @@ if sname == name then return "" else - sname = string.lower("-" .. sname .. "-") + sname = "-" .. sname .. "-" sname = string.gsub(sname, "[_%-]+", "-") sname = string.gsub(sname, "%-font(s?)%-", "-") sname = string.gsub(sname, "^%-", "") From nicolas.mailhot at laposte.net Thu Nov 5 09:08:08 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 5 Nov 2009 10:08:08 +0100 Subject: texlive-2009 breakage? In-Reply-To: <20091105082647.GA7711@dhcp-lab-133.englab.brq.redhat.com> References: <20091104082845.GD5888@dhcp-lab-133.englab.brq.redhat.com> <0689d791c3e365f9091126902656c644.squirrel@arekh.dyndns.org> <20091105082647.GA7711@dhcp-lab-133.englab.brq.redhat.com> Message-ID: <134c9b23dd16de6c0598f1ccc054cbeb.squirrel@arekh.dyndns.org> Le Jeu 5 novembre 2009 09:26, Jindrich Novy a ?crit : Hi Jindrich, > It is good to hear from you because I have a proposal for the > modification of macros.fonts in the "fontpackages". The reason is that > I had to manually hack it in order to let the TeX Live auto-generation > pass. > > The problem is that TeX Live provides a package "Asana-Math" which > provides couple of fonts. Note that there are upper case letters in > the name. Using lowercase is part of the fonts packaging guidelines. If we wanted to use font names as-is we'd have to authorize utf-8 package names (with codepoints outside the basic latin block), since font names are not necessarily basic latin (and in fact we *already* have several fonts in the distro with unicode names). Since FESCO decided unicode package names were a no-go, we frob package names completely fonts side and also lowercase them (as Debian, Suse, etc do; mixed case packages do not work on windows servers and FAT flash keys and are a nuisance for users). Lastly many upstreams do not use consistent casing for their font names (depending on the naming layer you look at) and for that reason fontconfig has to lowercase font names by default before processing (though it has to accept unicode names, and lowercases them according to unicode rules). Besides Asana is already packaged Fedora-side using the most recent upstream version IIRC. > Patch to fix macros.fonts is attached. I really do not wish to allow a case that goes against current font packaging guidelines all our font packages already respect (since, as you noted, it does not work if they don't). -- Nicolas Mailhot From mls at suse.de Thu Nov 5 09:48:37 2009 From: mls at suse.de (Michael Schroeder) Date: Thu, 5 Nov 2009 10:48:37 +0100 Subject: magic numbers for deltarpms and deltaisos In-Reply-To: <1257404452.2524.3.camel@jdlaptop.lesbg.loc> References: <4AF26F8D.4080808@bwh.harvard.edu> <1257404452.2524.3.camel@jdlaptop.lesbg.loc> Message-ID: <20091105094837.GB17072@suse.de> On Thu, Nov 05, 2009 at 09:00:52AM +0200, Jonathan Dieter wrote: > On Thu, 2009-11-05 at 01:24 -0500, Andre Robatino wrote: > > The file command appears to detect deltarpms as the same type of file as > > regular RPMs. Deltaisos are only detected as "data". Is this normal > > behavior? > > A deltarpm's header is identical to a rpm's header (except that the > payload format is "drpm"), so it will always be seen as an rpm by file. That's true for "header" deltarpms, but "rpm-only" delta rpms start with "drpm". > I'm not sure about deltaiso. They start with "DISO" and then 4 bytes deltaiso version in network byte order. Cheers, Michael. -- Michael Schroeder mls at suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} From rjones at redhat.com Thu Nov 5 11:39:04 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 5 Nov 2009 11:39:04 +0000 Subject: source file audit - 2009-11-01 In-Reply-To: <20091104171816.0ef2c0a5@ohm.scrye.com> References: <20091104171816.0ef2c0a5@ohm.scrye.com> Message-ID: <20091105113904.GA1660@amd.home.annexia.org> On Wed, Nov 04, 2009 at 05:18:16PM -0700, Kevin Fenzi wrote: > rjones:BADURL:ocaml-autoconf-1.1.tar.gz:ocaml-autoconf False alarm? Both the URL and Source0 work for me, but note that the site has a self-signed certificate so you need "--no-check-certificate" or the equivalent to download the source: wget --no-check-certificate https://forge.ocamlcore.org/frs/download.php/282/ocaml-autoconf-1.1.tar.gz > rjones:BADSOURCE:pa_do-0.8.10.tar.gz:ocaml-pa-do This is the same hosting provider as above, and I can definitely access the URL and Source0 from here. wget --no-check-certificate http://forge.ocamlcore.org/frs/download.php/273/pa_do-0.8.10.tar.gz > rjones:BADURL:coccinelle-0.1.10.tgz:coccinelle Upstream moved their website hosting. Fixed by rebuilding all the branches. > rjones:BADURL:febootstrap-2.5.tar.gz:febootstrap Fixed (upstream website problem). > rjones:BADURL:libpng-1.2.37.tar.bz2:mingw32-libpng Ugghh, upstream like to remove old copies of their source tarballs. Fixed and rebuilt in Rawhide only, because I don't want to push unstable updates to the other branches and there's no way to fix those other branches if the upstream tarball has gone. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 mschmidt at redhat.com Thu Nov 5 11:53:25 2009 From: mschmidt at redhat.com (Michal Schmidt) Date: Thu, 05 Nov 2009 12:53:25 +0100 Subject: source file audit - 2009-11-01 In-Reply-To: <20091105113904.GA1660@amd.home.annexia.org> References: <20091104171816.0ef2c0a5@ohm.scrye.com> <20091105113904.GA1660@amd.home.annexia.org> Message-ID: <4AF2BCB5.3070302@redhat.com> Dne 5.11.2009 12:39, Richard W.M. Jones napsal: >> rjones:BADURL:coccinelle-0.1.10.tgz:coccinelle > > Upstream moved their website hosting. Fixed by rebuilding all the > branches. I don't think rebuilding solely for this reason is necessary. Making the change in CVS should be just enough. Michal From jnovy at redhat.com Thu Nov 5 11:53:48 2009 From: jnovy at redhat.com (Jindrich Novy) Date: Thu, 5 Nov 2009 12:53:48 +0100 Subject: texlive-2009 breakage? In-Reply-To: <134c9b23dd16de6c0598f1ccc054cbeb.squirrel@arekh.dyndns.org> References: <20091104082845.GD5888@dhcp-lab-133.englab.brq.redhat.com> <0689d791c3e365f9091126902656c644.squirrel@arekh.dyndns.org> <20091105082647.GA7711@dhcp-lab-133.englab.brq.redhat.com> <134c9b23dd16de6c0598f1ccc054cbeb.squirrel@arekh.dyndns.org> Message-ID: <20091105115348.GA2208@dhcp-lab-133.englab.brq.redhat.com> Hi Nicolas, On Thu, Nov 05, 2009 at 10:08:08AM +0100, Nicolas Mailhot wrote: > > > Le Jeu 5 novembre 2009 09:26, Jindrich Novy a ?crit : > > Hi Jindrich, > > > It is good to hear from you because I have a proposal for the > > modification of macros.fonts in the "fontpackages". The reason is that > > I had to manually hack it in order to let the TeX Live auto-generation > > pass. > > > > The problem is that TeX Live provides a package "Asana-Math" which > > provides couple of fonts. Note that there are upper case letters in > > the name. > > Using lowercase is part of the fonts packaging guidelines. If we wanted to use > font names as-is we'd have to authorize utf-8 package names (with codepoints > outside the basic latin block), since font names are not necessarily basic > latin (and in fact we *already* have several fonts in the distro with unicode > names). Since FESCO decided unicode package names were a no-go, we frob > package names completely fonts side and also lowercase them (as Debian, Suse, > etc do; mixed case packages do not work on windows servers and FAT flash keys > and are a nuisance for users). Lastly many upstreams do not use consistent > casing for their font names (depending on the naming layer you look at) and > for that reason fontconfig has to lowercase font names by default before > processing (though it has to accept unicode names, and lowercases them > according to unicode rules). > > Besides Asana is already packaged Fedora-side using the most recent upstream > version IIRC. > > > Patch to fix macros.fonts is attached. > > I really do not wish to allow a case that goes against current font packaging > guidelines all our font packages already respect (since, as you noted, it does > not work if they don't). > Ok, thanks for the background. First I thought it is an unintentional mistake, it makes sense now. It would be better if the TL package generator handles the Asana fonts in a special way since there is only one such problematic package in the whole TeX Live distribution. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From andre at bwh.harvard.edu Thu Nov 5 12:02:22 2009 From: andre at bwh.harvard.edu (Andre Robatino) Date: Thu, 05 Nov 2009 07:02:22 -0500 Subject: magic numbers for deltarpms and deltaisos Message-ID: <4AF2BECE.7020503@bwh.harvard.edu> In addition to deltaisos, I found that rpm-only deltarpms are also not recognized, and filed https://bugzilla.redhat.com/show_bug.cgi?id=533151 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From joost at cnoc.nl Thu Nov 5 12:42:55 2009 From: joost at cnoc.nl (Joost van der Sluis) Date: Thu, 05 Nov 2009 13:42:55 +0100 Subject: Including windows-binary files for cross compiling into package In-Reply-To: <20091103125606.GA15146@amd.home.annexia.org> References: <1256579896.23821.186.camel@wsjoost.cnoc.lan> <20091026181502.919B02747@magilla.sf.frob.com> <1256582576.23821.193.camel@wsjoost.cnoc.lan> <20091103125606.GA15146@amd.home.annexia.org> Message-ID: <1257424975.26257.18.camel@wsjoost.cnoc.lan> On Tue, 2009-11-03 at 12:56 +0000, Richard W.M. Jones wrote: > On Mon, Oct 26, 2009 at 07:42:56PM +0100, Joost van der Sluis wrote: > > On Mon, 2009-10-26 at 11:15 -0700, Roland McGrath wrote: > > > If it's true cross support, then that should be a noarch package and the > > > file names it uses should not depend on %{_lib} that way. > > > Arguably it even belongs in %{_sharedir}, since it is fixed binary content > > > across all host machines. > > > > Those files are not architecture independent. They are somewhat similar > > to .o files. They contain the run time library for the language, > > compiled to native windows object files. If you want to compile your own > > program with them afterwards, they are linked together into a windows > > executable. > > > > You could argue that they should belong in a -devel package. But since > > this package is a compiler, we decided not to split it up into a devel > > package and a non-devel package. As that would be pointless, as one will > > not work without the other. > > Sorry, I'm late on this one. Yes the files *are* arch independent > from the point of view of the host, so they should be noarch. That's true. > Anyway you may find the Fedora MinGW packaging guidelines to be > helpful, and it would be useful to make your package compatible with > the other ones, even if that deviates from upstream a little bit. A little bit? Did you read my other mail on the subject: "That's an idea, but then we would be incompatible with upstream. I can try to patch the configuration files of fpc so that it searches for these binaries in /usr/x86_64-pc-fpc/sys-root/fpc/lib. But I prefer the 'standard' location. Also because other packages based in fpc relay on that. And what I've read here is that this path is chosen because mingw needs a root filesystem location. Fpc does not need that, so I think I keep the default locations, if that's ok." The thing is that fpc does not need a complete build-environment or something like that. It's just the compiler, one executable. Nothing more. And offcourse the compiled object-files, we are discussing the locations of these files only. I think I can patch the compiler and it's configuration files. But I think it's not really doable to patch Lazarus, a freepacal-ide, to use these paths. > We've also packaged some things, such as the OCaml cross-compiler, > which sound very similar to the Pascal case you describe. I can have a look. > http://fedoraproject.org/wiki/Packaging/MinGW Another thing, the MinGW packaging guidelines needs the packages to have a 'MinGw' prefix, not suffix. My example used a suffix, like 'fpc-win32'. Do you think I should use 'win32-fpc' instead? Again: this sounds logical when you have a complete build-environment or something like that. But in this case I think 'fpc-win32' is more logical. Joost From debarshi.ray at gmail.com Thu Nov 5 13:39:55 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Thu, 5 Nov 2009 15:39:55 +0200 Subject: Current libgdl induced mess Message-ID: <3170f42f0911050539w311b74b8hade46a117c7c7e0e@mail.gmail.com> Actually I had requested a freeze override for Anjuta and libgdl [1] causing the mess. Actually the changes between 2.27.92 to 2.28.0 included the addition of an extra enum value to GdlSwitcherStyle and I did not expect this to cause a bump in the soname. But it was bumped and I failed to notice it. My mistake. This new enum value is not being used as far as I know, so how do you propose we clean this? Untag the new libgdl or rebuild the other packages? Sorry, Debarshi [1] https://fedorahosted.org/rel-eng/ticket/3087 -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig From christoph.wickert at googlemail.com Thu Nov 5 13:48:37 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Thu, 05 Nov 2009 14:48:37 +0100 Subject: source file audit - 2009-11-01 In-Reply-To: <20091104171816.0ef2c0a5@ohm.scrye.com> References: <20091104171816.0ef2c0a5@ohm.scrye.com> Message-ID: <1257428917.8553.5.camel@wicktop.localdomain> Am Mittwoch, den 04.11.2009, 17:18 -0700 schrieb Kevin Fenzi: > Here's attached another run of my sources/patches url checker. ... > cwickert:BADURL:timer-applet-2.1.2.tar.gz:gnome-applet-timer fixed in CVS > cwickert:BADURL:lxde-settings-daemon-0.4.tar.bz2:lxde-settings-daemon lxde-settings-daemon will be merged into lxsession. This aldreay happened in SVN, but nothing was yet released. Looks like they removed the old file to early. Will talk to upstream to get it back. > cwickert:BADURL:thunar-volman-0.3.80.tar.bz2:thunar-volman fixed in CVS Regards, Christoph From rawhide at fedoraproject.org Thu Nov 5 13:50:00 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Thu, 5 Nov 2009 13:50:00 +0000 Subject: rawhide report: 20091105 changes Message-ID: <20091105135000.GA22384@releng2.fedora.phx.redhat.com> Compose started at Thu Nov 5 08:15:10 UTC 2009 Broken deps for i386 ---------------------------------------------------------- 1:anjuta-2.28.1.0-1.fc12.i686 requires libgdl-1.so.2 gnome-python2-gdl-2.25.3-12.fc12.i686 requires libgdl-1.so.2 gtranslator-1.9.6-1.fc12.i686 requires libgdl-1.so.2 solang-0.3-1.fc12.i686 requires libgdl-1.so.2 Broken deps for x86_64 ---------------------------------------------------------- 1:anjuta-2.28.1.0-1.fc12.i686 requires libgdl-1.so.2 1:anjuta-2.28.1.0-1.fc12.x86_64 requires libgdl-1.so.2()(64bit) gnome-python2-gdl-2.25.3-12.fc12.x86_64 requires libgdl-1.so.2()(64bit) gtranslator-1.9.6-1.fc12.x86_64 requires libgdl-1.so.2()(64bit) solang-0.3-1.fc12.x86_64 requires libgdl-1.so.2()(64bit) Broken deps for ppc ---------------------------------------------------------- 1:anjuta-2.28.1.0-1.fc12.ppc requires libgdl-1.so.2 1:anjuta-2.28.1.0-1.fc12.ppc64 requires libgdl-1.so.2()(64bit) gnome-python2-gdl-2.25.3-12.fc12.ppc requires libgdl-1.so.2 gtranslator-1.9.6-1.fc12.ppc requires libgdl-1.so.2 solang-0.3-1.fc12.ppc requires libgdl-1.so.2 Broken deps for ppc64 ---------------------------------------------------------- 1:anjuta-2.28.1.0-1.fc12.ppc64 requires libgdl-1.so.2()(64bit) gnome-python2-gdl-2.25.3-12.fc12.ppc64 requires libgdl-1.so.2()(64bit) gtranslator-1.9.6-1.fc12.ppc64 requires libgdl-1.so.2()(64bit) solang-0.3-1.fc12.ppc64 requires libgdl-1.so.2()(64bit) New package 9wm Emulation of the Plan 9 window manager 8 1/2 Updated Packages: NetworkManager-0.7.996-6.git20091021.fc12 ----------------------------------------- * Wed Nov 04 2009 Dan Williams - 0.7.996-6.git20091021 - nm: fix PPPoE connection authentication (rh #532862) R-hdf5-1.6.9-4.fc12 ------------------- * Wed Nov 04 2009 Tom "spot" Callaway - 1.6.9-4 - Rebuild for hdf5-1.8.3 alienarena-7.32-1.fc12 ---------------------- * Mon Nov 02 2009 Tom "spot" Callaway - 7.32-1 - update to 7.32 - fix CVE-2009-3637 (bugzilla 530514) alienarena-data-20091102-1.fc12 ------------------------------- * Mon Nov 02 2009 Tom "spot" Callaway 20091102-1 - update to 20091102 (7.32) anaconda-12.44-1.fc12 --------------------- * Wed Nov 04 2009 David Cantrell - 12.44-1 - Correctly initialize modopts in loader (#531932). (dcantrell) anjuta-2.28.1.0-1.fc12 ---------------------- * Thu Oct 29 2009 Debarshi Ray - 1:2.28.1.0-1 - Version bump to 2.28.1.0. * Debug manager plugin: + Report error when location is < 0 for markers. (GNOME Bugzilla #593954) * File loader plugin: + Improved drag-and-drop behaviour. (GNOME Bugzilla #567363) * GtkSourceView editor plugin: + Improved drag-and-drop behaviour. (GNOME Bugzilla #355151) * Subversion plugin: + Removed duplicate IDs from the Glade file. (GNOME Bugzilla #596001) * Symbol-db plugin: + Fixed crash when loading a project. (GNOME Bugzilla #597113) * Terminal plugin: + Prevented it from crashing and freezing X. (GNOME Bugzilla #597318) * http://download.gnome.org/sources/anjuta/2.28/anjuta-2.28.1.0.news - Added 'BuildRequires: GConf2-devel ORBit2-devel' and removed 'BuildRequires: binutils-devel graphviz-devel libgnomeui-devel pcre-devel'. aria2-1.6.3-1.fc12 ------------------ * Wed Nov 04 2009 Rahul Sundaram - 1.6.3-1 - Minor bug fixes - http://aria2.svn.sourceforge.net/viewvc/aria2/trunk/NEWS?revision=1616 calibre-0.6.20-1.fc12 --------------------- * Wed Nov 04 2009 Ionu? Ar??ri?i - 0.6.20-1 - new upstream version: http://calibre.kovidgoyal.net/wiki/Changelog#Version0.6.2030Oct2009 - upstream now ships correct .desktop files - fixed missing dependency: PyQt4 - fixed calibre-gui icon eclipse-photran-5.0.0-0.4.200910081739.fc12 ------------------------------------------- * Wed Nov 04 2009 Orion Poplawski - 5.0.0-0.4.200910081739 - Exclude ppc64 fedora-logos-12.0.3-2.fc12 -------------------------- * Wed Nov 04 2009 Tom "spot" Callaway - 12.0.3-2 - kde icon installation generic-logos-12.2-2.fc12 ------------------------- * Wed Nov 04 2009 Tom "spot" Callaway - 12.2-2 - kde icon installation gnome-vfs2-2.24.2-2.fc12 ------------------------ * Wed Nov 04 2009 Bastien Nocera 2.24.2-2 - Set a default media player application in the schemas gxmessage-2.12.4-1.fc12 ----------------------- * Wed Sep 30 2009 Christoph Wickert - 2.12.4-1 - Update to 2.12.4 ibus-1.2.0.20091024-1.fc12 -------------------------- * Sat Oct 24 2009 Peng Huang - 1.2.0.2001024-1 - Update to 1.2.0.20091024 jack-audio-connection-kit-0.116.2-1.fc12 ---------------------------------------- * Wed Nov 04 2009 Tom "spot" Callaway - 0.116.2-8 - update to 0.116.2 - make sure we cleanup threads that we open, fixes segfaults (thanks to Ray Strode) jbrout-0.3.211-20091105svn270.1.fc12 ------------------------------------ * Thu Nov 05 2009 Rahul Sundaram - 0.3.211-20091105svn270.1 - Pull latest svn snapshot - Add dependencies to fix startup crash and improve performance kdeaccessibility-4.3.2-2.fc12 ----------------------------- * Tue Nov 03 2009 Than Ngo - 4.3.2-2 - rhel cleanup kernel-2.6.31.5-117.fc12 ------------------------ libdrm-2.4.15-4.fc12 -------------------- * Thu Nov 05 2009 Ben Skeggs 2.4.15-4 - nouveau: improve reloc API to allow better error handling * Wed Nov 04 2009 Ben Skeggs 2.4.15-3 - nouveau: drop rendering on floor rather than asserting if flush fails * Tue Oct 27 2009 Ben Skeggs 2.4.15-2 - nouveau: retry pushbuf ioctl if interrupted by signal libgdl-2.28.1-1.fc12 -------------------- * Fri Oct 30 2009 Debarshi Ray - 2.28.1-1 - Version bump to 2.28.1. * Added new GdlSwitcherStyle name GDL_SWITCHER_STYLE_NONE. (GNOME Bugzilla * Translation updates. * http://download.gnome.org/sources/gdl/2.28/gdl-2.28.1.news * http://download.gnome.org/sources/gdl/2.27/gdl-2.27.92.news - Simplified mixed source licensing. There are no GPLv2 files left. * Tue Aug 11 2009 Ville Skytt? - 2.27.3-3 - Use bzipped upstream tarball. livecd-tools-031-1.fc12 ----------------------- * Tue Nov 03 2009 Warren Togami - 031-1 - livecd-iso-to-disk capable of installing installer DVD to USB nss_ldap-264-8.fc12 ------------------- * Wed Nov 04 2009 Nalin Dahyabhai 264-8 - add "rtkit" and "pulse" to the list of users whom we default to ignoring for looking up supplemental groups (Gordon Messmer, part of #186527) plymouth-0.8.0-0.2009.29.09.18.fc12 ----------------------------------- * Wed Nov 04 2009 Ray Strode 0.8.0-0.2009.29.09.18 - Make plymouth-update-initrd work with dracut prelink-0.4.2-4.fc12 -------------------- * Wed Nov 04 2009 Jakub Jelinek 0.4.2-4 - add support for STT_GNU_IFUNC on ppc/ppc64, R_PPC_IRELATIVE and R_PPC64_{IRELATIVE,JMP_IREL} pulseaudio-0.9.19-2.fc12 ------------------------ * Wed Nov 04 2009 Warren Togami - 0.9.19-2 - Bug #532583 gdm should not require pulseaudio qemu-0.11.0-11.fc12 ------------------- * Wed Nov 04 2009 Mark McLoughlin - 2:0.11.0-11 - Temporarily disable preadv/pwritev support to fix data corruption (#526549) qpidc-0.5.829175-2.fc12 ----------------------- * Tue Nov 03 2009 Nuno Santos - 0.5.829175-2 - Add patch for qmf fixes * Fri Oct 23 2009 Nuno Santos - 0.5.829175-1 - Rebased to svn rev 829175 * Thu Oct 15 2009 Nuno Santos - 0.5.825677-1 - Rebased to svn rev 825677 quake3-1.36-4.fc12 ------------------ * Wed Nov 04 2009 Hans de Goede 1.36-4 - Fix bots not working on Intel 64 bit CPU's (#526338) selinux-policy-3.6.32-41.fc12 ----------------------------- * Wed Nov 04 2009 Dan Walsh 3.6.32-41 - Allow podsleuth to send signals to users - Allow mail agents to getattr on fifo files from apps that execute mail agent - Fix labels for rpmfusion cruft - Allow xauth to read/write user tmp files because kdesu is doing something strange. - Let abrt read nsplugin_home_t udev-145-12.fc12 ---------------- * Thu Nov 05 2009 Bastien Nocera 145-12 - Update hid2hci from udev master, fixes problems with Dell Bluetooth dongles not working (#532628) valgrind-3.5.0-9 ---------------- * Wed Nov 04 2009 Jakub Jelinek 3.5.0-9 - rebuilt against glibc 2.11 - use upstream version of the ifunc support xfce4-clipman-plugin-1.1.1-1.fc12 --------------------------------- * Thu Oct 01 2009 Christoph Wickert - 1.1.1-1 - Update to 1.1.1 xfce4-mpc-plugin-0.3.4-1.fc12 ----------------------------- * Wed Nov 04 2009 Christoph Wickert - 0.3.4-1 - Update to 0.3.4 xorg-x11-drv-nouveau-0.0.15-17.20091105gite1c2efd.fc12 ------------------------------------------------------ * Thu Nov 05 2009 Ben Skeggs 0.0.15-17.20091105gite1c2efd - handle reloc failures more gracefully (rh#531058) - fix for rh#532322 * Mon Nov 02 2009 Ben Skeggs 0.0.15-16.20091030git5587f40 - force all pixmaps into system memory initally on low memory cards * Tue Oct 27 2009 Ben Skeggs 0.0.15-15.20091022git718a41b - misc fixes, initial NVA8 support * Fri Oct 09 2009 Ben Skeggs 0.0.15-14.20091008git3f020b0 - update from upstream, fixes various issues, especially with recent xservers xorg-x11-server-1.7.1-6.fc12 ---------------------------- * Wed Nov 04 2009 Soren Sandmann 1.7.1-5 - Update xserver-1.7.1-window-pictures.patch. Instead of calling GetImage(), simply call fb* functions rather than the screen hooks. (#524244) * Wed Nov 04 2009 Adam Jackson 1.7.1-6 - xserver-1.7.1-multilib.patch: Keep defining _XSERVER64, it's needed in some of the shared client/server headers. * Tue Nov 03 2009 Adam Jackson 1.7.1-3 - xserver-1.7.1-window-pictures.patch: Fix Render from Pictures backed by Windows to not crash in the presence of KMS. (#524244) * Thu Oct 29 2009 Adam Jackson 1.7.1-2 - xserver-1.7.1-multilib.patch: Fix silly multilib issue. (#470885) * Mon Oct 26 2009 Adam Jackson 1.7.1-1 - xserver 1.7.1 Summary: Added Packages: 1 Removed Packages: 0 Modified Packages: 35 From rjones at redhat.com Thu Nov 5 14:06:09 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 5 Nov 2009 14:06:09 +0000 Subject: Including windows-binary files for cross compiling into package In-Reply-To: <1257424975.26257.18.camel@wsjoost.cnoc.lan> References: <1256579896.23821.186.camel@wsjoost.cnoc.lan> <20091026181502.919B02747@magilla.sf.frob.com> <1256582576.23821.193.camel@wsjoost.cnoc.lan> <20091103125606.GA15146@amd.home.annexia.org> <1257424975.26257.18.camel@wsjoost.cnoc.lan> Message-ID: <20091105140609.GA3460@amd.home.annexia.org> On Thu, Nov 05, 2009 at 01:42:55PM +0100, Joost van der Sluis wrote: > A little bit? Did you read my other mail on the subject: > > "That's an idea, but then we would be incompatible with upstream. I can > try to patch the configuration files of fpc so that it searches for > these binaries in /usr/x86_64-pc-fpc/sys-root/fpc/lib. But I prefer the > 'standard' location. Also because other packages based in fpc relay on > that. This is based on a misunderstanding of the packaging guidelines. The Fedora MinGW cross-compiler itself does not live in /usr/i686-pc-mingw32, it lives in the usual places like /usr/bin and /usr/lib (it's a native Fedora executable, so obviously this is where it should go). $ which i686-pc-mingw32-gcc /usr/bin/i686-pc-mingw32-gcc $ ls /usr/lib64/gcc/i686-pc-mingw32/4.3.2/ crtbegin.o include-fixed libssp.a libstdc++.a crtend.o install-tools libssp.la libstdc++.la crtfastmath.o libgcc.a libssp_nonshared.a libsupc++.a include libgcov.a libssp_nonshared.la libsupc++.la > > http://fedoraproject.org/wiki/Packaging/MinGW > > Another thing, the MinGW packaging guidelines needs the packages to have > a 'MinGw' prefix, not suffix. > > My example used a suffix, like 'fpc-win32'. Do you think I should use > 'win32-fpc' instead? Again: this sounds logical when you have a complete > build-environment or something like that. But in this case I think > 'fpc-win32' is more logical. You should use a prefix so that autoconf knows how to find your cross-compiler. Read the documentation for AC_CHECK_TOOL. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 andy.shevchenko at gmail.com Thu Nov 5 14:08:09 2009 From: andy.shevchenko at gmail.com (Andy Shevchenko) Date: Thu, 5 Nov 2009 16:08:09 +0200 Subject: qstat conflicts Message-ID: <5ec8ebd50911050608v27bce3abja0ffcd9c45b1b90@mail.gmail.com> Hello. I have got few bugs [1] about conflicts between qstat (package) and torque-client where qstat is a POSIX registered name for some special service. Upstream as far as I know is like dead than alive. Thus, better solution to rename binary is not so simple. Nowadays the Conflicts: field is filled in the qstat.spec but torque-client doesn't have such field (and I understand the point). So, my idea is to ask upstream to change binary name and simultaneously raise discussion at distributions-list at fdo to do the same if upstream doesn't appear. Any comments, suggestions? [1] https://bugzilla.redhat.com/show_bug.cgi?id=472750 -- With Best Regards, Andy Shevchenko From sgrubb at redhat.com Thu Nov 5 14:10:12 2009 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 5 Nov 2009 09:10:12 -0500 Subject: rpm %verify Message-ID: <200911050910.12583.sgrubb@redhat.com> Hello, I have 2 bugzillas asking for %verify to be added to %config files. I am wondering if this is a good idea at all. The issue is that if you wanted to verify whether or not config files have changed, then this causes you to lose that ability. Adding --noscript to the verify command does not make rpm suddenly report the issues it was hiding. Does this mean that rpm is not working right? Or does this mean that we cannot use rpm for integrity checking for any package that has %verify attributes for config files? Thanks, -Steve PS - Anyone wanting to experiment can use the setup package and change the /etc/hosts file to verify what I am saying. From andy.shevchenko at gmail.com Thu Nov 5 14:23:21 2009 From: andy.shevchenko at gmail.com (Andy Shevchenko) Date: Thu, 5 Nov 2009 16:23:21 +0200 Subject: jack2 Message-ID: <5ec8ebd50911050623y5c4f83b4jd066e9949d26b1f7@mail.gmail.com> Hello. Nowadays the jack project has two branches - old jack (1) branch with version 0.116.2 and new one called jack2 version 1.9.3. I'd like to gather opinions and suggestions about applying new version for F13. Please, share your thoughts! Thank you. -- With Best Regards, Andy Shevchenko From valent.turkovic at gmail.com Thu Nov 5 14:24:18 2009 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 5 Nov 2009 14:24:18 +0000 (UTC) Subject: Fedora 12 vs. Ubuntu 9.10 Benchmarks ?!? Message-ID: http://is.gd/4NU9N Phoronix published Fedora 12 vs. Ubuntu 9.10 Benchmarks They claim they took Fedora 12 candidate release, but AFAIK there is no Fedora 12 RC, right? If they used Fedora 12 Beta are these number comparable with real Fedora 12 performance numbers when Fedora 12 ships? Aren't there some debugging features turned on in Rawhide (Fedora 12 beta) kernel? Are other packages in Fedora 12 also suffering from some speed penalty? Still Fedora 12 Beta ate Ubuntu for breakfast :) Fedora 12 performed on most test better than Ubuntu, nice work guys/ galls :) -- pratite me na twitteru - www.twitter.com/valentt 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 email.ahmedkamal at googlemail.com Thu Nov 5 14:08:05 2009 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Thu, 5 Nov 2009 16:08:05 +0200 Subject: Kernel installs not showing up in grub.conf Message-ID: <3da3b5b40911050608y711c542dr965f008e92efcf94@mail.gmail.com> Hi folks, Whenever I install a new kernel, it does NOT show up in /boot/grub/grub.conf. I am getting this error Installing : kernel-2.6.31.5-115.fc12.x86_64 11/137 W: Possible missing firmware aic94xx-seq.fw for module aic94xx.ko W: Possible missing firmware ql8100_fw.bin for module qla2xxx.ko grubby fatal error: unable to find a suitable template Here's my grub.conf: http://fpaste.org/b0qI/ Is that some known bug ? It's been broken since F11 Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdahlin at redhat.com Thu Nov 5 14:37:06 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Thu, 05 Nov 2009 09:37:06 -0500 Subject: Fedora 12 vs. Ubuntu 9.10 Benchmarks ?!? In-Reply-To: References: Message-ID: <4AF2E312.3070100@redhat.com> On 11/05/2009 09:24 AM, Valent Turkovic wrote: > http://is.gd/4NU9N > > Phoronix published Fedora 12 vs. Ubuntu 9.10 Benchmarks > > They claim they took Fedora 12 candidate release, but AFAIK there is no > Fedora 12 RC, right? > > If they used Fedora 12 Beta are these number comparable with real Fedora > 12 performance numbers when Fedora 12 ships? Aren't there some debugging > features turned on in Rawhide (Fedora 12 beta) kernel? Are other packages > in Fedora 12 also suffering from some speed penalty? > > Still Fedora 12 Beta ate Ubuntu for breakfast :) > > Fedora 12 performed on most test better than Ubuntu, nice work guys/ > galls :) > > Phoronix's reputation for rigor in their benchmarks seems to only get worse over time. Still, as long as we're winning :) --CJD From john.brown009 at gmail.com Thu Nov 5 14:35:28 2009 From: john.brown009 at gmail.com (TK009) Date: Thu, 5 Nov 2009 09:35:28 -0500 Subject: Fedora 12 vs. Ubuntu 9.10 Benchmarks ?!? In-Reply-To: References: Message-ID: <20091105143528.GC2485@blackhare> On Thu, Nov 05, 2009 at 02:24:18PM +0000, Valent Turkovic wrote: > http://is.gd/4NU9N > > Phoronix published Fedora 12 vs. Ubuntu 9.10 Benchmarks > > They claim they took Fedora 12 candidate release, but AFAIK there is no > Fedora 12 RC, right? If the email I saw on this list yesteday was correct we do in fact have an RC. > Still Fedora 12 Beta ate Ubuntu for breakfast :) And a distro like arch eats both of them for breakfast, lunch and dinner. As great as Fedora is preformace has never been a strong point. TK009 From che666 at gmail.com Thu Nov 5 14:36:57 2009 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 5 Nov 2009 15:36:57 +0100 Subject: qstat conflicts In-Reply-To: <5ec8ebd50911050608v27bce3abja0ffcd9c45b1b90@mail.gmail.com> References: <5ec8ebd50911050608v27bce3abja0ffcd9c45b1b90@mail.gmail.com> Message-ID: 2009/11/5 Andy Shevchenko : > Hello. > > I have got few bugs [1] about conflicts between qstat (package) and > torque-client where qstat is a POSIX registered name for some special > service. > Upstream as far as I know is like dead than alive. Thus, better > solution to rename binary is not so simple. > Nowadays the Conflicts: field is filled in the qstat.spec but > torque-client doesn't have such field (and I understand the point). > > So, my idea is to ask upstream to change binary name and > simultaneously raise discussion at distributions-list at fdo to do the > same if upstream doesn't appear. > > Any comments, suggestions? > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=472750 > > -- > With Best Regards, > Andy Shevchenko > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > There have been various comments in a former thread raised about the conflict a few days ago. Basically everyone involved into the discussion agreed that changing the binary name of qstat is the way to go. I guess the only program that has to be patched is xqf. kind regards, Rudolf Kastl From che666 at gmail.com Thu Nov 5 14:39:22 2009 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 5 Nov 2009 15:39:22 +0100 Subject: jack2 In-Reply-To: <5ec8ebd50911050623y5c4f83b4jd066e9949d26b1f7@mail.gmail.com> References: <5ec8ebd50911050623y5c4f83b4jd066e9949d26b1f7@mail.gmail.com> Message-ID: 2009/11/5 Andy Shevchenko : > Hello. > > Nowadays the jack project has two branches - old jack (1) branch with > version 0.116.2 and new one called jack2 version 1.9.3. > I'd like to gather opinions and suggestions about applying new version for F13. > Please, share your thoughts! > Thank you. > > -- > With Best Regards, > Andy Shevchenko > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > The new jack handles device reservation, so it interacts with pulseaudio much better. Waiting for a while already to see it appear atleast in rawhide (now rawhide f13) sometime soon. kind regards, Rudolf Kastl From mschmidt at redhat.com Thu Nov 5 14:40:36 2009 From: mschmidt at redhat.com (Michal Schmidt) Date: Thu, 05 Nov 2009 15:40:36 +0100 Subject: Fedora 12 vs. Ubuntu 9.10 Benchmarks ?!? In-Reply-To: References: Message-ID: <4AF2E3E4.603@redhat.com> Dne 5.11.2009 15:24, Valent Turkovic napsal(a): > http://is.gd/4NU9N > > Phoronix published Fedora 12 vs. Ubuntu 9.10 Benchmarks > > They claim they took Fedora 12 candidate release, but AFAIK there is no > Fedora 12 RC, right? They say they used http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/ but they did not specify the date of the snapshot, only that it reported itself as version 11.92. > Fedora 12 performed on most test better than Ubuntu, nice work guys/ > galls :) Are you referring to the 3D benchmarks using the proprietary nvidia driver? Michal From jarod at redhat.com Thu Nov 5 14:42:44 2009 From: jarod at redhat.com (Jarod Wilson) Date: Thu, 05 Nov 2009 09:42:44 -0500 Subject: Fedora 12 vs. Ubuntu 9.10 Benchmarks ?!? In-Reply-To: <20091105143528.GC2485@blackhare> References: <20091105143528.GC2485@blackhare> Message-ID: <4AF2E464.4030604@redhat.com> On 11/5/09 9:35 AM, TK009 wrote: > On Thu, Nov 05, 2009 at 02:24:18PM +0000, Valent Turkovic wrote: >> http://is.gd/4NU9N >> >> Phoronix published Fedora 12 vs. Ubuntu 9.10 Benchmarks >> >> They claim they took Fedora 12 candidate release, but AFAIK there is no >> Fedora 12 RC, right? > > If the email I saw on this list yesteday was correct we do in fact have an RC. > > >> Still Fedora 12 Beta ate Ubuntu for breakfast :) > > And a distro like arch eats both of them for breakfast, lunch and dinner. > As great as Fedora is preformace has never been a strong point. I presume you have relevant benchmarking data to back up this claim? -- Jarod Wilson jarod at redhat.com From sgrubb at redhat.com Thu Nov 5 14:43:39 2009 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 5 Nov 2009 09:43:39 -0500 Subject: AM_SILENT_RULES Message-ID: <200911050943.39330.sgrubb@redhat.com> Hello, I was looking at a package's build logs to see what kinds of problems gcc is reporting for the code and found a lot of lines with "CC object_name" and nothing else. This is really not helpful when you scan koji build logs or look for problems. Should we have a policy of requiring "--silent=no" configure option for packages that are hiding gcc warnings? -Steve From john.brown009 at gmail.com Thu Nov 5 14:45:03 2009 From: john.brown009 at gmail.com (TK009) Date: Thu, 5 Nov 2009 09:45:03 -0500 Subject: Fedora 12 vs. Ubuntu 9.10 Benchmarks ?!? In-Reply-To: <4AF2E464.4030604@redhat.com> References: <20091105143528.GC2485@blackhare> <4AF2E464.4030604@redhat.com> Message-ID: <20091105144503.GA5474@blackhare> On Thu, Nov 05, 2009 at 09:42:44AM -0500, Jarod Wilson wrote: > On 11/5/09 9:35 AM, TK009 wrote: >> On Thu, Nov 05, 2009 at 02:24:18PM +0000, Valent Turkovic wrote: >>> http://is.gd/4NU9N >>> >>> Phoronix published Fedora 12 vs. Ubuntu 9.10 Benchmarks >>> >>> They claim they took Fedora 12 candidate release, but AFAIK there is no >>> Fedora 12 RC, right? >> >> If the email I saw on this list yesteday was correct we do in fact have an RC. >> >> >>> Still Fedora 12 Beta ate Ubuntu for breakfast :) >> >> And a distro like arch eats both of them for breakfast, lunch and dinner. >> As great as Fedora is preformace has never been a strong point. > > I presume you have relevant benchmarking data to back up this claim? The same amount you have that disproves it. Better luck next time? From cdahlin at redhat.com Thu Nov 5 14:49:12 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Thu, 05 Nov 2009 09:49:12 -0500 Subject: AM_SILENT_RULES In-Reply-To: <200911050943.39330.sgrubb@redhat.com> References: <200911050943.39330.sgrubb@redhat.com> Message-ID: <4AF2E5E8.8050500@redhat.com> On 11/05/2009 09:43 AM, Steve Grubb wrote: > Hello, > > I was looking at a package's build logs to see what kinds of problems gcc is > reporting for the code and found a lot of lines with "CC object_name" and > nothing else. This is really not helpful when you scan koji build logs or look > for problems. Should we have a policy of requiring "--silent=no" configure > option for packages that are hiding gcc warnings? > > -Steve > If that is a package using kbuild, the warnings still show up. If you don't see them then there were none. The only thing that's hidden is the gcc invocation. --CJD From berrange at redhat.com Thu Nov 5 14:47:25 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 5 Nov 2009 14:47:25 +0000 Subject: AM_SILENT_RULES In-Reply-To: <200911050943.39330.sgrubb@redhat.com> References: <200911050943.39330.sgrubb@redhat.com> Message-ID: <20091105144725.GC689@redhat.com> On Thu, Nov 05, 2009 at 09:43:39AM -0500, Steve Grubb wrote: > Hello, > > I was looking at a package's build logs to see what kinds of problems gcc is > reporting for the code and found a lot of lines with "CC object_name" and > nothing else. This is really not helpful when you scan koji build logs or look > for problems. Should we have a policy of requiring "--silent=no" configure > option for packages that are hiding gcc warnings? Yes, I think that would be very helpful. 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 cmadams at hiwaay.net Thu Nov 5 14:49:48 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 5 Nov 2009 08:49:48 -0600 Subject: Fedora 12 vs. Ubuntu 9.10 Benchmarks ?!? In-Reply-To: <20091105144503.GA5474@blackhare> References: <20091105143528.GC2485@blackhare> <4AF2E464.4030604@redhat.com> <20091105144503.GA5474@blackhare> Message-ID: <20091105144948.GA1555174@hiwaay.net> Once upon a time, TK009 said: > The same amount you have that disproves it. Better luck next time? You made the claim, the onus is on you to back it up. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jarod at redhat.com Thu Nov 5 14:50:28 2009 From: jarod at redhat.com (Jarod Wilson) Date: Thu, 05 Nov 2009 09:50:28 -0500 Subject: Fedora 12 vs. Ubuntu 9.10 Benchmarks ?!? In-Reply-To: <20091105144503.GA5474@blackhare> References: <20091105143528.GC2485@blackhare> <4AF2E464.4030604@redhat.com> <20091105144503.GA5474@blackhare> Message-ID: <4AF2E634.6050402@redhat.com> On 11/5/09 9:45 AM, TK009 wrote: > On Thu, Nov 05, 2009 at 09:42:44AM -0500, Jarod Wilson wrote: >> On 11/5/09 9:35 AM, TK009 wrote: >>> On Thu, Nov 05, 2009 at 02:24:18PM +0000, Valent Turkovic wrote: >>>> http://is.gd/4NU9N >>>> >>>> Phoronix published Fedora 12 vs. Ubuntu 9.10 Benchmarks >>>> >>>> They claim they took Fedora 12 candidate release, but AFAIK there is no >>>> Fedora 12 RC, right? >>> >>> If the email I saw on this list yesteday was correct we do in fact have an RC. >>> >>> >>>> Still Fedora 12 Beta ate Ubuntu for breakfast :) >>> >>> And a distro like arch eats both of them for breakfast, lunch and dinner. >>> As great as Fedora is preformace has never been a strong point. >> >> I presume you have relevant benchmarking data to back up this claim? > > The same amount you have that disproves it. Better luck next time? I didn't make any claims one way or the other. At least phoronix posts *something* in the way of benchmarks to back up their claims. Put up, or shut up. -- Jarod Wilson jarod at redhat.com From andy.shevchenko at gmail.com Thu Nov 5 14:54:41 2009 From: andy.shevchenko at gmail.com (Andy Shevchenko) Date: Thu, 5 Nov 2009 16:54:41 +0200 Subject: qstat conflicts In-Reply-To: References: <5ec8ebd50911050608v27bce3abja0ffcd9c45b1b90@mail.gmail.com> Message-ID: <5ec8ebd50911050654s347093b1seb3a649c36657891@mail.gmail.com> > There have been various comments in a former thread raised about the > conflict a few days ago. Basically everyone involved into the > discussion agreed that changing the binary name of qstat is the way to > go. I guess the only program that has to be patched is xqf. Oh, I missed it. Please, paste the link to archive just in case. -- With Best Regards, Andy Shevchenko From MathStuf at gmail.com Thu Nov 5 15:01:02 2009 From: MathStuf at gmail.com (Ben Boeckel) Date: Thu, 05 Nov 2009 10:01:02 -0500 Subject: source file audit - 2009-11-01 References: <20091104171816.0ef2c0a5@ohm.scrye.com> <20091105113904.GA1660@amd.home.annexia.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Richard W.M. Jones wrote: >> rjones:BADSOURCE:pa_do-0.8.10.tar.gz:ocaml-pa-do > > This is the same hosting provider as above, and I can definitely > access the URL and Source0 from here. Isn't this saying the hash checks don't match up? Seems it got the download right to be able to compare them. - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJK8uivAAoJEKaxavVX4C1Xre0QAINvr8WhONWcxNRI1VjWJp3H SgiWmj5sK62AcC+vVyk0OHJ3ijnQnocglkUD1hp2Usfh9eD3w8kZf0EIz+aGsISL ATjUAIeoLH3gzuidnluzyvMA/3ydrm2y84Tz5n+Ow4csK3z5WhsXqkyfU5AWH8Xu ek9PMjPLlhMMQi3MhDYHV8dQPbS0YfnCqjoHnxkEWTBgkb7t5uNTJ9c8TlBkMast gsapJ8m07y7hbsxb7R9zRprt03SPlXRaAbeRnDHAmuavOaJTua/gd8zw6PK/sJjo m6fHjBwdJ2FbTXGIyb83bX+B9Y9AaSoqdbQGQKoky4+8rQkC4Al3KIK/BW7X7rJ3 D/Nc45ZkADYz/lB1Yck35ADLnUU43tN8uVs2Wlj7xibNH/k32ahxQB8YIzGUv6xC 2jA3udIiTTd6oWnqZWxfe5br3imVREx92kLyF2yrPeY1EALPGTJZwrmdxEFghT8J A9wOdm50anxOabwxk/RawYSsfq1KKgHEvUIUCycTAQgGhfO0e07uCYIJLO92BO26 a7/g6mbilzdFtrxlVw9i0dQNBEYkjjNGZ3DjhGsZfUpAz+6efSz0X240KC/oh9uU 4e2ZGvNcEdXYb2SVomKHNGSkGr+EOMj59Gx6S5898+w4RpdkhDn2pcrF0IxvSskC HWSma/BrYRJHvZQDQaDN =9yyL -----END PGP SIGNATURE----- From bnocera at redhat.com Thu Nov 5 15:04:25 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 05 Nov 2009 15:04:25 +0000 Subject: AM_SILENT_RULES In-Reply-To: <200911050943.39330.sgrubb@redhat.com> References: <200911050943.39330.sgrubb@redhat.com> Message-ID: <1257433465.23167.167.camel@localhost.localdomain> On Thu, 2009-11-05 at 09:43 -0500, Steve Grubb wrote: > Hello, > > I was looking at a package's build logs to see what kinds of problems gcc is > reporting for the code and found a lot of lines with "CC object_name" and > nothing else. This is really not helpful when you scan koji build logs or look > for problems. Should we have a policy of requiring "--silent=no" configure > option for packages that are hiding gcc warnings? GCC warnings will still show up, otherwise it means you don't have a high enough level of warnings in the package. V=1 passed to make is enough to show the full command-lines. I don't think that disabling silent would help one bit if you're just looking for warnings, because it would show them anyway. From rjones at redhat.com Thu Nov 5 15:11:37 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 5 Nov 2009 15:11:37 +0000 Subject: source file audit - 2009-11-01 In-Reply-To: References: <20091104171816.0ef2c0a5@ohm.scrye.com> <20091105113904.GA1660@amd.home.annexia.org> Message-ID: <20091105151137.GA3966@amd.home.annexia.org> On Thu, Nov 05, 2009 at 10:01:02AM -0500, Ben Boeckel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Richard W.M. Jones wrote: > > >> rjones:BADSOURCE:pa_do-0.8.10.tar.gz:ocaml-pa-do > > > > This is the same hosting provider as above, and I can definitely > > access the URL and Source0 from here. > > Isn't this saying the hash checks don't match up? Seems it got the download > right to be able to compare them. Oh I see, and damn upstream have changed the tarball as well :-( I've contacted upstream about this to see what's going on, and to remind them not to do this. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 rc040203 at freenet.de Thu Nov 5 15:17:17 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 05 Nov 2009 16:17:17 +0100 Subject: AM_SILENT_RULES In-Reply-To: <1257433465.23167.167.camel@localhost.localdomain> References: <200911050943.39330.sgrubb@redhat.com> <1257433465.23167.167.camel@localhost.localdomain> Message-ID: <4AF2EC7D.6060307@freenet.de> On 11/05/2009 04:04 PM, Bastien Nocera wrote: > On Thu, 2009-11-05 at 09:43 -0500, Steve Grubb wrote: >> Hello, >> >> I was looking at a package's build logs to see what kinds of problems gcc is >> reporting for the code and found a lot of lines with "CC object_name" and >> nothing else. This is really not helpful when you scan koji build logs or look >> for problems. Should we have a policy of requiring "--silent=no" configure >> option for packages that are hiding gcc warnings? Yes, definitely. > GCC warnings will still show up, otherwise it means you don't have a > high enough level of warnings in the package. > > V=1 passed to make is enough to show the full command-lines. Unless a package already uses "V" otherwise. > I don't think that disabling silent would help one bit if you're just > looking for warnings, because it would show them anyway. Wrong, Broken CPPFLAGS and CFLAGS don't show up as warning even when they kill a build. Ralf From rjones at redhat.com Thu Nov 5 15:22:00 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 5 Nov 2009 15:22:00 +0000 Subject: source file audit - 2009-11-01 In-Reply-To: <20091105151137.GA3966@amd.home.annexia.org> References: <20091104171816.0ef2c0a5@ohm.scrye.com> <20091105113904.GA1660@amd.home.annexia.org> <20091105151137.GA3966@amd.home.annexia.org> Message-ID: <20091105152200.GA4086@amd.home.annexia.org> On Thu, Nov 05, 2009 at 03:11:37PM +0000, Richard W.M. Jones wrote: > I've contacted upstream about this to see what's going on, and > to remind them not to do this. Actually it seems to be my mistake. Upstream (gforge) have a database-driven download system where it doesn't matter what you put at the end of the URL, it's the magic number in the middle that determines what you download: http://forge.ocamlcore.org/frs/download.php/273/this-could-be-anything.tar.gz http://forge.ocamlcore.org/frs/download.php/237/in-for-a-surprise.tar.gz Fixed now. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 notting at redhat.com Thu Nov 5 15:26:00 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 5 Nov 2009 10:26:00 -0500 Subject: Current libgdl induced mess In-Reply-To: <3170f42f0911050539w311b74b8hade46a117c7c7e0e@mail.gmail.com> References: <3170f42f0911050539w311b74b8hade46a117c7c7e0e@mail.gmail.com> Message-ID: <20091105152600.GH12372@nostromo.devel.redhat.com> Debarshi Ray (debarshi.ray at gmail.com) said: > Actually I had requested a freeze override for Anjuta and libgdl [1] > causing the mess. Actually the changes between 2.27.92 to 2.28.0 > included the addition of an extra enum value to GdlSwitcherStyle and I > did not expect this to cause a bump in the soname. But it was bumped > and I failed to notice it. My mistake. > > This new enum value is not being used as far as I know, so how do you > propose we clean this? Untag the new libgdl or rebuild the other > packages? How many 'other packages' are we referring to here? Bill From notting at redhat.com Thu Nov 5 15:27:30 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 5 Nov 2009 10:27:30 -0500 Subject: rpm %verify In-Reply-To: <200911050910.12583.sgrubb@redhat.com> References: <200911050910.12583.sgrubb@redhat.com> Message-ID: <20091105152729.GI12372@nostromo.devel.redhat.com> Steve Grubb (sgrubb at redhat.com) said: > I have 2 bugzillas asking for %verify to be added to %config files. I am > wondering if this is a good idea at all. The issue is that if you wanted to > verify whether or not config files have changed, then this causes you to lose > that ability. Adding --noscript to the verify command does not make rpm > suddenly report the issues it was hiding. Does this mean that rpm is not > working right? Or does this mean that we cannot use rpm for integrity checking > for any package that has %verify attributes for config files? %verify is for turning off specific verification checks for files we *know* are going to change from what's in the RPM package/db. /etc/passwd is an obvious example; users will be added there, and the fact that the passwd file does not match the packaged version is not a verification issue. Bill From notting at redhat.com Thu Nov 5 15:30:31 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 5 Nov 2009 10:30:31 -0500 Subject: Current libgdl induced mess In-Reply-To: <20091105152600.GH12372@nostromo.devel.redhat.com> References: <3170f42f0911050539w311b74b8hade46a117c7c7e0e@mail.gmail.com> <20091105152600.GH12372@nostromo.devel.redhat.com> Message-ID: <20091105153030.GJ12372@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > Debarshi Ray (debarshi.ray at gmail.com) said: > > Actually I had requested a freeze override for Anjuta and libgdl [1] > > causing the mess. Actually the changes between 2.27.92 to 2.28.0 > > included the addition of an extra enum value to GdlSwitcherStyle and I > > did not expect this to cause a bump in the soname. But it was bumped > > and I failed to notice it. My mistake. > > > > This new enum value is not being used as far as I know, so how do you > > propose we clean this? Untag the new libgdl or rebuild the other > > packages? > > How many 'other packages' are we referring to here? Never mind, I see 4 packages. So: - I'd rather ship a released version of libgdl - None of these are critical path How quickly can you build? Bill From pbrobinson at gmail.com Thu Nov 5 15:35:23 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 5 Nov 2009 15:35:23 +0000 Subject: source file audit - 2009-11-01 In-Reply-To: <20091104171816.0ef2c0a5@ohm.scrye.com> References: <20091104171816.0ef2c0a5@ohm.scrye.com> Message-ID: <5256d0b0911050735n3bfcf799o777669ed9d989c4d@mail.gmail.com> On Thu, Nov 5, 2009 at 12:18 AM, Kevin Fenzi wrote: > Here's attached another run of my sources/patches url checker. > > - There are 932 lines in this run. Down from 1060 last run. > > ? 700 sourcecheck-20070826.txt > ? 620 sourcecheck-20070917.txt > ? 561 sourcecheck-20071017.txt > ? 775 sourcecheck-20080206.txt > ? 685 sourcecheck-20080214.txt > ? 674 sourcecheck-20080301.txt > ? 666 sourcecheck-20080401.txt > ? 660 sourcecheck-20080501.txt > ? 642 sourcecheck-20080603.txt > ? 649 sourcecheck-20080705.txt > ? 662 sourcecheck-20080801.txt > ? 912 sourcecheck-20081114.txt > ? 884 sourcecheck-20090215.txt > ?1060 sourcecheck-20090810.txt > ? 932 sourcecheck-20091101.txt > > You can find the results file at: > > http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20091101.txt These are mine: pbrobinson:BADURL:ccss-0.5.0.tar.gz:ccss pbrobinson:BADURL:libccss-0.4.0.tar.gz:libccss pbrobinson:BADURL:mutter-2.28.0.tar.bz2:mutter pbrobinson:BADURL:rygel-0.4.4.tar.bz2:rygel The first two lost their hosting when one of the freedesktop.org servers crashed and people's home dirs were lost. I'm looking for the new location for the hosting of this. Both mutter and ryfel are fixed in cvs but I don't see the point in pushing a new release for a single character change so it will be fixed with the next release. Regards, Peter From che666 at gmail.com Thu Nov 5 15:37:06 2009 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 5 Nov 2009 16:37:06 +0100 Subject: qstat conflicts In-Reply-To: <5ec8ebd50911050654s347093b1seb3a649c36657891@mail.gmail.com> References: <5ec8ebd50911050608v27bce3abja0ffcd9c45b1b90@mail.gmail.com> <5ec8ebd50911050654s347093b1seb3a649c36657891@mail.gmail.com> Message-ID: 2009/11/5 Andy Shevchenko : >> There have been various comments in a former thread raised about the >> conflict a few days ago. Basically everyone involved into the >> discussion agreed that changing the binary name of qstat is the way to >> go. I guess the only program that has to be patched is xqf. > Oh, I missed it. Please, paste the link to archive just in case. there you go: https://www.redhat.com/archives/fedora-devel-list/2009-November/msg00170.html kind regards, Rudolf Kastl From sgrubb at redhat.com Thu Nov 5 15:43:58 2009 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 5 Nov 2009 10:43:58 -0500 Subject: rpm %verify In-Reply-To: <20091105152729.GI12372@nostromo.devel.redhat.com> References: <200911050910.12583.sgrubb@redhat.com> <20091105152729.GI12372@nostromo.devel.redhat.com> Message-ID: <200911051043.58347.sgrubb@redhat.com> On Thursday 05 November 2009 10:27:30 am Bill Nottingham wrote: > Steve Grubb (sgrubb at redhat.com) said: > > I have 2 bugzillas asking for %verify to be added to %config files. I am > > wondering if this is a good idea at all. The issue is that if you wanted > > to verify whether or not config files have changed, then this causes you > > to lose that ability. Adding --noscript to the verify command does not > > make rpm suddenly report the issues it was hiding. Does this mean that > > rpm is not working right? Or does this mean that we cannot use rpm for > > integrity checking for any package that has %verify attributes for config > > files? > > %verify is for turning off specific verification checks for files we > *know* are going to change from what's in the RPM package/db. /etc/passwd > is an obvious example; users will be added there, and the fact that the > passwd file does not match the packaged version is not a verification > issue. And there is no way to ask rpm to tell us what is different even if we wanted that? -Steve From joost at cnoc.nl Thu Nov 5 15:44:10 2009 From: joost at cnoc.nl (Joost van der Sluis) Date: Thu, 05 Nov 2009 16:44:10 +0100 Subject: Including windows-binary files for cross compiling into package In-Reply-To: <20091105140609.GA3460@amd.home.annexia.org> References: <1256579896.23821.186.camel@wsjoost.cnoc.lan> <20091026181502.919B02747@magilla.sf.frob.com> <1256582576.23821.193.camel@wsjoost.cnoc.lan> <20091103125606.GA15146@amd.home.annexia.org> <1257424975.26257.18.camel@wsjoost.cnoc.lan> <20091105140609.GA3460@amd.home.annexia.org> Message-ID: <1257435850.26257.36.camel@wsjoost.cnoc.lan> On Thu, 2009-11-05 at 14:06 +0000, Richard W.M. Jones wrote: > On Thu, Nov 05, 2009 at 01:42:55PM +0100, Joost van der Sluis wrote: > > A little bit? Did you read my other mail on the subject: > > > > "That's an idea, but then we would be incompatible with upstream. I can > > try to patch the configuration files of fpc so that it searches for > > these binaries in /usr/x86_64-pc-fpc/sys-root/fpc/lib. But I prefer the > > 'standard' location. Also because other packages based in fpc relay on > > that. > > This is based on a misunderstanding of the packaging guidelines. > > The Fedora MinGW cross-compiler itself does not live in > /usr/i686-pc-mingw32, it lives in the usual places like /usr/bin and > /usr/lib (it's a native Fedora executable, so obviously this is where > it should go). > $ which i686-pc-mingw32-gcc > /usr/bin/i686-pc-mingw32-gcc > $ ls /usr/lib64/gcc/i686-pc-mingw32/4.3.2/ > crtbegin.o include-fixed libssp.a libstdc++.a > crtend.o install-tools libssp.la libstdc++.la > crtfastmath.o libgcc.a libssp_nonshared.a libsupc++.a > include libgcov.a libssp_nonshared.la libsupc++.la Yes, I understood that, but the object files in windows-format should be in /usr/i686-pc-fpc/sys-root/fpc/lib, right? That's what I meant. If you are actually on windows, MinGW needs a directory-structure with paths like 'lib', 'bin' etc. But fpc doesn't need that. Well, the application should be in 'program files', but I doubt that that's what we want in a Fedora-package. So if this 'sys-root' path mimics a windows-directory structure, that has no advantage whatsoever for the freepascal compiler. > > > http://fedoraproject.org/wiki/Packaging/MinGW > > > > Another thing, the MinGW packaging guidelines needs the packages to have > > a 'MinGw' prefix, not suffix. > > > > My example used a suffix, like 'fpc-win32'. Do you think I should use > > 'win32-fpc' instead? Again: this sounds logical when you have a complete > > build-environment or something like that. But in this case I think > > 'fpc-win32' is more logical. > > You should use a prefix so that autoconf knows how to find your > cross-compiler. Read the documentation for AC_CHECK_TOOL. Autoconf? With Pascal? What's next, using 'make'? ;) You don't need those tools with Pascal, there's no need for makefiles because of the unit-system. Also, there's no separate compiler-executable for cross compiling to windows. The 'normal' compiler is able to compile for each OS which is supported, as long as the architecture stays the same. (for i386-arm you need a cross-compiler) You can do 'fpc --OS_TARGET=darwin' and you'll get a OS/X executable. Well, that is, if the linker (ld) supports darwin as a target. For windows the fpc-compiler has a build-in linker, so even that is not necessary. The extra package what I want to make consist only of the pre-compiled run time library (rtl and fcl). Joost. From mschwendt at gmail.com Thu Nov 5 15:45:51 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 5 Nov 2009 16:45:51 +0100 Subject: AM_SILENT_RULES In-Reply-To: <4AF2E5E8.8050500@redhat.com> References: <200911050943.39330.sgrubb@redhat.com> <4AF2E5E8.8050500@redhat.com> Message-ID: <20091105164551.0c6cd6e9@faldor.intranet> On Thu, 05 Nov 2009 09:49:12 -0500, Casey wrote: > On 11/05/2009 09:43 AM, Steve Grubb wrote: > > Hello, > > > > I was looking at a package's build logs to see what kinds of problems gcc is > > reporting for the code and found a lot of lines with "CC object_name" and > > nothing else. This is really not helpful when you scan koji build logs or look > > for problems. Should we have a policy of requiring "--silent=no" configure > > option for packages that are hiding gcc warnings? > > > > -Steve > > > > If that is a package using kbuild, the warnings still show up. If you don't see them then there were none. The only thing that's hidden is the gcc invocation. > We want to see the gcc invocation with all its details, though (which is one reason for %cmake VERBOSE=1, too). From debarshi.ray at gmail.com Thu Nov 5 16:03:54 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Thu, 5 Nov 2009 18:03:54 +0200 Subject: Current libgdl induced mess In-Reply-To: <20091105153030.GJ12372@nostromo.devel.redhat.com> References: <3170f42f0911050539w311b74b8hade46a117c7c7e0e@mail.gmail.com> <20091105152600.GH12372@nostromo.devel.redhat.com> <20091105153030.GJ12372@nostromo.devel.redhat.com> Message-ID: <3170f42f0911050803n5d05d38fv76034f6d44f15439@mail.gmail.com> > So: > - I'd rather ship a released version of libgdl > - None of these are critical path > > How quickly can you build? I can build Anjuta right now. Rest I do not have commit access to. -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig From notting at redhat.com Thu Nov 5 16:24:25 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 5 Nov 2009 11:24:25 -0500 Subject: Current libgdl induced mess In-Reply-To: <3170f42f0911050803n5d05d38fv76034f6d44f15439@mail.gmail.com> References: <3170f42f0911050539w311b74b8hade46a117c7c7e0e@mail.gmail.com> <20091105152600.GH12372@nostromo.devel.redhat.com> <20091105153030.GJ12372@nostromo.devel.redhat.com> <3170f42f0911050803n5d05d38fv76034f6d44f15439@mail.gmail.com> Message-ID: <20091105162424.GA15011@nostromo.devel.redhat.com> > > - I'd rather ship a released version of libgdl > > - None of these are critical path > > > > How quickly can you build? > > I can build Anjuta right now. Rest I do not have commit access to. gtranslator & solang building. gnome-python2-extras will likely get rebuilt anyway for an upcoming xulrunner upgrade. Bill From bnocera at redhat.com Thu Nov 5 16:27:38 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 05 Nov 2009 16:27:38 +0000 Subject: AM_SILENT_RULES In-Reply-To: <4AF2EC7D.6060307@freenet.de> References: <200911050943.39330.sgrubb@redhat.com> <1257433465.23167.167.camel@localhost.localdomain> <4AF2EC7D.6060307@freenet.de> Message-ID: <1257438458.23167.172.camel@localhost.localdomain> On Thu, 2009-11-05 at 16:17 +0100, Ralf Corsepius wrote: > On 11/05/2009 04:04 PM, Bastien Nocera wrote: > > On Thu, 2009-11-05 at 09:43 -0500, Steve Grubb wrote: > >> Hello, > >> > >> I was looking at a package's build logs to see what kinds of problems gcc is > >> reporting for the code and found a lot of lines with "CC object_name" and > >> nothing else. This is really not helpful when you scan koji build logs or look > >> for problems. Should we have a policy of requiring "--silent=no" configure > >> option for packages that are hiding gcc warnings? > Yes, definitely. > > > GCC warnings will still show up, otherwise it means you don't have a > > high enough level of warnings in the package. > > > > V=1 passed to make is enough to show the full command-lines. > Unless a package already uses "V" otherwise. > > > I don't think that disabling silent would help one bit if you're just > > looking for warnings, because it would show them anyway. > Wrong, Broken CPPFLAGS and CFLAGS don't show up as warning even when > they kill a build. Those weren't warnings in the first place, and certainly not gcc warnings, which was Steve's original question about. From notting at redhat.com Thu Nov 5 16:40:36 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 5 Nov 2009 11:40:36 -0500 Subject: Fedora 12 now in RC freeze Message-ID: <20091105164036.GA15062@nostromo.devel.redhat.com> We are reaching a *very* deep freeze now as we try and get a final release candidate for Fedora 12. Bodhi is now open for submitting F-12 updates, and we hope to have update repositories for testing later this weekend. If you have critical blocking issues, you can continue to file tag requests with 'make tag-request', and they will be considered. For the majority of updates, though, please use bodhi. Thanks, Fedora release engineering From rc040203 at freenet.de Thu Nov 5 17:14:06 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 05 Nov 2009 18:14:06 +0100 Subject: AM_SILENT_RULES In-Reply-To: <1257438458.23167.172.camel@localhost.localdomain> References: <200911050943.39330.sgrubb@redhat.com> <1257433465.23167.167.camel@localhost.localdomain> <4AF2EC7D.6060307@freenet.de> <1257438458.23167.172.camel@localhost.localdomain> Message-ID: <4AF307DE.1090304@freenet.de> On 11/05/2009 05:27 PM, Bastien Nocera wrote: > On Thu, 2009-11-05 at 16:17 +0100, Ralf Corsepius wrote: >> On 11/05/2009 04:04 PM, Bastien Nocera wrote: >>> On Thu, 2009-11-05 at 09:43 -0500, Steve Grubb wrote: >>>> Hello, >>>> >>>> I was looking at a package's build logs to see what kinds of problems gcc is >>>> reporting for the code and found a lot of lines with "CC object_name" and >>>> nothing else. This is really not helpful when you scan koji build logs or look >>>> for problems. Should we have a policy of requiring "--silent=no" configure >>>> option for packages that are hiding gcc warnings? >> Yes, definitely. >> >>> GCC warnings will still show up, otherwise it means you don't have a >>> high enough level of warnings in the package. >>> >>> V=1 passed to make is enough to show the full command-lines. >> Unless a package already uses "V" otherwise. >> >>> I don't think that disabling silent would help one bit if you're just >>> looking for warnings, because it would show them anyway. >> Wrong, Broken CPPFLAGS and CFLAGS don't show up as warning even when >> they kill a build. > > Those weren't warnings in the first place,and certainly not gcc > warnings, Not quite. Whether gcc issues warnings/errors depends upon CFLAGS/CPPFLAGS (e.g. optimization levels) and other factors (e.g. architectures, GCC version/patches, tools being used underneath). On a wider scope, in general, CPPFLAGS/CFLAGS can cause non-FPC compliant binaries (eg. using -O3, -m), deeply hidden compilation issues (-I/usr/include) or non-functional binaries (-DSYSCONFDIR="/home/nocera/"). Suche kind of issues are hidden when using AM_SILENT_RULES, though they often are the cause for deeply hidden and hard to trace down issues. Finally, IMNSHO, AM_SILENT_RULES is "greasy kid's stuff". People who are using and/or endoring them have no clue about what they are doing. Ralf From mike.cloaked at gmail.com Thu Nov 5 17:19:48 2009 From: mike.cloaked at gmail.com (Mike Cloaked) Date: Thu, 5 Nov 2009 17:19:48 +0000 (UTC) Subject: A question about allow_unconfined_mmap_low in f11 amd selinux References: <3b8e57a80911040723x280abfd0jf6bab04bf4803390@mail.gmail.com> <4AF1A2C5.8010008@redhat.com> Message-ID: Daniel J Walsh redhat.com> writes: > > On 11/04/2009 10:23 AM, mike cloaked wrote: > > By "moving forward" do you mean that one can, in f11, reset the > > original boolean and set boolean mmap_low_allowed instead, in a > > forthcoming policy update? > > > > Or is this a planned change coming for f12 but not yet policy in > > earlier versions? > > > > Thanks > > > We have setroubleshoot plugins that explain exactly to the users what they need to do to turn make their wine > apps run. > Does the dereference fix in kernel-2.6.30.9-96.fc11 address the issue raised here or have I got this wrong? From debarshi.ray at gmail.com Thu Nov 5 17:37:01 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Thu, 5 Nov 2009 19:37:01 +0200 Subject: Current libgdl induced mess In-Reply-To: <20091105162424.GA15011@nostromo.devel.redhat.com> References: <3170f42f0911050539w311b74b8hade46a117c7c7e0e@mail.gmail.com> <20091105152600.GH12372@nostromo.devel.redhat.com> <20091105153030.GJ12372@nostromo.devel.redhat.com> <3170f42f0911050803n5d05d38fv76034f6d44f15439@mail.gmail.com> <20091105162424.GA15011@nostromo.devel.redhat.com> Message-ID: <3170f42f0911050937y6a07ba36pe744ee2174818467@mail.gmail.com> Finished building anjuta-2.28.1.0-2.fc12 Cheers, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig From kevin.kofler at chello.at Thu Nov 5 17:36:15 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 05 Nov 2009 18:36:15 +0100 Subject: Current libgdl induced mess References: <3170f42f0911050539w311b74b8hade46a117c7c7e0e@mail.gmail.com> <20091105152600.GH12372@nostromo.devel.redhat.com> <20091105153030.GJ12372@nostromo.devel.redhat.com> <3170f42f0911050803n5d05d38fv76034f6d44f15439@mail.gmail.com> <20091105162424.GA15011@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > gtranslator & solang building. gnome-python2-extras will likely get > rebuilt anyway for an upcoming xulrunner upgrade. Yet another one? Didn't we just get one? :-( Kevin Kofler From pbrobinson at gmail.com Thu Nov 5 18:01:56 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 5 Nov 2009 18:01:56 +0000 Subject: Fedora Moblin remix Message-ID: <5256d0b0911051001i5a6d7429u2fd2c965685e40f0@mail.gmail.com> Hi All, For those interested there's a new test LiveCD of Fedora Moblin remix [1] for those that are interesting in playing. It would be nice to have some feedback on good or bad issues with it. There's been almost 1300 downloads since I announced the last one but I've had no feedback what so ever and while I'd like to assume that's because its perfect I doubt that is the case. Enjoy! Peter [1] http://fedora.roving-it.com/FedoraMoblin12-Beta2-LiveCD.iso As a side note the old one has been renamed to the following to make it easier to identify. http://fedora.roving-it.com/FedoraMoblin12-Beta1-LiveCD.iso From kevin at scrye.com Thu Nov 5 18:05:33 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Thu, 5 Nov 2009 11:05:33 -0700 Subject: source file audit - 2009-11-01 In-Reply-To: <4AF219D7.4080206@fedoraproject.org> References: <20091104171816.0ef2c0a5@ohm.scrye.com> <4AF219D7.4080206@fedoraproject.org> Message-ID: <20091105110533.1fb05ac7@ohm.scrye.com> On Thu, 05 Nov 2009 05:48:31 +0530 Rahul Sundaram wrote: > On 11/05/2009 05:48 AM, Kevin Fenzi wrote: > > > sundaram:BADSOURCE:cryptopp560.zip:cryptopp > > Upstream source modified to remove patent encumbered portions. ok, in that case don't use the full URL in the Source0 line. (I suppose it would be good to put it in a comment though). Thanks, kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From kevin at scrye.com Thu Nov 5 18:06:14 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Thu, 5 Nov 2009 11:06:14 -0700 Subject: source file audit - 2009-11-01 In-Reply-To: <20091105025742.GB17486@wolff.to> References: <20091104171816.0ef2c0a5@ohm.scrye.com> <20091105025742.GB17486@wolff.to> Message-ID: <20091105110614.5023b14f@ohm.scrye.com> On Wed, 4 Nov 2009 20:57:42 -0600 Bruno Wolff III wrote: > On Wed, Nov 04, 2009 at 17:18:16 -0700, > Kevin Fenzi wrote: > > Here's attached another run of my sources/patches url checker. > > > > bruno:BADURL:glest_data_3.2.1.zip:glest-data > > I took over glest recently and hadn't had to worry about where the > sources had come from yet. The next time I make a change I'll be sure > to make sure that the source URLs are accurate. Excellent. Thanks. > P.S. > If the audiance for this report is developers, I think it would make > more sense to sort on the FAS name and then on package name. ok. I think I did do that in the past, but failed this time. ;( kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From kevin at scrye.com Thu Nov 5 18:09:44 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Thu, 5 Nov 2009 11:09:44 -0700 Subject: source file audit - 2009-11-01 In-Reply-To: <20091105113904.GA1660@amd.home.annexia.org> References: <20091104171816.0ef2c0a5@ohm.scrye.com> <20091105113904.GA1660@amd.home.annexia.org> Message-ID: <20091105110944.236d9d07@ohm.scrye.com> On Thu, 5 Nov 2009 11:39:04 +0000 "Richard W.M. Jones" wrote: > On Wed, Nov 04, 2009 at 05:18:16PM -0700, Kevin Fenzi wrote: > > rjones:BADURL:ocaml-autoconf-1.1.tar.gz:ocaml-autoconf > > False alarm? Both the URL and Source0 work for me, but note that the > site has a self-signed certificate so you need > "--no-check-certificate" or the equivalent to download the source: > > wget --no-check-certificate > https://forge.ocamlcore.org/frs/download.php/282/ocaml-autoconf-1.1.tar.gz Well, the script I am running uses 'spectool -g' and indeed, it doesn't handle self signed certs: --2009-11-02 03:15:09-- https://forge.ocamlcore.org/frs/download.php/282/ocaml-autoconf-1.1.tar.gz Resolving forge.ocamlcore.org... 87.98.154.45 Connecting to forge.ocamlcore.org|87.98.154.45|:443... connected. ERROR: cannot verify forge.ocamlcore.org's certificate, issued by `/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support at cacert.org': Unable to locally verify the issuer's authority. To connect to forge.ocamlcore.org insecurely, use `--no-check-certificate'. Unable to establish SSL connection. Would it be possible to use a http link there? > > rjones:BADSOURCE:pa_do-0.8.10.tar.gz:ocaml-pa-do > > This is the same hosting provider as above, and I can definitely > access the URL and Source0 from here. > > wget --no-check-certificate > http://forge.ocamlcore.org/frs/download.php/273/pa_do-0.8.10.tar.gz Yeah, same issue. > > rjones:BADURL:coccinelle-0.1.10.tgz:coccinelle > > Upstream moved their website hosting. Fixed by rebuilding all the > branches. > > > rjones:BADURL:febootstrap-2.5.tar.gz:febootstrap > > Fixed (upstream website problem). > > > rjones:BADURL:libpng-1.2.37.tar.bz2:mingw32-libpng > > Ugghh, upstream like to remove old copies of their source tarballs. > > Fixed and rebuilt in Rawhide only, because I don't want to push > unstable updates to the other branches and there's no way to fix those > other branches if the upstream tarball has gone. No need to build anything for these... just correct the links and it should go out with the next update for something else. ;) kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From kevin at scrye.com Thu Nov 5 18:10:52 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Thu, 5 Nov 2009 11:10:52 -0700 Subject: source file audit - 2009-11-01 In-Reply-To: <5256d0b0911050735n3bfcf799o777669ed9d989c4d@mail.gmail.com> References: <20091104171816.0ef2c0a5@ohm.scrye.com> <5256d0b0911050735n3bfcf799o777669ed9d989c4d@mail.gmail.com> Message-ID: <20091105111052.1ec15ebc@ohm.scrye.com> On Thu, 5 Nov 2009 15:35:23 +0000 Peter Robinson wrote: > These are mine: > pbrobinson:BADURL:ccss-0.5.0.tar.gz:ccss > pbrobinson:BADURL:libccss-0.4.0.tar.gz:libccss > pbrobinson:BADURL:mutter-2.28.0.tar.bz2:mutter > pbrobinson:BADURL:rygel-0.4.4.tar.bz2:rygel > > The first two lost their hosting when one of the freedesktop.org > servers crashed and people's home dirs were lost. I'm looking for the > new location for the hosting of this. fedorahosted.org ? > Both mutter and ryfel are fixed in cvs but I don't see the point in > pushing a new release for a single character change so it will be > fixed with the next release. yeah, no need to build/push new releases. Just commit it for the next real issue. Thanks. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From tibbs at math.uh.edu Thu Nov 5 18:21:08 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 05 Nov 2009 12:21:08 -0600 Subject: source file audit - 2009-11-01 In-Reply-To: <20091105110944.236d9d07@ohm.scrye.com> (Kevin Fenzi's message of "Thu, 5 Nov 2009 11:09:44 -0700") References: <20091104171816.0ef2c0a5@ohm.scrye.com> <20091105113904.GA1660@amd.home.annexia.org> <20091105110944.236d9d07@ohm.scrye.com> Message-ID: >>>>> "KF" == Kevin Fenzi writes: KF> Well, the script I am running uses 'spectool -g' and indeed, it KF> doesn't handle self signed certs: Honestly, I find it easier to just hack spectool rather than reject valid URLs that just happen to use self-signed certificates. You might also be able to tweak /etc/fedora/wgetrc to achieve the same thing. - J< From guido.grazioli at gmail.com Thu Nov 5 18:48:59 2009 From: guido.grazioli at gmail.com (Guido Grazioli) Date: Thu, 5 Nov 2009 19:48:59 +0100 Subject: Fedora with Universal Binaries? In-Reply-To: <20091024145754.GA1446@genius.kawo2.rwth-aachen.de> References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com> <20091023173525.GA9400@host0.dyn.jankratochvil.net> <4AE30BCF.7030304@redhat.com> <20091024145754.GA1446@genius.kawo2.rwth-aachen.de> Message-ID: <2f984ea00911051048r5700beaaic492bdef7835b02@mail.gmail.com> 2009/10/24 Till Maas : > For me it would be useful to have a simple way to make a USB > installation device for both my 32bit and 64bit machines. Also a single > rescue system for both 64bit and 32bit machines would be nice. I agree; grub2 can boot iso images and seems to come handy for that task, this guide was helpful also: http://www.panticz.de/MultiBootUSB -- Guido Grazioli Via Parri 11 48011 - Alfonsine (RA) Mobile: +39 347 1017202 (10-18) Key FP = 7040 F398 0DED A737 7337 DAE1 12DC A698 5E81 2278 Linked in: http://www.linkedin.com/in/guidograzioli From mike.cloaked at gmail.com Thu Nov 5 19:32:38 2009 From: mike.cloaked at gmail.com (Mike Cloaked) Date: Thu, 5 Nov 2009 19:32:38 +0000 (UTC) Subject: A question about allow_unconfined_mmap_low in f11 amd selinux References: <3b8e57a80911040723x280abfd0jf6bab04bf4803390@mail.gmail.com> <4AF1A2C5.8010008@redhat.com> Message-ID: Mike Cloaked gmail.com> writes: > > Daniel J Walsh redhat.com> writes: > > > > > On 11/04/2009 10:23 AM, mike cloaked wrote: > > > > By "moving forward" do you mean that one can, in f11, reset the > > > original boolean and set boolean mmap_low_allowed instead, in a > > > forthcoming policy update? > > > > > > Or is this a planned change coming for f12 but not yet policy in > > > earlier versions? > > > > > > Thanks > > > > > We have setroubleshoot plugins that explain exactly to the users what > they need to do to turn make their wine > > apps run. > > > > Does the dereference fix in kernel-2.6.30.9-96.fc11 address the issue raised > here or have I got this wrong? > I am somewhat confused by the following - I thought that if mmap_min_addr was >0 then you are not vulnerable. I also thought that installing wine, OR Crossover would set it to zero. I have Crossover installed and not wine, and just checked: [mike at home1 ~]$ cat /proc/sys/vm/mmap_min_addr 65536 This is an f11 box. I also set the boolean by doing # setsebool -P allow_unconfined_mmap_low 1 Now I have lost track whether this means I am vulnerable or not? I understand that installing wine would set mmap_min_addr to zero and make the machine vulnerable but can someone clarify so that I no longer confused? Thanks. From ville.skytta at iki.fi Thu Nov 5 19:33:48 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 5 Nov 2009 21:33:48 +0200 Subject: source file audit - 2009-11-01 In-Reply-To: References: <20091104171816.0ef2c0a5@ohm.scrye.com> <20091105110944.236d9d07@ohm.scrye.com> Message-ID: <200911052133.48629.ville.skytta@iki.fi> On Thursday 05 November 2009, Jason L Tibbitts III wrote: > >>>>> "KF" == Kevin Fenzi writes: > > KF> Well, the script I am running uses 'spectool -g' and indeed, it > KF> doesn't handle self signed certs: > > Honestly, I find it easier to just hack spectool rather than reject > valid URLs that just happen to use self-signed certificates. You might > also be able to tweak /etc/fedora/wgetrc to achieve the same thing. Unless there are objections, I'll make spectool use wget --no-check- certificate in the next rpmdevtools release (internally, because shipping a /etc/fedora/wgetrc would be a backwards incompatible change that could break stuff). From orion at cora.nwra.com Thu Nov 5 21:49:10 2009 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 05 Nov 2009 14:49:10 -0700 Subject: cron no longer working in F-12 Message-ID: <4AF34856.5000400@cora.nwra.com> I'm seeing the following in my /var/log/cron files on my 3 F-12 machines: Nov 5 14:10:01 orca crond[6287]: (root) FAILED to open PAM security session (Failure setting user credentials) and jobs aren't running. Anyone else seeing this? https://bugzilla.redhat.com/show_bug.cgi?id=533289 -- 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 5 21:53:35 2009 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 05 Nov 2009 14:53:35 -0700 Subject: cron no longer working in F-12 In-Reply-To: <4AF34856.5000400@cora.nwra.com> References: <4AF34856.5000400@cora.nwra.com> Message-ID: <4AF3495F.5080001@cora.nwra.com> On 11/05/2009 02:49 PM, Orion Poplawski wrote: > I'm seeing the following in my /var/log/cron files on my 3 F-12 machines: > > Nov 5 14:10:01 orca crond[6287]: (root) FAILED to open PAM security > session (Failure setting user credentials) > > and jobs aren't running. Anyone else seeing this? > > > https://bugzilla.redhat.com/show_bug.cgi?id=533289 > Ah, already reported as 533189 and fix building. Should get tagged for F-12. -- 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 Thu Nov 5 22:24:20 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 5 Nov 2009 23:24:20 +0100 Subject: source file audit - 2009-11-01 In-Reply-To: <20091104171816.0ef2c0a5@ohm.scrye.com> References: <20091104171816.0ef2c0a5@ohm.scrye.com> Message-ID: <6f3c7953b638060b37f7fc15bf3be472.squirrel@arekh.dyndns.org> Le Jeu 5 novembre 2009 01:18, Kevin Fenzi a ?crit : Thanks a > nim:BADSOURCE:Tribun-Std.zip:adf-tribun-fonts > jussilehtola:BADURL:agedu-r8642.tar.gz:agedu > ruben:BADURL:Ajaxterm-0.10.tar.gz:Ajaxterm > pcheung:BAD_CVS_SOURCE:ant-1.7.1.pom:ant > tagoh:BADURL:anthy-9100h.tar.gz:anthy > dwmw2:BADURL:apmud-1.0.0.tgz:apmud > athimm:BADURL:apt-0.5.15lorg3.95.git416.tar.bz2:apt > sherry151:BADSOURCE:archmage-0.2.4.tar.gz:archmage > athimm:BAD_CVS_SOURCE:RiceBSD.doc:arpack > than:BADURL:arts-1.5.10.tar.bz2:arts > jstanley:BADSOURCE:asyropoulos_-_Asana_Math.otf:asana-math-fonts > chrisw:BADURL:asciidoc-8.4.5.tar.gz:asciidoc > spot:BADURL:asymptote-1.88.src.tgz:asymptote > mschwendt:BADURL:audacious-plugin-fc-0.4.tar.bz2:audacious-plugin-fc > tmraz:BADURL:authconfig-5.4.13.tar.bz2:authconfig > pwouters:BADURL:autotrust-0.3.1.tar.gz:autotrust > sindrepb:BADURL:avant-window-navigator-0.3.2.tar.gz:avant-window-navigator > tnorth:BADSOURCE:gcc-core-4.3.3.tar.bz2:avr-gcc > phuang:BADURL:awn-extras-applets-0.3.2.2.tar.gz:awn-extras-applets > abompard:BADURL:awstats-6.9.tar.gz:awstats > bjensen:BADURL:ax25-tools.tar.gz:ax25-tools > overholt:BAD_CVS_SOURCE:backport-util-concurrent-3.1.pom:backport-util-concurrent > ixs:BADURL:bacula-3.0.3.tar.gz:bacula > ixs:BADURL:bacula-docs-3.0.3.tar.bz2:bacula > zkota:BADURL:bazaar_1.4.2.tar.gz:bazaar > zkota:BADURL:bazaar-doc_1.4.tar.gz:bazaar > satyak:BADSOURCE:beacon-0.5.tar.gz:beacon > danken:BADURL:bidiv-1.5.tgz:bidiv > peter:BADSOURCE:bios_extract-17ca1c5e6a8df6b5663e899504d197862c286d1e.tar.bz2:bios_extract > jskala:BADURL:bltk-1.0.9.tar.gz:bltk > akahl:BADURL:bmpx-0.40.14.tar.bz2:bmpx > rrakus:BADSOURCE:netkit-bootparamd-0.17.tar.gz:bootparamd > langel:BAD_CVS_SOURCE:bcprov-jdk16-1.43.pom:bouncycastle > oget:BAD_CVS_SOURCE:bcmail-jdk16-1.43.pom:bouncycastle-mail > oget:BAD_CVS_SOURCE:bctsp-jdk16-1.43.pom:bouncycastle-tsp > fab:BADURL:bournal-1.3.tar.gz:bournal > mattdm:BADURL:calc-2.12.2.1.tar.gz:calc > nomis80:BADURL:camstream-0.26.3.tar.gz:camstream > rrelyea:BADSOURCE:ccid-1.3.9.tar.bz2:ccid > pbrobinson:BADURL:ccss-0.5.0.tar.gz:ccss > hubbitus:BADURL:ccze-0.2.1.tar.gz:ccze > mmahut:BADSOURCE:cdk.tar.gz:cdk > edhill:BADSOURCE:cdo.pdf:cdo > edhill:BADSOURCE:cdo_refcard.pdf:cdo > steve:BADURL:celestia-1.5.1.tar.gz:celestia > sheltren:BADURL:cfengine-2.2.10.tar.gz:cfengine > gilboa:BAD_CVS_SOURCE:cgdb.png:cgdb > jortel:BADSOURCE:chameleon-0.2.tar.gz:chameleon > dwalsh:BADURL:checkpolicy-2.0.19.tgz:checkpolicy > pali:BADURL:cherokee-0.99.24.tar.gz:cherokee > trasher:BADURL:childsplay-1.4.tgz:childsplay > herlo:BADSOURCE:2bc.zip:chisholm-to-be-continued-fonts > athimm:BADURL:chrpath-0.13.tar.gz:chrpath > fnasser:BADSOURCE:inetlib-1.1.1.tar.gz:classpathx-mail > jmrcpn:BADSOURCE:clement-2.1.320.tar.gz:clement > walters:BADURL:clojure_20090320.zip:clojure > sergiopr:BADURL:cloudy_v07_02_01.tar.gz:cloudy > beekhof:BADSOURCE:b79635605337.tar.bz2:cluster-glue > itamarjp:BADURL:clutter-gst-0.10.0.tar.bz2:clutter-gst > orphan:BADURL:cluttermm-0.9.4.20090907git.tar.bz2:cluttermm > rjones:BADURL:coccinelle-0.1.10.tgz:coccinelle > green:BADURL:common-lisp-controller_6.15.tar.gz:common-lisp-controller > markhla:BADSOURCE:comoonics-base-py-0.1.tar.gz:comoonics-base-py > elcody02:BADSOURCE:comoonics-cdsl-py-0.2.tar.gz:comoonics-cdsl-py > elcody02:BADSOURCE:comoonics-cluster-py-0.1.tar.gz:comoonics-cluster-py > krh:BADURL:compiz-0.8.2.tar.bz2:compiz > notting:BADURL:comps-extras-17.tar.gz:comps-extras > steve:BADURL:cone-0.78.tar.bz2.sig:cone > bpeck:BADURL:conmux-493svn.tar.gz:conmux > gemi:BADSOURCE:cook-2.32.tar.gz:cook > ovasik:BADURL:coreutils-8.0.tar.xz:coreutils > cweyl:BADURL:cpan-upload-2.2.tar.gz:cpan-upload > sergiopr:BADURL:cpl-5.0.1.tar.gz:cpl > mmahut:BADURL:cpm-0.23beta.tar.gz:cpm > bradbell:BADSOURCE:cppad-20090303.0.gpl.tgz:cppad > sundaram:BADSOURCE:cryptopp560.zip:cryptopp > chitlesh:BADURL:crystal-kwin4-1.0.5.tar.bz2:crystal > chitlesh:BADURL:CrystalClear.tar.gz:crystal-clear > chitlesh:BADSOURCE:crystal_project.tar.gz:crystal-project > nhorman:BADURL:cscope-15.6.tar.gz:cscope > jwilson:BADURL:ctrlproxy-3.0.8.tar.gz:ctrlproxy > twaugh:BADURL:cups-1.4.1-source.tar.bz2:cups > gemi:BADSOURCE:curry-0.9.11.tar.gz:curry > desi:BADSOURCE:cwrite-0.1.24.tar.gz:cwrite > nbecker:BADURL:Cython-0.11.3.tar.gz:Cython > spot:BADSOURCE:daa2iso.zip:daa2iso > jjh:BADURL:darcs-2.2.1.tar.gz:darcs > fab:BADSOURCE:dateshift-1.1.tar.gz:dateshift > pfj:BADSOURCE:db4o-6.1-mono.tar.gz:db4o > davidz:BADSOURCE:dbus-1.2.16.tar.gz:dbus > rdieter:BADSOURCE:dbus-1-qt3-0.9.tar.gz:dbus-qt3 > limb:BADURL:ddd-3.3.12.tar.gz:ddd > ixs:BADSOURCE:dd_rhelp-0.1.2.tar.gz:dd_rescue > ruben:BADURL:debmirror_20090807.tar.gz:debmirror > kasal:BADURL:debootstrap_1.0.19.tar.gz:debootstrap > pgordon:BADURL:deluge-1.2.0_rc1.tar.bz2:deluge > bjensen:BADSOURCE:demorse-0.9.tar.gz:demorse > sharkcz:BADURL:devio-1.2.tar.gz:devio > ensc:BADURL:dhcp-forwarder-0.8.tar.bz2:dhcp-forwarder > ensc:BADURL:dhcp-forwarder-0.8.tar.bz2.asc:dhcp-forwarder > fnasser:BAD_CVS_SOURCE:naming-resources-0.8.pom:directory-naming > robmv:BADSOURCE:dirvish-1.2.1.tgz:dirvish > lvm-team:BADURL:dmraid-1.0.0.rc16.tar.bz2:dmraid > pwouters:BADURL:dnssec-conf-1.22.tar.gz:dnssec-conf > awjb:BADURL:dosbox-0.73.tar.gz:dosbox > sergiopr:BADURL:ds9.5.4.tar.gz:ds9 > fkooman:BADSOURCE:dumpasn1.c:dumpasn1 > pjones:BADURL:dumpet-2.0.tar.bz2:dumpet > jgu:BADURL:dvipdfmx-20090708.tar.gz:dvipdfmx > guthrie:BADURL:dxpc-3.9.1.tgz:dxpc > till:BADURL:dzen2-latest.tar.gz:dzen2 > fnasser:BAD_CVS_SOURCE:easymock-1.2_Java1.5.pom:easymock > mmahut:BADURL:eboard-1.1.1.tar.bz2:eboard > spot:BADURL:ebtables-v2.0.9-1.tar.gz:ebtables > dbhole:BAD_CVS_SOURCE:core-3.3.0-v_771.pom:ecj > overholt:BADURL:eclipse-build-0.4.0RC0.tar.gz:eclipse > jjohnstn:BADURL:eclipse-cdt-fetched-src-autotools-v200910161608.tar.gz:eclipse-cdt > jjohnstn:BADURL:eclipse-cdt-fetched-src-libhover-R0_3_0.tar.gz:eclipse-cdt > anithra:BADSOURCE:com.ibm.systemtapgui.src.tar.gz:eclipse-systemtapgui > than:BADURL:efax-0.9a-001114.tar.gz:efax > davidz:BADURL:eggdbus-0.5.tar.gz:eggdbus > rdieter:BADSOURCE:default.tar.bz2:eigen2 > kdudka:BADURL:eject-2.1.5.tar.gz:eject > veillard:BADURL:ekiga-3.2.6.tar.bz2:ekiga > ausil:BADSOURCE:elftoaout-2.3.tgz:elftoaout > dnovotny:BAD_CVS_SOURCE:rpm-spec-mode.el:emacs > jkeating:BADSOURCE:email2trac.tar.gz:email2trac > sharkcz:BADSOURCE:entertrack-1.2.6.tar.gz:entertrack > icon:BADURL:epylog-1.0.3.tar.gz:epylog > gemi:BADURL:esdl-1.0.1.src.tar.gz:erlang-esdl > sergiopr:BADURL:esorex-3.7.2.tar.gz:esorex > mbarnes:BADURL:evolution-2.28.0.tar.bz2:evolution > bpepple:BADURL:evolution-brutus-1.2.35.tar.gz:evolution-brutus > mbarnes:BADURL:evolution-data-server-2.29.1.tar.bz2:evolution-data-server > mbarnes:BADURL:evolution-exchange-2.28.0.tar.bz2:evolution-exchange > mbarnes:BADURL:evolution-mapi-0.28.0.tar.bz2:evolution-mapi > mbarnes:BADURL:evolution-sharp-0.21.1.tar.bz2:evolution-sharp > deji:BADURL:exaile-0.3.0.1.tar.gz:exaile > dwmw2:BADURL:FAQ-html-20050415.tar.bz2:exim-doc > dwmw2:BADURL:config.samples-20050415.tar.bz2:exim-doc > itamarjp:BADSOURCE:ez-ipupdate-3.0.11b8.tar.gz:ez-ipupdate > itamarjp:BADURL:ez-ipupdate_3.0.11b8-10.diff.gz:ez-ipupdate > silas:BADSOURCE:fabric-0.9b1.tar.gz:fabric > athimm:BADURL:fakeroot_1.12.2.tar.gz:fakeroot > rjones:BADURL:febootstrap-2.5.tar.gz:febootstrap > akurtakov:BADURL:org.osgi.core-1.2.0-project.tar.gz:felix-osgi-core > 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 > gemi:BADURL:ffcall-20080704cvs.tar.bz2:ffcall > rineau:BADSOURCE:figtoipe-20080505.tar.gz:figtoipe > nbecker:BADURL:filelight-1.9-rc2.tgz:filelight > mebrown:BADURL:firmware-addon-dell-2.1.2.tar.gz:firmware-addon-dell > mebrown:BADSOURCE:firmware-tools-2.1.5.tar.gz:firmware-tools > deji:BADURL:flagpoll-0.9.1.tar.gz:flagpoll > bellet:BAD_CVS_SOURCE:fg-16.png:FlightGear > green:BADURL:fluidsynth-dssi-1.0.0.tar.gz:fluidsynth-dssi > andriy:BAD_CVS_SOURCE:fmio-gq-wrapper.py:fmio > than:BADURL:cyr-rfx-koi8-ub-1.1.bdfs.tar.bz2:fonts-KOI8-R > than:BADURL:ksi-XFree86-cyrillic-fonts.tar.bz2:fonts-KOI8-R > twaugh:BADURL:foomatic-db-4.0-20090819.tar.gz:foomatic-db > sheltren:BADURL:fortune-mod-1.99.1.tar.gz:fortune-mod > sheltren:BADURL:fortune-tao.tar.gz:fortune-mod > sheltren:BADURL:fortune-hitchhiker.tgz:fortune-mod > sheltren:BADURL:osfortune.tar.gz:fortune-mod > hubbitus:BADURL:fotoxx-8.0.tar.gz:fotoxx > joost:BADURL:fpcbuild-2.2.4.tar.gz:fpc > awjb:BADURL:freealut-1.1.0.tar.gz:freealut > tanguy:BADURL:freehdl-0.0.7.tar.gz:freehdl > jdetaeye:BADSOURCE:frepple-0.7.1.tar.gz:frepple > cgrau:BADURL:frotz-2.43.tar.gz:frotz > lkundrak:BADURL:tex-fusecompress-4e07d3fe1c61f9a83732eb3021e3016feb008bdb.tar.gz:fusecompress > ertzing:BADSOURCE:fwbuilder-3.0.5.tar.gz:fwbuilder > firewing:BADSOURCE:fwfstab-0.03.tar.gz:fwfstab > cweyl:BADURL:qrc-0.96-293svn.tar.gz:gaim-gaym > cweyl:BADURL:gaim-2.0.0beta4.tar.gz:gaim-gaym > laxathom:BADURL:gammu-1.25.92.tar.bz2:gammu > pfj:BADSOURCE:gDeskCal-1.01.tar.gz:gdeskcal > kevin:BADURL:gdk-pixbuf-0.22.0.tar.bz2:gdk-pixbuf > chitlesh:BADURL:geda-gaf-1.6.0.tar.gz:geda-gaf > chitlesh:BADURL:geda-gnetlist-1.4.3.tar.gz:geda-gnetlist > sergiopr:BADURL:LaTeXPlugin-0.2rc2.tar.gz:gedit-latex-plugin > thias:BADURL:gentoo-0.15.2.tar.gz:gentoo > rdieter:BADSOURCE:geomview-1.9.4.tar.bz2:geomview > nim:BADSOURCE:GFS_DECKER.zip:gfs-decker-fonts > nim:BADSOURCE:GFS_GAZIS.zip:gfs-gazis-fonts > nim:BADSOURCE:GFS_NEOHELLENIC_OT.zip:gfs-neohellenic-fonts > nim:BADSOURCE:GFS_PYRSOS.zip:gfs-pyrsos-fonts > bos:BADURL:ghc-6.12.0.20091010-src.tar.bz2:ghc > petersen:BADURL:cgi-3001.1.7.1.tar.gz:ghc-cgi > bos:BADURL:fgl-5.4.2.2.tar.gz:ghc-fgl > bos:BADURL:GLUT-2.1.1.2.tar.gz:ghc-GLUT > konradm:BADURL:haskell-src-exts-1.1.4.tar.gz:ghc-haskell-src-exts > bos:BADURL:HUnit-1.2.0.3.tar.gz:ghc-HUnit > petersen:BADURL:network-2.2.1.4.tar.gz:ghc-network > bos:BADURL:OpenGL-2.2.1.1.tar.gz:ghc-OpenGL > ynemoy:BADURL:tar-0.3.1.0.tar.gz:ghc-tar > petersen:BADURL:time-1.1.2.4.tar.gz:ghc-time > zoglesby:BADURL:X11-xft-0.3.tar.gz:ghc-X11-xft > ynemoy:BADURL:xmonad-contrib-0.8.1.tar.gz:ghc-xmonad-contrib > rakesh:BADURL:ginac-1.5.1.tar.bz2:ginac > mycae:BADURL:givaro-3.3.0.tar.gz:givaro > thias:BADSOURCE:gkrellm-gkfreq-1.0.tar.gz:gkrellm-freq > bruno:BADURL:glest_data_3.2.1.zip:glest-data > rafalzaq:BADURL:glob2-0.9.4.1.tar.gz:glob2 > remi:BADURL:glpi-datainjection-1.7.0.tar.gz:glpi-data-injection > adrian:BADURL:gmpc-0.18.0.tar.gz:gmpc > adrian:BADURL:gmpc-alarm-0.18.0.tar.gz:gmpc > adrian:BADURL:gmpc-lyricwiki-0.18.0.tar.gz:gmpc > adrian:BADURL:gmpc-magnatune-0.18.0.tar.gz:gmpc > adrian:BADURL:gmpc-mdcover-0.18.0.tar.gz:gmpc > adrian:BADURL:gmpc-mserver-0.18.0.tar.gz:gmpc > adrian:BADURL:gmpc-osd-0.18.0.tar.gz:gmpc > adrian:BADURL:gmpc-shout-0.18.0.tar.gz:gmpc > adrian:BADURL:gmpc-tagedit-0.18.0.tar.gz:gmpc > adrian:BADURL:gmpc-wikipedia-0.18.0.tar.gz:gmpc > adrian:BADURL:gmpc-avahi-0.18.0.tar.gz:gmpc > adrian:BADURL:gmpc-coveramazon-0.18.0.tar.gz:gmpc > adrian:BADURL:gmpc-extraplaylist-0.18.0.tar.gz:gmpc > adrian:BADURL:gmpc-jamendo-0.18.0.tar.gz:gmpc > adrian:BADURL:gmpc-last-fm-0.18.0.tar.gz:gmpc > adrian:BADURL:gmpc-libnotify-0.18.0.tar.gz:gmpc > adrian:BADURL:gmpc-lirc-0.18.0.tar.gz:gmpc > adrian:BADURL:gmpc-lyrics-0.18.0.tar.gz:gmpc > laxathom:BADURL:grandr_applet-0.4.1.tar.gz:gnome-applet-grandr > cwickert:BADURL:timer-applet-2.1.2.tar.gz:gnome-applet-timer > orphan:BADURL:tvn24_0.2.8-1.tar.gz:gnome-applet-tvn24 > orphan:BADURL:gnome-blog-0.9.1.tar.bz2:gnome-blog > mtasaka:BADURL:gnome-commander-1.3-git_D20090623T0316_13dev.tar.bz2:gnome-commander > hadess:BADURL:gnome-lirc-properties-0.4.0.tar.gz:gnome-lirc-properties > rhughes:BADURL:gnome-packagekit-2.28.1-20090928.tar.gz:gnome-packagekit > rhughes:BADURL:gnome-power-manager-2.28.0.tar.bz2:gnome-power-manager > mbarnes:BADURL:gnome-python-2.28.0.tar.bz2:gnome-python2 > otaylor:BADURL:gnome-shell-2.28.0.tar.bz2:gnome-shell > mwiriadi:BADURL:gnome-themes-extras-2.22.0.tar.gz:gnome-themes-extras > orphan:BADURL:gnome-yum-0.1.4.tar.gz:gnome-yum > clumens:BADURL:gnu-efi-3.0e.tar.bz2:gnu-efi > nsantos:BADURL:gnu.regexp-1.1.4.tar.gz:gnu-regexp > bjohnson:BADURL:goocanvas-0.14.tar.bz2:goocanvas > denis:BADURL:goocanvasmm-0.14.0.tar.bz2:goocanvasmm > nim:BAD_CVS_SOURCE:NOTICE:google-droid-fonts > npajkovs:BADURL:gpm-1.20.6.tar.lzma:gpm > bonii:BADURL:gquilt-0.20.tar.gz:gquilt > jcollie:BADURL:gramps-3.1.2.tar.gz:gramps > vlg:BADURL:granule-1.4.0.tar.gz:granule > mmahut:BADSOURCE:grc_0.70.tar.gz:grc > chitlesh:BADSOURCE:gresistor-0.0.1.tar.gz:gresistor > deebs:BADSOURCE:GREYCstoration-2.8.zip:GREYCstoration > athimm:BADURL:greylistd_0.8.7.tar.gz:greylistd > orphan:BADSOURCE:gst-plugins-0.8.12.tar.bz2:gstreamer08-plugins > denis:BADURL:gstreamermm-0.10.5.tar.bz2:gstreamermm > ixs:BADURL:gsynaptics-0.9.16.tar.gz:gsynaptics > rrankin:BAD_CVS_SOURCE:gtk+extra-2.1.1.tar.gz:gtk+extra > buc:BADURL:gtk-gnutella-0.96.6.tar.bz2:gtk-gnutella > mbarnes:BADURL:gtkhtml-3.29.1.tar.bz2:gtkhtml3 > mso:BADURL:gtk-nodoka-engine-0.7.2.tar.gz:gtk-nodoka-engine > maxx:BADURL:39179-rezlooks-0.6.tar.gz:gtk-rezlooks-engine > maxx:BADSOURCE:Rezlooks-Gilouche.tar.gz:gtk-rezlooks-engine > maxx:BADSOURCE:Rezlooks-Snow.tar.gz:gtk-rezlooks-engine > maxx:BADSOURCE:Rezlooks-candy.tar.gz:gtk-rezlooks-engine > maxx:BADSOURCE:Rezlooks-graphite.tar.gz:gtk-rezlooks-engine > maxx:BADSOURCE:Rezlooks-dark.tar.gz:gtk-rezlooks-engine > laxathom:BADURL:gtk-sharp-2.12.9.tar.bz2:gtk-sharp2 > pfj:BADURL:gtksourceview2-sharp-89788.tar.bz2:gtksourceview2-sharp > pfj:BADURL:gtksourceview-sharp-2.0-0.12.tar.bz2:gtksourceview-sharp > twaugh:BADURL:gutenprint-5.2.4.tar.bz2:gutenprint > dwalluck:BAD_CVS_SOURCE:hamcrest-parent-1.1.pom:hamcrest > maxx:BADURL:hamster-applet-2.28.1.tar.bz2:hamster-applet > petersen:BADURL:haskell-platform-2009.2.0.2.tar.gz:haskell-platform > orion:BADURL:hdf5-1.8.3-snap12.tar.gz:hdf5 > jwilson:BADURL:libhdhomerun_20090415.tgz:hdhomerun > jwilson:BADURL:hdhomerun_config_gui_20090415.tgz:hdhomerun > sharkcz:BADSOURCE:herculesstudio-1.0.0-src.tar.gz:hercstudio > cweyl:BADURL:diskdev_cmds-332.14.tar.gz:hfsplus-tools > cweyl:BAD_CVS_SOURCE:apsl-2.0.txt:hfsplus-tools > dwmw2:BADURL:hfsplus_1.0.4.src.tar.bz2:hfsplusutils > walters:BADURL:hippo-canvas-0.3.0.tar.gz:hippo-canvas > petersen:BADURL:hscolour-1.15.tar.gz:hscolour > jorton:BADURL:httpd-2.2.13.tar.gz:httpd > rishi:BADSOURCE:httrack-3.43-2.tar.gz:httrack > caolanm:BADURL:hunspell-hil-0.13.oxt:hunspell-hil > caolanm:BADSOURCE:hu_HU-1.5.tar.gz:hunspell-hu > caolanm:BADURL:sjp-myspell-pl-20090908.zip:hunspell-pl > ensc:BADURL:hunt-1.5.tgz:hunt > caolanm:BADURL:nagybence-huhyphn-aa3fc85f5ea7450f84f0cd3881a09ca065198dfc.tar.gz:hyphen-hu > dchen:BADSOURCE:ibus-chewing-1.2.0.20091002-Source.tar.gz:ibus-chewing > phuang:BADURL:pinyin-database-0.1.10.6.tar.bz2:ibus-pinyin > cchance:BADURL:ibus-table-cangjie-1.2.0.20090831.tar.gz:ibus-table-cangjie > gilboa:BAD_CVS_SOURCE:icewm-xdg-menu:icewm > cgrau:BADURL:ifm-5.1.tar.gz:ifm > pfj:BADURL:ikvm-0.22.tar.gz:ikvm > rineau:BADSOURCE:ipe-6.0pre32patch1-src.tar.gz:ipe > ensc:BADSOURCE:ip-sentinel-0.12.tar.bz2.sig:ip-sentinel > lkundrak:BADURL:ircp-tray-0.7.3.tar.gz:ircp-tray > karsten:BADURL:irda-utils-0.9.18.tar.gz:irda-utils > than:BADURL:isdn4k-utils-CVS-2009-10-20.tar.bz2:isdn4k-utils > rishi:BADURL:isight-firmware-tools-1.0.2.tar.gz:isight-firmware-tools > anaconda-maint:BADURL:isomd5sum-1.0.5.tar.bz2:isomd5sum > rezso:BADURL:verilog-0.9.1.tar.gz:iverilog > jfch2222:BADURL:iwak-2.5.tgz:iwak > fnasser:BAD_CVS_SOURCE:commons-configuration-1.4.pom:jakarta-commons-configuration > dbhole:BAD_CVS_SOURCE:commons-dbcp-1.2.1.pom:jakarta-commons-dbcp > mbooth:BADURL:commons-digester-1.7-src.tar.gz:jakarta-commons-digester > fnasser:BAD_CVS_SOURCE:commons-el-1.0.pom:jakarta-commons-el > fnasser:BAD_CVS_SOURCE:commons-jxpath-1.2.pom:jakarta-commons-jxpath > mbooth:BADURL:commons-modeler-2.0-src.tar.gz:jakarta-commons-modeler > dbhole:BADURL:commons-validator-1.1.4-src.tar.gz:jakarta-commons-validator > tagoh:BAD_CVS_SOURCE:k14.patch:japanese-bitmap-fonts > langel:BADSOURCE:icedtea6-1.6.tar.gz:java-1.6.0-openjdk > bkearney:BADSOURCE:java-augeas-0.0.1.tar.gz:java-augeas > mtasaka:BADURL:jd-2.5.0-svn3140_trunk.tgz:jd > itamarjp:BADURL:jfsutils-1.1.13.tar.gz:jfsutils > wolfy:BADURL:jnettop-0.13.0.tar.gz:jnettop > snecker:BADURL:jokosher-20090604svn.tar.gz:jokosher > overholt:BADURL:apache.zip:json > gajownik:BADSOURCE:kadu-split_messages-0.3.tar.bz2:kadu > orphan:BADSOURCE:kbiof-0.3.tar.gz:kbiof > than:BADURL:kdbg-2.1.1.tar.gz:kdbg > 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-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-nb-3.5.10.tar.bz2:kde-i18n > than:BADURL:kde-i18n-bn-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-ca-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-i18n-lt-3.5.10.tar.bz2:kde-i18n > than:BADURL:kde-i18n-ko-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-l10n-ar-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-es-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-et-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-eu-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-fi-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-fr-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-ga-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-gl-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-hi-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-hu-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-bg-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-it-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-ja-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-km-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-ko-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-ku-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-lv-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-lt-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-mk-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-ml-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-nb-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-ca-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-nds-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-nl-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-nn-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-pa-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-pl-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-pt-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-pt_BR-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-ru-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-cs-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-sk-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-sl-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-sv-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-th-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-tr-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-uk-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-wa-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-zh_CN-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-zh_TW-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-csb-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-sr-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-kk-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-he-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-bn_IN-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-gu-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-is-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-kn-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-mai-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-mr-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-da-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-ro-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-tg-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-hr-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-de-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-el-4.3.2.tar.bz2:kde-l10n > than:BADURL:kde-l10n-en_GB-4.3.2.tar.bz2:kde-l10n > rdieter:BADURL:kdelibs-experimental-4.3.2.tar.bz2:kdelibs-experimental > than:BADURL:kdepim-runtime-4.3.2.tar.bz2:kdepim-runtime > eliwap:BADURL:91009-iHateTheCashew-4.2.tbz:kde-plasma-ihatethecashew > eliwap:BADURL:translatoid1.0.tar.gz:kde-plasma-translatoid > than:BADSOURCE:css.tar.bz2:kdewebdev > than:BADSOURCE:html.tar.bz2:kdewebdev > than:BADSOURCE:javascript.tar.bz2:kdewebdev > ben:BADSOURCE:ketchup-0.9.8.tar.bz2:ketchup > chitlesh:BADURL:keurocalc-1.0.0.tgz:keurocalc > jstanley:BADURL:keychecker-0.2.tar.gz:keychecker > bouska:BADURL:kitsune2.0.tar.gz:kitsune > awjb:BADURL:koffice-l10n-en_GB-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-es-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-et-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-fr-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-fy-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-gl-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-hne-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-it-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-ja-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-kk-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-nb-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-nds-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-nl-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-pl-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-pt-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-pt_BR-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-ca-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-sv-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-tr-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-uk-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-wa-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-zh_CN-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-zh_TW-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-da-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-de-2.0.91.tar.bz2:koffice-langpack > awjb:BADURL:koffice-l10n-el-2.0.91.tar.bz2:koffice-langpack > jkeating:BADSOURCE:koji-1.3.1.tar.bz2:koji > ausil:BADURL:konversation-1.2.tar.bz2:konversation > roma:BADURL:kradio4-4.0.0.tar.bz2:kradio4 > ausil:BADURL:krecipes-1.0-beta2.tar.gz:krecipes > kkofler:BADURL:ksensors_0.7.3-15.diff.gz:ksensors > sxw:BADURL:kstart-3.11.tar.gz:kstart > akurtakov:BADURL:kxml2-src-2.2.2.zip:kxml > akurtakov:BAD_CVS_SOURCE:kxml2-2.2.2.pom:kxml > pwouters:BADURL:ldns-1.6.1.tar.gz:ldns > kevin:BADURL:leafnode-1.11.7.tar.bz2:leafnode > konradm:BADURL:L-1.2.tar.gz:L-function > thomasvs:BADSOURCE:libannodex-0.7.3.tar.gz:libannodex > mso:BADURL:libass-0.9.8.tar.bz2:libass > jmoskovc:BADURL:libbtctl-0.11.1.tar.bz2:libbtctl > pbrobinson:BADURL:libccss-0.4.0.tar.gz:libccss > thomasvs:BADSOURCE:libcmml-0.9.1.tar.gz:libcmml > kaitlin:BADSOURCE:libcmpiutil-0.5.tar.gz:libcmpiutil > edhill:BADURL:libctl-3.0.2.tar.gz:libctl > mikep:BADURL:libdmapsharing-1.9.0.10.tar.gz:libdmapsharing > green:BADURL:libffi-3.0.5.tar.gz:libffi > snecker:BADURL:libflaim-4.9.1052.tar.gz:libflaim > ertzing:BADSOURCE:libfwbuilder-3.0.5.tar.gz:libfwbuilder > denis:BADURL:libgda-4.0.4.tar.bz2:libgda > hadess:BADURL:libgdata-0.5.0.tar.bz2:libgdata > turki:BADURL:libgsasl-0.2.29.tar.gz:libgsasl > hguemar:BADURL:libgtksourceviewmm-0.3.1.tar.bz2:libgtksourceviewmm > jorton:BADURL:libidn-1.9.tar.gz:libidn > dajt:BADSOURCE:libiec61883-1.2.0.tar.gz:libiec61883 > orphan:BADURL:libipoddevice-0.5.3.tar.gz:libipoddevice > asheesh:BADURL:liblicense-0.8.1.tar.gz:liblicense > green:BADURL:liblo-0.24.tar.gz:liblo > adrian:BADURL:libmpd-0.18.0.tar.gz:libmpd > snirkel:BADURL:libmtp-1.0.1.tar.gz:libmtp > srini:BADURL:libnetdevname-0.0.3.tar.bz2:libnetdevname > huzaifas:BADSOURCE:libnova-0.12.1.tar.gz:libnova > chitlesh:BADURL:liborigin-20080225.tar.gz:liborigin > denis:BADURL:libpanelappletmm-2.26.0.tar.bz2:libpanelappletmm > tgl:BADURL:libpng-1.2.39.tar.bz2:libpng > awjb:BADSOURCE:libpolyxmass-0.9.1.tar.gz:libpolyxmass > dwalsh:BADURL:libselinux-2.0.88.tgz:libselinux > dwalsh:BADURL:libsemanage-2.0.39.tgz:libsemanage > dwalsh:BADURL:libsepol-2.0.39.tgz:libsepol > denis:BADURL:libsigc++-1.2.7.tar.bz2:libsigc++ > mebrown:BADSOURCE:libsmbios-2.2.16.tar.bz2:libsmbios > jroth:BADSOURCE:libspe2-2.3.0.135.tar.gz:libspe2 > heffer:BADURL:libsyncml-0.4.6.tar.bz2:libsyncml > jjh:BADURL:crypt-1.17.tar.bz2:libtomcrypt > jjh:BADURL:ltm-0.41.tar.bz2:libtommath > kdudka:BADSOURCE:libtrash-3.2.tgz:libtrash > dchen:BADSOURCE:libUnihan-0.5.3-Source.tar.gz:libUnihan > jwrdegoede:BADURL:libv4l-0.6.3.tar.gz:libv4l > kanarip:BADURL:libvmime-0.9.0.tar.bz2:libvmime > denis:BADURL:libxml++-2.26.0.tar.bz2:libxml++ > awjb:BADURL:libytnef-1.5.tar.bz:libytnef > hguemar:BADSOURCE:listen-0.6.3.tar.gz:listen > kushal:BADURL:liveusb-creator-3.7.3.tar.bz2:liveusb-creator > bos:BADURL:llvm-2.6.tar.gz:llvm > bos:BADURL:clang-2.6.tar.gz:llvm > pravins:BADURL:lohit-kashmiri-2.4.3.tar.gz:lohit-kashmiri-fonts > pravins:BADURL:lohit-maithili-2.4.3.tar.gz:lohit-maithili-fonts > pravins:BADURL:lohit-oriya-2.4.3.tar.gz:lohit-oriya-fonts > jwrdegoede:BADURL:labysource_3.5.1.tar.gz:lostlabyrinth > bjensen:BADSOURCE:lpsk31-1.1.tar.gz:lpsk31 > caolanm:BADSOURCE:lp_solve_5.5.0.15_source.tar.gz:lpsolve > kzak:BADURL:lslk_1.29_W.tar.gz:lslk > emunson:BADSOURCE:lsvpd-1.6.5.tar.gz:lsvpd > dbhole:BADURL:lucene-2.3.1-src.tar.gz:lucene > cwickert:BADURL:lxde-settings-daemon-0.4.tar.bz2:lxde-settings-daemon > jmoskovc:BADURL:lynx2.8.6.tar.bz2:lynx > varekova:BADURL:manpages-ru-0.7.tar.gz:man-pages-ru > arjunroy:BADSOURCE:matahari-0.0.4.tar.gz:matahari > akurtakov:BADURL:maven-bundle-plugin-2.0.0-project.tar.gz:maven-plugin-bundle > dbhole:BAD_CVS_SOURCE:cvsclient-20060125.pom:maven-scm > rdieter:BADURL:macref.pdf:maxima > dwalsh:BADURL:mcstrans-0.3.1.tgz:mcstrans > shakthimaan:BADSOURCE:mcu8051ide-1.3.1.tar.gz:mcu8051ide > jwboyer:BADURL:meanwhile-1.1.0.tar.gz:meanwhile > mtasaka:BAD_CVS_SOURCE:terms-and-conditions-for-IFS-J.html:mecab-ipadic > mclasen:BADURL:media-player-info-3.tar.gz:media-player-info > kushal:BADSOURCE:mediascrapper-0.1.tar.gz:mediascrapper > plindner:BADURL:memcached-1.4.2.tar.gz:memcached > slankes:BADURL:merkaartor-0.14.tar.bz2:merkaartor > ixs:BADURL:metapixel-1.0.2.tar.gz:metapixel > pgordon:BADURL:midori-0.2.0.tar.bz2:midori > rjones:BADURL:libpng-1.2.37.tar.bz2:mingw32-libpng > sailer:BADURL:pangomm-2.26.0.tar.bz2:mingw32-pangomm > plouj:BADSOURCE:physfs-1.0.1.tar.gz:mingw32-physfs > wtogami:BADURL:mkelfImage-2.7.tar.gz:mkelfimage > robert:BADSOURCE:arc4random.c:mksh > sharkcz:BADURL:mm3d-1.3.8.tar.gz:mm3d > timfenn:BADSOURCE:mmdb-1.21.tar.gz:mmdb > jkeating:BADURL:mock-0.9.17.tar.gz:mock > robert:BADSOURCE:mod_log_post-0.1.0.tar.gz:mod_log_post > laxathom:BADURL:mono-2.6.tar.bz2:mono > buhochileno:BADSOURCE:monodevelop-debugger-mdb-2.1.0.tar.bz2:monodevelop-debugger-mdb > pfj:BADURL:monodoc-2.0.zip:monodoc > rmeggins:BADSOURCE:mozldap-6.0.5.tar.gz:mozldap > tbzatek:BAD_CVS_SOURCE:mrxvt.desktop:mrxvt > jnovy:BADSOURCE:multican-0.0.5.tar.gz:multican > mmahut:BADURL:cmunipack-1.1.24.tar.gz:munipack > belegdol:BADURL:museek+-0.2.tar.bz2:museek+ > pbrobinson:BADURL:mutter-2.28.0.tar.bz2:mutter > itamarjp:BADURL:mydns-1.2.8.27.tar.gz:mydns > tgl:BADURL:mysql-5.1.39.tar.gz:mysql > tgl:BADURL:mysql-connector-odbc-5.1.5r1144.tar.gz:mysql-connector-odbc > ausil:BADURL:mysql-gui-tools-5.0r14.tar.gz:mysql-gui-tools > caolanm:BADSOURCE:thes_de_DE_v2.zip:mythes-de > caolanm:BADSOURCE:OOo2-thes_es_ES.tar.bz2:mythes-es > caolanm:BADSOURCE:thes_nl_v2.zip:mythes-nl > caolanm:BADSOURCE:OOo-Thesaurus2-sk_SK.zip:mythes-sk > caolanm:BADSOURCE:thes_sl_SI_v2.zip:mythes-sl > sbehera:BADURL:nabi-0.99.3.tar.gz:nabi > mmcgrath:BADURL:nagios-plugins-1.4.13.tar.gz:nagios-plugins > dwmw2:BADURL:nano-2.0.9.tar.gz:nano > frankb:BADURL:nas-1.9.1.src.tar.gz:nas > frankb:BAD_CVS_SOURCE:nasd.init:nas > bpepple:BADURL:nautilus-image-converter-0.3.0.tar.bz2:nautilus-image-converter > thias:BADSOURCE:ncftp-3.2.2-src.tar.bz2:ncftp > vcrhonek:BADURL:ncpfs-2.2.6.tar.gz:ncpfs > jspaleta:BADSOURCE:nec2c-0.8.tar.gz:nec2c > fnasser:BADURL:nekohtml-0.9.5.tar.gz:nekohtml > pgordon:BADURL:nemiver-0.7.2.tar.bz2:nemiver > lkundrak:BADURL:netbsd-iscsi-20080207.tar.gz:netbsd-iscsi > boodle:BADSOURCE:NetPIPE-3.7.1.tar.gz:NetPIPE > orphan:BADURL:new-1.3.9.tar.gz:new > rathann:BADSOURCE:newsx-1.6.tar.gz:newsx > mlichvar:BADURL:newt-0.52.11.tar.gz:newt > steved:BADURL:nfs.doc.tar.gz:nfs-utils > orphan:BADURL:nhpf-1.42.tar.gz:nhpf > sindrepb:BADURL:nikto-2.03.tar.bz2:nikto > sandeen:BADSOURCE:nilfs-utils-2.0.14.tar.bz2:nilfs-utils > agoode:BADURL:nip2-7.18.2.tar.gz:nip2 > msuchy:BADURL:nocpulse-common-2.0.14.tar.gz:nocpulse-common > jussilehtola:BADSOURCE:noip-duc-linux.tar.gz:noip > davidz:BADURL:notification-daemon-0.4.1.tar.gz:notification-daemon > mccann:BADURL:notification-daemon-engine-slider-0.2.0.tar.bz2:notification-daemon-engine-slider > mmcgrath:BADURL:nrpe-2.12.tar.gz:nrpe > rcritten:BADURL:nss_compat_ossl-0.9.5.tar.gz:nss_compat_ossl > nalin:BADURL:nss_db-2.2.tar.gz:nss_db > nalin:BADURL:nss_ldap-264.tar.gz:nss_ldap > nalin:BADURL:pam_ldap-184.tar.gz:nss_ldap > ndim:BADURL:nted-1.8.6.tar.gz:nted > rakesh:BADSOURCE:GeoLiteCity.dat.gz:ntop > rakesh:BADSOURCE:GeoIPASNum.dat.gz:ntop > drago01:BADSOURCE:numlockx-1.0.tar.gz:numlockx > mhlavink:BADURL:nut-2.4.1.tar.gz:nut > gemi:BADURL:nyqsrc303.zip:nyquist > rathann:BADURL:obexftp-0.23.tar.bz2:obexftp > dbhole:BADURL:ow_util_ant_tasks_1.3.2.zip:objectweb-anttask > fnasser:BAD_CVS_SOURCE:asm-3.1.pom:objectweb-asm > gemi:BADSOURCE:ocaml-3.11-refman.html.tar.gz:ocaml > gemi:BADSOURCE:ocaml-3.11-refman.pdf:ocaml > gemi:BADSOURCE:ocaml-3.11-refman.info.tar.gz:ocaml > rjones:BADURL:ocaml-autoconf-1.1.tar.gz:ocaml-autoconf > rjones:BADSOURCE:pa_do-0.8.10.tar.gz:ocaml-pa-do > jwrdegoede:BADSOURCE:ode-0.11.1.tar.bz2:ode > spot:BADSOURCE:chemoelectric_-_Goudy_Bookletter_1.zip:oflb-goudy-bookletter-1911-fonts > cjb:BADURL:ohm-0.1.1-1.20080921git.tar.gz:ohm > gemi:BADURL:ooRexx-4.0.0-4801.source.tar.gz:oorexx > gemi:BADSOURCE:ooRexx-4.0.0-beta-pdf.zip:oorexx > sdake:BADURL:openais-1.1.0.tar.gz:openais > s4504kr:BADSOURCE:open-cobol-1.1.tar.gz:open-cobol > jmoskovc:BADURL:openobex-1.4.tar.gz:openobex > dnglaze:BADSOURCE:openocd-0.2.0.tar.gz:openocd > aleksey2005:BADURL:openscada-0.6.4.tar.gz:openscada > heffer:BADURL:opengfx-0.1.1-source.tar.gz:openttd-opengfx > steve:BADSOURCE:openvpn-2.1_rc20.tar.gz:openvpn > steve:BADSOURCE:openvpn-2.1_rc20.tar.gz.asc:openvpn > lkundrak:BADURL:ovaldi-5.5.25-src.zip:ovaldi > rdieter:BADURL:oxygen-icons-4.3.2.tar.bz2:oxygen-icon-theme > beekhof:BADSOURCE:ee19d8e83c2a.tar.bz2:pacemaker > rrelyea:BADURL:pam_pkcs11-0.5.3.tar.gz:pam_pkcs11 > orphan:BADURL:pam-script-0.1.7.tar.gz:pam_script > adalloz:BADURL:pan-0.133.tar.bz2:pan > behdad:BADURL:pango-1.26.0.tar.bz2:pango > ovasik:BADURL:passivetex-1.25.zip:passivetex > spot:BADURL:pdsh-2.18.tar.bz2:pdsh > orphan:BADURL:pekwm-0.1.5.tar.bz2:pekwm > kasal:BADURL:Carp-Clan-6.03.tar.gz:perl-Carp-Clan > eseyman:BADURL:CGI-Application-Plugin-FillInForm-1.15.tar.gz:perl-CGI-Application-Plugin-FillInForm > hvad:BADURL:Config-Model-0.638.tar.gz:perl-Config-Model > ixs:BADURL:DBM-Deep-0.983.tar.gz:perl-DBM-Deep > lkundrak:BADURL:HTML-Template-Pro-0.87.tar.gz:perl-HTML-Template-Pro > wtogami:BADURL:IO-Socket-INET6-2.56.tar.gz:perl-IO-Socket-INET6 > mmaslano:BADURL:JavaScript-Beautifier-0.13.tar.gz:perl-JavaScript-Beautifier > ixs:BADURL:MD5-2.03.tar.gz:perl-MD5 > rmeggins:BADURL:perl-mozldap-1.5.2.tar.gz:perl-Mozilla-LDAP > rmeggins:BADURL:Makefile.PL.rpm:perl-Mozilla-LDAP > jussilehtola:BADURL:Net-UPnP-1.41.tar.gz:perl-Net-UPnP > mmaslano:BADURL:Padre-0.32.tar.gz:perl-Padre > iburrell:BADURL:Path-Class-0.16.tar.gz:perl-Path-Class > orion:BADURL:PDL-Graphics-PLplot-0.51.tar.gz:perl-PDL-Graphics-PLplot > cweyl:BADURL:POE-1.269.tar.gz:perl-POE > cweyl:BADURL:POE-Component-Client-DNS-1.050.tar.gz:perl-POE-Component-Client-DNS > cweyl:BADURL:POE-Component-Client-HTTP-0.890.tar.gz:perl-POE-Component-Client-HTTP > cweyl:BADURL:POE-Test-Loops-1.022.tar.gz:perl-POE-Test-Loops > rakesh:BADURL:Search-Xapian-1.0.15.0.tar.gz:perl-Search-Xapian > lkundrak:BADURL:String-Random-0.22.tar.gz:perl-String-Random > lkundrak:BADURL:Test-WWW-Selenium-1.18.tar.gz:perl-Test-WWW-Selenium > kasal:BADURL:XML-NamespaceSupport-1.10.tar.gz:perl-XML-NamespaceSupport > kasal:BADURL:XML-Twig-3.33.tar.gz:perl-XML-Twig > steve:BADURL:YAML-0.70.tar.gz:perl-YAML > dwmw2:BADURL:libpng-1.2.16.tar.bz2:petitboot > green:BADURL:phasex-0.12.0beta4.tar.gz:phasex > robert:BADURL:idn_1.2b.tar.gz:php-idn > buc:BADURL:phpldapadmin-1.2.0.3.tgz:phpldapadmin > mmcgrath:BADURL:phpMyAdmin-3.2.2.1-all-languages.tar.bz2:phpMyAdmin > cdamian:BADURL:PhpDocumentor-1.4.3.tgz:php-pear-PhpDocumentor > orphan:BAD_CVS_SOURCE:shot1.png:pic2aa > gemi:BADSOURCE:pl-5.7.11.tar.gz:pl > gemi:BADSOURCE:SWI-Prolog-5.7.11.pdf:pl > rstrode:BADURL:plymouth-0.8.0.tar.bz2:plymouth > twaugh:BADURL:ppa-0.8.6.tar.gz:pnm2ppa > cdamian:BADSOURCE:podcatcher-3.1.5.tar.gz:podcatcher > xulchris:BAD_CVS_SOURCE:copyright:poker3d-data > dwalsh:BADURL:policycoreutils-2.0.74.tgz:policycoreutils > dwalsh:BADURL:sepolgen-1.0.17.tgz:policycoreutils > davidz:BADURL:polkit-0.95.git20090913.tar.gz:polkit > davidz:BADURL:polkit-gnome-0.95.git20090913.tar.bz2:polkit-gnome > tgl:BADURL:postgresql-8.4.1-US.pdf:postgresql > tgl:BADSOURCE:pgtcl1.6.2.tar.gz:postgresql > tgl:BADSOURCE:pgtcldocs-20070115.zip:postgresql > tgl:BADURL:psqlodbc-08.04.0100.tar.gz:postgresql-odbc > devrim:BADURL:odbcng-0.99.101.tar.gz:postgresql-odbcng > jakub:BADURL:prelink-20090925.tar.bz2:prelink > skvidal:BADURL:preupgrade-1.1.2.tar.bz2:preupgrade > hubbitus:BADURL:printoxx-1.8.1.tar.gz:printoxx > varekova:BADURL:acct-6.3.2.tar.gz:psacct > abompard:BADURL:psi-0.13.tar.bz2:psi > kanarip:BADURL:publican-genome-1.0.tgz:publican-genome > jkeating:BADURL:pungi-2.0.20.tar.bz2:pungi > abompard:BADSOURCE:pure-ftpd-1.0.22.tar.bz2:pure-ftpd > orphan:BADURL:gaim-galago-0.5.1.tar.bz2:purple-galago > bogado:BADURL:puzzles-r8596.tar.gz:puzzles > itamarjp:BADURL:pyclutter-0.9.2.tar.bz2:pyclutter > bjohnson:BADURL:pygoocanvas-0.14.0.tar.bz2:pygoocanvas > mbarnes:BADURL:pygtk-2.16.0.tar.bz2:pygtk2 > kanarip:BADURL:pyjigdo-0.4.0.1.tar.gz:pyjigdo > spot:BADURL:pyke-1.0.3.tar.gz:pyke > spot:BAD_CVS_SOURCE:RELEASE_NOTES-1.0.3:pyke > thias:BADSOURCE:pymetar-0.14.tar.gz:pymetar > slankes:BADURL:pympdtouchgui-0.309.tgz:pympdtouchgui > pfj:BADURL:pyOpenSSL-0.9.tar.gz:pyOpenSSL > mbarnes:BADURL:pyorbit-2.24.0.tar.bz2:pyorbit > orphan:BADURL:pyrenamer-0.6.0.1.tar.gz:pyrenamer > sundaram:BADSOURCE:pyroom-0.4.1.tar.gz:pyroom > kwizart:BADURL:PythonCAD-DS1-R36.tar.bz2:PythonCAD > mikeb:BADURL:Cheetah-2.2.2.tar.gz:python-cheetah > thias:BADURL:Coherence-0.6.4.tar.gz:python-Coherence > lmacken:BADURL:configobj-4.6.0.zip:python-configobj > dyoung:BADURL:Djblets-0.5rc1.tar.gz:python-djblets > toshio:BADSOURCE:python-fedora-0.3.16.tar.gz:python-fedora > jamatos:BADURL:HTMLgen.tar.gz:python-HTMLgen > mdomsch:BADURL:IPy-0.63.tar.gz:python-IPy > mikeb:BADURL:python-krbV-1.0.13.tar.gz:python-krbV > huzaifas:BADSOURCE:python-lzo-1.08.tar.gz:python-lzo > ianweller:BADSOURCE:e4adff8732c4.tar.bz2:python-mwlib > thias:BADSOURCE:Nevow-0.9.32.tar.gz:python-nevow > sergiopr:BADURL:numdisplay-1.5.4.tar.gz:python-numdisplay > sharkcz:BADURL:openoffice-python-0.1-r34-20090228.tar.bz2:python-openoffice > lmacken:BADSOURCE:PEAK-Rules-0.5a1.dev-r2582.tar.gz:python-peak-rules > itamarjp:BADURL:Scriptaculous-1.8.2.tar.gz:python-Scriptaculous > jortel:BADURL:python-suds-0.3.7.tar.gz:python-suds > thias:BADURL:tagpy-0.94.5.tar.gz:python-tag > lmacken:BADURL:TestGears-0.2.tar.gz:python-TestGears > lmacken:BADSOURCE:TurboFlot-0.1.1.tar.bz2:python-turboflot > thomasvs:BADURL:TwistedConch-8.2.0.tar.bz2:python-twisted-conch > thomasvs:BADURL:TwistedCore-8.2.0.tar.bz2:python-twisted-core > thomasvs:BADURL:TwistedLore-8.2.0.tar.bz2:python-twisted-lore > thomasvs:BADURL:TwistedMail-8.2.0.tar.bz2:python-twisted-mail > thomasvs:BADURL:TwistedNames-8.2.0.tar.bz2:python-twisted-names > thomasvs:BADURL:TwistedNews-8.2.0.tar.bz2:python-twisted-news > thomasvs:BADURL:TwistedRunner-8.2.0.tar.bz2:python-twisted-runner > thomasvs:BADURL:TwistedWeb-8.2.0.tar.bz2:python-twisted-web > thomasvs:BADURL:TwistedWords-8.2.0.tar.bz2:python-twisted-words > lmacken:BADSOURCE:tw.jquery-0.9.5.tar.gz:python-tw-jquery > fab:BADURL:upoints-0.11.0.tar.bz2:python-upoints > lmacken:BADURL:wsgiref-0.1.2.zip:python-wsgiref > jbowes:BADURL:ZSI-2.0.tar.gz:python-ZSI > jspaleta:BADURL:pytz-2008i.tar.gz:pytz > twaugh:BADSOURCE:pyusb-0.4.1.tar.gz:pyusb > spot:BADURL:pyxdg-0.17.tar.gz:pyxdg > gemi:BADURL:qcad-manual-en-2.0.4.0-1.html.zip:qcad > muerte:BADURL:qcomicbook-0.4.0.tar.gz:qcomicbook > nbecker:BADSOURCE:qct-1.7.tar.gz:qct > john5342:BADSOURCE:0206ec8f2a802bf51455179933d8b7ab3e41a38b.tar.gz:qedje > nando:BADURL:qjackctl-0.3.5.tar.gz:qjackctl > silfreed:BADSOURCE:QLandkarte_final.tar.gz:qlandkarte > stefan:BADURL:qmtest-2.4.1.tar.gz:qmtest > chitlesh:BADSOURCE:qsa-x11-free-1.1.5.tar.gz:qt-qsa > john5342:BADSOURCE:d32223eae1bba7f1b191c334668f3f7dd662f582.tar.gz:qzion > kantrn:BADSOURCE:rainbow-0.8.1.tar.bz2:rainbow > giesen:BADURL:rancid-2.3.2.tar.gz:rancid > timj:BADURL:rapidsvn-0.10.0.tar.gz:rapidsvn > jmoskovc:BADURL:rarpd-ss981107.tar.gz:rarpd > spot:BADURL:bigmemory_3.10.tar.gz:R-bigmemory > pingou:BADURL:Biostrings_2.12.9.tar.gz:R-Biostrings > orion:BADURL:car_1.2-15.tar.gz:R-car > jmoskovc:BADURL:rdate-1.4.tar.gz:rdate > jmoskovc:BAD_CVS_SOURCE:rdist-eu-license.txt:rdist > sindrepb:BADURL:recordmydesktop-0.3.8.1.tar.gz:recordmydesktop > sxw:BADURL:remctl-2.11.tar.gz:remctl > fabbione:BADSOURCE:e2338892f59f.tar.bz2:resource-agents > kanarip:BADURL:revisor-2.1.8.tar.gz:revisor > pingou:BADURL:hgu95av2probe_2.4.0.tar.gz:R-hgu95av2probe > denisarnaud:BADURL:rmol-0.23.0.tar.gz:rmol > denisarnaud:BADURL:msm_0.9.1.tar.gz:R-msm > spot:BADURL:nws_2.0.0.3.tar.gz:R-nws > than:BADURL:rp-pppoe-3.10.tar.gz:rp-pppoe > spot:BADURL:RODBC_1.3-0.tar.gz:R-RODBC > kanarip:BADURL:arrayfields-4.7.4.gem:rubygem-arrayfields > kanarip:BADSOURCE:attributes-5.0.1.gem:rubygem-attributes > lutter:BADSOURCE:gem2rpm-0.6.0.gem:rubygem-gem2rpm > kanarip:BADSOURCE:highline-1.5.0.tgz:rubygem-highline > kanarip:BADURL:main-4.0.0.gem:rubygem-main > kanarip:BADSOURCE:picnic-0.8.1.gem:rubygem-picnic > kanarip:BADURL:reststop-0.4.0.gem:rubygem-reststop > lutter:BADURL:ruby-postgres-0.7.1.tar.gz:ruby-postgres > homeless:BADSOURCE:rudecgi-5.1.0.tar.bz2:rudecgi > pbrobinson:BADURL:rygel-0.4.4.tar.bz2:rygel > pwouters:BADURL:s3ssrc.zip:s3switch > ondrejj:BADURL:sagator-1.2.0-0.beta25.tar.bz2:sagator > mbarnes:BADURL:samba-4.0.0alpha8_git20090916.tar.gz:samba4 > srini:BADURL:sblim-sfcc-2.1.0.tar.bz2:sblim-sfcc > dgoodwin:BADSOURCE:scapy-2.0.0.10.tar.gz:scapy > jcollie:BADURL:schroedinger-1.0.8.tar.gz:schroedinger > jspaleta:BADSOURCE:ScientificPython-2.8.tar.gz:ScientificPython > phuang:BADURL:scim-bridge-0.4.16.tar.gz:scim-bridge > sindrepb:BADURL:scratchpad-0.3.0.tar.bz2:scratchpad > c4chris:BADURL:seaview_4.0.tar.gz:seaview > stefansf:BADURL:sec-2.5.2.tar.gz:sec > dwalsh:BADURL:selinux-doc-1.26.tgz:selinux-doc > ixs:BADURL:ser-0.9.6_src.tar.gz:ser > lucilanga:BADSOURCE:shapelib-1.2.10.tar.gz:shapelib > jgu:BADURL:shorewall-4.4.1.tar.bz2:shorewall > ausil:BADSOURCE:silo-1.4.14.tar.bz2:silo > robert:BADSOURCE:sip-redirect-0.1.2.tar.gz:sip-redirect > orphan:BADSOURCE:SmartEiffel-2-3.tar.bz2:smarteiffel > jlaska:BADURL:snake-0.11-0.19.tar.bz2:snake > ausil:BADURL:snort-2.8.5.1.tar.gz:snort > jcollie:BADURL:sofsip-cli-0.16.tar.gz:sofsip-cli > hguemar:BADSOURCE:sonata-1.6.2.1.tar.bz2:sonata > astokes:BADSOURCE:sos-1.8.tar.gz:sos > lennart:BADURL:sound-theme-freedesktop-0.7.tar.bz2:sound-theme-freedesktop > mmahut:BADURL:spacechart-0.9.5.tar.gz:spacechart > wtogami:BADURL:Mail-SpamAssassin-3.3.0-svn816416.tar.bz2:spamassassin > kanarip:BADURL:spin-kickstarts-0.12.0.tar.gz:spin-kickstarts > abompard:BADURL:spring_0.80.4.2_src.tar.lzma:spring > abompard:BADURL:SmallDivide.sd7:spring-maps-default > abompard:BADURL:Comet_Catcher_Redux.sd7:spring-maps-default > abompard:BADURL:Sands_of_War_v2.sd7:spring-maps-default > gavin:BADURL:Squeak-3.10-5.src.tar.gz:squeak-vm > limb:BADSOURCE:blacklists.tgz:squidGuard > limb:BAD_CVS_SOURCE:squid-getlist.html:squidGuard > mhlavink:BADURL:squirrelmail-1.4.20-RC2_20090917.tar.bz2:squirrelmail > ebrand:BADSOURCE:sslogger-0.9.tar.gz:sslogger > psklenar:BADURL:stardict-english-czech-20081201.tar.gz:stardict-dic-cs_CZ > lkundrak:BADSOURCE:starlab-4.4.3.tar.gz:starlab > roland:BADURL:strace-4.5.19.tar.bz2:strace > huzaifas:BADSOURCE:stund_0.96_Aug13.tgz:stun > mso:BADURL:subtitleeditor-0.34.0.tar.gz:subtitleeditor > s4504kr:BADURL:suck-4.3.2.tar.gz:suck > mildew:BADURL:sudo-1.7.1.tar.gz:sudo > tuxbrewr:BADURL:Terminal-26.tar.bz2:sugar-terminal > limb:BADURL:supertuxkart-0.6.2-src.tar.bz2:supertuxkart > bpepple:BADURL:swfdec-gnome-2.28.0.tar.bz2:swfdec-gnome > deji:BADURL:sword-1.6.0.tar.gz:sword > itamarjp:BADURL:sylpheed-2.7.0.tar.bz2:sylpheed > awjb:BADURL:synce-sync-engine-0.14.tar.gz:synce-sync-engine > awjb:BADURL:synce-trayicon-0.14.tar.gz:synce-trayicon > silfreed:BADURL:syslog-ng-2.1.4.tar.gz:syslog-ng > nphilipp:BADURL:system-config-date-docs-1.0.8.tar.bz2:system-config-date-docs > ajax:BADSOURCE:system-config-display-2.2.tar.bz2:system-config-display > nphilipp:BADURL:system-config-nfs-1.3.49.tar.bz2:system-config-nfs > nphilipp:BADURL:system-config-nfs-docs-1.0.7.tar.bz2:system-config-nfs-docs > nphilipp:BADURL:system-config-samba-1.2.83.tar.bz2:system-config-samba > nphilipp:BADURL:system-config-samba-docs-1.0.7.tar.bz2:system-config-samba-docs > nphilipp:BADURL:system-config-services-docs-1.1.7.tar.bz2:system-config-services-docs > nphilipp:BADURL:system-config-users-1.2.94.tar.bz2:system-config-users > nphilipp:BADURL:system-config-users-docs-1.0.7.tar.bz2:system-config-users-docs > plautrba:BADURL:sysvinit-2.87dsf.tar.gz:sysvinit > jamatos:BADURL:t1lib_5.1.1-3.diff.gz:t1lib > pmachata:BADSOURCE:tbb21_20080605oss_src.tgz:tbb > bpepple:BADURL:telepathy-sofiasip-0.5.18.tar.gz:telepathy-sofiasip > errr:BADURL:tenr-de-styles-pkg-1.1.tar.bz2:tenr-de-styles-pkg > rvinyard:BADSOURCE:IEEEtran.zip:tetex-IEEEtran > mef:BADURL:tex4ht-1.0.2008_09_16_1413.tar.gz:tetex-tex4ht > jnovy:BADURL:dvipsk-jpatch-p1.7a.tar.bz2:texlive > jnovy:BADURL:platex209.tar.bz2:texlive-texmf > jnovy:BADSOURCE:envlab.tar.lzma:texlive-texmf > hman-it:BADURL:themonospot-0.7.3.1.tar.gz:themonospot > cwickert:BADURL:thunar-volman-0.3.80.tar.bz2:thunar-volman > jjh:BADURL:tinyproxy-1.6.5.tar.gz:tinyproxy > deji:BADURL:tokyocabinet-1.4.33.tar.gz:tokyocabinet > chitlesh:BADURL:toped-0.9.5.tar.bz2:toped > awjb:BADURL:treecc-0.3.8.tar.gz:treecc > ssp:BADURL:tsclient-2.0.2.tar.bz2:tsclient > lmacken:BADURL:TurboGears-1.0.8.tar.gz:TurboGears > lmacken:BADURL:TurboGears2-2.0.3.tar.gz:TurboGears2 > trasher:BADURL:tuxmath_w_fonts-1.7.2.tar.gz:tuxmath > steve:BADURL:tuxtype_w_fonts-1.7.5.tar.gz:tuxtype2 > rakesh:BADURL:txt2rss-01.tar.bz2:txt2rss > pmachata:BADURL:tzdata2009o.tar.gz:tzdata > dyfet:BADURL:ucommon-2.0.5.tar.gz:ucommon > akurtakov:BAD_CVS_SOURCE:doclet-5.1.pom:umlgraph > jussilehtola:BADURL:unetbootin-source-358.tar.gz:unetbootin > dchen:BADSOURCE:Unihan.zip:UnihanDb > varekova:BADURL:unzip552.tar.gz:unzip > kzak:BADURL:util-linux-ng-2.17-git5e51568.tar.bz2:util-linux-ng > ensc:BADURL:util-vserver-0.30.215+svn2847.tar.bz2:util-vserver > lmacken:BADURL:valknut-0.4.9-gnome-icons.tar.gz:valknut > wart:BADURL:varconf-0.6.6.tar.bz2:varconf > ajax:BADURL:vbetool-1.2.1.tar.bz2:vbetool > icon:BADSOURCE:verbiste-0.1.26.tar.gz:verbiste > dirjud:BADURL:verilator-3.712.tgz:verilator > jima:BADSOURCE:videodog0.31.tar.gz:videodog > karsten:BADSOURCE:vim-7.2.tar.bz2:vim > agoode:BADURL:vips-7.18.2.tar.gz:vips > dwayne:BADURL:virtaal-0.4.1.tar.bz2:virtaal > kzak:BADURL:vlock-1.3.tar.gz:vlock > kdudka:BADURL:vorbis-tools-1.2.0.tar.gz:vorbis-tools > behdad:BADURL:vte-0.22.2.tar.bz2:vte > athimm:BADURL:vtkdata-5.4.2.tar.gz:vtkdata > limb:BADURL:vym-1.12.4.tar.bz2:vym > tagoh:BADURL:emacs-w3m-1.4.367.tar.gz:w3m-el > mtasaka:BADURL:wallpapoz-0.4.1-svn92_trunk.tar.bz2:wallpapoz > laxathom:BADURL:wammu-0.30.1.tar.bz2:wammu > karlik:BADURL:warzone2100-2.2.1.tar.bz2:warzone2100 > karlik:BADURL:sequences.wz:warzone2100 > fab:BADSOURCE:wavemon-0.6.7.tar.bz2:wavemon > sergiopr:BADURL:wcslib-4.3.1.tar.gz:wcslib > sergiopr:BADURL:wcstools-3.7.0.tar.gz:wcstools > ruben:BADURL:whatsup-1.9.tar.gz:whatsup > edhill:BADURL:wifiroamd-1.14.tar.gz:wifiroamd > awjb:BADURL:WindowMaker-0.92.0.tar.bz2:WindowMaker > awjb:BADURL:WindowMaker-extra-0.1.tar.gz:WindowMaker > awjb:BAD_CVS_SOURCE:winepulse-0.32-configure.ac.patch:wine > awjb:BAD_CVS_SOURCE:wmweather+-2.9.tar.gz:wmweather+ > lonetwin:BADURL:WordNet-3.0.tar.bz2:wordnet > ianweller:BADSOURCE:add-to-any.0.9.9.2.3.zip:wordpress-plugin-add-to-any > ianweller:BADSOURCE:add-to-any-subscribe.0.9.6.4.1.zip:wordpress-plugin-add-to-any-subscribe > kzak:BADURL:mwords.tar.Z:words > than:BADURL:wordtrans_1.1pre13.tar.gz:wordtrans > than:BAD_CVS_SOURCE:French.txt:wordtrans > caolanm:BADURL:1.0.tar.gz:writer2latex > dchen:BADSOURCE:WritRecogn-0.1.9.tar.gz:WritRecogn > srini:BADURL:wsmancli-2.1.0.tar.bz2:wsmancli > dgoodwin:BADURL:wuja-0.0.8.tar.gz:wuja > dp67:BADSOURCE:wxapt-1.3.tar.gz:wxapt > ensc:BADURL:xca-0.7.0.tar.gz:xca > sindrepb:BADURL:xdotool-20090815.tar.gz:xdotool > xen-maint:BADURL:xen-3.4.1.tar.gz:xen > jmoskovc:BADURL:xferstats-2.16.tar.gz:xferstats > bjensen:BADSOURCE:xfhell-1.9.tar.gz:xfhell > sandeen:BADURL:xfsprogs-3.0.3.tar.gz:xfsprogs > limb:BADURL:xgalaga_2.0.34-44.diff.gz:xgalaxy > dwalsh:BADURL:xguest-1.0.7.tar.bz2:xguest > spot:BAD_CVS_SOURCE:xmbdfed.png:xmbdfed > ovasik:BADURL:xmltex-1.9.tar.gz:xmltex > pcheung:BAD_CVS_SOURCE:xmlunit-1.0.pom:xmlunit > rathann:BADURL:xmp-2.7.1-free.tar.gz:xmp > bjensen:BADSOURCE:xnec2c-1.2.tar.gz:xnec2c > terjeros:BAD_CVS_SOURCE:XOsview.png:xosview > cassmodiah:BADURL:xpad-4.0.tar.bz2:xpad > oget:BADURL:xsynth-dssi-0.9.2.tar.gz:xsynth-dssi > dp67:BADSOURCE:xwxapt-1.2.tar.gz:xwxapt > jnovy:BADURL:xz-4.999.9beta.20091007git.tar.xz:xz > dwmw2:BADSOURCE:yaboot-1.3.14.tar.gz:yaboot > rakesh:BADURL:yum-plugin-download-order-0.2.tar.gz:yum-plugin-download-order > varekova:BADURL:zip231.tar.gz:zip > varekova:BADURL:zcrypt29.tar.gz:zip > varekova:BADURL:zlib-1.2.3.tar.bz2:zlib > green:BADURL:ZynAddSubFX-2.4.0.tar.bz2:zynaddsubfx > thias:BADURL:zziplib-0.13.49.tar.bz2:zziplib > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Nicolas Mailhot From nicolas.mailhot at laposte.net Thu Nov 5 22:28:14 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 5 Nov 2009 23:28:14 +0100 Subject: source file audit - 2009-11-01 In-Reply-To: <20091104171816.0ef2c0a5@ohm.scrye.com> References: <20091104171816.0ef2c0a5@ohm.scrye.com> Message-ID: [sorry about the dud message] Le Jeu 5 novembre 2009 01:18, Kevin Fenzi a ?crit : Thanks a lot for the checks, I wouldn't detect some upstream updates without you, please run the checker more often (if only FEver did this) > nim:BADSOURCE:Tribun-Std.zip:adf-tribun-fonts > nim:BADSOURCE:GFS_DECKER.zip:gfs-decker-fonts > nim:BADSOURCE:GFS_GAZIS.zip:gfs-gazis-fonts > nim:BADSOURCE:GFS_NEOHELLENIC_OT.zip:gfs-neohellenic-fonts > nim:BADSOURCE:GFS_PYRSOS.zip:gfs-pyrsos-fonts Various upstream stealth updates, all integrated in devel. > nim:BAD_CVS_SOURCE:NOTICE:google-droid-fonts Can't reproduce this one -- Nicolas Mailhot From guido.grazioli at gmail.com Thu Nov 5 22:56:50 2009 From: guido.grazioli at gmail.com (Guido Grazioli) Date: Thu, 5 Nov 2009 23:56:50 +0100 Subject: Fedora Moblin remix In-Reply-To: <5256d0b0911051001i5a6d7429u2fd2c965685e40f0@mail.gmail.com> References: <5256d0b0911051001i5a6d7429u2fd2c965685e40f0@mail.gmail.com> Message-ID: <2f984ea00911051456r3f642349q3c059178c456cbf5@mail.gmail.com> 2009/11/5 Peter Robinson : > Hi All, > > For those interested there's a new test LiveCD of Fedora Moblin remix > [1] for those that are interesting in playing. It would be nice to > have some feedback on good or bad issues with it. There's been almost > 1300 downloads since I announced the last one but I've had no feedback > what so ever and while I'd like to assume that's because its perfect I > doubt that is the case. > * I booted it for the first time some minutes ago on an Asus eeepc 900 (no atom, just a celeron). I actually never installed "vanilla" moblin because in their site atom is a requirement. * Boot is somewhat slow but it could depend on my crappy usb key, or because netbooks are crap themselves; after gdm login, the graphics go unexpectedly *FAST* and *SMOOTH* ! * Just before graphical boot screen, for some seconds i can see: -- render error detected, EIR: 0x00000010 page table error PGTBL_ER: 0x00000100 [drm:i915_handle_error] *ERROR* EIR stuck: 0x0000010, masking render error detected, EIR: 0x00000010 page table error PGTBL_ER: 0x00000100 -- however, everything seems to run just right after that. * Where's wifi configuration? isn't there a graphical tool to configure it? asking my gf to get it up on a shell is a no-no. * I mounted a touchscreen in my eeepc, and moblin gui looks much more friendly to that interface. However i couldnt install the manufacturer software (eGalax), because i think an autoloaded module interferes with it (generic-usb?). On F11 nothing get autoloaded and touchscreen works fine. I need some more testing to figure this out. Kudos to you: that's a *very* promising work! guido -- Guido Grazioli Via Parri 11 48011 - Alfonsine (RA) Mobile: +39 347 1017202 (10-18) Key FP = 7040 F398 0DED A737 7337 DAE1 12DC A698 5E81 2278 Linked in: http://www.linkedin.com/in/guidograzioli From pbrobinson at gmail.com Thu Nov 5 23:36:59 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 5 Nov 2009 23:36:59 +0000 Subject: Fedora Moblin remix In-Reply-To: <2f984ea00911051456r3f642349q3c059178c456cbf5@mail.gmail.com> References: <5256d0b0911051001i5a6d7429u2fd2c965685e40f0@mail.gmail.com> <2f984ea00911051456r3f642349q3c059178c456cbf5@mail.gmail.com> Message-ID: <5256d0b0911051536s3065dbcdsb803533dc48ee2d2@mail.gmail.com> On Thu, Nov 5, 2009 at 10:56 PM, Guido Grazioli wrote: > 2009/11/5 Peter Robinson : >> Hi All, >> >> For those interested there's a new test LiveCD of Fedora Moblin remix >> [1] for those that are interesting in playing. It would be nice to >> have some feedback on good or bad issues with it. There's been almost >> 1300 downloads since I announced the last one but I've had no feedback >> what so ever and while I'd like to assume that's because its perfect I >> doubt that is the case. >> > > * I booted it for the first time some minutes ago on an Asus eeepc 900 > (no atom, just a celeron). I actually never installed "vanilla" moblin > because in their site atom is a requirement. > > * Boot is somewhat slow but it could depend on my crappy usb key, or > because netbooks are crap themselves; after > gdm login, the graphics go unexpectedly *FAST* and *SMOOTH* ! Cool, I need to look closer at the boot to see what can improved. I'm been too busy for my own good of late so haven't had a chance to look closely at this bit. > * Just before graphical boot screen, for some seconds i can see: > -- > render error detected, EIR: 0x00000010 > page table error > ?PGTBL_ER: 0x00000100 > [drm:i915_handle_error] *ERROR* EIR stuck: 0x0000010, masking > render error detected, EIR: 0x00000010 > page table error > ?PGTBL_ER: 0x00000100 > -- > however, everything seems to run just right after that. Is it recorded in dmesg. It might be worth reporting a bug with all the details. > * Where's wifi configuration? isn't there a graphical tool > to configure it? asking my gf to get it up on a shell is a no-no. It should be in the top right corner of the top panel. Just to the left of the volume control. From memory the eeePC 900 has an atheros card so it should work OK. > * I mounted a touchscreen in my eeepc, and moblin gui looks > much more friendly to that interface. However i couldnt install > the manufacturer software (eGalax), because i think > an autoloaded module interferes with it (generic-usb?). > On F11 nothing get autoloaded and touchscreen works fine. > I need some more testing to figure this out. Do they have an open driver? Maybe its supported in F-12 and I just need to make sure the right package is included to support it. Thanks for the report. Cheers, Peter From jonstanley at gmail.com Fri Nov 6 02:35:53 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 5 Nov 2009 21:35:53 -0500 Subject: Plan for tomorrow's (20091106) FESCo meeting Message-ID: The following topic is on the agenda for tomorrow's FESCo meeting, taking place in #fedora-meeting at 17:00UTC (NOTE: this is now NOON eastern, not 1PM as before). 266 Need to decide on F10 EOL date For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor. From thuforuk at yahoo.co.uk Fri Nov 6 02:41:34 2009 From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski) Date: Thu, 05 Nov 2009 19:41:34 -0700 Subject: Curious changelog entry Message-ID: <4AF38CDE.90403@yahoo.co.uk> Changelog from today's geoclue-0.11.1.1-0.9.1.20091026git73b6729.fc11 update: ------ **2009-10-24** Peter Robinson 0.11.1.1-0.9 - New git snapshit, enable NetworkManager support for WiFi location, gsmloc and new Skyhook plugin ------ "snapshit", eh? :p From liangsuilong at gmail.com Fri Nov 6 04:49:17 2009 From: liangsuilong at gmail.com (Liang Suilong) Date: Fri, 6 Nov 2009 12:49:17 +0800 Subject: Fedora 12 now in RC freeze Message-ID: > > We are reaching a *very* deep freeze now as we try and get a final release candidate for Fedora 12. Bodhi is now open for submitting F-12 updates, and we hope to have update repositories for testing later this weekend. If you have critical blocking issues, you can continue to file tag requests with 'make tag-request', and they will be considered. For the majority of updates, though, please use bodhi. Thanks, Fedora release engineering Fedora 12 looks very well. But it seems that some components of GNOME has been removed or disappeared. For example, system-config-selinux disappears. I can not find it in the retired packages list. Is it merged into another package? I read some documents about gnome-2.28 on Fedora wiki. There should be a tab named as "Interface tab and enable" in the System->Preferences->Appearance. As a matter of fact. It is used to enable the icons for the buttons. However, no one find out it. Another things, I still consider the 'Main Menu' preference dialog should be reserved. I believe that many guys will customize their Gnome menu. As so many users will use it, Why remove alacarte by default? 'Show Desktop' applet in the gnome panel is the same with 'Main Menu'. I request to add them by default. Liang Suilong -- http://www.liangsuilong.info Fight for freedom!!!!(3F? Ask not what your Linux distro can do for you! Ask what you can do for your Linux distro! -------------- next part -------------- An HTML attachment was scrubbed... URL: From awilliam at redhat.com Fri Nov 6 05:27:10 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 05 Nov 2009 21:27:10 -0800 Subject: Fedora 12 vs. Ubuntu 9.10 Benchmarks ?!? In-Reply-To: References: Message-ID: <1257485230.2377.8.camel@adam.local.net> On Thu, 2009-11-05 at 14:24 +0000, Valent Turkovic wrote: > http://is.gd/4NU9N > > Phoronix published Fedora 12 vs. Ubuntu 9.10 Benchmarks > > They claim they took Fedora 12 candidate release, but AFAIK there is no > Fedora 12 RC, right? > > If they used Fedora 12 Beta are these number comparable with real Fedora > 12 performance numbers when Fedora 12 ships? Aren't there some debugging > features turned on in Rawhide (Fedora 12 beta) kernel? Are other packages > in Fedora 12 also suffering from some speed penalty? > > Still Fedora 12 Beta ate Ubuntu for breakfast :) > > Fedora 12 performed on most test better than Ubuntu, nice work guys/ > galls :) There's no way to know what they tested. It was not an RC, we did not have an RC until about 10 minutes ago. Yesterday's full compose was a TC (test compose). What they tested was one of the nightlies from http://alt.fedoraproject.org/pub/alt/nightly-composes/ , but we can't tell which because they didn't give a date. The NVIDIA driver benchmark is just weird, but not something we'd care much about anyway. All the others look within the range of meaning very little, to me. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From mmaslano at redhat.com Fri Nov 6 06:59:52 2009 From: mmaslano at redhat.com (Marcela Maslanova) Date: Fri, 6 Nov 2009 01:59:52 -0500 (EST) Subject: cron no longer working in F-12 In-Reply-To: <4AF3495F.5080001@cora.nwra.com> Message-ID: <1150362265.977831257490792468.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> ----- "Orion Poplawski" wrote: > On 11/05/2009 02:49 PM, Orion Poplawski wrote: > > I'm seeing the following in my /var/log/cron files on my 3 F-12 > machines: > > > > Nov 5 14:10:01 orca crond[6287]: (root) FAILED to open PAM security > > session (Failure setting user credentials) > > > > and jobs aren't running. Anyone else seeing this? > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=533289 > > > > Ah, already reported as 533189 and fix building. Should get tagged > for > F-12. > > -- > 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 Fixed in rawhide and tagged into F-12. From josephine.tannhauser at googlemail.com Fri Nov 6 07:20:38 2009 From: josephine.tannhauser at googlemail.com (=?UTF-8?Q?Josephine_Tannh=C3=A4user?=) Date: Fri, 6 Nov 2009 08:20:38 +0100 Subject: Fedora Moblin remix In-Reply-To: <5256d0b0911051536s3065dbcdsb803533dc48ee2d2@mail.gmail.com> References: <5256d0b0911051001i5a6d7429u2fd2c965685e40f0@mail.gmail.com> <2f984ea00911051456r3f642349q3c059178c456cbf5@mail.gmail.com> <5256d0b0911051536s3065dbcdsb803533dc48ee2d2@mail.gmail.com> Message-ID: <3668e9f50911052320v440f4b50i6ebe1ab507418ed5@mail.gmail.com> Hi all, Moblin is afaik Intel processors only. Would this work because of the fedora fundament on other processors like a via with 733mhz, too? 2009/11/6, Peter Robinson : > On Thu, Nov 5, 2009 at 10:56 PM, Guido Grazioli > wrote: >> 2009/11/5 Peter Robinson : >>> Hi All, >>> >>> For those interested there's a new test LiveCD of Fedora Moblin remix >>> [1] for those that are interesting in playing. It would be nice to >>> have some feedback on good or bad issues with it. There's been almost >>> 1300 downloads since I announced the last one but I've had no feedback >>> what so ever and while I'd like to assume that's because its perfect I >>> doubt that is the case. >>> >> >> * I booted it for the first time some minutes ago on an Asus eeepc 900 >> (no atom, just a celeron). I actually never installed "vanilla" moblin >> because in their site atom is a requirement. >> >> * Boot is somewhat slow but it could depend on my crappy usb key, or >> because netbooks are crap themselves; after >> gdm login, the graphics go unexpectedly *FAST* and *SMOOTH* ! > > Cool, I need to look closer at the boot to see what can improved. I'm > been too busy for my own good of late so haven't had a chance to look > closely at this bit. > >> * Just before graphical boot screen, for some seconds i can see: >> -- >> render error detected, EIR: 0x00000010 >> page table error >> ?PGTBL_ER: 0x00000100 >> [drm:i915_handle_error] *ERROR* EIR stuck: 0x0000010, masking >> render error detected, EIR: 0x00000010 >> page table error >> ?PGTBL_ER: 0x00000100 >> -- >> however, everything seems to run just right after that. > > Is it recorded in dmesg. It might be worth reporting a bug with all > the details. > >> * Where's wifi configuration? isn't there a graphical tool >> to configure it? asking my gf to get it up on a shell is a no-no. > > It should be in the top right corner of the top panel. Just to the > left of the volume control. From memory the eeePC 900 has an atheros > card so it should work OK. > >> * I mounted a touchscreen in my eeepc, and moblin gui looks >> much more friendly to that interface. However i couldnt install >> the manufacturer software (eGalax), because i think >> an autoloaded module interferes with it (generic-usb?). >> On F11 nothing get autoloaded and touchscreen works fine. >> I need some more testing to figure this out. > > Do they have an open driver? Maybe its supported in F-12 and I just > need to make sure the right package is included to support it. > > Thanks for the report. > > Cheers, > Peter > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Josephine "Fine" Tannh?user 2.6.18-164.2.1.el5 2.6.30.9-90.fc11.i586 From rjones at redhat.com Fri Nov 6 08:18:21 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 6 Nov 2009 08:18:21 +0000 Subject: Including windows-binary files for cross compiling into package In-Reply-To: <1257435850.26257.36.camel@wsjoost.cnoc.lan> References: <1256579896.23821.186.camel@wsjoost.cnoc.lan> <20091026181502.919B02747@magilla.sf.frob.com> <1256582576.23821.193.camel@wsjoost.cnoc.lan> <20091103125606.GA15146@amd.home.annexia.org> <1257424975.26257.18.camel@wsjoost.cnoc.lan> <20091105140609.GA3460@amd.home.annexia.org> <1257435850.26257.36.camel@wsjoost.cnoc.lan> Message-ID: <20091106081711.GA9092@amd.home.annexia.org> On Thu, Nov 05, 2009 at 04:44:10PM +0100, Joost van der Sluis wrote: > On Thu, 2009-11-05 at 14:06 +0000, Richard W.M. Jones wrote: > > On Thu, Nov 05, 2009 at 01:42:55PM +0100, Joost van der Sluis wrote: > > > A little bit? Did you read my other mail on the subject: > > > > > > "That's an idea, but then we would be incompatible with upstream. I can > > > try to patch the configuration files of fpc so that it searches for > > > these binaries in /usr/x86_64-pc-fpc/sys-root/fpc/lib. But I prefer the > > > 'standard' location. Also because other packages based in fpc relay on > > > that. > > > > This is based on a misunderstanding of the packaging guidelines. > > > > The Fedora MinGW cross-compiler itself does not live in > > /usr/i686-pc-mingw32, it lives in the usual places like /usr/bin and > > /usr/lib (it's a native Fedora executable, so obviously this is where > > it should go). > > $ which i686-pc-mingw32-gcc > > /usr/bin/i686-pc-mingw32-gcc > > $ ls /usr/lib64/gcc/i686-pc-mingw32/4.3.2/ > > crtbegin.o include-fixed libssp.a libstdc++.a > > crtend.o install-tools libssp.la libstdc++.la > > crtfastmath.o libgcc.a libssp_nonshared.a libsupc++.a > > include libgcov.a libssp_nonshared.la libsupc++.la > > Yes, I understood that, but the object files in windows-format should be > in /usr/i686-pc-fpc/sys-root/fpc/lib, right? Not necessarily. i686-pc-mingw32-gcc keeps its own internal object files (libgcc.a etc) under /usr/lib{,64} also. > That's what I meant. If you are actually on windows, MinGW needs a > directory-structure with paths like 'lib', 'bin' etc. But fpc doesn't > need that. Well, the application should be in 'program files', but I > doubt that that's what we want in a Fedora-package. It's nothing to do with what Windows needs. The directory is used because the upstream gcc/mingw toolchain requires it. The sys-root directory is neither used by, nor exported to Windows (in fact, Windows is not involved at any point in the process). > > You should use a prefix so that autoconf knows how to find your > > cross-compiler. Read the documentation for AC_CHECK_TOOL. > > Autoconf? With Pascal? What's next, using 'make'? ;) > > You don't need those tools with Pascal, there's no need for makefiles > because of the unit-system. Well OCaml has an integrated build system but still uses autotools, so it's not such a surprising thing. Using autotools has other advantages - it's not merely a fancy version of 'make'. What happens if a project isn't written entirely in Pascal? What happens if you need to detect if the Pascal compiler is installed? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 opensource at till.name Fri Nov 6 08:39:59 2009 From: opensource at till.name (Till Maas) Date: Fri, 06 Nov 2009 09:39:59 +0100 Subject: source file audit - 2009-11-01 In-Reply-To: <200911052133.48629.ville.skytta@iki.fi> References: <20091104171816.0ef2c0a5@ohm.scrye.com> <20091105110944.236d9d07@ohm.scrye.com> <200911052133.48629.ville.skytta@iki.fi> Message-ID: <20091106083959.GA4554@genius.kawo2.rwth-aachen.de> On Thu, Nov 05, 2009 at 09:33:48PM +0200, Ville Skytt? wrote: > On Thursday 05 November 2009, Jason L Tibbitts III wrote: > > >>>>> "KF" == Kevin Fenzi writes: > > > > KF> Well, the script I am running uses 'spectool -g' and indeed, it > > KF> doesn't handle self signed certs: > > > > Honestly, I find it easier to just hack spectool rather than reject > > valid URLs that just happen to use self-signed certificates. You might > > also be able to tweak /etc/fedora/wgetrc to achieve the same thing. > > Unless there are objections, I'll make spectool use wget --no-check- > certificate in the next rpmdevtools release (internally, because shipping a > /etc/fedora/wgetrc would be a backwards incompatible change that could break > stuff). Please make it also an paramater, e.g. only spectool -g --no-check-certificate foo.spec will disable the certificate checking. In case upstream provides a https URL with a well known CA, it should be easily for packagers to use it to update their package. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From mcepl at redhat.com Fri Nov 6 08:43:03 2009 From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=) Date: Fri, 06 Nov 2009 09:43:03 +0100 Subject: Fedora 12 now in RC freeze In-Reply-To: References: Message-ID: Dne 6.11.2009 05:49, Liang Suilong napsal(a): > For example, system-config-selinux disappears. I can not find it in the > retired packages list. Is it merged into another package? yum whatprovides /usr/bin/system-config-selinux -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC If Patrick Henry thought that taxation without representation was bad, he should see how bad it is with representation. From pbrobinson at gmail.com Fri Nov 6 09:18:19 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 6 Nov 2009 09:18:19 +0000 Subject: Fedora Moblin remix In-Reply-To: <3668e9f50911052320v440f4b50i6ebe1ab507418ed5@mail.gmail.com> References: <5256d0b0911051001i5a6d7429u2fd2c965685e40f0@mail.gmail.com> <2f984ea00911051456r3f642349q3c059178c456cbf5@mail.gmail.com> <5256d0b0911051536s3065dbcdsb803533dc48ee2d2@mail.gmail.com> <3668e9f50911052320v440f4b50i6ebe1ab507418ed5@mail.gmail.com> Message-ID: <5256d0b0911060118y58f21b33qacc0f00f93cbb262@mail.gmail.com> On Fri, Nov 6, 2009 at 7:20 AM, Josephine Tannh?user wrote: > Hi all, > > Moblin is afaik Intel processors only. Would this work because of the > fedora fundament on other processors like a via with 733mhz, too? Intel's version of Moblin is optimised for Intel processors only. Fedora's version of moblin should work on on all CPUs but the interface makes a lot of use of opengl through clutter so it will be dependant on your video card so you milage may vary. Peter From stefan at seekline.net Fri Nov 6 09:23:35 2009 From: stefan at seekline.net (Stefan Schulze Frielinghaus) Date: Fri, 06 Nov 2009 10:23:35 +0100 Subject: source file audit - 2009-11-01 In-Reply-To: <20091104171816.0ef2c0a5@ohm.scrye.com> References: <20091104171816.0ef2c0a5@ohm.scrye.com> Message-ID: <1257499415.2424.4.camel@localhost> On Wed, 2009-11-04 at 17:18 -0700, Kevin Fenzi wrote: [...] > stefansf:BADURL:sec-2.5.2.tar.gz:sec Fixed in CVS. Thanks for letting me know. Just an idea. Wouldn't it be useful to have such a feature in rpmlint, too? Maybe not enabled as default but as an option. From guhvies at gmail.com Fri Nov 6 09:40:56 2009 From: guhvies at gmail.com (ne...) Date: Fri, 6 Nov 2009 09:40:56 +0000 Subject: Fedora 12 vs. Ubuntu 9.10 Benchmarks ?!? In-Reply-To: References: Message-ID: On Thu, Nov 5, 2009 at 14:24, Valent Turkovic wrote: > http://is.gd/4NU9N > > Phoronix published Fedora 12 vs. Ubuntu 9.10 Benchmarks > [snip] > > Fedora 12 performed on most test better than Ubuntu, nice work guys/ > galls :) Well, I just did a tally of the results on the link you posted and Ubuntu, believe it or not, bested Fedora by a score of 9 to 5. ne... -- Registered Linux User # 125653 (http://counter.li.org) Now accepting personal mail for GMail invites. Jonathan Swift - "May you live every day of your life." - http://www.brainyquote.com/quotes/authors/j/jonathan_swift.html From dan at danny.cz Fri Nov 6 09:57:22 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Fri, 06 Nov 2009 10:57:22 +0100 Subject: Broken dependencies with Fedora 11 updates-testing - 2009-11-06 In-Reply-To: <20091106094933.7362.54091@faldor.intranet> References: <20091106094933.7362.54091@faldor.intranet> Message-ID: <1257501442.3786.32.camel@eagle.danny.cz> Michael Schwendt p??e v P? 06. 11. 2009 v 09:49 +0000: > The following packages in the repository suffer from broken dependencies: > > ====================================================================== > The results in this summary consider Test Updates! > ====================================================================== > > package: qlandkartegt-0.16.0-1.fc11.i586 from fedora-updates-testing-11-i386 > unresolved deps: > libQMKToolBox.so > libSerialPort.so > > package: qlandkartegt-0.16.0-1.fc11.ppc from fedora-updates-testing-11-ppc > unresolved deps: > libQMKToolBox.so > libSerialPort.so > > package: qlandkartegt-0.16.0-1.fc11.ppc64 from fedora-updates-testing-11-ppc64 > unresolved deps: > libQMKToolBox.so()(64bit) > libSerialPort.so()(64bit) > > package: qlandkartegt-0.16.0-1.fc11.x86_64 from fedora-updates-testing-11-x86_64 > unresolved deps: > libQMKToolBox.so()(64bit) > libSerialPort.so()(64bit) Can someone help me to find out where these libraries are coming from? My "repoqueries" were unsuccessful. The qlandkartegt build is http://koji.fedoraproject.org/koji/buildinfo?buildID=138829 Thanks Dan From mschwendt at gmail.com Fri Nov 6 10:53:42 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 6 Nov 2009 11:53:42 +0100 Subject: Broken dependencies with Fedora 11 updates-testing - 2009-11-06 In-Reply-To: <1257501442.3786.32.camel@eagle.danny.cz> References: <20091106094933.7362.54091@faldor.intranet> <1257501442.3786.32.camel@eagle.danny.cz> Message-ID: <20091106115342.401b83bc@faldor.intranet> On Fri, 06 Nov 2009 10:57:22 +0100, Dan wrote: > > package: qlandkartegt-0.16.0-1.fc11.i586 from fedora-updates-testing-11-i386 > > unresolved deps: > > libQMKToolBox.so > > libSerialPort.so > Can someone help me to find out where these libraries are coming from? > My "repoqueries" were unsuccessful. > > The qlandkartegt build is > http://koji.fedoraproject.org/koji/buildinfo?buildID=138829 First thought: Since the build depends on these libraries, they must be available in the koji buildroot. That means, either a repoquery must find them or it's just a pkg with a buildroot override tag that provides these libs. A quick look at the qlandkartegt src.rpm shows that they are built within it, though. From dan at danny.cz Fri Nov 6 11:08:15 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Fri, 06 Nov 2009 12:08:15 +0100 Subject: Broken dependencies with Fedora 11 updates-testing - 2009-11-06 In-Reply-To: <20091106115342.401b83bc@faldor.intranet> References: <20091106094933.7362.54091@faldor.intranet> <1257501442.3786.32.camel@eagle.danny.cz> <20091106115342.401b83bc@faldor.intranet> Message-ID: <1257505695.3786.40.camel@eagle.danny.cz> Michael Schwendt p??e v P? 06. 11. 2009 v 11:53 +0100: > On Fri, 06 Nov 2009 10:57:22 +0100, Dan wrote: > > > > package: qlandkartegt-0.16.0-1.fc11.i586 from fedora-updates-testing-11-i386 > > > unresolved deps: > > > libQMKToolBox.so > > > libSerialPort.so > > > Can someone help me to find out where these libraries are coming from? > > My "repoqueries" were unsuccessful. > > > > The qlandkartegt build is > > http://koji.fedoraproject.org/koji/buildinfo?buildID=138829 > > First thought: Since the build depends on these libraries, they must be > available in the koji buildroot. That means, either a repoquery must find > them or it's just a pkg with a buildroot override tag that provides these > libs. > > A quick look at the qlandkartegt src.rpm shows that they are built within > it, though. Thanks, I was looking anywhere else but forgot to look at the sources. Dan From rawhide at fedoraproject.org Fri Nov 6 13:21:27 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Fri, 6 Nov 2009 13:21:27 +0000 Subject: rawhide report: 20091106 changes Message-ID: <20091106132127.GA11846@releng2.fedora.phx.redhat.com> Compose started at Fri Nov 6 08:15:09 UTC 2009 Broken deps for i386 ---------------------------------------------------------- gnome-python2-gdl-2.25.3-12.fc12.i686 requires libgdl-1.so.2 lynx-2.8.6-22.fc12.i686 requires indexhtml Broken deps for x86_64 ---------------------------------------------------------- gnome-python2-gdl-2.25.3-12.fc12.x86_64 requires libgdl-1.so.2()(64bit) lynx-2.8.6-22.fc12.x86_64 requires indexhtml Broken deps for ppc ---------------------------------------------------------- gnome-python2-gdl-2.25.3-12.fc12.ppc requires libgdl-1.so.2 lynx-2.8.6-22.fc12.ppc requires indexhtml Broken deps for ppc64 ---------------------------------------------------------- gnome-python2-gdl-2.25.3-12.fc12.ppc64 requires libgdl-1.so.2()(64bit) lynx-2.8.6-22.fc12.ppc64 requires indexhtml Updated Packages: anaconda-12.45-1.fc12 --------------------- * Thu Nov 05 2009 David Cantrell - 12.45-1 - Set BETANAG to 0, we're nearing the actual release. (dcantrell) anjuta-2.28.1.0-2.fc12 ---------------------- * Thu Nov 05 2009 Debarshi Ray - 1:2.28.1.0-2 - Bumped to consume new libgdl soname. asterisk-1.6.1.9-1.fc12 ----------------------- * Wed Nov 04 2009 Jeffrey C. Ollie - 1.6.1.9-1 - Update to 1.6.1.9 to fix AST-2009-009/CVE-2008-7220 and AST-2009-008 - Fix obsoletes for firmware subpackage cronie-1.4.3-2.fc12 ------------------- * Thu Nov 05 2009 Marcela Ma?l??ov? - 1.4.3-2 - 533189 pam needs add a line and selinux needs defined one function fedora-release-notes-12.0.0-4.fc12 ---------------------------------- * Mon Nov 02 2009 John J. McDonough - 12.0.0-1 - Fedora 12 notes - Compared to Fedora 11, many documents and formats omitted - Only xml provided and then only for f-r-n and about-fedora. * Mon Nov 02 2009 John J. McDonough - 12.0.0-2 - Touch up .omf files for about-fedora * Mon Nov 02 2009 John J. McDonough - 12.0.0-3 - requires publican publican-fedora * Mon Nov 02 2009 John J. McDonough - 12.0.0-4 - Eliminate publican during the build dure to 0.44 => 1.0 probs glibc-2.11-2 ------------ * Thu Nov 05 2009 Andreas Schwab - 2.11-2 - Fix readahead on powerpc32. - Fix R_PPC64_{JMP_IREL,IRELATIVE} handling. - Fix preadv, pwritev and fallocate for -D_FILE_OFFSET_BITS=64 (#533063). gtk-gnutella-0.96.6-3.fc12 -------------------------- * Thu Nov 05 2009 Bill Nottingham - 0.96.6-3 - Rebuild against new glibc headers (#533063) gtranslator-1.9.6-2.fc12 ------------------------ * Thu Nov 05 2009 Bill Nottingham - 1.9.6-2 - Rebuild against newer libgdl kernel-2.6.31.5-122.fc12 ------------------------ * Thu Nov 05 2009 Ben Skeggs - nouveau: fix rh#532924 * Thu Nov 05 2009 Kyle McMartin - Add two patches from Soren from mingo/linux-2.6-x86.git to fix debug_kmap_atomic prints. * Thu Nov 05 2009 Dave Airlie 2.6.31.5-121 - drm-radeon-fix-agp-resume.patch (#531825) * Thu Nov 05 2009 Dave Airlie 2.6.31.5-122 - comment out kmap atomic for now, it breaks ppc build metacity-2.28.0-9.fc12 ---------------------- * Thu Nov 05 2009 Ray Strode 2.28.0-7 - Don't do bad things on sigterm * Thu Nov 05 2009 Ray Strode 2.28.0-8 - Minor clean ups to last patch based on feedback from Owen * Thu Nov 05 2009 Ray Strode 2.28.0-9 - One stab at the metacity patch mock-0.9.19-1.fc12 ------------------ * Thu Nov 05 2009 Jesse Keating - 0.9.18-1 - Update for Fedora 12 and 13 configs - Patch from dgilmore to clean up epel configs - Update configs for new koji static-repo locations - Don't automatically update the chroot in a --no-clean scenario * Thu Nov 05 2009 Jesse Keating - 0.9.19-1 - Fix target arch for i386 on 12 and rawhide pyzor-0.5.0-3.fc12 ------------------ * Thu Nov 05 2009 Warren Togami - 0.5.0-3 - -Wignore::DeprecationWarning to make it work (#531653) solang-0.3-2.fc12 ----------------- * Thu Nov 05 2009 Bill Nottingham - 0.3-2 - Rebuild against newer libgdl tangogps-0.9.9-1.fc12 --------------------- * Thu Nov 05 2009 Peter Robinson 0.9.9-1 - New upstream 0.9.9 release xforms-1.0.92-2.sp2.fc12 ------------------------ * Thu Nov 05 2009 Rex Dieter - 1.0.92-2.sp2 - xforms-1.9.92sp2 xfsprogs-3.0.3-2.fc12 --------------------- * Thu Nov 05 2009 Eric Sandeen 3.0.3-2 - Rebuild for glibc bug (#533063) xorg-x11-server-1.7.1-7.fc12 ---------------------------- * Fri Nov 06 2009 Dave Airlie 1.7.1-7 - xserver-1.7.1-multilib.patch: remove the miClearDrawable (fingers crossed) (#533236) - xserver-1.7.1-gamma-kdm-fix.patch: fix KDM vt gamma (#533217) Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 17 From benny+usenet at amorsen.dk Fri Nov 6 13:40:21 2009 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Fri, 06 Nov 2009 14:40:21 +0100 Subject: RPM dependency on cron Message-ID: We have a lot of virtualized (OpenVZ) Fedora servers. Until now I have avoided running cron inside each server; log rotation is done from the host. This has worked rather well until lately. Unfortunately rpm has acquired a dependency on crontabs, because it adds a file to /etc/cron.daily. In turn, crontabs depends on /etc/cron.d, which is provided by cronie. cronie explicitly depends on anacron. And thus, anacron and cronie are required for all Fedora installations. The really nasty thing is that cronie turns itself on when installed! I suddenly had an extra logrotate running which rotated logs in a way not consistent with our policy. I'm not sure where it's easiest to cut this chain. I'd be tempted to make crontabs provide /etc/cron.d and make cronie depend on crontabs. That way rpm would pull in crontabs but nothing more. /Benny From jimhayward at embarqmail.com Fri Nov 6 14:04:54 2009 From: jimhayward at embarqmail.com (Jim Hayward) Date: Fri, 06 Nov 2009 06:04:54 -0800 Subject: Current libgdl induced mess In-Reply-To: <3170f42f0911050539w311b74b8hade46a117c7c7e0e@mail.gmail.com> References: <3170f42f0911050539w311b74b8hade46a117c7c7e0e@mail.gmail.com> Message-ID: <1257516294.1885.22.camel@garfield> On Thu, 2009-11-05 at 15:39 +0200, Debarshi Ray wrote: > Actually I had requested a freeze override for Anjuta and libgdl [1] > causing the mess. Actually the changes between 2.27.92 to 2.28.0 > included the addition of an extra enum value to GdlSwitcherStyle and I > did not expect this to cause a bump in the soname. But it was bumped > and I failed to notice it. My mistake. > In case you were unaware libgdl is broken with the client-side windows in GTK 2.18. I filed an upstream bug report about the issue. I assume the libgdl developers released 2.28 to go along with the release of Gnome 2.28. However they apparently didn't test their code with GTK 2.18. You can reproduce the problem by rearranging/closing/opening the apps docked windows. https://bugzilla.gnome.org/show_bug.cgi?id=597417 Regards, Jim H From sgrubb at redhat.com Fri Nov 6 14:32:28 2009 From: sgrubb at redhat.com (Steve Grubb) Date: Fri, 6 Nov 2009 09:32:28 -0500 Subject: Fedora 12 now in RC freeze In-Reply-To: <20091105164036.GA15062@nostromo.devel.redhat.com> References: <20091105164036.GA15062@nostromo.devel.redhat.com> Message-ID: <200911060932.28774.sgrubb@redhat.com> On Thursday 05 November 2009 11:40:36 am Bill Nottingham wrote: > We are reaching a *very* deep freeze now as we try and get a final > release candidate for Fedora 12. Bodhi is now open for submitting > F-12 updates, and we hope to have update repositories for testing > later this weekend. > > If you have critical blocking issues, you can continue to file > tag requests with 'make tag-request', and they will be considered. > For the majority of updates, though, please use bodhi. Is something not setup right with cvs? In a F-12 branch when I do "make build" I get an error: koji: error: Destination tag dist-f12 is locked How do we make updates to put in bodhi? -Steve From paul at city-fan.org Fri Nov 6 14:36:32 2009 From: paul at city-fan.org (Paul Howarth) Date: Fri, 06 Nov 2009 14:36:32 +0000 Subject: Fedora 12 now in RC freeze In-Reply-To: <200911060932.28774.sgrubb@redhat.com> References: <20091105164036.GA15062@nostromo.devel.redhat.com> <200911060932.28774.sgrubb@redhat.com> Message-ID: <4AF43470.1040004@city-fan.org> On 06/11/09 14:32, Steve Grubb wrote: > On Thursday 05 November 2009 11:40:36 am Bill Nottingham wrote: >> We are reaching a *very* deep freeze now as we try and get a final >> release candidate for Fedora 12. Bodhi is now open for submitting >> F-12 updates, and we hope to have update repositories for testing >> later this weekend. >> >> If you have critical blocking issues, you can continue to file >> tag requests with 'make tag-request', and they will be considered. >> For the majority of updates, though, please use bodhi. > > Is something not setup right with cvs? In a F-12 branch when I do "make build" > I get an error: > > koji: error: Destination tag dist-f12 is locked > > How do we make updates to put in bodhi? Perhaps you need to update your "common" area so that F-12 builds target dist-f12-updates-candidate rather than dist-f12? Paul. From pbrobinson at gmail.com Fri Nov 6 14:38:20 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 6 Nov 2009 14:38:20 +0000 Subject: Fedora 12 now in RC freeze In-Reply-To: <200911060932.28774.sgrubb@redhat.com> References: <20091105164036.GA15062@nostromo.devel.redhat.com> <200911060932.28774.sgrubb@redhat.com> Message-ID: <5256d0b0911060638j4a9f5ea6x2644f0f2c7af0e4d@mail.gmail.com> On Fri, Nov 6, 2009 at 2:32 PM, Steve Grubb wrote: > On Thursday 05 November 2009 11:40:36 am Bill Nottingham wrote: >> We are reaching a *very* deep freeze now as we try and get a final >> release candidate for Fedora 12. Bodhi is now open for submitting >> F-12 updates, and we hope to have update repositories for testing >> later this weekend. >> >> If you have critical blocking issues, you can continue to file >> tag requests with 'make tag-request', and they will be considered. >> For the majority of updates, though, please use bodhi. > > Is something not setup right with cvs? In a F-12 branch when I do "make build" > I get an error: > > koji: error: Destination tag dist-f12 is locked > > How do we make updates to put in bodhi? Do a 'cvs update' in the root of the package directory tree and it will update the scripts in the common dir. Peter From guido.grazioli at gmail.com Fri Nov 6 14:43:40 2009 From: guido.grazioli at gmail.com (Guido Grazioli) Date: Fri, 6 Nov 2009 15:43:40 +0100 Subject: Fedora Moblin remix In-Reply-To: <5256d0b0911051536s3065dbcdsb803533dc48ee2d2@mail.gmail.com> References: <5256d0b0911051001i5a6d7429u2fd2c965685e40f0@mail.gmail.com> <2f984ea00911051456r3f642349q3c059178c456cbf5@mail.gmail.com> <5256d0b0911051536s3065dbcdsb803533dc48ee2d2@mail.gmail.com> Message-ID: <2f984ea00911060643x38bdbc46u422cb586d2e82da7@mail.gmail.com> 2009/11/6 Peter Robinson : >> * Just before graphical boot screen, for some seconds i can see: >> -- >> render error detected, EIR: 0x00000010 >> page table error >> ?PGTBL_ER: 0x00000100 >> [drm:i915_handle_error] *ERROR* EIR stuck: 0x0000010, masking >> render error detected, EIR: 0x00000010 >> page table error >> ?PGTBL_ER: 0x00000100 >> -- >> however, everything seems to run just right after that. > > Is it recorded in dmesg. It might be worth reporting a bug with all > the details. > Yep i can see it in dmesg; which component should i report the bug against? >> * Where's wifi configuration? isn't there a graphical tool >> to configure it? asking my gf to get it up on a shell is a no-no. > > It should be in the top right corner of the top panel. Just to the > left of the volume control. From memory the eeePC 900 has an atheros > card so it should work OK. > I can see NetworkManager running with top, but i have no icon in the toolbar; wifi devices are present and atheros module loaded correctly. >> * I mounted a touchscreen in my eeepc, and moblin gui looks >> much more friendly to that interface. However i couldnt install >> the manufacturer software (eGalax), because i think >> an autoloaded module interferes with it (generic-usb?). >> On F11 nothing get autoloaded and touchscreen works fine. >> I need some more testing to figure this out. > > Do they have an open driver? Maybe its supported in F-12 and I just > need to make sure the right package is included to support it. > The driver is here: http://210.64.17.162/web20/eGalaxTouchDriver/linuxDriver.htm A kernel module is actually needed only if the touchscreen uses serial connection; installation of their driver for usb only modifies xorg.conf and launches a calibration utility. Will try again in the weekend, as i can have made something wrong, and will report back to you. Just forgot to report yesterday: if i open cheese and take a picture from the webcam (default setting are ok), the image goes to the first "rolling" screen. If i click on the picture a program is opened (media viewer?) but after half a second it closes with no error. Then the background image is replaced with a grey background. -- Guido Grazioli Via Parri 11 48011 - Alfonsine (RA) Mobile: +39 347 1017202 (10-18) Key FP = 7040 F398 0DED A737 7337 DAE1 12DC A698 5E81 2278 Linked in: http://www.linkedin.com/in/guidograzioli From sgrubb at redhat.com Fri Nov 6 14:45:33 2009 From: sgrubb at redhat.com (Steve Grubb) Date: Fri, 6 Nov 2009 09:45:33 -0500 Subject: Fedora 12 now in RC freeze In-Reply-To: <4AF43470.1040004@city-fan.org> References: <20091105164036.GA15062@nostromo.devel.redhat.com> <200911060932.28774.sgrubb@redhat.com> <4AF43470.1040004@city-fan.org> Message-ID: <200911060945.34328.sgrubb@redhat.com> On Friday 06 November 2009 09:36:32 am Paul Howarth wrote: > On 06/11/09 14:32, Steve Grubb wrote: > > On Thursday 05 November 2009 11:40:36 am Bill Nottingham wrote: > >> We are reaching a *very* deep freeze now as we try and get a final > >> release candidate for Fedora 12. Bodhi is now open for submitting > >> F-12 updates, and we hope to have update repositories for testing > >> later this weekend. > >> > >> If you have critical blocking issues, you can continue to file > >> tag requests with 'make tag-request', and they will be considered. > >> For the majority of updates, though, please use bodhi. > > > > Is something not setup right with cvs? In a F-12 branch when I do "make > > build" I get an error: > > > > koji: error: Destination tag dist-f12 is locked > > > > How do we make updates to put in bodhi? > > Perhaps you need to update your "common" area so that F-12 builds target > dist-f12-updates-candidate rather than dist-f12? Yep, that fixes it. I sure wished it would automatically unlock itself just like it locked itself. The error output is not intuitive as to what you need to do to fix it. -Steve From pbrobinson at gmail.com Fri Nov 6 14:53:20 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 6 Nov 2009 14:53:20 +0000 Subject: Fedora Moblin remix In-Reply-To: <2f984ea00911060643x38bdbc46u422cb586d2e82da7@mail.gmail.com> References: <5256d0b0911051001i5a6d7429u2fd2c965685e40f0@mail.gmail.com> <2f984ea00911051456r3f642349q3c059178c456cbf5@mail.gmail.com> <5256d0b0911051536s3065dbcdsb803533dc48ee2d2@mail.gmail.com> <2f984ea00911060643x38bdbc46u422cb586d2e82da7@mail.gmail.com> Message-ID: <5256d0b0911060653l58d6c9e0xc0ea8d90f154602@mail.gmail.com> On Fri, Nov 6, 2009 at 2:43 PM, Guido Grazioli wrote: > 2009/11/6 Peter Robinson : >>> * Just before graphical boot screen, for some seconds i can see: >>> -- >>> render error detected, EIR: 0x00000010 >>> page table error >>> ?PGTBL_ER: 0x00000100 >>> [drm:i915_handle_error] *ERROR* EIR stuck: 0x0000010, masking >>> render error detected, EIR: 0x00000010 >>> page table error >>> ?PGTBL_ER: 0x00000100 >>> -- >>> however, everything seems to run just right after that. >> >> Is it recorded in dmesg. It might be worth reporting a bug with all >> the details. >> > > Yep i can see it in dmesg; which component should i report the bug against? Start with xorg-x11-drv-intel and we'll take it from there. Let me know what the bug number is. >>> * Where's wifi configuration? isn't there a graphical tool >>> to configure it? asking my gf to get it up on a shell is a no-no. >> >> It should be in the top right corner of the top panel. Just to the >> left of the volume control. From memory the eeePC 900 has an atheros >> card so it should work OK. >> > > I can see NetworkManager running with top, but i have no icon in the toolbar; > wifi devices are present and atheros module loaded correctly. Can you try running from a terminal "network-manager-netbook -s" and see what you get. You should get the gui but not embedded in the main bar. >>> * I mounted a touchscreen in my eeepc, and moblin gui looks >>> much more friendly to that interface. However i couldnt install >>> the manufacturer software (eGalax), because i think >>> an autoloaded module interferes with it (generic-usb?). >>> On F11 nothing get autoloaded and touchscreen works fine. >>> I need some more testing to figure this out. >> >> Do they have an open driver? Maybe its supported in F-12 and I just >> need to make sure the right package is included to support it. >> > > The driver is here: > http://210.64.17.162/web20/eGalaxTouchDriver/linuxDriver.htm > > A kernel module is actually needed only if > the touchscreen uses serial connection; installation of their > driver for usb only modifies xorg.conf and launches a > calibration utility. Will try again in the weekend, as i can have made > something wrong, and will report back to you. Sounds like the X input guys should be able to detect the USB device and autoconfigure it. > Just forgot to report yesterday: if i open cheese and take a > picture from the webcam (default setting are ok), the > image goes to the first "rolling" screen. If i click on the picture > a program is opened (media viewer?) but after half a second > it closes with no error. Then the background image is > replaced with a grey background. That's a known bug. Some issue in mesa/driver. See https://bugzilla.redhat.com/show_bug.cgi?id=529372 Cheers, Peter From james at fedoraproject.org Fri Nov 6 15:14:01 2009 From: james at fedoraproject.org (James Antill) Date: Fri, 06 Nov 2009 10:14:01 -0500 Subject: Ubuntu shows updates / security updates on shell logins In-Reply-To: <20091104165030.GA25940@amd.home.annexia.org> References: <20091104165030.GA25940@amd.home.annexia.org> Message-ID: <1257520441.2191.8.camel@code.and.org> On Wed, 2009-11-04 at 16:50 +0000, Richard W.M. Jones wrote: > Newly installed Ubuntu 9.10, when you log in over ssh you may see: > > 34 packages can be updated. > 10 updates are security updates. > > I think this is a nice feature, because many administrators will log > in to servers remotely over ssh and never see the graphical > indications from packagekit et al. > > Actually I was trying to work out how it's implemented. The text goes > into /etc/motd, and as near as I can tell, the Ubuntu "update-manager" > (roughly equivalent of PackageKit) rewrites it whenever packages > become available or get installed. Is this something that PackageKit > could also do? FWIW, I've added a summary-updateinfo command to the increasingly misnamed security plugin. Takes all the same options as list-updateinfo / info-updateinfo, but just prints a small summary: % yum -q summary-updateinfo Updates Info Summary: 6 Security update(s) 56 Bugfix update(s) 10 Enhancement update(s) % yum -q summary-updateinfo new Updates Info Summary: 706 New Package update(s) % ...putting that in motd, or whatever, is your fight :). -- James Antill - james at fedoraproject.org "I'd just like to see a realistic approach to updates via packages." -- Les Mikesell From tmraz at redhat.com Fri Nov 6 15:16:49 2009 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 06 Nov 2009 16:16:49 +0100 Subject: RPM dependency on cron In-Reply-To: References: Message-ID: <1257520609.442.27.camel@vespa.frost.loc> On Fri, 2009-11-06 at 14:40 +0100, Benny Amorsen wrote: > We have a lot of virtualized (OpenVZ) Fedora servers. Until now I have > avoided running cron inside each server; log rotation is done from the > host. > > This has worked rather well until lately. Unfortunately rpm has acquired > a dependency on crontabs, because it adds a file to /etc/cron.daily. In > turn, crontabs depends on /etc/cron.d, which is provided by cronie. > cronie explicitly depends on anacron. And thus, anacron and cronie are > required for all Fedora installations. > > The really nasty thing is that cronie turns itself on when installed! I > suddenly had an extra logrotate running which rotated logs in a way not > consistent with our policy. > > I'm not sure where it's easiest to cut this chain. I'd be tempted to > make crontabs provide /etc/cron.d and make cronie depend on crontabs. > That way rpm would pull in crontabs but nothing more. Why don't you create a custom package for your site which would provide /etc/cron.d but nothing else? The dependencies were added because people were reporting bugs that if they do not install cronie (+anacron) the jobs are not getting run but rpm dependencies do not tell them that cronie is required to run them. I mean there is no way everyone can be satisfied with the dependencies at least as far as the soft dependencies are not supported. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From benny+usenet at amorsen.dk Fri Nov 6 15:44:26 2009 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Fri, 06 Nov 2009 16:44:26 +0100 Subject: RPM dependency on cron References: <1257520609.442.27.camel@vespa.frost.loc> Message-ID: Tomas Mraz writes: > Why don't you create a custom package for your site which would > provide /etc/cron.d but nothing else? I guess I will have to do that. > The dependencies were added because people were reporting bugs that if > they do not install cronie (+anacron) the jobs are not getting run but > rpm dependencies do not tell them that cronie is required to run them. It seems rather surprising that people would miss /var/log/rpmpkgs that much. > I mean there is no way everyone can be satisfied with the dependencies > at least as far as the soft dependencies are not supported. In this case it seems that just installing cronie by default in anaconda would suffice. A similar bug, #474219, was apparently fixed earlier this year, with Jeremy Katz saying: "Having crontabs requiring /etc/cron.d means that you can't do a minimal install without cron, sendmail, etc anymore. There's nothing about crontabs that requires /etc/cron.d, so requiring it really is kind of overkill. Yes, you don't get working cron unless you have a cron daemon installed, but if I have it chkconfig'd off, they don't run either." /Benny From fedora at matbooth.co.uk Fri Nov 6 16:17:29 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Fri, 6 Nov 2009 16:17:29 +0000 Subject: source file audit - 2009-11-01 In-Reply-To: <20091105110614.5023b14f@ohm.scrye.com> References: <20091104171816.0ef2c0a5@ohm.scrye.com> <20091105025742.GB17486@wolff.to> <20091105110614.5023b14f@ohm.scrye.com> Message-ID: <9497e9990911060817g1d243c7eh6c197c012770e8ae@mail.gmail.com> 2009/11/5 Kevin Fenzi : > On Wed, 4 Nov 2009 20:57:42 -0600 > Bruno Wolff III wrote: > >> On Wed, Nov 04, 2009 at 17:18:16 -0700, >> ? Kevin Fenzi wrote: >> > Here's attached another run of my sources/patches url checker. >> > >> > bruno:BADURL:glest_data_3.2.1.zip:glest-data >> >> I took over glest recently and hadn't had to worry about where the >> sources had come from yet. The next time I make a change I'll be sure >> to make sure that the source URLs are accurate. > > Excellent. Thanks. > >> P.S. >> If the audiance for this report is developers, I think it would make >> more sense to sort on the FAS name and then on package name. > > ok. I think I did do that in the past, but failed this time. ;( > > kevin > Don't worry, my mail reader has a magical search function I can use to look for my FAS name. ;-) The packages of mine in that list I will look at this weekend. -- Mat Booth A: Because it destroys the order of the conversation. Q: Why shouldn't you do it? A: Posting your reply above the original message. Q: What is top-posting? From gmaxwell at gmail.com Fri Nov 6 16:41:41 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Fri, 6 Nov 2009 11:41:41 -0500 Subject: Fedora 12 vs. Ubuntu 9.10 Benchmarks ?!? In-Reply-To: References: Message-ID: On Fri, Nov 6, 2009 at 4:40 AM, ne... wrote: > On Thu, Nov 5, 2009 at 14:24, Valent Turkovic wrote: >> http://is.gd/4NU9N >> >> Phoronix published Fedora 12 vs. Ubuntu 9.10 Benchmarks >> > [snip] >> >> Fedora 12 performed on most test better than Ubuntu, nice work guys/ >> galls :) > Well, I just did a tally of the results on the link you posted and > Ubuntu, believe > it or not, bested Fedora by a score of 9 to 5. Allow me to introduce you to my friend statistical significance. Unfortunately the Phoronix results don't provide enough information to determine the confidence intervals, but I wouldn't bet on numbers like 18.32 vs 17.88... at least my own application timings are noisy enough that it wouldn't be. Really the results show that both perform similarly, with a couple of exceptions. This is as expected. From ville.skytta at iki.fi Fri Nov 6 16:41:49 2009 From: ville.skytta at iki.fi (Ville =?windows-1252?q?Skytt=E4?=) Date: Fri, 6 Nov 2009 18:41:49 +0200 Subject: source file audit - 2009-11-01 In-Reply-To: <1257499415.2424.4.camel@localhost> References: <20091104171816.0ef2c0a5@ohm.scrye.com> <1257499415.2424.4.camel@localhost> Message-ID: <200911061841.50289.ville.skytta@iki.fi> On Friday 06 November 2009, Stefan Schulze Frielinghaus wrote: > On Wed, 2009-11-04 at 17:18 -0700, Kevin Fenzi wrote: > [...] > > > stefansf:BADURL:sec-2.5.2.tar.gz:sec > > Fixed in CVS. Thanks for letting me know. > > Just an idea. Wouldn't it be useful to have such a feature in rpmlint, > too? Maybe not enabled as default but as an option. http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/165 From jeff at ocjtech.us Fri Nov 6 17:02:17 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Fri, 6 Nov 2009 11:02:17 -0600 Subject: source file audit - 2009-11-01 In-Reply-To: <20091104171816.0ef2c0a5@ohm.scrye.com> References: <20091104171816.0ef2c0a5@ohm.scrye.com> Message-ID: <935ead450911060902u33271b8byc08290a37dfeee77@mail.gmail.com> On Wed, Nov 4, 2009 at 6:18 PM, Kevin Fenzi wrote: > > jcollie:BADURL:gramps-3.1.2.tar.gz:gramps > jcollie:BADURL:sofsip-cli-0.16.tar.gz:sofsip-cli These are both hosted at SourceForge, but the officially sanctioned download URLs[1] don't work. Downloading the files manually from SourceForge and comparing them with what's in the lookaside cache results in identical files. > jcollie:BADURL:schroedinger-1.0.8.tar.gz:schroedinger This appears to be an issue with the upstream site, will contact them and see what's up. [1] http://fedoraproject.org/wiki/Packaging/SourceURL#Sourceforge.net -- Jeff Ollie From paul at city-fan.org Fri Nov 6 17:18:26 2009 From: paul at city-fan.org (Paul Howarth) Date: Fri, 06 Nov 2009 17:18:26 +0000 Subject: source file audit - 2009-11-01 In-Reply-To: <935ead450911060902u33271b8byc08290a37dfeee77@mail.gmail.com> References: <20091104171816.0ef2c0a5@ohm.scrye.com> <935ead450911060902u33271b8byc08290a37dfeee77@mail.gmail.com> Message-ID: <4AF45A62.8000405@city-fan.org> On 06/11/09 17:02, Jeffrey Ollie wrote: > On Wed, Nov 4, 2009 at 6:18 PM, Kevin Fenzi wrote: >> >> jcollie:BADURL:gramps-3.1.2.tar.gz:gramps >> jcollie:BADURL:sofsip-cli-0.16.tar.gz:sofsip-cli > > These are both hosted at SourceForge, but the officially sanctioned > download URLs[1] don't work. Downloading the files manually from > SourceForge and comparing them with what's in the lookaside cache > results in identical files. These URLs work for me: http://downloads.sf.net/project/gramps/Stable/3.1.2/gramps-3.1.2.tar.gz http://downloads.sf.net/project/sofia-sip/sofsip-cli/0.16/sofsip-cli-0.16.tar.gz Looks like sourceforge are rearranging their file layout. Paul. From jonstanley at gmail.com Fri Nov 6 17:28:28 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Fri, 6 Nov 2009 12:28:28 -0500 Subject: FESCo meeting summary for 2009-11-06 Message-ID: ======================================= #fedora-meeting: FESCo meeting 20091106 ======================================= Meeting started by jds2001 at 17:00:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2009-11-06/fedora-meeting.2009-11-06-17.00.log.html . Meeting summary --------------- * fluidsynth (jds2001, 17:01:19) * AGREED: deferred until the comaintainer is available (jds2001, 17:05:04) * F10 EOL (jds2001, 17:06:25) * AGREED: F10 EOL will be Dec 17, unless F12 slips, when it will be reconsidered. (jds2001, 17:12:33) * Open Floor (jds2001, 17:12:41) Meeting ended at 17:22:49 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * jds2001 (43) * nirik (12) * Kevin_Kofler (12) * abadger1999 (9) * zodbot (8) * dgilmore (5) * skvidal (4) * notting (3) * Oxf13 (3) * jwb (3) * sharkcz (3) * j-rod (0) * dwmw2 (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot From kevin.kofler at chello.at Fri Nov 6 17:42:28 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 06 Nov 2009 18:42:28 +0100 Subject: rawhide report: 20091106 changes References: <20091106132127.GA11846@releng2.fedora.phx.redhat.com> Message-ID: Rawhide Report wrote: > lynx-2.8.6-22.fc12.i686 requires indexhtml > lynx-2.8.6-22.fc12.x86_64 requires indexhtml > lynx-2.8.6-22.fc12.ppc requires indexhtml > lynx-2.8.6-22.fc12.ppc64 requires indexhtml Oh joy, now it's lynx which has broken dependencies. :-( I guess this was caused by the fedora-release-notes update, it was preannounced that index.html was getting dropped. So how to proceed from there? Kevin Kofler From jkeating at redhat.com Fri Nov 6 17:45:32 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 06 Nov 2009 09:45:32 -0800 Subject: rawhide report: 20091106 changes In-Reply-To: References: <20091106132127.GA11846@releng2.fedora.phx.redhat.com> Message-ID: <1257529532.2638.1.camel@localhost.localdomain> On Fri, 2009-11-06 at 18:42 +0100, Kevin Kofler wrote: > > Oh joy, now it's lynx which has broken dependencies. :-( I guess this was > caused by the fedora-release-notes update, it was preannounced that > index.html was getting dropped. So how to proceed from there? Updated lynx was built, it just missed the tag. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Fri Nov 6 17:50:26 2009 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 6 Nov 2009 12:50:26 -0500 Subject: rawhide report: 20091106 changes In-Reply-To: References: <20091106132127.GA11846@releng2.fedora.phx.redhat.com> Message-ID: <20091106175026.GX4048@victoria.internal.frields.org> On Fri, Nov 06, 2009 at 06:42:28PM +0100, Kevin Kofler wrote: > Rawhide Report wrote: > > lynx-2.8.6-22.fc12.i686 requires indexhtml > > lynx-2.8.6-22.fc12.x86_64 requires indexhtml > > lynx-2.8.6-22.fc12.ppc requires indexhtml > > lynx-2.8.6-22.fc12.ppc64 requires indexhtml > > Oh joy, now it's lynx which has broken dependencies. :-( I guess this was > caused by the fedora-release-notes update, it was preannounced that > index.html was getting dropped. So how to proceed from there? https://bugzilla.redhat.com/show_bug.cgi?id=533004 "We have our best men on it...." -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From psmith at fedoraproject.org Fri Nov 6 18:37:45 2009 From: psmith at fedoraproject.org (psmith) Date: Fri, 06 Nov 2009 18:37:45 +0000 Subject: GRUB2 In Fedora In-Reply-To: <5f6f8c5f0911030025x78526b69n98e21aafd9ef117b@mail.gmail.com> References: <5f6f8c5f0911030025x78526b69n98e21aafd9ef117b@mail.gmail.com> Message-ID: <4AF46CF9.9020906@fedoraproject.org> On 03/11/09 08:25, Joshua C. wrote: > 2009/11/3 Liang Suilong: > >> Some Linux distros has migrated from grub-0.97 to grub2-1.97. Grub2 provides >> more useful features to users. And it is more easy to add a new file system >> support. But I can not see Fedora has any plan for GRUB2. I read a feature >> page on Fedora wiki. There is no progress on grub2. >> Now Fedora official repo offers grub2 package. However the version is quite >> strange. Fedora provides grub2-1.98. In fact, this version was 1.96 grabbed >> from svn repo on Aug 27th, 2008. Also, maintainer adds some patches to fix >> the bug. But GNU released grub2-1.97 just now. >> In addition, I try to write grub2 into MBR of the HDD. I do not know why. Is >> there a bug in grub2? >> -- >> http://www.liangsuilong.info >> Fight for freedom!!!!(3F? >> Ask not what your Linux distro can do for you! >> Ask what you can do for your Linux distro! >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> >> > I don't see any need for this. The current grub (0.97) can boot from > ext4, works fine with windows and other distros and has almost (no) > other issues. why to fix it when it ain't broken? > > maybe because that's fedora's way, to be using the latest and greatest to help push linux development along? phil From bruno at wolff.to Fri Nov 6 18:40:53 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 6 Nov 2009 12:40:53 -0600 Subject: Kernel installs not showing up in grub.conf In-Reply-To: <3da3b5b40911050608y711c542dr965f008e92efcf94@mail.gmail.com> References: <3da3b5b40911050608y711c542dr965f008e92efcf94@mail.gmail.com> Message-ID: <20091106184053.GA15626@wolff.to> On Thu, Nov 05, 2009 at 16:08:05 +0200, The firmware warnings are not part of your problem. > grubby fatal error: unable to find a suitable template This sounds like none of the entries in grub are close enough to what the package was expecting so it doesn't know how to make one for the current kernel. One way to do this is to move grub.conf out of the way and install a new kernel. You may want to customize the parameters again. From email.ahmedkamal at googlemail.com Fri Nov 6 19:00:25 2009 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Fri, 6 Nov 2009 21:00:25 +0200 Subject: Kernel installs not showing up in grub.conf In-Reply-To: <20091106184053.GA15626@wolff.to> References: <3da3b5b40911050608y711c542dr965f008e92efcf94@mail.gmail.com> <20091106184053.GA15626@wolff.to> Message-ID: <3da3b5b40911061100u6cdf855cvca23125e9f50a07d@mail.gmail.com> Seems like I'm hitting https://bugzilla.redhat.com/show_bug.cgi?id=530108 since I'm btrfs root. The updated grubby seems not pushed out yet On Fri, Nov 6, 2009 at 8:40 PM, Bruno Wolff III wrote: > On Thu, Nov 05, 2009 at 16:08:05 +0200, > > The firmware warnings are not part of your problem. > > > grubby fatal error: unable to find a suitable template > > This sounds like none of the entries in grub are close enough to what the > package was expecting so it doesn't know how to make one for the current > kernel. > > One way to do this is to move grub.conf out of the way and install a new > kernel. You may want to customize the parameters again. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdahlin at redhat.com Fri Nov 6 19:45:20 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Fri, 06 Nov 2009 14:45:20 -0500 Subject: GRUB2 In Fedora In-Reply-To: <5f6f8c5f0911030025x78526b69n98e21aafd9ef117b@mail.gmail.com> References: <5f6f8c5f0911030025x78526b69n98e21aafd9ef117b@mail.gmail.com> Message-ID: <4AF47CD0.5050705@redhat.com> On 11/03/2009 03:25 AM, Joshua C. wrote: > 2009/11/3 Liang Suilong : >> Some Linux distros has migrated from grub-0.97 to grub2-1.97. Grub2 provides >> more useful features to users. And it is more easy to add a new file system >> support. But I can not see Fedora has any plan for GRUB2. I read a feature >> page on Fedora wiki. There is no progress on grub2. >> Now Fedora official repo offers grub2 package. However the version is quite >> strange. Fedora provides grub2-1.98. In fact, this version was 1.96 grabbed >> from svn repo on Aug 27th, 2008. Also, maintainer adds some patches to fix >> the bug. But GNU released grub2-1.97 just now. >> In addition, I try to write grub2 into MBR of the HDD. I do not know why. Is >> there a bug in grub2? >> -- >> http://www.liangsuilong.info >> Fight for freedom!!!!(3F? >> Ask not what your Linux distro can do for you! >> Ask what you can do for your Linux distro! >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > > I don't see any need for this. The current grub (0.97) can boot from > ext4, works fine with windows and other distros and has almost (no) > other issues. why to fix it when it ain't broken? > Because we're acting as de facto upstream for what is effectively a piece of abandonware. Grub development is essentially dead. This isn't a nice place to be in as a downstream. --CJD From jkeating at redhat.com Fri Nov 6 20:58:34 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 06 Nov 2009 12:58:34 -0800 Subject: GRUB2 In Fedora In-Reply-To: <4AF47CD0.5050705@redhat.com> References: <5f6f8c5f0911030025x78526b69n98e21aafd9ef117b@mail.gmail.com> <4AF47CD0.5050705@redhat.com> Message-ID: <1257541114.2638.2.camel@localhost.localdomain> On Fri, 2009-11-06 at 14:45 -0500, Casey Dahlin wrote: > > Because we're acting as de facto upstream for what is effectively a > piece of abandonware. Grub development is essentially dead. This isn't > a nice place to be in as a downstream. > And yet grub2 still doesn't have all the things we need it to have, that is in our grub, and seem to still not want our stuff yet. Also not a great place to be as a downstream. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jlaska at redhat.com Fri Nov 6 21:07:43 2009 From: jlaska at redhat.com (James Laska) Date: Fri, 06 Nov 2009 16:07:43 -0500 Subject: 2009-11-06 - Fedora 12 blocker bug review Recap Message-ID: <1257541663.2723.607.camel@localhost.localdomain> Greetings, The list was small [1], the event was poorly announced [2]. The conditions were right for a short meeting. However, it was not to be. Certainly nothing like the marathon review last week [3]. Many thanks to those in attendance for helping move the meeting along. Please read on for a summary of the review. [1] https://bugzilla.redhat.com/showdependencytree.cgi?id=473303&hide_resolved=1 [2] jlaska did not send an announcement earlier this week :( [3] https://www.redhat.com/archives/fedora-test-list/2009-October/msg00845.html Thanks, James ========================================================= #fedora-bugzappers: 2009-11-06 blocker bug review meeting ========================================================= Meeting started by adamw at 16:25:14 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-bugzappers/2009-11-06/fedora-bugzappers.2009-11-06-16.25.log.html . Meeting summary --------------- * welcome (adamw, 16:25:21) * https://bugzilla.redhat.com/show_bug.cgi?id=529292 (adamw, 16:25:59) * AGREED: 529292 is closed, fix it. (adamw, 16:28:26) * https://bugzilla.redhat.com/show_bug.cgi?id=533236 (adamw, 16:30:06) * AGREED: 533236 is fixed as confirmed by jlaska, he will close it (adamw, 16:33:53) * https://bugzilla.redhat.com/show_bug.cgi?id=474225 (adamw, 16:33:56) * AGREED: 474225 isn't really a blocker, we gave it a free pass before. we're pretty sure it's fixed, but dropping from the list to target (adamw, 16:50:31) * https://bugzilla.redhat.com/show_bug.cgi?id=533236 (adamw, 16:51:19) * AGREED: 533236 - false alarm (adamw, 16:51:32) * https://bugzilla.redhat.com/show_bug.cgi?id=533363 (adamw, 16:52:03) * AGREED: 533363 is almost certainly 533236, adamw is confirming (adamw, 16:58:32) * open floor (adamw, 17:00:09) * AGREED: 533392 is not a blocker, but we will take the fix if we re-spin anyway (which is likely) (adamw, 17:05:47) * AGREED: 533392 overriding previous agreement, this is a blocker, will be fixed in the respin by including dracut-network (adamw, 17:12:41) * AGREED: 533004 goes back on the blocker list with an updated summary as it resulted in a broken dep on the DVD, will be fixed with an updated lynx in the re-spin (adamw, 17:20:46) * LINK: http://kparal.wordpress.com/2009/10/21/rpmguard-print-important-differences-between-rpms/ (jlaska, 17:29:17) * Unfiled (HINT HINT) release-blocking xulrunner dependency issue (adamw, 17:34:47) * https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=533420 (adamw, 17:35:46) * discussion of 533420 occurs *above* its setting as the meeting topic, please read up (adamw, 17:36:15) * AGREED: 533420 is a release blocker as it's a broken dependency on the DVD spin, a minimum-impact method of sequential rebuilds has been agreed to produce a build that resolves the issue and can be added to the re-spin (adamw, 17:37:22) * ACTION: oxf13 to remove xulrunner from the buildroot, bump/build gnome-python2-extras, tag it, and then put xul back in teh buildroot to build gnome-python2-extras again for the xul update (adamw, 17:37:58) * https://bugzilla.redhat.com/show_bug.cgi?id=523610 (jlaska, 17:40:08) * ACTION: denise double checking with clumens for input on installer shrink results (jlaska, 17:50:16) * AGREED: present installer shrink bugs are not considered blocker bugs ... addressing them at this time would destabalize storage code (jlaska, 17:51:25) * https://bugzilla.redhat.com/show_bug.cgi?id=533350 (jlaska, 17:53:13) * ask for feedback as to whether the existing partitions have lost data (jlaska, 17:56:12) * https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=533108 (jlaska, 17:57:07) * AGREED: request updated testing from Hurry using latest kernel and xorg-x11-server fixes (jlaska, 18:02:16) * https://bugzilla.redhat.com/show_bug.cgi?id=533123 (jlaska, 18:02:52) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=525615#c12 (jlaska, 18:04:25) * LINK: https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_bugzilla (jlaska, 18:06:18) * AGREED: 525615 is change in behavior during reboot after a handled exception. Agreed this isn't a blocker list. Clumens will look into whether python-meh may have introduced the changed behavior (jlaska, 18:07:53) * open floor (jlaska, 18:08:05) * AGREED: everyone is go to spin RC.2 (adamw, 18:15:00) Meeting ended at 18:18:46 UTC. Action Items ------------ * oxf13 to remove xulrunner from the buildroot, bump/build gnome-python2-extras, tag it, and then put xul back in teh buildroot to build gnome-python2-extras again for the xul update * denise double checking with clumens for input on installer shrink results Action Items, by person ----------------------- * denise * denise double checking with clumens for input on installer shrink results * **UNASSIGNED** * oxf13 to remove xulrunner from the buildroot, bump/build gnome-python2-extras, tag it, and then put xul back in teh buildroot to build gnome-python2-extras again for the xul update People Present (lines said) --------------------------- * adamw (181) * jlaska (145) * Oxf13 (61) * notting (23) * buggbot (15) * denise (14) * halfline (7) * warren (5) * zodbot (3) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jreiser at bitwagon.com Fri Nov 6 21:09:32 2009 From: jreiser at bitwagon.com (John Reiser) Date: Fri, 06 Nov 2009 13:09:32 -0800 Subject: GRUB2 In Fedora In-Reply-To: <1257541114.2638.2.camel@localhost.localdomain> References: <5f6f8c5f0911030025x78526b69n98e21aafd9ef117b@mail.gmail.com> <4AF47CD0.5050705@redhat.com> <1257541114.2638.2.camel@localhost.localdomain> Message-ID: <4AF4908C.8030407@bitwagon.com> > And yet grub2 still doesn't have all the things we need it to have, that > is in our grub, and seem to still not want our stuff yet. Where is the list of the specific things that Fedora needs or wants, but which are not available? -- From cdahlin at redhat.com Fri Nov 6 21:28:18 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Fri, 06 Nov 2009 16:28:18 -0500 Subject: GRUB2 In Fedora In-Reply-To: <1257541114.2638.2.camel@localhost.localdomain> References: <5f6f8c5f0911030025x78526b69n98e21aafd9ef117b@mail.gmail.com> <4AF47CD0.5050705@redhat.com> <1257541114.2638.2.camel@localhost.localdomain> Message-ID: <4AF494F2.6070106@redhat.com> On 11/06/2009 03:58 PM, Jesse Keating wrote: > On Fri, 2009-11-06 at 14:45 -0500, Casey Dahlin wrote: >> >> Because we're acting as de facto upstream for what is effectively a >> piece of abandonware. Grub development is essentially dead. This isn't >> a nice place to be in as a downstream. >> > > And yet grub2 still doesn't have all the things we need it to have, that > is in our grub, and seem to still not want our stuff yet. Also not a > great place to be as a downstream. > > He asked why there was a need, not whether the alternative at hand /met/ that need. I've not heard glowing recommendations of Grub 2 from people that follow it, but saying there's no reason to /want/ to be rid of Grub is silly. --CJD From jkeating at redhat.com Fri Nov 6 21:38:47 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 06 Nov 2009 13:38:47 -0800 Subject: GRUB2 In Fedora In-Reply-To: <4AF4908C.8030407@bitwagon.com> References: <5f6f8c5f0911030025x78526b69n98e21aafd9ef117b@mail.gmail.com> <4AF47CD0.5050705@redhat.com> <1257541114.2638.2.camel@localhost.localdomain> <4AF4908C.8030407@bitwagon.com> Message-ID: <1257543527.2638.3.camel@localhost.localdomain> On Fri, 2009-11-06 at 13:09 -0800, John Reiser wrote: > > Where is the list of the specific things that Fedora needs or wants, > but which are not available? You'd have to ask our grub maintainer. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jwboyer at gmail.com Fri Nov 6 23:31:54 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 6 Nov 2009 18:31:54 -0500 Subject: Fedora PPC Koji setup Message-ID: <20091106233154.GG5367@hansolo.jdub.homelinux.org> Hi All, The Fedora PPC secondary arch koji instance is up and running and finally publicly accessible. You can find it here: http://ppc.koji.fedoraproject.org/koji It should work with any existing FAS account. At the moment, I have 3 builders running and a koji-shadow invocation running almost constantly. It's a bit behind the dist-f12 tag, but not by too much. Eventually I'll be switching to the dist-f13 tag. Staging the content will be the next step. I'd like to thank Dennis Gilmore for his exceptional help in getting this all up and running. josh From tim.lauridsen at googlemail.com Sat Nov 7 10:13:35 2009 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Sat, 07 Nov 2009 11:13:35 +0100 Subject: Fedora Moblin remix In-Reply-To: <5256d0b0911051001i5a6d7429u2fd2c965685e40f0@mail.gmail.com> References: <5256d0b0911051001i5a6d7429u2fd2c965685e40f0@mail.gmail.com> Message-ID: <4AF5484F.1040307@googlemail.com> On 11/05/2009 07:01 PM, Peter Robinson wrote: > Hi All, > > For those interested there's a new test LiveCD of Fedora Moblin remix > [1] for those that are interesting in playing. It would be nice to > have some feedback on good or bad issues with it. There's been almost > 1300 downloads since I announced the last one but I've had no feedback > what so ever and while I'd like to assume that's because its perfect I > doubt that is the case. > > Enjoy! > > Peter > > [1] http://fedora.roving-it.com/FedoraMoblin12-Beta2-LiveCD.iso > > As a side note the old one has been renamed to the following to make > it easier to identify. > > http://fedora.roving-it.com/FedoraMoblin12-Beta1-LiveCD.iso > > I downloaded at the livecd and booted it on my T60 http://www.smolts.org/client/show/pub_1b38e7a8-4ef5-478b-89d5-97f0ebf135be The interface was work and looked very nice, but it looked like the network applet was crached, so i couldn't connect to my wireless network :( abrt had a crash report on network-manager-netbook, but i could not submit it because i had not network connection. Thanks for the nice work ! Tim From lsof at nodata.co.uk Sat Nov 7 12:10:14 2009 From: lsof at nodata.co.uk (nodata) Date: Sat, 07 Nov 2009 13:10:14 +0100 Subject: Kernel installs not showing up in grub.conf In-Reply-To: <3da3b5b40911061100u6cdf855cvca23125e9f50a07d@mail.gmail.com> References: <3da3b5b40911050608y711c542dr965f008e92efcf94@mail.gmail.com> <20091106184053.GA15626@wolff.to> <3da3b5b40911061100u6cdf855cvca23125e9f50a07d@mail.gmail.com> Message-ID: <4AF563A6.3030606@nodata.co.uk> Am 2009-11-06 20:00, schrieb Ahmed Kamal: > Seems like I'm hitting https://bugzilla.redhat.com/show_bug.cgi?id=530108 > since I'm btrfs root. The updated grubby seems not pushed out yet > > On Fri, Nov 6, 2009 at 8:40 PM, Bruno Wolff III > wrote: > > On Thu, Nov 05, 2009 at 16:08:05 +0200, > > The firmware warnings are not part of your problem. > > > grubby fatal error: unable to find a suitable template > > This sounds like none of the entries in grub are close enough to > what the > package was expecting so it doesn't know how to make one for the current > kernel. > > One way to do this is to move grub.conf out of the way and install a new > kernel. You may want to customize the parameters again. > > We also have the annoying problem of having a menu.lst AND a grub.conf file. Reported here: https://bugzilla.redhat.com/show_bug.cgi?id=533265 From dave.nerd at gmail.com Sat Nov 7 12:46:21 2009 From: dave.nerd at gmail.com (Dave M) Date: Sat, 7 Nov 2009 06:46:21 -0600 Subject: nonresponsive maintainer for clamtk Message-ID: <9ac12b1c0911070446k7a0b63a5o5d78fa0dfc426e48@mail.gmail.com> Hi, The clamtk package has not been updated since February 2009. One of the two bugs opened against it is a missing dependency which prevents it from running at all. Unfortunately, it has been rebuilt for F12 with the same missing dependency, so it will not run there either. I have tried emailing the current maintainer but that has gone unanswered. Bugzilla # 530709 has been opened as per the unresponsive maintainer procedure. I would like to become the maintainer for this package (although I am not yet an existing Fedora contributor). Thanks, Dave From rawhide at fedoraproject.org Sat Nov 7 13:22:15 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sat, 7 Nov 2009 13:22:15 +0000 Subject: rawhide report: 20091107 changes Message-ID: <20091107132215.GA3552@releng2.fedora.phx.redhat.com> Compose started at Sat Nov 7 08:15:11 UTC 2009 Updated Packages: anaconda-12.46-1.fc12 --------------------- * Fri Nov 06 2009 David Cantrell - 12.46-1 - Correct modopts initialization in loader (take 2) (#531932). (dcantrell) gdm-2.28.1-24.fc12 ------------------ * Fri Nov 06 2009 Ray Strode 2.28.1-24 - Fix login button after cancel on livecd gnome-python2-extras-2.25.3-13.fc12.2 ------------------------------------- * Fri Nov 06 2009 Jesse Keating - 2.25.3-13.2 - Bump again on F12 for release, avoiding gecko update * Thu Nov 05 2009 Jan Horak - 2.25.3-13 - Rebuild against newer gecko lynx-2.8.6-23.fc12 ------------------ * Fri Nov 06 2009 Jiri Moskovcak - 2.8.6-23 - removed dependency on indexthml - changed default homepage to start.fedoraproject.org Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 4 From jerome.benoit at grenouille.com Sat Nov 7 13:44:18 2009 From: jerome.benoit at grenouille.com (Jerome Benoit) Date: Sat, 7 Nov 2009 14:44:18 +0100 Subject: Fedora security updates to full disclosure ? Message-ID: <20091107144418.48db5c77.jerome.benoit@grenouille.com> Hello, Like all major Linux distro, I really think Fedora should push security updates information to full disclosure mailing list ... Cheers. -- J?r?me Benoit aka fraggle La M?t?o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jussilehtola at fedoraproject.org Sat Nov 7 14:04:53 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Sat, 07 Nov 2009 16:04:53 +0200 Subject: Fedora security updates to full disclosure ? In-Reply-To: <20091107144418.48db5c77.jerome.benoit@grenouille.com> References: <20091107144418.48db5c77.jerome.benoit@grenouille.com> Message-ID: <1257602693.4913.2.camel@localhost> On Sat, 2009-11-07 at 14:44 +0100, Jerome Benoit wrote: > Hello, > > Like all major Linux distro, I really think Fedora should push security > updates information to full disclosure mailing list ... What do you mean? The info for security updates is pushed to fedora-package-announce just as for "normal" updates. For instance: https://www.redhat.com/archives/fedora-package-announce/2009-November/thread.html -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From jerome.benoit at grenouille.com Sat Nov 7 14:19:03 2009 From: jerome.benoit at grenouille.com (Jerome Benoit) Date: Sat, 7 Nov 2009 15:19:03 +0100 Subject: Fedora security updates to full disclosure ? In-Reply-To: <1257602693.4913.2.camel@localhost> References: <20091107144418.48db5c77.jerome.benoit@grenouille.com> <1257602693.4913.2.camel@localhost> Message-ID: <20091107151903.5f26ff45.jerome.benoit@grenouille.com> Le Sat, 07 Nov 2009 16:04:53 +0200, Jussi Lehtola a ?crit : > > What do you mean? The info for security updates is pushed to > fedora-package-announce just as for "normal" updates. For instance: > > https://www.redhat.com/archives/fedora-package-announce/2009-November/thread.html Gentoo, Ubuntu, Debian and other distro push them on also on full disclosure mailing list. It's useful for security people to have a central point to lurk in order to know when fixes are pushed on major and community driven Linux distribution... http://seclists.org/fulldisclosure/2009/Jan/index.html Regards. -- J?r?me Benoit aka fraggle La M?t?o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From sundaram at fedoraproject.org Sat Nov 7 14:21:46 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 07 Nov 2009 19:51:46 +0530 Subject: Fedora security updates to full disclosure ? In-Reply-To: <20091107151903.5f26ff45.jerome.benoit@grenouille.com> References: <20091107144418.48db5c77.jerome.benoit@grenouille.com> <1257602693.4913.2.camel@localhost> <20091107151903.5f26ff45.jerome.benoit@grenouille.com> Message-ID: <4AF5827A.6020706@fedoraproject.org> On 11/07/2009 07:49 PM, Jerome Benoit wrote: > Le Sat, 07 Nov 2009 16:04:53 +0200, > Jussi Lehtola a ?crit : > >> >> What do you mean? The info for security updates is pushed to >> fedora-package-announce just as for "normal" updates. For instance: >> >> https://www.redhat.com/archives/fedora-package-announce/2009-November/thread.html > > Gentoo, Ubuntu, Debian and other distro push them on also on full > disclosure mailing list. It's useful for security people to have a > central point to lurk in order to know when fixes are pushed on major > and community driven Linux distribution... > > http://seclists.org/fulldisclosure/2009/Jan/index.html I see a lot of posts about war and terror compared to security issues. Rahul From jerome.benoit at grenouille.com Sat Nov 7 14:50:48 2009 From: jerome.benoit at grenouille.com (Jerome Benoit) Date: Sat, 7 Nov 2009 15:50:48 +0100 Subject: Fedora security updates to full disclosure ? In-Reply-To: <4AF5827A.6020706@fedoraproject.org> References: <20091107144418.48db5c77.jerome.benoit@grenouille.com> <1257602693.4913.2.camel@localhost> <20091107151903.5f26ff45.jerome.benoit@grenouille.com> <4AF5827A.6020706@fedoraproject.org> Message-ID: <20091107155048.ae52f436.jerome.benoit@grenouille.com> Le Sat, 07 Nov 2009 19:51:46 +0530, Rahul Sundaram a ?crit : > > I see a lot of posts about war and terror compared to security issues. > security people hate moderation, of any kind. You can't survive on this list without a properly tuned killfile but it's anyway a central security list with a lot of very useful gems, just one example : http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html Bye. -- J?r?me Benoit aka fraggle La M?t?o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jaroslav at aster.pl Sat Nov 7 15:18:08 2009 From: jaroslav at aster.pl (=?utf-8?q?Jaros=C5=82aw_G=C3=B3rny?=) Date: Sat, 7 Nov 2009 16:18:08 +0100 Subject: cvs-import.sh problem Message-ID: <200911071618.08630.jaroslav@aster.pl> Hi, CVS branches for my first package were created couple of days ago. Today I've set up my account (I think correctly), did a successful checkout, but I can't import sources: [jaroslav at moonstone mpdscribble]$ ./common/cvs-import.sh -b F-11 -m "Initial import (#477542)" ../../mpdscribble-0.18.1-1.fc12.src.rpm Checking out module: 'mpdscribble' Unpacking source package: mpdscribble-0.18.1-1.fc12.src.rpm... L mpdscribble-0.18.1.tar.bz2 A mpdscribble.init.d A mpdscribble.spec Checking : mpdscribble-0.18.1.tar.bz2 on https://cvs.fedoraproject.org/repo/pkgs/upload.cgi... ERROR: could not check remote file status make: *** [upload] B??d 255 ERROR: Uploading the source tarballs failed! Is it me doing sth. wrong (or not configured properly)? Please help me, thanks, -- Jaros?aw G?rny RHCE From pbrobinson at gmail.com Sat Nov 7 15:41:22 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Sat, 7 Nov 2009 15:41:22 +0000 Subject: cvs-import.sh problem In-Reply-To: <200911071618.08630.jaroslav@aster.pl> References: <200911071618.08630.jaroslav@aster.pl> Message-ID: <5256d0b0911070741o489cfb09q2a835755977c6e6e@mail.gmail.com> 2009/11/7 Jaros?aw G?rny : > Hi, > CVS branches for my first package were created couple of days ago. > Today I've set up my account (I think correctly), did a successful checkout, > but I can't import sources: > > > [jaroslav at moonstone mpdscribble]$ ./common/cvs-import.sh -b F-11 -m "Initial > import (#477542)" ../../mpdscribble-0.18.1-1.fc12.src.rpm > Checking out module: 'mpdscribble' > Unpacking source package: mpdscribble-0.18.1-1.fc12.src.rpm... > L mpdscribble-0.18.1.tar.bz2 > A mpdscribble.init.d > A mpdscribble.spec > > Checking : mpdscribble-0.18.1.tar.bz2 on > https://cvs.fedoraproject.org/repo/pkgs/upload.cgi... > ERROR: could not check remote file status > make: *** [upload] B??d 255 > ERROR: Uploading the source tarballs failed! > > > Is it me doing sth. wrong (or not configured properly)? Please help me, It looks OK to me. Try going to the root dir of the package and doing another 'cvs update'. Then change into F-11 (or which ever one) and then I would do a "../common/cvs-import.sh ~/path/to/pacakge.rpm" then a 'cvs update' then 'make build' and take it from there. I would generally do that on devel and then just copy source .cvsignore and package.rpm to the various branches from there. Peter From sundaram at fedoraproject.org Sat Nov 7 15:48:58 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 07 Nov 2009 21:18:58 +0530 Subject: yum repolist puzzle Message-ID: <4AF596EA.4050402@fedoraproject.org> Hi, yum repolist on the latest rawhide shows "fedora" and "updates" repo as having the exact same number of packages which is rather confusing but I suppose it is because they get redirected by mirror manager to point to the same repo. Can we just show the candidate updates or something more meaningful? Rahul From skvidal at fedoraproject.org Sat Nov 7 15:56:21 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Sat, 7 Nov 2009 10:56:21 -0500 (EST) Subject: yum repolist puzzle In-Reply-To: <4AF596EA.4050402@fedoraproject.org> References: <4AF596EA.4050402@fedoraproject.org> Message-ID: On Sat, 7 Nov 2009, Rahul Sundaram wrote: > > Hi, > > yum repolist on the latest rawhide shows "fedora" and "updates" repo as > having the exact same number of packages which is rather confusing but I > suppose it is because they get redirected by mirror manager to point to > the same repo. Can we just show the candidate updates or something more > meaningful? > talk to releng and MM. -sv From sundaram at fedoraproject.org Sat Nov 7 15:57:09 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 07 Nov 2009 21:27:09 +0530 Subject: yum repolist puzzle In-Reply-To: References: <4AF596EA.4050402@fedoraproject.org> Message-ID: <4AF598D5.7010605@fedoraproject.org> On 11/07/2009 09:26 PM, Seth Vidal wrote: > > > On Sat, 7 Nov 2009, Rahul Sundaram wrote: > >> >> Hi, >> >> yum repolist on the latest rawhide shows "fedora" and "updates" repo as >> having the exact same number of packages which is rather confusing but I >> suppose it is because they get redirected by mirror manager to point to >> the same repo. Can we just show the candidate updates or something more >> meaningful? >> > > talk to releng and MM. Tibbs filed https://fedorahosted.org/fedora-infrastructure/ticket/1800 Rahul From jaroslav at aster.pl Sat Nov 7 16:10:06 2009 From: jaroslav at aster.pl (=?utf-8?q?Jaros=C5=82aw_G=C3=B3rny?=) Date: Sat, 7 Nov 2009 17:10:06 +0100 Subject: cvs-import.sh problem In-Reply-To: <5256d0b0911070741o489cfb09q2a835755977c6e6e@mail.gmail.com> References: <200911071618.08630.jaroslav@aster.pl> <5256d0b0911070741o489cfb09q2a835755977c6e6e@mail.gmail.com> Message-ID: <200911071710.06352.jaroslav@aster.pl> Hi, Dnia sobota 07 listopad 2009 o 16:41:22 Peter Robinson napisa?(a): > 2009/11/7 Jaros?aw G?rny : > > (...) but I can't import sources: > > > > Checking : mpdscribble-0.18.1.tar.bz2 on > > https://cvs.fedoraproject.org/repo/pkgs/upload.cgi... > > ERROR: could not check remote file status > > make: *** [upload] B??d 255 > > ERROR: Uploading the source tarballs failed! > > > > > > It looks OK to me. Try going to the root dir of the package and doing > another 'cvs update'. Then change into F-11 (or which ever one) and > then I would do a "../common/cvs-import.sh ~/path/to/pacakge.rpm" then > a 'cvs update' then 'make build' and take it from there. I would > generally do that on devel and then just copy source .cvsignore and > package.rpm to the various branches from there. Unfortunatelly 'cvs update' didn't help. I've tried running cvs-import.sh directly from branch directory (F-11 and also devel), result always the same. any other suggestions? Please ;) -- Jaros?aw G?rny RHCE From craftjml at gmail.com Sat Nov 7 16:48:27 2009 From: craftjml at gmail.com (Jud Craft) Date: Sat, 7 Nov 2009 11:48:27 -0500 Subject: missing help files for Evolution and Nautilus in F12 Beta? Message-ID: <20d6441a0911070848g5bc39d3blb3c273de4c36afd8@mail.gmail.com> In F12, the GNOME Help Program (I think it's called Yelp, now?) shows an error when trying to access Help in either Nautilus or Evolution. Do these programs not have help available? Or has it simply not been packaged for the F12 beta? From mclasen at redhat.com Sat Nov 7 18:25:44 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 07 Nov 2009 13:25:44 -0500 Subject: missing help files for Evolution and Nautilus in F12 Beta? In-Reply-To: <20d6441a0911070848g5bc39d3blb3c273de4c36afd8@mail.gmail.com> References: <20d6441a0911070848g5bc39d3blb3c273de4c36afd8@mail.gmail.com> Message-ID: <1257618344.3195.6.camel@planemask> On Sat, 2009-11-07 at 11:48 -0500, Jud Craft wrote: > In F12, the GNOME Help Program (I think it's called Yelp, now?) shows > an error when trying to access Help in either Nautilus or Evolution. > > Do these programs not have help available? Or has it simply not been > packaged for the F12 beta? The help browser has been called yelp for quite a number of years, not exactly a recent change... The help files for evolution are in the package evolution-help, the help files for nautilus (and the rest of the desktop infrastructure) are in the package gnome-user-docs. Both are not on the live CD for size reasons. We'll include them when we switch to targeting a larger USB stick. From lmacken at redhat.com Sat Nov 7 19:20:59 2009 From: lmacken at redhat.com (Luke Macken) Date: Sat, 7 Nov 2009 14:20:59 -0500 Subject: Fedora security updates to full disclosure ? In-Reply-To: <20091107144418.48db5c77.jerome.benoit@grenouille.com> References: <20091107144418.48db5c77.jerome.benoit@grenouille.com> Message-ID: <20091107192059.GF2972@x300.cable.rcn.com> On Sat, Nov 07, 2009 at 02:44:18PM +0100, Jerome Benoit wrote: > Hello, > > Like all major Linux distro, I really think Fedora should push security > updates information to full disclosure mailing list ... As someone who has spent years spamming Bugtraq & full-disclosure with Gentoo security advisories, I was initially in favor of sending Fedora security notices there. However, in their current state, I don't think that they are useful to many. We have a hard enough time getting package maintainers to enter *anything* about their updates, let alone security-related details such as severity, impact, workarounds, resolution, etc. I think that if we were to do a better job of encouraging/facilitating this, /then/ I would be in favor of spamming other lists. With the Bodhi v2.0 rewrite that I'm currently working on, I'm going to be adding more security tracking features into the core of the platform. I'm hoping to make it not only easier to track security issues, but also announce them in a way that is useful to others. If you're interested in helping to improve our security tracking/update process, we could use the help. luke -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From opensource at till.name Sat Nov 7 20:36:52 2009 From: opensource at till.name (Till Maas) Date: Sat, 07 Nov 2009 21:36:52 +0100 Subject: Non responsive maintainer Jerome Soyer aka saispo (was: Re: nonresponsive maintainer for clamtk) In-Reply-To: <9ac12b1c0911070446k7a0b63a5o5d78fa0dfc426e48@mail.gmail.com> References: <9ac12b1c0911070446k7a0b63a5o5d78fa0dfc426e48@mail.gmail.com> Message-ID: <20091107203652.GB5678@genius.kawo2.rwth-aachen.de> On Sat, Nov 07, 2009 at 06:46:21AM -0600, Dave M wrote: > The clamtk package has not been updated since February 2009. One of > the two bugs opened against it is a missing dependency which prevents > it from running at all. Unfortunately, it has been rebuilt for F12 > with the same missing dependency, so it will not run there either. > > I have tried emailing the current maintainer but that has gone unanswered. > > Bugzilla # 530709 has been opened as per the unresponsive maintainer procedure. > > I would like to become the maintainer for this package (although I am > not yet an existing Fedora contributor). You also should/need CC the maintainer, mention the name (Jerome Soyer) and FAS account (saispo) of him and a link to the Fedora PackageDB is also nice: https://admin.fedoraproject.org/pkgdb/users/packages/saispo He also maintains nufw btw. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From bruno at wolff.to Sat Nov 7 22:38:38 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 7 Nov 2009 16:38:38 -0600 Subject: source file audit - 2009-11-01 In-Reply-To: <20091105110614.5023b14f@ohm.scrye.com> References: <20091104171816.0ef2c0a5@ohm.scrye.com> <20091105025742.GB17486@wolff.to> <20091105110614.5023b14f@ohm.scrye.com> Message-ID: <20091107223838.GA13641@wolff.to> On Thu, Nov 05, 2009 at 11:06:14 -0700, Kevin Fenzi wrote: > On Wed, 4 Nov 2009 20:57:42 -0600 > Bruno Wolff III wrote: > > > On Wed, Nov 04, 2009 at 17:18:16 -0700, > > Kevin Fenzi wrote: > > > Here's attached another run of my sources/patches url checker. > > > > > > bruno:BADURL:glest_data_3.2.1.zip:glest-data > > > > I took over glest recently and hadn't had to worry about where the > > sources had come from yet. The next time I make a change I'll be sure > > to make sure that the source URLs are accurate. > > Excellent. Thanks. I tried grabbing http://dl.sf.net/glest/glest_data_3.2.1.zip and it seemed to work. The actual URL in the spec file has the %version macro. Is the macro or something with sourceforge the problem? From anders+fedora-devel at trudheim.co.uk Sat Nov 7 22:46:36 2009 From: anders+fedora-devel at trudheim.co.uk (Anders Rayner-Karlsson) Date: Sat, 7 Nov 2009 23:46:36 +0100 Subject: Ubuntu shows updates / security updates on shell logins In-Reply-To: <1257520441.2191.8.camel@code.and.org> References: <20091104165030.GA25940@amd.home.annexia.org> <1257520441.2191.8.camel@code.and.org> Message-ID: <20091107224635.GH11288@shuttle> * James Antill [20091106 16:14]: > On Wed, 2009-11-04 at 16:50 +0000, Richard W.M. Jones wrote: > > Newly installed Ubuntu 9.10, when you log in over ssh you may see: > > > > 34 packages can be updated. > > 10 updates are security updates. > > > > I think this is a nice feature, because many administrators will log > > in to servers remotely over ssh and never see the graphical > > indications from packagekit et al. > > > > Actually I was trying to work out how it's implemented. The text goes > > into /etc/motd, and as near as I can tell, the Ubuntu "update-manager" > > (roughly equivalent of PackageKit) rewrites it whenever packages > > become available or get installed. Is this something that PackageKit > > could also do? > > FWIW, I've added a summary-updateinfo command to the increasingly > misnamed security plugin. > Takes all the same options as list-updateinfo / info-updateinfo, but > just prints a small summary: > > % yum -q summary-updateinfo > Updates Info Summary: > 6 Security update(s) > 56 Bugfix update(s) > 10 Enhancement update(s) > % yum -q summary-updateinfo new > Updates Info Summary: > 706 New Package update(s) > % > > ...putting that in motd, or whatever, is your fight :). > Which can be trivially cron'ed. Then the Match parameter can be equally trivially set up in sshd_config for root / selected administrative users to display a separate motd to everyone else. Addresses the "security" concerns and provides a useful feature. No? -- Anders Rayner-Karlsson All-Round Linux Tinkerer, RHCE and PITA DeLuxe From lsof at nodata.co.uk Sat Nov 7 22:56:40 2009 From: lsof at nodata.co.uk (nodata) Date: Sat, 07 Nov 2009 23:56:40 +0100 Subject: RPM dependency on cron In-Reply-To: References: Message-ID: <4AF5FB28.9030403@nodata.co.uk> Am 2009-11-06 14:40, schrieb Benny Amorsen: > We have a lot of virtualized (OpenVZ) Fedora servers. Until now I have > avoided running cron inside each server; log rotation is done from the > host. > > This has worked rather well until lately. Unfortunately rpm has acquired > a dependency on crontabs, because it adds a file to /etc/cron.daily. In > turn, crontabs depends on /etc/cron.d, which is provided by cronie. > cronie explicitly depends on anacron. And thus, anacron and cronie are > required for all Fedora installations. > > The really nasty thing is that cronie turns itself on when installed! Can't you turn it off? > I > suddenly had an extra logrotate running which rotated logs in a way not > consistent with our policy. > > I'm not sure where it's easiest to cut this chain. I'd be tempted to > make crontabs provide /etc/cron.d and make cronie depend on crontabs. > That way rpm would pull in crontabs but nothing more. > > > /Benny > > From jkeating at redhat.com Sat Nov 7 23:28:35 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 07 Nov 2009 15:28:35 -0800 Subject: yum repolist puzzle In-Reply-To: <4AF598D5.7010605@fedoraproject.org> References: <4AF596EA.4050402@fedoraproject.org> <4AF598D5.7010605@fedoraproject.org> Message-ID: <1257636515.2468.0.camel@localhost.localdomain> On Sat, 2009-11-07 at 21:27 +0530, Rahul Sundaram wrote: > On 11/07/2009 09:26 PM, Seth Vidal wrote: > > > > > > On Sat, 7 Nov 2009, Rahul Sundaram wrote: > > > >> > >> Hi, > >> > >> yum repolist on the latest rawhide shows "fedora" and "updates" repo as > >> having the exact same number of packages which is rather confusing but I > >> suppose it is because they get redirected by mirror manager to point to > >> the same repo. Can we just show the candidate updates or something more > >> meaningful? > >> > > > > talk to releng and MM. > > Tibbs filed > > https://fedorahosted.org/fedora-infrastructure/ticket/1800 > > Rahul > We wanted to get some testing on the new updates repos before enabling them to the world, that's why they redirects haven't been updated. Hopefully we'll be good to go on those on Monday. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From awilliam at redhat.com Sun Nov 8 09:05:03 2009 From: awilliam at redhat.com (Adam Williamson) Date: Sun, 08 Nov 2009 01:05:03 -0800 Subject: GRUB2 In Fedora In-Reply-To: <1257541114.2638.2.camel@localhost.localdomain> References: <5f6f8c5f0911030025x78526b69n98e21aafd9ef117b@mail.gmail.com> <4AF47CD0.5050705@redhat.com> <1257541114.2638.2.camel@localhost.localdomain> Message-ID: <1257671103.3828.17.camel@adam.local.net> On Fri, 2009-11-06 at 12:58 -0800, Jesse Keating wrote: > On Fri, 2009-11-06 at 14:45 -0500, Casey Dahlin wrote: > > > > Because we're acting as de facto upstream for what is effectively a > > piece of abandonware. Grub development is essentially dead. This isn't > > a nice place to be in as a downstream. > > > > And yet grub2 still doesn't have all the things we need it to have, that > is in our grub, and seem to still not want our stuff yet. Also not a > great place to be as a downstream. why don't we make it official that we're the new-old-grub upstream and give it a shiny new name and a website? it's not like we're not the upstream for half the rest of the stack, it'd hardly be a radical new venture... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From sundaram at fedoraproject.org Sun Nov 8 09:04:31 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 08 Nov 2009 14:34:31 +0530 Subject: GRUB2 In Fedora In-Reply-To: <1257671103.3828.17.camel@adam.local.net> References: <5f6f8c5f0911030025x78526b69n98e21aafd9ef117b@mail.gmail.com> <4AF47CD0.5050705@redhat.com> <1257541114.2638.2.camel@localhost.localdomain> <1257671103.3828.17.camel@adam.local.net> Message-ID: <4AF6899F.9020304@fedoraproject.org> On 11/08/2009 02:35 PM, Adam Williamson wrote: > On Fri, 2009-11-06 at 12:58 -0800, Jesse Keating wrote: >> On Fri, 2009-11-06 at 14:45 -0500, Casey Dahlin wrote: >>> >>> Because we're acting as de facto upstream for what is effectively a >>> piece of abandonware. Grub development is essentially dead. This isn't >>> a nice place to be in as a downstream. >>> >> >> And yet grub2 still doesn't have all the things we need it to have, that >> is in our grub, and seem to still not want our stuff yet. Also not a >> great place to be as a downstream. > > why don't we make it official that we're the new-old-grub upstream and > give it a shiny new name and a website? it's not like we're not the > upstream for half the rest of the stack, it'd hardly be a radical new > venture... Wouldn't it be easier to work with GRUB2 folks to add the missing features we need? Rahul From rawhide at fedoraproject.org Sun Nov 8 12:16:10 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sun, 8 Nov 2009 12:16:10 +0000 Subject: rawhide report: 20091108 changes Message-ID: <20091108121610.GA20474@releng2.fedora.phx.redhat.com> Compose started at Sun Nov 8 08:15:08 UTC 2009 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 From mike at miketc.net Sun Nov 8 13:51:04 2009 From: mike at miketc.net (Mike Chambers) Date: Sun, 08 Nov 2009 07:51:04 -0600 Subject: Dell wireless chipset Message-ID: <1257688264.5539.2.camel@scrappy.miketc.net> I have seen on some Dells (as well as my brother's new one yesterday), that their wireless chip just says "Dell wireless" (give or take a word/number or two). What actual chipset/driver does that use and does it work with Fedora out of the box? Sorry for asking that type question here, but if I was to get one, it would have F12 (or soon to be) on it which is what we are testing now. -- Mike Chambers Madisonville, KY "Best lil town on Earth!" From bnocera at redhat.com Sun Nov 8 14:17:20 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Sun, 08 Nov 2009 14:17:20 +0000 Subject: Dell wireless chipset In-Reply-To: <1257688264.5539.2.camel@scrappy.miketc.net> References: <1257688264.5539.2.camel@scrappy.miketc.net> Message-ID: <1257689841.23167.208.camel@localhost.localdomain> On Sun, 2009-11-08 at 07:51 -0600, Mike Chambers wrote: > I have seen on some Dells (as well as my brother's new one yesterday), > that their wireless chip just says "Dell wireless" (give or take a > word/number or two). What actual chipset/driver does that use and does > it work with Fedora out of the box? > > Sorry for asking that type question here, but if I was to get one, it > would have F12 (or soon to be) on it which is what we are testing now. Those are usually rebranded Broadcom chips. If you're lucky, it's supported by one of the open-source drivers in the kernel, otherwise the "wl" driver in RPMFusion works decently well. See http://linuxwireless.org/en/users/Drivers/b43 Cheers From kevin at scrye.com Sun Nov 8 16:23:08 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Sun, 8 Nov 2009 09:23:08 -0700 Subject: source file audit - 2009-11-01 In-Reply-To: <20091107223838.GA13641@wolff.to> References: <20091104171816.0ef2c0a5@ohm.scrye.com> <20091105025742.GB17486@wolff.to> <20091105110614.5023b14f@ohm.scrye.com> <20091107223838.GA13641@wolff.to> Message-ID: <20091108092308.2558c2aa@ohm.scrye.com> On Sat, 7 Nov 2009 16:38:38 -0600 Bruno Wolff III wrote: > On Thu, Nov 05, 2009 at 11:06:14 -0700, > Kevin Fenzi wrote: > > On Wed, 4 Nov 2009 20:57:42 -0600 > > Bruno Wolff III wrote: > > > > > On Wed, Nov 04, 2009 at 17:18:16 -0700, > > > Kevin Fenzi wrote: > > > > Here's attached another run of my sources/patches url checker. > > > > > > > > bruno:BADURL:glest_data_3.2.1.zip:glest-data > > > > > > I took over glest recently and hadn't had to worry about where the > > > sources had come from yet. The next time I make a change I'll be > > > sure to make sure that the source URLs are accurate. > > > > Excellent. Thanks. > > I tried grabbing http://dl.sf.net/glest/glest_data_3.2.1.zip and it > seemed to work. The actual URL in the spec file has the %version > macro. > > Is the macro or something with sourceforge the problem? It's sourceforge. I use 'spectool -g foo.spec', which expands all the macros... Here's what my script said for that spec: --2009-11-01 17:16:41-- http://dl.sf.net/glest/glest_data_3.2.1.zip Resolving dl.sf.net... 128.101.240.209, 150.65.7.130, 198.142.1.17, ... Connecting to dl.sf.net|128.101.240.209|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2009-11-01 17:16:42 ERROR 404: Not Found. Sadly, I think sf is just unreliable. ;( kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sun Nov 8 16:37:34 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 8 Nov 2009 18:37:34 +0200 Subject: does fedora have anything requiring :mail rw access? In-Reply-To: <200910091531.45573.mhlavink@redhat.com> References: <200910091531.45573.mhlavink@redhat.com> Message-ID: <20091108163734.GC3429@victor.nirvana> On Fri, Oct 09, 2009 at 03:31:45PM +0200, Michal Hlavinka wrote: > I've got quite simple question from dovecot's upstream: Why do we have rw > access on mails for mail group? There are two popular models for MTA/MDAs. Run as root and drop priviledges to the receiving user or run under another uid/gid (like using gid mail) which then needs write access to all mailboxes. So depending on the security model of the MTAs you use you may or may not need the mail group being able to write into your mailboxes. I wouldn't change it, because if you don't seem to need it then no process is obviously running as gid mail. And in case you do switch to another MTA/MDA with a different security model you will not be surpised by mails not being delivered. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From andy.shevchenko at gmail.com Sun Nov 8 17:30:14 2009 From: andy.shevchenko at gmail.com (Andy Shevchenko) Date: Sun, 8 Nov 2009 19:30:14 +0200 Subject: qstat conflicts In-Reply-To: References: <5ec8ebd50911050608v27bce3abja0ffcd9c45b1b90@mail.gmail.com> <5ec8ebd50911050654s347093b1seb3a649c36657891@mail.gmail.com> Message-ID: <5ec8ebd50911080930x649968bx4763bbbf10a7e6e1@mail.gmail.com> I renamed binary in the Rawhide's package and filled bug against xqf. -- With Best Regards, Andy Shevchenko From jkeating at redhat.com Sun Nov 8 19:44:15 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 08 Nov 2009 11:44:15 -0800 Subject: GRUB2 In Fedora In-Reply-To: <4AF6899F.9020304@fedoraproject.org> References: <5f6f8c5f0911030025x78526b69n98e21aafd9ef117b@mail.gmail.com> <4AF47CD0.5050705@redhat.com> <1257541114.2638.2.camel@localhost.localdomain> <1257671103.3828.17.camel@adam.local.net> <4AF6899F.9020304@fedoraproject.org> Message-ID: <1257709455.2468.3.camel@localhost.localdomain> On Sun, 2009-11-08 at 14:34 +0530, Rahul Sundaram wrote: > > why don't we make it official that we're the new-old-grub upstream and > > give it a shiny new name and a website? it's not like we're not the > > upstream for half the rest of the stack, it'd hardly be a radical new > > venture... Well we do have a public git repo that consists of grub1 + our changes. Our grub package consists of the last upstream grub1 source + all our patches from our git repo on top of it. I think Peter has been working with other distros that are still on grub1. > > Wouldn't it be easier to work with GRUB2 folks to add the missing > features we need? > > In theory yes, that's how it's supposed to go. In practice, with grub, it doesn't work that way. From what I gather they just aren't interested in working on the things we need at this point in grub2's development. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From opensource at till.name Sun Nov 8 19:59:12 2009 From: opensource at till.name (Till Maas) Date: Sun, 08 Nov 2009 20:59:12 +0100 Subject: source file audit - 2009-11-01 In-Reply-To: <20091108092308.2558c2aa@ohm.scrye.com> References: <20091104171816.0ef2c0a5@ohm.scrye.com> <20091105025742.GB17486@wolff.to> <20091105110614.5023b14f@ohm.scrye.com> <20091107223838.GA13641@wolff.to> <20091108092308.2558c2aa@ohm.scrye.com> Message-ID: <20091108195912.GA27689@genius.kawo2.rwth-aachen.de> On Sun, Nov 08, 2009 at 09:23:08AM -0700, Kevin Fenzi wrote: > On Sat, 7 Nov 2009 16:38:38 -0600 > Bruno Wolff III wrote: > > I tried grabbing http://dl.sf.net/glest/glest_data_3.2.1.zip and it > > seemed to work. The actual URL in the spec file has the %version > > macro. > > > > Is the macro or something with sourceforge the problem? > > It's sourceforge. > > I use 'spectool -g foo.spec', which expands all the macros... > > Here's what my script said for that spec: > > --2009-11-01 17:16:41-- http://dl.sf.net/glest/glest_data_3.2.1.zip > Resolving dl.sf.net... 128.101.240.209, 150.65.7.130, 198.142.1.17, ... > Connecting to dl.sf.net|128.101.240.209|:80... connected. > HTTP request sent, awaiting response... 404 Not Found > 2009-11-01 17:16:42 ERROR 404: Not Found. > > Sadly, I think sf is just unreliable. ;( The SourceURL Guidelines[0] mandate to use in this case http://downloads.sourceforge.net/glest/glest_data_3.2.1.zip instead of the "dl.sf.net" version. Regards Till [0] https://fedoraproject.org/wiki/Packaging:SourceURL#Sourceforge.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From ngompa13 at gmail.com Sun Nov 8 20:02:09 2009 From: ngompa13 at gmail.com (King InuYasha) Date: Sun, 8 Nov 2009 14:02:09 -0600 Subject: GRUB2 In Fedora In-Reply-To: <1257709455.2468.3.camel@localhost.localdomain> References: <5f6f8c5f0911030025x78526b69n98e21aafd9ef117b@mail.gmail.com> <4AF47CD0.5050705@redhat.com> <1257541114.2638.2.camel@localhost.localdomain> <1257671103.3828.17.camel@adam.local.net> <4AF6899F.9020304@fedoraproject.org> <1257709455.2468.3.camel@localhost.localdomain> Message-ID: <8278b1b0911081202m5895456cif4b94fce66212a8a@mail.gmail.com> On Sun, Nov 8, 2009 at 1:44 PM, Jesse Keating wrote: > On Sun, 2009-11-08 at 14:34 +0530, Rahul Sundaram wrote: > > > > Wouldn't it be easier to work with GRUB2 folks to add the missing > > features we need? > > > > > > In theory yes, that's how it's supposed to go. In practice, with grub, > it doesn't work that way. From what I gather they just aren't > interested in working on the things we need at this point in grub2's > development. > > What do we need in grub2? Didn't they work with Ubuntu to get things working for their distribution? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruno at wolff.to Sun Nov 8 23:49:22 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 8 Nov 2009 17:49:22 -0600 Subject: source file audit - 2009-11-01 In-Reply-To: <20091108195912.GA27689@genius.kawo2.rwth-aachen.de> References: <20091104171816.0ef2c0a5@ohm.scrye.com> <20091105025742.GB17486@wolff.to> <20091105110614.5023b14f@ohm.scrye.com> <20091107223838.GA13641@wolff.to> <20091108092308.2558c2aa@ohm.scrye.com> <20091108195912.GA27689@genius.kawo2.rwth-aachen.de> Message-ID: <20091108234922.GA16128@wolff.to> On Sun, Nov 08, 2009 at 20:59:12 +0100, Till Maas wrote: > > The SourceURL Guidelines[0] mandate to use in this case > http://downloads.sourceforge.net/glest/glest_data_3.2.1.zip > instead of the "dl.sf.net" version. I made the change in CVS in the devel branch to help me remember to make this change while doing updates. From Matt_Domsch at dell.com Mon Nov 9 03:39:47 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 8 Nov 2009 21:39:47 -0600 Subject: yum repolist puzzle In-Reply-To: <1257636515.2468.0.camel@localhost.localdomain> References: <4AF596EA.4050402@fedoraproject.org> <4AF598D5.7010605@fedoraproject.org> <1257636515.2468.0.camel@localhost.localdomain> Message-ID: <20091109033947.GA16282@auslistsprd01.us.dell.com> On Sat, Nov 07, 2009 at 03:28:35PM -0800, Jesse Keating wrote: > On Sat, 2009-11-07 at 21:27 +0530, Rahul Sundaram wrote: > > https://fedorahosted.org/fedora-infrastructure/ticket/1800 > > We wanted to get some testing on the new updates repos before enabling > them to the world, that's why they redirects haven't been updated. > Hopefully we'll be good to go on those on Monday. If rel-eng wants to publish an 'empty' repo somewhere on the master mirror, I could have MM redirect the 'updates' repos to that empty repo until content is present for them. That would avoid having it look like both updates and fedora repos both have identical content. -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From liangsuilong at gmail.com Mon Nov 9 05:12:18 2009 From: liangsuilong at gmail.com (Liang Suilong) Date: Mon, 9 Nov 2009 13:12:18 +0800 Subject: GRUB2 In Fedora In-Reply-To: References: Message-ID: Thanks a lot, every helper. I am just so surprising that why grub2 in Fedora is 1.98 however the official version is 1.97. In fact grub2 in Fedora is older that official release. Why not follow the official release version? Does Fedora hope that grub2 replaces grub when GNU release grub2-1.98? I think that grub2 is too complicated for users especially for newbies. Boot loader should be more tiny, just like grub. And Fedora offer a beautiful background for grub. But grub2 has modular design. It looks like that it is easier to add new features and add new filesystem support, such as btrfs support. 2009/11/3 Liang Suilong > Some Linux distros has migrated from grub-0.97 to grub2-1.97. Grub2 > provides more useful features to users. And it is more easy to add a new > file system support. But I can not see Fedora has any plan for GRUB2. I > read a feature page on Fedora wiki. There is no progress on grub2. > > Now Fedora official repo offers grub2 package. However the version is quite > strange. Fedora provides grub2-1.98. In fact, this version was 1.96 grabbed > from svn repo on Aug 27th, 2008. Also, maintainer adds some patches to fix > the bug. But GNU released grub2-1.97 just now. > > In addition, I try to write grub2 into MBR of the HDD. I do not know why. > Is there a bug in grub2? > > -- > http://www.liangsuilong.info > Fight for freedom!!!!(3F? > Ask not what your Linux distro can do for you! > Ask what you can do for your Linux distro! > -- http://www.liangsuilong.info Fight for freedom!!!!(3F? Ask not what your Linux distro can do for you! Ask what you can do for your Linux distro! -------------- next part -------------- An HTML attachment was scrubbed... URL: From Quentin at Armitage.org.uk Mon Nov 9 06:53:12 2009 From: Quentin at Armitage.org.uk (Quentin Armitage) Date: Mon, 09 Nov 2009 06:53:12 +0000 Subject: Dead packages tagged into f12-final Message-ID: <1257749592.2478.15.camel@samson.armitage.org.uk> The following packages, which are marked as dead in the CVS F-12 tree, have builds tagged with f12-final: fonts-hebrew-fancy knm_new-fonts koan lam python-sqlite2 scim-tomoe Quentin Armitage From Quentin at Armitage.org.uk Mon Nov 9 07:19:33 2009 From: Quentin at Armitage.org.uk (Quentin Armitage) Date: Mon, 09 Nov 2009 07:19:33 +0000 Subject: Missing links on Fedora CVS Message-ID: <1257751173.2478.27.camel@samson.armitage.org.uk> I'm not sure where the correct place to report this is, so apologies if this is not the right place. I have noticed that there are some links missing in Fedora CVS. http://cvs.fedoraproject.org/viewvc/rpms/kcheckers/F-10/ http://cvs.fedoraproject.org/viewvc/rpms/kcheckers/F-11/ http://cvs.fedoraproject.org/viewvc/rpms/kcheckers/F-12/ http://cvs.fedoraproject.org/viewvc/rpms/kcheckers/devel/ all exist, but the following do not exist: http://cvs.fedoraproject.org/viewvc/F-10/kcheckers/ http://cvs.fedoraproject.org/viewvc/F-11/kcheckers/ http://cvs.fedoraproject.org/viewvc/F-12/kcheckers/ http://cvs.fedoraproject.org/viewvc/devel/kcheckers/ The same also applies for parrot, but it is also missing the F-9 link. kcheckers and parrot are the only two packages tagged into f12-final for which the http://cvs.fedoraproject.org/viewvc/F-12/PACKAGENAME/ link is missing; I haven't checked the devel or non F-12 branches to see if any other links are missing from them. Quentin Armitage From bioinfornatics at gmail.com Mon Nov 9 07:59:26 2009 From: bioinfornatics at gmail.com (Jonathan MERCIER) Date: Mon, 09 Nov 2009 08:59:26 +0100 Subject: GRUB2 In Fedora In-Reply-To: <4AF494F2.6070106@redhat.com> References: <5f6f8c5f0911030025x78526b69n98e21aafd9ef117b@mail.gmail.com> <4AF47CD0.5050705@redhat.com> <1257541114.2638.2.camel@localhost.localdomain> <4AF494F2.6070106@redhat.com> Message-ID: <1257753566.7081.1.camel@localhost.localdomain> - why Grub2? > Because Fedora is a Linux-based operating system that showcases the latest in free and open source software. Fedora is always free for anyone to use, modify, and distribute. It is built by people across the globe who work together as a community: the Fedora Project. The Fedora Project is open and anyone is welcome to join. The Fedora Project is out front for you, leading the advancement of free, open software and content. Fedora in first is not a distro for neewbie but for he latest in free and open source software. my 2 cents Kind regards From Quentin at Armitage.org.uk Mon Nov 9 11:19:52 2009 From: Quentin at Armitage.org.uk (Quentin Armitage) Date: Mon, 09 Nov 2009 11:19:52 +0000 Subject: Possible wrong versions tagged into f12-final Message-ID: <1257765592.2478.211.camel@samson.armitage.org.uk> I've noticed what might be a couple of anomalies regarding which versions of packages have been tagged into f12-final. freenx-client: 0.9-9.fc12 was built as part of the dist-f12-rebuild, but 0.9-10.fc11 tagged has been tagged into f12-final. gauche: 0.8.14.3.fc12 was built during the mass F12 rebuild, but 0.8.14.3.fc11 has been tagged into f12-final. It appears that 0.8.14-2.fc12 was built after 0.8.14-3.fc12 (during the mass F12 rebuild). Quentin Armitage From dominik at greysector.net Mon Nov 9 11:30:11 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 9 Nov 2009 12:30:11 +0100 Subject: Dead packages tagged into f12-final In-Reply-To: <1257749592.2478.15.camel@samson.armitage.org.uk> References: <1257749592.2478.15.camel@samson.armitage.org.uk> Message-ID: <20091109113011.GC22020@mokona.greysector.net> On Monday, 09 November 2009 at 07:53, Quentin Armitage wrote: > The following packages, which are marked as dead in the CVS F-12 tree, > have builds tagged with f12-final: [...] > lam LAM was killed very late in the cycle and without a plan to deal with broken dependencies that it caused, so it was resurrected. 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 mschwendt at gmail.com Mon Nov 9 12:02:45 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 9 Nov 2009 13:02:45 +0100 Subject: Dependency problems on upgrade from F-11 to F-12 Message-ID: <20091109130245.17f7154c@faldor.intranet> Results of an extras-repoclosure run for F-11 + Updates to F-12 + Updates and i686: | source rpm: PolicyKit-olpc-1.2-2.fc11.src.rpm | package: PolicyKit-olpc-1.2-2.fc11.noarch from fedora-11-i386 | unresolved deps: | /var/lib/PolicyKit-public | related pkgs: | PolicyKit The new "polkit" package set does not provide this directory anymore. And nothing replaces/obsoltes PolicyKit-olpc in F-12. | source rpm: asterisk-1.6.1-0.23.rc1.fc11.src.rpm | package: asterisk-mobile-1.6.1-0.23.rc1.fc11.i586 from fedora-11-i386 | unresolved deps: | asterisk = 0:1.6.1-0.23.rc1.fc11 | related pkgs: | asterisk No upgrade package for "asterisk-mobile". | source rpm: clutter-cairo-0.8.2-3.fc11.src.rpm | package: clutter-cairo-devel-0.8.2-3.fc11.i586 from fedora-11-i386 | unresolved deps: | libclutter-cairo-0.8.so.0 | clutter-cairo = 0:0.8.2-3.fc11 | related pkgs: | clutter-cairo | clutter No "clutter-cairo" anymore in Fedora 12. | source rpm: clutter-cairomm-0.7.4-2.fc11.src.rpm | package: clutter-cairomm-0.7.4-2.fc11.i586 from fedora-11-i386 | unresolved deps: | libclutter-cairo-0.8.so.0 | related pkgs: | clutter-cairo No "clutter-cairo" anymore in Fedora 12. | source rpm: openmpi-1.3.1-1.fc11.src.rpm | package: openmpi-vt-1.3.1-1.fc11.i586 from fedora-11-i386 | unresolved deps: | openmpi-libs = 0:1.3.1-1.fc11 | related pkgs: | openmpi No "openmpi-vt" anymore in Fedora 12. Obsolete sub-package? | source rpm: openvrml-0.18.3-5.fc12.src.rpm | package: openvrml-xembed-0.18.3-5.fc12.i686 from fedora-development-i386 | unresolved deps: | openvrml-gl(x86-32) = 0:0.18.3-5.fc12 | related pkgs: | openvrml Seems to be fixed in -8.fc12, but no ticket in bodhi yet. | source rpm: polkit-qt-0.9.2-1.fc11.src.rpm | package: polkit-qt-devel-0.9.2-1.fc11.i586 from fedora-updates-11-i386 | unresolved deps: | pkgconfig(polkit) | polkit-qt = 0:0.9.2-1.fc11 | pkgconfig(polkit-grant) | libpolkit-qt-gui.so.0 | pkgconfig(polkit-dbus) | libpolkit-qt-core.so.0 | related pkgs: | PolicyKit | polkit-qt | source rpm: polkit-qt-0.9.2-1.fc11.src.rpm | package: polkit-qt-examples-0.9.2-1.fc11.i586 from fedora-updates-11-i386 | unresolved deps: | libpolkit-dbus.so.2 | libpolkit.so.2 | libpolkit-grant.so.2 | polkit-qt = 0:0.9.2-1.fc11 | libpolkit-qt-core.so.0 | related pkgs: | PolicyKit | polkit-qt ?? No polkit-qt package set in F-12 anymore, although there are builds in koji. | source rpm: pyclutter-0.8.2-2.fc11.src.rpm | package: pyclutter-cairo-0.8.2-2.fc11.i586 from fedora-11-i386 | unresolved deps: | libclutter-cairo-0.8.so.0 | related pkgs: | clutter-cairo No "pyclutter-cairo" sub-package anymore in F-12. From pbrobinson at gmail.com Mon Nov 9 12:11:44 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 9 Nov 2009 12:11:44 +0000 Subject: Dependency problems on upgrade from F-11 to F-12 In-Reply-To: <20091109130245.17f7154c@faldor.intranet> References: <20091109130245.17f7154c@faldor.intranet> Message-ID: <5256d0b0911090411x4015180ag6a542c0527f399f3@mail.gmail.com> > | source rpm: clutter-cairo-0.8.2-3.fc11.src.rpm > | package: clutter-cairo-devel-0.8.2-3.fc11.i586 from fedora-11-i386 > | ? unresolved deps: > | ? ? ?libclutter-cairo-0.8.so.0 > | ? ? ?clutter-cairo = 0:0.8.2-3.fc11 > | related pkgs: > | ? clutter-cairo > | ? clutter > > No "clutter-cairo" anymore in Fedora 12. > > | source rpm: clutter-cairomm-0.7.4-2.fc11.src.rpm > | package: clutter-cairomm-0.7.4-2.fc11.i586 from fedora-11-i386 > | ? unresolved deps: > | ? ? ?libclutter-cairo-0.8.so.0 > | related pkgs: > | ? clutter-cairo > > No "clutter-cairo" anymore in Fedora 12. > | source rpm: pyclutter-0.8.2-2.fc11.src.rpm > | package: pyclutter-cairo-0.8.2-2.fc11.i586 from fedora-11-i386 > | ? unresolved deps: > | ? ? ?libclutter-cairo-0.8.so.0 > | related pkgs: > | ? clutter-cairo > > No "pyclutter-cairo" sub-package anymore in F-12. This -cairo functionality has been merged into main clutter packages and those packages should obsolete them. Peter From bnocera at redhat.com Mon Nov 9 12:27:35 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 09 Nov 2009 12:27:35 +0000 Subject: Fedora Moblin remix In-Reply-To: <5256d0b0911051001i5a6d7429u2fd2c965685e40f0@mail.gmail.com> References: <5256d0b0911051001i5a6d7429u2fd2c965685e40f0@mail.gmail.com> Message-ID: <1257769655.10888.8.camel@localhost.localdomain> On Thu, 2009-11-05 at 18:01 +0000, Peter Robinson wrote: > Hi All, > > For those interested there's a new test LiveCD of Fedora Moblin remix > [1] for those that are interesting in playing. It would be nice to > have some feedback on good or bad issues with it. There's been almost > 1300 downloads since I announced the last one but I've had no feedback > what so ever and while I'd like to assume that's because its perfect I > doubt that is the case. I couldn't boot it using EFI on a Macbook Air, from a USB key because of a bootx64.efi error. Which version of syslinux did you use to generate the ISO? The same hardware, generating the same USB key worked (kinda[1]) with the F12 beta live image. Cheers [1]: Got this error on boot (this a first gen MBA, with Intel gfx), will test with the F12 RC when it's available: [drm:drm_mode_rmfb] *ERROR* tried to remove a fb that we didn't own From rawhide at fedoraproject.org Mon Nov 9 12:57:00 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Mon, 9 Nov 2009 12:57:00 +0000 Subject: rawhide report: 20091109 changes Message-ID: <20091109125700.GA7065@releng2.fedora.phx.redhat.com> Compose started at Mon Nov 9 08:15:13 UTC 2009 Updated Packages: anaconda-12.46-2.fc12 --------------------- * Sun Nov 08 2009 Jesse Keating - 12.46-2 - Patch to make add on repos show up during package selection again kernel-2.6.31.5-127.fc12 ------------------------ * Sun Nov 08 2009 David Woodhouse 2.6.31.5-127 - Apply fix for fallback when HP/Acer BIOS bug detected (#524808) - Re-enable DMAR. - Fix libertas crash due to skb pointer bug * Sat Nov 07 2009 Kyle McMartin 2.6.31.5-125 - Disable linux-2.6-die-closed-source-bios-muppets-die.patch and default DMAR to off (can be re-enabled with intel_iommu=on on the command line due to last minute issues and reversion upstream.) * Sat Nov 07 2009 Kyle McMartin 2.6.31.5-126 - Re-enable linux-2.6-die-closed-source-bios-muppets-die.patch, DMAR still defaulting to off. livecd-tools-031-1.fc12.1 ------------------------- * Sun Nov 08 2009 Jesse Keating - 031-1.1 - Patch to disable iswmd on live images for F12 (533739) Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 3 From jwboyer at gmail.com Mon Nov 9 13:05:54 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 9 Nov 2009 08:05:54 -0500 Subject: yum repolist puzzle In-Reply-To: <20091109033947.GA16282@auslistsprd01.us.dell.com> References: <4AF596EA.4050402@fedoraproject.org> <4AF598D5.7010605@fedoraproject.org> <1257636515.2468.0.camel@localhost.localdomain> <20091109033947.GA16282@auslistsprd01.us.dell.com> Message-ID: <20091109130554.GI5367@hansolo.jdub.homelinux.org> On Sun, Nov 08, 2009 at 09:39:47PM -0600, Matt Domsch wrote: >On Sat, Nov 07, 2009 at 03:28:35PM -0800, Jesse Keating wrote: >> On Sat, 2009-11-07 at 21:27 +0530, Rahul Sundaram wrote: >> > https://fedorahosted.org/fedora-infrastructure/ticket/1800 >> >> We wanted to get some testing on the new updates repos before enabling >> them to the world, that's why they redirects haven't been updated. >> Hopefully we'll be good to go on those on Monday. > >If rel-eng wants to publish an 'empty' repo somewhere on the master >mirror, I could have MM redirect the 'updates' repos to that empty >repo until content is present for them. That would avoid having it >look like both updates and fedora repos both have identical content. We have actual F12 updates pushed already. Why does it need to be an 'empty' repo? josh From liangsuilong at gmail.com Mon Nov 9 13:08:11 2009 From: liangsuilong at gmail.com (Liang Suilong) Date: Mon, 9 Nov 2009 21:08:11 +0800 Subject: GRUB2 In Fedora In-Reply-To: References: Message-ID: > > Date: Sun, 8 Nov 2009 14:02:09 -0600 From: King InuYasha Subject: Re: GRUB2 In Fedora To: Development discussions related to Fedora Message-ID: <8278b1b0911081202m5895456cif4b94fce66212a8a at mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" On Sun, Nov 8, 2009 at 1:44 PM, Jesse Keating wrote: > On Sun, 2009-11-08 at 14:34 +0530, Rahul Sundaram wrote: > > > > Wouldn't it be easier to work with GRUB2 folks to add the missing > > features we need? > > > > > > In theory yes, that's how it's supposed to go. In practice, with grub, > it doesn't work that way. From what I gather they just aren't > interested in working on the things we need at this point in grub2's > development. > > What do we need in grub2? Didn't they work with Ubuntu to get things working for their distribution? Debian Sid swtiched from grub to grub2 firstly. And then Ubuntu was following. -- http://www.liangsuilong.info Fight for freedom!!!!(3F? Ask not what your Linux distro can do for you! Ask what you can do for your Linux distro! -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.lauridsen at googlemail.com Mon Nov 9 13:31:46 2009 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Mon, 09 Nov 2009 14:31:46 +0100 Subject: Fedora Moblin remix In-Reply-To: <4AF5484F.1040307@googlemail.com> References: <5256d0b0911051001i5a6d7429u2fd2c965685e40f0@mail.gmail.com> <4AF5484F.1040307@googlemail.com> Message-ID: <4AF819C2.8080800@googlemail.com> On 11/07/2009 11:13 AM, Tim Lauridsen wrote: > On 11/05/2009 07:01 PM, Peter Robinson wrote: >> Hi All, >> >> For those interested there's a new test LiveCD of Fedora Moblin remix >> [1] for those that are interesting in playing. It would be nice to >> have some feedback on good or bad issues with it. There's been almost >> 1300 downloads since I announced the last one but I've had no feedback >> what so ever and while I'd like to assume that's because its perfect I >> doubt that is the case. >> >> Enjoy! >> >> Peter >> >> [1] http://fedora.roving-it.com/FedoraMoblin12-Beta2-LiveCD.iso >> >> As a side note the old one has been renamed to the following to make >> it easier to identify. >> >> http://fedora.roving-it.com/FedoraMoblin12-Beta1-LiveCD.iso >> > I downloaded at the livecd and booted it on my T60 > http://www.smolts.org/client/show/pub_1b38e7a8-4ef5-478b-89d5-97f0ebf135be > > The interface was work and looked very nice, but it looked like the > network applet was crached, so i couldn't > connect to my wireless network :( > abrt had a crash report on network-manager-netbook, but i could not > submit it because i had not network connection. > > Thanks for the nice work ! > > Tim > Tested with Beta3, same issue no network applet and no way to get a wpa2 connection :( Tim From pbrobinson at gmail.com Mon Nov 9 13:36:39 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 9 Nov 2009 13:36:39 +0000 Subject: Fedora Moblin remix In-Reply-To: <4AF819C2.8080800@googlemail.com> References: <5256d0b0911051001i5a6d7429u2fd2c965685e40f0@mail.gmail.com> <4AF5484F.1040307@googlemail.com> <4AF819C2.8080800@googlemail.com> Message-ID: <5256d0b0911090536i3b658e54ka3c77d88239b56bf@mail.gmail.com> On Mon, Nov 9, 2009 at 1:31 PM, Tim Lauridsen wrote: > On 11/07/2009 11:13 AM, Tim Lauridsen wrote: >> >> On 11/05/2009 07:01 PM, Peter Robinson wrote: >>> >>> Hi All, >>> >>> For those interested there's a new test LiveCD of Fedora Moblin remix >>> [1] for those that are interesting in playing. It would be nice to >>> have some feedback on good or bad issues with it. There's been almost >>> 1300 downloads since I announced the last one but I've had no feedback >>> what so ever and while I'd like to assume that's because its perfect I >>> doubt that is the case. >>> >>> Enjoy! >>> >>> Peter >>> >>> [1] http://fedora.roving-it.com/FedoraMoblin12-Beta2-LiveCD.iso >>> >>> As a side note the old one has been renamed to the following to make >>> it easier to identify. >>> >>> http://fedora.roving-it.com/FedoraMoblin12-Beta1-LiveCD.iso >>> >> I downloaded at the livecd and booted it on my T60 >> http://www.smolts.org/client/show/pub_1b38e7a8-4ef5-478b-89d5-97f0ebf135be >> >> The interface was work and looked very nice, but it looked like the >> network applet was crached, so i couldn't >> connect to my wireless network :( >> abrt had a crash report on network-manager-netbook, but i could not >> submit it because i had not network connection. >> >> Thanks for the nice work ! >> >> Tim >> > > Tested with Beta3, same issue no network applet and no way to get a wpa2 > connection :( There's a crash in n-m-n that I'm looking into. It seems to be when there's no exiting connections as it works fine on my dual gnome/mobilin instance which already had APs. Cheers, Peter From pbrobinson at gmail.com Mon Nov 9 13:41:16 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 9 Nov 2009 13:41:16 +0000 Subject: Fedora Moblin remix In-Reply-To: <1257769655.10888.8.camel@localhost.localdomain> References: <5256d0b0911051001i5a6d7429u2fd2c965685e40f0@mail.gmail.com> <1257769655.10888.8.camel@localhost.localdomain> Message-ID: <5256d0b0911090541h98252c5u9bb46d2dd8174b85@mail.gmail.com> On Mon, Nov 9, 2009 at 12:27 PM, Bastien Nocera wrote: > On Thu, 2009-11-05 at 18:01 +0000, Peter Robinson wrote: >> Hi All, >> >> For those interested there's a new test LiveCD of Fedora Moblin remix >> [1] for those that are interesting in playing. It would be nice to >> have some feedback on good or bad issues with it. There's been almost >> 1300 downloads since I announced the last one but I've had no feedback >> what so ever and while I'd like to assume that's because its perfect I >> doubt that is the case. > > I couldn't boot it using EFI on a Macbook Air, from a USB key because of > a bootx64.efi error. > > Which version of syslinux did you use to generate the ISO? The current one in F-12/rawhide. I've only become aware of the EFI support (via Luke's blog post about the new livecd-creator tool) so its on my list to investigate shortly. Is there anything special that needs to be done or should it just work? If there is something that needs to be done can someone point me to what that is. > The same hardware, generating the same USB key worked (kinda[1]) with > the F12 beta live image. Unfortunately the only EFI based device I have to test this with is a O2 joggler and I have no idea what version of EFI it has, just that its a 32 bit Atom based system that I want took look at closer for hacking when I get some spare cycles. > Cheers > > [1]: Got this error on boot (this a first gen MBA, with Intel gfx), will > test with the F12 RC when it's available: > [drm:drm_mode_rmfb] *ERROR* tried to remove a fb that we didn't own Cheers, Peter From bnocera at redhat.com Mon Nov 9 15:45:42 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 09 Nov 2009 15:45:42 +0000 Subject: Fedora Moblin remix In-Reply-To: <5256d0b0911090541h98252c5u9bb46d2dd8174b85@mail.gmail.com> References: <5256d0b0911051001i5a6d7429u2fd2c965685e40f0@mail.gmail.com> <1257769655.10888.8.camel@localhost.localdomain> <5256d0b0911090541h98252c5u9bb46d2dd8174b85@mail.gmail.com> Message-ID: <1257781542.10888.23.camel@localhost.localdomain> On Mon, 2009-11-09 at 13:41 +0000, Peter Robinson wrote: > On Mon, Nov 9, 2009 at 12:27 PM, Bastien Nocera wrote: > > On Thu, 2009-11-05 at 18:01 +0000, Peter Robinson wrote: > >> Hi All, > >> > >> For those interested there's a new test LiveCD of Fedora Moblin remix > >> [1] for those that are interesting in playing. It would be nice to > >> have some feedback on good or bad issues with it. There's been almost > >> 1300 downloads since I announced the last one but I've had no feedback > >> what so ever and while I'd like to assume that's because its perfect I > >> doubt that is the case. > > > > I couldn't boot it using EFI on a Macbook Air, from a USB key because of > > a bootx64.efi error. > > > > Which version of syslinux did you use to generate the ISO? > > The current one in F-12/rawhide. I've only become aware of the EFI > support (via Luke's blog post about the new livecd-creator tool) so > its on my list to investigate shortly. Is there anything special that > needs to be done or should it just work? If there is something that > needs to be done can someone point me to what that is. > > > The same hardware, generating the same USB key worked (kinda[1]) with > > the F12 beta live image. > > Unfortunately the only EFI based device I have to test this with is a > O2 joggler and I have no idea what version of EFI it has, just that > its a 32 bit Atom based system that I want took look at closer for > hacking when I get some spare cycles. My just be a dupe of https://bugzilla.redhat.com/show_bug.cgi?id=533824 I'll recreate a boot disk when I get a chance. Cheers From pbrobinson at gmail.com Mon Nov 9 15:50:34 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 9 Nov 2009 15:50:34 +0000 Subject: Fedora Moblin remix In-Reply-To: <1257781542.10888.23.camel@localhost.localdomain> References: <5256d0b0911051001i5a6d7429u2fd2c965685e40f0@mail.gmail.com> <1257769655.10888.8.camel@localhost.localdomain> <5256d0b0911090541h98252c5u9bb46d2dd8174b85@mail.gmail.com> <1257781542.10888.23.camel@localhost.localdomain> Message-ID: <5256d0b0911090750t4840c4f0gf60aac5741c1f8ee@mail.gmail.com> On Mon, Nov 9, 2009 at 3:45 PM, Bastien Nocera wrote: > On Mon, 2009-11-09 at 13:41 +0000, Peter Robinson wrote: >> On Mon, Nov 9, 2009 at 12:27 PM, Bastien Nocera wrote: >> > On Thu, 2009-11-05 at 18:01 +0000, Peter Robinson wrote: >> >> Hi All, >> >> >> >> For those interested there's a new test LiveCD of Fedora Moblin remix >> >> [1] for those that are interesting in playing. It would be nice to >> >> have some feedback on good or bad issues with it. There's been almost >> >> 1300 downloads since I announced the last one but I've had no feedback >> >> what so ever and while I'd like to assume that's because its perfect I >> >> doubt that is the case. >> > >> > I couldn't boot it using EFI on a Macbook Air, from a USB key because of >> > a bootx64.efi error. >> > >> > Which version of syslinux did you use to generate the ISO? >> >> The current one in F-12/rawhide. I've only become aware of the EFI >> support (via Luke's blog post about the new livecd-creator tool) so >> its on my list to investigate shortly. Is there anything special that >> needs to be done or should it just work? If there is something that >> needs to be done can someone point me to what that is. >> >> > The same hardware, generating the same USB key worked (kinda[1]) with >> > the F12 beta live image. >> >> Unfortunately the only EFI based device I have to test this with is a >> O2 joggler and I have no idea what version of EFI it has, just that >> its a 32 bit Atom based system that I want took look at closer for >> hacking when I get some spare cycles. > > My just be a dupe of https://bugzilla.redhat.com/show_bug.cgi?id=533824 > I'll recreate a boot disk when I get a chance. I found these two efi ones over the weekend as well: https://bugzilla.redhat.com/show_bug.cgi?id=528232 https://bugzilla.redhat.com/show_bug.cgi?id=526825 Cheers, Peter From bruno at wolff.to Mon Nov 9 15:29:37 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 9 Nov 2009 09:29:37 -0600 Subject: GRUB2 In Fedora In-Reply-To: References: Message-ID: <20091109152937.GA14779@wolff.to> On Mon, Nov 09, 2009 at 13:12:18 +0800, Liang Suilong wrote: > Thanks a lot, every helper. > > I am just so surprising that why grub2 in Fedora is 1.98 however the > official version is 1.97. In fact grub2 in Fedora is older that official > release. Why not follow the official release version? Does Fedora hope that > grub2 replaces grub when GNU release grub2-1.98? It is a prerelease version. The release string starting with '0' is a tip off that this is the case. From Jochen at herr-schmitt.de Mon Nov 9 15:58:21 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 09 Nov 2009 16:58:21 +0100 Subject: GRUB2 In Fedora In-Reply-To: <20091109152937.GA14779@wolff.to> References: <20091109152937.GA14779@wolff.to> Message-ID: <4AF83C1D.7020502@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 09.11.2009 16:29, schrieb Bruno Wolff III: > > It is a prerelease version. The release string starting with '0' is a tip > off that this is the case. > The release of grub on Fedora is 9.97 nowaday. As link grub2, this is a prerelease. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iJwEAQECAAYFAkr4PBIACgkQZLAIBz9lVu/JvQQAg1YG1BtZWp5kCyAcwwPgv+iX JNylTC8ZnyO/mgGm7UP4yp/irArmGYD5bjIJogu7RsXmUUHqhlprKT40ZYz5414V beKX7GWsrZ2O4GovVVoJ5KjsgT2YuyL57NoeM3NpV/5Qq95m82EOqyMb/zCwEXJX NHCZ4tVMqJNfmOCJ/Zg= =wXAN -----END PGP SIGNATURE----- From skvidal at fedoraproject.org Mon Nov 9 16:58:12 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 9 Nov 2009 11:58:12 -0500 (EST) Subject: odd file requires Message-ID: Hey folks, I put together this list for things I'd like to work on for f13. It's a list of packages with a file-requires that falls outside of *bin/* and /etc/* and then the provider(s) for those files. http://skvidal.fedorapeople.org/misc/non-primary-file-reqs-and-what-requires-them.txt I've gone through some of them and I'm looking for where we can clean up a few more. Take a look through, see if you see a package you're responsible for and, if you can, figure out a way to not need the file-requires. this helps our users b/c if we don't need to get the filelists to resolve the dependency then they don't use up the bandwidth. thanks, -sv From eparis at redhat.com Mon Nov 9 17:17:31 2009 From: eparis at redhat.com (Eric Paris) Date: Mon, 09 Nov 2009 12:17:31 -0500 Subject: A question about allow_unconfined_mmap_low in f11 amd selinux In-Reply-To: References: <3b8e57a80911040723x280abfd0jf6bab04bf4803390@mail.gmail.com> <4AF1A2C5.8010008@redhat.com> Message-ID: <1257787051.2994.22.camel@dhcp231-106.rdu.redhat.com> On Thu, 2009-11-05 at 19:32 +0000, Mike Cloaked wrote: > Mike Cloaked gmail.com> writes: > > > > > Daniel J Walsh redhat.com> writes: > > > > > > > > On 11/04/2009 10:23 AM, mike cloaked wrote: > > > > > > By "moving forward" do you mean that one can, in f11, reset the > > > > original boolean and set boolean mmap_low_allowed instead, in a > > > > forthcoming policy update? > > > > > > > > Or is this a planned change coming for f12 but not yet policy in > > > > earlier versions? > > > > > > > > Thanks > > > > > > > We have setroubleshoot plugins that explain exactly to the users what > > they need to do to turn make their wine > > > apps run. > > > > > > > Does the dereference fix in kernel-2.6.30.9-96.fc11 address the issue raised > > here or have I got this wrong? > > > > I am somewhat confused by the following - I thought that if mmap_min_addr > was >0 then you are not vulnerable. I also thought that installing wine, OR > Crossover would set it to zero. Only on Ubuntu and then I believe only WINE. We do not ever set/allow this by default (at least not that I know of, and if we do please let me know, I'll whack someone with a clue-by-four) > I have Crossover installed and not wine, and just checked: > [mike at home1 ~]$ cat /proc/sys/vm/mmap_min_addr > 65536 > > This is an f11 box. I also set the boolean by doing > # setsebool -P allow_unconfined_mmap_low 1 Bad news! For maximum protection would want that bool off. You do not want to ALLOW unconfined to mmap low memory. -Eric From tmz at pobox.com Mon Nov 9 17:17:59 2009 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 9 Nov 2009 12:17:59 -0500 Subject: odd file requires In-Reply-To: References: Message-ID: <20091109171758.GI31109@inocybe.localdomain> Seth Vidal wrote: > Take a look through, see if you see a package you're responsible for > and, if you can, figure out a way to not need the file-requires. In the case of puppet (and probably some of the others listed in the /usr/share/emacs/site-lisp section), puppet provides an emacs file, but it also owns %{_datadir}/emacs so as not to require emacs. AFAIK, since puppet provides this file, the filelists don't need to be downloaded to resolve the dep. At least, I don't recall ever seeing it download them when I've installed or updated puppet. In the bug requesting the puppet emacs/vim stuff?, I did ask whether making subpackages was preferable to including them in the main package and owning the common dirs. I still could go either way on that. No one else on Cc: in the bug seemed to have an opinion. Thanks for looking into these kinds of details Seth! ? https://bugzilla.redhat.com/491437 -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ What it means to take rights seriously is that one will honor them even when there is a significant social cost in doing so. -- Ronald Dworkin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From jonathan.underwood at gmail.com Mon Nov 9 17:33:52 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 9 Nov 2009 17:33:52 +0000 Subject: odd file requires In-Reply-To: <20091109171758.GI31109@inocybe.localdomain> References: <20091109171758.GI31109@inocybe.localdomain> Message-ID: <645d17210911090933p4c0d4f0dsddc5febce964e523@mail.gmail.com> 2009/11/9 Todd Zullinger : > Seth Vidal wrote: >> Take a look through, see if you see a package you're responsible for >> and, if you can, figure out a way to not need the file-requires. > > In the case of puppet (and probably some of the others listed in the > /usr/share/emacs/site-lisp section), puppet provides an emacs file, > but it also owns %{_datadir}/emacs so as not to require emacs. ?AFAIK, > since puppet provides this file, the filelists don't need to be > downloaded to resolve the dep. ?At least, I don't recall ever seeing > it download them when I've installed or updated puppet. > > In the bug requesting the puppet emacs/vim stuff?, I did ask whether > making subpackages was preferable to including them in the main > package and owning the common dirs. ?I still could go either way on > that. ?No one else on Cc: in the bug seemed to have an opinion. > Note that presently the emacs add-on packaging guidelines do demand separate sub-packages for the elisp files. However a number of packages do exactly as you've done. I am in the process of reviewing and reworking the emacs packaging guidelines and the next iteration in that process (after the currently proposed revision - see fedora-packaging list) will be to propose a guideline to deal with this situation more pragmatically. When a package adds a one or two elisp files, it does seem like overkill to force them into a subpackage, IMO. Certainly Debian has an exception for this case allowing them to be installed without requiring emacs (which then forces a directory ownership as you describe). At the moment I'm thinking that the best approach is a variant of the above, where a package can install files into %{_datadir}/emacs/site-lisp/foo without requiring emacs, and so it will own %{_datadir}/emacs/site-lisp/foo, but not %{_datadir}/emacs/site-lisp/ J. From rdieter at math.unl.edu Mon Nov 9 17:52:49 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 09 Nov 2009 11:52:49 -0600 Subject: Dependency problems on upgrade from F-11 to F-12 References: <20091109130245.17f7154c@faldor.intranet> Message-ID: Michael Schwendt wrote: > ?? No polkit-qt package set in F-12 anymore, although there are builds > in koji. Fixed these in rawhide/cvs (added Obsoletes to kdebase-workspace), will be included in next batched kde update. -- Rex From jonathan.underwood at gmail.com Mon Nov 9 18:00:49 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 9 Nov 2009 18:00:49 +0000 Subject: odd file requires In-Reply-To: <20091109171758.GI31109@inocybe.localdomain> References: <20091109171758.GI31109@inocybe.localdomain> Message-ID: <645d17210911091000q1e3cc2d3o3d0e758294ebdb16@mail.gmail.com> 2009/11/9 Todd Zullinger : > Seth Vidal wrote: >> Take a look through, see if you see a package you're responsible for >> and, if you can, figure out a way to not need the file-requires. > > In the case of puppet (and probably some of the others listed in the > /usr/share/emacs/site-lisp section), puppet provides an emacs file, > but it also owns %{_datadir}/emacs so as not to require emacs. ?AFAIK, > since puppet provides this file, the filelists don't need to be > downloaded to resolve the dep. ?At least, I don't recall ever seeing > it download them when I've installed or updated puppet. Note that actually the problem raised in Seth's list is actually the ftnchek package doing a Requires: /usr/share/emacs/site-lisp Reported, with a patch here: https://bugzilla.redhat.com/show_bug.cgi?id=533906 Jonathan. From poelstra at redhat.com Mon Nov 9 18:20:17 2009 From: poelstra at redhat.com (John Poelstra) Date: Mon, 09 Nov 2009 10:20:17 -0800 Subject: Fedora 12 Status + "Go/No Go" Meeting @ 20:00 EST Today (01:00 AM UTC Tues) Message-ID: <4AF85D61.6020206@redhat.com> Testing of the latest Fedora 12 release candidate (RC4) is underway and a meeting will be held on #fedora-meeting today at 20:00 EST TODAY (01:00 AM UTC Tues)to determine if there are any known blocker bugs which would cast doubt on our ability to release on our current GA date of record: 2009-11-17. After the "Go/No Go" meeting I will also announce the final release readiness meeting... either this coming Wednesday or the following Wednesday @ 19:00 UTC (3 PM EDT/12 PM PDT). In the meantime help test if you can. https://fedoraproject.org/wiki/Test_Results:Fedora_12_RC4_Install Thanks, John _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From belegdol at gmail.com Mon Nov 9 18:30:49 2009 From: belegdol at gmail.com (Julian Sikorski) Date: Mon, 09 Nov 2009 19:30:49 +0100 Subject: odd file requires In-Reply-To: References: Message-ID: W dniu 09.11.2009 17:58, Seth Vidal pisze: > Hey folks, > I put together this list for things I'd like to work on for f13. It's a > list of packages with a file-requires that falls outside of *bin/* and > /etc/* and then the provider(s) for those files. > > http://skvidal.fedorapeople.org/misc/non-primary-file-reqs-and-what-requires-them.txt > > > I've gone through some of them and I'm looking for where we can clean up > a few more. > > Take a look through, see if you see a package you're responsible for > and, if you can, figure out a way to not need the file-requires. > > this helps our users b/c if we don't need to get the filelists to > resolve the dependency then they don't use up the bandwidth. > > thanks, > -sv > I fixed gnome-chemistry-utils-mozplugin to require mozilla-filesystem Julian From skvidal at fedoraproject.org Mon Nov 9 18:34:46 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 9 Nov 2009 13:34:46 -0500 (EST) Subject: odd file requires In-Reply-To: References: Message-ID: On Mon, 9 Nov 2009, Julian Sikorski wrote: > W dniu 09.11.2009 17:58, Seth Vidal pisze: >> Hey folks, >> I put together this list for things I'd like to work on for f13. It's a >> list of packages with a file-requires that falls outside of *bin/* and >> /etc/* and then the provider(s) for those files. >> >> http://skvidal.fedorapeople.org/misc/non-primary-file-reqs-and-what-requires-them.txt >> >> >> I've gone through some of them and I'm looking for where we can clean up >> a few more. >> >> Take a look through, see if you see a package you're responsible for >> and, if you can, figure out a way to not need the file-requires. >> >> this helps our users b/c if we don't need to get the filelists to >> resolve the dependency then they don't use up the bandwidth. >> >> thanks, >> -sv >> > I fixed gnome-chemistry-utils-mozplugin to require mozilla-filesystem Thank you! -sv From aris at redhat.com Mon Nov 9 18:59:12 2009 From: aris at redhat.com (Aristeu Rozanski) Date: Mon, 9 Nov 2009 13:59:12 -0500 Subject: linuxwacom maintenance Message-ID: <20091109185911.GQ18613@redhat.com> Hi, I don't have time to maintain the linuxwacom package anymore. Anyone willing to do it? -- Aristeu From awilliam at redhat.com Mon Nov 9 19:00:14 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 09 Nov 2009 11:00:14 -0800 Subject: Fedora Moblin remix In-Reply-To: <5256d0b0911090536i3b658e54ka3c77d88239b56bf@mail.gmail.com> References: <5256d0b0911051001i5a6d7429u2fd2c965685e40f0@mail.gmail.com> <4AF5484F.1040307@googlemail.com> <4AF819C2.8080800@googlemail.com> <5256d0b0911090536i3b658e54ka3c77d88239b56bf@mail.gmail.com> Message-ID: <1257793214.2352.8.camel@adam.local.net> On Mon, 2009-11-09 at 13:36 +0000, Peter Robinson wrote: > There's a crash in n-m-n that I'm looking into. It seems to be when > there's no exiting connections as it works fine on my dual > gnome/mobilin instance which already had APs. I recall a similar bug in NetworkManager-gnome getting fixed during the F12 cycle (around beta time IIRC) - maybe look at that fix? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Mon Nov 9 19:01:25 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 09 Nov 2009 11:01:25 -0800 Subject: Fedora Moblin remix In-Reply-To: <1257769655.10888.8.camel@localhost.localdomain> References: <5256d0b0911051001i5a6d7429u2fd2c965685e40f0@mail.gmail.com> <1257769655.10888.8.camel@localhost.localdomain> Message-ID: <1257793285.2352.9.camel@adam.local.net> On Mon, 2009-11-09 at 12:27 +0000, Bastien Nocera wrote: > The same hardware, generating the same USB key worked (kinda[1]) with > the F12 beta live image. > > Cheers > > [1]: Got this error on boot (this a first gen MBA, with Intel gfx), will > test with the F12 RC when it's available: > [drm:drm_mode_rmfb] *ERROR* tried to remove a fb that we didn't own That's a very common error message and, AFAICT anyway, doesn't really indicate that anything is particularly broken. At least I see it all the time on systems that otherwise appear to work fine. So if you're having problems I _doubt_ they trace to that message. Check with a qualified X hacker though =) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From jkeating at redhat.com Mon Nov 9 19:03:11 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 09 Nov 2009 11:03:11 -0800 Subject: Fedora Release Engineering meeting summary for 2009-11-9 Message-ID: <1257793391.2468.21.camel@localhost.localdomain> Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-11-09/fedora-releng.2009-11-09-18.08.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-11-09/fedora-releng.2009-11-09-18.08.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-11-09/fedora-releng.2009-11-09-18.08.log.html Meeting summary --------------- * roll call (Oxf13, 18:09:32) * Fedora 12 (Oxf13, 18:14:12) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=533739 (warren, 18:25:49) * Fedora 12 updates (Oxf13, 18:32:07) * Fedora 12 Everything Tree (Oxf13, 18:39:40) * Fedora 13 (Oxf13, 18:43:08) * AGREED: F-13 rawhide will be just a repo of packages, as per no frozen rawhide (Oxf13, 18:55:47) * open floor (Oxf13, 18:57:07) Meeting ended at 19:01:51 UTC. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From bnocera at redhat.com Mon Nov 9 19:11:48 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 09 Nov 2009 19:11:48 +0000 Subject: Fedora Moblin remix In-Reply-To: <1257793285.2352.9.camel@adam.local.net> References: <5256d0b0911051001i5a6d7429u2fd2c965685e40f0@mail.gmail.com> <1257769655.10888.8.camel@localhost.localdomain> <1257793285.2352.9.camel@adam.local.net> Message-ID: <1257793908.10888.111.camel@localhost.localdomain> On Mon, 2009-11-09 at 11:01 -0800, Adam Williamson wrote: > On Mon, 2009-11-09 at 12:27 +0000, Bastien Nocera wrote: > > > The same hardware, generating the same USB key worked (kinda[1]) with > > the F12 beta live image. > > > > Cheers > > > > [1]: Got this error on boot (this a first gen MBA, with Intel gfx), will > > test with the F12 RC when it's available: > > [drm:drm_mode_rmfb] *ERROR* tried to remove a fb that we didn't own > > That's a very common error message and, AFAICT anyway, doesn't really > indicate that anything is particularly broken. At least I see it all the > time on systems that otherwise appear to work fine. So if you're having > problems I _doubt_ they trace to that message. Check with a qualified X > hacker though =) I guess, for myself, and a number of other bug reporters, that's the sort of error you would _see_ when an error message from the console gets printed using KMS. Only problem is that it's not the error message we actually wanted to see. In my case, it was the initrd being unable to find its new root device. Which I later fixed in: https://bugzilla.redhat.com/show_bug.cgi?id=533824 From awilliam at redhat.com Mon Nov 9 19:18:52 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 09 Nov 2009 11:18:52 -0800 Subject: Fedora Moblin remix In-Reply-To: <1257793908.10888.111.camel@localhost.localdomain> References: <5256d0b0911051001i5a6d7429u2fd2c965685e40f0@mail.gmail.com> <1257769655.10888.8.camel@localhost.localdomain> <1257793285.2352.9.camel@adam.local.net> <1257793908.10888.111.camel@localhost.localdomain> Message-ID: <1257794332.2352.11.camel@adam.local.net> On Mon, 2009-11-09 at 19:11 +0000, Bastien Nocera wrote: > > That's a very common error message and, AFAICT anyway, doesn't really > > indicate that anything is particularly broken. At least I see it all the > > time on systems that otherwise appear to work fine. So if you're having > > problems I _doubt_ they trace to that message. Check with a qualified X > > hacker though =) > > I guess, for myself, and a number of other bug reporters, that's the > sort of error you would _see_ when an error message from the console > gets printed using KMS. Yeah, it's one you tend to notice when you get dumped to a console for some other reason, but was actually there all the time and you just weren't seeing it when whatever actually turns out to be broken was working... > Only problem is that it's not the error message we actually wanted to > see. In my case, it was the initrd being unable to find its new root > device. Which I later fixed in: > https://bugzilla.redhat.com/show_bug.cgi?id=533824 Yeah, I have a similar case where occasionally my system just fails to boot; I see the drm error, but it's actually grub or my BIOS falling over. I've verified the same error exists on a successful boot, I just don't see it because the bootsplash hides it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From jdy at cryregarder.com Mon Nov 9 19:18:34 2009 From: jdy at cryregarder.com (Joel) Date: Mon, 9 Nov 2009 19:18:34 +0000 (UTC) Subject: Getting Boost Caught-Up References: Message-ID: Joel cryregarder.com> writes: > Boost 1.41 is going into Beta now. Can we please get boost caught-up > to current release for FC13? Here is a feature request bug: https://bugzilla.redhat.com/show_bug.cgi?id=533922 From ajax at redhat.com Mon Nov 9 19:31:30 2009 From: ajax at redhat.com (Adam Jackson) Date: Mon, 09 Nov 2009 14:31:30 -0500 Subject: odd file requires In-Reply-To: References: Message-ID: <1257795091.7251.788.camel@atropine.boston.devel.redhat.com> On Mon, 2009-11-09 at 11:58 -0500, Seth Vidal wrote: > Hey folks, > I put together this list for things I'd like to work on for f13. It's a > list of packages with a file-requires that falls outside of *bin/* and > /etc/* and then the provider(s) for those files. > > http://skvidal.fedorapeople.org/misc/non-primary-file-reqs-and-what-requires-them.txt > > I've gone through some of them and I'm looking for where we can clean up a > few more. > > Take a look through, see if you see a package you're responsible for and, > if you can, figure out a way to not need the file-requires. Well, I'm on the provider end of these two. /usr/share/X11/app-defaults Required By: x11-ssh-askpass-1.2.4.1-7.fc12 Provided By: libXt-1.0.7-1.fc12 libXt is always going to be the thing providing this, app-defaults are an Xt-ism. /usr/share/X11/rgb.txt Required By: perl-Image-Info-1.28-4.fc12 Provided By: xorg-x11-server-utils-7.4-13.fc12 Requires: rgb is sufficient for the same reason. Fixed both in devel/. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From mike.cloaked at gmail.com Mon Nov 9 19:40:18 2009 From: mike.cloaked at gmail.com (Mike Cloaked) Date: Mon, 9 Nov 2009 19:40:18 +0000 (UTC) Subject: A question about allow_unconfined_mmap_low in f11 amd selinux References: <3b8e57a80911040723x280abfd0jf6bab04bf4803390@mail.gmail.com> <4AF1A2C5.8010008@redhat.com> <1257787051.2994.22.camel@dhcp231-106.rdu.redhat.com> Message-ID: Eric Paris redhat.com> writes: > > I have Crossover installed and not wine, and just checked: > > [mike home1 ~]$ cat /proc/sys/vm/mmap_min_addr > > 65536 > > > > This is an f11 box. I also set the boolean by doing > > # setsebool -P allow_unconfined_mmap_low 1 > > Bad news! For maximum protection would want that bool off. You do not > want to ALLOW unconfined to mmap low memory. > > -Eric Many thanks Eric - I just tried unsetting the boolean - # setsebool -P allow_unconfined_mmap_low 0 Excel and Word 2003 still run in Crossover after resetting it without AVCs popping up - I will unset it in the other machines where I have this also - I guess selinux policy may have changed so that setting it as I did originally is no longer necessary. From bruno at wolff.to Mon Nov 9 15:23:43 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 9 Nov 2009 09:23:43 -0600 Subject: GRUB2 In Fedora In-Reply-To: References: Message-ID: <20091109152343.GA12797@wolff.to> On Mon, Nov 09, 2009 at 13:12:18 +0800, Liang Suilong wrote: > Thanks a lot, every helper. > > I am just so surprising that why grub2 in Fedora is 1.98 however the > official version is 1.97. In fact grub2 in Fedora is older that official > release. Why not follow the official release version? Does Fedora hope that > grub2 replaces grub when GNU release grub2-1.98? It's a prerelease version. The release starting with '0' is a tip off that this is the case. From eqisow at gmail.com Mon Nov 9 20:15:28 2009 From: eqisow at gmail.com (Justin) Date: Mon, 9 Nov 2009 15:15:28 -0500 Subject: A question about allow_unconfined_mmap_low in f11 amd selinux In-Reply-To: References: <3b8e57a80911040723x280abfd0jf6bab04bf4803390@mail.gmail.com> <4AF1A2C5.8010008@redhat.com> <1257787051.2994.22.camel@dhcp231-106.rdu.redhat.com> Message-ID: On Mon, Nov 9, 2009 at 2:40 PM, Mike Cloaked wrote: > Eric Paris redhat.com> writes: > >> > I have Crossover installed and not wine, and just checked: >> > [mike home1 ~]$ cat /proc/sys/vm/mmap_min_addr >> > 65536 >> > >> > This is an f11 box. ?I also set the boolean by doing >> > # setsebool -P allow_unconfined_mmap_low 1 >> >> Bad news! ?For maximum protection would want that bool off. ?You do not >> want to ALLOW unconfined to mmap low memory. >> >> -Eric > > Many thanks Eric - I just tried unsetting the boolean - > # setsebool -P allow_unconfined_mmap_low 0 > > Excel and Word 2003 still run in Crossover after resetting it without AVCs > popping up - I will unset it in the other machines where I have this also - > I guess selinux policy may have changed so that setting it as I did originally > is no longer necessary. Really? For me there is no "allow_unconfined_mmap_low" at all and I'm definitely still getting the error with any Wine application with mmap_low_allowed set to 0. selinux-policy-3.6.32-41.fc12.noarch From notting at redhat.com Mon Nov 9 20:28:45 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 9 Nov 2009 15:28:45 -0500 Subject: intent to retire: kudzu Message-ID: <20091109202844.GA29552@nostromo.devel.redhat.com> I'd like to retire kudzu for F-13. Why? - There are places where it almost certainly does not work with current kernels - It's so deprecated that one of its replacements (HAL) has since been frozen and deprecated - Given that, its upstream is very dead However, it is still being required by two programs: - hwbrowser - fwfstab If someone wants to keep it limping along for thsese two programs I can orphan it. But I'd really rather just retire it. Bill From sundaram at fedoraproject.org Mon Nov 9 20:28:04 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 10 Nov 2009 01:58:04 +0530 Subject: intent to retire: kudzu In-Reply-To: <20091109202844.GA29552@nostromo.devel.redhat.com> References: <20091109202844.GA29552@nostromo.devel.redhat.com> Message-ID: <4AF87B54.5020807@fedoraproject.org> On 11/10/2009 01:58 AM, Bill Nottingham wrote: > I'd like to retire kudzu for F-13. > > Why? > - There are places where it almost certainly does not work with current kernels > - It's so deprecated that one of its replacements (HAL) has since been > frozen and deprecated > - Given that, its upstream is very dead > > However, it is still being required by two programs: > - hwbrowser > - fwfstab > > If someone wants to keep it limping along for thsese two programs I can > orphan it. But I'd really rather just retire it. I filed a bug report against these programs a while back to move away from Kudzu. Neither of these programs themselves seem to be actively maintained anymore. Rahul From smooge at gmail.com Mon Nov 9 21:22:43 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 9 Nov 2009 14:22:43 -0700 Subject: intent to retire: kudzu In-Reply-To: <20091109202844.GA29552@nostromo.devel.redhat.com> References: <20091109202844.GA29552@nostromo.devel.redhat.com> Message-ID: <80d7e4090911091322y61f157a8k3185e5b16578600a@mail.gmail.com> On Mon, Nov 9, 2009 at 1:28 PM, Bill Nottingham wrote: > I'd like to retire kudzu for F-13. > > Why? > - There are places where it almost certainly does not work with current kernels > - It's so deprecated that one of its replacements (HAL) has since been > ?frozen and deprecated > - Given that, its upstream is very dead What Red Hat filed Chapter 13? Crap I needed that paycheck next week. > However, it is still being required by two programs: > - hwbrowser > - fwfstab > > If someone wants to keep it limping along for thsese two programs I can > orphan it. But I'd really rather just retire it. So what replaces kudzu these days. I will say for one that I will miss it.. almost enough to take over it... -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From dwalsh at redhat.com Mon Nov 9 21:24:26 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 09 Nov 2009 16:24:26 -0500 Subject: A question about allow_unconfined_mmap_low in f11 amd selinux In-Reply-To: References: <3b8e57a80911040723x280abfd0jf6bab04bf4803390@mail.gmail.com> <4AF1A2C5.8010008@redhat.com> <1257787051.2994.22.camel@dhcp231-106.rdu.redhat.com> Message-ID: <4AF8888A.4040703@redhat.com> On 11/09/2009 03:15 PM, Justin wrote: > On Mon, Nov 9, 2009 at 2:40 PM, Mike Cloaked wrote: >> Eric Paris redhat.com> writes: >> >>>> I have Crossover installed and not wine, and just checked: >>>> [mike home1 ~]$ cat /proc/sys/vm/mmap_min_addr >>>> 65536 >>>> >>>> This is an f11 box. I also set the boolean by doing >>>> # setsebool -P allow_unconfined_mmap_low 1 >>> >>> Bad news! For maximum protection would want that bool off. You do not >>> want to ALLOW unconfined to mmap low memory. >>> >>> -Eric >> >> Many thanks Eric - I just tried unsetting the boolean - >> # setsebool -P allow_unconfined_mmap_low 0 >> >> Excel and Word 2003 still run in Crossover after resetting it without AVCs >> popping up - I will unset it in the other machines where I have this also - >> I guess selinux policy may have changed so that setting it as I did originally >> is no longer necessary. > > Really? For me there is no "allow_unconfined_mmap_low" at all and I'm > definitely still getting the error with any Wine application with > mmap_low_allowed set to 0. > > selinux-policy-3.6.32-41.fc12.noarch > The name has changed between RHEL5 - allow_unconfined_mmap_low and F12 - mmap_low_allowed The meaning has also changed in RHEL5 unconfined domains are allowed to mmap_low if the boolean is set. vbetool and wine are allowed whether or not the boolean is set. In F12 No domains are allowed to mmap_low unless the boolean is set. If it is set wine, vbetool and unconfined domains are allowed to mmap_zero. One of you is running wine in RHEL5 which is allowed to mmap_zero without the boolean. We changed this in F12 so that wine will break without the boolean set. From opensource at till.name Mon Nov 9 22:01:59 2009 From: opensource at till.name (Till Maas) Date: Mon, 09 Nov 2009 23:01:59 +0100 Subject: Missing links on Fedora CVS In-Reply-To: <1257751173.2478.27.camel@samson.armitage.org.uk> References: <1257751173.2478.27.camel@samson.armitage.org.uk> Message-ID: <20091109220159.GA29053@genius.kawo2.rwth-aachen.de> On Mon, Nov 09, 2009 at 07:19:33AM +0000, Quentin Armitage wrote: > I'm not sure where the correct place to report this is, so apologies if > this is not the right place. The right place is here: https://fedorahosted.org/fedora-infrastructure/ Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From dennis at ausil.us Mon Nov 9 22:36:13 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 9 Nov 2009 16:36:13 -0600 Subject: cvs-import.sh problem In-Reply-To: <200911071618.08630.jaroslav@aster.pl> References: <200911071618.08630.jaroslav@aster.pl> Message-ID: <200911091636.18404.dennis@ausil.us> On Saturday 07 November 2009 09:18:08 am Jaros?aw G?rny wrote: > Hi, > CVS branches for my first package were created couple of days ago. > Today I've set up my account (I think correctly), did a successful > checkout, but I can't import sources: > > > [jaroslav at moonstone mpdscribble]$ ./common/cvs-import.sh -b F-11 -m > "Initial import (#477542)" ../../mpdscribble-0.18.1-1.fc12.src.rpm > Checking out module: 'mpdscribble' > Unpacking source package: mpdscribble-0.18.1-1.fc12.src.rpm... > L mpdscribble-0.18.1.tar.bz2 > A mpdscribble.init.d > A mpdscribble.spec > > Checking : mpdscribble-0.18.1.tar.bz2 on > https://cvs.fedoraproject.org/repo/pkgs/upload.cgi... > ERROR: could not check remote file status > make: *** [upload] B??d 255 > ERROR: Uploading the source tarballs failed! > > > Is it me doing sth. wrong (or not configured properly)? Please help me, > > thanks, > you need to have your ssl cert in place to upload the tarball. run "fedora- cert -n" to get your cert and try again. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From peter.hutterer at who-t.net Mon Nov 9 22:35:40 2009 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Tue, 10 Nov 2009 08:35:40 +1000 Subject: linuxwacom maintenance In-Reply-To: <20091109185911.GQ18613@redhat.com> References: <20091109185911.GQ18613@redhat.com> Message-ID: <20091109223539.GC5789@barra.bne.redhat.com> On Mon, Nov 09, 2009 at 01:59:12PM -0500, Aristeu Rozanski wrote: > I don't have time to maintain the linuxwacom package anymore. Anyone willing > to do it? I'll pick it up. Note that it will become obsolete soon anyway once xorg-x11-drv-wacom gets past the new package review. Cheers, Peter From dwalsh at redhat.com Mon Nov 9 22:36:51 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 09 Nov 2009 17:36:51 -0500 Subject: conflict between seedit <-> selinux-policy and qstat <-> torque-client In-Reply-To: <20091104183836.GC11436@nostromo.devel.redhat.com> References: <4AF19437.9020702@redhat.com> <20091104183836.GC11436@nostromo.devel.redhat.com> Message-ID: <4AF89983.1050300@redhat.com> On 11/04/2009 01:38 PM, Bill Nottingham wrote: >> Because seedit getting installed causes selinux-policy-targeted and friends to get screwed up. > > That sounds like a reason to not ship seedit. Am I missing something? > > Bill > I would not ship it. From bjorn at xn--rombobjrn-67a.se Mon Nov 9 23:01:14 2009 From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=) Date: Tue, 10 Nov 2009 00:01:14 +0100 Subject: Are conflicts in debuginfo packages OK? Message-ID: <200911100001.36601.bjorn@xn--rombobjrn-67a.se> Hello, could someone help me understand the rules about file conflicts and debuginfo packages? I thought there was a rule that if the 32-bit and 64-bit versions of a package provide the same file, then the file's contents must be identical in both packages, with an exception for binary executable files in standard locations like /usr/bin. Now I've noticed that lots of debuginfo packages seem to be violating this rule. The debuginfo packages put files in /usr/lib/debug/usr/bin and similar directories, and the exception doesn't seem to apply to these directories, because RPM complains about conflicts when I try to install both architecture versions of a debuginfo package. I don't see that I as a packager can do anything to prevent these conflicts. Shall I conclude that I don't need to care about conflicts between architecture versions of debuginfo packages? Or shall I try to avoid conflicts in debuginfo packages for libraries, but not for programs? I think I can avoid debuginfo conflicts in packages that provide only libraries, but maybe I shouldn't bother? Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From jkeating at redhat.com Mon Nov 9 23:58:30 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 09 Nov 2009 15:58:30 -0800 Subject: Are conflicts in debuginfo packages OK? In-Reply-To: <200911100001.36601.bjorn@xn--rombobjrn-67a.se> References: <200911100001.36601.bjorn@xn--rombobjrn-67a.se> Message-ID: <1257811110.2468.28.camel@localhost.localdomain> On Tue, 2009-11-10 at 00:01 +0100, Bj?rn Persson wrote: > > I don't see that I as a packager can do anything to prevent these conflicts. > Shall I conclude that I don't need to care about conflicts between architecture > versions of debuginfo packages? Or shall I try to avoid conflicts in debuginfo > packages for libraries, but not for programs? I think I can avoid debuginfo > conflicts in packages that provide only libraries, but maybe I shouldn't > bother? > debuginfo packages cannot be multilib, that is why we don't offer them multilib. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Nov 10 01:29:30 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 09 Nov 2009 17:29:30 -0800 Subject: Fedora 12 has gone gold Message-ID: <1257816570.2468.32.camel@localhost.localdomain> We have just completed our Go / No Go meeting for Fedora 12 and have reached the decision to Go. Fedora 12's package set is golden and we're ready to stage things for shipping. Great work all around, I'm very proud of this release. I'm sure there will be more back patting and hand shaking to come, but Will Woods would like to remind everybody that it's just 11 weeks until Fedora 13 Alpha 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: 198 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From luya at fedoraproject.org Tue Nov 10 02:14:34 2009 From: luya at fedoraproject.org (Luya Tshimbalanga) Date: Mon, 09 Nov 2009 18:14:34 -0800 Subject: linuxwacom maintenance In-Reply-To: <20091109223539.GC5789@barra.bne.redhat.com> References: <20091109185911.GQ18613@redhat.com> <20091109223539.GC5789@barra.bne.redhat.com> Message-ID: <4AF8CC8A.9040908@fedoraproject.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/09/2009 02:35 PM, Peter Hutterer wrote: > On Mon, Nov 09, 2009 at 01:59:12PM -0500, Aristeu Rozanski wrote: >> I don't have time to maintain the linuxwacom package anymore. Anyone willing >> to do it? > > I'll pick it up. Note that it will become obsolete soon anyway once > xorg-x11-drv-wacom gets past the new package review. > Just curious, was xorg-x11-drv-wacom available on past Fedora release (Moonshine version comes in mind)? - -- Luya Tshimbalanga Graphic & Web Designer E: luya at fedoraproject.org W: http://www.thefinalzone.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkr4zIgACgkQaS6HaNQHFTn2EgCfQHrdrYChTuvPXeOhaUc9GJNe ibAAnjQQj18pSCpoih3uFfWyDIndWkM0 =st5A -----END PGP SIGNATURE----- From rodd at clarkson.id.au Tue Nov 10 02:21:59 2009 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 10 Nov 2009 13:21:59 +1100 Subject: Fedora 12 has gone gold In-Reply-To: <1257816570.2468.32.camel@localhost.localdomain> References: <1257816570.2468.32.camel@localhost.localdomain> Message-ID: <1257819719.2452.75.camel@localhost.localdomain> On Mon, 2009-11-09 at 17:29 -0800, Jesse Keating wrote: > We have just completed our Go / No Go meeting for Fedora 12 and have > reached the decision to Go. Fedora 12's package set is golden and we're > ready to stage things for shipping. Great work all around, I'm very > proud of this release. I'm sure there will be more back patting and > hand shaking to come, but Will Woods would like to remind everybody that > it's just 11 weeks until Fedora 13 Alpha freeze! I'd just like to say a big thank you to all involved in F12. Over the development cycle I couldn't get my system to boot, then I couldn't get X running, and then I couldn't keep it running and finally the ATI issues I and others were having were resolved. I'm pleased to say that while I didn't get to see it evolve from f11 to f12, when it finally worked, it was far better than I ever expected, and many of the issues I've had with f11 have been resolved which is great (and yes, I had filed bugs ;-]) Rodd From orion at cora.nwra.com Tue Nov 10 03:13:18 2009 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 9 Nov 2009 20:13:18 -0700 (MST) Subject: Status of HAL In-Reply-To: <20091109202844.GA29552@nostromo.devel.redhat.com> References: <20091109202844.GA29552@nostromo.devel.redhat.com> Message-ID: <4717.97.124.130.31.1257822798.squirrel@www.cora.nwra.com> On Mon, November 9, 2009 1:28 pm, Bill Nottingham wrote: > - It's so deprecated that one of its replacements (HAL) has since been > frozen and deprecated Okay, I really can't keep up with Linux development these days. What has replaced HAL? -- 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 jarod at redhat.com Tue Nov 10 03:19:29 2009 From: jarod at redhat.com (Jarod Wilson) Date: Mon, 09 Nov 2009 22:19:29 -0500 Subject: linuxwacom maintenance In-Reply-To: <4AF8CC8A.9040908@fedoraproject.org> References: <20091109185911.GQ18613@redhat.com> <20091109223539.GC5789@barra.bne.redhat.com> <4AF8CC8A.9040908@fedoraproject.org> Message-ID: <4AF8DBC1.5050506@redhat.com> On 11/9/09 9:14 PM, Luya Tshimbalanga wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/09/2009 02:35 PM, Peter Hutterer wrote: >> On Mon, Nov 09, 2009 at 01:59:12PM -0500, Aristeu Rozanski wrote: >>> I don't have time to maintain the linuxwacom package anymore. Anyone > willing >>> to do it? >> >> I'll pick it up. Note that it will become obsolete soon anyway once >> xorg-x11-drv-wacom gets past the new package review. >> > Just curious, was xorg-x11-drv-wacom available on past Fedora release > (Moonshine version comes in mind)? No. xorg-x11-drv-wacom is a new package that will obsolete linuxwacom. -- Jarod Wilson jarod at redhat.com From sundaram at fedoraproject.org Tue Nov 10 03:15:37 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 10 Nov 2009 08:45:37 +0530 Subject: Status of HAL In-Reply-To: <4717.97.124.130.31.1257822798.squirrel@www.cora.nwra.com> References: <20091109202844.GA29552@nostromo.devel.redhat.com> <4717.97.124.130.31.1257822798.squirrel@www.cora.nwra.com> Message-ID: <4AF8DAD9.3070403@fedoraproject.org> On 11/10/2009 08:43 AM, Orion Poplawski wrote: > > On Mon, November 9, 2009 1:28 pm, Bill Nottingham wrote: >> - It's so deprecated that one of its replacements (HAL) has since been >> frozen and deprecated > > Okay, I really can't keep up with Linux development these days. What has > replaced HAL? It hasn't yet but DeviceKit will over a period of time. Rahul From mzerqung at 0pointer.de Tue Nov 10 03:25:28 2009 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 10 Nov 2009 04:25:28 +0100 Subject: Status of HAL In-Reply-To: <4AF8DAD9.3070403@fedoraproject.org> References: <20091109202844.GA29552@nostromo.devel.redhat.com> <4717.97.124.130.31.1257822798.squirrel@www.cora.nwra.com> <4AF8DAD9.3070403@fedoraproject.org> Message-ID: <20091110032528.GA22395@tango.0pointer.de> On Tue, 10.11.09 08:45, Rahul Sundaram (sundaram at fedoraproject.org) wrote: > > On 11/10/2009 08:43 AM, Orion Poplawski wrote: > > > > On Mon, November 9, 2009 1:28 pm, Bill Nottingham wrote: > >> - It's so deprecated that one of its replacements (HAL) has since been > >> frozen and deprecated > > > > Okay, I really can't keep up with Linux development these days. What has > > replaced HAL? > > It hasn't yet but DeviceKit will over a period of time. There is no such thing as "DeviceKit" (anymore), there are only two independant projects DeviceKit-power and DeviceKit-disks. Most other things the old HAL did have been migrated into various other packages, such as udev/libudev and more. The Ubuntu folks have a nice overview of what moved where and how things were updated: https://wiki.ubuntu.com/Halsectomy Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mclasen at redhat.com Tue Nov 10 03:26:22 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 09 Nov 2009 22:26:22 -0500 Subject: Status of HAL In-Reply-To: <4AF8DAD9.3070403@fedoraproject.org> References: <20091109202844.GA29552@nostromo.devel.redhat.com> <4717.97.124.130.31.1257822798.squirrel@www.cora.nwra.com> <4AF8DAD9.3070403@fedoraproject.org> Message-ID: <1257823582.2002.23.camel@planemask> On Tue, 2009-11-10 at 08:45 +0530, Rahul Sundaram wrote: > On 11/10/2009 08:43 AM, Orion Poplawski wrote: > > > > On Mon, November 9, 2009 1:28 pm, Bill Nottingham wrote: > >> - It's so deprecated that one of its replacements (HAL) has since been > >> frozen and deprecated > > > > Okay, I really can't keep up with Linux development these days. What has > > replaced HAL? > > It hasn't yet but DeviceKit will over a period of time. You can't keep up either :-) There is no DeviceKit package anymore; the central role has been taken over by udev, mostly. And then there are subsystem-specific services, like DeviceKit-disks, DeviceKit-power, NetworkManager, etc. From sundaram at fedoraproject.org Tue Nov 10 03:29:54 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 10 Nov 2009 08:59:54 +0530 Subject: Status of HAL In-Reply-To: <20091110032528.GA22395@tango.0pointer.de> References: <20091109202844.GA29552@nostromo.devel.redhat.com> <4717.97.124.130.31.1257822798.squirrel@www.cora.nwra.com> <4AF8DAD9.3070403@fedoraproject.org> <20091110032528.GA22395@tango.0pointer.de> Message-ID: <4AF8DE32.50804@fedoraproject.org> On 11/10/2009 08:55 AM, Lennart Poettering wrote: > On Tue, 10.11.09 08:45, Rahul Sundaram (sundaram at fedoraproject.org) wrote: > >> >> On 11/10/2009 08:43 AM, Orion Poplawski wrote: >>> >>> On Mon, November 9, 2009 1:28 pm, Bill Nottingham wrote: >>>> - It's so deprecated that one of its replacements (HAL) has since been >>>> frozen and deprecated >>> >>> Okay, I really can't keep up with Linux development these days. What has >>> replaced HAL? >> >> It hasn't yet but DeviceKit will over a period of time. > > There is no such thing as "DeviceKit" (anymore), there are only two > independant projects DeviceKit-power and DeviceKit-disks. Yes, I am aware. I assumed the umbrella effort is still called DeviceKit. I guess not. Rahul From bruno at wolff.to Tue Nov 10 04:26:50 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 9 Nov 2009 22:26:50 -0600 Subject: Fedora 12 has gone gold In-Reply-To: <1257819719.2452.75.camel@localhost.localdomain> References: <1257816570.2468.32.camel@localhost.localdomain> <1257819719.2452.75.camel@localhost.localdomain> Message-ID: <20091110042650.GA11310@wolff.to> On Tue, Nov 10, 2009 at 13:21:59 +1100, Rodd Clarkson wrote: > > Over the development cycle I couldn't get my system to boot, then I > couldn't get X running, and then I couldn't keep it running and finally > the ATI issues I and others were having were resolved. I think it is huge that the video guys got stuff worked out in time for the release. Working native 3d for ATI and Intel is going to make a much better impression than what we have had the last few releases. From sundaram at fedoraproject.org Tue Nov 10 04:25:03 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 10 Nov 2009 09:55:03 +0530 Subject: Fedora 12 has gone gold In-Reply-To: <20091110042650.GA11310@wolff.to> References: <1257816570.2468.32.camel@localhost.localdomain> <1257819719.2452.75.camel@localhost.localdomain> <20091110042650.GA11310@wolff.to> Message-ID: <4AF8EB1F.5080007@fedoraproject.org> On 11/10/2009 09:56 AM, Bruno Wolff III wrote: > On Tue, Nov 10, 2009 at 13:21:59 +1100, > Rodd Clarkson wrote: >> >> Over the development cycle I couldn't get my system to boot, then I >> couldn't get X running, and then I couldn't keep it running and finally >> the ATI issues I and others were having were resolved. > > I think it is huge that the video guys got stuff worked out in time for > the release. Working native 3d for ATI and Intel is going to make a much > better impression than what we have had the last few releases. Hopefully Nouveau gets 3D support within a couple of releases as well. Getting rid of the biggest pain of proprietary drivers would be one giant step forward for Linux on the desktop. Rahul From bruno at wolff.to Tue Nov 10 04:39:23 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 9 Nov 2009 22:39:23 -0600 Subject: Fedora 12 has gone gold In-Reply-To: <4AF8EB1F.5080007@fedoraproject.org> References: <1257816570.2468.32.camel@localhost.localdomain> <1257819719.2452.75.camel@localhost.localdomain> <20091110042650.GA11310@wolff.to> <4AF8EB1F.5080007@fedoraproject.org> Message-ID: <20091110043923.GC11310@wolff.to> On Tue, Nov 10, 2009 at 09:55:03 +0530, Rahul Sundaram wrote: > > Hopefully Nouveau gets 3D support within a couple of releases as well. > Getting rid of the biggest pain of proprietary drivers would be one > giant step forward for Linux on the desktop. Yeah. While I wouldn't go out and buy nvidia cards I have a couple in systems I got as scrap and it would be nice to have 3d on them. I don't trust the nvidia stuff not to screw things up for helping test the nouveau drivers, so I have been stuck with only 2d support for a good chunk of F12's development. The nouveau guys have made a surprising amount of progress and I think there is a good chance they will have good 3d support 2 or 3 releases down the road. (Though I would like to see Red Hat help out more to cut this to 1 or 2 releases, since I think the current situation hurts Fedora.) I'd also like to see people move away from Cg and use the free and more portable equivalents. From inode0 at gmail.com Tue Nov 10 02:05:02 2009 From: inode0 at gmail.com (inode0) Date: Mon, 9 Nov 2009 20:05:02 -0600 Subject: F13 Naming: Leonidas -> Constantine -> ? Message-ID: With Fedora 12 just a few days from release it is time to begin the naming process for the next Fedora release. Contributors can make suggestions for the name for Fedora 13 by visiting https://fedoraproject.org/wiki/Name_suggestions_for_Fedora_13 and following the instructions. Remember there needs to be an "is-a" link between the name Constantine and the name you suggest and this link must be different than all previous links used to connect Fedora release names. Full details of the release naming schedule are available on the above link but please note than the period for gathering suggestions begins now and runs through November 16. So there isn't a lot of time, think up some good names, and get them added to the wiki. Have fun, John _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From poelstra at redhat.com Tue Nov 10 05:20:35 2009 From: poelstra at redhat.com (John Poelstra) Date: Mon, 09 Nov 2009 21:20:35 -0800 Subject: Final Fedora 12 Schedule Tasks Message-ID: <4AF8F823.4050007@redhat.com> Start End Name Wed 04-Nov Wed 11-Nov Test RC Mon 09-Nov Mon 09-Nov F12 Blocker Review (go/no go) 3 PM EDT Wed 11-Nov Wed 11-Nov F12 Project Wide Release Readiness Meeting Thu 12-Nov Thu 12-Nov Start Stage & Sync RC to Mirrors Thu 12-Nov Tue 17-Nov Stage & Sync RC to Mirrors Fri 13-Nov Fri 13-Nov Final Export Control Reporting Tue 17-Nov Tue 17-Nov GA Release From awilliam at redhat.com Tue Nov 10 07:15:56 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 09 Nov 2009 23:15:56 -0800 Subject: intent to retire: kudzu In-Reply-To: <20091109202844.GA29552@nostromo.devel.redhat.com> References: <20091109202844.GA29552@nostromo.devel.redhat.com> Message-ID: <1257837356.2467.9.camel@adam.local.net> On Mon, 2009-11-09 at 15:28 -0500, Bill Nottingham wrote: > I'd like to retire kudzu for F-13. > > Why? > - There are places where it almost certainly does not work with current kernels > - It's so deprecated that one of its replacements (HAL) has since been > frozen and deprecated > - Given that, its upstream is very dead > > However, it is still being required by two programs: > - hwbrowser > - fwfstab > > If someone wants to keep it limping along for thsese two programs I can > orphan it. But I'd really rather just retire it. It appears that system-config-network 's dependency on kudzu may have been incorrectly dropped: https://www.redhat.com/archives/fedora-test-list/2009-November/msg00456.html without it, s-c-n cannot handle modem connections, it looks like. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From stickster at gmail.com Tue Nov 10 07:33:41 2009 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 10 Nov 2009 17:33:41 +1000 Subject: Fedora 12 has gone gold In-Reply-To: <20091110043923.GC11310@wolff.to> References: <1257816570.2468.32.camel@localhost.localdomain> <1257819719.2452.75.camel@localhost.localdomain> <20091110042650.GA11310@wolff.to> <4AF8EB1F.5080007@fedoraproject.org> <20091110043923.GC11310@wolff.to> Message-ID: <20091110073341.GB5774@victoria.internal.frields.org> On Mon, Nov 09, 2009 at 10:39:23PM -0600, Bruno Wolff III wrote: > On Tue, Nov 10, 2009 at 09:55:03 +0530, > Rahul Sundaram wrote: > > > > Hopefully Nouveau gets 3D support within a couple of releases as well. > > Getting rid of the biggest pain of proprietary drivers would be one > > giant step forward for Linux on the desktop. > > Yeah. While I wouldn't go out and buy nvidia cards I have a couple in systems > I got as scrap and it would be nice to have 3d on them. I don't trust the > nvidia stuff not to screw things up for helping test the nouveau drivers, > so I have been stuck with only 2d support for a good chunk of F12's > development. > > The nouveau guys have made a surprising amount of progress and I think there > is a good chance they will have good 3d support 2 or 3 releases down the road. > (Though I would like to see Red Hat help out more to cut this to 1 or 2 > releases, since I think the current situation hurts Fedora.) I'd also > like to see people move away from Cg and use the free and more portable > equivalents. I had the good fortune to meet Ben Skeggs, a nouveau developer at Red Hat's Brisbane office, and tell him how effective some of his work has been so far. (I have a laptop with NVidia, not by choice but through a weird set of circumstances you can find on my blog from last year.) I have full KMS now on this laptop, and while there's no 3D yet, I still managed to surprise a bunch of people here in Brisbane by plugging my laptop into an external LCD TV, and having it just work. I used this as a great example of how 6 months in Fedora-land can bring a lot of changes. By the way, I also met Dave Airlie and told him my r770-based ATI card was also rocking, with the added bonus of 3D support. I'm really happy with the progress in F12 and I hope other people enjoy it too! -- 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 From markmc at redhat.com Tue Nov 10 07:50:19 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 10 Nov 2009 07:50:19 +0000 Subject: odd file requires In-Reply-To: References: Message-ID: <1257839419.2888.15.camel@blaa> On Mon, 2009-11-09 at 11:58 -0500, Seth Vidal wrote: > Hey folks, > I put together this list for things I'd like to work on for f13. It's a > list of packages with a file-requires that falls outside of *bin/* and > /etc/* and then the provider(s) for those files. > > http://skvidal.fedorapeople.org/misc/non-primary-file-reqs-and-what-requires-them.txt > > I've gone through some of them and I'm looking for where we can clean up a > few more. > > Take a look through, see if you see a package you're responsible for and, > if you can, figure out a way to not need the file-requires. > > this helps our users b/c if we don't need to get the filelists to resolve > the dependency then they don't use up the bandwidth. The qemu/gpxe-roms-qemu ones were added because we were moving a file from gpxe-roms to gpxe-roms-qemu. Leaving it as a package requires means hard-coding knowledge in qemu about which version of gpxe-roms-qemu provides which roms. IMHO, the file requires makes more sense. Cheers, Mark. From mike.cloaked at gmail.com Tue Nov 10 08:59:59 2009 From: mike.cloaked at gmail.com (Mike Cloaked) Date: Tue, 10 Nov 2009 08:59:59 +0000 (UTC) Subject: A question about allow_unconfined_mmap_low in f11 amd selinux References: <3b8e57a80911040723x280abfd0jf6bab04bf4803390@mail.gmail.com> <4AF1A2C5.8010008@redhat.com> <1257787051.2994.22.camel@dhcp231-106.rdu.redhat.com> <4AF8888A.4040703@redhat.com> Message-ID: Daniel J Walsh redhat.com> writes: > > definitely still getting the error with any Wine application with > > mmap_low_allowed set to 0. > > > > selinux-policy-3.6.32-41.fc12.noarch > > > The name has changed between RHEL5 - allow_unconfined_mmap_low > and F12 - mmap_low_allowed > > The meaning has also changed > > in RHEL5 > > unconfined domains are allowed to mmap_low if the boolean is set. vbetool > and wine are allowed whether or > not the boolean is set. > > In F12 > No domains are allowed to mmap_low unless the boolean is set. If it is > set wine, vbetool and unconfined > domains are allowed to mmap_zero. > > One of you is running wine in RHEL5 which is allowed to mmap_zero without > the boolean. We changed this in F12 > so that wine will break without the boolean set. Thank you for that clarification Dan. By the way I entered a private ticket at the Crossover site (hence not publicly visible), and have been told that their devs are currently already looking at this issue to try to see if the problem can be worked around in a new version of Crossover, which will presumably also be made available to newer versions of wine if a solution can be found. From rakesh.pandit at gmail.com Tue Nov 10 09:09:55 2009 From: rakesh.pandit at gmail.com (Rakesh Pandit) Date: Tue, 10 Nov 2009 14:39:55 +0530 Subject: Package Review Stats for last 7 days ending 8th Nov Message-ID: Top three FAS account holders who have completed reviewing "Package review" components on bugzilla for last 7 days ending 8th Nov were Nicolas Mailhot, Steve Traylen and Parag AN(????). Nicolas Mailhot : 7 https://bugzilla.redhat.com/show_bug.cgi?id=532231 https://bugzilla.redhat.com/show_bug.cgi?id=532816 https://bugzilla.redhat.com/show_bug.cgi?id=532817 https://bugzilla.redhat.com/show_bug.cgi?id=532818 https://bugzilla.redhat.com/show_bug.cgi?id=532819 https://bugzilla.redhat.com/show_bug.cgi?id=530880 https://bugzilla.redhat.com/show_bug.cgi?id=532368 Steve Traylen : 5 https://bugzilla.redhat.com/show_bug.cgi?id=516517 https://bugzilla.redhat.com/show_bug.cgi?id=516522 https://bugzilla.redhat.com/show_bug.cgi?id=516527 https://bugzilla.redhat.com/show_bug.cgi?id=516532 https://bugzilla.redhat.com/show_bug.cgi?id=516534 Parag AN(????) : 4 https://bugzilla.redhat.com/show_bug.cgi?id=516280 https://bugzilla.redhat.com/show_bug.cgi?id=531988 https://bugzilla.redhat.com/show_bug.cgi?id=532677 https://bugzilla.redhat.com/show_bug.cgi?id=533141 Jason Tibbitts : 3 https://bugzilla.redhat.com/show_bug.cgi?id=502991 https://bugzilla.redhat.com/show_bug.cgi?id=522777 https://bugzilla.redhat.com/show_bug.cgi?id=501958 Mamoru Tasaka : 3 https://bugzilla.redhat.com/show_bug.cgi?id=530204 https://bugzilla.redhat.com/show_bug.cgi?id=531391 https://bugzilla.redhat.com/show_bug.cgi?id=527488 Andrew Colin Kissa : 2 https://bugzilla.redhat.com/show_bug.cgi?id=525432 https://bugzilla.redhat.com/show_bug.cgi?id=526876 Jon Ciesla : 2 https://bugzilla.redhat.com/show_bug.cgi?id=532635 https://bugzilla.redhat.com/show_bug.cgi?id=526651 Lubomir Rintel : 2 https://bugzilla.redhat.com/show_bug.cgi?id=532315 https://bugzilla.redhat.com/show_bug.cgi?id=508521 Xavier Bachelot : 2 https://bugzilla.redhat.com/show_bug.cgi?id=532699 https://bugzilla.redhat.com/show_bug.cgi?id=524238 Alan Pevec : 1 https://bugzilla.redhat.com/show_bug.cgi?id=507697 Andrew Overholt : 1 https://bugzilla.redhat.com/show_bug.cgi?id=532057 Christof Damian : 1 https://bugzilla.redhat.com/show_bug.cgi?id=529073 Christoph Wickert : 1 https://bugzilla.redhat.com/show_bug.cgi?id=532779 Dennis Gilmore : 1 https://bugzilla.redhat.com/show_bug.cgi?id=521983 Jan Klepek : 1 https://bugzilla.redhat.com/show_bug.cgi?id=525914 Jon Stanley : 1 https://bugzilla.redhat.com/show_bug.cgi?id=523343 Jussi Lehtola : 1 https://bugzilla.redhat.com/show_bug.cgi?id=507030 Orcan 'oget' Ogetbil : 1 https://bugzilla.redhat.com/show_bug.cgi?id=529283 Peter Lemenkov : 1 https://bugzilla.redhat.com/show_bug.cgi?id=533075 Rahul Sundaram : 1 https://bugzilla.redhat.com/show_bug.cgi?id=512170 Ruben Kerkhof : 1 https://bugzilla.redhat.com/show_bug.cgi?id=531912 Steve Whitehouse : 1 https://bugzilla.redhat.com/show_bug.cgi?id=507106 Thomas Spura : 1 https://bugzilla.redhat.com/show_bug.cgi?id=526564 Total reviews modified: 44 Merge Reviews: 1 Review Requests: 43 This report by generated by bzReviewReport.py. The source is available at: https://fedorahosted.org/triage/browser/scripts/bzReviewReport.py Please submit patches or bug reports at: https://fedorahosted.org/triage/ -- Rakesh Pandit https://fedoraproject.org/ freedom, friends, features, first From kevin.kofler at chello.at Tue Nov 10 10:01:54 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 10 Nov 2009 11:01:54 +0100 Subject: odd file requires References: <1257839419.2888.15.camel@blaa> Message-ID: Mark McLoughlin wrote: > Leaving it as a package requires means hard-coding knowledge in qemu > about which version of gpxe-roms-qemu provides which roms. IMHO, the > file requires makes more sense. So what? Many packages have hardcoded Requires >= EVR for such things. Kevin Kofler From rakesh at fedoraproject.org Tue Nov 10 10:27:44 2009 From: rakesh at fedoraproject.org (Rakesh Pandit) Date: Tue, 10 Nov 2009 15:57:44 +0530 Subject: pushing 3.12.0 to rawhide: freeimage In-Reply-To: References: Message-ID: 2009/9/23 Rakesh Pandit wrote: > On 09/23/2009 02:50 PM, Nicolas Chauvet wrote: >> 2009/9/23 Rakesh Pandit wrote: >>> I will be pushing freeimage 3.12.0 to rawhide and following >>> dependencies will need a bump to consume it. I will probably be >>> bumping them myself unless someone does it before me. Just *rawhide* . >> Thx for the warning ! >> Can you provide the current wip version of the src.rpm ? >> >> Now I cannot rememember the beta freeze period, but I will request to >> wait for the unfreeze unless it is "far enought" >> > > I was just planning for rawhide. Still I will wait some time (till > deadlines are gone) and post you details once I am done. > [..] Now seems to be right time for f13 fotoxx PerceptualDiff posterazor phoronix-test-suite ogre will need a rebuild. In case everyone is okay I will start doing it in few days ? -- Rakesh Pandit https://fedoraproject.org/ freedom, friends, features, first From mike.cloaked at gmail.com Tue Nov 10 10:36:32 2009 From: mike.cloaked at gmail.com (Mike Cloaked) Date: Tue, 10 Nov 2009 10:36:32 +0000 (UTC) Subject: A question about allow_unconfined_mmap_low in f11 amd selinux References: <3b8e57a80911040723x280abfd0jf6bab04bf4803390@mail.gmail.com> <4AF1A2C5.8010008@redhat.com> <1257787051.2994.22.camel@dhcp231-106.rdu.redhat.com> <4AF8888A.4040703@redhat.com> Message-ID: Daniel J Walsh redhat.com> writes: > The name has changed between RHEL5 - allow_unconfined_mmap_low and F12 - mmap_low_allowed > > The meaning has also changed > > in RHEL5 > > unconfined domains are allowed to mmap_low if the boolean is set. vbetool > and wine are allowed whether or > not the boolean is set. > > In F12 > No domains are allowed to mmap_low unless the boolean is set. If it is > set wine, vbetool and unconfined > domains are allowed to mmap_zero. > > One of you is running wine in RHEL5 which is allowed to mmap_zero without > the boolean. We changed this in F12 > so that wine will break without the boolean set. There is an interesting thing I just found - in F11 without the bool set I can run MS Word 2003 in Crossover (i.e. effectively wine) and open a .doc file without any AVC popping up. However from a webmail interface opened in Firefox, and clicking on a .doc attachment, trying to open it via an association link to Word 2003 in Crossover immediately gives an AVC denial for wine-preloader and suggests allowing the bool! However the file does seem to open nevertheless!! From rawhide at fedoraproject.org Tue Nov 10 12:18:53 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Tue, 10 Nov 2009 12:18:53 +0000 Subject: rawhide report: 20091110 changes Message-ID: <20091110121853.GA19543@releng2.fedora.phx.redhat.com> Compose started at Tue Nov 10 08:15:09 UTC 2009 Updated Packages: gnome-do-0.8.2-4.fc12 --------------------- * Tue Nov 10 2009 Tom "spot" Callaway - 0.8.2-4 - Remove "Docky" due to patent issues Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 1 From mschwendt at gmail.com Tue Nov 10 12:45:01 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 10 Nov 2009 13:45:01 +0100 Subject: odd file requires In-Reply-To: References: <1257839419.2888.15.camel@blaa> Message-ID: <20091110134501.4e488ef4@faldor.intranet> On Tue, 10 Nov 2009 11:01:54 +0100, Kevin wrote: > Mark McLoughlin wrote: > > Leaving it as a package requires means hard-coding knowledge in qemu > > about which version of gpxe-roms-qemu provides which roms. IMHO, the > > file requires makes more sense. > > So what? Many packages have hardcoded Requires >= EVR for such things. And if you don't like to require package names, you could add your own "Provides" to the packages for capabilities such as ROM images. With the added benefit that you could apply versions to those capabilities, which is not possible with file dependencies. From mail at robertoragusa.it Tue Nov 10 13:10:03 2009 From: mail at robertoragusa.it (Roberto Ragusa) Date: Tue, 10 Nov 2009 14:10:03 +0100 Subject: Fedora 12 has gone gold In-Reply-To: <4AF8EB1F.5080007@fedoraproject.org> References: <1257816570.2468.32.camel@localhost.localdomain> <1257819719.2452.75.camel@localhost.localdomain> <20091110042650.GA11310@wolff.to> <4AF8EB1F.5080007@fedoraproject.org> Message-ID: <4AF9662B.8090001@robertoragusa.it> Rahul Sundaram wrote: > > Hopefully Nouveau gets 3D support within a couple of releases as well. > Getting rid of the biggest pain of proprietary drivers would be one > giant step forward for Linux on the desktop. It would be wonderful. Sometimes you have no choice for the hardware; if you get the wrong laptop, bad luck. For my job, I got an ATI thinkpad when ATI was not open. Now that ATI is open, bad luck gave me an NVidia. I'm sure Noveau will make great progress and in the mean time I will be assigned an Intel one (the new bad ones). :-) -- Roberto Ragusa mail at robertoragusa.it From jeff at ocjtech.us Tue Nov 10 15:24:21 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Tue, 10 Nov 2009 09:24:21 -0600 Subject: Problems reporting crashes with ABRT Message-ID: <935ead450911100724k5b5860f5n9236fa022dcf82f4@mail.gmail.com> ABRT has detected a couple of crashes recently, but has been unable to create bugs in Bugzilla. It makes an attempt, but fails with the message: XML-RPC Fault: libcurl failed to execute the HTTP POST transaction. I've verified that I've configured ABRT with the correct bugzilla username and password. Any hints on what my problem could be? -- Jeff Ollie From npajkovs at redhat.com Tue Nov 10 15:33:41 2009 From: npajkovs at redhat.com (Nikola Pajkovsky) Date: Tue, 10 Nov 2009 16:33:41 +0100 Subject: Problems reporting crashes with ABRT In-Reply-To: <935ead450911100724k5b5860f5n9236fa022dcf82f4@mail.gmail.com> References: <935ead450911100724k5b5860f5n9236fa022dcf82f4@mail.gmail.com> Message-ID: <4AF987D5.4040006@redhat.com> Dne 10.11.2009 16:24, Jeffrey Ollie napsal(a): > ABRT has detected a couple of crashes recently, but has been unable to > create bugs in Bugzilla. It makes an attempt, but fails with the > message: > > XML-RPC Fault: libcurl failed to execute the HTTP POST transaction. > > I've verified that I've configured ABRT with the correct bugzilla > username and password. Any hints on what my problem could be? > It helps you restart deamon for now. We have fix in git and it will be in new release. See: https://bugzilla.redhat.com/show_bug.cgi?id=531978#c5 -- Nikola Pajkovsky .~. Base Operating Systems Brno /V\ // \\ Jabber: nikis at isgeek.info /( )\ Mobile: +420 777 895 064 ^`~'^ From jeff at ocjtech.us Tue Nov 10 15:39:52 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Tue, 10 Nov 2009 09:39:52 -0600 Subject: Problems reporting crashes with ABRT In-Reply-To: <4AF987D5.4040006@redhat.com> References: <935ead450911100724k5b5860f5n9236fa022dcf82f4@mail.gmail.com> <4AF987D5.4040006@redhat.com> Message-ID: <935ead450911100739n7b41c51ftaca7b926c4382f29@mail.gmail.com> On Tue, Nov 10, 2009 at 9:33 AM, Nikola Pajkovsky wrote: > Dne 10.11.2009 16:24, Jeffrey Ollie napsal(a): >> >> ABRT has detected a couple of crashes recently, but has been unable to >> create bugs in Bugzilla. ?It makes an attempt, but fails with the >> message: >> >> ? ?XML-RPC Fault: libcurl failed to execute the HTTP POST transaction. >> >> I've verified that I've configured ABRT with the correct bugzilla >> username and password. ?Any hints on what my problem could be? > > It helps you restart deamon for now. We have fix in git and it will be in > new release. > > See: > ? ?https://bugzilla.redhat.com/show_bug.cgi?id=531978#c5 Yup, that fixed it, thanks! -- Jeff Ollie From bjorn at xn--rombobjrn-67a.se Tue Nov 10 15:45:08 2009 From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=) Date: Tue, 10 Nov 2009 16:45:08 +0100 Subject: F13 Naming: Leonidas -> Constantine -> ? In-Reply-To: References: Message-ID: <200911101645.08237.bjorn@xn--rombobjrn-67a.se> inode0 wrote: > With Fedora 12 just a few days from release it is time to begin the > naming process for the next Fedora release. After F12 comes Print Screen of course. ;-) Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From bnocera at redhat.com Tue Nov 10 15:52:14 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 10 Nov 2009 15:52:14 +0000 Subject: F13 Naming: Leonidas -> Constantine -> ? In-Reply-To: <200911101645.08237.bjorn@xn--rombobjrn-67a.se> References: <200911101645.08237.bjorn@xn--rombobjrn-67a.se> Message-ID: <1257868335.10888.1496.camel@localhost.localdomain> On Tue, 2009-11-10 at 16:45 +0100, Bj?rn Persson wrote: > inode0 wrote: > > With Fedora 12 just a few days from release it is time to begin the > > naming process for the next Fedora release. > > After F12 comes Print Screen of course. ;-) Depending on the keyboards I look at, I have "Insert", "Eject" and "Mute" after F12 ;) From fulko.hew at gmail.com Tue Nov 10 15:58:21 2009 From: fulko.hew at gmail.com (Fulko Hew) Date: Tue, 10 Nov 2009 10:58:21 -0500 Subject: F13 Naming: Leonidas -> Constantine -> ? In-Reply-To: <1257868335.10888.1496.camel@localhost.localdomain> References: <200911101645.08237.bjorn@xn--rombobjrn-67a.se> <1257868335.10888.1496.camel@localhost.localdomain> Message-ID: <8204a4fe0911100758v6491cbf7jd6d9f68468d1de5@mail.gmail.com> On Tue, Nov 10, 2009 at 10:52 AM, Bastien Nocera wrote: > On Tue, 2009-11-10 at 16:45 +0100, Bj?rn Persson wrote: > > inode0 wrote: > > > With Fedora 12 just a few days from release it is time to begin the > > > naming process for the next Fedora release. > > > > After F12 comes Print Screen of course. ;-) > > Depending on the keyboards I look at, I have "Insert", "Eject" and > "Mute" after F12 ;) > Ahhh, having choices is always good! After F12 _I_ have: Delete, End and Page Down. :-) (Sorry for adding to the noise, but its a 'slow news day'.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From inode0 at gmail.com Tue Nov 10 15:42:42 2009 From: inode0 at gmail.com (inode0) Date: Tue, 10 Nov 2009 09:42:42 -0600 Subject: Nominations now open for December Fedora Elections Message-ID: It is time to begin the process of nominating candidates for the open seats in the following bodies: * Fedora Project Board * Fedora Ambassadors Steering Committee (FAmSCo) * Fedora Engineering Steering Committee (FESCo) General Election Schedule: * November 10-16: Nominations are open. * November 17-23: Candidate questionnaires. * November 27 - December 3: IRC Town Hall-style discussions with candidates for the various elected positions will be arranged. * December 8-15: The elections will take place. Nominations You may self-nominate. If you wish to nominate someone else, please consult with that person ahead of time. Wiki nomination pages [1] carry additional details about the nominee which the nominee is expected to write. Simply update the respective wiki page with your nomination information. Please thoughtfully consider how you can best contribute to Fedora by serving on one of these important committees or by encouraging someone you know who you think can make a difference to serve. [1] https://fedoraproject.org/wiki/Elections Thanks, John _______________________________________________ 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 Tue Nov 10 16:03:02 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 10 Nov 2009 11:03:02 -0500 Subject: conflict between seedit <-> selinux-policy and qstat <-> torque-client In-Reply-To: <4AF89983.1050300@redhat.com> References: <4AF19437.9020702@redhat.com> <20091104183836.GC11436@nostromo.devel.redhat.com> <4AF89983.1050300@redhat.com> Message-ID: <20091110160302.GE8990@nostromo.devel.redhat.com> Daniel J Walsh (dwalsh at redhat.com) said: > On 11/04/2009 01:38 PM, Bill Nottingham wrote: > >> Because seedit getting installed causes selinux-policy-targeted and friends to get screwed up. > > > > That sounds like a reason to not ship seedit. Am I missing something? > > > > Bill > > > I would not ship it. Is there a schedule for when seedit will be able to function in a non-destructive mode? Bill From jkeating at redhat.com Tue Nov 10 16:02:15 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 10 Nov 2009 08:02:15 -0800 Subject: F13 Naming: Leonidas -> Constantine -> ? In-Reply-To: <200911101645.08237.bjorn@xn--rombobjrn-67a.se> References: <200911101645.08237.bjorn@xn--rombobjrn-67a.se> Message-ID: <1257868935.2468.51.camel@localhost.localdomain> On Tue, 2009-11-10 at 16:45 +0100, Bj?rn Persson wrote: > > After F12 comes Print Screen of course. ;-) My keyboard has F13 next... -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From cdahlin at redhat.com Tue Nov 10 16:17:43 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Tue, 10 Nov 2009 11:17:43 -0500 Subject: F13 Naming: Leonidas -> Constantine -> ? In-Reply-To: <8204a4fe0911100758v6491cbf7jd6d9f68468d1de5@mail.gmail.com> References: <200911101645.08237.bjorn@xn--rombobjrn-67a.se> <1257868335.10888.1496.camel@localhost.localdomain> <8204a4fe0911100758v6491cbf7jd6d9f68468d1de5@mail.gmail.com> Message-ID: <4AF99227.9060305@redhat.com> On 11/10/2009 10:58 AM, Fulko Hew wrote: > > > On Tue, Nov 10, 2009 at 10:52 AM, Bastien Nocera > wrote: > > On Tue, 2009-11-10 at 16:45 +0100, Bj?rn Persson wrote: > > inode0 wrote: > > > With Fedora 12 just a few days from release it is time to begin the > > > naming process for the next Fedora release. > > > > After F12 comes Print Screen of course. ;-) > > Depending on the keyboards I look at, I have "Insert", "Eject" and > "Mute" after F12 ;) > > > Ahhh, having choices is always good! > > After F12 _I_ have: Delete, End and Page Down. :-) > > (Sorry for adding to the noise, but its a 'slow news day'.) > I have a big badge that says Dell...???!!! --CJD From cmadams at hiwaay.net Tue Nov 10 16:18:39 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 10 Nov 2009 10:18:39 -0600 Subject: F13 Naming: Leonidas -> Constantine -> ? In-Reply-To: <1257868935.2468.51.camel@localhost.localdomain> References: <200911101645.08237.bjorn@xn--rombobjrn-67a.se> <1257868935.2468.51.camel@localhost.localdomain> Message-ID: <20091110161839.GE1536917@hiwaay.net> Once upon a time, Jesse Keating said: > On Tue, 2009-11-10 at 16:45 +0100, Bj??rn Persson wrote: > > After F12 comes Print Screen of course. ;-) > > My keyboard has F13 next... The One True Keyboard(tm) (IBM Model M) has Print Screen/SysRq there. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From awilliam at redhat.com Tue Nov 10 16:54:26 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 10 Nov 2009 08:54:26 -0800 Subject: Fedora 12 has gone gold In-Reply-To: <4AF8EB1F.5080007@fedoraproject.org> References: <1257816570.2468.32.camel@localhost.localdomain> <1257819719.2452.75.camel@localhost.localdomain> <20091110042650.GA11310@wolff.to> <4AF8EB1F.5080007@fedoraproject.org> Message-ID: <1257872066.2467.87.camel@adam.local.net> On Tue, 2009-11-10 at 09:55 +0530, Rahul Sundaram wrote: > Hopefully Nouveau gets 3D support within a couple of releases as well. Ben says to send beer. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From sundaram at fedoraproject.org Tue Nov 10 16:51:26 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 10 Nov 2009 22:21:26 +0530 Subject: Fedora 12 has gone gold In-Reply-To: <1257872066.2467.87.camel@adam.local.net> References: <1257816570.2468.32.camel@localhost.localdomain> <1257819719.2452.75.camel@localhost.localdomain> <20091110042650.GA11310@wolff.to> <4AF8EB1F.5080007@fedoraproject.org> <1257872066.2467.87.camel@adam.local.net> Message-ID: <4AF99A0E.8010604@fedoraproject.org> On 11/10/2009 10:24 PM, Adam Williamson wrote: > On Tue, 2009-11-10 at 09:55 +0530, Rahul Sundaram wrote: > >> Hopefully Nouveau gets 3D support within a couple of releases as well. > > Ben says to send beer. :) That would one hot beer if it travels all that way. Rahul From poelstra at redhat.com Tue Nov 10 17:02:52 2009 From: poelstra at redhat.com (John Poelstra) Date: Tue, 10 Nov 2009 09:02:52 -0800 Subject: Fedora 12 has gone gold In-Reply-To: <1257816570.2468.32.camel@localhost.localdomain> References: <1257816570.2468.32.camel@localhost.localdomain> Message-ID: <4AF99CBC.6060501@redhat.com> On 11/09/2009 05:29 PM, Jesse Keating wrote: > We have just completed our Go / No Go meeting for Fedora 12 and have > reached the decision to Go. Fedora 12's package set is golden and we're > ready to stage things for shipping. Great work all around, I'm very My impressions from this meeting were slightly different :-) We noted that there are no known reasons that we are "not go" and that we will continue testing until Wednesday when QA expects to have completed the testing matrix. Maybe we are separated by semantics, but "gone gold" or "completely done" was not an impression I left the meeting with. http://meetbot.fedoraproject.org/fedora-meeting/2009-11-10/fedora-meeting.2009-11-10-01.01.log.html John From inode0 at gmail.com Tue Nov 10 15:42:42 2009 From: inode0 at gmail.com (inode0) Date: Tue, 10 Nov 2009 09:42:42 -0600 Subject: Nominations now open for December Fedora Elections Message-ID: It is time to begin the process of nominating candidates for the open seats in the following bodies: * Fedora Project Board * Fedora Ambassadors Steering Committee (FAmSCo) * Fedora Engineering Steering Committee (FESCo) General Election Schedule: * November 10-16: Nominations are open. * November 17-23: Candidate questionnaires. * November 27 - December 3: IRC Town Hall-style discussions with candidates for the various elected positions will be arranged. * December 8-15: The elections will take place. Nominations You may self-nominate. If you wish to nominate someone else, please consult with that person ahead of time. Wiki nomination pages [1] carry additional details about the nominee which the nominee is expected to write. Simply update the respective wiki page with your nomination information. Please thoughtfully consider how you can best contribute to Fedora by serving on one of these important committees or by encouraging someone you know who you think can make a difference to serve. [1] https://fedoraproject.org/wiki/Elections Thanks, John -- fedora-announce-list mailing list fedora-announce-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From deadbabylon at googlemail.com Tue Nov 10 17:22:54 2009 From: deadbabylon at googlemail.com (Sebastian Vahl) Date: Tue, 10 Nov 2009 18:22:54 +0100 Subject: KDE-SIG weekly report (46/2009) Message-ID: <200911101823.02773.deadbabylon@googlemail.com> This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. ---------------------------------------------------------------------------------- = Weekly KDE Summary = Week: 46/2009 Time: 2009-11-10 14:00 UTC Meeting page: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-11-10 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2009-11-10/fedora-meeting.2009-11-10-14.02.html Meeting log: http://meetbot.fedoraproject.org/fedora- meeting/2009-11-10/fedora-meeting.2009-11-10-14.02.log.html ---------------------------------------------------------------------------------- = Participants = * BenBoeckel * JaroslavReznik * KevinKofler * LukasTinkl * RexDieter * SebastianVahl * StevenParrish * ThanNgo * Hello Chissini de Castro ---------------------------------------------------------------------------------- = Agenda = * Celebration of F12 going gold * Status of KDE 4.3.3 * Features for F13 = Summary = o Topic 1 - notes o Celebration of Fedora 12 going GOLD: * The KDE-SIG celebrated the gold status of Fedora 12. * With Hello Chissini de Castro a new KDE-SIG member was introduced. * He has been working for Connectiva/Mandriva for over 10 years and is also a KDE developer for a long time. o Status of KDE 4.3.3: * KDE 4.3.3 is imported into CVS for F10 and F11, work on F12 is ongoing. * (Existing) Extragear for KDE 4.3.3 packages will follow when buildroot is ready. * KDE 4.3.3 will be the last update for F10 which will EOL soon. o Features for F13: * KDE related features and their owners for Fedora 13: - phonon/pulseaudio integration (KevinKofler) - knetworkmanager (RexDieter) - polkit-1 in KDE (JaroslavReznik) - Firefox/OpenOffice.org integration in KDE (LukasTinkl) - Prepare a wiki page outlining KDE features in F13 to work on (LukasTinkl) [1] o package splitting: * SebastianVahl proposed a splitting of KDE packages as a possible Feature for F13. * Splits could be done on a per-app basis or a split out of the "popular" packages. * First pros/cons were discussed in the meeting: - more control over the installed packages (+) - better support for a minimal runtime for small targets (like netbooks) (+) - huge increase of metadata to download (--) - more work for packagers (-) - more complexity for users (-) * SebastianVahl will prepare a wiki page with pros/cons and a documentation of the splitting already done as a basis for further discussions. ---------------------------------------------------------------------------------- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-11-17 ---------------------------------------------------------------------------------- = Links = [1] http://fedoraproject.org/wiki/SIGs/KDE/F13Features -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From jkeating at redhat.com Tue Nov 10 17:24:12 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 10 Nov 2009 09:24:12 -0800 Subject: Fedora 12 has gone gold In-Reply-To: <4AF99CBC.6060501@redhat.com> References: <1257816570.2468.32.camel@localhost.localdomain> <4AF99CBC.6060501@redhat.com> Message-ID: <1257873852.2468.58.camel@localhost.localdomain> On Tue, 2009-11-10 at 09:02 -0800, John Poelstra wrote: > > My impressions from this meeting were slightly different :-) > > We noted that there are no known reasons that we are "not go" and that > we will continue testing until Wednesday when QA expects to have > completed the testing matrix. Maybe we are separated by semantics, but > "gone gold" or "completely done" was not an impression I left the > meeting with. > > http://meetbot.fedoraproject.org/fedora-meeting/2009-11-10/fedora-meeting.2009-11-10-01.01.log.html Our impressions are indeed different. The go / no go meeting was the point of no return. Once we go, there is no going back. We've made a commitment to go with what we have, and let the various teams that need time to prepare for the release to start their work, as much of that work cannot be pulled back once done. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From poelstra at redhat.com Tue Nov 10 17:28:20 2009 From: poelstra at redhat.com (John Poelstra) Date: Tue, 10 Nov 2009 09:28:20 -0800 Subject: 2009-11-09 Fedora 12 "Go/No Go" Meeting Minutes Message-ID: <4AF9A2B4.1050908@redhat.com> http://meetbot.fedoraproject.org/fedora-meeting/2009-11-10/fedora-meeting.2009-11-10-01.01.html http://meetbot.fedoraproject.org/fedora-meeting/2009-11-10/fedora-meeting.2009-11-10-01.01.txt http://meetbot.fedoraproject.org/fedora-meeting/2009-11-10/fedora-meeting.2009-11-10-01.01.log.html Meeting summary --------------- * LINK: https://fedoraproject.org/wiki/Test_Results:Fedora_12_RC4_Install (jlaska, 01:08:59) * QA expecting test completion of matrix Wednesday (https://fedoraproject.org/wiki/Test_Results:Fedora_12_RC4_Install) (jlaska, 01:23:23) People Present (lines said) --------------------------- * adamw_ (39) * jlaska (38) * wwoods (18) * poelcat (15) * Oxf13 (11) * notting (8) * jwb (6) * mmcgrath (3) * zodbot (3) * bao_ (3) * Sparks (2) * nirik (1) From pbrobinson at gmail.com Tue Nov 10 17:35:48 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 10 Nov 2009 17:35:48 +0000 Subject: Fedora 12 has gone gold In-Reply-To: <1257872066.2467.87.camel@adam.local.net> References: <1257816570.2468.32.camel@localhost.localdomain> <1257819719.2452.75.camel@localhost.localdomain> <20091110042650.GA11310@wolff.to> <4AF8EB1F.5080007@fedoraproject.org> <1257872066.2467.87.camel@adam.local.net> Message-ID: <5256d0b0911100935j5ef63930ua2a2fd282f473c60@mail.gmail.com> On Tue, Nov 10, 2009 at 4:54 PM, Adam Williamson wrote: > On Tue, 2009-11-10 at 09:55 +0530, Rahul Sundaram wrote: > >> Hopefully Nouveau gets 3D support within a couple of releases as well. > > Ben says to send beer. :) Happily, ask him what slab he wants and where he wants it delivered :-P Peter From bjorn at xn--rombobjrn-67a.se Tue Nov 10 18:05:46 2009 From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-15?q?Bj=F6rn_Persson?=) Date: Tue, 10 Nov 2009 19:05:46 +0100 Subject: Are conflicts in debuginfo packages OK? In-Reply-To: <1257811110.2468.28.camel@localhost.localdomain> References: <200911100001.36601.bjorn@xn--rombobjrn-67a.se> <1257811110.2468.28.camel@localhost.localdomain> Message-ID: <200911101905.47061.bjorn@xn--rombobjrn-67a.se> Jesse Keating wrote: > On Tue, 2009-11-10 at 00:01 +0100, Bj?rn Persson wrote: > > I don't see that I as a packager can do anything to prevent these > > conflicts. Shall I conclude that I don't need to care about conflicts > > between architecture versions of debuginfo packages? Or shall I try to > > avoid conflicts in debuginfo packages for libraries, but not for > > programs? I think I can avoid debuginfo conflicts in packages that > > provide only libraries, but maybe I shouldn't bother? > > debuginfo packages cannot be multilib, that is why we don't offer them > multilib. I'm guessing that "we don't offer them multilib" means that 32-bit debuginfo packages aren't meant to be installed on 64-bit systems, so I'll take this to mean that I shouldn't bother doing anything to avoid conflicts. Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From fche at redhat.com Tue Nov 10 18:36:03 2009 From: fche at redhat.com (Frank Ch. Eigler) Date: Tue, 10 Nov 2009 13:36:03 -0500 Subject: Are conflicts in debuginfo packages OK? In-Reply-To: <200911101905.47061.bjorn@xn--rombobjrn-67a.se> (bjorn@xn--rombobjrn-67a.se's message of "Tue, 10 Nov 2009 19:05:46 +0100") References: <200911100001.36601.bjorn@xn--rombobjrn-67a.se> <1257811110.2468.28.camel@localhost.localdomain> <200911101905.47061.bjorn@xn--rombobjrn-67a.se> Message-ID: =?iso-8859-15?q?Bj=F6rn_Persson?= writes: >> debuginfo packages cannot be multilib, that is why we don't offer them >> multilib. > I'm guessing that "we don't offer them multilib" means that 32-bit > debuginfo packages aren't meant to be installed on 64-bit systems, > so I'll take this to mean that I shouldn't bother doing anything to > avoid conflicts. Well, hold on, debuginfo for multilib'd libraries like glibc should be absolutely installable in parallel. - FChE From fedora at matbooth.co.uk Tue Nov 10 18:40:24 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Tue, 10 Nov 2009 18:40:24 +0000 Subject: F13 Naming: Leonidas -> Constantine -> ? In-Reply-To: <1257868935.2468.51.camel@localhost.localdomain> References: <200911101645.08237.bjorn@xn--rombobjrn-67a.se> <1257868935.2468.51.camel@localhost.localdomain> Message-ID: <9497e9990911101040t72875f6cwb4158d88a12472f4@mail.gmail.com> 2009/11/10 Jesse Keating : > On Tue, 2009-11-10 at 16:45 +0100, Bj?rn Persson wrote: >> >> After F12 comes Print Screen of course. ;-) > > My keyboard has F13 next... You *are* F13... -- Mat Booth A: Because it destroys the order of the conversation. Q: Why shouldn't you do it? A: Posting your reply above the original message. Q: What is top-posting? From notting at redhat.com Tue Nov 10 19:25:16 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 10 Nov 2009 14:25:16 -0500 Subject: Are conflicts in debuginfo packages OK? In-Reply-To: References: <200911100001.36601.bjorn@xn--rombobjrn-67a.se> <1257811110.2468.28.camel@localhost.localdomain> <200911101905.47061.bjorn@xn--rombobjrn-67a.se> Message-ID: <20091110192515.GA12535@nostromo.devel.redhat.com> Frank Ch. Eigler (fche at redhat.com) said: > > I'm guessing that "we don't offer them multilib" means that 32-bit > > debuginfo packages aren't meant to be installed on 64-bit systems, > > so I'll take this to mean that I shouldn't bother doing anything to > > avoid conflicts. > > Well, hold on, debuginfo for multilib'd libraries like glibc should be > absolutely installable in parallel. Not unless someone changes the layout of debuginfo entirely, as they use common paths: /usr/src/debug/ /usr/lib/debug/usr/bin/... Bill From jakub at redhat.com Tue Nov 10 19:27:52 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 10 Nov 2009 20:27:52 +0100 Subject: Are conflicts in debuginfo packages OK? In-Reply-To: <20091110192515.GA12535@nostromo.devel.redhat.com> References: <200911100001.36601.bjorn@xn--rombobjrn-67a.se> <1257811110.2468.28.camel@localhost.localdomain> <200911101905.47061.bjorn@xn--rombobjrn-67a.se> <20091110192515.GA12535@nostromo.devel.redhat.com> Message-ID: <20091110192752.GJ14664@tyan-ft48-01.lab.bos.redhat.com> On Tue, Nov 10, 2009 at 02:25:16PM -0500, Bill Nottingham wrote: > Frank Ch. Eigler (fche at redhat.com) said: > > > I'm guessing that "we don't offer them multilib" means that 32-bit > > > debuginfo packages aren't meant to be installed on 64-bit systems, > > > so I'll take this to mean that I shouldn't bother doing anything to > > > avoid conflicts. > > > > Well, hold on, debuginfo for multilib'd libraries like glibc should be > > absolutely installable in parallel. > > Not unless someone changes the layout of debuginfo entirely, as they > use common paths: > > /usr/src/debug/ > /usr/lib/debug/usr/bin/... Currently you can install say on x86_64 either a i686, or x86_64 debuginfo package, but not both. Jakub From bernie at codewiz.org Tue Nov 10 19:40:57 2009 From: bernie at codewiz.org (Bernie Innocenti) Date: Tue, 10 Nov 2009 14:40:57 -0500 Subject: Booting Fedora live USB on MacBookPro Message-ID: <1257882057.1551.148.camel@giskard> Hello, I'm creating an EFI bootable USB image on my rawhide system with this command-line: ./livecd-iso-to-disk.sh --format --efi --overlay-size-mb 400 \ --delete-home --extra-kernel-args selinux=0 ./soas04.iso /dev/sdb1 The resulting USB stick boots fine on a black MacBook, but not on a silver MacBook Pro. The bootable stick does not even show up in the list of boot devices. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ From pjones at redhat.com Tue Nov 10 20:32:26 2009 From: pjones at redhat.com (Peter Jones) Date: Tue, 10 Nov 2009 15:32:26 -0500 Subject: Booting Fedora live USB on MacBookPro In-Reply-To: <1257882057.1551.148.camel@giskard> References: <1257882057.1551.148.camel@giskard> Message-ID: <4AF9CDDA.4020709@redhat.com> On 11/10/2009 02:40 PM, Bernie Innocenti wrote: > Hello, > > I'm creating an EFI bootable USB image on my rawhide system with this > command-line: > > ./livecd-iso-to-disk.sh --format --efi --overlay-size-mb 400 \ > --delete-home --extra-kernel-args selinux=0 ./soas04.iso /dev/sdb1 > > The resulting USB stick boots fine on a black MacBook, but not on > a silver MacBook Pro. > > The bootable stick does not even show up in the list of boot devices. Which generation of MBP and MBP, and are you using the i386 tree or the x86_64 tree? It sounds like the MacBook is a Santa Rosa (MacBook3,1) or later and the MacBook Pro is an earlier generation, and you're using x86_64. Or vice-versa regarding the ages, and you're using the i386 tree. This won't work, as pre-Santa Rosa mac will only boot 32-bit EFI images, and post-Santa Rosa macs will only boot 64-bit EFI images. -- Peter From jreiser at bitwagon.com Tue Nov 10 20:49:17 2009 From: jreiser at bitwagon.com (John Reiser) Date: Tue, 10 Nov 2009 12:49:17 -0800 Subject: Booting Fedora live USB on MacBookPro In-Reply-To: <4AF9CDDA.4020709@redhat.com> References: <1257882057.1551.148.camel@giskard> <4AF9CDDA.4020709@redhat.com> Message-ID: <4AF9D1CD.3030700@bitwagon.com> > pre-Santa Rosa mac will only boot 32-bit EFI images, > and post-Santa Rosa macs will only boot 64-bit EFI images. Also, it is only recently that a Mac might boot from USB2.0 at all; Firewire (IEEE 1394) was required for most of Apple history. -- From fedora at camperquake.de Tue Nov 10 20:54:44 2009 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 10 Nov 2009 21:54:44 +0100 Subject: Booting Fedora live USB on MacBookPro In-Reply-To: <4AF9D1CD.3030700@bitwagon.com> References: <1257882057.1551.148.camel@giskard> <4AF9CDDA.4020709@redhat.com> <4AF9D1CD.3030700@bitwagon.com> Message-ID: <20091110215444.5c0dc400@fred.camperquake.de> Hi. On Tue, 10 Nov 2009 12:49:17 -0800, John Reiser wrote > Also, it is only recently that a Mac might boot from USB2.0 at all; > Firewire (IEEE 1394) was required for most of Apple history. My old iBook G3 booted from USB. That was USB1.1, though, which may or may not be significant. From pjones at redhat.com Tue Nov 10 21:07:54 2009 From: pjones at redhat.com (Peter Jones) Date: Tue, 10 Nov 2009 16:07:54 -0500 Subject: Booting Fedora live USB on MacBookPro In-Reply-To: <4AF9D1CD.3030700@bitwagon.com> References: <1257882057.1551.148.camel@giskard> <4AF9CDDA.4020709@redhat.com> <4AF9D1CD.3030700@bitwagon.com> Message-ID: <4AF9D62A.3010901@redhat.com> On 11/10/2009 03:49 PM, John Reiser wrote: >> pre-Santa Rosa mac will only boot 32-bit EFI images, >> and post-Santa Rosa macs will only boot 64-bit EFI images. > > Also, it is only recently that a Mac might boot from USB2.0 at all; > Firewire (IEEE 1394) was required for most of Apple history. All EFI macs can do this. -- Peter RFC 882 put the dots in .com. From bjorn at xn--rombobjrn-67a.se Tue Nov 10 21:15:47 2009 From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=) Date: Tue, 10 Nov 2009 22:15:47 +0100 Subject: Are conflicts in debuginfo packages OK? In-Reply-To: <20091110192515.GA12535@nostromo.devel.redhat.com> References: <200911100001.36601.bjorn@xn--rombobjrn-67a.se> <20091110192515.GA12535@nostromo.devel.redhat.com> Message-ID: <200911102215.47261.bjorn@xn--rombobjrn-67a.se> Bill Nottingham wrote: > Frank Ch. Eigler (fche at redhat.com) said: > > > I'm guessing that "we don't offer them multilib" means that 32-bit > > > debuginfo packages aren't meant to be installed on 64-bit systems, > > > so I'll take this to mean that I shouldn't bother doing anything to > > > avoid conflicts. > > > > Well, hold on, debuginfo for multilib'd libraries like glibc should be > > absolutely installable in parallel. > > Not unless someone changes the layout of debuginfo entirely, as they > use common paths: > > /usr/src/debug/ I think can handle those. For true source code files there is no problem, because they will be identical in both packages. Generated files can be placed in separate subdirectories, for example /usr/src/debug//%{_arch}. This may of course require more or less complicated patches to makefiles or other build scripts. I'm trying to find out wheter I should do this. > /usr/lib/debug/usr/bin/... Those are the ones I can't do anything about on my own, but perhaps the same exception could be applied there as in /usr/bin? Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From pbrobinson at gmail.com Tue Nov 10 22:25:25 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 10 Nov 2009 22:25:25 +0000 Subject: Booting Fedora live USB on MacBookPro In-Reply-To: <1257882057.1551.148.camel@giskard> References: <1257882057.1551.148.camel@giskard> Message-ID: <5256d0b0911101425n4d239bcfj3d9dc674435cf57b@mail.gmail.com> On Tue, Nov 10, 2009 at 7:40 PM, Bernie Innocenti wrote: > Hello, > > I'm creating an EFI bootable USB image on my rawhide system with this > command-line: > > ?./livecd-iso-to-disk.sh --format ?--efi --overlay-size-mb 400 \ > ? ? ? ?--delete-home --extra-kernel-args selinux=0 ./soas04.iso /dev/sdb1 > > The resulting USB stick boots fine on a black MacBook, but not on > a silver MacBook Pro. > > The bootable stick does not even show up in the list of boot devices. I think there's some bugs with booting EFI devices in the various live device (cd/usb) creation tools. The latest rawhide (released in the last day or two) has an updated liveusb-creator which fixes alot of the EFI issues, and a new livecd-tools I think is due soon. Cheers, Peter From pjones at redhat.com Tue Nov 10 22:41:17 2009 From: pjones at redhat.com (Peter Jones) Date: Tue, 10 Nov 2009 17:41:17 -0500 Subject: [SoaS] Booting Fedora live USB on MacBookPro In-Reply-To: References: <1257882057.1551.148.camel@giskard> Message-ID: <4AF9EC0D.3030203@redhat.com> On 11/10/2009 05:37 PM, Caryl Bigenho wrote: > > Hi, > > My MacBook is a 4,1. Will it work on my machine? A 64-bit EFI image should work on a MacBook4,1 . A 32-bit EFI image won't. -- Peter RFC 882 put the dots in .com. From bnocera at redhat.com Tue Nov 10 22:57:33 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 10 Nov 2009 22:57:33 +0000 Subject: Booting Fedora live USB on MacBookPro In-Reply-To: <5256d0b0911101425n4d239bcfj3d9dc674435cf57b@mail.gmail.com> References: <1257882057.1551.148.camel@giskard> <5256d0b0911101425n4d239bcfj3d9dc674435cf57b@mail.gmail.com> Message-ID: <1257893853.10888.1935.camel@localhost.localdomain> On Tue, 2009-11-10 at 22:25 +0000, Peter Robinson wrote: > On Tue, Nov 10, 2009 at 7:40 PM, Bernie Innocenti wrote: > > Hello, > > > > I'm creating an EFI bootable USB image on my rawhide system with this > > command-line: > > > > ./livecd-iso-to-disk.sh --format --efi --overlay-size-mb 400 \ > > --delete-home --extra-kernel-args selinux=0 ./soas04.iso /dev/sdb1 You need to pass the device, not the partition. > > The resulting USB stick boots fine on a black MacBook, but not on > > a silver MacBook Pro. > > > > The bootable stick does not even show up in the list of boot devices. > > I think there's some bugs with booting EFI devices in the various live > device (cd/usb) creation tools. The latest rawhide (released in the > last day or two) has an updated liveusb-creator which fixes alot of > the EFI issues, and a new livecd-tools I think is due soon. If you don't even see the USB hard disk when booting up, then it probably isn't formatted with GPT. Use --format on /dev/sdb. If it shows up but ends up booting another OS, then your EFI/boot/boot*.conf isn't updated, and you might have hit: https://bugzilla.redhat.com/show_bug.cgi?id=533824 Let me know if the patch works. And as Peter's mentioned, if your device supports x86_64, you need an x86_64 image, and the same for 32-bit. Note that I'm not sure how those are generated, but you should be able to boot a 32-bit distro as long as you have a bootx64.conf and bootx64.efi in /EFI/boot on the USB key. Cheers From bruno at wolff.to Wed Nov 11 00:23:43 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 10 Nov 2009 18:23:43 -0600 Subject: F13 Naming: Leonidas -> Constantine -> ? In-Reply-To: <1257868935.2468.51.camel@localhost.localdomain> References: <200911101645.08237.bjorn@xn--rombobjrn-67a.se> <1257868935.2468.51.camel@localhost.localdomain> Message-ID: <20091111002343.GA31082@wolff.to> On Tue, Nov 10, 2009 at 08:02:15 -0800, Jesse Keating wrote: > On Tue, 2009-11-10 at 16:45 +0100, Bj?rn Persson wrote: > > > > After F12 comes Print Screen of course. ;-) > > My keyboard has F13 next... F13 has to be named after Katz. From bruno at wolff.to Wed Nov 11 00:26:47 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 10 Nov 2009 18:26:47 -0600 Subject: F13 Naming: Leonidas -> Constantine -> ? In-Reply-To: <9497e9990911101040t72875f6cwb4158d88a12472f4@mail.gmail.com> References: <200911101645.08237.bjorn@xn--rombobjrn-67a.se> <1257868935.2468.51.camel@localhost.localdomain> <9497e9990911101040t72875f6cwb4158d88a12472f4@mail.gmail.com> Message-ID: <20091111002647.GB31082@wolff.to> On Tue, Nov 10, 2009 at 18:40:24 +0000, Mat Booth wrote: > 2009/11/10 Jesse Keating : > > On Tue, 2009-11-10 at 16:45 +0100, Bj?rn Persson wrote: > >> > >> After F12 comes Print Screen of course. ;-) > > > > My keyboard has F13 next... > > > You *are* F13... Too many J.K.s and I appear to have mixed them up. From MathStuf at gmail.com Wed Nov 11 02:08:16 2009 From: MathStuf at gmail.com (Ben Boeckel) Date: Tue, 10 Nov 2009 21:08:16 -0500 Subject: Are conflicts in debuginfo packages OK? References: <200911100001.36601.bjorn@xn--rombobjrn-67a.se> <20091110192515.GA12535@nostromo.devel.redhat.com> <200911102215.47261.bjorn@xn--rombobjrn-67a.se> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Bj?rn Persson wrote: > I think can handle those. For true source code files there is no problem, > because they will be identical in both packages. Generated files can be placed > in separate subdirectories, for example > /usr/src/debug//%{_arch}. > This may of course require more or less complicated patches to makefiles or > other build scripts. I'm trying to find out wheter I should do this. For KDE4 builds (which should also work for any CMake system as well) is (not copy-paste ready): mkdir %{_target_platform} pushd %{_target_platform} cmake .. popd make -C %{_target_platform} This ensures all of the generated files are in a separate directory. I'm not sure how this would work with autotools since I don't use them. - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJK+hyQAAoJEKaxavVX4C1XkMoP/iR/zV3s8+4F5KQB5F4+dw2T EgAkG/qtp8JQDUhakZ7WSbkdKhWVEP3ImZuwe+JOf+WA9MED3b03VXGL6mrQf08J pJz+mSsMUqR2g+Sh2+UUSBMCqLm4o7RW9MHDClDxroK+BslI/+wdT32Ouqzld9DY XMQZ/ifnBfYd/U+A9xbseLMkgOCj2TdEtQfrGfSesex8zufKKyFV/lfgAoA9NCRC BLQQBy+Hu83HwLBQmxCNqfqZ3IMlc7AHKXc9mw71Cog9L/8hvr02d41NjH9g3O4W JOOhLID+TdpAoyA0FTqy8DOpXPNYp/MccZW2pZ33SCECmsAkwJ1lR6A4zPf1VED4 TixnwMYlGztW2F8HoGNna1aU6eOiQjdrz18lJY9/ne01qK7l9cY2CeXME5bKzQu/ gizCPqZUzOHK4uMvnlezbpxF9UxL5GX8uphDd0MFsBZbkq+TTW4TitJ7MYs6UQ6h rBf2rwQXJidNWEYf8Ln03jxBdg59s80AcK2W7pzhWCNb61t6QpM+F86YQ9Kw9Hq0 zpm3rBHO+XkkwKM5bP35jbfv/8ZdnXbaoCuvJK5YVy6LT3irnk4F79IoJUDyaRh2 NYJNwsLW9DnWp/3lyujP4vrursS1nBEDm6cr3MFCcscktG9prwSWvr+WZZXh5S2B B1G/+rtz4VVIs9uBouL2 =Zr9O -----END PGP SIGNATURE----- From fche at redhat.com Wed Nov 11 03:14:49 2009 From: fche at redhat.com (Frank Ch. Eigler) Date: Tue, 10 Nov 2009 22:14:49 -0500 Subject: Are conflicts in debuginfo packages OK? In-Reply-To: <20091110192752.GJ14664@tyan-ft48-01.lab.bos.redhat.com> (Jakub Jelinek's message of "Tue, 10 Nov 2009 20:27:52 +0100") References: <200911100001.36601.bjorn@xn--rombobjrn-67a.se> <1257811110.2468.28.camel@localhost.localdomain> <200911101905.47061.bjorn@xn--rombobjrn-67a.se> <20091110192515.GA12535@nostromo.devel.redhat.com> <20091110192752.GJ14664@tyan-ft48-01.lab.bos.redhat.com> Message-ID: Jakub Jelinek writes: > [...] >> > Well, hold on, debuginfo for multilib'd libraries like glibc should be >> > absolutely installable in parallel. >> >> Not unless someone changes the layout of debuginfo entirely, as they >> use common paths: >> >> /usr/src/debug/ Right, that's a complication. (It could be handled by suffixing the arch in the source-tree-name part.) >> /usr/lib/debug/usr/bin/... Considering that the same files are also linked into multilib-safe collision-free /usr/lib/debug/.build-id files, where debuggers already know to look for them, the .../usr/bin* ones could be deprecated. Or the conflicting /bin files could be moved to a separate non-library subpackage. I hope it is obvious that it would be appropriate to be able to debug anything installed from the normal repositories. That the status quo is not quite up to the job (in the case of some multilib libraries) is a bug. - FChE From bernie at codewiz.org Wed Nov 11 04:24:59 2009 From: bernie at codewiz.org (Bernie Innocenti) Date: Tue, 10 Nov 2009 23:24:59 -0500 Subject: Booting Fedora live USB on MacBookPro In-Reply-To: References: <1257882057.1551.148.camel@giskard> Message-ID: <1257913499.1551.527.camel@giskard> El Tue, 10-11-2009 a las 15:31 -0500, Caroline Meeks escribi?: > Are you sure you macbook pro is capable of booting linux? I was > experimenting at a Apple Store and found that the White Macbooks there > were not capable of booting Linux from a CD, let alone Sugar from a > Stick. However the Silver Macbook pros booted both fine. White > macbooks at the GPA have the same issue. Older white macbooks at the > Lilla Fredrick boot fine. So things can be very odd with Macs. Next Saturday I'll bring a few boot CDs of Fedora and Ubuntu to see if I can manage to make them boot on those silver Mac Book Pros. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ From augustz at augustz.com Wed Nov 11 05:48:42 2009 From: augustz at augustz.com (August Zajonc) Date: Tue, 10 Nov 2009 21:48:42 -0800 Subject: Fedora Core 12 Public AMI for EC2 Message-ID: <4AFA503A.2080708@augustz.com> Hey there, Curious if anyone has put together FC11 (or 12) AMI for Amazons EC2. Anyone interested in working on this type of thing with me? Is there a key technical reason this may be hard / impossible? (Amazon kernel version for example jumps out as a possability). Many cheers, - August From maillist at diffingo.com Wed Nov 11 06:30:02 2009 From: maillist at diffingo.com (Stewart Adam) Date: Wed, 11 Nov 2009 01:30:02 -0500 Subject: [SoaS] Booting Fedora live USB on MacBookPro In-Reply-To: <4AF9EC0D.3030203@redhat.com> References: <1257882057.1551.148.camel@giskard> <4AF9EC0D.3030203@redhat.com> Message-ID: <4AFA59EA.4070302@diffingo.com> On 2009/11/10 5:41 PM, Peter Jones wrote: > On 11/10/2009 05:37 PM, Caryl Bigenho wrote: >> >> Hi, >> >> My MacBook is a 4,1. Will it work on my machine? > > A 64-bit EFI image should work on a MacBook4,1 . A 32-bit EFI image > won't. > If the silver MBP is also a 4,1 model, there may be complications... There are some video initialization problems [1] when booting EFI kernels. Stewart [1] https://bugzilla.redhat.com/show_bug.cgi?id=496134 From maillist at diffingo.com Wed Nov 11 06:37:12 2009 From: maillist at diffingo.com (Stewart Adam) Date: Wed, 11 Nov 2009 01:37:12 -0500 Subject: intent to retire: kudzu In-Reply-To: <4AF87B54.5020807@fedoraproject.org> References: <20091109202844.GA29552@nostromo.devel.redhat.com> <4AF87B54.5020807@fedoraproject.org> Message-ID: <4AFA5B98.7080000@diffingo.com> On 2009/11/09 3:28 PM, Rahul Sundaram wrote: > On 11/10/2009 01:58 AM, Bill Nottingham wrote: >> However, it is still being required by two programs: >> - hwbrowser >> - fwfstab >> > I filed a bug report against these programs a while back to move away > from Kudzu. Neither of these programs themselves seem to be actively > maintained anymore. > > Rahul I originally wrote it to aid users edit their fstab to get partitions automounted at boot, but for the past few Fedora releases that can be done right from Gnome/KDE so as a result I haven't given fwfstab much attention. I will update it eventually to DeviceKit, but I can't invest the time at the moment. Would it be possible to have it temporarily removed from the repos? Thanks, Stewart From mschwendt at gmail.com Wed Nov 11 08:00:58 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 11 Nov 2009 09:00:58 +0100 Subject: rpms/iptstate/devel iptstate.spec,1.22,1.23 In-Reply-To: <20091110233043.8F73111C02BA@cvs1.fedora.phx.redhat.com> References: <20091110233043.8F73111C02BA@cvs1.fedora.phx.redhat.com> Message-ID: <20091111090058.04a3e5a0@faldor.intranet> On Tue, 10 Nov 2009 23:30:43 +0000 (UTC), Paul wrote: > Author: stingray > > Update of /cvs/pkgs/rpms/iptstate/devel > In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv20114 > > Modified Files: > iptstate.spec > Log Message: > iptstate-2.2.2-2 Please give "make clog" and "cvs commit -F clog" a try when committing package changes. What it does is to store the latest %changelog comment in a file "clog" which to use as the cvs commit log message. Tons better than what you entered as a log message manually. Also consider later usage of "cvs log" where a meaningful log entry makes sense. > %changelog > +* Tue Nov 10 2009 Paul P. Komkoff Jr - 2.2.2-2 > +- rebuild for libnetfilter_conntrack-0.0.100 > + From bbaetz at gmail.com Wed Nov 11 08:06:51 2009 From: bbaetz at gmail.com (Bradley Baetz) Date: Wed, 11 Nov 2009 19:06:51 +1100 Subject: Fedora 12 has gone gold In-Reply-To: <1257873852.2468.58.camel@localhost.localdomain> References: <1257816570.2468.32.camel@localhost.localdomain> <4AF99CBC.6060501@redhat.com> <1257873852.2468.58.camel@localhost.localdomain> Message-ID: <4AFA709B.5050505@gmail.com> [sorry for the duplicate posting if you get one] On 11/11/09 04:24, Jesse Keating wrote: > Our impressions are indeed different. The go / no go meeting was the > point of no return. Once we go, there is no going back. We've made a > commitment to go with what we have, and let the various teams that need > time to prepare for the release to start their work, as much of that > work cannot be pulled back once done. > Does that mean that its too late to get a bug marked as a blocker? I've just upgraded from F11 using preupgrade and run into https://bugzilla.redhat.com/show_bug.cgi?id=530896 which appears to have the impact that anyone not using the graphical boot option can't enter a password for an encrypted partition (eg /home), and then gets stuck in an endless loop being prompted for the password with no way out. The fix is to boot off a rescue image (and liveusb-creator being broken for x86_64 didn't help - https://fedorahosted.org/liveusb-creator/ticket/626), upgrade to the packages from koji and then rebuild the initrd. The fix in koji solves this for me, but I suspect that its going to hit a lot of people... All the people in the bug are complaining about this happening with /home - does someone with / encrypted want to turn off graphical boot and see if it affects that too? Bradley From mschwendt at gmail.com Wed Nov 11 09:52:26 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 11 Nov 2009 10:52:26 +0100 Subject: rpms/iptstate/F-12 iptstate.spec,1.21,1.22 In-Reply-To: <20091111091758.0631E11C00E8@cvs1.fedora.phx.redhat.com> References: <20091111091758.0631E11C00E8@cvs1.fedora.phx.redhat.com> Message-ID: <20091111105226.3e7d1416@faldor.intranet> On Wed, 11 Nov 2009 09:17:58 +0000 (UTC), Paul wrote: > Author: stingray > > Update of /cvs/pkgs/rpms/iptstate/F-12 > %changelog > +* Tue Nov 10 2009 Paul P. Komkoff Jr - 2.2.2-2 > +- rebuild for libnetfilter_conntrack-0.0.100 > + > +* Tue Nov 10 2009 Thomas Woerner 2.2.2-1 > +- new version 2.2.2 > +- removed upstream strerror patch > +- fixed package description (rhbz#140516) > + Caution! Dude, you should slow down quite a bit and give all this a second thought. You have not yet committed and built the new libnetfilter_conntrack upgrade for F-12. Rebuilding the other packages for F-12 won't work correctly because of that. They are built against the old library. Take your time. Update your cvs working-directory with "cvs up -d" to get the F-12 branch, then follow Fedora procedures for this ABI-incompatible library upgrade (which means to request a koji buildroot override tag from Fedora Release Engineering so the new libnetfilter_conntrack for F-12 will be made available in the koji buildroot _prior_ to pushing it into the stable updates repository. That way you can prepare all rebuilds without pushing any incompatible upgrades into the stable repo). If you need help, ask your sponsor, or ask on this list. From sundaram at fedoraproject.org Wed Nov 11 09:51:12 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 11 Nov 2009 15:21:12 +0530 Subject: intent to retire: kudzu In-Reply-To: <4AFA5B98.7080000@diffingo.com> References: <20091109202844.GA29552@nostromo.devel.redhat.com> <4AF87B54.5020807@fedoraproject.org> <4AFA5B98.7080000@diffingo.com> Message-ID: <4AFA8910.4010508@fedoraproject.org> On 11/11/2009 12:07 PM, Stewart Adam wrote: > > I will update it eventually to DeviceKit, but I can't invest the time at > the moment. Would it be possible to have it temporarily removed from the > repos? If it works as it is, you can take over kudzu for the time being and continue with it till the time that you can move over to a replacement. Rahul From rjones at redhat.com Wed Nov 11 10:14:21 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 11 Nov 2009 10:14:21 +0000 Subject: cpio to ext4 seems much slower than to ext2, ext3 or xfs Message-ID: <20091111101421.GA28964@amd.home.annexia.org> Create a 128 MB input file: cd /tmp dd if=/dev/zero of=input bs=1024k count=128 and then create a cpio file from that to various target filesystems: echo input | time cpio --quiet -o -H newc > /path/to/fs/output I created ext2, ext3, ext4, xfs and tmpfs filesystems and mounted them (all default options). All timings on baremetal, quiet machine, with a hot cache, and then averaged over three runs: tmpfs 0.77 s x 1.0 ext2 1.12 s x 1.5 xfs 1.66 s x 2.1 ext3 2.58 s x 3.4 ext4 5.59 s x 7.3 <---- You can see that ext4 seems to do significantly worse than the others. I looked at the strace of cpio and it does 512 byte writes. I'm going to try to fix that so it does larger writes, but I'm not sure if that matters (shouldn't the kernel combine these writes?) The reason I'm concentrating on cpio (instead of cp) is that it was while creating a cpio format archive that I noticed the ext4 was performing very poorly. Rich. kernel 2.6.31.1-56.fc12.x86_64 cpio-2.10-3.fc12.x86_64 -- Richard Jones, Virtualization Group, Red Hat http://people.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 jaroslav at aster.pl Wed Nov 11 10:47:24 2009 From: jaroslav at aster.pl (=?utf-8?q?Jaros=C5=82aw_G=C3=B3rny?=) Date: Wed, 11 Nov 2009 11:47:24 +0100 Subject: cvs-import.sh problem In-Reply-To: <200911091636.18404.dennis@ausil.us> References: <200911071618.08630.jaroslav@aster.pl> <200911091636.18404.dennis@ausil.us> Message-ID: <200911111147.24548.jaroslav@aster.pl> Hi, Dnia poniedzia?ek 09 listopad 2009 o 23:36:13 Dennis Gilmore napisa?(a): > On Saturday 07 November 2009 09:18:08 am Jaros?aw G?rny wrote: (...) > > > > Checking : mpdscribble-0.18.1.tar.bz2 on > > https://cvs.fedoraproject.org/repo/pkgs/upload.cgi... > > ERROR: could not check remote file status > > make: *** [upload] B??d 255 > > ERROR: Uploading the source tarballs failed! > > > > > > Is it me doing sth. wrong (or not configured properly)? Please help me, > > > > thanks, > > you need to have your ssl cert in place to upload the tarball. run > "fedora- cert -n" to get your cert and try again. Yes, you are right. I came to this yesterday ;) It's just that I have requested new cert, but forgot to run fedora-package-setup. It's working now and my first package has been successfully built in koji ! thanks!, -- Jaros?aw G?rny RHCE From rjones at redhat.com Wed Nov 11 10:53:22 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 11 Nov 2009 10:53:22 +0000 Subject: cpio to ext4 seems much slower than to ext2, ext3 or xfs In-Reply-To: <20091111101421.GA28964@amd.home.annexia.org> References: <20091111101421.GA28964@amd.home.annexia.org> Message-ID: <20091111105322.GB28964@amd.home.annexia.org> On Wed, Nov 11, 2009 at 10:14:21AM +0000, Richard W.M. Jones wrote: > echo input | time cpio --quiet -o -H newc > /path/to/fs/output Update: I found the -C option that lets me specify the blocksize, and raising it to something sensible (65536) shows major improvements in performance for all filesystems. echo input | time cpio -C 65536 --quiet -o -H newc > /path/to/fs/output > tmpfs 0.77 s x 1.0 > ext2 1.12 s x 1.5 > xfs 1.66 s x 2.1 > ext3 2.58 s x 3.4 > ext4 5.59 s x 7.3 <---- The new times are: tmpfs 0.20 s x 1.0 ext2 0.30 s x 1.5 xfs 0.41 s x 2.1 ext3 0.57 s x 2.9 ext4 0.44 s x 2.2 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw From lfarkas at lfarkas.org Wed Nov 11 11:41:58 2009 From: lfarkas at lfarkas.org (Farkas Levente) Date: Wed, 11 Nov 2009 12:41:58 +0100 Subject: cpio to ext4 seems much slower than to ext2, ext3 or xfs In-Reply-To: <20091111105322.GB28964@amd.home.annexia.org> References: <20091111101421.GA28964@amd.home.annexia.org> <20091111105322.GB28964@amd.home.annexia.org> Message-ID: <4AFAA306.9090003@lfarkas.org> On 11/11/2009 11:53 AM, Richard W.M. Jones wrote: > On Wed, Nov 11, 2009 at 10:14:21AM +0000, Richard W.M. Jones wrote: >> echo input | time cpio --quiet -o -H newc > /path/to/fs/output > > Update: I found the -C option that lets me specify the blocksize, and > raising it to something sensible (65536) shows major improvements in > performance for all filesystems. > > echo input | time cpio -C 65536 --quiet -o -H newc > /path/to/fs/output > >> tmpfs 0.77 s x 1.0 >> ext2 1.12 s x 1.5 >> xfs 1.66 s x 2.1 >> ext3 2.58 s x 3.4 >> ext4 5.59 s x 7.3 <---- > > The new times are: > > tmpfs 0.20 s x 1.0 > ext2 0.30 s x 1.5 > xfs 0.41 s x 2.1 > ext3 0.57 s x 2.9 > ext4 0.44 s x 2.2 imho it's still a bug. wouldn't somehow rise the default or make the writes buffered or ... since the current situation is not correct. -- Levente "Si vis pacem para bellum!" From nicolas.mailhot at laposte.net Wed Nov 11 12:11:03 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Nov 2009 13:11:03 +0100 Subject: Identifying remaining core font users Message-ID: <1257941463.841.37.camel@arekh.okg> Hi, It has been plain since 2003? our new font access standard would be fontconfig. Since then most users of the old core fonts X11 backend have migrated, but there are still a few stragglers. Unfortunately these stragglers matter. Core fonts were not good in 2003, and they didn't get any better since. Few users means life-support maintenance only, no one to replace/fix core fonts when a technical or legal problem causes them to be dropped, no one to update them when encoding standards change. Also, few users means we do not install core font packages by default anymore, so packagers that depend on them but forgot to mark the deps in their packages will deliver broken packages to users. Every remaining core font user is therefore likely to hit more and more problems as time passes. Each of those problems produces as a side effect "Fedora fonts suck" messages on the Internet, messages that detract on all the terrific work Fedora people do on our main font backend (and associated fonts). End-users are not educated enough to recognize the root of their problems is the use of a deprecated almost-no-maintained tech (and they should not have to bother about it). Therefore, I'd like to identify remaining core font users, and remind them periodically their core font use is not good for their users or for Fedora. Since there is not question of deliberately removing core fonts infrastructure from Fedora, I need to whitelist first the few files used to maintain this infrastructure (xfontsel and xlsfonts are such files; twm and gtk1 ? not). I'd therefore be grateful if people checked the following list and pointed to me files that need to be removed for this reason. Please answer this message with statements such as "file foo can be removed from the list because it is used this way to manage the core fonts backend or to propagate the core font protocol to X11 clients". Again, widget libraries or utilities that made use of the core fonts backend when it was the font access standard, do not count. Also modern libraries that have some form of vestigial core fonts code hidden deep inside them should probably just excise it (this use it probably worse than apps that only use core fonts , since those apps at least test regularly if their core fonts use is not totally broken). ? 9wm 9wm-0:1.2-2.fc12 ? /usr/bin/9wm ? ClanLib ClanLib-0:1.0.0-3.fc12 ? /usr/lib64/libclanGL.so.1.0.0 ? GMT xgridedit-0:4.5.1-1.fc12 ? /usr/bin/xgridedit ? Glide3-libGL Glide3-libGL-0:6.2.1-10.fc12 ? /usr/lib64/Glide3-libGL/libGL.so.1.5.060201 ? GraphicsMagick GraphicsMagick-0:1.3.7-1.fc12 ? /usr/lib64/libGraphicsMagick.so.3.2.0 ? ImageMagick ImageMagick-0:6.5.4.7-3.fc12 ? /usr/lib64/libMagickCore.so.2.0.0 ? MagicPoint MagicPoint-0:1.11b-10.fc12 ? /usr/bin/mgp2ps ? /usr/bin/mgp ? /usr/bin/xwintoppm ? OpenSceneGraph OpenSceneGraph-libs-0:2.8.2-3.fc12 ? /usr/lib64/libosgViewer.so.2.8.2 ? R R-core-0:2.9.2-1.fc12 ? /usr/lib64/R/modules/R_X11.so ? TeXmacs TeXmacs-0:1.0.7.2-2.fc12 ? /usr/libexec/TeXmacs/bin/texmacs.bin ? WindowMaker WINGs-libs-0:0.92.0-20.fc12 ? /usr/lib64/libExtraWINGs.so.0.0.0 ? /usr/lib64/libWINGs.so.2.0.1 ? WindowMaker WindowMaker-0:0.92.0-20.fc12 ? /usr/bin/wmaker ? Xaw3d Xaw3d-0:1.5E-15.fc12 ? /usr/lib64/libXaw3d.so.7.0 ? aalib aalib-libs-0:1.4.0-0.18.rc5.fc12 ? /usr/lib64/libaa.so.1.0.4 ? allegro allegro-0:4.2.2-14.fc12 ? /usr/lib64/liballeg-4.2.2.so ? allegro allegro-devel-0:4.2.2-14.fc12 ? /usr/lib64/liballd-4.2.2.so ? /usr/lib64/liballp-4.2.2.so ? alliance alliance-0:5.0-31.20090901snap.fc12 ? /usr/lib64/alliance/bin/dreal ? /usr/lib64/alliance/bin/graal ? /usr/lib64/alliance/bin/xfsm ? /usr/lib64/alliance/bin/xgra ? /usr/lib64/alliance/bin/xpat ? /usr/lib64/alliance/bin/xsch ? /usr/lib64/alliance/bin/xvpn ? alltray alltray-0:0.70-4.fc12 ? /usr/bin/alltray ? aplus-fsf aplus-fsf-0:4.22.4-19.fc12 ? /usr/lib64/aplus-fsf/4.22.4/libAplusGUI.so ? /usr/lib64/aplus-fsf/4.22.4/libMSGUI.so ? atari++ atari++-0:1.57-1.fc12 ? /usr/bin/atari++ ? aterm aterm-0:1.0.1-6.fc12 ? /usr/bin/aterm ? blackbox blackbox-0:0.70.1-14 ? /usr/bin/blackbox ? /usr/lib64/libbt.so.0.0.0 ? blender blender-0:2.49b-1.fc12 ? /usr/bin/blender.bin ? blender blenderplayer-0:2.49b-1.fc12 ? /usr/bin/blenderplayer.bin ? brltty brltty-xw-0:4.1-3.fc12 ? /lib64/brltty/libbrlttybxw.so ? cernlib cernlib-0:2006-34.fc12 ? /usr/lib64/cernlib/2006/lib/libgrafX11.so.1_gfortran.2006 ? /usr/lib64/cernlib/2006/lib/libpacklib-lesstif.so.1_gfortran.2006 ? /usr/lib64/cernlib/2006/lib/libpawlib-lesstif.so.3_gfortran.2006 ? cernlib cernlib-packlib-gfortran-0:2006-34.fc12 ? /usr/bin/kxterm-gfortran ? cernlib paw-gfortran-0:2006-34.fc12 ? /usr/bin/paw++-gfortran ? /usr/bin/pawX11-gfortran ? cernlib-g77 cernlib-g77-0:2006-33.fc12 ? /usr/lib64/cernlib/2006-g77/lib/libgrafX11.so.1.2006 ? /usr/lib64/cernlib/2006-g77/lib/libpacklib-lesstif.so.1.2006 ? /usr/lib64/cernlib/2006-g77/lib/libpawlib-lesstif.so.3.2006 ? cernlib-g77 cernlib-packlib-0:2006-33.fc12 ? /usr/bin/kxterm ? cernlib-g77 cernlib-packlib-g77-0:2006-33.fc12 ? /usr/bin/kxterm-g77 ? cernlib-g77 paw-0:2006-33.fc12 ? /usr/bin/paw++ ? /usr/bin/pawX11 ? cernlib-g77 paw-g77-0:2006-33.fc12 ? /usr/bin/paw++-g77 ? /usr/bin/pawX11-g77 ? cgoban cgoban-0:1.9.14-12.fc12 ? /usr/bin/cgoban ? cinepaint cinepaint-0:0.22.1-14.fc12 ? /usr/bin/cinepaint ? clips clips-xclips-0:6.30.0-0.1.20090722svn.fc12 ? /usr/bin/xclips ? clisp clisp-0:2.47-4.fc12 ? /usr/lib64/clisp-2.47/full/lisp.run ? compiz compiz-0:0.8.2-19.fc12 ? /usr/bin/compiz ? /usr/lib64/compiz/libmove.so ? /usr/lib64/compiz/libresize.so ? /usr/lib64/compiz/libscale.so ? /usr/lib64/compiz/libzoom.so ? compiz compiz-gnome-0:0.8.2-19.fc12 ? /usr/bin/gtk-window-decorator ? compiz compiz-kde-0:0.8.2-19.fc12 ? /usr/bin/kde4-window-decorator ? compiz-fusion compiz-fusion-0:0.8.2-4.fc12 ? /usr/lib64/compiz/libshift.so ? compiz-fusion-extras compiz-fusion-extras-0:0.8.2-2.fc12 ? /usr/lib64/compiz/libshelf.so ? /usr/lib64/compiz/libwidget.so ? conky conky-0:1.7.2-1.fc12 ? /usr/bin/conky ? control-center control-center-1:2.28.1-4.fc12 ? /usr/bin/gnome-appearance-properties ? /usr/bin/gnome-font-viewer ? crossfire-client crossfire-client-0:1.11.0-3.fc12 ? /usr/bin/cfclient ? crystalspace crystalspace-0:1.2.1-6.fc12 ? /usr/lib64/crystalspace-1.2/xwin.so ? ddd ddd-0:3.3.12-5.fc12 ? /usr/bin/ddd ? dillo dillo-0:0.8.6-11.fc12 ? /usr/bin/dillo-i18n ? dinotrace dinotrace-0:9.4a-5.fc12 ? /usr/bin/dinotrace ? ds9 ds9-0:5.4-7.fc12 ? /usr/bin/ds9 ? dx dx-0:4.4.4-10.fc12 ? /usr/lib64/dx/bin_linux/builder ? /usr/lib64/dx/bin_linux/dxexec ? /usr/lib64/dx/bin_linux/dxui ? /usr/lib64/dx/bin_linux/prompter ? /usr/lib64/dx/bin_linux/startupui ? /usr/lib64/dx/bin_linux/tutor ? dx dx-libs-0:4.4.4-10.fc12 ? /usr/lib64/libDX.so.4.0.44 ? /usr/lib64/libDXcallm.so.4.0.44 ? dzen2 dzen2-0:0.8.5-5.fc12 ? /usr/bin/dzen2-textwidth ? /usr/bin/dzen2 ? e16 e16-0:0.16.8.15-3.fc12 ? /usr/bin/e16 ? /usr/bin/edox ? easystroke easystroke-0:0.4.9-1.fc12 ? /usr/bin/easystroke ? ecore ecore-0:0.9.9.050-7.fc12 ? /usr/lib64/libecore_x.so.0.9.9 ? efte efte-0:1.1-1.fc12 ? /usr/bin/efte ? emacs emacs-1:23.1-10.fc12 ? /usr/bin/emacs-23.1 ? emerald emerald-0:0.8.2-2.fc12 ? /usr/bin/emerald ? enlightenment enlightenment-0:0.16.999.050-5.fc12 ? /usr/bin/enlightenment ? eterm eterm-0:0.9.5-6.fc12 ? /usr/lib64/libEterm-0.9.5.so ? exim exim-mon-0:4.69-17.fc12 ? /usr/sbin/eximon.bin ? fbdesk fbdesk-0:1.4.1-6.fc12 ? /usr/bin/fbdesk ? fltk fltk-0:1.1.9-6.fc12 ? /usr/lib64/libfltk.so.1.1 ? fluxbox fluxbox-0:1.1.1-5.fc12 ? /usr/bin/fbrun ? /usr/bin/fbsetroot ? /usr/bin/fluxbox ? fontforge fontforge-0:20090622-2.fc12 ? /usr/lib64/libgdraw.so.4.0.7 ? freefem++ freefem++-0:3.5-2.fc12 ? /usr/bin/FreeFem++-x11 ? /usr/bin/drawbdmesh ? freefem++ freefem++-glx-0:3.5-2.fc12 ? /usr/bin/FreeFem++-glx ? freeglut freeglut-0:2.6.0-0.2.rc1.fc12 ? /usr/lib64/libglut.so.3.9.0 ? freetype freetype-demos-0:2.3.9-6.fc12 ? /usr/bin/ftdiff ? /usr/bin/ftgamma ? /usr/bin/ftgrid ? /usr/bin/ftmulti ? /usr/bin/ftstring ? /usr/bin/ftview ? fvwm fvwm-0:2.5.26-4.fc12 ? /usr/bin/fvwm ? /usr/libexec/fvwm/2.5.26/FvwmButtons ? /usr/libexec/fvwm/2.5.26/FvwmDragWell ? /usr/libexec/fvwm/2.5.26/FvwmForm ? /usr/libexec/fvwm/2.5.26/FvwmIconBox ? /usr/libexec/fvwm/2.5.26/FvwmIconMan ? /usr/libexec/fvwm/2.5.26/FvwmIdent ? /usr/libexec/fvwm/2.5.26/FvwmPager ? /usr/libexec/fvwm/2.5.26/FvwmProxy ? /usr/libexec/fvwm/2.5.26/FvwmScript ? /usr/libexec/fvwm/2.5.26/FvwmScroll ? /usr/libexec/fvwm/2.5.26/FvwmTaskBar ? /usr/libexec/fvwm/2.5.26/FvwmWinList ? gabedit gabedit-0:2.2.4-1.fc12 ? /usr/bin/gabedit ? gambas2 gambas2-gb-sdl-0:2.17.0-1.fc12 ? /usr/lib64/gambas2/gb.sdl.so.0.0.0 ? gbdfed gbdfed-0:1.5-1.fc12 ? /usr/bin/gbdfed ? gcl gcl-0:2.6.8-0.6.20090701cvs.fc12 ? /usr/lib/gcl-2.6.8/unixport/saved_ansi_gcl ? gdm gdm-1:2.28.1-24.fc12 ? /usr/libexec/gdm-factory-slave ? /usr/libexec/gdm-product-slave ? /usr/libexec/gdm-simple-slave ? /usr/libexec/gdm-xdmcp-chooser-slave ? gds2pov gds2pov-0:0.20080229-3.fc12 ? /usr/bin/gdsoglviewer ? geomview geomview-0:1.9.4-10.fc12 ? /usr/libexec/geomview/animate ? /usr/libexec/geomview/gvx ? ghostscript ghostscript-0:8.70-1.fc12 ? /usr/lib64/ghostscript/8.70/X11.so ? giflib giflib-utils-0:4.1.6-3.fc12 ? /usr/bin/gif2x11 ? gifsicle gifview-0:1.55-2.fc12 ? /usr/bin/gifview ? gimp gimp-2:2.6.7-2.fc12 ? /usr/lib64/gimp/2.0/plug-ins/screenshot ? gle gle-0:4.2.0-4.fc12 ? /usr/lib64/libgle-graphics-4.2.0.so ? glest glest-0:3.2.2-1.fc12 ? /usr/libexec/glest/glest ? gnome-libs gnome-libs-1:1.4.2-15.fc12 ? /usr/lib64/libgnomeui.so.32.14.1 ? /usr/lib64/libgtkxmhtml.so.1.0.1 ? /usr/lib64/libzvt.so.2.3.0 ? gnome-settings-daemon gnome-settings-daemon-0:2.28.1-5.fc12 ? /usr/lib64/gnome-settings-daemon-2.0/libfont.so ? gnuplot gnuplot-common-0:4.2.6-1.fc12 ? /usr/libexec/gnuplot/4.2/gnuplot_x11 ? grace grace-0:5.1.22-5.fc12 ? /usr/bin/gracebat ? /usr/bin/xmgrace ? grads grads-0:1.9b4-28.fc12 ? /usr/bin/gradsc ? /usr/bin/gradsdods ? /usr/bin/gradshdf ? /usr/bin/gradsnc ? /usr/bin/gxtran ? graphviz graphviz-0:2.20.3-5.fc12.1 ? /usr/bin/lefty ? grass grass-0:6.3.0-14.fc12 ? /usr/lib64/grass-6.3.0/driver/XDRIVER ? /usr/lib64/grass-6.3.0/etc/nviz2.2/nviz ? gridengine gridengine-qmon-0:6.2u3-3.fc12 ? /usr/bin/qmon ? groff groff-gxditview-0:1.18.1.4-18.fc12 ? /usr/bin/gxditview ? gromacs gromacs-0:4.0.4-2.fc11 ? /usr/bin/g_highway_d ? /usr/bin/g_highway ? /usr/bin/g_ngmx_d ? /usr/bin/g_ngmx ? /usr/bin/g_xrama_d ? /usr/bin/g_xrama ? gtk+ gtk+-1:1.2.10-69.fc12 ? /usr/lib64/libgdk-1.2.so.0.9.1 ? /usr/lib64/libgtk-1.2.so.0.9.1 ? gtk2 gtk2-0:2.18.3-19.fc12 ? /usr/lib64/libgdk-x11-2.0.so.0.1800.3 ? gv gv-0:3.6.7-2.fc12 ? /usr/bin/ghostview ? /usr/bin/gv ? gxine gxine-0:0.5.903-4.fc12 ? /usr/bin/gxine ? hackedbox hackedbox-0:0.8.5-7.fc12 ? /usr/bin/hackedbox ? hugs98 hugs98-x11-0:2006.09-8.fc12 ? /usr/lib64/hugs/packages/X11/Graphics/X11/Xlib/Context.so ? /usr/lib64/hugs/packages/X11/Graphics/X11/Xlib/Font.so ? /usr/lib64/hugs/packages/X11/Graphics/X11/Xlib/Misc.so ? icewm icewm-0:1.2.37-5.fc12 ? /usr/bin/icehelp ? /usr/bin/icesh ? /usr/bin/icewm-session ? /usr/bin/icewmbg ? /usr/bin/icewmtray ? /usr/bin/icewm ? idesk idesk-0:0.7.5-9.fc12 ? /usr/bin/idesk ? irsim irsim-0:9.7.68-3.fc12 ? /usr/bin/irsim ? isdn4k-utils xisdnload-0:3.2-67.fc12 ? /usr/bin/xmonisdn ? java-1.6.0-openjdk java-1.6.0-openjdk-1:1.6.0.0-31.b16.fc12 ? /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libsplashscreen.so ? /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/xawt/libmawt.so ? kdebase-workspace kdebase-workspace-0:4.3.2-1.fc12 ? /usr/lib64/kde4/kcm_input.so ? /usr/lib64/libkdeinit4_kwin.so ? kdebase-workspace kdebase-workspace-libs-0:4.3.2-1.fc12 ? /usr/lib64/libkfontinstui.so.4.3.0 ? kdebase-workspace kdm-0:4.3.2-1.fc12 ? /usr/bin/kdm ? /usr/libexec/kde4/kdm_greet ? kdelibs kdelibs-6:4.3.2-4.fc12 ? /usr/lib64/libkdeui.so.5.3.0 ? kdocker kdocker-0:1.3-13.fc12 ? /usr/bin/kdocker ? kinput2 kinput2-0:v3.1-41.fc12 ? /usr/bin/kinput2.canna ? koules koules-x11-0:1.4-8.fc12 ? /usr/bin/xkoules ? lazarus lazarus-0:0.9.26.2-4.fc12 ? /usr/lib64/lazarus/lazarus ? /usr/lib64/lazarus/startlazarus ? /usr/lib64/lazarus/tools/apiwizz/apiwizz ? lesstif lesstif-0:0.95.2-1.fc12 ? /usr/lib64/libMrm.so.2.0.1 ? /usr/lib64/libXm.so.2.0.1 ? lesstif lesstif-mwm-0:0.95.2-1.fc12 ? /usr/bin/mwm ? libXaw libXaw-0:1.0.6-4.fc12 ? /usr/lib64/libXaw7.so.7.0.0 ? libXcursor libXcursor-0:1.1.10-1.fc12 ? /usr/lib64/libXcursor.so.1.0.2 ? libXext libXext-0:1.1-1.fc12 ? /usr/lib64/libXext.so.6.4.0 ? libXmu libXmu-0:1.0.5-1.fc12 ? /usr/lib64/libXmu.so.6.2.0 ? libXt libXt-0:1.0.7-1.fc12 ? /usr/lib64/libXt.so.6.0.0 ? libcaca libcaca-0:0.99-0.9.beta16.fc12 ? /usr/lib64/libcaca.so.0.99.16 ? libsx libsx-0:2.05-18.fc12 ? /usr/lib64/libsx.so.0.0.0 ? lirc lirc-0:0.8.6-1.fc12 ? /usr/bin/xmode2 ? lmms lmms-0:0.4.5-2.fc12 ? /usr/libexec/remote_zynaddsubfx ? lsnipes lsnipes-0:0.9.4-5.fc12 ? /usr/bin/snipes ? lush lush-0:1.2.1-6.fc12 ? /usr/bin/lush ? magic magic-0:8.0.54-1.fc12 ? /usr/lib64/magic/tcl/tclmagic.so ? matchbox-keyboard matchbox-keyboard-0:0.1-0.2009.05.19.1.fc11 ? /usr/bin/matchbox-keyboard ? matchbox-window-manager matchbox-window-manager-0:1.2-6.20070628svn.fc12 ? /usr/bin/matchbox-window-manager ? mesa mesa-libGL-0:7.6-0.13.fc12 ? /usr/lib64/libGL.so.1.2 ? metacity metacity-0:2.28.0-9.fc12 ? /usr/bin/metacity ? mgetty mgetty-viewfax-0:1.1.36-5.fc12 ? /usr/bin/viewfax ? mrxvt mrxvt-0:0.5.3-5.fc12 ? /usr/bin/mrxvt ? mutter mutter-0:2.28.0-2.fc12 ? /usr/bin/mutter ? nabi nabi-0:0.99.3-3.fc12 ? /usr/bin/nabi ? ncl ncl-0:5.1.1-3.fc12 ? /usr/bin/ctrans ? /usr/bin/ictrans ? /usr/bin/idt ? ncview ncview-0:1.93c-6.fc12 ? /usr/bin/ncview ? nedit nedit-0:5.5-22.fc12 ? /usr/bin/nedit ? netpbm netpbm-progs-0:10.47.04-1.fc12 ? /usr/bin/pamx ? ngspice ngspice-0:19-1.fc12 ? /usr/bin/ngnutmeg ? /usr/bin/ngspice ? nx nx-0:3.3.0-38.fc12 ? /usr/lib64/nx/libXext.so.6.4 ? /usr/lib64/nx/libXext.so.6 ? /usr/libexec/nx/nxagent ? ocaml ocaml-0:3.11.1-0.rc1.2.fc12.1 ? /usr/lib64/ocaml/graphics.cmxs ? ocaml ocaml-runtime-0:3.11.1-0.rc1.2.fc12.1 ? /usr/lib64/ocaml/stublibs/dllgraphics.so ? ocaml-lablgl ocaml-lablgl-0:1.04-2.fc12 ? /usr/lib64/ocaml/stublibs/dlltogl.so ? openbox openbox-0:3.4.7.2-11.fc12 ? /usr/bin/openbox ? openoffice.org openoffice.org-core-1:3.1.1-19.14.fc12 ? /usr/lib64/openoffice.org/basis3.1/program/libpsplx.so ? /usr/lib64/openoffice.org/basis3.1/program/libvclplug_genlx.so ? oxine oxine-0:0.7.1-5.fc12 ? /usr/bin/oxine ? pango pango-0:1.26.0-1.fc12 ? /usr/lib64/libpangox-1.0.so.0.2600.0 ? /usr/lib64/libpangoxft-1.0.so.0.2600.0 ? paraview paraview-0:3.6.1-6.fc12 ? /usr/lib64/paraview/libvtkRendering.so.pv3.6 ? paraview paraview-mpi-0:3.6.1-6.fc12 ? /usr/lib64/paraview-mpi/libvtkRendering.so.pv3.6 ? perl-PDL perl-PDL-0:2.4.4_05-5.fc12 ? /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/auto/PDL/Graphics/OpenGL/OpenGL.so ? perl-Tk perl-Tk-0:804.028-10.fc12 ? /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/auto/Tk/Tk.so ? pigment pigment-0:0.3.17-3.fc12 ? /usr/lib64/pigment-0.3/0.3.17/libpgmopengl.so ? pl pl-0:5.7.11-5.fc12 ? /usr/lib64/pl-5.7.11/xpce-6.6.65/lib/x86_64-linux/pl2xpce.so ? plib plib-0:1.8.5-3.fc12 ? /usr/lib64/libplibpw.so.1.8.5 ? plotutils plotutils-0:2.5-7.fc12 ? /usr/lib64/libplot.so.2.2.2 ? /usr/lib64/libplotter.so.2.2.2 ? plplot plplot-libs-0:5.9.5-1.fc12 ? /usr/lib64/plplot5.9.5/driversd/cairo.so ? /usr/lib64/plplot5.9.5/driversd/xwin.so ? plt-scheme plt-scheme-1:4.1.2-3.fc12 ? /usr/bin/mred ? putty putty-0:0.60-5.fc12 ? /usr/bin/pterm ? /usr/bin/puttytel ? /usr/bin/putty ? qt qt-x11-1:4.5.3-7.fc12 ? /usr/lib64/libQtGui.so.4.5.3 ? qt3 qt3-0:3.3.8b-28.fc12 ? /usr/lib64/qt-3.3/lib/libqt-mt.so.3.3.8 ? /usr/lib64/qt-3.3/plugins/inputmethods/libqxim.so ? ratpoison ratpoison-0:1.4.5-2.fc12 ? /usr/bin/ratpoison ? rcssmonitor rcssmonitor-0:13.1.0-3.fc12 ? /usr/bin/rcssmonitor ? root-tail root-tail-0:1.2-6.fc12 ? /usr/bin/root-tail ? rosegarden4 rosegarden4-0:1.7.3-4.fc12 ? /usr/bin/rosegarden ? rxvt rxvt-0:2.7.10-17.fc12 ? /usr/bin/rclock ? /usr/bin/rxvt-2.7.10 ? /usr/bin/rxvt ? rxvt-unicode rxvt-unicode-0:9.06-4.fc12 ? /usr/bin/urxvtd ? /usr/bin/urxvt ? sK1 sK1-0:0.9.1-0.2.pre_rev730.fc12 ? /usr/lib64/python2.6/site-packages/sk1/app/modules/paxmodule.so ? saoimage saoimage-0:1.35.1-7.fc12 ? /usr/bin/saoimage ? scrot scrot-0:0.8-5.fc12 ? /usr/bin/scrot ? seamonkey seamonkey-0:2.0-7.fc12 ? /usr/lib64/seamonkey-2.0/plugins/libnullplugin.so ? skychart skychart-0:3.0.1.5-6.20081026svn.fc11 ? /usr/bin/skychart ? slim slim-0:1.3.1-8.fc12 ? /usr/bin/slim ? squeak-vm squeak-vm-0:3.10.5-2.fc12 ? /usr/lib64/squeak/3.10-5/vm-display-X11 ? starlab starlab-libs-0:4.4.3-7.fc12 ? /usr/lib64/libgfx.so.0.0.0 ? sunbird sunbird-0:1.0-0.12.20090916hg.fc12 ? /usr/lib64/sunbird-1.0pre/plugins/libnullplugin.so ? /usr/lib64/sunbird-1.0pre/plugins/libunixprintplugin.so ? tgif tgif-0:4.2.1-1.fc12 ? /usr/libexec/tgif ? tigervnc tigervnc-0:1.0.0-1.fc12 ? /usr/bin/vncviewer ? tigervnc tigervnc-server-0:1.0.0-1.fc12 ? /usr/bin/vncconfig ? /usr/bin/x0vncserver ? tk tk-1:8.5.7-2.fc12 ? /usr/lib64/libtk8.5.so ? tkgate tkgate-0:2.0-7.beta9.fc12 ? /usr/bin/tkgate ? torsmo torsmo-0:0.18-10.fc12 ? /usr/bin/torsmo ? ucblogo ucblogo-0:6.0-5.fc12 ? /usr/bin/logo ? uim uim-0:1.5.6-2.fc12 ? /usr/bin/uim-xim ? vtk vtk-0:5.4.2-34.fc12 ? /usr/lib64/libvtkRendering.so.5.4.2 ? windowlab windowlab-0:1.37-1.fc12 ? /usr/bin/windowlab ? wine wine-core-0:1.1.29-3.fc12 ? /usr/lib64/wine/winex11.drv.so ? wmctrl wmctrl-0:1.07-7.fc12 ? /usr/bin/wmctrl ? wmx wmx-0:7-5.fc12 ? /usr/bin/wmx ? x11-ssh-askpass x11-ssh-askpass-0:1.2.4.1-7.fc12 ? /usr/libexec/openssh/x11-ssh-askpass ? x11vnc x11vnc-0:0.9.8-14.fc12 ? /usr/bin/x11vnc ? x2vnc x2vnc-0:1.7.2-11.fc12 ? /usr/bin/x2vnc ? x3270 x3270-x11-0:3.3.6-10.fc12 ? /usr/bin/x3270 ? xaos xaos-0:3.5-1.fc12 ? /usr/bin/xaos ? xarchon xarchon-0:0.50-10.fc12 ? /usr/bin/xarchon ? xastir xastir-1:1.9.4-10.fc12 ? /usr/bin/xastir ? xawtv xawtv-0:3.95-12.fc12.1 ? /usr/bin/propwatch ? /usr/bin/xawtv ? xbae xbae-0:4.60.4-12.fc12 ? /usr/lib64/libXbae.so.4.0.60 ? xblast xblast-x11-0:2.10.4-8.fc12 ? /usr/bin/xblast-x11 ? xboard xboard-0:4.2.7-20.fc12 ? /usr/bin/xboard ? xcircuit xcircuit-0:3.6.161-1.fc12 ? /usr/lib64/xcircuit-3.6/xcircuit.so ? xdaliclock xdaliclock-0:2.25-3.fc12 ? /usr/bin/xdaliclock ? xdvik xdvik-0:22.84.14-7.fc12 ? /usr/bin/pxdvi-xaw3d ? /usr/bin/xdvi-xaw3d ? xemacs xemacs-0:21.5.29-6.fc12 ? /usr/bin/xemacs-21.5-b29 ? xfig xfig-0:3.2.5-22.a.fc12 ? /usr/bin/xfig-Xaw3d ? xfig xfig-plain-0:3.2.5-22.a.fc12 ? /usr/bin/xfig-plain ? xforms xforms-0:1.0.92-2.sp2.fc12 ? /usr/lib64/libforms.so.1.1.0 ? xfwm4 xfwm4-0:4.6.1-5.fc12 ? /usr/bin/xfwm4 ? xgalaxy xgalaxy-0:2.0.34-13.fc12 ? /usr/bin/xgalaxy-hyperspace ? /usr/bin/xgalaxy ? xine-plugin xine-plugin-0:1.0.2-3.fc12 ? /usr/lib64/mozilla/plugins/xineplugin.so ? xine-ui xine-ui-0:0.99.5-16.fc12 ? /usr/bin/xine ? xloadimage xloadimage-0:4.1-4.fc12 ? /usr/bin/xloadimage ? xlockmore xlockmore-0:5.28-1.fc12 ? /usr/bin/xlock ? xmbdfed xmbdfed-0:4.7-7.fc12 ? /usr/bin/xmbdfed ? xmonad xmonad-0:0.8.1-15.fc12 ? /usr/bin/xmonad ? xorg-x11-apps xorg-x11-apps-0:7.4-8.fc12 ? /usr/bin/x11perf ? /usr/bin/xbiff ? /usr/bin/xclock ? /usr/bin/xfd ? /usr/bin/xfontsel ? /usr/bin/xkill ? /usr/bin/xmag ? /usr/bin/xwd ? xorg-x11-resutils xorg-x11-resutils-0:7.1-9.fc12 ? /usr/bin/editres ? xorg-x11-server xorg-x11-server-Xdmx-0:1.7.1-7.fc12 ? /usr/bin/Xdmx ? /usr/bin/dmxwininfo ? /usr/bin/xdmxconfig ? xorg-x11-server xorg-x11-server-Xnest-0:1.7.1-7.fc12 ? /usr/bin/Xnest ? xorg-x11-server-utils xorg-x11-server-utils-0:7.4-13.fc12 ? /usr/bin/xsetroot ? /usr/bin/xset ? xorg-x11-twm xorg-x11-twm-1:1.0.3-5.fc12 ? /usr/bin/twm ? xorg-x11-utils xorg-x11-utils-0:7.4-7.fc12 ? /usr/bin/xlsfonts ? /usr/bin/xprop ? /usr/bin/xwininfo ? xorg-x11-xdm xorg-x11-xdm-1:1.1.6-14.fc12 ? /usr/lib64/X11/xdm/libXdmGreet.so ? xosd xosd-0:2.2.14-13.fc12 ? /usr/lib64/libxosd.so.2.2.14 ? xosview xosview-0:1.8.3-17.20080301cvs.fc12 ? /usr/bin/xosview ? xpdf xpdf-1:3.02-15.fc12 ? /usr/bin/xpdf ? xpilot-ng xpilot-ng-0:4.7.2-16.fc11 ? /usr/bin/xpilot-ng-replay ? /usr/bin/xpilot-ng-x11 ? xpilot-ng xpilot-ng-server-0:4.7.2-16.fc11 ? /usr/bin/xpilot-ng-xp-mapedit ? xscreensaver xscreensaver-base-1:5.10-2.fc12 ? /usr/bin/xscreensaver ? xscreensaver xscreensaver-extras-1:5.10-2.fc12 ? /usr/libexec/xscreensaver/abstractile ? /usr/libexec/xscreensaver/anemone ? /usr/libexec/xscreensaver/anemotaxis ? /usr/libexec/xscreensaver/apollonian ? /usr/libexec/xscreensaver/apple2 ? /usr/libexec/xscreensaver/attraction ? /usr/libexec/xscreensaver/barcode ? /usr/libexec/xscreensaver/blaster ? /usr/libexec/xscreensaver/blitspin ? /usr/libexec/xscreensaver/bouboule ? /usr/libexec/xscreensaver/boxfit ? /usr/libexec/xscreensaver/braid ? /usr/libexec/xscreensaver/bsod ? /usr/libexec/xscreensaver/bumps ? /usr/libexec/xscreensaver/ccurve ? /usr/libexec/xscreensaver/celtic ? /usr/libexec/xscreensaver/cloudlife ? /usr/libexec/xscreensaver/compass ? /usr/libexec/xscreensaver/coral ? /usr/libexec/xscreensaver/crystal ? /usr/libexec/xscreensaver/cwaves ? /usr/libexec/xscreensaver/cynosure ? /usr/libexec/xscreensaver/decayscreen ? /usr/libexec/xscreensaver/deco ? /usr/libexec/xscreensaver/deluxe ? /usr/libexec/xscreensaver/demon ? /usr/libexec/xscreensaver/discrete ? /usr/libexec/xscreensaver/distort ? /usr/libexec/xscreensaver/drift ? /usr/libexec/xscreensaver/epicycle ? /usr/libexec/xscreensaver/eruption ? /usr/libexec/xscreensaver/euler2d ? /usr/libexec/xscreensaver/fadeplot ? /usr/libexec/xscreensaver/fiberlamp ? /usr/libexec/xscreensaver/fireworkx ? /usr/libexec/xscreensaver/flame ? /usr/libexec/xscreensaver/flow ? /usr/libexec/xscreensaver/fluidballs ? /usr/libexec/xscreensaver/fontglide ? /usr/libexec/xscreensaver/fuzzyflakes ? /usr/libexec/xscreensaver/galaxy ? /usr/libexec/xscreensaver/goop ? /usr/libexec/xscreensaver/grav ? /usr/libexec/xscreensaver/greynetic ? /usr/libexec/xscreensaver/halftone ? /usr/libexec/xscreensaver/halo ? /usr/libexec/xscreensaver/helix ? /usr/libexec/xscreensaver/hopalong ? /usr/libexec/xscreensaver/ifs ? /usr/libexec/xscreensaver/imsmap ? /usr/libexec/xscreensaver/interaggregate ? /usr/libexec/xscreensaver/interference ? /usr/libexec/xscreensaver/intermomentary ? /usr/libexec/xscreensaver/julia ? /usr/libexec/xscreensaver/kaleidescope ? /usr/libexec/xscreensaver/kumppa ? /usr/libexec/xscreensaver/lcdscrub ? /usr/libexec/xscreensaver/loop ? /usr/libexec/xscreensaver/m6502 ? /usr/libexec/xscreensaver/maze ? /usr/libexec/xscreensaver/memscroller ? /usr/libexec/xscreensaver/metaballs ? /usr/libexec/xscreensaver/moire2 ? /usr/libexec/xscreensaver/moire ? /usr/libexec/xscreensaver/mountain ? /usr/libexec/xscreensaver/munch ? /usr/libexec/xscreensaver/nerverot ? /usr/libexec/xscreensaver/noseguy ? /usr/libexec/xscreensaver/pacman ? /usr/libexec/xscreensaver/pedal ? /usr/libexec/xscreensaver/penetrate ? /usr/libexec/xscreensaver/penrose ? /usr/libexec/xscreensaver/petri ? /usr/libexec/xscreensaver/phosphor ? /usr/libexec/xscreensaver/piecewise ? /usr/libexec/xscreensaver/polyominoes ? /usr/libexec/xscreensaver/pong ? /usr/libexec/xscreensaver/popsquares ? /usr/libexec/xscreensaver/pyro ? /usr/libexec/xscreensaver/qix ? /usr/libexec/xscreensaver/rd-bomb ? /usr/libexec/xscreensaver/ripples ? /usr/libexec/xscreensaver/rocks ? /usr/libexec/xscreensaver/rorschach ? /usr/libexec/xscreensaver/rotzoomer ? /usr/libexec/xscreensaver/shadebobs ? /usr/libexec/xscreensaver/sierpinski ? /usr/libexec/xscreensaver/slidescreen ? /usr/libexec/xscreensaver/slip ? /usr/libexec/xscreensaver/speedmine ? /usr/libexec/xscreensaver/spotlight ? /usr/libexec/xscreensaver/squiral ? /usr/libexec/xscreensaver/starfish ? /usr/libexec/xscreensaver/strange ? /usr/libexec/xscreensaver/substrate ? /usr/libexec/xscreensaver/swirl ? /usr/libexec/xscreensaver/thornbird ? /usr/libexec/xscreensaver/triangle ? /usr/libexec/xscreensaver/truchet ? /usr/libexec/xscreensaver/twang ? /usr/libexec/xscreensaver/vermiculate ? /usr/libexec/xscreensaver/wander ? /usr/libexec/xscreensaver/whirlwindwarp ? /usr/libexec/xscreensaver/wormhole ? /usr/libexec/xscreensaver/xanalogtv ? /usr/libexec/xscreensaver/xflame ? /usr/libexec/xscreensaver/xjack ? /usr/libexec/xscreensaver/xlyap ? /usr/libexec/xscreensaver/xmatrix ? /usr/libexec/xscreensaver/xrayswarm ? /usr/libexec/xscreensaver/xspirograph ? /usr/libexec/xscreensaver/zoom ? xscreensaver xscreensaver-gl-extras-1:5.10-2.fc12 ? /usr/libexec/xscreensaver/antinspect ? /usr/libexec/xscreensaver/antmaze ? /usr/libexec/xscreensaver/antspotlight ? /usr/libexec/xscreensaver/atlantis ? /usr/libexec/xscreensaver/atunnel ? /usr/libexec/xscreensaver/blinkbox ? /usr/libexec/xscreensaver/blocktube ? /usr/libexec/xscreensaver/boing ? /usr/libexec/xscreensaver/bouncingcow ? /usr/libexec/xscreensaver/boxed ? /usr/libexec/xscreensaver/bubble3d ? /usr/libexec/xscreensaver/cage ? /usr/libexec/xscreensaver/carousel ? /usr/libexec/xscreensaver/circuit ? /usr/libexec/xscreensaver/crackberg ? /usr/libexec/xscreensaver/cube21 ? /usr/libexec/xscreensaver/cubenetic ? /usr/libexec/xscreensaver/cubestorm ? /usr/libexec/xscreensaver/cubicgrid ? /usr/libexec/xscreensaver/dangerball ? /usr/libexec/xscreensaver/endgame ? /usr/libexec/xscreensaver/engine ? /usr/libexec/xscreensaver/flipflop ? /usr/libexec/xscreensaver/flipscreen3d ? /usr/libexec/xscreensaver/fliptext ? /usr/libexec/xscreensaver/flurry ? /usr/libexec/xscreensaver/flyingtoasters ? /usr/libexec/xscreensaver/gears ? /usr/libexec/xscreensaver/gflux ? /usr/libexec/xscreensaver/glblur ? /usr/libexec/xscreensaver/glcells ? /usr/libexec/xscreensaver/gleidescope ? /usr/libexec/xscreensaver/glhanoi ? /usr/libexec/xscreensaver/glknots ? /usr/libexec/xscreensaver/glmatrix ? /usr/libexec/xscreensaver/glplanet ? /usr/libexec/xscreensaver/glschool ? /usr/libexec/xscreensaver/glslideshow ? /usr/libexec/xscreensaver/glsnake ? /usr/libexec/xscreensaver/gltext ? /usr/libexec/xscreensaver/hypertorus ? /usr/libexec/xscreensaver/hypnowheel ? /usr/libexec/xscreensaver/jigglypuff ? /usr/libexec/xscreensaver/jigsaw ? /usr/libexec/xscreensaver/juggler3d ? /usr/libexec/xscreensaver/klein ? /usr/libexec/xscreensaver/lament ? /usr/libexec/xscreensaver/lavalite ? /usr/libexec/xscreensaver/lockward ? /usr/libexec/xscreensaver/menger ? /usr/libexec/xscreensaver/mirrorblob ? /usr/libexec/xscreensaver/moebiusgears ? /usr/libexec/xscreensaver/moebius ? /usr/libexec/xscreensaver/molecule ? /usr/libexec/xscreensaver/morph3d ? /usr/libexec/xscreensaver/noof ? /usr/libexec/xscreensaver/photopile ? /usr/libexec/xscreensaver/pinion ? /usr/libexec/xscreensaver/pipes ? /usr/libexec/xscreensaver/polyhedra ? /usr/libexec/xscreensaver/polytopes ? /usr/libexec/xscreensaver/providence ? /usr/libexec/xscreensaver/pulsar ? /usr/libexec/xscreensaver/queens ? /usr/libexec/xscreensaver/rubikblocks ? /usr/libexec/xscreensaver/rubik ? /usr/libexec/xscreensaver/sballs ? /usr/libexec/xscreensaver/sierpinski3d ? /usr/libexec/xscreensaver/skytentacles ? /usr/libexec/xscreensaver/sonar ? /usr/libexec/xscreensaver/spheremonics ? /usr/libexec/xscreensaver/sproingies ? /usr/libexec/xscreensaver/stairs ? /usr/libexec/xscreensaver/starwars ? /usr/libexec/xscreensaver/stonerview ? /usr/libexec/xscreensaver/superquadrics ? /usr/libexec/xscreensaver/surfaces ? /usr/libexec/xscreensaver/tangram ? /usr/libexec/xscreensaver/timetunnel ? /usr/libexec/xscreensaver/topblock ? /usr/libexec/xscreensaver/voronoi ? xstar xstar-0:2.2.0-5.fc12 ? /usr/bin/xstar ? xteddy xteddy-0:2.0.1-5.fc12 ? /usr/bin/xteddy ? xterm xterm-0:248-2.fc12 ? /usr/bin/xterm ? xtide xtide-0:2.10-5.fc12 ? /usr/bin/xtide ? xulrunner xulrunner-0:1.9.1.4-1.fc12 ? /usr/lib64/xulrunner-1.9.1/plugins/libnullplugin.so ? /usr/lib64/xulrunner-1.9.1/plugins/libunixprintplugin.so ? xwrits xwrits-0:2.24-6.fc12 ? /usr/bin/xwrits ? yadex yadex-0:1.7.0-13.fc12 ? /usr/bin/yadex-1.7.0 ? http://xfree86.org/pipermail/forum/2003-March/000799.html -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From j.w.r.degoede at hhs.nl Wed Nov 11 12:41:37 2009 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 11 Nov 2009 13:41:37 +0100 Subject: Identifying remaining core font users In-Reply-To: <1257941463.841.37.camel@arekh.okg> References: <1257941463.841.37.camel@arekh.okg> Message-ID: <4AFAB101.4030309@hhs.nl> On 11/11/2009 01:11 PM, Nicolas Mailhot wrote: > Hi, > > It has been plain since 2003? our new font access standard would be > fontconfig. Since then most users of the old core fonts X11 backend have > migrated, but there are still a few stragglers. > > Unfortunately these stragglers matter. Core fonts were not good in 2003, > and they didn't get any better since. Few users means life-support > maintenance only, no one to replace/fix core fonts when a technical or > legal problem causes them to be dropped, no one to update them when > encoding standards change. Also, few users means we do not install core > font packages by default anymore, so packagers that depend on them but > forgot to mark the deps in their packages will deliver broken packages > to users. > > Every remaining core font user is therefore likely to hit more and more > problems as time passes. Each of those problems produces as a side > effect "Fedora fonts suck" messages on the Internet, messages that > detract on all the terrific work Fedora people do on our main font > backend (and associated fonts). End-users are not educated enough to > recognize the root of their problems is the use of a deprecated > almost-no-maintained tech (and they should not have to bother about it). > > Therefore, I'd like to identify remaining core font users, and remind > them periodically their core font use is not good for their users or for > Fedora. > > Since there is not question of deliberately removing core fonts > infrastructure from Fedora, I need to whitelist first the few files used > to maintain this infrastructure (xfontsel and xlsfonts are such files; > twm and gtk1 ? not). I'd therefore be grateful if people checked the > following list and pointed to me files that need to be removed for this > reason. > > Please answer this message with statements such as "file foo can be > removed from the list because it is used this way to manage the core > fonts backend or to propagate the core font protocol to X11 clients". > > Again, widget libraries or utilities that made use of the core fonts > backend when it was the font access standard, do not count. Also modern > libraries that have some form of vestigial core fonts code hidden deep > inside them should probably just excise it (this use it probably worse > than apps that only use core fonts , since those apps at least test > regularly if their core fonts use is not totally broken). > Hi, It would help tremendously to know how you generated this list of files / packages which allegedly use Core Fonts, there are quite a few packages of mine there, but in many cases I have no idea as to why they are here. For example there are some OpenGL libs in there which have absolutely nothing to do with fonts in any way, so I think your algorithm for generating this list needs some serious work, starting with publishing the algorithm. Regards, Hans > ? 9wm 9wm-0:1.2-2.fc12 > ? /usr/bin/9wm > ? ClanLib ClanLib-0:1.0.0-3.fc12 > ? /usr/lib64/libclanGL.so.1.0.0 > ? GMT xgridedit-0:4.5.1-1.fc12 > ? /usr/bin/xgridedit > ? Glide3-libGL Glide3-libGL-0:6.2.1-10.fc12 > ? /usr/lib64/Glide3-libGL/libGL.so.1.5.060201 > ? GraphicsMagick GraphicsMagick-0:1.3.7-1.fc12 > ? /usr/lib64/libGraphicsMagick.so.3.2.0 > ? ImageMagick ImageMagick-0:6.5.4.7-3.fc12 > ? /usr/lib64/libMagickCore.so.2.0.0 > ? MagicPoint MagicPoint-0:1.11b-10.fc12 > ? /usr/bin/mgp2ps > ? /usr/bin/mgp > ? /usr/bin/xwintoppm > ? OpenSceneGraph OpenSceneGraph-libs-0:2.8.2-3.fc12 > ? /usr/lib64/libosgViewer.so.2.8.2 > ? R R-core-0:2.9.2-1.fc12 > ? /usr/lib64/R/modules/R_X11.so > ? TeXmacs TeXmacs-0:1.0.7.2-2.fc12 > ? /usr/libexec/TeXmacs/bin/texmacs.bin > ? WindowMaker WINGs-libs-0:0.92.0-20.fc12 > ? /usr/lib64/libExtraWINGs.so.0.0.0 > ? /usr/lib64/libWINGs.so.2.0.1 > ? WindowMaker WindowMaker-0:0.92.0-20.fc12 > ? /usr/bin/wmaker > ? Xaw3d Xaw3d-0:1.5E-15.fc12 > ? /usr/lib64/libXaw3d.so.7.0 > ? aalib aalib-libs-0:1.4.0-0.18.rc5.fc12 > ? /usr/lib64/libaa.so.1.0.4 > ? allegro allegro-0:4.2.2-14.fc12 > ? /usr/lib64/liballeg-4.2.2.so > ? allegro allegro-devel-0:4.2.2-14.fc12 > ? /usr/lib64/liballd-4.2.2.so > ? /usr/lib64/liballp-4.2.2.so > ? alliance alliance-0:5.0-31.20090901snap.fc12 > ? /usr/lib64/alliance/bin/dreal > ? /usr/lib64/alliance/bin/graal > ? /usr/lib64/alliance/bin/xfsm > ? /usr/lib64/alliance/bin/xgra > ? /usr/lib64/alliance/bin/xpat > ? /usr/lib64/alliance/bin/xsch > ? /usr/lib64/alliance/bin/xvpn > ? alltray alltray-0:0.70-4.fc12 > ? /usr/bin/alltray > ? aplus-fsf aplus-fsf-0:4.22.4-19.fc12 > ? /usr/lib64/aplus-fsf/4.22.4/libAplusGUI.so > ? /usr/lib64/aplus-fsf/4.22.4/libMSGUI.so > ? atari++ atari++-0:1.57-1.fc12 > ? /usr/bin/atari++ > ? aterm aterm-0:1.0.1-6.fc12 > ? /usr/bin/aterm > ? blackbox blackbox-0:0.70.1-14 > ? /usr/bin/blackbox > ? /usr/lib64/libbt.so.0.0.0 > ? blender blender-0:2.49b-1.fc12 > ? /usr/bin/blender.bin > ? blender blenderplayer-0:2.49b-1.fc12 > ? /usr/bin/blenderplayer.bin > ? brltty brltty-xw-0:4.1-3.fc12 > ? /lib64/brltty/libbrlttybxw.so > ? cernlib cernlib-0:2006-34.fc12 > ? /usr/lib64/cernlib/2006/lib/libgrafX11.so.1_gfortran.2006 > ? /usr/lib64/cernlib/2006/lib/libpacklib-lesstif.so.1_gfortran.2006 > ? /usr/lib64/cernlib/2006/lib/libpawlib-lesstif.so.3_gfortran.2006 > ? cernlib cernlib-packlib-gfortran-0:2006-34.fc12 > ? /usr/bin/kxterm-gfortran > ? cernlib paw-gfortran-0:2006-34.fc12 > ? /usr/bin/paw++-gfortran > ? /usr/bin/pawX11-gfortran > ? cernlib-g77 cernlib-g77-0:2006-33.fc12 > ? /usr/lib64/cernlib/2006-g77/lib/libgrafX11.so.1.2006 > ? /usr/lib64/cernlib/2006-g77/lib/libpacklib-lesstif.so.1.2006 > ? /usr/lib64/cernlib/2006-g77/lib/libpawlib-lesstif.so.3.2006 > ? cernlib-g77 cernlib-packlib-0:2006-33.fc12 > ? /usr/bin/kxterm > ? cernlib-g77 cernlib-packlib-g77-0:2006-33.fc12 > ? /usr/bin/kxterm-g77 > ? cernlib-g77 paw-0:2006-33.fc12 > ? /usr/bin/paw++ > ? /usr/bin/pawX11 > ? cernlib-g77 paw-g77-0:2006-33.fc12 > ? /usr/bin/paw++-g77 > ? /usr/bin/pawX11-g77 > ? cgoban cgoban-0:1.9.14-12.fc12 > ? /usr/bin/cgoban > ? cinepaint cinepaint-0:0.22.1-14.fc12 > ? /usr/bin/cinepaint > ? clips clips-xclips-0:6.30.0-0.1.20090722svn.fc12 > ? /usr/bin/xclips > ? clisp clisp-0:2.47-4.fc12 > ? /usr/lib64/clisp-2.47/full/lisp.run > ? compiz compiz-0:0.8.2-19.fc12 > ? /usr/bin/compiz > ? /usr/lib64/compiz/libmove.so > ? /usr/lib64/compiz/libresize.so > ? /usr/lib64/compiz/libscale.so > ? /usr/lib64/compiz/libzoom.so > ? compiz compiz-gnome-0:0.8.2-19.fc12 > ? /usr/bin/gtk-window-decorator > ? compiz compiz-kde-0:0.8.2-19.fc12 > ? /usr/bin/kde4-window-decorator > ? compiz-fusion compiz-fusion-0:0.8.2-4.fc12 > ? /usr/lib64/compiz/libshift.so > ? compiz-fusion-extras compiz-fusion-extras-0:0.8.2-2.fc12 > ? /usr/lib64/compiz/libshelf.so > ? /usr/lib64/compiz/libwidget.so > ? conky conky-0:1.7.2-1.fc12 > ? /usr/bin/conky > ? control-center control-center-1:2.28.1-4.fc12 > ? /usr/bin/gnome-appearance-properties > ? /usr/bin/gnome-font-viewer > ? crossfire-client crossfire-client-0:1.11.0-3.fc12 > ? /usr/bin/cfclient > ? crystalspace crystalspace-0:1.2.1-6.fc12 > ? /usr/lib64/crystalspace-1.2/xwin.so > ? ddd ddd-0:3.3.12-5.fc12 > ? /usr/bin/ddd > ? dillo dillo-0:0.8.6-11.fc12 > ? /usr/bin/dillo-i18n > ? dinotrace dinotrace-0:9.4a-5.fc12 > ? /usr/bin/dinotrace > ? ds9 ds9-0:5.4-7.fc12 > ? /usr/bin/ds9 > ? dx dx-0:4.4.4-10.fc12 > ? /usr/lib64/dx/bin_linux/builder > ? /usr/lib64/dx/bin_linux/dxexec > ? /usr/lib64/dx/bin_linux/dxui > ? /usr/lib64/dx/bin_linux/prompter > ? /usr/lib64/dx/bin_linux/startupui > ? /usr/lib64/dx/bin_linux/tutor > ? dx dx-libs-0:4.4.4-10.fc12 > ? /usr/lib64/libDX.so.4.0.44 > ? /usr/lib64/libDXcallm.so.4.0.44 > ? dzen2 dzen2-0:0.8.5-5.fc12 > ? /usr/bin/dzen2-textwidth > ? /usr/bin/dzen2 > ? e16 e16-0:0.16.8.15-3.fc12 > ? /usr/bin/e16 > ? /usr/bin/edox > ? easystroke easystroke-0:0.4.9-1.fc12 > ? /usr/bin/easystroke > ? ecore ecore-0:0.9.9.050-7.fc12 > ? /usr/lib64/libecore_x.so.0.9.9 > ? efte efte-0:1.1-1.fc12 > ? /usr/bin/efte > ? emacs emacs-1:23.1-10.fc12 > ? /usr/bin/emacs-23.1 > ? emerald emerald-0:0.8.2-2.fc12 > ? /usr/bin/emerald > ? enlightenment enlightenment-0:0.16.999.050-5.fc12 > ? /usr/bin/enlightenment > ? eterm eterm-0:0.9.5-6.fc12 > ? /usr/lib64/libEterm-0.9.5.so > ? exim exim-mon-0:4.69-17.fc12 > ? /usr/sbin/eximon.bin > ? fbdesk fbdesk-0:1.4.1-6.fc12 > ? /usr/bin/fbdesk > ? fltk fltk-0:1.1.9-6.fc12 > ? /usr/lib64/libfltk.so.1.1 > ? fluxbox fluxbox-0:1.1.1-5.fc12 > ? /usr/bin/fbrun > ? /usr/bin/fbsetroot > ? /usr/bin/fluxbox > ? fontforge fontforge-0:20090622-2.fc12 > ? /usr/lib64/libgdraw.so.4.0.7 > ? freefem++ freefem++-0:3.5-2.fc12 > ? /usr/bin/FreeFem++-x11 > ? /usr/bin/drawbdmesh > ? freefem++ freefem++-glx-0:3.5-2.fc12 > ? /usr/bin/FreeFem++-glx > ? freeglut freeglut-0:2.6.0-0.2.rc1.fc12 > ? /usr/lib64/libglut.so.3.9.0 > ? freetype freetype-demos-0:2.3.9-6.fc12 > ? /usr/bin/ftdiff > ? /usr/bin/ftgamma > ? /usr/bin/ftgrid > ? /usr/bin/ftmulti > ? /usr/bin/ftstring > ? /usr/bin/ftview > ? fvwm fvwm-0:2.5.26-4.fc12 > ? /usr/bin/fvwm > ? /usr/libexec/fvwm/2.5.26/FvwmButtons > ? /usr/libexec/fvwm/2.5.26/FvwmDragWell > ? /usr/libexec/fvwm/2.5.26/FvwmForm > ? /usr/libexec/fvwm/2.5.26/FvwmIconBox > ? /usr/libexec/fvwm/2.5.26/FvwmIconMan > ? /usr/libexec/fvwm/2.5.26/FvwmIdent > ? /usr/libexec/fvwm/2.5.26/FvwmPager > ? /usr/libexec/fvwm/2.5.26/FvwmProxy > ? /usr/libexec/fvwm/2.5.26/FvwmScript > ? /usr/libexec/fvwm/2.5.26/FvwmScroll > ? /usr/libexec/fvwm/2.5.26/FvwmTaskBar > ? /usr/libexec/fvwm/2.5.26/FvwmWinList > ? gabedit gabedit-0:2.2.4-1.fc12 > ? /usr/bin/gabedit > ? gambas2 gambas2-gb-sdl-0:2.17.0-1.fc12 > ? /usr/lib64/gambas2/gb.sdl.so.0.0.0 > ? gbdfed gbdfed-0:1.5-1.fc12 > ? /usr/bin/gbdfed > ? gcl gcl-0:2.6.8-0.6.20090701cvs.fc12 > ? /usr/lib/gcl-2.6.8/unixport/saved_ansi_gcl > ? gdm gdm-1:2.28.1-24.fc12 > ? /usr/libexec/gdm-factory-slave > ? /usr/libexec/gdm-product-slave > ? /usr/libexec/gdm-simple-slave > ? /usr/libexec/gdm-xdmcp-chooser-slave > ? gds2pov gds2pov-0:0.20080229-3.fc12 > ? /usr/bin/gdsoglviewer > ? geomview geomview-0:1.9.4-10.fc12 > ? /usr/libexec/geomview/animate > ? /usr/libexec/geomview/gvx > ? ghostscript ghostscript-0:8.70-1.fc12 > ? /usr/lib64/ghostscript/8.70/X11.so > ? giflib giflib-utils-0:4.1.6-3.fc12 > ? /usr/bin/gif2x11 > ? gifsicle gifview-0:1.55-2.fc12 > ? /usr/bin/gifview > ? gimp gimp-2:2.6.7-2.fc12 > ? /usr/lib64/gimp/2.0/plug-ins/screenshot > ? gle gle-0:4.2.0-4.fc12 > ? /usr/lib64/libgle-graphics-4.2.0.so > ? glest glest-0:3.2.2-1.fc12 > ? /usr/libexec/glest/glest > ? gnome-libs gnome-libs-1:1.4.2-15.fc12 > ? /usr/lib64/libgnomeui.so.32.14.1 > ? /usr/lib64/libgtkxmhtml.so.1.0.1 > ? /usr/lib64/libzvt.so.2.3.0 > ? gnome-settings-daemon gnome-settings-daemon-0:2.28.1-5.fc12 > ? /usr/lib64/gnome-settings-daemon-2.0/libfont.so > ? gnuplot gnuplot-common-0:4.2.6-1.fc12 > ? /usr/libexec/gnuplot/4.2/gnuplot_x11 > ? grace grace-0:5.1.22-5.fc12 > ? /usr/bin/gracebat > ? /usr/bin/xmgrace > ? grads grads-0:1.9b4-28.fc12 > ? /usr/bin/gradsc > ? /usr/bin/gradsdods > ? /usr/bin/gradshdf > ? /usr/bin/gradsnc > ? /usr/bin/gxtran > ? graphviz graphviz-0:2.20.3-5.fc12.1 > ? /usr/bin/lefty > ? grass grass-0:6.3.0-14.fc12 > ? /usr/lib64/grass-6.3.0/driver/XDRIVER > ? /usr/lib64/grass-6.3.0/etc/nviz2.2/nviz > ? gridengine gridengine-qmon-0:6.2u3-3.fc12 > ? /usr/bin/qmon > ? groff groff-gxditview-0:1.18.1.4-18.fc12 > ? /usr/bin/gxditview > ? gromacs gromacs-0:4.0.4-2.fc11 > ? /usr/bin/g_highway_d > ? /usr/bin/g_highway > ? /usr/bin/g_ngmx_d > ? /usr/bin/g_ngmx > ? /usr/bin/g_xrama_d > ? /usr/bin/g_xrama > ? gtk+ gtk+-1:1.2.10-69.fc12 > ? /usr/lib64/libgdk-1.2.so.0.9.1 > ? /usr/lib64/libgtk-1.2.so.0.9.1 > ? gtk2 gtk2-0:2.18.3-19.fc12 > ? /usr/lib64/libgdk-x11-2.0.so.0.1800.3 > ? gv gv-0:3.6.7-2.fc12 > ? /usr/bin/ghostview > ? /usr/bin/gv > ? gxine gxine-0:0.5.903-4.fc12 > ? /usr/bin/gxine > ? hackedbox hackedbox-0:0.8.5-7.fc12 > ? /usr/bin/hackedbox > ? hugs98 hugs98-x11-0:2006.09-8.fc12 > ? /usr/lib64/hugs/packages/X11/Graphics/X11/Xlib/Context.so > ? /usr/lib64/hugs/packages/X11/Graphics/X11/Xlib/Font.so > ? /usr/lib64/hugs/packages/X11/Graphics/X11/Xlib/Misc.so > ? icewm icewm-0:1.2.37-5.fc12 > ? /usr/bin/icehelp > ? /usr/bin/icesh > ? /usr/bin/icewm-session > ? /usr/bin/icewmbg > ? /usr/bin/icewmtray > ? /usr/bin/icewm > ? idesk idesk-0:0.7.5-9.fc12 > ? /usr/bin/idesk > ? irsim irsim-0:9.7.68-3.fc12 > ? /usr/bin/irsim > ? isdn4k-utils xisdnload-0:3.2-67.fc12 > ? /usr/bin/xmonisdn > ? java-1.6.0-openjdk java-1.6.0-openjdk-1:1.6.0.0-31.b16.fc12 > ? /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libsplashscreen.so ? /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/xawt/libmawt.so > ? kdebase-workspace kdebase-workspace-0:4.3.2-1.fc12 > ? /usr/lib64/kde4/kcm_input.so > ? /usr/lib64/libkdeinit4_kwin.so > ? kdebase-workspace kdebase-workspace-libs-0:4.3.2-1.fc12 > ? /usr/lib64/libkfontinstui.so.4.3.0 > ? kdebase-workspace kdm-0:4.3.2-1.fc12 > ? /usr/bin/kdm > ? /usr/libexec/kde4/kdm_greet > ? kdelibs kdelibs-6:4.3.2-4.fc12 > ? /usr/lib64/libkdeui.so.5.3.0 > ? kdocker kdocker-0:1.3-13.fc12 > ? /usr/bin/kdocker > ? kinput2 kinput2-0:v3.1-41.fc12 > ? /usr/bin/kinput2.canna > ? koules koules-x11-0:1.4-8.fc12 > ? /usr/bin/xkoules > ? lazarus lazarus-0:0.9.26.2-4.fc12 > ? /usr/lib64/lazarus/lazarus > ? /usr/lib64/lazarus/startlazarus > ? /usr/lib64/lazarus/tools/apiwizz/apiwizz > ? lesstif lesstif-0:0.95.2-1.fc12 > ? /usr/lib64/libMrm.so.2.0.1 > ? /usr/lib64/libXm.so.2.0.1 > ? lesstif lesstif-mwm-0:0.95.2-1.fc12 > ? /usr/bin/mwm > ? libXaw libXaw-0:1.0.6-4.fc12 > ? /usr/lib64/libXaw7.so.7.0.0 > ? libXcursor libXcursor-0:1.1.10-1.fc12 > ? /usr/lib64/libXcursor.so.1.0.2 > ? libXext libXext-0:1.1-1.fc12 > ? /usr/lib64/libXext.so.6.4.0 > ? libXmu libXmu-0:1.0.5-1.fc12 > ? /usr/lib64/libXmu.so.6.2.0 > ? libXt libXt-0:1.0.7-1.fc12 > ? /usr/lib64/libXt.so.6.0.0 > ? libcaca libcaca-0:0.99-0.9.beta16.fc12 > ? /usr/lib64/libcaca.so.0.99.16 > ? libsx libsx-0:2.05-18.fc12 > ? /usr/lib64/libsx.so.0.0.0 > ? lirc lirc-0:0.8.6-1.fc12 > ? /usr/bin/xmode2 > ? lmms lmms-0:0.4.5-2.fc12 > ? /usr/libexec/remote_zynaddsubfx > ? lsnipes lsnipes-0:0.9.4-5.fc12 > ? /usr/bin/snipes > ? lush lush-0:1.2.1-6.fc12 > ? /usr/bin/lush > ? magic magic-0:8.0.54-1.fc12 > ? /usr/lib64/magic/tcl/tclmagic.so > ? matchbox-keyboard matchbox-keyboard-0:0.1-0.2009.05.19.1.fc11 > ? /usr/bin/matchbox-keyboard > ? matchbox-window-manager > matchbox-window-manager-0:1.2-6.20070628svn.fc12 > ? /usr/bin/matchbox-window-manager > ? mesa mesa-libGL-0:7.6-0.13.fc12 > ? /usr/lib64/libGL.so.1.2 > ? metacity metacity-0:2.28.0-9.fc12 > ? /usr/bin/metacity > ? mgetty mgetty-viewfax-0:1.1.36-5.fc12 > ? /usr/bin/viewfax > ? mrxvt mrxvt-0:0.5.3-5.fc12 > ? /usr/bin/mrxvt > ? mutter mutter-0:2.28.0-2.fc12 > ? /usr/bin/mutter > ? nabi nabi-0:0.99.3-3.fc12 > ? /usr/bin/nabi > ? ncl ncl-0:5.1.1-3.fc12 > ? /usr/bin/ctrans > ? /usr/bin/ictrans > ? /usr/bin/idt > ? ncview ncview-0:1.93c-6.fc12 > ? /usr/bin/ncview > ? nedit nedit-0:5.5-22.fc12 > ? /usr/bin/nedit > ? netpbm netpbm-progs-0:10.47.04-1.fc12 > ? /usr/bin/pamx > ? ngspice ngspice-0:19-1.fc12 > ? /usr/bin/ngnutmeg > ? /usr/bin/ngspice > ? nx nx-0:3.3.0-38.fc12 > ? /usr/lib64/nx/libXext.so.6.4 > ? /usr/lib64/nx/libXext.so.6 > ? /usr/libexec/nx/nxagent > ? ocaml ocaml-0:3.11.1-0.rc1.2.fc12.1 > ? /usr/lib64/ocaml/graphics.cmxs > ? ocaml ocaml-runtime-0:3.11.1-0.rc1.2.fc12.1 > ? /usr/lib64/ocaml/stublibs/dllgraphics.so > ? ocaml-lablgl ocaml-lablgl-0:1.04-2.fc12 > ? /usr/lib64/ocaml/stublibs/dlltogl.so > ? openbox openbox-0:3.4.7.2-11.fc12 > ? /usr/bin/openbox > ? openoffice.org openoffice.org-core-1:3.1.1-19.14.fc12 > ? /usr/lib64/openoffice.org/basis3.1/program/libpsplx.so > ? /usr/lib64/openoffice.org/basis3.1/program/libvclplug_genlx.so > ? oxine oxine-0:0.7.1-5.fc12 > ? /usr/bin/oxine > ? pango pango-0:1.26.0-1.fc12 > ? /usr/lib64/libpangox-1.0.so.0.2600.0 > ? /usr/lib64/libpangoxft-1.0.so.0.2600.0 > ? paraview paraview-0:3.6.1-6.fc12 > ? /usr/lib64/paraview/libvtkRendering.so.pv3.6 > ? paraview paraview-mpi-0:3.6.1-6.fc12 > ? /usr/lib64/paraview-mpi/libvtkRendering.so.pv3.6 > ? perl-PDL perl-PDL-0:2.4.4_05-5.fc12 > ? /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/auto/PDL/Graphics/OpenGL/OpenGL.so > ? perl-Tk perl-Tk-0:804.028-10.fc12 > ? /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/auto/Tk/Tk.so > ? pigment pigment-0:0.3.17-3.fc12 > ? /usr/lib64/pigment-0.3/0.3.17/libpgmopengl.so > ? pl pl-0:5.7.11-5.fc12 > ? /usr/lib64/pl-5.7.11/xpce-6.6.65/lib/x86_64-linux/pl2xpce.so > ? plib plib-0:1.8.5-3.fc12 > ? /usr/lib64/libplibpw.so.1.8.5 > ? plotutils plotutils-0:2.5-7.fc12 > ? /usr/lib64/libplot.so.2.2.2 > ? /usr/lib64/libplotter.so.2.2.2 > ? plplot plplot-libs-0:5.9.5-1.fc12 > ? /usr/lib64/plplot5.9.5/driversd/cairo.so > ? /usr/lib64/plplot5.9.5/driversd/xwin.so > ? plt-scheme plt-scheme-1:4.1.2-3.fc12 > ? /usr/bin/mred > ? putty putty-0:0.60-5.fc12 > ? /usr/bin/pterm > ? /usr/bin/puttytel > ? /usr/bin/putty > ? qt qt-x11-1:4.5.3-7.fc12 > ? /usr/lib64/libQtGui.so.4.5.3 > ? qt3 qt3-0:3.3.8b-28.fc12 > ? /usr/lib64/qt-3.3/lib/libqt-mt.so.3.3.8 > ? /usr/lib64/qt-3.3/plugins/inputmethods/libqxim.so > ? ratpoison ratpoison-0:1.4.5-2.fc12 > ? /usr/bin/ratpoison > ? rcssmonitor rcssmonitor-0:13.1.0-3.fc12 > ? /usr/bin/rcssmonitor > ? root-tail root-tail-0:1.2-6.fc12 > ? /usr/bin/root-tail > ? rosegarden4 rosegarden4-0:1.7.3-4.fc12 > ? /usr/bin/rosegarden > ? rxvt rxvt-0:2.7.10-17.fc12 > ? /usr/bin/rclock > ? /usr/bin/rxvt-2.7.10 > ? /usr/bin/rxvt > ? rxvt-unicode rxvt-unicode-0:9.06-4.fc12 > ? /usr/bin/urxvtd > ? /usr/bin/urxvt > ? sK1 sK1-0:0.9.1-0.2.pre_rev730.fc12 > ? /usr/lib64/python2.6/site-packages/sk1/app/modules/paxmodule.so > ? saoimage saoimage-0:1.35.1-7.fc12 > ? /usr/bin/saoimage > ? scrot scrot-0:0.8-5.fc12 > ? /usr/bin/scrot > ? seamonkey seamonkey-0:2.0-7.fc12 > ? /usr/lib64/seamonkey-2.0/plugins/libnullplugin.so > ? skychart skychart-0:3.0.1.5-6.20081026svn.fc11 > ? /usr/bin/skychart > ? slim slim-0:1.3.1-8.fc12 > ? /usr/bin/slim > ? squeak-vm squeak-vm-0:3.10.5-2.fc12 > ? /usr/lib64/squeak/3.10-5/vm-display-X11 > ? starlab starlab-libs-0:4.4.3-7.fc12 > ? /usr/lib64/libgfx.so.0.0.0 > ? sunbird sunbird-0:1.0-0.12.20090916hg.fc12 > ? /usr/lib64/sunbird-1.0pre/plugins/libnullplugin.so > ? /usr/lib64/sunbird-1.0pre/plugins/libunixprintplugin.so > ? tgif tgif-0:4.2.1-1.fc12 > ? /usr/libexec/tgif > ? tigervnc tigervnc-0:1.0.0-1.fc12 > ? /usr/bin/vncviewer > ? tigervnc tigervnc-server-0:1.0.0-1.fc12 > ? /usr/bin/vncconfig > ? /usr/bin/x0vncserver > ? tk tk-1:8.5.7-2.fc12 > ? /usr/lib64/libtk8.5.so > ? tkgate tkgate-0:2.0-7.beta9.fc12 > ? /usr/bin/tkgate > ? torsmo torsmo-0:0.18-10.fc12 > ? /usr/bin/torsmo > ? ucblogo ucblogo-0:6.0-5.fc12 > ? /usr/bin/logo > ? uim uim-0:1.5.6-2.fc12 > ? /usr/bin/uim-xim > ? vtk vtk-0:5.4.2-34.fc12 > ? /usr/lib64/libvtkRendering.so.5.4.2 > ? windowlab windowlab-0:1.37-1.fc12 > ? /usr/bin/windowlab > ? wine wine-core-0:1.1.29-3.fc12 > ? /usr/lib64/wine/winex11.drv.so > ? wmctrl wmctrl-0:1.07-7.fc12 > ? /usr/bin/wmctrl > ? wmx wmx-0:7-5.fc12 > ? /usr/bin/wmx > ? x11-ssh-askpass x11-ssh-askpass-0:1.2.4.1-7.fc12 > ? /usr/libexec/openssh/x11-ssh-askpass > ? x11vnc x11vnc-0:0.9.8-14.fc12 > ? /usr/bin/x11vnc > ? x2vnc x2vnc-0:1.7.2-11.fc12 > ? /usr/bin/x2vnc > ? x3270 x3270-x11-0:3.3.6-10.fc12 > ? /usr/bin/x3270 > ? xaos xaos-0:3.5-1.fc12 > ? /usr/bin/xaos > ? xarchon xarchon-0:0.50-10.fc12 > ? /usr/bin/xarchon > ? xastir xastir-1:1.9.4-10.fc12 > ? /usr/bin/xastir > ? xawtv xawtv-0:3.95-12.fc12.1 > ? /usr/bin/propwatch > ? /usr/bin/xawtv > ? xbae xbae-0:4.60.4-12.fc12 > ? /usr/lib64/libXbae.so.4.0.60 > ? xblast xblast-x11-0:2.10.4-8.fc12 > ? /usr/bin/xblast-x11 > ? xboard xboard-0:4.2.7-20.fc12 > ? /usr/bin/xboard > ? xcircuit xcircuit-0:3.6.161-1.fc12 > ? /usr/lib64/xcircuit-3.6/xcircuit.so > ? xdaliclock xdaliclock-0:2.25-3.fc12 > ? /usr/bin/xdaliclock > ? xdvik xdvik-0:22.84.14-7.fc12 > ? /usr/bin/pxdvi-xaw3d > ? /usr/bin/xdvi-xaw3d > ? xemacs xemacs-0:21.5.29-6.fc12 > ? /usr/bin/xemacs-21.5-b29 > ? xfig xfig-0:3.2.5-22.a.fc12 > ? /usr/bin/xfig-Xaw3d > ? xfig xfig-plain-0:3.2.5-22.a.fc12 > ? /usr/bin/xfig-plain > ? xforms xforms-0:1.0.92-2.sp2.fc12 > ? /usr/lib64/libforms.so.1.1.0 > ? xfwm4 xfwm4-0:4.6.1-5.fc12 > ? /usr/bin/xfwm4 > ? xgalaxy xgalaxy-0:2.0.34-13.fc12 > ? /usr/bin/xgalaxy-hyperspace > ? /usr/bin/xgalaxy > ? xine-plugin xine-plugin-0:1.0.2-3.fc12 > ? /usr/lib64/mozilla/plugins/xineplugin.so > ? xine-ui xine-ui-0:0.99.5-16.fc12 > ? /usr/bin/xine > ? xloadimage xloadimage-0:4.1-4.fc12 > ? /usr/bin/xloadimage > ? xlockmore xlockmore-0:5.28-1.fc12 > ? /usr/bin/xlock > ? xmbdfed xmbdfed-0:4.7-7.fc12 > ? /usr/bin/xmbdfed > ? xmonad xmonad-0:0.8.1-15.fc12 > ? /usr/bin/xmonad > ? xorg-x11-apps xorg-x11-apps-0:7.4-8.fc12 > ? /usr/bin/x11perf > ? /usr/bin/xbiff > ? /usr/bin/xclock > ? /usr/bin/xfd > ? /usr/bin/xfontsel > ? /usr/bin/xkill > ? /usr/bin/xmag > ? /usr/bin/xwd > ? xorg-x11-resutils xorg-x11-resutils-0:7.1-9.fc12 > ? /usr/bin/editres > ? xorg-x11-server xorg-x11-server-Xdmx-0:1.7.1-7.fc12 > ? /usr/bin/Xdmx > ? /usr/bin/dmxwininfo > ? /usr/bin/xdmxconfig > ? xorg-x11-server xorg-x11-server-Xnest-0:1.7.1-7.fc12 > ? /usr/bin/Xnest > ? xorg-x11-server-utils xorg-x11-server-utils-0:7.4-13.fc12 > ? /usr/bin/xsetroot > ? /usr/bin/xset > ? xorg-x11-twm xorg-x11-twm-1:1.0.3-5.fc12 > ? /usr/bin/twm > ? xorg-x11-utils xorg-x11-utils-0:7.4-7.fc12 > ? /usr/bin/xlsfonts > ? /usr/bin/xprop > ? /usr/bin/xwininfo > ? xorg-x11-xdm xorg-x11-xdm-1:1.1.6-14.fc12 > ? /usr/lib64/X11/xdm/libXdmGreet.so > ? xosd xosd-0:2.2.14-13.fc12 > ? /usr/lib64/libxosd.so.2.2.14 > ? xosview xosview-0:1.8.3-17.20080301cvs.fc12 > ? /usr/bin/xosview > ? xpdf xpdf-1:3.02-15.fc12 > ? /usr/bin/xpdf > ? xpilot-ng xpilot-ng-0:4.7.2-16.fc11 > ? /usr/bin/xpilot-ng-replay > ? /usr/bin/xpilot-ng-x11 > ? xpilot-ng xpilot-ng-server-0:4.7.2-16.fc11 > ? /usr/bin/xpilot-ng-xp-mapedit > ? xscreensaver xscreensaver-base-1:5.10-2.fc12 > ? /usr/bin/xscreensaver > ? xscreensaver xscreensaver-extras-1:5.10-2.fc12 > ? /usr/libexec/xscreensaver/abstractile > ? /usr/libexec/xscreensaver/anemone > ? /usr/libexec/xscreensaver/anemotaxis > ? /usr/libexec/xscreensaver/apollonian > ? /usr/libexec/xscreensaver/apple2 > ? /usr/libexec/xscreensaver/attraction > ? /usr/libexec/xscreensaver/barcode > ? /usr/libexec/xscreensaver/blaster > ? /usr/libexec/xscreensaver/blitspin > ? /usr/libexec/xscreensaver/bouboule > ? /usr/libexec/xscreensaver/boxfit > ? /usr/libexec/xscreensaver/braid > ? /usr/libexec/xscreensaver/bsod > ? /usr/libexec/xscreensaver/bumps > ? /usr/libexec/xscreensaver/ccurve > ? /usr/libexec/xscreensaver/celtic > ? /usr/libexec/xscreensaver/cloudlife > ? /usr/libexec/xscreensaver/compass > ? /usr/libexec/xscreensaver/coral > ? /usr/libexec/xscreensaver/crystal > ? /usr/libexec/xscreensaver/cwaves > ? /usr/libexec/xscreensaver/cynosure > ? /usr/libexec/xscreensaver/decayscreen > ? /usr/libexec/xscreensaver/deco > ? /usr/libexec/xscreensaver/deluxe > ? /usr/libexec/xscreensaver/demon > ? /usr/libexec/xscreensaver/discrete > ? /usr/libexec/xscreensaver/distort > ? /usr/libexec/xscreensaver/drift > ? /usr/libexec/xscreensaver/epicycle > ? /usr/libexec/xscreensaver/eruption > ? /usr/libexec/xscreensaver/euler2d > ? /usr/libexec/xscreensaver/fadeplot > ? /usr/libexec/xscreensaver/fiberlamp > ? /usr/libexec/xscreensaver/fireworkx > ? /usr/libexec/xscreensaver/flame > ? /usr/libexec/xscreensaver/flow > ? /usr/libexec/xscreensaver/fluidballs > ? /usr/libexec/xscreensaver/fontglide > ? /usr/libexec/xscreensaver/fuzzyflakes > ? /usr/libexec/xscreensaver/galaxy > ? /usr/libexec/xscreensaver/goop > ? /usr/libexec/xscreensaver/grav > ? /usr/libexec/xscreensaver/greynetic > ? /usr/libexec/xscreensaver/halftone > ? /usr/libexec/xscreensaver/halo > ? /usr/libexec/xscreensaver/helix > ? /usr/libexec/xscreensaver/hopalong > ? /usr/libexec/xscreensaver/ifs > ? /usr/libexec/xscreensaver/imsmap > ? /usr/libexec/xscreensaver/interaggregate > ? /usr/libexec/xscreensaver/interference > ? /usr/libexec/xscreensaver/intermomentary > ? /usr/libexec/xscreensaver/julia > ? /usr/libexec/xscreensaver/kaleidescope > ? /usr/libexec/xscreensaver/kumppa > ? /usr/libexec/xscreensaver/lcdscrub > ? /usr/libexec/xscreensaver/loop > ? /usr/libexec/xscreensaver/m6502 > ? /usr/libexec/xscreensaver/maze > ? /usr/libexec/xscreensaver/memscroller > ? /usr/libexec/xscreensaver/metaballs > ? /usr/libexec/xscreensaver/moire2 > ? /usr/libexec/xscreensaver/moire > ? /usr/libexec/xscreensaver/mountain > ? /usr/libexec/xscreensaver/munch > ? /usr/libexec/xscreensaver/nerverot > ? /usr/libexec/xscreensaver/noseguy > ? /usr/libexec/xscreensaver/pacman > ? /usr/libexec/xscreensaver/pedal > ? /usr/libexec/xscreensaver/penetrate > ? /usr/libexec/xscreensaver/penrose > ? /usr/libexec/xscreensaver/petri > ? /usr/libexec/xscreensaver/phosphor > ? /usr/libexec/xscreensaver/piecewise > ? /usr/libexec/xscreensaver/polyominoes > ? /usr/libexec/xscreensaver/pong > ? /usr/libexec/xscreensaver/popsquares > ? /usr/libexec/xscreensaver/pyro > ? /usr/libexec/xscreensaver/qix > ? /usr/libexec/xscreensaver/rd-bomb > ? /usr/libexec/xscreensaver/ripples > ? /usr/libexec/xscreensaver/rocks > ? /usr/libexec/xscreensaver/rorschach > ? /usr/libexec/xscreensaver/rotzoomer > ? /usr/libexec/xscreensaver/shadebobs > ? /usr/libexec/xscreensaver/sierpinski > ? /usr/libexec/xscreensaver/slidescreen > ? /usr/libexec/xscreensaver/slip > ? /usr/libexec/xscreensaver/speedmine > ? /usr/libexec/xscreensaver/spotlight > ? /usr/libexec/xscreensaver/squiral > ? /usr/libexec/xscreensaver/starfish > ? /usr/libexec/xscreensaver/strange > ? /usr/libexec/xscreensaver/substrate > ? /usr/libexec/xscreensaver/swirl > ? /usr/libexec/xscreensaver/thornbird > ? /usr/libexec/xscreensaver/triangle > ? /usr/libexec/xscreensaver/truchet > ? /usr/libexec/xscreensaver/twang > ? /usr/libexec/xscreensaver/vermiculate > ? /usr/libexec/xscreensaver/wander > ? /usr/libexec/xscreensaver/whirlwindwarp > ? /usr/libexec/xscreensaver/wormhole > ? /usr/libexec/xscreensaver/xanalogtv > ? /usr/libexec/xscreensaver/xflame > ? /usr/libexec/xscreensaver/xjack > ? /usr/libexec/xscreensaver/xlyap > ? /usr/libexec/xscreensaver/xmatrix > ? /usr/libexec/xscreensaver/xrayswarm > ? /usr/libexec/xscreensaver/xspirograph > ? /usr/libexec/xscreensaver/zoom > ? xscreensaver xscreensaver-gl-extras-1:5.10-2.fc12 > ? /usr/libexec/xscreensaver/antinspect > ? /usr/libexec/xscreensaver/antmaze > ? /usr/libexec/xscreensaver/antspotlight > ? /usr/libexec/xscreensaver/atlantis > ? /usr/libexec/xscreensaver/atunnel > ? /usr/libexec/xscreensaver/blinkbox > ? /usr/libexec/xscreensaver/blocktube > ? /usr/libexec/xscreensaver/boing > ? /usr/libexec/xscreensaver/bouncingcow > ? /usr/libexec/xscreensaver/boxed > ? /usr/libexec/xscreensaver/bubble3d > ? /usr/libexec/xscreensaver/cage > ? /usr/libexec/xscreensaver/carousel > ? /usr/libexec/xscreensaver/circuit > ? /usr/libexec/xscreensaver/crackberg > ? /usr/libexec/xscreensaver/cube21 > ? /usr/libexec/xscreensaver/cubenetic > ? /usr/libexec/xscreensaver/cubestorm > ? /usr/libexec/xscreensaver/cubicgrid > ? /usr/libexec/xscreensaver/dangerball > ? /usr/libexec/xscreensaver/endgame > ? /usr/libexec/xscreensaver/engine > ? /usr/libexec/xscreensaver/flipflop > ? /usr/libexec/xscreensaver/flipscreen3d > ? /usr/libexec/xscreensaver/fliptext > ? /usr/libexec/xscreensaver/flurry > ? /usr/libexec/xscreensaver/flyingtoasters > ? /usr/libexec/xscreensaver/gears > ? /usr/libexec/xscreensaver/gflux > ? /usr/libexec/xscreensaver/glblur > ? /usr/libexec/xscreensaver/glcells > ? /usr/libexec/xscreensaver/gleidescope > ? /usr/libexec/xscreensaver/glhanoi > ? /usr/libexec/xscreensaver/glknots > ? /usr/libexec/xscreensaver/glmatrix > ? /usr/libexec/xscreensaver/glplanet > ? /usr/libexec/xscreensaver/glschool > ? /usr/libexec/xscreensaver/glslideshow > ? /usr/libexec/xscreensaver/glsnake > ? /usr/libexec/xscreensaver/gltext > ? /usr/libexec/xscreensaver/hypertorus > ? /usr/libexec/xscreensaver/hypnowheel > ? /usr/libexec/xscreensaver/jigglypuff > ? /usr/libexec/xscreensaver/jigsaw > ? /usr/libexec/xscreensaver/juggler3d > ? /usr/libexec/xscreensaver/klein > ? /usr/libexec/xscreensaver/lament > ? /usr/libexec/xscreensaver/lavalite > ? /usr/libexec/xscreensaver/lockward > ? /usr/libexec/xscreensaver/menger > ? /usr/libexec/xscreensaver/mirrorblob > ? /usr/libexec/xscreensaver/moebiusgears > ? /usr/libexec/xscreensaver/moebius > ? /usr/libexec/xscreensaver/molecule > ? /usr/libexec/xscreensaver/morph3d > ? /usr/libexec/xscreensaver/noof > ? /usr/libexec/xscreensaver/photopile > ? /usr/libexec/xscreensaver/pinion > ? /usr/libexec/xscreensaver/pipes > ? /usr/libexec/xscreensaver/polyhedra > ? /usr/libexec/xscreensaver/polytopes > ? /usr/libexec/xscreensaver/providence > ? /usr/libexec/xscreensaver/pulsar > ? /usr/libexec/xscreensaver/queens > ? /usr/libexec/xscreensaver/rubikblocks > ? /usr/libexec/xscreensaver/rubik > ? /usr/libexec/xscreensaver/sballs > ? /usr/libexec/xscreensaver/sierpinski3d > ? /usr/libexec/xscreensaver/skytentacles > ? /usr/libexec/xscreensaver/sonar > ? /usr/libexec/xscreensaver/spheremonics > ? /usr/libexec/xscreensaver/sproingies > ? /usr/libexec/xscreensaver/stairs > ? /usr/libexec/xscreensaver/starwars > ? /usr/libexec/xscreensaver/stonerview > ? /usr/libexec/xscreensaver/superquadrics > ? /usr/libexec/xscreensaver/surfaces > ? /usr/libexec/xscreensaver/tangram > ? /usr/libexec/xscreensaver/timetunnel > ? /usr/libexec/xscreensaver/topblock > ? /usr/libexec/xscreensaver/voronoi > ? xstar xstar-0:2.2.0-5.fc12 > ? /usr/bin/xstar > ? xteddy xteddy-0:2.0.1-5.fc12 > ? /usr/bin/xteddy > ? xterm xterm-0:248-2.fc12 > ? /usr/bin/xterm > ? xtide xtide-0:2.10-5.fc12 > ? /usr/bin/xtide > ? xulrunner xulrunner-0:1.9.1.4-1.fc12 > ? /usr/lib64/xulrunner-1.9.1/plugins/libnullplugin.so > ? /usr/lib64/xulrunner-1.9.1/plugins/libunixprintplugin.so > ? xwrits xwrits-0:2.24-6.fc12 > ? /usr/bin/xwrits > ? yadex yadex-0:1.7.0-13.fc12 > ? /usr/bin/yadex-1.7.0 > > > ? http://xfree86.org/pipermail/forum/2003-March/000799.html > > From nicolas.mailhot at laposte.net Wed Nov 11 12:50:44 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Nov 2009 13:50:44 +0100 Subject: Identifying remaining core font users In-Reply-To: <4AFAB101.4030309@hhs.nl> References: <1257941463.841.37.camel@arekh.okg> <4AFAB101.4030309@hhs.nl> Message-ID: <1257943844.841.42.camel@arekh.okg> Le mercredi 11 novembre 2009 ? 13:41 +0100, Hans de Goede a ?crit : > It would help tremendously to know how you generated this list of files / > packages which allegedly use Core Fonts, there are quite a few packages of > mine there, but in many cases I have no idea as to why they are here. Sure, sorry about this, I didn't want to make the message longer than it already was. All credit for the receipe goes to ajax, it mostly does : repoquery --whatrequires 'libX11.so* ? download, unpack ? find elf files ? nm -aDu "$file" | grep -q '\ From snecklifter at gmail.com Wed Nov 11 12:53:35 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Wed, 11 Nov 2009 12:53:35 +0000 Subject: rpms/iptstate/F-12 iptstate.spec,1.21,1.22 In-Reply-To: <20091111105226.3e7d1416@faldor.intranet> References: <20091111091758.0631E11C00E8@cvs1.fedora.phx.redhat.com> <20091111105226.3e7d1416@faldor.intranet> Message-ID: <364d303b0911110453u3a67be69s5f4477ae02143b03@mail.gmail.com> 2009/11/11 Michael Schwendt : > On Wed, 11 Nov 2009 09:17:58 +0000 (UTC), Paul wrote: > >> Author: stingray >> >> Update of /cvs/pkgs/rpms/iptstate/F-12 > >> ?%changelog >> +* Tue Nov 10 2009 Paul P. Komkoff Jr - 2.2.2-2 >> +- rebuild for libnetfilter_conntrack-0.0.100 >> + >> +* Tue Nov 10 2009 Thomas Woerner 2.2.2-1 >> +- new version 2.2.2 >> +- removed upstream strerror patch >> +- fixed package description (rhbz#140516) >> + > > Caution! Dude, you should slow down quite a bit and give all this a second > thought. > > You have not yet committed and built the new libnetfilter_conntrack > upgrade for F-12. Rebuilding the other packages for F-12 won't work > correctly because of that. They are built against the old library. > > Take your time. Update your cvs working-directory with "cvs up -d" to get > the F-12 branch, then follow Fedora procedures for this ABI-incompatible > library upgrade (which means to request a koji buildroot override tag from > Fedora Release Engineering so the new libnetfilter_conntrack for F-12 will > be made available in the koji buildroot _prior_ to pushing it into the > stable updates repository. That way you can prepare all rebuilds without > pushing any incompatible upgrades into the stable repo). If you need help, > ask your sponsor, or ask on this list. Oops, too late! [chris at yoda ~]$ sudo yum update Loaded plugins: presto, refresh-packagekit Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package dhclient.x86_64 12:4.1.0p1-4.fc11 set to be updated ---> Package f-spot.x86_64 0:0.6.1.3-1.fc11 set to be updated ---> Package f-spot-screensaver.x86_64 0:0.6.1.3-1.fc11 set to be updated --> Processing Dependency: libnetfilter_conntrack.so.1()(64bit) for package: iptstate-2.2.1-5.fc11.x86_64 ---> Package libnetfilter_conntrack.x86_64 0:0.0.100-1.fc11 set to be updated ---> Package libvorbis.x86_64 1:1.2.0-9.fc11 set to be updated ---> Package libvorbis-devel.x86_64 1:1.2.0-9.fc11 set to be updated --> Finished Dependency Resolution iptstate-2.2.1-5.fc11.x86_64 from installed has depsolving problems --> Missing Dependency: libnetfilter_conntrack.so.1()(64bit) is needed by package iptstate-2.2.1-5.fc11.x86_64 (installed) Error: Missing Dependency: libnetfilter_conntrack.so.1()(64bit) is needed by package iptstate-2.2.1-5.fc11.x86_64 (installed) You could try using --skip-broken to work around the problem You could try running: package-cleanup --problems package-cleanup --dupes rpm -Va --nofiles --nodigest Is there any way to sanity-check pushed updates for depsolving capabilities? -- Christopher Brown From nicolas.mailhot at laposte.net Wed Nov 11 12:54:34 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Nov 2009 13:54:34 +0100 Subject: Identifying remaining core font users In-Reply-To: <1257943844.841.42.camel@arekh.okg> References: <1257941463.841.37.camel@arekh.okg> <4AFAB101.4030309@hhs.nl> <1257943844.841.42.camel@arekh.okg> Message-ID: <1257944074.841.45.camel@arekh.okg> Le mercredi 11 novembre 2009 ? 13:50 +0100, Nicolas Mailhot a ?crit : > Le mercredi 11 novembre 2009 ? 13:41 +0100, Hans de Goede a ?crit : > > > It would help tremendously to know how you generated this list of files / > > packages which allegedly use Core Fonts, there are quite a few packages of > > mine there, but in many cases I have no idea as to why they are here. > > Sure, sorry about this, I didn't want to make the message longer than it > already was. All credit for the receipe goes to ajax, it mostly does : > > repoquery --whatrequires 'libX11.so* > ? > download, unpack > ? > find elf files > ? > nm -aDu "$file" | grep -q '\ > Complete code with history in git repo-font-audit > http://git.fedorahosted.org/git/fontpackages.git?p=fontpackages.git;a=tree;f=bin > (I now it's fugly but it woks) Of course suggestions to improve this are welcome, and I need to ping indirect core font users too ie everyone that uses gtk1, etc Also we have some packages that use font files without passing through the core font system or fontconfig, I need to find a good heuristic to detect those too. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nils at redhat.com Wed Nov 11 13:03:18 2009 From: nils at redhat.com (Nils Philippsen) Date: Wed, 11 Nov 2009 14:03:18 +0100 Subject: intent to retire: kudzu In-Reply-To: <4AF87B54.5020807@fedoraproject.org> References: <20091109202844.GA29552@nostromo.devel.redhat.com> <4AF87B54.5020807@fedoraproject.org> Message-ID: <1257944598.3799.175.camel@gibraltar.str.redhat.com> On Tue, 2009-11-10 at 01:58 +0530, Rahul Sundaram wrote: > On 11/10/2009 01:58 AM, Bill Nottingham wrote: > > I'd like to retire kudzu for F-13. > > > > Why? > > - There are places where it almost certainly does not work with current kernels > > - It's so deprecated that one of its replacements (HAL) has since been > > frozen and deprecated > > - Given that, its upstream is very dead > > > > However, it is still being required by two programs: > > - hwbrowser > > - fwfstab > > > > If someone wants to keep it limping along for thsese two programs I can > > orphan it. But I'd really rather just retire it. > > I filed a bug report against these programs a while back to move away > from Kudzu. Neither of these programs themselves seem to be actively > maintained anymore. The move from kudzu over udev to hal and via DeviceKit back to (lib)udev wasn't something I wanted to follow while it was still moving ;-). In the hope that using libudev is here to stay, I can now reimplement hwbrowser on top of it -- I don't think porting the old code is a good idea, as it wasn't written with hot-pluggable hardware in mind. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty nils at redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From mclasen at redhat.com Wed Nov 11 13:11:10 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 11 Nov 2009 08:11:10 -0500 Subject: intent to retire: kudzu In-Reply-To: <1257944598.3799.175.camel@gibraltar.str.redhat.com> References: <20091109202844.GA29552@nostromo.devel.redhat.com> <4AF87B54.5020807@fedoraproject.org> <1257944598.3799.175.camel@gibraltar.str.redhat.com> Message-ID: <1257945070.1914.3.camel@planemask> On Wed, 2009-11-11 at 14:03 +0100, Nils Philippsen wrote: > On Tue, 2009-11-10 at 01:58 +0530, Rahul Sundaram wrote: > > On 11/10/2009 01:58 AM, Bill Nottingham wrote: > > > I'd like to retire kudzu for F-13. > > > > > > Why? > > > - There are places where it almost certainly does not work with current kernels > > > - It's so deprecated that one of its replacements (HAL) has since been > > > frozen and deprecated > > > - Given that, its upstream is very dead > > > > > > However, it is still being required by two programs: > > > - hwbrowser > > > - fwfstab > > > > > > If someone wants to keep it limping along for thsese two programs I can > > > orphan it. But I'd really rather just retire it. > > > > I filed a bug report against these programs a while back to move away > > from Kudzu. Neither of these programs themselves seem to be actively > > maintained anymore. > > The move from kudzu over udev to hal and via DeviceKit back to (lib)udev > wasn't something I wanted to follow while it was still moving ;-). In > the hope that using libudev is here to stay, I can now reimplement > hwbrowser on top of it -- I don't think porting the old code is a good > idea, as it wasn't written with hot-pluggable hardware in mind. I noticed recently that suse have a patch to add a 'Hardware' tab to gnome-system-monitor. I haven't looked deeper, so I don't know if it is any good. But it might be worth checking out. From rjones at redhat.com Wed Nov 11 13:22:41 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 11 Nov 2009 13:22:41 +0000 Subject: Identifying remaining core font users In-Reply-To: <1257941463.841.37.camel@arekh.okg> References: <1257941463.841.37.camel@arekh.okg> Message-ID: <20091111132241.GC28964@amd.home.annexia.org> On Wed, Nov 11, 2009 at 01:11:03PM +0100, Nicolas Mailhot wrote: > ? ocaml ocaml-0:3.11.1-0.rc1.2.fc12.1 > ? /usr/lib64/ocaml/graphics.cmxs > ? ocaml ocaml-runtime-0:3.11.1-0.rc1.2.fc12.1 > ? /usr/lib64/ocaml/stublibs/dllgraphics.so I guess it falls to me (with Debian folk) to do this one, since upstream are unlikely to care enough to change this old, working code. Here is the code at issue: http://caml.inria.fr/cgi-bin/viewcvs.cgi/ocaml/trunk/otherlibs/graph/text.c?rev=6171&view=markup Some questions since I know very little about this: (1) Are there any recipes / guides / tutorials for changing basic X core fonts calls into whatever has replaced them? Note that using a library like gtk is not an option. (2) Will the replacement work on other Unix platforms (eg Solaris, AIX)? Note that the OCaml Graphics module isn't used by any serious code. Serious users are using ocaml-cairo or LablGTK. On the other hand, we wouldn't want to remove it because it is useful for showing beginners how to "draw a circle using a little bit of OCaml" and having that demo code work on Unix and Windows. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw From rawhide at fedoraproject.org Wed Nov 11 13:47:48 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Wed, 11 Nov 2009 13:47:48 +0000 Subject: rawhide report: 20091111 changes Message-ID: <20091111134748.GA14862@releng2.fedora.phx.redhat.com> Compose started at Wed Nov 11 08:15:08 UTC 2009 Updated Packages: xfce4-settings-4.6.3-2.fc12 --------------------------- * Tue Nov 10 2009 Christoph Wickert - 4.6.3-2 - Patch xfce4-mouse-settings for newer libXi (#525501) Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 1 From nicolas.mailhot at laposte.net Wed Nov 11 13:53:00 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Nov 2009 14:53:00 +0100 Subject: Identifying remaining core font users In-Reply-To: <20091111132241.GC28964@amd.home.annexia.org> References: <1257941463.841.37.camel@arekh.okg> <20091111132241.GC28964@amd.home.annexia.org> Message-ID: <1257947580.841.76.camel@arekh.okg> Le mercredi 11 novembre 2009 ? 13:22 +0000, Richard W.M. Jones a ?crit : > I guess it falls to me (with Debian folk) to do this one, since > upstream are unlikely to care enough to change this old, working code. > > Here is the code at issue: > > http://caml.inria.fr/cgi-bin/viewcvs.cgi/ocaml/trunk/otherlibs/graph/text.c?rev=6171&view=markup > > Some questions since I know very little about this: > > (1) Are there any recipes / guides / tutorials for changing basic X > core fonts calls into whatever has replaced them? Note that using a > library like gtk is not an option. > > (2) Will the replacement work on other Unix platforms (eg Solaris, > AIX)? The right person to ask this would be Behdad, as he's the Fedora/Red Hat/upstream maintainer of most core components of our current text stack. IIRC his advice last time I asked the question was to avoid accessing fontconfig directly, but to pass through gtk2/pango, QT, or pango-cairo in cairo (those are the three main ways to do text nowadays and modern text requirements are complex enough they're all trying to converge behind the scenes instead of using different implementations of text libs. Too difficult to do alone, even for projects their size) Note that pango-cairo in particular will work on recent versions of other Unixes, and even on Windows and OSX. In fact OO.o is currently migrating this way mainly for OSX compat. If depending on this level of libraries is out of the question for you I'd advise ripping the text parts from those modules. Text is much more complex than just drawing a simple form like a triangle, it is getting more complex every year (as new font format specs and encoding standards revisions are released, and support is added to more minority languages with strange requirements). I don't think you'll find maintaining text support sustainable without depending on common text libs. QT/GTK/Mozilla/OO.o tried, and concluded convergence was the only path. But feel free to ask Behdad directly, I'm sure anything he tells you will prove valuable. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jwboyer at gmail.com Wed Nov 11 13:55:40 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 11 Nov 2009 08:55:40 -0500 Subject: rpms/iptstate/F-12 iptstate.spec,1.21,1.22 In-Reply-To: <364d303b0911110453u3a67be69s5f4477ae02143b03@mail.gmail.com> References: <20091111091758.0631E11C00E8@cvs1.fedora.phx.redhat.com> <20091111105226.3e7d1416@faldor.intranet> <364d303b0911110453u3a67be69s5f4477ae02143b03@mail.gmail.com> Message-ID: <20091111135540.GD5699@hansolo.jdub.homelinux.org> On Wed, Nov 11, 2009 at 12:53:35PM +0000, Christopher Brown wrote: >Oops, too late! > >[chris at yoda ~]$ sudo yum update >Loaded plugins: presto, refresh-packagekit >Setting up Update Process >Resolving Dependencies >--> Running transaction check >---> Package dhclient.x86_64 12:4.1.0p1-4.fc11 set to be updated >---> Package f-spot.x86_64 0:0.6.1.3-1.fc11 set to be updated >---> Package f-spot-screensaver.x86_64 0:0.6.1.3-1.fc11 set to be updated >--> Processing Dependency: libnetfilter_conntrack.so.1()(64bit) for >package: iptstate-2.2.1-5.fc11.x86_64 >---> Package libnetfilter_conntrack.x86_64 0:0.0.100-1.fc11 set to be updated >---> Package libvorbis.x86_64 1:1.2.0-9.fc11 set to be updated >---> Package libvorbis-devel.x86_64 1:1.2.0-9.fc11 set to be updated >--> Finished Dependency Resolution >iptstate-2.2.1-5.fc11.x86_64 from installed has depsolving problems > --> Missing Dependency: libnetfilter_conntrack.so.1()(64bit) is >needed by package iptstate-2.2.1-5.fc11.x86_64 (installed) >Error: Missing Dependency: libnetfilter_conntrack.so.1()(64bit) is >needed by package iptstate-2.2.1-5.fc11.x86_64 (installed) > You could try using --skip-broken to work around the problem > You could try running: package-cleanup --problems > package-cleanup --dupes > rpm -Va --nofiles --nodigest > >Is there any way to sanity-check pushed updates for depsolving capabilities? There is, but it hasn't been implemented yet and it would add quite a bit of time to the updates compose process. I plan on working on it RSN. josh From bruno at wolff.to Wed Nov 11 14:22:22 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 11 Nov 2009 08:22:22 -0600 Subject: Fedora 12 has gone gold In-Reply-To: <4AFA709B.5050505@gmail.com> References: <1257816570.2468.32.camel@localhost.localdomain> <4AF99CBC.6060501@redhat.com> <1257873852.2468.58.camel@localhost.localdomain> <4AFA709B.5050505@gmail.com> Message-ID: <20091111142222.GA26825@wolff.to> On Wed, Nov 11, 2009 at 19:06:51 +1100, Bradley Baetz wrote: > > All the people in the bug are complaining about this happening with > /home - does someone with / encrypted want to turn off graphical > boot and see if it affects that too? I boot in text mode all of the time and haven't had a problem entering passwords for my machines with encrypted / since the initial dracut stuff. From rjones at redhat.com Wed Nov 11 14:32:26 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 11 Nov 2009 14:32:26 +0000 Subject: Identifying remaining core font users In-Reply-To: <1257947580.841.76.camel@arekh.okg> References: <1257941463.841.37.camel@arekh.okg> <20091111132241.GC28964@amd.home.annexia.org> <1257947580.841.76.camel@arekh.okg> Message-ID: <20091111143226.GB30567@amd.home.annexia.org> On Wed, Nov 11, 2009 at 02:53:00PM +0100, Nicolas Mailhot wrote: > If depending on this level of libraries is out of the question for you > I'd advise ripping the text parts from those modules. Text is much more > complex than just drawing a simple form like a triangle, it is getting > more complex every year (as new font format specs and encoding standards > revisions are released, and support is added to more minority languages > with strange requirements). I don't think you'll find maintaining text > support sustainable without depending on common text libs. > QT/GTK/Mozilla/OO.o tried, and concluded convergence was the only path. > > But feel free to ask Behdad directly, I'm sure anything he tells you > will prove valuable. I emailed him. It has to be said that maybe text in the OCaml Graphics module only works right now for people using "fixed" in a ISO-8859-1 locale or whatever [in reality, it works for a whole lot more than that], but ripping out text support means it won't work for anyone at all. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 bruno at wolff.to Wed Nov 11 15:01:43 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 11 Nov 2009 09:01:43 -0600 Subject: Identifying remaining core font users In-Reply-To: <1257941463.841.37.camel@arekh.okg> References: <1257941463.841.37.camel@arekh.okg> Message-ID: <20091111150143.GA10659@wolff.to> On Wed, Nov 11, 2009 at 13:11:03 +0100, Nicolas Mailhot wrote: > > Therefore, I'd like to identify remaining core font users, and remind > them periodically their core font use is not good for their users or for > Fedora. Is there any documentation on how to avoid this? I am the current maintainer of glest and am not sure what I even need to be looking for, let alone how to fix it. From halfline at gmail.com Wed Nov 11 15:15:47 2009 From: halfline at gmail.com (Ray Strode) Date: Wed, 11 Nov 2009 10:15:47 -0500 Subject: Fedora 12 has gone gold In-Reply-To: <4AFA709B.5050505@gmail.com> References: <1257816570.2468.32.camel@localhost.localdomain> <4AF99CBC.6060501@redhat.com> <1257873852.2468.58.camel@localhost.localdomain> <4AFA709B.5050505@gmail.com> Message-ID: <45abe7d80911110715jc96b9f4nfd88caa0f5e625dc@mail.gmail.com> On Wed, Nov 11, 2009 at 3:06 AM, Bradley Baetz wrote: > [sorry for the duplicate posting if you get one] > > On 11/11/09 04:24, Jesse Keating wrote: > >> Our impressions are indeed different. ?The go / no go meeting was the >> point of no return. ?Once we go, there is no going back. ?We've made a >> commitment to go with what we have, and let the various teams that need >> time to prepare for the release to start their work, as much of that >> work cannot be pulled back once done. >> > > Does that mean that its too late to get a bug marked as a blocker? Unfortunately, yes. > I've just upgraded from F11 using preupgrade and run into > https://bugzilla.redhat.com/show_bug.cgi?id=530896 which appears to have the > impact that anyone not using the graphical boot option can't enter a > password for an encrypted partition (eg /home), and then gets stuck in an > endless loop being prompted for the password with no way out. I don't think it affects all non-graphical boot users, but I don't know how far reaching it is (because we haven't identified what program is causing the problem yet). I added some notes to the CommonBugs page here: https://fedoraproject.org/wiki/Common_F12_bugs#Encrypted_disks_can.27t_be_unencrypted_for_non-graphical_boot That combined with the 0-day update that users should pick up at initial install time automatically sort of defangs this issue. Still unfortunate that no one ran into this issue a week earlier though. --Ray From ikem.krueger at googlemail.com Wed Nov 11 15:30:34 2009 From: ikem.krueger at googlemail.com (Ikem Krueger) Date: Wed, 11 Nov 2009 15:30:34 +0000 Subject: 2009-11-09 Fedora 12 "Go/No Go" Meeting Minutes In-Reply-To: <4AF9A2B4.1050908@redhat.com> References: <4AF9A2B4.1050908@redhat.com> Message-ID: > Meeting summary Folks, this question maybe sound stupid but, how do I participate on a meeting? From rjones at redhat.com Wed Nov 11 15:33:39 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 11 Nov 2009 15:33:39 +0000 Subject: Identifying remaining core font users In-Reply-To: <20091111150143.GA10659@wolff.to> References: <1257941463.841.37.camel@arekh.okg> <20091111150143.GA10659@wolff.to> Message-ID: <20091111153339.GA31088@amd.home.annexia.org> On Wed, Nov 11, 2009 at 09:01:43AM -0600, Bruno Wolff III wrote: > On Wed, Nov 11, 2009 at 13:11:03 +0100, > Nicolas Mailhot wrote: > > > > Therefore, I'd like to identify remaining core font users, and remind > > them periodically their core font use is not good for their users or for > > Fedora. > > Is there any documentation on how to avoid this? I am the current maintainer > of glest and am not sure what I even need to be looking for, let alone > how to fix it. Calls to functions named X[A-Z]*Font* indicate use of core fonts, eg: XLoadQueryFont XQueryFont XLoadFont XListFonts XGetFontPath XSetFont XFreeFont etc. (for more see ) See the other emails we exchanged for discussion of what the replacement ought to be if you're using Xlib directly. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw From sundaram at fedoraproject.org Wed Nov 11 15:30:44 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 11 Nov 2009 21:00:44 +0530 Subject: 2009-11-09 Fedora 12 "Go/No Go" Meeting Minutes In-Reply-To: References: <4AF9A2B4.1050908@redhat.com> Message-ID: <4AFAD8A4.4040204@fedoraproject.org> On 11/11/2009 09:00 PM, Ikem Krueger wrote: >> Meeting summary > > Folks, this question maybe sound stupid but, how do I participate on a meeting? Meetings are usually held in #fedora-meeting IRC channel in freenode.net. If you are not familiar IRC, refer to http://fedoraproject.org/wiki/How_to_use_IRC Recurrent meetings are listed in http://fedoraproject.org/wiki/Meeting_channel Rahul From Jochen at herr-schmitt.de Wed Nov 11 15:36:06 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 11 Nov 2009 16:36:06 +0100 Subject: 2009-11-09 Fedora 12 "Go/No Go" Meeting Minutes In-Reply-To: References: <4AF9A2B4.1050908@redhat.com> Message-ID: <4AFAD9E6.7010902@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 11.11.2009 16:30, schrieb Ikem Krueger: > > Folks, this question maybe sound stupid but, how do I participate on a meeting? > As first you need a IRC client as IRSSI or konversation. With this client you have to make a connection the a irc.freenode.org server. After you are connected you can joe the channel on which the meeting is happen. Of course you should consider the announcement of the meeting to find out on which channel and when the meeting will happens. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iJwEAQECAAYFAkr62dUACgkQZLAIBz9lVu/WlwQA5QwZUebsEMQ/PcnddZAX8fm+ gpXkyhFcglWcWx1zemSp5H8BISqIEha5VYrIJbBWVIH0sfrpPldL5VKd4Q4zNXo9 TXu5No3k86F6FmzeAPemsJzkmdUy3PVPNizf2iTv8sgWp+6JhO51DAxmahD/3VaG jpWWgEshOKrVVtnRjZA= =4ICK -----END PGP SIGNATURE----- From nicolas.mailhot at laposte.net Wed Nov 11 15:41:32 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Nov 2009 16:41:32 +0100 Subject: Identifying remaining core font users In-Reply-To: <20091111143226.GB30567@amd.home.annexia.org> References: <1257941463.841.37.camel@arekh.okg> <20091111132241.GC28964@amd.home.annexia.org> <1257947580.841.76.camel@arekh.okg> <20091111143226.GB30567@amd.home.annexia.org> Message-ID: <1257954092.6777.20.camel@arekh.okg> Le mercredi 11 novembre 2009 ? 14:32 +0000, Richard W.M. Jones a ?crit : > I emailed him. > > It has to be said that maybe text in the OCaml Graphics module only > works right now for people using "fixed" in a ISO-8859-1 locale or > whatever [in reality, it works for a whole lot more than that], but > ripping out text support means it won't work for anyone at all. It seems the people maintaining text libs are not interested in backends that fail if you use codepoints outside a specific encoding, or when you use the "wrong" font (because encoding is just one part that changed, OpenType "smart" features such as ligatures and swashes mean that even if you restrict yourself to basic latin nowadays a modern font won't behave like a "simple" ASCII font used to ten years ago). Probably because they know that if they limited themselves users would ask for the missing bits anyway. Projects that find modern text libs over-complex should try to maintain their own "simple" alternative (or pick up the maintenance of the X11 Core fonts system). I suspect they'd quickly find themselves in agreement with current text lib maintainers. So really, it's just a matter of delegation: if you don't want to maintain your own text stack, follow the advice of the people maintaining the one you use, and the advice of X11 Core fonts maintainers (back when there were still some, in 2003) was clear: drop it and use fontconfig instead. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From bruno at wolff.to Wed Nov 11 15:42:23 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 11 Nov 2009 09:42:23 -0600 Subject: Fedora 12 has gone gold In-Reply-To: <45abe7d80911110715jc96b9f4nfd88caa0f5e625dc@mail.gmail.com> References: <1257816570.2468.32.camel@localhost.localdomain> <4AF99CBC.6060501@redhat.com> <1257873852.2468.58.camel@localhost.localdomain> <4AFA709B.5050505@gmail.com> <45abe7d80911110715jc96b9f4nfd88caa0f5e625dc@mail.gmail.com> Message-ID: <20091111154223.GA30556@wolff.to> On Wed, Nov 11, 2009 at 10:15:47 -0500, Ray Strode wrote: > > Still unfortunate that no one ran into this issue a week earlier though. Well, I was testing it and not seeing it, so it wasn't hitting everyone not using graphical boots. I had 4 machines doing this until I lost a power supply in one, midway through last week, but still had been doing reboots on them almost everytime a new kernel hit koji (and on one multiple reboots because I needed to rebuild a kernel module with the new kernel running). I didn't see that issue once. From ikem.krueger at googlemail.com Wed Nov 11 15:53:12 2009 From: ikem.krueger at googlemail.com (Ikem Krueger) Date: Wed, 11 Nov 2009 15:53:12 +0000 Subject: 2009-11-09 Fedora 12 "Go/No Go" Meeting Minutes In-Reply-To: <4AFAD9E6.7010902@herr-schmitt.de> References: <4AF9A2B4.1050908@redhat.com> <4AFAD9E6.7010902@herr-schmitt.de> Message-ID: Thank you both. :> From choeger at cs.tu-berlin.de Wed Nov 11 16:06:17 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Wed, 11 Nov 2009 17:06:17 +0100 Subject: Fedora 12 has gone gold In-Reply-To: <1257816570.2468.32.camel@localhost.localdomain> References: <1257816570.2468.32.camel@localhost.localdomain> Message-ID: <1257955577.2514.15.camel@choeger5.umpa.netz> Am Montag, den 09.11.2009, 17:29 -0800 schrieb Jesse Keating: > We have just completed our Go / No Go meeting for Fedora 12 and have > reached the decision to Go. Fedora 12's package set is golden and we're > ready to stage things for shipping. Great work all around, I'm very > proud of this release. I'm sure there will be more back patting and > hand shaking to come, but Will Woods would like to remind everybody that > it's just 11 weeks until Fedora 13 Alpha freeze! Does that mean, preupgrade to rawhide will bring in the f12 packages? If so, there is a major issue with anaconda that crashes upon detecting the harddrives. This is a little bit troubling since I have nothing exotic here, just two sata hds. I saved the debug report, but without storage I probably saved it to a ram disk. If anyone can help me figuring out how to get a stacktrace to a running machine (except for pen&paper), I would be able to bring up some valuable information about that crash. regards christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From mschwendt at gmail.com Wed Nov 11 16:17:41 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 11 Nov 2009 17:17:41 +0100 Subject: rpms/iptstate/F-12 iptstate.spec,1.21,1.22 In-Reply-To: <364d303b0911110453u3a67be69s5f4477ae02143b03@mail.gmail.com> References: <20091111091758.0631E11C00E8@cvs1.fedora.phx.redhat.com> <20091111105226.3e7d1416@faldor.intranet> <364d303b0911110453u3a67be69s5f4477ae02143b03@mail.gmail.com> Message-ID: <20091111171741.3d619934@faldor.intranet> On Wed, 11 Nov 2009 12:53:35 +0000, Christopher wrote: > Oops, too late! > > [chris at yoda ~]$ sudo yum update > Loaded plugins: presto, refresh-packagekit > Setting up Update Process > Resolving Dependencies > --> Running transaction check > ---> Package dhclient.x86_64 12:4.1.0p1-4.fc11 set to be updated > ---> Package f-spot.x86_64 0:0.6.1.3-1.fc11 set to be updated > ---> Package f-spot-screensaver.x86_64 0:0.6.1.3-1.fc11 set to be updated > --> Processing Dependency: libnetfilter_conntrack.so.1()(64bit) for > package: iptstate-2.2.1-5.fc11.x86_64 > ---> Package libnetfilter_conntrack.x86_64 0:0.0.100-1.fc11 set to be updated > ---> Package libvorbis.x86_64 1:1.2.0-9.fc11 set to be updated > ---> Package libvorbis-devel.x86_64 1:1.2.0-9.fc11 set to be updated > --> Finished Dependency Resolution > iptstate-2.2.1-5.fc11.x86_64 from installed has depsolving problems > --> Missing Dependency: libnetfilter_conntrack.so.1()(64bit) is > needed by package iptstate-2.2.1-5.fc11.x86_64 (installed) > Error: Missing Dependency: libnetfilter_conntrack.so.1()(64bit) is > needed by package iptstate-2.2.1-5.fc11.x86_64 (installed) > You could try using --skip-broken to work around the problem > You could try running: package-cleanup --problems > package-cleanup --dupes > rpm -Va --nofiles --nodigest Well, hey, that's the broken dep he's trying to fix with rebuilds of the three affected packages on F-11 and F-10. ;-) My reply to questionable activity in F-12 cvs is related, but not "too late", because libnetfilter_conntrack in F-12 has not been upgraded [yet]. So, it's multiple issues currently. It's still possible to avoid the same broken dep in F-12. From rjones at redhat.com Wed Nov 11 16:38:01 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 11 Nov 2009 16:38:01 +0000 Subject: Identifying remaining core font users In-Reply-To: <1257954092.6777.20.camel@arekh.okg> References: <1257941463.841.37.camel@arekh.okg> <20091111132241.GC28964@amd.home.annexia.org> <1257947580.841.76.camel@arekh.okg> <20091111143226.GB30567@amd.home.annexia.org> <1257954092.6777.20.camel@arekh.okg> Message-ID: <20091111163801.GA31248@amd.home.annexia.org> On Wed, Nov 11, 2009 at 04:41:32PM +0100, Nicolas Mailhot wrote: > It seems the people maintaining text libs are not interested in backends > that fail if you use codepoints outside a specific encoding, or when you > use the "wrong" font (because encoding is just one part that changed, > OpenType "smart" features such as ligatures and swashes mean that even > if you restrict yourself to basic latin nowadays a modern font won't > behave like a "simple" ASCII font used to ten years ago). Probably > because they know that if they limited themselves users would ask for > the missing bits anyway. > > Projects that find modern text libs over-complex should try to maintain > their own "simple" alternative (or pick up the maintenance of the X11 > Core fonts system). I suspect they'd quickly find themselves in > agreement with current text lib maintainers. > > So really, it's just a matter of delegation: if you don't want to > maintain your own text stack, follow the advice of the people > maintaining the one you use, and the advice of X11 Core fonts > maintainers (back when there were still some, in 2003) was clear: drop > it and use fontconfig instead. Yes ... but ... we're talking mainly about demos and examples written for beginners. ------------------------------------------------------- hello.ml -- #!/usr/bin/ocamlrun ocaml #load "graphics.cma";; open Graphics let () = open_graph " 200x150"; set_font "-*-times-*-r-*-*-*-240-*-*-*-*-*-*"; auto_synchronize false; while true do let x, y = ref 50, ref 80 in List.iter ( fun c -> moveto !x !y; let rand () = Random.int 256 in set_color (rgb (rand ()) (rand ()) (rand ())); draw_char c; x := !x + 24; if c = ' ' then (y := !y - 24; x := 50) ) [ 'H'; 'E'; 'L'; 'L'; 'O'; ' '; 'W'; 'O'; 'R'; 'L'; 'D'; '!' ]; synchronize () done ------------------------------------------------------------------- Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw From kevin at scrye.com Tue Nov 10 20:42:04 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Tue, 10 Nov 2009 13:42:04 -0700 Subject: Fedora 12 test machine for package maintainers Message-ID: <20091110134204.529898da@ohm.scrye.com> Greetings. I have updated my test machine resources for Fedora package maintainers with a new Fedora 12 instance: abraxas.scrye.com or f12-test.scrye.com. As always you can see the full list and get more info at: https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers Please feel free to use the new instance to test bugs, build packages or otherwise anything Fedora related that will assist you. Enjoy. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From David.Avery at united.com Wed Nov 11 17:00:45 2009 From: David.Avery at united.com (Avery, David [DENTK]) Date: Wed, 11 Nov 2009 10:00:45 -0700 Subject: Identifying remaining core font users In-Reply-To: <20091111163801.GA31248@amd.home.annexia.org> References: <1257941463.841.37.camel@arekh.okg><20091111132241.GC28964@amd.home.annexia.org><1257947580.841.76.camel@arekh.okg><20091111143226.GB30567@amd.home.annexia.org><1257954092.6777.20.camel@arekh.okg> <20091111163801.GA31248@amd.home.annexia.org> Message-ID: I have a bigger problem with this, I use fedora boxes to talk to older devices (solaris 2.6 and M88KV4 unix machines) that can never be upgraded to newer X clients. Since the fedora ( or any xorg) servers are talking to "classic" X11 clients dropping support for core fonts is a huge issue. The clients are running on the host computers for flight simulators. The clients are built on 3rd party libraries that date from the early 90s. As the existing Xterms (Tek/NCD ) fail we are replacing them with newer linux based thin clients, but we still need "classic" X11 font support. The programming support is done on solaris and linux boxes the need to display the same layouts as the xterms dave -----Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Richard W.M. Jones Sent: Wednesday, November 11, 2009 9:38 AM To: Development discussions related to Fedora Subject: Re: Identifying remaining core font users On Wed, Nov 11, 2009 at 04:41:32PM +0100, Nicolas Mailhot wrote: > It seems the people maintaining text libs are not interested in backends > that fail if you use codepoints outside a specific encoding, or when you > use the "wrong" font (because encoding is just one part that changed, > OpenType "smart" features such as ligatures and swashes mean that even > if you restrict yourself to basic latin nowadays a modern font won't > behave like a "simple" ASCII font used to ten years ago). Probably > because they know that if they limited themselves users would ask for > the missing bits anyway. > > Projects that find modern text libs over-complex should try to maintain > their own "simple" alternative (or pick up the maintenance of the X11 > Core fonts system). I suspect they'd quickly find themselves in > agreement with current text lib maintainers. > > So really, it's just a matter of delegation: if you don't want to > maintain your own text stack, follow the advice of the people > maintaining the one you use, and the advice of X11 Core fonts > maintainers (back when there were still some, in 2003) was clear: drop > it and use fontconfig instead. Yes ... but ... we're talking mainly about demos and examples written for beginners. ------------------------------------------------------- hello.ml -- #!/usr/bin/ocamlrun ocaml #load "graphics.cma";; open Graphics let () = open_graph " 200x150"; set_font "-*-times-*-r-*-*-*-240-*-*-*-*-*-*"; auto_synchronize false; while true do let x, y = ref 50, ref 80 in List.iter ( fun c -> moveto !x !y; let rand () = Random.int 256 in set_color (rgb (rand ()) (rand ()) (rand ())); draw_char c; x := !x + 24; if c = ' ' then (y := !y - 24; x := 50) ) [ 'H'; 'E'; 'L'; 'L'; 'O'; ' '; 'W'; 'O'; 'R'; 'L'; 'D'; '!' ]; synchronize () done ------------------------------------------------------------------- Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list From a.badger at gmail.com Wed Nov 11 17:12:24 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 11 Nov 2009 09:12:24 -0800 Subject: rpm %verify In-Reply-To: <200911051043.58347.sgrubb@redhat.com> References: <200911050910.12583.sgrubb@redhat.com> <20091105152729.GI12372@nostromo.devel.redhat.com> <200911051043.58347.sgrubb@redhat.com> Message-ID: <20091111171224.GF25960@clingman.lan> On Thu, Nov 05, 2009 at 10:43:58AM -0500, Steve Grubb wrote: > On Thursday 05 November 2009 10:27:30 am Bill Nottingham wrote: > > Steve Grubb (sgrubb at redhat.com) said: > > > I have 2 bugzillas asking for %verify to be added to %config files. I am > > > wondering if this is a good idea at all. The issue is that if you wanted > > > to verify whether or not config files have changed, then this causes you > > > to lose that ability. Adding --noscript to the verify command does not > > > make rpm suddenly report the issues it was hiding. Does this mean that > > > rpm is not working right? Or does this mean that we cannot use rpm for > > > integrity checking for any package that has %verify attributes for config > > > files? > > > > %verify is for turning off specific verification checks for files we > > *know* are going to change from what's in the RPM package/db. /etc/passwd > > is an obvious example; users will be added there, and the fact that the > > passwd file does not match the packaged version is not a verification > > issue. > > And there is no way to ask rpm to tell us what is different even if we wanted > that? > Correct -- rpm records checksums of files, not the file's contents. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From orion at cora.nwra.com Wed Nov 11 17:17:48 2009 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 11 Nov 2009 10:17:48 -0700 Subject: netcdf update and soname bump Message-ID: <4AFAF1BC.5070104@cora.nwra.com> I'm about to build a netcdf 4.1.0 beta snapshot for F-13. This is a soname bump (libnetcdf.so.4 -> libnetcdf.so.6). It also enables the netcdf4, dap, and ncgen4 features of netcdf. The following packages will need to get rebuilt: cdo-0:1.0.8-6.fc12.i686 dap-netcdf_handler-0:3.8.3-2.fc12.i686 gdal-0:1.6.1-2.fc12.i686 gdl-0:0.9-0.7.rc3.fc12.i686 GMT-0:4.5.1-1.fc12.i686 grace-0:5.1.22-5.fc12.i686 grads-0:1.9b4-28.fc12.i686 kst-netcdf-0:1.8.0-3.fc12.i686 nco-0:3.9.8-2.fc12.i686 ncview-0:1.93c-6.fc12.i686 netcdf-decoders-0:5.0.0-5.fc12.i686 netcdf-perl-0:1.2.4-2.fc12.i686 ScientificPython-0:2.8-6.fc11.i586 scrip-0:1.4-14.fc12.i686 wgrib2-0:1.8.1-1.fc12.i686 xgridedit-0:4.5.1-1.fc12.i686 I'm the owner for several of these and can rebuild others if needed as well. -- 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 bnocera at redhat.com Wed Nov 11 17:28:54 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Wed, 11 Nov 2009 17:28:54 +0000 Subject: Heads up: gstreamer/gstreamer-plugins-base updates in F12 Message-ID: <1257960534.24730.325.camel@localhost.localdomain> Heya, I've packaged snapshots of gstreamer and gstreamer-plugins-base to fix a number of bugs. So if you saw: - Hangs on startup when using file opened has a corresponding text subtitle in Totem - Requiring a restart of Totem or Rhythmbox after installing missing plugins Packages (will be shortly in updates-testing): http://koji.fedoraproject.org/koji/buildinfo?buildID=140790 http://koji.fedoraproject.org/koji/buildinfo?buildID=140831 If you see regressions, or that those bugs above aren't fixed for you, please file bugs in the Red Hat bugzilla Cheers From gene at czarc.net Wed Nov 11 17:33:32 2009 From: gene at czarc.net (Gene Czarcinski) Date: Wed, 11 Nov 2009 12:33:32 -0500 Subject: cpio to ext4 seems much slower than to ext2, ext3 or xfs In-Reply-To: <4AFAA306.9090003@lfarkas.org> References: <20091111101421.GA28964@amd.home.annexia.org> <20091111105322.GB28964@amd.home.annexia.org> <4AFAA306.9090003@lfarkas.org> Message-ID: <200911111233.32771.gene@czarc.net> On Wednesday 11 November 2009 06:41:58 Farkas Levente wrote: > On 11/11/2009 11:53 AM, Richard W.M. Jones wrote: > > On Wed, Nov 11, 2009 at 10:14:21AM +0000, Richard W.M. Jones wrote: > >> echo input | time cpio --quiet -o -H newc > /path/to/fs/output > > > > Update: I found the -C option that lets me specify the blocksize, and > > raising it to something sensible (65536) shows major improvements in > > performance for all filesystems. > > > > echo input | time cpio -C 65536 --quiet -o -H newc > /path/to/fs/output > > > >> tmpfs 0.77 s x 1.0 > >> ext2 1.12 s x 1.5 > >> xfs 1.66 s x 2.1 > >> ext3 2.58 s x 3.4 > >> ext4 5.59 s x 7.3 <---- > > > > The new times are: > > > > tmpfs 0.20 s x 1.0 > > ext2 0.30 s x 1.5 > > xfs 0.41 s x 2.1 > > ext3 0.57 s x 2.9 > > ext4 0.44 s x 2.2 > > imho it's still a bug. wouldn't somehow rise the default or make the > writes buffered or ... since the current situation is not correct. > I am not sure if this is related or not ... During the F12 development cycle, I have done a number of installs on both bare hardware and qemu-kvm guests. In all cases, I have formatted the root ("/") partition as ext4. I have noticed that formatting the partition for ext4 seems to take considerably more wall-clock time for ext4 partitions than my previous experience with ext3 partitions. I do not know if this is because ext4 "formatting" needs to do a lot more work than ext3 or if there is a performance issue. Gene From sandeen at redhat.com Wed Nov 11 17:43:27 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 11 Nov 2009 11:43:27 -0600 Subject: cpio to ext4 seems much slower than to ext2, ext3 or xfs In-Reply-To: <200911111233.32771.gene@czarc.net> References: <20091111101421.GA28964@amd.home.annexia.org> <20091111105322.GB28964@amd.home.annexia.org> <4AFAA306.9090003@lfarkas.org> <200911111233.32771.gene@czarc.net> Message-ID: <4AFAF7BF.4040405@redhat.com> Gene Czarcinski wrote: ... > I am not sure if this is related or not ... > > During the F12 development cycle, I have done a number of installs on both > bare hardware and qemu-kvm guests. > > In all cases, I have formatted the root ("/") partition as ext4. I have > noticed that formatting the partition for ext4 seems to take considerably more > wall-clock time for ext4 partitions than my previous experience with ext3 > partitions. > > I do not know if this is because ext4 "formatting" needs to do a lot more work > than ext3 or if there is a performance issue. > > Gene > There shouldn't be a big difference, but if you want to do some tests, find a difference, and report back with some times, I'd be interested. -Eric From jlaska at redhat.com Wed Nov 11 17:52:11 2009 From: jlaska at redhat.com (James Laska) Date: Wed, 11 Nov 2009 12:52:11 -0500 Subject: Fedora 12 has gone gold In-Reply-To: <1257955577.2514.15.camel@choeger5.umpa.netz> References: <1257816570.2468.32.camel@localhost.localdomain> <1257955577.2514.15.camel@choeger5.umpa.netz> Message-ID: <1257961931.2357.42.camel@localhost.localdomain> On Wed, 2009-11-11 at 17:06 +0100, Christoph H?ger wrote: > Am Montag, den 09.11.2009, 17:29 -0800 schrieb Jesse Keating: > > We have just completed our Go / No Go meeting for Fedora 12 and have > > reached the decision to Go. Fedora 12's package set is golden and we're > > ready to stage things for shipping. Great work all around, I'm very > > proud of this release. I'm sure there will be more back patting and > > hand shaking to come, but Will Woods would like to remind everybody that > > it's just 11 weeks until Fedora 13 Alpha freeze! > > Does that mean, preupgrade to rawhide will bring in the f12 packages? If > so, there is a major issue with anaconda that crashes upon detecting the > harddrives. This is a little bit troubling since I have nothing exotic > here, just two sata hds. > > I saved the debug report, but without storage I probably saved it to a > ram disk. > If anyone can help me figuring out how to get a stacktrace to a running > machine (except for pen&paper), I would be able to bring up some > valuable information about that crash. The installer team has a fairly comprehensive wiki page on triaging installation-related failures (https://fedoraproject.org/wiki/How_to_debug_installation_problems). Are you able to save the traceback directly to bugzilla, instead of to your local disk? Thanks, James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jan.kratochvil at redhat.com Wed Nov 11 18:06:29 2009 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Wed, 11 Nov 2009 19:06:29 +0100 Subject: Are conflicts in debuginfo packages OK? In-Reply-To: <200911102215.47261.bjorn@xn--rombobjrn-67a.se> Message-ID: <20091111180629.GA6143@host0.dyn.jankratochvil.net> On Wed, 11 Nov 2009 04:14:49 +0100, Frank Ch. Eigler wrote: > (It could be handled by suffixing the arch in the source-tree-name part.) ... > Considering that the same files are also linked into multilib-safe > collision-free /usr/lib/debug/.build-id files, where debuggers already > know to look for them, the .../usr/bin* ones could be deprecated. /usr/lib/debug/path/name.debug were kept only as backward compatibility symlinks possibly wrong for multi-arch/multi-version installed packages. Implemented as a postinstall script but it would be more right to resolve it by rpm coloring as is being done for the real /bin/* multilib files. > I hope it is obvious that it would be appropriate to be able to debug > anything installed from the normal repositories. That the status quo > is not quite up to the job (in the case of some multilib libraries) is > a bug. I sometimes hit it having to uninstall a x86_64 debuginfo and temporarily replace it by its i686 variant. On Tue, 10 Nov 2009 22:15:47 +0100, Bj?rn Persson wrote: > Generated files can be placed in separate subdirectories, for example > /usr/src/debug//%{_arch}. My patch uses there: /usr/src/debug/name-version-release.arch It was here, unaware how it is still applicable now: http://people.redhat.com/jkratoch/multidebug/ But Roland McGrath had some more general debuginfos plans but I think that temporary hack of mine could be worth the two years of Fedoras. Roland, does it make sense to revive + improve this patch? Thanks, Jan From fche at redhat.com Wed Nov 11 18:42:07 2009 From: fche at redhat.com (Frank Ch. Eigler) Date: Wed, 11 Nov 2009 13:42:07 -0500 Subject: cpio to ext4 seems much slower than to ext2, ext3 or xfs In-Reply-To: <200911111233.32771.gene@czarc.net> (Gene Czarcinski's message of "Wed, 11 Nov 2009 12:33:32 -0500") References: <20091111101421.GA28964@amd.home.annexia.org> <20091111105322.GB28964@amd.home.annexia.org> <4AFAA306.9090003@lfarkas.org> <200911111233.32771.gene@czarc.net> Message-ID: Gene Czarcinski writes: > [...] In all cases, I have formatted the root ("/") partition as > ext4. I have noticed that formatting the partition for ext4 seems > to take considerably more wall-clock time for ext4 partitions than > my previous experience with ext3 partitions. [...] I have seen the same thing; this sort of thing appeared to help: mkfs.ext4 -O uninit_bg -E lazy_itable_init=1 - FChE From bjorn at xn--rombobjrn-67a.se Wed Nov 11 18:54:55 2009 From: bjorn at xn--rombobjrn-67a.se (=?utf-8?q?Bj=C3=B6rn_Persson?=) Date: Wed, 11 Nov 2009 19:54:55 +0100 Subject: Are conflicts in debuginfo packages OK? In-Reply-To: <20091111180629.GA6143@host0.dyn.jankratochvil.net> References: <20091111180629.GA6143@host0.dyn.jankratochvil.net> Message-ID: <200911111955.07195.bjorn@xn--rombobjrn-67a.se> Jan Kratochvil wrote: > On Tue, 10 Nov 2009 22:15:47 +0100, Bj?rn Persson wrote: > > Generated files can be placed in separate subdirectories, for example > > /usr/src/debug//%{_arch}. > > My patch uses there: > /usr/src/debug/name-version-release.arch Duplicating the entire source tree seems a bit wasteful when it's only generated files that sometimes need to be separated, but I suppose that's the only way if you want to do it without patching makefiles in numerous packages. Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From nicolas.mailhot at laposte.net Wed Nov 11 19:03:19 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Nov 2009 20:03:19 +0100 Subject: Identifying remaining core font users In-Reply-To: References: <1257941463.841.37.camel@arekh.okg> <20091111132241.GC28964@amd.home.annexia.org> <1257947580.841.76.camel@arekh.okg> <20091111143226.GB30567@amd.home.annexia.org> <1257954092.6777.20.camel@arekh.okg> <20091111163801.GA31248@amd.home.annexia.org> Message-ID: <1257966199.4121.36.camel@arekh.okg> Le mercredi 11 novembre 2009 ? 10:00 -0700, Avery, David [DENTK] a ?crit : > I have a bigger problem with this, I use fedora boxes to talk to older > devices (solaris 2.6 and M88KV4 unix machines) that can never be > upgraded to newer X clients. Since the fedora ( or any xorg) servers are > talking to "classic" X11 clients dropping support for core fonts is a > huge issue. Let me write again what I put in my original message. There is no talk of deliberately dropping support for core fonts infrastructure. Core fonts are slowly heading the way of the dodo through natural obsolescence and lack of people interested in investing in their future. Big text users jumped ship for fontconfig a long time ago (circa 2003) and they're not coming back to resume core fonts maintenance. However, core fonts will be with us, in a somewhat reduced and degraded state, for a long time. So this is not about removing Fedora core fonts infrastructure (individual fonts have and will continue to be dropped every time they fail a legal or technical check and there's no one willing to fix the problem). This is about notifying the maintainers of core font *clients* in Fedora they have a problem and should start planning migration to fontconfig if they're not already doing so (on the plus side anyone migrating today will have access to a font library and text features core fonts can not compare with). Every modern *nix system has some form of fontconfig support (because every single modern GUI app requires it). You can run fontconfig on non-*nixes. There is no good reason for a client app not to migrate to fontconfig if it wants a future. > The clients are running on the host computers for flight simulators. The > clients are built on 3rd party libraries that date from the early 90s. > As the existing Xterms (Tek/NCD ) fail we are replacing them with newer > linux based thin clients, but we still need "classic" X11 font support. > The programming support is done on solaris and linux boxes the need to > display the same layouts as the xterms I'm sure you don't need me to tell you that forcing the limitations of old clients in new clients is eating your cake now, and that you're preparing yourself a painful big bang migration when the situation gets to the point core font support is no longer at the acceptable level for you. More than six years have elapsed since core fonts stopped being the preferred font system X-side. Use the remaining years wisely before your back is to the wall (I know that's easy for me to say, but there is no magic solution). Having worked with some decades-old systems myself, I know it's really easy to get yourself trapped in a situation where you pay an harm and a leg for multiple levels of legacy emulation that barely work and have pitiful capabilities compared to recent systems, just because someone went for the short-term "let's emulate and pretend nothing changed" route back when keeping up with the technological changes would have been just slightly harder (but future-proof). -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From sandeen at redhat.com Wed Nov 11 19:24:20 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 11 Nov 2009 13:24:20 -0600 Subject: cpio to ext4 seems much slower than to ext2, ext3 or xfs In-Reply-To: References: <20091111101421.GA28964@amd.home.annexia.org> <20091111105322.GB28964@amd.home.annexia.org> <4AFAA306.9090003@lfarkas.org> <200911111233.32771.gene@czarc.net> Message-ID: <4AFB0F64.1010505@redhat.com> Frank Ch. Eigler wrote: > Gene Czarcinski writes: > >> [...] In all cases, I have formatted the root ("/") partition as >> ext4. I have noticed that formatting the partition for ext4 seems >> to take considerably more wall-clock time for ext4 partitions than >> my previous experience with ext3 partitions. [...] > > I have seen the same thing; this sort of thing appeared to help: > > mkfs.ext4 -O uninit_bg -E lazy_itable_init=1 > > - FChE > lazy_itable_init isn't yet safe, unfortunately, we still need a kernel background zeroing to make it so ... Anybody got actual numbers? I don't disagree that mkfs.ext4 is slow in the default config, but I don't think it should be slower than mkfs.ext3 for the same sized disks. You sure your disks didn't just get bigger since the F9 days? :) -Eric From Jochen at herr-schmitt.de Wed Nov 11 19:32:12 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 11 Nov 2009 20:32:12 +0100 Subject: Fedora 12 test machine for package maintainers In-Reply-To: <20091110134204.529898da@ohm.scrye.com> References: <20091110134204.529898da@ohm.scrye.com> Message-ID: <4AFB113C.4070207@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 10.11.2009 21:42, schrieb Kevin Fenzi: > Greetings. > > I have updated my test machine resources for Fedora package maintainers > with a new Fedora 12 instance: abraxas.scrye.com or f12-test.scrye.com. > > As always you can see the full list and get more info at: > > https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers > > Please feel free to use the new instance to test bugs, build packages > or otherwise anything Fedora related that will assist you. At first thank you for your offering of the test machines. Unfortunately, I'm searching a ppc64 system where I can make a su for testing an odd issue with gnu-smalltalk. Unfortunately, this issue only happes on ppc64 systems. On ppc32 it's works fine. this is the reason why I'm search such system. The bombadil.infradead.org system is unusable for me, because I can't do a su or sudo on this system. It may be nice, if we can have a ppc64 test machine in the future. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iJwEAQECAAYFAkr7ETMACgkQZLAIBz9lVu/33QP/UTgQ3qfIabE+V/4cgQlDHPmP eZtZ2Ji7tKqE9iF7MZo7TJPljlL5rDm14YMr0Z+pxLALncE4wbUU8ybntqpJv30b Mfr4dGC7+51UKOdRaKp7G48PEMHJQ3u36wym408vAzJu4OmLYa/QtgibbnABEtfI c4o9jiPWjoTF7DJTgu0= =IwiI -----END PGP SIGNATURE----- From awilliam at redhat.com Wed Nov 11 19:38:33 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 11 Nov 2009 11:38:33 -0800 Subject: rpms/iptstate/F-12 iptstate.spec,1.21,1.22 In-Reply-To: <364d303b0911110453u3a67be69s5f4477ae02143b03@mail.gmail.com> References: <20091111091758.0631E11C00E8@cvs1.fedora.phx.redhat.com> <20091111105226.3e7d1416@faldor.intranet> <364d303b0911110453u3a67be69s5f4477ae02143b03@mail.gmail.com> Message-ID: <1257968313.9898.6.camel@adam.local.net> On Wed, 2009-11-11 at 12:53 +0000, Christopher Brown wrote: > Is there any way to sanity-check pushed updates for depsolving capabilities? It's called AutoQA, and it's coming. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From choeger at cs.tu-berlin.de Wed Nov 11 19:38:30 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Wed, 11 Nov 2009 20:38:30 +0100 Subject: Fedora 12 has gone gold In-Reply-To: <1257961931.2357.42.camel@localhost.localdomain> References: <1257816570.2468.32.camel@localhost.localdomain> <1257955577.2514.15.camel@choeger5.umpa.netz> <1257961931.2357.42.camel@localhost.localdomain> Message-ID: <1257968310.3362.0.camel@choeger5.umpa.netz> Am Mittwoch, den 11.11.2009, 12:52 -0500 schrieb James Laska: > On Wed, 2009-11-11 at 17:06 +0100, Christoph H?ger wrote: > > Am Montag, den 09.11.2009, 17:29 -0800 schrieb Jesse Keating: > > > We have just completed our Go / No Go meeting for Fedora 12 and have > > > reached the decision to Go. Fedora 12's package set is golden and we're > > > ready to stage things for shipping. Great work all around, I'm very > > > proud of this release. I'm sure there will be more back patting and > > > hand shaking to come, but Will Woods would like to remind everybody that > > > it's just 11 weeks until Fedora 13 Alpha freeze! > > > > Does that mean, preupgrade to rawhide will bring in the f12 packages? If > > so, there is a major issue with anaconda that crashes upon detecting the > > harddrives. This is a little bit troubling since I have nothing exotic > > here, just two sata hds. > > > > I saved the debug report, but without storage I probably saved it to a > > ram disk. > > If anyone can help me figuring out how to get a stacktrace to a running > > machine (except for pen&paper), I would be able to bring up some > > valuable information about that crash. > > The installer team has a fairly comprehensive wiki page on triaging > installation-related failures > (https://fedoraproject.org/wiki/How_to_debug_installation_problems). > > Are you able to save the traceback directly to bugzilla, instead of to > your local disk? Nope, but the tty2 hint was what I needed. https://bugzilla.redhat.com/show_bug.cgi?id=536906 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From awilliam at redhat.com Wed Nov 11 19:40:26 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 11 Nov 2009 11:40:26 -0800 Subject: Identifying remaining core font users In-Reply-To: <20091111150143.GA10659@wolff.to> References: <1257941463.841.37.camel@arekh.okg> <20091111150143.GA10659@wolff.to> Message-ID: <1257968426.9898.7.camel@adam.local.net> On Wed, 2009-11-11 at 09:01 -0600, Bruno Wolff III wrote: > On Wed, Nov 11, 2009 at 13:11:03 +0100, > Nicolas Mailhot wrote: > > > > Therefore, I'd like to identify remaining core font users, and remind > > them periodically their core font use is not good for their users or for > > Fedora. > > Is there any documentation on how to avoid this? I am the current maintainer > of glest and am not sure what I even need to be looking for, let alone > how to fix it. As you're a true maintainer and not a hybrid maintainer/upstream developer like a lot of Fedora packagers, you should be annoying the hell out of your upstream to move to a non-antiquated font system :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From sundaram at fedoraproject.org Wed Nov 11 20:16:44 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 12 Nov 2009 01:46:44 +0530 Subject: Broken dependencies with Fedora 11 updates-testing - 2009-11-11 In-Reply-To: <20091111193516.7509.90815@faldor.intranet> References: <20091111193516.7509.90815@faldor.intranet> Message-ID: <4AFB1BAC.2060203@fedoraproject.org> On 11/12/2009 01:05 AM, Michael Schwendt wrote: > The following packages in the repository suffer from broken dependencies: > > ====================================================================== > The results in this summary consider Test Updates! > ====================================================================== > > package: tremulous-1.1.0-8.fc11.i586 from fedora-11-i386 > unresolved deps: > libopenal.so.0 --- Seriously, can the openal maintainer please stop breaking the ABI in updates? This isn't the first time. Is there a real necessity to do so? Rahul From mmcgrath at redhat.com Wed Nov 11 20:26:03 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 11 Nov 2009 14:26:03 -0600 (CST) Subject: Outage Notification - 2009-11-11 21:00 UTC Message-ID: There will be an outage starting at 2009-11-11 21:00 UTC, which will last approximately 1 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2009-11-11 21:00 UTC' Affected Services: DNS Torrent Websites Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/1785 Reason for Outage: The new memory is on site, we're going to replace it. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From rjones at redhat.com Wed Nov 11 21:05:20 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 11 Nov 2009 21:05:20 +0000 Subject: cpio to ext4 seems much slower than to ext2, ext3 or xfs In-Reply-To: <4AFB0F64.1010505@redhat.com> References: <20091111101421.GA28964@amd.home.annexia.org> <20091111105322.GB28964@amd.home.annexia.org> <4AFAA306.9090003@lfarkas.org> <200911111233.32771.gene@czarc.net> <4AFB0F64.1010505@redhat.com> Message-ID: <20091111210520.GA622@amd.home.annexia.org> On Wed, Nov 11, 2009 at 01:24:20PM -0600, Eric Sandeen wrote: > Anybody got actual numbers? I don't disagree that mkfs.ext4 is slow in > the default config, but I don't think it should be slower than mkfs.ext3 > for the same sized disks. Easy with guestfish: $ guestfish --version guestfish 1.0.78 $ for fs in ext2 ext3 ext4 xfs jfs ; do guestfish sparse /tmp/test.img 10G : run : echo $fs : sfdiskM /dev/sda , : time mkfs $fs /dev/sda1 ; done ext2 elapsed time: 5.21 seconds ext3 elapsed time: 7.87 seconds ext4 elapsed time: 6.10 seconds xfs elapsed time: 0.45 seconds jfs elapsed time: 0.78 seconds Note that because this is using a sparsely allocated disk each write to the virtual disk is very slow. Change 'sparse' to 'alloc' to test this with a non-sparse file-backed disk. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 linuxdonald at linuxdonald.de Wed Nov 11 20:52:50 2009 From: linuxdonald at linuxdonald.de (LinuxDonald) Date: Wed, 11 Nov 2009 21:52:50 +0100 Subject: Broken dependencies with Fedora 11 updates-testing - 2009-11-11 In-Reply-To: <4AFB1BAC.2060203@fedoraproject.org> References: <20091111193516.7509.90815@faldor.intranet> <4AFB1BAC.2060203@fedoraproject.org> Message-ID: <4AFB2422.5060208@linuxdonald.de> Am 11.11.2009 21:16, schrieb Rahul Sundaram: > On 11/12/2009 01:05 AM, Michael Schwendt wrote: > >> The following packages in the repository suffer from broken dependencies: >> >> ====================================================================== >> The results in this summary consider Test Updates! >> ====================================================================== >> >> package: tremulous-1.1.0-8.fc11.i586 from fedora-11-i386 >> unresolved deps: >> libopenal.so.0 >> > --- > > Seriously, can the openal maintainer please stop breaking the ABI in > updates? This isn't the first time. Is there a real necessity to do so? > > Rahul > > I have forgoten that for F-11 some changes are needed in the spec file. I have fixed it and the new package is on the way. Sorry for the problems. From rjones at redhat.com Wed Nov 11 21:12:09 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 11 Nov 2009 21:12:09 +0000 Subject: cpio to ext4 seems much slower than to ext2, ext3 or xfs In-Reply-To: <20091111210520.GA622@amd.home.annexia.org> References: <20091111101421.GA28964@amd.home.annexia.org> <20091111105322.GB28964@amd.home.annexia.org> <4AFAA306.9090003@lfarkas.org> <200911111233.32771.gene@czarc.net> <4AFB0F64.1010505@redhat.com> <20091111210520.GA622@amd.home.annexia.org> Message-ID: <20091111211209.GB622@amd.home.annexia.org> On Wed, Nov 11, 2009 at 09:05:20PM +0000, Richard W.M. Jones wrote: > ext2 > elapsed time: 5.21 seconds > ext3 > elapsed time: 7.87 seconds > ext4 > elapsed time: 6.10 seconds > xfs > elapsed time: 0.45 seconds > jfs > elapsed time: 0.78 seconds Sod it, let's do all the others too ... $ for fs in reiserfs nilfs2 ntfs msdos btrfs hfs hfsplus gfs gfs2 ; do guestfish sparse /tmp/test.img 10G : run : echo $fs : sfdiskM /dev/sda , : time mkfs $fs /dev/sda1 ; done reiserfs elapsed time: 1.15 seconds nilfs2 elapsed time: 0.12 seconds ntfs elapsed time: 3.09 seconds msdos elapsed time: 0.38 seconds btrfs elapsed time: 0.07 seconds hfs elapsed time: 0.42 seconds hfsplus elapsed time: 0.49 seconds gfs elapsed time: 5.37 seconds gfs2 elapsed time: 4.93 seconds (By the way I really don't think that mkfs time matters that much :-) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From mschwendt at gmail.com Wed Nov 11 21:21:22 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 11 Nov 2009 22:21:22 +0100 Subject: Broken dependencies with Fedora 11 updates-testing - 2009-11-11 In-Reply-To: <4AFB2422.5060208@linuxdonald.de> References: <20091111193516.7509.90815@faldor.intranet> <4AFB1BAC.2060203@fedoraproject.org> <4AFB2422.5060208@linuxdonald.de> Message-ID: <20091111222122.207ae9a7@faldor.intranet> On Wed, 11 Nov 2009 21:52:50 +0100, LinuxDonald wrote: > Am 11.11.2009 21:16, schrieb Rahul Sundaram: > > On 11/12/2009 01:05 AM, Michael Schwendt wrote: > > > >> The following packages in the repository suffer from broken dependencies: > >> > >> ====================================================================== > >> The results in this summary consider Test Updates! > >> ====================================================================== > >> > >> package: tremulous-1.1.0-8.fc11.i586 from fedora-11-i386 > >> unresolved deps: > >> libopenal.so.0 > >> > > --- > > > > Seriously, can the openal maintainer please stop breaking the ABI in > > updates? This isn't the first time. Is there a real necessity to do so? > > > > Rahul > > > > > I have forgoten that for F-11 some changes are needed in the spec file. > I have fixed it and the new package is on the way. > Sorry for the problems. Did you notice that the package still upgrades the library SONAME from libopenal.so.0 to libopenal.so.1? From fedora at leemhuis.info Wed Nov 11 21:30:24 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 11 Nov 2009 22:30:24 +0100 Subject: What questions would you like to ask the Candidates for the Fedora Board, FESCo, and FAMSCO? Message-ID: <4AFB2CF0.10303@leemhuis.info> Hi! As you may have heard already, several seats of the Fedora Board, FESCo, and FAMSCO are up for election soon(?). Right now we are in the nomination period, which will be followed by a "Candidate Questionnaire." That means we'll give candidates a list of questions to answer by private mail within one week after the nomination period closed; the results will be publish soon after that to make sure they are available to the public before the Town Hall meetings on IRC happen. Candidates may choose to answer (or not) those questions as they see fit. Voters can use the answers to get an impression of what the candidate think or plan to do while serving for the committees they are nominated for. That should help to get a interesting discussion running during the IRC Town Hall meetings; furthermore, those people that can't or don't want to participate in the IRC meetings can use the answers to make a more informed vote. Hence we need to prepare a few good questions that we can send to the candidates once the nomination period ends. And that's where I need *your help* now: If you have one or more questions you'd like to send to the candidates simply go and add them to: https://fedoraproject.org/wiki/Elections/F13_Questionnaire It just takes a minute or two, so best to do it right now -- otherwise you might get distracted and forget about it. ;-) I'll take care of the remaining work to review, sort, and clean up the questions(?); after that I'll send them to the candidates soon after the nomination period ended. Hence, I need your question suggestions by around the 15th November 17:00 UTC latest to get a chance to prepare everything in time. So please go to the wiki now and add at least one hard question! The answers will help Fedora contributors to chose whom to vote for! Thanks in advance for your help . CU knurd (?) If you haven't read about it yet see https://fedoraproject.org/wiki/Elections for details. (?) If you want to get involved or review the questions before I send them please drop me a line and I'll try to get that arranged; maybe we can arrange a quick, informal IRC meeting on Sunday evening if there is interest From ian at ianweller.org Wed Nov 11 21:36:38 2009 From: ian at ianweller.org (Ian Weller) Date: Wed, 11 Nov 2009 15:36:38 -0600 Subject: Broken dependencies with Fedora 11 updates-testing - 2009-11-11 In-Reply-To: <4AFB1BAC.2060203@fedoraproject.org> References: <20091111193516.7509.90815@faldor.intranet> <4AFB1BAC.2060203@fedoraproject.org> Message-ID: <20091111213638.GB7231@hovercraft.mobile.ianweller.org> On Thu, Nov 12, 2009 at 01:46:44AM +0530, Rahul Sundaram wrote: > On 11/12/2009 01:05 AM, Michael Schwendt wrote: > > The following packages in the repository suffer from broken dependencies: > > > > ====================================================================== > > The results in this summary consider Test Updates! > > ====================================================================== > > > > package: tremulous-1.1.0-8.fc11.i586 from fedora-11-i386 > > unresolved deps: > > libopenal.so.0 > > --- > > Seriously, can the openal maintainer please stop breaking the ABI in > updates? This isn't the first time. Is there a real necessity to do so? > Can someone give me a definitive answer on whether or not I need to rebuild tremulous and tremfusion with the new ABI? I'm willing to, I just need the confusion to go away. -- Ian Weller "Why, a four-year-old could understand this report. Find me a four-year-old child. I can't make head or tail out of it." -- Groucho Marx, "Duck Soup" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mschwendt at gmail.com Wed Nov 11 21:39:21 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 11 Nov 2009 22:39:21 +0100 Subject: Broken dependencies with Fedora 11 updates-testing - 2009-11-11 In-Reply-To: <20091111213638.GB7231@hovercraft.mobile.ianweller.org> References: <20091111193516.7509.90815@faldor.intranet> <4AFB1BAC.2060203@fedoraproject.org> <20091111213638.GB7231@hovercraft.mobile.ianweller.org> Message-ID: <20091111223921.535c2b71@faldor.intranet> On Wed, 11 Nov 2009 15:36:38 -0600, Ian wrote: > Can someone give me a definitive answer on whether or not I need to > rebuild tremulous and tremfusion with the new ABI? I'm willing to, I > just need the confusion to go away. No need to. This was just the separate openal-soft package that is supposed to be parallel-installable with the older openal instead of obsoleting it. I've mentioned in the bodhi ticket that the packager could evaluate %{fedora} in the spec file to avoid the error that has happened. From kevin at scrye.com Wed Nov 11 21:51:53 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 11 Nov 2009 14:51:53 -0700 Subject: Fedora 12 test machine for package maintainers In-Reply-To: <4AFB113C.4070207@herr-schmitt.de> References: <20091110134204.529898da@ohm.scrye.com> <4AFB113C.4070207@herr-schmitt.de> Message-ID: <20091111145153.6285134e@ohm.scrye.com> On Wed, 11 Nov 2009 20:32:12 +0100 Jochen Schmitt wrote: > At first thank you for your offering of the test machines. > > Unfortunately, I'm searching a ppc64 system where I can make a su > for testing an odd issue with gnu-smalltalk. > > Unfortunately, this issue only happes on ppc64 systems. On ppc32 > it's works fine. this is the reason why I'm search such system. > > The bombadil.infradead.org system is unusable for me, because I > can't do a su or sudo on this system. > > It may be nice, if we can have a ppc64 test machine in the future. Yeah, if someone would like to send me one, I would be happy to set it up and maintain it. ;) Otherwise, perhaps someone else will see your plea here and help you out. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From linuxdonald at linuxdonald.de Wed Nov 11 21:54:35 2009 From: linuxdonald at linuxdonald.de (LinuxDonald) Date: Wed, 11 Nov 2009 22:54:35 +0100 Subject: Broken dependencies with Fedora 11 updates-testing - 2009-11-11 In-Reply-To: <20091111223921.535c2b71@faldor.intranet> References: <20091111193516.7509.90815@faldor.intranet> <4AFB1BAC.2060203@fedoraproject.org> <20091111213638.GB7231@hovercraft.mobile.ianweller.org> <20091111223921.535c2b71@faldor.intranet> Message-ID: <4AFB329B.8080809@linuxdonald.de> Am 11.11.2009 22:39, schrieb Michael Schwendt: > On Wed, 11 Nov 2009 15:36:38 -0600, Ian wrote: > > >> Can someone give me a definitive answer on whether or not I need to >> rebuild tremulous and tremfusion with the new ABI? I'm willing to, I >> just need the confusion to go away. >> > No need to. > > This was just the separate openal-soft package that is supposed to be > parallel-installable with the older openal instead of obsoleting it. > I've mentioned in the bodhi ticket that the packager could evaluate > %{fedora} in the spec file to avoid the error that has happened. > > It was my wrong on the Spec file for fedora 11. I have created an new packaged that don't make any problems and it's installable with openal. Sorry for that :( @Tremulos you not need rebuild it for fedora 11 you have rebuild that game allready for f12 and that is okay :) From bruno at wolff.to Wed Nov 11 22:37:54 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 11 Nov 2009 16:37:54 -0600 Subject: Identifying remaining core font users In-Reply-To: <1257968426.9898.7.camel@adam.local.net> References: <1257941463.841.37.camel@arekh.okg> <20091111150143.GA10659@wolff.to> <1257968426.9898.7.camel@adam.local.net> Message-ID: <20091111223754.GA28128@wolff.to> On Wed, Nov 11, 2009 at 11:40:26 -0800, Adam Williamson wrote: > On Wed, 2009-11-11 at 09:01 -0600, Bruno Wolff III wrote: > > On Wed, Nov 11, 2009 at 13:11:03 +0100, > > Nicolas Mailhot wrote: > > > > > > Therefore, I'd like to identify remaining core font users, and remind > > > them periodically their core font use is not good for their users or for > > > Fedora. > > > > Is there any documentation on how to avoid this? I am the current maintainer > > of glest and am not sure what I even need to be looking for, let alone > > how to fix it. > > As you're a true maintainer and not a hybrid maintainer/upstream > developer like a lot of Fedora packagers, you should be annoying the > hell out of your upstream to move to a non-antiquated font system :) I'll try to understand the problem well enough to make a coherent request and then communicate it upstream. Based on my understanding of what's going on in the project right now, there isn't likely to be big changes in what we are using in Fedora soon. There is a pilot subproject that seems to be getting the most attention right now and eventually it will merge back. In the meantime things are moving slow for the base project. From orion at cora.nwra.com Wed Nov 11 23:38:12 2009 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 11 Nov 2009 16:38:12 -0700 Subject: netcdf update and soname bump In-Reply-To: <4AFAF1BC.5070104@cora.nwra.com> References: <4AFAF1BC.5070104@cora.nwra.com> Message-ID: <4AFB4AE4.3030500@cora.nwra.com> On 11/11/2009 10:17 AM, Orion Poplawski wrote: > I'm about to build a netcdf 4.1.0 beta snapshot for F-13. This is a > soname bump (libnetcdf.so.4 -> libnetcdf.so.6). It also enables the > netcdf4, dap, and ncgen4 features of netcdf. There are some linking issues to work out upstream, and some packages don't expect to have to link to additional libraries in addition to -lnetcdf. If you have trouble, you can work around for now with adding the following to your configure line: LIBS="$(pkg-config netcdf --libs)" -- 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 bojan at rexursive.com Thu Nov 12 00:48:53 2009 From: bojan at rexursive.com (Bojan Smojver) Date: Thu, 12 Nov 2009 11:48:53 +1100 Subject: FF 3.5.5 for F-12 Message-ID: <1257986933.2590.10.camel@shrek.rexursive.com> What happened to that? It's been built in Koji but it's not Rawhide or updates... -- Bojan From gilboad at gmail.com Thu Nov 12 04:51:20 2009 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 12 Nov 2009 06:51:20 +0200 Subject: Identifying remaining core font users In-Reply-To: <1257941463.841.37.camel@arekh.okg> References: <1257941463.841.37.camel@arekh.okg> Message-ID: <1258001480.6989.23.camel@gilboa-home-dev.localdomain> On Wed, 2009-11-11 at 13:11 +0100, Nicolas Mailhot wrote: > Hi, > > It has been plain since 2003? our new font access standard would be > fontconfig. Since then most users of the old core fonts X11 backend have > migrated, but there are still a few stragglers. > > Unfortunately these stragglers matter. Core fonts were not good in 2003, > and they didn't get any better since. Few users means life-support > maintenance only, no one to replace/fix core fonts when a technical or > legal problem causes them to be dropped, no one to update them when > encoding standards change. Also, few users means we do not install core > font packages by default anymore, so packagers that depend on them but > forgot to mark the deps in their packages will deliver broken packages > to users. > > Every remaining core font user is therefore likely to hit more and more > problems as time passes. Each of those problems produces as a side > effect "Fedora fonts suck" messages on the Internet, messages that > detract on all the terrific work Fedora people do on our main font > backend (and associated fonts). End-users are not educated enough to > recognize the root of their problems is the use of a deprecated > almost-no-maintained tech (and they should not have to bother about it). > > Therefore, I'd like to identify remaining core font users, and remind > them periodically their core font use is not good for their users or for > Fedora. > > Since there is not question of deliberately removing core fonts > infrastructure from Fedora, I need to whitelist first the few files used > to maintain this infrastructure (xfontsel and xlsfonts are such files; > twm and gtk1 ? not). I'd therefore be grateful if people checked the > following list and pointed to me files that need to be removed for this > reason. > > Please answer this message with statements such as "file foo can be > removed from the list because it is used this way to manage the core > fonts backend or to propagate the core font protocol to X11 clients". > > Again, widget libraries or utilities that made use of the core fonts > backend when it was the font access standard, do not count. Also modern > libraries that have some form of vestigial core fonts code hidden deep > inside them should probably just excise it (this use it probably worse > than apps that only use core fonts , since those apps at least test > regularly if their core fonts use is not totally broken). > ? icewm icewm-0:1.2.37-5.fc12 > ? /usr/bin/icehelp > ? /usr/bin/icesh > ? /usr/bin/icewm-session > ? /usr/bin/icewmbg > ? /usr/bin/icewmtray > ? /usr/bin/icewm > ? idesk idesk-0:0.7.5-9.fc12 > ? /usr/bin/idesk I own both icewm and idesk. As far as I know, both icewm and idesk are linked against xft and should not default to core fonts. (Unless I completely misunderstanding something...) - Gilboa From gilboad at gmail.com Thu Nov 12 04:56:54 2009 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 12 Nov 2009 06:56:54 +0200 Subject: Identifying remaining core font users In-Reply-To: <1258001480.6989.23.camel@gilboa-home-dev.localdomain> References: <1257941463.841.37.camel@arekh.okg> <1258001480.6989.23.camel@gilboa-home-dev.localdomain> Message-ID: <1258001814.6989.24.camel@gilboa-home-dev.localdomain> On Thu, 2009-11-12 at 06:51 +0200, Gilboa Davara wrote: > I own both icewm and idesk. > As far as I know, both icewm and idesk are linked against xft and should > not default to core fonts. (Unless I completely misunderstanding > something...) > > - Gilboa OK. Did some reading. I more-or-less understand the scope of the problem. Not sure there's something I can do about it. (In both cases upstream either moved to different path or dropped support completely), but I'll see what I can do about it. - Gilboa From dchen at redhat.com Thu Nov 12 05:06:24 2009 From: dchen at redhat.com (Ding Yi Chen) Date: Thu, 12 Nov 2009 00:06:24 -0500 (EST) Subject: Package name conflict: eina, the media player or optimized data types and useful tools for e-17. In-Reply-To: <515459312.1704171258002185412.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1661529914.1704221258002384584.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi, I've tried to build e-17 by hand. When I try to build from eina from e-17, however, I found that the package name, eina, is already been taken by eina, the media player. How should I do with them? Regards, -- Ding-Yi Chen From nicolas.mailhot at laposte.net Thu Nov 12 06:42:22 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 12 Nov 2009 07:42:22 +0100 Subject: Identifying remaining core font users In-Reply-To: <1258001480.6989.23.camel@gilboa-home-dev.localdomain> References: <1257941463.841.37.camel@arekh.okg> <1258001480.6989.23.camel@gilboa-home-dev.localdomain> Message-ID: <1258008142.8351.0.camel@arekh.okg> Le jeudi 12 novembre 2009 ? 06:51 +0200, Gilboa Davara a ?crit : > I own both icewm and idesk. > As far as I know, both icewm and idesk are linked against xft and should > not default to core fonts. (Unless I completely misunderstanding > something...) I've been asked to filter out xft matches next run, so if they *only* do xft they won't appear again. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From berrange at redhat.com Thu Nov 12 09:54:12 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 12 Nov 2009 09:54:12 +0000 Subject: cpio to ext4 seems much slower than to ext2, ext3 or xfs In-Reply-To: <20091111210520.GA622@amd.home.annexia.org> References: <20091111101421.GA28964@amd.home.annexia.org> <20091111105322.GB28964@amd.home.annexia.org> <4AFAA306.9090003@lfarkas.org> <200911111233.32771.gene@czarc.net> <4AFB0F64.1010505@redhat.com> <20091111210520.GA622@amd.home.annexia.org> Message-ID: <20091112095412.GA2060@redhat.com> On Wed, Nov 11, 2009 at 09:05:20PM +0000, Richard W.M. Jones wrote: > On Wed, Nov 11, 2009 at 01:24:20PM -0600, Eric Sandeen wrote: > > Anybody got actual numbers? I don't disagree that mkfs.ext4 is slow in > > the default config, but I don't think it should be slower than mkfs.ext3 > > for the same sized disks. > > Easy with guestfish: > > $ guestfish --version > guestfish 1.0.78 > $ for fs in ext2 ext3 ext4 xfs jfs ; do guestfish sparse /tmp/test.img 10G : run : echo $fs : sfdiskM /dev/sda , : time mkfs $fs /dev/sda1 ; done > ext2 > elapsed time: 5.21 seconds > ext3 > elapsed time: 7.87 seconds > ext4 > elapsed time: 6.10 seconds > xfs > elapsed time: 0.45 seconds > jfs > elapsed time: 0.78 seconds > > Note that because this is using a sparsely allocated disk each write > to the virtual disk is very slow. Change 'sparse' to 'alloc' to test > this with a non-sparse file-backed disk. You really want to avoid using sparse files at all when doing any kind of benchmark / performance tests in VMs. The combo of a sparse file store on a journalling filesystem in the host, w/ virt can cause very pathelogically bad I/O performance until the file has all its extents fully allocated on the host FS. So the use of a sparse file may well be exagarating the real difference in elapsed time between these different mkfs calls in the guest. 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 rjones at redhat.com Thu Nov 12 10:18:15 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 12 Nov 2009 10:18:15 +0000 Subject: cpio to ext4 seems much slower than to ext2, ext3 or xfs In-Reply-To: <20091112095412.GA2060@redhat.com> References: <20091111101421.GA28964@amd.home.annexia.org> <20091111105322.GB28964@amd.home.annexia.org> <4AFAA306.9090003@lfarkas.org> <200911111233.32771.gene@czarc.net> <4AFB0F64.1010505@redhat.com> <20091111210520.GA622@amd.home.annexia.org> <20091112095412.GA2060@redhat.com> Message-ID: <20091112101815.GA4039@amd.home.annexia.org> On Thu, Nov 12, 2009 at 09:54:12AM +0000, Daniel P. Berrange wrote: > On Wed, Nov 11, 2009 at 09:05:20PM +0000, Richard W.M. Jones wrote: > > On Wed, Nov 11, 2009 at 01:24:20PM -0600, Eric Sandeen wrote: > > > Anybody got actual numbers? I don't disagree that mkfs.ext4 is slow in > > > the default config, but I don't think it should be slower than mkfs.ext3 > > > for the same sized disks. > > > > Easy with guestfish: > > > > $ guestfish --version > > guestfish 1.0.78 > > $ for fs in ext2 ext3 ext4 xfs jfs ; do guestfish sparse /tmp/test.img 10G : run : echo $fs : sfdiskM /dev/sda , : time mkfs $fs /dev/sda1 ; done > > ext2 > > elapsed time: 5.21 seconds > > ext3 > > elapsed time: 7.87 seconds > > ext4 > > elapsed time: 6.10 seconds > > xfs > > elapsed time: 0.45 seconds > > jfs > > elapsed time: 0.78 seconds > > > > Note that because this is using a sparsely allocated disk each write > > to the virtual disk is very slow. Change 'sparse' to 'alloc' to test > > this with a non-sparse file-backed disk. > > You really want to avoid using sparse files at all when doing any kind of > benchmark / performance tests in VMs. The combo of a sparse file store on > a journalling filesystem in the host, w/ virt can cause very pathelogically > bad I/O performance until the file has all its extents fully allocated on > the host FS. So the use of a sparse file may well be exagarating the real > difference in elapsed time between these different mkfs calls in the > guest. Again, this time backed by a 10 GB logical volume in the host, so this should remove pretty much all host effects: $ for fs in ext2 ext3 ext4 xfs jfs reiserfs nilfs2 ntfs msdos btrfs hfs hfsplus gfs gfs2 ; do guestfish add /dev/mapper/vg_trick-Temp : run : zero /dev/sda : echo $fs : sfdiskM /dev/sda , : time mkfs $fs /dev/sda1 ; doneext2 elapsed time: 3.48 seconds ext3 elapsed time: 5.45 seconds ext4 elapsed time: 5.19 seconds xfs elapsed time: 0.35 seconds jfs elapsed time: 0.66 seconds reiserfs elapsed time: 0.73 seconds nilfs2 elapsed time: 0.19 seconds ntfs elapsed time: 2.33 seconds msdos elapsed time: 0.29 seconds btrfs elapsed time: 0.16 seconds hfs elapsed time: 0.44 seconds hfsplus elapsed time: 0.46 seconds gfs elapsed time: 1.60 seconds gfs2 elapsed time: 3.98 seconds I'd like to repeat my proviso: I think this test is meaningless for most users. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 Thu Nov 12 10:21:12 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 12 Nov 2009 10:21:12 +0000 Subject: cpio to ext4 seems much slower than to ext2, ext3 or xfs In-Reply-To: <20091112101815.GA4039@amd.home.annexia.org> References: <20091111101421.GA28964@amd.home.annexia.org> <20091111105322.GB28964@amd.home.annexia.org> <4AFAA306.9090003@lfarkas.org> <200911111233.32771.gene@czarc.net> <4AFB0F64.1010505@redhat.com> <20091111210520.GA622@amd.home.annexia.org> <20091112095412.GA2060@redhat.com> <20091112101815.GA4039@amd.home.annexia.org> Message-ID: <20091112102112.GB4039@amd.home.annexia.org> On Thu, Nov 12, 2009 at 10:18:15AM +0000, Richard W.M. Jones wrote: > [...] done <--- line break here > ext2 > elapsed time: 3.48 seconds Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html From gilboad at gmail.com Thu Nov 12 11:08:56 2009 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 12 Nov 2009 13:08:56 +0200 Subject: Identifying remaining core font users In-Reply-To: <1258008142.8351.0.camel@arekh.okg> References: <1257941463.841.37.camel@arekh.okg> <1258001480.6989.23.camel@gilboa-home-dev.localdomain> <1258008142.8351.0.camel@arekh.okg> Message-ID: <1258024136.6989.30.camel@gilboa-home-dev.localdomain> On Thu, 2009-11-12 at 07:42 +0100, Nicolas Mailhot wrote: > Le jeudi 12 novembre 2009 ? 06:51 +0200, Gilboa Davara a ?crit : > > > I own both icewm and idesk. > > As far as I know, both icewm and idesk are linked against xft and should > > not default to core fonts. (Unless I completely misunderstanding > > something...) > > I've been asked to filter out xft matches next run, so if they *only* do > xft they won't appear again. Thanks. - Gilboa From rawhide at fedoraproject.org Thu Nov 12 12:28:18 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Thu, 12 Nov 2009 12:28:18 +0000 Subject: rawhide report: 20091112 changes Message-ID: <20091112122818.GA22353@releng2.fedora.phx.redhat.com> Compose started at Thu Nov 12 08:15:08 UTC 2009 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 From jwboyer at gmail.com Thu Nov 12 13:00:55 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 12 Nov 2009 08:00:55 -0500 Subject: FF 3.5.5 for F-12 In-Reply-To: <1257986933.2590.10.camel@shrek.rexursive.com> References: <1257986933.2590.10.camel@shrek.rexursive.com> Message-ID: <20091112130055.GE5699@hansolo.jdub.homelinux.org> On Thu, Nov 12, 2009 at 11:48:53AM +1100, Bojan Smojver wrote: >What happened to that? It's been built in Koji but it's not Rawhide or >updates... It's there now. It will be included in the next push. josh From pertusus at free.fr Thu Nov 12 13:42:12 2009 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 12 Nov 2009 14:42:12 +0100 Subject: Identifying remaining core font users In-Reply-To: <1257947580.841.76.camel@arekh.okg> References: <1257941463.841.37.camel@arekh.okg> <20091111132241.GC28964@amd.home.annexia.org> <1257947580.841.76.camel@arekh.okg> Message-ID: <20091112134212.GA4719@free.fr> On Wed, Nov 11, 2009 at 02:53:00PM +0100, Nicolas Mailhot wrote: > > The right person to ask this would be Behdad, as he's the Fedora/Red > Hat/upstream maintainer of most core components of our current text > stack. IIRC his advice last time I asked the question was to avoid > accessing fontconfig directly, but to pass through gtk2/pango, QT, or > pango-cairo in cairo Is using Xft an acceptable way of using fontconfig or is it too low level? -- Pat From rjones at redhat.com Thu Nov 12 13:49:34 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 12 Nov 2009 13:49:34 +0000 Subject: Identifying remaining core font users In-Reply-To: <20091112134212.GA4719@free.fr> References: <1257941463.841.37.camel@arekh.okg> <20091111132241.GC28964@amd.home.annexia.org> <1257947580.841.76.camel@arekh.okg> <20091112134212.GA4719@free.fr> Message-ID: <20091112134934.GA5442@amd.home.annexia.org> On Thu, Nov 12, 2009 at 02:42:12PM +0100, Patrice Dumas wrote: > On Wed, Nov 11, 2009 at 02:53:00PM +0100, Nicolas Mailhot wrote: > > > > The right person to ask this would be Behdad, as he's the Fedora/Red > > Hat/upstream maintainer of most core components of our current text > > stack. IIRC his advice last time I asked the question was to avoid > > accessing fontconfig directly, but to pass through gtk2/pango, QT, or > > pango-cairo in cairo > > Is using Xft an acceptable way of using fontconfig or is it too low > level? Behdad's advice to me was to use Xft to replace raw X*Font calls in the example I gave: http://caml.inria.fr/cgi-bin/viewcvs.cgi/ocaml/trunk/otherlibs/graph/text.c?rev=6171&view=markup Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From schwab at redhat.com Thu Nov 12 13:59:17 2009 From: schwab at redhat.com (Andreas Schwab) Date: Thu, 12 Nov 2009 14:59:17 +0100 Subject: Identifying remaining core font users In-Reply-To: <1257941463.841.37.camel@arekh.okg> (Nicolas Mailhot's message of "Wed, 11 Nov 2009 13:11:03 +0100") References: <1257941463.841.37.camel@arekh.okg> Message-ID: Nicolas Mailhot writes: > Therefore, I'd like to identify remaining core font users, and remind > them periodically their core font use is not good for their users or for > Fedora. What's wrong with proving support for core fonts as a fallback? That's what Emacs is doing, for example. Andreas. -- Andreas Schwab, schwab at redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." From ajax at redhat.com Thu Nov 12 14:34:14 2009 From: ajax at redhat.com (Adam Jackson) Date: Thu, 12 Nov 2009 09:34:14 -0500 Subject: Identifying remaining core font users In-Reply-To: References: <1257941463.841.37.camel@arekh.okg> Message-ID: <1258036454.7251.3968.camel@atropine.boston.devel.redhat.com> On Thu, 2009-11-12 at 14:59 +0100, Andreas Schwab wrote: > Nicolas Mailhot writes: > > > Therefore, I'd like to identify remaining core font users, and remind > > them periodically their core font use is not good for their users or for > > Fedora. > > What's wrong with proving support for core fonts as a fallback? That's > what Emacs is doing, for example. As a fallback for what? - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From schwab at redhat.com Thu Nov 12 15:00:08 2009 From: schwab at redhat.com (Andreas Schwab) Date: Thu, 12 Nov 2009 16:00:08 +0100 Subject: Identifying remaining core font users In-Reply-To: <1258036454.7251.3968.camel@atropine.boston.devel.redhat.com> (Adam Jackson's message of "Thu, 12 Nov 2009 09:34:14 -0500") References: <1257941463.841.37.camel@arekh.okg> <1258036454.7251.3968.camel@atropine.boston.devel.redhat.com> Message-ID: Adam Jackson writes: > On Thu, 2009-11-12 at 14:59 +0100, Andreas Schwab wrote: >> Nicolas Mailhot writes: >> >> > Therefore, I'd like to identify remaining core font users, and remind >> > them periodically their core font use is not good for their users or for >> > Fedora. >> >> What's wrong with proving support for core fonts as a fallback? That's >> what Emacs is doing, for example. > > As a fallback for what? If a suitable xft font is not found. Andreas. -- Andreas Schwab, schwab at redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." From sandeen at redhat.com Thu Nov 12 15:03:02 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Thu, 12 Nov 2009 09:03:02 -0600 Subject: cpio to ext4 seems much slower than to ext2, ext3 or xfs In-Reply-To: <20091112101815.GA4039@amd.home.annexia.org> References: <20091111101421.GA28964@amd.home.annexia.org> <20091111105322.GB28964@amd.home.annexia.org> <4AFAA306.9090003@lfarkas.org> <200911111233.32771.gene@czarc.net> <4AFB0F64.1010505@redhat.com> <20091111210520.GA622@amd.home.annexia.org> <20091112095412.GA2060@redhat.com> <20091112101815.GA4039@amd.home.annexia.org> Message-ID: <4AFC23A6.50209@redhat.com> Richard W.M. Jones wrote: > On Thu, Nov 12, 2009 at 09:54:12AM +0000, Daniel P. Berrange wrote: >> On Wed, Nov 11, 2009 at 09:05:20PM +0000, Richard W.M. Jones wrote: >>> On Wed, Nov 11, 2009 at 01:24:20PM -0600, Eric Sandeen wrote: >>>> Anybody got actual numbers? I don't disagree that mkfs.ext4 is slow in >>>> the default config, but I don't think it should be slower than mkfs.ext3 >>>> for the same sized disks. >>> Easy with guestfish: >>> >>> $ guestfish --version >>> guestfish 1.0.78 >>> $ for fs in ext2 ext3 ext4 xfs jfs ; do guestfish sparse /tmp/test.img 10G : run : echo $fs : sfdiskM /dev/sda , : time mkfs $fs /dev/sda1 ; done >>> ext2 >>> elapsed time: 5.21 seconds >>> ext3 >>> elapsed time: 7.87 seconds >>> ext4 >>> elapsed time: 6.10 seconds >>> xfs >>> elapsed time: 0.45 seconds >>> jfs >>> elapsed time: 0.78 seconds >>> >>> Note that because this is using a sparsely allocated disk each write >>> to the virtual disk is very slow. Change 'sparse' to 'alloc' to test >>> this with a non-sparse file-backed disk. >> You really want to avoid using sparse files at all when doing any kind of >> benchmark / performance tests in VMs. The combo of a sparse file store on >> a journalling filesystem in the host, w/ virt can cause very pathelogically >> bad I/O performance until the file has all its extents fully allocated on >> the host FS. So the use of a sparse file may well be exagarating the real >> difference in elapsed time between these different mkfs calls in the >> guest. > > Again, this time backed by a 10 GB logical volume in the host, so this > should remove pretty much all host effects: > > $ for fs in ext2 ext3 ext4 xfs jfs reiserfs nilfs2 ntfs msdos btrfs hfs hfsplus gfs gfs2 ; do guestfish add /dev/mapper/vg_trick-Temp : run : zero /dev/sda : echo $fs : sfdiskM /dev/sda , : time mkfs $fs /dev/sda1 ; done > ext2 > elapsed time: 3.48 seconds > ext3 > elapsed time: 5.45 seconds > ext4 > elapsed time: 5.19 seconds so here we have ext4 slightly faster, which was the original question... ;) (dropping caches in between might be best, too...) > xfs > elapsed time: 0.35 seconds > jfs > elapsed time: 0.66 seconds > reiserfs > elapsed time: 0.73 seconds > nilfs2 > elapsed time: 0.19 seconds > ntfs > elapsed time: 2.33 seconds > msdos > elapsed time: 0.29 seconds > btrfs > elapsed time: 0.16 seconds > hfs > elapsed time: 0.44 seconds > hfsplus > elapsed time: 0.46 seconds > gfs > elapsed time: 1.60 seconds > gfs2 > elapsed time: 3.98 seconds > > I'd like to repeat my proviso: I think this test is meaningless for > most users. Until users have 8TB raids at home, which is not really that far off ... -Eric > Rich. > From dennisml at conversis.de Thu Nov 12 15:20:34 2009 From: dennisml at conversis.de (Dennis J.) Date: Thu, 12 Nov 2009 16:20:34 +0100 Subject: cpio to ext4 seems much slower than to ext2, ext3 or xfs In-Reply-To: <4AFC23A6.50209@redhat.com> References: <20091111101421.GA28964@amd.home.annexia.org> <20091111105322.GB28964@amd.home.annexia.org> <4AFAA306.9090003@lfarkas.org> <200911111233.32771.gene@czarc.net> <4AFB0F64.1010505@redhat.com> <20091111210520.GA622@amd.home.annexia.org> <20091112095412.GA2060@redhat.com> <20091112101815.GA4039@amd.home.annexia.org> <4AFC23A6.50209@redhat.com> Message-ID: <4AFC27C2.5010300@conversis.de> On 11/12/2009 04:03 PM, Eric Sandeen wrote: > Richard W.M. Jones wrote: >> On Thu, Nov 12, 2009 at 09:54:12AM +0000, Daniel P. Berrange wrote: >>> On Wed, Nov 11, 2009 at 09:05:20PM +0000, Richard W.M. Jones wrote: >>>> On Wed, Nov 11, 2009 at 01:24:20PM -0600, Eric Sandeen wrote: >>>>> Anybody got actual numbers? I don't disagree that mkfs.ext4 is slow >>>>> in the default config, but I don't think it should be slower than >>>>> mkfs.ext3 for the same sized disks. >>>> Easy with guestfish: >>>> >>>> $ guestfish --version >>>> guestfish 1.0.78 >>>> $ for fs in ext2 ext3 ext4 xfs jfs ; do guestfish sparse >>>> /tmp/test.img 10G : run : echo $fs : sfdiskM /dev/sda , : time mkfs >>>> $fs /dev/sda1 ; done >>>> ext2 >>>> elapsed time: 5.21 seconds >>>> ext3 >>>> elapsed time: 7.87 seconds >>>> ext4 >>>> elapsed time: 6.10 seconds >>>> xfs >>>> elapsed time: 0.45 seconds >>>> jfs >>>> elapsed time: 0.78 seconds >>>> >>>> Note that because this is using a sparsely allocated disk each write >>>> to the virtual disk is very slow. Change 'sparse' to 'alloc' to test >>>> this with a non-sparse file-backed disk. >>> You really want to avoid using sparse files at all when doing any >>> kind of >>> benchmark / performance tests in VMs. The combo of a sparse file >>> store on >>> a journalling filesystem in the host, w/ virt can cause very >>> pathelogically >>> bad I/O performance until the file has all its extents fully >>> allocated on >>> the host FS. So the use of a sparse file may well be exagarating the >>> real >>> difference in elapsed time between these different mkfs calls in the >>> guest. >> >> Again, this time backed by a 10 GB logical volume in the host, so this >> should remove pretty much all host effects: >> >> $ for fs in ext2 ext3 ext4 xfs jfs reiserfs nilfs2 ntfs msdos btrfs >> hfs hfsplus gfs gfs2 ; do guestfish add /dev/mapper/vg_trick-Temp : >> run : zero /dev/sda : echo $fs : sfdiskM /dev/sda , : time mkfs $fs >> /dev/sda1 ; done > > >> ext2 >> elapsed time: 3.48 seconds > >> ext3 >> elapsed time: 5.45 seconds >> ext4 >> elapsed time: 5.19 seconds > > so here we have ext4 slightly faster, which was the original question... ;) > > (dropping caches in between might be best, too...) > >> xfs >> elapsed time: 0.35 seconds >> jfs >> elapsed time: 0.66 seconds >> reiserfs >> elapsed time: 0.73 seconds >> nilfs2 >> elapsed time: 0.19 seconds >> ntfs >> elapsed time: 2.33 seconds >> msdos >> elapsed time: 0.29 seconds >> btrfs >> elapsed time: 0.16 seconds >> hfs >> elapsed time: 0.44 seconds >> hfsplus >> elapsed time: 0.46 seconds >> gfs >> elapsed time: 1.60 seconds >> gfs2 >> elapsed time: 3.98 seconds >> >> I'd like to repeat my proviso: I think this test is meaningless for >> most users. > > Until users have 8TB raids at home, which is not really that far off ... Let's hope btrfs is production ready before then because extX doesn't look like a fitting filesystem for such big drives due their lack of online fsck. Regards, Dennis From rjones at redhat.com Thu Nov 12 15:39:22 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 12 Nov 2009 15:39:22 +0000 Subject: cpio to ext4 seems much slower than to ext2, ext3 or xfs In-Reply-To: <4AFC23A6.50209@redhat.com> References: <20091111101421.GA28964@amd.home.annexia.org> <20091111105322.GB28964@amd.home.annexia.org> <4AFAA306.9090003@lfarkas.org> <200911111233.32771.gene@czarc.net> <4AFB0F64.1010505@redhat.com> <20091111210520.GA622@amd.home.annexia.org> <20091112095412.GA2060@redhat.com> <20091112101815.GA4039@amd.home.annexia.org> <4AFC23A6.50209@redhat.com> Message-ID: <20091112153922.GA6036@amd.home.annexia.org> On Thu, Nov 12, 2009 at 09:03:02AM -0600, Eric Sandeen wrote: > so here we have ext4 slightly faster, which was the original question... ;) > > (dropping caches in between might be best, too...) It starts a whole new VM between each test. > Until users have 8TB raids at home, which is not really that far off ... :-) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 ajax at redhat.com Thu Nov 12 16:17:24 2009 From: ajax at redhat.com (Adam Jackson) Date: Thu, 12 Nov 2009 11:17:24 -0500 Subject: Identifying remaining core font users In-Reply-To: References: <1257941463.841.37.camel@arekh.okg> <1258036454.7251.3968.camel@atropine.boston.devel.redhat.com> Message-ID: <1258042644.7251.4080.camel@atropine.boston.devel.redhat.com> On Thu, 2009-11-12 at 16:00 +0100, Andreas Schwab wrote: > Adam Jackson writes: > > On Thu, 2009-11-12 at 14:59 +0100, Andreas Schwab wrote: > >> Nicolas Mailhot writes: > >> > >> > Therefore, I'd like to identify remaining core font users, and remind > >> > them periodically their core font use is not good for their users or for > >> > Fedora. > >> > >> What's wrong with proving support for core fonts as a fallback? That's > >> what Emacs is doing, for example. > > > > As a fallback for what? > > If a suitable xft font is not found. Though the X server is not using fontconfig for finding fonts (for lame historical reasons), it looks in a subset of the set of paths that fontconfig will look at. (Xft is a renderer, not a font looker upper, but your meaning was clear.) - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From orion at cora.nwra.com Thu Nov 12 16:44:46 2009 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 12 Nov 2009 09:44:46 -0700 Subject: netcdf update and soname bump In-Reply-To: <4AFB4AE4.3030500@cora.nwra.com> References: <4AFAF1BC.5070104@cora.nwra.com> <4AFB4AE4.3030500@cora.nwra.com> Message-ID: <4AFC3B7E.6000900@cora.nwra.com> On 11/11/2009 04:38 PM, Orion Poplawski wrote: > On 11/11/2009 10:17 AM, Orion Poplawski wrote: >> I'm about to build a netcdf 4.1.0 beta snapshot for F-13. This is a >> soname bump (libnetcdf.so.4 -> libnetcdf.so.6). It also enables the >> netcdf4, dap, and ncgen4 features of netcdf. > > There are some linking issues to work out upstream, and some packages > don't expect to have to link to additional libraries in addition to > -lnetcdf. If you have trouble, you can work around for now with adding > the following to your configure line: > > LIBS="$(pkg-config netcdf --libs)" I think I've fixed the netcdf/hdf5 linkage issue, so this should not be required. -- 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 sandeen at redhat.com Thu Nov 12 16:59:55 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Thu, 12 Nov 2009 10:59:55 -0600 Subject: cpio to ext4 seems much slower than to ext2, ext3 or xfs In-Reply-To: <4AFC27C2.5010300@conversis.de> References: <20091111101421.GA28964@amd.home.annexia.org> <20091111105322.GB28964@amd.home.annexia.org> <4AFAA306.9090003@lfarkas.org> <200911111233.32771.gene@czarc.net> <4AFB0F64.1010505@redhat.com> <20091111210520.GA622@amd.home.annexia.org> <20091112095412.GA2060@redhat.com> <20091112101815.GA4039@amd.home.annexia.org> <4AFC23A6.50209@redhat.com> <4AFC27C2.5010300@conversis.de> Message-ID: <4AFC3F0B.4080400@redhat.com> Dennis J. wrote: > On 11/12/2009 04:03 PM, Eric Sandeen wrote: >> Richard W.M. Jones wrote: ... >>> I'd like to repeat my proviso: I think this test is meaningless for >>> most users. >> >> Until users have 8TB raids at home, which is not really that far off ... > > Let's hope btrfs is production ready before then because extX doesn't > look like a fitting filesystem for such big drives due their lack of > online fsck. ext4's fsck is much faster than ext3's, and xfs's repair tool is also pretty speedy. Both are offline, but so far online fsck for btrfs is just a goal, no (released, anyway) code yet AFAIK. -Eric > Regards, > Dennis > From nathanael at gnat.ca Thu Nov 12 17:31:27 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Thu, 12 Nov 2009 10:31:27 -0700 Subject: abrt / kernel oops issue Message-ID: <4AFC466F.2060201@gnat.ca> Hello, I've been running F12/rawhide from a preupgrade from F11 for a couple weeks now. I've just recently noticed the abrt feature. I started submitting the bugs it found in the kerneloops. Which has me wondering couple things. #1 - I have many many kerneloops, each stacktrace/log snippet seems fairly identical. I assume you would prefer not to get 20 identical abrt submitted bugs? Or should I submit them all? #2 - When looking at the trace it has the following line(s): Nov 10 09:15:57 iridium kernel: WARNING: at lib/list_debug.c:30 __list_add+0x68/0x81() (Tainted: G W ) ... Nov 10 09:15:57 iridium kernel: Pid: 2197, comm: Xorg Tainted: G W 2.6.31.5-127.fc12.x86_64 #1 I'm wondering why it is saying it is tainted.. or maybe Tainted: G mean Good?? I don't have any closed source modules loaded as far as I know. Unless Virtualbox is closed source but I didn't think it was. Virtualbox isn't running when this happens, though the module seems to be loaded. #3 Validity of the bugs it is finding... It calls the following a kerneloops... > Nov 11 16:56:41 iridium gnome-session[2259]: WARNING: Could not parse desktop file /etc/xdg/autostart/network-manager-netbook.desktop: Key file does not have key 'Name' > Nov 11 16:56:41 iridium gnome-session[2259]: WARNING: could not read /etc/xdg/autostart/network-manager-netbook.desktop > Nov 11 16:56:42 iridium kernel: executing set pll > Nov 11 16:56:42 iridium kernel: executing set crtc timing > Nov 11 16:56:42 iridium kernel: [drm] TMDS-15: set mode 25 > Nov 11 16:56:42 iridium kernel: executing set pll > Nov 11 16:56:42 iridium kernel: executing set crtc timing > Nov 11 16:56:42 iridium kernel: [drm] TMDS-11: set mode 2f > Nov 11 16:56:42 iridium kernel: fuse init (API version 7.12) > Nov 11 16:56:43 iridium pulseaudio[2406]: pid.c: Daemon already running. > Nov 11 16:56:46 iridium restorecond: Unable to watch (/home/****/public_html/*) No such file or directory do I submit this anyway? Thanks, just rying to do my part without burying you guys in senseless bug reports. From rjones at redhat.com Thu Nov 12 17:38:57 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 12 Nov 2009 17:38:57 +0000 Subject: Identifying remaining core font users In-Reply-To: <20091112134934.GA5442@amd.home.annexia.org> References: <1257941463.841.37.camel@arekh.okg> <20091111132241.GC28964@amd.home.annexia.org> <1257947580.841.76.camel@arekh.okg> <20091112134212.GA4719@free.fr> <20091112134934.GA5442@amd.home.annexia.org> Message-ID: <20091112173857.GA6736@amd.home.annexia.org> On Thu, Nov 12, 2009 at 01:49:34PM +0000, Richard W.M. Jones wrote: > Behdad's advice to me was to use Xft to replace raw X*Font calls in > the example I gave: > > http://caml.inria.fr/cgi-bin/viewcvs.cgi/ocaml/trunk/otherlibs/graph/text.c?rev=6171&view=markup This is the patch I submitted upstream: http://annexia.org/tmp/0001-Graphics-Use-modern-X-fonts-instead-of-X-core-fonts-2.patch.txt Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 dcbw at redhat.com Thu Nov 12 17:50:13 2009 From: dcbw at redhat.com (Dan Williams) Date: Thu, 12 Nov 2009 09:50:13 -0800 Subject: abrt / kernel oops issue In-Reply-To: <4AFC466F.2060201@gnat.ca> References: <4AFC466F.2060201@gnat.ca> Message-ID: <1258048213.2347.94.camel@localhost.localdomain> On Thu, 2009-11-12 at 10:31 -0700, Nathanael D. Noblet wrote: > Hello, > I've been running F12/rawhide from a preupgrade from F11 for a couple > weeks now. I've just recently noticed the abrt feature. I started > submitting the bugs it found in the kerneloops. Which has me wondering > couple things. > > #1 - I have many many kerneloops, each stacktrace/log snippet seems > fairly identical. I assume you would prefer not to get 20 identical abrt > submitted bugs? Or should I submit them all? > > #2 - When looking at the trace it has the following line(s): > > Nov 10 09:15:57 iridium kernel: WARNING: at lib/list_debug.c:30 > __list_add+0x68/0x81() (Tainted: G W ) > > ... > > Nov 10 09:15:57 iridium kernel: Pid: 2197, comm: Xorg Tainted: G > W 2.6.31.5-127.fc12.x86_64 #1 > > > I'm wondering why it is saying it is tainted.. or maybe Tainted: G mean > Good?? I don't have any closed source modules loaded as far as I know. > Unless Virtualbox is closed source but I didn't think it was. Virtualbox > isn't running when this happens, though the module seems to be loaded. If you have an oops or BUG of any sort, I think that sets the taint flag for further oops reports, because after the first one you can't really trust that the stacktrace or internal kernel structures aren't corrupted. Most of the time they aren't, but you simply can't trust that. So I'd expect the first one to be untainted, and then subsequent oops reports to have the taint flag set. Of course if you start loading random kernel modules that didn't come with the kernel itself, you can also taint the kernel. If you have staging drivers loaded, you'll have the taint_crap flag set because staging drivers are crap. Dan > > #3 Validity of the bugs it is finding... It calls the following a > kerneloops... > > > Nov 11 16:56:41 iridium gnome-session[2259]: WARNING: Could not parse desktop file /etc/xdg/autostart/network-manager-netbook.desktop: Key file does not have key 'Name' > > Nov 11 16:56:41 iridium gnome-session[2259]: WARNING: could not read /etc/xdg/autostart/network-manager-netbook.desktop > > Nov 11 16:56:42 iridium kernel: executing set pll > > Nov 11 16:56:42 iridium kernel: executing set crtc timing > > Nov 11 16:56:42 iridium kernel: [drm] TMDS-15: set mode 25 > > Nov 11 16:56:42 iridium kernel: executing set pll > > Nov 11 16:56:42 iridium kernel: executing set crtc timing > > Nov 11 16:56:42 iridium kernel: [drm] TMDS-11: set mode 2f > > Nov 11 16:56:42 iridium kernel: fuse init (API version 7.12) > > Nov 11 16:56:43 iridium pulseaudio[2406]: pid.c: Daemon already running. > > Nov 11 16:56:46 iridium restorecond: Unable to watch (/home/****/public_html/*) No such file or directory > > do I submit this anyway? > > > Thanks, just rying to do my part without burying you guys in senseless > bug reports. > From nathanael at gnat.ca Thu Nov 12 18:01:39 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Thu, 12 Nov 2009 11:01:39 -0700 Subject: abrt / kernel oops issue In-Reply-To: <1258048213.2347.94.camel@localhost.localdomain> References: <4AFC466F.2060201@gnat.ca> <1258048213.2347.94.camel@localhost.localdomain> Message-ID: <4AFC4D83.8000302@gnat.ca> On 11/12/2009 10:50 AM, Dan Williams wrote: > If you have an oops or BUG of any sort, I think that sets the taint flag > for further oops reports, because after the first one you can't really > trust that the stacktrace or internal kernel structures aren't > corrupted. Most of the time they aren't, but you simply can't trust > that. So I'd expect the first one to be untainted, and then subsequent > oops reports to have the taint flag set. I see.. I'll have to reboot and see if the first one is not being marked as tainted. > Of course if you start loading random kernel modules that didn't come > with the kernel itself, you can also taint the kernel. If you have > staging drivers loaded, you'll have the taint_crap flag set because > staging drivers are crap. I'm not manually loading anything, and the only module I have loaded that isn't part of the kernel rpm package itself is Virtualbox. Which I can remove or not load to see if it makes a difference. I have to also note that I didn't even know I was having kernel oops until abrt popped up. From dennisml at conversis.de Thu Nov 12 18:30:18 2009 From: dennisml at conversis.de (Dennis J.) Date: Thu, 12 Nov 2009 19:30:18 +0100 Subject: cpio to ext4 seems much slower than to ext2, ext3 or xfs In-Reply-To: <4AFC3F0B.4080400@redhat.com> References: <20091111101421.GA28964@amd.home.annexia.org> <20091111105322.GB28964@amd.home.annexia.org> <4AFAA306.9090003@lfarkas.org> <200911111233.32771.gene@czarc.net> <4AFB0F64.1010505@redhat.com> <20091111210520.GA622@amd.home.annexia.org> <20091112095412.GA2060@redhat.com> <20091112101815.GA4039@amd.home.annexia.org> <4AFC23A6.50209@redhat.com> <4AFC27C2.5010300@conversis.de> <4AFC3F0B.4080400@redhat.com> Message-ID: <4AFC543A.2090409@conversis.de> On 11/12/2009 05:59 PM, Eric Sandeen wrote: > Dennis J. wrote: >> On 11/12/2009 04:03 PM, Eric Sandeen wrote: >>> Richard W.M. Jones wrote: > > ... > >>>> I'd like to repeat my proviso: I think this test is meaningless for >>>> most users. >>> >>> Until users have 8TB raids at home, which is not really that far off ... >> >> Let's hope btrfs is production ready before then because extX doesn't >> look like a fitting filesystem for such big drives due their lack of >> online fsck. > > ext4's fsck is much faster than ext3's, and xfs's repair tool is also > pretty speedy. > > Both are offline, but so far online fsck for btrfs is just a goal, no > (released, anyway) code yet AFAIK. Isn't the speed improvement of ext4 achieved by not dealing with empty extends/blocks? If so that wouldn't help you much if those 8TB are really used. But even a speedy fsck is going to take longer and longer as filesystem size grows which is why I believe we will soon reach a point were offline-fsck simply isn't a viable option anymore. I have a 30TB storage system that I chopped into ten individual volumes because current filesystems don't really make creating a single 30TB fs a wise choice even though I'd like to be able to do that. Regards, Dennis From adrian at lisas.de Thu Nov 12 18:39:48 2009 From: adrian at lisas.de (Adrian Reber) Date: Thu, 12 Nov 2009 19:39:48 +0100 Subject: id3lib stack smashing Message-ID: <20091112183948.GS16031@lisas.de> There is ubuntu bug report against id3lib "libid3 crashes (stack smashing) when reading VBR MP3 file"[1]. I am able to reproduce this on ubuntu but not on Fedora and I do not understand why. The patch[2] looks like it is doing the right thing but there is not stack smashing detected using the Fedora version (even on ubuntu). I have looked at the ubuntu build logs[3] and it uses completely different compiler flags. Is one of those flags the reason for not seeing the stack smashing on Fedora? Adrian [1]https://bugs.launchpad.net/ubuntu/+source/id3lib3.8.3/+bug/444466 [2]http://launchpadlibrarian.net/33114077/id3lib-vbr_buffer_overflow.diff [3]http://launchpadlibrarian.net/30361665/buildlog_ubuntu-karmic-i386.id3lib3.8.3_3.8.3-7.2ubuntu1_FULLYBUILT.txt.gz From nicolas.mailhot at laposte.net Thu Nov 12 19:34:24 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 12 Nov 2009 20:34:24 +0100 Subject: Identifying remaining core font users In-Reply-To: <1258024136.6989.30.camel@gilboa-home-dev.localdomain> References: <1257941463.841.37.camel@arekh.okg> <1258001480.6989.23.camel@gilboa-home-dev.localdomain> <1258008142.8351.0.camel@arekh.okg> <1258024136.6989.30.camel@gilboa-home-dev.localdomain> Message-ID: <1258054464.12961.7.camel@arekh.okg> Le jeudi 12 novembre 2009 ? 13:08 +0200, Gilboa Davara a ?crit : > On Thu, 2009-11-12 at 07:42 +0100, Nicolas Mailhot wrote: > > Le jeudi 12 novembre 2009 ? 06:51 +0200, Gilboa Davara a ?crit : > > > > > I own both icewm and idesk. > > > As far as I know, both icewm and idesk are linked against xft and should > > > not default to core fonts. (Unless I completely misunderstanding > > > something...) > > > > I've been asked to filter out xft matches next run, so if they *only* do > > xft they won't appear again. > > Thanks. However please note that even though using xft is less bad than using core fonts, xft alone is still not a complete text stack. For robust text support nothing less than fontconfig and a shaper such as the one in qt, pango or pango-cairo will work -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Thu Nov 12 19:39:36 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 12 Nov 2009 20:39:36 +0100 Subject: Identifying remaining core font users In-Reply-To: References: <1257941463.841.37.camel@arekh.okg> Message-ID: <1258054776.12961.17.camel@arekh.okg> Le jeudi 12 novembre 2009 ? 14:59 +0100, Andreas Schwab a ?crit : > Nicolas Mailhot writes: > > > Therefore, I'd like to identify remaining core font users, and remind > > them periodically their core font use is not good for their users or for > > Fedora. > > What's wrong with proving support for core fonts as a fallback? That's > what Emacs is doing, for example. The problem here is your fallback is going to be less robust than your primary path. Also it is not needed at all. Every single major GUI app uses the "new" (in 2003 sense of new) font backend, so if it fails you're not going to fallback individual apps you're going to switch to the console to fix the system. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Thu Nov 12 19:55:36 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 12 Nov 2009 20:55:36 +0100 Subject: Identifying remaining core font users In-Reply-To: <1258054464.12961.7.camel@arekh.okg> References: <1257941463.841.37.camel@arekh.okg> <1258001480.6989.23.camel@gilboa-home-dev.localdomain> <1258008142.8351.0.camel@arekh.okg> <1258024136.6989.30.camel@gilboa-home-dev.localdomain> <1258054464.12961.7.camel@arekh.okg> Message-ID: <1258055736.14447.3.camel@arekh.okg> Le jeudi 12 novembre 2009 ? 20:34 +0100, Nicolas Mailhot a ?crit : > However please note that even though using xft is less bad than using > core fonts, xft alone is still not a complete text stack. (I should have written, using xft directly. xft2 uses fontconfig but direct xft2 access bypasses the shaper layer. The shaper is needed for the complex glyph positioning required by some asian languages, and for the typographic features integrated in smart fonts, including latin ones) > For robust text support nothing less than fontconfig and a shaper such > as the one in qt, pango or pango-cairo will work -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jlaska at redhat.com Thu Nov 12 19:56:42 2009 From: jlaska at redhat.com (James Laska) Date: Thu, 12 Nov 2009 14:56:42 -0500 Subject: FESCO ticket#270 - preupgrade and F-12 Message-ID: <1258055802.2192.53.camel@localhost.localdomain> Greetings folks, After careful review by Will Woods around recently discovered problems related to preupgrading to Fedora 12, I've filed ticket#270 (https://fedorahosted.org/fesco/ticket/270) for discussion at the next FESCO meeting. Please take a moment to read the details in the ticket. The high-level summary from Will ... preupgrade to F12 is basically not going to work for anyone without significant manual workarounds, due to insufficient disk space on /boot. I think we may need to talk to hughsie and/or the desktop team about removing the preupgrade integration in PackageKit for F10/F11 and how to do preupgrade right for F13 and higher. Most of the folks impacted by this proposal are already informed. However, as per the FESCO meeting guidelines [1], I'm sending this to fedora-devel-list for wider discussion. Thanks, James [1] https://fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines#Meeting_shall_be_quick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From linuxguy123 at gmail.com Thu Nov 12 20:00:32 2009 From: linuxguy123 at gmail.com (Linuxguy123) Date: Thu, 12 Nov 2009 13:00:32 -0700 Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: <1258055802.2192.53.camel@localhost.localdomain> References: <1258055802.2192.53.camel@localhost.localdomain> Message-ID: <1258056032.3749.5.camel@localhost.localdomain> On Thu, 2009-11-12 at 14:56 -0500, James Laska wrote: > Greetings folks, > > After careful review by Will Woods around recently discovered problems > related to preupgrading to Fedora 12, I've filed ticket#270 > (https://fedorahosted.org/fesco/ticket/270) for discussion at the next > FESCO meeting. Please take a moment to read the details in the ticket. > > The high-level summary from Will ... > > preupgrade to F12 is basically not going to work for anyone > without significant manual workarounds, due to insufficient disk > space on /boot. How much disk space will one require on /boot to perform the update without work arounds ? Can gparted resize /boot ? Thanks From rwheeler at redhat.com Thu Nov 12 20:05:14 2009 From: rwheeler at redhat.com (Ric Wheeler) Date: Thu, 12 Nov 2009 15:05:14 -0500 Subject: cpio to ext4 seems much slower than to ext2, ext3 or xfs In-Reply-To: <4AFC543A.2090409@conversis.de> References: <20091111101421.GA28964@amd.home.annexia.org> <20091111105322.GB28964@amd.home.annexia.org> <4AFAA306.9090003@lfarkas.org> <200911111233.32771.gene@czarc.net> <4AFB0F64.1010505@redhat.com> <20091111210520.GA622@amd.home.annexia.org> <20091112095412.GA2060@redhat.com> <20091112101815.GA4039@amd.home.annexia.org> <4AFC23A6.50209@redhat.com> <4AFC27C2.5010300@conversis.de> <4AFC3F0B.4080400@redhat.com> <4AFC543A.2090409@conversis.de> Message-ID: <4AFC6A7A.5050802@redhat.com> On 11/12/2009 01:30 PM, Dennis J. wrote: > On 11/12/2009 05:59 PM, Eric Sandeen wrote: >> Dennis J. wrote: >>> On 11/12/2009 04:03 PM, Eric Sandeen wrote: >>>> Richard W.M. Jones wrote: >> >> ... >> >>>>> I'd like to repeat my proviso: I think this test is meaningless for >>>>> most users. >>>> >>>> Until users have 8TB raids at home, which is not really that far off >>>> ... >>> >>> Let's hope btrfs is production ready before then because extX doesn't >>> look like a fitting filesystem for such big drives due their lack of >>> online fsck. >> >> ext4's fsck is much faster than ext3's, and xfs's repair tool is also >> pretty speedy. >> >> Both are offline, but so far online fsck for btrfs is just a goal, no >> (released, anyway) code yet AFAIK. > > Isn't the speed improvement of ext4 achieved by not dealing with empty > extends/blocks? If so that wouldn't help you much if those 8TB are > really used. But even a speedy fsck is going to take longer and longer > as filesystem size grows which is why I believe we will soon reach a > point were offline-fsck simply isn't a viable option anymore. > I have a 30TB storage system that I chopped into ten individual volumes > because current filesystems don't really make creating a single 30TB fs > a wise choice even though I'd like to be able to do that. > > Regards, > Dennis > In our testing with f12, I build a 60TB ext4 file system with 1 billion small files. A forced fsck of ext4 finished in 2.5 hours give or take a bit :-) The fill was artificial and the file system was not aged, so real world results will probably be slower. fsck time scales mostly with the number of allocated files in my experience. Allocated blocks (fewer very large files) are quite quick. ric From Jochen at herr-schmitt.de Thu Nov 12 20:01:29 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 12 Nov 2009 21:01:29 +0100 Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: <1258055802.2192.53.camel@localhost.localdomain> References: <1258055802.2192.53.camel@localhost.localdomain> Message-ID: <4AFC6999.3060602@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 12.11.2009 20:56, schrieb James Laska: > > preupgrade to F12 is basically not going to work for anyone without > significant manual workarounds, due to insufficient disk space on > /boot. I think we may need to talk to hughsie and/or the desktop > team about removing the preupgrade integration in PackageKit for > F10/F11 and how to do preupgrade right for F13 and higher. My last experience with preupgrade was, that I have go an error message because there was not enaugh space on the /boot partition to download a special image. But after rebooting I was able to download this image from a mirror server before my system starts the upgrade process. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iJwEAQECAAYFAkr8aZEACgkQZLAIBz9lVu9edwQAlmTNnElmOCJDHBNxWu8uXuoi 7vuvyJxF+mGGHivNIiKJicpUn0P+aIIp+KglECHZEXW45HUG8Y6QC4L8Il7e1F8+ 4vYpG7FUSH7fCDqA56lXrb8fjv35lZ9ZB4nOo0zyurVR6F/LoZEEqKwTmdcYqOyc SL1KiYEZ1gAwAYMpECo= =Hszt -----END PGP SIGNATURE----- From hughsient at gmail.com Thu Nov 12 20:02:10 2009 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 12 Nov 2009 20:02:10 +0000 Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: <1258055802.2192.53.camel@localhost.localdomain> References: <1258055802.2192.53.camel@localhost.localdomain> Message-ID: <15e53e180911121202t4c101f7eofa7d607f668db0be@mail.gmail.com> 2009/11/12 James Laska : > ? ? ? ?preupgrade to F12 is basically not going to work for anyone > ? ? ? ?without significant manual workarounds, due to insufficient disk > ? ? ? ?space on /boot. I think we may need to talk to hughsie and/or > ? ? ? ?the desktop team about removing the preupgrade integration in > ? ? ? ?PackageKit for F10/F11 and how to do preupgrade right for F13 > ? ? ? ?and higher. Tomorrow I'll push a F11 update disabling the preupgrade functionality. This will give us enough time to fix things, and then we can "flip the switch" with another PK update in a few weeks that re-enables the upgrade functionality. Richard. From nicolas.mailhot at laposte.net Thu Nov 12 20:06:54 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 12 Nov 2009 21:06:54 +0100 Subject: Identifying remaining core font users In-Reply-To: <20091112173857.GA6736@amd.home.annexia.org> References: <1257941463.841.37.camel@arekh.okg> <20091111132241.GC28964@amd.home.annexia.org> <1257947580.841.76.camel@arekh.okg> <20091112134212.GA4719@free.fr> <20091112134934.GA5442@amd.home.annexia.org> <20091112173857.GA6736@amd.home.annexia.org> Message-ID: <1258056414.16638.1.camel@arekh.okg> Le jeudi 12 novembre 2009 ? 17:38 +0000, Richard W.M. Jones a ?crit : > On Thu, Nov 12, 2009 at 01:49:34PM +0000, Richard W.M. Jones wrote: > > Behdad's advice to me was to use Xft to replace raw X*Font calls in > > the example I gave: > > > > http://caml.inria.fr/cgi-bin/viewcvs.cgi/ocaml/trunk/otherlibs/graph/text.c?rev=6171&view=markup > > This is the patch I submitted upstream: > > http://annexia.org/tmp/0001-Graphics-Use-modern-X-fonts-instead-of-X-core-fonts-2.patch.txt > That was wonderfully reactive. Thanks! I should have posted the list earlier :p -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jlaska at redhat.com Thu Nov 12 20:10:13 2009 From: jlaska at redhat.com (James Laska) Date: Thu, 12 Nov 2009 15:10:13 -0500 Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: <1258056032.3749.5.camel@localhost.localdomain> References: <1258055802.2192.53.camel@localhost.localdomain> <1258056032.3749.5.camel@localhost.localdomain> Message-ID: <1258056613.2192.65.camel@localhost.localdomain> On Thu, 2009-11-12 at 13:00 -0700, Linuxguy123 wrote: > On Thu, 2009-11-12 at 14:56 -0500, James Laska wrote: > > Greetings folks, > > > > After careful review by Will Woods around recently discovered problems > > related to preupgrading to Fedora 12, I've filed ticket#270 > > (https://fedorahosted.org/fesco/ticket/270) for discussion at the next > > FESCO meeting. Please take a moment to read the details in the ticket. > > > > The high-level summary from Will ... > > > > preupgrade to F12 is basically not going to work for anyone > > without significant manual workarounds, due to insufficient disk > > space on /boot. > > How much disk space will one require on /boot to perform the update > without work arounds ? From the ticket (see URL above). Here's the details. The default /boot partition is 200MB, but there's some overhead: Ext3/Ext4 overhead: 7MB Reserved space: 10MB F11 kernel: 8MB (at least - usually 3 kernels = 24MB) GRUB/EFI files: 1MB Total overhead: 26MB So there's 174MB of usable space maximum, and usually 158MB available. preupgrade now requires at least 167MB free space on /boot: F12 installer images: 143MB (8mb larger than F11!) F12 kernel: 18MB (10mb larger than F11!) RPM/anaconda tmpfiles: >=8MB (measured in stupid tests) Total: 167MB (Was 149MB in F11 - no problem!) > Can gparted resize /boot ? There are definitely workarounds available, but none that meet the criteria for preupgrade as an effortless upgrade option. Thanks, James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From mail at robertoragusa.it Thu Nov 12 20:12:41 2009 From: mail at robertoragusa.it (Roberto Ragusa) Date: Thu, 12 Nov 2009 21:12:41 +0100 Subject: cpio to ext4 seems much slower than to ext2, ext3 or xfs In-Reply-To: <4AFC6A7A.5050802@redhat.com> References: <20091111101421.GA28964@amd.home.annexia.org> <20091111105322.GB28964@amd.home.annexia.org> <4AFAA306.9090003@lfarkas.org> <200911111233.32771.gene@czarc.net> <4AFB0F64.1010505@redhat.com> <20091111210520.GA622@amd.home.annexia.org> <20091112095412.GA2060@redhat.com> <20091112101815.GA4039@amd.home.annexia.org> <4AFC23A6.50209@redhat.com> <4AFC27C2.5010300@conversis.de> <4AFC3F0B.4080400@redhat.com> <4AFC543A.2090409@conversis.de> <4AFC6A7A.5050802@redhat.com> Message-ID: <4AFC6C39.2040901@robertoragusa.it> Ric Wheeler wrote: > In our testing with f12, I build a 60TB ext4 file system with 1 billion > small files. A forced fsck of ext4 finished in 2.5 hours give or take a > bit :-) The fill was artificial and the file system was not aged, so > real world results will probably be slower. > > fsck time scales mostly with the number of allocated files in my > experience. Allocated blocks (fewer very large files) are quite quick. > What kind of machine did you use? With 60TB a simple allocation bitmap for 4k-blocks takes almost 2GB; and this is just to detect free space or double allocation of blocks. Wow. -- Roberto Ragusa mail at robertoragusa.it From ndbecker2 at gmail.com Thu Nov 12 20:25:32 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 12 Nov 2009 15:25:32 -0500 Subject: FESCO ticket#270 - preupgrade and F-12 References: <1258055802.2192.53.camel@localhost.localdomain> <1258056032.3749.5.camel@localhost.localdomain> <1258056613.2192.65.camel@localhost.localdomain> Message-ID: James Laska wrote: > On Thu, 2009-11-12 at 13:00 -0700, Linuxguy123 wrote: >> On Thu, 2009-11-12 at 14:56 -0500, James Laska wrote: >> > Greetings folks, >> > >> > After careful review by Will Woods around recently discovered problems >> > related to preupgrading to Fedora 12, I've filed ticket#270 >> > (https://fedorahosted.org/fesco/ticket/270) for discussion at the next >> > FESCO meeting. Please take a moment to read the details in the ticket. >> > >> > The high-level summary from Will ... >> > >> > preupgrade to F12 is basically not going to work for anyone >> > without significant manual workarounds, due to insufficient >> > disk space on /boot. >> >> How much disk space will one require on /boot to perform the update >> without work arounds ? > > From the ticket (see URL above). > > Here's the details. > The default /boot partition is 200MB, but there's some overhead: > Ext3/Ext4 overhead: 7MB > Reserved space: 10MB > F11 kernel: 8MB (at least - usually 3 kernels = 24MB) > GRUB/EFI files: 1MB > Total overhead: 26MB > > So there's 174MB of usable space maximum, and usually 158MB > available. > > preupgrade now requires at least 167MB free space on /boot: > F12 installer images: 143MB (8mb larger than F11!) > F12 kernel: 18MB (10mb larger than F11!) > RPM/anaconda tmpfiles: >=8MB (measured in stupid tests) > Total: 167MB (Was 149MB in F11 - no problem!) > >> Can gparted resize /boot ? > > There are definitely workarounds available, but none that meet the > criteria for preupgrade as an effortless upgrade option. > > Thanks, > James What if I have already a large /boot? From cemeyer at u.washington.edu Thu Nov 12 20:26:27 2009 From: cemeyer at u.washington.edu (Conrad Meyer) Date: Thu, 12 Nov 2009 12:26:27 -0800 Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: <1258056613.2192.65.camel@localhost.localdomain> References: <1258055802.2192.53.camel@localhost.localdomain> <1258056032.3749.5.camel@localhost.localdomain> <1258056613.2192.65.camel@localhost.localdomain> Message-ID: <200911121226.27595.cemeyer@u.washington.edu> On Thursday 12 November 2009 12:10:13 pm James Laska wrote: > *snip* > > So there's 174MB of usable space maximum, and usually 158MB > available. > > preupgrade now requires at least 167MB free space on /boot: > F12 installer images: 143MB (8mb larger than F11!) > F12 kernel: 18MB (10mb larger than F11!) > RPM/anaconda tmpfiles: >=8MB (measured in stupid tests) > Total: 167MB (Was 149MB in F11 - no problem!) Is part of the reason the F-12 kernel is so much larger that the debugging switch is still flipped on? Regards, -- Conrad Meyer From sandeen at redhat.com Thu Nov 12 20:27:35 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Thu, 12 Nov 2009 14:27:35 -0600 Subject: cpio to ext4 seems much slower than to ext2, ext3 or xfs In-Reply-To: <4AFC6C39.2040901@robertoragusa.it> References: <20091111101421.GA28964@amd.home.annexia.org> <20091111105322.GB28964@amd.home.annexia.org> <4AFAA306.9090003@lfarkas.org> <200911111233.32771.gene@czarc.net> <4AFB0F64.1010505@redhat.com> <20091111210520.GA622@amd.home.annexia.org> <20091112095412.GA2060@redhat.com> <20091112101815.GA4039@amd.home.annexia.org> <4AFC23A6.50209@redhat.com> <4AFC27C2.5010300@conversis.de> <4AFC3F0B.4080400@redhat.com> <4AFC543A.2090409@conversis.de> <4AFC6A7A.5050802@redhat.com> <4AFC6C39.2040901@robertoragusa.it> Message-ID: <4AFC6FB7.5020105@redhat.com> Roberto Ragusa wrote: > Ric Wheeler wrote: >> In our testing with f12, I build a 60TB ext4 file system with 1 billion >> small files. A forced fsck of ext4 finished in 2.5 hours give or take a >> bit :-) The fill was artificial and the file system was not aged, so >> real world results will probably be slower. >> >> fsck time scales mostly with the number of allocated files in my >> experience. Allocated blocks (fewer very large files) are quite quick. >> > > What kind of machine did you use? > > With 60TB a simple allocation bitmap for 4k-blocks takes almost 2GB; > and this is just to detect free space or double allocation of blocks. > Wow. > The box did have a lot of memory, it's true :) But ext4 also uses the "uninit_bg" feature: uninit_bg Create a filesystem without initializing all of the block groups. This feature also enables checksums and highest-inode-used statistics in each block- group. This feature can speed up filesystem cre- ation time noticeably (if lazy_itable_init is enabled), and can also reduce e2fsck time dramati- cally. It is only supported by the ext4 filesystem in recent Linux kernels. -Eric From skvidal at fedoraproject.org Thu Nov 12 20:29:58 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 12 Nov 2009 15:29:58 -0500 (EST) Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: References: <1258055802.2192.53.camel@localhost.localdomain> <1258056032.3749.5.camel@localhost.localdomain> <1258056613.2192.65.camel@localhost.localdomain> Message-ID: On Thu, 12 Nov 2009, Neal Becker wrote: > James Laska wrote: > >> On Thu, 2009-11-12 at 13:00 -0700, Linuxguy123 wrote: >>> On Thu, 2009-11-12 at 14:56 -0500, James Laska wrote: >>>> Greetings folks, >>>> >>>> After careful review by Will Woods around recently discovered problems >>>> related to preupgrading to Fedora 12, I've filed ticket#270 >>>> (https://fedorahosted.org/fesco/ticket/270) for discussion at the next >>>> FESCO meeting. Please take a moment to read the details in the ticket. >>>> >>>> The high-level summary from Will ... >>>> >>>> preupgrade to F12 is basically not going to work for anyone >>>> without significant manual workarounds, due to insufficient >>>> disk space on /boot. >>> >>> How much disk space will one require on /boot to perform the update >>> without work arounds ? >> >> From the ticket (see URL above). >> >> Here's the details. >> The default /boot partition is 200MB, but there's some overhead: >> Ext3/Ext4 overhead: 7MB >> Reserved space: 10MB >> F11 kernel: 8MB (at least - usually 3 kernels = 24MB) >> GRUB/EFI files: 1MB >> Total overhead: 26MB >> >> So there's 174MB of usable space maximum, and usually 158MB >> available. >> >> preupgrade now requires at least 167MB free space on /boot: >> F12 installer images: 143MB (8mb larger than F11!) >> F12 kernel: 18MB (10mb larger than F11!) >> RPM/anaconda tmpfiles: >=8MB (measured in stupid tests) >> Total: 167MB (Was 149MB in F11 - no problem!) >> >>> Can gparted resize /boot ? >> >> There are definitely workarounds available, but none that meet the >> criteria for preupgrade as an effortless upgrade option. >> >> Thanks, >> James > > What if I have already a large /boot? then just run preupgrade. -sv From jlaska at redhat.com Thu Nov 12 20:32:42 2009 From: jlaska at redhat.com (James Laska) Date: Thu, 12 Nov 2009 15:32:42 -0500 Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: References: <1258055802.2192.53.camel@localhost.localdomain> <1258056032.3749.5.camel@localhost.localdomain> <1258056613.2192.65.camel@localhost.localdomain> Message-ID: <1258057962.2192.91.camel@localhost.localdomain> On Thu, 2009-11-12 at 15:25 -0500, Neal Becker wrote: > James Laska wrote: > > > On Thu, 2009-11-12 at 13:00 -0700, Linuxguy123 wrote: > >> On Thu, 2009-11-12 at 14:56 -0500, James Laska wrote: > >> > Greetings folks, > >> > > >> > After careful review by Will Woods around recently discovered problems > >> > related to preupgrading to Fedora 12, I've filed ticket#270 > >> > (https://fedorahosted.org/fesco/ticket/270) for discussion at the next > >> > FESCO meeting. Please take a moment to read the details in the ticket. > >> > > >> > The high-level summary from Will ... > >> > > >> > preupgrade to F12 is basically not going to work for anyone > >> > without significant manual workarounds, due to insufficient > >> > disk space on /boot. > >> > >> How much disk space will one require on /boot to perform the update > >> without work arounds ? > > > > From the ticket (see URL above). > > > > Here's the details. > > The default /boot partition is 200MB, but there's some overhead: > > Ext3/Ext4 overhead: 7MB > > Reserved space: 10MB > > F11 kernel: 8MB (at least - usually 3 kernels = 24MB) > > GRUB/EFI files: 1MB > > Total overhead: 26MB > > > > So there's 174MB of usable space maximum, and usually 158MB > > available. > > > > preupgrade now requires at least 167MB free space on /boot: > > F12 installer images: 143MB (8mb larger than F11!) > > F12 kernel: 18MB (10mb larger than F11!) > > RPM/anaconda tmpfiles: >=8MB (measured in stupid tests) > > Total: 167MB (Was 149MB in F11 - no problem!) > > > >> Can gparted resize /boot ? > > > > There are definitely workarounds available, but none that meet the > > criteria for preupgrade as an effortless upgrade option. > > > > Thanks, > > James > > What if I have already a large /boot? As Seth points out, you are likely okay in this scenario. The concern is for users who have installed using the default partition size for '/boot'. Thanks, James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From linuxguy123 at gmail.com Thu Nov 12 20:39:02 2009 From: linuxguy123 at gmail.com (Linuxguy123) Date: Thu, 12 Nov 2009 13:39:02 -0700 Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: <1258056613.2192.65.camel@localhost.localdomain> References: <1258055802.2192.53.camel@localhost.localdomain> <1258056032.3749.5.camel@localhost.localdomain> <1258056613.2192.65.camel@localhost.localdomain> Message-ID: <1258058342.3749.18.camel@localhost.localdomain> On Thu, 2009-11-12 at 15:10 -0500, James Laska wrote: > On Thu, 2009-11-12 at 13:00 -0700, Linuxguy123 wrote: > > On Thu, 2009-11-12 at 14:56 -0500, James Laska wrote: > > > Greetings folks, > > > > > > After careful review by Will Woods around recently discovered problems > > > related to preupgrading to Fedora 12, I've filed ticket#270 > > > (https://fedorahosted.org/fesco/ticket/270) for discussion at the next > > > FESCO meeting. Please take a moment to read the details in the ticket. > > > > > > The high-level summary from Will ... > > > > > > preupgrade to F12 is basically not going to work for anyone > > > without significant manual workarounds, due to insufficient disk > > > space on /boot. > > > > How much disk space will one require on /boot to perform the update > > without work arounds ? > > From the ticket (see URL above). > > Here's the details. > The default /boot partition is 200MB, but there's some overhead: > Ext3/Ext4 overhead: 7MB > Reserved space: 10MB > F11 kernel: 8MB (at least - usually 3 kernels = 24MB) > GRUB/EFI files: 1MB > Total overhead: 26MB > > So there's 174MB of usable space maximum, and usually 158MB available. > > preupgrade now requires at least 167MB free space on /boot: > F12 installer images: 143MB (8mb larger than F11!) > F12 kernel: 18MB (10mb larger than F11!) > RPM/anaconda tmpfiles: >=8MB (measured in stupid tests) > Total: 167MB (Was 149MB in F11 - no problem!) With all my kernels removed except the current one, I have this: # df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 143G 89G 47G 66% / /dev/sda1 190M 14M 167M 8% /boot tmpfs 2.0G 88K 2.0G 1% /dev/shm /dev/sdb1 294G 242G 37G 87% /data uname -a Linux localhost.localdomain 2.6.30.9-96.fc11.i686.PAE #1 SMP Tue Nov 3 23:41:33 EST 2009 i686 i686 i386 GNU/Linux From jkeating at redhat.com Thu Nov 12 20:43:18 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 12 Nov 2009 12:43:18 -0800 Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: <200911121226.27595.cemeyer@u.washington.edu> References: <1258055802.2192.53.camel@localhost.localdomain> <1258056032.3749.5.camel@localhost.localdomain> <1258056613.2192.65.camel@localhost.localdomain> <200911121226.27595.cemeyer@u.washington.edu> Message-ID: <1258058598.2477.22.camel@localhost.localdomain> On Thu, 2009-11-12 at 12:26 -0800, Conrad Meyer wrote: > Is part of the reason the F-12 kernel is so much larger that the > debugging > switch is still flipped on? That's only true for the older F12 development kernels. The kernels since 2.6.31.5-94 have had debugging turned off. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From rwheeler at redhat.com Thu Nov 12 20:52:34 2009 From: rwheeler at redhat.com (Ric Wheeler) Date: Thu, 12 Nov 2009 15:52:34 -0500 Subject: cpio to ext4 seems much slower than to ext2, ext3 or xfs In-Reply-To: <4AFC6FB7.5020105@redhat.com> References: <20091111101421.GA28964@amd.home.annexia.org> <20091111105322.GB28964@amd.home.annexia.org> <4AFAA306.9090003@lfarkas.org> <200911111233.32771.gene@czarc.net> <4AFB0F64.1010505@redhat.com> <20091111210520.GA622@amd.home.annexia.org> <20091112095412.GA2060@redhat.com> <20091112101815.GA4039@amd.home.annexia.org> <4AFC23A6.50209@redhat.com> <4AFC27C2.5010300@conversis.de> <4AFC3F0B.4080400@redhat.com> <4AFC543A.2090409@conversis.de> <4AFC6A7A.5050802@redhat.com> <4AFC6C39.2040901@robertoragusa.it> <4AFC6FB7.5020105@redhat.com> Message-ID: <4AFC7592.3070301@redhat.com> On 11/12/2009 03:27 PM, Eric Sandeen wrote: > Roberto Ragusa wrote: >> Ric Wheeler wrote: >>> In our testing with f12, I build a 60TB ext4 file system with 1 billion >>> small files. A forced fsck of ext4 finished in 2.5 hours give or take a >>> bit :-) The fill was artificial and the file system was not aged, so >>> real world results will probably be slower. >>> >>> fsck time scales mostly with the number of allocated files in my >>> experience. Allocated blocks (fewer very large files) are quite quick. >>> >> >> What kind of machine did you use? >> >> With 60TB a simple allocation bitmap for 4k-blocks takes almost 2GB; >> and this is just to detect free space or double allocation of blocks. >> Wow. >> > > The box did have a lot of memory, it's true :) > > But ext4 also uses the "uninit_bg" feature: > > uninit_bg > Create a filesystem without initializing all of the > block groups. This feature also enables checksums > and highest-inode-used statistics in each block- > group. This feature can speed up filesystem cre- > ation time noticeably (if lazy_itable_init is > enabled), and can also reduce e2fsck time dramati- > cally. It is only supported by the ext4 filesystem > in recent Linux kernels. > > -Eric > A lot in this case was 40GB of DRAM - fsck (iirc) consumed about 13GB of virtual space during the run? Ric From cemeyer at u.washington.edu Thu Nov 12 21:11:06 2009 From: cemeyer at u.washington.edu (Conrad Meyer) Date: Thu, 12 Nov 2009 13:11:06 -0800 Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: <1258058598.2477.22.camel@localhost.localdomain> References: <1258055802.2192.53.camel@localhost.localdomain> <200911121226.27595.cemeyer@u.washington.edu> <1258058598.2477.22.camel@localhost.localdomain> Message-ID: <200911121311.06165.cemeyer@u.washington.edu> On Thursday 12 November 2009 12:43:18 pm Jesse Keating wrote: > On Thu, 2009-11-12 at 12:26 -0800, Conrad Meyer wrote: > > Is part of the reason the F-12 kernel is so much larger that the > > debugging > > switch is still flipped on? > > That's only true for the older F12 development kernels. The kernels > since 2.6.31.5-94 have had debugging turned off. Ok, that's what I was curious about. Thanks for the clarification. -- Conrad Meyer From jreiser at bitwagon.com Thu Nov 12 21:23:29 2009 From: jreiser at bitwagon.com (John Reiser) Date: Thu, 12 Nov 2009 13:23:29 -0800 Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: <200911121226.27595.cemeyer@u.washington.edu> References: <1258055802.2192.53.camel@localhost.localdomain> <1258056032.3749.5.camel@localhost.localdomain> <1258056613.2192.65.camel@localhost.localdomain> <200911121226.27595.cemeyer@u.washington.edu> Message-ID: <4AFC7CD1.2060505@bitwagon.com> >> F12 kernel: 18MB (10mb larger than F11!) > Is part of the reason the F-12 kernel is so much larger that the debugging > switch is still flipped on? F12 initrd (initramfs) is about 15.5MB (x86_64) or 11.3MB (i686). F11 initrd (initramfs) is about 3.5MB (x86_64) or 3.0MB (i686). F12 initramfs has *all* the drivers; F11 has a subset. -- From ville.skytta at iki.fi Thu Nov 12 21:30:27 2009 From: ville.skytta at iki.fi (Ville =?windows-1252?q?Skytt=E4?=) Date: Thu, 12 Nov 2009 23:30:27 +0200 Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: <1258058598.2477.22.camel@localhost.localdomain> References: <1258055802.2192.53.camel@localhost.localdomain> <200911121226.27595.cemeyer@u.washington.edu> <1258058598.2477.22.camel@localhost.localdomain> Message-ID: <200911122330.27684.ville.skytta@iki.fi> On Thursday 12 November 2009, Jesse Keating wrote: > On Thu, 2009-11-12 at 12:26 -0800, Conrad Meyer wrote: > > Is part of the reason the F-12 kernel is so much larger that the > > debugging > > switch is still flipped on? > > That's only true for the older F12 development kernels. The kernels > since 2.6.31.5-94 have had debugging turned off. Are the newer non-debug ones still 10MB larger than the F-11 ones (more than twice the size)? If yes, why is that? Just wondering. From jkeating at redhat.com Thu Nov 12 21:45:37 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 12 Nov 2009 13:45:37 -0800 Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: <200911122330.27684.ville.skytta@iki.fi> References: <1258055802.2192.53.camel@localhost.localdomain> <200911121226.27595.cemeyer@u.washington.edu> <1258058598.2477.22.camel@localhost.localdomain> <200911122330.27684.ville.skytta@iki.fi> Message-ID: <1258062337.2477.23.camel@localhost.localdomain> On Thu, 2009-11-12 at 23:30 +0200, Ville Skytt? wrote: > Are the newer non-debug ones still 10MB larger than the F-11 ones > (more than > twice the size)? If yes, why is that? Just wondering. > > They are larger, due to using dracut to make the initrds rather than mkinitrd. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Thu Nov 12 21:47:23 2009 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 12 Nov 2009 22:47:23 +0100 Subject: Identifying remaining core font users In-Reply-To: <1257941463.841.37.camel@arekh.okg> References: <1257941463.841.37.camel@arekh.okg> Message-ID: <20091112214723.GA3841@free.fr> On Wed, Nov 11, 2009 at 01:11:03PM +0100, Nicolas Mailhot wrote: > Hi, > > > ? cernlib cernlib-0:2006-34.fc12 > ? /usr/lib64/cernlib/2006/lib/libgrafX11.so.1_gfortran.2006 > ? /usr/lib64/cernlib/2006/lib/libpacklib-lesstif.so.1_gfortran.2006 > ? /usr/lib64/cernlib/2006/lib/libpawlib-lesstif.so.3_gfortran.2006 > ? cernlib cernlib-packlib-gfortran-0:2006-34.fc12 > ? /usr/bin/kxterm-gfortran > ? cernlib paw-gfortran-0:2006-34.fc12 > ? /usr/bin/paw++-gfortran > ? /usr/bin/pawX11-gfortran > ? cernlib-g77 cernlib-g77-0:2006-33.fc12 > ? /usr/lib64/cernlib/2006-g77/lib/libgrafX11.so.1.2006 > ? /usr/lib64/cernlib/2006-g77/lib/libpacklib-lesstif.so.1.2006 > ? /usr/lib64/cernlib/2006-g77/lib/libpawlib-lesstif.so.3.2006 > ? cernlib-g77 cernlib-packlib-0:2006-33.fc12 > ? /usr/bin/kxterm > ? cernlib-g77 cernlib-packlib-g77-0:2006-33.fc12 > ? /usr/bin/kxterm-g77 > ? cernlib-g77 paw-0:2006-33.fc12 > ? /usr/bin/paw++ > ? /usr/bin/pawX11 > ? cernlib-g77 paw-g77-0:2006-33.fc12 > ? /usr/bin/paw++-g77 > ? /usr/bin/pawX11-g77 Cernlib is already legacy, so it wouldn't be so bad that the graphical stuff in cernlib doesn't work. Also it is not clear that it uses that much directly X, but rather goes through Motif. Maybe Xm* symbols should not be taken into account? > ? wmctrl wmctrl-0:1.07-7.fc12 > ? /usr/bin/wmctrl This is a use of XCreateFontCursor. Is it really in the scope? Another remark is that some of the problematic applications are Xaw or lesstif apps. Is it really an issue in that case that they use X legacy fonts stuff? -- Pat From cmadams at hiwaay.net Thu Nov 12 21:51:15 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 12 Nov 2009 15:51:15 -0600 Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: <1258058342.3749.18.camel@localhost.localdomain> References: <1258055802.2192.53.camel@localhost.localdomain> <1258056032.3749.5.camel@localhost.localdomain> <1258056613.2192.65.camel@localhost.localdomain> <1258058342.3749.18.camel@localhost.localdomain> Message-ID: <20091112215115.GE1570327@hiwaay.net> Once upon a time, Linuxguy123 said: > On Thu, 2009-11-12 at 15:10 -0500, James Laska wrote: > > preupgrade now requires at least 167MB free space on /boot: > > F12 installer images: 143MB (8mb larger than F11!) > > F12 kernel: 18MB (10mb larger than F11!) > > RPM/anaconda tmpfiles: >=8MB (measured in stupid tests) > > Total: 167MB (Was 149MB in F11 - no problem!) > > With all my kernels removed except the current one, I have this: > > # df -h > Filesystem Size Used Avail Use% Mounted on > /dev/sda1 190M 14M 167M 8% /boot I just removed all but the running kernel (on a system that was a fresh install of F11) and got a similar result: # rpm -e $(rpm -qf /boot/vmlinuz* | grep -v "kernel-$(uname -r)") # df -h /boot Filesystem Size Used Avail Use% Mounted on /dev/md0 194M 15M 169M 9% /boot That's right at the edge, and could push untested corner cases in anaconda with respect to temp files and such. I don't think increasing /boot just because of preupgrade is a viable solution, as the installer image continues to grow. Is it possible instead to put the installer image (the real problem) somewhere else, like /? Why does it need to be in /boot? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From wwoods at redhat.com Thu Nov 12 22:00:31 2009 From: wwoods at redhat.com (Will Woods) Date: Thu, 12 Nov 2009 17:00:31 -0500 (EST) Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: <20091112215115.GE1570327@hiwaay.net> Message-ID: <601364355.428671258063231802.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- "Chris Adams" wrote: > I don't think increasing /boot just because of preupgrade is a viable > solution, as the installer image continues to grow. Is it possible > instead to put the installer image (the real problem) somewhere else, > like /? Why does it need to be in /boot? Because anaconda's stage1 (initrd) doesn't know how to assemble LVM/mdraid/dmraid/whatever crazy thing your root partition is on. So install.img needs to be on something that stage1 can read. Conveniently, GRUB also requires a non-LVM partition - /boot! So that's the only place we can reliably put it. -w From cmadams at hiwaay.net Thu Nov 12 22:04:12 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 12 Nov 2009 16:04:12 -0600 Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: <601364355.428671258063231802.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <20091112215115.GE1570327@hiwaay.net> <601364355.428671258063231802.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <20091112220412.GF1570327@hiwaay.net> Once upon a time, Will Woods said: > ----- "Chris Adams" wrote: > > I don't think increasing /boot just because of preupgrade is a viable > > solution, as the installer image continues to grow. Is it possible > > instead to put the installer image (the real problem) somewhere else, > > like /? Why does it need to be in /boot? > > Because anaconda's stage1 (initrd) doesn't know how to assemble > LVM/mdraid/dmraid/whatever crazy thing your root partition is on. > So install.img needs to be on something that stage1 can read. How about using dracut for anaconda's initrd as well? Obviously, not for F12, but maybe for F13? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From abo at root.snowtree.se Thu Nov 12 22:12:54 2009 From: abo at root.snowtree.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Thu, 12 Nov 2009 23:12:54 +0100 Subject: Conservative preupgrade In-Reply-To: <15e53e180911121202t4c101f7eofa7d607f668db0be@mail.gmail.com> References: <1258055802.2192.53.camel@localhost.localdomain> <15e53e180911121202t4c101f7eofa7d607f668db0be@mail.gmail.com> Message-ID: <1258063974.3737.17.camel@tempo.alexander.bostrom.net> tor 2009-11-12 klockan 20:02 +0000 skrev Richard Hughes: > Tomorrow I'll push a F11 update disabling the preupgrade > functionality. This will give us enough time to fix things, and then > we can "flip the switch" with another PK update in a few weeks that > re-enables the upgrade functionality. There is the option of a "conservative" preupgrade integration. By that I mean that PK would suggest an upgrade only when the currently installed release has reached end of life and it would then suggest an upgrade to the next release rather than the latest release (which would probably be +2 from what's currently running.) The advantages and disadvantages to the Fedora users and the Fedora project are obvious... /abo From nicolas.mailhot at laposte.net Thu Nov 12 22:38:26 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 12 Nov 2009 23:38:26 +0100 Subject: Identifying remaining core font users In-Reply-To: <20091112214723.GA3841@free.fr> References: <1257941463.841.37.camel@arekh.okg> <20091112214723.GA3841@free.fr> Message-ID: <1258065506.7664.9.camel@arekh.okg> Le jeudi 12 novembre 2009 ? 22:47 +0100, Patrice Dumas a ?crit : Hi, > Cernlib is already legacy, so it wouldn't be so bad that the graphical > stuff in cernlib doesn't work. Also it is not clear that it uses that > much directly X, but rather goes through Motif. Maybe Xm* symbols > should not be taken into account? Going through Motif or another widget lib does not change the problem. Apps will be affected the same whether they access Core fonts directly or through a proxy. In fact the next step is probably to identify such indirect users (the current check caught Motif apps, but gtk1 have the same problem). Deciding if the app has a future of if it's ok it fails is a judgment call I refuse to hardwire in the checker. Packagers will receive notifications and decide what they do with them alone. (however that *also* means someone who decided to keep a core client in Fedora after being notified of the risks gets to explain the breakage if some user complains it works less and less well) > > ? wmctrl wmctrl-0:1.07-7.fc12 > > ? /usr/bin/wmctrl > > This is a use of XCreateFontCursor. Is it really in the scope? Yes, this was already on the list of things not to warn about. Sorry about not posting about it. I wanted to do a full repo check before reporting again, but due to the number of packages checked it takes a long time (hours) to run and I have to rewind every time I find a bug in the script. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pertusus at free.fr Thu Nov 12 22:08:23 2009 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 12 Nov 2009 23:08:23 +0100 Subject: Identifying remaining core font users In-Reply-To: <1257941463.841.37.camel@arekh.okg> References: <1257941463.841.37.camel@arekh.okg> Message-ID: <20091112220823.GB3841@free.fr> On Wed, Nov 11, 2009 at 01:11:03PM +0100, Nicolas Mailhot wrote: > Hi, > > encoding standards change. Also, few users means we do not install core > font packages by default anymore, so packagers that depend on them but > forgot to mark the deps in their packages will deliver broken packages > to users. On that matter, what is the way to know which packagee is necessary for fonts like *-courier-medium-r-normal-*-120-* *-helvetica-medium-r-normal-*-120-* Is there an easy way to know in which package they are? (If I recall well, fixed is now built-in the X server). -- Pat From jkeating at redhat.com Thu Nov 12 22:52:28 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 12 Nov 2009 14:52:28 -0800 Subject: Fedora 12 staged for mirrors, rawhide moving on soon Message-ID: <1258066348.2477.44.camel@localhost.localdomain> I have just staged Fedora 12 for our mirrors. We're doing something a little different this time around. The releases/12/Everything/ tree will be open to the public as it gets staged. This will allow us to give people who have "Fedora 12" installed now access to the "fedora" repo. We will then be able to move rawhide along to Fedora 13. The Fedora/ and Live/ trees will remain locked until our release date. On this Saturday or Sunday rawhide will have Fedora 13 content. Users of rawhide right now do not need to do anything to keep on Fedora 12. Unless you have modified your /etc/yum.repos.d/ files, you will stay on Fedora 12 as we transition. Those of you that wish to move along to Fedora 13 rawhide will need to modify your fedora-rawhide.repo file and keep it enabled, while disabling fedora and fedora-updates repos. Thanks again to all of you who have helped make Fedora 12 the great release it is about to be! -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From pertusus at free.fr Thu Nov 12 23:59:29 2009 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 13 Nov 2009 00:59:29 +0100 Subject: Identifying remaining core font users In-Reply-To: <1258065506.7664.9.camel@arekh.okg> References: <1257941463.841.37.camel@arekh.okg> <20091112214723.GA3841@free.fr> <1258065506.7664.9.camel@arekh.okg> Message-ID: <20091112235929.GA14605@free.fr> On Thu, Nov 12, 2009 at 11:38:26PM +0100, Nicolas Mailhot wrote: > Le jeudi 12 novembre 2009 ? 22:47 +0100, Patrice Dumas a ?crit : > > Going through Motif or another widget lib does not change the problem. > Apps will be affected the same whether they access Core fonts directly > or through a proxy. That was not exactly my point. Part of what I said was that maybe Motif functions like XmFontListAdd... should not be taken into account, since Motif per se is not tied to legacy X fonts, and indeed lesstif can use xft. The second part of what I wanted to say is that maybe it is not really useful to bother apps using legacy Fonts because they use a given widget library that mandates the use of such fonts (I don't think Motif falls in this category, though). -- Pat From hpa at zytor.com Fri Nov 13 00:09:55 2009 From: hpa at zytor.com (H. Peter Anvin) Date: Thu, 12 Nov 2009 16:09:55 -0800 Subject: Fedora 12 staged for mirrors, rawhide moving on soon In-Reply-To: <1258066348.2477.44.camel@localhost.localdomain> References: <1258066348.2477.44.camel@localhost.localdomain> Message-ID: <4AFCA3D3.80005@zytor.com> On 11/12/2009 02:52 PM, Jesse Keating wrote: > I have just staged Fedora 12 for our mirrors. We're doing something a > little different this time around. The releases/12/Everything/ tree > will be open to the public as it gets staged. For heaven's sake, no! Don't you realize this means a ton of *users* will start to bog down the mirrors before the whole data set has propagated through the network? -hpa _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From lfarkas at lfarkas.org Thu Nov 12 23:35:22 2009 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 13 Nov 2009 00:35:22 +0100 Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: <1258062337.2477.23.camel@localhost.localdomain> References: <1258055802.2192.53.camel@localhost.localdomain> <200911121226.27595.cemeyer@u.washington.edu> <1258058598.2477.22.camel@localhost.localdomain> <200911122330.27684.ville.skytta@iki.fi> <1258062337.2477.23.camel@localhost.localdomain> Message-ID: <4AFC9BBA.2080603@lfarkas.org> On 11/12/2009 10:45 PM, Jesse Keating wrote: > On Thu, 2009-11-12 at 23:30 +0200, Ville Skytt? wrote: >> Are the newer non-debug ones still 10MB larger than the F-11 ones >> (more than >> twice the size)? If yes, why is that? Just wondering. >> >> > > They are larger, due to using dracut to make the initrds rather than > mkinitrd. and do you still think it was worth to switch to dracut from mkinitrd? it's 4-5 times larger! this kind of reason smells comes from microsoft:-( -- Levente "Si vis pacem para bellum!" From ndbecker2 at gmail.com Fri Nov 13 00:38:21 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 12 Nov 2009 19:38:21 -0500 Subject: texlive2009 f11 broken by today's update Message-ID: Was working, but after today's update: pdflatex pll_freq_ramp.tex This is pdfTeX, Version 3.1415926-1.40.10 (Web2C 2009) kpathsea: Running mktexfmt pdflatex.fmt I can't find the format file `pdflatex.fmt'! From jwboyer at gmail.com Fri Nov 13 01:09:34 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 12 Nov 2009 20:09:34 -0500 Subject: Fedora 12 staged for mirrors, rawhide moving on soon In-Reply-To: <4AFCA3D3.80005@zytor.com> References: <1258066348.2477.44.camel@localhost.localdomain> <4AFCA3D3.80005@zytor.com> Message-ID: <20091113010933.GG5699@hansolo.jdub.homelinux.org> On Thu, Nov 12, 2009 at 04:09:55PM -0800, H. Peter Anvin wrote: >On 11/12/2009 02:52 PM, Jesse Keating wrote: >> I have just staged Fedora 12 for our mirrors. We're doing something a >> little different this time around. The releases/12/Everything/ tree >> will be open to the public as it gets staged. > >For heaven's sake, no! > >Don't you realize this means a ton of *users* will start to bog down the >mirrors before the whole data set has propagated through the network? To do what? The Everything trees don't contain bootable media. They are just package repositories. The users on rawhide-f12 installs will hit that if they want to install packages, but that is no more load than them just hitting rawhide for packages. It's certainly possible that users will rsync the Everything tree, but they won't be able to do much with it. Is that the usecase you're worried about? josh From jonstanley at gmail.com Fri Nov 13 01:36:32 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 12 Nov 2009 20:36:32 -0500 Subject: Plan for tomorrow's (20091113) FESCo meeting Message-ID: The following topics are currently on the agenda for tomorrow's FESCo meeting, taking place at 17:00UTC (that's noon Eastern) in #fedora-meeting on irc.freenode.net 263 Sponsorship request: hubbitus 268 Proven packager request - Daniel Drake 269 Request to approve me a sponsor for package maintainers 270 FESCO topic proposal - preupgrade and F-12 41 SystemTap Static Probes - https://fedoraproject.org/wiki/Features/SystemtapStaticProbes 260 SIP Witch Domain Telephony - https://fedoraproject.org/wiki/Features/SIP_Witch_Domain_Telephony 271 Automatic Print Driver installation - https://fedoraproject.org/wiki/Features/AutomaticPrintDriverInstallation 272 Intellij IDEA - https://fedoraproject.org/wiki/Features/IntelliJ_IDEA 273 Python 3 F13 - https://fedoraproject.org/wiki/Features/Python3F13 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor. From a.badger at gmail.com Fri Nov 13 01:14:20 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 12 Nov 2009 17:14:20 -0800 Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: <1258055802.2192.53.camel@localhost.localdomain> References: <1258055802.2192.53.camel@localhost.localdomain> Message-ID: <20091113011420.GL25960@clingman.lan> On Thu, Nov 12, 2009 at 02:56:42PM -0500, James Laska wrote: > Greetings folks, > > After careful review by Will Woods around recently discovered problems > related to preupgrading to Fedora 12, I've filed ticket#270 > (https://fedorahosted.org/fesco/ticket/270) for discussion at the next > FESCO meeting. Please take a moment to read the details in the ticket. > > The high-level summary from Will ... > > preupgrade to F12 is basically not going to work for anyone > without significant manual workarounds, due to insufficient disk > space on /boot. I think we may need to talk to hughsie and/or > the desktop team about removing the preupgrade integration in > PackageKit for F10/F11 and how to do preupgrade right for F13 > and higher. > > Most of the folks impacted by this proposal are already informed. > However, as per the FESCO meeting guidelines [1], I'm sending this to > fedora-devel-list for wider discussion. > From the ticket and my experiences (I preupgraded a machine with a 100MB /boot last night with no problems) this seems like an exageration. Could you please explain "not going to work for anyone without significant manual workarounds"? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jonstanley at gmail.com Fri Nov 13 02:04:27 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 12 Nov 2009 21:04:27 -0500 Subject: Plan for tomorrow's (20091113) FESCo meeting In-Reply-To: References: Message-ID: On Thu, Nov 12, 2009 at 8:36 PM, Jon Stanley wrote: > 269 ? ? Request to approve me a sponsor for package maintainers Apologies, this is a bad title for a ticket that I normally catch and correct. The "me" in this instance refers to Rahul Sundaram. From kevin.kofler at chello.at Fri Nov 13 03:00:06 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 13 Nov 2009 04:00:06 +0100 Subject: Identifying remaining core font users References: <1257941463.841.37.camel@arekh.okg> <20091112214723.GA3841@free.fr> <1258065506.7664.9.camel@arekh.okg> <20091112235929.GA14605@free.fr> Message-ID: Patrice Dumas wrote: > The second part of what I wanted to say is that maybe it is not > really useful to bother apps using legacy Fonts because they use > a given widget library that mandates the use of such fonts Then they need to be ported to a modern toolkit (by upstream). E.g. Xaw has long stopped being viable. (In fact it was never supposed to be more than an example.) If there is no upstream, then maybe it's time to retire the package? Or pick up upstream maintenance if there's really no modern alternative? Kevin Kofler From sundaram at fedoraproject.org Fri Nov 13 03:03:32 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 13 Nov 2009 08:33:32 +0530 Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: <4AFC9BBA.2080603@lfarkas.org> References: <1258055802.2192.53.camel@localhost.localdomain> <200911121226.27595.cemeyer@u.washington.edu> <1258058598.2477.22.camel@localhost.localdomain> <200911122330.27684.ville.skytta@iki.fi> <1258062337.2477.23.camel@localhost.localdomain> <4AFC9BBA.2080603@lfarkas.org> Message-ID: <4AFCCC84.4070404@fedoraproject.org> On 11/13/2009 05:05 AM, Farkas Levente wrote: > On 11/12/2009 10:45 PM, Jesse Keating wrote: >> On Thu, 2009-11-12 at 23:30 +0200, Ville Skytt? wrote: >>> Are the newer non-debug ones still 10MB larger than the F-11 ones >>> (more than >>> twice the size)? If yes, why is that? Just wondering. >>> >>> >> >> They are larger, due to using dracut to make the initrds rather than >> mkinitrd. > > and do you still think it was worth to switch to dracut from mkinitrd? > it's 4-5 times larger! this kind of reason smells comes from microsoft:-( Dracut produces a generic initrd by default instead of something system specific. If you want to reduce that, go to /etc/dracut.conf and enable the hostonly option. Rahul From roland at redhat.com Fri Nov 13 03:20:42 2009 From: roland at redhat.com (Roland McGrath) Date: Thu, 12 Nov 2009 19:20:42 -0800 (PST) Subject: Fedora 12 staged for mirrors, rawhide moving on soon In-Reply-To: Josh Boyer's message of Thursday, 12 November 2009 20:09:34 -0500 <20091113010933.GG5699@hansolo.jdub.homelinux.org> References: <1258066348.2477.44.camel@localhost.localdomain> <4AFCA3D3.80005@zytor.com> <20091113010933.GG5699@hansolo.jdub.homelinux.org> Message-ID: <20091113032042.9F229505@magilla.sf.frob.com> > It's certainly possible that users will rsync the Everything tree, but they > won't be able to do much with it. Is that the usecase you're worried about? I just rsync'd it from my mirror of choice (kernel.org) and was very glad to get it releases/12/Everything quickly populated with hard links to the development/ files I already had locally. Now whenever I next rsync after the development/ tree cuts over, I won't wind up downloading copies of all the *.fc12.*.rpm in one place and deleting them in the other. In past releases I've had to either let that happen (and hope my ISP doesn't call me an "abuser" for downloading so much so fast), or do some careful manual cp -rl magic to stage local copies for rsync to find. This is a drastic improvement for me--and for my use of my chosen mirror's bandwidth. Thanks, Roland From cmadams at hiwaay.net Fri Nov 13 03:25:05 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 12 Nov 2009 21:25:05 -0600 Subject: Identifying remaining core font users In-Reply-To: References: <1257941463.841.37.camel@arekh.okg> <20091112214723.GA3841@free.fr> <1258065506.7664.9.camel@arekh.okg> <20091112235929.GA14605@free.fr> Message-ID: <20091113032505.GA1165063@hiwaay.net> Once upon a time, Kevin Kofler said: > Then they need to be ported to a modern toolkit (by upstream). E.g. Xaw has > long stopped being viable. (In fact it was never supposed to be more than an > example.) If there is no upstream, then maybe it's time to retire the > package? Or pick up upstream maintenance if there's really no modern > alternative? Why is there a rush to throw out working software? I use xterm as my standard terminal program, because it is lighter-weight and for a long time "felt" faster than anything else. My father uses it because he still has software that uses the Tek4014 emulation that AFAIK nothing else supports. xterm still uses Xaw, although it does support fontconfig (still has core font support as a fall-back). Xaw and core fonts are not something new programs should use, but they still work. Are they really a significant maintenance issue? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From kevin.kofler at chello.at Fri Nov 13 03:03:01 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 13 Nov 2009 04:03:01 +0100 Subject: abrt / kernel oops issue References: <4AFC466F.2060201@gnat.ca> Message-ID: Nathanael D. Noblet wrote: > Unless Virtualbox is closed source but I didn't think it was. VirtualBox is proprietary. VirtualBox OSE (Open Source Edition) is Free Software. RPM Fusion (Free section) ships the latter. Upstream packages only the former, they only distribute the OSE in source form. Kevin Kofler From a.badger at gmail.com Fri Nov 13 04:04:08 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 12 Nov 2009 20:04:08 -0800 Subject: FESCO ticket#270 - preupgrade and F-12 Message-ID: <20091113040408.GM25960@clingman.lan> Sorry for breaking thread: > There are definitely workarounds available, but none that meet the > criteria for preupgrade as an effortless upgrade option. So I'm a bit confused by what is so hard here. preupgrade starts up, finds it can't store stage2, and then tells you that you'll need to have a wired connection to the internet if you want to use it. So you have to download stage2 when you reboot and you have to cart your laptop over to the router to plug it in while it does so... it's not like I'm going to be using it for work while anaconda is running.... I mean, in order to achieve the same thing without preupgrade, I'd have to get on IRC, ask skvidal for a script to dep solve against F12 and download the packages. Then I'd need to remember where the stage1 initird and kernel live in the download tree, grab them, and drop them in /boot. Then I'd need to modify grub.conf to add an entry for them. And I either have to figure out the magic kernel commandline options to specify where everything lives at or I have to figure out where everything belongs in a repository I build somewhere locally. Ugh. That's a lot of steps and a lot of memorizing that preupgrade encodes for me. The fact that stage2 needs to be (automatically) downloaded after I reboot is a truly trivial thing here. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From notting at redhat.com Fri Nov 13 04:27:28 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 12 Nov 2009 23:27:28 -0500 Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: <20091113040408.GM25960@clingman.lan> References: <20091113040408.GM25960@clingman.lan> Message-ID: <20091113042728.GB3828@nostromo.devel.redhat.com> Toshio Kuratomi (a.badger at gmail.com) said: > > There are definitely workarounds available, but none that meet the > > criteria for preupgrade as an effortless upgrade option. > > So I'm a bit confused by what is so hard here. preupgrade starts up, > finds it can't store stage2, and then tells you that you'll need to have a > wired connection to the internet if you want to use it. So you have to > download stage2 when you reboot and you have to cart your laptop over to the > router to plug it in while it does so... it's not like I'm going to be using > it for work while anaconda is running.... Basically, the case where it fails is when there's enough space to download stage2, but not enough space left after downloading stage2 to do the upgrade. Bill From jkeating at redhat.com Fri Nov 13 04:52:16 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 12 Nov 2009 20:52:16 -0800 Subject: Fedora 12 staged for mirrors, rawhide moving on soon In-Reply-To: <4AFCA3D3.80005@zytor.com> References: <1258066348.2477.44.camel@localhost.localdomain> <4AFCA3D3.80005@zytor.com> Message-ID: <1258087936.15679.2.camel@localhost.localdomain> On Thu, 2009-11-12 at 16:09 -0800, H. Peter Anvin wrote: > For heaven's sake, no! > > Don't you realize this means a ton of *users* will start to bog down the > mirrors before the whole data set has propagated through the network? I'm not sure what you're expecting, but users will only be able to get to the Everything tree, which is nearly 100% hardlinks into the development/ tree. There are no isos, no install images, nothing but rpms and repodata. They will not be able to get to the isos which are behind locked dirs. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Fri Nov 13 04:52:48 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 12 Nov 2009 20:52:48 -0800 Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: <20091113042728.GB3828@nostromo.devel.redhat.com> References: <20091113040408.GM25960@clingman.lan> <20091113042728.GB3828@nostromo.devel.redhat.com> Message-ID: <20091113045248.GN25960@clingman.lan> On Thu, Nov 12, 2009 at 11:27:28PM -0500, Bill Nottingham wrote: > Toshio Kuratomi (a.badger at gmail.com) said: > > > There are definitely workarounds available, but none that meet the > > > criteria for preupgrade as an effortless upgrade option. > > > > So I'm a bit confused by what is so hard here. preupgrade starts up, > > finds it can't store stage2, and then tells you that you'll need to have a > > wired connection to the internet if you want to use it. So you have to > > download stage2 when you reboot and you have to cart your laptop over to the > > router to plug it in while it does so... it's not like I'm going to be using > > it for work while anaconda is running.... > > Basically, the case where it fails is when there's enough space to download > stage2, but not enough space left after downloading stage2 to do the > upgrade. > What happens then? Grub can't copy files over to the /boot partition? Doesn't this just mean that preupgrade's estmate of how much space it needs is too small? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jamatos at fc.up.pt Fri Nov 13 08:04:20 2009 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Fri, 13 Nov 2009 08:04:20 +0000 Subject: texlive2009 f11 broken by today's update In-Reply-To: References: Message-ID: <200911130804.20821.jamatos@fc.up.pt> On Friday 13 November 2009 00:38:21 Neal Becker wrote: > Was working, but after today's update: > pdflatex pll_freq_ramp.tex > This is pdfTeX, Version 3.1415926-1.40.10 (Web2C 2009) > > kpathsea: Running mktexfmt pdflatex.fmt > I can't find the format file `pdflatex.fmt'! I have been testing this on F-12 and sometimes update break with this same error. The latest updates are working here. The symptom is that running fmtutil-sys --all as root returns nothing. I have still determine what causes this, and since the last update is working I don't have an incentive to continue searching. :-) -- Jos? Ab?lio From nicolas.mailhot at laposte.net Fri Nov 13 08:21:00 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 13 Nov 2009 09:21:00 +0100 Subject: Identifying remaining core font users In-Reply-To: <20091113032505.GA1165063@hiwaay.net> References: <1257941463.841.37.camel@arekh.okg> <20091112214723.GA3841@free.fr> <1258065506.7664.9.camel@arekh.okg> <20091112235929.GA14605@free.fr> <20091113032505.GA1165063@hiwaay.net> Message-ID: <1258100460.29924.6.camel@arekh.okg> Le jeudi 12 novembre 2009 ? 21:25 -0600, Chris Adams a ?crit : > Xaw and core fonts are not something new programs should use, but they > still work. Are they really a significant maintenance issue? Core fonts are an issue for anyone working on X or Linux fonts. You may think this year's big X11 news was driver changes or render magic, but for many people it was that emacs finally released an official stable version that didn't use them (even though they kept the old path as fallback, probably because they don't trust 100% their new code) Every single legacy xorg font package fails validation, because many fonts of this era have incomplete metadata (you could cheat and put the info manually in fonts.dir and no one was the wiser, except people who ran mkfontdir and got garbage indexes as output). I doubt we'll find people willing to fix them. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Fri Nov 13 08:24:06 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 13 Nov 2009 09:24:06 +0100 Subject: Identifying remaining core font users In-Reply-To: <20091112220823.GB3841@free.fr> References: <1257941463.841.37.camel@arekh.okg> <20091112220823.GB3841@free.fr> Message-ID: <1258100646.29924.9.camel@arekh.okg> Le jeudi 12 novembre 2009 ? 23:08 +0100, Patrice Dumas a ?crit : > On Wed, Nov 11, 2009 at 01:11:03PM +0100, Nicolas Mailhot wrote: > > Hi, > > > > encoding standards change. Also, few users means we do not install core > > font packages by default anymore, so packagers that depend on them but > > forgot to mark the deps in their packages will deliver broken packages > > to users. > > On that matter, what is the way to know which packagee is necessary > for fonts like > *-courier-medium-r-normal-*-120-* > *-helvetica-medium-r-normal-*-120-* > > Is there an easy way to know in which package they are? I don't think you can short of uncompressing each font package and reading the indexes (ignoring built-ins). As I wrote no one has been willing to expend energy on the core fonts backend for a long, long time. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From oget.fedora at gmail.com Fri Nov 13 08:37:39 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Fri, 13 Nov 2009 03:37:39 -0500 Subject: libsndfile status? In-Reply-To: References: <20091103104851.571a717f@faldor.intranet> Message-ID: On Tue, Nov 3, 2009 at 12:47 PM, Orcan Ogetbil wrote: > On Tue, Nov 3, 2009 at 4:48 AM, Michael Schwendt wrote: >> https://admin.fedoraproject.org/pkgdb/packages/bugs/libsndfile >> >> What's up with libsndfile in Fedora and EPEL? >> There are open tickets about CVEs filed in March. >> There are additional tickets without any reply. >> > > Yeah, things go a little slow with libsndfile. Because of the old > version we have in < Fedora 12 we also are not able to update some of > our audio packages. > I requested for comaintainership to fix the bugs filed to Fedora. > > Orcan > We can't reach the maintainer. We tried it in various ways at various times, e.g. [1]. I even offered help but got nothing... Shall I fix the bugs and update the package with my "proven" powers? I don't like to do substantial changes on other people's packages. But this one has a security bug that is open for 8 months... Also a few users asked me to update ardour but I can't do it without updating libsndfile. What shall we do? Orcan [1] https://bugzilla.redhat.com/show_bug.cgi?id=527109 [2] https://bugzilla.redhat.com/show_bug.cgi?id=488362 From ndbecker2 at gmail.com Fri Nov 13 08:47:47 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 13 Nov 2009 03:47:47 -0500 Subject: texlive2009 f11 broken by today's update References: <200911130804.20821.jamatos@fc.up.pt> Message-ID: Jos? Matos wrote: > On Friday 13 November 2009 00:38:21 Neal Becker wrote: >> Was working, but after today's update: >> pdflatex pll_freq_ramp.tex >> This is pdfTeX, Version 3.1415926-1.40.10 (Web2C 2009) >> >> kpathsea: Running mktexfmt pdflatex.fmt >> I can't find the format file `pdflatex.fmt'! > > I have been testing this on F-12 and sometimes update break with this same > error. The latest updates are working here. > > The symptom is that running fmtutil-sys --all as root returns nothing. > > I have still determine what causes this, and since the last update is > working I don't have an incentive to continue searching. :-) Very strange, I'm testing on 2 machines, both very similar. This happened on one, but not the other. I ran yum reinstall texlive*, and it's fixed. From schwab at redhat.com Fri Nov 13 08:55:44 2009 From: schwab at redhat.com (Andreas Schwab) Date: Fri, 13 Nov 2009 09:55:44 +0100 Subject: Identifying remaining core font users In-Reply-To: <1258054776.12961.17.camel@arekh.okg> (Nicolas Mailhot's message of "Thu, 12 Nov 2009 20:39:36 +0100") References: <1257941463.841.37.camel@arekh.okg> <1258054776.12961.17.camel@arekh.okg> Message-ID: Nicolas Mailhot writes: > Le jeudi 12 novembre 2009 ? 14:59 +0100, Andreas Schwab a ?crit : >> Nicolas Mailhot writes: >> >> > Therefore, I'd like to identify remaining core font users, and remind >> > them periodically their core font use is not good for their users or for >> > Fedora. >> >> What's wrong with proving support for core fonts as a fallback? That's >> what Emacs is doing, for example. > > The problem here is your fallback is going to be less robust than your > primary path. Also it is not needed at all. Every single major GUI app > uses the "new" (in 2003 sense of new) font backend, so if it fails > you're not going to fallback individual apps you're going to switch to > the console to fix the system. I don't understand. Emacs uses the fallback for example to display characters from the Korean KSC charset, in my case using -daewoo-minco-medium-*-ksc5601.1987-0 fonts. What's the "approved" way to do that? Andreas. -- Andreas Schwab, schwab at redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." From nicolas.mailhot at laposte.net Fri Nov 13 09:45:50 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 13 Nov 2009 10:45:50 +0100 Subject: Identifying remaining core font users In-Reply-To: References: <1257941463.841.37.camel@arekh.okg> <1258054776.12961.17.camel@arekh.okg> Message-ID: <1258105550.30766.3.camel@arekh.okg> Le vendredi 13 novembre 2009 ? 09:55 +0100, Andreas Schwab a ?crit : > I don't understand. Emacs uses the fallback for example to display > characters from the Korean KSC charset, in my case using > -daewoo-minco-medium-*-ksc5601.1987-0 fonts. What's the "approved" way > to do that? You do it like everyone else. You pass the codepoints to fontconfig (possibly, after unicode conversion) and let it find Korean fonts available in the distro (there are many, and daewoo minco medium would appear in the list if it was packaged properly). How do you think Firefox displays Korean pages ? It does not use core fonts. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From schwab at redhat.com Fri Nov 13 09:55:18 2009 From: schwab at redhat.com (Andreas Schwab) Date: Fri, 13 Nov 2009 10:55:18 +0100 Subject: Identifying remaining core font users In-Reply-To: <1258105550.30766.3.camel@arekh.okg> (Nicolas Mailhot's message of "Fri, 13 Nov 2009 10:45:50 +0100") References: <1257941463.841.37.camel@arekh.okg> <1258054776.12961.17.camel@arekh.okg> <1258105550.30766.3.camel@arekh.okg> Message-ID: Nicolas Mailhot writes: > You do it like everyone else. You pass the codepoints to fontconfig Emacs does that already AFAIK. Andreas. -- Andreas Schwab, schwab at redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." From j.w.r.degoede at hhs.nl Fri Nov 13 10:13:10 2009 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 13 Nov 2009 11:13:10 +0100 Subject: libsndfile status? In-Reply-To: References: <20091103104851.571a717f@faldor.intranet> Message-ID: <4AFD3136.1050408@hhs.nl> Hi, On 11/13/2009 09:37 AM, Orcan Ogetbil wrote: > On Tue, Nov 3, 2009 at 12:47 PM, Orcan Ogetbil wrote: >> On Tue, Nov 3, 2009 at 4:48 AM, Michael Schwendt wrote: >>> https://admin.fedoraproject.org/pkgdb/packages/bugs/libsndfile >>> >>> What's up with libsndfile in Fedora and EPEL? >>> There are open tickets about CVEs filed in March. >>> There are additional tickets without any reply. >>> >> >> Yeah, things go a little slow with libsndfile. Because of the old >> version we have in< Fedora 12 we also are not able to update some of >> our audio packages. >> I requested for comaintainership to fix the bugs filed to Fedora. >> >> Orcan >> > > We can't reach the maintainer. We tried it in various ways at various > times, e.g. [1]. > > I even offered help but got nothing... Shall I fix the bugs and update > the package with my "proven" powers? I don't like to do substantial > changes on other people's packages. But this one has a security bug > that is open for 8 months... Also a few users asked me to update > ardour but I can't do it without updating libsndfile. > > What shall we do? > I would say just go ahead and fix it, and maybe start an awol maintainer procedure so that you can eventually take over the package. Regards, Hans From nicolas.mailhot at laposte.net Fri Nov 13 10:06:45 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 13 Nov 2009 11:06:45 +0100 Subject: Identifying remaining core font users In-Reply-To: References: <1257941463.841.37.camel@arekh.okg> <1258054776.12961.17.camel@arekh.okg> <1258105550.30766.3.camel@arekh.okg> Message-ID: <1258106805.14416.1.camel@arekh.okg> Le vendredi 13 novembre 2009 ? 10:55 +0100, Andreas Schwab a ?crit : > Nicolas Mailhot writes: > > > You do it like everyone else. You pass the codepoints to fontconfig > > Emacs does that already AFAIK. Then it has no actual need to the fallback path. It's probably only there because emacs people were not 100% confident on the new fontconfig code they wrote. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pertusus at free.fr Fri Nov 13 10:06:47 2009 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 13 Nov 2009 11:06:47 +0100 Subject: Identifying remaining core font users In-Reply-To: <1257941463.841.37.camel@arekh.okg> References: <1257941463.841.37.camel@arekh.okg> Message-ID: <20091113100647.GC2611@free.fr> On Wed, Nov 11, 2009 at 01:11:03PM +0100, Nicolas Mailhot wrote: > Hi, > > ? grads grads-0:1.9b4-28.fc12 > ? /usr/bin/gradsc > ? /usr/bin/gradsdods > ? /usr/bin/gradshdf > ? /usr/bin/gradsnc > ? /usr/bin/gxtran The X core fonts are used to draw custom widgets on the graphs. Maybe using xft as a build-time alternative would be acceptable upstream. I may have a look at it at some point. In the mean time it defaults to fixed font which should always be available. > ? lesstif lesstif-0:0.95.2-1.fc12 > ? /usr/lib64/libMrm.so.2.0.1 > ? /usr/lib64/libXm.so.2.0.1 lesstif since 2003 or so and Motif more generally supports Xft. I don't knwow exactly how integrated this is with fontconfig. When there is a need to do some low level stuff with fonts (for example getting the font dimensions), the calling appliaction should check whether this is a X Font, an X FontSet or an Xft font and act accordingly. So for Motif clients, there should always be some handling of X core fonts in parallel with Xft fonts. And in most cases the font style should not be known by the application since high level Motif API should be used. > ? xbae xbae-0:4.60.4-12.fc12 > ? /usr/lib64/libXbae.so.4.0.60 xbae uses some low level font handling in Draw.c/Create.c and XFT should be supported here. There is a request: https://sourceforge.net/tracker/?func=detail&aid=2811228&group_id=31337&atid=401983 I may have a look as time permits. -- Pat From pertusus at free.fr Fri Nov 13 10:09:20 2009 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 13 Nov 2009 11:09:20 +0100 Subject: Identifying remaining core font users In-Reply-To: <1258106805.14416.1.camel@arekh.okg> References: <1257941463.841.37.camel@arekh.okg> <1258054776.12961.17.camel@arekh.okg> <1258105550.30766.3.camel@arekh.okg> <1258106805.14416.1.camel@arekh.okg> Message-ID: <20091113100920.GA3449@free.fr> On Fri, Nov 13, 2009 at 11:06:45AM +0100, Nicolas Mailhot wrote: > Le vendredi 13 novembre 2009 ? 10:55 +0100, Andreas Schwab a ?crit : > > Nicolas Mailhot writes: > > > > > You do it like everyone else. You pass the codepoints to fontconfig > > > > Emacs does that already AFAIK. > > Then it has no actual need to the fallback path. It's probably only > there because emacs people were not 100% confident on the new fontconfig > code they wrote. There is also a portability issue. Maybe emacs is also meant to work on old unices that don't use fontconfig. -- Pat From nicolas.mailhot at laposte.net Fri Nov 13 10:22:40 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 13 Nov 2009 11:22:40 +0100 Subject: Identifying remaining core font users In-Reply-To: <20091113100920.GA3449@free.fr> References: <1257941463.841.37.camel@arekh.okg> <1258054776.12961.17.camel@arekh.okg> <1258105550.30766.3.camel@arekh.okg> <1258106805.14416.1.camel@arekh.okg> <20091113100920.GA3449@free.fr> Message-ID: <1258107760.14416.3.camel@arekh.okg> Le vendredi 13 novembre 2009 ? 11:09 +0100, Patrice Dumas a ?crit : > On Fri, Nov 13, 2009 at 11:06:45AM +0100, Nicolas Mailhot wrote: > > Le vendredi 13 novembre 2009 ? 10:55 +0100, Andreas Schwab a ?crit : > > > Nicolas Mailhot writes: > > > > > > > You do it like everyone else. You pass the codepoints to fontconfig > > > > > > Emacs does that already AFAIK. > > > > Then it has no actual need to the fallback path. It's probably only > > there because emacs people were not 100% confident on the new fontconfig > > code they wrote. > > There is also a portability issue. Maybe emacs is also meant to work > on old unices that don't use fontconfig. Well in that case you do not include the code for old unices in the version built for modern unices such as Fedora -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pertusus at free.fr Fri Nov 13 10:33:56 2009 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 13 Nov 2009 11:33:56 +0100 Subject: Identifying remaining core font users In-Reply-To: <1258107760.14416.3.camel@arekh.okg> References: <1257941463.841.37.camel@arekh.okg> <1258054776.12961.17.camel@arekh.okg> <1258105550.30766.3.camel@arekh.okg> <1258106805.14416.1.camel@arekh.okg> <20091113100920.GA3449@free.fr> <1258107760.14416.3.camel@arekh.okg> Message-ID: <20091113103356.GD3449@free.fr> On Fri, Nov 13, 2009 at 11:22:40AM +0100, Nicolas Mailhot wrote: > > Well in that case you do not include the code for old unices in the > version built for modern unices such as Fedora It is not always possible to distinguish whether the unix is old or new at compile time. Maybe the Xft version number could be a hint, but it may not be that easy. There could be, however, configure switches to disable completly support for one or the other backend, sure, that could be chosen by the pakager. -- Pat From thomasj at fedoraproject.org Fri Nov 13 11:14:37 2009 From: thomasj at fedoraproject.org (Thomas Janssen) Date: Fri, 13 Nov 2009 12:14:37 +0100 Subject: libsndfile status? In-Reply-To: <4AFD3136.1050408@hhs.nl> References: <20091103104851.571a717f@faldor.intranet> <4AFD3136.1050408@hhs.nl> Message-ID: 2009/11/13 Hans de Goede : > On 11/13/2009 09:37 AM, Orcan Ogetbil wrote: >> We can't reach the maintainer. We tried it in various ways at various >> times, e.g. [1]. >> >> But this one has a security bug >> that is open for 8 months... Also a few users asked me to update >> ardour but I can't do it without updating libsndfile. >> >> What shall we do? > > I would say just go ahead and fix it, and maybe start an awol maintainer > procedure so that you can eventually take over the package. +1 -- LG Thomas Dubium sapientiae initium From roopesh.majeti at gmail.com Fri Nov 13 11:21:33 2009 From: roopesh.majeti at gmail.com (Roopesh Majeti) Date: Fri, 13 Nov 2009 11:21:33 +0000 (UTC) Subject: Roopesh's Birthday Calendar Message-ID: <1019898453.465571258111293498.JavaMail.batch@lpc04> Hi Please click on the link below and enter your birthday for me. I am creating a birthday calendar for myself. Don't worry, it'll take less than a minute (and you don't have to enter your year of birth). http://www.birthdayalarm.com/bd2/51225737a343014563b1484265164c167535118d1386 Roopesh From nicolas.mailhot at laposte.net Fri Nov 13 11:34:22 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 13 Nov 2009 12:34:22 +0100 Subject: Identifying remaining core font users In-Reply-To: <20091113103356.GD3449@free.fr> References: <1257941463.841.37.camel@arekh.okg> <1258054776.12961.17.camel@arekh.okg> <1258105550.30766.3.camel@arekh.okg> <1258106805.14416.1.camel@arekh.okg> <20091113100920.GA3449@free.fr> <1258107760.14416.3.camel@arekh.okg> <20091113103356.GD3449@free.fr> Message-ID: <1258112062.14416.5.camel@arekh.okg> Le vendredi 13 novembre 2009 ? 11:33 +0100, Patrice Dumas a ?crit : > On Fri, Nov 13, 2009 at 11:22:40AM +0100, Nicolas Mailhot wrote: > > > > Well in that case you do not include the code for old unices in the > > version built for modern unices such as Fedora > > It is not always possible to distinguish whether the unix is old or > new at compile time. Maybe the Xft version number could be a hint, but > it may not be that easy. I'm quite sure it is that easy. fontconfig and xft2 were born at the same time out of an xft1 rewrite. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rjones at redhat.com Fri Nov 13 11:58:19 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 13 Nov 2009 11:58:19 +0000 Subject: Identifying remaining core font users In-Reply-To: <1258065506.7664.9.camel@arekh.okg> References: <1257941463.841.37.camel@arekh.okg> <20091112214723.GA3841@free.fr> <1258065506.7664.9.camel@arekh.okg> Message-ID: <20091113115819.GA11955@amd.home.annexia.org> On Thu, Nov 12, 2009 at 11:38:26PM +0100, Nicolas Mailhot wrote: > In fact the next step is probably to identify such indirect users (the > current check caught Motif apps, but gtk1 have the same problem). Nicolas, if possible next time please give the package maintainer (ie. FAS username) next to each package in the list. Otherwise it's harder to tell which packages I should look at. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From rawhide at fedoraproject.org Fri Nov 13 12:30:09 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Fri, 13 Nov 2009 12:30:09 +0000 Subject: rawhide report: 20091113 changes Message-ID: <20091113123009.GA7822@releng2.fedora.phx.redhat.com> Compose started at Fri Nov 13 08:15:09 UTC 2009 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 From nicolas.mailhot at laposte.net Fri Nov 13 13:35:27 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 13 Nov 2009 14:35:27 +0100 Subject: Identifying remaining core font users In-Reply-To: <20091113115819.GA11955@amd.home.annexia.org> References: <1257941463.841.37.camel@arekh.okg> <20091112214723.GA3841@free.fr> <1258065506.7664.9.camel@arekh.okg> <20091113115819.GA11955@amd.home.annexia.org> Message-ID: <1258119327.19405.2.camel@arekh.okg> Le vendredi 13 novembre 2009 ? 11:58 +0000, Richard W.M. Jones a ?crit : > On Thu, Nov 12, 2009 at 11:38:26PM +0100, Nicolas Mailhot wrote: > > In fact the next step is probably to identify such indirect users (the > > current check caught Motif apps, but gtk1 have the same problem). > > Nicolas, if possible next time please give the package maintainer > (ie. FAS username) next to each package in the list. Otherwise it's > harder to tell which packages I should look at. Last time I asked how to do this the answer was "just rewrite your script in python". Since I have other things to do, it won't happen. However once the heuristic is stabilized people will receive package-owner at ... mails -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From fedora at camperquake.de Fri Nov 13 13:50:50 2009 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 13 Nov 2009 14:50:50 +0100 Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: <4AFCCC84.4070404@fedoraproject.org> References: <1258055802.2192.53.camel@localhost.localdomain> <200911121226.27595.cemeyer@u.washington.edu> <1258058598.2477.22.camel@localhost.localdomain> <200911122330.27684.ville.skytta@iki.fi> <1258062337.2477.23.camel@localhost.localdomain> <4AFC9BBA.2080603@lfarkas.org> <4AFCCC84.4070404@fedoraproject.org> Message-ID: <20091113145050.526fdc53@dhcp03.addix.net> Hi. On Fri, 13 Nov 2009 08:33:32 +0530, Rahul Sundaram wrote: > Dracut produces a generic initrd by default instead of something > system specific. If you want to reduce that, go to /etc/dracut.conf > and enable the hostonly option. Can preupgrade generate an initrd? From gospo at redhat.com Fri Nov 13 14:35:52 2009 From: gospo at redhat.com (Andy Gospodarek) Date: Fri, 13 Nov 2009 09:35:52 -0500 Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: <20091113042728.GB3828@nostromo.devel.redhat.com> References: <20091113040408.GM25960@clingman.lan> <20091113042728.GB3828@nostromo.devel.redhat.com> Message-ID: <20091113143552.GN2231@gospo.rdu.redhat.com> On Thu, Nov 12, 2009 at 11:27:28PM -0500, Bill Nottingham wrote: > Toshio Kuratomi (a.badger at gmail.com) said: > > > There are definitely workarounds available, but none that meet the > > > criteria for preupgrade as an effortless upgrade option. > > > > So I'm a bit confused by what is so hard here. preupgrade starts up, > > finds it can't store stage2, and then tells you that you'll need to have a > > wired connection to the internet if you want to use it. So you have to > > download stage2 when you reboot and you have to cart your laptop over to the > > router to plug it in while it does so... it's not like I'm going to be using > > it for work while anaconda is running.... > > Basically, the case where it fails is when there's enough space to download > stage2, but not enough space left after downloading stage2 to do the > upgrade. > Could we add some support to use a USB key as scratch space for any part of this process? From nathanael at gnat.ca Fri Nov 13 14:53:21 2009 From: nathanael at gnat.ca (Nathanael Noblet) Date: Fri, 13 Nov 2009 07:53:21 -0700 Subject: abrt / kernel oops issue In-Reply-To: References: <4AFC466F.2060201@gnat.ca> Message-ID: On Nov 12, 2009, at 8:03 PM, Kevin Kofler wrote: > Nathanael D. Noblet wrote: >> Unless Virtualbox is closed source but I didn't think it was. > > VirtualBox is proprietary. VirtualBox OSE (Open Source Edition) is Free > Software. RPM Fusion (Free section) ships the latter. Upstream packages only > the former, they only distribute the OSE in source form. > right. this is the OSE version. From rjones at redhat.com Fri Nov 13 15:36:14 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 13 Nov 2009 15:36:14 +0000 Subject: Identifying remaining core font users In-Reply-To: <1258119327.19405.2.camel@arekh.okg> References: <1257941463.841.37.camel@arekh.okg> <20091112214723.GA3841@free.fr> <1258065506.7664.9.camel@arekh.okg> <20091113115819.GA11955@amd.home.annexia.org> <1258119327.19405.2.camel@arekh.okg> Message-ID: <20091113153614.GA13216@amd.home.annexia.org> On Fri, Nov 13, 2009 at 02:35:27PM +0100, Nicolas Mailhot wrote: > Le vendredi 13 novembre 2009 ? 11:58 +0000, Richard W.M. Jones a ?crit : > > On Thu, Nov 12, 2009 at 11:38:26PM +0100, Nicolas Mailhot wrote: > > > In fact the next step is probably to identify such indirect users (the > > > current check caught Motif apps, but gtk1 have the same problem). > > > > Nicolas, if possible next time please give the package maintainer > > (ie. FAS username) next to each package in the list. Otherwise it's > > harder to tell which packages I should look at. > > Last time I asked how to do this the answer was "just rewrite your > script in python". Since I have other things to do, it won't happen. > However once the heuristic is stabilized people will receive > package-owner at ... mails I'm no fan of Python either, but there is a fairly simple JSON API to the package database. eg: wget -O ocaml.json 'https://admin.fedoraproject.org/pkgdb/packages/name/ocaml?tg_format=json' which gave me a huge JSON-format file which did contain my FAS username in the field packageListings[0].people[0].username, see: http://www.annexia.org/tmp/ocaml.json.txt Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 nicolas.mailhot at laposte.net Fri Nov 13 16:42:42 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 13 Nov 2009 17:42:42 +0100 Subject: Identifying remaining core font users In-Reply-To: <1257941463.841.37.camel@arekh.okg> References: <1257941463.841.37.camel@arekh.okg> Message-ID: <1258130562.30821.1.camel@arekh.okg> Hi, Here is a new filtered list, based on the suggestions I've received since my first posting. Please tell me if there is still some files that should not belong here, and why ? 9wm-0:1.2-2.fc12 ? /usr/bin/9wm ? GraphicsMagick-0:1.3.7-1.fc12 ? /usr/lib64/libGraphicsMagick.so.3.2.0 ? ImageMagick-0:6.5.4.7-3.fc12 ? /usr/lib64/libMagickCore.so.2.0.0 ? MagicPoint-0:1.11b-10.fc12 ? /usr/bin/mgp ? /usr/bin/xwintoppm ? R-core-0:2.9.2-1.fc12 ? /usr/lib64/R/modules/R_X11.so ? TeXmacs-0:1.0.7.2-2.fc12 ? /usr/libexec/TeXmacs/bin/texmacs.bin ? WindowMaker-0:0.92.0-20.fc12 ? /usr/bin/wmaker ? aalib-libs-0:1.4.0-0.18.rc5.fc12 ? /usr/lib64/libaa.so.1.0.4 ? alliance-0:5.0-31.20090901snap.fc12 ? /usr/lib64/alliance/bin/dreal ? /usr/lib64/alliance/bin/graal ? /usr/lib64/alliance/bin/xfsm ? /usr/lib64/alliance/bin/xgra ? /usr/lib64/alliance/bin/xpat ? /usr/lib64/alliance/bin/xsch ? /usr/lib64/alliance/bin/xvpn ? aplus-fsf-0:4.22.4-19.fc12 ? /usr/lib64/aplus-fsf/4.22.4/libMSGUI.so ? aterm-0:1.0.1-6.fc12 ? /usr/bin/aterm ? cernlib-0:2006-34.fc12 ? /usr/lib64/cernlib/2006/lib/libgrafX11.so.1_gfortran.2006 ? /usr/lib64/cernlib/2006/lib/libpacklib-lesstif.so.1_gfortran.2006 ? /usr/lib64/cernlib/2006/lib/libpawlib-lesstif.so.3_gfortran.2006 ? cernlib-g77-0:2006-33.fc12 ? /usr/lib64/cernlib/2006-g77/lib/libgrafX11.so.1.2006 ? /usr/lib64/cernlib/2006-g77/lib/libpacklib-lesstif.so.1.2006 ? /usr/lib64/cernlib/2006-g77/lib/libpawlib-lesstif.so.3.2006 ? cgoban-0:1.9.14-12.fc12 ? /usr/bin/cgoban ? clips-xclips-0:6.30.0-0.1.20090722svn.fc12 ? /usr/bin/xclips ? clisp-0:2.47-4.fc12 ? /usr/lib64/clisp-2.47/full/lisp.run ? conky-0:1.7.2-1.fc12 ? /usr/bin/conky ? crossfire-client-0:1.11.0-3.fc12 ? /usr/bin/cfclient ? ddd-0:3.3.12-5.fc12 ? /usr/bin/ddd ? dinotrace-0:9.4a-5.fc12 ? /usr/bin/dinotrace ? dx-0:4.4.4-10.fc12 ? /usr/lib64/dx/bin_linux/builder ? /usr/lib64/dx/bin_linux/dxexec ? /usr/lib64/dx/bin_linux/dxui ? /usr/lib64/dx/bin_linux/prompter ? /usr/lib64/dx/bin_linux/startupui ? /usr/lib64/dx/bin_linux/tutor ? dx-libs-0:4.4.4-10.fc12 ? /usr/lib64/libDX.so.4.0.44 ? /usr/lib64/libDXcallm.so.4.0.44 ? dzen2-0:0.8.5-5.fc12 ? /usr/bin/dzen2-textwidth ? /usr/bin/dzen2 ? e16-0:0.16.8.15-3.fc12 ? /usr/bin/e16 ? efte-0:1.1-1.fc12 ? /usr/bin/efte ? emacs-1:23.1-10.fc12 ? /usr/bin/emacs-23.1 ? enlightenment-0:0.16.999.050-5.fc12 ? /usr/bin/enlightenment ? eterm-0:0.9.5-6.fc12 ? /usr/lib64/libEterm-0.9.5.so ? exim-mon-0:4.69-17.fc12 ? /usr/sbin/eximon.bin ? fbdesk-0:1.4.1-6.fc12 ? /usr/bin/fbdesk ? fltk-0:1.1.9-6.fc12 ? /usr/lib64/libfltk.so.1.1 ? fluxbox-0:1.1.1-5.fc12 ? /usr/bin/fbrun ? /usr/bin/fbsetroot ? /usr/bin/fluxbox ? fontforge-0:20090622-2.fc12 ? /usr/lib64/libgdraw.so.4.0.7 ? freefem++-0:3.5-2.fc12 ? /usr/bin/FreeFem++-x11 ? /usr/bin/drawbdmesh ? freefem++-glx-0:3.5-2.fc12 ? /usr/bin/FreeFem++-glx ? fvwm-0:2.5.26-4.fc12 ? /usr/bin/fvwm ? /usr/libexec/fvwm/2.5.26/FvwmButtons ? /usr/libexec/fvwm/2.5.26/FvwmForm ? /usr/libexec/fvwm/2.5.26/FvwmIconBox ? /usr/libexec/fvwm/2.5.26/FvwmIconMan ? /usr/libexec/fvwm/2.5.26/FvwmIdent ? /usr/libexec/fvwm/2.5.26/FvwmPager ? /usr/libexec/fvwm/2.5.26/FvwmProxy ? /usr/libexec/fvwm/2.5.26/FvwmScript ? /usr/libexec/fvwm/2.5.26/FvwmTaskBar ? /usr/libexec/fvwm/2.5.26/FvwmWinList ? gabedit-0:2.2.4-1.fc12 ? /usr/bin/gabedit ? gbdfed-0:1.5-1.fc12 ? /usr/bin/gbdfed ? gcl-0:2.6.8-0.6.20090701cvs.fc12 ? /usr/lib/gcl-2.6.8/unixport/saved_ansi_gcl ? gds2pov-0:0.20080229-3.fc12 ? /usr/bin/gdsoglviewer ? geomview-0:1.9.4-10.fc12 ? /usr/libexec/geomview/animate ? /usr/libexec/geomview/gvx ? ghostscript-0:8.70-1.fc12 ? /usr/lib64/ghostscript/8.70/X11.so ? gle-0:4.2.0-4.fc12 ? /usr/lib64/libgle-graphics-4.2.0.so ? glest-0:3.2.2-1.fc12 ? /usr/libexec/glest/glest ? gnuplot-common-0:4.2.6-1.fc12 ? /usr/libexec/gnuplot/4.2/gnuplot_x11 ? grace-0:5.1.22-5.fc12 ? /usr/bin/gracebat ? /usr/bin/xmgrace ? grads-0:1.9b4-28.fc12 ? /usr/bin/gradsc ? /usr/bin/gradsdods ? /usr/bin/gradshdf ? /usr/bin/gradsnc ? /usr/bin/gxtran ? graphviz-0:2.20.3-5.fc12.1 ? /usr/bin/lefty ? grass-0:6.3.0-14.fc12 ? /usr/lib64/grass-6.3.0/etc/nviz2.2/nviz ? gridengine-qmon-0:6.2u3-3.fc12 ? /usr/bin/qmon ? groff-gxditview-0:1.18.1.4-18.fc12 ? /usr/bin/gxditview ? gromacs-0:4.0.4-2.fc11 ? /usr/bin/g_highway_d ? /usr/bin/g_highway ? /usr/bin/g_ngmx_d ? /usr/bin/g_ngmx ? /usr/bin/g_xrama_d ? /usr/bin/g_xrama ? gtk+-1:1.2.10-69.fc12 ? /usr/lib64/libgdk-1.2.so.0.9.1 ? gtk2-0:2.18.3-19.fc12 ? /usr/lib64/libgdk-x11-2.0.so.0.1800.3 ? hackedbox-0:0.8.5-7.fc12 ? /usr/bin/hackedbox ? hugs98-x11-0:2006.09-8.fc12 ? /usr/lib64/hugs/packages/X11/Graphics/X11/Xlib/Font.so ? irsim-0:9.7.68-3.fc12 ? /usr/bin/irsim ? java-1.6.0-openjdk-1:1.6.0.0-31.b16.fc12 ? /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/xawt/libmawt.so ? kdebase-workspace-0:4.3.2-1.fc12 ? /usr/lib64/kde4/kcm_input.so ? kinput2-0:v3.1-41.fc12 ? /usr/bin/kinput2.canna ? koules-x11-0:1.4-8.fc12 ? /usr/bin/xkoules ? lesstif-0:0.95.2-1.fc12 ? /usr/lib64/libMrm.so.2.0.1 ? /usr/lib64/libXm.so.2.0.1 ? libXaw-0:1.0.6-4.fc12 ? /usr/lib64/libXaw7.so.7.0.0 ? libXt-0:1.0.7-1.fc12 ? /usr/lib64/libXt.so.6.0.0 ? libcaca-0:0.99-0.9.beta16.fc12 ? /usr/lib64/libcaca.so.0.99.16 ? libsx-0:2.05-18.fc12 ? /usr/lib64/libsx.so.0.0.0 ? lirc-0:0.8.6-1.fc12 ? /usr/bin/xmode2 ? lsnipes-0:0.9.4-5.fc12 ? /usr/bin/snipes ? lush-0:1.2.1-6.fc12 ? /usr/bin/lush ? metacity-0:2.28.0-9.fc12 ? /usr/bin/metacity ? mrxvt-0:0.5.3-5.fc12 ? /usr/bin/mrxvt ? mutter-0:2.28.0-2.fc12 ? /usr/bin/mutter ? ncl-0:5.1.1-3.fc12 ? /usr/bin/ctrans ? /usr/bin/ictrans ? ncview-0:1.93c-6.fc12 ? /usr/bin/ncview ? nedit-0:5.5-22.fc12 ? /usr/bin/nedit ? ngspice-0:19-1.fc12 ? /usr/bin/ngnutmeg ? /usr/bin/ngspice ? nx-0:3.3.0-38.fc12 ? /usr/libexec/nx/nxagent ? ocaml-0:3.11.1-0.rc1.2.fc12.1 ? /usr/lib64/ocaml/graphics.cmxs ? ocaml-lablgl-0:1.04-2.fc12 ? /usr/lib64/ocaml/stublibs/dlltogl.so ? ocaml-runtime-0:3.11.1-0.rc1.2.fc12.1 ? /usr/lib64/ocaml/stublibs/dllgraphics.so ? openoffice.org-core-1:3.1.1-19.14.fc12 ? /usr/lib64/openoffice.org/basis3.1/program/libvclplug_genlx.so ? pango-0:1.26.0-1.fc12 ? /usr/lib64/libpangox-1.0.so.0.2600.0 ? paw-0:2006-33.fc12 ? /usr/bin/paw++ ? /usr/bin/pawX11 ? paw-g77-0:2006-33.fc12 ? /usr/bin/paw++-g77 ? /usr/bin/pawX11-g77 ? paw-gfortran-0:2006-34.fc12 ? /usr/bin/paw++-gfortran ? /usr/bin/pawX11-gfortran ? perl-PDL-0:2.4.4_05-5.fc12 ? /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/auto/PDL/Graphics/OpenGL/OpenGL.so ? perl-Tk-0:804.028-10.fc12 ? /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/auto/Tk/Tk.so ? pigment-0:0.3.17-3.fc12 ? /usr/lib64/pigment-0.3/0.3.17/libpgmopengl.so ? plotutils-0:2.5-7.fc12 ? /usr/lib64/libplot.so.2.2.2 ? /usr/lib64/libplotter.so.2.2.2 ? plt-scheme-1:4.1.2-3.fc12 ? /usr/bin/mred ? qt-x11-1:4.5.3-7.fc12 ? /usr/lib64/libQtGui.so.4.5.3 ? qt3-0:3.3.8b-28.fc12 ? /usr/lib64/qt-3.3/lib/libqt-mt.so.3.3.8 ? rcssmonitor-0:13.1.0-3.fc12 ? /usr/bin/rcssmonitor ? rxvt-0:2.7.10-17.fc12 ? /usr/bin/rclock ? /usr/bin/rxvt-2.7.10 ? /usr/bin/rxvt ? rxvt-unicode-0:9.06-4.fc12 ? /usr/bin/urxvtd ? /usr/bin/urxvt ? sK1-0:0.9.1-0.2.pre_rev730.fc12 ? /usr/lib64/python2.6/site-packages/sk1/app/modules/paxmodule.so ? saoimage-0:1.35.1-7.fc12 ? /usr/bin/saoimage ? starlab-libs-0:4.4.3-7.fc12 ? /usr/lib64/libgfx.so.0.0.0 ? tgif-0:4.2.1-1.fc12 ? /usr/libexec/tgif ? tigervnc-0:1.0.0-1.fc12 ? /usr/bin/vncviewer ? tigervnc-server-0:1.0.0-1.fc12 ? /usr/bin/vncconfig ? /usr/bin/x0vncserver ? tk-1:8.5.7-2.fc12 ? /usr/lib64/libtk8.5.so ? tkgate-0:2.0-7.beta9.fc12 ? /usr/bin/tkgate ? torsmo-0:0.18-10.fc12 ? /usr/bin/torsmo ? ucblogo-0:6.0-5.fc12 ? /usr/bin/logo ? windowlab-0:1.37-1.fc12 ? /usr/bin/windowlab ? wine-core-0:1.1.29-3.fc12 ? /usr/lib64/wine/winex11.drv.so ? x11-ssh-askpass-0:1.2.4.1-7.fc12 ? /usr/libexec/openssh/x11-ssh-askpass ? x3270-x11-0:3.3.6-10.fc12 ? /usr/bin/x3270 ? xaos-0:3.5-1.fc12 ? /usr/bin/xaos ? xarchon-0:0.50-10.fc12 ? /usr/bin/xarchon ? xastir-1:1.9.4-10.fc12 ? /usr/bin/xastir ? xawtv-0:3.95-12.fc12.1 ? /usr/bin/xawtv ? xblast-x11-0:2.10.4-8.fc12 ? /usr/bin/xblast-x11 ? xboard-0:4.2.7-20.fc12 ? /usr/bin/xboard ? xcircuit-0:3.6.161-1.fc12 ? /usr/lib64/xcircuit-3.6/xcircuit.so ? xdaliclock-0:2.25-3.fc12 ? /usr/bin/xdaliclock ? xdvik-0:22.84.14-7.fc12 ? /usr/bin/pxdvi-xaw3d ? /usr/bin/xdvi-xaw3d ? xemacs-0:21.5.29-6.fc12 ? /usr/bin/xemacs-21.5-b29 ? xfig-0:3.2.5-22.a.fc12 ? /usr/bin/xfig-Xaw3d ? xfig-plain-0:3.2.5-22.a.fc12 ? /usr/bin/xfig-plain ? xforms-0:1.0.92-2.sp2.fc12 ? /usr/lib64/libforms.so.1.1.0 ? xgalaxy-0:2.0.34-13.fc12 ? /usr/bin/xgalaxy-hyperspace ? /usr/bin/xgalaxy ? xlockmore-0:5.28-1.fc12 ? /usr/bin/xlock ? xmbdfed-0:4.7-7.fc12 ? /usr/bin/xmbdfed ? xmonad-0:0.8.1-15.fc12 ? /usr/bin/xmonad ? xorg-x11-apps-0:7.4-8.fc12 ? /usr/bin/x11perf ? /usr/bin/xwd ? xorg-x11-twm-1:1.0.3-5.fc12 ? /usr/bin/twm ? xosview-0:1.8.3-17.20080301cvs.fc12 ? /usr/bin/xosview ? xpilot-ng-0:4.7.2-16.fc11 ? /usr/bin/xpilot-ng-replay ? /usr/bin/xpilot-ng-x11 ? xpilot-ng-server-0:4.7.2-16.fc11 ? /usr/bin/xpilot-ng-xp-mapedit ? xscreensaver-base-1:5.10-2.fc12 ? /usr/bin/xscreensaver ? xscreensaver-extras-1:5.10-2.fc12 ? /usr/libexec/xscreensaver/abstractile ? /usr/libexec/xscreensaver/anemone ? /usr/libexec/xscreensaver/anemotaxis ? /usr/libexec/xscreensaver/apollonian ? /usr/libexec/xscreensaver/apple2 ? /usr/libexec/xscreensaver/attraction ? /usr/libexec/xscreensaver/barcode ? /usr/libexec/xscreensaver/blaster ? /usr/libexec/xscreensaver/blitspin ? /usr/libexec/xscreensaver/bouboule ? /usr/libexec/xscreensaver/boxfit ? /usr/libexec/xscreensaver/braid ? /usr/libexec/xscreensaver/bsod ? /usr/libexec/xscreensaver/bumps ? /usr/libexec/xscreensaver/ccurve ? /usr/libexec/xscreensaver/celtic ? /usr/libexec/xscreensaver/cloudlife ? /usr/libexec/xscreensaver/compass ? /usr/libexec/xscreensaver/coral ? /usr/libexec/xscreensaver/crystal ? /usr/libexec/xscreensaver/cwaves ? /usr/libexec/xscreensaver/cynosure ? /usr/libexec/xscreensaver/decayscreen ? /usr/libexec/xscreensaver/deco ? /usr/libexec/xscreensaver/deluxe ? /usr/libexec/xscreensaver/demon ? /usr/libexec/xscreensaver/discrete ? /usr/libexec/xscreensaver/distort ? /usr/libexec/xscreensaver/drift ? /usr/libexec/xscreensaver/epicycle ? /usr/libexec/xscreensaver/eruption ? /usr/libexec/xscreensaver/euler2d ? /usr/libexec/xscreensaver/fadeplot ? /usr/libexec/xscreensaver/fiberlamp ? /usr/libexec/xscreensaver/fireworkx ? /usr/libexec/xscreensaver/flame ? /usr/libexec/xscreensaver/flow ? /usr/libexec/xscreensaver/fluidballs ? /usr/libexec/xscreensaver/fontglide ? /usr/libexec/xscreensaver/fuzzyflakes ? /usr/libexec/xscreensaver/galaxy ? /usr/libexec/xscreensaver/goop ? /usr/libexec/xscreensaver/grav ? /usr/libexec/xscreensaver/greynetic ? /usr/libexec/xscreensaver/halftone ? /usr/libexec/xscreensaver/halo ? /usr/libexec/xscreensaver/helix ? /usr/libexec/xscreensaver/hopalong ? /usr/libexec/xscreensaver/ifs ? /usr/libexec/xscreensaver/imsmap ? /usr/libexec/xscreensaver/interaggregate ? /usr/libexec/xscreensaver/interference ? /usr/libexec/xscreensaver/intermomentary ? /usr/libexec/xscreensaver/julia ? /usr/libexec/xscreensaver/kaleidescope ? /usr/libexec/xscreensaver/kumppa ? /usr/libexec/xscreensaver/lcdscrub ? /usr/libexec/xscreensaver/loop ? /usr/libexec/xscreensaver/m6502 ? /usr/libexec/xscreensaver/maze ? /usr/libexec/xscreensaver/memscroller ? /usr/libexec/xscreensaver/metaballs ? /usr/libexec/xscreensaver/moire2 ? /usr/libexec/xscreensaver/moire ? /usr/libexec/xscreensaver/mountain ? /usr/libexec/xscreensaver/munch ? /usr/libexec/xscreensaver/nerverot ? /usr/libexec/xscreensaver/noseguy ? /usr/libexec/xscreensaver/pacman ? /usr/libexec/xscreensaver/pedal ? /usr/libexec/xscreensaver/penetrate ? /usr/libexec/xscreensaver/penrose ? /usr/libexec/xscreensaver/petri ? /usr/libexec/xscreensaver/phosphor ? /usr/libexec/xscreensaver/piecewise ? /usr/libexec/xscreensaver/polyominoes ? /usr/libexec/xscreensaver/pong ? /usr/libexec/xscreensaver/popsquares ? /usr/libexec/xscreensaver/pyro ? /usr/libexec/xscreensaver/qix ? /usr/libexec/xscreensaver/rd-bomb ? /usr/libexec/xscreensaver/ripples ? /usr/libexec/xscreensaver/rocks ? /usr/libexec/xscreensaver/rorschach ? /usr/libexec/xscreensaver/rotzoomer ? /usr/libexec/xscreensaver/shadebobs ? /usr/libexec/xscreensaver/sierpinski ? /usr/libexec/xscreensaver/slidescreen ? /usr/libexec/xscreensaver/slip ? /usr/libexec/xscreensaver/speedmine ? /usr/libexec/xscreensaver/spotlight ? /usr/libexec/xscreensaver/squiral ? /usr/libexec/xscreensaver/starfish ? /usr/libexec/xscreensaver/strange ? /usr/libexec/xscreensaver/substrate ? /usr/libexec/xscreensaver/swirl ? /usr/libexec/xscreensaver/thornbird ? /usr/libexec/xscreensaver/triangle ? /usr/libexec/xscreensaver/truchet ? /usr/libexec/xscreensaver/twang ? /usr/libexec/xscreensaver/vermiculate ? /usr/libexec/xscreensaver/wander ? /usr/libexec/xscreensaver/whirlwindwarp ? /usr/libexec/xscreensaver/wormhole ? /usr/libexec/xscreensaver/xanalogtv ? /usr/libexec/xscreensaver/xflame ? /usr/libexec/xscreensaver/xjack ? /usr/libexec/xscreensaver/xlyap ? /usr/libexec/xscreensaver/xmatrix ? /usr/libexec/xscreensaver/xrayswarm ? /usr/libexec/xscreensaver/xspirograph ? /usr/libexec/xscreensaver/zoom ? xscreensaver-gl-extras-1:5.10-2.fc12 ? /usr/libexec/xscreensaver/antinspect ? /usr/libexec/xscreensaver/antmaze ? /usr/libexec/xscreensaver/antspotlight ? /usr/libexec/xscreensaver/atlantis ? /usr/libexec/xscreensaver/atunnel ? /usr/libexec/xscreensaver/blinkbox ? /usr/libexec/xscreensaver/blocktube ? /usr/libexec/xscreensaver/boing ? /usr/libexec/xscreensaver/bouncingcow ? /usr/libexec/xscreensaver/boxed ? /usr/libexec/xscreensaver/bubble3d ? /usr/libexec/xscreensaver/cage ? /usr/libexec/xscreensaver/carousel ? /usr/libexec/xscreensaver/circuit ? /usr/libexec/xscreensaver/crackberg ? /usr/libexec/xscreensaver/cube21 ? /usr/libexec/xscreensaver/cubenetic ? /usr/libexec/xscreensaver/cubestorm ? /usr/libexec/xscreensaver/cubicgrid ? /usr/libexec/xscreensaver/dangerball ? /usr/libexec/xscreensaver/endgame ? /usr/libexec/xscreensaver/engine ? /usr/libexec/xscreensaver/flipflop ? /usr/libexec/xscreensaver/flipscreen3d ? /usr/libexec/xscreensaver/fliptext ? /usr/libexec/xscreensaver/flurry ? /usr/libexec/xscreensaver/flyingtoasters ? /usr/libexec/xscreensaver/gears ? /usr/libexec/xscreensaver/gflux ? /usr/libexec/xscreensaver/glblur ? /usr/libexec/xscreensaver/glcells ? /usr/libexec/xscreensaver/gleidescope ? /usr/libexec/xscreensaver/glhanoi ? /usr/libexec/xscreensaver/glknots ? /usr/libexec/xscreensaver/glmatrix ? /usr/libexec/xscreensaver/glplanet ? /usr/libexec/xscreensaver/glschool ? /usr/libexec/xscreensaver/glslideshow ? /usr/libexec/xscreensaver/glsnake ? /usr/libexec/xscreensaver/gltext ? /usr/libexec/xscreensaver/hypertorus ? /usr/libexec/xscreensaver/hypnowheel ? /usr/libexec/xscreensaver/jigglypuff ? /usr/libexec/xscreensaver/jigsaw ? /usr/libexec/xscreensaver/juggler3d ? /usr/libexec/xscreensaver/klein ? /usr/libexec/xscreensaver/lament ? /usr/libexec/xscreensaver/lavalite ? /usr/libexec/xscreensaver/lockward ? /usr/libexec/xscreensaver/menger ? /usr/libexec/xscreensaver/mirrorblob ? /usr/libexec/xscreensaver/moebiusgears ? /usr/libexec/xscreensaver/moebius ? /usr/libexec/xscreensaver/molecule ? /usr/libexec/xscreensaver/morph3d ? /usr/libexec/xscreensaver/noof ? /usr/libexec/xscreensaver/photopile ? /usr/libexec/xscreensaver/pinion ? /usr/libexec/xscreensaver/pipes ? /usr/libexec/xscreensaver/polyhedra ? /usr/libexec/xscreensaver/polytopes ? /usr/libexec/xscreensaver/providence ? /usr/libexec/xscreensaver/pulsar ? /usr/libexec/xscreensaver/queens ? /usr/libexec/xscreensaver/rubikblocks ? /usr/libexec/xscreensaver/rubik ? /usr/libexec/xscreensaver/sballs ? /usr/libexec/xscreensaver/sierpinski3d ? /usr/libexec/xscreensaver/skytentacles ? /usr/libexec/xscreensaver/sonar ? /usr/libexec/xscreensaver/spheremonics ? /usr/libexec/xscreensaver/sproingies ? /usr/libexec/xscreensaver/stairs ? /usr/libexec/xscreensaver/starwars ? /usr/libexec/xscreensaver/stonerview ? /usr/libexec/xscreensaver/superquadrics ? /usr/libexec/xscreensaver/surfaces ? /usr/libexec/xscreensaver/tangram ? /usr/libexec/xscreensaver/timetunnel ? /usr/libexec/xscreensaver/topblock ? /usr/libexec/xscreensaver/voronoi ? xterm-0:248-2.fc12 ? /usr/bin/xterm ? xtide-0:2.10-5.fc12 ? /usr/bin/xtide ? xwrits-0:2.24-6.fc12 ? /usr/bin/xwrits ? yadex-0:1.7.0-13.fc12 ? /usr/bin/yadex-1.7.0 Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Fri Nov 13 16:53:24 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 13 Nov 2009 17:53:24 +0100 Subject: Identifying remaining core font users In-Reply-To: <1258130562.30821.1.camel@arekh.okg> References: <1257941463.841.37.camel@arekh.okg> <1258130562.30821.1.camel@arekh.okg> Message-ID: <1258131204.30821.5.camel@arekh.okg> Le vendredi 13 novembre 2009 ? 17:42 +0100, Nicolas Mailhot a ?crit : > Here is a new filtered list, based on the suggestions I've received > since my first posting. Please tell me if there is still some files that > should not belong here, and why I should have written that the test used in this version is repoquery --whatrequires 'libX11.so*' ? grep -i -e "^./sbin/" \ -e "^./usr/sbin/" \ -e "^./usr/kerberos/sbin" \ -e "^./bin/" \ -e "^./usr/bin/" \ -e "^./usr/kerberos/bin/" \ -e "^./lib.*/" \ -e "^./usr/lib.*/" \ -e "^./opt/" \ -e "^./usr/X11R6/" \ -e "^./usr/games/" \ -e "^./usr/local/" \ | grep -vi -e "^./usr/bin/dmxwininfo" \ -e "^./usr/bin/Xdmx" \ -e "^./usr/bin/xfontsel" \ -e "^./usr/bin/xlsfonts" \ -e "^./usr/bin/Xnest" \ -e "^./usr/bin/xprop" \ -e "^./usr/bin/xsetroot" \ -e "^./usr/bin/xwininfo" \ -e "^./usr/bin/x11vnc" \ -e "^./usr/bin/x2vnc" \ -e "^./usr/lib.*/libXcursor.so" ? [ $(nm -aDu "$file" 2> /dev/null | grep -q '\ From jlaska at redhat.com Fri Nov 13 16:59:57 2009 From: jlaska at redhat.com (James Laska) Date: Fri, 13 Nov 2009 11:59:57 -0500 Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: <20091113143552.GN2231@gospo.rdu.redhat.com> References: <20091113040408.GM25960@clingman.lan> <20091113042728.GB3828@nostromo.devel.redhat.com> <20091113143552.GN2231@gospo.rdu.redhat.com> Message-ID: <1258131597.2381.102.camel@localhost.localdomain> On Fri, 2009-11-13 at 09:35 -0500, Andy Gospodarek wrote: > On Thu, Nov 12, 2009 at 11:27:28PM -0500, Bill Nottingham wrote: > > Toshio Kuratomi (a.badger at gmail.com) said: > > > > There are definitely workarounds available, but none that meet the > > > > criteria for preupgrade as an effortless upgrade option. > > > > > > So I'm a bit confused by what is so hard here. preupgrade starts up, > > > finds it can't store stage2, and then tells you that you'll need to have a > > > wired connection to the internet if you want to use it. So you have to > > > download stage2 when you reboot and you have to cart your laptop over to the > > > router to plug it in while it does so... it's not like I'm going to be using > > > it for work while anaconda is running.... > > > > Basically, the case where it fails is when there's enough space to download > > stage2, but not enough space left after downloading stage2 to do the > > upgrade. > > > > Could we add some support to use a USB key as scratch space for any part > of this process? Not a bad idea. Not sure who would add this support and test it before Tuesday. Definitely something to consider as a future enhancement to preupgrade. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jonathan.underwood at gmail.com Fri Nov 13 18:01:47 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 13 Nov 2009 18:01:47 +0000 Subject: Identifying remaining core font users In-Reply-To: <1258130562.30821.1.camel@arekh.okg> References: <1257941463.841.37.camel@arekh.okg> <1258130562.30821.1.camel@arekh.okg> Message-ID: <645d17210911131001l4a8d20f2xe882be8126af083d@mail.gmail.com> 2009/11/13 Nicolas Mailhot : > ? xdvik-0:22.84.14-7.fc12 > ?? /usr/bin/pxdvi-xaw3d > ?? /usr/bin/xdvi-xaw3d A more crusty piece of code than xdvi you never did see. It's very much in bugfix only mode upstream, so I very much doubt upstream, such as it is, will be moving to a modern tool kit and using fontconfig. I don't think it'd be a useful expenditure of time in any case. A better expenditure of time would be to work out what (if any) functionality is missing in evince-dvi which prevents us from dropping xdvi altogether. J. From nicolas.mailhot at laposte.net Fri Nov 13 18:39:58 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 13 Nov 2009 19:39:58 +0100 Subject: Identifying remaining core font users In-Reply-To: <645d17210911131001l4a8d20f2xe882be8126af083d@mail.gmail.com> References: <1257941463.841.37.camel@arekh.okg> <1258130562.30821.1.camel@arekh.okg> <645d17210911131001l4a8d20f2xe882be8126af083d@mail.gmail.com> Message-ID: <1258137598.25528.0.camel@arekh.okg> Le vendredi 13 novembre 2009 ? 18:01 +0000, Jonathan Underwood a ?crit : > 2009/11/13 Nicolas Mailhot : > > ? xdvik-0:22.84.14-7.fc12 > > ? /usr/bin/pxdvi-xaw3d > > ? /usr/bin/xdvi-xaw3d > > A more crusty piece of code than xdvi you never did see. It's very > much in bugfix only mode upstream, so I very much doubt upstream, such > as it is, will be moving to a modern tool kit and using fontconfig. I > don't think it'd be a useful expenditure of time in any case. A > better expenditure of time would be to work out what (if any) > functionality is missing in evince-dvi which prevents us from dropping > xdvi altogether. As long as the bit using Core fonts is no longer in the repo, I'll be happy :p -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From poelstra at redhat.com Fri Nov 13 18:44:23 2009 From: poelstra at redhat.com (John Poelstra) Date: Fri, 13 Nov 2009 10:44:23 -0800 Subject: Fedora 12 has gone gold In-Reply-To: <1257873852.2468.58.camel@localhost.localdomain> References: <1257816570.2468.32.camel@localhost.localdomain> <4AF99CBC.6060501@redhat.com> <1257873852.2468.58.camel@localhost.localdomain> Message-ID: <4AFDA907.2050408@redhat.com> On 11/10/2009 09:24 AM, Jesse Keating wrote: > On Tue, 2009-11-10 at 09:02 -0800, John Poelstra wrote: >> >> My impressions from this meeting were slightly different :-) >> >> We noted that there are no known reasons that we are "not go" and that >> we will continue testing until Wednesday when QA expects to have >> completed the testing matrix. Maybe we are separated by semantics, but >> "gone gold" or "completely done" was not an impression I left the >> meeting with. >> >> http://meetbot.fedoraproject.org/fedora-meeting/2009-11-10/fedora-meeting.2009-11-10-01.01.log.html > > Our impressions are indeed different. The go / no go meeting was the > point of no return. Once we go, there is no going back. We've made a > commitment to go with what we have, and let the various teams that need > time to prepare for the release to start their work, as much of that > work cannot be pulled back once done. > > Let's say all of these things next time and be clear about what our next steps are. I will try to help with that. Re-reading the meeting log, none of the things announced about "going GOLD" were said at the meeting. The "Go/No-Go" meetings for Alpha and Beta were handled differently in that we kept optimistically testing after them vs. saying we were "GO" and abruptly moving on to other things. That was the disconnect for me. John From kevin at scrye.com Fri Nov 13 18:44:34 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 13 Nov 2009 11:44:34 -0700 Subject: FESCO meeting summary - 2009-11-13 Message-ID: <20091113114434.62671daa@ohm.scrye.com> =================================== #fedora-meeting: FESCO (2009-11-13) =================================== Meeting started by nirik at 17:00:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2009-11-13/fesco.2009-11-13-17.00.log.html Meeting summary --------------- * ticket 263 - Sponsorship request: hubbitus (nirik, 17:03:47) * AGREED: ticket 263 is rejected for now. (nirik, 17:06:41) * ticket 268 - Proven packager request - Daniel Drake (nirik, 17:06:54) * AGREED: ticket 268 is approved. (nirik, 17:08:13) * ticket 269 - Request to approve mether a sponsor for package maintainers (nirik, 17:08:34) * AGREED: ticket 269 is rejected for now, please do some more detailed reviews and come back in a while. (nirik, 17:11:24) * ticket 270 - FESCO topic proposal - preupgrade and F-12 (nirik, 17:11:39) * LINK: https://fedoraproject.org/wiki/QA:Testcase_Preupgrade (jlaska, 17:36:27) * AGREED: preupgrade plan is approved. (nirik, 17:39:01) * ticket 41 - SystemTap Static Probes - https://fedoraproject.org/wiki/Features/SystemtapStaticProbes (nirik, 17:42:06) * back to preupgrade talk (nirik, 17:45:38) * ticket 41 - SystemTap Static Probes - https://fedoraproject.org/wiki/Features/SystemtapStaticProbes (nirik, 17:47:12) * LINK: https://fedoraproject.org/w/index.php?title=Features/SystemtapStaticProbes&diff=113907&oldid=99276 (nirik, 17:49:46) * AGREED: SystemTap Static Probes feature is approved for F13 (nirik, 17:51:18) * ticket 260 - SIP Witch Domain Telephony - https://fedoraproject.org/wiki/Features/SIP_Witch_Domain_Telephony (nirik, 17:51:36) * AGREED: the SIP Witch Domain Telephony Feature is approved for F13. (nirik, 17:55:00) * ticket 271 - Automatic Print Driver installation - https://fedoraproject.org/wiki/Features/AutomaticPrintDriverInstallation (nirik, 17:55:22) * AGREED: Automatic Print Driver installation feature is approved for F13 (nirik, 18:02:20) * ticket 272 - Intellij IDEA - https://fedoraproject.org/wiki/Features/IntelliJ_IDEA (nirik, 18:02:35) * LINK: http://www.jetbrains.com/idea/ (Kevin_Kofler, 18:08:14) * LINK: http://www.jetbrains.com/idea/buy/buy.jsp#openSource seems to indicate that its for open source developers only (dgilmore, 18:10:44) * LINK: http://www.jetbrains.com/idea/nextversion/free_java_ide.html (dgilmore, 18:12:05) * LINK: http://www.jetbrains.com/company/press/pr_151009.html (Kevin_Kofler, 18:12:15) * AGREED: the Intellij IDEA Feature is deffered until next week for more info from the feature owner. (nirik, 18:15:34) * ticket 273 - Python 3 F13 - https://fedoraproject.org/wiki/Features/Python3F13 (nirik, 18:15:51) * LINK: https://fedoraproject.org/wiki/PackagingDrafts/Python3 (dmalcolm, 18:20:39) * LINK: https://fedoraproject.org/wiki/PackagingDrafts/Python3#Python_modules_for_non-standard_runtimes in fact (dmalcolm, 18:21:03) * AGREED: Python 3 F13 feature is approved for F13 (nirik, 18:25:59) * Open Floor (nirik, 18:26:06) Meeting ended at 18:37:11 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * nirik (123) * Kevin_Kofler (92) * wwoods (83) * j-rod (55) * skvidal (46) * dgilmore (31) * jlaska (27) * dmalcolm (19) * zodbot (16) * sharkcz (16) * Oxf13 (14) * oget (7) * tibbs (6) * abadger1999 (5) * jrb (4) * thomasj (4) * jwb (3) * muep_ (2) * smooge (1) * cebbert (1) * dwmw2 (0) * jds2001 (0) * notting (0) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jkeating at redhat.com Fri Nov 13 18:57:17 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 13 Nov 2009 10:57:17 -0800 Subject: Fedora 12 has gone gold In-Reply-To: <4AFDA907.2050408@redhat.com> References: <1257816570.2468.32.camel@localhost.localdomain> <4AF99CBC.6060501@redhat.com> <1257873852.2468.58.camel@localhost.localdomain> <4AFDA907.2050408@redhat.com> Message-ID: <1258138637.15679.44.camel@localhost.localdomain> On Fri, 2009-11-13 at 10:44 -0800, John Poelstra wrote: > Let's say all of these things next time and be clear about what our next > steps are. I will try to help with that. Re-reading the meeting log, > none of the things announced about "going GOLD" were said at the > meeting. The "Go/No-Go" meetings for Alpha and Beta were handled > differently in that we kept optimistically testing after them vs. saying > we were "GO" and abruptly moving on to other things. > > That was the disconnect for me. AFAIK QA always keeps testing things, because there are still bugs to be found, and things to document for the release, or things to update for 0-day. The whole point of having a go/no-go decision is that it is the point where we say we are going without stopping, or we're stopping until we fix some things and we can go again. It's a point in which we tell those that depend on us that we are go, that nothing can stop us. I had mistakenly assumed everybody knew that's what a go/no-go was. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Fri Nov 13 19:08:30 2009 From: ville.skytta at iki.fi (Ville =?windows-1252?q?Skytt=E4?=) Date: Fri, 13 Nov 2009 21:08:30 +0200 Subject: Identifying remaining core font users In-Reply-To: <1258119327.19405.2.camel@arekh.okg> References: <1257941463.841.37.camel@arekh.okg> <20091113115819.GA11955@amd.home.annexia.org> <1258119327.19405.2.camel@arekh.okg> Message-ID: <200911132108.31082.ville.skytta@iki.fi> On Friday 13 November 2009, Nicolas Mailhot wrote: > Le vendredi 13 novembre 2009 ? 11:58 +0000, Richard W.M. Jones a ?crit : > > Nicolas, if possible next time please give the package maintainer > > (ie. FAS username) next to each package in the list. Otherwise it's > > harder to tell which packages I should look at. > > Last time I asked how to do this the answer was "just rewrite your > script in python". Since I have other things to do, it won't happen. Check out /usr/bin/fedoradev-pkgowners in the fedora-packager package. From nicolas.mailhot at laposte.net Fri Nov 13 19:28:45 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 13 Nov 2009 20:28:45 +0100 Subject: Identifying remaining core font users In-Reply-To: <200911132108.31082.ville.skytta@iki.fi> References: <1257941463.841.37.camel@arekh.okg> <20091113115819.GA11955@amd.home.annexia.org> <1258119327.19405.2.camel@arekh.okg> <200911132108.31082.ville.skytta@iki.fi> Message-ID: <1258140525.25528.1.camel@arekh.okg> Le vendredi 13 novembre 2009 ? 21:08 +0200, Ville Skytt? a ?crit : > On Friday 13 November 2009, Nicolas Mailhot wrote: > > Le vendredi 13 novembre 2009 ? 11:58 +0000, Richard W.M. Jones a ?crit : > > > > Nicolas, if possible next time please give the package maintainer > > > (ie. FAS username) next to each package in the list. Otherwise it's > > > harder to tell which packages I should look at. > > > > Last time I asked how to do this the answer was "just rewrite your > > script in python". Since I have other things to do, it won't happen. > > Check out /usr/bin/fedoradev-pkgowners in the fedora-packager package. Oh, here goes my reason not to do it. Thanks for the tip! -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ndbecker2 at gmail.com Fri Nov 13 19:35:55 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 13 Nov 2009 14:35:55 -0500 Subject: texlive 2009 f11 info conflict Message-ID: Transaction Check Error: file /usr/share/info/dir from install of texlive-kpathsea- doc-2009-2.15842.fc12.noarch conflicts with file from package info-4.13a-4.fc11.x86_64 file /usr/share/info/kpathsea.info.gz from install of texlive-kpathsea- doc-2009-2.15842.fc12.noarch conflicts with file from package kpathsea-2007-46.fc11.x86_64 From jkeating at j2solutions.net Fri Nov 13 20:22:17 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 13 Nov 2009 12:22:17 -0800 Subject: [Fwd: Meeting (Fedora talk?) to discuss no frozen rawhide] Message-ID: <1258143737.15679.72.camel@localhost.localdomain> Realized I should post this here, for transparency and all. Anybody is welcome to join once we pick a time/place, but I would urge only those that are willing to do some work come along. We'll summarize the output for others who just wish to be informed. -------- Forwarded Message -------- From: Jesse Keating To: rel-eng at lists.fedoraproject.org Subject: Meeting (Fedora talk?) to discuss no frozen rawhide Date: Fri, 13 Nov 2009 11:23:20 -0800 Now that 12 is in the can, we need to start talking about 13, and how no frozen rawhide comes into play. I'd like to set aside some time Wed or later to have a Fedora talk + gobby call where we can review the proposal, see where we are with it, and walk through the Fedora 13 development cycle in light of the proposal, so that we can outline where work needs to be done and deadlines for that work. I currently have no meetings scheduled for Wed the 18th, so I'm available from 1700 UTC to 2300 UTC. _______________________________________________ rel-eng mailing list rel-eng at lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/rel-eng -- 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: 198 bytes Desc: This is a digitally signed message part URL: From qdlacz at gmail.com Fri Nov 13 21:07:30 2009 From: qdlacz at gmail.com (Krzesimir Nowak) Date: Fri, 13 Nov 2009 22:07:30 +0100 Subject: New package for F-12 Message-ID: <1258146451.4934.8.camel@fiodor> Hi, is it allowed to get new package into F-12 by standard "make tag, make build, make update" workflow? Or rather should I file a ticket to FESCO, since F-12 is in some freeze? I have my package approved and got CVS module already[1]. It is my first time to push a package to frozen branch. Thanks for help, Krzesimir [1] https://bugzilla.redhat.com/show_bug.cgi?id=527241 From ikem.krueger at googlemail.com Fri Nov 13 21:11:36 2009 From: ikem.krueger at googlemail.com (Ikem Krueger) Date: Fri, 13 Nov 2009 21:11:36 +0000 Subject: [Fwd: Meeting (Fedora talk?) to discuss no frozen rawhide] In-Reply-To: <1258143737.15679.72.camel@localhost.localdomain> References: <1258143737.15679.72.camel@localhost.localdomain> Message-ID: Is this the place where we talk about new features? From ikem.krueger at googlemail.com Fri Nov 13 21:13:20 2009 From: ikem.krueger at googlemail.com (Ikem Krueger) Date: Fri, 13 Nov 2009 21:13:20 +0000 Subject: Roopesh's Birthday Calendar In-Reply-To: <1019898453.465571258111293498.JavaMail.batch@lpc04> References: <1019898453.465571258111293498.JavaMail.batch@lpc04> Message-ID: > Please click on the link below and enter your birthday for me. ?I am creating a birthday calendar for myself. ?Don't worry, it'll take less than a minute (and you don't have to enter your year of birth). Spam? o.O From cdahlin at redhat.com Fri Nov 13 21:18:41 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Fri, 13 Nov 2009 16:18:41 -0500 Subject: Roopesh's Birthday Calendar In-Reply-To: References: <1019898453.465571258111293498.JavaMail.batch@lpc04> Message-ID: <4AFDCD31.4030206@redhat.com> On 11/13/2009 04:13 PM, Ikem Krueger wrote: >> Please click on the link below and enter your birthday for me. I am creating a birthday calendar for myself. Don't worry, it'll take less than a minute (and you don't have to enter your year of birth). > > Spam? o.O > Or he just loves us. --CJD From ian at ianweller.org Fri Nov 13 21:25:30 2009 From: ian at ianweller.org (Ian Weller) Date: Fri, 13 Nov 2009 15:25:30 -0600 Subject: New package for F-12 In-Reply-To: <1258146451.4934.8.camel@fiodor> References: <1258146451.4934.8.camel@fiodor> Message-ID: <20091113212530.GA30676@hovercraft.mobile.ianweller.org> On Fri, Nov 13, 2009 at 10:07:30PM +0100, Krzesimir Nowak wrote: > is it allowed to get new package into F-12 by standard "make tag, make > build, make update" workflow? Or rather should I file a ticket to FESCO, > since F-12 is in some freeze? I have my package approved and got CVS > module already[1]. It is my first time to push a package to frozen > branch. > You should create it as a zero-day update in Bodhi for Fedora 12. -- Ian Weller "Why, a four-year-old could understand this report. Find me a four-year-old child. I can't make head or tail out of it." -- Groucho Marx, "Duck Soup" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From ndbecker2 at gmail.com Fri Nov 13 23:52:33 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 13 Nov 2009 18:52:33 -0500 Subject: Fedora 12 staged for mirrors, rawhide moving on soon References: <1258066348.2477.44.camel@localhost.localdomain> <4AFCA3D3.80005@zytor.com> <1258087936.15679.2.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > On Thu, 2009-11-12 at 16:09 -0800, H. Peter Anvin wrote: >> For heaven's sake, no! >> >> Don't you realize this means a ton of *users* will start to bog down the >> mirrors before the whole data set has propagated through the network? > > I'm not sure what you're expecting, but users will only be able to get > to the Everything tree, which is nearly 100% hardlinks into the > development/ tree. There are no isos, no install images, nothing but > rpms and repodata. They will not be able to get to the isos which are > behind locked dirs. > So, can I do preupgrade now (I have plenty of /boot)? From a.badger at gmail.com Fri Nov 13 23:59:46 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 13 Nov 2009 15:59:46 -0800 Subject: Identifying remaining core font users In-Reply-To: <20091113153614.GA13216@amd.home.annexia.org> References: <1257941463.841.37.camel@arekh.okg> <20091112214723.GA3841@free.fr> <1258065506.7664.9.camel@arekh.okg> <20091113115819.GA11955@amd.home.annexia.org> <1258119327.19405.2.camel@arekh.okg> <20091113153614.GA13216@amd.home.annexia.org> Message-ID: <20091113235946.GP25960@clingman.lan> On Fri, Nov 13, 2009 at 03:36:14PM +0000, Richard W.M. Jones wrote: > > I'm no fan of Python either, but there is a fairly simple JSON API to > the package database. eg: > > wget -O ocaml.json 'https://admin.fedoraproject.org/pkgdb/packages/name/ocaml?tg_format=json' > > which gave me a huge JSON-format file which did contain my FAS > username in the field packageListings[0].people[0].username, see: > > http://www.annexia.org/tmp/ocaml.json.txt > If you're going to use this URL, note that you can also filter the data returned by collection and release. For instance, if you only want to get information about the devel branch: wget -O ocaml.json 'https://admin.fedoraproject.org/pkgdb/packages/name/ocaml/Fedora/devel?tg_format=json' -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From tonynelson at georgeanelson.com Sat Nov 14 02:19:39 2009 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Fri, 13 Nov 2009 21:19:39 -0500 Subject: Roopesh's Birthday Calendar In-Reply-To: (from ikem.krueger@googlemail.com on Fri Nov 13 16:13:20 2009) Message-ID: <1258165179.3059.1@localhost.localdomain> On 09-11-13 16:13:20, Ikem Krueger wrote: > > Please click on the link below and enter your birthday for me. ?I > am creating a birthday calendar for myself. ?Don't worry, it'll take > less than a minute (and you don't have to enter your year of birth). > > Spam? o.O Phishing. -- ____________________________________________________________________ TonyN.:' ' From kevin.kofler at chello.at Sat Nov 14 04:08:12 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 14 Nov 2009 05:08:12 +0100 Subject: New package for F-12 References: <1258146451.4934.8.camel@fiodor> Message-ID: Krzesimir Nowak wrote: > is it allowed to get new package into F-12 by standard "make tag, make > build, make update" workflow? Yes, it's even the only way as it is no longer possible to get the package into the F12 release itself (it's too late for that, the release is already in the process of being mirrored). > Or rather should I file a ticket to FESCO, since F-12 is in some freeze? That would be rel-eng, not FESCo, but it's too late for a freeze break anyway, you have to file an update instead. Kevin Kofler From sundaram at fedoraproject.org Sat Nov 14 06:23:00 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 14 Nov 2009 11:53:00 +0530 Subject: Fedora 12 staged for mirrors, rawhide moving on soon In-Reply-To: References: <1258066348.2477.44.camel@localhost.localdomain> <4AFCA3D3.80005@zytor.com> <1258087936.15679.2.camel@localhost.localdomain> Message-ID: <4AFE4CC4.206@fedoraproject.org> On 11/14/2009 05:22 AM, Neal Becker wrote: > Jesse Keating wrote: > >> On Thu, 2009-11-12 at 16:09 -0800, H. Peter Anvin wrote: >>> For heaven's sake, no! >>> >>> Don't you realize this means a ton of *users* will start to bog down the >>> mirrors before the whole data set has propagated through the network? >> >> I'm not sure what you're expecting, but users will only be able to get >> to the Everything tree, which is nearly 100% hardlinks into the >> development/ tree. There are no isos, no install images, nothing but >> rpms and repodata. They will not be able to get to the isos which are >> behind locked dirs. >> > > So, can I do preupgrade now (I have plenty of /boot)? Yes. As always, having a backup of your data is a good thing. Rahul From opensource at till.name Sat Nov 14 10:41:57 2009 From: opensource at till.name (Till Maas) Date: Sat, 14 Nov 2009 11:41:57 +0100 Subject: New package for F-12 In-Reply-To: <20091113212530.GA30676@hovercraft.mobile.ianweller.org> References: <1258146451.4934.8.camel@fiodor> <20091113212530.GA30676@hovercraft.mobile.ianweller.org> Message-ID: <20091114104157.GA4814@genius.kawo2.rwth-aachen.de> On Fri, Nov 13, 2009 at 03:25:30PM -0600, Ian Weller wrote: > On Fri, Nov 13, 2009 at 10:07:30PM +0100, Krzesimir Nowak wrote: > > is it allowed to get new package into F-12 by standard "make tag, make > > build, make update" workflow? Or rather should I file a ticket to FESCO, > > since F-12 is in some freeze? I have my package approved and got CVS > > module already[1]. It is my first time to push a package to frozen > > branch. > > > You should create it as a zero-day update in Bodhi for Fedora 12. And this is the "make tag build update" workflow. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From sundaram at fedoraproject.org Sat Nov 14 10:42:50 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 14 Nov 2009 16:12:50 +0530 Subject: [Fwd: Meeting (Fedora talk?) to discuss no frozen rawhide] In-Reply-To: References: <1258143737.15679.72.camel@localhost.localdomain> Message-ID: <4AFE89AA.3040502@fedoraproject.org> On 11/14/2009 02:41 AM, Ikem Krueger wrote: > Is this the place where we talk about new features? What new features are you referring to? Perhaps you should start a new thread on that. Rahul From oget.fedora at gmail.com Sat Nov 14 10:59:20 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Sat, 14 Nov 2009 05:59:20 -0500 Subject: ilbsndfile update! Message-ID: Hi folks, After getting okays from a few folks I decided to fix the long standing libsndfile bugs. One of these was a request [1] to split the utilities that come with libsndfile into a utils subpackage. I did this only for F-13. Since libsndfile is used by so many other software, it is impractical for me to check all of these software to see if any of them depends on these command line utilities. If you have a package that depends on libsndfile, it would be good to check whether it uses these utilities. Then you'll need to require libsndfile-utils directly. If your package just needs the library there is nothing to worry about. Again, the utils split is only made in F-13. Other than that, libsndfile is updated to 1.0.20 in F-10+. Also, now it has the libvorbis support enabled. Cheers, oget [1] https://bugzilla.redhat.com/show_bug.cgi?id=515172 From pasik at iki.fi Sat Nov 14 13:52:50 2009 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Sat, 14 Nov 2009 15:52:50 +0200 Subject: Fedora 12 has gone gold In-Reply-To: <1257816570.2468.32.camel@localhost.localdomain> References: <1257816570.2468.32.camel@localhost.localdomain> Message-ID: <20091114135250.GU16033@reaktio.net> On Mon, Nov 09, 2009 at 05:29:30PM -0800, Jesse Keating wrote: > We have just completed our Go / No Go meeting for Fedora 12 and have > reached the decision to Go. Fedora 12's package set is golden and we're > ready to stage things for shipping. Great work all around, I'm very > proud of this release. I'm sure there will be more back patting and > hand shaking to come, but Will Woods would like to remind everybody that > it's just 11 weeks until Fedora 13 Alpha freeze! > Hmm.. so I guess this means Fedora 12 will ship with 2.6.31.5 kernel? 2.6.31.6 would have had some important Xen PV guest bugfixes: https://bugzilla.redhat.com/show_bug.cgi?id=533730 -- Pasi From sundaram at fedoraproject.org Sat Nov 14 13:51:13 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 14 Nov 2009 19:21:13 +0530 Subject: Fedora 12 has gone gold In-Reply-To: <20091114135250.GU16033@reaktio.net> References: <1257816570.2468.32.camel@localhost.localdomain> <20091114135250.GU16033@reaktio.net> Message-ID: <4AFEB5D1.7070301@fedoraproject.org> On 11/14/2009 07:22 PM, Pasi K?rkk?inen wrote: > On Mon, Nov 09, 2009 at 05:29:30PM -0800, Jesse Keating wrote: >> We have just completed our Go / No Go meeting for Fedora 12 and have >> reached the decision to Go. Fedora 12's package set is golden and we're >> ready to stage things for shipping. Great work all around, I'm very >> proud of this release. I'm sure there will be more back patting and >> hand shaking to come, but Will Woods would like to remind everybody that >> it's just 11 weeks until Fedora 13 Alpha freeze! >> > > Hmm.. so I guess this means Fedora 12 will ship with 2.6.31.5 kernel? > > 2.6.31.6 would have had some important Xen PV guest bugfixes: > https://bugzilla.redhat.com/show_bug.cgi?id=533730 I am sure, we will get kernel updates post-release due to security reasons anyway. Rahul From pasik at iki.fi Sat Nov 14 13:58:25 2009 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Sat, 14 Nov 2009 15:58:25 +0200 Subject: Fedora 12 has gone gold In-Reply-To: <4AFEB5D1.7070301@fedoraproject.org> References: <1257816570.2468.32.camel@localhost.localdomain> <20091114135250.GU16033@reaktio.net> <4AFEB5D1.7070301@fedoraproject.org> Message-ID: <20091114135825.GV16033@reaktio.net> On Sat, Nov 14, 2009 at 07:21:13PM +0530, Rahul Sundaram wrote: > On 11/14/2009 07:22 PM, Pasi K?rkk?inen wrote: > > On Mon, Nov 09, 2009 at 05:29:30PM -0800, Jesse Keating wrote: > >> We have just completed our Go / No Go meeting for Fedora 12 and have > >> reached the decision to Go. Fedora 12's package set is golden and we're > >> ready to stage things for shipping. Great work all around, I'm very > >> proud of this release. I'm sure there will be more back patting and > >> hand shaking to come, but Will Woods would like to remind everybody that > >> it's just 11 weeks until Fedora 13 Alpha freeze! > >> > > > > Hmm.. so I guess this means Fedora 12 will ship with 2.6.31.5 kernel? > > > > 2.6.31.6 would have had some important Xen PV guest bugfixes: > > https://bugzilla.redhat.com/show_bug.cgi?id=533730 > > I am sure, we will get kernel updates post-release due to security > reasons anyway. > Yeah.. that I'm aware of. It just means the GA kernel (and thus installer) won't boot on Intel Nehalem CPUs. Oh well.. bad timing with that bug/patch. -- Pasi From jfontain at free.fr Sat Nov 14 13:59:45 2009 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Sat, 14 Nov 2009 14:59:45 +0100 Subject: Fedora 12 has gone gold In-Reply-To: <20091114135250.GU16033@reaktio.net> References: <1257816570.2468.32.camel@localhost.localdomain> <20091114135250.GU16033@reaktio.net> Message-ID: <4AFEB7D1.2040503@free.fr> On 11/14/2009 02:52 PM, Pasi K?rkk?inen wrote: > On Mon, Nov 09, 2009 at 05:29:30PM -0800, Jesse Keating wrote: > >> We have just completed our Go / No Go meeting for Fedora 12 and have >> reached the decision to Go. Fedora 12's package set is golden and we're >> ready to stage things for shipping. Great work all around, I'm very >> proud of this release. Does that mean that preupgrade with 200 M /boot works? Thanks, Jean-Luc From ndbecker2 at gmail.com Sat Nov 14 14:10:05 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 14 Nov 2009 09:10:05 -0500 Subject: Fedora 12 staged for mirrors, rawhide moving on soon References: <1258066348.2477.44.camel@localhost.localdomain> <4AFCA3D3.80005@zytor.com> <1258087936.15679.2.camel@localhost.localdomain> <4AFE4CC4.206@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > On 11/14/2009 05:22 AM, Neal Becker wrote: >> Jesse Keating wrote: >> >>> On Thu, 2009-11-12 at 16:09 -0800, H. Peter Anvin wrote: >>>> For heaven's sake, no! >>>> >>>> Don't you realize this means a ton of *users* will start to bog down >>>> the mirrors before the whole data set has propagated through the >>>> network? >>> >>> I'm not sure what you're expecting, but users will only be able to get >>> to the Everything tree, which is nearly 100% hardlinks into the >>> development/ tree. There are no isos, no install images, nothing but >>> rpms and repodata. They will not be able to get to the isos which are >>> behind locked dirs. >>> >> >> So, can I do preupgrade now (I have plenty of /boot)? > > Yes. As always, having a backup of your data is a good thing. > > Rahul > Preupgrade is not showing f12, only choice is rawhide. From sundaram at fedoraproject.org Sat Nov 14 14:23:52 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 14 Nov 2009 19:53:52 +0530 Subject: Fedora 12 has gone gold In-Reply-To: <4AFEB7D1.2040503@free.fr> References: <1257816570.2468.32.camel@localhost.localdomain> <20091114135250.GU16033@reaktio.net> <4AFEB7D1.2040503@free.fr> Message-ID: <4AFEBD78.7050401@fedoraproject.org> On 11/14/2009 07:29 PM, Jean-Luc Fontaine wrote: > On 11/14/2009 02:52 PM, Pasi K?rkk?inen wrote: >> On Mon, Nov 09, 2009 at 05:29:30PM -0800, Jesse Keating wrote: >> >>> We have just completed our Go / No Go meeting for Fedora 12 and have >>> reached the decision to Go. Fedora 12's package set is golden and we're >>> ready to stage things for shipping. Great work all around, I'm very >>> proud of this release. > Does that mean that preupgrade with 200 M /boot works? This was a problem noticed post-release and workarounded by a PackageKit push that disables upgrade release notifications on the desktop. It is possible to run preupgrade manually if you clean up older kernels and find enough room. Rahul From sundaram at fedoraproject.org Sat Nov 14 14:24:43 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 14 Nov 2009 19:54:43 +0530 Subject: Fedora 12 staged for mirrors, rawhide moving on soon In-Reply-To: References: <1258066348.2477.44.camel@localhost.localdomain> <4AFCA3D3.80005@zytor.com> <1258087936.15679.2.camel@localhost.localdomain> <4AFE4CC4.206@fedoraproject.org> Message-ID: <4AFEBDAB.3050005@fedoraproject.org> On 11/14/2009 07:40 PM, Neal Becker wrote: >> > > Preupgrade is not showing f12, only choice is rawhide. Yes but Rawhide is still Fedora 12 now. So you have a small window to upgrade. Rahul From tomek at pipebreaker.pl Sat Nov 14 14:34:09 2009 From: tomek at pipebreaker.pl (Tomasz Torcz) Date: Sat, 14 Nov 2009 15:34:09 +0100 Subject: Fedora 12 has gone gold In-Reply-To: <20091114135825.GV16033@reaktio.net> References: <1257816570.2468.32.camel@localhost.localdomain> <20091114135250.GU16033@reaktio.net> <4AFEB5D1.7070301@fedoraproject.org> <20091114135825.GV16033@reaktio.net> Message-ID: <20091114143409.GA5254@mother.pipebreaker.pl> On Sat, Nov 14, 2009 at 03:58:25PM +0200, Pasi K?rkk?inen wrote: > On Sat, Nov 14, 2009 at 07:21:13PM +0530, Rahul Sundaram wrote: > > On 11/14/2009 07:22 PM, Pasi K?rkk?inen wrote: > > > On Mon, Nov 09, 2009 at 05:29:30PM -0800, Jesse Keating wrote: > > >> We have just completed our Go / No Go meeting for Fedora 12 and have > > >> reached the decision to Go. Fedora 12's package set is golden and we're > > >> ready to stage things for shipping. Great work all around, I'm very > > >> proud of this release. I'm sure there will be more back patting and > > >> hand shaking to come, but Will Woods would like to remind everybody that > > >> it's just 11 weeks until Fedora 13 Alpha freeze! > > >> > > > > > > Hmm.. so I guess this means Fedora 12 will ship with 2.6.31.5 kernel? > > > > > > 2.6.31.6 would have had some important Xen PV guest bugfixes: > > > https://bugzilla.redhat.com/show_bug.cgi?id=533730 > > > > I am sure, we will get kernel updates post-release due to security > > reasons anyway. > > > > Yeah.. that I'm aware of. It just means the GA kernel (and thus > installer) won't boot on Intel Nehalem CPUs. Judging from the bug report, it will only fail to boot when used over Xen. Which I believe represents small minority of Fedora users. -- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzichubg at chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 238 bytes Desc: not available URL: From ndbecker2 at gmail.com Sat Nov 14 14:47:56 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 14 Nov 2009 09:47:56 -0500 Subject: Fedora 12 staged for mirrors, rawhide moving on soon References: <1258066348.2477.44.camel@localhost.localdomain> <4AFCA3D3.80005@zytor.com> <1258087936.15679.2.camel@localhost.localdomain> <4AFE4CC4.206@fedoraproject.org> <4AFEBDAB.3050005@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > On 11/14/2009 07:40 PM, Neal Becker wrote: > >>> >> >> Preupgrade is not showing f12, only choice is rawhide. > > Yes but Rawhide is still Fedora 12 now. So you have a small window to > upgrade. > > Rahul > Looks like it didn't work, only ran for a moment. Offers to reboot, but didn't seem to download any packages: sudo preupgrade /usr/lib/python2.6/site-packages/yum/__init__.py:203: UserWarning: Use .preconf instead of passing args to _getConfig warnings.warn('Use .preconf instead of passing args to _getConfig') Loaded plugins: blacklist, dellsysidplugin2, refresh-packagekit, whiteout preupgrade (mirrorlist) url: http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide&arch=$basearch now: http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide&arch=x86_64 preupgrade-rpmfusion-free-rawhide (mirrorlist) url: http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora- rawhide&arch=x86_64 now: http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora- rawhide&arch=x86_64 preupgrade-rpmfusion-nonfree-rawhide (mirrorlist) url: http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora- rawhide&arch=x86_64 now: http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora- rawhide&arch=x86_64 Fetched treeinfo from ftp://fedora.bu.edu/development/x86_64/os//.treeinfo treeinfo timestamp: Tue Apr 7 06:29:33 2009 rpmfusion-nonfree-release-11.90-1.noarch from preupgrade-rpmfusion-nonfree- rawhide has depsolving problems --> Missing Dependency: system-release >= 11.90 is needed by package rpmfusion-nonfree-release-11.90-1.noarch (preupgrade-rpmfusion-nonfree- rawhide) rpmfusion-free-release-11.90-1.noarch from preupgrade-rpmfusion-free-rawhide has depsolving problems --> Missing Dependency: system-release >= 11.90 is needed by package rpmfusion-free-release-11.90-1.noarch (preupgrade-rpmfusion-free-rawhide) Downloading 1.8MB Available disk space for /var/cache/yum/preupgrade: 1.1TB Upgrade requires 500.0MB Available disk space for /usr: 1.1TB Generating metadata for preupgrade repo DEBUG /sbin/grubby --title="Upgrade to Rawhide" --remove- kernel="/boot/upgrade/vmlinuz" --add-kernel="/boot/upgrade/vmlinuz" -- initrd="/boot/upgrade/initrd.img" --args="preupgrade repo=hd::/var/cache/yum/preupgrade stage2=hd:UUID=9a7b4349-d278-4287- b6a9-4c4949e97730:/upgrade/install.img ks=hd:UUID=9a7b4349-d278-4287- b6a9-4c4949e97730:/upgrade/ks.cfg" From sundaram at fedoraproject.org Sat Nov 14 14:50:36 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 14 Nov 2009 20:20:36 +0530 Subject: Fedora 12 staged for mirrors, rawhide moving on soon In-Reply-To: References: <1258066348.2477.44.camel@localhost.localdomain> <4AFCA3D3.80005@zytor.com> <1258087936.15679.2.camel@localhost.localdomain> <4AFE4CC4.206@fedoraproject.org> <4AFEBDAB.3050005@fedoraproject.org> Message-ID: <4AFEC3BC.9080607@fedoraproject.org> On 11/14/2009 08:17 PM, Neal Becker wrote: > rpmfusion-free-release-11.90-1.noarch from preupgrade-rpmfusion-free-rawhide > has depsolving problems > --> Missing Dependency: system-release >= 11.90 is needed by package > rpmfusion-free-release-11.90-1.noarch (preupgrade-rpmfusion-free-rawhide) Remove the rpmfusion-*-release packages and try again. I would prefer if you post a new thread on fedora-test list if you want to continue this discussion. Rahul From rjones at redhat.com Sat Nov 14 15:07:50 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 14 Nov 2009 15:07:50 +0000 Subject: glXUseXFont (was: Re: Identifying remaining core font users) In-Reply-To: <1258130562.30821.1.camel@arekh.okg> References: <1257941463.841.37.camel@arekh.okg> <1258130562.30821.1.camel@arekh.okg> Message-ID: <20091114150750.GA18116@amd.home.annexia.org> On Fri, Nov 13, 2009 at 05:42:42PM +0100, Nicolas Mailhot wrote: > ? ocaml-lablgl-0:1.04-2.fc12 > ? /usr/lib64/ocaml/stublibs/dlltogl.so This one uses a single reference to glXUseXFont to turn an X core font into a GL display list. There is one oblique reference to doing this manually using Fontconfig and Freetype. It doesn't look very easy: http://lists.cairographics.org/archives/cairo/2004-January/000945.html Any ideas on this? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From paul at city-fan.org Sat Nov 14 16:12:49 2009 From: paul at city-fan.org (Paul Howarth) Date: Sat, 14 Nov 2009 16:12:49 +0000 Subject: Broken dependencies script at it again Message-ID: <20091114161249.55838f88@zion.intra.city-fan.org> Please make it stop. milter-regex-1.7-6.fc12.ppc requires /bin/sh I guess this is happening because of dropping ppc/ppc64 as primary arches? ISTR the last time the dep checker went off on a mailbombing session it was suggested that it checks for broken deps against obvious things like /bin/sh and declared itself insane, sparing us all the pointless mails? Paul. From tgl at redhat.com Sat Nov 14 16:35:47 2009 From: tgl at redhat.com (Tom Lane) Date: Sat, 14 Nov 2009 11:35:47 -0500 Subject: Broken dependencies script at it again In-Reply-To: <20091114161249.55838f88@zion.intra.city-fan.org> References: <20091114161249.55838f88@zion.intra.city-fan.org> Message-ID: <14291.1258216547@sss.pgh.pa.us> Paul Howarth writes: > Please make it stop. +1 > ISTR the last time the dep checker went off on a mailbombing session it > was suggested that it checks for broken deps against obvious things > like /bin/sh and declared itself insane, sparing us all the pointless > mails? /bin/sh and libc.so both ought to be trigger points for an I'm-not-sane kill switch. Or maybe reverse the logic: if you fail to find *any* of a package's dependencies, you're probably broken and should shut up. regards, tom lane From nicolas.mailhot at laposte.net Sat Nov 14 17:13:40 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 14 Nov 2009 18:13:40 +0100 Subject: Broken dependencies script at it again In-Reply-To: <20091114161249.55838f88@zion.intra.city-fan.org> References: <20091114161249.55838f88@zion.intra.city-fan.org> Message-ID: <1258218820.5250.0.camel@arekh.okg> Le samedi 14 novembre 2009 ? 16:12 +0000, Paul Howarth a ?crit : > Please make it stop. > > milter-regex-1.7-6.fc12.ppc requires /bin/sh > > I guess this is happening because of dropping ppc/ppc64 as primary > arches? I think pretty much everyone will be mailbombed this way. Seems /bin/sh was dropped from provides, but the packages have not been rebuilt not to require it -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rc040203 at freenet.de Sat Nov 14 18:31:46 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 14 Nov 2009 19:31:46 +0100 Subject: Broken dependencies script at it again In-Reply-To: <20091114161249.55838f88@zion.intra.city-fan.org> References: <20091114161249.55838f88@zion.intra.city-fan.org> Message-ID: <4AFEF792.3000100@freenet.de> On 11/14/2009 05:12 PM, Paul Howarth wrote: > Please make it stop. +1 ... ... so far, I've received ca. 1200 of these mails and the figure is still growing by the minute. Ralf From nathanael at gnat.ca Sat Nov 14 18:44:39 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Sat, 14 Nov 2009 11:44:39 -0700 Subject: Review Request... Message-ID: <4AFEFA97.8040907@gnat.ca> Hello, I just submitted my first package for review. I'm not sure how to mark it as need sponsor. I've created my FAS account and signed the cla. I've started a scratch build to see how it works on the other arches. I've compiled locally on f12 for x86_64. Do I need to do anything else to mark it as need sponsor? Otherwise I assume I just wait for feedback via the bugzilla entry correct? Thanks, -- Nathanael Noblet From henriquecsj at gmail.com Sat Nov 14 18:52:02 2009 From: henriquecsj at gmail.com (Henrique Junior) Date: Sat, 14 Nov 2009 16:52:02 -0200 Subject: Broken dependencies script at it again In-Reply-To: <4AFEF792.3000100@freenet.de> References: <20091114161249.55838f88@zion.intra.city-fan.org> <4AFEF792.3000100@freenet.de> Message-ID: <4f629b520911141052m6c48964cn67d3523c308b92b5@mail.gmail.com> +1 Henrique "LonelySpooky" Junior http://www.lonelyspooky.com ------------------------------------------------------------- "In a world without walls and fences, who needs windows and gates?!" 2009/11/14 Ralf Corsepius > On 11/14/2009 05:12 PM, Paul Howarth wrote: > >> Please make it stop. >> > > +1 ... > > ... so far, I've received ca. 1200 of these mails and the figure is still > growing by the minute. > > Ralf > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomek at pipebreaker.pl Sat Nov 14 18:52:58 2009 From: tomek at pipebreaker.pl (Tomasz Torcz) Date: Sat, 14 Nov 2009 19:52:58 +0100 Subject: Review Request... In-Reply-To: <4AFEFA97.8040907@gnat.ca> References: <4AFEFA97.8040907@gnat.ca> Message-ID: <20091114185258.GA26510@mother.pipebreaker.pl> On Sat, Nov 14, 2009 at 11:44:39AM -0700, Nathanael D. Noblet wrote: > Hello, > I just submitted my first package for review. I'm not sure how to > mark it as need sponsor. I've created my FAS account and signed the > cla. I've started a scratch build to see how it works on the other > arches. I've compiled locally on f12 for x86_64. > > Do I need to do anything else to mark it as need sponsor? Otherwise You should add you review request as blocker for FE_NEEDSPONSOR bug. It is described in yellow table at http://fedoraproject.org/wiki/PackageMaintainers/Join#Create_Your_Review_Request > I assume I just wait for feedback via the bugzilla entry correct? Basically yes. -- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzichubg at chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML) From qdlacz at gmail.com Sat Nov 14 18:53:38 2009 From: qdlacz at gmail.com (Krzesimir Nowak) Date: Sat, 14 Nov 2009 19:53:38 +0100 Subject: Review Request... In-Reply-To: <4AFEFA97.8040907@gnat.ca> References: <4AFEFA97.8040907@gnat.ca> Message-ID: <1258224818.2181.2.camel@fiodor> On Sat, 2009-11-14 at 11:44 -0700, Nathanael D. Noblet wrote: > Hello, > I just submitted my first package for review. I'm not sure how to > mark it as need sponsor. I've created my FAS account and signed the cla. > I've started a scratch build to see how it works on the other arches. > I've compiled locally on f12 for x86_64. > > Do I need to do anything else to mark it as need sponsor? Otherwise I > assume I just wait for feedback via the bugzilla entry correct? Just mention in your review request that you need sponsoring. Here is detailed document how to join to package maintainers: https://fedoraproject.org/wiki/PackageMaintainers/Join#Create_Your_Review_Request > > Thanks, > -- > Nathanael Noblet > Krzesimir. From mmcgrath at redhat.com Sat Nov 14 21:12:40 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 14 Nov 2009 15:12:40 -0600 (CST) Subject: Broken dependencies script at it again In-Reply-To: <4f629b520911141052m6c48964cn67d3523c308b92b5@mail.gmail.com> References: <20091114161249.55838f88@zion.intra.city-fan.org> <4AFEF792.3000100@freenet.de> <4f629b520911141052m6c48964cn67d3523c308b92b5@mail.gmail.com> Message-ID: On Sat, 14 Nov 2009, Henrique Junior wrote: > +1 > Are people +1'ing getting rid of the broken dependencies script altogether? or +1'ing to predicting the future and stopping it before it breaks? -Mike > Henrique "LonelySpooky" Junior > http://www.lonelyspooky.com > ------------------------------------------------------------- > "In a world without walls and fences, who needs windows and gates?!" > > > 2009/11/14 Ralf Corsepius > On 11/14/2009 05:12 PM, Paul Howarth wrote: > Please make it stop. > > > +1 ... > > ... so far, I've received ca. 1200 of these mails and the figure is still growing by the minute. > > Ralf > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > From rc040203 at freenet.de Sat Nov 14 21:31:25 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 14 Nov 2009 22:31:25 +0100 Subject: Broken dependencies script at it again In-Reply-To: References: <20091114161249.55838f88@zion.intra.city-fan.org> <4AFEF792.3000100@freenet.de> <4f629b520911141052m6c48964cn67d3523c308b92b5@mail.gmail.com> Message-ID: <4AFF21AD.2070202@freenet.de> On 11/14/2009 10:12 PM, Mike McGrath wrote: > On Sat, 14 Nov 2009, Henrique Junior wrote: > >> +1 >> > > Are people +1'ing getting rid of the broken dependencies script > altogether? or +1'ing to predicting the future and stopping it before it > breaks? No, it's raising hands to a) draw attention of those persons who "flipped this switch" this time. b) draw attention of those persons who have the means to take countermeasures against the damage this "flipping the switch" had. c) to draw attention of those persons, who are in charge to supervise those persons who "flipped this switch" this time. Ralf From tgl at redhat.com Sat Nov 14 21:44:37 2009 From: tgl at redhat.com (Tom Lane) Date: Sat, 14 Nov 2009 16:44:37 -0500 Subject: Broken dependencies script at it again In-Reply-To: References: <20091114161249.55838f88@zion.intra.city-fan.org> <4AFEF792.3000100@freenet.de> <4f629b520911141052m6c48964cn67d3523c308b92b5@mail.gmail.com> Message-ID: <19139.1258235077@sss.pgh.pa.us> Mike McGrath writes: > Are people +1'ing getting rid of the broken dependencies script > altogether? or +1'ing to predicting the future and stopping it before it > breaks? I thought the +1's were for putting in some circuit breakers, so that when (not if) it breaks again, it won't spam the entire package maintainer list. We can predict the future to the extent of being sure this will happen again. The thing is useful when it's working, but it will stop being useful if people get conditioned to ignore it. regards, tom lane From mrsam at courier-mta.com Sat Nov 14 21:53:44 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sat, 14 Nov 2009 16:53:44 -0500 Subject: Broken dependencies script at it again References: <20091114161249.55838f88@zion.intra.city-fan.org> <4AFEF792.3000100@freenet.de> <4f629b520911141052m6c48964cn67d3523c308b92b5@mail.gmail.com> <19139.1258235077@sss.pgh.pa.us> Message-ID: Tom Lane writes: > Mike McGrath writes: >> Are people +1'ing getting rid of the broken dependencies script >> altogether? or +1'ing to predicting the future and stopping it before it >> breaks? > > I thought the +1's were for putting in some circuit breakers, so > that when (not if) it breaks again, it won't spam the entire package Proposed circuit breaker: if more than 5% of packages supposedly have broken dependencies. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From steve.traylen at cern.ch Sat Nov 14 22:04:55 2009 From: steve.traylen at cern.ch (Steve Traylen) Date: Sat, 14 Nov 2009 23:04:55 +0100 Subject: Broken dependencies script at it again In-Reply-To: References: <20091114161249.55838f88@zion.intra.city-fan.org> <4AFEF792.3000100@freenet.de> <4f629b520911141052m6c48964cn67d3523c308b92b5@mail.gmail.com> <19139.1258235077@sss.pgh.pa.us> Message-ID: On Sat, Nov 14, 2009 at 10:53 PM, Sam Varshavchik wrote: > Tom Lane writes: > >> Mike McGrath writes: >>> >>> Are people +1'ing getting rid of the broken dependencies script >>> altogether? ?or +1'ing to predicting the future and stopping it before it >>> breaks? >> >> I thought the +1's were for putting in some circuit breakers, so >> that when (not if) it breaks again, it won't spam the entire package > > Proposed circuit breaker: if more than 5% of packages supposedly have broken > dependencies. I would produce a report before sending any mails. A report suming up the occurrence of each missing dependency. Eyeballing the top slots of this list should highlight some obvious things to fix first like the /bin/sh one. You want to avoid reporting global or near global items on a per package basis. > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Steve Traylen From jkeating at j2solutions.net Sat Nov 14 22:06:48 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 14 Nov 2009 14:06:48 -0800 Subject: Broken dependencies script at it again In-Reply-To: References: <20091114161249.55838f88@zion.intra.city-fan.org> <4AFEF792.3000100@freenet.de> <4f629b520911141052m6c48964cn67d3523c308b92b5@mail.gmail.com> <19139.1258235077@sss.pgh.pa.us> Message-ID: <18BA8B5A-57EB-4296-AEF9-211B27A92066@j2solutions.net> On Nov 14, 2009, at 13:53, Sam Varshavchik wrote: > Tom Lane writes: > >> Mike McGrath writes: >>> Are people +1'ing getting rid of the broken dependencies script >>> altogether? or +1'ing to predicting the future and stopping it >>> before it >>> breaks? >> I thought the +1's were for putting in some circuit breakers, so >> that when (not if) it breaks again, it won't spam the entire package > > Proposed circuit breaker: if more than 5% of packages supposedly > have broken dependencies. Sounds reasonable. Accepting patches if you want this done in the new future. -- Jes -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.traylen at cern.ch Sat Nov 14 22:36:27 2009 From: steve.traylen at cern.ch (Steve Traylen) Date: Sat, 14 Nov 2009 23:36:27 +0100 Subject: Broken dependencies script at it again In-Reply-To: <18BA8B5A-57EB-4296-AEF9-211B27A92066@j2solutions.net> References: <20091114161249.55838f88@zion.intra.city-fan.org> <4AFEF792.3000100@freenet.de> <4f629b520911141052m6c48964cn67d3523c308b92b5@mail.gmail.com> <19139.1258235077@sss.pgh.pa.us> <18BA8B5A-57EB-4296-AEF9-211B27A92066@j2solutions.net> Message-ID: On Sat, Nov 14, 2009 at 11:06 PM, Jesse Keating wrote: > > > On Nov 14, 2009, at 13:53, Sam Varshavchik wrote: > > Tom Lane writes: > > Mike McGrath writes: > > Are people +1'ing getting rid of the broken dependencies script > > altogether? ?or +1'ing to predicting the future and stopping it before it > > breaks? > > I thought the +1's were for putting in some circuit breakers, so > > that when (not if) it breaks again, it won't spam the entire package > > Proposed circuit breaker: if more than 5% of packages supposedly have broken > dependencies. > > > Sounds reasonable. Accepting patches if you want this done in the new > future. $ repoclosure -r updates | grep '^ ' | sort | uniq -c | sort -gr | head 167 rtld(GNU_HASH) 130 /sbin/ldconfig 127 libc.so.6(GLIBC_2.2.5)(64bit) 127 libc.so.6()(64bit) 101 /bin/sh on the repo... But this is not the new rawhide (it's updates on its own) repo of course. I'm not sure where that actually is at the moment? Will look at how the rawhide report is created. The results belong in there. > -- > Jes > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Steve Traylen From mmcgrath at redhat.com Sun Nov 15 00:13:32 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 14 Nov 2009 18:13:32 -0600 (CST) Subject: Broken dependencies script at it again In-Reply-To: <18BA8B5A-57EB-4296-AEF9-211B27A92066@j2solutions.net> References: <20091114161249.55838f88@zion.intra.city-fan.org> <4AFEF792.3000100@freenet.de> <4f629b520911141052m6c48964cn67d3523c308b92b5@mail.gmail.com> <19139.1258235077@sss.pgh.pa.us> <18BA8B5A-57EB-4296-AEF9-211B27A92066@j2solutions.net> Message-ID: On Sat, 14 Nov 2009, Jesse Keating wrote: > > > On Nov 14, 2009, at 13:53, Sam Varshavchik wrote: > > Tom Lane writes: > > Mike McGrath writes: > > Are people +1'ing getting rid of the broken dependencies script > > altogether? ?or +1'ing to predicting the future and stopping it before it > > breaks? > > I thought the +1's were for putting in some circuit breakers, so > > that when (not if) it breaks again, it won't spam the entire package > > > Proposed circuit breaker: if more than 5% of packages supposedly have broken dependencies. > > > > Sounds reasonable. Accepting patches if you want this done in the new future.? > Anyone on the list irritated enough to work on these scripts or just irritated enough to complain via email and let it be someone else's problem? -Mike From ikem.krueger at googlemail.com Sun Nov 15 02:53:42 2009 From: ikem.krueger at googlemail.com (Ikem Krueger) Date: Sun, 15 Nov 2009 02:53:42 +0000 Subject: F12-Beta-i686-Live has some bugs Message-ID: I booted from cd and I was left with a black screen. When I switched to a console, I got: render error detected, EIR: 0x00000010 [drm:i915_handle_error] *ERROR* EIR stuck: 0x00000010, masking I guess the kernel is guessing my graphiccard wrong. Usually I use "i810" or "intel" in Xorg. Workaround is to boot with "nomodeset". (That isn't even working with the LXDE Spin. :S) --- When I boot without "rhgb", I got several times: WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. And at the end: plymouthd: ply-event-loop.c:729: ply_event_loop_stop_watching_fd: Assertion 'watch != ((void *)0)' failed. -- Btw, Where went the options for "testing ram", "testing cd/dvd", "failsafe"? o.O From alexl at users.sourceforge.net Sun Nov 15 05:52:09 2009 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Sun, 15 Nov 2009 00:52:09 -0500 Subject: F-12 regression: new HAL completely breaks Palm-synching Message-ID: Hi there, Unfortunately the new HAL on F-12 removed the handling for ACLs (apparently this is now done by udev >= 145), but this now has the side-effect of removing the fdi files that were being used for Palm devices, resulting in breaking of all Palm functionality in Fedora, as detailed here: https://bugzilla.redhat.com/show_bug.cgi?id=529259 My question is, as a neophyte wrt udev/hal internal logic, where should this logic correctly reside? The appropriate functionality appears to have moved to the udev package as implied by the changelog entry in hal: * Wed Jul 22 2009 David Zeuthen - 0.5.12-26.20090226git.4 - Disable ConsoleKit+PolicyKit support and lock down most interfaces with at_console - Disable ACL management, this is now handled by udev >= 145 but it doesn't appear to be there at least with respect to Palm devices. At one point we actually had the logic in the pilot-link package, but we removed it when it was upstreamed in hal, now it's moved again. :( I have only just upgraded to F-12, and apparently the main pilot-link owner (I'm just a co-maintainer) has not had a chance to test this on F-12 otherwise it would have been caught earlier in the release cycle. This is a fairly major regression for the user experience of any Palm user (yes there are still many of us!) on F-12, so I would like to get it fixed ASAP (at the very least for a 0-day or 1-day update if possible). If necessary I'm happy re-enable it in pilot-link only (if that's possible) until upstream is ready to push an update, but I'd like to know fairly soon so that I don't conflict on a possible udev/hal update that does the same thing. Alex From maillist at diffingo.com Sun Nov 15 07:41:21 2009 From: maillist at diffingo.com (Stewart Adam) Date: Sun, 15 Nov 2009 02:41:21 -0500 Subject: Broken dependencies script at it again In-Reply-To: References: <20091114161249.55838f88@zion.intra.city-fan.org> <4AFEF792.3000100@freenet.de> <4f629b520911141052m6c48964cn67d3523c308b92b5@mail.gmail.com> <19139.1258235077@sss.pgh.pa.us> <18BA8B5A-57EB-4296-AEF9-211B27A92066@j2solutions.net> Message-ID: <4AFFB0A1.3020907@diffingo.com> On 2009/11/14 7:13 PM, Mike McGrath wrote: > > Anyone on the list irritated enough to work on these scripts or just > irritated enough to complain via email and let it be someone else's > problem? > > -Mike > Where can we find a copy those scripts? I would be happy to take a look and see if we can implement a simple "do not send any mail if" blacklist for the broken deps. Stewart From kevin.kofler at chello.at Sun Nov 15 07:49:01 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 15 Nov 2009 08:49:01 +0100 Subject: F-12 regression: new HAL completely breaks Palm-synching References: Message-ID: Alex Lancaster wrote: > My question is, as a neophyte wrt udev/hal internal logic, where should > this logic correctly reside? udev rules. See: https://bugzilla.redhat.com/show_bug.cgi?id=529259#c15 for details. Kevin Kofler From mschwendt at gmail.com Sun Nov 15 08:38:52 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 15 Nov 2009 09:38:52 +0100 Subject: Broken dependencies script at it again In-Reply-To: <4AFFB0A1.3020907@diffingo.com> References: <20091114161249.55838f88@zion.intra.city-fan.org> <4AFEF792.3000100@freenet.de> <4f629b520911141052m6c48964cn67d3523c308b92b5@mail.gmail.com> <19139.1258235077@sss.pgh.pa.us> <18BA8B5A-57EB-4296-AEF9-211B27A92066@j2solutions.net> <4AFFB0A1.3020907@diffingo.com> Message-ID: <20091115093852.70d86482@faldor.intranet> On Sun, 15 Nov 2009 02:41:21 -0500, Stewart wrote: > Where can we find a copy those scripts? I would be happy to take a look and > see if we can implement a simple "do not send any mail if" blacklist for the > broken deps. repoclosure is part of the "yum-utils" package. The rawhide broken deps mail is created by the tools in the "mash" package. From mschwendt at gmail.com Sun Nov 15 08:40:36 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 15 Nov 2009 09:40:36 +0100 Subject: Broken dependencies script at it again In-Reply-To: References: <20091114161249.55838f88@zion.intra.city-fan.org> <4AFEF792.3000100@freenet.de> <4f629b520911141052m6c48964cn67d3523c308b92b5@mail.gmail.com> <19139.1258235077@sss.pgh.pa.us> <18BA8B5A-57EB-4296-AEF9-211B27A92066@j2solutions.net> Message-ID: <20091115094036.583513d6@faldor.intranet> On Sat, 14 Nov 2009 23:36:27 +0100, Steve wrote: > $ repoclosure -r updates | grep '^ ' | sort | uniq -c | sort -gr | head > 167 rtld(GNU_HASH) > 130 /sbin/ldconfig > 127 libc.so.6(GLIBC_2.2.5)(64bit) > 127 libc.so.6()(64bit) > 101 /bin/sh > > on the repo... But this is not the new rawhide (it's updates on its > own) repo of course. I'm not sure where that actually is at the moment? Bad choice of -r options. "updates" depend on base packages. Either add the missing repos or run repoclosure without -r options to use default yum repo config. From braden at endoframe.com Sun Nov 15 08:46:01 2009 From: braden at endoframe.com (Braden McDaniel) Date: Sun, 15 Nov 2009 03:46:01 -0500 Subject: "make tag" failure doesn't fail right? Message-ID: <1258274761.5832.202.camel@hinge.endoframe.net> I did: $ make tag and got: cvs tag -c openvrml-0_18_3-11_fc13 cvs tag: openvrml.spec is locally modified cvs [tag aborted]: correct the above errors first! Whoops. And so I proceeded to commit the outstanding changes that I'd forgotten to commit. Once I'd done that, I went to tag again: $ make tag cvs tag -c openvrml-0_18_3-11_fc13 ERROR: Tag openvrml-0_18_3-11_fc13 has been already created. The following tags have been created so far . . . openvrml-0_18_3-11_fc13:devel:braden:1258273475 cvs tag: Pre-tag check failed cvs [tag aborted]: correct the above errors first! Uh oh. Did my previous "make tag" actually succeed? -- Braden McDaniel From thomasj at fedoraproject.org Sun Nov 15 09:35:05 2009 From: thomasj at fedoraproject.org (Thomas Janssen) Date: Sun, 15 Nov 2009 10:35:05 +0100 Subject: "make tag" failure doesn't fail right? In-Reply-To: <1258274761.5832.202.camel@hinge.endoframe.net> References: <1258274761.5832.202.camel@hinge.endoframe.net> Message-ID: 2009/11/15 Braden McDaniel : > I did: > > ? ? ? ?$ make tag > > > and got: > > ? ? ? ?cvs tag ?-c openvrml-0_18_3-11_fc13 > ? ? ? ?cvs tag: openvrml.spec is locally modified > ? ? ? ?cvs [tag aborted]: correct the above errors first! > > Whoops. ?And so I proceeded to commit the outstanding changes that I'd > forgotten to commit. ?Once I'd done that, I went to tag again: > > ? ? ? ?$ make tag > ? ? ? ?cvs tag ?-c openvrml-0_18_3-11_fc13 > ? ? ? ?ERROR: Tag openvrml-0_18_3-11_fc13 has been already created. > ? ? ? ?The following tags have been created so far > ? ? ? ?. > ? ? ? ?. > ? ? ? ?. > ? ? ? ?openvrml-0_18_3-11_fc13:devel:braden:1258273475 > ? ? ? ?cvs tag: Pre-tag check failed > ? ? ? ?cvs [tag aborted]: correct the above errors first! > > Uh oh. > > Did my previous "make tag" actually succeed? But not for your spec file. You could increase the Release version in your spec file, commit the changes, and run make tag normally. Or use: TAG_OPTS=-F make tag WARNING! The latter only as long as you have not built the package! https://fedoraproject.org/wiki/Using_CVS_FAQ_for_package_maintainers#How_to_request_builds.3F -- LG Thomas Dubium sapientiae initium From alexl at users.sourceforge.net Sun Nov 15 11:24:03 2009 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Sun, 15 Nov 2009 06:24:03 -0500 Subject: "make tag" failure doesn't fail right? In-Reply-To: (Thomas Janssen's message of "Sun, 15 Nov 2009 10:35:05 +0100") References: <1258274761.5832.202.camel@hinge.endoframe.net> Message-ID: >>>>> Thomas Janssen writes: > 2009/11/15 Braden McDaniel : >> I did: >> >> ? ? ? ?$ make tag >> >> >> and got: >> >> ? ? ? ?cvs tag ?-c openvrml-0_18_3-11_fc13 ? ? ? ?cvs tag: >> openvrml.spec is locally modified ? ? ? ?cvs [tag aborted]: correct >> the above errors first! >> >> Whoops. ?And so I proceeded to commit the outstanding changes that >> I'd forgotten to commit. ?Once I'd done that, I went to tag again: >> >> ? ? ? ?$ make tag ? ? ? ?cvs tag ?-c openvrml-0_18_3-11_fc13 ? ? ? >> ?ERROR: Tag openvrml-0_18_3-11_fc13 has been already created. ? ? ? >> ?The following tags have been created so far ? ? ? ?. ? ? ? ?. ? ? >> ? ?. ? ? ? ?openvrml-0_18_3-11_fc13:devel:braden:1258273475 ? ? ? >> ?cvs tag: Pre-tag check failed ? ? ? ?cvs [tag aborted]: correct the >> above errors first! >> >> Uh oh. >> >> Did my previous "make tag" actually succeed? > But not for your spec file. You could increase the Release version in > your spec file, commit the changes, and run make tag normally. Or use: > TAG_OPTS=-F make tag > WARNING! The latter only as long as you have not built the package! > https://fedoraproject.org/wiki/Using_CVS_FAQ_for_package_maintainers#How_to_request_builds.3F Right, but what I think Braden (and I) would expect by the principle of least surprise is that "make tag" should *first* check whether any files are locally modified, and refuse to run the "cvs tag" command until all locally modified files were committed. Otherwise it creates unnecessary incrementing of the spec file or nasty "-F" contortions. I will file a bug about that if there isn't one already when I get a chance later. Alex From pasik at iki.fi Sun Nov 15 15:21:11 2009 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Sun, 15 Nov 2009 17:21:11 +0200 Subject: Fedora 12 has gone gold In-Reply-To: <20091114143409.GA5254@mother.pipebreaker.pl> References: <1257816570.2468.32.camel@localhost.localdomain> <20091114135250.GU16033@reaktio.net> <4AFEB5D1.7070301@fedoraproject.org> <20091114135825.GV16033@reaktio.net> <20091114143409.GA5254@mother.pipebreaker.pl> Message-ID: <20091115152111.GY16033@reaktio.net> On Sat, Nov 14, 2009 at 03:34:09PM +0100, Tomasz Torcz wrote: > On Sat, Nov 14, 2009 at 03:58:25PM +0200, Pasi K?rkk?inen wrote: > > On Sat, Nov 14, 2009 at 07:21:13PM +0530, Rahul Sundaram wrote: > > > On 11/14/2009 07:22 PM, Pasi K?rkk?inen wrote: > > > > On Mon, Nov 09, 2009 at 05:29:30PM -0800, Jesse Keating wrote: > > > >> We have just completed our Go / No Go meeting for Fedora 12 and have > > > >> reached the decision to Go. Fedora 12's package set is golden and we're > > > >> ready to stage things for shipping. Great work all around, I'm very > > > >> proud of this release. I'm sure there will be more back patting and > > > >> hand shaking to come, but Will Woods would like to remind everybody that > > > >> it's just 11 weeks until Fedora 13 Alpha freeze! > > > >> > > > > > > > > Hmm.. so I guess this means Fedora 12 will ship with 2.6.31.5 kernel? > > > > > > > > 2.6.31.6 would have had some important Xen PV guest bugfixes: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=533730 > > > > > > I am sure, we will get kernel updates post-release due to security > > > reasons anyway. > > > > > > > Yeah.. that I'm aware of. It just means the GA kernel (and thus > > installer) won't boot on Intel Nehalem CPUs. > > Judging from the bug report, it will only fail to boot when used over Xen. > Which I believe represents small minority of Fedora users. > Yes, when used as Xen paravirtualized (PV) guest, on Intel Nehalem CPUs :) -- Pasi From iarnell at gmail.com Sun Nov 15 15:55:53 2009 From: iarnell at gmail.com (Iain Arnell) Date: Sun, 15 Nov 2009 16:55:53 +0100 Subject: Broken dependencies script at it again In-Reply-To: <18BA8B5A-57EB-4296-AEF9-211B27A92066@j2solutions.net> References: <20091114161249.55838f88@zion.intra.city-fan.org> <4AFEF792.3000100@freenet.de> <4f629b520911141052m6c48964cn67d3523c308b92b5@mail.gmail.com> <19139.1258235077@sss.pgh.pa.us> <18BA8B5A-57EB-4296-AEF9-211B27A92066@j2solutions.net> Message-ID: <81487f820911150755g23dd49fs8a46e03eba1d8e38@mail.gmail.com> On Sat, Nov 14, 2009 at 11:06 PM, Jesse Keating wrote: > Sounds reasonable. Accepting patches if you want this done in the new > future. But until patched, please just turn the damn thing off! I can accept over a thousand spams once, but for it happen again the next day is really too much. -- Iain. From ngompa13 at gmail.com Sun Nov 15 16:20:31 2009 From: ngompa13 at gmail.com (King InuYasha) Date: Sun, 15 Nov 2009 10:20:31 -0600 Subject: Help! Broken Dependencies in oggconvert? Message-ID: <8278b1b0911150820t1637dfb4kce1b7c33c03efad2@mail.gmail.com> Hello, I got a warning from the buildsystem about OggConvert having broken dependencies on PowerPC, when I know OggConvert is a noarch package. What am I supposed to do? This is what I got from the buildsystem: oggconvert has broken dependencies in the development tree: On ppc: oggconvert-0.3.2-7.fc12.noarch requires gstreamer >= 0:0.10.12 oggconvert-0.3.2-7.fc12.noarch requires gstreamer-plugins-base oggconvert-0.3.2-7.fc12.noarch requires python(abi) = 0:2.6 oggconvert-0.3.2-7.fc12.noarch requires /usr/bin/python On ppc64: oggconvert-0.3.2-7.fc12.noarch requires gstreamer >= 0:0.10.12 oggconvert-0.3.2-7.fc12.noarch requires gstreamer-plugins-base oggconvert-0.3.2-7.fc12.noarch requires python(abi) = 0:2.6 oggconvert-0.3.2-7.fc12.noarch requires /usr/bin/python Please resolve this as soon as possible. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanjay.ankur at gmail.com Sun Nov 15 16:30:30 2009 From: sanjay.ankur at gmail.com (Ankur Sinha) Date: Sun, 15 Nov 2009 22:00:30 +0530 Subject: Help! Broken Dependencies in oggconvert? In-Reply-To: <8278b1b0911150820t1637dfb4kce1b7c33c03efad2@mail.gmail.com> References: <8278b1b0911150820t1637dfb4kce1b7c33c03efad2@mail.gmail.com> Message-ID: <1258302630.1835.1.camel@localhost> On Sun, 2009-11-15 at 10:20 -0600, King InuYasha wrote: > Hello, > > > I got a warning from the buildsystem about OggConvert having broken > dependencies on PowerPC, when I know OggConvert is a noarch package. > What am I supposed to do? > > > This is what I got from the buildsystem: > > oggconvert has broken dependencies in the development tree: > On ppc: > oggconvert-0.3.2-7.fc12.noarch requires gstreamer >= 0:0.10.12 > oggconvert-0.3.2-7.fc12.noarch requires gstreamer-plugins-base > oggconvert-0.3.2-7.fc12.noarch requires python(abi) = 0:2.6 > oggconvert-0.3.2-7.fc12.noarch requires /usr/bin/python > On ppc64: > oggconvert-0.3.2-7.fc12.noarch requires gstreamer >= 0:0.10.12 > oggconvert-0.3.2-7.fc12.noarch requires gstreamer-plugins-base > oggconvert-0.3.2-7.fc12.noarch requires python(abi) = 0:2.6 > oggconvert-0.3.2-7.fc12.noarch requires /usr/bin/python > Please resolve this as soon as possible. > > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list read the thread with subject "Broken dependencies script at it again" i guess? Ankur From jkeating at redhat.com Sun Nov 15 18:07:16 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 15 Nov 2009 10:07:16 -0800 Subject: Broken dependencies script at it again In-Reply-To: <4AFFB0A1.3020907@diffingo.com> References: <20091114161249.55838f88@zion.intra.city-fan.org> <4AFEF792.3000100@freenet.de> <4f629b520911141052m6c48964cn67d3523c308b92b5@mail.gmail.com> <19139.1258235077@sss.pgh.pa.us> <18BA8B5A-57EB-4296-AEF9-211B27A92066@j2solutions.net> <4AFFB0A1.3020907@diffingo.com> Message-ID: <1258308436.15679.78.camel@localhost.localdomain> On Sun, 2009-11-15 at 02:41 -0500, Stewart Adam wrote: > Where can we find a copy those scripts? I would be happy to take a look and > see if we can implement a simple "do not send any mail if" blacklist for the > broken deps. > There are two scripts. One, spam-o-matic, is what emails the individual maintainers about a problem. The other, repodiff, is what generates the broken deps part of the daily rawhide report. spam-o-matic can be found in the rel-eng git repo, git://git.fedorahosted.org/git/releng repodiff can be found in the yumutils git. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Sun Nov 15 18:08:47 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 15 Nov 2009 10:08:47 -0800 Subject: Broken dependencies script at it again In-Reply-To: <81487f820911150755g23dd49fs8a46e03eba1d8e38@mail.gmail.com> References: <20091114161249.55838f88@zion.intra.city-fan.org> <4AFEF792.3000100@freenet.de> <4f629b520911141052m6c48964cn67d3523c308b92b5@mail.gmail.com> <19139.1258235077@sss.pgh.pa.us> <18BA8B5A-57EB-4296-AEF9-211B27A92066@j2solutions.net> <81487f820911150755g23dd49fs8a46e03eba1d8e38@mail.gmail.com> Message-ID: <1258308527.15679.80.camel@localhost.localdomain> On Sun, 2009-11-15 at 16:55 +0100, Iain Arnell wrote: > But until patched, please just turn the damn thing off! > > I can accept over a thousand spams once, but for it happen again the > next day is really too much. Sorry about this. We forgot to turn off the composing of ppc/ppc64 when we switched to Fedora 13 based rawhide. I just fixed that so we won't see this problem tonight. I apologize for not getting to this sooner, I don't normally work weekends and I've been rather disconnected this particular weekend. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jnovy at redhat.com Sun Nov 15 19:54:40 2009 From: jnovy at redhat.com (Jindrich Novy) Date: Sun, 15 Nov 2009 20:54:40 +0100 Subject: texlive 2009 f11 info conflict In-Reply-To: References: Message-ID: <20091115195440.GA6252@dhcp-lab-133.englab.brq.redhat.com> Hi, On Fri, Nov 13, 2009 at 02:35:55PM -0500, Neal Becker wrote: > Transaction Check Error: > file /usr/share/info/dir from install of texlive-kpathsea- > doc-2009-2.15842.fc12.noarch conflicts with file from package > info-4.13a-4.fc11.x86_64 > file /usr/share/info/kpathsea.info.gz from install of texlive-kpathsea- > doc-2009-2.15842.fc12.noarch conflicts with file from package > kpathsea-2007-46.fc11.x86_64 Both conflicts are now fixed. -- Jindrich Novy http://people.redhat.com/jnovy/ From bruno at wolff.to Sun Nov 15 19:57:05 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 15 Nov 2009 13:57:05 -0600 Subject: F12-Beta-i686-Live has some bugs In-Reply-To: References: Message-ID: <20091115195705.GA8331@wolff.to> On Sun, Nov 15, 2009 at 02:53:42 +0000, Ikem Krueger wrote: > I booted from cd and I was left with a black screen. When I switched > to a console, I got: > > render error detected, EIR: 0x00000010 > [drm:i915_handle_error] *ERROR* EIR stuck: 0x00000010, masking > > I guess the kernel is guessing my graphiccard wrong. Usually I use > "i810" or "intel" in Xorg. > > Workaround is to boot with "nomodeset". (That isn't even working with > the LXDE Spin. :S) There were significant fixes to video between Beta and the release candidates. The release (isos will be out Tuesday) may work better for you. From jnovy at redhat.com Sun Nov 15 19:58:20 2009 From: jnovy at redhat.com (Jindrich Novy) Date: Sun, 15 Nov 2009 20:58:20 +0100 Subject: texlive2009 f11 broken by today's update In-Reply-To: References: <200911130804.20821.jamatos@fc.up.pt> Message-ID: <20091115195820.GB6252@dhcp-lab-133.englab.brq.redhat.com> Hi, On Fri, Nov 13, 2009 at 03:47:47AM -0500, Neal Becker wrote: > Jos? Matos wrote: > > > On Friday 13 November 2009 00:38:21 Neal Becker wrote: > >> Was working, but after today's update: > >> pdflatex pll_freq_ramp.tex > >> This is pdfTeX, Version 3.1415926-1.40.10 (Web2C 2009) > >> > >> kpathsea: Running mktexfmt pdflatex.fmt > >> I can't find the format file `pdflatex.fmt'! > > > > I have been testing this on F-12 and sometimes update break with this same > > error. The latest updates are working here. > > > > The symptom is that running fmtutil-sys --all as root returns nothing. > > > > I have still determine what causes this, and since the last update is > > working I don't have an incentive to continue searching. :-) > > Very strange, I'm testing on 2 machines, both very similar. This happened > on one, but not the other. > > I ran yum reinstall texlive*, and it's fixed. > It is likely caused by broken scriptlets from an old installation of TeX Live. Just reinstalling all TL packages in this case so that TL has correct scriptlets will help. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From nathanael at gnat.ca Sun Nov 15 20:59:57 2009 From: nathanael at gnat.ca (Nathanael Noblet) Date: Sun, 15 Nov 2009 13:59:57 -0700 Subject: rpmlint warnings... Message-ID: <43C23821-C660-4DBB-BA38-204D868BC351@gnat.ca> Hello, So I recently posted my first package and the review. While I waited I started cleaning up more issues I found after I realized you could run rpmlint on the actual rpm and not just the spec file. I'd like the review to go as quickly as possible so I'm just trying to get all those warnings cleaned up. My package has a number of sub packages for various backend drivers. These subpackages basically contain a .so file for the most part however I'm getting rpmlint messages as follows libdspam.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libdspam.so how is libdspam.so determined to be a devel file? libdspam.so.7.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped Is what I get back from file. What is it that I'm missing? Thanks, From dominik at greysector.net Sun Nov 15 21:30:44 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 15 Nov 2009 22:30:44 +0100 Subject: rpmlint warnings... In-Reply-To: <43C23821-C660-4DBB-BA38-204D868BC351@gnat.ca> References: <43C23821-C660-4DBB-BA38-204D868BC351@gnat.ca> Message-ID: <20091115213043.GA11194@mokona.greysector.net> On Sunday, 15 November 2009 at 21:59, Nathanael Noblet wrote: > Hello, > So I recently posted my first package and the review. While I waited I started cleaning up more issues I found after I realized you could run rpmlint on the actual rpm and not just the spec file. I'd like the review to go as quickly as possible so I'm just trying to get all those warnings cleaned up. > > My package has a number of sub packages for various backend drivers. These subpackages basically contain a .so file for the most part however I'm getting rpmlint messages as follows > > libdspam.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libdspam.so > > how is libdspam.so determined to be a devel file? Shared objects (libraries) residing in %{_libdir} usually have names like libfoo.so.X.Y.Z where X.Y.Z is their ABI version number. -devel subpackages contain libfoo.so which is usually a link to libfoo.X.Y.Z and is used for linking against libfoo (-lfoo in linker command line). > libdspam.so.7.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped > > Is what I get back from file. What is it that I'm missing? Judging by the above, your libdspam.so should in fact be named libdspam.so.7.0.0. 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 mschwendt at gmail.com Sun Nov 15 22:05:55 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 15 Nov 2009 23:05:55 +0100 Subject: rpmlint warnings... In-Reply-To: <20091115213043.GA11194@mokona.greysector.net> References: <43C23821-C660-4DBB-BA38-204D868BC351@gnat.ca> <20091115213043.GA11194@mokona.greysector.net> Message-ID: <20091115230555.47498c9d@faldor.intranet> On Sun, 15 Nov 2009 22:30:44 +0100, Dominik wrote: > On Sunday, 15 November 2009 at 21:59, Nathanael Noblet wrote: > > Hello, > > So I recently posted my first package and the review. While I waited I started cleaning up more issues I found after I realized you could run rpmlint on the actual rpm and not just the spec file. I'd like the review to go as quickly as possible so I'm just trying to get all those warnings cleaned up. > > > > My package has a number of sub packages for various backend drivers. These subpackages basically contain a .so file for the most part however I'm getting rpmlint messages as follows > > > > libdspam.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libdspam.so > > > > how is libdspam.so determined to be a devel file? > > Shared objects (libraries) residing in %{_libdir} usually have names like > libfoo.so.X.Y.Z where X.Y.Z is their ABI version number. -devel subpackages > contain libfoo.so which is usually a link to libfoo.X.Y.Z and is used for > linking against libfoo (-lfoo in linker command line). > > > libdspam.so.7.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped > > > > Is what I get back from file. What is it that I'm missing? > > Judging by the above, your libdspam.so should in fact be named > libdspam.so.7.0.0. It is. "file" prints the file name, not the SONAME. Often, projects, which dlopen plugin/module shared libraries at run-time, store the versioned libraries as well as the .so symlinks. Then they dlopen the libraries via the .so symlinks. Find out how and with what file names those backend libraries are loaded. If the .so symlinks are not needed, don't package them. And if the backend libraries have SONAMEs defined, check for [potential] conflicts with system libraries. From fedora at matbooth.co.uk Sun Nov 15 22:42:44 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Sun, 15 Nov 2009 22:42:44 +0000 Subject: Help! Broken Dependencies in oggconvert? In-Reply-To: <8278b1b0911150820t1637dfb4kce1b7c33c03efad2@mail.gmail.com> References: <8278b1b0911150820t1637dfb4kce1b7c33c03efad2@mail.gmail.com> Message-ID: <9497e9990911151442y4b2612a4t3dbd2d19ebda79be@mail.gmail.com> 2009/11/15 King InuYasha : > Hello, > I got a warning from the buildsystem about OggConvert having broken > dependencies on PowerPC, when I know OggConvert is a noarch package. What am > I supposed to do? > > This is what I got from the buildsystem: > oggconvert has broken dependencies in the development tree: > On ppc: > ? ? ? ?oggconvert-0.3.2-7.fc12.noarch requires gstreamer >= 0:0.10.12 > ? ? ? ?oggconvert-0.3.2-7.fc12.noarch requires gstreamer-plugins-base > ? ? ? ?oggconvert-0.3.2-7.fc12.noarch requires python(abi) = 0:2.6 > ? ? ? ?oggconvert-0.3.2-7.fc12.noarch requires /usr/bin/python > On ppc64: > ? ? ? ?oggconvert-0.3.2-7.fc12.noarch requires gstreamer >= 0:0.10.12 > ? ? ? ?oggconvert-0.3.2-7.fc12.noarch requires gstreamer-plugins-base > ? ? ? ?oggconvert-0.3.2-7.fc12.noarch requires python(abi) = 0:2.6 > ? ? ? ?oggconvert-0.3.2-7.fc12.noarch requires /usr/bin/python > Please resolve this as soon as possible. > > See https://www.redhat.com/archives/fedora-devel-list/2009-November/msg00748.html Hopefully it should be sorted now. -- Mat Booth A: Because it destroys the order of the conversation. Q: Why shouldn't you do it? A: Posting your reply above the original message. Q: What is top-posting? From mjs at clemson.edu Mon Nov 16 00:23:10 2009 From: mjs at clemson.edu (Matthew Saltzman) Date: Sun, 15 Nov 2009 19:23:10 -0500 Subject: texlive-2009 update dependency failure in F11 Message-ID: <1258330990.3968.35.camel@valkyrie.localdomain> >From today's F11 texlive-2009 update: Setting up Update Process Resolving Dependencies --> Running transaction check --> Processing Dependency: libkpathsea.so.4()(64bit) for package: evince-dvi-2.26.2-1.fc11.x86_64 ---> Package texlive-kpathsea-doc.noarch 0:2009-2.15842.1.fc12 set to be updated --> Finished Dependency Resolution evince-dvi-2.26.2-1.fc11.x86_64 from installed has depsolving problems --> Missing Dependency: libkpathsea.so.4()(64bit) is needed by package evince-dvi-2.26.2-1.fc11.x86_64 (installed) Error: Missing Dependency: libkpathsea.so.4()(64bit) is needed by package evince-dvi-2.26.2-1.fc11.x86_64 (installed) You could try using --skip-broken to work around the problem You could try running: package-cleanup --problems package-cleanup --dupes rpm -Va --nofiles --nodigest Thanks for any suggestions. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From ndbecker2 at gmail.com Mon Nov 16 00:37:54 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 15 Nov 2009 19:37:54 -0500 Subject: texlive 2009 texlive-Asana-Math conflict Message-ID: --> Processing Dependency: texlive-Asana-Math = 2009 for package: texlive- collection-fontsextra-2009-2.13989.fc12.noarch ---> Package texlive-asana-math-fedora-fonts.noarch 0:2009-2.0.926.15878.fc12 set to be updated --> Finished Dependency Resolution texlive-collection-fontsextra-2009-2.13989.fc12.noarch from installed has depsolving problems --> Missing Dependency: texlive-Asana-Math = 2009 is needed by package texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) Error: Missing Dependency: texlive-Asana-Math = 2009 is needed by package texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) From Matt_Domsch at dell.com Mon Nov 16 01:52:31 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 15 Nov 2009 19:52:31 -0600 Subject: rpmlint warnings... In-Reply-To: <43C23821-C660-4DBB-BA38-204D868BC351@gnat.ca> References: <43C23821-C660-4DBB-BA38-204D868BC351@gnat.ca> Message-ID: <20091116015231.GA32721@auslistsprd01.us.dell.com> On Sun, Nov 15, 2009 at 01:59:57PM -0700, Nathanael Noblet wrote: > Hello, > So I recently posted my first package and the review. While I waited I started cleaning up more issues I found after I realized you could run rpmlint on the actual rpm and not just the spec file. I'd like the review to go as quickly as possible so I'm just trying to get all those warnings cleaned up. > > My package has a number of sub packages for various backend drivers. These subpackages basically contain a .so file for the most part however I'm getting rpmlint messages as follows > > libdspam.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libdspam.so You should also see if you can build the app such that it installs its private plugins in a subdir of %{_libdir} rather than clutter up %{_libdir} with libraries that nothing else can use. Thanks, Matt -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From braden at endoframe.com Mon Nov 16 05:30:34 2009 From: braden at endoframe.com (Braden McDaniel) Date: Mon, 16 Nov 2009 00:30:34 -0500 Subject: "make tag" failure doesn't fail right? In-Reply-To: References: <1258274761.5832.202.camel@hinge.endoframe.net> Message-ID: <1258349434.4196.7.camel@localhost> On Sun, 2009-11-15 at 10:35 +0100, Thomas Janssen wrote: > 2009/11/15 Braden McDaniel : [snip] > > Did my previous "make tag" actually succeed? > > But not for your spec file. You could increase the Release version in > your spec file, commit the changes, and run make tag normally. I did; seemed like the shortest path to victory. > Or use: > TAG_OPTS=-F make tag > > WARNING! The latter only as long as you have not built the package! Aha... Good to know. Thanks. As Alex notes, I think it would be really nice if partial success could be avoided. -- Braden McDaniel From arthurg.work at gmail.com Mon Nov 16 05:37:56 2009 From: arthurg.work at gmail.com (Arthur G) Date: Mon, 16 Nov 2009 16:37:56 +1100 Subject: buildsys Broken dependencies - libc Message-ID: <8b9607eb0911152137k3a2b090cwdaf7ac58abcadf8c@mail.gmail.com> Hi anyonewhocanhelp, Just curious, is libc now an explicit dependency or should I buy a sense of humour? broken dependencies in the development tree: On ppc: xmlfy-1.5.0-1.fc12.ppc requires libc.so.6(GLIBC_2.4) xmlfy-1.5.0-1.fc12.ppc requires libc.so.6 ....etc Regs, Arthur. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvonau at shaw.ca Mon Nov 16 07:33:01 2009 From: jvonau at shaw.ca (Jerry Vonau) Date: Mon, 16 Nov 2009 01:33:01 -0600 Subject: FESCO ticket#270 - preupgrade and F-12 Message-ID: <1258356781.2068.23.camel@f9.vonau.ca> > On Fri, 2009-11-13 at 09:35 -0500, Andy Gospodarek wrote: > > On Thu, Nov 12, 2009 at 11:27:28PM -0500, Bill Nottingham wrote: > > > Toshio Kuratomi (a badger gmail com) said: > > > > > There are definitely workarounds available, but none that meet the > > > > > criteria for preupgrade as an effortless upgrade option. > > > > > > > > So I'm a bit confused by what is so hard here. preupgrade starts up, > > > > finds it can't store stage2, and then tells you that you'll need to have a > > > > wired connection to the internet if you want to use it. So you have to > > > > download stage2 when you reboot and you have to cart your laptop over to the > > > > router to plug it in while it does so... it's not like I'm going to be using > > > > it for work while anaconda is running.... > > > > > > Basically, the case where it fails is when there's enough space to download > > > stage2, but not enough space left after downloading stage2 to do the > > > upgrade. > > > > > > > Could we add some support to use a USB key as scratch space for any part > > of this process? > > Not a bad idea. Not sure who would add this support and test it before > Tuesday. Definitely something to consider as a future enhancement to > preupgrade. You could hand edit the stage2= line and point is to any non-lvm partition including a temporary usbkey. You would need to have a filesystem label on the usbkey, and change "Fedora" to be the name of your usbkey in the grub.conf file entry for preupgrade. Just make sure that the install.img resides in /images on the usbkey. You could boot off the boot.iso and pass the needed options to anaconda, appending to the boot line does work with: append initrd=initrd.img stage2=hd:LABEL="Fedora" preupgrade \ repo=hd::/var/cache/yum/preupgrade ks=hd:sda1:/upgrade/ks.cfg Yea, I know ks=hd:sda1 is less that ideal, but if that is the /boot partition unless your playing bios games with the boot order, where else can it be but sda1? This could be added to the boot.iso in a stanza as an option much like rescue. Just some thoughts, Jerry From luya at fedoraproject.org Mon Nov 16 08:31:59 2009 From: luya at fedoraproject.org (Luya Tshimbalanga) Date: Mon, 16 Nov 2009 00:31:59 -0800 Subject: buildsys Broken dependencies - libc In-Reply-To: <8b9607eb0911152137k3a2b090cwdaf7ac58abcadf8c@mail.gmail.com> References: <8b9607eb0911152137k3a2b090cwdaf7ac58abcadf8c@mail.gmail.com> Message-ID: <4B010DFF.5030105@fedoraproject.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/15/2009 09:37 PM, Arthur G wrote: > Hi anyonewhocanhelp, > > Just curious, is libc now an explicit dependency or should I buy a sense of humour? > > broken dependencies in the development tree: > On ppc: > xmlfy-1.5.0-1.fc12.ppc requires libc.so.6(GLIBC_2.4) > xmlfy-1.5.0-1.fc12.ppc requires libc.so.6 > ....etc > > Regs, Arthur. > You are not alone, I receives the same broken dependencies for PPC and PPC64. I wonder if migration for both architecture as "second class" has occurred in a process. - -- Luya Tshimbalanga Graphic & Web Designer E: luya at fedoraproject.org W: http://www.thefinalzone.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAksBDfwACgkQaS6HaNQHFTn31wCePwWtki4IJHQuv0vc2HfPe5nF V9kAn1O+pGsbFb5w3QD4KawQwgBfHu0S =Ojqa -----END PGP SIGNATURE----- From jgarzik at pobox.com Mon Nov 16 08:53:32 2009 From: jgarzik at pobox.com (Jeff Garzik) Date: Mon, 16 Nov 2009 03:53:32 -0500 Subject: buildsys Broken dependencies - libc In-Reply-To: <8b9607eb0911152137k3a2b090cwdaf7ac58abcadf8c@mail.gmail.com> References: <8b9607eb0911152137k3a2b090cwdaf7ac58abcadf8c@mail.gmail.com> Message-ID: <4B01130C.2070101@pobox.com> On 11/16/2009 12:37 AM, Arthur G wrote: > Hi anyonewhocanhelp, > Just curious, is libc now an explicit dependency or should I buy a sense > of humour? > broken dependencies in the development tree: > On ppc: > xmlfy-1.5.0-1.fc12.ppc requires libc.so.6(GLIBC_2.4) > xmlfy-1.5.0-1.fc12.ppc requires libc.so.6 > ....etc Everyone is getting these emails, therefore I assumed it would be fixed by someone other than the package maintainers :) Jeff From htraki at gmail.com Mon Nov 16 10:12:55 2009 From: htraki at gmail.com (Tamas Hoppar) Date: Mon, 16 Nov 2009 11:12:55 +0100 Subject: dbus bug when writing with dvd+rw Message-ID: <515ba58a0911160212o507eb3beo8e1343933f63f1ff@mail.gmail.com> Hi everybody, I get a dbus error after blanking a dvd+rw and start to write an ISO, using brasero. Get http://www.hugos.hu/uploads/bug.png to see the error msg. The hungarian message says: I can not mount empty optical disc. From htraki at gmail.com Mon Nov 16 10:22:25 2009 From: htraki at gmail.com (Tamas Hoppar) Date: Mon, 16 Nov 2009 11:22:25 +0100 Subject: FC12 bugs Message-ID: <515ba58a0911160222wa169bd5tcc8129338aeb2079@mail.gmail.com> I have these error messages in dmesg: [drm:drm_mode_rmfb] *ERROR* tried to remove a fb that we didn't own type=1400 audit(1258366567.758:4): avc: denied { mmap_zero } for pid=352 comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect From jlaska at redhat.com Mon Nov 16 13:30:34 2009 From: jlaska at redhat.com (James Laska) Date: Mon, 16 Nov 2009 08:30:34 -0500 Subject: FESCO ticket#270 - preupgrade and F-12 In-Reply-To: <1258356781.2068.23.camel@f9.vonau.ca> References: <1258356781.2068.23.camel@f9.vonau.ca> Message-ID: <1258378234.10605.3.camel@localhost.localdomain> On Mon, 2009-11-16 at 01:33 -0600, Jerry Vonau wrote: > > On Fri, 2009-11-13 at 09:35 -0500, Andy Gospodarek wrote: > > > On Thu, Nov 12, 2009 at 11:27:28PM -0500, Bill Nottingham wrote: > > > > Toshio Kuratomi (a badger gmail com) said: > > > > > > There are definitely workarounds available, but none that meet the > > > > > > criteria for preupgrade as an effortless upgrade option. > > > > > > > > > > So I'm a bit confused by what is so hard here. preupgrade starts up, > > > > > finds it can't store stage2, and then tells you that you'll need to have a > > > > > wired connection to the internet if you want to use it. So you have to > > > > > download stage2 when you reboot and you have to cart your laptop over to the > > > > > router to plug it in while it does so... it's not like I'm going to be using > > > > > it for work while anaconda is running.... > > > > > > > > Basically, the case where it fails is when there's enough space to download > > > > stage2, but not enough space left after downloading stage2 to do the > > > > upgrade. > > > > > > > > > > Could we add some support to use a USB key as scratch space for any part > > > of this process? > > > > Not a bad idea. Not sure who would add this support and test it before > > Tuesday. Definitely something to consider as a future enhancement to > > preupgrade. > > You could hand edit the stage2= line and point is to any non-lvm partition including > a temporary usbkey. You would need to have a filesystem label on the usbkey, and > change "Fedora" to be the name of your usbkey in the grub.conf file entry for > preupgrade. Just make sure that the install.img resides in /images on the usbkey. > > You could boot off the boot.iso and pass the needed options to anaconda, > appending to the boot line does work with: > > append initrd=initrd.img stage2=hd:LABEL="Fedora" preupgrade \ > repo=hd::/var/cache/yum/preupgrade ks=hd:sda1:/upgrade/ks.cfg > > Yea, I know ks=hd:sda1 is less that ideal, but if that is the /boot > partition unless your playing bios games with the boot order, where else > can it be but sda1? This could be added to the boot.iso in a stanza as an > option much like rescue. > > Just some thoughts, Thanks for the input Jerry. Lot's of good ideas on how to manually work around the issue. The preupgrade target user is typically one who might not be fully comfortable with some of the manual workarounds on the table. Ideally, a preupgrade maintainer will be addressing a method to make this process more smooth for Fedora 13, but for now we're looking to avoid leaving the average user high-and-dry, and documenting suggested workarounds (as you've noted above) in the Common_F12_Bugs page. Thanks, James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon Nov 16 14:42:49 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 16 Nov 2009 06:42:49 -0800 Subject: Broken dependencies script at it again In-Reply-To: <1258308527.15679.80.camel@localhost.localdomain> References: <20091114161249.55838f88@zion.intra.city-fan.org> <4AFEF792.3000100@freenet.de> <4f629b520911141052m6c48964cn67d3523c308b92b5@mail.gmail.com> <19139.1258235077@sss.pgh.pa.us> <18BA8B5A-57EB-4296-AEF9-211B27A92066@j2solutions.net> <81487f820911150755g23dd49fs8a46e03eba1d8e38@mail.gmail.com> <1258308527.15679.80.camel@localhost.localdomain> Message-ID: <1258382569.15679.83.camel@localhost.localdomain> On Sun, 2009-11-15 at 10:08 -0800, Jesse Keating wrote: > On Sun, 2009-11-15 at 16:55 +0100, Iain Arnell wrote: > > But until patched, please just turn the damn thing off! > > > > I can accept over a thousand spams once, but for it happen again the > > next day is really too much. > > Sorry about this. We forgot to turn off the composing of ppc/ppc64 when > we switched to Fedora 13 based rawhide. I just fixed that so we won't > see this problem tonight. > > I apologize for not getting to this sooner, I don't normally work > weekends and I've been rather disconnected this particular weekend. > Argh. It helps if I check the patch into CVS before doing the build. Sorry about 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: 198 bytes Desc: This is a digitally signed message part URL: From pjones at redhat.com Mon Nov 16 15:56:44 2009 From: pjones at redhat.com (Peter Jones) Date: Mon, 16 Nov 2009 10:56:44 -0500 Subject: [SoaS] Booting Fedora live USB on MacBookPro In-Reply-To: <4AFA59EA.4070302@diffingo.com> References: <1257882057.1551.148.camel@giskard> <4AF9EC0D.3030203@redhat.com> <4AFA59EA.4070302@diffingo.com> Message-ID: <4B01763C.70205@redhat.com> On 11/11/2009 01:30 AM, Stewart Adam wrote: > On 2009/11/10 5:41 PM, Peter Jones wrote: >> On 11/10/2009 05:37 PM, Caryl Bigenho wrote: >>> >>> Hi, >>> >>> My MacBook is a 4,1. Will it work on my machine? >> >> A 64-bit EFI image should work on a MacBook4,1 . A 32-bit EFI image >> won't. >> > > If the silver MBP is also a 4,1 model, there may be complications... > There are some video initialization problems [1] when booting EFI kernels. > > Stewart > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=496134 Yeah. If somebody had one of these machines at FudCon in Toronto, I could probably knock this out in relatively short time. -- Peter In computing, turning the obvious into the useful is a living definition of the word "frustration" -- Alan Perlis From pjones at redhat.com Mon Nov 16 15:58:24 2009 From: pjones at redhat.com (Peter Jones) Date: Mon, 16 Nov 2009 10:58:24 -0500 Subject: intent to retire: kudzu In-Reply-To: <4AFA8910.4010508@fedoraproject.org> References: <20091109202844.GA29552@nostromo.devel.redhat.com> <4AF87B54.5020807@fedoraproject.org> <4AFA5B98.7080000@diffingo.com> <4AFA8910.4010508@fedoraproject.org> Message-ID: <4B0176A0.3060009@redhat.com> On 11/11/2009 04:51 AM, Rahul Sundaram wrote: > On 11/11/2009 12:07 PM, Stewart Adam wrote: > >> >> I will update it eventually to DeviceKit, but I can't invest the time at >> the moment. Would it be possible to have it temporarily removed from the >> repos? > > If it works as it is, you can take over kudzu for the time being and > continue with it till the time that you can move over to a replacement. Really, temporarily removing this is more desirable than merely passing maintainership of kudzu around. Kudzu needs to actually go away. -- Peter In computing, turning the obvious into the useful is a living definition of the word "frustration" -- Alan Perlis From fedora at leemhuis.info Mon Nov 16 16:58:13 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 16 Nov 2009 17:58:13 +0100 Subject: What questions would you like to ask the Candidates for the Fedora Board, FESCo, and FAMSCO? In-Reply-To: <4AFBAAF6.5090508@leemhuis.info> References: <4AFBAAF6.5090508@leemhuis.info> Message-ID: <4B0184A5.1040106@leemhuis.info> Hi! Sorry, I haven't got around to work on the final version of the questions yet. I plan to do that early tomorrow, which leaves everybody still something like 13 hours to add questions to the wiki. CU knurd Thorsten Leemhuis wrote on 12.11.2009 07:28: > > As you may have heard already, several seats of the Fedora Board, FESCo, > and FAMSCO are up for election soon(?). Right now we are in the > nomination period, which will be followed by a "Candidate > Questionnaire." That means we'll give candidates a list of questions to > answer by private mail within one week after the nomination period > closed; the results will be publish soon after that to make sure they > are available to the public before the Town Hall meetings on IRC happen. > > Candidates may choose to answer (or not) those questions as they see > fit. Voters can use the answers to get an impression of what the > candidate think or plan to do while serving for the committees they are > nominated for. That should help to get a interesting discussion running > during the IRC Town Hall meetings; furthermore, those people that can't > or don't want to participate in the IRC meetings can use the answers to > make a more informed vote. > > Hence we need to prepare a few good questions that we can send to the > candidates once the nomination period ends. And that's where I need > *your help* now: > > If you have one or more questions you'd like to send to the candidates > simply go and add them to: > > https://fedoraproject.org/wiki/Elections/F13_Questionnaire > > It just takes a minute or two, so best to do it right now -- otherwise > you might get distracted and forget about it. ;-) > > I'll take care of the remaining work to review, sort, and clean up the > questions(?); after that I'll send them to the candidates soon after the > nomination period ended. Hence, I need your question suggestions by > around the 15th November 17:00 UTC latest to get a chance to prepare > everything in time. > > So please go to the wiki now and add at least one hard question! The > answers will help Fedora contributors to chose whom to vote for! Thanks > in advance for your help . > > CU > knurd > > (?) If you haven't read about it yet see > https://fedoraproject.org/wiki/Elections for details. > > (?) If you want to get involved or review the questions before I send > them please drop me a line and I'll try to get that arranged; maybe we > can arrange a quick, informal IRC meeting on Sunday evening if there is > interest From kevin.kofler at chello.at Mon Nov 16 17:34:33 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 16 Nov 2009 18:34:33 +0100 Subject: "make tag" failure doesn't fail right? References: <1258274761.5832.202.camel@hinge.endoframe.net> Message-ID: Thomas Janssen wrote: > WARNING! The latter only as long as you have not built the package! Not successfully, at least. Failed builds can be resubmitted, but if you try to resubmit a successful build, Koji will reject it and say the Version- Release is already used. So once the build has succeeded, you cannot reuse the same Version-Release combination anymore, you have to bump Release if you want to change something. Kevin Kofler From bruno at wolff.to Mon Nov 16 18:36:02 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 16 Nov 2009 12:36:02 -0600 Subject: Name of the 'chess' package Message-ID: <20091116183602.GA8087@wolff.to> We currently have a 3d chess game packaged as chess. I want to ask for fedora hosted space for it sop that we can be upstream for some modernization (with regard to ogre and gcc) changes. However it strikes me that the package name probably shouldn't have been 'chess' as that is a generic name. Before officially asking for fedora hosted space I wanted to see if there is sentiment to making some name change for F13+ and fedora hosted. Possibilities would be 3dchess (possibly still too generic), ogrechess (possibly misleading, as people might think it had ogres for pieces), chess-ogre or ? From jkeating at redhat.com Mon Nov 16 19:12:53 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 16 Nov 2009 11:12:53 -0800 Subject: Fedora Release Engineering meeting summary for 2009-11-16 Message-ID: <1258398773.15679.97.camel@localhost.localdomain> Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-11-16/fedora-releng.2009-11-16-18.05.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-11-16/fedora-releng.2009-11-16-18.05.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-11-16/fedora-releng.2009-11-16-18.05.log.html Meeting summary --------------- * roll call (Oxf13, 18:06:03) * Fedora 13 (Oxf13, 18:18:51) * AGREED: No Frozen Rawhide meeting to be held Thursday the 19th at 2000UTC on Fedora Talk (Oxf13, 18:31:54) * mash configs were still trying to compose ppc, and failing badly (Oxf13, 18:35:55) * install image creation was not actually shut off (Oxf13, 18:37:28) * ACTION: notting to fix mash today to stop trying to mash ppc (Oxf13, 18:38:04) * Oxf13 already fixed image creation not being turned off (Oxf13, 18:38:25) * ACTION: wwoods will stop israwhidebroken from caring about ppc(64) (Oxf13, 18:42:46) * ACTION: oxf13 to review proposed schedule and comment on list (Oxf13, 18:47:26) * Open Floor (Oxf13, 18:49:37) Meeting ended at 18:55:35 UTC. Action Items ------------ * notting to fix mash today to stop trying to mash ppc * wwoods will stop israwhidebroken from caring about ppc(64) * oxf13 to review proposed schedule and comment on list -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon Nov 16 19:22:47 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 16 Nov 2009 11:22:47 -0800 Subject: Broken deps for rawhide the past few days Message-ID: <1258399367.15679.99.camel@localhost.localdomain> Many of you received emails over the weekend and this morning regarding broken deps in rawhide. If these emails mentioned that the deps were broken on ppc or ppc64 they can be ignored. We are no longer producing ppc/ppc64 as a primary arch, however we forgot to tag the config change that enacted this on our compose tools. We were attempting to compose ppc(64) trees with only noarch packages, and well things didn't work so hot. We should have this fixed today so that future emails about broken deps will be about actual broken deps, not broken configurations. Sorry for the mailbombing. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From cmadams at hiwaay.net Mon Nov 16 20:12:26 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 16 Nov 2009 14:12:26 -0600 Subject: Broken deps for rawhide the past few days In-Reply-To: <1258399367.15679.99.camel@localhost.localdomain> References: <1258399367.15679.99.camel@localhost.localdomain> Message-ID: <20091116201226.GB1193130@hiwaay.net> Once upon a time, Jesse Keating said: > Many of you received emails over the weekend and this morning regarding > broken deps in rawhide. If these emails mentioned that the deps were > broken on ppc or ppc64 they can be ignored. We are no longer producing > ppc/ppc64 as a primary arch, however we forgot to tag the config change > that enacted this on our compose tools. We were attempting to compose > ppc(64) trees with only noarch packages, and well things didn't work so > hot. As a mirror admin: what does this mean for .../development/ppc{,64}? Will they go away at some point? If so, when? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From nathanael at gnat.ca Mon Nov 16 20:24:03 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Mon, 16 Nov 2009 13:24:03 -0700 Subject: rpmlint warnings... In-Reply-To: <20091115213043.GA11194@mokona.greysector.net> References: <43C23821-C660-4DBB-BA38-204D868BC351@gnat.ca> <20091115213043.GA11194@mokona.greysector.net> Message-ID: <4B01B4E3.20807@gnat.ca> On 11/15/2009 02:30 PM, Dominik 'Rathann' Mierzejewski wrote: > On Sunday, 15 November 2009 at 21:59, Nathanael Noblet wrote: >> Hello, >> So I recently posted my first package and the review. While I waited I started cleaning up more issues I found after I realized you could run rpmlint on the actual rpm and not just the spec file. I'd like the review to go as quickly as possible so I'm just trying to get all those warnings cleaned up. >> >> My package has a number of sub packages for various backend drivers. These subpackages basically contain a .so file for the most part however I'm getting rpmlint messages as follows >> >> libdspam.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libdspam.so >> >> how is libdspam.so determined to be a devel file? > > Shared objects (libraries) residing in %{_libdir} usually have names like > libfoo.so.X.Y.Z where X.Y.Z is their ABI version number. -devel subpackages > contain libfoo.so which is usually a link to libfoo.X.Y.Z and is used for > linking against libfoo (-lfoo in linker command line). > >> libdspam.so.7.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped >> >> Is what I get back from file. What is it that I'm missing? > > Judging by the above, your libdspam.so should in fact be named > libdspam.so.7.0.0. [gnat at iridium ~]$ ls -l /usr/lib64/libdspam.* -rw-r--r--. 1 root root 175812 2009-11-15 13:54 /usr/lib64/libdspam.a -rwxr-xr-x. 1 root root 954 2009-11-15 13:54 /usr/lib64/libdspam.la lrwxrwxrwx. 1 root root 17 2009-11-15 13:59 /usr/lib64/libdspam.so -> libdspam.so.7.0.0 lrwxrwxrwx. 1 root root 17 2009-11-15 13:59 /usr/lib64/libdspam.so.7 -> libdspam.so.7.0.0 -rwxr-xr-x. 1 root root 111000 2009-11-15 13:54 /usr/lib64/libdspam.so.7.0.0 [gnat at iridium ~]$ ldd /usr/bin/dspam_2sql linux-vdso.so.1 => (0x00007fffccfda000) ==> libdspam.so.7 => /usr/lib64/libdspam.so.7 (0x00007f7f4d89e000) libm.so.6 => /lib64/libm.so.6 (0x000000335a400000) libdl.so.2 => /lib64/libdl.so.2 (0x000000335a800000) libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x00007f7f4d659000) liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x0000003362000000) libpthread.so.0 => /lib64/libpthread.so.0 (0x000000335ac00000) libc.so.6 => /lib64/libc.so.6 (0x000000335a000000) /lib64/ld-linux-x86-64.so.2 (0x0000003359c00000) libresolv.so.2 => /lib64/libresolv.so.2 (0x000000335d000000) libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00007f7f4d43d000) libssl.so.10 => /usr/lib64/libssl.so.10 (0x0000003368000000) libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x0000003366000000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f7f4d205000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x0000003367000000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x0000003366c00000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000003365c00000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x0000003367400000) libz.so.1 => /lib64/libz.so.1 (0x000000335b000000) libfreebl3.so => /usr/lib64/libfreebl3.so (0x00007f7f4cfa4000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x0000003366800000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x0000003367800000) libselinux.so.1 => /lib64/libselinux.so.1 (0x000000335bc00000) It seems to me then that libdspam.so.7.0.0 is the actual file, and I have libdspam.so and libdspam.so.7 as symlinks. Based off the ldd of some of the binaries I can see that it is linked to x.so.VER for most libraries... So does that mean that my libdspam.so.7.0.0 and libdspam.so.7 are in the one package and then libdspam.a/la/so are part of -devel ? Would that be the correct assumption? Thanks for the tips so far. -- Nathanael D. Noblet From nathanael at gnat.ca Mon Nov 16 20:27:39 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Mon, 16 Nov 2009 13:27:39 -0700 Subject: rpmlint warnings... In-Reply-To: <20091116015231.GA32721@auslistsprd01.us.dell.com> References: <43C23821-C660-4DBB-BA38-204D868BC351@gnat.ca> <20091116015231.GA32721@auslistsprd01.us.dell.com> Message-ID: <4B01B5BB.7000609@gnat.ca> On 11/15/2009 06:52 PM, Matt Domsch wrote: > On Sun, Nov 15, 2009 at 01:59:57PM -0700, Nathanael Noblet wrote: >> Hello, >> So I recently posted my first package and the review. While I waited I started cleaning up more issues I found after I realized you could run rpmlint on the actual rpm and not just the spec file. I'd like the review to go as quickly as possible so I'm just trying to get all those warnings cleaned up. >> >> My package has a number of sub packages for various backend drivers. These subpackages basically contain a .so file for the most part however I'm getting rpmlint messages as follows >> >> libdspam.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libdspam.so > > You should also see if you can build the app such that it installs its > private plugins in a subdir of %{_libdir} rather than > clutter up %{_libdir} with libraries that nothing else can use. Yeah, there is a lib, and then dlopened backend drivers. So we have. %{_libdir}/libdspam.so.7 (libdspam package) %{_libdir}/dspam/libdspam-mysql_drv.so (libdspam-mysql) For each backend driver. From nathanael at gnat.ca Mon Nov 16 20:41:47 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Mon, 16 Nov 2009 13:41:47 -0700 Subject: rpmlint warnings... In-Reply-To: <20091115230555.47498c9d@faldor.intranet> References: <43C23821-C660-4DBB-BA38-204D868BC351@gnat.ca> <20091115213043.GA11194@mokona.greysector.net> <20091115230555.47498c9d@faldor.intranet> Message-ID: <4B01B90B.2020507@gnat.ca> On 11/15/2009 03:05 PM, Michael Schwendt wrote: > On Sun, 15 Nov 2009 22:30:44 +0100, Dominik wrote: > >> On Sunday, 15 November 2009 at 21:59, Nathanael Noblet wrote: >>> Hello, >>> So I recently posted my first package and the review. While I waited I started cleaning up more issues I found after I realized you could run rpmlint on the actual rpm and not just the spec file. I'd like the review to go as quickly as possible so I'm just trying to get all those warnings cleaned up. >>> >>> My package has a number of sub packages for various backend drivers. These subpackages basically contain a .so file for the most part however I'm getting rpmlint messages as follows >>> >>> libdspam.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libdspam.so >>> >>> how is libdspam.so determined to be a devel file? >> >> Shared objects (libraries) residing in %{_libdir} usually have names like >> libfoo.so.X.Y.Z where X.Y.Z is their ABI version number. -devel subpackages >> contain libfoo.so which is usually a link to libfoo.X.Y.Z and is used for >> linking against libfoo (-lfoo in linker command line). >> >>> libdspam.so.7.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped >>> >>> Is what I get back from file. What is it that I'm missing? >> >> Judging by the above, your libdspam.so should in fact be named >> libdspam.so.7.0.0. > > It is. "file" prints the file name, not the SONAME. > > Often, projects, which dlopen plugin/module shared libraries at run-time, > store the versioned libraries as well as the .so symlinks. Then they dlopen > the libraries via the .so symlinks. > > Find out how and with what file names those backend libraries are loaded. > If the .so symlinks are not needed, don't package them. And if the > backend libraries have SONAMEs defined, check for [potential] conflicts with > system libraries. > So I've grepped through the source a bit and the library loads a storage driver from the config file. So in the case of mysql the dspam.conf file has StorageDriver /usr/lib64/dspam/libhash_drv.so and passes that full path to dlopen. The sub driver package has the following files. /usr/lib64/dspam/libmysql_drv.so /usr/lib64/dspam/libmysql_drv.so.7 /usr/lib64/dspam/libmysql_drv.so.7.0.0 It will open the .so which is a symlink to the real file of so.7.0.0. I don't think it would be feasible to have the config file load the so.7.0.0 because any update to to the SONAME would cause a config change when it may not be necessary. So in this case do I package them all? So does that mean the .so is okay to be in the non devel package? From jkeating at redhat.com Mon Nov 16 20:53:29 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 16 Nov 2009 12:53:29 -0800 Subject: Broken deps for rawhide the past few days In-Reply-To: <20091116201226.GB1193130@hiwaay.net> References: <1258399367.15679.99.camel@localhost.localdomain> <20091116201226.GB1193130@hiwaay.net> Message-ID: <1258404809.15679.101.camel@localhost.localdomain> On Mon, 2009-11-16 at 14:12 -0600, Chris Adams wrote: > Once upon a time, Jesse Keating said: > > Many of you received emails over the weekend and this morning regarding > > broken deps in rawhide. If these emails mentioned that the deps were > > broken on ppc or ppc64 they can be ignored. We are no longer producing > > ppc/ppc64 as a primary arch, however we forgot to tag the config change > > that enacted this on our compose tools. We were attempting to compose > > ppc(64) trees with only noarch packages, and well things didn't work so > > hot. > > As a mirror admin: what does this mean for .../development/ppc{,64}? > Will they go away at some point? If so, when? > They will go away as of tonight I do believe. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From choeger at cs.tu-berlin.de Mon Nov 16 21:08:15 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 16 Nov 2009 22:08:15 +0100 Subject: [Fwd: Broken dependencies: offlineimap] Message-ID: <1258405695.9194.1.camel@choeger6> Hi, does anyone know what this means? Did we switch from Python 2.6 to 3.x or is python broken itself on rawhide? -------------- next part -------------- An embedded message was scrubbed... From: buildsys at fedoraproject.org Subject: Broken dependencies: offlineimap Date: Sat, 14 Nov 2009 15:52:08 +0000 (UTC) Size: 3115 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From sundaram at fedoraproject.org Mon Nov 16 21:08:44 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 17 Nov 2009 02:38:44 +0530 Subject: [Fwd: Broken dependencies: offlineimap] In-Reply-To: <1258405695.9194.1.camel@choeger6> References: <1258405695.9194.1.camel@choeger6> Message-ID: <4B01BF5C.4020500@fedoraproject.org> On 11/17/2009 02:38 AM, Christoph H?ger wrote: > Hi, > > does anyone know what this means? Did we switch from Python 2.6 to 3.x > or is python broken itself on rawhide? You can ignore them. Details at https://www.redhat.com/archives/fedora-devel-announce/2009-November/msg00010.html Rahul From choeger at cs.tu-berlin.de Mon Nov 16 21:18:21 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 16 Nov 2009 22:18:21 +0100 Subject: [Fwd: Broken dependencies: offlineimap] In-Reply-To: <4B01BF5C.4020500@fedoraproject.org> References: <1258405695.9194.1.camel@choeger6> <4B01BF5C.4020500@fedoraproject.org> Message-ID: <1258406301.9194.4.camel@choeger6> Am Dienstag, den 17.11.2009, 02:38 +0530 schrieb Rahul Sundaram: > On 11/17/2009 02:38 AM, Christoph H?ger wrote: > > Hi, > > > > does anyone know what this means? Did we switch from Python 2.6 to 3.x > > or is python broken itself on rawhide? > > You can ignore them. Details at > > https://www.redhat.com/archives/fedora-devel-announce/2009-November/msg00010.html > > Rahul Ah, I should have noticed that, but this email was on top of my TODO this evening. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From mschwendt at gmail.com Mon Nov 16 21:54:16 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 16 Nov 2009 22:54:16 +0100 Subject: rpmlint warnings... In-Reply-To: <4B01B4E3.20807@gnat.ca> References: <43C23821-C660-4DBB-BA38-204D868BC351@gnat.ca> <20091115213043.GA11194@mokona.greysector.net> <4B01B4E3.20807@gnat.ca> Message-ID: <20091116225416.0b18089a@faldor.intranet> On Mon, 16 Nov 2009 13:24:03 -0700, Nathanael wrote: > >> libdspam.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libdspam.so > [gnat at iridium ~]$ ls -l /usr/lib64/libdspam.* > -rw-r--r--. 1 root root 175812 2009-11-15 13:54 /usr/lib64/libdspam.a > -rwxr-xr-x. 1 root root 954 2009-11-15 13:54 /usr/lib64/libdspam.la > lrwxrwxrwx. 1 root root 17 2009-11-15 13:59 /usr/lib64/libdspam.so > -> libdspam.so.7.0.0 > lrwxrwxrwx. 1 root root 17 2009-11-15 13:59 /usr/lib64/libdspam.so.7 > -> libdspam.so.7.0.0 > -rwxr-xr-x. 1 root root 111000 2009-11-15 13:54 /usr/lib64/libdspam.so.7.0.0 > > > [gnat at iridium ~]$ ldd /usr/bin/dspam_2sql > linux-vdso.so.1 => (0x00007fffccfda000) > ==> libdspam.so.7 => /usr/lib64/libdspam.so.7 (0x00007f7f4d89e000) That means you only need the .so.7 and the .so.7.0.0 libs in %{_libdir}. For the .a lib, follow the Fedora Packaging Guidelines on Static Libraries. Same for the .la libtool archive. Delete it. The symlink libdspam.so is not needed at run-time. It's only needed to make the -ldspam linking step work when building software with this lib. From ndbecker2 at gmail.com Mon Nov 16 22:02:01 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Mon, 16 Nov 2009 17:02:01 -0500 Subject: The tag mercurial-1_4-1_fc12 is already applied on a different branch Message-ID: Seems I do this every time we have a new release. In F12: cvs tag -F -c mercurial-1_4-1_fc12 ERROR: The tag mercurial-1_4-1_fc12 is already applied on a different branch ERROR: You can not forcibly move tags between branches cvs tag: Pre-tag check failed cvs [tag aborted]: correct the above errors first! What are my choices to proceed? I already have built/are building 1.4.1 on F13 and F11. I don't want to have a different package number on F12. From mschwendt at gmail.com Mon Nov 16 22:23:30 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 16 Nov 2009 23:23:30 +0100 Subject: The tag mercurial-1_4-1_fc12 is already applied on a different branch In-Reply-To: References: Message-ID: <20091116232330.03370e4d@faldor.intranet> On Mon, 16 Nov 2009 17:02:01 -0500, Neal wrote: > Seems I do this every time we have a new release. How about you avoid that mistake in the future? ;) > In F12: > cvs tag -F -c mercurial-1_4-1_fc12 > ERROR: The tag mercurial-1_4-1_fc12 is already applied on a different branch > ERROR: You can not forcibly move tags between branches > cvs tag: Pre-tag check failed > cvs [tag aborted]: correct the above errors first! You've applied this tag to the devel dir. > What are my choices to proceed? Bump %release in F-12 and devel, commit, make tag again. From dennis at ausil.us Mon Nov 16 22:26:39 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 16 Nov 2009 16:26:39 -0600 Subject: The tag mercurial-1_4-1_fc12 is already applied on a different branch In-Reply-To: References: Message-ID: <200911161626.46533.dennis@ausil.us> On Monday 16 November 2009 04:02:01 pm Neal Becker wrote: > Seems I do this every time we have a new release. > > In F12: > cvs tag -F -c mercurial-1_4-1_fc12 > ERROR: The tag mercurial-1_4-1_fc12 is already applied on a different > branch ERROR: You can not forcibly move tags between branches > cvs tag: Pre-tag check failed > cvs [tag aborted]: correct the above errors first! > > What are my choices to proceed? I already have built/are building 1.4.1 on > F13 and F11. I don't want to have a different package number on F12. > your only option is to bump and tag you can use either 1.4-2 or 1.4-1.1 but you can do cross branch tagging. so there is no way to tag 1.4-1 on the f-12 branch. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mschwendt at gmail.com Mon Nov 16 22:49:31 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 16 Nov 2009 23:49:31 +0100 Subject: The tag mercurial-1_4-1_fc12 is already applied on a different branch In-Reply-To: <200911161626.46533.dennis@ausil.us> References: <200911161626.46533.dennis@ausil.us> Message-ID: <20091116234931.06214b3d@faldor.intranet> On Mon, 16 Nov 2009 16:26:39 -0600, Dennis wrote: > On Monday 16 November 2009 04:02:01 pm Neal Becker wrote: > > Seems I do this every time we have a new release. > > > > In F12: > > cvs tag -F -c mercurial-1_4-1_fc12 > > ERROR: The tag mercurial-1_4-1_fc12 is already applied on a different > > branch ERROR: You can not forcibly move tags between branches > > cvs tag: Pre-tag check failed > > cvs [tag aborted]: correct the above errors first! > > > > What are my choices to proceed? I already have built/are building 1.4.1 on > > F13 and F11. I don't want to have a different package number on F12. > > > your only option is to bump and tag you can use either 1.4-2 or 1.4-1.1 but To be precise, avoid 1.4-1.1 as it would be higher than 1.4-1.fc13 Use 1.4-1%{?dist}.1 instead for F-12 if you don't want to bump to 1.4-2%{?dist} for both F-12 and devel. From henriquecsj at gmail.com Mon Nov 16 22:57:07 2009 From: henriquecsj at gmail.com (Henrique Junior) Date: Mon, 16 Nov 2009 20:57:07 -0200 Subject: A silly question about our "FC" tag Message-ID: <4f629b520911161457l2897facs5dd7e02b357bcd76@mail.gmail.com> Hello, * I have a question that may sound a little stupid, but that came as I write a short article about some Fedora's curiosities. Why are our packages still using the tag "f*c*X", "f*c*Y", "f*c*W" since Fedora does not use ?*Core*? in his name anymore? I know it's an almost irrelevant question, but the article is just about small curiosities and I could not think in a better place to ask. Henrique "LonelySpooky" Junior http://www.lonelyspooky.com ------------------------------------------------------------- "In a world without walls and fences, who needs windows and gates?!" -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Mon Nov 16 22:58:24 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 17 Nov 2009 04:28:24 +0530 Subject: A silly question about our "FC" tag In-Reply-To: <4f629b520911161457l2897facs5dd7e02b357bcd76@mail.gmail.com> References: <4f629b520911161457l2897facs5dd7e02b357bcd76@mail.gmail.com> Message-ID: <4B01D910.8030107@fedoraproject.org> On 11/17/2009 04:27 AM, Henrique Junior wrote: > Hello, * > > I have a question that may sound a little stupid, but that came as I > write a short article about some Fedora's curiosities. > > Why are our packages still using the tag "f*c*X", "f*c*Y", "f*c*W" since > Fedora does not use ?*Core*? in his name anymore? > > I know it's an almost irrelevant question, but the article is just about > small curiosities and I could not think in a better place to ask. When Fedora 7 was about to be released, there was a long and serious discussion about how to rename it but we took the easy way out and decided to call it "Fedora Package Collection" along the lines of GCC being called "GNU Compiler Collection". Dropping the "C" would have broken the upgrade path for RPM. Rahul From itamar at ispbrasil.com.br Mon Nov 16 23:04:33 2009 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Mon, 16 Nov 2009 21:04:33 -0200 Subject: A silly question about our "FC" tag In-Reply-To: <4f629b520911161457l2897facs5dd7e02b357bcd76@mail.gmail.com> References: <4f629b520911161457l2897facs5dd7e02b357bcd76@mail.gmail.com> Message-ID: because renaming it will cause problems, for example. foo-1.0.fc10 foo-1.0.fc11 foo-1.0.fc11 > foo-1.0.fc10 foo-1.0.fc10 foo-1.0.f11 foo-1.0.f11 < foo-1.0.fc10 rpmdev-vercmp foo-1.0.f11 foo-1.0.fc10 0:foo-1.0.fc10 is newer On Mon, Nov 16, 2009 at 8:57 PM, Henrique Junior wrote: > Hello, * > > I have a question that may sound a little stupid, but that came as I write a > short article about some Fedora's curiosities. > > Why are our packages still using the tag "fcX", "fcY", "fcW" since Fedora > does not use ?Core? in his name anymore? > > I know it's an almost irrelevant question, but the article is just about > small curiosities and I could not think in a better place to ask. > > Henrique "LonelySpooky" Junior > http://www.lonelyspooky.com > ------------------------------------------------------------- -- ------------ Itamar Reis Peixoto e-mail/msn/google talk/sip: itamar at ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 From dennis at ausil.us Mon Nov 16 23:09:45 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 16 Nov 2009 17:09:45 -0600 Subject: The tag mercurial-1_4-1_fc12 is already applied on a different branch In-Reply-To: <20091116234931.06214b3d@faldor.intranet> References: <200911161626.46533.dennis@ausil.us> <20091116234931.06214b3d@faldor.intranet> Message-ID: <200911161709.49800.dennis@ausil.us> On Monday 16 November 2009 04:49:31 pm Michael Schwendt wrote: > On Mon, 16 Nov 2009 16:26:39 -0600, Dennis wrote: > > On Monday 16 November 2009 04:02:01 pm Neal Becker wrote: > > > Seems I do this every time we have a new release. > > > > > > In F12: > > > cvs tag -F -c mercurial-1_4-1_fc12 > > > ERROR: The tag mercurial-1_4-1_fc12 is already applied on a different > > > branch ERROR: You can not forcibly move tags between branches > > > cvs tag: Pre-tag check failed > > > cvs [tag aborted]: correct the above errors first! > > > > > > What are my choices to proceed? I already have built/are building > > > 1.4.1 on F13 and F11. I don't want to have a different package number > > > on F12. > > > > your only option is to bump and tag you can use either 1.4-2 or 1.4-1.1 > > but > > To be precise, avoid 1.4-1.1 as it would be higher than 1.4-1.fc13 No it won't I could have been cleaer 1.4-1%{?dist}.1 is what i meant. but i assumed that the implementer would have done it as such. > > Use 1.4-1%{?dist}.1 instead for F-12 if you don't want to bump to > 1.4-2%{?dist} for both F-12 and devel. > I was intentionally leaving the %{?dist} macro out and putting it in the changelog format. I assume that our packagers are smart enough to do the right thing (tm) Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From tibbs at math.uh.edu Mon Nov 16 23:11:56 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 16 Nov 2009 17:11:56 -0600 Subject: A silly question about our "FC" tag In-Reply-To: (Itamar Reis Peixoto's message of "Mon, 16 Nov 2009 21:04:33 -0200") References: <4f629b520911161457l2897facs5dd7e02b357bcd76@mail.gmail.com> Message-ID: >>>>> "IRP" == Itamar Reis Peixoto writes: IRP> because renaming it will cause problems, Actually not if done in conjunction with a release bump, such as we do with a mass rebuild. - J< From cjb at laptop.org Tue Nov 17 00:55:24 2009 From: cjb at laptop.org (Chris Ball) Date: Mon, 16 Nov 2009 19:55:24 -0500 Subject: RFC: Btrfs snapshots feature for F13 Message-ID: Hi, I've written up a draft of an F13 filesystem rollback feature using Btrfs snapshots that are automatically created by yum: https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs It'd be great to get feedback on whether this is the right idea, and how exactly the UI interaction should work, before submitting this formally. Thanks! - Chris. -- Chris Ball One Laptop Per Child From jgarzik at pobox.com Tue Nov 17 01:43:57 2009 From: jgarzik at pobox.com (Jeff Garzik) Date: Mon, 16 Nov 2009 20:43:57 -0500 Subject: How to update F12 packages? Message-ID: <4B01FFDD.9030709@pobox.com> Project Hail[1] has three packages in F12, cld, chunkd and tabled, which need updating. I successfully built cld: "make build" placed it into dist-f12-updates-candidate apparently. But "koji wait-repo" is timing out after a two-hour wait, preventing me from building chunkd and tabled. What do I need to do, to build updated chunkd and tabled packages on top of the new cld? Does each dependency need its own bodhi update, or something? I am hoping to avoid - build cld - submit bodhi update - wait for update to be processed into repo - build chunkd - submit bodhi update - wait for update to be processed into repo - build tabled - submit bodhi update - wait for update to be processed into repo Surely there is a faster way, for _clusters_ of dependent packages, such as Project Hail's? Thanks, Jeff [1] http://hail.wiki.kernel.org/ From mjs at clemson.edu Tue Nov 17 02:27:08 2009 From: mjs at clemson.edu (Matthew Saltzman) Date: Mon, 16 Nov 2009 21:27:08 -0500 Subject: More broken deps for F11 texlive-2009 Message-ID: <1258424828.23045.78.camel@valkyrie.localdomain> Latest F11 texlive-2009 update complains about dependencies of the new packages (which have .fc12 version suffixes!) on libpoppler.so.5()(64bit). -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From oget.fedora at gmail.com Tue Nov 17 02:42:20 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Mon, 16 Nov 2009 21:42:20 -0500 Subject: How to update F12 packages? In-Reply-To: <4B01FFDD.9030709@pobox.com> References: <4B01FFDD.9030709@pobox.com> Message-ID: On Mon, Nov 16, 2009 at 8:43 PM, Jeff Garzik wrote: > > What do I need to do, to build updated chunkd and tabled packages on top of > the new cld? > You need to file a ticket to releng [1] and ask for buildroot overrides as outlined in the guidelines somewhere I can't remember. You need to provide them the name, version, release of the package you want to have in the buildroot so you can build other packages on top of that. Also let them know on what Fedora version(s) you want to have your package tagged. See example [2]. Orcan [1] https://fedorahosted.org/rel-eng/wiki [2] https://fedorahosted.org/rel-eng/ticket/3158 From jgarzik at pobox.com Tue Nov 17 02:53:17 2009 From: jgarzik at pobox.com (Jeff Garzik) Date: Mon, 16 Nov 2009 21:53:17 -0500 Subject: How to update F12 packages? In-Reply-To: References: <4B01FFDD.9030709@pobox.com> Message-ID: <4B02101D.2060008@pobox.com> On 11/16/2009 09:42 PM, Orcan Ogetbil wrote: > On Mon, Nov 16, 2009 at 8:43 PM, Jeff Garzik wrote: >> >> What do I need to do, to build updated chunkd and tabled packages on top of >> the new cld? >> > > You need to file a ticket to releng [1] and ask for buildroot > overrides as outlined in the guidelines somewhere I can't remember. > > You need to provide them the name, version, release of the package you > want to have in the buildroot so you can build other packages on top > of that. Also let them know on what Fedora version(s) you want to have > your package tagged. See example [2]. Ticket filed, thanks for the advice. It is a bit messy to file two tickets each time I build my packages, though :( Jeff From awilliam at redhat.com Tue Nov 17 03:27:21 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 16 Nov 2009 19:27:21 -0800 Subject: F12-Beta-i686-Live has some bugs In-Reply-To: References: Message-ID: <1258428441.2577.44.camel@adam.local.net> On Sun, 2009-11-15 at 02:53 +0000, Ikem Krueger wrote: > I booted from cd and I was left with a black screen. When I switched > to a console, I got: > > render error detected, EIR: 0x00000010 > [drm:i915_handle_error] *ERROR* EIR stuck: 0x00000010, masking > > I guess the kernel is guessing my graphiccard wrong. Usually I use > "i810" or "intel" in Xorg. You're guessing wrong. i915 is the kernel module used for all Intel graphics adapters. It goes together with the intel X.org driver. > Workaround is to boot with "nomodeset". (That isn't even working with > the LXDE Spin. :S) Which is a fine indication that it's not a wrong driver, isn't it? :) > When I boot without "rhgb", I got several times: > > WARNING: Deprecated config file /etc/modprobe.conf, all config files > belong into /etc/modprobe.d/. > > And at the end: > > plymouthd: ply-event-loop.c:729: ply_event_loop_stop_watching_fd: > Assertion 'watch != ((void *)0)' failed. Neither of these have anything to do with your problem, most likely. Please file a bug against xorg-x11-drv-intel , including all info described here: https://fedoraproject.org/wiki/How_to_debug_Xorg_problems -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From sanjay.ankur at gmail.com Tue Nov 17 05:30:56 2009 From: sanjay.ankur at gmail.com (Ankur Sinha) Date: Tue, 17 Nov 2009 11:00:56 +0530 Subject: Packagekit weirdness: Update applet Message-ID: <1258435856.2360.1.camel@localhost> hey, The update applet is showing me one update available, however on clicking it gives me this[1] I don't know how to reproduce this. Do I still file a bug? regards, Ankur [1] http://ankursinha.fedorapeople.org/Screenshot-Software%20Update.png From mike at cchtml.com Tue Nov 17 05:29:25 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Mon, 16 Nov 2009 23:29:25 -0600 Subject: Packagekit weirdness: Update applet In-Reply-To: <1258435856.2360.1.camel@localhost> References: <1258435856.2360.1.camel@localhost> Message-ID: <4B0234B5.8030707@cchtml.com> On 11/16/2009 11:30 PM, Ankur Sinha wrote: > [1] http://ankursinha.fedorapeople.org/Screenshot-Software%20Update.pn Hm... I'm not Richard, but I bet he'll want you to supply some pkcon output. Try "pkcon -v get-updates" and attach the output. From sanjay.ankur at gmail.com Tue Nov 17 05:42:25 2009 From: sanjay.ankur at gmail.com (Ankur Sinha) Date: Tue, 17 Nov 2009 11:12:25 +0530 Subject: Packagekit weirdness: Update applet In-Reply-To: <4B0234B5.8030707@cchtml.com> References: <1258435856.2360.1.camel@localhost> <4B0234B5.8030707@cchtml.com> Message-ID: <1258436545.2360.3.camel@localhost> On Mon, 2009-11-16 at 23:29 -0600, Michael Cronenworth wrote: > pkcon -v get-updates hi, output from pkcon -v get-updates > packagekit.log is attached. regards, Ankur -------------- next part -------------- A non-text attachment was scrubbed... Name: packagekit.log Type: text/x-log Size: 7701 bytes Desc: not available URL: From sundaram at fedoraproject.org Tue Nov 17 05:37:18 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 17 Nov 2009 11:07:18 +0530 Subject: Packagekit weirdness: Update applet In-Reply-To: <1258436545.2360.3.camel@localhost> References: <1258435856.2360.1.camel@localhost> <4B0234B5.8030707@cchtml.com> <1258436545.2360.3.camel@localhost> Message-ID: <4B02368E.1020805@fedoraproject.org> On 11/17/2009 11:12 AM, Ankur Sinha wrote: > On Mon, 2009-11-16 at 23:29 -0600, Michael Cronenworth wrote: >> pkcon -v get-updates > > hi, > > output from > > pkcon -v get-updates > packagekit.log Please redirect to http://bugz.fedoraproject.org/PackageKit Rahul From sanjay.ankur at gmail.com Tue Nov 17 05:54:15 2009 From: sanjay.ankur at gmail.com (Ankur Sinha) Date: Tue, 17 Nov 2009 11:24:15 +0530 Subject: Packagekit weirdness: Update applet In-Reply-To: <4B02368E.1020805@fedoraproject.org> References: <1258435856.2360.1.camel@localhost> <4B0234B5.8030707@cchtml.com> <1258436545.2360.3.camel@localhost> <4B02368E.1020805@fedoraproject.org> Message-ID: <1258437255.2360.4.camel@localhost> On Tue, 2009-11-17 at 11:07 +0530, Rahul Sundaram wrote: > On 11/17/2009 11:12 AM, Ankur Sinha wrote: > > On Mon, 2009-11-16 at 23:29 -0600, Michael Cronenworth wrote: > >> pkcon -v get-updates > > > > hi, > > > > output from > > > > pkcon -v get-updates > packagekit.log > > Please redirect to http://bugz.fedoraproject.org/PackageKit > > Rahul > hi, https://bugzilla.redhat.com/show_bug.cgi?id=537998 regards, Ankur From fedora at leemhuis.info Tue Nov 17 06:54:17 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Nov 2009 07:54:17 +0100 Subject: What questions would you like to ask the Candidates for the Fedora Board, FESCo, and FAMSCO? In-Reply-To: <4AFB2CF0.10303@leemhuis.info> References: <4AFB2CF0.10303@leemhuis.info> Message-ID: <4B024899.60707@leemhuis.info> Thorsten Leemhuis wrote on 11.11.2009 22:30: > > As you may have heard already, several seats of the Fedora Board, FESCo, > and FAMSCO are up for election soon(?). Right now we are in the > nomination period, which will be followed by a "Candidate > Questionnaire." That means we'll give candidates a list of questions to > answer by private mail within one week after the nomination period > closed; the results will be publish soon after that to make sure they > are available to the public before the Town Hall meetings on IRC happen. > [...] > If you have one or more questions you'd like to send to the candidates > simply go and add them to: > > https://fedoraproject.org/wiki/Elections/F13_Questionnaire I did some cleanups and added a few more question from the last questionnaire. Find below what I plan to sent to the candidates this evening at something like 19:00 UTC. If you dislike something please comment until then in a way to make sure we don't further delay things (yes, I know, that is a tight schedule, but I thought a RFC period of 12 hours is better then none). tia! CU knurd === Main questions === # What is ''The Fedora Project'' to you? # What do you consider to be Fedora's [http://en.wikipedia.org/wiki/Raison_d%27%C3%AAtre raison d'etre]? # Where do you see the project in one years? # Where do you see the project in two years? # Do you see a long-term goal or a "target audience" Fedora should strive for? # What part of the Fedora project would you change, given total power to do so? # Please name three things you plan to work on and realize while being on the Committee you run for! # How would you measure your success as an elected member? # What are your unique strengths and what are your weaknesses? ==== Committee specific questions: Board ==== # Suppose a user/contributor brings up an issue that bothers an important fraction of Fedora community and he proposes a change in the default behavior of Fedora; but either you don't have personal interest in that area, or (as a user) the issue doesn't bother you. How would you approach the problem? ==== Committee specific questions: FAmSCo ==== # What would you be doing to ensure that as a body FAmSCo is communicating more with its constituents ? # What things should be done to promote Fedora in countries where there is little or no Fedora presence, and how you see FAmSCo can support those initiatives? # Do you see any shortcomings in the mentoring overall process? What do you want to change in that process? ==== Committee specific questions: FESCo ==== # Do you feel that a Fedora release should have a more conservative update policy than rawhide, and if so what types of updates do you feel are acceptable to a stable Fedora release? # Suppose a user/contributor brings up an issue that bothers an important fraction of Fedora community and he proposes a change in the default behavior of Fedora; but either you don't have personal interest in that area, or (as a user) the issue doesn't bother you. How would you approach the problem? === More questions === # Why are you a member of the Fedora project? # Please mention if you are running for re-election or not. Further: If you are running for re-election, what are the things that you promised but could not do? Why so? What are you planning to prevent a recurrence? If you are running for the first time, in your opinion, what are the things that the previous committee could do but couldn't/didn't? # What is the most important part of the Fedora the distribution? (IE, Desktop, FEL, AOS) # From your perspective what is it that Fedora brings to linux distros that is unique and original? What sets Fedora apart? From alexl at users.sourceforge.net Tue Nov 17 07:10:33 2009 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Tue, 17 Nov 2009 02:10:33 -0500 Subject: moovida replaces elisa: sponsor needed Message-ID: Graeme Gillies, after consulting with the current elisa maintainer, Matthias Saou, has volunteered to step-up and maintain the Moovida media center package (which will replace elisa). Unfortunately as a new packager, he needs a sponsor. Anybody willing to sponsor him? Package review request is here: https://bugzilla.redhat.com/show_bug.cgi?id=530021 Cheers, Alex From lsof at nodata.co.uk Tue Nov 17 07:43:31 2009 From: lsof at nodata.co.uk (nodata) Date: Tue, 17 Nov 2009 08:43:31 +0100 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: References: Message-ID: <4B025423.3070309@nodata.co.uk> Am 2009-11-17 01:55, schrieb Chris Ball: > Hi, > > I've written up a draft of an F13 filesystem rollback feature using > Btrfs snapshots that are automatically created by yum: > > https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs > > It'd be great to get feedback on whether this is the right idea, and > how exactly the UI interaction should work, before submitting this > formally. > > Thanks! > > - Chris. So this will confuse things a lot if the user doesn't have only rpm stuff on one partition, and everything else on another. This is potentially a major risk. How would that be handled? From jgarzik at pobox.com Tue Nov 17 07:48:50 2009 From: jgarzik at pobox.com (Jeff Garzik) Date: Tue, 17 Nov 2009 02:48:50 -0500 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <4B025423.3070309@nodata.co.uk> References: <4B025423.3070309@nodata.co.uk> Message-ID: <4B025562.5020109@pobox.com> On 11/17/2009 02:43 AM, nodata wrote: > Am 2009-11-17 01:55, schrieb Chris Ball: >> Hi, >> >> I've written up a draft of an F13 filesystem rollback feature using >> Btrfs snapshots that are automatically created by yum: >> >> https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs >> >> It'd be great to get feedback on whether this is the right idea, and >> how exactly the UI interaction should work, before submitting this >> formally. >> >> Thanks! >> >> - Chris. > > So this will confuse things a lot if the user doesn't have only rpm > stuff on one partition, and everything else on another. This is > potentially a major risk. How would that be handled? Mr. nodata, As the URL notes under "Detailed Description," that is not handled at all. It wraps all file I/O, yum or not, into the snapshot. A bloody awful solution, especially when you consider that btrfs' maintainer Chris Mason is adding support for real userland transactions (via some additional ioctls). Jeff From fedora at leemhuis.info Tue Nov 17 08:08:05 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Nov 2009 09:08:05 +0100 Subject: A silly question about our "FC" tag In-Reply-To: <4f629b520911161457l2897facs5dd7e02b357bcd76@mail.gmail.com> References: <4f629b520911161457l2897facs5dd7e02b357bcd76@mail.gmail.com> Message-ID: <4B0259E5.5080500@leemhuis.info> Henrique Junior wrote on 16.11.2009 23:57: > I have a question that may sound a little stupid, but that came as I > write a short article about some Fedora's curiosities. > > Why are our packages still using the tag "f*c*X", "f*c*Y", "f*c*W" since > Fedora does not use ?*Core*? in his name anymore? > > I know it's an almost irrelevant question, but the article is just about > small curiosities and I could not think in a better place to ask. I don't care much about the "c", but we IMHO really should get rid of a disttag in rawhide that is related to the release cycle when a package got build. Only then we can avoid confusion like "why are there packages with .fc11 on my F12 machine/in the F12 repos" which IMHO come up way to often and seem to highly confuse people. I still vote for using ".1" as %dist in rawhide all the time(?), as that is higher then (for example) ".fc12"(?). But that suggestion was shot down last time I brought it up one or two years ago. Has anybody any better idea? CU knurd (?) read "all the time" as in "this doesn't ever need to be increased" (?) $ rpmdev-vercmp 1-2.1 1-2.fc12 0:1-2.1 is newer From rc040203 at freenet.de Tue Nov 17 08:43:11 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 17 Nov 2009 09:43:11 +0100 Subject: A silly question about our "FC" tag In-Reply-To: <4B0259E5.5080500@leemhuis.info> References: <4f629b520911161457l2897facs5dd7e02b357bcd76@mail.gmail.com> <4B0259E5.5080500@leemhuis.info> Message-ID: <4B02621F.6070801@freenet.de> On 11/17/2009 09:08 AM, Thorsten Leemhuis wrote: > Henrique Junior wrote on 16.11.2009 23:57: >> I have a question that may sound a little stupid, but that came as I >> write a short article about some Fedora's curiosities. >> >> Why are our packages still using the tag "f*c*X", "f*c*Y", "f*c*W" since >> Fedora does not use ?*Core*? in his name anymore? >> >> I know it's an almost irrelevant question, but the article is just about >> small curiosities and I could not think in a better place to ask. > > I don't care much about the "c", but we IMHO really should get rid of a > disttag in rawhide that is related to the release cycle when a package > got build. Only then we can avoid confusion like "why are there packages > with .fc11 on my F12 machine/in the F12 repos" which IMHO come up way to > often and seem to highly confuse people. > > I still vote for using ".1" as %dist in rawhide all the time(?), as that > is higher then (for example) ".fc12"(?). But that suggestion was shot > down last time I brought it up one or two years ago. IMO, this proposal is silly and was shot down for valid reasons. > Has anybody any better idea? Keep things as they are. I don't see any reason for any change. Ralf From jamatos at fc.up.pt Tue Nov 17 08:47:16 2009 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Tue, 17 Nov 2009 08:47:16 +0000 Subject: More broken deps for F11 texlive-2009 In-Reply-To: <1258424828.23045.78.camel@valkyrie.localdomain> References: <1258424828.23045.78.camel@valkyrie.localdomain> Message-ID: <200911170847.16177.jamatos@fc.up.pt> On Tuesday 17 November 2009 02:27:08 Matthew Saltzman wrote: > Latest F11 texlive-2009 update complains about dependencies of the new > packages (which have .fc12 version suffixes!) on > libpoppler.so.5()(64bit). The same complain happens on F12 (on a x86_64 no less). :-) -- Jos? Ab?lio From jnovy at redhat.com Tue Nov 17 08:47:48 2009 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 17 Nov 2009 09:47:48 +0100 Subject: More broken deps for F11 texlive-2009 In-Reply-To: <1258424828.23045.78.camel@valkyrie.localdomain> References: <1258424828.23045.78.camel@valkyrie.localdomain> Message-ID: <20091117084748.GA5166@dhcp-lab-133.englab.brq.redhat.com> On Mon, Nov 16, 2009 at 09:27:08PM -0500, Matthew Saltzman wrote: > Latest F11 texlive-2009 update complains about dependencies of the new > packages (which have .fc12 version suffixes!) on > libpoppler.so.5()(64bit). > It is now fixed. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From jnovy at redhat.com Tue Nov 17 08:54:38 2009 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 17 Nov 2009 09:54:38 +0100 Subject: More broken deps for F11 texlive-2009 In-Reply-To: <200911170847.16177.jamatos@fc.up.pt> References: <1258424828.23045.78.camel@valkyrie.localdomain> <200911170847.16177.jamatos@fc.up.pt> Message-ID: <20091117085438.GB5166@dhcp-lab-133.englab.brq.redhat.com> On Tue, Nov 17, 2009 at 08:47:16AM +0000, Jos? Matos wrote: > On Tuesday 17 November 2009 02:27:08 Matthew Saltzman wrote: > > Latest F11 texlive-2009 update complains about dependencies of the new > > packages (which have .fc12 version suffixes!) on > > libpoppler.so.5()(64bit). > > The same complain happens on F12 (on a x86_64 no less). :-) It could happen only on x86_64 and F11 repo because I forgot to remove the F12 packages created in local build from the repo directory before createrepo. Do you see anything broken on non-x86_64 arches? I checked the F12 repo and everything looks sane to me. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From jnovy at redhat.com Tue Nov 17 08:55:57 2009 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 17 Nov 2009 09:55:57 +0100 Subject: texlive 2009 texlive-Asana-Math conflict In-Reply-To: References: Message-ID: <20091117085557.GC5166@dhcp-lab-133.englab.brq.redhat.com> On Sun, Nov 15, 2009 at 07:37:54PM -0500, Neal Becker wrote: > --> Processing Dependency: texlive-Asana-Math = 2009 for package: texlive- > collection-fontsextra-2009-2.13989.fc12.noarch > ---> Package texlive-asana-math-fedora-fonts.noarch > 0:2009-2.0.926.15878.fc12 set to be updated > --> Finished Dependency Resolution > texlive-collection-fontsextra-2009-2.13989.fc12.noarch from installed has > depsolving problems > --> Missing Dependency: texlive-Asana-Math = 2009 is needed by package > texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) > Error: Missing Dependency: texlive-Asana-Math = 2009 is needed by package > texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) > Fixed. -- Jindrich Novy http://people.redhat.com/jnovy/ From jnovy at redhat.com Tue Nov 17 09:00:21 2009 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 17 Nov 2009 10:00:21 +0100 Subject: texlive-2009 update dependency failure in F11 In-Reply-To: <1258330990.3968.35.camel@valkyrie.localdomain> References: <1258330990.3968.35.camel@valkyrie.localdomain> Message-ID: <20091117090021.GD5166@dhcp-lab-133.englab.brq.redhat.com> Hi, On Sun, Nov 15, 2009 at 07:23:10PM -0500, Matthew Saltzman wrote: > >From today's F11 texlive-2009 update: > > Setting up Update Process > Resolving Dependencies > --> Running transaction check > --> Processing Dependency: libkpathsea.so.4()(64bit) for > package: evince-dvi-2.26.2-1.fc11.x86_64 > ---> Package texlive-kpathsea-doc.noarch 0:2009-2.15842.1.fc12 > set to be updated > --> Finished Dependency Resolution > evince-dvi-2.26.2-1.fc11.x86_64 from installed has depsolving > problems > --> Missing Dependency: libkpathsea.so.4()(64bit) is needed by > package evince-dvi-2.26.2-1.fc11.x86_64 (installed) > Error: Missing Dependency: libkpathsea.so.4()(64bit) is needed > by package evince-dvi-2.26.2-1.fc11.x86_64 (installed) > You could try using --skip-broken to work around the problem > You could try running: package-cleanup --problems > package-cleanup --dupes > rpm -Va --nofiles --nodigest > > Thanks for any suggestions. > This one is actually unfixable without a new tag in koji so that I can rebuild evince against the new libkpathsea. For now, I suggest to remove evince-dvi, install TeX Live and rebuild evince locally from fedora CVS. Then you can install evince-dvi from your local build which will be linked against the TeX Live 2009's kpathsea. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From mail at robertoragusa.it Tue Nov 17 09:03:47 2009 From: mail at robertoragusa.it (Roberto Ragusa) Date: Tue, 17 Nov 2009 10:03:47 +0100 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <4B025562.5020109@pobox.com> References: <4B025423.3070309@nodata.co.uk> <4B025562.5020109@pobox.com> Message-ID: <4B0266F3.4060402@robertoragusa.it> Jeff Garzik wrote: > It wraps all file I/O, yum or not, into the snapshot. In this case it could only be useful in an "undoable mode" boot option. You boot in this mode, avoid touching any data (no email downloading) and do something dangerous (distro upgrade). But how do you handle multiple filesystem?... -- Roberto Ragusa mail at robertoragusa.it From bruno at wolff.to Tue Nov 17 09:12:26 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 17 Nov 2009 03:12:26 -0600 Subject: Issue with F13 dracut/kernel/selinux Message-ID: <20091117091226.GA469@wolff.to> I just went to rawhide over the last day and am not able to boot into kernel 2.6.32-0.48.rc7.git1.fc13 unless selinux is disabled. (permissive isn't good enough). I can boot into my old kernel 2.6.31.5-127.fc12 which had a dracut generated image from before the upgrade. The error occurs when udev is trying to unlock my nonroot partitions. I get an error message refering to filesetcon not working on a /dev/mapper file. I get asked for passwords again (since all of the file systems have the same luks password I normally don't have to do this) and the correct password doesn't work. If I boot with selinux=0, the system boots with the 2.6.32-0.48.rc7.git1.fc13 kernel (but then I have to relabel the next time I boot without that option). I am using selinux-policy-targeted-3.6.33-1.fc13. From henriquecsj at gmail.com Tue Nov 17 09:21:16 2009 From: henriquecsj at gmail.com (Henrique Junior) Date: Tue, 17 Nov 2009 07:21:16 -0200 Subject: A silly question about our "FC" tag In-Reply-To: <4B01D910.8030107@fedoraproject.org> References: <4f629b520911161457l2897facs5dd7e02b357bcd76@mail.gmail.com> <4B01D910.8030107@fedoraproject.org> Message-ID: <4f629b520911170121q8ffd7f4he0916a76e3bee707@mail.gmail.com> 2009/11/16 Rahul Sundaram > On 11/17/2009 04:27 AM, Henrique Junior wrote: > > Hello, * > > > > I have a question that may sound a little stupid, but that came as I > > write a short article about some Fedora's curiosities. > > > > Why are our packages still using the tag "f*c*X", "f*c*Y", "f*c*W" since > > Fedora does not use ?*Core*? in his name anymore? > > > > I know it's an almost irrelevant question, but the article is just about > > small curiosities and I could not think in a better place to ask. > > When Fedora 7 was about to be released, there was a long and serious > discussion about how to rename it but we took the easy way out and > decided to call it "Fedora Package Collection" along the lines of GCC > being called "GNU Compiler Collection". Dropping the "C" would have > broken the upgrade path for RPM. > > Rahul > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Thank you for the answers, they were very enlightening. -- Henrique "LonelySpooky" Junior http://www.lonelyspooky.com ------------------------------------------------------------- "In a world without walls and fences, who needs windows and gates?!" -------------- next part -------------- An HTML attachment was scrubbed... URL: From sulyokpeti at gmail.com Tue Nov 17 09:29:25 2009 From: sulyokpeti at gmail.com (Sulyok Peti) Date: Tue, 17 Nov 2009 10:29:25 +0100 Subject: dbus bug when writing with dvd+rw In-Reply-To: <515ba58a0911160212o507eb3beo8e1343933f63f1ff@mail.gmail.com> References: <515ba58a0911160212o507eb3beo8e1343933f63f1ff@mail.gmail.com> Message-ID: <1258450165.2750.40.camel@sutty.chickenkiller.com> Maybe it should be reported in bugzilla: https://bugzilla.redhat.com/ This might be useful too: https://fedoraproject.org/wiki/Bugs 2009. 11. 16, h?tf? keltez?ssel 11.12-kor Tamas Hoppar ezt ?rta: > Hi everybody, > > I get a dbus error after blanking a dvd+rw and start to write an ISO, > using brasero. > > Get http://www.hugos.hu/uploads/bug.png to see the error msg. The > hungarian message says: I can not mount empty optical disc. > From aphukan.fedora at gmail.com Tue Nov 17 10:09:53 2009 From: aphukan.fedora at gmail.com (Amitakhya Phukan) Date: Tue, 17 Nov 2009 15:39:53 +0530 Subject: po2sgml no longer exists in translate-toolkit ? Message-ID: Hello, I can't find po2sgml installed in the latest translate-toolkit package. Has it been removed ? Is there any other package that provides it ? Regards, Amit. From bnocera at redhat.com Tue Nov 17 10:31:57 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 17 Nov 2009 10:31:57 +0000 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: References: Message-ID: <1258453917.2150.2979.camel@localhost.localdomain> On Mon, 2009-11-16 at 19:55 -0500, Chris Ball wrote: > Hi, > > I've written up a draft of an F13 filesystem rollback feature using > Btrfs snapshots that are automatically created by yum: > > https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs > > It'd be great to get feedback on whether this is the right idea, and > how exactly the UI interaction should work, before submitting this > formally. See also: http://blogs.sun.com/erwann/entry/zfs_on_the_desktop_zfs http://blogs.sun.com/erwann/entry/time_slider_screencast http://blogs.sun.com/erwann/entry/new_time_slider_features_in It was mentioned in the past that we'd want to have this ported to using btrfs snapshots. Cheers From choeger at cs.tu-berlin.de Tue Nov 17 10:33:06 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Tue, 17 Nov 2009 11:33:06 +0100 Subject: abrt bugzilla reporting - does it work? Message-ID: <1258453986.18984.2.camel@choeger6> Hi, I just wanted to report an evolution crash report with abrt. All I get (besides a stacktrace) is "libcurl failed HTTP Post". Since I suspect that libcurl generally can handle HTTP posts, I wonder if this is some general bug in abrt? Did anybody submit bugs successfully using this tool? regards Christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From felix at fetzig.org Tue Nov 17 11:09:16 2009 From: felix at fetzig.org (Felix Kaechele) Date: Tue, 17 Nov 2009 12:09:16 +0100 Subject: abrt bugzilla reporting - does it work? In-Reply-To: <1258453986.18984.2.camel@choeger6> References: <1258453986.18984.2.camel@choeger6> Message-ID: <1258456156.2265.5.camel@localhost> Am Dienstag, den 17.11.2009, 11:33 +0100 schrieb Christoph H?ger: > Since I suspect that libcurl generally can handle HTTP posts, I wonder > if this is some general bug in abrt? It's a problem with libcurl's resolver. > Did anybody submit bugs successfully using this tool? Yes I did. However I had to add bugzilla.redhat.com to my /etc/hosts After that it worked. Felix From ndbecker2 at gmail.com Tue Nov 17 11:53:25 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 17 Nov 2009 06:53:25 -0500 Subject: texlive 2009 massive dep problem today Message-ID: Lots of errors like these: Error: Missing Dependency: libc.so.6(GLIBC_2.11)(64bit) is needed by package texlive-luatex-bin-2009-2.15878.fc12.x86_64 (texlive) Error: Missing Dependency: libpoppler.so.5()(64bit) is needed by package texlive-jadetex-bin-2009-2.15878.fc12.x86_64 (texlive) From mjs at clemson.edu Tue Nov 17 12:40:50 2009 From: mjs at clemson.edu (Matthew Saltzman) Date: Tue, 17 Nov 2009 07:40:50 -0500 Subject: texlive-2009 update dependency failure in F11 In-Reply-To: <20091117090021.GD5166@dhcp-lab-133.englab.brq.redhat.com> References: <1258330990.3968.35.camel@valkyrie.localdomain> <20091117090021.GD5166@dhcp-lab-133.englab.brq.redhat.com> Message-ID: <1258461650.23045.90.camel@valkyrie.localdomain> On Tue, 2009-11-17 at 10:00 +0100, Jindrich Novy wrote: > Hi, > > On Sun, Nov 15, 2009 at 07:23:10PM -0500, Matthew Saltzman wrote: > > >From today's F11 texlive-2009 update: > > > > Setting up Update Process > > Resolving Dependencies > > --> Running transaction check > > --> Processing Dependency: libkpathsea.so.4()(64bit) for > > package: evince-dvi-2.26.2-1.fc11.x86_64 > > ---> Package texlive-kpathsea-doc.noarch 0:2009-2.15842.1.fc12 > > set to be updated > > --> Finished Dependency Resolution > > evince-dvi-2.26.2-1.fc11.x86_64 from installed has depsolving > > problems > > --> Missing Dependency: libkpathsea.so.4()(64bit) is needed by > > package evince-dvi-2.26.2-1.fc11.x86_64 (installed) > > Error: Missing Dependency: libkpathsea.so.4()(64bit) is needed > > by package evince-dvi-2.26.2-1.fc11.x86_64 (installed) > > You could try using --skip-broken to work around the problem > > You could try running: package-cleanup --problems > > package-cleanup --dupes > > rpm -Va --nofiles --nodigest > > > > Thanks for any suggestions. > > > > This one is actually unfixable without a new tag in koji so that I can > rebuild evince against the new libkpathsea. For now, I suggest to remove > evince-dvi, install TeX Live and rebuild evince locally from fedora CVS. > Then you can install evince-dvi from your local build which will be > linked against the TeX Live 2009's kpathsea. Or upgrade to F12, I suppose? We'll see which I get to first... > > Jindrich > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From dwalsh at redhat.com Tue Nov 17 13:04:44 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 17 Nov 2009 08:04:44 -0500 Subject: Issue with F13 dracut/kernel/selinux In-Reply-To: <20091117091226.GA469@wolff.to> References: <20091117091226.GA469@wolff.to> Message-ID: <4B029F6C.9000302@redhat.com> On 11/17/2009 04:12 AM, Bruno Wolff III wrote: > I just went to rawhide over the last day and am not able to boot into > kernel 2.6.32-0.48.rc7.git1.fc13 unless selinux is disabled. (permissive > isn't good enough). I can boot into my old kernel 2.6.31.5-127.fc12 which > had a dracut generated image from before the upgrade. The error occurs > when udev is trying to unlock my nonroot partitions. I get an error > message refering to filesetcon not working on a /dev/mapper file. I get > asked for passwords again (since all of the file systems have the same > luks password I normally don't have to do this) and the correct password > doesn't work. If I boot with selinux=0, the system boots with the > 2.6.32-0.48.rc7.git1.fc13 kernel (but then I have to relabel the next > time I boot without that option). > I am using selinux-policy-targeted-3.6.33-1.fc13. > I have not made the leap yet to F13 to see what the problems are. I will look into this. From ndbecker2 at gmail.com Tue Nov 17 13:09:38 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 17 Nov 2009 08:09:38 -0500 Subject: texlive 2009 texlive-Asana-Math conflict References: <20091117085557.GC5166@dhcp-lab-133.englab.brq.redhat.com> Message-ID: Jindrich Novy wrote: > On Sun, Nov 15, 2009 at 07:37:54PM -0500, Neal Becker wrote: >> --> Processing Dependency: texlive-Asana-Math = 2009 for package: >> texlive- collection-fontsextra-2009-2.13989.fc12.noarch >> ---> Package texlive-asana-math-fedora-fonts.noarch >> 0:2009-2.0.926.15878.fc12 set to be updated >> --> Finished Dependency Resolution >> texlive-collection-fontsextra-2009-2.13989.fc12.noarch from installed has >> depsolving problems >> --> Missing Dependency: texlive-Asana-Math = 2009 is needed by package >> texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) >> Error: Missing Dependency: texlive-Asana-Math = 2009 is needed by package >> texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) >> > > Fixed. > texlive-Asana-Math-fedora-fonts-2009-2.0.926.15878.fc12.noarch from installed has depsolving problems --> Missing Dependency: texlive-Asana-Math = 2009 is needed by package texlive-Asana-Math-fedora-fonts-2009-2.0.926.15878.fc12.noarch (installed) texlive-collection-fontsextra-2009-2.13989.fc12.noarch from installed has depsolving problems --> Missing Dependency: texlive-Asana-Math = 2009 is needed by package texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) Skip-broken could not solve problems Error: Missing Dependency: texlive-linearA = 2009 is needed by package texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) Error: Missing Dependency: texlive-Asana-Math = 2009 is needed by package texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) From josef at toxicpanda.com Tue Nov 17 13:10:31 2009 From: josef at toxicpanda.com (Josef Bacik) Date: Tue, 17 Nov 2009 08:10:31 -0500 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <4B025562.5020109@pobox.com> References: <4B025423.3070309@nodata.co.uk> <4B025562.5020109@pobox.com> Message-ID: <1b7401870911170510n4f021b14hef959b2e3028e2f5@mail.gmail.com> On Tue, Nov 17, 2009 at 2:48 AM, Jeff Garzik wrote: > On 11/17/2009 02:43 AM, nodata wrote: >> >> Am 2009-11-17 01:55, schrieb Chris Ball: >>> >>> Hi, >>> >>> I've written up a draft of an F13 filesystem rollback feature using >>> Btrfs snapshots that are automatically created by yum: >>> >>> https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs >>> >>> It'd be great to get feedback on whether this is the right idea, and >>> how exactly the UI interaction should work, before submitting this >>> formally. >>> >>> Thanks! >>> >>> - Chris. >> >> So this will confuse things a lot if the user doesn't have only rpm >> stuff on one partition, and everything else on another. This is >> potentially a major risk. How would that be handled? > > Mr. nodata, > > As the URL notes under "Detailed Description," that is not handled at all. > ?It wraps all file I/O, yum or not, into the snapshot. > > A bloody awful solution, especially when you consider that btrfs' maintainer > Chris Mason is adding support for real userland transactions (via some > additional ioctls). > Yeah but you can't roll back userland transactions. Not to mention you are talking about an interface that may change quite a bit over the next year. We have snapshotting abilities now, and yes it's a big hammer, but just because its a bit of a blunt instrument doesn't mean we shouldn't take advantage of it. Thanks, Josef From pbrobinson at gmail.com Tue Nov 17 13:26:51 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 17 Nov 2009 13:26:51 +0000 Subject: Broken deps for rawhide the past few days In-Reply-To: <1258399367.15679.99.camel@localhost.localdomain> References: <1258399367.15679.99.camel@localhost.localdomain> Message-ID: <5256d0b0911170526j152d2e19s6b6830b4d5611363@mail.gmail.com> On Mon, Nov 16, 2009 at 7:22 PM, Jesse Keating wrote: > Many of you received emails over the weekend and this morning regarding > broken deps in rawhide. ?If these emails mentioned that the deps were > broken on ppc or ppc64 they can be ignored. ?We are no longer producing > ppc/ppc64 as a primary arch, however we forgot to tag the config change > that enacted this on our compose tools. ?We were attempting to compose > ppc(64) trees with only noarch packages, and well things didn't work so > hot. > > We should have this fixed today so that future emails about broken deps > will be about actual broken deps, not broken configurations. ?Sorry for > the mailbombing. Seems its underway again today for the ppc/ppc64. Cheers, Peter From rc040203 at freenet.de Tue Nov 17 13:55:34 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 17 Nov 2009 14:55:34 +0100 Subject: Broken deps for rawhide the past few days In-Reply-To: <1258399367.15679.99.camel@localhost.localdomain> References: <1258399367.15679.99.camel@localhost.localdomain> Message-ID: <4B02AB56.9080104@freenet.de> On 11/16/2009 08:22 PM, Jesse Keating wrote: > Many of you received emails over the weekend and this morning regarding > broken deps in rawhide. If these emails mentioned that the deps were > broken on ppc or ppc64 they can be ignored. We are no longer producing > ppc/ppc64 as a primary arch, however we forgot to tag the config change > that enacted this on our compose tools. We were attempting to compose > ppc(64) trees with only noarch packages, and well things didn't work so > hot. > > We should have this fixed today so that future emails about broken deps > will be about actual broken deps, not broken configurations. Sorry for > the mailbombing. Seems as if you once more failed to fix this. The 4th flood of mail (ca. 1200 each) seems to be underway. Ralf From james at fedoraproject.org Tue Nov 17 14:53:03 2009 From: james at fedoraproject.org (James Antill) Date: Tue, 17 Nov 2009 09:53:03 -0500 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <1b7401870911170510n4f021b14hef959b2e3028e2f5@mail.gmail.com> References: <4B025423.3070309@nodata.co.uk> <4B025562.5020109@pobox.com> <1b7401870911170510n4f021b14hef959b2e3028e2f5@mail.gmail.com> Message-ID: <1258469583.31861.4.camel@code.and.org> On Tue, 2009-11-17 at 08:10 -0500, Josef Bacik wrote: > On Tue, Nov 17, 2009 at 2:48 AM, Jeff Garzik wrote: > > As the URL notes under "Detailed Description," that is not handled at all. > > It wraps all file I/O, yum or not, into the snapshot. > > Yeah but you can't roll back userland transactions. Not to mention > you are talking about an interface that may change quite a bit over > the next year. That seems like a significant limitation, I'm also not sure that the current transaction API would be usable by rpm. Anyway... > We have snapshotting abilities now, and yes it's a big > hammer, but just because its a bit of a blunt instrument doesn't mean > we shouldn't take advantage of it. This implies that "all you have is a hammer" but you can already run "yum history undo". -- James Antill - james at fedoraproject.org "I'd just like to see a realistic approach to updates via packages." -- Les Mikesell From jkeating at redhat.com Tue Nov 17 14:50:58 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 17 Nov 2009 06:50:58 -0800 Subject: Broken deps for rawhide the past few days In-Reply-To: <1258399367.15679.99.camel@localhost.localdomain> References: <1258399367.15679.99.camel@localhost.localdomain> Message-ID: <1258469458.2485.2.camel@localhost.localdomain> On Mon, 2009-11-16 at 11:22 -0800, Jesse Keating wrote: > Many of you received emails over the weekend and this morning regarding > broken deps in rawhide. If these emails mentioned that the deps were > broken on ppc or ppc64 they can be ignored. We are no longer producing > ppc/ppc64 as a primary arch, however we forgot to tag the config change > that enacted this on our compose tools. We were attempting to compose > ppc(64) trees with only noarch packages, and well things didn't work so > hot. > > We should have this fixed today so that future emails about broken deps > will be about actual broken deps, not broken configurations. Sorry for > the mailbombing. > *sigh* While we were successful in building a new mash package that would avoid making ppc repos, we forgot to update one of the rawhide creation configs so that it used dist-f13 content as opposed to dist-f12. So the rawhide creation process has been using dist-f12 content all this time to build up the chroot, which would then compose dist-f13 content. This means that the dist-f12 version of mash was used, not the dist-f13 version we built to disable ppc. I've corrected that. Third try to kill the ppc deps should be the charm. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From cjb at laptop.org Tue Nov 17 14:52:13 2009 From: cjb at laptop.org (Chris Ball) Date: Tue, 17 Nov 2009 09:52:13 -0500 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: (Chris Ball's message of "Mon, 16 Nov 2009 19:55:24 -0500") References: Message-ID: Hi all, > It'd be great to get feedback on whether this is the right idea, > and how exactly the UI interaction should work, before submitting > this formally. Some off-list feedback so far: * People want independent active snapshots per filesystem (i.e. btrfs /home is the live filesystem, and btrfs / is an older snapshot), which makes sense but makes the UI more complex since it'll have to show a list of (filesystem, snapshot) tuples. * Ray says not to invent a new system-config-blah, and instead to talk with davidz about Palimpsest. David, what do you think? * Several people think that the ZFS Time Slider patches to nautilus? look good, and want that for btrfs. Sounds plausible?, but I'm personally less interested in file versioning via snapshots and more interested in working on ways to let developers feel comfortable upgrading to Rawhide daily, for the next release. * Someone on the feature's Talk Page suggests that we should encourage people using anaconda to create a btrfs rootfs separate to their /home, so that they can rollback rootfs snapshots without affecting their homedir. Could work; maybe an anaconda dialog that says "hey, I see you're choosing btrfs, we're going to turn on snapshots and we suggest you use a separate /home partition". Any more thoughts? Thanks! - Chris. ?: http://blogs.sun.com/erwann/entry/zfs_on_the_desktop_zfs http://blogs.sun.com/erwann/entry/time_slider_screencast http://blogs.sun.com/erwann/entry/new_time_slider_features_in ?: It's a bit awkward; you have to do a mount on each snapshot to be able to show the directory listing for it, but it appears that's what ZFS/Time Slider does already, so it won't be any worse.. -- Chris Ball One Laptop Per Child From jnovy at redhat.com Tue Nov 17 15:00:23 2009 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 17 Nov 2009 16:00:23 +0100 Subject: texlive 2009 texlive-Asana-Math conflict In-Reply-To: References: <20091117085557.GC5166@dhcp-lab-133.englab.brq.redhat.com> Message-ID: <20091117150023.GA7129@dhcp-lab-133.englab.brq.redhat.com> On Tue, Nov 17, 2009 at 08:09:38AM -0500, Neal Becker wrote: > Jindrich Novy wrote: > > > On Sun, Nov 15, 2009 at 07:37:54PM -0500, Neal Becker wrote: > >> --> Processing Dependency: texlive-Asana-Math = 2009 for package: > >> texlive- collection-fontsextra-2009-2.13989.fc12.noarch > >> ---> Package texlive-asana-math-fedora-fonts.noarch > >> 0:2009-2.0.926.15878.fc12 set to be updated > >> --> Finished Dependency Resolution > >> texlive-collection-fontsextra-2009-2.13989.fc12.noarch from installed has > >> depsolving problems > >> --> Missing Dependency: texlive-Asana-Math = 2009 is needed by package > >> texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) > >> Error: Missing Dependency: texlive-Asana-Math = 2009 is needed by package > >> texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) > >> > > > > Fixed. > > > texlive-Asana-Math-fedora-fonts-2009-2.0.926.15878.fc12.noarch from > installed has depsolving problems > --> Missing Dependency: texlive-Asana-Math = 2009 is needed by package > texlive-Asana-Math-fedora-fonts-2009-2.0.926.15878.fc12.noarch (installed) > texlive-collection-fontsextra-2009-2.13989.fc12.noarch from installed has > depsolving problems > --> Missing Dependency: texlive-Asana-Math = 2009 is needed by package > texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) > Skip-broken could not solve problems > Error: Missing Dependency: texlive-linearA = 2009 is needed by package > texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) > Error: Missing Dependency: texlive-Asana-Math = 2009 is needed by package > texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) > Old yum metadata. yum clean all, yum update resolves that. Note that texlive-linearA and texlive-Asana-Math are no more present in the repository and are replaced by texlive-asana-math and texlive-lineara which correctly obsoletes the old ones. This is because of the font guidelines which require packages containing fonts to be lower case. Please report further problems to: http://bugzilla.redhat.com/488651 in order to not to spam fedora-devel list. Thanks, Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From skvidal at fedoraproject.org Tue Nov 17 15:15:19 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 17 Nov 2009 10:15:19 -0500 (EST) Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <1258469583.31861.4.camel@code.and.org> References: <4B025423.3070309@nodata.co.uk> <4B025562.5020109@pobox.com> <1b7401870911170510n4f021b14hef959b2e3028e2f5@mail.gmail.com> <1258469583.31861.4.camel@code.and.org> Message-ID: On Tue, 17 Nov 2009, James Antill wrote: > On Tue, 2009-11-17 at 08:10 -0500, Josef Bacik wrote: >> On Tue, Nov 17, 2009 at 2:48 AM, Jeff Garzik wrote: >>> As the URL notes under "Detailed Description," that is not handled at all. >>> It wraps all file I/O, yum or not, into the snapshot. >> >> Yeah but you can't roll back userland transactions. Not to mention >> you are talking about an interface that may change quite a bit over >> the next year. > > That seems like a significant limitation, I'm also not sure that the > current transaction API would be usable by rpm. Anyway... > >> We have snapshotting abilities now, and yes it's a big >> hammer, but just because its a bit of a blunt instrument doesn't mean >> we shouldn't take advantage of it. > > This implies that "all you have is a hammer" but you can already run > "yum history undo". which works up to a point. If the older pkgs you had prior to an update are not available anywhere history undo isn't going to be able to 'undo' but so much. -sv From jkeating at redhat.com Tue Nov 17 15:18:27 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 17 Nov 2009 07:18:27 -0800 Subject: A silly question about our "FC" tag In-Reply-To: References: <4f629b520911161457l2897facs5dd7e02b357bcd76@mail.gmail.com> Message-ID: <1258471107.2485.6.camel@localhost.localdomain> On Mon, 2009-11-16 at 17:11 -0600, Jason L Tibbitts III wrote: > Actually not if done in conjunction with a release bump, such as we do > with a mass rebuild. > > Only if we make a promise to never use the same base n-v-r across the releases until whichever release we did the mass rebuild on is retired. You are correct in that if we did a mass rebuild in dist-f13, we could move to .f##, but consider 3 days later a maintainer wants to push a new upstream release across the branches: foo-1.2-1.fc11 foo-1.2-1.fc12 foo-1.2-1.f13 We're back in the same boat where the "fc" packages will be n-v-r higher. If we did a macro change in dist-f13 and a mass rebuild, and did a macro change on dist-f12 and dist-f11 at the same time (without a mass rebuild) this might work. I'm not sure I like dist value changing on a released Fedora though. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jnovy at redhat.com Tue Nov 17 15:20:59 2009 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 17 Nov 2009 16:20:59 +0100 Subject: texlive 2009 massive dep problem today In-Reply-To: References: Message-ID: <20091117152059.GA7307@dhcp-lab-133.englab.brq.redhat.com> On Tue, Nov 17, 2009 at 06:53:25AM -0500, Neal Becker wrote: > Lots of errors like these: > > Error: Missing Dependency: libc.so.6(GLIBC_2.11)(64bit) is needed by package > texlive-luatex-bin-2009-2.15878.fc12.x86_64 (texlive) > Error: Missing Dependency: libpoppler.so.5()(64bit) is needed by package > texlive-jadetex-bin-2009-2.15878.fc12.x86_64 (texlive) > > This one looks serious. Are you using the f12/rawhide TL repo on a rawhide system? If so, I need to separate the F12/rawhide repositories because of the glibc change in rawhide. So F12 and rawhide binary packages are no more compatible. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From cjb at laptop.org Tue Nov 17 15:21:28 2009 From: cjb at laptop.org (Chris Ball) Date: Tue, 17 Nov 2009 10:21:28 -0500 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: (Seth Vidal's message of "Tue, 17 Nov 2009 10:15:19 -0500 (EST)") References: <4B025423.3070309@nodata.co.uk> <4B025562.5020109@pobox.com> <1b7401870911170510n4f021b14hef959b2e3028e2f5@mail.gmail.com> <1258469583.31861.4.camel@code.and.org> Message-ID: Hi, >> This implies that "all you have is a hammer" but you can already run >> "yum history undo". > which works up to a point. If the older pkgs you had prior to an > update are not available anywhere history undo isn't going to be able > to 'undo' but so much. And of course, it's not going to work if Rawhide's broken something anywhere in the yum/rpm/*kit/etc stack, or if prelink's hosed every binary on your system again, or so on. But this would. - Chris. -- Chris Ball One Laptop Per Child From david at fubar.dk Tue Nov 17 15:36:28 2009 From: david at fubar.dk (David Zeuthen) Date: Tue, 17 Nov 2009 10:36:28 -0500 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: References: Message-ID: <1258472188.16176.55.camel@localhost.localdomain> (I'm not subscribed to fedora-devel-list so if you expect an answer please Cc me) On Tue, 2009-11-17 at 09:52 -0500, Chris Ball wrote: > * Ray says not to invent a new system-config-blah, and instead to talk > with davidz about Palimpsest. David, what do you think? Yep, we're planning to add support to DeviceKit-disks for exposing the (privileged) operations that btrfs may expose (locked down by polkit, etc etc). There are also plans to expose these operations in the UI in Palimpsest and/or Nautilus. I don't think snapshots is going to have any Palimpsest UI (it belongs in Nautilus I think) but the multi-disk stuff definitely will. As always, DKD and Palimpsest is supposed to be complementary to the command-line tools. So all this is only relevant for creating nice UIs for managing btrfs. (Btw there's still some work needed in udev/blkid (but hopefully not in the btrfs on-disk format) to properly export everything we need - e.g. things like number of block devices in the multi-disk filesystem, maybe the "raid" level and so on. I haven't gotten around to looking at this in detail yet. It's on my TODO list though.) > * Several people think that the ZFS Time Slider patches to nautilus? > look good, and want that for btrfs. Sounds plausible?, People hacking on Nautilus will have to look into this with both ZFS, btrfs and possibly other filesystems in mind. I haven't seen anyone do work like this and it's not trivial. (Oh, and if it turns out that creating/destroying btrfs snaphots isn't a privileged operation (I can't remember at this point) it would probably make sense for Nautilus to just use the btrfs tools directly instead of going through a system daemon. There's just no need to overcomplicate things.) David From nathanael at gnat.ca Tue Nov 17 15:48:14 2009 From: nathanael at gnat.ca (Nathanael Noblet) Date: Tue, 17 Nov 2009 08:48:14 -0700 Subject: abrt bugzilla reporting - does it work? In-Reply-To: <1258453986.18984.2.camel@choeger6> References: <1258453986.18984.2.camel@choeger6> Message-ID: <29752C3E-82AD-4D7F-8B24-F798E3B4AF5F@gnat.ca> On Nov 17, 2009, at 3:33 AM, Christoph H?ger wrote: > Hi, > > I just wanted to report an evolution crash report with abrt. All I get > (besides a stacktrace) is "libcurl failed HTTP Post". > Since I suspect that libcurl generally can handle HTTP posts, I wonder > if this is some general bug in abrt? > > Did anybody submit bugs successfully using this tool? > I've submitted a handful of bugs. From pjones at redhat.com Tue Nov 17 16:13:03 2009 From: pjones at redhat.com (Peter Jones) Date: Tue, 17 Nov 2009 11:13:03 -0500 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <4B025562.5020109@pobox.com> References: <4B025423.3070309@nodata.co.uk> <4B025562.5020109@pobox.com> Message-ID: <4B02CB8F.8020702@redhat.com> On 11/17/2009 02:48 AM, Jeff Garzik wrote: > On 11/17/2009 02:43 AM, nodata wrote: >> Am 2009-11-17 01:55, schrieb Chris Ball: >>> Hi, >>> >>> I've written up a draft of an F13 filesystem rollback feature using >>> Btrfs snapshots that are automatically created by yum: >>> >>> https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs >>> >>> It'd be great to get feedback on whether this is the right idea, and >>> how exactly the UI interaction should work, before submitting this >>> formally. >>> >>> Thanks! >>> >>> - Chris. >> >> So this will confuse things a lot if the user doesn't have only rpm >> stuff on one partition, and everything else on another. This is >> potentially a major risk. How would that be handled? > > Mr. nodata, > > As the URL notes under "Detailed Description," that is not handled at > all. It wraps all file I/O, yum or not, into the snapshot. > > A bloody awful solution, especially when you consider that btrfs' > maintainer Chris Mason is adding support for real userland transactions > (via some additional ioctls). Do they support rollbacks after commit? If they don't, they're not really as useful for this as they could be. If they do, that'd be really interesting for upgrades. -- Peter If you're not part of the solution, then you're part of the precipitate. From schwab at redhat.com Tue Nov 17 16:37:32 2009 From: schwab at redhat.com (Andreas Schwab) Date: Tue, 17 Nov 2009 17:37:32 +0100 Subject: texlive 2009 massive dep problem today In-Reply-To: <20091117152059.GA7307@dhcp-lab-133.englab.brq.redhat.com> (Jindrich Novy's message of "Tue, 17 Nov 2009 16:20:59 +0100") References: <20091117152059.GA7307@dhcp-lab-133.englab.brq.redhat.com> Message-ID: Jindrich Novy writes: > On Tue, Nov 17, 2009 at 06:53:25AM -0500, Neal Becker wrote: >> Lots of errors like these: >> >> Error: Missing Dependency: libc.so.6(GLIBC_2.11)(64bit) is needed by package >> texlive-luatex-bin-2009-2.15878.fc12.x86_64 (texlive) >> Error: Missing Dependency: libpoppler.so.5()(64bit) is needed by package >> texlive-jadetex-bin-2009-2.15878.fc12.x86_64 (texlive) >> >> > > This one looks serious. Are you using the f12/rawhide TL repo on a > rawhide system? If so, I need to separate the F12/rawhide repositories because > of the glibc change in rawhide. So F12 and rawhide binary packages are > no more compatible. libc.so.6(GLIBC_2.11)(64bit) is provided by both f12 and rawhide glibc. Andreas. -- Andreas Schwab, schwab at redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." From eqisow at gmail.com Tue Nov 17 16:46:04 2009 From: eqisow at gmail.com (Justin) Date: Tue, 17 Nov 2009 11:46:04 -0500 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <1258472188.16176.55.camel@localhost.localdomain> References: <1258472188.16176.55.camel@localhost.localdomain> Message-ID: On Tue, Nov 17, 2009 at 10:36 AM, David Zeuthen wrote: > (I'm not subscribed to fedora-devel-list so if you expect an answer > please Cc me) > > On Tue, 2009-11-17 at 09:52 -0500, Chris Ball wrote: >> * Ray says not to invent a new system-config-blah, and instead to talk >> ? with davidz about Palimpsest. ?David, what do you think? > > Yep, we're planning to add support to DeviceKit-disks for exposing the > (privileged) operations that btrfs may expose (locked down by polkit, > etc etc). There are also plans to expose these operations in the UI in > Palimpsest and/or Nautilus. I don't think snapshots is going to have any > Palimpsest UI (it belongs in Nautilus I think) but the multi-disk stuff > definitely will. > Talking about sliders and various btrfs bits in Nautilus, I would just like to point out that there are other desktops and file managers to consider. It should be possible to perform the same operations via GUI in KDE or xfce. Whether this means keeping stuff in a seperate, desktop agnostic, application (like a system-config or Palimpset) or making changes to Dolphin, etc as well I don't know. From tgl at redhat.com Tue Nov 17 16:48:41 2009 From: tgl at redhat.com (Tom Lane) Date: Tue, 17 Nov 2009 11:48:41 -0500 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <4B02CB8F.8020702@redhat.com> References: <4B025423.3070309@nodata.co.uk> <4B025562.5020109@pobox.com> <4B02CB8F.8020702@redhat.com> Message-ID: <210.1258476521@sss.pgh.pa.us> Peter Jones writes: > Do they support rollbacks after commit? If they don't, they're not > really as useful for this as they could be. Rollback *after* commit? This must be some other usage of the term "commit" than is standard to database people. regards, tom lane From deadbabylon at googlemail.com Tue Nov 17 17:27:46 2009 From: deadbabylon at googlemail.com (Sebastian Vahl) Date: Tue, 17 Nov 2009 18:27:46 +0100 Subject: KDE-SIG weekly report (47/2009) Message-ID: <200911171827.47022.deadbabylon@googlemail.com> This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. ---------------------------------------------------------------------------------- = Weekly KDE Summary = Week: 47/2009 Time: 2009-11-17 14:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-11-17 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2009-11-17/kde-sig.2009-11-17-14.07.html Meeting log: http://meetbot.fedoraproject.org/fedora-meeting/2009-11-17/kde- sig.2009-11-17-14.07.log.html ---------------------------------------------------------------------------------- = Participants = * KevinKofler * MaryEllenFoster * RexDieter * SebastianVahl * StevenParrish * ThanNgo * ThomasJanssen ---------------------------------------------------------------------------------- = Agenda = * kde-4.3.3 updates status (sip abi breakage too) * KDE-4.4 alpha in F13 (rawhide) * F10 bugs getting rebased = Summary = KDE 4.3.3 update status: * RexDieter reported that KDE 4.3.3 received a good feedback. * Some issues due to sip abi/api change should be fixed with the latest patch. * RexDieter introduced a new "Provides:" so that dependent packages could be tracked easier: sip(sip_api_major_version) = sip_api_version KDE-4.4 alpha in F13 (rawhide): * KDE 4.4 Beta 1 will be tagged on November 25th. [1] * Either someone with enough free time will start work on packaging pre- release snapshots or the work will start when upstream has tagged the packages. F10 bugs getting rebases: * StephenParrish will rebase all F10 bugs to either F12 or rawhide today. * If a rebased bug should just be closed it's up to the maintainers to close it. * Additionally to that a new triage keyword will be used for all f13/rawhide bugs from today on. Open discussion: * First release candidate of upcoming Qt 4.6 was released. * A binary-incompatible change with former snapshots of Qt 4.6 will cause a rebuild of packages which were built against these snapshots. ---------------------------------------------------------------------------------- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-11-24 ---------------------------------------------------------------------------------- = Links = [1] http://techbase.kde.org/Schedules/KDE4/4.4_Release_Schedule [2] http://labs.trolltech.com/blogs/2009/11/17/qt-460-release-candidate-1/ [3] http://labs.trolltech.com/blogs/2009/11/12/bc-break-in-46-against- previous-46/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From ikem.krueger at googlemail.com Tue Nov 17 17:30:51 2009 From: ikem.krueger at googlemail.com (Ikem Krueger) Date: Tue, 17 Nov 2009 17:30:51 +0000 Subject: Drop wodim, use cdrskin instead? Message-ID: Wodim was always cumbersome for me. I burned a lot of ISOs in conjunction with DVD+RWs and I needed to burn the disc twice to make sure it is burned without errors. Recently I used Cdrskin* and I didn't had this troubles. *http://libburnia-project.org/wiki/Cdrskin From andre at bwh.harvard.edu Tue Nov 17 17:43:15 2009 From: andre at bwh.harvard.edu (Andre Robatino) Date: Tue, 17 Nov 2009 12:43:15 -0500 Subject: Drop wodim, use cdrskin instead? Message-ID: <4B02E0B3.5080909@bwh.harvard.edu> Contrary to what the man page says, wodim doesn't automatically format DVD+RWs, so you have to fully format the disc in advance before using wodim to write it. https://bugzilla.redhat.com/show_bug.cgi?id=519465 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From tcallawa at redhat.com Tue Nov 17 18:14:40 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 17 Nov 2009 13:14:40 -0500 Subject: Package name conflict: eina, the media player or optimized data types and useful tools for e-17. In-Reply-To: <1661529914.1704221258002384584.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1661529914.1704221258002384584.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4B02E810.4080004@redhat.com> On 11/12/2009 12:06 AM, Ding Yi Chen wrote: > Hi, > > I've tried to build e-17 by hand. > When I try to build from eina from e-17, > however, I found that the package name, eina, is already been taken by eina, the media player. > > How should I do with them? Off the top of my head, I'd suggest naming it "libeina". ~spot From tcallawa at redhat.com Tue Nov 17 18:16:56 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 17 Nov 2009 13:16:56 -0500 Subject: id3lib stack smashing In-Reply-To: <20091112183948.GS16031@lisas.de> References: <20091112183948.GS16031@lisas.de> Message-ID: <4B02E898.9000909@redhat.com> On 11/12/2009 01:39 PM, Adrian Reber wrote: > There is ubuntu bug report against id3lib "libid3 crashes (stack > smashing) when reading VBR MP3 file"[1]. I am able to reproduce this on > ubuntu but not on Fedora and I do not understand why. The patch[2] looks > like it is doing the right thing but there is not stack smashing detected > using the Fedora version (even on ubuntu). I have looked at the ubuntu > build logs[3] and it uses completely different compiler flags. Is one of > those flags the reason for not seeing the stack smashing on Fedora? It's possible, but that patch looks obviously correct. ~spot From tcallawa at redhat.com Tue Nov 17 18:19:54 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 17 Nov 2009 13:19:54 -0500 Subject: ilbsndfile update! In-Reply-To: References: Message-ID: <4B02E94A.2050001@redhat.com> On 11/14/2009 05:59 AM, Orcan Ogetbil wrote: > Hi folks, > After getting okays from a few folks I decided to fix the long > standing libsndfile bugs. > > One of these was a request [1] to split the utilities that come with > libsndfile into a utils subpackage. I did this only for F-13. > > Since libsndfile is used by so many other software, it is impractical > for me to check all of these software to see if any of them depends on > these command line utilities. If you have a package that depends on > libsndfile, it would be good to check whether it uses these utilities. > Then you'll need to require libsndfile-utils directly. If your package > just needs the library there is nothing to worry about. Again, the > utils split is only made in F-13. > > Other than that, libsndfile is updated to 1.0.20 in F-10+. Also, now > it has the libvorbis support enabled. Thanks for taking care of this. ~spot From james at fedoraproject.org Tue Nov 17 18:33:05 2009 From: james at fedoraproject.org (James Antill) Date: Tue, 17 Nov 2009 13:33:05 -0500 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <210.1258476521@sss.pgh.pa.us> References: <4B025423.3070309@nodata.co.uk> <4B025562.5020109@pobox.com> <4B02CB8F.8020702@redhat.com> <210.1258476521@sss.pgh.pa.us> Message-ID: <1258482785.31861.14.camel@code.and.org> On Tue, 2009-11-17 at 11:48 -0500, Tom Lane wrote: > Peter Jones writes: > > Do they support rollbacks after commit? If they don't, they're not > > really as useful for this as they could be. > > Rollback *after* commit? This must be some other usage of the term > "commit" than is standard to database people. No it's just a new definition of "rollback" than is standard. The idea is that _ideally_ people seem to _want_ to be able to do: 1. update to new foo 2. run random other things that alter data. 3. update to new bar 4. run random other things that alter data. 5. run new foo, which alters it's data. 6. run random other things that alter data. 7. run new bar, which alters it's data. 8. run random other things that alter data. 9a. Decide foo is bad and thus. "rollback" just #1 and #5. 9b. Decide bar is bad and thus. "rollback" just #3 and #7. ...so all solutions tend to be exercises in randomly picking the features you think they really want, from what is desired. Yum history assumes you are happy with just #1 and/or #3. Snapshots assume you are happy to take a lot of collateral damage to get #5 and/or #7. -- James Antill - james at fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.25 http://yum.baseurl.org/wiki/YumMultipleMachineCaching From abo at root.snowtree.se Tue Nov 17 18:33:13 2009 From: abo at root.snowtree.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Tue, 17 Nov 2009 19:33:13 +0100 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <4B025562.5020109@pobox.com> References: <4B025423.3070309@nodata.co.uk> <4B025562.5020109@pobox.com> Message-ID: <1258482793.14844.25.camel@tempo.alexander.bostrom.net> tis 2009-11-17 klockan 02:48 -0500 skrev Jeff Garzik: > A bloody awful solution, especially when you consider that btrfs' > maintainer Chris Mason is adding support for real userland transactions > (via some additional ioctls). Yes. But the draft proposal is presented as "tools for experienced people" rather than "cool feature for all", so I don't see the harm. (Check the uses cases under Benefit to Fedora.) /abo From abo at root.snowtree.se Tue Nov 17 18:38:44 2009 From: abo at root.snowtree.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Tue, 17 Nov 2009 19:38:44 +0100 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: References: Message-ID: <1258483124.14844.48.camel@tempo.alexander.bostrom.net> tis 2009-11-17 klockan 09:52 -0500 skrev Chris Ball: > * Someone on the feature's Talk Page suggests that we should encourage > people using anaconda to create a btrfs rootfs separate to their > /home, so that they can rollback rootfs snapshots without affecting > their homedir. If you have a single btrfs filesystem with one snapshot from a while back and one "head", would it be possible for some hypothetical tool to create a new head which looks like the root from the snapshot but with the latest /home on top? I mean, without actually copying the files from the snapshot, just creating a "fake snapshot" that can the be mounted and writeable. Then you wouldn't need a separate /home. /abo From jnovy at redhat.com Tue Nov 17 18:49:53 2009 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 17 Nov 2009 19:49:53 +0100 Subject: texlive 2009 massive dep problem today In-Reply-To: References: <20091117152059.GA7307@dhcp-lab-133.englab.brq.redhat.com> Message-ID: <20091117184953.GA21273@dhcp-lab-133.englab.brq.redhat.com> On Tue, Nov 17, 2009 at 05:37:32PM +0100, Andreas Schwab wrote: > Jindrich Novy writes: > > > On Tue, Nov 17, 2009 at 06:53:25AM -0500, Neal Becker wrote: > >> Lots of errors like these: > >> > >> Error: Missing Dependency: libc.so.6(GLIBC_2.11)(64bit) is needed by package > >> texlive-luatex-bin-2009-2.15878.fc12.x86_64 (texlive) > >> Error: Missing Dependency: libpoppler.so.5()(64bit) is needed by package > >> texlive-jadetex-bin-2009-2.15878.fc12.x86_64 (texlive) > >> > >> > > > > This one looks serious. Are you using the f12/rawhide TL repo on a > > rawhide system? If so, I need to separate the F12/rawhide repositories because > > of the glibc change in rawhide. So F12 and rawhide binary packages are > > no more compatible. > > libc.so.6(GLIBC_2.11)(64bit) is provided by both f12 and rawhide glibc. > > Andreas. > Thanks. In that case it is not a problem on the TeX Live side. Just to be sure have just created a new repository solely for F13 to avoid such surprises. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From pjones at redhat.com Tue Nov 17 18:54:00 2009 From: pjones at redhat.com (Peter Jones) Date: Tue, 17 Nov 2009 13:54:00 -0500 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <210.1258476521@sss.pgh.pa.us> References: <4B025423.3070309@nodata.co.uk> <4B025562.5020109@pobox.com> <4B02CB8F.8020702@redhat.com> <210.1258476521@sss.pgh.pa.us> Message-ID: <4B02F148.90808@redhat.com> On 11/17/2009 11:48 AM, Tom Lane wrote: > Peter Jones writes: >> Do they support rollbacks after commit? If they don't, they're not >> really as useful for this as they could be. > > Rollback *after* commit? This must be some other usage of the term > "commit" than is standard to database people. Yes, that's why I included the extra words. -- Peter If you're not part of the solution, then you're part of the precipitate. From ndbecker2 at gmail.com Tue Nov 17 18:55:19 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 17 Nov 2009 13:55:19 -0500 Subject: texlive 2009 massive dep problem today References: <20091117152059.GA7307@dhcp-lab-133.englab.brq.redhat.com> Message-ID: Jindrich Novy wrote: > On Tue, Nov 17, 2009 at 06:53:25AM -0500, Neal Becker wrote: >> Lots of errors like these: >> >> Error: Missing Dependency: libc.so.6(GLIBC_2.11)(64bit) is needed by >> package texlive-luatex-bin-2009-2.15878.fc12.x86_64 (texlive) >> Error: Missing Dependency: libpoppler.so.5()(64bit) is needed by package >> texlive-jadetex-bin-2009-2.15878.fc12.x86_64 (texlive) >> >> > > This one looks serious. Are you using the f12/rawhide TL repo on a > rawhide system? If so, I need to separate the F12/rawhide repositories > because of the glibc change in rawhide. So F12 and rawhide binary packages > are no more compatible. > > Jindrich > No, that was just F11. From josef at toxicpanda.com Tue Nov 17 19:05:20 2009 From: josef at toxicpanda.com (Josef Bacik) Date: Tue, 17 Nov 2009 14:05:20 -0500 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <1258482785.31861.14.camel@code.and.org> References: <4B025423.3070309@nodata.co.uk> <4B025562.5020109@pobox.com> <4B02CB8F.8020702@redhat.com> <210.1258476521@sss.pgh.pa.us> <1258482785.31861.14.camel@code.and.org> Message-ID: <1b7401870911171105y51567671ne18d7c2857406f72@mail.gmail.com> On Tue, Nov 17, 2009 at 1:33 PM, James Antill wrote: > On Tue, 2009-11-17 at 11:48 -0500, Tom Lane wrote: >> Peter Jones writes: >> > Do they support rollbacks after commit? ?If they don't, they're not >> > really as useful for this as they could be. >> >> Rollback *after* commit? ?This must be some other usage of the term >> "commit" than is standard to database people. > > ?No it's just a new definition of "rollback" than is standard. The idea > is that _ideally_ people seem to _want_ to be able to do: > > 1. update to new foo > 2. run random other things that alter data. > 3. update to new bar > 4. run random other things that alter data. > 5. run new foo, which alters it's data. > 6. run random other things that alter data. > 7. run new bar, which alters it's data. > 8. run random other things that alter data. > 9a. Decide foo is bad and thus. "rollback" just #1 and #5. > 9b. Decide bar is bad and thus. "rollback" just #3 and #7. > > ...so all solutions tend to be exercises in randomly picking the > features you think they really want, from what is desired. > > ?Yum history assumes you are happy with just #1 and/or #3. > > ?Snapshots assume you are happy to take a lot of collateral damage to > get #5 and/or #7. > Sure, this isn't a perfect solution, it's just a nice to have feature if you care for it. It's nice to take a complete snapshot of your system right before you update just in case something goes horribly wrong and you lose say configuration files or some such. If you modified other things and have to rollback, you can always just mount the newer snapshot when you boot into the old snapshot and copy the new data that you want back. This isn't for the faint of heart, I envisioned it really for people who want to play the rawhide game with less exposure to its instability. Thanks, Josef From jkeating at redhat.com Tue Nov 17 19:07:23 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 17 Nov 2009 11:07:23 -0800 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <1b7401870911171105y51567671ne18d7c2857406f72@mail.gmail.com> References: <4B025423.3070309@nodata.co.uk> <4B025562.5020109@pobox.com> <4B02CB8F.8020702@redhat.com> <210.1258476521@sss.pgh.pa.us> <1258482785.31861.14.camel@code.and.org> <1b7401870911171105y51567671ne18d7c2857406f72@mail.gmail.com> Message-ID: <1258484843.2485.15.camel@localhost.localdomain> On Tue, 2009-11-17 at 14:05 -0500, Josef Bacik wrote: > On Tue, Nov 17, 2009 at 1:33 PM, James Antill wrote: > > On Tue, 2009-11-17 at 11:48 -0500, Tom Lane wrote: > >> Peter Jones writes: > >> > Do they support rollbacks after commit? If they don't, they're not > >> > really as useful for this as they could be. > >> > >> Rollback *after* commit? This must be some other usage of the term > >> "commit" than is standard to database people. > > > > No it's just a new definition of "rollback" than is standard. The idea > > is that _ideally_ people seem to _want_ to be able to do: > > > > 1. update to new foo > > 2. run random other things that alter data. > > 3. update to new bar > > 4. run random other things that alter data. > > 5. run new foo, which alters it's data. > > 6. run random other things that alter data. > > 7. run new bar, which alters it's data. > > 8. run random other things that alter data. > > 9a. Decide foo is bad and thus. "rollback" just #1 and #5. > > 9b. Decide bar is bad and thus. "rollback" just #3 and #7. > > > > ...so all solutions tend to be exercises in randomly picking the > > features you think they really want, from what is desired. > > > > Yum history assumes you are happy with just #1 and/or #3. > > > > Snapshots assume you are happy to take a lot of collateral damage to > > get #5 and/or #7. > > > > Sure, this isn't a perfect solution, it's just a nice to have feature > if you care for it. It's nice to take a complete snapshot of your > system right before you update just in case something goes horribly > wrong and you lose say configuration files or some such. If you > modified other things and have to rollback, you can always just mount > the newer snapshot when you boot into the old snapshot and copy the > new data that you want back. This isn't for the faint of heart, I > envisioned it really for people who want to play the rawhide game with > less exposure to its instability. Thanks, > > Josef > It also works well for people who have things like homedir backup going nightly, but not full system backup. Restore to the way it was before the last yum update, recover important things from backup. It's an "oh shit" handle that has saved my bacon on other platforms before. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From pjones at redhat.com Tue Nov 17 19:09:14 2009 From: pjones at redhat.com (Peter Jones) Date: Tue, 17 Nov 2009 14:09:14 -0500 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <210.1258476521@sss.pgh.pa.us> References: <4B025423.3070309@nodata.co.uk> <4B025562.5020109@pobox.com> <4B02CB8F.8020702@redhat.com> <210.1258476521@sss.pgh.pa.us> Message-ID: <4B02F4DA.3030801@redhat.com> On 11/17/2009 11:48 AM, Tom Lane wrote: > Peter Jones writes: >> Do they support rollbacks after commit? If they don't, they're not >> really as useful for this as they could be. > > Rollback *after* commit? This must be some other usage of the term > "commit" than is standard to database people. So, I guess I should expand some more on what I'm saying. The problem here is that normal database-like transactions don't help an upgrade much, because you don't really know whether you want to commit the changes until you've rebooted the machine and poked around for a bit. Or, put another way, what you basically want is: 1 create an fs snapshot 2 do an upgrade 3 reboot machine 4 poke around 5 decide if it's good (6a) or bad (6b) 6 act on #5 a - remove snapshot b - abandon all changes after the snapshot And if you're talking about implementing that with database-like semantics, then you want something non-traditional such as: 1 start transaction 2 upgrade 3 tentatively commit transaction 4 reboot machine 5 poke around 6 decide if it's good (6a) or bad (6b) 7 act on #6 a - fully commit transaction b - roll back These obviously aren't the traditional semantics, hence I'm asking if it has semantics like that, because if it doesn't, then I don't really see Jeff's point. -- Peter If you're not part of the solution, then you're part of the precipitate. From josef at toxicpanda.com Tue Nov 17 19:15:12 2009 From: josef at toxicpanda.com (Josef Bacik) Date: Tue, 17 Nov 2009 14:15:12 -0500 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <4B02F4DA.3030801@redhat.com> References: <4B025423.3070309@nodata.co.uk> <4B025562.5020109@pobox.com> <4B02CB8F.8020702@redhat.com> <210.1258476521@sss.pgh.pa.us> <4B02F4DA.3030801@redhat.com> Message-ID: <1b7401870911171115v9b7c30bu5e5f78055cd8d23b@mail.gmail.com> On Tue, Nov 17, 2009 at 2:09 PM, Peter Jones wrote: > On 11/17/2009 11:48 AM, Tom Lane wrote: >> Peter Jones writes: >>> Do they support rollbacks after commit? ?If they don't, they're not >>> really as useful for this as they could be. >> >> Rollback *after* commit? ?This must be some other usage of the term >> "commit" than is standard to database people. > > So, I guess I should expand some more on what I'm saying. > > The problem here is that normal database-like transactions don't help an > upgrade much, because you don't really know whether you want to commit the > changes until you've rebooted the machine and poked around for a bit. > > Or, put another way, what you basically want is: > > 1 create an fs snapshot > 2 do an upgrade > 3 reboot machine > 4 poke around > 5 decide if it's good (6a) or bad (6b) > 6 act on #5 > ?a - remove snapshot > ?b - abandon all changes after the snapshot > > And if you're talking about implementing that with database-like semantics, > then you want something non-traditional such as: > > 1 start transaction > 2 upgrade > 3 tentatively commit transaction > 4 reboot machine > 5 poke around > 6 decide if it's good (6a) or bad (6b) > 7 act on #6 > ?a - fully commit transaction > ?b - roll back > > These obviously aren't the traditional semantics, hence I'm asking if it has > semantics like that, because if it doesn't, then I don't really see Jeff's > point. > It doesn't. Userspace transactions are _only_ to make sure that a set of operations go to disk at the same time. The original reason this was implemented was for ceph, a distributed filesystem that has a client that runs in userspace and needs to write to an inode and update an xattr on that inode at the same time in order to maintain filesystem consistency. Nowadays there is _no_ guarantee that the write to the inode and the write to the xattr will go into the same transaction, so the userspace transaction just makes sure that they do happen in the same transaction. It's not a snapshot or anything like that, its just a way to guarantee ordering. Thanks, Josef From pjones at redhat.com Tue Nov 17 19:20:37 2009 From: pjones at redhat.com (Peter Jones) Date: Tue, 17 Nov 2009 14:20:37 -0500 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <1b7401870911171115v9b7c30bu5e5f78055cd8d23b@mail.gmail.com> References: <4B025423.3070309@nodata.co.uk> <4B025562.5020109@pobox.com> <4B02CB8F.8020702@redhat.com> <210.1258476521@sss.pgh.pa.us> <4B02F4DA.3030801@redhat.com> <1b7401870911171115v9b7c30bu5e5f78055cd8d23b@mail.gmail.com> Message-ID: <4B02F785.4080304@redhat.com> On 11/17/2009 02:15 PM, Josef Bacik wrote: > On Tue, Nov 17, 2009 at 2:09 PM, Peter Jones wrote: >> On 11/17/2009 11:48 AM, Tom Lane wrote: >>> Peter Jones writes: >>>> Do they support rollbacks after commit? If they don't, they're not >>>> really as useful for this as they could be. >>> >>> Rollback *after* commit? This must be some other usage of the term >>> "commit" than is standard to database people. >> >> So, I guess I should expand some more on what I'm saying. >> >> The problem here is that normal database-like transactions don't help an >> upgrade much, because you don't really know whether you want to commit the >> changes until you've rebooted the machine and poked around for a bit. >> >> Or, put another way, what you basically want is: >> >> 1 create an fs snapshot >> 2 do an upgrade >> 3 reboot machine >> 4 poke around >> 5 decide if it's good (6a) or bad (6b) >> 6 act on #5 >> a - remove snapshot >> b - abandon all changes after the snapshot >> >> And if you're talking about implementing that with database-like semantics, >> then you want something non-traditional such as: >> >> 1 start transaction >> 2 upgrade >> 3 tentatively commit transaction >> 4 reboot machine >> 5 poke around >> 6 decide if it's good (6a) or bad (6b) >> 7 act on #6 >> a - fully commit transaction >> b - roll back >> >> These obviously aren't the traditional semantics, hence I'm asking if it has >> semantics like that, because if it doesn't, then I don't really see Jeff's >> point. >> > > It doesn't. Userspace transactions are _only_ to make sure that a set > of operations go to disk at the same time. The original reason this > was implemented was for ceph, a distributed filesystem that has a > client that runs in userspace and needs to write to an inode and > update an xattr on that inode at the same time in order to maintain > filesystem consistency. Nowadays there is _no_ guarantee that the > write to the inode and the write to the xattr will go into the same > transaction, so the userspace transaction just makes sure that they do > happen in the same transaction. It's not a snapshot or anything like > that, its just a way to guarantee ordering. Thanks, Okay, so then I definitely don't see what jgarzik was getting at. -- Peter If you're not part of the solution, then you're part of the precipitate. From nathanael at gnat.ca Tue Nov 17 19:31:08 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Tue, 17 Nov 2009 12:31:08 -0700 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <1b7401870911171105y51567671ne18d7c2857406f72@mail.gmail.com> References: <4B025423.3070309@nodata.co.uk> <4B025562.5020109@pobox.com> <4B02CB8F.8020702@redhat.com> <210.1258476521@sss.pgh.pa.us> <1258482785.31861.14.camel@code.and.org> <1b7401870911171105y51567671ne18d7c2857406f72@mail.gmail.com> Message-ID: <4B02F9FC.6060907@gnat.ca> On 11/17/2009 12:05 PM, Josef Bacik wrote: > Sure, this isn't a perfect solution, it's just a nice to have feature > if you care for it. It's nice to take a complete snapshot of your > system right before you update just in case something goes horribly > wrong and you lose say configuration files or some such. If you > modified other things and have to rollback, you can always just mount > the newer snapshot when you boot into the old snapshot and copy the > new data that you want back. This isn't for the faint of heart, I > envisioned it really for people who want to play the rawhide game with > less exposure to its instability. Thanks, I've long wanted to help with fedora rawhide a bit more but only really have it on the one computer I work on. So this would make it possible for me to do that. I think that's great. I have a few questions. Suppose I do an update, and it breaks X or some other important piece for me. I reboot into my previous snapshot. From there I continue to work. Do I have to remove the 'future' snapshot I came back from to continue working in that snapshot? Or is that just best practice. If I move forward, I'd have to move all the work I did in that snapshot to the head/snapshot that just got fixed with an update... Just thinking out loud here. From pbrobinson at gmail.com Tue Nov 17 19:38:16 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 17 Nov 2009 19:38:16 +0000 Subject: ilbsndfile update! In-Reply-To: References: Message-ID: <5256d0b0911171138x884e982j81d03337a92075b0@mail.gmail.com> On Sat, Nov 14, 2009 at 10:59 AM, Orcan Ogetbil wrote: > Hi folks, > After getting okays from a few folks I decided to fix the long > standing libsndfile bugs. > > One of these was a request [1] to split the utilities that come with > libsndfile into a utils subpackage. I did this only for F-13. > > Since libsndfile is used by so many other software, it is impractical > for me to check all of these software to see if any of them depends on > these command line utilities. If you have a package that depends on > libsndfile, it would be good to check whether it uses these utilities. > Then you'll need to require libsndfile-utils directly. If your package > just needs the library there is nothing to worry about. Again, the > utils split is only made in F-13. > > Other than that, libsndfile is updated to 1.0.20 in F-10+. Also, now > it has the libvorbis support enabled. Any chance of getting the jack-audio-connection-kit dependency split out into a sub package? Cheers, Peter From fedora at leemhuis.info Tue Nov 17 19:47:24 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Nov 2009 20:47:24 +0100 Subject: Questions sent (was: What questions would you like to ask the Candidates for the Fedora Board, FESCo, and FAMSCO?) In-Reply-To: <4B024899.60707@leemhuis.info> References: <4AFB2CF0.10303@leemhuis.info> <4B024899.60707@leemhuis.info> Message-ID: <4B02FDCC.8050508@leemhuis.info> On 17.11.2009 07:54, Thorsten Leemhuis wrote: > Thorsten Leemhuis wrote on 11.11.2009 22:30: >> >> As you may have heard already, several seats of the Fedora Board, >> FESCo, and FAMSCO are up for election soon(?). Right now we are in >> the nomination period, which will be followed by a "Candidate >> Questionnaire." That means we'll give candidates a list of >> questions to answer by private mail within one week after the >> nomination period closed; the results will be publish soon after >> that to make sure they are available to the public before the Town >> Hall meetings on IRC happen. [...] If you have one or more >> questions you'd like to send to the candidates simply go and add >> them to: >> >> https://fedoraproject.org/wiki/Elections/F13_Questionnaire > > I did some cleanups and added a few more question from the last > questionnaire. Find below what I plan to sent to the candidates this > evening at something like 19:00 UTC. If you dislike something please > comment until then in a way to make sure we don't further delay > things (yes, I know, that is a tight schedule, but I thought a RFC > period of 12 hours is better then none). tia! Nobody yelled, so I sent the questions to the people that are running in the elections by mail to the address from FAS. If you are one of those that are running and didn't get my mail please let me know asap. Deadline for answers: 20091124-06:00 UTC (the easier to remember date variant: have them finished by next Monday before midnight). I'll soon afterwards will try compile some documents that allow easy comparison of the answers. Cu knurd From oget.fedora at gmail.com Tue Nov 17 20:15:21 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Tue, 17 Nov 2009 15:15:21 -0500 Subject: ilbsndfile update! In-Reply-To: <5256d0b0911171138x884e982j81d03337a92075b0@mail.gmail.com> References: <5256d0b0911171138x884e982j81d03337a92075b0@mail.gmail.com> Message-ID: On Tue, Nov 17, 2009 at 2:38 PM, Peter Robinson wrote: > On Sat, Nov 14, 2009 at 10:59 AM, Orcan Ogetbil wrote: >> Hi folks, >> After getting okays from a few folks I decided to fix the long >> standing libsndfile bugs. >> >> One of these was a request [1] to split the utilities that come with >> libsndfile into a utils subpackage. I did this only for F-13. >> >> Since libsndfile is used by so many other software, it is impractical >> for me to check all of these software to see if any of them depends on >> these command line utilities. If you have a package that depends on >> libsndfile, it would be good to check whether it uses these utilities. >> Then you'll need to require libsndfile-utils directly. If your package >> just needs the library there is nothing to worry about. Again, the >> utils split is only made in F-13. >> >> Other than that, libsndfile is updated to 1.0.20 in F-10+. Also, now >> it has the libvorbis support enabled. > > Any chance of getting the jack-audio-connection-kit dependency split > out into a sub package? > I think that the jack dependency comes from one of the command line utilities of libsndfile which are now separated into the libsndfile-tools package. Note that here "now" means F-13+. I didn't want to make the split on F-12 and before as it might break potential direct dependencies on these utilities. This will give packagers a full release cycle to find regressions if there are any. Or am I too paranoid? Orcan From fedora at matbooth.co.uk Tue Nov 17 20:39:02 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Tue, 17 Nov 2009 20:39:02 +0000 Subject: ilbsndfile update! In-Reply-To: References: <5256d0b0911171138x884e982j81d03337a92075b0@mail.gmail.com> Message-ID: <9497e9990911171239t5957864h8e3758285f77166d@mail.gmail.com> 2009/11/17 Orcan Ogetbil : > Or am I too paranoid? > Not at all. -- Mat Booth From cdahlin at redhat.com Tue Nov 17 20:41:08 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Tue, 17 Nov 2009 15:41:08 -0500 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <1258484843.2485.15.camel@localhost.localdomain> References: <4B025423.3070309@nodata.co.uk> <4B025562.5020109@pobox.com> <4B02CB8F.8020702@redhat.com> <210.1258476521@sss.pgh.pa.us> <1258482785.31861.14.camel@code.and.org> <1b7401870911171105y51567671ne18d7c2857406f72@mail.gmail.com> <1258484843.2485.15.camel@localhost.localdomain> Message-ID: <4B030A64.80907@redhat.com> On 11/17/2009 02:07 PM, Jesse Keating wrote: > > It also works well for people who have things like homedir backup going > nightly, but not full system backup. Restore to the way it was before > the last yum update, recover important things from backup. It's an "oh > shit" handle that has saved my bacon on other platforms before. > I'm not sure how much of this can/should be automated. From the way btrfs snapshots work the ideal workflow should be: 1) /user/ takes a snapshot. 2) user runs yum 3) rebooting/poking/(possibly) restoring I think the best value add to this would be a yum plugin that simply emits a warning along the lines of "Your last snapshot is ### hours old. Are you sure you want to continue?" This also keeps us out of the dangerous territory that comes with using non-ubiquitous FS features (your boot is on ext3, your root is on btrfs, your etc is on xfs and your usr is on jfs. What do you snapshot and how?) --CJD From pbrobinson at gmail.com Tue Nov 17 20:45:15 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 17 Nov 2009 20:45:15 +0000 Subject: ilbsndfile update! In-Reply-To: References: <5256d0b0911171138x884e982j81d03337a92075b0@mail.gmail.com> Message-ID: <5256d0b0911171245t4124a90bq70137f2981ad75bb@mail.gmail.com> On Tue, Nov 17, 2009 at 8:15 PM, Orcan Ogetbil wrote: > On Tue, Nov 17, 2009 at 2:38 PM, Peter Robinson wrote: >> On Sat, Nov 14, 2009 at 10:59 AM, Orcan Ogetbil wrote: >>> Hi folks, >>> After getting okays from a few folks I decided to fix the long >>> standing libsndfile bugs. >>> >>> One of these was a request [1] to split the utilities that come with >>> libsndfile into a utils subpackage. I did this only for F-13. >>> >>> Since libsndfile is used by so many other software, it is impractical >>> for me to check all of these software to see if any of them depends on >>> these command line utilities. If you have a package that depends on >>> libsndfile, it would be good to check whether it uses these utilities. >>> Then you'll need to require libsndfile-utils directly. If your package >>> just needs the library there is nothing to worry about. Again, the >>> utils split is only made in F-13. >>> >>> Other than that, libsndfile is updated to 1.0.20 in F-10+. Also, now >>> it has the libvorbis support enabled. >> >> Any chance of getting the jack-audio-connection-kit dependency split >> out into a sub package? >> > > I think that the jack dependency comes from one of the command line > utilities of libsndfile which are now separated into the > libsndfile-tools package. > > Note that here "now" means F-13+. I didn't want to make the split on > F-12 and before as it might break potential direct dependencies on > these utilities. This will give packagers a full release cycle to find > regressions if there are any. Or am I too paranoid? F-13+ is just fine. Cheers, Peter From dbhole at redhat.com Tue Nov 17 20:52:43 2009 From: dbhole at redhat.com (Deepak Bhole) Date: Tue, 17 Nov 2009 15:52:43 -0500 Subject: Status of maven 2.2.1 update in rawhide Message-ID: <20091117205242.GC13169@redhat.com> Hi Everyone, Sorry for the cross-list posting, but the matter is of interest to both lists afaict, as I have seen messages related to maven on both. As some of you might know, we intend to put maven 2.2.1 in rawhide. The new maven will be a completely re-written rpm, one that should be a lot easier to maintain, and much more stable. All progress related to this upgrade is now on the wiki: https://fedoraproject.org/wiki/MavenUpdate Updates/new packages for dependencies will be a significant effort. Once we (Andrew Overholt, Alexander Kurtakov and myself) start work on that, we will need all the help we can get :) So if you are interested in helping, or just tracking progress -- that is the page to subscribe to/check out! I'll send one more mail to this list when work on dependencies starts. Cheers, Deepak From cjb at laptop.org Tue Nov 17 20:56:16 2009 From: cjb at laptop.org (Chris Ball) Date: Tue, 17 Nov 2009 15:56:16 -0500 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <4B030A64.80907@redhat.com> (Casey Dahlin's message of "Tue, 17 Nov 2009 15:41:08 -0500") References: <4B025423.3070309@nodata.co.uk> <4B025562.5020109@pobox.com> <4B02CB8F.8020702@redhat.com> <210.1258476521@sss.pgh.pa.us> <1258482785.31861.14.camel@code.and.org> <1b7401870911171105y51567671ne18d7c2857406f72@mail.gmail.com> <1258484843.2485.15.camel@localhost.localdomain> <4B030A64.80907@redhat.com> Message-ID: Hi, > I'm not sure how much of this can/should be automated. Sorry, not quite following -- what is the caution around automatically creating a new snapshot before each yum transaction? Why shouldn't it be automated? > This also keeps us out of the dangerous territory that comes with > using non-ubiquitous FS features (your boot is on ext3, your root > is on btrfs, your etc is on xfs and your usr is on jfs. What do > you snapshot and how?) This feature would snapshot the btrfs / only, but that doesn't matter, because snapshots don't do anything until the user chooses to initiate a rollback. The user who chooses a btrfs / and a jfs /usr knows what happens when they rollback only the btrfs filesystem. (And we can print a warning to make sure of that if we decide it's necessary.) Thanks, - Chris. -- Chris Ball One Laptop Per Child From cdahlin at redhat.com Tue Nov 17 21:12:35 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Tue, 17 Nov 2009 16:12:35 -0500 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: References: <4B025423.3070309@nodata.co.uk> <4B025562.5020109@pobox.com> <4B02CB8F.8020702@redhat.com> <210.1258476521@sss.pgh.pa.us> <1258482785.31861.14.camel@code.and.org> <1b7401870911171105y51567671ne18d7c2857406f72@mail.gmail.com> <1258484843.2485.15.camel@localhost.localdomain> <4B030A64.80907@redhat.com> Message-ID: <4B0311C3.2030002@redhat.com> On 11/17/2009 03:56 PM, Chris Ball wrote: > Hi, > > > I'm not sure how much of this can/should be automated. > > Sorry, not quite following -- what is the caution around automatically > creating a new snapshot before each yum transaction? Why shouldn't it > be automated? > I somewhat read the initial suggestion as trying to implement transactional behavior via snapshot. Just creating one shouldn't hurt. > > This also keeps us out of the dangerous territory that comes with > > using non-ubiquitous FS features (your boot is on ext3, your root > > is on btrfs, your etc is on xfs and your usr is on jfs. What do > > you snapshot and how?) > > This feature would snapshot the btrfs / only, but that doesn't matter, > because snapshots don't do anything until the user chooses to initiate > a rollback. The user who chooses a btrfs / and a jfs /usr knows what > happens when they rollback only the btrfs filesystem. (And we can > print a warning to make sure of that if we decide it's necessary.) > We've now created a useless and slightly dangerous object though. Regardless of the competence of the user who's problem that is, better to avoid it if we can. > Thanks, > > - Chris. --CJD From maillist at diffingo.com Tue Nov 17 21:17:07 2009 From: maillist at diffingo.com (Stewart Adam) Date: Tue, 17 Nov 2009 16:17:07 -0500 Subject: [SoaS] Booting Fedora live USB on MacBookPro In-Reply-To: <4B01763C.70205@redhat.com> References: <1257882057.1551.148.camel@giskard> <4AF9EC0D.3030203@redhat.com> <4AFA59EA.4070302@diffingo.com> <4B01763C.70205@redhat.com> Message-ID: <4B0312D3.2080402@diffingo.com> On 2009/11/16 10:56 AM, Peter Jones wrote: > On 11/11/2009 01:30 AM, Stewart Adam wrote: >> On 2009/11/10 5:41 PM, Peter Jones wrote: >>> On 11/10/2009 05:37 PM, Caryl Bigenho wrote: >>>> >>>> Hi, >>>> >>>> My MacBook is a 4,1. Will it work on my machine? >>> >>> A 64-bit EFI image should work on a MacBook4,1 . A 32-bit EFI image >>> won't. >>> >> >> If the silver MBP is also a 4,1 model, there may be complications... >> There are some video initialization problems [1] when booting EFI kernels. >> >> Stewart >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=496134 > > Yeah. If somebody had one of these machines at FudCon in Toronto, I > could probably knock this out in relatively short time. I know that it can be harder to debug if you're not at the machine, but if I can provide you with any info I'll be happy to do so - just let me know what I need to do. Stewart From ssorce at redhat.com Tue Nov 17 21:18:27 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 17 Nov 2009 16:18:27 -0500 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <4B0311C3.2030002@redhat.com> References: <4B025423.3070309@nodata.co.uk> <4B025562.5020109@pobox.com> <4B02CB8F.8020702@redhat.com> <210.1258476521@sss.pgh.pa.us> <1258482785.31861.14.camel@code.and.org> <1b7401870911171105y51567671ne18d7c2857406f72@mail.gmail.com> <1258484843.2485.15.camel@localhost.localdomain> <4B030A64.80907@redhat.com> <4B0311C3.2030002@redhat.com> Message-ID: <1258492707.12148.2894.camel@willson.li.ssimo.org> On Tue, 2009-11-17 at 16:12 -0500, Casey Dahlin wrote: > On 11/17/2009 03:56 PM, Chris Ball wrote: > > Hi, > > > > > I'm not sure how much of this can/should be automated. > > > > Sorry, not quite following -- what is the caution around > automatically > > creating a new snapshot before each yum transaction? Why shouldn't > it > > be automated? > > > > I somewhat read the initial suggestion as trying to implement > transactional behavior via snapshot. Just creating one shouldn't hurt. I fail to understand how a snapshot would differentiate between yum related changes and other changes that occur by an otherwise normally operating daemon (logs for example). Certainly you don't want to loose your logs when you want to revert a yum update ? What if you loose is something more important, like shared secrets (a kerberos keytab) that have changed during the transaction ? Simo. -- Simo Sorce * Red Hat, Inc * New York From cjb at laptop.org Tue Nov 17 21:20:06 2009 From: cjb at laptop.org (Chris Ball) Date: Tue, 17 Nov 2009 16:20:06 -0500 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <4B0311C3.2030002@redhat.com> (Casey Dahlin's message of "Tue, 17 Nov 2009 16:12:35 -0500") References: <4B025423.3070309@nodata.co.uk> <4B025562.5020109@pobox.com> <4B02CB8F.8020702@redhat.com> <210.1258476521@sss.pgh.pa.us> <1258482785.31861.14.camel@code.and.org> <1b7401870911171105y51567671ne18d7c2857406f72@mail.gmail.com> <1258484843.2485.15.camel@localhost.localdomain> <4B030A64.80907@redhat.com> <4B0311C3.2030002@redhat.com> Message-ID: Hi, > We've now created a useless and slightly dangerous object > though. Regardless of the competence of the user who's problem > that is, better to avoid it if we can. Okay. Perhaps the automated snapshot creation algorithm should be amended to something like: "check /proc/mounts for at least one btrfs, and zero other non-btrfs filesystems, except for /boot which can be anything." Thanks, - Chris. -- Chris Ball One Laptop Per Child From cjb at laptop.org Tue Nov 17 21:56:02 2009 From: cjb at laptop.org (Chris Ball) Date: Tue, 17 Nov 2009 16:56:02 -0500 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <1258492707.12148.2894.camel@willson.li.ssimo.org> (Simo Sorce's message of "Tue, 17 Nov 2009 16:18:27 -0500") References: <4B025423.3070309@nodata.co.uk> <4B025562.5020109@pobox.com> <4B02CB8F.8020702@redhat.com> <210.1258476521@sss.pgh.pa.us> <1258482785.31861.14.camel@code.and.org> <1b7401870911171105y51567671ne18d7c2857406f72@mail.gmail.com> <1258484843.2485.15.camel@localhost.localdomain> <4B030A64.80907@redhat.com> <4B0311C3.2030002@redhat.com> <1258492707.12148.2894.camel@willson.li.ssimo.org> Message-ID: Hi, >> I somewhat read the initial suggestion as trying to implement >> transactional behavior via snapshot. Just creating one shouldn't >> hurt. Ah. Yeah, not at all. > I fail to understand how a snapshot would differentiate between > yum related changes and other changes that occur by an otherwise > normally operating daemon (logs for example). If someone wanted to use whole-fs snapshots for yum transactions (which I don't) the way to do it would be to only rollback changes made to files that are present in either of the RPM manifests. - Chris. -- Chris Ball One Laptop Per Child From lsof at nodata.co.uk Tue Nov 17 22:02:04 2009 From: lsof at nodata.co.uk (nodata) Date: Tue, 17 Nov 2009 23:02:04 +0100 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <1258482793.14844.25.camel@tempo.alexander.bostrom.net> References: <4B025423.3070309@nodata.co.uk> <4B025562.5020109@pobox.com> <1258482793.14844.25.camel@tempo.alexander.bostrom.net> Message-ID: <4B031D5C.9010102@nodata.co.uk> Am 2009-11-17 19:33, schrieb Alexander Bostr?m: > tis 2009-11-17 klockan 02:48 -0500 skrev Jeff Garzik: > >> A bloody awful solution, especially when you consider that btrfs' >> maintainer Chris Mason is adding support for real userland transactions >> (via some additional ioctls). > > Yes. > > But the draft proposal is presented as "tools for experienced people" It has a gui... > rather than "cool feature for all", so I don't see the harm. (Check the > uses cases under Benefit to Fedora.) From pjones at redhat.com Tue Nov 17 22:19:51 2009 From: pjones at redhat.com (Peter Jones) Date: Tue, 17 Nov 2009 17:19:51 -0500 Subject: [SoaS] Booting Fedora live USB on MacBookPro In-Reply-To: <4B0312D3.2080402@diffingo.com> References: <1257882057.1551.148.camel@giskard> <4AF9EC0D.3030203@redhat.com> <4AFA59EA.4070302@diffingo.com> <4B01763C.70205@redhat.com> <4B0312D3.2080402@diffingo.com> Message-ID: <4B032187.9050008@redhat.com> On 11/17/2009 04:17 PM, Stewart Adam wrote: > On 2009/11/16 10:56 AM, Peter Jones wrote: >> On 11/11/2009 01:30 AM, Stewart Adam wrote: >>> On 2009/11/10 5:41 PM, Peter Jones wrote: >>>> On 11/10/2009 05:37 PM, Caryl Bigenho wrote: >>>>> >>>>> Hi, >>>>> >>>>> My MacBook is a 4,1. Will it work on my machine? >>>> >>>> A 64-bit EFI image should work on a MacBook4,1 . A 32-bit EFI image >>>> won't. >>>> >>> >>> If the silver MBP is also a 4,1 model, there may be complications... >>> There are some video initialization problems [1] when booting EFI >>> kernels. >>> >>> Stewart >>> >>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=496134 >> >> Yeah. If somebody had one of these machines at FudCon in Toronto, I >> could probably knock this out in relatively short time. > > I know that it can be harder to debug if you're not at the machine, but > if I can provide you with any info I'll be happy to do so - just let me > know what I need to do. There's nothing to /debug/. Somebody needs to figure out where the framebuffer is and what it's dimensions are, and then it needs to be added to the table. -- Peter From ikem.krueger at googlemail.com Tue Nov 17 22:38:31 2009 From: ikem.krueger at googlemail.com (Ikem Krueger) Date: Tue, 17 Nov 2009 22:38:31 +0000 Subject: Drop wodim, use cdrskin instead? In-Reply-To: <4B02E0B3.5080909@bwh.harvard.edu> References: <4B02E0B3.5080909@bwh.harvard.edu> Message-ID: > Contrary to what the man page says, wodim doesn't automatically format > DVD+RWs, so you have to fully format the disc in advance before using > wodim to write it. > https://bugzilla.redhat.com/show_bug.cgi?id=519465 Thanks. :) As I know that's not the only thing that's not fixed in Wodim and fixed in Cdrskin.. From ikem.krueger at googlemail.com Tue Nov 17 22:44:57 2009 From: ikem.krueger at googlemail.com (Ikem Krueger) Date: Tue, 17 Nov 2009 22:44:57 +0000 Subject: Xorg and multitouch Message-ID: Some news? Planned for Fedora 13? From cemeyer at u.washington.edu Tue Nov 17 22:47:05 2009 From: cemeyer at u.washington.edu (Conrad Meyer) Date: Tue, 17 Nov 2009 14:47:05 -0800 Subject: Broken deps for rawhide the past few days In-Reply-To: <1258469458.2485.2.camel@localhost.localdomain> References: <1258399367.15679.99.camel@localhost.localdomain> <1258469458.2485.2.camel@localhost.localdomain> Message-ID: <200911171447.05681.cemeyer@u.washington.edu> On Tuesday 17 November 2009 06:50:58 am Jesse Keating wrote: > On Mon, 2009-11-16 at 11:22 -0800, Jesse Keating wrote: > > Many of you received emails over the weekend and this morning regarding > > broken deps in rawhide. If these emails mentioned that the deps were > > broken on ppc or ppc64 they can be ignored. We are no longer producing > > ppc/ppc64 as a primary arch, however we forgot to tag the config change > > that enacted this on our compose tools. We were attempting to compose > > ppc(64) trees with only noarch packages, and well things didn't work so > > hot. > > > > We should have this fixed today so that future emails about broken deps > > will be about actual broken deps, not broken configurations. Sorry for > > the mailbombing. > > *sigh* > > While we were successful in building a new mash package that would avoid > making ppc repos, we forgot to update one of the rawhide creation > configs so that it used dist-f13 content as opposed to dist-f12. So the > rawhide creation process has been using dist-f12 content all this time > to build up the chroot, which would then compose dist-f13 content. This > means that the dist-f12 version of mash was used, not the dist-f13 > version we built to disable ppc. > > I've corrected that. Third try to kill the ppc deps should be the > charm. Could we just not send emails tomorrow, double check that it produces the correct result, and re-enable them for the next day? In case there's something else we-shouldn't-have-missed-but-we-did? -- Conrad Meyer From jkeating at j2solutions.net Tue Nov 17 22:50:48 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 17 Nov 2009 14:50:48 -0800 Subject: Broken deps for rawhide the past few days In-Reply-To: <200911171447.05681.cemeyer@u.washington.edu> References: <1258399367.15679.99.camel@localhost.localdomain> <1258469458.2485.2.camel@localhost.localdomain> <200911171447.05681.cemeyer@u.washington.edu> Message-ID: <337AC99A-1A2A-4DCC-B1B2-9E7F764EC240@j2solutions.net> On Nov 17, 2009, at 14:47, Conrad Meyer wrote: > On Tuesday 17 November 2009 06:50:58 am Jesse Keating wrote: >> On Mon, 2009-11-16 at 11:22 -0800, Jesse Keating wrote: >>> Many of you received emails over the weekend and this morning >>> regarding >>> broken deps in rawhide. If these emails mentioned that the deps >>> were >>> broken on ppc or ppc64 they can be ignored. We are no longer >>> producing >>> ppc/ppc64 as a primary arch, however we forgot to tag the config >>> change >>> that enacted this on our compose tools. We were attempting to >>> compose >>> ppc(64) trees with only noarch packages, and well things didn't >>> work so >>> hot. >>> >>> We should have this fixed today so that future emails about broken >>> deps >>> will be about actual broken deps, not broken configurations. >>> Sorry for >>> the mailbombing. >> >> *sigh* >> >> While we were successful in building a new mash package that would >> avoid >> making ppc repos, we forgot to update one of the rawhide creation >> configs so that it used dist-f13 content as opposed to dist-f12. >> So the >> rawhide creation process has been using dist-f12 content all this >> time >> to build up the chroot, which would then compose dist-f13 content. >> This >> means that the dist-f12 version of mash was used, not the dist-f13 >> version we built to disable ppc. >> >> I've corrected that. Third try to kill the ppc deps should be the >> charm. > > Could we just not send emails tomorrow, double check that it > produces the > correct result, and re-enable them for the next day? In case there's > something > else we-shouldn't-have-missed-but-we-did? > That's one of the changes I made today. -- Jes From nathanael at gnat.ca Tue Nov 17 23:10:48 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Tue, 17 Nov 2009 16:10:48 -0700 Subject: Review request... Message-ID: <4B032D78.1020409@gnat.ca> Hello, I just posted my first review request a few days ago. I think someone has been trying to help me through that process. Up to now I've felt like I've been following instructions. Could someone please review the information in the following (not necessarily review the request), to see if I've completely lost it and am not understanding what is being requested of me? I feel like I'm complying but got some odd message about not following instructions and so won't be helped. When I think I'm doing what they ask. Anyway a total packaging noob (for fedora atleast, we maintain a bunch of software in RPM format for CentOS and Fedora workstations inhouse). I've read the guidlines as best I can, and responded to requests on the review so I'm just wondering what I may be missing... https://bugzilla.redhat.com/show_bug.cgi?id=537587 Thanks, Nathanael From awilliam at redhat.com Tue Nov 17 23:19:51 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 17 Nov 2009 15:19:51 -0800 Subject: Xorg and multitouch In-Reply-To: References: Message-ID: <1258499991.9312.1.camel@adam.local.net> On Tue, 2009-11-17 at 22:44 +0000, Ikem Krueger wrote: > Some news? Planned for Fedora 13? The X level support is already in F12 - see http://fedoraproject.org/wiki/Features/XI2 . Application level support will come later -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From lsof at nodata.co.uk Tue Nov 17 23:22:12 2009 From: lsof at nodata.co.uk (nodata) Date: Wed, 18 Nov 2009 00:22:12 +0100 Subject: Xorg and multitouch In-Reply-To: <1258499991.9312.1.camel@adam.local.net> References: <1258499991.9312.1.camel@adam.local.net> Message-ID: <4B033024.9020605@nodata.co.uk> Am 2009-11-18 00:19, schrieb Adam Williamson: > On Tue, 2009-11-17 at 22:44 +0000, Ikem Krueger wrote: >> Some news? Planned for Fedora 13? > > The X level support is already in F12 - see > http://fedoraproject.org/wiki/Features/XI2 . Application level support > will come later > Is multi-touch the same as gesture support? From martin.sourada at gmail.com Tue Nov 17 23:38:31 2009 From: martin.sourada at gmail.com (Martin Sourada) Date: Wed, 18 Nov 2009 00:38:31 +0100 Subject: Review request... In-Reply-To: <4B032D78.1020409@gnat.ca> References: <4B032D78.1020409@gnat.ca> Message-ID: <1258501111.1870.7.camel@localhost.localdomain> On Tue, 2009-11-17 at 16:10 -0700, Nathanael D. Noblet wrote: > Hello, > I just posted my first review request a few days ago. I think someone > has been trying to help me through that process. Up to now I've felt > like I've been following instructions. Could someone please review the > information in the following (not necessarily review the request), to > see if I've completely lost it and am not understanding what is being > requested of me? I feel like I'm complying but got some odd message > about not following instructions and so won't be helped. When I think > I'm doing what they ask. > > Anyway a total packaging noob (for fedora atleast, we maintain a > bunch of software in RPM format for CentOS and Fedora workstations > inhouse). I've read the guidlines as best I can, and responded to > requests on the review so I'm just wondering what I may be missing... > > https://bugzilla.redhat.com/show_bug.cgi?id=537587 > > Thanks, > Nathanael > Hm... on a very quick first look, you obviously don't follow https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Release Your release should look something like 0.x.BETA4, not just BETA4. Plus every time you update the SPEC, you should also increase the x ;-) I'm not sure if it's explicitly in the guidelines somewhere or not (haven't ever used this kind of thing myself), but you appear to generate subpackages based on some build time conditionals -- (at least IMHO) it's not a good approach. Do you really need these conditionals anyway? Why not just build all the subpackages that are worth building? Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From itamar at ispbrasil.com.br Tue Nov 17 23:45:54 2009 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Tue, 17 Nov 2009 21:45:54 -0200 Subject: Review request... In-Reply-To: <1258501111.1870.7.camel@localhost.localdomain> References: <4B032D78.1020409@gnat.ca> <1258501111.1870.7.camel@localhost.localdomain> Message-ID: >> > Hm... on a very quick first look, you obviously don't follow > https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Release > Your release should look something like 0.x.BETA4, not just BETA4. Plus > every time you update the SPEC, you should also increase the x ;-) > > I'm not sure if it's explicitly in the guidelines somewhere or not > (haven't ever used this kind of thing myself), but you appear to > generate subpackages based on some build time conditionals -- (at least > IMHO) it's not a good approach. Do you really need these conditionals > anyway? Why not just build all the subpackages that are worth building? > > Martin > Can you post this info in the bug report ? -- ------------ Itamar Reis Peixoto e-mail/msn/google talk/sip: itamar at ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 From martin.sourada at gmail.com Wed Nov 18 00:09:40 2009 From: martin.sourada at gmail.com (Martin Sourada) Date: Wed, 18 Nov 2009 01:09:40 +0100 Subject: Review request... In-Reply-To: References: <4B032D78.1020409@gnat.ca> <1258501111.1870.7.camel@localhost.localdomain> Message-ID: <1258502980.1870.13.camel@localhost.localdomain> On Tue, 2009-11-17 at 21:45 -0200, Itamar Reis Peixoto wrote: > Can you post this info in the bug report ? I was just about to at your request (I think one of the two places is enough ;-) but noticed that Nathan was faster in applying relevant changes. Note that I haven't done a throughout check, only pointed what I noticed on quick look, so there *might* be more problems. Supposing I'll take a closer look at it tomorrow (no promises though), I'll point out anything other that I find in the bug report itself. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From bruno at wolff.to Wed Nov 18 00:49:50 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 17 Nov 2009 18:49:50 -0600 Subject: Name of the 'chess' package In-Reply-To: <20091116183602.GA8087@wolff.to> References: <20091116183602.GA8087@wolff.to> Message-ID: <20091118004950.GA6517@wolff.to> On Mon, Nov 16, 2009 at 12:36:02 -0600, Bruno Wolff III wrote: > We currently have a 3d chess game packaged as chess. I want to ask for > fedora hosted space for it sop that we can be upstream for some modernization > (with regard to ogre and gcc) changes. However it strikes me that the package > name probably shouldn't have been 'chess' as that is a generic name. Before > officially asking for fedora hosted space I wanted to see if there is > sentiment to making some name change for F13+ and fedora hosted. Possibilities > would be 3dchess (possibly still too generic), ogrechess (possibly misleading, > as people might think it had ogres for pieces), chess-ogre or ? As a followup, I have opened a ticket (https://fedorahosted.org/fedora-infrastructure/ticket/1822) to request a project for this under the name ogrechess. I expect eventually to want to change the package name to match, but there isn't a hurry. I might end up treating it as a new package (after getting most of the cleanup done) and obsoleting the old one. From jwboyer at gmail.com Tue Nov 17 23:21:53 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 17 Nov 2009 18:21:53 -0500 Subject: Review request... In-Reply-To: <4B032D78.1020409@gnat.ca> References: <4B032D78.1020409@gnat.ca> Message-ID: <20091117232153.GE19843@hansolo.jdub.homelinux.org> On Tue, Nov 17, 2009 at 04:10:48PM -0700, Nathanael D. Noblet wrote: > Hello, > I just posted my first review request a few days ago. I think someone > has been trying to help me through that process. Up to now I've felt > like I've been following instructions. Could someone please review the > information in the following (not necessarily review the request), to > see if I've completely lost it and am not understanding what is being > requested of me? I feel like I'm complying but got some odd message > about not following instructions and so won't be helped. When I think > I'm doing what they ask. > > Anyway a total packaging noob (for fedora atleast, we maintain a bunch > of software in RPM format for CentOS and Fedora workstations inhouse). > I've read the guidlines as best I can, and responded to requests on the > review so I'm just wondering what I may be missing... He is wanting you to increment Release each time you change something, and post a URL to the updated SRPM. There is a language barrier issue here, and the reviewer could have had a bit more patience. josh From ikem.krueger at googlemail.com Wed Nov 18 01:34:16 2009 From: ikem.krueger at googlemail.com (Ikem Krueger) Date: Wed, 18 Nov 2009 01:34:16 +0000 Subject: Xorg and multitouch In-Reply-To: <1258499991.9312.1.camel@adam.local.net> References: <1258499991.9312.1.camel@adam.local.net> Message-ID: > The X level support is already in F12 - see: http://fedoraproject.org/wiki/Features/XI2 > Application level support will come later Do you know when? I ask, because Windows and Mac OS already have them and Linux is a bit behind with it. Nevertheless I believe that our implementation will be better. ^^ From ikem.krueger at googlemail.com Wed Nov 18 01:38:45 2009 From: ikem.krueger at googlemail.com (Ikem Krueger) Date: Wed, 18 Nov 2009 01:38:45 +0000 Subject: Xorg and multitouch In-Reply-To: <4B033024.9020605@nodata.co.uk> References: <1258499991.9312.1.camel@adam.local.net> <4B033024.9020605@nodata.co.uk> Message-ID: > Is multi-touch the same as gesture support? As I know, nope. Multitouch means, several mousepointers and you can move them all seperately. Gesture support is, you make a certain sign with a mousepointer, and a certain action is triggered. Would be cool to see both together. I mean, several independent mousepointers, with each you can make a different gesture and different actions are triggered. ^^ From cjb at laptop.org Wed Nov 18 02:14:25 2009 From: cjb at laptop.org (Chris Ball) Date: Tue, 17 Nov 2009 21:14:25 -0500 Subject: Xorg and multitouch In-Reply-To: (Ikem Krueger's message of "Wed, 18 Nov 2009 01:38:45 +0000") References: <1258499991.9312.1.camel@adam.local.net> <4B033024.9020605@nodata.co.uk> Message-ID: Hi, > Multitouch means, several mousepointers and you can move them all > seperately. No, that's what multi-pointer means. Multi-Pointer X is already in F12. > Gesture support is, you make a certain sign with a mousepointer, > and a certain action is triggered. > > Would be cool to see both together. I mean, several independent > mousepointers, with each you can make a different gesture and > different actions are triggered. ^^ I'm sure you can achieve this gesture support today, again using MPX in F12. Multitouch refers to technologies that involve extrapolating from motion of finger-shaped blobs on your input device to the idea that a user has performed some continuous motion with said finger(s), and reacting appropriately. It's not the same as multi-pointer X, but it does use the same core technology. - Chris. -- Chris Ball One Laptop Per Child From mattdm at mattdm.org Wed Nov 18 04:23:57 2009 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 17 Nov 2009 23:23:57 -0500 Subject: intent to retire: kudzu In-Reply-To: <4B0176A0.3060009@redhat.com> References: <20091109202844.GA29552@nostromo.devel.redhat.com> <4AF87B54.5020807@fedoraproject.org> <4AFA5B98.7080000@diffingo.com> <4AFA8910.4010508@fedoraproject.org> <4B0176A0.3060009@redhat.com> Message-ID: <20091118042357.GB8183@jadzia.bu.edu> On Mon, Nov 16, 2009 at 10:58:24AM -0500, Peter Jones wrote: > Really, temporarily removing this is more desirable than merely passing > maintainership of kudzu around. Kudzu needs to actually go away. Yay! -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs / Instructional & Research Computing Computing & Information Technology Harvard School of Engineering & Applied Sciences From cjb at laptop.org Wed Nov 18 04:34:52 2009 From: cjb at laptop.org (Chris Ball) Date: Tue, 17 Nov 2009 23:34:52 -0500 Subject: RFC: Btrfs snapshots feature for F13 In-Reply-To: <1258472188.16176.55.camel@localhost.localdomain> (David Zeuthen's message of "Tue, 17 Nov 2009 10:36:28 -0500") References: <1258472188.16176.55.camel@localhost.localdomain> Message-ID: Hi David, thanks for the reply. > Yep, we're planning to add support to DeviceKit-disks for > exposing the (privileged) operations that btrfs may expose > (locked down by polkit, etc etc). There are also plans to expose > these operations in the UI in Palimpsest and/or Nautilus. I don't > think snapshots is going to have any Palimpsest UI (it belongs in > Nautilus I think) but the multi-disk stuff definitely will. I don't think it makes sense for the filesystem-level snapshot operations I describe in the feature proposal to be in Nautilus: https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs The proposal is about system-administrator decisions on what your root directory on btrfs will look like at next boot; they should only be performed by someone deep into "I am modifying the mount behavior of my fs" mode. (It does make sense for a Time Slider port to Btrfs, working with file-level operations on snapshots, to live inside Nautilus. That's not part of this proposal, but would be very useful work.) Given the above, do you think you'd be okay with having: Filesystem snapshot that will be active on next boot: and Create new whole-filesystem snapshot now: