From oget.fedora at gmail.com Wed Jul 1 00:24:53 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Tue, 30 Jun 2009 20:24:53 -0400 Subject: an update to automake-1.11? In-Reply-To: <1246385157.8362.127.camel@localhost.localdomain> References: <1246385157.8362.127.camel@localhost.localdomain> Message-ID: By the way, On Tue, Jun 30, 2009 at 2:05 PM, Owen Taylor wrote: > I was rather surprised to see: > > ?https://admin.fedoraproject.org/updates/F9/FEDORA-2009-6661 > ?https://admin.fedoraproject.org/updates/F10/FEDORA-2009-6076 > ?https://admin.fedoraproject.org/updates/F11/FEDORA-2009-6370 > > Where the automake was upgraded to 1.11 for F9, F10, and F11. > why is there no update information about these builds? There is a big "Notes" box on bodhi which is there for a reason. Orcan From mike at miketc.net Wed Jul 1 00:36:49 2009 From: mike at miketc.net (Mike Chambers) Date: Tue, 30 Jun 2009 19:36:49 -0500 Subject: kernel-2.6.29.5-206.fc11.x86_64 in koji Message-ID: <1246408609.2167.3.camel@scrappy.miketc.net> Installed this kernel, and upon boot it panics. I can't find anything in any logs, as it seems to happen upon first start of boot (as in during the "quiet" part of boot) before the processes are started to come up. -- Mike Chambers Madisonville, KY Fedora Project - Bugzapper, Tester, User, etc.. miketc302 at fedoraproject.org From MathStuf at gmail.com Wed Jul 1 01:01:45 2009 From: MathStuf at gmail.com (Ben Boeckel) Date: Tue, 30 Jun 2009 21:01:45 -0400 Subject: RFC: Kernel changes that may affect desktops References: <20090630135644.GA24165@srcf.ucam.org> <20090630161918.GA26920@srcf.ucam.org> <20090630225028.GA2360@srcf.ucam.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthew Garrett wrote: > On Wed, Jul 01, 2009 at 12:31:20AM +0200, Kevin Kofler wrote: > >> IMHO DeviceKit should just unmount it itself and notify the desktop that it >> has unmounted the device so the desktop can report it (or ignore it if it >> doesn't know about the event). I don't see why we need to add code to every >> desktop to listen for a "please unmount me" event and send an unmount >> request back when this could just be handled within DeviceKit. Or even >> within the kernel for that matter, do we really need a roundtrip through >> userspace for this? When and why would we ever want to do anything *other* >> than unmounting the device when this event triggers? > > Because you might want to warn the user that they have unsaved work that > will be lost if they continue? Isn't there "Save As..." for saving it? If not, I smell a bug report. When I'm working over sshfs and the network goes down, my editor still works with the file, the actual save is what fails. >> An additional problem is: what if the unmount fails due to open files? Your >> suggestion to just kill the applications sounds really broken to me. A >> forced unmount at kernel level and failing any attempts to further access >> that file just like what happens when an NFS mount goes offline sounds like >> a better solution to me. > > There are alternatives, like revoking the filehandles or prompting the > user to close the application themselves. This is the same problem faced > when unmounting any device. Umm, Windows locks files when they're opened. AFAIK, Linux doesn't enforce this. A similar problem is this: mkdir foo touch foo/bar kwrite foo/bar & rm -rf foo Should kwrite be killed because rm killed the directory? - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpKtXkACgkQiPi+MRHG3qTVrgCfXM3ItQpUBYzK1JT91RoJ4rjy fNEAoKEkgrII4JNkaundDYMv76fTAD69 =qUfz -----END PGP SIGNATURE----- From mjg at redhat.com Wed Jul 1 01:11:42 2009 From: mjg at redhat.com (Matthew Garrett) Date: Wed, 1 Jul 2009 02:11:42 +0100 Subject: RFC: Kernel changes that may affect desktops In-Reply-To: References: <20090630135644.GA24165@srcf.ucam.org> <20090630161918.GA26920@srcf.ucam.org> <20090630225028.GA2360@srcf.ucam.org> Message-ID: <20090701011142.GA5513@srcf.ucam.org> On Tue, Jun 30, 2009 at 09:01:45PM -0400, Ben Boeckel wrote: > Isn't there "Save As..." for saving it? If not, I smell a bug > report. When I'm working over sshfs and the network goes down, > my editor still works with the file, the actual save is what > fails. It depends on what resources you have open on the hardware. If part of your application is on the disk that's about to be disconnected, then you have problems. > Umm, Windows locks files when they're opened. AFAIK, Linux > doesn't enforce this. > > A similar problem is this: > > mkdir foo > touch foo/bar > kwrite foo/bar & > rm -rf foo > > Should kwrite be killed because rm killed the directory? No, because it still has a reference to it. Unmount works differently to remove. -- Matthew Garrett | mjg59 at srcf.ucam.org From dchen at redhat.com Wed Jul 1 01:52:30 2009 From: dchen at redhat.com (Ding Yi Chen) Date: Tue, 30 Jun 2009 21:52:30 -0400 (EDT) Subject: RFC: Kernel changes that may affect desktops In-Reply-To: <828709067.702491246413091832.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1953030807.702511246413150182.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> ----- "Matthew Garrett" wrote: > On Tue, Jun 30, 2009 at 05:48:44PM +0200, Kevin Kofler wrote: > > Matthew Garrett wrote: > > What changes are needed to the desktop? > > > > The big problem we've been facing integrating new features of core > system > > services into KDE so far was lack of documentation. What do we need > to > > change? > > An event will be generated and a policy agent then needs to choose > what > to do in terms of unmounting any media. The precise interface doesn't > > exist yet, but will be documented. > > > If this will be all handled within DeviceKit, then this will come by > itself > > with the Solid DeviceKit backend ltinkl is working on, but if we > need to > > add some desktop interaction for it, we have to know what it should > be. > > So, what you'll get is a notification that a block device has > requested > removal along with a notification that a dock device is being > undocked. > What you do with the block device is up to you, but in general you'll > > want to unmount it. Whether you're willing to kill applications that > have open files on it is a policy decision. After the unmount you'll > then trigger the completion of the undock and tell the user that it's > > now safe to remove their hardware. IMHO, it is pretty much similar to the way that we handle USB hubs and devices. In terms of UI, it may have a nice dock status icon to show status and to be pressed if users want to un-dock safely. Yet we still need to handle the force-undock event, just like we handle the forced unplug USB devices. -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ From notting at redhat.com Wed Jul 1 02:56:48 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 30 Jun 2009 22:56:48 -0400 Subject: FESCo meeting summary for 2009-06-26 In-Reply-To: References: <20090627000642.GA19010@srcf.ucam.org> <20090627013827.GC19838@srcf.ucam.org> <20090629155126.GB32653@nostromo.devel.redhat.com> <20090630023721.GC1165657@hiwaay.net> <20090630160057.GA22566@nostromo.devel.redhat.com> Message-ID: <20090701025648.GA1085@nostromo.devel.redhat.com> Kevin Kofler (kevin.kofler at chello.at) said: > The thing is, any moment is as good as any other to file a proposal to > FESCo, I don't see why I *shouldn't* have filed it now. I wasn't asking as a means of making an argument against it. I'm asking because this is something that could have been raised to FESCo at any time in the past by you (or others), regardless of your status on FESCo. The fact that you filed it immediately after joining FESCo, combined with your own statement of 'I've been proposing this on the mailing list for ages' and 'My platform was clear', makes the implication that it was *intentional* to wait until now, and in essence use a FESCo position as the colloquial bully pulpit. Which I find sort of sad. > > But hey, thanks for the unfounded assertion that everyone who voted > > against it was operating under false assumptions, and they could not > > possibly have any rational reasons for disagreeing with you. > > The arguments you (plural) have brought have been very weak. If there are > such "rational reasons", I'd like to read them! 1) You argue that the name 'Desktop' makes people think that it contains *all possible desktops*. I find that to be an extremely unlikely reading of the name. Given that to assume that you'd already have to know of other desktops, then you would already know what the 'KDE fans...' text means, or know what the long list of things on the torrent pages are. 2) I feel that changing the name on get-fedora doesn't give any benefits; it adds verbiage that's *already there* in the description. 3) On get-fedora-all... you're coming from a page (#2) that already describes it as being GNOME. 3) If you're talking about torrent.fp.o, the descriptions on that are so bad that there are a whole host of things that need fixed before one filename. Bill From cjb at laptop.org Wed Jul 1 03:06:38 2009 From: cjb at laptop.org (Chris Ball) Date: Tue, 30 Jun 2009 23:06:38 -0400 Subject: FESCo meeting summary for 2009-06-26 In-Reply-To: (Kevin Kofler's message of "Wed, 01 Jul 2009 00:04:17 +0200") References: <20090627000642.GA19010@srcf.ucam.org> <20090627013827.GC19838@srcf.ucam.org> <20090629155126.GB32653@nostromo.devel.redhat.com> <20090630023721.GC1165657@hiwaay.net> <20090630160057.GA22566@nostromo.devel.redhat.com> Message-ID: Hi Kevin, > It was because you (plural) didn't want to listen to my > arguments, you were just eager to shoot my proposal down no > matter what. I think this is your 60th post to this thread, in the four days that it's been going. I don't have anything to say about the thread itself, but I'd encourage you to take a break from the thread and consider what else you think it's important to add to it. This is just advice, naturally; I'm interested in ways that we can use this list more constructively. - Chris. -- Chris Ball From notting at redhat.com Wed Jul 1 03:16:34 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 30 Jun 2009 23:16:34 -0400 Subject: RFC: Kernel changes that may affect desktops In-Reply-To: <20090630231556.GC2279@hansolo.jdub.homelinux.org> References: <20090630135644.GA24165@srcf.ucam.org> <20090630182857.GK4832@hansolo.jdub.homelinux.org> <20090630231556.GC2279@hansolo.jdub.homelinux.org> Message-ID: <20090701031634.GA3094@nostromo.devel.redhat.com> Josh Boyer (jwboyer at gmail.com) said: > So I agree breaking things is bad, and in general we should all try and play > nice and communicate about upcoming changes. Which is exactly what Matthew > has done by starting this very thread. Good for him. And, to be honest, I think a hack that just returns 'hey, do whatever' to the kernel (thereby preserving the old behavior) would be pretty darn simple. Bill From jonathan at jonmasters.org Wed Jul 1 03:29:03 2009 From: jonathan at jonmasters.org (Jon Masters) Date: Tue, 30 Jun 2009 23:29:03 -0400 Subject: KSplice in Fedora? In-Reply-To: References: <8278b1b0906291521i45f71873n2da7cda47161bb2d@mail.gmail.com> <4A49640B.9070202@cchtml.com> Message-ID: <1246418943.5270.226.camel@perihelion.bos.jonmasters.org> Hi folks, Ksplice is very interesting and I've spoken with a few people about it before. I met the (local to Cambridge, MA) ksplice guys several times and recently talked to them about the kinds of things they're doing right now. Uptrack is a nice showcase of the technology for sure. More comments below... On Tue, 2009-06-30 at 04:49 +0200, Kevin Kofler wrote: > Michael Cronenworth wrote: > > From looking at their website, it sounds like this software can take > > you from say kernel 2.6.27 to 2.6.29 without rebooting? Sounds like > > black magic. I'm intrigued. It relies upon using the existing module loading code to stop the kernel at a given moment in time (which might have to be attempted several times before succeeding in applying the ksplice patch, if the code paths being updated are currently being exercised) and inserts careful jumps to new code replacing existing functions wholesale with new ones. > It actually can't and this is why it isn't very useful within Fedora, as we > get big updates, not just minimal security patches. It would be useful for stable security updates in an enterprise distribution, and it is useful to some people in community distributions - but there's a lot of effort involved and this is where the ksplice guys have invested time in their infrastructure which we would have to entirely duplicate (and engineers too) to do this in Fedora. > KSplice can't handle that kind of updates. Actually, it technically can. > It can only handle small patches which don't change any data structures. That's a load of . I'm not sure where you get this idea from - perhaps because it's not obvious how they might achieve structural updates and so you assume it cannot be done - but actually, they can handle most kinds of update. They achieve this with shadow data structure tracking and manage the ABI differences - see the paper - and implement pre/post code hooks for things that cannot be done without a human kernel engineer. So you can also apply initcall-time fixes by implementing a custom pre-hook to perform what would happen at boot. But anyway, yes, it gets complex. And I've no doubt that for the Ubuntu kernel they're doing this for at the moment they have some of the kernel engineers they have on staff actively writing pre/post hooks. > So the official Fedora kernel updates will never be > suitable to be distributed through KSplice. That's not technically true either. It's just not practical. We would need a much larger team of people and all of the infrastructure tools developed by the ksplice guys. And it's indeterminate what the end goal would be from that - most people are happy to reboot occasionally, and those who are not can already pay Ksplice, Inc. to make updates for them. I'm not sure this is something Fedora can practically offer. Also - for those kernel folks reading. Don't discount ksplice because it sounds ugly. Tim and Waseem really do get it, and they know what they're doing - and they're actively engaging with upstream to get the bits that could be in the mainline kernel in there (ksplice doesn't require any existing kernel modifications because it also injects its own code during the ksplice patch application as part of the wrapper module). I suggest if you're interested in "add this random code patch here" type of kernel development/testing that you add ksplice to the toolbox. Jon. From rc040203 at freenet.de Wed Jul 1 05:30:37 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 01 Jul 2009 07:30:37 +0200 Subject: an update to automake-1.11? In-Reply-To: References: <1246385157.8362.127.camel@localhost.localdomain> <20090630213457.GC22149@redhat.com> Message-ID: <4A4AF47D.8030503@freenet.de> Kevin Kofler wrote: > Daniel P. Berrange wrote: >> This is seriously dubious for F9, since if it causes a problem there >> is next to no time in which to fix it before F9 updates are turned >> off. In general I struggle to believe that there is a compelling >> need to rebase automake versions in our stable releases. > > Some software may need the new version to build. Very unlikely. However, this upgrade may break rebuilding some of the packages whose packagers refuse to accept that running the autotools during builts is harmful. Anyway, the changes between automake-1.10 and automake-1.11 have been comparatively harmless. Ralf From ich at frank-schmitt.net Wed Jul 1 06:44:57 2009 From: ich at frank-schmitt.net (Frank Schmitt) Date: Wed, 01 Jul 2009 08:44:57 +0200 Subject: KSplice in Fedora? References: <8278b1b0906291521i45f71873n2da7cda47161bb2d@mail.gmail.com> <1246354287.20189.56.camel@breeves.fab.redhat.com> <1246377541.20189.86.camel@breeves.fab.redhat.com> <4A4A45B2.90808@bfccomputing.com> Message-ID: Kevin Kofler writes: > Bill McGonigle wrote: >> The parenthetical is the actual reason people don't like to reboot and >> may ignore security updates. Boot times are trivial in comparison to >> restoring one's application state, for anything beyond the most trivial >> of use cases. > > The average home user turns his/her computer off when going to sleep, so > he/she reboots at least once per day. Heck, even I do that. Leaving my > computer running when I sleep wastes power and makes me sleep badly > (probably because of the noise from the fans, though I don't exclude > electromagnetic waves possibly having to do with it as well (but no, I > don't use tinfoil hats or similar nonsense ;-) )). Home users with record > uptimes are a small minority, even if there are probably many of those on > this list. I think most people hibernate or suspend when they go to sleep. -- Have you ever considered how much text can fit in eighty columns? Given that a signature typically contains up to four lines of text, this space allows you to attach a tremendous amount of valuable information to your messages. Seize the opportunity and don't waste your signature on bullshit that nobody cares about. From ovasik at redhat.com Wed Jul 1 07:02:59 2009 From: ovasik at redhat.com (=?UTF-8?Q?Ond=C5=99ej_Va=C5=A1=C3=ADk?=) Date: Wed, 01 Jul 2009 09:02:59 +0200 Subject: an update to automake-1.11? In-Reply-To: <1246385157.8362.127.camel@localhost.localdomain> References: <1246385157.8362.127.camel@localhost.localdomain> Message-ID: <1246431779.3872.18.camel@dhcp-lab-219.englab.brq.redhat.com> Owen Taylor wrote: > I was rather surprised to see: > > https://admin.fedoraproject.org/updates/F9/FEDORA-2009-6661 > https://admin.fedoraproject.org/updates/F10/FEDORA-2009-6076 > https://admin.fedoraproject.org/updates/F11/FEDORA-2009-6370 > > Where the automake was upgraded to 1.11 for F9, F10, and F11. Upgrade on F-11 (and F-10) was requested because there are some projects (like gnulib/coreutils) which really need automake 1.11 for build in latest stable versions. Anyway I'm a bit surprised by F-9 update - as we argumented by more possible projects with need for automake-1.11 during F-10/F-11 lifecycle. Packages automake/autoconf are special - as you need them not only for packaging, but for building not packaged projects from git/whatever upstream repos. Yes, you could always compile latest autotools as well and use them, but automake 1.10 is ~2 years old software. AFAIK there were no incompatibility changes in automake, so the only problem could be if the program relies on exact automake version - which is imho wrong. > In general automake hasn't had a very good track record of compatibility > between 1.x and 1.y, though this has been getting better recently. Previous automake 1.10 is more than 2 years old, automake 1.10b and beta release were used at least for building testing gnulib and coreutils project and there were no troubles. Ralf Wildenhues is very conservative with changes - which is good for projects like automake/autoconf. Therefore I don't expect incompatibility issues. Anyone experienced troubles with latest automake in rawhide (other than exact automake version check)? If so - it's still in testing, so it still could (and for F-9 imho anyway should) be unpushed... Greetings, Ond?ej Va??k -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Toto je digit?ln? podepsan? ??st zpr?vy URL: From ngompa13 at gmail.com Wed Jul 1 07:19:22 2009 From: ngompa13 at gmail.com (King InuYasha) Date: Wed, 1 Jul 2009 02:19:22 -0500 Subject: KSplice in Fedora? In-Reply-To: References: <8278b1b0906291521i45f71873n2da7cda47161bb2d@mail.gmail.com> <1246354287.20189.56.camel@breeves.fab.redhat.com> <1246377541.20189.86.camel@breeves.fab.redhat.com> <4A4A45B2.90808@bfccomputing.com> Message-ID: <8278b1b0907010019v265cd2e1qe568363b46266bde@mail.gmail.com> On Wed, Jul 1, 2009 at 1:44 AM, Frank Schmitt wrote: > Kevin Kofler writes: > > > Bill McGonigle wrote: > >> The parenthetical is the actual reason people don't like to reboot and > >> may ignore security updates. Boot times are trivial in comparison to > >> restoring one's application state, for anything beyond the most trivial > >> of use cases. > > > > The average home user turns his/her computer off when going to sleep, so > > he/she reboots at least once per day. Heck, even I do that. Leaving my > > computer running when I sleep wastes power and makes me sleep badly > > (probably because of the noise from the fans, though I don't exclude > > electromagnetic waves possibly having to do with it as well (but no, I > > don't use tinfoil hats or similar nonsense ;-) )). Home users with record > > uptimes are a small minority, even if there are probably many of those on > > this list. > > I think most people hibernate or suspend when they go to sleep. > > -- > Have you ever considered how much text can fit in eighty columns? Given > that a > signature typically contains up to four lines of text, this space allows > you to > attach a tremendous amount of valuable information to your messages. Seize > the > opportunity and don't waste your signature on bullshit that nobody cares > about. > Since hibernate has been broken for the last three releases of Fedora, I do suspend to RAM. I wish hibernate worked though. Either way, I don't like rebooting and I think something like this would be great. Most the people I do know, even non-techies, generally either suspend or hibernate the machine since they don't want to wait for the system to start up. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtasaka at ioa.s.u-tokyo.ac.jp Wed Jul 1 07:29:59 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 01 Jul 2009 16:29:59 +0900 Subject: newrepo tasks freezing? Message-ID: <4A4B1077.2060109@ioa.s.u-tokyo.ac.jp> Hello: It seems that on koji newrepo tasks are all freezing: http://koji.fedoraproject.org/koji/taskinfo?taskID=1444680 http://koji.fedoraproject.org/koji/taskinfo?taskID=1444681 http://koji.fedoraproject.org/koji/taskinfo?taskID=1444815 Would someone investigate what is occuring? Regards, Mamoru From frankly3d at gmail.com Wed Jul 1 07:41:08 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Wed, 01 Jul 2009 08:41:08 +0100 Subject: FESCo meeting summary for 2009-06-26 In-Reply-To: References: <20090627013827.GC19838@srcf.ucam.org> <20090629155126.GB32653@nostromo.devel.redhat.com> <20090630023721.GC1165657@hiwaay.net> Message-ID: <4A4B1314.7020605@gmail.com> On 01/07/09 00:22, inode0 wrote: > > So if the community agreed to these two changes, which seem reasonable > to me, then what? Well, I think at this point we hit the real wall in > this debate, but I really don't think we can avoid the subsequent > requests for more equal treatment by refusing to call GNOME GNOME. > > John > +1 Frank From paul at city-fan.org Wed Jul 1 09:40:40 2009 From: paul at city-fan.org (Paul Howarth) Date: Wed, 01 Jul 2009 10:40:40 +0100 Subject: Segfault connecting to a VPN through NetworkManager In-Reply-To: <9497e9990906301352s35c97ac9oc0253217b382481@mail.gmail.com> References: <9497e9990906301352s35c97ac9oc0253217b382481@mail.gmail.com> Message-ID: <4A4B2F18.2090004@city-fan.org> On 30/06/09 21:52, Mat Booth wrote: > Hi, > > I got this segfault trying to connect to the Microsoft VPN at work. [1] > > What should I raise a ticket against? NetworkManager, kernel, pptp, > none of the above? > > [1] http://mbooth.fedorapeople.org/vpn-bug.txt Looks like pptp to me; can you repeat the segfault with pptp-debuginfo installed? Paul. From P at draigBrady.com Wed Jul 1 09:40:37 2009 From: P at draigBrady.com (=?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?=) Date: Wed, 1 Jul 2009 10:40:37 +0100 Subject: an update to automake-1.11? In-Reply-To: <1246431779.3872.18.camel@dhcp-lab-219.englab.brq.redhat.com> References: <1246385157.8362.127.camel@localhost.localdomain> <1246431779.3872.18.camel@dhcp-lab-219.englab.brq.redhat.com> Message-ID: <4A4B2F15.7020401@draigBrady.com> Ond?ej Va??k wrote: > Owen Taylor wrote: >> I was rather surprised to see: >> >> https://admin.fedoraproject.org/updates/F9/FEDORA-2009-6661 >> https://admin.fedoraproject.org/updates/F10/FEDORA-2009-6076 >> https://admin.fedoraproject.org/updates/F11/FEDORA-2009-6370 >> >> Where the automake was upgraded to 1.11 for F9, F10, and F11. > > Upgrade on F-11 (and F-10) was requested because there are some projects > (like gnulib/coreutils) which really need automake 1.11 for build in > latest stable versions. To clarify, coreutils needs automake only for development, but it is nice not to have to build it as described here: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=README-prereq;hb=HEAD I am surprised it was pused to F9 & F10 cheers, P?draig. From skasal at redhat.com Wed Jul 1 09:52:20 2009 From: skasal at redhat.com (Stepan Kasal) Date: Wed, 1 Jul 2009 11:52:20 +0200 Subject: an update to automake-1.11? In-Reply-To: <1246385157.8362.127.camel@localhost.localdomain> References: <1246385157.8362.127.camel@localhost.localdomain> Message-ID: <20090701095220.GC19366@camelia.ucw.cz> Hi, On Tue, Jun 30, 2009 at 02:05:57PM -0400, Owen Taylor wrote: > In general automake hasn't had a very good track record of compatibility > between 1.x and 1.y, though this has been getting better recently. Yeah, there were some serious problems with the redisign in 2001. Recently = since 1.8, at least. So we are observing more than 5 years of good track. > But is this the type of upgrade that makes sense in general? It seems to > me that we should be very conservative in upgrading build tools, > especially in "maintenance mode" distributions like F9 and F10. Well, in a sense, Automake is not a build tool, it's more a maintainer tool. In the typical case, it is run interactively by the maintainer of a package to create the tarball. Yes, there are many cases where automake is run from the spec file and these are in danger. If there were a backward compatibility bug, these may not rebuild. But, AFAIK, this is not anything that would prevent people from using Fedora. OTOH, people might want to use Fedora for software development. And building new versions of software packages might require new features or rely on Automake bugs being fixed. IOW, what's Fedora good for after its EOL? If it is a museum artifact, then I'm spoiling the game. If it is to be used in real life, then update to Automake 1.11 is beneficial for the developers using it and harmless for the non-developer uses (office, proxy, etc.) > But it is also a pretty long release announcement so it wouldn't > surprise me if there were some subtle incompatibilities. The Automake maintainer is very careful. So it would not surprise me if the amount of incompatibilities would be surprisingly small. > The only breakage I'm actually aware of in the gnome-common package; Yeah, that is a very clumsy package. > gnome-common-2.26 and earlier doesn't know that automake-1.11 is > a valid replacement when automake-1.10 is asked for. Consider telling it that 1.12 is going to be a valid replacement for both of these as well. Stepan From mtasaka at ioa.s.u-tokyo.ac.jp Wed Jul 1 09:52:14 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 01 Jul 2009 18:52:14 +0900 Subject: newrepo tasks freezing? In-Reply-To: <4A4B1077.2060109@ioa.s.u-tokyo.ac.jp> References: <4A4B1077.2060109@ioa.s.u-tokyo.ac.jp> Message-ID: <4A4B31CE.1030501@ioa.s.u-tokyo.ac.jp> Mamoru Tasaka wrote, at 07/01/2009 04:29 PM +9:00: > Hello: > > It seems that on koji newrepo tasks are all freezing: > http://koji.fedoraproject.org/koji/taskinfo?taskID=1444680 > http://koji.fedoraproject.org/koji/taskinfo?taskID=1444681 > http://koji.fedoraproject.org/koji/taskinfo?taskID=1444815 > Would someone investigate what is occuring? > It seems that new newrepo tasks completed successfully. Mamoru From skasal at redhat.com Wed Jul 1 10:05:07 2009 From: skasal at redhat.com (Stepan Kasal) Date: Wed, 1 Jul 2009 12:05:07 +0200 Subject: an update to automake-1.11? In-Reply-To: References: <1246385157.8362.127.camel@localhost.localdomain> Message-ID: <20090701100507.GA19903@camelia.ucw.cz> Hi, On Tue, Jun 30, 2009 at 08:24:53PM -0400, Orcan Ogetbil wrote: > why is there no update information about these builds? There is a big > "Notes" box on bodhi which is there for a reason. I apologize for that. I got bored writing three-word nonsenses so I tried the null string. I will do better now when I know that it might be read by someone in certain cases. Stepan From skasal at redhat.com Wed Jul 1 10:06:52 2009 From: skasal at redhat.com (Stepan Kasal) Date: Wed, 1 Jul 2009 12:06:52 +0200 Subject: an update to automake-1.11? In-Reply-To: References: <1246385157.8362.127.camel@localhost.localdomain> <20090630213457.GC22149@redhat.com> Message-ID: <20090701100652.GD19366@camelia.ucw.cz> Hello, On Tue, Jun 30, 2009 at 06:58:39PM -0400, Sam Varshavchik wrote: > Kevin Kofler writes: >> Some software may need the new version to build. > > Then, they need to be patched so that they would get built for F9, or > they should not be built for F9 altogether. I'm afraid the answer shows you do not fully understand the context. Sorry, Stepan From mschwendt at gmail.com Wed Jul 1 10:12:10 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 01 Jul 2009 10:12:10 -0000 Subject: Broken dependencies in Fedora 11 - 2009-07-01 Message-ID: <20090701101210.4935.64098@noname> ====================================================================== The results in this summary consider Test Updates! ====================================================================== Summary of broken packages (by src.rpm name): beagle f-spot gauche-gl gauche-gtk gbrainy gnome-do gnome-keyring-sharp gnome-phone-manager ipod-sharp lat liferea muine notify-sharp podsleuth ppl python-repoze-what sunbird tomboy wine ====================================================================== Broken packages in fedora-11-i386: gauche-gl-0.4.4-4.fc11.i586 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.i586 requires gauche = 0:0.8.13 liferea-WebKit-1.4.26-2.fc11.i586 requires liferea = 0:1.4.26 ====================================================================== Broken packages in fedora-11-ppc: gauche-gl-0.4.4-4.fc11.ppc requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.ppc requires gauche = 0:0.8.13 liferea-WebKit-1.4.26-2.fc11.ppc requires liferea = 0:1.4.26 ====================================================================== Broken packages in fedora-11-ppc64: liferea-WebKit-1.4.26-2.fc11.ppc64 requires liferea = 0:1.4.26 ====================================================================== Broken packages in fedora-11-x86_64: gauche-gl-0.4.4-4.fc11.x86_64 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.x86_64 requires gauche = 0:0.8.13 liferea-WebKit-1.4.26-2.fc11.x86_64 requires liferea = 0:1.4.26 ====================================================================== Broken packages in fedora-updates-11-i386: ppl-yap-0.10.2-2.fc11.i586 requires libYap.so ====================================================================== Broken packages in fedora-updates-11-ppc: ppl-yap-0.10.2-2.fc11.ppc requires libYap.so ====================================================================== Broken packages in fedora-updates-11-ppc64: ppl-yap-0.10.2-2.fc11.ppc64 requires libYap.so()(64bit) tomboy-0.14.2-1.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 tomboy-0.14.2-1.fc11.ppc64 requires mono(Mono.Addins.Setup) = 0:0.4.0.0 tomboy-0.14.2-1.fc11.ppc64 requires mono(Mono.Addins) = 0:0.4.0.0 tomboy-0.14.2-1.fc11.ppc64 requires mono(Mono.Addins.Gui) = 0:0.4.0.0 tomboy-0.14.2-1.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 ====================================================================== Broken packages in fedora-updates-11-x86_64: ppl-yap-0.10.2-2.fc11.x86_64 requires libYap.so()(64bit) wine-esd-1.1.23-1.fc11.i586 requires wine-core = 0:1.1.23-1.fc11 wine-jack-1.1.23-1.fc11.i586 requires wine-core = 0:1.1.23-1.fc11 wine-nas-1.1.23-1.fc11.i586 requires wine-core = 0:1.1.23-1.fc11 ====================================================================== Broken packages in fedora-updates-testing-11-i386: gnome-phone-manager-0.65-2.fc11.i586 requires libgnome-bluetooth.so.2 python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 thunderbird-lightning-1.0-0.5.20090513hg.fc11.i586 requires thunderbird >= 0:3.0-2.4.b3pre ====================================================================== Broken packages in fedora-updates-testing-11-ppc: gnome-phone-manager-0.65-2.fc11.ppc requires libgnome-bluetooth.so.2 python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 thunderbird-lightning-1.0-0.5.20090513hg.fc11.ppc requires thunderbird >= 0:3.0-2.4.b3pre ====================================================================== Broken packages in fedora-updates-testing-11-ppc64: beagle-0.3.9-8.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0 beagle-0.3.9-8.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 beagle-0.3.9-8.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 beagle-0.3.9-8.fc11.ppc64 requires mono(taglib-sharp) = 0:2.0.3.2 beagle-evolution-0.3.9-8.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0 beagle-gnome-0.3.9-8.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 beagle-gnome-0.3.9-8.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 beagle-thunderbird-0.3.9-8.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0 f-spot-0.5.0.3-9.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 f-spot-0.5.0.3-9.fc11.ppc64 requires mono(Mono.Addins.Setup) = 0:0.4.0.0 f-spot-0.5.0.3-9.fc11.ppc64 requires mono(Mono.Addins) = 0:0.4.0.0 f-spot-0.5.0.3-9.fc11.ppc64 requires mono(Mono.Addins.Gui) = 0:0.4.0.0 f-spot-0.5.0.3-9.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 gbrainy-1.1-4.fc11.ppc64 requires mono(Mono.Addins) = 0:0.4.0.0 gbrainy-1.1-4.fc11.ppc64 requires mono(Mono.Addins.Setup) = 0:0.4.0.0 gbrainy-1.1-4.fc11.ppc64 requires mono(Mono.Addins.Gui) = 0:0.4.0.0 gnome-do-0.8.1.3-6.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 gnome-do-0.8.1.3-6.fc11.ppc64 requires mono(Mono.Addins.Setup) = 0:0.4.0.0 gnome-do-0.8.1.3-6.fc11.ppc64 requires mono(Mono.Addins) = 0:0.4.0.0 gnome-keyring-sharp-1.0.1-0.3.115768svn.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 gnome-phone-manager-0.65-2.fc11.ppc64 requires libgnome-bluetooth.so.2()(64bit) ipod-sharp-0.8.1-3.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 lat-1.2.3-7.fc11.ppc64 requires dbus-sharp muine-0.8.10-5.fc11.ppc64 requires ndesk-dbus-glib notify-sharp-0.4.0-0.7.20080912svn.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 notify-sharp-0.4.0-0.7.20080912svn.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 podsleuth-0.6.3-3.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 thunderbird-lightning-1.0-0.5.20090513hg.fc11.ppc64 requires thunderbird >= 0:3.0-2.4.b3pre ====================================================================== Broken packages in fedora-updates-testing-11-x86_64: gnome-phone-manager-0.65-2.fc11.x86_64 requires libgnome-bluetooth.so.2()(64bit) python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 thunderbird-lightning-1.0-0.5.20090513hg.fc11.x86_64 requires thunderbird >= 0:3.0-2.4.b3pre From skasal at redhat.com Wed Jul 1 10:15:14 2009 From: skasal at redhat.com (Stepan Kasal) Date: Wed, 1 Jul 2009 12:15:14 +0200 Subject: an update to automake-1.11? In-Reply-To: <4A4AF47D.8030503@freenet.de> References: <1246385157.8362.127.camel@localhost.localdomain> <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> Message-ID: <20090701101514.GB19903@camelia.ucw.cz> Hello, On Wed, Jul 01, 2009 at 07:30:37AM +0200, Ralf Corsepius wrote: > Kevin Kofler wrote: >> Some software may need the new version to build. > > Very unlikely. There are people using the new features, like Jim Mayering, the coreutils maintainer, and others. Building checkouts or even tarballs of their projects on F9 might be a problem. > However, this upgrade may break rebuilding some of the packages whose > packagers refuse to accept that running the autotools during builts is > harmful. But this is not too likely either. Only a minority of Fedora packages does run autotools in their spec files. > Anyway, the changes between automake-1.10 and automake-1.11 have > been comparatively harmless. Thank you for saying that. (Yes, I know this statment does not mean you support the updates and I do not intend to imply that.) Stepan From markmc at redhat.com Wed Jul 1 10:30:35 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 01 Jul 2009 11:30:35 +0100 Subject: an update to automake-1.11? In-Reply-To: <1246431779.3872.18.camel@dhcp-lab-219.englab.brq.redhat.com> References: <1246385157.8362.127.camel@localhost.localdomain> <1246431779.3872.18.camel@dhcp-lab-219.englab.brq.redhat.com> Message-ID: <1246444235.598.23.camel@blaa> On Wed, 2009-07-01 at 09:02 +0200, Ond?ej Va??k wrote: > Owen Taylor wrote: > > I was rather surprised to see: > > > > https://admin.fedoraproject.org/updates/F9/FEDORA-2009-6661 > > https://admin.fedoraproject.org/updates/F10/FEDORA-2009-6076 > > https://admin.fedoraproject.org/updates/F11/FEDORA-2009-6370 > > > > Where the automake was upgraded to 1.11 for F9, F10, and F11. > > Upgrade on F-11 (and F-10) was requested because there are some projects > (like gnulib/coreutils) which really need automake 1.11 for build in > latest stable versions. Is there a bug report with details of this gnulib/coreutils request? Thanks, Mark. From rc040203 at freenet.de Wed Jul 1 10:40:44 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 01 Jul 2009 12:40:44 +0200 Subject: an update to automake-1.11? In-Reply-To: <20090701101514.GB19903@camelia.ucw.cz> References: <1246385157.8362.127.camel@localhost.localdomain> <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> Message-ID: <4A4B3D2C.60000@freenet.de> Stepan Kasal wrote: > Hello, > > On Wed, Jul 01, 2009 at 07:30:37AM +0200, Ralf Corsepius wrote: >> Kevin Kofler wrote: >>> Some software may need the new version to build. >> Very unlikely. > > There are people using the new features, like Jim Mayering, the > coreutils maintainer, and others. Building checkouts or even > tarballs of their projects on F9 might be a problem. No, not if they bundle the generated auto* files with their tarballs, as they are supposed to do. >> However, this upgrade may break rebuilding some of the packages whose >> packagers refuse to accept that running the autotools during builts is >> harmful. > > But this is not too likely either. Right, it is unlikely to happen with packages which already use automake-1.10 or versions next to it. > Only a minority of Fedora > packages does run autotools in their spec files. Well, with Fedora having attracted new packagers, who are not aware about the issues lurking, the number of such packages is increasing, once again! >> Anyway, the changes between automake-1.10 and automake-1.11 have >> been comparatively harmless. > > Thank you for saying that. (Yes, I know this statment does not mean > you support the updates and I do not intend to imply that.) Oh, actually I welcome Fedora shipping automake-1.11, because a) it will cause some moderate stir-up to those packages whose upstreams are still abusing the autotools. b) it will force packagers who are running the autotools during builds to review their packages, and to reconsider their habits. c) I (as a developer) am using automake-1.11 for my own works already. The new features having been introduced to automake-1.11, however are not welcomed by me. Neither do I find them useful nor do I find them helpful - They better should never have been added to automake! Ralf From ovasik at redhat.com Wed Jul 1 10:50:16 2009 From: ovasik at redhat.com (=?UTF-8?Q?Ond=C5=99ej_Va=C5=A1=C3=ADk?=) Date: Wed, 01 Jul 2009 12:50:16 +0200 Subject: an update to automake-1.11? In-Reply-To: <1246444235.598.23.camel@blaa> References: <1246385157.8362.127.camel@localhost.localdomain> <1246431779.3872.18.camel@dhcp-lab-219.englab.brq.redhat.com> <1246444235.598.23.camel@blaa> Message-ID: <1246445416.5846.31.camel@dhcp-lab-219.englab.brq.redhat.com> Mark McLoughlin wrote: > On Wed, 2009-07-01 at 09:02 +0200, Ond?ej Va??k wrote: > > Owen Taylor wrote: > > > I was rather surprised to see: > > > > > > https://admin.fedoraproject.org/updates/F9/FEDORA-2009-6661 > > > https://admin.fedoraproject.org/updates/F10/FEDORA-2009-6076 > > > https://admin.fedoraproject.org/updates/F11/FEDORA-2009-6370 > > > > > > Where the automake was upgraded to 1.11 for F9, F10, and F11. > > > > Upgrade on F-11 (and F-10) was requested because there are some projects > > (like gnulib/coreutils) which really need automake 1.11 for build in > > latest stable versions. > > Is there a bug report with details of this gnulib/coreutils request? Not really, it was just direct irl/irc/mail communication with automake/autoconf fedora maintainers&comaintainers. First request was only about 1.10b in rawhide (after f-12 split) - as I needed at least 1.10b to build coreutils-7.4 there (otherwise only with an ugly hack). Greetings, Ond?ej Va??k -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Toto je digit?ln? podepsan? ??st zpr?vy URL: From rc040203 at freenet.de Wed Jul 1 11:06:04 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 01 Jul 2009 13:06:04 +0200 Subject: an update to automake-1.11? In-Reply-To: <1246445416.5846.31.camel@dhcp-lab-219.englab.brq.redhat.com> References: <1246385157.8362.127.camel@localhost.localdomain> <1246431779.3872.18.camel@dhcp-lab-219.englab.brq.redhat.com> <1246444235.598.23.camel@blaa> <1246445416.5846.31.camel@dhcp-lab-219.englab.brq.redhat.com> Message-ID: <4A4B431C.3050102@freenet.de> Ond?ej Va??k wrote: > Mark McLoughlin wrote: >> On Wed, 2009-07-01 at 09:02 +0200, Ond?ej Va??k wrote: >>> Owen Taylor wrote: >>>> I was rather surprised to see: >>>> >>>> https://admin.fedoraproject.org/updates/F9/FEDORA-2009-6661 >>>> https://admin.fedoraproject.org/updates/F10/FEDORA-2009-6076 >>>> https://admin.fedoraproject.org/updates/F11/FEDORA-2009-6370 >>>> >>>> Where the automake was upgraded to 1.11 for F9, F10, and F11. >>> Upgrade on F-11 (and F-10) was requested because there are some projects >>> (like gnulib/coreutils) which really need automake 1.11 for build in >>> latest stable versions. >> Is there a bug report with details of this gnulib/coreutils request? > > Not really, it was just direct irl/irc/mail communication with > automake/autoconf fedora maintainers&comaintainers. First request was > only about 1.10b in rawhide (after f-12 split) - as I needed at least > 1.10b to build coreutils-7.4 there (otherwise only with an ugly hack). And? This should not be a problem to you. Simply install the original GNU versions of these autotools in parallel (using a different --prefix) to the vendor supplied versions and use them for your packages (here core-utils). Ralf From mrsam at courier-mta.com Wed Jul 1 11:08:19 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Wed, 01 Jul 2009 07:08:19 -0400 Subject: an update to automake-1.11? References: <1246385157.8362.127.camel@localhost.localdomain> <20090630213457.GC22149@redhat.com> <20090701100652.GD19366@camelia.ucw.cz> Message-ID: Stepan Kasal writes: > Hello, > > On Tue, Jun 30, 2009 at 06:58:39PM -0400, Sam Varshavchik wrote: >> Kevin Kofler writes: >>> Some software may need the new version to build. >> >> Then, they need to be patched so that they would get built for F9, or >> they should not be built for F9 altogether. > > I'm afraid the answer shows you do not fully understand the context. > Sorry, I understand the concept very well, and have done precisely that numerous times before. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From markmc at redhat.com Wed Jul 1 11:09:08 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 01 Jul 2009 12:09:08 +0100 Subject: an update to automake-1.11? In-Reply-To: <1246445416.5846.31.camel@dhcp-lab-219.englab.brq.redhat.com> References: <1246385157.8362.127.camel@localhost.localdomain> <1246431779.3872.18.camel@dhcp-lab-219.englab.brq.redhat.com> <1246444235.598.23.camel@blaa> <1246445416.5846.31.camel@dhcp-lab-219.englab.brq.redhat.com> Message-ID: <1246446548.598.43.camel@blaa> On Wed, 2009-07-01 at 12:50 +0200, Ond?ej Va??k wrote: > Mark McLoughlin wrote: > > On Wed, 2009-07-01 at 09:02 +0200, Ond?ej Va??k wrote: > > > Owen Taylor wrote: > > > > I was rather surprised to see: > > > > > > > > https://admin.fedoraproject.org/updates/F9/FEDORA-2009-6661 > > > > https://admin.fedoraproject.org/updates/F10/FEDORA-2009-6076 > > > > https://admin.fedoraproject.org/updates/F11/FEDORA-2009-6370 > > > > > > > > Where the automake was upgraded to 1.11 for F9, F10, and F11. > > > > > > Upgrade on F-11 (and F-10) was requested because there are some projects > > > (like gnulib/coreutils) which really need automake 1.11 for build in > > > latest stable versions. > > > > Is there a bug report with details of this gnulib/coreutils request? > > Not really, it was just direct irl/irc/mail communication with > automake/autoconf fedora maintainers&comaintainers. First request was > only about 1.10b in rawhide (after f-12 split) - as I needed at least > 1.10b to build coreutils-7.4 there (otherwise only with an ugly hack). Okay, but what exactly are we talking about here? What does gnulib or coreutils need that 1.10 doesn't have? A rebase of an important package in three stable releases, which is expected to break rebuilds of some packages, should surely have more justification than an empty update description, no associated bugzilla and claims that Jim Meyering needs some unspecified new features. Cheers, Mark. From rc040203 at freenet.de Wed Jul 1 11:21:50 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 01 Jul 2009 13:21:50 +0200 Subject: an update to automake-1.11? In-Reply-To: <1246446548.598.43.camel@blaa> References: <1246385157.8362.127.camel@localhost.localdomain> <1246431779.3872.18.camel@dhcp-lab-219.englab.brq.redhat.com> <1246444235.598.23.camel@blaa> <1246445416.5846.31.camel@dhcp-lab-219.englab.brq.redhat.com> <1246446548.598.43.camel@blaa> Message-ID: <4A4B46CE.5090705@freenet.de> Mark McLoughlin wrote: > On Wed, 2009-07-01 at 12:50 +0200, Ond?ej Va??k wrote: >> Mark McLoughlin wrote: >>> On Wed, 2009-07-01 at 09:02 +0200, Ond?ej Va??k wrote: >>>> Owen Taylor wrote: >>>>> I was rather surprised to see: >>>>> >>>>> https://admin.fedoraproject.org/updates/F9/FEDORA-2009-6661 >>>>> https://admin.fedoraproject.org/updates/F10/FEDORA-2009-6076 >>>>> https://admin.fedoraproject.org/updates/F11/FEDORA-2009-6370 >>>>> >>>>> Where the automake was upgraded to 1.11 for F9, F10, and F11. >>>> Upgrade on F-11 (and F-10) was requested because there are some projects >>>> (like gnulib/coreutils) which really need automake 1.11 for build in >>>> latest stable versions. >>> Is there a bug report with details of this gnulib/coreutils request? >> Not really, it was just direct irl/irc/mail communication with >> automake/autoconf fedora maintainers&comaintainers. First request was >> only about 1.10b in rawhide (after f-12 split) - as I needed at least >> 1.10b to build coreutils-7.4 there (otherwise only with an ugly hack). > > Okay, but what exactly are we talking about here? What does gnulib or > coreutils need that 1.10 doesn't have? coreutils' automake configuration uses features which are not available before automake-1.11 (rsp. post automake-1.10 devel snapshots) > A rebase of an important package in three stable releases, which is > expected to break rebuilds of some packages, No, it doesn't. It's simply that developing coreutils now requires a specific version of the autotools. This is not much different from demands of many other projects, which also require specific versions. The only difference is coreutils requiring a very recent automake, due to it exploiting a new feature and not a specific, older version due to suffering from compatibility issues, like most other such cases do. > should surely have more > justification than an empty update description, no associated bugzilla > and claims that Jim Meyering needs some unspecified new features. Well, these new features have been introduced to automake, primarily due to Jim Meyering's initiative/pressure. I guess hardly anybody but him is currently using these features. Ralf From ovasik at redhat.com Wed Jul 1 12:36:52 2009 From: ovasik at redhat.com (=?UTF-8?Q?Ond=C5=99ej_Va=C5=A1=C3=ADk?=) Date: Wed, 01 Jul 2009 14:36:52 +0200 Subject: an update to automake-1.11? In-Reply-To: <4A4B431C.3050102@freenet.de> References: <1246385157.8362.127.camel@localhost.localdomain> <1246431779.3872.18.camel@dhcp-lab-219.englab.brq.redhat.com> <1246444235.598.23.camel@blaa> <1246445416.5846.31.camel@dhcp-lab-219.englab.brq.redhat.com> <4A4B431C.3050102@freenet.de> Message-ID: <1246451812.5846.42.camel@dhcp-lab-219.englab.brq.redhat.com> Ralf Corsepius wrote: > Ond?ej Va??k wrote: > > Mark McLoughlin wrote: > >> On Wed, 2009-07-01 at 09:02 +0200, Ond?ej Va??k wrote: > >>> Owen Taylor wrote: > >>>> I was rather surprised to see: > >>>> > >>>> https://admin.fedoraproject.org/updates/F9/FEDORA-2009-6661 > >>>> https://admin.fedoraproject.org/updates/F10/FEDORA-2009-6076 > >>>> https://admin.fedoraproject.org/updates/F11/FEDORA-2009-6370 > >>>> > >>>> Where the automake was upgraded to 1.11 for F9, F10, and F11. > >>> Upgrade on F-11 (and F-10) was requested because there are some projects > >>> (like gnulib/coreutils) which really need automake 1.11 for build in > >>> latest stable versions. > >> Is there a bug report with details of this gnulib/coreutils request? > > > > Not really, it was just direct irl/irc/mail communication with > > automake/autoconf fedora maintainers&comaintainers. First request was > > only about 1.10b in rawhide (after f-12 split) - as I needed at least > > 1.10b to build coreutils-7.4 there (otherwise only with an ugly hack). > > And? This should not be a problem to you. This is not problem for me on my machine - I had 1.10a/1.10b/1.11 already on my machine for quite a long time those days - but to build them in koji it required hacky solution (e.g. temporarily reverting/disabling things which do need automake 1.10a+ or some even more ugly things). I was talking about first request - just to add 1.10b to rawhide, initiative for updating F-10/F-11 to F-11 came later from Jim Meyering side. Anyway - I like F-11 update of autotools, F-10 update is still ok for me, but imho F-9 update should not make it to stable. Greetings, Ond?ej -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Toto je digit?ln? podepsan? ??st zpr?vy URL: From mclasen at redhat.com Wed Jul 1 13:59:07 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 01 Jul 2009 09:59:07 -0400 Subject: libxklavier api change Message-ID: <1246456747.1685.2.camel@localhost.localdomain> I built libxklavier 4.0 in rawhide yesterday. It changed api; the required change looks like this: - xkl_config_registry_load (config_registry); + xkl_config_registry_load (config_registry, FALSE); Sorry for the late notice... Here is a list of likely affected packages: xfce4-settings-0:4.6.1-1.fc12.x86_64 libgnomekbd-0:2.27.2-1.fc12.x86_64 gnome-settings-daemon-0:2.27.3-1.fc12.x86_64 cairo-dock-plug-ins-0:2.0.6-1.fc12.x86_64 xfce4-xkb-plugin-0:0.5.2-3.fc11.x86_64 control-center-1:2.26.0-9.fc12.x86_64 libgnomekbd-capplet-0:2.27.2-1.fc12.x86_64 kdebase-workspace-0:4.2.95-3.fc12.x86_64 gdm-1:2.26.1-10.fc12.x86_64 gnome-applets-1:2.27.3-2.fc12.x86_64 libxklavier-devel-0:3.9-1.fc11.x86_64 gnome-screensaver-0:2.27.0-1.fc12.x86_64 Matthias From rawhide at fedoraproject.org Wed Jul 1 14:01:22 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Wed, 1 Jul 2009 14:01:22 +0000 Subject: rawhide report: 20090701 changes Message-ID: <20090701140122.GA19699@releng2.fedora.phx.redhat.com> Compose started at Wed Jul 1 06:15:04 UTC 2009 New package awesfx Utility programs for the AWE32/Emu10k1 sound driver. New package kdepim-runtime KDE PIM Runtime Environment New package miredo Tunneling of IPv6 over UDP through NATs New package perl-POE-Component-Server-Bayeux Bayeux/cometd server implementation in POE New package sK1 Advanced vector graphics editor New package xscope X Window Protocol Viewer Removed package repoman Updated Packages: GraphicsMagick-1.1.15-1.fc12 ---------------------------- * Tue Jun 30 2009 Rex Dieter - 1.1.15-1 - GraphicsMagick-1.1.15 - fix BuildRoot - multiarch conflicts in GraphicsMagick (#341381) - broken -L in GraphicsMagick.pc (#456466) - %files: track sonames apr-1.3.5-5.fc12 ---------------- * Tue Jun 30 2009 Joe Orton 1.3.5-5 - BR libuuid-devel instead of e2fsprogs-devel audacious-plugins-1.5.1-9.fc12 ------------------------------ binutils-2.19.51.0.11-23.fc12 ----------------------------- * Tue Jun 30 2009 Nick Clifton 2.19.51.0.11-23 - Rebase sources on the 2.19.51.0.11 tarball. diffuse-0.3.3-1.fc12 -------------------- * Tue Jun 30 2009 Jon Levell - 0.3.3-1 - Update to latest upstream release - Add patch provided by upstream directfb-1.2.8-4.fc12 --------------------- * Tue Jun 30 2009 kwizart < kwizart at gmail.com > - 1.2.8-4 - Built with tslib e2fsprogs-1.41.7-1.fc12 ----------------------- * Tue Jun 30 2009 Eric Sandeen 1.41.7-1 - New upstream version espeak-1.40.02-2.fc12 --------------------- * Tue Jun 30 2009 Francois Aucamp - 1.40.02-2 - Compile against pulseaudio instead of portaudio (RHBZ #481651) firefox-3.5-1.fc12 ------------------ * Tue Jun 30 2009 Christopher Aillon - 3.5-1 - Firefox 3.5 final release gedit-2.27.2-1.fc12 ------------------- * Tue Jun 30 2009 Matthias Clasen - 1:2.27.2-1 - Update to 2.27.2 * Fri Jun 26 2009 Matthias Clasen - 1:2.27.1-2 - Improve print-to-file glade3-3.6.7-1.fc12 ------------------- * Tue Jun 30 2009 Matthias Clasen - 3.6.7-1 - Update to 3.6.7 - Drop the menu patch, since glade-3 is the version we install by default now, and it didn't work right anyway gnome-doc-utils-0.17.2-1.fc12 ----------------------------- * Mon Jun 29 2009 Matthew Barnes - 0.17.2-1 - Update to 0.17.2 - Require libxml2-python for building. gnome-lirc-properties-0.3.1-4.fc12 ---------------------------------- * Tue Jun 30 2009 Bastien Nocera 0.3.1-4 - Add D-Bus patch to allow the front-end to run - Fix overly enthusiastic quoting gnome-menus-2.26.2-1.fc12 ------------------------- * Tue Jun 30 2009 Matthias Clasen 2.26.2-1 - Update to 2.26.2 - See http://download.gnome.org/sources/gnome-menus/2.26/gnome-menus-2.26.2.news gnome-web-photo-0.8-1.fc12 -------------------------- * Tue Jun 30 2009 Matthias Clasen - 0.8-1 - Update to 0.8 grub-0.97-53.fc12 ----------------- * Tue Jun 30 2009 Peter Jones - 0.97-53 - Don't assume that gcc provides us with writable strings in the xfs driver gstreamer-java-1.2-1.fc12 ------------------------- * Tue Jun 30 2009 Levente Farkas - 1.2-1 - update to the new upstream version - don't use build-classpath for SWT on any platform since it's broken in most cases - add suport for platfrom which has no SWT support hdhomerun-0.0-0.11.20090415.fc12 -------------------------------- * Tue Jun 30 2009 Jarod Wilson 0.0-0.11.20090415 - Add README.firmware, pointing folks to firmware downloads kde-l10n-4.2.95-1.fc12 ---------------------- * Tue Jun 30 2009 Than Ngo - 4.2.95-1 - 4.3rc1 kdeaccessibility-4.2.95-1.fc12 ------------------------------ * Thu Jun 25 2009 Than Ngo - 4.2.95-1 - 4.3 rc1 kdeadmin-4.2.95-1.fc12 ---------------------- * Thu Jun 25 2009 Than Ngo - 4.2.95-1 - 4.3rc1 kdeartwork-4.2.95-1.fc12 ------------------------ * Thu Jun 25 2009 Than Ngo - 4.2.95-1 - 4.3rc1 kdebase-4.2.95-1.fc12 --------------------- * Thu Jun 25 2009 Than Ngo - 4.2.95-1 - 4.3rc1 kdebindings-4.2.95-1.fc12 ------------------------- * Fri Jun 26 2009 Than Ngo - 4.2.95-1 - 4.3rc1 kdeedu-4.2.95-1.fc12 -------------------- * Fri Jun 26 2009 Than Ngo - 4.2.95-1 - 4.3rc1 kdegames-4.2.95-1.fc12 ---------------------- * Fri Jun 26 2009 Than Ngo - 4.2.95-1 - 4.3rc1 kdegraphics-4.2.95-1.fc12 ------------------------- * Fri Jun 26 2009 Than Ngo - 4.2.95-1 - 4.3rc1 * Mon Jun 22 2009 Rex Dieter - 4.2.90-2 - rebuild (poppler reduced libs) kdemultimedia-4.2.95-1.fc12 --------------------------- * Fri Jun 26 2009 Than Ngo - 4.2.95-1 - 4.3rc1 kdenetwork-4.2.95-1.fc12 ------------------------ * Fri Jun 26 2009 Than Ngo - 4.2.95-1 - 4.3rc1 kdepim-4.2.95-1.fc12 -------------------- * Mon Jun 29 2009 Than Ngo - 4.2.95-1 - 4.3rc1 kdeplasma-addons-4.2.95-1.fc12 ------------------------------ * Fri Jun 26 2009 Than Ngo - 4.2.95-1 - 4.3rc1 kdesdk-4.2.95-1.fc12 -------------------- * Fri Jun 26 2009 Than Ngo - 4.2.95-1 - 4.3rc1 kdetoys-4.2.95-1.fc12 --------------------- * Fri Jun 26 2009 Than Ngo - 4.2.95-1 - 4.3rc1 kdeutils-4.2.95-1.fc12 ---------------------- * Fri Jun 26 2009 Than Ngo - 4.2.95-1 - 4.3rc1 kernel-2.6.31-0.38.rc1.git7.fc12 -------------------------------- * Tue Jun 30 2009 Ben Skeggs - drm-nouveau.patch: match upstream * Tue Jun 30 2009 Dave Jones 2.6.31-0.37.rc1.git5 - Disable kmemleak. Way too noisy, and not finding any real bugs. * Tue Jun 30 2009 Chuck Ebbert 2.6.31-0.38.rc1.git7 - 2.6.31-rc1-git7 kgtk-0.10.1-1.fc12 ------------------ * Tue Jun 30 2009 Francois Aucamp - 0.10.1-1 - Update to version 0.10.1 - Added "kgtk2_wrapper_lib_suffix" patch to fix libdir locations on x86_64 (RHBZ #508733) - Added explicit Requires: kdebase-runtime (for kreadconfig) - Removed old bundled %cmake macros from spec - Dropped obsolete "open_O_CREAT_parameters" patch (included upstream) - Dropped obsolete "intptr_t" patch (fixed upstream) - Dropped obsolete "kgtk-wrapper-gtk2_detection" patch (included upstream) liberation-fonts-1.05.1.20090630-1.fc12 --------------------------------------- libgnomekbd-2.27.2-3.fc12 ------------------------- * Tue Jun 30 2009 Matthias Clasen - 2.27.2-3 - Rebuild against new libxklavier - Adapt to api changes libhugetlbfs-2.5-1.fc12 ----------------------- * Tue Jun 30 2009 Eric Munson 2.5-1 - Updating for the libhugetlbfs-2.5 release libxklavier-4.0-1.fc12 ---------------------- * Tue Jun 30 2009 Matthias Clasen - 4.0-1 - Update to 4.0 liferea-1.6.0-0.1.rc6.fc12 -------------------------- * Tue Jun 30 2009 Steven M. Parrish 1.6.0-0.1.rc6 - Updated the example feeds. - Updated the social bookmarking sites. - Added Twitter Search support. - Added Identi.ca Search support. - Support non-RFC822 alphabetic timezones. - Fix favicon downloads when the feed contains a link with leading or trailing whitespace. - Fixes comment feed hiding when comment feed is disabled. - Don't use the deprecated soup_message_headers_get() function. - More consistent tab label widths. - Avoid having loading of other tabs cancelled when opening a new tab. * Wed Jun 24 2009 Rex Dieter 1.6.0-0.3.fc5 - Obsoletes: liferea-WebKit < 1.6.0 lvm2-2.02.48-1.fc12 ------------------- * Tue Jun 30 2009 Alasdair Kergon - 2.02.48-1 - Abort if automatic metadata correction fails when reading VG to update it. - Don't fallback to default major number in libdm: use dm_task_set_major_minor. - Explicitly request fallback to default major number in device mapper. - Ignore suspended devices during repair. - Suggest using lvchange --resync when adding leg to not-yet-synced mirror. - Destroy toolcontext on clvmd exit to avoid memory pool leaks. - Fix lvconvert not to poll mirror if no conversion in progress. - Fix memory leaks in toolcontext error path. - Reinstate partial activation support in clustered mode. - Allow metadata correction even when PVs are missing. - Use 'lvm lvresize' instead of 'lvresize' in fsadm. - Do not use '-n' realine option in fsadm for rescue disk compatiblity. - Round up requested readahead to at least one page and print warning. - Try to repair vg before actual vgremove when force flag provided. - Unify error messages when processing inconsistent volume group. - Introduce lvconvert --use_policies (repair policy according to lvm.conf). - Fix rename of active snapshot with virtual origin. - Fix convert polling to ignore LV with different UUID. - Cache underlying device readahead only before activation calls. - Fix segfault when calculating readahead on missing device in vgreduce. - Remove verbose 'visited' messages. - Handle multi-extent mirror log allocation when smallest PV has only 1 extent. - Add LSB standard headers and functions (incl. reload) to clvmd initscript. - When creating new LV, double-check that name is not already in use. - Remove /dev/vgname/lvname symlink automatically if LV is no longer visible. - Rename internal vorigin LV to match visible LV. - Suppress 'removed' messages displayed when internal LVs are removed. - Fix lvchange -a and -p for sparse LVs. - Fix lvcreate --virtualsize to activate the new device immediately. - Make --snapshot optional with lvcreate --virtualsize. - Generalise --virtualoriginsize to --virtualsize. - Skip virtual origins in process_each_lv_in_vg() without --all. - Fix counting of virtual origin LVs in vg_validate. - Attempt to load dm-zero module if zero target needed but not present. - Add crypt target handling to libdevmapper tree nodes. - Add splitname command to dmsetup. - Add subsystem, vg_name, lv_name, lv_layer fields to dmsetup reports. - Make mempool optional in dm_split_lvm_name() in libdevmapper. mkinitrd-6.0.90-1.fc12 ---------------------- * Tue Jun 30 2009 Hans de Goede - 6.0.90-1 - drop e2fsprogs requires (#508407) - process all PVs in a required VG (#506189) nspr-4.8-1.fc12 --------------- * Tue Jun 30 2009 Christopher Aillon 4.8-1 - update to 4.8 openscada-0.6.3.3-8.fc12 ------------------------ * Tue Jun 30 2009 Popkov Aleksey 0.6.3.3-8 - Added of dependences in to self package demo - Fixed %preun section by Peter Lemenkov - Somes cosmetics. openssh-5.2p1-12.fc12 --------------------- * Tue Jun 30 2009 Jan F. Chadima - 5.2p1-11 - create '~/.ssh/known_hosts' within proper context oxygen-icon-theme-4.2.95-1.fc12 ------------------------------- * Fri Jun 26 2009 Than Ngo - 4.2.95-1 - 4.3rc1 pango-1.24.4-1.fc12 ------------------- * Tue Jun 30 2009 Matthias Clasen - 1.24.4-1 - Update to 1.24.4 php-ezc-Authentication-1.3-1.fc12 --------------------------------- * Mon Jun 29 2009 Guillaume Kulakowski - 1.3-1 - Update to 1.3 php-ezc-Mail-1.6.3-1.fc12 ------------------------- * Tue Jun 30 2009 Guillaume Kulakowski - 1.6.3-1 - Update to 1.6.3 php-ezc-PersistentObject-1.6-1.fc12 ----------------------------------- * Tue Jun 30 2009 Guillaume Kulakowski - 1.6-1 - Update to 1.6 phpMyAdmin-3.2.0.1-1.fc12 ------------------------- * Tue Jun 30 2009 Robert Scheck 3.2.0-1 - Upstream released 3.2.0 * Tue Jun 30 2009 Robert Scheck 3.2.0.1-1 - Upstream released 3.2.0.1 (#508879) procmail-3.22-24.fc12 --------------------- * Tue Jun 30 2009 Miroslav Lichvar 3.22-24 - rename getline to avoid conflict with glibc (#505977) - add -Wno-comments to CFLAGS - remove package name from summary python-gdata-2.0.0-1.fc12 ------------------------- * Tue Jun 30 2009 Bastien Nocera 2.0.0-1 - Update to 2.0.0 python-kaa-base-0.6.0-1.fc12 ---------------------------- * Tue Jun 30 2009 kwizart < kwizart at gmail.com > - 0.6.0-1 - Update to 0.6.0 python-nss-0.4-1.fc12 --------------------- * Tue Jun 30 2009 John Dennis - 0.4-1 - add binding for NSS_NoDB_Init(), bug #509002 move nss_init and nss_shutdown from ssl module to nss module rhythmbox-0.12.2.92-1.fc12 -------------------------- * Tue Jun 30 2009 Bastien Nocera 0.12.2.92-1 - Update to 0.12.2.92 ricci-0.16.1-1.fc12 ------------------- * Thu Apr 16 2009 Ryan McCabe 0.16.1-1 - More updates for cluster3. * Tue Apr 07 2009 Ryan McCabe 0.16.0-2 - Fix memory corruption bug. - Update package and service list. - Add missing dependency for nss-tools ruby-gnome2-0.19.0-2.fc12 ------------------------- * Wed Jul 01 2009 Mamoru Tasaka - 0.19.0-2 - Install more needed header files in ruby-gtk2-devel (bug 509035) - Keep timestamps on installed header files * Tue Jun 30 2009 Christopher Aillon - Rebuild against newer gecko rubygem-main-2.8.4-2.fc12 ------------------------- * Wed Jul 01 2009 Jeroen van Meeuwen - 2.8.4-2 - Add requirement for rubygem(fattr) (Brenton Leanhardt) seekwatcher-0.12-3.fc12 ----------------------- * Tue Jun 30 2009 Eric Sandeen - 0.12-3 - Updates for new matplotlib selinux-policy-3.6.20-2.fc12 ---------------------------- * Tue Jun 30 2009 Dan Walsh 3.6.20-2 - Add rules for rtkit-daemon system-config-cluster-1.0.53-6 ------------------------------ * Tue Jun 30 2009 Jeremy Katz - 1.0.53-6 - Doesn't really depend on rhpl, remove the dependency system-config-lvm-1.1.4-6.fc12 ------------------------------ * Tue Jun 30 2009 Jeremy Katz - 1.1.4-6 - Remove superfluous dependency on rhpl (#508951) xfce4-dict-0.5.3-2.fc12 ----------------------- * Tue Jun 30 2009 Caol?n McNamara - 0.5.3-2 - Resolves: rhbz#508633 Require enchant rather than aspell, xfce4-dict already prefers it at run-time xfsdump-3.0.1-2.fc12 -------------------- * Tue Jun 30 2009 Eric Sandeen 3.0.1-2 - Fix up build-requires after e2fsprogs splitup xfsprogs-3.0.1-8.fc12 --------------------- * Tue Jun 30 2009 Eric Sandeen 3.0.1-8 - Fix up build-requires after e2fsprogs splitup xulrunner-1.9.1-2.fc12 ---------------------- * Tue Jun 30 2009 Christopher Aillon 1.9.1-1 - Update to 1.9.1 final release * Tue Jun 30 2009 Yanko Kaneti - 1.9.1-2 - Build using system hunspell ytalk-3.3.0-15.fc12 ------------------- * Tue Jun 30 2009 Mike McGrath 3.3.9-15 - Release bump for test build Summary: Added Packages: 6 Removed Packages: 1 Modified Packages: 69 From kevin.kofler at chello.at Wed Jul 1 15:03:36 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 01 Jul 2009 17:03:36 +0200 Subject: FESCo meeting summary for 2009-06-26 References: <20090627000642.GA19010@srcf.ucam.org> <20090627013827.GC19838@srcf.ucam.org> <20090629155126.GB32653@nostromo.devel.redhat.com> <20090630023721.GC1165657@hiwaay.net> <20090630160057.GA22566@nostromo.devel.redhat.com> <20090701025648.GA1085@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > 1) You argue that the name 'Desktop' makes people think that it contains > *all possible desktops*. I'm arguing that people will either think that or (more likely) that GNOME is the only possible desktop (a misconception which the "featuring the GNOME desktop" small print wouldn't fix either). Now technically they'd in both cases think that it contains "all possible desktops" (if they think there's just one, it would be "all possible"), but the distinction is important because: > Given that to assume that you'd already have to know of other desktops, > then you would already know what the 'KDE fans...' text means, > or know what the long list of things on the torrent pages are. ... this is not true in the second case. > 2) I feel that changing the name on get-fedora doesn't give any benefits; > it adds verbiage that's *already there* in the description. Having in the title would be clearer (see also the above) and make sure the information appears everywhere, not just on that page. > 3) On get-fedora-all... you're coming from a page (#2) that already > describes it as being GNOME. Except if you go (e.g. from some link on some other site) directly to get-fedora-all because the fancy page hides 5 of the 7 primary options (it would be 7 of 9 if we started shipping PPC Live CDs, which is now technically possible as of F11). > 3) If you're talking about torrent.fp.o, the descriptions on that are so > bad that there are a whole host of things that need fixed before one > filename. Still, having "GNOME" in the name would at least make it automatically show up there and everywhere else. Kevin Kofler From kevin.kofler at chello.at Wed Jul 1 15:03:36 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 01 Jul 2009 17:03:36 +0200 Subject: FESCo meeting summary for 2009-06-26 References: <20090627000642.GA19010@srcf.ucam.org> <20090627013827.GC19838@srcf.ucam.org> <20090629155126.GB32653@nostromo.devel.redhat.com> <20090630023721.GC1165657@hiwaay.net> <20090630160057.GA22566@nostromo.devel.redhat.com> <20090701025648.GA1085@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > 1) You argue that the name 'Desktop' makes people think that it contains > *all possible desktops*. I'm arguing that people will either think that or (more likely) that GNOME is the only possible desktop (a misconception which the "featuring the GNOME desktop" small print wouldn't fix either). Now technically they'd in both cases think that it contains "all possible desktops" (if they think there's just one, it would be "all possible"), but the distinction is important because: > Given that to assume that you'd already have to know of other desktops, > then you would already know what the 'KDE fans...' text means, > or know what the long list of things on the torrent pages are. ... this is not true in the second case. > 2) I feel that changing the name on get-fedora doesn't give any benefits; > it adds verbiage that's *already there* in the description. Having in the title would be clearer (see also the above) and make sure the information appears everywhere, not just on that page. > 3) On get-fedora-all... you're coming from a page (#2) that already > describes it as being GNOME. Except if you go (e.g. from some link on some other site) directly to get-fedora-all because the fancy page hides 5 of the 7 primary options (it would be 7 of 9 if we started shipping PPC Live CDs, which is now technically possible as of F11). > 3) If you're talking about torrent.fp.o, the descriptions on that are so > bad that there are a whole host of things that need fixed before one > filename. Still, having "GNOME" in the name would at least make it automatically show up there and everywhere else. Kevin Kofler From kevin.kofler at chello.at Wed Jul 1 15:15:45 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 01 Jul 2009 17:15:45 +0200 Subject: KSplice in Fedora? References: <8278b1b0906291521i45f71873n2da7cda47161bb2d@mail.gmail.com> <4A49640B.9070202@cchtml.com> <1246418943.5270.226.camel@perihelion.bos.jonmasters.org> Message-ID: Jon Masters wrote: > That's a load of . I'm not sure where you get this idea from - > perhaps because it's not obvious how they might achieve structural > updates and so you assume it cannot be done - but actually, they can > handle most kinds of update. They achieve this with shadow data > structure tracking and manage the ABI differences - see the paper - and > implement pre/post code hooks for things that cannot be done without a > human kernel engineer. So you can also apply initcall-time fixes by > implementing a custom pre-hook to perform what would happen at boot. The paper or web page (I don't remember exactly) I've read talked about this limitation. But maybe that information is outdated or this is just for automatically generating the fixes and you can do more complex stuff by manually writing fixup code. Kevin Kofler From mike at cchtml.com Wed Jul 1 15:18:08 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Wed, 01 Jul 2009 10:18:08 -0500 Subject: an update to automake-1.11? In-Reply-To: <20090701100507.GA19903@camelia.ucw.cz> References: <1246385157.8362.127.camel@localhost.localdomain> <20090701100507.GA19903@camelia.ucw.cz> Message-ID: <4A4B7E30.8020200@cchtml.com> Stepan Kasal on 07/01/2009 05:05 AM wrote: > > I apologize for that. I got bored writing three-word nonsenses so I > tried the null string. I will do better now when I know that it > might be read by someone in certain cases. > Fedora 11 brings a PackageKit that actually promotes and accentuates the notes for each package. Not having any actually looks bad this time around. It was "normal" to not have them in F9 or F10 but not anymore. From kevin.kofler at chello.at Wed Jul 1 15:16:30 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 01 Jul 2009 17:16:30 +0200 Subject: KSplice in Fedora? References: <8278b1b0906291521i45f71873n2da7cda47161bb2d@mail.gmail.com> <1246354287.20189.56.camel@breeves.fab.redhat.com> <1246377541.20189.86.camel@breeves.fab.redhat.com> <4A4A45B2.90808@bfccomputing.com> Message-ID: Frank Schmitt wrote: > I think most people hibernate or suspend when they go to sleep. Those people must be trusting their hardware and software (drivers in particular) a lot more than I do. ;-) Kevin Kofler From rdieter at math.unl.edu Wed Jul 1 15:20:27 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 01 Jul 2009 10:20:27 -0500 Subject: GraphicsMagick-1.3.x coming to rawhide Message-ID: <4A4B7EBB.1020904@math.unl.edu> Manually, sending to -devel list, while one to -announce sits for moderation... ------------------------- Up'ing to GraphicsMagick-1.3.x in rawhide, which involves an ABI break. I'll take care of (re)building dependent apps, dvdauthor and koffice. Issue tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=487605 If you're aware of any other deps I missed, please comment or block the aforementioned bug. Thanks. -- Rex From kevin.kofler at chello.at Wed Jul 1 15:21:46 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 01 Jul 2009 17:21:46 +0200 Subject: an update to automake-1.11? References: <1246385157.8362.127.camel@localhost.localdomain> <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> Message-ID: Ralf Corsepius wrote: > a) it will cause some moderate stir-up to those packages whose upstreams > are still abusing the autotools. s/ab// ;-) Why can't we just move to a better build system with higher focus on backwards compatibility? (And FYI, I'm "against autotools" more than I'm "for CMake". It's just that in the past I could just say "don't use autotools", now I have an actual alternative to suggest.) Kevin Kofler From nalin at redhat.com Wed Jul 1 15:06:00 2009 From: nalin at redhat.com (Nalin Dahyabhai) Date: Wed, 1 Jul 2009 11:06:00 -0400 Subject: an update to automake-1.11? In-Reply-To: <20090701095220.GC19366@camelia.ucw.cz> References: <1246385157.8362.127.camel@localhost.localdomain> <20090701095220.GC19366@camelia.ucw.cz> Message-ID: <20090701150600.GA383@redhat.com> On Wed, Jul 01, 2009 at 11:52:20AM +0200, Stepan Kasal wrote: > IOW, what's Fedora good for after its EOL? If it is a museum > artifact, then I'm spoiling the game. If it is to be used in real > life, then update to Automake 1.11 is beneficial for the developers > using it and harmless for the non-developer uses (office, proxy, > etc.) After a release goes EOL, we don't push updates for it. That means we don't push security updates for it. To me, that means people shouldn't use it. That's my short answer anyway. Here's the long one: The above having been said, you obviously *can*, but outside of making sure things build on it -- a development use case which upgrading the developer tools and libraries actually makes less useful for me -- I strongly recommend against doing so. Of course, I can't deny that there are people who continue to run EOL releases in production. But in doing so they take on the responsibility of ensuring that things which might need updates (in particular, security updates) either get them, or are only deployed in such a way that they're not affected by whatever issues would normally require updates. That cumulative list of issues typically grows for a given release as time passes (and as each successive release reaches EOL with an ever-larger set of packages it may grow at a faster rate), so the amount of work also grows as time passes. I worry that some of the people who run EOL releases don't even know that they've taken on this burden, that a release going EOL means that we're not doing this work any more, and that means that *they* have to do the work. And I worry that that's partly due to us not always being emphatic about warning them of it. Sometimes it feels like failure. Cheers, Nalin From kevin.kofler at chello.at Wed Jul 1 15:35:52 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 01 Jul 2009 17:35:52 +0200 Subject: an update to automake-1.11? References: <1246385157.8362.127.camel@localhost.localdomain> <20090701095220.GC19366@camelia.ucw.cz> <20090701150600.GA383@redhat.com> Message-ID: Nalin Dahyabhai wrote: > I worry that some of the people who run EOL releases don't even know > that they've taken on this burden, that a release going EOL means that > we're not doing this work any more, and that means that *they* have to > do the work. And I worry that that's partly due to us not always being > emphatic about warning them of it. Sometimes it feels like failure. Maybe the last update to any EOL distro should be a firstboot-like tool which just gives 3 options: * Run preupgrade * Wipe all hard disks * Turn off computer Kevin Kofler From Jochen at herr-schmitt.de Wed Jul 1 15:36:42 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 01 Jul 2009 17:36:42 +0200 Subject: KSplice in Fedora? In-Reply-To: References: <8278b1b0906291521i45f71873n2da7cda47161bb2d@mail.gmail.com> <1246354287.20189.56.camel@breeves.fab.redhat.com> <1246377541.20189.86.camel@breeves.fab.redhat.com> <4A4A45B2.90808@bfccomputing.com> Message-ID: <4A4B828A.1010803@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 01.07.2009 17:16, schrieb Kevin Kofler: > Those people must be trusting their hardware and software (drivers in > particular) a lot more than I do. ;-) This behaviour is not right in the time of climatic change. Running a system 7x24 hours make only sense for a server and for this system you have the need to avoid reboots. Avoiding reboots have the advantage of minimizing the time of outage during maintaining your system. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEUEARECAAYFAkpLgnkACgkQT2AHK6txfgwbuACY9udWHZSz5opYT3DQpGckDMck ZACfYAgB+YdUY3we/KWulrypiooOKyE= =6rrv -----END PGP SIGNATURE----- From rc040203 at freenet.de Wed Jul 1 15:37:55 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 01 Jul 2009 17:37:55 +0200 Subject: an update to automake-1.11? In-Reply-To: References: <1246385157.8362.127.camel@localhost.localdomain> <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> Message-ID: <4A4B82D3.1050407@freenet.de> Kevin Kofler wrote: > Ralf Corsepius wrote: >> a) it will cause some moderate stir-up to those packages whose upstreams >> are still abusing the autotools. > > s/ab// ;-) > > Why can't we just move to a better build system with higher focus on > backwards compatibility? Because a) the autotools are not as bad as you in your want to make them appear. b) it's not "we" (Fedora) who chooses the tools, it's the upstreams's choice. > (And FYI, I'm "against autotools" more than > I'm "for CMake". It's just that in the past I could just say "don't use > autotools", now I have an actual alternative to suggest.) Sigh, ... Kevin, please refrain from spreading foul and silly propaganda on topic you apparently have insufficient knowledge about. From skvidal at fedoraproject.org Wed Jul 1 15:40:15 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 1 Jul 2009 11:40:15 -0400 (EDT) Subject: an update to automake-1.11? In-Reply-To: References: <1246385157.8362.127.camel@localhost.localdomain> <20090701095220.GC19366@camelia.ucw.cz> <20090701150600.GA383@redhat.com> Message-ID: On Wed, 1 Jul 2009, Kevin Kofler wrote: > Nalin Dahyabhai wrote: >> I worry that some of the people who run EOL releases don't even know >> that they've taken on this burden, that a release going EOL means that >> we're not doing this work any more, and that means that *they* have to >> do the work. And I worry that that's partly due to us not always being >> emphatic about warning them of it. Sometimes it feels like failure. > > Maybe the last update to any EOL distro should be a firstboot-like tool > which just gives 3 options: > * Run preupgrade > * Wipe all hard disks > * Turn off computer yum install system-autodeath -sv From kevin.kofler at chello.at Wed Jul 1 15:47:11 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 01 Jul 2009 17:47:11 +0200 Subject: an update to automake-1.11? References: <1246385157.8362.127.camel@localhost.localdomain> <20090701095220.GC19366@camelia.ucw.cz> <20090701150600.GA383@redhat.com> Message-ID: Seth Vidal wrote: > yum install system-autodeath That just turns off networking (so then how do you preupgrade from there? And it lets people keep running their obsolete stuff forever in their closet) and it has to be explicitly installed. Kevin Kofler From kevin.kofler at chello.at Wed Jul 1 15:48:52 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 01 Jul 2009 17:48:52 +0200 Subject: KSplice in Fedora? References: <8278b1b0906291521i45f71873n2da7cda47161bb2d@mail.gmail.com> <1246354287.20189.56.camel@breeves.fab.redhat.com> <1246377541.20189.86.camel@breeves.fab.redhat.com> <4A4A45B2.90808@bfccomputing.com> <4A4B828A.1010803@herr-schmitt.de> Message-ID: Jochen Schmitt wrote: > Am 01.07.2009 17:16, schrieb Kevin Kofler: >> Those people must be trusting their hardware and software (drivers in >> particular) a lot more than I do. ;-) > This behaviour is not right in the time of climatic change. Whose behavior? Turning the computer off completely definitely saves more power than suspend to RAM and on some machines also suspend to disk (hibernate). Kevin Kofler From skvidal at fedoraproject.org Wed Jul 1 15:51:47 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 1 Jul 2009 11:51:47 -0400 (EDT) Subject: an update to automake-1.11? In-Reply-To: References: <1246385157.8362.127.camel@localhost.localdomain> <20090701095220.GC19366@camelia.ucw.cz> <20090701150600.GA383@redhat.com> Message-ID: On Wed, 1 Jul 2009, Kevin Kofler wrote: > Seth Vidal wrote: >> yum install system-autodeath > > That just turns off networking (so then how do you preupgrade from there? > And it lets people keep running their obsolete stuff forever in their > closet) and it has to be explicitly installed. > yum install sense-of-humor -sv From Jochen at herr-schmitt.de Wed Jul 1 15:55:03 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 01 Jul 2009 17:55:03 +0200 Subject: KSplice in Fedora? In-Reply-To: References: <8278b1b0906291521i45f71873n2da7cda47161bb2d@mail.gmail.com> <1246354287.20189.56.camel@breeves.fab.redhat.com> <1246377541.20189.86.camel@breeves.fab.redhat.com> <4A4A45B2.90808@bfccomputing.com> <4A4B828A.1010803@herr-schmitt.de> Message-ID: <4A4B86D7.7000207@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 01.07.2009 17:48, schrieb Kevin Kofler: > Whose behavior? Turning the computer off completely definitely > saves more power than suspend to RAM and on some machines also > suspend to disk (hibernate). Yes, and this is the reason why a desktop user should turns his coputer completely of to save the maximum of power. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpLhsMACgkQT2AHK6txfgzw0ACfSRYdJFzpAlVwM9lY9SURmx+F eeUAoMx9JmTHe4Vob2KvUDbiE885eJwP =aLyW -----END PGP SIGNATURE----- From ngompa13 at gmail.com Wed Jul 1 15:55:54 2009 From: ngompa13 at gmail.com (King InuYasha) Date: Wed, 1 Jul 2009 10:55:54 -0500 Subject: KSplice in Fedora? In-Reply-To: <4A4B86D7.7000207@herr-schmitt.de> References: <8278b1b0906291521i45f71873n2da7cda47161bb2d@mail.gmail.com> <1246377541.20189.86.camel@breeves.fab.redhat.com> <4A4A45B2.90808@bfccomputing.com> <4A4B828A.1010803@herr-schmitt.de> <4A4B86D7.7000207@herr-schmitt.de> Message-ID: <8278b1b0907010855n5bdbff7cpecdea67f4ae01c0b@mail.gmail.com> If your desktop doubles as a server, then no you don't turn off the computer... On Wed, Jul 1, 2009 at 10:55 AM, Jochen Schmitt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 01.07.2009 17:48, schrieb Kevin Kofler: > > Whose behavior? Turning the computer off completely definitely > > saves more power than suspend to RAM and on some machines also > > suspend to disk (hibernate). > Yes, and this is the reason why a desktop user should turns his > coputer completely of to save the maximum of power. > > Best Regards: > > Jochen Schmitt > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkpLhsMACgkQT2AHK6txfgzw0ACfSRYdJFzpAlVwM9lY9SURmx+F > eeUAoMx9JmTHe4Vob2KvUDbiE885eJwP > =aLyW > -----END PGP SIGNATURE----- > > -- > 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 bill at bfccomputing.com Wed Jul 1 16:38:39 2009 From: bill at bfccomputing.com (Bill McGonigle) Date: Wed, 01 Jul 2009 12:38:39 -0400 Subject: KSplice in Fedora? In-Reply-To: References: <8278b1b0906291521i45f71873n2da7cda47161bb2d@mail.gmail.com> <1246354287.20189.56.camel@breeves.fab.redhat.com> <1246377541.20189.86.camel@breeves.fab.redhat.com> <4A4A45B2.90808@bfccomputing.com> Message-ID: <4A4B910F.1050907@bfccomputing.com> On 06/30/2009 06:23 PM, Kevin Kofler wrote: > The average home user turns his/her computer off when going to sleep, so > he/she reboots at least once per day. Can we measure this? My anecdotal evidence says most home users walk away from the computer and let the default power management settings do whatever they do, so they don't have to worry about rebuilding their workspace state every day. Even laziness is sufficient to explain that behavior - few GUI environments can shut down without getting the user involved in making decisions about unsaved changes, terminating stuck apps, etc. I realize the plural of 'anecdote' is not 'data', however, so it would be helpful to have some data. My netbook has low uptimes because it keeps getting hosed on resume from disk, not because I shut it down. As far as the right thing to do to 'save the earth', there are a bunch of variables. 'How much power does it take to keep DRAM fresh?' vs. 'How much power does it take to book an OS from power-hungry hard drives'. Some new RAM types in the work don't need DRAM refreshes. Engineer down the power cost 'till it's negligible. Linux could come up with some sort of COW-like scheme to start running out of suspend-to-disk space instead of restoring to RAM first (then you can suspend to flash, e.g.), etc. And none of that addresses the macroeconomic opportunity cost of final-solution energy research as a function of GDP as a function of productivity (but now I'm completely off-topic). -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/ Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: bill at bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf From frankly3d at gmail.com Wed Jul 1 16:44:31 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Wed, 01 Jul 2009 17:44:31 +0100 Subject: KSplice in Fedora? In-Reply-To: <4A4B910F.1050907@bfccomputing.com> References: <8278b1b0906291521i45f71873n2da7cda47161bb2d@mail.gmail.com> <1246354287.20189.56.camel@breeves.fab.redhat.com> <1246377541.20189.86.camel@breeves.fab.redhat.com> <4A4A45B2.90808@bfccomputing.com> <4A4B910F.1050907@bfccomputing.com> Message-ID: <4A4B926F.30901@gmail.com> On 01/07/09 17:38, Bill McGonigle wrote: > On 06/30/2009 06:23 PM, Kevin Kofler wrote: >> The average home user turns his/her computer off when going to sleep, so >> he/she reboots at least once per day. > Unless they are into torrents\limewire, then it's 24/7. Their is quite a lot of normal users in that catagory. Frank From bill at bfccomputing.com Wed Jul 1 16:44:45 2009 From: bill at bfccomputing.com (Bill McGonigle) Date: Wed, 01 Jul 2009 12:44:45 -0400 Subject: KSplice in Fedora? In-Reply-To: <4A4A4955.8080303@herr-schmitt.de> References: <8278b1b0906291521i45f71873n2da7cda47161bb2d@mail.gmail.com> <1246354287.20189.56.camel@breeves.fab.redhat.com> <1246377541.20189.86.camel@breeves.fab.redhat.com> <4A4A45B2.90808@bfccomputing.com> <4A4A4955.8080303@herr-schmitt.de> Message-ID: <4A4B927D.4070903@bfccomputing.com> On 06/30/2009 01:20 PM, Jochen Schmitt wrote: > Am 30.06.2009 19:04, schrieb Bill McGonigle: >> > ksplice updates are only available for: >> > >> > 1. kernels that have been the lastest kernel in the past two weeks >> > 2. kernel updates that are remotely exploitable >> > 3. kernel updates that rate 'high' on CVSS >> > >> > I'd have to do more research to be sure, but just guessing this feels >> > like 0-4 candidates per Fedora release cycle. > Please keep in mind, that you can't handle a kernel update, if globlal > structure was changed. Jon says this isn't so (BTW, Jon, thanks for the very informative post if you're reading this). But most kernel security updates don't do this anyway, to the best of my knowledge. They're fixing a buffer check, adding an extra if to validate an assumption, etc. > Because Fedora has several kernel update in the > lifetime, you have to create a ksplice kernelpatch for each kernel release > which is available on Fedora. Since you quoted my post with criteria to avoid this, I have to assume I'm missing your point here. Could you clarify? -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/ Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: bill at bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf From ajax at redhat.com Wed Jul 1 17:22:52 2009 From: ajax at redhat.com (Adam Jackson) Date: Wed, 01 Jul 2009 13:22:52 -0400 Subject: an update to automake-1.11? In-Reply-To: References: <1246385157.8362.127.camel@localhost.localdomain> <20090701095220.GC19366@camelia.ucw.cz> <20090701150600.GA383@redhat.com> Message-ID: <1246468972.25343.8537.camel@atropine.boston.devel.redhat.com> On Wed, 2009-07-01 at 11:51 -0400, Seth Vidal wrote: > On Wed, 1 Jul 2009, Kevin Kofler wrote: > > Seth Vidal wrote: > >> yum install system-autodeath > > > > That just turns off networking (so then how do you preupgrade from there? > > And it lets people keep running their obsolete stuff forever in their > > closet) and it has to be explicitly installed. > > yum install sense-of-humor He can't, KDE doesn't support that yet. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pjones at redhat.com Wed Jul 1 17:30:51 2009 From: pjones at redhat.com (Peter Jones) Date: Wed, 01 Jul 2009 13:30:51 -0400 Subject: an update to automake-1.11? In-Reply-To: <1246468972.25343.8537.camel@atropine.boston.devel.redhat.com> References: <1246385157.8362.127.camel@localhost.localdomain> <20090701095220.GC19366@camelia.ucw.cz> <20090701150600.GA383@redhat.com> <1246468972.25343.8537.camel@atropine.boston.devel.redhat.com> Message-ID: <4A4B9D4B.2080800@redhat.com> On 07/01/2009 01:22 PM, Adam Jackson wrote: > On Wed, 2009-07-01 at 11:51 -0400, Seth Vidal wrote: >> On Wed, 1 Jul 2009, Kevin Kofler wrote: >>> Seth Vidal wrote: >>>> yum install system-autodeath >>> That just turns off networking (so then how do you preupgrade from there? >>> And it lets people keep running their obsolete stuff forever in their >>> closet) and it has to be explicitly installed. >> yum install sense-of-humor > > He can't, KDE doesn't support that yet. Did you inform them that they needed to? -- Peter The trouble with the global village are all the global village idiots. -- Paul Ginsparg From fedora at matbooth.co.uk Wed Jul 1 17:33:13 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Wed, 1 Jul 2009 18:33:13 +0100 Subject: Segfault connecting to a VPN through NetworkManager In-Reply-To: <4A4B2F18.2090004@city-fan.org> References: <9497e9990906301352s35c97ac9oc0253217b382481@mail.gmail.com> <4A4B2F18.2090004@city-fan.org> Message-ID: <9497e9990907011033h21e37366ud51d1142482e20ac@mail.gmail.com> On Wed, Jul 1, 2009 at 10:40 AM, Paul Howarth wrote: > On 30/06/09 21:52, Mat Booth wrote: >> >> Hi, >> >> I got this segfault trying to connect to the Microsoft VPN at work. [1] >> >> What should I raise a ticket against? NetworkManager, kernel, pptp, >> none of the above? >> >> [1] http://mbooth.fedorapeople.org/vpn-bug.txt > > Looks like pptp to me; can you repeat the segfault with pptp-debuginfo > installed? > > Paul. > Good idea, I should have thought of that. But wouldn't you know it? I install the debuginfo and the damned thing works perfectly. :-/ (Not that I'm complaining, you understand. I just really hate when something fixes itself.) I definitely raise a ticket if I see it again. Thanks all the same. -- Mat Booth www.matbooth.co.uk From jamatos at fc.up.pt Wed Jul 1 17:43:38 2009 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Wed, 1 Jul 2009 18:43:38 +0100 Subject: an update to automake-1.11? In-Reply-To: <1246468972.25343.8537.camel@atropine.boston.devel.redhat.com> References: <1246385157.8362.127.camel@localhost.localdomain> <1246468972.25343.8537.camel@atropine.boston.devel.redhat.com> Message-ID: <200907011843.39270.jamatos@fc.up.pt> On Wednesday 01 July 2009 18:22:52 Adam Jackson wrote: > He can't, KDE doesn't support that yet. > > - ajax Neither does gnome apparently: :-) $ yum search sense-of-humor Loaded plugins: dellsysidplugin2, presto, refresh-packagekit Warning: No matches found for: sense-of-humor No Matches found In any case I would recommend the better form: yum install sense-of-humor --skip-broken as you never know what can be broken if you do that. ;-) -- Jos? Ab?lio From Jochen at herr-schmitt.de Wed Jul 1 17:48:34 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 01 Jul 2009 19:48:34 +0200 Subject: KSplice in Fedora? In-Reply-To: <4A4B927D.4070903@bfccomputing.com> References: <8278b1b0906291521i45f71873n2da7cda47161bb2d@mail.gmail.com> <1246354287.20189.56.camel@breeves.fab.redhat.com> <1246377541.20189.86.camel@breeves.fab.redhat.com> <4A4A45B2.90808@bfccomputing.com> <4A4A4955.8080303@herr-schmitt.de> <4A4B927D.4070903@bfccomputing.com> Message-ID: <4A4BA172.8090408@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 01.07.2009 18:44, schrieb Bill McGonigle: > Because Fedora has several kernel update in the >> lifetime, you have to create a ksplice kernelpatch for each >> kernel release which is available on Fedora. > > Since you quoted my post with criteria to avoid this, I have to > assume I'm missing your point here. Could you clarify? > Ok, lets assume, that we have a security kernel patch for Fedora-10. On Fedora we have kernels from the 2.6.27 and from the 2.6.28 series. This means, that you have to create seperates kernel patch modules for each kernel release which was submitted for Fedora-10. The reseason to do it, is that ksplice is not able to handled patches, which may change global data structures. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpLoVkACgkQT2AHK6txfgzmFACgrhko8Pnppq48txUYl3HS6/QE J+8AoNhj2aSfI5jW4UGTuQQb6x+TD9Tm =0KZA -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From ville.skytta at iki.fi Wed Jul 1 18:02:45 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 1 Jul 2009 21:02:45 +0300 Subject: mingw32 debuginfo packages without sources, build id Message-ID: <200907012102.47030.ville.skytta@iki.fi> Hello, I noticed a bunch of mingw32*-debuginfo packages that contain only *.debug (no sources, no build id) appeared in Rawhide. Is this how mingw32 debuginfo packages are supposed to look like, or is the infrastructure for creating the debuginfo packages not quite complete, or are these packaging bugs? mingw32-boost-debuginfo-1.39.0-2.fc12.noarch mingw32-cairomm-debuginfo-1.8.0-3.fc12.noarch mingw32-glib2-debuginfo-2.21.2-2.fc12.noarch mingw32-glibmm24-debuginfo-2.20.0-4.fc12.noarch mingw32-gtkmm24-debuginfo-2.16.0-2.fc12.noarch mingw32-libglade2-debuginfo-2.6.4-3.fc12.noarch mingw32-libglademm24-debuginfo-2.6.7-7.fc12.noarch mingw32-libgnurx-debuginfo-2.5.1-5.fc12.noarch mingw32-libsigc++20-debuginfo-2.2.2-8.fc12.noarch mingw32-libsqlite3x-debuginfo-20071018-8.fc12.noarch mingw32-libxml++-debuginfo-2.26.0-2.fc12.noarch mingw32-pangomm-debuginfo-2.24.0-3.fc12.noarch mingw32-plotmm-debuginfo-0.1.2-3.fc12.noarch mingw32-qt-debuginfo-4.5.2-1.fc12.noarch mingw32-qwt-debuginfo-5.1.1-8.fc12.noarch mingw32-sqlite-debuginfo-3.6.14.2-1.fc12.noarch mingw32-tcl-debuginfo-8.5.7-6.fc12.noarch mingw32-wpcap-debuginfo-4.1.beta5-6.fc12.noarch mingw32-zfstream-debuginfo-20041202-6.fc12.noarch From linville at redhat.com Wed Jul 1 18:18:57 2009 From: linville at redhat.com (John W. Linville) Date: Wed, 1 Jul 2009 14:18:57 -0400 Subject: Wireless summit at FUDCon in Berlin -- thanks! Message-ID: <20090701181857.GE2276@redhat.com> On 26-27 June 2009 a Linux wireless mini-summit was hosted by the Fedora project as part of their FUDCon event in Berlin, Germany. This event was attended by well over a dozen upstream Linux developers representing various kernel wireless LAN drivers, kernel wireless LAN infrastructure components, and related userland applications. Attendees also represented hardware vendors, Fedora and other Linux distributions, and other members of the overall community. Discussions covered a number of development issues, including status updates related to recent developments and preliminary design discussions for future API enhancements. In particular, the face-to-face involvement of hardware vendors revealed the need for a "testing mode" extension to the new cfg80211 API for wireless LAN configuration. One of the attendees is a voting member of the IEEE802.11 standards body, and he gave a very useful overview of current standards activities and their likely impacts on Linux over the next few years. On the BarCamp day of FUDCon some of the wireless attendees provided content for two one-hour slots. One of these was an introduction for would-be developers to understand the basics of the wireless LAN APIs in the kernel. The other was split between a short overview of some of the powersaving improvements happening for wireless LANs and an interesting presentation on Freifunk, a community-based free wireless LAN deployment in Berlin. The Freifunk presentation also touched upon some similar projects ongoing throughout the world. Given my position as the Linux kernel wireless LAN maintainer, I found this meeting to be extremely valuable. Developers are far more productive when they know each other and have some personal connections. Further, face-to-face meetings enable fast-paced discussions that would be difficult or impossible to complete in an electronic (i.e. email, IRC, etc) environment. Keeping these people working well together is the key to further improvements and successful maintenance in RHEL, Fedora, and the rest of Linux community. On behalf of the upstream Linux wireless LAN developer community, I would like to express our gratitude to the Fedora project for doing its part to enable our continued progress. Of course, I also want to thank the wireless LAN developers (and those who may have sponsored their travel) for coming to the event. You guys are the ones who make all these good things happen. The fact that you are all friendly and cooperative makes things even better! I enjoyed seeing all of you in Berlin, both the ones I had already met and the new faces as well. I look forward to our next opportunity to meet face-to-face, and I anticipate lots of productive email between now and then! Thanks! John -- John W. Linville Linux should be at the core linville at redhat.com of your literate lifestyle. From bill at bfccomputing.com Wed Jul 1 18:19:01 2009 From: bill at bfccomputing.com (Bill McGonigle) Date: Wed, 01 Jul 2009 14:19:01 -0400 Subject: KSplice in Fedora? In-Reply-To: <4A4BA172.8090408@herr-schmitt.de> References: <8278b1b0906291521i45f71873n2da7cda47161bb2d@mail.gmail.com> <1246354287.20189.56.camel@breeves.fab.redhat.com> <1246377541.20189.86.camel@breeves.fab.redhat.com> <4A4A45B2.90808@bfccomputing.com> <4A4A4955.8080303@herr-schmitt.de> <4A4B927D.4070903@bfccomputing.com> <4A4BA172.8090408@herr-schmitt.de> Message-ID: <4A4BA895.8030406@bfccomputing.com> On 07/01/2009 01:48 PM, Jochen Schmitt wrote: > > On Fedora we have kernels from the 2.6.27 and from the 2.6.28 series. > This means, that you have to create seperates kernel patch modules for > each kernel release which was submitted for Fedora-10. This is why I suggested it would be practical to set a bar. The example I gave was a kernel which was the latest kernel in the past two weeks. This would usually be one, occasionally two. For a sysadmin, it's pretty easy to schedule a reboot within two weeks. '-r now' can be impossible. > The reseason to do it, is that ksplice is not able to handled patches, > which may change global data structures. Have there been remotely exploitable and/or CVSS 'high' kernel problems for which the patches need to change global data structures? Perhaps I'm just unaware of them. Besides this, Jon Masters' post says ksplice can handle this (unless I'm misunderstanding his post). Even though it can, if a bar as set above were set, Fedora wouldn't need to. -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/ Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: bill at bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf From jonathan at jonmasters.org Wed Jul 1 19:29:55 2009 From: jonathan at jonmasters.org (Jon Masters) Date: Wed, 01 Jul 2009 15:29:55 -0400 Subject: KSplice in Fedora? In-Reply-To: <4A4BA895.8030406@bfccomputing.com> References: <8278b1b0906291521i45f71873n2da7cda47161bb2d@mail.gmail.com> <1246354287.20189.56.camel@breeves.fab.redhat.com> <1246377541.20189.86.camel@breeves.fab.redhat.com> <4A4A45B2.90808@bfccomputing.com> <4A4A4955.8080303@herr-schmitt.de> <4A4B927D.4070903@bfccomputing.com> <4A4BA172.8090408@herr-schmitt.de> <4A4BA895.8030406@bfccomputing.com> Message-ID: <1246476595.5270.318.camel@perihelion.bos.jonmasters.org> On Wed, 2009-07-01 at 14:19 -0400, Bill McGonigle wrote: > On 07/01/2009 01:48 PM, Jochen Schmitt wrote: > > > > On Fedora we have kernels from the 2.6.27 and from the 2.6.28 series. > > This means, that you have to create seperates kernel patch modules for > > each kernel release which was submitted for Fedora-10. > > This is why I suggested it would be practical to set a bar. I think it would be very useful to offer rebootless updates on a schedule - so for example, "one CVE fix" followed by "must reboot within a week or so", during which time it is unlikely there will be another CVE to stack upon the first. Truly never rebooting is something most users aren't worried too much about (even with shiny Apple crap) and those who are tend to be telco/embedded types who have had their own hacks for years and years - Montavista still have something in CGL. > The example I gave was a kernel which was the latest kernel in the > past two weeks. This would usually be one, occasionally two. For a > sysadmin, it's pretty easy to schedule a reboot within two weeks. > '-r now' can be impossible. Indeed. There's a lot of value in saying that you can delay the reboot but that you're protected now - akin to the syscall table hacks we used to shove onto some systems to fix the vmsplice of the moment issue. > > The reseason to do it, is that ksplice is not able to handled patches, > > which may change global data structures. Why not ask Tim to comment on the limitations directly? The ksplice guys are pretty amenable types and I'm sure they would happily chat with you. Jon. From cebbert at redhat.com Wed Jul 1 19:31:44 2009 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 1 Jul 2009 15:31:44 -0400 Subject: kernel-2.6.29.5-206.fc11.x86_64 in koji In-Reply-To: <1246408609.2167.3.camel@scrappy.miketc.net> References: <1246408609.2167.3.camel@scrappy.miketc.net> Message-ID: <20090701153144.0c5a43e8@dhcp-100-2-144.bos.redhat.com> On Tue, 30 Jun 2009 19:36:49 -0500 Mike Chambers wrote: > Installed this kernel, and upon boot it panics. I can't find anything > in any logs, as it seems to happen upon first start of boot (as in > during the "quiet" part of boot) before the processes are started to > come up. > If it's what I think it is, that should be fixed in the 2.6.29.6-rc1 that was just built. From ville.skytta at iki.fi Wed Jul 1 20:21:43 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 1 Jul 2009 23:21:43 +0300 Subject: New maintainer needed: dumpasn1, freedroid, http_ping, id3v2, pscan, zzuf Message-ID: <200907012321.43913.ville.skytta@iki.fi> I have released ownership of the following packages I haven't used in a while and don't feel like maintaining just for the fun of it. They're all simple, very low maintenance ones, in good shape (no open bugs and otherwise), and up to date with latest upstream versions. dumpasn1 freedroid http_ping id3v2 pscan zzuf I may end up keeping an eye on some of these every now and then later unless a new maintainer appears. No promises though. From limb at jcomserv.net Wed Jul 1 20:27:03 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 01 Jul 2009 15:27:03 -0500 Subject: New maintainer needed: dumpasn1, freedroid, http_ping, id3v2, pscan, zzuf In-Reply-To: <200907012321.43913.ville.skytta@iki.fi> References: <200907012321.43913.ville.skytta@iki.fi> Message-ID: <4A4BC697.9020305@jcomserv.net> Ville Skytt? wrote: > I have released ownership of the following packages I haven't used in a while > and don't feel like maintaining just for the fun of it. They're all simple, > very low maintenance ones, in good shape (no open bugs and otherwise), and up > to date with latest upstream versions. > > dumpasn1 > freedroid > http_ping > id3v2 > pscan > zzuf > > I may end up keeping an eye on some of these every now and then later unless a > new maintainer appears. No promises though. > > I grabbed freedroid and zzuf. -- in your fear, speak only peace in your fear, seek only love -d. bowie From philipp_subx at redfish-solutions.com Wed Jul 1 20:43:31 2009 From: philipp_subx at redfish-solutions.com (Philip A. Prindeville) Date: Wed, 01 Jul 2009 13:43:31 -0700 Subject: Getting MD5 sum mismatch errors unpacking rawhide on FC9 Message-ID: <4A4BCA73.1030707@redfish-solutions.com> I have an FC9 (updated) x86_64 install, and I just tried to pull down proftpd.src from rawhide-source. I'm seeing the following: [philipp at builder SPECS]$ rpm -vv -i /tmp/proftpd-1.3.2-2.fc11.src.rpm D: ============== /tmp/proftpd-1.3.2-2.fc11.src.rpm D: Expected size: 2471936 = lead(96)+sigs(1284)+pad(4)+data(2470552) D: Actual size: 2471936 D: opening db index /var/lib/rpm/Packages rdonly mode=0x0 D: locked db index /var/lib/rpm/Packages D: opening db index /var/lib/rpm/Pubkeys rdonly mode=0x0 warning: /tmp/proftpd-1.3.2-2.fc11.src.rpm: Header V3 RSA/SHA256 signature: NOKEY, key ID d22e77f2 D: added source package [0] D: found 1 source and 0 binary packages D: Expected size: 2471936 = lead(96)+sigs(1284)+pad(4)+data(2470552) D: Actual size: 2471936 D: InstallSourcePackage: Header V3 RSA/SHA256 signature: NOKEY, key ID d22e77f2 proftpd-1.3.2-2.fc11 D: ========== Directories not explicitly included in package: D: 0 /home/philipp/rpmbuild/SOURCES/ D: 1 /home/philipp/rpmbuild/SPECS/ D: ========== warning: user mockbuild does not exist - using root warning: group mockbuild does not exist - using root D: undo 100664 1 ( 0, 0) 2457498 /home/philipp/rpmbuild/SOURCES/proftpd-1.3.2.tar.bz2;4a4bc949 GZDIO: 301 reads, 2465792 total bytes in 0.008182 secs error: unpacking of archive failed on file /home/philipp/rpmbuild/SOURCES/proftpd-1.3.2.tar.bz2;4a4bc949: cpio: MD5 sum mismatch D: closed db index /var/lib/rpm/Pubkeys D: closed db index /var/lib/rpm/Packages D: May free Score board((nil)) [philipp at builder SPECS]$ What am I missing here? From dennis at ausil.us Wed Jul 1 20:57:26 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 1 Jul 2009 15:57:26 -0500 Subject: Getting MD5 sum mismatch errors unpacking rawhide on FC9 In-Reply-To: <4A4BCA73.1030707@redfish-solutions.com> References: <4A4BCA73.1030707@redfish-solutions.com> Message-ID: <200907011557.27535.dennis@ausil.us> On Wednesday 01 July 2009 03:43:31 pm Philip A. Prindeville wrote: > I have an FC9 (updated) x86_64 install, and I just tried to pull down > proftpd.src from rawhide-source. > > I'm seeing the following: > > [philipp at builder SPECS]$ rpm -vv -i /tmp/proftpd-1.3.2-2.fc11.src.rpm > D: ============== /tmp/proftpd-1.3.2-2.fc11.src.rpm > D: Expected size: 2471936 = lead(96)+sigs(1284)+pad(4)+data(2470552) > D: Actual size: 2471936 > D: opening db index /var/lib/rpm/Packages rdonly mode=0x0 > D: locked db index /var/lib/rpm/Packages > D: opening db index /var/lib/rpm/Pubkeys rdonly mode=0x0 > warning: /tmp/proftpd-1.3.2-2.fc11.src.rpm: Header V3 RSA/SHA256 signature: > NOKEY, key ID d22e77f2 D: added source package [0] > D: found 1 source and 0 binary packages > D: Expected size: 2471936 = lead(96)+sigs(1284)+pad(4)+data(2470552) > D: Actual size: 2471936 > D: InstallSourcePackage: Header V3 RSA/SHA256 signature: NOKEY, key ID > d22e77f2 proftpd-1.3.2-2.fc11 > D: ========== Directories not explicitly included in package: > D: 0 /home/philipp/rpmbuild/SOURCES/ > D: 1 /home/philipp/rpmbuild/SPECS/ > D: ========== > warning: user mockbuild does not exist - using root > warning: group mockbuild does not exist - using root > D: undo 100664 1 ( 0, 0) 2457498 > /home/philipp/rpmbuild/SOURCES/proftpd-1.3.2.tar.bz2;4a4bc949 GZDIO: > 301 reads, 2465792 total bytes in 0.008182 secs > error: unpacking of archive failed on file > /home/philipp/rpmbuild/SOURCES/proftpd-1.3.2.tar.bz2;4a4bc949: cpio: MD5 > sum mismatch D: closed db index /var/lib/rpm/Pubkeys > D: closed db index /var/lib/rpm/Packages > D: May free Score board((nil)) > [philipp at builder SPECS]$ > > > What am I missing here? rpm in F-11 and newer uses a sha256sum and mot md5sum the rpm is incompatible. you would need to get the rpm from F-10 updates to install it 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 philipp_subx at redfish-solutions.com Wed Jul 1 21:01:20 2009 From: philipp_subx at redfish-solutions.com (Philip A. Prindeville) Date: Wed, 01 Jul 2009 14:01:20 -0700 Subject: Getting MD5 sum mismatch errors unpacking rawhide on FC9 In-Reply-To: <200907011557.27535.dennis@ausil.us> References: <4A4BCA73.1030707@redfish-solutions.com> <200907011557.27535.dennis@ausil.us> Message-ID: <4A4BCEA0.1050205@redfish-solutions.com> Dennis Gilmore wrote: > On Wednesday 01 July 2009 03:43:31 pm Philip A. Prindeville wrote: > >> I have an FC9 (updated) x86_64 install, and I just tried to pull down >> proftpd.src from rawhide-source. >> >> I'm seeing the following: >> >> [philipp at builder SPECS]$ rpm -vv -i /tmp/proftpd-1.3.2-2.fc11.src.rpm >> D: ============== /tmp/proftpd-1.3.2-2.fc11.src.rpm >> D: Expected size: 2471936 = lead(96)+sigs(1284)+pad(4)+data(2470552) >> D: Actual size: 2471936 >> D: opening db index /var/lib/rpm/Packages rdonly mode=0x0 >> D: locked db index /var/lib/rpm/Packages >> D: opening db index /var/lib/rpm/Pubkeys rdonly mode=0x0 >> warning: /tmp/proftpd-1.3.2-2.fc11.src.rpm: Header V3 RSA/SHA256 signature: >> NOKEY, key ID d22e77f2 D: added source package [0] >> D: found 1 source and 0 binary packages >> D: Expected size: 2471936 = lead(96)+sigs(1284)+pad(4)+data(2470552) >> D: Actual size: 2471936 >> D: InstallSourcePackage: Header V3 RSA/SHA256 signature: NOKEY, key ID >> d22e77f2 proftpd-1.3.2-2.fc11 >> D: ========== Directories not explicitly included in package: >> D: 0 /home/philipp/rpmbuild/SOURCES/ >> D: 1 /home/philipp/rpmbuild/SPECS/ >> D: ========== >> warning: user mockbuild does not exist - using root >> warning: group mockbuild does not exist - using root >> D: undo 100664 1 ( 0, 0) 2457498 >> /home/philipp/rpmbuild/SOURCES/proftpd-1.3.2.tar.bz2;4a4bc949 GZDIO: >> 301 reads, 2465792 total bytes in 0.008182 secs >> error: unpacking of archive failed on file >> /home/philipp/rpmbuild/SOURCES/proftpd-1.3.2.tar.bz2;4a4bc949: cpio: MD5 >> sum mismatch D: closed db index /var/lib/rpm/Pubkeys >> D: closed db index /var/lib/rpm/Packages >> D: May free Score board((nil)) >> [philipp at builder SPECS]$ >> >> >> What am I missing here? >> > rpm in F-11 and newer uses a sha256sum and mot md5sum the rpm is > incompatible. you would need to get the rpm from F-10 updates to install it > > > Dennis > Grrr... that would cause all sorts of other things to be brought in. I just need to rebuild certain Rawhide or FC11 packages for FC9. Is there an easy way to do this using mock? -Philip From sandeen at redhat.com Wed Jul 1 21:03:37 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 01 Jul 2009 16:03:37 -0500 Subject: Getting MD5 sum mismatch errors unpacking rawhide on FC9 In-Reply-To: <4A4BCEA0.1050205@redfish-solutions.com> References: <4A4BCA73.1030707@redfish-solutions.com> <200907011557.27535.dennis@ausil.us> <4A4BCEA0.1050205@redfish-solutions.com> Message-ID: <4A4BCF29.9020401@redhat.com> Philip A. Prindeville wrote: > Grrr... that would cause all sorts of other things to be brought in. > > I just need to rebuild certain Rawhide or FC11 packages for FC9. Is > there an easy way to do this using mock? > > -Philip rpm -i --nomd5 blah.src.rpm rpmbuild -ba blah.spec -Eric From sandeen at redhat.com Wed Jul 1 21:04:26 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 01 Jul 2009 16:04:26 -0500 Subject: Getting MD5 sum mismatch errors unpacking rawhide on FC9 In-Reply-To: <4A4BCF29.9020401@redhat.com> References: <4A4BCA73.1030707@redfish-solutions.com> <200907011557.27535.dennis@ausil.us> <4A4BCEA0.1050205@redfish-solutions.com> <4A4BCF29.9020401@redhat.com> Message-ID: <4A4BCF5A.6070504@redhat.com> Eric Sandeen wrote: > Philip A. Prindeville wrote: > >> Grrr... that would cause all sorts of other things to be brought in. >> >> I just need to rebuild certain Rawhide or FC11 packages for FC9. Is >> there an easy way to do this using mock? >> >> -Philip > > rpm -i --nomd5 blah.src.rpm > rpmbuild -ba blah.spec > > -Eric > or maybe rpmbuild -bs blah.spec and mock build the resulting src.rpm -Eric From paul at city-fan.org Wed Jul 1 21:06:17 2009 From: paul at city-fan.org (Paul Howarth) Date: Wed, 1 Jul 2009 22:06:17 +0100 Subject: Getting MD5 sum mismatch errors unpacking rawhide on FC9 In-Reply-To: <4A4BCEA0.1050205@redfish-solutions.com> References: <4A4BCA73.1030707@redfish-solutions.com> <200907011557.27535.dennis@ausil.us> <4A4BCEA0.1050205@redfish-solutions.com> Message-ID: <20090701220617.79e02dcd@metropolis.intra.city-fan.org> On Wed, 01 Jul 2009 14:01:20 -0700 "Philip A. Prindeville" wrote: > Dennis Gilmore wrote: > > On Wednesday 01 July 2009 03:43:31 pm Philip A. Prindeville wrote: > > > >> I have an FC9 (updated) x86_64 install, and I just tried to pull > >> down proftpd.src from rawhide-source. > >> > >> I'm seeing the following: > >> > >> [philipp at builder SPECS]$ rpm -vv > >> -i /tmp/proftpd-1.3.2-2.fc11.src.rpm D: > >> ============== /tmp/proftpd-1.3.2-2.fc11.src.rpm D: Expected > >> size: 2471936 = lead(96)+sigs(1284)+pad(4)+data(2470552) D: > >> Actual size: 2471936 D: opening db > >> index /var/lib/rpm/Packages rdonly mode=0x0 D: locked db > >> index /var/lib/rpm/Packages D: opening db > >> index /var/lib/rpm/Pubkeys rdonly mode=0x0 > >> warning: /tmp/proftpd-1.3.2-2.fc11.src.rpm: Header V3 RSA/SHA256 > >> signature: NOKEY, key ID d22e77f2 D: added source package > >> [0] D: found 1 source and 0 binary packages D: Expected size: > >> 2471936 = lead(96)+sigs(1284)+pad(4)+data(2470552) D: Actual > >> size: 2471936 D: InstallSourcePackage: Header V3 RSA/SHA256 > >> signature: NOKEY, key ID d22e77f2 proftpd-1.3.2-2.fc11 > >> D: ========== Directories not explicitly included in package: > >> D: 0 /home/philipp/rpmbuild/SOURCES/ > >> D: 1 /home/philipp/rpmbuild/SPECS/ > >> D: ========== > >> warning: user mockbuild does not exist - using root > >> warning: group mockbuild does not exist - using root > >> D: undo 100664 1 ( 0, 0) 2457498 > >> /home/philipp/rpmbuild/SOURCES/proftpd-1.3.2.tar.bz2;4a4bc949 > >> GZDIO: 301 reads, 2465792 total bytes in 0.008182 secs > >> error: unpacking of archive failed on file > >> /home/philipp/rpmbuild/SOURCES/proftpd-1.3.2.tar.bz2;4a4bc949: > >> cpio: MD5 sum mismatch D: closed db > >> index /var/lib/rpm/Pubkeys D: closed db > >> index /var/lib/rpm/Packages D: May free Score board((nil)) > >> [philipp at builder SPECS]$ > >> > >> > >> What am I missing here? > >> > > rpm in F-11 and newer uses a sha256sum and mot md5sum the rpm is > > incompatible. you would need to get the rpm from F-10 updates to > > install it > > > > > > Dennis > > > > Grrr... that would cause all sorts of other things to be brought in. > > I just need to rebuild certain Rawhide or FC11 packages for FC9. Is > there an easy way to do this using mock? Easiest way is probably to check out the desired packages from CVS, do "make srpm" and then rebuild that. proftpd will be updated to 1.3.2a in a day or two by the way. Paul. > > -Philip > From maxamillion at gmail.com Wed Jul 1 21:09:26 2009 From: maxamillion at gmail.com (Adam Miller) Date: Wed, 1 Jul 2009 16:09:26 -0500 Subject: New maintainer needed: dumpasn1, freedroid, http_ping, id3v2, pscan, zzuf In-Reply-To: <4A4BC697.9020305@jcomserv.net> References: <200907012321.43913.ville.skytta@iki.fi> <4A4BC697.9020305@jcomserv.net> Message-ID: I would like to take http_ping and pscan. -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From jwboyer at gmail.com Wed Jul 1 21:03:36 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 1 Jul 2009 17:03:36 -0400 Subject: Getting MD5 sum mismatch errors unpacking rawhide on FC9 In-Reply-To: <4A4BCA73.1030707@redfish-solutions.com> References: <4A4BCA73.1030707@redfish-solutions.com> Message-ID: <20090701210336.GA5772@hansolo.jdub.homelinux.org> On Wed, Jul 01, 2009 at 01:43:31PM -0700, Philip A. Prindeville wrote: >I have an FC9 (updated) x86_64 install, and I just tried to pull down >proftpd.src from rawhide-source. > >I'm seeing the following: > >[philipp at builder SPECS]$ rpm -vv -i /tmp/proftpd-1.3.2-2.fc11.src.rpm >D: ============== /tmp/proftpd-1.3.2-2.fc11.src.rpm >D: Expected size: 2471936 = lead(96)+sigs(1284)+pad(4)+data(2470552) >D: Actual size: 2471936 >D: opening db index /var/lib/rpm/Packages rdonly mode=0x0 >D: locked db index /var/lib/rpm/Packages >D: opening db index /var/lib/rpm/Pubkeys rdonly mode=0x0 >warning: /tmp/proftpd-1.3.2-2.fc11.src.rpm: Header V3 RSA/SHA256 signature: NOKEY, key ID d22e77f2 >D: added source package [0] >D: found 1 source and 0 binary packages >D: Expected size: 2471936 = lead(96)+sigs(1284)+pad(4)+data(2470552) >D: Actual size: 2471936 >D: InstallSourcePackage: Header V3 RSA/SHA256 signature: NOKEY, key ID d22e77f2 >proftpd-1.3.2-2.fc11 >D: ========== Directories not explicitly included in package: >D: 0 /home/philipp/rpmbuild/SOURCES/ >D: 1 /home/philipp/rpmbuild/SPECS/ >D: ========== >warning: user mockbuild does not exist - using root >warning: group mockbuild does not exist - using root >D: undo 100664 1 ( 0, 0) 2457498 /home/philipp/rpmbuild/SOURCES/proftpd-1.3.2.tar.bz2;4a4bc949 >GZDIO: 301 reads, 2465792 total bytes in 0.008182 secs >error: unpacking of archive failed on file /home/philipp/rpmbuild/SOURCES/proftpd-1.3.2.tar.bz2;4a4bc949: cpio: MD5 sum mismatch >D: closed db index /var/lib/rpm/Pubkeys >D: closed db index /var/lib/rpm/Packages >D: May free Score board((nil)) >[philipp at builder SPECS]$ > > >What am I missing here? An rpm version capable of dealing with the larger checksums used in F11 and rawhide RPMs perhaps. That would be my guess. josh From txtoth at gmail.com Wed Jul 1 21:19:37 2009 From: txtoth at gmail.com (Xavier Toth) Date: Wed, 1 Jul 2009 16:19:37 -0500 Subject: F10 anaconda incompatible with current F10 yum - WTF Message-ID: [Bug 509024] TypeError: doLoggingSetup() takes at most 5 arguments (6 given) --- Comment #4 from Chris Lumens 2009-07-01 10:00:03 EDT --- This is likely because you are using an updated yum but the original anaconda for F10. We do not release updates for anaconda for older releases as it makes little sense, and the reasons have been rehashed in plenty of places so it's not worth discussing here again. - Show quoted text - So I do a yum update, pickup a yum that isn't compatible with the original anaconda and then can no longer make installable DVD's. This is busted! If anaconda is dependent on a specific version of yum then it's Requires need to be equal to that version and not greater than or equal to. Ted From philipp_subx at redfish-solutions.com Wed Jul 1 21:21:57 2009 From: philipp_subx at redfish-solutions.com (Philip A. Prindeville) Date: Wed, 01 Jul 2009 14:21:57 -0700 Subject: Getting MD5 sum mismatch errors unpacking rawhide on FC9 In-Reply-To: <20090701220617.79e02dcd@metropolis.intra.city-fan.org> References: <4A4BCA73.1030707@redfish-solutions.com> <200907011557.27535.dennis@ausil.us> <4A4BCEA0.1050205@redfish-solutions.com> <20090701220617.79e02dcd@metropolis.intra.city-fan.org> Message-ID: <4A4BD375.6060906@redfish-solutions.com> Paul Howarth wrote: > On Wed, 01 Jul 2009 14:01:20 -0700 > "Philip A. Prindeville" wrote: > > >> Dennis Gilmore wrote: >> >>> On Wednesday 01 July 2009 03:43:31 pm Philip A. Prindeville wrote: >>> >>> >>>> I have an FC9 (updated) x86_64 install, and I just tried to pull >>>> down proftpd.src from rawhide-source. >>>> >>>> I'm seeing the following: >>>> >>>> [philipp at builder SPECS]$ rpm -vv >>>> -i /tmp/proftpd-1.3.2-2.fc11.src.rpm D: >>>> ============== /tmp/proftpd-1.3.2-2.fc11.src.rpm D: Expected >>>> size: 2471936 = lead(96)+sigs(1284)+pad(4)+data(2470552) D: >>>> Actual size: 2471936 D: opening db >>>> index /var/lib/rpm/Packages rdonly mode=0x0 D: locked db >>>> index /var/lib/rpm/Packages D: opening db >>>> index /var/lib/rpm/Pubkeys rdonly mode=0x0 >>>> warning: /tmp/proftpd-1.3.2-2.fc11.src.rpm: Header V3 RSA/SHA256 >>>> signature: NOKEY, key ID d22e77f2 D: added source package >>>> [0] D: found 1 source and 0 binary packages D: Expected size: >>>> 2471936 = lead(96)+sigs(1284)+pad(4)+data(2470552) D: Actual >>>> size: 2471936 D: InstallSourcePackage: Header V3 RSA/SHA256 >>>> signature: NOKEY, key ID d22e77f2 proftpd-1.3.2-2.fc11 >>>> D: ========== Directories not explicitly included in package: >>>> D: 0 /home/philipp/rpmbuild/SOURCES/ >>>> D: 1 /home/philipp/rpmbuild/SPECS/ >>>> D: ========== >>>> warning: user mockbuild does not exist - using root >>>> warning: group mockbuild does not exist - using root >>>> D: undo 100664 1 ( 0, 0) 2457498 >>>> /home/philipp/rpmbuild/SOURCES/proftpd-1.3.2.tar.bz2;4a4bc949 >>>> GZDIO: 301 reads, 2465792 total bytes in 0.008182 secs >>>> error: unpacking of archive failed on file >>>> /home/philipp/rpmbuild/SOURCES/proftpd-1.3.2.tar.bz2;4a4bc949: >>>> cpio: MD5 sum mismatch D: closed db >>>> index /var/lib/rpm/Pubkeys D: closed db >>>> index /var/lib/rpm/Packages D: May free Score board((nil)) >>>> [philipp at builder SPECS]$ >>>> >>>> >>>> What am I missing here? >>>> >>>> >>> rpm in F-11 and newer uses a sha256sum and mot md5sum the rpm is >>> incompatible. you would need to get the rpm from F-10 updates to >>> install it >>> >>> >>> Dennis >>> >>> >> Grrr... that would cause all sorts of other things to be brought in. >> >> I just need to rebuild certain Rawhide or FC11 packages for FC9. Is >> there an easy way to do this using mock? >> > > Easiest way is probably to check out the desired packages from CVS, do > "make srpm" and then rebuild that. > > proftpd will be updated to 1.3.2a in a day or two by the way. > Good to know. Hopefully this bug will be fixed at that time: https://bugzilla.redhat.com/show_bug.cgi?id=509251 I noticed that it's not just FC9 that's affected, but rawhide too. -Philip > Paul. > > >> -Philip >> >> > > From jim at meyering.net Wed Jul 1 21:49:00 2009 From: jim at meyering.net (Jim Meyering) Date: Wed, 01 Jul 2009 23:49:00 +0200 Subject: an update to automake-1.11? In-Reply-To: <1246446548.598.43.camel@blaa> (Mark McLoughlin's message of "Wed, 01 Jul 2009 12:09:08 +0100") References: <1246385157.8362.127.camel@localhost.localdomain> <1246431779.3872.18.camel@dhcp-lab-219.englab.brq.redhat.com> <1246444235.598.23.camel@blaa> <1246445416.5846.31.camel@dhcp-lab-219.englab.brq.redhat.com> <1246446548.598.43.camel@blaa> Message-ID: <87fxdgxeer.fsf@meyering.net> Mark McLoughlin wrote: > On Wed, 2009-07-01 at 12:50 +0200, Ond?ej Va??k wrote: >> Mark McLoughlin wrote: >> > On Wed, 2009-07-01 at 09:02 +0200, Ond?ej Va??k wrote: >> > > Owen Taylor wrote: >> > > > I was rather surprised to see: >> > > > >> > > > https://admin.fedoraproject.org/updates/F9/FEDORA-2009-6661 >> > > > https://admin.fedoraproject.org/updates/F10/FEDORA-2009-6076 >> > > > https://admin.fedoraproject.org/updates/F11/FEDORA-2009-6370 >> > > > >> > > > Where the automake was upgraded to 1.11 for F9, F10, and F11. >> > > >> > > Upgrade on F-11 (and F-10) was requested because there are some projects >> > > (like gnulib/coreutils) which really need automake 1.11 for build in >> > > latest stable versions. >> > >> > Is there a bug report with details of this gnulib/coreutils request? >> >> Not really, it was just direct irl/irc/mail communication with >> automake/autoconf fedora maintainers&comaintainers. First request was >> only about 1.10b in rawhide (after f-12 split) - as I needed at least >> 1.10b to build coreutils-7.4 there (otherwise only with an ugly hack). > > Okay, but what exactly are we talking about here? What does gnulib or > coreutils need that 1.10 doesn't have? Hi Mark, I think it's great that automake-1.11 made it into F11 and F10. Even for F9, it's seems worthwhile. The features in automake-1.11 that I've found worthwhile (in addition to 3 years worth of improved robustness, portability and performance, fewer bugs, etc.) are enabled by these two lines from coreutils' configure.ac: AM_INIT_AUTOMAKE([1.11 dist-xz color-tests parallel-tests]) AM_SILENT_RULES([yes]) The silent-rules option makes it so build output by default no longer includes many compile/link/etc command invocations. Instead, you get very brief lines like these: ... CC tee.o CC test.o CC timeout.o CC true.o CC truncate.o CC tty.o CC whoami.o CC yes.o CC base64.o CC setuidgid.o CC getlimits.o CC libstdbuf_so-libstdbuf.o CC su.o AR libver.a CCLD chroot CCLD uname CCLD hostid CCLD nice CCLD who CCLD users CCLD pinky CCLD uptime CCLD stty ... Run "make V=1" if you want the verbose output you're used to. Note that I prefer the behavior shown above. Remove the ([yes]) if you (as package maintainer) want to provide the option, but with V=1 as default. That may look trivial, but the reduced clutter makes surprising output stand out more than it used to. This has helped me find at least two minor problems in coreutils and gnulib already. parallel-tests is well worth it any time I run "make check" on a multi-core system. On a quad-core system, with many, fine-grained tests, it cuts test run time by 70% or more. Of course, it helps to start the longest-running tests early enough so that they have a better chance to complete before other cores go idle. >From automake's NEWS: this was an important improvement for projects that install many files into the same directory, especially on systems with SELinux enabled (in some extreme cases, this change resulted in a 30-X(!) speed-up): - The targets `install' and `uninstall' are more efficient now, in that for example multiple files from one Automake variable such as `bin_SCRIPTS' are copied in one `install' (or `libtool --mode=install') invocation if they do not have to be renamed. color-tests is no big deal. It gives you e.g., green "PASS" and red "FAIL" highlighting in the output of "make check". I like dist-xz because the compressed tarballs are so much smaller than bzip2-compressed ones. xz is the successor to LZMA (http://tukaani.org/xz/). I install it from source. FYI, I do not make changes like these lightly. I follow automake development very closely and even contribute once in a while. The standard of quality there is very high. When I discovered that some tools could compress tarballs 10-35% better than bzip2, I poked and prodded the contenders. Lzma-utils stood out for its quality of implementation and it adherence to the de-facto gzip/bzip2 standards. Due to a significant format change, the name has changed too, and now the tool is called xz. There are many more improvements and bug fixes in 1.11 that were not in any previous version. See the NEWS file for the complete list: http://git.sv.gnu.org/cgit/automake.git/plain/NEWS > A rebase of an important package in three stable releases, which is > expected to break rebuilds of some packages, should surely have more > justification than an empty update description, no associated bugzilla > and claims that Jim Meyering needs some unspecified new features. I've been lamenting the 3-year-old version of automake in Fedora for years, and worse, having to jump through hoops for projects like qpid, parted, corosync, openais, etc. because I refuse to waste time working around bugs/misfeatures that were fixed in upstream automake years before. I've been helping people build from source and install their own versions of these tools for use on Fedora-based systems. This script was essential before the upgrade to automake-1.11: http://et.redhat.com/~meyering/autotools-install Distributing such an old version of automake (with no newer alternative) was doing a disservice to Fedora developers everywhere. That old version of automake would inject its older, inferior infrastructure into every Makefile.in and aclocal.m4, and from there into every package's configure script. People using stock Fedora were thus stuck with some 3-year-old bugs, and could not take advantage of the numerous improvements made during that period. Fedora is better than that. Thanks again to the Fedora automake maintainers. Jim From jreiser at BitWagon.com Wed Jul 1 22:21:20 2009 From: jreiser at BitWagon.com (John Reiser) Date: Wed, 01 Jul 2009 15:21:20 -0700 Subject: F10 anaconda incompatible with current F10 yum - WTF In-Reply-To: References: Message-ID: <4A4BE160.8040404@BitWagon.com> Xavier Toth wrote: > So I do a yum update, pickup a yum that isn't compatible with the > original anaconda and then can no longer make installable DVD's. Depending on your exact requirements, the re-spins by the Fedora Unity project may be able to help you: http://spins.fedoraunity.org/spins The most recent one for Fedora 10 was on April 14. -- From kevin.kofler at chello.at Wed Jul 1 22:38:12 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 02 Jul 2009 00:38:12 +0200 Subject: an update to automake-1.11? References: <1246385157.8362.127.camel@localhost.localdomain> <1246431779.3872.18.camel@dhcp-lab-219.englab.brq.redhat.com> <1246444235.598.23.camel@blaa> <1246445416.5846.31.camel@dhcp-lab-219.englab.brq.redhat.com> <1246446548.598.43.camel@blaa> <87fxdgxeer.fsf@meyering.net> Message-ID: Jim Meyering wrote: > The silent-rules option makes it so build output by default > no longer includes many compile/link/etc command invocations. > Instead, you get very brief lines like these: > > ... > CC tee.o [etc.] FWIW, that's what CMake does by default. (CMake's implementation is better though: it also gives the progress percentage and uses color-coding so you can immediately recognize the different kinds of operations and so the operations are visually separated from the stderr output.) It is frowned upon in Fedora because it doesn't allow you to easily check that RPM_OPT_FLAGS are being used and so our %cmake and %cmake_kde4 macros include: -DCMAKE_VERBOSE_MAKEFILE=ON which overrides this behavior and shows the full command lines by default. (It's also possible for CMake-using packages to do this at make time with make VERBOSE=ON which is what was the previous recommendation.) > Run "make V=1" if you want the verbose output you're used to. This will be REQUIRED in Fedora for packages using this feature (unless this can somehow be set at configure time, in which case our %configure macro could do it similarly to how our %cmake and %cmake_kde4 macros do). By the way, it's pretty sad that automake had to reinvent the wheel instead of using the established VERBOSE=ON syntax. > That may look trivial, but the reduced clutter makes surprising output > stand out more than it used to. I agree (and I like how this has been the default in CMake since forever), but we were told that this is no good for Fedora because we should have the full command lines in build.log so we can check for the optflags. Kevin Kofler From kevin.kofler at chello.at Wed Jul 1 22:47:28 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 02 Jul 2009 00:47:28 +0200 Subject: F10 anaconda incompatible with current F10 yum - WTF References: Message-ID: Xavier Toth wrote: > So I do a yum update, pickup a yum that isn't compatible with the > original anaconda and then can no longer make installable DVD's. This > is busted! If anaconda is dependent on a specific version of yum then > it's Requires need to be equal to that version and not greater than or > equal to. That would just replace the runtime error with a broken dependency. The only solution is to release an anaconda update matching the yum update. We really need anaconda updates for the benefit of respins! Anaconda not working with the current update yum is a serious regression and we need a matching Anaconda update ASAP. Kevin Kofler From xiashing at gmail.com Thu Jul 2 01:26:15 2009 From: xiashing at gmail.com (Xia Shing Zee) Date: Thu, 2 Jul 2009 11:26:15 +1000 Subject: New maintainer needed: dumpasn1, freedroid, http_ping, id3v2, pscan, zzuf In-Reply-To: References: <200907012321.43913.ville.skytta@iki.fi> <4A4BC697.9020305@jcomserv.net> Message-ID: <954b158e0907011826o5d9013aag85f537370cac2999@mail.gmail.com> I'm a new package maintainer, but I'll try dumpasn1 and id3v2 Regards, Xia Shing On Thu, Jul 2, 2009 at 7:09 AM, Adam Miller wrote: > I would like to take http_ping and pscan. > > -Adam > > > -- > http://maxamillion.googlepages.com > --------------------------------------------------------- > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments > > -- > 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 markmc at redhat.com Thu Jul 2 09:10:07 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 02 Jul 2009 10:10:07 +0100 Subject: an update to automake-1.11? In-Reply-To: <87fxdgxeer.fsf@meyering.net> References: <1246385157.8362.127.camel@localhost.localdomain> <1246431779.3872.18.camel@dhcp-lab-219.englab.brq.redhat.com> <1246444235.598.23.camel@blaa> <1246445416.5846.31.camel@dhcp-lab-219.englab.brq.redhat.com> <1246446548.598.43.camel@blaa> <87fxdgxeer.fsf@meyering.net> Message-ID: <1246525807.3006.39.camel@blaa> Hi Jim, On Wed, 2009-07-01 at 23:49 +0200, Jim Meyering wrote: > Mark McLoughlin wrote: > > On Wed, 2009-07-01 at 12:50 +0200, Ond?ej Va??k wrote: > >> Mark McLoughlin wrote: > >> > On Wed, 2009-07-01 at 09:02 +0200, Ond?ej Va??k wrote: > >> > > Owen Taylor wrote: > >> > > > I was rather surprised to see: > >> > > > > >> > > > https://admin.fedoraproject.org/updates/F9/FEDORA-2009-6661 > >> > > > https://admin.fedoraproject.org/updates/F10/FEDORA-2009-6076 > >> > > > https://admin.fedoraproject.org/updates/F11/FEDORA-2009-6370 > >> > > > > >> > > > Where the automake was upgraded to 1.11 for F9, F10, and F11. > >> > > > >> > > Upgrade on F-11 (and F-10) was requested because there are some projects > >> > > (like gnulib/coreutils) which really need automake 1.11 for build in > >> > > latest stable versions. > >> > > >> > Is there a bug report with details of this gnulib/coreutils request? > >> > >> Not really, it was just direct irl/irc/mail communication with > >> automake/autoconf fedora maintainers&comaintainers. First request was > >> only about 1.10b in rawhide (after f-12 split) - as I needed at least > >> 1.10b to build coreutils-7.4 there (otherwise only with an ugly hack). > > > > Okay, but what exactly are we talking about here? What does gnulib or > > coreutils need that 1.10 doesn't have? > > Hi Mark, > > I think it's great that automake-1.11 made it into F11 and F10. > Even for F9, it's seems worthwhile. > > The features in automake-1.11 that I've found worthwhile > (in addition to 3 years worth of improved robustness, > portability and performance, fewer bugs, etc.) > are enabled by these two lines from coreutils' configure.ac: > > AM_INIT_AUTOMAKE([1.11 dist-xz color-tests parallel-tests]) > AM_SILENT_RULES([yes]) Thanks for the details, that's exactly the kind of information I was trying to squeeze out of this discussion :-) IMHO, if this had been in a bug report and referenced in the update description, this discussion would purely be about whether it makes sense to do this in F-9 (and F-10, maybe). The issue here is weighing up the benefit of a 1.11 update to developers using F-9 and F-10 versus the risk of breaking existing working builds. It sounds automake has improved its level of compatibility between releases, so the risk is relatively low. Even still, I'd be inclined to say that developers who want 0.11 should install it themselves or update to F-11. > > A rebase of an important package in three stable releases, which is > > expected to break rebuilds of some packages, should surely have more > > justification than an empty update description, no associated bugzilla > > and claims that Jim Meyering needs some unspecified new features. > > I've been lamenting the 3-year-old version of automake in Fedora for > years, This "3 year old" issue is upstream's fault for taking that long to ship a new release. 0.11 is 6 weeks old, so Fedora hadn't much choice in the matter. The timing vis-a-vis F-11 looks like it was unfortunate. Could we have included a 0.10b in F-11 GA and update to 0.11 in an update? That would have given the new code more Fedora testing. Thanks again, Mark. From markmc at redhat.com Thu Jul 2 09:18:45 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 02 Jul 2009 10:18:45 +0100 Subject: an update to automake-1.11? In-Reply-To: References: <1246385157.8362.127.camel@localhost.localdomain> <1246431779.3872.18.camel@dhcp-lab-219.englab.brq.redhat.com> <1246444235.598.23.camel@blaa> <1246445416.5846.31.camel@dhcp-lab-219.englab.brq.redhat.com> <1246446548.598.43.camel@blaa> <87fxdgxeer.fsf@meyering.net> Message-ID: <1246526325.3006.42.camel@blaa> On Thu, 2009-07-02 at 00:38 +0200, Kevin Kofler wrote: > > Run "make V=1" if you want the verbose output you're used to. > > This will be REQUIRED in Fedora for packages using this feature Yes, it's a good idea for packages to do this, as it makes the koji logs much more useful. We do this for qemu builds, for example. (The syntax was copied from the kernel AFAIK) Cheers, Mark. From jim at meyering.net Thu Jul 2 10:14:06 2009 From: jim at meyering.net (Jim Meyering) Date: Thu, 02 Jul 2009 12:14:06 +0200 Subject: an update to automake-1.11? In-Reply-To: <1246525807.3006.39.camel@blaa> (Mark McLoughlin's message of "Thu, 02 Jul 2009 10:10:07 +0100") References: <1246385157.8362.127.camel@localhost.localdomain> <1246431779.3872.18.camel@dhcp-lab-219.englab.brq.redhat.com> <1246444235.598.23.camel@blaa> <1246445416.5846.31.camel@dhcp-lab-219.englab.brq.redhat.com> <1246446548.598.43.camel@blaa> <87fxdgxeer.fsf@meyering.net> <1246525807.3006.39.camel@blaa> Message-ID: <87y6r7v1ch.fsf@meyering.net> Mark McLoughlin wrote: ... > The issue here is weighing up the benefit of a 1.11 update to developers > using F-9 and F-10 versus the risk of breaking existing working builds. > It sounds automake has improved its level of compatibility between > releases, so the risk is relatively low. Even still, I'd be inclined to > say that developers who want 0.11 should install it themselves or update > to F-11. That would make it inconvenient to use the new features in any project that does development (runs automake) on the still-very-useful F10. It is precisely this barrier-to-adoption that we want to overcome. These days, there is no excuse not to provide the very latest stable releases of automake and autoconf on F10 and F11. Yes, they really are that stable and robust. Besides, these are developer-only tools. They are not like libraries. They typically aren't even installed on end-user systems. The only potential penalty is a failure (not to build from source, but) to rebuild after rerunning autoconf. Pretty minor, considering all of the good reasons to upgrade, for both the developer and the eventual user. I try to accommodate progressiveness, when the benefit appears to outweigh the risk. Here, I see little risk. So far, I know of no incompatibility that would require any manual work. But even if there are a few corner cases, anyone who cannot find the time for whatever small changes are needed to update to automake-1.11 can install an older version and use that. By the way, has anyone reported a problem that can be attributed to this new version of automake? (we won't count the one involving gnome-common-2.26 ;-) It's like replacement functions in gnulib: the target systems with working functions pays no penalty at all, but a system with a missing or broken function has to endure the cost of the replacement or wrapper. From gdt at gdt.id.au Thu Jul 2 10:16:35 2009 From: gdt at gdt.id.au (Glen Turner) Date: Thu, 02 Jul 2009 19:46:35 +0930 Subject: FESCo meeting summary for 2009-06-26 In-Reply-To: <20090629160913.GD32653@nostromo.devel.redhat.com> References: <200906291314.19557.mhlavink@redhat.com> <571dcba60906290420v4720785gac13b28fab0f8d3e@mail.gmail.com> <20090629160913.GD32653@nostromo.devel.redhat.com> Message-ID: <4A4C8903.3000302@gdt.id.au> On 30/06/09 01:39, Bill Nottingham wrote: > That's a really crappy place for that message, though. What's the user > supposed to do there... reboot and then go download another 700MB - 4GB? Yes it's a crappy place. I knew that when I suggested it. I just couldn't think of a Javascript hack which would cough up the CPU features even when running under a 32b OS like Windows Xp. Suggestions welcomed. -- Glen Turner From pbrobinson at gmail.com Thu Jul 2 10:29:40 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 2 Jul 2009 11:29:40 +0100 Subject: ppc64 assistance Message-ID: <5256d0b0907020329k8ed1219ldf26d4443e4858b@mail.gmail.com> Hi All, I've having some issues with a PPC64 build and was wondering if someone a bit more ppc savy could have a poke. It builds fine on x86 and ppc32. git head also has the same issue as the current stable release so unfortunately that doesn't help much. PPC64 build http://koji.fedoraproject.org/koji/taskinfo?taskID=1449113 PPC32 build http://koji.fedoraproject.org/koji/taskinfo?taskID=1449147 Cheers, Peter From walters at verbum.org Thu Jul 2 10:49:10 2009 From: walters at verbum.org (Colin Walters) Date: Thu, 2 Jul 2009 06:49:10 -0400 Subject: ppc64 assistance In-Reply-To: <5256d0b0907020329k8ed1219ldf26d4443e4858b@mail.gmail.com> References: <5256d0b0907020329k8ed1219ldf26d4443e4858b@mail.gmail.com> Message-ID: On Thu, Jul 2, 2009 at 6:29 AM, Peter Robinson wrote: > Hi All, > > I've having some issues with a PPC64 build and was wondering if > someone a bit more ppc savy could have a poke. A backtrace would be really useful here (remember to build with -ggdb -O0 for extra usefulness). The typelib code is fairly heavy on lowlevel C bit-twiddling so it's not unlikely this is an upstream issue. From pbrobinson at gmail.com Thu Jul 2 10:51:46 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 2 Jul 2009 11:51:46 +0100 Subject: ppc64 assistance In-Reply-To: References: <5256d0b0907020329k8ed1219ldf26d4443e4858b@mail.gmail.com> Message-ID: <5256d0b0907020351k2256c987pe3b531ef78281a2d@mail.gmail.com> On Thu, Jul 2, 2009 at 11:49 AM, Colin Walters wrote: > On Thu, Jul 2, 2009 at 6:29 AM, Peter Robinson wrote: >> Hi All, >> >> I've having some issues with a PPC64 build and was wondering if >> someone a bit more ppc savy could have a poke. > > A backtrace would be really useful here (remember to build with -ggdb > -O0 for extra usefulness). > > The typelib code is fairly heavy on lowlevel C bit-twiddling so it's > not unlikely this is an upstream issue. OK, will do. I'm seeing the same issues on git master as well. Peter From harald at redhat.com Thu Jul 2 10:59:06 2009 From: harald at redhat.com (Harald Hoyer) Date: Thu, 02 Jul 2009 12:59:06 +0200 Subject: [ANNOUNCEMENT] dracut-0.3 Message-ID: <4A4C92FA.50501@redhat.com> Here it is, dracut-0.3! Featuring booting from all kind of block devices, NFS, iSCSI and NBD. Dracut is a new initramfs infrastructure. It should replace nash/mkinitrd. Dracut is a feauture for Fedora 12 http://fedoraproject.org/wiki/Features/Dracut How to get started, if you want to test. # yum install dracut-0.3 To generate a initramfs image, run: # dracut to overwrite an existing image: # dracut -f Try to boot from that image by modifying /etc/grub.conf. Be sure to have a fallback entry. If you want to boot from network have a look at the manpage. Basically everything can be specified on the kernel command line. Bug reports can be send directly to me (harald at redhat.com) until dracut appears in the bugzilla component list. Further information about dracut: http://sourceforge.net/apps/trac/dracut/wiki From dsd at laptop.org Thu Jul 2 11:09:32 2009 From: dsd at laptop.org (Daniel Drake) Date: Thu, 02 Jul 2009 12:09:32 +0100 Subject: [ANNOUNCEMENT] dracut-0.3 In-Reply-To: <4A4C92FA.50501@redhat.com> References: <4A4C92FA.50501@redhat.com> Message-ID: <1246532972.2168.4.camel@polyethylene> Hi Harald, On Thu, 2009-07-02 at 12:59 +0200, Harald Hoyer wrote: > Here it is, dracut-0.3! Thanks for your efforts, this is excellent. We've started using it for OLPC's F11 spin, including our own modules to implement OLPC features. So much nicer than what we had before! However, the spec file already pulls in a lot of dependencies, things like device-mapper and cryptsetup which we won't need. Especially for XO-1 we need to work to keep images small (1GB hard disk). Is there any chance that this could be split up, and the more exotic dependencies moved into subpackages? Cheers, Daniel From harald at redhat.com Thu Jul 2 11:14:21 2009 From: harald at redhat.com (Harald Hoyer) Date: Thu, 02 Jul 2009 13:14:21 +0200 Subject: [ANNOUNCEMENT] dracut-0.3 In-Reply-To: <1246532972.2168.4.camel@polyethylene> References: <4A4C92FA.50501@redhat.com> <1246532972.2168.4.camel@polyethylene> Message-ID: <4A4C968D.3040003@redhat.com> On 07/02/2009 01:09 PM, Daniel Drake wrote: > Hi Harald, > > On Thu, 2009-07-02 at 12:59 +0200, Harald Hoyer wrote: >> Here it is, dracut-0.3! > > Thanks for your efforts, this is excellent. > > We've started using it for OLPC's F11 spin, including our own modules to > implement OLPC features. So much nicer than what we had before! > > However, the spec file already pulls in a lot of dependencies, things > like device-mapper and cryptsetup which we won't need. Especially for > XO-1 we need to work to keep images small (1GB hard disk). > > Is there any chance that this could be split up, and the more exotic > dependencies moved into subpackages? > > Cheers, > Daniel > > The idea is to pregenerate a generic initrd and package it in an rpm and deliver it together with the kernel. There should be no need to generate the initrd on an X0-1 itsself. Read the dracut manpage. You could explicitly set the modules you want to use and omit those, you know you will never use. From rc040203 at freenet.de Thu Jul 2 11:14:20 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 02 Jul 2009 13:14:20 +0200 Subject: an update to automake-1.11? In-Reply-To: <87y6r7v1ch.fsf@meyering.net> References: <1246385157.8362.127.camel@localhost.localdomain> <1246431779.3872.18.camel@dhcp-lab-219.englab.brq.redhat.com> <1246444235.598.23.camel@blaa> <1246445416.5846.31.camel@dhcp-lab-219.englab.brq.redhat.com> <1246446548.598.43.camel@blaa> <87fxdgxeer.fsf@meyering.net> <1246525807.3006.39.camel@blaa> <87y6r7v1ch.fsf@meyering.net> Message-ID: <4A4C968C.6070605@freenet.de> Jim Meyering wrote: > I try to accommodate progressiveness, when the benefit appears to > outweigh the risk. ACK. The risk of an automake-1.10->automake-1.11 upgrade on Fedora is close to zero and outweigh the effects of bug fixes having gone into automake-1.11. > So far, I know of no incompatibility > that would require any manual work. I am not aware of any, either. The latest major breakage with autoconf/automake, I encountered was introduction of AC_ENABLE/DISABLE_OPTION_CHECKING, which causes irritating warnings when not being treated manually. However this was introduced by autoconf, not automake, and is more a nuissance but a regression. > But even if there are a few corner > cases, anyone who cannot find the time for whatever small changes are > needed to update to automake-1.11 can install an older version and > use that. The fact "make V=..." uses an unprefixed/non-namespace safe environment variable is a candidate to cause problems. Admitted, the likelihood of older packages tripping over this is close to null. Ralf From dsd at laptop.org Thu Jul 2 11:25:52 2009 From: dsd at laptop.org (Daniel Drake) Date: Thu, 02 Jul 2009 12:25:52 +0100 Subject: [ANNOUNCEMENT] dracut-0.3 In-Reply-To: <4A4C968D.3040003@redhat.com> References: <4A4C92FA.50501@redhat.com> <1246532972.2168.4.camel@polyethylene> <4A4C968D.3040003@redhat.com> Message-ID: <1246533952.2168.5.camel@polyethylene> On Thu, 2009-07-02 at 13:14 +0200, Harald Hoyer wrote: > The idea is to pregenerate a generic initrd and package it in an rpm and deliver > it together with the kernel. There should be no need to generate the initrd on > an X0-1 itsself. Is it going to work like this in standard Fedora too? Or will dracut be invoked like mkinitrd is today, that is at RPM-install time on the target system? Daniel From rawhide at fedoraproject.org Thu Jul 2 11:32:21 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Thu, 2 Jul 2009 11:32:21 +0000 Subject: rawhide report: 20090702 changes Message-ID: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> Compose started at Thu Jul 2 06:15:05 UTC 2009 New package Mayavi Scientific data 3-dimensional visualizer New package dracut Initramfs generator using udev New package efte A lightweight, extendable, folding text editor for X11 New package hunspell-et Estonian hunspell dictionaries New package ldd-pdf Linux Device Drivers, Third Edition Book in PDF format New package perl-Hash-Merge Merges arbitrary deep hashes into a single hash New package perl-String-RewritePrefix Rewrite strings based on a set of known prefixes New package perl-namespace-autoclean Keep imports out of your namespace New package php-pear-Auth_HTTP Class providing HTTP authentication methods New package php-pecl-parsekit PHP Opcode Analyser New package rubygem-rake-compiler Rake-based Ruby C Extension task generator New package skanlite Lightweight scanning program New package wordpress-mu-plugin-defaults Wordpress MU new blog defaults plugin for WordPress MU Updated Packages: AcetoneISO2-2.0.3.1-1.fc12 -------------------------- * Wed Jul 01 2009 Tom "spot" Callaway - 2.0.3.1-1 - update to 2.0.3.1 GraphicsMagick-1.3.5-1.fc12 --------------------------- Miro-2.0.5-1.fc12 ----------------- * Wed Jul 01 2009 Alex Lancaster - 2.0.5-1 - Update to latest upstream (2.0.5), fixes #507642 amtu-1.0.7-1.fc12 ----------------- * Wed Jul 01 2009 Steve Grubb 1.0.7-1 - new upstream version argyllcms-1.0.4-1.fc12 ---------------------- * Tue Jun 30 2009 Jon Ciesla - 1.0.4-1 - New upstream, incorporating ICC fixes. audex-0.71-0.3.beta5.fc12 ------------------------- * Wed Jul 01 2009 Roland Wolters 0.71-0.3.beta5 - update to upstream version beta5 awesfx-0.5.1c-2.fc12 -------------------- * Thu May 28 2009 Guido Grazioli 0.5.1c-2 - fixed %install - fixed license - fixed files ownership * Thu Mar 12 2009 Guido Grazioli 0.5.1c-1 - initial packaging barry-0.15-0.7.20090630git.fc12 ------------------------------- * Tue Jun 30 2009 Christopher D. Stover 0.15-0.7.20090630git - version/git bump - create separate doc package; BZ#508462 - fixed opensync build issue; BZ#506609 - incorporated hal changes to fix permission issues; BZ#478851 - add icon for BarryBackup; BZ#483151 cave9-0.3-8.fc12 ---------------- * Wed Jun 24 2009 Victor Bogado 0.3-8 - removed the redundant ownership of the fontdir. - lowered the priority - Updated the font configuration to better match the suggested template. * Tue Jun 23 2009 Victor Bogado 0.3-7 - following the tips from Nicolas Mailhot on bug#477371 * Mon Jun 22 2009 Victor Bogado 0.3-6 - adapted the font subpackge to the new template on Fedora 11 cluster-3.0.0-19.rc4.fc12 ------------------------- * Thu Jul 02 2009 Fabio M. Di Nitto - 3.0.0-19.rc4 - New upstream release - spec file updates: * cman subpackage: avoid unnecessary calls to ldconfig * rgmanager subpackage: drop unrequired Requires: that belong to ras * BuildRequires and Requires corosync/openais 1.0.0.rc1 control-center-2.27.3-1.fc12 ---------------------------- * Tue Jun 30 2009 Matthias Clasen - 2.27.3-1 - Update to 2.27.3 corosync-0.100-1.fc12 --------------------- * Thu Jul 02 2009 Fabio M. Di Nitto - 0.100-1 - New upstream release ctdb-1.0.86-1.fc12 ------------------ * Wed Jul 01 2009 Sumit Bose - 1.0.86-1 - Update to ctdb version 1.0.86 * Tue Jun 30 2009 : Version 1.0.86 - Do not access the reclock at all if VerifyRecoveryLock is zero, not even try to probe it. - Allow setting the reclock file as "", which means that no reclock file at all should be used. - Document that a reclock file is no longer required, but that it is dangerous. - Add a control that can be used to set/clear/change the reclock file in the daemon during runtime. - Update the recovery daemon to poll whether a reclock file should be sued and if so which file at runtime in each monitoring cycle. - Automatically disable VerifyRecoveryLock everytime a user changes the location of the reclock file. - do not allow the VerifyRecoveryLock to be set using ctdb setvar if there is no recovery lock file specified. - Add two commands "ctdb getreclock" and "ctdb setreclock" to modify the reclock file. * Tue Jun 23 2009 : Version 1.0.85 - From William Jojo : Dont use getopt on AIX - Make it possible to use "ctdb listnodes" also when the daemon is not running - Provide machinereadable output to "ctdb listnodes" - Dont list DELETED nodes in the ctdb listnodes output - Try to avoid causing a recovery for the average case when adding/deleting/moving an ip - When banning a node, drop the IPs on that node only and not all nodes. - Add tests for NFS and CIFS tickles - Rename 99.routing to 11.routing so it executes before NFS and LVS scripts - Increase the default timeout before we deem an unresponsive recovery daemon hung and shutdown - Reduce the reclock timout to 5 seconds - Spawn a child process in the recovery daemon ot check the reclock file to avoid blocking the process if the underlying filesystem is unresponsive - fix for filedescriptor leak when a child process timesout - Dont log errors if waitpid() returns -1 - Onnode updates by Martins - Test and initscript cleanups from Martin S * Fri Jun 05 2009 Sumit Bose - 1.0.84-1 - Update to ctdb version 1.0.84 * Tue Jun 02 2009 : Version 1.0.83 - Document how to remove a ndoe from a running cluster. - Hide all deleted nodes from ctdb output. - Lower the loglevel on some eventscript related items - Dont queue packets to deleted nodes - When building initial vnnmap, ignode any nonexisting nodes - Add a new nodestate : DELETED that is used when deleting a node from an existing cluster. - dont remove the ctdb socket when shutting down. This prevents a race in the initscripts when restarting ctdb quickly after stopping it. - TDB nesting reworked. - Remove obsolete ipmux - From Flavio Carmo Junior: Add eventscript and documentation for ClamAV antivirus engine - From Sumit Bose: fix the regex in the test to handle the new ctdb statistics output that was recently added. - change the socket type we use for grauitious arps from the obsolete AF_INET/SOCK_PACKET to instead use PF_PACKET/SOCK_RAW. - Check return codes for some functions, from Sumit Bose, based on codereview by Jim Meyering. - Sumit Bose: Remove structure memeber node_list_file that is no longer used. - Sumit Bose: fix configure warning for netfilter.h - Updates to the webpages by Volker. - Remove error messages about missing /var/log/log.ctdb file from ctdb_diagnostics.sh from christian Ambach - Additional error logs if hte eventscript switching from dameon to client mode fails. - track how long it takes for ctdbd and the recovery daemon to perform the rec-lock fcntl() lock attemt and show this in the ctdb statistics output. * Tue Jun 02 2009 : Version 1.0.84 - Fix a bug in onnode that could not handle dead nodes cups-1.4-0.rc1.7.fc12 --------------------- * Wed Jul 01 2009 Tim Waugh 1:1.4-0.rc1.6 - Fixed lpadmin for remote 1.3.x servers (bug #506977, STR #3231). * Wed Jul 01 2009 Tim Waugh 1:1.4-0.rc1.7 - Fixed template problem preventing current printer option defaults from being shown in the web interface (bug #506794, STR #3244). * Tue Jun 23 2009 Tim Waugh 1:1.4-0.rc1.5 - Added more debugging output when constructing filter chain. darcs-2.2.1-3.fc12 ------------------ * Thu Jul 02 2009 Jens Petersen - 2.2.1-3 - drop post script since semanage now superfluous - drop the unused alphatag for now - simplify BRs dvb-apps-1.1.1-16.fc12 ---------------------- * Thu Jul 02 2009 Ville Skytt? - 1.1.1-16 - Update tuning files to 20090702. - Drop no longer needed workaround for #483644. dvdauthor-0.6.14-9.fc12 ----------------------- * Tue Jun 30 2009 Rex Dieter - 0.6.14-9 - rebuild (GraphicsMagick) eclipse-gef-3.5.0-1.fc12 ------------------------ * Wed Jul 01 2009 Mat Booth 3.5.0-1 - Update to 3.5.0 final release (Galileo). - Build the features seperately to allow for a saner %files section. - Use %global instead of %define. eigen2-2.0.52-0.2.20090622.fc12 ------------------------------- * Mon Jun 22 2009 Rex Dieter 2.0.52-0.2.20090622 - switch to upstream-provided snapshot empathy-2.27.3-3.fc12 --------------------- * Thu Jul 02 2009 Matthias Clasen - 2.27.3-3 - Shrink GConf schemas evolution-2.27.3-3.fc12 ----------------------- * Wed Jul 01 2009 Milan Crha - 2.27.3-3.fc12 - Rebuild against newer gcc evolution-data-server-2.27.3-2.fc12 ----------------------------------- * Wed Jul 01 2009 Milan Crha - 2.27.3-2.fc12 - Rebuild against newer gcc evolution-exchange-2.27.3-2.fc12 -------------------------------- * Wed Jul 01 2009 Milan Crha - 2.27.3-2.fc12 - Rebuild against newer gcc fence-agents-3.0.0-13.rc4.fc12 ------------------------------ * Thu Jul 02 2009 Fabio M. Di Nitto - 3.0.0-13.rc4 - New upstream release. - spec file updates: * BuildRequires / Requires: latest corosync and openais * Drop --enable_virt. Now default upstream findutils-4.4.2-1.fc12 ---------------------- * Wed Jul 01 2009 Vitezslav Crhonek - 1:4.4.2-1 - Update to findutils-4.4.2 flickrnet-2.2-1.fc12 -------------------- * Fri Jun 26 2009 Paul Lange - 2.2-1 - Update to upstream release 2.2. gdm-2.26.1-12.fc12 ------------------ * Wed Jul 01 2009 Ray Strode - 1:2.26.1-12 - Drop defunct arch conditional buildrequires * Tue Jun 30 2009 Matthias Clasen - 1:2.26.1-11 - Rebuild against new libxklavier ghc-haskell-src-exts-1.0.1-1.fc12 --------------------------------- * Wed Jul 01 2009 Conrad Meyer - 1.0.1-1 - Version bump. gnome-applets-2.27.3-3.fc12 --------------------------- * Tue Jun 30 2009 Matthias Clasen - 1:2.27.3-3 - Rebuild against new libxklavier gnome-media-2.27.3.1-1.fc12 --------------------------- * Wed Jul 01 2009 Bastien Nocera 2.27.3.1-1 - Update to 2.27.3.1 gnome-screensaver-2.27.0-2.fc12 ------------------------------- * Wed Jul 01 2009 Matthias Clasen 2.27.0-2 - Rebuild against new libxklavier gnome-settings-daemon-2.27.3-2.fc12 ----------------------------------- * Tue Jun 30 2009 Matthias Clasen 2.27.3-2 - Rebuild against new libxklavier gnome-system-monitor-2.27.3-1.fc12 ---------------------------------- * Wed Jul 01 2009 Matthias Clasen - 2.27.3-1 - Update to 2.27.3 gnome-user-share-2.26.0-3.fc12 ------------------------------ * Thu Jul 02 2009 Matthias Clasen - 2.26.0-3 - Rebuild to shrink GConf schemas gnome-utils-2.27.2-2.fc12 ------------------------- * Thu Jul 02 2009 Matthias Clasen - 1:2.27.2-2 - Shrink some more schemas google-gadgets-0.11.0-1.fc12 ---------------------------- * Wed Jul 01 2009 Michel Salim - 0.11.0-1 - Update to 0.11.0 grsync-0.9.1-1.fc12 ------------------- * Wed Jul 01 2009 Sebastian Vahl - 0.9.1-1 - new upstream release gthumb-2.10.11-4.fc12 --------------------- * Thu Jul 02 2009 Matthias Clasen - 2.10.11-4 - Rebuild to shrink GConf schemas gtkhtml3-3.27.3-2.fc12 ---------------------- * Wed Jul 01 2009 Milan Crha - 3.27.3-2.fc12 - Rebuild against newer gcc gupnp-0.12.8-2.fc12 ------------------- * Wed Jul 01 2009 Peter Robinson 0.12.8-2 - Rebuild with new libuuid build req gupnp-tools-0.7.1-4.fc12 ------------------------ hunspell-ca-0.20090630-1.fc12 ----------------------------- * Wed Jul 01 2009 Caolan McNamara - 0.20090630-1 - latest version ibus-table-1.2.0.20090625-2.fc12 -------------------------------- * Wed Jul 01 2009 Caius 'kaio' Chance - 1.2.0.20090625-1.fc12 - Updated source from upstream, which released for IBus 1.2 and so on. * Wed Jul 01 2009 Caius 'kaio' Chance - 1.2.0.20090625-2.fc12 - Rebuilt. kazehakase-0.5.6-13.svn3773_trunk.fc12 -------------------------------------- * Wed Jul 01 2009 Mamoru Tasaka - Rebuild kdebase-workspace-4.2.95-5.fc12 ------------------------------- * Wed Jul 01 2009 Rex Dieter 4.2.95-4 - rebuild (libxklavier) * Wed Jul 01 2009 Michel Salim - 4.2.95-5 - rebuild (google-gadgets) koffice-2.0.1-2.fc12 -------------------- * Tue Jun 30 2009 Rex Dieter - 2:2.0.1-2 - rebuild (GraphicsMagick) lekhonee-0.5-3.fc12 ------------------- * Tue Jun 30 2009 Kushal Das 0.5-1 - New release * Tue Jun 30 2009 Kushal Das 0.5-2 - Fixing requires issue * Tue Jun 30 2009 Kushal Das 0.5-3 - Fixing requires issue libcanberra-0.14-2.fc12 ----------------------- * Thu Jul 02 2009 Lennart Poettering 0.14-1 - New version 0.14 * Thu Jul 02 2009 Lennart Poettering 0.14-2 - Upload the right tarball libftdi-0.16-3.fc12 ------------------- * Wed Jul 01 2009 Lucian Langa - 0.16-3 - added udev rules - addedd c++, python bindings * Tue Jun 30 2009 Lucian Langa - 0.16-2 - fix doxygen conflict (#508498) libgnome-2.26.0-3.fc12 ---------------------- * Thu Jul 02 2009 Matthias Clasen - 2.26.0-3 - Rebuild * Mon Apr 27 2009 Matthias Clasen - 2.26.0-2 - Don't drop schemas translations from po files libtiff-3.8.2-13.fc12 --------------------- * Wed Jul 01 2009 Tom Lane 3.8.2-13 - Fix some more LZW decoding vulnerabilities (CVE-2009-2285) Related: #507465 - Update upstream URL listen-0.6.2-1.fc12 ------------------- * Wed Jul 01 2009 Ha?kel Gu?mar 0.6.2-1 - updated to 0.6.2 - fixed website url - removed the now useless Xvfb hack - Use pywebkitgtk instead of gnome-python2-gtkmozembed for fedora >= 11 - refreshed some bits in spec mercurial-1.3-2.fc12 -------------------- * Wed Jul 01 2009 Neal Becker - 1.3-1 - Update to 1.3 * Wed Jul 01 2009 Neal Becker - 1.3-2 - Re-enable tests since they now pass mingw32-qt-qmake-4.5.2-1.fc12 ----------------------------- * Wed Jul 01 2009 Thomas Sailer - 4.5.2-1 - update to 4.5.2 to match mingw32-qt version mono-nat-1.0.2-1.fc12 --------------------- * Wed Jul 01 2009 Paul Lange - 1.0.2-1 - Update to 1.0.2 mozplugger-1.12.1-2.fc12 ------------------------ * Thu Jul 02 2009 Ville Skytt? - 1.12.1-2 - Add dependency on m4 (#453306). mysqltuner-1.0.0-1.fc12 ----------------------- * Wed Jul 01 2009 Ville Skytt? - 1.0.0-1 - Update to 1.0.0. net-snmp-5.4.2.1-13.fc12 ------------------------ * Wed Jul 01 2009 Jan Safranek 5.4.2.1-12 - make the default configuration less noisy, i.e. do not print "Connection from UDP:" and "Received SNMP packet(s) from UDP:" messages on each connection. (#509055) * Wed Jul 01 2009 Jan Safranek 5.4.2.1-13 - package cleanup, remove unnecessary patches - move local state file from /var/net-snmp/ to /var/lib/net-snmp notification-daemon-0.4.0-3.fc12 -------------------------------- * Thu Jul 02 2009 Matthias Clasen - 0.4.0-3 - Drop libsexy dependency notification-daemon-engine-nodoka-0.1.0-8.fc12 ---------------------------------------------- * Thu Jul 02 2009 Matthias Clasen - 0.1.0-8 - Drop libsexy dep openais-0.100-1.fc12 -------------------- * Thu Jul 02 2009 Fabio M. Di Nitto - 0.100-1 - New upstream release openldap-2.4.16-1.fc12 ---------------------- * Wed Jul 01 2009 Jan Zeleny 2.4.16-1 - rebase of openldap to 2.4.16 - fixed minor issue in spec file (output looking interactive when installing servers) openssl-0.9.8k-6.fc12 --------------------- * Tue Jun 30 2009 Tomas Mraz 0.9.8k-6 - abort if selftests failed and random number generator is polled - mention EVP_aes and EVP_sha2xx routines in the manpages - add README.FIPS - make CA dir absolute path (#445344) - change default length for RSA key generation to 2048 (#484101) pavucontrol-0.9.9-0.test1.fc12 ------------------------------ * Thu Jul 02 2009 Lennart Poettering 0.9.9-1 - Preview of upcoming 0.9.9 perl-Catalyst-Runtime-5.80005-3.fc12 ------------------------------------ * Sun Jun 14 2009 Chris Weyl 5.80005-3 - flesh out to full requires list (from upstream metadata) - auto-update to 5.80005 (by cpan-spec-update 0.01) - added a new req on perl(Text::Balanced) (version 0) - added a new req on perl(HTTP::Response) (version 0) - added a new req on perl(LWP::UserAgent) (version 0) - added a new req on perl(Scalar::Util) (version 0) - added a new req on perl(CGI::Simple::Cookie) (version 0) - added a new req on perl(Class::C3::Adopt::NEXT) (version 0.07) - added a new req on perl(Class::MOP) (version 0.83) - added a new req on perl(Time::HiRes) (version 0) - added a new req on perl(MRO::Compat) (version 0) - added a new req on perl(File::Modified) (version 0) - added a new req on perl(HTTP::Headers) (version 1.64) - added a new req on perl(Sub::Exporter) (version 0) - added a new req on perl(Tree::Simple) (version 1.15) - added a new req on perl(B::Hooks::EndOfScope) (version 0.08) - added a new req on perl(namespace::clean) (version 0) - added a new req on perl(HTML::Entities) (version 0) - added a new req on perl(Moose) (version 0.78) - added a new req on perl(Data::Dump) (version 0) - added a new req on perl(Tree::Simple::Visitor::FindByPath) (version 0) - added a new req on perl(Module::Pluggable) (version 3.01) - added a new req on perl(Text::SimpleTable) (version 0.03) - altered req on perl(HTTP::Request::AsCGI) (0.5 => 0.8) - added a new req on perl(HTTP::Request) (version 0) - added a new req on perl(HTTP::Body) (version 1.04) - added a new req on perl(Path::Class) (version 0.09) - added a new req on perl(MooseX::MethodAttributes::Inheritable) (version 0.12) - added a new req on perl(URI) (version 1.35) - added a new req on perl(Carp) (version 0) php-ezc-Template-1.4-1.fc12 --------------------------- * Wed Jul 01 2009 Guillaume Kulakowski - 1.4-1 - Update to 1.4 php-ezc-Webdav-1.1.1-1.fc12 --------------------------- * Wed Jul 01 2009 Guillaume Kulakowski - 1.1.1-1 - Update to 1.1.1 pokerth-0.7.1-1.fc12 -------------------- * Wed Jul 01 2009 Jussi Lehtola - 0.7.1-1 - Update to upstream 0.7.1. pulseaudio-0.9.16-2.test2.fc12 ------------------------------ * Thu Jul 02 2009 Lennart Poettering 0.9.16-2.test2 - New test release python-kaa-base-0.6.0-2.fc12 ---------------------------- python-nss-0.5-1.fc12 --------------------- * Wed Jul 01 2009 John Dennis - 0.5-1 - restore ssl.nss_init and ssl.nss_shutdown but make them deprecated add __version__ string to nss module rabbitmq-server-1.6.0-1.fc12 ---------------------------- * Wed Jun 17 2009 Matthias Radestock 1.6.0-1 - New upstream release * Tue May 26 2009 Hubert Plociniczak 1.5.5-2 - Include dist macro in the release number resource-agents-3.0.0-11.rc4.fc12 --------------------------------- * Thu Jul 02 2009 Fabio M. Di Nitto - 3.0.0-11.rc4 - New upstream release. rhythmbox-0.12.2.93-1.fc12 -------------------------- * Wed Jul 01 2009 Bastien Nocera 0.12.2.93-1 - Update to 0.12.2.93 roundcubemail-0.2.2-1.fc12 -------------------------- * Wed Jul 01 2009 Jon Ciesla = 0.2.2-1 - New upstream. rtkit-0.3-1.fc12 ---------------- * Thu Jul 02 2009 Lennart Poettering - 0.3-1 - New release rubygem-hoe-2.3.2-1.fc12 ------------------------ * Wed Jul 01 2009 Darryl Pierce - 2.3.2-1 - Release 2.3.2 of Hoe. rygel-0.3-3.fc12 ---------------- * Wed Jul 01 2009 Peter Robinson 0.3-3 - Rebuild with new libuuid build req sdcc-2.9.0-2.fc12 ----------------- * Wed Jul 01 2009 Conrad Meyer - 2.9.0-2 - Fix #454205 by BR'ing gputils and re-adding install_post hack. sed-4.2.1-1.fc12 ---------------- * Mon Jun 29 2009 Jiri Moskovcak - 4.2.1-1 - new version - obsoletes previous patches - added patch to maintain backwards compatibility for scripts using -c/--copy - Resolves: #502934 setroubleshoot-2.2.12-1.fc12 ---------------------------- * Wed Jul 01 2009 Dan Walsh - 2.2.11-1 - Update to upstream 2009-7-01 Thomas Liu - Fixed browser behavior when there are no alerts - Fixed seapplet behavior when there are no alerts - Made delete all button delete alerts on server side and on local side * Wed Jul 01 2009 Dan Walsh - 2.2.12-1 - Fix locate code to use os.lstat soundmodem-0.14-1.fc12 ---------------------- * Wed Jul 01 2009 Lucian Langa - 0.14-1 - new upstream release squid-3.0.STABLE16-2.fc12 ------------------------- * Wed Jul 01 2009 Jiri Skala 3.0.STABLE16-2 - fixed patch parameter of bXXX patches * Mon Jun 29 2009 Henrik Nordstrom 3.0.STABLE16-1 - Upgrade to 3.0.STABLE16 squirrel-2.2.3-1.fc12 --------------------- * Wed Jul 01 2009 Dan Hor?k 2.2.3-1 - update to upstream version 2.2.3 squirrelmail-1.4.19-3.fc12 -------------------------- * Wed Jul 01 2009 Michal Hlavinka - 1.4.19-3 - change default configuration to use only ssl connections * Tue Jun 30 2009 Michal Hlavinka - 1.4.19-2 - use hunspell instead of ispell in squirrelspell plugin (#508631) system-config-kickstart-2.8.0-1.fc12 ------------------------------------ * Wed Jul 01 2009 Chris Lumens - 2.8.0-1 - Allow specifying anything for a network device name, not just ethX (#508089). - Don't traceback when opening files with null bytes (#508092). - Make the OK button on some dialogs insensitive until changes happen (#493887). - Don't traceback if the filename entry is blank (#500409). - Lots more UI style/layout updates (#493842, #493857, rrakus). - Don't traceback if given an invalid language or timezone (#487390). - Update to glade3 (#495754, rrakus). - Add a progress window when saving or previewing files (#493879, rrakus). - Use the standard about/license dialog (rrakus, #493926). - Center dialogs on the parent (rrakus, #493823). usbutils-0.82-3.fc12 -------------------- * Wed Jul 01 2009 Jiri Moskovcak 0.82-2 - minor fix in Makefile.am to properly find usb.ids from hwdata - Resolves: #506974 * Wed Jul 01 2009 Jiri Moskovcak 0.82-3 - added autoconf to fix build in koji vdrift-20090615-1.fc12 ---------------------- * Tue Jun 30 2009 Jon Ciesla - 20090615-1 - Update to 2009-06-15. - Split data into noarch subpackage, BZ 508079. yelp-2.27.2-1.fc12 ------------------ * Mon Jun 29 2009 Matthew Barnes - 2.27.2-1 - Update to 2.27.2 - Bump gnome_doc_utils requirement to 0.17.2. Summary: Added Packages: 13 Removed Packages: 0 Modified Packages: 89 From choeger at cs.tu-berlin.de Thu Jul 2 11:36:27 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Thu, 02 Jul 2009 13:36:27 +0200 Subject: certificate not (yet) active? Message-ID: <1246534587.14509.7.camel@choeger6> Hi, I had to create a new .fedora.cert this morning, because make new-sources told me mine was out of date. So I did but now make build runs into Error: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')] why that? (And I wanted to update offlineimap to 6.1.0 today *sniff*) -------------- 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 harald at redhat.com Thu Jul 2 11:37:49 2009 From: harald at redhat.com (Harald Hoyer) Date: Thu, 02 Jul 2009 13:37:49 +0200 Subject: [ANNOUNCEMENT] dracut-0.3 In-Reply-To: <1246533952.2168.5.camel@polyethylene> References: <4A4C92FA.50501@redhat.com> <1246532972.2168.4.camel@polyethylene> <4A4C968D.3040003@redhat.com> <1246533952.2168.5.camel@polyethylene> Message-ID: <4A4C9C0D.3090608@redhat.com> On 07/02/2009 01:25 PM, Daniel Drake wrote: > On Thu, 2009-07-02 at 13:14 +0200, Harald Hoyer wrote: >> The idea is to pregenerate a generic initrd and package it in an rpm and deliver >> it together with the kernel. There should be no need to generate the initrd on >> an X0-1 itsself. > > Is it going to work like this in standard Fedora too? > Or will dracut be invoked like mkinitrd is today, that is at RPM-install > time on the target system? > > Daniel > > My personal target is to deliver the initrd image with the kernel. For performance issues or special needs one can install dracut and generate his own image, if new kernels are installed. We will see, if can work that way. From opensource at till.name Thu Jul 2 12:02:25 2009 From: opensource at till.name (Till Maas) Date: Thu, 02 Jul 2009 14:02:25 +0200 Subject: certificate not (yet) active? In-Reply-To: <1246534587.14509.7.camel@choeger6> References: <1246534587.14509.7.camel@choeger6> Message-ID: <200907021402.31638.opensource@till.name> On Thu July 2 2009, Christoph H?ger wrote: > I had to create a new .fedora.cert this morning, because make > new-sources told me mine was out of date. > So I did but now make build runs into > > Error: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate > verify failed')] > > why that? (And I wanted to update offlineimap to 6.1.0 today *sniff*) Maybe you need to run fedora-packager-setup from fedora-packager again. If you edited your koji.conf, you may re-add your changes btw. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From john5342 at googlemail.com Thu Jul 2 12:23:14 2009 From: john5342 at googlemail.com (John5342) Date: Thu, 2 Jul 2009 13:23:14 +0100 Subject: [ANNOUNCEMENT] dracut-0.3 In-Reply-To: <4A4C9C0D.3090608@redhat.com> References: <4A4C92FA.50501@redhat.com> <1246532972.2168.4.camel@polyethylene> <4A4C968D.3040003@redhat.com> <1246533952.2168.5.camel@polyethylene> <4A4C9C0D.3090608@redhat.com> Message-ID: <6dc6523c0907020523j153ff112rc2a91d145619034e@mail.gmail.com> 2009/7/2 Harald Hoyer : > On 07/02/2009 01:25 PM, Daniel Drake wrote: >> >> On Thu, 2009-07-02 at 13:14 +0200, Harald Hoyer wrote: >>> >>> The idea is to pregenerate a generic initrd and package it in an rpm and >>> deliver >>> it together with the kernel. There should be no need to generate the >>> initrd on >>> an X0-1 itsself. >> >> Is it going to work like this in standard Fedora too? >> Or will dracut be invoked like mkinitrd is today, that is at RPM-install >> time on the target system? >> >> Daniel >> >> > > My personal target is to deliver the initrd image with the kernel. For > performance issues or special needs one can install dracut and generate his > own image, if new kernels are installed. > > We will see, if can work that way. > Can i just point out that i am probably not the only one to require omitting some modules and adding others to the initrd image. With the current setup i run mkinitrd once when i first install (using rescue disk) and then these altered options are remembered so it creates the correct initrd whenever the kernel is updated. If i understand correctly and the initrd images are pre-generated within an rpm then my mods will be overwritten on each update and i would presumably need to run dracut manually after each kernel update to replace the pregenerated initrd. That would be a major regression and surely cannot be allowed to happen. Please accept my apologies if i got it all wrong. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... From stickster at gmail.com Thu Jul 2 12:26:08 2009 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 2 Jul 2009 08:26:08 -0400 Subject: Raising the bar In-Reply-To: <4A49DEAF.8010403@redhat.com> References: <1246303647.1527.132.camel@localhost.localdomain> <4A49DEAF.8010403@redhat.com> Message-ID: <20090702122608.GE9871@localhost.localdomain> On Tue, Jun 30, 2009 at 10:45:19AM +0100, Andrew Haley wrote: > Matthias Clasen wrote: > > > we'd like to announce the 'Fit and Finish' initiative for Fedora, > > > > http://fedoraproject.org/wiki/Fit_and_Finish > > > > with the goal to improve the user experience of the Fedora desktop. We > > want to identify the small (and sometimes large) roadblocks that make > > everyday computer use harder than it needs to be, and try to fix them. > > In Ubuntu there's a "Help" button on the top menu bar that leads to a > nice help application, yelp. We have that app too, but it doesn't > seem to have the same contents, which are: > > New to Ubuntu? > Adding and Removing Software > Files, Folders and Documents > Customising Your Desktop > Internet > Music, Videos and Photos > Assistive Tools > Keeping Your Computer Safe > Printing, Faxing and Scanning > Advanced Topics > > And under each section there's a clear explanation of what to do. > Maybe we have something equivalent for Fedora, but I can't find it. Perhaps this is something you could raise separately with the Fedora Docs team. I'm just getting back from some travel during which I caught wind of some new documentation standards being produced by the GNOME docs community to make documentation more task-based, with which I agree whole-heartedly. Also, our own Docs team is working on providing an easy way for people to retrieve and install language-specific documentation such as a user guide which would integrate into the desktop menu system. (I'm pretty sure that integration is desktop environment-neutral.) The confluence of those two developments might provide some better docs at the desktop level. -- 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 martin.langhoff at gmail.com Thu Jul 2 12:30:41 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Thu, 2 Jul 2009 14:30:41 +0200 Subject: [ANNOUNCEMENT] dracut-0.3 In-Reply-To: <1246532972.2168.4.camel@polyethylene> References: <4A4C92FA.50501@redhat.com> <1246532972.2168.4.camel@polyethylene> Message-ID: <46a038f90907020530gc16dad7wb79f817b043ade51@mail.gmail.com> On Thu, Jul 2, 2009 at 1:09 PM, Daniel Drake wrote: > Thanks for your efforts, this is excellent. Guess it's time for me to learn a bit about it. > We've started using it for OLPC's F11 spin, including our own modules to > implement OLPC features. So much nicer than what we had before! Looks like it is missing my patches. Any plan to merge them in? :-) cheers, martin -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From drago01 at gmail.com Thu Jul 2 12:33:05 2009 From: drago01 at gmail.com (drago01) Date: Thu, 2 Jul 2009 14:33:05 +0200 Subject: rawhide report: 20090702 changes In-Reply-To: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> Message-ID: On Thu, Jul 2, 2009 at 1:32 PM, Rawhide Report wrote: > Compose started at Thu Jul ?2 06:15:05 UTC 2009 > ... > New package ldd-pdf > ? ? ? ?Linux Device Drivers, Third Edition Book in PDF format We ship books as packages? From martin.langhoff at gmail.com Thu Jul 2 12:41:44 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Thu, 2 Jul 2009 14:41:44 +0200 Subject: Raising the bar In-Reply-To: <1246303647.1527.132.camel@localhost.localdomain> References: <1246303647.1527.132.camel@localhost.localdomain> Message-ID: <46a038f90907020541u1385f58fs22a801e378ca5ed4@mail.gmail.com> On Mon, Jun 29, 2009 at 9:27 PM, Matthias Clasen wrote: > To achieve this, we will hold regular test days, each of which will > focus on use cases in a certain area. A few ideas for test day topics Overall, an excellent idea and plan. We had some very good results with an OLPC test group in Wellington NZ, which started gathering every saturday morning at a trendy cafe to test OS snapshots. They keep the practice going with both OS snapshots for the XO and Sugar-on-a-Stick (LiveUSB) images. Using liveCDs and live USB disks is great as you can upgrade, downgrade and potentially bisect a bug quickly. It also means you can run it on many different bits of HW (assuming you've invited everyone to bring their laptops ;-) ) The event is a social thing as much as a technical thing. Of course, it is a great environment to find and diagnose certain kinds of bugs, just like running Fedora betas on a server helps catch and debug only certain kinds of bugs. But the bugs that you are likely to find and diagnose are exactly those that affect the casual and newcomer desktop user. We did find a few things that work well in terms of nurturing a core group of people joining regularly, and switching from the social chatter to the effective bug-hunting and filing. Let me know if you're interested in more info on this. cheers! martin -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From sundaram at fedoraproject.org Thu Jul 2 12:41:08 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Jul 2009 18:11:08 +0530 Subject: rawhide report: 20090702 changes In-Reply-To: References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> Message-ID: <4A4CAAE4.4090404@fedoraproject.org> On 07/02/2009 06:03 PM, drago01 wrote: > On Thu, Jul 2, 2009 at 1:32 PM, Rawhide Report wrote: >> Compose started at Thu Jul 2 06:15:05 UTC 2009 >> ... >> New package ldd-pdf >> Linux Device Drivers, Third Edition Book in PDF format > > We ship books as packages? Yes and this is not even the first time. Dive Into Python has been in the repo for ages already. Rahul From frankly3d at gmail.com Thu Jul 2 12:45:09 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Thu, 02 Jul 2009 13:45:09 +0100 Subject: rawhide report: 20090702 changes In-Reply-To: <4A4CAAE4.4090404@fedoraproject.org> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> Message-ID: <4A4CABD5.4030104@gmail.com> On 02/07/09 13:41, Rahul Sundaram wrote: > >> We ship books as packages? > > Yes and this is not even the first time. Dive Into Python has been in > the repo for ages already. > > Rahul > Is there a book group? or what search parameter? Tried yum info "Dive Into Python" Error: No matching Packages to list Frank From sundaram at fedoraproject.org Thu Jul 2 12:47:07 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Jul 2009 18:17:07 +0530 Subject: rawhide report: 20090702 changes In-Reply-To: <4A4CABD5.4030104@gmail.com> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <4A4CABD5.4030104@gmail.com> Message-ID: <4A4CAC4B.8070600@fedoraproject.org> On 07/02/2009 06:15 PM, Frank Murphy wrote: > Is there a book group? > or what search parameter? > Tried yum info "Dive Into Python" # yum info diveintopython Since we have more than one book, I guess a new group could be defined as well. If there is consensus on the name, I can add it. Should we just call it "Books" ? Rahul From frankly3d at gmail.com Thu Jul 2 12:50:17 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Thu, 02 Jul 2009 13:50:17 +0100 Subject: rawhide report: 20090702 changes In-Reply-To: <4A4CAC4B.8070600@fedoraproject.org> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <4A4CABD5.4030104@gmail.com> <4A4CAC4B.8070600@fedoraproject.org> Message-ID: <4A4CAD09.5050105@gmail.com> On 02/07/09 13:47, Rahul Sundaram wrote: > On 07/02/2009 06:15 PM, Frank Murphy wrote: > >> Is there a book group? >> or what search parameter? >> Tried yum info "Dive Into Python" > > # yum info diveintopython > > Since we have more than one book, I guess a new group could be defined > as well. If there is consensus on the name, I can add it. Should we just > call it "Books" ? > > Rahul > Books sound ok Frank From pingou at pingoured.fr Thu Jul 2 12:51:18 2009 From: pingou at pingoured.fr (Pierre-Yves) Date: Thu, 02 Jul 2009 14:51:18 +0200 Subject: rawhide report: 20090702 changes In-Reply-To: <4A4CABD5.4030104@gmail.com> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <4A4CABD5.4030104@gmail.com> Message-ID: <1246539078.21687.34.camel@localhost.localdomain> On Thu, 2009-07-02 at 13:45 +0100, Frank Murphy wrote: > On 02/07/09 13:41, Rahul Sundaram wrote: > > > > > >> We ship books as packages? > > > > Yes and this is not even the first time. Dive Into Python has been in > > the repo for ages already. > > > > Rahul > > > > Is there a book group? > or what search parameter? > Tried yum info "Dive Into Python" > > Error: No matching Packages to list $ yum search "dive into python" Loaded plugins: dellsysidplugin2, presto, refresh-packagekit ========================================================================================== Matched: dive into python =========================================================================================== diveintopython.noarch : Dive into Python - a python book diveintopython-html.noarch : Dive into Python - a python book diveintopython-pdf.noarch : Dive into Python - a python book diveintopython-single-html.noarch : Dive into Python - a python book diveintopython-txt.noarch : Dive into Python - a python book Regards, Pierre From thomasj at fedoraproject.org Thu Jul 2 12:52:59 2009 From: thomasj at fedoraproject.org (Thomas Janssen) Date: Thu, 2 Jul 2009 14:52:59 +0200 Subject: rawhide report: 20090702 changes In-Reply-To: <4A4CAC4B.8070600@fedoraproject.org> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <4A4CABD5.4030104@gmail.com> <4A4CAC4B.8070600@fedoraproject.org> Message-ID: 2009/7/2 Rahul Sundaram : > On 07/02/2009 06:15 PM, Frank Murphy wrote: > >> Is there a book group? >> or what search parameter? >> Tried yum info "Dive Into Python" > > # yum info diveintopython > > Since we have more than one book, I guess a new group could be defined > as well. If there is consensus on the name, I can add it. Should we just > call it "Books" ? +1 -- LG Thomas Dubium sapientiae initium From harald at redhat.com Thu Jul 2 13:05:39 2009 From: harald at redhat.com (Harald Hoyer) Date: Thu, 02 Jul 2009 15:05:39 +0200 Subject: [ANNOUNCEMENT] dracut-0.3 In-Reply-To: <6dc6523c0907020523j153ff112rc2a91d145619034e@mail.gmail.com> References: <4A4C92FA.50501@redhat.com> <1246532972.2168.4.camel@polyethylene> <4A4C968D.3040003@redhat.com> <1246533952.2168.5.camel@polyethylene> <4A4C9C0D.3090608@redhat.com> <6dc6523c0907020523j153ff112rc2a91d145619034e@mail.gmail.com> Message-ID: <4A4CB0A3.6010201@redhat.com> On 07/02/2009 02:23 PM, John5342 wrote: > 2009/7/2 Harald Hoyer: >> On 07/02/2009 01:25 PM, Daniel Drake wrote: >>> On Thu, 2009-07-02 at 13:14 +0200, Harald Hoyer wrote: >>>> The idea is to pregenerate a generic initrd and package it in an rpm and >>>> deliver >>>> it together with the kernel. There should be no need to generate the >>>> initrd on >>>> an X0-1 itsself. >>> Is it going to work like this in standard Fedora too? >>> Or will dracut be invoked like mkinitrd is today, that is at RPM-install >>> time on the target system? >>> >>> Daniel >>> >>> >> My personal target is to deliver the initrd image with the kernel. For >> performance issues or special needs one can install dracut and generate his >> own image, if new kernels are installed. >> >> We will see, if can work that way. >> > > Can i just point out that i am probably not the only one to require > omitting some modules and adding others to the initrd image. With the > current setup i run mkinitrd once when i first install (using rescue > disk) and then these altered options are remembered so it creates the > correct initrd whenever the kernel is updated. If i understand > correctly and the initrd images are pre-generated within an rpm then > my mods will be overwritten on each update and i would presumably need > to run dracut manually after each kernel update to replace the > pregenerated initrd. That would be a major regression and surely > cannot be allowed to happen. > Please accept my apologies if i got it all wrong. > As I said, "For performance issues or special needs one can install dracut and generate his own image, if new kernels are installed." .. surely this will be done automatically, if you install dracut and there is /etc/dracut.conf where you can configure additional kernel modules and your needs. From harald at redhat.com Thu Jul 2 13:07:43 2009 From: harald at redhat.com (Harald Hoyer) Date: Thu, 02 Jul 2009 15:07:43 +0200 Subject: [ANNOUNCEMENT] dracut-0.3 In-Reply-To: <4A4C92FA.50501@redhat.com> References: <4A4C92FA.50501@redhat.com> Message-ID: <4A4CB11F.6060608@redhat.com> On 07/02/2009 12:59 PM, Harald Hoyer wrote: > Here it is, dracut-0.3! > > Featuring booting from all kind of block devices, NFS, iSCSI and NBD. > > Dracut is a new initramfs infrastructure. It should replace nash/mkinitrd. > Dracut is a feauture for Fedora 12 > http://fedoraproject.org/wiki/Features/Dracut > > How to get started, if you want to test. > > # yum install dracut-0.3 > > To generate a initramfs image, run: > > # dracut > > to overwrite an existing image: > > # dracut -f > > Try to boot from that image by modifying /etc/grub.conf. Be sure to have > a fallback entry. > > If you want to boot from network have a look at the manpage. > Basically everything can be specified on the kernel command line. > > Bug reports can be send directly to me (harald at redhat.com) until dracut > appears in the bugzilla component list. > > Further information about dracut: > http://sourceforge.net/apps/trac/dracut/wiki > Ok, it seems the debug dracut module wants to be installed automatically, due to a bug. You either have all binaries which are needed by the dracut debug module, or create the images with: # dracut --omit debug From choeger at cs.tu-berlin.de Thu Jul 2 13:09:37 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Thu, 02 Jul 2009 15:09:37 +0200 Subject: certificate not (yet) active? In-Reply-To: <200907021402.31638.opensource@till.name> References: <1246534587.14509.7.camel@choeger6> <200907021402.31638.opensource@till.name> Message-ID: <1246540177.14509.11.camel@choeger6> Am Donnerstag, den 02.07.2009, 14:02 +0200 schrieb Till Maas: > On Thu July 2 2009, Christoph H?ger wrote: > > > I had to create a new .fedora.cert this morning, because make > > new-sources told me mine was out of date. > > So I did but now make build runs into > > > > Error: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate > > verify failed')] > > > > why that? (And I wanted to update offlineimap to 6.1.0 today *sniff*) > > Maybe you need to run fedora-packager-setup from fedora-packager again. If you > edited your koji.conf, you may re-add your changes btw. > Thanks, that worked it out. It isn't the easiest thing to package from two pcs and keep their data in sync. -------------- 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 aph at redhat.com Thu Jul 2 13:18:24 2009 From: aph at redhat.com (Andrew Haley) Date: Thu, 02 Jul 2009 14:18:24 +0100 Subject: Raising the bar In-Reply-To: <20090702122608.GE9871@localhost.localdomain> References: <1246303647.1527.132.camel@localhost.localdomain> <4A49DEAF.8010403@redhat.com> <20090702122608.GE9871@localhost.localdomain> Message-ID: <4A4CB3A0.5080907@redhat.com> Paul W. Frields wrote: > On Tue, Jun 30, 2009 at 10:45:19AM +0100, Andrew Haley wrote: >> In Ubuntu there's a "Help" button on the top menu bar that leads to a >> nice help application, yelp. We have that app too, but it doesn't >> seem to have the same contents, which are: >> >> New to Ubuntu? >> Adding and Removing Software >> Files, Folders and Documents >> Customising Your Desktop >> Internet >> Music, Videos and Photos >> Assistive Tools >> Keeping Your Computer Safe >> Printing, Faxing and Scanning >> Advanced Topics >> >> And under each section there's a clear explanation of what to do. >> Maybe we have something equivalent for Fedora, but I can't find it. > > Perhaps this is something you could raise separately with the Fedora > Docs team. OK, will do. Andrew. From pbrobinson at gmail.com Thu Jul 2 13:20:32 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 2 Jul 2009 14:20:32 +0100 Subject: ppc64 assistance In-Reply-To: References: <5256d0b0907020329k8ed1219ldf26d4443e4858b@mail.gmail.com> Message-ID: <5256d0b0907020620x18420b4ah8574122feae83221@mail.gmail.com> On Thu, Jul 2, 2009 at 11:49 AM, Colin Walters wrote: > On Thu, Jul 2, 2009 at 6:29 AM, Peter Robinson wrote: >> Hi All, >> >> I've having some issues with a PPC64 build and was wondering if >> someone a bit more ppc savy could have a poke. > > A backtrace would be really useful here (remember to build with -ggdb > -O0 for extra usefulness). > > The typelib code is fairly heavy on lowlevel C bit-twiddling so it's > not unlikely this is an upstream issue. Interestingly with -ggdb it builds fine with out without -O0. With -O0 http://koji.fedoraproject.org/koji/taskinfo?taskID=1449368 Without. http://koji.fedoraproject.org/koji/taskinfo?taskID=1449389 Regards, Peter From pbrobinson at gmail.com Thu Jul 2 13:26:45 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 2 Jul 2009 14:26:45 +0100 Subject: [ANNOUNCEMENT] dracut-0.3 In-Reply-To: <4A4C968D.3040003@redhat.com> References: <4A4C92FA.50501@redhat.com> <1246532972.2168.4.camel@polyethylene> <4A4C968D.3040003@redhat.com> Message-ID: <5256d0b0907020626x7cfebacdpfd211d52863e7c28@mail.gmail.com> >> Hi Harald, >> >> On Thu, 2009-07-02 at 12:59 +0200, Harald Hoyer wrote: >>> >>> Here it is, dracut-0.3! >> >> Thanks for your efforts, this is excellent. >> >> We've started using it for OLPC's F11 spin, including our own modules to >> implement OLPC features. So much nicer than what we had before! >> >> However, the spec file already pulls in a lot of dependencies, things >> like device-mapper and cryptsetup which we won't need. Especially for >> XO-1 we need to work to keep images small (1GB hard disk). >> >> Is there any chance that this could be split up, and the more exotic >> dependencies moved into subpackages? >> >> Cheers, >> Daniel >> >> > > The idea is to pregenerate a generic initrd and package it in an rpm and > deliver it together with the kernel. There should be no need to generate the > initrd on an X0-1 itsself. How does this work for changing plymouth spash plugins as I seem to remember these are installed into the initrd? Peter From maxamillion at gmail.com Thu Jul 2 13:28:57 2009 From: maxamillion at gmail.com (Adam Miller) Date: Thu, 2 Jul 2009 08:28:57 -0500 Subject: rawhide report: 20090702 changes In-Reply-To: References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <4A4CABD5.4030104@gmail.com> <4A4CAC4B.8070600@fedoraproject.org> Message-ID: +1 on the Books idea but I feel obligated to do something along the lines of: But I shall refrain. -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From walters at verbum.org Thu Jul 2 13:30:37 2009 From: walters at verbum.org (Colin Walters) Date: Thu, 2 Jul 2009 09:30:37 -0400 Subject: ppc64 assistance In-Reply-To: <5256d0b0907020620x18420b4ah8574122feae83221@mail.gmail.com> References: <5256d0b0907020329k8ed1219ldf26d4443e4858b@mail.gmail.com> <5256d0b0907020620x18420b4ah8574122feae83221@mail.gmail.com> Message-ID: On Thu, Jul 2, 2009 at 9:20 AM, Peter Robinson wrote: > > Interestingly with -ggdb it builds fine with out without -O0. That makes it a lot more likely to be a compiler flaw (though not guaranteed). Does 'make check' pass in the source tree you built with -O0? A backtrace would still be great though. Try setting DEBUG=fcatch in the environment. Some day hopefully ABRT will come and do this transparently and automatically... From stickster at gmail.com Thu Jul 2 13:48:46 2009 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 2 Jul 2009 09:48:46 -0400 Subject: rawhide report: 20090702 changes In-Reply-To: References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <4A4CABD5.4030104@gmail.com> <4A4CAC4B.8070600@fedoraproject.org> Message-ID: <20090702134846.GH9871@localhost.localdomain> On Thu, Jul 02, 2009 at 02:52:59PM +0200, Thomas Janssen wrote: > 2009/7/2 Rahul Sundaram : > > On 07/02/2009 06:15 PM, Frank Murphy wrote: > > > >> Is there a book group? > >> or what search parameter? > >> Tried yum info "Dive Into Python" > > > > # yum info diveintopython > > > > Since we have more than one book, I guess a new group could be defined > > as well. If there is consensus on the name, I can add it. Should we just > > call it "Books" ? > > +1 Perhaps something more inclusive like "Documentation" would be good. It's possible that the Docs team might produce some content that would be useful here as well. Or alternately, "Books and Guides"? -- 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 pbrobinson at gmail.com Thu Jul 2 13:55:30 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 2 Jul 2009 14:55:30 +0100 Subject: ppc64 assistance In-Reply-To: References: <5256d0b0907020329k8ed1219ldf26d4443e4858b@mail.gmail.com> <5256d0b0907020620x18420b4ah8574122feae83221@mail.gmail.com> Message-ID: <5256d0b0907020655y31945b0bqc3b8b73cacd6dccd@mail.gmail.com> >> Interestingly with -ggdb it builds fine with out without -O0. > > That makes it a lot more likely to be a compiler flaw (though not guaranteed). > > Does 'make check' pass in the source tree you built with -O0? > > A backtrace would still be great though. ?Try setting DEBUG=fcatch in > the environment. ?Some day hopefully ABRT will come and do this > transparently and automatically... A -O0 segfaults in x86 too so I just discovered :-( It seems also that the frysk package isn't built in rawhide ppc and I'm not sure if there's any other bits I need to add to it. The make clean is on this koji report. http://koji.fedoraproject.org/koji/getfile?taskID=1449535&name=build.log Cheers, Peter From harald at redhat.com Thu Jul 2 14:20:12 2009 From: harald at redhat.com (Harald Hoyer) Date: Thu, 02 Jul 2009 16:20:12 +0200 Subject: [ANNOUNCEMENT] dracut-0.3 In-Reply-To: <4A4CB11F.6060608@redhat.com> References: <4A4C92FA.50501@redhat.com> <4A4CB11F.6060608@redhat.com> Message-ID: <4A4CC21C.3070405@redhat.com> On 07/02/2009 03:07 PM, Harald Hoyer wrote: > On 07/02/2009 12:59 PM, Harald Hoyer wrote: >> Here it is, dracut-0.3! >> >> Featuring booting from all kind of block devices, NFS, iSCSI and NBD. >> >> Dracut is a new initramfs infrastructure. It should replace >> nash/mkinitrd. >> Dracut is a feauture for Fedora 12 >> http://fedoraproject.org/wiki/Features/Dracut >> >> How to get started, if you want to test. >> >> # yum install dracut-0.3 >> >> To generate a initramfs image, run: >> >> # dracut >> >> to overwrite an existing image: >> >> # dracut -f >> >> Try to boot from that image by modifying /etc/grub.conf. Be sure to have >> a fallback entry. >> >> If you want to boot from network have a look at the manpage. >> Basically everything can be specified on the kernel command line. >> >> Bug reports can be send directly to me (harald at redhat.com) until dracut >> appears in the bugzilla component list. >> >> Further information about dracut: >> http://sourceforge.net/apps/trac/dracut/wiki >> > > > Ok, it seems the debug dracut module wants to be installed > automatically, due to a bug. > > You either have all binaries which are needed by the dracut debug > module, or create the images with: > > > # dracut --omit debug > Oh, and here are the Fedora 11 rpms https://koji.fedoraproject.org/koji/buildinfo?buildID=112659 From harald at redhat.com Thu Jul 2 14:22:05 2009 From: harald at redhat.com (Harald Hoyer) Date: Thu, 02 Jul 2009 16:22:05 +0200 Subject: [ANNOUNCEMENT] dracut-0.3 In-Reply-To: <5256d0b0907020626x7cfebacdpfd211d52863e7c28@mail.gmail.com> References: <4A4C92FA.50501@redhat.com> <1246532972.2168.4.camel@polyethylene> <4A4C968D.3040003@redhat.com> <5256d0b0907020626x7cfebacdpfd211d52863e7c28@mail.gmail.com> Message-ID: <4A4CC28D.2070800@redhat.com> On 07/02/2009 03:26 PM, Peter Robinson wrote: >>> Hi Harald, >>> >>> On Thu, 2009-07-02 at 12:59 +0200, Harald Hoyer wrote: >>>> Here it is, dracut-0.3! >>> Thanks for your efforts, this is excellent. >>> >>> We've started using it for OLPC's F11 spin, including our own modules to >>> implement OLPC features. So much nicer than what we had before! >>> >>> However, the spec file already pulls in a lot of dependencies, things >>> like device-mapper and cryptsetup which we won't need. Especially for >>> XO-1 we need to work to keep images small (1GB hard disk). >>> >>> Is there any chance that this could be split up, and the more exotic >>> dependencies moved into subpackages? >>> >>> Cheers, >>> Daniel >>> >>> >> The idea is to pregenerate a generic initrd and package it in an rpm and >> deliver it together with the kernel. There should be no need to generate the >> initrd on an X0-1 itsself. > > How does this work for changing plymouth spash plugins as I seem to > remember these are installed into the initrd? > > Peter > Right, didn't think of that one.. ah well.. maybe package all plugins and make the theme selectable on the command line. From sundaram at fedoraproject.org Thu Jul 2 14:22:35 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Jul 2009 19:52:35 +0530 Subject: rawhide report: 20090702 changes In-Reply-To: References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <4A4CABD5.4030104@gmail.com> <4A4CAC4B.8070600@fedoraproject.org> Message-ID: <4A4CC2AB.9010508@fedoraproject.org> On 07/02/2009 06:58 PM, Adam Miller wrote: > +1 on the Books idea Does this look ok? --- comps-f12.xml.in.orig 2009-07-02 15:39:02.000000000 +0530 +++ comps-f12.xml.in 2009-07-02 19:49:32.108616562 +0530 @@ -520,6 +520,17 @@ + books + <_name>Technical Books + <_description/> + false + true + + diveintopython + ldd-pdf + + + buildsys-build <_name>Buildsystem building group <_description/> Rahul From iarnell at gmail.com Thu Jul 2 14:46:27 2009 From: iarnell at gmail.com (Iain Arnell) Date: Thu, 2 Jul 2009 16:46:27 +0200 Subject: FESCo meeting summary for 2009-06-26 In-Reply-To: <4A4C8903.3000302@gdt.id.au> References: <200906291314.19557.mhlavink@redhat.com> <571dcba60906290420v4720785gac13b28fab0f8d3e@mail.gmail.com> <20090629160913.GD32653@nostromo.devel.redhat.com> <4A4C8903.3000302@gdt.id.au> Message-ID: <81487f820907020746n3caa08b2v96bfef27d76ec5e4@mail.gmail.com> On Thu, Jul 2, 2009 at 12:16 PM, Glen Turner wrote: > On 30/06/09 01:39, Bill Nottingham wrote: >> >> That's a really crappy place for that message, though. What's the user >> supposed to do there... reboot and then go download another 700MB - 4GB? > > Yes it's a crappy place. I knew that when I suggested it. ?I just couldn't > think of a Javascript hack which would cough up the CPU features even when > running under a 32b OS like Windows Xp. ?Suggestions welcomed. Ah, on OS like Windows, maybe ActiveX helps. I don't have such a beast at the minute to test, but maybe this[1] works. [1] http://www.devarticles.com/c/a/JavaScript/How-to-Use-JavaScript-for-Hardware-Knowledge/1/ -- Iain. From kevin.kofler at chello.at Thu Jul 2 15:01:29 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 02 Jul 2009 17:01:29 +0200 Subject: ppc64 assistance References: <5256d0b0907020329k8ed1219ldf26d4443e4858b@mail.gmail.com> Message-ID: Peter Robinson wrote: > http://koji.fedoraproject.org/koji/taskinfo?taskID=1449113 Unrelated to this issue, but please use "make V=1" so we see the actual build command lines in the build.log (see the thread about the new automake). Kevin Kofler From kevin.kofler at chello.at Thu Jul 2 15:07:39 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 02 Jul 2009 17:07:39 +0200 Subject: rawhide report: 20090702 changes References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > Yes and this is not even the first time. Dive Into Python has been in > the repo for ages already. That doesn't mean it's compliant with our guidelines on shipping content. I really don't see what benefit it gives us to have a package dumping some book into /usr/share. Can't it be given as a regular download on a website? Possibly even the Fedora wiki. But packages sound to me like a completely overkill format to distribute PDF books. It's also a hard decision where to draw the line: will you accept a PDF of Jules Verne's Around the World in 80 Days (which is in the public domain) as well? What exact criteria make Dive into Python OK and Around the World in 80 Days not? Kevin Kofler From drago01 at gmail.com Thu Jul 2 15:14:06 2009 From: drago01 at gmail.com (drago01) Date: Thu, 2 Jul 2009 17:14:06 +0200 Subject: rawhide report: 20090702 changes In-Reply-To: References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> Message-ID: On Thu, Jul 2, 2009 at 5:07 PM, Kevin Kofler wrote: > Rahul Sundaram wrote: >> Yes and this is not even the first time. Dive Into Python has been in >> the repo for ages already. > > That doesn't mean it's compliant with our guidelines on shipping content. I > really don't see what benefit it gives us to have a package dumping some > book into /usr/share. Can't it be given as a regular download on a website? > Possibly even the Fedora wiki. But packages sound to me like a completely > overkill format to distribute PDF books. +1 http://fedoraproject.org/wiki/Packaging/Guidelines#Code_Vs_Content "If the content enhances the OS user experience, then the content is OK to be packaged in Fedora. This means, for example, that things like: fonts, themes, clipart, and wallpaper are OK. " So does a programming book enhance the OS user experience? From drago01 at gmail.com Thu Jul 2 15:15:37 2009 From: drago01 at gmail.com (drago01) Date: Thu, 2 Jul 2009 17:15:37 +0200 Subject: rawhide report: 20090702 changes In-Reply-To: <4A4CC2AB.9010508@fedoraproject.org> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <4A4CABD5.4030104@gmail.com> <4A4CAC4B.8070600@fedoraproject.org> <4A4CC2AB.9010508@fedoraproject.org> Message-ID: On Thu, Jul 2, 2009 at 4:22 PM, Rahul Sundaram wrote: > On 07/02/2009 06:58 PM, Adam Miller wrote: >> +1 on the Books idea > > Does this look ok? > > --- comps-f12.xml.in.orig ? ? ? 2009-07-02 15:39:02.000000000 +0530 > +++ comps-f12.xml.in ? ?2009-07-02 19:49:32.108616562 +0530 > @@ -520,6 +520,17 @@ > ? ? > ? > ? > + ? ?books > + ? ?<_name>Technical Books > + ? ?<_description/> > + ? ?false > + ? ?true > + ? ? > + ? ? ?diveintopython > + ? ? ?ldd-pdf > + ? ? > + ? > + ? > ? ? buildsys-build > ? ? <_name>Buildsystem building group > ? ? <_description/> > If we want to go this route, why limit it to technical books? From maxamillion at gmail.com Thu Jul 2 15:19:10 2009 From: maxamillion at gmail.com (Adam Miller) Date: Thu, 2 Jul 2009 10:19:10 -0500 Subject: rawhide report: 20090702 changes In-Reply-To: References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> Message-ID: On Thu, Jul 2, 2009 at 10:14 AM, drago01 wrote: > "If the content enhances the OS user experience, then the content is > OK to be packaged in Fedora. This means, for example, that things > like: fonts, themes, clipart, and wallpaper are OK. " > > So does a programming book enhance the OS user experience? That's subject to opinion which is exactly why this policy is flawed. -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From sundaram at fedoraproject.org Thu Jul 2 15:19:30 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Jul 2009 20:49:30 +0530 Subject: rawhide report: 20090702 changes In-Reply-To: References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <4A4CABD5.4030104@gmail.com> <4A4CAC4B.8070600@fedoraproject.org> <4A4CC2AB.9010508@fedoraproject.org> Message-ID: <4A4CD002.1050101@fedoraproject.org> On 07/02/2009 08:45 PM, drago01 wrote: > > If we want to go this route, why limit it to technical books? That's what is currently available. The description can be changed if policy is. Rahul From bouncingcats at gmail.com Thu Jul 2 15:21:40 2009 From: bouncingcats at gmail.com (David) Date: Fri, 3 Jul 2009 01:21:40 +1000 Subject: rawhide report: 20090702 changes In-Reply-To: <4A4CAAE4.4090404@fedoraproject.org> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> Message-ID: <3098cd930907020821t48af4e83ne1c64c7a2e28bec2@mail.gmail.com> On Thu, Jul 2, 2009 at 10:41 PM, Rahul Sundaram wrote: > On 07/02/2009 06:03 PM, drago01 wrote: >> On Thu, Jul 2, 2009 at 1:32 PM, Rawhide Report wrote: >>> Compose started at Thu Jul ?2 06:15:05 UTC 2009 >>> ... >>> New package ldd-pdf >>> ? ? ? ?Linux Device Drivers, Third Edition Book in PDF format >> >> We ship books as packages? > > Yes and this is not even the first time. Dive Into Python has been in > the repo for ages already. I disagree that Fedora should be packaging books, both of these can easily be downloaded via web. Why package something that has no dependencies? From sundaram at fedoraproject.org Thu Jul 2 15:23:52 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Jul 2009 20:53:52 +0530 Subject: rawhide report: 20090702 changes In-Reply-To: <3098cd930907020821t48af4e83ne1c64c7a2e28bec2@mail.gmail.com> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <3098cd930907020821t48af4e83ne1c64c7a2e28bec2@mail.gmail.com> Message-ID: <4A4CD108.8050402@fedoraproject.org> On 07/02/2009 08:51 PM, David wrote: > I disagree that Fedora should be packaging books, both of these can > easily be downloaded via web. > Why package something that has no dependencies? We package hundreds of things that have no dependencies and can be downloaded easily via web including fonts. That is not a argument. Rahul From pbrobinson at gmail.com Thu Jul 2 15:28:15 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 2 Jul 2009 16:28:15 +0100 Subject: ppc64 assistance In-Reply-To: References: <5256d0b0907020329k8ed1219ldf26d4443e4858b@mail.gmail.com> Message-ID: <5256d0b0907020828i7dddc797wd89d3b440b0948be@mail.gmail.com> >> http://koji.fedoraproject.org/koji/taskinfo?taskID=1449113 > > Unrelated to this issue, but please use "make V=1" so we see the actual > build command lines in the build.log (see the thread about the new > automake). With V=1 http://koji.fedoraproject.org/koji/getfile?taskID=1450335&name=build.log Peter From belegdol at gmail.com Thu Jul 2 15:30:04 2009 From: belegdol at gmail.com (Julian Sikorski) Date: Thu, 02 Jul 2009 17:30:04 +0200 Subject: rawhide report: 20090702 changes In-Reply-To: <4A4CD108.8050402@fedoraproject.org> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <3098cd930907020821t48af4e83ne1c64c7a2e28bec2@mail.gmail.com> <4A4CD108.8050402@fedoraproject.org> Message-ID: Rahul Sundaram pisze: > On 07/02/2009 08:51 PM, David wrote: > >> I disagree that Fedora should be packaging books, both of these can >> easily be downloaded via web. >> Why package something that has no dependencies? > > We package hundreds of things that have no dependencies and can be > downloaded easily via web including fonts. That is not a argument. > > Rahul > I think the main point here should be what advantage does packaging books have. Are there any book readers that look into /usr/share/yourfavouritebook by default? If not, I think that's actually easier to open a file you have lying on your desktop or your docs dir (where your recently opened files most likely are) than to dig through the filesystem. Julian From txtoth at gmail.com Thu Jul 2 15:31:48 2009 From: txtoth at gmail.com (Xavier Toth) Date: Thu, 2 Jul 2009 10:31:48 -0500 Subject: F10 anaconda incompatible with current F10 yum - WTF In-Reply-To: References: Message-ID: On Wed, Jul 1, 2009 at 5:47 PM, Kevin Kofler wrote: > Xavier Toth wrote: >> So I do a yum update, pickup a yum that isn't compatible with the >> original anaconda and then can no longer make installable DVD's. This >> is busted! If anaconda is dependent on a specific version of yum then >> it's Requires need to be equal to that version and not greater than or >> equal to. > > That would just replace the runtime error with a broken dependency. The only > solution is to release an anaconda update matching the yum update. We > really need anaconda updates for the benefit of respins! Anaconda not > working with the current update yum is a serious regression and we need a > matching Anaconda update ASAP. > > ? ? ? ?Kevin Kofler > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > It's a one liner. --- anaconda-11.5.0.12/yuminstall.py.orig 2009-06-30 09:05:19.000000000 -0500 +++ anaconda-11.5.0.12/yuminstall.py 2009-06-30 09:06:03.000000000 -0500 @@ -575,8 +575,7 @@ YumSorter.getReposFromConfig(self) # Override this method so yum doesn't nuke our existing logging config. - def doLoggingSetup(self, debuglevel, errorlevel, syslog_indent=None, - syslog_facility=None): + def doLoggingSetup(self, *args, **kwargs): pass def doConfigSetup(self, fn='/tmp/anaconda-yum.conf', root='/'): Ted From stickster at gmail.com Thu Jul 2 15:34:24 2009 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 2 Jul 2009 11:34:24 -0400 Subject: rawhide report: 20090702 changes In-Reply-To: <4A4CD108.8050402@fedoraproject.org> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <3098cd930907020821t48af4e83ne1c64c7a2e28bec2@mail.gmail.com> <4A4CD108.8050402@fedoraproject.org> Message-ID: <20090702153424.GB20634@localhost.localdomain> On Thu, Jul 02, 2009 at 08:53:52PM +0530, Rahul Sundaram wrote: > On 07/02/2009 08:51 PM, David wrote: > > > I disagree that Fedora should be packaging books, both of these can > > easily be downloaded via web. > > Why package something that has no dependencies? > > We package hundreds of things that have no dependencies and can be > downloaded easily via web including fonts. That is not a argument. Arguably, this particular content can be helpful for cultivating contribution, i.e. training developers. Perhaps there is a reasonably objective standard to be found there for content, but I'm not sure it captures everything we hope to include in the future. -- 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 bouncingcats at gmail.com Thu Jul 2 15:39:37 2009 From: bouncingcats at gmail.com (David) Date: Fri, 3 Jul 2009 01:39:37 +1000 Subject: rawhide report: 20090702 changes In-Reply-To: <4A4CD108.8050402@fedoraproject.org> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <3098cd930907020821t48af4e83ne1c64c7a2e28bec2@mail.gmail.com> <4A4CD108.8050402@fedoraproject.org> Message-ID: <3098cd930907020839l47040aa2m77b305825972150@mail.gmail.com> On Fri, Jul 3, 2009 at 1:23 AM, Rahul Sundaram wrote: > On 07/02/2009 08:51 PM, David wrote: > >> I disagree that Fedora should be packaging books, both of these can >> easily be downloaded via web. >> Why package something that has no dependencies? > > We package hundreds of things that have no dependencies and can be > downloaded easily via web including fonts. That is not a argument. OK, but if the package payload doesn't interoperate with another package, I can't see the point. Fonts, artwork, sure, they are a system resource for other software. From maxamillion at gmail.com Thu Jul 2 15:42:01 2009 From: maxamillion at gmail.com (Adam Miller) Date: Thu, 2 Jul 2009 10:42:01 -0500 Subject: rawhide report: 20090702 changes In-Reply-To: <3098cd930907020839l47040aa2m77b305825972150@mail.gmail.com> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <3098cd930907020821t48af4e83ne1c64c7a2e28bec2@mail.gmail.com> <4A4CD108.8050402@fedoraproject.org> <3098cd930907020839l47040aa2m77b305825972150@mail.gmail.com> Message-ID: On Thu, Jul 2, 2009 at 10:39 AM, David wrote: > OK, but if the package payload doesn't interoperate with another > package, I can't see the point. Fonts, artwork, sure, they are a > system resource for other software. By that logic a book distributed in PDF is a "system resource" for my pdf viewer just as artwork is a "system resource" for my desktop environment's background manager. -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From notting at redhat.com Thu Jul 2 15:43:46 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 2 Jul 2009 11:43:46 -0400 Subject: FESCo meeting summary for 2009-06-26 In-Reply-To: <4A4C8903.3000302@gdt.id.au> References: <200906291314.19557.mhlavink@redhat.com> <571dcba60906290420v4720785gac13b28fab0f8d3e@mail.gmail.com> <20090629160913.GD32653@nostromo.devel.redhat.com> <4A4C8903.3000302@gdt.id.au> Message-ID: <20090702154346.GC26481@nostromo.devel.redhat.com> Glen Turner (gdt at gdt.id.au) said: >> That's a really crappy place for that message, though. What's the user >> supposed to do there... reboot and then go download another 700MB - 4GB? > > Yes it's a crappy place. I knew that when I suggested it. I just couldn't > think of a Javascript hack which would cough up the CPU features even when > running under a 32b OS like Windows Xp. Suggestions welcomed. Dual-arch media. (Which is a pain, and will run into space issues sooner or later.) Bill From dwmw2 at infradead.org Thu Jul 2 15:43:50 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 02 Jul 2009 16:43:50 +0100 Subject: ppc64 assistance In-Reply-To: <5256d0b0907020828i7dddc797wd89d3b440b0948be@mail.gmail.com> References: <5256d0b0907020329k8ed1219ldf26d4443e4858b@mail.gmail.com> <5256d0b0907020828i7dddc797wd89d3b440b0948be@mail.gmail.com> Message-ID: <1246549430.3681.3486.camel@macbook.infradead.org> On Thu, 2009-07-02 at 16:28 +0100, Peter Robinson wrote: > >> http://koji.fedoraproject.org/koji/taskinfo?taskID=1449113 > > > > Unrelated to this issue, but please use "make V=1" so we see the actual > > build command lines in the build.log (see the thread about the new > > automake). > > With V=1 > > http://koji.fedoraproject.org/koji/getfile?taskID=1450335&name=build.log You know you can have access to a real box to test this on if you want it, right? You don't have to do it all in koji and look at the build logs. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation From rc040203 at freenet.de Thu Jul 2 15:45:03 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 02 Jul 2009 17:45:03 +0200 Subject: ppc64 assistance In-Reply-To: <5256d0b0907020828i7dddc797wd89d3b440b0948be@mail.gmail.com> References: <5256d0b0907020329k8ed1219ldf26d4443e4858b@mail.gmail.com> <5256d0b0907020828i7dddc797wd89d3b440b0948be@mail.gmail.com> Message-ID: <4A4CD5FF.9030701@freenet.de> Peter Robinson wrote: >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=1449113 >> Unrelated to this issue, but please use "make V=1" so we see the actual >> build command lines in the build.log (see the thread about the new >> automake). > > With V=1 > > http://koji.fedoraproject.org/koji/getfile?taskID=1450335&name=build.log AFAIS, your spec doesn't seem to pass RPM_OPT_FLAGS correctly, as well as does the package seems to play dirty games with CFLAGS. I haven't checked details, though. FWIW: Build breakdowns on ppc64 often are caused by not passing RPM_OPT_FLAGS correctly or a package playing dirty games with CFLAGS/CXXFLAGS. Ralf From sundaram at fedoraproject.org Thu Jul 2 15:45:22 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Jul 2009 21:15:22 +0530 Subject: rawhide report: 20090702 changes In-Reply-To: References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> Message-ID: <4A4CD612.7010702@fedoraproject.org> On 07/02/2009 08:37 PM, Kevin Kofler wrote: > Rahul Sundaram wrote: >> Yes and this is not even the first time. Dive Into Python has been in >> the repo for ages already. > > That doesn't mean it's compliant with our guidelines on shipping content. I > really don't see what benefit it gives us to have a package dumping some > book into /usr/share. Can't it be given as a regular download on a website? > Possibly even the Fedora wiki. But packages sound to me like a completely > overkill format to distribute PDF books. We have heard both sides of the argument in detail several times now and I doubt there is value in debating it one more time on the list. So take it up to FESCo if you think there is some violation of guidelines. Rahul From pbrobinson at gmail.com Thu Jul 2 15:51:14 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 2 Jul 2009 16:51:14 +0100 Subject: ppc64 assistance In-Reply-To: <4A4CD5FF.9030701@freenet.de> References: <5256d0b0907020329k8ed1219ldf26d4443e4858b@mail.gmail.com> <5256d0b0907020828i7dddc797wd89d3b440b0948be@mail.gmail.com> <4A4CD5FF.9030701@freenet.de> Message-ID: <5256d0b0907020851w492e690kf666e70b5b0fd824@mail.gmail.com> >>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=1449113 >>> >>> Unrelated to this issue, but please use "make V=1" so we see the actual >>> build command lines in the build.log (see the thread about the new >>> automake). >> >> With V=1 >> >> http://koji.fedoraproject.org/koji/getfile?taskID=1450335&name=build.log > > AFAIS, your spec doesn't seem to pass RPM_OPT_FLAGS correctly, as well as > does the package seems to play dirty games with CFLAGS. I haven't checked > details, though. > > FWIW: Build breakdowns on ppc64 often are caused by not passing > RPM_OPT_FLAGS correctly or a package playing dirty games with > CFLAGS/CXXFLAGS. The dirty games were to try and work out this issue with PPC64 (it built fine on the rest of them) and it seems your right with the dirty CFLAGS game as it broke other previous working ones. This rev of the spec file was the one that worked on all but ppc64. http://cvs.fedoraproject.org/viewvc/rpms/gobject-introspection/devel/gobject-introspection.spec?revision=1.9&view=markup Peter From pbrobinson at gmail.com Thu Jul 2 15:51:50 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 2 Jul 2009 16:51:50 +0100 Subject: ppc64 assistance In-Reply-To: <1246549430.3681.3486.camel@macbook.infradead.org> References: <5256d0b0907020329k8ed1219ldf26d4443e4858b@mail.gmail.com> <5256d0b0907020828i7dddc797wd89d3b440b0948be@mail.gmail.com> <1246549430.3681.3486.camel@macbook.infradead.org> Message-ID: <5256d0b0907020851r51d04710u3e1e0e380ef9ad28@mail.gmail.com> >> >> http://koji.fedoraproject.org/koji/taskinfo?taskID=1449113 >> > >> > Unrelated to this issue, but please use "make V=1" so we see the actual >> > build command lines in the build.log (see the thread about the new >> > automake). >> >> With V=1 >> >> http://koji.fedoraproject.org/koji/getfile?taskID=1450335&name=build.log > > You know you can have access to a real box to test this on if you want > it, right? You don't have to do it all in koji and look at the build > logs. No I didn't. Are the details published anywhere of how to request access? Peter From drago01 at gmail.com Thu Jul 2 15:20:26 2009 From: drago01 at gmail.com (drago01) Date: Thu, 2 Jul 2009 17:20:26 +0200 Subject: rawhide report: 20090702 changes In-Reply-To: References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> Message-ID: On Thu, Jul 2, 2009 at 5:19 PM, Adam Miller wrote: > On Thu, Jul 2, 2009 at 10:14 AM, drago01 wrote: >> "If the content enhances the OS user experience, then the content is >> OK to be packaged in Fedora. This means, for example, that things >> like: fonts, themes, clipart, and wallpaper are OK. " >> >> So does a programming book enhance the OS user experience? > > That's subject to opinion which is exactly why this policy is flawed. I know (there is a reason why I did not provide an answer to this question) From bochecha at fedoraproject.org Thu Jul 2 14:55:48 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Thu, 2 Jul 2009 16:55:48 +0200 Subject: rawhide report: 20090702 changes In-Reply-To: <4A4CC2AB.9010508@fedoraproject.org> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <4A4CABD5.4030104@gmail.com> <4A4CAC4B.8070600@fedoraproject.org> <4A4CC2AB.9010508@fedoraproject.org> Message-ID: <2d319b780907020755k708a64f6s32c5885cce22e84c@mail.gmail.com> > Does this look ok? > > --- comps-f12.xml.in.orig ? ? ? 2009-07-02 15:39:02.000000000 +0530 > +++ comps-f12.xml.in ? ?2009-07-02 19:49:32.108616562 +0530 > @@ -520,6 +520,17 @@ > ? ? > ? > ? > + ? ?books > + ? ?<_name>Technical Books > + ? ?<_description/> > + ? ?false > + ? ?true > + ? ? > + ? ? ?diveintopython > + ? ? ?ldd-pdf > + ? ? > + ? > + ? > ? ? buildsys-build > ? ? <_name>Buildsystem building group > ? ? <_description/> What if we start including non-technical books (like educational material for the OLPC) ? If the group name is "Technical books", so should be the group id don't you think ? Might be bikeshedding, but if we can avoid closing some doors... ---------- Mathieu Bridon (bochecha) From jwboyer at gmail.com Thu Jul 2 16:08:56 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 2 Jul 2009 12:08:56 -0400 Subject: ppc64 assistance In-Reply-To: <5256d0b0907020851r51d04710u3e1e0e380ef9ad28@mail.gmail.com> References: <5256d0b0907020329k8ed1219ldf26d4443e4858b@mail.gmail.com> <5256d0b0907020828i7dddc797wd89d3b440b0948be@mail.gmail.com> <1246549430.3681.3486.camel@macbook.infradead.org> <5256d0b0907020851r51d04710u3e1e0e380ef9ad28@mail.gmail.com> Message-ID: <20090702160856.GD5772@hansolo.jdub.homelinux.org> On Thu, Jul 02, 2009 at 04:51:50PM +0100, Peter Robinson wrote: >>> >> http://koji.fedoraproject.org/koji/taskinfo?taskID=1449113 >>> > >>> > Unrelated to this issue, but please use "make V=1" so we see the actual >>> > build command lines in the build.log (see the thread about the new >>> > automake). >>> >>> With V=1 >>> >>> http://koji.fedoraproject.org/koji/getfile?taskID=1450335&name=build.log >> >> You know you can have access to a real box to test this on if you want >> it, right? You don't have to do it all in koji and look at the build >> logs. > >No I didn't. Are the details published anywhere of how to request access? I'm working on it. Basically, email dwmw2 or me an ssh public key. josh From opensource at till.name Thu Jul 2 16:14:49 2009 From: opensource at till.name (Till Maas) Date: Thu, 02 Jul 2009 18:14:49 +0200 Subject: rawhide report: 20090702 changes In-Reply-To: References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> Message-ID: <200907021815.08176.opensource@till.name> On Thu July 2 2009, Kevin Kofler wrote: > It's also a hard decision where to draw the line: will you accept a PDF of > Jules Verne's Around the World in 80 Days (which is in the public domain) > as well? What exact criteria make Dive into Python OK and Around the World > in 80 Days not? Dive into python is additional documentation to software we ship in Fedora. The Jule Verne Book is not. Nevertheless it would be nice to have a central repository for entertaining free content. Btw. an even older content older package is "man-pages". Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From rc040203 at freenet.de Thu Jul 2 16:24:16 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 02 Jul 2009 18:24:16 +0200 Subject: ppc64 assistance In-Reply-To: <5256d0b0907020851w492e690kf666e70b5b0fd824@mail.gmail.com> References: <5256d0b0907020329k8ed1219ldf26d4443e4858b@mail.gmail.com> <5256d0b0907020828i7dddc797wd89d3b440b0948be@mail.gmail.com> <4A4CD5FF.9030701@freenet.de> <5256d0b0907020851w492e690kf666e70b5b0fd824@mail.gmail.com> Message-ID: <4A4CDF30.3000608@freenet.de> Peter Robinson wrote: >>>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=1449113 >>>> Unrelated to this issue, but please use "make V=1" so we see the actual >>>> build command lines in the build.log (see the thread about the new >>>> automake). >>> With V=1 >>> >>> http://koji.fedoraproject.org/koji/getfile?taskID=1450335&name=build.log >> AFAIS, your spec doesn't seem to pass RPM_OPT_FLAGS correctly, as well as >> does the package seems to play dirty games with CFLAGS. I haven't checked >> details, though. >> >> FWIW: Build breakdowns on ppc64 often are caused by not passing >> RPM_OPT_FLAGS correctly or a package playing dirty games with >> CFLAGS/CXXFLAGS. > > The dirty games were to try and work out this issue with PPC64 (it > built fine on the rest of them) Well, this is expected ;) AFAICT, on the ppc64, the default/implicit -mXXX flags in GCC diverge from what is in RPM_OPT_FLAGS, so you end up with incorrectly compiled binaries, if not correctly passing through RPM_OPT_FLAGS. Conversely, if not passing RPM_OPT_FLAGS, one often gets away with "no build-breakdowns" on all targets, but is facing the kind of issue your are facing on the ppc64. Furthermore, several GCC flags people are using in dirty CFLAGS tricks often actually are target-specific, which will cause build-breakdowns on more exotic target. -ggdb is one of these non-portable options, but I am not sufficiently familiar with RH's ppc64 to be able to judge if -ggdb is valid on RH-ppc64. Ralf From mcepl at redhat.com Thu Jul 2 16:27:52 2009 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 2 Jul 2009 16:27:52 +0000 (UTC) Subject: rawhide report: 20090702 changes References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> Message-ID: Kevin Kofler, Thu, 02 Jul 2009 17:07:39 +0200: > It's also a hard decision where to draw the line: will you accept a PDF > of Jules Verne's Around the World in 80 Days (which is in the public > domain) as well? What exact criteria make Dive into Python OK and Around > the World in 80 Days not? And even more seriously ... sword (library for retrieval and search through big texts used mainly by Biblical software like bibletime or xiphos) could really use some texts ... Biblical program without any content seems kind of bare, and I think KJV is distributable just fine. Mat?j From mcepl at redhat.com Thu Jul 2 16:29:35 2009 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 2 Jul 2009 16:29:35 +0000 (UTC) Subject: rawhide report: 20090702 changes References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <3098cd930907020821t48af4e83ne1c64c7a2e28bec2@mail.gmail.com> <4A4CD108.8050402@fedoraproject.org> Message-ID: Julian Sikorski, Thu, 02 Jul 2009 17:30:04 +0200: > I think the main point here should be what advantage does packaging > books have. Are there any book readers that look into > /usr/share/yourfavouritebook by default? If not, I think that's actually > easier to open a file you have lying on your desktop or your docs dir > (where your recently opened files most likely are) than to dig through > the filesystem. Well, my sword example would be more complicated than just a file on Desktop. Mat?j From skvidal at fedoraproject.org Thu Jul 2 16:29:12 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 2 Jul 2009 12:29:12 -0400 (EDT) Subject: rawhide report: 20090702 changes In-Reply-To: References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> Message-ID: On Thu, 2 Jul 2009, Matej Cepl wrote: > Kevin Kofler, Thu, 02 Jul 2009 17:07:39 +0200: >> It's also a hard decision where to draw the line: will you accept a PDF >> of Jules Verne's Around the World in 80 Days (which is in the public >> domain) as well? What exact criteria make Dive into Python OK and Around >> the World in 80 Days not? > > And even more seriously ... sword (library for retrieval and search > through big texts used mainly by Biblical software like bibletime or > xiphos) could really use some texts ... Biblical program without any > content seems kind of bare, and I think KJV is distributable just fine. > no. -sv From opensource at till.name Thu Jul 2 16:30:50 2009 From: opensource at till.name (Till Maas) Date: Thu, 02 Jul 2009 18:30:50 +0200 Subject: ppc64 assistance In-Reply-To: <20090702160856.GD5772@hansolo.jdub.homelinux.org> References: <5256d0b0907020329k8ed1219ldf26d4443e4858b@mail.gmail.com> <5256d0b0907020851r51d04710u3e1e0e380ef9ad28@mail.gmail.com> <20090702160856.GD5772@hansolo.jdub.homelinux.org> Message-ID: <200907021830.56477.opensource@till.name> On Thu July 2 2009, Josh Boyer wrote: > On Thu, Jul 02, 2009 at 04:51:50PM +0100, Peter Robinson wrote: > >No I didn't. Are the details published anywhere of how to request access? > > I'm working on it. Basically, email dwmw2 or me an ssh public key. I added this information to the PPC Sig wiki page: https://fedoraproject.org/wiki/Architectures/PowerPC#PPC_Shell_access_for_debugging Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From notting at redhat.com Thu Jul 2 16:43:10 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 2 Jul 2009 12:43:10 -0400 Subject: rawhide report: 20090702 changes In-Reply-To: References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> Message-ID: <20090702164310.GA30611@nostromo.devel.redhat.com> Matej Cepl (mcepl at redhat.com) said: > And even more seriously ... sword (library for retrieval and search > through big texts used mainly by Biblical software like bibletime or > xiphos) could really use some texts ... Biblical program without any > content seems kind of bare, and I think KJV is distributable just fine. I'm not sure how distributable the KJV is or isnt', but it's explicitly forbidden by the guidelines. Of course, I suspect we'll now have someone claiming that the camel book is actually a religous text. Bill From drago01 at gmail.com Thu Jul 2 16:54:56 2009 From: drago01 at gmail.com (drago01) Date: Thu, 2 Jul 2009 18:54:56 +0200 Subject: FESCo meeting summary for 2009-06-26 In-Reply-To: <20090702154346.GC26481@nostromo.devel.redhat.com> References: <200906291314.19557.mhlavink@redhat.com> <571dcba60906290420v4720785gac13b28fab0f8d3e@mail.gmail.com> <20090629160913.GD32653@nostromo.devel.redhat.com> <4A4C8903.3000302@gdt.id.au> <20090702154346.GC26481@nostromo.devel.redhat.com> Message-ID: On Thu, Jul 2, 2009 at 5:43 PM, Bill Nottingham wrote: > Glen Turner (gdt at gdt.id.au) said: >>> That's a really crappy place for that message, though. What's the user >>> supposed to do there... reboot and then go download another 700MB - 4GB? >> >> Yes it's a crappy place. I knew that when I suggested it. ?I just couldn't >> think of a Javascript hack which would cough up the CPU features even when >> running under a 32b OS like Windows Xp. ?Suggestions welcomed. > > Dual-arch media. (Which is a pain, and will run into space issues sooner > or later.) I don't see this as an issue for live media (if it is possible to do here). We have 700MB x 2 = 1400MB out of 4GB which we can ship on a DVD. We can provide an extra link "download CD" if someone really still has no dvd burner / drive in 2009. This also would allow us to add software like openoffice to the live media (which is ommited for space reasons because we insist on the pointless cd limit). From thomasj at fedoraproject.org Thu Jul 2 16:03:03 2009 From: thomasj at fedoraproject.org (Thomas Janssen) Date: Thu, 2 Jul 2009 18:03:03 +0200 Subject: rawhide report: 20090702 changes In-Reply-To: <20090702134846.GH9871@localhost.localdomain> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <4A4CABD5.4030104@gmail.com> <4A4CAC4B.8070600@fedoraproject.org> <20090702134846.GH9871@localhost.localdomain> Message-ID: 2009/7/2 Paul W. Frields : > On Thu, Jul 02, 2009 at 02:52:59PM +0200, Thomas Janssen wrote: >> 2009/7/2 Rahul Sundaram : >> > On 07/02/2009 06:15 PM, Frank Murphy wrote: >> > >> >> Is there a book group? >> > >> > Since we have more than one book, I guess a new group could be defined >> > as well. If there is consensus on the name, I can add it. Should we just >> > call it "Books" ? >> >> +1 > > Perhaps something more inclusive like "Documentation" would be good. > It's possible that the Docs team might produce some content that would > be useful here as well. ?Or alternately, "Books and Guides"? "Books and Guides" even better. -- LG Thomas Dubium sapientiae initium From pbrobinson at gmail.com Thu Jul 2 16:57:37 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 2 Jul 2009 17:57:37 +0100 Subject: Package reviews Message-ID: <5256d0b0907020957y25976db0i41099895c90fd12a@mail.gmail.com> Hi All, I'm working to get the core moblin packages into Fedora with the plan of having at least experimental support in time for F-12. If you've got a few spare cycles and have some time to review a package there's a list against the tracker bug here. https://bugzilla.redhat.com/show_bug.cgi?id=506446 Regards, Peter From fedora at matbooth.co.uk Thu Jul 2 17:02:39 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Thu, 2 Jul 2009 18:02:39 +0100 Subject: rawhide report: 20090702 changes In-Reply-To: <20090702164310.GA30611@nostromo.devel.redhat.com> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <20090702164310.GA30611@nostromo.devel.redhat.com> Message-ID: <9497e9990907021002h35a5f6dct92b6e18cf7cf9de6@mail.gmail.com> On Thu, Jul 2, 2009 at 5:43 PM, Bill Nottingham wrote: > > Of course, I suspect we'll now have someone claiming that the camel > book is actually a religous text. > For the love of Larry, have you no respect? -- Mat Booth www.matbooth.co.uk From jwboyer at gmail.com Thu Jul 2 17:04:20 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 2 Jul 2009 13:04:20 -0400 Subject: ppc64 assistance In-Reply-To: <200907021830.56477.opensource@till.name> References: <5256d0b0907020329k8ed1219ldf26d4443e4858b@mail.gmail.com> <5256d0b0907020851r51d04710u3e1e0e380ef9ad28@mail.gmail.com> <20090702160856.GD5772@hansolo.jdub.homelinux.org> <200907021830.56477.opensource@till.name> Message-ID: <20090702170420.GE5772@hansolo.jdub.homelinux.org> On Thu, Jul 02, 2009 at 06:30:50PM +0200, Till Maas wrote: >On Thu July 2 2009, Josh Boyer wrote: >> On Thu, Jul 02, 2009 at 04:51:50PM +0100, Peter Robinson wrote: > >> >No I didn't. Are the details published anywhere of how to request access? >> >> I'm working on it. Basically, email dwmw2 or me an ssh public key. > >I added this information to the PPC Sig wiki page: >https://fedoraproject.org/wiki/Architectures/PowerPC#PPC_Shell_access_for_debugging > Thanks. That's where I was going to add it too after doing some rework to that page. I'll be sure not to accidentally delete it when I do :) josh From mcepl at redhat.com Thu Jul 2 17:07:26 2009 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 2 Jul 2009 17:07:26 +0000 (UTC) Subject: rawhide report: 20090702 changes References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <20090702164310.GA30611@nostromo.devel.redhat.com> Message-ID: Bill Nottingham, Thu, 02 Jul 2009 12:43:10 -0400: > I'm not sure how distributable the KJV is or isnt', but it's explicitly > forbidden by the guidelines. > > Of course, I suspect we'll now have someone claiming that the camel book > is actually a religous text. Of course, and GNU Manifesto! But, no I wasn't seriously suggesting we should package Bibles (and Quaran etc. ... Fedora ME anyone http://www.sabily.org/website/ ? :)), just that if one goes other ones shouldn't as well. So, how should I propose to FESCO exclusion of DiveIntoPython (BTW, wonderful book), Jules Verne and anything else we find? Mat?j From pmachata at redhat.com Thu Jul 2 17:15:03 2009 From: pmachata at redhat.com (Petr Machata) Date: Thu, 02 Jul 2009 19:15:03 +0200 Subject: packaging fix in boost Message-ID: <4A4CEB17.3050500@redhat.com> Hi, recently we've (that's "we" as in me and Benjamin Kosnik, not a royal "we") broken up boost to sub-packages in Fedora Rawhide, but we forgot to drop a filelist at the main boost package, intended as an umbrella over all the sub-packages. So in the end, main boost package was still as big as it always was and all benefits (and bugs) that the split could bring were lost. Meh. boost-1.39.0-3.fc12 that should fix the above is being built right now. Maintainers of dependent packages, especially those that are known to be on the Live CD, might want to consider a rebuild. Thanks, PM -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From sundaram at fedoraproject.org Thu Jul 2 17:22:21 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Jul 2009 22:52:21 +0530 Subject: packaging fix in boost In-Reply-To: <4A4CEB17.3050500@redhat.com> References: <4A4CEB17.3050500@redhat.com> Message-ID: <4A4CECCD.7070402@fedoraproject.org> On 07/02/2009 10:45 PM, Petr Machata wrote: > Hi, > > recently we've (that's "we" as in me and Benjamin Kosnik, not a royal > "we") broken up boost to sub-packages in Fedora Rawhide, but we forgot > to drop a filelist at the main boost package, intended as an umbrella > over all the sub-packages. So in the end, main boost package was still > as big as it always was and all benefits (and bugs) that the split could > bring were lost. Meh. > > boost-1.39.0-3.fc12 that should fix the above is being built right now. > Maintainers of dependent packages, especially those that are known to > be on the Live CD, might want to consider a rebuild. Thanks for fixing this problem. Rahul From tibbs at math.uh.edu Thu Jul 2 17:32:48 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 02 Jul 2009 12:32:48 -0500 Subject: rawhide report: 20090702 changes In-Reply-To: (Matej Cepl's message of "Thu\, 2 Jul 2009 17\:07\:26 +0000 \(UTC\)") References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <20090702164310.GA30611@nostromo.devel.redhat.com> Message-ID: >>>>> "MC" == Matej Cepl writes: MC> So, how should I propose to FESCO exclusion of DiveIntoPython MC> (BTW, wonderful book), Jules Verne and anything else we find? Open a ticket on their trac (https://fedorahosted.org/fesco/). The issue here is that the guidelines explicitly permit documentation and help files; diveintopython is obviously documenting Python, and if it was bundled with the Python tarball then there wouldn't be any question at all about this. So I'm not really sure that the place where you draw the line is all that clear. At least the python package itself includes some reasonable documentation about the language. But the package that spawned this duscussion, the device drivers book, actually documents the kernel where the kernel doesn't really document itself. And there are other reviews for this kind of thing pending: javanotes, for example (https://bugzilla.redhat.com//show_bug.cgi?id=507916) covers Java for which we have little in-distro documentation, and there's at least one other package submitted by the same person. Make sure that the line you draw is clear with regards those packages as well. - J< From mclasen at redhat.com Thu Jul 2 17:34:18 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 02 Jul 2009 13:34:18 -0400 Subject: Raising the bar In-Reply-To: <1246384554.2087.85.camel@diet-anarchy.localdomain> References: <1246303647.1527.132.camel@localhost.localdomain> <1246384554.2087.85.camel@diet-anarchy.localdomain> Message-ID: <1246556058.2431.7.camel@localhost.localdomain> On Tue, 2009-06-30 at 13:55 -0400, Christopher Beland wrote: > On Mon, 2009-06-29 at 15:27 -0400, Matthias Clasen wrote: > > If you have ideas for > > other areas that could benefit from this kind of attention, please let > > us know. > > I can think of a number of different cross-component tests... [...] Yeah, this is a very nice checklist for 'basic sanity'. And any bug you file about a problem in one of those categories certainly qualifies as a 'fit and finish' issue. But as a test day topic, it might be a bit boring to spend the whole day testing e.g. copy-and-paste between app X and Y to fill a big matrix... Matthias From ngompa13 at gmail.com Thu Jul 2 17:39:03 2009 From: ngompa13 at gmail.com (King InuYasha) Date: Thu, 2 Jul 2009 12:39:03 -0500 Subject: Raising the bar In-Reply-To: <1246556058.2431.7.camel@localhost.localdomain> References: <1246303647.1527.132.camel@localhost.localdomain> <1246384554.2087.85.camel@diet-anarchy.localdomain> <1246556058.2431.7.camel@localhost.localdomain> Message-ID: <8278b1b0907021039v2c7e6359i7fa9690b537504d@mail.gmail.com> This might not be a big thing, but I was always rather annoyed that KDE applications didn't integrate nicely into the GNOME desktop. When KDE is the desktop, GNOME applications (except XUL based ones) looked very much in place and felt normal in a KDE system. KDE applications in a GNOME desktop tend to ignore GNOME and stick out like a sore thumb. Note that I mean KDE applications and not Qt applications. Qt applications (like VLC) fit right in GNOME. On Thu, Jul 2, 2009 at 12:34 PM, Matthias Clasen wrote: > On Tue, 2009-06-30 at 13:55 -0400, Christopher Beland wrote: > > On Mon, 2009-06-29 at 15:27 -0400, Matthias Clasen wrote: > > > If you have ideas for > > > other areas that could benefit from this kind of attention, please let > > > us know. > > > > I can think of a number of different cross-component tests... > > [...] > > Yeah, this is a very nice checklist for 'basic sanity'. And any bug you > file about a problem in one of those categories certainly qualifies as a > 'fit and finish' issue. But as a test day topic, it might be a bit > boring to spend the whole day testing e.g. copy-and-paste between app X > and Y to fill a big matrix... > > > Matthias > > -- > 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 sundaram at fedoraproject.org Thu Jul 2 17:40:09 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Jul 2009 23:10:09 +0530 Subject: rawhide report: 20090702 changes In-Reply-To: References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <4A4CABD5.4030104@gmail.com> <4A4CAC4B.8070600@fedoraproject.org> <20090702134846.GH9871@localhost.localdomain> Message-ID: <4A4CF0F9.1060701@fedoraproject.org> On 07/02/2009 09:33 PM, Thomas Janssen wrote: > 2009/7/2 Paul W. Frields : >> On Thu, Jul 02, 2009 at 02:52:59PM +0200, Thomas Janssen wrote: >>> 2009/7/2 Rahul Sundaram : >>>> On 07/02/2009 06:15 PM, Frank Murphy wrote: >>>> >>>>> Is there a book group? >>>> >>>> Since we have more than one book, I guess a new group could be defined >>>> as well. If there is consensus on the name, I can add it. Should we just >>>> call it "Books" ? >>> >>> +1 >> >> Perhaps something more inclusive like "Documentation" would be good. >> It's possible that the Docs team might produce some content that would >> be useful here as well. Or alternately, "Books and Guides"? > > "Books and Guides" even better. Committed for Fedora 12. Rahul From jonstanley at gmail.com Thu Jul 2 18:24:16 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 2 Jul 2009 14:24:16 -0400 Subject: No FESCo meeting for 2009-07-03 Message-ID: Due to the US holiday, FESCo will not hold it's regularly scheduled meeting tomorrow. All business will be postponed until next week. Have a great 4th if you're in the US, and if you're anywhere else, have a great 4th anyway! :) -Jon From awilliam at redhat.com Thu Jul 2 18:10:25 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 02 Jul 2009 19:10:25 +0100 Subject: rawhide report: 20090702 changes In-Reply-To: <20090702164310.GA30611@nostromo.devel.redhat.com> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <20090702164310.GA30611@nostromo.devel.redhat.com> Message-ID: <1246558225.25852.208.camel@vaio.local.net> On Thu, 2009-07-02 at 12:43 -0400, Bill Nottingham wrote: > I'm not sure how distributable the KJV is or isnt' It's been out of copyright for some little time, now. Probably.(*) * Of course, one could potentially make some quite interesting legal arguments about the author credit, and whether said author counts as 'living' within the terms of copyright laws that grant copyright during the lifetime of the author... ;) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From loganjerry at gmail.com Thu Jul 2 18:30:15 2009 From: loganjerry at gmail.com (Jerry James) Date: Thu, 2 Jul 2009 12:30:15 -0600 Subject: (A)synchronous file operations & xdg-open In-Reply-To: <200906252132.08976.ville.skytta@iki.fi> References: <870180fe0906250849h5f103e83g8b90bc00d73f2f47@mail.gmail.com> <200906252132.08976.ville.skytta@iki.fi> Message-ID: <870180fe0907021130l34fe18bcmff0fd5fac24c82b5@mail.gmail.com> On Thu, Jun 25, 2009 at 12:32 PM, Ville Skytt? wrote: > IMO the latter is clearly preferable, and would be even a good default. ?But > then again, it might be too late to change the default as it could break stuff > (even if the xdg-open man page doesn't document async/sync operation at the > moment). ?And I'm not sure if the tools xdg-open invokes have async/sync > operation modes - at least some of them would quite probably need > modifications as well. So xdg-open currently invokes the following tools, depending on desktop: KDE: kfmclient GNOME: gnome-open XFCE: exo-open If the desktop is something else, it runs the first of these tools it can find, checking in this order: mimeopen, run-mailcap, each element of $BROWSER, htmlview, firefox, mozilla, netscape, links, lynx. We already know that gnome-open operates in asynchronous mode. In https://bugzilla.redhat.com/show_bug.cgi?id=435107, Kevin Kofler says that kfmclient is also asynchronous. Does anybody know about exo-open? The desktop-agnostic tools are all aimed at displaying random URLs to the user, and would not be appropriate for the "edit a temporary file" use-case we're talking about. I am more and more of the opinion that xdg-open is simply the wrong tool for viewing/editing temporary files. It wasn't built for that use case, and the tools it invokes were not either. I think we need something different altogether. Should we go back to invoking $EDITOR, $VISUAL, etc.? -- Jerry James http://www.jamezone.org/ From tcallawa at redhat.com Thu Jul 2 18:32:02 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 02 Jul 2009 14:32:02 -0400 Subject: rawhide report: 20090702 changes In-Reply-To: <1246558225.25852.208.camel@vaio.local.net> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <20090702164310.GA30611@nostromo.devel.redhat.com> <1246558225.25852.208.camel@vaio.local.net> Message-ID: <4A4CFD22.2060303@redhat.com> On 07/02/2009 02:10 PM, Adam Williamson wrote: > On Thu, 2009-07-02 at 12:43 -0400, Bill Nottingham wrote: >> I'm not sure how distributable the KJV is or isnt' > > It's been out of copyright for some little time, now. Probably.(*) > > * Of course, one could potentially make some quite interesting legal > arguments about the author credit, and whether said author counts as > 'living' within the terms of copyright laws that grant copyright during > the lifetime of the author... Translations are generally considered to by copyrighted, even when the original work may not be. Regardless, we're not including religious texts in Fedora as content. Period. ~spot From sundaram at fedoraproject.org Thu Jul 2 18:33:03 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 03 Jul 2009 00:03:03 +0530 Subject: (A)synchronous file operations & xdg-open In-Reply-To: <870180fe0907021130l34fe18bcmff0fd5fac24c82b5@mail.gmail.com> References: <870180fe0906250849h5f103e83g8b90bc00d73f2f47@mail.gmail.com> <200906252132.08976.ville.skytta@iki.fi> <870180fe0907021130l34fe18bcmff0fd5fac24c82b5@mail.gmail.com> Message-ID: <4A4CFD5F.7090805@fedoraproject.org> On 07/03/2009 12:00 AM, Jerry James wrote: > > I am more and more of the opinion that xdg-open is simply the wrong > tool for viewing/editing temporary files. It wasn't built for that > use case, and the tools it invokes were not either. I think we need > something different altogether. Should we go back to invoking > $EDITOR, $VISUAL, etc.? ... or talk to the xdg-utils upstream developers and see if we can get a new tool added that serves our purpose. Rahul From cweyl at alumni.drew.edu Thu Jul 2 18:35:06 2009 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Thu, 2 Jul 2009 11:35:06 -0700 Subject: rawhide report: 20090702 changes In-Reply-To: <20090702164310.GA30611@nostromo.devel.redhat.com> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <20090702164310.GA30611@nostromo.devel.redhat.com> Message-ID: <7dd7ab490907021135t504fc95doeeddf56340cd5178@mail.gmail.com> On Thu, Jul 2, 2009 at 9:43 AM, Bill Nottingham wrote: > Of course, I suspect we'll now have someone claiming that the camel > book is actually a religous text. > So say we all! :) -Chris -- Chris Weyl Ex astris, scientia -------------- next part -------------- An HTML attachment was scrubbed... URL: From walters at verbum.org Thu Jul 2 18:47:06 2009 From: walters at verbum.org (Colin Walters) Date: Thu, 2 Jul 2009 14:47:06 -0400 Subject: (A)synchronous file operations & xdg-open In-Reply-To: <870180fe0907021130l34fe18bcmff0fd5fac24c82b5@mail.gmail.com> References: <870180fe0906250849h5f103e83g8b90bc00d73f2f47@mail.gmail.com> <200906252132.08976.ville.skytta@iki.fi> <870180fe0907021130l34fe18bcmff0fd5fac24c82b5@mail.gmail.com> Message-ID: On Thu, Jul 2, 2009 at 2:30 PM, Jerry James wrote: > > > I am more and more of the opinion that xdg-open is simply the wrong > tool for viewing/editing temporary files. ?It wasn't built for that > use case, and the tools it invokes were not either. I think the easiest fix here is for the app not to delete the temporary file immediately after the helper exits. Just write it in $TMPDIR and let tempreaper come along and eat it later. From linuxhippy at gmail.com Thu Jul 2 19:02:31 2009 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Thu, 2 Jul 2009 15:02:31 -0400 Subject: Missing libxklavier.so.12 dependency Message-ID: <194f62550907021202t12732b23i83f621875d2b96a7@mail.gmail.com> Hi, For a few days now updating rawhide doesn't work, because it misses a dependency: kdebase-workspace-4.2.95-3.fc12.i586 from rawhide has depsolving problems --> Missing Dependency: libxklavier.so.12 is needed by package kdebase-workspace-4.2.95-3.fc12.i586 (rawhide) Error: Missing Dependency: libxklavier.so.12 is needed by package kdebase-workspace-4.2.95-3.fc12.i586 (rawhide) 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 this anything to worry about my system, or will that be fixed anyway? Thanks, Clemens From loganjerry at gmail.com Thu Jul 2 19:06:18 2009 From: loganjerry at gmail.com (Jerry James) Date: Thu, 2 Jul 2009 13:06:18 -0600 Subject: (A)synchronous file operations & xdg-open In-Reply-To: References: <870180fe0906250849h5f103e83g8b90bc00d73f2f47@mail.gmail.com> <200906252132.08976.ville.skytta@iki.fi> <870180fe0907021130l34fe18bcmff0fd5fac24c82b5@mail.gmail.com> Message-ID: <870180fe0907021206xc5ae3bcl97e5cec5f7c6f522@mail.gmail.com> On Thu, Jul 2, 2009 at 12:47 PM, Colin Walters wrote: > I think the easiest fix here is for the app not to delete the > temporary file immediately after the helper exits. ?Just write it in > $TMPDIR and let tempreaper come along and eat it later. I am an XEmacs developer, and I would like to fix this upstream. We may have users on systems with xdg-open but without tmpreaper. I'll take that discussion to the upstream list, however. Thanks for the suggestion. -- Jerry James http://www.jamezone.org/ From erik at vanpienbroek.nl Thu Jul 2 19:07:04 2009 From: erik at vanpienbroek.nl (Erik van Pienbroek) Date: Thu, 02 Jul 2009 21:07:04 +0200 Subject: mingw32 debuginfo packages without sources, build id In-Reply-To: <200907012102.47030.ville.skytta@iki.fi> References: <200907012102.47030.ville.skytta@iki.fi> Message-ID: <1246561624.3029.13.camel@alguno.terneuzen.openftd.org> Op woensdag 01-07-2009 om 21:02 uur [tijdzone +0300], schreef Ville Skytt?: > Hello, > > I noticed a bunch of mingw32*-debuginfo packages that contain only *.debug (no > sources, no build id) appeared in Rawhide. Is this how mingw32 debuginfo > packages are supposed to look like, or is the infrastructure for creating the > debuginfo packages not quite complete, or are these packaging bugs? > > mingw32-boost-debuginfo-1.39.0-2.fc12.noarch > mingw32-cairomm-debuginfo-1.8.0-3.fc12.noarch > mingw32-glib2-debuginfo-2.21.2-2.fc12.noarch > mingw32-glibmm24-debuginfo-2.20.0-4.fc12.noarch > mingw32-gtkmm24-debuginfo-2.16.0-2.fc12.noarch > mingw32-libglade2-debuginfo-2.6.4-3.fc12.noarch > mingw32-libglademm24-debuginfo-2.6.7-7.fc12.noarch > mingw32-libgnurx-debuginfo-2.5.1-5.fc12.noarch > mingw32-libsigc++20-debuginfo-2.2.2-8.fc12.noarch > mingw32-libsqlite3x-debuginfo-20071018-8.fc12.noarch > mingw32-libxml++-debuginfo-2.26.0-2.fc12.noarch > mingw32-pangomm-debuginfo-2.24.0-3.fc12.noarch > mingw32-plotmm-debuginfo-0.1.2-3.fc12.noarch > mingw32-qt-debuginfo-4.5.2-1.fc12.noarch > mingw32-qwt-debuginfo-5.1.1-8.fc12.noarch > mingw32-sqlite-debuginfo-3.6.14.2-1.fc12.noarch > mingw32-tcl-debuginfo-8.5.7-6.fc12.noarch > mingw32-wpcap-debuginfo-4.1.beta5-6.fc12.noarch > mingw32-zfstream-debuginfo-20041202-6.fc12.noarch Hi, The implementation of mingw32 debuginfo packages has recently been discussed on the Fedora-MinGW mailing list: http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-June/001613.html At the moment we just started experimenting with it in rawhide and we haven't really got to thorough testing yet (due to FUDCON and a bug in mash which has just been solved). Initially only two mingw32 packages should have got -debuginfo support (just enough to perform tests), but due to a small mis-communication several other packages also got updated. I think it's best to continue this discussion on the fedora-mingw mailing list instead of fedora-devel. There indeed are some issues remaining which need to be solved. Regards, Erik van Pienbroek From ajax at redhat.com Thu Jul 2 19:07:47 2009 From: ajax at redhat.com (Adam Jackson) Date: Thu, 02 Jul 2009 15:07:47 -0400 Subject: Missing libxklavier.so.12 dependency In-Reply-To: <194f62550907021202t12732b23i83f621875d2b96a7@mail.gmail.com> References: <194f62550907021202t12732b23i83f621875d2b96a7@mail.gmail.com> Message-ID: <1246561667.25343.8611.camel@atropine.boston.devel.redhat.com> On Thu, 2009-07-02 at 15:02 -0400, Clemens Eisserer wrote: > Hi, > > For a few days now updating rawhide doesn't work, because it misses a > dependency: > > kdebase-workspace-4.2.95-3.fc12.i586 from rawhide has depsolving problems > --> Missing Dependency: libxklavier.so.12 is needed by package > kdebase-workspace-4.2.95-3.fc12.i586 (rawhide) > Error: Missing Dependency: libxklavier.so.12 is needed by package > kdebase-workspace-4.2.95-3.fc12.i586 (rawhide) > 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 this anything to worry about my system, or will that be fixed anyway? Known breakage, announced here: https://www.redhat.com/archives/fedora-devel-list/2009-July/msg00031.html and fixed here: * Wed Jul 01 2009 Rex Dieter 4.2.95-4 - rebuild (libxklavier) - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jamatos at fc.up.pt Thu Jul 2 19:43:44 2009 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Thu, 2 Jul 2009 20:43:44 +0100 Subject: TeX Live 2008 available for testing In-Reply-To: <20090627124142.GA32345@pucmeloud.redhat.com> References: <20090627124142.GA32345@pucmeloud.redhat.com> Message-ID: <200907022043.45143.jamatos@fc.up.pt> On Saturday 27 June 2009 13:41:42 Jindrich Novy wrote: > Good news everyone! > > I've invented a device that installs TeX Live 2008 on your Fedora! > > > TeX Live 2008 is now packaged and available for testing. It is not in > Fedora yet because it requires reviews of couple of packages. But you > can test it before it happens. First of all I would like to thank for the amazing job you have done. Even if most of the work is automatically generated it is not an easy task by any measure. :-) With all that work coming for F12 it would be a bonus if we could come with a set of rules for packaging tex projects. Those guidelines could then go to FPC for approval. With the amount of packages coming now is the time to get this right. One of the issues discussed before but never set is the name space to be used. If I remember the rough consensus was to name packages as tex-packagename or even tex-latex-packagename. Even the packages retain the same name as they are now in your repo you could add a (virtual) Provides so that if later, for any reason, we change the tex distribution we don't need to change every involved package. What is your plan? To use the wiki Feature page as the place of contact for further actions or something else... > Thanks, > Jindrich Regards, -- Jos? Ab?lio From jamatos at fc.up.pt Thu Jul 2 19:44:45 2009 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Thu, 2 Jul 2009 20:44:45 +0100 Subject: TeX Live 2008 available for testing In-Reply-To: <20090627231310.GA2752@pucmeloud.redhat.com> References: <20090627124142.GA32345@pucmeloud.redhat.com> <200906271527.02139.jamatos@fc.up.pt> <20090627231310.GA2752@pucmeloud.redhat.com> Message-ID: <200907022044.46110.jamatos@fc.up.pt> On Sunday 28 June 2009 00:13:10 Jindrich Novy wrote: > Currently texlive correctly obsoletes all the old tetex* stuff. I > thought it is a good idea to not to provide the old tetex bits any more > because we have virtual provides for them like tex(latex) or tex(dvips) for > a long time. So it is better to fix the requires on the packages side > requiring TeX. Note that this will work even with the current old > texlive-2007 present in Fedoras. Thanks for the list of packages that > needs to be fixed. Should I bug the respective maintainers? :-) > evince-dvi will need rebuild for the libkpathsea soname bump as soon > as new texlive lands in Fedora. > > Jindrich -- Jos? Ab?lio From loganjerry at gmail.com Thu Jul 2 20:52:29 2009 From: loganjerry at gmail.com (Jerry James) Date: Thu, 2 Jul 2009 14:52:29 -0600 Subject: Updates can't handle multiple bug #s? Message-ID: <870180fe0907021352q402c7c4bm84e7ba98e1978d99@mail.gmail.com> I just submitted this update: https://admin.fedoraproject.org/updates/edit/xemacs-21.5.29-1.fc11, which is supposed to close two bugs. When I submitted it, I got this: 500 Internal error The server encountered an unexpected condition which prevented it from fulfilling the request. I checked "My updates" before retyping the whole thing and, sure enough, there it is, but with only 1 of the two bug numbers I tried to enter. I've tried editing it several times now, always with an internal server error and no change to the update as a result. I've tried entering the two bug numbers as "xxx xxx", "xxx,xxx", and "#xxx,#xxx", but no joy. -- Jerry James http://www.jamezone.org/ From ville.skytta at iki.fi Thu Jul 2 21:46:04 2009 From: ville.skytta at iki.fi (Ville =?windows-1252?q?Skytt=E4?=) Date: Fri, 3 Jul 2009 00:46:04 +0300 Subject: New maintainer needed: dumpasn1, freedroid, http_ping, id3v2, pscan, zzuf In-Reply-To: <954b158e0907011826o5d9013aag85f537370cac2999@mail.gmail.com> References: <200907012321.43913.ville.skytta@iki.fi> <954b158e0907011826o5d9013aag85f537370cac2999@mail.gmail.com> Message-ID: <200907030046.05420.ville.skytta@iki.fi> On Thursday 02 July 2009, Xia Shing Zee wrote: > I'm a new package maintainer, but I'll try dumpasn1 and id3v2 Thanks (ditto to the others who grabbed the rest of the packages). Please go ahead and take ownership of these in pkgdb, they have been orphaned already. From ville.skytta at iki.fi Thu Jul 2 21:49:13 2009 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Fri, 3 Jul 2009 00:49:13 +0300 Subject: mingw32 debuginfo packages without sources, build id In-Reply-To: <1246561624.3029.13.camel@alguno.terneuzen.openftd.org> References: <200907012102.47030.ville.skytta@iki.fi> <1246561624.3029.13.camel@alguno.terneuzen.openftd.org> Message-ID: <200907030049.13620.ville.skytta@iki.fi> On Thursday 02 July 2009, Erik van Pienbroek wrote: > The implementation of mingw32 debuginfo packages has recently been > discussed on the Fedora-MinGW mailing list: > http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-June/001613.html [...] > I think it's best to continue this discussion on the fedora-mingw > mailing list instead of fedora-devel. There indeed are some issues > remaining which need to be solved. Ok, thanks for the info. I don't think I have much to add to those discussions, I'm just doing some semi-regular grunt work watching debuginfos for sanity and wanted to know whether bugs should be filed against the affected packages, but I gather not at this point as there seems to be some work in progress. From erik at vanpienbroek.nl Thu Jul 2 22:46:13 2009 From: erik at vanpienbroek.nl (Erik van Pienbroek) Date: Fri, 03 Jul 2009 00:46:13 +0200 Subject: mingw32 debuginfo packages without sources, build id In-Reply-To: <200907030049.13620.ville.skytta@iki.fi> References: <200907012102.47030.ville.skytta@iki.fi> <1246561624.3029.13.camel@alguno.terneuzen.openftd.org> <200907030049.13620.ville.skytta@iki.fi> Message-ID: <1246574773.3029.43.camel@alguno.terneuzen.openftd.org> Op vrijdag 03-07-2009 om 00:49 uur [tijdzone +0300], schreef Ville Skytt?: > On Thursday 02 July 2009, Erik van Pienbroek wrote: > > > The implementation of mingw32 debuginfo packages has recently been > > discussed on the Fedora-MinGW mailing list: > > http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-June/001613.html > [...] > > I think it's best to continue this discussion on the fedora-mingw > > mailing list instead of fedora-devel. There indeed are some issues > > remaining which need to be solved. > > Ok, thanks for the info. I don't think I have much to add to those > discussions, I'm just doing some semi-regular grunt work watching debuginfos > for sanity and wanted to know whether bugs should be filed against the > affected packages, but I gather not at this point as there seems to be some > work in progress. Perhaps you might want to read http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-July/001811.html which sums up my tests of these -debuginfo packages. Some help with adding MinGW32 / PE binaries support to the RPM tool debugedit (/usr/lib/rpm/debugedit) is really welcome. Regards, Erik van Pienbroek From mcepl at redhat.com Thu Jul 2 22:57:30 2009 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 2 Jul 2009 22:57:30 +0000 (UTC) Subject: rawhide report: 20090702 changes References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <20090702164310.GA30611@nostromo.devel.redhat.com> Message-ID: Jason L Tibbitts III, Thu, 02 Jul 2009 12:32:48 -0500: > Open a ticket on their trac (https://fedorahosted.org/fesco/). Hmm, it *is* complicated. > The issue here is that the guidelines explicitly permit documentation > and help files; diveintopython is obviously documenting Python, and if > it was bundled with the Python tarball then there wouldn't be any > question at all about this. So I'm not really sure that the place where > you draw the line is all that clear. Well, I always understood, that documentation which is part of normal package is OK, but source package which contains nothing else than documentation isn't. But then yes we have man-pages. Hmm. Any thoughts? Mat?j From christoph.wickert at googlemail.com Thu Jul 2 23:23:14 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Fri, 03 Jul 2009 01:23:14 +0200 Subject: rawhide report: 20090702 changes In-Reply-To: <20090702134846.GH9871@localhost.localdomain> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <4A4CABD5.4030104@gmail.com> <4A4CAC4B.8070600@fedoraproject.org> <20090702134846.GH9871@localhost.localdomain> Message-ID: <1246576994.2635.6.camel@localhost> Am Donnerstag, den 02.07.2009, 09:48 -0400 schrieb Paul W. Frields: > On Thu, Jul 02, 2009 at 02:52:59PM +0200, Thomas Janssen wrote: > > 2009/7/2 Rahul Sundaram : > > > On 07/02/2009 06:15 PM, Frank Murphy wrote: > > > > > >> Is there a book group? > > >> or what search parameter? > > >> Tried yum info "Dive Into Python" > > > > > > # yum info diveintopython > > > > > > Since we have more than one book, I guess a new group could be defined > > > as well. If there is consensus on the name, I can add it. Should we just > > > call it "Books" ? > > > > +1 > > Perhaps something more inclusive like "Documentation" would be good. +1 for "Documentation", -1 for "Books". Books is to generic on the one hand but to graphic on the other (These are no real books). Documentation fits very well and it already is a group in rpm, so IMO we should stick with that. Regards, Christoph From christoph.wickert at googlemail.com Thu Jul 2 23:26:12 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Fri, 03 Jul 2009 01:26:12 +0200 Subject: rawhide report: 20090702 changes In-Reply-To: <4A4CF0F9.1060701@fedoraproject.org> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <4A4CABD5.4030104@gmail.com> <4A4CAC4B.8070600@fedoraproject.org> <20090702134846.GH9871@localhost.localdomain> <4A4CF0F9.1060701@fedoraproject.org> Message-ID: <1246577172.2635.12.camel@localhost> Am Donnerstag, den 02.07.2009, 23:10 +0530 schrieb Rahul Sundaram: > On 07/02/2009 09:33 PM, Thomas Janssen wrote: ... > > "Books and Guides" even better. > > Committed for Fedora 12. Correct me if I'm wrong, but new groups in comps are expected to be ratified by FESCo. > Rahul Regards, Christoph From johannbg at hi.is Thu Jul 2 23:22:33 2009 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Thu, 02 Jul 2009 23:22:33 +0000 Subject: Dracut now has a wiki page in the Fedora wiki... Message-ID: <4A4D4139.706@hi.is> The Dracut wiki page has now been moved from my drafts to it's permanent location. https://fedoraproject.org/wiki/Dracut Debugging can be found here https://fedoraproject.org/wiki/Dracut/Debugging Note i'm not sure if the http://fedoraproject.org/wiki/Dracut#Getting_the_Source containst correct git commands hence I've label them #FIXME the maintainer(s) can confirm or fix the entry's It would be nice if someone who actually who's primary language is English reviews and fixes potential ken lee entry's i've made. JBG From cweyl at alumni.drew.edu Thu Jul 2 23:32:32 2009 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Thu, 2 Jul 2009 16:32:32 -0700 Subject: rawhide report: 20090702 changes In-Reply-To: <1246577172.2635.12.camel@localhost> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <4A4CABD5.4030104@gmail.com> <4A4CAC4B.8070600@fedoraproject.org> <20090702134846.GH9871@localhost.localdomain> <4A4CF0F9.1060701@fedoraproject.org> <1246577172.2635.12.camel@localhost> Message-ID: <7dd7ab490907021632q2cb5126em73a59518306c3c7b@mail.gmail.com> On Thu, Jul 2, 2009 at 4:26 PM, Christoph Wickert < christoph.wickert at googlemail.com> wrote: > Am Donnerstag, den 02.07.2009, 23:10 +0530 schrieb Rahul Sundaram: > > On 07/02/2009 09:33 PM, Thomas Janssen wrote: > ... > > > "Books and Guides" even better. > > > > Committed for Fedora 12. > > Correct me if I'm wrong, but new groups in comps are expected to be > ratified by FESCo. > If memory serves, the admonition is "use good judgement, and talk about it on -devel first." -Chris -- Chris Weyl Ex astris, scientia -------------- next part -------------- An HTML attachment was scrubbed... URL: From tibbs at math.uh.edu Thu Jul 2 23:41:46 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 02 Jul 2009 18:41:46 -0500 Subject: rawhide report: 20090702 changes In-Reply-To: (Matej Cepl's message of "Thu\, 2 Jul 2009 22\:57\:30 +0000 \(UTC\)") References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <20090702164310.GA30611@nostromo.devel.redhat.com> Message-ID: >>>>> "MC" == Matej Cepl writes: MC> Well, I always understood, that documentation which is part of MC> normal package is OK, but source package which contains nothing MC> else than documentation isn't. If that was the case, then I see 17 -docs packages that build completely separately from any other package. Some upstreams package their documentation in separate tarballs, and so these can be built from separate source packages. (And often this makes sense, as the documentation package doesn't have to change when a bug is fixed in the main package.) So you could have a rule that says the package has to directly document some program in the distro, but then the Linux device drivers book does just that. I don't think anyone would reasonably want to exclude the python-docs package (built as a separate source package containing nothing other than documentation) but I know I can't articulate just how diveintopython is different. Honestly I think this would be easier if we had a separate content repository, because then the decision wouldn't be about excluding some things completely but instead about which repository to put them in. I recall some discussion about that but I don't know what the end result was. Honestly I don't care either way except that I need to know what to do with this javanotes review ticket I've taken; I'd just like to be able to point people to a clear decision. - J< From sundaram at fedoraproject.org Fri Jul 3 04:24:35 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 03 Jul 2009 09:54:35 +0530 Subject: rawhide report: 20090702 changes In-Reply-To: <1246577172.2635.12.camel@localhost> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <4A4CABD5.4030104@gmail.com> <4A4CAC4B.8070600@fedoraproject.org> <20090702134846.GH9871@localhost.localdomain> <4A4CF0F9.1060701@fedoraproject.org> <1246577172.2635.12.camel@localhost> Message-ID: <4A4D8803.904@fedoraproject.org> On 07/03/2009 04:56 AM, Christoph Wickert wrote: > Am Donnerstag, den 02.07.2009, 23:10 +0530 schrieb Rahul Sundaram: >> On 07/02/2009 09:33 PM, Thomas Janssen wrote: > ... >>> "Books and Guides" even better. >> >> Committed for Fedora 12. > > Correct me if I'm wrong, but new groups in comps are expected to be > ratified by FESCo. Groups don't go through FESCo ratification. http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups#New_groups Rahul From fedora at leemhuis.info Fri Jul 3 04:30:56 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 03 Jul 2009 06:30:56 +0200 Subject: FESCo meeting summary for 2009-06-26 In-Reply-To: References: <200906291314.19557.mhlavink@redhat.com> <571dcba60906290420v4720785gac13b28fab0f8d3e@mail.gmail.com> <20090629160913.GD32653@nostromo.devel.redhat.com> <4A4C8903.3000302@gdt.id.au> <20090702154346.GC26481@nostromo.devel.redhat.com> Message-ID: <4A4D8980.50704@leemhuis.info> On 02.07.2009 18:54, drago01 wrote: > On Thu, Jul 2, 2009 at 5:43 PM, Bill Nottingham wrote: >> Glen Turner (gdt at gdt.id.au) said: >>>> That's a really crappy place for that message, though. What's the user >>>> supposed to do there... reboot and then go download another 700MB - 4GB? >>> >>> Yes it's a crappy place. I knew that when I suggested it. I just couldn't >>> think of a Javascript hack which would cough up the CPU features even when >>> running under a 32b OS like Windows Xp. Suggestions welcomed. >> >> Dual-arch media. (Which is a pain, and will run into space issues sooner >> or later.) > > I don't see this as an issue for live media (if it is possible to do here). > > We have 700MB x 2 = 1400MB out of 4GB which we can ship on a DVD. > > We can provide an extra link "download CD" if someone really still has > no dvd burner / drive in 2009. Such a dual-arch disc afaics also would be quite interesting for publishing companies that might want to deliver Fedora on a DVD together with their magazines. Otherwise they will definitely chose x86-32, as that's what runs on most systems. CU knurd From ghosler at redhat.com Fri Jul 3 09:34:17 2009 From: ghosler at redhat.com (Gregory Hosler) Date: Fri, 03 Jul 2009 17:34:17 +0800 Subject: Building packages for EPEL In-Reply-To: <200906210440.27401.dennis@ausil.us> References: <200906210440.27401.dennis@ausil.us> Message-ID: <4A4DD099.40207@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dennis Gilmore wrote: > EPEL is now using koji to build instead of plague. please make sure that you > update th common directory in your checkout to pick up the needed changes to > submit builds. I was able to do builds for EL-4/EL-5 using koji. thanks a lot! > Bodhi support will come early next week to issue updates. Please let us know as and when "make update" will be available. Until then, what is the alternative? http://admin.fedoraproject.org/updates ? Thanks a lot, - -Greg > the buildroots are only populated by packages from stable if you need to build > against something in testing or that you have just build please email your > request to epel-releng at lists.fedoraproject.org > > > thanks > > Dennis > > > ------------------------------------------------------------------------ > > _______________________________________________ > Fedora-devel-announce mailing list > Fedora-devel-announce at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-announce - -- +---------------------------------------------------------------------+ Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler ghosler at redhat.com | +---------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkpN0JcACgkQ404fl/0CV/T1LwCfZhc7U9ZvPeI8yafQX6SI8/gT lFYAoLJXluDxeH4qMWs6n0nlHLS2xJoO =w4dv -----END PGP SIGNATURE----- From awilliam at redhat.com Fri Jul 3 09:43:34 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 03 Jul 2009 10:43:34 +0100 Subject: Dracut now has a wiki page in the Fedora wiki... In-Reply-To: <4A4D4139.706@hi.is> References: <4A4D4139.706@hi.is> Message-ID: <1246614214.25852.239.camel@vaio.local.net> On Thu, 2009-07-02 at 23:22 +0000, "J?hann B. Gu?mundsson" wrote: > The Dracut wiki page has now been moved from my drafts to it's permanent > location. > > https://fedoraproject.org/wiki/Dracut > > Debugging can be found here > > https://fedoraproject.org/wiki/Dracut/Debugging > > Note i'm not sure if the > http://fedoraproject.org/wiki/Dracut#Getting_the_Source containst > correct git commands hence I've label them #FIXME the maintainer(s) can > confirm or fix the entry's Thanks for this! "tar xzf dracut-$version.tar.bz2" This won't work. z means 'this is a gzip formatted archive'. The letter for bzip2 is j, so you could do: "tar xjf dracut-$version.tar.bz2" but it's actually a lot less trouble to just do: "tar xf dracut-$version.tar.bz2" which auto-detects the archive type. It's much easier to just let it be handled by autodetection, and only bother specifying the archive type manually if the autodetection trips up. > It would be nice if someone who actually who's primary language is > English reviews and fixes potential ken lee entry's i've made. Haha, 'ken lee entries' needs to go into common usage :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From lxtnow at gmail.com Fri Jul 3 09:50:20 2009 From: lxtnow at gmail.com (SmootherFrOgZ) Date: Fri, 3 Jul 2009 11:50:20 +0200 Subject: Building packages for EPEL In-Reply-To: <4A4DD099.40207@redhat.com> References: <200906210440.27401.dennis@ausil.us> <4A4DD099.40207@redhat.com> Message-ID: <62bc09df0907030250q41c4f35j2e651e6795077ba7@mail.gmail.com> On Fri, Jul 3, 2009 at 11:34 AM, Gregory Hosler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dennis Gilmore wrote: >> EPEL is now using koji to build instead of plague. ?please make sure that you >> update th common directory in your checkout to pick up the needed changes to >> submit builds. > > I was able to do builds for EL-4/EL-5 using koji. thanks a lot! > >> Bodhi support will come early next week to issue updates. > > Please let us know as and when "make update" will be available. Until then, what > is the alternative? http://admin.fedoraproject.org/updates ? > "make update" goes to bodhi as well as "http://admin.fedoraproject.org/updates" which is bodhi UI. epel-releng will be taking care of the updates for now. -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB From awilliam at redhat.com Fri Jul 3 10:18:16 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 03 Jul 2009 11:18:16 +0100 Subject: Dracut now has a wiki page in the Fedora wiki... In-Reply-To: <4A4D4139.706@hi.is> References: <4A4D4139.706@hi.is> Message-ID: <1246616296.25852.241.camel@vaio.local.net> On Thu, 2009-07-02 at 23:22 +0000, "J?hann B. Gu?mundsson" wrote: > It would be nice if someone who actually who's primary language is > English reviews and fixes potential ken lee entry's i've made. I did a copyedit on the page, correcting a few errors, using lists and templates more consistently, moving most of the 'introduction' into a named section so it doesn't eat up the entire top of the page, using links to User pages for the author list and just generally cleaning up. Hope you find it an improvement. Thanks for working on this! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From mlichvar at redhat.com Fri Jul 3 10:27:47 2009 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Fri, 3 Jul 2009 12:27:47 +0200 Subject: readline update? Message-ID: <20090703102747.GA32668@localhost> I'd like to update readline to the latest version 6.0. The problem is that the license was changed to GPLv3+ and we have some GPLv2 packages using readline. A possible replacement is the editline library which provides a compatible interface and is licensed under BSD, unfortunately it doesn't handle UTF-8. Are we stuck with readline 5.2? Suggestions? The package list is: GMT-4.4.0-2.fc11 Macaulay2-1.2-4.fc12 afpfs-ng-0.8.1-2.fc11 bti-015-1.fc11 calc-2.12.2.1-13.fc11 callweaver-1.2.0.1-3.fc11 cgdb-0.6.4-4.fc11 chrony-1.23-5.20081106gitbe42b4.fc12 clisp-2.47-3.fc11 coda-6.9.4-2.fc11 devtodo-0.1.20-3.fc12 fityk-0.8.1-14.fc10 gnu-smalltalk-3.1-5.fc12 gnubg-0.9.0.1-7.fc11 gnuplot-4.2.5-4.fc12 grass-6.3.0-12.fc11 kdeedu-4.2.95-1.fc12 ktechlab-0.3.70-1.20090304svn.fc11 lvm2-2.02.48-1.fc12 maxima-5.18.1-3.fc12 ocfs2-tools-1.3.9-10.20080221git.fc11 socat-1.7.0.0-2.fc11 -- Miroslav Lichvar From sundaram at fedoraproject.org Fri Jul 3 10:30:02 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 03 Jul 2009 16:00:02 +0530 Subject: readline update? In-Reply-To: <20090703102747.GA32668@localhost> References: <20090703102747.GA32668@localhost> Message-ID: <4A4DDDAA.80103@fedoraproject.org> On 07/03/2009 03:57 PM, Miroslav Lichvar wrote: > I'd like to update readline to the latest version 6.0. The problem is > that the license was changed to GPLv3+ and we have some GPLv2 packages > using readline. > > A possible replacement is the editline library which provides a > compatible interface and is licensed under BSD, unfortunately it > doesn't handle UTF-8. > > Are we stuck with readline 5.2? Suggestions? Have you talked to upstream and checked on what they suggest that we do about this? Rahul From mlichvar at redhat.com Fri Jul 3 10:37:51 2009 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Fri, 3 Jul 2009 12:37:51 +0200 Subject: readline update? In-Reply-To: <4A4DDDAA.80103@fedoraproject.org> References: <20090703102747.GA32668@localhost> <4A4DDDAA.80103@fedoraproject.org> Message-ID: <20090703103751.GC4109@localhost> On Fri, Jul 03, 2009 at 04:00:02PM +0530, Rahul Sundaram wrote: > On 07/03/2009 03:57 PM, Miroslav Lichvar wrote: > > I'd like to update readline to the latest version 6.0. The problem is > > that the license was changed to GPLv3+ and we have some GPLv2 packages > > using readline. > > > > A possible replacement is the editline library which provides a > > compatible interface and is licensed under BSD, unfortunately it > > doesn't handle UTF-8. > > > > Are we stuck with readline 5.2? Suggestions? > > Have you talked to upstream and checked on what they suggest that we do > about this? No. Some time ago they asked if there were any GPLv2 projects, I gave them a list, but they changed the license anyway. -- Miroslav Lichvar From johannbg at hi.is Fri Jul 3 10:57:31 2009 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Fri, 03 Jul 2009 10:57:31 +0000 Subject: Dracut now has a wiki page in the Fedora wiki... In-Reply-To: <1246616296.25852.241.camel@vaio.local.net> References: <4A4D4139.706@hi.is> <1246616296.25852.241.camel@vaio.local.net> Message-ID: <4A4DE41B.5060007@hi.is> On 07/03/2009 10:18 AM, Adam Williamson wrote: > On Thu, 2009-07-02 at 23:22 +0000, "J?hann B. Gu?mundsson" wrote: > > >> It would be nice if someone who actually who's primary language is >> English reviews and fixes potential ken lee entry's i've made. >> > > I did a copyedit on the page, correcting a few errors, using lists and > templates more consistently, moving most of the 'introduction' into a > named section so it doesn't eat up the entire top of the page, using > links to User pages for the author list and just generally cleaning up. > Hope you find it an improvement. Thanks for working on this! > I manage to catch Harald on irc yesterday he gladly filled me in what was needed on the report against this component so with swift action I created the page which leaves us with one less component to worry about now we only have ca 6999 to go... JBG -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschwendt at gmail.com Fri Jul 3 11:21:12 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 3 Jul 2009 13:21:12 +0200 Subject: rawhide report: 20090702 changes In-Reply-To: <4A4CC2AB.9010508@fedoraproject.org> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <4A4CABD5.4030104@gmail.com> <4A4CAC4B.8070600@fedoraproject.org> <4A4CC2AB.9010508@fedoraproject.org> Message-ID: <20090703132112.657c582c@noname.noname> On Thu, 02 Jul 2009 19:52:35 +0530, Rahul wrote: > On 07/02/2009 06:58 PM, Adam Miller wrote: > > +1 on the Books idea > > Does this look ok? > > --- comps-f12.xml.in.orig 2009-07-02 15:39:02.000000000 +0530 > +++ comps-f12.xml.in 2009-07-02 19:49:32.108616562 +0530 > @@ -520,6 +520,17 @@ > > > > + books > + <_name>Technical Books > + <_description/> > + false > + true > + > + diveintopython > + ldd-pdf > + > + > + > buildsys-build > <_name>Buildsystem building group > <_description/> > > Rahul No, it doesn't. First of all, in my opinion it doesn't make sense to separate "books" from other forms of documentation. Secondly, "samba-doc" is missing in above package list, and there are probably more "books" included in other packages. From rawhide at fedoraproject.org Fri Jul 3 12:04:44 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Fri, 3 Jul 2009 12:04:44 +0000 Subject: rawhide report: 20090703 changes Message-ID: <20090703120444.GA22599@releng2.fedora.phx.redhat.com> Compose started at Fri Jul 3 06:15:05 UTC 2009 New package perl-CGI-Application-Dispatch Dispatch requests to CGI::Application based objects New package perl-CGI-Application-Plugin-ConfigAuto Easy config file management for CGI::Application New package php-pear-HTML_Javascript Class for creating simple JS scripts New package pypar Parallel programming with Python Removed package hunspell-ee Updated Packages: PyQt4-4.5.1-2.fc12 ------------------ * Thu Jul 02 2009 Rex Dieter - 4.5.1-2 - fix build with qt-4.5.2 - PyQt4-devel multilib conflict (#509415) alsa-plugins-1.0.20-2.fc12 -------------------------- * Wed Jun 24 2009 Eric Moret - 1.0.20-2 - Added speex subpackage - Removed ascii-art from jack's plugin description amqp-1.0.790661-1.fc12 ---------------------- * Thu Jul 02 2009 Nuno Santos - 0:1.0.790661-1 - Rebased to svn rev 790661 anaconda-12.0-1.fc12 -------------------- * Thu Jul 02 2009 Chris Lumens - 12.0-1 - network --bootproto no longer implies DHCP. (clumens) - Don't unconditionally skip the network config screen in kickstart. (clumens) - Allow creating new groups through kickstart. (clumens) - Set focus on hostname entry in network UI screen (#494135) (rvykydal) - Fix upgrade selected in UI after storage reset (#503302) (rvykydal) - Add support for specifying upgrade partition in ks (#471232) (rvykydal) - Add missing liveinst/* files. (dcantrell) - Update code that checks for devices that contain install media. (dlehman) - Rework tracking of devices containing installation media. (#497087) (dlehman) - Add function storage.udev.udev_resolve_devspec. (dlehman) - Prevent false positives in devtree's device lookup methods. (dlehman) - Skip exceptionDisks if exn originated in devtree.populate. (#497240) (dlehman) - Stop using rhpl.arch in writeRpmPlatform() (katzj) - Move simpleconfig (back) into anaconda from rhpl (katzj) - Use iutil arch specifiers rather than rhpl (katzj) - Remove unused rhpl imports (katzj) - Switch to using iutil.isS390 instead of rhpl.getArch (katzj) - Stop using rhpl.translate (katzj) - Default to /boot on ext4 (katzj) - Allow /boot on ext4 now that we have a grub that allows it (katzj) - Make sure the library directory is always set (notting) - Write out "MAILADDR root" into mdadm.conf (#508321) (rvykydal) - Do not install grub more times than needed. (rvykydal) - Ensure we set the SELinux context correctly on symlinks (#505054) (katzj) - udev dropped vol_id (#506360) (katzj) - Handle installing multilib into the installer intramfs correctly. (notting) - Set LIBDIR appropriately on PPC64. (notting) - Fix grub upgrade (#505966) (rvykydal) - Include yum.log in anacdump.txt too. (rvykydal) - Access format options property instead of mountopts attr. (#506219) (dlehman) - Be more careful about identifying NFS fstab entries. (dlehman) - Don't add leading directory for files twice. (#503830) (dlehman) - booty changes for iswmd (Jacek.Danecki) - Support for MD containers. (Jacek.Danecki) - New iswmd parameter for kernel cmdline (Jacek.Danecki) - New udev rule for using mdadm for isw_raid_member (Jacek.Danecki) - Use isohybrid to make boot.iso a hybrid image (katzj) - Log yum messages. (rvykydal) - Tell booty to rescan for bootable drivers when an extra disks get added (hdegoede) - Do not encourage VNC when doing kickstart text installs (#506534) (dcantrell) - Rename bootstrap to autogen.sh (dcantrell) - Include the contents of /proc/cmdline in exception reports (katzj) - Include libwrap library for sshd and telnet in s390 installs (jgranado) - Enforcing matching rootfs type on LVs as well as for partitions (#504743) (katzj) - Remove problem packages before attempting a re-download (#501887). (clumens) - Be more explicit about what's lacking on EFI systems (#501341). (clumens) - If not enough memory is installed, enforce swap partition creation (#498742). (clumens) - Convert to using automake/autoconf. (dcantrell) - Convert po/ subdirectory to GNU gettext template system. (dcantrell) - Restructure liveinst/ for the new build system. (dcantrell) - Add m4/ subdirectory with autoconf macros. (dcantrell) - Removed py-compile script. (dcantrell) - Rename anaconda.spec to anaconda.spec.in (dcantrell) - Ignore autoconf and automake files in the tree. (dcantrell) - Removed toplevel Makefile and Makefile.inc (dcantrell) - Show MAC address of network device in combo box (#504216) (dcantrell) - Remove loader/tr/.cvsignore (dcantrell) - Increase max NIC identification duration to 5 minutes (#473747). (dcantrell) - Use /sbin/ipcalc for IP address validation (#460579) (dcantrell) - Fix an obvious traceback when doing part --ondisk= (#504687). (clumens) - Catch errors from bootloader installation (#502210). (clumens) - Remove umask temporarily so device permissions are correct (#383531, wmealing). - Remove the name check on driver disk packages (#472951). (clumens) - Make the installation key text more descriptive (#474375). (clumens) - Fix discovery of existing raid/lvm for ks install without clearpart (#503310, #503681) (rvykydal) - Use the F12 version of the bootloader command. (clumens) - It's /sbin/fsadm, not /sbin/e2fsadm (#504043). (clumens) - Remove the bootloader --lba32 option. (clumens) - Use gettext.ldngettext when necessary (#467603) (dcantrell) - Test NM_CONTROLLED setting correctly in network.py (#502466) (dcantrell) - Show unknown partitions as "Unknown" in partition editor. (dcantrell) - Add a type hint on popup windows (rstrode). (clumens) - Use the F12 version of the driverdisk command. (clumens) - Remove driverdisk --type, since mount can figure that out. (clumens) - Fix an error when editing an unreachable repo (#503454). (clumens) - If /etc/rpm/platform is found, move it out of the way. (clumens) - We no longer write out /etc/rpm/platform, so don't offer to upgrade it. (clumens) - Remove locals containing "passphrase" or "password" from exns (#503442). (clumens) - Make progress bars modal (#493263, #498553, rstrode). (clumens) - Make sure to import os.path if we are going to use it. (jgranado) - ipcalc is copied to /usr/lib. (jgranado) - Limit the trigger to block type devices. (jgranado) - We need ipcalc for new s390 installation script. (jgranado) - Fix off-by-one errors in read. (notting) - sysconfig file changed names for system-config-firewall (katzj) - Don't write out firewall settings if they already exist (#502479) (katzj) - Make sure that the devices are correctly detected (#491700) (jgranado) - Make the save-to-bugzilla dupe detection smarter. (clumens) - If network --device=MAC is given, translate to device name (#185522). (clumens) - Add a function to convert MAC addresses to device names. (clumens) - Move /boot checks from sanityCheck into Platform.checkBootRequest. (clumens) - Return translated strings from checkBootRequest. (clumens) - Check that /boot is on a Mac disk label for PPC installs (#497745). (clumens) - Call checkBootRequest from sanityCheck. (clumens) - Put some space in that big scary warning. (clumens) - fond -> found (clumens) - Use powers of two in swapSuggestion (#463885). (clumens) - Trim "mapper/" off device names in the bootloader UI (#501057). (clumens) - Make the weak password dialog comply with the HIG (#487435). (clumens) - Add a newline to a cmdline mode string (#497575). (clumens) * Tue Jun 02 2009 Chris Lumens - 11.5.0.59-1 - Do not show disabled repos such as rawhide during the install (#503798). (jkeating) * Sun May 31 2009 David Lehman - 11.5.0.58-1 - Pass --force to lvresize so it doesn't ask for confirmation. (dlehman) - Fix a typo in action sorting for resize actions (fs vs. device). (#501000) (dlehman) - Sending translation for French (mrtom) * Thu May 28 2009 Chris Lumens - 11.5.0.57-1 - Create and use unique ids for Device instances. (#500808) (dlehman) - Adjust remaining PartitionDevices' names after removing a partition. (dlehman) * Tue May 26 2009 Chris Lumens - 11.5.0.55-1 - Fix blank network device descriptions in the loader. (#501757) (notting) - Make sure the right _isMigratable gets used for Ext3FS (#501585). (clumens) * Tue May 26 2009 Chris Lumens - 11.5.0.56-1 - Ensure matching rootfs type to live type with autopart (#501876) (katzj) * Tue May 19 2009 Chris Lumens - 11.5.0.54-1 - We are not guaranteed to have a partedDisk in the udev code (#501556, - The location of the options wiki page has changed. (clumens) - Disable BETANAG. (clumens) - Install a en_US.UTF-8 locale in the first stage image. (notting) - Reset font when changing language. (notting) - Set locale to en_US.UTF-8 when initializing the console. (notting) anki-0.9.9.8.4-1.fc12 --------------------- * Thu Jul 02 2009 Christian Krause - 0.9.9.8.4-1 - Update to new upstream version 0.9.9.8.4 - fix one %lang tag at-spi-1.26.0-2.fc12 -------------------- * Thu Jul 02 2009 Matthias Clasen - 1.26.0-2 - Rebuild audacious-plugins-1.5.1-10.fc12 ------------------------------- * Thu Jul 02 2009 Michael Schwendt - 1.5.1-10 - Prevent alsalib mixer crash if mixer isn't ready. banshee-mirage-0.5.0-3.fc12 --------------------------- * Thu Jul 02 2009 Paul Lange - 0.5.0-3 - Fix translation conflicts with mirage (#506145) boost-1.39.0-3.fc12 ------------------- * Thu Jul 02 2009 Petr Machata - 1.39.0-3 - Drop file list for main "boost" package, which was inadvertently left in. - Add thread sub-package to capture omitted boost_thread. - Add upstream patch to make boost_filesystem compatible with C++0x. - Resolves: #496188 - Resolves: #509250 curl-7.19.5-5.fc12 ------------------ * Thu Jul 02 2009 Kamil Dudka 7.19.5-5 - run test suite after build - enable built-in manual devhelp-0.23-7.fc12 ------------------- * Thu Jul 02 2009 Matthias Clasen - 0.23-7 - Shrink GConf schemas dhcp-4.1.0-22.fc12 ------------------ * Wed Jul 01 2009 David Cantrell - 12:4.1.0-22 - Set permissions on /etc/dhcp to 0750 (#508247) - Update to new ldap-for-dhcp patch set - Correct problems when upgrading from a previous release and your dhcpd.conf file not being placed in /etc/dhcp (#506600) directfb-1.4.0-1.fc12.1 ----------------------- dracut-0.3-1.fc12 ----------------- * Thu Jul 02 2009 Harald Hoyer 0.3-1 - version 0.3 drupal-6.13-1.fc12 ------------------ * Thu Jul 02 2009 Jon Ciesla - 6.13-1 - Update to 6.11, SA-CORE-2009-007. - Added clarifying text on module installation to readme, BZ 500707. eclipse-dtp-1.7.0-1.fc12 ------------------------ * Thu Jul 02 2009 Mat Booth 1.7.0-1 - Update to 1.7.0 final release (Galileo). - Get map files from CVS instead of maintaining our own. - Require Eclipse 3.4.2. eclipse-emf-2.5.0-2.fc12 ------------------------ * Thu Jul 02 2009 Mat Booth 2.5.0-2 - SDK requires PDE for example plug-in projects. eclipse-gef-3.5.0-2.fc12 ------------------------ * Thu Jul 02 2009 Mat Booth 3.5.0-2 - SDK requires PDE for example plug-in projects. eclipse-valgrind-0.2.1-2.fc12 ----------------------------- * Thu Jul 02 2009 Elliott Baron 0.2.1-2 - Fix Massif parsing for unknown symbols (Eclipse#281417). enchant-1.5.0-2.fc12 -------------------- * Thu Jul 02 2009 Caol?n McNamara 1:1.5.0-2 - Resolves: rhbz#508781 improve enchant quality, leaks, and edge-case language dict selection evolution-data-server-2.27.3-3.fc12 ----------------------------------- * Thu Jul 02 2009 Matthew Barnes - 2.27.3-3.fc12 - Add patch for RH bug #505661 (crash on startup). evolution-mapi-0.27.3-4.fc12 ---------------------------- * Thu Jul 02 2009 Matthew Barnes - 0.27.3-4 - Remove redundant library flag from pkg-config file. foomatic-4.0.2-3.fc12 --------------------- * Thu Jul 02 2009 Tim Waugh 4.0.2-1 - Updated db-engine to 4.0.2 (bug #503188). - Updated foomatic-filters to 4.0.2 (bug #496521). - Updated db-hpijs to 20090701. - Updated db to 4.0-20090702. - This package obsoletes oki4linux (bug #491489). - Don't ship ChangeLog/README/USAGE for each of the 4 packages as it comes to more than 1MB (bug #492449). - Don't use mktemp in foomatic-rip. * Thu Jul 02 2009 Tim Waugh 4.0.2-3 - Removed '-O0' compiler option for foomatic-filters, which had been used for debugging purposes. ganyremote-5.10-1.fc12 ---------------------- * Thu Jul 02 2009 Mikhail Fedotov - 5.10 - Threading issues were fixed. Enhanced handling of GuiAppBinary tag. Handle java client with 48x48 icons. gdm-2.26.1-13.fc12 ------------------ * Thu Jul 02 2009 Adam Jackson 1:2.26.1-13 - Requires: xorg-x11-xkb-utils -> Requires: setxkbmap glibc-2.10.90-2 --------------- * Thu Jul 02 2009 Andreas Schwab 2.10.90-2 - Update from master. * Fri Jun 26 2009 Andreas Schwab 2.10.90-1 - Update from master. - Enable multi-arch support on x86/x86-64. - Add requires glibc-headers to glibc-devel (#476295). - Implement second fallback mode for DNS requests (#505105). - Don't generate invalid POSIX TZ string for Asia/Dhaka timezone (#506941). - Allow backtrace through __longjmp_chk on powerpc. gnome-keyring-2.26.1-2.fc12 --------------------------- * Thu Jul 02 2009 Matthias Clasen - 2.26.1-2 - Rebuild gnurobots-1.2.0-6.fc12 ---------------------- * Fri Jul 03 2009 Vivek Shah - 1.2.0-6 - Added subcategory for the desktop file google-perftools-1.3-2.fc12 --------------------------- * Thu Jul 02 2009 Tom "spot" Callaway - 1.3-1 - update to 1.3 * Thu Jul 02 2009 Tom "spot" Callaway - 1.3-2 - disable tests for ppc, upstream ticket #153 gpodder-0.16.1-2.fc12 --------------------- * Thu Jul 02 2009 - 0.16.1-2 jpaleta - feedparser buildrequires fix * Sun Jun 14 2009 - 0.16.1-1 jpaleta - new upstream point release new features and bug fixes. See upstream website for details. gyachi-1.2.0-4.fc12 ------------------- * Thu Jul 02 2009 Gregory D Hosler - 1.2.0-4 - Fixed Yahoo PM text problem ibus-table-cangjie-1.1.0.20090309-12.fc12 ----------------------------------------- * Fri Jul 03 2009 Caius 'kaio' Chance - 1.1.0.20090309-12.fc12 - Rebuilt. * Wed Jul 01 2009 Caius 'kaio' Chance - 1.1.0.20090309-10.fc12 - Fixed that change into table directory for index creation. - Added owned directories in file section. - Removed bootstrap. - Updated package dependencies. * Wed Jul 01 2009 Caius 'kaio' Chance - 1.1.0.20090309-11.fc12 - Rebuilt with ibus-table 1.2.0. ibus-table-erbi-1.1.0.20090407-9.fc12 ------------------------------------- * Fri Jul 03 2009 Caius Chance - 1.1.0.20090407-9.fc12 - Fixed index creation at post-install. - Removed bootstrap. - Refined package dependencies. - Added owned directories. - Replaced hard coded command with macros. ibus-table-wubi-1.1.0.20090327-9.fc12 ------------------------------------- * Fri Jul 03 2009 Caius 'kaio' Chance - 1.1.0.20090316-9.fc12 - Rebuilt. * Wed Jul 01 2009 Caius 'kaio' Chance - 1.1.0.20090316-8.fc12 - Corrected by change into installed table directory for index creation. - Further specify package dependencies. - Added owned directories that supposed to belong to this package. - Move hard coded commands to macros. ibus-table-yong-1.1.0.20090422-6.fc12 ------------------------------------- kanyremote-5.10-1.fc12 ---------------------- * Thu Jul 02 2009 Mikhail Fedotov - 5.10 - Tool was rewritten on QT4. Enhanced handling of GuiAppBinary tag. Handle java client with 48x48 icons. kcometen4-1.0.5-1.fc12 ---------------------- * Wed Jul 01 2009 Alexey Kurov - 1.0.5-1 - update to 1.0.5 kdepim-runtime-4.2.95-3.fc12 ---------------------------- * Thu Jul 02 2009 Rex Dieter 4.2.95-3 - -devel: Requires: kdepimlibs-devel - Req: akonadi >= 1.1.95 kdepimlibs-4.2.95-3.fc12 ------------------------ * Thu Jul 02 2009 Rex Dieter - 4.2.95-3 - akonadi_version 1.1.95 kernel-2.6.31-0.39.rc1.git9.fc12 -------------------------------- * Thu Jul 02 2009 Kyle McMartin 2.6.31-0.39.rc1.git9 - 2.6.31-rc1-git9 - linux-2.6-dm-fix-exstore-search.patch: similar patch merged upstream. ldd-pdf-3.0-3.fc12 ------------------ * Thu Jul 02 2009 Steven Fernandez 3.0-3 - Added the dist tag libHX-2.8-1.fc12 ---------------- * Thu Jul 02 2009 Till Maas - 2.8-1 - Update to new release - Define docdir for %configure, because of installed PDF documentation libXaw-1.0.6-1.fc12 ------------------- * Thu Jul 02 2009 Adam Jackson 1.0.6-1 - libXaw 1.0.6 libXt-1.0.6-1.fc12 ------------------ * Thu Jul 02 2009 Adam Jackson 1.0.6-1 - libXt 1.0.6 libguestfs-1.0.55-1.fc12 ------------------------ * Thu Jul 02 2009 Richard W.M. Jones - 1.0.55-1 - New upstream release 1.0.55. - New manual page libguestfs(3). liblinebreak-1.2-1.fc12 ----------------------- * Thu Jul 02 2009 Michel Salim - 1.2-1 - Update to 1.2 - Build as dynamic library, instead of static libogg-1.1.4-1.fc12 ------------------- * Thu Jul 02 2009 Adam Jackson 1.1.4-1 - libogg 1.1.4 libvorbis-1.2.2-1.fc12 ---------------------- * Thu Jul 02 2009 Adam Jackson 1.2.2-1 - libvorbis 1.2.2 logwatch-7.3.6-45.fc12 ---------------------- * Thu Jul 02 2009 Ivana Varekova 7.3.6-45 - fix cron script mod_wsgi-2.5-1.fc12 ------------------- * Thu Jul 02 2009 James Bowes 2.5-1 - Update to 2.5 nemiver-0.7.0-2.fc12 -------------------- * Thu Jul 02 2009 Dodji Seketeli - 0.7.0-1 - Update to new upstream release (0.7.0) * Thu Jul 02 2009 Dodji Seketeli - 0.7.0-2 - Fix typo (redhat.org -> redhat.com) offlineimap-6.1.0-1.fc12 ------------------------ * Thu Jul 02 2009 Christoph H?ger - 6.1.0-1 - Update to latest version - Add a temporary patch for socket.ssl deprecation pam_mount-1.27-1.fc12 --------------------- * Thu Jul 02 2009 Till Maas - 1.27-1 - Update to new release php-hkit-0.5-3.fc12 ------------------- * Thu Jul 02 2009 Patrick Monnerat 0.5-3. - Release bump due to cvs tag problem. * Mon Jun 22 2009 Patrick Monnerat 0.5-2 - Move class files from /usr/share/php to /usr/share/php/hkit. psi-0.13-0.1.rc2.fc12 --------------------- * Thu Jul 02 2009 Sven Lankes 0.13-0.1.rc2 - 0.13 rc2 pykickstart-1.55-1.fc12 ----------------------- * Thu Jul 02 2009 Chris Lumens - 1.55-1 - Add support for the group command to F12 (#509119). - RHEL5 now supports RAID 10. - The f12 hander class should be called F12Handler. (jgranado) - Remove bootloader --lba32. - Add a new version of the driverdisk command without --type=. - Add initial support for F12. - Fetch the programmers-guide from the wiki now. * Mon May 18 2009 Chris Lumens - 1.54-1 - Make sure the F11 handler gets used for "partition" and "part" (#501020). python-mutagen-1.16-1.fc12 -------------------------- * Thu Jul 02 2009 Silas Sewell - 1.16-1 - Update to 1.16 - New project URLs * Sun Apr 12 2009 Silas Sewell - 1.15-3 - Normalize spec * Fri Apr 10 2009 Silas Sewell - 1.15-2 - Make sed safer - Add back in removed changelogs python-qpid-0.5.790661-1.fc12 ----------------------------- * Thu Jul 02 2009 Nuno Santos - 0.5.790661-1 - Rebased to svn rev 790661 python-twitter-0.6-1.fc12 ------------------------- * Thu Jul 02 2009 Tom "spot" Callaway - 0.6-1 - update to 0.6 qpidc-0.5.790661-1.fc12 ----------------------- * Thu Jul 02 2009 Nuno Santos - 0.5.790661-1 - Rebased to svn rev 790661; .so lib numbers bumped qt-4.5.2-3.fc12 --------------- * Thu Jul 02 2009 Than Ngo - 4.5.2-3 - pregenerate PNG, drop BR on GraphicsMagick (bz#509244) ruby-qpid-0.5.790661-1.fc12 --------------------------- * Thu Jul 02 2009 Nuno Santos - 0.5.790661-1 - Rebased to svn rev 790661 rubygem-nokogiri-1.3.2-2.fc12 ----------------------------- * Thu Jul 02 2009 Mamoru Tasaka - 1.3.2-2 - Enable test - Recompile with -O2 stellarium-0.10.2-3.fc12 ------------------------ * Thu Jul 02 2009 Jochen Schmitt 0.10.2-3 - Rebuild for new boost release subcommander-2.0-0.4.fc12.1 --------------------------- * Thu Jul 02 2009 Jochen Schmitt 2.0-0.4.1 - Change versioning for beta releases - Rebuild for new boost release t1lib-5.1.2-4.fc12 ------------------ * Thu Jul 02 2009 Adam Jackson 5.1.2-4 - Split demo apps to a subpackage to isolate libXaw deps xine-lib-1.1.16.3-3.fc12 ------------------------ * Thu Jul 02 2009 Rex Dieter - 1.1.16.3-3 - rebuild (DirectFB) * Fri Apr 17 2009 Rex Dieter - 1.1.16.3-2.1 - drop old_caca hacks/patches (F-9) xorg-x11-apps-7.4-1.fc12 ------------------------ * Thu Jul 02 2009 Adam Jackson 7.4-1 - Add xfd, xfontsel, and xvidtune xorg-x11-drv-cirrus-1.3.1-1.fc12 -------------------------------- * Thu Jul 02 2009 Adam Jackson 1.3.1-1 - cirrus 1.3.1 * Mon Jun 22 2009 Adam Jackson 1.3.0-2 - Fix ABI for new server xorg-x11-drv-dummy-0.3.2-1.fc12 ------------------------------- * Thu Jul 02 2009 Adam Jackson 0.3.2-1 - dummy 0.3.2 xorg-x11-drv-glint-1.2.3-1.fc12 ------------------------------- * Thu Jul 02 2009 Adam Jackson 1.2.3-1 - glint 1.2.3 xorg-x11-drv-i128-1.3.2-1.fc12 ------------------------------ * Thu Jul 02 2009 Adam Jackson 1.3.2-1 - i128 1.3.2 xorg-x11-drv-i740-1.3.1-1.fc12 ------------------------------ * Thu Jul 02 2009 Adam Jackson 1.3.1-1 - i740 1.3.1 xorg-x11-drv-neomagic-1.2.3-1.fc12 ---------------------------------- * Thu Jul 02 2009 Adam Jackson 1.2.3-1 - neomagic 1.2.3 xorg-x11-drv-rendition-4.2.2-1.fc12 ----------------------------------- * Thu Jul 02 2009 Adam Jackson 4.2.2-1 - rendition 4.2.2 xorg-x11-drv-s3-0.6.2-1.fc12 ---------------------------- * Thu Jul 02 2009 Adam Jackson 0.6.2-1 - s3 0.6.2 xorg-x11-drv-s3virge-1.10.3-1.fc12 ---------------------------------- * Thu Jul 02 2009 Adam Jackson 1.10.3-1 - s3virge 1.10.3 xorg-x11-drv-savage-2.3.0-1.fc12 -------------------------------- * Thu Jul 02 2009 Adam Jackson 2.3.0-1 - savage 2.3.0 xorg-x11-drv-siliconmotion-1.7.2-1.fc12 --------------------------------------- * Thu Jul 02 2009 Adam Jackson 1.7.2-1 - siliconmotion 1.7.2 xorg-x11-drv-sisusb-0.9.2-1.fc12 -------------------------------- * Thu Jul 02 2009 Adam Jackson 0.9.2-1 - sisusb 0.9.2 xorg-x11-drv-tdfx-1.4.2-1.fc12 ------------------------------ * Thu Jul 02 2009 Adam Jackson 1.4.2-1 - tdfx 1.4.2 xorg-x11-drv-trident-1.3.2-1.fc12 --------------------------------- * Thu Jul 02 2009 Adam Jackson 1.3.2-1 - trident 1.3.2 xorg-x11-drv-tseng-1.2.2-1.fc12 ------------------------------- * Thu Jul 02 2009 Adam Jackson 1.2.2-1 - tseng 1.2.2 xorg-x11-drv-voodoo-1.2.2-1.fc12 -------------------------------- * Thu Jul 02 2009 Adam Jackson 1.2.2-1 - voodoo 1.2.2 xorg-x11-server-utils-7.4-9.fc12 -------------------------------- * Thu Jul 02 2009 Adam Jackson 7.4-8 - Drop xvidtune, move it to -apps to isolate libXaw deps * Thu Jul 02 2009 Adam Jackson 7.4-9 - Requires: mcpp instead of cpp, and switch xrdb to use it. xorg-x11-utils-7.4-5.fc12 ------------------------- * Thu Jul 02 2009 Adam Jackson 7.4-5 - Drop xfd and xfontsel, move them to -apps to isolate libXaw deps. xorg-x11-xkb-utils-7.4-2.fc12 ----------------------------- * Thu Jul 02 2009 Adam Jackson 7.4-1 - Split Xaw-requiring utilities to extras subpackage * Thu Jul 02 2009 Adam Jackson 7.4-2 - Fix missing %defattr in -extras yelp-2.27.2-2.fc12 ------------------ * Thu Jul 02 2009 Matthias Clasen - 2.27.2-2 - Shrink GConf schemas yum-3.2.23-9.fc12 ----------------- * Thu Jul 02 2009 Seth Vidal - 3.2.23-9 - update to latest head - make livecd creation work again in rawhide - disable one of the man page patches until after 3.2.24 is released b/c of the changes to the man page in the head patch Summary: Added Packages: 4 Removed Packages: 1 Modified Packages: 89 From kevin.kofler at chello.at Fri Jul 3 12:48:47 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 03 Jul 2009 14:48:47 +0200 Subject: readline update? References: <20090703102747.GA32668@localhost> Message-ID: Miroslav Lichvar wrote: > kdeedu-4.2.95-1.fc12 kdeedu only uses readline in KAlgebra which is GPLv2+ (and only in the command-line version ("calgebra") at that), so no problems there. (I also verified that "calgebra" doesn't use any GPL v2 only libraries.) Kevin Kofler From paul at city-fan.org Fri Jul 3 13:09:01 2009 From: paul at city-fan.org (Paul Howarth) Date: Fri, 03 Jul 2009 14:09:01 +0100 Subject: readline update? In-Reply-To: <20090703102747.GA32668@localhost> References: <20090703102747.GA32668@localhost> Message-ID: <4A4E02ED.5020903@city-fan.org> On 03/07/09 11:27, Miroslav Lichvar wrote: > I'd like to update readline to the latest version 6.0. The problem is > that the license was changed to GPLv3+ and we have some GPLv2 packages > using readline. > > A possible replacement is the editline library which provides a > compatible interface and is licensed under BSD, unfortunately it > doesn't handle UTF-8. > > Are we stuck with readline 5.2? Suggestions? > > The package list is: > > GMT-4.4.0-2.fc11 > Macaulay2-1.2-4.fc12 > afpfs-ng-0.8.1-2.fc11 > bti-015-1.fc11 > calc-2.12.2.1-13.fc11 > callweaver-1.2.0.1-3.fc11 > cgdb-0.6.4-4.fc11 > chrony-1.23-5.20081106gitbe42b4.fc12 > clisp-2.47-3.fc11 > coda-6.9.4-2.fc11 > devtodo-0.1.20-3.fc12 > fityk-0.8.1-14.fc10 > gnu-smalltalk-3.1-5.fc12 > gnubg-0.9.0.1-7.fc11 > gnuplot-4.2.5-4.fc12 > grass-6.3.0-12.fc11 > kdeedu-4.2.95-1.fc12 > ktechlab-0.3.70-1.20090304svn.fc11 > lvm2-2.02.48-1.fc12 > maxima-5.18.1-3.fc12 > ocfs2-tools-1.3.9-10.20080221git.fc11 > socat-1.7.0.0-2.fc11 You've missed perl-Term-ReadLine-Gnu (and I wonder how many other packages?) but that one's OK as it's GPL+. Paul. From a.badger at gmail.com Fri Jul 3 13:39:19 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 03 Jul 2009 06:39:19 -0700 Subject: readline update? In-Reply-To: <20090703102747.GA32668@localhost> References: <20090703102747.GA32668@localhost> Message-ID: <4A4E0A07.90406@gmail.com> On 07/03/2009 03:27 AM, Miroslav Lichvar wrote: > I'd like to update readline to the latest version 6.0. The problem is > that the license was changed to GPLv3+ and we have some GPLv2 packages > using readline. > > A possible replacement is the editline library which provides a > compatible interface and is licensed under BSD, unfortunately it > doesn't handle UTF-8. > > Are we stuck with readline 5.2? Suggestions? > Can we parallel install readline5 and readline6? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From dev at nigelj.com Fri Jul 3 14:02:13 2009 From: dev at nigelj.com (Nigel Jones) Date: Sat, 4 Jul 2009 02:02:13 +1200 Subject: Mass-Package Orphanage Message-ID: <4a8a1eec80f398b597045ef77c1a8f94.squirrel@webmail.nigelj.com> Hi All, I'm orphaning a bunch of packages for various reasons, mainly though -ENOSPARETIME to update. Although there are some mono packages there and I definately don't have enough time to make them work properly. Mono Packages: f-spot -- Photo management application ndesk-dbus -- Managed C# implementation of DBus ndesk-dbus-glib -- Provides glib mainloop integration for ndesk-dbus PHP Based Packages: php-pecl-json -- PECL library to implement JSON in PHP Horde: horde -- The common Horde Framework for all Horde applications imp -- The Internet Messaging Program: webmail access to IMAP/POP3 accounts ingo -- The Horde web-based Email Filter Rules Manager jeta -- Horde Java SSH module kronolith -- The Horde calendar application turba -- The Horde contact management application Mediawiki Related: mediawiki-Cite -- An extension to provide Citation tools for Mediawiki mediawiki-SpecialInterwiki -- An extension to provide an interwiki management system I'm going to be marking them as Orphaned over the next day (hopefully now, but just in case I don't get them all right away). Thanks, Nigel From tgl at redhat.com Fri Jul 3 14:18:19 2009 From: tgl at redhat.com (Tom Lane) Date: Fri, 03 Jul 2009 10:18:19 -0400 Subject: readline update? In-Reply-To: <4A4E0A07.90406@gmail.com> References: <20090703102747.GA32668@localhost> <4A4E0A07.90406@gmail.com> Message-ID: <687.1246630699@sss.pgh.pa.us> Toshio Kuratomi writes: > On 07/03/2009 03:27 AM, Miroslav Lichvar wrote: >> I'd like to update readline to the latest version 6.0. The problem is >> that the license was changed to GPLv3+ and we have some GPLv2 packages >> using readline. >> >> A possible replacement is the editline library which provides a >> compatible interface and is licensed under BSD, unfortunately it >> doesn't handle UTF-8. >> >> Are we stuck with readline 5.2? Suggestions? >> > Can we parallel install readline5 and readline6? Maybe somebody should work on fixing whatever editline deficiencies are seen as showstoppers. regards, tom lane From jonstanley at gmail.com Fri Jul 3 14:22:10 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Fri, 3 Jul 2009 10:22:10 -0400 Subject: Mass-Package Orphanage In-Reply-To: <4a8a1eec80f398b597045ef77c1a8f94.squirrel@webmail.nigelj.com> References: <4a8a1eec80f398b597045ef77c1a8f94.squirrel@webmail.nigelj.com> Message-ID: On Fri, Jul 3, 2009 at 10:02 AM, Nigel Jones wrote: > PHP Based Packages: > php-pecl-json -- PECL library to implement JSON in PHP Got this one since it's a dependency for the MW stuff below. ] > Mediawiki Related: > mediawiki-Cite -- An extension to provide Citation tools for Mediawiki > mediawiki-SpecialInterwiki -- An extension to provide an interwiki > management system And these, we use them in Fedora Infrastructure. From tibbs at math.uh.edu Fri Jul 3 15:23:15 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 03 Jul 2009 10:23:15 -0500 Subject: Mass-Package Orphanage In-Reply-To: <4a8a1eec80f398b597045ef77c1a8f94.squirrel@webmail.nigelj.com> (Nigel Jones's message of "Sat\, 4 Jul 2009 02\:02\:13 +1200") References: <4a8a1eec80f398b597045ef77c1a8f94.squirrel@webmail.nigelj.com> Message-ID: >>>>> "NJ" == Nigel Jones writes: NJ> Horde: All of these packages (horde, imp, ingo, jeta, kronolith, turba) are PHP-based webapps, which should strike fear into most maintainers. I happen to be co-maintainer so I guess I've been promoted, although honestly I haven't had time to put much effort into these packages either. So, I'm pretty sure I can't be the only person in Fedora who cares about these packages. They need at least two maintainers, preferably three. Please feel free to pile on. - J< From nathanael at gnat.ca Fri Jul 3 15:29:24 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Fri, 03 Jul 2009 09:29:24 -0600 Subject: Mass-Package Orphanage In-Reply-To: References: <4a8a1eec80f398b597045ef77c1a8f94.squirrel@webmail.nigelj.com> Message-ID: <4A4E23D4.1090307@gnat.ca> On 07/03/2009 09:23 AM, Jason L Tibbitts III wrote: >>>>>> "NJ" == Nigel Jones writes: > > NJ> Horde: > > All of these packages (horde, imp, ingo, jeta, kronolith, turba) are > PHP-based webapps, which should strike fear into most maintainers. I > happen to be co-maintainer so I guess I've been promoted, although > honestly I haven't had time to put much effort into these packages > either. > > So, I'm pretty sure I can't be the only person in Fedora who cares > about these packages. They need at least two maintainers, preferably > three. Please feel free to pile on. I've recently decided to try to help out by being a package maintainer... I haven't submitted a package, I don't have any new packages I need. I'm wondering if it is possible to be a co-maintainer with someone willing? I've got lots of experience creating packages for our own server farm and workstations, but none with fedora approved packaging... What's the policy here? I wouldn't mind helping out with the horde stack, but am guessing I would need some sort of sponsor, double check commits before they happen type thing... ? From tibbs at math.uh.edu Fri Jul 3 16:52:03 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 03 Jul 2009 11:52:03 -0500 Subject: Mass-Package Orphanage In-Reply-To: <4A4E23D4.1090307@gnat.ca> (Nathanael D. Noblet's message of "Fri\, 03 Jul 2009 09\:29\:24 -0600") References: <4a8a1eec80f398b597045ef77c1a8f94.squirrel@webmail.nigelj.com> <4A4E23D4.1090307@gnat.ca> Message-ID: >>>>> "NDN" == Nathanael D Noblet writes: NDN> I'm wondering if it is possible to be a co-maintainer with NDN> someone willing? In general, all you need is a sponsor. The usual route to that is via the submission of new packages, but it's not the only way. I happen to be a sponsor, so that's not an issue. What is an issue is that fact that the horde suite is somewhat delicate and security sensitive, and not really the best set of packages for a first-time packager. This is somewhat offset by the fact that the packages already exist and just need maintenance. I think that if you're interested, you should start by requesting watchcommits and watchbugzilla on at least the Fedora branches of those packages. (I have no desire to maintain the EPEL5 branch, so someone else needs to step in to take care of that one.) The URLs are: https://admin.fedoraproject.org/pkgdb/packages/name/horde https://admin.fedoraproject.org/pkgdb/packages/name/imp https://admin.fedoraproject.org/pkgdb/packages/name/ingo https://admin.fedoraproject.org/pkgdb/packages/name/jeta https://admin.fedoraproject.org/pkgdb/packages/name/kronolith https://admin.fedoraproject.org/pkgdb/packages/name/turba Later we can progress to sponsorship and commit access. I still hope we can find at least one other person to assist in maintaining these packages. Otherwise I fear I will just end up orphaning them again. - J< From nathanael at gnat.ca Fri Jul 3 16:56:32 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Fri, 03 Jul 2009 10:56:32 -0600 Subject: Mass-Package Orphanage In-Reply-To: References: <4a8a1eec80f398b597045ef77c1a8f94.squirrel@webmail.nigelj.com> <4A4E23D4.1090307@gnat.ca> Message-ID: <4A4E3840.4060704@gnat.ca> On 07/03/2009 10:52 AM, Jason L Tibbitts III wrote: >>>>>> "NDN" == Nathanael D Noblet writes: > > NDN> I'm wondering if it is possible to be a co-maintainer with > NDN> someone willing? > > In general, all you need is a sponsor. The usual route to that is via > the submission of new packages, but it's not the only way. I happen > to be a sponsor, so that's not an issue. > > What is an issue is that fact that the horde suite is somewhat > delicate and security sensitive, and not really the best set of > packages for a first-time packager. This is somewhat offset by the > fact that the packages already exist and just need maintenance. Yeah, I figured as much. There are a few other packages I wouldn't mind helping out with all in all but without submitting a package for review it seems I'm coming at this a bit sideways... > I think that if you're interested, you should start by requesting > watchcommits and watchbugzilla on at least the Fedora branches of > those packages. (I have no desire to maintain the EPEL5 branch, so > someone else needs to step in to take care of that one.) The URLs > are: Ok, well I could definitely use the EPEL5 packages as I up to now have been installing them on CentOS 5 servers manually. > https://admin.fedoraproject.org/pkgdb/packages/name/horde > https://admin.fedoraproject.org/pkgdb/packages/name/imp > https://admin.fedoraproject.org/pkgdb/packages/name/ingo > https://admin.fedoraproject.org/pkgdb/packages/name/jeta > https://admin.fedoraproject.org/pkgdb/packages/name/kronolith > https://admin.fedoraproject.org/pkgdb/packages/name/turba > > Later we can progress to sponsorship and commit access. > > I still hope we can find at least one other person to assist in > maintaining these packages. Otherwise I fear I will just end up > orphaning them again. Sounds good.. From fedora at matbooth.co.uk Fri Jul 3 17:37:16 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Fri, 3 Jul 2009 18:37:16 +0100 Subject: Mass-Package Orphanage In-Reply-To: <4A4E3840.4060704@gnat.ca> References: <4a8a1eec80f398b597045ef77c1a8f94.squirrel@webmail.nigelj.com> <4A4E23D4.1090307@gnat.ca> <4A4E3840.4060704@gnat.ca> Message-ID: <9497e9990907031037o55240325re29a8e8acb654eb2@mail.gmail.com> On Fri, Jul 3, 2009 at 5:56 PM, Nathanael D. Noblet wrote: > On 07/03/2009 10:52 AM, Jason L Tibbitts III wrote: >>>>>>> >>>>>>> "NDN" == Nathanael D Noblet ?writes: >> >> NDN> ?I'm wondering if it is possible to be a co-maintainer with >> NDN> ?someone willing? >> >> In general, all you need is a sponsor. ?The usual route to that is via >> the submission of new packages, but it's not the only way. ?I happen >> to be a sponsor, so that's not an issue. >> >> What is an issue is that fact that the horde suite is somewhat >> delicate and security sensitive, and not really the best set of >> packages for a first-time packager. ?This is somewhat offset by the >> fact that the packages already exist and just need maintenance. > > Yeah, I figured as much. There are a few other packages I wouldn't mind > helping out with all in all but without submitting a package for review it > seems I'm coming at this a bit sideways... > > >> I think that if you're interested, you should start by requesting >> watchcommits and watchbugzilla on at least the Fedora branches of >> those packages. ?(I have no desire to maintain the EPEL5 branch, so >> someone else needs to step in to take care of that one.) ?The URLs >> are: > > Ok, well I could definitely use the EPEL5 packages as I up to now have been > installing them on CentOS 5 servers manually. > Then help Jason maintain the EPEL branches by sending him spec file patches, re-basing Fedora carried patches to new versions, etc. Submitting patches is great alternative way to prove yourself for getting sponsored. -- Mat Booth www.matbooth.co.uk From dodji at redhat.com Fri Jul 3 17:56:11 2009 From: dodji at redhat.com (Dodji Seketeli) Date: Fri, 03 Jul 2009 19:56:11 +0200 Subject: Mass-Package Orphanage In-Reply-To: References: <4a8a1eec80f398b597045ef77c1a8f94.squirrel@webmail.nigelj.com> <4A4E23D4.1090307@gnat.ca> Message-ID: <4A4E463B.90908@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 03/07/2009 18:52, Jason L Tibbitts III a ?crit : >>>>>> "NDN" == Nathanael D Noblet writes: > > NDN> I'm wondering if it is possible to be a co-maintainer with > NDN> someone willing? > > In general, all you need is a sponsor. The usual route to that is via > the submission of new packages, but it's not the only way. I happen > to be a sponsor, so that's not an issue. Interesting. I thought people were obliged to submit _new_ packages to request sponsorship, and to be honest, I have always found unfortunate that people like Nathanael would'd want to help co-maintain an existing package would be left out of the door just because they wouldn't be interested in submitting a new package. Out of curiosity, could you point me to a reference documentation that explains the process to sponsor a co-maintainer who is not a fedora packager already ? The only link I was aware of was this one: http://fedoraproject.org/wiki/PackageMaintainers/Join#Make_a_Package, where it's stated: "You should make sure that it is a new package. " Thanks. - -- Dodji Seketeli Red Hat, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEUEARECAAYFAkpORjsACgkQPejI7lrem2G7NQCfe60L/w1FfUMLDJEYfP9n+Xrb 34UAmNPQRaU55lhGV5fKOqJj4D/GtmI= =7HEZ -----END PGP SIGNATURE----- From dodji at redhat.com Fri Jul 3 17:56:29 2009 From: dodji at redhat.com (Dodji Seketeli) Date: Fri, 03 Jul 2009 19:56:29 +0200 Subject: Mass-Package Orphanage In-Reply-To: References: <4a8a1eec80f398b597045ef77c1a8f94.squirrel@webmail.nigelj.com> <4A4E23D4.1090307@gnat.ca> Message-ID: <4A4E464D.1090101@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 03/07/2009 18:52, Jason L Tibbitts III a ?crit : >>>>>> "NDN" == Nathanael D Noblet writes: > > NDN> I'm wondering if it is possible to be a co-maintainer with > NDN> someone willing? > > In general, all you need is a sponsor. The usual route to that is via > the submission of new packages, but it's not the only way. I happen > to be a sponsor, so that's not an issue. Interesting. I thought people were obliged to submit _new_ packages to request sponsorship, and to be honest, I have always found unfortunate that people like Nathanael would'd want to help co-maintain an existing package would be left out of the door just because they wouldn't be interested in submitting a new package. Out of curiosity, could you point me to a reference documentation that explains the process to sponsor a co-maintainer who is not a fedora packager already ? The only link I was aware of was this one: http://fedoraproject.org/wiki/PackageMaintainers/Join#Make_a_Package, where it's stated: "You should make sure that it is a new package. " Thanks. - -- Dodji Seketeli Red Hat, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEUEARECAAYFAkpORjsACgkQPejI7lrem2G7NQCfe60L/w1FfUMLDJEYfP9n+Xrb 34UAmNPQRaU55lhGV5fKOqJj4D/GtmI= =7HEZ -----END PGP SIGNATURE----- From tibbs at math.uh.edu Fri Jul 3 18:12:54 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 03 Jul 2009 13:12:54 -0500 Subject: Mass-Package Orphanage In-Reply-To: <4A4E463B.90908@redhat.com> (Dodji Seketeli's message of "Fri\, 03 Jul 2009 19\:56\:11 +0200") References: <4a8a1eec80f398b597045ef77c1a8f94.squirrel@webmail.nigelj.com> <4A4E23D4.1090307@gnat.ca> <4A4E463B.90908@redhat.com> Message-ID: >>>>> "DS" == Dodji Seketeli writes: DS> Interesting. I thought people were obliged to submit _new_ DS> packages to request sponsorship, Any user can request sponsorship without doing anything. That doesn't mean they're going to get it, of course. It is the sponsor's responsibility to monitor and mentor the person they've sponsored, and they make the decision about who they wish to sponsor. (And here I'm talking about the packager group only, not any other group which also has sponsors and which may have their own rules.) It is true that one significant path to this is the submission of new packages. I don't think you'll find it anywhere documented that the only possible path is the submission of new packages. DS> Out of curiosity, could you point me to a reference documentation DS> that explains the process to sponsor a co-maintainer who is not a DS> fedora packager already ? If you're a sponsor, you just go to the account system and sponsor them (assuming they've already applied, of course). The procedure isn't any different than any other situation where someone is sponsored into a group. DS> The only link I was aware of was this one: DS> http://fedoraproject.org/wiki/PackageMaintainers/Join#Make_a_Package, DS> where it's stated: "You should make sure that it is a new DS> package. " That's the document on submitting new packages, yes. As such, you can expect that it talks about submitting new packages. - J< From sandeen at redhat.com Fri Jul 3 18:27:06 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Fri, 03 Jul 2009 13:27:06 -0500 Subject: readline update? In-Reply-To: <20090703102747.GA32668@localhost> References: <20090703102747.GA32668@localhost> Message-ID: <4A4E4D7A.2000404@redhat.com> Miroslav Lichvar wrote: > I'd like to update readline to the latest version 6.0. The problem is > that the license was changed to GPLv3+ and we have some GPLv2 packages > using readline. > > A possible replacement is the editline library which provides a > compatible interface and is licensed under BSD, unfortunately it > doesn't handle UTF-8. > > Are we stuck with readline 5.2? Suggestions? > > The package list is: latest xfsprogs uses libreadline too (it can also be configured to use editline) -Eric > GMT-4.4.0-2.fc11 > Macaulay2-1.2-4.fc12 > afpfs-ng-0.8.1-2.fc11 > bti-015-1.fc11 > calc-2.12.2.1-13.fc11 > callweaver-1.2.0.1-3.fc11 > cgdb-0.6.4-4.fc11 > chrony-1.23-5.20081106gitbe42b4.fc12 > clisp-2.47-3.fc11 > coda-6.9.4-2.fc11 > devtodo-0.1.20-3.fc12 > fityk-0.8.1-14.fc10 > gnu-smalltalk-3.1-5.fc12 > gnubg-0.9.0.1-7.fc11 > gnuplot-4.2.5-4.fc12 > grass-6.3.0-12.fc11 > kdeedu-4.2.95-1.fc12 > ktechlab-0.3.70-1.20090304svn.fc11 > lvm2-2.02.48-1.fc12 > maxima-5.18.1-3.fc12 > ocfs2-tools-1.3.9-10.20080221git.fc11 > socat-1.7.0.0-2.fc11 > From peter at thecodergeek.com Fri Jul 3 19:10:49 2009 From: peter at thecodergeek.com (Peter Gordon) Date: Fri, 03 Jul 2009 12:10:49 -0700 Subject: Mass-Package Orphanage In-Reply-To: <4a8a1eec80f398b597045ef77c1a8f94.squirrel@webmail.nigelj.com> References: <4a8a1eec80f398b597045ef77c1a8f94.squirrel@webmail.nigelj.com> Message-ID: <1246648249.12114.13.camel@tuxhugs> On Sat, 2009-07-04 at 02:02 +1200, Nigel Jones wrote: > ndesk-dbus -- Managed C# implementation of DBus > ndesk-dbus-glib -- Provides glib mainloop integration for ndesk-dbus I'd be happy to take these two, since Banshee and Tomboy (among others) require them. :) -- Peter Gordon (codergeek42) Who am I? :: http://thecodergeek.com/about-me -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Fri Jul 3 19:29:46 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 03 Jul 2009 21:29:46 +0200 Subject: readline update? In-Reply-To: <20090703102747.GA32668@localhost> References: <20090703102747.GA32668@localhost> Message-ID: <4A4E5C2A.7020702@freenet.de> Miroslav Lichvar wrote: > I'd like to update readline to the latest version 6.0. The problem is > that the license was changed to GPLv3+ and we have some GPLv2 packages > using readline. > > A possible replacement is the editline library which provides a > compatible interface and is licensed under BSD, unfortunately it > doesn't handle UTF-8. I thought, we banned all non-utf-8 aware packages? Ralf From drago01 at gmail.com Fri Jul 3 19:57:28 2009 From: drago01 at gmail.com (drago01) Date: Fri, 3 Jul 2009 21:57:28 +0200 Subject: readline update? In-Reply-To: <4A4E5C2A.7020702@freenet.de> References: <20090703102747.GA32668@localhost> <4A4E5C2A.7020702@freenet.de> Message-ID: On Fri, Jul 3, 2009 at 9:29 PM, Ralf Corsepius wrote: > Miroslav Lichvar wrote: >> >> I'd like to update readline to the latest version 6.0. The problem is >> that the license was changed to GPLv3+ and we have some GPLv2 packages >> using readline. >> >> A possible replacement is the editline library which provides a >> compatible interface and is licensed under BSD, unfortunately it >> doesn't handle UTF-8. > > I thought, we banned all non-utf-8 aware packages? err .. what? no we still have a lot of them... From bruno at wolff.to Fri Jul 3 20:00:35 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 3 Jul 2009 15:00:35 -0500 Subject: Dracut now has a wiki page in the Fedora wiki... In-Reply-To: <1246614214.25852.239.camel@vaio.local.net> References: <4A4D4139.706@hi.is> <1246614214.25852.239.camel@vaio.local.net> Message-ID: <20090703200035.GB15962@wolff.to> On Fri, Jul 03, 2009 at 10:43:34 +0100, Adam Williamson wrote: > > but it's actually a lot less trouble to just do: > > "tar xf dracut-$version.tar.bz2" > > which auto-detects the archive type. It's much easier to just let it be > handled by autodetection, and only bother specifying the archive type > manually if the autodetection trips up. How long has that feature been there? From kevin at scrye.com Fri Jul 3 20:09:41 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 3 Jul 2009 14:09:41 -0600 Subject: libxklavier api change In-Reply-To: <1246456747.1685.2.camel@localhost.localdomain> References: <1246456747.1685.2.camel@localhost.localdomain> Message-ID: <20090703140941.64a24fd0@ohm.scrye.com> On Wed, 01 Jul 2009 09:59:07 -0400 Matthias Clasen wrote: > I built libxklavier 4.0 in rawhide yesterday. > It changed api; the required change looks like this: > > - xkl_config_registry_load (config_registry); > + xkl_config_registry_load (config_registry, FALSE); > > > Sorry for the late notice... > > > Here is a list of likely affected packages: > > xfce4-settings-0:4.6.1-1.fc12.x86_64 Sorry about the delay here... rebuilt 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 rc040203 at freenet.de Fri Jul 3 20:35:51 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 03 Jul 2009 22:35:51 +0200 Subject: readline update? In-Reply-To: References: <20090703102747.GA32668@localhost> <4A4E5C2A.7020702@freenet.de> Message-ID: <4A4E6BA7.1030905@freenet.de> drago01 wrote: > On Fri, Jul 3, 2009 at 9:29 PM, Ralf Corsepius wrote: >> Miroslav Lichvar wrote: >>> I'd like to update readline to the latest version 6.0. The problem is >>> that the license was changed to GPLv3+ and we have some GPLv2 packages >>> using readline. >>> >>> A possible replacement is the editline library which provides a >>> compatible interface and is licensed under BSD, unfortunately it >>> doesn't handle UTF-8. >> I thought, we banned all non-utf-8 aware packages? > > err .. what? Yes, utf-8 awareness had been a review criterion since the earliest Fedora days. > no we still have a lot of them... Packages to get rid off ... did somebody say Fedora is "leading edge"? Ralf From jussilehtola at fedoraproject.org Fri Jul 3 21:53:00 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Sat, 04 Jul 2009 00:53:00 +0300 Subject: readline update? In-Reply-To: <4A4E6BA7.1030905@freenet.de> References: <20090703102747.GA32668@localhost> <4A4E5C2A.7020702@freenet.de> <4A4E6BA7.1030905@freenet.de> Message-ID: <20090704005300.18094duiwiamuta4@webmail.helsinki.fi> Quoting "Ralf Corsepius" : > drago01 wrote: >> On Fri, Jul 3, 2009 at 9:29 PM, Ralf Corsepius wrote: >>> Miroslav Lichvar wrote: >>>> A possible replacement is the editline library which provides a >>>> compatible interface and is licensed under BSD, unfortunately it >>>> doesn't handle UTF-8. >>> I thought, we banned all non-utf-8 aware packages? >> >> err .. what? > Yes, utf-8 awareness had been a review criterion since the earliest > Fedora days. No. What you are thinking of is spec files and rpm filenames (and documentation that is in non-ASCII character set). >> no we still have a lot of them... > Packages to get rid off ... did somebody say Fedora is "leading edge"? Just because a program doesn't support UTF8 doesn't make it broken. I can state a lot of programs that aren't UTF8 compatible but still offer a lot of functionality and are important for daily work. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From notting at redhat.com Fri Jul 3 21:55:21 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 3 Jul 2009 17:55:21 -0400 Subject: readline update? In-Reply-To: <20090703102747.GA32668@localhost> References: <20090703102747.GA32668@localhost> Message-ID: <20090703215521.GD13203@nostromo.devel.redhat.com> Miroslav Lichvar (mlichvar at redhat.com) said: > I'd like to update readline to the latest version 6.0. The problem is > that the license was changed to GPLv3+ and we have some GPLv2 packages > using readline. > > A possible replacement is the editline library which provides a > compatible interface and is licensed under BSD, unfortunately it > doesn't handle UTF-8. > > Are we stuck with readline 5.2? Suggestions? I suppose the first question is whether or not 5.2 and 6.0 are ABI-compatible; if they're not, a parallel intsall would be simplest. Bill From rc040203 at freenet.de Fri Jul 3 22:26:47 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 04 Jul 2009 00:26:47 +0200 Subject: readline update? In-Reply-To: <20090704005300.18094duiwiamuta4@webmail.helsinki.fi> References: <20090703102747.GA32668@localhost> <4A4E5C2A.7020702@freenet.de> <4A4E6BA7.1030905@freenet.de> <20090704005300.18094duiwiamuta4@webmail.helsinki.fi> Message-ID: <4A4E85A7.60306@freenet.de> Jussi Lehtola wrote: > Quoting "Ralf Corsepius" : > >> drago01 wrote: >>> On Fri, Jul 3, 2009 at 9:29 PM, Ralf Corsepius >>> wrote: >>>> Miroslav Lichvar wrote: >>>>> A possible replacement is the editline library which provides a >>>>> compatible interface and is licensed under BSD, unfortunately it >>>>> doesn't handle UTF-8. >>>> I thought, we banned all non-utf-8 aware packages? >>> >>> err .. what? >> Yes, utf-8 awareness had been a review criterion since the earliest >> Fedora days. > > No. What you are thinking of is spec files and rpm filenames (and > documentation that is in non-ASCII character set). No, I am talking about applications and libraries, not about documentation. >>> no we still have a lot of them... >> Packages to get rid off ... did somebody say Fedora is "leading edge"? > > Just because a program doesn't support UTF8 doesn't make it broken. Wrong, it is broken. > I can state a lot of programs that aren't UTF8 compatible but still > offer a lot of functionality and are important for daily work. Most programs automatically are utf8 compatible on Linux and don't need further treatment. Ralf From sundaram at fedoraproject.org Fri Jul 3 22:45:07 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 04 Jul 2009 04:15:07 +0530 Subject: readline update? In-Reply-To: <4A4E85A7.60306@freenet.de> References: <20090703102747.GA32668@localhost> <4A4E5C2A.7020702@freenet.de> <4A4E6BA7.1030905@freenet.de> <20090704005300.18094duiwiamuta4@webmail.helsinki.fi> <4A4E85A7.60306@freenet.de> Message-ID: <4A4E89F3.7050106@fedoraproject.org> On 07/04/2009 03:56 AM, Ralf Corsepius wrote: > Jussi Lehtola wrote: >> Quoting "Ralf Corsepius" : >>> Yes, utf-8 awareness had been a review criterion since the earliest >>> Fedora days. >> >> No. What you are thinking of is spec files and rpm filenames (and >> documentation that is in non-ASCII character set). > > No, I am talking about applications and libraries, not about documentation. http://fedoraproject.org/wiki/Packaging:ReviewGuidelines You claim that UTF-8 awareness is a review criteria. However I find no record of that. The only thing in the guidelines is "MUST: All filenames in rpm packages must be valid UTF-8" This is what is noted in the packaging guidelines as well. Can you provide a reference to what you claim? Rahul From jcm at redhat.com Sat Jul 4 03:19:04 2009 From: jcm at redhat.com (Jon Masters) Date: Fri, 03 Jul 2009 23:19:04 -0400 Subject: Dracut now has a wiki page in the Fedora wiki... In-Reply-To: <20090703200035.GB15962@wolff.to> References: <4A4D4139.706@hi.is> <1246614214.25852.239.camel@vaio.local.net> <20090703200035.GB15962@wolff.to> Message-ID: <1246677544.5270.405.camel@perihelion.bos.jonmasters.org> On Fri, 2009-07-03 at 15:00 -0500, Bruno Wolff III wrote: > On Fri, Jul 03, 2009 at 10:43:34 +0100, > Adam Williamson wrote: > > > > but it's actually a lot less trouble to just do: > > > > "tar xf dracut-$version.tar.bz2" > > > > which auto-detects the archive type. It's much easier to just let it be > > handled by autodetection, and only bother specifying the archive type > > manually if the autodetection trips up. > > How long has that feature been there? I'm as amused as you are that I didn't know about that either (my guess is it's been there a while and we're just all stuck in our ways). At least we're not stuck in the 1970s and willing to move with the times - a lot of people still like to use pipes of the individual utilities ;) Jon. From jcm at redhat.com Sat Jul 4 03:22:54 2009 From: jcm at redhat.com (Jon Masters) Date: Fri, 03 Jul 2009 23:22:54 -0400 Subject: readline update? In-Reply-To: <20090703102747.GA32668@localhost> References: <20090703102747.GA32668@localhost> Message-ID: <1246677774.5270.408.camel@perihelion.bos.jonmasters.org> On Fri, 2009-07-03 at 12:27 +0200, Miroslav Lichvar wrote: > bti-015-1.fc11 > lvm2-2.02.48-1.fc12 I mailed Greg and Alasdair about these just so they know. Jon. From tmz at pobox.com Sat Jul 4 03:24:37 2009 From: tmz at pobox.com (Todd Zullinger) Date: Fri, 3 Jul 2009 23:24:37 -0400 Subject: Dracut now has a wiki page in the Fedora wiki... In-Reply-To: <20090703200035.GB15962@wolff.to> References: <4A4D4139.706@hi.is> <1246614214.25852.239.camel@vaio.local.net> <20090703200035.GB15962@wolff.to> Message-ID: <20090704032437.GV4753@inocybe.localdomain> Bruno Wolff III wrote: > On Fri, Jul 03, 2009 at 10:43:34 +0100, > Adam Williamson wrote: >> >> but it's actually a lot less trouble to just do: >> >> "tar xf dracut-$version.tar.bz2" >> >> which auto-detects the archive type. It's much easier to just let >> it be handled by autodetection, and only bother specifying the >> archive type manually if the autodetection trips up. > > How long has that feature been there? A good while. From the tar NEWS file: version 1.15 - Sergey Poznyakoff, 2004-12-20 * Compressed archives are recognised automatically, it is no longer necessary to specify -Z, -z, or -j options to read them. Thus, you can now run `tar tf archive.tar.gz'. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ People are crazy and times are strange I'm locked in tight, I'm out of range I used to care, but things have changed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From kevin.kofler at chello.at Sat Jul 4 07:21:50 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 04 Jul 2009 09:21:50 +0200 Subject: readline update? References: <20090703102747.GA32668@localhost> <4A4E5C2A.7020702@freenet.de> Message-ID: Ralf Corsepius wrote: > I thought, we banned all non-utf-8 aware packages? Unfortunately, a lot of that crap went in anyway because some reviewers just don't care. I agree with you that it's a showstopper. Applications which don't support UTF-8 WILL NOT WORK properly in Fedora's default locales. Not even in English. But it's especially apparent in languages actually using non-ASCII characters (i.e. most non-English languages). We really need to fix editline to properly support UTF-8, then these readline licensing issues might also just go away. (Sadly, this inconsiderate "upgrade" to GPLv3 looks to me like an own goal by the FSF. They always present readline like a library which is intentionally GPL to provide an advantage to Free Software and proudly show how some programs chose the GPL because of readline. Now this license change is actually going to help editline and thus a BSD-licensed implementation.) Kevin Kofler From awilliam at redhat.com Sat Jul 4 07:11:46 2009 From: awilliam at redhat.com (Adam Williamson) Date: Sat, 04 Jul 2009 08:11:46 +0100 Subject: Dracut now has a wiki page in the Fedora wiki... In-Reply-To: <1246677544.5270.405.camel@perihelion.bos.jonmasters.org> References: <4A4D4139.706@hi.is> <1246614214.25852.239.camel@vaio.local.net> <20090703200035.GB15962@wolff.to> <1246677544.5270.405.camel@perihelion.bos.jonmasters.org> Message-ID: <1246691506.25852.258.camel@vaio.local.net> On Fri, 2009-07-03 at 23:19 -0400, Jon Masters wrote: > On Fri, 2009-07-03 at 15:00 -0500, Bruno Wolff III wrote: > > On Fri, Jul 03, 2009 at 10:43:34 +0100, > > Adam Williamson wrote: > > > > > > but it's actually a lot less trouble to just do: > > > > > > "tar xf dracut-$version.tar.bz2" > > > > > > which auto-detects the archive type. It's much easier to just let it be > > > handled by autodetection, and only bother specifying the archive type > > > manually if the autodetection trips up. > > > > How long has that feature been there? > > I'm as amused as you are that I didn't know about that either (my guess > is it's been there a while and we're just all stuck in our ways). At > least we're not stuck in the 1970s and willing to move with the times - > a lot of people still like to use pipes of the individual utilities ;) I only figured it out last year, actually. By accident I think :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From ghosler at redhat.com Sat Jul 4 08:23:59 2009 From: ghosler at redhat.com (Gregory Hosler) Date: Sat, 04 Jul 2009 16:23:59 +0800 Subject: Building packages for EPEL In-Reply-To: <62bc09df0907030250q41c4f35j2e651e6795077ba7@mail.gmail.com> References: <200906210440.27401.dennis@ausil.us> <4A4DD099.40207@redhat.com> <62bc09df0907030250q41c4f35j2e651e6795077ba7@mail.gmail.com> Message-ID: <4A4F119F.60609@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 SmootherFrOgZ wrote: > On Fri, Jul 3, 2009 at 11:34 AM, Gregory Hosler wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Dennis Gilmore wrote: >>> EPEL is now using koji to build instead of plague. please make sure that you >>> update th common directory in your checkout to pick up the needed changes to >>> submit builds. >> I was able to do builds for EL-4/EL-5 using koji. thanks a lot! >> >>> Bodhi support will come early next week to issue updates. >> Please let us know as and when "make update" will be available. Until then, what >> is the alternative? http://admin.fedoraproject.org/updates ? >> > > "make update" goes to bodhi as well as > "http://admin.fedoraproject.org/updates" which is bodhi UI. > > epel-releng will be taking care of the updates for now. So if I understand things ... once I have I clean make build I can either use bodhi, or drop an email to epel-releng at lists.fedoraproject.org ? (I'm more inclined to use the web interface, but I just want to clarify the alternatives :-) Thanks a lot, and all the best, - -Greg - -- +---------------------------------------------------------------------+ Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler ghosler at redhat.com | +---------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpPEZ0ACgkQ404fl/0CV/QcFgCeLxt7xuzf1fEE+jXdn7aLg2+z ALoAnR41wwoXVLoVcRH79KfoNNHCtU5d =0EgE -----END PGP SIGNATURE----- From harald at redhat.com Sat Jul 4 08:36:14 2009 From: harald at redhat.com (Harald Hoyer) Date: Sat, 04 Jul 2009 10:36:14 +0200 Subject: [ANNOUNCEMENT] dracut-0.4 In-Reply-To: <4A4C92FA.50501@redhat.com> References: <4A4C92FA.50501@redhat.com> Message-ID: <4A4F147E.2080302@redhat.com> Information: https://fedoraproject.org/wiki/Dracut Download: F-11: http://koji.fedoraproject.org/koji/buildinfo?buildID=112941 Rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=112940 Bugs can be filed in bugzilla now: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=dracut root on LVM, MD, cryptoluks, NFS, iSCSI and NBD is supported. From pertusus at free.fr Sat Jul 4 08:41:57 2009 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 4 Jul 2009 10:41:57 +0200 Subject: readline update? In-Reply-To: <4A4E5C2A.7020702@freenet.de> References: <20090703102747.GA32668@localhost> <4A4E5C2A.7020702@freenet.de> Message-ID: <20090704084157.GA4021@free.fr> On Fri, Jul 03, 2009 at 09:29:46PM +0200, Ralf Corsepius wrote: > I thought, we banned all non-utf-8 aware packages? Certainly not. Many very useful package are not utf8 aware, at least many that use motif or the athena widget set. And yes, there are very useful applications in that case. More broadly, in some fields of use, namely in research and maths, english is the main language, so that internationalization isn't that problematic, the cost of utf8-izing those apps isn't worth the benefit. -- Pat From alsadi at gmail.com Sat Jul 4 09:56:12 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Sat, 4 Jul 2009 12:56:12 +0300 Subject: RFE: clean up keyboard layout config Message-ID: <385866f0907040256q1bad84caw3bef357c203cfcae@mail.gmail.com> Hello everybody, I was tracing a problem that was no reproducible getting "Error activating XKB configuration" as I'm not the only one who got this error, just google for it and see some times is could be a result of broken language files https://bugzilla.redhat.com/show_bug.cgi?id=487583 but it's very difficult to trace the problem https://bugzilla.redhat.com/show_bug.cgi?id=508628 what do we want ? 1. we want to a way to select a system wide layout 2. we want to allow users to override that (per-user layout) the problem ? issues solving #1 rhpl - used by fedora-setup-keyboard at compile time [is the any other usage ?] this mean that any update to rhpl needs a rebuild for fedora-setup-keyboard so does koji knows this ? after #487583, rhpl was updated rhpl to put ara and make the variant qwerty passed to ara not us this could result that one can't add new users in first login because the default layout is Arabic fedora-setup-keyboard - beside building issue there is another issue it reads /etc/sysconfig/keyboard which could contain something like KEYTABLE="ar-qwerty" [from rhpl] or detailed parameters like LAYOUT, OPTIONS and VARIANT the question is what happened if both are specified ? the second question which is related to #487583 while setxkbmap manual says it does not support per-layout variants does this apply to fedora-setup-keyboard (and is this inherited from evdev hal interface) if not then it rhpl should be updated to be us,ara with variants=",querty" and if possible change it to be "layout1\tvariant1,layout2\tvariant2" or something like that xkeyboard-config - the arabic part in it, is it difficult to make it defaults to qwerty so that KEYTABLE="ar-qwerty" needs no variants at all, and ar-azerty will be just coupled with fr,ara instead. how to test this ? gnome and gdm should not be used to test this I suggest xfce to test this stage [I used autologin in gdm to stop it from playing withouts] because both gdm and gnome interferes this process --------------------- issues solving #2 gdm - to what options ? unable to login in many cases, for example after #487583 they updated rhpl to put ara first but gdm did not allow me to switch using shifts or shift caps or alt+shift and using a special debug stubs I injected into libgnomekbd, it seems that gdm does not set options like grp:alt_shift_toggle, it just set layouts, gnome - in general we have the following components gnome-settings-daemon - which activates the layout based on gconf /desktop/gnome/peripherals/keyboard/kbd this is the one that shows that dialog in the screenshot control-center - contains gnome-keyboard-properties libgnomekbd - the library that talks to libxklavier and converts to gconf libxklavier - the back end library used by gnome related apps it seems that there is a bug libgnomekbd, because it though that the comma in ara,us should be escaped as it wrote "ara\,us" to gconf when I set multiple variants in /etc/sysconfig/keyboard or rhpl so even though libxklavier and thus libgnomekbd supports multiple variants it failed to import it from the current X -------------- misc issues xorg-x11-utils - contains xprop which is used like this xprop -root | grep XKB xorg-x11-xkb-utils - contains setxkbmap - the man page says that it takes only one single variant not a list of variants does setxkbmap supports multiple variants but it's not documented or it's not supported if it's the first then its man page should be updated with examples it it does not support it how difficult is it to make it support it From laxathom at fedoraproject.org Sat Jul 4 10:02:30 2009 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Sat, 4 Jul 2009 12:02:30 +0200 Subject: Building packages for EPEL In-Reply-To: <4A4F119F.60609@redhat.com> References: <200906210440.27401.dennis@ausil.us> <4A4DD099.40207@redhat.com> <62bc09df0907030250q41c4f35j2e651e6795077ba7@mail.gmail.com> <4A4F119F.60609@redhat.com> Message-ID: <62bc09df0907040302x4c8b421cod4072f4246e642b8@mail.gmail.com> On Sat, Jul 4, 2009 at 10:23 AM, Gregory Hosler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > SmootherFrOgZ wrote: > > On Fri, Jul 3, 2009 at 11:34 AM, Gregory Hosler > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Dennis Gilmore wrote: > >>> EPEL is now using koji to build instead of plague. please make sure > that you > >>> update th common directory in your checkout to pick up the needed > changes to > >>> submit builds. > >> I was able to do builds for EL-4/EL-5 using koji. thanks a lot! > >> > >>> Bodhi support will come early next week to issue updates. > >> Please let us know as and when "make update" will be available. Until > then, what > >> is the alternative? http://admin.fedoraproject.org/updates ? > >> > > > > "make update" goes to bodhi as well as > > "http://admin.fedoraproject.org/updates" which is bodhi UI. > > > > epel-releng will be taking care of the updates for now. > > So if I understand things ... once I have I clean make build I can > either use bodhi, or drop an email to epel-releng at lists.fedoraproject.org? Not really. However, epel support is now available. > (I'm more inclined to use the web interface, but I just want to clarify > the alternatives :-) > > -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From bojan at rexursive.com Sat Jul 4 10:40:03 2009 From: bojan at rexursive.com (Bojan Smojver) Date: Sat, 04 Jul 2009 20:40:03 +1000 Subject: Time for 2.6.30 in F-11? Message-ID: <1246704003.2811.43.camel@shrek.rexursive.com> Now that .1 is out, is there anything in particular stopping F-11 from having this kernel? -- Bojan From ilyes.gouta at gmail.com Sat Jul 4 10:51:15 2009 From: ilyes.gouta at gmail.com (Ilyes Gouta) Date: Sat, 4 Jul 2009 11:51:15 +0100 Subject: Time for 2.6.30 in F-11? In-Reply-To: <1246704003.2811.43.camel@shrek.rexursive.com> References: <1246704003.2811.43.camel@shrek.rexursive.com> Message-ID: <234fa2210907040351u671e3d11n5c4be3b97013da3c@mail.gmail.com> Hi, Users with Intel's integrated chips need the updated DRM in that kernel. I think that an update is highly recommended. -Ilyes On Sat, Jul 4, 2009 at 11:40 AM, Bojan Smojver wrote: > Now that .1 is out, is there anything in particular stopping F-11 from > having this kernel? > > -- > Bojan > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From ngompa13 at gmail.com Sat Jul 4 11:22:15 2009 From: ngompa13 at gmail.com (King InuYasha) Date: Sat, 4 Jul 2009 06:22:15 -0500 Subject: Time for 2.6.30 in F-11? In-Reply-To: <234fa2210907040351u671e3d11n5c4be3b97013da3c@mail.gmail.com> References: <1246704003.2811.43.camel@shrek.rexursive.com> <234fa2210907040351u671e3d11n5c4be3b97013da3c@mail.gmail.com> Message-ID: <8278b1b0907040422g6c3bb75bu16a60e507b98c17@mail.gmail.com> On Sat, Jul 4, 2009 at 5:51 AM, Ilyes Gouta wrote: > Hi, > > Users with Intel's integrated chips need the updated DRM in that > kernel. I think that an update is highly recommended. > > -Ilyes > > On Sat, Jul 4, 2009 at 11:40 AM, Bojan Smojver wrote: > > Now that .1 is out, is there anything in particular stopping F-11 from > > having this kernel? > > > > -- > > Bojan > > > > -- > > 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 > I concur.... I have five laptops and a few desktops with Intel graphics, and it would definitely be great if the update would be pushed through! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rawhide at fedoraproject.org Sat Jul 4 12:34:51 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sat, 4 Jul 2009 12:34:51 +0000 Subject: rawhide report: 20090704 changes Message-ID: <20090704123451.GA18361@releng2.fedora.phx.redhat.com> Compose started at Sat Jul 4 06:15:03 UTC 2009 Updated Packages: bluez-4.43-2.fc12 ----------------- * Fri Jul 03 2009 Bastien Nocera 4.43-1 - Update to 4.43 * Fri Jul 03 2009 Bastien Nocera 4.43-2 - Up the required udev requires so bluetoothd gets started on boot when an adapter is present cbios-0.23-1.fc12 ----------------- * Fri Jul 03 2009 Hans de Goede 0.23-1 - New upstream release 0.23 doxygen-1.5.9-1.fc12 -------------------- * Fri Jul 03 2009 Than Ngo - 1.5.9-1 - 1.5.9 eina-0.8.0-2.fc12 ----------------- * Fri Jul 03 2009 Allisson Azevedo 0.8.0-1 - Update to 0.8.0. - Added curl-devel BR. - Removed patches. * Fri Jul 03 2009 Allisson Azevedo 0.8.0-2 - Fix changelog date. fish-1.23.1-3.fc12 ------------------ * Fri Jul 03 2009 Lorenzo Villani - 1.23.1-1 - 1.23.1 - Fix bz #472613 * Fri Jul 03 2009 Lorenzo Villani - 1.23.1-2 - rebuilt * Fri Jul 03 2009 Lorenzo Villani - 1.23.1-3 - Pass --without-xsel to configure, if you want xsel install its package instead - Fix file list - Drop unneeded BuildRequires gegl-0.1.0-1.fc12 ----------------- * Thu Jul 02 2009 Nils Philippsen - version 0.1.0 - use "--disable-gtk-doc" to avoid rebuilding documentation (#481404) - remove *.la files in %{_libdir}/gegl-*/ (#509292) * Thu Jul 02 2009 Nils Philippsen - 0.1.0-1 - fix cflags for building gnote-0.5.2-2.fc12 ------------------ * Sat Jul 04 2009 Rahul Sundaram - 0.5.2-1 - New upstream bug fix release - http://mail.gnome.org/archives/gnote-list/2009-July/msg00000.html * Sat Jul 04 2009 Rahul Sundaram - 0.5.2-2 - Build requires libuuid-devel instead of e2fsprogs-devel gstreamer-java-1.2-2.fc12 ------------------------- * Fri Jul 03 2009 Levente Farkas - 1.2-2 - don't build debuginfo pacakges since it's actualy a noarch pacakge gyachi-1.2.1-4.fc12 ------------------- * Fri Jul 03 2009 Gregory D Hosler - 1.2.1-4 - Fix double post of YM-9 client text. hunspell-pt-0.20090702-1.fc12 ----------------------------- * Fri Jul 03 2009 Caolan McNamara - 0.20090702-1 - latest pt_BR version ibus-rawcode-1.2.0.20090703-1.fc12 ---------------------------------- * Fri Jul 03 2009 Pravin Satpute - @VERSON at -1 - upstream release 1.2.0 ibus-sayura-1.2.0.20090703-1.fc12 --------------------------------- * Fri Jul 03 2009 Pravin Satpute - @VERSON at -1 - upstream release 1.2.0 kdebase-workspace-4.2.95-6.fc12 ------------------------------- * Fri Jul 03 2009 Kevin Kofler - 4.2.95-6 - add kde-plasma-networkmanagement to the default panel if installed kdelibs-4.2.95-3.fc12 --------------------- * Fri Jul 03 2009 Rex Dieter - 4.2.95-2 - up min versions, phonon, strigi, soprano (#509511) * Fri Jul 03 2009 Rex Dieter - 4.2.95-3 - plasma animation crasher (kdebug#198338) kipi-plugins-0.4.0-1.fc12 ------------------------- * Fri Jul 03 2009 Rex Dieter 0.4.0-1 - kipi-plugins-0.4.0 konversation-1.2-0.2.alpha4.fc12 -------------------------------- * Fri Jul 03 2009 Rex Dieter - 1.2-0.2.alpha4 - konversation-1.2-alpha4 leafnode-1.11.7-2.fc12 ---------------------- * Fri Jul 03 2009 Kevin Fenzi - 1.11.7-2 - Fix xinetd file to use ipv4 for bug #509218 lekhonee-0.6-1.fc12 ------------------- * Fri Jul 03 2009 Kushal Das 0.6-1 - New release libtorrent-0.12.5-1.fc12 ------------------------ * Fri Jul 03 2009 Conrad Meyer - 0.12.5-1 - Bump version. libvirt-0.6.5-1.fc12 -------------------- * Fri Jul 03 2009 Mark McLoughlin - 0.6.4-3.fc12 - Handle shared/readonly image labelling (bug #493692) - Don't unnecessarily try to change a file context (bug #507555) - Don't try to label a disk with no path (e.g. empty cdrom) (bug #499569) * Fri Jul 03 2009 Mark McLoughlin - 0.6.4-4.fc12 - Fix libvirtd crash with bad capabilities data (bug #505635) * Fri Jul 03 2009 Daniel Veillard - 0.6.5-1.fc12 - Upstream release of 0.6.5 - OpenNebula driver - many bug fixes mozplugger-1.12.1-3.fc12 ------------------------ * Fri Jul 03 2009 Than Ngo - 1.12.1-3 - fix #469257, selinux policy and mozplugger do not get along obexd-0.14-1.fc12 ----------------- * Fri Jul 03 2009 Bastien Nocera 0.14-1 - Update to 0.14 ocaml-camlimages-3.0.1-10.fc12 ------------------------------ * Fri Jul 03 2009 Richard W.M. Jones - 3.0.1-10 - ocaml-camlimages: PNG reader multiple integer overflows (CVE 2009-2295 / RHBZ#509531). openoffice.org-3.1.1-15.1.fc12 ------------------------------ * Fri Jul 03 2009 Caol?n McNamara - 1:3.1.1-15.1 - Resolves: rhbz#506984 openoffice.org-3.1.0.ooo103277.vcl.kwinworkaround.patch - next milestone perl-IO-Socket-SSL-1.25-1.fc12 ------------------------------ * Fri Jul 03 2009 Paul Howarth - 1.25-1 - Update to 1.25 (fix t/nonblock.t for OS X 10.5 - CPAN RT#47240) perl-Sysadm-Install-0.29-1.fc12 ------------------------------- * Fri Jul 03 2009 Paul Howarth 0.29-1 - Update to 0.29 - Add proper error handling to print and pipe statements - Fix up some "if $dir" cases to protect against a value of "0" in $dir - Fix up logcroak calls to use the current logger qemu-0.10.50-8.kvm87.fc12 ------------------------- * Fri Jul 03 2009 Mark McLoughlin - 2:0.10.50-8.kvm87 - Prefer sysfs over usbfs for usb passthrough (#508326) rkhunter-1.3.4-7.fc12 --------------------- * Fri Jul 03 2009 Kevin Fenzi - 1.3.4-7 - Add exception for software raid udev file - bug #509253 rtorrent-0.8.5-1.fc12 --------------------- * Fri Jul 03 2009 Conrad Meyer - 0.8.5-1 - Bump version. system-config-printer-1.1.8-5.fc12 ---------------------------------- * Fri Jul 03 2009 Tim Waugh 1.1.8-5 - Use gpk-install-package-name instead of trying to use the D-Bus API. - Spot stopped jobs with CUPS 1.4 as well (trac #177). This, along with the previous fix, addresses bug #509177. - Map gutenprint filenames to the package name. - Fixed sensitivity of class member selection arrows (bug #508653). udev-143-2.fc12 --------------- * Fri Jul 03 2009 Harald Hoyer 143-2 - add acpi floppy modalias - add retrigger of failed events in udev-post.init - killall pids of udev in %pre vim-perl-support-4.4-1.fc12 --------------------------- * Fri Jul 03 2009 Iain Arnell 4.4-1 - update to 4.4 weechat-0.2.6.3-1.fc12 ---------------------- * Thu Jun 25 2009 Paul P. Komkoff Jr - 0.2.6.3-1 - gnutls detection bugfix xfce4-clipman-plugin-1.0.2-1.fc12 --------------------------------- * Fri Jul 03 2009 Christoph Wickert - 1.0.2-1 - Update to 1.0.2 xfce4-notes-plugin-1.7.0-1.fc12 ------------------------------- * Fri Jul 03 2009 Christoph Wickert - 1.7.0-1 - Update to 1.7.0 - Update gtk-update-icon-cache scriptlets xfce4-power-manager-0.8.1-1.fc12 -------------------------------- * Fri Jul 03 2009 Christoph Wickert - 0.8.1-1 - Update to 0.8.1 - Drop libglade2 requirement xfce4-quicklauncher-plugin-1.9.4-5.fc12 --------------------------------------- * Fri Jul 03 2009 Christoph Wickert - 1.9.4-5 - Fix path in desktop file (#509294) xfce4-settings-4.6.1-2.fc12 --------------------------- * Fri Jul 03 2009 Kevin Fenzi - 4.6.1-2 - Update for new libxklavier xfce4-smartbookmark-plugin-0.4.2-9.fc12 --------------------------------------- * Fri Jul 03 2009 Christoph Wickert - 0.4.2-9 - Fix path in desktop file (#509294) xfce4-weather-plugin-0.7.0-1.fc12 --------------------------------- * Fri Jul 03 2009 Christoph Wickert - 0.7.0-1 - Update to 0.7.0 xfce4-websearch-plugin-0.1.1-0.11.20070428svn2704.fc12 ------------------------------------------------------ * Fri Jul 03 2009 Christoph Wickert - 0.1.1-0.11.20070428svn2704 - Fix path in desktop file (#509294) Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 41 From bruno at wolff.to Sat Jul 4 12:55:44 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 4 Jul 2009 07:55:44 -0500 Subject: Time for 2.6.30 in F-11? In-Reply-To: <234fa2210907040351u671e3d11n5c4be3b97013da3c@mail.gmail.com> References: <1246704003.2811.43.camel@shrek.rexursive.com> <234fa2210907040351u671e3d11n5c4be3b97013da3c@mail.gmail.com> Message-ID: <20090704125544.GB3380@wolff.to> On Sat, Jul 04, 2009 at 11:51:15 +0100, Ilyes Gouta wrote: > Hi, > > Users with Intel's integrated chips need the updated DRM in that > kernel. I think that an update is highly recommended. Where do you think the development of those features has been going on? Most of that stuff went into the Fedora version of the kernel during the F11 rawhide cycle. Some of the KMS stuff even goes back to the F10 rawhide cycle. Everyone else is just getting what has already been available in Fedora. From ilyes.gouta at gmail.com Sat Jul 4 13:15:49 2009 From: ilyes.gouta at gmail.com (Ilyes Gouta) Date: Sat, 4 Jul 2009 14:15:49 +0100 Subject: Time for 2.6.30 in F-11? In-Reply-To: <20090704125544.GB3380@wolff.to> References: <1246704003.2811.43.camel@shrek.rexursive.com> <234fa2210907040351u671e3d11n5c4be3b97013da3c@mail.gmail.com> <20090704125544.GB3380@wolff.to> Message-ID: <234fa2210907040615g12c7d23br340fcb6bad0ab40d@mail.gmail.com> Hi, The fact is that F11 shipped with broken Xv support for old Intel chips such as the i855 among other deficiencies. The problem can mainly be attributed to the outdated xorg-drv-x11-intel-2.7.0 that came with F11. A newer version (2.8.0) for that driver exists but also depends on an updated user-space libdrm and kernel DRM for Intel h/w hence the request. xorg-drv-x11-intel should be really updated ASAP. Regards, Ilyes Gouta. On Sat, Jul 4, 2009 at 1:55 PM, Bruno Wolff III wrote: > On Sat, Jul 04, 2009 at 11:51:15 +0100, > ?Ilyes Gouta wrote: >> Hi, >> >> Users with Intel's integrated chips need the updated DRM in that >> kernel. I think that an update is highly recommended. > > Where do you think the development of those features has been going on? > Most of that stuff went into the Fedora version of the kernel during the > F11 rawhide cycle. Some of the KMS stuff even goes back to the F10 > rawhide cycle. Everyone else is just getting what has already been available > in Fedora. > From linuxhippy at gmail.com Sat Jul 4 13:50:01 2009 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Sat, 4 Jul 2009 09:50:01 -0400 Subject: Time for 2.6.30 in F-11? In-Reply-To: <234fa2210907040615g12c7d23br340fcb6bad0ab40d@mail.gmail.com> References: <1246704003.2811.43.camel@shrek.rexursive.com> <234fa2210907040351u671e3d11n5c4be3b97013da3c@mail.gmail.com> <20090704125544.GB3380@wolff.to> <234fa2210907040615g12c7d23br340fcb6bad0ab40d@mail.gmail.com> Message-ID: <194f62550907040650rfdcc917u55aba26c3639195e@mail.gmail.com> Hi, > The fact is that F11 shipped with broken Xv support for old Intel > chips such as the i855 among other deficiencies. The problem can > mainly be attributed to the outdated xorg-drv-x11-intel-2.7.0 that > came with F11. The version in F11 isn't really 2.7, its heavily patched as is the kernel part. In fact the RedHat guys fixed tons of bugs themself, because intel seemed unable to e.g. provide mouse-pointer support for i865 when UXA is used, or to find the cause of sporadic pixmap corruptions. All this was done by RedHat. > A newer version (2.8.0) for that driver exists but also > depends on an updated user-space libdrm and kernel DRM for Intel h/w > hence the request. xorg-drv-x11-intel should be really updated ASAP. As far as I know 2.8.0 hasn't been officially released. I could imaginge they hestitate to replace the patched 2.6.29, until 2.8.0 is released and declared as stable. - Clemens From fedora at camperquake.de Sat Jul 4 13:59:46 2009 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 4 Jul 2009 15:59:46 +0200 Subject: Time for 2.6.30 in F-11? In-Reply-To: <234fa2210907040615g12c7d23br340fcb6bad0ab40d@mail.gmail.com> References: <1246704003.2811.43.camel@shrek.rexursive.com> <234fa2210907040351u671e3d11n5c4be3b97013da3c@mail.gmail.com> <20090704125544.GB3380@wolff.to> <234fa2210907040615g12c7d23br340fcb6bad0ab40d@mail.gmail.com> Message-ID: <20090704155946.4c9daf2b@fred.camperquake.de> Hi. On Sat, 4 Jul 2009 14:15:49 +0100, Ilyes Gouta wrote > The fact is that F11 shipped with broken Xv support for old Intel > chips such as the i855 among other deficiencies. The problem can > mainly be attributed to the outdated xorg-drv-x11-intel-2.7.0 that > came with F11. A newer version (2.8.0) for that driver exists but also > depends on an updated user-space libdrm and kernel DRM for Intel h/w > hence the request. xorg-drv-x11-intel should be really updated ASAP. Given the fact that F11-xorg actually works on my GM45, while rawhide with the mentioned .30 kernel and 2.8 intel driver died various horrible deaths without ever producing a picture makes me question the general usefulness of that update. From kevin.kofler at chello.at Sat Jul 4 14:10:15 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 04 Jul 2009 16:10:15 +0200 Subject: readline update? References: <20090703102747.GA32668@localhost> <4A4E5C2A.7020702@freenet.de> <20090704084157.GA4021@free.fr> Message-ID: Patrice Dumas wrote: > Certainly not. Many very useful package are not utf8 aware Those packages need to be fixed. It is not acceptable that we ship applications which don't work properly in our default locales. You can't even open your files with those broken applications if they're in a directory containing special characters. > at least many that use motif or the athena widget set. Those applications are obsolete by definition. Kevin Kofler From kevin.kofler at chello.at Sat Jul 4 14:12:55 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 04 Jul 2009 16:12:55 +0200 Subject: Time for 2.6.30 in F-11? References: <1246704003.2811.43.camel@shrek.rexursive.com> Message-ID: Bojan Smojver wrote: > Now that .1 is out, is there anything in particular stopping F-11 from > having this kernel? And why is F10 still stuck on 2.6.27? 2.6.29 has been in updates-testing for ages now. Kevin Kofler From drago01 at gmail.com Sat Jul 4 14:26:04 2009 From: drago01 at gmail.com (drago01) Date: Sat, 4 Jul 2009 16:26:04 +0200 Subject: readline update? In-Reply-To: References: <20090703102747.GA32668@localhost> <4A4E5C2A.7020702@freenet.de> <20090704084157.GA4021@free.fr> Message-ID: On Sat, Jul 4, 2009 at 4:10 PM, Kevin Kofler wrote: > Patrice Dumas wrote: >> Certainly not. Many very useful package are not utf8 aware > > Those packages need to be fixed. It is not acceptable that we ship > applications which don't work properly in our default locales. You can't > even open your files with those broken applications if they're in a > directory containing special characters. > >> at least many that use motif or the athena widget set. > > Those applications are obsolete by definition. Sure for most people they are .. same as old gtk1 apps. But who is forcing anybody to use them? They are not installed by default, and adding unicode support to legacy frameworks means breaking API/ABI and the apps would have to be ported. In this case we could as well port them to newer frameworks and be done with it. From dennis at ausil.us Sat Jul 4 14:28:18 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 4 Jul 2009 09:28:18 -0500 Subject: Building packages for EPEL In-Reply-To: <4A4F119F.60609@redhat.com> References: <200906210440.27401.dennis@ausil.us> <62bc09df0907030250q41c4f35j2e651e6795077ba7@mail.gmail.com> <4A4F119F.60609@redhat.com> Message-ID: <200907040928.19577.dennis@ausil.us> On Saturday 04 July 2009 03:23:59 am Gregory Hosler wrote: > SmootherFrOgZ wrote: > > On Fri, Jul 3, 2009 at 11:34 AM, Gregory Hosler wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Dennis Gilmore wrote: > >>> EPEL is now using koji to build instead of plague. please make sure > >>> that you update th common directory in your checkout to pick up the > >>> needed changes to submit builds. > >> > >> I was able to do builds for EL-4/EL-5 using koji. thanks a lot! > >> > >>> Bodhi support will come early next week to issue updates. > >> > >> Please let us know as and when "make update" will be available. Until > >> then, what is the alternative? http://admin.fedoraproject.org/updates ? > > > > "make update" goes to bodhi as well as > > "http://admin.fedoraproject.org/updates" which is bodhi UI. > > > > epel-releng will be taking care of the updates for now. > > So if I understand things ... once I have I clean make build I can > either use bodhi, or drop an email to epel-releng at lists.fedoraproject.org ? > (I'm more inclined to use the web interface, but I just want to clarify > the alternatives :-) Dropping an email to epel-releng is not an option. you need to either create a sn update via "make update" or https://admin.fedoraproject.org/updates/ you should file a ticket https://fedorahosted.org/rel-eng/newticket making sure to select the epel component if you need something tagged into the override tags so you can build against it. 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 fedora at camperquake.de Sat Jul 4 12:53:39 2009 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 4 Jul 2009 14:53:39 +0200 Subject: Time for 2.6.30 in F-11? In-Reply-To: <20090704155946.4c9daf2b@fred.camperquake.de> References: <1246704003.2811.43.camel@shrek.rexursive.com> <234fa2210907040351u671e3d11n5c4be3b97013da3c@mail.gmail.com> <20090704125544.GB3380@wolff.to> <234fa2210907040615g12c7d23br340fcb6bad0ab40d@mail.gmail.com> <20090704155946.4c9daf2b@fred.camperquake.de> Message-ID: <20090704145339.5df6eaad@lain.camperquake.de> Hi. On Sat, 4 Jul 2009 15:59:46 +0200, Ralf Ertzinger wrote > Given the fact that F11-xorg actually works on my GM45, while rawhide > with the mentioned .30 kernel and 2.8 intel driver died various > horrible deaths without ever producing a picture makes me question > the general usefulness of that update. In all fairness I'll have to add that the current rawhide packages as of some minutes ago (kernel, xorg\* and \*drm\*) seem to work, at least I have a working desktop. From zaitcev at redhat.com Sat Jul 4 15:16:50 2009 From: zaitcev at redhat.com (Pete Zaitcev) Date: Sat, 4 Jul 2009 09:16:50 -0600 Subject: rawhide report: 20090703 changes In-Reply-To: <20090703120444.GA22599@releng2.fedora.phx.redhat.com> References: <20090703120444.GA22599@releng2.fedora.phx.redhat.com> Message-ID: <20090704091650.e40718fc.zaitcev@redhat.com> On Fri, 3 Jul 2009 12:04:44 +0000, Rawhide Report wrote: > glibc-2.10.90-2 > --------------- > * Thu Jul 02 2009 Andreas Schwab 2.10.90-2 > - Update from master. > > * Fri Jun 26 2009 Andreas Schwab 2.10.90-1 > - Update from master. > - Enable multi-arch support on x86/x86-64. > - Add requires glibc-headers to glibc-devel (#476295). > - Implement second fallback mode for DNS requests (#505105). > - Don't generate invalid POSIX TZ string for Asia/Dhaka timezone (#506941). > - Allow backtrace through __longjmp_chk on powerpc. This glibc makes all applications to segfault immediately (on x86_64), rendering system unbootable and unrecoverable without external help. I copied glibc files from another box to make my workstation working again. It sure was a fabulous debut as a maintainer for Andreas (according to changelog he took over from Jakub). --Pete From tcallawa at redhat.com Sat Jul 4 16:36:25 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 04 Jul 2009 12:36:25 -0400 Subject: rawhide report: 20090703 changes In-Reply-To: <20090704091650.e40718fc.zaitcev@redhat.com> References: <20090703120444.GA22599@releng2.fedora.phx.redhat.com> <20090704091650.e40718fc.zaitcev@redhat.com> Message-ID: <4A4F8509.8000602@redhat.com> On 07/04/2009 11:16 AM, Pete Zaitcev wrote: > On Fri, 3 Jul 2009 12:04:44 +0000, Rawhide Report wrote: > >> glibc-2.10.90-2 >> --------------- >> * Thu Jul 02 2009 Andreas Schwab 2.10.90-2 >> - Update from master. >> >> * Fri Jun 26 2009 Andreas Schwab 2.10.90-1 >> - Update from master. >> - Enable multi-arch support on x86/x86-64. >> - Add requires glibc-headers to glibc-devel (#476295). >> - Implement second fallback mode for DNS requests (#505105). >> - Don't generate invalid POSIX TZ string for Asia/Dhaka timezone (#506941). >> - Allow backtrace through __longjmp_chk on powerpc. > > This glibc makes all applications to segfault immediately (on x86_64), > rendering system unbootable and unrecoverable without external help. > I copied glibc files from another box to make my workstation working > again. I hit this as well, rolling back to: glibc-2.10.1-2 got me running again. ~spot From jakub at redhat.com Sat Jul 4 16:47:35 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Sat, 4 Jul 2009 18:47:35 +0200 Subject: rawhide report: 20090703 changes In-Reply-To: <4A4F8509.8000602@redhat.com> References: <20090703120444.GA22599@releng2.fedora.phx.redhat.com> <20090704091650.e40718fc.zaitcev@redhat.com> <4A4F8509.8000602@redhat.com> Message-ID: <20090704164735.GY4462@tyan-ft48-01.lab.bos.redhat.com> On Sat, Jul 04, 2009 at 12:36:25PM -0400, Tom spot Callaway wrote: > On 07/04/2009 11:16 AM, Pete Zaitcev wrote: > > On Fri, 3 Jul 2009 12:04:44 +0000, Rawhide Report wrote: > > > >> glibc-2.10.90-2 > >> --------------- > >> * Thu Jul 02 2009 Andreas Schwab 2.10.90-2 > >> - Update from master. > >> > >> * Fri Jun 26 2009 Andreas Schwab 2.10.90-1 > >> - Update from master. > >> - Enable multi-arch support on x86/x86-64. > >> - Add requires glibc-headers to glibc-devel (#476295). > >> - Implement second fallback mode for DNS requests (#505105). > >> - Don't generate invalid POSIX TZ string for Asia/Dhaka timezone (#506941). > >> - Allow backtrace through __longjmp_chk on powerpc. > > > > This glibc makes all applications to segfault immediately (on x86_64), > > rendering system unbootable and unrecoverable without external help. > > I copied glibc files from another box to make my workstation working > > again. > > I hit this as well, rolling back to: glibc-2.10.1-2 got me running again. It is actually prelink, a fixed prelink is in package CVS, but can't be built because libselinux is broken. https://bugzilla.redhat.com/show_bug.cgi?id=509575 Jakub From zaitcev at redhat.com Sat Jul 4 17:01:10 2009 From: zaitcev at redhat.com (Pete Zaitcev) Date: Sat, 4 Jul 2009 11:01:10 -0600 Subject: rawhide report: 20090703 changes In-Reply-To: <20090704164735.GY4462@tyan-ft48-01.lab.bos.redhat.com> References: <20090703120444.GA22599@releng2.fedora.phx.redhat.com> <20090704091650.e40718fc.zaitcev@redhat.com> <4A4F8509.8000602@redhat.com> <20090704164735.GY4462@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <20090704110110.0a6bfb07.zaitcev@redhat.com> On Sat, 4 Jul 2009 18:47:35 +0200, Jakub Jelinek wrote: > > I hit this as well, rolling back to: glibc-2.10.1-2 got me running again. > > It is actually prelink, a fixed prelink is in package CVS, but can't be > built because libselinux is broken. > https://bugzilla.redhat.com/show_bug.cgi?id=509575 Indeed, a gentleman on cc: for bz#509655 pointed out that it's prelink. https://bugzilla.redhat.com/show_bug.cgi?id=509655 -- Pete From debarshi.ray at gmail.com Sat Jul 4 18:00:23 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Sat, 4 Jul 2009 23:30:23 +0530 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: References: <4A4A360F.6040205@cchtml.com> <4A4A37F5.8040403@fedoraproject.org> Message-ID: <3170f42f0907041100v37215019q3aad8fcaf6c68ed1@mail.gmail.com> >>> I don't see a package review request or any koji builds. Are you sure >>> it's coming to Fedora? >> >> Solang developers need to port it to the newer version of libgda first. >> Otherwise it would require a compat package to get into the repository. To be precise, it is actually libgdamm. The 4.x API is something we are not comfortable with, so we need some help to move from 3.x to it. > They also need to support latest version of libexiv2 It is already there in Git. Happy hacking, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig From mcepl at redhat.com Sat Jul 4 19:10:13 2009 From: mcepl at redhat.com (Matej Cepl) Date: Sat, 4 Jul 2009 19:10:13 +0000 (UTC) Subject: readline update? References: <20090703102747.GA32668@localhost> <4A4E5C2A.7020702@freenet.de> Message-ID: Ralf Corsepius, Fri, 03 Jul 2009 21:29:46 +0200: > I thought, we banned all non-utf-8 aware packages? I agree, who needs grep after all :) https://bugzilla.redhat.com/show_bug.cgi?id=194471 Mat?j From mcepl at redhat.com Sat Jul 4 19:11:40 2009 From: mcepl at redhat.com (Matej Cepl) Date: Sat, 4 Jul 2009 19:11:40 +0000 (UTC) Subject: readline update? References: <20090703102747.GA32668@localhost> <4A4E5C2A.7020702@freenet.de> Message-ID: Ralf Corsepius, Fri, 03 Jul 2009 21:29:46 +0200: > I thought, we banned all non-utf-8 aware packages? And BTW zsh has been fixed not to corrupt non-ASCII filenames? Mat?j From kanarip at kanarip.com Sat Jul 4 21:58:52 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 04 Jul 2009 23:58:52 +0200 Subject: Feature proposal: Extended Life Cycle Support Message-ID: <4A4FD09C.7000809@kanarip.com> I wanted to draw your attention to a feature I've proposed for Fedora 12, mysteriously called Extended Life Cycle. You can find more details at https://fedoraproject.org/wiki/Features/Extended_Life_Cycle Kind regards, Jeroen van Meeuwen -kanarip From rjones at redhat.com Sat Jul 4 22:22:52 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 4 Jul 2009 23:22:52 +0100 Subject: an update to automake-1.11? In-Reply-To: <4A4B3D2C.60000@freenet.de> References: <1246385157.8362.127.camel@localhost.localdomain> <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> Message-ID: <20090704222252.GA10230@amd.home.annexia.org> On Wed, Jul 01, 2009 at 12:40:44PM +0200, Ralf Corsepius wrote: > No, not if they bundle the generated auto* files with their tarballs, as > they are supposed to do. They're not "supposed to do" that. Don't make stuff up. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From fedora at camperquake.de Sat Jul 4 22:22:41 2009 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 5 Jul 2009 00:22:41 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <4A4FD09C.7000809@kanarip.com> References: <4A4FD09C.7000809@kanarip.com> Message-ID: <20090705002241.3af46c45@fred.camperquake.de> Hi. On Sat, 04 Jul 2009 23:58:52 +0200, Jeroen van Meeuwen wrote > I wanted to draw your attention to a feature I've proposed for Fedora > 12, mysteriously called Extended Life Cycle. Is it that time of the year again? From bpepple at fedoraproject.org Sat Jul 4 22:39:12 2009 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sat, 04 Jul 2009 18:39:12 -0400 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <20090705002241.3af46c45@fred.camperquake.de> References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> Message-ID: <1246747152.2345.0.camel@localhost.localdomain> On Sun, 2009-07-05 at 00:22 +0200, Ralf Ertzinger wrote: > On Sat, 04 Jul 2009 23:58:52 +0200, Jeroen van Meeuwen wrote > > I wanted to draw your attention to a feature I've proposed for Fedora > > 12, mysteriously called Extended Life Cycle. > > Is it that time of the year again? Geez, I was going to say thing. Didn't we have this discussion about 8 months ago? Later, /B -- Brian Pepple identi.ca: http://identi.ca/bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dr.diesel at gmail.com Sat Jul 4 22:41:17 2009 From: dr.diesel at gmail.com (Dr. Diesel) Date: Sat, 4 Jul 2009 18:41:17 -0400 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <1246747152.2345.0.camel@localhost.localdomain> References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <1246747152.2345.0.camel@localhost.localdomain> Message-ID: <2a28d2ab0907041541g454dfb0m5866656d1101a6d1@mail.gmail.com> On Sat, Jul 4, 2009 at 6:39 PM, Brian Pepple wrote: > On Sun, 2009-07-05 at 00:22 +0200, Ralf Ertzinger wrote: > > On Sat, 04 Jul 2009 23:58:52 +0200, Jeroen van Meeuwen wrote > > > I wanted to draw your attention to a feature I've proposed for Fedora > > > 12, mysteriously called Extended Life Cycle. > > > > Is it that time of the year again? > > Geez, I was going to say thing. Didn't we have this discussion about 8 > months ago? > > Later, > /B > How about "Reduced Life Cycle", I'd like to get to F30 quicker! -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From kanarip at kanarip.com Sat Jul 4 22:41:25 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 05 Jul 2009 00:41:25 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <20090705002241.3af46c45@fred.camperquake.de> References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> Message-ID: <735309ff3d0ab1e6fc11e146c00fded8@localhost> On Sun, 5 Jul 2009 00:22:41 +0200, Ralf Ertzinger wrote: > Hi. > > On Sat, 04 Jul 2009 23:58:52 +0200, Jeroen van Meeuwen wrote >> I wanted to draw your attention to a feature I've proposed for Fedora >> 12, mysteriously called Extended Life Cycle. > > Is it that time of the year again? BINGO! The first response spawns a dead branch to this thread, congratulations! -- Jeroen From julian.fedoralists at googlemail.com Sat Jul 4 23:13:14 2009 From: julian.fedoralists at googlemail.com (Julian Aloofi) Date: Sun, 05 Jul 2009 01:13:14 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <735309ff3d0ab1e6fc11e146c00fded8@localhost> References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> Message-ID: <1246749194.22032.10.camel@Julians-Notebook> https://fedoraproject.org/wiki/Features/Extended_Life_Cycle reads: > Say a desktop environment runs Fedora 9 today, then within a month > after Fedora 11 is released, the user can choose to either upgrade to > Fedora 10 (N+1), or Fedora 11 (N+2). This is not considered a suitable > amount of time for corporate desktop environments, where projects need > to be defined, testing needs to be performed, resources have to be > alocated, etc, before any of the actual work can be done. To be honest, I think environments that work like that won't use Fedora anyway if it wasn't supported for at least three, let's say two and a half, years. People hate work, and it would be a lot of work to maintain 5 or even six parallel versions of Fedora. Maybe something like a Fedora LTS version is more likely to be a success. But hey, I like the idea behind it, let's see how it develops. -------------- 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 kanarip at kanarip.com Sat Jul 4 23:30:46 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 05 Jul 2009 01:30:46 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <1246749194.22032.10.camel@Julians-Notebook> References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> Message-ID: <66bf87684bab0af297fcc12b2f5100f2@localhost> On Sun, 05 Jul 2009 01:13:14 +0200, Julian Aloofi wrote: > https://fedoraproject.org/wiki/Features/Extended_Life_Cycle reads: >> Say a desktop environment runs Fedora 9 today, then within a month >> after Fedora 11 is released, the user can choose to either upgrade to >> Fedora 10 (N+1), or Fedora 11 (N+2). This is not considered a suitable >> amount of time for corporate desktop environments, where projects need >> to be defined, testing needs to be performed, resources have to be >> alocated, etc, before any of the actual work can be done. > > To be honest, I think environments that work like that won't use Fedora > anyway if it wasn't supported for at least three, let's say two and a > half, years. Having to agree with your general statement -not necessarily the exact period- I think neither of us can commit to extending even a single release's life cycle to that extent right now. We'll have to start somewhere, as you'll agree, and so we're thinking of starting out here; 3 releases to maintain in parallel, for those that opt-in, excluding EPEL (which has long term support in all it's aspects already). > People hate work, and it would be a lot of work to maintain 5 or even > six parallel versions of Fedora. Maybe something like a Fedora LTS > version is more likely to be a success. While of course we'd never call it LTS, and while LTS has a very much different value proposition then what is in the current proposal (LTS is just too hard to start with at this moment), the 13 months we have now is most definitely not suitable for corporate environments. Whether 6 months of additional availability of security updates is going to help, and to what extend, we'll have to see. Compared to the current situation, that'll give an environment 7 months to upgrade beyond the moment that we now call End-Of-Life for a given release and 3 releases to choose from -certainly a lot more time then 1 month and 2 releases to choose from. I doubt whether the first six months will meet it's full potential in terms of success since the feature will need to be known to consumers, and just having it available does not make environments use Fedora all of a sudden. That too needs time to settle. Also, I should mention that in my experience, businesses that do choose Fedora despite the requirement of one upgrade per year, tend to upgrade within month 7-9 of a given release as long as you give them the full details on how to make it easier on themselves; (Revisor, optional) -> Cobbler -> Puppet. > But hey, I like the idea behind it, let's see how it develops. Thanks ;-) I'm sure this will be continued ;-) -- Jeroen From a.badger at gmail.com Sat Jul 4 23:53:11 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 04 Jul 2009 16:53:11 -0700 Subject: an update to automake-1.11? In-Reply-To: <20090704222252.GA10230@amd.home.annexia.org> References: <1246385157.8362.127.camel@localhost.localdomain> <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> Message-ID: <4A4FEB67.8070905@gmail.com> On 07/04/2009 03:22 PM, Richard W.M. Jones wrote: > On Wed, Jul 01, 2009 at 12:40:44PM +0200, Ralf Corsepius wrote: >> No, not if they bundle the generated auto* files with their tarballs, as >> they are supposed to do. > > They're not "supposed to do" that. Don't make stuff up. > It's true there are no literal files matching the wildcard "auto*" that are generated for inclusion in the tarballs. But I think Ralf is talking about the files generated by the auto-tools (autoconf, automake, and libtool). Those are supposed to be bundled with the tarballs. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From mrsam at courier-mta.com Sun Jul 5 02:01:48 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sat, 04 Jul 2009 22:01:48 -0400 Subject: an update to automake-1.11? References: <1246385157.8362.127.camel@localhost.localdomain> <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> Message-ID: Toshio Kuratomi writes: > On 07/04/2009 03:22 PM, Richard W.M. Jones wrote: >> On Wed, Jul 01, 2009 at 12:40:44PM +0200, Ralf Corsepius wrote: >>> No, not if they bundle the generated auto* files with their tarballs, as >>> they are supposed to do. >> >> They're not "supposed to do" that. Don't make stuff up. >> > > It's true there are no literal files matching the wildcard "auto*" that > are generated for inclusion in the tarballs. But I think Ralf is > talking about the files generated by the auto-tools (autoconf, automake, > and libtool). Those are supposed to be bundled with the tarballs. And, they are. So, the automake update should not really have any impact on rebuilding any existing well-made rpm package. The only possible impact would be to those packages that rerun automake or autoconf, for some reason. Although I do believe that there's a small number of rpms whose spec script does that, I really think that this is not correct, and the packaging guidelines should really prohibit that. If the configure script needs patching, make a patch against the configure script, and/or Makefile.in; rather than patching configure.in and Makefile.am, and rerun all the auto scripts. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mcepl at redhat.com Sun Jul 5 06:20:38 2009 From: mcepl at redhat.com (Matej Cepl) Date: Sun, 5 Jul 2009 06:20:38 +0000 (UTC) Subject: Feature proposal: Extended Life Cycle Support References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> Message-ID: Jeroen van Meeuwen, Sun, 05 Jul 2009 01:30:46 +0200: > On Sun, 05 Jul 2009 01:13:14 +0200, Julian Aloofi >> To be honest, I think environments that work like that won't use Fedora >> anyway if it wasn't supported for at least three, let's say two and a >> half, years. > > Having to agree with your general statement -not necessarily the exact > period- I think neither of us can commit to extending even a single > release's life cycle to that extent right now. We'll have to start > somewhere, as you'll agree, and so we're thinking of starting out here; > 3 releases to maintain in parallel, for those that opt-in, excluding > EPEL (which has long term support in all it's aspects already). The problem I have with this whole project is that nobody explained me well, why you folks interested in this don't join CentOS project? NIH? Mat?j From gmaxwell at gmail.com Sun Jul 5 06:50:07 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Sun, 5 Jul 2009 02:50:07 -0400 Subject: Time for 2.6.30 in F-11? In-Reply-To: <1246704003.2811.43.camel@shrek.rexursive.com> References: <1246704003.2811.43.camel@shrek.rexursive.com> Message-ID: On Sat, Jul 4, 2009 at 6:40 AM, Bojan Smojver wrote: > Now that .1 is out, is there anything in particular stopping F-11 from > having this kernel? Worth mentioning? .30 makes a non-backwards-compatible BTRFS format change. So if you go .30 on a BTRFS system you can't go back. (though, I suppose that can be seen an argument for getting Fedora to .30 sooner) From drago01 at gmail.com Sun Jul 5 07:44:14 2009 From: drago01 at gmail.com (drago01) Date: Sun, 5 Jul 2009 09:44:14 +0200 Subject: Time for 2.6.30 in F-11? In-Reply-To: References: <1246704003.2811.43.camel@shrek.rexursive.com> Message-ID: On Sun, Jul 5, 2009 at 8:50 AM, Gregory Maxwell wrote: > On Sat, Jul 4, 2009 at 6:40 AM, Bojan Smojver wrote: >> Now that .1 is out, is there anything in particular stopping F-11 from >> having this kernel? > > Worth mentioning? .30 makes a non-backwards-compatible BTRFS format change. > > So if you go .30 on a BTRFS system you can't go back. > > (though, I suppose that can be seen an argument for getting Fedora to > .30 sooner) brtfs support was always "if you care about data than don't use it or make backups" From frankly3d at gmail.com Sun Jul 5 08:20:50 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Sun, 05 Jul 2009 09:20:50 +0100 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> Message-ID: <4A506262.9010907@gmail.com> On 05/07/09 07:20, Matej Cepl wrote: > Jeroen van Meeuwen, Sun, 05 Jul 2009 01:30:46 +0200: > > > The problem I have with this whole project is that nobody explained me > well, why you folks interested in this don't join CentOS project? NIH? > > Mat?j > Possibly because CentOS is not Fedora. Frank From fedora at leemhuis.info Sun Jul 5 08:02:18 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 05 Jul 2009 10:02:18 +0200 Subject: Time for 2.6.30 in F-11? In-Reply-To: References: <1246704003.2811.43.camel@shrek.rexursive.com> Message-ID: <4A505E0A.4050408@leemhuis.info> CCing #fedora-kernel-list On 04.07.2009 16:12, Kevin Kofler wrote: > Bojan Smojver wrote: >> Now that .1 is out, is there anything in particular stopping F-11 from >> having this kernel? > And why is F10 still stuck on 2.6.27? 2.6.29 has been in updates-testing for > ages now. Good question. Seems the "ship state-of-the-art/nearly latest kernel versions from kernel.org as regular update for Fedora" worked much better in the past. Is that for a specific reason or just a side effect of something (maintainer/responsibly changes maybe?). And yes, I know it's a lot of work to prepare updates from 2.6.x.y to 2.6.(x+1).y. So thx for that work -- it IMHO is definitely worth it as it makes people get drivers for new hardware without forcing them to switch to rawhide. That, btw and afaics, for quite some people was one of the reasons to chose Fedora. I for example use Fedora for testing at work mainly because I got latest kernels on Fedora automatically. Cu knurd From kanarip at kanarip.com Sun Jul 5 10:03:05 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 05 Jul 2009 12:03:05 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> Message-ID: <66ff0543780f93d7f263af099cd22e1d@localhost> On Sun, 5 Jul 2009 06:20:38 +0000 (UTC), Matej Cepl wrote: > Jeroen van Meeuwen, Sun, 05 Jul 2009 01:30:46 +0200: > >> On Sun, 05 Jul 2009 01:13:14 +0200, Julian Aloofi >>> To be honest, I think environments that work like that won't use Fedora >>> anyway if it wasn't supported for at least three, let's say two and a >>> half, years. >> >> Having to agree with your general statement -not necessarily the exact >> period- I think neither of us can commit to extending even a single >> release's life cycle to that extent right now. We'll have to start >> somewhere, as you'll agree, and so we're thinking of starting out here; >> 3 releases to maintain in parallel, for those that opt-in, excluding >> EPEL (which has long term support in all it's aspects already). > > The problem I have with this whole project is that nobody explained me > well, why you folks interested in this don't join CentOS project? NIH? > The CentOS project, or it's upstream, has a release cycle of approximately three years -not a steady release cycle of three years but that's what it turns out to be. This disqualifies the distribution(s) as desktop Linux distributions, as desktops tend to need to run the latest and greatest for as far the latest and greatest lets them. Does that make sense? Kind regards, Jeroen van Meeuwen -kanarip From jos at xos.nl Sun Jul 5 10:12:45 2009 From: jos at xos.nl (Jos Vos) Date: Sun, 5 Jul 2009 12:12:45 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <66ff0543780f93d7f263af099cd22e1d@localhost> References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> <66ff0543780f93d7f263af099cd22e1d@localhost> Message-ID: <20090705101245.GA10184@jasmine.xos.nl> On Sun, Jul 05, 2009 at 12:03:05PM +0200, Jeroen van Meeuwen wrote: > The CentOS project, or it's upstream, has a release cycle of approximately > three years -not a steady release cycle of three years but that's what it > turns out to be. This disqualifies the distribution(s) as desktop Linux > distributions, as desktops tend to need to run the latest and greatest for > as far the latest and greatest lets them. I don't completely agree that "desktops tend to need to run the latest and greatest" (when we're talking about business desktops), but desktops (especially also when talking about laptops because of HW compatibilities) need newer software than RHEL offers, based on now 3 year old base versions of most packages (except Firefox and a few others). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From kanarip at kanarip.com Sun Jul 5 10:32:59 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 05 Jul 2009 12:32:59 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <20090705101245.GA10184@jasmine.xos.nl> References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> <66ff0543780f93d7f263af099cd22e1d@localhost> <20090705101245.GA10184@jasmine.xos.nl> Message-ID: <4A50815B.7070300@kanarip.com> On 07/05/2009 12:12 PM, Jos Vos wrote: > On Sun, Jul 05, 2009 at 12:03:05PM +0200, Jeroen van Meeuwen wrote: > >> The CentOS project, or it's upstream, has a release cycle of approximately >> three years -not a steady release cycle of three years but that's what it >> turns out to be. This disqualifies the distribution(s) as desktop Linux >> distributions, as desktops tend to need to run the latest and greatest for >> as far the latest and greatest lets them. > > I don't completely agree that "desktops tend to need to run the latest and > greatest" (when we're talking about business desktops), but desktops > (especially also when talking about laptops because of HW compatibilities) > need newer software than RHEL offers, based on now 3 year old base versions > of most packages (except Firefox and a few others). > Agreed, I exaggerated a little there ;-) What I meant is they tend to need to run the latest and greatest *compared* to servers, and as you said, especially laptops and newer hardware. -- Jeroen From dwmw2 at infradead.org Sun Jul 5 10:39:44 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 05 Jul 2009 11:39:44 +0100 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <66ff0543780f93d7f263af099cd22e1d@localhost> References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> <66ff0543780f93d7f263af099cd22e1d@localhost> Message-ID: <1246790384.6295.13.camel@macbook.infradead.org> On Sun, 2009-07-05 at 12:03 +0200, Jeroen van Meeuwen wrote: > The CentOS project, or it's upstream, has a release cycle of approximately > three years -not a steady release cycle of three years but that's what it > turns out to be. This disqualifies the distribution(s) as desktop Linux > distributions, as desktops tend to need to run the latest and greatest for > as far the latest and greatest lets them. > > Does that make sense? As a standalone observation, perhaps -- some desktop users often don't want old, stagnant code; they'd prefer the latest bells and whistles. But it makes no sense when considered in conjunction with your apparent desire for an old, stagnant version of Fedora. What makes you think it would be any different? It's not exactly difficult or problematic to update from one version of Fedora to the next. I do it on each of my servers at least once a year (I usually skip a release, but not always). And those are mostly headless, remote boxes. If you want new stuff, run Fedora and do a fairly painless update annually. If you want old stuff, run Centos and update less frequently. I don't see any need for a middle ground. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation From rawhide at fedoraproject.org Sun Jul 5 11:21:58 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sun, 5 Jul 2009 11:21:58 +0000 Subject: rawhide report: 20090705 changes Message-ID: <20090705112158.GA32600@releng2.fedora.phx.redhat.com> Compose started at Sun Jul 5 06:15:06 UTC 2009 New package oflb-notcouriersans-fonts NotCourier Sans is a re-interpretation of Nimbus Mono Updated Packages: abiword-2.7.6-2.fc12 -------------------- * Sun Jul 05 2009 Peter Robinson - 1:2.7.6-1 - New upstream release * Sun Jul 05 2009 Peter Robinson - 1:2.7.6-2 - Remove old patch bognor-regis-0.4.6-1.fc12 ------------------------- * Sat Jul 04 2009 Peter Robinson 0.4.6-1 - New upstream release bouml-4.13-1.fc12 ----------------- * Sat Jul 04 2009 Debarshi Ray - 4.13-1 - Version bump to 4.13. * Added active on activity, class and state. * Browser search can now search for elements depending on their stereotype. * Duplicating a state caused a crash. Fixed. * Made it easier to select small elements connectd to a line in a diagram. * When an attribute or operation of a class was deleted from a plug-out, the drawing of the class was not updated in already opened diagrams. Fixed. * C++ Generator: + A dependency stereotyped as friend produced wrong code in case the target class was a template. Fixed. * Java Roundtrip: + New plug-out. * Plug-out: + A crash occured when upgrading an old plug-out without Python management. Fixed. + Added operations isActive and set_isActive to UmlBaseActivity, UmlBaseClass and UmlBaseState. + Added operations isPython_3_operation and set_IsPython_3_operation to PythonSettings. + Internal plug-out API extended for Java Roundtrip, and type specification of function's parameters and return values. All plug-outs updated to use the new API. + The operation importProject has been added to UmlBasePackage, which returns the UmlPackage corresponding to the imported project or null in case of an error. * Python Generator: + All the lines of a docstring are indented according to PEP-0257. + Manage type specification of function's parameters return values according to PEP-3107. * XMI Generator: + When a parameter of an operation doesn't have type the token UML:Parameter was not closed. Fixed. * XMI2 Generator: + The base type of a class stereotyped typedef is now produced in an extension form supposing you ask for them. claws-mail-3.7.2-1.fc12 ----------------------- * Sat Jul 04 2009 Andreas Bierfert - 3.7.2-1 - version upgrade - drop gssapi patch -> upstream cuetools-1.4.0-0.4.svn305.fc12 ------------------------------ * Fri May 08 2009 Todd Zullinger - 1.4.0-0.4.svn305 - cuetag.sh: Fix metaflac options for flac >= 1.1.3 (bug 488586) - cuetag.sh: Fix handling of files with spaces (bug 499910) - cuetag.sh: Correct typo in error output diffuse-0.3.4-1.fc12 -------------------- * Sat Jul 04 2009 Jon Levell - 0.3.4-1 - Update to new upstream release (patch no longer needed) dracut-0.4-1.fc12 ----------------- * Sat Jul 04 2009 Harald Hoyer 0.4-1 - version 0.4 hugs98-2006.09-6.fc12 --------------------- * Fri Jul 03 2009 Gerard Milmeister - 2006.09-6 - added alternatives setup for runhaskell and friends icu-4.2.1-1.fc12 ---------------- * Fri Jul 03 2009 Caolan McNamara - 4.2.1-1 - 4.2.1 release jd-2.4.1-0.2.svn2925_trunk.fc12 ------------------------------- * Sun Jul 05 2009 Mamoru Tasaka - rev 2925 kdegames-4.2.95-2.fc12 ---------------------- * Sat Jul 04 2009 Kevin Kofler - 4.2.95-2 - reenable and rebrand the ship sinking game and the snake duel game (#502359) kernel-2.6.31-0.42.rc2.fc12 --------------------------- * Sat Jul 04 2009 Chuck Ebbert - 2.6.31-rc1-git11 * Sat Jul 04 2009 Dave Jones 2.6.31-0.42.rc2 - 2.6.31-rc2 * Fri Jul 03 2009 Hans de Goede - Disable v4l1 ov511 and quickcam_messenger drivers (obsoleted by v4l2 gspca subdrivers) moreutils-0.35-1.fc12 --------------------- * Sat Jul 04 2009 Marc Bradshaw 0.35-1.fc12 - new upstream version 0.35 released with these changes - * ifdata: Don't assume that all interface names are 6 characters or less, for instance "wmaster0" is longer. - Increase the limit to 20 characters. Closes: #526654 (Thanks, Alan Pope) - * isutf8: Reject UTF-8-encoded UTF-16 surrogates. Closes: #525301 (Thanks, Jakub Wilk and liw) openlayers-2.8-1.fc12 --------------------- * Sun Jun 28 2009 Mathieu Bridon - 2.8-1 - New upstream version: 2.8 - see http://trac.openlayers.org/wiki/Release/2.8/Notes perl-IO-Socket-SSL-1.26-1.fc12 ------------------------------ * Sat Jul 04 2009 Paul Howarth - 1.26-1 - Update to 1.26 (verify_hostname_of_cert matched only the prefix for the hostname when no wildcard was given, e.g. www.example.org matched against a certificate with name www.exam in it) pyabiword-0.7.6-1.fc12 ---------------------- * Sun Jul 05 2009 Peter Robinson - 0.7.6-1 - Upgrade to pyabiword 0.7.6 python-2.6-10.fc12 ------------------ * Sat Jul 04 2009 Jonathan Steffan - 2.6-10 - Move python-config to devel subpackage (#506153) - Update BuildRoot for new standard * Sun Jun 28 2009 Jonathan Steffan - 2.6-9 - Update python-tools description (#448940) * Wed Apr 15 2009 Ignacio Vazquez-Abrams 2.6-8 - Replace python-hashlib and python-uuid (#484715) siege-2.69-1.fc12 ----------------- * Sat Jul 04 2009 Allisson Azevedo 2.69-1 - Update to 2.69 - Update Makefile.in patch sipwitch-0.5.6-0.fc12 --------------------- * Sat Jul 04 2009 - David Sugar - 0.5.6-0 - split runtime from server to build plugins without requiring server. - removed separate rtp proxy, functionality will be integrated into server. webkitgtk-1.1.10-2.fc12 ----------------------- * Sat Jul 04 2009 Peter Gordon - 1.1.10-2 - Invoke chrpath to remove the hardcoded RPATH in GtkLauncher. - Remove unnecessary libtool build dependency. Summary: Added Packages: 1 Removed Packages: 0 Modified Packages: 20 From brad.longo at gmail.com Sun Jul 5 12:47:43 2009 From: brad.longo at gmail.com (Brad) Date: Sun, 05 Jul 2009 08:47:43 -0400 Subject: [Fwd: Re: vPython] In-Reply-To: <469E6BB7.2070103@redhat.com> References: <469E6BB7.2070103@redhat.com> Message-ID: <4A50A0EF.7040804@gmail.com> I have rpms for older versions of vpython and a tutorial on how to make rpms. Here is some information that might be useful(http://rpmbuildtut.wordpress.com/). Let me know if you need any help. ?Brad Longo North Carolina State University Aerospace Engineering/Applied Mathematics Raleigh, NC USA 862.266.7066 brad.longo at gmail.com Casey Dahlin wrote > > > -------- Original Message -------- > Subject: Re: vPython > Date: Fri, 13 Jul 2007 10:54:50 -0400 (EDT) > From: Greg Dekoenigsberg > To: Casey Dahlin > References: <46979159.2050605 at redhat.com> > > > > On Fri, 13 Jul 2007, Casey Dahlin wrote: > >> At NCSU, nearly every student in every department codes a small >> subset of python once during their studies. This is due to the >> physics department's use of a library called vPython. vPython is >> simply a 3d library. Its capabilities are very limited but it is >> extremely simple to use. Basically any student who takes a physics >> lab at state (usually a general education requirement) learns to >> model physics problems in vPython (admittedly without ever seeing so >> much as a conditional or loop). >> >> I bring this up because vPython is very very difficult to install on >> Fedora. there is no RPM, and many of the dependencies for building >> the source are very difficult to resolve due to conflicts etc. >> However I do have a friend who has found a procedure to do it. What >> would be the process for getting vPython included as a package in >> Fedora? It'd be one step closer to getting the Physics people off of >> win2k. > > It is not a simple process. It should probably be simpler. But it's > not rocket science, either. It's documented here: > > http://fedoraproject.org/wiki/PackageMaintainers/Join > > If you'd like to do this, I'd really appreciate a newbie's detailed > impressions of the process of joining the world of Fedora packagers. :) > > --g > From rjones at redhat.com Sun Jul 5 13:16:55 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Sun, 5 Jul 2009 14:16:55 +0100 Subject: an update to automake-1.11? In-Reply-To: References: <1246385157.8362.127.camel@localhost.localdomain> <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> Message-ID: <20090705131655.GA21540@amd.home.annexia.org> On Sat, Jul 04, 2009 at 10:01:48PM -0400, Sam Varshavchik wrote: > Although I do believe that there's a small number of rpms whose spec > script does that, I really think that this is not correct, and the > packaging guidelines should really prohibit that. If the configure script > needs patching, make a patch against the configure script, and/or > Makefile.in; rather than patching configure.in and Makefile.am, and rerun > all the auto scripts. There's been lots of previous discussion of this silly idea of patching generated code. You end up carrying enormous patches containing just line number changes that often can't be applied upstream, and can't be carried forward to new upstream releases -- what on earth use is that? And still no one has explained coherently why the sky will fall if we patch configure.ac and Makefile.am and just rerun autoconf/automake in the specfile. Earlier thread here if you have the stomach for it: http://www.redhat.com/archives/fedora-devel-list/2008-October/thread.html#00467 Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From opensource at till.name Sun Jul 5 14:37:02 2009 From: opensource at till.name (Till Maas) Date: Sun, 05 Jul 2009 16:37:02 +0200 Subject: an update to automake-1.11? In-Reply-To: <20090705131655.GA21540@amd.home.annexia.org> References: <1246385157.8362.127.camel@localhost.localdomain> <20090705131655.GA21540@amd.home.annexia.org> Message-ID: <200907051637.08456.opensource@till.name> On Sun July 5 2009, Richard W.M. Jones wrote: > There's been lots of previous discussion of this silly idea of > patching generated code. You end up carrying enormous patches > containing just line number changes that often can't be applied > upstream, and can't be carried forward to new upstream releases -- > what on earth use is that? And still no one has explained coherently > why the sky will fall if we patch configure.ac and Makefile.am and > just rerun autoconf/automake in the specfile. There is also the third alternative to patch configure.ac and Makefile.am, send the patches upstream, then run autoconf/automake once to get a patch for the upstream tarball and use this patch inside the spec. The patch in the spec may still be big, but it does not hurt anyone afaics. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mrsam at courier-mta.com Sun Jul 5 14:45:46 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sun, 05 Jul 2009 10:45:46 -0400 Subject: an update to automake-1.11? References: <1246385157.8362.127.camel@localhost.localdomain> <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> Message-ID: Richard W.M. Jones writes: > There's been lots of previous discussion of this silly idea of > patching generated code. You end up carrying enormous patches > containing just line number changes that often can't be applied > upstream, and can't be carried forward to new upstream releases -- What line number changes? You cut a patch against configure, and you're done. That's it. When a later release rolls down the pike, the patch gets rebased, and fixed up, against a newer version. I fail to see any substantive difference between that, and patching any other file in the source tarball. With a subsequent release, you'll still have to rebase your existing patch, if the new release did not fix the original bug. As I understand, rpm's default settings now reject fuzz in patch files, so you'll just have to do it, now. And since the likelyhood of configure changing in a new release is no different than any other source file getting changed, on average, believing that some work can be saved just by choosing to patch a different file, then the one that really needs to be patched, is somewhat naive. > what on earth use is that? And still no one has explained coherently > why the sky will fall if we patch configure.ac and Makefile.am and > just rerun autoconf/automake in the specfile. Because autoconf and automake are going to change a lot more than just what the patch was intended to patch. It's fairly likely that the upstream is using a different version of autoconf and automake, so this ends up producing a brand new configure and makefile. If I were to do that, then I would find it necessary to spend additional time testing the new configure script, running it an eyeballing all of its voluminous output, watching for something that falls out, as a result of the new configure script. Dunno, it just seems much easier to me to just patch a single line in configure, adding or fixing some directory's name, then to do all that. I get the impression that there's a meme going around that patching configure is some kind of a herculean, impossible task, and that's its easier to patch configure.in, then run autoconf to generate a brand new configure script. I suppose that there may be some situations where rebuilding the configure script is the right thing to do, but I wouldn't expect to have this happen very often. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From nushio at fedoraproject.org Sun Jul 5 15:29:33 2009 From: nushio at fedoraproject.org (Juan Rodriguez) Date: Sun, 5 Jul 2009 10:29:33 -0500 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <1246790384.6295.13.camel@macbook.infradead.org> References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> <66ff0543780f93d7f263af099cd22e1d@localhost> <1246790384.6295.13.camel@macbook.infradead.org> Message-ID: On Sun, Jul 5, 2009 at 5:39 AM, David Woodhouse wrote: > On Sun, 2009-07-05 at 12:03 +0200, Jeroen van Meeuwen wrote: > > The CentOS project, or it's upstream, has a release cycle of > approximately > > three years -not a steady release cycle of three years but that's what it > > turns out to be. This disqualifies the distribution(s) as desktop Linux > > distributions, as desktops tend to need to run the latest and greatest > for > > as far the latest and greatest lets them. > > > > Does that make sense? > > As a standalone observation, perhaps -- some desktop users often don't > want old, stagnant code; they'd prefer the latest bells and whistles. > > But it makes no sense when considered in conjunction with your apparent > desire for an old, stagnant version of Fedora. > > What makes you think it would be any different? > > It's not exactly difficult or problematic to update from one version of > Fedora to the next. I do it on each of my servers at least once a year > (I usually skip a release, but not always). And those are mostly > headless, remote boxes. > > If you want new stuff, run Fedora and do a fairly painless update > annually. If you want old stuff, run Centos and update less frequently. > > I don't see any need for a middle ground. > > -- > David Woodhouse Open Source Technology Centre > David.Woodhouse at intel.com Intel Corporation > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Out of curiosity, don't we have an Extended Life Cycle Fedora version called Red Hat Enterprise Linux and/or CentOS and/or dozens of other similar distros? Why duplicate efforts? Just so it goes under the name "Fedora"? -- Ing. Juan M. Rodriguez Moreno Desarrollador de Sistemas Abiertos Sitio: http://proyectofedora.org/mexico -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonstanley at gmail.com Sun Jul 5 15:46:15 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Sun, 5 Jul 2009 11:46:15 -0400 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <20090705101245.GA10184@jasmine.xos.nl> References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> <66ff0543780f93d7f263af099cd22e1d@localhost> <20090705101245.GA10184@jasmine.xos.nl> Message-ID: On Sun, Jul 5, 2009 at 6:12 AM, Jos Vos wrote: > I don't completely agree that "desktops tend to need to run the latest and > greatest" (when we're talking about business desktops), but desktops I don't agree with that position either - note my work laptop, which unfortunately runs Windows. However, just to make a point, it runs Windows XP Pro, and Office 2003 - hardly the latest and greatest that Microsoft has to offer. A RHEL 5 desktop would provide me similarly aged (or newer) software. RHEL/CentOS also gets hardware enablement throughout it's lifecycle, so the "newer laptops need newer software" only holds true through the beginning of the Production 2 support phase at minimum, by which time the next release of RHEL should be available (for RHEL 5, this date is 3/31/2011) From kanarip at kanarip.com Sun Jul 5 15:52:14 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 05 Jul 2009 17:52:14 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <1246790384.6295.13.camel@macbook.infradead.org> References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> <66ff0543780f93d7f263af099cd22e1d@localhost> <1246790384.6295.13.camel@macbook.infradead.org> Message-ID: On Sun, 05 Jul 2009 11:39:44 +0100, David Woodhouse wrote: > On Sun, 2009-07-05 at 12:03 +0200, Jeroen van Meeuwen wrote: >> The CentOS project, or it's upstream, has a release cycle of >> approximately >> three years -not a steady release cycle of three years but that's what it >> turns out to be. This disqualifies the distribution(s) as desktop Linux >> distributions, as desktops tend to need to run the latest and greatest >> for >> as far the latest and greatest lets them. >> >> Does that make sense? > > As a standalone observation, perhaps -- some desktop users often don't > want old, stagnant code; they'd prefer the latest bells and whistles. > > But it makes no sense when considered in conjunction with your apparent > desire for an old, stagnant version of Fedora. > > What makes you think it would be any different? > As described on the Feature page, but if there's any specific questions about the reasoning on there I'll be happy to answer those questions. -- Jeroen From fedora at matbooth.co.uk Sun Jul 5 17:40:37 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Sun, 5 Jul 2009 18:40:37 +0100 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <66ff0543780f93d7f263af099cd22e1d@localhost> References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> <66ff0543780f93d7f263af099cd22e1d@localhost> Message-ID: <9497e9990907051040u6c36bd0bjd9b0be44afe8123c@mail.gmail.com> On Sun, Jul 5, 2009 at 11:03 AM, Jeroen van Meeuwen wrote: > > The CentOS project, or it's upstream, has a release cycle of approximately > three years -not a steady release cycle of three years but that's what it > turns out to be. This disqualifies the distribution(s) as desktop Linux > distributions, as desktops tend to need to run the latest and greatest for > as far the latest and greatest lets them. > > Does that make sense? > No, it doesn't make a great deal of sense. You say a market for this is the corporate desktop, but a government department I work with runs their scientific desktops on RHEL 4. They have a lot of in-house apps that are known to work on that platform. There is absolutely no sense in expending resources on switching to a newer version until that version's EOL is in sight. -- Mat Booth www.matbooth.co.uk From jos at xos.nl Sun Jul 5 17:53:57 2009 From: jos at xos.nl (Jos Vos) Date: Sun, 5 Jul 2009 19:53:57 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <9497e9990907051040u6c36bd0bjd9b0be44afe8123c@mail.gmail.com> References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> <66ff0543780f93d7f263af099cd22e1d@localhost> <9497e9990907051040u6c36bd0bjd9b0be44afe8123c@mail.gmail.com> Message-ID: <20090705175357.GA14272@jasmine.xos.nl> On Sun, Jul 05, 2009 at 06:40:37PM +0100, Mat Booth wrote: > No, it doesn't make a great deal of sense. You say a market for this > is the corporate desktop, but a government department I work with runs > their scientific desktops on RHEL 4. They have a lot of in-house apps > that are known to work on that platform. There is absolutely no sense > in expending resources on switching to a newer version until that > version's EOL is in sight. But these requirements are certainly not the same for every customer. One desktop customer running RHEL5 already complains about the version of OpenOffice. For that reason (and some others) we are thinking of migrating their desktops (not their server) to F11. And using OpenOffice (and requiring maximal MS-Office compatibility for communicating with the evil world) can't be seen as an exotic requirement for a desktop, IMHO... -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From cemeyer at u.washington.edu Sun Jul 5 18:11:35 2009 From: cemeyer at u.washington.edu (Conrad Meyer) Date: Sun, 5 Jul 2009 11:11:35 -0700 Subject: an update to automake-1.11? In-Reply-To: References: <1246385157.8362.127.camel@localhost.localdomain> <20090705131655.GA21540@amd.home.annexia.org> Message-ID: <200907051111.36123.cemeyer@u.washington.edu> On Sunday 05 July 2009 07:45:46 am Sam Varshavchik wrote: > *snip* > > With a subsequent release, you'll still > have to rebase your existing patch, if the new release did not fix the > original bug. As I understand, rpm's default settings now reject fuzz in > patch files, so you'll just have to do it, now. And since the likelyhood of > configure changing in a new release is no different than any other source > file getting changed, on average, believing that some work can be saved > just by choosing to patch a different file, then the one that really needs > to be patched, is somewhat naive. The problem is that configure scripts are not written by a human, but generated by autoconf. It is easy to make small changes to configure.ac and generate large changes in configure. This makes it easier to rebase patches against configure.ac. Regards, -- Conrad Meyer From andreas.tunek at gmail.com Sun Jul 5 18:19:28 2009 From: andreas.tunek at gmail.com (Andreas Tunek) Date: Sun, 5 Jul 2009 20:19:28 +0200 Subject: Better ways to format USB disks (file fomats etc) Message-ID: I bought a new shiny red 500 GB USB HDD recently in order to back up large files (mostly video but other stuff as well). My previous HDDs I formatted as fat32 since that can be read and written by most devices (PS3, Windows, Mac etc). Since I would only use this new HDD with my different computers running fedora I thought I could use a more modern file system like ext3 or ext4. This would allow me to have larger files (and also maybe better performance). However, I would like to have the extremely high usability/minimal security of fat32 (anyone who mounts the disk can read and write everything on the disk) and it seems that this is not possible using ext3/ext4. So I ended up using ntfs..... I feel this is a bit of loss for free software in general and fedora in particular and I hope something could be done at the situation. So I have the following questions: 1: Are there already ways to do what I want and I have just missed it? 2: Are there any others who have this need or am I just weird. Do people really need permissions on all their disk or is it more convenient if some disks are totally open? If I am the only one who wants this there is no need to do any work. 3: What can be done? Do we need to create a "Permissionless ext4" or are there any simpler options? Could we maybe make an option to set all mounted USB drives so that all users can write and read anything on them? Or are the any better ways to achive what I want? Best regards Andreas Tunek From frankly3d at gmail.com Sun Jul 5 18:22:39 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Sun, 05 Jul 2009 19:22:39 +0100 Subject: Better ways to format USB disks (file fomats etc) In-Reply-To: References: Message-ID: <4A50EF6F.6040604@gmail.com> snipped> Since I would only use this new HDD with my > different computers running fedora I thought I could use a more > modern file system like ext3 or ext4. This would allow me to have > larger files (and also maybe better performance). However, I would > like to have the extremely high usability/minimal security of fat32 > (anyone who mounts the disk can read and write everything on the disk) > and it seems that this is not possible using ext3/ext4. So I ended up > using ntfs..... > > I have used luxs ext3 usb disks, on WinXP systems, and was prompted for the password to use them. Frank From mrsam at courier-mta.com Sun Jul 5 18:24:43 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sun, 05 Jul 2009 14:24:43 -0400 Subject: an update to automake-1.11? References: <1246385157.8362.127.camel@localhost.localdomain> <20090705131655.GA21540@amd.home.annexia.org> <200907051111.36123.cemeyer@u.washington.edu> Message-ID: Conrad Meyer writes: > On Sunday 05 July 2009 07:45:46 am Sam Varshavchik wrote: >> *snip* >> >> With a subsequent release, you'll still >> have to rebase your existing patch, if the new release did not fix the >> original bug. As I understand, rpm's default settings now reject fuzz in >> patch files, so you'll just have to do it, now. And since the likelyhood of >> configure changing in a new release is no different than any other source >> file getting changed, on average, believing that some work can be saved >> just by choosing to patch a different file, then the one that really needs >> to be patched, is somewhat naive. > > The problem is that configure scripts are not written by a human, but > generated by autoconf. It is easy to make small changes to configure.ac and > generate large changes in configure. This makes it easier to rebase patches > against configure.ac. The macros in configure.ac generally expand out to canned shell script fragments, with the macro's parameters substituted somewhere. Changing a parameter in configure.ac usually results in an equivalent substitution in configure. Generally, only when one adds or removes entire macros from configure.ac, that's when this results in wholesale changes to configure. In my experience, the overwhelming majority of fixups to configure scripts involve nothing more than adjusting someone's pathname, or compiler flags. For this kind of scope, rebuilding the entire configure script is overkill, and I wouldn't do it unless I audit it and verify whether or not upstream is relying on some specific behavior in the specific version of autoconf that was used to build the original configure script. Patching the configure script is much safer than patching configure.ac, then have autoconf grok all .m4 macros and rebuild the whole thing, likely ending up with a completely different beast, that not only includes your changes but who knows what else. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From kanarip at kanarip.com Sun Jul 5 18:27:14 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 05 Jul 2009 20:27:14 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <9497e9990907051040u6c36bd0bjd9b0be44afe8123c@mail.gmail.com> References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> <66ff0543780f93d7f263af099cd22e1d@localhost> <9497e9990907051040u6c36bd0bjd9b0be44afe8123c@mail.gmail.com> Message-ID: On Sun, 5 Jul 2009 18:40:37 +0100, Mat Booth wrote: > On Sun, Jul 5, 2009 at 11:03 AM, Jeroen van Meeuwen > wrote: >> >> The CentOS project, or it's upstream, has a release cycle of >> approximately >> three years -not a steady release cycle of three years but that's what it >> turns out to be. This disqualifies the distribution(s) as desktop Linux >> distributions, as desktops tend to need to run the latest and greatest >> for >> as far the latest and greatest lets them. >> >> Does that make sense? >> > > No, it doesn't make a great deal of sense. You say a market for this > is the corporate desktop, but a government department I work with runs > their scientific desktops on RHEL 4. They have a lot of in-house apps > that are known to work on that platform. There is absolutely no sense > in expending resources on switching to a newer version until that > version's EOL is in sight. > You just made (part of) my point, I hope you realize: > There is absolutely no sense > in expending resources on switching to a newer version until that > version's EOL is in sight. Thanks! Also, note that one example of a corporate environment that runs Enterprise Linux grade distributions on their desktop systems does not make the rest less true. And before anyone else is going to say it; I bet there's dozens if not hundreds if not thousands if not millions of similar environments happy to run with the Enterprise Linux distributions out there. Kind regards, Jeroen van Meeuwen -kanarip From andreas.tunek at gmail.com Sun Jul 5 18:27:53 2009 From: andreas.tunek at gmail.com (Andreas Tunek) Date: Sun, 5 Jul 2009 20:27:53 +0200 Subject: Better ways to format USB disks (file fomats etc) In-Reply-To: <4A50EF6F.6040604@gmail.com> References: <4A50EF6F.6040604@gmail.com> Message-ID: Maybe I should clarify my use case experience. After I used GParted to format the HDD to ext3 (and ext4 later) I tried to create a folder on the HDD. I could not do this as a normal user, only as root. When I formatted the HDD to ntfs I could create folders and files. I want the ntfs behavior. From bochecha at fedoraproject.org Sun Jul 5 18:49:23 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Sun, 5 Jul 2009 20:49:23 +0200 Subject: Better ways to format USB disks (file fomats etc) In-Reply-To: References: <4A50EF6F.6040604@gmail.com> Message-ID: <2d319b780907051149g77db8c16nae3d779df15be021@mail.gmail.com> > Maybe I should clarify my use case experience. After I used GParted to > format the HDD to ext3 (and ext4 later) I tried to create a folder on > the HDD. I could not do this as a normal user, only as root. You can create files/folders with users if they ? own ? the HDD. But then, another user won't be able to do so. I tried to do what you want some time ago, but all I could find was to create several user owned directories on the HDD, then each user could write in his folder. If there's a way to have the ? FAT behavior ?, I'd like to know it as much as you :) ---------- Mathieu Bridon (bochecha) From mrsam at courier-mta.com Sun Jul 5 18:52:06 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sun, 05 Jul 2009 14:52:06 -0400 Subject: Better ways to format USB disks (file fomats etc) References: <4A50EF6F.6040604@gmail.com> Message-ID: Andreas Tunek writes: > Maybe I should clarify my use case experience. After I used GParted to > format the HDD to ext3 (and ext4 later) I tried to create a folder on > the HDD. I could not do this as a normal user, only as root. When I > formatted the HDD to ntfs I could create folders and files. I want the > ntfs behavior. Create a top-level folder on the USB drive that's owned by your userid, then you can create any subfolders that your heart desires. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From muepsj at gmail.com Sun Jul 5 19:31:57 2009 From: muepsj at gmail.com (=?UTF-8?Q?Joonas_Saraj=C3=A4rvi?=) Date: Sun, 5 Jul 2009 22:31:57 +0300 Subject: Better ways to format USB disks (file fomats etc) In-Reply-To: References: <4A50EF6F.6040604@gmail.com> Message-ID: <66ec675b0907051231h1fbbd6bu222004d38f9f24ce@mail.gmail.com> 2009/7/5, Sam Varshavchik : > Andreas Tunek writes: > >> Maybe I should clarify my use case experience. After I used GParted to >> format the HDD to ext3 (and ext4 later) I tried to create a folder on >> the HDD. I could not do this as a normal user, only as root. When I >> formatted the HDD to ntfs I could create folders and files. I want the >> ntfs behavior. > > Create a top-level folder on the USB drive that's owned by your userid, then > you can create any subfolders that your heart desires. > > This is totally broken if the disk is used on multiple computers. Having to maintain same UID-username combinations on the different computers is just not good usability. The way I'd like it to work is that all the files would appear to be owned by the user who mounted the disk, regardless of what was stored in the filesystem metadata. The rwx permission bits could well be applied as usual. -- Joonas Saraj?rvi muepsj at gmail.com From kwhiskerz at gmail.com Sun Jul 5 19:33:59 2009 From: kwhiskerz at gmail.com (Petrus de Calguarium) Date: Sun, 05 Jul 2009 13:33:59 -0600 Subject: Better ways to format USB disks (file fomats etc) References: <4A50EF6F.6040604@gmail.com> Message-ID: Sam Varshavchik wrote: > Create a top-level folder on the USB drive that's owned by your userid, > then you can create any subfolders that your heart desires. This works for me. I formatted the hard disk as ext4 and made a few directories, then changed ownership to me, and now I can modify the contents at will without becoming root. I used to change some of the Policy settings, but I no longer bother with that. From bochecha at fedoraproject.org Sun Jul 5 19:55:58 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Sun, 5 Jul 2009 21:55:58 +0200 Subject: Better ways to format USB disks (file fomats etc) In-Reply-To: <66ec675b0907051231h1fbbd6bu222004d38f9f24ce@mail.gmail.com> References: <4A50EF6F.6040604@gmail.com> <66ec675b0907051231h1fbbd6bu222004d38f9f24ce@mail.gmail.com> Message-ID: <2d319b780907051255o4507f05ck9c3153ba6faa98e2@mail.gmail.com> >> Create a top-level folder on the USB drive that's owned by your userid, then >> you can create any subfolders that your heart desires. >> >> > This is totally broken if the disk is used on multiple computers. > Having to maintain same UID-username combinations on the different > computers is just not good usability. At least, on all Fedora desktop, the first created user has the same UID (501) right ? And as most desktops are single user anyway, this is less trouble than it would seem. However, fun starts when you plug your HDD in a cyber-caf? or another multi-user desktop environment :) > The way I'd like it to work is that all the files would appear to be > owned by the user who mounted the disk, regardless of what was stored > in the filesystem metadata. The rwx permission bits could well be > applied as usual. That sure would be great. ---------- Mathieu Bridon (bochecha) From cemeyer at u.washington.edu Sun Jul 5 21:05:08 2009 From: cemeyer at u.washington.edu (Conrad Meyer) Date: Sun, 5 Jul 2009 14:05:08 -0700 Subject: an update to automake-1.11? In-Reply-To: References: <1246385157.8362.127.camel@localhost.localdomain> <200907051111.36123.cemeyer@u.washington.edu> Message-ID: <200907051405.08377.cemeyer@u.washington.edu> On Sunday 05 July 2009 11:24:43 am Sam Varshavchik wrote: > Conrad Meyer writes: > > On Sunday 05 July 2009 07:45:46 am Sam Varshavchik wrote: > >> *snip* > >> > >> With a subsequent release, you'll still > >> have to rebase your existing patch, if the new release did not fix the > >> original bug. As I understand, rpm's default settings now reject fuzz in > >> patch files, so you'll just have to do it, now. And since the likelyhood > >> of configure changing in a new release is no different than any other > >> source file getting changed, on average, believing that some work can be > >> saved just by choosing to patch a different file, then the one that > >> really needs to be patched, is somewhat naive. > > > > The problem is that configure scripts are not written by a human, but > > generated by autoconf. It is easy to make small changes to configure.ac > > and generate large changes in configure. This makes it easier to rebase > > patches against configure.ac. > > The macros in configure.ac generally expand out to canned shell script > fragments, with the macro's parameters substituted somewhere. Changing a > parameter in configure.ac usually results in an equivalent substitution in > configure. Right. Still, it makes more sense to patch the original source than the generated result, I think. > Generally, only when one adds or removes entire macros from configure.ac, > that's when this results in wholesale changes to configure. > > In my experience, the overwhelming majority of fixups to configure scripts > involve nothing more than adjusting someone's pathname, or compiler flags. > For this kind of scope, rebuilding the entire configure script is overkill, > and I wouldn't do it unless I audit it and verify whether or not upstream > is relying on some specific behavior in the specific version of autoconf > that was used to build the original configure script. Patching the > configure script is much safer than patching configure.ac, then have > autoconf grok all .m4 macros and rebuild the whole thing, likely ending up > with a completely different beast, that not only includes your changes but > who knows what else. Unrelated, but I think this sort of phobia of regenerating an auto-generated script just goes to show how completely broken autotools is. Regards, -- Conrad Meyer From snecklifter at gmail.com Sun Jul 5 21:13:07 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Sun, 5 Jul 2009 22:13:07 +0100 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <4A4FD09C.7000809@kanarip.com> References: <4A4FD09C.7000809@kanarip.com> Message-ID: <364d303b0907051413q4cc36c70r7173e5cdd2b66e1f@mail.gmail.com> 2009/7/4 Jeroen van Meeuwen : > I wanted to draw your attention to a feature I've proposed for Fedora 12, > mysteriously called Extended Life Cycle. > > You can find more details at > https://fedoraproject.org/wiki/Features/Extended_Life_Cycle Perhaps a way to do this would be to identify what the latest and greatest is that users want and make _that_ run on Centos. Here's my list: OO.org Firefox Thunderbird Evolution with MAPI connector GNOME-RDP Amarok I can only see MAPI being a problem requiring some Samba 4 stuff. Honestly, I'm impressed by your persistence but I think simply trying to re-instate Fedora Legacy (which it sounds like this is what you are trying to do) is doomed to permanent failure. Regards -- Christopher Brown From rjones at redhat.com Sun Jul 5 21:17:29 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Sun, 5 Jul 2009 22:17:29 +0100 Subject: an update to automake-1.11? In-Reply-To: <200907051637.08456.opensource@till.name> References: <1246385157.8362.127.camel@localhost.localdomain> <20090705131655.GA21540@amd.home.annexia.org> <200907051637.08456.opensource@till.name> Message-ID: <20090705211644.GA22871@amd.home.annexia.org> On Sun, Jul 05, 2009 at 04:37:02PM +0200, Till Maas wrote: > On Sun July 5 2009, Richard W.M. Jones wrote: > > > There's been lots of previous discussion of this silly idea of > > patching generated code. You end up carrying enormous patches > > containing just line number changes that often can't be applied > > upstream, and can't be carried forward to new upstream releases -- > > what on earth use is that? And still no one has explained coherently > > why the sky will fall if we patch configure.ac and Makefile.am and > > just rerun autoconf/automake in the specfile. > > There is also the third alternative to patch configure.ac and > Makefile.am, send the patches upstream, then run autoconf/automake > once to get a patch for the upstream tarball and use this patch > inside the spec. The patch in the spec may still be big, but it does > not hurt anyone afaics. But WHY!??!!! Why is it bad to patch configure.ac and rerun the autotools stuff? I do this all the time and it doesn't fail, even when we upgrade autotools mid-release. Please someone explain why this is bad. It's totally stupid to go to all this extra effort and carry huge patches against what are essentially binary files, unless there's a really _really_ good reason for it. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From rjones at redhat.com Sun Jul 5 21:30:45 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Sun, 5 Jul 2009 22:30:45 +0100 Subject: an update to automake-1.11? In-Reply-To: References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> Message-ID: <20090705213045.GB22871@amd.home.annexia.org> On Sun, Jul 05, 2009 at 10:45:46AM -0400, Sam Varshavchik wrote: > What line number changes? You cut a patch against configure, and you're > done. That's it. And you get a big patch containing line numbers. Here's a single line change to configure.ac, and the corresponding patch that generates: http://annexia.org/tmp/configure.patch Note: I'm not even changing the version of autoconf, because really what you mean is I have to track down the exact same version of all autotools that the upstream author used. If you don't do that, then you get a _real_ big patch. > I fail to see any substantive difference between that, and patching any > other file in the source tarball. With a subsequent release, you'll still > have to rebase your existing patch, if the new release did not fix the > original bug. No you don't - often patches continue to work over versions. Not in the case where you're patching a binary of course ... Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From rjones at redhat.com Sun Jul 5 21:33:07 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Sun, 5 Jul 2009 22:33:07 +0100 Subject: an update to automake-1.11? In-Reply-To: References: <1246385157.8362.127.camel@localhost.localdomain> <20090705131655.GA21540@amd.home.annexia.org> <200907051111.36123.cemeyer@u.washington.edu> Message-ID: <20090705213307.GC22871@amd.home.annexia.org> On Sun, Jul 05, 2009 at 02:24:43PM -0400, Sam Varshavchik wrote: > For this kind of scope, rebuilding the entire configure > script is overkill, and I wouldn't do it unless I audit it and verify > whether or not upstream is relying on some specific behavior in the > specific version of autoconf that was used to build the original > configure script. So to make this patch, I've got to track down the exact version of all the autotools that upstream happens to be using. Great. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.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 bjorn at xn--rombobjrn-67a.se Sun Jul 5 21:43:36 2009 From: bjorn at xn--rombobjrn-67a.se (=?utf-8?q?Bj=C3=B6rn_Persson?=) Date: Sun, 5 Jul 2009 23:43:36 +0200 Subject: Better ways to format USB disks (file fomats etc) In-Reply-To: References: Message-ID: <200907052343.49554.bjorn@xn--rombobjrn-67a.se> Andreas Tunek wrote: > I would > like to have the extremely high usability/minimal security of fat32 > (anyone who mounts the disk can read and write everything on the disk) > and it seems that this is not possible using ext3/ext4. Try this command: setfacl --modify other::rwX --modify default:other::rwX It will give everybody read and write permissions on the specified directory and all new files and directories created in it. 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 davej at redhat.com Sun Jul 5 22:46:36 2009 From: davej at redhat.com (Dave Jones) Date: Sun, 5 Jul 2009 18:46:36 -0400 Subject: rawhide report: 20090705 changes In-Reply-To: <20090705112158.GA32600@releng2.fedora.phx.redhat.com> References: <20090705112158.GA32600@releng2.fedora.phx.redhat.com> Message-ID: <20090705224635.GA4928@redhat.com> On Sun, Jul 05, 2009 at 11:21:58AM +0000, Rawhide Report wrote: > kernel-2.6.31-0.42.rc2.fc12 > --------------------------- > * Sat Jul 04 2009 Chuck Ebbert > - 2.6.31-rc1-git11 > > * Sat Jul 04 2009 Dave Jones 2.6.31-0.42.rc2 > - 2.6.31-rc2 > > * Fri Jul 03 2009 Hans de Goede > - Disable v4l1 ov511 and quickcam_messenger drivers (obsoleted by > v4l2 gspca subdrivers) Why is the changelog out of order in the rawhide report? It's the right way around in CVS. Dave From oget.fedora at gmail.com Sun Jul 5 22:47:08 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Sun, 5 Jul 2009 18:47:08 -0400 Subject: an update to automake-1.11? In-Reply-To: References: <1246385157.8362.127.camel@localhost.localdomain> <20090705131655.GA21540@amd.home.annexia.org> <200907051111.36123.cemeyer@u.washington.edu> Message-ID: On Sun, Jul 5, 2009 at 2:24 PM, Sam Varshavchik wrote: > [cut] > Patching the configure > script is much safer than patching configure.ac, then have autoconf grok all > .m4 macros and rebuild the whole thing, likely ending up with a completely > different beast, that not only includes your changes but who knows what > else. > What else? You and some other people are defending this from the beginning of this thread but no one explained what else might change. If I patch configure.ac and Makefile.am, then run autotools and build the RPM package that way, what else might go in unnoticed? Please back up your claims. I do not have much knowledge to make claims in either direction but I am willing to learn. Orcan From mrsam at courier-mta.com Sun Jul 5 22:50:04 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sun, 05 Jul 2009 18:50:04 -0400 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> Message-ID: Richard W.M. Jones writes: > On Sun, Jul 05, 2009 at 10:45:46AM -0400, Sam Varshavchik wrote: >> What line number changes? You cut a patch against configure, and you're >> done. That's it. > > And you get a big patch containing line numbers. Here's a single line > change to configure.ac, and the corresponding patch that generates: ====================== Who said anything about patching configure.ac? The cited link is not a patch to the configure script, it's a result of a patch to configure.ac. I'll repeat again: patch configure, not configure.ac. I said "patch configure", and you reply, "well, it won't work because if you patch configure.ac, run autoconf, then generate the patch between the original configure, and the new configure, I get a big hairball". Duh. I've been reading configure scripts long enough to know that your pseudo-patch is the result of adding AC_PATH_PROG(PERL, perl) to configure.ac. Now, why don't you explain why, and we'll go from there. Presuming that this is needed because some script in $srcdir uses the PERL environment variable, or a later part of the configure script itself (it assumes that PERL is set in the environment) then I would just patch in: PERL=/usr/bin/perl export PERL instead, to configure. Or, have the spec file set PERL itself, before running configure. If the reason for the patch is that there's some *.in in src with a @PERL@ placeholder, I'd just patch that *.in file directly, instead. No need to uselessly screw around with configure, when I don't even need to do it. Like I said earlier, there seems to be a meme going around that making a minor fix to configure is an impossible task. It can't be done, the only option is to fix configure.ac, and rerun autoconf. configure itself is untouchable. You can't patch it, you have to patch configure.ac, and then regenerate it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From kevin.kofler at chello.at Sun Jul 5 22:51:30 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 06 Jul 2009 00:51:30 +0200 Subject: rawhide report: 20090703 changes References: <20090703120444.GA22599@releng2.fedora.phx.redhat.com> <20090704091650.e40718fc.zaitcev@redhat.com> Message-ID: Pete Zaitcev wrote: > It sure was a fabulous debut as a maintainer for Andreas (according > to changelog he took over from Jakub). Hey, we all make mistakes, it's no use insulting people over it! Was that sarcastic remark really necessary? Kevin Kofler From mrsam at courier-mta.com Sun Jul 5 22:51:54 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sun, 05 Jul 2009 18:51:54 -0400 Subject: an update to automake-1.11? References: <1246385157.8362.127.camel@localhost.localdomain> <20090705131655.GA21540@amd.home.annexia.org> <200907051111.36123.cemeyer@u.washington.edu> <20090705213307.GC22871@amd.home.annexia.org> Message-ID: Richard W.M. Jones writes: > On Sun, Jul 05, 2009 at 02:24:43PM -0400, Sam Varshavchik wrote: >> For this kind of scope, rebuilding the entire configure >> script is overkill, and I wouldn't do it unless I audit it and verify >> whether or not upstream is relying on some specific behavior in the >> specific version of autoconf that was used to build the original >> configure script. > > So to make this patch, I've got to track down the exact version > of all the autotools that upstream happens to be using. Great. If you want to patch configure.ac, and then rerun autoconf to generate a brand new configure script, then, yes, that's what due diligence indicates. But that's what /you/ want to do, not me. Me, I'll just apply a patch to the configure script, directly. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From kevin.kofler at chello.at Sun Jul 5 23:36:10 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 06 Jul 2009 01:36:10 +0200 Subject: an update to automake-1.11? References: <1246385157.8362.127.camel@localhost.localdomain> <200907051111.36123.cemeyer@u.washington.edu> <200907051405.08377.cemeyer@u.washington.edu> Message-ID: Conrad Meyer wrote: > Unrelated, but I think this sort of phobia of regenerating an > auto-generated script just goes to show how completely broken autotools > is. +1, "auto-generated source code" is an oxymoron, this design is really broken. Kevin Kofler From kevin.kofler at chello.at Sun Jul 5 23:37:52 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 06 Jul 2009 01:37:52 +0200 Subject: an update to automake-1.11? References: <1246385157.8362.127.camel@localhost.localdomain> <20090705131655.GA21540@amd.home.annexia.org> <200907051111.36123.cemeyer@u.washington.edu> <20090705213307.GC22871@amd.home.annexia.org> Message-ID: Sam Varshavchik wrote: > But that's what /you/ want to do, not me. Me, I'll just apply a patch to > the configure script, directly. And you'll be violating the GPL (unless you're talking about a BSD-style-licensed software or configure.ac is explicitly marked with special permissions). The GPL requires you to edit the preferred form for modification, which is definitely NOT a generated file. Kevin Kofler From kevin.kofler at chello.at Sun Jul 5 23:41:48 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 06 Jul 2009 01:41:48 +0200 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> Message-ID: Sam Varshavchik wrote: > Now, why don't you explain why, and we'll go from there. Presuming that > this is needed because some script in $srcdir uses the PERL environment > variable, or a later part of the configure script itself (it assumes that > PERL is set in the environment) then I would just patch in: > > PERL=/usr/bin/perl > export PERL > > instead, to configure. This is a really dirty hack and cannot be upstreamed. Fixing configure.ac is the clean fix. > Like I said earlier, there seems to be a meme going around that making a > minor fix to configure is an impossible task. It can't be done, the only > option is to fix configure.ac, and rerun autoconf. configure itself is > untouchable. You can't patch it, you have to patch configure.ac, and then > regenerate it. That "meme" goes around for a reason, patching a generated file is dirty, can be hard to do depending on what you want to patch, leads to patches which can't be upstreamed and, if the source code is GPLed, violates the GPL. Kevin Kofler From kevin.kofler at chello.at Sun Jul 5 23:52:31 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 06 Jul 2009 01:52:31 +0200 Subject: an update to automake-1.11? References: <1246385157.8362.127.camel@localhost.localdomain> <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> Message-ID: Sam Varshavchik wrote: > As I understand, rpm's default settings now reject fuzz in patch files, so > you'll just have to do it, now. "%define _default_patch_fuzz 2" (or even 3) can do miracles. :-p > And since the likelyhood of configure changing in a new release is no > different than any other source file getting changed This is a wrong assertion to start from: configure tends to change a lot since configure.ac gets changed at least once per version (to bump the version) and upstream will regenerate configure with the then-current configure.ac on their then-current distro. Sometimes, it's not even the same person regenerating configure each time, so it can get regenerated on completely different distros. Plus, as even small patches to configure.ac can change a lot in configure (e.g. line numbers all over the place) and as upstream WILL regenerate configure, not patch it directly, fuzz is a lot more likely in configure than configure.ac. > on average, believing that some work can be saved just by choosing to > patch a different file, then the one that really needs to be patched, is > somewhat naive. It's believing it can't which is naive. All evidence points towards the fact that patching configure.ac is indeed less work for changes. > Because autoconf and automake are going to change a lot more than just > what the patch was intended to patch. It's fairly likely that the upstream > is using a different version of autoconf and automake, so this ends up > producing a brand new configure and makefile. If I were to do that, then > I would find it necessary to spend additional time testing the new > configure script, running it an eyeballing all of its voluminous output, > watching for something that falls out, as a result of the new configure > script. And you think upstream does that? On the autotools-using stuff I'm now upstream for (no, it wasn't my decision to use autotools, and yes, moving to CMake is a high-priority todo item), I just run "autoreconf -i -f" with the latest autotools updates of the version of Fedora I'm currently running and ignore all the warnings. Kevin Kofler From kevin.kofler at chello.at Sun Jul 5 23:57:05 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 06 Jul 2009 01:57:05 +0200 Subject: readline update? References: <20090703102747.GA32668@localhost> <4A4E5C2A.7020702@freenet.de> Message-ID: Matej Cepl wrote: > Ralf Corsepius, Fri, 03 Jul 2009 21:29:46 +0200: >> I thought, we banned all non-utf-8 aware packages? > > I agree, who needs grep after all :) > https://bugzilla.redhat.com/show_bug.cgi?id=194471 > That package WORKS with UTF-8, it's just very slow with it on some extreme testcases. Kevin Kofler From kevin.kofler at chello.at Sun Jul 5 23:58:45 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 06 Jul 2009 01:58:45 +0200 Subject: readline update? References: <20090703102747.GA32668@localhost> <4A4E5C2A.7020702@freenet.de> Message-ID: Matej Cepl wrote: > Ralf Corsepius, Fri, 03 Jul 2009 21:29:46 +0200: >> I thought, we banned all non-utf-8 aware packages? > > And BTW zsh has been fixed not to corrupt non-ASCII filenames? Bash FTW! :-p Kevin Kofler From cjb at laptop.org Sun Jul 5 23:58:03 2009 From: cjb at laptop.org (Chris Ball) Date: Sun, 05 Jul 2009 19:58:03 -0400 Subject: an update to automake-1.11? In-Reply-To: (Kevin Kofler's message of "Mon, 06 Jul 2009 01:37:52 +0200") References: <1246385157.8362.127.camel@localhost.localdomain> <20090705131655.GA21540@amd.home.annexia.org> <200907051111.36123.cemeyer@u.washington.edu> <20090705213307.GC22871@amd.home.annexia.org> Message-ID: Hi, > And you'll be violating the GPL (unless you're talking about a > BSD-style-licensed software or configure.ac is explicitly marked > with special permissions). The GPL requires you to edit the > preferred form for modification, which is definitely NOT a > generated file. [citation needed] I think this clause talks about *my* preferred form for modification, not yours -- it's saying that I have to distribute my changes in the form I created them in. If you write a program in Perl, and I port it to Python and release it, I haven't "violated the preferred form for modification" by not using Perl. - Chris. -- Chris Ball From kevin.kofler at chello.at Mon Jul 6 00:03:01 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 06 Jul 2009 02:03:01 +0200 Subject: Feature proposal: Extended Life Cycle Support References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> Message-ID: Jeroen van Meeuwen wrote: > Whether 6 months of additional availability of security updates is going > to help, and to what extend, we'll have to see. Compared to the current > situation, that'll give an environment 7 months to upgrade beyond the > moment that we now call End-Of-Life for a given release and 3 releases to > choose from -certainly a lot more time then 1 month and 2 releases to > choose from. They already have 7 months of time to move to the next version. It's just if they absolutely want to skip a version that they only have 1 month. Kevin Kofler From mjs at clemson.edu Mon Jul 6 00:11:46 2009 From: mjs at clemson.edu (Matthew Saltzman) Date: Sun, 05 Jul 2009 20:11:46 -0400 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <364d303b0907051413q4cc36c70r7173e5cdd2b66e1f@mail.gmail.com> References: <4A4FD09C.7000809@kanarip.com> <364d303b0907051413q4cc36c70r7173e5cdd2b66e1f@mail.gmail.com> Message-ID: <1246839106.4556.138.camel@valkyrie.localdomain> On Sun, 2009-07-05 at 22:13 +0100, Christopher Brown wrote: > 2009/7/4 Jeroen van Meeuwen : > > I wanted to draw your attention to a feature I've proposed for Fedora 12, > > mysteriously called Extended Life Cycle. > > > > You can find more details at > > https://fedoraproject.org/wiki/Features/Extended_Life_Cycle > > Perhaps a way to do this would be to identify what the latest and > greatest is that users want and make _that_ run on Centos. Here's my > list: > > OO.org > Firefox > Thunderbird > Evolution with MAPI connector > GNOME-RDP > Amarok There is a fast track channel for RHEL5 that is supposed to provide early updates of at least some apps. > > I can only see MAPI being a problem requiring some Samba 4 stuff. Much worse than that. The MAPI evo is 2.26, but RHEL5's is 2.16. You'd have to upgrade the entire GNOME infrastructure to support the MAPI stuff. From the discussions I've read, back-porting MAPI support is not practical. > > Honestly, I'm impressed by your persistence but I think simply trying > to re-instate Fedora Legacy (which it sounds like this is what you are > trying to do) is doomed to permanent failure. > > Regards > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From jwboyer at gmail.com Mon Jul 6 00:36:44 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Sun, 5 Jul 2009 20:36:44 -0400 Subject: rawhide report: 20090705 changes In-Reply-To: <20090705224635.GA4928@redhat.com> References: <20090705112158.GA32600@releng2.fedora.phx.redhat.com> <20090705224635.GA4928@redhat.com> Message-ID: <20090706003644.GA19829@hansolo.jdub.homelinux.org> On Sun, Jul 05, 2009 at 06:46:36PM -0400, Dave Jones wrote: >On Sun, Jul 05, 2009 at 11:21:58AM +0000, Rawhide Report wrote: > > > kernel-2.6.31-0.42.rc2.fc12 > > --------------------------- > > * Sat Jul 04 2009 Chuck Ebbert > > - 2.6.31-rc1-git11 > > > > * Sat Jul 04 2009 Dave Jones 2.6.31-0.42.rc2 > > - 2.6.31-rc2 > > > > * Fri Jul 03 2009 Hans de Goede > > - Disable v4l1 ov511 and quickcam_messenger drivers (obsoleted by > > v4l2 gspca subdrivers) > >Why is the changelog out of order in the rawhide report? >It's the right way around in CVS. Because the script that generates it doesn't deal with multiple entries on the same day properly. It's becoming a common question. josh From mrsam at courier-mta.com Mon Jul 6 02:00:54 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sun, 05 Jul 2009 22:00:54 -0400 Subject: an update to automake-1.11? References: <1246385157.8362.127.camel@localhost.localdomain> <20090705131655.GA21540@amd.home.annexia.org> <200907051111.36123.cemeyer@u.washington.edu> Message-ID: Orcan Ogetbil writes: > On Sun, Jul 5, 2009 at 2:24 PM, Sam Varshavchik wrote: >> [cut] >> Patching the configure >> script is much safer than patching configure.ac, then have autoconf grok all >> .m4 macros and rebuild the whole thing, likely ending up with a completely >> different beast, that not only includes your changes but who knows what >> else. >> > > What else? You and some other people are defending this from the > beginning of this thread but no one explained what else might change. > If I patch configure.ac and Makefile.am, then run autotools and build > the RPM package that way, what else might go in unnoticed? Why are you asking me? I'm the one arguing against patching configure.ac and Makefile.am and rerunning autotools. > Please back up your claims. I do not have much knowledge to make > claims in either direction but I am willing to learn. You can start by reading this thread, again. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mrsam at courier-mta.com Mon Jul 6 02:08:25 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sun, 05 Jul 2009 22:08:25 -0400 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> Message-ID: Kevin Kofler writes: > Sam Varshavchik wrote: >> Now, why don't you explain why, and we'll go from there. Presuming that >> this is needed because some script in $srcdir uses the PERL environment >> variable, or a later part of the configure script itself (it assumes that >> PERL is set in the environment) then I would just patch in: >> >> PERL=/usr/bin/perl >> export PERL >> >> instead, to configure. > > This is a really dirty hack and cannot be upstreamed. I see. A surgical patch that addresses the build failure directly is dirty. It's much cleaner to patch a different file that's one step removed, then run a tool to regenerate the script where the original problem was, and hope that there are not going to be any side effects. And I don't recall ever claiming that this should be sent directly upstream. Upstrem can be informed in parallel, so that the proper fix can be put in place. > Fixing configure.ac is > the clean fix. Fixing configure.ac accomplishes absolutely nothing. One has to run autotools to propagate the fix, and that's the messy part. Like I said, due diligence would require you to track which specific version of autotools the upstream used to generate the original scripts, and whether or not there's any code in configure.ac that's specific to that version of autotools, so that any side effects can be properly vetted, when the entire build system gets regenerated by autotools. > That "meme" goes around for a reason, patching a generated file is dirty, >From the viewpoint of a package builder it is not a generated file. It comes right out of the tarball, as is. > can be hard to do depending on what you want to patch, leads to patches > which can't be upstreamed and, if the source code is GPLed, violates the > GPL. How exactly would that violate the GPL? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mrsam at courier-mta.com Mon Jul 6 02:09:12 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sun, 05 Jul 2009 22:09:12 -0400 Subject: an update to automake-1.11? References: <1246385157.8362.127.camel@localhost.localdomain> <20090705131655.GA21540@amd.home.annexia.org> <200907051111.36123.cemeyer@u.washington.edu> <20090705213307.GC22871@amd.home.annexia.org> Message-ID: Kevin Kofler writes: > Sam Varshavchik wrote: >> But that's what /you/ want to do, not me. Me, I'll just apply a patch to >> the configure script, directly. > > And you'll be violating the GPL (unless you're talking about a > BSD-style-licensed software or configure.ac is explicitly marked with > special permissions). The GPL requires you to edit the preferred form for > modification, which is definitely NOT a generated file. You do not understand the GPL. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From nathanael at gnat.ca Mon Jul 6 02:15:53 2009 From: nathanael at gnat.ca (Nathanael Noblet) Date: Sun, 5 Jul 2009 20:15:53 -0600 Subject: Possible packages... Message-ID: Hello, So I've been toying with the idea of getting more involved with fedora. Up till now if there has been a bug or other issue, i'll file a bug or simply get the srpm and try to update it to a newer version, or create my own specs / rpms when they don't already exist. Lately I've figured that I should get more involved with some of the packages that I use or anything like that. The packaging guidelines kinda describe entry to the packager group as being done via new packages. I've offered to try to help on some recently orphaned packages. Though that may be more work than just submitting a new package. So after all that rambling, I'm wondering about the two following pieces of software. Apple's Calendar Server. It runs using python 2.5 or greater (I've installed it on a F11 machine and it work well). I've started looking at some of its dependancies. 90% of them are in fedora already, and of the ones in F11, only one if I remember correctly isn't at the version it requires). It seems like a great addition to Fedora if you ask me. So basically it would require two new packages, and an update to one other package (libevent) which is a minor version bump it seems if at all needed. PS3MediaServer. A Java program to talk to a PS3 with DLNA. I'm guessing this one would have problems because it requires ffmpeg or mplayer/mencoder... Plus as a java program its probably a bit more complex to create a proper spec file for. I've made the other kind often enough, but java ones not so much... Any feedback on either? From oget.fedora at gmail.com Mon Jul 6 02:28:16 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Sun, 5 Jul 2009 22:28:16 -0400 Subject: an update to automake-1.11? In-Reply-To: References: <1246385157.8362.127.camel@localhost.localdomain> <20090705131655.GA21540@amd.home.annexia.org> <200907051111.36123.cemeyer@u.washington.edu> Message-ID: On Sun, Jul 5, 2009 at 10:00 PM, Sam Varshavchik wrote: > Orcan Ogetbil writes: > >> On Sun, Jul 5, 2009 at 2:24 PM, Sam Varshavchik wrote: >>> >>> [cut] >>> Patching the configure >>> script is much safer than patching configure.ac, then have autoconf grok >>> all >>> .m4 macros and rebuild the whole thing, likely ending up with a >>> completely >>> different beast, that not only includes your changes but who knows what >>> else. >>> >> >> What else? You and some other people are defending this from the >> beginning of this thread but no one explained what else might change. >> If I patch configure.ac and Makefile.am, then run autotools and build >> the RPM package that way, what else might go in unnoticed? > > Why are you asking me? I'm the one arguing against patching configure.ac and > Makefile.am and rerunning autotools. > >> Please back up your claims. I do not have much knowledge to make >> claims in either direction but I am willing to learn. > > You can start by reading this thread, again. > > No, I believe that you are the one who needs to read again. :) Read my post. I know that you are against patching configure.ac and I ask you what might go wrong unnoticed if you do patch configure.ac. Example cases? please! Orcan From sandeen at redhat.com Mon Jul 6 03:33:36 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Sun, 05 Jul 2009 22:33:36 -0500 Subject: Possible packages... In-Reply-To: References: Message-ID: <4A517090.3090609@redhat.com> Nathanael Noblet wrote: > Hello, > > So I've been toying with the idea of getting more involved with > fedora. Up till now if there has been a bug or other issue, i'll file > a bug or simply get the srpm and try to update it to a newer version, > or create my own specs / rpms when they don't already exist. Lately > I've figured that I should get more involved with some of the packages > that I use or anything like that. The packaging guidelines kinda > describe entry to the packager group as being done via new packages. > I've offered to try to help on some recently orphaned packages. Though > that may be more work than just submitting a new package. > > So after all that rambling, I'm wondering about the two following > pieces of software. > > Apple's Calendar Server. It runs using python 2.5 or greater (I've > installed it on a F11 machine and it work well). I've started looking > at some of its dependancies. 90% of them are in fedora already, and of > the ones in F11, only one if I remember correctly isn't at the version > it requires). It seems like a great addition to Fedora if you ask me. > So basically it would require two new packages, and an update to one > other package (libevent) which is a minor version bump it seems if at > all needed. I'd love to see a calendar server in Fedora, though TBH when I looked at Apple's long ago it was a bit daunting; it seemed like one of those cross-platform hacks that is very much -not- nicely integrated with the OS (I don't remember the details; weird file hierarchies or private copies of libraries or ...?). Maybe it's better now. But if not, that may be a hiccup. But I'd say give it a shot. I'd help test it. :) FWIW I looked at DAViCal (http://rscds.sourceforge.net/) too and it seemed like an interesting possibility as well. -Eric From ob.system at gmail.com Mon Jul 6 04:38:31 2009 From: ob.system at gmail.com (Oscar Bacho) Date: Sun, 5 Jul 2009 23:38:31 -0500 Subject: rawhide report: 20090703 changes In-Reply-To: References: <20090703120444.GA22599@releng2.fedora.phx.redhat.com> <20090704091650.e40718fc.zaitcev@redhat.com> Message-ID: <6a28481b0907052138v4f7e8cd6j10a238a54b03f318@mail.gmail.com> 2009/7/5 Kevin Kofler > Pete Zaitcev wrote: > > It sure was a fabulous debut as a maintainer for Andreas (according > > to changelog he took over from Jakub). > > Hey, we all make mistakes, it's no use insulting people over it! Was that > sarcastic remark really necessary? > Sorry mom -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathanael at gnat.ca Mon Jul 6 06:25:56 2009 From: nathanael at gnat.ca (Nathanael Noblet) Date: Mon, 6 Jul 2009 00:25:56 -0600 Subject: Possible packages... In-Reply-To: <4A517090.3090609@redhat.com> References: <4A517090.3090609@redhat.com> Message-ID: <05069AE3-863E-4A0D-9E75-B42988B4B2EC@gnat.ca> On Jul 5, 2009, at 9:33 PM, Eric Sandeen wrote: > Nathanael Noblet wrote: >> >> Apple's Calendar Server. It runs using python 2.5 or greater (I've >> installed it on a F11 machine and it work well). I've started looking >> at some of its dependancies. 90% of them are in fedora already, and >> of >> the ones in F11, only one if I remember correctly isn't at the >> version >> it requires). It seems like a great addition to Fedora if you ask me. >> So basically it would require two new packages, and an update to one >> other package (libevent) which is a minor version bump it seems if at >> all needed. > > I'd love to see a calendar server in Fedora, though TBH when I > looked at > Apple's long ago it was a bit daunting; it seemed like one of those > cross-platform hacks that is very much -not- nicely integrated with > the > OS (I don't remember the details; weird file hierarchies or private > copies of libraries or ...?). Maybe it's better now. But if not, > that > may be a hiccup. But I'd say give it a shot. I'd help test it. :) Well their python run script checks for its dependancies, and if not met will do a svn checkout of the right copy, however, they don't keep copies of the libraries within their own repository. So if you fulfill all its dependancies that shouldn't be an issue. As for data storage and all that I assume the methods they choose to store data aren't part of the review? Plus that is configurable between a few different choices. > FWIW I looked at DAViCal (http://rscds.sourceforge.net/) too and it > seemed like an interesting possibility as well. Looks interesting, however the last release was well over a year ago it seems. Whereas Apple's CalendarServer is likely to receive more constant development. I guess there is a chance the Apple starts adding some features only available in their commercial version I guess... but I'm not sure if that is relevant either... So would a good start be attempting to package calendar server for F11 along with verifying its dependancies and then getting someone to review it? I'm a little curious about the one library that F11 packages (libevent at 1.4.x, where calendar server seems to download a 1.5.x...) Do I repackage libevent as part of my packages to be reviewed? Or simply talk to the maintainer of libevent to see if it can be bumped? On my system the only package that required libevent was something related to nfs... though I guess there could be others but I haven't checked... From drago01 at gmail.com Mon Jul 6 07:27:33 2009 From: drago01 at gmail.com (drago01) Date: Mon, 6 Jul 2009 09:27:33 +0200 Subject: rawhide report: 20090705 changes In-Reply-To: <20090706003644.GA19829@hansolo.jdub.homelinux.org> References: <20090705112158.GA32600@releng2.fedora.phx.redhat.com> <20090705224635.GA4928@redhat.com> <20090706003644.GA19829@hansolo.jdub.homelinux.org> Message-ID: On Mon, Jul 6, 2009 at 2:36 AM, Josh Boyer wrote: > On Sun, Jul 05, 2009 at 06:46:36PM -0400, Dave Jones wrote: >>On Sun, Jul 05, 2009 at 11:21:58AM +0000, Rawhide Report wrote: >> >> > kernel-2.6.31-0.42.rc2.fc12 >> > --------------------------- >> > * Sat Jul 04 2009 Chuck Ebbert >> > - 2.6.31-rc1-git11 >> > >> > * Sat Jul 04 2009 Dave Jones 2.6.31-0.42.rc2 >> > - 2.6.31-rc2 >> > >> > * Fri Jul 03 2009 Hans de Goede >> > - Disable v4l1 ov511 and quickcam_messenger drivers (obsoleted by >> > ? v4l2 gspca subdrivers) >> >>Why is the changelog out of order in the rawhide report? >>It's the right way around in CVS. > > Because the script that generates it doesn't deal with multiple > entries on the same day properly. ?It's becoming a common > question. Why does it mess with them at all? Why not just copy them from the specfile and assume that this is correct? From pertusus at free.fr Mon Jul 6 08:01:09 2009 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 6 Jul 2009 10:01:09 +0200 Subject: readline update? In-Reply-To: References: <20090703102747.GA32668@localhost> <4A4E5C2A.7020702@freenet.de> <20090704084157.GA4021@free.fr> Message-ID: <20090706080058.GA11847@free.fr> On Sat, Jul 04, 2009 at 04:10:15PM +0200, Kevin Kofler wrote: > > Those applications are obsolete by definition. Such a sentence doesn't make sense. As long as there are users and maintainers for those applications they are not obsolete. I personnally use xfig, xpdf, gv, grace, and I am far from being alone in that case. -- Pat From markmc at redhat.com Mon Jul 6 08:06:55 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 06 Jul 2009 09:06:55 +0100 Subject: an update to automake-1.11? In-Reply-To: <20090705211644.GA22871@amd.home.annexia.org> References: <1246385157.8362.127.camel@localhost.localdomain> <20090705131655.GA21540@amd.home.annexia.org> <200907051637.08456.opensource@till.name> <20090705211644.GA22871@amd.home.annexia.org> Message-ID: <1246867615.5451.41.camel@blaa> On Sun, 2009-07-05 at 22:17 +0100, Richard W.M. Jones wrote: > Why is it bad to patch configure.ac and rerun the autotools stuff? I used to avoid re-running autotools in rpm builds because I worried that a future autotools update would subtly screw up the build - e.g. disabling a previously enabled feature in the built package. These were in the days that upstream maintainers distributing tarballs had to be very careful what versions of autotools they used - e.g. I recall something like GNOME folks using Fedora's version of autoconf 2.52 because upstream 2.52 had broken utf-8 support[1]. Perhaps those days are gone now and autotools are much more reliable. If upstream people who run "make dist" don't pay much attention to what autotools versions they are using, then why should Fedora packagers care either? Cheers, Mark. [1] - I could be totally wrong on the details, but I do remember Owen (who started this thread) pointing out the problem to GNOME maintainers From dwmw2 at infradead.org Mon Jul 6 09:27:43 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 06 Jul 2009 10:27:43 +0100 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> <66ff0543780f93d7f263af099cd22e1d@localhost> <1246790384.6295.13.camel@macbook.infradead.org> Message-ID: <1246872463.10674.107.camel@macbook.infradead.org> On Sun, 2009-07-05 at 17:52 +0200, Jeroen van Meeuwen wrote: > > > As described on the Feature page, but if there's any specific > questions > about the reasoning on there I'll be happy to answer those questions. I had read the feature page, in which you claim that a three-year cycle "disqualifies the distribution(s) as desktop Linux distributions". I didn't see any justification for that assertion, especially given that you're simultaneously claiming that a 13-month lifetime isn't long _enough_ for you. You've conveniently dodged the question of what lifetime you _do_ want to provide, by saying 'yet to be determined'. But you must have _some_ idea, if you're so sure that 13 months is too short and 36 months is too long. So if three years is too long and one year is too short, what _do_ you want? 2 years? 18 months? 18 months would be a single extra Fedora release, and that _might_ be something we could make some progress on. How much work would it take, to make it possible for us to still ship updates for a release which has officially reached EOL? Does the sky fall on our heads if we don't push the 'Kill F-9' button in koji and bodhi precisely 1 month after the F-11 release? As a first step, perhaps we try that -- still officially state that the release is EOL and should not be used, but _allow_ interested people like Jeroen (and the original package owners, _if_ they are so inclined) to continue to build and push updates, instead of forcibly cutting off builds and updates as we do at the moment. That _isn't_ something we would publish as a 'feature' though -- it would strictly _unofficial_, although you'd be permitted to use the Fedora infrastructure for it. If it turns out that there _is_ enough interest and the interested people are _actually_ keeping on top of security fixes etc., then maybe we could consider officially admitting that it happens, and _then_ publishing it as a 'feature'. And/or extending it to more than one extra release. But those are all questions for the future. If it doesn't take too much infrastructure work, I see no reason why we shouldn't let them _try_. It doesn't hurt Fedora at all, does it? -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation From jwboyer at gmail.com Mon Jul 6 10:54:38 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 6 Jul 2009 06:54:38 -0400 Subject: rawhide report: 20090705 changes In-Reply-To: References: <20090705112158.GA32600@releng2.fedora.phx.redhat.com> <20090705224635.GA4928@redhat.com> <20090706003644.GA19829@hansolo.jdub.homelinux.org> Message-ID: <20090706105438.GB19829@hansolo.jdub.homelinux.org> On Mon, Jul 06, 2009 at 09:27:33AM +0200, drago01 wrote: >On Mon, Jul 6, 2009 at 2:36 AM, Josh Boyer wrote: >> On Sun, Jul 05, 2009 at 06:46:36PM -0400, Dave Jones wrote: >>>On Sun, Jul 05, 2009 at 11:21:58AM +0000, Rawhide Report wrote: >>> >>> > kernel-2.6.31-0.42.rc2.fc12 >>> > --------------------------- >>> > * Sat Jul 04 2009 Chuck Ebbert >>> > - 2.6.31-rc1-git11 >>> > >>> > * Sat Jul 04 2009 Dave Jones 2.6.31-0.42.rc2 >>> > - 2.6.31-rc2 >>> > >>> > * Fri Jul 03 2009 Hans de Goede >>> > - Disable v4l1 ov511 and quickcam_messenger drivers (obsoleted by >>> > ? v4l2 gspca subdrivers) >>> >>>Why is the changelog out of order in the rawhide report? >>>It's the right way around in CVS. >> >> Because the script that generates it doesn't deal with multiple >> entries on the same day properly. ?It's becoming a common >> question. > >Why does it mess with them at all? It has to do at least _some_ munging, otherwise you don't get the actual "this changed since the last rawhide report" part. >Why not just copy them from the specfile and assume that this is correct? I don't think it operates from CVS, so to get the specfile it would have to unpack the SRPMs. Not very efficient. I believe it just uses the changelog query on the RPM itself. josh From jwboyer at gmail.com Mon Jul 6 11:11:30 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 6 Jul 2009 07:11:30 -0400 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <1246872463.10674.107.camel@macbook.infradead.org> References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> <66ff0543780f93d7f263af099cd22e1d@localhost> <1246790384.6295.13.camel@macbook.infradead.org> <1246872463.10674.107.camel@macbook.infradead.org> Message-ID: <20090706111130.GC19829@hansolo.jdub.homelinux.org> On Mon, Jul 06, 2009 at 10:27:43AM +0100, David Woodhouse wrote: >On Sun, 2009-07-05 at 17:52 +0200, Jeroen van Meeuwen wrote: >> >> >> As described on the Feature page, but if there's any specific >> questions >> about the reasoning on there I'll be happy to answer those questions. > >I had read the feature page, in which you claim that a three-year cycle >"disqualifies the distribution(s) as desktop Linux distributions". > >I didn't see any justification for that assertion, especially given that >you're simultaneously claiming that a 13-month lifetime isn't long >_enough_ for you. > >You've conveniently dodged the question of what lifetime you _do_ want >to provide, by saying 'yet to be determined'. But you must have _some_ >idea, if you're so sure that 13 months is too short and 36 months is too >long. > >So if three years is too long and one year is too short, what _do_ you >want? 2 years? 18 months? > >18 months would be a single extra Fedora release, and that _might_ be >something we could make some progress on. > >How much work would it take, to make it possible for us to still ship >updates for a release which has officially reached EOL? Does the sky >fall on our heads if we don't push the 'Kill F-9' button in koji and >bodhi precisely 1 month after the F-11 release? No, the sky does not fall. There are a few hurdles though. 1) Master mirror space. This used to be an issue, in that we had to move older releases to alt.fp.o in order to make space for the new release. I believe we still do that, so either the yum.repo.d config files for the EOL release would need to be changed, or we'd have to grow a lot more mirror space. 2) Update push times. It takes 3+ hours to mash f9-updates right now. Keeping that time duration in the official updates pushing for an EOL release would be really annoying. Particularly since we are already going to hit some major time hurdles as F10 and F11 age and definitely when we add F12. >As a first step, perhaps we try that -- still officially state that the >release is EOL and should not be used, but _allow_ interested people >like Jeroen (and the original package owners, _if_ they are so inclined) >to continue to build and push updates, instead of forcibly cutting off >builds and updates as we do at the moment. > >That _isn't_ something we would publish as a 'feature' though -- it >would strictly _unofficial_, although you'd be permitted to use the >Fedora infrastructure for it. It doesn't work that way in practice. If it is allowed, it is official. You have to coordinate downtimes, End-of-Life-After-Death times, etc. The minute it's disabled early for one reason or another (space, time constraints, etc) people will cry foul even if it was "unofficial". >If it turns out that there _is_ enough interest and the interested >people are _actually_ keeping on top of security fixes etc., then maybe >we could consider officially admitting that it happens, and _then_ >publishing it as a 'feature'. And/or extending it to more than one extra >release. But those are all questions for the future. I would encourage people to run this as a secondary architecture. CVS still remains open for commits. You could just have a secondary koji hub for the builds. >If it doesn't take too much infrastructure work, I see no reason why we >shouldn't let them _try_. It doesn't hurt Fedora at all, does it? There is minimal pain, yes. Mostly to infrastructure and rel-eng. What I don't immediately see is the benefit to Fedora overall. josh From kevin.kofler at chello.at Mon Jul 6 12:22:19 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 06 Jul 2009 14:22:19 +0200 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> Message-ID: Sam Varshavchik wrote: > How exactly would that violate the GPL? You aren't patching the actual source code. Kevin Kofler From rawhide at fedoraproject.org Mon Jul 6 13:16:12 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Mon, 6 Jul 2009 13:16:12 +0000 Subject: rawhide report: 20090706 changes Message-ID: <20090706131612.GA22283@releng2.fedora.phx.redhat.com> Compose started at Mon Jul 6 06:15:04 UTC 2009 New package mcu8051ide IDE for MCS-51 based microcontrollers Updated Packages: abiword-2.7.6-3.fc12 -------------------- cln-1.3.0-1.fc12 ---------------- * Thu Jul 02 2009 Deji Akingunola - 1.3.0-1 - Update to latest upstream release 1.3.0 curl-7.19.5-6.fc12 ------------------ * Sun Jul 05 2009 Kamil Dudka 7.19.5-6 - force test suite to use the just built libcurl, thanks to Paul Howarth dbmail-2.2.11-7.fc12 -------------------- * Mon Jul 06 2009 Bernard Johnson - 2.2.11-7 - fix left out ? in comparison * Sun Jul 05 2009 Bernard Johnson - 2.2.11-5 - patch to remove duplicate email boxes from being listed - consider cron file a config file - add -b option to cron job to rebuild body/header/envelope cache tables - change order of redirection in cron job - fix typo in dbmail-pop3d that causes LSB info to not be recognized - add provides for dbmail-sqlite - conditional to compile with gmime22 when needed * Sun Jul 05 2009 Bernard Johnson - 2.2.11-6 - fix conditional comparison to be 0 for no value eric-4.3.5-1.fc12 ----------------- * Sun Jul 05 2009 Johan Cwiklinski 4.3.5-1 - 4.3.5 * Sun May 31 2009 Johan Cwiklinski 4.3.4-1 - 4.3.4 freedink-data-1.08.20090705-1.fc12 ---------------------------------- * Sun Jul 05 2009 Sylvain Beucler - 1.08.20090705-1 - New upstream release - Removed patch to preserve timestamps (applied upstream) glib2-2.21.3-1.fc12 ------------------- * Mon Jul 06 2009 Matthias Clasen - 2.21.3-1 - Update to 2.21.3 gnu-smalltalk-3.1-6.fc12 ------------------------ * Sun Jul 05 2009 Jochen Schmitt 3.1-6 - Fix license tag jd-2.4.1-0.3.rc090705.fc12 -------------------------- libiptcdata-1.0.4-1.fc12 ------------------------ * Sun Jul 05 2009 David Moore 1.0.4-1 - New upstream version libqalculate-0.9.6-6.fc12 ------------------------- * Sun Jul 05 2009 Deji Akingunola - 0.9.6-6 - Rebuild for cln-1.3.0 libzdb-2.6-1.fc12 ----------------- * Sun Jul 05 2009 Bernard Johnson - 2.6-1 - v 2.6 lxappearance-0.2.1-1.fc12 ------------------------- * Mon Jul 06 2009 Christoph Wickert - 0.2.1-1 - Update to 0.2.1 lxmenu-data-0.1.1-1.fc12 ------------------------ * Mon Jul 06 2009 Christoph Wickert 0.1.1-1 - Update to 0.1.1 lxshortcut-0.1.1-1.fc12 ----------------------- * Mon Jul 06 2009 Christoph Wickert - 0.1.1-1 - Update to 0.1.1 manaworld-0.0.29.1-1.fc12 ------------------------- * Sun Jul 05 2009 Wart 0.0.29.1-1 - Update to 0.0.29.1 mediatomb-0.11.0-9.fc12 ----------------------- merkaartor-0.14-0.1.pre2.fc12 ----------------------------- * Sun Jul 05 2009 Sven Lankes - 0.14-0.1-pre2 - 0.14-pre2 * Thu Jul 02 2009 Sven Lankes - 0.14-0.1-pre1 - 0.14-pre1 mingw32-nsiswrapper-4-2.fc12 ---------------------------- * Sun Jul 05 2009 Richard W.M. Jones - 4-2 - Add runtime requires mingw32-binutils (RHBZ#509747). prelink-0.4.1-1.fc12 -------------------- * Sun Jul 05 2009 Jakub Jelinek 0.4.1-1 - add support for STT_GNU_IFUNC on i?86/x86_64 and R_{386,X86_64}_IRELATIVE - add support for DWARF3/DWARF4 features generated newly by recent gccs - temporarily link prelink against -lpthread to workaround -lselinux issue psi-0.13-0.2.rc2.fc12 --------------------- * Sun Jul 05 2009 Sven Lankes 0.13-0.2.rc2 - own plugin directories (bz #509683) python-zope-interface-3.5.2-1.fc12 ---------------------------------- * Sun Jul 05 2009 Felix Schwarz 3.5.2-1 - update to 3.5.2 qalculate-gtk-0.9.6-6.fc12 -------------------------- * Sun Jul 05 2009 Deji Akingunola - 0.9.6-6 - Rebuild for cln-1.3.0 qalculate-kde-0.9.6-8.fc12 -------------------------- * Sun Jul 05 2009 Deji Akingunola - 0.9.6-8 - Rebuild for cln-1.3.0 scidavis-0.2.3-1.fc12 --------------------- * Sun Jul 05 2009 Eric Tanguy - 0.2.3-1 - Update to 0.2.3 sugar-write-63-1.fc12 --------------------- wesnoth-1.6.4-1.fc12 -------------------- * Sun Jul 05 2009 Warren Togami - 1.6.4-1 - 1.6.4 maintenance release xorg-x11-drv-nouveau-0.0.14-1.20090701git6d14327.fc12 ----------------------------------------------------- * Tue Jul 07 2009 Ben Skeggs 0.0.14-1.20090701git6d14327 - update from upstream + bring back additional features found in F11 xorg-x11-server-1.6.99-9.20090706.fc12 -------------------------------------- * Mon Jul 06 2009 Peter Hutterer 1.6.99-9.20090706 - Today's git snapshot. - xserver-1.5.0-bad-fbdev-thats-mine.patch: Drop. Merged upstream. Summary: Added Packages: 1 Removed Packages: 0 Modified Packages: 29 From ajax at redhat.com Mon Jul 6 13:58:52 2009 From: ajax at redhat.com (Adam Jackson) Date: Mon, 06 Jul 2009 09:58:52 -0400 Subject: an update to automake-1.11? In-Reply-To: References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> Message-ID: <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> On Sun, 2009-07-05 at 18:50 -0400, Sam Varshavchik wrote: > Richard W.M. Jones writes: > > On Sun, Jul 05, 2009 at 10:45:46AM -0400, Sam Varshavchik wrote: > >> What line number changes? You cut a patch against configure, and you're > >> done. That's it. > > > > And you get a big patch containing line numbers. Here's a single line > > change to configure.ac, and the corresponding patch that generates: > ====================== > > Who said anything about patching configure.ac? The cited link is not a patch > to the configure script, it's a result of a patch to configure.ac. > > I'll repeat again: patch configure, not configure.ac. > > I said "patch configure", and you reply, "well, it won't work because if you > patch configure.ac, run autoconf, then generate the patch between the > original configure, and the new configure, I get a big hairball". Duh. The fundamental problem with patching configure instead of configure.ac (or Makefile instead of Makefile.am) is that it's changing the wrong semantic level. As a bad example (because sed would be a better tool), imagine a patch to Makefile that does basically s/-O2/-Os/g. Now upstream makes a new release, and adds a new build target. Your patch might still apply, but it'll miss the CFLAGS emitted for the new target, and your patch will no longer _mean_ the same thing it used to. This is the same reason we patch .c files, and not the intermediate .i or .S. Don't let the fact that you never see the intermediate files in the tarball confuse you. You don't see them because they're not abstraction levels humans should have to deal with; and neither is the complete expanded configure script. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ajax at redhat.com Mon Jul 6 14:22:20 2009 From: ajax at redhat.com (Adam Jackson) Date: Mon, 06 Jul 2009 10:22:20 -0400 Subject: an update to automake-1.11? In-Reply-To: References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> Message-ID: <1246890140.25343.8650.camel@atropine.boston.devel.redhat.com> On Mon, 2009-07-06 at 14:22 +0200, Kevin Kofler wrote: > Sam Varshavchik wrote: > > How exactly would that violate the GPL? > > You aren't patching the actual source code. Assuming GPLv2, the term in the license that you're referring to is "preferred form". There is clearly some difference of opinion as to what the preferred form is here. In a strict construction sense, the preferred form for modification is whatever the modifier opted to modify. More concretely, the source code on offer in section 3 is the "corresponding source", meaning, the code and changes _you_ used to produce the binary. If you changed the generated source, well, that's a thing you can do, and it means you have to distribute those changes. If you change the metasource, that's also a thing you can do, and you have to distribute the recipe for creating the generated source. In other words: no. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at j2solutions.net Mon Jul 6 14:37:14 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 6 Jul 2009 07:37:14 -0700 Subject: rawhide report: 20090705 changes In-Reply-To: References: <20090705112158.GA32600@releng2.fedora.phx.redhat.com> <20090705224635.GA4928@redhat.com> <20090706003644.GA19829@hansolo.jdub.homelinux.org> Message-ID: <60C61E9E-88BB-4054-A248-303682303B5F@j2solutions.net> On Jul 6, 2009, at 0:27, drago01 wrote: > On Mon, Jul 6, 2009 at 2:36 AM, Josh Boyer wrote: >> On Sun, Jul 05, 2009 at 06:46:36PM -0400, Dave Jones wrote: >>> On Sun, Jul 05, 2009 at 11:21:58AM +0000, Rawhide Report wrote: >>> >>>> kernel-2.6.31-0.42.rc2.fc12 >>>> --------------------------- >>>> * Sat Jul 04 2009 Chuck Ebbert >>>> - 2.6.31-rc1-git11 >>>> >>>> * Sat Jul 04 2009 Dave Jones 2.6.31-0.42.rc2 >>>> - 2.6.31-rc2 >>>> >>>> * Fri Jul 03 2009 Hans de Goede >>>> - Disable v4l1 ov511 and quickcam_messenger drivers (obsoleted by >>>> v4l2 gspca subdrivers) >>> >>> Why is the changelog out of order in the rawhide report? >>> It's the right way around in CVS. >> >> Because the script that generates it doesn't deal with multiple >> entries on the same day properly. It's becoming a common >> question. > > Why does it mess with them at all? > Why not just copy them from the specfile and assume that this is > correct? > Because the info is gathered from the repodata and not from opening each and every srpm. The tool is repodiff if you want to work on a patch. -- Jes From fedora at camperquake.de Mon Jul 6 14:41:51 2009 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 6 Jul 2009 16:41:51 +0200 Subject: rawhide report: 20090706 changes In-Reply-To: <20090706131612.GA22283@releng2.fedora.phx.redhat.com> References: <20090706131612.GA22283@releng2.fedora.phx.redhat.com> Message-ID: <20090706164151.2bbd18bd@dhcp03.addix.net> Hi. On Mon, 6 Jul 2009 13:16:12 +0000, Rawhide Report wrote: > prelink-0.4.1-1.fc12 > -------------------- > * Sun Jul 05 2009 Jakub Jelinek 0.4.1-1 > - add support for STT_GNU_IFUNC on i?86/x86_64 and > R_{386,X86_64}_IRELATIVE > - add support for DWARF3/DWARF4 features generated newly by recent > gccs > - temporarily link prelink against -lpthread to workaround -lselinux > issue Does this make updating glibc safe again? From sandeen at redhat.com Mon Jul 6 14:49:31 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Mon, 06 Jul 2009 09:49:31 -0500 Subject: Possible packages... In-Reply-To: <05069AE3-863E-4A0D-9E75-B42988B4B2EC@gnat.ca> References: <4A517090.3090609@redhat.com> <05069AE3-863E-4A0D-9E75-B42988B4B2EC@gnat.ca> Message-ID: <4A520EFB.4080703@redhat.com> Nathanael Noblet wrote: > On Jul 5, 2009, at 9:33 PM, Eric Sandeen wrote: ... > Well their python run script checks for its dependancies, and if not > met will do a svn checkout of the right copy, however, they don't keep > copies of the libraries within their own repository. So if you fulfill > all its dependancies that shouldn't be an issue. Ah, ok - maybe that was it. > As for data storage > and all that I assume the methods they choose to store data aren't > part of the review? Plus that is configurable between a few different > choices. Right, as long as it's not putting it in /apple or something it should be fine. > >> FWIW I looked at DAViCal (http://rscds.sourceforge.net/) too and it >> seemed like an interesting possibility as well. > > Looks interesting, however the last release was well over a year ago > it seems. Whereas Apple's CalendarServer is likely to receive more > constant development. I guess there is a chance the Apple starts > adding some features only available in their commercial version I > guess... but I'm not sure if that is relevant either... Ok, if it's stagnant then maybe not such a good choice. > So would a good start be attempting to package calendar server for F11 > along with verifying its dependancies and then getting someone to > review it? Yep, just follow the review guidelines... > I'm a little curious about the one library that F11 packages (libevent > at 1.4.x, where calendar server seems to download a 1.5.x...) Do I > repackage libevent as part of my packages to be reviewed? Or simply > talk to the maintainer of libevent to see if it can be bumped? On my > system the only package that required libevent was something related > to nfs... though I guess there could be others but I haven't checked... Looking at http://monkey.org/~provos/libevent/ there's no mention of 1.5.x on the front page anyway. Where does it get it? steved 'Steve Dickson' owns libevent, you could talk w/ him. Starting w/ rawhide may be easier. -Eric From skvidal at fedoraproject.org Mon Jul 6 14:48:51 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 6 Jul 2009 10:48:51 -0400 (EDT) Subject: comps groupreqs??? Message-ID: A message from Will Woods on thursday made me go looking at the comps file for a bit. A few groups have these sections: x-software-development this tag is not supported (and hasn't been) for a while in comps. So groupreq is going to do exactly NOTHING. If you are the caretaker of a group and it has a grouplist and a groupreq - remove it - they just add data that nothing uses. thanks, -sv From pbrobinson at gmail.com Mon Jul 6 15:00:23 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 6 Jul 2009 16:00:23 +0100 Subject: Possible packages... In-Reply-To: <4A517090.3090609@redhat.com> References: <4A517090.3090609@redhat.com> Message-ID: <5256d0b0907060800l3f979c87tb1584992063f0fc7@mail.gmail.com> Hi, >> ? ?So I've been toying with the idea of getting more involved with >> fedora. Up till now if there has been a bug or other issue, i'll file >> a bug or simply get the srpm and try to update it to a newer version, >> or create my own specs / rpms when they don't already exist. Lately >> I've figured that I should get more involved with some of the packages >> that I use or anything like that. The packaging guidelines kinda >> describe entry to the packager group as being done via new packages. >> I've offered to try to help on some recently orphaned packages. Though >> that may be more work than just submitting a new package. >> >> So after all that rambling, I'm wondering about the two following >> pieces of software. >> >> Apple's Calendar Server. It runs using python 2.5 or greater (I've >> installed it on a F11 machine and it work well). I've started looking >> at some of its dependancies. 90% of them are in fedora already, and of >> the ones in F11, only one if I remember correctly isn't at the version >> it requires). It seems like a great addition to Fedora if you ask me. >> So basically it would require two new packages, and an update to one >> other package (libevent) which is a minor version bump it seems if at >> all needed. > > I'd love to see a calendar server in Fedora, though TBH when I looked at > Apple's long ago it was a bit daunting; it seemed like one of those > cross-platform hacks that is very much -not- nicely integrated with the > OS (I don't remember the details; weird file hierarchies or private > copies of libraries or ...?). ?Maybe it's better now. ?But if not, that > may be a hiccup. ?But I'd say give it a shot. ?I'd help test it. ?:) > > FWIW I looked at DAViCal (http://rscds.sourceforge.net/) too and it > seemed like an interesting possibility as well. I was looking for one of these the other day as well :-) The one I came across was mod_caldav it seems quite simple. http://sourceforge.net/projects/modcaldav/ It depends on mod_dav_acl which isn't in Fedora but I got as far as a few issues with the build and haven't had another chance to have a look at it. http://sourceforge.net/projects/moddavacl/ Cheers, Peter From Jochen at herr-schmitt.de Mon Jul 6 15:00:27 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 06 Jul 2009 17:00:27 +0200 Subject: readline update? In-Reply-To: <20090703102747.GA32668@localhost> References: <20090703102747.GA32668@localhost> Message-ID: <0MKxQS-1MNpgA3ddv-0003Aw@mrelayeu.kundenserver.de> On Fri, 3 Jul 2009 12:27:47 +0200, you wrote: >gnu-smalltalk-3.1-5.fc12 I have revisited this package for a license check and changed the license tag to GPLv2+ with exceptions Best Regards: Jochen Schmitt From kanarip at kanarip.com Mon Jul 6 15:13:45 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 06 Jul 2009 17:13:45 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <364d303b0907051413q4cc36c70r7173e5cdd2b66e1f@mail.gmail.com> References: <4A4FD09C.7000809@kanarip.com> <364d303b0907051413q4cc36c70r7173e5cdd2b66e1f@mail.gmail.com> Message-ID: <99e6529575712252b1bd8ff6e14376f3@localhost> On Sun, 5 Jul 2009 22:13:07 +0100, Christopher Brown wrote: > Honestly, I'm impressed by your persistence but I think simply trying > to re-instate Fedora Legacy (which it sounds like this is what you are > trying to do) is doomed to permanent failure. > I love your argumentation behind this statement; Why do you think it's doomed exactly? Is it reasoning following the past Fedora Legacy initiatives (and failure), or is there anything new? -- Jeroen From kanarip at kanarip.com Mon Jul 6 15:16:20 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 06 Jul 2009 17:16:20 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> Message-ID: <274944a91ddd993d4f5d96cdc3b5ed14@localhost> On Mon, 06 Jul 2009 02:03:01 +0200, Kevin Kofler wrote: > Jeroen van Meeuwen wrote: >> Whether 6 months of additional availability of security updates is going >> to help, and to what extend, we'll have to see. Compared to the current >> situation, that'll give an environment 7 months to upgrade beyond the >> moment that we now call End-Of-Life for a given release and 3 releases to >> choose from -certainly a lot more time then 1 month and 2 releases to >> choose from. > > They already have 7 months of time to move to the next version. It's just > if > they absolutely want to skip a version that they only have 1 month. > True, but consider that moving to Fedora N+1 requires one to reconsider within 6 months. As such I'd say choosing the Fedora N+1 option when Fedora N+2 does not meet ones needs or expectations and one decides to put off on upgrading to Fedora N+2, leaves them with a one month upgrade opportunity after Fedora N+3's GA after all, and so is not exactly without penalty. Kind regards, Jeroen van Meeuwen -kanarip From snecklifter at gmail.com Mon Jul 6 15:25:08 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Mon, 6 Jul 2009 16:25:08 +0100 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <99e6529575712252b1bd8ff6e14376f3@localhost> References: <4A4FD09C.7000809@kanarip.com> <364d303b0907051413q4cc36c70r7173e5cdd2b66e1f@mail.gmail.com> <99e6529575712252b1bd8ff6e14376f3@localhost> Message-ID: <364d303b0907060825p2840e5f7wb871675f5ab1547f@mail.gmail.com> 2009/7/6 Jeroen van Meeuwen : > > On Sun, 5 Jul 2009 22:13:07 +0100, Christopher Brown > > wrote: >> Honestly, I'm impressed by your persistence but I think simply trying >> to re-instate Fedora Legacy (which it sounds like this is what you are >> trying to do) is doomed to permanent failure. >> > > I love your argumentation behind this statement; > > Why do you think it's doomed exactly? Is it reasoning following the past > Fedora Legacy initiatives (and failure), or is there anything new? That plus the fact that you have Red Hat, the major backers of Fedora, producing a distribution that is geared towards long term support for their clients. Hence any initiative to increase the length of time Fedora is supported will not (I believe) receive anything more than lip service from RH. I completely understand that and it makes financial sense. The more you try and give Fedora some kind of LTS, the more you stray into territory already covered by RHEL (paid support) or CentOS (unpaid support). I was simply trying to identify what the requirements are for LTS on Fedora. I think simply saying "Fedora needs LTS" is doomed as the past has proved. "Those that forget the past are doomed to repeat it." - George Santayana The sooner Fedora gets out of its identity crisis the better. I believe the following: Fedora is the distribution for those who love computers. CentOS, Ubuntu and others are for those who dont. Regards -- Christopher Brown From kanarip at kanarip.com Mon Jul 6 15:27:23 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 06 Jul 2009 17:27:23 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <1246872463.10674.107.camel@macbook.infradead.org> References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> <66ff0543780f93d7f263af099cd22e1d@localhost> <1246790384.6295.13.camel@macbook.infradead.org> <1246872463.10674.107.camel@macbook.infradead.org> Message-ID: <4c12112313d21f3b2f7edf714afe0c8e@localhost> On Mon, 06 Jul 2009 10:27:43 +0100, David Woodhouse wrote: > On Sun, 2009-07-05 at 17:52 +0200, Jeroen van Meeuwen wrote: >> >> >> As described on the Feature page, but if there's any specific >> questions >> about the reasoning on there I'll be happy to answer those questions. > > I had read the feature page, in which you claim that a three-year cycle > "disqualifies the distribution(s) as desktop Linux distributions". > > I didn't see any justification for that assertion, especially given that > you're simultaneously claiming that a 13-month lifetime isn't long > _enough_ for you. > Hold on... Realistically, the current 13 month life cycle is about 7-8 months too long for me personally as I upgrade to rawhide anywhere between Beta and GA everywhere I can ;-) This extended life cycle feature is not to support my own needs and/or expectations. The longer (3 year approx.) release cycle doesn't necessarily disqualify a distribution for desktop environments, but for some environments that have a desire to run newer software. The shorter life cycle (~13 months) however is a major downside to many businesses -in my experience. > You've conveniently dodged the question of what lifetime you _do_ want > to provide, by saying 'yet to be determined'. But you must have _some_ > idea, if you're so sure that 13 months is too short and 36 months is too > long. > As the page says, at: https://fedoraproject.org/wiki/Features/Extended_Life_Cycle#Notes my initial thoughts are 6 months extra (~19 months total). This will give us enough time to establish whether this is successful (although not meeting it's full potential success after this short a period of time), and whether this is sustainable. > How much work would it take, to make it possible for us to still ship > updates for a release which has officially reached EOL? Does the sky > fall on our heads if we don't push the 'Kill F-9' button in koji and > bodhi precisely 1 month after the F-11 release? > Overall, roughly estimated, it'll take 1 FTE to do all the work involved. Whether that is one person doing all the work (including patching, building, maintaining infra, pushing, signing, etc, etc..), or 80 people doing all kinds of various stuff, doesn't matter; It'd still come down to approximately 1 FTE. > As a first step, perhaps we try that -- still officially state that the > release is EOL and should not be used, but _allow_ interested people > like Jeroen (and the original package owners, _if_ they are so inclined) > to continue to build and push updates, instead of forcibly cutting off > builds and updates as we do at the moment. > As suggested on the wiki page, we rename "EOL" to End-Of-Support (EOS), only to make a given release EOL after the period of time we decide to provide security updates for. Of course, not renaming EOL to EOS does not block anything from moving forward. > That _isn't_ something we would publish as a 'feature' though -- it > would strictly _unofficial_, although you'd be permitted to use the > Fedora infrastructure for it. > > If it turns out that there _is_ enough interest and the interested > people are _actually_ keeping on top of security fixes etc., then maybe > we could consider officially admitting that it happens, and _then_ > publishing it as a 'feature'. And/or extending it to more than one extra > release. But those are all questions for the future. > > If it doesn't take too much infrastructure work, I see no reason why we > shouldn't let them _try_. It doesn't hurt Fedora at all, does it? > Thank you, Kind regards, Jeroen van Meeuwen -kanarip From skvidal at fedoraproject.org Mon Jul 6 15:27:08 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 6 Jul 2009 11:27:08 -0400 (EDT) Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <364d303b0907060825p2840e5f7wb871675f5ab1547f@mail.gmail.com> References: <4A4FD09C.7000809@kanarip.com> <364d303b0907051413q4cc36c70r7173e5cdd2b66e1f@mail.gmail.com> <99e6529575712252b1bd8ff6e14376f3@localhost> <364d303b0907060825p2840e5f7wb871675f5ab1547f@mail.gmail.com> Message-ID: On Mon, 6 Jul 2009, Christopher Brown wrote: > The sooner Fedora gets out of its identity crisis the better. I > believe the following: > > Fedora is the distribution for those who love computers. > CentOS, Ubuntu and others are for those who dont. > well, crap. I guess I'm in the wrong place ;) -sv From kanarip at kanarip.com Mon Jul 6 15:36:25 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 06 Jul 2009 17:36:25 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <20090706111130.GC19829@hansolo.jdub.homelinux.org> References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> <66ff0543780f93d7f263af099cd22e1d@localhost> <1246790384.6295.13.camel@macbook.infradead.org> <1246872463.10674.107.camel@macbook.infradead.org> <20090706111130.GC19829@hansolo.jdub.homelinux.org> Message-ID: On Mon, 6 Jul 2009 07:11:30 -0400, Josh Boyer wrote: > No, the sky does not fall. There are a few hurdles though. > > 1) Master mirror space. This used to be an issue, in that we had to move > older releases to alt.fp.o in order to make space for the new release. I > believe we still do that, so either the yum.repo.d config files for the EOL > release would need to be changed, or we'd have to grow a lot more mirror > space. > > 2) Update push times. It takes 3+ hours to mash f9-updates right now. > Keeping > that time duration in the official updates pushing for an EOL release would > be really annoying. Particularly since we are already going to hit some > major > time hurdles as F10 and F11 age and definitely when we add F12. > These are very valid constraints/concerns which I've added to the Feature wiki page. This is stuff I like to hear ;-) > It doesn't work that way in practice. If it is allowed, it is official. > You > have to coordinate downtimes, End-of-Life-After-Death times, etc. The > minute > it's disabled early for one reason or another (space, time constraints, > etc) > people will cry foul even if it was "unofficial". > This (downtimes, etc) is why initially, I wanted the period of time between EOS and EOL to match a release cycle. I guess these dependencies make it a little more required to stick with periods of time equal to the release-cycle of a Fedora release. >>If it turns out that there _is_ enough interest and the interested >>people are _actually_ keeping on top of security fixes etc., then maybe >>we could consider officially admitting that it happens, and _then_ >>publishing it as a 'feature'. And/or extending it to more than one extra >>release. But those are all questions for the future. > > I would encourage people to run this as a secondary architecture. CVS > still > remains open for commits. You could just have a secondary koji hub for the > builds. > It that's the solution to problems (to be) set forth, then so be it. I would love to have it as part of the primary infrastructure but then again it's no blocker. >>If it doesn't take too much infrastructure work, I see no reason why we >>shouldn't let them _try_. It doesn't hurt Fedora at all, does it? > > There is minimal pain, yes. Mostly to infrastructure and rel-eng. What I > don't immediately see is the benefit to Fedora overall. > Is it you question the benefit given in the paragraph on the Feature page, or ...? Thanks, Kind regards, Jeroen van Meeuwen -kanarip From walters at verbum.org Mon Jul 6 15:42:14 2009 From: walters at verbum.org (Colin Walters) Date: Mon, 6 Jul 2009 11:42:14 -0400 Subject: ppc64 assistance In-Reply-To: References: <5256d0b0907020329k8ed1219ldf26d4443e4858b@mail.gmail.com> <5256d0b0907020620x18420b4ah8574122feae83221@mail.gmail.com> Message-ID: On Thu, Jul 2, 2009 at 9:30 AM, Colin Walters wrote: > On Thu, Jul 2, 2009 at 9:20 AM, Peter Robinson wrote: >> >> Interestingly with -ggdb it builds fine with out without -O0. > > That makes it a lot more likely to be a compiler flaw (though not guaranteed). Of course, it turns out this is very likely not a compiler flaw. Compiler authors everywhere are shocked I'm sure. See: http://bugzilla.gnome.org/show_bug.cgi?id=587823 And http://git.gnome.org/cgit/gobject-introspection/commit/?id=a1f5af4683b08892e87288ef4906782f4094703d From kanarip at kanarip.com Mon Jul 6 15:46:51 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 06 Jul 2009 17:46:51 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <364d303b0907060825p2840e5f7wb871675f5ab1547f@mail.gmail.com> References: <4A4FD09C.7000809@kanarip.com> <364d303b0907051413q4cc36c70r7173e5cdd2b66e1f@mail.gmail.com> <99e6529575712252b1bd8ff6e14376f3@localhost> <364d303b0907060825p2840e5f7wb871675f5ab1547f@mail.gmail.com> Message-ID: On Mon, 6 Jul 2009 16:25:08 +0100, Christopher Brown wrote: > 2009/7/6 Jeroen van Meeuwen : >> >> On Sun, 5 Jul 2009 22:13:07 +0100, Christopher Brown >> >> wrote: >>> Honestly, I'm impressed by your persistence but I think simply trying >>> to re-instate Fedora Legacy (which it sounds like this is what you are >>> trying to do) is doomed to permanent failure. >>> >> >> I love your argumentation behind this statement; >> >> Why do you think it's doomed exactly? Is it reasoning following the past >> Fedora Legacy initiatives (and failure), or is there anything new? > > That plus the fact that you have Red Hat, the major backers of Fedora, > producing a distribution that is geared towards long term support for > their clients. Hence any initiative to increase the length of time > Fedora is supported will not (I believe) receive anything more than > lip service from RH. I completely understand that and it makes > financial sense. > "lip service" doesn't translate very well but I think I got the clue; If you're saying that Red Hat would choose to not support this initiative for whatever their reasons, may be, then so be it. I can't control what they do and I wouldn't want to. I can control however what I do with or without Red Hat's blessing. > I was simply trying to identify what the requirements are for LTS on > Fedora. I think simply saying "Fedora needs LTS" is doomed as the past > has proved. "Those that forget the past are doomed to repeat it." - > George Santayana > I'm too eager to respond with similar phrases as put onto the Feature wiki page; if the difference between the long term support model for RHEL and an extended life cycle model for Fedora isn't clear enough, then how can I explain the added value of a commercial company backing it's product, stable API/ABI offerings, hardware and software certifications, a phone number, the differences between 7 years or 19 months, desktop environments vs. enterprise solutions, prolonged availability of security updates (only!) vs. prolonged application support (including security updates), and the difference between 19 months and 3 years? > The sooner Fedora gets out of its identity crisis the better. I wholeheartedly agree, but it's a completely different discussion. Kind regards, Jeroen van Meeuwen -kanarip From cdahlin at redhat.com Mon Jul 6 15:53:05 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Mon, 06 Jul 2009 11:53:05 -0400 Subject: [Fwd: Re: vPython] In-Reply-To: <4A50A0EF.7040804@gmail.com> References: <469E6BB7.2070103@redhat.com> <4A50A0EF.7040804@gmail.com> Message-ID: <4A521DE1.9070105@redhat.com> On 07/05/2009 08:47 AM, Brad wrote: > I have rpms for older versions of vpython and a tutorial on how to make > rpms. Here is some information that might be > useful(http://rpmbuildtut.wordpress.com/). Let me know if you need any > help. > This thread is years old. It probably shouldn't be bumped. If you want to revive this topic you should send a new email to fedora-devel with a better subject and some body text that makes a better starting point to a discussion. Are you mailing devel-list because you are interested again in packaging vpython? --CJD > > ?Brad Longo > North Carolina State University > Aerospace Engineering/Applied Mathematics > Raleigh, NC USA > 862.266.7066 > brad.longo at gmail.com > > > > Casey Dahlin wrote >> >> >> -------- Original Message -------- >> Subject: Re: vPython >> Date: Fri, 13 Jul 2007 10:54:50 -0400 (EDT) >> From: Greg Dekoenigsberg >> To: Casey Dahlin >> References: <46979159.2050605 at redhat.com> >> >> >> >> On Fri, 13 Jul 2007, Casey Dahlin wrote: >> >>> At NCSU, nearly every student in every department codes a small >>> subset of python once during their studies. This is due to the >>> physics department's use of a library called vPython. vPython is >>> simply a 3d library. Its capabilities are very limited but it is >>> extremely simple to use. Basically any student who takes a physics >>> lab at state (usually a general education requirement) learns to >>> model physics problems in vPython (admittedly without ever seeing so >>> much as a conditional or loop). >>> >>> I bring this up because vPython is very very difficult to install on >>> Fedora. there is no RPM, and many of the dependencies for building >>> the source are very difficult to resolve due to conflicts etc. >>> However I do have a friend who has found a procedure to do it. What >>> would be the process for getting vPython included as a package in >>> Fedora? It'd be one step closer to getting the Physics people off of >>> win2k. >> >> It is not a simple process. It should probably be simpler. But it's >> not rocket science, either. It's documented here: >> >> http://fedoraproject.org/wiki/PackageMaintainers/Join >> >> If you'd like to do this, I'd really appreciate a newbie's detailed >> impressions of the process of joining the world of Fedora packagers. :) >> >> --g >> > From jos at xos.nl Mon Jul 6 15:49:52 2009 From: jos at xos.nl (Jos Vos) Date: Mon, 6 Jul 2009 17:49:52 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <364d303b0907060825p2840e5f7wb871675f5ab1547f@mail.gmail.com> References: <4A4FD09C.7000809@kanarip.com> <364d303b0907051413q4cc36c70r7173e5cdd2b66e1f@mail.gmail.com> <99e6529575712252b1bd8ff6e14376f3@localhost> <364d303b0907060825p2840e5f7wb871675f5ab1547f@mail.gmail.com> Message-ID: <20090706154952.GC23003@jasmine.xos.nl> On Mon, Jul 06, 2009 at 04:25:08PM +0100, Christopher Brown wrote: > The more you try and give Fedora some kind of LTS, the more you stray > into territory already covered by RHEL (paid support) or CentOS > (unpaid support). The term "unpaid support" sounds very misleading. You can also buy paid support from various companies for CentOS and other rebuilds. For the rest, there is no formal support (with support I mean here somthing you can count on). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From jwboyer at gmail.com Mon Jul 6 15:59:48 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 6 Jul 2009 11:59:48 -0400 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: References: <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> <66ff0543780f93d7f263af099cd22e1d@localhost> <1246790384.6295.13.camel@macbook.infradead.org> <1246872463.10674.107.camel@macbook.infradead.org> <20090706111130.GC19829@hansolo.jdub.homelinux.org> Message-ID: <20090706155948.GE19829@hansolo.jdub.homelinux.org> On Mon, Jul 06, 2009 at 05:36:25PM +0200, Jeroen van Meeuwen wrote: >>>If it doesn't take too much infrastructure work, I see no reason why we >>>shouldn't let them _try_. It doesn't hurt Fedora at all, does it? >> >> There is minimal pain, yes. Mostly to infrastructure and rel-eng. What >I >> don't immediately see is the benefit to Fedora overall. >> > >Is it you question the benefit given in the paragraph on the Feature page, >or ...? Yes, I question the benefit listed in the Feature page. I have personally seen evidence to the contrary that the current release cycles are too short to enable corporate usage. However, I have no doubt that you could also come up with data supporting your claim. I am simply not convinced (yet) that the stated benefit is enough to warrant the cost. This does not mean you are wrong, and I do not want to get into a bikeshed argument about it. josh From jwboyer at gmail.com Mon Jul 6 16:03:04 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 6 Jul 2009 12:03:04 -0400 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <99e6529575712252b1bd8ff6e14376f3@localhost> References: <4A4FD09C.7000809@kanarip.com> <364d303b0907051413q4cc36c70r7173e5cdd2b66e1f@mail.gmail.com> <99e6529575712252b1bd8ff6e14376f3@localhost> Message-ID: <20090706160304.GF19829@hansolo.jdub.homelinux.org> On Mon, Jul 06, 2009 at 05:13:45PM +0200, Jeroen van Meeuwen wrote: > >On Sun, 5 Jul 2009 22:13:07 +0100, Christopher Brown > >wrote: >> Honestly, I'm impressed by your persistence but I think simply trying >> to re-instate Fedora Legacy (which it sounds like this is what you are >> trying to do) is doomed to permanent failure. >> > >I love your argumentation behind this statement; > >Why do you think it's doomed exactly? Is it reasoning following the past >Fedora Legacy initiatives (and failure), or is there anything new? Hyperbole aside, ignoring history doesn't seem prudent. Fedora Legacy (the original one) failed. The last time something like this was proposed, it generated a few meetings and some discussion here and on f-a-b. I have yet to see anything actually come of that. Without a concrete group of people large enough to make this wory saying that they are signing up to do that work, I don't have high hopes for this succeeding in the long run. josh From pbrobinson at gmail.com Mon Jul 6 16:07:27 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 6 Jul 2009 17:07:27 +0100 Subject: ppc64 assistance In-Reply-To: References: <5256d0b0907020329k8ed1219ldf26d4443e4858b@mail.gmail.com> <5256d0b0907020620x18420b4ah8574122feae83221@mail.gmail.com> Message-ID: <5256d0b0907060907o7cae0babo5990f750bab901ec@mail.gmail.com> >>> Interestingly with -ggdb it builds fine with out without -O0. >> >> That makes it a lot more likely to be a compiler flaw (though not guaranteed). > > Of course, it turns out this is very likely not a compiler flaw. > Compiler authors everywhere are shocked I'm sure. > > See: http://bugzilla.gnome.org/show_bug.cgi?id=587823 > And > http://git.gnome.org/cgit/gobject-introspection/commit/?id=a1f5af4683b08892e87288ef4906782f4094703d Doing a scrratch build it gets further but there's another failure, although I haven't tried this with git head. http://koji.fedoraproject.org/koji/getfile?taskID=1457149&name=build.log Peter From kanarip at kanarip.com Mon Jul 6 16:11:00 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 06 Jul 2009 18:11:00 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <20090706155948.GE19829@hansolo.jdub.homelinux.org> References: <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> <66ff0543780f93d7f263af099cd22e1d@localhost> <1246790384.6295.13.camel@macbook.infradead.org> <1246872463.10674.107.camel@macbook.infradead.org> <20090706111130.GC19829@hansolo.jdub.homelinux.org> <20090706155948.GE19829@hansolo.jdub.homelinux.org> Message-ID: <396a2df177a2f71265eef7eb3e0b7634@localhost> On Mon, 6 Jul 2009 11:59:48 -0400, Josh Boyer wrote: > On Mon, Jul 06, 2009 at 05:36:25PM +0200, Jeroen van Meeuwen wrote: >>>>If it doesn't take too much infrastructure work, I see no reason why we >>>>shouldn't let them _try_. It doesn't hurt Fedora at all, does it? >>> >>> There is minimal pain, yes. Mostly to infrastructure and rel-eng. What >>I >>> don't immediately see is the benefit to Fedora overall. >>> >> >>Is it you question the benefit given in the paragraph on the Feature page, >>or ...? > > Yes, I question the benefit listed in the Feature page. I have personally > seen evidence to the contrary that the current release cycles are too short > to enable corporate usage. However, I have no doubt that you could also > come > up with data supporting your claim. > > I am simply not convinced (yet) that the stated benefit is enough to > warrant > the cost. This does not mean you are wrong, and I do not want to get into > a > bikeshed argument about it. > Neither do I, but I'll take your doubts and see what I can do about them (through the Feature page), if anything. If only we could put out finger on the actual cost, or even just put our finger on the actual benefit, things would be a little clearer, but regrettably, the figures are unavailable until after we try :/ I guess that *who* does (is going to do, would be doing) the actual work is of significant importance as well. -- Jeroen From rdieter at math.unl.edu Mon Jul 6 16:16:45 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 06 Jul 2009 11:16:45 -0500 Subject: Feature proposal: Extended Life Cycle Support References: <4A4FD09C.7000809@kanarip.com> Message-ID: Jeroen van Meeuwen wrote: > I wanted to draw your attention to a feature I've proposed for Fedora > 12, mysteriously called Extended Life Cycle. > > You can find more details at > https://fedoraproject.org/wiki/Features/Extended_Life_Cycle As one who could directly benefit (@ work) and participate in such a venture, I would support it and participate. -- Rex From sundaram at fedoraproject.org Mon Jul 6 16:20:53 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 06 Jul 2009 21:50:53 +0530 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <4A4FD09C.7000809@kanarip.com> References: <4A4FD09C.7000809@kanarip.com> Message-ID: <4A522465.1010400@fedoraproject.org> On 07/05/2009 03:28 AM, Jeroen van Meeuwen wrote: > I wanted to draw your attention to a feature I've proposed for Fedora > 12, mysteriously called Extended Life Cycle. > > You can find more details at > https://fedoraproject.org/wiki/Features/Extended_Life_Cycle Instead of saying "yet to be determined", put in the actual number of say 20 months there in the summary upfront. The FAQ should also answer "How is this going to succeed, where Fedora Legacy failed?". You should put in a place for people to sign up for this effort. If more people volunteer, it would make answer the question on who is actually going to do this. Is opt-in ELC support for every release or is it going to be an experimental effort just for Fedora 12 to evaluate feasibility? How would you prefer to brand it? Would maintenance of packages be available for a separate ELC support team if the primary maintainers are not interested? Do you want to focus on a "core" set of packages instead of everything? If people had a better handle on what exactly they are volunteering for, more of them might. Rahul From pertusus at free.fr Mon Jul 6 16:23:33 2009 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 6 Jul 2009 18:23:33 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: References: <4A4FD09C.7000809@kanarip.com> Message-ID: <20090706162333.GD26575@free.fr> On Mon, Jul 06, 2009 at 11:16:45AM -0500, Rex Dieter wrote: > Jeroen van Meeuwen wrote: > > > I wanted to draw your attention to a feature I've proposed for Fedora > > 12, mysteriously called Extended Life Cycle. > > > > You can find more details at > > https://fedoraproject.org/wiki/Features/Extended_Life_Cycle > > As one who could directly benefit (@ work) and participate in such a > venture, I would support it and participate. In the previous try I remember that Kevin Kofler, Orion, Ralf Corsepius and Manuel were interested. I was too, but I am not in fedora anymore. -- Pat From pertusus at free.fr Mon Jul 6 16:29:33 2009 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 6 Jul 2009 18:29:33 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <4A522465.1010400@fedoraproject.org> References: <4A4FD09C.7000809@kanarip.com> <4A522465.1010400@fedoraproject.org> Message-ID: <20090706162933.GE26575@free.fr> On Mon, Jul 06, 2009 at 09:50:53PM +0530, Rahul Sundaram wrote: > > The FAQ should also answer > "How is this going to succeed, where Fedora Legacy failed?". You should this was debated a lot in the previous attempts, and I still think that any attempt to do this with fedora infra (not necessarily speaking about resources, but more about policies) is very different from Fedora Legacy. The policies of fedora legacy were very different than in fedora extras in these days, and I think this is one of the reasons why it failed. At least it is why I didn't stepped in, although I was very interested. This is not a valid point of comparison. EPEL is certainly a much more relevant point of comparison. -- Pat From sundaram at fedoraproject.org Mon Jul 6 16:32:16 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 06 Jul 2009 22:02:16 +0530 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <20090706162933.GE26575@free.fr> References: <4A4FD09C.7000809@kanarip.com> <4A522465.1010400@fedoraproject.org> <20090706162933.GE26575@free.fr> Message-ID: <4A522710.5010107@fedoraproject.org> On 07/06/2009 09:59 PM, Patrice Dumas wrote: > On Mon, Jul 06, 2009 at 09:50:53PM +0530, Rahul Sundaram wrote: >> >> The FAQ should also answer >> "How is this going to succeed, where Fedora Legacy failed?". You should > > this was debated a lot in the previous attempts, and I still think that > any attempt to do this with fedora infra (not necessarily speaking about > resources, but more about policies) is very different from Fedora Legacy. > The policies of fedora legacy were very different than in fedora extras in > these days, and I think this is one of the reasons why it failed. At least it > is why I didn't stepped in, although I was very interested. > > This is not a valid point of comparison. EPEL is certainly a much more > relevant point of comparison. You may be right but answering this question upfront in the feature page will help move the discussions to other important issues. I would be more willing to support this effort and get involved if the questions were answered convincingly. Rahul From walters at verbum.org Mon Jul 6 16:42:45 2009 From: walters at verbum.org (Colin Walters) Date: Mon, 6 Jul 2009 12:42:45 -0400 Subject: ppc64 assistance In-Reply-To: <5256d0b0907060907o7cae0babo5990f750bab901ec@mail.gmail.com> References: <5256d0b0907020329k8ed1219ldf26d4443e4858b@mail.gmail.com> <5256d0b0907020620x18420b4ah8574122feae83221@mail.gmail.com> <5256d0b0907060907o7cae0babo5990f750bab901ec@mail.gmail.com> Message-ID: On Mon, Jul 6, 2009 at 12:07 PM, Peter Robinson wrote: >>>> Interestingly with -ggdb it builds fine with out without -O0. >>> >>> That makes it a lot more likely to be a compiler flaw (though not guaranteed). >> >> Of course, it turns out this is very likely not a compiler flaw. >> Compiler authors everywhere are shocked I'm sure. >> >> See: http://bugzilla.gnome.org/show_bug.cgi?id=587823 >> And >> http://git.gnome.org/cgit/gobject-introspection/commit/?id=a1f5af4683b08892e87288ef4906782f4094703d > > Doing a scrratch build it gets further but there's another failure, > although I haven't tried this with git head. > > http://koji.fedoraproject.org/koji/getfile?taskID=1457149&name=build.log This looks relevant: http://sourceware.org/ml/libffi-discuss/2009/msg00185.html From darrellpf at gmail.com Mon Jul 6 16:54:13 2009 From: darrellpf at gmail.com (darrell pfeifer) Date: Mon, 6 Jul 2009 09:54:13 -0700 Subject: ck-list-sessions shows active = false Message-ID: Using rawhide and gdm-2.26.1-13.fc12.i586 when I do a ck-list-sessions I see Session4: unix-user = '500' realname = 'darrell pfeifer' seat = 'Seat5' session-type = '' active = FALSE x11-display = ':0' x11-display-device = '' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2009-07-06T15:56:08.908744Z' login-session-id = '' Currently almost all my device-related functionality is not working (including pulseaudio, mounting usb sticks, starting virtual machines). In addition, polkit-gnome-authorization and polkit-gnome-authorization are crashing. Am I on the right track thinking that the problem is gdm related? darrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at scrye.com Mon Jul 6 16:57:34 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 6 Jul 2009 10:57:34 -0600 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <4A4FD09C.7000809@kanarip.com> References: <4A4FD09C.7000809@kanarip.com> Message-ID: <20090706105734.29c92a78@ohm.scrye.com> On Sat, 04 Jul 2009 23:58:52 +0200 Jeroen van Meeuwen wrote: > I wanted to draw your attention to a feature I've proposed for Fedora > 12, mysteriously called Extended Life Cycle. > > You can find more details at > https://fedoraproject.org/wiki/Features/Extended_Life_Cycle > > Kind regards, Some general comments: - Have you talked with the last folks that attempted this? https://www.redhat.com/archives/fedora-advisory-board/2009-February/msg00030.html http://docs.google.com/Doc?id=dc7dcczk_2fxtsctdq&hl=en - The issue I have with this plan (and the others very like it) is that if you say "we will just do updates for the things we have people willing to do updates" it means the entire end of life distro is not covered and the likelyhood of an outstanding security issue is quite high. There is a chicken and egg issue here where unless there is enough coverage we shouldn't do it, but we can't find out if there is enough coverage without doing it. Doing it in such a way that it fails just gives everyone a bad name and feeling, IMHO. - An indeterminate time is also bad IMHO. How can these corporations plan if they don't know how much time you are adding here? - Have you considered leveraging the 'critical path' proposal? Try and up front get enough folks to cover all the critical path packages and expand from there? - How many people are on board with this? Do you have guidelines for what will be updated or not? what packages? Version updates ok? Or only security fixes? - Are there any Corporations that specifically asked for this? Would they be willing to provide any resources to the effort? Just a few thoughts... > Jeroen van Meeuwen > -kanarip kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From choeger at cs.tu-berlin.de Mon Jul 6 17:03:25 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 06 Jul 2009 19:03:25 +0200 Subject: RFC: cronKit Message-ID: <1246899805.5836.15.camel@choeger6> Hi, since I sync my mail with the experimental gnome ui of offlineimap, I encounter a small problem: How do I tell cron to only invoke the job when I am logged in under gnome only? Since consolekit (correct me if I am wrong on that) does not provide a way to get that information (it is even unclear if dbus is running at all), I was thinking of the following solution: Since I want the job only to be run if I am logged in under gnome the main idea is to have a process added to the session that can handle crontab like jobs (aka cronKit) Do you have any advice on that? Does such a software already exist? 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 opensource at till.name Mon Jul 6 17:21:25 2009 From: opensource at till.name (Till Maas) Date: Mon, 06 Jul 2009 19:21:25 +0200 Subject: RFC: cronKit In-Reply-To: <1246899805.5836.15.camel@choeger6> References: <1246899805.5836.15.camel@choeger6> Message-ID: <200907061921.43992.opensource@till.name> On Mon July 6 2009, Christoph H?ger wrote: > since I sync my mail with the experimental gnome ui of offlineimap, I > encounter a small problem: > How do I tell cron to only invoke the job when I am logged in under > gnome only? Since consolekit (correct me if I am wrong on that) does not > Do you have any advice on that? Does such a software already exist? You can probably replace "till" with your username and then use this in your crontab: ps u -C gnome-session | egrep -q "^till " && offlineimap Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From notting at redhat.com Mon Jul 6 17:56:43 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 6 Jul 2009 13:56:43 -0400 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <20090706105734.29c92a78@ohm.scrye.com> References: <4A4FD09C.7000809@kanarip.com> <20090706105734.29c92a78@ohm.scrye.com> Message-ID: <20090706175643.GB7415@nostromo.devel.redhat.com> Kevin Fenzi (kevin at scrye.com) said: > - The issue I have with this plan (and the others very like it) is that > if you say "we will just do updates for the things we have people > willing to do updates" it means the entire end of life distro is not > covered and the likelyhood of an outstanding security issue is quite > high. There is a chicken and egg issue here where unless there is > enough coverage we shouldn't do it, but we can't find out if there is > enough coverage without doing it. Doing it in such a way that it > fails just gives everyone a bad name and feeling, IMHO. > > - An indeterminate time is also bad IMHO. How can these corporations > plan if they don't know how much time you are adding here? These two are my big concerns - doing this badly is worse than not doing it, IMO. When it comes to user's security, I don't want to give promises we can't keep, or leave them in a bind. Other notes: - while F9 updates may be 3+ hours, F11 updates is currently *14-15* hours, and there aren't as many updates now as there will be; that number will only go up. (Yay deltarpms!) - You don't provide API/ABI guarantees. Which means you're signing up for more work than you might want if you're pushing updates to Firefox/xulrunner. (And if you're not providing updates for that for the desktop, it's not worth starting.) - You state that "the only reason that makes upgrading the distribution a requirement is the continuous availability of security updates. " This implies that you're fine with the feature set of an older distribution after a while; but you don't want something like RHEL or CentOS. Is it just the 'RHEL is sort of old in the tooth right now' sort of philosophy? Because by your metrics, a RHEL released now (or in 3 months, or whatever) would be fine. Also, just going back to original first principles: http://fedoraproject.org/wiki/Objectives "Fedora is not interested in having a slow rate of change, but rather to be innovative. We do not offer a long-term release cycle because it diverts attention away from innovation." Long term support, in general, goes against the directly objectives of the project. If it's felt that extending the life cycle a *specific, measureable amount* would be of more benefit to the project, that's probably a board issue, not a FESCo issue. Bill From choeger at cs.tu-berlin.de Mon Jul 6 18:02:34 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 06 Jul 2009 20:02:34 +0200 Subject: RFC: cronKit In-Reply-To: <200907061921.43992.opensource@till.name> References: <1246899805.5836.15.camel@choeger6> <200907061921.43992.opensource@till.name> Message-ID: <1246903354.5836.17.camel@choeger6> > ps u -C gnome-session | egrep -q "^till " && offlineimap Yeah, that would be a hack ;). -------------- 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 lemenkov at gmail.com Mon Jul 6 18:09:55 2009 From: lemenkov at gmail.com (Peter Lemenkov) Date: Mon, 6 Jul 2009 22:09:55 +0400 Subject: [RFE] Auto-approve watchcommits and watchbugzilla in Pkgdb Message-ID: Hello All! Why we should approve manually requests to watching bugzilla and cvs changes for packages? I'm sure we need to change policy in order to automatically approve all such requests. -- With best regards! From tgl at redhat.com Mon Jul 6 18:14:27 2009 From: tgl at redhat.com (Tom Lane) Date: Mon, 06 Jul 2009 14:14:27 -0400 Subject: [RFE] Auto-approve watchcommits and watchbugzilla in Pkgdb In-Reply-To: References: Message-ID: <18203.1246904067@sss.pgh.pa.us> Peter Lemenkov writes: > Why we should approve manually requests to watching bugzilla and cvs > changes for packages? I'm sure we need to change policy in order to > automatically approve all such requests. Isn't there a security issue there? I'm not sure I want any random person watching every bz or commit I make. regards, tom lane From kanarip at kanarip.com Mon Jul 6 18:20:50 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 06 Jul 2009 20:20:50 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <20090706105734.29c92a78@ohm.scrye.com> References: <4A4FD09C.7000809@kanarip.com> <20090706105734.29c92a78@ohm.scrye.com> Message-ID: <6e3ba5f24be85ab5aa79d152acc96095@localhost> On Mon, 6 Jul 2009 10:57:34 -0600, Kevin Fenzi wrote: > On Sat, 04 Jul 2009 23:58:52 +0200 > Jeroen van Meeuwen wrote: > >> I wanted to draw your attention to a feature I've proposed for Fedora >> 12, mysteriously called Extended Life Cycle. >> >> You can find more details at >> https://fedoraproject.org/wiki/Features/Extended_Life_Cycle >> >> Kind regards, > > Some general comments: > > - Have you talked with the last folks that attempted this? > > https://www.redhat.com/archives/fedora-advisory-board/2009-February/msg00030.html > http://docs.google.com/Doc?id=dc7dcczk_2fxtsctdq&hl=en > > - The issue I have with this plan (and the others very like it) is that > if you say "we will just do updates for the things we have people > willing to do updates" it means the entire end of life distro is not > covered and the likelyhood of an outstanding security issue is quite > high. There is a chicken and egg issue here where unless there is > enough coverage we shouldn't do it, but we can't find out if there is > enough coverage without doing it. Doing it in such a way that it > fails just gives everyone a bad name and feeling, IMHO. > This "issue" depends on an "if", and is thus invalid. Maybe what you wanted to say/ask is along the lines of: "Are you planning on only providing updates for the packages you have maintainers for?". In that case; The question doesn't make any sense -given that the Feature page does not say "only a selection of packages". To put it in understandable English: We are not going to selectively supply updates for a limited number of packages, it's either all or nothing. > - An indeterminate time is also bad IMHO. How can these corporations > plan if they don't know how much time you are adding here? > 6 months is our initial life cycle extension, as the page says. I feel like everyone missed that. Who am I to set the extended life cycle when various people participate...? I'm not in control! Would the period of time to extend the life cycle with not be the first agenda item at a meeting of peers interested and/or participating? I made one suggestion to start out with, 6 months, put it on the Feature page and no-one reads it. Frankly those 6 months are not set in stone -it's just a proposal for the bunch of people interested and a guideline for others -including those deciding on whether this feature is in or out. Regrettably, some of these people feel like they *are* in control, rather then providing the governance they should. Different subject though. > - Have you considered leveraging the 'critical path' proposal? Try and > up front get enough folks to cover all the critical path packages and > expand from there? > Yes I have. It is not applicable to the scenario I'm after, though in the long term would help the greater Fedora community; including potential users of what could be an extended life cycle. > - How many people are on board with this? Do you have guidelines for > what will be updated or not? what packages? Version updates ok? Or > only security fixes? > This is a lot of questions for one bullet point. I lost you half-way through. What's the actual question here? Reading it on a question-mark per question-mark basis though, I think the feature page answers half of the half-posed questions. Anyway: - a bunch - everything that needs to be updated to ensure prolonged security fixes' availability for any given Fedora release - only security fixes - no guarantee for stable API/ABI - no guarantee for binary compatibility throughout the life cycle > - Are there any Corporations that specifically asked for this? Would > they be willing to provide any resources to the effort? > The demand is there..., the offerings... not so much. Maybe there's a trick to get sponsoring for something that does not and may not exist yet because approval is pending, that I don't know about. Care to share? -- Jeroen From lemenkov at gmail.com Mon Jul 6 18:22:42 2009 From: lemenkov at gmail.com (Peter Lemenkov) Date: Mon, 6 Jul 2009 22:22:42 +0400 Subject: [RFE] Auto-approve watchcommits and watchbugzilla in Pkgdb In-Reply-To: <18203.1246904067@sss.pgh.pa.us> References: <18203.1246904067@sss.pgh.pa.us> Message-ID: 2009/7/6 Tom Lane : > Peter Lemenkov writes: >> Why we should approve manually requests to watching bugzilla and cvs >> changes for packages? I'm sure we need to change policy in order to >> automatically approve all such requests. > > Isn't there a security issue there? ?I'm not sure I want any random > person watching every bz or commit I make. I don't think so - right now anyone can subscribe to the Bugzilla activity of (or , or anyone else) and anyone can watch cvs commits. Adding youself to watchcommits and watchbugzilla is just another one (more convenient for Fedora members) way to monitor bugzilla and commits. -- With best regards! From berrange at redhat.com Mon Jul 6 18:27:28 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 6 Jul 2009 19:27:28 +0100 Subject: [RFE] Auto-approve watchcommits and watchbugzilla in Pkgdb In-Reply-To: <18203.1246904067@sss.pgh.pa.us> References: <18203.1246904067@sss.pgh.pa.us> Message-ID: <20090706182728.GH19478@redhat.com> On Mon, Jul 06, 2009 at 02:14:27PM -0400, Tom Lane wrote: > Peter Lemenkov writes: > > Why we should approve manually requests to watching bugzilla and cvs > > changes for packages? I'm sure we need to change policy in order to > > automatically approve all such requests. > > Isn't there a security issue there? I'm not sure I want any random > person watching every bz or commit I make. Anyone with a BZ account can already watch every BZ you have Preferences -> Email Preferences -> Add users to my watch list pkgdb just makes it more fine grained, so you can watch individual components instead of having to find the owner and watch everything they own NB, the email watches don't allow them to snoop on bugs with restricted group visibility, so they shouldn't be able to see bugs restrict to the 'Security Sensitive Bug' group IIUC. 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 tmz at pobox.com Mon Jul 6 18:28:56 2009 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 6 Jul 2009 14:28:56 -0400 Subject: [RFE] Auto-approve watchcommits and watchbugzilla in Pkgdb In-Reply-To: <18203.1246904067@sss.pgh.pa.us> References: <18203.1246904067@sss.pgh.pa.us> Message-ID: <20090706182856.GY4753@inocybe.localdomain> Tom Lane wrote: > Peter Lemenkov writes: >> Why we should approve manually requests to watching bugzilla and >> cvs changes for packages? I'm sure we need to change policy in >> order to automatically approve all such requests. > > Isn't there a security issue there? I'm not sure I want any random > person watching every bz or commit I make. I _think_ watchbugzilla could have security risks, as anyone with that privilege would see potentially security-sensitive bugs. I'm not sure I see what issue there would be with watchcommits. Anyone random person can watch every commit you make right now, they just have to subscribe to fedora-extras-commits and filter things on your name. Generally, I think more people watching every one else's commits makes for better security. Of course, I could be missing something that watchcommits grants which could be a real security risk. And I'm happy to be enlightened in that case. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ever notice that even the busiest people are never too busy to tell you just how busy they are? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From kanarip at kanarip.com Mon Jul 6 18:41:48 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 06 Jul 2009 20:41:48 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <20090706175643.GB7415@nostromo.devel.redhat.com> References: <4A4FD09C.7000809@kanarip.com> <20090706105734.29c92a78@ohm.scrye.com> <20090706175643.GB7415@nostromo.devel.redhat.com> Message-ID: <5c1717b81c52145a7dd418964be15681@localhost> On Mon, 6 Jul 2009 13:56:43 -0400, Bill Nottingham wrote: > Kevin Fenzi (kevin at scrye.com) said: >> - The issue I have with this plan (and the others very like it) is that >> if you say "we will just do updates for the things we have people >> willing to do updates" it means the entire end of life distro is not >> covered and the likelyhood of an outstanding security issue is quite >> high. There is a chicken and egg issue here where unless there is >> enough coverage we shouldn't do it, but we can't find out if there is >> enough coverage without doing it. Doing it in such a way that it >> fails just gives everyone a bad name and feeling, IMHO. >> >> - An indeterminate time is also bad IMHO. How can these corporations >> plan if they don't know how much time you are adding here? > > These two are my big concerns - doing this badly is worse than not > doing it, IMO. When it comes to user's security, I don't want to give > promises we can't keep, or leave them in a bind. > This has been addressed in another response to the quoted message from Kevin. > Other notes: > > - while F9 updates may be 3+ hours, F11 updates is currently *14-15* hours, > and there aren't as many updates now as there will be; that number > will only go up. (Yay deltarpms!) The support of deltarpms within the extended life cycle is something that can be (re-)considered. > - You don't provide API/ABI guarantees. Which means you're signing up > for more work than you might want if you're pushing updates to > Firefox/xulrunner. (And if you're not providing updates for that for > the desktop, it's not worth starting.) Thanks for the heads-up. > - You state that "the only reason that makes upgrading the distribution a > requirement is the continuous availability of security updates. " > > This implies that you're fine with the feature set of an older distribution > after a while; but you don't want something like RHEL or CentOS. Is it > just the 'RHEL is sort of old in the tooth right now' sort of philosophy? > Because by your metrics, a RHEL released now (or in 3 months, or whatever) > would be fine. > The "or whatever" is sorta funny... (1) The opt-in upgrade every 3 years or every 6 months is a *major* difference. (2) The required upgrade every 7 years or every year is a *major* difference. At point 1 where RHEL is released, it might be fine. At point 2 where Fedora N+1 is released RHEL gets old. You have another 4 (!) Fedora releases (do I hear anyone say ~20 features each?) coming your way to make you appreciate the more rapid release cycle; if only you didn't hate the rapid required upgrade cycle as much... Now, if one could opt-in to upgrade every 6 months for a longer period of time, say 19 months instead of 13 months (leaving 7 or 1 month(s) respectively to upgrade to N+1 or N+2, as said before), then I foresee greater adoption and thus potentially greater participation. > Also, just going back to original first principles: > > http://fedoraproject.org/wiki/Objectives > > "Fedora is not interested in having a slow rate of change, but rather to be > innovative. We do not offer a long-term release cycle because it diverts > attention away from innovation." > > Long term support, in general, goes against the directly objectives of the > project. If it's felt that extending the life cycle a *specific, > measureable > amount* would be of more benefit to the project, that's probably a board > issue, > not a FESCo issue. > I've heard before it does not feel like a Feature. I guess it'll be up to FESCo to decide on whether or not to make a decision on this, or to relay the issue to the Board? -- Jeroen From a.badger at gmail.com Mon Jul 6 18:53:37 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 06 Jul 2009 11:53:37 -0700 Subject: [RFE] Auto-approve watchcommits and watchbugzilla in Pkgdb In-Reply-To: <20090706182856.GY4753@inocybe.localdomain> References: <18203.1246904067@sss.pgh.pa.us> <20090706182856.GY4753@inocybe.localdomain> Message-ID: <4A524831.9060101@gmail.com> On 07/06/2009 11:28 AM, Todd Zullinger wrote: > Tom Lane wrote: >> Peter Lemenkov writes: >>> Why we should approve manually requests to watching bugzilla and >>> cvs changes for packages? I'm sure we need to change policy in >>> order to automatically approve all such requests. >> >> Isn't there a security issue there? I'm not sure I want any random >> person watching every bz or commit I make. > > I _think_ watchbugzilla could have security risks, as anyone with that > privilege would see potentially security-sensitive bugs. > > I'm not sure I see what issue there would be with watchcommits. > Anyone random person can watch every commit you make right now, they > just have to subscribe to fedora-extras-commits and filter things on > your name. Generally, I think more people watching every one else's > commits makes for better security. > > Of course, I could be missing something that watchcommits grants which > could be a real security risk. And I'm happy to be enlightened in > that case. > Nope, autoapproval of watchcommits shouldn't add any problems. I want to make the pkgdb UI less cluttered, though, and give people a choice between signing up to watch everything about a package or nothing by default. Separating only giving autoapproval to one of these but not the other doesn't help much. Is someone in a position to verify whether setting security flags on a bug prevents someone who would be put in the CC list by the default cc attribute would or would not let people see those bugs? Is someone in a position to tell me if watching a person in bugzilla would also let you violate this? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From notting at redhat.com Mon Jul 6 19:19:41 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 6 Jul 2009 15:19:41 -0400 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <5c1717b81c52145a7dd418964be15681@localhost> References: <4A4FD09C.7000809@kanarip.com> <20090706105734.29c92a78@ohm.scrye.com> <20090706175643.GB7415@nostromo.devel.redhat.com> <5c1717b81c52145a7dd418964be15681@localhost> Message-ID: <20090706191941.GA11974@nostromo.devel.redhat.com> Jeroen van Meeuwen (kanarip at kanarip.com) said: > > These two are my big concerns - doing this badly is worse than not > > doing it, IMO. When it comes to user's security, I don't want to give > > promises we can't keep, or leave them in a bind. > > This has been addressed in another response to the quoted message from > Kevin. OK. When you state in the feature page: "Note that the following items may only apply to those that opt-in on ELC support" that implies that it would not apply to every package. Or are you referring to 'users who opt-in to use ELC'? > > Also, just going back to original first principles: > > > > http://fedoraproject.org/wiki/Objectives > > > > "Fedora is not interested in having a slow rate of change, but rather to > be > > innovative. We do not offer a long-term release cycle because it diverts > > attention away from innovation." > > > > Long term support, in general, goes against the directly objectives of > the > > project. If it's felt that extending the life cycle a *specific, > > measureable > > amount* would be of more benefit to the project, that's probably a board > > issue, > > not a FESCo issue. > > > > I've heard before it does not feel like a Feature. I guess it'll be up to > FESCo to decide on whether or not to make a decision on this, or to relay > the issue to the Board? Probably, yes. But this is why I think the specific amount of extension is a good idea to state - it makes the proposal more actionable. Bill From choeger at cs.tu-berlin.de Mon Jul 6 19:58:06 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 06 Jul 2009 21:58:06 +0200 Subject: RFC: cronKit In-Reply-To: <1246903354.5836.17.camel@choeger6> References: <1246899805.5836.15.camel@choeger6> <200907061921.43992.opensource@till.name> <1246903354.5836.17.camel@choeger6> Message-ID: <1246910286.5836.19.camel@choeger6> What I forgot to mention: Obviously it is not enough to know that there is a gnome session running. My programs should inherit the environment. -------------- 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 cdahlin at redhat.com Mon Jul 6 20:02:45 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Mon, 06 Jul 2009 16:02:45 -0400 Subject: RFC: cronKit In-Reply-To: <1246910286.5836.19.camel@choeger6> References: <1246899805.5836.15.camel@choeger6> <200907061921.43992.opensource@till.name> <1246903354.5836.17.camel@choeger6> <1246910286.5836.19.camel@choeger6> Message-ID: <4A525865.3080607@redhat.com> On 07/06/2009 03:58 PM, Christoph H?ger wrote: > What I forgot to mention: Obviously it is not enough to know that there > is a gnome session running. My programs should inherit the environment. > I'll point out that upstart will do all this to some point, but I don't expect you to wait around for us :) --CJD From choeger at cs.tu-berlin.de Mon Jul 6 20:05:18 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 06 Jul 2009 22:05:18 +0200 Subject: RFC: cronKit In-Reply-To: <4A525865.3080607@redhat.com> References: <1246899805.5836.15.camel@choeger6> <200907061921.43992.opensource@till.name> <1246903354.5836.17.camel@choeger6> <1246910286.5836.19.camel@choeger6> <4A525865.3080607@redhat.com> Message-ID: <1246910718.5836.21.camel@choeger6> Am Montag, den 06.07.2009, 16:02 -0400 schrieb Casey Dahlin: > On 07/06/2009 03:58 PM, Christoph H?ger wrote: > > What I forgot to mention: Obviously it is not enough to know that there > > is a gnome session running. My programs should inherit the environment. > > > > I'll point out that upstart will do all this to some point, but I don't expect you to wait around for us :) > > --CJD > Could it handle jobs as gnome child processes? Or would upstart solve that issue differently? -------------- 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 cdahlin at redhat.com Mon Jul 6 20:17:08 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Mon, 06 Jul 2009 16:17:08 -0400 Subject: RFC: cronKit In-Reply-To: <1246910718.5836.21.camel@choeger6> References: <1246899805.5836.15.camel@choeger6> <200907061921.43992.opensource@till.name> <1246903354.5836.17.camel@choeger6> <1246910286.5836.19.camel@choeger6> <4A525865.3080607@redhat.com> <1246910718.5836.21.camel@choeger6> Message-ID: <4A525BC4.9070100@redhat.com> On 07/06/2009 04:05 PM, Christoph H?ger wrote: > Am Montag, den 06.07.2009, 16:02 -0400 schrieb Casey Dahlin: >> On 07/06/2009 03:58 PM, Christoph H?ger wrote: >>> What I forgot to mention: Obviously it is not enough to know that there >>> is a gnome session running. My programs should inherit the environment. >>> >> I'll point out that upstart will do all this to some point, but I don't expect you to wait around for us :) >> >> --CJD >> > > Could it handle jobs as gnome child processes? Or would upstart solve > that issue differently? > Once all the bits are in place Upstart will likely offer a completely different way to manage user sessions. It may offer us the chance to do away with gnome-session altogether, in favor of something more abstract (i.e. an object within upstart tracking session processes, which are all children of init). --CJD From cdahlin at redhat.com Mon Jul 6 20:49:09 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Mon, 06 Jul 2009 16:49:09 -0400 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> <66ff0543780f93d7f263af099cd22e1d@localhost> <20090705101245.GA10184@jasmine.xos.nl> Message-ID: <4A526345.4010902@redhat.com> On 07/05/2009 11:46 AM, Jon Stanley wrote: > On Sun, Jul 5, 2009 at 6:12 AM, Jos Vos wrote: > >> I don't completely agree that "desktops tend to need to run the latest and >> greatest" (when we're talking about business desktops), but desktops > > I don't agree with that position either - note my work laptop, which > unfortunately runs Windows. However, just to make a point, it runs > Windows XP Pro, and Office 2003 - hardly the latest and greatest that > Microsoft has to offer. A RHEL 5 desktop would provide me similarly > aged (or newer) software. > > RHEL/CentOS also gets hardware enablement throughout it's lifecycle, > so the "newer laptops need newer software" only holds true through the > beginning of the Production 2 support phase at minimum, by which time > the next release of RHEL should be available (for RHEL 5, this date is > 3/31/2011) > I think the notion that desktops need newer software is all a side effect of where Linux was when RHEL came out (and may continue to be a side effect of where it is now). Desktop linux is largely new, groundbreaking stuff. It can't be too old before it starts to have limbs missing. "Older" Linux desktop software isn't bad because its old, its bad because its unfinished. --CJD From mrsam at courier-mta.com Mon Jul 6 21:45:38 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Mon, 06 Jul 2009 17:45:38 -0400 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> Message-ID: Kevin Kofler writes: > Sam Varshavchik wrote: >> How exactly would that violate the GPL? > > You aren't patching the actual source code. Oh, no! You mean, the tarball I downloaded from upstream, labeled "source code", did not actually contain the source code? Looks like I've been snookered. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From bill at bfccomputing.com Mon Jul 6 21:44:29 2009 From: bill at bfccomputing.com (Bill McGonigle) Date: Mon, 06 Jul 2009 17:44:29 -0400 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> Message-ID: <4A52703D.3080005@bfccomputing.com> On 07/05/2009 08:03 PM, Kevin Kofler wrote: > They already have 7 months of time to move to the next version. It's just if > they absolutely want to skip a version that they only have 1 month. In the field I've often found that a Fedora at GA+0 isn't really ready to deploy. A bunch of fixes come in quickly, and things are mostly rock-solid by 2 months in, maybe 3. So, one can't really plan to skip versions and remain stable - 1 month is too short. One way to look at this project, then, would be to extend the EOL of the previous version by that period (however it could be rigorously defined). That would enable effective version skipping, thus doubling the effective life of a release. The tools required to make a 2-version skip dependable would be another useful avenue. WRT Legacy, that was done before the Extras merge, right? Did Legacy handle Extras? I don't recall, but if not that could make this incarnation that many times more difficult. -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/ Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: bill at bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf From mrsam at courier-mta.com Mon Jul 6 21:53:37 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Mon, 06 Jul 2009 17:53:37 -0400 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> Message-ID: Adam Jackson writes: > On Sun, 2009-07-05 at 18:50 -0400, Sam Varshavchik wrote: >> Richard W.M. Jones writes: >> > On Sun, Jul 05, 2009 at 10:45:46AM -0400, Sam Varshavchik wrote: >> >> What line number changes? You cut a patch against configure, and you're >> >> done. That's it. >> > >> > And you get a big patch containing line numbers. Here's a single line >> > change to configure.ac, and the corresponding patch that generates: >> ====================== >> >> Who said anything about patching configure.ac? The cited link is not a patch >> to the configure script, it's a result of a patch to configure.ac. >> >> I'll repeat again: patch configure, not configure.ac. >> >> I said "patch configure", and you reply, "well, it won't work because if you >> patch configure.ac, run autoconf, then generate the patch between the >> original configure, and the new configure, I get a big hairball". Duh. > > The fundamental problem with patching configure instead of configure.ac > (or Makefile instead of Makefile.am) is that it's changing the wrong > semantic level. As was discussed previously in this thread, when creating packages the objective is not to patch the correct semantic level. If there's a problem that prevents the source from getting built properly, it's my understanding that the objective is to fix it in the way that absolutely minimizes the chance of accidentally introducing a side effect that creates a new problem that did not exist before. Whatever you would like the upstream to do for the next release, is a separate task. It may or may not be the same thing. So, the choices are, once it's identified where configure goes wrong are: 1) Fix the configure script, with shellcode whose contents are well understood 2) Patch configure.ac, and feed it to a code generator that spits out a brand new configure script. Your turn. Of course, if you take #2, you would, of course, verify which specific version of autoconf the upstream used, and whether the differences between your's and upstream's autoconf does not have any other impacts on the configure script. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From ajax at redhat.com Mon Jul 6 22:06:31 2009 From: ajax at redhat.com (Adam Jackson) Date: Mon, 06 Jul 2009 18:06:31 -0400 Subject: an update to automake-1.11? In-Reply-To: References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> Message-ID: <1246917991.25343.8673.camel@atropine.boston.devel.redhat.com> On Mon, 2009-07-06 at 17:53 -0400, Sam Varshavchik wrote: > So, the choices are, once it's identified where configure goes wrong are: > > 1) Fix the configure script, with shellcode whose contents are well > understood > > 2) Patch configure.ac, and feed it to a code generator that spits out a > brand new configure script. > > Your turn. Of course, if you take #2, you would, of course, verify which > specific version of autoconf the upstream used, and whether the differences > between your's and upstream's autoconf does not have any other impacts on > the configure script. I suppose it depends whether you consider the initial act of package creation, or the continued maintenance of that packaging, to be more time consuming. All I know is that rediffing patches to configure.ac takes way less time than rediffing against configure, and that as a practice that hasn't (non-trivially) bitten me once in over three years, where configure patches have. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon Jul 6 22:07:56 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 06 Jul 2009 15:07:56 -0700 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <4A4FD09C.7000809@kanarip.com> References: <4A4FD09C.7000809@kanarip.com> Message-ID: <1246918076.2965.33.camel@localhost.localdomain> On Sat, 2009-07-04 at 23:58 +0200, Jeroen van Meeuwen wrote: > I wanted to draw your attention to a feature I've proposed for Fedora > 12, mysteriously called Extended Life Cycle. > > You can find more details at > https://fedoraproject.org/wiki/Features/Extended_Life_Cycle When we talked at Berlin some of the details were a bit different, and I'll get to some of what I talked about there later in this email. First off, I think this is different from Fedora Legacy, or has potential to. Legacy had a few very key fail points. 1) it was opt in. Users had to know about it and actively enable it. 2) it was completely done outside of the Fedora infrastructure. 3) Fedora's popularity was very hit and miss, the type of people that would best use a Legacy like service were too burned to give any Red Hat related offering a shot. 4) RHEL4 (and its clones) were new enough for most of the people that would use this service, and thus they went that way. A longer Fedora sounds really great now, particularly because EL 5 and its clones are rather long in the tooth. How good it will sound once EL6 is out is a different matter. I think the popularity will wax and wane as the EL release cycles go. I think for this to succeed as an effort, which there is some folks whom state a need, I think there needs to be a few key things. * Automatic use. Users shouldn't have to opt-in to something different, they should have to do nothing and continue to get the updates. * A clarification of "security" updates. Will local denial of service (aka crash bug) be fixed? Local root escalation? Remote denial of service? Remote escalations? The amount of updates you will have to do will change dramatically based upon what level of security updates you want to target. http://www.redhat.com/security/updates/classification/ may help and may be familiar to the type of users you are targeting. * All or nothing. Either updates for whatever class you clarify from above will be provided for all packages, or none. There can't be any vagueness here. * A way to prevent updates that do not match the above from being pushed. Ambiguity in what can be expected can cause confusion and fear. I realize that we have ambiguity during the normal release cycle and that is maintainer driven, but an extended support effort like this should clarify what will be offered. * A measure of success. Some way that you can decide whether or not the "Feature" has been a success and should be continued, or whether it is a failure and shot not be continued, or should be attempted in some other way * A timeline to go with the above to review for success/failure * A responsible body behind the effort to make regular reports to FESCo/Board Some other interesting problems: Bugzilla spam. If we keep the release open for random bug filing, we have no good way of telling bugzilla that only specific users should get bugs for specific releases of Fedora. Ownership is at a product level, not at the product version level. So maintainers will get all the spam, and have to forward it along to whomever is handling security updates. Who is going to track and discover the security issues? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Mon Jul 6 22:10:00 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 06 Jul 2009 15:10:00 -0700 Subject: an update to automake-1.11? In-Reply-To: References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> Message-ID: <4A527638.1040004@gmail.com> On 07/06/2009 02:53 PM, Sam Varshavchik wrote: > Adam Jackson writes: > >> On Sun, 2009-07-05 at 18:50 -0400, Sam Varshavchik wrote: >>> Richard W.M. Jones writes: >>> > On Sun, Jul 05, 2009 at 10:45:46AM -0400, Sam Varshavchik wrote: >>> >> What line number changes? You cut a patch against configure, and >>> you're >> done. That's it. >>> > > And you get a big patch containing line numbers. Here's a single >>> line >>> > change to configure.ac, and the corresponding patch that generates: >>> ====================== >>> >>> Who said anything about patching configure.ac? The cited link is not >>> a patch to the configure script, it's a result of a patch to >>> configure.ac. >>> >>> I'll repeat again: patch configure, not configure.ac. >>> >>> I said "patch configure", and you reply, "well, it won't work because >>> if you patch configure.ac, run autoconf, then generate the patch >>> between the original configure, and the new configure, I get a big >>> hairball". Duh. >> >> The fundamental problem with patching configure instead of configure.ac >> (or Makefile instead of Makefile.am) is that it's changing the wrong >> semantic level. > > As was discussed previously in this thread, when creating packages the > objective is not to patch the correct semantic level. Actually, in Fedora, it is. We work closely with upstream. If you patch the correct semantic level, you can send the patch back to upstream for incorporation. If you only patch the configure script you aren't helping upstream to improve their code. Also, patching the configure script, while easier fixing the things the majority of times that you've had to fix the build scripts is just anecdotal. My own anecdotes are skewed in the other direction -- I can't recall one time that I've needed to patch the configure.ac script where it would have been easier to patch the configure script directly instead. Introducing side-effects is something to watch out for but patching configure instead of the true source is a short term fix, not a long term solution. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From kevin.kofler at chello.at Mon Jul 6 22:18:51 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 07 Jul 2009 00:18:51 +0200 Subject: Feature proposal: Extended Life Cycle Support References: <4A4FD09C.7000809@kanarip.com> <364d303b0907051413q4cc36c70r7173e5cdd2b66e1f@mail.gmail.com> <99e6529575712252b1bd8ff6e14376f3@localhost> <20090706160304.GF19829@hansolo.jdub.homelinux.org> Message-ID: Josh Boyer wrote: > Fedora Legacy (the original one) failed. It failed because of excess bureaucracy (they didn't even trust Bugzilla's authentication, requiring GPG signing of all Bugzilla comments with impact on the procedures, and QA requirements were also unrealistic given the manpower). > The last time something like this was proposed, it generated a few > meetings and some discussion here and on f-a-b. I have yet to see > anything actually come of that. Patrice Dumas's proposal failed because he wasn't provided with the required infrastructure (and he was unable to come up with it himself, which I can't blame him for). > Without a concrete group of people large enough to make this wory saying > that they are signing up to do that work, I don't have high hopes for this > succeeding in the long run. We'd just need some minimal infrastructure effort, one person willing to do the pushes (like you're doing for the supported releases) and everything else would be "as is", if somebody wants something fixed, they'll have to push the fix, if nobody cares, it won't be fixed. It isn't supported after all. And no QA, if it breaks, you get to keep the pieces. Again, it's unsupported, that means what it means. I still think it's better than not getting any security fixes at all. Kevin Kofler From mw_triad at users.sourceforge.net Mon Jul 6 22:29:39 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Mon, 06 Jul 2009 17:29:39 -0500 Subject: an update to automake-1.11? In-Reply-To: <4A4B82D3.1050407@freenet.de> References: <1246385157.8362.127.camel@localhost.localdomain> <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <4A4B82D3.1050407@freenet.de> Message-ID: Ralf Corsepius wrote: > Kevin Kofler wrote: >> Ralf Corsepius wrote: >>> a) it will cause some moderate stir-up to those packages whose upstreams >>> are still abusing the autotools. >> >> s/ab// ;-) >> >> Why can't we just move to a better build system with higher focus on >> backwards compatibility? > > Because > a) the autotools are not as bad as you in your want to make them appear. Sorry, but any build system where you can't patch the build system without risking the sky falling *is* that bad. Why is it that to build a cmake-based project, it is a given that I run cmake, but to build an autotools-based project, I am expected to fear and dread and avoid-at-all-costs running autotools? Do you /really/, honestly not see anything wrong with that? As Conrad noted, "[the] phobia of regenerating an auto-generated script just goes to show how completely broken autotools is." -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- It is training and experience that gives us the ability to abstract problems, remain objective, use previous knowledge, interact with users, and herd cats. -- Celeste Lyn Paul, on Usability Experts From a.badger at gmail.com Mon Jul 6 22:29:08 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 06 Jul 2009 15:29:08 -0700 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <1246918076.2965.33.camel@localhost.localdomain> References: <4A4FD09C.7000809@kanarip.com> <1246918076.2965.33.camel@localhost.localdomain> Message-ID: <4A527AB4.7020505@gmail.com> On 07/06/2009 03:07 PM, Jesse Keating wrote: > Bugzilla spam. If we keep the release open for random bug filing, we > have no good way of telling bugzilla that only specific users should get > bugs for specific releases of Fedora. Ownership is at a product level, > not at the product version level. So maintainers will get all the spam, > and have to forward it along to whomever is handling security updates. > This one could be solved by having a separate component in bugzilla like "Fedora Legacy", however that does move into a space that is visible to end users. Bug triage could probably move bugs from normal Fedora to "Fedora Legacy" if people were reporting against the correct version but incorrect product. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From kevin.kofler at chello.at Mon Jul 6 22:34:46 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 07 Jul 2009 00:34:46 +0200 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> Message-ID: Sam Varshavchik wrote: > Oh, no! You mean, the tarball I downloaded from upstream, labeled "source > code", did not actually contain the source code? It contains both the actual source code and some unreadable generated gibberish which is NOT source code and which is being passed off as such (which is why the autotools are broken by design: it's a mistake to encourage shipping generated files in a source tarball). Kevin Kofler From kevin at scrye.com Mon Jul 6 22:37:37 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 6 Jul 2009 16:37:37 -0600 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: References: <4A4FD09C.7000809@kanarip.com> <364d303b0907051413q4cc36c70r7173e5cdd2b66e1f@mail.gmail.com> <99e6529575712252b1bd8ff6e14376f3@localhost> <20090706160304.GF19829@hansolo.jdub.homelinux.org> Message-ID: <20090706163737.1b5a932d@ohm.scrye.com> On Tue, 07 Jul 2009 00:18:51 +0200 Kevin Kofler wrote: > Josh Boyer wrote: > > Fedora Legacy (the original one) failed. > > It failed because of excess bureaucracy (they didn't even trust > Bugzilla's authentication, requiring GPG signing of all Bugzilla > comments with impact on the procedures, and QA requirements were also > unrealistic given the manpower). > > > The last time something like this was proposed, it generated a few > > meetings and some discussion here and on f-a-b. I have yet to see > > anything actually come of that. > > Patrice Dumas's proposal failed because he wasn't provided with the > required infrastructure (and he was unable to come up with it > himself, which I can't blame him for). That was the time before last. The last one was in Feb by Scott Williams. I guess it just quietly faded out. > > Without a concrete group of people large enough to make this wory > > saying that they are signing up to do that work, I don't have high > > hopes for this succeeding in the long run. > > We'd just need some minimal infrastructure effort, one person willing > to do the pushes (like you're doing for the supported releases) and > everything else would be "as is", if somebody wants something fixed, > they'll have to push the fix, if nobody cares, it won't be fixed. It > isn't supported after all. And no QA, if it breaks, you get to keep > the pieces. Again, it's unsupported, that means what it means. I > still think it's better than not getting any security fixes at all. I think it is worse. It causes people to have an expectation that something will get security updates, and when it doesn't happen and they get compromised, they will not be very happy. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mrsam at courier-mta.com Mon Jul 6 22:46:13 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Mon, 06 Jul 2009 18:46:13 -0400 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <1246917991.25343.8673.camel@atropine.boston.devel.redhat.com> Message-ID: Adam Jackson writes: > On Mon, 2009-07-06 at 17:53 -0400, Sam Varshavchik wrote: > >> So, the choices are, once it's identified where configure goes wrong are: >> >> 1) Fix the configure script, with shellcode whose contents are well >> understood >> >> 2) Patch configure.ac, and feed it to a code generator that spits out a >> brand new configure script. >> >> Your turn. Of course, if you take #2, you would, of course, verify which >> specific version of autoconf the upstream used, and whether the differences >> between your's and upstream's autoconf does not have any other impacts on >> the configure script. > > I suppose it depends whether you consider the initial act of package > creation, or the continued maintenance of that packaging, to be more > time consuming. All I know is that rediffing patches to configure.ac > takes way less time than rediffing against configure, and that as a Gee, I didn't know that rediffing is a mandatory step. Here I was, just fixing configure by opening it in emacs, adding one or two lines, or changing a variable setting, saving it the diffing the results against the original configure file, producing a tiny patch. And I was doing it wrong way all along? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mrsam at courier-mta.com Mon Jul 6 22:50:50 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Mon, 06 Jul 2009 18:50:50 -0400 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <4A527638.1040004@gmail.com> Message-ID: Toshio Kuratomi writes: > On 07/06/2009 02:53 PM, Sam Varshavchik wrote: >> As was discussed previously in this thread, when creating packages the >> objective is not to patch the correct semantic level. > > Actually, in Fedora, it is. We work closely with upstream. If you > patch the correct semantic level, you can send the patch back to > upstream for incorporation. If you only patch the configure script you > aren't helping upstream to improve their code. Right. And what exactly is difficult about still sending the ultimate patch upstream, but using a minimalist patch to configure, for the actual package, for the interim? I guess it all comes down to what's easier: vetting the impact of your minimalist changes to configure, versus vetting a freshly minted configure script for any unintended side effects from regenerating it using a -- very likely -- different version of autoconf than the upstream used originally. I know which one I'll choose. But, if some feel that vetting the entire configure script, whatever floats their boat. Although, I suspect, that 99% of the time everyone ignores it, hoping that the new configure script works as before, sans the patch. Basically cross your fingers, ignore it, and hope that nothing ends up broken. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From braden at endoframe.com Mon Jul 6 22:57:04 2009 From: braden at endoframe.com (Braden McDaniel) Date: Mon, 06 Jul 2009 18:57:04 -0400 Subject: an update to automake-1.11? In-Reply-To: <4A527638.1040004@gmail.com> References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <4A527638.1040004@gmail.com> Message-ID: <4A528140.2070100@endoframe.com> On 7/6/09 6:10 PM, Toshio Kuratomi wrote: [snip] > Introducing side-effects is something to watch out for but > patching configure instead of the true source is a short term fix, not a > long term solution. *Any* patch should be viewed as a short-term fix. A patch that needs to persist indefinitely suggests broken maintainership somewhere along the line--either upstream, of the Fedora package in question, or elsewhere in Fedora's infrastructure. -- Braden McDaniel e-mail: Jabber: From mrsam at courier-mta.com Mon Jul 6 23:00:09 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Mon, 06 Jul 2009 19:00:09 -0400 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> Message-ID: Kevin Kofler writes: > Sam Varshavchik wrote: >> Oh, no! You mean, the tarball I downloaded from upstream, labeled "source >> code", did not actually contain the source code? > > It contains both the actual source code and some unreadable generated > gibberish which is NOT source code and which is being passed off as such Just because you can't read it, it's not gibberish. Besides, Merriam-Webster defines "source code" as: http://www.merriam-webster.com/dictionary/source%20code "a computer program in its original programming language (as FORTRAN or C) before translation into object code usually by a compiler" You learn something new about configure scripts every day. I didn't know that gets translated into object code, before execution. > (which is why the autotools are broken by design: it's a mistake to > encourage shipping generated files in a source tarball). Oh, ok. Good luck with your quest to change the mind of everyone who uses autoconf, to do it your way. Perhaps you'd like to show everyone how it should be done. Pick just one moderately popular package, convince them to let you own release management, then start releasing tarballs without a configure script. Let us know how it works out, but kindly give advance warning. I want to stock up on earplugs. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mw_triad at users.sourceforge.net Mon Jul 6 23:03:20 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Mon, 06 Jul 2009 18:03:20 -0500 Subject: rawhide report: 20090702 changes In-Reply-To: <1246558225.25852.208.camel@vaio.local.net> References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <20090702164310.GA30611@nostromo.devel.redhat.com> <1246558225.25852.208.camel@vaio.local.net> Message-ID: Adam Williamson wrote: > On Thu, 2009-07-02 at 12:43 -0400, Bill Nottingham wrote: >> I'm not sure how distributable the KJV is or isnt' > > It's been out of copyright for some little time, now. Probably.(*) > > * Of course, one could potentially make some quite interesting legal > arguments about the author credit, and whether said author counts as > 'living' within the terms of copyright laws that grant copyright during > the lifetime of the author... I think it's safe to assume that the Author grants permission to redistribute ;-). (In fact, I'm pretty sure I could make an argument that that's explicitly granted...) Permission to modify, on the other hand... (To be clear, I'm just trying to amuse folks, not argue that KJV should be included in Fedora. At the least, I /would/ argue that we'd have to allow other religious texts if we allow any, but I generally agree it's better not to start down that slope.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- It is training and experience that gives us the ability to abstract problems, remain objective, use previous knowledge, interact with users, and herd cats. -- Celeste Lyn Paul, on Usability Experts From kevin at scrye.com Mon Jul 6 23:06:25 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 6 Jul 2009 17:06:25 -0600 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <6e3ba5f24be85ab5aa79d152acc96095@localhost> References: <4A4FD09C.7000809@kanarip.com> <20090706105734.29c92a78@ohm.scrye.com> <6e3ba5f24be85ab5aa79d152acc96095@localhost> Message-ID: <20090706170625.4d562f75@ohm.scrye.com> On Mon, 06 Jul 2009 20:20:50 +0200 Jeroen van Meeuwen wrote: > > On Mon, 6 Jul 2009 10:57:34 -0600, Kevin Fenzi > wrote: ...snip... > > - The issue I have with this plan (and the others very like it) is > > that if you say "we will just do updates for the things we have > > people willing to do updates" it means the entire end of life > > distro is not covered and the likelyhood of an outstanding security > > issue is quite high. There is a chicken and egg issue here where > > unless there is enough coverage we shouldn't do it, but we can't > > find out if there is enough coverage without doing it. Doing it in > > such a way that it fails just gives everyone a bad name and > > feeling, IMHO. > > > > This "issue" depends on an "if", and is thus invalid. Maybe what you > wanted to say/ask is along the lines of: > > "Are you planning on only providing updates for the packages you have > maintainers for?". In that case; > > The question doesn't make any sense -given that the Feature page does > not say "only a selection of packages". To put it in understandable > English: We are not going to selectively supply updates for a limited > number of packages, it's either all or nothing. Great. I did read the page and didn't get that impression... The "Note that the following items may only apply to those that opt-in on ELC support" confused me perhaps? > 6 months is our initial life cycle extension, as the page says. > > I feel like everyone missed that. ok. I guess I missed it too. > Who am I to set the extended life cycle when various people > participate...? I'm not in control! Would the period of time to > extend the life cycle with not be the first agenda item at a meeting > of peers interested and/or participating? I made one suggestion to > start out with, 6 months, put it on the Feature page and no-one reads > it. Frankly those 6 months are not set in stone -it's just a proposal > for the bunch of people interested and a guideline for others > -including those deciding on whether this feature is in or out. > Regrettably, some of these people feel like they *are* in control, > rather then providing the governance they should. Different subject > though. ok. How about having a meeting and deciding that before trying to get the proposal off the ground? > > - How many people are on board with this? Do you have guidelines for > > what will be updated or not? what packages? Version updates ok? Or > > only security fixes? > > This is a lot of questions for one bullet point. I lost you half-way > through. What's the actual question here? Sorry, Should have split it out. > Reading it on a question-mark per question-mark basis though, I think > the feature page answers half of the half-posed questions. Anyway: > > - a bunch fas names? Approximate number? When this comes up there is always "A bunch of people" who want this, but they never seem to want to sign up to do the work. Do you have such people ready to go to work? > - everything that needs to be updated to ensure prolonged security > fixes' availability for any given Fedora release > - only security fixes > - no guarantee for stable API/ABI > - no guarantee for binary compatibility throughout the life cycle great. > > - Are there any Corporations that specifically asked for this? Would > > they be willing to provide any resources to the effort? > > The demand is there..., the offerings... not so much. Maybe there's a > trick to get sponsoring for something that does not and may not exist > yet because approval is pending, that I don't know about. Care to > share? Well, I would say gather your group, show that there is an active group of people ready to work on this and you will have a lot less skepticism. I personally look at the last time this came up. As far as I know the group had 1 meeting, nothing ever happened. I fear you are going to have to show some great setup and activity before people are going to take this seriously. :( kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mw_triad at users.sourceforge.net Mon Jul 6 23:05:43 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Mon, 06 Jul 2009 18:05:43 -0500 Subject: rawhide report: 20090702 changes In-Reply-To: References: <20090702113221.GA15858@releng2.fedora.phx.redhat.com> <4A4CAAE4.4090404@fedoraproject.org> <20090702164310.GA30611@nostromo.devel.redhat.com> Message-ID: Matej Cepl wrote: > Well, I always understood, that documentation which is part of normal > package is OK, but source package which contains nothing else than > documentation isn't. But then yes we have man-pages. Hmm. man-pages appears to be misnamed glibc-doc (well, okay, glibc + kernel). If we start drafting guidelines that would exclude /that/, then we have a problem ;-). I'm on the fence w.r.t. "third-party" books on using Fedora components (e.g. DIP). Beyond that I tend to agree with "don't ship content" except to the extent it is shipped by upstream (e.g. shipping the "official" KDE wallpapers is fine, but unofficial wallpapers should not be shipped). (And before anyone asks, obviously "Fedora Official" content, e.g. solar-backgrounds is okay also.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- It is training and experience that gives us the ability to abstract problems, remain objective, use previous knowledge, interact with users, and herd cats. -- Celeste Lyn Paul, on Usability Experts From oget.fedora at gmail.com Mon Jul 6 23:13:50 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Mon, 6 Jul 2009 19:13:50 -0400 Subject: an update to automake-1.11? In-Reply-To: References: <20090630213457.GC22149@redhat.com> <20090705213045.GB22871@amd.home.annexia.org> Message-ID: Wow! 78 messages and still, no one gave solid examples of what might go wrong unnoticed if one uses autotools in a specfile. "Using autotools in a specfile is bad" started to sound like an urban legend to me. I'll keep reading. Orcan From jonstanley at gmail.com Wed Jul 1 17:04:47 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Wed, 1 Jul 2009 13:04:47 -0400 Subject: Fwd: Last call for F9 updates In-Reply-To: <20090630222443.GB2279@hansolo.jdub.homelinux.org> References: <20090630222443.GB2279@hansolo.jdub.homelinux.org> Message-ID: Please see below from our fabulous releng team! ---------- Forwarded message ---------- From: Josh Boyer Date: Tue, Jun 30, 2009 at 6:24 PM Subject: Last call for F9 updates To: fedora-devel-list at redhat.com F9 will be EOL'd very very soon. ?This is probably the last call for updates to F9. I wouldn't bother with updates-testing, as the time required to properly get those pushed out and have feedback from them is longer than the EOL date. ?That does not mean to push untested stuff straight to stable. josh -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From awilliam at redhat.com Thu Jul 2 19:17:34 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 02 Jul 2009 20:17:34 +0100 Subject: Use of Priority and Severity fields in Bugzilla Message-ID: <1246562254.25852.233.camel@vaio.local.net> Hi, folks. We in the QA and BugZappers groups have been working for a while on a proposal to use the severity and priority fields in Bugzilla. With the help of various groups, and after considerable feedback both within our groups and from the development group, we're ready to put this into place now. To briefly explain the system, the priority field will be reserved by policy for developers only. You can use it to organize bugs into the order you'd like to tackle them. Or, you can not. It's entirely up to you. The policy makes maintainers the sole 'owners' of this field; no-one else is supposed to touch it, and there are no rules or guidelines for how it should be used, it's entirely up to developers' discretion. Significantly, Bugzilla is now configured so that only members of the 'fedorabugs' FAS group can touch this field, so there is less chance that - if you decide to actually use it - disgruntled users / reporters will mess with your settings. The severity field is reserved by policy to the Bugzappers team and developers. Again, it's been restricted in Bugzilla now so that only members of 'fedorabugs' can touch it. The policy is that triagers will set this field initially as part of triage, but developers have the final say, and if a developer decides to change the setting chosen by a triager, the triager is to accept that decision and not change it back. The guidelines for how the various settings should be used are here: https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#Priority_and_Severity The severity setting will be used in future as part of the QA and BugZapper processes - for instance, we're planning to do a weekly review of 'urgent' severity bugs, and will also review these during blocker bug review meetings. This policy and the changes to Bugzilla configuration are all in line with proposals made during the last few weeks, and sent for feedback to -devel-list a few weeks back. No opposition has been received to the proposal in this form. Having said that, if you have a big problem with this policy, please do let us know and we'll try to accommodate your concerns. Thanks very much, and please do contact me directly or test-list (or anyone else in QA or BugZappers) with any questions relating to this. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net _______________________________________________ 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 Fri Jul 3 21:19:49 2009 From: poelstra at redhat.com (John Poelstra) Date: Fri, 03 Jul 2009 14:19:49 -0700 Subject: logistics list Message-ID: <4A4E75F5.7030402@redhat.com> The logistics at lists.fedoraproject.org mailing list has been created to meet the requirements discussed here: http://www.redhat.com/archives/fedora-advisory-board/2009-July/msg00000.html Anyone is welcome to join the list at: https://admin.fedoraproject.org/mailman/listinfo/logistics and participants are strongly encouraged to use it only for important topics that need to be coordinated across teams. I have also take the liberty to sign up leads from each the teams that attended the Fedora 11 Release Readiness meetings (assuming they will be the same for Fedora 12) as well as the people who have expressed an interest in helping with or learning more about the Fedora Zikula CMS implementation. Feel free to adjust things by adding or removing yourself. 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 Sun Jul 5 23:29:24 2009 From: poelstra at redhat.com (John Poelstra) Date: Sun, 05 Jul 2009 16:29:24 -0700 Subject: Requesting Feature Page Status Updates by July 14, 2009 Message-ID: <4A513754.5040907@redhat.com> One thing we overlooked by dropping the Alpha Release (as we knew it in Fedora 11 and before) is the built-in feature check at Alpha freeze. As a result we need all feature owners to update their feature pages with current completion information by July 14, 2009. I'll be forwarding a list of stale feature pages (hopefully there won't be any) to FESCo for their review on July 17, 2009. This checkpoint is important to know if currently accepted features are on track for a successful Fedora 12 landing or if contingency plans need to be considered at Feature Freeze as we prepare for the Alpha release. Tracking important development dates has never been easier! iCal: http://poelstra.fedorapeople.org/schedules/f-12/f-12-devel.ics (Import to Zimbra, Google Calendar, etc.) Boring html: http://poelstra.fedorapeople.org/schedules/f-12/f-12-devel-tasks.html Thanks for your help, John _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From kevin at scrye.com Mon Jul 6 00:21:20 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Sun, 5 Jul 2009 18:21:20 -0600 Subject: Test Machine Resources for Package Maintainers Message-ID: <20090705182120.250891a0@ohm.scrye.com> Greetings. I have setup some machines/virtual instances here to assist maintainers that might not have access to all versions/arches Fedora runs on. Please see: https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers For more information on the instances, how to use them and common questions and answers. Feel free to email me with any outstanding questions you might have about the instances, and I hope they are useful. 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 mrsam at courier-mta.com Mon Jul 6 23:22:20 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Mon, 06 Jul 2009 19:22:20 -0400 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <20090705213045.GB22871@amd.home.annexia.org> Message-ID: Orcan Ogetbil writes: > Wow! 78 messages and still, no one gave solid examples of what might > go wrong unnoticed if one uses autotools in a specfile. I already did, several times. You just ignored it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From braden at endoframe.com Mon Jul 6 23:24:42 2009 From: braden at endoframe.com (Braden McDaniel) Date: Mon, 06 Jul 2009 19:24:42 -0400 Subject: an update to automake-1.11? In-Reply-To: References: <1246385157.8362.127.camel@localhost.localdomain> <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <4A4B82D3.1050407@freenet.de> Message-ID: <4A5287BA.3000504@endoframe.com> On 7/6/09 6:29 PM, Matthew Woehlke wrote: > Ralf Corsepius wrote: >> Kevin Kofler wrote: >>> Ralf Corsepius wrote: >>>> a) it will cause some moderate stir-up to those packages whose >>>> upstreams >>>> are still abusing the autotools. >>> >>> s/ab// ;-) >>> >>> Why can't we just move to a better build system with higher focus on >>> backwards compatibility? >> >> Because >> a) the autotools are not as bad as you in your want to make them appear. > > Sorry, but any build system where you can't patch the build system > without risking the sky falling *is* that bad. > > Why is it that to build a cmake-based project, it is a given that I run > cmake, but to build an autotools-based project, I am expected to fear > and dread and avoid-at-all-costs running autotools? Do you /really/, > honestly not see anything wrong with that? > > As Conrad noted, "[the] phobia of regenerating an auto-generated script > just goes to show how completely broken autotools is." The problem is not the sky falling, which is quite unlikely. The problem is that when you regenerate configure and Makefile.in, you are changing files that are part of the upstream deliverable. And you're doing so in a less-than-surgical way that may have unintended consequences. The situation is similar to regenerating documentation (that was already included in the upstream distribution). Unless you are certain that you are using the same versions of tools used by upstream, it is awfully hard to be confident that your doc generation toolchain is bugwards-compatible with upstream's. You probably won't get any error messages--but you cannot be confident that the output has been rendered as upstream intended without some very careful inspection of the output. The difference between regenerating the build system and regenerating documentation is that the former is irrelevant once you've successfully built the package. If you get to that point, the way you got there should have no impact on end users. The number of people chiming in on this thread to the effect, "I've regenerated configure/Makefile.in for years and I've never had a problem," is testament to the fact that backward compatibility of autotools releases has gotten a lot better in recent years. The autotools are hardly unique in experiencing such growing pains during maturation. Where they do differ from a tool like cmake is that they insulate packages against future changes to the autotools themselves by avoiding any requirement that they (the autotools) be invoked when building the package. However, it is quite a bit more difficult to insulate against package maintainers determined to defeat such measures. Regenerating the build system is the antithesis of providing surgical patches to solve a problem. More often than not in package maintenance, "nuke 'em from orbit" is *not* the *only* way to be sure. -- Braden McDaniel e-mail: Jabber: From oget.fedora at gmail.com Mon Jul 6 23:27:03 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Mon, 6 Jul 2009 19:27:03 -0400 Subject: an update to automake-1.11? In-Reply-To: References: <20090630213457.GC22149@redhat.com> Message-ID: On Mon, Jul 6, 2009 at 7:22 PM, Sam Varshavchik wrote: > Orcan Ogetbil writes: > >> Wow! 78 messages and still, no one gave solid examples of what might >> go wrong unnoticed if one uses autotools in a specfile. > > I already did, several times. You just ignored it. > Would you kindly give quotes or links to these examples? I read all your messages for the 5th time and I still can't find your examples. Many thanks! Orcan From a.badger at gmail.com Mon Jul 6 23:36:37 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 06 Jul 2009 16:36:37 -0700 Subject: an update to automake-1.11? In-Reply-To: <4A528140.2070100@endoframe.com> References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <4A527638.1040004@gmail.com> <4A528140.2070100@endoframe.com> Message-ID: <4A528A85.3010704@gmail.com> On 07/06/2009 03:57 PM, Braden McDaniel wrote: > On 7/6/09 6:10 PM, Toshio Kuratomi wrote: > > [snip] > >> Introducing side-effects is something to watch out for but >> patching configure instead of the true source is a short term fix, not a >> long term solution. > > *Any* patch should be viewed as a short-term fix. A patch that needs to > persist indefinitely suggests broken maintainership somewhere along the > line--either upstream, of the Fedora package in question, or elsewhere > in Fedora's infrastructure. > But one of those patches is upstreamable and the other is not. The upstreamable patch is a step on the road to the long term fix. The non-upstreamable one is a dead-end. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From kevin.kofler at chello.at Tue Jul 7 00:02:24 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 07 Jul 2009 02:02:24 +0200 Subject: an update to automake-1.11? References: <1246385157.8362.127.camel@localhost.localdomain> <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <4A4B82D3.1050407@freenet.de> <4A5287BA.3000504@endoframe.com> Message-ID: Braden McDaniel wrote: > The number of people chiming in on this thread to the effect, "I've > regenerated configure/Makefile.in for years and I've never had a > problem," is testament to the fact that backward compatibility of > autotools releases has gotten a lot better in recent years. The > autotools are hardly unique in experiencing such growing pains during > maturation. Then how come CMake manages to provide near-100% backwards compatibility? Of course, no software is perfect, but CMake's design is to be completely bug- for-bug (*) compatible with the original version the project used (see also the CMake policy system), whereas the autotools are doing incompatible changes in a way which require the sources to be changed. (*) of course only where the bugfix actually causes compatibility issues! Otherwise they just fix it. > Where they do differ from a tool like cmake is that they insulate packages > against future changes to the autotools themselves by avoiding any > requirement that they (the autotools) be invoked when building the > package. And that's bad because there's no plan B: incompatible changes are made (even fairly recently, see libtool 2.1) without providing backwards source compatibility, relying entirely on tarballs shipping generated files for backwards compatibility. This is unhelpful because it doesn't help the developer (upstream developer, packager etc.) who needs to edit the actual source code (and this is the reason why we're having this discussion in the first place), it doesn't help for things like snapshot checkouts from repositories which don't carry generated files (but only generate them for release tarballs, a fairly common practice) and of course it doesn't help if upstream doesn't ship generated files at all (though the autotools discourage that). I think it would be much better to ensure rerunning autoreconf will always just work, then upstreams wouldn't have to ship autogenerated files as "source code". But of course that'd turn a lot of the autotools' core design decisions (e.g. the idea of generating shell scripts in the first place) into accidents of history. So I'm sorry (and I know you'll probably never be convinced), but I don't think the autotools can be fixed and still be the autotools, the whole concept is flawed. What I see is tarballs getting littered with generated files which are 1. unnecessary, as they can just be regenerated and 2. contain generated snippets which get old quickly. If I fix a bug in CMake, it'll automatically fix the issue for all subsequent builds of CMake-using software (unless my fix is incompatible and I have to introduce a "policy" for it, then they need to opt in to the fix). If I fix a bug in the autotools, some software may never pick it up, and the one that will may take years to pick it up! How is that an advantage? Kevin Kofler From kevin.kofler at chello.at Tue Jul 7 00:17:50 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 07 Jul 2009 02:17:50 +0200 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> Message-ID: Sam Varshavchik wrote: > Just because you can't read it, it's not gibberish. It's not that *I* can't read it, it's that it is just plain hard to read, especially because it contains workarounds for bazillions of broken proprietary *nix shells (trying to use Bourne-style shell code as a portable language is a major design failure of its own, there are tons of subtly different dialects and megatons of plain bugs). Try reading that 1.1 MB (!) shell script: http://svn.calcforge.org/viewvc/emu- tigcc/trunk/configure?revision=2861&root=emu-tigcc It's generated from a 9.7 KB configure.ac: http://svn.calcforge.org/viewvc/emu- tigcc/trunk/configure.ac?revision=2847&root=emu-tigcc It uses the stock KDE 3 acinclude.m4 and stock macros fetched by aclocal, no special magic. Needless to say, getting that project off the autotools is a high-priority item for me? > Besides, Merriam-Webster defines "source code" as: > > http://www.merriam-webster.com/dictionary/source%20code > > "a computer program in its original programming language (as FORTRAN or C) The original programming language is the configure.ac language. > before translation into object code usually by a compiler" And the object code is the shell code. > You learn something new about configure scripts every day. I didn't know > that gets translated into object code, before execution. They get translated into shell code which is interpreted by the shell (which is used as a kind of VM). But the shell code is clearly NOT the ORIGINAL programming language, it's generated. > Oh, ok. Good luck with your quest to change the mind of everyone who uses > autoconf, to do it your way. Actually they should just stop using autoconf because it is not designed for doing things right. And in fact KDE did just that (they moved to CMake and nobody at KDE is missing the autotools, quite the opposite!) and several other projects followed suit. Kevin Kofler From kevin.kofler at chello.at Tue Jul 7 00:18:42 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 07 Jul 2009 02:18:42 +0200 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <1246917991.25343.8673.camel@atropine.boston.devel.redhat.com> Message-ID: Sam Varshavchik wrote: > Gee, I didn't know that rediffing is a mandatory step. It is when your patch no longer applies after you upgraded the package to a new upstream version. Kevin Kofler From kevin.kofler at chello.at Tue Jul 7 00:23:37 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 07 Jul 2009 02:23:37 +0200 Subject: Requesting Feature Page Status Updates by July 14, 2009 References: <4A513754.5040907__11365.4729015709$1246922254$gmane$org@redhat.com> Message-ID: John Poelstra wrote: > This checkpoint is important to know if currently accepted features are > on track for a successful Fedora 12 landing or if contingency plans need > to be considered at Feature Freeze as we prepare for the Alpha release. ? for the what? ;-) Kevin Kofler From jkeating at redhat.com Tue Jul 7 00:28:42 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 06 Jul 2009 17:28:42 -0700 Subject: Requesting Feature Page Status Updates by July 14, 2009 In-Reply-To: References: <4A513754.5040907__11365.4729015709$1246922254$gmane$org@redhat.com> Message-ID: <1246926522.6216.5.camel@localhost.localdomain> On Tue, 2009-07-07 at 02:23 +0200, Kevin Kofler wrote: > John Poelstra wrote: > > This checkpoint is important to know if currently accepted features are > > on track for a successful Fedora 12 landing or if contingency plans need > > to be considered at Feature Freeze as we prepare for the Alpha release. > > ? for the what? ;-) > > Kevin Kofler > > Per https://fedoraproject.org/wiki/Milestone_Adjustment_Proposal what used to be called "Beta" is now called "Alpha". This matches industry nomenclature for what we were actually producing. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jwboyer at gmail.com Tue Jul 7 00:30:20 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 6 Jul 2009 20:30:20 -0400 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: References: <4A4FD09C.7000809@kanarip.com> <364d303b0907051413q4cc36c70r7173e5cdd2b66e1f@mail.gmail.com> <99e6529575712252b1bd8ff6e14376f3@localhost> <20090706160304.GF19829@hansolo.jdub.homelinux.org> Message-ID: <20090707003020.GJ19829@hansolo.jdub.homelinux.org> On Tue, Jul 07, 2009 at 12:18:51AM +0200, Kevin Kofler wrote: >Josh Boyer wrote: >> Without a concrete group of people large enough to make this wory saying >> that they are signing up to do that work, I don't have high hopes for this >> succeeding in the long run. > >We'd just need some minimal infrastructure effort, one person willing to do >the pushes (like you're doing for the supported releases) and everything >else would be "as is", if somebody wants something fixed, they'll have to >push the fix, if nobody cares, it won't be fixed. It isn't supported after >all. And no QA, if it breaks, you get to keep the pieces. Again, it's >unsupported, that means what it means. I still think it's better than not >getting any security fixes at all. Is there a reason any of that can't be done as a secondary arch-like effort? I've already pointed out why it's painful to keep EOL releases around. You didn't really address those, and you seemed to have grouped them into "minimal infrastructure effort". I didn't touch on package signing earlier, but that is another potential hurdle. Let me put is this way: None of the items I have listed are show-stoppers or insurmountable. However, unless someone comes forward with _concrete_ proposals on how to approach them and actual _people_ willing to work on it, they won't change. I don't think that is an undue burden to having this approved by a governing committee, whether it be FESCo or the Board. It's as simple as that. I think Jeroen understands that, and he seems to really want constructive criticism on the proposal. So I'll be happy to wait and see what comes of this. josh From kevin.kofler at chello.at Tue Jul 7 00:42:28 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 07 Jul 2009 02:42:28 +0200 Subject: Requesting Feature Page Status Updates by July 14, 2009 References: <4A513754.5040907__11365.4729015709$1246922254$gmane$org@redhat.com> <1246926522.6216.5.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > Per https://fedoraproject.org/wiki/Milestone_Adjustment_Proposal what > used to be called "Beta" is now called "Alpha". This matches industry > nomenclature for what we were actually producing. Uh, I kinda recalled that the feedback on the mailing list for this renaming proposal has been overwhelmingly negative, but maybe that was just me getting a wrong impression? Personally, I don't care strongly about the naming anyway, be it "beta", "alpha", "test1" or whatever. :-) Kevin Kofler From mrsam at courier-mta.com Tue Jul 7 01:13:48 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Mon, 06 Jul 2009 21:13:48 -0400 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> Message-ID: Orcan Ogetbil writes: > On Mon, Jul 6, 2009 at 7:22 PM, Sam Varshavchik wrote: >> Orcan Ogetbil writes: >> >>> Wow! 78 messages and still, no one gave solid examples of what might >>> go wrong unnoticed if one uses autotools in a specfile. >> >> I already did, several times. You just ignored it. >> > > Would you kindly give quotes or links to these examples? I read all > your messages for the 5th time and I still can't find your examples. # Message-ID: # I guess it all comes down to what's easier: vetting the impact of your # minimalist changes to configure, versus vetting a freshly minted configure # script for any unintended side effects from regenerating it using a -- # very likely -- different version of autoconf than the upstream used # originally. I specifically cited the potential danger from rebuilding configure that came out of a different version of autoconf than what the upstream used -- and I explicitly stated this three or four times. It just fits into your blind spot so nicely -- because you are firmly convinced that there is never any downside, you completely ignore everytime someone brings up an obvious one. Tell me what -- every time you choose to rebuild an upstream's configure -- do you always notice which specific version of autoconf the upstream used originally? Well, unless you always do so, it's very easy for something to go "unnoticed" by you. Thank you for playing. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From kanarip at kanarip.com Tue Jul 7 01:22:38 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 07 Jul 2009 03:22:38 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <20090706191941.GA11974@nostromo.devel.redhat.com> References: <4A4FD09C.7000809@kanarip.com> <20090706105734.29c92a78@ohm.scrye.com> <20090706175643.GB7415@nostromo.devel.redhat.com> <5c1717b81c52145a7dd418964be15681@localhost> <20090706191941.GA11974@nostromo.devel.redhat.com> Message-ID: <4A52A35E.8090409@kanarip.com> On 07/06/2009 09:19 PM, Bill Nottingham wrote: > Jeroen van Meeuwen (kanarip at kanarip.com) said: >>> These two are my big concerns - doing this badly is worse than not >>> doing it, IMO. When it comes to user's security, I don't want to give >>> promises we can't keep, or leave them in a bind. >> This has been addressed in another response to the quoted message from >> Kevin. > > OK. When you state in the feature page: > > "Note that the following items may only apply to those that opt-in on ELC > support" > > that implies that it would not apply to every package. Or are you referring > to 'users who opt-in to use ELC'? > Between packages and maintainers, only maintainers are in a position to opt-in. >>> Also, just going back to original first principles: >>> >>> http://fedoraproject.org/wiki/Objectives >>> >>> "Fedora is not interested in having a slow rate of change, but rather to >> be >>> innovative. We do not offer a long-term release cycle because it diverts >>> attention away from innovation." >>> >>> Long term support, in general, goes against the directly objectives of >> the >>> project. If it's felt that extending the life cycle a *specific, >>> measureable >>> amount* would be of more benefit to the project, that's probably a board >>> issue, >>> not a FESCo issue. >>> >> I've heard before it does not feel like a Feature. I guess it'll be up to >> FESCo to decide on whether or not to make a decision on this, or to relay >> the issue to the Board? > > Probably, yes. But this is why I think the specific amount of extension > is a good idea to state - it makes the proposal more actionable. > And it is proposed, it's just not everywhere in the text: https://fedoraproject.org/wiki/Features/Extended_Life_Cycle#Notes -- Jeroen From mrsam at courier-mta.com Tue Jul 7 01:24:39 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Mon, 06 Jul 2009 21:24:39 -0400 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> Message-ID: Kevin Kofler writes: > Sam Varshavchik wrote: >> Just because you can't read it, it's not gibberish. > > It's not that *I* can't read it, it's that it is just plain hard to read, > especially because it contains workarounds for bazillions of broken > proprietary *nix shells (trying to use Bourne-style shell code as a portable > language is a major design failure of its own, there are tons of subtly > different dialects and megatons of plain bugs). > > Try reading that 1.1 MB (!) shell script: > http://svn.calcforge.org/viewvc/emu- > tigcc/trunk/configure?revision=2861&root=emu-tigcc > > It's generated from a 9.7 KB configure.ac: > http://svn.calcforge.org/viewvc/emu- > tigcc/trunk/configure.ac?revision=2847&root=emu-tigcc Sure, why not. It just so happens that, not too long ago, I was in an analogous position where I had some other package that also built against zlib, for $dayjob$. At $dayjob$ we also package free software using a scripted reproducible build. Not RPMs, but an analogous process, and at $dayjob$, for reasons that are irrelevant, zlib was installed into a nonstandard location. The fix for that, and the analogous fix here, were that to be the case, was to stick CPPFLAGS="-I $CPPFLAGS" right after the following line in configure, grep for it: # Check for zlib I'm of course, skipping over some other details (similar thing needs to be done with LDFLAGS). So, you see -- it's not really complicated. Not at all. And, this is a typical reason why one might need to fix up the configure script. In at least 99%+ of the time Perhaps if it's necessary to do major surgery on some package's configure script, for some reason -- if wholesale changes are required -- one might have an argument for patching configure.ac (or configure.in, for us old-timers), and rebuilding configure. But for 99% of the actual use case situations out there, it's like driving in a 1" nail with a sledgehammer. Too much risk for collateral damage. > And in fact KDE did just that (they moved to CMake and nobody at KDE is > missing the autotools, quite the opposite!) and several other projects > followed suit. Yes, well, that might be one of the reasons why KDE is sweeping over the Linux desktop, and Gnome is just a fading memory for most. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mrsam at courier-mta.com Tue Jul 7 01:25:39 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Mon, 06 Jul 2009 21:25:39 -0400 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <1246917991.25343.8673.camel@atropine.boston.devel.redhat.com> Message-ID: Kevin Kofler writes: > Sam Varshavchik wrote: >> Gee, I didn't know that rediffing is a mandatory step. > > It is when your patch no longer applies after you upgraded the package to a > new upstream version. Which, as I pointed out, is still the case if you were to patch configure.ac instead. But, go ahead and ignore this inconvenient fact, too. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From oget.fedora at gmail.com Tue Jul 7 01:48:37 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Mon, 6 Jul 2009 21:48:37 -0400 Subject: an update to automake-1.11? In-Reply-To: References: <20090630213457.GC22149@redhat.com> Message-ID: On Mon, Jul 6, 2009 at 9:13 PM, Sam Varshavchik wrote: > Orcan Ogetbil writes: > >> On Mon, Jul 6, 2009 at 7:22 PM, Sam Varshavchik wrote: >>> >>> Orcan Ogetbil writes: >>> >>>> Wow! 78 messages and still, no one gave solid examples of what might >>>> go wrong unnoticed if one uses autotools in a specfile. >>> >>> I already did, several times. You just ignored it. >>> >> >> Would you kindly give quotes or links to these examples? I read all >> your messages for the 5th time and I still can't find your examples. > > # Message-ID: > > # I guess it all comes down to what's easier: vetting the impact of your # > minimalist changes to configure, versus vetting a freshly minted configure # > script for any unintended side effects from regenerating it using a -- # > very likely -- different version of autoconf than the upstream used # > originally. > > I specifically cited the potential danger from rebuilding configure that > came out of a different version of autoconf than what the upstream used -- > and I explicitly stated this three or four times. > Yes you did say that it is dangerous a few times. But you never said what the consequences would be, what the dangers actually are. The only one closest example was given by Mark McLoughlin: > I used to avoid re-running autotools in rpm builds because I worried > that a future autotools update would subtly screw up the build - e.g. > disabling a previously enabled feature in the built package. but this will hardly go unnoticed. > It just fits into your blind spot so nicely -- because you are firmly > convinced that there is never any downside, you completely ignore everytime > someone brings up an obvious one. > Hold on there. I am not ignoring. I am curiously reading because, as I said, I'm willing to learn. I am completely neutral about this issue. You don't need to fight me :) Just show me some evidence so I'll get convinced into your side. > Tell me what -- every time you choose to rebuild an upstream's configure -- > do you always notice which specific version of autoconf the upstream used > originally? Well, unless you always do so, it's very easy for something to > go "unnoticed" by you. > What is this "something"? I am begging you to give me one (1) example. I am not sarcastic at all. I am very sincere in this statement. No, I don't really check what version of autotools upstream used. But I look at the build logs and check the resulting binary. If everything looks reasonable I send it to updates-testing. I keep it there for about 2 weeks (sometimes longer but most usually not shorter). If there are no complaints I then push it to stable. So, let us start from the beginning: Let's say I modify configure.ac and use automake/autoconf during building my package. The package builds and seems to work "fine". In what step can I miss "something"? What will this "something" be? Please stop the fight and help me. I need help. Thanks, Orcan From peter at thecodergeek.com Tue Jul 7 01:55:51 2009 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 06 Jul 2009 18:55:51 -0700 Subject: [OT] Re: an update to automake-1.11? In-Reply-To: References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> Message-ID: <1246931751.3034.5.camel@tuxhugs> On Mon, 2009-07-06 at 21:24 -0400, Sam Varshavchik wrote: > Yes, well, that might be one of the reasons why KDE is sweeping over the > Linux desktop, and Gnome is just a fading memory for most. Please don't claim such obviously fallacious things. Like it or not, GNOME has been - and continues to be - the default desktop environment on a great many major GNU/Linux distributions (including Fedora). -- Peter Gordon (codergeek42) Who am I? :: http://thecodergeek.com/about-me -------------- next part -------------- A 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 mrsam at courier-mta.com Tue Jul 7 02:06:56 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Mon, 06 Jul 2009 22:06:56 -0400 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246931751.3034.5.camel@tuxhugs> Message-ID: Peter Gordon writes: > On Mon, 2009-07-06 at 21:24 -0400, Sam Varshavchik wrote: >> Yes, well, that might be one of the reasons why KDE is sweeping over the >> Linux desktop, and Gnome is just a fading memory for most. > > Please don't claim such obviously fallacious things. Like it or not, > GNOME has been - and continues to be - the default desktop environment > on a great many major GNU/Linux distributions (including Fedora). Yes -- I plead guilty. I often forget to put explicit tags in the right places. Perhaps you might want to reread my entire message. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mrsam at courier-mta.com Tue Jul 7 02:29:13 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Mon, 06 Jul 2009 22:29:13 -0400 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> Message-ID: Orcan Ogetbil writes: > On Mon, Jul 6, 2009 at 9:13 PM, Sam Varshavchik wrote: >> I specifically cited the potential danger from rebuilding configure that >> came out of a different version of autoconf than what the upstream used -- >> and I explicitly stated this three or four times. >> > > Yes you did say that it is dangerous a few times. But you never said > what the consequences would be, what the dangers actually are. I see. You want me to explain the possible consequences of a broken build? > Hold on there. I am not ignoring. I am curiously reading because, as I > said, I'm willing to learn. > > I am completely neutral about this issue. You don't need to fight me > :) Just show me some evidence so I'll get convinced into your side. There is no universal consequence of a broken build, and there is no tell tale symptom to watch for. One example from memory occured about four years ago. Someone else, at $dayjob$, was trying to bootstrap the entire toolchain, including gcc. On multiple platforms. Everything seemed to build, and work. Yet, when it was time to build other applications, gcc on x86_64 was barfing every time it tried to compile a 64 bit shared library. Only on x86_64. An error was coming out of the linker. Just a typical undecipherable ld error message, that seems to be written in English words, but in a language other than English. Anyway, to make a long story short, I ended up running some sample code through both the native (red hat) gcc compiler, and the bootstrapped compiler, producing .s assembly files. Of course, I know x86_64 machine language as much as I know Latin, but there were differences. By staring at what ended up in the .s files, and some Googling, I eventually traced it down to an obscure breakage in one of the configure scripts. It was frobbing the version of ld, and, based on the results, making some decision as to what features to enable or disable. The breakage was that it was picking up the wrong ld (the native one, rather than the one being bootstrapped). This is just one example of the results of a broken configure script. Everything would seem to build, apparently, but with the wrong options for the given platform, and you wouldn't realize that something was broken until a lot of other people already wasted a lot of time. > What is this "something"? I am begging you to give me one (1) example. > I am not sarcastic at all. I am very sincere in this statement. All you really have to observe is that configure does not run with the -e flag set, so if something in the massive shell script fails with a non-zero exit code, the rest of the configure script continues to plod along, with just a diagnostic message on stderr, which is easily lost amidst all the other noisy output produced by configure. > No, I don't really check what version of autotools upstream used. But > I look at the build logs and check the resulting binary. If Unfortunately, it's not that easy. You may not very well realize that, on your platform, the result of some specific "checking for foo" should be "yes", instead of "no" (or the other way around), but breakage introduced by a rebuild by a different version of autoconf flipped that setting. > So, let us start from the beginning: Let's say I modify configure.ac > and use automake/autoconf during building my package. The package > builds and seems to work "fine". In what step can I miss "something"? You want me to give you a universal answer how to detect a problem caused by breakage due to a rebuild by a different version of autoconf? As if this can only fail in one specific way, no matter what the break is. You believe that a single, specific, light bulb goes on, when configure produces wrong results, no matter what those wrong results are. Riiiiight. > What will this "something" be? Could be anything. There is no single error message that is a tell-tale indication that it's broke. And the chances of happening that as a result of making a targeted patch to configure, with well defined consequences, are orders of magnitude less than patching configure.ac, and then generating a brand. new. script. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mclasen at redhat.com Tue Jul 7 02:53:33 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 06 Jul 2009 22:53:33 -0400 Subject: Display configuration test day tomorrow Message-ID: <1246935213.1600.14.camel@planemask> Just a reminder that we are kicking off our 'fit and finish' initiative with a test day on display configuration tomorrow, in #fedora-fit-and-finish. If you go to http://www.fedoraproject.org/wiki/Test_Day:2009-07-07_Fit_and_Finish:Display_Configuration you'll find more information. We will also have (slightly oversize) live cds available. Please come and join us tomorrow, Matthias From braden at endoframe.com Tue Jul 7 03:09:51 2009 From: braden at endoframe.com (Braden McDaniel) Date: Mon, 06 Jul 2009 23:09:51 -0400 Subject: an update to automake-1.11? In-Reply-To: <4A528A85.3010704@gmail.com> References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <4A527638.1040004@gmail.com> <4A528140.2070100@endoframe.com> <4A528A85.3010704@gmail.com> Message-ID: <1246936191.1347.2466.camel@localhost> On Mon, 2009-07-06 at 16:36 -0700, Toshio Kuratomi wrote: > On 07/06/2009 03:57 PM, Braden McDaniel wrote: > > On 7/6/09 6:10 PM, Toshio Kuratomi wrote: > > > > [snip] > > > >> Introducing side-effects is something to watch out for but > >> patching configure instead of the true source is a short term fix, not a > >> long term solution. > > > > *Any* patch should be viewed as a short-term fix. A patch that needs to > > persist indefinitely suggests broken maintainership somewhere along the > > line--either upstream, of the Fedora package in question, or elsewhere > > in Fedora's infrastructure. > > > But one of those patches is upstreamable and the other is not. > The upstreamable patch is a step on the road to the long term fix. The > non-upstreamable one is a dead-end. Creating a patch to configure/Makefile.in in no way precludes a package maintainer from sending an analogous patch to configure.ac/Makefile.am upstream. So, yes, it's a "dead end" that: 1. reduces the size of the changeset between the upstream package and the one Fedora actually builds and 2. improves the resiliency of the package build to changes to Fedora's autotools chain. -- Braden McDaniel From braden at endoframe.com Tue Jul 7 03:27:28 2009 From: braden at endoframe.com (Braden McDaniel) Date: Mon, 06 Jul 2009 23:27:28 -0400 Subject: an update to automake-1.11? In-Reply-To: References: <1246385157.8362.127.camel@localhost.localdomain> <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <4A4B82D3.1050407@freenet.de> <4A5287BA.3000504@endoframe.com> Message-ID: <1246937248.1347.2514.camel@localhost> On Tue, 2009-07-07 at 02:02 +0200, Kevin Kofler wrote: > Braden McDaniel wrote: > > The number of people chiming in on this thread to the effect, "I've > > regenerated configure/Makefile.in for years and I've never had a > > problem," is testament to the fact that backward compatibility of > > autotools releases has gotten a lot better in recent years. The > > autotools are hardly unique in experiencing such growing pains during > > maturation. > > Then how come CMake manages to provide near-100% backwards compatibility? Of > course, no software is perfect, but CMake's design is to be completely bug- > for-bug (*) compatible with the original version the project used (see also > the CMake policy system), whereas the autotools are doing incompatible > changes in a way which require the sources to be changed. > > (*) of course only where the bugfix actually causes compatibility issues! > Otherwise they just fix it. Breaking compatibility with previous versions of automake, autoconf, or libtool has no impact on released tarballs made using those tools; they continue to work as intended because they do not depend on the presence of these tools. As such, I imagine the autotools maintainers do not feel so great an obligation to backward compatibility as the CMake maintainers might. > > Where they do differ from a tool like cmake is that they insulate packages > > against future changes to the autotools themselves by avoiding any > > requirement that they (the autotools) be invoked when building the > > package. > > And that's bad because there's no plan B: incompatible changes are made > (even fairly recently, see libtool 2.1) without providing backwards source > compatibility, relying entirely on tarballs shipping generated files for > backwards compatibility. That is the use case for the tools. As with most software, little to no support is provided for those who misuse it. This is not especially surprising. > This is unhelpful because it doesn't help the > developer (upstream developer, packager etc.) who needs to edit the actual > source code (and this is the reason why we're having this discussion in the > first place), it doesn't help for things like snapshot checkouts from > repositories which don't carry generated files (but only generate them for > release tarballs, a fairly common practice) and of course it doesn't help if > upstream doesn't ship generated files at all (though the autotools > discourage that). Nor is it any hindrance in these endeavors. The autotools are well known not to make tea, either. And astoundingly, I know of no plans to correct this. -- Braden McDaniel From pbrobinson at gmail.com Tue Jul 7 06:26:34 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 7 Jul 2009 07:26:34 +0100 Subject: issues with the koji repo? Message-ID: <5256d0b0907062326g4477f39ajc1d3d9360e9ede4@mail.gmail.com> Hi All, Is there currently an issue with the koji repo process? A pair of rawhide chain builds that I ran last night failed and when I tried them again this morning the previous package still wasn't in the repo to build against. Similarly a F-11 build override that was tagged 10 or so hours ago is still not available. Peter From markmc at redhat.com Tue Jul 7 08:05:29 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 07 Jul 2009 09:05:29 +0100 Subject: an update to automake-1.11? In-Reply-To: References: <20090630213457.GC22149@redhat.com> Message-ID: <1246953929.2836.26.camel@blaa> On Mon, 2009-07-06 at 21:13 -0400, Sam Varshavchik wrote: > It just fits into your blind spot so nicely -- because you are firmly > convinced that there is never any downside, you completely ignore everytime > someone brings up an obvious one. Have a look at http://live.gnome.org/CodeOfConduct e.g. "assume people mean well" - IMHO, Orcan is just looking for specific examples of things breaking in the past because he genuinely wants to understand the issue. And there hasn't been specific examples on this thread yet. > Tell me what -- every time you choose to rebuild an upstream's configure -- > do you always notice which specific version of autoconf the upstream used > originally? Well, unless you always do so, it's very easy for something to > go "unnoticed" by you. A counter point is how many upstream maintainers look at what version of autoconf they're building tarballs with? My guess is that these days very, very few do and it's not causing problems - perhaps autoconf isn't so broken anymore? (Bear in mind, I used to advocate what you're advocating, but it's looking like the situation has changed) Cheers, Mark. From mtasaka at ioa.s.u-tokyo.ac.jp Tue Jul 7 08:17:26 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 07 Jul 2009 17:17:26 +0900 Subject: issues with the koji repo? In-Reply-To: <5256d0b0907062326g4477f39ajc1d3d9360e9ede4@mail.gmail.com> References: <5256d0b0907062326g4477f39ajc1d3d9360e9ede4@mail.gmail.com> Message-ID: <4A530496.4080004@ioa.s.u-tokyo.ac.jp> Peter Robinson wrote, at 07/07/2009 03:26 PM +9:00: > Hi All, > > Is there currently an issue with the koji repo process? A pair of > rawhide chain builds that I ran last night failed and when I tried > them again this morning the previous package still wasn't in the repo > to build against. Similarly a F-11 build override that was tagged 10 > or so hours ago is still not available. > For F-12. the newrepo task http://koji.fedoraproject.org/koji/taskinfo?taskID=1457708 is hanging for more than 11 hours (I don't know why). For F-11, the last new repo task was http://koji.fedoraproject.org/koji/taskinfo?taskID=1457163 , which was 15 hours ago. Would someone restart koji's new repo tasks? Regards, Mamoru From a.badger at gmail.com Tue Jul 7 08:17:51 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 07 Jul 2009 01:17:51 -0700 Subject: an update to automake-1.11? In-Reply-To: <1246936191.1347.2466.camel@localhost> References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <4A527638.1040004@gmail.com> <4A528140.2070100@endoframe.com> <4A528A85.3010704@gmail.com> <1246936191.1347.2466.camel@localhost> Message-ID: <4A5304AF.3020905@gmail.com> On 07/06/2009 08:09 PM, Braden McDaniel wrote: > On Mon, 2009-07-06 at 16:36 -0700, Toshio Kuratomi wrote: >> On 07/06/2009 03:57 PM, Braden McDaniel wrote: >>> On 7/6/09 6:10 PM, Toshio Kuratomi wrote: >>> >>> [snip] >>> >>>> Introducing side-effects is something to watch out for but >>>> patching configure instead of the true source is a short term fix, not a >>>> long term solution. >>> >>> *Any* patch should be viewed as a short-term fix. A patch that needs to >>> persist indefinitely suggests broken maintainership somewhere along the >>> line--either upstream, of the Fedora package in question, or elsewhere >>> in Fedora's infrastructure. >>> >> But one of those patches is upstreamable and the other is not. >> The upstreamable patch is a step on the road to the long term fix. The >> non-upstreamable one is a dead-end. > > Creating a patch to configure/Makefile.in in no way precludes a package > maintainer from sending an analogous patch to configure.ac/Makefile.am > upstream. So, yes, it's a "dead end" that: > > 1. reduces the size of the changeset between the upstream package > and the one Fedora actually builds and > 2. improves the resiliency of the package build to changes to > Fedora's autotools chain. > Perhaps but it doesn't decrease the work that the maintainer has to do. The package maintainer needs to patch configure.ac so they have something upstreamable. Then they need to test that their changes make the changes they think and don't break things via unintended side-effects. If they notice discrepancies, they have to find out what is going on (whether it's a version difference in automake or a bug introduced by their patch) and fix it. Then they can submit that upstream. At that point, the reasons for creating a separate, even just a few lines different code that directly changes configure is extraneous work. Do all maintainers do this kind of work when they make a patch for configure.ac? Perhaps not but they are doing their duties better if they do. Do all maintainers make upstreamable patches when they directly fix a configure script? I think the answer is the same. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From drago01 at gmail.com Tue Jul 7 08:24:24 2009 From: drago01 at gmail.com (drago01) Date: Tue, 7 Jul 2009 10:24:24 +0200 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: <4A486F85.7000109@gmail.com> References: <4A486F85.7000109@gmail.com> Message-ID: On Mon, Jun 29, 2009 at 9:38 AM, Frank Murphy wrote: > Is there any contingency plans in place, > for a worst case scenario if C#, is lost? > FesCo? > Legal? > > Is there any searchable parameter, > to work out what something is coded in\depending on (code wise) > > > This is not the normal "**** mono" post. > I hope, I worded it enough, that my concern is: > Fedora and *All* our Users > (http://fedoraproject.org/wiki/Overview#What_is_Fedora.3F) http://port25.technet.com/archive/2009/07/06/the-ecma-c-and-cli-standards.aspx From frankly3d at gmail.com Tue Jul 7 08:28:02 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Tue, 07 Jul 2009 09:28:02 +0100 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: References: <4A486F85.7000109@gmail.com> Message-ID: <4A530712.3030003@gmail.com> On 07/07/09 09:24, drago01 wrote: > On Mon, Jun 29, 2009 at 9:38 AM, Frank Murphy wrote: >> Is there any contingency plans in place, >> for a worst case scenario if C#, is lost? >> FesCo? >> Legal? >> >> Is there any searchable parameter, >> to work out what something is coded in\depending on (code wise) >> >> >> This is not the normal "**** mono" post. >> I hope, I worded it enough, that my concern is: >> Fedora and *All* our Users >> (http://fedoraproject.org/wiki/Overview#What_is_Fedora.3F) > > http://port25.technet.com/archive/2009/07/06/the-ecma-c-and-cli-standards.aspx > If legal are happy with this, it should be ok. Regards, Frank From rms at 1407.org Tue Jul 7 08:56:53 2009 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Tue, 7 Jul 2009 09:56:53 +0100 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: References: <4A486F85.7000109@gmail.com> Message-ID: <20090707085653.GB5189@roque.1407.org> On Tue, Jul 07, 2009 at 10:24:24AM +0200, drago01 wrote: > On Mon, Jun 29, 2009 at 9:38 AM, Frank Murphy wrote: > > Is there any contingency plans in place, > > for a worst case scenario if C#, is lost? > > FesCo? > > Legal? > > > > Is there any searchable parameter, > > to work out what something is coded in\depending on (code wise) > > > > > > This is not the normal "**** mono" post. > > I hope, I worded it enough, that my concern is: > > Fedora and *All* our Users > > (http://fedoraproject.org/wiki/Overview#What_is_Fedora.3F) > > http://port25.technet.com/archive/2009/07/06/the-ecma-c-and-cli-standards.aspx Oh poo, and what's the difference? None. None whatsoever but more marketing. You can't distribute GPL'ed software unless you have the right to do it. The promise makes quite sure to tell you you have no right[1], but you can infringe that they won't sue *you*[2]. [1] => means you can't do it with GPL [2] => means you can't do it with GPL3 If you want to do it with GPL'ed software, you need to obtain a RAND or RAND-Z patent license. Who ever got it, could s/he please publish it? Microsoft promised to give it to a company that asked for it in Portugal, and they never fulfilled (even after insistence). I know of several other people who have asked for it and never got it. You need to stop believing in Santa. Rui From lemenkov at gmail.com Tue Jul 7 09:02:22 2009 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 7 Jul 2009 13:02:22 +0400 Subject: How to add custom rpm-defines to rpmbuild while building in Koji? Message-ID: Hello All! In order to build cross-toolchain I need to pass additional --define "binutils_target " to rpmbuild command-line. See this spec, for example: http://cvs.fedoraproject.org/viewvc/rpms/spu-binutils/devel/spu-binutils.spec?revision=1.10&view=markup How can I do it? -- With best regards! From drago01 at gmail.com Tue Jul 7 09:07:52 2009 From: drago01 at gmail.com (drago01) Date: Tue, 7 Jul 2009 11:07:52 +0200 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: <20090707085653.GB5189@roque.1407.org> References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> Message-ID: On Tue, Jul 7, 2009 at 10:56 AM, Rui Miguel Silva Seabra wrote: > On Tue, Jul 07, 2009 at 10:24:24AM +0200, drago01 wrote: >> On Mon, Jun 29, 2009 at 9:38 AM, Frank Murphy wrote: >> > Is there any contingency plans in place, >> > for a worst case scenario if C#, is lost? >> > FesCo? >> > Legal? >> > >> > Is there any searchable parameter, >> > to work out what something is coded in\depending on (code wise) >> > >> > >> > This is not the normal "**** mono" post. >> > I hope, I worded it enough, that my concern is: >> > Fedora and *All* our Users >> > (http://fedoraproject.org/wiki/Overview#What_is_Fedora.3F) >> >> http://port25.technet.com/archive/2009/07/06/the-ecma-c-and-cli-standards.aspx > > Oh poo, and what's the difference? None. None whatsoever but more marketing. > > You can't distribute GPL'ed software unless you have the right to do it. So? > The promise makes quite sure to tell you you have no right[1], but you can > infringe that they won't sue *you*[2]. > > [1] => means you can't do it with GPL It explicitly grant this right. > [2] => means you can't do it with GPL3 > > If you want to do it with GPL'ed software, you need to obtain a RAND or RAND-Z > patent license. Who ever got it, could s/he please publish it? > > Microsoft promised to give it to a company that asked for it in Portugal, and > they never fulfilled (even after insistence). > > I know of several other people who have asked for it and never got it. > > You need to stop believing in Santa. We already had the OIN protection and this is additional safety. But I am not a lawyer so I leave the judgment to them. From erik at vanpienbroek.nl Tue Jul 7 09:20:35 2009 From: erik at vanpienbroek.nl (Erik van Pienbroek) Date: Tue, 07 Jul 2009 11:20:35 +0200 Subject: How to add custom rpm-defines to rpmbuild while building in Koji? In-Reply-To: References: Message-ID: <1246958435.2864.6.camel@alguno-laptop.terneuzen.openftd.org> Op dinsdag 07-07-2009 om 13:02 uur [tijdzone +0400], schreef Peter Lemenkov: > Hello All! > In order to build cross-toolchain I need to pass additional --define > "binutils_target " to rpmbuild command-line. See > this spec, for example: > > http://cvs.fedoraproject.org/viewvc/rpms/spu-binutils/devel/spu-binutils.spec?revision=1.10&view=markup > > How can I do it? Hi, In the .spec file you referred to the binutils_target is already set (first line: %define binutils_target spu). If you need to build this package for another target you need to change it here. AFAIK it isn't possible to inject custom rpmbuild arguments in Koji. Regards, Erik van Pienbroek From lemenkov at gmail.com Tue Jul 7 09:25:11 2009 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 7 Jul 2009 13:25:11 +0400 Subject: How to add custom rpm-defines to rpmbuild while building in Koji? In-Reply-To: <1246958435.2864.6.camel@alguno-laptop.terneuzen.openftd.org> References: <1246958435.2864.6.camel@alguno-laptop.terneuzen.openftd.org> Message-ID: 2009/7/7 Erik van Pienbroek : > Op dinsdag 07-07-2009 om 13:02 uur [tijdzone +0400], schreef Peter > Lemenkov: >> Hello All! >> In order to build cross-toolchain I need to pass additional --define >> "binutils_target " to rpmbuild command-line. See >> this spec, for example: >> >> http://cvs.fedoraproject.org/viewvc/rpms/spu-binutils/devel/spu-binutils.spec?revision=1.10&view=markup >> >> How can I do it? > > Hi, > > In the .spec file you referred to the binutils_target is already set > (first line: %define binutils_target spu). Oh, I didn't noticed it. -- With best regards! From mschwendt at gmail.com Tue Jul 7 09:45:32 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 7 Jul 2009 11:45:32 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: References: <4A4FD09C.7000809@kanarip.com> <364d303b0907051413q4cc36c70r7173e5cdd2b66e1f@mail.gmail.com> <99e6529575712252b1bd8ff6e14376f3@localhost> <20090706160304.GF19829@hansolo.jdub.homelinux.org> Message-ID: <20090707114532.1804edc5@noname.noname> On Tue, 07 Jul 2009 00:18:51 +0200, Kevin wrote: > Josh Boyer wrote: > > Fedora Legacy (the original one) failed. > > It failed because of excess bureaucracy (they didn't even trust Bugzilla's > authentication, requiring GPG signing of all Bugzilla comments with impact > on the procedures, and QA requirements were also unrealistic given the > manpower). The manpower bottleneck affected it in two different areas. From the beginning on, the leadership failed to meet the requirements of the tiny base of people who actually prepared updates. The limited infrastructure made the manpower bottleneck worse, because only a very few people were permitted to rpmbuild/mach official update packages. Not enough people to cover all packages, which suffered from vulnerabilities. Not enough people to become a Fedora Legacy package "owner" or "maintainer", who would also watch bugzilla for example. Not enough people with interest in those packages, not even in testing updates. It quickly became evident that a growing number of packages would remain vulnerable (or otherwise broken by a critical bug), because nobody wanted to take care of them. No inheritance of fedora.us' web of trust either. Even somebody, who copied and verified a patch from RHEL, couldn't move forward, because no second person acknowledged the pending updates in bugzilla. The old QA checklist was very short compared with Fedora's current guidelines -- still it had its enemies, especially those who would rather botch up a src.rpm and dump it into some /incoming place where others would need to pick it up and turn it into an official Fedora Legacy update. No quick leadership decisions to alter the policies and procedures. From rjones at redhat.com Tue Jul 7 09:56:26 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 7 Jul 2009 10:56:26 +0100 Subject: an update to automake-1.11? In-Reply-To: <1246936191.1347.2466.camel@localhost> References: <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <4A527638.1040004@gmail.com> <4A528140.2070100@endoframe.com> <4A528A85.3010704@gmail.com> <1246936191.1347.2466.camel@localhost> Message-ID: <20090707095626.GA30095@amd.home.annexia.org> On Mon, Jul 06, 2009 at 11:09:51PM -0400, Braden McDaniel wrote: > 2. improves the resiliency of the package build to changes to > Fedora's autotools chain. Many projects come with public source repositories, and those don't include the binary configure/Makefile.in files. You usually build those locally with a script like 'autogen.sh'. Projects that depend on precise versions of the autotools are just going to break under those conditions. libguestfs is a case in point - the Debian maintainer builds it from git using some unknown version of autoconf, and I build it on RHEL and Fedora using other versions of autoconf. If there was a bug reported to me that configure.ac didn't work on (eg.) Debian's autoconf, I'd consider it a bug in the project itself, and I wouldn't tell the Debian maintainer to install a specific autoconf. It's better in the long term to fix the configure.ac so that it can work with any version of autotools. If it requires some specific version or a narrow range of versions, I'd consider it broken. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 75 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From rms at 1407.org Tue Jul 7 10:02:39 2009 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Tue, 7 Jul 2009 11:02:39 +0100 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> Message-ID: <20090707100239.GC5189@roque.1407.org> On Tue, Jul 07, 2009 at 11:07:52AM +0200, drago01 wrote: > > The promise makes quite sure to tell you you have no right[1], but you can > > infringe that they won't sue *you*[2]. > > > > [1] => means you can't do it with GPL > > It explicitly grant this right. What you're explicitly told s that you won't be sued if you do so without the right. And you have no right! Further down (in the FAQ, outside the promise) you're told you need to get a RAND or RAND-Z license to have the rights. Who ever got these, could s/he please publish them? No one I know who has asked ever got it from Microsoft, even under promises. > > [2] => means you can't do it with GPL3 > > > > If you want to do it with GPL'ed software, you need to obtain a RAND or RAND-Z > > patent license. Who ever got it, could s/he please publish it? > > > > Microsoft promised to give it to a company that asked for it in Portugal, and > > they never fulfilled (even after insistence). > > > > I know of several other people who have asked for it and never got it. > > > > You need to stop believing in Santa. > > We already had the OIN protection and this is additional safety. You seem to fail to grasp the concept that without weapons there's no war. You think that by having weapons you're defended? That's rich... it only means you can probably fight back (depending on the infringement), not that you win or are defended. > But I am not a lawyer so I leave the judgment to them. You don't need a lawyer to distinguish between a) having a right or b) not being sued if you infringe Rui From dodji at redhat.com Tue Jul 7 10:15:28 2009 From: dodji at redhat.com (Dodji Seketeli) Date: Tue, 07 Jul 2009 12:15:28 +0200 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: <20090707100239.GC5189@roque.1407.org> References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <20090707100239.GC5189@roque.1407.org> Message-ID: <4A532040.1050704@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 07/07/2009 12:02, Rui Miguel Silva Seabra a ?crit : > What you're explicitly told s that you won't be sued if you do so without the right. > > And you have no right! Just to try to understand your point. 1/You don't have the rights to do A. 2/ But you do A, you won't be sued. Doesn't that make 1/ irrelevant in practice ? - -- Dodji Seketeli Red Hat, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpTIEAACgkQPejI7lrem2G7JgCaAhVcAFl5+XesvRHHpI4NEAqa NS4AoJbTAKf60egjGS1/OcosyMnCnMRL =dezR -----END PGP SIGNATURE----- From mrsam at courier-mta.com Tue Jul 7 11:14:01 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Tue, 07 Jul 2009 07:14:01 -0400 Subject: an update to automake-1.11? References: <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <4A527638.1040004@gmail.com> <4A528140.2070100@endoframe.com> <4A528A85.3010704@gmail.com> <1246936191.1347.2466.camel@localhost> <20090707095626.GA30095@amd.home.annexia.org> Message-ID: Richard W.M. Jones writes: > On Mon, Jul 06, 2009 at 11:09:51PM -0400, Braden McDaniel wrote: >> 2. improves the resiliency of the package build to changes to >> Fedora's autotools chain. > > Many projects come with public source repositories, and those don't > include the binary configure/Makefile.in files. You usually build > those locally with a script like 'autogen.sh'. Projects that depend > on precise versions of the autotools are just going to break under > those conditions. Bingo. Which is why this is a rather strange (not my first, or the second, or the nth choice, but I had to spend a few minutes here picking the correct adjective that expresses the general idea, but is still somewhat diplomatic) way to publish source. And, which is why this is somewhat of a rarity, and a novelty. > libguestfs is a case in point - the Debian maintainer builds it from > git using some unknown version of autoconf, and I build it on RHEL and This is a rare exception. For each project you can cite that releases their sources this way, I'll be happy to cite twenty others who don't. Feel free to come up with your largest list. I'll just go through Sourceforge, and grab the first x*20 projects, in response. Given that automake's "make dist" automatically rolls Makefile.in, and configure into the tarball (together with a bunch of other stuff), one has to go out of their way to leave them out of the tarball. Bizarre. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From markmc at redhat.com Tue Jul 7 11:34:21 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 07 Jul 2009 12:34:21 +0100 Subject: an update to automake-1.11? In-Reply-To: References: <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <4A527638.1040004@gmail.com> <4A528140.2070100@endoframe.com> <4A528A85.3010704@gmail.com> <1246936191.1347.2466.camel@localhost> <20090707095626.GA30095@amd.home.annexia.org> Message-ID: <1246966461.2836.56.camel@blaa> On Tue, 2009-07-07 at 07:14 -0400, Sam Varshavchik wrote: > > libguestfs is a case in point - the Debian maintainer builds it from > > git using some unknown version of autoconf, and I build it on RHEL and > > This is a rare exception. No, it's a rare exception for project to keep autotools generated files in version control. Yet people still build lots of projects from version control on a variety of different distros using different versions of autotools. I'm also making the point that maintainers build tarballs without paying much attention to the versions of autotools they're using. > For each project you can cite that releases their > sources this way, I'll be happy to cite twenty others who don't. > > Feel free to come up with your largest list. I'll just go through > Sourceforge, and grab the first x*20 projects, in response. Please tone down the hyperbole. I'd be very interested to hear of a specific case where a recent autotools update has broken old tarball builds. If that was in fact common, and we had some examples, I'd agree with you. > Given that automake's "make dist" automatically rolls Makefile.in, and > configure into the tarball (together with a bunch of other stuff), one has > to go out of their way to leave them out of the tarball. Yes, that autotools generated files are distributed in tarballs is a clear autotools design decision. But why? Is it: a) because the autotools maintainers feel it is unreliable to have people building from the tarball to re-run autotools or b) because the autotools maintainers feel it is inconvenient to require people build from tarballs to have autotools installed I suspect (b) is primary reason, especially in recent times. Cheers, Mark. From rawhide at fedoraproject.org Tue Jul 7 11:50:39 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Tue, 7 Jul 2009 11:50:39 +0000 Subject: rawhide report: 20090707 changes Message-ID: <20090707115039.GA4314@releng2.fedora.phx.redhat.com> Compose started at Tue Jul 7 06:15:17 UTC 2009 New package b43-openfwwf Open firmware for some Broadcom 43xx series WLAN chip New package frinika Music Workstation New package mojito A social network data aggregator New package perl-CGI-Application-Plugin-FillInForm Integrate CGI::Application with HTML::FillInForm New package perl-CGI-Application-Plugin-Forward Pass control from one run mode to another in CGI::Application New package perl-CGI-Application-Plugin-LogDispatch Add Log::Dispatch support to CGI::Application New package perl-CGI-Application-Plugin-TT Add Template Toolkit support to CGI::Application New package supybot-meetbot Plugin for Supybot for handling IRC meetings New package tremfusion Enhanced modification of the free software first person shooter Tremulous New package xorriso ISO 9660 image manipulation tool Updated Packages: DeviceKit-power-009-1.fc12 -------------------------- * Mon Jul 06 2009 Richard Hughes - 009-1 - Update to 009 - Fixes many problems with multi-battery laptops - Use pm-powersave like HAL used to - Fix detecting UPS devices - Add support for recalled laptop batteries PackageKit-0.5.0-1.fc12 ----------------------- * Mon Jul 06 2009 Richard Hughes - 0.5.0-1 - New upstream version, many bugfixes and a few new features - Fixes #483164, #504377, #504137, #499590, #506110 and #506649 R-pls-2.1.0-1.fc12 ------------------ * Mon Jul 06 2009 pingou 2.1.0-1 - Update version from 2.1 to 2.1.0 since for R having a - or a . is similar alpine-2.00-6.fc12 ------------------ * Thu Jul 02 2009 Caol?n McNamara - 2.00-6 - --with-spellcheck-prog isn't a configure option use --with-simple-spellcheck/--with-interactive-spellcheck and patch to prefer hunspell to aspell (#509387) * Wed May 06 2009 Rex Dieter - 2.00-5 - "reply to all recipients" doesn't include anyone on the Cc list (#496400) anaconda-12.1-1.fc12 -------------------- * Mon Jul 06 2009 Chris Lumens - 12.1-1 - Include the rest of the libs isys needs to link against (#509572). (clumens) - Add FCoE disks to the devicetree with a type of FcoeDiskDevice (hdegoede) - Add FcoeDiskDevice class to storage/devices.py (hdegoede) - Add FCoE support to storage/udev.py (hdegoede) - Write out configuration of FCoE to installed system (hdegoede) - Initial FCoE support (hdegoede) blender-2.49a-2.fc12 -------------------- * Mon Jul 06 2009 kwizart < kwizart at gmail.com > - 2.49a-2 - Fix perm on blend2renderinfo.py - raised by #506957 celt-0.6.0-1.fc12 ----------------- * Mon Jul 06 2009 Peter Robinson 0.6.0-1 - New 0.6.0 upstream release claws-mail-plugins-3.7.2-1.fc12 ------------------------------- * Mon Jul 06 2009 Andreas Bierfert - 3.7.2-1 - version upgrade - new plugin: fancy - fix notification plugin to work with libnotify (#496149) coreutils-7.4-3.fc12 -------------------- * Mon Jul 06 2009 Ondrej Vasik 7.4-3 - do not ignore sort's version sort for multibyte locales (#509688) dbus-cxx-0.4.1-1.fc12 --------------------- * Mon Jul 06 2009 Rick L Vinyard Jr - 0.4.1-1 - New release digikam-1.0.0-0.2.beta2.fc12 ---------------------------- * Mon Jul 06 2009 Rex Dieter - 1.0.0-0.2.beta2 - digikam-1.0.0-beta2 fedora-packager-0.3.4-3.fc12 ---------------------------- * Mon Jul 06 2009 Tom "spot" Callaway - 0.3.4-3 - add Requires: redhat-rpm-config to be sure fedora packagers are using all available macros filezilla-3.2.6.1-1.fc12 ------------------------ * Mon Jul 06 2009 kwizart < kwizart at gmail.com > - 3.2.6-1 - Update to 3.2.6.1 freedink-data-1.08.20090706-1.fc12 ---------------------------------- * Mon Jul 06 2009 Sylvain Beucler - 1.08.20090706-1 - New upstream release (remove savegame) frescobaldi-0.7.12-1.fc12 ------------------------- * Sun Jul 05 2009 Orcan Ogetbil - 0.7.12-1 - New upstream version gdb-6.8.50.20090302-39.fc12 --------------------------- * Mon Jul 06 2009 Jan Kratochvil - 6.8.50.20090302-38 - Archer update to the snapshot: 17bfc0488f54aeeb7a9e20ef3caa7e31e8e985fb - Archer backport: de9c5190034b84b0a5fb4b98b05b304cda187700 - [vla] Fix a crash regression on constant DW_AT_data_member_location. * Mon Jul 06 2009 Jan Kratochvil - 6.8.50.20090302-39 - testsuite: Fix multiple runs in parallel on a single host. - testsuite: Remove the rpmbuild option: --with parallel - testsuite: Run the testsuite with default rpm _smp_mflags. geeqie-1.0-0.18.beta2.fc12 -------------------------- * Mon Jul 06 2009 Michael Schwendt - 1.0-0.18.beta2 - update to beta2 tarball - BR intltool - print-pagesize.patch enabled in 1.0beta2 (#222639) geos-3.1.1-1.fc12 ----------------- * Thu Jun 18 2009 Devrim GUNDUZ - 3.1.1-1 - Update to 3.1.1 - Update URL and download URL. - Apply cosmetic changes to spec file. * Sun Apr 26 2009 Devrim GUNDUZ - 3.1.0-1 - Update to 3.1.0 gnome-packagekit-2.27.3-1.fc12 ------------------------------ * Mon Jul 06 2009 Richard Hughes - 2.27.3-1 - New upstream version - Lots of updated translations - Check for dependancies before downloading updates in the update viewer - Connect to gnome-session to get the idle status, not gnome-screensaver - Don't show a generic icon when we have messages - Use the newest filter by default in the update viewer - Run all the packages after install, not just the selected package - Fixes #506010, #507062, #508505, #509067, #509104 and #509636 * Thu Jun 25 2009 Richard Hughes - 2.27.3-0.3.20090625git - Update to latest git master snapshot * Thu Jun 25 2009 Richard Hughes - 2.27.3-0.4.20090625git - Don't build with GDK_MULTIHEAD_SAFE as it breaks ca_gtk_context_get with a new libcanberra-gtk. Ifdefs probably required as ca_gtk_context_get_for_screen is fairly new. gnome-power-manager-2.27.2-1.fc12 --------------------------------- * Mon Jul 06 2009 Richard Hughes - 2.27.2-1 - Update to 2.27.1 gobject-introspection-0.6.3-4.fc12 ---------------------------------- * Mon Jul 06 2009 Peter Robinson - 0.6.3-4 - Add upstream patch to fix a build crash * Thu Jul 02 2009 Peter Robinson - 0.6.3-1 - Update to 0.6.3 * Thu Jul 02 2009 Peter Robinson - 0.6.3-2 - Add the new source file * Thu Jul 02 2009 Peter Robinson - 0.6.3-3 - Add -ggdb temporarily so it compiles on ppc64 gtk2-2.17.3-1.fc12 ------------------ * Tue Jul 07 2009 Matthias Clasen - 2.17.3-1 - Update to 2.17.3 hunspell-ko-0.3.1-1.fc12 ------------------------ * Mon Jul 06 2009 Caolan McNamara - 0.3.1-1 - latest version kde-plasma-stasks-0.5.1-4.fc12 ------------------------------ * Sun Jul 26 2009 Sven Lankes 0.5.1-4 - Really fix it for KDE 4.3 * Mon Jun 29 2009 Sven Lankes 0.5.1-3 - Add two patches for KDE 4.3 plasma kde-plasma-translatoid-0.9-1.fc12 --------------------------------- kdebase-workspace-4.2.95-7.fc12 ------------------------------- * Mon Jul 06 2009 Than Ngo - 4.2.95-7 - plasma-desktop crashes when closing/opening windows (upstream patch) kdeedu-4.2.95-2.fc12 -------------------- * Mon Jul 06 2009 Rex Dieter - 4.2.95-2 - rebuild for cln(libqalculate), see also rhbz#509840 kexec-tools-2.0.0-21.fc12 ------------------------- * Mon Jul 06 2009 Neil Horman 2.0.0-17 - Fixed mkdumprd2 tarball creation * Mon Jul 06 2009 Neil Horman 2.0.0-18 - Updated initscript to use mkdumprd2 if manifest is present - Updated spec to require dash - Updated sample manifest to point to correct initscript - Updated populate_std_files helper to fix sh symlink * Mon Jul 06 2009 Neil Horman 2.0.0-19 - Fix build issue * Mon Jul 06 2009 Neil Horman 2.0.0-20 - Make makedumpfile a dynamic binary * Mon Jul 06 2009 Neil Horman 2.0.0-21 - Fixed build break leafnode-1.11.7-3.fc12 ---------------------- * Sun Jul 05 2009 Kevin Fenzi - 1.11.7-3 - Enable ipv6 support libX11-1.2.1-3.fc12 ------------------- * Mon Jul 06 2009 Adam Jackson 1.2.1-3 - -common subpackage * Tue May 26 2009 Peter Hutterer - 1.2.1-1 - libX11 1.2.1 * Tue May 26 2009 Peter Hutterer - 1.2.1-2 - libX11-1.2.1-indic.patch: Add new Indic language information to nls directory files (#497971) libqalculate-0.9.6-7.fc12 ------------------------- * Mon Jul 06 2009 Rex Dieter 0.9.6-7 - move auto*foo to prep stage - trim pkg-config-related deps (#509840) listen-0.6.2-2.fc12 ------------------- * Mon Jul 06 2009 Ha?kel Gu?mar 0.6.2-2 - added python-inotify as Requires lxsession-edit-0.1.1-1.fc12 --------------------------- * Mon Jul 06 2009 Christoph Wickert - 0.1.1-1 - Update to 0.1.1 lxtask-0.1.1-1.fc12 ------------------- * Mon Jul 06 2009 Christoph Wickert - 0.1.1-1 - Update to 0.1.1 mingw32-glib2-2.21.3-1.fc12 --------------------------- * Mon Jul 06 2009 Erik van Pienbroek - 2.21.3-1 - Update to 2.21.3 - Drop upstreamed patch mkinitrd-6.0.91-1.fc12 ---------------------- * Mon Jul 06 2009 Hans de Goede - 6.0.91-1 - Allow setting VG_LIST in /etc/sysconfig/mkinitrd (#509709) - Fix mkrootdev failing with norelatime option (#509687) olpc-utils-1.0.3-1.fc12 ----------------------- * Mon Jul 06 2009 Daniel Drake 1.0.3-1 - Bug fix release openmsx-0.7.2-1.fc12 -------------------- * Fri Jul 03 2009 Hans de Goede 0.7.2-1 - New upstream release 0.7.2 * Fri Apr 10 2009 Hans de Goede 0.7.0-1 - New upstream release 0.7.0 openswan-2.6.21-5.fc12 ---------------------- * Mon Jul 06 2009 Avesh Agarwal - 2.6.21-5 - Added support for using PSK with NSS - Fixed several warnings and undid unnecessary comments - Updated README.nss with an example configuration - Fixed Openswan ASN.1 parser vulnerability (CVE-2009-2185) parrot-1.3.0-1.39897svn.fc12 ---------------------------- pl-5.7.11-1.fc12 ---------------- * Mon Jul 06 2009 Mary Ellen Foster - 5.7.11-1 - Move binaries into /usr/bin directly to fix multilib issues - Update to latest upstream release - Use officially-distributed PDF documentation instead of HTML - Unify Java patches - Remove strndup package; they fixed it upstream - Fix compilation of "maildrop" packages - Give the xpce documentation directory a clearer name - Removed the FILES section of the man page because it also caused multilib conflicts (and was inaccurate anyway) ptlib-2.6.4-1.fc12 ------------------ * Mon Jul 06 2009 Peter Robinson - 2.6.4-1 - New 2.6.4 stable release pydot-1.0.2-4.fc12 ------------------ * Mon Jul 06 2009 Tom "spot" Callaway - 1.0.2-4 - fix pydot crash with accented character (bugzilla 481540) python-twitter-0.6-2.fc12 ------------------------- * Mon Jul 06 2009 Tom "spot" Callaway - 0.6-2 - fix files so they do not have hardcoded !#/usr/bin/python2.4 quodlibet-2.1-1.fc12 -------------------- * Mon Jul 06 2009 Jeffrey C. Ollie - 2.1-1 - Update to 2.1 based on patches to spec by Andrew Nayenko rednotebook-0.7.5-1.fc12 ------------------------ * Mon Jul 06 2009 Fabian Affolter - 0.7.5-1 - Removed the shebang stuff, upstream changed this - Updated to new upstream version 0.7.5 rhm-0.5.3465-1.fc12 ------------------- * Tue Jun 30 2009 Nuno Santos - 0.5.3465-1 - Rebased to svn rev 3465/788782 rpcbind-0.2.0-3.fc12 -------------------- * Mon Jul 06 2009 Adam Jackson 0.2.0-3 - Requires(pre): coreutils for cut(1). ruby-qpid-0.5.791584-1.fc12 --------------------------- * Mon Jul 06 2009 Nuno Santos - 0.5.791584-1 - Rebased to svn rev 791584 setroubleshoot-plugins-2.1.7-1.fc12 ----------------------------------- * Mon Jul 06 2009 - 2.1.7-1 - Remove stunnel_is_daemon plugin - Add httpd_can_sendmail tcl-trf-2.1.3-3.fc12 -------------------- * Mon Jul 06 2009 Tom "spot" Callaway 2.1.3-3 - fix noripemd patch to resolve undefined symbols (bz 506072) tcpjunk-2.6.92-1.fc12 --------------------- * Mon Jul 06 2009 Fabian Affolter - 2.6.92-1 - Updated to new upsteram version 2.6.92 * Sat Jun 13 2009 Fabian Affolter - 2.6.87-1 - Updated to new upsteram version 2.6.87 xcb-util-0.3.4-2.fc12 --------------------- * Mon Jul 06 2009 Adam Jackson 0.3.4-2 - Explicitly list DSOs so we're notified of version changes. * Sat Jun 13 2009 Michal Nowak - 0.3.4-1 - 0.3.4; needed for Awesome 3.3 xml-security-c-1.5.0-1.fc12 --------------------------- * Mon Jul 06 2009 Antti Andreimann - 1.5.0-1 - New upstream release Summary: Added Packages: 10 Removed Packages: 0 Modified Packages: 54 From kevin.kofler at chello.at Tue Jul 7 12:01:51 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 07 Jul 2009 14:01:51 +0200 Subject: an update to automake-1.11? References: <1246385157.8362.127.camel@localhost.localdomain> <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <4A4B82D3.1050407@freenet.de> <4A5287BA.3000504@endoframe.com> <1246937248.1347.2514.camel@localhost> Message-ID: Braden McDaniel wrote: > Breaking compatibility with previous versions of automake, autoconf, or > libtool has no impact on released tarballs made using those tools; they > continue to work as intended because they do not depend on the presence > of these tools. As such, I imagine the autotools maintainers do not > feel so great an obligation to backward compatibility as the CMake > maintainers might. And that's exactly what I'm complaining about. You eschewed my question about what the advantage of this way of working is, in face of the obvious drawbacks, i.e.: * changing the actual source code (and yes, it's necessary for upstream to change the actual source code) may require other, unrelated changes to account for incompatible autotools changes. Especially if upstream is using a fast-moving distribution like Fedora. Even if updates like that automake 1.11 update wouldn't get pushed, they'd still have to upgrade to a new Fedora with new autotools at least once a year. It's unrealistic to expect upstreams to have a self-installed custom copy of specific autotools versions. A few projects, such as GCC, do that, but most upstreams just use whatever autotools their distro ships, which is usually not even the same for all upstream developers (so configure scripts pingpong between different autotools versions as they're regenerated by different developers). * any bugs in the shared template snippets get copied into all packages using the snippet, so you have to patch lots of packages to fix something. The infamous lib64 rpath bug is one example (and compounded by the fact that upstream refuses to fix it ? one upstream developer claimed it fixed in upstream libtool 2.1, but it actually isn't). For me, this design is inherently broken, just like bundling libraries is (and Fedora has policies banning the latter in most cases), for the same reasons (bugs getting copied to all packages), and I fail to see any advantage of that way of working. Kevin Kofler From kevin.kofler at chello.at Tue Jul 7 12:12:41 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 07 Jul 2009 14:12:41 +0200 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> Message-ID: Sam Varshavchik wrote: > Sure, why not. It just so happens that, not too long ago, I was in an > analogous position where I had some other package that also built against > zlib, for $dayjob$. At $dayjob$ we also package free software using a > scripted reproducible build. Not RPMs, but an analogous process, and at > $dayjob$, for reasons that are irrelevant, zlib was installed into a > nonstandard location. In CMake, in such a case, you just have to use: -DCMAKE_PREFIX_PATH="" It can also be exported as an environment variable. Either way, no changes to the scripts needed at all. Kevin Kofler From kevin.kofler at chello.at Tue Jul 7 12:14:27 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 07 Jul 2009 14:14:27 +0200 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <1246917991.25343.8673.camel@atropine.boston.devel.redhat.com> Message-ID: Sam Varshavchik wrote: > Which, as I pointed out, is still the case if you were to patch > configure.ac instead. > > But, go ahead and ignore this inconvenient fact, too. As I explained (and you ignored), configure.ac tends to change a lot less between upstream releases, especially with a lot fewer irrelevant changes like line number changes or changes in aclocal snippets (because upstream WILL regenerate the file, not surgically edit it!), so it's a lot less likely to produce fuzz. Kevin Kofler From dchen at redhat.com Tue Jul 7 13:07:26 2009 From: dchen at redhat.com (Ding-Yi Chen) Date: Tue, 07 Jul 2009 23:07:26 +1000 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <4A50815B.7070300@kanarip.com> References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> <66ff0543780f93d7f263af099cd22e1d@localhost> <20090705101245.GA10184@jasmine.xos.nl> <4A50815B.7070300@kanarip.com> Message-ID: <1246972046.4725.26.camel@localhost.localdomain> ? ??2009-07-05 ? 12:32 +0200?Jeroen van Meeuwen ??? > On 07/05/2009 12:12 PM, Jos Vos wrote: > > On Sun, Jul 05, 2009 at 12:03:05PM +0200, Jeroen van Meeuwen wrote: > > > >> The CentOS project, or it's upstream, has a release cycle of approximately > >> three years -not a steady release cycle of three years but that's what it > >> turns out to be. This disqualifies the distribution(s) as desktop Linux > >> distributions, as desktops tend to need to run the latest and greatest for > >> as far the latest and greatest lets them. > > > > I don't completely agree that "desktops tend to need to run the latest and > > greatest" (when we're talking about business desktops), but desktops > > (especially also when talking about laptops because of HW compatibilities) > > need newer software than RHEL offers, based on now 3 year old base versions > > of most packages (except Firefox and a few others). > > > > Agreed, I exaggerated a little there ;-) What I meant is they tend to > need to run the latest and greatest *compared* to servers, and as you > said, especially laptops and newer hardware. > > -- Jeroen > Usually, people stick with older releases because they like to keep some packages/applications which are known to works on those releases. On the other hand, they may still want to upgrade other packages to obtain security fixes or crucial features. But the problem is, there is no unanimous way to determine what packages to keep and what packages to update, so generic Fedora legacy repository might not provide much help for those people, who actually need the legacy support. Therefore, I would like to propose an alternative approach, namely, project Denture. See my blog post for further information: http://dingyichen.livejournal.com/14055.html Any comments? -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ From ajax at redhat.com Tue Jul 7 13:19:18 2009 From: ajax at redhat.com (Adam Jackson) Date: Tue, 07 Jul 2009 09:19:18 -0400 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: <20090707085653.GB5189@roque.1407.org> References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> Message-ID: <1246972758.25343.8680.camel@atropine.boston.devel.redhat.com> On Tue, 2009-07-07 at 09:56 +0100, Rui Miguel Silva Seabra wrote: > On Tue, Jul 07, 2009 at 10:24:24AM +0200, drago01 wrote: > > http://port25.technet.com/archive/2009/07/06/the-ecma-c-and-cli-standards.aspx > > Oh poo, and what's the difference? None. None whatsoever but more marketing. > > You can't distribute GPL'ed software unless you have the right to do it. > > The promise makes quite sure to tell you you have no right[1], but you can > infringe that they won't sue *you*[2]. I am unable to read the Community Promise in any way that implies either of the above. Please cite exactly which statement in the Community Promise you take issue with. http://www.microsoft.com/interop/cp/default.mspx - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mlichvar at redhat.com Tue Jul 7 13:24:30 2009 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Tue, 7 Jul 2009 15:24:30 +0200 Subject: readline update? In-Reply-To: <20090703215521.GD13203@nostromo.devel.redhat.com> References: <20090703102747.GA32668@localhost> <20090703215521.GD13203@nostromo.devel.redhat.com> Message-ID: <20090707132430.GD19965@localhost> On Fri, Jul 03, 2009 at 05:55:21PM -0400, Bill Nottingham wrote: > Miroslav Lichvar (mlichvar at redhat.com) said: > > I'd like to update readline to the latest version 6.0. The problem is > > that the license was changed to GPLv3+ and we have some GPLv2 packages > > using readline. > > > > A possible replacement is the editline library which provides a > > compatible interface and is licensed under BSD, unfortunately it > > doesn't handle UTF-8. > > > > Are we stuck with readline 5.2? Suggestions? > > I suppose the first question is whether or not 5.2 and 6.0 are > ABI-compatible; if they're not, a parallel intsall would be simplest. They use different sonames, so parallel install will be probably the least painful way. Review requst for compat-readline5: https://bugzilla.redhat.com/show_bug.cgi?id=510022 After the package is accepted, I'll start patching the packages (except gnu-smalltalk and kdeedu) to build correctly with the compat package. Let me know if you don't want me to touch your package or want to use editline instead. Thanks, -- Miroslav Lichvar From jonathan.underwood at gmail.com Tue Jul 7 13:27:34 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 7 Jul 2009 14:27:34 +0100 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: <1246972758.25343.8680.camel@atropine.boston.devel.redhat.com> References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <1246972758.25343.8680.camel@atropine.boston.devel.redhat.com> Message-ID: <645d17210907070627h426673e8wa1ee2d99fb93492d@mail.gmail.com> 2009/7/7 Adam Jackson : > On Tue, 2009-07-07 at 09:56 +0100, Rui Miguel Silva Seabra wrote: >> On Tue, Jul 07, 2009 at 10:24:24AM +0200, drago01 wrote: >> > http://port25.technet.com/archive/2009/07/06/the-ecma-c-and-cli-standards.aspx >> >> Oh poo, and what's the difference? None. None whatsoever but more marketing. >> >> You can't distribute GPL'ed software unless you have the right to do it. >> >> The promise makes quite sure to tell you you have no right[1], but you can >> infringe that they won't sue *you*[2]. > > I am unable to read the Community Promise in any way that implies either > of the above. ?Please cite exactly which statement in the Community > Promise you take issue with. > > http://www.microsoft.com/interop/cp/default.mspx > Not answering Ajax's question specifically, but this looks a bit iffy: "If you file, maintain, or voluntarily participate in a patent infringement lawsuit against a Microsoft implementation of any Covered Specification, then this personal promise does not apply with respect to any Covered Implementation made or used by you." So, say a few years have passed and C# and the CLI is now a very key component of the stack, and Red Hat (for example) filed a patent lawsuit against MS for something unrelated, MS could turn around and revoke the promise not to sue Red Hat for distributing a C#/CLI implementation, crippling the product that Red Hat now relies on. So I doubt that RMS's concerns are much assuaged by the Community Promise. But I'm just guessing. With similar reasoning it probably cripples the OIN's ability to sue back as well. J. From mlichvar at redhat.com Tue Jul 7 13:28:37 2009 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Tue, 7 Jul 2009 15:28:37 +0200 Subject: readline update? In-Reply-To: References: <20090703102747.GA32668@localhost> Message-ID: <20090707132837.GE19965@localhost> On Fri, Jul 03, 2009 at 02:48:47PM +0200, Kevin Kofler wrote: > Miroslav Lichvar wrote: > > kdeedu-4.2.95-1.fc12 > > kdeedu only uses readline in KAlgebra which is GPLv2+ (and only in the > command-line version ("calgebra") at that), so no problems there. (I also > verified that "calgebra" doesn't use any GPL v2 only libraries.) Thanks. Can you please add it to the license tag? -- Miroslav Lichvar From drago01 at gmail.com Tue Jul 7 13:36:12 2009 From: drago01 at gmail.com (drago01) Date: Tue, 7 Jul 2009 15:36:12 +0200 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: <645d17210907070627h426673e8wa1ee2d99fb93492d@mail.gmail.com> References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <1246972758.25343.8680.camel@atropine.boston.devel.redhat.com> <645d17210907070627h426673e8wa1ee2d99fb93492d@mail.gmail.com> Message-ID: On Tue, Jul 7, 2009 at 3:27 PM, Jonathan Underwood wrote: > 2009/7/7 Adam Jackson : >> On Tue, 2009-07-07 at 09:56 +0100, Rui Miguel Silva Seabra wrote: >>> On Tue, Jul 07, 2009 at 10:24:24AM +0200, drago01 wrote: >>> > http://port25.technet.com/archive/2009/07/06/the-ecma-c-and-cli-standards.aspx >>> >>> Oh poo, and what's the difference? None. None whatsoever but more marketing. >>> >>> You can't distribute GPL'ed software unless you have the right to do it. >>> >>> The promise makes quite sure to tell you you have no right[1], but you can >>> infringe that they won't sue *you*[2]. >> >> I am unable to read the Community Promise in any way that implies either >> of the above. ?Please cite exactly which statement in the Community >> Promise you take issue with. >> >> http://www.microsoft.com/interop/cp/default.mspx >> > > Not answering Ajax's question specifically, but this looks a bit iffy: > > "If you file, maintain, or voluntarily participate in a patent > infringement lawsuit against a Microsoft implementation of any Covered > Specification, then this personal promise does not apply with respect > to any Covered Implementation made or used by you." > > So, say a few years have passed and C# and the CLI is now a very key > component of the stack, and Red Hat (for example) filed a patent > lawsuit against MS for something *unrelated*, " against a Microsoft implementation of any Covered Specification" I don't see why Red Hat would ever sue MS because of a C# / CLI patent. Anything unrelated _IS_ unrelated. From kanarip at kanarip.com Tue Jul 7 13:40:05 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 07 Jul 2009 15:40:05 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <20090707003020.GJ19829@hansolo.jdub.homelinux.org> References: <4A4FD09C.7000809@kanarip.com> <364d303b0907051413q4cc36c70r7173e5cdd2b66e1f@mail.gmail.com> <99e6529575712252b1bd8ff6e14376f3@localhost> <20090706160304.GF19829@hansolo.jdub.homelinux.org> <20090707003020.GJ19829@hansolo.jdub.homelinux.org> Message-ID: <4A535035.5090104@kanarip.com> On 07/07/2009 02:30 AM, Josh Boyer wrote: > Is there a reason any of that can't be done as a secondary arch-like effort? > Nope. Not as far as I can see. > I've already pointed out why it's painful to keep EOL releases around. You > didn't really address those, and you seemed to have grouped them into > "minimal infrastructure effort". I didn't touch on package signing earlier, > but that is another potential hurdle. > > Let me put is this way: > > None of the items I have listed are show-stoppers or insurmountable. However, > unless someone comes forward with _concrete_ proposals on how to approach them > and actual _people_ willing to work on it, they won't change. I don't think > that is an undue burden to having this approved by a governing committee, > whether it be FESCo or the Board. > > It's as simple as that. I think Jeroen understands that, and he seems to > really want constructive criticism on the proposal. So I'll be happy to wait > and see what comes of this. > +1 to all of the above. Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Tue Jul 7 13:41:45 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 07 Jul 2009 15:41:45 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <20090706163737.1b5a932d@ohm.scrye.com> References: <4A4FD09C.7000809@kanarip.com> <364d303b0907051413q4cc36c70r7173e5cdd2b66e1f@mail.gmail.com> <99e6529575712252b1bd8ff6e14376f3@localhost> <20090706160304.GF19829@hansolo.jdub.homelinux.org> <20090706163737.1b5a932d@ohm.scrye.com> Message-ID: <4A535099.6030602@kanarip.com> On 07/07/2009 12:37 AM, Kevin Fenzi wrote: > On Tue, 07 Jul 2009 00:18:51 +0200 > Kevin Kofler wrote: >> Patrice Dumas's proposal failed because he wasn't provided with the >> required infrastructure (and he was unable to come up with it >> himself, which I can't blame him for). > > That was the time before last. The last one was in Feb by Scott > Williams. I guess it just quietly faded out. > Scott Williams was also required to build up his own infrastructure, which frankly is too much overhead in order to be able to start up the rest of it. >>> Without a concrete group of people large enough to make this wory >>> saying that they are signing up to do that work, I don't have high >>> hopes for this succeeding in the long run. >> We'd just need some minimal infrastructure effort, one person willing >> to do the pushes (like you're doing for the supported releases) and >> everything else would be "as is", if somebody wants something fixed, >> they'll have to push the fix, if nobody cares, it won't be fixed. It >> isn't supported after all. And no QA, if it breaks, you get to keep >> the pieces. Again, it's unsupported, that means what it means. I >> still think it's better than not getting any security fixes at all. > > I think it is worse. It causes people to have an expectation that > something will get security updates, and when it doesn't happen and > they get compromised, they will not be very happy. > The same goes for current releases, don't you think? Kind regards, Jeroen van Meeuwen -kanarip From john5342 at googlemail.com Tue Jul 7 13:44:47 2009 From: john5342 at googlemail.com (John5342) Date: Tue, 7 Jul 2009 14:44:47 +0100 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <1246972046.4725.26.camel@localhost.localdomain> References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> <66ff0543780f93d7f263af099cd22e1d@localhost> <20090705101245.GA10184@jasmine.xos.nl> <4A50815B.7070300@kanarip.com> <1246972046.4725.26.camel@localhost.localdomain> Message-ID: <6dc6523c0907070644n49c5d93cp139919e7fc32e86d@mail.gmail.com> 2009/7/7 Ding-Yi Chen : > > ? ??2009-07-05 ? 12:32 +0200?Jeroen van Meeuwen ??? >> On 07/05/2009 12:12 PM, Jos Vos wrote: >> > On Sun, Jul 05, 2009 at 12:03:05PM +0200, Jeroen van Meeuwen wrote: >> > >> >> The CentOS project, or it's upstream, has a release cycle of approximately >> >> three years -not a steady release cycle of three years but that's what it >> >> turns out to be. This disqualifies the distribution(s) as desktop Linux >> >> distributions, as desktops tend to need to run the latest and greatest for >> >> as far the latest and greatest lets them. >> > >> > I don't completely agree that "desktops tend to need to run the latest and >> > greatest" (when we're talking about business desktops), but desktops >> > (especially also when talking about laptops because of HW compatibilities) >> > need newer software than RHEL offers, based on now 3 year old base versions >> > of most packages (except Firefox and a few others). >> > >> >> Agreed, I exaggerated a little there ;-) What I meant is they tend to >> need to run the latest and greatest *compared* to servers, and as you >> said, especially laptops and newer hardware. >> >> -- Jeroen >> > > Usually, people stick with older releases because they like to keep some > packages/applications which are known to works on those releases. > > On the other hand, they may still want to upgrade other packages to > obtain security fixes or crucial features. > > But the problem is, there is no unanimous way to determine what packages > to keep and what packages to update, so generic Fedora legacy repository > might not provide much help for those people, who actually need the > legacy support. > > Therefore, I would like to propose an alternative approach, > namely, project Denture. See my blog post for further information: > http://dingyichen.livejournal.com/14055.html > > Any comments? In theory your proposal sounds great but i see just one major flaw that probably doesn't have a solution. Your idea of packages being built based on dependencies should work great apart from the fact that most packages don't tend to have hard dependencies on versions. Hypothetically in F11 package X-1.2.X relies on package Y-1.2. Later in the release cycle Y-1.3 is released followed later by X-1.3. Eve though X-1.3 actually requires Y-1.3 the maintainer probably never thinks to update the required version (assuming there even was one in the first place). Now your system can easily fail. It picks X-1.3 from F-11 (because thats the latest one) but Y-1.3 isn't allowed (because one of its dependencies is black listed) so it falls back to Y-1.2 which was the latest in F-10. Everything builds fine because they are source compatible but Y-1.2 doesnt have a crucial bug fixed. Now your software is broken. Believe it or not i actually tried something similar for some of my internal servers and i like the idea but its impossible to get the dependencies right which makes the whole idea a no go. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... From lemenkov at gmail.com Tue Jul 7 13:56:29 2009 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 7 Jul 2009 17:56:29 +0400 Subject: How to properly name a cross-toolchain package? Message-ID: Hello All! I plan to add arm-toolchain into Fedora and encountered a difficulty - how to properly name the package? From what I found in the Internets, the cross-toolchains *often* named with the following prefix: ---- For example: i686-pc-linux-gnu- powerpc-unknown-linux-gnu- x86_64-unknown-linux-gnu- http://www.gentoo.org/proj/en/base/embedded/handbook/?part=1&chap=3 However sometimes they named differently (arm-none-eabi-, arm-uclinuxeabi-, etc). Some cross-compilers already included into Fedora, and their packages naming schemes are also different - some examples of prefixes are arm-gp2x-linux-, avr-, msp430-, spu- (mingw32 differs from others because it, at least, implies target OS and libc). I'm sure, it's time to create unified rules for packaging of cross-toolchains, but right now I'm asking you for help in proper naming of it. Should we name it as ----gcc or should we use some other naming schemes? What values should be used for - "fedora" maybe? O should we simply drop this field ("unknown")? -- With best regards! From kanarip at kanarip.com Tue Jul 7 13:57:53 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 07 Jul 2009 15:57:53 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <4A527AB4.7020505@gmail.com> References: <4A4FD09C.7000809@kanarip.com> <1246918076.2965.33.camel@localhost.localdomain> <4A527AB4.7020505@gmail.com> Message-ID: <4A535461.4060406@kanarip.com> On 07/07/2009 12:29 AM, Toshio Kuratomi wrote: > On 07/06/2009 03:07 PM, Jesse Keating wrote: > >> Bugzilla spam. If we keep the release open for random bug filing, we >> have no good way of telling bugzilla that only specific users should get >> bugs for specific releases of Fedora. Ownership is at a product level, >> not at the product version level. So maintainers will get all the spam, >> and have to forward it along to whomever is handling security updates. >> > This one could be solved by having a separate component in bugzilla like > "Fedora Legacy", however that does move into a space that is visible to > end users. Bug triage could probably move bugs from normal Fedora to > "Fedora Legacy" if people were reporting against the correct version but > incorrect product. > For the Bugzilla gurus out there, to what extent is Bugzilla capable to Assign a bug to the owner of a package for a certain branch? Say I file a bug against foo in Fedora 8 now, and have ownership of the foo package in PackageDB... would the owner of the foo package in Fedora !8 branches be spammed with the Bugzilla report? Would it end up in his/her assigned list? I guess the example here is EPEL, which has a separate product "Fedora EPEL" in Bugzilla, no? I guess it would be doable to add a product "Fedora End-Of-Sales" or something (please avoid the Legacy or LTS names). -- Jeroen From rdieter at math.unl.edu Tue Jul 7 13:58:30 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 07 Jul 2009 08:58:30 -0500 Subject: readline update? References: <20090703102747.GA32668@localhost> <20090707132837.GE19965@localhost> Message-ID: Miroslav Lichvar wrote: > On Fri, Jul 03, 2009 at 02:48:47PM +0200, Kevin Kofler wrote: >> Miroslav Lichvar wrote: >> > kdeedu-4.2.95-1.fc12 >> >> kdeedu only uses readline in KAlgebra which is GPLv2+ (and only in the >> command-line version ("calgebra") at that), so no problems there. (I also >> verified that "calgebra" doesn't use any GPL v2 only libraries.) > > Thanks. Can you please add it to the license tag? The kde stack could use some License tag updates, surely, since upstream policy is to be explicitly gplv3 compatible, per http://techbase.kde.org/Policies/Licensing_Policy -- Rex From ajax at redhat.com Tue Jul 7 14:05:43 2009 From: ajax at redhat.com (Adam Jackson) Date: Tue, 07 Jul 2009 10:05:43 -0400 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: <645d17210907070627h426673e8wa1ee2d99fb93492d@mail.gmail.com> References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <1246972758.25343.8680.camel@atropine.boston.devel.redhat.com> <645d17210907070627h426673e8wa1ee2d99fb93492d@mail.gmail.com> Message-ID: <1246975543.25343.8712.camel@atropine.boston.devel.redhat.com> On Tue, 2009-07-07 at 14:27 +0100, Jonathan Underwood wrote: > Not answering Ajax's question specifically, but this looks a bit iffy: > > "If you file, maintain, or voluntarily participate in a patent > infringement lawsuit against a Microsoft implementation of any Covered > Specification, then this personal promise does not apply with respect > to any Covered Implementation made or used by you." > > So, say a few years have passed and C# and the CLI is now a very key > component of the stack, and Red Hat (for example) filed a patent > lawsuit against MS for something unrelated, MS could turn around and > revoke the promise not to sue Red Hat for distributing a C#/CLI > implementation, crippling the product that Red Hat now relies on. So there's two things wrong here. The first one is the "turn around" statement. The very first sentence starts with "Microsoft irrevocably promises". Any assurance made by the Community Promise is forever. The second is the retaliation model. In the language of the Promise: "If you [sue for patent] against a Microsoft implementation of any Covered Specification [...]". A Covered Specification is one that they're covering with this promise. So, if Frobnitz Inc. distributed Mono, and then filed suit against Microsoft for infringing one of Frobnitz' patents in the Microsoft C# implementation, they would lose the right to distribute Mono [1]. However, if Frobnitz distributes Mono, and then files suit against Microsoft for a rendering technique patent used in Internet Explorer, they would still be allowed to distribute Mono [2]. In other words, it's a MAD agreement. You're not even agreeing that any patents they may hold that read on the Covered Spec are _valid_. You're simply agreeing that neither of you will assert any patent claims against the other, for the scope of the Covered Specs, iff you chose to use/make/sell/distribute/etc an implementation of one of the Covered specs. Now this still might not be something you want to agree to. For example, if you hold patents that you think already read on MS's C# implementation, you might not want to lose the ability to exercise them. The question may also be made irrelevant by some third-party patent claim that you think would read on a Covered Spec. Finally, there is the detail that the Promise only extends to what they call "Microsoft Necessary Claims", which are patents necessary to implement any required portion of the spec. There's some wiggle room in the word "necessary"; you might be able to implement a given feature some other way, in which case the patent would presumably not be covered. There's also no assurance over patents involved for optional functionality. (Not a lawyer. Not even a Microsoft fan.) [1] - Specifically, they would lose any rights given to them by the Community Promise. They might still have the right to distribute through some other legal mechanism. [2] - Again, they would only still retain the right to distribute to the extent that they are not infringing some other legal agreement between them and Microsoft. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From drago01 at gmail.com Tue Jul 7 14:06:02 2009 From: drago01 at gmail.com (drago01) Date: Tue, 7 Jul 2009 16:06:02 +0200 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: <20090707100239.GC5189@roque.1407.org> References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <20090707100239.GC5189@roque.1407.org> Message-ID: On Tue, Jul 7, 2009 at 12:02 PM, Rui Miguel Silva Seabra wrote: > On Tue, Jul 07, 2009 at 11:07:52AM +0200, drago01 wrote: >> > The promise makes quite sure to tell you you have no right[1], but you can >> > infringe that they won't sue *you*[2]. >> > >> > [1] => means you can't do it with GPL >> >> It explicitly grant this right. > > What you're explicitly told s that you won't be sued if you do so without the right. > > And you have no right! If I told you "you can do whatever you want with this and I won't sue you" or "you have the right to implement this" Where exactly is the difference? I can redistribute the implementation as I wish because nobody will sue me if I do so .. which means that I HAVE the right to do so. > Further down (in the FAQ, outside the promise) you're told you need to get a > RAND or RAND-Z license to have the rights. Source? > You don't need a lawyer to distinguish between > ?a) having a right > or > ?b) not being sued if you infringe > So what? "not being sued" is the key here... (does not matter how they phrase it, see above) You try to find holes, without backing it up with any citation so sure you need a lawyer to clarification this. From julian.fedoralists at googlemail.com Tue Jul 7 14:06:15 2009 From: julian.fedoralists at googlemail.com (Julian Aloofi) Date: Tue, 07 Jul 2009 16:06:15 +0200 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <1246972758.25343.8680.camel@atropine.boston.devel.redhat.com> <645d17210907070627h426673e8wa1ee2d99fb93492d@mail.gmail.com> Message-ID: <1246975575.5022.3.camel@Julians-Notebook> Am Dienstag, den 07.07.2009, 15:36 +0200 schrieb drago01: > On Tue, Jul 7, 2009 at 3:27 PM, Jonathan > Underwood wrote: > > 2009/7/7 Adam Jackson : > >> On Tue, 2009-07-07 at 09:56 +0100, Rui Miguel Silva Seabra wrote: > >>> On Tue, Jul 07, 2009 at 10:24:24AM +0200, drago01 wrote: > >>> > http://port25.technet.com/archive/2009/07/06/the-ecma-c-and-cli-standards.aspx > >>> > >>> Oh poo, and what's the difference? None. None whatsoever but more marketing. > >>> > >>> You can't distribute GPL'ed software unless you have the right to do it. > >>> > >>> The promise makes quite sure to tell you you have no right[1], but you can > >>> infringe that they won't sue *you*[2]. > >> > >> I am unable to read the Community Promise in any way that implies either > >> of the above. Please cite exactly which statement in the Community > >> Promise you take issue with. > >> > >> http://www.microsoft.com/interop/cp/default.mspx > >> > > > > Not answering Ajax's question specifically, but this looks a bit iffy: > > > > "If you file, maintain, or voluntarily participate in a patent > > infringement lawsuit against a Microsoft implementation of any Covered > > Specification, then this personal promise does not apply with respect > > to any Covered Implementation made or used by you." > > > > So, say a few years have passed and C# and the CLI is now a very key > > component of the stack, and Red Hat (for example) filed a patent > > lawsuit against MS for something *unrelated*, > > " against a Microsoft implementation of any Covered Specification" > I don't see why Red Hat would ever sue MS because of a C# / CLI patent. > > Anything unrelated _IS_ unrelated. Unfortunately the patent promise covers more things than just C# / CLI patents. And it seems like you're going to lose the whole promise when you just sue them over one specification in there, e.g. the XPS specification. Maybe that's less of a problem for Red Hat because they don't like patents anyway and are not likely holding any XPS related patents, but it could be a problem for the OIN. -------------- 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 drago01 at gmail.com Tue Jul 7 14:09:08 2009 From: drago01 at gmail.com (drago01) Date: Tue, 7 Jul 2009 16:09:08 +0200 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: <1246975575.5022.3.camel@Julians-Notebook> References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <1246972758.25343.8680.camel@atropine.boston.devel.redhat.com> <645d17210907070627h426673e8wa1ee2d99fb93492d@mail.gmail.com> <1246975575.5022.3.camel@Julians-Notebook> Message-ID: On Tue, Jul 7, 2009 at 4:06 PM, Julian Aloofi wrote: > Am Dienstag, den 07.07.2009, 15:36 +0200 schrieb drago01: >> On Tue, Jul 7, 2009 at 3:27 PM, Jonathan >> Underwood wrote: >> > 2009/7/7 Adam Jackson : >> >> On Tue, 2009-07-07 at 09:56 +0100, Rui Miguel Silva Seabra wrote: >> >>> On Tue, Jul 07, 2009 at 10:24:24AM +0200, drago01 wrote: >> >>> > http://port25.technet.com/archive/2009/07/06/the-ecma-c-and-cli-standards.aspx >> >>> >> >>> Oh poo, and what's the difference? None. None whatsoever but more marketing. >> >>> >> >>> You can't distribute GPL'ed software unless you have the right to do it. >> >>> >> >>> The promise makes quite sure to tell you you have no right[1], but you can >> >>> infringe that they won't sue *you*[2]. >> >> >> >> I am unable to read the Community Promise in any way that implies either >> >> of the above. ?Please cite exactly which statement in the Community >> >> Promise you take issue with. >> >> >> >> http://www.microsoft.com/interop/cp/default.mspx >> >> >> > >> > Not answering Ajax's question specifically, but this looks a bit iffy: >> > >> > "If you file, maintain, or voluntarily participate in a patent >> > infringement lawsuit against a Microsoft implementation of any Covered >> > Specification, then this personal promise does not apply with respect >> > to any Covered Implementation made or used by you." >> > >> > So, say a few years have passed and C# and the CLI is now a very key >> > component of the stack, and Red Hat (for example) filed a patent >> > lawsuit against MS for something *unrelated*, >> >> " against a Microsoft implementation of any Covered Specification" >> I don't see why Red Hat would ever sue MS because of a C# / CLI patent. >> >> Anything unrelated _IS_ unrelated. > Unfortunately the patent promise covers more things than just C# / CLI patents. > And it seems like you're going to lose the whole promise when you just > sue them over one specification in there, e.g. the XPS specification. > Maybe that's less of a problem for Red Hat because they don't like > patents anyway and are not likely holding any XPS related patents, but > it could be a problem for the OIN. Yeah got this after reading Ajax's post. From jkeating at j2solutions.net Tue Jul 7 14:14:47 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 7 Jul 2009 07:14:47 -0700 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: <4A532040.1050704@redhat.com> References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <20090707100239.GC5189@roque.1407.org> <4A532040.1050704@redhat.com> Message-ID: <196900AB-4E17-47CF-8D09-4EC9B1BD3E3F@j2solutions.net> On Jul 7, 2009, at 3:15, Dodji Seketeli wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Le 07/07/2009 12:02, Rui Miguel Silva Seabra a ?crit : > >> What you're explicitly told s that you won't be sued if you do so >> without the right. >> >> And you have no right! > > Just to try to understand your point. > > 1/You don't have the rights to do A. > 2/ But you do A, you won't be sued. > > Doesn't that make 1/ irrelevant in practice ? > No, it just means that the promise to not sue can be lifted at any time and leave every user vulnerable. If the code were licensed in such a way that the patent indemnification came with the license then when the license changes to remove the patent protection only users of the new versions are at risk. All users of the old versions are not at risk due to the license on those old versions. Licenses cannot be changed retroactively but promises outside the license can. -- Jes From jkeating at j2solutions.net Tue Jul 7 14:18:08 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 7 Jul 2009 07:18:08 -0700 Subject: an update to automake-1.11? In-Reply-To: References: <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <4A527638.1040004@gmail.com> <4A528140.2070100@endoframe.com> <4A528A85.3010704@gmail.com> <1246936191.1347.2466.camel@localhost> <20090707095626.GA30095@amd.home.annexia.org> Message-ID: <655A2590-9244-48DF-B9F9-899F1F82F09D@j2solutions.net> On Jul 7, 2009, at 4:14, Sam Varshavchik wrote: > Richard W.M. Jones writes: > >> On Mon, Jul 06, 2009 at 11:09:51PM -0400, Braden McDaniel wrote: >>> 2. improves the resiliency of the package build to changes to >>> Fedora's autotools chain. >> Many projects come with public source repositories, and those don't >> include the binary configure/Makefile.in files. You usually build >> those locally with a script like 'autogen.sh'. Projects that depend >> on precise versions of the autotools are just going to break under >> those conditions. > > Bingo. Which is why this is a rather strange (not my first, or the > second, or the nth choice, but I had to spend a few minutes here > picking the correct adjective that expresses the general idea, but > is still somewhat diplomatic) way to publish source. And, which is > why this is somewhat of a rarity, and a novelty. > >> libguestfs is a case in point - the Debian maintainer builds it from >> git using some unknown version of autoconf, and I build it on RHEL >> and > > This is a rare exception. For each project you can cite that > releases their sources this way, I'll be happy to cite twenty others > who don't. > > Feel free to come up with your largest list. I'll just go through > Sourceforge, and grab the first x*20 projects, in response. > > Given that automake's "make dist" automatically rolls Makefile.in, > and configure into the tarball (together with a bunch of other > stuff), one has to go out of their way to leave them out of the > tarball. > > Bizarre. These days distributing via tarball is bizarre. Distributed source control is changing the way that projects work and release. Sure there are plenty of projects out here that don't work this way but more and more are headed in this direction. -- Jes -------------- next part -------------- An HTML attachment was scrubbed... URL: From kanarip at kanarip.com Tue Jul 7 14:21:49 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 07 Jul 2009 16:21:49 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <20090706170625.4d562f75@ohm.scrye.com> References: <4A4FD09C.7000809@kanarip.com> <20090706105734.29c92a78@ohm.scrye.com> <6e3ba5f24be85ab5aa79d152acc96095@localhost> <20090706170625.4d562f75@ohm.scrye.com> Message-ID: <4A5359FD.6060101@kanarip.com> On 07/07/2009 01:06 AM, Kevin Fenzi wrote: > On Mon, 06 Jul 2009 20:20:50 +0200 > Jeroen van Meeuwen wrote: > >> Reading it on a question-mark per question-mark basis though, I think >> the feature page answers half of the half-posed questions. Anyway: >> >> - a bunch > > fas names? Approximate number? A bunch right now is approximately 25, including the people I've seen being enthusiastic in this thread or in private conversations. This doesn't mean I have 25 people lined up to do the actual work though, but for a single thread and some private communication (not fully exposed and not started yet), I think ~25 people is a strong start. > When this comes up there is always "A bunch of people" who want this, > but they never seem to want to sign up to do the work. Do you have such > people ready to go to work? > I can personally guarantee 1 FTE of work backing up this proposal for 6 months of extended life cycle support. >>> - Are there any Corporations that specifically asked for this? Would >>> they be willing to provide any resources to the effort? >> The demand is there..., the offerings... not so much. Maybe there's a >> trick to get sponsoring for something that does not and may not exist >> yet because approval is pending, that I don't know about. Care to >> share? > > Well, I would say gather your group, show that there is an active > group of people ready to work on this and you will have a lot less > skepticism. I personally look at the last time this came up. As far as > I know the group had 1 meeting, nothing ever happened. > Nothing ever got out, true. Some things did happen, such as building a large part of the infrastructure needed. It didn't live up to it's full potential though, agreed. > I fear you are going to have to show some great setup and activity > before people are going to take this seriously. :( > What the conditions are for anyone out there to take this seriously or not, realistically, isn't my problem. I can't satisfy everybody in every aspect as you'll undoubtedly understand, but I can make sure valid concerns are addressed or taken into account prior to a decision being made on whether to allow this within and through the Fedora Project (as a Feature?). I should also note that I can not just share information on people interested or willing to do the work with you all, since I do not know or control their desired level of privacy. Either they step up and make themselves known to the world during one of these conversations, or they keep silent and you will never hear from then until after the discussion and the final decision -for whatever reason, I don't know. I'm sorry, but I choose to not be the one deciding whether people can opt-in later, at any given point, or whether they opt-in because I share their personal information. Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Tue Jul 7 14:24:40 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 07 Jul 2009 16:24:40 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <1246918076.2965.33.camel@localhost.localdomain> References: <4A4FD09C.7000809@kanarip.com> <1246918076.2965.33.camel@localhost.localdomain> Message-ID: <4A535AA8.4020405@kanarip.com> On 07/07/2009 12:07 AM, Jesse Keating wrote: > On Sat, 2009-07-04 at 23:58 +0200, Jeroen van Meeuwen wrote: >> I wanted to draw your attention to a feature I've proposed for Fedora >> 12, mysteriously called Extended Life Cycle. >> >> You can find more details at >> https://fedoraproject.org/wiki/Features/Extended_Life_Cycle > > When we talked at Berlin some of the details were a bit different, and > I'll get to some of what I talked about there later in this email. > > First off, I think this is different from Fedora Legacy, or has > potential to. Legacy had a few very key fail points. 1) it was opt in. > Users had to know about it and actively enable it. 2) it was completely > done outside of the Fedora infrastructure. 3) Fedora's popularity was > very hit and miss, the type of people that would best use a Legacy like > service were too burned to give any Red Hat related offering a shot. 4) > RHEL4 (and its clones) were new enough for most of the people that would > use this service, and thus they went that way. > > A longer Fedora sounds really great now, particularly because EL 5 and > its clones are rather long in the tooth. How good it will sound once > EL6 is out is a different matter. I think the popularity will wax and > wane as the EL release cycles go. > Like with anything else, though FY2010 is the right moment to start with, it has to grow organically and it will, or it won't, regardless of whether the timing is excellent -we would only need to take into account the release of EL6 from the perspective of expectations from our side. > I think for this to succeed as an effort, which there is some folks whom > state a need, I think there needs to be a few key things. > > * Automatic use. Users shouldn't have to opt-in to something different, > they should have to do nothing and continue to get the updates. > +1, no change on the consumer side may be required in order to have the ELC feature succeed. > * A clarification of "security" updates. Will local denial of service > (aka crash bug) be fixed? Local root escalation? Remote denial of > service? Remote escalations? The amount of updates you will have to do > will change dramatically based upon what level of security updates you > want to target. http://www.redhat.com/security/updates/classification/ > may help and may be familiar to the type of users you are targeting. > I'll look into these details and try and elaborate on what I find -on the Feature page, so that this is (more) clear. Like I said before, I'm not in control and this is (going to be) a group effort so things may turn out a little different but we need to think about it anyway, so let's give it a shot beforehand. Thanks! > * All or nothing. Either updates for whatever class you clarify from > above will be provided for all packages, or none. There can't be any > vagueness here. > All, +1 > * A way to prevent updates that do not match the above from being > pushed. Ambiguity in what can be expected can cause confusion and fear. > I realize that we have ambiguity during the normal release cycle and > that is maintainer driven, but an extended support effort like this > should clarify what will be offered. > If you take into account that the proposal concerns security fixes only, then every update has to be labeled a security update (and preferably have some kind of CVE/bug# attached??). We would need to think about a policy for that, agreed. Without a guarantee for stable ABI/API or stable major/minor version numbers though some updates may have to be pushed as part of the dependency stack for a given security bug fix -or not. I guess we'll need to describe how this should be tackled exactly. > * A measure of success. Some way that you can decide whether or not the > "Feature" has been a success and should be continued, or whether it is a > failure and shot not be continued, or should be attempted in some other > way > The measure of success is particularly hard to state in figures. Just thinking about some measures of success though, it would include; - increased participation from the Fedora side of things - continuous flow of security updates (and bugs against EOS releases solved) - increased consumption and maybe there's more. Number of subscriptions to an announcement / errata type of mailing list maybe? Number of subscriptions to a ELC SIG mailing list? > * A timeline to go with the above to review for success/failure > Here's where the initial proposed extension of 6 months kicks in. I would say our first review is what is now called "Alpha freeze" -the milestone where Features are checked for their readiness -whether this proposal ends up being an actual feature or not. > * A responsible body behind the effort to make regular reports to > FESCo/Board > This is not up to me ;-) I guess we'll hear from FESCo, on whether they think this is a feature, on whether they think this is in their mandate, on whether they think this has to go to the Board. > Who is going to track and discover the security issues? > To be determined. Could be delegated to a (dedicated?) small(er) group of people within the SIG (to be set up) -maybe the not-so-technical??, or could be a responsible of each individual participating. Kind regards, Jeroen van Meeuwen -kanarip From ajax at redhat.com Tue Jul 7 14:39:48 2009 From: ajax at redhat.com (Adam Jackson) Date: Tue, 07 Jul 2009 10:39:48 -0400 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: <1246975575.5022.3.camel@Julians-Notebook> References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <1246972758.25343.8680.camel@atropine.boston.devel.redhat.com> <645d17210907070627h426673e8wa1ee2d99fb93492d@mail.gmail.com> <1246975575.5022.3.camel@Julians-Notebook> Message-ID: <1246977588.25343.8735.camel@atropine.boston.devel.redhat.com> On Tue, 2009-07-07 at 16:06 +0200, Julian Aloofi wrote: > Unfortunately the patent promise covers more things than just C# / CLI patents. > And it seems like you're going to lose the whole promise when you just > sue them over one specification in there, e.g. the XPS specification. > Maybe that's less of a problem for Red Hat because they don't like > patents anyway and are not likely holding any XPS related patents, but > it could be a problem for the OIN. The relevant sentence to the above argument is: "If you file, maintain, or voluntarily participate in a patent infringement lawsuit against a Microsoft implementation of any Covered Specification, then this personal promise does not apply with respect to any Covered Implementation made or used by you." This may be ambiguously worded. "any Covered Implementation" might mean the one(s) corresponding to the Covered Specification you're bringing suit against, or it might mean any Covered Implementation of yours at all. The FAQ on the same page seems to indicate that the "corresponding" interpretation is intended: "As stated in the CP, the only time Microsoft can withdraw its promise against a specific person or company for a specific Covered Specification is if that person or company brings (or voluntarily participates in) a patent infringement lawsuit against Microsoft regarding Microsoft's implementation of the _same_ [emphasis mine] Covered Specification. This type of "suspension" clause is common industry practice." But I'd definitely ask a lawyer for the real answer, and probably ask Microsoft to clarify the language if I were to rely on it. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From frankly3d at gmail.com Tue Jul 7 14:41:34 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Tue, 07 Jul 2009 15:41:34 +0100 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: <1246975543.25343.8712.camel@atropine.boston.devel.redhat.com> References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <1246972758.25343.8680.camel@atropine.boston.devel.redhat.com> <645d17210907070627h426673e8wa1ee2d99fb93492d@mail.gmail.com> <1246975543.25343.8712.camel@atropine.boston.devel.redhat.com> Message-ID: <4A535E9E.3020202@gmail.com> https://www.redhat.com/archives/fedora-legal-list/2009-July/msg00014.html Regards, Frank From skvidal at fedoraproject.org Tue Jul 7 14:23:36 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 7 Jul 2009 10:23:36 -0400 (EDT) Subject: an update to automake-1.11? In-Reply-To: <655A2590-9244-48DF-B9F9-899F1F82F09D@j2solutions.net> References: <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <4A527638.1040004@gmail.com> <4A528140.2070100@endoframe.com> <4A528A85.3010704@gmail.com> <1246936191.1347.2466.camel@localhost> <20090707095626.GA30095@amd.home.annexia.org> <655A2590-9244-48DF-B9F9-899F1F82F09D@j2solutions.net> Message-ID: On Tue, 7 Jul 2009, Jesse Keating wrote: > > These days distributing via tarball is bizarre. ?Distributed source control is changing the way that projects work and > release. Sure there are plenty of projects out here that don't work this way but more and more are headed in this > direction.? > I disagree. I think the discrete tarball snapshot of a release will continue for quite some time and I've not seen anyone moving away from that in their public software releases. -sv From dchen at redhat.com Tue Jul 7 14:59:40 2009 From: dchen at redhat.com (Ding-Yi Chen) Date: Wed, 08 Jul 2009 00:59:40 +1000 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <6dc6523c0907070644n49c5d93cp139919e7fc32e86d@mail.gmail.com> References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> <66ff0543780f93d7f263af099cd22e1d@localhost> <20090705101245.GA10184@jasmine.xos.nl> <4A50815B.7070300@kanarip.com> <1246972046.4725.26.camel@localhost.localdomain> <6dc6523c0907070644n49c5d93cp139919e7fc32e86d@mail.gmail.com> Message-ID: <1246978780.4725.69.camel@localhost.localdomain> ? ??2009-07-07 ? 14:44 +0100?John5342 ??? > 2009/7/7 Ding-Yi Chen : > > > > Any comments? > > In theory your proposal sounds great but i see just one major flaw > that probably doesn't have a solution. Your idea of packages being > built based on dependencies should work great apart from the fact that > most packages don't tend to have hard dependencies on versions. > Hypothetically in F11 package X-1.2.X relies on package Y-1.2. Later > in the release cycle Y-1.3 is released followed later by X-1.3. Eve > though X-1.3 actually requires Y-1.3 the maintainer probably never > thinks to update the required version (assuming there even was one in > the first place). Now your system can easily fail. It picks X-1.3 from > F-11 (because thats the latest one) but Y-1.3 isn't allowed (because > one of its dependencies is black listed) so it falls back to Y-1.2 > which was the latest in F-10. Everything builds fine because they are > source compatible but Y-1.2 doesnt have a crucial bug fixed. Now your > software is broken. All systems have bugs and may break. So you don't use any of them? :-) The scenario you raised could happen if not so many people use the package X. Otherwise, it would likely be spot by people who use yum update X, as Y-1.3 is not dragged in. Given X-1.3 is broken without Y-1.3, thus bug will likely be spot. Well, Y depends on black-listed packages doesn't mean Y cannot be upgraded at all. As long as the the newer Y does not require higher version of black-listed packages. But if black-listed packages requires Y, or Y is black-listed, then Y will not be upgraded. In those cases, it is expected behavior that X should not be upgraded to X-1.3 because Y cannot be upgraded to Y-1.3. Yes, you find out the limitation of Denture, but no, Denture is not broken. :-) > Believe it or not i actually tried something similar for some of my > internal servers and i like the idea but its impossible to get the > dependencies right which makes the whole idea a no go. Believe it or not I actually tried something similar, but by hand though. I agree some maintainers does not accurately specify the dependency. but it is not beyond fix. One way to overcome this is maintaining a small datafile that contain the *true* dependency. Denture is not meant to be used to upgrade the whole system, but an automated tool to build a target package and corresponding mid-packages under specified constrain. So you only need to correct the dependencies of the target packages and mid-packages if you really need the target package. > > -- > There are 10 kinds of people in the world: Those who understand binary > and those who don't... > I like your signature. :-) -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ From notting at redhat.com Tue Jul 7 01:38:24 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 6 Jul 2009 21:38:24 -0400 Subject: Requesting Feature Page Status Updates by July 14, 2009 In-Reply-To: References: <4A513754.5040907__11365.4729015709$1246922254$gmane$org@redhat.com> <1246926522.6216.5.camel@localhost.localdomain> Message-ID: <20090707013824.GA18891@nostromo.devel.redhat.com> Kevin Kofler (kevin.kofler at chello.at) said: > > Per https://fedoraproject.org/wiki/Milestone_Adjustment_Proposal what > > used to be called "Beta" is now called "Alpha". This matches industry > > nomenclature for what we were actually producing. > > Uh, I kinda recalled that the feedback on the mailing list for this renaming > proposal has been overwhelmingly negative, but maybe that was just me > getting a wrong impression? Personally, I don't care strongly about the > naming anyway, be it "beta", "alpha", "test1" or whatever. :-) My recollection is that the feedback on this proposal was overwhelmingly nonexistent. The proposals on 'no frozen rawhide', 'critical path', etc. got a lot more response. Bill From walters at verbum.org Tue Jul 7 15:04:47 2009 From: walters at verbum.org (Colin Walters) Date: Tue, 7 Jul 2009 11:04:47 -0400 Subject: an update to automake-1.11? In-Reply-To: References: <20090705131655.GA21540@amd.home.annexia.org> <4A527638.1040004@gmail.com> <4A528140.2070100@endoframe.com> <4A528A85.3010704@gmail.com> <1246936191.1347.2466.camel@localhost> <20090707095626.GA30095@amd.home.annexia.org> <655A2590-9244-48DF-B9F9-899F1F82F09D@j2solutions.net> Message-ID: On Tue, Jul 7, 2009 at 10:23 AM, Seth Vidal wrote: > > I disagree. I think the discrete tarball snapshot of a release will continue > for quite some time and I've not seen anyone moving away from that in their > public software releases. It's not so black and white; for example, it often makes sense to pull git snapshots of a project during rawhide. If our tooling made it easy to run a command and pull from git I'd definitely use it. Not for all projects, and not all the time, but it'd be useful. From drago01 at gmail.com Tue Jul 7 15:10:44 2009 From: drago01 at gmail.com (drago01) Date: Tue, 7 Jul 2009 17:10:44 +0200 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: <4A535E9E.3020202@gmail.com> References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <1246972758.25343.8680.camel@atropine.boston.devel.redhat.com> <645d17210907070627h426673e8wa1ee2d99fb93492d@mail.gmail.com> <1246975543.25343.8712.camel@atropine.boston.devel.redhat.com> <4A535E9E.3020202@gmail.com> Message-ID: On Tue, Jul 7, 2009 at 4:41 PM, Frank Murphy wrote: > https://www.redhat.com/archives/fedora-legal-list/2009-July/msg00014.html OK, so lets move on before this ends into a flamewar ;) From ajax at redhat.com Tue Jul 7 15:18:46 2009 From: ajax at redhat.com (Adam Jackson) Date: Tue, 07 Jul 2009 11:18:46 -0400 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: <196900AB-4E17-47CF-8D09-4EC9B1BD3E3F@j2solutions.net> References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <20090707100239.GC5189@roque.1407.org> <4A532040.1050704@redhat.com> <196900AB-4E17-47CF-8D09-4EC9B1BD3E3F@j2solutions.net> Message-ID: <1246979926.25343.8737.camel@atropine.boston.devel.redhat.com> On Tue, 2009-07-07 at 07:14 -0700, Jesse Keating wrote: > On Jul 7, 2009, at 3:15, Dodji Seketeli wrote: > > Le 07/07/2009 12:02, Rui Miguel Silva Seabra a ?crit : > >> What you're explicitly told s that you won't be sued if you do so > >> without the right. > >> > >> And you have no right! > > > > Just to try to understand your point. > > > > 1/You don't have the rights to do A. > > 2/ But you do A, you won't be sued. > > > > Doesn't that make 1/ irrelevant in practice ? > > No, it just means that the promise to not sue can be lifted at any > time and leave every user vulnerable. Except that, for the Microsoft Community Promise, it can not. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Tue Jul 7 15:21:20 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 7 Jul 2009 11:21:20 -0400 (EDT) Subject: an update to automake-1.11? In-Reply-To: References: <20090705131655.GA21540@amd.home.annexia.org> <4A527638.1040004@gmail.com> <4A528140.2070100@endoframe.com> <4A528A85.3010704@gmail.com> <1246936191.1347.2466.camel@localhost> <20090707095626.GA30095@amd.home.annexia.org> <655A2590-9244-48DF-B9F9-899F1F82F09D@j2solutions.net> Message-ID: On Tue, 7 Jul 2009, Colin Walters wrote: > On Tue, Jul 7, 2009 at 10:23 AM, Seth Vidal wrote: >> >> I disagree. I think the discrete tarball snapshot of a release will continue >> for quite some time and I've not seen anyone moving away from that in their >> public software releases. > > It's not so black and white; for example, it often makes sense to pull > git snapshots of a project during rawhide. If our tooling made it > easy to run a command and pull from git I'd definitely use it. Not > for all projects, and not all the time, but it'd be useful. > umm - I don't think I said tarballs were the only way to do things. I just said that I didn't think they were as disused for releases as jesse suggested. -sv From jlaska at redhat.com Tue Jul 7 15:29:07 2009 From: jlaska at redhat.com (James Laska) Date: Tue, 07 Jul 2009 11:29:07 -0400 Subject: Display configuration test day [TODAY] In-Reply-To: <1246935213.1600.14.camel@planemask> References: <1246935213.1600.14.camel@planemask> Message-ID: <1246980547.3918.73.camel@flatline.devel.redhat.com> On Mon, 2009-07-06 at 22:53 -0400, Matthias Clasen wrote: > Just a reminder that we are kicking off our 'fit and finish' initiative > with a test day on display configuration tomorrow, in > #fedora-fit-and-finish. If you go to > > http://www.fedoraproject.org/wiki/Test_Day:2009-07-07_Fit_and_Finish:Display_Configuration > > you'll find more information. We will also have (slightly oversize) live > cds available. Thanks for the reminder Matthias! For interested folks, there is a receptive audience awaiting your feedback and ideas around 'desktop configuration' issues. There are several test cases defined to help guide testing. I encourage you to join the fun over in #fedora-fit-and-finish. Thanks, James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kanarip at kanarip.com Tue Jul 7 15:30:55 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 07 Jul 2009 17:30:55 +0200 Subject: F10 anaconda incompatible with current F10 yum - WTF In-Reply-To: References: Message-ID: <4A536A2F.6080404@kanarip.com> On 07/02/2009 05:31 PM, Xavier Toth wrote: > It's a one liner. > > --- anaconda-11.5.0.12/yuminstall.py.orig 2009-06-30 > 09:05:19.000000000 -0500 > +++ anaconda-11.5.0.12/yuminstall.py 2009-06-30 09:06:03.000000000 -0500 > @@ -575,8 +575,7 @@ > YumSorter.getReposFromConfig(self) > > # Override this method so yum doesn't nuke our existing logging config. > - def doLoggingSetup(self, debuglevel, errorlevel, syslog_indent=None, > - syslog_facility=None): > + def doLoggingSetup(self, *args, **kwargs): > pass > > def doConfigSetup(self, fn='/tmp/anaconda-yum.conf', root='/'): > > > Ted > Regrettably, 11.5.0.12 is the wrong version for Fedora 10; you need 11.4.1.63. 11.5.0.12 is the Fedora 11 series and might therefor have different disturbing effects on composing media. I'm building a new version of anaconda for Fedora 10, if you're interested let me know. -- Jeroen From john5342 at googlemail.com Tue Jul 7 15:39:16 2009 From: john5342 at googlemail.com (John5342) Date: Tue, 7 Jul 2009 16:39:16 +0100 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <1246978780.4725.69.camel@localhost.localdomain> References: <4A4FD09C.7000809@kanarip.com> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> <66ff0543780f93d7f263af099cd22e1d@localhost> <20090705101245.GA10184@jasmine.xos.nl> <4A50815B.7070300@kanarip.com> <1246972046.4725.26.camel@localhost.localdomain> <6dc6523c0907070644n49c5d93cp139919e7fc32e86d@mail.gmail.com> <1246978780.4725.69.camel@localhost.localdomain> Message-ID: <6dc6523c0907070839n759ee561tf83edab15e49077b@mail.gmail.com> 2009/7/7 Ding-Yi Chen : > > ? ??2009-07-07 ? 14:44 +0100?John5342 ??? >> 2009/7/7 Ding-Yi Chen : >> > >> > Any comments? >> >> In theory your proposal sounds great but i see just one major flaw >> that probably doesn't have a solution. Your idea of packages being >> built based on dependencies should work great apart from the fact that >> most packages don't tend to have hard dependencies on versions. >> Hypothetically in F11 package X-1.2.X relies on package Y-1.2. Later >> in the release cycle Y-1.3 is released followed later by X-1.3. Eve >> though X-1.3 actually requires Y-1.3 the maintainer probably never >> thinks to update the required version (assuming there even was one in >> the first place). Now your system can easily fail. It picks X-1.3 from >> F-11 (because thats the latest one) but Y-1.3 isn't allowed (because >> one of its dependencies is black listed) so it falls back to Y-1.2 >> which was the latest in F-10. Everything builds fine because they are >> source compatible but Y-1.2 doesnt have a crucial bug fixed. Now your >> software is broken. > > All systems have bugs and may break. So you don't use any of them? :-) Ofcourse all systems have bugs. However some are minor whilst others are so much work to make them usable that they are simply not worth it. Stuff that requires constant user intervention to cope with scenarios that cannot be automated is one such major issue. > The scenario you raised could happen if not so many people use the > package X. Otherwise, it would likely be spot by people who use > yum update X, as Y-1.3 is not dragged in. > Given X-1.3 is broken without Y-1.3, thus bug will likely be spot. Wouldn't be spotted until it is used in your system. It wouldn't be used during standard usage because in a normal release both would be updated at the same time (or at least in the right order) so the scenario never happens. > Well, Y depends on black-listed packages doesn't mean Y cannot be > upgraded at all. As long as the the newer Y does not require higher > version of black-listed packages. Of course Y can be updated but not necessarily to the required version. If the world was perfect all versions of packages would contain the exact versions required for things to work and your proposed system would either update fine or refuse to with a message if a dependency is blacklisted or unavailable as a recent enough version. However unfortunately for the same reasons i stated already virtually no package will state the dependant versions accurately enough to do what you want. > ?But if black-listed packages requires Y, or Y is black-listed, > then Y will not be upgraded. > In those cases, it is expected behavior that X should not be upgraded to > X-1.3 because Y cannot be upgraded to Y-1.3. That is of course assuming X-1.3 has an explicit dependency on Y-1.3. It would be lovely if all packages has these versioned dependencies and a lot have automatically due to things like sonames but take the scenario where the soname is the same but the presence of the bug is not. > Yes, you find out the limitation of Denture, but no, > Denture is not broken. :-) Denture is not broken. Unfortunately though Denture only works in the ideal world. In reality though scenarios like i just mentioned happen all the time (along with many other similar issues) and the scenario i mentioned would break the users system and Denture has no way of knowing until it is too late. >> Believe it or not i actually tried something similar for some of my >> internal servers and i like the idea but its impossible to get the >> dependencies right which makes the whole idea a no go. > > Believe it or not I actually tried something similar, > but by hand though. > > I agree some maintainers does not accurately specify the dependency. > but it is not beyond fix. It is not some. It is more like most. How many packages do you see with the following for every single requires and build requires: BuildRequires: X-devel = X.X.X-X Requires: X = X.X.X-X And packagers shouldnt have to. apart from anything else it would mean that every single time somebody rebuilds a package all packages that depend on it would need rebuilding even if the update is binary compatible yet at the same time the only way to stop the scenario i mentioned from happening is to do exactly that. During a normal release bugs are easily spotted and fixed and scenarios like i mentioned will mostly never even happen anyway but mixing packages from different releases will potentially create an infinite number of combinations and almost certainly break. > One way to overcome this is maintaining a small datafile that contain > the *true* dependency. > Denture is not meant to be used to upgrade the whole system, > but an automated tool to build a target package and corresponding > mid-packages under specified constrain. > > So you only need to correct the dependencies of the target packages and > mid-packages if you really need the target package. > >> >> -- >> There are 10 kinds of people in the world: Those who understand binary >> and those who don't... >> > > I like your signature. :-) Thanks :) -- There are 10 kinds of people in the world: Those who understand binary and those who don't... From mw_triad at users.sourceforge.net Tue Jul 7 15:43:04 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Tue, 07 Jul 2009 10:43:04 -0500 Subject: an update to automake-1.11? In-Reply-To: <1246937248.1347.2514.camel@localhost> References: <1246385157.8362.127.camel@localhost.localdomain> <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <4A4B82D3.1050407@freenet.de> <4A5287BA.3000504@endoframe.com> <1246937248.1347.2514.camel@localhost> Message-ID: Braden McDaniel wrote: > Breaking compatibility with previous versions of automake, autoconf, or > libtool has no impact on released tarballs made using those tools; they > continue to work as intended because they do not depend on the presence > of these tools. ...but they depend on a slew of *other* things, like a POSIX shell and many POSIX tools. And IIRC I've run into problems when those weren't the /GNU/ versions thereof. There's a lot to be said for /one/ tool that - while, granted, it needs to be installed - not only allows you to build, but also do full development without having to hunt down some precise version thereof, have several versions installed at once, etc. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- You're on your own for the pony. -- Richard Hughes, on feature requests From mschwendt at gmail.com Tue Jul 7 15:47:21 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 07 Jul 2009 15:47:21 -0000 Subject: Broken dependencies in Rawhide - 2009-07-07 Message-ID: <20090707154721.12472.7174@noname> Summary of broken packages (by src.rpm name): bmpx clutter-cairo clutter-cairomm clutter-gst clutter-gtkmm cluttermm CodeAnalyst-gui gauche-gl gauche-gtk ginac kdeedu libchamplain libprojectM libvirt-qpid octave-forge orsa pyclutter pypar python-mwlib python-twitter R-RScaLAPACK rhm rubygem-main showimg springlobby sunbird vtk xfce4-xkb-plugin ====================================================================== Broken packages in fedora-development-i386: CodeAnalyst-gui-2.8.38-12.fc12.i586 requires libbfd-2.19.51.0.2-20.fc12.so R-RScaLAPACK-0.5.1-19.fc11.i586 requires openmpi-libs bmpx-0.40.14-8.fc11.i386 requires libboost_iostreams-mt.so.4 bmpx-0.40.14-8.fc11.i386 requires libboost_regex-mt.so.4 clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gtkmm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gtkmm-0.7.4-2.fc11.i586 requires libclutter-gtk-0.8.so.0 clutter-gtkmm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-gtk-0.8) cluttermm-0.7.5-2.fc11.i586 requires libclutter-glx-0.8.so.0 cluttermm-devel-0.7.5-2.fc11.i586 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.i586 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.i586 requires gauche = 0:0.8.13 ginac-1.5.1-1.fc11.i586 requires libcln.so.5 ginac-utils-1.5.1-1.fc11.i586 requires libcln.so.5 kdeedu-4.2.95-1.fc12.i586 requires libcln.so.5 libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 libvirt-qpid-0.2.14-3.fc12.i586 requires libqpidclient.so.0 libvirt-qpid-0.2.14-3.fc12.i586 requires libqpidcommon.so.0 libvirt-qpid-0.2.14-3.fc12.i586 requires libqmfagent.so.0 octave-forge-20080831-8.fc11.i586 requires libcln.so.5 orsa-0.7.0-8.fc11.i586 requires libcln.so.5 pyclutter-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.i386 requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.i386 requires python(abi) = 0:2.5 python-twitter-0.6-1.fc12.noarch requires /usr/bin/python2.4 rhm-0.5.3153-3.fc12.i586 requires qpidd = 0:0.5.752600 rhm-0.5.3153-3.fc12.i586 requires libqpidbroker.so.0 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.i586 requires libpqxx-2.6.8.so springlobby-0.0.1.10461-1.fc12.i586 requires libtorrent-rasterbar.so.3 thunderbird-lightning-1.0-0.5.20090513hg.fc12.i586 requires thunderbird >= 0:3.0-2.4.b3pre vtk-examples-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 xfce4-xkb-plugin-0.5.2-3.fc11.i586 requires libxklavier.so.12 ====================================================================== Broken packages in fedora-development-ppc: R-RScaLAPACK-0.5.1-19.fc11.ppc requires openmpi-libs bmpx-0.40.14-8.fc11.ppc requires libboost_iostreams-mt.so.4 bmpx-0.40.14-8.fc11.ppc requires libboost_regex-mt.so.4 clutter-cairo-0.8.2-3.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gtkmm-0.7.4-2.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-gtkmm-0.7.4-2.fc11.ppc requires libclutter-gtk-0.8.so.0 clutter-gtkmm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gtkmm-0.7.4-2.fc11.ppc64 requires libclutter-gtk-0.8.so.0()(64bit) clutter-gtkmm-devel-0.7.4-2.fc11.ppc requires pkgconfig(clutter-gtk-0.8) clutter-gtkmm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-gtk-0.8) cluttermm-0.7.5-2.fc11.ppc requires libclutter-glx-0.8.so.0 cluttermm-0.7.5-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) cluttermm-devel-0.7.5-2.fc11.ppc requires pkgconfig(clutter-0.8) cluttermm-devel-0.7.5-2.fc11.ppc64 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.ppc requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.ppc requires gauche = 0:0.8.13 ginac-1.5.1-1.fc11.ppc requires libcln.so.5 ginac-1.5.1-1.fc11.ppc64 requires libcln.so.5()(64bit) ginac-utils-1.5.1-1.fc11.ppc requires libcln.so.5 kdeedu-4.2.95-1.fc12.ppc requires libcln.so.5 kdeedu-4.2.95-1.fc12.ppc64 requires libcln.so.5()(64bit) libchamplain-0.2.9-1.fc11.ppc requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc requires libftgl.so.0 libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) libvirt-qpid-0.2.14-3.fc12.ppc requires libqpidclient.so.0 libvirt-qpid-0.2.14-3.fc12.ppc requires libqpidcommon.so.0 libvirt-qpid-0.2.14-3.fc12.ppc requires libqmfagent.so.0 octave-forge-20080831-8.fc11.ppc requires libcln.so.5 orsa-0.7.0-8.fc11.ppc requires libcln.so.5 orsa-0.7.0-8.fc11.ppc64 requires libcln.so.5()(64bit) pyclutter-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.ppc requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.ppc requires python(abi) = 0:2.5 python-twitter-0.6-1.fc12.noarch requires /usr/bin/python2.4 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc requires libpqxx-2.6.8.so thunderbird-lightning-1.0-0.5.20090513hg.fc12.ppc requires thunderbird >= 0:3.0-2.4.b3pre vtk-examples-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 xfce4-xkb-plugin-0.5.2-3.fc11.ppc requires libxklavier.so.12 ====================================================================== Broken packages in fedora-development-ppc64: R-RScaLAPACK-0.5.1-19.fc11.ppc64 requires openmpi-libs bmpx-0.40.14-8.fc11.ppc64 requires libboost_regex.so.4()(64bit) bmpx-0.40.14-8.fc11.ppc64 requires libboost_iostreams.so.4()(64bit) clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gtkmm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gtkmm-0.7.4-2.fc11.ppc64 requires libclutter-gtk-0.8.so.0()(64bit) clutter-gtkmm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-gtk-0.8) cluttermm-0.7.5-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) cluttermm-devel-0.7.5-2.fc11.ppc64 requires pkgconfig(clutter-0.8) ginac-1.5.1-1.fc11.ppc64 requires libcln.so.5()(64bit) ginac-utils-1.5.1-1.fc11.ppc64 requires libcln.so.5()(64bit) kdeedu-4.2.95-1.fc12.ppc64 requires libcln.so.5()(64bit) libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) libvirt-qpid-0.2.14-3.fc12.ppc64 requires libqmfagent.so.0()(64bit) libvirt-qpid-0.2.14-3.fc12.ppc64 requires libqpidcommon.so.0()(64bit) libvirt-qpid-0.2.14-3.fc12.ppc64 requires libqpidclient.so.0()(64bit) octave-forge-20080831-8.fc11.ppc64 requires libcln.so.5()(64bit) orsa-0.7.0-8.fc11.ppc64 requires libcln.so.5()(64bit) pyclutter-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires python(abi) = 0:2.5 python-mwlib-0.11.2-2.20090522hg2956.fc12.ppc64 requires LabPlot python-twitter-0.6-1.fc12.noarch requires /usr/bin/python2.4 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc64 requires libpqxx-2.6.8.so()(64bit) thunderbird-lightning-1.0-0.5.20090513hg.fc12.ppc64 requires thunderbird >= 0:3.0-2.4.b3pre vtk-examples-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 xfce4-xkb-plugin-0.5.2-3.fc11.ppc64 requires libxklavier.so.12()(64bit) ====================================================================== Broken packages in fedora-development-x86_64: CodeAnalyst-gui-2.8.38-12.fc12.i586 requires libbfd-2.19.51.0.2-20.fc12.so CodeAnalyst-gui-2.8.38-12.fc12.x86_64 requires libbfd-2.19.51.0.2-20.fc12.so()(64bit) R-RScaLAPACK-0.5.1-19.fc11.x86_64 requires openmpi-libs bmpx-0.40.14-8.fc11.x86_64 requires libboost_regex.so.4()(64bit) bmpx-0.40.14-8.fc11.x86_64 requires libboost_iostreams.so.4()(64bit) clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-gtkmm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gtkmm-0.7.4-2.fc11.i586 requires libclutter-gtk-0.8.so.0 clutter-gtkmm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gtkmm-0.7.4-2.fc11.x86_64 requires libclutter-gtk-0.8.so.0()(64bit) clutter-gtkmm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-gtk-0.8) clutter-gtkmm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-gtk-0.8) cluttermm-0.7.5-2.fc11.i586 requires libclutter-glx-0.8.so.0 cluttermm-0.7.5-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) cluttermm-devel-0.7.5-2.fc11.i586 requires pkgconfig(clutter-0.8) cluttermm-devel-0.7.5-2.fc11.x86_64 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.x86_64 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.x86_64 requires gauche = 0:0.8.13 ginac-1.5.1-1.fc11.i586 requires libcln.so.5 ginac-1.5.1-1.fc11.x86_64 requires libcln.so.5()(64bit) ginac-utils-1.5.1-1.fc11.x86_64 requires libcln.so.5()(64bit) kdeedu-4.2.95-1.fc12.i586 requires libcln.so.5 kdeedu-4.2.95-1.fc12.x86_64 requires libcln.so.5()(64bit) libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.x86_64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 libprojectM-1.2.0-9.fc11.x86_64 requires libftgl.so.0()(64bit) libvirt-qpid-0.2.14-3.fc12.x86_64 requires libqmfagent.so.0()(64bit) libvirt-qpid-0.2.14-3.fc12.x86_64 requires libqpidcommon.so.0()(64bit) libvirt-qpid-0.2.14-3.fc12.x86_64 requires libqpidclient.so.0()(64bit) octave-forge-20080831-8.fc11.x86_64 requires libcln.so.5()(64bit) orsa-0.7.0-8.fc11.i586 requires libcln.so.5 orsa-0.7.0-8.fc11.x86_64 requires libcln.so.5()(64bit) pyclutter-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires python(abi) = 0:2.5 python-twitter-0.6-1.fc12.noarch requires /usr/bin/python2.4 rhm-0.5.3153-3.fc12.x86_64 requires qpidd = 0:0.5.752600 rhm-0.5.3153-3.fc12.x86_64 requires libqpidbroker.so.0()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.x86_64 requires libpqxx-2.6.8.so()(64bit) springlobby-0.0.1.10461-1.fc12.x86_64 requires libtorrent-rasterbar.so.3()(64bit) thunderbird-lightning-1.0-0.5.20090513hg.fc12.x86_64 requires thunderbird >= 0:3.0-2.4.b3pre vtk-examples-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 xfce4-xkb-plugin-0.5.2-3.fc11.x86_64 requires libxklavier.so.12()(64bit) From kevin.kofler at chello.at Tue Jul 7 16:01:20 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 07 Jul 2009 18:01:20 +0200 Subject: Feature proposal: Extended Life Cycle Support References: <4A4FD09C.7000809@kanarip.com> <20090705002241.3af46c45@fred.camperquake.de> <735309ff3d0ab1e6fc11e146c00fded8@localhost> <1246749194.22032.10.camel@Julians-Notebook> <66bf87684bab0af297fcc12b2f5100f2@localhost> <66ff0543780f93d7f263af099cd22e1d@localhost> <20090705101245.GA10184@jasmine.xos.nl> <4A50815B.7070300@kanarip.com> <1246972046.4725.26.camel@localhost.localdomain> Message-ID: Ding-Yi Chen wrote: > Therefore, I would like to propose an alternative approach, > namely, project Denture. See my blog post for further information: > http://dingyichen.livejournal.com/14055.html > > Any comments? As I've tried to explain to you last time you proposed that approach on your blog, that approach is completely broken by design and cannot work. Please go back to those blog posts and reread my comments. John5432's replies here also point out the issues. For example, you suggest blacklisting qt because of the renames, but that means NO Qt/KDE app can be upgraded to a supported version. (Fedora 8, the last release prior to the renames, is no longer supported.) You'll find that many of the packages you'll want to upgrade won't work because of some blacklisted dependency, and even where they appear to work, they might not actually work (see also John5432's point about unspecified minimum version dependencies). There's no way to just use the packages from a newer distribution on an older one, we have separate branches for a reason, there's no way around them. And your idea of cherry-picking individual packages for upgrading is just unsupportable. Kevin Kofler From kevin.kofler at chello.at Tue Jul 7 16:05:54 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 07 Jul 2009 18:05:54 +0200 Subject: Feature proposal: Extended Life Cycle Support References: <4A4FD09C.7000809@kanarip.com> <1246918076.2965.33.camel@localhost.localdomain> <4A527AB4.7020505@gmail.com> <4A535461.4060406@kanarip.com> Message-ID: Jeroen van Meeuwen wrote: > "Fedora End-Of-Sales" or something (please avoid the Legacy or LTS names). End-Of-Sales doesn't make a lot of sense for something which isn't sold? Kevin Kofler From ville.skytta at iki.fi Tue Jul 7 16:20:27 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 7 Jul 2009 19:20:27 +0300 Subject: an update to automake-1.11? In-Reply-To: References: <1246385157.8362.127.camel@localhost.localdomain> Message-ID: <200907071920.28358.ville.skytta@iki.fi> On Monday 06 July 2009, Kevin Kofler wrote: > Sam Varshavchik wrote: > > But that's what /you/ want to do, not me. Me, I'll just apply a patch to > > the configure script, directly. > > And you'll be violating the GPL (unless you're talking about a > BSD-style-licensed software or configure.ac is explicitly marked with > special permissions). The FSF seems to disagree with that. http://www.gnu.org/software/autoconf/manual/html_node/Distributing.html#Distributing $ sed -ne '4,8 p' configure # this one was generated by autoconf 2.63 # # Copyright (C) 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001, # 2002, 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc. # This configure script is free software; the Free Software Foundation # gives unlimited permission to copy, distribute and modify it. From notting at redhat.com Tue Jul 7 16:25:52 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 7 Jul 2009 12:25:52 -0400 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <4A535461.4060406@kanarip.com> References: <4A4FD09C.7000809@kanarip.com> <1246918076.2965.33.camel@localhost.localdomain> <4A527AB4.7020505@gmail.com> <4A535461.4060406@kanarip.com> Message-ID: <20090707162551.GG12948@nostromo.devel.redhat.com> Jeroen van Meeuwen (kanarip at kanarip.com) said: > For the Bugzilla gurus out there, to what extent is Bugzilla capable to > Assign a bug to the owner of a package for a certain branch? > > Say I file a bug against foo in Fedora 8 now, and have ownership of the > foo package in PackageDB... would the owner of the foo package in Fedora > !8 branches be spammed with the Bugzilla report? Would it end up in > his/her assigned list? Owners are per prodct, not per product + release combination (as I recall.) Bill From braden at endoframe.com Tue Jul 7 16:30:26 2009 From: braden at endoframe.com (Braden McDaniel) Date: Tue, 07 Jul 2009 12:30:26 -0400 Subject: an update to automake-1.11? In-Reply-To: References: <1246385157.8362.127.camel@localhost.localdomain> <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <4A4B82D3.1050407@freenet.de> <4A5287BA.3000504@endoframe.com> <1246937248.1347.2514.camel@localhost> Message-ID: <1246984226.1347.4101.camel@localhost> On Tue, 2009-07-07 at 14:01 +0200, Kevin Kofler wrote: > Braden McDaniel wrote: > > Breaking compatibility with previous versions of automake, autoconf, or > > libtool has no impact on released tarballs made using those tools; they > > continue to work as intended because they do not depend on the presence > > of these tools. As such, I imagine the autotools maintainers do not > > feel so great an obligation to backward compatibility as the CMake > > maintainers might. > > And that's exactly what I'm complaining about. Why in this forum? What do you think you can accomplish by doing that? > You eschewed my question about what the advantage of this way of working is, > in face of the obvious drawbacks, i.e.: The benefits of using software as its authors intend and support are, I hope, obvious. I don't understand the objective of your continued rambling outside those parameters. Your estimation of the build systems used by various packages is completely irrelevant here. Fedora is downstream. If you have issues with the upstream implementation of a package, take it upstream. -- Braden McDaniel From jkeating at redhat.com Tue Jul 7 16:39:00 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 07 Jul 2009 09:39:00 -0700 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <4A535AA8.4020405@kanarip.com> References: <4A4FD09C.7000809@kanarip.com> <1246918076.2965.33.camel@localhost.localdomain> <4A535AA8.4020405@kanarip.com> Message-ID: <1246984740.8303.6.camel@localhost.localdomain> On Tue, 2009-07-07 at 16:24 +0200, Jeroen van Meeuwen wrote: > If you take into account that the proposal concerns security fixes only, > then every update has to be labeled a security update (and preferably > have some kind of CVE/bug# attached??). We would need to think about a > policy for that, agreed. Yeah, if you pick the line at say "critical" then every update would have a CVE, or would be bundled in bodhi with the package that had the CVE. So say webkit needs updating due to a CVE, you would bundle all the dependent packages in the same update, and the whole update itself would have the CVE listing, and would have just once announcement. > > Without a guarantee for stable ABI/API or stable major/minor version > numbers though some updates may have to be pushed as part of the > dependency stack for a given security bug fix -or not. I guess we'll > need to describe how this should be tackled exactly. See above, should be how we do things now, group related updates into a single bodhi submission, and attach the bugs/CVEs to that single submission. > > > * A measure of success. Some way that you can decide whether or not the > > "Feature" has been a success and should be continued, or whether it is a > > failure and shot not be continued, or should be attempted in some other > > way > > > > The measure of success is particularly hard to state in figures. Just > thinking about some measures of success though, it would include; > > - increased participation from the Fedora side of things > - continuous flow of security updates (and bugs against EOS releases solved) > - increased consumption > > and maybe there's more. Number of subscriptions to an announcement / > errata type of mailing list maybe? Number of subscriptions to a ELC SIG > mailing list? Could go by time it takes to get a CVE discovered/fixed, how many are slipping through, karma on the updates, or just mirrormanager hits on the repos. > > > * A timeline to go with the above to review for success/failure > > > > Here's where the initial proposed extension of 6 months kicks in. I > would say our first review is what is now called "Alpha freeze" -the > milestone where Features are checked for their readiness -whether this > proposal ends up being an actual feature or not. I would think 6 months might be a little too short. Why not give it a year? > > > * A responsible body behind the effort to make regular reports to > > FESCo/Board > > > > This is not up to me ;-) I guess we'll hear from FESCo, on whether they > think this is a feature, on whether they think this is in their mandate, > on whether they think this has to go to the Board. You're driving the feature, but don't want to be responsible for the feature? odd? > > > Who is going to track and discover the security issues? > > > > To be determined. Could be delegated to a (dedicated?) small(er) group > of people within the SIG (to be set up) -maybe the not-so-technical??, > or could be a responsible of each individual participating. Ok, so long as your aware that somebody or somebodies will need to monitor the entire package set for CVEs (something we're probably missing to some extent already). -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A 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 braden at endoframe.com Tue Jul 7 16:45:40 2009 From: braden at endoframe.com (Braden McDaniel) Date: Tue, 07 Jul 2009 12:45:40 -0400 Subject: an update to automake-1.11? In-Reply-To: <4A5304AF.3020905@gmail.com> References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <4A527638.1040004@gmail.com> <4A528140.2070100@endoframe.com> <4A528A85.3010704@gmail.com> <1246936191.1347.2466.camel@localhost> <4A5304AF.3020905@gmail.com> Message-ID: <1246985140.1347.4142.camel@localhost> On Tue, 2009-07-07 at 01:17 -0700, Toshio Kuratomi wrote: > On 07/06/2009 08:09 PM, Braden McDaniel wrote: > > On Mon, 2009-07-06 at 16:36 -0700, Toshio Kuratomi wrote: > >> On 07/06/2009 03:57 PM, Braden McDaniel wrote: > >>> On 7/6/09 6:10 PM, Toshio Kuratomi wrote: > >>> > >>> [snip] > >>> > >>>> Introducing side-effects is something to watch out for but > >>>> patching configure instead of the true source is a short term fix, not a > >>>> long term solution. > >>> > >>> *Any* patch should be viewed as a short-term fix. A patch that needs to > >>> persist indefinitely suggests broken maintainership somewhere along the > >>> line--either upstream, of the Fedora package in question, or elsewhere > >>> in Fedora's infrastructure. > >>> > >> But one of those patches is upstreamable and the other is not. > >> The upstreamable patch is a step on the road to the long term fix. The > >> non-upstreamable one is a dead-end. > > > > Creating a patch to configure/Makefile.in in no way precludes a package > > maintainer from sending an analogous patch to configure.ac/Makefile.am > > upstream. So, yes, it's a "dead end" that: > > > > 1. reduces the size of the changeset between the upstream package > > and the one Fedora actually builds and > > 2. improves the resiliency of the package build to changes to > > Fedora's autotools chain. > > > Perhaps but it doesn't decrease the work that the maintainer has to do. It very well might if Fedora upgrades to a new autoconf, automake, or libtool that is not 100% backward compatible with the previous version. Obviously there is a class of Fedora package maintainers who are comfortable incurring that risk and prefer simply to pick up the pieces when such breakage occurs. And then there are those of us who don't mind doing 5-15 minutes of work for the insurance that updates to Fedora's autotools will have no impact on our package's build. -- Braden McDaniel From paragn at fedoraproject.org Tue Jul 7 16:46:59 2009 From: paragn at fedoraproject.org (=?UTF-8?B?UGFyYWcgTijgpKrgpLDgpL7gpZop?=) Date: Tue, 7 Jul 2009 22:16:59 +0530 Subject: Broken dependencies in Rawhide - 2009-07-07 In-Reply-To: <20090707154644.12472.94029@noname> References: <20090707154644.12472.94029@noname> Message-ID: Hi, On Tue, Jul 7, 2009 at 9:16 PM, Michael Schwendt wrote: > The following packages in the repository suffer from broken dependencies: > > package: CodeAnalyst-gui-2.8.38-12.fc12.i586 from fedora-development-i386 > ?unresolved deps: > ? ? libbfd-2.19.51.0.2-20.fc12.so > > package: CodeAnalyst-gui-2.8.38-12.fc12.i586 from fedora-development-x86_64 > ?unresolved deps: > ? ? libbfd-2.19.51.0.2-20.fc12.so > > package: CodeAnalyst-gui-2.8.38-12.fc12.x86_64 from fedora-development-x86_64 > ?unresolved deps: > ? ? libbfd-2.19.51.0.2-20.fc12.so()(64bit) > > I am already facing a lot of problems with my rawhide machine (like X driver, mdns, prelink) so did not get to know that this is broken. This should have already included in daily rawhide report. I am not sure why broken deps report is not getting included in daily rawhide report. Will build this tomorrow. Thanks & Regards, Parag. From debarshi.ray at gmail.com Tue Jul 7 16:56:14 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Tue, 7 Jul 2009 22:26:14 +0530 Subject: Broken dependencies in Rawhide - 2009-07-07 In-Reply-To: References: <20090707154644.12472.94029@noname> Message-ID: <3170f42f0907070956t48eb8f80t45afba37d1ca3578@mail.gmail.com> > This should have already included in daily rawhide report. I am not > sure why broken deps report is not getting included in daily rawhide > report. There is some problem with the script and Jesse is not around to fix it. Cheerio, 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 Tue Jul 7 17:02:34 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 07 Jul 2009 19:02:34 +0200 Subject: an update to automake-1.11? References: <1246385157.8362.127.camel@localhost.localdomain> <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <4A4B82D3.1050407@freenet.de> <4A5287BA.3000504@endoframe.com> <1246937248.1347.2514.camel@localhost> Message-ID: Matthew Woehlke wrote: > ...but they depend on a slew of *other* things, like a POSIX shell and > many POSIX tools. Right. Assuming POSIX in a tool which is supposed to be a portability tool is completely nonsensical and anachronistic, considering the most popular operating system is a proprietary system which does not support POSIX out of the box. For the people on that inferior operating system, installing a POSIX environment is actually harder than installing a simple tool like CMake. And for those of us on a sane operating system, CMake is just one "yum install cmake" away. So what's the point of generating POSIX shell code into each and every tarball? Kevin Kofler From kevin.kofler at chello.at Tue Jul 7 17:03:50 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 07 Jul 2009 19:03:50 +0200 Subject: an update to automake-1.11? References: <1246385157.8362.127.camel@localhost.localdomain> <200907071920.28358.ville.skytta@iki.fi> Message-ID: Ville Skytt? wrote: > The FSF seems to disagree with that. > > http://www.gnu.org/software/autoconf/manual/html_node/Distributing.html#Distributing That applies to the automatically copied shell code, but not necessarily to the code from the original configure.ac. Kevin Kofler From jkeating at redhat.com Tue Jul 7 17:16:42 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 07 Jul 2009 10:16:42 -0700 Subject: Broken dependencies in Rawhide - 2009-07-07 In-Reply-To: <3170f42f0907070956t48eb8f80t45afba37d1ca3578@mail.gmail.com> References: <20090707154644.12472.94029@noname> <3170f42f0907070956t48eb8f80t45afba37d1ca3578@mail.gmail.com> Message-ID: <1246987002.9833.0.camel@localhost.localdomain> On Tue, 2009-07-07 at 22:26 +0530, Debarshi Ray wrote: > > This should have already included in daily rawhide report. I am not > > sure why broken deps report is not getting included in daily rawhide > > report. > > There is some problem with the script and Jesse is not around to fix it. > I'm working on it today. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Tue Jul 7 17:15:03 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 07 Jul 2009 10:15:03 -0700 Subject: an update to automake-1.11? In-Reply-To: <1246985140.1347.4142.camel@localhost> References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <4A527638.1040004@gmail.com> <4A528140.2070100@endoframe.com> <4A528A85.3010704@gmail.com> <1246936191.1347.2466.camel@localhost> <4A5304AF.3020905@gmail.com> <1246985140.1347.4142.camel@localhost> Message-ID: <4A538297.9030505@gmail.com> On 07/07/2009 09:45 AM, Braden McDaniel wrote: > On Tue, 2009-07-07 at 01:17 -0700, Toshio Kuratomi wrote: >> Perhaps but it doesn't decrease the work that the maintainer has to do. > > It very well might if Fedora upgrades to a new autoconf, automake, or > libtool that is not 100% backward compatible with the previous version. > As opposed to having to repatch the configure script everytime upstream makes a new release? And as opposed to specifying BuildRequires: automake10? And as opposed to needing to know that the build breaks so that you can update the patch that you sent to upstream? > Obviously there is a class of Fedora package maintainers who are > comfortable incurring that risk and prefer simply to pick up the pieces > when such breakage occurs. > > And then there are those of us who don't mind doing 5-15 minutes of work > for the insurance that updates to Fedora's autotools will have no impact > on our package's build. > we're arguing over which of these outlooks is correct now because we have different priorities for helping upstream improve their build scripts vs making sure that the Fedora package builds. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jwboyer at gmail.com Tue Jul 7 17:21:30 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 7 Jul 2009 13:21:30 -0400 Subject: Broken dependencies in Rawhide - 2009-07-07 In-Reply-To: References: <20090707154644.12472.94029@noname> Message-ID: <20090707172130.GM19829@hansolo.jdub.homelinux.org> On Tue, Jul 07, 2009 at 10:16:59PM +0530, Parag N(????) wrote: >Hi, > >On Tue, Jul 7, 2009 at 9:16 PM, Michael Schwendt wrote: >> The following packages in the repository suffer from broken dependencies: >> >> package: CodeAnalyst-gui-2.8.38-12.fc12.i586 from fedora-development-i386 >> ?unresolved deps: >> ? ? libbfd-2.19.51.0.2-20.fc12.so >> >> package: CodeAnalyst-gui-2.8.38-12.fc12.i586 from fedora-development-x86_64 >> ?unresolved deps: >> ? ? libbfd-2.19.51.0.2-20.fc12.so >> >> package: CodeAnalyst-gui-2.8.38-12.fc12.x86_64 from fedora-development-x86_64 >> ?unresolved deps: >> ? ? libbfd-2.19.51.0.2-20.fc12.so()(64bit) >> >> > >I am already facing a lot of problems with my rawhide machine (like X >driver, mdns, prelink) so did not get to know that this is broken. >This should have already included in daily rawhide report. I am not >sure why broken deps report is not getting included in daily rawhide >report. There is a bug in the script that generates that. It's being worked on josh From fgfs.stefan at gmail.com Tue Jul 7 17:22:57 2009 From: fgfs.stefan at gmail.com (stefan riemens) Date: Tue, 7 Jul 2009 19:22:57 +0200 Subject: Howto escape # in a spec file Message-ID: Hi all, I need to escape a # character in a spec file, but I can't seem to find how to do that (is it even possible?) See also BZ #508847. There are a couple of .#pfd1.xml like files which need to be rm -f 'd... Thanks, Stefan From kwade at redhat.com Tue Jul 7 07:58:49 2009 From: kwade at redhat.com (Karsten Wade) Date: Tue, 7 Jul 2009 00:58:49 -0700 Subject: relicensing of Fedora wiki/docs (OPL => CC BY SA) Message-ID: <20090707075849.GI15350@calliope.phig.org> This is a policy and licensing change that affects anyone who edits the wiki or otherwise contributes to Fedora documentation. The consensus of the Docs Team, with full Legal support, is to relicense wiki and documentation from the deprecated OPL 1.0 to the CC BY SA 3.0 license. This move brings Fedora on to the mainland of free and open content; tens of millions of pieces of content and media are licensed under the CC BY SA. Our goal is to do the switchover in about 2 weeks (22 July). Because of the larger number of contributors involved (thousands), it is too much effort to contact each contributor (copyright holder) to gain permission to relicense. Instead, we are enacting a clause of the contributors license agreement that grants the Fedora Project permission to relicense (sublicense.) Questions? Discussion? First read this: http://iquaid.org/2009/07/06/why-relicense-fedora-documentation-and-wiki-content/ ... then bring your discussion to fedora-devel-list or fedora-advisory-board. Cheers - Karsten -- Karsten 'quaid' Wade, Community Gardener http://quaid.fedorapeople.org AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jussilehtola at fedoraproject.org Tue Jul 7 17:46:02 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Tue, 07 Jul 2009 19:46:02 +0200 Subject: Broken dependencies in Rawhide - 2009-07-07 In-Reply-To: <20090707154718.12472.80644@noname> References: <20090707154718.12472.80644@noname> Message-ID: <1246988762.16402.4.camel@hawking.theorphys.helsinki.fi> On Tue, 2009-07-07 at 15:47 +0000, Michael Schwendt wrote: > The following packages in the repository suffer from broken dependencies: > > package: pypar-2.1.0_66-3.fc10.i386 from fedora-development-i386 > unresolved deps: > libpython2.5.so.1.0 > python(abi) = 0:2.5 I haven't been able to build the package due to https://bugzilla.redhat.com/show_bug.cgi?id=499851 and have deferred doing a workaround to cope with a problem that is inherently in opempi. And it's not the only one, either: the environment module is messed up, and will override the build environment variables if it is loaded. https://bugzilla.redhat.com/show_bug.cgi?id=476844 Related to this is bug https://bugzilla.redhat.com/show_bug.cgi?id=504357 Openmpi needs some TLC. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From Jochen at herr-schmitt.de Tue Jul 7 17:52:47 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 07 Jul 2009 19:52:47 +0200 Subject: relicensing of Fedora wiki/docs (OPL => CC BY SA) In-Reply-To: <20090707075849.GI15350@calliope.phig.org> References: <20090707075849.GI15350@calliope.phig.org> Message-ID: <4A538B6F.6050209@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 07.07.2009 09:58, schrieb Karsten Wade: > The consensus of the Docs Team, with full Legal support, is to > relicense wiki and documentation from the deprecated OPL 1.0 to the CC > BY SA 3.0 license. This move brings Fedora on to the mainland of free > and open content; tens of millions of pieces of content and media are > licensed under the CC BY SA. > Simple question: What are the main diferences beetween OPL 1.0 and the new CC BY SA 3.0 license. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpTi2YACgkQT2AHK6txfgwqAACghpXpR+0HGwkTxjySxWPqb7zi t/sAnRDWC/0hM4nsEGWV03xiP4Ff/2lH =srYB -----END PGP SIGNATURE----- From jos at xos.nl Tue Jul 7 18:08:52 2009 From: jos at xos.nl (Jos Vos) Date: Tue, 7 Jul 2009 20:08:52 +0200 Subject: Howto escape # in a spec file In-Reply-To: References: Message-ID: <20090707180852.GA11311@jasmine.xos.nl> On Tue, Jul 07, 2009 at 07:22:57PM +0200, stefan riemens wrote: > I need to escape a # character in a spec file, but I can't seem to > find how to do that (is it even possible?) > > See also BZ #508847. There are a couple of .#pfd1.xml like files which > need to be rm -f 'd... On RHEL5 (rpm 4.4.2, if that matters) it all works for me with \#. I don't see the problem. Can you post an almost-empty mini spec file that demonstrates the problem? -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From mtasaka at ioa.s.u-tokyo.ac.jp Tue Jul 7 18:21:20 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 08 Jul 2009 03:21:20 +0900 Subject: Howto escape # in a spec file In-Reply-To: References: Message-ID: <4A539220.9010407@ioa.s.u-tokyo.ac.jp> stefan riemens wrote, at 07/08/2009 02:22 AM +9:00: > Hi all, > > I need to escape a # character in a spec file, but I can't seem to > find how to do that (is it even possible?) > > See also BZ #508847. There are a couple of .#pfd1.xml like files which > need to be rm -f 'd... > > Thanks, Stefan For me using single quotation mark works. Regards, Mamoru From ville.skytta at iki.fi Tue Jul 7 18:42:40 2009 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 7 Jul 2009 21:42:40 +0300 Subject: an update to automake-1.11? In-Reply-To: References: <1246385157.8362.127.camel@localhost.localdomain> <200907071920.28358.ville.skytta@iki.fi> Message-ID: <200907072142.41301.ville.skytta@iki.fi> On Tuesday 07 July 2009, Kevin Kofler wrote: > Ville Skytt? wrote: > > The FSF seems to disagree with that. > > > > http://www.gnu.org/software/autoconf/manual/html_node/Distributing.html#D > >istributing > > That applies to the automatically copied shell code, but not necessarily to > the code from the original configure.ac. Well, the copyright notice at the top of configure (included in my previous mail) pretty clearly tells me what I can do with the script, and who to contact in case I'd disagree or have any questions. From john5342 at googlemail.com Tue Jul 7 18:57:49 2009 From: john5342 at googlemail.com (John5342) Date: Tue, 7 Jul 2009 19:57:49 +0100 Subject: an update to automake-1.11? In-Reply-To: <200907072142.41301.ville.skytta@iki.fi> References: <1246385157.8362.127.camel@localhost.localdomain> <200907071920.28358.ville.skytta@iki.fi> <200907072142.41301.ville.skytta@iki.fi> Message-ID: <6dc6523c0907071157i6d6ec73agaab961320f1216ad@mail.gmail.com> 2009/7/7 Ville Skytt? : > On Tuesday 07 July 2009, Kevin Kofler wrote: >> Ville Skytt? wrote: >> > The FSF seems to disagree with that. >> > >> > http://www.gnu.org/software/autoconf/manual/html_node/Distributing.html#D >> >istributing >> >> That applies to the automatically copied shell code, but not necessarily to >> the code from the original configure.ac. > > Well, the copyright notice at the top of configure (included in my previous > mail) pretty clearly tells me what I can do with the script, and who to > contact in case I'd disagree or have any questions. That might be true but although the header in configure doesn't mention it it is generated based on whats in configure.ac and therefore it could be considered a derivative work. End result is if the package is e.g GPLv2 then configure.ac probably is and it then follows that the generated configure is potentially also GPLv2. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... From rodrigopadula at projetofedora.org Tue Jul 7 19:38:58 2009 From: rodrigopadula at projetofedora.org (Rodrigo Padula de Oliveira) Date: Tue, 07 Jul 2009 16:38:58 -0300 Subject: Keyboard US Internacional In-Reply-To: <4A2FB61F.4030004@projetofedora.org> References: <4A2F3C62.8070504@projetofedora.org> <4A2F8BAB.60603@googlemail.com> <4A2FB61F.4030004@projetofedora.org> Message-ID: <4A53A452.2040808@projetofedora.org> Hello guys. How can we add gtk2-immodules and gtk2-immodule-xim by default in a PT_BR Fedora installation ? We need to correct this problem ASAP for Fedora 10 ,11 and rawhide We are receiving a lot of claims about this problem in Brazilian lists and forum. Bugzilla entry: https://bugzilla.redhat.com/show_bug.cgi?id=505100 Thanks! Em 10-06-2009 10:33, Rodrigo Padula de Oliveira escreveu: > Em 10-06-2009 07:32, Bill Crawford escreveu: >> Rodrigo Padula de Oliveira wrote: >>> Hello Guys! >>> We have a problem with the keyboard Us Internacional. >>> >>> I'm using Fedora 11 in pt_BR >>> >>> Looking the file /lib/kbd/keymaps/i386/qwerty/us-acentos.map.gz, I >>> found this: >>> >>> compose '\'' 'C' to '?' >>> compose '\'' 'c' to '?' >>> >>> This is correct, but, when I press ' + c or ' + C = ? or ?. >>> >>> In portuguese we don't have acent in the c, the correct is ? (C + >>> cedilla) >>> >>> So, how can We fix this problem ? >>> >> >> It's possible (you don't say) that you're experiencing this problem >> within X, not at the console. If so, it's because the compose file has >> '+c = ? (see /usr/share/X11/locale/pt_BR.UTF-8/Compose for details). Try >> composing , (comma) and c. >> > > The error is the same in the console and X. > > rpm -qf /lib/kbd/keymaps/i386/qwerty/us-acentos.map.gz > > The package is kbd-1.15-7.fc11.i586 > > I will report a bug. > -- Rodrigo Padula de Oliveira M.Sc. Student - COPPE/UFRJ Fedora Community Manager - Latin America Red Hat Community and Academy Relations http://www.proyectofedora.org http://twitter.com/rodrigopadula http://www.rodrigopadula.com From rms at 1407.org Tue Jul 7 20:11:27 2009 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Tue, 7 Jul 2009 21:11:27 +0100 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <20090707100239.GC5189@roque.1407.org> Message-ID: <20090707201127.GD5189@roque.1407.org> On Tue, Jul 07, 2009 at 04:06:02PM +0200, drago01 wrote: > On Tue, Jul 7, 2009 at 12:02 PM, Rui Miguel Silva Seabra wrote: > > On Tue, Jul 07, 2009 at 11:07:52AM +0200, drago01 wrote: > >> > The promise makes quite sure to tell you you have no right[1], but you can > >> > infringe that they won't sue *you*[2]. > >> > > >> > [1] => means you can't do it with GPL > >> > >> It explicitly grant this right. > > > > What you're explicitly told s that you won't be sued if you do so without the right. > > > > And you have no right! > > If I told you "you can do whatever you want with this and I won't sue > you" or "you have the right to implement this" > > Where exactly is the difference? In one you can be sued (because it's not only Microsoft who can do that in some jurisdictions) and you're doing something which is illegal. In the other you're lawfully using legally granted rights. Where exactly is the difference? I don't know, what do you think? > > Further down (in the FAQ, outside the promise) you're told you need to get a > > RAND or RAND-Z license to have the rights. > > Source? It's in the FAQ, which you would know by now if you read the promise and the FAQ instead of trusting Microsoft's employees. > > You don't need a lawyer to distinguish between > > ?a) having a right > > or > > ?b) not being sued if you infringe > > > > So what? "not being sued" is the key here... (does not matter how they > phrase it, see above) > > You try to find holes, without backing it up with any citation so sure > you need a lawyer to clarification this. I'm backing it up with what is in the text of the promise, instead of what is in the mouth of marketing agents. Trust whatever you want, but I prefer authoritative texts infinity times more than a marketing agent's tongue. Rui From rms at 1407.org Tue Jul 7 20:12:28 2009 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Tue, 7 Jul 2009 21:12:28 +0100 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: <4A532040.1050704@redhat.com> References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <20090707100239.GC5189@roque.1407.org> <4A532040.1050704@redhat.com> Message-ID: <20090707201228.GE5189@roque.1407.org> On Tue, Jul 07, 2009 at 12:15:28PM +0200, Dodji Seketeli wrote: > Le 07/07/2009 12:02, Rui Miguel Silva Seabra a ?crit : > > > What you're explicitly told s that you won't be sued if you do so without the right. > > > > And you have no right! > > Just to try to understand your point. > > 1/You don't have the rights to do A. > 2/ But you do A, you won't be sued. > > Doesn't that make 1/ irrelevant in practice ? Only if: a) you like doing illegal stuff which might bite your ass later b) the only one suing you would be Microsoft (in some jurisdictions others may do so). Rui From jlaska at redhat.com Tue Jul 7 20:19:03 2009 From: jlaska at redhat.com (James Laska) Date: Tue, 07 Jul 2009 16:19:03 -0400 Subject: Dracut now has a wiki page in the Fedora wiki... In-Reply-To: <1246616296.25852.241.camel@vaio.local.net> References: <4A4D4139.706@hi.is> <1246616296.25852.241.camel@vaio.local.net> Message-ID: <1246997944.3918.333.camel@flatline.devel.redhat.com> On Fri, 2009-07-03 at 11:18 +0100, Adam Williamson wrote: > On Thu, 2009-07-02 at 23:22 +0000, "J?hann B. Gu?mundsson" wrote: > > > It would be nice if someone who actually who's primary language is > > English reviews and fixes potential ken lee entry's i've made. > > I did a copyedit on the page, correcting a few errors, using lists and > templates more consistently, moving most of the 'introduction' into a > named section so it doesn't eat up the entire top of the page, using > links to User pages for the author list and just generally cleaning up. > Hope you find it an improvement. Thanks for working on this! Apologies for late response. One thousand kudos for investing time into these pages! Dracut is scheduled for a August 27, 2009 Fedora Test Day slot (see https://fedoraproject.org/wiki/QA/Fedora_12_test_days). No doubt these pages will prove tremendously useful for the event. Perhaps this can be another selling point for those who wish to create feature pages and seek QA assistance for testing. I've made a minor change to the Dracut/Debugging page to add the TOC back. It makes the content very readable for me, I hope this works for others as well. Thanks, James -------------- next part -------------- A 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 cdahlin at redhat.com Tue Jul 7 20:37:09 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Tue, 07 Jul 2009 16:37:09 -0400 Subject: Dracut now has a wiki page in the Fedora wiki... In-Reply-To: <1246691506.25852.258.camel@vaio.local.net> References: <4A4D4139.706@hi.is> <1246614214.25852.239.camel@vaio.local.net> <20090703200035.GB15962@wolff.to> <1246677544.5270.405.camel@perihelion.bos.jonmasters.org> <1246691506.25852.258.camel@vaio.local.net> Message-ID: <4A53B1F5.2030405@redhat.com> On 07/04/2009 03:11 AM, Adam Williamson wrote: > On Fri, 2009-07-03 at 23:19 -0400, Jon Masters wrote: >> On Fri, 2009-07-03 at 15:00 -0500, Bruno Wolff III wrote: >>> On Fri, Jul 03, 2009 at 10:43:34 +0100, >>> Adam Williamson wrote: >>>> but it's actually a lot less trouble to just do: >>>> >>>> "tar xf dracut-$version.tar.bz2" >>>> >>>> which auto-detects the archive type. It's much easier to just let it be >>>> handled by autodetection, and only bother specifying the archive type >>>> manually if the autodetection trips up. >>> How long has that feature been there? >> I'm as amused as you are that I didn't know about that either (my guess >> is it's been there a while and we're just all stuck in our ways). At >> least we're not stuck in the 1970s and willing to move with the times - >> a lot of people still like to use pipes of the individual utilities ;) > > I only figured it out last year, actually. By accident I think :) Its not there in RHEL 4, its there in RHEL 5. --CJD From ajax at redhat.com Tue Jul 7 20:39:48 2009 From: ajax at redhat.com (Adam Jackson) Date: Tue, 07 Jul 2009 16:39:48 -0400 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: <20090707201127.GD5189@roque.1407.org> References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <20090707100239.GC5189@roque.1407.org> <20090707201127.GD5189@roque.1407.org> Message-ID: <1246999188.25343.8753.camel@atropine.boston.devel.redhat.com> On Tue, 2009-07-07 at 21:11 +0100, Rui Miguel Silva Seabra wrote: > On Tue, Jul 07, 2009 at 04:06:02PM +0200, drago01 wrote: > > On Tue, Jul 7, 2009 at 12:02 PM, Rui Miguel Silva Seabra wrote: > > > On Tue, Jul 07, 2009 at 11:07:52AM +0200, drago01 wrote: > > >> > The promise makes quite sure to tell you you have no right[1], but you can > > >> > infringe that they won't sue *you*[2]. > > >> > > > >> > [1] => means you can't do it with GPL > > >> > > >> It explicitly grant this right. > > > > > > What you're explicitly told s that you won't be sued if you do so without the right. > > > > > > And you have no right! > > > > If I told you "you can do whatever you want with this and I won't sue > > you" or "you have the right to implement this" > > > > Where exactly is the difference? > > In one you can be sued (because it's not only Microsoft who can do that in some > jurisdictions) and you're doing something which is illegal. At the risk of getting bogged down in details: My understanding is that, in such countries, in order to have any standing in such a case, the third party bringing the suit against you would have to have some claim to a grievance against you as a result of your illegal action against Microsoft. I would be delighted to hear a scenario in which you think this could arise. Also, please do remember that it is _not_ in itself illegal to distribute software that embodies someone else's patent. It's only illegal to do so without the owner's consent. If this is _not_ the case in some country, then everyone in that country needs to stop using the Linux kernel right now, because - to pick a trivial example - RCU is definitely patented. I mean, basically you're asserting that - for whatever bizarro country you're talking about - not only can you not waive your own property rights, but other people can be sued for accepting your waiver at face value. Now, there do exist a handful of countries that haven't accepted the Berne Convention, but they tend to be countries with an even weaker notion of copyright... - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From drago01 at gmail.com Tue Jul 7 20:55:15 2009 From: drago01 at gmail.com (drago01) Date: Tue, 7 Jul 2009 22:55:15 +0200 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: <20090707201127.GD5189@roque.1407.org> References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <20090707100239.GC5189@roque.1407.org> <20090707201127.GD5189@roque.1407.org> Message-ID: On Tue, Jul 7, 2009 at 10:11 PM, Rui Miguel Silva Seabra wrote: > On Tue, Jul 07, 2009 at 04:06:02PM +0200, drago01 wrote: >> On Tue, Jul 7, 2009 at 12:02 PM, Rui Miguel Silva Seabra wrote: >> > On Tue, Jul 07, 2009 at 11:07:52AM +0200, drago01 wrote: >> >> > The promise makes quite sure to tell you you have no right[1], but you can >> >> > infringe that they won't sue *you*[2]. >> >> > >> >> > [1] => means you can't do it with GPL >> >> >> >> It explicitly grant this right. >> > >> > What you're explicitly told s that you won't be sued if you do so without the right. >> > >> > And you have no right! >> >> If I told you "you can do whatever you want with this and I won't sue >> you" or "you have the right to implement this" >> >> Where exactly is the difference? > > In one you can be sued (because it's not only Microsoft who can do that in some > jurisdictions) and you're doing something which is illegal. > > In the other you're lawfully using legally granted rights. > > Where exactly is the difference? I don't know, what do you think? In which jurisdictions can somebody sue me because I infringe a US Patent of a different company? And no I am not doing something illegal because the company which holds the patents stated in a legally binding document that I can implement this standards as long as I don't sue them over a patent that is covered by the CP. >> > Further down (in the FAQ, outside the promise) you're told you need to get a >> > RAND or RAND-Z license to have the rights. >> >> Source? > > It's in the FAQ, which you would know by now if you read the promise and the FAQ > instead of trusting Microsoft's employees. I did read the FAQ and I could not find what you are referring to so I asked. But ok lets quote the FAQ: ------------------ Q: Why does Microsoft obtain patents that apply to specifications to which the Community Promise apply? Is that something that others do too? A: Microsoft invests a significant amount of resources in research and development efforts. Like any other company that commits such resources to creating new technologies, Microsoft seeks to protect its investment by obtaining patents on the resulting innovations. At a minimum, patents have value in defending Microsoft with regard to patent infringement claims made by others. Many patent owners use their patents defensively to protect themselves against third-party law suits when they make their patents available under reasonable and non-discriminatory (RAND or RAND-Z) terms and conditions (including promises like the CP). ------------------ (The only text that mentions RAND or RAND-Z) How do you conclude that you need one to get the rights to do anything. They just try to justifity why the filled patents to begin with. There is no "you need a RAND or RAND-Z license to implement the standards that are covered by this promise", no matter how you read it. >> > You don't need a lawyer to distinguish between >> > ?a) having a right >> > or >> > ?b) not being sued if you infringe >> > >> >> So what? "not being sued" is the key here... (does not matter how they >> phrase it, see above) >> >> You try to find holes, without backing it up with any citation so sure >> you need a lawyer to clarification this. > > I'm backing it up with what is in the text of the promise, instead of what > is in the mouth of marketing agents. > > Trust whatever you want, but I prefer authoritative texts infinity times > more than a marketing agent's tongue. No you did not, you are interpreting the text in the way you want. "I don't trust MS so it must have holes", while blindly trusting anybody is wrong, I don't see the point in making up points that do not exits in the text. Neither in the promise itself nor in the FAQ. In order to get 100% clearance consult a lawyer I doubt that any lawyer would interprets it the way you do. From opensource at till.name Tue Jul 7 21:06:53 2009 From: opensource at till.name (Till Maas) Date: Tue, 07 Jul 2009 23:06:53 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <1246984740.8303.6.camel@localhost.localdomain> References: <4A4FD09C.7000809@kanarip.com> <4A535AA8.4020405@kanarip.com> <1246984740.8303.6.camel@localhost.localdomain> Message-ID: <200907072306.58925.opensource@till.name> On Tue July 7 2009, Jesse Keating wrote: > See above, should be how we do things now, group related updates into a > single bodhi submission, and attach the bugs/CVEs to that single > submission. This may be disliked by upstream and others, because it creates bogus security update notification mails, that say that there are security updates for packages that are no security updates, e.g.: https://www.redhat.com/archives/fedora-package-announce/2008- September/msg00723.html Probably these mails are also parsed by third parties, e.g. LWN, because they also repeat that there were security issues in packages that did not have any security issues. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From jkeating at redhat.com Tue Jul 7 21:16:57 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 07 Jul 2009 14:16:57 -0700 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <200907072306.58925.opensource@till.name> References: <4A4FD09C.7000809@kanarip.com> <4A535AA8.4020405@kanarip.com> <1246984740.8303.6.camel@localhost.localdomain> <200907072306.58925.opensource@till.name> Message-ID: <1247001417.2969.5.camel@localhost.localdomain> On Tue, 2009-07-07 at 23:06 +0200, Till Maas wrote: > > This may be disliked by upstream and others, because it creates bogus security > update notification mails, that say that there are security updates for > packages that are no security updates, e.g.: > https://www.redhat.com/archives/fedora-package-announce/2008- > September/msg00723.html > > Probably these mails are also parsed by third parties, e.g. LWN, because they > also repeat that there were security issues in packages that did not have any > security issues. Why was this update marked as security, but not bundled with the package that actually had the security issue that you were rebuilding for? When the entire list of packages is in one email then it makes sense. Such as https://rhn.redhat.com/errata/RHSA-2009-1095.html where all the packages are listed under one announcement instead of individually. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Tue Jul 7 21:33:44 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 07 Jul 2009 23:33:44 +0200 Subject: an update to automake-1.11? References: <1246385157.8362.127.camel@localhost.localdomain> <200907071920.28358.ville.skytta@iki.fi> <200907072142.41301.ville.skytta@iki.fi> Message-ID: Ville Skytt? wrote: > Well, the copyright notice at the top of configure (included in my > previous mail) pretty clearly tells me what I can do with the script, and > who to contact in case I'd disagree or have any questions. The FSF cannot claim copyright over the configure.ac code I or whoever else wrote and which ends up in the configure script, nor grant a license to use it. That copyright notice and license grant only applies to the code portions which are actually under FSF copyright. Kevin Kofler From opensource at till.name Tue Jul 7 21:34:19 2009 From: opensource at till.name (Till Maas) Date: Tue, 07 Jul 2009 23:34:19 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <1247001417.2969.5.camel@localhost.localdomain> References: <4A4FD09C.7000809@kanarip.com> <200907072306.58925.opensource@till.name> <1247001417.2969.5.camel@localhost.localdomain> Message-ID: <200907072334.27335.opensource@till.name> On Tue July 7 2009, Jesse Keating wrote: > Why was this update marked as security, but not bundled with the package > that actually had the security issue that you were rebuilding for? When It was bundled with the packagate that had the security issue: https://admin.fedoraproject.org/updates/F9/FEDORA-2008-7976 > the entire list of packages is in one email then it makes sense. Such > as https://rhn.redhat.com/errata/RHSA-2009-1095.html where all the > packages are listed under one announcement instead of individually. Yes, but Bodhi does not (or did not?) create such announcements. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From kevin.kofler at chello.at Tue Jul 7 21:36:16 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 07 Jul 2009 23:36:16 +0200 Subject: Feature proposal: Extended Life Cycle Support References: <4A4FD09C.7000809@kanarip.com> <4A535AA8.4020405@kanarip.com> <1246984740.8303.6.camel@localhost.localdomain> <200907072306.58925.opensource@till.name> <1247001417.2969.5.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > Why was this update marked as security, but not bundled with the package > that actually had the security issue that you were rebuilding for? When > the entire list of packages is in one email then it makes sense. Such > as https://rhn.redhat.com/errata/RHSA-2009-1095.html where all the > packages are listed under one announcement instead of individually. Because the fedora-package-announce mails are per updated package, not per grouped update. Kevin Kofler From ssorce at redhat.com Tue Jul 7 21:46:23 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 07 Jul 2009 17:46:23 -0400 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: <1246999188.25343.8753.camel@atropine.boston.devel.redhat.com> References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <20090707100239.GC5189@roque.1407.org> <20090707201127.GD5189@roque.1407.org> <1246999188.25343.8753.camel@atropine.boston.devel.redhat.com> Message-ID: <1247003183.6317.143.camel@localhost.localdomain> On Tue, 2009-07-07 at 16:39 -0400, Adam Jackson wrote: > On Tue, 2009-07-07 at 21:11 +0100, Rui Miguel Silva Seabra wrote: > > On Tue, Jul 07, 2009 at 04:06:02PM +0200, drago01 wrote: > > > On Tue, Jul 7, 2009 at 12:02 PM, Rui Miguel Silva Seabra wrote: > > > > On Tue, Jul 07, 2009 at 11:07:52AM +0200, drago01 wrote: > > > >> > The promise makes quite sure to tell you you have no right[1], but you can > > > >> > infringe that they won't sue *you*[2]. > > > >> > > > > >> > [1] => means you can't do it with GPL > > > >> > > > >> It explicitly grant this right. > > > > > > > > What you're explicitly told s that you won't be sued if you do so without the right. > > > > > > > > And you have no right! > > > > > > If I told you "you can do whatever you want with this and I won't sue > > > you" or "you have the right to implement this" > > > > > > Where exactly is the difference? > > > > In one you can be sued (because it's not only Microsoft who can do that in some > > jurisdictions) and you're doing something which is illegal. > > At the risk of getting bogged down in details: My understanding is that, > in such countries, in order to have any standing in such a case, the > third party bringing the suit against you would have to have some claim > to a grievance against you as a result of your illegal action against > Microsoft. I would be delighted to hear a scenario in which you think > this could arise. Unless you are a lawyer that specialize in multiple countries laws I'd avoid commenting one way or another. Of course what you say up to this point is reasonable, but that doesn't mean it's actually true :-) > Also, please do remember that it is _not_ in itself illegal to > distribute software that embodies someone else's patent. It's only > illegal to do so without the owner's consent. If this is _not_ the case > in some country, then everyone in that country needs to stop using the > Linux kernel right now, because - to pick a trivial example - RCU is > definitely patented. > > I mean, basically you're asserting that - for whatever bizarro country > you're talking about - not only can you not waive your own property > rights, but other people can be sued for accepting your waiver at face > value. Now, there do exist a handful of countries that haven't accepted > the Berne Convention, but they tend to be countries with an even weaker > notion of copyright... ... which has nothing to do with patents, or property rights ... SIGH! People, why don't you all stop playing lawyer and wait that some lawyer actually comment on the promise? I guess some organization like the SFLC might be willing to comment if there is enough demand (and maybe they are already working on that). Simo. -- Simo Sorce * Red Hat, Inc * New York From opensource at till.name Tue Jul 7 21:52:11 2009 From: opensource at till.name (Till Maas) Date: Tue, 07 Jul 2009 23:52:11 +0200 Subject: logistics list In-Reply-To: <4A4E75F5.7030402@redhat.com> References: <4A4E75F5.7030402@redhat.com> Message-ID: <200907072352.20000.opensource@till.name> On Fri July 3 2009, John Poelstra wrote: > The logistics at lists.fedoraproject.org mailing list has been created to > meet the requirements discussed here: > http://www.redhat.com/archives/fedora-advisory-board/2009-July/msg00000.htm >l Imho announcement mails should not require someone to read some other discussion to know what the announcement is about. For the interested: it is about mailing list for coordination between the several teams that work on Fedora. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From bill at bfccomputing.com Tue Jul 7 21:55:10 2009 From: bill at bfccomputing.com (Bill McGonigle) Date: Tue, 07 Jul 2009 17:55:10 -0400 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: References: <4A486F85.7000109@gmail.com> Message-ID: <4A53C43E.2030600@bfccomputing.com> On 07/07/2009 04:24 AM, drago01 wrote: > http://port25.technet.com/archive/2009/07/06/the-ecma-c-and-cli-standards.aspx Were there any announcements about their libraries? This sounds like clarification about which parts of .NET they *don't* plan to sue people over. It would have been easy enough to add more to this announcement. With being tied up with ECMA and the various well-publicized efforts to get RAND licenses on them, these aren't the parts most people were worried about. "I promise not to beat you up on any week day that's a Monday, Tuesday, Thursday or Friday." Call me paranoid, but to me this says Wednesday is Win.Forms. I'd be happy to be proven wrong by a subsequent press release - then Fedora [project,users] only need worry about whether Microsoft should be setting technical direction. -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/ Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: bill at bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf From ajax at redhat.com Tue Jul 7 22:04:57 2009 From: ajax at redhat.com (Adam Jackson) Date: Tue, 07 Jul 2009 18:04:57 -0400 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: <1247003183.6317.143.camel@localhost.localdomain> References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <20090707100239.GC5189@roque.1407.org> <20090707201127.GD5189@roque.1407.org> <1246999188.25343.8753.camel@atropine.boston.devel.redhat.com> <1247003183.6317.143.camel@localhost.localdomain> Message-ID: <1247004297.25343.8755.camel@atropine.boston.devel.redhat.com> On Tue, 2009-07-07 at 17:46 -0400, Simo Sorce wrote: > On Tue, 2009-07-07 at 16:39 -0400, Adam Jackson wrote: > > Also, please do remember that it is _not_ in itself illegal to > > distribute software that embodies someone else's patent. It's only > > illegal to do so without the owner's consent. If this is _not_ the case > > in some country, then everyone in that country needs to stop using the > > Linux kernel right now, because - to pick a trivial example - RCU is > > definitely patented. > > > > I mean, basically you're asserting that - for whatever bizarro country > > you're talking about - not only can you not waive your own property > > rights, but other people can be sued for accepting your waiver at face > > value. Now, there do exist a handful of countries that haven't accepted > > the Berne Convention, but they tend to be countries with an even weaker > > notion of copyright... > > ... which has nothing to do with patents, or property rights ... Eek, that's actually a good point, Berne is copyright not patent. Mea culpa. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mrsam at courier-mta.com Tue Jul 7 22:05:47 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Tue, 07 Jul 2009 18:05:47 -0400 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <1246917991.25343.8673.camel@atropine.boston.devel.redhat.com> Message-ID: Kevin Kofler writes: > Sam Varshavchik wrote: >> Which, as I pointed out, is still the case if you were to patch >> configure.ac instead. >> >> But, go ahead and ignore this inconvenient fact, too. > > As I explained (and you ignored), configure.ac tends to change a lot less > between upstream releases, especially with a lot fewer irrelevant changes This may come as a shock to some, but configure does not often change unless configure.ac changes too. So, I'm not sure what does the frequency of changes to configure.ac has to do with anything. > like line number changes or changes in aclocal snippets (because upstream > WILL regenerate the file, not surgically edit it!), so it's a lot less > likely to produce fuzz. 99% of the time when configure changes, it's due to changes in configure.ac. If someone thinks that by patching configure.ac, instead of configure, one achieves tremendous savings in the frequency of needing to rebase one's patches, they're in a desperate need for a reality check. Furthermore, changes to configure.ac will more likely to result in a more frequent manual rebases, where the corresponding changes in configure are far more likely to result in much simpler rebasing that's limited only to eliminating the fuzz. If one patches a line or two in configure.ac, then if the upstream futzes around with a neighboring line, the patch is going to get kicked out, and must be manually rebased. On the other hand, if a corresponding patch was against configure, instead, (and by that I mean a real patch, and not a patch to configure.ac followed by autoconf followed by a diff of the new configure against the old, I hate to explicitly say this, but some folks around here have a mental block on this subject, and can't wrap their brains around the concept of patching configure directly), the corresponding differences in configure would've ended up being hundred of lines apart, resulting in nothing more than some fuzz, that can be automatically updated. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mrsam at courier-mta.com Tue Jul 7 22:07:45 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Tue, 07 Jul 2009 18:07:45 -0400 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> Message-ID: Kevin Kofler writes: > Sam Varshavchik wrote: >> Sure, why not. It just so happens that, not too long ago, I was in an >> analogous position where I had some other package that also built against >> zlib, for $dayjob$. At $dayjob$ we also package free software using a >> scripted reproducible build. Not RPMs, but an analogous process, and at >> $dayjob$, for reasons that are irrelevant, zlib was installed into a >> nonstandard location. > > In CMake, in such a case, you just have to use: > -DCMAKE_PREFIX_PATH="" > It can also be exported as an environment variable. Either way, no changes > to the scripts needed at all. That's great, and if this discussion was about cmake, then this would be a valid point. But, this thread is not about cmake. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mw_triad at users.sourceforge.net Tue Jul 7 22:11:13 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Tue, 07 Jul 2009 17:11:13 -0500 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: <1247003183.6317.143.camel@localhost.localdomain> References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <20090707100239.GC5189@roque.1407.org> <20090707201127.GD5189@roque.1407.org> <1246999188.25343.8753.camel@atropine.boston.devel.redhat.com> <1247003183.6317.143.camel@localhost.localdomain> Message-ID: (Since I see some people here doing it... *cough*Please do not quote my e-mail address unobfuscated in message bodies.*cough* Thank you.) Simo Sorce wrote: > People, why don't you all stop playing lawyer and wait that some lawyer > actually comment on the promise? > > I guess some organization like the SFLC might be willing to comment if > there is enough demand (and maybe they are already working on that). Um... really? You mean they haven't, already? GIYF: http://www.google.com/search?sourceid=mozclient&ie=utf-8&oe=utf-8&q=sflc+microsoft+patent+promise (Granted, much of that is about OOXML, but it seems to be referring to the same OSP, and even so, given the opinion on how poorly OOXML is covered, I doubt M$ would do anything to make the Mono/C#/CLI situation appreciably better.) Oh, and drago01: > I doubt that any lawyer would interprets it the way [Riu does]. I don't about exact agreement with Riu's specific arguments, but they sure don't seem to share /your/ comfort level. Next time, either check that 5 seconds of googling doesn't make you look like you don't know what you are talking about, or else point out why said googling does not invalidate your point :-). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- You're on your own for the pony. -- Richard Hughes, on feature requests From mrsam at courier-mta.com Tue Jul 7 22:13:14 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Tue, 07 Jul 2009 18:13:14 -0400 Subject: an update to automake-1.11? References: <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <4A527638.1040004@gmail.com> <4A528140.2070100@endoframe.com> <4A528A85.3010704@gmail.com> <1246936191.1347.2466.camel@localhost> <20090707095626.GA30095@amd.home.annexia.org> <1246966461.2836.56.camel@blaa> Message-ID: Mark McLoughlin writes: > On Tue, 2009-07-07 at 07:14 -0400, Sam Varshavchik wrote: >> > libguestfs is a case in point - the Debian maintainer builds it from >> > git using some unknown version of autoconf, and I build it on RHEL and >> >> This is a rare exception. > > No, it's a rare exception for project to keep autotools generated files > in version control. > > Yet people still build lots of projects from version control on a > variety of different distros using different versions of autotools. I'm sure that there are some folks who do that. But, the overwhelming majority of folks want to compile some stable result, rather than the greatest and the latest, which may not even compile at all. Presumably, those who want to build straight out of the upstream repo, have sufficient skills and experience to deal with autotools. > I'm also making the point that maintainers build tarballs without paying > much attention to the versions of autotools they're using. I don't get that impression. When I end up upgrading, as a result of the entire distro upgrade, or otherwise, to a new autotools, I make sure that I go through my existing configure scripts with a fine-toothed comb. Every time this happens I always end up tweaking something, making sure to replace obsoleted macros with their replacements, etc? But I can only speak for myself. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mrsam at courier-mta.com Tue Jul 7 22:16:05 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Tue, 07 Jul 2009 18:16:05 -0400 Subject: an update to automake-1.11? References: <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <4A527638.1040004@gmail.com> <4A528140.2070100@endoframe.com> <4A528A85.3010704@gmail.com> <1246936191.1347.2466.camel@localhost> <20090707095626.GA30095@amd.home.annexia.org> <655A2590-9244-48DF-B9F9-899F1F82F09D@j2solutions.net> Message-ID: Jesse Keating writes: > These days distributing via tarball is bizarre. ?Distributed source > control is changing the way that projects work and release. Sure there are > plenty of projects out here that don't work this way but more and more are > headed in this direction.? Yes. If I get the desire to build a new library, or something, I always want to just find the URL to the upstream's source control repo, then check out whatever I find in there, and run with it. I'm confident that I will never have any problems building it, and it won't have any issues. This is the best and the most reliable mechanism of downloading stable code. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rms at 1407.org Tue Jul 7 22:19:26 2009 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Tue, 7 Jul 2009 23:19:26 +0100 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <20090707100239.GC5189@roque.1407.org> <20090707201127.GD5189@roque.1407.org> Message-ID: <20090707221926.GF5189@roque.1407.org> Note: this is my last email on this thread On Tue, Jul 07, 2009 at 10:55:15PM +0200, drago01 wrote: > >> > What you're explicitly told s that you won't be sued if you do so without the right. > >> > > >> > And you have no right! > >> > >> If I told you "you can do whatever you want with this and I won't sue > >> you" or "you have the right to implement this" > >> > >> Where exactly is the difference? > > > > In one you can be sued (because it's not only Microsoft who can do that in some > > jurisdictions) and you're doing something which is illegal. > > > > In the other you're lawfully using legally granted rights. > > > > Where exactly is the difference? I don't know, what do you think? > > In which jurisdictions can somebody sue me because I infringe a US > Patent of a different company? Who told you only US patents are involved? > And no I am not doing something illegal because the company which > holds the patents stated in a legally binding document that I can > implement this standards as long as I don't sue them over a patent > that is covered by the CP. Yes, you're possibly doing something illegal, in the US it's called patent infringement. They just "promised" (and their word is worthless in this regard) not to sue you. > >> > Further down (in the FAQ, outside the promise) you're told you need to get a > >> > RAND or RAND-Z license to have the rights. > >> > >> Source? > > > > It's in the FAQ, which you would know by now if you read the promise and the FAQ > > instead of trusting Microsoft's employees. > > I did read the FAQ and I could not find what you are referring to so I > asked. But ok lets quote the FAQ: > > ------------------ > Q: Why does Microsoft obtain patents that apply to specifications to > which the Community Promise apply? Is that something that others do > too? > > A: Microsoft invests a significant amount of resources in research and > development efforts. Like any other company that commits such > resources to creating new technologies, Microsoft seeks to protect its > investment by obtaining patents on the resulting innovations. At a > minimum, patents have value in defending Microsoft with regard to > patent infringement claims made by others. Many patent owners use > their patents defensively to protect themselves against third-party > law suits when they make their patents available under reasonable and > non-discriminatory (RAND or RAND-Z) terms and conditions (including > promises like the CP). > ------------------ > > (The only text that mentions RAND or RAND-Z) > > How do you conclude that you need one to get the rights to do anything. Two things: 1) they told so in several TC that analysed MS-OOXML, and even *promised* to bring these terms to the TCs. Guess what? The promise was worthless. they *promised* to get these terms to some companies. Where are the terms? Microsoft doesn't even answer anymore. and 2) Because, as the *promise* quite clearly tells you so: No other rights except those expressly stated in this promise shall be deemed granted, waived or received by implication, exhaustion, estoppel, or otherwise. Since they don't give you a license (just promise not to sue) you haven't got any right. The FAQ subtly reveals there's RAND or RAND-Z terms, and tries to fool you into believing "not suing" == "granting rights" In a couple of years Microsoft is bought by Fu-Bar Inc and there goes the promise down the drain. > They just try to justifity why the filled patents to begin with. You think filing software patents is correct? It may be legal in the US and a few other countries, but while filing a few software patents in the US may be viewed as a defense strategy in a software patent infected country, filing them by the thousands, even in countries where they're invalid, but you'll still have to pay possibly hundreds of thousands of Euros to prove that. > > I'm backing it up with what is in the text of the promise, instead of what > > is in the mouth of marketing agents. > > > > Trust whatever you want, but I prefer authoritative texts infinity times > > more than a marketing agent's tongue. > > No you did not, you are interpreting the text in the way you want. > "I don't trust MS so it must have holes", while blindly trusting > anybody is wrong, I don't see the point in making up points that do > not exits in the text. And I don't see the point of scorning someone by implying they blindly mistrust Microsoft. It's not blind mistrust, the reality is filled with enough fishy things to give the benefit of doubt. Proof is needed. > Neither in the promise itself nor in the FAQ. > > In order to get 100% clearance consult a lawyer I doubt that any > lawyer would interprets it the way you do. Funny enough we tried to get a lawyer team to analyse this problem in Portugal. Microsoft, as president of the TC, chose the firm (a firm they have ties with, how un-surpriseing), and you know what they did? They acknowledged our question, decided to invent a new question, and then answered this new question. You know what our question was? Whether that promise was a legally valid patent license grant (in shorter words). They turned the question into "is the promise valid?" with the result being "in principle yes, but the courts will have the final word". Now, if they want to avoid it this hard, do you think it's because they have honesty in their words? Rui From drago01 at gmail.com Tue Jul 7 22:20:16 2009 From: drago01 at gmail.com (drago01) Date: Wed, 8 Jul 2009 00:20:16 +0200 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <20090707100239.GC5189@roque.1407.org> <20090707201127.GD5189@roque.1407.org> <1246999188.25343.8753.camel@atropine.boston.devel.redhat.com> <1247003183.6317.143.camel@localhost.localdomain> Message-ID: On Wed, Jul 8, 2009 at 12:11 AM, Matthew Woehlke<> wrote: > (Since I see some people here doing it... *cough*Please do not quote my > e-mail address unobfuscated in message bodies.*cough* Thank you.) > > Simo Sorce wrote: >> >> People, why don't you all stop playing lawyer and wait that some lawyer >> actually comment on the promise? >> >> I guess some organization like the SFLC might be willing to comment if >> there is enough demand (and maybe they are already working on that). > > Um... really? You mean they haven't, already? > > GIYF: > > http://www.google.com/search?sourceid=mozclient&ie=utf-8&oe=utf-8&q=sflc+microsoft+patent+promise > > (Granted, much of that is about OOXML, but it seems to be referring to the > same OSP, and even so, given the opinion on how poorly OOXML is covered, I > doubt M$ would do anything to make the Mono/C#/CLI situation appreciably > better.) No its not the same "Open Specification Promise" != "Community Promise" > Oh, and drago01: >> >> I doubt that any lawyer would interprets it the way [Riu does]. > > I don't about exact agreement with Riu's specific arguments, but they sure > don't seem to share /your/ comfort level. I stated serval times that I am not a laywer and therefore can be wrong, than Riu stated that we don't need laywers because his point is obivious (to him). Besides my personal opinion to this is "I don't give a damn about software patents" (and they are void here anyway). But unfortunatly the US laws suck, and that won't change anytime soon. > Next time, either check that 5 seconds of googling doesn't make you look > like you don't know what you are talking about, or else point out why said > googling does not invalidate your point :-). When providing links make sure that they cover the same topic ;) Because than _you_ look that you have no idea what you are talking about. From mastahnke at gmail.com Tue Jul 7 22:32:23 2009 From: mastahnke at gmail.com (Michael Stahnke) Date: Tue, 7 Jul 2009 17:32:23 -0500 Subject: EPEL Bug Day July 11, 2009 0-23:59 UTC Message-ID: <7874d9dd0907071532u55a53af6nb1156d93ab532141@mail.gmail.com> EPEL bug day is fast approaching and we are looking for your help. This is a chance to get involved with EPEL and help make the overall product a little better. Goal: Reduce or update bugs from EPEL. Strategy: The vast majority of EPEL bugs have been classified loosely into three categories. * ActualBug -- A real bug, often times with upstream software issues, or perhaps packaging dependencies. To triage, see if you can reproduce, ask for more input, and in general see what can be done to fix it. * PackageBranch -- This is a request to get something into EPEL that currently isn't there. To triage, see if the package has been branched in CVS. Perhaps the maintainer simply hasn't built it yet. Or, if it requires dependencies, contact the maintainer for those dependencies, open another bug, and create the proper relationship between them. * UpdatePackage -- Requests to update packages can be difficult in EPEL, but each should be evaluated. Ask for reasons why the update is required (security is an extremely valid reason). Sometimes the old version is no longer maintained upstream, etc. Keep in mind that updates that cause breakage should at least be mentioned on the epel-announce mailing list. Feel free to take a bug and help out. It's a 24 hour event, and we have about 135 bugs. If we can get 6 bugs an hour triage and updated, that would be all of them. Event coordination and collaboration will occur in #epel on irc.freenode.net. (Also you don't have to wait until July 11 to start) More Information: * https://fedoraproject.org/wiki/EPEL_Bug_Day_July_2009 Current Bug List * http://tr.im/epelbugs From jkeating at redhat.com Tue Jul 7 22:33:27 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 07 Jul 2009 15:33:27 -0700 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: References: <4A4FD09C.7000809@kanarip.com> <4A535AA8.4020405@kanarip.com> <1246984740.8303.6.camel@localhost.localdomain> <200907072306.58925.opensource@till.name> <1247001417.2969.5.camel@localhost.localdomain> Message-ID: <1247006007.2969.11.camel@localhost.localdomain> On Tue, 2009-07-07 at 23:36 +0200, Kevin Kofler wrote: > Jesse Keating wrote: > > Why was this update marked as security, but not bundled with the package > > that actually had the security issue that you were rebuilding for? When > > the entire list of packages is in one email then it makes sense. Such > > as https://rhn.redhat.com/errata/RHSA-2009-1095.html where all the > > packages are listed under one announcement instead of individually. > > Because the fedora-package-announce mails are per updated package, not per > grouped update. > > Kevin Kofler > > Perhaps it's time for that to change. Luke? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Jul 7 22:37:45 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 07 Jul 2009 15:37:45 -0700 Subject: an update to automake-1.11? In-Reply-To: References: <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <4A527638.1040004@gmail.com> <4A528140.2070100@endoframe.com> <4A528A85.3010704@gmail.com> <1246936191.1347.2466.camel@localhost> <20090707095626.GA30095@amd.home.annexia.org> <655A2590-9244-48DF-B9F9-899F1F82F09D@j2solutions.net> Message-ID: <1247006265.2969.12.camel@localhost.localdomain> On Tue, 2009-07-07 at 18:16 -0400, Sam Varshavchik wrote: > Jesse Keating writes: > > > These days distributing via tarball is bizarre. Distributed source > > control is changing the way that projects work and release. Sure there are > > plenty of projects out here that don't work this way but more and more are > > headed in this direction. > > Yes. If I get the desire to build a new library, or something, I always want > to just find the URL to the upstream's source control repo, then check out > whatever I find in there, and run with it. I'm confident that I will never > have any problems building it, and it won't have any issues. > > This is the best and the most reliable mechanism of downloading stable code. > Ahem. Tagged releases in source code. Just skipping the step of extracting that into a tarball to pass around. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A 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 mw_triad at users.sourceforge.net Tue Jul 7 22:39:04 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Tue, 07 Jul 2009 17:39:04 -0500 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <20090707100239.GC5189@roque.1407.org> <20090707201127.GD5189@roque.1407.org> <1246999188.25343.8753.camel@atropine.boston.devel.redhat.com> <1247003183.6317.143.camel@localhost.localdomain> Message-ID: drago01 wrote: > On Wed, Jul 8, 2009 at 12:11 AM, Matthew Woehlke<> wrote: (Thank you.) >> http://www.google.com/search?sourceid=mozclient&ie=utf-8&oe=utf-8&q=sflc+microsoft+patent+promise >> >> (Granted, much of that is about OOXML, but it seems to be referring to the >> same OSP, and even so, given the opinion on how poorly OOXML is covered, I >> doubt M$ would do anything to make the Mono/C#/CLI situation appreciably >> better.) > > No its not the same "Open Specification Promise" != "Community Promise" ...but there are certainly people weighing in on both. Hmm, I thought I'd seen an actual statement from SFLC on the CP, but now I can't find it again. Still most of what I saw is others that feel the CP is no better than the OSP (some even said it is worse). Certainly some of the same points apply. >> Oh, and drago01: >>> I doubt that any lawyer would interprets it the way [Riu does]. >> I don't about exact agreement with Riu's specific arguments, but they sure >> don't seem to share /your/ comfort level. > > I stated serval times that I am not a laywer and therefore can be > wrong, than Riu stated that we don't need laywers because his point is > obivious (to him). Fair enough. The point was just that your argument is better if 5 seconds of google doesn't appear to refute it. It was just a friendly suggest on 'how to make a better argument'. > But unfortunatly the US laws suck, and that won't change anytime soon. Unfortunate, yes :-). > When providing links make sure that they cover the same topic ;) > Because than _you_ look that you have no idea what you are talking about. Touch?. (Though my point was partly the obvious google results.) Still, you are right. How about these? http://opendotdotdot.blogspot.com/2009/07/are-microsofts-promises-for-ever.html http://mono-nono.com/2009/07/07/is-it-enough/ -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- You're on your own for the pony. -- Richard Hughes, on feature requests From drago01 at gmail.com Tue Jul 7 22:43:28 2009 From: drago01 at gmail.com (drago01) Date: Wed, 8 Jul 2009 00:43:28 +0200 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: <20090707221926.GF5189@roque.1407.org> References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <20090707100239.GC5189@roque.1407.org> <20090707201127.GD5189@roque.1407.org> <20090707221926.GF5189@roque.1407.org> Message-ID: On Wed, Jul 8, 2009 at 12:19 AM, Rui Miguel Silva Seabra wrote: >> And no I am not doing something illegal because the company which >> holds the patents stated in a legally binding document that I can >> implement this standards as long as I don't sue them over a patent >> that is covered by the CP. > > Yes, you're possibly doing something illegal, in the US it's called > patent infringement. > > They just "promised" (and their word is worthless in this regard) not to sue you. So what about the patents owned by redhat? http://www.redhat.com/legal/patent_policy.html It's also just "promise". You claim that this is a worthless statement, but others (including MS here) claim that this is a legal binding document. So we need a lawyer or better a court decision to clear this up. >> (The only text that mentions RAND or RAND-Z) >> >> How do you conclude that you need one to get the rights to do anything. > > Two things: > > ?1) they told so in several TC that analysed MS-OOXML, and even *promised* > ? ?to bring these terms to the TCs. Guess what? The promise was worthless. Only because it is called "promise" in the sense "we will bring this terms" it is not legaly binding. This document is different. > ? ?they *promised* to get these terms to some companies. Where are the > ? ?terms? Microsoft doesn't even answer anymore. See above. > and > > ?2) Because, as the *promise* quite clearly tells you so: > > ? ? ? ?No other rights except those expressly stated in this promise shall > ? ? ? ?be deemed granted, waived or received by implication, exhaustion, > ? ? ? ?estoppel, or otherwise. Yes but we are talking about the things stated here. > Since they don't give you a license (just promise not to sue) you haven't > got any right. The FAQ subtly reveals there's RAND or RAND-Z terms, and tries > to fool you into believing "not suing" == "granting rights" > > In a couple of years Microsoft is bought by Fu-Bar Inc and there goes the > promise down the drain. Same applies to Redhat. >> They just try to justifity why the filled patents to begin with. > > You think filing software patents is correct? It may be legal in the US and > a few other countries, but while filing a few software patents in the US > may be viewed as a defense strategy in a software patent infected country, > filing them by the thousands, even in countries where they're invalid, but > you'll still have to pay possibly hundreds of thousands of Euros to prove > that. Yes it is, even though I think that software patents are a stupid idea and should go away, if the law allows you to fill patents it is broken and needs fixing. Not that companies that file patents are evil. (Even RedHat owns and files softeware patents) >> > I'm backing it up with what is in the text of the promise, instead of what >> > is in the mouth of marketing agents. >> > >> > Trust whatever you want, but I prefer authoritative texts infinity times >> > more than a marketing agent's tongue. >> >> No you did not, you are interpreting the text in the way you want. >> "I don't trust MS so it must have holes", while blindly trusting >> anybody is wrong, I don't see the point in making up points that do >> not exits in the text. > > And I don't see the point of scorning someone by implying they blindly > mistrust Microsoft. It's not blind mistrust, the reality is filled with > enough fishy things to give the benefit of doubt. Proof is needed. " someone by implying they blindly mistrust Microsoft" I never said that but the opposite "while blindly trusting anybody is wrong". Which implies do not trust anybody unless you have a reason. But trying to come up with any unproven statements isn't right either. And again whether this is worth anything has to be judged by a lawyer. >> Neither in the promise itself nor in the FAQ. >> >> In order to get 100% clearance consult a lawyer I doubt that any >> lawyer would interprets it the way you do. > > Funny enough we tried to get a lawyer team to analyse this problem in Portugal. No you did not it was a _different_ (but similar) case. From mw_triad at users.sourceforge.net Tue Jul 7 22:48:02 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Tue, 07 Jul 2009 17:48:02 -0500 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: <20090707221926.GF5189@roque.1407.org> References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <20090707100239.GC5189@roque.1407.org> <20090707201127.GD5189@roque.1407.org> <20090707221926.GF5189@roque.1407.org> Message-ID: Rui Miguel Silva Seabra wrote: > In a couple of years Microsoft is bought by Fu-Bar Inc and there goes the > promise down the drain. ...if only. The odds of *any* company that might buy out M$ (well, if it isn't started by Gates and/or Ballmer and/or such) being as bad as M$ have got to be pretty high ;-). More likely, M$ sells the patents to a puppet company that has made no such promise. Said company happily starts bringing lawsuits. Hey, they've already got Myhrvold (Intellectual Ventures) to sell to, and OIN is useless against a tro^H NPE. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- You're on your own for the pony. -- Richard Hughes, on feature requests From mw_triad at users.sourceforge.net Tue Jul 7 22:59:10 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Tue, 07 Jul 2009 17:59:10 -0500 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <20090707100239.GC5189@roque.1407.org> <20090707201127.GD5189@roque.1407.org> <20090707221926.GF5189@roque.1407.org> Message-ID: drago01 wrote: > So what about the patents owned by redhat? > http://www.redhat.com/legal/patent_policy.html > It's also just "promise". True. However anything RH shipped as GPLv3 that uses a RH patent is no longer a mere promise, it's a legally binding patent license. Something that has yet to come out of M$. (The same can be argued for GPLv2, just that v3 has a "better" license in this regard.) ...and I suspect you'd have more luck getting an actual license from RH if you asked for one. >> In a couple of years Microsoft is bought by Fu-Bar Inc and there goes the >> promise down the drain. > > Same applies to Redhat. The question to ask here is how this applies when an actual license has been granted, as in the case of distributing GPLv3 software. (Especially as I don't see "irrevocable" in Section 11... or, indeed, anything about the term of the GPLv3 implicit patent license. Hmm, this is actually a good question at first glance.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- You're on your own for the pony. -- Richard Hughes, on feature requests From wieseltux23 at gmail.com Tue Jul 7 23:00:57 2009 From: wieseltux23 at gmail.com (DebianTux23) Date: Wed, 8 Jul 2009 01:00:57 +0200 Subject: Do we need split media CDs for F12? In-Reply-To: <4522157.52241245119121121.JavaMail.root@zimbra.cbccgroup.com> References: <21532712.52221245118889992.JavaMail.root@zimbra.cbccgroup.com> <4522157.52241245119121121.JavaMail.root@zimbra.cbccgroup.com> Message-ID: alfinity at boxbe.com On Tue, Jun 16, 2009 at 4:25 AM, Robert 'Bob' Jensen wrote: > Junk Score: 1 out of 10 (below your Auto Allow threshold) | Change: > https://www.boxbe.com/mail-screening&tc=147907721_1484328999 > Approve sender: > https://www.boxbe.com/policy_update?sender=fedora-devel-list%40redhat.com&tc=147907721_1484328999 > Block sender: > https://www.boxbe.com/policy_update?sender=fedora-devel-list%40redhat.com&action=add&disp=b&tc=147907721_1484328999 > ___ > > > > ----- "Jesse Keating" wrote: > > > And this is what pisses me off, and why I say you're holding us > > hostage. > > Whether or not it is a good idea to continue to produce them, you > > don't > > care, you're just going to do it anyway. Great way to run a project. > > > > Jesse, > > Both Fedora Project and Fedora Unity have users that want, need or download > in error CD media. The simple difference in the future of CD media is that > we, Fedora Unity, are choosing to not remove the users freedom of choice. > Giving users freedom of choice is how we run our project. We have faith that > Fedora Project will do what it feels is best for it's contributors and > resources. Independent of what Fedora Project does we also will do what we > feel is best for our users and also keep in mind our resources. No one > should feel they are being held hostage. Without the hard work Fedora > Project puts in to a release and the subsequent updates Fedora Unity could > not produce any media. I feel it is in our best interest to work together to > resolve issues, I have always felt this way, unfortunately history has shown > that this is not often possible. I keep hoping it will someday happen. > > - Bob > > ------------------------------------------------------------------------ > | Robert 'Bob' Jensen || Fedora Unity Founder | > | bob at fedoraunity.org || http://fedoraunity.org/ | > | http://bjensen.fedorapeople.org/ | > | http://blogs.fedoraunity.org/bobjensen | > ------------------------------------------------------------------------ > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > ___ > http://boxbe.com/?tc=147907721_1484328999 | D93HG9EB > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kanarip at kanarip.com Tue Jul 7 23:05:21 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 08 Jul 2009 01:05:21 +0200 Subject: Feature proposal: Extended Life Cycle Support Message-ID: True, but it's a normal term used in life cycle stage descriptions of many products from many vendors. Even though we -as suppliers- do not consider ourselves vendors, frankly it is how a business looks at things (us?) regardless of whether capital venture or operational costs in terms of resources -including money- is/are exchanged, between parties or (internal) departments between whatever and whathaveyou. If they feel they make an effort they feel like it costs them. Entirely different (economical and moral) motivators, different standards. Give or take the few corners I cut here ;-) Let's return to the actual topic, shall we? -- Jeroen @ android Kevin Kofler wrote: >Jeroen van Meeuwen wrote: >> "Fedora End-Of-Sales" or something (please avoid the Legacy or LTS names). > >End-Of-Sales doesn't make a lot of sense for something which isn't sold? > > Kevin Kofler > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-devel-list From mrsam at courier-mta.com Tue Jul 7 23:06:17 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Tue, 07 Jul 2009 19:06:17 -0400 Subject: http://www.fsf.org/news/dont-depend-on-mono References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <20090707100239.GC5189@roque.1407.org> <20090707201127.GD5189@roque.1407.org> <20090707221926.GF5189@roque.1407.org> Message-ID: Matthew Woehlke writes: > Rui Miguel Silva Seabra wrote: >> In a couple of years Microsoft is bought by Fu-Bar Inc and there goes the >> promise down the drain. > > ...if only. The odds of *any* company that might buy out M$ (well, if it > isn't started by Gates and/or Ballmer and/or such) being as bad as M$ > have got to be pretty high ;-). If you want legal advice, pay a lawyer. This is not legal advice. Microsoft's statement is what's generally called "covenant not to sue". When someone buys a business, they buy all the business's assets and liabilities. A covenant not to sue is generally considered a liability, and the covenant not to sue does not get to repudiated just by the virtue of the company changing owners. Having said all that -- I agree that MSFT's promise is not to be given much weight. If MSFT desired to sue someone, I'm sure they'd come up with some way to claim that their cause of action falls outside the scope of this covenant. They have plenty of money to pay lawyers to invent creative arguments, and it will be up to the defendants to prove that MSFT's covenant applies, in their defense. Even better, they'll just get sued for some other reason, like MSFT claiming that they're violating some patent in Windows, and it's just purely by accident, heavens to betsy, that they have a bunch of Mono-based products. Nothing to see here, move along. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rms at 1407.org Tue Jul 7 23:16:11 2009 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Wed, 8 Jul 2009 00:16:11 +0100 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <20090707100239.GC5189@roque.1407.org> <20090707201127.GD5189@roque.1407.org> <20090707221926.GF5189@roque.1407.org> Message-ID: <20090707231611.GG5189@roque.1407.org> Argh... I know I said I wouldn't, but this one really needs to have some scale applied. On Wed, Jul 08, 2009 at 12:43:28AM +0200, drago01 wrote: > > They just "promised" (and their word is worthless in this regard) not to sue you. > > So what about the patents owned by redhat? > http://www.redhat.com/legal/patent_policy.html > It's also just "promise". And it suffers from some of the "promise" and "not license grant" problems as well. But I should point out a few things which must be duly noted in order to understand the scale difference. (1) Red Hat does NOT have a history of attacking Free Software (2) Red Hat does HAVE a history of promoting Free Software with deeds and words (3) Red Hat opposes software patents: ?Red Hat has consistently taken the position that software patents generally impede innovation in software development and that software patents are inconsistent with open source/free software.? -- First phrase in Red Hat's statement of position on software patents. ?A relatively small number of very large companies have amassed large numbers of software patents. We believe such massive software patent portfolios are ripe for misuse because of the questionable nature of many software patents generally and because of the high cost of patent litigation.? (4) Red Hat fully acknowledges the most important Free Software Licenses: ?Approved License means any of the following licenses: GNU General Public License v2.0 and v3.0; GNU Lesser General Public License v2.1 and v3.0, IBM Public License v1.0; Common Public License v1.0; Q Public License v1.0; Open Software License v3.0; and any open source license granted by Red Hat. Red Hat may add to this list in its sole discretion by publication on this page. (5) "any claim" (aka well defined) vs "necessary claims" (aka smoke screen) As such, even though there are problems, Red Hat is a "good citizen", whilst Microsoft is a several times repeating offender. Who would you give the benefit of doubt, and whom would you demand proof from? Rui From wieseltux23 at gmail.com Tue Jul 7 22:59:45 2009 From: wieseltux23 at gmail.com (DebianTux23) Date: Wed, 8 Jul 2009 00:59:45 +0200 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <20090707100239.GC5189@roque.1407.org> <20090707201127.GD5189@roque.1407.org> <20090707221926.GF5189@roque.1407.org> Message-ID: alfinity at boxbe.com On Wed, Jul 8, 2009 at 12:48 AM, Matthew Woehlke < mw_triad at users.sourceforge.net> wrote: > Junk Score: 4 out of 10 (below your Auto Allow threshold) | Change: > https://www.boxbe.com/mail-screening&tc=205147289_978180501 > Approve sender: > https://www.boxbe.com/policy_update?sender=fedora-devel-list%40redhat.com&tc=205147289_978180501 > Block sender: > https://www.boxbe.com/policy_update?sender=fedora-devel-list%40redhat.com&action=add&disp=b&tc=205147289_978180501 > ___ > > > Rui Miguel Silva Seabra wrote: > > In a couple of years Microsoft is bought by Fu-Bar Inc and there goes the > > promise down the drain. > > ...if only. The odds of *any* company that might buy out M$ (well, if it > isn't started by Gates and/or Ballmer and/or such) being as bad as M$ > have got to be pretty high ;-). > > More likely, M$ sells the patents to a puppet company that has made no > such promise. Said company happily starts bringing lawsuits. > > Hey, they've already got Myhrvold (Intellectual Ventures) to sell to, > and OIN is useless against a tro^H NPE. > > -- > Matthew > Please do not quote my e-mail address unobfuscated in message bodies. > -- > You're on your own for the pony. -- Richard Hughes, on feature requests > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > ___ > http://boxbe.com/?tc=205147289_978180501 | D93HG9EB > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Tue Jul 7 23:42:29 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 08 Jul 2009 01:42:29 +0200 Subject: http://www.fsf.org/news/dont-depend-on-mono References: <4A486F85.7000109@gmail.com> <4A53C43E.2030600@bfccomputing.com> Message-ID: Bill McGonigle wrote: > With being tied up with ECMA and the various well-publicized efforts to > get RAND licenses on them, these aren't the parts most people were > worried about. But the thing is, RAND does not necessarily mean royalty-free, let alone compatible with Free Software licenses (no royalty-based patent license is, and even royalty-free ones can have problematic restrictions). RAND just means they won't charge you more just because you like Fedora and hate M$, but it doesn't preclude them from charging a fee from every licensor (which is inherently incompatible with Free Software: while Free Software is about freedom, not cost, having to pay a patent holder for a license is NOT considered Free). Kevin Kofler From kevin.kofler at chello.at Tue Jul 7 23:49:28 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 08 Jul 2009 01:49:28 +0200 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <1246917991.25343.8673.camel@atropine.boston.devel.redhat.com> Message-ID: Sam Varshavchik wrote: > This may come as a shock to some, but configure does not often change > unless configure.ac changes too. > > So, I'm not sure what does the frequency of changes to configure.ac has to > do with anything. Where your argument falls apart is that patch fuzz is a local concept! It's irrelevant that the file is not byte-identical. What matters is whether the context lines directly above and below the line(s) you're patching changed. And that's a lot more likely to happen for configure than for configure.ac. > If someone thinks that by patching configure.ac, instead of configure, one > achieves tremendous savings in the frequency of needing to rebase one's > patches, they're in a desperate need for a reality check. No, they're just more familiar with how patch(1) works than you. > Furthermore, changes to configure.ac will more likely to result in a more > frequent manual rebases, where the corresponding changes in configure are > far more likely to result in much simpler rebasing that's limited only to > eliminating the fuzz. If one patches a line or two in configure.ac, then > if the upstream futzes around with a neighboring line, the patch is going > to get kicked out, and must be manually rebased. On the other hand, if a > corresponding patch was against configure, instead, (and by that I mean a > real patch, and not a patch to configure.ac followed by autoconf followed > by a diff of the new configure against the old, I hate to explicitly say > this, but some folks around here have a mental block on this subject, and > can't wrap their brains around the concept of patching configure > directly), the corresponding differences in configure would've ended up > being hundred of lines apart, resulting in nothing more than some fuzz, > that can be automatically updated. Huh? It's quite the opposite, as those "hundred (sic) of lines" which are inserted automatically (i.e. which do NOT come from configure.ac) are the ones most likely to change, it just takes upstream using a different autoconf (and they WILL do that, it's only in your dream world that all upstreams use a fixed autoconf binary and never change it, only a few projects like GCC do that, and even there, the version changes from time to time) and those lines will be completely different. Kevin Kofler From kevin.kofler at chello.at Tue Jul 7 23:50:41 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 08 Jul 2009 01:50:41 +0200 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> Message-ID: Sam Varshavchik wrote: > That's great, and if this discussion was about cmake, then this would be a > valid point. But, this thread is not about cmake. That CMake has this feature implies that the autotools suck for not having it and forcing you to patch the configure script for your usecase. Kevin Kofler From kevin.kofler at chello.at Tue Jul 7 23:52:28 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 08 Jul 2009 01:52:28 +0200 Subject: an update to automake-1.11? References: <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <4A527638.1040004@gmail.com> <4A528140.2070100@endoframe.com> <4A528A85.3010704@gmail.com> <1246936191.1347.2466.camel@localhost> <20090707095626.GA30095@amd.home.annexia.org> <1246966461.2836.56.camel@blaa> Message-ID: Sam Varshavchik wrote: > I don't get that impression. When I end up upgrading, as a result of the > entire distro upgrade, or otherwise, to a new autotools, I make sure that > I go through my existing configure scripts with a fine-toothed comb. Every > time this happens I always end up tweaking something, making sure to > replace obsoleted macros with their replacements, etc? But I can only > speak for myself. Indeed. I can also only speak for myself, but I just run "autoreconf -i -f" and ignore all the warnings on the autotools-using projects I inherited. Kevin Kofler From jwboyer at gmail.com Wed Jul 8 00:15:19 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 7 Jul 2009 20:15:19 -0400 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <1247006007.2969.11.camel@localhost.localdomain> References: <4A4FD09C.7000809@kanarip.com> <4A535AA8.4020405@kanarip.com> <1246984740.8303.6.camel@localhost.localdomain> <200907072306.58925.opensource@till.name> <1247001417.2969.5.camel@localhost.localdomain> <1247006007.2969.11.camel@localhost.localdomain> Message-ID: <20090708001519.GO19829@hansolo.jdub.homelinux.org> On Tue, Jul 07, 2009 at 03:33:27PM -0700, Jesse Keating wrote: >On Tue, 2009-07-07 at 23:36 +0200, Kevin Kofler wrote: >> Jesse Keating wrote: >> > Why was this update marked as security, but not bundled with the package >> > that actually had the security issue that you were rebuilding for? When >> > the entire list of packages is in one email then it makes sense. Such >> > as https://rhn.redhat.com/errata/RHSA-2009-1095.html where all the >> > packages are listed under one announcement instead of individually. >> >> Because the fedora-package-announce mails are per updated package, not per >> grouped update. >> >> Kevin Kofler >> >> > > >Perhaps it's time for that to change. Luke? I suggest filing a ticket against bodhi instead of assuming this will magically be seen in the middle of a thread. josh From dchen at redhat.com Wed Jul 8 01:07:50 2009 From: dchen at redhat.com (Ding Yi Chen) Date: Tue, 7 Jul 2009 21:07:50 -0400 (EDT) Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <978886840.124441247014779050.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <568583797.124581247015270953.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> ----- "John5342" wrote: > 2009/7/7 Ding-Yi Chen : > > > > ? ??2009-07-07 ? 14:44 +0100?John5342 ??? > >> 2009/7/7 Ding-Yi Chen : > >> > > >> > Any comments? > >> > >> In theory your proposal sounds great but i see just one major flaw > >> that probably doesn't have a solution. Your idea of packages being > >> built based on dependencies should work great apart from the fact > that > >> most packages don't tend to have hard dependencies on versions. > >> Hypothetically in F11 package X-1.2.X relies on package Y-1.2. > Later > >> in the release cycle Y-1.3 is released followed later by X-1.3. > Eve > >> though X-1.3 actually requires Y-1.3 the maintainer probably never > >> thinks to update the required version (assuming there even was one > in > >> the first place). Now your system can easily fail. It picks X-1.3 > from > >> F-11 (because thats the latest one) but Y-1.3 isn't allowed > (because > >> one of its dependencies is black listed) so it falls back to Y-1.2 > >> which was the latest in F-10. Everything builds fine because they > are > >> source compatible but Y-1.2 doesnt have a crucial bug fixed. Now > your > >> software is broken. > > > > All systems have bugs and may break. So you don't use any of them? > :-) > > Of course all systems have bugs. However some are minor whilst others > are so much work to make them usable that they are simply not worth > it. Stuff that requires constant user intervention to cope with > scenarios that cannot be automated is one such major issue. > > > The scenario you raised could happen if not so many people use the > > package X. Otherwise, it would likely be spot by people who use > > yum update X, as Y-1.3 is not dragged in. > > Given X-1.3 is broken without Y-1.3, thus bug will likely be spot. > > Wouldn't be spotted until it is used in your system. It wouldn't be > used during standard usage because in a normal release both would be > updated at the same time (or at least in the right order) so the > scenario never happens. Firstly, not all people turn the automatic upgrade on. Secondly, there are folks use rpm -hiv or build from srpm. In that case, they are more likely to spot the bugs. > > Well, Y depends on black-listed packages doesn't mean Y cannot be > > upgraded at all. As long as the the newer Y does not require higher > > version of black-listed packages. > > Of course Y can be updated but not necessarily to the required > version. If the world was perfect all versions of packages would > contain the exact versions required for things to work and your > proposed system would either update fine or refuse to with a message > if a dependency is blacklisted or unavailable as a recent enough > version. > > However unfortunately for the same reasons i stated already virtually > no package will state the dependant versions accurately enough to do > what you want. If what you said is completely true, I would not even bother to propose Denture. :-) > > ?But if black-listed packages requires Y, or Y is black-listed, > > then Y will not be upgraded. > > In those cases, it is expected behavior that X should not be > upgraded to > > X-1.3 because Y cannot be upgraded to Y-1.3. > > That is of course assuming X-1.3 has an explicit dependency on Y-1.3. > It would be lovely if all packages has these versioned dependencies > and a lot have automatically due to things like sonames but take the > scenario where the soname is the same but the presence of the bug is > not. If X-1.3 does not specify Y-1.3 as dependency, I don't think yum update X will pull Y-1.3, even with the current version. Not to mention people who use rpm directly or build from srpm. So please file bug to X, don't blame Denture. > > Yes, you find out the limitation of Denture, but no, > > Denture is not broken. :-) > > Denture is not broken. Unfortunately though Denture only works in the > ideal world. In reality though scenarios like i just mentioned happen > all the time (along with many other similar issues) and the scenario > i > mentioned would break the users system and Denture has no way of > knowing until it is too late. So do other package managers. Tell me, why are you so sure that the current version packages don't break the system secretly and user and the package managers has no way of knowing until it is too late? > > >> Believe it or not i actually tried something similar for some of > my > >> internal servers and i like the idea but its impossible to get the > >> dependencies right which makes the whole idea a no go. > > > > Believe it or not I actually tried something similar, > > but by hand though. > > > > I agree some maintainers does not accurately specify the > dependency. > > but it is not beyond fix. > > It is not some. It is more like most. How many packages do you see > with the following for every single requires and build requires: > BuildRequires: X-devel = X.X.X-X > Requires: X = X.X.X-X After a quick peek of the packages I maintain or am interested in: 7 packages provide the version info of each dependency. 5 packages provide the version info for some critical package (see dvdauthor.spec for example). 5 packages does not specified it at all. 3 of which are man-pages :-) Only 15% of the packages (exclude the man-pages) does not provide any version information. It may show the laziness of upstream or maintainer, but most of the case, it's meant to work with older version. > And packagers shouldnt have to. What? Why? Does it logical to expect a stable system if critical dependency information is missing? > apart from anything else it would > mean > that every single time somebody rebuilds a package all packages that > depend on it would need rebuilding even if the update is binary > compatible yet at the same time the only way to stop the scenario i > mentioned from happening is to do exactly that. Yes, but let the computer to the rebuilding while you enjoy the result. :-) Is a rebuilding bad thing? According to my FreeBSD experience, not at all. > During a normal release bugs are easily spotted and fixed and > scenarios like i mentioned will mostly never even happen anyway but > mixing packages from different releases will potentially create an > infinite number of combinations and almost certainly break. If this is true, then Denture can happily live with it. Almost certainly break? You mentioned that you did have similar system, if it almost certainly break, how come you still like the idea? BTW, mind sharing your program? :-) -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ From mrsam at courier-mta.com Wed Jul 8 01:10:43 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Tue, 07 Jul 2009 21:10:43 -0400 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <1246917991.25343.8673.camel@atropine.boston.devel.redhat.com> Message-ID: Kevin Kofler writes: > Sam Varshavchik wrote: >> This may come as a shock to some, but configure does not often change >> unless configure.ac changes too. >> >> So, I'm not sure what does the frequency of changes to configure.ac has to >> do with anything. > > Where your argument falls apart is that patch fuzz is a local concept! It's > irrelevant that the file is not byte-identical. What matters is whether the > context lines directly above and below the line(s) you're patching changed. > And that's a lot more likely to happen for configure than for configure.ac. Wrong, as usual. Since each autoconf macro typically expands out to hundreds lines of shellcode, with the autoconf macro's parameter embedded somewhere in the middle of all that stuff, were you to change a parameter to an autoconf macro in configure.ac, and upstream changes the parameter in the next line, your patch gets broken. If the corresponding line in configure ended up getting patched, instead, your patch would still apply, with fuzz, since the results of upstream's changes would be hundreds of shellcode lines away. The patch would still apply. Even if the upstream deleted the preceding, or the succeeding, macro altogether, your patch to configure would still apply, since it patches one line in the middle of several dozens of lines of shellcode, and patch(1) is likely to search for the necessary fuzz. >> If someone thinks that by patching configure.ac, instead of configure, one >> achieves tremendous savings in the frequency of needing to rebase one's >> patches, they're in a desperate need for a reality check. > > No, they're just more familiar with how patch(1) works than you. Yes, tell me again how conflicting patches to neighboring lines in configure.ac "works", while the equivalent two patches hundreds of lines apart in configure do not. > >> Furthermore, changes to configure.ac will more likely to result in a more >> frequent manual rebases, where the corresponding changes in configure are >> far more likely to result in much simpler rebasing that's limited only to >> eliminating the fuzz. If one patches a line or two in configure.ac, then >> if the upstream futzes around with a neighboring line, the patch is going >> to get kicked out, and must be manually rebased. On the other hand, if a >> corresponding patch was against configure, instead, (and by that I mean a >> real patch, and not a patch to configure.ac followed by autoconf followed >> by a diff of the new configure against the old, I hate to explicitly say >> this, but some folks around here have a mental block on this subject, and >> can't wrap their brains around the concept of patching configure >> directly), the corresponding differences in configure would've ended up >> being hundred of lines apart, resulting in nothing more than some fuzz, >> that can be automatically updated. > > Huh? It's quite the opposite, as those "hundred (sic) of lines" which are > inserted automatically (i.e. which do NOT come from configure.ac) are the > ones most likely to change, Perhaps you should actually familiarize yourself with how most autoconf macros work, before you attempt to engage in a deep philosophical discussions on their merits. Stuff like AC_PATH_PROG produces several dozens lines of canned shellcode, with the arguments to AC_PATH_PROG appearing once, in the middle of them. Changing the parameter to AC_PATH_PROG, for example, does not change hundreds of lines of shellcode. This may come as a shock to you, but it does not. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mrsam at courier-mta.com Wed Jul 8 01:11:52 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Tue, 07 Jul 2009 21:11:52 -0400 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> Message-ID: Kevin Kofler writes: > Sam Varshavchik wrote: >> That's great, and if this discussion was about cmake, then this would be a >> valid point. But, this thread is not about cmake. > > That CMake has this feature implies that the autotools suck for not having > it and forcing you to patch the configure script for your usecase. Indeed. Here's an idea -- why don't you mass mail the maintainers of all the autotools-using projects you can find on Sourceforge, and be sure to tell them how much autotools suck, and how better CMake is. I'm sure they will appreciate your helpful suggestions. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mrsam at courier-mta.com Wed Jul 8 01:12:36 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Tue, 07 Jul 2009 21:12:36 -0400 Subject: an update to automake-1.11? References: <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <4A527638.1040004@gmail.com> <4A528140.2070100@endoframe.com> <4A528A85.3010704@gmail.com> <1246936191.1347.2466.camel@localhost> <20090707095626.GA30095@amd.home.annexia.org> <1246966461.2836.56.camel@blaa> Message-ID: Kevin Kofler writes: > Sam Varshavchik wrote: >> I don't get that impression. When I end up upgrading, as a result of the >> entire distro upgrade, or otherwise, to a new autotools, I make sure that >> I go through my existing configure scripts with a fine-toothed comb. Every >> time this happens I always end up tweaking something, making sure to >> replace obsoleted macros with their replacements, etc? But I can only >> speak for myself. > > Indeed. I can also only speak for myself, but I just run "autoreconf -i -f" > and ignore all the warnings on the autotools-using projects I inherited. That's definitely a useful tip -- always ignore warnings. They are always completely meaningless. You don't need to worry about them. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dchen at redhat.com Wed Jul 8 01:59:51 2009 From: dchen at redhat.com (Ding Yi Chen) Date: Tue, 7 Jul 2009 21:59:51 -0400 (EDT) Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <1141049532.126321247017793735.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <294841555.126761247018391415.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> ----- "Kevin Kofler" wrote: > Ding-Yi Chen wrote: > > Therefore, I would like to propose an alternative approach, > > namely, project Denture. See my blog post for further information: > > http://dingyichen.livejournal.com/14055.html > > > > Any comments? > > As I've tried to explain to you last time you proposed that approach > on your > blog, that approach is completely broken by design and cannot work. > Please > go back to those blog posts and reread my comments. John5432's replies > here > also point out the issues. I know what you were saying, but like I said to you: I have such system, I have motivation, I put some effort to try, and I succeed. I know some can be done and some would have serious consequences. You, on the other hand, don't have such motivation, never tried seriously, thus you think everything tend to be broken. :-) > For example, you suggest blacklisting qt because of the renames, but > that > means NO Qt/KDE app can be upgraded to a supported version. (Fedora 8, > the > last release prior to the renames, is no longer supported.) If what you require is the latest Qt/KDE, then you may remove it from black-listed. But mind you, unless you know what you are doing and deal with it carefully, such action will break KDE3 apps such as kbabel. Of course, you can develop an ad-hoc logic for Denture to deal this problem, but currently I have no plan for it. > > You'll find that many of the packages you'll want to upgrade won't > work > because of some blacklisted dependency, I know. I wish IBus can run on RHEL5, but it cannot because it requires Python 2.5. I also know that Denture can tell me that such install/upgrade is not possible unless I remove Python form black-list and face all the consequences. > and even where they appear to > work, > they might not actually work (see also John5432's point about > unspecified minimum version dependencies). If that is the case, either file a bug to the package owners and ask them to correct the minimum version dependencies if the package version is covered by current supported released; or to Denture to override. > There's no way to just use the packages > from > a newer distribution on an older one, we have separate branches for a > reason, there's no way around them. And your idea of cherry-picking > individual packages for upgrading is just unsupportable. Some packages can support the certain older releases, some packages don't. Blindly assuming all package versions can work with older releases will surely fail. Tell Denture your constraint and it will build packages if it can; or reasons why it cannot build. -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ From john5342 at googlemail.com Wed Jul 8 02:00:51 2009 From: john5342 at googlemail.com (John5342) Date: Wed, 8 Jul 2009 03:00:51 +0100 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <568583797.124581247015270953.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <978886840.124441247014779050.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <568583797.124581247015270953.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <6dc6523c0907071900p5006c709qd4297ce041371545@mail.gmail.com> 2009/7/8 Ding Yi Chen : > > ----- "John5342" wrote: > >> 2009/7/7 Ding-Yi Chen : >> > >> > ? ??2009-07-07 ? 14:44 +0100?John5342 ??? >> >> 2009/7/7 Ding-Yi Chen : >> >> > >> >> > Any comments? >> >> >> >> In theory your proposal sounds great but i see just one major flaw >> >> that probably doesn't have a solution. Your idea of packages being >> >> built based on dependencies should work great apart from the fact >> that >> >> most packages don't tend to have hard dependencies on versions. >> >> Hypothetically in F11 package X-1.2.X relies on package Y-1.2. >> Later >> >> in the release cycle Y-1.3 is released followed later by X-1.3. >> Eve >> >> though X-1.3 actually requires Y-1.3 the maintainer probably never >> >> thinks to update the required version (assuming there even was one >> in >> >> the first place). Now your system can easily fail. It picks X-1.3 >> from >> >> F-11 (because thats the latest one) but Y-1.3 isn't allowed >> (because >> >> one of its dependencies is black listed) so it falls back to Y-1.2 >> >> which was the latest in F-10. Everything builds fine because they >> are >> >> source compatible but Y-1.2 doesnt have a crucial bug fixed. Now >> your >> >> software is broken. >> > >> > All systems have bugs and may break. So you don't use any of them? >> :-) >> >> Of course all systems have bugs. However some are minor whilst others >> are so much work to make them usable that they are simply not worth >> it. Stuff that requires constant user intervention to cope with >> scenarios that cannot be automated is one such major issue. >> >> > The scenario you raised could happen if not so many people use the >> > package X. Otherwise, it would likely be spot by people who use >> > yum update X, as Y-1.3 is not dragged in. >> > Given X-1.3 is broken without Y-1.3, thus bug will likely be spot. >> >> Wouldn't be spotted until it is used in your system. It wouldn't be >> used during standard usage because in a normal release both would be >> updated at the same time (or at least in the right order) so the >> scenario never happens. > > Firstly, not all people turn the automatic upgrade on. > Secondly, there are folks use rpm -hiv or build from srpm. > In that case, they are more likely to spot the bugs. I am not talking about upgrades. I am talking about updates. Most people just run updates when packagekit (or similar) tells them to. In a proper release updates are released together. In Denture they will be updated out of order and from various different releases. As for people rebuilding from srpms etc they represent a minority and it is in any case irrelevant. >> > Well, Y depends on black-listed packages doesn't mean Y cannot be >> > upgraded at all. As long as the the newer Y does not require higher >> > version of black-listed packages. >> >> Of course Y can be updated but not necessarily to the required >> version. If the world was perfect all versions of packages would >> contain the exact versions required for things to work and your >> proposed system would either update fine or refuse to with a message >> if a dependency is blacklisted or unavailable as a recent enough >> version. >> >> However unfortunately for the same reasons i stated already virtually >> no package will state the dependant versions accurately enough to do >> what you want. > > If what you said is completely true, I would not even bother to propose Denture. :-) What i said is plain and simple fact. The scenario i mentioned is one of several points of failure. I am not suggesting it is a problem with Denture itself but it is a problem with the real world. Thats just life. >> > ?But if black-listed packages requires Y, or Y is black-listed, >> > then Y will not be upgraded. >> > In those cases, it is expected behavior that X should not be >> upgraded to >> > X-1.3 because Y cannot be upgraded to Y-1.3. >> >> That is of course assuming X-1.3 has an explicit dependency on Y-1.3. >> It would be lovely if all packages has these versioned dependencies >> and a lot have automatically due to things like sonames but take the >> scenario where the soname is the same but the presence of the bug is >> not. > > If X-1.3 does not specify Y-1.3 as dependency, I don't think > yum update X will pull Y-1.3, even with the current version. > Not to mention people who use rpm directly or build from srpm. > So please file bug to X, don't blame Denture. This isn't about whether Y-1.3 will be pulled in. If you do what the vast majority of users do then you will get the equivelant of yum update. Regardless of whether X-1.3 explicitly specifies Y-1.3. Y-1.3 will still be updated siply because there is a later version. When you update using Denture however you could easily end up with X-1.3 and Y-1.2 for any number of reasons. >> > Yes, you find out the limitation of Denture, but no, >> > Denture is not broken. :-) >> >> Denture is not broken. Unfortunately though Denture only works in the >> ideal world. In reality though scenarios like i just mentioned happen >> all the time (along with many other similar issues) and the scenario >> i >> mentioned would break the users system and Denture has no way of >> knowing until it is too late. > > So do other package managers. > Tell me, why are you so sure that the current version packages > don't break the system secretly and user and the package managers > has no way of knowing until it is too late? If you read all i wrote then you will find that has been answered thoroughly already >> >> >> Believe it or not i actually tried something similar for some of >> my >> >> internal servers and i like the idea but its impossible to get the >> >> dependencies right which makes the whole idea a no go. >> > >> > Believe it or not I actually tried something similar, >> > but by hand though. >> > >> > I agree some maintainers does not accurately specify the >> dependency. >> > but it is not beyond fix. >> >> It is not some. It is more like most. How many packages do you see >> with the following for every single requires and build requires: >> BuildRequires: X-devel = X.X.X-X >> Requires: X = X.X.X-X > > After a quick peek of the packages I maintain or am interested in: > > 7 packages provide the version info of each dependency. > 5 packages provide the version info for some critical package (see dvdauthor.spec for example). > 5 packages does not specified it at all. 3 of which are man-pages :-) > > Only 15% of the packages (exclude the man-pages) does not provide any version information. > It may show the laziness of upstream or maintainer, but most of the case, > it's meant to work with older version. You have found the exceptions there. Try looking at some others. >> And packagers shouldnt have to. > > What? Why? Does it logical to expect a stable system if > critical dependency information is missing? I am sure even your dependency versions become stale. Taking your example of dvdauthor BuildRequires: libpng-devel BuildRequires: flex BuildRequires: bison BuildRequires: fribidi-devel BuildRequires: freetype-devel BuildRequires: GraphicsMagick-devel BuildRequires: autoconf automake gettext-devel In a single release you perhaps can be pretty sure that the versions in the build root are good enough to satisfy dvdauthor. If on the other hand you end up with a version of one of these packages from a previous release due to blacklisting then things may well start to break. Would you however insist that all of these are bugs? >> apart from anything else it would >> mean >> that every single time somebody rebuilds a package all packages that >> depend on it would need rebuilding even if the update is binary >> compatible yet at the same time the only way to stop the scenario i >> mentioned from happening is to do exactly that. > > Yes, but let the computer to the rebuilding while you enjoy the result. :-) > Is a rebuilding bad thing? According to my FreeBSD experience, not at all. The result could be great but i can be pretty sure that the actually stability of a partially updated system is probably much worse than rawhide and people who are happy with that level of stability would ore than likely just prefer actual recent release >> During a normal release bugs are easily spotted and fixed and >> scenarios like i mentioned will mostly never even happen anyway but >> mixing packages from different releases will potentially create an >> infinite number of combinations and almost certainly break. > > If this is true, then Denture can happily live with it. > Almost certainly break? You mentioned that > you did have similar system, if it almost certainly break, > how come you still like the idea? I like the idea because the concept is great. The idea that you can run whatever version of whatever package you want and get the best of all worlds is a nice dream but unfortunately i also know that it is only a dream and in real life it simply can't work because the huge requirements that Denture would place on packaging just can't be done. If nothing else because of manpower. Most maintainers wont have time to test every possible combination of versions accross multiple releases just so that Denture stands a chance of working. When i was working on my project i quickly realised that for the reasons i have been trying to explain (falling on deaf ears apparently) and many others besides it simply wasn't feasible. It could be done but the effort of maintaining the fedora packages to a level that would allow Denture to work would probably require double the package maintainers we already have. Good luck with that one. > BTW, mind sharing your program? :-) I probably have it somewhere on backup but i never bother restoring backups of projects that are doomed to failure. If i ever come across the backup i will send it you but i don't see much point in searching through Exabytes of data just for that. I really wish you all the best. I really do. I would love to be surprised and see it work but i won't be holding my breath. Good luck! -- There are 10 kinds of people in the world: Those who understand binary and those who don't... From gmaxwell at gmail.com Wed Jul 8 02:20:19 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Tue, 7 Jul 2009 22:20:19 -0400 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: <1246975543.25343.8712.camel@atropine.boston.devel.redhat.com> References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <1246972758.25343.8680.camel@atropine.boston.devel.redhat.com> <645d17210907070627h426673e8wa1ee2d99fb93492d@mail.gmail.com> <1246975543.25343.8712.camel@atropine.boston.devel.redhat.com> Message-ID: On Tue, Jul 7, 2009 at 10:05 AM, Adam Jackson wrote: [snip] > So, if Frobnitz Inc. distributed Mono, and then filed suit against > Microsoft for infringing one of Frobnitz' patents in the Microsoft C# > implementation, they would lose the right to distribute Mono [1]. [snip] > In other words, it's a MAD agreement. ?You're not even agreeing that any Sadly most MAD agreements are also uni-lateral disarmament agreements. They are only really mutual when the participants are true peers and otherwise magnify existing power imbalances between the parties. Try this alternative scenario: Over time Frobnitz amasses a large portfolio of patents which it places in trust to help defend its free software business. Frobnitz scrupulously avoids encumbered technoligy without irrevocable free software compatible licenses, but it does rely heavily on technology available under terms like the ones under discussion. Later Microsoft initiates spurious patent litigation against Frobnitz which will ultimately fail but cost frobnitz millions in the process (perhaps as part of an attempted takeover). Normally Frobnitz would use its defensive portfolio to discourage this sort of attack, but unfortunately this option has been eliminated because any patent litigation would result in the revocation of permission for several pieces of technology which it is openly and publicly practicing, depends on for compatibility, etc. If Frobnitz doesn't think the MAD-covered patents are valid or applicable and that it could quickly and cheaply fight them, then it doesn't matter much, but in that case it didn't really need the MAD grant at all. If they are valid then frobnitz would be better off if they retained the flexibility of So to sometimes these 'MAD' terms are just 'AD', nothing much mutual about them. Of course, if you aren't the sort that would keep a patent stockpile for defense, the distinction is moot. But, it's still naive to look at that kind of 'MAD' grant as a cure-all. -greg [speaking for no one but himself] From john5342 at googlemail.com Wed Jul 8 02:39:14 2009 From: john5342 at googlemail.com (John5342) Date: Wed, 8 Jul 2009 03:39:14 +0100 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <294841555.126761247018391415.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1141049532.126321247017793735.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <294841555.126761247018391415.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <6dc6523c0907071939w7b4c8851n5793b54ee4ff56c9@mail.gmail.com> 2009/7/8 Ding Yi Chen : > > ----- "Kevin Kofler" wrote: > >> Ding-Yi Chen wrote: >> > Therefore, I would like to propose an alternative approach, >> > namely, project Denture. See my blog post for further information: >> > http://dingyichen.livejournal.com/14055.html >> > >> > Any comments? >> >> As I've tried to explain to you last time you proposed that approach >> on your >> blog, that approach is completely broken by design and cannot work. >> Please >> go back to those blog posts and reread my comments. John5432's replies >> here >> also point out the issues. > > I know what you were saying, but like I said to you: > I have such system, I have motivation, I put some effort to try, and I succeed. > I know some can be done and some would have serious consequences. > You, on the other hand, don't have such motivation, never tried seriously, > thus you think everything tend to be broken. :-) I don't think this has anything to do with motivation. You have an idea and on the face of it it sounds great but even the greatest ideas can be doomed by the details. If you don't believe me (or Kevin) then go for it and when you get to the details you will see exactly what we are talking about. We are simply trying to save you the time. >> For example, you suggest blacklisting qt because of the renames, but >> that >> means NO Qt/KDE app can be upgraded to a supported version. (Fedora 8, >> the >> last release prior to the renames, is no longer supported.) > > If what you require is the latest Qt/KDE, then you may remove it from black-listed. > But mind you, unless you know what you are doing and deal with it carefully, > such action will break KDE3 apps such as kbabel. > > Of course, you can develop an ad-hoc logic for Denture to deal this problem, > but currently I have no plan for it. And if you develop ad-hoc logic (which i had too) which is required for it to come even close to working then who is going to maintain the data that drives this ad-hoc logic? If you think the users will then you are likely wrong because the same people who are capable of helping with this will find it less effort just to use the latest release and build some compatibility packages for the older stuff. >> >> You'll find that many of the packages you'll want to upgrade won't >> work >> because of some blacklisted dependency, > > I know. I wish IBus can run on RHEL5, but it cannot because it requires Python 2.5. > I also know that Denture can tell me that such install/upgrade is not possible > unless I remove Python form black-list and face all the consequences. > >> and even where they appear to >> work, >> they might not actually work (see also John5432's point about >> unspecified ?minimum version dependencies). > > If that is the case, either file a bug to the package owners > and ask them to correct the minimum version dependencies if > the package version is covered by current supported released; > or to Denture to override. First of all that largely wouldnt be possible for your proposal. You also cant account for differences between releases (different releases can have the same version but entirely different features and dependencies). Also minimum versions probably aren't enough. You would also need maximum versions to make your proposal work. >> There's no way to just use the packages >> from >> a newer distribution on an older one, we have separate branches for a >> reason, there's no way around them. And your idea of cherry-picking >> individual packages for upgrading is just unsupportable. > > Some packages can support the certain older releases, some packages don't. > Blindly assuming all package versions can work with older releases will > surely fail. > > Tell Denture your constraint and > it will build packages if it can; or reasons why it cannot build. You clearly don't know how many ways a package can fail. There are a lot of subtle advantages provided by the flow of updates during a release but Denture will be completely and utterly outside those comfortable walls. If you really want a run down of some of the issues you will run into i can provide although i don't think the list is the place for them. I can also tell you the far simpler and more effective solution i came up with for your use case. It is also a frankly much more efficient use of the time. Instead create a program to generate side by side installable packages. Then you can use the latest release with all its features but your old programs that works better on an older Fedora has all the libs it needs to run. The whole concept is more efficient, easier to test, less likely to break systems, less dependent on the user, the type of user in your use case could deal with it more easily, etc and it also covers most of your use cases on your blog. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... From tmz at pobox.com Wed Jul 8 02:41:12 2009 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 7 Jul 2009 22:41:12 -0400 Subject: EPEL Bug Day July 11, 2009 0-23:59 UTC In-Reply-To: <7874d9dd0907071532u55a53af6nb1156d93ab532141@mail.gmail.com> References: <7874d9dd0907071532u55a53af6nb1156d93ab532141@mail.gmail.com> Message-ID: <20090708024112.GA19992@inocybe.localdomain> Michael Stahnke wrote: > Feel free to take a bug and help out. It's a 24 hour event, and we > have about 135 bugs. If we can get 6 bugs an hour triage and > updated, that would be all of them. This is surely a worthy goal, thanks for working on it. I am curious what the plan is for bugs that are already assigned. I have a few bugs on the list that I have assigned to myself (as a co-maintainer of the affected packages) and am working on or testing fixes. I'm not sure that there is much to gain from anyone spending time to triage these bugs, as they're already known and in progress. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A lot of people I know believe in positive thinking, and so do I. I believe everything positively stinks. -- Lew Col -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From mastahnke at gmail.com Wed Jul 8 03:10:16 2009 From: mastahnke at gmail.com (Michael Stahnke) Date: Tue, 7 Jul 2009 22:10:16 -0500 Subject: EPEL Bug Day July 11, 2009 0-23:59 UTC In-Reply-To: <20090708024112.GA19992@inocybe.localdomain> References: <7874d9dd0907071532u55a53af6nb1156d93ab532141@mail.gmail.com> <20090708024112.GA19992@inocybe.localdomain> Message-ID: <7874d9dd0907072010w36ced43am9d780121e95d50be@mail.gmail.com> On Tue, Jul 7, 2009 at 9:41 PM, Todd Zullinger wrote: > Michael Stahnke wrote: >> Feel free to take a bug and help out. ?It's a 24 hour event, and we >> have about 135 bugs. ?If we can get 6 bugs an hour triage and >> updated, that would be all of them. > > This is surely a worthy goal, thanks for working on it. > > I am curious what the plan is for bugs that are already assigned. ?I > have a few bugs on the list that I have assigned to myself (as a > co-maintainer of the affected packages) and am working on or testing > fixes. ?I'm not sure that there is much to gain from anyone spending > time to triage these bugs, as they're already known and in progress. > > -- > Todd ? ? ? ?OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > A lot of people I know believe in positive thinking, and so do I. ?I > believe everything positively stinks. > ? ?-- Lew Col > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Good point and I certainly didn't cover it too well. If you don't need a lot of help on triaging, feel free to offer fixes and closure :) Also, just marking 'triaged' in the Whiteboard field would work. stahnma From dchen at redhat.com Wed Jul 8 04:36:46 2009 From: dchen at redhat.com (Ding Yi Chen) Date: Wed, 8 Jul 2009 00:36:46 -0400 (EDT) Subject: Keyboard US Internacional In-Reply-To: <328179192.129621247027760084.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <128943507.129711247027806955.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> ----- "Rodrigo Padula de Oliveira" wrote: > Hello guys. > > How can we add gtk2-immodules and gtk2-immodule-xim by default in a > PT_BR Fedora installation ? > > We need to correct this problem ASAP for Fedora 10 ,11 and rawhide > > We are receiving a lot of claims about this problem in Brazilian lists > > and forum. > > Bugzilla entry: https://bugzilla.redhat.com/show_bug.cgi?id=505100 > > Thanks! How about adding gtk2-immodules and gtk2-immodule-xim in Portuguese support? -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ From dchen at redhat.com Wed Jul 8 06:11:43 2009 From: dchen at redhat.com (Ding Yi Chen) Date: Wed, 8 Jul 2009 02:11:43 -0400 (EDT) Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <1269451874.132091247033461491.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <329153386.132111247033503865.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> ----- "John5342" wrote: > > Firstly, not all people turn the automatic upgrade on. > > Secondly, there are folks use rpm -hiv or build from srpm. > > In that case, they are more likely to spot the bugs. > > I am not talking about upgrades. I am talking about updates. Most > people just run updates when packagekit (or similar) tells them to. > In > a proper release updates are released together. In Denture they will > be updated out of order and from various different releases. As for > people rebuilding from srpms etc they represent a minority and it is > in any case irrelevant. What you said is true, but since what Denture is for unsupported released, which is unlikely getting any updated. Your case is not suitable for unsupported release. > > If what you said is completely true, I would not even bother to > propose Denture. :-) > > What i said is plain and simple fact. The scenario i mentioned is one > of several points of failure. I am not suggesting it is a problem > with Denture itself but it is a problem with the real world. Thats just > life. But the fact does not cover all packages, so that's why I need Denture, and take the risk. That's also life. :-) > This isn't about whether Y-1.3 will be pulled in. If you do what the > vast majority of users do then you will get the equivelant of yum > update. Regardless of whether X-1.3 explicitly specifies Y-1.3. Y-1.3 > will still be updated siply because there is a later version. When > you > update using Denture however you could easily end up with X-1.3 and > Y-1.2 for any number of reasons. Yes I could hit the bump, so are the guys that using source build and other distribution which have not yet put Y-1.3 to their repos. > > So do other package managers. > > Tell me, why are you so sure that the current version packages > > don't break the system secretly and user and the package managers > > has no way of knowing until it is too late? > > If you read all i wrote then you will find that has been answered > thoroughly already. I also states my justification why the packages should specify the exact depended versions. > You have found the exceptions there. Try looking at some others. I see. What I mainly need Denture help is for end-user applications. I am not quite sure about using Denture for library or toolkit directly. > I am sure even your dependency versions become stale. Taking your > example of dvdauthor > BuildRequires: libpng-devel > BuildRequires: flex > BuildRequires: bison > BuildRequires: fribidi-devel > BuildRequires: freetype-devel > BuildRequires: GraphicsMagick-devel > BuildRequires: autoconf automake gettext-devel > > In a single release you perhaps can be pretty sure that the versions > in the build root are good enough to satisfy dvdauthor. If on the > other hand you end up with a version of one of these packages from a > previous release due to blacklisting then things may well start to > break. > > Would you however insist that all of these are bugs? Mmm, BuildRequires: libdvdread-devel >= 0.9.4-4 BuildRequires: libxml2-devel >= 2.6.0 Without these, dvdauthor might break even within current release. You were saying that version is not important? :-) Nevertheless, you raise a valid point that version information is sometime unavailable or unreliable. But this can be overcome by a datafile that stores correct version. > The result could be great but i can be pretty sure that the actually > stability of a partially updated system is probably much worse than > rawhide and people who are happy with that level of stability would > ore than likely just prefer actual recent release For people who requires absolute stable, they can just use CentOS/ RHEL and totally ignore Denture. Denture is for the people that need to keep some critical packages, but wouldn't mind to take some risk. :-) > I like the idea because the concept is great. The idea that you can > run whatever version of whatever package you want and get the best of > all worlds is a nice dream but unfortunately i also know that it is > only a dream and in real life it simply can't work because the huge > requirements that Denture would place on packaging just can't be > done. "Whatever" is possibly the problem. Denture only eats what it can eat. :-) According to my experience, some of the dreams can come true. > When i was working on my project i quickly realised that for the > reasons i have been trying to explain (falling on deaf ears > apparently). Please don't assume that I am not aware your concerns. Did you see my answers about them? > I really wish you all the best. I really do. I would love to be > surprised and see it work but i won't be holding my breath. Good > luck! Thanks! -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ From dchen at redhat.com Wed Jul 8 06:57:01 2009 From: dchen at redhat.com (Ding Yi Chen) Date: Wed, 8 Jul 2009 02:57:01 -0400 (EDT) Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <277679960.133471247036036893.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1500354367.133571247036221681.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> ----- "John5342" wrote: > 2009/7/8 Ding Yi Chen : > > > I don't think this has anything to do with motivation. You have an > idea and on the face of it it sounds great but even the greatest > ideas > can be doomed by the details. If you don't believe me (or Kevin) then > go for it and when you get to the details you will see exactly what > we > are talking about. We are simply trying to save you the time. You have good deed. But it does not help by simply saying everything break. As I do have some example to break your claim. :-) I would like to know, specifically, what packages did you tried and optionally, why did they fail? > And if you develop ad-hoc logic (which i had too) which is required > for it to come even close to working then who is going to maintain > the > data that drives this ad-hoc logic? If you think the users will then > you are likely wrong because the same people who are capable of > helping with this will find it less effort just to use the latest > release and build some compatibility packages for the older stuff. If nobody is willing to provide sufficient data for the ad-hoc logic, then those packages should be black-listed. > First of all that largely wouldnt be possible for your proposal. You > also cant account for differences between releases (different > releases > can have the same version but entirely different features and > dependencies). I actually encountered the dependency issue you stated. but I've solved that before, and I don't think it is impossible to convert my steps to code. > Also minimum versions probably aren't enough. You would > also need maximum versions to make your proposal work. I've consider that (thus the data file that keep the "correct" dependency), but thanks anyway. You may asked how this data file be generated. Well, at infant stage, it needs to be filled by the early adopters who crush into bugs. You are free to join the data file building. Don't use Denture if you are uncomfortable with that. > You clearly don't know how many ways a package can fail. There are a > lot of subtle advantages provided by the flow of updates during a > release but Denture will be completely and utterly outside those > comfortable walls. Package fails in old releases and current releases. But it's not end of world. Either file bug reports, fix it yourself, find alternative ones that do the same thing, or live with it. Given it's experimental nature, don't use Denture on the packages that is critical to your life, job or other thing you value much. Use Denture on the packages that, "It's good to have, but can live without it." Perhaps that's why I haven't yet got bitten by extra bugs. > If you really want a run down of some of the issues you will run into > i can provide although i don't think the list is the place for them. Please mail me the issues that you encountered. Appreciated. > > I can also tell you the far simpler and more effective solution i > came > up with for your use case. It is also a frankly much more efficient > use of the time. Instead create a program to generate side by side > installable packages. Then you can use the latest release with all > its > features but your old programs that works better on an older Fedora > has all the libs it needs to run. The whole concept is more > efficient, > easier to test, less likely to break systems, less dependent on the > user, the type of user in your use case could deal with it more > easily, etc and it also covers most of your use cases on your blog. I am interested in what you said, what do you mean "side by side"? -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ From mschwendt at gmail.com Wed Jul 8 09:00:21 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 8 Jul 2009 11:00:21 +0200 Subject: poll(), gdb, threads, alsa-lib, deadlock Message-ID: <20090708110021.12ee5076@noname.noname> I'd like another pair of eyes as what I see in a backtrace looks strange. The full backtrace is attached, two excerpts inline below. With Fedora 11 (and never before) I see deadlocks in Audacious occasionally. It's not too easy to reproduce, but starting something resource-hungry while playing ogg/mp3 makes the player hang up occasionally. Two threads enter poll(). One is the Gtk main-loop, the other one the ALSA plugin play-loop that uses alsa-lib. But why does thread #1 (the Gtk main-loop) switch to the same fds array address 0x319ff4 as thread #2? Originally, g_poll() was called with a different pointer 0x8a5fdd8. Why does the fds address change between g_poll() and poll() while the nfds and timeout args stay unchanged? What am I missing here? [Secondly, alsa-lib's snd_pcm_wait calls poll() with an infinite timeout, which looks dangerous. Obviously, one should only do that if there are certain guarantees, but apparently those aren't satisfied here.] Thread 2 (Thread 0xb35ffb70 (LWP 9678)): #0 0x00cd6416 in __kernel_vsyscall () #1 0x00280276 in *__GI___poll (fds=0x319ff4, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 #2 0x063b1215 in snd1_pcm_wait_nocheck (pcm=0xb362c9a0, timeout=-1) at pcm.c:2367 #3 0x063b1403 in snd_pcm_wait (pcm=0xfffffdfc, timeout=-1) at pcm.c:2338 #4 0x063b1592 in snd1_pcm_write_areas (pcm=0xb362c9a0, areas=0xb35fe9e0, offset=0, size=512, func=0x63bd6f0 ) at pcm.c:6646 Thread 1 (Thread 0xb7f3c930 (LWP 9671)): #0 0x00cd6416 in __kernel_vsyscall () #1 0x00280276 in *__GI___poll (fds=0x319ff4, nfds=3, timeout=9) at ../sysdeps/unix/sysv/linux/poll.c:87 #2 0x0070543b in IA__g_poll (fds=0x8a5fdd8, nfds=3, timeout=9) at gpoll.c:127 #3 0x006f81ab in g_main_context_poll (n_fds=, fds=, priority=, timeout=, context=) at gmain.c:2768 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: audacious-deadlock-1.txt URL: From kevin.kofler at chello.at Wed Jul 8 09:12:06 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 08 Jul 2009 11:12:06 +0200 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> Message-ID: Sam Varshavchik wrote: > Indeed. Here's an idea -- why don't you mass mail the maintainers of all > the autotools-using projects you can find on Sourceforge, and be sure to > tell them how much autotools suck, and how better CMake is. I'm sure they > will appreciate your helpful suggestions. Hahaha? Do you have any SERIOUS suggestion on how to bring the deficiencies of the autotools to the attention of upstream maintainers? Of course spamming them won't cut it. Kevin Kofler From kevin.kofler at chello.at Wed Jul 8 09:23:15 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 08 Jul 2009 11:23:15 +0200 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <1246917991.25343.8673.camel@atropine.boston.devel.redhat.com> Message-ID: Sam Varshavchik wrote: > Wrong, as usual. That's an ad hominem "argument". > Since each autoconf macro typically expands out to hundreds lines of > shellcode, But those hundreds of lines of shellcode *CHANGE* with the autoconf and/or aclocal version! Even if upstream changes *nothing* in configure.ac, those lines *will* change whenever they use a different version of the autotools. For most upstreams, that will happen much more often than some actual change in configure.ac in the immediate context of what you're patching. > with the autoconf macro's parameter embedded somewhere in the > middle of all that stuff, were you to change a parameter to an autoconf > macro in configure.ac, and upstream changes the parameter in the next > line, your patch gets broken. Upstream is much less likely to change that parameter in the next line than to use a different version of autoconf. Chances are those context lines won't be touched for YEARS! It's just basic Statistics. > Yes, tell me again how conflicting patches to neighboring lines in > configure.ac "works", while the equivalent two patches hundreds of lines > apart in configure do not. You don't understand me, I'm telling you how patches to configure.ac in an area upstream is unlikely to touch any time soon work, while the equivalent patches in configure get fuzzed by unrelated changes introduced by a new autoconf used by upstream and break. > Stuff like AC_PATH_PROG produces several dozens lines of canned shellcode, > with the arguments to AC_PATH_PROG appearing once, in the middle of them. But those "several dozens lines of canned shellcode" CHANGE WITH THE AUTOCONF VERSION! > Changing the parameter to AC_PATH_PROG, for example, does not change > hundreds of lines of shellcode. No, but using the next point release of autoconf, even with no changes to configure.ac at all, does. Most programmers use fast-moving distros. Distros like Fedora, Debian testing/unstable, Gentoo (even masked packages sometimes) etc. There are even upstream developers using Rawhide! So the version of autoconf upstream is using will change extremely often. Much more often than a 5-line window in configure.ac. Your flawed assumption is that all upstreams are as conservative with autotools upgrades as you are. Kevin Kofler From kevin.kofler at chello.at Wed Jul 8 09:27:06 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 08 Jul 2009 11:27:06 +0200 Subject: an update to automake-1.11? References: <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <4A527638.1040004@gmail.com> <4A528140.2070100@endoframe.com> <4A528A85.3010704@gmail.com> <1246936191.1347.2466.camel@localhost> <20090707095626.GA30095@amd.home.annexia.org> <1246966461.2836.56.camel@blaa> Message-ID: Sam Varshavchik wrote: > That's definitely a useful tip -- always ignore warnings. They are > always completely meaningless. > > You don't need to worry about them. Quit the sarcasm. The thing is: this is how things work in the real world, whether it's a good idea or not. The autotools spit out tons of incomprehensible warnings (e.g. "`foo' should be called before `bar'", but both "foo" and "bar" are called by some canned snippets, not by your own code) for things which previous versions accepted just fine, it's no surprise that maintainers aren't motivated to fix them. Kevin Kofler From kevin.kofler at chello.at Wed Jul 8 09:34:30 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 08 Jul 2009 11:34:30 +0200 Subject: Feature proposal: Extended Life Cycle Support References: <978886840.124441247014779050.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <568583797.124581247015270953.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: Ding Yi Chen wrote: > If X-1.3 does not specify Y-1.3 as dependency, I don't think > yum update X will pull Y-1.3, even with the current version. Selective updates are not really tested in practice and tend not to work. You're expected to get ALL stable updates, not just one. The old RHL advisories made this clear: | Before applying this update, make sure all previously released errata | relevant to your system have been applied. Kevin Kofler From kevin.kofler at chello.at Wed Jul 8 09:37:36 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 08 Jul 2009 11:37:36 +0200 Subject: Feature proposal: Extended Life Cycle Support References: <1141049532.126321247017793735.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <294841555.126761247018391415.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: Ding Yi Chen wrote: > Tell Denture your constraint and > it will build packages if it can; or reasons why it cannot build. The word "build" there is another big fail. Users DO NOT WANT to build their packages from source. If they did, they'd all be using Gentoo! Kevin Kofler From mzerqung at 0pointer.de Wed Jul 8 09:44:15 2009 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 8 Jul 2009 11:44:15 +0200 Subject: ck-list-sessions shows active = false In-Reply-To: References: Message-ID: <20090708094415.GB6981@tango.0pointer.de> On Mon, 06.07.09 09:54, darrell pfeifer (darrellpf at gmail.com) wrote: > Using rawhide and gdm-2.26.1-13.fc12.i586 when I do a ck-list-sessions I see > Session4: > unix-user = '500' > realname = 'darrell pfeifer' > seat = 'Seat5' > session-type = '' > active = FALSE > x11-display = ':0' > x11-display-device = '' > display-device = '' > remote-host-name = '' > is-local = TRUE > on-since = '2009-07-06T15:56:08.908744Z' > login-session-id = '' > > Currently almost all my device-related functionality is not working > (including pulseaudio, mounting usb sticks, starting virtual machines). In > addition, polkit-gnome-authorization and polkit-gnome-authorization are > crashing. > > Am I on the right track thinking that the problem is gdm related? We are currently in the process of moving the device ACL management from HAL to udev. This is not finished yet, at least for the PA case I know that that there is some work left to do to fix udev/ck to make things completely race-free. A temporary work-around for the PA case is to make yourself a member of the "audio" group which then gives you device access regardless if ACLs are set up and work correctly. This will break audio if you have multiple simultaneous session of different users. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From kevin.kofler at chello.at Wed Jul 8 09:42:57 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 08 Jul 2009 11:42:57 +0200 Subject: Feature proposal: Extended Life Cycle Support References: <1269451874.132091247033461491.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <329153386.132111247033503865.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: Ding Yi Chen wrote: > ----- "John5342" wrote: >> I am not talking about upgrades. I am talking about updates. Most >> people just run updates when packagekit (or similar) tells them to. >> In >> a proper release updates are released together. In Denture they will >> be updated out of order and from various different releases. As for >> people rebuilding from srpms etc they represent a minority and it is >> in any case irrelevant. > > What you said is true, but since what Denture is for unsupported > released, which is unlikely getting any updated. Your case is not suitable > for unsupported release. He was just explaining why packages tend not to have versioned dependencies in practice, and still work fine in supported Fedora releases. And you can't expect them to be "fixed" to support unsupported releases, those are unsupported for a reason. > Yes I could hit the bump, so are the guys that using source build and > other distribution which have not yet put Y-1.3 to their repos. Specfiles are per definition distribution-specific. > But this can be overcome by a datafile that stores correct version. Good luck maintaining that monster file! Kevin Kofler From dominik at greysector.net Wed Jul 8 10:28:55 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 8 Jul 2009 12:28:55 +0200 Subject: poll(), gdb, threads, alsa-lib, deadlock In-Reply-To: <20090708110021.12ee5076@noname.noname> References: <20090708110021.12ee5076@noname.noname> Message-ID: <20090708102854.GA16449@mokona.greysector.net> On Wednesday, 08 July 2009 at 11:00, Michael Schwendt wrote: > I'd like another pair of eyes as what I see in a backtrace looks strange. > The full backtrace is attached, two excerpts inline below. > > With Fedora 11 (and never before) I see deadlocks in Audacious > occasionally. It's not too easy to reproduce, but starting something > resource-hungry while playing ogg/mp3 makes the player hang up > occasionally. Actually, I see that on Fedora 10, too. Pressing pause and then play makes it return to normal again, for some time. Not sure if it's the same issue, because only the playback thread seems to hang (as if "pause" was pressed). Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From rjones at redhat.com Wed Jul 8 10:36:12 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 8 Jul 2009 11:36:12 +0100 Subject: an update to automake-1.11? In-Reply-To: References: <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <1246917991.25343.8673.camel@atropine.boston.devel.redhat.com> Message-ID: <20090708103612.GA10438@amd.home.annexia.org> On Tue, Jul 07, 2009 at 06:05:47PM -0400, Sam Varshavchik wrote: > If someone thinks that by patching configure.ac, instead of configure, > one achieves tremendous savings in the frequency of needing to rebase > one's patches, they're in a desperate need for a reality check. No, you are. Please find out how patch works. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.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 mrsam at courier-mta.com Wed Jul 8 11:07:56 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Wed, 08 Jul 2009 07:07:56 -0400 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> Message-ID: Kevin Kofler writes: > Sam Varshavchik wrote: >> Indeed. Here's an idea -- why don't you mass mail the maintainers of all >> the autotools-using projects you can find on Sourceforge, and be sure to >> tell them how much autotools suck, and how better CMake is. I'm sure they >> will appreciate your helpful suggestions. > > Hahaha? Do you have any SERIOUS suggestion on how to bring the deficiencies > of the autotools to the attention of upstream maintainers? Of course > spamming them won't cut it. What's wrong with what I suggested? If you truly believe that cmake is so much better, I'm sure that everyone would be glad to hear it. Go ahead, state your case. I'm the upstream for two packages in Fedora. Make your case. You can start with me. -------------- 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 Jul 8 11:16:56 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 8 Jul 2009 13:16:56 +0200 Subject: poll(), gdb, threads, alsa-lib, deadlock In-Reply-To: <20090708102854.GA16449@mokona.greysector.net> References: <20090708110021.12ee5076@noname.noname> <20090708102854.GA16449@mokona.greysector.net> Message-ID: <20090708131656.73fe05a8@faldor> On Wed, 8 Jul 2009 12:28:55 +0200, Dominik wrote: > On Wednesday, 08 July 2009 at 11:00, Michael Schwendt wrote: > > I'd like another pair of eyes as what I see in a backtrace looks strange. > > The full backtrace is attached, two excerpts inline below. > > > > With Fedora 11 (and never before) I see deadlocks in Audacious > > occasionally. It's not too easy to reproduce, but starting something > > resource-hungry while playing ogg/mp3 makes the player hang up > > occasionally. > > Actually, I see that on Fedora 10, too. Do you remember when you ran into it for the first time? alsa-lib was upgraded for F10 at beginning of May, for example. [Perhaps I need to diff in that area.] On F11 I can downgrade audacious* to the packages before the first set of alsa patches, and the problem is reproducible. The upstream updates 2.0 and 2.1beta1 are not safe, since they contain new problems (and not the latest alsa plugin and even one or a few race conditions). > Pressing pause and then play makes it > return to normal again, for some time. Not sure if it's the same issue, > because only the playback thread seems to hang (as if "pause" was pressed). Very likely it's related -- and yes, in one or two cases I could click stop, too, to end the deadlock. Multiple threads are used and communicate with eachother via glib2 conditions (GCond) and proper mutex locking. Wherever infinite timeouts are used when waiting for conditions and a key thread doesn't return from a syscall, other threads might wait endlessly, too. From mrsam at courier-mta.com Wed Jul 8 11:16:27 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Wed, 08 Jul 2009 07:16:27 -0400 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <1246917991.25343.8673.camel@atropine.boston.devel.redhat.com> Message-ID: Kevin Kofler writes: > Sam Varshavchik wrote: >> Wrong, as usual. > > That's an ad hominem "argument". > >> Since each autoconf macro typically expands out to hundreds lines of >> shellcode, > > But those hundreds of lines of shellcode *CHANGE* with the autoconf and/or > aclocal version! You're changing the topic. On this point, we're not talking about what happens when autoconf changes. Here, the original statement was that patches to configure.ac are less likely to be kicked out than configure, if configure.ac changes. I pointed out that this is completely absurd, and you have no idea how autoconf works. You have no answer, so you must now start talking about what happens when autoconf itself changes. >> with the autoconf macro's parameter embedded somewhere in the >> middle of all that stuff, were you to change a parameter to an autoconf >> macro in configure.ac, and upstream changes the parameter in the next >> line, your patch gets broken. > > Upstream is much less likely to change that parameter in the next line than > to use a different version of autoconf. Do you have any data to back up this interesting notion -- that most changes to configure are due to autoconf version changes, rather than upstream making changes to configure.ac itself? I thought not. >> Yes, tell me again how conflicting patches to neighboring lines in >> configure.ac "works", while the equivalent two patches hundreds of lines >> apart in configure do not. > > You don't understand me, I'm telling you how patches to configure.ac in an > area upstream is unlikely to touch any time soon work, while the equivalent > patches in configure get fuzzed by unrelated changes introduced by a new > autoconf used by upstream and break. This is absurd. configure.ac changes due to natural evolution of the package far more often than autoconf itself changing. In fact, many actually loathe switching to a different version of autoconf, preferring to stay on the same version as long as possible. >> Stuff like AC_PATH_PROG produces several dozens lines of canned shellcode, >> with the arguments to AC_PATH_PROG appearing once, in the middle of them. > > But those "several dozens lines of canned shellcode" CHANGE WITH THE > AUTOCONF VERSION! Which happens far less often than routine changes to configure.ac, as the package natural evolves over time. autoconf changes happens maybe once every other year or so. Most configure script change far more often than once every other year. This is a bogus argument. >> Changing the parameter to AC_PATH_PROG, for example, does not change >> hundreds of lines of shellcode. > > No, but using the next point release of autoconf, even with no changes to > configure.ac at all, does. > > Most programmers use fast-moving distros. Distros like Fedora, Debian It would be trivial to pick a typical package, and look at intervening releases, years apart, and observe the major differences in configure.ac, yet, perhaps only one, if none, update to autoconf itself occuring in all the intervening releases. But, once I do that, you'll abandon this reasoning too, once you realize that it's a non-starter, and change the topic to something else. It'll probably be line number changes. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mrsam at courier-mta.com Wed Jul 8 11:17:13 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Wed, 08 Jul 2009 07:17:13 -0400 Subject: an update to automake-1.11? References: <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <1246917991.25343.8673.camel@atropine.boston.devel.redhat.com> <20090708103612.GA10438@amd.home.annexia.org> Message-ID: Richard W.M. Jones writes: > On Tue, Jul 07, 2009 at 06:05:47PM -0400, Sam Varshavchik wrote: >> If someone thinks that by patching configure.ac, instead of configure, >> one achieves tremendous savings in the frequency of needing to rebase >> one's patches, they're in a desperate need for a reality check. > > No, you are. Please find out how patch works. I do. Which is why you cannot hold your end of the debate. -------------- 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 Jul 8 11:21:44 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 8 Jul 2009 13:21:44 +0200 Subject: poll(), gdb, threads, alsa-lib, deadlock In-Reply-To: <20090708131656.73fe05a8@faldor> References: <20090708110021.12ee5076@noname.noname> <20090708102854.GA16449@mokona.greysector.net> <20090708131656.73fe05a8@faldor> Message-ID: <20090708132144.5b6593d7@faldor> On Wed, 8 Jul 2009 13:16:56 +0200, me wrote: > > Actually, I see that on Fedora 10, too. > > Do you remember when you ran into it for the first time? > alsa-lib was upgraded for F10 at beginning of May, for example. [Perhaps > I need to diff in that area.] Hmmm, the alsa-lib diff between 1.0.19 and 1.0.20 is 36K short and actually touches the poll() stuff in snd_pcm_wait_nocheck(). From dominik at greysector.net Wed Jul 8 11:49:04 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 8 Jul 2009 13:49:04 +0200 Subject: poll(), gdb, threads, alsa-lib, deadlock In-Reply-To: <20090708131656.73fe05a8@faldor> References: <20090708110021.12ee5076@noname.noname> <20090708102854.GA16449@mokona.greysector.net> <20090708131656.73fe05a8@faldor> Message-ID: <20090708114903.GB16449@mokona.greysector.net> On Wednesday, 08 July 2009 at 13:16, Michael Schwendt wrote: > On Wed, 8 Jul 2009 12:28:55 +0200, Dominik wrote: > > > On Wednesday, 08 July 2009 at 11:00, Michael Schwendt wrote: > > > I'd like another pair of eyes as what I see in a backtrace looks strange. > > > The full backtrace is attached, two excerpts inline below. > > > > > > With Fedora 11 (and never before) I see deadlocks in Audacious > > > occasionally. It's not too easy to reproduce, but starting something > > > resource-hungry while playing ogg/mp3 makes the player hang up > > > occasionally. > > > > Actually, I see that on Fedora 10, too. > > Do you remember when you ran into it for the first time? > alsa-lib was upgraded for F10 at beginning of May, for example. [Perhaps > I need to diff in that area.] AFAIR I got the problem right from the beginning of using F10, but I installed it about a month or two after it came out and updated immediately after installation. 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 kmaraas at broadpark.no Wed Jul 8 12:43:16 2009 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Wed, 08 Jul 2009 14:43:16 +0200 Subject: No sound in rawhide In-Reply-To: <20090617184434.GA6931@bludgeon.org> References: <1245067767.2620.8.camel@localhost.localdomain> <1245147470.11069.8216.camel@localhost.localdomain> <1245239497.12256.1.camel@nc6400> <20090617152500.GA3770@bludgeon.org> <604aa7910906170906i10306bdcwb9fbf4f3d6f99288@mail.gmail.com> <20090617184434.GA6931@bludgeon.org> Message-ID: <1247056996.3299.0.camel@nc6400> on., 17.06.2009 kl. 11.44 -0700, skrev Ray Van Dolson: > On Wed, Jun 17, 2009 at 08:06:36AM -0800, Jeff Spaleta wrote: > > On Wed, Jun 17, 2009 at 7:25 AM, Ray Van Dolson wrote: > > > Hmm, I just always figured I was supposed to add myself to the audio > > > group. So these files are supposed to be owned by my local user > > > account when I log in eh? > > > > No... you should be added to the acl list associated to the device if > > you are the physical console user as per the authorization policy > > managed by PolicyKit. This it how it works from at least F10 onward. > > Mucking around with file ownership directly is "old think." The system > > scripts associated with pam use to do that on user login and > > logout...but has been replaced with the more flexible solution > > involving acls that PolicyKit based hardware access authorization > > makes use of. > > > > > > for example on the F10 system I'm on right now: > > ls -la /dev/snd/seq > > crw-rw----+ 1 root root 116, 3 2009-06-17 07:07 /dev/snd/seq > > > > > > getfacl /dev/dsp > > # file: dev/snd/seq > > # owner: root > > # group: root > > user::rw- > > user:myuser:rw- > > group::rw- > > mask::rw- > > other::--- > > > > I do not own the file in the traditional Unix permissions sense. But I > > am listed in the acl list with read write access. If your user is not > > in the acl list, something misfired in the area of the PolicyKit based > > authorization handling. > > Good to know. I've checked the acl list in the past and definitely > wasn't a member. > > I'll have to remove myself from audio and see if I can track this down. > Did you find anything? I'm still seeing this problem with rawhide as of today. Cheers Kjartan From ascii79 at gmail.com Wed Jul 8 13:22:58 2009 From: ascii79 at gmail.com (Sachin) Date: Wed, 8 Jul 2009 08:22:58 -0500 Subject: No sound in rawhide In-Reply-To: <1247056996.3299.0.camel@nc6400> References: <1245067767.2620.8.camel@localhost.localdomain> <1245147470.11069.8216.camel@localhost.localdomain> <1245239497.12256.1.camel@nc6400> <20090617152500.GA3770@bludgeon.org> <604aa7910906170906i10306bdcwb9fbf4f3d6f99288@mail.gmail.com> <20090617184434.GA6931@bludgeon.org> <1247056996.3299.0.camel@nc6400> Message-ID: i added myself to the pulse-access and audio group .. On Wed, Jul 8, 2009 at 7:43 AM, Kjartan Maraas wrote: > on., 17.06.2009 kl. 11.44 -0700, skrev Ray Van Dolson: > > On Wed, Jun 17, 2009 at 08:06:36AM -0800, Jeff Spaleta wrote: > > > On Wed, Jun 17, 2009 at 7:25 AM, Ray Van Dolson > wrote: > > > > Hmm, I just always figured I was supposed to add myself to the audio > > > > group. So these files are supposed to be owned by my local user > > > > account when I log in eh? > > > > > > No... you should be added to the acl list associated to the device if > > > you are the physical console user as per the authorization policy > > > managed by PolicyKit. This it how it works from at least F10 onward. > > > Mucking around with file ownership directly is "old think." The system > > > scripts associated with pam use to do that on user login and > > > logout...but has been replaced with the more flexible solution > > > involving acls that PolicyKit based hardware access authorization > > > makes use of. > > > > > > > > > for example on the F10 system I'm on right now: > > > ls -la /dev/snd/seq > > > crw-rw----+ 1 root root 116, 3 2009-06-17 07:07 /dev/snd/seq > > > > > > > > > getfacl /dev/dsp > > > # file: dev/snd/seq > > > # owner: root > > > # group: root > > > user::rw- > > > user:myuser:rw- > > > group::rw- > > > mask::rw- > > > other::--- > > > > > > I do not own the file in the traditional Unix permissions sense. But I > > > am listed in the acl list with read write access. If your user is not > > > in the acl list, something misfired in the area of the PolicyKit based > > > authorization handling. > > > > Good to know. I've checked the acl list in the past and definitely > > wasn't a member. > > > > I'll have to remove myself from audio and see if I can track this down. > > > Did you find anything? I'm still seeing this problem with rawhide as of > today. > > Cheers > Kjartan > > > -- > 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 rvinyard at cs.nmsu.edu Wed Jul 8 13:59:43 2009 From: rvinyard at cs.nmsu.edu (Rick L. Vinyard, Jr.) Date: Wed, 8 Jul 2009 07:59:43 -0600 Subject: noarch subpackages Message-ID: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> What is the effect on non-Fedora and older distributions (pre F10) if I mark a subpackage (such as documentation) with BuildArch: noarch? From choeger at cs.tu-berlin.de Wed Jul 8 14:21:23 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Wed, 08 Jul 2009 16:21:23 +0200 Subject: delaying an update Message-ID: <1247062883.6598.4.camel@choeger6> Hi, my latest update to offlineimap https://admin.fedoraproject.org/updates/offlineimap-6.1.0-2.fc11 has revealed a bug somewhere between offlineimap imaplib2 and kerberos. Since I do not know how to fix that, I would like to: a) delay that update from being pushed to stable as long as the situation is unclear b) cancel it if there is no upstream response in a week or so how do I do that? -------------- 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 mike at cchtml.com Wed Jul 8 14:30:56 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Wed, 08 Jul 2009 09:30:56 -0500 Subject: delaying an update In-Reply-To: <1247062883.6598.4.camel@choeger6> References: <1247062883.6598.4.camel@choeger6> Message-ID: <4A54ADA0.20508@cchtml.com> Christoph H?ger on 07/08/2009 09:21 AM wrote: > > how do I do that? > Since you have not submitted it for "stable" I do not see any problem. Don't do anything. :) From dennis at ausil.us Wed Jul 8 14:31:48 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 8 Jul 2009 09:31:48 -0500 Subject: noarch subpackages In-Reply-To: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> References: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> Message-ID: <200907080931.57748.dennis@ausil.us> On Wednesday 08 July 2009 08:59:43 am Rick L. Vinyard, Jr. wrote: > What is the effect on non-Fedora and older distributions (pre F10) if I > mark a subpackage (such as documentation) with BuildArch: noarch? the package will attempt to build as noarch only. you cant to it for F-9 and since F-9 is EOL in two days dont. for EL-4 and EL-5 you could probably if the BuildArch out 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 mhlavink at redhat.com Wed Jul 8 14:39:37 2009 From: mhlavink at redhat.com (Michal Hlavinka) Date: Wed, 8 Jul 2009 16:39:37 +0200 Subject: delaying an update In-Reply-To: <4A54ADA0.20508@cchtml.com> References: <1247062883.6598.4.camel@choeger6> <4A54ADA0.20508@cchtml.com> Message-ID: <200907081639.37528.mhlavink@redhat.com> On Wednesday 08 July 2009 16:30:56 Michael Cronenworth wrote: > Christoph H?ger on 07/08/2009 09:21 AM wrote: > > how do I do that? I guess you can use Delete/Unpush/Revoke request or something like that in bodhi web interface. > Since you have not submitted it for "stable" I do not see any problem. > Don't do anything. :) I disagree. There are several users using packages from updates-testing. Letting them update to a package you know is broken is bad. From jussilehtola at fedoraproject.org Wed Jul 8 14:41:06 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Wed, 08 Jul 2009 17:41:06 +0300 Subject: delaying an update In-Reply-To: <4A54ADA0.20508@cchtml.com> References: <1247062883.6598.4.camel@choeger6> <4A54ADA0.20508@cchtml.com> Message-ID: <1247064066.3501.4.camel@politzer.theorphys.helsinki.fi> On Wed, 2009-07-08 at 09:30 -0500, Michael Cronenworth wrote: > Christoph H?ger on 07/08/2009 09:21 AM wrote: > > > > how do I do that? > > > > Since you have not submitted it for "stable" I do not see any problem. > Don't do anything. :) You might want to disable the automatic push to stable, though, in case the package gets too much karma.. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From mschwendt at gmail.com Wed Jul 8 15:06:39 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 8 Jul 2009 17:06:39 +0200 Subject: noarch subpackages In-Reply-To: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> References: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> Message-ID: <20090708170639.21f9b4bf@faldor> On Wed, 8 Jul 2009 07:59:43 -0600, Jr. wrote: > What is the effect on non-Fedora and older distributions (pre F10) if I > mark a subpackage (such as documentation) with BuildArch: noarch? You can evaluate the %fedora variable to use this new feature only for Fedora >= 10: %if 0%{?fedora} > 9 BuildArch: noarch %endif From rvinyard at cs.nmsu.edu Wed Jul 8 15:07:31 2009 From: rvinyard at cs.nmsu.edu (Rick L. Vinyard, Jr.) Date: Wed, 8 Jul 2009 09:07:31 -0600 Subject: noarch subpackages In-Reply-To: <20090708170639.21f9b4bf@faldor> References: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> <20090708170639.21f9b4bf@faldor> Message-ID: <9514c41a0ff9d6e5be9b2ad6f16331d6.squirrel@intranet.cs.nmsu.edu> Michael Schwendt wrote: > On Wed, 8 Jul 2009 07:59:43 -0600, Jr. wrote: > >> What is the effect on non-Fedora and older distributions (pre F10) if I >> mark a subpackage (such as documentation) with BuildArch: noarch? > > You can evaluate the %fedora variable to use this new feature only > for Fedora >= 10: > > %if 0%{?fedora} > 9 > BuildArch: noarch > %endif > Excellent. That's what I was looking for. From ascii79 at gmail.com Wed Jul 8 15:09:02 2009 From: ascii79 at gmail.com (Sachin) Date: Wed, 8 Jul 2009 10:09:02 -0500 Subject: No sound in rawhide In-Reply-To: References: <1245067767.2620.8.camel@localhost.localdomain> <1245147470.11069.8216.camel@localhost.localdomain> <1245239497.12256.1.camel@nc6400> <20090617152500.GA3770@bludgeon.org> <604aa7910906170906i10306bdcwb9fbf4f3d6f99288@mail.gmail.com> <20090617184434.GA6931@bludgeon.org> <1247056996.3299.0.camel@nc6400> Message-ID: also renamed file /etc/pulse/default.pa.rpmnew to /etc/pulse/default.pa On Wed, Jul 8, 2009 at 8:22 AM, Sachin wrote: > i added myself to the pulse-access and audio group .. > > > On Wed, Jul 8, 2009 at 7:43 AM, Kjartan Maraas wrote: > >> on., 17.06.2009 kl. 11.44 -0700, skrev Ray Van Dolson: >> > On Wed, Jun 17, 2009 at 08:06:36AM -0800, Jeff Spaleta wrote: >> > > On Wed, Jun 17, 2009 at 7:25 AM, Ray Van Dolson >> wrote: >> > > > Hmm, I just always figured I was supposed to add myself to the audio >> > > > group. So these files are supposed to be owned by my local user >> > > > account when I log in eh? >> > > >> > > No... you should be added to the acl list associated to the device if >> > > you are the physical console user as per the authorization policy >> > > managed by PolicyKit. This it how it works from at least F10 onward. >> > > Mucking around with file ownership directly is "old think." The system >> > > scripts associated with pam use to do that on user login and >> > > logout...but has been replaced with the more flexible solution >> > > involving acls that PolicyKit based hardware access authorization >> > > makes use of. >> > > >> > > >> > > for example on the F10 system I'm on right now: >> > > ls -la /dev/snd/seq >> > > crw-rw----+ 1 root root 116, 3 2009-06-17 07:07 /dev/snd/seq >> > > >> > > >> > > getfacl /dev/dsp >> > > # file: dev/snd/seq >> > > # owner: root >> > > # group: root >> > > user::rw- >> > > user:myuser:rw- >> > > group::rw- >> > > mask::rw- >> > > other::--- >> > > >> > > I do not own the file in the traditional Unix permissions sense. But I >> > > am listed in the acl list with read write access. If your user is not >> > > in the acl list, something misfired in the area of the PolicyKit based >> > > authorization handling. >> > >> > Good to know. I've checked the acl list in the past and definitely >> > wasn't a member. >> > >> > I'll have to remove myself from audio and see if I can track this down. >> > >> Did you find anything? I'm still seeing this problem with rawhide as of >> today. >> >> Cheers >> Kjartan >> >> >> -- >> 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 choeger at cs.tu-berlin.de Wed Jul 8 15:17:49 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Wed, 08 Jul 2009 17:17:49 +0200 Subject: delaying an update In-Reply-To: <1247064066.3501.4.camel@politzer.theorphys.helsinki.fi> References: <1247062883.6598.4.camel@choeger6> <4A54ADA0.20508@cchtml.com> <1247064066.3501.4.camel@politzer.theorphys.helsinki.fi> Message-ID: <1247066269.19468.0.camel@choeger6> Am Mittwoch, den 08.07.2009, 17:41 +0300 schrieb Jussi Lehtola: > On Wed, 2009-07-08 at 09:30 -0500, Michael Cronenworth wrote: > > Christoph H?ger on 07/08/2009 09:21 AM wrote: > > > > > > how do I do that? > > > > > > > Since you have not submitted it for "stable" I do not see any problem. > > Don't do anything. :) > > You might want to disable the automatic push to stable, though, in case > the package gets too much karma.. That's what I meant with "delay". So how do I do that? -------------- 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 darrellpf at gmail.com Wed Jul 8 15:30:18 2009 From: darrellpf at gmail.com (darrell pfeifer) Date: Wed, 8 Jul 2009 08:30:18 -0700 Subject: inotify and gnome authorization Message-ID: Over the last few months I've had problems with the gnome authorization dialog failing, sometimes intermittently and sometimes consistently for long periods of time. The dialog I'm referring to is the one that pops up when root access is needed to run an application or control panel. Examples are System/Preferences/Authorizations, running the virtual machine manager, running lots of control panels from System/Administration/* It turns out that eventually polkit-gnome-manager is called. It uses inotify to put a watch on /etc/PolicyKit/PolicyKit.conf. In my case, placing the watch was failing, which meant no authorization. A workaround is to bump up the 8192 limit to something higher echo 16384 > /proc/sys/fs/inotify/max_user_watches I'm still a bit mystified as to what is using all the watches. Before and after the echo lsof only reports less than 32 watches on my system. Other than lsof there don't appear to be an tools to show who is consuming the watches. If nobody has an suggestions, I may try systemtap. I'm not sure at this point that it makes sense to bump up the kernel default without knowing the current culprit. The bottom line: with policykit being used more heavily in rawhide, if you're getting strange intermittent permissions failures, try the workaround. darrell From mclasen at redhat.com Wed Jul 8 15:47:50 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 08 Jul 2009 11:47:50 -0400 Subject: inotify and gnome authorization In-Reply-To: References: Message-ID: <1247068071.2153.10.camel@planemask> On Wed, 2009-07-08 at 08:30 -0700, darrell pfeifer wrote: > > The bottom line: with policykit being used more heavily in rawhide, if > you're getting strange intermittent permissions failures, try the > workaround. > When you run out of inotify watches, many things will fail, not just PolicyKit. Likely culprits for eating the watches would be indexers like beagle or tracker. I used to have a systemtap script for monitoring inotify watch consumption, but I seem to have lost it... Matthias From kevin.kofler at chello.at Wed Jul 8 17:17:38 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 08 Jul 2009 19:17:38 +0200 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <1246917991.25343.8673.camel@atropine.boston.devel.redhat.com> Message-ID: Sam Varshavchik wrote: > You're changing the topic. No, you're the one changing the topic. > On this point, we're not talking about what happens when autoconf changes. > Here, the original statement was that patches to configure.ac are less > likely to be kicked out than configure, if configure.ac changes. The original statement was: (Adam Jackson wrote:) | I suppose it depends whether you consider the initial act of package | creation, or the continued maintenance of that packaging, to be more | time consuming. All I know is that rediffing patches to configure.ac | takes way less time than rediffing against configure, and that as a | practice that hasn't (non-trivially) bitten me once in over three years, | where configure patches have. What he was talking about is that rediffing patches, i.e. making patches apply to a new upstream version (that's what "rediffing" means for us Fedora packagers), is more likely to break for configure.ac than for configure. So your "if configure.ac changes" part was not in the original topic, instead it was that patches to configure.ac are less likely to be kicked out than configure when upgrading to a new upstream version. > I pointed out that this is completely absurd, and you have no idea how > autoconf works. You have no answer, so you must now start talking about > what happens when autoconf itself changes. Nonsense. This was always part of the original topic, you have just been ignoring it. New upstream versions also use new autoconf versions. > This is absurd. configure.ac changes due to natural evolution of the > package far more often than autoconf itself changing. > > In fact, many actually loathe switching to a different version of > autoconf, preferring to stay on the same version as long as possible. [snip] > Which happens far less often than routine changes to configure.ac, as the > package natural evolves over time. autoconf changes happens maybe once > every other year or so. Most configure script change far more often than > once every other year. I don't know what upstreams you worked with. For the projects I worked on with Romain Li?vin, he generally ran autoreconf with what was current on Debian unstable or testing that day and me with what was current on Fedora (stable updates) that day. The stuff would even ping-pong between the Debian and Fedora versions. And even when it was the same person regenerating it, it changed all the time. Fedora updates and Debian unstable/testing both get autotools updates much more often than once every other year. Most developers do not work on an enterprise distribution nor do they build their own autotools. They use whatever is current on their fast-moving distribution. configure.ac itself only got minimal changes (the most frequent one was bumping the version number). > This is a bogus argument. No, it isn't. See above. See also Ajax's statement I quoted again. > It would be trivial to pick a typical package, and look at intervening > releases, years apart, and observe the major differences in configure.ac, > yet, perhaps only one, if none, update to autoconf itself occuring in all > the intervening releases. What's your "typical package"? Definitely not the ones I worked on. > But, once I do that, you'll abandon this reasoning too, once you realize > that it's a non-starter, and change the topic to something else. It'll > probably be line number changes. Nonsense. I'm not being intentionally dishonest, please stop those unwarranted accusations! Kevin Kofler From kevin.kofler at chello.at Wed Jul 8 17:20:12 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 08 Jul 2009 19:20:12 +0200 Subject: noarch subpackages References: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> <20090708170639.21f9b4bf@faldor> <9514c41a0ff9d6e5be9b2ad6f16331d6.squirrel@intranet.cs.nmsu.edu> Message-ID: Rick L. Vinyard, Jr. wrote: > Michael Schwendt wrote: >> On Wed, 8 Jul 2009 07:59:43 -0600, Jr. wrote: >> >>> What is the effect on non-Fedora and older distributions (pre F10) if I >>> mark a subpackage (such as documentation) with BuildArch: noarch? >> >> You can evaluate the %fedora variable to use this new feature only >> for Fedora >= 10: >> >> %if 0%{?fedora} > 9 >> BuildArch: noarch >> %endif >> > > Excellent. That's what I was looking for. Except it should be: %if 0%{?fedora} > 9 || 0%{?rhel} > 5 Kevin Kofler From ricky at fedoraproject.org Wed Jul 8 17:26:28 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Wed, 8 Jul 2009 13:26:28 -0400 Subject: Anybody know how to contact Axel Thimm (again)? Message-ID: <20090708172628.GM4580@alpha.rzhou.org> Hi, we're following the policy for nonresponsive package maintainers again for bug 484855. There hasn't been any update on this breakage in the last 3 weeks. http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers https://bugzilla.redhat.com/show_bug.cgi?id=484855 Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From limb at jcomserv.net Wed Jul 8 17:30:30 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 08 Jul 2009 12:30:30 -0500 Subject: Anybody know how to contact Axel Thimm (again)? In-Reply-To: <20090708172628.GM4580@alpha.rzhou.org> References: <20090708172628.GM4580@alpha.rzhou.org> Message-ID: <4A54D7B6.9060302@jcomserv.net> Ricky Zhou wrote: > Hi, we're following the policy for nonresponsive package maintainers > again for bug 484855. There hasn't been any update on this breakage in > the last 3 weeks. > > http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers > https://bugzilla.redhat.com/show_bug.cgi?id=484855 > > Thanks, > Ricky > Is he not responding at Axel.Thimm at ATrpms.net? -- in your fear, speak only peace in your fear, seek only love -d. bowie From ricky at fedoraproject.org Wed Jul 8 17:41:15 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Wed, 8 Jul 2009 13:41:15 -0400 Subject: Anybody know how to contact Axel Thimm (again)? In-Reply-To: <4A54D7B6.9060302@jcomserv.net> References: <20090708172628.GM4580@alpha.rzhou.org> <4A54D7B6.9060302@jcomserv.net> Message-ID: <20090708174115.GN4580@alpha.rzhou.org> On 2009-07-08 12:30:30 PM, Jon Ciesla wrote: > Is he not responding at Axel.Thimm at ATrpms.net? That's his bugzilla email addess, so that seems to be the case :-( Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From limb at jcomserv.net Wed Jul 8 17:41:56 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 08 Jul 2009 12:41:56 -0500 Subject: Anybody know how to contact Axel Thimm (again)? In-Reply-To: <20090708174115.GN4580@alpha.rzhou.org> References: <20090708172628.GM4580@alpha.rzhou.org> <4A54D7B6.9060302@jcomserv.net> <20090708174115.GN4580@alpha.rzhou.org> Message-ID: <4A54DA64.8020002@jcomserv.net> Ricky Zhou wrote: > On 2009-07-08 12:30:30 PM, Jon Ciesla wrote: > >> Is he not responding at Axel.Thimm at ATrpms.net? >> > That's his bugzilla email addess, so that seems to be the case :-( > > Thanks, > Ricky > What about ixs at fedoraproject.org? -- in your fear, speak only peace in your fear, seek only love -d. bowie From jwboyer at gmail.com Wed Jul 8 17:44:48 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 8 Jul 2009 13:44:48 -0400 Subject: an update to automake-1.11? In-Reply-To: References: Message-ID: <20090708174448.GQ19829@hansolo.jdub.homelinux.org> On Wed, Jul 08, 2009 at 07:17:38PM +0200, Kevin Kofler wrote: >> But, once I do that, you'll abandon this reasoning too, once you realize >> that it's a non-starter, and change the topic to something else. It'll >> probably be line number changes. > >Nonsense. I'm not being intentionally dishonest, please stop those >unwarranted accusations! I think you both need to stop this ridiculous conversation. While I'm sure the merits of patching configure or configure.ac can and will be debated forever, you are not doing anything other than wasting each other's time. josh From limb at jcomserv.net Wed Jul 8 17:46:16 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 08 Jul 2009 12:46:16 -0500 Subject: Anybody know how to contact Axel Thimm (again)? In-Reply-To: <20090708174509.GA18255@killefiz> References: <20090708172628.GM4580@alpha.rzhou.org> <4A54D7B6.9060302@jcomserv.net> <20090708174115.GN4580@alpha.rzhou.org> <4A54DA64.8020002@jcomserv.net> <20090708174509.GA18255@killefiz> Message-ID: <4A54DB68.6080504@jcomserv.net> Sven Lankes wrote: > On Wed, Jul 08, 2009 at 12:41:56PM -0500, Jon Ciesla wrote: > > >>>> Is he not responding at Axel.Thimm at ATrpms.net? >>>> >>> That's his bugzilla email addess, so that seems to be the case :-( >>> > > >> What about ixs at fedoraproject.org? >> > > That is Andreas Thienemann - same initials, different person. > > Maybe I should try to sleep more than 1.5 hours tonight. :) -- in your fear, speak only peace in your fear, seek only love -d. bowie From notting at redhat.com Wed Jul 8 17:51:36 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 8 Jul 2009 13:51:36 -0400 Subject: Anybody know how to contact Axel Thimm (again)? In-Reply-To: <4A54DA64.8020002@jcomserv.net> References: <20090708172628.GM4580@alpha.rzhou.org> <4A54D7B6.9060302@jcomserv.net> <20090708174115.GN4580@alpha.rzhou.org> <4A54DA64.8020002@jcomserv.net> Message-ID: <20090708175136.GA1341@nostromo.devel.redhat.com> Jon Ciesla (limb at jcomserv.net) said: >>> Is he not responding at Axel.Thimm at ATrpms.net? >> That's his bugzilla email addess, so that seems to be the case :-( > > What about ixs at fedoraproject.org? ixs at fp.o is not Axel. athimm at fp.o just goes to the ATrpms.net e-mail address. Bill From itamar at ispbrasil.com.br Wed Jul 8 17:52:58 2009 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Wed, 8 Jul 2009 14:52:58 -0300 Subject: Anybody know how to contact Axel Thimm (again)? In-Reply-To: <20090708175136.GA1341@nostromo.devel.redhat.com> References: <20090708172628.GM4580@alpha.rzhou.org> <4A54D7B6.9060302@jcomserv.net> <20090708174115.GN4580@alpha.rzhou.org> <4A54DA64.8020002@jcomserv.net> <20090708175136.GA1341@nostromo.devel.redhat.com> Message-ID: there are alot of bug report's and patch's waiting for Axel.Thimm On Wed, Jul 8, 2009 at 2:51 PM, Bill Nottingham wrote: > Jon Ciesla (limb at jcomserv.net) said: >>>> Is he not responding at Axel.Thimm at ATrpms.net? >>> That's his bugzilla email addess, so that seems to be the case :-( >> >> What about ixs at fedoraproject.org? > > ixs at fp.o is not Axel. athimm at fp.o just goes to the ATrpms.net e-mail address. > > Bill > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- ------------ Itamar Reis Peixoto e-mail/msn: itamar at ispbrasil.com.br sip: itamar at ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 From frankly3d at gmail.com Wed Jul 8 17:55:07 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Wed, 08 Jul 2009 18:55:07 +0100 Subject: Anybody know how to contact Axel Thimm (again)? In-Reply-To: <20090708175136.GA1341@nostromo.devel.redhat.com> References: <20090708172628.GM4580@alpha.rzhou.org> <4A54D7B6.9060302@jcomserv.net> <20090708174115.GN4580@alpha.rzhou.org> <4A54DA64.8020002@jcomserv.net> <20090708175136.GA1341@nostromo.devel.redhat.com> Message-ID: <4A54DD7B.6070505@gmail.com> On 08/07/09 18:51, Bill Nottingham wrote: > Jon Ciesla (limb at jcomserv.net) said: >>>> Is he not responding at Axel.Thimm at ATrpms.net? >>> That's his bugzilla email addess, so that seems to be the case :-( >> >> What about ixs at fedoraproject.org? > > ixs at fp.o is not Axel. athimm at fp.o just goes to the ATrpms.net e-mail address. > > Bill > Try a who is, it will give an extra addy. Frank From tcallawa at redhat.com Wed Jul 8 17:58:49 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 08 Jul 2009 13:58:49 -0400 Subject: an update to automake-1.11? In-Reply-To: <20090708174448.GQ19829@hansolo.jdub.homelinux.org> References: <20090708174448.GQ19829@hansolo.jdub.homelinux.org> Message-ID: <4A54DE59.9090108@redhat.com> On 07/08/2009 01:44 PM, Josh Boyer wrote: > On Wed, Jul 08, 2009 at 07:17:38PM +0200, Kevin Kofler wrote: >>> But, once I do that, you'll abandon this reasoning too, once you realize >>> that it's a non-starter, and change the topic to something else. It'll >>> probably be line number changes. >> Nonsense. I'm not being intentionally dishonest, please stop those >> unwarranted accusations! > > I think you both need to stop this ridiculous conversation. While I'm sure > the merits of patching configure or configure.ac can and will be debated > forever, you are not doing anything other than wasting each other's time. I agree. Consider this an informal warning that you're both about to cross the line on "being excellent to each other". ~spot From bernie at codewiz.org Wed Jul 8 18:05:21 2009 From: bernie at codewiz.org (Bernie Innocenti) Date: Wed, 08 Jul 2009 20:05:21 +0200 Subject: Can we import dia 0.97 in rawhide? Message-ID: <1247076321.24440.22.camel@localhost> It's been released here: http://projects.gnome.org/dia/ -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ From kzak at redhat.com Wed Jul 8 18:22:16 2009 From: kzak at redhat.com (Karel Zak) Date: Wed, 8 Jul 2009 20:22:16 +0200 Subject: art of packaging: fluxbox-pulseaudio Message-ID: <20090708182216.GB4757@nb.net.home> # rpm -ql fluxbox-pulseaudio /etc/fluxbox-pulseaudio # ls -la /etc/fluxbox-pulseaudio -rw-r--r-- 1 root root 0 2008-09-17 19:29 /etc/fluxbox-pulseaudio # rpm -q --qf "%{ARCH}\n" fluxbox-pulseaudio x86_64 ... it means the package contains one empty file. Is it really normal that we configure our system by "yum install/remove"? Really? Karel -- Karel Zak From cemeyer at u.washington.edu Wed Jul 8 18:36:19 2009 From: cemeyer at u.washington.edu (Conrad Meyer) Date: Wed, 8 Jul 2009 11:36:19 -0700 Subject: Can we import dia 0.97 in rawhide? In-Reply-To: <1247076321.24440.22.camel@localhost> References: <1247076321.24440.22.camel@localhost> Message-ID: <200907081136.19762.cemeyer@u.washington.edu> On Wednesday 08 July 2009 11:05:21 am Bernie Innocenti wrote: > It's been released here: > > http://projects.gnome.org/dia/ > > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ File a bug. -- Conrad Meyer From andreas.bierfert at lowlatency.de Wed Jul 8 18:44:53 2009 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Wed, 8 Jul 2009 20:44:53 +0200 Subject: art of packaging: fluxbox-pulseaudio In-Reply-To: <20090708182216.GB4757@nb.net.home> References: <20090708182216.GB4757@nb.net.home> Message-ID: <20090708204453.74654358@spica.a.lan> On Wed, 8 Jul 2009 20:22:16 +0200 Karel Zak wrote: > > # rpm -ql fluxbox-pulseaudio > ... it means the package contains one empty file. Is it really normal > that we configure our system by "yum install/remove"? Really? It is not only an empty file. It requires the necessary PA packages and triggers automatic PA loading on session starts. Please see [1] and [2] for some more background information. Regards, Andreas [1] - http://cvs.fedoraproject.org/viewvc/devel/fluxbox/fluxbox.spec?view=markup [2] - https://bugzilla.redhat.com/show_bug.cgi?id=388971 -- Andreas Bierfert, M.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 6897 1721738 | cell: +49 173 5803043 | mail preferred -------------- 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 Wed Jul 8 18:50:18 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 08 Jul 2009 11:50:18 -0700 Subject: art of packaging: fluxbox-pulseaudio In-Reply-To: <20090708204453.74654358@spica.a.lan> References: <20090708182216.GB4757@nb.net.home> <20090708204453.74654358@spica.a.lan> Message-ID: <1247079018.2969.19.camel@localhost.localdomain> On Wed, 2009-07-08 at 20:44 +0200, Andreas Bierfert wrote: > It is not only an empty file. It requires the necessary PA packages > and triggers > automatic PA loading on session starts. > > Please see [1] and [2] for some more background information. That subpackage should likely 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: 197 bytes Desc: This is a digitally signed message part URL: From andreas.bierfert at lowlatency.de Wed Jul 8 18:55:05 2009 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Wed, 8 Jul 2009 20:55:05 +0200 Subject: art of packaging: fluxbox-pulseaudio In-Reply-To: <1247079018.2969.19.camel@localhost.localdomain> References: <20090708182216.GB4757@nb.net.home> <20090708204453.74654358@spica.a.lan> <1247079018.2969.19.camel@localhost.localdomain> Message-ID: <20090708205505.769a5b0e@spica.a.lan> On Wed, 08 Jul 2009 11:50:18 -0700 Jesse Keating wrote: > On Wed, 2009-07-08 at 20:44 +0200, Andreas Bierfert wrote: > > It is not only an empty file. It requires the necessary PA packages > > and triggers > > automatic PA loading on session starts. > > > > Please see [1] and [2] for some more background information. > > That subpackage should likely be noarch. > Just been thinking the same. Will be fixed asap. - Andreas -- Andreas Bierfert, M.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 6897 1721738 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From opensource at till.name Wed Jul 8 18:59:54 2009 From: opensource at till.name (Till Maas) Date: Wed, 08 Jul 2009 20:59:54 +0200 Subject: delaying an update In-Reply-To: <1247066269.19468.0.camel@choeger6> References: <1247062883.6598.4.camel@choeger6> <1247064066.3501.4.camel@politzer.theorphys.helsinki.fi> <1247066269.19468.0.camel@choeger6> Message-ID: <200907082100.01577.opensource@till.name> On Wed July 8 2009, Christoph H?ger wrote: > Am Mittwoch, den 08.07.2009, 17:41 +0300 schrieb Jussi Lehtola: > > On Wed, 2009-07-08 at 09:30 -0500, Michael Cronenworth wrote: > > > Christoph H?ger on 07/08/2009 09:21 AM wrote: > > > > how do I do that? > > > > > > Since you have not submitted it for "stable" I do not see any problem. > > > Don't do anything. :) > > > > You might want to disable the automatic push to stable, though, in case > > the package gets too much karma.. > > That's what I meant with "delay". So how do I do that? You can unselect it here: https://admin.fedoraproject.org/updates/edit/offlineimap-6.1.0-2.fc11 And revoke the push request here: https://admin.fedoraproject.org/updates/revoke/offlineimap-6.1.0-2.fc11 Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mclasen at redhat.com Wed Jul 8 19:42:54 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 08 Jul 2009 15:42:54 -0400 Subject: Display Configuration test day summary Message-ID: <1247082174.2303.11.camel@planemask> We've had the first 'Fit and Finish' test day on display configuration yesterday. I'd like to thank everybody who came by on irc and tested something, or filed a bug. If you could not make it, our test cases are still available here: https://fedoraproject.org/wiki/Test_Day:2009-07-07_Fit_and_Finish:Display_Configuration That page also contains the results of our yesterdays testing efforts, if you are interested. The good news is that we have already fixed some of the things that were found broken, and more fixes are on the way. Here is just one exemplary fix: * Tue Jul 07 2009 Adam Jackson 2.27.3-2 - gnome-desktop-2.27.3-edid-prop-name.patch: Adapt to RANDR 1.3's new name for the EDID output property. I'll post the date an topic for our next 'Fit and Finish' test day in the next few days. Matthias From choeger at cs.tu-berlin.de Wed Jul 8 21:31:30 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Wed, 08 Jul 2009 23:31:30 +0200 Subject: delaying an update In-Reply-To: <200907082100.01577.opensource@till.name> References: <1247062883.6598.4.camel@choeger6> <1247064066.3501.4.camel@politzer.theorphys.helsinki.fi> <1247066269.19468.0.camel@choeger6> <200907082100.01577.opensource@till.name> Message-ID: <1247088690.19468.1.camel@choeger6> Thanks. Did it. -------------- 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 mrsam at courier-mta.com Wed Jul 8 22:12:46 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Wed, 08 Jul 2009 18:12:46 -0400 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <1246917991.25343.8673.camel@atropine.boston.devel.redhat.com> Message-ID: Kevin Kofler writes: > What he was talking about is that rediffing patches, i.e. making patches > apply to a new upstream version (that's what "rediffing" means for us Fedora > packagers), is more likely to break for configure.ac than for configure. And that's exactly what I said. Thank you for agreeing with me, that fixing configure is less likely to cause problems in the long run. >> Which happens far less often than routine changes to configure.ac, as the >> package natural evolves over time. autoconf changes happens maybe once >> every other year or so. Most configure script change far more often than >> once every other year. > > I don't know what upstreams you worked with. For the projects I worked on > with Romain Li?vin, he generally ran autoreconf with what was current on > Debian unstable or testing that day and me with what was current on Fedora > (stable updates) that day. The stuff would even ping-pong between the Debian Well, I don't know what those projects were, but here's a better known example. I just downloaded all available versions of the 2.4 branch of openldap, and greped their configure script. The results are: openldap-2.4.6/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.7/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.8/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.9/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.10/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.11/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.12/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.13/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.14/configure:# Generated by GNU Autoconf 2.61. openldap-2.4.15/configure:# Generated by GNU Autoconf 2.61. openldap-2.4.16/configure:# Generated by GNU Autoconf 2.61. Now, let's grep configure.in: openldap-2.4.6/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.7 2007/10/16 23:43:09 quanah Exp $ openldap-2.4.7/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.7 2007/10/16 23:43:09 quanah Exp $ openldap-2.4.8/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.9 2008/02/11 23:26:37 kurt Exp $ openldap-2.4.9/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.9 2008/02/11 23:26:37 kurt Exp $ openldap-2.4.10/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.9 2008/02/11 23:26:37 kurt Exp $ openldap-2.4.11/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.9 2008/02/11 23:26:37 kurt Exp $ openldap-2.4.12/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.14 2008/09/17 22:54:33 quanah Exp $ openldap-2.4.13/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.17 2008/11/21 01:26:24 quanah Exp $ openldap-2.4.14/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.22 2009/01/26 21:54:23 quanah Exp $ openldap-2.4.15/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.22 2009/01/26 21:54:23 quanah Exp $ openldap-2.4.16/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.22 2009/01/26 21:54:23 quanah Exp $ Over a span of nearly two years, openldap updated their autotools exactly once, while configure.in changed six times (with several additional intervening changes in-between consecutive releases). Which busy project would you like to repeat this experiment with? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From bernie at codewiz.org Wed Jul 8 22:32:25 2009 From: bernie at codewiz.org (Bernie Innocenti) Date: Thu, 09 Jul 2009 00:32:25 +0200 Subject: Can we import dia 0.97 in rawhide? In-Reply-To: <200907081136.19762.cemeyer@u.washington.edu> References: <1247076321.24440.22.camel@localhost> <200907081136.19762.cemeyer@u.washington.edu> Message-ID: <1247092345.3606.57.camel@localhost> On Wed, 2009-07-08 at 11:36 -0700, Conrad Meyer wrote: > File a bug. Found one already filed here: https://bugzilla.redhat.com/show_bug.cgi?id=502870 -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ From MathStuf at gmail.com Wed Jul 8 22:53:49 2009 From: MathStuf at gmail.com (Ben Boeckel) Date: Wed, 08 Jul 2009 18:53:49 -0400 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sam Varshavchik wrote: Frankly, all of this would scare me away from the autotools. If all that can happen from patching a small file rather than a monster file... Forcing version x.y of some tool and then shipping the results of using said tool and then slapping the hands of those who try to move forward with a new version seems to me that something is wrong. - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpVI30ACgkQiPi+MRHG3qTD8wCdEDKzia6Sig67u5TFuQGnDmSe xDEAoK+oUfvYZAHzuEb+Z4NbBdEcnuzK =Cuty -----END PGP SIGNATURE----- From kevin.kofler at chello.at Wed Jul 8 22:59:55 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 09 Jul 2009 00:59:55 +0200 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <1246917991.25343.8673.camel@atropine.boston.devel.redhat.com> Message-ID: Sam Varshavchik wrote: > Kevin Kofler writes: >> What he was talking about is that rediffing patches, i.e. making patches >> apply to a new upstream version (that's what "rediffing" means for us >> Fedora packagers), is more likely to break for configure.ac than for >> configure. > > And that's exactly what I said. Thank you for agreeing with me, that > fixing configure is less likely to cause problems in the long run. That's just because I made a mispaste. ;-) So let's try again: What he was talking about is that rediffing patches, i.e. making patches apply to a new upstream version (that's what "rediffing" means for us Fedora packagers), is more likely to break for configure than for configure.ac. (Check the actual citation if you don't believe me.) Kevin Kofler From bernie at codewiz.org Wed Jul 8 23:14:48 2009 From: bernie at codewiz.org (Bernie Innocenti) Date: Thu, 09 Jul 2009 01:14:48 +0200 Subject: readline update? In-Reply-To: <20090703102747.GA32668@localhost> References: <20090703102747.GA32668@localhost> Message-ID: <1247094888.3606.62.camel@localhost> On Fri, 2009-07-03 at 12:27 +0200, Miroslav Lichvar wrote: > devtodo-0.1.20-3.fc12 I maintain this package in Fedora. Just wrote the author asking for a clarification on licensing. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ From mrsam at courier-mta.com Wed Jul 8 23:21:19 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Wed, 08 Jul 2009 19:21:19 -0400 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <1246917991.25343.8673.camel@atropine.boston.devel.redhat.com> Message-ID: Kevin Kofler writes: > Sam Varshavchik wrote: > >> Kevin Kofler writes: >>> What he was talking about is that rediffing patches, i.e. making patches >>> apply to a new upstream version (that's what "rediffing" means for us >>> Fedora packagers), is more likely to break for configure.ac than for >>> configure. >> >> And that's exactly what I said. Thank you for agreeing with me, that >> fixing configure is less likely to cause problems in the long run. > > That's just because I made a mispaste. ;-) > > So let's try again: > > What he was talking about is that rediffing patches, i.e. making patches > apply to a new upstream version (that's what "rediffing" means for us > Fedora packagers), is more likely to break for configure than for > configure.ac. And I already pointed out why this is not true, several times. Furthermore, one part of your argument is that it is supposedly true because most changes to configure are due to autoconf getting updated, rather than any actual changes to configure.ac. In my last message, rather than speculate I posted logs from a randomly chosen project, openldap, that showed that to be not the case. I don't really have enough spare time to try downloading all releases, over the course of two years, of one project after another, trying to cherry-pick my example. Openldap was the first one that came to mind. I am confident that I am right, on this topic, so it was fairly likely that openldap's tarballs would've proved my point. They did, and you ignored it. I invite you to find a counterexample, but I regret to inform you, finding one won't be easy. Your other argument is that a patch to configure is less likely to require manual rebasing after configure changes, rather than an equivalent one to configure.ac, because new versions of autotools end up generating major changes to configure. Well, I just showed that routine changes to configure.ac occur far more often than updated to autoconf. Furthermore, as I pointed out, changes to nearby lines in configure.ac result in corresponding changes to configure being hundreds of lines apart, therefore a change to configure.ac is going to require rebasing of any patches to nearby lines, while the equivalent change to configure (once again -- for those with a short attention span -- that's a real patch to configure, and not a change to configure.ac, a regenerated configure, and a diff against the original version of configure) will therefore still apply, at most with some fuzz, and can therefore be rebased automatically. Conclusion: given a patch to configure.ac, and a patch to configure, an update to autotools is far likely to require more work to maintain the configure patch, while an update to configure.ac will likely require more woth main the configure.ac. And, this is the most likely outcome given, as I pointed out in openldap's case, which you would like to ignore, happens far more often than autotools update. Case closed. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From bill at bfccomputing.com Wed Jul 8 23:34:03 2009 From: bill at bfccomputing.com (Bill McGonigle) Date: Wed, 08 Jul 2009 19:34:03 -0400 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: References: <4A486F85.7000109@gmail.com> <4A53C43E.2030600@bfccomputing.com> Message-ID: <4A552CEB.7090700@bfccomputing.com> On 07/07/2009 07:42 PM, Kevin Kofler wrote: > RAND does not necessarily mean royalty-free Oh, I agree. The trick is nobody knows what those RAND terms are. Free, not free, something-we-never-dreamed-of, etc. Various folks (e.g. OSNews) have been attempting to get Microsoft to present them with a RAND license offer to clear this up. So, the legal theory is that since ECMA requires RAND license terms, and the spec is a published ECMA spec, and various people have been trying to get a RAND license offer for a while, that if Microsoft drags you before a magistrate charging that you didn't get a license, that "licenses were not available and therefore implicitly not required" would convince him that the prosecution is malicious and get the case tossed out on its ear. Whether the argument holds any water or not, I have no idea, it's just what I've heard from defenders. -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/ Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: bill at bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf From dchen at redhat.com Thu Jul 9 00:44:37 2009 From: dchen at redhat.com (Ding-Yi Chen) Date: Thu, 09 Jul 2009 10:44:37 +1000 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: References: <1141049532.126321247017793735.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <294841555.126761247018391415.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1247100277.4738.27.camel@localhost.localdomain> ? ??2009-07-08 ? 11:37 +0200?Kevin Kofler ??? > Ding Yi Chen wrote: > > Tell Denture your constraint and > > it will build packages if it can; or reasons why it cannot build. > > The word "build" there is another big fail. Users DO NOT WANT to build their > packages from source. If they did, they'd all be using Gentoo! Users with rpm building knowledge can build. Users came from FreeBSD and Gentoo are familar with build. Even those ex-Windows users, if there is good GUI that only require you to click on "Next" or "Ok", they don't mind to build. *Sign*, well, How about following prompt: Denture will build the package for you, however, in order to do so, it will consume cpu time, disk space, network bandwidth, proceed? -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ From kevin.kofler at chello.at Thu Jul 9 00:58:00 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 09 Jul 2009 02:58 +0200 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <1246917991.25343.8673.camel@atropine.boston.devel.redhat.com> Message-ID: Sam Varshavchik wrote: > In my last message, rather than speculate I posted logs from a randomly > chosen project, openldap, that showed that to be not the case. That's one project. It doesn't prove any sort of a general trend. > I invite you to find a counterexample, but I regret to inform you, finding > one won't be easy. I already mentioned a bunch of counterexamples (all the stuff I worked on with Romain Li?vin: tfdocgen, libticables2, libticonv, libtifiles2, libticalcs2, TiLP 2, TiEmu, TiLP GFM, TiEmu SkinEdit etc.). > Well, I just showed that routine changes to configure.ac occur far more > often than updated to autoconf. You just found one project which is extremely reluctant to upgrade their autoconf (and it's one of those projects still using the deprecated "configure.in" file name, that says pretty much everything). > Conclusion: given a patch to configure.ac, and a patch to configure, an > update to autotools is far likely to require more work to maintain the > configure patch, while an update to configure.ac will likely require more > woth main the configure.ac. And, this is the most likely outcome given, as > I pointed out in openldap's case, which you would like to ignore, happens > far more often than autotools update. I'm ignoring your example because it's one example against 9+ examples from me, plus Adam Jackson's packaging experiences which started this subthread. You just found the exception. > Case closed. No, your argumentation is based on false premises. Kevin Kofler From brent at brentnorris.net Thu Jul 9 01:04:17 2009 From: brent at brentnorris.net (Brent Norris) Date: Wed, 08 Jul 2009 20:04:17 -0500 Subject: Anybody know how to contact Axel Thimm (again)? In-Reply-To: <4A54DD7B.6070505@gmail.com> References: <20090708172628.GM4580@alpha.rzhou.org> <4A54D7B6.9060302@jcomserv.net> <20090708174115.GN4580@alpha.rzhou.org> <4A54DA64.8020002@jcomserv.net> <20090708175136.GA1341@nostromo.devel.redhat.com> <4A54DD7B.6070505@gmail.com> Message-ID: <4A554211.6020003@brentnorris.net> Frank Murphy wrote: > On 08/07/09 18:51, Bill Nottingham wrote: >> Jon Ciesla (limb at jcomserv.net) said: >>>>> Is he not responding at Axel.Thimm at ATrpms.net? >>>> That's his bugzilla email addess, so that seems to be the case :-( >>> What about ixs at fedoraproject.org? >> ixs at fp.o is not Axel. athimm at fp.o just goes to the ATrpms.net e-mail address. >> >> Bill >> > > Try a who is, it will give an extra addy. > > > Frank > Axel just replied to something from the axel.thimm at atrpms.net address on his own list today. Is it possible there is a routing issue or something? I will forward one of these mails to his mailing list perhaps he just isn't getting the messages. Brent From tcallawa at redhat.com Thu Jul 9 01:04:31 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 08 Jul 2009 21:04:31 -0400 Subject: an update to automake-1.11? In-Reply-To: References: <20090630213457.GC22149@redhat.com> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <1246917991.25343.8673.camel@atropine.boston.devel.redhat.com> Message-ID: <4A55421F.6090307@redhat.com> On 07/08/2009 08:58 PM, Kevin Kofler wrote: > Sam Varshavchik wrote: >> Case closed. > > No, your argumentation is based on false premises. Perhaps I wasn't clear in my last post. You two need to take this offlist, or simply let this thread stop by agreeing to disagree. This is the last friendly warning I'm giving before triggering the "hall monitor"/"moderation" policies. ~spot From mike at miketc.net Thu Jul 9 01:20:03 2009 From: mike at miketc.net (Mike Chambers) Date: Wed, 08 Jul 2009 20:20:03 -0500 Subject: Partitioning error during install Message-ID: <1247102403.9797.9.camel@scrappy.miketc.net> I have a 500G Sata Drive that I have F11 installed on half of it, using 3 primary partitions (/boot, / and swap). Now, I want to run rawhide on the other half, via F11 and update to rawhide (which I understand is not exactly running smoothly), or install rawhide itself. But the problem I run into (no matter which I install), is when I get to the partition section. I go to add a partition - not as a primary (this should allow it to be an extended correct?) - and I get an error and can't proceed any longer. So either anaconda is having problems with this setup (due to the rewrite?), or I am doing something wrong causing it to crash. BTW, when I say as or not as a primary partition, I mean I am actually checking or not checking the "make it a primary partition" check box. Any ideas? -- Mike Chambers Madisonville, KY Fedora Project - Bugzapper, Tester, User, etc.. miketc302 at fedoraproject.org From huzaifas at redhat.com Thu Jul 9 01:35:23 2009 From: huzaifas at redhat.com (Huzaifa Sidhpurwala) Date: Thu, 09 Jul 2009 07:05:23 +0530 Subject: Can we import dia 0.97 in rawhide? In-Reply-To: <1247076321.24440.22.camel@localhost> References: <1247076321.24440.22.camel@localhost> Message-ID: <4A55495B.6090306@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes, i am doing it. Bernie Innocenti wrote: > It's been released here: > > http://projects.gnome.org/dia/ > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkpVSVoACgkQzHDc8tpb2uV75gCgnbQ197n8Xu0X+SwSyopcB1/j saEAn1QSz90pMk+wvPKcLNPy/TX6d26J =DB5Q -----END PGP SIGNATURE----- From mrsam at courier-mta.com Thu Jul 9 01:42:27 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Wed, 08 Jul 2009 21:42:27 -0400 Subject: an update to automake-1.11? References: <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> <4A4FEB67.8070905@gmail.com> <20090705131655.GA21540@amd.home.annexia.org> <20090705213045.GB22871@amd.home.annexia.org> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <1246917991.25343.8673.camel@atropine.boston.devel.redhat.com> Message-ID: Kevin Kofler writes: > Sam Varshavchik wrote: >> In my last message, rather than speculate I posted logs from a randomly >> chosen project, openldap, that showed that to be not the case. > > That's one project. It doesn't prove any sort of a general trend. That's one more project's worth of data that you posted yourself. >> I invite you to find a counterexample, but I regret to inform you, finding >> one won't be easy. > > I already mentioned a bunch of counterexamples (all the stuff I worked on > with Romain Li?vin: tfdocgen, libticables2, libticonv, libtifiles2, > libticalcs2, TiLP 2, TiEmu, TiLP GFM, TiEmu SkinEdit etc.). Rattling off a bunch of project names is a poor substitute for posting two years' worth of data. Why don't you grab the last one or two years' worth of these projects' releases, and see how many releases had updated configure.ac scripts, and how many releases were rebased to newer versions of autoconf. You know, like what I did, for openldap. But, I'm pretty sure I know what you'll expect to find. And you know the same thing, too. And which is why you don't want to do it. >> Well, I just showed that routine changes to configure.ac occur far more >> often than updated to autoconf. > > You just found one project which is extremely reluctant to upgrade their > autoconf (and it's one of those projects still using the deprecated > "configure.in" file name, that says pretty much everything). No, it means that there is absolutely no reason to rename a file, just for the heck of it. Whether it's configure.in or configure.ac, it's irrelevant. Or, perhaps, you'd like to explain the major difference between naming the source file for autoconf as configure.in, or configure.ac. And I didn't really do much of finding, as I said. It's one of the packages that I'm tracking on http://manpages.courier-mta.org which has the largest archive of historical releases. But, you're demanding to look at some project that uses configure.ac? Sure. Not that it makes one fig's worth of difference, of course, whether it's configure.in or configure.ac, but here you go: pcre. It's another one that I'm tracking. Upstream only has the last four releases available, but they also span about a year and a half chronologically, rougly the same time span as openldap: pcre-7.6/configure:# Generated by GNU Autoconf 2.61 for PCRE 7.6. pcre-7.7/configure:# Generated by GNU Autoconf 2.61 for PCRE 7.7. pcre-7.8/configure:# Generated by GNU Autoconf 2.61 for PCRE 7.8. pcre-7.9/configure:# Generated by GNU Autoconf 2.63 for PCRE 7.9. Looking at pcre's configure.acs, only pcre-7.8 had no substantive changes from the previous version, all the others contained very major changes. Looks like this one doesn't agree with your theory, too. So go ahead, and tell me again how that's still insufficient data for your liking (all the while offering zilch of hard data yourself, I note). I'll be happy to continue, as long as you like, but, you must understand, the hits will just keep on comin'. I also snuck a peek at the evolution of GnuTLS's toolchain. I guessed that it would be your best hope of salvaging some crumb of hard data that goes your way -- given that it's a GNU project and thus would be the most likely ones to always rebase to the latest-and-greatest autotools. Well, I looked at it, and would you like to see how GnuTLS's version history actually is? I'll be happy to post it. All you have to do is ask. >> Conclusion: given a patch to configure.ac, and a patch to configure, an >> update to autotools is far likely to require more work to maintain the >> configure patch, while an update to configure.ac will likely require more >> woth main the configure.ac. And, this is the most likely outcome given, as >> I pointed out in openldap's case, which you would like to ignore, happens >> far more often than autotools update. > > I'm ignoring your example because it's one example against 9+ examples from > me, You did not post a single example. Rattling off names of packages is not the same thing as actually listing which version of autoconf generated each version, and how many original changes went into the corresponding configure.in (or configure.ac), thus giving you an actual look at what the rate of change is to configure.ac, versus the rate of change to the version of autotools that generated the configure script. Why don't you do that, and really prove how wrong I am? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From itamar at ispbrasil.com.br Thu Jul 9 05:15:54 2009 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Thu, 9 Jul 2009 02:15:54 -0300 Subject: fedora EPEL packages. Message-ID: since now the people is able to build EPEL packages, why not ask to the people when it's request cvs branch's to maintain EPEL packages too ? -- ------------ Itamar Reis Peixoto e-mail/msn: itamar at ispbrasil.com.br sip: itamar at ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 From mschwendt at gmail.com Thu Jul 9 06:03:55 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 9 Jul 2009 08:03:55 +0200 Subject: fedora EPEL packages. In-Reply-To: References: Message-ID: <20090709080355.5eeeaabb@faldor> On Thu, 9 Jul 2009 02:15:54 -0300, Itamar wrote: > since now the people is able to build EPEL packages, "since now"? The people have been able to build EPEL packages for a much longer time. The only thing that's new is that koji+bodhi can be used. > why not ask to > the people when it's request cvs branch's to maintain EPEL packages > too ? They still decide for themselves whether they want to maintain a package for EPEL. I mean, EPEL is not a secret project. If a Fedora Packager has not heard about EPEL, [s]he probably doesn't use RHEL or CentOS either. From kanarip at kanarip.com Tue Jul 7 23:38:50 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 08 Jul 2009 01:38:50 +0200 Subject: Feature proposal: Extended Life Cycle Support In-Reply-To: <1246984740.8303.6.camel@localhost.localdomain> References: <4A4FD09C.7000809@kanarip.com> <1246918076.2965.33.camel@localhost.localdomain> <4A535AA8.4020405@kanarip.com> <1246984740.8303.6.camel@localhost.localdomain> Message-ID: <4A53DC8A.50103@kanarip.com> On 07/07/2009 06:39 PM, Jesse Keating wrote: > On Tue, 2009-07-07 at 16:24 +0200, Jeroen van Meeuwen wrote: >> If you take into account that the proposal concerns security fixes only, >> then every update has to be labeled a security update (and preferably >> have some kind of CVE/bug# attached??). We would need to think about a >> policy for that, agreed. > > Yeah, if you pick the line at say "critical" then every update would > have a CVE, or would be bundled in bodhi with the package that had the > CVE. So say webkit needs updating due to a CVE, you would bundle all > the dependent packages in the same update, and the whole update itself > would have the CVE listing, and would have just once announcement. > +1, my thoughts exactly. >> The measure of success is particularly hard to state in figures. Just >> thinking about some measures of success though, it would include; >> >> - increased participation from the Fedora side of things >> - continuous flow of security updates (and bugs against EOS releases solved) >> - increased consumption >> >> and maybe there's more. Number of subscriptions to an announcement / >> errata type of mailing list maybe? Number of subscriptions to a ELC SIG >> mailing list? > > Could go by time it takes to get a CVE discovered/fixed, how many are > slipping through, karma on the updates, or just mirrormanager hits on > the repos. > Agreed, these certainly are measurables. Might be a little harder to get some figures on, but we'd have to figure it out at some point anyway. >>> * A timeline to go with the above to review for success/failure >>> >> Here's where the initial proposed extension of 6 months kicks in. I >> would say our first review is what is now called "Alpha freeze" -the >> milestone where Features are checked for their readiness -whether this >> proposal ends up being an actual feature or not. > > I would think 6 months might be a little too short. Why not give it a > year? > 6 months would be what we can commit to now, right now, to extend the life cycle of one Fedora release with. Depending on those results, and it's success, we might be able to 1) extend the life cycle a little more, and/or 2) take on a second release's extended life cycle. >>> * A responsible body behind the effort to make regular reports to >>> FESCo/Board >>> >> This is not up to me ;-) I guess we'll hear from FESCo, on whether they >> think this is a feature, on whether they think this is in their mandate, >> on whether they think this has to go to the Board. > > You're driving the feature, but don't want to be responsible for the > feature? odd? > Yes, I'm driving the feature. That doesn't mean I'm in a position to say anything definitive ;-) I'm not elected, chosen, endorsed, unique in this initiative, or anything else, I'm just driving it. Even if I were to be assigned a leading position within whatever governance body should govern this feature/initiative, I'd not be in control -like I said before though; different subject ;-) If, supposedly, FESCo (or the Board) says "hell yeah" (or just 'yes', which would do) to the initiative, then I suppose we put our jewels on the table and determine the final shape and form of the project. >>> Who is going to track and discover the security issues? >>> >> To be determined. Could be delegated to a (dedicated?) small(er) group >> of people within the SIG (to be set up) -maybe the not-so-technical??, >> or could be a responsible of each individual participating. > > Ok, so long as your aware that somebody or somebodies will need to > monitor the entire package set for CVEs (something we're probably > missing to some extent already). > > And so this has to be resolved from a Fedora Project wide perspective rather then just be assigned to the people that co-incidentally said "security fixes only". This can not and will not ever be a measurable against the ELC feature if the Fedora Project itself does not have the same or similar procedures approved and implemented. If we miss out on a few, or many, then we're bad. If the Fedora Project misses out on just as much, then we're good, within the bad, bad Fedora Project. Even though a Fedora release is much less likely to have security issues linger around for a while due to frequent updates being available for virtually any given application, the Fedora Project sets the standard in this case, not vice-versa ;-) -- Jeroen From yersinia.spiros at gmail.com Thu Jul 9 07:32:54 2009 From: yersinia.spiros at gmail.com (yersinia) Date: Thu, 9 Jul 2009 09:32:54 +0200 Subject: fedora EPEL packages. In-Reply-To: <20090709080355.5eeeaabb@faldor> References: <20090709080355.5eeeaabb@faldor> Message-ID: On Thu, Jul 9, 2009 at 8:03 AM, Michael Schwendt wrote: > On Thu, 9 Jul 2009 02:15:54 -0300, Itamar wrote: > > > since now the people is able to build EPEL packages, > > "since now"? The people have been able to build EPEL packages for > a much longer time. The only thing that's new is that koji+bodhi > can be used. > > > why not ask to > > the people when it's request cvs branch's to maintain EPEL packages > > too ? > > They still decide for themselves whether they want to maintain > a package for EPEL. I mean, EPEL is not a secret project. If a Fedora > Packager has not heard about EPEL, [s]he probably doesn't use RHEL > or CentOS either. > If someone want mantain an package for EPEL but the maintainer for FEDORA don't, it is possible for someone else to do ? Thanks > > -- > 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 sundaram at fedoraproject.org Thu Jul 9 07:35:13 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 09 Jul 2009 13:05:13 +0530 Subject: fedora EPEL packages. In-Reply-To: References: <20090709080355.5eeeaabb@faldor> Message-ID: <4A559DB1.4030201@fedoraproject.org> On 07/09/2009 01:02 PM, yersinia wrote: > If someone want mantain an package for EPEL but the maintainer for > FEDORA don't, it is possible for someone else to do ? Yes. Refer to the EPEL FAQ. http://fedoraproject.org/wiki/EPEL/FAQ Rahul From yersinia.spiros at gmail.com Thu Jul 9 07:47:20 2009 From: yersinia.spiros at gmail.com (yersinia) Date: Thu, 9 Jul 2009 09:47:20 +0200 Subject: an update to automake-1.11? In-Reply-To: <1246985140.1347.4142.camel@localhost> References: <20090630213457.GC22149@redhat.com> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <4A527638.1040004@gmail.com> <4A528140.2070100@endoframe.com> <4A528A85.3010704@gmail.com> <1246936191.1347.2466.camel@localhost> <4A5304AF.3020905@gmail.com> <1246985140.1347.4142.camel@localhost> Message-ID: On Tue, Jul 7, 2009 at 6:45 PM, Braden McDaniel wrote: > On Tue, 2009-07-07 at 01:17 -0700, Toshio Kuratomi wrote: > > On 07/06/2009 08:09 PM, Braden McDaniel wrote: > > > On Mon, 2009-07-06 at 16:36 -0700, Toshio Kuratomi wrote: > > >> On 07/06/2009 03:57 PM, Braden McDaniel wrote: > > >>> On 7/6/09 6:10 PM, Toshio Kuratomi wrote: > > >>> > > >>> [snip] > > >>> > > >>>> Introducing side-effects is something to watch out for but > > >>>> patching configure instead of the true source is a short term fix, > not a > > >>>> long term solution. > > >>> > > >>> *Any* patch should be viewed as a short-term fix. A patch that needs > to > > >>> persist indefinitely suggests broken maintainership somewhere along > the > > >>> line--either upstream, of the Fedora package in question, or > elsewhere > > >>> in Fedora's infrastructure. > > >>> > > >> But one of those patches is upstreamable and the other is not. > > >> The upstreamable patch is a step on the road to the long term fix. > The > > >> non-upstreamable one is a dead-end. > > > > > > Creating a patch to configure/Makefile.in in no way precludes a package > > > maintainer from sending an analogous patch to configure.ac/Makefile.am > > > upstream. So, yes, it's a "dead end" that: > > > > > > 1. reduces the size of the changeset between the upstream package > > > and the one Fedora actually builds and > > > 2. improves the resiliency of the package build to changes to > > > Fedora's autotools chain. > > > > > Perhaps but it doesn't decrease the work that the maintainer has to do. > > It very well might if Fedora upgrades to a new autoconf, automake, or > libtool that is not 100% backward compatible with the previous version. > It is not hard at all to have ALL the version of autotool installed. Simply pick one (for example for automake) version for the default (for example 1.10 ) and call this package automake. If you want also automake 1.11 package this as automake-1.11 rpm and, if the developer want, it is its choice, use this instead of the default via the autotool env var. I do this in RHEL also for libtool 2.2 ecc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yersinia.spiros at gmail.com Thu Jul 9 07:50:56 2009 From: yersinia.spiros at gmail.com (yersinia) Date: Thu, 9 Jul 2009 09:50:56 +0200 Subject: an update to automake-1.11? In-Reply-To: References: <20090630213457.GC22149@redhat.com> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <4A527638.1040004@gmail.com> <4A528140.2070100@endoframe.com> <4A528A85.3010704@gmail.com> <1246936191.1347.2466.camel@localhost> <4A5304AF.3020905@gmail.com> <1246985140.1347.4142.camel@localhost> Message-ID: On Thu, Jul 9, 2009 at 9:47 AM, yersinia wrote: > On Tue, Jul 7, 2009 at 6:45 PM, Braden McDaniel wrote: > >> On Tue, 2009-07-07 at 01:17 -0700, Toshio Kuratomi wrote: >> > On 07/06/2009 08:09 PM, Braden McDaniel wrote: >> > > On Mon, 2009-07-06 at 16:36 -0700, Toshio Kuratomi wrote: >> > >> On 07/06/2009 03:57 PM, Braden McDaniel wrote: >> > >>> On 7/6/09 6:10 PM, Toshio Kuratomi wrote: >> > >>> >> > >>> [snip] >> > >>> >> > >>>> Introducing side-effects is something to watch out for but >> > >>>> patching configure instead of the true source is a short term fix, >> not a >> > >>>> long term solution. >> > >>> >> > >>> *Any* patch should be viewed as a short-term fix. A patch that >> needs to >> > >>> persist indefinitely suggests broken maintainership somewhere along >> the >> > >>> line--either upstream, of the Fedora package in question, or >> elsewhere >> > >>> in Fedora's infrastructure. >> > >>> >> > >> But one of those patches is upstreamable and the other is not. >> > >> The upstreamable patch is a step on the road to the long term fix. >> The >> > >> non-upstreamable one is a dead-end. >> > > >> > > Creating a patch to configure/Makefile.in in no way precludes a >> package >> > > maintainer from sending an analogous patch to >> configure.ac/Makefile.am >> > > upstream. So, yes, it's a "dead end" that: >> > > >> > > 1. reduces the size of the changeset between the upstream package >> > > and the one Fedora actually builds and >> > > 2. improves the resiliency of the package build to changes to >> > > Fedora's autotools chain. >> > > >> > Perhaps but it doesn't decrease the work that the maintainer has to do. >> >> It very well might if Fedora upgrades to a new autoconf, automake, or >> libtool that is not 100% backward compatible with the previous version. >> > > It is not hard at all to have ALL the version of autotool installed. Simply > pick one > (for example for automake) version for the default (for example 1.10 ) and > call > this package automake. If you want also automake 1.11 package this as > automake-1.11 rpm > and, if the developer want, it is its choice, use this instead of the > default via the autotool env var. I do this in RHEL > also for libtool 2.2 ecc. > > And for gcc ecc. - so not only "compat" package but "upstream" package - without support as it is but if my user want, why not ? Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From yersinia.spiros at gmail.com Thu Jul 9 08:10:09 2009 From: yersinia.spiros at gmail.com (yersinia) Date: Thu, 9 Jul 2009 10:10:09 +0200 Subject: noarch subpackages In-Reply-To: <9514c41a0ff9d6e5be9b2ad6f16331d6.squirrel@intranet.cs.nmsu.edu> References: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> <20090708170639.21f9b4bf@faldor> <9514c41a0ff9d6e5be9b2ad6f16331d6.squirrel@intranet.cs.nmsu.edu> Message-ID: On Wed, Jul 8, 2009 at 5:07 PM, Rick L. Vinyard, Jr. wrote: > Michael Schwendt wrote: > > On Wed, 8 Jul 2009 07:59:43 -0600, Jr. wrote: > > > >> What is the effect on non-Fedora and older distributions (pre F10) if I > >> mark a subpackage (such as documentation) with BuildArch: noarch? > > > > You can evaluate the %fedora variable to use this new feature only > > for Fedora >= 10: > > > > %if 0%{?fedora} > 9 > > BuildArch: noarch > > %endif > > > > Excellent. That's what I was looking for. > No, it is not right for me. The BuildArch issue depends on the RPM version and not from from distro version. It is simply bad style, IMHO, defining in the SPEC file something that depends from the "distribution" (in the large sense not only fedora). I never see this style in RHEL package (appart some little package for the rpm keys ecc). Ok is SUSE yes but, again, i don't like define a dependency based on a "distro" version, if possible anyway. regards > > -- > 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 frankly3d at gmail.com Thu Jul 9 08:27:01 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Thu, 09 Jul 2009 09:27:01 +0100 Subject: an update to automake-1.11? In-Reply-To: References: <20090630213457.GC22149@redhat.com> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <1246917991.25343.8673.camel@atropine.boston.devel.redhat.com> Message-ID: <4A55A9D5.3070601@gmail.com> Take 5, take note of Spot's msg. Regards, Frank From opensource at till.name Thu Jul 9 08:31:24 2009 From: opensource at till.name (Till Maas) Date: Thu, 09 Jul 2009 10:31:24 +0200 Subject: hall monitor / moderation policies (was: Re: an update to automake-1.11?) In-Reply-To: <4A55421F.6090307@redhat.com> References: <20090630213457.GC22149@redhat.com> <4A55421F.6090307@redhat.com> Message-ID: <200907091031.36225.opensource@till.name> On Thu July 9 2009, Tom "spot" Callaway wrote: > Perhaps I wasn't clear in my last post. You two need to take this > offlist, or simply let this thread stop by agreeing to disagree. This is > the last friendly warning I'm giving before triggering the "hall > monitor"/"moderation" policies. Is the policy documented somewhere? I only found a meeting summary, which imho does not qualify as proper documentation: http://fedoraproject.org/wiki/Board/Meetings/2009-05-14 Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From bernie at codewiz.org Thu Jul 9 09:01:53 2009 From: bernie at codewiz.org (Bernie Innocenti) Date: Thu, 09 Jul 2009 11:01:53 +0200 Subject: readline update? In-Reply-To: <1247094888.3606.62.camel@localhost> References: <20090703102747.GA32668@localhost> <1247094888.3606.62.camel@localhost> Message-ID: <1247130113.3606.234.camel@localhost> On Thu, 2009-07-09 at 01:14 +0200, Bernie Innocenti wrote: > On Fri, 2009-07-03 at 12:27 +0200, Miroslav Lichvar wrote: > > devtodo-0.1.20-3.fc12 > > I maintain this package in Fedora. Just wrote the author asking for a > clarification on licensing. FYI, I got this reply: -------- Forwarded Message -------- From: Alec Thomas To: Bernie Innocenti Subject: Re: License clarification for devtodo Date: Thu, 9 Jul 2009 12:02:04 +1000 I haven't looked at the GPLv3 to determine whether I'd actually want to license devtodo under it, but I'll take a look when I get a chance. Unfortunately I'm going on holidays for a month, so likely won't be able to until mid-August or so. 2009/7/9 Bernie Innocenti : > Hello, > > I'm packaging devtodo in Fedora. We can't link it against readline 6 > because it is GPLv3 and devtodo appears to be GPLv2 only. > > Is that right? If your intention actually was to make devtodo GPLv2 or > later, could you please release an updated source package with this fact > explained explicitly? > > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ From harsha.k.gowda at gmail.com Thu Jul 9 10:33:10 2009 From: harsha.k.gowda at gmail.com (Harsha gowda) Date: Thu, 9 Jul 2009 16:03:10 +0530 Subject: Hi help required for setting up a debug setup Message-ID: Hi, Setup build environment as you said earlier, Thanks for help I did followed all you said. * yum install fedora-rpmdevtools -y yum install rpmdevtools rpmdev-setuptree * I install the srpm as below *rpm -i /home/harsha/Download/wpa_supplicant-0.6.4-2.fc10.src.rpm * every time i will create the tar.gz file of the folder /root/rpmbuild/SOURCE/wpa_supplicant-0.6.4/ and compile as *rpmbuild -bs wpa_supplicant.spec * and i put* print statements and debug,* Can any one help me how can i use kdbg and use any kind of debug build where i can debug line by line... Please help me how to setup debug enveronment in fedora and debug line by line, I even installed *rpm -i wpa_supplicant-debuginfo-0.6.4-2.fc10.i386.rpm* the source is present at */usr/src/debug/* But could not find any pointers in net where i can debug line by line. Thanks for your replies Regards Harsha -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at camperquake.de Thu Jul 9 10:59:33 2009 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 9 Jul 2009 12:59:33 +0200 Subject: an update to automake-1.11? In-Reply-To: <4A55421F.6090307@redhat.com> References: <20090630213457.GC22149@redhat.com> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <1246917991.25343.8673.camel@atropine.boston.devel.redhat.com> <4A55421F.6090307@redhat.com> Message-ID: <20090709125933.668f92cb@dhcp03.addix.net> Hi. On Wed, 08 Jul 2009 21:04:31 -0400, Tom "spot" Callaway wrote: > Perhaps I wasn't clear in my last post. You two need to take this > offlist, or simply let this thread stop by agreeing to disagree. This > is the last friendly warning I'm giving before triggering the "hall > monitor"/"moderation" policies. While you may argue that this discussion does not lead anywhere, and you may even be right, the tone of the discussion is definitely technical and civil in my book. From ndbecker2 at gmail.com Thu Jul 9 11:37:28 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 09 Jul 2009 07:37:28 -0400 Subject: bodhi error Message-ID: bodhi -C igraph-0.5.2-1.fc9 dist-f9-updates-candidate qct-1.7-3.fc9 dist-f9-updates-candidate python-igraph-0.5.1-3.fc9 dist-f9-updates-candidate libotf-0.9.8-1.fc9 dist-f9-updates-candidate igraph-0.5.2-1.fc10 dist-f10-updates-candidate qct-1.7-3.fc10 dist-f10-updates-candidate Traceback (most recent call last): File "/usr/bin/bodhi", line 322, in main() File "/usr/bin/bodhi", line 230, in main for build in bodhi.candidates(): File "/usr/lib/python2.6/site-packages/fedora/client/bodhi.py", line 193, in candidates for build in self.koji_session.listTagged(tag, latest=True): File "/usr/lib/python2.6/site-packages/koji/__init__.py", line 1255, in __call__ return self.__func(self.__name,args,opts) File "/usr/lib/python2.6/site-packages/koji/__init__.py", line 1501, in _callMethod raise err koji.GenericError: No such entry in table tag: dist-4E-epel-updates- candidate From pknirsch at redhat.com Thu Jul 9 11:52:42 2009 From: pknirsch at redhat.com (Phil Knirsch) Date: Thu, 09 Jul 2009 13:52:42 +0200 Subject: Announcement: Weekly meeting for power management related things each Thursday 15:00 UTC (17:00 CET, 9:00 EST) on #fedora-meeting Message-ID: <4A55DA0A.7080409@redhat.com> Hi everyone. I just wanted to let everyone know that at FUDCon 2009 in Berlin we decided to make the whole power management effort a lot more transparent and do it the "proper" Open Source way. To do that we'll now be holding weekly meetings on the #fedora-meeting channel each Thursday at 15:00 UTC. Topics can vary wildly each week and everyone is welcome to bring up anything around power management. In order to track the whole work we're aiming for we've also started a (very skeleton at the moment) power management SIG: http://fedoraproject.org/wiki/SIGs/PowerManagement where we'll collect everything we'd like to see happen in Fedora over time in regard to power management. And again, everyone is more than welcome to participate here either in the discussions or the actual work that needs to be done. Thanks & see you there, Phil! -- Philipp Knirsch | Tel.: +49-711-96437-470 Team Lead Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany Motd: You're only jealous cos the little penguins are talking to me. From skvidal at fedoraproject.org Thu Jul 9 12:12:04 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 9 Jul 2009 08:12:04 -0400 (EDT) Subject: an update to automake-1.11? In-Reply-To: <20090709125933.668f92cb@dhcp03.addix.net> References: <20090630213457.GC22149@redhat.com> <1246888732.25343.8639.camel@atropine.boston.devel.redhat.com> <1246917991.25343.8673.camel@atropine.boston.devel.redhat.com> <4A55421F.6090307@redhat.com> <20090709125933.668f92cb@dhcp03.addix.net> Message-ID: On Thu, 9 Jul 2009, Ralf Ertzinger wrote: > Hi. > > On Wed, 08 Jul 2009 21:04:31 -0400, Tom "spot" Callaway wrote: > >> Perhaps I wasn't clear in my last post. You two need to take this >> offlist, or simply let this thread stop by agreeing to disagree. This >> is the last friendly warning I'm giving before triggering the "hall >> monitor"/"moderation" policies. > > While you may argue that this discussion does not lead anywhere, and > you may even be right, the tone of the discussion is definitely technical > and civil in my book. It was rapidly becoming less and less civil. Accusations of intellectual dishonesty and constantly repeating back and forth the same arguments are not going to keep it civil. Additionally, it was not necessarily civil to everyone else if only b/c of the massive volume of mail it was generating that is being delivered to everyone but only involving two people. It was time for that thread to be taken off list. -sv From kevin.kofler at chello.at Thu Jul 9 12:34:43 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 09 Jul 2009 14:34:43 +0200 Subject: noarch subpackages References: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> <20090708170639.21f9b4bf@faldor> <9514c41a0ff9d6e5be9b2ad6f16331d6.squirrel@intranet.cs.nmsu.edu> Message-ID: yersinia wrote: > No, it is not right for me. But it's just how things work. We conditionalize such things based on the Fedora (and possibly RHEL if the specfile supports RHEL or EPEL too) version. Our specfiles do not support any other distribution (by design). Kevin Kofler From MathStuf at gmail.com Thu Jul 9 12:48:56 2009 From: MathStuf at gmail.com (Ben Boeckel) Date: Thu, 09 Jul 2009 08:48:56 -0400 Subject: noarch subpackages References: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> <20090708170639.21f9b4bf@faldor> <9514c41a0ff9d6e5be9b2ad6f16331d6.squirrel@intranet.cs.nmsu.edu> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 yersinia wrote: > On Wed, Jul 8, 2009 at 5:07 PM, Rick L. Vinyard, Jr. > wrote: > >> Michael Schwendt wrote: >> > On Wed, 8 Jul 2009 07:59:43 -0600, Jr. wrote: >> > >> >> What is the effect on non-Fedora and older distributions (pre F10) if I >> >> mark a subpackage (such as documentation) with BuildArch: noarch? >> > >> > You can evaluate the %fedora variable to use this new feature only >> > for Fedora >= 10: >> > >> > %if 0%{?fedora} > 9 >> > BuildArch: noarch >> > %endif >> > >> >> Excellent. That's what I was looking for. >> > > No, it is not right for me. The BuildArch issue depends on the RPM version > and not from from distro version. It is simply bad style, IMHO, defining > in the SPEC file something that depends from the "distribution" (in the > large sense not only fedora). I never see > this style in RHEL package (appart some little package for the rpm keys > ecc). Ok is SUSE yes but, again, i don't like define a dependency based on > a "distro" version, if possible anyway. > > regards I don't think you should use a spec file for two distros. AFAIK, SuSE uses /opt for stuff. Fedora uses /usr. The file listings would be different for each. I don't think you can have an every-rpm-distro-under-the-sun specfile and not have it either messy or wrong. - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpV5zgACgkQiPi+MRHG3qTg4wCbBmmc7nSkN9NNF0xK94Evs11f 4xEAoLtciGgwjRkCl6wiGYt1v3pazh6l =L40w -----END PGP SIGNATURE----- From yersinia.spiros at gmail.com Thu Jul 9 13:41:06 2009 From: yersinia.spiros at gmail.com (yersinia) Date: Thu, 9 Jul 2009 15:41:06 +0200 Subject: noarch subpackages In-Reply-To: References: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> <20090708170639.21f9b4bf@faldor> <9514c41a0ff9d6e5be9b2ad6f16331d6.squirrel@intranet.cs.nmsu.edu> Message-ID: On Thu, Jul 9, 2009 at 2:48 PM, Ben Boeckel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > yersinia wrote: > > > On Wed, Jul 8, 2009 at 5:07 PM, Rick L. Vinyard, Jr. > > wrote: > > > >> Michael Schwendt wrote: > >> > On Wed, 8 Jul 2009 07:59:43 -0600, Jr. wrote: > >> > > >> >> What is the effect on non-Fedora and older distributions > (pre F10) if I > >> >> mark a subpackage (such as documentation) with BuildArch: > noarch? > >> > > >> > You can evaluate the %fedora variable to use this new > feature only > >> > for Fedora >= 10: > >> > > >> > %if 0%{?fedora} > 9 > >> > BuildArch: noarch > >> > %endif > >> > > >> > >> Excellent. That's what I was looking for. > >> > > > > No, it is not right for me. The BuildArch issue depends on the > RPM version > > and not from from distro version. It is simply bad style, > IMHO, defining > > in the SPEC file something that depends from the > "distribution" (in the > > large sense not only fedora). I never see > > this style in RHEL package (appart some little package for the > rpm keys > > ecc). Ok is SUSE yes but, again, i don't like define a > dependency based on > > a "distro" version, if possible anyway. > > > > regards > > I don't think you should use a spec file for two distros. AFAIK, > SuSE uses /opt for stuff. Fedora uses /usr. The file listings > would be different for each. I don't think you can have an > every-rpm-distro-under-the-sun specfile and not have it either > messy or wrong. > No everyone agreed with this or would the spec/rpm version frammentation go forever. http://www.mail-archive.com/rpm-maint at lists.rpm.org/msg00885.html http://www.mail-archive.com/rpm-maint at lists.rpm.org/msg00939.html Regards > > - --Ben > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkpV5zgACgkQiPi+MRHG3qTg4wCbBmmc7nSkN9NNF0xK94Evs11f > 4xEAoLtciGgwjRkCl6wiGYt1v3pazh6l > =L40w > -----END PGP SIGNATURE----- > > > -- > 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 rvinyard at cs.nmsu.edu Thu Jul 9 13:56:44 2009 From: rvinyard at cs.nmsu.edu (Rick L. Vinyard, Jr.) Date: Thu, 9 Jul 2009 07:56:44 -0600 Subject: noarch subpackages In-Reply-To: References: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> <20090708170639.21f9b4bf@faldor> <9514c41a0ff9d6e5be9b2ad6f16331d6.squirrel@intranet.cs.nmsu.edu> Message-ID: Kevin Kofler wrote: > Rick L. Vinyard, Jr. wrote: > >> Michael Schwendt wrote: >>> On Wed, 8 Jul 2009 07:59:43 -0600, Jr. wrote: >>> >>>> What is the effect on non-Fedora and older distributions (pre F10) if >>>> I >>>> mark a subpackage (such as documentation) with BuildArch: noarch? >>> >>> You can evaluate the %fedora variable to use this new feature only >>> for Fedora >= 10: >>> >>> %if 0%{?fedora} > 9 >>> BuildArch: noarch >>> %endif >>> >> >> Excellent. That's what I was looking for. > > Except it should be: > %if 0%{?fedora} > 9 || 0%{?rhel} > 5 > Does this cover CentOS as well? From rvinyard at cs.nmsu.edu Thu Jul 9 13:59:27 2009 From: rvinyard at cs.nmsu.edu (Rick L. Vinyard, Jr.) Date: Thu, 9 Jul 2009 07:59:27 -0600 Subject: multi-distro specs (was noarch subpackages) In-Reply-To: References: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> <20090708170639.21f9b4bf@faldor> <9514c41a0ff9d6e5be9b2ad6f16331d6.squirrel@intranet.cs.nmsu.edu> Message-ID: Ben Boeckel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > yersinia wrote: > >> On Wed, Jul 8, 2009 at 5:07 PM, Rick L. Vinyard, Jr. >> wrote: >> >>> Michael Schwendt wrote: >>> > On Wed, 8 Jul 2009 07:59:43 -0600, Jr. wrote: >>> > >>> >> What is the effect on non-Fedora and older distributions > (pre F10) if I >>> >> mark a subpackage (such as documentation) with BuildArch: > noarch? >>> > >>> > You can evaluate the %fedora variable to use this new > feature only >>> > for Fedora >= 10: >>> > >>> > %if 0%{?fedora} > 9 >>> > BuildArch: noarch >>> > %endif >>> > >>> >>> Excellent. That's what I was looking for. >>> >> >> No, it is not right for me. The BuildArch issue depends on the > RPM version >> and not from from distro version. It is simply bad style, > IMHO, defining >> in the SPEC file something that depends from the > "distribution" (in the >> large sense not only fedora). I never see >> this style in RHEL package (appart some little package for the > rpm keys >> ecc). Ok is SUSE yes but, again, i don't like define a > dependency based on >> a "distro" version, if possible anyway. >> >> regards > > I don't think you should use a spec file for two distros. AFAIK, > SuSE uses /opt for stuff. Fedora uses /usr. The file listings > would be different for each. I don't think you can have an > every-rpm-distro-under-the-sun specfile and not have it either > messy or wrong. > Doesn't %{_datadir} and %{_libdir} take care of that? From MathStuf at gmail.com Thu Jul 9 14:29:51 2009 From: MathStuf at gmail.com (Ben Boeckel) Date: Thu, 09 Jul 2009 10:29:51 -0400 Subject: multi-distro specs (was noarch subpackages) References: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> <20090708170639.21f9b4bf@faldor> <9514c41a0ff9d6e5be9b2ad6f16331d6.squirrel@intranet.cs.nmsu.edu> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rick L. Vinyard, Jr. wrote: > Ben Boeckel wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> yersinia wrote: >> >>> On Wed, Jul 8, 2009 at 5:07 PM, Rick L. Vinyard, Jr. >>> wrote: >>> >>>> Michael Schwendt wrote: >>>> > On Wed, 8 Jul 2009 07:59:43 -0600, Jr. wrote: >>>> > >>>> >> What is the effect on non-Fedora and older distributions >> (pre F10) if I >>>> >> mark a subpackage (such as documentation) with BuildArch: >> noarch? >>>> > >>>> > You can evaluate the %fedora variable to use this new >> feature only >>>> > for Fedora >= 10: >>>> > >>>> > %if 0%{?fedora} > 9 >>>> > BuildArch: noarch >>>> > %endif >>>> > >>>> >>>> Excellent. That's what I was looking for. >>>> >>> >>> No, it is not right for me. The BuildArch issue depends on the >> RPM version >>> and not from from distro version. It is simply bad style, >> IMHO, defining >>> in the SPEC file something that depends from the >> "distribution" (in the >>> large sense not only fedora). I never see >>> this style in RHEL package (appart some little package for the >> rpm keys >>> ecc). Ok is SUSE yes but, again, i don't like define a >> dependency based on >>> a "distro" version, if possible anyway. >>> >>> regards >> >> I don't think you should use a spec file for two distros. AFAIK, >> SuSE uses /opt for stuff. Fedora uses /usr. The file listings >> would be different for each. I don't think you can have an >> every-rpm-distro-under-the-sun specfile and not have it either >> messy or wrong. >> > > Doesn't %{_datadir} and %{_libdir} take care of that? Probably, which answers the concern there, but you still have package splits differing. Fedora has tarball-level splits. Other distros do app-level splits (Debian(-based) at least, though not RPM could still happen with an RPM distro). Still a filelists issue. You also have package naming to deal with. Though I suppose is a moot point as well if it's a side-effect of sharing spec files. - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpV/t8ACgkQiPi+MRHG3qQ8MgCeMnLynOUE0HrSYKW9qdRxRXHQ diUAn2M5yKt/X7MiNWIEJrvVPuqTbxQq =e6kq -----END PGP SIGNATURE----- From mattdm at mattdm.org Thu Jul 9 14:32:01 2009 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 9 Jul 2009 10:32:01 -0400 Subject: prelink: is it worth it? Message-ID: <20090709143201.GA22885@jadzia.bu.edu> Apparently there was some fun with prelink breaking everything in rawhide recently: . I didn't notice, because like Pete Zaitcev says in the comments, removing prelink is one of the first things I do. I see it as adding unnecessary complexity and fragility, and it makes forensic verification difficult. Binaries can't be verified without being modified, which is far from ideal. And the error about dependencies having changed since prelinking is disturbingly frequent. On the other hand, smart people have worked on it. It's very likely that those smart people know things I don't. I can't find any good numbers anywhere demonstrating the concrete benefits provided by prelink. Is there data out there? Pretty charts and graphs would be nice. The only things I've been able to find are old and not very impressive: Even assuming a benefit, the price may not be worth it. SELinux gives a definite performance hit, but it's widely accepted as being part of the price to pay for added security. Enabling prelink seems to fall on the other side of the line. What's the justification? -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs Computing & Information Technology Harvard School of Engineering & Applied Sciences From kevin.kofler at chello.at Thu Jul 9 14:35:42 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 09 Jul 2009 16:35:42 +0200 Subject: noarch subpackages References: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> <20090708170639.21f9b4bf@faldor> <9514c41a0ff9d6e5be9b2ad6f16331d6.squirrel@intranet.cs.nmsu.edu> Message-ID: Rick L. Vinyard, Jr. wrote: > Does this cover CentOS as well? Yes. Kevin Kofler From maxamillion at gmail.com Thu Jul 9 14:36:20 2009 From: maxamillion at gmail.com (Adam Miller) Date: Thu, 9 Jul 2009 09:36:20 -0500 Subject: prelink: is it worth it? In-Reply-To: <20090709143201.GA22885@jadzia.bu.edu> References: <20090709143201.GA22885@jadzia.bu.edu> Message-ID: I am curious as to this answer as well because prelink has been something that actually hurt my netbook in performance so I nuked it. -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From harsha.k.gowda at gmail.com Thu Jul 9 14:39:00 2009 From: harsha.k.gowda at gmail.com (Harsha gowda) Date: Thu, 9 Jul 2009 20:09:00 +0530 Subject: Fwd: Hi help required for setting up a debug setup In-Reply-To: <4A55F375.50600@fedoraproject.org> References: <4A55F375.50600@fedoraproject.org> Message-ID: ---------- Forwarded message ---------- From: Rahul Sundaram Date: Thu, Jul 9, 2009 at 7:11 PM Subject: Re: Hi help required for setting up a debug setup To: Harsha gowda On 07/09/2009 06:37 PM, Harsha gowda wrote: > > > Hi, > Setup build environment as you said earlier, > Thanks for help > > I did followed all you said. > * > yum install fedora-rpmdevtools -y > yum install rpmdevtools > rpmdev-setuptree * > > I install the srpm as below > > *rpm -i /home/harsha/Download/wpa_supplicant-0.6.4-2.fc10.src.rpm * > > every time i will create the > tar.gz file of the folder /root/rpmbuild/SOURCE/wpa_supplicant-0.6.4/ > and compile as > > *rpmbuild -bs wpa_supplicant.spec * > > and i put* print statements and debug,* > Can any one help me how can i use kdbg and use > any kind of debug build where i can debug line by line... > > Please help me how to setup debug enveronment in fedora > and debug line by line, I am not sure what you are trying to do yet but since you already posted to the development list, you might want to continue the conversation there. Rahul -- ???? ???? ?? ??? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Thu Jul 9 14:37:35 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 09 Jul 2009 16:37:35 +0200 Subject: noarch subpackages References: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> <20090708170639.21f9b4bf@faldor> <9514c41a0ff9d6e5be9b2ad6f16331d6.squirrel@intranet.cs.nmsu.edu> Message-ID: yersinia wrote: > No everyone agreed with this or would the spec/rpm version frammentation > go forever. > > http://www.mail-archive.com/rpm-maint at lists.rpm.org/msg00885.html > > http://www.mail-archive.com/rpm-maint at lists.rpm.org/msg00939.html People are suggesting unified macros and guidelines, but the reality is that they aren't, so high-quality, guideline-compliant cross-distribution specfiles are not possible at this time. Kevin Kofler From pinto.elia at gmail.com Thu Jul 9 14:45:55 2009 From: pinto.elia at gmail.com (devzero2000) Date: Thu, 9 Jul 2009 16:45:55 +0200 Subject: prelink: is it worth it? In-Reply-To: References: <20090709143201.GA22885@jadzia.bu.edu> Message-ID: On Thu, Jul 9, 2009 at 4:36 PM, Adam Miller wrote: > I am curious as to this answer as well because prelink has been > something that actually hurt my netbook in performance so I nuked it. > There are also other two big problem, imho, now, with prelink support: 1 - it render impossibile to do a centralizzated integrity checker (with as example rfc.sf.net ): very very bad 2 - not checked if this problem is actual or not: prelink erases file-based capabilities https://bugzilla.redhat.com/show_bug.cgi?id=456105 If actual it render new rpm possibility in this area pointless > -Adam > > -- > http://maxamillion.googlepages.com > --------------------------------------------------------- > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments > > -- > 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 drepper at redhat.com Thu Jul 9 14:55:38 2009 From: drepper at redhat.com (Ulrich Drepper) Date: Thu, 09 Jul 2009 07:55:38 -0700 Subject: prelink: is it worth it? In-Reply-To: References: <20090709143201.GA22885@jadzia.bu.edu> Message-ID: <4A5604EA.9090107@redhat.com> Adam Miller wrote: > I am curious as to this answer as well because prelink has been > something that actually hurt my netbook in performance so I nuked it. Performance only ever can be hurt because prelink runs periodically to prelink newly installed code or re-randomize to increase security. prelink has two benefits: - almost all relocations a program has to perform are avoided. These can be very expensive when many dependencies and/or large symbol tables are involved. The latter is somewhat mitigated by the new symbol table hashing we implemented some time back but still. - as a side effect of the first point some pages in the loaded binary are not copied-on-write. This can obviously have good effects on systems with little memory (netbooks). Just run your own tests on apps with many relocations and dependencies. FF, OO.org, most GUI apps come into mind. Use LD_DEBUG=statistics some/program to compare numbers. Run it with and without prelink (but always with hot disk cache to be fair). The number of cycles for total startup is representative of the win. Note, also small but frequently used apps benefit. I run gcc etc a lot and like every single saved cycle. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From zaitcev at redhat.com Thu Jul 9 14:58:08 2009 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 9 Jul 2009 08:58:08 -0600 Subject: prelink: is it worth it? In-Reply-To: <20090709143201.GA22885@jadzia.bu.edu> References: <20090709143201.GA22885@jadzia.bu.edu> Message-ID: <20090709085808.6b9a1b82.zaitcev@redhat.com> On Thu, 9 Jul 2009 10:32:01 -0400, Matthew Miller wrote: > Apparently there was some fun with prelink breaking everything in rawhide > recently: . I didn't > notice, because like Pete Zaitcev says in the comments, removing prelink is > one of the first things I do. I meant that it was the first thing I did when the root cause became known. This is not the same thing as removing mlocate upon install that "everyone" do. That said, you raise an interesting question. -- Pete From mattdm at mattdm.org Thu Jul 9 14:59:48 2009 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 9 Jul 2009 10:59:48 -0400 Subject: prelink: is it worth it? In-Reply-To: <20090709085808.6b9a1b82.zaitcev@redhat.com> References: <20090709143201.GA22885@jadzia.bu.edu> <20090709085808.6b9a1b82.zaitcev@redhat.com> Message-ID: <20090709145948.GB26265@jadzia.bu.edu> On Thu, Jul 09, 2009 at 08:58:08AM -0600, Pete Zaitcev wrote: > > Apparently there was some fun with prelink breaking everything in rawhide > > recently: . I didn't > > notice, because like Pete Zaitcev says in the comments, removing prelink is > > one of the first things I do. > I meant that it was the first thing I did when the root cause > became known. This is not the same thing as removing mlocate > upon install that "everyone" do. Sorry -- didn't mean to put words into your mouth. -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs Computing & Information Technology Harvard School of Engineering & Applied Sciences From jakub at redhat.com Thu Jul 9 15:06:54 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 9 Jul 2009 17:06:54 +0200 Subject: prelink: is it worth it? In-Reply-To: <20090709143201.GA22885@jadzia.bu.edu> References: <20090709143201.GA22885@jadzia.bu.edu> Message-ID: <20090709150654.GS4462@tyan-ft48-01.lab.bos.redhat.com> On Thu, Jul 09, 2009 at 10:32:01AM -0400, Matthew Miller wrote: > Apparently there was some fun with prelink breaking everything in rawhide > recently: . I didn't > notice, because like Pete Zaitcev says in the comments, removing prelink is > one of the first things I do. > > I see it as adding unnecessary complexity and fragility, and it makes > forensic verification difficult. Binaries can't be verified without being > modified, which is far from ideal. And the error about dependencies having > changed since prelinking is disturbingly frequent. > > On the other hand, smart people have worked on it. It's very likely that > those smart people know things I don't. I can't find any good numbers > anywhere demonstrating the concrete benefits provided by prelink. Is there > data out there? Pretty charts and graphs would be nice. The only things I've > been able to find are old and not very impressive: > > > > Say on x86-64 F11 (with /etc/prelink.conf.d/nss-prelink.conf removed): LD_DEBUG=statistics /usr/lib64/openoffice.org3/program/swriter.bin 11799: 11799: runtime linker statistics: 11799: total startup time in dynamic loader: 18632372 clock cycles 11799: time needed for relocation: 2975643 clock cycles (15.9%) 11799: number of relocations: 0 11799: number of relocations from cache: 1527 11799: number of relative relocations: 0 11799: time needed to load objects: 13190177 clock cycles (70.7%) LD_USE_LOAD_BIAS=0 LD_DEBUG=statistics /usr/lib64/openoffice.org3/program/swriter.bin 11817: 11817: runtime linker statistics: 11817: total startup time in dynamic loader: 145813250 clock cycles 11817: time needed for relocation: 129375884 clock cycles (88.7%) 11817: number of relocations: 42207 11817: number of relocations from cache: 126013 11817: number of relative relocations: 149959 11817: time needed to load objects: 15248893 clock cycles (10.4%) The former is how long it takes before swriter.bin starts up when prelinked, the latter tells it not to use prelink information and do normal relocation. Try this on any other GUI app that links against dozens of shared libraries. Even on binaries that link against only very few libraries, but are executed often it makes a difference, say consider configure scripts or libtool that exec hundreds to thousands small programs. And time isn't the only saving, another is that fewer pages are dirtied. The rawhide prelink issue is just that we've added a new ELF extension to the toolchain (binutils, glibc) and prelink had to be changed to handle it. Jakub From yersinia.spiros at gmail.com Thu Jul 9 15:07:05 2009 From: yersinia.spiros at gmail.com (yersinia) Date: Thu, 9 Jul 2009 17:07:05 +0200 Subject: prelink: is it worth it? In-Reply-To: <4A5604EA.9090107@redhat.com> References: <20090709143201.GA22885@jadzia.bu.edu> <4A5604EA.9090107@redhat.com> Message-ID: On Thu, Jul 9, 2009 at 4:55 PM, Ulrich Drepper wrote: > Adam Miller wrote: > > I am curious as to this answer as well because prelink has been > > something that actually hurt my netbook in performance so I nuked it. > > Performance only ever can be hurt because prelink runs periodically to > prelink newly installed code or re-randomize to increase security. > > prelink has two benefits: > > - almost all relocations a program has to perform are avoided. These > can be very expensive when many dependencies and/or large symbol > tables are involved. The latter is somewhat mitigated by the new > symbol table hashing we implemented some time back but still. > > - as a side effect of the first point some pages in the loaded binary > are not copied-on-write. This can obviously have good effects on > systems with little memory (netbooks). > > > Just run your own tests on apps with many relocations and dependencies. > FF, OO.org, most GUI apps come into mind. Use > > LD_DEBUG=statistics some/program > > to compare numbers. Run it with and without prelink (but always with > hot disk cache to be fair). The number of cycles for total startup is > representative of the win. > > Note, also small but frequently used apps benefit. I run gcc etc a lot > and like every single saved cycle. > But something one have to pay a security prize on not disabling it : it render impossible to have a centralizzated security integrity management (e.g. rfc.sf.net for example) or one have to skip from check the prelink binary. Very bad i think. > > -- > ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? > > -- > 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 mattdm at mattdm.org Thu Jul 9 15:08:20 2009 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 9 Jul 2009 11:08:20 -0400 Subject: prelink: is it worth it? In-Reply-To: <4A5604EA.9090107@redhat.com> References: <20090709143201.GA22885@jadzia.bu.edu> <4A5604EA.9090107@redhat.com> Message-ID: <20090709150820.GA26398@jadzia.bu.edu> On Thu, Jul 09, 2009 at 07:55:38AM -0700, Ulrich Drepper wrote: > hot disk cache to be fair). The number of cycles for total startup is > representative of the win. I'm not sure that's the case. If I can get a 50% speed up to a program's startup times, that sounds great, but if I then leave that program running for days on end, I haven't actually won very much at all -- but I still pay the price continuously. (That price being: fragility, verifiability, and of course the prelinking activity itself.) > Note, also small but frequently used apps benefit. I run gcc etc a lot > and like every single saved cycle. Right, this actually seems more significant to me, even though it may be less important in terms of marketing to new Linux desktop users. But saving every last possible cycle is only one concern of many, particularly when deciding on a default configuration. -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs Computing & Information Technology Harvard School of Engineering & Applied Sciences From skvidal at fedoraproject.org Thu Jul 9 15:09:28 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 9 Jul 2009 11:09:28 -0400 (EDT) Subject: prelink: is it worth it? In-Reply-To: <20090709150820.GA26398@jadzia.bu.edu> References: <20090709143201.GA22885@jadzia.bu.edu> <4A5604EA.9090107@redhat.com> <20090709150820.GA26398@jadzia.bu.edu> Message-ID: On Thu, 9 Jul 2009, Matthew Miller wrote: > On Thu, Jul 09, 2009 at 07:55:38AM -0700, Ulrich Drepper wrote: >> hot disk cache to be fair). The number of cycles for total startup is >> representative of the win. > > I'm not sure that's the case. If I can get a 50% speed up to a program's > startup times, that sounds great, but if I then leave that program running > for days on end, I haven't actually won very much at all -- but I still pay > the price continuously. (That price being: fragility, verifiability, and of > course the prelinking activity itself.) > >> Note, also small but frequently used apps benefit. I run gcc etc a lot >> and like every single saved cycle. > > Right, this actually seems more significant to me, even though it may be > less important in terms of marketing to new Linux desktop users. But > saving every last possible cycle is only one concern of many, particularly > when deciding on a default configuration. > Is there a middle road which involves having prelink target specific pkgs/binaries and avoid others? -sv From jakub at redhat.com Thu Jul 9 15:12:17 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 9 Jul 2009 17:12:17 +0200 Subject: prelink: is it worth it? In-Reply-To: References: <20090709143201.GA22885@jadzia.bu.edu> <4A5604EA.9090107@redhat.com> Message-ID: <20090709151217.GT4462@tyan-ft48-01.lab.bos.redhat.com> On Thu, Jul 09, 2009 at 05:07:05PM +0200, yersinia wrote: > But something one have to pay a security prize on not disabling it : it > render impossible to have a > centralizzated security integrity management (e.g. rfc.sf.net for example) > or one have to skip from check the prelink binary. Very bad i think. That's what prelink -y is for, it verifies the binary would prelink from unprelinked state to bitwise same file and gives you the bits before prelinking, which you can use for verification. rpm -V uses this, why can't other security integrity apps do the same? Jakub From yersinia.spiros at gmail.com Thu Jul 9 15:12:24 2009 From: yersinia.spiros at gmail.com (yersinia) Date: Thu, 9 Jul 2009 17:12:24 +0200 Subject: prelink: is it worth it? In-Reply-To: <20090709150654.GS4462@tyan-ft48-01.lab.bos.redhat.com> References: <20090709143201.GA22885@jadzia.bu.edu> <20090709150654.GS4462@tyan-ft48-01.lab.bos.redhat.com> Message-ID: On Thu, Jul 9, 2009 at 5:06 PM, Jakub Jelinek wrote: > On Thu, Jul 09, 2009 at 10:32:01AM -0400, Matthew Miller wrote: > > Apparently there was some fun with prelink breaking everything in rawhide > > recently: . I didn't > > notice, because like Pete Zaitcev says in the comments, removing prelink > is > > one of the first things I do. > > > > I see it as adding unnecessary complexity and fragility, and it makes > > forensic verification difficult. Binaries can't be verified without being > > modified, which is far from ideal. And the error about dependencies > having > > changed since prelinking is disturbingly frequent. > > > > On the other hand, smart people have worked on it. It's very likely that > > those smart people know things I don't. I can't find any good numbers > > anywhere demonstrating the concrete benefits provided by prelink. Is > there > > data out there? Pretty charts and graphs would be nice. The only things > I've > > been able to find are old and not very impressive: > > > > > > < > http://smackerelofopinion.blogspot.com/2009/06/does-prelinking-speed-up-boot-times.html > > > > > > Say on x86-64 F11 (with /etc/prelink.conf.d/nss-prelink.conf removed): > LD_DEBUG=statistics /usr/lib64/openoffice.org3/program/swriter.bin > 11799: > 11799: runtime linker statistics: > 11799: total startup time in dynamic loader: 18632372 clock > cycles > 11799: time needed for relocation: 2975643 clock cycles > (15.9%) > 11799: number of relocations: 0 > 11799: number of relocations from cache: 1527 > 11799: number of relative relocations: 0 > 11799: time needed to load objects: 13190177 clock > cycles (70.7%) > LD_USE_LOAD_BIAS=0 LD_DEBUG=statistics > /usr/lib64/openoffice.org3/program/swriter.bin > 11817: > 11817: runtime linker statistics: > 11817: total startup time in dynamic loader: 145813250 clock > cycles > 11817: time needed for relocation: 129375884 clock > cycles (88.7%) > 11817: number of relocations: 42207 > 11817: number of relocations from cache: 126013 > 11817: number of relative relocations: 149959 > 11817: time needed to load objects: 15248893 clock > cycles (10.4%) > The former is how long it takes before swriter.bin starts up when > prelinked, > the latter tells it not to use prelink information and do normal > relocation. > Try this on any other GUI app that links against dozens of shared > libraries. Perfect. this is the key point for me. If i mantain server only, not desktop client, without X and the like, no problem to disable it. Isn't right ? I have already do this, for security reason due to centralizzated integrity checker, on +300 production RHEL machine. Regards > > -- > 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 yersinia.spiros at gmail.com Thu Jul 9 15:16:25 2009 From: yersinia.spiros at gmail.com (yersinia) Date: Thu, 9 Jul 2009 17:16:25 +0200 Subject: prelink: is it worth it? In-Reply-To: <20090709151217.GT4462@tyan-ft48-01.lab.bos.redhat.com> References: <20090709143201.GA22885@jadzia.bu.edu> <4A5604EA.9090107@redhat.com> <20090709151217.GT4462@tyan-ft48-01.lab.bos.redhat.com> Message-ID: On Thu, Jul 9, 2009 at 5:12 PM, Jakub Jelinek wrote: > On Thu, Jul 09, 2009 at 05:07:05PM +0200, yersinia wrote: > > But something one have to pay a security prize on not disabling it : it > > render impossible to have a > > centralizzated security integrity management (e.g. rfc.sf.net for > example) > > or one have to skip from check the prelink binary. Very bad i think. > > That's what prelink -y is for, it verifies the binary would prelink from > unprelinked state to bitwise same file and gives you the bits before > prelinking, which you can use for verification. > rpm -V uses this, why can't other security integrity apps do the same? > Yes I know that rpm do this. But other centralizzated integrity checker, perhaps for portability between posix platform, at max permit to skip the check - OSSSEC for example iirc do this - on prelinked binary. regards > Jakub > > -- > 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 jakub at redhat.com Thu Jul 9 15:17:28 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 9 Jul 2009 17:17:28 +0200 Subject: prelink: is it worth it? In-Reply-To: <20090709150820.GA26398@jadzia.bu.edu> References: <20090709143201.GA22885@jadzia.bu.edu> <4A5604EA.9090107@redhat.com> <20090709150820.GA26398@jadzia.bu.edu> Message-ID: <20090709151728.GU4462@tyan-ft48-01.lab.bos.redhat.com> On Thu, Jul 09, 2009 at 11:08:20AM -0400, Matthew Miller wrote: > On Thu, Jul 09, 2009 at 07:55:38AM -0700, Ulrich Drepper wrote: > > hot disk cache to be fair). The number of cycles for total startup is > > representative of the win. > > I'm not sure that's the case. If I can get a 50% speed up to a program's > startup times, that sounds great, but if I then leave that program running > for days on end, I haven't actually won very much at all -- but I still pay > the price continuously. (That price being: fragility, verifiability, and of > course the prelinking activity itself.) Most of GNOME apps link against 50+ libraries, however small they are, many of them are executed frequently. Also, while prelink process has been fairly expensive some years ago, it is much faster these days; if you haven't installed any rpms in the last day, most of the days the cron job will just quit, if you have installed some, for libraries/binaries that don't need reprelinking it will just do a quick stat and nothing else, and even a full prelink takes just a minute or two. Jakub From jan.kratochvil at redhat.com Thu Jul 9 15:24:20 2009 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Thu, 9 Jul 2009 17:24:20 +0200 Subject: Hi help required for setting up a debug setup In-Reply-To: References: Message-ID: <20090709152420.GA28352@host0.dyn.jankratochvil.net> On Thu, 09 Jul 2009 12:33:10 +0200, Harsha gowda wrote: > use any kind of debug build where i can debug line by line... If you want to debug wpa_supplicant installed in the system: $ gdb -q wpa_supplicant Missing separate debuginfos, use: debuginfo-install wpa_supplicant-0.6.8-4.fc11.x86_64 (gdb) quit # debuginfo-install wpa_supplicant-0.6.8-4.fc11.x86_64 $ gdb -q wpa_supplicant (gdb) start Temporary breakpoint 1 at 0x43d690: file main.c, line 115. Starting program: /usr/sbin/wpa_supplicant [Thread debugging using libthread_db enabled] Temporary breakpoint 1, main (argc=1, argv=0x7fffffffd678) at main.c:115 115 { (gdb) next 122 if (os_program_init()) (gdb) warning: Source file is more recent than executable. 85 return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest)); (gdb) 128 iface = ifaces = os_zalloc(sizeof(struct wpa_interface)); (gdb) 126 params.wpa_debug_level = MSG_INFO; (gdb) list 121 122 if (os_program_init()) 123 return -1; 124 125 os_memset(¶ms, 0, sizeof(params)); 126 params.wpa_debug_level = MSG_INFO; 127 128 iface = ifaces = os_zalloc(sizeof(struct wpa_interface)); 129 if (ifaces == NULL) 130 return -1; (gdb) > and debug line by line, Just with current gcc and production rpms (built using -O2) the stepping jumps a bit. You should recompile the package with -O0 for serious debugging (for -O2 it should be fixed sometimes during gcc-4.5). To recompile wpa_supplicant (or the same way some other package) with -O0 try the .spec patch below. Regards, Jan --- wpa_supplicant.spec-orig 2009-05-13 16:56:01.000000000 +0200 +++ wpa_supplicant.spec 2009-07-09 17:01:22.000000000 +0200 @@ -63,8 +63,9 @@ Graphical User Interface for wpa_supplic %build pushd wpa_supplicant cp %{SOURCE1} ./.config - CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; - CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; + CFLAGS="${CFLAGS:-%optflags} -O0 -ggdb3" ; export CFLAGS ; + CXXFLAGS="${CXXFLAGS:-%optflags} -O0 -ggdb3" ; export CXXFLAGS ; + # FIXME: wpa_supplicant/wpa_gui/Makefile is left with unchanged {CFLAGS,CXXFLAGS} due to qmake. make %{_smp_mflags} QTDIR=%{_libdir}/qt-3.3 make wpa_gui %{_smp_mflags} popd From ch.nolte at noltec.org Thu Jul 9 15:55:25 2009 From: ch.nolte at noltec.org (Christian Nolte) Date: Thu, 09 Jul 2009 17:55:25 +0200 Subject: Font-Size Problem with liberation-fonts Message-ID: <4A5612ED.9060208@noltec.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, currently I am working on a website which should be displayed correctly on Linux and Windows using the "Arial"-Font. I've learned that liberation-fonts are the way to go (because they are metric compatible), and discovered a problem with a font-size below 12px. The fonts are rendered with different spaces between the characters independent of the browser, but seemingly dependent of the OS (so I blame the liberation-fonts). I am not quite sure if there are patent restriction or something else, which prevents liberation-fonts to be exact clones, so it would be nice if someone of you could tell me if this is expected behaviour, or a bug: Here are some screenshots of the browsers and OS combinations I have tested: ftp://velian.dyndns.org/pub/nolte/liberation-fonts/ie7-windows.png ftp://velian.dyndns.org/pub/nolte/liberation-fonts/ff-3.5-windows.png ftp://velian.dyndns.org/pub/nolte/liberation-fonts/ff-3.0.11-linux.png This is the testbed: ftp://velian.dyndns.org/pub/nolte/liberation-fonts/liberation-fonts-test.html I have only tested this with font-sizes of 12px, 11px and 10px. Below 12px liberation-fonts puts too much spaces between the characters, so that 10px with liberation-fonts is equal to 11px Arial on Windows. BTW I am currently using liberation-fonts-1.04-1.fc9.noarch. But the problem is visible on a F11-box too. Thanks for looking at it. Best regards, Christian - -- "He's a benighted misogynist astronaut fleeing from a secret government programme. She's a foxy communist mechanic who inherited a spooky stately manor from her late maiden aunt. They fight crime!" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkpWEukACgkQCNjA0nfhW7wpHwCg1e1rbq0g76qAP6fOKj89XPuQ MRAAoJbV6+CKQJ/WbToy6evuEQfda5yt =1e+m -----END PGP SIGNATURE----- From opensource at till.name Thu Jul 9 15:59:32 2009 From: opensource at till.name (Till Maas) Date: Thu, 09 Jul 2009 17:59:32 +0200 Subject: prelink: is it worth it? In-Reply-To: References: <20090709143201.GA22885@jadzia.bu.edu> <4A5604EA.9090107@redhat.com> Message-ID: <200907091759.38976.opensource@till.name> On Thu July 9 2009, yersinia wrote: > But something one have to pay a security prize on not disabling it : it > render impossible to have a > centralizzated security integrity management (e.g. rfc.sf.net for example) > or one have to skip from check the prelink binary. Very bad i think. You pay a security prize if you disable prelink, because it also performs address space randomization: http://lwn.net/Articles/190139/ Btw. you can also patch the remote integrity checker to use prelink to either get a checksum of the perlinked binary or undo the prelinking before checking it. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From pinto.elia at gmail.com Thu Jul 9 16:11:22 2009 From: pinto.elia at gmail.com (devzero2000) Date: Thu, 9 Jul 2009 18:11:22 +0200 Subject: prelink: is it worth it? In-Reply-To: <200907091759.38976.opensource@till.name> References: <20090709143201.GA22885@jadzia.bu.edu> <4A5604EA.9090107@redhat.com> <200907091759.38976.opensource@till.name> Message-ID: On Thu, Jul 9, 2009 at 5:59 PM, Till Maas wrote: > On Thu July 9 2009, yersinia wrote: > > > But something one have to pay a security prize on not disabling it : it > > render impossible to have a > > centralizzated security integrity management (e.g. rfc.sf.net for > example) > > or one have to skip from check the prelink binary. Very bad i think. > > You pay a security prize if you disable prelink, because it also performs > address space randomization: > http://lwn.net/Articles/190139/ > Perhaps something have changed from 2006 - try yourself. on your RHEL/fedora if ASLR depends only on prelink. But the last word on this is on jackub/Ulrich/Molnar. If i was wrong it is nice to know. regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From yersinia.spiros at gmail.com Thu Jul 9 16:11:59 2009 From: yersinia.spiros at gmail.com (yersinia) Date: Thu, 9 Jul 2009 18:11:59 +0200 Subject: prelink: is it worth it? In-Reply-To: References: <20090709143201.GA22885@jadzia.bu.edu> <4A5604EA.9090107@redhat.com> <200907091759.38976.opensource@till.name> Message-ID: On Thu, Jul 9, 2009 at 5:59 PM, Till Maas wrote: > On Thu July 9 2009, yersinia wrote: >> >> > But something one have to pay a security prize on not disabling it : it >> > render impossible to have a >> > centralizzated security integrity management (e.g. rfc.sf.net for >> example) >> > or one have to skip from check the prelink binary. Very bad i think. >> >> You pay a security prize if you disable prelink, because it also performs >> address space randomization: >> http://lwn.net/Articles/190139/ >> > > Perhaps something have changed from 2006 - try yourself. on your > RHEL/fedora if ASLR depends only on prelink. > But the last word on this is on jackub/Ulrich/Molnar. If i was wrong it is > nice to know. > > regards > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmacken at redhat.com Thu Jul 9 16:12:58 2009 From: lmacken at redhat.com (Luke Macken) Date: Thu, 9 Jul 2009 12:12:58 -0400 Subject: bodhi error In-Reply-To: References: Message-ID: <20090709161258.GA4033@x300> On Thu, Jul 09, 2009 at 07:37:28AM -0400, Neal Becker wrote: > bodhi -C > igraph-0.5.2-1.fc9 dist-f9-updates-candidate > qct-1.7-3.fc9 dist-f9-updates-candidate > python-igraph-0.5.1-3.fc9 dist-f9-updates-candidate > libotf-0.9.8-1.fc9 dist-f9-updates-candidate > igraph-0.5.2-1.fc10 dist-f10-updates-candidate > qct-1.7-3.fc10 dist-f10-updates-candidate > Traceback (most recent call last): > File "/usr/bin/bodhi", line 322, in > main() > File "/usr/bin/bodhi", line 230, in main > for build in bodhi.candidates(): > File "/usr/lib/python2.6/site-packages/fedora/client/bodhi.py", line 193, > in candidates > for build in self.koji_session.listTagged(tag, latest=True): > File "/usr/lib/python2.6/site-packages/koji/__init__.py", line 1255, in > __call__ > return self.__func(self.__name,args,opts) > File "/usr/lib/python2.6/site-packages/koji/__init__.py", line 1501, in > _callMethod > raise err > koji.GenericError: No such entry in table tag: dist-4E-epel-updates- > candidate I just fixed this issue in python-fedora and in the bodhi-server. In the future, please file bodhi bugs here: https://fedorahosted.org/bodhi/newticket Thanks, luke From yaneti at declera.com Thu Jul 9 16:16:11 2009 From: yaneti at declera.com (Yanko Kaneti) Date: Thu, 09 Jul 2009 19:16:11 +0300 Subject: Font-Size Problem with liberation-fonts In-Reply-To: <4A5612ED.9060208@noltec.org> References: <4A5612ED.9060208@noltec.org> Message-ID: <1247156171.4727.27.camel@d2> On Thu, 2009-07-09 at 17:55 +0200, Christian Nolte wrote: > Hi, > > currently I am working on a website which should be displayed correctly > on Linux and Windows using the "Arial"-Font. I've learned that > liberation-fonts are the way to go (because they are metric compatible), > and discovered a problem with a font-size below 12px. The fonts are > rendered with different spaces between the characters independent of the > browser, but seemingly dependent of the OS (so I blame the > liberation-fonts). > > I am not quite sure if there are patent restriction or something else, > which prevents liberation-fonts to be exact clones, so it would be nice > if someone of you could tell me if this is expected behaviour, or a bug: > > Here are some screenshots of the browsers and OS combinations I have tested: > > ftp://velian.dyndns.org/pub/nolte/liberation-fonts/ie7-windows.png > ftp://velian.dyndns.org/pub/nolte/liberation-fonts/ff-3.5-windows.png > ftp://velian.dyndns.org/pub/nolte/liberation-fonts/ff-3.0.11-linux.png > > This is the testbed: > ftp://velian.dyndns.org/pub/nolte/liberation-fonts/liberation-fonts-test.html > > I have only tested this with font-sizes of 12px, 11px and 10px. Below > 12px liberation-fonts puts too much spaces between the characters, so > that 10px with liberation-fonts is equal to 11px Arial on Windows. > > BTW I am currently using liberation-fonts-1.04-1.fc9.noarch. But the > problem is visible on a F11-box too. See Bug 503430 - Incorrect Kerning in some applications https://bugzilla.redhat.com/show_bug.cgi?id=503430 From tmraz at redhat.com Thu Jul 9 16:20:57 2009 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 09 Jul 2009 18:20:57 +0200 Subject: prelink: is it worth it? In-Reply-To: <200907091759.38976.opensource@till.name> References: <20090709143201.GA22885@jadzia.bu.edu> <4A5604EA.9090107@redhat.com> <200907091759.38976.opensource@till.name> Message-ID: <1247156457.23660.84.camel@vespa.frost.loc> On Thu, 2009-07-09 at 17:59 +0200, Till Maas wrote: > On Thu July 9 2009, yersinia wrote: > > > But something one have to pay a security prize on not disabling it : it > > render impossible to have a > > centralizzated security integrity management (e.g. rfc.sf.net for example) > > or one have to skip from check the prelink binary. Very bad i think. > > You pay a security prize if you disable prelink, because it also performs > address space randomization: > http://lwn.net/Articles/190139/ That's nonsense. Actually with prelink the randomization is done only when prelink is rerun as the addresses can change only during the prelinking. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From jan.kratochvil at redhat.com Thu Jul 9 16:21:20 2009 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Thu, 9 Jul 2009 18:21:20 +0200 Subject: Hi help required for setting up a debug setup In-Reply-To: References: <20090709152420.GA28352@host0.dyn.jankratochvil.net> Message-ID: <20090709162120.GA10103@host0.dyn.jankratochvil.net> On Thu, 09 Jul 2009 18:03:43 +0200, Harsha gowda wrote: > I tried compiling with -O0 ggdb3 > > and installed the rpms & still get symbol not found, > > *[root at localhost i386]#* gdb -q wpa_supplicant > (no debugging symbols found) I wanted to write it short but it was not clear I see. So just one of the choices: Either (a) gdb /usr/bin/wpa_supplicant and use debuginfo-install wpa_supplicant (the line stepping will work but it will be "imperfect") or (but not both) (b) Patch wpa_supplicant.spec with `-O0 -ggdb3' but do not install it at all, use just the version from the build tree. I use `rpmbuild -bc' for such cases. Do some: gdb /root/rpmbuild/BUILD/wpa_supplicant-0.6.4/wpa_supplicant (unchecked) You can also do (if you need the binary present at the standard system location such as in /usr/bin): (c) rpm -U wpa_supplicant-0.6.4*.rpm but do not use debuginfo-install but instead install also its corresponding locally built debuginfo: rpm -U wpa_supplicant-debuginfo-0.6.4*.rpm > *[root at localhost i386]#* debuginfo-install wpa_supplicant > Package 1:wpa_supplicant-debuginfo-0.6.4-2.fc10.i386 already installed and latest version > *[root at localhost i386]#* gdb -q wpa_supplicant > (no debugging symbols found) > (gdb) If you do rpm -qi wpa_supplicant wpa_supplicant-debuginfo you should find out their builds do not match. I am more curious gdb should have printed also: warning: the debug information found in "/usr/lib/debug//usr/sbin/wpa_supplicant.debug" does not match "/usr/sbin/wpa_supplicant" (CRC mismatch). Regards, Jan From rodrigopadula at projetofedora.org Thu Jul 9 16:27:11 2009 From: rodrigopadula at projetofedora.org (Rodrigo Padula de Oliveira) Date: Thu, 09 Jul 2009 13:27:11 -0300 Subject: Keyboard US Internacional In-Reply-To: <128943507.129711247027806955.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <128943507.129711247027806955.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4A561A5F.7050707@projetofedora.org> Em 08-07-2009 01:36, Ding Yi Chen escreveu: > ----- "Rodrigo Padula de Oliveira" wrote: > >> Hello guys. >> >> How can we add gtk2-immodules and gtk2-immodule-xim by default in a >> PT_BR Fedora installation ? >> >> We need to correct this problem ASAP for Fedora 10 ,11 and rawhide >> >> We are receiving a lot of claims about this problem in Brazilian lists >> >> and forum. >> >> Bugzilla entry: https://bugzilla.redhat.com/show_bug.cgi?id=505100 >> >> Thanks! > > How about adding gtk2-immodules and gtk2-immodule-xim in > Portuguese support? > > Ahhh, is necessary to change the /etc/X11/xinit/xinput.d/none.conf file changing the line GTK_IM_MODULE=gtk-im-context-simple to GTK_IM_MODULE=gtk-im-cedilla after the gtk2-immodules installation. -- Rodrigo Padula de Oliveira M.Sc. Student - COPPE/UFRJ Fedora Community Manager - Latin America Red Hat Community and Academy Relations http://www.proyectofedora.org http://twitter.com/rodrigopadula http://www.rodrigopadula.com From lfarkas at lfarkas.org Thu Jul 9 16:28:31 2009 From: lfarkas at lfarkas.org (Farkas Levente) Date: Thu, 09 Jul 2009 18:28:31 +0200 Subject: noarch subpackages In-Reply-To: References: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> <20090708170639.21f9b4bf@faldor> <9514c41a0ff9d6e5be9b2ad6f16331d6.squirrel@intranet.cs.nmsu.edu> Message-ID: <4A561AAF.2010305@lfarkas.org> Kevin Kofler wrote: > Rick L. Vinyard, Jr. wrote: > >> Michael Schwendt wrote: >>> On Wed, 8 Jul 2009 07:59:43 -0600, Jr. wrote: >>> >>>> What is the effect on non-Fedora and older distributions (pre F10) if I >>>> mark a subpackage (such as documentation) with BuildArch: noarch? >>> You can evaluate the %fedora variable to use this new feature only >>> for Fedora >= 10: >>> >>> %if 0%{?fedora} > 9 >>> BuildArch: noarch >>> %endif >>> >> Excellent. That's what I was looking for. > > Except it should be: > %if 0%{?fedora} > 9 || 0%{?rhel} > 5 it'd be nice if _all_ packages which have noarch subpackage use this since most fedora packager reply to my such patches that they don't care about rhel/centos:-( -- Levente "Si vis pacem para bellum!" From rawhide at fedoraproject.org Thu Jul 9 16:42:32 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Thu, 9 Jul 2009 16:42:32 +0000 Subject: rawhide report: 20090709 changes Message-ID: <20090709164232.GA1540@releng2.fedora.phx.redhat.com> Compose started at Thu Jul 9 06:15:04 UTC 2009 New package daemonize Run a command as a Unix daemon New package ewl Enlightenment Widget Library New package gir-repository Introspection for GNOME libraries New package hunspell-am Amharic hunspell dictionaries New package hunspell-ti Tigrigna hunspell dictionaries New package panoglview Immersive viewer for spherical panoramas New package perl-CGI-Application-Plugin-ValidateRM Help validate CGI::Application run modes using Data::FormValidator New package perl-CGI-Application-Plugin-ViewCode Allows you to view the source of a CGI::Application module New package perl-Test-Unit-Runner-Xml Generate XML reports from unit test results New package python-sybase Python interface to Sybase New package python-webpy A simple web framework for Python New package rubygem-bacon A ruby-based testing framework New package rubygem-configuration Pure Ruby scoped configuration files New package rubygem-diff-lcs Provide a list of changes between two sequenced collections New package slashem Super Lotsa Added Stuff Hack - Extended Magic New package squeal Data manipulation tool for the command line New package wmfire A WindowMaker dock app that displays cpu, memory or network load as flames New package xsd W3C XML schema to C++ data binding compiler Updated Packages: CodeAnalyst-gui-2.8.54-14.fc12 ------------------------------ * Wed Jul 08 2009 - Suravee Suthikulpanit - 2.8.54-14 - Update new release - Update source - Update patch0 - Remove patches1-4 * Tue Jul 07 2009 - Suravee Suthikulpanit - 2.8.38-13 - Rebuild against new libbfd-2.19.51.0.20-20.fc12.so NetworkManager-0.7.1-7.git20090708.fc12 --------------------------------------- * Wed Jul 08 2009 Dan Williams - 0.7.1-7.git20090708 - nm: fixes for ZTE/Onda modem detection - nm: prevent re-opening serial port when the SIM has a PIN - applet: updated translations - editor: show list column headers * Thu Jun 25 2009 Dan Williams - 0.7.1-6.git20090617 - nm: fix serial port settings * Wed Jun 17 2009 Dan Williams - 0.7.1-5.git20090617 - nm: fix AT&T Quicksilver modem connections (rh #502002) - nm: fix support for s390 bus types (rh #496820) - nm: fix detection of some CMOtech modems - nm: handle unsolicited wifi scans better - nm: resolv.conf fixes when using DHCP and overriding search domains - nm: handle WEP and WPA passphrases (rh #441070) - nm: fix removal of old APs when none are scanned - nm: fix Huawei EC121 and EC168C detection and handling (rh #496426) - applet: save WEP and WPA passphrases instead of hashed keys (rh #441070) - applet: fix broken notification bubble actions - applet: default to WEP encryption for Ad-Hoc network creation - applet: fix crash when connection editor dialogs are canceled - applet: add a mobile broadband provider wizard * Tue May 19 2009 Karsten Hopp 0.7.1-4.git20090414.1 - drop ExcludeArch s390 s390x, we need at least the header files * Tue May 05 2009 Adam Jackson 1:0.7.1-4.git20090414 - nm-save-the-leases.patch: Use per-connection lease files, and don't delete them on interface deactivate. amarok-2.1.1-2.fc12 ------------------- * Tue Jul 07 2009 Rex Dieter 2.1.1-2 - Requires: qtscripbindings%{?_isa} (#510133) anthy-9100h-5.fc12 ------------------ * Wed Jul 08 2009 Akira TAGOH - 9100h-5 - Update the corpus. - Fix typos in dictionary. (#509534) anyremote2html-1.0-1.fc12 ------------------------- * Wed Jul 08 2009 Mikhail Fedotov - 1.0 - Handle Get(password) command. Add -m command line option. Add 48x48 icons handling. bluez-4.45-1.fc12 ----------------- * Wed Jul 08 2009 Bastien Nocera 4.45-1 - Update to 4.45 * Tue Jul 07 2009 Bastien Nocera 4.44-1 - Update to 4.44 bugzilla-3.2.4-1.fc12 --------------------- * Wed Jul 08 2009 Itamar Reis Peixoto - 3.2.4-1 - fix https://bugzilla.mozilla.org/show_bug.cgi?id=495257 certmaster-0.25-1.fc12 ---------------------- * Tue May 26 2009 Adrian Likins - 0.25-1 - add /var/lib/certmaster/certmaster* to spec and set perms - add /var/log/certmaster/certmaster.log,audit.log to spec and set perms cloog-0.15-0.9.gitb9d79.fc12 ---------------------------- * Tue Jul 07 2009 Dodji Seketeli - 0.15-0.9.gitb9d79 - Update to new upstream git snapshot. - Update some comments in the spec file. cluster-3.0.0-20.fc12 --------------------- * Wed Jul 08 2009 Fabio M. Di Nitto - 3.0.0-20 - New upstream release - spec file updates: * Update copyright header * final release.. undefine alphatag * BuildRequires and Requires corosync/openais 1.0.0-1 final. clutter-gtkmm-0.9.4-1.fc12 -------------------------- * Wed Jul 08 2009 Denis Leroy - 0.9.4-1 - Update to upstream 0.9.4 - API update to 0.9 cluttermm-0.9.4-1.fc12 ---------------------- * Wed Jul 08 2009 Denis Leroy - 0.9.4-1 - Update to upstream 0.9.4 - API update to 0.9 corosync-1.0.0-1.fc12 --------------------- * Wed Jul 08 2009 Fabio M. Di Nitto - 1.0.0-1 - New upstream release d-feet-0.1.10-1.fc12 -------------------- * Wed Jul 08 2009 John (J5) Palmieri - 0.1.10-1 - update to upstream 0.1.10 - output now pretty printed - all simple types supported - ui cleanups deluge-1.1.9-2.fc12 ------------------- * Wed Jul 08 2009 Peter Gordon - 1.1.9-2 - Fixed rb_libtorrent-python dependency, so as not to use the %min_rblibtorrent_ver macro any more (#510264). ekiga-3.2.5-1.fc12 ------------------ * Mon Jul 06 2009 Peter Robinson - 3.2.5-1 - Ekiga 3.2.5 stable - Changelog ftp://ftp.gnome.org/pub/gnome/sources/ekiga/3.2/ekiga-3.2.5.news elinks-0.12-0.17.pre5.fc12 -------------------------- * Wed Jul 08 2009 Ondrej Vasik 0.12-0.17.pre5 - new upstream bugfix prerelease fence-agents-3.0.0-14.fc12 -------------------------- * Wed Jul 08 2009 Fabio M. Di Nitto - 3.0.0-14 - New upstream release - spec file updates: * Update copyright header * final release.. undefine alphatag * BuildRequires and Requires corosync/openais 1.0.0-1 final. filesystem-2.4.22-1.fc12 ------------------------ * Wed Jul 08 2009 Ondrej Vasik - 2.4.22-1 - do own interface description directory /usr/share/idl(#451719) - add a few missing lang-exceptions to filelist(#508309) fluxbox-1.1.1-3.fc12 -------------------- * Wed Jul 08 2009 Andreas Bierfert - 1.1.1-3 - make -pulseaudio package noarch fprintd-0.1-12.git04fd09cfa.fc12 -------------------------------- * Thu Jul 09 2009 Matthias Clasen 0.1-12.git04fd09cfa - Fix the pam module (#510152) func-0.25-1.fc12 ---------------- * Wed Jun 10 2009 Adrian Likins - 0.25-1 - add CHANGES to spec file * Wed May 27 2009 Adrian Likins - 0.25-1 - add /var/log/func/*.log files to spec - add a post section to chmod any log files with bogus perms * Thu Apr 16 2009 Adrian Likins - 0.24-5 - add an overlord.conf file gcc-4.4.0-12 ------------ * Wed Jul 08 2009 Jakub Jelinek 4.4.0-12 - update from gcc-4_4-branch - PRs c++/35828, c++/37816, c++/37946, c++/40557, c++/40633, c++/40639, debug/40666, target/38900 - use more compact DW_AT_member_location for constant offsets (PR debug/40659) * Tue Jul 07 2009 Jakub Jelinek 4.4.0-11 - update from gcc-4_4-branch - PRs c++/40274, c++/40342, c++/40566, c++/40595, c++/40619, c/39902, fortran/40443, fortran/40551, fortran/40576, fortran/40594, fortran/40638, libfortran/40576, libstdc++/40297, libstdc++/40600, middle-end/40585, middle-end/40669, other/40024, target/40587, tree-optimization/40493, tree-optimization/40542, tree-optimization/40550, tree-optimization/40579, tree-optimization/40582, tree-optimization/40640 - backports from trunk - fix debuginfo in dynamically realigned functions (PR debug/40596) - speed up polyhedron NF (PR middle-end/34163) - epilogue unwinding fixes (PRs bootstrap/40347, debug/40462) - fix debug info for inlines (PR debug/40573) - optimize assuming allocatable arrays in the innermost dimension are always stride 1 (PR fortran/32131) geglmm-0.1.0-1.fc12 ------------------- * Tue Jul 07 2009 Dodji Seketeli - 0.1.0-1 - Update to new upstream release (0.1.0) - Remove add-cstdio.patch and kill-warnings.patch as integrated upstream glibc-2.10.90-3 --------------- * Wed Jul 08 2009 Andreas Schwab 2.10.90-3 - Reenable setuid on pt_chown. gnome-desktop-2.27.3-2.fc12 --------------------------- * Tue Jul 07 2009 Adam Jackson 2.27.3-2 - gnome-desktop-2.27.3-edid-prop-name.patch: Adapt to RANDR 1.3's new name for the EDID output property. gnome-power-manager-2.27.2-2.fc12 --------------------------------- * Tue Jul 07 2009 Tom "spot" Callaway - 2.27.2-2 - fix file ownership so that only this packages manpages are owned, resolves duplicate directory ownership with "filesystem" package gtk2-2.17.3-2.fc12 ------------------ * Wed Jul 08 2009 Matthias Clasen - 2.17.3-2 - Some fixes for drawing issues, e.g. with statusicons guiloader-2.15.0-1.fc12 ----------------------- * Tue Jul 07 2009 Fabian Affolter - 2.15.0-1 - Removed Patch0 - Updated to new upstream version 2.15.0 gxemul-0.4.7.2-1.fc12 --------------------- * Wed Jul 08 2009 Tom "spot" Callaway - 0.4.7.2-1 - update to 0.4.7.2 hunspell-1.2.8-8.fc12 --------------------- * Tue Jul 07 2009 Caolan McNamara - 1.2.8-8 - Resolves: rhbz#509882 ignore an empty LANGUAGE variable hunspell-pl-0.20090708-1.fc12 ----------------------------- * Wed Jul 08 2009 Caolan McNamara - 0.20090708-1 - latest version hwdata-0.225-2.fc12 ------------------- * Tue Jul 07 2009 Adam Jackson 0.225-2 - pnp-dell.patch: Fix Dell's entry in pnp.ids ice-3.3.1-2.fc12 ---------------- * Wed Jul 08 2009 Mary Ellen Foster - 3.3.1-2 - Include upstream patches: - slice2html creates bad links - slice compilers abort on symlinks and double backslashes - random endpoint selection in .Net See http://www.zeroc.com/forums/patches/ for details kacst-fonts-2.0-4.fc12 ---------------------- * Thu Jul 09 2009 Pravin Satpute - 2.0-4 - cleaned rpmlink * Wed Jul 08 2009 Pravin Satpute - 2.0-3 - updated spec as per new font packaging guideline kde-i18n-3.5.10-8.fc12 ---------------------- * Tue Jul 07 2009 Tom "spot" Callaway 1:3.5.10-7 - fix duplicate directory ownership (/usr/share/locale/*/LC_MESSAGES) * Tue Jul 07 2009 Tom "spot" Callaway 1:3.5.10-8 - catch the missing files in the locale directories kde-l10n-4.2.95-2.fc12 ---------------------- * Tue Jul 07 2009 Tom "spot" Callaway - 4.2.95-2 - fix duplicate directory ownership (/usr/share/locale/*/LC_MESSAGES) kdeedu-4.2.95-3.fc12 -------------------- * Tue Jul 07 2009 Rex Dieter - 4.2.95-3 - rebuild against fixed libqalculate to purge cln dep kdelibs-4.2.95-4.fc12 --------------------- * Wed Jul 08 2009 Kevin Kofler - 4.2.95-4 - fix CMake dependency in parallel_devel patch (#510259, CHIKAMA Masaki) kernel-2.6.31-0.54.rc2.git2.fc12 -------------------------------- * Wed Jul 08 2009 Steve Dickson - Added NFSD v4 dynamic pseudo root patch which allows NFS v3 exports to be mounted by v4 clients. * Wed Jul 08 2009 Kyle McMartin 2.6.31-0.54.rc2.git2 - Rebase and re-apply all the Fedora-specific linux-2.6-debug-* patches. - Cull a bunch of upstreamed patches from the spec. * Tue Jul 07 2009 Jarod Wilson - Make lirc_i2c actually work with 2.6.31 i2c * Tue Jul 07 2009 Chuck Ebbert 2.6.31-0.47.rc2.git2 - 2.6.31-rc2-git2 * Tue Jul 07 2009 Jarod Wilson - See if we can't make lirc_streamzap behave better... (#508952) * Mon Jul 06 2009 Jarod Wilson - Hack up lirc_i2c and lirc_zilog to compile with 2.6.31 i2c changes. The drivers might not actually be functional now, but at least they compile again. Will fix later, if need be... * Mon Jul 06 2009 Chuck Ebbert - Use LZMA for kernel compression on X86. kicad-2009.07.07-1.rev1863.fc12 ------------------------------- * Tue Jul 07 2009 Chitlesh Goorah - 2009.07.07-1.rev1863 - svn rev 1863 - documentation splitted into multiple packages - libraries are now taken directly from SVN rather than from older releases - build changed to cmake based kpackagekit-0.4.1.1-2.fc12 -------------------------- * Tue Jul 07 2009 Steven M. Parrish 0.4.1.1-2 - rebuild for new packagekit ktorrent-3.2.2-3.fc12 --------------------- * Tue Jul 07 2009 Rex Dieter - 3.2.2-3 - don't use internal flags (prefer those provided by kdebase-runtime-flags) libcgroup-0.34-1.fc12 --------------------- * Tue Jul 07 2009 Jan Safranek 0.34-1 - Update to 0.34 libguestfs-1.0.56-2.fc12 ------------------------ * Tue Jul 07 2009 Richard W.M. Jones - 1.0.56-2 - New upstream release 1.0.56. - Don't rerun generator. libkate-0.3.4-1.fc12 -------------------- * Wed Jul 08 2009 kwizart < kwizart at gmail.com > - 0.3.4-1 - Update to 0.3.4 libselinux-2.0.84-1.fc12 ------------------------ * Tue Jul 07 2009 Dan Walsh - 2.0.84-1 - Update to upstream * Add per-service seuser support from Dan Walsh. * Let load_policy gracefully handle selinuxfs being mounted from Stephen Smalley. * Check /proc/filesystems before /proc/mounts for selinuxfs from Eric Paris. libsepol-2.0.37-1.fc12 ---------------------- * Tue Jul 07 2009 Dan Walsh 2.0.37-1 - Upgrade to latest from NSA * Add method to check disable dontaudit flag from Christopher Pardy. libvirt-qpid-0.2.16-5.fc12 -------------------------- * Fri Jun 05 2009 Ian Main - 0.2.16-1 - Cache calls to get storage XML as they take a LONG time. This greatly speeds up volume enumeration. * Fri Jun 05 2009 Ian Main - 0.2.16-2 - Spec fixes. * Fri Jun 05 2009 Ian Main - 0.2.16-5 - Bump for new build. * Thu May 28 2009 Ian Main - 0.2.15-1 - Fix migration bug. * Thu May 28 2009 Ian Main - 0.2.16-1 - Cache calls to get storage XML as they take a LONG time. This greatly speeds up volume enumeration. libvorbis-1.2.2-2.fc12 ---------------------- * Wed Jul 08 2009 Adam Jackson 1.2.2-2 - libvorbis-1.2.2-svn16228.patch: Backport a fix from pre-1.2.3 to hopefully fix small sound file playback. (#505610) lm_sensors-3.1.1-1.fc12 ----------------------- * Tue Jul 07 2009 Nikola Pajokvsky 3.1.1-1 - New release 3.1.1 logwatch-7.3.6-46.fc12 ---------------------- * Tue Jul 07 2009 Ivana Varekova 7.3.6-16 - fix cron script lxinput-0.1.1-1.fc12 -------------------- * Tue Jul 07 2009 Christoph Wickert - 0.1.1-1 - Update to 0.1.1 - Include new manpage lxlauncher-0.2.1-1.fc12 ----------------------- * Tue Jul 07 2009 Christoph Wickert - 0.2.1-1 - Update to 0.2.1 - Switch from libgnome-menu to menu-cache madan-fonts-1.0-9.fc12 ---------------------- * Wed Jul 08 2009 Pravin Satpute - 1.0-9 - updated spec as per new packaging guideline mailman-2.1.12-6.fc12 --------------------- * Wed Jul 08 2009 Daniel Novotny 3:2.1.12-6 - fix bz#509689 - please remove execute perms * Tue Jul 07 2009 Daniel Novotny 3:2.1.12-5 - hardcoded library path removed - mixed use of spaces and tabs fixed - added --libdir to configure - fixed URL to tarball - permissions of source files changed to 0644 - got rid of "file listed twice" warnings: listing the files explicitly - all this were cleanups for merge review (#226117) mobile-broadband-provider-info-1.20090707-1.fc12 ------------------------------------------------ * Tue Jul 07 2009 Dan Williams - 1.20090707-1 - Update to latest upstream release including: - T-Mobile USA - Brazil - Bangladesh - Sweden - Spain - Moldova mock-0.9.17-1.fc12 ------------------ * Wed Jul 08 2009 Clark Williams - 0.9.17-1 - Patch from Jakub Jelinek for mounting /dev/pts correctly in the chroot (BZ# 510183) - raise exception when --shell specified for uninitialized chroot (BZ# 506288) - add directory and infrastructure to allow dbus to run inside chroot (BZ# 460574) - patch from Levente Farkas to fix exclude in EPEL 5 x86_64 config mythes-de-0.20090708-1.fc12 --------------------------- * Wed Jul 08 2009 Caolan McNamara - 0.20090708-1 - latest version mythes-es-0.20090708-1.fc12 --------------------------- * Wed Jul 08 2009 Caol?n McNamara - 0.20090708-1 - latest version mythes-nl-0.20090708-1.fc12 --------------------------- * Wed Jul 08 2009 Caolan McNamara - 0.20090708-1 - latest version mythes-sk-0.20090707-1.fc12 --------------------------- * Wed Jul 08 2009 Caolan McNamara - 0.20090707-1 - latest version mythes-sl-0.20090708-1.fc12 --------------------------- * Wed Jul 08 2009 Caolan McNamara - 0.20090708-1 - latest version ncl-5.1.0-4.fc12 ---------------- * Tue Jul 07 2009 - Orion Poplawski - 5.1.0-4 - Fixup more paths in shipped ncl scripts (bug #505240) net-tools-1.60-93.fc12 ---------------------- * Wed Jul 08 2009 Jiri Popelka - 1.60-93 - scanf format length fix (non exploitable?) from Fabian Hugelshofer - URL tag changed to http://net-tools.berlios.de/ nethack-vultures-2.1.2-1.fc12 ----------------------------- * Sat May 23 2009 Ville Skytt? - 2.1.2-1 - Update to 2.1.2 (#502292). - Patch to log in %{_var}/log/vultures. - Bring icon cache update scriptlets up to date with current guidelines. - Simplify and improve space savings by using hardlink. - Build with bison instead of byacc; bison is needed anyway. - Drop default patch fuzz, apply it selectively. nss_ldap-264-4.fc12 ------------------- * Tue Jul 07 2009 Nalin Dahyabhai - 264-4 - add proposed patch for upstream #322: crashing in oneshot mode * Mon Jul 06 2009 Nalin Dahyabhai - add but don't apply proposed patch for upstream #399: depending on the server to enforce the expected case-sensitivity opens up corner cases opal-3.6.4-2.fc12 ----------------- * Mon Jul 06 2009 Peter Robinson - 3.6.4-1 - New 3.6.4 stable release * Mon Jul 06 2009 Peter Robinson - 3.6.4-2 - Increment required ptlib version openais-1.0.0-1.fc12 -------------------- * Wed Jul 08 2009 Fabio M. Di Nitto - 1.0.0-1 - New upstream release openvrml-0.18.2-1.fc12 ---------------------- * Tue Jul 07 2009 Braden McDaniel - 0.18.2-1 - Updated to 0.18.2. - Removed unnecessary Requires from openvrml-devel. * Mon Jul 06 2009 Braden McDaniel - 0.18.1-2 - Added BuildRequires: libtool-ltdl-devel. * Sun Jul 05 2009 Braden McDaniel - 0.18.1-1 - Updated to 0.18.1. - Put documentation in doc subpackage. - Added check phase back. paktype-fonts-2.0-4.fc12 ------------------------ * Thu Jul 09 2009 Pravin Satpute 2.0-4 - updated as per new font packaging guideline perl-5.10.0-73.fc12 ------------------- * Tue Jul 07 2009 Stepan Kasal - 4:5.10.0-72 - move -DPERL_USE_SAFE_PUTENV to ccflags (#508496) * Tue Jul 07 2009 Stepan Kasal - 4:5.10.0-73 - re-enable tests perl-Catalyst-Controller-HTML-FormFu-0.05000-1.fc12 --------------------------------------------------- * Wed Jul 08 2009 Iain Arnell 0.05000-1 - update to latest upstream version - BR perl(namespace::autoclean) perl-Devel-REPL-1.003007-2.fc12 ------------------------------- * Tue Jul 07 2009 Iain Arnell 1.003007-1 - update to latest version (fixes rt#44919) * Tue Jul 07 2009 Iain Arnell 1.003007-2 - BR perl(CPAN) perl-HTML-FormFu-0.05001-1.fc12 ------------------------------- * Tue Jul 07 2009 Iain Arnell 0.05001-1 - update to latest upstream version perl-Wx-0.91-5.fc12 ------------------- * Tue Jul 07 2009 Stepan Kasal - 0.91-4 - rebuild against perl-5.10.0-72 (#508496) * Tue Jul 07 2009 Stepan Kasal - 0.91-5 - return back RPM_OPT_FLAGS pl-5.7.11-2.fc12 ---------------- * Tue Jul 07 2009 Mary Ellen Foster - 5.7.11-2 - Really fix issue with compiling "maildrop" packages policycoreutils-2.0.64-2.fc12 ----------------------------- * Tue Jul 07 2009 Tom "spot" Callaway 2.0.64-2 - fix multiple directory ownership of mandirs qemu-0.10.50-9.kvm87.fc12 ------------------------- * Tue Jul 07 2009 Glauber Costa - 2:0.10.50-9.kvm87 - use pxe roms from gpxe, instead of etherboot package. resource-agents-3.0.0-12.fc12 ----------------------------- * Wed Jul 08 2009 Fabio M. Di Nitto - 3.0.0-12 - - spec file updates: * Update copyright header * final release.. undefine alphatag rhm-0.5.3465-2.fc12 ------------------- ruby-openid-2.1.7-1.fc12 ------------------------ * Tue Jul 07 2009 Allisson Azevedo 2.1.7-1 - Update to 2.1.7 selinux-policy-3.6.21-3.fc12 ---------------------------- * Wed Jul 08 2009 Dan Walsh 3.6.21-3 - Fixes for xguest * Tue Jul 07 2009 Tom "spot" Callaway 3.6.21-2 - fix multiple directory ownership of mandirs * Wed Jul 01 2009 Dan Walsh 3.6.21-1 - Update to upstream setroubleshoot-2.2.13-1.fc12 ---------------------------- * Tue Jul 07 2009 Dan Walsh - 2.2.13-1 - Update to upstream 2009-7-07 Thomas Liu - Fixed detail doc not clearing when deleting all alerts - Hid notify check when deleting all alerts. setroubleshoot-plugins-2.1.8-1.fc12 ----------------------------------- * Tue Jul 07 2009 - 2.1.8-1 - Add avc.source=sendmail to httpd_can_sendmail shorewall-4.4.0-0.1.Beta3.fc12 ------------------------------ * Tue Jul 07 2009 Jonathan G. Underwood - 4.4.0-0.1.Beta3 - Update to 4.4.0-Beta3 smolt-1.3-1.fc12 ---------------- * Thu Jul 02 2009 Mike McGrath - 1.3-1 - Added touch for generated stats - Upstream released new version spamassassin-3.3.0-0.2.alpha1.fc12 ---------------------------------- * Tue Jul 07 2009 Warren Togami - 3.3.0-0.2.alpha1 - Include default rules to prevent mass confusion and complaints. You should really use sa-update though. Really. Edit /etc/cron.d/sa-update to automate it. * Mon Jul 06 2009 Warren Togami - 3.3.0-0.1.alpha1 - 3.3.0-alpha1 supybot-meetbot-0.1.1-2.fc12 ---------------------------- * Tue Jul 07 2009 Kevin Fenzi - 0.1.1-2 - Fix install location to be the correct name. - Add additional doc files system-config-httpd-1.4.4-5.fc12 -------------------------------- * Tue Jul 07 2009 Tom "spot" Callaway - 5:1.4.4-5 - fix duplicate directory ownership (/usr/share/applications/) system-config-language-1.3.2-7.fc12 ----------------------------------- * Tue Jul 07 2009 Pravin Satpute - 1.3.2-7 - fix bug 598975 tcpjunk-2.7.01-1.fc12 --------------------- * Tue Jul 07 2009 Fabian Affolter - 2.7.01-1 - Updated to new upsteram version 2.7.01 terminator-0.13-2.fc12 ---------------------- * Tue Jul 07 2009 Ian Weller - 0.13-2 - BuildRequires: intltool * Thu Jul 02 2009 Ian Weller - 0.13-1 - New upstream release tritonus-0.3.7-0.4.20090419cvs.fc12 ----------------------------------- * Wed Jul 08 2009 Orcan Ogetbil - 0.3.7-0.4.20090419cvs - Fix alsa midi crash RHBZ #510063 - No more rebuilding in %install ucarp-1.5.1-1.fc12 ------------------ * Wed Jul 08 2009 Jon Ciesla - 1.5.1-1 - New upstream. - New option (--nomcast / -M) to use broadcast - advertisements instead of multicast ones. uget-1.4.9-1.fc12 ----------------- * Wed Jul 08 2009 Mamoru Tasaka - 1.4.9-1 - 1.4.9 uw-imap-2007e-7.fc12 -------------------- * Wed Jul 08 2009 Rex Dieter - 2007e-7 - fix shared.patch to use CFLAGS for osdep.c too * Tue Jul 07 2009 Rex Dieter - 2007e-6 - build with -fPIC - rebase patches (patch fuzz=0) vala-0.7.4-1.fc12 ----------------- * Tue Jul 07 2009 Michel Salim - 0.7.4-1 - Update to 0.7.4 vdr-text2skin-1.2-1.fc12 ------------------------ * Thu Jul 09 2009 Ville Skytt? - 1.2-1 - Update to 1.2. - Specfile cleanups. - Fix spelling errors in description. vidalia-0.1.14-1.fc12 --------------------- * Tue Jul 07 2009 Simon Wesp - 0.1.14-1 - New upstream release webkitgtk-1.1.10-3.fc12 ----------------------- * Wed Jul 08 2009 Peter Gordon - 1.1.10-3 - Move jsc to the -devel subpackage (#510355). xfce4-xkb-plugin-0.5.2-4.fc12 ----------------------------- * Tue Jul 07 2009 Adam Jackson 0.5.2-4 - xxp-0.5.2-xklavier-api.patch: Fix for new libxklavier API. xorg-x11-drv-nv-2.1.14-1.fc12 ----------------------------- * Tue Jul 07 2009 Adam Jackson 2.1.14-1 - nv 2.1.14 xorg-x11-server-utils-7.4-10.fc12 --------------------------------- * Tue Jul 07 2009 Adam Jackson 7.4-10 - xrandr 1.3.0 xorg-x11-xkb-utils-7.4-4.fc12 ----------------------------- * Thu Jul 09 2009 Peter Hutterer 7.4-3 - xkbcomp 1.1.0 * Thu Jul 09 2009 Peter Hutterer 7.4-4 - setxkbmap 1.1.0 xscorch-0.2.1-0.3.pre2.fc12 --------------------------- * Wed Jul 08 2009 Marcin Garski 0.2.1-0.3.pre2 - Update to 0.2.1-pre2 yum-utils-1.1.22-2.fc12 ----------------------- * Tue Jul 07 2009 Seth Vidal - patch to repoclosure so spam-o-matic works again in rawhide Summary: Added Packages: 18 Removed Packages: 0 Modified Packages: 107 Broken deps for i386 ---------------------------------------------------------- R-RScaLAPACK-0.5.1-19.fc11.i586 requires openmpi-libs bmpx-0.40.14-8.fc11.i386 requires libboost_iostreams-mt.so.4 bmpx-0.40.14-8.fc11.i386 requires libboost_regex-mt.so.4 clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.i586 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.i586 requires gauche = 0:0.8.13 ginac-1.5.1-1.fc11.i586 requires libcln.so.5 ginac-utils-1.5.1-1.fc11.i586 requires libcln.so.5 guiloader-c++-2.13.0-2.fc11.i586 requires libguiloader.so.0 libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 octave-forge-20080831-8.fc11.i586 requires libcln.so.5 orsa-0.7.0-8.fc11.i586 requires libcln.so.5 ppl-swiprolog-0.10.2-3.fc12.i586 requires libpl.so.5.7.6 pyclutter-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.i386 requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.i386 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.i586 requires libgeos-3.0.3.so rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.i586 requires libpqxx-2.6.8.so springlobby-0.0.1.10461-1.fc12.i586 requires libtorrent-rasterbar.so.3 thunderbird-lightning-1.0-0.5.20090513hg.fc12.i586 requires thunderbird >= 0:3.0-2.4.b3pre vtk-examples-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 Broken deps for x86_64 ---------------------------------------------------------- R-RScaLAPACK-0.5.1-19.fc11.x86_64 requires openmpi-libs bmpx-0.40.14-8.fc11.x86_64 requires libboost_regex.so.4()(64bit) bmpx-0.40.14-8.fc11.x86_64 requires libboost_iostreams.so.4()(64bit) clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.x86_64 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.x86_64 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.x86_64 requires gauche = 0:0.8.13 ginac-1.5.1-1.fc11.i586 requires libcln.so.5 ginac-1.5.1-1.fc11.x86_64 requires libcln.so.5()(64bit) ginac-utils-1.5.1-1.fc11.x86_64 requires libcln.so.5()(64bit) guiloader-c++-2.13.0-2.fc11.i586 requires libguiloader.so.0 guiloader-c++-2.13.0-2.fc11.x86_64 requires libguiloader.so.0()(64bit) libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.x86_64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 libprojectM-1.2.0-9.fc11.x86_64 requires libftgl.so.0()(64bit) octave-forge-20080831-8.fc11.x86_64 requires libcln.so.5()(64bit) orsa-0.7.0-8.fc11.i586 requires libcln.so.5 orsa-0.7.0-8.fc11.x86_64 requires libcln.so.5()(64bit) ppl-swiprolog-0.10.2-3.fc12.x86_64 requires libpl.so.5.7.6()(64bit) pyclutter-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.x86_64 requires libgeos-3.0.3.so()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.x86_64 requires libpqxx-2.6.8.so()(64bit) springlobby-0.0.1.10461-1.fc12.x86_64 requires libtorrent-rasterbar.so.3()(64bit) thunderbird-lightning-1.0-0.5.20090513hg.fc12.x86_64 requires thunderbird >= 0:3.0-2.4.b3pre vtk-examples-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 Broken deps for ppc ---------------------------------------------------------- R-RScaLAPACK-0.5.1-19.fc11.ppc requires openmpi-libs bmpx-0.40.14-8.fc11.ppc requires libboost_iostreams-mt.so.4 bmpx-0.40.14-8.fc11.ppc requires libboost_regex-mt.so.4 clutter-cairo-0.8.2-3.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.ppc requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.ppc requires gauche = 0:0.8.13 ginac-1.5.1-1.fc11.ppc requires libcln.so.5 ginac-1.5.1-1.fc11.ppc64 requires libcln.so.5()(64bit) ginac-utils-1.5.1-1.fc11.ppc requires libcln.so.5 guiloader-c++-2.13.0-2.fc11.ppc requires libguiloader.so.0 guiloader-c++-2.13.0-2.fc11.ppc64 requires libguiloader.so.0()(64bit) libchamplain-0.2.9-1.fc11.ppc requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc requires libftgl.so.0 libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) octave-forge-20080831-8.fc11.ppc requires libcln.so.5 orsa-0.7.0-8.fc11.ppc requires libcln.so.5 orsa-0.7.0-8.fc11.ppc64 requires libcln.so.5()(64bit) ppl-swiprolog-0.10.2-3.fc12.ppc requires libpl.so.5.7.6 pyclutter-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.ppc requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.ppc requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.ppc requires libgeos-3.0.3.so rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc requires libpqxx-2.6.8.so thunderbird-lightning-1.0-0.5.20090513hg.fc12.ppc requires thunderbird >= 0:3.0-2.4.b3pre vtk-examples-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 Broken deps for ppc64 ---------------------------------------------------------- R-RScaLAPACK-0.5.1-19.fc11.ppc64 requires openmpi-libs bmpx-0.40.14-8.fc11.ppc64 requires libboost_regex.so.4()(64bit) bmpx-0.40.14-8.fc11.ppc64 requires libboost_iostreams.so.4()(64bit) clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) ginac-1.5.1-1.fc11.ppc64 requires libcln.so.5()(64bit) ginac-utils-1.5.1-1.fc11.ppc64 requires libcln.so.5()(64bit) guiloader-c++-2.13.0-2.fc11.ppc64 requires libguiloader.so.0()(64bit) libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) octave-forge-20080831-8.fc11.ppc64 requires libcln.so.5()(64bit) orsa-0.7.0-8.fc11.ppc64 requires libcln.so.5()(64bit) ppl-swiprolog-0.10.2-3.fc12.ppc64 requires libpl.so.5.7.6()(64bit) pyclutter-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.ppc64 requires libgeos-3.0.3.so()(64bit) python-mwlib-0.11.2-2.20090522hg2956.fc12.ppc64 requires LabPlot rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc64 requires libpqxx-2.6.8.so()(64bit) thunderbird-lightning-1.0-0.5.20090513hg.fc12.ppc64 requires thunderbird >= 0:3.0-2.4.b3pre vtk-examples-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 From jussilehtola at fedoraproject.org Thu Jul 9 16:51:59 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Thu, 09 Jul 2009 19:51:59 +0300 Subject: noarch subpackages In-Reply-To: <4A561AAF.2010305@lfarkas.org> References: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> <20090708170639.21f9b4bf@faldor> <9514c41a0ff9d6e5be9b2ad6f16331d6.squirrel@intranet.cs.nmsu.edu> <4A561AAF.2010305@lfarkas.org> Message-ID: <1247158319.2589.22.camel@localhost.localdomain> On Thu, 2009-07-09 at 18:28 +0200, Farkas Levente wrote: > > Except it should be: > > %if 0%{?fedora} > 9 || 0%{?rhel} > 5 > > it'd be nice if _all_ packages which have noarch subpackage use this > since most fedora packager reply to my such patches that they don't care > about rhel/centos:-( This should really be a macro in rpm, as it has to be duplicated in so many places. Say, %{_noarch_subpackage} which would expand to %if 0%{?fedora} > 9 || 0%{?rhel} > 5 BuildArch: noarch %endif -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From rjones at redhat.com Thu Jul 9 17:51:49 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 9 Jul 2009 18:51:49 +0100 Subject: prelink: is it worth it? In-Reply-To: References: <20090709143201.GA22885@jadzia.bu.edu> Message-ID: <20090709175149.GA21731@amd.home.annexia.org> On Thu, Jul 09, 2009 at 04:45:55PM +0200, devzero2000 wrote: > 2 - not checked if this problem is actual or not: prelink erases file-based > capabilities And not just that - it nukes other stuff too. Old-style OCaml bytecode programs[1] and there was some MinGW binary problem too, can't find the BZ for that right now. I think the mistake was to change binaries directly. It should just store additional hints about binaries in a /var/ directory somewhere. Rich. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460730 -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 75 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From opensource at till.name Thu Jul 9 18:11:51 2009 From: opensource at till.name (Till Maas) Date: Thu, 09 Jul 2009 20:11:51 +0200 Subject: prelink: is it worth it? In-Reply-To: <1247156457.23660.84.camel@vespa.frost.loc> References: <20090709143201.GA22885@jadzia.bu.edu> <200907091759.38976.opensource@till.name> <1247156457.23660.84.camel@vespa.frost.loc> Message-ID: <200907092011.57483.opensource@till.name> On Thu July 9 2009, Tomas Mraz wrote: > On Thu, 2009-07-09 at 17:59 +0200, Till Maas wrote: > > On Thu July 9 2009, yersinia wrote: > > > But something one have to pay a security prize on not disabling it : > > > it render impossible to have a > > > centralizzated security integrity management (e.g. rfc.sf.net for > > > example) or one have to skip from check the prelink binary. Very bad i > > > think. > > > > You pay a security prize if you disable prelink, because it also performs > > address space randomization: > > http://lwn.net/Articles/190139/ > > That's nonsense. Actually with prelink the randomization is done only > when prelink is rerun as the addresses can change only during the > prelinking. I fail to understand what is nonsense, since you agree that prelink performs randomization. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From pinto.elia at gmail.com Thu Jul 9 18:12:59 2009 From: pinto.elia at gmail.com (devzero2000) Date: Thu, 9 Jul 2009 20:12:59 +0200 Subject: prelink: is it worth it? In-Reply-To: <200907091759.38976.opensource@till.name> References: <20090709143201.GA22885@jadzia.bu.edu> <4A5604EA.9090107@redhat.com> <200907091759.38976.opensource@till.name> Message-ID: On Thu, Jul 9, 2009 at 5:59 PM, Till Maas wrote: > On Thu July 9 2009, yersinia wrote: > > > But something one have to pay a security prize on not disabling it : it > > render impossible to have a > > centralizzated security integrity management (e.g. rfc.sf.net for > example) > > or one have to skip from check the prelink binary. Very bad i think. > > You pay a security prize if you disable prelink, because it also performs > address space randomization: > http://lwn.net/Articles/190139/ > Strange enough this authorative refs, imho, not cited prelink as a security feature for aslr :=) http://www.awe.com/mark/blog/200801070918.html Btw, the reality is more complex this days -------------- next part -------------- An HTML attachment was scrubbed... URL: From yersinia.spiros at gmail.com Thu Jul 9 18:15:17 2009 From: yersinia.spiros at gmail.com (yersinia) Date: Thu, 9 Jul 2009 20:15:17 +0200 Subject: prelink: is it worth it? In-Reply-To: <200907091759.38976.opensource@till.name> References: <20090709143201.GA22885@jadzia.bu.edu> <4A5604EA.9090107@redhat.com> <200907091759.38976.opensource@till.name> Message-ID: On Thu, Jul 9, 2009 at 5:59 PM, Till Maas wrote: > On Thu July 9 2009, yersinia wrote: > > > But something one have to pay a security prize on not disabling it : it > > render impossible to have a > > centralizzated security integrity management (e.g. rfc.sf.net for > example) > > or one have to skip from check the prelink binary. Very bad i think. > > You pay a security prize if you disable prelink, because it also performs > address space randomization: > http://lwn.net/Articles/190139/ > Strange enough this authorative refs, imho, not cited prelink as a security feature for aslr :=) http://www.awe.com/mark/blog/200801070918.html Btw, the reality is more complex this days. Details omitted, this is not a security mailing list. Regards > Btw. you can also patch the remote integrity checker to use prelink to > either > get a checksum of the perlinked binary or undo the prelinking before > checking > it. > > Regards > Till > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Thu Jul 9 18:17:46 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 09 Jul 2009 20:17:46 +0200 Subject: prelink: is it worth it? References: <20090709143201.GA22885@jadzia.bu.edu> <200907091759.38976.opensource@till.name> <1247156457.23660.84.camel@vespa.frost.loc> <200907092011.57483.opensource@till.name> Message-ID: Till Maas wrote: > I fail to understand what is nonsense, since you agree that prelink > performs randomization. If the binary is not prelinked, the kernel randomizes the address spaces at runtime, which is more secure than the prelink-time randomization. Kevin Kofler From sgrubb at redhat.com Thu Jul 9 18:19:25 2009 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 9 Jul 2009 14:19:25 -0400 Subject: prelink: is it worth it? In-Reply-To: References: <20090709143201.GA22885@jadzia.bu.edu> Message-ID: <200907091419.25259.sgrubb@redhat.com> On Thursday 09 July 2009 10:45:55 am devzero2000 wrote: > There are also other two big problem, imho, now, with prelink support: > > 1 - it render impossibile to do a centralizzated integrity checker (with as > example rfc.sf.net ): very very bad The aide program in rawhide is prelink friendly. So there are integrity checkers that can be used. As for security, prelink stirring around address space randomization is good for security. For example, this hack needed prelink not to have run to get the exploit reliable: http://invisiblethingslab.com/pub/xenfb-adventures-10.pdf There are more examples like this. -Steve From rvinyard at cs.nmsu.edu Thu Jul 9 18:50:35 2009 From: rvinyard at cs.nmsu.edu (Rick L. Vinyard, Jr.) Date: Thu, 9 Jul 2009 12:50:35 -0600 Subject: noarch subpackages In-Reply-To: <1247158319.2589.22.camel@localhost.localdomain> References: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> <20090708170639.21f9b4bf@faldor> <9514c41a0ff9d6e5be9b2ad6f16331d6.squirrel@intranet.cs.nmsu.edu> <4A561AAF.2010305@lfarkas.org> <1247158319.2589.22.camel@localhost.localdomain> Message-ID: <3763a78f3e725ef9b2af68a7d3d38113.squirrel@intranet.cs.nmsu.edu> Jussi Lehtola wrote: > On Thu, 2009-07-09 at 18:28 +0200, Farkas Levente wrote: >> > Except it should be: >> > %if 0%{?fedora} > 9 || 0%{?rhel} > 5 >> >> it'd be nice if _all_ packages which have noarch subpackage use this >> since most fedora packager reply to my such patches that they don't care >> about rhel/centos:-( > > This should really be a macro in rpm, as it has to be duplicated in so > many places. Say, %{_noarch_subpackage} which would expand to > > %if 0%{?fedora} > 9 || 0%{?rhel} > 5 > BuildArch: noarch > %endif Yes, it really should. Otherwise, some will look like: %if 0%{?fedora} > 9 BuildArch: noarch %endif and others like: %if 0%{?fedora} > 9 || 0%{?rhel} > 5 BuildArch: noarch %endif If you need further proof of the confusion simply look to this thread. Plus it is more expressive as to what the intent of the check is for, allowing a smoother migration process if, in the future, a check is put in for the rpm version. It would also allow a non-Fedora/RHEL/CentOS distro (SuSE???) to implement their own macro. From fedora at camperquake.de Thu Jul 9 18:54:20 2009 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 9 Jul 2009 20:54:20 +0200 Subject: rawhide report: 20090709 changes In-Reply-To: <20090709164232.GA1540@releng2.fedora.phx.redhat.com> References: <20090709164232.GA1540@releng2.fedora.phx.redhat.com> Message-ID: <20090709205420.03770c36@fred.camperquake.de> Hi. On Thu, 9 Jul 2009 16:42:32 +0000, Rawhide Report wrote > glibc-2.10.90-3 > --------------- > * Wed Jul 08 2009 Andreas Schwab 2.10.90-3 > - Reenable setuid on pt_chown. That glibc explodes on my x64 laptop (everything segfaults), reverting to -2 fixes that. From clydekunkel7734 at cox.net Thu Jul 9 19:41:36 2009 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Thu, 09 Jul 2009 15:41:36 -0400 Subject: [ANNOUNCEMENT] dracut-0.3 In-Reply-To: <4A4C92FA.50501@redhat.com> References: <4A4C92FA.50501@redhat.com> Message-ID: <4A5647F0.4080908@cox.net> On 07/02/2009 06:59 AM, Harald Hoyer wrote: > Here it is, dracut-0.3! > > Featuring booting from all kind of block devices, NFS, iSCSI and NBD. > > Dracut is a new initramfs infrastructure. It should replace nash/mkinitrd. > Dracut is a feauture for Fedora 12 > http://fedoraproject.org/wiki/Features/Dracut > > How to get started, if you want to test. > > # yum install dracut-0.3 > > To generate a initramfs image, run: > > # dracut > > to overwrite an existing image: > > # dracut -f > > Try to boot from that image by modifying /etc/grub.conf. Be sure to have > a fallback entry. > > If you want to boot from network have a look at the manpage. > Basically everything can be specified on the kernel command line. > > Bug reports can be send directly to me (harald at redhat.com) until dracut > appears in the bugzilla component list. > > Further information about dracut: > http://sourceforge.net/apps/trac/dracut/wiki > Will dracut work with a Fedora 11 guest vm? From ch.nolte at noltec.org Thu Jul 9 19:43:14 2009 From: ch.nolte at noltec.org (Christian Nolte) Date: Thu, 09 Jul 2009 21:43:14 +0200 Subject: Font-Size Problem with liberation-fonts In-Reply-To: <1247156171.4727.27.camel@d2> References: <4A5612ED.9060208@noltec.org> <1247156171.4727.27.camel@d2> Message-ID: <4A564852.7020008@noltec.org> On 09.07.2009 18:16, Yanko Kaneti wrote: > On Thu, 2009-07-09 at 17:55 +0200, Christian Nolte wrote: >> Hi, >> >> currently I am working on a website which should be displayed correctly >> on Linux and Windows using the "Arial"-Font. I've learned that >> liberation-fonts are the way to go (because they are metric compatible), >> and discovered a problem with a font-size below 12px. The fonts are >> rendered with different spaces between the characters independent of the >> browser, but seemingly dependent of the OS (so I blame the >> liberation-fonts). >> >> I am not quite sure if there are patent restriction or something else, >> which prevents liberation-fonts to be exact clones, so it would be nice >> if someone of you could tell me if this is expected behaviour, or a bug: >> >> Here are some screenshots of the browsers and OS combinations I have tested: >> >> ftp://velian.dyndns.org/pub/nolte/liberation-fonts/ie7-windows.png >> ftp://velian.dyndns.org/pub/nolte/liberation-fonts/ff-3.5-windows.png >> ftp://velian.dyndns.org/pub/nolte/liberation-fonts/ff-3.0.11-linux.png >> >> This is the testbed: >> ftp://velian.dyndns.org/pub/nolte/liberation-fonts/liberation-fonts-test.html >> >> I have only tested this with font-sizes of 12px, 11px and 10px. Below >> 12px liberation-fonts puts too much spaces between the characters, so >> that 10px with liberation-fonts is equal to 11px Arial on Windows. >> >> BTW I am currently using liberation-fonts-1.04-1.fc9.noarch. But the >> problem is visible on a F11-box too. > > See Bug 503430 - Incorrect Kerning in some applications > https://bugzilla.redhat.com/show_bug.cgi?id=503430 Thanks, Yanko for this hint! -- "He's a maverick playboy gentleman spy who hangs with the wrong crowd. She's a cynical tomboy queen of the dead who believes she is the reincarnation of an ancient Egyptian queen. They fight crime!" From yersinia.spiros at gmail.com Thu Jul 9 19:57:36 2009 From: yersinia.spiros at gmail.com (yersinia) Date: Thu, 9 Jul 2009 21:57:36 +0200 Subject: prelink: is it worth it? In-Reply-To: <200907091419.25259.sgrubb@redhat.com> References: <20090709143201.GA22885@jadzia.bu.edu> <200907091419.25259.sgrubb@redhat.com> Message-ID: On Thu, Jul 9, 2009 at 8:19 PM, Steve Grubb wrote: > On Thursday 09 July 2009 10:45:55 am devzero2000 wrote: > > There are also other two big problem, imho, now, with prelink support: > > > > 1 - it render impossibile to do a centralizzated integrity checker (with > as > > example rfc.sf.net ): very very bad > > The aide program in rawhide is prelink friendly. So there are integrity > checkers that can be used. > > As for security, prelink stirring around address space randomization is > good > for security. For example, this hack needed prelink not to have run to get > the > exploit reliable: > > http://invisiblethingslab.com/pub/xenfb-adventures-10.pdf > > There are more examples like this. > i know this ref. Tell me something other. I follow only 15 mailing list on these subjects. Anyway if prelink is a good thing for ASLR IT MUST BE DOCUMENTATED BETTER. I am sure anyone agreed on this. regards > > -Steve > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amdunn at gmail.com Thu Jul 9 19:59:58 2009 From: amdunn at gmail.com (Alan Dunn) Date: Thu, 9 Jul 2009 15:59:58 -0400 Subject: Conditionally applying a patch based on a program's EVR Message-ID: I want to conditionally apply a patch in a spec file based upon the version of a package. (There's an emacs package that needs a patch to work with the latest version of xemacs, but this patch shouldn't be applied for previous versions of xemacs.) I know that for checking something like Fedora version numbers I can use %if 0%{?fedora} > 9 ... %endif but is there an easy way to do this for a version number in say, EVR form? That is, something like %if %{program_version} > 1.2.3 ... %endif (%{program_version} will always be defined) RPM doesn't seem to support a mechanism like this in %if conditionals (I believe having a digit first causes rpmbuild to try and interpret the result as a number), though clearly there is a mechanism for examining EVRs of this form for other parts of rpmbuild. One could try something like %if "%{prorgram_version}" > "1.2.3" which does string comparison, but this doesn't work for some version combinations, since, for example, we would want 1.10.1 > 1.9.1 - Alan From yersinia.spiros at gmail.com Thu Jul 9 20:05:22 2009 From: yersinia.spiros at gmail.com (yersinia) Date: Thu, 9 Jul 2009 22:05:22 +0200 Subject: noarch subpackages In-Reply-To: <3763a78f3e725ef9b2af68a7d3d38113.squirrel@intranet.cs.nmsu.edu> References: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> <20090708170639.21f9b4bf@faldor> <9514c41a0ff9d6e5be9b2ad6f16331d6.squirrel@intranet.cs.nmsu.edu> <4A561AAF.2010305@lfarkas.org> <1247158319.2589.22.camel@localhost.localdomain> <3763a78f3e725ef9b2af68a7d3d38113.squirrel@intranet.cs.nmsu.edu> Message-ID: On Thu, Jul 9, 2009 at 8:50 PM, Rick L. Vinyard, Jr. wrote: > Jussi Lehtola wrote: > > On Thu, 2009-07-09 at 18:28 +0200, Farkas Levente wrote: > >> > Except it should be: > >> > %if 0%{?fedora} > 9 || 0%{?rhel} > 5 > >> > >> it'd be nice if _all_ packages which have noarch subpackage use this > >> since most fedora packager reply to my such patches that they don't care > >> about rhel/centos:-( > > > > This should really be a macro in rpm, as it has to be duplicated in so > > many places. Say, %{_noarch_subpackage} which would expand to > > > > %if 0%{?fedora} > 9 || 0%{?rhel} > 5 > > BuildArch: noarch > > %endif > > Yes, it really should. Otherwise, some will look like: > > %if 0%{?fedora} > 9 > BuildArch: noarch > %endif > > and others like: > > %if 0%{?fedora} > 9 || 0%{?rhel} > 5 > BuildArch: noarch > %endif > > If you need further proof of the confusion simply look to this thread. > > Plus it is more expressive as to what the intent of the check is for, > allowing a smoother migration process if, in the future, a check is put in > for the rpm version. So you agreed that the check is on the rpm version, not "distro" version. > > -- > 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 Jochen at herr-schmitt.de Thu Jul 9 20:07:05 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 09 Jul 2009 22:07:05 +0200 Subject: Conditionally applying a patch based on a program's EVR In-Reply-To: References: Message-ID: <4A564DE9.7060805@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 09.07.2009 21:59, schrieb Alan Dunn: > I want to conditionally apply a patch in a spec file based upon the > version of a package. (There's an emacs package that needs a patch to > work with the latest version of xemacs, but this patch shouldn't be > applied for previous versions of xemacs.) I know that for checking > something like Fedora version numbers I can use > > %if 0%{?fedora} > 9 > ... > %endif > > but is there an easy way to do this for a version number in say, EVR > form? That is, something like > I assume, that your match may fixed a issue caused by xemacs. So, I would to prefer, that the user should make a update to the specific release of xemacs on which the issue doesn't occurs. You may write someting link # You need xemacs >= to # fix the following issue ... Requires: xemacs >= Of corse, if the required release may not available on older distribution, you may embrace the Requires statement into a condition. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpWTd8ACgkQT2AHK6txfgyL+ACfYmujoW+Grc46ngj7gFSH1GER MGgAoMI7fLQnLjin2dJ8HNFFGCDQKy0Z =WR+q -----END PGP SIGNATURE----- From jussilehtola at fedoraproject.org Thu Jul 9 20:14:37 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Thu, 09 Jul 2009 23:14:37 +0300 Subject: noarch subpackages In-Reply-To: References: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> <20090708170639.21f9b4bf@faldor> <9514c41a0ff9d6e5be9b2ad6f16331d6.squirrel@intranet.cs.nmsu.edu> <4A561AAF.2010305@lfarkas.org> <1247158319.2589.22.camel@localhost.localdomain> <3763a78f3e725ef9b2af68a7d3d38113.squirrel@intranet.cs.nmsu.edu> Message-ID: <20090709231437.16001og6kj3vz54d@webmail.helsinki.fi> Lainaus yersinia : > On Thu, Jul 9, 2009 at 8:50 PM, Rick L. Vinyard, Jr. > wrote: > >> Jussi Lehtola wrote: >> >> > This should really be a macro in rpm, as it has to be duplicated in so >> > many places. Say, %{_noarch_subpackage} which would expand to >> >> Yes, it really should. Otherwise, some will look like: clip >> If you need further proof of the confusion simply look to this thread. >> >> Plus it is more expressive as to what the intent of the check is for, >> allowing a smoother migration process if, in the future, a check is put in >> for the rpm version. > > > So you agreed that the check is on the rpm version, not "distro" version. That would be up to the distro guys to do, since they can define the macro how they wish. SuSe might define it to use their corresponding %{dist} variable. Or, it could be defined to evaluate to empty, if the rpm version doesn't support it. Or, it could evaluate just the noarch bit. The beauty of this is, of course, that you could even skip the conditionals and just define the macro per distro basis (e.g. in the redhat-rpm-macros package): the macro in F-10 could be just %{nil} and in F-11 "BuildArch: noarch". There has been some discussion about versioning rpm specfiles, but I don't know whether that discussion lead anywhere. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From edwin at tenbrink-bekkers.nl Thu Jul 9 20:23:21 2009 From: edwin at tenbrink-bekkers.nl (Edwin ten Brink) Date: Thu, 9 Jul 2009 22:23:21 +0200 (CEST) Subject: Partitioning error during install Message-ID: <63033.195.240.127.3.1247171001.squirrel@webmail.tenbrink-bekkers.nl> >?But the problem I run into (no matter which I install), > is when I get to the partition section. I go to add a partition - not > as a primary (this should allow it to be an extended correct?) - and I > get an error and can't proceed any longer. > > So either anaconda is having problems with this setup (due to the > rewrite?), or I am doing something wrong causing it to crash.? Perhaps your problem is related to bug 493058 [1],where automatic bug reporting from anaconda?leads you?via bug 499236 [2]. Regards, Edwin [1] https://bugzilla.redhat.com/show_bug.cgi?id=493058 [2] https://bugzilla.redhat.com/show_bug.cgi?id=499236 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yersinia.spiros at gmail.com Thu Jul 9 20:31:18 2009 From: yersinia.spiros at gmail.com (yersinia) Date: Thu, 9 Jul 2009 22:31:18 +0200 Subject: noarch subpackages In-Reply-To: <20090709231437.16001og6kj3vz54d@webmail.helsinki.fi> References: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> <20090708170639.21f9b4bf@faldor> <9514c41a0ff9d6e5be9b2ad6f16331d6.squirrel@intranet.cs.nmsu.edu> <4A561AAF.2010305@lfarkas.org> <1247158319.2589.22.camel@localhost.localdomain> <3763a78f3e725ef9b2af68a7d3d38113.squirrel@intranet.cs.nmsu.edu> <20090709231437.16001og6kj3vz54d@webmail.helsinki.fi> Message-ID: On Thu, Jul 9, 2009 at 10:14 PM, Jussi Lehtola < jussilehtola at fedoraproject.org> wrote: > Lainaus yersinia : > > On Thu, Jul 9, 2009 at 8:50 PM, Rick L. Vinyard, Jr. >> wrote: >> >> Jussi Lehtola wrote: >>> >>> > This should really be a macro in rpm, as it has to be duplicated in so >>> > many places. Say, %{_noarch_subpackage} which would expand to >>> >>> Yes, it really should. Otherwise, some will look like: >>> >> > clip > > If you need further proof of the confusion simply look to this thread. >>> >>> Plus it is more expressive as to what the intent of the check is for, >>> allowing a smoother migration process if, in the future, a check is put >>> in >>> for the rpm version. >>> >> >> >> So you agreed that the check is on the rpm version, not "distro" version. >> > > That would be up to the distro guys to do, since they can define the macro > how they wish. He, macro %configure exist everywhere. Not bad at all to have everywhere a rpm_version macro upstream. Also in the past this could be useful (think to the %check stanza) > SuSe might define it to use their corresponding %{dist} variable. Or, it > could be defined to evaluate to empty, if the rpm version doesn't support > it. Or, it could evaluate just the noarch bit. > > The beauty of this is, of course, that you could even skip the conditionals > and just define the macro per distro basis (e.g. in the redhat-rpm-macros > package): the macro in F-10 could be just %{nil} and in F-11 "BuildArch: > noarch". > > There has been some discussion about versioning rpm specfiles, but I don't > know whether that discussion lead anywhere. > Noone care of this. the rpm world is different from the deb world : it is just a matter of fact, not sharp criticism at all. > > -- > Jussi Lehtola > Fedora Project Contributor > jussilehtola at fedoraproject.org > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarod at redhat.com Thu Jul 9 20:31:58 2009 From: jarod at redhat.com (Jarod Wilson) Date: Thu, 9 Jul 2009 16:31:58 -0400 Subject: Possible packages... In-Reply-To: <4A520EFB.4080703@redhat.com> References: <05069AE3-863E-4A0D-9E75-B42988B4B2EC@gnat.ca> <4A520EFB.4080703@redhat.com> Message-ID: <200907091631.59269.jarod@redhat.com> On Monday 06 July 2009 10:49:31 Eric Sandeen wrote: > Nathanael Noblet wrote: > > On Jul 5, 2009, at 9:33 PM, Eric Sandeen wrote: ... > > Well their python run script checks for its dependancies, and if not > > met will do a svn checkout of the right copy, however, they don't keep > > copies of the libraries within their own repository. So if you fulfill > > all its dependancies that shouldn't be an issue. > > Ah, ok - maybe that was it. Currently, it looks like it still requires its own builds of a few things. Stuff (apparently) not in Fedora: -pydirector -PyKerberos (might just be named something slightly different) Stuff in Fedora, but simply not used for whatever reason: -vobject (we have python-vobject) -pyflakes Stuff in Fedora, but still heavily patched for CalendarServer: -Twisted (the web2 portion, specifically) -xattr ("requires Bob Ippolito's implementation") That said, I have it up and running on an F11 host at home right now, satisfying everything else w/Fedora packages. > > I'm a little curious about the one library that F11 packages (libevent > > at 1.4.x, where calendar server seems to download a 1.5.x...) Do I > > repackage libevent as part of my packages to be reviewed? Or simply > > talk to the maintainer of libevent to see if it can be bumped? On my > > system the only package that required libevent was something related > > to nfs... though I guess there could be others but I haven't checked... > > Looking at http://monkey.org/~provos/libevent/ there's no mention of > 1.5.x on the front page anyway. Where does it get it? Fedora 11 has libevent 1.4.5. The calendarserver auto-build script tries to build 1.4.8. If you install libevent 1.4.11 from rawhide, its perfectly happy with that. -- Jarod Wilson jarod at redhat.com From nathanael at gnat.ca Thu Jul 9 21:02:45 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Thu, 09 Jul 2009 15:02:45 -0600 Subject: Possible packages... In-Reply-To: <200907091631.59269.jarod@redhat.com> References: <05069AE3-863E-4A0D-9E75-B42988B4B2EC@gnat.ca> <4A520EFB.4080703@redhat.com> <200907091631.59269.jarod@redhat.com> Message-ID: <4A565AF5.1050006@gnat.ca> On 07/09/2009 02:31 PM, Jarod Wilson wrote: > On Monday 06 July 2009 10:49:31 Eric Sandeen wrote: >> Nathanael Noblet wrote: >>> On Jul 5, 2009, at 9:33 PM, Eric Sandeen wrote: > .. >>> Well their python run script checks for its dependancies, and if not >>> met will do a svn checkout of the right copy, however, they don't keep >>> copies of the libraries within their own repository. So if you fulfill >>> all its dependancies that shouldn't be an issue. >> Ah, ok - maybe that was it. > > Currently, it looks like it still requires its own builds of a few > things. > > Stuff (apparently) not in Fedora: > -pydirector Yeah I don't think this is in fedora > -PyKerberos (might just be named something slightly different) I thought this was I could be wrong though. > > Stuff in Fedora, but simply not used for whatever reason: > -vobject (we have python-vobject) > -pyflakes I thought they were used if found... I'd have to look at the run file to see if they ignore the system versions.. > Stuff in Fedora, but still heavily patched for CalendarServer: > -Twisted (the web2 portion, specifically) > -xattr ("requires Bob Ippolito's implementation") I've got it using the fedora version of xattr I think, and didn't notice the patches to Twisted... > > That said, I have it up and running on an F11 host at home right now, > satisfying everything else w/Fedora packages. Yeah same here. From fedora at matbooth.co.uk Thu Jul 9 21:15:06 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Thu, 9 Jul 2009 22:15:06 +0100 Subject: 3Dsee.net java applet crashes firefox Message-ID: <9497e9990907091415m41fa3256m3c10f1d15df7f188@mail.gmail.com> I get an intermittant segfault in Firefox [1] when viewing the items in the gallery over at http://3dsee.net/Gallery (once even trashing the display and locking the machine up solid). Should I report this against Firefox or Java? I have the following installed: java-1.5.0-gcj.x86_64 1.5.0.0-28.fc11 java-1.6.0-openjdk.x86_64 1:1.6.0.0-22.b16.fc11 java-1.6.0-openjdk-plugin.x86_64 1:1.6.0.0-22.b16.fc11 firefox.x86_64 3.5-1.fc11 [1] Running firefox from the terminal produces: JNLPAppletLauncher: static initializer os.name = linux nativePrefix = lib nativeSuffix = .so tmpRootDir = /tmp/jnlp-applet/jln4687162377651411657 Applet.init subapplet.classname = ACIDVisionViewer.ObjViewer subapplet.displayname = ACID Vision Viewer Applet.start os.name = linux os.arch = amd64 processNativeJar: using previously cached: /home/mbooth/.jnlp-applet/cache/3dsee_net/7a0e806f70cba53e5de753282fb8bea46fe32ffa/lib_j3dcore-ogl_so.jar validateCertificates: VALIDATE: libj3dcore-ogl.so extractNativeLibs: EXTRACT: libj3dcore-ogl.so(j3dcore-ogl) JNLPAppletLauncher.loadLibrary("j3dcore-ogl") loading: /tmp/jnlp-applet/jln4687162377651411657/jln7242786902609691381/libj3dcore-ogl.so JNLPAppletLauncher: static initializer os.name = linux nativePrefix = lib nativeSuffix = .so tmpRootDir = /tmp/jnlp-applet/jln4687162377651411657 Applet.init subapplet.classname = ACIDVisionViewer.ObjViewer subapplet.displayname = ACID Vision Viewer Applet.start os.name = linux os.arch = amd64 /usr/lib64/firefox-3.5/run-mozilla.sh: line 131: 3605 Segmentation fault "$prog" ${1+"$@"} -- 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 jarod at redhat.com Thu Jul 9 21:15:47 2009 From: jarod at redhat.com (Jarod Wilson) Date: Thu, 9 Jul 2009 17:15:47 -0400 Subject: Possible packages... In-Reply-To: <4A565AF5.1050006@gnat.ca> References: <200907091631.59269.jarod@redhat.com> <4A565AF5.1050006@gnat.ca> Message-ID: <200907091715.48217.jarod@redhat.com> On Thursday 09 July 2009 17:02:45 Nathanael D. Noblet wrote: > On 07/09/2009 02:31 PM, Jarod Wilson wrote: > > On Monday 06 July 2009 10:49:31 Eric Sandeen wrote: > >> Nathanael Noblet wrote: > >>> On Jul 5, 2009, at 9:33 PM, Eric Sandeen wrote: > > .. > >>> Well their python run script checks for its dependancies, and if not > >>> met will do a svn checkout of the right copy, however, they don't keep > >>> copies of the libraries within their own repository. So if you fulfill > >>> all its dependancies that shouldn't be an issue. > >> Ah, ok - maybe that was it. > > > > Currently, it looks like it still requires its own builds of a few > > things. > > > > Stuff (apparently) not in Fedora: > > -pydirector > > Yeah I don't think this is in fedora > > > -PyKerberos (might just be named something slightly different) > > I thought this was I could be wrong though. Ah, python-kerberos seems to be it: Name : python-kerberos Arch : x86_64 Version : 1.1 Release : 4.1.fc11 Size : 23 k Repo : fedora Summary : A high-level wrapper for Kerberos (GSSAPI) operations URL : http://trac.calendarserver.org/projects/calendarserver/browser/PyKerberos License : ASL 2.0 ... Didn't look hard enough then. Good. (Why must our python bits so haphazardly mismatch upstream's name? PyKerberos would have been a perfectly acceptable package name too...) > > Stuff in Fedora, but simply not used for whatever reason: > > -vobject (we have python-vobject) > > -pyflakes > > I thought they were used if found... I'd have to look at the run file to > see if they ignore the system versions.. They weren't here. Had 'em already installed, and the run script still insisted on downloading private copies. > > Stuff in Fedora, but still heavily patched for CalendarServer: > > -Twisted (the web2 portion, specifically) > > -xattr ("requires Bob Ippolito's implementation") > > I've got it using the fedora version of xattr I think, I tried that first, it explicitly blows up when trying to start the server, and says something about using the wrong version of xattr. > and didn't notice the patches to Twisted... Its not as bad as I first thought, but: $ ls CalendarServer-trunk/lib-patches/Twisted/ twisted.application.app.patch twisted.web2.dav.method.report.patch twisted.mail.imap4.patch twisted.web2.dav.resource.patch twisted.python.util.patch twisted.web2.error.patch twisted.web2.auth.digest.patch twisted.web2.server.patch -- Jarod Wilson jarod at redhat.com From jarod at redhat.com Thu Jul 9 21:22:20 2009 From: jarod at redhat.com (Jarod Wilson) Date: Thu, 9 Jul 2009 17:22:20 -0400 Subject: Possible packages... In-Reply-To: <200907091715.48217.jarod@redhat.com> References: <4A565AF5.1050006@gnat.ca> <200907091715.48217.jarod@redhat.com> Message-ID: <200907091722.20449.jarod@redhat.com> On Thursday 09 July 2009 17:15:47 Jarod Wilson wrote: > > > Stuff in Fedora, but simply not used for whatever reason: > > > -vobject (we have python-vobject) > > > -pyflakes > > > > I thought they were used if found... I'd have to look at the run file to > > see if they ignore the system versions.. > > They weren't here. Had 'em already installed, and the run script still > insisted on downloading private copies. There are two patches they have for vobject, so that might explain why a local copy of that is still being used. No clue on pyflakes though. (also, Fedora's python-kerberos, aka PyKerberos, does indeed work) -- Jarod Wilson jarod at redhat.com From fedora at matbooth.co.uk Thu Jul 9 21:29:39 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Thu, 9 Jul 2009 22:29:39 +0100 Subject: 3Dsee.net java applet crashes firefox In-Reply-To: <9497e9990907091415m41fa3256m3c10f1d15df7f188@mail.gmail.com> References: <9497e9990907091415m41fa3256m3c10f1d15df7f188@mail.gmail.com> Message-ID: <9497e9990907091429h6283e62cmf06be94b162e3c86@mail.gmail.com> On Thu, Jul 9, 2009 at 10:15 PM, Mat Booth wrote: > I get an intermittant segfault in Firefox [1] when viewing the items > in the gallery over at http://3dsee.net/Gallery (once even trashing > the display and locking the machine up solid). > > Should I report this against Firefox or Java? > > I have the following installed: > > java-1.5.0-gcj.x86_64 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1.5.0.0-28.fc11 > java-1.6.0-openjdk.x86_64 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1:1.6.0.0-22.b16.fc11 > java-1.6.0-openjdk-plugin.x86_64 ? ? ? ? ? ? ? ? ? ? ? ? ?1:1.6.0.0-22.b16.fc11 > firefox.x86_64 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?3.5-1.fc11 > > > [1] Running firefox from the terminal produces: > > JNLPAppletLauncher: static initializer > os.name = linux > nativePrefix = lib ?nativeSuffix = .so > tmpRootDir = /tmp/jnlp-applet/jln4687162377651411657 > Applet.init > subapplet.classname = ACIDVisionViewer.ObjViewer > subapplet.displayname = ACID Vision Viewer > Applet.start > os.name = linux > os.arch = amd64 > processNativeJar: using previously cached: > /home/mbooth/.jnlp-applet/cache/3dsee_net/7a0e806f70cba53e5de753282fb8bea46fe32ffa/lib_j3dcore-ogl_so.jar > validateCertificates: > VALIDATE: libj3dcore-ogl.so > extractNativeLibs: > EXTRACT: libj3dcore-ogl.so(j3dcore-ogl) > JNLPAppletLauncher.loadLibrary("j3dcore-ogl") > ? ?loading: /tmp/jnlp-applet/jln4687162377651411657/jln7242786902609691381/libj3dcore-ogl.so > JNLPAppletLauncher: static initializer > os.name = linux > nativePrefix = lib ?nativeSuffix = .so > tmpRootDir = /tmp/jnlp-applet/jln4687162377651411657 > Applet.init > subapplet.classname = ACIDVisionViewer.ObjViewer > subapplet.displayname = ACID Vision Viewer > Applet.start > os.name = linux > os.arch = amd64 > /usr/lib64/firefox-3.5/run-mozilla.sh: line 131: ?3605 Segmentation > fault ? ? ?"$prog" ${1+"$@"} > > This screenshot is quite good, not had a good crash like this in ages: http://mbooth.fedorapeople.org/3dsee.png Though after a little thought, it could be the proprietary nvidia driver I'm using. I'll hold off reporting a bug until I try it with a different driver. -- 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 caolanm at redhat.com Thu Jul 9 22:23:32 2009 From: caolanm at redhat.com (=?ISO-8859-1?Q?Caol=E1n?= McNamara) Date: Thu, 09 Jul 2009 23:23:32 +0100 Subject: prelink: is it worth it? In-Reply-To: <20090709150654.GS4462@tyan-ft48-01.lab.bos.redhat.com> References: <20090709143201.GA22885@jadzia.bu.edu> <20090709150654.GS4462@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <1247178212.2804.17.camel@Vain> On Thu, 2009-07-09 at 17:06 +0200, Jakub Jelinek wrote: > LD_DEBUG=statistics /usr/lib64/openoffice.org3/program/swriter.bin > 11799: > 11799: runtime linker statistics: > 11799: total startup time in dynamic loader: 18632372 clock cycles > 11799: time needed for relocation: 2975643 clock cycles (15.9%) > 11799: number of relocations: 0 > 11799: number of relocations from cache: 1527 > 11799: number of relative relocations: 0 > 11799: time needed to load objects: 13190177 clock cycles (70.7%) > LD_USE_LOAD_BIAS=0 LD_DEBUG=statistics /usr/lib64/openoffice.org3/program/swriter.bin > 11817: > 11817: runtime linker statistics: > 11817: total startup time in dynamic loader: 145813250 clock cycles > 11817: time needed for relocation: 129375884 clock cycles (88.7%) > 11817: number of relocations: 42207 > 11817: number of relocations from cache: 126013 > 11817: number of relative relocations: 149959 > 11817: time needed to load objects: 15248893 clock cycles (10.4%) > The former is how long it takes before swriter.bin starts up when prelinked, > the latter tells it not to use prelink information and do normal relocation. Indeed, and Fedora OOo has a "prelink-friendly" set of launchers that explicitly link against the dsos that OOo will definitely dlopen on the various appropriate launch paths, and it's reassuring to see smaller numbers spat out at the end, but do we have actual numbers that measure the real-world difference it makes, or even a reliable mechanism that can be used to reproducibly and consistently measure the real-world difference that *any* given change makes. e.g. I've been totally unable to consistently measure a difference between compiling OOo with -fstrict-aliasing and the current -fno-strict-aliasing. And any other number of other proposed optimizations are massively difficult to measure reliably. C. From drago01 at gmail.com Thu Jul 9 22:51:12 2009 From: drago01 at gmail.com (drago01) Date: Fri, 10 Jul 2009 00:51:12 +0200 Subject: 3Dsee.net java applet crashes firefox In-Reply-To: <9497e9990907091429h6283e62cmf06be94b162e3c86@mail.gmail.com> References: <9497e9990907091415m41fa3256m3c10f1d15df7f188@mail.gmail.com> <9497e9990907091429h6283e62cmf06be94b162e3c86@mail.gmail.com> Message-ID: On Thu, Jul 9, 2009 at 11:29 PM, Mat Booth wrote: > On Thu, Jul 9, 2009 at 10:15 PM, Mat Booth wrote: >> I get an intermittant segfault in Firefox [1] when viewing the items >> in the gallery over at http://3dsee.net/Gallery (once even trashing >> the display and locking the machine up solid). >> >> Should I report this against Firefox or Java? >> >> I have the following installed: >> >> java-1.5.0-gcj.x86_64 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1.5.0.0-28.fc11 >> java-1.6.0-openjdk.x86_64 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1:1.6.0.0-22.b16.fc11 >> java-1.6.0-openjdk-plugin.x86_64 ? ? ? ? ? ? ? ? ? ? ? ? ?1:1.6.0.0-22.b16.fc11 >> firefox.x86_64 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?3.5-1.fc11 >> >> >> [1] Running firefox from the terminal produces: >> >> JNLPAppletLauncher: static initializer >> os.name = linux >> nativePrefix = lib ?nativeSuffix = .so >> tmpRootDir = /tmp/jnlp-applet/jln4687162377651411657 >> Applet.init >> subapplet.classname = ACIDVisionViewer.ObjViewer >> subapplet.displayname = ACID Vision Viewer >> Applet.start >> os.name = linux >> os.arch = amd64 >> processNativeJar: using previously cached: >> /home/mbooth/.jnlp-applet/cache/3dsee_net/7a0e806f70cba53e5de753282fb8bea46fe32ffa/lib_j3dcore-ogl_so.jar >> validateCertificates: >> VALIDATE: libj3dcore-ogl.so >> extractNativeLibs: >> EXTRACT: libj3dcore-ogl.so(j3dcore-ogl) >> JNLPAppletLauncher.loadLibrary("j3dcore-ogl") >> ? ?loading: /tmp/jnlp-applet/jln4687162377651411657/jln7242786902609691381/libj3dcore-ogl.so >> JNLPAppletLauncher: static initializer >> os.name = linux >> nativePrefix = lib ?nativeSuffix = .so >> tmpRootDir = /tmp/jnlp-applet/jln4687162377651411657 >> Applet.init >> subapplet.classname = ACIDVisionViewer.ObjViewer >> subapplet.displayname = ACID Vision Viewer >> Applet.start >> os.name = linux >> os.arch = amd64 >> /usr/lib64/firefox-3.5/run-mozilla.sh: line 131: ?3605 Segmentation >> fault ? ? ?"$prog" ${1+"$@"} >> >> > > This screenshot is quite good, not had a good crash like this in ages: > > http://mbooth.fedorapeople.org/3dsee.png > > Though after a little thought, it could be the proprietary nvidia > driver I'm using. I'll hold off reporting a bug until I try it with a > different driver. Works fine here. From jonstanley at gmail.com Fri Jul 10 00:03:41 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 9 Jul 2009 20:03:41 -0400 Subject: Plan for tomorrow's (20090710) FESCo meeting Message-ID: Following are the topics to be discussed at tomorrow's FESCo meeting at 17:00UTC in #fedora-meeting on freenode: 178 Application for provenpackager - whot 171 Critical Path Package Proposal 175 Exception to link against bundled copy of crypsetup in volume_key 177 Are the Adobe CMap files in ghostscript & poppler-data code or content? 179 Anaconda FCoE - https://fedoraproject.org/wiki/Anaconda/Features/FCoE 182 KDE 4.3 - https://fedoraproject.org/wiki/Features/KDE43 184 VirtGPXE - https://fedoraproject.org/wiki/Features/VirtgPXE 186 Yum langpack plugin - https://fedoraproject.org/wiki/Features/YumLangpackPlugin 66 MinimalPlatform - http://fedoraproject.org/wiki/Features/MinimalPlatform 174 NetworkManager Mobile Broadband F12 - https://fedoraproject.org/wiki/Features/MoreNetworkManagerMobileBroadband 180 Extended Lifecycle - https://fedoraproject.org/wiki/Features/Extended_Life_Cycle 181 FedoraMoblin - https://fedoraproject.org/wiki/Features/FedoraMoblin 183 Open Sharedroot - https://fedoraproject.org/wiki/Features/Opensharedroot 185 XI2 - https://fedoraproject.org/wiki/Features/XI2 187 virtio Serial - https://fedoraproject.org/wiki/VirtioSerial 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 dchen at redhat.com Fri Jul 10 01:38:59 2009 From: dchen at redhat.com (Ding-Yi Chen) Date: Fri, 10 Jul 2009 11:38:59 +1000 Subject: Man pages need love from native speakers! Message-ID: <1247189939.5536.14.camel@dhcp-0-207.bne.redhat.com> Currently I maintain man-pages-es, man-pages-it, and man-pages-ko. In terms of package maintenance, they are easy and requires low maintenance effort. These packages are also good for a novice packager to get use to the rpm spec. But since I speak none of them, it is better for them to be handled in better hands (and tongues). So, who wants them? -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ From peter at thecodergeek.com Fri Jul 10 03:26:44 2009 From: peter at thecodergeek.com (Peter Gordon) Date: Thu, 09 Jul 2009 20:26:44 -0700 Subject: Man pages need love from native speakers! In-Reply-To: <1247189939.5536.14.camel@dhcp-0-207.bne.redhat.com> References: <1247189939.5536.14.camel@dhcp-0-207.bne.redhat.com> Message-ID: <1247196404.11173.0.camel@tuxhugs> On Fri, 2009-07-10 at 11:38 +1000, Ding-Yi Chen wrote: > Currently I maintain man-pages-es, man-pages-it, and man-pages-ko. I could help with the -es manpages, as I also speak Spanish fluently. :) -- Peter Gordon (codergeek42) Who am I? :: http://thecodergeek.com/about-me -------------- next part -------------- A 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 pmatilai at laiskiainen.org Fri Jul 10 05:48:02 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 10 Jul 2009 08:48:02 +0300 (EEST) Subject: Conditionally applying a patch based on a program's EVR In-Reply-To: References: Message-ID: On Thu, 9 Jul 2009, Alan Dunn wrote: > I want to conditionally apply a patch in a spec file based upon the > version of a package. (There's an emacs package that needs a patch to > work with the latest version of xemacs, but this patch shouldn't be > applied for previous versions of xemacs.) I know that for checking > something like Fedora version numbers I can use > > %if 0%{?fedora} > 9 > ... > %endif > > but is there an easy way to do this for a version number in say, EVR > form? That is, something like > > %if %{program_version} > 1.2.3 > ... > %endif > > (%{program_version} will always be defined) > > RPM doesn't seem to support a mechanism like this in %if conditionals > (I believe having a digit first causes rpmbuild to try and interpret > the result as a number), though clearly there is a mechanism for > examining EVRs of this form for other parts of rpmbuild. > > One could try something like > > %if "%{prorgram_version}" > "1.2.3" > > which does string comparison, but this doesn't work for some version > combinations, since, for example, we would want 1.10.1 > 1.9.1 In rpm >= 4.7.0 the real rpm version comparison algorithm is available to the embedded Lua interpreter as rpm.vercmp(), eg: [pmatilai at localhost ~]$ rpm --eval "%{lua:print(rpm.vercmp('1.2.3-1', '1.1.1-1'))}" 1 [pmatilai at localhost ~]$ rpm --eval "%{lua:print(rpm.vercmp('1.2.3-1', '5:1.1.1-1'))}" -1 With older rpm versions you need to do "something else", such as call rpmdev-vercmp. - Panu - From rmy at tigress.co.uk Fri Jul 10 08:08:49 2009 From: rmy at tigress.co.uk (Ron Yorston) Date: Fri, 10 Jul 2009 09:08:49 +0100 Subject: prelink: is it worth it? In-Reply-To: <20090709151728.GU4462@tyan-ft48-01.lab.bos.redhat.com> References: <20090709143201.GA22885@jadzia.bu.edu> <4A5604EA.9090107@redhat.com> <20090709150820.GA26398@jadzia.bu.edu> <20090709151728.GU4462@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <200907100808.n6A88nlr021446@tiffany.internal.tigress.co.uk> Jakub Jelinek wrote: >Also, while prelink process has been fairly expensive some years ago, it is >much faster these days; if you haven't installed any rpms in the last day, >most of the days the cron job will just quit, if you have installed some, >for libraries/binaries that don't need reprelinking it will just do a quick >stat and nothing else, and even a full prelink takes just a minute or two. So what got faster, prelink or hardware? My experience, some years ago, was that a full prelink took 35-40 minutes. Since I didn't see any visible difference in performance I added "turn off prelink" to my list of things to do after installing Fedore. Ron From jakub at redhat.com Fri Jul 10 08:14:46 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 10 Jul 2009 10:14:46 +0200 Subject: prelink: is it worth it? In-Reply-To: <200907100808.n6A88nlr021446@tiffany.internal.tigress.co.uk> References: <20090709143201.GA22885@jadzia.bu.edu> <4A5604EA.9090107@redhat.com> <20090709150820.GA26398@jadzia.bu.edu> <20090709151728.GU4462@tyan-ft48-01.lab.bos.redhat.com> <200907100808.n6A88nlr021446@tiffany.internal.tigress.co.uk> Message-ID: <20090710081446.GX4462@tyan-ft48-01.lab.bos.redhat.com> On Fri, Jul 10, 2009 at 09:08:49AM +0100, Ron Yorston wrote: > Jakub Jelinek wrote: > >Also, while prelink process has been fairly expensive some years ago, it is > >much faster these days; if you haven't installed any rpms in the last day, > >most of the days the cron job will just quit, if you have installed some, > >for libraries/binaries that don't need reprelinking it will just do a quick > >stat and nothing else, and even a full prelink takes just a minute or two. > > So what got faster, prelink or hardware? > > My experience, some years ago, was that a full prelink took 35-40 minutes. > Since I didn't see any visible difference in performance I added "turn off > prelink" to my list of things to do after installing Fedore. Both. prelink's C++ optimizations used to be quite time consuming, that has been fixed, also there were changes to avoid reading all libraries and binaries, even when those haven't changed since last prelinking and don't need prelinking even now. Jakub From jmoskovc at redhat.com Fri Jul 10 09:18:53 2009 From: jmoskovc at redhat.com (Jiri Moskovcak) Date: Fri, 10 Jul 2009 11:18:53 +0200 Subject: non-blocking dbus server Message-ID: <4A57077D.2020604@redhat.com> Hi, in our project ABRT we use DBUS for communication between ABRT daemon and client (gui), the problem is that when I ask daemon to do some time-consuming work the server is blocked until the work is done. So I want to use threads and that's where I found the catch. Here is my idea: 1. client calls remote method foo() over dbus 2. daemon receives the call, creates the thread and let it do the work in background and serve other requests 3. when the work is finished send reply to the client - this is the part where I'm stuck, because I want to send the reply as return message to the matching method call, but the method call already returned when I started the thread. (So far I can achieve this by sending signal with return value as an argument, but I don't think this is a good solution). I use dbus-c++, so maybe the answer is in some low-level DBUS API. Thanks for any help, Jirka -------------- next part -------------- A non-text attachment was scrubbed... Name: jmoskovc.vcf Type: text/x-vcard Size: 126 bytes Desc: not available URL: From mschwendt at gmail.com Fri Jul 10 09:28:34 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 10 Jul 2009 11:28:34 +0200 Subject: poll(), gdb, threads, alsa-lib, deadlock In-Reply-To: <20090708114903.GB16449@mokona.greysector.net> References: <20090708110021.12ee5076@noname.noname> <20090708102854.GA16449@mokona.greysector.net> <20090708131656.73fe05a8@faldor> <20090708114903.GB16449@mokona.greysector.net> Message-ID: <20090710112834.6469ea56@faldor> On Wed, 8 Jul 2009 13:49:04 +0200, Dominik wrote: > AFAIR I got the problem right from the beginning of using F10, but I installed > it about a month or two after it came out and updated immediately after > installation. Here's somebody who gets "audacious, totem, mplayer etc." to lock up with PulseAudio and snd-intel8x0: https://bugzilla.redhat.com/496608 The backtrace shows multiple threads in poll(). Different hardware driver than me (ens1371). Bugzilla is full of sound problems. [...] [Unrelated to the problem, but strange nevertheless: PulseAudio's pa_rtpoll_run calculates a timeout of 0xb3eb31d0 ms. That's very large (over 800 hours), negative in 32-bit, and hence infinite for ppoll().] From paul at all-the-johnsons.co.uk Fri Jul 10 10:08:50 2009 From: paul at all-the-johnsons.co.uk (Paul) Date: Fri, 10 Jul 2009 11:08:50 +0100 Subject: Oh to have USB/CD write and sound... Message-ID: <1247220530.6521.20.camel@localhost.localdomain> Hi, As you're all aware on here, I've been using Rawhide for many many many moons now, I accept the risks, I accept the bleeding edge and that my fingers may get burned from time to time. However, it's been quite a while now (I think it broke shortly after the rawhide repos opened post the release of f11) since I can plug in a USB drive and have it mount without having to open a terminal window, su and mount it by hand. I can no longer use my DVD writer as I don't have the correct user permissions and the only way to get sound is to again su, change the ownership of /dev/snd to be me and restart pulseaudio. The above are really just annoyances that I can deal with. However, I now find that I can't open a terminal window (makes no difference to program used - happens with xterm, gnome-terminal and the kde one) without being told that "there was an error creating the child process for this terminal". OK, xterm just sits there, but I'm guessing it's suffering from the same problem. Any ideas when normality will be returned? TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From guido.grazioli at gmail.com Fri Jul 10 10:15:25 2009 From: guido.grazioli at gmail.com (Guido Grazioli) Date: Fri, 10 Jul 2009 12:15:25 +0200 Subject: Man pages need love from native speakers! In-Reply-To: <1247189939.5536.14.camel@dhcp-0-207.bne.redhat.com> References: <1247189939.5536.14.camel@dhcp-0-207.bne.redhat.com> Message-ID: <2f984ea00907100315w96e05bcl25706454c4862889@mail.gmail.com> Hello, i'd be glad to help you with the -it package Guido 2009/7/10 Ding-Yi Chen > Currently I maintain man-pages-es, man-pages-it, and man-pages-ko. > > In terms of package maintenance, they are easy and requires low > maintenance effort. These packages are also good for a novice packager > to get use to the rpm spec. > > But since I speak none of them, it is better for them to be handled in > better hands (and tongues). So, who wants them? > > > -- > Ding-Yi Chen > Software Engineer > Internationalization Group > Red Hat, Inc. > > Looking to carve out IT costs? > www.apac.redhat.com/promo/carveoutcosts/ > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschwendt at gmail.com Fri Jul 10 10:23:52 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 10 Jul 2009 12:23:52 +0200 Subject: noarch subpackages In-Reply-To: References: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> <20090708170639.21f9b4bf@faldor> <9514c41a0ff9d6e5be9b2ad6f16331d6.squirrel@intranet.cs.nmsu.edu> Message-ID: <20090710122352.3d353e54@faldor> On Thu, 9 Jul 2009 10:10:09 +0200, yersinia wrote: > > > %if 0%{?fedora} > 9 > > > BuildArch: noarch > > > %endif > > > > > > > Excellent. That's what I was looking for. > > > > No, it is not right for me. The BuildArch issue depends on the RPM version > and not from from distro version. It is simply bad style, IMHO, defining > in the SPEC file something that depends from the "distribution" (in the > large sense not only fedora). I never see > this style in RHEL package (appart some little package for the rpm keys > ecc). Ok is SUSE yes but, again, i don't like define a dependency based on > a "distro" version, if possible anyway. First of all, the original question was about "non-Fedora and older distributions (pre F10)". Above conditional does its job and enables a noarch sub-pkg only for Fedora > 9. "0%{?rhel} > 5" may be more future-proof, okay, but isn't true yet for any existing build-target. Also, as far as I know, %rhel and %dist are specific to koji/Plague EPEL builds, as stock RHEL and CentOS don't ship those macros. One needs the buildsys-macros package. In case I'm mistaken, and I don't have the time to verify that, what package defines those macros for RHEL? Finally, I don't agree with parts of the complaints. Either rpmbuild predefines a variables one can evaluate to check for a certain feature, or it doesn't. If it doesn't, I don't consider it "bad style" to eval %fedora/%rhel and make explicit what a conditional is trying to achieve. Even for a feature like this, that's better than hiding the details in a macro. Btw, we're miles away from clean multi-dist spec files, not only due to different package names. My experience with multi-dist spec files is that very often the packager loses overview due to overuse of conditionals and the added difficult of keeping changes in all conditional spec sections in sync with eachother. From pbrobinson at gmail.com Fri Jul 10 10:28:25 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 10 Jul 2009 11:28:25 +0100 Subject: F11 updates? Message-ID: <5256d0b0907100328q55e6601eh437fdacd73d53108@mail.gmail.com> Hi All, Is there an issue with F11 updates, I don't remember seeing anything on the list about it but AFAICT it seems there's not been an updates push for around 2 weeks. Peter From john5342 at googlemail.com Fri Jul 10 10:34:37 2009 From: john5342 at googlemail.com (John5342) Date: Fri, 10 Jul 2009 11:34:37 +0100 Subject: F11 updates? In-Reply-To: <5256d0b0907100328q55e6601eh437fdacd73d53108@mail.gmail.com> References: <5256d0b0907100328q55e6601eh437fdacd73d53108@mail.gmail.com> Message-ID: <6dc6523c0907100334n41ac518ar805d0d42f4bef990@mail.gmail.com> 2009/7/10 Peter Robinson : > Hi All, > > Is there an issue with F11 updates, I don't remember seeing anything > on the list about it but AFAICT it seems there's not been an updates > push for around 2 weeks. Last updates i saw where 3rd and 4th July which is a while ago but hardly 2 weeks. Other than that i would say they might be a little slower due to the 4th July and related holidays. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... From fedora at leemhuis.info Fri Jul 10 10:40:29 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 10 Jul 2009 12:40:29 +0200 Subject: F11 updates? In-Reply-To: <5256d0b0907100328q55e6601eh437fdacd73d53108@mail.gmail.com> References: <5256d0b0907100328q55e6601eh437fdacd73d53108@mail.gmail.com> Message-ID: <4A571A9D.7090400@leemhuis.info> On 10.07.2009 12:28, Peter Robinson wrote: > Is there an issue with F11 updates, I don't remember seeing anything > on the list about it but AFAICT it seems there's not been an updates > push for around 2 weeks. You often can find a status on: http://identi.ca/jwboyer @jwb: thx for that service btw CU knurd From pbrobinson at gmail.com Fri Jul 10 10:41:03 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 10 Jul 2009 11:41:03 +0100 Subject: F11 updates? In-Reply-To: <6dc6523c0907100334n41ac518ar805d0d42f4bef990@mail.gmail.com> References: <5256d0b0907100328q55e6601eh437fdacd73d53108@mail.gmail.com> <6dc6523c0907100334n41ac518ar805d0d42f4bef990@mail.gmail.com> Message-ID: <5256d0b0907100341v1c6c8ba5o42deaca427f28fa9@mail.gmail.com> >> Hi All, >> >> Is there an issue with F11 updates, I don't remember seeing anything >> on the list about it but AFAICT it seems there's not been an updates >> push for around 2 weeks. > > Last updates i saw where 3rd and 4th July which is a while ago but > hardly 2 weeks. Other than that i would say they might be a little > slower due to the 4th July and related holidays. OK. Maybe it just seems like 2 weeks :-) I have update pushes that are over a week old so its just a query. Peter From pbrobinson at gmail.com Fri Jul 10 10:42:01 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 10 Jul 2009 11:42:01 +0100 Subject: F11 updates? In-Reply-To: <4A571A9D.7090400@leemhuis.info> References: <5256d0b0907100328q55e6601eh437fdacd73d53108@mail.gmail.com> <4A571A9D.7090400@leemhuis.info> Message-ID: <5256d0b0907100342v3d24a9f4ycb0950537df43f5@mail.gmail.com> >> Is there an issue with F11 updates, I don't remember seeing anything >> on the list about it but AFAICT it seems there's not been an updates >> push for around 2 weeks. > > You often can find a status on: > http://identi.ca/jwboyer > > @jwb: thx for that service btw How useful, thanks :-) Peter From fedora at matbooth.co.uk Fri Jul 10 13:23:17 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Fri, 10 Jul 2009 14:23:17 +0100 Subject: non-blocking dbus server In-Reply-To: <4A57077D.2020604@redhat.com> References: <4A57077D.2020604@redhat.com> Message-ID: <9497e9990907100623k2ae94b2amff64d821273024e0@mail.gmail.com> On Fri, Jul 10, 2009 at 10:18 AM, Jiri Moskovcak wrote: > Hi, > in our project ABRT we use DBUS for communication between ABRT daemon and > client (gui), the problem is that when I ask daemon to do some > time-consuming work the server is blocked until the work is done. So I want > to use threads and that's where I found the catch. > > Here is my idea: > 1. client calls remote method foo() over dbus > 2. daemon receives the call, creates the thread and let it do the work in > background and serve other requests > 3. when the work is finished send reply to the client > - this is the part where I'm stuck, because I want to send the reply as > return message to the matching method call, but the method call already > returned when I started the thread. (So far I can achieve this by sending > signal with return value as an argument, but I don't think this is a good > solution). > > I use dbus-c++, so maybe the answer is in some low-level DBUS API. > > Thanks for any help, > Jirka > Why can't you have a callback in the client that the daemon can call when it has finished? -- 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 jgranado at redhat.com Fri Jul 10 13:27:06 2009 From: jgranado at redhat.com (Joel Granados) Date: Fri, 10 Jul 2009 15:27:06 +0200 Subject: New parted release update. Message-ID: <20090710132706.GB3552@dhcp-lab-171.englab.brq.redhat.com> Hello list. I posted a mail some weeks ago about new parted version in fedora. As some of you might have noticed i have been to lazy to put it in :). But after a few adjustments and a little bit of actual work, I think I have gotten to a point where I am satisfied. Packages that might need rebuilding: # repoquery --repoid rawhide --whatrequires --alldeps parted DeviceKit-disks-0:005-2 nash-0:6.0.91-1 nash-0:6.0.91-1 ricci-0:0.16.1-1 qtparted-0:0.4.5-19 pyparted-0:2.0.12-1 libvirt-0:0.6.5-1 gparted-0:0.4.5-1 anaconda-0:12.1-1 Additional comments: 1. I bumped the soname (upstream will bump it as well) to libparted-1.9.so.0 2. The new parted is working in s390 as well. 3. There was a little API change that involved not including some header files. I'm pretty sure that those header files where not in fedora to begin with, so I don't expect any issues. 4. You can find the build in: http://koji.fedoraproject.org/koji/taskinfo?taskID=1465511 Feel free to scream at me if you see anything going wrong with the new version. Regards. -- Joel Andres Granados Brno, Czech Republic, Red Hat. From jmoskovc at redhat.com Fri Jul 10 13:33:05 2009 From: jmoskovc at redhat.com (Jiri Moskovcak) Date: Fri, 10 Jul 2009 15:33:05 +0200 Subject: non-blocking dbus server In-Reply-To: <9497e9990907100623k2ae94b2amff64d821273024e0@mail.gmail.com> References: <4A57077D.2020604@redhat.com> <9497e9990907100623k2ae94b2amff64d821273024e0@mail.gmail.com> Message-ID: <4A574311.3030205@redhat.com> On 07/10/2009 03:23 PM, Mat Booth wrote: > On Fri, Jul 10, 2009 at 10:18 AM, Jiri Moskovcak wrote: >> Hi, >> in our project ABRT we use DBUS for communication between ABRT daemon and >> client (gui), the problem is that when I ask daemon to do some >> time-consuming work the server is blocked until the work is done. So I want >> to use threads and that's where I found the catch. >> >> Here is my idea: >> 1. client calls remote method foo() over dbus >> 2. daemon receives the call, creates the thread and let it do the work in >> background and serve other requests >> 3. when the work is finished send reply to the client >> - this is the part where I'm stuck, because I want to send the reply as >> return message to the matching method call, but the method call already >> returned when I started the thread. (So far I can achieve this by sending >> signal with return value as an argument, but I don't think this is a good >> solution). >> >> I use dbus-c++, so maybe the answer is in some low-level DBUS API. >> >> Thanks for any help, >> Jirka >> > > Why can't you have a callback in the client that the daemon can call > when it has finished? > > What you suggest is non-blocking call on client-side. I want a non-blocking execution on the server-side, to be able to handle other requests. -------------- next part -------------- A non-text attachment was scrubbed... Name: jmoskovc.vcf Type: text/x-vcard Size: 126 bytes Desc: not available URL: From jarod at redhat.com Fri Jul 10 13:41:21 2009 From: jarod at redhat.com (Jarod Wilson) Date: Fri, 10 Jul 2009 09:41:21 -0400 Subject: Possible packages... In-Reply-To: <200907091722.20449.jarod@redhat.com> References: <200907091715.48217.jarod@redhat.com> <200907091722.20449.jarod@redhat.com> Message-ID: <200907100941.21433.jarod@redhat.com> On Thursday 09 July 2009 17:22:20 Jarod Wilson wrote: > On Thursday 09 July 2009 17:15:47 Jarod Wilson wrote: > > > > Stuff in Fedora, but simply not used for whatever reason: > > > > -vobject (we have python-vobject) > > > > -pyflakes > > > > > > I thought they were used if found... I'd have to look at the run file to > > > see if they ignore the system versions.. > > > > They weren't here. Had 'em already installed, and the run script still > > insisted on downloading private copies. > > There are two patches they have for vobject, so that might explain why > a local copy of that is still being used. No clue on pyflakes though. Neither pyflakes or vobject are wrapped with a "only checkout local copies if it doesn't already exist on the system" check. After adding checks, I've got it running using the system versions of these now too. There may be $something that doesn't work right w/o the patches to vobject though, dunno. -- Jarod Wilson jarod at redhat.com From nathanael at gnat.ca Fri Jul 10 15:24:20 2009 From: nathanael at gnat.ca (Nathanael Noblet) Date: Fri, 10 Jul 2009 09:24:20 -0600 Subject: Possible packages... In-Reply-To: <200907100941.21433.jarod@redhat.com> References: <200907091715.48217.jarod@redhat.com> <200907091722.20449.jarod@redhat.com> <200907100941.21433.jarod@redhat.com> Message-ID: <4951D730-F6F8-4274-8D92-9676756FDD13@gnat.ca> On Jul 10, 2009, at 7:41 AM, Jarod Wilson wrote: > On Thursday 09 July 2009 17:22:20 Jarod Wilson wrote: >> On Thursday 09 July 2009 17:15:47 Jarod Wilson wrote: >>>>> Stuff in Fedora, but simply not used for whatever reason: >>>>> -vobject (we have python-vobject) >>>>> -pyflakes >>>> >>>> I thought they were used if found... I'd have to look at the run >>>> file to >>>> see if they ignore the system versions.. >>> >>> They weren't here. Had 'em already installed, and the run script >>> still >>> insisted on downloading private copies. >> >> There are two patches they have for vobject, so that might explain >> why >> a local copy of that is still being used. No clue on pyflakes though. > > Neither pyflakes or vobject are wrapped with a "only checkout local > copies if it doesn't already exist on the system" check. After adding > checks, I've got it running using the system versions of these now > too. There may be $something that doesn't work right w/o the patches > to vobject though, dunno. > Yeah, I was planning on using their caldavtester to test. Find any regressions... I can't remember what package when not quite new enough caused some odd responses in the test suite, but most looked harmless (data came back correctly, but sometimes key/value pairs were in a different order from what the test was expecting, otherwise it was identical). I just got a bit busy so hadn't continued to investigate, however I figured this package would necessitate including updating some fedora packages, as well as seeing how if their local patches could be pushed upstream somehow. From mikeb at redhat.com Fri Jul 10 15:45:27 2009 From: mikeb at redhat.com (Mike Bonnet) Date: Fri, 10 Jul 2009 11:45:27 -0400 Subject: art of packaging: fluxbox-pulseaudio In-Reply-To: <20090708205505.769a5b0e@spica.a.lan> References: <20090708182216.GB4757@nb.net.home> <20090708204453.74654358@spica.a.lan> <1247079018.2969.19.camel@localhost.localdomain> <20090708205505.769a5b0e@spica.a.lan> Message-ID: <4A576217.4080302@redhat.com> On 07/08/2009 02:55 PM, Andreas Bierfert wrote: > On Wed, 08 Jul 2009 11:50:18 -0700 > Jesse Keating wrote: > >> On Wed, 2009-07-08 at 20:44 +0200, Andreas Bierfert wrote: >>> It is not only an empty file. It requires the necessary PA packages >>> and triggers >>> automatic PA loading on session starts. >>> >>> Please see [1] and [2] for some more background information. >> That subpackage should likely be noarch. >> > > Just been thinking the same. Will be fixed asap. While you're at it, could you convert that specfile (specifically the changelog) from iso8859-1 to utf-8? createrepo complains about non-ascii non-utf-8 encodings. Thanks, Mike From wdierkes at 5dollarwhitebox.org Fri Jul 10 15:50:36 2009 From: wdierkes at 5dollarwhitebox.org (BJ Dierkes) Date: Fri, 10 Jul 2009 10:50:36 -0500 Subject: Fail2ban + Shorewall Question Message-ID: <08257EB7-9DC9-402A-B749-FD0D4D91CBBE@5dollarwhitebox.org> Hello all, I originally posted this on the epel-devel-list, but was referred by the EPEL maintainer of fail2ban to bring the discussion upstream to Fedora in hopes of convincing the Fedora maintainer of fail2ban to make these changes. The following was my original message: --- I bring this to the list being that the issue isn't necessarily a bug, rather a concern about implementation. Per the documentation [http://www.fail2ban.org/wiki/index.php/MANUAL_0_8 ] fail2ban is _capable_ of supporting shorewall (among other things) and even states that "the following software is optional but recommended" with reference to shorewall. However, fail2ban does not _require_ shorewall to function. That said, having a 'Requires: shorewall' in the fail2ban spec seems unnecessary and in my opinion improper. Breaking the package out into a sub package doesn't seem necessary either... being that the only file(s) I see that could be split off would be: ]# rpm -ql fail2ban | grep shorewall /etc/fail2ban/action.d/shorewall.conf Regardless, for the sake of those that have no interest in shorewall (and in particular those that want to avoid having to support shorewall) I'd like to suggest that fail2ban-shorewall be broken off in a sub-package or simply drop the Requires: shorewall completely so that the dependency of shorewall is only enacted when desired (or not at all). Thoughts? Thank you for your time. --- derks -------------- next part -------------- An HTML attachment was scrubbed... URL: From mclasen at redhat.com Fri Jul 10 16:19:35 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 10 Jul 2009 12:19:35 -0400 Subject: Next Fit and Finish test day: Batteries and Suspend Message-ID: <1247242775.2004.10.camel@planemask> Time to announce the next 'fit and finish' test day. On July 21, we want to look at issues with the user experience around batteries, suspend and power management in general. https://fedoraproject.org/wiki/Test_Day:2009-07-21_Fit_and_Finish:Batteries_and_Suspend Please join us in #fedora-fit-and-finish. Matthias From walters at verbum.org Fri Jul 10 16:20:40 2009 From: walters at verbum.org (Colin Walters) Date: Fri, 10 Jul 2009 12:20:40 -0400 Subject: non-blocking dbus server In-Reply-To: <4A57077D.2020604@redhat.com> References: <4A57077D.2020604@redhat.com> Message-ID: On Fri, Jul 10, 2009 at 5:18 AM, Jiri Moskovcak wrote: > > 3. when the work is finished send reply to the client > - this is the part where I'm stuck, because I want to send the reply as > return message to the matching method call, but the method call already > returned when I started the thread. (So far I can achieve this by sending > signal with return value as an argument, but I don't think this is a good > solution). Your options are: 1) Method returns "work item id", send a signal WorkDone with the id 2) Agent pattern, the server makes calls back to the client using its unique name. 3) Infinite timeouts on method calls is in dbus git master From rvinyard at cs.nmsu.edu Fri Jul 10 17:35:28 2009 From: rvinyard at cs.nmsu.edu (Rick L Vinyard Jr) Date: Fri, 10 Jul 2009 11:35:28 -0600 Subject: noarch subpackages In-Reply-To: References: <306f2b854006be720e0e833c96983470.squirrel@intranet.cs.nmsu.edu> <20090708170639.21f9b4bf@faldor> <9514c41a0ff9d6e5be9b2ad6f16331d6.squirrel@intranet.cs.nmsu.edu> <4A561AAF.2010305@lfarkas.org> <1247158319.2589.22.camel@localhost.localdomain> <3763a78f3e725ef9b2af68a7d3d38113.squirrel@intranet.cs.nmsu.edu> Message-ID: <4A577BE0.6080704@cs.nmsu.edu> yersinia wrote: > > > On Thu, Jul 9, 2009 at 8:50 PM, Rick L. Vinyard, Jr. > > wrote: > > Jussi Lehtola wrote: > > On Thu, 2009-07-09 at 18:28 +0200, Farkas Levente wrote: > >> > Except it should be: > >> > %if 0%{?fedora} > 9 || 0%{?rhel} > 5 > >> > >> it'd be nice if _all_ packages which have noarch subpackage use > this > >> since most fedora packager reply to my such patches that they > don't care > >> about rhel/centos:-( > > > > This should really be a macro in rpm, as it has to be duplicated > in so > > many places. Say, %{_noarch_subpackage} which would expand to > > > > %if 0%{?fedora} > 9 || 0%{?rhel} > 5 > > BuildArch: noarch > > %endif > > Yes, it really should. Otherwise, some will look like: > > %if 0%{?fedora} > 9 > BuildArch: noarch > %endif > > and others like: > > %if 0%{?fedora} > 9 || 0%{?rhel} > 5 > BuildArch: noarch > %endif > > If you need further proof of the confusion simply look to this thread. > > Plus it is more expressive as to what the intent of the check is for, > allowing a smoother migration process if, in the future, a check > is put in > for the rpm version. > > > So you agreed that the check is on the rpm version, not "distro" version. I never said it wasn't. From rawhide at fedoraproject.org Fri Jul 10 18:32:33 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Fri, 10 Jul 2009 18:32:33 +0000 Subject: rawhide report: 20090710 changes Message-ID: <20090710183233.GA30960@releng2.fedora.phx.redhat.com> Compose started at Fri Jul 10 06:15:06 UTC 2009 New package armadillo Fast C++ matrix library with interfaces to LAPACK and ATLAS New package elfelli Visualisation tool for flux lines New package libqinfinity Qt interface for libinfinity New package perl-CGI-Application-Server Simple HTTP server for developing with CGI::Application New package perl-CGI-Application-Standard-Config Defines a standard configuration API for CGI::Application New package python-Scriptaculous TurboGears, Scriptaculous and Prototype New package rubygem-mkrf Making C extensions for Ruby a bit easier New package rubygem-ruby-opengl OpenGL Interface for Ruby New package zikula-module-crpTag Simple Zikula component for tagging items, based on hooks Updated Packages: NetworkManager-0.7.1-8.git20090708.fc12 --------------------------------------- * Thu Jul 09 2009 Dan Williams - 0.7.1-8.git20090708 - applet: fix certificate validation in hidden wifi networks dialog (rh #508207) anaconda-12.2-1.fc12 -------------------- * Thu Jul 09 2009 David Cantrell - 12.2-1 - mdmon added to install.img (Jacek.Danecki) - Remove some unnecessary code. (clumens) - Use a method yum provides, rather than inventing our own. (clumens) - Remove _catchallCategory. yum handles this for us now. (clumens) - Write out NM_CONTROLLED=no for NICs used for FCoE (hdegoede) - Add support for biosraid using mdadm (hdegoede) - Reverse: "Support for MD containers" (hdegoede) - When all udev_is-foo() checks fail return instead of backtracing (hdegoede) - 70-anaconda.rules: always import blkid output (hdegoede) - Make sure to have "self" as an argument. (clumens) - Add kickstart fcoe command (hdegoede) - Use the yum preconf object to do $releasever substitution. (clumens) - Indicate LV status according to lv_attr active bit (#491754) (dcantrell) - Include lv_attr in lvm.lvs() return value. (dcantrell) - Fix list of 64-bit arches. (notting) - We also need -DUSESELINUX if we want to call matchPathContext. (clumens) - Clean up some arch code. (notting) - Update /etc/hosts with hostname for loopback IP address (#506384) (rvykydal) - Add missing LAYER2 and PORTNO handling for s390x. (dcantrell) - Ignore configure.ac when generating updates.img (dcantrell) - AC_ARG_WITH -> AC_ARG_ENABLE (dcantrell) - dhclient now reads config files from /etc/dhcp (dcantrell) - no "rhgb quiet" on s390 to enable visible boot progress and system automation (#509881) (maier) - fix backtrace in s390 reipl support due to missing anaconda.id.fsset (#509877) (maier) - Put sleep in /bin on the initrd (#505639). (clumens) - Also include the grep programs. (clumens) - Add programs from vim-minimal, coreutils, and util-linux-ng. (clumens) - Move programs that aren't s390-specific into the main image. (clumens) - Look for /bin/sh, not /sbin/busybox. (clumens) - No longer symlink binaries to busybox. (clumens) - No longer require busybox. (clumens) ardour-2.8.1-1.fc12 ------------------- * Thu Jul 09 2009 Orcan Ogetbil 2.8.1-1 - New upstream release 2.8.1. bodhi-0.6.1-1.fc12 ------------------ * Thu Jul 09 2009 Luke Macken - 0.6.0-1 - 0.6.0 final * Thu Jul 09 2009 Luke Macken - 0.6.1-1 - 0.6.1 * Mon Jul 06 2009 Luke Macken - 0.6.0-0.5.beta - beta5, with EPEL mash configs * Mon Jul 06 2009 Luke Macken - 0.6.0-0.6.beta - beta6 * Mon Jul 06 2009 Luke Macken - 0.6.0-0.7.beta - beta7 * Fri Jul 03 2009 Luke Macken - 0.6.0-0.2.beta - beta2 - Make our Bugzilla cookie file configurable * Fri Jul 03 2009 Luke Macken - 0.6.0-0.3.beta - beta3 * Fri Jul 03 2009 Luke Macken - 0.6.0-0.4.beta - beta4 * Thu Jul 02 2009 Luke Macken - 0.6.0-0.1.beta - 0.6.0 beta control-center-2.27.3-2.fc12 ---------------------------- * Thu Jul 09 2009 Matthias Clasen - 2.27.3-2 - Improve theme rendering in the appearance capplet dhcp-4.1.0-24.fc12 ------------------ * Thu Jul 09 2009 David Cantrell - 12:4.1.0-23 - Upgrade to ldap-for-dhcp-4.1.0-4 * Thu Jul 09 2009 David Cantrell - 12:4.1.0-24 - Ensure 64-bit platforms parse lease file dates & times correctly (#448615) ekiga-3.2.5-2.fc12 ------------------ * Thu Jul 09 2009 Matthias Clasen - 3.2.5-2 - Shrink GConf schemas electronics-menu-1.0-4.fc12 --------------------------- * Wed Jul 08 2009 Chitlesh Goorah - 1.0-4 - patched for submenus - added extra icons and directory desktop files to support the submenus feature empathy-2.27.3-4.fc12 --------------------- * Thu Jul 09 2009 Matthias Clasen - 2.27.3-4 - Require telepathy-mission-control filesystem-2.4.23-1.fc12 ------------------------ * Thu Jul 09 2009 Ondrej Vasik - 2.4.23-1 - do own /usr/src/debug (#214983) ginac-1.5.1-2.fc12 ------------------ * Thu Jul 09 2009 Alex Lancaster - 1.5.1-2 - Rebuild to fix broken deps gsim85-0.2-5.fc12 ----------------- * Sun Jun 28 2009 Fabian Affolter - 0.2-5 - Fixed the place in the menu guiloader-c++-2.15.0-1.fc12 --------------------------- * Thu Jul 09 2009 Fabian Affolter - 2.15.0-1 - Removed Patch0 - Updated to new upstream version 2.15.0 hunspell-1.2.8-9.fc12 --------------------- * Thu Jul 09 2009 Caolan McNamara - 1.2.8-9 - Resolves: rhbz#510360 unowned dirs - fix up rpmlint warnings hunspell-sc-0.20081101-3.fc12 ----------------------------- * Thu Jul 09 2009 Caolan McNamara - 0.20081101-3 - drop unneeded buildrequires itext-2.1.7-1.fc12 ------------------ * Thu Jul 09 2009 Orcan Ogetbil 2.1.7-1 - New upstream release kernel-2.6.31-0.62.rc2.git4.fc12 -------------------------------- * Thu Jul 09 2009 Jarod Wilson - Enable IR receiver on the Hauppauge HD PVR - Trim the changelog, axing everything before 2.6.29 (see cvs if you still really want to see that far back) * Thu Jul 09 2009 Chuck Ebbert 2.6.31-0.61.rc2.git4 - 2.6.31-rc2-git4 * Thu Jul 09 2009 Dave Jones 2.6.31-0.62.rc2.git4 - Use correct spinlock initialization in dma-debug libccss-0.3.1-2.fc12 -------------------- * Thu Jul 09 2009 Peter Robinson 0.3.1-1 - New release - 0.3.1 * Thu Jul 09 2009 Peter Robinson 0.3.1-2 - Add new files to specs libgdl-2.27.3-1.fc12 -------------------- * Fri Jul 10 2009 Debarshi Ray - 2.26.2-1 - Version bump to 2.26.2. * Translation updates: ar, be, ca at valencia, el, jp and sk. * http://ftp.gnome.org/pub/GNOME/sources/gdl/2.26/gdl-2.26.2.news - Ensure that objects docked to a GdlDockPaned are shown. (GNOME Bugzilla * Fri Jul 10 2009 Debarshi Ray - 2.27.3-1 - Version bump to 2.27.3. * Fixed soname generation. * Private API hidden. * Fixed invisible buttons in HighContrastInverse theme. (GNOME Bugzilla * Removed GdlComboButton. Use GtkMenuToolButton instead. (GNOME Bugzilla * Optional grip handle hatching. (GNOME Bugzilla #577001) * Fixed layout bug in the grip widget headers. (GNOME Bugzilla #577107) * GNOME Goal: removed deprecated Gtk+ symbols. (GNOME Bugzilla #577469) * Implemented gdl_dock_item_grip_remove. (GNOME Bugzilla #578967) * gdl_dock_placeholder_new takes a const gchar*. (GNOME Bugzilla #577938) * Fixed grip layout bug where negative rectangles are possible. (GNOME Bugzilla #579057) * Get rid of libgnome. (GNOME Bugzilla #580860) * Ported to GtkBuilder. (GNOME Bugzilla #582511) * http://ftp.gnome.org/pub/GNOME/sources/gdl/2.27/gdl-2.27.3.news * http://ftp.gnome.org/pub/GNOME/sources/gdl/2.27/gdl-2.27.2.news - Fix to show objects docked to a GdlDockPaned accepted by upstream. - Replaced 'BuildRequires: libglade2-devel' with 'BuildRequires: gtk2-devel libxml2-devel'. libprelude-0.9.24-1.fc12 ------------------------ * Thu Jul 09 2009 Steve Grubb - 0.9.24-1 - New upstream release libsemanage-2.0.33-1.fc12 ------------------------- * Tue Jul 07 2009 Dan Walsh - 2.0.33-1 - Update to upstream libtirpc-0.2.0-3.fc12 --------------------- * Thu Jul 09 2009 Steve Dickson 0.2.0-3 - Updated to latest upstream tag: 0-2-1-rc3 Fixed the --disable-gss options Fixed a number of warnings Change how architectures are define in xdr_float.c libv4l-0.6.0-1.fc12 ------------------- * Thu Jul 09 2009 Hans de Goede 0.6.0-1 - New upstream release 0.6.0 - This fixes a divide by 0 crash in the whitebalancing code (#507748) libxklavier-4.0-3.fc12 ---------------------- * Thu Jul 09 2009 Matthias Clasen - 4.0-3 - Avoid a critical warning at runtime * Wed Jul 01 2009 Rex Dieter - 4.0-2 - %files: track files closer, esp lib sonames - %build: drop --disable-doxygen, add --disable-static, add %{?_smp_mflags} man-pages-es-1.55-9.fc12 ------------------------ * Fri Jul 10 2009 Ding-Yi Chen - 1.55-9 - Bug 510363 - Unowned directories in man-pages-es-1.55-7.fc11 mono-2.4.2.1-1.fc12 ------------------- * Thu Jul 09 2009 Paul F. Johnson 2.4.2.1-1 - Bump to 2.4.2.1 release - Add system.web.mvc mono-debugger-2.4.2.1-1.fc12 ---------------------------- * Thu Jul 09 2009 Paul F. Johnson 2.4.2.1-1 - Bump to 2.4.2.1 neon-0.28.5-1.fc12 ------------------ * Thu Jul 09 2009 Joe Orton 0.28.5-1 - update to 0.28.5 ntfsprogs-2.0.0-11.fc12 ----------------------- * Thu Jul 09 2009 Tom "spot" Callaway - 2.0.0-11 - Fix BuildRequires from e2fsprogs-devel to libuuid-devel octave-forge-20080831-9.fc12 ---------------------------- * Thu Jul 09 2009 Alex Lancaster - 20080831-9 - Rebuild for dependencies pdfposter-0.5.0-2.fc12 ---------------------- * Thu Jul 09 2009 Fabian Affolter - 0.5.0-2 - Replaced 'define' with 'global' pdftk-1.41-21.fc12 ------------------ * Thu Jul 09 2009 Orcan Ogetbil 1.41-21 - Build against itext-2.1.7 prelink-0.4.2-1.fc12 -------------------- * Thu Jul 09 2009 Jakub Jelinek 0.4.2-1 - don't look for *_IRELATIVE relocations in .gnu.conflict section in binaries prewikka-0.9.17-1.fc12 ---------------------- * Thu Jul 09 2009 Steve Grubb 0.9.17-1 - new upstream release pstoedit-3.45-8.fc12 -------------------- * Thu Jul 09 2009 Denis Leroy - 3.45-8 - Fix parallel build (#510281) - Remove ImageMagick support, to work around bug 507035 pykickstart-1.56-1.fc12 ----------------------- * Thu Jul 09 2009 Chris Lumens - 1.56-1 - Make sure to import the gettext stuff in fcoe. (clumens) - Correctly deprecate bootloader --lba32 (jlaska). - pykickstart: fix zfcp command writepriority (hdegoede) - pykickstart: Add fcoe command (take 2) (hdegoede) - Add a test case for RAID (jlaska). pymol-1.2-5.20090709svn3827.fc12 -------------------------------- * Tue Jul 07 2009 Tim Fenn - 1.2-5.20090709svn3827 - update to SVN 3827, 1.2r1 python-nss-0.6-2.fc12 --------------------- * Thu Jul 09 2009 John Dennis - 0.6-2 - restore nss.nssinit(), make deprecated * Wed Jul 08 2009 John Dennis - 0.6-1 - fix bug #510343 client_auth_data_callback seg faults if False is returned from callback ruby-gnome2-0.19.0-3.fc12 ------------------------- * Thu Jul 09 2009 Mamoru Tasaka - 0.19.0-3 - Make ruby-gtkglext require ruby(opengl) safecopy-1.3-1.fc12 ------------------- * Fri Jul 10 2009 Fabian Affolter - 1.3-1 - Updated to new upstream version 1.3 setroubleshoot-plugins-2.1.9-1.fc12 ----------------------------------- * Thu Jul 09 2009 - 2.1.9-1 - Add Scott Radvan. doc cleanup sudo-1.7.1-4.fc12 ----------------- * Thu Jul 09 2009 Daniel Kopecek 1.7.1-4 - moved the closefrom() call before audit_help_open() (sudo-1.7.1-auditfix.patch) - epoch number sync synce-hal-0.13.1-4.fc12 ----------------------- * Tue Jul 07 2009 Adam Jackson 0.13.1-4 - Fix Provides: of synce-serial. system-config-date-1.9.39-1.fc12 -------------------------------- * Thu Jul 09 2009 Nils Philippsen - 1.9.39-1 - use POOL_NTP_ORG_VENDOR in Makefile to set default NTP servers (#510309) * Thu Jun 04 2009 Nils Philippsen - don't BR: anaconda * Thu May 28 2009 Nils Philippsen - require libselinux-python - use simplified source URL tar-1.22-4.fc12 --------------- * Thu Jun 25 2009 Ondrej Vasik 2:1.22-4 - Report record size only if the archive refers to a device (#487760) - Do not sigabrt with new gcc/glibc because of writing to struct members of gnutar header at once via strcpy tvtime-1.0.2-11.fc12 -------------------- * Thu Jul 09 2009 Tomas Smetana 1.0.2-11 - fix a typo in the default config file ugene-1.5.0-3.fc12 ------------------ * Fri Jul 10 2009 Ivan Efremov - 1.5.0-3 - desktop-file-utils added to dependencies * Mon Jul 06 2009 Ivan Efremov - 1.5.0-1 - Upstream version change - Needed Qt versions bumped up - Fix for lrelease updated due to upstream package changes vino-2.26.1-5.fc12 ------------------ * Thu Jul 09 2009 Matthias Clasen - 2.26.1-5 - Rebuild to shrink GConf schemas wine-1.1.25-1.fc12 ------------------ * Thu Jul 09 2009 Andreas Bierfert - 1.1.25-1 - version upgrade (#509648) * Mon Jun 29 2009 Andreas Bierfert - 1.1.24-3 - pull in nss correctly on x86_64 xfce4-power-manager-0.8.2-1.fc12 -------------------------------- * Thu Jul 09 2009 Christoph Wickert - 0.8.2-1 - Update to 0.8.2 * Mon Jul 06 2009 Christoph Wickert - 0.8.1.1-1 - Update to 0.8.1.1 xfsprogs-3.0.1-9.fc12 --------------------- xorg-x11-drv-evdev-2.2.99-3.20090629.fc12 ----------------------------------------- * Thu Jul 09 2009 Adam Jackson 2.2.99-3.20090629 - Fix EVR inversion, 1.20090629 < 2.20090619 xorg-x11-drv-synaptics-1.1.99-2.20090710.fc12 --------------------------------------------- * Fri Jul 10 2009 Peter Hutterer 1.1.99-2-22090710 - Update to today's git master. xorg-x11-drv-vmmouse-12.6.4-2.fc12 ---------------------------------- * Thu Jul 09 2009 Adam Jackson 12.6.4-2 - Port to new server ABI (#509682) Summary: Added Packages: 9 Removed Packages: 0 Modified Packages: 54 Broken deps for i386 ---------------------------------------------------------- R-RScaLAPACK-0.5.1-19.fc11.i586 requires openmpi-libs 1:anjuta-2.26.1.0-1.fc12.i586 requires libgdl-1.so.0 bmpx-0.40.14-8.fc11.i386 requires libboost_iostreams-mt.so.4 bmpx-0.40.14-8.fc11.i386 requires libboost_regex-mt.so.4 clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.i586 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.i586 requires gauche = 0:0.8.13 gnome-python2-gdl-2.25.3-4.fc12.i586 requires libgdl-1.so.0 gtranslator-1.9.5-1.fc12.i586 requires libgdl-1.so.0 libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 orsa-0.7.0-8.fc11.i586 requires libcln.so.5 ppl-swiprolog-0.10.2-3.fc12.i586 requires libpl.so.5.7.6 pyclutter-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.i386 requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.i386 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.i586 requires libgeos-3.0.3.so rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.i586 requires libpqxx-2.6.8.so springlobby-0.0.1.10461-1.fc12.i586 requires libtorrent-rasterbar.so.3 thunderbird-lightning-1.0-0.5.20090513hg.fc12.i586 requires thunderbird >= 0:3.0-2.4.b3pre vtk-examples-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 Broken deps for x86_64 ---------------------------------------------------------- R-RScaLAPACK-0.5.1-19.fc11.x86_64 requires openmpi-libs 1:anjuta-2.26.1.0-1.fc12.i586 requires libgdl-1.so.0 1:anjuta-2.26.1.0-1.fc12.x86_64 requires libgdl-1.so.0()(64bit) bmpx-0.40.14-8.fc11.x86_64 requires libboost_regex.so.4()(64bit) bmpx-0.40.14-8.fc11.x86_64 requires libboost_iostreams.so.4()(64bit) clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.x86_64 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.x86_64 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.x86_64 requires gauche = 0:0.8.13 gnome-python2-gdl-2.25.3-4.fc12.x86_64 requires libgdl-1.so.0()(64bit) gtranslator-1.9.5-1.fc12.x86_64 requires libgdl-1.so.0()(64bit) libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.x86_64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 libprojectM-1.2.0-9.fc11.x86_64 requires libftgl.so.0()(64bit) orsa-0.7.0-8.fc11.i586 requires libcln.so.5 orsa-0.7.0-8.fc11.x86_64 requires libcln.so.5()(64bit) ppl-swiprolog-0.10.2-3.fc12.x86_64 requires libpl.so.5.7.6()(64bit) pyclutter-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.x86_64 requires libgeos-3.0.3.so()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.x86_64 requires libpqxx-2.6.8.so()(64bit) springlobby-0.0.1.10461-1.fc12.x86_64 requires libtorrent-rasterbar.so.3()(64bit) thunderbird-lightning-1.0-0.5.20090513hg.fc12.x86_64 requires thunderbird >= 0:3.0-2.4.b3pre vtk-examples-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 Broken deps for ppc ---------------------------------------------------------- R-RScaLAPACK-0.5.1-19.fc11.ppc requires openmpi-libs 1:anjuta-2.26.1.0-1.fc12.ppc requires libgdl-1.so.0 1:anjuta-2.26.1.0-1.fc12.ppc64 requires libgdl-1.so.0()(64bit) bmpx-0.40.14-8.fc11.ppc requires libboost_iostreams-mt.so.4 bmpx-0.40.14-8.fc11.ppc requires libboost_regex-mt.so.4 clutter-cairo-0.8.2-3.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.ppc requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.ppc requires gauche = 0:0.8.13 gnome-python2-gdl-2.25.3-4.fc12.ppc requires libgdl-1.so.0 gtranslator-1.9.5-1.fc12.ppc requires libgdl-1.so.0 libchamplain-0.2.9-1.fc11.ppc requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc requires libftgl.so.0 libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) orsa-0.7.0-8.fc11.ppc requires libcln.so.5 orsa-0.7.0-8.fc11.ppc64 requires libcln.so.5()(64bit) ppl-swiprolog-0.10.2-3.fc12.ppc requires libpl.so.5.7.6 pyclutter-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.ppc requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.ppc requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.ppc requires libgeos-3.0.3.so rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc requires libpqxx-2.6.8.so thunderbird-lightning-1.0-0.5.20090513hg.fc12.ppc requires thunderbird >= 0:3.0-2.4.b3pre vtk-examples-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 Broken deps for ppc64 ---------------------------------------------------------- R-RScaLAPACK-0.5.1-19.fc11.ppc64 requires openmpi-libs 1:anjuta-2.26.1.0-1.fc12.ppc64 requires libgdl-1.so.0()(64bit) bmpx-0.40.14-8.fc11.ppc64 requires libboost_regex.so.4()(64bit) bmpx-0.40.14-8.fc11.ppc64 requires libboost_iostreams.so.4()(64bit) clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) gnome-python2-gdl-2.25.3-4.fc12.ppc64 requires libgdl-1.so.0()(64bit) gtranslator-1.9.5-1.fc12.ppc64 requires libgdl-1.so.0()(64bit) libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) orsa-0.7.0-8.fc11.ppc64 requires libcln.so.5()(64bit) ppl-swiprolog-0.10.2-3.fc12.ppc64 requires libpl.so.5.7.6()(64bit) pyclutter-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.ppc64 requires libgeos-3.0.3.so()(64bit) python-mwlib-0.11.2-2.20090522hg2956.fc12.ppc64 requires LabPlot rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc64 requires libpqxx-2.6.8.so()(64bit) thunderbird-lightning-1.0-0.5.20090513hg.fc12.ppc64 requires thunderbird >= 0:3.0-2.4.b3pre vtk-examples-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 From cdahlin at redhat.com Fri Jul 10 18:54:38 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Fri, 10 Jul 2009 14:54:38 -0400 Subject: non-blocking dbus server In-Reply-To: <4A57077D.2020604@redhat.com> References: <4A57077D.2020604@redhat.com> Message-ID: <4A578E6E.90308@redhat.com> On 07/10/2009 05:18 AM, Jiri Moskovcak wrote: > Hi, > in our project ABRT we use DBUS for communication between ABRT daemon > and client (gui), the problem is that when I ask daemon to do some > time-consuming work the server is blocked until the work is done. So I > want to use threads and that's where I found the catch. > > Here is my idea: > 1. client calls remote method foo() over dbus > 2. daemon receives the call, creates the thread and let it do the work > in background and serve other requests > 3. when the work is finished send reply to the client > - this is the part where I'm stuck, because I want to send the reply as > return message to the matching method call, but the method call already > returned when I started the thread. (So far I can achieve this by > sending signal with return value as an argument, but I don't think this > is a good solution). > > I use dbus-c++, so maybe the answer is in some low-level DBUS API. > > Thanks for any help, > Jirka > Take a look at upstart's trunk. It uses the C API, but usually if you know how to do it with that you can find the corresponding features in the higher level wrapper pretty easily. Upstart is single-threaded, but spawns other processes as part of its operation which it occasionally has to wait for before returning a result. The typical case is: 1) Client calls start() method for a service 2) init gets start method, but doesn't send back a return value. It forks and execs the new service and waits for it to become ready. 3) Service signals that its running. init allows the DBus method to return with the status. --CJD From jonstanley at gmail.com Fri Jul 10 19:04:55 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Fri, 10 Jul 2009 15:04:55 -0400 Subject: FESCo meeting summary for 2009-07-10 Message-ID: Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-10/fedora-meeting.2009-07-10-17.00.html Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-10/fedora-meeting.2009-07-10-17.00.log.html Log below as well ---- 17:00:44 #startmeeting FESCo meeting 2009-07-10 17:00:45 #chair dgilmore jwb notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler 17:00:53 FESCo meeting ping -- dgilmore, jwb, notting, nirik, sharkcz, jds2001, j-rod, skvidal, Kevin_Kofler 17:00:53 * nirik is here. 17:00:58 * sharkcz is here 17:01:01 * notting is here 17:01:02 * Kevin_Kofler is here. 17:01:04 here 17:01:14 * dgilmore is here 17:01:37 alright, full agenda today.... 17:01:52 #topic whot provenpackager application 17:01:57 .fesco 178 17:02:06 * jwb is here 17:02:18 +1 to whot 17:02:22 +1 17:02:26 I didn't see any objections on the list, +1 17:02:34 +1 17:02:43 +1, no objections from me nor have I seen any from the sponsors 17:02:48 +1 here. 17:02:54 +1 i guess 17:02:59 +1 17:02:59 I'd have liked more positive feedback, but we can't have everything. 17:03:18 Kevin_Kofler: that's about normal what we got. 17:03:38 #agreed whot provenpackager membership is approved 17:03:50 #topic critical path packages 17:03:55 .fesco 171 17:04:20 jds2001, we approved this, so we're just re-reviewing? 17:04:24 * jds2001 honestly didnt have time to look at what changed. 17:04:30 So we just approved this last time and now it's up again? 17:04:33 jwb: skvidal put it back on the agenda. 17:04:38 Well, what's new is that there's now an actual list of packages. 17:04:46 Which should have been there BEFORE we approved this in the first place. 17:05:11 * jds2001 not sure of what we do from here 17:05:14 skvidal: ping???? 17:05:25 is there something to do with this? 17:05:26 i disagree with the BEFORE statement, but we already hashed that out last time 17:05:33 The obvious absent from this list is a @critical-path-kde group. 17:05:46 Kevin_Kofler: the KDE SIG needs to make that. 17:05:54 and they're more than welcome to. 17:06:02 I propose that the creation of a @critical-path-kde should be delegated to KDE SIG and will be taken up in the next KDE SIG meeting (probably July 21). 17:06:02 Kevin_Kofler, it is absent, yes. so is the XFCE and any other spin group. which are defined by those SIGs 17:06:10 * nirik has toyed with doing a Xfce one... 17:06:18 Kevin_Kofler, that was already in the proposal we approved 17:06:23 you don't need to re-propose it 17:06:38 Well, then what are we voting over? 17:06:42 is it expected that @critical-path* groups all are under the same scrutiny? 17:06:45 Should we just move on? 17:06:48 * jds2001 was wondering the same thing. 17:06:59 yeah, we have a full schedule 17:07:01 NEXT! 17:07:10 yeah, next. 17:07:26 #topic bundling of cryptsetup with volume_key 17:07:37 .fesco 175 17:07:47 +1 to allowing this, for the reasons I gave in the comments. 17:07:54 * mitr waves 17:08:02 We can't require linking against a system version which doesn't exist yet. 17:08:08 -1, it needs to go in it's own package. 17:08:26 -1 17:08:27 cryptsetup1.1 or the like. 17:08:37 jds2001: That only adds work and does not help anything - it would still be me who maintains that package. 17:08:38 * skvidal apologizes for his lateness - flaky network 17:08:43 Get the system ver up to snuff instead 17:08:44 Why? As long as there's no other user, what's the benefit? 17:08:50 I was not able tpo get to my irc proxy 17:08:56 Kevin_Kofler: it needs to make it a system version 17:09:17 That's the plan, but it needs time to get into cryptsetup upstream with a supportable API. 17:09:25 mitr: is there urgency in getting this in? or can it not just wait for the update from upstream? 17:09:31 Adding random APIs to system libraries isn't that great an idea. 17:09:43 Fwuw, the name volume_key is... Suboptimal... 17:09:45 i would strongly prefer we not ship something that requires a fork, if upstream is actively working on the functionality 17:09:57 notting, agreed 17:10:02 yeah, i thought it was something for adjusting sound or something. 17:10:05 nirik: I don't know eactly when new cryptsetup will be released (~10 work items), and volume_key package is necessary to develop dependencies (anaconda in particular) 17:10:13 * nirik just wonders what the hurry is. Is there some reason to get this in sooner than upstream is willing to add that functionality 17:10:33 See mitr's comments in the Trac item. 17:10:38 mitr: is upstream unresponsive? 17:10:38 Anaconda needs it. 17:10:43 notting: upstream will review the patch and perhaps request changes, there's not disagreement about the idea - this is not a long-term "fork" 17:10:52 that being said, the risks for security and bugfixes that would need applied seems identical whether it's bundled or unbundled 17:10:53 nirik: Responsive, but not willing to cut a release just for me. 17:11:28 If not releasing a stable release with a new feature and major new APIs within a few days is being "unresponsive", then there are a lot of "unresponsive" upstreams... 17:12:39 mitr: and the fedora maintainer doesn't want to apply your patches for now before upstream does? 17:12:54 is this cryptsetup-luks ? 17:12:57 that's certainly not "unresponsive"; it's not unreasonable for upstreams to want to get to particular milestones before cutting releases. 17:13:04 nirik: He wants to keep the Fedora package identical to the upstream package. yes, this is cryptsetup-luks. 17:13:05 nirik: changing the libraries abi locally in fedora would be bad 17:13:09 pjones: That's kinda my point. :-) 17:13:14 (that might be... responsible?) 17:13:17 pjones: of course not, i dont think anyone was ever claiming it was. 17:13:43 so why can't we patch in stuff that's already been committed upstream? 17:13:59 I was just asking the status of talking to upstream... :) 17:14:00 pjones: It was not committed yet. 17:14:02 we should be able too, not sure why..... 17:14:02 Upstream didn't commit this to their trunk yet, they have yet to review the new APIs. 17:14:12 mitr: is volume_key intended to be the only user of the new ap? 17:14:15 erm, api? 17:14:18 and it's got APIs that get exposed? 17:14:26 It's additions to a library. 17:14:30 So of course there are new APIs. 17:14:38 Which is the whole reason why the bundled copy is needed. 17:14:45 notting: I don't know about anything else, but it could appear 17:14:46 mitr: why not push out this change until it does land upstream? I know it's needed for anaconda, but can't they defer those changes? 17:14:53 So that means somebody is going to code to those, and then upstream is going to change them before committing, and then we're going to have more bugs. 17:14:57 mitr: hrm, ok 17:15:05 is there someone here who works on anaconda? 17:15:20 notting: I guess some proprietary sotware might want it - one more reason _not_ to make the API public until it is finished. 17:15:21 pjones: That's exactly why it's not a good idea to just patch them in. 17:15:23 so, i think it's two questions - do we care about shipping the forked library, and if so, do we care if it's bundled in volume_key? 17:15:26 And thus the bundled copy. 17:15:31 nirik: There's not that much time left. 17:15:40 Kevin_Kofler: well, that's why it's probably fine /once they've been accepted upstream/. 17:15:47 but until then, it seems very premature. 17:15:55 mitr: the world is about to end? 17:15:57 if we allow the forked library, i don't have any objections to shipping it bundled with volume_key (since nothing else will use it) 17:16:23 but could anything else benefit from these new API' 17:16:25 's? 17:16:26 Are we in a business to ban forked libraries altogether? 17:16:28 nirik: No, I'll spend 3 days removing the cryptsetup-luks dependency. A net loss, IMHO. 17:16:29 mitr: fedora releases every 6 months or so... if it doesn't happen this time, why not wait for next cycle? 17:16:34 Really we want dlehman around for this discussion. 17:16:38 * jds2001 has a concern that it will end up de facto used. 17:16:45 Kevin_Kofler: in general, yes. 17:16:46 Libraries can fork just like any other project. 17:16:57 And apps will rely on the forks. 17:17:00 Kevin_Kofler: that doesn't mean it's not okay in some situations, but it is frowned upon, and rightly so. 17:17:10 there is a cost to forks... and should be. 17:17:31 mitr: removing the dependency how? moving all that code into your app? 17:17:58 So I think there's another concern to be addressed. 17:18:16 nirik: moving (and integrating cleanly). Right now I'd rather rather do that work than wait 6 months. 17:18:22 * jds2001 steps away for a few minutes. I propose like 5 more minutes on this topic...there's lots more :) 17:18:28 mitr: you said they're not willing to cut a release for us, but they've also not accepted the patch yet. The former seems to be a separate issue from the latter. Is there a reason they haven't taken the patch? 17:18:53 pjones: No specific reason I know about - lack of time/priority I guess. 17:19:23 It'd really help to know if upstream likes or dislikes the patch. 17:19:26 w/ 45 17:19:28 oops. 17:19:47 pjones: +1 17:19:58 pjones: agreed 17:20:18 pjones: I'm 100% sure upstream will accept the functionality. 17:20:28 mitr: how can you be completely sure? 17:20:37 sure, but "the functionality" and "the api change" aren't the same, and we need the stronger guarantee of the latter. 17:20:59 Specifics of the patch are my responsibility anyway - both in talking to upstream, and in fixing the bugs that affect volume_key (even more so if it is bundled). 17:21:07 skvidal: I talked to mbroz 17:21:20 mitr: it should not be bundled at all 17:21:32 mitr: and you cannot talk to mbroz again and find out about the patch? 17:21:37 bundling it is straight out bad. 17:21:42 skvidal: I can't make him review it right now. 17:22:01 mitr: s/make him /ask him to/ 17:22:03 well, we've got what, 18 days before it needs to be finished? 17:22:59 skvidal: mbroz is not cryptsetup upstream 17:23:04 (unless i missed something) 17:23:11 notting: then how does he know what they will accept? 17:23:13 notting: recent change 17:23:43 * jds2001 back, sorry 17:23:46 mitr: he took over for clemens? 17:24:01 notting: http://code.google.com/p/cryptsetup/source/browse/trunk/ChangeLog - mbroz releasing 1.0.7-rc1 17:24:15 notting: Apparently, I don't know the exact arrangement. 17:24:39 wow...thats a long gap in releases. 17:25:05 so we don't know the upstream maintainer arrangement, they haven't reviewed the patch yet, but we're 100% sure it'll go in at some point 17:25:25 jwb: If mbroz tells me he is upstream, I trust him :) 17:25:25 jwb: yes, that was my point :) 17:25:32 * jwb hums "one of these things does not belong here" 17:25:47 jwb: "the functionality" will go in. "the patch" might not. 17:26:15 right, but "the patch" is the thing it's helpful to know about. 17:26:20 and the patch - specifically the API is the issue we need to know about 17:26:22 proposal: table this for next week, pending further discussions with upstream? 17:26:25 this jsut strikes me as full of potential fail. 17:26:34 notting, further logged discussions 17:26:35 As I wrote in Trac: I propose we approve this, with the understanding that it's a temporary solution and efforts should be made to get the changes upstreamed into libcryptsetup ASAP. 17:26:36 notting: I don't think I actually get a vote here, but +1 17:26:44 notting, +1 17:26:46 what if we allow it, then the API's change, then our code is broken...... 17:26:47 notting: What do you want to learn by net week in particular? 17:26:54 notting: There's not much time. 17:26:59 seems like a viscious cycle of never getting rid of it. 17:27:02 Wasting another week will hurt Anaconda. 17:27:10 We should just approve this now as a temporary solution. 17:27:10 mitr: ... a timetable on when a frozen api will be available? 17:27:40 mitr: ... some sort of status on the patch, whether it's "ignored", "read", "reviewed", or "comittted" 17:27:48 (translating) "Fedora will be the first one to have the new release, what more do you want me to say"? 17:27:57 Kevin_Kofler: making hasty decisions b/c of a potential schedule is a bad idea and a worse precedent 17:28:00 (from earlier dicussion) 17:28:18 mitr, when the release is. or even when the patch will be committed 17:28:28 i think everyone would feel better with a committed change 17:28:35 skvidal: It's being unable to provide important features due to useless bureaucratic delays which would be the bad precedent. 17:28:47 mitr: or alternately if that API is what'll go in. 17:28:59 pjones, yes 17:29:00 Kevin_Kofler: there's nothing useless or bureaucratic here - this is just planning 17:29:20 Kevin_Kofler: lest we end up having to REDO this AGAIN - or wose yet maintain a fork forever 17:29:31 Kevin_Kofler: I don't think wasting another week will actually hurt us that badly, but really I need dlehman to be sure. 17:29:38 Kevin_Kofler: my expectation is that he has other things he also needs to work on that this doesn't block, so it won't actually hurt us that badly. 17:29:47 (I also don't think it's fair to call it "wasting another week", but I was quoting you there.) 17:30:01 As an anaconda maintainer, I'd prefer we wait and do this once instead of wasting time by revisiting it again and again. 17:30:34 Well, in that case I'm OK with waiting for next week, but we need some additional information by then or we'll just have wasted a week. 17:30:46 skvidal: "we end up having to REDO it" is me, not FESCo. 17:30:56 Ideally, we'd get upstream to commit this into trunk and the Fedora maintainer to backport the patch from trunk. 17:31:04 pjones: right. i think we need to get the new api stablke and settled upstream and package it correctly 17:31:16 dgilmore: yeah. 17:31:19 * nirik is ok also with updating the ticket as info comes in and we can weigh in there over the week before next weeks meeting. 17:31:23 +1 for notting's table it, next 17:31:29 Kevin_Kofler: that's not ideally. That's worst-reasonable-case. 17:31:32 j-rod: +1 17:31:35 j-rod: +1 17:31:37 +1 17:31:40 ok, that's at least 6 or 7 +1 17:31:44 agreed. Next. 17:32:04 #agreed tabled for next week when additional information will be available 17:32:23 #topic Adobe CMap files - code or content? 17:32:31 .fesco 177 17:32:55 This one is almost philosophical... Always fun to discuss. 17:32:56 good question :) 17:33:13 * jds2001 has been waffling back and forth on this one 17:33:43 Kevin_Kofler: this has VERY practical ramifications. 17:34:06 it's ... a table. is that even copyrightable? 17:34:09 * notting looks at spot 17:34:18 jds2001: Right, that's the big problem here. 17:34:23 * dgilmore thinks its likely content and needs removal 17:34:24 * nirik thinks he would side with spot here... Barely content. 17:34:38 dgilmore: it wouldnt need removal if content. 17:34:47 dgilmore: content that restricts modification is ok. code that restricts it is not (per guidelines) 17:34:48 Thiese are technically code (PostScript) files, but they just contain tables, see e.g. http://www.ghostscript.com/pipermail/gs-cvs/2003-December/003861.html for what they look like. 17:35:02 jds2001: well i think being unmodifiable makes it unacceptable 17:35:18 dgilmore: as code, yes. non-modifiable content is fine. 17:35:21 * jwb sighs 17:35:51 So it's really hard to decide whether we need to apply the stricter rules for code here or not. 17:36:05 we could take a practical approach 17:36:27 does removal cause breakage? if yes, content. if no, code 17:36:28 there is a free postscript interpreter. 17:36:36 so I view it as content. 17:36:53 There's a Free Python interpreter, so all .py files are content??? 17:36:55 barely 17:37:02 practically that's pretty similar to the keymap definition files in X 17:37:15 jds2001: This argument makes no sense. 17:37:21 ajax: i'd argue they are content as well. 17:37:31 which have had some hilarious licenses that we just ignore because they're a) not copyrightable b) not meaningfully modifiable anyway 17:37:31 The argument is over what the file actually contains. 17:37:36 Kevin_Kofler: im framing it in terms of a previous FESCo decision. 17:37:36 ajax: are they considered copyrightable (nigeria aside) 17:37:44 Kevin_Kofler: not by itslef. 17:39:21 I think these files are clearly code, not content. We don't even apply the laxer content rules for fonts. 17:39:22 so, what is the data used for? 17:39:33 I think that is really the determining factor. 17:39:37 pjones: character mapping. 17:39:50 They're in code files (.ps), they're used in code just like fonts and the tables within fonts are. 17:39:52 pjones: https://bugzilla.redhat.com/show_bug.cgi?id=487510#c5 17:39:54 Bug 487510: medium, low, ---, twaugh, NEW, Licensing issue of ghostscript CMap files 17:40:00 so, i'm +1 to them being content, as that is how they appear to be used. barely. i'm also interested in a fedora-legal opinion of whether a table of mappings is an actual copyrightable file, in which case the issue is null and void 17:40:22 +1 to notting. 17:40:23 I'm with notting. +1 (barely content). 17:40:26 notting: i can work with that 17:40:27 +1 17:40:31 +1 to notting 17:40:32 Fonts aren't "content", so why would these character maps be "content"? 17:40:34 jds2001: mapping between what and what? 17:40:35 -1 to notting. 17:40:38 +1 for content, just barely 17:41:13 +1 to notting 17:41:14 We shouldn't call this "content" just to sweep the legal issues under the carpet. 17:41:32 thus notting's interest in fedora-legal's opinion 17:41:37 Next we call the NVidia drivers "content"? 17:41:46 Kevin_Kofler: of course not. 17:41:46 Or maybe we call them "firmware", just for fun? 17:41:53 thus notting's interest in fedora-legal's opinion 17:41:59 Kevin_Kofler: Nvidia drivers are clearly not content 17:42:06 which is why I +1'd notting's suggestion 17:42:16 my approach to hyperbole is to ignore it 17:42:30 jwb: indeed we should 17:42:34 #agreed Adobe CMap files are content, but we're not sure that they are actually copyrightable. 17:42:36 it would be akin to copyrighting a unicode table, no? 17:42:37 So the question in my mind is: is there a reason to modify this? If it is, it seems less like content 17:42:39 NEXT! 17:42:53 so I believe we've now witnessed both reductio ad absurdum *and* post hoc ergo propter hoc logical fallacies so far today... 17:43:10 #topic Docs guides RPM's 17:43:14 .fesco 188 17:43:17 If you have to change them to either add a new character codes or new glyph selectors (whatever those are ;), as opposed to just adding more of them in parallel, then they definitely are code. 17:43:24 Sparks: you around? 17:43:28 jds2001: I am... 17:43:29 guess we moved on. 17:43:49 pjones: we have, nothing more to be gained from the previous discussion. 17:44:11 i don't suppose it can make one source rpm, multiple language outputs? 17:44:12 jds2001: I think the facts have largely been ignored there, but it's not really my place, so I'll let you move on. 17:44:20 * notting knows jack about the publican input 17:44:25 * dgilmore thinks that having all docs for one language in one srpm would be good 17:44:37 Sparks: you wanna give an overview of what the deal is here? 17:44:37 notting: Publican won't... not natively. 17:44:43 jds2001: Sure 17:44:52 pjones: feel free to update the ticket with more info if you find it. ;) 17:44:57 So, thanks for allowing me to come and get direction... 17:44:59 can you modify it to? 17:45:07 IMHO, publish whatever you want. 17:45:15 I don't see no reason why we wouldn't package all languages. 17:45:22 nirik: well, I think there's insufficient information there about how they're *used*, and I think that's the determining factor. 17:45:26 the problem is that when Publican creates the SRPM for a particular guide it does it one language at a time... 17:45:29 It's up to you folks actually working on the docs to package them. 17:45:35 Kevin_Kofler: so we have 42 packages for each guide. 17:45:37 Why is this a FESCo issue at all? 17:45:43 At most this is something for FPC. 17:45:49 so that means that if all our guides are translated to what the Release Notes are (in 41 languages)... 17:46:07 one can start to see the problem with getting each package approved... having multiple CVS instances... etc. 17:46:21 yeah, i would prefer publican not do that 17:46:28 The Docs Team is willing to be flexible but we are still looking for direction. 17:46:49 We had thought of just including the en-US version in the repo and having all other RPMs available at docs.fp.o 17:46:51 is there something we can do here? I guess I would say make publican not do that, but it's not a FESCo issue really. 17:47:09 nirik: that's easier said than done, unfortunately. 17:47:30 Sparks: i personally think we should have fedora-docs-xx-XX packages that has all the docs in one language, and have it all available via a web download in pdf and html online viewing 17:47:32 So if we throw them all together into a BIG rpm... that makes it a large download. 17:47:34 It's fairly easy to make one huge package out of several independent l10n tarballs. 17:47:47 kde-l10n (and kde-i18n before that) have been doing just that for ages. 17:47:53 Sparks: it boils down to what do you want to do, how much effort you want to do with reviews, updates, etc. not something fesco necessarily needs to 'rule' on 17:48:06 Kevin_Kofler: publican actually produces SRPM's 17:48:13 dgilmore: Yeah... and docs.fp.o will have all the guides in HTML and PDF 17:48:21 Sparks: :) 17:48:23 jds2001: Specfiles can be hand-edited. 17:48:40 I see no requirement that the autogenerated specfile must be imported as is. 17:48:46 notting: Yes.. but we also don't want to start dumping a couple hundred RPMs into the system 17:49:05 explode the srpms for each lingo, merge into a singe srpm for each document 17:49:21 Kevin_Kofler: The SPEC files cannot easily be manipulated in Publican. it is a hands-off tool 17:49:34 Sparks: but they can be afterwards. 17:49:35 You need to commit the specfile to the CVS anyway. 17:49:38 so maintain your own spec 17:49:44 that's what we're saying.... 17:49:49 jds2001: Yes which is kinda what we were doing with the Release Notes. 17:50:17 See e.g. http://cvs.fedoraproject.org/viewvc/rpms/kde-l10n/devel/kde-l10n.spec?revision=1.83&view=markup for the "one SRPM, many tarballs, many binary RPMs" approach. 17:50:19 The problem becomes that if you put them all into a single RPM that RPM becomes a HUGE file 17:50:36 What we're doing is we just loop over the extracted tarballs and build them all. 17:50:47 Sparks: put them in subpackages. 17:50:49 Then we loop over them and install them all. 17:50:52 the SRPM becomes huge 17:50:55 And we have one subpackage for each. 17:51:01 but the subpackages don't. 17:51:05 what is huge? 17:51:07 But yes, the drawback of this approach is that the SRPM gets really, really huge. 17:51:39 kde-l10n's SRPM is 217 MB. 17:51:41 * jds2001 thinks kde-i18n is in the range of 200-300MB+ 17:51:47 271 MB actually. 17:51:52 (typo) 17:51:53 If the Security Guide package becomes 500 MB... it becomes a little burdonsome on the enduser 17:52:06 it would only be the src.rpm 17:52:08 but they never see all 500MB 17:52:12 not the binary that anyone would install. 17:52:13 unless they get source. 17:52:23 we're talking about a lot of stuff, right? So something's going to be huge, be it the number of srpms or the size of one, right? 17:52:31 But I still don't see why that's a FESCo issue. 17:52:41 Isn't this something to be sorted out with FPC and/or rel-eng? 17:52:42 jds2001: no one uses the source :) 17:52:46 Okay... so with subpackages... the end user only gets the one file == small? 17:53:02 skvidal: i sync source on my local mirror :D 17:53:02 Kevin_Kofler: or just in devel later. ;) 17:53:12 jds2001: and you're clearly nobody :) 17:53:23 Sparks: nod 17:53:40 Sparks: so we can help you make it work. ;) See folks in devel later? 17:53:40 Well, I'm good with many SPRMs and smaller files for the end user 17:54:05 nirik: Getting ready to hit the road for NC but we'll get this straightened out soon. 17:54:09 alright, can we move on? 17:54:14 i propose nirik helps Sparks and the docs team fix this 17:54:15 ;) 17:54:22 I'd be happy to assist. 17:54:24 Thanks for the input! 17:54:50 #topic Minimal Platfrom from F11 17:54:54 * skvidal hurries to the border to stop Sparks 17:54:55 .fesco 66 17:55:07 so stickster pinged me about this one. 17:55:10 #agreed nirik will help Sparks and the docs team with this. not a direct fesco issue. 17:55:30 notting: oops, it's under the wrong heading now. oh well. 17:55:41 it sounded like it was implemented as it was supposed to have been 17:55:47 #agreed this == previous topic of docs 17:56:07 yeah, i think this should just be retargeted back at f11 17:56:13 dgilmore: there's no UI around it like hte feature said. 17:56:16 haha 17:56:30 stickster: you around? 17:56:33 it's because they're using * Targeted release: [[Releases/{{FedoraVersion||next}} | {{FedoraVersion|long|next}} ]] in the feature page. the page actually hasn't been edited for f12 17:56:36 * stickster pops up like groundhog 17:56:46 hehe 17:56:48 jds2001: right. they did the compos work but neglected to get the anaconda work done 17:56:51 we need to get a hold of the feature owner and see whats going on. 17:56:57 * stickster was asked a question about this feature and the feature page is unclear on overall status. 17:57:06 nirik: That sounds like a good plan to me. 17:57:22 ping feature owner, table and revisit next week? or are they around? 17:57:23 stickster: see above re: wiki markup. i think it's just a markup error. 17:57:23 Note the page itself says F12 is the target, yet it remains at 100% and in the F11 feature list. 17:57:27 ah! 17:57:27 this was the server SIG's work from memory 17:57:31 sharkcz: ping 17:57:31 whoops. 17:57:50 so i think we should just manually edit the version, and it all will be ok? 17:57:51 dgilmore: pong - it was parallel to server sig 17:58:09 sharkcz: this feature. was proposed for the server sig right? 17:58:16 proposal: notting to edit the version 17:58:23 sharkcz: and the anaconda work was not done. 17:58:28 The page also links to a kickstart which might use some sprucing up 17:58:30 The feature page says: "Owner: Name: Peter Vrabec" 17:58:37 we did a bad job of checking that the feature was actually complete 17:58:43 dgilmore: that would be a new page, no? 17:58:59 notting: it seems to be in scope of this feature. 17:59:20 I think it doesn't make sense to revisit this feature now, it's a done deal. 17:59:22 right, but if feature bit A is done for release , then we do a new page for feature 17:59:48 notting: i thought,( and id need to go back to irc logs) that we said that this minimal platform was what you would get on a text install unless you used a kickstart 18:00:08 notting: but for F-122 it will need a new page 18:01:01 dgilmore: right: 18:01:08 anaconda.backend.resetPackageSelections() 18:01:08 anaconda.backend.selectGroup("Core") 18:01:15 notting: it only says Fedora-12 because they used a variable to define the release 18:01:32 have we just come full circle? 18:01:36 notting: but it did not happen in F-11. 18:01:37 right, so lets just change that and be done???? 18:01:47 I'm fixing the targeted release now. 18:01:51 I need to do a text mode install and check but dcantrell said it was not done 18:01:54 dgilmore: that change is from march 12 18:02:24 Targeted release fixed. 18:02:27 ok, then the graphical ui wasnt done, but dont think we need/want one. 18:02:41 #agreed targeted release fixed. 18:02:43 NEXT! 18:03:01 #topic NM mobile broadband enhancements 18:03:07 .fesco 174 18:03:15 Kevin_Kofler: did you have anything more on this? 18:03:59 +1 18:04:02 I think we're basically OK now. I'd like Summary and/or Detailed Description to make it clear which UIs currently implement it (AFAIK only the GNOME nm-applet). 18:04:16 +1 18:04:21 But the important compatibility questions have been addressed. 18:04:25 +1 18:04:27 +1 18:04:34 +1 18:04:55 #agreed NM mobile broadband F12 feature is accepted. 18:04:57 +1 to the feature 18:05:00 +1 18:05:18 +1 18:05:27 #topic Feature =Anaconda FCoE 18:05:28 +1 18:05:37 .fesco 179 18:05:47 (for the NM one) 18:05:58 * j-rod slightly distracted atm 18:06:06 +1 18:06:17 i have a somewhat dumb question 18:06:18 The documentation is not written yet. 18:06:19 +1 for this. i realize it's unlikely to get much community testing 18:06:33 +1 18:06:36 +1 18:06:38 +1 18:06:42 is this going to have another stupid daemon installed and running by default on all systems? 18:06:43 +1, but agreed. A test day might be good? 18:06:43 +1 with the documentation filled in 18:06:49 (like the iscsi stuff...) 18:07:09 I'm with dgilmore, +1 to the feature, but the documentation needs to be written ASAP! 18:07:11 ew, yeah, that would... be annoying... 18:07:16 jwb: hrmm hope not 18:07:34 Kevin_Kofler: we are not commenting on the completeness of the feature at this time. 18:07:39 that comes later. 18:08:08 that's somewhat orthogonal to the Feature, but it would be nice if that didn't happen given the previous statements of rarity 18:08:15 anyway, +1 overall from me 18:08:18 #agreed Anaconda FCoE feature is accepted. 18:08:20 jwb: AIUI... the utils are commandline 'attach to this fcoe device'. there's no daemon 18:08:23 jwb: agreed 18:08:45 jwb: anaconda should only enable the iscsiinitiator if iscsi is used 18:08:49 #topic Feature - extended lifecycle 18:08:55 -ENOTAFEATURE 18:09:02 jds2001: +1 18:09:08 not a feature 18:09:19 notting, cool 18:09:20 jwb: /etc/rc.d/init.d/fcoe-utils there is a daemon 18:09:20 nor does it have a snowballs chance in hell 18:09:38 jds2001, +1 18:09:47 I also think the feature process is the wrong way to get this approved. 18:10:02 So +1 to "not a feature". 18:10:08 +1 to not a feature, HOWEVER... 18:10:12 yeah, pass buck to board? 18:10:23 i think this sort of falls under fesco's purview somewhat (quantifying resources required, etc.) 18:10:40 notting, that is true. but either way, not a Feature 18:10:49 notting: agreed. But shouldn't the board say if we want to do this? then fesco should chime in on the tech aspect. 18:10:49 i think what could be a feature is having a way to move between fedora/CentOs/RHEL 18:10:59 So what should we answer? Bring it up again as a task item? 18:11:01 I think this *could* be a feature 18:11:11 nirik, that is also a valid point 18:11:15 since its possibly something that would want the associated marketing 18:11:17 dgilmore: -1 - "I want a pony" features are not fun 18:11:20 dgilmore: The problem is that it doesn't depend only on us. 18:11:22 j-rod, you can market outside of Features 18:11:40 true 18:11:43 Kevin_Kofler: right. it needs to be done above us 18:11:52 And the big technical problem is that if RHEL n is based on Fedora x, Fedora x will have moved on in updates beyond RHEL n's conservative versions. 18:11:59 Heck, even Fedora x-1 will! 18:12:12 RHEL is not a concern of mine for this at all 18:12:15 skvidal: essentially i think that having it would make the swarm of we need a extended fedora release go away 18:12:16 Compare e.g. kernel and KDE in FC5 and RHEL 5. 18:12:41 dgilmore: it just won't work nicely. Not to mention making it tie to rhel would mean communicating to rhn :( 18:12:49 (x=6 here, FC5 is Fedora x-1.) 18:12:50 anyhow..... 18:12:52 dgilmore, i don't think we are here to make swarms of people go away 18:13:05 skvidal: right. it wouldnt be fun 18:13:09 #agreed Extemded Lifecycle does not meet the definition of a feature 18:13:14 the swarm always builds when the current EL is getting rather old 18:13:16 should we officially move to board? 18:13:22 more to get to, can we move on..... 18:13:27 notting: sure 18:13:28 proposal: ask the Board if an extended lifecycle is something the project should consider 18:13:51 f13: right 18:13:53 +1 for 'ask the board' 18:13:56 at least this proposal has something of a measurable goal and plan other than "hey leave buildsystem running and maybe people will use it!" 18:13:59 #agreed this is deferred to the Board for consideration if an extended lifecycle is desired. 18:14:00 +1 for ask the board 18:14:10 +1 ask the board 18:14:13 +1 18:14:18 +1 18:14:22 * nirik nods. This is a higher level direction, needs board 18:14:27 -1, this is just "hot potato" handling of proposals. 18:14:43 +1 for my proposal 18:14:47 or really, niriks 18:14:56 Kevin_Kofler: so what do you propose we do, drop it on the floor? 18:15:03 fwiw, I think this would meet both at least #1 and #5 of the criteria for calling something a feature 18:15:05 that surely wouldn't be good. 18:15:12 jds2001: Approve it within FESCo. 18:15:16 anyhow...... 18:15:18 Kevin_Kofler: weren't you just questioning why a proposal was being looked at by FESCo ? 18:15:25 Kevin_Kofler: we can't do that. 18:15:31 jds2001, we have majority vote to move to the Board 18:15:38 yep 18:15:40 f13: I was saying it's not a feature, I wasn't saying it shouldn't be a FESCo task. 18:16:06 #topic Feature - Fedora Moblin 18:16:07 And I was saying moving to RHEL isn't easily possible, but that wasn't the proposal we're voting on! 18:16:11 .fesco 181 18:16:32 Kevin_Kofler, if the board things it's worth doing as an official thing, we can decide how to do it at that point 18:16:38 * nirik notes the spins part of this needs to use the spins process. 18:16:41 s/things/thinks 18:17:04 * jds2001 hasnt really had a chance to read feature pages from here on down. 18:17:12 * jds2001 does that real quick 18:17:24 +1 for adding the moblin bits. only 10% done makes it seem like its going to have trouble being ready in time though. 18:17:41 +1. please tell the feature owner to link to review tickets in the feature definition :) 18:17:45 Would the use of "Moblin" be a trademark issue? 18:17:50 yeah, +1, and note again they need to use the spins process for a spin, but I suspect they will not make it in time. 18:17:59 bag 18:18:02 bah 18:18:02 i'm ok either way on this one. i think it might be good to revisit after the packages are in-distro and the spin is approved by the spins SIG 18:18:10 +1 the spin part needs to go through the spins approval 18:18:12 Work with Fedora QA to ensure that we have sufficient coverage 18:18:13 +1 18:18:20 * jds2001 *hates* features that say this. 18:18:29 jds2001, yeah. that's not feasible 18:18:51 wait, there's a "Fedora QA" ? ;) 18:19:07 j-rod: thanks. 18:19:25 Kevin_Kofler: moblin is not a trademark 18:19:42 f13: no problem, any time... :) 18:19:44 (at least, not in the US) 18:19:55 it's a good thought to be concerned with though 18:19:58 +1 to the feature, don't think it will make it, spins process needs to be used. 18:20:04 +1 18:20:07 A real test plan would be a plus too. 18:20:11 * j-rod watches out for jlaska's wrath... 18:20:13 +1 w/QA 18:20:27 +1 but needs separate spin approval 18:21:08 As for QA: it's always hard to write a test plan for a complete desktop environment. 18:21:10 #agreed Moblin feature is approved, with the understanding that the spins component will need to go through the spins process. 18:21:18 There's no way to test it exhaustively. 18:21:48 Kevin_Kofler: it doesn't have to be perfect 18:21:50 * nirik nods. Way too much there... 18:21:51 but there should be something there 18:21:53 #topic KDE 4.3 Feature 18:21:58 like "every menu item launches" 18:22:04 .fesco 182 18:22:05 or "can log in from login manager" 18:22:19 QA is just looking for something we can measure the feature against for success/fail 18:22:25 +1 to KDE 4.3 18:22:26 * jds2001 has the same comments aboutt he lack of a test plan here. 18:22:33 is KDE 4.3 akin to a 4.0 release? 18:22:47 i don't know the numbering schemes 18:22:54 you mention testing integration with various parts of the distro 18:22:57 It's akin to 4.2 which was accepted as a feature. 18:22:57 jwb: kde doesn't do odd/even, if that's what you mean. 18:23:02 +1 here. Thanks for making it a feature. ;) 18:23:03 but there's no way to do that. 18:23:09 +1 to kde 4.3. 18:23:12 +1 at any rate 18:23:14 Plus we have Solid DeviceKit and PolicyKit 1 integration in the works. 18:23:16 notting, ok. i was mostly just asking if it was to be considered a "rough" release like 4.0 was 18:23:16 +1 18:23:22 +1 to kde 4.3 18:23:29 jds2001: ltinkl and jreznik are working on those integration features right now. 18:23:36 Kevin_Kofler: cool. 18:24:00 We may also get fingerprint reading in KDM in, no promises though. (There's code out there, but there are known issues.) 18:24:09 #agreed KDE 4.3 feature is accepted. 18:24:36 #topic Open Sharedroot - Featire 18:24:41 * jds2001 cant type 18:24:47 I also wrote a draft test plan for Phonon-GStreamer earlier today. 18:25:21 .fesco 183 18:26:06 So the problem with this one is that they're using a third-party repository. 18:26:29 right, I think these packages are supposed to be in Fedora. 18:26:30 my understanding is that that's only until the packages are accepted 18:26:39 We need this stuff to actually get into Fedora, i.e. reviewed as packages, or patched into the kernel for kernel modules (no, we're not going to debate separate kmods today ;-) ). 18:26:44 -1, for two reasons. 1) they're using a third party repo. 2) if they're not using a third party repo, i think a secondary (or is that tertiary now) initramfs setup is a bad bad bad idea 18:27:09 the 'yet another initrd' part is my only real concern 18:27:21 kinda the opposite direction of dracut 18:27:35 perhaps these two camps should talk... :) 18:27:44 scope is listed as "Except from the small changes that have to be accepted for the initprocess. Everything else is already working for FC11, RHEL5 and RHEL4. So only the migration to FC12 has to be made.". that implies they're not submitting comoonics stuff 18:27:46 they probably should, but i don't think it's grounds for dismissal 18:28:03 It was me to add this feature. We don't have a problem to integrate into dracut (new initramfs) but were not sure what you would want. 18:28:09 It's not a Fedora feature if it requires outside repositories. 18:28:10 erm, my comment was about the duplicate initrd thing. not the packages 18:28:22 Kevin_Kofler: my understanding is it won't 18:28:27 marcg_: is that correct? 18:28:37 oh. hrm. I'd ASSumed the packages were under review... 18:28:40 the outside repo is temporary until these packages are in Fedora? 18:28:40 marcg_, are you going to submit the packages needed to fedora? 18:29:02 Yes we are going to submit all packages which are of interest. 18:29:35 ah, ok, that should be listed under 'scope' 18:29:36 cool, do you have a tracker bug for all the reviews? 18:29:42 We've also already talked to the developer of dracut and also think that it would be no problem to integrate the initrd part into that. 18:29:45 85% complete seems slightly optimistic if you've got multiple packages that still need to go through review... :) 18:30:11 marcg_: that would be preferred. 18:30:21 my concern is also that (as it stands now), it's essentailly a secondary initramfs boot setup, a secondary cluster suite setup, etc. etc. 18:30:41 And have a fedora11 open-sharedroot cluster running with dracut. So basically 85% is because it's already running but we were not sure what else we needed to do. 18:31:12 so the integration into dracut is already done? 18:31:22 What definitely needs to be done is to get the packages reviewed and approved for Fedora. 18:31:28 nooting: It's not really a secondary cluster suite setup. Whereever we can we'll integrate into what's already there. 18:31:35 Kevin_Kofler, yes. that's probably step 1 18:31:58 Hopefully you have a second person working with you, otherwise the reviews will take a long time. 18:32:00 marcg_: well, when i see a package called comoonics-clustersuite ... 18:32:02 jwb: for us yes. But we need to talk to the dracut developer again. 18:32:39 You need one submitter and one reviewer, ideally both already sponsored, to get things done fast. 18:32:40 notting: comoonics-clustersuite is just a abstraction layer that fits on redhat-cluster oracle cluster or "no" cluster and whatever will come later. 18:33:41 marcg_: like libvirt abstracts different virt technologies? 18:33:57 dgilmore: more or less yes. 18:34:14 marcg_: does it still require disabling selinxu? 18:34:26 marcg_: ok. without everything in fedora its not a feature 18:34:52 dgilmore: rhcs is in fedora i think 18:35:02 notting: I didn't test it with enabled selinux. 18:35:08 ick 18:35:21 jds2001: right but this works with it it sounds like 18:35:26 j-rod: prepare for wrath ;) 18:35:35 It was initially based on rhcs. Yes. Those guys know about sharedroots. 18:36:20 jlaska: I'm waiting patiently for it... ;) 18:36:24 marcg_: we cant evaluate it as a fetaure until you work to get it all in fedora. which would include working to get whatever initramfs stuff you need into dracut 18:36:25 But it's more or less an extension of any clustered or distributed filesystem when used as root filesystem. 18:36:51 j-rod: I was in another side-bar ... are you looking for QA input on a feature? 18:37:20 jlaska: nah, j-rod was trying to tell us there is no Fedora QA :D 18:37:36 jlaska: no, I was just being a smart-ass about an earlier feature that included a "talk to Fedora QA" bit in it... :) 18:37:43 dgilmore: ok (the dracut thing that's perfectly ok for us) and the tools for managing cdsl and the issues we have with the initprocess. 18:38:10 lemme know if we need some input from the QA group ... I'll be happy to lend $0.02 and ask for input from the larger team 18:38:48 marcg_: how much of the comoonics repo are you looking at bringing in? i mean, that's 500k of python scripts 18:38:59 which seems like an awful lot of infrastructure 18:39:21 No it's not that big, basically we can cut it down to about 20 classes. 18:40:01 It just the cluster abstraction layer and the cdsl management. All other classes are for more advanced usages. 18:40:06 still, strikes me a little odd. we already have rhcs, which is configured one way,and now you have this other infrastructure on top of it that's being brought in 18:40:25 marcg_: ok sof for now we will deny the feature. when you have a plan for getting everything into fedora and dracut. we can re-evaluate. as it stands its not ok. there can be no referneces to outside repos. 18:40:35 to me it's just a service on top of rhcs, right? 18:40:43 notting: indeed. but i guess i can see using it like libvirt 18:40:54 dgilmore: Well, outside repos for testing until the packages get accepted is quite common. 18:40:58 The TeXLive feature had them too. 18:41:14 dgilmore, i think you mean defer the feature 18:41:23 jwb: sure 18:41:30 yeah, im fine with deferring this 18:41:32 I'm fine w/the outside repo, as long as its clear this is only for testing pending the package being included in fedora 18:41:33 dgilmore: libvirt makes sense if you're planning on switching out the underlying implementation. i don't think we're swapping fedora's cluster support out for oracle cluster suite any time soon 18:41:39 ...which the feature is dependent upon 18:41:43 j-rod: +1 18:42:05 notting: no, but a consumer of this could. 18:42:07 notting: we may not. but if we had both in admins only need to know one way to setup a cluster 18:42:25 notting: what that cluster is becomes less relevant 18:42:29 Because of the abstraction layer. There are many customers using nfs sharedroot without rhcs. 18:42:31 I don't see why we can't just vote on this feature now either, with the simple caveat that it should use dracut and all packages need to be in fedora 18:42:35 notting: Isn't btrfs from Oracle? Yet it's likely to become the next default FS. 18:42:57 We shouldn't assume we won't ever use something just because of who wrote it, nor even based on the current license (OpenJDK anyone? Licenses can change). 18:43:10 the layer is just for querying the cluster configuration 18:43:13 j-rod: its way incomplete for whats really needed 18:43:26 Kevin_Kofler: to use your earlier reductio ad absurdum argument, then we should write an abstraction layer for using windows libc. after all, they might open it. 18:43:33 well, if its still incomplete at feature freeze, then it doesn't get in 18:43:48 doesn't mean we can't approve the idea of the feature 18:44:08 dgilmore: right. but then i think that should be coordinated with the people already working on clustering... 18:44:14 don't be afraid to let features fail, just ensure they have a reasonable contingency plan 18:44:34 notting: ill agree to that 18:44:40 j-rod: +1 18:45:12 * nirik nods. I'd be ok with approving it based on it getting packages in and stuff merged. 18:45:26 if not, it goes to next release and contingency plan gets used. 18:45:36 Yeah. 18:46:00 ok, so basically, what say we vote on approving the feature w/the caveats that 1) it needs to use dracut, 2) all packages *must* be in fedora and 3) needs to be coordinated w/other cluster offerings and the people working on them 18:46:02 contingency plan is "we dont have this", since we're not switching out massive pieces of infrastructure 18:46:35 +1 to this feature with the contingencies that j-rod mentioned. 18:46:43 +1, same 18:46:45 +1 to j-rod 18:46:47 +1 18:46:50 * skvidal will brb 18:46:57 +1 from me, obviously 18:46:59 +1 i guess 18:47:08 +1 18:47:32 #agreed Opensharedroot is approved with the following caveats 1) it needs to use dracut, 2) all packages *must* be in fedora and 3) needs to be coordinated w/other cluster offerings and the people working on them 18:47:57 * notting votes 0 18:48:05 #topic virtgpxe feature 18:48:12 .fesco 184 18:48:23 +1 18:48:28 +1 18:48:30 etherboot is dead 18:48:34 +1 18:48:40 +1, the logic makes sense and it's already done. 18:48:40 cool stuff. 18:48:42 gpxe replaces it, no-brainer 18:48:42 +1 18:48:46 +1 18:48:46 +1 18:49:18 #agreed gpxe feature is accepted 18:49:23 +1 18:49:35 #topic XI2 feature 18:49:40 * j-rod has something at 3pm, hoping we can plow through the last few issues quick... :) 18:49:41 .fesco 185 18:49:44 +1 18:50:27 +1 no brainer again. Backward compat. 18:50:31 +1 18:50:39 +1 18:50:56 +1 18:51:08 +1 18:51:08 There's a new libXi, is that API-compatible? 18:51:13 Or will both versions be provided? 18:51:19 it's compatible. 18:51:36 OK, so +1 to the feature. 18:51:58 #agreed XI2 feature is accepted 18:52:14 #topic feature - yum langpack plugin 18:52:19 .fesco 186 18:52:51 This one needs changes to kde-i18n and kde-l10n which aren't listed under "Scope". 18:52:52 +1 18:53:15 Kevin_Kofler: true. although that should just be a Provides: additions 18:53:21 maybe they didnt know? 18:53:26 "when base packages with langpacks" 18:53:35 does that mean @base ? 18:54:15 Actually we already have some Provides which might be sufficient. 18:54:25 kde-l10n-German Provides: kde-l10n-de and same for the KDE 3 kde-i18n. 18:54:39 Kevin_Kofler: as long as the iso codes match, yeah, that should do it 18:55:08 +1 18:55:10 +1 here. 18:55:11 but... i'm still 0 on this. i'm concerned about the implementation and how it will work with anaconda and tree building 18:55:17 i wanna get through the last one. 18:55:22 +1 18:55:24 +1 to the feature. 18:55:31 notting: i'd like to know how it interacts with livecd creation too. 18:55:35 If any KDE changes are needed, I can take care of them. 18:55:49 let me rephrase. i'm -1 without more details 18:56:17 hrm. hadn't considered impact on livecd and anaconda tree building... 18:56:26 (KDE packaging changes ??? AIUI no changes to the desktops themselves are planned at this stage) 18:56:27 yeah 18:56:30 do those happen w/yum-utils installed? 18:56:46 can we defer til we get further info? 18:56:52 j-rod: they 'can'? i don't know if pungi uses plugins. anaconda would need code to use specific ones 18:57:15 ok, I'll go from +1 to 0, 'needinfo' 18:57:28 same here 18:57:54 So you're proposing to ask for more information and defer to next week? 18:57:58 yes 18:58:15 generally for it, but want to know that its not going to hose over livecd and anaconda in anyway 18:58:27 #agreed further information on the impact to pungi, anaconda, and livecd-tools is needed. 18:58:35 Yeah, 18:58:44 +1 to that (further info needed). 18:59:02 #topic VirtIO serial 18:59:06 The KDE Live CD should also be tested, we definitely don't want to have all the kde-l10n-* dragged in. 18:59:07 .fesco 187 18:59:16 last one 18:59:56 +1. seems uneventful. 18:59:56 +1 19:00:08 +1 19:00:08 +1 19:00:38 +1 19:00:45 +1 19:01:11 #agreed virtio serial feature is accepted. 19:01:24 that's all I had 19:01:39 +1 19:01:44 anyone else have anything pressing? 19:01:54 or can I put a fork in this? 19:02:01 fork it 19:02:08 #endmeeting From opensource at till.name Fri Jul 10 20:43:07 2009 From: opensource at till.name (Till Maas) Date: Fri, 10 Jul 2009 22:43:07 +0200 Subject: Packages tracked by FEver that need to be updated Message-ID: <200907102243.14776.opensource@till.name> Aloas, some of you added your packages to: https://fedoraproject.org/wiki/Using_FEver_to_track_upstream_changes Unfortunately seems the original author of fever not to be around anymore, e.g. his fedorapeople account is removed/backed-up. Therefore I started to write a new framework to replace it. My tool is not ready to bug you via private mail or create bug reports, therefore I only post the current findings here: Outdated packages: Name Rawhide Version < Upstream Version ======================================================= abook 0.6.0 < 0.6.0pre2 aria2 1.3.1 < 1.5.0b+20090705 bouml 4.13 < 4.13.1 bouml-doc 4.3.2 < 4.12.4 bti 015 < 023 bygfoot 2.2.0 < 2.2.1 chemtool 1.6.11 < 1.6.12 conduit 0.3.15 < 0.3.16 cpl 4.2.0 < 5.0.1 crm114 0 < 200904023 crossvc 1.5.2 < 1.5.2-0 ctorrent 1.3.4 < 1.3.4-dnh3 dblatex 0.2.10 < 0.2.11 debootstrap 1.0.10 < 1.0.13 ekg2 0.2 < 0.2-rc1 emacs-auctex 11.85 < 11.85-e22.3-msw Falcon 0.8.14.2 < 0.9.2 fdupes 1.50 < 1.50-PR2 fio 1.24 < 1.31 fusecompress 2.5 < 2.6 g2clib 1.1.8 < 1.1.9 gajim 0.12.1 < 0.12.3 gengetopt 2.22.1 < 2.22.2 gifsicle 1.52 < 1.55 glpk 4.36 < 4.38 guilt 0.32 < 0.32.1 gxine 0.5.903 < 0.5.904 hping3 0.0.20051105 < 20051105 hplip 3.9.2 < 3.9.6b httrack 3.43.2 < 3.43-5 kdesvn 1.3.0 < 1.3.2 ldtp 1.3.0 < 1.6.0 libedit 2.11 < 3.0 libextractor 0.5.22 < 0.5.23 libfplll 3.0.11 < 3.0.12 libtlen 0 < 20060309 lightning 1.2 < 1.2c mimetic 0.9.5 < 0.9.6rc2 mingw32-nsis 2.44 < 207b0 mkvtoolnix 2.6.0 < 2.9.7 mysqltuner 1.0.0 < 1.0.0-rc1 openbabel 2.2.1 < 2.2.2b6-20090709-r3138 perl-HTML-Template-Pro 0.74 < 0.75 perl-TAP-Harness-Archive 0.12 < 0.13 perl-Test-WWW-Selenium 1.15 < 1.17 perl-XML-Atom-SimpleFeed 0.82 < 0.86 php 5.2.10 < 5.3.0 php-pear-DB 1.7.13 < 1.7.14RC1 php-pecl-apc 3.0.19 < 3.1.2 python-sphinx 0.6.1 < 0.6.2 rapidsvn 0.9.8 < 0.9.8/ sextractor 2.5.0 < 2.8.6 sonata 1.5.2 < 1.6.2 sundials 2.3.0 < 2.4.0 tesseract 2.03 < 2.04 tor 0.2.0.34 < 0.2.0.35 tre 0.7.5 < 0.7.6 uncrustify 0.52 < 0.53 valknut 0.4.9 < 9 varconf 0.6.5 < 0.6.6 warzone2100 2.1.2 < 2.2.1 wgrib2 1.7.8g < 1.7.8j wormux 0.8.3 < 0.8.4 xchm 1.14 < 1.17 xcb-util 0.3.4 < 0.3.5 Packages new in Rawhide than at upstream (may indicate outdated FEver URL) Name Rawhide Version > Upstream Version ======================================================= a2ps 4.14 > 4.13 aircrack-ng 1.0 > 0.9.3 anjuta 2.26.1.0 > 2.25.903.0 centerim 4.22.7 > 4.22.6 cups 1.4 > 1.3.9 ekg 1.8 > 1.7 giggle 0.4.91 > 0.4 glade3 3.6.7 > 3.6.0 inkscape 0.47 > 0.46 kile 2.1 > 2.0.3 libgdl 2.26.0 > 0.7.11 milter-greylist 4.2.2 > 2.1.12 monotone 0.44 > 0.9 opencdk 0.6.6 > 0.6.0 pyicq-t 0.8.1.3 > 0.8b python-mutagen 1.16 > 1.15 strigi 0.6.5 > 0.5.11 sunbird 1.0 > 0.8 swing-layout 1.0.3 > 1 up-imapproxy 1.2.7 > 1.2.6 xalan-c 1.10.0 > 1.10 xmlrpc-c 1.16.6 > 1.06.35 Packages that could not be checked because of errors, i.e. non working URLs or missing information about latest release: cowsay inadyn newsx obexftp osmo Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From yersinia.spiros at gmail.com Fri Jul 10 21:29:43 2009 From: yersinia.spiros at gmail.com (yersinia) Date: Fri, 10 Jul 2009 23:29:43 +0200 Subject: prelink: is it worth it? In-Reply-To: <20090710081446.GX4462@tyan-ft48-01.lab.bos.redhat.com> References: <20090709143201.GA22885@jadzia.bu.edu> <4A5604EA.9090107@redhat.com> <20090709150820.GA26398@jadzia.bu.edu> <20090709151728.GU4462@tyan-ft48-01.lab.bos.redhat.com> <200907100808.n6A88nlr021446@tiffany.internal.tigress.co.uk> <20090710081446.GX4462@tyan-ft48-01.lab.bos.redhat.com> Message-ID: On Fri, Jul 10, 2009 at 10:14 AM, Jakub Jelinek wrote: > On Fri, Jul 10, 2009 at 09:08:49AM +0100, Ron Yorston wrote: > > Jakub Jelinek wrote: > > >Also, while prelink process has been fairly expensive some years ago, it > is > > >much faster these days; if you haven't installed any rpms in the last > day, > > >most of the days the cron job will just quit, if you have installed > some, > > >for libraries/binaries that don't need reprelinking it will just do a > quick > > >stat and nothing else, and even a full prelink takes just a minute or > two. > > > > So what got faster, prelink or hardware? > > > > My experience, some years ago, was that a full prelink took 35-40 > minutes. > > Since I didn't see any visible difference in performance I added "turn > off > > prelink" to my list of things to do after installing Fedore. > > Both. prelink's C++ optimizations used to be quite time consuming, > that has been fixed, also there were changes to avoid reading all libraries > and binaries, even when those haven't changed since last prelinking and > don't need prelinking even now. > Ok. But prelink it or not a requisite for ASLR or not ? In other word, besides performance is disabling prelink a security matter or not ? It is not bad to have some answer on this. Regards > > Jakub > > -- > 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 joshuacov at googlemail.com Fri Jul 10 21:58:37 2009 From: joshuacov at googlemail.com (Joshua C.) Date: Fri, 10 Jul 2009 17:58:37 -0400 Subject: x86_64 packages depends on i586. Message-ID: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> I made a custom x86_64 livecd (f11) and found that the following x86_64 packages depend on i586 and i686. Is this an error when compiling those packages or they do need the 32 bits? mesa-libGL-devel.x86_64 needs glibc.i686 libdrm.i586 libdrm-devel.i586 nss-softokn-freebl.i586 pulseaudio-module-x11.x86_64 needs alsa-lib.i586 dbus-libs.i586 e2fsprogs-libs.i586 flac.i586 gdbm.i586 glibc.i586 libICE.i586 libSM.i586 libX11.i586 libXau.i586 libXext.i586 libXtst.i586 libasyncns.i586 libattr.i586 libcap.i586 libgcc.i586 libogg.i586 libsndfile.i586 libstdc++.i586 libxcb.i586 ncurses-libs.i586 nss-softokn-freebl.i586 pulseaudio-libs.i586 pulseaudio-utils.i586 readline.i586 sqlite.i586 tcp_wrappers-libs.i586 I also found dupllicates of NetworkManager x86_64 and .i586 and others. I wanted some -devel packages but I thought only the x86_64 versions would be pulled in. How have this happened? From jonathan.underwood at gmail.com Fri Jul 10 22:02:33 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 10 Jul 2009 23:02:33 +0100 Subject: Fail2ban + Shorewall Question In-Reply-To: <08257EB7-9DC9-402A-B749-FD0D4D91CBBE@5dollarwhitebox.org> References: <08257EB7-9DC9-402A-B749-FD0D4D91CBBE@5dollarwhitebox.org> Message-ID: <645d17210907101502x7fae7b9dvd8305abf26ac2c97@mail.gmail.com> 2009/7/10 BJ Dierkes : > Hello all, > I originally posted this on the epel-devel-list, but was referred by the > EPEL maintainer of fail2ban to bring the discussion upstream to Fedora in > hopes of convincing the Fedora maintainer of fail2ban to make these changes. > ?The following was my original message: > --- > I bring this to the list being that the issue isn't necessarily a bug, > rather a concern about implementation. ?Per the documentation > [http://www.fail2ban.org/wiki/index.php/MANUAL_0_8] fail2ban is _capable_ of > supporting shorewall (among other things) and even states that "the > following software is optional but recommended" with reference to shorewall. > ?However, fail2ban does not _require_ shorewall to function. > > That said, having a 'Requires: shorewall' in the fail2ban spec seems > unnecessary and in my opinion improper. ?Breaking the package out into a sub > package doesn't seem necessary either... ?being that the only file(s) I see > that could be split off would be: https://bugzilla.redhat.com/show_bug.cgi?id=244275 > > ]# rpm -ql fail2ban | grep shorewall > /etc/fail2ban/action.d/shorewall.conf > > > Regardless, for the sake of those that have no interest in shorewall (and in > particular those that want to avoid having to support shorewall) I'd like to > suggest that fail2ban-shorewall be broken off in a sub-package or simply > drop the Requires: shorewall completely so that the dependency of shorewall > is only enacted when desired (or not at all). > > Thoughts? > > Thank you for your time. > > --- > derks > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From rjones at redhat.com Fri Jul 10 22:10:10 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 10 Jul 2009 23:10:10 +0100 Subject: New parted release update. In-Reply-To: <20090710132706.GB3552@dhcp-lab-171.englab.brq.redhat.com> References: <20090710132706.GB3552@dhcp-lab-171.englab.brq.redhat.com> Message-ID: <20090710221010.GA2053@amd.home.annexia.org> On Fri, Jul 10, 2009 at 03:27:06PM +0200, Joel Granados wrote: > Packages that might need rebuilding: > > > # repoquery --repoid rawhide --whatrequires --alldeps parted [...] > nash-0:6.0.91-1 [...] > libvirt-0:0.6.5-1 I rebuilt libvirt, and was going to rebuild nash (ie. mkinitrd) but noticed that spot got there first. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 75 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From jakub at redhat.com Fri Jul 10 22:26:24 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Sat, 11 Jul 2009 00:26:24 +0200 Subject: prelink: is it worth it? In-Reply-To: References: <20090709143201.GA22885@jadzia.bu.edu> <4A5604EA.9090107@redhat.com> <20090709150820.GA26398@jadzia.bu.edu> <20090709151728.GU4462@tyan-ft48-01.lab.bos.redhat.com> <200907100808.n6A88nlr021446@tiffany.internal.tigress.co.uk> <20090710081446.GX4462@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <20090710222622.GB4462@tyan-ft48-01.lab.bos.redhat.com> On Fri, Jul 10, 2009 at 11:29:43PM +0200, yersinia wrote: > Ok. But prelink it or not a requisite for ASLR or not ? In other word, > besides performance > is disabling prelink a security matter or not ? It is not bad to have some > answer on this. ASLR happens with prelink or without. Particularly, PIEs (should be used for most of suid/network facing or otherwise security exposed programs) are always randomized, both the binary itself and all shared libraries it uses. Other than that, on prelinked system libraries are assigned random addresses whenever reprelinked, while when not prelinked, libraries are given random addresses on every exec. Non-PIE binaries have always fixed address. Jakub From yersinia.spiros at gmail.com Fri Jul 10 22:36:32 2009 From: yersinia.spiros at gmail.com (yersinia) Date: Sat, 11 Jul 2009 00:36:32 +0200 Subject: prelink: is it worth it? In-Reply-To: <20090710222622.GB4462@tyan-ft48-01.lab.bos.redhat.com> References: <20090709143201.GA22885@jadzia.bu.edu> <4A5604EA.9090107@redhat.com> <20090709150820.GA26398@jadzia.bu.edu> <20090709151728.GU4462@tyan-ft48-01.lab.bos.redhat.com> <200907100808.n6A88nlr021446@tiffany.internal.tigress.co.uk> <20090710081446.GX4462@tyan-ft48-01.lab.bos.redhat.com> <20090710222622.GB4462@tyan-ft48-01.lab.bos.redhat.com> Message-ID: On Sat, Jul 11, 2009 at 12:26 AM, Jakub Jelinek wrote: > On Fri, Jul 10, 2009 at 11:29:43PM +0200, yersinia wrote: > > Ok. But prelink it or not a requisite for ASLR or not ? In other word, > > besides performance > > is disabling prelink a security matter or not ? It is not bad to have > some > > answer on this. > > ASLR happens with prelink or without. Particularly, PIEs (should be used > for most of suid/network facing or otherwise security exposed programs) are > always randomized, both the binary itself and all shared libraries it uses. > > Other than that, on prelinked system libraries are assigned random > addresses > whenever reprelinked, while when not prelinked, libraries are given random > addresses on every exec. Non-PIE binaries have always fixed address. > > Jakub > Thank a lot for your answer: this was a delicate and very interesting issue, for me almost. Best regards > > -- > 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 tcallawa at redhat.com Fri Jul 10 22:20:49 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 10 Jul 2009 18:20:49 -0400 Subject: Open Seat on the Fedora Packaging Committee Message-ID: <4A57BEC1.1010000@redhat.com> The Fedora Packaging Committee has an open seat. Are you interested in helping to decide the packaging standards and guidelines for Fedora? Are you familiar with the inner workings of RPM and its spec file magic? Are you clinically insane? (Well, the last one isn't mandatory, but it helps.) Members of the Fedora Packaging Committee get: * My neverending gratitude * The ability to tell people "I'm on the Fedora Packaging Committee" * Good karma The FPC meets biweekly. In theory. (In practice, we meet less than that). If you're interested in this seat, please email me. ~spot _______________________________________________ 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 Fri Jul 10 22:54:49 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 10 Jul 2009 18:54:49 -0400 Subject: x86_64 packages depends on i586. In-Reply-To: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> Message-ID: <4A57C6B9.5000702@redhat.com> On 07/10/2009 05:58 PM, Joshua C. wrote: > I made a custom x86_64 livecd (f11) and found that the following > x86_64 packages depend on i586 and i686. Is this an error when > compiling those packages or they do need the 32 bits? > > mesa-libGL-devel.x86_64 needs > > glibc.i686 > libdrm.i586 > libdrm-devel.i586 > nss-softokn-freebl.i586 > pulseaudio-module-x11.x86_64 needs > > alsa-lib.i586 > dbus-libs.i586 > e2fsprogs-libs.i586 > flac.i586 > gdbm.i586 > glibc.i586 > libICE.i586 > libSM.i586 > libX11.i586 > libXau.i586 > libXext.i586 > libXtst.i586 > libasyncns.i586 > libattr.i586 > libcap.i586 > libgcc.i586 > libogg.i586 > libsndfile.i586 > libstdc++.i586 > libxcb.i586 > ncurses-libs.i586 > nss-softokn-freebl.i586 > pulseaudio-libs.i586 > pulseaudio-utils.i586 > readline.i586 > sqlite.i586 > tcp_wrappers-libs.i586 I'm pretty sure you're looking at it wrong. [spot at velociraptor devel]$ rpm -q mesa-libGL-devel.x86_64 --requires /usr/bin/pkg-config libGL.so.1()(64bit) libX11-devel mesa-libGL = 7.5-0.14.fc11 pkgconfig(dri2proto) >= 1.99.3 pkgconfig(libdrm) >= 2.4.3 pkgconfig(x11) pkgconfig(xdamage) pkgconfig(xext) pkgconfig(xfixes) pkgconfig(xxf86vm) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) <= 3.0.3-1 [spot at velociraptor devel]$ rpm -q pulseaudio-module-x11.x86_64 --requires /bin/sh config(pulseaudio-module-x11) = 0.9.16-2.test2.fc12 libICE.so.6()(64bit) libSM.so.6()(64bit) libX11.so.6()(64bit) libXtst.so.6()(64bit) libasyncns.so.0()(64bit) libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libdbus-1.so.3()(64bit) libdl.so.2()(64bit) libltdl.so.7()(64bit) libm.so.6()(64bit) liboil-0.3.so.0()(64bit) libprotocol-native.so()(64bit) libpthread.so.0()(64bit) libpulse.so.0()(64bit) libpulse.so.0(PULSE_0)(64bit) libpulsecommon-0.9.16.so()(64bit) libpulsecore-0.9.16.so()(64bit) librt.so.1()(64bit) libsamplerate.so.0()(64bit) libsndfile.so.1()(64bit) libspeexdsp.so.1()(64bit) libtdb.so.1()(64bit) libwrap.so.0()(64bit) pulseaudio = 0.9.16-2.test2.fc12 pulseaudio-utils = 0.9.16-2.test2.fc12 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rtld(GNU_HASH) > I also found dupllicates of NetworkManager x86_64 and .i586 and > others. I wanted some -devel packages but I thought only the x86_64 > versions would be pulled in. > > How have this happened? Not sure how you managed it, but the packages themselves are correct. ~spot From rjune at bravegnuworld.com Sat Jul 11 04:46:03 2009 From: rjune at bravegnuworld.com (Richard June) Date: Fri, 10 Jul 2009 23:46:03 -0500 Subject: Open Seat on the Fedora Packaging Committee In-Reply-To: <4A57BEC1.1010000@redhat.com> References: <4A57BEC1.1010000@redhat.com> Message-ID: <1247287565.6470.1.camel@firbolg.bravegnuworld.com> I'm interested, I have packaged for Livna, YellowDog, and ran my own repository that built for fedora, centos, yellowdog, and suse. On Fri, 2009-07-10 at 18:20 -0400, Tom "spot" Callaway wrote: > The Fedora Packaging Committee has an open seat. Are you interested in > helping to decide the packaging standards and guidelines for Fedora? Are > you familiar with the inner workings of RPM and its spec file magic? Are > you clinically insane? (Well, the last one isn't mandatory, but it helps.) > > Members of the Fedora Packaging Committee get: > * My neverending gratitude > * The ability to tell people "I'm on the Fedora Packaging Committee" > * Good karma > > The FPC meets biweekly. In theory. (In practice, we meet less than that). > > If you're interested in this seat, please email me. > > ~spot > > _______________________________________________ > Fedora-devel-announce mailing list > Fedora-devel-announce at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-announce > From frankly3d at gmail.com Sat Jul 11 05:19:24 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Sat, 11 Jul 2009 06:19:24 +0100 Subject: Open Seat on the Fedora Packaging Committee In-Reply-To: <1247287565.6470.1.camel@firbolg.bravegnuworld.com> References: <4A57BEC1.1010000@redhat.com> <1247287565.6470.1.camel@firbolg.bravegnuworld.com> Message-ID: <4A5820DC.8050702@gmail.com> On 11/07/09 05:46, Richard June wrote: > I'm interested, I have packaged for Livna, YellowDog, and ran my own > repository that built for fedora, centos, yellowdog, and suse. > I think the plan was to send "Spot" an email ;) Regards, Frank From joshuacov at googlemail.com Sat Jul 11 07:38:17 2009 From: joshuacov at googlemail.com (Joshua C.) Date: Sat, 11 Jul 2009 08:38:17 +0100 Subject: x86_64 packages depends on i586. In-Reply-To: <4A57C6B9.5000702@redhat.com> References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> Message-ID: <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> 2009/7/10 Tom "spot" Callaway : > On 07/10/2009 05:58 PM, Joshua C. wrote: >> I made a custom x86_64 livecd (f11) and found that the following >> x86_64 packages depend on i586 and i686. Is this an error when >> compiling those packages or they do need the 32 bits? >> >> ?mesa-libGL-devel.x86_64 needs >> >> ?glibc.i686 >> ?libdrm.i586 >> ?libdrm-devel.i586 >> ?nss-softokn-freebl.i586 > >> ?pulseaudio-module-x11.x86_64 ?needs >> >> ?alsa-lib.i586 >> ?dbus-libs.i586 >> ?e2fsprogs-libs.i586 >> ?flac.i586 >> ?gdbm.i586 >> ?glibc.i586 >> ?libICE.i586 >> ?libSM.i586 >> ?libX11.i586 >> ?libXau.i586 >> ?libXext.i586 >> ?libXtst.i586 >> ?libasyncns.i586 >> ?libattr.i586 >> ?libcap.i586 >> ?libgcc.i586 >> ?libogg.i586 >> ?libsndfile.i586 >> ?libstdc++.i586 >> ?libxcb.i586 >> ?ncurses-libs.i586 >> ?nss-softokn-freebl.i586 >> ?pulseaudio-libs.i586 >> ?pulseaudio-utils.i586 >> ?readline.i586 >> ?sqlite.i586 >> ?tcp_wrappers-libs.i586 > > I'm pretty sure you're looking at it wrong. > > [spot at velociraptor devel]$ rpm -q mesa-libGL-devel.x86_64 --requires > /usr/bin/pkg-config > libGL.so.1()(64bit) > libX11-devel > mesa-libGL = 7.5-0.14.fc11 > pkgconfig(dri2proto) >= 1.99.3 > pkgconfig(libdrm) >= 2.4.3 > pkgconfig(x11) > pkgconfig(xdamage) > pkgconfig(xext) > pkgconfig(xfixes) > pkgconfig(xxf86vm) > rpmlib(CompressedFileNames) <= 3.0.4-1 > rpmlib(FileDigests) <= 4.6.0-1 > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > rpmlib(VersionedDependencies) <= 3.0.3-1 > > [spot at velociraptor devel]$ rpm -q pulseaudio-module-x11.x86_64 --requires > /bin/sh > config(pulseaudio-module-x11) = 0.9.16-2.test2.fc12 > libICE.so.6()(64bit) > libSM.so.6()(64bit) > libX11.so.6()(64bit) > libXtst.so.6()(64bit) > libasyncns.so.0()(64bit) > libc.so.6()(64bit) > libc.so.6(GLIBC_2.2.5)(64bit) > libdbus-1.so.3()(64bit) > libdl.so.2()(64bit) > libltdl.so.7()(64bit) > libm.so.6()(64bit) > liboil-0.3.so.0()(64bit) > libprotocol-native.so()(64bit) > libpthread.so.0()(64bit) > libpulse.so.0()(64bit) > libpulse.so.0(PULSE_0)(64bit) > libpulsecommon-0.9.16.so()(64bit) > libpulsecore-0.9.16.so()(64bit) > librt.so.1()(64bit) > libsamplerate.so.0()(64bit) > libsndfile.so.1()(64bit) > libspeexdsp.so.1()(64bit) > libtdb.so.1()(64bit) > libwrap.so.0()(64bit) > pulseaudio = 0.9.16-2.test2.fc12 > pulseaudio-utils = 0.9.16-2.test2.fc12 > rpmlib(CompressedFileNames) <= 3.0.4-1 > rpmlib(FileDigests) <= 4.6.0-1 > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > rtld(GNU_HASH) > >> I also found dupllicates of NetworkManager x86_64 and .i586 and >> others. I wanted some -devel packages but I thought only the x86_64 >> versions would be pulled in. >> >> How have this happened? > > Not sure how you managed it, but the packages themselves are correct. > > ~spot > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I don't know but when I try to install one of those x86_64 packages it pulls the i586 as dependencies. I've pointed all repo files to x86_64 and I really don't know how and why this happens? From rc040203 at freenet.de Sat Jul 11 08:21:51 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 11 Jul 2009 10:21:51 +0200 Subject: How to properly name a cross-toolchain package? In-Reply-To: References: Message-ID: <4A584B9F.2010506@freenet.de> Peter Lemenkov wrote: > Hello All! > > I plan to add arm-toolchain into Fedora and encountered a difficulty - > how to properly name the package? From what I found in the Internets, > the cross-toolchains *often* named with the following prefix: > > ---- > > For example: > > i686-pc-linux-gnu- > powerpc-unknown-linux-gnu- > x86_64-unknown-linux-gnu- > > http://www.gentoo.org/proj/en/base/embedded/handbook/?part=1&chap=3 > > However sometimes they named differently (arm-none-eabi-, > arm-uclinuxeabi-, etc). Some cross-compilers already included into > Fedora, and their packages naming schemes are also different - some > examples of prefixes are arm-gp2x-linux-, avr-, msp430-, spu- > (mingw32 differs from others because it, at least, implies target OS > and libc). > > I'm sure, it's time to create unified rules for packaging of > cross-toolchains, but right now I'm asking you for help in proper > naming of it. Should we name it as -- system>--gcc IM(NS)HO: basically yes. It's the clearest and least confusing from. > or should we use some other naming schemes? What > values should be used for - "fedora" maybe? No. > O should we simply drop this field ("unknown")? No. GCC's canonicalization triples (the triples passed as --target=<..> when configuring a cross-toolchain) are standardized and can not be chosen at random. What occasionally confuses people is the fact that for some targets abbreviations exist rsp. and that theses triples exit in an "external" (often abbreviated) and "internal" (fully expanded) form. Ralf From rc040203 at freenet.de Sat Jul 11 08:27:15 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 11 Jul 2009 10:27:15 +0200 Subject: an update to automake-1.11? In-Reply-To: <20090704222252.GA10230@amd.home.annexia.org> References: <1246385157.8362.127.camel@localhost.localdomain> <20090630213457.GC22149@redhat.com> <4A4AF47D.8030503@freenet.de> <20090701101514.GB19903@camelia.ucw.cz> <4A4B3D2C.60000@freenet.de> <20090704222252.GA10230@amd.home.annexia.org> Message-ID: <4A584CE3.1000700@freenet.de> Richard W.M. Jones wrote: > On Wed, Jul 01, 2009 at 12:40:44PM +0200, Ralf Corsepius wrote: >> No, not if they bundle the generated auto* files with their tarballs, as >> they are supposed to do. > > They're not "supposed to do" that. Wrong. > Don't make stuff up. Read the manuals, then come back. From jussilehtola at fedoraproject.org Sat Jul 11 09:41:28 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Sat, 11 Jul 2009 12:41:28 +0300 Subject: x86_64 packages depends on i586. In-Reply-To: <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> Message-ID: <1247305288.2599.2.camel@localhost.localdomain> On Sat, 2009-07-11 at 08:38 +0100, Joshua C. wrote: > 2009/7/10 Tom "spot" Callaway : > > On 07/10/2009 05:58 PM, Joshua C. wrote: > >> I made a custom x86_64 livecd (f11) and found that the following > >> x86_64 packages depend on i586 and i686. Is this an error when > >> compiling those packages or they do need the 32 bits? > > > > I'm pretty sure you're looking at it wrong. > I don't know but when I try to install one of those x86_64 packages it > pulls the i586 as dependencies. I've pointed all repo files to x86_64 > and I really don't know how and why this happens? The x86_64 repo contains some multilib packages. If you don't specify the wanted architecture when installing, yum might install both 32- and 64-bit versions if available. Try adding the .x86_64 arch specifier, e.g. instead of # yum install foo perform # yum install foo.x86_64 -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From joshuacov at googlemail.com Sat Jul 11 09:52:20 2009 From: joshuacov at googlemail.com (Joshua C.) Date: Sat, 11 Jul 2009 10:52:20 +0100 Subject: x86_64 packages depends on i586. In-Reply-To: <1247305288.2599.2.camel@localhost.localdomain> References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> <1247305288.2599.2.camel@localhost.localdomain> Message-ID: <5f6f8c5f0907110252n4f4f4fabo31d4a0e67d7fbc4@mail.gmail.com> 2009/7/11 Jussi Lehtola : > > The x86_64 repo contains some multilib packages. If you don't specify > the wanted architecture when installing, yum might install both 32- and > 64-bit versions if available. Try adding the .x86_64 arch specifier, > e.g. instead of > # yum install foo > perform > # yum install foo.x86_64 > -- > Jussi Lehtola > Fedora Project Contributor > jussilehtola at fedoraproject.org I also noticed this. The problem is that I use the spin-kickstarts files and there groups of files are specified with @core. When the livecd-creator see this, maybe it pulls all files that much the given name regardless of the architecture. But I still cannot explain why when running the livecd and trying to install some of the files (in the first thread), yum still pulls the i586 as dependencies. Should I file a bug against yum (or livecd-creator) so that they respect the given architecture? From debarshi.ray at gmail.com Sat Jul 11 10:52:30 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Sat, 11 Jul 2009 16:22:30 +0530 Subject: Packages tracked by FEver that need to be updated In-Reply-To: <200907102243.14776.opensource@till.name> References: <200907102243.14776.opensource@till.name> Message-ID: <3170f42f0907110352g73269129r395fe2dfe84def3c@mail.gmail.com> Thank you very much for doing this. Happy hacking, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig From debarshi.ray at gmail.com Sat Jul 11 11:06:19 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Sat, 11 Jul 2009 16:36:19 +0530 Subject: Champlain Message-ID: <3170f42f0907110406v46117b12mdc102bcf085cb882@mail.gmail.com> I am going to update libchamplain from 0.2.9 to 0.3.3 in Fedora 11. This involves a change in the soname, but since no other package depends on it I hope it would not be a problem. On the plus side, the GtkChamplainEmbed widget which was earlier separately released has been merged into the libchamplain tarball and we can put in a subpackage. Not to mention that potential Champlain users and developers will find this helpful. What do you think? Happy hacking, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig From rakesh.pandit at gmail.com Sat Jul 11 11:29:59 2009 From: rakesh.pandit at gmail.com (Rakesh Pandit) Date: Sat, 11 Jul 2009 16:59:59 +0530 Subject: Packages tracked by FEver that need to be updated In-Reply-To: <200907102243.14776.opensource@till.name> References: <200907102243.14776.opensource@till.name> Message-ID: 2009/7/11 Till Maas wrote: > Aloas, > > some of you added your packages to: > https://fedoraproject.org/wiki/Using_FEver_to_track_upstream_changes > > Unfortunately seems the original author of fever not to be around anymore, > e.g. his fedorapeople account is removed/backed-up. Therefore I started to > write a new framework to replace it. My tool is not ready to bug you via > private mail or create bug reports, therefore I only post the current findings > here: > Thanks for nice work. I too mailed other some time back .. but did not recieved any mail back. May you share the program ;) Thanks, -- Regards, Rakesh Pandit From bpepple at fedoraproject.org Sat Jul 11 12:37:49 2009 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sat, 11 Jul 2009 08:37:49 -0400 Subject: Champlain In-Reply-To: <3170f42f0907110406v46117b12mdc102bcf085cb882@mail.gmail.com> References: <3170f42f0907110406v46117b12mdc102bcf085cb882@mail.gmail.com> Message-ID: <1247315869.2774.4.camel@localhost.localdomain> On Sat, 2009-07-11 at 16:36 +0530, Debarshi Ray wrote: > I am going to update libchamplain from 0.2.9 to 0.3.3 in Fedora 11. > This involves a change in the soname, but since no other package > depends on it I hope it would not be a problem. On the plus side, the > GtkChamplainEmbed widget which was earlier separately released has > been merged into the libchamplain tarball and we can put in a > subpackage. Not to mention that potential Champlain users and > developers will find this helpful. > > What do you think? I've been working on updating libchamplain to 0.3.3 in Rawhide, but until it gets ported to the clutter-0.9 api (or we do a clutter-0.8 compat) it's a no go for now. Regarding pushing this to F11, I really don't think we should, since the only real consumer of libchamplain is Empathy and we won't be pushing a version of it with libchamplain support to F11. Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mschwendt at gmail.com Sat Jul 11 12:58:30 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 11 Jul 2009 14:58:30 +0200 Subject: Champlain In-Reply-To: <1247315869.2774.4.camel@localhost.localdomain> References: <3170f42f0907110406v46117b12mdc102bcf085cb882@mail.gmail.com> <1247315869.2774.4.camel@localhost.localdomain> Message-ID: <20090711145830.27634ec7@faldor> On Sat, 11 Jul 2009 08:37:49 -0400, Brian wrote: > I've been working on updating libchamplain to 0.3.3 in Rawhide, but > until it gets ported to the clutter-0.9 api (or we do a clutter-0.8 > compat) it's a no go for now. Regarding pushing this to F11, I really > don't think we should, since the only real consumer of libchamplain is > Empathy and we won't be pushing a version of it with libchamplain > support to F11. Geeqie could use it (and libchamplain-gtk) too, but requires >= 0.3.0. From debarshi.ray at gmail.com Sat Jul 11 12:55:17 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Sat, 11 Jul 2009 18:25:17 +0530 Subject: Champlain In-Reply-To: <1247315869.2774.4.camel@localhost.localdomain> References: <3170f42f0907110406v46117b12mdc102bcf085cb882@mail.gmail.com> <1247315869.2774.4.camel@localhost.localdomain> Message-ID: <3170f42f0907110555t56c4ce34u76254bb797360b29@mail.gmail.com> > I've been working on updating libchamplain to 0.3.3 in Rawhide, but > until it gets ported to the clutter-0.9 api (or we do a clutter-0.8 > compat) it's a no go for now. That is also what I was waiting for. > Regarding pushing this to F11, I really > don't think we should, since the only real consumer of libchamplain is > Empathy There is a Eye of GNOME plugin too. > and we won't be pushing a version of it with libchamplain > support to F11. So no one is affected by this change. On the other hand, 0.2.x is old and 0.3.x is where the fun is. So atleast some developers would benefit from it and libchamplain-0.3 would also get some testing leading to a better 0.4.x. Cheers, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig From bpepple at fedoraproject.org Sat Jul 11 13:01:25 2009 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sat, 11 Jul 2009 09:01:25 -0400 Subject: Champlain In-Reply-To: <3170f42f0907110555t56c4ce34u76254bb797360b29@mail.gmail.com> References: <3170f42f0907110406v46117b12mdc102bcf085cb882@mail.gmail.com> <1247315869.2774.4.camel@localhost.localdomain> <3170f42f0907110555t56c4ce34u76254bb797360b29@mail.gmail.com> Message-ID: <1247317285.3215.2.camel@localhost.localdomain> On Sat, 2009-07-11 at 18:25 +0530, Debarshi Ray wrote: > > So no one is affected by this change. On the other hand, 0.2.x is old > and 0.3.x is where the fun is. So atleast some developers would > benefit from it and libchamplain-0.3 would also get some testing > leading to a better 0.4.x. Since the are some consumers that could make use of it that I wasn't aware of, it's probably worth it (assuming we also update Rawhide, so we don't have NVR issues). Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kanarip at kanarip.com Sat Jul 11 13:03:29 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 11 Jul 2009 15:03:29 +0200 Subject: FESCo meeting summary for 2009-07-10 In-Reply-To: References: Message-ID: <4A588DA1.1050509@kanarip.com> On 07/10/2009 09:04 PM, Jon Stanley wrote: > 18:08:49 #topic Feature - extended lifecycle (...snip...) > 18:15:31 jds2001, we have majority vote to move to the Board I'm interested to know what the follow-up on this would be; Is it added to the board's agenda? Also, I would appreciate if the verdict goes in the ticket; https://fedorahosted.org/fesco/ticket/180 Thanks! Kind regards, Jeroen van Meeuwen -kanarip From denis at poolshark.org Sat Jul 11 13:22:15 2009 From: denis at poolshark.org (Denis Leroy) Date: Sat, 11 Jul 2009 15:22:15 +0200 Subject: Champlain In-Reply-To: <1247315869.2774.4.camel@localhost.localdomain> References: <3170f42f0907110406v46117b12mdc102bcf085cb882@mail.gmail.com> <1247315869.2774.4.camel@localhost.localdomain> Message-ID: <4A589207.4010406@poolshark.org> On 07/11/2009 02:37 PM, Brian Pepple wrote: > I've been working on updating libchamplain to 0.3.3 in Rawhide, but > until it gets ported to the clutter-0.9 api (or we do a clutter-0.8 > compat) it's a no go for now. I've been told to expect clutter 1.0 real soon (tm) :-) From rjune at bravegnuworld.com Sat Jul 11 13:39:08 2009 From: rjune at bravegnuworld.com (Richard June) Date: Sat, 11 Jul 2009 08:39:08 -0500 Subject: Open Seat on the Fedora Packaging Committee In-Reply-To: <4A5820DC.8050702@gmail.com> Message-ID: <67cc46537dc28f38d9fb85b18e59b865@www.bravegnuworld.com> Doh! teach me for not watching my mail client more carefully. ----------------original message----------------- From: "Frank Murphy" frankly3d at gmail.com To: fedora-devel-list at redhat.com Date: Sat, 11 Jul 2009 06:19:24 +0100 ------------------------------------------------- > On 11/07/09 05:46, Richard June wrote: >> I'm interested, I have packaged for Livna, YellowDog, and ran my own >> repository that built for fedora, centos, yellowdog, and suse. >> > > I think the plan was to send "Spot" an email ;) > > Regards, > > Frank > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From kevin.kofler at chello.at Sat Jul 11 13:43:21 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 11 Jul 2009 15:43:21 +0200 Subject: Conditionally applying a patch based on a program's EVR References: Message-ID: Alan Dunn wrote: > but is there an easy way to do this for a version number in say, EVR > form? That is, something like > > %if %{program_version} > 1.2.3 > ... > %endif Just figure out the Fedora releases with that version and conditionalize based on the Fedora release. If the required version was released as an update, you can use a versioned BuildRequires and/or Requires to enforce the minimum version (at build time and at run time, respectively). Kevin Kofler From kevin.kofler at chello.at Sat Jul 11 13:44:44 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 11 Jul 2009 15:44:44 +0200 Subject: 3Dsee.net java applet crashes firefox References: <9497e9990907091415m41fa3256m3c10f1d15df7f188@mail.gmail.com> <9497e9990907091429h6283e62cmf06be94b162e3c86@mail.gmail.com> Message-ID: Mat Booth wrote: > Though after a little thought, it could be the proprietary nvidia > driver I'm using. It most definitely is. Yet another nvidia driver bug... Kevin Kofler From sundaram at fedoraproject.org Sat Jul 11 14:04:22 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 11 Jul 2009 19:34:22 +0530 Subject: Fail2ban + Shorewall Question In-Reply-To: <645d17210907101502x7fae7b9dvd8305abf26ac2c97@mail.gmail.com> References: <08257EB7-9DC9-402A-B749-FD0D4D91CBBE@5dollarwhitebox.org> <645d17210907101502x7fae7b9dvd8305abf26ac2c97@mail.gmail.com> Message-ID: <4A589BE6.5090305@fedoraproject.org> On 07/11/2009 03:32 AM, Jonathan Underwood wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=244275 Wow. A simple spec file change and a rebuild has been waiting for 2 years now? Rahul From kevin.kofler at chello.at Sat Jul 11 14:23:37 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 11 Jul 2009 16:23:37 +0200 Subject: Packages tracked by FEver that need to be updated References: <200907102243.14776.opensource@till.name> Message-ID: Till Maas wrote: > mingw32-nsis 2.44 < 207b0 Hmmm, the regex is somehow picking up something broken. The current version is actually 2.45. I should probably make it read http://nsis.sourceforge.net/Download instead. Kevin Kofler From opensource at till.name Sat Jul 11 15:35:10 2009 From: opensource at till.name (Till Maas) Date: Sat, 11 Jul 2009 17:35:10 +0200 Subject: Packages tracked by FEver that need to be updated In-Reply-To: References: <200907102243.14776.opensource@till.name> Message-ID: <200907111735.17615.opensource@till.name> On Sat July 11 2009, Kevin Kofler wrote: > Till Maas wrote: > > mingw32-nsis 2.44 < 207b0 > > Hmmm, the regex is somehow picking up something broken. The current version > is actually 2.45. I should probably make it read > http://nsis.sourceforge.net/Download instead. In 2005 they released a tarball named "nsis-207b0-src.tar.bz2". With the other URL it works, therefore I changed it. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From sandeen at redhat.com Sat Jul 11 16:05:38 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Sat, 11 Jul 2009 11:05:38 -0500 Subject: Packages tracked by FEver that need to be updated In-Reply-To: <200907102243.14776.opensource@till.name> References: <200907102243.14776.opensource@till.name> Message-ID: <4A58B852.8000205@redhat.com> Till Maas wrote: > Aloas, > > some of you added your packages to: > https://fedoraproject.org/wiki/Using_FEver_to_track_upstream_changes > > Unfortunately seems the original author of fever not to be around anymore, > e.g. his fedorapeople account is removed/backed-up. Therefore I started to > write a new framework to replace it. My tool is not ready to bug you via > private mail or create bug reports, therefore I only post the current findings > here: Thanks! I wonder, can FEver become part of the Fedora infrastructure, so it's not quite so bus-sensitive? -Eric From frankly3d at gmail.com Sat Jul 11 16:18:26 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Sat, 11 Jul 2009 17:18:26 +0100 Subject: x86_64 packages depends on i586. In-Reply-To: <1247305288.2599.2.camel@localhost.localdomain> References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> <1247305288.2599.2.camel@localhost.localdomain> Message-ID: <4A58BB52.8070005@gmail.com> On 11/07/09 10:41, Jussi Lehtola wrote: > > The x86_64 repo contains some multilib packages. If you don't specify > the wanted architecture when installing, yum might install both 32- and > 64-bit versions if available. Try adding the .x86_64 arch specifier, > e.g. instead of > # yum install foo > perform > # yum install foo.x86_64 Doesn't seem to work for wine :) Regards, Frank From opensource at till.name Sat Jul 11 16:25:33 2009 From: opensource at till.name (Till Maas) Date: Sat, 11 Jul 2009 18:25:33 +0200 Subject: Packages tracked by FEver that need to be updated In-Reply-To: <4A58B852.8000205@redhat.com> References: <200907102243.14776.opensource@till.name> <4A58B852.8000205@redhat.com> Message-ID: <200907111825.41242.opensource@till.name> On Sat July 11 2009, Eric Sandeen wrote: > I wonder, can FEver become part of the Fedora infrastructure, so it's > not quite so bus-sensitive? Probably and afaik the original author also planned to do so. Unluckily the code that handled the bugzilla tickets is afaik not publicly available, therefore this needs to be rewritten. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From wdierkes at 5dollarwhitebox.org Sat Jul 11 16:31:42 2009 From: wdierkes at 5dollarwhitebox.org (BJ Dierkes) Date: Sat, 11 Jul 2009 11:31:42 -0500 Subject: Fail2ban + Shorewall Question In-Reply-To: <4A589BE6.5090305@fedoraproject.org> References: <08257EB7-9DC9-402A-B749-FD0D4D91CBBE@5dollarwhitebox.org> <645d17210907101502x7fae7b9dvd8305abf26ac2c97@mail.gmail.com> <4A589BE6.5090305@fedoraproject.org> Message-ID: <045513D3-871E-40C5-896D-6C13987A0460@5dollarwhitebox.org> On Jul 11, 2009, at 9:04 AM, Rahul Sundaram wrote: > On 07/11/2009 03:32 AM, Jonathan Underwood wrote: > >> >> https://bugzilla.redhat.com/show_bug.cgi?id=244275 > > Wow. A simple spec file change and a rebuild has been waiting for 2 > years now? > No kidding. I've submitted two patches... one just removing the dep, and two adding a subpackage as an alternative route. Hopefully this will help move it along. --- derks From opensource at till.name Sat Jul 11 16:36:45 2009 From: opensource at till.name (Till Maas) Date: Sat, 11 Jul 2009 18:36:45 +0200 Subject: Packages tracked by FEver that need to be updated In-Reply-To: References: <200907102243.14776.opensource@till.name> Message-ID: <200907111836.52963.opensource@till.name> On Sat July 11 2009, Rakesh Pandit wrote: > Thanks for nice work. I too mailed other some time back .. but did not > recieved any mail back. May you share the program ;) I'll share the program once I setup some repo for it, which will probably happen the next time I spend a reasonable amount of time on it. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From drago01 at gmail.com Sat Jul 11 16:49:08 2009 From: drago01 at gmail.com (drago01) Date: Sat, 11 Jul 2009 18:49:08 +0200 Subject: x86_64 packages depends on i586. In-Reply-To: <4A58BB52.8070005@gmail.com> References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> <1247305288.2599.2.camel@localhost.localdomain> <4A58BB52.8070005@gmail.com> Message-ID: On Sat, Jul 11, 2009 at 6:18 PM, Frank Murphy wrote: > On 11/07/09 10:41, Jussi Lehtola wrote: > >> >> The x86_64 repo contains some multilib packages. If you don't specify >> the wanted architecture when installing, yum might install both 32- and >> 64-bit versions if available. Try adding the .x86_64 arch specifier, >> e.g. instead of >> # yum install foo >> perform >> # yum install foo.x86_64 > > > Doesn't seem to work for wine :) > yum install foo will install foo.x86_64 by default it will only install foo.i586 if foo.x86_64 when 1) you do yum install foo and only foo.i586 is in the repo 2) yo do yum install foo.i586 3) if you set "exactarch=0" in /etc/yum.conf (default is 1 which leads to the behavior I explained above) From drago01 at gmail.com Sat Jul 11 16:50:01 2009 From: drago01 at gmail.com (drago01) Date: Sat, 11 Jul 2009 18:50:01 +0200 Subject: x86_64 packages depends on i586. In-Reply-To: References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> <1247305288.2599.2.camel@localhost.localdomain> <4A58BB52.8070005@gmail.com> Message-ID: On Sat, Jul 11, 2009 at 6:49 PM, drago01 wrote: > On Sat, Jul 11, 2009 at 6:18 PM, Frank Murphy wrote: >> On 11/07/09 10:41, Jussi Lehtola wrote: >> >>> >>> The x86_64 repo contains some multilib packages. If you don't specify >>> the wanted architecture when installing, yum might install both 32- and >>> 64-bit versions if available. Try adding the .x86_64 arch specifier, >>> e.g. instead of >>> # yum install foo >>> perform >>> # yum install foo.x86_64 >> >> >> Doesn't seem to work for wine :) >> > > yum install foo > will install foo.x86_64 by default it will only install foo.i586 if > foo.x86_64 when s/if foo.x86_64// ;) From jreiser at BitWagon.com Sat Jul 11 18:15:36 2009 From: jreiser at BitWagon.com (John Reiser) Date: Sat, 11 Jul 2009 11:15:36 -0700 Subject: prelink: is it worth it? In-Reply-To: <4A5604EA.9090107@redhat.com> References: <20090709143201.GA22885@jadzia.bu.edu> <4A5604EA.9090107@redhat.com> Message-ID: <4A58D6C8.2020402@BitWagon.com> > [benefit of prelink:] > - almost all relocations a program has to perform are avoided. These > can be very expensive when many dependencies and/or large symbol > tables are involved. The latter is somewhat mitigated by the new > symbol table hashing we implemented some time back but still. About 10% to 50% of the time on i686, this benefit of prelink is trashed by the randomization of the placement of [vdso], also known as linux-gate.so. If the page that the kernel chooses for [vdso] overlaps any pre-linked needed shared library, then ld-linux cannot avoid processing the relocations for that library. Often the cost snowballs as libraries that do not get their pre-linked pages are moved so that they interfere with subsequent libraries. [On x86_64 the vdso is at a special fixed address that cannot conflict.] Try this example from https://bugzilla.redhat.com/show_bug.cgi?id=162797 ----- for i in 0 1 2 3 4 5 6 7 8 9; do for j in 0 1 2 3 4 5 6 7 8 9; do for k in 0 1 2 3 4 5 6 7 8 9; do ldd /bin/cat done done done | grep libc | sort | uniq -c ----- For current Fedora 11 on i686, I see a conflict about 10% of the time, involving only ld-linux, libc, and [vdso]. This means that glibc must be dynamically relocated about 10% of the time anyway, even though glibc has been pre-linked, and even though /bin/cat is near minimal in its use of shared libraries. When a GNOME app uses 50 or more pre-linked shared libs, as claimed in another thread on this subject, then runtime conflict and expense are even more likely. If time performance matters a lot, then the kernel must co-operate when placing the vdso. A patch to FC5 was submitted and adopted some years ago to offer the choice of: no vdso, random vdso, vdso just below STACKTOP, vdso just below PT_INTERP (namely, ld-linux.so.2), vdso just below main. Maintenance suffered because exec_shield was not in the kernel mainline. None of the choices is available today. Even the remaining comment in Fedora's kernel/sysctl.c [just after "int exec_shield = (1<<0);"] is incorrect. -- From joe at nall.com Sat Jul 11 18:30:01 2009 From: joe at nall.com (Joe Nall) Date: Sat, 11 Jul 2009 13:30:01 -0500 Subject: prelink: is it worth it? In-Reply-To: References: <20090709143201.GA22885@jadzia.bu.edu> Message-ID: On Jul 9, 2009, at 9:45 AM, devzero2000 wrote: > > 2 - not checked if this problem is actual or not: prelink erases > file-based > capabilities > > https://bugzilla.redhat.com/show_bug.cgi?id=456105 Which remains 'NEW' a year after it was opened. It was recently reconfirmed by Tomas Mraz in F11. We have a number of apps that use file system capabilities, so we don't install prelink. This is frustrating since it impacts interactive app performance. joe From sundaram at fedoraproject.org Sat Jul 11 18:50:57 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 12 Jul 2009 00:20:57 +0530 Subject: Fail2ban + Shorewall Question In-Reply-To: <045513D3-871E-40C5-896D-6C13987A0460@5dollarwhitebox.org> References: <08257EB7-9DC9-402A-B749-FD0D4D91CBBE@5dollarwhitebox.org> <645d17210907101502x7fae7b9dvd8305abf26ac2c97@mail.gmail.com> <4A589BE6.5090305@fedoraproject.org> <045513D3-871E-40C5-896D-6C13987A0460@5dollarwhitebox.org> Message-ID: <4A58DF11.4070609@fedoraproject.org> On 07/11/2009 10:01 PM, BJ Dierkes wrote: > No kidding. I've submitted two patches... one just removing the dep, > and two adding a subpackage as an alternative route. Hopefully this > will help move it along. Axel Thimm has only been sporadically active for a long time now. There are a number of bugs against his packages that he has not responded to but I didn't realize the situation was so bad. I think it is high time, we orphan the packages and let more interested maintainers take over. Rahul From wdierkes at 5dollarwhitebox.org Sat Jul 11 21:14:25 2009 From: wdierkes at 5dollarwhitebox.org (BJ Dierkes) Date: Sat, 11 Jul 2009 16:14:25 -0500 Subject: Fail2ban + Shorewall Question In-Reply-To: <4A58DF11.4070609@fedoraproject.org> References: <08257EB7-9DC9-402A-B749-FD0D4D91CBBE@5dollarwhitebox.org> <645d17210907101502x7fae7b9dvd8305abf26ac2c97@mail.gmail.com> <4A589BE6.5090305@fedoraproject.org> <045513D3-871E-40C5-896D-6C13987A0460@5dollarwhitebox.org> <4A58DF11.4070609@fedoraproject.org> Message-ID: <94C56C28-284C-4077-8EC0-149A615D1C68@5dollarwhitebox.org> On Jul 11, 2009, at 1:50 PM, Rahul Sundaram wrote: > On 07/11/2009 10:01 PM, BJ Dierkes wrote: > >> No kidding. I've submitted two patches... one just removing the dep, >> and two adding a subpackage as an alternative route. Hopefully this >> will help move it along. > > Axel Thimm has only been sporadically active for a long time now. > There > are a number of bugs against his packages that he has not responded to > but I didn't realize the situation was so bad. I think it is high > time, > we orphan the packages and let more interested maintainers take over. > I'd be interested in taking over fail2ban though I'm just now learning the procedures involved in doing so... and researched everything online for Fedora/EPEL Package Maintainers. Any pointers welcome. --- derks From jonstanley at gmail.com Sat Jul 11 21:34:31 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Sat, 11 Jul 2009 17:34:31 -0400 Subject: Packages tracked by FEver that need to be updated In-Reply-To: <200907111825.41242.opensource@till.name> References: <200907102243.14776.opensource@till.name> <4A58B852.8000205@redhat.com> <200907111825.41242.opensource@till.name> Message-ID: On Sat, Jul 11, 2009 at 12:25 PM, Till Maas wrote: > Probably and afaik the original author also planned to do so. Unluckily the > code that handled the bugzilla tickets is afaik not publicly available, > therefore this needs to be rewritten. What language is it written in? Should be easy to implement using python-bugzilla assuming it's written in python. From kevin.kofler at chello.at Sat Jul 11 22:17:44 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 12 Jul 2009 00:17:44 +0200 Subject: x86_64 packages depends on i586. References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> <1247305288.2599.2.camel@localhost.localdomain> <4A58BB52.8070005@gmail.com> Message-ID: Frank Murphy wrote: > Doesn't seem to work for wine :) That's because WINE is only 32-bit, because most Winblow$ executables are. Kevin Kofler From jussilehtola at fedoraproject.org Sat Jul 11 23:51:09 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Sun, 12 Jul 2009 02:51:09 +0300 Subject: rpm %defattr question Message-ID: <1247356269.22031.1.camel@hawking.theorphys.helsinki.fi> Hi, is the default attribute definition %defattr(-,root,root) the same as %defattr(-,root,root,-)? -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From christoph.wickert at googlemail.com Sat Jul 11 23:54:01 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Sun, 12 Jul 2009 01:54:01 +0200 Subject: RFC: cronKit In-Reply-To: <1246899805.5836.15.camel@choeger6> References: <1246899805.5836.15.camel@choeger6> Message-ID: <1247356441.31951.1.camel@localhost> Am Montag, den 06.07.2009, 19:03 +0200 schrieb Christoph H?ger: > Hi, > > since I sync my mail with the experimental gnome ui of offlineimap, I > encounter a small problem: > How do I tell cron to only invoke the job when I am logged in under > gnome only? How about http://www.gnomefiles.org/app.php/DoThisNow > Since I want the job only to be run if I am logged in under gnome the > main idea is to have a process added to the session that can handle > crontab like jobs (aka cronKit) No more kits please. ;) Whatever the new software would be named, pls don't make another *kit. Regards, Christoph From brusefamelion at gmail.com Sun Jul 12 00:03:51 2009 From: brusefamelion at gmail.com (David) Date: Sat, 11 Jul 2009 20:03:51 -0400 Subject: x86_64 packages depends on i586. In-Reply-To: References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> <1247305288.2599.2.camel@localhost.localdomain> <4A58BB52.8070005@gmail.com> Message-ID: <4A592867.6000408@gmail.com> On 7/11/2009 6:17 PM, Kevin Kofler wrote: > Frank Murphy wrote: >> Doesn't seem to work for wine :) > > That's because WINE is only 32-bit, because most Winblow$ executables are. > > Kevin Kofler "Winblow$"? You really should learn some control here. The 'real guys'. The developers, code writers, people-in-the-know, show respect where respect is warranted. Microsoft should recieve that respect IMO. 90% of the desktop computers in the world use some version of Windows. More desktop computers use some form of Mac OS than all combined versions (distributions) of Linux. WINE? Is a nice concept. But it will never, again IMO, as long as the 'Windows programs' that WINE can run are mostly really old DOS programs. Sheesh. -- David From bruno at wolff.to Sun Jul 12 00:27:41 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 11 Jul 2009 19:27:41 -0500 Subject: x86_64 packages depends on i586. In-Reply-To: <4A592867.6000408@gmail.com> References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> <1247305288.2599.2.camel@localhost.localdomain> <4A58BB52.8070005@gmail.com> <4A592867.6000408@gmail.com> Message-ID: <20090712002741.GB31330@wolff.to> On Sat, Jul 11, 2009 at 20:03:51 -0400, David wrote: > > The 'real guys'. The developers, code writers, people-in-the-know, show > respect where respect is warranted. I'm sure Al Capone got a lot of respect in his day as well. From brusefamelion at gmail.com Sun Jul 12 01:17:56 2009 From: brusefamelion at gmail.com (David) Date: Sat, 11 Jul 2009 21:17:56 -0400 Subject: x86_64 packages depends on i586. In-Reply-To: <20090712002741.GB31330@wolff.to> References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> <1247305288.2599.2.camel@localhost.localdomain> <4A58BB52.8070005@gmail.com> <4A592867.6000408@gmail.com> <20090712002741.GB31330@wolff.to> Message-ID: <4A5939C4.3030204@gmail.com> On 7/11/2009 8:27 PM, Bruno Wolff III wrote: > On Sat, Jul 11, 2009 at 20:03:51 -0400, > David wrote: >> The 'real guys'. The developers, code writers, people-in-the-know, show >> respect where respect is warranted. > > I'm sure Al Capone got a lot of respect in his day as well. ;-) I think that he *demanded* that respect. Deserved? Not really. -- David From bruno at wolff.to Sun Jul 12 01:27:22 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 11 Jul 2009 20:27:22 -0500 Subject: x86_64 packages depends on i586. In-Reply-To: <4A5939C4.3030204@gmail.com> References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> <1247305288.2599.2.camel@localhost.localdomain> <4A58BB52.8070005@gmail.com> <4A592867.6000408@gmail.com> <20090712002741.GB31330@wolff.to> <4A5939C4.3030204@gmail.com> Message-ID: <20090712012722.GA25651@wolff.to> On Sat, Jul 11, 2009 at 21:17:56 -0400, David wrote: > On 7/11/2009 8:27 PM, Bruno Wolff III wrote: > > On Sat, Jul 11, 2009 at 20:03:51 -0400, > > David wrote: > >> The 'real guys'. The developers, code writers, people-in-the-know, show > >> respect where respect is warranted. > > > > I'm sure Al Capone got a lot of respect in his day as well. > > > ;-) > > I think that he *demanded* that respect. Deserved? Not really. I think the analogy works. From brusefamelion at gmail.com Sun Jul 12 01:30:15 2009 From: brusefamelion at gmail.com (David) Date: Sat, 11 Jul 2009 21:30:15 -0400 Subject: x86_64 packages depends on i586. In-Reply-To: <20090712012722.GA25651@wolff.to> References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> <1247305288.2599.2.camel@localhost.localdomain> <4A58BB52.8070005@gmail.com> <4A592867.6000408@gmail.com> <20090712002741.GB31330@wolff.to> <4A5939C4.3030204@gmail.com> <20090712012722.GA25651@wolff.to> Message-ID: <4A593CA7.40508@gmail.com> On 7/11/2009 9:27 PM, Bruno Wolff III wrote: > On Sat, Jul 11, 2009 at 21:17:56 -0400, > David wrote: >> On 7/11/2009 8:27 PM, Bruno Wolff III wrote: >>> On Sat, Jul 11, 2009 at 20:03:51 -0400, >>> David wrote: >>>> The 'real guys'. The developers, code writers, people-in-the-know, show >>>> respect where respect is warranted. >>> I'm sure Al Capone got a lot of respect in his day as well. >> >> ;-) >> >> I think that he *demanded* that respect. Deserved? Not really. > > I think the analogy works. > Thought of that way. I agree. -- David From jkeating at j2solutions.net Sun Jul 12 01:35:39 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 11 Jul 2009 18:35:39 -0700 Subject: x86_64 packages depends on i586. In-Reply-To: <4A592867.6000408@gmail.com> References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> <1247305288.2599.2.camel@localhost.localdomain> <4A58BB52.8070005@gmail.com> <4A592867.6000408@gmail.com> Message-ID: <44E99AC8-82AB-4AD5-9CDE-45A3A77C4224@j2solutions.net> On Jul 11, 2009, at 17:03, David wrote: > On 7/11/2009 6:17 PM, Kevin Kofler wrote: >> Frank Murphy wrote: >>> Doesn't seem to work for wine :) >> >> That's because WINE is only 32-bit, because most Winblow$ >> executables are. >> >> Kevin Kofler > > > "Winblow$"? > > You really should learn some control here. > > The 'real guys'. The developers, code writers, people-in-the-know, > show > respect where respect is warranted. > > Microsoft should recieve that respect IMO. > > 90% of the desktop computers in the world use some version of Windows. > More desktop computers use some form of Mac OS than all combined > versions (distributions) of Linux. > > WINE? Is a nice concept. But it will never, again IMO, as long as the > 'Windows programs' that WINE can run are mostly really old DOS > programs. > > Sheesh. > -- > Perhaps you should do a little research before you spout off. Wine is capable of running very modern day applications that are written for the windows platform. It is anything but old dos programs. -- Jes From brusefamelion at gmail.com Sun Jul 12 02:35:42 2009 From: brusefamelion at gmail.com (David) Date: Sat, 11 Jul 2009 22:35:42 -0400 Subject: x86_64 packages depends on i586. In-Reply-To: <44E99AC8-82AB-4AD5-9CDE-45A3A77C4224@j2solutions.net> References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> <1247305288.2599.2.camel@localhost.localdomain> <4A58BB52.8070005@gmail.com> <4A592867.6000408@gmail.com> <44E99AC8-82AB-4AD5-9CDE-45A3A77C4224@j2solutions.net> Message-ID: <4A594BFE.6030102@gmail.com> On 7/11/2009 9:35 PM, Jesse Keating wrote: > > > On Jul 11, 2009, at 17:03, David wrote: > >> On 7/11/2009 6:17 PM, Kevin Kofler wrote: >>> Frank Murphy wrote: >>>> Doesn't seem to work for wine :) >>> >>> That's because WINE is only 32-bit, because most Winblow$ executables >>> are. >>> >>> Kevin Kofler >> >> >> "Winblow$"? >> >> You really should learn some control here. >> >> The 'real guys'. The developers, code writers, people-in-the-know, show >> respect where respect is warranted. >> >> Microsoft should recieve that respect IMO. >> >> 90% of the desktop computers in the world use some version of Windows. >> More desktop computers use some form of Mac OS than all combined >> versions (distributions) of Linux. >> >> WINE? Is a nice concept. But it will never, again IMO, as long as the >> 'Windows programs' that WINE can run are mostly really old DOS programs. >> >> Sheesh. >> -- >> > > Perhaps you should do a little research before you spout off. Wine is > capable of running very modern day applications that are written for the > windows platform. It is anything but old dos programs. Mr. Keating. May I call you Jessie? I know who you are and I respect you a lot. Would you please name "some very modern day applications that are written for the windows platform" that will run in a Linux current version of WINE? That will run under the currently available WINE in Fedora 11. Names and versions. _Real_ applications. The ones that ordinary 'users' want. Not the geeky ones that 'Linux geeks' want. I am serious here. Really. The names are...? -- David From ricky at fedoraproject.org Sun Jul 12 03:12:14 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Sat, 11 Jul 2009 23:12:14 -0400 Subject: Anybody know how to contact Axel Thimm (again)? In-Reply-To: <20090708172628.GM4580@alpha.rzhou.org> References: <20090708172628.GM4580@alpha.rzhou.org> Message-ID: <20090712031214.GA29972@alpha.rzhou.org> On 2009-07-08 01:26:28 PM, Ricky Zhou wrote: > Hi, we're following the policy for nonresponsive package maintainers > again for bug 484855. There hasn't been any update on this breakage in > the last 3 weeks. > > http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers > https://bugzilla.redhat.com/show_bug.cgi?id=484855 Update on this, there was a response today at https://bugzilla.redhat.com/show_bug.cgi?id=484855#c32. Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From erikina at gmail.com Sun Jul 12 03:53:37 2009 From: erikina at gmail.com (Eric Springer) Date: Sun, 12 Jul 2009 13:53:37 +1000 Subject: x86_64 packages depends on i586. In-Reply-To: <4A594BFE.6030102@gmail.com> References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> <1247305288.2599.2.camel@localhost.localdomain> <4A58BB52.8070005@gmail.com> <4A592867.6000408@gmail.com> <44E99AC8-82AB-4AD5-9CDE-45A3A77C4224@j2solutions.net> <4A594BFE.6030102@gmail.com> Message-ID: On Sun, Jul 12, 2009 at 12:35 PM, David wrote: > > I am serious here. Really. The names are...? It's besides the point, but there are quite a few games (World of Warcraft, Half-life 2 etc.) that run perfectly under wine. I do think Kevin does need to act a little more maturely though (especially now that he's got an official position), and I also know that nothing is going to be gained by continuing this emotional argument. From dgboles at comcast.net Sun Jul 12 04:07:17 2009 From: dgboles at comcast.net (David) Date: Sun, 12 Jul 2009 00:07:17 -0400 Subject: x86_64 packages depends on i586. In-Reply-To: References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> <1247305288.2599.2.camel@localhost.localdomain> <4A58BB52.8070005@gmail.com> <4A592867.6000408@gmail.com> <44E99AC8-82AB-4AD5-9CDE-45A3A77C4224@j2solutions.net> <4A594BFE.6030102@gmail.com> Message-ID: <4A596175.2030806@comcast.net> On 7/11/2009 11:53 PM, Eric Springer wrote: > On Sun, Jul 12, 2009 at 12:35 PM, David wrote: >> I am serious here. Really. The names are...? > > It's besides the point, but there are quite a few games (World of > Warcraft, Half-life 2 etc.) that run perfectly under wine. I do think > Kevin does need to act a little more maturely though (especially now > that he's got an official position), and I also know that nothing is > going to be gained by continuing this emotional argument. > "quite a few games"? "quite a few games" does not count IMO as a real world situation. Real Microsoft applications. Not games. As for Keven? He needs. IMO, to control his emotions if he really wants to be a 'voice?'. Those of use that have been here for years can deal with that. Newbies? They see what is written. My anyone. Wrong or right. as 'the truth". Period. -- David From frankly3d at gmail.com Sun Jul 12 07:50:53 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Sun, 12 Jul 2009 08:50:53 +0100 Subject: Wine was: Re: x86_64 packages depends on i586. In-Reply-To: <4A594BFE.6030102@gmail.com> References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> <1247305288.2599.2.camel@localhost.localdomain> <4A58BB52.8070005@gmail.com> <4A592867.6000408@gmail.com> <44E99AC8-82AB-4AD5-9CDE-45A3A77C4224@j2solutions.net> <4A594BFE.6030102@gmail.com> Message-ID: <4A5995DD.7040602@gmail.com> On 12/07/09 03:35, David wrote: > > Would you please name "some very modern day applications that are > written for the windows platform" that will run in a Linux current > version of WINE? That will run under the currently available WINE in > Fedora 11. Names and versions. _Real_ applications. The ones that > ordinary 'users' want. Not the geeky ones that 'Linux geeks' want. > > I am serious here. Really. The names are...? > http://www.codeweavers.com/compatibility/browse/name/?app_id=2591 All I'm interested in. I also test in wine, but keep forgetting the paperwork. I find makehuman, currently in a position. That it's not a perfect substitute: http://www.makehuman.org/blog/index.php But I keep testing, looking in Regards, Frank From drago01 at gmail.com Sun Jul 12 09:17:18 2009 From: drago01 at gmail.com (drago01) Date: Sun, 12 Jul 2009 11:17:18 +0200 Subject: x86_64 packages depends on i586. In-Reply-To: <4A594BFE.6030102@gmail.com> References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> <1247305288.2599.2.camel@localhost.localdomain> <4A58BB52.8070005@gmail.com> <4A592867.6000408@gmail.com> <44E99AC8-82AB-4AD5-9CDE-45A3A77C4224@j2solutions.net> <4A594BFE.6030102@gmail.com> Message-ID: On Sun, Jul 12, 2009 at 4:35 AM, David wrote: > On 7/11/2009 9:35 PM, Jesse Keating wrote: >> >> >> On Jul 11, 2009, at 17:03, David wrote: >> >>> On 7/11/2009 6:17 PM, Kevin Kofler wrote: >>>> Frank Murphy wrote: >>>>> Doesn't seem to work for wine :) >>>> >>>> That's because WINE is only 32-bit, because most Winblow$ executables >>>> are. >>>> >>>> ? ? ? ?Kevin Kofler >>> >>> >>> "Winblow$"? >>> >>> You really should learn some control here. >>> >>> The 'real guys'. The developers, code writers, people-in-the-know, show >>> respect where respect is warranted. >>> >>> Microsoft should recieve that respect IMO. >>> >>> 90% of the desktop computers in the world use some version of Windows. >>> More desktop computers use some form of Mac OS than all combined >>> versions (distributions) of Linux. >>> >>> WINE? Is a nice concept. But it will never, again IMO, as long as the >>> 'Windows programs' that WINE can run are mostly really old DOS programs. >>> >>> Sheesh. >>> -- >>> >> >> Perhaps you should do a little research before you spout off. Wine is >> capable of running very modern day applications that are written for the >> windows platform. It is anything but old dos programs. > > > Mr. Keating. May I call you Jessie? I know who you are and I respect you > a lot. > > Would you please name "some very modern day applications that are > written for the windows platform" that will run in a Linux current > version of WINE? That will run under the currently available WINE in > Fedora 11. Names and versions. _Real_ applications. The ones that > ordinary 'users' want. Not the geeky ones that 'Linux geeks' want. > > I am serious here. Really. The names are...? Adobe Photoshop, Microsoft Office, Microsoft Visio, Quicken, Lotus Notes and games like WoW, CoD, Halflife, Counter Strike + many more. Sure they are all "old DOS programs" that nobody uses .... From drago01 at gmail.com Sun Jul 12 09:20:51 2009 From: drago01 at gmail.com (drago01) Date: Sun, 12 Jul 2009 11:20:51 +0200 Subject: x86_64 packages depends on i586. In-Reply-To: References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> <1247305288.2599.2.camel@localhost.localdomain> <4A58BB52.8070005@gmail.com> <4A592867.6000408@gmail.com> <44E99AC8-82AB-4AD5-9CDE-45A3A77C4224@j2solutions.net> <4A594BFE.6030102@gmail.com> Message-ID: On Sun, Jul 12, 2009 at 11:17 AM, drago01 wrote: > On Sun, Jul 12, 2009 at 4:35 AM, David wrote: >> On 7/11/2009 9:35 PM, Jesse Keating wrote: >>> >>> >>> On Jul 11, 2009, at 17:03, David wrote: >>> >>>> On 7/11/2009 6:17 PM, Kevin Kofler wrote: >>>>> Frank Murphy wrote: >>>>>> Doesn't seem to work for wine :) >>>>> >>>>> That's because WINE is only 32-bit, because most Winblow$ executables >>>>> are. >>>>> >>>>> ? ? ? ?Kevin Kofler >>>> >>>> >>>> "Winblow$"? >>>> >>>> You really should learn some control here. >>>> >>>> The 'real guys'. The developers, code writers, people-in-the-know, show >>>> respect where respect is warranted. >>>> >>>> Microsoft should recieve that respect IMO. >>>> >>>> 90% of the desktop computers in the world use some version of Windows. >>>> More desktop computers use some form of Mac OS than all combined >>>> versions (distributions) of Linux. >>>> >>>> WINE? Is a nice concept. But it will never, again IMO, as long as the >>>> 'Windows programs' that WINE can run are mostly really old DOS programs. >>>> >>>> Sheesh. >>>> -- >>>> >>> >>> Perhaps you should do a little research before you spout off. Wine is >>> capable of running very modern day applications that are written for the >>> windows platform. It is anything but old dos programs. >> >> >> Mr. Keating. May I call you Jessie? I know who you are and I respect you >> a lot. >> >> Would you please name "some very modern day applications that are >> written for the windows platform" that will run in a Linux current >> version of WINE? That will run under the currently available WINE in >> Fedora 11. Names and versions. _Real_ applications. The ones that >> ordinary 'users' want. Not the geeky ones that 'Linux geeks' want. >> >> I am serious here. Really. The names are...? > > Adobe Photoshop, Microsoft Office, Microsoft Visio, Quicken, Lotus > Notes and games like WoW, CoD, Halflife, Counter Strike + many more. > > Sure they are all "old DOS programs" that nobody uses .... > Forgot to add wine does not even support DOS programs (you can use dosbox for them) From jim at meyering.net Sun Jul 12 10:01:15 2009 From: jim at meyering.net (Jim Meyering) Date: Sun, 12 Jul 2009 12:01:15 +0200 Subject: rawhide hosed after latest update: everything segfaults Message-ID: <87zlbab4pg.fsf@meyering.net> Last night I updated a rawhide x86_64 system that I'd installed just a week ago. The previous update was two or three days ago, and went fine. This one however, did not go well. ... Transaction Test Succeeded Running Transaction Updating : 1:NetworkManager-glib-0.7.1-8.git20090708.fc12.x86_64 1/74 Updating : libxklavier-4.0-3.fc12.x86_64 2/74 Updating : libsemanage-2.0.33-1.fc12.x86_64 3/74 Updating : 12:dhclient-4.1.0-24.fc12.x86_64 4/74 Error in POSTIN scriptlet in rpm package 12:dhclient-4.1.0-24.fc12.x86_64 error: %post(dhclient-12:4.1.0-24.fc12.x86_64) scriptlet failed, signal 11 Updating : 1:NetworkManager-0.7.1-8.git20090708.fc12.x86_64 5/74 Error in POSTIN scriptlet in rpm package 1:NetworkManager-0.7.1-8.git20090708.fc12.x86_64 ... "yum -y upgrade" printed this summary: Removed: kernel.x86_64 0:2.6.29.5-191.fc11 Updated: NetworkManager-glib.x86_64 1:0.7.1-8.git20090708.fc12 bodhi-client.noarch 0:0.6.1-1.fc12 control-center-filesystem.x86_64 1:2.27.3-2.fc12 empathy-libs.x86_64 0:2.27.3-4.fc12 filesystem.x86_64 0:2.4.23-1.fc12 hunspell.x86_64 0:1.2.8-9.fc12 kernel-firmware.noarch 0:2.6.31-0.62.rc2.git4.fc12 kernel-headers.x86_64 0:2.6.31-0.62.rc2.git4.fc12 libsemanage.x86_64 0:2.0.33-1.fc12 libsemanage-python.x86_64 0:2.0.33-1.fc12 libtirpc.x86_64 0:0.2.0-3.fc12 libv4l.x86_64 0:0.6.0-1.fc12 libxklavier.x86_64 0:4.0-3.fc12 mono-core.x86_64 0:2.4.2.1-1.fc12 mono-data.x86_64 0:2.4.2.1-1.fc12 mono-data-sqlite.x86_64 0:2.4.2.1-1.fc12 mono-extras.x86_64 0:2.4.2.1-1.fc12 mono-web.x86_64 0:2.4.2.1-1.fc12 mono-winforms.x86_64 0:2.4.2.1-1.fc12 monodoc.x86_64 0:2.4.2.1-1.fc12 neon.x86_64 0:0.28.5-1.fc12 ntfsprogs.x86_64 0:2.0.0-11.fc12 xfsprogs.x86_64 0:3.0.1-9.fc12 xorg-x11-drv-evdev.x86_64 0:2.2.99-3.20090629.fc12 xorg-x11-drv-synaptics.x86_64 0:1.1.99-2.20090710.fc12 xorg-x11-drv-vmmouse.x86_64 0:12.6.4-2.fc12 Failed: NetworkManager.x86_64 1:0.7.1-8.git20090708.fc12 NetworkManager-gnome.x86_64 1:0.7.1-8.git20090708.fc12 control-center.x86_64 1:2.27.3-2.fc12 dhclient.x86_64 12:4.1.0-24.fc12 ekiga.x86_64 0:3.2.5-2.fc12 kernel.x86_64 0:2.6.31-0.62.rc2.git4.fc12 prelink.x86_64 0:0.4.2-1.fc12 setroubleshoot-plugins.noarch 0:2.1.9-1.fc12 sudo.x86_64 0:1.7.1-4.fc12 system-config-date.noarch 0:1.9.39-1.fc12 tar.x86_64 2:1.22-4.fc12 And now, from the same root shell (zsh) that ran the yum -y upgrade command, whenever I try to run any non-builtin command with shared libraries, it segfaults: $ /bin/true zsh: segmentation fault /bin/true $ ldd /bin/false zsh: segmentation fault ldd /bin/false Statically-linked ones like "mount" do work: $ mount > /dev/null && echo ok ok >From the names of the packages involved in the latest update, only "prelink" seems like it could cause such fundamental trouble. Digging a little showed I'm not alone: http://bugzilla.redhat.com/509655 Jakub Jelinek's comments suggesting how to recover worked for me: https://bugzilla.redhat.com/show_bug.cgi?id=509655#c13 From muepsj at gmail.com Sun Jul 12 10:37:40 2009 From: muepsj at gmail.com (=?UTF-8?Q?Joonas_Saraj=C3=A4rvi?=) Date: Sun, 12 Jul 2009 13:37:40 +0300 Subject: x86_64 packages depends on i586. In-Reply-To: <4A594BFE.6030102@gmail.com> References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> <1247305288.2599.2.camel@localhost.localdomain> <4A58BB52.8070005@gmail.com> <4A592867.6000408@gmail.com> <44E99AC8-82AB-4AD5-9CDE-45A3A77C4224@j2solutions.net> <4A594BFE.6030102@gmail.com> Message-ID: <66ec675b0907120337u3a5e2009yeff8f2776980ff78@mail.gmail.com> 2009/7/12, David : > Would you please name "some very modern day applications that are > written for the windows platform" that will run in a Linux current > version of WINE? That will run under the currently available WINE in > Fedora 11. Names and versions. _Real_ applications. The ones that > ordinary 'users' want. Not the geeky ones that 'Linux geeks' want. > > I am serious here. Really. The names are...? For me, - Spotify And a quite long list of games, including - the IL-2 Sturmovik series - the Homeworld series - Trainz - Areena 5 - Diablo II - Command & Conquer (might be close to a DOS game, but it's still win32) - Sim City 4 - Age of Mythology - Rollercoaster tycoon - and many more I consider games to be a real use case. -- Joonas Saraj?rvi muepsj at gmail.com From joshuacov at googlemail.com Sun Jul 12 10:46:15 2009 From: joshuacov at googlemail.com (Joshua C.) Date: Sun, 12 Jul 2009 12:46:15 +0200 Subject: x86_64 packages depends on i586. In-Reply-To: <66ec675b0907120337u3a5e2009yeff8f2776980ff78@mail.gmail.com> References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> <1247305288.2599.2.camel@localhost.localdomain> <4A58BB52.8070005@gmail.com> <4A592867.6000408@gmail.com> <44E99AC8-82AB-4AD5-9CDE-45A3A77C4224@j2solutions.net> <4A594BFE.6030102@gmail.com> <66ec675b0907120337u3a5e2009yeff8f2776980ff78@mail.gmail.com> Message-ID: <5f6f8c5f0907120346w4348e3e4vd3f82328975f20cb@mail.gmail.com> 2009/7/12 Joonas Saraj?rvi : > 2009/7/12, David : >> Would you please name "some very modern day applications that are >> written for the windows platform" that will run in a Linux current >> version of WINE? That will run under the currently available WINE in >> Fedora 11. Names and versions. _Real_ applications. The ones that >> ordinary 'users' want. Not the geeky ones that 'Linux geeks' want. >> >> I am serious here. Really. The names are...? > > For me, > - Spotify > > And a quite long list of games, including > - the IL-2 Sturmovik series > - the Homeworld series > - Trainz > - Areena 5 > - Diablo II > - Command & Conquer (might be close to a DOS game, but it's still win32) > - Sim City 4 > - Age of Mythology > - Rollercoaster tycoon > - and many more > > I consider games to be a real use case. > -- > Joonas Saraj?rvi > muepsj at gmail.com > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > HEY, CAN WE GO BACK TO THE ORIGINAL DISCUSSION, PLEASE!!! I'm not a newbey and I've been using my kick files for the last 3-4 months. This is the first time that I got 32 bit apps in my livecd. The most strange thing is that after deleting all *.i?86, yum deletes some x86_64 apps as well. After this i tried to install back the deleted x86_64 and the same i?86 are pulled in as dependencies. I don't know how this could have happened. I do saw that there is some update to yum (in koji) which says something like "making livecd-creator works again". Maybe I just hit some nasty bug. I'll try to compose one more x86_64 livecd and if this happenes agian I'll file a bug against yum (or livecd-creator) --joshua PS: I've never used wine and it's not included in my kick files (so please stop this windoof discussion) From rjones at redhat.com Sun Jul 12 11:17:39 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Sun, 12 Jul 2009 12:17:39 +0100 Subject: x86_64 packages depends on i586. In-Reply-To: <4A594BFE.6030102@gmail.com> References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> <1247305288.2599.2.camel@localhost.localdomain> <4A58BB52.8070005@gmail.com> <4A592867.6000408@gmail.com> <44E99AC8-82AB-4AD5-9CDE-45A3A77C4224@j2solutions.net> <4A594BFE.6030102@gmail.com> Message-ID: <20090712111739.GA17360@amd.home.annexia.org> On Sat, Jul 11, 2009 at 10:35:42PM -0400, David wrote: > Would you please name "some very modern day applications that are > written for the windows platform" that will run in a Linux current > version of WINE? That will run under the currently available WINE in > Fedora 11. Names and versions. _Real_ applications. The ones that > ordinary 'users' want. Not the geeky ones that 'Linux geeks' want. All of the cross-compiled apps from the Fedora MinGW project. If you find one which doesn't work in Wine, please file a bug about it. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From rjones at redhat.com Sun Jul 12 11:19:24 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Sun, 12 Jul 2009 12:19:24 +0100 Subject: x86_64 packages depends on i586. In-Reply-To: <20090712111739.GA17360@amd.home.annexia.org> References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> <1247305288.2599.2.camel@localhost.localdomain> <4A58BB52.8070005@gmail.com> <4A592867.6000408@gmail.com> <44E99AC8-82AB-4AD5-9CDE-45A3A77C4224@j2solutions.net> <4A594BFE.6030102@gmail.com> <20090712111739.GA17360@amd.home.annexia.org> Message-ID: <20090712111924.GB17360@amd.home.annexia.org> On Sun, Jul 12, 2009 at 12:17:39PM +0100, Richard W.M. Jones wrote: > All of the cross-compiled apps ... by which I mean apps cross-compiled using our libraries, like mingw32-gtk2. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 75 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From bnocera at redhat.com Sun Jul 12 17:24:30 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Sun, 12 Jul 2009 18:24:30 +0100 Subject: Champlain In-Reply-To: <4A589207.4010406@poolshark.org> References: <3170f42f0907110406v46117b12mdc102bcf085cb882@mail.gmail.com> <1247315869.2774.4.camel@localhost.localdomain> <4A589207.4010406@poolshark.org> Message-ID: <1247419470.5460.5.camel@snoogens.fab.redhat.com> On Sat, 2009-07-11 at 15:22 +0200, Denis Leroy wrote: > On 07/11/2009 02:37 PM, Brian Pepple wrote: > > I've been working on updating libchamplain to 0.3.3 in Rawhide, but > > until it gets ported to the clutter-0.9 api (or we do a clutter-0.8 > > compat) it's a no go for now. > > I've been told to expect clutter 1.0 real soon (tm) :-) Given that the last release on the devel branch was called "rc2", this is hardly insider information... From Fedora at FamilleCollet.com Sun Jul 12 17:40:39 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Sun, 12 Jul 2009 19:40:39 +0200 Subject: Heads UP - PHP 5.3.0 in rawhide with new ABI/API. Message-ID: <4A5A2017.3090409@FamilleCollet.com> Hi, PHP 5.3.0 freshly build in Rawhide. $ phpize --version Configuring for: PHP Api Version: 20090626 Zend Module Api No: 20090626 Zend Extension Api No: 220090626 REMOVED sub-packages - php-dbase (not maintained) - php-mhash (not maintained) - php-ncurses (moved to pecl, see php-pecl-ncurses) NEW sub-packages - php-intl - php-enchant NEW extensions - php-phar (in php-common and php-cli) - php-fileinfo (in php-common) - php-sqlite3 (in php-pdo) DEAD Packages - php-pecl-phar - php-pecl-Fileinfo NEW Package - php-pecl-ncurses : Waiting for Review (please do it) https://bugzilla.redhat.com/show_bug.cgi?id=510913 I've start working on building all extensions (upgrading to latest version when needed) I know, starting with the ones I own. Most webapp should work (probably with E_DEPRECATED warning, but it's disabled for production use). A lot of webapp have been already fixed upstream (phpMyAdmin, p.e.) Some will probably require some works. Remi. From denis at poolshark.org Sun Jul 12 18:25:42 2009 From: denis at poolshark.org (Denis Leroy) Date: Sun, 12 Jul 2009 20:25:42 +0200 Subject: Champlain In-Reply-To: <1247419470.5460.5.camel@snoogens.fab.redhat.com> References: <3170f42f0907110406v46117b12mdc102bcf085cb882@mail.gmail.com> <1247315869.2774.4.camel@localhost.localdomain> <4A589207.4010406@poolshark.org> <1247419470.5460.5.camel@snoogens.fab.redhat.com> Message-ID: <4A5A2AA6.8080904@poolshark.org> On 07/12/2009 07:24 PM, Bastien Nocera wrote: > On Sat, 2009-07-11 at 15:22 +0200, Denis Leroy wrote: >> On 07/11/2009 02:37 PM, Brian Pepple wrote: >>> I've been working on updating libchamplain to 0.3.3 in Rawhide, but >>> until it gets ported to the clutter-0.9 api (or we do a clutter-0.8 >>> compat) it's a no go for now. >> I've been told to expect clutter 1.0 real soon (tm) :-) > > Given that the last release on the devel branch was called "rc2", this > is hardly insider information... I never claimed it was From rawhide at fedoraproject.org Sun Jul 12 18:56:34 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sun, 12 Jul 2009 18:56:34 +0000 Subject: rawhide report: 20090711 changes Message-ID: <20090712185634.GA23711@releng2.fedora.phx.redhat.com> Compose started at Sat Jul 11 06:15:06 UTC 2009 New package bitfrost OLPC bitfrost security modules New package perl-Math-Curve-Hilbert Perl Implementation of Hilberts space-filling Curve New package phpFlickr PHP client for the Flickr web service New package python-repoze-what-plugins-sql The repoze.what SQL plugin New package rubygem-rack-test Simple testing API built on Rack New package rubygem-rubigen A framework to allow Ruby applications to generate file/folder stubs New package xgridloc A GTK+ application for the calculation of Maidenhead QRA Locators Removed package virt-df Updated Packages: R-2.9.1-2.fc12 -------------- * Fri Jul 10 2009 Tom "spot" Callaway - 2.9.1-2 - don't try to make the PDFs in rawhide/i586 * Thu Jul 09 2009 Tom "spot" Callaway - 2.9.1-1 - update to 2.9.1 - fix versioned provides abrt-0.0.4-3.fc12 ----------------- * Thu Jun 25 2009 Jiri Moskovcak 0.0.4-3 - fixed dependencies in spec file * Tue Jun 16 2009 Daniel Novotny 0.0.4-2 - added manual pages (also for plugins) * Mon Jun 15 2009 Jiri Moskovcak 0.0.4-1 - new version - added cli (only supports sockets) - added python hook - many fixes asymptote-1.80-1.fc12 --------------------- * Fri Jul 10 2009 Tom "spot" Callaway - 1.80-1 - update to 1.80 * Wed Jul 01 2009 Tom "spot" Callaway - 1.78-1 - update to 1.78 * Wed Jul 01 2009 Tom "spot" Callaway - 1.78-2 - disable pdf generation in rawhide bouncycastle-1.43-2.fc12 ------------------------ * Fri Jul 10 2009 Orcan Ogetbil - 1.43-2 - Re-enable AOT bits thanks to Andrew Haley. clutter-0.9.6-1.fc12 -------------------- * Fri Jul 10 2009 Bastien Nocera 0.9.6-1 - Update to 0.9.6 compiz-0.8.2-4.fc12 ------------------- * Fri Jul 10 2009 Adel Gadllah - 0.8.2-4 - Replace compiz-0.8.2-pin-initial-plugins with a fixed up one by Philippe Troin (RH #473896) culmus-fonts-0.103-3.fc12 ------------------------- * Fri Jul 10 2009 Pravin Satpute - 0.103-3 - added DavidCLM afm and pfa - bug 509694 * Wed Jul 08 2009 Pravin Satpute - 0.103-1 - upstream new release 0.103 curl-7.19.5-7.fc12 ------------------ * Fri Jul 10 2009 Kamil Dudka 7.19.5-7 - fix SIGSEGV when using NSS client certificates, thanks to Claes Jakobsson freedink-dfarc-3.2.3-1.fc12 --------------------------- * Fri Jul 10 2009 Sylvain Beucler - 3.2.3-1 - New upstream release gambas2-2.14.0-1.fc12 --------------------- * Fri Jul 10 2009 Tom "spot" Callaway - 2.14.0-1 - update to 2.14.0 - fix missing subpackages (bz 507496) gparted-0.4.5-2.fc12 -------------------- * Fri Jul 10 2009 Deji Akingunola - 0.4.5-2 - Change e2fsprog-devel BR to libuuid-devel, and rebuild for parted soname bump grub-0.97-54.fc12 ----------------- * Fri Jul 10 2009 Peter Jones - 0.97-54 - Add support for partitionable md devices. gtk2-2.17.4-1.fc12 ------------------ * Fri Jul 10 2009 Matthias Clasen - 2.17.3-3 - Add an imsettings conf file for im-cedilla * Fri Jul 10 2009 Matthias Clasen - 2.17.4-1 - Update to 2.17.4 hunspell-bg-4.1-4.fc12 ---------------------- * Fri Jul 10 2009 Caolan McNamara - 4.1-4 - clean up spec hunspell-fy-2.0.0-3.fc12 ------------------------ * Fri Jul 10 2009 Caolan McNamara - 2.0.0-3 - tidy up hunspell-ku-0.21-5.fc12 ----------------------- * Fri Jul 10 2009 Caolan McNamara - 0.21-5 - tidy spec hunspell-lt-1.2.1-3.fc12 ------------------------ * Fri Jul 10 2009 Caolan McNamara - 1.2.1-3 - clean spec hunspell-ur-0.64-1.fc12 ----------------------- * Thu Jul 09 2009 Caolan McNamara - 0.64-1 - latest version hyphen-bg-4.1-3.fc12 -------------------- * Fri Jul 10 2009 Caolan McNamara - 4.1-3 - tidy spec iwl4965-firmware-228.61.2.24-1.fc12 ----------------------------------- java-1.6.0-openjdk-1.6.0.0-24.b16.fc12 -------------------------------------- * Fri Jul 10 2009 Lillian Angel - 1:1.6.0-24.b16 - Added java-1.6.0-openjdk-execvpe.patch. * Thu Jul 09 2009 Lillian Angel - 1:1.6.0-24.b16 - Added java-1.6.0-openjdk-netx.patch - Moved policytool to devel package. - Updated release. - Resolves: rhbz#507870 - Resolves: rhbz#471346 kernel-2.6.31-0.64.rc2.git5.fc12 -------------------------------- * Fri Jul 10 2009 Dave Jones - 2.6.31-rc2-git5 * Fri Jul 10 2009 Dave Jones 2.6.31-0.64.rc2.git5 - Don't jump through hoops that ppc powerbooks have to on sensible systems in cpufreq_suspend. kicad-2009.07.07-2.rev1863.fc12 ------------------------------- * Wed Jul 08 2009 Jon Ciesla - 2009.07.07-2.rev1863 - Dropped eeschema desktop file. - Moved English kicad.pdf to main rpm. - Added ls.so.conf file and ldconfig to post, postun to fix libs issue. - Dropped category Development from desktop file. ldns-1.6.0-2.fc12 ----------------- * Sat Jul 11 2009 Paul Wouters - 1.6.0-1 - Updated to 1.6.0 - (did not yet compile with --without-ssl due to compile failures) * Thu Apr 16 2009 Paul Wouters - 1.5.1-4 - Memory management bug when generating a sha256 key, see: https://bugzilla.redhat.com/show_bug.cgi?id=493953 less-436-1.fc12 --------------- * Fri Jul 10 2009 Zdenek Prikryl - 436-1 - Foption patch is more optimal now - Update to 436 libgsf-1.14.15-2.fc12 --------------------- * Fri Jul 10 2009 Caol?n McNamara 1.14.15-2 - clean some rpmlint warnings libguestfs-1.0.57-1.fc12 ------------------------ * Fri Jul 10 2009 Richard W.M. Jones - 1.0.57-1 - New upstream release 1.0.57. - New tool virt-df (obsoletes existing package with this name). - RHBZ#507066 may be fixed, so reenable tests. libsemanage-2.0.33-2.fc12 ------------------------- * Fri Jul 10 2009 Dan Walsh - 2.0.33-2 - Put check for /root back into genhomedircon libvirt-0.6.5-2.fc12 -------------------- * Fri Jul 10 2009 Richard W.M. Jones - 0.6.5-2.fc12 - Bump release number to rebuild against new libparted. lm_sensors-3.1.1-2.fc12 ----------------------- * Fri Jul 10 2009 Adam Jackson 3.1.1-2 - Add -libs subpackage so perl doesn't get dragged in just for linking against libsensors. m17n-contrib-1.1.9-7.fc12 ------------------------- * Fri Jul 10 2009 Parag Nemade -1.1.9-7 - update patch pa-jhelum-numeric-503478.patch * Tue Jun 02 2009 Parag Nemade -1.1.9-6 - Resolves: rh#503478-[pa_IN][Jhelum] layout need update for Gurmukhi Numeric * Wed May 06 2009 Parag Nemade -1.1.9-5 - Resolves: rh#485152- Kashmiri (Arabic-persian) language keyboard layout mkinitrd-6.0.91-2.fc12 ---------------------- * Fri Jul 10 2009 Tom "spot" Callaway - 6.0.91-2 - rebuild against new parted mysql-5.1.36-1.fc12 ------------------- * Fri Jul 10 2009 Tom Lane 5.1.36-1 - Update to MySQL 5.1.36, for various fixes described at http://dev.mysql.com/doc/refman/5.1/en/news-5-1-36.html mythes-it-2.0.9l-3.fc12 ----------------------- * Fri Jul 10 2009 Caolan McNamara - 2.0.9l-3 - tidy spec mythes-pl-1.5-3.fc12 -------------------- * Fri Jul 10 2009 Caolan McNamara - 1.5-3 - clean spec nasm-2.06-1.fc12 ---------------- * Fri Jul 10 2009 Zdenek Prikryl - 2.06-1 - updated to 2.06 nethack-3.4.3-21.fc12 --------------------- * Fri Jul 10 2009 Luke Macken - 3.4.3-21 - Apply a patch from Iain Arnell to update our spec to comply with the new font packaging guidelines (#505613) parted-1.9.0-1.fc12 ------------------- * Fri Jul 10 2009 Joel Granados - 1.9.0-1 - New version. perl-5.10.0-74.fc12 ------------------- * Fri Jul 10 2009 Stepan Kasal - 4:5.10.0-74 - fix generated .ph files so that they no longer cause warnings (#509676) - remove PREREQ_FATAL from Makefile.PL's processed by miniperl - update to latest Scalar-List-Utils (#507378) - perl-skip-prereq.patch: skip more prereq declarations in Makefile.PL files prelude-manager-0.9.15-1.fc12 ----------------------------- * Fri Jul 10 2009 Steve Grubb 0.9.15-1 - new upstream version pykickstart-1.57-1.fc12 ----------------------- * Fri Jul 10 2009 Chris Lumens - 1.57-1 - Another patch to make the bootloader test work (jlaska). pyparted-2.0.12-2.fc12 ---------------------- * Fri Jul 10 2009 David Cantrell - 2.0.12-2 - Rebuild for new parted python-application-1.1.2-1.fc12 ------------------------------- * Fri Jul 10 2009 Peter Lemenkov 1.1.2-1 - Ver. 1.1.2 python-wokkel-0.6.2-1.fc12 -------------------------- * Fri Jul 10 2009 Ruben Kerkhof - 0.6.2-1 - Upstream released new version radvd-1.3-1.fc12 ---------------- * Fri Jul 10 2009 Jiri Skala - 1.3-1 - updated to latest upstream version rhythmbox-0.12.3-1.fc12 ----------------------- * Thu Jul 09 2009 Bastien Nocera 0.12.3-1 - Udpate to 0.12.3 rpy-2.0.6-3.fc12 ---------------- * Fri Jul 10 2009 Tom "spot" Callaway - 2.0.6-3 - images are only installed incorrectly on 64bit platforms that aren't ia64 * Thu Jul 09 2009 Tom "spot" Callaway - 2.0.6-1 - rebuild for R 2.9.1 - update to rpy2 2.0.6 seamonkey-1.1.17-1.fc12 ----------------------- * Fri Jul 10 2009 Martin Stransky 1.1.17-1 - Update to 1.1.17 srecord-1.50-2.fc12 ------------------- * Fri Jul 10 2009 Tom "spot" Callaway - 1.50-1 - update to 1.50 * Fri Jul 10 2009 Tom "spot" Callaway - 1.50-2 - add BuildRequires: libgcrypt-devel sugar-update-control-0.21-1.fc12 -------------------------------- * Fri Jul 10 2009 Daniel Drake 0.21-1 - Update to v0.21 sunbird-1.0-0.6.20090513hg.fc12 ------------------------------- * Fri Jul 10 2009 Lubomir Rintel - 1.0-0.6.20090513hg - Fix up lignthing's require of rawhide thunderbird tryton-1.2.1-1.fc12 ------------------- * Fri Jul 10 2009 Dan Hor?k 1.2.1-1 - update to upstream version 1.2.1 trytond-1.2.1-1.fc12 -------------------- * Fri Jul 10 2009 Dan Hor?k 1.2.1-1 - update to upstream version 1.2.1 wordpress-2.8.1-1.fc12 ---------------------- * Fri Jul 10 2009 Adrian Reber - 2.8.1-1 - updated to 2.8.1 for security fixes - BZ 510745 xchm-1.17-1.fc12 ---------------- * Wed Jul 08 2009 Manuel "lonely wolf" Wolfshant - 1.17-1 - Version update. Summary: Added Packages: 7 Removed Packages: 1 Modified Packages: 55 Broken deps for i386 ---------------------------------------------------------- DeviceKit-disks-005-2.fc12.i586 requires libparted-1.8.so.8 R-RScaLAPACK-0.5.1-19.fc11.i586 requires openmpi-libs 1:anjuta-2.26.1.0-1.fc12.i586 requires libgdl-1.so.0 bmpx-0.40.14-8.fc11.i386 requires libboost_iostreams-mt.so.4 bmpx-0.40.14-8.fc11.i386 requires libboost_regex-mt.so.4 clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.i586 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.i586 requires gauche = 0:0.8.13 gnome-python2-gdl-2.25.3-4.fc12.i586 requires libgdl-1.so.0 gparted-0.4.5-2.fc12.i586 requires libparted-1.8.so.8 gtranslator-1.9.5-1.fc12.i586 requires libgdl-1.so.0 libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 orsa-0.7.0-8.fc11.i586 requires libcln.so.5 ppl-swiprolog-0.10.2-3.fc12.i586 requires libpl.so.5.7.6 pyclutter-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.i386 requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.i386 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.i586 requires libgeos-3.0.3.so python-repoze-what-plugins-sql-1.0-0.5.rc1.fc12.noarch requires python-repoze-who-plugins-sa qtparted-0.4.5-19.fc11.i586 requires libparted-1.8.so.8 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.i586 requires libpqxx-2.6.8.so springlobby-0.0.1.10461-1.fc12.i586 requires libtorrent-rasterbar.so.3 thunderbird-lightning-1.0-0.6.20090513hg.fc12.i586 requires thunderbird < 0:3.0-2.3.b4 vtk-examples-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 Broken deps for x86_64 ---------------------------------------------------------- DeviceKit-disks-005-2.fc12.x86_64 requires libparted-1.8.so.8()(64bit) R-RScaLAPACK-0.5.1-19.fc11.x86_64 requires openmpi-libs 1:anjuta-2.26.1.0-1.fc12.i586 requires libgdl-1.so.0 1:anjuta-2.26.1.0-1.fc12.x86_64 requires libgdl-1.so.0()(64bit) bmpx-0.40.14-8.fc11.x86_64 requires libboost_regex.so.4()(64bit) bmpx-0.40.14-8.fc11.x86_64 requires libboost_iostreams.so.4()(64bit) clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.x86_64 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.x86_64 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.x86_64 requires gauche = 0:0.8.13 gnome-python2-gdl-2.25.3-4.fc12.x86_64 requires libgdl-1.so.0()(64bit) gparted-0.4.5-2.fc12.x86_64 requires libparted-1.8.so.8()(64bit) gtranslator-1.9.5-1.fc12.x86_64 requires libgdl-1.so.0()(64bit) libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.x86_64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 libprojectM-1.2.0-9.fc11.x86_64 requires libftgl.so.0()(64bit) orsa-0.7.0-8.fc11.i586 requires libcln.so.5 orsa-0.7.0-8.fc11.x86_64 requires libcln.so.5()(64bit) ppl-swiprolog-0.10.2-3.fc12.x86_64 requires libpl.so.5.7.6()(64bit) pyclutter-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.x86_64 requires libgeos-3.0.3.so()(64bit) python-repoze-what-plugins-sql-1.0-0.5.rc1.fc12.noarch requires python-repoze-who-plugins-sa qtparted-0.4.5-19.fc11.x86_64 requires libparted-1.8.so.8()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.x86_64 requires libpqxx-2.6.8.so()(64bit) springlobby-0.0.1.10461-1.fc12.x86_64 requires libtorrent-rasterbar.so.3()(64bit) thunderbird-lightning-1.0-0.6.20090513hg.fc12.x86_64 requires thunderbird < 0:3.0-2.3.b4 vtk-examples-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 Broken deps for ppc ---------------------------------------------------------- DeviceKit-disks-005-2.fc12.ppc requires libparted-1.8.so.8 R-RScaLAPACK-0.5.1-19.fc11.ppc requires openmpi-libs 1:anjuta-2.26.1.0-1.fc12.ppc requires libgdl-1.so.0 1:anjuta-2.26.1.0-1.fc12.ppc64 requires libgdl-1.so.0()(64bit) bmpx-0.40.14-8.fc11.ppc requires libboost_iostreams-mt.so.4 bmpx-0.40.14-8.fc11.ppc requires libboost_regex-mt.so.4 clutter-cairo-0.8.2-3.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.ppc requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.ppc requires gauche = 0:0.8.13 gnome-python2-gdl-2.25.3-4.fc12.ppc requires libgdl-1.so.0 gparted-0.4.5-2.fc12.ppc requires libparted-1.8.so.8 gtranslator-1.9.5-1.fc12.ppc requires libgdl-1.so.0 libchamplain-0.2.9-1.fc11.ppc requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc requires libftgl.so.0 libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) orsa-0.7.0-8.fc11.ppc requires libcln.so.5 orsa-0.7.0-8.fc11.ppc64 requires libcln.so.5()(64bit) ppl-swiprolog-0.10.2-3.fc12.ppc requires libpl.so.5.7.6 pyclutter-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.ppc requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.ppc requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.ppc requires libgeos-3.0.3.so python-repoze-what-plugins-sql-1.0-0.5.rc1.fc12.noarch requires python-repoze-who-plugins-sa qtparted-0.4.5-19.fc11.ppc requires libparted-1.8.so.8 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc requires libpqxx-2.6.8.so thunderbird-lightning-1.0-0.6.20090513hg.fc12.ppc requires thunderbird < 0:3.0-2.3.b4 vtk-examples-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 Broken deps for ppc64 ---------------------------------------------------------- DeviceKit-disks-005-2.fc12.ppc64 requires libparted-1.8.so.8()(64bit) R-RScaLAPACK-0.5.1-19.fc11.ppc64 requires openmpi-libs 1:anjuta-2.26.1.0-1.fc12.ppc64 requires libgdl-1.so.0()(64bit) bmpx-0.40.14-8.fc11.ppc64 requires libboost_regex.so.4()(64bit) bmpx-0.40.14-8.fc11.ppc64 requires libboost_iostreams.so.4()(64bit) clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) gnome-python2-gdl-2.25.3-4.fc12.ppc64 requires libgdl-1.so.0()(64bit) gparted-0.4.5-2.fc12.ppc64 requires libparted-1.8.so.8()(64bit) gtranslator-1.9.5-1.fc12.ppc64 requires libgdl-1.so.0()(64bit) libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) orsa-0.7.0-8.fc11.ppc64 requires libcln.so.5()(64bit) ppl-swiprolog-0.10.2-3.fc12.ppc64 requires libpl.so.5.7.6()(64bit) pyclutter-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.ppc64 requires libgeos-3.0.3.so()(64bit) python-mwlib-0.11.2-2.20090522hg2956.fc12.ppc64 requires LabPlot python-repoze-what-plugins-sql-1.0-0.5.rc1.fc12.noarch requires python-repoze-who-plugins-sa qtparted-0.4.5-19.fc11.ppc64 requires libparted-1.8.so.8()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc64 requires libpqxx-2.6.8.so()(64bit) thunderbird-lightning-1.0-0.6.20090513hg.fc12.ppc64 requires thunderbird < 0:3.0-2.3.b4 vtk-examples-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 From choeger at cs.tu-berlin.de Sun Jul 12 20:04:20 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Sun, 12 Jul 2009 22:04:20 +0200 Subject: RFC: cronKit In-Reply-To: <1247356441.31951.1.camel@localhost> References: <1246899805.5836.15.camel@choeger6> <1247356441.31951.1.camel@localhost> Message-ID: <1247429060.28925.2.camel@choeger6> Am Sonntag, den 12.07.2009, 01:54 +0200 schrieb Christoph Wickert: > How about http://www.gnomefiles.org/app.php/DoThisNow Looks, good, thanks Christoph. > No more kits please. ;) Whatever the new software would be named, pls > don't make another *kit. What about a KitKit to manage tham all? Or NameKit for controlling how newly created software will be named? ;) -------------- 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 fedora at camperquake.de Sun Jul 12 20:06:52 2009 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 12 Jul 2009 22:06:52 +0200 Subject: rawhide hosed after latest update: everything segfaults In-Reply-To: <87zlbab4pg.fsf@meyering.net> References: <87zlbab4pg.fsf@meyering.net> Message-ID: <20090712220652.005832f1@fred.camperquake.de> Hi. On Sun, 12 Jul 2009 12:01:15 +0200, Jim Meyering wrote > Jakub Jelinek's comments suggesting how to recover worked for me: > > https://bugzilla.redhat.com/show_bug.cgi?id=509655#c13 In order to upgrade prelink (or glibc, in my case) without sinking the whole system do the following: a) set PRELINKING=no in /etc/sysconfig/prelink b) run /etc/cron.daily/prelink c) Upgrade. Optional: d) set PRELINKING=yes in /etc/sysconfig/prelink Even more optional, as it will be run later sometime by cron: e) run /etc/cron.daily/prelink From choeger at cs.tu-berlin.de Sun Jul 12 20:09:43 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Sun, 12 Jul 2009 22:09:43 +0200 Subject: RFC: cronKit In-Reply-To: <1247429060.28925.2.camel@choeger6> References: <1246899805.5836.15.camel@choeger6> <1247356441.31951.1.camel@localhost> <1247429060.28925.2.camel@choeger6> Message-ID: <1247429383.28925.4.camel@choeger6> Am Sonntag, den 12.07.2009, 22:04 +0200 schrieb Christoph H?ger: > Am Sonntag, den 12.07.2009, 01:54 +0200 schrieb Christoph Wickert: > > How about http://www.gnomefiles.org/app.php/DoThisNow > > Looks, good, thanks Christoph. Darn. Not free. -------------- 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 christoph.wickert at googlemail.com Sun Jul 12 20:22:47 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Sun, 12 Jul 2009 22:22:47 +0200 Subject: RFC: cronKit In-Reply-To: <1247429383.28925.4.camel@choeger6> References: <1246899805.5836.15.camel@choeger6> <1247356441.31951.1.camel@localhost> <1247429060.28925.2.camel@choeger6> <1247429383.28925.4.camel@choeger6> Message-ID: <1247430167.2845.5.camel@localhost> Am Sonntag, den 12.07.2009, 22:09 +0200 schrieb Christoph H?ger: > Am Sonntag, den 12.07.2009, 22:04 +0200 schrieb Christoph H?ger: > > Am Sonntag, den 12.07.2009, 01:54 +0200 schrieb Christoph Wickert: > > > How about http://www.gnomefiles.org/app.php/DoThisNow > > > > Looks, good, thanks Christoph. > > Darn. Not free. Sorry about that, I didn't notice. Time for a free port I think ;) Regards, Christoph From rawhide at fedoraproject.org Sun Jul 12 21:22:42 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sun, 12 Jul 2009 21:22:42 +0000 Subject: rawhide report: 20090712 changes Message-ID: <20090712212242.GA26411@releng2.fedora.phx.redhat.com> Compose started at Sun Jul 12 06:15:20 UTC 2009 New package ModemManager Mobile broadband modem management service New package R-RM2 Revenue Management and Pricing for R New package erlang-eradius RADIUS authentication/accounting for erlang apps New package morse2txt Morse Code Reader New package nurbs++ Non Uniform Rational Basis Spline (NURBS) library for C++ New package olpc-library OLPC library files and scripts New package pondus A personal weight management program New package qrupdate A Fortran library for fast updates of QR and Cholesky decompositions Updated Packages: abby-0.4.1-1.fc12 ----------------- * Sat Jul 11 2009 Nicoleau Fabien 0.4.1-1 - Rebuild for 0.4.1 * Mon Jun 22 2009 Nicoleau Fabien 0.3.0-1 - Rebuild for 0.3.0 anki-0.9.9.8.5-1.fc12 --------------------- * Sun Jul 12 2009 Christian Krause - 0.9.9.8.5-1 - Update to new upstream version 0.9.9.8.5 beldi-0.9.25-1.fc12 ------------------- * Sat Jul 11 2009 Christoph Wickert - 0.9.25-1 - Upgrade to 0.9.25 - BuildRequire dbus-glib and hal-devel for USB support binutils-2.19.51.0.11-24.fc12 ----------------------------- * Sat Jul 11 2009 Jan Kratochvil 2.19.51.0.11-24 - Provide uuencode output of the testsuite results. bouncycastle-1.43-3.fc12 ------------------------ * Sat Jul 11 2009 Orcan Ogetbil - 1.43-3 - Raise java requirement to >= 1.7 once again. cclive-0.4.5-1.fc12 ------------------- * Sat Jul 11 2009 Nicoleau Fabien 0.4.5-1 - Rebuild for 0.4.5 * Mon Jun 22 2009 Nicoleau Fabien 0.4.4-1 - Rebuild for 0.4.4 clive-2.2.2-1.fc12 ------------------ * Sat Jul 11 2009 Nicoleau Fabien 2.2.2-1 - Rebuild for 2.2.2 - Now using Makefile.PL install type * Mon Jun 22 2009 Nicoleau Fabien 2.2.1-1 - Rebuild for 2.2.1 compiz-0.8.2-6.fc12 ------------------- * Sat Jul 11 2009 Adel Gadllah - 0.8.2-6 - Fix build compiz-fusion-0.8.2-2.fc12 -------------------------- * Fri Jul 10 2009 Adel Gadllah 0.8.2-2 - Don't ship the wall plugin, moved to the compiz package edb-0.9.10-1.fc12 ----------------- * Sat Jul 11 2009 Nicoleau Fabien 0.9.10-1 - Rebuild for 0.9.10 fio-1.31-1.fc12 --------------- * Sat Jul 11 2009 Eric Sandeen 1.31-1 - Much newer upstream version firebird-2.1.2.18118.0-9.fc12 ----------------------------- * Sat Jul 11 2009 Philippe Makowski 2.1.2.18118.0-9 - change xinetd script (rh #506528) - add missing library (and header files) for build php4-interbase module (rh #506728) - update README.fedora - automatically created user now have /bin/nologin as shell to make things a little more secure guilt-0.32.1-2.fc12 ------------------- * Sat Jul 11 2009 Eric Sandeen 0.32.1-1 - New upstream version * Sat Jul 11 2009 Eric Sandeen 0.32.1-2 - Fix asciidoc call so it works. hunspell-az-0.20040827-3.fc12 ----------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20040827-3 - tidy spec hunspell-cop-0.2.0-3.fc12 ------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.2.0-3 - tidy spec hunspell-csb-0.20050311-3.fc12 ------------------------------ * Sat Jul 11 2009 Caolan McNamara - 0.20050311-3 - tidy spec hunspell-cy-0.20040425-4.fc12 ----------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20040425-4 - tidy spec hunspell-de-0.20090107-3.fc12 ----------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20090107-3 - tidy spec hunspell-en-0.20090216-5.fc12 ----------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20090216-5 - tidy spec hunspell-fj-0.20050811-3.fc12 ----------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20050811-3 - tidy spec hunspell-fo-0.2.36-2.fc12 ------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.2.36-2 - tidy spec hunspell-fur-0.20050912-3.fc12 ------------------------------ * Sat Jul 11 2009 Caolan McNamara - 0.20050912-3 - tidy spec hunspell-gd-1.0.0-0.2.rc.1.fc12 ------------------------------- * Sat Jul 11 2009 Caolan McNamara - 1.0.0-0.2.rc.1 - tidy spec hunspell-gv-0.20040505-3.fc12 ----------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20040505-3 - tidy spec hunspell-hil-0.20050406-3.fc12 ------------------------------ * Sat Jul 11 2009 Caolan McNamara - 0.20050406-3 - tidy spec hunspell-is-0.20060928-4.fc12 ----------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20060928-4 - tidy spec hunspell-kk-1.0-2.fc12 ---------------------- * Sat Jul 11 2009 Caolan McNamara - 1.0-2 - tidy spec hunspell-ky-0.20090415-2.fc12 ----------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20090414-2 - preserve timestamp hunspell-la-0.20080903-3.fc12 ----------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20080903-3 - tidy spec hunspell-lt-1.2.1-4.fc12 ------------------------ * Sat Jul 11 2009 Caolan McNamara - 1.2.1-4 - clean spec hunspell-mg-0.20050109-3.fc12 ----------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20050109-3 - tidy spec hunspell-nl-1.00g-5.fc12 ------------------------ * Sat Jul 11 2009 Caolan McNamara - 1.00g-5 - retain timestamp hunspell-no-2.0.10-4.fc12 ------------------------- * Sat Jul 11 2009 Caolan McNamara - 2.0.10-4 - tidy spec hunspell-ny-0.20050108-3.fc12 ----------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20050108-3 - tidy spec hunspell-pt-0.20090702-2.fc12 ----------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20090702-2 - tidy spec hunspell-sw-0.20050819-3.fc12 ----------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20050819-3 - tidy spec hunspell-tet-0.20050108-4.fc12 ------------------------------ * Sat Jul 11 2009 Caolan McNamara - 0.20050108-4 - tidy spec hunspell-tl-0.20050109-3.fc12 ----------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20050109-3 - tidy spec hunspell-wa-0.4.15-3.fc12 ------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.4.15-3 - tidy spec hyphen-de-0.20060120-4.fc12 --------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20060120-4 - tidy spec hyphen-is-0.20030920-3.fc12 --------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20030920-3 - tidy spec hyphen-nl-0.20050617-4.fc12 --------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20050617-4 - tidy spec hyphen-pl-0.20060726-3.fc12 --------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20060726-3 - tidy spec hyphen-sk-0.20031227-4.fc12 --------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20031227-4 - tidy spec hyphen-sv-1.00.1-3.fc12 ----------------------- * Sat Jul 11 2009 Caolan McNamara - 1.00.1-3 - tidy spec itcl-3.4-4.fc12 --------------- * Sat Jul 11 2009 Wart - 3.4-4 - Fix bad logic for locating itcl.tcl from the C bindings itk-3.4-4.fc12 -------------- * Sat Jul 11 2009 Wart - 3.4-4 - Fix bad logic for locating itk.tcl from the C bindings (bz #485252) iw-0.9.15-1.fc12 ---------------- * Sat Jul 11 2009 Adel Gadllah 0.9.15-1 - Update to 0.9.15 libguestfs-1.0.58-2.fc12 ------------------------ libtextcat-2.2-7.fc12 --------------------- * Sat Jul 11 2009 Caolan McNamara 2.2-7 - remove rpmlint warnings lxterminal-0.1.6-1.fc12 ----------------------- * Sat Jul 11 2009 Christoph Wickert - 0.1.6-1 - Update to 0.1.6 - Remove missing-icons.patch, changes got upstreamed mediawiki-1.15.0-47.fc12 ------------------------ * Sat Jul 11 2009 Axel Thimm - 1.15.0-47 - Fix api.php breakage. * Sat Jun 13 2009 Axel Thimm - 1.15.0-46 - Update to 1.15.0. * Thu Apr 16 2009 S390x secondary arch maintainer - ExcludeArch sparc64, s390, s390x as we don't have OCaml on those archs (added sparc64 per request from the sparc maintainer) mono-tools-2.4.2-3.fc12 ----------------------- * Sat Jul 11 2009 Christian Krause - 2.4.2-2 - Add BR webkit-sharp-devel to build the webkit engine for monodoc (BZ 478650) - Add mono(gtkhtml-sharp) as run-time requirement since it is needed by the gtkhtml engine of monodoc (BZ 478650) - Minor spec file beautification to fix some rpmlint warnings * Sat Jul 11 2009 Christian Krause - 2.4.2-3 - Add mono(webkit-sharp) as run-time requirement since it is needed by the webkit engine of monodoc (BZ 478650) - More minor spec file beautifications to fix rpmlint warnings mythes-ca-1.5.0-2.fc12 ---------------------- * Sat Jul 11 2009 Caol?n McNamara - 1.5.0-2 - tidy spec mythes-da-0.20090522-2.fc12 --------------------------- * Sat Jul 11 2009 Caol?n McNamara - 0.20090522-2 - tidy spec mythes-de-0.20090708-2.fc12 --------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20090708-2 - tidy spec mythes-el-0.20070412-4.fc12 --------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20070412-4 - tidy spec mythes-es-0.20090708-2.fc12 --------------------------- * Sat Jul 11 2009 Caol?n McNamara - 0.20090708-2 - tidy spec mythes-ga-0.20071001-4.fc12 --------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20071001-4 - tidy spec mythes-nl-0.20090708-2.fc12 --------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20090708-2 - tidy spec mythes-pt-0.20060817-3.fc12 --------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20060817-3 - tidy spec mythes-sk-0.20090707-2.fc12 --------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20090707-2 - tidy spec mythes-sl-0.20090708-2.fc12 --------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.20090708-2 - tidy spec openoffice-lv-0.8-0.2.b1.fc12 ----------------------------- * Sat Jul 11 2009 Caolan McNamara - 0.8-0.2.b1 - tidy spec perl-WWW-Curl-4.09-1.fc12 ------------------------- * Sat Jul 11 2009 Nicoleau Fabien - 4.09-1 - Rebuild for 4.09 php-pear-Cache-Lite-1.7.8-1.fc12 -------------------------------- * Wed Jul 08 2009 Remi Collet 1.7.8-1 - update to 1.7.8 (bugfix) python-markdown-2.0.1-1.fc12 ---------------------------- * Sat Jul 11 2009 Thomas Moschny - 2.0.1-1 - Update to 2.0.1. - Upstream stripped .py of the cmdline script. python-markdown2-1.0.1.13-1.fc12 -------------------------------- * Sat Jul 11 2009 Thomas Moschny - 1.0.1.13-1 - Update to 1.0.1.13. virtaal-0.4.0-0.1.beta1.fc12 ---------------------------- * Tue Jun 30 2009 Dwayne Bailey - 0.4.0-0.1.beta1 - Update to 0.4.0 beta1 - Backport r11846 --nodepcheck * Wed Apr 15 2009 Dwayne Bailey - 0.3.1-3 - Update icon installation to latest Fedora guidelines Summary: Added Packages: 8 Removed Packages: 0 Modified Packages: 69 Broken deps for i386 ---------------------------------------------------------- CodeAnalyst-gui-2.8.54-14.fc12.i586 requires libbfd-2.19.51.0.11-23.fc12.so DeviceKit-disks-005-2.fc12.i586 requires libparted-1.8.so.8 R-RScaLAPACK-0.5.1-19.fc11.i586 requires openmpi-libs 1:anjuta-2.26.1.0-1.fc12.i586 requires libgdl-1.so.0 bmpx-0.40.14-8.fc11.i386 requires libboost_iostreams-mt.so.4 bmpx-0.40.14-8.fc11.i386 requires libboost_regex-mt.so.4 clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.i586 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.i586 requires gauche = 0:0.8.13 gnome-python2-gdl-2.25.3-4.fc12.i586 requires libgdl-1.so.0 gparted-0.4.5-2.fc12.i586 requires libparted-1.8.so.8 gtranslator-1.9.5-1.fc12.i586 requires libgdl-1.so.0 libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 orsa-0.7.0-8.fc11.i586 requires libcln.so.5 ppl-swiprolog-0.10.2-3.fc12.i586 requires libpl.so.5.7.6 pyclutter-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.i386 requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.i386 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.i586 requires libgeos-3.0.3.so python-repoze-what-plugins-sql-1.0-0.5.rc1.fc12.noarch requires python-repoze-who-plugins-sa qtparted-0.4.5-19.fc11.i586 requires libparted-1.8.so.8 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.i586 requires libpqxx-2.6.8.so springlobby-0.0.1.10461-1.fc12.i586 requires libtorrent-rasterbar.so.3 thunderbird-lightning-1.0-0.6.20090513hg.fc12.i586 requires thunderbird < 0:3.0-2.3.b4 vtk-examples-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 Broken deps for x86_64 ---------------------------------------------------------- CodeAnalyst-gui-2.8.54-14.fc12.i586 requires libbfd-2.19.51.0.11-23.fc12.so CodeAnalyst-gui-2.8.54-14.fc12.x86_64 requires libbfd-2.19.51.0.11-23.fc12.so()(64bit) DeviceKit-disks-005-2.fc12.x86_64 requires libparted-1.8.so.8()(64bit) R-RScaLAPACK-0.5.1-19.fc11.x86_64 requires openmpi-libs 1:anjuta-2.26.1.0-1.fc12.i586 requires libgdl-1.so.0 1:anjuta-2.26.1.0-1.fc12.x86_64 requires libgdl-1.so.0()(64bit) bmpx-0.40.14-8.fc11.x86_64 requires libboost_regex.so.4()(64bit) bmpx-0.40.14-8.fc11.x86_64 requires libboost_iostreams.so.4()(64bit) clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.x86_64 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.x86_64 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.x86_64 requires gauche = 0:0.8.13 gnome-python2-gdl-2.25.3-4.fc12.x86_64 requires libgdl-1.so.0()(64bit) gparted-0.4.5-2.fc12.x86_64 requires libparted-1.8.so.8()(64bit) gtranslator-1.9.5-1.fc12.x86_64 requires libgdl-1.so.0()(64bit) libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.x86_64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 libprojectM-1.2.0-9.fc11.x86_64 requires libftgl.so.0()(64bit) orsa-0.7.0-8.fc11.i586 requires libcln.so.5 orsa-0.7.0-8.fc11.x86_64 requires libcln.so.5()(64bit) ppl-swiprolog-0.10.2-3.fc12.x86_64 requires libpl.so.5.7.6()(64bit) pyclutter-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.x86_64 requires libgeos-3.0.3.so()(64bit) python-repoze-what-plugins-sql-1.0-0.5.rc1.fc12.noarch requires python-repoze-who-plugins-sa qtparted-0.4.5-19.fc11.x86_64 requires libparted-1.8.so.8()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.x86_64 requires libpqxx-2.6.8.so()(64bit) springlobby-0.0.1.10461-1.fc12.x86_64 requires libtorrent-rasterbar.so.3()(64bit) thunderbird-lightning-1.0-0.6.20090513hg.fc12.x86_64 requires thunderbird < 0:3.0-2.3.b4 vtk-examples-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 Broken deps for ppc ---------------------------------------------------------- DeviceKit-disks-005-2.fc12.ppc requires libparted-1.8.so.8 R-RScaLAPACK-0.5.1-19.fc11.ppc requires openmpi-libs 1:anjuta-2.26.1.0-1.fc12.ppc requires libgdl-1.so.0 1:anjuta-2.26.1.0-1.fc12.ppc64 requires libgdl-1.so.0()(64bit) bmpx-0.40.14-8.fc11.ppc requires libboost_iostreams-mt.so.4 bmpx-0.40.14-8.fc11.ppc requires libboost_regex-mt.so.4 clutter-cairo-0.8.2-3.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.ppc requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.ppc requires gauche = 0:0.8.13 gnome-python2-gdl-2.25.3-4.fc12.ppc requires libgdl-1.so.0 gparted-0.4.5-2.fc12.ppc requires libparted-1.8.so.8 gtranslator-1.9.5-1.fc12.ppc requires libgdl-1.so.0 libchamplain-0.2.9-1.fc11.ppc requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc requires libftgl.so.0 libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) orsa-0.7.0-8.fc11.ppc requires libcln.so.5 orsa-0.7.0-8.fc11.ppc64 requires libcln.so.5()(64bit) ppl-swiprolog-0.10.2-3.fc12.ppc requires libpl.so.5.7.6 pyclutter-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.ppc requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.ppc requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.ppc requires libgeos-3.0.3.so python-repoze-what-plugins-sql-1.0-0.5.rc1.fc12.noarch requires python-repoze-who-plugins-sa qtparted-0.4.5-19.fc11.ppc requires libparted-1.8.so.8 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc requires libpqxx-2.6.8.so thunderbird-lightning-1.0-0.6.20090513hg.fc12.ppc requires thunderbird < 0:3.0-2.3.b4 vtk-examples-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 Broken deps for ppc64 ---------------------------------------------------------- DeviceKit-disks-005-2.fc12.ppc64 requires libparted-1.8.so.8()(64bit) R-RScaLAPACK-0.5.1-19.fc11.ppc64 requires openmpi-libs 1:anjuta-2.26.1.0-1.fc12.ppc64 requires libgdl-1.so.0()(64bit) bmpx-0.40.14-8.fc11.ppc64 requires libboost_regex.so.4()(64bit) bmpx-0.40.14-8.fc11.ppc64 requires libboost_iostreams.so.4()(64bit) clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) gnome-python2-gdl-2.25.3-4.fc12.ppc64 requires libgdl-1.so.0()(64bit) gparted-0.4.5-2.fc12.ppc64 requires libparted-1.8.so.8()(64bit) gtranslator-1.9.5-1.fc12.ppc64 requires libgdl-1.so.0()(64bit) libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) orsa-0.7.0-8.fc11.ppc64 requires libcln.so.5()(64bit) ppl-swiprolog-0.10.2-3.fc12.ppc64 requires libpl.so.5.7.6()(64bit) pyclutter-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.ppc64 requires libgeos-3.0.3.so()(64bit) python-mwlib-0.11.2-2.20090522hg2956.fc12.ppc64 requires LabPlot python-repoze-what-plugins-sql-1.0-0.5.rc1.fc12.noarch requires python-repoze-who-plugins-sa qtparted-0.4.5-19.fc11.ppc64 requires libparted-1.8.so.8()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc64 requires libpqxx-2.6.8.so()(64bit) thunderbird-lightning-1.0-0.6.20090513hg.fc12.ppc64 requires thunderbird < 0:3.0-2.3.b4 vtk-examples-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 From limb at jcomserv.net Mon Jul 13 01:17:42 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Sun, 12 Jul 2009 20:17:42 -0500 Subject: Heads UP - PHP 5.3.0 in rawhide with new ABI/API. In-Reply-To: <4A5A2017.3090409@FamilleCollet.com> References: <4A5A2017.3090409@FamilleCollet.com> Message-ID: <38617c76f135677691f6b8d0f692d64b.squirrel@secure.jcomserv.net> > Hi, > > PHP 5.3.0 freshly build in Rawhide. > > $ phpize --version > Configuring for: > PHP Api Version: 20090626 > Zend Module Api No: 20090626 > Zend Extension Api No: 220090626 > > > REMOVED sub-packages > > - php-dbase (not maintained) > - php-mhash (not maintained) Is it possible to keep this?? I have a package that depends on it, and there may be others, though I have not checked.? If not, is there a replacement, or would you recommend that I construct and submit for review my own package for it? > - php-ncurses (moved to pecl, see php-pecl-ncurses) > > NEW sub-packages > > - php-intl > - php-enchant > > NEW extensions > > - php-phar (in php-common and php-cli) > - php-fileinfo (in php-common) > - php-sqlite3 (in php-pdo) > > DEAD Packages > > - php-pecl-phar > - php-pecl-Fileinfo > > NEW Package > > - php-pecl-ncurses : Waiting for Review (please do it) > https://bugzilla.redhat.com/show_bug.cgi?id=510913 > > I've start working on building all extensions (upgrading to latest > version when needed) I know, starting with the ones I own. > > > > Most webapp should work (probably with E_DEPRECATED warning, but it's > disabled for production use). > A lot of webapp have been already fixed upstream (phpMyAdmin, p.e.) > Some will probably require some works. > > > Remi. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- in your fear, speak only peace in your fear, seek only love -d. bowie -------------- next part -------------- An HTML attachment was scrubbed... URL: From kwade at redhat.com Mon Jul 13 01:48:59 2009 From: kwade at redhat.com (Karsten Wade) Date: Sun, 12 Jul 2009 18:48:59 -0700 Subject: relicensing of Fedora wiki/docs (OPL => CC BY SA) In-Reply-To: <4A538B6F.6050209@herr-schmitt.de> References: <20090707075849.GI15350@calliope.phig.org> <4A538B6F.6050209@herr-schmitt.de> Message-ID: <20090713014859.GM29035@calliope.phig.org> On Tue, Jul 07, 2009 at 07:52:47PM +0200, Jochen Schmitt wrote: > > What are the main diferences beetween OPL 1.0 and the new CC BY SA 3.0 > license. I cannot provide a legalistic difference, except to note that the OPL was written by a non-lawyer and has been explained to me as containing legal flaws, whereas the CC licenses are lawyer-written, have iterated a few times, and are generally well used/tested. Regarding features, that also takes a deeper legal understanding than I can provide. The CC seems to be more liberal in allowing derivatives to be sub-licensed with a similar license, but that is just an understanding have and is not a legal opinion. The biggest differences I think I cover in my article[1], namely: 1. OPL is deprecated, unsupported, and not lawyer preferred; CC is very popular, supported, and lawyer preffered. ** More chances to reuse CC licensed content. ** Makes our content more useful for other people to blend in to a CC work. 2. Very little open content exists under the OPL by comparison to the CC. The OPL is a very small content island, the CC is a very large content sub-continent. - Karsten [1] http://iquaid.org/2009/07/06/why-relicense-fedora-documentation-and-wiki-content/ -- Karsten 'quaid' Wade, Community Gardener http://quaid.fedorapeople.org AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Fedora at FamilleCollet.com Mon Jul 13 06:47:18 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Mon, 13 Jul 2009 08:47:18 +0200 Subject: Heads UP - PHP 5.3.0 in rawhide with new ABI/API. In-Reply-To: <38617c76f135677691f6b8d0f692d64b.squirrel@secure.jcomserv.net> References: <4A5A2017.3090409@FamilleCollet.com> <38617c76f135677691f6b8d0f692d64b.squirrel@secure.jcomserv.net> Message-ID: <4A5AD876.3010206@FamilleCollet.com> Le 13/07/2009 03:17, Jon Ciesla a ?crit : >> - php-mhash (not maintained) > > Is it possible to keep this? I have a package that depends on it, and > there may be others, though I have not checked. $ repoquery --whatrequires php-mhash php-pear-Net-DNS-0:1.0.0-3.fc11.noarch limph-0:1.9.5-4.fc11.noarch limph-hostagent-0:1.9.5-4.fc11.noarch php-pear-Crypt-CHAP-0:1.0.1-2.fc11.noarch php-pear-Auth-RADIUS-0:1.0.6-2.fc11.noarch > If not, is there a > replacement, or would you recommend that I construct and submit for > review my own package for it? This extension is not maintained, removed from main php and not transferred to PECL. The recommended new hash solution is HASH, see http://fr2.php.net/mhash http://fr2.php.net/hash The other solution is to become upstream for mhash ;) Remi. From jmoskovc at redhat.com Mon Jul 13 11:10:58 2009 From: jmoskovc at redhat.com (Jiri Moskovcak) Date: Mon, 13 Jul 2009 13:10:58 +0200 Subject: non-blocking dbus server In-Reply-To: References: <4A57077D.2020604@redhat.com> Message-ID: <4A5B1642.8030203@redhat.com> On 07/10/2009 06:20 PM, Colin Walters wrote: > Your options are: > > 1) Method returns "work item id", send a signal WorkDone with the id This was my first idea.. > 2) Agent pattern, the server makes calls back to the client using its > unique name. Sounds good, will take a look at this. > 3) Infinite timeouts on method calls is in dbus git master > I don't see how this could help me, I don't have problem with timeout, but the problem is "blocked server" during the method call. Thanks for the hints, Jirka -------------- next part -------------- A non-text attachment was scrubbed... Name: jmoskovc.vcf Type: text/x-vcard Size: 126 bytes Desc: not available URL: From sassmann at redhat.com Mon Jul 13 11:31:01 2009 From: sassmann at redhat.com (Stefan Assmann) Date: Mon, 13 Jul 2009 13:31:01 +0200 Subject: $HOME/bin Message-ID: <4A5B1AF5.90406@redhat.com> Hi all, I was wondering why there's no $HOME/bin directory and $HOME/bin not mentioned in the $PATH variable. Any particular reason not to have that by default? Stefan -- Stefan Assmann | Red Hat GmbH Software Engineer | Otto-Hahn-Strasse 20, 85609 Dornach | HR: Amtsgericht Muenchen HRB 153243 | GF: Brendan Lane, Charlie Peters, sassmann at redhat.com | Michael Cunningham, Charles Cachera From martin.sourada at gmail.com Mon Jul 13 11:47:28 2009 From: martin.sourada at gmail.com (Martin Sourada) Date: Mon, 13 Jul 2009 11:47:28 +0000 Subject: $HOME/bin In-Reply-To: <4A5B1AF5.90406@redhat.com> References: <4A5B1AF5.90406@redhat.com> Message-ID: <1247485648.2397.48.camel@pc-notebook.kolej.mff.cuni.cz> On Mon, 2009-07-13 at 13:31 +0200, Stefan Assmann wrote: > Hi all, > > I was wondering why there's no $HOME/bin directory and $HOME/bin not > mentioned in the $PATH variable. Any particular reason not to have that > by default? > > Stefan Hi, because most people don't need it? Well, I would not be exactly against making this default, but I'm not sure if $HOME/bin would be the right one... Since xdg-dirs came around I use $HOME/Applications/bin for that purpose to keep $HOME cleaner (even though this particular directory isn't in the scheme...) But I cannot really argue either way... Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bochecha at fedoraproject.org Mon Jul 13 12:07:08 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Mon, 13 Jul 2009 14:07:08 +0200 Subject: $HOME/bin In-Reply-To: <1247485648.2397.48.camel@pc-notebook.kolej.mff.cuni.cz> References: <4A5B1AF5.90406@redhat.com> <1247485648.2397.48.camel@pc-notebook.kolej.mff.cuni.cz> Message-ID: <2d319b780907130507w48a26dc5vf00e5e1b89ab9d1@mail.gmail.com> Hi, >> I was wondering why there's no $HOME/bin directory and $HOME/bin not >> mentioned in the $PATH variable. Any particular reason not to have that >> by default? >> >> ? ?Stefan > Hi, > > because most people don't need it? True. Look at your /etc/profile (or ~/.bash_profile, I don't remember). There should be something like: [ -d ~/bin ] && PATH=~/bin:$PATH Which means that the folder will be added to your PATH if it exists. I'm on Windows XP right now, so I can't verify it, but iirc there's something like that. ---------- Mathieu Bridon (bochecha) From ovasik at redhat.com Mon Jul 13 12:08:55 2009 From: ovasik at redhat.com (=?UTF-8?Q?Ond=C5=99ej_Va=C5=A1=C3=ADk?=) Date: Mon, 13 Jul 2009 14:08:55 +0200 Subject: $HOME/bin In-Reply-To: <4A5B1AF5.90406@redhat.com> References: <4A5B1AF5.90406@redhat.com> Message-ID: <1247486935.3863.7.camel@dhcp-lab-219.englab.brq.redhat.com> Stefan Assmann wrote: > Hi all, > > I was wondering why there's no $HOME/bin directory and $HOME/bin not > mentioned in the $PATH variable. Any particular reason not to have that > by default? $HOME/bin is not on every system and the other default directories in default PATH are(at least on the most of systems ;) ). However, some Linux distros do add something as: # set PATH so it includes user's private bin if it exists if [ -d "$HOME/bin" ] ; then PATH="$HOME/bin:$PATH" fi as default - so this dir gets added automatically when does exist. I'm generally +1 for changing the default that way - as it would not change anything for users without that directory. Greetings, Ond?ej Va??k -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Toto je digit?ln? podepsan? ??st zpr?vy URL: From fabian.deutsch at gmx.de Mon Jul 13 12:15:12 2009 From: fabian.deutsch at gmx.de (Fabian Deutsch) Date: Mon, 13 Jul 2009 14:15:12 +0200 Subject: $HOME/bin In-Reply-To: <1247486935.3863.7.camel@dhcp-lab-219.englab.brq.redhat.com> References: <4A5B1AF5.90406@redhat.com> <1247486935.3863.7.camel@dhcp-lab-219.englab.brq.redhat.com> Message-ID: <1247487312.4713.4.camel@decade.local> Hey, Am Montag, den 13.07.2009, 14:08 +0200 schrieb Ond?ej Va??k: > Stefan Assmann wrote: > > Hi all, > > > > I was wondering why there's no $HOME/bin directory and $HOME/bin not > > mentioned in the $PATH variable. Any particular reason not to have that > > by default? > > $HOME/bin is not on every system and the other default directories in > default PATH are(at least on the most of systems ;) ). However, some > Linux distros do add something as: > # set PATH so it includes user's private bin if it exists > if [ -d "$HOME/bin" ] ; then > PATH="$HOME/bin:$PATH" > fi Adding something like this raises security concerns, as this opens doors for malicious software. E.g. some application could but a binary named "bash" in ~/bin, which would be run before /bin/bash. So, if at all, let's use $PATH:$HOME/PATH - fabian > as default - so this dir gets added automatically when does exist. > I'm generally +1 for changing the default that way - as it would not > change anything for users without that directory. > > Greetings, > Ond?ej Va??k > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From stickster at gmail.com Mon Jul 13 12:15:28 2009 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 13 Jul 2009 08:15:28 -0400 Subject: $HOME/bin In-Reply-To: <1247486935.3863.7.camel@dhcp-lab-219.englab.brq.redhat.com> References: <4A5B1AF5.90406@redhat.com> <1247486935.3863.7.camel@dhcp-lab-219.englab.brq.redhat.com> Message-ID: <20090713121528.GG3257@localhost.localdomain> On Mon, Jul 13, 2009 at 02:08:55PM +0200, Ond?ej Va??k wrote: > Stefan Assmann wrote: > > Hi all, > > > > I was wondering why there's no $HOME/bin directory and $HOME/bin not > > mentioned in the $PATH variable. Any particular reason not to have that > > by default? > > $HOME/bin is not on every system and the other default directories in > default PATH are(at least on the most of systems ;) ). However, some > Linux distros do add something as: > # set PATH so it includes user's private bin if it exists > if [ -d "$HOME/bin" ] ; then > PATH="$HOME/bin:$PATH" > fi > as default - so this dir gets added automatically when does exist. > I'm generally +1 for changing the default that way - as it would not > change anything for users without that directory. I would only want this at the *end* of the current PATH, not the beginning, for obvious security reasons. -- 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 emmanuel.seyman at club-internet.fr Mon Jul 13 12:28:30 2009 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Mon, 13 Jul 2009 14:28:30 +0200 Subject: $HOME/bin In-Reply-To: <4A5B1AF5.90406@redhat.com> References: <4A5B1AF5.90406@redhat.com> Message-ID: <20090713122830.GA14930@orient.maison.lan> * Stefan Assmann [13/07/2009 13:53] : > > I was wondering why there's no $HOME/bin directory and $HOME/bin not > mentioned in the $PATH variable. Any particular reason not to have that > by default? [manu at orient ~]$ rpm -q fedora-release fedora-release-11-1.noarch [manu at orient ~]$ rpm -qf /etc/skel/.bash_profile bash-4.0-6.fc11.i586 [manu at orient ~]$ rpm -qV bash-4.0-6.fc11.i586 [manu at orient ~]$ grep PATH /etc/skel/.bash_profile PATH=$PATH:$HOME/bin export PATH Emmanuel From petersen at redhat.com Mon Jul 13 12:46:31 2009 From: petersen at redhat.com (Jens Petersen) Date: Mon, 13 Jul 2009 08:46:31 -0400 (EDT) Subject: Open Seat on the Fedora Packaging Committee In-Reply-To: <4A57BEC1.1010000@redhat.com> Message-ID: <206461988.508471247489191046.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> > If you're interested in this seat, please email me. I would be interested. Dunno if my geolocation helps or not. Jens From choeger at cs.tu-berlin.de Mon Jul 13 12:54:01 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 13 Jul 2009 14:54:01 +0200 Subject: RFC: cronKit In-Reply-To: <1247430167.2845.5.camel@localhost> References: <1246899805.5836.15.camel@choeger6> <1247356441.31951.1.camel@localhost> <1247429060.28925.2.camel@choeger6> <1247429383.28925.4.camel@choeger6> <1247430167.2845.5.camel@localhost> Message-ID: <1247489641.6861.2.camel@choeger6> Am Sonntag, den 12.07.2009, 22:22 +0200 schrieb Christoph Wickert: > Am Sonntag, den 12.07.2009, 22:09 +0200 schrieb Christoph H?ger: > > Am Sonntag, den 12.07.2009, 22:04 +0200 schrieb Christoph H?ger: > > > Am Sonntag, den 12.07.2009, 01:54 +0200 schrieb Christoph Wickert: > > > > How about http://www.gnomefiles.org/app.php/DoThisNow > > > > > > Looks, good, thanks Christoph. > > > > Darn. Not free. > > Sorry about that, I didn't notice. Time for a free port I think ;) Yes, after my exam in SOA, I can definetely need something to work on besides my thesis. That will fit that hole. I'll still need to see what language and tools I'll use. -------------- 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 maxamillion at gmail.com Mon Jul 13 13:12:19 2009 From: maxamillion at gmail.com (Adam Miller) Date: Mon, 13 Jul 2009 08:12:19 -0500 Subject: Fail2ban + Shorewall Question In-Reply-To: <94C56C28-284C-4077-8EC0-149A615D1C68@5dollarwhitebox.org> References: <08257EB7-9DC9-402A-B749-FD0D4D91CBBE@5dollarwhitebox.org> <645d17210907101502x7fae7b9dvd8305abf26ac2c97@mail.gmail.com> <4A589BE6.5090305@fedoraproject.org> <045513D3-871E-40C5-896D-6C13987A0460@5dollarwhitebox.org> <4A58DF11.4070609@fedoraproject.org> <94C56C28-284C-4077-8EC0-149A615D1C68@5dollarwhitebox.org> Message-ID: I maintain fail2ban for EPEL, I can just take the Fedora package as well unless someone else has a relatively high interest in doing so (I purely maintain it for EPEL because we use it at work on our servers and Axel said he had no interest in packaging it for EPEL). I've needed to contact Axel in the past and he was very responsive so I wasn't aware there were any issues with his participation in the project. -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From rc040203 at freenet.de Mon Jul 13 13:27:24 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 13 Jul 2009 15:27:24 +0200 Subject: $HOME/bin In-Reply-To: <20090713121528.GG3257@localhost.localdomain> References: <4A5B1AF5.90406@redhat.com> <1247486935.3863.7.camel@dhcp-lab-219.englab.brq.redhat.com> <20090713121528.GG3257@localhost.localdomain> Message-ID: <4A5B363C.5070405@freenet.de> Paul W. Frields wrote: > On Mon, Jul 13, 2009 at 02:08:55PM +0200, Ond?ej Va??k wrote: >> Stefan Assmann wrote: >>> Hi all, >>> >>> I was wondering why there's no $HOME/bin directory and $HOME/bin not >>> mentioned in the $PATH variable. Any particular reason not to have that >>> by default? >> $HOME/bin is not on every system and the other default directories in >> default PATH are(at least on the most of systems ;) ). However, some >> Linux distros do add something as: >> # set PATH so it includes user's private bin if it exists >> if [ -d "$HOME/bin" ] ; then >> PATH="$HOME/bin:$PATH" >> fi >> as default - so this dir gets added automatically when does exist. >> I'm generally +1 for changing the default that way - as it would not >> change anything for users without that directory. > > I would only want this at the *end* of the current PATH, not the > beginning, for obvious security reasons. 1. Your practice to a wide extend defeats one prime rationale for ~/bin: Replacing/Overriding vendor-provided applications by per-user installed versions. 2. Unless using ~/bin as root, these files are user-installed binaries, which under normal circumstances may only have security impacts on user files => What you call "obvious security reasons" are minor concerns. The only real issue you are solving by appending ~/bin instead of prepending ~/bin to $PATH is avoiding application-name conflicts. From mhlavink at redhat.com Mon Jul 13 13:36:55 2009 From: mhlavink at redhat.com (Michal Hlavinka) Date: Mon, 13 Jul 2009 15:36:55 +0200 Subject: $HOME/bin In-Reply-To: <4A5B363C.5070405@freenet.de> References: <4A5B1AF5.90406@redhat.com> <20090713121528.GG3257@localhost.localdomain> <4A5B363C.5070405@freenet.de> Message-ID: <200907131536.55687.mhlavink@redhat.com> > Paul W. Frields wrote: > > On Mon, Jul 13, 2009 at 02:08:55PM +0200, Ond?ej Va??k wrote: > >> Stefan Assmann wrote: > >>> Hi all, > >>> > >>> I was wondering why there's no $HOME/bin directory and $HOME/bin not > >>> mentioned in the $PATH variable. Any particular reason not to have that > >>> by default? > >> > >> $HOME/bin is not on every system and the other default directories in > >> default PATH are(at least on the most of systems ;) ). However, some > >> Linux distros do add something as: > >> # set PATH so it includes user's private bin if it exists > >> if [ -d "$HOME/bin" ] ; then > >> PATH="$HOME/bin:$PATH" > >> fi > >> as default - so this dir gets added automatically when does exist. > >> I'm generally +1 for changing the default that way - as it would not > >> change anything for users without that directory. > > > > I would only want this at the *end* of the current PATH, not the > > beginning, for obvious security reasons. > > 1. Your practice to a wide extend defeats one prime rationale for ~/bin: > Replacing/Overriding vendor-provided applications by per-user installed > versions. > > 2. Unless using ~/bin as root, these files are user-installed binaries, > which under normal circumstances may only have security impacts on user > files => What you call "obvious security reasons" are minor concerns. if "su" (instead of "su -") is used, root will inherit user's environment including PATH. > The only real issue you are solving by appending ~/bin instead of > prepending ~/bin to $PATH is avoiding application-name conflicts. From cpardy at redhat.com Mon Jul 13 13:41:40 2009 From: cpardy at redhat.com (Christopher Pardy) Date: Mon, 13 Jul 2009 09:41:40 -0400 Subject: System-Config-Selinux package review Message-ID: <4A5B3994.7040209@redhat.com> Hello Fedora developers, I'm Christopher Pardy I'll be spending the summer interning at redhat working on Selinux. I'm not sure if I've gone through all the nessesary steps for this, if I haven't please point me to them. I've recently finished splitting off some code from policycoreutils to allow our packages to better conform with the upstream code. I submitted a package review request for this https://bugzilla.redhat.com/show_bug.cgi?id=508922 This is my first package and I'm sure there's tons of issues with it and I would like to get most of them cleared up by the end of the summer. Again if there is any steps I'm missing please let me know. Christopher Pardy From rc040203 at freenet.de Mon Jul 13 13:47:17 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 13 Jul 2009 15:47:17 +0200 Subject: $HOME/bin In-Reply-To: <200907131536.55687.mhlavink@redhat.com> References: <4A5B1AF5.90406@redhat.com> <20090713121528.GG3257@localhost.localdomain> <4A5B363C.5070405@freenet.de> <200907131536.55687.mhlavink@redhat.com> Message-ID: <4A5B3AE5.6040406@freenet.de> Michal Hlavinka wrote: >> Paul W. Frields wrote: >>> On Mon, Jul 13, 2009 at 02:08:55PM +0200, Ond?ej Va??k wrote: >>>> Stefan Assmann wrote: >>>>> Hi all, >>>>> >>>>> I was wondering why there's no $HOME/bin directory and $HOME/bin not >>>>> mentioned in the $PATH variable. Any particular reason not to have that >>>>> by default? >>>> $HOME/bin is not on every system and the other default directories in >>>> default PATH are(at least on the most of systems ;) ). However, some >>>> Linux distros do add something as: >>>> # set PATH so it includes user's private bin if it exists >>>> if [ -d "$HOME/bin" ] ; then >>>> PATH="$HOME/bin:$PATH" >>>> fi >>>> as default - so this dir gets added automatically when does exist. >>>> I'm generally +1 for changing the default that way - as it would not >>>> change anything for users without that directory. >>> I would only want this at the *end* of the current PATH, not the >>> beginning, for obvious security reasons. >> 1. Your practice to a wide extend defeats one prime rationale for ~/bin: >> Replacing/Overriding vendor-provided applications by per-user installed >> versions. >> >> 2. Unless using ~/bin as root, these files are user-installed binaries, >> which under normal circumstances may only have security impacts on user >> files => What you call "obvious security reasons" are minor concerns. > > if "su" (instead of "su -") is used, root will inherit user's environment > including PATH. Yes, but ... we are talking about ordinary users here, not about users who have root access. These people have other means to install packages. For ordinary users, prepending ~/bin to $PATH is the only approach e.g. to replace vendor-supplied applications, the "security risks" are almost non-existent. Ralf From maxamillion at gmail.com Mon Jul 13 13:48:24 2009 From: maxamillion at gmail.com (Adam Miller) Date: Mon, 13 Jul 2009 08:48:24 -0500 Subject: System-Config-Selinux package review In-Reply-To: <4A5B3994.7040209@redhat.com> References: <4A5B3994.7040209@redhat.com> Message-ID: [08:46:58][adam at turnip][src]+ rpmlint scselinux.spec scselinux.spec:91: E: hardcoded-library-path in /usr/lib/python2.6/site-packages/scselinux scselinux.spec:92: E: hardcoded-library-path in /usr/lib/python2.6/site-packages/scselinux/* scselinux.spec:93: E: hardcoded-library-path in /usr/lib/python2.6/site-packages/scselinux-0.1-py2.6.egg-info scselinux.spec: W: mixed-use-of-spaces-and-tabs (spaces: line 61, tab: line 1) 0 packages and 1 specfiles checked; 3 errors, 1 warnings. First thing I would do is handle the rpmlint errors. These are the documents you are probably going to be most interested in: http://fedoraproject.org/wiki/Packaging/ReviewGuidelines https://fedoraproject.org/wiki/Packaging/Guidelines -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From opensource at till.name Mon Jul 13 13:54:01 2009 From: opensource at till.name (Till Maas) Date: Mon, 13 Jul 2009 15:54:01 +0200 Subject: $HOME/bin In-Reply-To: <200907131536.55687.mhlavink@redhat.com> References: <4A5B1AF5.90406@redhat.com> <4A5B363C.5070405@freenet.de> <200907131536.55687.mhlavink@redhat.com> Message-ID: <200907131554.08075.opensource@till.name> On Mon July 13 2009, Michal Hlavinka wrote: > if "su" (instead of "su -") is used, root will inherit user's environment > including PATH. So why should a malicious user be able to change the contents of ~/bin, but not set the variable PATH to an arbitrary value? Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From enrico.scholz at informatik.tu-chemnitz.de Mon Jul 13 13:54:51 2009 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 13 Jul 2009 15:54:51 +0200 Subject: $HOME/bin In-Reply-To: <4A5B1AF5.90406@redhat.com> (Stefan Assmann's message of "Mon\, 13 Jul 2009 13\:31\:01 +0200") References: <4A5B1AF5.90406@redhat.com> Message-ID: <878wis3cyc.fsf@fc5.bigo.ensc.de> Stefan Assmann writes: > I was wondering why there's no $HOME/bin directory and $HOME/bin not > mentioned in the $PATH variable. Any particular reason not to have > that by default? It should be there, but some kind of bug prevents evaluation of ~/.bash_profile (which adds this directory to $PATH). $ echo $PATH /home/ensc/bin:/usr/lib64/qt-3.3/bin:/usr/kerberos/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/games starts the xfrun4 "Run program" application) $ ps wwwe `/sbin/pidof xfrun4` 4220 ? Ss 0:00 /usr/bin/xfrun4 --daemon ... PATH=/usr/local/bin:/usr/bin:/bin:/usr/games It's probably some kind of undebuggable d-bus interaction :( Hence, use xterm to start your applications, but not this buggy desktop crap. Enrico From emmanuel.seyman at club-internet.fr Mon Jul 13 13:55:36 2009 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Mon, 13 Jul 2009 15:55:36 +0200 Subject: $HOME/bin In-Reply-To: <4A5B3AE5.6040406@freenet.de> References: <4A5B1AF5.90406@redhat.com> <20090713121528.GG3257@localhost.localdomain> <4A5B363C.5070405@freenet.de> <200907131536.55687.mhlavink@redhat.com> <4A5B3AE5.6040406@freenet.de> Message-ID: <20090713135536.GA15218@orient.maison.lan> * Ralf Corsepius [13/07/2009 15:50] : > > For ordinary users, prepending ~/bin to $PATH is the only approach e.g. > to replace vendor-supplied applications, the "security risks" are almost > non-existent. You can also use bash aliases to override binary calls. Emmanuel From mnowak at redhat.com Mon Jul 13 14:05:25 2009 From: mnowak at redhat.com (Michal Nowak) Date: Mon, 13 Jul 2009 10:05:25 -0400 (EDT) Subject: Update startup-notification to version 0.10 In-Reply-To: <854209076.325641247493468322.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1302241097.326611247493925142.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Awesome Window Manager [0] requires startup-notification of version 0.10 [1], I filled bug for it [3], however, no action was taken so far. Can some of you desktop folks bump the version, please? The only changes are that XCB support was merged and some code clean up was done [3]. Thanks, Michal -- [0] https://bugzilla.redhat.com/show_bug.cgi?id=awesome [1] http://www.freedesktop.org/software/startup-notification/releases/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=499517 [3] http://lists.freedesktop.org/archives/xdg/2009-January/010176.html From bbbush.yuan at gmail.com Mon Jul 13 14:08:03 2009 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Mon, 13 Jul 2009 22:08:03 +0800 Subject: Help on CMake usage (read gecko's "libdir" variable) Message-ID: <76e72f800907130708t7f8a17e9p60084e91ac9a2658@mail.gmail.com> Hi, The package "chmsee" used to need a patch to read "libdir" variable. The original patch can be found here https://bugzilla.redhat.com/attachment.cgi?id=303660 of https://bugzilla.redhat.com/427622 Now latest chmsee switched to use CMake instead. I cannot figure out how to apply such a patch. Anyone can help? -- bbbush ^_^ From rc040203 at freenet.de Mon Jul 13 14:08:25 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 13 Jul 2009 16:08:25 +0200 Subject: $HOME/bin In-Reply-To: <20090713135536.GA15218@orient.maison.lan> References: <4A5B1AF5.90406@redhat.com> <20090713121528.GG3257@localhost.localdomain> <4A5B363C.5070405@freenet.de> <200907131536.55687.mhlavink@redhat.com> <4A5B3AE5.6040406@freenet.de> <20090713135536.GA15218@orient.maison.lan> Message-ID: <4A5B3FD9.4020500@freenet.de> Emmanuel Seyman wrote: > * Ralf Corsepius [13/07/2009 15:50] : >> For ordinary users, prepending ~/bin to $PATH is the only approach e.g. >> to replace vendor-supplied applications, the "security risks" are almost >> non-existent. > > You can also use bash aliases to override binary calls. Sometimes, but not always. e.g. when testing "application suites" which install many binaries. Ralf From sassmann at redhat.com Mon Jul 13 14:18:59 2009 From: sassmann at redhat.com (Stefan Assmann) Date: Mon, 13 Jul 2009 16:18:59 +0200 Subject: $HOME/bin In-Reply-To: <20090713122830.GA14930@orient.maison.lan> References: <4A5B1AF5.90406@redhat.com> <20090713122830.GA14930@orient.maison.lan> Message-ID: <4A5B4253.3020009@redhat.com> On 13.07.2009 14:28, Emmanuel Seyman wrote: > * Stefan Assmann [13/07/2009 13:53] : >> I was wondering why there's no $HOME/bin directory and $HOME/bin not >> mentioned in the $PATH variable. Any particular reason not to have that >> by default? > > [manu at orient ~]$ rpm -q fedora-release > fedora-release-11-1.noarch > [manu at orient ~]$ rpm -qf /etc/skel/.bash_profile > bash-4.0-6.fc11.i586 > [manu at orient ~]$ rpm -qV bash-4.0-6.fc11.i586 > [manu at orient ~]$ grep PATH /etc/skel/.bash_profile > PATH=$PATH:$HOME/bin > export PATH > > Emmanuel > Thanks for pointing this out! .bash_profile was missing in my home directory, not sure why. Stefan -- Stefan Assmann | Red Hat GmbH Software Engineer | Otto-Hahn-Strasse 20, 85609 Dornach | HR: Amtsgericht Muenchen HRB 153243 | GF: Brendan Lane, Charlie Peters, sassmann at redhat.com | Michael Cunningham, Charles Cachera From mail at marcus-moeller.de Mon Jul 13 14:31:34 2009 From: mail at marcus-moeller.de (Marcus Moeller) Date: Mon, 13 Jul 2009 16:31:34 +0200 Subject: %{_global_cflags} Message-ID: Hi all. In http://fedoraproject.org/wiki/Packaging:RPMMacros#Build_flags_macros %{_global_cflags} is set and %{_optflags} references %{__global_cflags} (double underscores). Is this correct or should it say %{_global_cflags}? Best Regards Marcus From mschwendt at gmail.com Mon Jul 13 15:17:00 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 13 Jul 2009 17:17:00 +0200 Subject: %{_global_cflags} In-Reply-To: References: Message-ID: <20090713171700.2f2cae87@faldor> On Mon, 13 Jul 2009 16:31:34 +0200, Marcus wrote: > Hi all. > > In http://fedoraproject.org/wiki/Packaging:RPMMacros#Build_flags_macros > %{_global_cflags} is set and %{_optflags} references > %{__global_cflags} (double underscores). Is this correct or should it > say %{_global_cflags}? %{optflags} and %{__global_cflags} $ rpm --eval %optflags -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables $ rpm --eval %__global_cflags -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 From orion at cora.nwra.com Mon Jul 13 15:41:25 2009 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 13 Jul 2009 09:41:25 -0600 (MDT) Subject: wine applications In-Reply-To: <4A594BFE.6030102@gmail.com> References: <5f6f8c5f0907101458n60fb60c4mccea3fca6faa83c6@mail.gmail.com> <4A57C6B9.5000702@redhat.com> <5f6f8c5f0907110038q5b68fe6dya4d5a2e799868b4a@mail.gmail.com> <1247305288.2599.2.camel@localhost.localdomain> <4A58BB52.8070005@gmail.com> <4A592867.6000408@gmail.com> <44E99AC8-82AB-4AD5-9CDE-45A3A77C4224@j2solutions.net> <4A594BFE.6030102@gmail.com> Message-ID: <4240.75.171.226.228.1247499685.squirrel@www.cora.nwra.com> On Sat, July 11, 2009 8:35 pm, David wrote: > > I am serious here. Really. The names are...? > See http://appdb.winehq.org/ -- 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 Mon Jul 13 15:36:24 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 13 Jul 2009 16:36:24 +0100 Subject: Possible packages... In-Reply-To: References: Message-ID: <1247499384.2483.40.camel@vaio.local.net> On Sun, 2009-07-05 at 20:15 -0600, Nathanael Noblet wrote: > Apple's Calendar Server. It runs using python 2.5 or greater (I've > installed it on a F11 machine and it work well). I've started looking > at some of its dependancies. 90% of them are in fedora already, and of > the ones in F11, only one if I remember correctly isn't at the version > it requires). It seems like a great addition to Fedora if you ask me. > So basically it would require two new packages, and an update to one > other package (libevent) which is a minor version bump it seems if at > all needed. The Infrastructure group has a rather ongoing project to try and find a really good calendar server system (and then, obviously, package it) to be used as the official Fedora calendaring system (then we could schedule events and all that good stuff in an official Fedora server, and people could access them via CalDAV or web, and all would be roses). It's proved a bit tricky, though, to find a really perfect option. See https://fedoraproject.org/wiki/Infrastructure/Test/Calendering_Solution for most of the details on this project. At present, we seem to be looking at one called Calagator: http://calagator.org/ . > PS3MediaServer. A Java program to talk to a PS3 with DLNA. I'm > guessing this one would have problems because it requires ffmpeg or > mplayer/mencoder... Plus as a java program its probably a bit more > complex to create a proper spec file for. I've made the other kind > often enough, but java ones not so much... There's a sort of 'agreed-upon-right-way-of-doing-this' candidate for this particular need, which is a nice modern GTK+ app and based on gstreamer...but I can't quite pull the name out of long-term storage at present. Someone will probably know what I mean, though. The one most people use (as the one I'm talking about is still a bit alpha) is mediatomb, which is also in Fedora already. Unless this provides something significant the other options don't, it may not be the best place to start, since it looks a bit complex. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From mclasen at redhat.com Mon Jul 13 15:59:38 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 13 Jul 2009 11:59:38 -0400 Subject: Update startup-notification to version 0.10 In-Reply-To: <1302241097.326611247493925142.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1302241097.326611247493925142.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1247500779.1695.0.camel@planemask> On Mon, 2009-07-13 at 10:05 -0400, Michal Nowak wrote: > Awesome Window Manager [0] requires startup-notification of version > 0.10 [1], I filled bug for it [3], however, no action was taken so > far. Can some of you desktop folks bump the version, please? Done From mjg at redhat.com Mon Jul 13 16:10:56 2009 From: mjg at redhat.com (Matthew Garrett) Date: Mon, 13 Jul 2009 17:10:56 +0100 Subject: $HOME/bin In-Reply-To: <878wis3cyc.fsf@fc5.bigo.ensc.de> References: <4A5B1AF5.90406@redhat.com> <878wis3cyc.fsf@fc5.bigo.ensc.de> Message-ID: <20090713161056.GA22709@srcf.ucam.org> On Mon, Jul 13, 2009 at 03:54:51PM +0200, Enrico Scholz wrote: > $ echo $PATH > /home/ensc/bin:/usr/lib64/qt-3.3/bin:/usr/kerberos/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/games > > starts the xfrun4 "Run program" application) > $ ps wwwe `/sbin/pidof xfrun4` > 4220 ? Ss 0:00 /usr/bin/xfrun4 --daemon ... PATH=/usr/local/bin:/usr/bin:/bin:/usr/games .bash_profile is only evaluated for login shells. > It's probably some kind of undebuggable d-bus interaction :( Hence, use > xterm to start your applications, but not this buggy desktop crap. It seems to be working as expected, given the implementation. Please don't blame parts of the software stack just because you don't understand them - it doesn't provide much incentive to improve things. -- Matthew Garrett | mjg59 at srcf.ucam.org From awilliam at redhat.com Mon Jul 13 16:07:47 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 13 Jul 2009 17:07:47 +0100 Subject: http://www.fsf.org/news/dont-depend-on-mono In-Reply-To: References: <4A486F85.7000109@gmail.com> <20090707085653.GB5189@roque.1407.org> <20090707100239.GC5189@roque.1407.org> <20090707201127.GD5189@roque.1407.org> <20090707221926.GF5189@roque.1407.org> Message-ID: <1247501267.2483.48.camel@vaio.local.net> On Tue, 2009-07-07 at 19:06 -0400, Sam Varshavchik wrote: > Matthew Woehlke writes: > > > Rui Miguel Silva Seabra wrote: > >> In a couple of years Microsoft is bought by Fu-Bar Inc and there goes the > >> promise down the drain. > > > > ...if only. The odds of *any* company that might buy out M$ (well, if it > > isn't started by Gates and/or Ballmer and/or such) being as bad as M$ > > have got to be pretty high ;-). > > If you want legal advice, pay a lawyer. This is not legal advice. > > Microsoft's statement is what's generally called "covenant not to sue". When Right. This is the form of words I was going to bring up. I thought the difference between a grant of rights and a 'covenant not to sue' was fairly well-established and non-controversial, since that's the exact loophole in GPLv2 that Microsoft drove the Novell agreement through, and the main reason that GPLv3 exists. I remember the point being discussed and explained at tedious length around the time that was going on. So it seems a bit odd to have this long thread with some people arguing that a 'covenant not to sue' and a 'grant of rights to use a patent' are the same thing, when it seems a fairly well-established principle, accepted on all sides, that they're not. (I echo Sam's disclaimer: I'm not a lawyer and this isn't legal advice). -- 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 Jul 13 16:17:22 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 13 Jul 2009 17:17:22 +0100 Subject: Display Configuration test day summary In-Reply-To: <1247082174.2303.11.camel@planemask> References: <1247082174.2303.11.camel@planemask> Message-ID: <1247501842.2483.49.camel@vaio.local.net> On Wed, 2009-07-08 at 15:42 -0400, Matthias Clasen wrote: > We've had the first 'Fit and Finish' test day on display configuration > yesterday. I'd like to thank everybody who came by on irc and tested > something, or filed a bug. If you could not make it, our test cases are > still available here: Thanks for organizing this, looks like it went off really well. Sorry I couldn't be there, I was on vacation last week. I'll try to be at the next one. Great job! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From Fedora at FamilleCollet.com Mon Jul 13 16:51:25 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Mon, 13 Jul 2009 18:51:25 +0200 Subject: Heads UP - PHP 5.3.0 in rawhide with new ABI/API. In-Reply-To: <4A5A2017.3090409@FamilleCollet.com> References: <4A5A2017.3090409@FamilleCollet.com> Message-ID: <4A5B660D.3040205@FamilleCollet.com> Le 12/07/2009 19:40, Remi Collet a ?crit : > Hi, > > PHP 5.3.0 freshly build in Rawhide. **** Broken package - need work/patch syck https://bugzilla.redhat.com/show_bug.cgi?id=511018 **** Extension package rebuild: php-pecl-apc-3.1.2-1.fc12 update to 3.1.2 (beta) - PHP 5.3 support php-pecl-mailparse-2.1.5-1.fc12 update to 2.1.5 (bugfix + php 5.3.0 compatibility) php-pecl-memcache-3.0.4-2.fc12 php-pecl-memcached-1.0.0-1.fc12 Update to 1.0.0 php-pecl-ncurses-1.0.0-2.fc12 New package php-pecl-geoip-1.0.7-3.fc12 php-pecl-lzf-1.5.2-4.fc12 php-pecl-ssh2-0.11.0-3.fc12 add ssh2-php53.patch php-pecl-xdebug-2.0.4-1.fc12 update to 2.0.4 (bugfix + Basic PHP 5.3 support) php-pecl-radius-1.2.5-7.fc12 php-pecl-runkit-0.9-11.CVS20090215.fc12 php-pecl-parsekit-1.2-4.CVS20090309.fc12 php-pecl-selinux-0.3.1-3.fc12 php-pecl-imagick-2.2.2-3.fc12 php-shout-0.9.2-4.fc12 libpuzzle-0.11-5.fc12 add PHP ABI check php-magickwand-1.0.8-3.fc12 better PHP ABI check use php_extdir rrdtool-1.3.8-3.fc12 ice-3.3.1-3.fc12 https://bugzilla.redhat.com/show_bug.cgi?id=511068 ice-php53.patch add PHP ABI check use php_extdir graphviz https://bugzilla.redhat.com/show_bug.cgi?id=511092 add PHP ABI check use php_extdir (and don't own it) add php configuration file (/etc/php.d/graphviz.ini) **** TODO cups-php sipwitch-php-swig uuid-php php-eaccelerator php-suhosin **** OTHER TODO Update "PHP Guidelines" - note about /usr/share/php (subfolder for each library) - All C extension need ABI check not only PECL "official" ones. - PECL conditional post/postun only need if php < 5.2.0 (EL-5) I think it's enough for today... ;) Remi From martin.sourada at gmail.com Mon Jul 13 17:50:19 2009 From: martin.sourada at gmail.com (Martin Sourada) Date: Mon, 13 Jul 2009 19:50:19 +0200 Subject: $HOME/bin In-Reply-To: <2d319b780907130507w48a26dc5vf00e5e1b89ab9d1@mail.gmail.com> References: <4A5B1AF5.90406@redhat.com> <1247485648.2397.48.camel@pc-notebook.kolej.mff.cuni.cz> <2d319b780907130507w48a26dc5vf00e5e1b89ab9d1@mail.gmail.com> Message-ID: <1247507419.2627.1.camel@pc-notebook.kolej.mff.cuni.cz> On Mon, 2009-07-13 at 14:07 +0200, Mathieu Bridon (bochecha) wrote: > Look at your /etc/profile (or ~/.bash_profile, I don't remember). > > There should be something like: > [ -d ~/bin ] && PATH=~/bin:$PATH > > Which means that the folder will be added to your PATH if it exists. Well, I have there PATH=$PATH:$HOME/Applications/bin and that's because I added it manually there... I don't remember the original value. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From enrico.scholz at informatik.tu-chemnitz.de Mon Jul 13 18:24:54 2009 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 13 Jul 2009 20:24:54 +0200 Subject: $HOME/bin In-Reply-To: <20090713161056.GA22709@srcf.ucam.org> (Matthew Garrett's message of "Mon\, 13 Jul 2009 17\:10\:56 +0100") References: <4A5B1AF5.90406@redhat.com> <878wis3cyc.fsf@fc5.bigo.ensc.de> <20090713161056.GA22709@srcf.ucam.org> Message-ID: <871vokcufd.fsf@sheridan.bigo.ensc.de> Matthew Garrett writes: >> starts the xfrun4 "Run program" application) >> $ ps wwwe `/sbin/pidof xfrun4` >> 4220 ? Ss 0:00 /usr/bin/xfrun4 --daemon ... PATH=/usr/local/bin:/usr/bin:/bin:/usr/games > > .bash_profile is only evaluated for login shells. How else is the program environment (e.g. $http_proxy or $PATH) supposed to be set for applications started by the "Run program" desktop feature? And -- I want it to be consistent across xterm, the xfce4-panel buttons (which both have the bash profile environment) and "Run program". >> It's probably some kind of undebuggable d-bus interaction :( Hence, >> use xterm to start your applications, but not this buggy desktop >> crap. > > It seems to be working as expected, given the implementation. Most computer languages guarantee that everything works as expected, given its implementation. But this does not mean that it works correctly. Enrico From tgl at redhat.com Mon Jul 13 18:36:12 2009 From: tgl at redhat.com (Tom Lane) Date: Mon, 13 Jul 2009 14:36:12 -0400 Subject: F-11 updates seem hosed today Message-ID: <27515.1247510172@sss.pgh.pa.us> (Not sure if this is the right list to complain on, but ...) Trying to do a routine "yum update" on an F-11 x86 machine is not working today. It successfully downloaded a bunch of packages, but cannot find these: Error Downloading Packages: grubby-6.0.87-1.fc11.i586: failure: grubby-6.0.87-1.fc11.i586.rpm from updates: (256, 'No more mirrors to try.') farsight2-0.0.12-1.fc11.i586: failure: farsight2-0.0.12-1.fc11.i586.rpm from updates: (256, 'No more mirrors to try.') 12:dhclient-4.1.0-22.fc11.i586: failure: dhclient-4.1.0-22.fc11.i586.rpm from updates: (256, 'No more mirrors to try.') gnome-common-2.26.0-2.fc11.noarch: failure: gnome-common-2.26.0-2.fc11.noarch.rpm from updates: (256, 'No more mirrors to try.') alsa-plugins-pulseaudio-1.0.20-2.fc11.i586: failure: alsa-plugins-pulseaudio-1.0.20-2.fc11.i586.rpm from updates: (256, 'No more mirrors to try.') gstreamer-plugins-good-0.10.15-3.fc11.i586: failure: gstreamer-plugins-good-0.10.15-3.fc11.i586.rpm from updates: (256, 'No more mirrors to try.') gdb-6.8.50.20090302-33.fc11.i586: failure: gdb-6.8.50.20090302-33.fc11.i586.rpm from updates: (256, 'No more mirrors to try.') I don't see any way to ask yum to ignore these packages and apply the updates it did get, either ... regards, tom lane From pbrobinson at gmail.com Mon Jul 13 18:38:54 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 13 Jul 2009 19:38:54 +0100 Subject: F-11 updates seem hosed today In-Reply-To: <27515.1247510172@sss.pgh.pa.us> References: <27515.1247510172@sss.pgh.pa.us> Message-ID: <5256d0b0907131138u5414632fyd39d804a804a5d96@mail.gmail.com> On Mon, Jul 13, 2009 at 7:36 PM, Tom Lane wrote: > (Not sure if this is the right list to complain on, but ...) > > Trying to do a routine "yum update" on an F-11 x86 machine is not > working today. ?It successfully downloaded a bunch of packages, > but cannot find these: > > Error Downloading Packages: > ?grubby-6.0.87-1.fc11.i586: failure: grubby-6.0.87-1.fc11.i586.rpm from updates: (256, 'No more mirrors to try.') > ?farsight2-0.0.12-1.fc11.i586: failure: farsight2-0.0.12-1.fc11.i586.rpm from updates: (256, 'No more mirrors to try.') > ?12:dhclient-4.1.0-22.fc11.i586: failure: dhclient-4.1.0-22.fc11.i586.rpm from updates: (256, 'No more mirrors to try.') > ?gnome-common-2.26.0-2.fc11.noarch: failure: gnome-common-2.26.0-2.fc11.noarch.rpm from updates: (256, 'No more mirrors to try.') > ?alsa-plugins-pulseaudio-1.0.20-2.fc11.i586: failure: alsa-plugins-pulseaudio-1.0.20-2.fc11.i586.rpm from updates: (256, 'No more mirrors to try.') > ?gstreamer-plugins-good-0.10.15-3.fc11.i586: failure: gstreamer-plugins-good-0.10.15-3.fc11.i586.rpm from updates: (256, 'No more mirrors to try.') > ?gdb-6.8.50.20090302-33.fc11.i586: failure: gdb-6.8.50.20090302-33.fc11.i586.rpm from updates: (256, 'No more mirrors to try.') > > I don't see any way to ask yum to ignore these packages and apply the > updates it did get, either ... I had issues this morning but eventually got all but one alsa update which I just used a --exclude to get around. Peter From dodji at redhat.com Mon Jul 13 18:39:46 2009 From: dodji at redhat.com (Dodji Seketeli) Date: Mon, 13 Jul 2009 20:39:46 +0200 Subject: F-11 updates seem hosed today In-Reply-To: <27515.1247510172@sss.pgh.pa.us> References: <27515.1247510172@sss.pgh.pa.us> Message-ID: <4A5B7F72.4070708@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 13/07/2009 20:36, Tom Lane a ?crit : > (Not sure if this is the right list to complain on, but ...) > > Trying to do a routine "yum update" on an F-11 x86 machine is not > working today. It successfully downloaded a bunch of packages, > but cannot find these: Yeah, a bug has been filed at https://bugzilla.redhat.com/show_bug.cgi?id=510898 for this. I guess we just have to wait for the mirrors to sync to the right content ... - -- Dodji Seketeli Red Hat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpbf3IACgkQPejI7lrem2EjuQCgppHSF1zzH7P8CBaZVuFUbool /wcAnRoZocAyKQlLtDEnme0/gaYSLKcG =n0bC -----END PGP SIGNATURE----- From skvidal at fedoraproject.org Mon Jul 13 18:38:27 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 13 Jul 2009 14:38:27 -0400 (EDT) Subject: F-11 updates seem hosed today In-Reply-To: <27515.1247510172@sss.pgh.pa.us> References: <27515.1247510172@sss.pgh.pa.us> Message-ID: On Mon, 13 Jul 2009, Tom Lane wrote: > (Not sure if this is the right list to complain on, but ...) > > Trying to do a routine "yum update" on an F-11 x86 machine is not > working today. It successfully downloaded a bunch of packages, > but cannot find these: > > Error Downloading Packages: > grubby-6.0.87-1.fc11.i586: failure: grubby-6.0.87-1.fc11.i586.rpm from updates: (256, 'No more mirrors to try.') > farsight2-0.0.12-1.fc11.i586: failure: farsight2-0.0.12-1.fc11.i586.rpm from updates: (256, 'No more mirrors to try.') > 12:dhclient-4.1.0-22.fc11.i586: failure: dhclient-4.1.0-22.fc11.i586.rpm from updates: (256, 'No more mirrors to try.') > gnome-common-2.26.0-2.fc11.noarch: failure: gnome-common-2.26.0-2.fc11.noarch.rpm from updates: (256, 'No more mirrors to try.') > alsa-plugins-pulseaudio-1.0.20-2.fc11.i586: failure: alsa-plugins-pulseaudio-1.0.20-2.fc11.i586.rpm from updates: (256, 'No more mirrors to try.') > gstreamer-plugins-good-0.10.15-3.fc11.i586: failure: gstreamer-plugins-good-0.10.15-3.fc11.i586.rpm from updates: (256, 'No more mirrors to try.') > gdb-6.8.50.20090302-33.fc11.i586: failure: gdb-6.8.50.20090302-33.fc11.i586.rpm from updates: (256, 'No more mirrors to try.') > > I don't see any way to ask yum to ignore these packages and apply the > updates it did get, either ... > https://bugzilla.redhat.com/show_bug.cgi?id=510898 -sv From ville.skytta at iki.fi Mon Jul 13 19:07:10 2009 From: ville.skytta at iki.fi (Ville =?windows-1252?q?Skytt=E4?=) Date: Mon, 13 Jul 2009 22:07:10 +0300 Subject: rpm %defattr question In-Reply-To: <1247356269.22031.1.camel@hawking.theorphys.helsinki.fi> References: <1247356269.22031.1.camel@hawking.theorphys.helsinki.fi> Message-ID: <200907132207.15588.ville.skytta@iki.fi> On Sunday 12 July 2009, Jussi Lehtola wrote: > is the default attribute definition > %defattr(-,root,root) > the same as > %defattr(-,root,root,-)? Currently yes, the latter is just more explicit. From jussilehtola at fedoraproject.org Mon Jul 13 19:24:55 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Mon, 13 Jul 2009 22:24:55 +0300 Subject: rpm %defattr question In-Reply-To: <200907132207.15588.ville.skytta@iki.fi> References: <1247356269.22031.1.camel@hawking.theorphys.helsinki.fi> <200907132207.15588.ville.skytta@iki.fi> Message-ID: <1247513095.3095.3.camel@localhost.localdomain> On Mon, 2009-07-13 at 22:07 +0300, Ville Skytt? wrote: > On Sunday 12 July 2009, Jussi Lehtola wrote: > > > is the default attribute definition > > %defattr(-,root,root) > > the same as > > %defattr(-,root,root,-)? > > Currently yes, the latter is just more explicit. .. and is this going to change at some stage? -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From jkeating at redhat.com Mon Jul 13 19:31:03 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 13 Jul 2009 12:31:03 -0700 Subject: Release Engineering meeting summary for 2009-07-13 Message-ID: <1247513463.3073.23.camel@localhost.localdomain> Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-13/fedora-meeting.2009-07-13-18.25.html Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-13/fedora-meeting.2009-07-13-18.25.log.html Meeting log ----------- * **F12 Schedule** (f13-18:30:06_) * *LINK*: http://poelstra.fedorapeople.org/schedules/f-12/f12-releng-updated-version-2009-07-13.txt is the current iteration (f13-18:31:26_) * *AGREED*: Mass branch will happen just prior (day before) to final freeze (f13-18:51:29_) * *AGREED*: bodhi will accept/push updates as of 2009-10-21 which is the RC phase for the final release. (f13-18:52:23_) * *ACTION*: poelcat will add such dates to the schedule (f13-18:52:43_) * **Orphan round up** (f13-18:54:17_) * *ACTION*: jkeating will file a releng ticket to purge the orphans by feature freeze (f13-18:56:51_) * **FAD follow up** (f13-18:58:52_) * *ACTION*: f13 will spend more time on FAD follow up this week (f13-19:01:37_) * *ACTION*: f13 will file a releng ticket to purge the orphans by feature freeze (f13-19:01:47_) * **open floor** (f13-19:01:52_) * **updates pushes** (f13-19:03:59_) * *ACTION*: f13 will file a ticket to remember to back down koji signed package pruning (f13-19:04:23_) * **Critical Path** (f13-19:22:30_) * *AGREED*: Critical Path will be talked about next week (f13-19:22:51_) * **Open Floor** (f13-19:22:57_) -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A 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 rjones at redhat.com Mon Jul 13 21:45:59 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 13 Jul 2009 22:45:59 +0100 Subject: $HOME/bin In-Reply-To: <1247485648.2397.48.camel@pc-notebook.kolej.mff.cuni.cz> References: <4A5B1AF5.90406@redhat.com> <1247485648.2397.48.camel@pc-notebook.kolej.mff.cuni.cz> Message-ID: <20090713214559.GA25760@amd.home.annexia.org> On Mon, Jul 13, 2009 at 11:47:28AM +0000, Martin Sourada wrote: > because most people don't need it? Well, I would not be exactly against > making this default, but I'm not sure if $HOME/bin would be the right > one... Since xdg-dirs came around I use $HOME/Applications/bin for that Yuck! Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From rjones at redhat.com Mon Jul 13 21:48:35 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 13 Jul 2009 22:48:35 +0100 Subject: $HOME/bin In-Reply-To: <1247487312.4713.4.camel@decade.local> References: <4A5B1AF5.90406@redhat.com> <1247486935.3863.7.camel@dhcp-lab-219.englab.brq.redhat.com> <1247487312.4713.4.camel@decade.local> Message-ID: <20090713214835.GB25760@amd.home.annexia.org> On Mon, Jul 13, 2009 at 02:15:12PM +0200, Fabian Deutsch wrote: > Adding something like this raises security concerns, as this opens doors > for malicious software. > E.g. some application could but a binary named "bash" in ~/bin, which > would be run before /bin/bash. The same application could overwrite .bash_profile too. Or it would be very contrived to imagine a security hole that lets you create ~/bin and place an arbitrary binary into ~/bin/bash, but doesn't let you overwrite .bash_profile. So I don't think this is a security concern at all in the real world. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.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 rawhide at fedoraproject.org Mon Jul 13 22:47:31 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Mon, 13 Jul 2009 22:47:31 +0000 Subject: rawhide report: 20090713 changes Message-ID: <20090713224731.GA6392@releng2.fedora.phx.redhat.com> Compose started at Mon Jul 13 06:15:04 UTC 2009 New package axel Accelerated download client New package colossus Allows people to play Titan against each other or AIs New package eclipse-eclox Eclipse-based doxygen plugin New package mrepo A tool to set up a yum/apt mirror from various sources New package php-LightweightPicasaAPI A lightweight API for Picasa in PHP New package php-pecl-ncurses Terminal screen handling and optimization package New package pkcs11-helper A library for using PKCS#11 providers New package ruby-icon-artist Supporting libraries for icon artists New package samtools Tools for nucleotide sequence alignments in the SAM format New package trac-customfieldadmin-plugin Expose ticket custom fields via the web admin interface New package znc An advanced IRC bouncer Updated Packages: CodeAnalyst-gui-2.8.54-15.fc12 ------------------------------ * Mon Jul 13 2009 - Parag Nemade - 2.8.54-15 - Rebuild against new libbfd-2.19.51.0.11-23.fc12.so DeviceKit-disks-005-3.fc12 -------------------------- * Sun Jul 12 2009 Matthias Clasen - 005-3.f12 - Rebuild backup-manager-0.7.8-4.fc12 --------------------------- * Sun Jul 12 2009 Guillaume Kulakowski - 0.7.8-4 - Bump release * Thu Jun 25 2009 Guillaume Kulakowski - 0.7.8-3 - Add dar in requierement cherokee-0.99.20-1.fc12 ----------------------- * Sat Jul 11 2009 Pavel Lisy - 0.99.20-1 - updated to 0.99.20 chmsee-1.0.6-1.fc12 ------------------- * Sun Jul 12 2009 bbbush - 1.0.6-1 - update to 1.0.6 - update project location. Chmsee moved to google code since 2009-01-05, co-maintained by Li Daobing and Jungle Ji - update build steps to use CMake - Chmsee 1.0.3 was released on 2009-01-10, added "copy page location" in context menu, updated translation - Chmsee 1.0.4 was released on 2009-03-14, added "drag and drop" support, dropped cs2w - Chmsee 1.0.5 was released on 2009-05-17, added fullscreen support, switched to CMake, supported 6 more new languages - Chmsee 1.0.6 was released on 2009-07-12, added index support, supported 8 more new languages e2fsprogs-1.41.8-1.fc12 ----------------------- * Sun Jul 12 2009 Eric Sandeen 1.41.8-1 - New upstream version, several resize fixes. fsarchiver-0.5.8-2.fc12 ----------------------- * Sun Jul 12 2009 Adel Gadllah - 0.5.8-1 - Update to 0.5.8 * Sun Jul 12 2009 Adel Gadllah - 0.5.8-2 - BR libblkid-devel gerbv-2.3.0-1.fc12 ------------------ * Sat Jul 11 2009 Chitlesh Goorah - 2.3.0-1 - new upstream release gnome-python2-extras-2.25.3-5.fc12 ---------------------------------- * Sun Jul 12 2009 Matthew Barnes - 2.25.3-5 - Add patch for GNOME bug #584126 (gdl API break). gucharmap-2.26.3.1-1.fc12 ------------------------- * Sun Jul 12 2009 Matthias Clasen - 2.26.3.1-1 - Update to 2.26.3.1 jd-2.4.1-1.fc12 --------------- * Sun Jul 12 2009 Mamoru Tasaka - 2.4.1-1 - 2.4.1 libX11-1.2.99-1.20090712.fc12 ----------------------------- * Sun Jul 12 2009 Peter Hutterer 1.2.99-1.20090712 - Today's git snapshot - libX11-1.2.1-indic.patch: Drop. libXi-1.2.99-4.20090713.fc12 ---------------------------- * Mon Jul 13 2009 Peter Hutterer 1.2.99-4.20090713 - Update to today's git master - Add commitid file. * Sun Jul 12 2009 Peter Hutterer 1.2.99-3.20090712 - Update to today's git master moin-1.8.4-2.fc12 ----------------- * Sun Jul 12 2009 Ville-Pekka Vainio 1.8.4-2 - Remove the filemanager directory from the embedded FCKeditor, it contains code with know security vulnerabilities, even though that code couldn't be invoked when moin was used with the default settings. - Fixes rhbz #509924, related to CVE-2009-2265 mono-tools-2.4.2-4.fc12 ----------------------- * Sun Jul 12 2009 Christian Krause - 2.4.2-4 - Add version to requirement of gtkhtml-sharp to distinguish between gtk-sharp and gnome-desktop-sharp opengrok-0.8-0.1.20090712hg.fc12 -------------------------------- * Sun Jul 12 2009 Lubomir Rintel - 0.8-0.1.20090712hg - Update to latest Mercurial snapshot - bconds are nice, use them php-5.3.0-1.fc12 ---------------- * Sun Jul 12 2009 Remi Collet 5.3.0-1 - update to 5.3.0 - remove ncurses, dbase, mhash extensions - add enchant, sqlite3, intl, phar, fileinfo extensions - raise sqlite version to 3.6.0 (for sqlite3, build with --enable-load-extension) - sync with upstream "production" php.ini php-pecl-geoip-1.0.7-3.fc12 --------------------------- * Sun Jul 12 2009 Remi Collet 1.0.7-3 - rebuild for new PHP 5.3.0 ABI (20090626) php-pecl-lzf-1.5.2-4.fc12 ------------------------- * Sun Jul 12 2009 Remi Collet - 1.5.2-4 - rebuild for new PHP 5.3.0 ABI (20090626) php-pecl-mailparse-2.1.5-1.fc12 ------------------------------- * Sun Jul 12 2009 Remi Collet 2.1.5-1 - update to 2.1.5 (bugfix + php 5.3.0 compatibility) php-pecl-memcache-3.0.4-2.fc12 ------------------------------ * Sun Jul 12 2009 Remi Collet 3.0.4-2 - rebuild for new PHP 5.3.0 ABI (20090626) php-pecl-memcached-1.0.0-1.fc12 ------------------------------- * Sun Jul 12 2009 Remi Collet - 1.0.0-1 - Update to 1.0.0 (First stable release) php-pecl-radius-1.2.5-7.fc12 ---------------------------- * Sun Jul 12 2009 Remi Collet - 1.2.5-7 - rebuild for new PHP 5.3.0 ABI (20090626) php-pecl-ssh2-0.11.0-3.fc12 --------------------------- * Sun Jul 12 2009 Remi Collet - 0.11.0-3 - add ssh2-php53.patch - rebuild for new PHP 5.3.0 ABI (20090626) php-pecl-xdebug-2.0.4-1.fc12 ---------------------------- * Sun Jul 12 2009 Remi Collet - 2.0.4-1 - update to 2.0.4 (bugfix + Basic PHP 5.3 support) pidgin-2.5.8-2.fc12 ------------------- * Sat Jul 11 2009 Stu Tomlison 2.5.8-2 - Backport patch from upstream to enable NSS to recognize root CA certificates that use MD2 & MD4 algorithms in their signature, as used by some MSN and XMPP servers ppl-0.10.2-4.fc12 ----------------- * Sun Jul 12 2009 Roberto Bagnara 0.10.2-4 - Force rebuild. rubyripper-0.5.7-1.fc12 ----------------------- * Sun Jul 12 2009 Sindre Pedersen Bj?rdal - 0.5.7-1 - New upstream release, notable changes including: - a fix for discs that start with a data track - a fix for checking the available space for some languages - fix a typo in the logfile when errors were corrected - fix a typo which resulted in a directory not containing the album name taskjuggler-2.4.2-1 ------------------- * Mon Jul 13 2009 Ondrej Vasik - 2.4.2-1 - New upstream release 2.4.2 tomoe-gtk-0.6.0-8.fc12 ---------------------- * Mon Jul 13 2009 Ding-Yi Chen - 0.6.0-8 - Actually Fixed RH Bug 499880: tomoe-gtk not built with $RPM_OPT_FLAGS * Wed May 13 2009 Ding-Yi Chen - 0.6.0-7 - Fixed RH Bug 499880: tomoe-gtk not built with $RPM_OPT_FLAGS - Add libtool BuildRequires. - Fixed rpath issues. - Add tomoegtk.so * Fri May 08 2009 Ville Skytt? - 0.6.0-6 - Build with $RPM_OPT_FLAGS (patch to avoid discarding user set $CFLAGS). - Disable autotools dependency tracking during build for cleaner build logs and possible slight build speedup. xdvik-22.84.14-6.fc12 --------------------- * Sun Jul 12 2009 Jonathan G. Underwood - 22.84.14-6 - Correct paths in xdvi-ptex.map to fix BZ 508429 (Yuki Watanabe) xorg-x11-proto-devel-7.4-18.fc12 -------------------------------- * Sun Jul 12 2009 Peter Hutterer 7.4-18 - inputproto 1.9.99.13 Summary: Added Packages: 11 Removed Packages: 0 Modified Packages: 32 Broken deps for i386 ---------------------------------------------------------- R-RScaLAPACK-0.5.1-19.fc11.i586 requires openmpi-libs 1:anjuta-2.26.1.0-1.fc12.i586 requires libgdl-1.so.0 bmpx-0.40.14-8.fc11.i386 requires libboost_iostreams-mt.so.4 bmpx-0.40.14-8.fc11.i386 requires libboost_regex-mt.so.4 clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.i586 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.i586 requires gauche = 0:0.8.13 gparted-0.4.5-2.fc12.i586 requires libparted-1.8.so.8 gtranslator-1.9.5-1.fc12.i586 requires libgdl-1.so.0 libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 limph-1.9.5-4.fc11.noarch requires php-mhash limph-hostagent-1.9.5-4.fc11.noarch requires php-mhash maniadrive-1.2-15.fc12.i586 requires libphp5-5.2.10.so maniadrive-track-editor-1.2-15.fc12.i586 requires libphp5-5.2.10.so orsa-0.7.0-8.fc11.i586 requires libcln.so.5 1:php-eaccelerator-0.9.5.3-3.fc11.i586 requires php(zend-abi) = 0:20060613 1:php-eaccelerator-0.9.5.3-3.fc11.i586 requires php(api) = 0:20041225 php-idn-1.2-5.fc12.i586 requires php-api = 0:20041225 php-magickwand-1.0.8-2.fc12.i586 requires php-api = 0:20041225 php-pear-Auth-RADIUS-1.0.6-2.fc11.noarch requires php-mhash php-pear-Crypt-CHAP-1.0.1-2.fc11.noarch requires php-mhash php-pear-Net-DNS-1.0.0-3.fc11.noarch requires php-mhash php-pecl-Fileinfo-1.0.4-5.fc11.i586 requires php-api = 0:20041225 php-pecl-apc-3.0.19-2.fc11.i586 requires php(zend-abi) = 0:20060613 php-pecl-apc-3.0.19-2.fc11.i586 requires php(api) = 0:20041225 php-pecl-imagick-2.2.2-2.fc11.i586 requires php(zend-abi) = 0:20060613 php-pecl-imagick-2.2.2-2.fc11.i586 requires php(api) = 0:20041225 php-pecl-parsekit-1.2-3.CVS20090309.fc12.i586 requires php(zend-abi) = 0:20060613 php-pecl-parsekit-1.2-3.CVS20090309.fc12.i586 requires php(api) = 0:20041225 php-pecl-phar-1.2.3-4.fc11.i586 requires php(zend-abi) = 0:20060613 php-pecl-phar-1.2.3-4.fc11.i586 requires php(api) = 0:20041225 php-pecl-runkit-0.9-10.CVS20090215.fc11.i586 requires php(zend-abi) = 0:20060613 php-pecl-runkit-0.9-10.CVS20090215.fc11.i586 requires php(api) = 0:20041225 php-pecl-selinux-0.3.1-2.fc12.i586 requires php(zend-abi) = 0:20060613 php-pecl-selinux-0.3.1-2.fc12.i586 requires php(api) = 0:20041225 php-shout-0.9.2-3.fc11.i586 requires php-api = 0:20041225 php-suhosin-0.9.27-2.fc11.i586 requires php(zend-abi) = 0:20060613 php-suhosin-0.9.27-2.fc11.i586 requires php(api) = 0:20041225 pyclutter-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.i386 requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.i386 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.i586 requires libgeos-3.0.3.so python-repoze-what-plugins-sql-1.0-0.5.rc1.fc12.noarch requires python-repoze-who-plugins-sa qtparted-0.4.5-19.fc11.i586 requires libparted-1.8.so.8 raydium-1.2-15.fc12.i586 requires libphp5-5.2.10.so rrdtool-php-1.3.8-2.fc12.i586 requires php(zend-abi) = 0:20060613 rrdtool-php-1.3.8-2.fc12.i586 requires php(api) = 0:20041225 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.i586 requires libpqxx-2.6.8.so springlobby-0.0.1.10461-1.fc12.i586 requires libtorrent-rasterbar.so.3 syck-php-0.61-8.2.fc11.i586 requires php(api) = 0:20041225 syck-php-0.61-8.2.fc11.i586 requires php(zend-abi) = 0:20060613 thunderbird-lightning-1.0-0.6.20090513hg.fc12.i586 requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 Broken deps for x86_64 ---------------------------------------------------------- R-RScaLAPACK-0.5.1-19.fc11.x86_64 requires openmpi-libs 1:anjuta-2.26.1.0-1.fc12.i586 requires libgdl-1.so.0 1:anjuta-2.26.1.0-1.fc12.x86_64 requires libgdl-1.so.0()(64bit) bmpx-0.40.14-8.fc11.x86_64 requires libboost_regex.so.4()(64bit) bmpx-0.40.14-8.fc11.x86_64 requires libboost_iostreams.so.4()(64bit) clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.x86_64 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.x86_64 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.x86_64 requires gauche = 0:0.8.13 gparted-0.4.5-2.fc12.x86_64 requires libparted-1.8.so.8()(64bit) gtranslator-1.9.5-1.fc12.x86_64 requires libgdl-1.so.0()(64bit) libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.x86_64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 libprojectM-1.2.0-9.fc11.x86_64 requires libftgl.so.0()(64bit) limph-1.9.5-4.fc11.noarch requires php-mhash limph-hostagent-1.9.5-4.fc11.noarch requires php-mhash maniadrive-1.2-15.fc12.x86_64 requires libphp5-5.2.10.so()(64bit) maniadrive-track-editor-1.2-15.fc12.x86_64 requires libphp5-5.2.10.so()(64bit) orsa-0.7.0-8.fc11.i586 requires libcln.so.5 orsa-0.7.0-8.fc11.x86_64 requires libcln.so.5()(64bit) 1:php-eaccelerator-0.9.5.3-3.fc11.x86_64 requires php(zend-abi) = 0:20060613 1:php-eaccelerator-0.9.5.3-3.fc11.x86_64 requires php(api) = 0:20041225 php-idn-1.2-5.fc12.x86_64 requires php-api = 0:20041225 php-magickwand-1.0.8-2.fc12.x86_64 requires php-api = 0:20041225 php-pear-Auth-RADIUS-1.0.6-2.fc11.noarch requires php-mhash php-pear-Crypt-CHAP-1.0.1-2.fc11.noarch requires php-mhash php-pear-Net-DNS-1.0.0-3.fc11.noarch requires php-mhash php-pecl-Fileinfo-1.0.4-5.fc11.x86_64 requires php-api = 0:20041225 php-pecl-apc-3.0.19-2.fc11.x86_64 requires php(zend-abi) = 0:20060613 php-pecl-apc-3.0.19-2.fc11.x86_64 requires php(api) = 0:20041225 php-pecl-imagick-2.2.2-2.fc11.x86_64 requires php(zend-abi) = 0:20060613 php-pecl-imagick-2.2.2-2.fc11.x86_64 requires php(api) = 0:20041225 php-pecl-parsekit-1.2-3.CVS20090309.fc12.x86_64 requires php(zend-abi) = 0:20060613 php-pecl-parsekit-1.2-3.CVS20090309.fc12.x86_64 requires php(api) = 0:20041225 php-pecl-phar-1.2.3-4.fc11.x86_64 requires php(zend-abi) = 0:20060613 php-pecl-phar-1.2.3-4.fc11.x86_64 requires php(api) = 0:20041225 php-pecl-runkit-0.9-10.CVS20090215.fc11.x86_64 requires php(zend-abi) = 0:20060613 php-pecl-runkit-0.9-10.CVS20090215.fc11.x86_64 requires php(api) = 0:20041225 php-pecl-selinux-0.3.1-2.fc12.x86_64 requires php(zend-abi) = 0:20060613 php-pecl-selinux-0.3.1-2.fc12.x86_64 requires php(api) = 0:20041225 php-shout-0.9.2-3.fc11.x86_64 requires php-api = 0:20041225 php-suhosin-0.9.27-2.fc11.x86_64 requires php(zend-abi) = 0:20060613 php-suhosin-0.9.27-2.fc11.x86_64 requires php(api) = 0:20041225 pyclutter-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.x86_64 requires libgeos-3.0.3.so()(64bit) python-repoze-what-plugins-sql-1.0-0.5.rc1.fc12.noarch requires python-repoze-who-plugins-sa qtparted-0.4.5-19.fc11.x86_64 requires libparted-1.8.so.8()(64bit) raydium-1.2-15.fc12.i586 requires libphp5-5.2.10.so raydium-1.2-15.fc12.x86_64 requires libphp5-5.2.10.so()(64bit) rrdtool-php-1.3.8-2.fc12.x86_64 requires php(zend-abi) = 0:20060613 rrdtool-php-1.3.8-2.fc12.x86_64 requires php(api) = 0:20041225 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.x86_64 requires libpqxx-2.6.8.so()(64bit) springlobby-0.0.1.10461-1.fc12.x86_64 requires libtorrent-rasterbar.so.3()(64bit) syck-php-0.61-8.2.fc11.x86_64 requires php(api) = 0:20041225 syck-php-0.61-8.2.fc11.x86_64 requires php(zend-abi) = 0:20060613 thunderbird-lightning-1.0-0.6.20090513hg.fc12.x86_64 requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 Broken deps for ppc ---------------------------------------------------------- R-RScaLAPACK-0.5.1-19.fc11.ppc requires openmpi-libs 1:anjuta-2.26.1.0-1.fc12.ppc requires libgdl-1.so.0 1:anjuta-2.26.1.0-1.fc12.ppc64 requires libgdl-1.so.0()(64bit) bmpx-0.40.14-8.fc11.ppc requires libboost_iostreams-mt.so.4 bmpx-0.40.14-8.fc11.ppc requires libboost_regex-mt.so.4 clutter-cairo-0.8.2-3.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.ppc requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.ppc requires gauche = 0:0.8.13 gparted-0.4.5-2.fc12.ppc requires libparted-1.8.so.8 gtranslator-1.9.5-1.fc12.ppc requires libgdl-1.so.0 libchamplain-0.2.9-1.fc11.ppc requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc requires libftgl.so.0 libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) limph-1.9.5-4.fc11.noarch requires php-mhash limph-hostagent-1.9.5-4.fc11.noarch requires php-mhash maniadrive-1.2-15.fc12.ppc requires libphp5-5.2.10.so maniadrive-track-editor-1.2-15.fc12.ppc requires libphp5-5.2.10.so orsa-0.7.0-8.fc11.ppc requires libcln.so.5 orsa-0.7.0-8.fc11.ppc64 requires libcln.so.5()(64bit) 1:php-eaccelerator-0.9.5.3-3.fc11.ppc requires php(zend-abi) = 0:20060613 1:php-eaccelerator-0.9.5.3-3.fc11.ppc requires php(api) = 0:20041225 php-idn-1.2-5.fc12.ppc requires php-api = 0:20041225 php-magickwand-1.0.8-2.fc12.ppc requires php-api = 0:20041225 php-pear-Auth-RADIUS-1.0.6-2.fc11.noarch requires php-mhash php-pear-Crypt-CHAP-1.0.1-2.fc11.noarch requires php-mhash php-pear-Net-DNS-1.0.0-3.fc11.noarch requires php-mhash php-pecl-Fileinfo-1.0.4-5.fc11.ppc requires php-api = 0:20041225 php-pecl-apc-3.0.19-2.fc11.ppc requires php(zend-abi) = 0:20060613 php-pecl-apc-3.0.19-2.fc11.ppc requires php(api) = 0:20041225 php-pecl-imagick-2.2.2-2.fc11.ppc requires php(zend-abi) = 0:20060613 php-pecl-imagick-2.2.2-2.fc11.ppc requires php(api) = 0:20041225 php-pecl-parsekit-1.2-3.CVS20090309.fc12.ppc requires php(zend-abi) = 0:20060613 php-pecl-parsekit-1.2-3.CVS20090309.fc12.ppc requires php(api) = 0:20041225 php-pecl-phar-1.2.3-4.fc11.ppc requires php(zend-abi) = 0:20060613 php-pecl-phar-1.2.3-4.fc11.ppc requires php(api) = 0:20041225 php-pecl-runkit-0.9-10.CVS20090215.fc11.ppc requires php(zend-abi) = 0:20060613 php-pecl-runkit-0.9-10.CVS20090215.fc11.ppc requires php(api) = 0:20041225 php-pecl-selinux-0.3.1-2.fc12.ppc requires php(zend-abi) = 0:20060613 php-pecl-selinux-0.3.1-2.fc12.ppc requires php(api) = 0:20041225 php-shout-0.9.2-3.fc11.ppc requires php-api = 0:20041225 php-suhosin-0.9.27-2.fc11.ppc requires php(zend-abi) = 0:20060613 php-suhosin-0.9.27-2.fc11.ppc requires php(api) = 0:20041225 pyclutter-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.ppc requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.ppc requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.ppc requires libgeos-3.0.3.so python-repoze-what-plugins-sql-1.0-0.5.rc1.fc12.noarch requires python-repoze-who-plugins-sa qtparted-0.4.5-19.fc11.ppc requires libparted-1.8.so.8 raydium-1.2-15.fc12.ppc requires libphp5-5.2.10.so raydium-1.2-15.fc12.ppc64 requires libphp5-5.2.10.so()(64bit) rrdtool-php-1.3.8-2.fc12.ppc requires php(zend-abi) = 0:20060613 rrdtool-php-1.3.8-2.fc12.ppc requires php(api) = 0:20041225 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc requires libpqxx-2.6.8.so syck-php-0.61-8.2.fc11.ppc requires php(api) = 0:20041225 syck-php-0.61-8.2.fc11.ppc requires php(zend-abi) = 0:20060613 thunderbird-lightning-1.0-0.6.20090513hg.fc12.ppc requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 Broken deps for ppc64 ---------------------------------------------------------- R-RScaLAPACK-0.5.1-19.fc11.ppc64 requires openmpi-libs 1:anjuta-2.26.1.0-1.fc12.ppc64 requires libgdl-1.so.0()(64bit) bmpx-0.40.14-8.fc11.ppc64 requires libboost_regex.so.4()(64bit) bmpx-0.40.14-8.fc11.ppc64 requires libboost_iostreams.so.4()(64bit) clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) gparted-0.4.5-2.fc12.ppc64 requires libparted-1.8.so.8()(64bit) gtranslator-1.9.5-1.fc12.ppc64 requires libgdl-1.so.0()(64bit) libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) limph-1.9.5-4.fc11.noarch requires php-mhash limph-hostagent-1.9.5-4.fc11.noarch requires php-mhash maniadrive-1.2-15.fc12.ppc64 requires libphp5-5.2.10.so()(64bit) maniadrive-track-editor-1.2-15.fc12.ppc64 requires libphp5-5.2.10.so()(64bit) orsa-0.7.0-8.fc11.ppc64 requires libcln.so.5()(64bit) 1:php-eaccelerator-0.9.5.3-3.fc11.ppc64 requires php(zend-abi) = 0:20060613 1:php-eaccelerator-0.9.5.3-3.fc11.ppc64 requires php(api) = 0:20041225 php-idn-1.2-5.fc12.ppc64 requires php-api = 0:20041225 php-magickwand-1.0.8-2.fc12.ppc64 requires php-api = 0:20041225 php-pear-Auth-RADIUS-1.0.6-2.fc11.noarch requires php-mhash php-pear-Crypt-CHAP-1.0.1-2.fc11.noarch requires php-mhash php-pear-Net-DNS-1.0.0-3.fc11.noarch requires php-mhash php-pecl-Fileinfo-1.0.4-5.fc11.ppc64 requires php-api = 0:20041225 php-pecl-apc-3.0.19-2.fc11.ppc64 requires php(zend-abi) = 0:20060613 php-pecl-apc-3.0.19-2.fc11.ppc64 requires php(api) = 0:20041225 php-pecl-imagick-2.2.2-2.fc11.ppc64 requires php(zend-abi) = 0:20060613 php-pecl-imagick-2.2.2-2.fc11.ppc64 requires php(api) = 0:20041225 php-pecl-parsekit-1.2-3.CVS20090309.fc12.ppc64 requires php(zend-abi) = 0:20060613 php-pecl-parsekit-1.2-3.CVS20090309.fc12.ppc64 requires php(api) = 0:20041225 php-pecl-phar-1.2.3-4.fc11.ppc64 requires php(zend-abi) = 0:20060613 php-pecl-phar-1.2.3-4.fc11.ppc64 requires php(api) = 0:20041225 php-pecl-runkit-0.9-10.CVS20090215.fc11.ppc64 requires php(zend-abi) = 0:20060613 php-pecl-runkit-0.9-10.CVS20090215.fc11.ppc64 requires php(api) = 0:20041225 php-pecl-selinux-0.3.1-2.fc12.ppc64 requires php(zend-abi) = 0:20060613 php-pecl-selinux-0.3.1-2.fc12.ppc64 requires php(api) = 0:20041225 php-shout-0.9.2-3.fc11.ppc64 requires php-api = 0:20041225 php-suhosin-0.9.27-2.fc11.ppc64 requires php(zend-abi) = 0:20060613 php-suhosin-0.9.27-2.fc11.ppc64 requires php(api) = 0:20041225 pyclutter-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.ppc64 requires libgeos-3.0.3.so()(64bit) python-mwlib-0.11.2-2.20090522hg2956.fc12.ppc64 requires LabPlot python-repoze-what-plugins-sql-1.0-0.5.rc1.fc12.noarch requires python-repoze-who-plugins-sa qtparted-0.4.5-19.fc11.ppc64 requires libparted-1.8.so.8()(64bit) raydium-1.2-15.fc12.ppc64 requires libphp5-5.2.10.so()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc64 requires libpqxx-2.6.8.so()(64bit) syck-php-0.61-8.2.fc11.ppc64 requires php(api) = 0:20041225 syck-php-0.61-8.2.fc11.ppc64 requires php(zend-abi) = 0:20060613 thunderbird-lightning-1.0-0.6.20090513hg.fc12.ppc64 requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 From poelstra at redhat.com Mon Jul 13 22:52:39 2009 From: poelstra at redhat.com (John Poelstra) Date: Mon, 13 Jul 2009 15:52:39 -0700 Subject: Alpha Blocker Bug Meeting: Friday 2009-07-17 Message-ID: <4A5BBAB7.8040100@redhat.com> What: F12Alpha Blocker bug meeting (https://bugzilla.redhat.com/show_bug.cgi?id=f12alpha) When: Friday, 2009-07-17 @ 17:00 UTC (1 PM EDT) Where: #fedora-bugzappers It is hard to believe, but it is already time to start getting prepared for the Alpha! For Fedora 12 we are making a concerted effort to pro-actively review the blocker bug lists on a more consistent basis. Right now the blocker bug for Fedora 12 alpha is "bug free." Either this is going to be a really solid release that requires little effort... or we need to start focusing on rawhide and marking blockers as we find them :) Hope to see you on Friday. Thanks, John From giallu at gmail.com Mon Jul 13 23:50:16 2009 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 14 Jul 2009 01:50:16 +0200 Subject: Mock issue with ifarch BuildRequires In-Reply-To: References: Message-ID: Sorry for the cross-posting, I'm trying to get a clue... ---------- Forwarded message ---------- From: Gianluca Sforna Date: Mon, Jul 13, 2009 at 1:38 AM Subject: Mock issue with ifarch BuildRequires To: Discussion of Fedora build system I am trying to run the tests included in the BuildBot package during the RPM build, and one of the tests requires darcs, which is built in Fedora ExclusiveArch %{ix86} x86_64 ppc alpha. Now, I'm adding to buildbot's spec[1] file an ifarch like: %ifarch %{ix86} x86_64 ppc alpha # darcs ExclusiveArchs BuildRequires: ?darcs %endif but it seems darcs is never installed in the buildroot [2] am I just doing something stupid or there's a bug somewhere? [1] http://cvs.fedoraproject.org/viewvc/rpms/buildbot/devel/buildbot.spec?view=log [2] http://koji.fedoraproject.org/koji/getfile?taskID=1470380&name=root.log -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna From mjg at redhat.com Tue Jul 14 02:34:02 2009 From: mjg at redhat.com (Matthew Garrett) Date: Tue, 14 Jul 2009 03:34:02 +0100 Subject: $HOME/bin In-Reply-To: <20090713214835.GB25760@amd.home.annexia.org> References: <4A5B1AF5.90406@redhat.com> <1247486935.3863.7.camel@dhcp-lab-219.englab.brq.redhat.com> <1247487312.4713.4.camel@decade.local> <20090713214835.GB25760@amd.home.annexia.org> Message-ID: <20090714023402.GA9563@srcf.ucam.org> On Mon, Jul 13, 2009 at 10:48:35PM +0100, Richard W.M. Jones wrote: > The same application could overwrite .bash_profile too. Or it would > be very contrived to imagine a security hole that lets you create > ~/bin and place an arbitrary binary into ~/bin/bash, but doesn't let > you overwrite .bash_profile. So I don't think this is a security > concern at all in the real world. Realistically, the concern is more likely to be binaries accidently causing subtle breakage by colliding with the expected behaviour of system utilities. -- Matthew Garrett | mjg59 at srcf.ucam.org From mail at marcus-moeller.de Tue Jul 14 06:56:21 2009 From: mail at marcus-moeller.de (Marcus Moeller) Date: Tue, 14 Jul 2009 08:56:21 +0200 Subject: library path Message-ID: Hi all. I am currently working on an openmotif .spec which contains libs that are also part of the lesstif package. I am now planning to move them to /usr/lib/openmotif and wonder if it makes sense to place them in a subfolder like /usr/lib/openmotif/lib or directly into /usr/lib/openmotif. Best Regards Marcus From giallu at gmail.com Tue Jul 14 07:17:50 2009 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 14 Jul 2009 09:17:50 +0200 Subject: library path In-Reply-To: References: Message-ID: On Tue, Jul 14, 2009 at 8:56 AM, Marcus Moeller wrote: > Hi all. > > I am currently working on an openmotif .spec openmotif is being packaged at rpmfusion due to its license: http://bugzilla.rpmfusion.org/show_bug.cgi?id=461 -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna From dmc.fedora at filteredperception.org Tue Jul 14 08:04:34 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 14 Jul 2009 02:04:34 -0600 Subject: Feature proposal: Rebootless Installer Message-ID: <4A5C3C12.9050009@filteredperception.org> Fedorans, Can you spare 50 or 100K? If you can spare 100K/700M in the forthcoming Fedora-12 LiveCD, I can provide you with a rebootless installation experience. http://fedoraproject.org/wiki/Features/RebootlessInstaller The short story is that you boot the LiveCD/USB, run the installation, and then, instead of rebooting into the installed OS, you are already looking at and using it. I just threw together a decent first pass at a feature page, with all the relevent info, as well as a couple links to youtube videos showing the complete user experience. Or, if you are the adventurous kind with an idle test system (obviously with no important unbacked up data), simply a) boot an f11-i686 livecd or usb, with an internet connection b) firefox http://viros.org/rebootless c) click the i386 rpm link, and submit to packagekit d) do any partitioning beforehand with fdisk, or whatever gui tool (is palimpsest really supposed to be able to repartition?) e) launch the new desktop icon f) run the installer, simply selecting target root/boot/swap partitions g) enjoy the coolness that is rebootless installation, and my gratitude for being one of the first, if not the second tester :) I would obviously love to see this in F12 even though it could use quite a bit of polish. It is fairly important that it go in sooner rather than later, as when unionfs percolates to fedora, this feature may no longer be technically possible. In the event the feature were wildly popular, and sticks around, obviously integration with anaconda would be next, i.e. simply a checkbox before beginning installation stating whether you want rebootless instead of traditional. In any event, I'd love to hear what people think. I suppose if space is the issue, it could even be a feature just getting the package into the fedora repos so that it could be advertised, with users just needing an internet connection, and not having to see a complaint about lack of signature on the package. But cmon, can you spare 100K? (50 of that is ego/logo I can probably part with :) peace... -dmc From dmach at redhat.com Tue Jul 14 08:21:13 2009 From: dmach at redhat.com (Daniel Mach) Date: Tue, 14 Jul 2009 10:21:13 +0200 Subject: NVR bugs in rawhide Message-ID: <4A5C3FF9.3010903@redhat.com> I found 375 possibly wrong NVRs in rawhide. Can you check it an fix it, please? I'd like to file bugs for those which won't get fixed in couple weeks. Short explanation of detected errors follows: Release doesn't contain a %dist tag. - %dist is missing in Release: in spec - http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Using_the_.25.7B.3Fdist.7D_Tag Pre-release build's release should start with '0.'. - a pre-release build is detected with these patterns: "test", "alpha", "beta", "rc", "[\.0-9]a[\.0-9]", "b[0-9]+", "snap", "pre", "dev", "build", "bzr", "cvs", "svn", "git", "hg", "trunk", "branch" - release should start with .0, but generally it can start with any number as long as it's bumped before each build. - http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages Release format can be wrong. Unknown non-numeric characters in release. - release contains characters different than dots and numbers & does not match any of pre-release patterns - please report any detected false-positives Extra characters after %dist tag. - there should not be any characters after %dist - the only exception is a workaround for older releases to keep upgrade path: 2.fc10.1 < 2.fc11 - rawhide definitely shouldn't contain these - http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches -------------- next part -------------- A non-text attachment was scrubbed... Name: nvr_rawhide.log Type: text/x-log Size: 31892 bytes Desc: not available URL: From jakub at redhat.com Tue Jul 14 08:26:27 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 14 Jul 2009 10:26:27 +0200 Subject: NVR bugs in rawhide In-Reply-To: <4A5C3FF9.3010903@redhat.com> References: <4A5C3FF9.3010903@redhat.com> Message-ID: <20090714082627.GH4462@tyan-ft48-01.lab.bos.redhat.com> On Tue, Jul 14, 2009 at 10:21:13AM +0200, Daniel Mach wrote: > I found 375 possibly wrong NVRs in rawhide. > Can you check it an fix it, please? > I'd like to file bugs for those which won't get fixed in couple weeks. > > Short explanation of detected errors follows: > > Release doesn't contain a %dist tag. > - %dist is missing in Release: in spec > - > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Using_the_.25.7B.3Fdist.7D_Tag The guideline you refer to says "if you wish to use a single spec file...". So I don't see why not using %dist would be a bug if you don't wish to do that. Jakub From caolanm at redhat.com Tue Jul 14 08:30:03 2009 From: caolanm at redhat.com (=?ISO-8859-1?Q?Caol=E1n?= McNamara) Date: Tue, 14 Jul 2009 09:30:03 +0100 Subject: NVR bugs in rawhide In-Reply-To: <4A5C3FF9.3010903@redhat.com> References: <4A5C3FF9.3010903@redhat.com> Message-ID: <1247560203.12445.863.camel@Vain> On Tue, 2009-07-14 at 10:21 +0200, Daniel Mach wrote: > Release doesn't contain a %dist tag. > - %dist is missing in Release: in spec > - > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Using_the_.25.7B.3Fdist.7D_Tag "If you wish", so until now it hasn't been an error to not have one. Has this changed ? > Pre-release build's release should start with '0.'. > - a pre-release build is detected with these patterns: "test", "alpha", > "beta", "rc", "[\.0-9]a[\.0-9]", "b[0-9]+", "snap", "pre", "dev", > "build", "bzr", "cvs", "svn", "git", "hg", "trunk", "branch" > - release should start with .0, but generally it can start with any > number as long as it's bumped before each build. But of course we also have post-release snapshot packages, so if alliance-5.0-26.20070718snap is a svn/cvs snapshot *post* 5.0 release then its be perfectly correct, right ? C. From fedora at leemhuis.info Tue Jul 14 08:33:25 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 14 Jul 2009 10:33:25 +0200 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C3C12.9050009@filteredperception.org> References: <4A5C3C12.9050009@filteredperception.org> Message-ID: <4A5C42D5.10105@leemhuis.info> On 14.07.2009 10:04, Douglas McClendon wrote: > > [...]In any event, I'd love to hear what people think. [...] I for one think rebooting after install is a very good thing, as only a full reboot makes sure the install (including boot loaders) was completely successful and works fine. Or IOW: I for one would be really annoyed if I'm doing a "rebootless install" and after hours of customizing and using it notice after a reboot that the install doesn't boot due to a broken boot-loader installation/configuration. Just my 2 cent. CU knurd From dmc.fedora at filteredperception.org Tue Jul 14 08:56:19 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 14 Jul 2009 02:56:19 -0600 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C42D5.10105@leemhuis.info> References: <4A5C3C12.9050009@filteredperception.org> <4A5C42D5.10105@leemhuis.info> Message-ID: <4A5C4833.9050800@filteredperception.org> Thorsten Leemhuis wrote: > On 14.07.2009 10:04, Douglas McClendon wrote: >> [...]In any event, I'd love to hear what people think. [...] > > I for one think rebooting after install is a very good thing, as only a > full reboot makes sure the install (including boot loaders) was > completely successful and works fine. > > Or IOW: I for one would be really annoyed if I'm doing a "rebootless > install" and after hours of customizing and using it notice after a > reboot that the install doesn't boot due to a broken boot-loader > installation/configuration. > > Just my 2 cent. Thanks for the feedback, those are good points. I would only emphasize that I'm in no way suggesting replacing the current installers with this absolutely bleeding edge technology. Even in what I envision as the long term most positive adoption, as I said, it would merely be an optional (default off) choice inside, or in addition to the traditional rebooting method. In the first F12 incarnation, it would be hidden behind an appropriate number of warning/danger/experimental/imminent-explosion* messages. * "eating babies" would be the traditional fedora scare tactic, but that might offend some number of fedora users who have had their children eaten by bears. Thanks, -dmc From dmc.fedora at filteredperception.org Tue Jul 14 09:01:15 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 14 Jul 2009 03:01:15 -0600 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C42D5.10105@leemhuis.info> References: <4A5C3C12.9050009@filteredperception.org> <4A5C42D5.10105@leemhuis.info> Message-ID: <4A5C495B.1000005@filteredperception.org> Thorsten Leemhuis wrote: > On 14.07.2009 10:04, Douglas McClendon wrote: >> [...]In any event, I'd love to hear what people think. [...] > > I for one think rebooting after install is a very good thing, as only a > full reboot makes sure the install (including boot loaders) was > completely successful and works fine. Also, one possible way to potentially mitigate this danger with yet another device mapper trick would be to- After installation, create a snapshot of the system disk(s), then boot them headlessly under qemu in some way that you could tickle them into proving that the bootloader worked (perhaps an init script that detects this type of test qemu run, and provides some output than can be caught). -dmc From mschwendt at gmail.com Tue Jul 14 09:15:32 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 14 Jul 2009 11:15:32 +0200 Subject: NVR bugs in rawhide In-Reply-To: <4A5C3FF9.3010903@redhat.com> References: <4A5C3FF9.3010903@redhat.com> Message-ID: <20090714111532.4b688163@faldor> On Tue, 14 Jul 2009 10:21:13 +0200, Daniel wrote: > I found 375 possibly wrong NVRs in rawhide. > Can you check it an fix it, please? > I'd like to file bugs for those which won't get fixed in couple weeks. > > Short explanation of detected errors follows: > > Release doesn't contain a %dist tag. > - %dist is missing in Release: in spec Often on purpose. Not a bug. > Extra characters after %dist tag. > - there should not be any characters after %dist > - the only exception is a workaround for older releases to keep upgrade > path: 2.fc10.1 < 2.fc11 > - rawhide definitely shouldn't contain these Should not or must not? > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches > > iniparser-3.0-0.1.b.fc12.src.rpm > - Release format can be wrong. Unknown non-numeric characters in release. Not a bug. The ".1" in "0.1" here is the portion of %release that is more significant than the parts following it. painstakingly, one would bump it with every change of the package, no matter whether the ".b" changes, too. > - Pre-release build's release should start with '0.'. Too late to correct it (for many of the findings). And often they are not even an error, because with post-release (!) scm snapshots, upstream *and* packagers typically don't increase %version -- particulary not if the next official %version is not known yet. So, once the next final upstream release is made, %version will increase. And only then one can reset %release to 0 or 1. From jonathan at jonmasters.org Tue Jul 14 10:45:35 2009 From: jonathan at jonmasters.org (Jon Masters) Date: Tue, 14 Jul 2009 06:45:35 -0400 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C3C12.9050009@filteredperception.org> References: <4A5C3C12.9050009@filteredperception.org> Message-ID: <1247568335.31188.238.camel@perihelion.bos.jonmasters.org> On Tue, 2009-07-14 at 02:04 -0600, Douglas McClendon wrote: > Can you spare 50 or 100K? If you can spare 100K/700M in the forthcoming > Fedora-12 LiveCD, I can provide you with a rebootless installation > experience. > > http://fedoraproject.org/wiki/Features/RebootlessInstaller > > The short story is that you boot the LiveCD/USB, run the installation, > and then, instead of rebooting into the installed OS, you are already > looking at and using it. I think this needs a lot more discussion before it's considered. As others have said, rebooting is often necessary with our current modus operandi and whether we like it or not, it is consistent. Besides, most people don't mind an *expected* reboot after they do a major upgrade. Me, I normally set aside a weekend for Fedora major upgrades anyway. It's not something I'm inclined to do without some planned downtime, since the last two times I've had an hour of fixing to do afterward. Jon. From mschwendt at gmail.com Tue Jul 14 10:56:34 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 14 Jul 2009 12:56:34 +0200 Subject: bchunk: dead package Message-ID: <20090714125634.7ee22a57@faldor> https://fedorahosted.org/rel-eng/ticket/1977 bchunk is said to be obsolete, because "shntool" (also in Fedora) would be superior. If you disagree and find a good reason to adopt bchunk, please find a solution for the open ticket. Originally, I had sponsored Alan Olson (alano) when he wanted to take over this old package in Fedora. A deal that hasn't worked out this time. The single bugzilla ticket (#439661)is without a response/action since over a year. And attempts at contacting alano via private mail and bugzilla have been fruitless. As such, I've removed him from the FAS Packager group, too. From dmc.fedora at filteredperception.org Tue Jul 14 11:04:25 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 14 Jul 2009 05:04:25 -0600 Subject: Feature proposal: Rebootless Installer In-Reply-To: <1247568335.31188.238.camel@perihelion.bos.jonmasters.org> References: <4A5C3C12.9050009@filteredperception.org> <1247568335.31188.238.camel@perihelion.bos.jonmasters.org> Message-ID: <4A5C6639.7030904@filteredperception.org> Jon Masters wrote: > On Tue, 2009-07-14 at 02:04 -0600, Douglas McClendon wrote: > >> Can you spare 50 or 100K? If you can spare 100K/700M in the forthcoming >> Fedora-12 LiveCD, I can provide you with a rebootless installation >> experience. >> >> http://fedoraproject.org/wiki/Features/RebootlessInstaller >> >> The short story is that you boot the LiveCD/USB, run the installation, >> and then, instead of rebooting into the installed OS, you are already >> looking at and using it. > > I think this needs a lot more discussion before it's considered. As > others have said, rebooting is often necessary with our current modus > operandi and whether we like it or not, it is consistent. Besides, most > people don't mind an *expected* reboot after they do a major upgrade. I quite agree that more discussion is needed as it is considered. But my own biased opinion is that several days to a week and a half of flushing out issues here and on the feature talk page, should be sufficient to provide fesco members with enough confidence to approve this feature. Again, I emphasize that this is in a way akin to putting ext4 in f10. It was there, but a default user experience wouldn't touch the code. I think there is a justifiable place in fedora 12 for this experimental technology. Please elaborate on the necessary reboots that are part of the 'current modus operandi'. I can think of a few things, but nothing that would cause me concern that the feature would have any significant detrimental impact on the reception of and satisfaction with F12. I personally think the feature if advertised similarly to one which could lead to data corruption on the root filesystem (e.g. ext4 in f10), that it could overall be appreciated by some users, and be good press at the same time, IMNSHO... But absolutely, before fesco considers this, I do want all the potential gotchas and risks to be thoroughly vetted. I don't however think at all that the risks are such that this is too late a time to seriously propose this for F12. peace... -dmc From mschwendt at gmail.com Tue Jul 14 11:12:10 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 14 Jul 2009 11:12:10 -0000 Subject: Broken dependencies in Fedora 11 - 2009-07-14 Message-ID: <20090714111210.10907.58788@faldor.intranet> ====================================================================== The results in this summary consider Test Updates! ====================================================================== Summary of broken packages (by src.rpm name): beagle gauche-gl gauche-gtk ppl python-repoze-what sunbird synce-kde tomboy vdccm ====================================================================== Broken packages in fedora-11-i386: gauche-gl-0.4.4-4.fc11.i586 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.i586 requires gauche = 0:0.8.13 synce-kde-0.9.1-4.fc11.i586 requires synce-serial vdccm-0.10.1-5.fc11.i586 requires synce-serial ====================================================================== Broken packages in fedora-11-ppc: gauche-gl-0.4.4-4.fc11.ppc requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.ppc requires gauche = 0:0.8.13 synce-kde-0.9.1-4.fc11.ppc requires synce-serial vdccm-0.10.1-5.fc11.ppc requires synce-serial ====================================================================== Broken packages in fedora-11-ppc64: synce-kde-0.9.1-4.fc11.ppc64 requires synce-serial vdccm-0.10.1-5.fc11.ppc64 requires synce-serial ====================================================================== Broken packages in fedora-11-x86_64: gauche-gl-0.4.4-4.fc11.x86_64 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.x86_64 requires gauche = 0:0.8.13 synce-kde-0.9.1-4.fc11.x86_64 requires synce-serial vdccm-0.10.1-5.fc11.x86_64 requires synce-serial ====================================================================== Broken packages in fedora-updates-testing-11-i386: ppl-swiprolog-0.10.2-3.fc11.i586 requires libpl.so.5.7.6 ppl-yap-0.10.2-3.fc11.i586 requires libYap.so python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 thunderbird-lightning-1.0-0.5.20090513hg.fc11.i586 requires thunderbird >= 0:3.0-2.4.b3pre ====================================================================== Broken packages in fedora-updates-testing-11-ppc: ppl-swiprolog-0.10.2-3.fc11.ppc requires libpl.so.5.7.6 ppl-yap-0.10.2-3.fc11.ppc requires libYap.so python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 thunderbird-lightning-1.0-0.5.20090513hg.fc11.ppc requires thunderbird >= 0:3.0-2.4.b3pre ====================================================================== Broken packages in fedora-updates-testing-11-ppc64: beagle-0.3.9-9.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0 beagle-0.3.9-9.fc11.ppc64 requires mono(gsf-sharp) = 0:0.0.0.7 beagle-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 beagle-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 beagle-0.3.9-9.fc11.ppc64 requires mono(taglib-sharp) = 0:2.0.3.2 beagle-evolution-0.3.9-9.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0 beagle-evolution-0.3.9-9.fc11.ppc64 requires mono(evolution-sharp) = 0:5.0.0.0 beagle-gnome-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 beagle-gnome-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 beagle-thunderbird-0.3.9-9.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0 ppl-swiprolog-0.10.2-3.fc11.ppc64 requires libpl.so.5.7.6()(64bit) ppl-yap-0.10.2-3.fc11.ppc64 requires libYap.so()(64bit) python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 thunderbird-lightning-1.0-0.5.20090513hg.fc11.ppc64 requires thunderbird >= 0:3.0-2.4.b3pre tomboy-0.14.3-1.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(Mono.Addins.Setup) = 0:0.4.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(gnome-panel-sharp) = 0:2.24.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(Mono.Addins) = 0:0.4.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(Mono.Addins.Gui) = 0:0.4.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 ====================================================================== Broken packages in fedora-updates-testing-11-x86_64: ppl-swiprolog-0.10.2-3.fc11.x86_64 requires libpl.so.5.7.6()(64bit) ppl-yap-0.10.2-3.fc11.x86_64 requires libYap.so()(64bit) python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 thunderbird-lightning-1.0-0.5.20090513hg.fc11.x86_64 requires thunderbird >= 0:3.0-2.4.b3pre From mschwendt at gmail.com Tue Jul 14 11:16:58 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 14 Jul 2009 13:16:58 +0200 Subject: beagle In-Reply-To: <20090625114833.4b5f2895@noname.noname> References: <20090625114833.4b5f2895@noname.noname> Message-ID: <20090714131658.0d8787a7@faldor> On Thu, 25 Jun 2009 11:48:33 +0200, Michael wrote: > * Delivery to the following recipient failed permanently: > > beagle-owner AT fedoraproject DOT org > > Recipient address rejected: > User unknown in local recipient table (state 14). > > * https://admin.fedoraproject.org/pkgdb/packages/name shows more than a > dozen people on watchcommit+commit, but no package owner. It's an orphan. > > * https://admin.fedoraproject.org/pkgdb/packages/bugs shows more than a > dozen open tickets, but nobody is subscribed to watchbugzilla. > > * "yum list beagle" shows beagle-0.3.9-6.fc11 in "fedora". There is still no beagle-owner for this package. From mrmazda at earthlink.net Tue Jul 14 11:23:49 2009 From: mrmazda at earthlink.net (Felix Miata) Date: Tue, 14 Jul 2009 07:23:49 -0400 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C3C12.9050009@filteredperception.org> References: <4A5C3C12.9050009@filteredperception.org> Message-ID: <4A5C6AC5.4060102@earthlink.net> On 2009/07/14 02:04 (GMT-0600) Douglas McClendon composed: [snip] > http://viros.org/rebootless Doesn't kexec, which does a BIOS bypassing reboot, accomplish what you want? OpenSUSE's installer has had kexec_reboot=1 by default for a version or two (I think default started with 11.1): http://en.opensuse.org/Kexec http://en.opensuse.org/Linuxrc -- No Jesus - No peace , Know Jesus - Know Peace Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ From dmach at redhat.com Tue Jul 14 11:34:07 2009 From: dmach at redhat.com (Daniel Mach) Date: Tue, 14 Jul 2009 13:34:07 +0200 Subject: NVR bugs in rawhide In-Reply-To: <20090714082627.GH4462@tyan-ft48-01.lab.bos.redhat.com> References: <4A5C3FF9.3010903@redhat.com> <20090714082627.GH4462@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <4A5C6D2F.6070501@redhat.com> Jakub Jelinek wrote: > On Tue, Jul 14, 2009 at 10:21:13AM +0200, Daniel Mach wrote: > >> I found 375 possibly wrong NVRs in rawhide. >> Can you check it an fix it, please? >> I'd like to file bugs for those which won't get fixed in couple weeks. >> >> Short explanation of detected errors follows: >> >> Release doesn't contain a %dist tag. >> - %dist is missing in Release: in spec >> - >> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Using_the_.25.7B.3Fdist.7D_Tag >> > > The guideline you refer to says "if you wish to use a single spec file...". > So I don't see why not using %dist would be a bug if you don't wish to do > that. > > Jakub > Right, %dist is not mandatory in Fedora. But Fedora is upstream for RHEL and we'll probably consider this as a bug in RHEL once we import some Fedora packages. I think it's better to fix it upstream rather than do our local fixes. Why we do it? For example, you can't push a rpm signed with two different keys to Spacewalk channels (which happens when you use per-release signing keys). Therefore we have to make difference between NVRs and add %dist. I'll discuss possible Fedora NVR policy changes with spot. - daniel -- Daniel Mach Release Engineering, Red Hat From skvidal at fedoraproject.org Tue Jul 14 11:34:43 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 14 Jul 2009 07:34:43 -0400 (EDT) Subject: NVR bugs in rawhide In-Reply-To: <4A5C6D2F.6070501@redhat.com> References: <4A5C3FF9.3010903@redhat.com> <20090714082627.GH4462@tyan-ft48-01.lab.bos.redhat.com> <4A5C6D2F.6070501@redhat.com> Message-ID: On Tue, 14 Jul 2009, Daniel Mach wrote: >> > Right, %dist is not mandatory in Fedora. > But Fedora is upstream for RHEL and we'll probably consider this as a bug in > RHEL once we import some Fedora packages. > I think it's better to fix it upstream rather than do our local fixes. It being required for rhel does not make it a fedora bug. If you want to fix it for YOUR packages, that's fine, but it's not everyone's problem. > Why we do it? For example, you can't push a rpm signed with two different > keys to Spacewalk channels (which happens when you use per-release signing > keys). > Therefore we have to make difference between NVRs and add %dist. But fedora doesn't use spacewalk and we don't have the above problem. -sv From dmc.fedora at filteredperception.org Tue Jul 14 11:38:54 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 14 Jul 2009 05:38:54 -0600 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C6AC5.4060102@earthlink.net> References: <4A5C3C12.9050009@filteredperception.org> <4A5C6AC5.4060102@earthlink.net> Message-ID: <4A5C6E4E.1080603@filteredperception.org> Felix Miata wrote: > On 2009/07/14 02:04 (GMT-0600) Douglas McClendon composed: > [snip] >> http://viros.org/rebootless > > Doesn't kexec, which does a BIOS bypassing reboot, accomplish what you want? > OpenSUSE's installer has had kexec_reboot=1 by default for a version or two > (I think default started with 11.1): http://en.opensuse.org/Kexec > http://en.opensuse.org/Linuxrc No, from a user experience perspective, a kexec 'warm' reboot is still a reboot. There is AFAIK no user experience example to look to in comparison. Perhaps somewhere along the line people tried pivot_roots after installation, but short of this devicemapper trick, there was always the trouble that tied up file descriptors would prevent you from being able to eject the livecd. I could be wrong about that, or my interpretation of what kexec does (I've read about it often in LWN, but never knowingly used it). Your first link seems currently broken (database error), and the second doesn't really lead me to believe it is anything equivalent. I haven't used *suse that much recently so I can't be sure- Is it perhaps something where they have a very minimal partial installation, then start writing the minimal stuff to disk, kexec-reboot, and then set you up in system that is finishing installing while you use it? If so, one way to describe the major benefit of my rebootless installer, is that you get to boot the livecd/usb environment, *then use it as such*, and at your option, desire, and convenience, decide to permanently install the LiveOS you have just been using and configuring, to disk. And of course when done, just pop out the livecd/usb, and your are done... and free to leave your system with a continuingly increasing uptime :) peace... -dmc From dmach at redhat.com Tue Jul 14 11:40:01 2009 From: dmach at redhat.com (Daniel Mach) Date: Tue, 14 Jul 2009 13:40:01 +0200 Subject: NVR bugs in rawhide In-Reply-To: <1247560203.12445.863.camel@Vain> References: <4A5C3FF9.3010903@redhat.com> <1247560203.12445.863.camel@Vain> Message-ID: <4A5C6E91.7040005@redhat.com> Caol?n McNamara wrote: > On Tue, 2009-07-14 at 10:21 +0200, Daniel Mach wrote: > >> Release doesn't contain a %dist tag. >> - %dist is missing in Release: in spec >> - >> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Using_the_.25.7B.3Fdist.7D_Tag >> > > "If you wish", so until now it hasn't been an error to not have one. Has > this changed ? > Nothing changed. See my reply to Jakub's email, please. > >> Pre-release build's release should start with '0.'. >> - a pre-release build is detected with these patterns: "test", "alpha", >> "beta", "rc", "[\.0-9]a[\.0-9]", "b[0-9]+", "snap", "pre", "dev", >> "build", "bzr", "cvs", "svn", "git", "hg", "trunk", "branch" >> - release should start with .0, but generally it can start with any >> number as long as it's bumped before each build. >> > > But of course we also have post-release snapshot packages, so if > alliance-5.0-26.20070718snap is a svn/cvs snapshot *post* 5.0 release > then its be perfectly correct, right ? > > C. > That's a good point, I was never thinking about post-release snapshot packages, always just about pre-release ones. Thanks for catching that. - daniel -- Daniel Mach Release Engineering, Red Hat From dmach at redhat.com Tue Jul 14 12:21:28 2009 From: dmach at redhat.com (Daniel Mach) Date: Tue, 14 Jul 2009 14:21:28 +0200 Subject: NVR bugs in rawhide In-Reply-To: <20090714111532.4b688163@faldor> References: <4A5C3FF9.3010903@redhat.com> <20090714111532.4b688163@faldor> Message-ID: <4A5C7848.20608@redhat.com> Michael Schwendt wrote: > On Tue, 14 Jul 2009 10:21:13 +0200, Daniel wrote: > > >> I found 375 possibly wrong NVRs in rawhide. >> Can you check it an fix it, please? >> I'd like to file bugs for those which won't get fixed in couple weeks. >> >> Short explanation of detected errors follows: >> >> Release doesn't contain a %dist tag. >> - %dist is missing in Release: in spec >> > > Often on purpose. Not a bug. > Can you be more specific, please? What's exactly the purpose? > >> Extra characters after %dist tag. >> - there should not be any characters after %dist >> - the only exception is a workaround for older releases to keep upgrade >> path: 2.fc10.1 < 2.fc11 >> - rawhide definitely shouldn't contain these >> > > Should not or must not? > Policy doesn't explicitly forbid this, but it's recommendation for "Minor release bumps for old branches". Since rawhide is the devel branch, I wouldn't expect it there. > >> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches >> >> > > >> iniparser-3.0-0.1.b.fc12.src.rpm >> - Release format can be wrong. Unknown non-numeric characters in release. >> > > Not a bug. The ".1" in "0.1" here is the portion of %release that > is more significant than the parts following it. > painstakingly, one would bump it with every change of the package, > no matter whether the ".b" changes, too. > Agree, this is obviously a false-positive. > >> - Pre-release build's release should start with '0.'. >> > > Too late to correct it (for many of the findings). And often they are not > even an error, because with post-release (!) scm snapshots, upstream *and* > packagers typically don't increase %version -- particulary not if the > next official %version is not known yet. So, once the next final > upstream release is made, %version will increase. And only then one > can reset %release to 0 or 1. > Agree. -- Daniel Mach Release Engineering, Red Hat From mschwendt at gmail.com Tue Jul 14 12:48:53 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 14 Jul 2009 14:48:53 +0200 Subject: NVR bugs in rawhide In-Reply-To: <4A5C7848.20608@redhat.com> References: <4A5C3FF9.3010903@redhat.com> <20090714111532.4b688163@faldor> <4A5C7848.20608@redhat.com> Message-ID: <20090714144853.19816cfc@faldor> On Tue, 14 Jul 2009 14:21:28 +0200, Daniel wrote: > >> Release doesn't contain a %dist tag. > >> - %dist is missing in Release: in spec > >> > > > > Often on purpose. Not a bug. > > > Can you be more specific, please? What's exactly the purpose? That %dist isn't used. There are various reasons why somebody may decide against using %dist. One example are noarch data packages that want to utilise koji build inheritance. From jussilehtola at fedoraproject.org Tue Jul 14 12:48:11 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Tue, 14 Jul 2009 15:48:11 +0300 Subject: NVR bugs in rawhide In-Reply-To: <20090714144853.19816cfc@faldor> References: <4A5C3FF9.3010903@redhat.com> <20090714111532.4b688163@faldor> <4A5C7848.20608@redhat.com> <20090714144853.19816cfc@faldor> Message-ID: <1247575691.3164.2.camel@politzer.theorphys.helsinki.fi> On Tue, 2009-07-14 at 14:48 +0200, Michael Schwendt wrote: > On Tue, 14 Jul 2009 14:21:28 +0200, Daniel wrote: > > > >> Release doesn't contain a %dist tag. > > >> - %dist is missing in Release: in spec > > >> > > > > > > Often on purpose. Not a bug. > > > > > Can you be more specific, please? What's exactly the purpose? > > That %dist isn't used. There are various reasons why somebody may decide > against using %dist. One example are noarch data packages that want to > utilise koji build inheritance. ... except that doesn't help anything. See https://bugzilla.redhat.com/show_bug.cgi?id=507915 %dist should be used always. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From tcallawa at redhat.com Tue Jul 14 13:05:58 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 14 Jul 2009 09:05:58 -0400 Subject: NVR bugs in rawhide In-Reply-To: <1247575691.3164.2.camel@politzer.theorphys.helsinki.fi> References: <4A5C3FF9.3010903@redhat.com> <20090714111532.4b688163@faldor> <4A5C7848.20608@redhat.com> <20090714144853.19816cfc@faldor> <1247575691.3164.2.camel@politzer.theorphys.helsinki.fi> Message-ID: <4A5C82B6.7070204@redhat.com> On 07/14/2009 08:48 AM, Jussi Lehtola wrote: > %dist should be used always. As the person who invented %dist, I can assure you, this is false. In the specific situation where a new noarch package with relatively static content is being introduced, you have a few options: * Use %dist * Manually ensure that the upgrade ordering is sane (e.g. foo-1.2.3-1 (fc10), foo-1.2.3-2 (fc11), foo-1.2.3-3 (rawhide) * Only build in rawhide and let inheritance pull it in for future releases (doesn't work for past releases). Admittedly, I think using %dist is easier/saner, but it isn't mandatory. ~spot From bart at vanbrabant.eu Tue Jul 14 13:19:58 2009 From: bart at vanbrabant.eu (Bart Vanbrabant) Date: Tue, 14 Jul 2009 15:19:58 +0200 Subject: Heads UP - PHP 5.3.0 in rawhide with new ABI/API. In-Reply-To: <4A5B660D.3040205@FamilleCollet.com> References: <4A5A2017.3090409@FamilleCollet.com> <4A5B660D.3040205@FamilleCollet.com> Message-ID: > **** TODO > > cups-php > sipwitch-php-swig > uuid-php > php-eaccelerator > php-suhosin Upstream has no new version ready. I do not know if there is any way to disable the package until a new version becomes available. > **** OTHER TODO gr, Bart -- Bart Vanbrabant From bbbush.yuan at gmail.com Tue Jul 14 13:29:06 2009 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Tue, 14 Jul 2009 21:29:06 +0800 Subject: Help on CMake usage (read gecko's "libdir" variable) In-Reply-To: <76e72f800907130708t7f8a17e9p60084e91ac9a2658@mail.gmail.com> References: <76e72f800907130708t7f8a17e9p60084e91ac9a2658@mail.gmail.com> Message-ID: <76e72f800907140629o2c6986d2l5b6dc5becf6e1a6c@mail.gmail.com> 2009/7/13 Yuan Yijun : > Hi, > > The package "chmsee" used to need a patch to read "libdir" variable. > The original patch can be found here > https://bugzilla.redhat.com/attachment.cgi?id=303660 of > https://bugzilla.redhat.com/427622 > > Now latest chmsee switched to use CMake instead. I cannot figure out > how to apply such a patch. Anyone can help? > > problem solved. The patch is no longer necessary because of Gecko's API change: use GRE_GetGREPathWithProperties() and its param of type GREVersionRange to find correct path at runtime. Thanks! -- bbbush ^_^ From mschwendt at gmail.com Tue Jul 14 13:37:37 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 14 Jul 2009 15:37:37 +0200 Subject: NVR bugs in rawhide In-Reply-To: <1247575691.3164.2.camel@politzer.theorphys.helsinki.fi> References: <4A5C3FF9.3010903@redhat.com> <20090714111532.4b688163@faldor> <4A5C7848.20608@redhat.com> <20090714144853.19816cfc@faldor> <1247575691.3164.2.camel@politzer.theorphys.helsinki.fi> Message-ID: <20090714153737.785463f7@faldor> On Tue, 14 Jul 2009 15:48:11 +0300, Jussi wrote: > On Tue, 2009-07-14 at 14:48 +0200, Michael Schwendt wrote: > > On Tue, 14 Jul 2009 14:21:28 +0200, Daniel wrote: > > > > > >> Release doesn't contain a %dist tag. > > > >> - %dist is missing in Release: in spec > > > >> > > > > > > > > Often on purpose. Not a bug. > > > > > > > Can you be more specific, please? What's exactly the purpose? > > > > That %dist isn't used. There are various reasons why somebody may decide > > against using %dist. One example are noarch data packages that want to > > utilise koji build inheritance. > > ... except that doesn't help anything. ?? Let me be more clear then. You don't need to drop %dist for koji build inheritance to work. It just looks much cleaner to inherit foo-1.0-1.noarch.rpm for all newer targets -- than to inherit foo-1.0-1.fc9.noarch.rpm and have users scratch their heads (even if release notes mention that packages with old dist tags may be found in a new dist release). > %dist should be used always. No. Particulary for noarch data packages, using %dist bears an additional risk. Because it becomes possible to tag a package on multiple branches and break inheritance by building for more than the oldest branch. In other cases, for example, %dist suggests that a spec/src.rpm would be dist-independent and could simply be copied to multiple branches. That doesn't need to be true. From choeger at cs.tu-berlin.de Tue Jul 14 13:32:21 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Tue, 14 Jul 2009 15:32:21 +0200 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C3C12.9050009@filteredperception.org> References: <4A5C3C12.9050009@filteredperception.org> Message-ID: <1247578341.8875.8.camel@choeger6> Hi, although (as others pointed out) a reboot may be necessary one way or the other, my opinion would be: Why not? Currently you are *forced* to reboot which now seems not to be a must have. So why not remove that force and allow the user to decide when to reboot? (Maybe one would like to install all available updates before he has to reboot *again* because kernel updates or stuff). So before any flaming starts: Please keep in mind that no one wants to *remove* reboot. ;) my 2ct 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 sundaram at fedoraproject.org Tue Jul 14 13:35:03 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 14 Jul 2009 19:05:03 +0530 Subject: Feature proposal: Rebootless Installer In-Reply-To: <1247578341.8875.8.camel@choeger6> References: <4A5C3C12.9050009@filteredperception.org> <1247578341.8875.8.camel@choeger6> Message-ID: <4A5C8987.9090908@fedoraproject.org> On 07/14/2009 07:02 PM, Christoph H?ger wrote: > Hi, > > although (as others pointed out) a reboot may be necessary one way or > the other, my opinion would be: Why not? > > Currently you are *forced* to reboot which now seems not to be a must > have. Nobody is forced. You must be misremembering things. Rahul From dmc.fedora at filteredperception.org Tue Jul 14 13:46:31 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 14 Jul 2009 07:46:31 -0600 Subject: Feature proposal: Rebootless Installer In-Reply-To: <1247578341.8875.8.camel@choeger6> References: <4A5C3C12.9050009@filteredperception.org> <1247578341.8875.8.camel@choeger6> Message-ID: <4A5C8C37.1030909@filteredperception.org> Christoph H?ger wrote: > Hi, > > although (as others pointed out) a reboot may be necessary one way or > the other, my opinion would be: Why not? > > Currently you are *forced* to reboot which now seems not to be a must > have. Thanks for the feedback. Glad to see somebody else can see the added value that doesn't obviously (to me) imply any negative consequence (except for the 100kb/700M space on the LiveCD). To respond to Rahul's response, I think you have it right. Currently, when doing an install of Fedora 11, without my installer, the user is 'forced' to reboot in order to start 'really' using the newly installed system. (see next paragraph for '' explanation) > So why not remove that force and allow the user to decide when to > reboot? (Maybe one would like to install all available updates before he > has to reboot *again* because kernel updates or stuff). But to demonstrate a lack of bias, I will mention that you are currently able to do something like a chroot'd yum update on the installed system without rebooting, without my installer. But this also highlights the benefit- it's a lot more trivial and intuitive to update your system if it is the one running in front of you, than if it is one you have to mount and chroot, and probably even throw in some bindmounts to manage. > > So before any flaming starts: Please keep in mind that no one wants to > *remove* reboot. ;) ;) peace... -dmc From walters at verbum.org Tue Jul 14 13:51:44 2009 From: walters at verbum.org (Colin Walters) Date: Tue, 14 Jul 2009 09:51:44 -0400 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C3C12.9050009@filteredperception.org> References: <4A5C3C12.9050009@filteredperception.org> Message-ID: On Tue, Jul 14, 2009 at 4:04 AM, Douglas McClendon wrote: > i.e. simply a checkbox before beginning installation stating whether you want rebootless instead of traditional. I don't think the installation process needs more questions. Also, off by default means it won't get testing and will eventually bitrot. It's unclear to me what your plan is for handling firstboot, which is a critical part of the OS setup. Now, we should probably move most of the current firstboot questions into anaconda. At a minimum, it'd be useful to ask them when you'd otherwise be staring at the image copying progress bar. Another issue that occurs to me is that the livecd user, besides not matching the target username, also has no password (and I believe won't have an encrypted gnome keyring), but this is different from the expected target installation. So this looks technically cool, but there are a lot of problems to investigate and solve that it brings up. From jussilehtola at fedoraproject.org Tue Jul 14 13:54:26 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Tue, 14 Jul 2009 16:54:26 +0300 Subject: NVR bugs in rawhide In-Reply-To: <20090714153737.785463f7@faldor> References: <4A5C3FF9.3010903@redhat.com> <20090714111532.4b688163@faldor> <4A5C7848.20608@redhat.com> <20090714144853.19816cfc@faldor> <1247575691.3164.2.camel@politzer.theorphys.helsinki.fi> <20090714153737.785463f7@faldor> Message-ID: <1247579666.3164.5.camel@politzer.theorphys.helsinki.fi> On Tue, 2009-07-14 at 15:37 +0200, Michael Schwendt wrote: > > %dist should be used always. > > No. Particulary for noarch data packages, using %dist bears an > additional risk. Because it becomes possible to tag a package on > multiple branches and break inheritance by building for more than > the oldest branch. So, how do you do it without the %dist branch? AFAIK then you have to manually make sure that the EVR in F(N) is greater than that in F(N-1). Say I've built foo-1-1 in rawhide a year ago and thus the package is available now in F-10 and F-11. How do I update to foo-2-1 in both distros? > In other cases, for example, %dist suggests that a spec/src.rpm would be > dist-independent and could simply be copied to multiple branches. That > doesn't need to be true. Yes, that is true. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From walters at verbum.org Tue Jul 14 13:57:48 2009 From: walters at verbum.org (Colin Walters) Date: Tue, 14 Jul 2009 09:57:48 -0400 Subject: Feature proposal: Rebootless Installer In-Reply-To: References: <4A5C3C12.9050009@filteredperception.org> Message-ID: Another thing to keep in mind that immediately post-installation there are going to be updates, which will at a minimum need desktop reset (fast reboot experience), or more likely system restart. From rc040203 at freenet.de Tue Jul 14 14:01:50 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 14 Jul 2009 16:01:50 +0200 Subject: NVR bugs in rawhide In-Reply-To: <20090714153737.785463f7@faldor> References: <4A5C3FF9.3010903@redhat.com> <20090714111532.4b688163@faldor> <4A5C7848.20608@redhat.com> <20090714144853.19816cfc@faldor> <1247575691.3164.2.camel@politzer.theorphys.helsinki.fi> <20090714153737.785463f7@faldor> Message-ID: <4A5C8FCE.40905@freenet.de> Michael Schwendt wrote: > On Tue, 14 Jul 2009 15:48:11 +0300, Jussi wrote: > >> On Tue, 2009-07-14 at 14:48 +0200, Michael Schwendt wrote: >>> On Tue, 14 Jul 2009 14:21:28 +0200, Daniel wrote: >>> >>>>>> Release doesn't contain a %dist tag. >>>>>> - %dist is missing in Release: in spec >>>>>> >>>>> Often on purpose. Not a bug. >>>>> >>>> Can you be more specific, please? What's exactly the purpose? >>> That %dist isn't used. There are various reasons why somebody may decide >>> against using %dist. One example are noarch data packages that want to >>> utilise koji build inheritance. >> ... except that doesn't help anything. > > ?? Let me be more clear then. > > You don't need to drop %dist for koji build inheritance to work. > > It just looks much cleaner to inherit foo-1.0-1.noarch.rpm for all > newer targets IFF "current rpm" is sufficiently compatible to the antique version of rpm a package has been built on. If this doesn't apply you don't get anywhere. This issue e.g. will hit when rpm should abandon supporting features, say md5 checksums, or when some standard macros should change (Some people might recall %mandir once having moved from /usr/man to /usr/share/man) .... -- than to inherit foo-1.0-1.fc9.noarch.rpm and have > users scratch their heads (even if release notes mention that packages > with old dist tags may be found in a new dist release). > >> %dist should be used always. > > No. Particulary for noarch data packages, using %dist bears an > additional risk. Because it becomes possible to tag a package on > multiple branches and break inheritance by building for more than > the oldest branch. To me, this is not a risk, but a valuable feature. > In other cases, for example, %dist suggests that a spec/src.rpm would be > dist-independent and could simply be copied to multiple branches. That > doesn't need to be true. Well, a package is never distro independent, it is always distro dependent, because an *.rpm always has some distro specific rpm-setting built-in. Even noarch packages. => I agree with Jussi. Allowing people not to use %dist is not helpful. It's a booby trap which certainly will hit some day. Ralf From dmc.fedora at filteredperception.org Tue Jul 14 14:06:10 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 14 Jul 2009 08:06:10 -0600 Subject: Feature proposal: Rebootless Installer In-Reply-To: References: <4A5C3C12.9050009@filteredperception.org> Message-ID: <4A5C90D2.4020706@filteredperception.org> Colin Walters wrote: > On Tue, Jul 14, 2009 at 4:04 AM, Douglas > McClendon wrote: > >> i.e. simply a checkbox before beginning installation stating whether you want rebootless instead of traditional. > > I don't think the installation process needs more questions. Also, > off by default means it won't get testing and will eventually bitrot. I think we would only ever consider adding a checkbox (not a question) to anaconda, if the initial reception of the feature in, e.g. F12, was so positive that it justified it without requiring any advocacy on my part. > > It's unclear to me what your plan is for handling firstboot, which is > a critical part of the OS setup. Now, we should probably move most of > the current firstboot questions into anaconda. At a minimum, it'd be > useful to ask them when you'd otherwise be staring at the image > copying progress bar. I'll try to add this to the wiki. My intention was to start with the minimum possible for the first experimental release (f12, alpha freeze in 3 weeks). With the feature accepted, and me currently being unemployed, the minimum possible might actually be quite a bit though. My answer of course is the same as what you mentioned, they go into the installer. Honestly a create user, change rootpw, and similar complexity pages are not that difficult to add. It is also quite acceptable to move anything that can be done as 'regular system maintenance and reconfiguration' out of the installer. The whole philosophy of a LiveOS is that you boot in the most generic agnostic way possible, and let the user configure at runtime. I.e. it's actually a really good thing IMO to force the user to say use system-config-time or whatever to change the timezone. I know too many examples from personal experience, dating back to the days when you couldn't easily tab out system-config- how much of a pain it was to learn how to administer things that were done in the installer. > Another issue that occurs to me is that the livecd user, besides not > matching the target username, also has no password (and I believe > won't have an encrypted gnome keyring), but this is different from the > expected target installation. My long term ideal vision for this, would be to have gdm login accept an arbitrary user/pass instead of the autologin of liveuser, then that user/pass would be the initial user. Obviously with an option at install time to disable the mode subsequently, probably default on. Though possibly left off for people who want a very guest permissive system. For now, a simple addition to my installer already in my ROADMAP is a checkbox in the installer 'delete liveuser account upon logout'. > So this looks technically cool, but there are a lot of problems to > investigate and solve that it brings up. Thanks for the positive feedback, and I do agree. In response to some of the prior feedback, I already adjusted the wiki release notes to emphasize the experimental status. peace... -dmc From dmc.fedora at filteredperception.org Tue Jul 14 14:09:09 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 14 Jul 2009 08:09:09 -0600 Subject: Feature proposal: Rebootless Installer In-Reply-To: References: <4A5C3C12.9050009@filteredperception.org> Message-ID: <4A5C9185.5010800@filteredperception.org> Colin Walters wrote: > Another thing to keep in mind that immediately post-installation there > are going to be updates, which will at a minimum need desktop reset > (fast reboot experience), or more likely system restart. I don't exactly get this. I might understand some negligible things. But historically I've often done -normal install, reboot -booted, logged in using everying, then a massive yum update, then I'd wait till it was absolutely convenient to logout of the desktop or reboot In fact, when I felt I needed to do it before my convenience, I generally regarded it as a pretty horrible bug. peace... -dmc From martin.sourada at gmail.com Tue Jul 14 14:13:11 2009 From: martin.sourada at gmail.com (Martin Sourada) Date: Tue, 14 Jul 2009 16:13:11 +0200 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C3C12.9050009@filteredperception.org> References: <4A5C3C12.9050009@filteredperception.org> Message-ID: <1247580791.3916.14.camel@pc-notebook.kolej.mff.cuni.cz> On Tue, 2009-07-14 at 02:04 -0600, Douglas McClendon wrote: > Fedorans, > > Can you spare 50 or 100K? If you can spare 100K/700M in the forthcoming > Fedora-12 LiveCD, I can provide you with a rebootless installation > experience. > > http://fedoraproject.org/wiki/Features/RebootlessInstaller > > The short story is that you boot the LiveCD/USB, run the installation, > and then, instead of rebooting into the installed OS, you are already > looking at and using it. > Hi Doug, I think this is an interesting idea and I don't see why you it should not be done (if you are willing to do the work). It would also IMHO be a cool killing feature (from marketing POV) ;-) My idea of how this would be implemented best is: 1. do the installation 2. on the last page instead of plain "thank you for installing" and "exit" (I don't recall what exactly is on the last anaconda page) would be "thank you for installing" and "start using the installed system now", "continue using {Desktop, KDE, ...} Live" and "reboot" buttons. If you pushed the "start using the installed system now" you'd start using the system from hdd and the live CD/DVD would be ejected. Also it would be probably good idea to pop-up a notification icon that suggests reboot (like package-kit does for e.g. kernel updates). If you pushed the "continue using {Desktop, KDE, ...} Live" it would just quit the installer and suggest reboot in a similar case as before. If you pushed the "reboot one" it would quit the installer and forced a reboot (and perhaps prompted the user to save their work). Of course it could be made into radiobuttons instead of buttons with just one "Finish" or whatever button. The default would stay "continue using {Desktop, KDE, ...} Live". This would of course work only for Live Spins, I don't see any reason to try to push this to the "standard" DVD or network installs. Also you'd need to properly handle firstboot in this case, which would be bypassed. Me thinks firstboot should be purged anyway, but it still exists and you need to be aware of it. Just my ?0.02, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mrmazda at earthlink.net Tue Jul 14 14:14:09 2009 From: mrmazda at earthlink.net (Felix Miata) Date: Tue, 14 Jul 2009 10:14:09 -0400 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C6E4E.1080603@filteredperception.org> References: <4A5C3C12.9050009@filteredperception.org> <4A5C6AC5.4060102@earthlink.net> <4A5C6E4E.1080603@filteredperception.org> Message-ID: <4A5C92B1.5020203@earthlink.net> On 2009/07/14 05:38 (GMT-0600) Douglas McClendon composed: > Felix Miata wrote: >> Doesn't kexec, which does a BIOS bypassing reboot, accomplish what you want? >> OpenSUSE's installer has had kexec_reboot=1 by default for a version or two >> (I think default started with 11.1): http://en.opensuse.org/Kexec >> http://en.opensuse.org/Linuxrc > ... I could be wrong about that, or my > interpretation of what kexec does ... The first URL explains it. > Your first link seems currently broken (database error), and the second It worked and works for me. > doesn't really lead me to believe it is anything equivalent. The second URL is mainly a list of installer options, and affirms my statement that kexec is now a default option. > used *suse that much recently so I can't be sure- Is it perhaps > something where they have a very minimal partial installation, then > start writing the minimal stuff to disk, kexec-reboot, and then set you > up in system that is finishing installing while you use it? If so, one IIRC most rpms, initrd & Grub are installed by the initial installer, then kexec prior to most configuration steps by the installer now running on the installed kernel instead of the installation kernel. -- No Jesus - No peace , Know Jesus - Know Peace Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ From choeger at cs.tu-berlin.de Tue Jul 14 14:16:16 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Tue, 14 Jul 2009 16:16:16 +0200 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C8987.9090908@fedoraproject.org> References: <4A5C3C12.9050009@filteredperception.org> <1247578341.8875.8.camel@choeger6> <4A5C8987.9090908@fedoraproject.org> Message-ID: <1247580976.8875.11.camel@choeger6> > Nobody is forced. You must be misremembering things. Huh? Plain installing worked without reboot? Did not notice that last weekend with f11 i386 dvd. -------------- 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 dmc.fedora at filteredperception.org Tue Jul 14 14:21:14 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 14 Jul 2009 08:21:14 -0600 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C92B1.5020203@earthlink.net> References: <4A5C3C12.9050009@filteredperception.org> <4A5C6AC5.4060102@earthlink.net> <4A5C6E4E.1080603@filteredperception.org> <4A5C92B1.5020203@earthlink.net> Message-ID: <4A5C945A.4030805@filteredperception.org> Felix Miata wrote: > On 2009/07/14 05:38 (GMT-0600) Douglas McClendon composed: > >> Felix Miata wrote: > >>> Doesn't kexec, which does a BIOS bypassing reboot, accomplish what you want? >>> OpenSUSE's installer has had kexec_reboot=1 by default for a version or two >>> (I think default started with 11.1): http://en.opensuse.org/Kexec >>> http://en.opensuse.org/Linuxrc > >> ... I could be wrong about that, or my >> interpretation of what kexec does ... > > The first URL explains it. > >> Your first link seems currently broken (database error), and the second > > It worked and works for me. Yeah, it's working now. My impression from LWN was correct. > >> doesn't really lead me to believe it is anything equivalent. > > The second URL is mainly a list of installer options, and affirms my > statement that kexec is now a default option. > >> used *suse that much recently so I can't be sure- Is it perhaps >> something where they have a very minimal partial installation, then >> start writing the minimal stuff to disk, kexec-reboot, and then set you >> up in system that is finishing installing while you use it? If so, one > > IIRC most rpms, initrd & Grub are installed by the initial installer, then > kexec prior to most configuration steps by the installer now running on the > installed kernel instead of the installation kernel. So it is in fact like what I supposed, except instead of a minimal install before kexec, it's basically the full install followed by a kexec reboot. Which again, is an entirely different user experience. peace... -dmc From stickster at gmail.com Tue Jul 14 14:23:11 2009 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 14 Jul 2009 10:23:11 -0400 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C9185.5010800@filteredperception.org> References: <4A5C3C12.9050009@filteredperception.org> <4A5C9185.5010800@filteredperception.org> Message-ID: <20090714142311.GK18297@localhost.localdomain> On Tue, Jul 14, 2009 at 08:09:09AM -0600, Douglas McClendon wrote: > Colin Walters wrote: >> Another thing to keep in mind that immediately post-installation there >> are going to be updates, which will at a minimum need desktop reset >> (fast reboot experience), or more likely system restart. > > I don't exactly get this. I might understand some negligible things. But > historically I've often done > > -normal install, reboot > > -booted, logged in using everying, then a massive yum update, then I'd > wait till it was absolutely convenient to logout of the desktop or reboot > > In fact, when I felt I needed to do it before my convenience, I generally > regarded it as a pretty horrible bug. I thought that preupgrade is supposed to help ease this discomfort. It deals pretty well with combining the base release of the new distro with package updates, and you reboot when you're ready. There's nothing in preupgrade to deal with repartitioning, though, it's purely for an in-place upgrade. Downloading happens in the background, and you reboot when you're ready to run the transaction. May not cover all the cases you're looking at, but worth noting. -- 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 ville.skytta at iki.fi Tue Jul 14 14:29:33 2009 From: ville.skytta at iki.fi (Ville =?windows-1252?q?Skytt=E4?=) Date: Tue, 14 Jul 2009 17:29:33 +0300 Subject: epel-release in Fedora repos? (was: Re: NVR bugs in rawhide) In-Reply-To: <4A5C3FF9.3010903@redhat.com> References: <4A5C3FF9.3010903@redhat.com> Message-ID: <200907141729.34196.ville.skytta@iki.fi> On Tuesday 14 July 2009, Daniel Mach wrote: > epel-release-6-2.src.rpm Why is the epel-release package shipped in Fedora repos? From ville.skytta at iki.fi Tue Jul 14 14:33:30 2009 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 14 Jul 2009 17:33:30 +0300 Subject: rpm %defattr question In-Reply-To: <1247513095.3095.3.camel@localhost.localdomain> References: <1247356269.22031.1.camel@hawking.theorphys.helsinki.fi> <200907132207.15588.ville.skytta@iki.fi> <1247513095.3095.3.camel@localhost.localdomain> Message-ID: <200907141733.30646.ville.skytta@iki.fi> On Monday 13 July 2009, Jussi Lehtola wrote: > On Mon, 2009-07-13 at 22:07 +0300, Ville Skytt? wrote: > > On Sunday 12 July 2009, Jussi Lehtola wrote: > > > is the default attribute definition > > > %defattr(-,root,root) > > > the same as > > > %defattr(-,root,root,-)? > > > > Currently yes, the latter is just more explicit. > > .. and is this going to change at some stage? Your guess is as good as mine, but I don't know why it would need to change. From dgregor at redhat.com Tue Jul 14 14:33:49 2009 From: dgregor at redhat.com (Dennis Gregorovic) Date: Tue, 14 Jul 2009 10:33:49 -0400 Subject: NVR bugs in rawhide In-Reply-To: <4A5C82B6.7070204@redhat.com> References: <4A5C3FF9.3010903@redhat.com> <20090714111532.4b688163@faldor> <4A5C7848.20608@redhat.com> <20090714144853.19816cfc@faldor> <1247575691.3164.2.camel@politzer.theorphys.helsinki.fi> <4A5C82B6.7070204@redhat.com> Message-ID: <1247582029.3469.54.camel@localhost.localdomain> On Tue, 2009-07-14 at 09:05 -0400, Tom "spot" Callaway wrote: > On 07/14/2009 08:48 AM, Jussi Lehtola wrote: > > %dist should be used always. > > As the person who invented %dist, I can assure you, this is false. > > In the specific situation where a new noarch package with relatively > static content is being introduced, you have a few options: > > * Use %dist > * Manually ensure that the upgrade ordering is sane (e.g. foo-1.2.3-1 > (fc10), foo-1.2.3-2 (fc11), foo-1.2.3-3 (rawhide) > * Only build in rawhide and let inheritance pull it in for future > releases (doesn't work for past releases). > > Admittedly, I think using %dist is easier/saner, but it isn't mandatory. > > ~spot In F11 Everything, there are 211 i386 packages without the dist tag and just 81 noarch packages without the dist tag. So, it's definitely not just the noarch packages that aren't using the dist tag. Personally, I think that the dist tag usage should be strongly encouraged for all packages. It makes rebuilds and upgrade easier and the only potential downside is a small cosmetic one. Cheers -- Dennis From dmc.fedora at filteredperception.org Tue Jul 14 14:35:34 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 14 Jul 2009 08:35:34 -0600 Subject: Feature proposal: Rebootless Installer In-Reply-To: <1247580791.3916.14.camel@pc-notebook.kolej.mff.cuni.cz> References: <4A5C3C12.9050009@filteredperception.org> <1247580791.3916.14.camel@pc-notebook.kolej.mff.cuni.cz> Message-ID: <4A5C97B6.9060602@filteredperception.org> Martin Sourada wrote: > On Tue, 2009-07-14 at 02:04 -0600, Douglas McClendon wrote: >> Fedorans, >> >> Can you spare 50 or 100K? If you can spare 100K/700M in the forthcoming >> Fedora-12 LiveCD, I can provide you with a rebootless installation >> experience. >> >> http://fedoraproject.org/wiki/Features/RebootlessInstaller >> >> The short story is that you boot the LiveCD/USB, run the installation, >> and then, instead of rebooting into the installed OS, you are already >> looking at and using it. >> > > Hi Doug, > > I think this is an interesting idea and I don't see why you it should > not be done (if you are willing to do the work). It would also IMHO be a > cool killing feature (from marketing POV) ;-) My idea of how this would > be implemented best is: Hi Martin, thanks for the great feedback. As you can see from the project page, I already have a simple/experimental implementation, which I would like to get accepted more or less as is, perhaps prioritizing more on functionality for F12 than features. But you brought up some good ideas... > 1. do the installation > 2. on the last page instead of plain "thank you for installing" and > "exit" (I don't recall what exactly is on the last anaconda page) would > be "thank you for installing" and "start using the installed system > now", "continue using {Desktop, KDE, ...} Live" and "reboot" buttons. That is more or less what I have, or rather, I have a big text widget with the simplest line of text currently. The text for the intro and final pages, and other places, I definitely expect to hone based on feedback like yours. After the feature is accepted, and even before, I'll gladly accept patches :) > If you pushed the "start using the installed system now" you'd start > using the system from hdd and the live CD/DVD would be ejected. Also it > would be probably good idea to pop-up a notification icon that suggests > reboot (like package-kit does for e.g. kernel updates). How about a mention in the intro or success page that mentions the minimal root-on-lvm performance hit until the next reboot. Other than that, there is no reason to suggest the reboot. Or rather, just let packagekit do what packagekit does, and get an updated kernel, and then give the suggest like normal, for the normal reason? > > If you pushed the "continue using {Desktop, KDE, ...} Live" it would > just quit the installer and suggest reboot in a similar case as before. > > If you pushed the "reboot one" it would quit the installer and forced a > reboot (and perhaps prompted the user to save their work). Adding an optional reboot button to the success page is certainly a reasonable idea, fairly trivial to add. > Of course it could be made into radiobuttons instead of buttons with > just one "Finish" or whatever button. > > The default would stay "continue using {Desktop, KDE, ...} Live". > > This would of course work only for Live Spins, I don't see any reason to > try to push this to the "standard" DVD or network installs. I agree, this is definitely a 'LiveOS' thing. > > Also you'd need to properly handle firstboot in this case, which would > be bypassed. Me thinks firstboot should be purged anyway, but it still > exists and you need to be aware of it. There really isn't that much there these days anyway. See my reply to Colin for a discussion of that. Thanks again for good design ideas, peace... -dmc From christoph.wickert at googlemail.com Tue Jul 14 14:38:12 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Tue, 14 Jul 2009 16:38:12 +0200 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C8987.9090908@fedoraproject.org> References: <4A5C3C12.9050009@filteredperception.org> <1247578341.8875.8.camel@choeger6> <4A5C8987.9090908@fedoraproject.org> Message-ID: <1247582292.15109.60.camel@localhost> Am Dienstag, den 14.07.2009, 19:05 +0530 schrieb Rahul Sundaram: > On 07/14/2009 07:02 PM, Christoph H?ger wrote: > > Hi, > > > > although (as others pointed out) a reboot may be necessary one way or > > the other, my opinion would be: Why not? > > > > Currently you are *forced* to reboot which now seems not to be a must > > have. > > Nobody is forced. You must be misremembering things. Obviously you are the one misremembering things: http://cwickert.fedorapeople.org/temp/anaconda-last-screen.png > Rahul Regards, Christoph From sundaram at fedoraproject.org Tue Jul 14 14:40:22 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 14 Jul 2009 20:10:22 +0530 Subject: Feature proposal: Rebootless Installer In-Reply-To: <1247580976.8875.11.camel@choeger6> References: <4A5C3C12.9050009@filteredperception.org> <1247578341.8875.8.camel@choeger6> <4A5C8987.9090908@fedoraproject.org> <1247580976.8875.11.camel@choeger6> Message-ID: <4A5C98D6.3070004@fedoraproject.org> On 07/14/2009 07:46 PM, Christoph H?ger wrote: > >> Nobody is forced. You must be misremembering things. > > Huh? Plain installing worked without reboot? Did not notice that last > weekend with f11 i386 dvd. Live CD installation. You aren't "forced" to do a reboot. Rahul From sundaram at fedoraproject.org Tue Jul 14 14:42:03 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 14 Jul 2009 20:12:03 +0530 Subject: Feature proposal: Rebootless Installer In-Reply-To: <1247582292.15109.60.camel@localhost> References: <4A5C3C12.9050009@filteredperception.org> <1247578341.8875.8.camel@choeger6> <4A5C8987.9090908@fedoraproject.org> <1247582292.15109.60.camel@localhost> Message-ID: <4A5C993B.2070600@fedoraproject.org> On 07/14/2009 08:08 PM, Christoph Wickert wrote: > Am Dienstag, den 14.07.2009, 19:05 +0530 schrieb Rahul Sundaram: >> On 07/14/2009 07:02 PM, Christoph H?ger wrote: >>> Hi, >>> >>> although (as others pointed out) a reboot may be necessary one way or >>> the other, my opinion would be: Why not? >>> >>> Currently you are *forced* to reboot which now seems not to be a must >>> have. >> >> Nobody is forced. You must be misremembering things. > > Obviously you are the one misremembering things: > http://cwickert.fedorapeople.org/temp/anaconda-last-screen.png We are talking about a live cd installation, yes? You can close the installer then. Rahul From martin.sourada at gmail.com Tue Jul 14 14:49:42 2009 From: martin.sourada at gmail.com (Martin Sourada) Date: Tue, 14 Jul 2009 16:49:42 +0200 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C993B.2070600@fedoraproject.org> References: <4A5C3C12.9050009@filteredperception.org> <1247578341.8875.8.camel@choeger6> <4A5C8987.9090908@fedoraproject.org> <1247582292.15109.60.camel@localhost> <4A5C993B.2070600@fedoraproject.org> Message-ID: <1247582983.3916.40.camel@pc-notebook.kolej.mff.cuni.cz> On Tue, 2009-07-14 at 20:12 +0530, Rahul Sundaram wrote: > We are talking about a live cd installation, yes? You can close the > installer then. > Yes, and reboot in order to be able to use the installed system. The suggested feature is, as I understand it, trying to make this reboot optional, i.e. not necessary. There's no need to play with words like "forced" reboot. It is clearly not directly forced in the Live install, yet still necessary, so someone actually could consider it forced (indirectly)... > Rahul > Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dmc.fedora at filteredperception.org Tue Jul 14 14:54:51 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 14 Jul 2009 08:54:51 -0600 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C993B.2070600@fedoraproject.org> References: <4A5C3C12.9050009@filteredperception.org> <1247578341.8875.8.camel@choeger6> <4A5C8987.9090908@fedoraproject.org> <1247582292.15109.60.camel@localhost> <4A5C993B.2070600@fedoraproject.org> Message-ID: <4A5C9C3B.6040002@filteredperception.org> Rahul Sundaram wrote: > On 07/14/2009 08:08 PM, Christoph Wickert wrote: >> Am Dienstag, den 14.07.2009, 19:05 +0530 schrieb Rahul Sundaram: >>> On 07/14/2009 07:02 PM, Christoph H?ger wrote: >>>> Hi, >>>> >>>> although (as others pointed out) a reboot may be necessary one way or >>>> the other, my opinion would be: Why not? >>>> >>>> Currently you are *forced* to reboot which now seems not to be a must >>>> have. >>> Nobody is forced. You must be misremembering things. >> Obviously you are the one misremembering things: >> http://cwickert.fedorapeople.org/temp/anaconda-last-screen.png > > We are talking about a live cd installation, yes? You can close the > installer then. Rahul, let's stay on topic and not split semantic hairs. We both know you aren't trying to suggest that there is no significant difference between my rebootless installer and the traditional (anaconda) live installer. But your arguing of this point could be interpreted like that out of context. peace... -dmc From dmc.fedora at filteredperception.org Tue Jul 14 14:43:09 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 14 Jul 2009 08:43:09 -0600 Subject: Feature proposal: Rebootless Installer In-Reply-To: <20090714142311.GK18297@localhost.localdomain> References: <4A5C3C12.9050009@filteredperception.org> <4A5C9185.5010800@filteredperception.org> <20090714142311.GK18297@localhost.localdomain> Message-ID: <4A5C997D.5070306@filteredperception.org> Paul W. Frields wrote: > On Tue, Jul 14, 2009 at 08:09:09AM -0600, Douglas McClendon wrote: >> Colin Walters wrote: >>> Another thing to keep in mind that immediately post-installation there >>> are going to be updates, which will at a minimum need desktop reset >>> (fast reboot experience), or more likely system restart. >> I don't exactly get this. I might understand some negligible things. But >> historically I've often done >> >> -normal install, reboot >> >> -booted, logged in using everying, then a massive yum update, then I'd >> wait till it was absolutely convenient to logout of the desktop or reboot >> >> In fact, when I felt I needed to do it before my convenience, I generally >> regarded it as a pretty horrible bug. > > I thought that preupgrade is supposed to help ease this discomfort. > It deals pretty well with combining the base release of the new distro > with package updates, and you reboot when you're ready. There's > nothing in preupgrade to deal with repartitioning, though, it's purely > for an in-place upgrade. Downloading happens in the background, and > you reboot when you're ready to run the transaction. May not cover > all the cases you're looking at, but worth noting. Yes, I do see how preupgrade does ease that discomfort. The RebootlessInstaller's use-case is only about installations, not upgrades. Though... (envisioning lots of future work that I'm not that interested in doing myself) peace... -dmc From choeger at cs.tu-berlin.de Tue Jul 14 14:53:47 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Tue, 14 Jul 2009 16:53:47 +0200 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C993B.2070600@fedoraproject.org> References: <4A5C3C12.9050009@filteredperception.org> <1247578341.8875.8.camel@choeger6> <4A5C8987.9090908@fedoraproject.org> <1247582292.15109.60.camel@localhost> <4A5C993B.2070600@fedoraproject.org> Message-ID: <1247583227.8875.14.camel@choeger6> > We are talking about a live cd installation, yes? You can close the > installer then. We were talking about anaconda. And I still don't know a sane (aka "no manual chroot") way to go from livecd into the fresh installed environment. You surely agree that users that know about chroot are probably not the ones adressed with the "hey, cool, in this linux thingy i do not need to reboot after install" feature, don't you? -------------- 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 sundaram at fedoraproject.org Tue Jul 14 14:54:23 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 14 Jul 2009 20:24:23 +0530 Subject: Feature proposal: Rebootless Installer In-Reply-To: <1247583227.8875.14.camel@choeger6> References: <4A5C3C12.9050009@filteredperception.org> <1247578341.8875.8.camel@choeger6> <4A5C8987.9090908@fedoraproject.org> <1247582292.15109.60.camel@localhost> <4A5C993B.2070600@fedoraproject.org> <1247583227.8875.14.camel@choeger6> Message-ID: <4A5C9C1F.8060401@fedoraproject.org> On 07/14/2009 08:23 PM, Christoph H?ger wrote: >> We are talking about a live cd installation, yes? You can close the >> installer then. > > We were talking about anaconda. And I still don't know a sane (aka "no > manual chroot") way to go from livecd into the fresh installed > environment. > You surely agree that users that know about chroot are probably not the > ones adressed with the "hey, cool, in this linux thingy i do not need to > reboot after install" feature, don't you? I never suggested otherwise but my point is simply that describing the current experience as being forced to reboot doesn't sound appropriate. You are free to continue working on the live environment post installation unlike in regular installations. That is a significant difference, IMO. Rahul From dmc.fedora at filteredperception.org Tue Jul 14 15:00:06 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 14 Jul 2009 09:00:06 -0600 Subject: Feature proposal: Rebootless Installer In-Reply-To: <1247583227.8875.14.camel@choeger6> References: <4A5C3C12.9050009@filteredperception.org> <1247578341.8875.8.camel@choeger6> <4A5C8987.9090908@fedoraproject.org> <1247582292.15109.60.camel@localhost> <4A5C993B.2070600@fedoraproject.org> <1247583227.8875.14.camel@choeger6> Message-ID: <4A5C9D76.2080201@filteredperception.org> Christoph H?ger wrote: >> We are talking about a live cd installation, yes? You can close the >> installer then. > > We were talking about anaconda. And I still don't know a sane (aka "no > manual chroot") way to go from livecd into the fresh installed > environment. If you look at the feature page and watch 18 minutes of youtube videos, and/or look at my code, I think you'll have to admit there is 'a way' to do it. I certainly won't be offended by the label 'insane' however, unless of course you find technical problems with my implementation, in which case, I still won't mind the label, I'll just go fix em. > You surely agree that users that know about chroot are probably not the > ones adressed with the "hey, cool, in this linux thingy i do not need to > reboot after install" feature, don't you? Given that I'm precisely the kind of person who is comfortable doing the chroot dance, and I get the most joy from using my installer, I'd have to biasedly suggest that it is for everyone who thinks its kindof cool. peace... -dmc From dmc.fedora at filteredperception.org Tue Jul 14 15:02:17 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 14 Jul 2009 09:02:17 -0600 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C9C1F.8060401@fedoraproject.org> References: <4A5C3C12.9050009@filteredperception.org> <1247578341.8875.8.camel@choeger6> <4A5C8987.9090908@fedoraproject.org> <1247582292.15109.60.camel@localhost> <4A5C993B.2070600@fedoraproject.org> <1247583227.8875.14.camel@choeger6> <4A5C9C1F.8060401@fedoraproject.org> Message-ID: <4A5C9DF9.2080100@filteredperception.org> Rahul Sundaram wrote: > On 07/14/2009 08:23 PM, Christoph H?ger wrote: >>> We are talking about a live cd installation, yes? You can close the >>> installer then. >> We were talking about anaconda. And I still don't know a sane (aka "no >> manual chroot") way to go from livecd into the fresh installed >> environment. >> You surely agree that users that know about chroot are probably not the >> ones adressed with the "hey, cool, in this linux thingy i do not need to >> reboot after install" feature, don't you? > > I never suggested otherwise but my point is simply that describing the > current experience as being forced to reboot doesn't sound appropriate. > You are free to continue working on the live environment post > installation unlike in regular installations. That is a significant > difference, IMO. I agree that is a significant already existing benefit of Fedora's LiveOS. I would just hope you would agree that the leap to not having to deal with the chroot, and just being 'already in your installed system' is as significant a difference as well. peace... -dmc From christoph.wickert at googlemail.com Tue Jul 14 15:04:45 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Tue, 14 Jul 2009 17:04:45 +0200 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C9185.5010800@filteredperception.org> References: <4A5C3C12.9050009@filteredperception.org> <4A5C9185.5010800@filteredperception.org> Message-ID: <1247583885.15109.112.camel@localhost> Am Dienstag, den 14.07.2009, 08:09 -0600 schrieb Douglas McClendon: > Colin Walters wrote: > > Another thing to keep in mind that immediately post-installation there > > are going to be updates, which will at a minimum need desktop reset > > (fast reboot experience), or more likely system restart. > > I don't exactly get this. I might understand some negligible things. > But historically I've often done > > -normal install, reboot > > -booted, logged in using everying, then a massive yum update, then I'd > wait till it was absolutely convenient to logout of the desktop or reboot You wouldn't need no yum update if you enabled the updates repo during install. It's a single click. Your proposal sounds interesting, but I have two questions/issues: 1. The installation is not finished after reboot because we have firstboot. How to trigger firstboot in a rebootless install? 2. Imagine after the installation you switch rebootless to the new system and install a kmod. But you are still running the kernel from the installation medium and kmods get installed for the running kernel, which not necessarily needs to be the one that was installed. Regards, Christoph From mschwendt at gmail.com Tue Jul 14 15:23:25 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 14 Jul 2009 17:23:25 +0200 Subject: NVR bugs in rawhide In-Reply-To: <1247579666.3164.5.camel@politzer.theorphys.helsinki.fi> References: <4A5C3FF9.3010903@redhat.com> <20090714111532.4b688163@faldor> <4A5C7848.20608@redhat.com> <20090714144853.19816cfc@faldor> <1247575691.3164.2.camel@politzer.theorphys.helsinki.fi> <20090714153737.785463f7@faldor> <1247579666.3164.5.camel@politzer.theorphys.helsinki.fi> Message-ID: <20090714172325.4f54113f@faldor> On Tue, 14 Jul 2009 16:54:26 +0300, Jussi wrote: > On Tue, 2009-07-14 at 15:37 +0200, Michael Schwendt wrote: > > > %dist should be used always. > > > > No. Particulary for noarch data packages, using %dist bears an > > additional risk. Because it becomes possible to tag a package on > > multiple branches and break inheritance by building for more than > > the oldest branch. > > So, how do you do it without the %dist branch? AFAIK then you have to > manually make sure that the EVR in F(N) is greater than that in F(N-1). Is it a problem? I don't think so. Even _with_ %dist there are pitfalls. > Say I've built foo-1-1 in rawhide a year ago and thus the package is > available now in F-10 and F-11. How do I update to foo-2-1 in both > distros? Whether with %dist or not, doesn't make a difference. You commit the upgrade to the branch that previously targeted rawhide. F-10 in your example. From dmc.fedora at filteredperception.org Tue Jul 14 15:20:10 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 14 Jul 2009 09:20:10 -0600 Subject: Feature proposal: Rebootless Installer In-Reply-To: <1247583885.15109.112.camel@localhost> References: <4A5C3C12.9050009@filteredperception.org> <4A5C9185.5010800@filteredperception.org> <1247583885.15109.112.camel@localhost> Message-ID: <4A5CA22A.2030307@filteredperception.org> Christoph Wickert wrote: > Am Dienstag, den 14.07.2009, 08:09 -0600 schrieb Douglas McClendon: >> Colin Walters wrote: >>> Another thing to keep in mind that immediately post-installation there >>> are going to be updates, which will at a minimum need desktop reset >>> (fast reboot experience), or more likely system restart. >> I don't exactly get this. I might understand some negligible things. >> But historically I've often done >> >> -normal install, reboot >> >> -booted, logged in using everying, then a massive yum update, then I'd >> wait till it was absolutely convenient to logout of the desktop or reboot > > You wouldn't need no yum update if you enabled the updates repo during > install. It's a single click. I don't know this off the top of my head, but I think I can say with some certainty- either that isn't possible with the current LiveOS installer, or if it is, the same thing is a trivial addition to mine. I.e. in the context of my rebootless installer, it is literally just a checkbox which spawns a yum update, or pokes packagekit to do the same. > > Your proposal sounds interesting, but I have two questions/issues: > 1. The installation is not finished after reboot because we have > firstboot. How to trigger firstboot in a rebootless install? firstboot really just isn't that much. It is all stuff that can be done just as easily in the running system. But as mentioned in response to Colin, integrating parts of that in the RebootlessInstaller are already in the ROADMAP. But I don't think that that level of feature parity with existing installations should be required for feature acceptance in f12 (given 'experimental' tagging of the feature). > 2. Imagine after the installation you switch rebootless to the new > system and install a kmod. But you are still running the kernel > from the installation medium and kmods get installed for the > running kernel, which not necessarily needs to be the one that > was installed. As with a current LiveOS installation, the installation media kernel is the running kernel. (unless the f11 installer already allows you to trigger a chrooted yum update as part of install). So yes, if there is a kernel update available - and I'll grant, it is the rule for installations and not the exception - you will need to reboot to switch to that kernel (at least until the whole ksplice technology rolls into town...) peace... -dmc From walters at verbum.org Tue Jul 14 15:19:09 2009 From: walters at verbum.org (Colin Walters) Date: Tue, 14 Jul 2009 11:19:09 -0400 Subject: Feature proposal: Rebootless Installer In-Reply-To: <1247583885.15109.112.camel@localhost> References: <4A5C3C12.9050009@filteredperception.org> <4A5C9185.5010800@filteredperception.org> <1247583885.15109.112.camel@localhost> Message-ID: On Tue, Jul 14, 2009 at 11:04 AM, Christoph Wickert wrote: > Am Dienstag, den 14.07.2009, 08:09 -0600 schrieb Douglas McClendon: >> Colin Walters wrote: >> > Another thing to keep in mind that immediately post-installation there >> > are going to be updates, which will at a minimum need desktop reset >> > (fast reboot experience), or more likely system restart. >> >> I don't exactly get this. ?I might understand some negligible things. >> But historically I've often done >> >> -normal install, reboot >> >> -booted, logged in using everying, then a massive yum update, then I'd >> wait till it was absolutely convenient to logout of the desktop or reboot > > You wouldn't need no yum update if you enabled the updates repo during > install. It's a single click. There's no such step in the live install (right?). Now, it would likely make sense to have such a mechanism, but it would need design. I forget offhand too how the PackageKit updater works in the live image (do we disable it by default?). It's super confusing to discuss installation when we have two wildly different forms of it; in general I think if we're looking at improving user experience the right things to focus on are preupgrade and the live image. From dpierce at redhat.com Tue Jul 14 15:23:20 2009 From: dpierce at redhat.com (Darryl L. Pierce) Date: Tue, 14 Jul 2009 11:23:20 -0400 Subject: Problem with ruby package with binary content... Message-ID: <20090714152320.GB3432@mcpierce-laptop.rdu.redhat.com> This question is related to: https://bugzilla.redhat.com/show_bug.cgi?id=3D505589 When I remove the strip line, then the build process fails with the complaint: Found '/home/mcpierce/Packaging/rpms/BUILDROOT/rubygem-RedCloth-4.1.9-5.fc12.x86_= 64' in installed files; aborting I'm not sure what's wrong here. The %install portion of my spec file is as follows: ---8<[snip]--- rm -rf %{buildroot} install -d -m0755 %{buildroot}%{gemdir} install -d -m0755 %{buildroot}%{ruby_sitelib} install -d -m0755 %{buildroot}%{ruby_sitearch} install -d -m0755 %{buildroot}%{_bindir} gem install --local --install-dir %{buildroot}%{gemdir} \ --force -V --rdoc %{SOURCE0} cp -a %{buildroot}%{gemdir}/bin/* %{buildroot}%{_bindir} mv %{extensionddir}%{gemlibname} %{buildroot}%{ruby_sitearch}/%{gemlibname} rm -rf %{extensionddir} # strip %{buildroot}%{ruby_sitearch}/%{gemlibname} rm %{installroot}/lib/%{gemlibname} cp %{installroot}/lib/redcloth.rb %{buildroot}%{ruby_sitelib}/redcloth.rb rm -rf %{buildroot}%{gemdir}/bin find %{buildroot}%{geminstdir}/bin -type f | xargs chmod a+x find %{buildroot}%{geminstdir} -name "*.rb" | xargs chmod a+x find %{buildroot}%{geminstdir} -type f -name \*.rb | xargs chmod 0644 find %{buildroot}%{geminstdir} -type f -name \*.rb | \ xargs grep -l "^#!%{_bindir}/env" $file | xargs chmod 0755 rm %{installroot}/.require_paths ---8<[snip]--- Any ideas? -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Virtual Machine Management - http://www.ovirt.org/ Is fearr Gaeilge bhriste n? B?arla cliste. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From christoph.wickert at googlemail.com Tue Jul 14 15:23:29 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Tue, 14 Jul 2009 17:23:29 +0200 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C993B.2070600@fedoraproject.org> References: <4A5C3C12.9050009@filteredperception.org> <1247578341.8875.8.camel@choeger6> <4A5C8987.9090908@fedoraproject.org> <1247582292.15109.60.camel@localhost> <4A5C993B.2070600@fedoraproject.org> Message-ID: <1247585009.15109.137.camel@localhost> Am Dienstag, den 14.07.2009, 20:12 +0530 schrieb Rahul Sundaram: > On 07/14/2009 08:08 PM, Christoph Wickert wrote: > > Am Dienstag, den 14.07.2009, 19:05 +0530 schrieb Rahul Sundaram: > >> On 07/14/2009 07:02 PM, Christoph H?ger wrote: > >>> Hi, > >>> > >>> although (as others pointed out) a reboot may be necessary one way or > >>> the other, my opinion would be: Why not? > >>> > >>> Currently you are *forced* to reboot which now seems not to be a must > >>> have. > >> > >> Nobody is forced. You must be misremembering things. > > > > Obviously you are the one misremembering things: > > http://cwickert.fedorapeople.org/temp/anaconda-last-screen.png > > We are talking about a live cd installation, yes? Are we? If I understand the proposal correctly it also includes rebootless switching from the installation DVD into your newly installed system. > You can close the installer then. But why would I want that? If somebody installs Fedora, I'm sure he wants to actually use it and not the slow livecd. So the rebootless feature only makes sense if one can switch rebootless to the installed system - from the livecd as well as from the installation DVD. Regards, Christoph From dmc.fedora at filteredperception.org Tue Jul 14 15:27:08 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 14 Jul 2009 09:27:08 -0600 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5CA22A.2030307@filteredperception.org> References: <4A5C3C12.9050009@filteredperception.org> <4A5C9185.5010800@filteredperception.org> <1247583885.15109.112.camel@localhost> <4A5CA22A.2030307@filteredperception.org> Message-ID: <4A5CA3CC.7080503@filteredperception.org> Douglas McClendon wrote: > Christoph Wickert wrote: >> Am Dienstag, den 14.07.2009, 08:09 -0600 schrieb Douglas McClendon: >> 2. Imagine after the installation you switch rebootless to the new >> system and install a kmod. But you are still running the kernel >> from the installation medium and kmods get installed for the >> running kernel, which not necessarily needs to be the one that >> was installed. > > As with a current LiveOS installation, the installation media kernel is > the running kernel. (unless the f11 installer already allows you to > trigger a chrooted yum update as part of install). Ok, I'll show my good fedora developer maturity and call it a 'night' now that I'm starting to get sloppy. That should have been worded- As with a current LiveOS installation, the installation media kernel is the running kernel. Even if the f11 installer already allows you to trigger a chrooted yum update as part of the install, you won't be running the updated kernel until after a reboot. ... Same as RebootlessInstaller ... until ksplice ... Thanks everyone for the vetting so far. I'm sure by the time I check back in, I'll have a lot of catching up to do, but that my installer will be all the better in the long run for it. peace... -dmc From dmc.fedora at filteredperception.org Tue Jul 14 15:30:06 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 14 Jul 2009 09:30:06 -0600 Subject: Feature proposal: Rebootless Installer In-Reply-To: <1247585009.15109.137.camel@localhost> References: <4A5C3C12.9050009@filteredperception.org> <1247578341.8875.8.camel@choeger6> <4A5C8987.9090908@fedoraproject.org> <1247582292.15109.60.camel@localhost> <4A5C993B.2070600@fedoraproject.org> <1247585009.15109.137.camel@localhost> Message-ID: <4A5CA47E.2030308@filteredperception.org> Christoph Wickert wrote: > Am Dienstag, den 14.07.2009, 20:12 +0530 schrieb Rahul Sundaram: >> On 07/14/2009 08:08 PM, Christoph Wickert wrote: >>> Am Dienstag, den 14.07.2009, 19:05 +0530 schrieb Rahul Sundaram: >>>> On 07/14/2009 07:02 PM, Christoph H?ger wrote: >>>>> Hi, >>>>> >>>>> although (as others pointed out) a reboot may be necessary one way or >>>>> the other, my opinion would be: Why not? >>>>> >>>>> Currently you are *forced* to reboot which now seems not to be a must >>>>> have. >>>> Nobody is forced. You must be misremembering things. >>> Obviously you are the one misremembering things: >>> http://cwickert.fedorapeople.org/temp/anaconda-last-screen.png >> We are talking about a live cd installation, yes? > > Are we? If I understand the proposal correctly it also includes > rebootless switching from the installation DVD into your newly installed > system. Ok, one more simple reply- No, this is *just* a LiveOS thing, that has nothing to do with the traditional^2 (non-live) DVD installer. Though one could of course imagine architecting something like that, but that _would_ boil down to more or less the same thing as opensuse appears to be doing with kexec. peace and g'nite... -dmc > >> You can close the installer then. > > But why would I want that? If somebody installs Fedora, I'm sure he > wants to actually use it and not the slow livecd. So the rebootless > feature only makes sense if one can switch rebootless to the installed > system - from the livecd as well as from the installation DVD. > > Regards, > Christoph > From mschwendt at gmail.com Tue Jul 14 15:36:02 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 14 Jul 2009 17:36:02 +0200 Subject: NVR bugs in rawhide In-Reply-To: <4A5C8FCE.40905@freenet.de> References: <4A5C3FF9.3010903@redhat.com> <20090714111532.4b688163@faldor> <4A5C7848.20608@redhat.com> <20090714144853.19816cfc@faldor> <1247575691.3164.2.camel@politzer.theorphys.helsinki.fi> <20090714153737.785463f7@faldor> <4A5C8FCE.40905@freenet.de> Message-ID: <20090714173602.2fa06b11@faldor> On Tue, 14 Jul 2009 16:01:50 +0200, Ralf wrote: > > You don't need to drop %dist for koji build inheritance to work. > > > > It just looks much cleaner to inherit foo-1.0-1.noarch.rpm for all > > newer targets > > IFF "current rpm" is sufficiently compatible to the antique version of > rpm a package has been built on. > > If this doesn't apply you don't get anywhere. Not _with_ %dist either. > > No. Particulary for noarch data packages, using %dist bears an > > additional risk. Because it becomes possible to tag a package on > > multiple branches and break inheritance by building for more than > > the oldest branch. > To me, this is not a risk, but a valuable feature. The packager is free to decide whether and when to do this either with or without %dist. > => I agree with Jussi. Allowing people not to use %dist is not helpful. > It's a booby trap which certainly will hit some day. %dist is a trap itself - packagers run into it regularly, e.g. when adding Obsoletes and versioned dependencies, when doing trial-and-error fixing of old branches (without paying attention to the recommendations in the guidelines), when committing and tagging after a server-side update of the "branches" file. From sundaram at fedoraproject.org Tue Jul 14 15:30:56 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 14 Jul 2009 21:00:56 +0530 Subject: Feature proposal: Rebootless Installer In-Reply-To: <1247585009.15109.137.camel@localhost> References: <4A5C3C12.9050009@filteredperception.org> <1247578341.8875.8.camel@choeger6> <4A5C8987.9090908@fedoraproject.org> <1247582292.15109.60.camel@localhost> <4A5C993B.2070600@fedoraproject.org> <1247585009.15109.137.camel@localhost> Message-ID: <4A5CA4B0.7050908@fedoraproject.org> On 07/14/2009 08:53 PM, Christoph Wickert wrote: > Are we? If I understand the proposal correctly it also includes > rebootless switching from the installation DVD into your newly installed > system. You might want to read the proposal again. It specifically talks about only Live installation. http://fedoraproject.org/wiki/Features/RebootlessInstaller There is nothing in it about a regular installation. >> You can close the installer then. > > But why would I want that? If somebody installs Fedora, I'm sure he > wants to actually use it and not the slow livecd. I have continued using the Live CD after a installation because it is sometimes convenient to do so. It is not slow since I usually use a Live USB. The flexibility is quite useful. It would be wonderful to get the rebootless feature added as well. Rahul From Fedora at FamilleCollet.com Tue Jul 14 15:33:45 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Tue, 14 Jul 2009 17:33:45 +0200 Subject: Heads UP - PHP 5.3.0 in rawhide with new ABI/API. In-Reply-To: <4A5B660D.3040205@FamilleCollet.com> References: <4A5A2017.3090409@FamilleCollet.com> <4A5B660D.3040205@FamilleCollet.com> Message-ID: <4A5CA559.2080307@FamilleCollet.com> Le 13/07/2009 18:51, Remi Collet a ?crit : **** More extension package rebuild: syck https://bugzilla.redhat.com/show_bug.cgi?id=511018 cups-php https://bugzilla.redhat.com/show_bug.cgi?id=511106 add PHP ABI check use php_extdir add php configuration file (/etc/php.d/cups.ini) php-suhosin uuid-php https://bugzilla.redhat.com/show_bug.cgi?id=511115 add PHP ABI check use php_extdir add php configuration file (/etc/php.d/uuid.ini) syck https://bugzilla.redhat.com/show_bug.cgi?id=511018 php-pear-Net-DNS remove php-mhash dependency php-pear-Crypt-CHAP remove php-mhash dependency php-pear-Auth-RADIUS remove php-mhash dependency *** Still Broken sipwitch-php-swig https://bugzilla.redhat.com/show_bug.cgi?id=511123 php-eaccelerator (upstream working on it) https://bugzilla.redhat.com/show_bug.cgi?id=511127 All broken deps fixed, I think / hope Remi From mschwendt at gmail.com Tue Jul 14 15:41:02 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 14 Jul 2009 17:41:02 +0200 Subject: epel-release in Fedora repos? (was: Re: NVR bugs in rawhide) In-Reply-To: <200907141729.34196.ville.skytta@iki.fi> References: <4A5C3FF9.3010903@redhat.com> <200907141729.34196.ville.skytta@iki.fi> Message-ID: <20090714174102.2b8a744c@faldor> On Tue, 14 Jul 2009 17:29:33 +0300, Ville wrote: > On Tuesday 14 July 2009, Daniel Mach wrote: > > > epel-release-6-2.src.rpm > > Why is the epel-release package shipped in Fedora repos? Because it comes with a valid "devel" tree in cvs and apparently was (re)built by releng automatically. "devel" is for Fedora. That tree ought to have been deleted after importing the pkg for EPEL. From choeger at cs.tu-berlin.de Tue Jul 14 15:37:09 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Tue, 14 Jul 2009 17:37:09 +0200 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C9D76.2080201@filteredperception.org> References: <4A5C3C12.9050009@filteredperception.org> <1247578341.8875.8.camel@choeger6> <4A5C8987.9090908@fedoraproject.org> <1247582292.15109.60.camel@localhost> <4A5C993B.2070600@fedoraproject.org> <1247583227.8875.14.camel@choeger6> <4A5C9D76.2080201@filteredperception.org> Message-ID: <1247585829.8875.15.camel@choeger6> Am Dienstag, den 14.07.2009, 09:00 -0600 schrieb Douglas McClendon: > Christoph H?ger wrote: > >> We are talking about a live cd installation, yes? You can close the > >> installer then. > > > > We were talking about anaconda. And I still don't know a sane (aka "no > > manual chroot") way to go from livecd into the fresh installed > > environment. > > If you look at the feature page and watch 18 minutes of youtube videos, > and/or look at my code, I think you'll have to admit there is 'a way' to > do it. I certainly won't be offended by the label 'insane' however, > unless of course you find technical problems with my implementation, in > which case, I still won't mind the label, I'll just go fix em. That was, of course, meant: Except for feature proposals discussed here ;) -------------- 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 christoph.wickert at googlemail.com Tue Jul 14 15:37:10 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Tue, 14 Jul 2009 17:37:10 +0200 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5CA3CC.7080503@filteredperception.org> References: <4A5C3C12.9050009@filteredperception.org> <4A5C9185.5010800@filteredperception.org> <1247583885.15109.112.camel@localhost> <4A5CA22A.2030307@filteredperception.org> <4A5CA3CC.7080503@filteredperception.org> Message-ID: <1247585830.15109.151.camel@localhost> Am Dienstag, den 14.07.2009, 09:27 -0600 schrieb Douglas McClendon: > Douglas McClendon wrote: > > Christoph Wickert wrote: > >> Am Dienstag, den 14.07.2009, 08:09 -0600 schrieb Douglas McClendon: > >> 2. Imagine after the installation you switch rebootless to the new > >> system and install a kmod. But you are still running the kernel > >> from the installation medium and kmods get installed for the > >> running kernel, which not necessarily needs to be the one that > >> was installed. > > > > As with a current LiveOS installation, the installation media kernel is > > the running kernel. (unless the f11 installer already allows you to > > trigger a chrooted yum update as part of install). > > Ok, I'll show my good fedora developer maturity and call it a 'night' > now that I'm starting to get sloppy. That should have been worded- > > As with a current LiveOS installation, the installation media kernel is > the running kernel. Even if the f11 installer already allows you to > trigger a chrooted yum update as part of the install, you won't be > running the updated kernel until after a reboot. There is no chrooted yum update but the updated packages get installed *instead* of the old ones from the installation media. > ... Same as RebootlessInstaller ... until ksplice ... > > Thanks everyone for the vetting so far. Thanks a lot for the proposal and the work you've put into it. I'm sure we all are interested in it, but many of use are just a little skeptical if it really works out. Please don't let this skepticism scare you. :) Regards, Christoph From mlichvar at redhat.com Tue Jul 14 15:46:38 2009 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Tue, 14 Jul 2009 17:46:38 +0200 Subject: readline update? In-Reply-To: <20090707132430.GD19965@localhost> References: <20090703102747.GA32668@localhost> <20090703215521.GD13203@nostromo.devel.redhat.com> <20090707132430.GD19965@localhost> Message-ID: <20090714154638.GA15785@localhost> On Tue, Jul 07, 2009 at 03:24:30PM +0200, Miroslav Lichvar wrote: > Review requst for compat-readline5: > https://bugzilla.redhat.com/show_bug.cgi?id=510022 > > After the package is accepted, I'll start patching the packages > (except gnu-smalltalk and kdeedu) to build correctly with the compat > package. It turned out that I can no longer commit to other packages, so I'll file bugs with patches instead. However, it seems that more of the packages I posted in the original mail are not GPLv2. calc (can be relicensed to GPLv3?) cgdb (GPLv2+?) gnubg (GPLv3?) grass (GPLv2+?) gnuplot (not compatible with any GPL?) ktechlab (GPLv2+?) Can someone confirm this? Thanks, -- Miroslav Lichvar From rjones at redhat.com Tue Jul 14 15:50:06 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 14 Jul 2009 16:50:06 +0100 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5CA3CC.7080503@filteredperception.org> References: <4A5C3C12.9050009@filteredperception.org> <4A5C9185.5010800@filteredperception.org> <1247583885.15109.112.camel@localhost> <4A5CA22A.2030307@filteredperception.org> <4A5CA3CC.7080503@filteredperception.org> Message-ID: <20090714155006.GA30757@amd.home.annexia.org> On Tue, Jul 14, 2009 at 09:27:08AM -0600, Douglas McClendon wrote: > As with a current LiveOS installation, the installation media kernel is > the running kernel. Even if the f11 installer already allows you to > trigger a chrooted yum update as part of the install, you won't be > running the updated kernel until after a reboot. Is it the case that the installation kernel is always UP, whereas the real kernel would probably be SMP nowadays? > ... Same as RebootlessInstaller ... until ksplice ... I don't think ksplice changes things -- it seems to only work for very minor kernel patches. For example, any change to the layout of a kernel structure would appear to be incompatible with ksplice. Thus it seems highly unlikely it'll ever work in its current form for arbitrary kernel revisions. Before you use ksplice-create on a patch, you should confirm that the desired source code change does not make any semantic changes to kernel data structures--that is, changes that would require existing instances of kernel data structures to be transformed (e.g., a patch that adds a field to a global data structure would require the existing data structures to change). If you use Ksplice on a patch that changes data structure semantics, Ksplice will not detect the problem and you could experience kernel problems as a result. from: http://www.ksplice.com/doc/ksplice-create Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.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 rc040203 at freenet.de Tue Jul 14 15:54:10 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 14 Jul 2009 17:54:10 +0200 Subject: NVR bugs in rawhide In-Reply-To: <20090714173602.2fa06b11@faldor> References: <4A5C3FF9.3010903@redhat.com> <20090714111532.4b688163@faldor> <4A5C7848.20608@redhat.com> <20090714144853.19816cfc@faldor> <1247575691.3164.2.camel@politzer.theorphys.helsinki.fi> <20090714153737.785463f7@faldor> <4A5C8FCE.40905@freenet.de> <20090714173602.2fa06b11@faldor> Message-ID: <4A5CAA22.3090701@freenet.de> Michael Schwendt wrote: > On Tue, 14 Jul 2009 16:01:50 +0200, Ralf wrote: > >>> You don't need to drop %dist for koji build inheritance to work. >>> >>> It just looks much cleaner to inherit foo-1.0-1.noarch.rpm for all >>> newer targets >> IFF "current rpm" is sufficiently compatible to the antique version of >> rpm a package has been built on. >> >> If this doesn't apply you don't get anywhere. > > Not _with_ %dist either. Of cause it would help. A package's release tag would very verbosely tell you that a package is outdated. >>> No. Particulary for noarch data packages, using %dist bears an >>> additional risk. Because it becomes possible to tag a package on >>> multiple branches and break inheritance by building for more than >>> the oldest branch. >> To me, this is not a risk, but a valuable feature. > > The packager is free to decide whether and when to do this either with or > without %dist. Yes, that's the status quo, probably because certain Fedora and Red Hat key people refuse to keep things simple and straight, but prefer to what I consider to be "outsmarting themselves" by making the corner cases the norm. IMO, that's simply silly of these people. >> => I agree with Jussi. Allowing people not to use %dist is not helpful. >> It's a booby trap which certainly will hit some day. > > %dist is a trap itself - packagers run into it regularly, e.g. when > adding Obsoletes and versioned dependencies, when doing trial-and-error > fixing of old branches (without paying attention to the recommendations in > the guidelines), when committing and tagging after a server-side update of > the "branches" file. Quite easy to overcome: always use %?dist. It's the cases when people add/remove %?dist, which are problematic. Ralf From a.badger at gmail.com Tue Jul 14 16:02:20 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 14 Jul 2009 09:02:20 -0700 Subject: beagle In-Reply-To: <20090714131658.0d8787a7@faldor> References: <20090625114833.4b5f2895@noname.noname> <20090714131658.0d8787a7@faldor> Message-ID: <4A5CAC0C.4010108@gmail.com> On 07/14/2009 04:16 AM, Michael Schwendt wrote: > On Thu, 25 Jun 2009 11:48:33 +0200, Michael wrote: > >> * Delivery to the following recipient failed permanently: >> >> beagle-owner AT fedoraproject DOT org >> >> Recipient address rejected: >> User unknown in local recipient table (state 14). >> >> * https://admin.fedoraproject.org/pkgdb/packages/name shows more than a >> dozen people on watchcommit+commit, but no package owner. It's an orphan. >> >> * https://admin.fedoraproject.org/pkgdb/packages/bugs shows more than a >> dozen open tickets, but nobody is subscribed to watchbugzilla. >> >> * "yum list beagle" shows beagle-0.3.9-6.fc11 in "fedora". > > There is still no beagle-owner for this package. > So, it looks like the desktop team isn't interested in picking up beagle (and they're most of the people in the commit/watchcommit) for the package. If no one else is willing to take ownership, I think we should block the package for rawhide and list it as retired for not having someone interested in working on it. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From drago01 at gmail.com Tue Jul 14 16:07:46 2009 From: drago01 at gmail.com (drago01) Date: Tue, 14 Jul 2009 18:07:46 +0200 Subject: beagle In-Reply-To: <4A5CAC0C.4010108@gmail.com> References: <20090625114833.4b5f2895@noname.noname> <20090714131658.0d8787a7@faldor> <4A5CAC0C.4010108@gmail.com> Message-ID: On Tue, Jul 14, 2009 at 6:02 PM, Toshio Kuratomi wrote: > On 07/14/2009 04:16 AM, Michael Schwendt wrote: >> On Thu, 25 Jun 2009 11:48:33 +0200, Michael wrote: >> >>> * Delivery to the following recipient failed permanently: >>> >>> ? ? ?beagle-owner AT fedoraproject DOT org >>> >>> ? ? ?Recipient address rejected: >>> ? ? ?User unknown in local recipient table (state 14). >>> >>> * https://admin.fedoraproject.org/pkgdb/packages/name ?shows more than a >>> dozen people on watchcommit+commit, but no package owner. It's an orphan. >>> >>> * https://admin.fedoraproject.org/pkgdb/packages/bugs ?shows more than a >>> dozen open tickets, but nobody is subscribed to watchbugzilla. >>> >>> * "yum list beagle" shows beagle-0.3.9-6.fc11 in "fedora". >> >> There is still no beagle-owner for this package. >> > So, it looks like the desktop team isn't interested in picking up beagle > (and they're most of the people in the commit/watchcommit) for the > package. ?If no one else is willing to take ownership, I think we should > block the package for rawhide and list it as retired for not having > someone interested in working on it. It does not even build on rawhide right now (epiphany related breakage). I dropped it due to lack of time (which is worse rather than better now) but nobody responded to my mail where I was searching for a new maintainer. From mschwendt at gmail.com Tue Jul 14 16:14:10 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 14 Jul 2009 18:14:10 +0200 Subject: NVR bugs in rawhide In-Reply-To: <4A5CAA22.3090701@freenet.de> References: <4A5C3FF9.3010903@redhat.com> <20090714111532.4b688163@faldor> <4A5C7848.20608@redhat.com> <20090714144853.19816cfc@faldor> <1247575691.3164.2.camel@politzer.theorphys.helsinki.fi> <20090714153737.785463f7@faldor> <4A5C8FCE.40905@freenet.de> <20090714173602.2fa06b11@faldor> <4A5CAA22.3090701@freenet.de> Message-ID: <20090714181410.2d2ff8f4@faldor> On Tue, 14 Jul 2009 17:54:10 +0200, Ralf wrote: > Michael Schwendt wrote: > > On Tue, 14 Jul 2009 16:01:50 +0200, Ralf wrote: > > > >>> You don't need to drop %dist for koji build inheritance to work. > >>> > >>> It just looks much cleaner to inherit foo-1.0-1.noarch.rpm for all > >>> newer targets > >> IFF "current rpm" is sufficiently compatible to the antique version of > >> rpm a package has been built on. > >> > >> If this doesn't apply you don't get anywhere. > > > > Not _with_ %dist either. > Of cause it would help. A package's release tag would very verbosely > tell you that a package is outdated. And still it would fail if RPM were changed [the way you describe] while %dist stayed the same. %dist doesn't reflect at all whether RPM changes its file format near the beginning of a Fedora devel cycle. > >> => I agree with Jussi. Allowing people not to use %dist is not helpful. > >> It's a booby trap which certainly will hit some day. > > > > %dist is a trap itself - packagers run into it regularly, e.g. when > > adding Obsoletes and versioned dependencies, when doing trial-and-error > > fixing of old branches (without paying attention to the recommendations in > > the guidelines), when committing and tagging after a server-side update of > > the "branches" file. > Quite easy to overcome: always use %?dist. Doesn't help much. Packager still needs to bump all branches [correctly] to recover. > It's the cases when people add/remove %?dist, which are problematic. Going in circles won't be of any use in this thread. Using %dist adds complications, too. Or else packagers would not run into some of the pitfalls I've pointed out. From jussilehtola at fedoraproject.org Tue Jul 14 16:08:49 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Tue, 14 Jul 2009 19:08:49 +0300 Subject: NVR bugs in rawhide In-Reply-To: <20090714172325.4f54113f@faldor> References: <4A5C3FF9.3010903@redhat.com> <20090714111532.4b688163@faldor> <4A5C7848.20608@redhat.com> <20090714144853.19816cfc@faldor> <1247575691.3164.2.camel@politzer.theorphys.helsinki.fi> <20090714153737.785463f7@faldor> <1247579666.3164.5.camel@politzer.theorphys.helsinki.fi> <20090714172325.4f54113f@faldor> Message-ID: <1247587729.3164.12.camel@politzer.theorphys.helsinki.fi> On Tue, 2009-07-14 at 17:23 +0200, Michael Schwendt wrote: > > Say I've built foo-1-1 in rawhide a year ago and thus the package is > > available now in F-10 and F-11. How do I update to foo-2-1 in both > > distros? > > Whether with %dist or not, doesn't make a difference. You commit the > upgrade to the branch that previously targeted rawhide. F-10 in your > example. And it automatically ends up in F-11? I can't tag and build for F-11 if the tag with same EVR already exists in F-10. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From nushio at fedoraproject.org Tue Jul 14 16:09:58 2009 From: nushio at fedoraproject.org (Juan Rodriguez) Date: Tue, 14 Jul 2009 11:09:58 -0500 Subject: beagle In-Reply-To: References: <20090625114833.4b5f2895@noname.noname> <20090714131658.0d8787a7@faldor> <4A5CAC0C.4010108@gmail.com> Message-ID: On Tue, Jul 14, 2009 at 11:07 AM, drago01 wrote: > On Tue, Jul 14, 2009 at 6:02 PM, Toshio Kuratomi > wrote: > > On 07/14/2009 04:16 AM, Michael Schwendt wrote: > >> On Thu, 25 Jun 2009 11:48:33 +0200, Michael wrote: > >> > >>> * Delivery to the following recipient failed permanently: > >>> > >>> beagle-owner AT fedoraproject DOT org > >>> > >>> Recipient address rejected: > >>> User unknown in local recipient table (state 14). > >>> > >>> * https://admin.fedoraproject.org/pkgdb/packages/name shows more than > a > >>> dozen people on watchcommit+commit, but no package owner. It's an > orphan. > >>> > >>> * https://admin.fedoraproject.org/pkgdb/packages/bugs shows more than > a > >>> dozen open tickets, but nobody is subscribed to watchbugzilla. > >>> > >>> * "yum list beagle" shows beagle-0.3.9-6.fc11 in "fedora". > >> > >> There is still no beagle-owner for this package. > >> > > So, it looks like the desktop team isn't interested in picking up beagle > > (and they're most of the people in the commit/watchcommit) for the > > package. If no one else is willing to take ownership, I think we should > > block the package for rawhide and list it as retired for not having > > someone interested in working on it. > > It does not even build on rawhide right now (epiphany related breakage). > > I dropped it due to lack of time (which is worse rather than better > now) but nobody responded to my mail where I was searching for a new > maintainer. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > As a beagle user, I'd like to help co-maintain it (Or maintain it if noone else is interested), What would I have to do? -- Ing. Juan M. Rodriguez Moreno Desarrollador de Sistemas Abiertos Sitio: http://proyectofedora.org/mexico -------------- next part -------------- An HTML attachment was scrubbed... URL: From drago01 at gmail.com Tue Jul 14 16:12:49 2009 From: drago01 at gmail.com (drago01) Date: Tue, 14 Jul 2009 18:12:49 +0200 Subject: beagle In-Reply-To: References: <20090625114833.4b5f2895@noname.noname> <20090714131658.0d8787a7@faldor> <4A5CAC0C.4010108@gmail.com> Message-ID: On Tue, Jul 14, 2009 at 6:09 PM, Juan Rodriguez wrote: > > > On Tue, Jul 14, 2009 at 11:07 AM, drago01 wrote: >> >> On Tue, Jul 14, 2009 at 6:02 PM, Toshio Kuratomi >> wrote: >> > On 07/14/2009 04:16 AM, Michael Schwendt wrote: >> >> On Thu, 25 Jun 2009 11:48:33 +0200, Michael wrote: >> >> >> >>> * Delivery to the following recipient failed permanently: >> >>> >> >>> ? ? ?beagle-owner AT fedoraproject DOT org >> >>> >> >>> ? ? ?Recipient address rejected: >> >>> ? ? ?User unknown in local recipient table (state 14). >> >>> >> >>> * https://admin.fedoraproject.org/pkgdb/packages/name ?shows more than >> >>> a >> >>> dozen people on watchcommit+commit, but no package owner. It's an >> >>> orphan. >> >>> >> >>> * https://admin.fedoraproject.org/pkgdb/packages/bugs ?shows more than >> >>> a >> >>> dozen open tickets, but nobody is subscribed to watchbugzilla. >> >>> >> >>> * "yum list beagle" shows beagle-0.3.9-6.fc11 in "fedora". >> >> >> >> There is still no beagle-owner for this package. >> >> >> > So, it looks like the desktop team isn't interested in picking up beagle >> > (and they're most of the people in the commit/watchcommit) for the >> > package. ?If no one else is willing to take ownership, I think we should >> > block the package for rawhide and list it as retired for not having >> > someone interested in working on it. >> >> It does not even build on rawhide right now (epiphany related breakage). >> >> I dropped it due to lack of time (which is worse rather than better >> now) but nobody responded to my mail where I was searching for a new >> maintainer. >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list > > As a beagle user, I'd like to help co-maintain it (Or maintain it if noone > else is interested), > What would I have to do? Are you already sponsored? If yes just take it in pkgdb (it is already orphaned) From mschwendt at gmail.com Tue Jul 14 16:39:43 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 14 Jul 2009 18:39:43 +0200 Subject: NVR bugs in rawhide In-Reply-To: <1247587729.3164.12.camel@politzer.theorphys.helsinki.fi> References: <4A5C3FF9.3010903@redhat.com> <20090714111532.4b688163@faldor> <4A5C7848.20608@redhat.com> <20090714144853.19816cfc@faldor> <1247575691.3164.2.camel@politzer.theorphys.helsinki.fi> <20090714153737.785463f7@faldor> <1247579666.3164.5.camel@politzer.theorphys.helsinki.fi> <20090714172325.4f54113f@faldor> <1247587729.3164.12.camel@politzer.theorphys.helsinki.fi> Message-ID: <20090714183943.3d2e8397@faldor> On Tue, 14 Jul 2009 19:08:49 +0300, Jussi wrote: > On Tue, 2009-07-14 at 17:23 +0200, Michael Schwendt wrote: > > > Say I've built foo-1-1 in rawhide a year ago and thus the package is > > > available now in F-10 and F-11. How do I update to foo-2-1 in both > > > distros? > > > > Whether with %dist or not, doesn't make a difference. You commit the > > upgrade to the branch that previously targeted rawhide. F-10 in your > > example. > > And it automatically ends up in F-11? With koji inheritance, yes. > I can't tag and build for F-11 if > the tag with same EVR already exists in F-10. We're not talking about the same thing. Or to put it differently, you want to prove something to me which I don't find relevant in this discussion. From jkeating at redhat.com Tue Jul 14 16:40:19 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 14 Jul 2009 09:40:19 -0700 Subject: Feature proposal: Rebootless Installer In-Reply-To: References: <4A5C3C12.9050009@filteredperception.org> <4A5C9185.5010800@filteredperception.org> <1247583885.15109.112.camel@localhost> Message-ID: <1247589619.3073.1161.camel@localhost.localdomain> On Tue, 2009-07-14 at 11:19 -0400, Colin Walters wrote: > There's no such step in the live install (right?). Now, it would > likely make sense to have such a mechanism, but it would need design. > I forget offhand too how the PackageKit updater works in the live > image (do we disable it by default?). With the Anaconda live installer, it's the raw unmodified live filesystem that is "copied" to the newly partitioned disk(s). Ergo any rpm updating you do on the LiveOS before you start the installer will be lost. It appears that Doglas' installer uses the in use LiveOS so that the changes you make while running the LiveOS before starting the install will be carried over into the install. That in itself seems interesting enough to explore and see if we can't get the same functionality, to some extent into Anaconda. As for rebootless, that's interesting too. I'm glad you were able to demo the technology within your installer, but I'd worry about the duplication of effort/code to have yet another program that is designed to discover disks, partition them appropriately for an install, copy content, then install a boot loader. There is a lot of logic code in Anaconda to get the partitioning correct for an installation, even if the backend code uses system level libraries and tools to accomplish the partitioning. Ditto boot loaders and kernel setup. If we as a project find rebootless installation useful then we should find a way to integrate it with our existing installer and code set which already carries all the logic necessary to pull it off, from years of experience and bug reports. I think your work is great and useful 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: 197 bytes Desc: This is a digitally signed message part URL: From drago01 at gmail.com Tue Jul 14 16:43:11 2009 From: drago01 at gmail.com (drago01) Date: Tue, 14 Jul 2009 18:43:11 +0200 Subject: beagle In-Reply-To: References: <20090625114833.4b5f2895@noname.noname> <20090714131658.0d8787a7@faldor> <4A5CAC0C.4010108@gmail.com> Message-ID: On Tue, Jul 14, 2009 at 6:12 PM, drago01 wrote: > On Tue, Jul 14, 2009 at 6:09 PM, Juan Rodriguez wrote: >> >> >> On Tue, Jul 14, 2009 at 11:07 AM, drago01 wrote: >>> >>> On Tue, Jul 14, 2009 at 6:02 PM, Toshio Kuratomi >>> wrote: >>> > On 07/14/2009 04:16 AM, Michael Schwendt wrote: >>> >> On Thu, 25 Jun 2009 11:48:33 +0200, Michael wrote: >>> >> >>> >>> * Delivery to the following recipient failed permanently: >>> >>> >>> >>> ? ? ?beagle-owner AT fedoraproject DOT org >>> >>> >>> >>> ? ? ?Recipient address rejected: >>> >>> ? ? ?User unknown in local recipient table (state 14). >>> >>> >>> >>> * https://admin.fedoraproject.org/pkgdb/packages/name ?shows more than >>> >>> a >>> >>> dozen people on watchcommit+commit, but no package owner. It's an >>> >>> orphan. >>> >>> >>> >>> * https://admin.fedoraproject.org/pkgdb/packages/bugs ?shows more than >>> >>> a >>> >>> dozen open tickets, but nobody is subscribed to watchbugzilla. >>> >>> >>> >>> * "yum list beagle" shows beagle-0.3.9-6.fc11 in "fedora". >>> >> >>> >> There is still no beagle-owner for this package. >>> >> >>> > So, it looks like the desktop team isn't interested in picking up beagle >>> > (and they're most of the people in the commit/watchcommit) for the >>> > package. ?If no one else is willing to take ownership, I think we should >>> > block the package for rawhide and list it as retired for not having >>> > someone interested in working on it. >>> >>> It does not even build on rawhide right now (epiphany related breakage). >>> >>> I dropped it due to lack of time (which is worse rather than better >>> now) but nobody responded to my mail where I was searching for a new >>> maintainer. Juan just took ownership of beagle, so the issue (not having a maintainer) is solved now. From mtasaka at ioa.s.u-tokyo.ac.jp Tue Jul 14 16:44:59 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 15 Jul 2009 01:44:59 +0900 Subject: Problem with ruby package with binary content... In-Reply-To: <20090714152320.GB3432@mcpierce-laptop.rdu.redhat.com> References: <20090714152320.GB3432@mcpierce-laptop.rdu.redhat.com> Message-ID: <4A5CB60B.8010801@ioa.s.u-tokyo.ac.jp> Darryl L. Pierce wrote, at 07/15/2009 12:23 AM +9:00: > This question is related to: > https://bugzilla.redhat.com/show_bug.cgi?id=505589 > > When I remove the strip line, then the build process fails with the > complaint: > > Found > '/home/mcpierce/Packaging/rpms/BUILDROOT/rubygem-RedCloth-4.1.9-5.fc12.x86_= > 64' > in installed files; aborting > > I'm not sure what's wrong here. The %install portion of my spec file is > as follows: > > ---8<[snip]--- > rm -rf %{buildroot} > > install -d -m0755 %{buildroot}%{gemdir} > install -d -m0755 %{buildroot}%{ruby_sitelib} > install -d -m0755 %{buildroot}%{ruby_sitearch} > install -d -m0755 %{buildroot}%{_bindir} > > gem install --local --install-dir %{buildroot}%{gemdir} \ > --force -V --rdoc %{SOURCE0} > > cp -a %{buildroot}%{gemdir}/bin/* %{buildroot}%{_bindir} > mv %{extensionddir}%{gemlibname} > %{buildroot}%{ruby_sitearch}/%{gemlibname} > rm -rf %{extensionddir} > # strip %{buildroot}%{ruby_sitearch}/%{gemlibname} > rm %{installroot}/lib/%{gemlibname} > cp %{installroot}/lib/redcloth.rb > %{buildroot}%{ruby_sitelib}/redcloth.rb > rm -rf %{buildroot}%{gemdir}/bin > find %{buildroot}%{geminstdir}/bin -type f | xargs chmod a+x > find %{buildroot}%{geminstdir} -name "*.rb" | xargs chmod a+x > > find %{buildroot}%{geminstdir} -type f -name \*.rb | xargs chmod 0644 > > find %{buildroot}%{geminstdir} -type f -name \*.rb | \ > xargs grep -l "^#!%{_bindir}/env" $file | xargs chmod 0755 > > rm %{installroot}/.require_paths > ---8<[snip]--- > > Any ideas? This is because with your spec file gem is directly installed under %buildroot. So some C codes in the gem (usually under ext/ directory) are compiled under %buildroot and the string "%buildroot" is embedded in the built binary (with "gcc -g"). This will make /usr/lib/rpm/check-buildroot complain. The correct way is to expand (install) gem file once under %_builddir (at %prep or %build) and and copy all (under %_builddir) under %buildroot at %install like: ------------------------------------------------------------------- %prep %setup -q -c -T mkdir -p ./%{gemdir} export CONFIGURE_ARGS="--with-cflags='%{optflags}'" gem install --local --install-dir .%{gemdir} \ --force -V --rdoc %{SOURCE0} %build %install rm -rf %{buildroot} mkdir -p %{buildroot}%{gemdir} cp -a .%{gemdir}/* %{buildroot}%{gemdir} .... .... ------------------------------------------------------------------- With this debuginfo rpm will also be created correctly. Regards, Mamoru From nushio at fedoraproject.org Tue Jul 14 16:45:59 2009 From: nushio at fedoraproject.org (Juan Rodriguez) Date: Tue, 14 Jul 2009 11:45:59 -0500 Subject: beagle In-Reply-To: References: <20090625114833.4b5f2895@noname.noname> <20090714131658.0d8787a7@faldor> <4A5CAC0C.4010108@gmail.com> Message-ID: On Tue, Jul 14, 2009 at 11:43 AM, drago01 wrote: > Juan just took ownership of beagle, so the issue (not having a > maintainer) is solved now. > However, if anyone wants to co-maintain the package, feel free to do so. :) -- 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 Tue Jul 14 16:56:49 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 14 Jul 2009 09:56:49 -0700 Subject: epel-release in Fedora repos? (was: Re: NVR bugs in rawhide) In-Reply-To: <20090714174102.2b8a744c@faldor> References: <4A5C3FF9.3010903@redhat.com> <200907141729.34196.ville.skytta@iki.fi> <20090714174102.2b8a744c@faldor> Message-ID: <1247590610.3073.1165.camel@localhost.localdomain> On Tue, 2009-07-14 at 17:41 +0200, Michael Schwendt wrote: > Because it comes with a valid "devel" tree in cvs and apparently was > (re)built by releng automatically. > > "devel" is for Fedora. That tree ought to have been deleted after > importing the pkg for EPEL. releng doesn't key off of a devel/ branch alone. The package was somehow added to a Fedora collection in Koji, and thus it showed up as a valid package when I queried Koji for all the packages buildable in dist-f11. The fact that it was added to a Fedora collection in Koji /plus/ it had a real devel/ branch in CVS led to it being built. At 7000+ srpms there is no way I could evaluate each and every one for validity before submitting it for a rebuild. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Jul 14 16:59:07 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 14 Jul 2009 09:59:07 -0700 Subject: rpm %defattr question In-Reply-To: <200907141733.30646.ville.skytta@iki.fi> References: <1247356269.22031.1.camel@hawking.theorphys.helsinki.fi> <200907132207.15588.ville.skytta@iki.fi> <1247513095.3095.3.camel@localhost.localdomain> <200907141733.30646.ville.skytta@iki.fi> Message-ID: <1247590747.3073.1166.camel@localhost.localdomain> On Tue, 2009-07-14 at 17:33 +0300, Ville Skytt? wrote: > Your guess is as good as mine, but I don't know why it would need to > change. %defattr and %attr appear to use different syntax, as I tried to use the same %defattr syntax for an %attr line and RPM balked. Making them consistent would be nice. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Jul 14 16:40:37 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 14 Jul 2009 09:40:37 -0700 Subject: Purging the F12 orphans Message-ID: <1247589637.3073.1162.camel@localhost.localdomain> It's that time of the release cycle again, to purge the orphans before we get to feature freeze. Any unblocked orphans will be purged by the 28th of this month. Here is a current list of unblocked orphans: Unblocked orphan ant-contrib Unblocked orphan apollon Unblocked orphan azureus Unblocked orphan beagle Unblocked orphan bes Unblocked orphan bmake Unblocked orphan buoh Unblocked orphan cryptix Unblocked orphan ctrlproxy Unblocked orphan dap-freeform_handler Unblocked orphan dap-hdf4_handler Unblocked orphan dap-netcdf_handler Unblocked orphan dap-server Unblocked orphan drapes Unblocked orphan dumpasn1 Unblocked orphan elsa Unblocked orphan f-spot Unblocked orphan fig2ps Unblocked orphan flpsed Unblocked orphan fmit Taking ownership of them on the devel collection will prevent them from being blocked. Remember, it is OK to let software die. Don't view this as a list of things that somebody should pick up if they have the spare time. Things should only be revived if there are actual users in need of the software. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jarod at redhat.com Tue Jul 14 17:04:34 2009 From: jarod at redhat.com (Jarod Wilson) Date: Tue, 14 Jul 2009 13:04:34 -0400 Subject: Feature proposal: Rebootless Installer In-Reply-To: <20090714155006.GA30757@amd.home.annexia.org> References: <4A5C3C12.9050009@filteredperception.org> <4A5CA3CC.7080503@filteredperception.org> <20090714155006.GA30757@amd.home.annexia.org> Message-ID: <200907141304.34841.jarod@redhat.com> On Tuesday 14 July 2009 11:50:06 Richard W.M. Jones wrote: > On Tue, Jul 14, 2009 at 09:27:08AM -0600, Douglas McClendon wrote: > > As with a current LiveOS installation, the installation media kernel is > > the running kernel. Even if the f11 installer already allows you to > > trigger a chrooted yum update as part of the install, you won't be > > running the updated kernel until after a reboot. > > Is it the case that the installation kernel is always UP, > whereas the real kernel would probably be SMP nowadays? On everything but ppc32, we don't even ship an UP kernel any longer, the base kernel used by the installer *is* an SMP kernel. > > ... Same as RebootlessInstaller ... until ksplice ... > > I don't think ksplice changes things -- it seems to only work for very > minor kernel patches. For example, any change to the layout of a > kernel structure would appear to be incompatible with ksplice. Thus > it seems highly unlikely it'll ever work in its current form for > arbitrary kernel revisions. Trying to ksplice from 2.6.29.4 in the installer to say 2.6.30.1 or even to 2.6.31 does sound like massive fail... -- Jarod Wilson jarod at redhat.com From tibbs at math.uh.edu Tue Jul 14 17:05:20 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 14 Jul 2009 12:05:20 -0500 Subject: epel-release in Fedora repos? In-Reply-To: <1247590610.3073.1165.camel@localhost.localdomain> (Jesse Keating's message of "Tue\, 14 Jul 2009 09\:56\:49 -0700") References: <4A5C3FF9.3010903@redhat.com> <200907141729.34196.ville.skytta@iki.fi> <20090714174102.2b8a744c@faldor> <1247590610.3073.1165.camel@localhost.localdomain> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> At 7000+ srpms there is no way I could evaluate each and every one JK> for validity before submitting it for a rebuild. I think the point is that the package owner should have deleted it from devel so that there would be nothing for rel-eng to rebuild. - J< From dex.mbox at googlemail.com Tue Jul 14 17:09:22 2009 From: dex.mbox at googlemail.com (dexter) Date: Tue, 14 Jul 2009 18:09:22 +0100 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C3C12.9050009@filteredperception.org> References: <4A5C3C12.9050009@filteredperception.org> Message-ID: 2009/7/14 Douglas McClendon : > Fedorans, > > Can you spare 50 or 100K? ?If you can spare 100K/700M in the forthcoming > Fedora-12 LiveCD, I can provide you with a rebootless installation > experience. > > http://fedoraproject.org/wiki/Features/RebootlessInstaller > > > peace... > > -dmc Truly great idea, I can finally bypass anaconda thanks. ...dex From christoph.wickert at googlemail.com Tue Jul 14 17:20:02 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Tue, 14 Jul 2009 19:20:02 +0200 Subject: How to contact =?utf-8?b?VG9tw6HFoSBCxb5hdGVrPw==?= Message-ID: <1247592002.15109.209.camel@localhost> Anybody knows how to contact Tom?? B?atek? Is he still working for Red Hat? I see he has a lot of open bugs (some of them are just getting closed by the bugzappers) without a single comment from him. I set one to NEEDINFO but didn't get a response for months. Already time for AWOL procedure? [1] Regards, Christoph [1] https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers From mclasen at redhat.com Tue Jul 14 17:26:44 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 14 Jul 2009 13:26:44 -0400 (EDT) Subject: =?utf-8?b?UmU6IEhvdyB0byBjb250YWN0IFRvbcOhxaEgQsW+YXRlaz8=?= In-Reply-To: <1247592002.15109.209.camel@localhost> Message-ID: <1385896072.460741247592404623.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> > Anybody knows how to contact Tom?? B?atek? Is he still working for Red > Hat? I see he has a lot of open bugs (some of them are just getting > closed by the bugzappers) without a single comment from him. I set one > to NEEDINFO but didn't get a response for months. You can send mail to tbzatek at redhat.com, and wait for him to return from conferences and vacation. He works in Europe, so he actually gets noticable amounts of vacation :-) From dpierce at redhat.com Tue Jul 14 17:28:51 2009 From: dpierce at redhat.com (Darryl L. Pierce) Date: Tue, 14 Jul 2009 13:28:51 -0400 Subject: Problem with ruby package with binary content... In-Reply-To: <4A5CB60B.8010801@ioa.s.u-tokyo.ac.jp> References: <20090714152320.GB3432@mcpierce-laptop.rdu.redhat.com> <4A5CB60B.8010801@ioa.s.u-tokyo.ac.jp> Message-ID: <20090714172851.GC3432@mcpierce-laptop.rdu.redhat.com> On Wed, Jul 15, 2009 at 01:44:59AM +0900, Mamoru Tasaka wrote: > This is because with your spec file gem is directly installed under > %buildroot. So some C codes in the gem (usually under ext/ directory) > are compiled under %buildroot and the string "%buildroot" > is embedded in the built binary (with "gcc -g"). This will make > /usr/lib/rpm/check-buildroot complain. > > The correct way is to expand (install) gem file once under %_builddir > (at %prep or %build) and and copy all (under %_builddir) under > %buildroot at %install like: > > ------------------------------------------------------------------- > %prep > %setup -q -c -T > mkdir -p ./%{gemdir} > export CONFIGURE_ARGS="--with-cflags='%{optflags}'" > gem install --local --install-dir .%{gemdir} \ > --force -V --rdoc %{SOURCE0} > > %build > > %install > rm -rf %{buildroot} > mkdir -p %{buildroot}%{gemdir} > cp -a .%{gemdir}/* %{buildroot}%{gemdir} > .... > .... > ------------------------------------------------------------------- > > With this debuginfo rpm will also be created correctly. Awesome, that appears to have worked nicely. Thanks for the input. :) -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Virtual Machine Management - http://www.ovirt.org/ Is fearr Gaeilge bhriste n? B?arla cliste. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From christoph.wickert at googlemail.com Tue Jul 14 17:33:13 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Tue, 14 Jul 2009 19:33:13 +0200 Subject: How to contact =?utf-8?b?VG9tw6HFoSBCxb5hdGVrPw==?= In-Reply-To: <1385896072.460741247592404623.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> References: <1385896072.460741247592404623.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> Message-ID: <1247592793.15109.226.camel@localhost> Am Dienstag, den 14.07.2009, 13:26 -0400 schrieb Matthias Clasen: > > Anybody knows how to contact Tom?? B?atek? Is he still working for Red > > Hat? I see he has a lot of open bugs (some of them are just getting > > closed by the bugzappers) without a single comment from him. I set one > > to NEEDINFO but didn't get a response for months. > > You can send mail to tbzatek at redhat.com, and wait for him to return from conferences and vacation. He was BCC'ed to my previous message with his rh address, so let's hope he responds soon. > He works in Europe, so he actually gets noticable amounts of vacation :-) You can put your mind at rest, even in Europe we don't have a year of vacation. ;) Thanks, Christoph From mastahnke at gmail.com Tue Jul 14 17:33:30 2009 From: mastahnke at gmail.com (Michael Stahnke) Date: Tue, 14 Jul 2009 12:33:30 -0500 Subject: epel-release in Fedora repos? (was: Re: NVR bugs in rawhide) In-Reply-To: <1247590610.3073.1165.camel@localhost.localdomain> References: <4A5C3FF9.3010903@redhat.com> <200907141729.34196.ville.skytta@iki.fi> <20090714174102.2b8a744c@faldor> <1247590610.3073.1165.camel@localhost.localdomain> Message-ID: <7874d9dd0907141033y29bc7a37vb852b15229d428af@mail.gmail.com> Package has been marked as dead.package in devel. Ticket filed with rel-eng. stahnma From frankly3d at gmail.com Tue Jul 14 17:35:26 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Tue, 14 Jul 2009 18:35:26 +0100 Subject: Any Ruby Packagers Here? Message-ID: <4A5CC1DE.9030202@gmail.com> I don't know ruby. But: http://tinyurl.com/9m4wzr is some ruby stuff to identify snippets of Code. Any ruby knowing people willing to package it? Regards, Frank -- jabber | msn | skype: frankly3d http://www.frankly3d.com From frankly3d at gmail.com Tue Jul 14 17:37:08 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Tue, 14 Jul 2009 18:37:08 +0100 Subject: How to contact =?utf-8?b?VG9tw6HFoSBCxb5hdGVrPw==?= In-Reply-To: <1247592793.15109.226.camel@localhost> References: <1385896072.460741247592404623.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <1247592793.15109.226.camel@localhost> Message-ID: <4A5CC244.3050508@gmail.com> On 14/07/09 18:33, Christoph Wickert wrote: > Am Dienstag, den 14.07.2009, 13:26 -0400 schrieb Matthias Clasen: >>> Anybody knows how to contact Tom?? B?atek? Is he still working for Red >>> Hat? I see he has a lot of open bugs (some of them are just getting >>> closed by the bugzappers) without a single comment from him. I set one >>> to NEEDINFO but didn't get a response for months. >> >> You can send mail to tbzatek at redhat.com, and wait for him to return from conferences and vacation. > > He was BCC'ed to my previous message with his rh address, so let's hope > he responds soon. > >> He works in Europe, so he actually gets noticable amounts of vacation :-) > > You can put your mind at rest, even in Europe we don't have a year of > vacation. ;) > > Thanks, > Christoph > > Unless a politician :D Regards, Frank From ville.skytta at iki.fi Tue Jul 14 17:37:28 2009 From: ville.skytta at iki.fi (Ville =?windows-1252?q?Skytt=E4?=) Date: Tue, 14 Jul 2009 20:37:28 +0300 Subject: rpm %defattr question In-Reply-To: <1247590747.3073.1166.camel@localhost.localdomain> References: <1247356269.22031.1.camel@hawking.theorphys.helsinki.fi> <200907141733.30646.ville.skytta@iki.fi> <1247590747.3073.1166.camel@localhost.localdomain> Message-ID: <200907142037.28317.ville.skytta@iki.fi> On Tuesday 14 July 2009, Jesse Keating wrote: > On Tue, 2009-07-14 at 17:33 +0300, Ville Skytt? wrote: > > Your guess is as good as mine, but I don't know why it would need to > > change. > > %defattr and %attr appear to use different syntax, as I tried to use the > same %defattr syntax for an %attr line and RPM balked. Making them > consistent would be nice. I don't think consistency is necessarily a very good thing here because as you noticed, %defattr and %attr are different. Somewhat simplified; %defattr specifies default ownership and _optionally different modes_ for files and dirs for stuff on lines after it in %files, while %attr specifies the _same mode_ and ownership for all the stuff following it on the same line in %files, regardless if the stuff is dirs or files. The same/different modes difference is most important with %files entries that recurse and match both files and dirs. %defattr(,,[,]) %attr(,,) /some/thing From silfreed at silfreed.net Tue Jul 14 17:37:20 2009 From: silfreed at silfreed.net (Doug Warner) Date: Tue, 14 Jul 2009 13:37:20 -0400 Subject: Purging the F12 orphans In-Reply-To: <1247589637.3073.1162.camel@localhost.localdomain> References: <1247589637.3073.1162.camel@localhost.localdomain> Message-ID: <4A5CC250.5020901@silfreed.net> On 07/14/2009 12:40 PM, Jesse Keating wrote: > It's that time of the release cycle again, to purge the orphans before > we get to feature freeze. Any unblocked orphans will be purged by the > 28th of this month. Here is a current list of unblocked orphans: > Thinkfinger should probably also be blocked; I abandoned it during F11 development and has been replaced by fprint. -Doug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From bill at bfccomputing.com Tue Jul 14 17:37:28 2009 From: bill at bfccomputing.com (Bill McGonigle) Date: Tue, 14 Jul 2009 13:37:28 -0400 Subject: Feature proposal: Rebootless Installer In-Reply-To: <1247583885.15109.112.camel@localhost> References: <4A5C3C12.9050009@filteredperception.org> <4A5C9185.5010800@filteredperception.org> <1247583885.15109.112.camel@localhost> Message-ID: <4A5CC258.8010100@bfccomputing.com> On 07/14/2009 11:04 AM, Christoph Wickert wrote: > 2. Imagine after the installation you switch rebootless to the new > system and install a kmod. But you are still running the kernel > from the installation medium and kmods get installed for the > running kernel, which not necessarily needs to be the one that > was installed. Would it be feasible to fetch the current kernel from the 'net (if possible/permitted) and kexec into it before proceeding with the install? With liveUSB there's persistence, but is there a way to have a ramdisk survive kexec for liveCD? Heck, fetch the latest anaconda too, and get rid of some of the zero-day problems we have that require respins now. -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/ Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: bill at bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf From jussilehtola at fedoraproject.org Tue Jul 14 17:47:00 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Tue, 14 Jul 2009 20:47:00 +0300 Subject: NVR bugs in rawhide In-Reply-To: <20090714183943.3d2e8397@faldor> References: <4A5C3FF9.3010903@redhat.com> <20090714111532.4b688163@faldor> <4A5C7848.20608@redhat.com> <20090714144853.19816cfc@faldor> <1247575691.3164.2.camel@politzer.theorphys.helsinki.fi> <20090714153737.785463f7@faldor> <1247579666.3164.5.camel@politzer.theorphys.helsinki.fi> <20090714172325.4f54113f@faldor> <1247587729.3164.12.camel@politzer.theorphys.helsinki.fi> <20090714183943.3d2e8397@faldor> Message-ID: <1247593620.2607.7.camel@localhost.localdomain> On Tue, 2009-07-14 at 18:39 +0200, Michael Schwendt wrote: > On Tue, 14 Jul 2009 19:08:49 +0300, Jussi wrote: > > > On Tue, 2009-07-14 at 17:23 +0200, Michael Schwendt wrote: > > > > Say I've built foo-1-1 in rawhide a year ago and thus the package is > > > > available now in F-10 and F-11. How do I update to foo-2-1 in both > > > > distros? > > > > > > Whether with %dist or not, doesn't make a difference. You commit the > > > upgrade to the branch that previously targeted rawhide. F-10 in your > > > example. > > > > And it automatically ends up in F-11? > > With koji inheritance, yes. > > > I can't tag and build for F-11 if > > the tag with same EVR already exists in F-10. > > We're not talking about the same thing. Or to put it differently, you want > to prove something to me which I don't find relevant in this discussion. I just don't understand the build system well enough yet to know how this works. I agree that for packages that only contain stuff that is going to be the same on every architecture and distribution (such as packages consisting of PDF files) not using the %{?dist} tag is sane. The question about rpm internals changing is related to this, but is a separate issue. IMHO one should be able to tag&build noarch packages for multiple distributions at once to cope with the changes in rpm. However, packages that are compiled in some way *really should* use the %{?dist} tag, since that way they are upgraded when the distribution is upgraded. (Or it can be easily seen that the compilation is obsolete.) -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From loganjerry at gmail.com Tue Jul 14 17:27:18 2009 From: loganjerry at gmail.com (Jerry James) Date: Tue, 14 Jul 2009 11:27:18 -0600 Subject: Purging the F12 orphans In-Reply-To: <1247589637.3073.1162.camel@localhost.localdomain> References: <1247589637.3073.1162.camel@localhost.localdomain> Message-ID: <870180fe0907141027u7de31e4ct7a07a8c494bca031@mail.gmail.com> On Tue, Jul 14, 2009 at 10:40 AM, Jesse Keating wrote: > Unblocked orphan ant-contrib > Unblocked orphan apollon > Unblocked orphan azureus > Unblocked orphan beagle > Unblocked orphan bes > Unblocked orphan bmake > Unblocked orphan buoh > Unblocked orphan cryptix > Unblocked orphan ctrlproxy > Unblocked orphan dap-freeform_handler > Unblocked orphan dap-hdf4_handler > Unblocked orphan dap-netcdf_handler > Unblocked orphan dap-server > Unblocked orphan drapes > Unblocked orphan dumpasn1 > Unblocked orphan elsa > Unblocked orphan f-spot > Unblocked orphan fig2ps > Unblocked orphan flpsed > Unblocked orphan fmit > Are there really none that start with g-z, or did something quit after fmit? -- Jerry James http://www.jamezone.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at matbooth.co.uk Tue Jul 14 17:59:08 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Tue, 14 Jul 2009 18:59:08 +0100 Subject: Purging the F12 orphans In-Reply-To: <870180fe0907141027u7de31e4ct7a07a8c494bca031@mail.gmail.com> References: <1247589637.3073.1162.camel@localhost.localdomain> <870180fe0907141027u7de31e4ct7a07a8c494bca031@mail.gmail.com> Message-ID: <9497e9990907141059v443f19ep70da70569b6a6d7a@mail.gmail.com> On Tue, Jul 14, 2009 at 6:27 PM, Jerry James wrote: > On Tue, Jul 14, 2009 at 10:40 AM, Jesse Keating wrote: >> >> Unblocked orphan ant-contrib >> Unblocked orphan apollon >> Unblocked orphan azureus >> Unblocked orphan beagle >> Unblocked orphan bes >> Unblocked orphan bmake >> Unblocked orphan buoh >> Unblocked orphan cryptix >> Unblocked orphan ctrlproxy >> Unblocked orphan dap-freeform_handler >> Unblocked orphan dap-hdf4_handler >> Unblocked orphan dap-netcdf_handler >> Unblocked orphan dap-server >> Unblocked orphan drapes >> Unblocked orphan dumpasn1 >> Unblocked orphan elsa >> Unblocked orphan f-spot >> Unblocked orphan fig2ps >> Unblocked orphan flpsed >> Unblocked orphan fmit > > Are there really none that start with g-z, or did something quit after fmit? No specfile was ever booked into CVS for fmit... What a waste of time! -- 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 jkeating at redhat.com Tue Jul 14 17:58:43 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 14 Jul 2009 10:58:43 -0700 Subject: Purging the F12 orphans In-Reply-To: <1247589637.3073.1162.camel@localhost.localdomain> References: <1247589637.3073.1162.camel@localhost.localdomain> Message-ID: <1247594323.3073.1169.camel@localhost.localdomain> On Tue, 2009-07-14 at 09:40 -0700, Jesse Keating wrote: > > It's that time of the release cycle again, to purge the orphans before > we get to feature freeze. Any unblocked orphans will be purged by the > 28th of this month. Here is a current list of unblocked orphans: The first list was incomplete due to an API change. Here is the complete list: Unblocked orphan ant-contrib Unblocked orphan apollon Unblocked orphan azureus Unblocked orphan bes Unblocked orphan bmake Unblocked orphan buoh Unblocked orphan cryptix Unblocked orphan ctrlproxy Unblocked orphan dap-freeform_handler Unblocked orphan dap-hdf4_handler Unblocked orphan dap-netcdf_handler Unblocked orphan dap-server Unblocked orphan drapes Unblocked orphan dumpasn1 Unblocked orphan elsa Unblocked orphan fig2ps Unblocked orphan flpsed Unblocked orphan fmit Unblocked orphan fontypython Unblocked orphan galago-daemon Unblocked orphan galago-filesystem Unblocked orphan gconf-cleaner Unblocked orphan gdhcpd Unblocked orphan gfa Unblocked orphan gift Unblocked orphan gift-gnutella Unblocked orphan gift-openft Unblocked orphan gimp-lqr-plugin Unblocked orphan glipper Unblocked orphan gnochm Unblocked orphan gnome-audio Unblocked orphan gnome-compiz-manager Unblocked orphan gnome-specimen Unblocked orphan gnome-vfs2-obexftp Unblocked orphan gnubiff Unblocked orphan gstm Unblocked orphan gtk-murrine-engine Unblocked orphan gtkperf Unblocked orphan ht2html Unblocked orphan httpunit Unblocked orphan id3v2 Unblocked orphan jakarta-commons-codec Unblocked orphan jakarta-commons-digester Unblocked orphan jakarta-commons-launcher Unblocked orphan jakarta-commons-modeler Unblocked orphan jakarta-taglibs-standard Unblocked orphan javacc Unblocked orphan jdepend Unblocked orphan jflex Unblocked orphan jrexx Unblocked orphan js Unblocked orphan junitperf Unblocked orphan klear Unblocked orphan ldapvi Unblocked orphan libatomic_ops Unblocked orphan libchmxx Unblocked orphan libdap Unblocked orphan libdockapp Unblocked orphan libgtksourceviewmm Unblocked orphan liblqr-1 Unblocked orphan libnc-dap Unblocked orphan libreadline-java Unblocked orphan macchanger Unblocked orphan metamonitor Unblocked orphan mftrace Unblocked orphan mk-files Unblocked orphan msv Unblocked orphan musicbox Unblocked orphan nekohtml Unblocked orphan notecase Unblocked orphan otl Unblocked orphan pam_keyring Unblocked orphan pcmanx-gtk2 Unblocked orphan perl-LWP-Authen-Wsse Unblocked orphan perl-Text-CHM Unblocked orphan pessulus Unblocked orphan piccolo Unblocked orphan pidgin-knotify Unblocked orphan plexus-container-default Unblocked orphan plexus-interactivity Unblocked orphan plexus-velocity Unblocked orphan puretls Unblocked orphan pystatgrab Unblocked orphan python-cjson Unblocked orphan python-dbsprockets Unblocked orphan qdox Unblocked orphan qemu-launcher Unblocked orphan qt-qsa Unblocked orphan quickfix Unblocked orphan ruby-flexmock Unblocked orphan scim-input-pad Unblocked orphan scim-skk Unblocked orphan scim-tomoe Unblocked orphan shapelib Unblocked orphan skkdic Unblocked orphan surfraw Unblocked orphan themes-backgrounds-gnome Unblocked orphan thinkfinger Unblocked orphan tomoe Unblocked orphan tpm-tools Unblocked orphan tremulous-data Unblocked orphan viewmtn Unblocked orphan w3lib Unblocked orphan wdm Unblocked orphan wifi-radar Unblocked orphan wmix Unblocked orphan wxdfast Unblocked orphan xdoclet Unblocked orphan xerces-j2 Unblocked orphan xml-commons-apis Unblocked orphan xml-commons-apis12 Unblocked orphan xml-commons-which Unblocked orphan xmms-cdread Unblocked orphan xyz-gallery -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From dpierce at redhat.com Tue Jul 14 18:14:20 2009 From: dpierce at redhat.com (Darryl L. Pierce) Date: Tue, 14 Jul 2009 14:14:20 -0400 Subject: Problem with ruby package with binary content... In-Reply-To: <20090714172851.GC3432@mcpierce-laptop.rdu.redhat.com> References: <20090714152320.GB3432@mcpierce-laptop.rdu.redhat.com> <4A5CB60B.8010801@ioa.s.u-tokyo.ac.jp> <20090714172851.GC3432@mcpierce-laptop.rdu.redhat.com> Message-ID: <20090714181420.GE3432@mcpierce-laptop.rdu.redhat.com> On Tue, Jul 14, 2009 at 01:28:51PM -0400, Darryl L. Pierce wrote: > > With this debuginfo rpm will also be created correctly. > > Awesome, that appears to have worked nicely. Thanks for the input. :) Shoot, spoke way too soon. I had reset the spec file to remove where I had been experimenting with some fixes, and didn't remove the strip line. So I ran it with the changes you posted and with the strip line there and it worked. I removed the strip line and a different error came up now. The problem is now with pathing and not finding the .so file. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Virtual Machine Management - http://www.ovirt.org/ Is fearr Gaeilge bhriste n? B?arla cliste. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From limb at jcomserv.net Tue Jul 14 18:15:19 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 14 Jul 2009 13:15:19 -0500 Subject: Heads UP - PHP 5.3.0 in rawhide with new ABI/API. In-Reply-To: <4A5AD876.3010206@FamilleCollet.com> References: <4A5A2017.3090409@FamilleCollet.com> <38617c76f135677691f6b8d0f692d64b.squirrel@secure.jcomserv.net> <4A5AD876.3010206@FamilleCollet.com> Message-ID: <4A5CCB37.3080305@jcomserv.net> Remi Collet wrote: > Le 13/07/2009 03:17, Jon Ciesla a ?crit : > > >>> - php-mhash (not maintained) >>> >> Is it possible to keep this? I have a package that depends on it, and >> there may be others, though I have not checked. >> > > $ repoquery --whatrequires php-mhash > php-pear-Net-DNS-0:1.0.0-3.fc11.noarch > limph-0:1.9.5-4.fc11.noarch > limph-hostagent-0:1.9.5-4.fc11.noarch > php-pear-Crypt-CHAP-0:1.0.1-2.fc11.noarch > php-pear-Auth-RADIUS-0:1.0.6-2.fc11.noarch > > >> If not, is there a >> replacement, or would you recommend that I construct and submit for >> review my own package for it? >> > > This extension is not maintained, removed from main php and not > transferred to PECL. > > The recommended new hash solution is HASH, see > http://fr2.php.net/mhash > http://fr2.php.net/hash > > The other solution is to become upstream for mhash ;) > > Remi. > Thanks, I migrated Limph to hash, which was easy as I'm upstream. Fixed in rawhide. -- in your fear, speak only peace in your fear, seek only love -d. bowie From martin.sourada at gmail.com Tue Jul 14 18:17:40 2009 From: martin.sourada at gmail.com (Martin Sourada) Date: Tue, 14 Jul 2009 20:17:40 +0200 Subject: Purging the F12 orphans In-Reply-To: <1247594323.3073.1169.camel@localhost.localdomain> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> Message-ID: <1247595460.3916.61.camel@pc-notebook.kolej.mff.cuni.cz> On Tue, 2009-07-14 at 10:58 -0700, Jesse Keating wrote: > On Tue, 2009-07-14 at 09:40 -0700, Jesse Keating wrote: > > > > It's that time of the release cycle again, to purge the orphans before > > we get to feature freeze. Any unblocked orphans will be purged by the > > 28th of this month. Here is a current list of unblocked orphans: > > The first list was incomplete due to an API change. Here is the > complete list: > > Unblocked orphan gtk-murrine-engine I'm taking over this one. Co-maintainers welcomed. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rjune at bravegnuworld.com Tue Jul 14 18:20:34 2009 From: rjune at bravegnuworld.com (Richard June) Date: Tue, 14 Jul 2009 14:20:34 -0400 Subject: Purging the F12 orphans In-Reply-To: <1247589637.3073.1162.camel@localhost.localdomain> References: <1247589637.3073.1162.camel@localhost.localdomain> Message-ID: <200907141420.35036.rjune@bravegnuworld.com> I use azureus, and if it's reasonably popular, I'll happily maintain the package. Is there information on whether or not people actually install these packages? On Tuesday 14 July 2009 12:40:37 pm Jesse Keating wrote: > It's that time of the release cycle again, to purge the orphans before > we get to feature freeze. Any unblocked orphans will be purged by the > 28th of this month. Here is a current list of unblocked orphans: > > Unblocked orphan ant-contrib > Unblocked orphan apollon > Unblocked orphan azureus > Unblocked orphan beagle > Unblocked orphan bes > Unblocked orphan bmake > Unblocked orphan buoh > Unblocked orphan cryptix > Unblocked orphan ctrlproxy > Unblocked orphan dap-freeform_handler > Unblocked orphan dap-hdf4_handler > Unblocked orphan dap-netcdf_handler > Unblocked orphan dap-server > Unblocked orphan drapes > Unblocked orphan dumpasn1 > Unblocked orphan elsa > Unblocked orphan f-spot > Unblocked orphan fig2ps > Unblocked orphan flpsed > Unblocked orphan fmit > > Taking ownership of them on the devel collection will prevent them from > being blocked. Remember, it is OK to let software die. Don't view this > as a list of things that somebody should pick up if they have the spare > time. Things should only be revived if there are actual users in need > of the software. From katzj at redhat.com Tue Jul 14 18:23:18 2009 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 14 Jul 2009 14:23:18 -0400 Subject: Orphaning garmin-sync and pyusb Message-ID: <20090714182318.GA43950@redhat.com> Since I upgraded from the Garmin Edge 305 to the 705, I'm no longer using either of garmin-sync or its dependency pyusb on any sort of regular basis. This is probably less than ideal for adequately maintaining them. If you *have* one of the older Garmin Edge or Forerunner devices, they're easy enough packages to maintain -- upstream is responsive to the one or two things I threw at him and the userbase is not that large. Orphaned in pkgdb for devel -- I'll keep responding to things for F10/F11 unless someone else picks them up to avoid leaving users of existing releases out in the cold Jeremy From Matt_Domsch at dell.com Tue Jul 14 18:22:35 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 14 Jul 2009 13:22:35 -0500 Subject: Fedora rawhide rebuild in mock status 2009-07-10 x86_64 Message-ID: <20090714182235.GA1967@mock.linuxdev.us.dell.com> Fedora Rawhide-in-Mock Build Results for x86_64 using rawhide as of 10 July 2009. This is a full rebuild of all packages. Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ 1 Open Bugs which now build, and can be marked CLOSED RAWHIDE: ruby-rpm: [u'465103'] Total packages: 8004 Number failed to build: 391 Number expected to fail due to ExclusiveArch or ExcludeArch: 32 Leaving: 359 Of those expected to have worked... Without a bug filed: 355 ---------------------------------- 389-ds-base-1.2.1-1.fc12 (build/make) rmeggins,nhosoi,nkinder 389-dsgw-1.1.3-1.fc12 (build/make) rmeggins,nhosoi,nkinder BackupPC-3.1.0-5.fc11 (build/make) trasher CTL-1.4.1-9.fc11 (build/make) kwizart Django-1.0.2-3.fc11 (build/make) salimma,smilner GtkAda-2.10.2-2.fc11 (build/make) gemi Io-language-20071010-10.fc11 (build/make) salimma,salimma Macaulay2-1.2-4.fc12 (build/make) rdieter Perlbal-1.70-3.fc11 (build/make) ruben PyKDE-3.16.3-1.fc12 (build/make) rdieter,jamatos PyQuante-1.6.3-1.fc11 (build/make) jussilehtola PyQwt-5.1.0-3.fc11 (build/make) tadej PyX-0.10-6.fc11 (build/make) jamatos,jamatos,mpeters R-BSgenome.Celegans.UCSC.ce2-1.2.0-5 (build/make) pingou R-BSgenome.Dmelanogaster.FlyBase.r51-1.3.1-3 (build/make) pingou R-RODBC-1.2-2.fc11 (build/make) spot R-RScaLAPACK-0.5.1-19.fc11 (build/make) spot R-hgu95av2probe-2.0.0-1.fc9 (build/make) pingou ScientificPython-2.8-4.fc11 (build/make) jspaleta UnihanDb-5.1.0-7.fc11.1 (build/make) dchen,i18n-team abcMIDI-20090317-1.fc12 (build/make) gemi alliance-5.0-26.20070718snap.fc11 (build/make) chitlesh,chitlesh,tnorth almanah-0.5.0-1.fc11 (build/make) lokthare amanda-2.6.0p2-9.fc12 (build/make) dnovotny amora-1.1-4.fc11 (build/make) allisson anjuta-2.26.1.0-1.fc12 (build/make) rishi,rakesh anyremote-4.18.1-1.fc11 (build/make) anyremote apr-util-1.3.7-4.fc12 (build/make) jorton,bojan argyllcms-1.0.4-1.fc12 (build/make) limb arm4-0.8.2-1.fc12 (build/make) grandcross,limb arts-1.5.10-5.fc11 (build/make) than,kkofler,rdieter,tuxbrewr artwiz-aleczapka-fonts-1.3-7.fc11 (build/make) spot,awjb,fonts-sig asio-1.2.0-2.fc11 (build/make) uwog asymptote-1.73-1.fc12 (build/make) spot atlas-3.8.3-4.fc12 (build/make) deji,deji aubio-0.3.2-6.fc11 (build/make) green avr-binutils-2.18-4.fc11 (build/make) tnorth,trondd avr-libc-1.6.4-4.fc12 (build/make) tnorth,trondd awn-extras-applets-0.3.2.1-8.fc11 (build/make) phuang,sindrepb axis-1.2.1-4.1.fc10 (build/make) pcheung babl-0.1.0-1.fc12 (build/make) deji,nphilipp batik-1.7-4.fc11 (build/make) langel,fitzsim beagle-0.3.9-6.fc11 (build/make) orphan,drago01,psytux bigloo-3.1b-5.fc11 (build/make) gemi blacs-1.1-31.fc11 (build/make) spot bmpx-0.40.14-8.fc11 (build/make) akahl,cheese btrfs-progs-0.19-3.fc12 (build/make) josef,mmahut buffer-1.19-5.fc11 (build/make) bcornec,wolfy calf-0.0.18.5-1.fc12 (build/make) oget cave9-0.3-8.fc12 (build/make) bogado cdrkit-1.1.9-4.fc11 (build/make) rrakus cernlib-2006-32.fc11 (build/make) limb,pertusus chipmunk-4.1.0-6.fc11 (build/make) limb classpathx-jaf-1.0-12.fc10 (build/make) devrim,dwalluck clutter-cairo-0.8.2-3.fc11 (build/make) allisson clutter-cairomm-0.7.4-2.fc11 (build/make) denis clutter-gst-0.8.0-4.fc11 (build/make) allisson codeblocks-8.02-7.fc11 (build/make) sharkcz cogito-0.18.2-4.fc11 (build/make) chrisw compat-db-4.6.21-5.fc10 (build/make) jnovy,pmatilai compat-erlang-R10B-13.11.fc11 (build/make) gemi coredumper-1.2.1-8.fc12 (build/make) rakesh couchdb-0.9.0-2.fc12 (build/make) allisson cryptsetup-luks-1.0.7-0.1.fc12 (build/make) lvm-team,agk,dwysocha,mbroz,mornfall,pjones,till,whulbert cuetools-1.4.0-0.4.svn305.fc12 (build/make) stingray dap-hdf4_handler-3.7.9-2.fc11 (build/make) pertusus,pertusus dbus-c++-0.5.0-0.8.20090203git13281b3.fc11 (build/make) drago01 dev86-0.16.17-14.fc11 (build/make) jnovy devhelp-0.23-7.fc12 (build/make) mbarnes e16-themes-0.16.8.0.2-3.fc11 (build/make) terjeros eclipse-cdt-5.0.2-2.fc11 (build/make) jjohnstn eclipse-checkstyle-4.0.1-12.fc11 (build/make) rmyers,akurtakov,overholt elfutils-0.141-1.fc12 (build/make) roland emacs-mew-6.2.51-2.fc11 (build/make) tagoh epiphany-extensions-2.26.1-2.fc12 (build/make) caillon,pgordon espeak-1.40.02-2.fc12 (build/make) faucamp etherbat-1.0.1-5.fc11 (build/make) limb evolution-brutus-1.2.35-2.fc11 (build/make) bpepple evolution-data-server-2.27.3-3.fc12 (build/make) mbarnes,mbarnes,mcrha evolution-rss-0.1.2-9.fc12 (build/make) lucilanga evolution-zimbra-0.1.1-6.fc11 (build/make) mbarnes,mmahut fbreader-0.10.7-1.fc11 (build/make) salimma findbugs-1.3.8-1.fc11 (build/make) jjames fityk-0.8.1-14.fc10 (build/make) jpye fluidsynth-1.0.9-1.fc12 (build/make) green,oget fonts-KOI8-R-1.0-11.fc11 (build/make) than,fonts-sig fonts-hebrew-fancy-0.20051122-5.fc11 (build/make) danken,fonts-sig freefem++-3.0-5.5.fc11 (patch_fuzz) rathann,itamarjp fsarchiver-0.5.6-1.fc12 (build/make) drago01 func-0.25-1.fc12 (build/make) mdehaan,alikins,skvidal fusecompress-2.5-1.fc12 (build/make) lkundrak,lmacken gauche-gl-0.4.4-4.fc11 (build/make) gemi gauche-gtk-0.4.1-18.fc11 (build/make) gemi gawk-3.1.6-5.fc11 (build/make) kasal gbdfed-1.4-2.fc11 (build/make) spot gc-7.1-7.fc11 (build/make) rdieter gcdmaster-1.2.2-5.fc11 (build/make) denis gcl-2.6.8-0.3.20090303cvs.fc12 (build/make) jjames,green gdal-1.6.0-8.fc11 (build/make) rezso,pertusus gearmand-0.7-1.fc12 (build/make) ruben gedit-vala-0.4.1-2.fc11 (build/make) salimma gengetopt-2.22.1-2.fc11 (build/make) rishi geronimo-specs-1.0-2.M2.fc10 (build/make) fnasser gflags-1.0-3.fc11 (build/make) rakesh gget-0.0.4-9.fc11 (build/make) ant ghasher-1.2.1-7.fc11 (build/make) denis glob2-0.9.4.1-1.fc12 (build/make) rafalzaq globus-common-10.2-5.fc12 (build/make) ellert globus-ftp-client-3.14-2.fc12 (build/make) ellert globus-gsi-openssl-error-0.14-3.fc12 (build/make) ellert globus-gssapi-error-2.5-3.fc12 (build/make) ellert globus-xio-2.7-4.fc12 (build/make) ellert globus-xio-gsi-driver-0.6-2.fc12 (build/make) ellert gloox-1.0-0.5.SVNr4003.fc12 (build/make) hubbitus gmfsk-0.7-0.6.pre1.fc11 (build/make) bjensen,bjensen,dp67,sconklin,sindrepb gmime-2.4.3-3.fc11 (build/make) alexl,thl gmime22-2.2.23-5.fc11 (build/make) bjohnson gmrun-0.9.2-16.fc11 (build/make) gilboa gnome-doc-utils-0.17.2-1.fc12 (build/make) mbarnes gnome-python2-extras-2.25.3-4.fc12 (build/make) mbarnes gnome-scan-0.6.2-1.fc11 (build/make) deji gnome-specimen-0.3-4.fc11 (build/make) orphan gnomint-0.9.1-5.fc12 (build/make) verdurin gnotime-2.3.0-3.fc11 (build/make) limb gnubversion-0.5-7.fc11 (build/make) laxathom gnuchess-5.07-12.fc11 (build/make) kaboom gnupg-1.4.9-5.fc11 (build/make) nalin,rdieter gnuradio-3.1.3-5.fc11 (build/make) mmahut,astronomy-sig gparted-0.4.5-1.fc12 (build/make) deji gromacs-4.0.4-2.fc11 (build/make) jussilehtola grub-0.97-53.fc12 (build/make) pjones,lkundrak grub2-1.98-0.5.20080827svn.fc11 (build/make) lkundrak gspiceui-0.9.65-4.fc11 (build/make) laxathom,chitlesh gsynaptics-0.9.16-1.fc11 (build/make) ixs gt-0.4-8.fc11 (build/make) jwrdegoede gtkmm24-2.16.0-1.fc11 (build/make) denis gtranslator-1.9.5-1.fc12 (build/make) sindrepb,atorkhov guilt-0.32-3.fc11 (build/make) sandeen gutenprint-5.2.3-5.fc11 (unpackaged_files/python-egg-info?) twaugh gvfs-1.3.1-2.fc12 (build/make) tbzatek,alexl gwget-1.0.1-2.fc11 (build/make) cwickert hosts3d-0.98-1.fc11 (build/make) cassmodiah htmldoc-1.8.27-10.fc11 (build/make) agoode,pertusus hydrogen-0.9.4-0.3.rc1.1.fc11 (build/make) green,lkundrak,nando,oget hyphen-hsb-0.20080619-1.fc11 (build/make) caolanm hyphen-ia-0.20050628-1.fc11 (build/make) caolanm iksemel-1.3-7.fc11 (build/make) jcollie inn-2.5.0-2 (build/make) npajkovs,npajkovs,ovasik insight-6.8-7.fc11 (build/make) monnerat,jkratoch ipsec-tools-0.7.2-1.fc12 (build/make) tmraz irda-utils-0.9.18-7.fc11 (build/make) karsten iverilog-0.9.20090423-4..fc11 (build/make) rezso,chitlesh jack-keyboard-2.5-2.fc12 (build/make) oget jack-rack-1.4.7-2.fc11 (build/make) kwizart,nando jakarta-commons-dbcp-1.2.1-12.5.fc11 (build/make) dbhole jasper-1.900.1-10.fc11 (build/make) rdieter java-1.6.0-openjdk-1.6.0.0-23.b16.fc12 (build/make) langel,dbhole,langel,lkundrak,mjw jfsutils-1.1.13-5.fc11 (build/make) jwboyer jruby-1.1.6-3.fc11 (build/make) konradm junitperf-1.9.1-3.2.fc11 (build/make) mwringe k3d-0.7.11.0-1.fc12 (build/make) denis kaya-0.5.1-4.fc11 (build/make) s4504kr kdebase3-3.5.10-8.fc11 (build/make) than,jreznik,kkofler,ltinkl,rdieter,svahl,tuxbrewr kdelibs3-3.5.10-11.fc11 (build/make) than,kkofler,ltinkl,rdieter,tuxbrewr kdevelop-3.5.4-3.fc11 (build/make) than,kkofler,ltinkl,rdieter,tuxbrewr kdewebdev-3.5.10-2.fc11 (build/make) than,jreznik,kkofler,ltinkl,rdieter,tuxbrewr kdnssd-avahi-0.1.3-0.7.20080116svn.fc11 (build/make) rdieter,rdieter,tuxbrewr klear-0.7.0-2.svn113.fc10 (build/make) orphan knetstats-1.6.1-9.fc11 (build/make) chitlesh knm_new-fonts-1.1-5.fc11 (build/make) tagoh,fonts-sig,i18n-team konq-plugins-4.2.2-1.fc11 (build/make) svahl,kkofler,ltinkl,rdieter,than,tuxbrewr kopete-cryptography-1.3.0-7.fc11 (build/make) jreznik,kkofler,ltinkl,rdieter,than kpolynome-0.1.2-13.fc11 (build/make) chitlesh ktechlab-0.3.70-1.20090304svn.fc11 (build/make) chitlesh lam-7.1.4-7.fc12 (build/make) dledford lash-0.5.4-5.fc12 (build/make) green,oget lasi-1.1.0-4.fc11 (build/make) orion ldapvi-1.7-8.fc11 (build/make) orphan libSM-1.1.0-4.fc11 (build/make) ssp libXtst-1.0.3-5.fc11 (build/make) ssp libbeagle-0.3.9-3.fc11 (build/make) mclasen libchamplain-0.2.9-1.fc11 (build/make) rishi libepc-0.3.10-1.fc12 (build/make) bpepple libfakekey-0.1-2.fc11 (build/make) mccann libgnomedb-3.99.7-3.fc11 (build/make) denis,denis,huzaifas libgnomeprint22-2.18.6-1.fc11 (build/make) behdad libibumad-1.3.1-1.fc12 (build/make) dledford libprojectM-1.2.0-9.fc11 (build/make) imntreal libprojectM-qt-1.2.0-5.fc11 (build/make) imntreal libsigsegv-2.6-2.fc11 (build/make) rdieter libsoup22-2.2.105-4.fc11 (build/make) mbarnes libsx-2.05-16.fc11 (build/make) kasal,pertusus libtar-1.2.11-11.fc10 (build/make) huzaifas,huzaifas libtheora-1.1alpha2-1.fc12 (build/make) ajax,jnovy,jwrdegoede libtommath-0.41-9.fc11 (build/make) jjh libtopology-0.3-5.fc11 (build/make) tbreeds libunwind-0.99-0.10.20090430betagit4b8404d1.fc12 (build/make) jkratoch libvirt-cim-0.5.5-1.fc12 (build/make) danms,kaitlin linux-libertine-fonts-4.1.8-1.fc11 (build/make) farnold,fonts-sig,kevin linuxwacom-0.8.2.2-11.fc11 (build/make) arozansk lordsawar-0.1.5-2.fc11 (build/make) ianweller lout-3.38-2.fc11 (build/make) spot lxappearance-0.2.1-1.fc12 (build/make) cwickert lxlauncher-0.2.1-1.fc12 (build/make) cwickert lxsession-edit-0.1.1-1.fc12 (build/make) cwickert lxshortcut-0.1.1-1.fc12 (build/make) cwickert maildrop-2.0.4-9.fc11 (build/make) athimm matchbox-keyboard-0.1-0.2009.05.19.1.fc11 (build/make) mccann mathml-fonts-1.0-23.fc11 (build/make) rdieter,fonts-sig mercurial-1.3-2.fc12 (build/make) nbecker,ausil,mmcgrath,nbecker mhash-0.9.9-7 (build/make) spot,limb mingw32-pango-1.24.2-1.fc12 (build/make) rjones,berrange,epienbro minicom-2.3-4.fc11 (build/make) mlichvar minirpc-0.3.2-3.fc11 (build/make) agoode mod_dnssd-0.6-2.fc11 (build/make) ivazquez,lennart monafont-2.90-8.fc11 (build/make) mtasaka mpfi-1.3.4-0.5.RC3.fc11 (build/make) konradm mugshot-1.2.2-9.fc12 (build/make) otaylor multiget-1.2.0-5.fc11 (build/make) guidoledermann,mtasaka muse-1.0-0.6.rc3.fc12 (build/make) oget,nando museek+-0.2-1.fc11 (build/make) belegdol mysql-5.1.35-1.fc12 (build/make) tgl mysql-gui-tools-5.0r12-11.fc11 (build/make) ausil,hubbitus nautilus-actions-1.10.1-1.fc12 (build/make) deji netcdf-perl-1.2.3-9.fc11 (build/make) orion,perl-sig,pertusus newsx-1.6-11.fc11 (build/make) rathann,itamarjp ngspice-18-2.fc11 (build/make) chitlesh nickle-2.68-1.fc11 (build/make) salimma ntop-3.3.9-5.fc11 (build/make) rakesh,pvrabec nwsclient-1.6.3-3.fc11 (build/make) spot nx-3.3.0-35.fc12 (build/make) athimm,limb ocaml-pa-do-0.8.9-2.fc12 (build/make) rjones ocfs2-tools-1.3.9-10.20080221git.fc11 (build/make) mfasheh,fabbione,mfasheh opencv-1.1.0-0.1.pre1.fc12.1 (build/make) rakesh,kwizart,nomis80 openhpi-2.14.0-2.fc12 (build/make) sharkcz,pknirsch orpie-1.5.1-4.fc10 (build/make) xris orsa-0.7.0-8.fc11 (build/make) mjakubicek,mmahut paraview-3.4.0-4.fc11 (build/make) orion,pertusus parted-1.8.8-17.fc11 (build/make) jgranado pcmanx-gtk2-0.3.8-5.fc11 (build/make) orphan pdf2djvu-0.5.0-3.fc12 (build/make) rakesh perl-AnyEvent-XMPP-0.4-1.fc11 (build/make) allisson,perl-sig perl-DBIx-Class-Schema-Loader-0.04005-3.fc11 (build/make) cweyl,perl-sig perl-Email-MIME-Creator-1.455-1.fc11 (build/make) spot,perl-sig perl-Email-MIME-Modifier-1.443-2.fc11 (build/make) spot,perl-sig perl-Event-Lib-1.03-6.fc11 (build/make) kwizart,perl-sig perl-HTML-FormFu-Model-DBIC-0.03007-1.fc11 (build/make) cweyl,perl-sig perl-IPC-Run-0.82-2.fc11 (build/make) steve,perl-sig perl-Log-Log4perl-1.20-3.fc11 (build/make) kasal,mmaslano,perl-sig perl-MooseX-AttributeHelpers-0.19-1.fc12 (build/make) cweyl,perl-sig perl-MooseX-Daemonize-0.08-3.fc11 (build/make) allisson perl-MooseX-Getopt-0.18-1.fc12 (build/make) cweyl,perl-sig perl-MooseX-POE-0.204-1.fc12 (build/make) allisson perl-MooseX-Role-Parameterized-0.09-2.fc12 (build/make) cweyl,perl-sig perl-MooseX-Traits-Attribute-CascadeClear-0.03-2.fc11 (build/make) cweyl,perl-sig perl-PDL-2.4.4-3.fc11 (build/make) kasal,mmaslano,orion perl-SQL-Statement-1.15-5.fc11 (build/make) kasal,mmaslano,perl-sig perl-SVN-Mirror-0.75-2.fc11 (build/make) iburrell,perl-sig perl-SVN-Simple-0.27-7.fc11 (build/make) iburrell,perl-sig perl-Sendmail-PMilter-0.97-1.fc10 (build/make) guthrie perl-Template-Plugin-Class-0.13-6.fc11 (build/make) spot,perl-sig perl-Test-AutoBuild-1.2.2-7.fc11 (build/make) berrange pg_top-3.6.2-4.fc11 (build/make) itamarjp pmount-0.9.17-4.fc11 (build/make) kasal,jpmahowa,pertusus projectM-jack-1.2.0-5.fc11 (build/make) imntreal projectM-libvisual-1.2.0-5.fc11 (build/make) imntreal projectM-pulseaudio-1.2.0-4.fc11 (build/make) imntreal protobuf-2.0.2-8.fc11 (build/make) abbot pvm-3.4.5-12.fc11 (build/make) alexlan pyclutter-0.8.2-2.fc11 (build/make) allisson pygoocanvas-0.14.0-1.fc12 (build/make) bjohnson pygsl-0.9.3-4.fc11 (build/make) jamatos pypar-2.1.0_66-3.fc10 (build/make) jussilehtola pysvn-1.6.3-2.fc11 (build/make) ravenoak python-basemap-0.99.2-3.fc11 (build/make) jspaleta python-docs-2.6-2.fc11 (build/make) james,ivazquez,rrakus python-openhpi-1.1-3.fc11 (build/make) sharkcz python-peak-util-symbols-1.0-3.fc11 (build/make) lmacken python-py-0.9.2-7.fc11 (build/make) thm python-pylons-0.9.7-0.2.rc4.fc11 (build/make) kylev python-reportlab-2.1-4.fc11 (build/make) bpepple python-tftpy-0.4.6-3.fc11 (build/make) ivaxer qtiplot-0.9-11.fc11 (build/make) frankb qtparted-0.4.5-19.fc11 (build/make) steve qzion-0.4.0-1.fc11 (build/make) john5342,rdieter ragel-6.3-2.fc11 (build/make) jjh ratpoison-1.4.4-3.fc12 (build/make) kevin,kevin rcssserver3d-0.6.1-4.fc12 (build/make) hedayat readahead-1.4.9-1.fc11 (build/make) harald,harald rsibreak-0.9.0-10.fc11 (build/make) liquidat,rdieter safekeep-1.0.5-2.fc11 (build/make) jspaleta samba-3.4.0-0pre1.37.fc12 (build/make) simo,gd sane-frontends-1.0.14-6.fc11 (build/make) nphilipp scalapack-1.7.5-5.fc11 (build/make) spot sdcc-2.9.0-2.fc12 (build/make) konradm,jwrdegoede seahorse-plugins-2.27.1-1.fc12 (build/make) mclasen,tbzatek sectool-0.9.3-1.fc12 (build/make) pvrabec,jhrozek,mildew sems-1.1.0-7.fc12 (build/make) peter,ondrejj seq24-0.8.7-15.fc11 (build/make) green showimg-0.9.5-22.fc11 (build/make) abompard siril-0.8-7.fc11 (build/make) mmahut slapi-nis-0.17-1.fc12 (build/make) nalin smart-1.2-64.fc12 (build/make) athimm spambayes-1.0.4-7.fc11 (build/make) xulchris squeak-vm-3.10.4-4.fc11 (build/make) gavin,tuxbrewr supertuxkart-0.6.1-2.fc11 (build/make) limb svgalib-1.9.25-6.fc11 (build/make) rakesh,orion svnkit-1.2.3-1.fc11 (build/make) robmv,akurtakov syck-0.61-8.2.fc11 (build/make) oliver synergy-1.3.1-12.fc11 (build/make) thias system-config-vsftpd-0.5.1-4.fc11 (build/make) mbarabas t1utils-1.33-2.fc11 (build/make) jamatos tachyon-0.98.1-1.fc11 (build/make) rathann,itamarjp taipeifonts-1.2-7.fc11 (build/make) cchance,fonts-sig,i18n-team tcl-8.5.6-6.fc11 (build/make) mmaslano testdisk-6.11-3.fc12 (build/make) grenier tex-musixtex-0.114-6.rev4.fc11 (build/make) oget tig-0.14.1-1.fc11 (build/make) jbowes,jcollie,tmz tor-0.2.0.34-3.fc11 (build/make) ensc,cassmodiah towhee-6.2.3-5.fc10 (build/make) jussilehtola ucblogo-6.0-4.fc11 (build/make) gemi unifdef-1.171-8.fc11 (build/make) dwmw2,jaswinder util-vserver-0.30.215-7.fc11 (build/make) ensc uuid-1.6.1-6.fc12 (build/make) steve varnish-2.0.4-2.fc12 (build/make) ingvar vdr-1.6.0-23.fc12 (build/make) scop,vpv w3c-libwww-5.4.1-0.15.20060206cvs.fc11 (build/make) awjb widelands-0-0.13.Build13.fc11 (build/make) karlik wise2-2.2.0-5.fc11 (build/make) alexlan xastir-1.9.4-8.fc12 (build/make) lucilanga,bjensen xdotool-20090330-3.fc12 (build/make) sindrepb xemacs-packages-extra-20090217-1.fc11 (build/make) jjames xen-3.4.0-2.fc12 (build/make) xen-maint,berrange,kraxel,virtmaint xenner-0.47-1.fc12 (build/make) kraxel,berrange,itamarjp,virtmaint xine-ui-0.99.5-11.fc12 (build/make) jussilehtola xmbdfed-4.7-4.fc11 (build/make) spot xmlcopyeditor-1.1.0.6-4.fc9 (build/make) ivazquez xorg-x11-drv-acecad-1.3.0-1.fc11 (build/make) xgl-maint xorg-x11-drv-aiptek-1.2.0-1.fc11 (build/make) xgl-maint xorg-x11-drv-elographics-1.2.3-2.fc11 (build/make) xgl-maint xorg-x11-drv-fpit-1.3.0-2.fc11 (build/make) xgl-maint xorg-x11-drv-glint-1.2.3-1.fc12 (build/make) xgl-maint xorg-x11-drv-hyperpen-1.3.0-1.fc11 (build/make) xgl-maint xorg-x11-drv-keyboard-1.3.2-3.fc11 (build/make) xgl-maint xorg-x11-drv-mutouch-1.2.1-2.fc11 (build/make) xgl-maint xorg-x11-drv-penmount-1.4.0-2.fc11 (build/make) xgl-maint xorg-x11-drv-radeonhd-1.2.5-2.8.20090411git.fc11 (build/make) ndim,ajax xorg-x11-xdm-1.1.6-10.fc12 (build/make) xgl-maint,pertusus xorg-x11-xsm-1.0.2-9.fc11 (build/make) xgl-maint xpilot-ng-4.7.2-16.fc11 (build/make) wart xqilla-2.1.3-0.6.fc11 (build/make) mzazrive xqilla10-1.0.2-6.fc11 (build/make) mzazrive xsane-0.996-7.fc11 (build/make) nphilipp zsh-4.3.9-4.fc11 (build/make) james zynaddsubfx-2.2.1-20.fc11 (build/make) green With bugs filed: 4 ---------------------------------- httping-1.2.9-4.fc11 [u'502430 NEW'] (build/make) fab libFoundation-1.1.3-11.fc9 [u'440564 ASSIGNED'] (build/make) athimm perl-RRD-Simple-1.43-3.fc9 [u'464964 ASSIGNED'] (build/make) cweyl,perl-sig smarteiffel-2.3-2.fc9 [u'464923 ASSIGNED'] (build/make) gemi ---------------------------------- Packages by owner: abbot: protobuf abompard: showimg agk: cryptsetup-luks agoode: htmldoc,minirpc ajax: libtheora,xorg-x11-drv-radeonhd akahl: bmpx akurtakov: eclipse-checkstyle,svnkit alexl: gmime,gvfs alexlan: pvm,wise2 alikins: func allisson: amora,clutter-cairo,clutter-gst,couchdb,perl-AnyEvent-XMPP,perl-MooseX-Daemonize,perl-MooseX-POE,pyclutter ant: gget anyremote: anyremote arozansk: linuxwacom astronomy-sig: gnuradio athimm: libFoundation,maildrop,nx,smart atorkhov: gtranslator ausil: mercurial,mysql-gui-tools awjb: artwiz-aleczapka-fonts,w3c-libwww bcornec: buffer behdad: libgnomeprint22 belegdol: museek+ berrange: mingw32-pango,perl-Test-AutoBuild,xen,xenner bjensen: gmfsk,gmfsk,xastir bjohnson: gmime22,pygoocanvas bogado: cave9 bojan: apr-util bpepple: evolution-brutus,libepc,python-reportlab caillon: epiphany-extensions caolanm: hyphen-hsb,hyphen-ia cassmodiah: hosts3d,tor cchance: taipeifonts cheese: bmpx chitlesh: alliance,alliance,gspiceui,iverilog,knetstats,kpolynome,ktechlab,ngspice chrisw: cogito cweyl: perl-DBIx-Class-Schema-Loader,perl-HTML-FormFu-Model-DBIC,perl-MooseX-AttributeHelpers,perl-MooseX-Getopt,perl-MooseX-Role-Parameterized,perl-MooseX-Traits-Attribute-CascadeClear,perl-RRD-Simple cwickert: gwget,lxappearance,lxlauncher,lxsession-edit,lxshortcut danken: fonts-hebrew-fancy danms: libvirt-cim dbhole: jakarta-commons-dbcp,java-1.6.0-openjdk dchen: UnihanDb deji: atlas,atlas,babl,gnome-scan,gparted,nautilus-actions denis: clutter-cairomm,gcdmaster,ghasher,gtkmm24,k3d,libgnomedb,libgnomedb devrim: classpathx-jaf dledford: lam,libibumad dnovotny: amanda dp67: gmfsk drago01: beagle,dbus-c++,fsarchiver dwalluck: classpathx-jaf dwmw2: unifdef dwysocha: cryptsetup-luks ellert: globus-common,globus-ftp-client,globus-gsi-openssl-error,globus-gssapi-error,globus-xio,globus-xio-gsi-driver ensc: tor,util-vserver epienbro: mingw32-pango fab: httping fabbione: ocfs2-tools farnold: linux-libertine-fonts faucamp: espeak fitzsim: batik fnasser: geronimo-specs fonts-sig: artwiz-aleczapka-fonts,fonts-KOI8-R,fonts-hebrew-fancy,knm_new-fonts,linux-libertine-fonts,mathml-fonts,taipeifonts frankb: qtiplot gavin: squeak-vm gd: samba gemi: GtkAda,abcMIDI,bigloo,compat-erlang,gauche-gl,gauche-gtk,smarteiffel,ucblogo gilboa: gmrun grandcross: arm4 green: aubio,fluidsynth,gcl,hydrogen,lash,seq24,zynaddsubfx grenier: testdisk guidoledermann: multiget guthrie: perl-Sendmail-PMilter harald: readahead,readahead hedayat: rcssserver3d hubbitus: gloox,mysql-gui-tools huzaifas: libgnomedb,libtar,libtar i18n-team: UnihanDb,knm_new-fonts,taipeifonts ianweller: lordsawar iburrell: perl-SVN-Mirror,perl-SVN-Simple imntreal: libprojectM,libprojectM-qt,projectM-jack,projectM-libvisual,projectM-pulseaudio ingvar: varnish itamarjp: freefem++,newsx,pg_top,tachyon,xenner ivaxer: python-tftpy ivazquez: mod_dnssd,python-docs,xmlcopyeditor ixs: gsynaptics jamatos: PyKDE,PyX,PyX,pygsl,t1utils james: python-docs,zsh jaswinder: unifdef jbowes: tig jcollie: iksemel,tig jgranado: parted jhrozek: sectool jjames: findbugs,gcl,xemacs-packages-extra jjh: libtommath,ragel jjohnstn: eclipse-cdt jkratoch: insight,libunwind jnovy: compat-db,dev86,libtheora john5342: qzion jorton: apr-util josef: btrfs-progs jpmahowa: pmount jpye: fityk jreznik: kdebase3,kdewebdev,kopete-cryptography jspaleta: ScientificPython,python-basemap,safekeep jussilehtola: PyQuante,gromacs,pypar,towhee,xine-ui jwboyer: jfsutils jwrdegoede: gt,libtheora,sdcc kaboom: gnuchess kaitlin: libvirt-cim karlik: widelands karsten: irda-utils kasal: gawk,libsx,perl-Log-Log4perl,perl-PDL,perl-SQL-Statement,pmount kevin: linux-libertine-fonts,ratpoison,ratpoison kkofler: arts,kdebase3,kdelibs3,kdevelop,kdewebdev,konq-plugins,kopete-cryptography konradm: jruby,mpfi,sdcc kraxel: xen,xenner kwizart: CTL,jack-rack,opencv,perl-Event-Lib kylev: python-pylons langel: batik,java-1.6.0-openjdk,java-1.6.0-openjdk laxathom: gnubversion,gspiceui lennart: mod_dnssd limb: argyllcms,arm4,cernlib,chipmunk,etherbat,gnotime,mhash,nx,supertuxkart liquidat: rsibreak lkundrak: fusecompress,grub,grub2,hydrogen,java-1.6.0-openjdk lmacken: fusecompress,python-peak-util-symbols lokthare: almanah ltinkl: kdebase3,kdelibs3,kdevelop,kdewebdev,konq-plugins,kopete-cryptography lucilanga: evolution-rss,xastir lvm-team: cryptsetup-luks mbarabas: system-config-vsftpd mbarnes: devhelp,evolution-data-server,evolution-data-server,evolution-zimbra,gnome-doc-utils,gnome-python2-extras,libsoup22 mbroz: cryptsetup-luks mccann: libfakekey,matchbox-keyboard mclasen: libbeagle,seahorse-plugins mcrha: evolution-data-server mdehaan: func mfasheh: ocfs2-tools,ocfs2-tools mildew: sectool mjakubicek: orsa mjw: java-1.6.0-openjdk mlichvar: minicom mmahut: btrfs-progs,evolution-zimbra,gnuradio,orsa,siril mmaslano: perl-Log-Log4perl,perl-PDL,perl-SQL-Statement,tcl mmcgrath: mercurial monnerat: insight mornfall: cryptsetup-luks mpeters: PyX mtasaka: monafont,multiget mwringe: junitperf mzazrive: xqilla,xqilla10 nalin: gnupg,slapi-nis nando: hydrogen,jack-rack,muse nbecker: mercurial,mercurial ndim: xorg-x11-drv-radeonhd nhosoi: 389-ds-base,389-dsgw nkinder: 389-ds-base,389-dsgw nomis80: opencv npajkovs: inn,inn nphilipp: babl,sane-frontends,xsane oget: calf,fluidsynth,hydrogen,jack-keyboard,lash,muse,tex-musixtex oliver: syck ondrejj: sems orion: lasi,netcdf-perl,paraview,perl-PDL,svgalib orphan: beagle,gnome-specimen,klear,ldapvi,pcmanx-gtk2 otaylor: mugshot ovasik: inn overholt: eclipse-checkstyle pcheung: axis perl-sig: netcdf-perl,perl-AnyEvent-XMPP,perl-DBIx-Class-Schema-Loader,perl-Email-MIME-Creator,perl-Email-MIME-Modifier,perl-Event-Lib,perl-HTML-FormFu-Model-DBIC,perl-IPC-Run,perl-Log-Log4perl,perl-MooseX-AttributeHelpers,perl-MooseX-Getopt,perl-MooseX-Role-Parameterized,perl-MooseX-Traits-Attribute-CascadeClear,perl-RRD-Simple,perl-SQL-Statement,perl-SVN-Mirror,perl-SVN-Simple,perl-Template-Plugin-Class pertusus: cernlib,dap-hdf4_handler,dap-hdf4_handler,gdal,htmldoc,libsx,netcdf-perl,paraview,pmount,xorg-x11-xdm peter: sems pgordon: epiphany-extensions phuang: awn-extras-applets pingou: R-BSgenome.Celegans.UCSC.ce2,R-BSgenome.Dmelanogaster.FlyBase.r51,R-hgu95av2probe pjones: cryptsetup-luks,grub pknirsch: openhpi pmatilai: compat-db psytux: beagle pvrabec: ntop,sectool rafalzaq: glob2 rakesh: anjuta,coredumper,gflags,ntop,opencv,pdf2djvu,svgalib rathann: freefem++,newsx,tachyon ravenoak: pysvn rdieter: Macaulay2,PyKDE,arts,gc,gnupg,jasper,kdebase3,kdelibs3,kdevelop,kdewebdev,kdnssd-avahi,kdnssd-avahi,konq-plugins,kopete-cryptography,libsigsegv,mathml-fonts,qzion,rsibreak rezso: gdal,iverilog rishi: anjuta,gengetopt,libchamplain rjones: mingw32-pango,ocaml-pa-do rmeggins: 389-ds-base,389-dsgw rmyers: eclipse-checkstyle robmv: svnkit roland: elfutils rrakus: cdrkit,python-docs ruben: Perlbal,gearmand s4504kr: kaya salimma: Django,Io-language,Io-language,fbreader,gedit-vala,nickle sandeen: guilt sconklin: gmfsk scop: vdr sharkcz: codeblocks,openhpi,python-openhpi simo: samba sindrepb: awn-extras-applets,gmfsk,gtranslator,xdotool skvidal: func smilner: Django spot: R-RODBC,R-RScaLAPACK,artwiz-aleczapka-fonts,asymptote,blacs,gbdfed,lout,mhash,nwsclient,perl-Email-MIME-Creator,perl-Email-MIME-Modifier,perl-Template-Plugin-Class,scalapack,xmbdfed ssp: libSM,libXtst steve: perl-IPC-Run,qtparted,uuid stingray: cuetools svahl: kdebase3,konq-plugins tadej: PyQwt tagoh: emacs-mew,knm_new-fonts tbreeds: libtopology tbzatek: gvfs,seahorse-plugins terjeros: e16-themes tgl: mysql than: arts,fonts-KOI8-R,kdebase3,kdelibs3,kdevelop,kdewebdev,konq-plugins,kopete-cryptography thias: synergy thl: gmime thm: python-py till: cryptsetup-luks tmraz: ipsec-tools tmz: tig tnorth: alliance,avr-binutils,avr-libc trasher: BackupPC trondd: avr-binutils,avr-libc tuxbrewr: arts,kdebase3,kdelibs3,kdevelop,kdewebdev,kdnssd-avahi,konq-plugins,squeak-vm twaugh: gutenprint uwog: asio verdurin: gnomint virtmaint: xen,xenner vpv: vdr wart: xpilot-ng whulbert: cryptsetup-luks wolfy: buffer xen-maint: xen xgl-maint: xorg-x11-drv-acecad,xorg-x11-drv-aiptek,xorg-x11-drv-elographics,xorg-x11-drv-fpit,xorg-x11-drv-glint,xorg-x11-drv-hyperpen,xorg-x11-drv-keyboard,xorg-x11-drv-mutouch,xorg-x11-drv-penmount,xorg-x11-xdm,xorg-x11-xsm xris: orpie xulchris: spambayes -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at dell.com Tue Jul 14 18:23:34 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 14 Jul 2009 13:23:34 -0500 Subject: Fedora rawhide rebuild in mock status 2009-07-10 i386 Message-ID: <20090714182334.GA2064@mock.linuxdev.us.dell.com> Fedora Rawhide-in-Mock Build Results for i386 using rawhide as of 10 July 2009. This is a full rebuild of all packages. Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ 1 Open Bugs which now build, and can be marked CLOSED RAWHIDE: ruby-rpm: [u'465103'] Total packages: 8005 Number failed to build: 352 Number expected to fail due to ExclusiveArch or ExcludeArch: 18 Leaving: 334 Of those expected to have worked... Without a bug filed: 330 ---------------------------------- Django-1.0.2-3.fc11 (build/make) salimma,smilner GtkAda-2.10.2-2.fc11 (build/make) gemi Io-language-20071010-10.fc11 (build/make) salimma,salimma PyQwt-5.1.0-3.fc11 (build/make) tadej PyX-0.10-6.fc11 (build/make) jamatos,jamatos,mpeters R-2.9.0-2.fc12 (build/make) spot R-BSgenome.Celegans.UCSC.ce2-1.2.0-5 (build/make) pingou R-BSgenome.Dmelanogaster.FlyBase.r51-1.3.1-3 (build/make) pingou R-RScaLAPACK-0.5.1-19.fc11 (build/make) spot R-hgu95av2probe-2.0.0-1.fc9 (build/make) pingou ScientificPython-2.8-4.fc11 (build/make) jspaleta SimGear-1.9.1-6.fc12 (build/make) spot,bellet UnihanDb-5.1.0-7.fc11.1 (build/make) dchen,i18n-team alexandria-0.6.4.1-6.fc11 (build/make) mtasaka almanah-0.5.0-1.fc11 (build/make) lokthare amanda-2.6.0p2-9.fc12 (build/make) dnovotny amora-1.1-4.fc11 (build/make) allisson anjuta-2.26.1.0-1.fc12 (build/make) rishi,rakesh anyremote-4.18.1-1.fc11 (build/make) anyremote apr-util-1.3.7-4.fc12 (build/make) jorton,bojan arm4-0.8.2-1.fc12 (build/make) grandcross,limb arts-1.5.10-5.fc11 (build/make) than,kkofler,rdieter,tuxbrewr asio-1.2.0-2.fc11 (build/make) uwog asterisk-sounds-core-1.4.15-1.fc11 (build/make) jcollie asymptote-1.73-1.fc12 (build/make) spot atlas-3.8.3-4.fc12 (build/make) deji,deji aubio-0.3.2-6.fc11 (build/make) green auriferous-1.0.1-7.fc11 (build/make) jwrdegoede avr-binutils-2.18-4.fc11 (build/make) tnorth,trondd avr-libc-1.6.4-4.fc12 (build/make) tnorth,trondd awn-extras-applets-0.3.2.1-8.fc11 (build/make) phuang,sindrepb axis-1.2.1-4.1.fc10 (build/make) pcheung babl-0.1.0-1.fc12 (build/make) deji,nphilipp baekmuk-bdf-fonts-2.2-7.fc11 (build/make) cchance,fonts-sig,i18n-team,petersen beagle-0.3.9-6.fc11 (build/make) orphan,drago01,psytux bigloo-3.1b-5.fc11 (build/make) gemi blacs-1.1-31.fc11 (build/make) spot bmpx-0.40.14-8.fc11 (build/make) akahl,cheese btrfs-progs-0.19-3.fc12 (build/make) josef,mmahut buffer-1.19-5.fc11 (build/make) bcornec,wolfy bug-buddy-2.27.1-2.fc12 (unpackaged_files/python-egg-info?) rstrode calf-0.0.18.5-1.fc12 (build/make) oget cdrkit-1.1.9-4.fc11 (build/make) rrakus cernlib-2006-32.fc11 (build/make) limb,pertusus chipmunk-4.1.0-6.fc11 (build/make) limb classpathx-jaf-1.0-12.fc10 (build/make) devrim,dwalluck clutter-cairo-0.8.2-3.fc11 (build/make) allisson clutter-cairomm-0.7.4-2.fc11 (build/make) denis clutter-gst-0.8.0-4.fc11 (build/make) allisson codeblocks-8.02-7.fc11 (build/make) sharkcz cogito-0.18.2-4.fc11 (build/make) chrisw compat-db-4.6.21-5.fc10 (build/make) jnovy,pmatilai compat-erlang-R10B-13.11.fc11 (build/make) gemi coredumper-1.2.1-8.fc12 (build/make) rakesh couchdb-0.9.0-2.fc12 (build/make) allisson cryptsetup-luks-1.0.7-0.1.fc12 (build/make) lvm-team,agk,dwysocha,mbroz,mornfall,pjones,till,whulbert cuetools-1.4.0-0.4.svn305.fc12 (build/make) stingray dap-hdf4_handler-3.7.9-2.fc11 (build/make) pertusus,pertusus dbus-c++-0.5.0-0.8.20090203git13281b3.fc11 (build/make) drago01 dev86-0.16.17-14.fc11 (build/make) jnovy devhelp-0.23-7.fc12 (build/make) mbarnes dietlibc-0.31-8.20090228.fc11 (build/make) ensc eclipse-cdt-5.0.2-2.fc11 (build/make) jjohnstn eclipse-checkstyle-4.0.1-12.fc11 (build/make) rmyers,akurtakov,overholt emacs-mew-6.2.51-2.fc11 (build/make) tagoh epiphany-extensions-2.26.1-2.fc12 (build/make) caillon,pgordon etherbat-1.0.1-5.fc11 (build/make) limb evolution-brutus-1.2.35-2.fc11 (build/make) bpepple evolution-data-server-2.27.3-3.fc12 (build/make) mbarnes,mbarnes,mcrha evolution-rss-0.1.2-9.fc12 (build/make) lucilanga evolution-zimbra-0.1.1-6.fc11 (build/make) mbarnes,mmahut fbreader-0.10.7-1.fc11 (build/make) salimma findbugs-1.3.8-1.fc11 (build/make) jjames fityk-0.8.1-14.fc10 (build/make) jpye fluidsynth-1.0.9-1.fc12 (build/make) green,oget fonts-ISO8859-2-1.0-20.fc11 (build/make) pnemade,fonts-sig,i18n-team,pnemade fonts-KOI8-R-1.0-11.fc11 (build/make) than,fonts-sig freefem++-3.0-5.5.fc11 (patch_fuzz) rathann,itamarjp fsarchiver-0.5.6-1.fc12 (build/make) drago01 fusecompress-2.5-1.fc12 (build/make) lkundrak,lmacken gauche-gl-0.4.4-4.fc11 (build/make) gemi gauche-gtk-0.4.1-18.fc11 (build/make) gemi gawk-3.1.6-5.fc11 (build/make) kasal gbdfed-1.4-2.fc11 (build/make) spot gc-7.1-7.fc11 (build/make) rdieter gcdmaster-1.2.2-5.fc11 (build/make) denis gcl-2.6.8-0.3.20090303cvs.fc12 (build/make) jjames,green gdal-1.6.0-8.fc11 (build/make) rezso,pertusus gearmand-0.7-1.fc12 (build/make) ruben gedit-vala-0.4.1-2.fc11 (build/make) salimma geronimo-specs-1.0-2.M2.fc10 (build/make) fnasser gflags-1.0-3.fc11 (build/make) rakesh gget-0.0.4-9.fc11 (build/make) ant glest-3.2.1-1.fc11 (build/make) abompard globus-common-10.2-5.fc12 (build/make) ellert globus-ftp-client-3.14-2.fc12 (build/make) ellert globus-gsi-openssl-error-0.14-3.fc12 (build/make) ellert globus-gssapi-error-2.5-3.fc12 (build/make) ellert globus-xio-2.7-4.fc12 (build/make) ellert globus-xio-gsi-driver-0.6-2.fc12 (build/make) ellert gloox-1.0-0.5.SVNr4003.fc12 (build/make) hubbitus gmfsk-0.7-0.6.pre1.fc11 (build/make) bjensen,bjensen,dp67,sconklin,sindrepb gmime-2.4.3-3.fc11 (build/make) alexl,thl gmime22-2.2.23-5.fc11 (build/make) bjohnson gmrun-0.9.2-16.fc11 (build/make) gilboa gnome-python2-extras-2.25.3-4.fc12 (build/make) mbarnes gnome-scan-0.6.2-1.fc11 (build/make) deji gnomint-0.9.1-5.fc12 (build/make) verdurin gnotime-2.3.0-3.fc11 (build/make) limb gnubversion-0.5-7.fc11 (build/make) laxathom gnuchess-5.07-12.fc11 (build/make) kaboom gnupg-1.4.9-5.fc11 (build/make) nalin,rdieter gnuradio-3.1.3-5.fc11 (build/make) mmahut,astronomy-sig gparted-0.4.5-1.fc12 (build/make) deji gromacs-4.0.4-2.fc11 (build/make) jussilehtola gspiceui-0.9.65-4.fc11 (build/make) laxathom,chitlesh gsynaptics-0.9.16-1.fc11 (build/make) ixs gt-0.4-8.fc11 (build/make) jwrdegoede gtkmm24-2.16.0-1.fc11 (build/make) denis gtranslator-1.9.5-1.fc12 (build/make) sindrepb,atorkhov guilt-0.32-3.fc11 (build/make) sandeen gutenprint-5.2.3-5.fc11 (unpackaged_files/python-egg-info?) twaugh gvfs-1.3.1-2.fc12 (build/make) tbzatek,alexl gwget-1.0.1-2.fc11 (build/make) cwickert hdf-4.2r4-2.fc11 (build/make) orion,pertusus hosts3d-0.98-1.fc11 (build/make) cassmodiah htmldoc-1.8.27-10.fc11 (build/make) agoode,pertusus hydrogen-0.9.4-0.3.rc1.1.fc11 (build/make) green,lkundrak,nando,oget hyphen-hsb-0.20080619-1.fc11 (build/make) caolanm iksemel-1.3-7.fc11 (build/make) jcollie insight-6.8-7.fc11 (build/make) monnerat,jkratoch ipsec-tools-0.7.2-1.fc12 (build/make) tmraz irda-utils-0.9.18-7.fc11 (build/make) karsten iverilog-0.9.20090423-4..fc11 (build/make) rezso,chitlesh jack-keyboard-2.5-2.fc12 (build/make) oget jack-rack-1.4.7-2.fc11 (build/make) kwizart,nando jasper-1.900.1-10.fc11 (build/make) rdieter java-1.6.0-openjdk-1.6.0.0-23.b16.fc12 (build/make) langel,dbhole,langel,lkundrak,mjw jeuclid-3.1.3-11.fc11 (buildroot) bashton jfsutils-1.1.13-5.fc11 (build/make) jwboyer jruby-1.1.6-3.fc11 (build/make) konradm k3d-0.7.11.0-1.fc12 (build/make) denis kaya-0.5.1-4.fc11 (build/make) s4504kr kdebase3-3.5.10-8.fc11 (build/make) than,jreznik,kkofler,ltinkl,rdieter,svahl,tuxbrewr kdelibs3-3.5.10-11.fc11 (build/make) than,kkofler,ltinkl,rdieter,tuxbrewr kdevelop-3.5.4-3.fc11 (build/make) than,kkofler,ltinkl,rdieter,tuxbrewr kdewebdev-3.5.10-2.fc11 (build/make) than,jreznik,kkofler,ltinkl,rdieter,tuxbrewr kdnssd-avahi-0.1.3-0.7.20080116svn.fc11 (build/make) rdieter,rdieter,tuxbrewr klear-0.7.0-2.svn113.fc10 (build/make) orphan knetstats-1.6.1-9.fc11 (build/make) chitlesh knm_new-fonts-1.1-5.fc11 (build/make) tagoh,fonts-sig,i18n-team kopete-cryptography-1.3.0-7.fc11 (build/make) jreznik,kkofler,ltinkl,rdieter,than kpolynome-0.1.2-13.fc11 (build/make) chitlesh ktechlab-0.3.70-1.20090304svn.fc11 (build/make) chitlesh labrea-2.5.1-2.fc10 (build/make) huzaifas lam-7.1.4-7.fc12 (build/make) dledford lash-0.5.4-5.fc12 (build/make) green,oget lasi-1.1.0-4.fc11 (build/make) orion ldapvi-1.7-8.fc11 (build/make) orphan libSM-1.1.0-4.fc11 (build/make) ssp libXtst-1.0.3-5.fc11 (build/make) ssp libbeagle-0.3.9-3.fc11 (build/make) mclasen libchamplain-0.2.9-1.fc11 (build/make) rishi libepc-0.3.10-1.fc12 (build/make) bpepple libfakekey-0.1-2.fc11 (build/make) mccann libgnomedb-3.99.7-3.fc11 (build/make) denis,denis,huzaifas libgnomeprint22-2.18.6-1.fc11 (build/make) behdad libibumad-1.3.1-1.fc12 (build/make) dledford libprojectM-1.2.0-9.fc11 (build/make) imntreal libprojectM-qt-1.2.0-5.fc11 (build/make) imntreal libsigsegv-2.6-2.fc11 (build/make) rdieter libsoup22-2.2.105-4.fc11 (build/make) mbarnes libsx-2.05-16.fc11 (build/make) kasal,pertusus libtar-1.2.11-11.fc10 (build/make) huzaifas,huzaifas libtheora-1.1alpha2-1.fc12 (build/make) ajax,jnovy,jwrdegoede libtopology-0.3-5.fc11 (build/make) tbreeds libunwind-0.99-0.10.20090430betagit4b8404d1.fc12 (build/make) jkratoch libvirt-cim-0.5.5-1.fc12 (build/make) danms,kaitlin linux-libertine-fonts-4.1.8-1.fc11 (build/make) farnold,fonts-sig,kevin linuxwacom-0.8.2.2-11.fc11 (build/make) arozansk lordsawar-0.1.5-2.fc11 (build/make) ianweller lout-3.38-2.fc11 (build/make) spot lxappearance-0.2.1-1.fc12 (build/make) cwickert lxlauncher-0.2.1-1.fc12 (build/make) cwickert lxsession-edit-0.1.1-1.fc12 (build/make) cwickert lxshortcut-0.1.1-1.fc12 (build/make) cwickert maildrop-2.0.4-9.fc11 (build/make) athimm matchbox-keyboard-0.1-0.2009.05.19.1.fc11 (build/make) mccann mathml-fonts-1.0-23.fc11 (build/make) rdieter,fonts-sig mcrypt-2.6.8-2.fc11 (build/make) spot mdbtools-0.6-0.6.cvs20051109.fc11.1 (build/make) jwrdegoede mingw32-wpcap-4.1.beta5-6.fc12 (build/make) sailer,rjones minicom-2.3-4.fc11 (build/make) mlichvar minirpc-0.3.2-3.fc11 (build/make) agoode mod_dnssd-0.6-2.fc11 (build/make) ivazquez,lennart monafont-2.90-8.fc11 (build/make) mtasaka mugshot-1.2.2-9.fc12 (build/make) otaylor multiget-1.2.0-5.fc11 (build/make) guidoledermann,mtasaka muse-1.0-0.6.rc3.fc12 (build/make) oget,nando museek+-0.2-1.fc11 (build/make) belegdol mysql-5.1.35-1.fc12 (build/make) tgl mysql-gui-tools-5.0r12-11.fc11 (build/make) ausil,hubbitus nautilus-actions-1.10.1-1.fc12 (build/make) deji netcdf-perl-1.2.3-9.fc11 (build/make) orion,perl-sig,pertusus newsx-1.6-11.fc11 (build/make) rathann,itamarjp ngspice-18-2.fc11 (build/make) chitlesh nickle-2.68-1.fc11 (build/make) salimma ntop-3.3.9-5.fc11 (build/make) rakesh,pvrabec nwsclient-1.6.3-3.fc11 (build/make) spot nx-3.3.0-35.fc12 (build/make) athimm,limb ocaml-libvirt-0.6.1.0-3.fc12 (build/make) rjones,ocamlmaint,virtmaint ocaml-pa-do-0.8.9-2.fc12 (build/make) rjones ocfs2-tools-1.3.9-10.20080221git.fc11 (build/make) mfasheh,fabbione,mfasheh oorexx-3.2.0-4.fc9 (build/make) gemi opencv-1.1.0-0.1.pre1.fc12.1 (build/make) rakesh,kwizart,nomis80 openhpi-2.14.0-2.fc12 (build/make) sharkcz,pknirsch orpie-1.5.1-4.fc10 (build/make) xris orsa-0.7.0-8.fc11 (build/make) mjakubicek,mmahut paraview-3.4.0-4.fc11 (build/make) orion,pertusus parted-1.8.8-17.fc11 (build/make) jgranado pcmanx-gtk2-0.3.8-5.fc11 (build/make) orphan pdf2djvu-0.5.0-3.fc12 (build/make) rakesh pdns-recursor-3.1.7-4.fc11 (build/make) ruben perl-AnyEvent-XMPP-0.4-1.fc11 (build/make) allisson,perl-sig perl-Bio-Graphics-1.94-1.fc12 (build/make) alexlan,perl-sig perl-DBIx-Class-Schema-Loader-0.04005-3.fc11 (build/make) cweyl,perl-sig perl-Email-MIME-Creator-1.455-1.fc11 (build/make) spot,perl-sig perl-Email-MIME-Modifier-1.443-2.fc11 (build/make) spot,perl-sig perl-HTML-FormFu-Model-DBIC-0.03007-1.fc11 (build/make) cweyl,perl-sig perl-Log-Log4perl-1.20-3.fc11 (build/make) kasal,mmaslano,perl-sig perl-Mail-Box-2.087-1.fc11 (build/make) spot,perl-sig perl-MooseX-AttributeHelpers-0.19-1.fc12 (build/make) cweyl,perl-sig perl-MooseX-Daemonize-0.08-3.fc11 (build/make) allisson perl-MooseX-Getopt-0.18-1.fc12 (build/make) cweyl,perl-sig perl-MooseX-POE-0.204-1.fc12 (build/make) allisson perl-MooseX-Role-Parameterized-0.09-2.fc12 (build/make) cweyl,perl-sig perl-MooseX-Traits-Attribute-CascadeClear-0.03-2.fc11 (build/make) cweyl,perl-sig perl-PDL-2.4.4-3.fc11 (build/make) kasal,mmaslano,orion perl-POE-Component-Server-SimpleHTTP-1.48-2.fc11 (build/make) cweyl,perl-sig perl-SQL-Statement-1.15-5.fc11 (build/make) kasal,mmaslano,perl-sig perl-SVN-Mirror-0.75-2.fc11 (build/make) iburrell,perl-sig perl-SVN-Simple-0.27-7.fc11 (build/make) iburrell,perl-sig perl-Sys-Virt-0.2.0-2.fc11 (build/make) steve,berrange,perl-sig perl-Template-Plugin-Class-0.13-6.fc11 (build/make) spot,perl-sig perl-Test-AutoBuild-1.2.2-7.fc11 (build/make) berrange perl-Tie-IxHash-1.21-9.fc11 (build/make) spot,perl-sig pg_top-3.6.2-4.fc11 (build/make) itamarjp phasex-0.11.1-6.fc11 (build/make) green pmount-0.9.17-4.fc11 (build/make) kasal,jpmahowa,pertusus projectM-jack-1.2.0-5.fc11 (build/make) imntreal projectM-libvisual-1.2.0-5.fc11 (build/make) imntreal projectM-pulseaudio-1.2.0-4.fc11 (build/make) imntreal protobuf-2.0.2-8.fc11 (build/make) abbot pyclutter-0.8.2-2.fc11 (build/make) allisson pygame-1.8.1-6.fc12 (build/make) xulchris pygoocanvas-0.14.0-1.fc12 (build/make) bjohnson pygsl-0.9.3-4.fc11 (build/make) jamatos pypar-2.1.0_66-3.fc10 (build/make) jussilehtola pysvn-1.6.3-2.fc11 (build/make) ravenoak python-basemap-0.99.2-3.fc11 (build/make) jspaleta python-docs-2.6-2.fc11 (build/make) james,ivazquez,rrakus python-openhpi-1.1-3.fc11 (build/make) sharkcz python-py-0.9.2-7.fc11 (build/make) thm python-pylons-0.9.7-0.2.rc4.fc11 (build/make) kylev python-tftpy-0.4.6-3.fc11 (build/make) ivaxer qtiplot-0.9-11.fc11 (build/make) frankb qtparted-0.4.5-19.fc11 (build/make) steve qzion-0.4.0-1.fc11 (build/make) john5342,rdieter ragel-6.3-2.fc11 (build/make) jjh ratpoison-1.4.4-3.fc12 (build/make) kevin,kevin rcssserver3d-0.6.1-4.fc12 (build/make) hedayat readahead-1.4.9-1.fc11 (build/make) harald,harald rsibreak-0.9.0-10.fc11 (build/make) liquidat,rdieter safekeep-1.0.5-2.fc11 (build/make) jspaleta samba-3.4.0-0pre1.37.fc12 (build/make) simo,gd sane-frontends-1.0.14-6.fc11 (build/make) nphilipp scalapack-1.7.5-5.fc11 (build/make) spot seahorse-plugins-2.27.1-1.fc12 (build/make) mclasen,tbzatek sectool-0.9.3-1.fc12 (build/make) pvrabec,jhrozek,mildew sems-1.1.0-7.fc12 (build/make) peter,ondrejj seq24-0.8.7-15.fc11 (build/make) green showimg-0.9.5-22.fc11 (build/make) abompard siril-0.8-7.fc11 (build/make) mmahut smart-1.2-64.fc12 (build/make) athimm spambayes-1.0.4-7.fc11 (build/make) xulchris squeak-vm-3.10.4-4.fc11 (build/make) gavin,tuxbrewr supertuxkart-0.6.1-2.fc11 (build/make) limb svgalib-1.9.25-6.fc11 (build/make) rakesh,orion svnkit-1.2.3-1.fc11 (build/make) robmv,akurtakov syck-0.61-8.2.fc11 (build/make) oliver synergy-1.3.1-12.fc11 (build/make) thias t1utils-1.33-2.fc11 (build/make) jamatos tachyon-0.98.1-1.fc11 (build/make) rathann,itamarjp tcl-8.5.6-6.fc11 (build/make) mmaslano testdisk-6.11-3.fc12 (build/make) grenier tig-0.14.1-1.fc11 (build/make) jbowes,jcollie,tmz tor-0.2.0.34-3.fc11 (build/make) ensc,cassmodiah towhee-6.2.3-5.fc10 (build/make) jussilehtola ucblogo-6.0-4.fc11 (build/make) gemi unifdef-1.171-8.fc11 (build/make) dwmw2,jaswinder util-vserver-0.30.215-7.fc11 (build/make) ensc uuid-1.6.1-6.fc12 (build/make) steve varnish-2.0.4-2.fc12 (build/make) ingvar w3c-libwww-5.4.1-0.15.20060206cvs.fc11 (build/make) awjb widelands-0-0.13.Build13.fc11 (build/make) karlik wise2-2.2.0-5.fc11 (build/make) alexlan xastir-1.9.4-8.fc12 (build/make) lucilanga,bjensen xdotool-20090330-3.fc12 (build/make) sindrepb xen-3.4.0-2.fc12 (build/make) xen-maint,berrange,kraxel,virtmaint xenner-0.47-1.fc12 (build/make) kraxel,berrange,itamarjp,virtmaint xine-ui-0.99.5-11.fc12 (build/make) jussilehtola xmbdfed-4.7-4.fc11 (build/make) spot xmlcopyeditor-1.1.0.6-4.fc9 (build/make) ivazquez xorg-x11-drv-acecad-1.3.0-1.fc11 (build/make) xgl-maint xorg-x11-drv-aiptek-1.2.0-1.fc11 (build/make) xgl-maint xorg-x11-drv-elographics-1.2.3-2.fc11 (build/make) xgl-maint xorg-x11-drv-fpit-1.3.0-2.fc11 (build/make) xgl-maint xorg-x11-drv-hyperpen-1.3.0-1.fc11 (build/make) xgl-maint xorg-x11-drv-keyboard-1.3.2-3.fc11 (build/make) xgl-maint xorg-x11-drv-mutouch-1.2.1-2.fc11 (build/make) xgl-maint xorg-x11-drv-penmount-1.4.0-2.fc11 (build/make) xgl-maint xorg-x11-drv-radeonhd-1.2.5-2.8.20090411git.fc11 (build/make) ndim,ajax xorg-x11-xdm-1.1.6-10.fc12 (build/make) xgl-maint,pertusus xorg-x11-xsm-1.0.2-9.fc11 (build/make) xgl-maint xpilot-ng-4.7.2-16.fc11 (build/make) wart xqilla-2.1.3-0.6.fc11 (build/make) mzazrive xqilla10-1.0.2-6.fc11 (build/make) mzazrive xsane-0.996-7.fc11 (build/make) nphilipp yap-5.1.1-13.fc11 (build/make) gemi zynaddsubfx-2.2.1-20.fc11 (build/make) green With bugs filed: 4 ---------------------------------- httping-1.2.9-4.fc11 [u'502430 NEW'] (build/make) fab libFoundation-1.1.3-11.fc9 [u'440564 ASSIGNED'] (build/make) athimm perl-RRD-Simple-1.43-3.fc9 [u'464964 ASSIGNED'] (build/make) cweyl,perl-sig smarteiffel-2.3-2.fc9 [u'464923 ASSIGNED'] (build/make) gemi ---------------------------------- Packages by owner: abbot: protobuf abompard: glest,showimg agk: cryptsetup-luks agoode: htmldoc,minirpc ajax: libtheora,xorg-x11-drv-radeonhd akahl: bmpx akurtakov: eclipse-checkstyle,svnkit alexl: gmime,gvfs alexlan: perl-Bio-Graphics,wise2 allisson: amora,clutter-cairo,clutter-gst,couchdb,perl-AnyEvent-XMPP,perl-MooseX-Daemonize,perl-MooseX-POE,pyclutter ant: gget anyremote: anyremote arozansk: linuxwacom astronomy-sig: gnuradio athimm: libFoundation,maildrop,nx,smart atorkhov: gtranslator ausil: mysql-gui-tools awjb: w3c-libwww bashton: jeuclid bcornec: buffer behdad: libgnomeprint22 belegdol: museek+ bellet: SimGear berrange: perl-Sys-Virt,perl-Test-AutoBuild,xen,xenner bjensen: gmfsk,gmfsk,xastir bjohnson: gmime22,pygoocanvas bojan: apr-util bpepple: evolution-brutus,libepc caillon: epiphany-extensions caolanm: hyphen-hsb cassmodiah: hosts3d,tor cchance: baekmuk-bdf-fonts cheese: bmpx chitlesh: gspiceui,iverilog,knetstats,kpolynome,ktechlab,ngspice chrisw: cogito cweyl: perl-DBIx-Class-Schema-Loader,perl-HTML-FormFu-Model-DBIC,perl-MooseX-AttributeHelpers,perl-MooseX-Getopt,perl-MooseX-Role-Parameterized,perl-MooseX-Traits-Attribute-CascadeClear,perl-POE-Component-Server-SimpleHTTP,perl-RRD-Simple cwickert: gwget,lxappearance,lxlauncher,lxsession-edit,lxshortcut danms: libvirt-cim dbhole: java-1.6.0-openjdk dchen: UnihanDb deji: atlas,atlas,babl,gnome-scan,gparted,nautilus-actions denis: clutter-cairomm,gcdmaster,gtkmm24,k3d,libgnomedb,libgnomedb devrim: classpathx-jaf dledford: lam,libibumad dnovotny: amanda dp67: gmfsk drago01: beagle,dbus-c++,fsarchiver dwalluck: classpathx-jaf dwmw2: unifdef dwysocha: cryptsetup-luks ellert: globus-common,globus-ftp-client,globus-gsi-openssl-error,globus-gssapi-error,globus-xio,globus-xio-gsi-driver ensc: dietlibc,tor,util-vserver fab: httping fabbione: ocfs2-tools farnold: linux-libertine-fonts fnasser: geronimo-specs fonts-sig: baekmuk-bdf-fonts,fonts-ISO8859-2,fonts-KOI8-R,knm_new-fonts,linux-libertine-fonts,mathml-fonts frankb: qtiplot gavin: squeak-vm gd: samba gemi: GtkAda,bigloo,compat-erlang,gauche-gl,gauche-gtk,oorexx,smarteiffel,ucblogo,yap gilboa: gmrun grandcross: arm4 green: aubio,fluidsynth,gcl,hydrogen,lash,phasex,seq24,zynaddsubfx grenier: testdisk guidoledermann: multiget harald: readahead,readahead hedayat: rcssserver3d hubbitus: gloox,mysql-gui-tools huzaifas: labrea,libgnomedb,libtar,libtar i18n-team: UnihanDb,baekmuk-bdf-fonts,fonts-ISO8859-2,knm_new-fonts ianweller: lordsawar iburrell: perl-SVN-Mirror,perl-SVN-Simple imntreal: libprojectM,libprojectM-qt,projectM-jack,projectM-libvisual,projectM-pulseaudio ingvar: varnish itamarjp: freefem++,newsx,pg_top,tachyon,xenner ivaxer: python-tftpy ivazquez: mod_dnssd,python-docs,xmlcopyeditor ixs: gsynaptics jamatos: PyX,PyX,pygsl,t1utils james: python-docs jaswinder: unifdef jbowes: tig jcollie: asterisk-sounds-core,iksemel,tig jgranado: parted jhrozek: sectool jjames: findbugs,gcl jjh: ragel jjohnstn: eclipse-cdt jkratoch: insight,libunwind jnovy: compat-db,dev86,libtheora john5342: qzion jorton: apr-util josef: btrfs-progs jpmahowa: pmount jpye: fityk jreznik: kdebase3,kdewebdev,kopete-cryptography jspaleta: ScientificPython,python-basemap,safekeep jussilehtola: gromacs,pypar,towhee,xine-ui jwboyer: jfsutils jwrdegoede: auriferous,gt,libtheora,mdbtools kaboom: gnuchess kaitlin: libvirt-cim karlik: widelands karsten: irda-utils kasal: gawk,libsx,perl-Log-Log4perl,perl-PDL,perl-SQL-Statement,pmount kevin: linux-libertine-fonts,ratpoison,ratpoison kkofler: arts,kdebase3,kdelibs3,kdevelop,kdewebdev,kopete-cryptography konradm: jruby kraxel: xen,xenner kwizart: jack-rack,opencv kylev: python-pylons langel: java-1.6.0-openjdk,java-1.6.0-openjdk laxathom: gnubversion,gspiceui lennart: mod_dnssd limb: arm4,cernlib,chipmunk,etherbat,gnotime,nx,supertuxkart liquidat: rsibreak lkundrak: fusecompress,hydrogen,java-1.6.0-openjdk lmacken: fusecompress lokthare: almanah ltinkl: kdebase3,kdelibs3,kdevelop,kdewebdev,kopete-cryptography lucilanga: evolution-rss,xastir lvm-team: cryptsetup-luks mbarnes: devhelp,evolution-data-server,evolution-data-server,evolution-zimbra,gnome-python2-extras,libsoup22 mbroz: cryptsetup-luks mccann: libfakekey,matchbox-keyboard mclasen: libbeagle,seahorse-plugins mcrha: evolution-data-server mfasheh: ocfs2-tools,ocfs2-tools mildew: sectool mjakubicek: orsa mjw: java-1.6.0-openjdk mlichvar: minicom mmahut: btrfs-progs,evolution-zimbra,gnuradio,orsa,siril mmaslano: perl-Log-Log4perl,perl-PDL,perl-SQL-Statement,tcl monnerat: insight mornfall: cryptsetup-luks mpeters: PyX mtasaka: alexandria,monafont,multiget mzazrive: xqilla,xqilla10 nalin: gnupg nando: hydrogen,jack-rack,muse ndim: xorg-x11-drv-radeonhd nomis80: opencv nphilipp: babl,sane-frontends,xsane ocamlmaint: ocaml-libvirt oget: calf,fluidsynth,hydrogen,jack-keyboard,lash,muse oliver: syck ondrejj: sems orion: hdf,lasi,netcdf-perl,paraview,perl-PDL,svgalib orphan: beagle,klear,ldapvi,pcmanx-gtk2 otaylor: mugshot overholt: eclipse-checkstyle pcheung: axis perl-sig: netcdf-perl,perl-AnyEvent-XMPP,perl-Bio-Graphics,perl-DBIx-Class-Schema-Loader,perl-Email-MIME-Creator,perl-Email-MIME-Modifier,perl-HTML-FormFu-Model-DBIC,perl-Log-Log4perl,perl-Mail-Box,perl-MooseX-AttributeHelpers,perl-MooseX-Getopt,perl-MooseX-Role-Parameterized,perl-MooseX-Traits-Attribute-CascadeClear,perl-POE-Component-Server-SimpleHTTP,perl-RRD-Simple,perl-SQL-Statement,perl-SVN-Mirror,perl-SVN-Simple,perl-Sys-Virt,perl-Template-Plugin-Class,perl-Tie-IxHash pertusus: cernlib,dap-hdf4_handler,dap-hdf4_handler,gdal,hdf,htmldoc,libsx,netcdf-perl,paraview,pmount,xorg-x11-xdm peter: sems petersen: baekmuk-bdf-fonts pgordon: epiphany-extensions phuang: awn-extras-applets pingou: R-BSgenome.Celegans.UCSC.ce2,R-BSgenome.Dmelanogaster.FlyBase.r51,R-hgu95av2probe pjones: cryptsetup-luks pknirsch: openhpi pmatilai: compat-db pnemade: fonts-ISO8859-2,fonts-ISO8859-2 psytux: beagle pvrabec: ntop,sectool rakesh: anjuta,coredumper,gflags,ntop,opencv,pdf2djvu,svgalib rathann: freefem++,newsx,tachyon ravenoak: pysvn rdieter: arts,gc,gnupg,jasper,kdebase3,kdelibs3,kdevelop,kdewebdev,kdnssd-avahi,kdnssd-avahi,kopete-cryptography,libsigsegv,mathml-fonts,qzion,rsibreak rezso: gdal,iverilog rishi: anjuta,libchamplain rjones: mingw32-wpcap,ocaml-libvirt,ocaml-pa-do rmyers: eclipse-checkstyle robmv: svnkit rrakus: cdrkit,python-docs rstrode: bug-buddy ruben: gearmand,pdns-recursor s4504kr: kaya sailer: mingw32-wpcap salimma: Django,Io-language,Io-language,fbreader,gedit-vala,nickle sandeen: guilt sconklin: gmfsk sharkcz: codeblocks,openhpi,python-openhpi simo: samba sindrepb: awn-extras-applets,gmfsk,gtranslator,xdotool smilner: Django spot: R,R-RScaLAPACK,SimGear,asymptote,blacs,gbdfed,lout,mcrypt,nwsclient,perl-Email-MIME-Creator,perl-Email-MIME-Modifier,perl-Mail-Box,perl-Template-Plugin-Class,perl-Tie-IxHash,scalapack,xmbdfed ssp: libSM,libXtst steve: perl-Sys-Virt,qtparted,uuid stingray: cuetools svahl: kdebase3 tadej: PyQwt tagoh: emacs-mew,knm_new-fonts tbreeds: libtopology tbzatek: gvfs,seahorse-plugins tgl: mysql than: arts,fonts-KOI8-R,kdebase3,kdelibs3,kdevelop,kdewebdev,kopete-cryptography thias: synergy thl: gmime thm: python-py till: cryptsetup-luks tmraz: ipsec-tools tmz: tig tnorth: avr-binutils,avr-libc trondd: avr-binutils,avr-libc tuxbrewr: arts,kdebase3,kdelibs3,kdevelop,kdewebdev,kdnssd-avahi,squeak-vm twaugh: gutenprint uwog: asio verdurin: gnomint virtmaint: ocaml-libvirt,xen,xenner wart: xpilot-ng whulbert: cryptsetup-luks wolfy: buffer xen-maint: xen xgl-maint: xorg-x11-drv-acecad,xorg-x11-drv-aiptek,xorg-x11-drv-elographics,xorg-x11-drv-fpit,xorg-x11-drv-hyperpen,xorg-x11-drv-keyboard,xorg-x11-drv-mutouch,xorg-x11-drv-penmount,xorg-x11-xdm,xorg-x11-xsm xris: orpie xulchris: pygame,spambayes -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From nushio at fedoraproject.org Tue Jul 14 18:23:33 2009 From: nushio at fedoraproject.org (Juan Rodriguez) Date: Tue, 14 Jul 2009 13:23:33 -0500 Subject: Purging the F12 orphans In-Reply-To: <1247594323.3073.1169.camel@localhost.localdomain> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> Message-ID: On Tue, Jul 14, 2009 at 12:58 PM, Jesse Keating wrote: > Unblocked orphan glipper > If noone's taking care of glipper, I'll have to sign up, as I actually *depend* on glipper to function properly. Co-maintainers welcome. -- Ing. Juan M. Rodriguez Moreno Desarrollador de Sistemas Abiertos Sitio: http://proyectofedora.org/mexico -------------- next part -------------- An HTML attachment was scrubbed... URL: From frankly3d at gmail.com Tue Jul 14 18:24:12 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Tue, 14 Jul 2009 19:24:12 +0100 Subject: Purging the F12 orphans In-Reply-To: <200907141420.35036.rjune@bravegnuworld.com> References: <1247589637.3073.1162.camel@localhost.localdomain> <200907141420.35036.rjune@bravegnuworld.com> Message-ID: <4A5CCD4C.2030200@gmail.com> On 14/07/09 19:20, Richard June wrote: > I use azureus, and if it's reasonably popular, I'll happily maintain the > package. Is there information on whether or not people actually install these > packages? > I use it. That's as far as it goes at the moment. (keeps my ISP happy) Is there anyway to gauge a download popularity? Regards, Frank From mschwendt at gmail.com Tue Jul 14 18:31:36 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 14 Jul 2009 20:31:36 +0200 Subject: rpms/bmpx/devel bmpx-compile.patch,1.1,1.2 bmpx.spec,1.20,1.21 In-Reply-To: <20090714145217.0907511C0497@cvs1.fedora.phx.redhat.com> References: <20090714145217.0907511C0497@cvs1.fedora.phx.redhat.com> Message-ID: <20090714203136.3f9f0515@faldor> On Tue, 14 Jul 2009 14:52:17 +0000 (UTC), Caolan wrote: > Author: caolanm > > Update of /cvs/pkgs/rpms/bmpx/devel > In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv18298 > > Modified Files: > bmpx-compile.patch bmpx.spec > Log Message: > Resolves: rhbz#489552 fix to compile > bmpx-compile.patch: bmpx on Fedora 11 is broken and needs a rebuild for Cairo, too: https://bugzilla.redhat.com/511333#c1 From rjones at redhat.com Tue Jul 14 18:26:13 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 14 Jul 2009 19:26:13 +0100 Subject: Fedora rawhide rebuild in mock status 2009-07-10 x86_64 In-Reply-To: <20090714182235.GA1967@mock.linuxdev.us.dell.com> References: <20090714182235.GA1967@mock.linuxdev.us.dell.com> Message-ID: <20090714182613.GA31836@amd.home.annexia.org> On Tue, Jul 14, 2009 at 01:22:35PM -0500, Matt Domsch wrote: > ocaml-pa-do-0.8.9-2.fc12 (build/make) rjones I checked your logfiles and it seems to have built fine on both architectures ... Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From limb at jcomserv.net Tue Jul 14 18:32:23 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 14 Jul 2009 13:32:23 -0500 Subject: Fedora rawhide rebuild in mock status 2009-07-10 x86_64 In-Reply-To: <20090714182613.GA31836@amd.home.annexia.org> References: <20090714182235.GA1967@mock.linuxdev.us.dell.com> <20090714182613.GA31836@amd.home.annexia.org> Message-ID: <4A5CCF37.3010706@jcomserv.net> Richard W.M. Jones wrote: > On Tue, Jul 14, 2009 at 01:22:35PM -0500, Matt Domsch wrote: > >> ocaml-pa-do-0.8.9-2.fc12 (build/make) rjones >> > > I checked your logfiles and it seems to have built fine on > both architectures ... > > Rich. > > Yeah, some of mine built and some didn't. Not sure. . . -- in your fear, speak only peace in your fear, seek only love -d. bowie From jussilehtola at fedoraproject.org Tue Jul 14 18:36:12 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Tue, 14 Jul 2009 21:36:12 +0300 Subject: Something amock with rawhide? Message-ID: <1247596572.3550.2.camel@localhost.localdomain> Hello, is something still haywire in rawhide? My build of Octave 3.2.0 hangs on i586 with *** glibc detected *** pdfetex: malloc(): memory corruption: 0x09a3c3a0 *** The package builds fine in x86_64 and ppc{,64}. http://koji.fedoraproject.org/koji/taskinfo?taskID=1473079 <- task root http://koji.fedoraproject.org/koji/getfile?taskID=1473086&name=build.log -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From mschwendt at gmail.com Tue Jul 14 18:45:44 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 14 Jul 2009 20:45:44 +0200 Subject: NVR bugs in rawhide In-Reply-To: <1247593620.2607.7.camel@localhost.localdomain> References: <4A5C3FF9.3010903@redhat.com> <20090714111532.4b688163@faldor> <4A5C7848.20608@redhat.com> <20090714144853.19816cfc@faldor> <1247575691.3164.2.camel@politzer.theorphys.helsinki.fi> <20090714153737.785463f7@faldor> <1247579666.3164.5.camel@politzer.theorphys.helsinki.fi> <20090714172325.4f54113f@faldor> <1247587729.3164.12.camel@politzer.theorphys.helsinki.fi> <20090714183943.3d2e8397@faldor> <1247593620.2607.7.camel@localhost.localdomain> Message-ID: <20090714204544.34108796@faldor> On Tue, 14 Jul 2009 20:47:00 +0300, Jussi wrote: > [...] packages that are compiled in some way *really should* use the > %{?dist} tag, since that way they are upgraded when the distribution is > upgraded. They are only upgraded if somebody (or something) bumps'n'rebuilds them, including a spec file %changelog for the new %release value and a new tag in cvs. One cannot rebuild for a changed %{dist} value without creating a corresponding cvs tag first. One cannot rebuild an unchanged NEVR with an unchanged [old] cvs tag, because koji rejects such build requests. For a package whose %version value makes bigger jump mostly or only during the Rawhide cycle, one doesn't need anything like %dist but can use RPM's %release everywhere for that pkg just fine. > (Or it can be easily seen that the compilation is obsolete.) Only if you insist on relying on %dist instead of examining RPM's "Build Date" values (or equivalent values in koji) or file timestamps, which are more accurate. From Matt_Domsch at dell.com Tue Jul 14 18:40:45 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 14 Jul 2009 13:40:45 -0500 Subject: Fedora rawhide rebuild in mock status 2009-07-10 x86_64 In-Reply-To: <20090714182613.GA31836@amd.home.annexia.org> References: <20090714182235.GA1967@mock.linuxdev.us.dell.com> <20090714182613.GA31836@amd.home.annexia.org> Message-ID: <20090714184045.GA32522@auslistsprd01.us.dell.com> On Tue, Jul 14, 2009 at 07:26:13PM +0100, Richard W.M. Jones wrote: > On Tue, Jul 14, 2009 at 01:22:35PM -0500, Matt Domsch wrote: > > ocaml-pa-do-0.8.9-2.fc12 (build/make) rjones > > I checked your logfiles and it seems to have built fine on > both architectures ... I jumped the gun a bit; the results are still syncing out to the website. I'll repost soon as I see the sync is finished. In this case, on i386 it timed out after 6 hours. On x86_64 the build did fail. *** omake: 54/59 targets are up to date *** omake: failed (3.15 sec, 1/1 scans, 2/2 rules, 1/143 digests) *** omake: targets were not rebuilt because of errors: depends on: doc/user-meeting09/talk.tex error: Bad exit status from /var/tmp/rpm-tmp.6gXu5M (%build) Bad exit status from /var/tmp/rpm-tmp.6gXu5M (%build) -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From forum at hubbitus.com.ru Tue Jul 14 18:50:40 2009 From: forum at hubbitus.com.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Tue, 14 Jul 2009 14:50:40 -0400 Subject: Purging the F12 orphans In-Reply-To: <1247594323.3073.1169.camel@localhost.localdomain> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> Message-ID: <4A5CD380.9020002@ru.bir.ru> 14.07.2009 13:58, Jesse Keating ?????: > On Tue, 2009-07-14 at 09:40 -0700, Jesse Keating wrote: > >> It's that time of the release cycle again, to purge the orphans before >> we get to feature freeze. Any unblocked orphans will be purged by the >> 28th of this month. Here is a current list of unblocked orphans: >> > > The first list was incomplete due to an API change. Here is the > complete list: > [snip] > Unblocked orphan js > Strange. It is my package. I again take ownership over it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpierce at redhat.com Tue Jul 14 19:00:14 2009 From: dpierce at redhat.com (Darryl L. Pierce) Date: Tue, 14 Jul 2009 15:00:14 -0400 Subject: Problem with ruby package with binary content... In-Reply-To: <20090714181420.GE3432@mcpierce-laptop.rdu.redhat.com> References: <20090714152320.GB3432@mcpierce-laptop.rdu.redhat.com> <4A5CB60B.8010801@ioa.s.u-tokyo.ac.jp> <20090714172851.GC3432@mcpierce-laptop.rdu.redhat.com> <20090714181420.GE3432@mcpierce-laptop.rdu.redhat.com> Message-ID: <20090714190014.GH3432@mcpierce-laptop.rdu.redhat.com> On Tue, Jul 14, 2009 at 02:14:20PM -0400, Darryl L. Pierce wrote: > Shoot, spoke way too soon. I had reset the spec file to remove where I > had been experimenting with some fixes, and didn't remove the strip > line. So I ran it with the changes you posted and with the strip line > there and it worked. I removed the strip line and a different error came > up now. The problem is now with pathing and not finding the .so file. Okay, the pathing problem is fixed. Doing the following fixed the problem: ---8<[snip]--- %global workdir %(mktemp -d) ... gem install --local --install-dir %{workdir} \ --force -V --rdoc %{SOURCE0} cp -ra %{workdir}/* %{buildroot}%{gemdir} ---8<[snip]--- Things are now working fine with the non-stripped binaries. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Virtual Machine Management - http://www.ovirt.org/ Is fearr Gaeilge bhriste n? B?arla cliste. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From christoph.wickert at googlemail.com Tue Jul 14 19:01:26 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Tue, 14 Jul 2009 21:01:26 +0200 Subject: glipper (was Re: Purging the F12 orphans) In-Reply-To: References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> Message-ID: <1247598086.15109.264.camel@localhost> Am Dienstag, den 14.07.2009, 13:23 -0500 schrieb Juan Rodriguez: > > On Tue, Jul 14, 2009 at 12:58 PM, Jesse Keating > wrote: > Unblocked orphan glipper > > If noone's taking care of glipper, I'll have to sign up, as I actually > *depend* on glipper to function properly. Well, then you are lost, as it's broken for ages, see https://bugzilla.redhat.com/show_bug.cgi?id=449890 I think the program is dead upstream. Use parcelite instead. Regards, Christoph From christoph.wickert at googlemail.com Tue Jul 14 19:03:31 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Tue, 14 Jul 2009 21:03:31 +0200 Subject: Purging the F12 orphans In-Reply-To: <870180fe0907141027u7de31e4ct7a07a8c494bca031@mail.gmail.com> References: <1247589637.3073.1162.camel@localhost.localdomain> <870180fe0907141027u7de31e4ct7a07a8c494bca031@mail.gmail.com> Message-ID: <1247598211.15109.267.camel@localhost> Am Dienstag, den 14.07.2009, 11:27 -0600 schrieb Jerry James: > On Tue, Jul 14, 2009 at 10:40 AM, Jesse Keating > wrote: > ... > Unblocked orphan fmit > > Are there really none that start with g-z, or did something quit after > fmit? Yes, there was a new list sent out to fedora-devel-announce. Regards, Christoph From cemeyer at u.washington.edu Tue Jul 14 19:08:19 2009 From: cemeyer at u.washington.edu (Conrad Meyer) Date: Tue, 14 Jul 2009 12:08:19 -0700 Subject: glipper (was Re: Purging the F12 orphans) In-Reply-To: <1247598086.15109.264.camel@localhost> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247598086.15109.264.camel@localhost> Message-ID: <200907141208.20100.cemeyer@u.washington.edu> On Tuesday 14 July 2009 12:01:26 pm Christoph Wickert wrote: > Am Dienstag, den 14.07.2009, 13:23 -0500 schrieb Juan Rodriguez: > > On Tue, Jul 14, 2009 at 12:58 PM, Jesse Keating > > wrote: > > Unblocked orphan glipper > > > > If noone's taking care of glipper, I'll have to sign up, as I actually > > *depend* on glipper to function properly. > > Well, then you are lost, as it's broken for ages, see > https://bugzilla.redhat.com/show_bug.cgi?id=449890 > > I think the program is dead upstream. Use parcelite instead. > > Regards, > Christoph I had more trouble than I should have googling this one -- it's parcellite[0]. [0]: http://parcellite.sourceforge.net/ Regards, -- Conrad Meyer From nushio at fedoraproject.org Tue Jul 14 19:14:52 2009 From: nushio at fedoraproject.org (Juan Rodriguez) Date: Tue, 14 Jul 2009 14:14:52 -0500 Subject: glipper (was Re: Purging the F12 orphans) In-Reply-To: <200907141208.20100.cemeyer@u.washington.edu> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247598086.15109.264.camel@localhost> <200907141208.20100.cemeyer@u.washington.edu> Message-ID: On Tue, Jul 14, 2009 at 2:08 PM, Conrad Meyer wrote: > On Tuesday 14 July 2009 12:01:26 pm Christoph Wickert wrote: > > Am Dienstag, den 14.07.2009, 13:23 -0500 schrieb Juan Rodriguez: > > > On Tue, Jul 14, 2009 at 12:58 PM, Jesse Keating > > > wrote: > > > Unblocked orphan glipper > > > > > > If noone's taking care of glipper, I'll have to sign up, as I actually > > > *depend* on glipper to function properly. > > > > Well, then you are lost, as it's broken for ages, see > > https://bugzilla.redhat.com/show_bug.cgi?id=449890 > > > > I think the program is dead upstream. Use parcelite instead. > > > > Regards, > > Christoph > > I had more trouble than I should have googling this one -- it's > parcellite[0]. > > [0]: http://parcellite.sourceforge.net/ > > Regards, > -- > Conrad Meyer > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Thanks, I just installed it, I think I'll use this instead. glipper might be dead, but it still works on Fedora 11. I guess I should re-orphan glipper then. Regards, -- Ing. Juan M. Rodriguez Moreno Desarrollador de Sistemas Abiertos Sitio: http://proyectofedora.org/mexico -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at matbooth.co.uk Tue Jul 14 19:26:56 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Tue, 14 Jul 2009 20:26:56 +0100 Subject: Purging the F12 orphans In-Reply-To: <1247594323.3073.1169.camel@localhost.localdomain> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> Message-ID: <9497e9990907141226w5e0ff3f6o8ccdc32b704ed7bd@mail.gmail.com> On Tue, Jul 14, 2009 at 6:58 PM, Jesse Keating wrote: > > Unblocked orphan jakarta-commons-codec > Unblocked orphan jakarta-commons-digester > Unblocked orphan jakarta-commons-launcher > Unblocked orphan jakarta-commons-modeler > Unblocked orphan xerces-j2 > Unblocked orphan xml-commons-apis > The ones listed above are Eclipse dependencies (at least, ones I'm aware are Eclipse dependencies), which I can take, but co-maintainers are preferred of course. > Unblocked orphan xml-commons-apis12 > repoquery says nothing uses xml-commons-apis12, could this be retired? -- 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 cemeyer at u.washington.edu Tue Jul 14 19:30:03 2009 From: cemeyer at u.washington.edu (Conrad Meyer) Date: Tue, 14 Jul 2009 12:30:03 -0700 Subject: bchunk: dead package In-Reply-To: <20090714125634.7ee22a57@faldor> References: <20090714125634.7ee22a57@faldor> Message-ID: <200907141230.03271.cemeyer@u.washington.edu> On Tuesday 14 July 2009 03:56:34 am Michael Schwendt wrote: > https://fedorahosted.org/rel-eng/ticket/1977 > > bchunk is said to be obsolete, because "shntool" (also in Fedora) would > be superior. If you disagree and find a good reason to adopt bchunk, please > find a solution for the open ticket. > > Originally, I had sponsored Alan Olson (alano) when he wanted to take over > this old package in Fedora. A deal that hasn't worked out this time. The > single bugzilla ticket (#439661)is without a response/action since over a > year. And attempts at contacting alano via private mail and bugzilla have > been fruitless. As such, I've removed him from the FAS Packager group, too. >From reading the ticket[0], it looks like the Debian patch solves the issue -- I would like to take the package. [0]: https://bugzilla.redhat.com/show_bug.cgi?id=439661 Regards, -- Conrad Meyer From christoph.wickert at googlemail.com Tue Jul 14 19:41:57 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Tue, 14 Jul 2009 21:41:57 +0200 Subject: Fedora rawhide rebuild in mock status 2009-07-10 x86_64 In-Reply-To: <20090714182235.GA1967@mock.linuxdev.us.dell.com> References: <20090714182235.GA1967@mock.linuxdev.us.dell.com> Message-ID: <1247600517.15109.326.camel@localhost> Am Dienstag, den 14.07.2009, 13:22 -0500 schrieb Matt Domsch: > cwickert: gwget,lxappearance,lxlauncher,lxsession-edit,lxshortcut The epiphany extension of gwget is known to be broken. Already reported upstream: http://bugzilla.gnome.org/show_bug.cgi?id=585401 Should I disable it for now? The rest are false positives. All have been updated last week without problems and I verified they still build with a couple scratch builds: http://koji.fedoraproject.org/koji/taskinfo?taskID=1473863 http://koji.fedoraproject.org/koji/taskinfo?taskID=1473873 http://koji.fedoraproject.org/koji/taskinfo?taskID=1473864 http://koji.fedoraproject.org/koji/taskinfo?taskID=1473905 There must be something wrong with your builds: lxappearance: build.log is 33 MB lxlauncher: build.log is 46 MB lxsession-edit: build.log is 19 MB lxshortcut: build.log is 17 MB Regards, Christoph From cemeyer at u.washington.edu Tue Jul 14 19:51:36 2009 From: cemeyer at u.washington.edu (Conrad Meyer) Date: Tue, 14 Jul 2009 12:51:36 -0700 Subject: Orphaning packages Message-ID: <200907141251.36460.cemeyer@u.washington.edu> Hi, I intend to orphan the JRuby package and some of the dependencies I don't believe anything else uses. It's a piece of software upstream really doesn't intend to be packaged, and bumping to new versions is a constant struggle. Furthermore, I don't have anymore use for it. Here is the list of packages I'll orphan sometime in the next week or so: - bytelist - constantine - jcodings - jline - jna-posix - joni - jvyamlb If anyone wants any of them, let me know. (In case it's not obvious, they are all java packages.) Regards, -- Conrad Meyer From opensource at till.name Tue Jul 14 20:32:08 2009 From: opensource at till.name (Till Maas) Date: Tue, 14 Jul 2009 22:32:08 +0200 Subject: epel-release in Fedora repos? In-Reply-To: References: <4A5C3FF9.3010903@redhat.com> <1247590610.3073.1165.camel@localhost.localdomain> Message-ID: <200907142232.09618.opensource@till.name> On Tue July 14 2009, Jason L Tibbitts III wrote: > >>>>> "JK" == Jesse Keating writes: > > JK> At 7000+ srpms there is no way I could evaluate each and every one > JK> for validity before submitting it for a rebuild. > > I think the point is that the package owner should have deleted it > from devel so that there would be nothing for rel-eng to rebuild. Imho if the devel branch is a problem, then it should not be created when the package is imported to CVS, if it is a epel-only package. Requesting such strange actions from package maintainers who may not know all the magic behind the build system will only lead to errors like this one. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From ville.skytta at iki.fi Tue Jul 14 20:33:35 2009 From: ville.skytta at iki.fi (Ville =?windows-1252?q?Skytt=E4?=) Date: Tue, 14 Jul 2009 23:33:35 +0300 Subject: New maintainer needed: dumpasn1, freedroid, http_ping, id3v2, pscan, zzuf In-Reply-To: <200907030046.05420.ville.skytta@iki.fi> References: <200907012321.43913.ville.skytta@iki.fi> <954b158e0907011826o5d9013aag85f537370cac2999@mail.gmail.com> <200907030046.05420.ville.skytta@iki.fi> Message-ID: <200907142333.36151.ville.skytta@iki.fi> On Friday 03 July 2009, Ville Skytt? wrote: > On Thursday 02 July 2009, Xia Shing Zee wrote: > > I'm a new package maintainer, but I'll try dumpasn1 and id3v2 > > Thanks (ditto to the others who grabbed the rest of the packages). Please > go ahead and take ownership of these in pkgdb, they have been orphaned > already. I see you applied for F-11 watchbugzilla and watchcommits for dumpasn1 and id3v2, but that's not enough for them to be unorphaned. Click the "Take ownership" button to accomplish that, and I suggest doing that for Fedora devel as well in addition to F-11. From jwboyer at gmail.com Tue Jul 14 20:48:09 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 14 Jul 2009 16:48:09 -0400 Subject: epel-release in Fedora repos? In-Reply-To: <200907142232.09618.opensource@till.name> References: <4A5C3FF9.3010903@redhat.com> <1247590610.3073.1165.camel@localhost.localdomain> <200907142232.09618.opensource@till.name> Message-ID: <20090714204809.GG14757@hansolo.jdub.homelinux.org> On Tue, Jul 14, 2009 at 10:32:08PM +0200, Till Maas wrote: >On Tue July 14 2009, Jason L Tibbitts III wrote: >> >>>>> "JK" == Jesse Keating writes: >> >> JK> At 7000+ srpms there is no way I could evaluate each and every one >> JK> for validity before submitting it for a rebuild. >> >> I think the point is that the package owner should have deleted it >> from devel so that there would be nothing for rel-eng to rebuild. > >Imho if the devel branch is a problem, then it should not be created when the >package is imported to CVS, if it is a epel-only package. Requesting such >strange actions from package maintainers who may not know all the magic behind >the build system will only lead to errors like this one. You have a valid point. I'm not sure if the cvs scripts or pkgdb can currently cope with that though. If you have the time to look into it, I'm sure it would be appreciated. josh From tibbs at math.uh.edu Tue Jul 14 21:05:00 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 14 Jul 2009 16:05:00 -0500 Subject: epel-release in Fedora repos? In-Reply-To: <200907142232.09618.opensource@till.name> (Till Maas's message of "Tue\, 14 Jul 2009 22\:32\:08 +0200") References: <4A5C3FF9.3010903@redhat.com> <1247590610.3073.1165.camel@localhost.localdomain> <200907142232.09618.opensource@till.name> Message-ID: >>>>> "TM" == Till Maas writes: TM> Imho if the devel branch is a problem, then it should not be TM> created when the package is imported to CVS, if it is a epel-only TM> package. The devel branch is mandatory, but that doesn't mean that the package owner has to import anything there if they don't need it. Honestly, though, packages that will be in EPEL but not in Fedora at all are very rare exceptions and retooling the infrastructure to handle them specially would be something of a waste of effort. - J< From opensource at till.name Tue Jul 14 21:07:53 2009 From: opensource at till.name (Till Maas) Date: Tue, 14 Jul 2009 23:07:53 +0200 Subject: epel-release in Fedora repos? In-Reply-To: <20090714204809.GG14757@hansolo.jdub.homelinux.org> References: <4A5C3FF9.3010903@redhat.com> <200907142232.09618.opensource@till.name> <20090714204809.GG14757@hansolo.jdub.homelinux.org> Message-ID: <200907142308.01388.opensource@till.name> On Tue July 14 2009, Josh Boyer wrote: > You have a valid point. I'm not sure if the cvs scripts or pkgdb can > currently cope with that though. If you have the time to look into it, I'm > sure it would be appreciated. Do you know which script parses the cvs requests and generates the module(?)? The easiest (workaround) way to do it woul probably be just to run "cvs rm -f devel" right after it was created by the script. If it works when the maintainer does it, it should also work when a cvs-admin does it. :-) Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From Matt_Domsch at dell.com Tue Jul 14 21:38:24 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 14 Jul 2009 16:38:24 -0500 Subject: Fedora rawhide rebuild in mock status 2009-07-10 x86_64 In-Reply-To: <20090714184045.GA32522@auslistsprd01.us.dell.com> References: <20090714182235.GA1967@mock.linuxdev.us.dell.com> <20090714182613.GA31836@amd.home.annexia.org> <20090714184045.GA32522@auslistsprd01.us.dell.com> Message-ID: <20090714213824.GA23213@auslistsprd01.us.dell.com> On Tue, Jul 14, 2009 at 01:40:45PM -0500, Matt Domsch wrote: > I jumped the gun a bit; the results are still syncing out to the > website. I'll repost soon as I see the sync is finished. OK, the logs are all present now. -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From darrellpf at gmail.com Tue Jul 14 21:49:15 2009 From: darrellpf at gmail.com (darrell pfeifer) Date: Tue, 14 Jul 2009 14:49:15 -0700 Subject: gnome applications failing to start Message-ID: In rawhide gnome applications are failing to start. type array 97 not a basic type D-Bus not built with -rdynamic so unable to print a backtrace It seems to be related to attempting to open a file. eog dies at startup but works when double-clicking a file. gedit just always dies. What component should get the bug report? darrell From opensource at till.name Tue Jul 14 21:50:09 2009 From: opensource at till.name (Till Maas) Date: Tue, 14 Jul 2009 23:50:09 +0200 Subject: Packages tracked by FEver that need to be updated In-Reply-To: References: <200907102243.14776.opensource@till.name> <200907111825.41242.opensource@till.name> Message-ID: <200907142350.26191.opensource@till.name> On Sat July 11 2009, Jon Stanley wrote: > On Sat, Jul 11, 2009 at 12:25 PM, Till Maas wrote: > > Probably and afaik the original author also planned to do so. Unluckily > > the code that handled the bugzilla tickets is afaik not publicly > > available, therefore this needs to be rewritten. > > What language is it written in? Should be easy to implement using > python-bugzilla assuming it's written in python. It's written in python and python-bugzilla would allow to make this easier. But afaics it does not yet allow to set the whiteboard of new bugs to FutureFeature, which is something the triage SIG would like to have. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From Matt_Domsch at dell.com Tue Jul 14 21:57:22 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 14 Jul 2009 16:57:22 -0500 Subject: Fedora rawhide rebuild in mock status 2009-07-10 x86_64 In-Reply-To: <1247600517.15109.326.camel@localhost> References: <20090714182235.GA1967@mock.linuxdev.us.dell.com> <1247600517.15109.326.camel@localhost> Message-ID: <20090714215722.GA24214@auslistsprd01.us.dell.com> On Tue, Jul 14, 2009 at 09:41:57PM +0200, Christoph Wickert wrote: > Am Dienstag, den 14.07.2009, 13:22 -0500 schrieb Matt Domsch: > > > cwickert: gwget,lxappearance,lxlauncher,lxsession-edit,lxshortcut > > The epiphany extension of gwget is known to be broken. Already reported > upstream: http://bugzilla.gnome.org/show_bug.cgi?id=585401 > Should I disable it for now? > > The rest are false positives. All have been updated last week without > problems and I verified they still build with a couple scratch builds: > http://koji.fedoraproject.org/koji/taskinfo?taskID=1473863 > http://koji.fedoraproject.org/koji/taskinfo?taskID=1473873 > http://koji.fedoraproject.org/koji/taskinfo?taskID=1473864 > http://koji.fedoraproject.org/koji/taskinfo?taskID=1473905 > > There must be something wrong with your builds: > lxappearance: build.log is 33 MB > lxlauncher: build.log is 46 MB > lxsession-edit: build.log is 19 MB > lxshortcut: build.log is 17 MB make got very upset... mv -f .deps/main.Tpo .deps/main.Po mv -f .deps/main-dlg.Tpo .deps/main-dlg.Po mv -f .deps/demo-ui.Tpo .deps/demo-ui.Po mv -f .deps/main-dlg-ui.Tpo .deps/main-dlg-ui.Po gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o lxappearance main.o glade-s upport.o main-dlg-ui.o main-dlg.o demo-ui.o demo.o -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo - lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 make[2]: Leaving directory `/builddir/build/BUILD/lxappearance-0.2.1/src' Making all in po make[2]: Entering directory `/builddir/build/BUILD/lxappearance-0.2.1/po' cd .. \ && CONFIG_FILES=po/Makefile.in CONFIG_HEADERS= CONFIG_LINKS= \ /bin/sh ./config.status config.status: creating po/Makefile.in config.status: executing depfiles commands config.status: executing default-1 commands make[2]: Leaving directory `/builddir/build/BUILD/lxappearance-0.2.1/po' make[2]: Entering directory `/builddir/build/BUILD/lxappearance-0.2.1/po' cd .. \ && CONFIG_FILES=po/Makefile.in CONFIG_HEADERS= CONFIG_LINKS= \ /bin/sh ./config.status config.status: creating po/Makefile.in config.status: executing depfiles commands config.status: executing default-1 commands (repeat until 6 hour timeout) -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From a.badger at gmail.com Tue Jul 14 22:00:53 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 14 Jul 2009 15:00:53 -0700 Subject: epel-release in Fedora repos? In-Reply-To: <20090714204809.GG14757@hansolo.jdub.homelinux.org> References: <4A5C3FF9.3010903@redhat.com> <1247590610.3073.1165.camel@localhost.localdomain> <200907142232.09618.opensource@till.name> <20090714204809.GG14757@hansolo.jdub.homelinux.org> Message-ID: <4A5D0015.8010500@gmail.com> On 07/14/2009 01:48 PM, Josh Boyer wrote: > On Tue, Jul 14, 2009 at 10:32:08PM +0200, Till Maas wrote: >> On Tue July 14 2009, Jason L Tibbitts III wrote: >>>>>>>> "JK" == Jesse Keating writes: >>> >>> JK> At 7000+ srpms there is no way I could evaluate each and every one >>> JK> for validity before submitting it for a rebuild. >>> >>> I think the point is that the package owner should have deleted it >>> from devel so that there would be nothing for rel-eng to rebuild. >> >> Imho if the devel branch is a problem, then it should not be created when the >> package is imported to CVS, if it is a epel-only package. Requesting such >> strange actions from package maintainers who may not know all the magic behind >> the build system will only lead to errors like this one. > > You have a valid point. I'm not sure if the cvs scripts or pkgdb can currently > cope with that though. If you have the time to look into it, I'm sure it > would be appreciated. All sorts of breakage is likely to occur without a devel branch in the pkgdb meta-data. We might be able to get rid of the actual cvs directory but I wouldn't bet that something doesn't rely on this as well. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From oget.fedora at gmail.com Tue Jul 14 22:10:50 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Tue, 14 Jul 2009 18:10:50 -0400 Subject: Fedora rawhide rebuild in mock status 2009-07-10 x86_64 In-Reply-To: <20090714182235.GA1967@mock.linuxdev.us.dell.com> References: <20090714182235.GA1967@mock.linuxdev.us.dell.com> Message-ID: On Tue, Jul 14, 2009 at 2:22 PM, Matt Domsch wrote: > > oget: calf,fluidsynth,hydrogen,jack-keyboard,lash,muse,tex-musixtex > All except the last one is due to the e2fsprogs split and I'm fixing them. But the last one may be an rpm or mock issue. I don't know what to do. Any ideas? http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/x86_64/tex-musixtex-0.114-6.rev4.fc11.src.rpm/result/build.log Orcan From chkr at fedoraproject.org Tue Jul 14 22:30:19 2009 From: chkr at fedoraproject.org (Christian Krause) Date: Wed, 15 Jul 2009 00:30:19 +0200 Subject: Purging the F12 orphans In-Reply-To: <1247589637.3073.1162.camel@localhost.localdomain> References: <1247589637.3073.1162.camel@localhost.localdomain> Message-ID: <4A5D06FB.7060809@fedoraproject.org> Hi, Jesse Keating wrote: > It's that time of the release cycle again, to purge the orphans before > we get to feature freeze. Any unblocked orphans will be purged by the > 28th of this month. Here is a current list of unblocked orphans: > Unblocked orphan f-spot I'm using f-spot occasionally and since I'm already helping out with some of the mono packages I'm taking ownership of this one. Best regards, Christian From poelstra at redhat.com Tue Jul 14 22:58:33 2009 From: poelstra at redhat.com (John Poelstra) Date: Tue, 14 Jul 2009 15:58:33 -0700 Subject: Fedora 12 Features Needing Updates Message-ID: <4A5D0D99.4040409@redhat.com> Hello Fedora 12 Feature Owners, As a follow-up to my previous request, we still have a few feature pages that have not been updated recently. Please update your page as soon as possible. Please make sure the information listed on your feature page is current and then update the "Last Updated" date--even if you haven't changed any information on the page. This is a simple way for us to know that your page is current. If any of the features below remain unchanged by this Thursday, July 16, 2009, I will send them on to FESCo for their reconsideration. https://fedoraproject.org/wiki/Features/DebuginfoFS https://fedoraproject.org/wiki/Features/DisplayPort https://fedoraproject.org/wiki/Features/Dracut https://fedoraproject.org/wiki/Features/Empathy https://fedoraproject.org/wiki/Features/KDE43 https://fedoraproject.org/wiki/Features/liblvm https://fedoraproject.org/wiki/Features/MoreNetworkManagerMobileBroadband https://fedoraproject.org/wiki/Features/Multiseat https://fedoraproject.org/wiki/Features/NFSClientIPv6 https://fedoraproject.org/wiki/Features/SystemtapStaticProbes https://fedoraproject.org/wiki/Features/VirtgPXE https://fedoraproject.org/wiki/Features/XZRpmPayloads https://fedoraproject.org/wiki/Features/F12X86Support https://fedoraproject.org/wiki/Features/VirtioSerial https://fedoraproject.org/wiki/Features/XI2 Thank you, John _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From sahartsu at xs4all.nl Tue Jul 14 23:11:49 2009 From: sahartsu at xs4all.nl (S.A. Hartsuiker) Date: Wed, 15 Jul 2009 01:11:49 +0200 Subject: Against what do I file this bug? Message-ID: <4A5D10B5.8000004@xs4all.nl> Hi, I reinstalled my desktop last weekend and now it doesn't quite work :) Some background info: Anaconda (11.5.0.59) did succesfully install F11 on my fakeraid nvidia (mirrored). My bootup device is the fakeraid mirrored device. Therefore the /boot partition is also on the fakeraid mirrored device. Booting up in a rescue environment I can see that everything that should be there is in fact there. I have a second faraid device connected to the same nvidia chip bridge thingy. This one however only consist of 1 drive, don't ask me why it is still seen by Fedora as a fakeraid device, I don't know. Now for my problem. Although Anaconda installed grub in the bootsector of the fakeraid mirrored device, I never actually get to a grub prompt, it just loads the kernel. Presumably due to the possibility that grub can't find the /boot partition. Although annoying, not really a big problem for me as I always run the latest kernel on the desktop anyway. However during the mounting stage of the boot process the /boot partition can also not be found and I am dropped into maintance mode. After a little investigation it turns out that device mapper has not made the devicenodes for the root partition either, in fact none of the partitions of the fakeraid mirrored device are present in the /dev/mapper folder, but the other fakeraid device (including it's partitions) is. Comparing the /sys/dev/block/ entries from the rescue environment and from maintance mode show that sysfs is not completely populating the respective folders for the fakeraid mirrored device. So the question becomes against what do I file bugs? I've never seen this situation before and while I'm typing this I get the distinct impression that I have several bugs on my hands. Kind regards, Stefan Hartsuiker From mw_triad at users.sourceforge.net Tue Jul 14 23:24:10 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Tue, 14 Jul 2009 18:24:10 -0500 Subject: Against what do I file this bug? In-Reply-To: <4A5D10B5.8000004@xs4all.nl> References: <4A5D10B5.8000004@xs4all.nl> Message-ID: S.A. Hartsuiker wrote: > Now for my problem. Although Anaconda installed grub in the bootsector > of the fakeraid mirrored device, I never actually get to a grub prompt, > it just loads the kernel. Um... do you mean that grub loads the latest kernel without pausing to ask if that's what you want? Because as I understand that is intended behavior with F11 (with F10 already, I want to say). Hold some key during boot to get the grub menu (ctrl works well, being unused by most BIOS's). > Presumably due to the possibility that grub can't find the /boot > partition. This makes no sense. If grub was failing to find /boot, you would get a grub error, since there would be nothing for it to boot (nor would it find grub.conf, I think). IOW, you would get slightly farther than the BIOS failing to find a MBR, but certainly no maintenance mode (which implies a roughly-functional kernel and initrd). > However during the mounting stage of the boot process the /boot > partition can also not be found and I am dropped into maintance mode. This sounds like an initrd problem to me, but I am no expert. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- From sahartsu at xs4all.nl Tue Jul 14 23:31:22 2009 From: sahartsu at xs4all.nl (S.A. Hartsuiker) Date: Wed, 15 Jul 2009 01:31:22 +0200 Subject: Against what do I file this bug? In-Reply-To: References: <4A5D10B5.8000004@xs4all.nl> Message-ID: <4A5D154A.1070009@xs4all.nl> On 07/15/2009 01:24 AM, Matthew Woehlke wrote: > S.A. Hartsuiker wrote: >> Now for my problem. Although Anaconda installed grub in the bootsector >> of the fakeraid mirrored device, I never actually get to a grub prompt, >> it just loads the kernel. > > Um... do you mean that grub loads the latest kernel without pausing to > ask if that's what you want? Because as I understand that is intended > behavior with F11 (with F10 already, I want to say). Hold some key > during boot to get the grub menu (ctrl works well, being unused by most > BIOS's). Ok, this is a pebkac. Apparently it's just a very short timeout now. Keeping a key pressed after POST, but before I see any mention of grub seems to work. > >> Presumably due to the possibility that grub can't find the /boot >> partition. > > This makes no sense. If grub was failing to find /boot, you would get a > grub error, since there would be nothing for it to boot (nor would it > find grub.conf, I think). IOW, you would get slightly farther than the > BIOS failing to find a MBR, but certainly no maintenance mode (which > implies a roughly-functional kernel and initrd). Yes, see above. > >> However during the mounting stage of the boot process the /boot >> partition can also not be found and I am dropped into maintance mode. > > This sounds like an initrd problem to me, but I am no expert. > From mw_triad at users.sourceforge.net Tue Jul 14 23:40:39 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Tue, 14 Jul 2009 18:40:39 -0500 Subject: Against what do I file this bug? In-Reply-To: <4A5D154A.1070009@xs4all.nl> References: <4A5D10B5.8000004@xs4all.nl> <4A5D154A.1070009@xs4all.nl> Message-ID: S.A. Hartsuiker wrote: > On 07/15/2009 01:24 AM, Matthew Woehlke wrote: >> S.A. Hartsuiker wrote: >>> Now for my problem. Although Anaconda installed grub in the bootsector >>> of the fakeraid mirrored device, I never actually get to a grub prompt, >>> it just loads the kernel. >> >> Um... do you mean that grub loads the latest kernel without pausing to >> ask if that's what you want? Because as I understand that is intended >> behavior with F11 (with F10 already, I want to say). Hold some key >> during boot to get the grub menu (ctrl works well, being unused by most >> BIOS's). > > Ok, this is a pebkac. Apparently it's just a very short timeout now. In theory the timeout is "0" :-). Or I suppose, "only as long as it takes to poll the keyboard to see if a key is pressed". (In case you are wondering, the reason was to further reduce boot time. You can of course edit grub.conf to have an actual timeout, if you prefer.) > Keeping a key pressed after POST, but before I see any mention of grub > seems to work. Right, this is what you're supposed to do :-). (Or even start holding a key during POST works, which is why I suggested ctrl as something that POST will ignore, and that grub will only pay attention to as far as "oh, you want to see the menu".) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- From rc040203 at freenet.de Tue Jul 14 23:50:44 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 15 Jul 2009 01:50:44 +0200 Subject: NVR bugs in rawhide In-Reply-To: <20090714181410.2d2ff8f4@faldor> References: <4A5C3FF9.3010903@redhat.com> <20090714111532.4b688163@faldor> <4A5C7848.20608@redhat.com> <20090714144853.19816cfc@faldor> <1247575691.3164.2.camel@politzer.theorphys.helsinki.fi> <20090714153737.785463f7@faldor> <4A5C8FCE.40905@freenet.de> <20090714173602.2fa06b11@faldor> <4A5CAA22.3090701@freenet.de> <20090714181410.2d2ff8f4@faldor> Message-ID: <4A5D19D4.3090207@freenet.de> Michael Schwendt wrote: > On Tue, 14 Jul 2009 17:54:10 +0200, Ralf wrote: > >> Michael Schwendt wrote: >>> On Tue, 14 Jul 2009 16:01:50 +0200, Ralf wrote: >>> >>>>> You don't need to drop %dist for koji build inheritance to work. >>>>> >>>>> It just looks much cleaner to inherit foo-1.0-1.noarch.rpm for all >>>>> newer targets >>>> IFF "current rpm" is sufficiently compatible to the antique version of >>>> rpm a package has been built on. >>>> >>>> If this doesn't apply you don't get anywhere. >>> Not _with_ %dist either. >> Of cause it would help. A package's release tag would very verbosely >> tell you that a package is outdated. > > And still it would fail if RPM were changed [the way you describe] while > %dist stayed the same. Right, the key being using %?dist is _rebuilding_. > %dist doesn't reflect at all whether RPM changes > its file format near the beginning of a Fedora devel cycle. Right, but unlike hidden build dates etc. it is clearly _visible_. >>>> => I agree with Jussi. Allowing people not to use %dist is not helpful. >>>> It's a booby trap which certainly will hit some day. >>> %dist is a trap itself - packagers run into it regularly, e.g. when >>> adding Obsoletes and versioned dependencies, when doing trial-and-error >>> fixing of old branches (without paying attention to the recommendations in >>> the guidelines), when committing and tagging after a server-side update of >>> the "branches" file. >> Quite easy to overcome: always use %?dist. > > Doesn't help much. Packager still needs to bump all branches [correctly] > to recover. Not true. He needs to rebuild rawhide, not all branches. >> It's the cases when people add/remove %?dist, which are problematic. > > Going in circles won't be of any use in this thread. Using %dist adds > complications, too. Or else packagers would not run into some of the > pitfalls I've pointed out. Well, they are running into them, because Fedora's NVRs rules are not strict enough. Ralf From walters at verbum.org Tue Jul 14 23:58:00 2009 From: walters at verbum.org (Colin Walters) Date: Tue, 14 Jul 2009 19:58:00 -0400 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C6E4E.1080603@filteredperception.org> References: <4A5C3C12.9050009@filteredperception.org> <4A5C6AC5.4060102@earthlink.net> <4A5C6E4E.1080603@filteredperception.org> Message-ID: On Tue, Jul 14, 2009 at 7:38 AM, Douglas McClendon wrote: > No, from a user experience perspective, a kexec 'warm' reboot is still a > reboot. I could be wrong about that, or my interpretation of what > kexec does (I've read about it often in LWN, but never knowingly used it). That's correct I believe, yes. > ?If so, one way to describe the major > benefit of my rebootless installer, is that you get to boot the livecd/usb > environment, *then use it as such*, and at your option, desire, and > convenience, decide to permanently install the LiveOS you have just been > using and configuring, to disk. ?And of course when done, just pop out the > livecd/usb, and your are done... and free to leave your system with a > continuingly increasing uptime :) Wait, so it's persisting any changes you made to the target drive? That sounds quite cool actually, and I misunderstood the original post. Concretely with your change, if I've connected to a wireless network with NetworkManager, that would get saved in the target drive's configuration in gconf and be there next time I boot? I know with the live images one problem we have is that data can sort of randomly disappear if you're running close to the memory limit; if we go with your architecture we should probably special-case things like ~/.gconf so say the Firefox http disk cache doesn't blow away your wireless config. From MathStuf at gmail.com Wed Jul 15 00:28:07 2009 From: MathStuf at gmail.com (Ben Boeckel) Date: Tue, 14 Jul 2009 20:28:07 -0400 Subject: Fedora 12 Features Needing Updates References: <4A5D0D99.4040409__39087.9116407179$1247612486$gmane$org@redhat.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Poelstra wrote: > https://fedoraproject.org/wiki/Features/KDE43 I updated this since both Rex is on vacation and Kevin is most likely as well. - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpdIpcACgkQiPi+MRHG3qT//wCfQOTcd9TRONQamStPVBhwD2X0 Hj0AoKqCdxep/8WtDFstoJW712vMyiTB =9BnQ -----END PGP SIGNATURE----- From rawhide at fedoraproject.org Wed Jul 15 01:33:03 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Wed, 15 Jul 2009 01:33:03 +0000 Subject: rawhide report: 20090714 changes Message-ID: <20090715013303.GA3804@releng2.fedora.phx.redhat.com> Compose started at Tue Jul 14 06:15:05 UTC 2009 New package rubygem-syntax Ruby library for performing simple syntax highlighting Updated Packages: NetworkManager-openvpn-0.7.1-1.git20090713.fc12 ----------------------------------------------- * Mon Jul 13 2009 Dan Williams - 1:0.7.1-1.20090713 - Update to 0.7.1 - Translation updates R-BSgenome-1.12.3-1.fc12 ------------------------ * Mon Jul 13 2009 pingou 1.12.3-1 - Update to 1.12.3 R-Biostrings-2.12.7-1.fc12 -------------------------- * Mon Jul 13 2009 pingou 2.12.7-1 - Update to 2.12.7 augeas-0.5.2-1.fc12 ------------------- * Mon Jul 13 2009 David Lutterkort - 0.5.2-1 - New version bind-9.6.1-3.fc12 ----------------- * Mon Jul 13 2009 Adam Tkac 32:9.6.1-3 - fix broken symlinks in bind-libs (#509635) - fix typos in /etc/sysconfig/named (#509650) - add DEBUG option to /etc/sysconfig/named (#510283) brasero-2.27.4-1.fc12 --------------------- * Tue Jul 14 2009 Matthias Clasen 2.27.4-1 - Update to 2.27.4 bzr-1.17-0.1.rc1.fc12 --------------------- * Mon Jul 13 2009 Henrik Nordstrom - 1.17-0.1 - Update to 1.17rc1 bzrtools-1.17.0-1.fc12 ---------------------- * Tue Jul 14 2009 Henrik Nordstrom - 1.17.0-1 - Update to 1.17.0 cheese-2.27.4-1.fc12 -------------------- * Mon Jul 13 2009 Matthias Clasen 2.27.4-1 - Update to 2.27.4 compiz-fusion-0.8.2-3.fc12 -------------------------- * Mon Jul 13 2009 Adel Gadllah 0.8.2-3 - Remove the wall gconf schema (conflicts with the one in compiz) cups-1.4-0.rc1.9.fc12 --------------------- * Mon Jul 13 2009 Remi Collet 1:1.4-0.rc1.9 - rebuild for new PHP 5.3.0 ABI (20090626) - add PHP ABI check - use php_extdir - add php configuration file (/etc/php.d/cups.ini) * Fri Jul 10 2009 Tim Waugh 1:1.4-0.rc1.8 - Build does not require aspell-devel (bug #510405). dovecot-1.2.1-1.fc12 -------------------- * Mon Jul 13 2009 Michal Hlavinka - 1:1.2.1-1 - updated to 1.2.1 - GSSAPI authentication is fixed (#506782) - logins now fail if home directory path is relative, because it was not working correctly and never was expected to work - sieve and managesieve update dssi-1.0.0-2.fc12 ----------------- * Mon Jul 13 2009 Orcan Ogetbil - 1.0.0-2 - Fix the default DSSI plugin path to avoid a crash dvdisaster-0.72-1.fc12 ---------------------- * Mon Jul 13 2009 Dmitry Butskoy - 0.72-1 - Upgrade to 0.72 eclipse-nls-3.5.0.v20090620043401-1.fc12 ---------------------------------------- * Mon Jul 13 2009 Sean Flanigan - 3.5.0.v20090620043401-1 - Updated to Babel's release "0.7" - Created a new fetch-babel.sh to automate the zip downloads evince-2.27.4-1.fc12 -------------------- * Mon Jul 13 2009 Matthias Clasen - 2.27.4-1 - Update to 2.27.4 evolution-2.27.4-1.fc12 ----------------------- * Mon Jul 13 2009 Matthew Barnes - 2.27.4-1.fc12 - Update to 2.27.4 - Work around deprecation of g_mount_unmount(). * Fri Jul 10 2009 Matthew Barnes - 2.27.3-5.fc11 - Add an evolution-pst subpackage for the PST importer plugin. - Disabled until libpst settles on an API. * Thu Jul 02 2009 Matthew Barnes - 2.27.3-4.fc12 - Add BR for libpst-devel and libytnef-devel (RH bug #493049). - Add patch to build pst-import plugin against current libpst. - libpst's API broke again so disable the BR's for now. - Specify the gettext package when calling intltool-update. evolution-data-server-2.27.4-1.fc12 ----------------------------------- * Mon Jul 13 2009 Matthew Barnes - 2.27.4-1.fc12 - Update to 2.27.4 - Remove patch for RH bug #505661 (fixed upstream). evolution-exchange-2.27.4-1.fc12 -------------------------------- * Mon Jul 13 2009 Matthew Barnes - 2.27.4-1.fc12 - Update to 2.27.4 evolution-mapi-0.27.4-1.fc12 ---------------------------- * Mon Jul 13 2009 Matthew Barnes - 0.27.4-1 - Update to 0.27.4 fedora-packager-0.3.5-1.fc12 ---------------------------- * Mon Jul 13 2009 Dennis Gilmore - 0.3.5-1 - add new rpmbuild-md5 script to build old style hash srpms - it is a wrapper around rpmbuild file-roller-2.27.2-1.fc12 ------------------------- * Mon Jul 13 2009 Matthias Clasen 2.27.2-1 - Update to 2.27.2 firefox-3.5-2.fc12 ------------------ * Mon Jul 13 2009 Jan Horak - 3.5-2 - Updated icon firstaidkit-0.2.3-3.fc12 ------------------------ * Mon Jul 13 2009 Martin Sivak - 0.2.3-1 - Add firstaidkit-qs script - Do not build undelparts plugin since we ignore it anyways * Mon Jul 13 2009 Martin Sivak - 0.2.3-2 - Fixed firstaidkit-qs included.. * Mon Jul 13 2009 Martin Sivak - 0.2.3-3 - Add timeout to firstaidkit-qs fontmatrix-0.6.0-2.r1063.fc12 ----------------------------- * Mon Jul 13 2009 Parag - 0.6.0-1.r1063 - update to svn revision 1063 * Mon Jul 13 2009 Parag - 0.6.0-2.r1063 - Add missing BRs:python-devel podofo-devel libicu-devel gcc-4.4.0-13 ------------ * Mon Jul 13 2009 Jakub Jelinek 4.4.0-13 - update from gcc-4_4-branch - PRs c++/36628, c++/37206, c++/40502, c++/40684, c++/40689, fortran/40440, rtl-optimization/40667, target/40668 - avoid overlapping entries in .debug_ranges section (PR debug/40713) gnome-applets-2.27.3-4.fc12 --------------------------- * Mon Jul 13 2009 Matthias Clasen - 1:2.27.3-4 - Fix PolicyKit 1 patch gnome-games-2.27.4-1.fc12 ------------------------- * Tue Jul 14 2009 Matthias Clasen 2.27.4-1 - Update to 2.27.4 gnome-keyring-2.27.4-1.fc12 --------------------------- * Mon Jul 13 2009 Matthias Clasen - 2.27.4-1 - Update to 2.27.4 gnome-media-2.27.4-1.fc12 ------------------------- * Tue Jul 14 2009 Matthias Clasen 2.27.4-1 - Update to 2.27.4 * Thu Jul 02 2009 Matthias Clasen 2.27.3.1-2 - Shrink GConf schemas gnome-system-monitor-2.27.4-1.fc12 ---------------------------------- * Tue Jul 14 2009 Matthias Clasen - 2.27.4-1 - Update to 2.27.4 gnome-themes-2.27.4-1.fc12 -------------------------- * Mon Jul 13 2009 Matthias Clasen - 2.27.4-1 - Update to 2.27.4 gnome-translate-0.99-14.fc12 ---------------------------- * Mon Jul 13 2009 Dmitry Butskoy - 0.99-14 - Use enchant instead of aspell for language autodetection (#477274, patch by Caolan McNamara ) gok-2.27.4-1.fc12 ----------------- * Tue Jul 14 2009 Matthias Clasen 2.27.4-1 - Update to 2.27.4 graphviz-2.20.3-4.fc12.1 ------------------------ * Mon Jul 13 2009 Remi Collet 2.20.3-4 - rebuild for new PHP 5.3.0 ABI (20090626) - add PHP ABI check - use php_extdir (and don't own it) - add php configuration file (/etc/php.d/graphviz.ini) * Mon Jul 13 2009 Remi Collet 2.20.3-4.1 - fix mistake in make rtest fix gtk2-2.17.4-2.fc12 ------------------ * Mon Jul 13 2009 Matthias Clasen - 2.17.4-2 - Fix a problem with gtkentry.h gtkhtml3-3.27.4-1.fc12 ---------------------- * Mon Jul 13 2009 Matthew Barnes - 3.27.4-1.fc12 - Update to 3.27.4 gvfs-1.3.2-1.fc12 ----------------- * Mon Jul 13 2009 Matthias Clasen - 1.3.2-1 - Update to 1.3.2 - Drop upstreamed patches gwibber-1.2.0-2.349bzr.fc12 --------------------------- * Mon Jul 13 2009 Ian Weller - 1:1.2.0-2.349bzr - update to r349, bugfixes ice-3.3.1-3.fc12 ---------------- * Mon Jul 13 2009 Remi Collet - 3.3.1-3 - rebuild for new PHP 5.3.0 ABI (20090626) + ice-php53.patch - add PHP ABI check - use php_extdir iverilog-0.9.20090423-5.fc12 ---------------------------- * Sat Jun 13 2009 Chitlesh Goorah - 0.9.20090423-5 - Improved VPI support jbrout-0.3.174-2.fc12 --------------------- * Mon Jul 13 2009 Mat?j Cepl - 0.3.174-2 - Use hashlib if possible. kdelibs-4.2.96-1.fc12 --------------------- * Fri Jul 10 2009 Than Ngo - 4.2.96-1 - 4.3rc2 kernel-2.6.31-0.67.rc2.git9.fc12 -------------------------------- * Mon Jul 13 2009 Ben Skeggs - drm-nouveau.patch: update from upstream * Mon Jul 13 2009 Kyle McMartin 2.6.31-0.67.rc2.git9 - 2.6.31-rc2-git9 - config changes: - BLK_DEV_OSD=m lcdf-typetools-2.79-1.fc12 -------------------------- * Mon Jul 13 2009 Parag Nemade - 2.79-1 - Update to next upstream release 2.79 liberation-fonts-1.05.1.20090713-2.fc12 --------------------------------------- * Tue Jul 14 2009 Caius 'kaio' Chance - 1.05.1.20090713-2.fc12 - Required fontforge ver 20090408 which supports generation with traditional kern table. (rhbz#503430) * Mon Jul 13 2009 Caius 'kaio' Chance - 1.05.1.20090713-1.fc12 - Updated to upstream 1.05.1.20090713. - Generate TTFs with traditional kern table via fontforge scripts. (rh#503430) * Mon Jul 06 2009 Caius 'kaio' Chance - 1.05.1.20090706-1.fc12 - Updated to upstream 1.05.1.20090706. - Reconverted from original TTF with traditional kern table. (rh#503430) * Tue Jun 30 2009 Caius 'kaio' Chance - 1.05.1.20090630-1.fc12 - Updated to upstream 1.05.1.20090630. - Reconverted from original TTF with better procedures of data conservation. libmp4v2-1.5.0.1-9.fc12 ----------------------- * Mon Jul 13 2009 Matthias Saou 1.5.0.1-9 - Rebuild to fix runtime problems of the latest builds (#507302). libpuzzle-0.11-5.fc12 --------------------- * Mon Jul 13 2009 Remi Collet - 0.11-5 - rebuild for new PHP 5.3.0 ABI (20090626) - add PHP ABI check libsoup-2.27.4-1.fc12 --------------------- * Mon Jul 13 2009 Matthew Barnes - 2.27.4-1 - Update to 2.27.4 libtiff-3.8.2-14.fc12 --------------------- * Mon Jul 13 2009 Tom Lane 3.8.2-14 - Fix buffer overrun risks caused by unchecked integer overflow (CVE-2009-2347) Related: #510041 libvorbis-1.2.3-1.fc12 ---------------------- * Mon Jul 13 2009 Adam Jackson 1.2.3-1 - libvorbis 1.2.3 libxcb-1.2-8.fc12 ----------------- * Mon Jul 13 2009 Adam Jackson 1.2-8 - Really fix xpyb build. * Mon Jul 06 2009 Adam Jackson 1.2-7 - Fix xpyb build * Mon Jun 29 2009 Adam Jackson 1.2-6 - BuildRequires: xcb-proto >= 1.5 * Wed Jun 24 2009 Adam Jackson 1.2-5 - libxcb-1.2-no-nagle.patch: Disable Nagle's algorithm on TCP. (#442158) * Tue May 19 2009 Adam Jackson 1.2-4 - Add libxcb-python subpackage mingw32-libtiff-3.8.2-17.fc12 ----------------------------- * Mon Jul 13 2009 Michael Ploujnikov - 3.8.2-17 - update upstream URL - Fix some more LZW decoding vulnerabilities (CVE-2009-2285) Related: #511015 mousetweaks-2.27.4-1.fc12 ------------------------- * Tue Jul 14 2009 Matthias Clasen 2.27.4-1 - Update to 2.27.4 mythes-fr-2.1-4.fc12 -------------------- * Mon Jul 13 2009 Caolan McNamara - 2.1-4 - tidy spec nautilus-2.27.4-1.fc12 ---------------------- * Tue Jul 14 2009 Matthias Clasen - 2.27.4-1 - Update to 2.27.4 nfs-utils-1.2.0-6.fc12 ---------------------- * Mon Jul 13 2009 1.2.0-6 - Added NFSD v4 dynamic pseudo root patch which allows NFS v3 exports to be mounted by v4 clients. openvrml-0.18.2-2.fc12 ---------------------- * Mon Jul 13 2009 Braden McDaniel - 0.18.2-2 - Patch openvrml-player to fix symbol visibility. * Thu Jul 09 2009 Braden McDaniel - Made doc subpackage noarch. orca-2.27.4-1.fc12 ------------------ * Tue Jul 14 2009 Matthias Clasen - 2.27.4-1 - Update to 2.27.4 orsa-0.7.0-9.fc12 ----------------- * Mon Jul 13 2009 Milos Jakubicek - 0.7.0-9 - Rebuilt against new cln 1.3.0 - Temporarily disabled MPI support as current openmpi builds do not ship -devel, nor its previous content in the main package parted-1.9.0-2.20090610git32dc.fc12 ----------------------------------- * Mon Jul 13 2009 Joel Granados - 1.9.0-2.20090610git32dc - Correctly number the snapshot. pem-0.7.7-1.fc12 ---------------- * Mon Jul 13 2009 P J P - 0.7.7-1 - Fixed a minor bug and did few changes recommended by PBP. perl-TAP-Harness-JUnit-0.32-1.fc12 ---------------------------------- * Mon Jul 13 2009 Lubomir Rintel (Good Data) 0.31-1 - New upstream release * Mon Jul 13 2009 Lubomir Rintel (Good Data) 0.32-1 - New upstream release. Stupid, Lubomir, stupid. * Fri Apr 17 2009 Lubomir Rintel (Good Data) 0.30-1 - New upstream release php-magickwand-1.0.8-3.fc12 --------------------------- * Mon Jul 13 2009 Remi Collet 1.0.8-3 - rebuild for new PHP 5.3.0 ABI (20090626) - better PHP ABI check - use php_extdir php-pear-Auth-RADIUS-1.0.6-3.fc12 --------------------------------- * Mon Jul 13 2009 Remi Collet - 1.0.6-3 - remove mhash dependency (optional, and not provided by php 5.3.0) - rename Auth_RADIUS.xml to php-pear-Auth-RADIUS.xml php-pear-Crypt-CHAP-1.0.1-3.fc12 -------------------------------- * Mon Jul 13 2009 Remi Collet - 1.0.1-3 - remove mhash dependency (optional, and not provided by php 5.3.0) - rename Crypt_CHAP.xml to php-pear-Crypt-CHAP.xml php-pear-Net-DNS-1.0.1-1.fc12 ----------------------------- * Mon Jul 13 2009 Remi Collet - 1.0.1-1 - update to 1.0.1 - remove mhash dependency (now optional, and not provided by php 5.3.0) - rename Net_DNS.xml to php-pear-Net-DNS.xml php-pecl-apc-3.1.2-1.fc12 ------------------------- * Sun Jul 12 2009 Remi Collet - 3.1.2-1 - update to 3.1.2 (beta) - PHP 5.3 support - use setup -q -c php-pecl-imagick-2.2.2-3.fc12 ----------------------------- * Mon Jul 13 2009 Remi Collet - 2.2.2-3 - rebuild for new PHP 5.3.0 ABI (20090626) php-pecl-parsekit-1.2-4.CVS20090309.fc12 ---------------------------------------- * Mon Jul 13 2009 Remi Collet - 1.2-4.CVS20090309 - rebuild for new PHP 5.3.0 ABI (20090626) php-pecl-runkit-0.9-11.CVS20090215.fc12 --------------------------------------- * Mon Jul 13 2009 Remi Collet - 0.9-11.CVS20090215 - rebuild for new PHP 5.3.0 ABI (20090626) php-pecl-selinux-0.3.1-3.fc12 ----------------------------- * Mon Jul 13 2009 Remi Collet - 0.3.1-2 - rebuild for new PHP 5.3.0 ABI (20090626) php-shout-0.9.2-4.fc12 ---------------------- * Mon Jul 13 2009 Remi Collet - 0.9.2-4 - rebuild for new PHP 5.3.0 ABI (20090626) php-suhosin-0.9.27-3.fc12 ------------------------- * Mon Jul 13 2009 Remi Collet - 0.9.27-3 - rebuild for new PHP 5.3.0 ABI (20090626) pixman-0.15.16-1.fc12 --------------------- * Mon Jul 13 2009 Soren Sandmann 0.15.16-1 - pixman 0.15.16 prelude-correlator-0.9.0-0.8.beta6.fc12 --------------------------------------- * Fri Jul 10 2009 Steve Grubb 0.9.0-0.8.beta6 - New beta release psi-0.13-0.2.rc3.fc12 --------------------- * Mon Jul 13 2009 Sven Lankes 0.13-0.2.rc3 - 0.13 rc3 - remove qt 4.5 patch pygtk2-2.15.2-2.fc12 -------------------- * Mon Jul 13 2009 Matthew Barnes - 2.15.2-2.fc12 - Add patch for RH bug #511082 (missing gtk-2.16-types.defs). qt-creator-1.2.0-2.fc12 ----------------------- * Mon Jul 13 2009 Itamar Reis Peixoto - 1.2.0-2 - fix BZ #498563 patch from Michel Salim - Update GTK icon cache rrdtool-1.3.8-3.fc12 -------------------- * Mon Jul 13 2009 Remi Collet 1.3.8-3 - rebuild for new PHP 5.3.0 ABI (20090626) ruby-icon-artist-0.1.90-2.fc12 ------------------------------ * Mon Jul 13 2009 Martin Sourada - 0.1.90-2 - Backport fix for correct checking of icon name from git solar-kde-theme-0.1.17-5.fc12 ----------------------------- * Mon Jul 13 2009 Jaroslav Reznik - 0.1.17-5 - Link to F11 system logo spr-3.3.2-1.fc12 ---------------- * Mon Jul 13 2009 Wart - 3.3.2-1 - Update to latest release startup-notification-0.10-1.fc12 -------------------------------- * Mon Jul 13 2009 Matthias Clasen 0.10-1 - Update to 0.10 system-config-language-1.3.2-8.fc12 ----------------------------------- * Mon Jul 13 2009 Pravin Satpute - 1.3.2-8 - fix bug 493858, 507796 tuned-0.1.6-1.fc12 ------------------ * Mon Jul 13 2009 Marcela Ma?l??ov? - 0.1.6-1 - on popular demand update to the latest release with brand new scomes and varnetload uuid-1.6.1-7.fc12 ----------------- * Mon Jul 13 2009 Remi Collet - 1.6.1-7 - rebuild for new PHP 5.3.0 ABI (20090626) - add PHP ABI check - use php_extdir - add php configuration file (/etc/php.d/uuid.ini) valgrind-3.4.1-5 ---------------- * Mon Jul 13 2009 Jakub Jelinek 3.4.1-4 - handle version 3 .debug_frame, .eh_frame, .debug_info and .debug_line (#509197) * Mon Jul 13 2009 Jakub Jelinek 3.4.1-5 - add support for DW_CFA_{remember,restore}_state Summary: Added Packages: 1 Removed Packages: 0 Modified Packages: 88 Broken deps for i386 ---------------------------------------------------------- R-RScaLAPACK-0.5.1-19.fc11.i586 requires openmpi-libs 1:anjuta-2.26.1.0-1.fc12.i586 requires libgdl-1.so.0 bmpx-0.40.14-8.fc11.i386 requires libboost_iostreams-mt.so.4 bmpx-0.40.14-8.fc11.i386 requires libboost_regex-mt.so.4 clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.i586 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.i586 requires gauche = 0:0.8.13 gparted-0.4.5-2.fc12.i586 requires libparted-1.8.so.8 gtranslator-1.9.5-1.fc12.i586 requires libgdl-1.so.0 libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 limph-1.9.5-4.fc11.noarch requires php-mhash limph-hostagent-1.9.5-4.fc11.noarch requires php-mhash maniadrive-1.2-15.fc12.i586 requires libphp5-5.2.10.so maniadrive-track-editor-1.2-15.fc12.i586 requires libphp5-5.2.10.so 1:php-eaccelerator-0.9.5.3-3.fc11.i586 requires php(zend-abi) = 0:20060613 1:php-eaccelerator-0.9.5.3-3.fc11.i586 requires php(api) = 0:20041225 php-idn-1.2-5.fc12.i586 requires php-api = 0:20041225 php-pecl-Fileinfo-1.0.4-5.fc11.i586 requires php-api = 0:20041225 php-pecl-phar-1.2.3-4.fc11.i586 requires php(zend-abi) = 0:20060613 php-pecl-phar-1.2.3-4.fc11.i586 requires php(api) = 0:20041225 pyclutter-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.i386 requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.i386 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.i586 requires libgeos-3.0.3.so python-repoze-what-plugins-sql-1.0-0.5.rc1.fc12.noarch requires python-repoze-who-plugins-sa qtparted-0.4.5-19.fc11.i586 requires libparted-1.8.so.8 raydium-1.2-15.fc12.i586 requires libphp5-5.2.10.so rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.i586 requires libpqxx-2.6.8.so springlobby-0.0.1.10461-1.fc12.i586 requires libtorrent-rasterbar.so.3 syck-php-0.61-8.2.fc11.i586 requires php(api) = 0:20041225 syck-php-0.61-8.2.fc11.i586 requires php(zend-abi) = 0:20060613 thunderbird-lightning-1.0-0.6.20090513hg.fc12.i586 requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 Broken deps for x86_64 ---------------------------------------------------------- R-RScaLAPACK-0.5.1-19.fc11.x86_64 requires openmpi-libs 1:anjuta-2.26.1.0-1.fc12.i586 requires libgdl-1.so.0 1:anjuta-2.26.1.0-1.fc12.x86_64 requires libgdl-1.so.0()(64bit) bmpx-0.40.14-8.fc11.x86_64 requires libboost_regex.so.4()(64bit) bmpx-0.40.14-8.fc11.x86_64 requires libboost_iostreams.so.4()(64bit) clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.x86_64 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.x86_64 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.x86_64 requires gauche = 0:0.8.13 gparted-0.4.5-2.fc12.x86_64 requires libparted-1.8.so.8()(64bit) gtranslator-1.9.5-1.fc12.x86_64 requires libgdl-1.so.0()(64bit) libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.x86_64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 libprojectM-1.2.0-9.fc11.x86_64 requires libftgl.so.0()(64bit) limph-1.9.5-4.fc11.noarch requires php-mhash limph-hostagent-1.9.5-4.fc11.noarch requires php-mhash maniadrive-1.2-15.fc12.x86_64 requires libphp5-5.2.10.so()(64bit) maniadrive-track-editor-1.2-15.fc12.x86_64 requires libphp5-5.2.10.so()(64bit) 1:php-eaccelerator-0.9.5.3-3.fc11.x86_64 requires php(zend-abi) = 0:20060613 1:php-eaccelerator-0.9.5.3-3.fc11.x86_64 requires php(api) = 0:20041225 php-idn-1.2-5.fc12.x86_64 requires php-api = 0:20041225 php-pecl-Fileinfo-1.0.4-5.fc11.x86_64 requires php-api = 0:20041225 php-pecl-phar-1.2.3-4.fc11.x86_64 requires php(zend-abi) = 0:20060613 php-pecl-phar-1.2.3-4.fc11.x86_64 requires php(api) = 0:20041225 pyclutter-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.x86_64 requires libgeos-3.0.3.so()(64bit) python-repoze-what-plugins-sql-1.0-0.5.rc1.fc12.noarch requires python-repoze-who-plugins-sa qtparted-0.4.5-19.fc11.x86_64 requires libparted-1.8.so.8()(64bit) raydium-1.2-15.fc12.i586 requires libphp5-5.2.10.so raydium-1.2-15.fc12.x86_64 requires libphp5-5.2.10.so()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.x86_64 requires libpqxx-2.6.8.so()(64bit) springlobby-0.0.1.10461-1.fc12.x86_64 requires libtorrent-rasterbar.so.3()(64bit) syck-php-0.61-8.2.fc11.x86_64 requires php(api) = 0:20041225 syck-php-0.61-8.2.fc11.x86_64 requires php(zend-abi) = 0:20060613 thunderbird-lightning-1.0-0.6.20090513hg.fc12.x86_64 requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 Broken deps for ppc ---------------------------------------------------------- R-RScaLAPACK-0.5.1-19.fc11.ppc requires openmpi-libs 1:anjuta-2.26.1.0-1.fc12.ppc requires libgdl-1.so.0 1:anjuta-2.26.1.0-1.fc12.ppc64 requires libgdl-1.so.0()(64bit) bmpx-0.40.14-8.fc11.ppc requires libboost_iostreams-mt.so.4 bmpx-0.40.14-8.fc11.ppc requires libboost_regex-mt.so.4 clutter-cairo-0.8.2-3.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.ppc requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.ppc requires gauche = 0:0.8.13 gparted-0.4.5-2.fc12.ppc requires libparted-1.8.so.8 gtranslator-1.9.5-1.fc12.ppc requires libgdl-1.so.0 libchamplain-0.2.9-1.fc11.ppc requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc requires libftgl.so.0 libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) limph-1.9.5-4.fc11.noarch requires php-mhash limph-hostagent-1.9.5-4.fc11.noarch requires php-mhash maniadrive-1.2-15.fc12.ppc requires libphp5-5.2.10.so maniadrive-track-editor-1.2-15.fc12.ppc requires libphp5-5.2.10.so 1:php-eaccelerator-0.9.5.3-3.fc11.ppc requires php(zend-abi) = 0:20060613 1:php-eaccelerator-0.9.5.3-3.fc11.ppc requires php(api) = 0:20041225 php-idn-1.2-5.fc12.ppc requires php-api = 0:20041225 php-pecl-Fileinfo-1.0.4-5.fc11.ppc requires php-api = 0:20041225 php-pecl-phar-1.2.3-4.fc11.ppc requires php(zend-abi) = 0:20060613 php-pecl-phar-1.2.3-4.fc11.ppc requires php(api) = 0:20041225 pyclutter-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.ppc requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.ppc requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.ppc requires libgeos-3.0.3.so python-repoze-what-plugins-sql-1.0-0.5.rc1.fc12.noarch requires python-repoze-who-plugins-sa qtparted-0.4.5-19.fc11.ppc requires libparted-1.8.so.8 raydium-1.2-15.fc12.ppc requires libphp5-5.2.10.so raydium-1.2-15.fc12.ppc64 requires libphp5-5.2.10.so()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc requires libpqxx-2.6.8.so syck-php-0.61-8.2.fc11.ppc requires php(api) = 0:20041225 syck-php-0.61-8.2.fc11.ppc requires php(zend-abi) = 0:20060613 thunderbird-lightning-1.0-0.6.20090513hg.fc12.ppc requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 Broken deps for ppc64 ---------------------------------------------------------- R-RScaLAPACK-0.5.1-19.fc11.ppc64 requires openmpi-libs 1:anjuta-2.26.1.0-1.fc12.ppc64 requires libgdl-1.so.0()(64bit) bmpx-0.40.14-8.fc11.ppc64 requires libboost_regex.so.4()(64bit) bmpx-0.40.14-8.fc11.ppc64 requires libboost_iostreams.so.4()(64bit) clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) gparted-0.4.5-2.fc12.ppc64 requires libparted-1.8.so.8()(64bit) gtranslator-1.9.5-1.fc12.ppc64 requires libgdl-1.so.0()(64bit) libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) limph-1.9.5-4.fc11.noarch requires php-mhash limph-hostagent-1.9.5-4.fc11.noarch requires php-mhash maniadrive-1.2-15.fc12.ppc64 requires libphp5-5.2.10.so()(64bit) maniadrive-track-editor-1.2-15.fc12.ppc64 requires libphp5-5.2.10.so()(64bit) 1:php-eaccelerator-0.9.5.3-3.fc11.ppc64 requires php(zend-abi) = 0:20060613 1:php-eaccelerator-0.9.5.3-3.fc11.ppc64 requires php(api) = 0:20041225 php-idn-1.2-5.fc12.ppc64 requires php-api = 0:20041225 php-pecl-Fileinfo-1.0.4-5.fc11.ppc64 requires php-api = 0:20041225 php-pecl-phar-1.2.3-4.fc11.ppc64 requires php(zend-abi) = 0:20060613 php-pecl-phar-1.2.3-4.fc11.ppc64 requires php(api) = 0:20041225 pyclutter-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.ppc64 requires libgeos-3.0.3.so()(64bit) python-mwlib-0.11.2-2.20090522hg2956.fc12.ppc64 requires LabPlot python-repoze-what-plugins-sql-1.0-0.5.rc1.fc12.noarch requires python-repoze-who-plugins-sa qtparted-0.4.5-19.fc11.ppc64 requires libparted-1.8.so.8()(64bit) raydium-1.2-15.fc12.ppc64 requires libphp5-5.2.10.so()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc64 requires libpqxx-2.6.8.so()(64bit) syck-php-0.61-8.2.fc11.ppc64 requires php(api) = 0:20041225 syck-php-0.61-8.2.fc11.ppc64 requires php(zend-abi) = 0:20060613 thunderbird-lightning-1.0-0.6.20090513hg.fc12.ppc64 requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 From darrellpf at gmail.com Wed Jul 15 02:04:13 2009 From: darrellpf at gmail.com (darrell pfeifer) Date: Tue, 14 Jul 2009 19:04:13 -0700 Subject: gnome applications failing to start In-Reply-To: References: Message-ID: On Tue, Jul 14, 2009 at 14:49, darrell pfeifer wrote: > In rawhide gnome applications are failing to start. > > type array 97 not a basic type > ?D-Bus not built with -rdynamic so unable to print a backtrace > > It seems to be related to attempting to open a file. eog dies at > startup but works when double-clicking a file. gedit just always dies. > gnome-settings-daemon 2.27.4-1.fc12 fixes the problem. darrell From debarshi.ray at gmail.com Wed Jul 15 02:04:55 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Wed, 15 Jul 2009 07:34:55 +0530 Subject: rawhide report: 20090714 changes In-Reply-To: <20090715013303.GA3804@releng2.fedora.phx.redhat.com> References: <20090715013303.GA3804@releng2.fedora.phx.redhat.com> Message-ID: <3170f42f0907141904l10f2222eh5f2a12c5f2085c1a@mail.gmail.com> > ? ? ? ?1:anjuta-2.26.1.0-1.fc12.i586 requires libgdl-1.so.0 > [...] > ? ? ? ?1:anjuta-2.26.1.0-1.fc12.i586 requires libgdl-1.so.0 > ? ? ? ?1:anjuta-2.26.1.0-1.fc12.x86_64 requires libgdl-1.so.0()(64bit) > [...] > ? ? ? ?1:anjuta-2.26.1.0-1.fc12.ppc requires libgdl-1.so.0 > ? ? ? ?1:anjuta-2.26.1.0-1.fc12.ppc64 requires libgdl-1.so.0()(64bit) > [...] > ? ? ? ?1:anjuta-2.26.1.0-1.fc12.ppc64 requires libgdl-1.so.0()(64bit) This should be fixed because I built Anjuta 2.27.3.0 sometime back. Cheers, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig From debarshi.ray at gmail.com Wed Jul 15 02:09:13 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Wed, 15 Jul 2009 07:39:13 +0530 Subject: Champlain In-Reply-To: <1247317285.3215.2.camel@localhost.localdomain> References: <3170f42f0907110406v46117b12mdc102bcf085cb882@mail.gmail.com> <1247315869.2774.4.camel@localhost.localdomain> <3170f42f0907110555t56c4ce34u76254bb797360b29@mail.gmail.com> <1247317285.3215.2.camel@localhost.localdomain> Message-ID: <3170f42f0907141909y1d309a5cj6f37920a9a60e224@mail.gmail.com> According to http://live.gnome.org/libchamplain/schedule they can be expected to use Clutter 1.0 only from 3rd August, which is a day before the Alpha freeze. Cheers, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig From dmc.fedora at filteredperception.org Wed Jul 15 03:54:45 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 14 Jul 2009 21:54:45 -0600 Subject: Feature proposal: Rebootless Installer In-Reply-To: <1247585830.15109.151.camel@localhost> References: <4A5C3C12.9050009@filteredperception.org> <4A5C9185.5010800@filteredperception.org> <1247583885.15109.112.camel@localhost> <4A5CA22A.2030307@filteredperception.org> <4A5CA3CC.7080503@filteredperception.org> <1247585830.15109.151.camel@localhost> Message-ID: <4A5D5305.50504@filteredperception.org> Christoph Wickert wrote: > Am Dienstag, den 14.07.2009, 09:27 -0600 schrieb Douglas McClendon: >> Douglas McClendon wrote: >>> Christoph Wickert wrote: >>>> Am Dienstag, den 14.07.2009, 08:09 -0600 schrieb Douglas McClendon: >>>> 2. Imagine after the installation you switch rebootless to the new >>>> system and install a kmod. But you are still running the kernel >>>> from the installation medium and kmods get installed for the >>>> running kernel, which not necessarily needs to be the one that >>>> was installed. >>> As with a current LiveOS installation, the installation media kernel is >>> the running kernel. (unless the f11 installer already allows you to >>> trigger a chrooted yum update as part of install). >> Ok, I'll show my good fedora developer maturity and call it a 'night' >> now that I'm starting to get sloppy. That should have been worded- >> >> As with a current LiveOS installation, the installation media kernel is >> the running kernel. Even if the f11 installer already allows you to >> trigger a chrooted yum update as part of the install, you won't be >> running the updated kernel until after a reboot. > > There is no chrooted yum update but the updated packages get installed > *instead* of the old ones from the installation media. I believe you are speaking of the most traditional (DVD) installer, and not the LiveOS/CD/USB installer. I just added the following to the feature wiki- clarification note: This is only an alternate method to the current LiveOS installer. This method does not provide any interesting alternative to the old school non-live DVD installer. Though it does provide an alternative for DVD-sized LiveOS spin's installers. This architecture could provide a rebootless equivalent to what it sounds like opensuse achieves with kexec, but that is just an idea with no proof of concept yet, unrelated to this feature. Nor does this feature pertain in any way to upgrade scenarios, just as the current Fedora LiveOS installer does not (I believe) support any kind of upgrade. (I believe vanilla anaconda may be usable to perform upgrades from the current LiveCD, but that is not a use-case that is well documented/advertised. Wiki editors, please confirm/deny) >> Thanks everyone for the vetting so far. > > Thanks a lot for the proposal and the work you've put into it. I'm sure > we all are interested in it, but many of use are just a little skeptical > if it really works out. Please don't let this skepticism scare you. :) No need to worry, I've been around the fedora-devel block once or twice before. The technique/technology here I first published as a bash script on this list a couple years ago. I think what is sinking in is that people need GUIs and lots of clear documentation in order to mitigate their skepticism. It's getting there... Thanks, -dmc From dmc.fedora at filteredperception.org Wed Jul 15 03:59:31 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 14 Jul 2009 21:59:31 -0600 Subject: Feature proposal: Rebootless Installer In-Reply-To: <200907141304.34841.jarod@redhat.com> References: <4A5C3C12.9050009@filteredperception.org> <4A5CA3CC.7080503@filteredperception.org> <20090714155006.GA30757@amd.home.annexia.org> <200907141304.34841.jarod@redhat.com> Message-ID: <4A5D5423.8030702@filteredperception.org> Jarod Wilson wrote: > On Tuesday 14 July 2009 11:50:06 Richard W.M. Jones wrote: >> On Tue, Jul 14, 2009 at 09:27:08AM -0600, Douglas McClendon wrote: >>> ... Same as RebootlessInstaller ... until ksplice ... >> I don't think ksplice changes things -- it seems to only work for very >> minor kernel patches. For example, any change to the layout of a >> kernel structure would appear to be incompatible with ksplice. Thus >> it seems highly unlikely it'll ever work in its current form for >> arbitrary kernel revisions. > > Trying to ksplice from 2.6.29.4 in the installer to say 2.6.30.1 or even > to 2.6.31 does sound like massive fail... > Yes, I was only really referring to the 'idea of ksplice', not it's actual implementation thus far. Or rather, more in an enterprise/LTS scenario like that company dedicated to supporting an extremely stable set of ksplicable kernel packages. Because in the fantasy scenario, with such ksplice, and RebootlessInstaller, a truly rebootless OS lifecycle does become theoretically possible. Which is kind of cool. But that is so bleeding edge it really shouldn't distract from the current decision on this feature. peace... -dmc From dmc.fedora at filteredperception.org Wed Jul 15 04:25:22 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 14 Jul 2009 22:25:22 -0600 Subject: Feature proposal: Rebootless Installer In-Reply-To: <1247589619.3073.1161.camel@localhost.localdomain> References: <4A5C3C12.9050009@filteredperception.org> <4A5C9185.5010800@filteredperception.org> <1247583885.15109.112.camel@localhost> <1247589619.3073.1161.camel@localhost.localdomain> Message-ID: <4A5D5A32.1090406@filteredperception.org> Jesse Keating wrote: > On Tue, 2009-07-14 at 11:19 -0400, Colin Walters wrote: >> There's no such step in the live install (right?). Now, it would >> likely make sense to have such a mechanism, but it would need design. >> I forget offhand too how the PackageKit updater works in the live >> image (do we disable it by default?). > > With the Anaconda live installer, it's the raw unmodified live > filesystem that is "copied" to the newly partitioned disk(s). Ergo any > rpm updating you do on the LiveOS before you start the installer will be > lost. > > It appears that Doglas' installer uses the in use LiveOS so that the > changes you make while running the LiveOS before starting the install > will be carried over into the install. Douglas, JDog, whatever... But correct characterization, with the added 'changes you make while running the LiveOS before, during, and after starting the install will be carried over into the install'. > > That in itself seems interesting enough to explore and see if we can't > get the same functionality, to some extent into Anaconda. Yes, this is a subtle distinction you have made. An entirely different feature, could be to simply run the current LiveOS installer as is, except instead of using the pristine (i.e. pre-boot, no changes from the running LiveOS) image, you could use a snapshot of the image as it is at the time of the start of installation. That would go back to your wording above instead of my correction, i.e. only changes made prior to the start of installation would get copied over, _and_ you would then need to reboot into the new OS as is currently normal. > > As for rebootless, that's interesting too. I'm glad you were able to > demo the technology within your installer, but I'd worry about the > duplication of effort/code to have yet another program that is designed > to discover disks,... There is a lot of logic code in > Anaconda to get the partitioning correct .... This is all I believe 100% in line with what I said in the progenitor/top post. If this feature is to remain in Fedora in the longterm, Anaconda is absolutely the right place for it, for all the reasons you mentioned. However, even though over a year ago I had skimmed all the relevant parts of anaconda, the reason I chose to go the route I did were a) lack of complexity. The first iteration of my installer was just a 100 line bash script. Thus narrowing my task to just writing a GUI front end for it, simplified things. b) educational value- This was a great, relatively simple, pygtk-glade exercise for me. c) the whole unionfs issue. There is *very real possibility* that Fedora may decide to go the ubuntu LiveOS architecture once a solid unionfs is in mainline. Depending on implementation- if going with the ubuntu native squashfs for instance, it may then be impossible to have RebootlessInstallation as an additional optional feature on the same LiveOS. I will be more than happy making or helping to make the anaconda implementation of this feature, if I can be assured that it will have some longevity. I really think going with zyx-liveinstaller (my thing) for F12 is the right answer to put this feature out there before people, to determine if it is something that we want to really start doing some serious additions to anaconda for. Perhaps jkatz or others can and don't mind just whipping up an anaconda implementation in the next few weeks. But I didn't see much(any) interest on fedora-livecd-list, and I'm making a wild guess here- that everybody (especially those getting paychecks) have plenty on their plate in the near future already. > > I think your work is great and useful though! That means a lot. Back at you 10X, I know you and others here have done vast amounts of very hard, often unrewarding work keeping Fedora in shape. peace... -dmc From dmc.fedora at filteredperception.org Wed Jul 15 04:32:12 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 14 Jul 2009 22:32:12 -0600 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5CC258.8010100@bfccomputing.com> References: <4A5C3C12.9050009@filteredperception.org> <4A5C9185.5010800@filteredperception.org> <1247583885.15109.112.camel@localhost> <4A5CC258.8010100@bfccomputing.com> Message-ID: <4A5D5BCC.1000901@filteredperception.org> Bill McGonigle wrote: > On 07/14/2009 11:04 AM, Christoph Wickert wrote: >> 2. Imagine after the installation you switch rebootless to the new >> system and install a kmod. But you are still running the kernel >> from the installation medium and kmods get installed for the >> running kernel, which not necessarily needs to be the one that >> was installed. > > Would it be feasible to fetch the current kernel from the 'net (if > possible/permitted) and kexec into it before proceeding with the install? Short answer- Yes. Though mainly for systems with 1+G ram and/or usb persistence, because a kernel and anaconda upgrade will take a healthy chunk of space in the overlay. I do like this idea, for instance, as an optional bootloader choice. The key thing though, is this would have to happen, _at boot up_. I.e. to get the kexec out of the way before the user dives into things. Otherwise the user has to see a kexec reboot, which while skipping the BIOS, is still a 'reboot experience'. But this is not at all within the scope of the currently proposed feature. > > With liveUSB there's persistence, but is there a way to have a ramdisk > survive kexec for liveCD? Hmm... Short answer- I don't know. If not now, it's probably just a kexec kernel feature enhancement away to find a way to protect some arbitrary hunk of ram during kexec. > > Heck, fetch the latest anaconda too, and get rid of some of the zero-day > problems we have that require respins now. Yes, as above, I agree that would be a pretty cool feature (again, beyond the scope of the one currently being discussed). peace... -dmc From dmc.fedora at filteredperception.org Wed Jul 15 04:42:49 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 14 Jul 2009 22:42:49 -0600 Subject: Feature proposal: Rebootless Installer In-Reply-To: References: <4A5C3C12.9050009@filteredperception.org> <4A5C6AC5.4060102@earthlink.net> <4A5C6E4E.1080603@filteredperception.org> Message-ID: <4A5D5E49.90305@filteredperception.org> Colin Walters wrote: > On Tue, Jul 14, 2009 at 7:38 AM, Douglas > McClendon wrote: > >> If so, one way to describe the major >> benefit of my rebootless installer, is that you get to boot the livecd/usb >> environment, *then use it as such*, and at your option, desire, and >> convenience, decide to permanently install the LiveOS you have just been >> using and configuring, to disk. And of course when done, just pop out the >> livecd/usb, and your are done... and free to leave your system with a >> continuingly increasing uptime :) > > Wait, so it's persisting any changes you made to the target drive? yup. > That sounds quite cool actually, and I misunderstood the original > post. Concretely with your change, if I've connected to a wireless > network with NetworkManager, that would get saved in the target > drive's configuration in gconf and be there next time I boot? yup. > I know with the live images one problem we have is that data can sort > of randomly disappear if you're running close to the memory limit; if yes, and this is one motivation to possibly switch to a unionfs LiveOS architecture, which would preclude my feature from working. Note that unionfs doesn't magically defeat this problem, it just suffers differently. I.e. a different set (but similar kind) of tradeoffs, that clearly the ubuntu and lots of other folks think is better (maybe not by a lot, but by enough). In any event, the current feature proposal does not address this (though I've suggested other ideas on fedora-livecd-list over the years on ways to mitigate the pain). Really, the coolest way to mitigate the pain, would be if you could pass a boot cmdline flag to the kernel, such that ext3/4 would have a preference for block(?) allocation, i.e. always preferring blocks that have been used and freed, instead of blocks that had never been used. If that could be done, that would go _a long_ way in mitigating the pain of the devicemapper LiveOS architecture. But I'm getting off track of the feature under consideration... > we go with your architecture we should probably special-case things > like ~/.gconf so say the Firefox http disk cache doesn't blow away > your wireless config. Uh... yes. And if I understand you correctly, that is not limited to my new feature, and should just be done period, because it helps out just as much for normal LiveOS usage. It would just have to be another one those things done in /etc/rc.d/init.d/livesys that my installer would have to undo at the end of installation. peace... -dmc From xiashing at gmail.com Wed Jul 15 05:03:31 2009 From: xiashing at gmail.com (Xia Shing Zee) Date: Wed, 15 Jul 2009 15:03:31 +1000 Subject: New maintainer needed: dumpasn1, freedroid, http_ping, id3v2, pscan, zzuf In-Reply-To: <200907142333.36151.ville.skytta@iki.fi> References: <200907012321.43913.ville.skytta@iki.fi> <954b158e0907011826o5d9013aag85f537370cac2999@mail.gmail.com> <200907030046.05420.ville.skytta@iki.fi> <200907142333.36151.ville.skytta@iki.fi> Message-ID: <954b158e0907142203r59faaaffkc9b43d687ecdcb38@mail.gmail.com> It seems I can't as I'm not officially a packager. :( On Wed, Jul 15, 2009 at 6:33 AM, Ville Skytt? wrote: > On Friday 03 July 2009, Ville Skytt? wrote: > > On Thursday 02 July 2009, Xia Shing Zee wrote: > > > I'm a new package maintainer, but I'll try dumpasn1 and id3v2 > > > > Thanks (ditto to the others who grabbed the rest of the packages). > Please > > go ahead and take ownership of these in pkgdb, they have been orphaned > > already. > > I see you applied for F-11 watchbugzilla and watchcommits for dumpasn1 and > id3v2, but that's not enough for them to be unorphaned. Click the "Take > ownership" button to accomplish that, and I suggest doing that for Fedora > devel as well in addition to F-11. > > -- > 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 mail at marcus-moeller.de Wed Jul 15 06:05:07 2009 From: mail at marcus-moeller.de (Marcus Moeller) Date: Wed, 15 Jul 2009 08:05:07 +0200 Subject: Purging the F12 orphans In-Reply-To: <4A5D06FB.7060809@fedoraproject.org> References: <1247589637.3073.1162.camel@localhost.localdomain> <4A5D06FB.7060809@fedoraproject.org> Message-ID: Hi all. >> Unblocked orphan f-spot f-spot was only mentioned on Jesse's first list, so I wonder if it's still listed as orphaned? > I'm using f-spot occasionally and since I'm already helping out with > some of the mono packages I'm taking ownership of this one. If interested I would offer my help on that package as co-maintainer. Best Regards Marcus From oget.fedora at gmail.com Wed Jul 15 06:43:23 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Wed, 15 Jul 2009 02:43:23 -0400 Subject: Fedora rawhide rebuild in mock status 2009-07-10 x86_64 In-Reply-To: References: <20090714182235.GA1967@mock.linuxdev.us.dell.com> Message-ID: On Tue, Jul 14, 2009 at 6:10 PM, Orcan Ogetbil wrote: > On Tue, Jul 14, 2009 at 2:22 PM, Matt Domsch wrote: >> >> oget: calf,fluidsynth,hydrogen,jack-keyboard,lash,muse,tex-musixtex >> > > All except the last one is due to the e2fsprogs split and I'm fixing them. > > But the last one may be an rpm or mock issue. I don't know what to do. > Any ideas? > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/x86_64/tex-musixtex-0.114-6.rev4.fc11.src.rpm/result/build.log > > Orcan > Now the same package built fine as scratch: https://koji.fedoraproject.org/koji/taskinfo?taskID=1474620 Weird... Broken builder? Orcan From sahartsu at xs4all.nl Wed Jul 15 07:11:50 2009 From: sahartsu at xs4all.nl (S.A. Hartsuiker) Date: Wed, 15 Jul 2009 09:11:50 +0200 Subject: Against what do I file this bug? In-Reply-To: <4A5D154A.1070009@xs4all.nl> References: <4A5D10B5.8000004@xs4all.nl> <4A5D154A.1070009@xs4all.nl> Message-ID: <4A5D8136.5070108@xs4all.nl> On 07/15/2009 01:31 AM, S.A. Hartsuiker wrote: > On 07/15/2009 01:24 AM, Matthew Woehlke wrote: >> S.A. Hartsuiker wrote: >>> Now for my problem. Although Anaconda installed grub in the bootsector >>> of the fakeraid mirrored device, I never actually get to a grub prompt, >>> it just loads the kernel. >> >> Um... do you mean that grub loads the latest kernel without pausing to >> ask if that's what you want? Because as I understand that is intended >> behavior with F11 (with F10 already, I want to say). Hold some key >> during boot to get the grub menu (ctrl works well, being unused by most >> BIOS's). > > Ok, this is a pebkac. Apparently it's just a very short timeout now. > Keeping a key pressed after POST, but before I see any mention of grub > seems to work. > >> >>> Presumably due to the possibility that grub can't find the /boot >>> partition. >> >> This makes no sense. If grub was failing to find /boot, you would get a >> grub error, since there would be nothing for it to boot (nor would it >> find grub.conf, I think). IOW, you would get slightly farther than the >> BIOS failing to find a MBR, but certainly no maintenance mode (which >> implies a roughly-functional kernel and initrd). > > Yes, see above. > >> >>> However during the mounting stage of the boot process the /boot >>> partition can also not be found and I am dropped into maintance mode. >> >> This sounds like an initrd problem to me, but I am no expert. >> > Uhm, no. I am in the ''Fedora Interactive'' bit, the /etc/rc.d/rc.sysinit at that moment. From jzeleny at redhat.com Wed Jul 15 07:16:26 2009 From: jzeleny at redhat.com (Jan =?utf-8?q?Zelen=C3=BD?=) Date: Wed, 15 Jul 2009 09:16:26 +0200 Subject: How to contact =?utf-8?b?VG9tw6HFoSBCxb5hdGVrPw==?= In-Reply-To: <1247592002.15109.209.camel@localhost> References: <1247592002.15109.209.camel@localhost> Message-ID: <200907150916.26646.jzeleny@redhat.com> Dne ?ter? 14 ?ervence 2009 19:20:02 Christoph Wickert napsal(a): > Anybody knows how to contact Tom?? B?atek? Is he still working for Red > Hat? I see he has a lot of open bugs (some of them are just getting > closed by the bugzappers) without a single comment from him. I set one > to NEEDINFO but didn't get a response for months. > > Already time for AWOL procedure? [1] He usually sits next to me, I'll let him know to pay attention to this thread (or your attempts to contact him). AFAIK he's on vacation this and the next week, then he should be available. -- Jan From christoph.wickert at googlemail.com Wed Jul 15 07:21:05 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Wed, 15 Jul 2009 09:21:05 +0200 Subject: Fedora rawhide rebuild in mock status 2009-07-10 x86_64 In-Reply-To: <20090714215722.GA24214@auslistsprd01.us.dell.com> References: <20090714182235.GA1967@mock.linuxdev.us.dell.com> <1247600517.15109.326.camel@localhost> <20090714215722.GA24214@auslistsprd01.us.dell.com> Message-ID: <1247642465.2743.16.camel@localhost> Am Dienstag, den 14.07.2009, 16:57 -0500 schrieb Matt Domsch: > On Tue, Jul 14, 2009 at 09:41:57PM +0200, Christoph Wickert wrote: > > Am Dienstag, den 14.07.2009, 13:22 -0500 schrieb Matt Domsch: > > > > > cwickert: gwget,lxappearance,lxlauncher,lxsession-edit,lxshortcut > > > > The epiphany extension of gwget is known to be broken. Already reported > > upstream: http://bugzilla.gnome.org/show_bug.cgi?id=585401 > > Should I disable it for now? So should I or should I not? > > The rest are false positives. All have been updated last week without > > problems and I verified they still build with a couple scratch builds: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1473863 > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1473873 > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1473864 > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1473905 > > > > There must be something wrong with your builds: > > lxappearance: build.log is 33 MB > > lxlauncher: build.log is 46 MB > > lxsession-edit: build.log is 19 MB > > lxshortcut: build.log is 17 MB > > make got very upset... But only on your buildsys but not in Fedora's. I think you should stop your script from mass-filing bugs until you found the error on your side, because a high percentage are false positives. Regards, Christoph From christoph.wickert at googlemail.com Wed Jul 15 07:31:13 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Wed, 15 Jul 2009 09:31:13 +0200 Subject: How to contact =?utf-8?b?VG9tw6HFoSBCxb5hdGVrPw==?= In-Reply-To: <200907150916.26646.jzeleny@redhat.com> References: <1247592002.15109.209.camel@localhost> <200907150916.26646.jzeleny@redhat.com> Message-ID: <1247643073.2743.23.camel@localhost> Am Mittwoch, den 15.07.2009, 09:16 +0200 schrieb Jan Zelen?: > Dne ?ter? 14 ?ervence 2009 19:20:02 Christoph Wickert napsal(a): > > Anybody knows how to contact Tom?? B?atek? Is he still working for Red > > Hat? I see he has a lot of open bugs (some of them are just getting > > closed by the bugzappers) without a single comment from him. I set one > > to NEEDINFO but didn't get a response for months. > > > > Already time for AWOL procedure? [1] > > He usually sits next to me, I'll let him know to pay attention to this thread > (or your attempts to contact him). Thanks Jan, not necessary, just tell him to please pay attention to his bug reports (especially if they already contain the solution or if they are set to NEEDINFO assignee). I just wanted to make sure he's still around because I could not find any activity from him in Bugzilla or CVS for quite some time and I was afraid, the bugs were assigned to somebody who no longer works for Red Hat. Regards, Christoph From sundaram at fedoraproject.org Wed Jul 15 07:32:48 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Jul 2009 13:02:48 +0530 Subject: How to contact =?utf-8?b?VG9tw6HFoSBCxb5hdGVrPw==?= In-Reply-To: <1247643073.2743.23.camel@localhost> References: <1247592002.15109.209.camel@localhost> <200907150916.26646.jzeleny@redhat.com> <1247643073.2743.23.camel@localhost> Message-ID: <4A5D8620.2060005@fedoraproject.org> On 07/15/2009 01:01 PM, Christoph Wickert wrote: > > I just wanted to make sure he's still around because I could not find > any activity from him in Bugzilla or CVS for quite some time and I was > afraid, the bugs were assigned to somebody who no longer works for Red > Hat. IIRC, a recent process change ensures that if someone leaves Red Hat, the bugs are automatically reassigned to the person taking over. It should be transparent. Rahul From jdieter at gmail.com Wed Jul 15 07:46:21 2009 From: jdieter at gmail.com (Jonathan Dieter) Date: Wed, 15 Jul 2009 10:46:21 +0300 Subject: Purging the F12 orphans In-Reply-To: <1247594323.3073.1169.camel@localhost.localdomain> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> Message-ID: <1247643981.2643.0.camel@jdlaptop.lesbg.loc> On Tue, 2009-07-14 at 10:58 -0700, Jesse Keating wrote: > Unblocked orphan tremulous-data Shouldn't this be owned by whoever owns tremulous? It's the data files for the game. 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 jreznik at redhat.com Wed Jul 15 08:27:10 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Wed, 15 Jul 2009 10:27:10 +0200 Subject: NVR bugs in rawhide In-Reply-To: <4A5C3FF9.3010903@redhat.com> References: <4A5C3FF9.3010903@redhat.com> Message-ID: <200907151027.10901.jreznik@redhat.com> On Tuesday 14 July 2009 10:21:13 Daniel Mach wrote: > I found 375 possibly wrong NVRs in rawhide. > Can you check it an fix it, please? > I'd like to file bugs for those which won't get fixed in couple weeks. kde-settings-4.2-10.20090430svn.fc11.src.rpm - Pre-release build's release should start with '0.'. It's not a pre-release but regular snapshot from our SVN repository. We don't have releases. Jaroslav From jreznik at redhat.com Wed Jul 15 08:39:56 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Wed, 15 Jul 2009 10:39:56 +0200 Subject: Fedora 12 Features Needing Updates In-Reply-To: References: <4A5D0D99.4040409__39087.9116407179$1247612486$gmane$org@redhat.com> Message-ID: <200907151039.56247.jreznik@redhat.com> On Wednesday 15 July 2009 02:28:07 Ben Boeckel wrote: > John Poelstra wrote: > > https://fedoraproject.org/wiki/Features/KDE43 > > I updated this since both Rex is on vacation and Kevin is most > likely as well. Hi Ben, don't forget to update "Updated" column on Feature List page [1]. I often forget either :D It's updated now. [1] https://fedoraproject.org/wiki/Releases/12/FeatureList Jaroslav > --Ben From mschwendt at gmail.com Wed Jul 15 08:47:35 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 15 Jul 2009 10:47:35 +0200 Subject: NVR bugs in rawhide In-Reply-To: <4A5D19D4.3090207@freenet.de> References: <4A5C3FF9.3010903@redhat.com> <20090714111532.4b688163@faldor> <4A5C7848.20608@redhat.com> <20090714144853.19816cfc@faldor> <1247575691.3164.2.camel@politzer.theorphys.helsinki.fi> <20090714153737.785463f7@faldor> <4A5C8FCE.40905@freenet.de> <20090714173602.2fa06b11@faldor> <4A5CAA22.3090701@freenet.de> <20090714181410.2d2ff8f4@faldor> <4A5D19D4.3090207@freenet.de> Message-ID: <20090715104735.297e5a55@faldor> On Wed, 15 Jul 2009 01:50:44 +0200, Ralf wrote: > Michael Schwendt wrote: > > On Tue, 14 Jul 2009 17:54:10 +0200, Ralf wrote: > > > >> Michael Schwendt wrote: > >>> On Tue, 14 Jul 2009 16:01:50 +0200, Ralf wrote: > >>> > >>>>> You don't need to drop %dist for koji build inheritance to work. > >>>>> > >>>>> It just looks much cleaner to inherit foo-1.0-1.noarch.rpm for all > >>>>> newer targets > >>>> IFF "current rpm" is sufficiently compatible to the antique version of > >>>> rpm a package has been built on. > >>>> > >>>> If this doesn't apply you don't get anywhere. > >>> Not _with_ %dist either. > >> Of cause it would help. A package's release tag would very verbosely > >> tell you that a package is outdated. > > > > And still it would fail if RPM were changed [the way you describe] while > > %dist stayed the same. > Right, the key being using %?dist is _rebuilding_. It's insufficient. %dist alone doesn't tell anything about ABI compatibility or compatibility of products/packages in general. Further, when you need to mass-rebuild more than once you cannot rely on %dist. And because %dist changes too slowly, you still need to bump %release whenever you rebuild something. [Theoretically, when %dist changes, one could create new cvs tag _without_ committing an increased %release tag, but this is not what has been done so far, as such rebuilds would not have a %changelog entry, for example.] > > %dist doesn't reflect at all whether RPM changes > > its file format near the beginning of a Fedora devel cycle. > Right, but unlike hidden build dates etc. it is clearly _visible_. Still, it's not accurate enough to jump to conclusions about whether a package needs a rebuild or not. > >>>> => I agree with Jussi. Allowing people not to use %dist is not helpful. > >>>> It's a booby trap which certainly will hit some day. > >>> %dist is a trap itself - packagers run into it regularly, e.g. when > >>> adding Obsoletes and versioned dependencies, when doing trial-and-error > >>> fixing of old branches (without paying attention to the recommendations in > >>> the guidelines), when committing and tagging after a server-side update of > >>> the "branches" file. > >> Quite easy to overcome: always use %?dist. > > > > Doesn't help much. Packager still needs to bump all branches [correctly] > > to recover. > Not true. He needs to rebuild rawhide, not all branches. The tag for F[N-1] %dist is occupied by "devel" cvs, so clearly it's necessary to bump'n'rebuild at least _two_ branches after the "cvs up common". (if you don't want to cheat and build the F[N-1] pkg from the tag on the "wrong" cvs dir) The problem is not specific to using %dist, but with packages where using %dist doesn't add any value (e.g. those where %version makes big jumps only during the devel period), you are unlikely to run into it anyway. Probably we can end this thread. I'm aware of the small benefit of using %dist for src.rpm pkgs that shall be copied to multiple target branches in cvs _without modification_. That's the only thing where %dist aids the packager. It doesn't "fix" anything else. [It doesn't wipe out upgrade path problems either, just think about that please before making a rushed reply.] Using %dist isn't safe (or "more safe") than not using %dist. There are pitfalls. From mschwendt at gmail.com Wed Jul 15 09:28:45 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 15 Jul 2009 11:28:45 +0200 Subject: bchunk: dead package In-Reply-To: <200907141230.03271.cemeyer@u.washington.edu> References: <20090714125634.7ee22a57@faldor> <200907141230.03271.cemeyer@u.washington.edu> Message-ID: <20090715112845.258113e2@faldor> On Tue, 14 Jul 2009 12:30:03 -0700, Conrad wrote: > From reading the ticket[0], it looks like the Debian patch solves the issue -- > I would like to take the package. > > [0]: https://bugzilla.redhat.com/show_bug.cgi?id=439661 You will need the help of somebody with admin powers to give you ownership in pkgdb and a releng request to bring back bchunk in koji dist-f12 (the reverse of releng ticket 1977). From alsadi at gmail.com Wed Jul 15 10:54:34 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Wed, 15 Jul 2009 13:54:34 +0300 Subject: Fedora 12 Features Needing Updates In-Reply-To: <200907151039.56247.jreznik@redhat.com> References: <4A5D0D99.4040409__39087.9116407179$1247612486$gmane$org@redhat.com> <200907151039.56247.jreznik@redhat.com> Message-ID: <385866f0907150354x68df8806w6dbfbc29bcd76205@mail.gmail.com> I proposed this feature https://fedoraproject.org/wiki/Features/MediaRepo and I implemented the solution for yumex (about 25%) and contacted the upstream (he asked me to do that in yumex nextgen and that's not a problem) the next step is to do that in PK (another 25%) I hope I can do that today 50% is to clean up the CDROM mounting routines because they use old HAL code I was advised to use GIO and GVolumeMonitor because DeviceKit-disks API won't be stable in F12 nor F13 regardless of any of those factors, what should I do to make this feature be part of F12 features ? From mschmidt at redhat.com Wed Jul 15 12:12:32 2009 From: mschmidt at redhat.com (Michal Schmidt) Date: Wed, 15 Jul 2009 14:12:32 +0200 Subject: Purging the F12 orphans In-Reply-To: <1247594323.3073.1169.camel@localhost.localdomain> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> Message-ID: <20090715141232.0b13a730@leela> Dne Tue, 14 Jul 2009 10:58:43 -0700 Jesse Keating napsal(a): > Unblocked orphan tpm-tools I've taken tpm-tools. Michal From Matt_Domsch at dell.com Wed Jul 15 12:19:56 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 15 Jul 2009 07:19:56 -0500 Subject: Fedora rawhide rebuild in mock status 2009-07-10 x86_64 In-Reply-To: <1247642465.2743.16.camel@localhost> References: <20090714182235.GA1967@mock.linuxdev.us.dell.com> <1247600517.15109.326.camel@localhost> <20090714215722.GA24214@auslistsprd01.us.dell.com> <1247642465.2743.16.camel@localhost> Message-ID: <20090715121956.GA28902@auslistsprd01.us.dell.com> On Wed, Jul 15, 2009 at 09:21:05AM +0200, Christoph Wickert wrote: > Am Dienstag, den 14.07.2009, 16:57 -0500 schrieb Matt Domsch: > > On Tue, Jul 14, 2009 at 09:41:57PM +0200, Christoph Wickert wrote: > > > Am Dienstag, den 14.07.2009, 13:22 -0500 schrieb Matt Domsch: > > > > > > > cwickert: gwget,lxappearance,lxlauncher,lxsession-edit,lxshortcut > > > > > > The epiphany extension of gwget is known to be broken. Already reported > > > upstream: http://bugzilla.gnome.org/show_bug.cgi?id=585401 > > > Should I disable it for now? > > So should I or should I not? Depends on how long you expect before upstream will have a fix in place. Right now the package just fails to rebuild. That's not a problem for most end users. However, rel-eng is investigating doing a mass rebuild for F12. If at the point that's ready to go, the package still doesn't build, yes, disabling that extension would be appropriate. > > > The rest are false positives. All have been updated last week without > > > problems and I verified they still build with a couple scratch builds: > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1473863 > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1473873 > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1473864 > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1473905 > > > > > > There must be something wrong with your builds: > > > lxappearance: build.log is 33 MB > > > lxlauncher: build.log is 46 MB > > > lxsession-edit: build.log is 19 MB > > > lxshortcut: build.log is 17 MB > > > > make got very upset... > > But only on your buildsys but not in Fedora's. I think you should stop > your script from mass-filing bugs until you found the error on your > side, because a high percentage are false positives. I don't think it's a "high percentage". There may be a few false positives, for which I'm sorry. But most are actual problems, either with the package noted, or with a dependency. The e2fsprogs/uuid split caught several apps. One difference between the Fedora buildsystem and mine is the environment running on the builders. While Fedora's builders run essentially RHEL5 plus specific fixes (e.g. newer RPM), mine are running Fedora 11. I strongly believe that Fedora needs to be capable of "self-hosting". But besides that, it's using mock, and a rawhide tree as of a given day as the buildroot. I'm re-running the failed builds right now, and I'll dig into those that succeed now, when they failed before. -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From sundaram at fedoraproject.org Wed Jul 15 12:25:10 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Jul 2009 17:55:10 +0530 Subject: Fedora rawhide rebuild in mock status 2009-07-10 x86_64 In-Reply-To: <20090715121956.GA28902@auslistsprd01.us.dell.com> References: <20090714182235.GA1967@mock.linuxdev.us.dell.com> <1247600517.15109.326.camel@localhost> <20090714215722.GA24214@auslistsprd01.us.dell.com> <1247642465.2743.16.camel@localhost> <20090715121956.GA28902@auslistsprd01.us.dell.com> Message-ID: <4A5DCAA6.6070208@fedoraproject.org> On 07/15/2009 05:49 PM, Matt Domsch wrote: > One difference between the Fedora buildsystem and mine is the > environment running on the builders. I assume you are scripting the whole process. Are those available publically for those who want to setup something similar in their own infrastructure? Rahul From tcallawa at redhat.com Wed Jul 15 12:55:20 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 15 Jul 2009 08:55:20 -0400 Subject: NVR bugs in rawhide In-Reply-To: <1247582029.3469.54.camel@localhost.localdomain> References: <4A5C3FF9.3010903@redhat.com> <20090714111532.4b688163@faldor> <4A5C7848.20608@redhat.com> <20090714144853.19816cfc@faldor> <1247575691.3164.2.camel@politzer.theorphys.helsinki.fi> <4A5C82B6.7070204@redhat.com> <1247582029.3469.54.camel@localhost.localdomain> Message-ID: <4A5DD1B8.2070709@redhat.com> On 07/14/2009 10:33 AM, Dennis Gregorovic wrote: > In F11 Everything, there are 211 i386 packages without the dist tag and > just 81 noarch packages without the dist tag. So, it's definitely not > just the noarch packages that aren't using the dist tag. I didn't mean to imply that was the case. I was specifically focusing on the most common case where people don't want to use the dist tag, and the one referenced in the bugzilla ticket a few posts up in the thread. > Personally, I think that the dist tag usage should be strongly > encouraged for all packages. It makes rebuilds and upgrade easier and > the only potential downside is a small cosmetic one. I agree, and would hope that the widespread adoption of it means that others agree as well. :) ~spot From jdieter at gmail.com Wed Jul 15 13:06:11 2009 From: jdieter at gmail.com (Jonathan Dieter) Date: Wed, 15 Jul 2009 16:06:11 +0300 Subject: Purging the F12 orphans In-Reply-To: <1247594323.3073.1169.camel@localhost.localdomain> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> Message-ID: <1247663171.2530.0.camel@jdlaptop.lesbg.loc> On Tue, 2009-07-14 at 10:58 -0700, Jesse Keating wrote: > Unblocked orphan buoh I've taken buoh. 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 mike at cchtml.com Wed Jul 15 13:15:56 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Wed, 15 Jul 2009 08:15:56 -0500 Subject: Purging the F12 orphans In-Reply-To: <1247595460.3916.61.camel@pc-notebook.kolej.mff.cuni.cz> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> <1247595460.3916.61.camel@pc-notebook.kolej.mff.cuni.cz> Message-ID: <4A5DD68C.6030205@cchtml.com> Martin Sourada on 07/14/2009 01:17 PM wrote: > On Tue, 2009-07-14 at 10:58 -0700, Jesse Keating wrote: >> Unblocked orphan gtk-murrine-engine > I'm taking over this one. Co-maintainers welcomed. > Could you post an update to 0.9.x for F11? I see one in rawhide, but there's some themes that need 0.9.x and that particular version has been out for a while. If you need a bug I'll post one. From mclasen at redhat.com Wed Jul 15 13:33:04 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 15 Jul 2009 09:33:04 -0400 Subject: Fedora 12 Features Needing Updates In-Reply-To: <385866f0907150354x68df8806w6dbfbc29bcd76205@mail.gmail.com> References: <4A5D0D99.4040409__39087.9116407179$1247612486$gmane$org@redhat.com> <200907151039.56247.jreznik@redhat.com> <385866f0907150354x68df8806w6dbfbc29bcd76205@mail.gmail.com> Message-ID: <1247664784.13459.1.camel@planemask> On Wed, 2009-07-15 at 13:54 +0300, Muayyad AlSadi wrote: > > regardless of any of those factors, what should I do to make this > feature be part of F12 features ? > Put your feature in the category FeatureReadyForWrangler when your feature page is sufficiently complete. Its all explained here: http://www.fedoraproject.org/wiki/Features/Policy From jarod at redhat.com Wed Jul 15 13:37:54 2009 From: jarod at redhat.com (Jarod Wilson) Date: Wed, 15 Jul 2009 09:37:54 -0400 Subject: Purging the F12 orphans In-Reply-To: <1247594323.3073.1169.camel@localhost.localdomain> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> Message-ID: <200907150937.54541.jarod@redhat.com> On Tuesday 14 July 2009 13:58:43 Jesse Keating wrote: > On Tue, 2009-07-14 at 09:40 -0700, Jesse Keating wrote: > > > > It's that time of the release cycle again, to purge the orphans before > > we get to feature freeze. Any unblocked orphans will be purged by the > > 28th of this month. Here is a current list of unblocked orphans: > > The first list was incomplete due to an API change. Here is the > complete list: ... > Unblocked orphan ctrlproxy User 'bernie' has watchbugzilla, watchcommits, commit and approveacls on ctrlproxy, but not ownership. He's more than welcome to take over ownership too, but for the moment, I've taken ownership of the devel branch to stave off purging, since I use ctrlproxy myself... -- Jarod Wilson jarod at redhat.com From henriquecsj at gmail.com Wed Jul 15 14:00:37 2009 From: henriquecsj at gmail.com (Henrique Junior) Date: Wed, 15 Jul 2009 11:00:37 -0300 Subject: Purging the F12 orphans In-Reply-To: <200907150937.54541.jarod@redhat.com> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> <200907150937.54541.jarod@redhat.com> Message-ID: <4f629b520907150700g75b2d11al7438838548f75b04@mail.gmail.com> fmit is not ready yet. The package was being made by another maintainer. Without knowing that he had already started a review I've started another review request, when I realized that someone had already started the package I've canceled my request. The package was accepted and the CVS was created, but there was still some small problems that should be solved in the package and the first maintainer, for personal reasons, resigned. He asked me if I would like to take the package. I am still working on it now. 2009/7/15 Jarod Wilson > On Tuesday 14 July 2009 13:58:43 Jesse Keating wrote: > > On Tue, 2009-07-14 at 09:40 -0700, Jesse Keating wrote: > > > > > > It's that time of the release cycle again, to purge the orphans before > > > we get to feature freeze. Any unblocked orphans will be purged by the > > > 28th of this month. Here is a current list of unblocked orphans: > > > > The first list was incomplete due to an API change. Here is the > > complete list: > ... > > Unblocked orphan ctrlproxy > > User 'bernie' has watchbugzilla, watchcommits, commit and approveacls > on ctrlproxy, but not ownership. He's more than welcome to take over > ownership too, but for the moment, I've taken ownership of the devel > branch to stave off purging, since I use ctrlproxy myself... > > -- > Jarod Wilson > jarod at redhat.com > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Henrique "LonelySpooky" Junior http://www.lonelyspooky.com ------------------------------------------------------------- "In a world without walls and fences, who needs windows and gates?!" -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmz at pobox.com Wed Jul 15 14:01:07 2009 From: tmz at pobox.com (Todd Zullinger) Date: Wed, 15 Jul 2009 10:01:07 -0400 Subject: Any asciidoc users? Message-ID: <20090715140107.GQ19992@inocybe.localdomain> I'm not sure how widely used asciidoc is around here. Both git and tig use it to build their documentation and have been hit by bug 506953?. I think this bug may hit many other users of asciidoc as well, making our current packages a bit annoying to use for many projects. If any other asciidoc users have run into spurious 'unsafe: include file' errors since asciidoc was updated to 8.4.5 (F-11 and devel), your help confirming that the patch I posted to the bug report helps and doesn't hurt would be most welcome. (Even if you haven't hit the 'unsafe: include file' errors, your testing would be great.) ? https://bugzilla.redhat.com/506953 -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A person who smiles in the face of adversity ... probably has a scapegoat. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From msuchy at redhat.com Wed Jul 15 14:31:31 2009 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Wed, 15 Jul 2009 16:31:31 +0200 Subject: fedora-cvs flag could not be set Message-ID: <4A5DE843.6060301@redhat.com> I just wanted to set fedora-cvs flag to "?" in my bug https://bugzilla.redhat.com/show_bug.cgi?id=491331 But it is grey (i.e disabled) and I could not change it. I can edit: fedora?review fedora_requires_release_note needinfo but not fedora-cvs Q: Did I miss some process change? It is bug in BZ? Did somebody set some wrong settings? Did I forgot to set someting in BZ? -- Miroslav Suchy Red Hat Satellite Engineering From Jochen at herr-schmitt.de Wed Jul 15 14:38:20 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 15 Jul 2009 16:38:20 +0200 Subject: fedora-cvs flag could not be set In-Reply-To: <4A5DE843.6060301@redhat.com> References: <4A5DE843.6060301@redhat.com> Message-ID: <4A5DE9DC.8070408@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 15.07.2009 16:31, schrieb Miroslav Such?: > I just wanted to set fedora-cvs flag to "?" in my bug > https://bugzilla.redhat.com/show_bug.cgi?id=491331 > But it is grey (i.e disabled) and I could not change it. I can edit: > fedora?review > fedora_requires_release_note > needinfo > but not > fedora-cvs > > Q: Did I miss some process change? It is bug in BZ? Did somebody set > some wrong settings? Did I forgot to set someting in BZ? Question: Why do you want to set this flag. Your package is not approved until yet, so it make no sense to create a CVSAdmin request. As a secons question: Are you a member of the packager group, or do you need a sponsor. If so, please set the FE-NEEDSPONSOR blocker bug on your review request. Best regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpd6dQACgkQT2AHK6txfgwhYgCeIq5Ip/LfSfVn1c+70zXftCuc L8QAniCSjt/8hi1dNAk8iZmKV7m2dZeN =oVqj -----END PGP SIGNATURE----- From sandeen at redhat.com Wed Jul 15 14:42:21 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 15 Jul 2009 09:42:21 -0500 Subject: Any asciidoc users? In-Reply-To: <20090715140107.GQ19992@inocybe.localdomain> References: <20090715140107.GQ19992@inocybe.localdomain> Message-ID: <4A5DEACD.6050003@redhat.com> Todd Zullinger wrote: > I'm not sure how widely used asciidoc is around here. Both git and > tig use it to build their documentation and have been hit by bug > 506953?. I think this bug may hit many other users of asciidoc as > well, making our current packages a bit annoying to use for many > projects. > > If any other asciidoc users have run into spurious 'unsafe: include > file' errors since asciidoc was updated to 8.4.5 (F-11 and devel), > your help confirming that the patch I posted to the bug report helps > and doesn't hurt would be most welcome. (Even if you haven't hit the > 'unsafe: include file' errors, your testing would be great.) > > ? https://bugzilla.redhat.com/506953 > guilt hit this, but I just passed the --unsafe option to asciidoc to work around it :) -Eric From dan at danny.cz Wed Jul 15 14:43:54 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Wed, 15 Jul 2009 16:43:54 +0200 Subject: fedora-cvs flag could not be set In-Reply-To: <4A5DE843.6060301@redhat.com> References: <4A5DE843.6060301@redhat.com> Message-ID: <1247669034.3723.43.camel@eagle.danny.cz> Miroslav Such? p??e v St 15. 07. 2009 v 16:31 +0200: > I just wanted to set fedora-cvs flag to "?" in my bug > https://bugzilla.redhat.com/show_bug.cgi?id=491331 > But it is grey (i.e disabled) and I could not change it. I can edit: > fedora?review > fedora_requires_release_note > needinfo > but not > fedora-cvs > > Q: Did I miss some process change? It is bug in BZ? Did somebody set > some wrong settings? Did I forgot to set someting in BZ? you are not the only one with this problem :-) See https://fedorahosted.org/fedora-infrastructure/ticket/1534 for details. Dan From msuchy at redhat.com Wed Jul 15 14:47:03 2009 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Wed, 15 Jul 2009 16:47:03 +0200 Subject: fedora-cvs flag could not be set In-Reply-To: <4A5DE9DC.8070408@herr-schmitt.de> References: <4A5DE843.6060301@redhat.com> <4A5DE9DC.8070408@herr-schmitt.de> Message-ID: <4A5DEBE7.8020104@redhat.com> Jochen Schmitt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 15.07.2009 16:31, schrieb Miroslav Such?: >> I just wanted to set fedora-cvs flag to "?" in my bug >> https://bugzilla.redhat.com/show_bug.cgi?id=491331 >> But it is grey (i.e disabled) and I could not change it. I can edit: >> fedora?review >> fedora_requires_release_note >> needinfo >> but not >> fedora-cvs >> >> Q: Did I miss some process change? It is bug in BZ? Did somebody set >> some wrong settings? Did I forgot to set someting in BZ? > > Question: Why do you want to set this flag. Your package is not approved > until yet, so it make no sense to create a CVSAdmin request. Err. Sorry wrong content of clipboard. Should be: https://bugzilla.redhat.com/show_bug.cgi?id=501655 > As a secons question: Are you a member of the packager group, or do you Yes, I'm. Unless somebody took that from me recently. -- Miroslav Suchy Red Hat Satellite Engineering From gspurgeon at redhat.com Wed Jul 15 15:07:53 2009 From: gspurgeon at redhat.com (Gavin Spurgeon) Date: Wed, 15 Jul 2009 16:07:53 +0100 Subject: Purging the F12 orphans In-Reply-To: <1247669373.616.540.camel@localhost.localdomain> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> <1247669373.616.540.camel@localhost.localdomain> Message-ID: <4A5DF0C9.2060904@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/07/09 15:49, David Juran wrote: > On Tue, 2009-07-14 at 10:58 -0700, Jesse Keating wrote: >> On Tue, 2009-07-14 at 09:40 -0700, Jesse Keating wrote: >>> It's that time of the release cycle again, to purge the orphans before >>> we get to feature freeze. Any unblocked orphans will be purged by the >>> 28th of this month. Here is a current list of unblocked orphans: >> The first list was incomplete due to an API change. Here is the >> complete list: > >> Unblocked orphan azureus > > I'm using azureus myself so if no-one else is willing to take it, I > could. Co-maintainers are welcome (-: I am willing to co-maintain Azureus with David. - -- Gavin Spurgeon. gspurgeon at redhat.com RedHat GLS Instructor EMEA Red Hat UK Ltd 64 Baker Street 4th Floor, London, W1U 7DF Mob: +44 7841 231160 Desk: +44 0207 009 4429 (Direct) Tel: +44 1252 362709 Fax: +44 1252 548116 Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson (USA), Charlie Peters (USA) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpd8MkACgkQvp6arS3vDiqoUwCfaO894nFTkLGwpnUcKKL1GSsO mXEAoJ4KJuWFLZBVR51v7KPWvxw0O3kV =1bv+ -----END PGP SIGNATURE----- From pablo.martin-gomez at laposte.net Wed Jul 15 15:47:19 2009 From: pablo.martin-gomez at laposte.net (Pablo Martin-Gomez) Date: Wed, 15 Jul 2009 17:47:19 +0200 Subject: Purging the F12 orphans In-Reply-To: <1247594323.3073.1169.camel@localhost.localdomain> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> Message-ID: <20090715174719.21aac89a@laposte.net> Le Tue, 14 Jul 2009 10:58:43 -0700, Jesse Keating a ?crit : I've taken all the following packages, co-maintainer are welcome : > Unblocked orphan gconf-cleaner > Unblocked orphan gnome-specimen > Unblocked orphan gtkperf > Unblocked orphan notecase > Unblocked orphan qemu-launcher > Unblocked orphan wifi-radar If someone want to take the ownership of one of the package, tell me and I will orphan it. Pablo From mw_triad at users.sourceforge.net Wed Jul 15 15:31:48 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 15 Jul 2009 10:31:48 -0500 Subject: Against what do I file this bug? In-Reply-To: <4A5D8136.5070108@xs4all.nl> References: <4A5D10B5.8000004@xs4all.nl> <4A5D154A.1070009@xs4all.nl> <4A5D8136.5070108@xs4all.nl> Message-ID: S.A. Hartsuiker wrote: > On 07/15/2009 01:24 AM, Matthew Woehlke wrote: >> This sounds like an initrd problem to me, but I am no expert. > > Uhm, no. I am in the ''Fedora Interactive'' bit, the > /etc/rc.d/rc.sysinit at that moment. What I mean is, if you aren't getting something mounted, my first guess would be that the contents of the initrd are wrong. That might be a mkinitrd problem, but it might be something else. I am not a boot process expert... ergo I probably will not be of further help; sorry. I can think of one other question that might help someone else help you, however. Is it only /boot that doesn't mount? What about /, swap, and any other disk mounts (i.e. /proc, /sys are likely not interesting) you have configured? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- It is training and experience that gives us the ability to abstract problems, remain objective, use previous knowledge, interact with users, and herd cats. -- Celeste Lyn Paul, on Usability Experts From dennis at ausil.us Wed Jul 15 15:52:29 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 15 Jul 2009 10:52:29 -0500 Subject: fedora-cvs flag could not be set In-Reply-To: <4A5DE843.6060301@redhat.com> References: <4A5DE843.6060301@redhat.com> Message-ID: <200907151052.34000.dennis@ausil.us> On Wednesday 15 July 2009 09:31:31 am Miroslav Such? wrote: > I just wanted to set fedora-cvs flag to "?" in my bug > https://bugzilla.redhat.com/show_bug.cgi?id=491331 > But it is grey (i.e disabled) and I could not change it. I can edit: > fedora?review > fedora_requires_release_note > needinfo > but not > fedora-cvs We recently removed the automatic @rh permissions for fedora flag setting a side effect of how acls sync to bugzilla caused every redhat person in fedorabugs lo lose there flag access. ive just run a manual process to add the permissions back. if anyone else thinks they should have access to the flags and doesn't. please apply for access to fedorabugs in fas 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 gilboad at gmail.com Wed Jul 15 16:47:38 2009 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 15 Jul 2009 19:47:38 +0300 Subject: readline update? In-Reply-To: <20090714154638.GA15785@localhost> References: <20090703102747.GA32668@localhost> <20090703215521.GD13203@nostromo.devel.redhat.com> <20090707132430.GD19965@localhost> <20090714154638.GA15785@localhost> Message-ID: <1247676458.5712.5.camel@gilboa-work-lap.localdomain> On Tue, 2009-07-14 at 17:46 +0200, Miroslav Lichvar wrote: > On Tue, Jul 07, 2009 at 03:24:30PM +0200, Miroslav Lichvar wrote: > > Review requst for compat-readline5: > > https://bugzilla.redhat.com/show_bug.cgi?id=510022 > > > > After the package is accepted, I'll start patching the packages > > (except gnu-smalltalk and kdeedu) to build correctly with the compat > > package. > > It turned out that I can no longer commit to other packages, so I'll > file bugs with patches instead. > > However, it seems that more of the packages I posted in the original > mail are not GPLv2. > > calc (can be relicensed to GPLv3?) > cgdb (GPLv2+?) > gnubg (GPLv3?) > grass (GPLv2+?) > gnuplot (not compatible with any GPL?) > ktechlab (GPLv2+?) > > Can someone confirm this? > > Thanks, > > -- > Miroslav Lichvar > I've sent a message to cgdb upstream and checked if I can mark cgdb as GPLv2+ in rawhide. - Gilboa From Matt_Domsch at dell.com Wed Jul 15 16:48:22 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 15 Jul 2009 11:48:22 -0500 Subject: Fedora rawhide rebuild in mock status 2009-07-10 x86_64 In-Reply-To: <4A5DCAA6.6070208@fedoraproject.org> References: <20090714182235.GA1967@mock.linuxdev.us.dell.com> <1247600517.15109.326.camel@localhost> <20090714215722.GA24214@auslistsprd01.us.dell.com> <1247642465.2743.16.camel@localhost> <20090715121956.GA28902@auslistsprd01.us.dell.com> <4A5DCAA6.6070208@fedoraproject.org> Message-ID: <20090715164822.GA3804@auslistsprd01.us.dell.com> On Wed, Jul 15, 2009 at 05:55:10PM +0530, Rahul Sundaram wrote: > On 07/15/2009 05:49 PM, Matt Domsch wrote: > > > One difference between the Fedora buildsystem and mine is the > > environment running on the builders. > > I assume you are scripting the whole process. Are those available > publically for those who want to setup something similar in their own > infrastructure? Sure. the most recent posted copy is http://linux.dell.com/files/fedora/FixBuildRequires/ftbfs-nov08.tgz and since I took the F11 dev cycle off (rel-eng did the rebuilds and filed the bugs themselves), that is very close to what I'm actually running. -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From itamar at ispbrasil.com.br Wed Jul 15 16:48:49 2009 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Wed, 15 Jul 2009 13:48:49 -0300 Subject: ext4 /boot in F12 ALPHA - changes in anaconda. Message-ID: Hello guy's anaconda can be fixed before F12 ALPHA to allow ext4 /boot ? https://bugzilla.redhat.com/show_bug.cgi?id=486284 -- ------------ Itamar Reis Peixoto e-mail/msn: itamar at ispbrasil.com.br sip: itamar at ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 From sundaram at fedoraproject.org Wed Jul 15 16:48:38 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Jul 2009 22:18:38 +0530 Subject: ext4 /boot in F12 ALPHA - changes in anaconda. In-Reply-To: References: Message-ID: <4A5E0866.4010700@fedoraproject.org> On 07/15/2009 10:18 PM, Itamar Reis Peixoto wrote: > Hello guy's > > anaconda can be fixed before F12 ALPHA to allow ext4 /boot ? > > https://bugzilla.redhat.com/show_bug.cgi?id=486284 Already supports it in Rawhide IIRC. Rahul From christoph.wickert at googlemail.com Wed Jul 15 16:59:50 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Wed, 15 Jul 2009 18:59:50 +0200 Subject: ext4 /boot in F12 ALPHA - changes in anaconda. In-Reply-To: References: Message-ID: <1247677190.2685.10.camel@localhost> Am Mittwoch, den 15.07.2009, 13:48 -0300 schrieb Itamar Reis Peixoto: > Hello guy's > > anaconda can be fixed before F12 ALPHA to allow ext4 /boot ? > > https://bugzilla.redhat.com/show_bug.cgi?id=486284 Already fixed in http://koji.fedoraproject.org/koji/buildinfo?buildID=112216 Regards, Christoph From christoph.wickert at googlemail.com Wed Jul 15 17:06:56 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Wed, 15 Jul 2009 19:06:56 +0200 Subject: ext4 /boot in F12 ALPHA - changes in anaconda. In-Reply-To: <1247677190.2685.10.camel@localhost> References: <1247677190.2685.10.camel@localhost> Message-ID: <1247677616.2685.12.camel@localhost> Am Mittwoch, den 15.07.2009, 18:59 +0200 schrieb Christoph Wickert: > Am Mittwoch, den 15.07.2009, 13:48 -0300 schrieb Itamar Reis Peixoto: > > Hello guy's > > > > anaconda can be fixed before F12 ALPHA to allow ext4 /boot ? > > > > https://bugzilla.redhat.com/show_bug.cgi?id=486284 > > Already fixed in > http://koji.fedoraproject.org/koji/buildinfo?buildID=112216 Opps, wrong link, this is the correct one for anaconda: http://koji.fedoraproject.org/koji/buildinfo?buildID=112742 > > Regards, > Christoph From awilliam at redhat.com Wed Jul 15 17:07:28 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 15 Jul 2009 10:07:28 -0700 Subject: ext4 /boot in F12 ALPHA - changes in anaconda. In-Reply-To: <1247677190.2685.10.camel@localhost> References: <1247677190.2685.10.camel@localhost> Message-ID: <1247677648.5179.27.camel@adam.local.net> On Wed, 2009-07-15 at 18:59 +0200, Christoph Wickert wrote: > Am Mittwoch, den 15.07.2009, 13:48 -0300 schrieb Itamar Reis Peixoto: > > Hello guy's > > > > anaconda can be fixed before F12 ALPHA to allow ext4 /boot ? > > > > https://bugzilla.redhat.com/show_bug.cgi?id=486284 > > Already fixed in > http://koji.fedoraproject.org/koji/buildinfo?buildID=112216 No. See Itamar's mail: it says 'anaconda', not 'grub'. The patches are now in grub, but anaconda is not yet set up to support installing grub to an ext4 partition, AIUI. See the bug report for more discussion. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Wed Jul 15 17:18:17 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 15 Jul 2009 10:18:17 -0700 Subject: ext4 /boot in F12 ALPHA - changes in anaconda. In-Reply-To: <1247677616.2685.12.camel@localhost> References: <1247677190.2685.10.camel@localhost> <1247677616.2685.12.camel@localhost> Message-ID: <1247678297.5179.35.camel@adam.local.net> On Wed, 2009-07-15 at 19:06 +0200, Christoph Wickert wrote: > Am Mittwoch, den 15.07.2009, 18:59 +0200 schrieb Christoph Wickert: > > Am Mittwoch, den 15.07.2009, 13:48 -0300 schrieb Itamar Reis Peixoto: > > > Hello guy's > > > > > > anaconda can be fixed before F12 ALPHA to allow ext4 /boot ? > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=486284 > > > > Already fixed in > > http://koji.fedoraproject.org/koji/buildinfo?buildID=112216 > > Opps, wrong link, this is the correct one for anaconda: > http://koji.fedoraproject.org/koji/buildinfo?buildID=112742 Ah. That explains it. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From fedora at camperquake.de Wed Jul 15 18:34:22 2009 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 15 Jul 2009 20:34:22 +0200 Subject: Fedora 12 Features Needing Updates In-Reply-To: <4A5D0D99.4040409@redhat.com> References: <4A5D0D99.4040409@redhat.com> Message-ID: <20090715203422.70a37d8b@fred.camperquake.de> Hi. On Tue, 14 Jul 2009 15:58:33 -0700, John Poelstra wrote > https://fedoraproject.org/wiki/Features/DisplayPort Am I right in thinking this feature is about DisplayPort sinks on DisplayPort sources? Because I use a monitor (albeit via a DisplayPort/DVI adapter) on my G45 based desktop, and it just works, and that is on rawhide pre-F11. From linuxguy123 at gmail.com Wed Jul 15 18:50:59 2009 From: linuxguy123 at gmail.com (Linuxguy123) Date: Wed, 15 Jul 2009 12:50:59 -0600 Subject: Request for assistance with F11 Sound Issue. (Intel/Pulseaudio) Message-ID: <1247683859.3136.18.camel@localhost.localdomain> I, and others, have been without sound since F11 shipped. Sound worked fine for me in F10 and F9 IIRC. I have posted the details of my problem in a thread titled "From the top... how do I get sound working in F11 ?" in the fedora-list list. As far as I know I have implemented every "solution" thus offered and none of them have worked. I am willing to spend considerable time troubleshooting this situation with a developer. I will file a bugzilla report if we determine that it is in fact a bug. I will do an extensive write up of how we get sound working on my machine if we are successful. I request that someone knowledgeable with this issue come over to the fedora-list list and assist us with this problem. I feel it would be better to address the issue over there as regular users don't usually come to the developer list to look for solutions like this. Thanks for listening. LG From chkr at fedoraproject.org Wed Jul 15 19:05:16 2009 From: chkr at fedoraproject.org (Christian Krause) Date: Wed, 15 Jul 2009 21:05:16 +0200 Subject: Purging the F12 orphans In-Reply-To: References: <1247589637.3073.1162.camel@localhost.localdomain> <4A5D06FB.7060809@fedoraproject.org> Message-ID: <4A5E286C.5010908@fedoraproject.org> Hi Marcus, Marcus Moeller wrote: >>> Unblocked orphan f-spot > > f-spot was only mentioned on Jesse's first list, so I wonder if it's > still listed as orphaned? That's because I've taken ownership of this package between these two posts. ;-) >> I'm using f-spot occasionally and since I'm already helping out with >> some of the mono packages I'm taking ownership of this one. > > If interested I would offer my help on that package as co-maintainer. Sure, any help is welcome! Best regards, Christian From jspaleta at gmail.com Wed Jul 15 19:12:19 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 15 Jul 2009 11:12:19 -0800 Subject: Any asciidoc users? In-Reply-To: <20090715140107.GQ19992@inocybe.localdomain> References: <20090715140107.GQ19992@inocybe.localdomain> Message-ID: <604aa7910907151212s5513fa92vaf0ba03c02f32233@mail.gmail.com> On Wed, Jul 15, 2009 at 6:01 AM, Todd Zullinger wrote: > ? https://bugzilla.redhat.com/506953 safekeep hit it. I was just starting to diagnose the problem. Do we really need to carry patches around in multiple individual projects for what is understood to be a problem in our asciidoc packaging? Really? Can't we deal with this in asciidoc packaging? So we aren't running done multiple failure to build reports? These are the packages which asciidoc's broken safe behavior. potentially impacts on packaging building. repoquery --whatrequires --archlist=src --repoid=rawhide-source asciidoc git-cola-0:1.3.8-1.fc12.src tig-0:0.14.1-1.fc11.src gegl-0:0.1.0-1.fc12.src libXi-0:1.2.99-2.20090619.fc12.src guilt-0:0.32-3.fc11.src git-0:1.6.3.3-1.fc12.src safekeep-0:1.0.5-2.fc11.src cogito-0:0.18.2-4.fc11.src sectool-0:0.9.3-1.fc12.src -jef From wtogami at redhat.com Wed Jul 15 19:22:27 2009 From: wtogami at redhat.com (Warren Togami) Date: Wed, 15 Jul 2009 15:22:27 -0400 Subject: Help Needed: spamassassin-3.3.0 coming soon Message-ID: <4A5E2C73.5060404@redhat.com> http://people.redhat.com/wtogami/temp/spamassassin/3.3.0/ Test RPMS for Fedora 10+, RHEL-4 and RHEL-5. Rawhide has this version too. Upstream says there are no remaining serious issues left for release. They are fixing a few minor bugs and hopefully releasing 3.3.0 in about 2 months. http://wiki.apache.org/spamassassin/NightlyMassCheck http://wiki.apache.org/spamassassin/HandClassifiedCorpora The main concern for release is to improve the qualty of the scores. At the moment there are only five people participating in the NightlyMassCheck used for weekly score generation. More volunteers are needed to follow the HandClassifiedCorpora procedure, where manually sorted Spam and Ham (non-Spam) are fed into the masscheck script on a nightly basis, and logs are uploaded for statistical analysis. They especially need real persons with a mix of opt-in commercial e-mail (Ham) and unwanted Spam. Please read NightlyMassCheck if you want to help improve spamassassin's accuracy for everybody. Reminder: If you use spamassassin, you should edit /etc/cron.d/sa-update and enable nightly score updates. Warren Togami wtogami at redhat.com From twaugh at redhat.com Wed Jul 15 20:27:42 2009 From: twaugh at redhat.com (Tim Waugh) Date: Wed, 15 Jul 2009 21:27:42 +0100 Subject: Purging the F12 orphans In-Reply-To: <4A5E286C.5010908@fedoraproject.org> References: <1247589637.3073.1162.camel@localhost.localdomain> <4A5D06FB.7060809@fedoraproject.org> <4A5E286C.5010908@fedoraproject.org> Message-ID: <1247689662.3327.1.camel@worm> On Wed, 2009-07-15 at 21:05 +0200, Christian Krause wrote: > Marcus Moeller wrote: > >>> Unblocked orphan f-spot > > > > f-spot was only mentioned on Jesse's first list, so I wonder if it's > > still listed as orphaned? > > That's because I've taken ownership of this package between these two > posts. ;-) Hurray! I use f-spot for storing and indexing all of our photos. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From twaugh at redhat.com Wed Jul 15 20:28:49 2009 From: twaugh at redhat.com (Tim Waugh) Date: Wed, 15 Jul 2009 21:28:49 +0100 Subject: Orphaning garmin-sync and pyusb In-Reply-To: <20090714182318.GA43950@redhat.com> References: <20090714182318.GA43950@redhat.com> Message-ID: <1247689729.3327.2.camel@worm> On Tue, 2009-07-14 at 14:23 -0400, Jeremy Katz wrote: > Since I upgraded from the Garmin Edge 305 to the 705, I'm no longer > using either of garmin-sync or its dependency pyusb on any sort of > regular basis. This is probably less than ideal for adequately > maintaining them. I've taken pyusb as it's used by hal-cups-utils. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From MathStuf at gmail.com Wed Jul 15 20:54:46 2009 From: MathStuf at gmail.com (Ben Boeckel) Date: Wed, 15 Jul 2009 16:54:46 -0400 Subject: NVR bugs in rawhide References: <4A5C3FF9.3010903@redhat.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Mach wrote: > krazy2-2.8-8.20090127svn.fc11.src.rpm > - Pre-release build's release should start with '0.'. Krazy doesn't have releases. It's a tool from KDE SVN that I packaged since it's also useful for KDE-dependent apps as well. - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpeQhYACgkQiPi+MRHG3qQifQCdG633pXiJjIsC7Q7IsUR1MpK6 nc4AoIM+Agt14lEvrErOeDtx54IGknIe =qzzo -----END PGP SIGNATURE----- From dmc.fedora at filteredperception.org Wed Jul 15 21:03:12 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 15 Jul 2009 15:03:12 -0600 Subject: Feature proposal: Rebootless Installer In-Reply-To: References: <4A5C3C12.9050009@filteredperception.org> <4A5C6AC5.4060102@earthlink.net> <4A5C6E4E.1080603@filteredperception.org> Message-ID: <4A5E4410.6080008@filteredperception.org> Colin Walters wrote: > Wait, so it's persisting any changes you made to the target drive? > That sounds quite cool actually, and I misunderstood the original > post. Concretely with your change, if I've connected to a wireless > network with NetworkManager, that would get saved in the target > drive's configuration in gconf and be there next time I boot? > > I know with the live images one problem we have is that data can sort > of randomly disappear if you're running close to the memory limit; if > we go with your architecture we should probably special-case things > like ~/.gconf so say the Firefox http disk cache doesn't blow away > your wireless config. To help clarify the feature, let me try to clarify this last point of yours even more. What you are saying is orthogonal to the new feature. I.e. the fact that if you have been using a booted LiveOS long enough for the in-ram rootfs overlay to fill up, that Bad Things Happen (tm). Actually, there is no current or future case where a firefox http disk cache would blow away your wireless config. What would happen, is that the firefox cache would simply cause the system to run out of ram (space in the rootfs overlay), and subsequently everything would just start failing badly. I.e. it is not as you say that things randomly disappear, it is that attempts to write to the rootfs just start failing (in a way that confuses the OS even more than if the same thing happened due to 100% rootfs capacity). So to mitigate this, you do things by making a firefox cache smaller. But now, the important clarification to how this pertains to the zyx-liveinstaller: If you complete installation before falling off of this cliff, there is no subsequent danger of hitting this problem. The instant that the installation completes, all the ram or usbdisk that had been used for the rootfs overlay is released/unbound, and subsequently you are just dealing with your installed rootfs on disk like normal. (before even rebooting the first time...) Hope that makes sense. peace... -dmc From Matt_Domsch at dell.com Wed Jul 15 21:22:31 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 15 Jul 2009 16:22:31 -0500 Subject: Fedora rawhide rebuild in mock status 2009-07-10 x86_64 In-Reply-To: <1247600517.15109.326.camel@localhost> References: <20090714182235.GA1967@mock.linuxdev.us.dell.com> <1247600517.15109.326.camel@localhost> Message-ID: <20090715212231.GA6834@auslistsprd01.us.dell.com> On Tue, Jul 14, 2009 at 09:41:57PM +0200, Christoph Wickert wrote: > Am Dienstag, den 14.07.2009, 13:22 -0500 schrieb Matt Domsch: > > > cwickert: gwget,lxappearance,lxlauncher,lxsession-edit,lxshortcut > > The epiphany extension of gwget is known to be broken. Already reported > upstream: http://bugzilla.gnome.org/show_bug.cgi?id=585401 > Should I disable it for now? > > The rest are false positives. All have been updated last week without > problems and I verified they still build with a couple scratch builds: > http://koji.fedoraproject.org/koji/taskinfo?taskID=1473863 > http://koji.fedoraproject.org/koji/taskinfo?taskID=1473873 > http://koji.fedoraproject.org/koji/taskinfo?taskID=1473864 > http://koji.fedoraproject.org/koji/taskinfo?taskID=1473905 > > There must be something wrong with your builds: > lxappearance: build.log is 33 MB > lxlauncher: build.log is 46 MB > lxsession-edit: build.log is 19 MB > lxshortcut: build.log is 17 MB This is indeed odd. I've rebuilt all of these now on my systems (different hardware each time) , and they continue to fail in the same manner. config.status: creating po/Makefile.in config.status: executing depfiles commands config.status: executing default-1 commands make[2]: Leaving directory `/builddir/build/BUILD/lxshortcut-0.1.1/po' make[2]: Entering directory `/builddir/build/BUILD/lxshortcut-0.1.1/po' cd .. \ && CONFIG_FILES=po/Makefile.in CONFIG_HEADERS= CONFIG_LINKS= \ /bin/sh ./config.status config.status: creating po/Makefile.in (repeat forever) I've done this passing --define "_smp_mflags -j1", and it still fails. I wonder... My build systems are running F11 using ext4 file system, while the koji buildsystems will still be using ext3. It seems like make is getting confused as to whether or not something got created; timestamps may not be getting updated correctly. -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From christoph.wickert at googlemail.com Wed Jul 15 22:58:55 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Thu, 16 Jul 2009 00:58:55 +0200 Subject: Fedora rawhide rebuild in mock status 2009-07-10 x86_64 In-Reply-To: <20090715212231.GA6834@auslistsprd01.us.dell.com> References: <20090714182235.GA1967@mock.linuxdev.us.dell.com> <1247600517.15109.326.camel@localhost> <20090715212231.GA6834@auslistsprd01.us.dell.com> Message-ID: <1247698735.2685.55.camel@localhost> Am Mittwoch, den 15.07.2009, 16:22 -0500 schrieb Matt Domsch: > I wonder... My build systems are running F11 using ext4 file system, > while the koji buildsystems will still be using ext3. It seems like > make is getting confused as to whether or not something got created; > timestamps may not be getting updated correctly. Indeed. Builds fine in my homdir, which is ext3, but when I build it inside /usr/src/ it goes into an infinite loop. Weird. Where is the bug, or where to file it? Regards, Christoph From peter.hutterer at who-t.net Wed Jul 15 23:20:14 2009 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Thu, 16 Jul 2009 09:20:14 +1000 Subject: Any asciidoc users? In-Reply-To: <604aa7910907151212s5513fa92vaf0ba03c02f32233@mail.gmail.com> References: <20090715140107.GQ19992@inocybe.localdomain> <604aa7910907151212s5513fa92vaf0ba03c02f32233@mail.gmail.com> Message-ID: <20090715232011.GB2839@dingo.bne.redhat.com> On Wed, Jul 15, 2009 at 11:12:19AM -0800, Jeff Spaleta wrote: > These are the packages which asciidoc's broken safe behavior. > potentially impacts on packaging building. > > repoquery --whatrequires --archlist=src --repoid=rawhide-source asciidoc > > git-cola-0:1.3.8-1.fc12.src > tig-0:0.14.1-1.fc11.src > gegl-0:0.1.0-1.fc12.src > libXi-0:1.2.99-2.20090619.fc12.src libXi is not affected by this issue. > guilt-0:0.32-3.fc11.src > git-0:1.6.3.3-1.fc12.src > safekeep-0:1.0.5-2.fc11.src > cogito-0:0.18.2-4.fc11.src > sectool-0:0.9.3-1.fc12.src Cheers, Peter From airlied at redhat.com Thu Jul 16 00:41:06 2009 From: airlied at redhat.com (Dave Airlie) Date: Thu, 16 Jul 2009 10:41:06 +1000 Subject: Any asciidoc users? In-Reply-To: <20090715140107.GQ19992@inocybe.localdomain> References: <20090715140107.GQ19992@inocybe.localdomain> Message-ID: <1247704867.3572.3.camel@clockmaker.usersys.redhat.com> On Wed, 2009-07-15 at 10:01 -0400, Todd Zullinger wrote: > I'm not sure how widely used asciidoc is around here. Both git and > tig use it to build their documentation and have been hit by bug > 506953?. I think this bug may hit many other users of asciidoc as > well, making our current packages a bit annoying to use for many > projects. > > If any other asciidoc users have run into spurious 'unsafe: include > file' errors since asciidoc was updated to 8.4.5 (F-11 and devel), > your help confirming that the patch I posted to the bug report helps > and doesn't hurt would be most welcome. (Even if you haven't hit the > 'unsafe: include file' errors, your testing would be great.) > > ? https://bugzilla.redhat.com/506953 just apply the --unsafe as default patch I suppose, I'm not sure its actually a useful feature, Dave. From tony at bakeyournoodle.com Thu Jul 16 01:38:46 2009 From: tony at bakeyournoodle.com (Tony Breeds) Date: Thu, 16 Jul 2009 11:38:46 +1000 Subject: Orphaning garmin-sync and pyusb In-Reply-To: <20090714182318.GA43950@redhat.com> References: <20090714182318.GA43950@redhat.com> Message-ID: <20090716013846.GJ32080@bilbo.ozlabs.org> On Tue, Jul 14, 2009 at 02:23:18PM -0400, Jeremy Katz wrote: > If you *have* one of the older Garmin Edge or Forerunner devices, > they're easy enough packages to maintain -- upstream is responsive to > the one or two things I threw at him and the userbase is not that > large. When I get my Forerunner back from the shop, I'll see if garmin-sync talks to it. If it does, I'll take it. Yours Tony From randyn3lrx at gmail.com Thu Jul 16 03:09:15 2009 From: randyn3lrx at gmail.com (Randall J. Berry) Date: Wed, 15 Jul 2009 23:09:15 -0400 Subject: Proposal to drop gMFSK in favor of fldigi Message-ID: <4A5E99DB.4010703@gmail.com> This is a proposal to drop gMFSK (http://koji.fedoraproject.org/koji/packageinfo?packageID=5883) in favor of fldigi (http://koji.fedoraproject.org/koji/packageinfo?packageID=5817) which already supports all the same modes as gMFSK and then some. Also; gMFSK has not been updated in a while whereas fldigi seems to still be an active project. gMFSK is also having troubles being built on rawhide (https://bugzilla.redhat.com/show_bug.cgi?id=511780) Shall we work on the error and build it for rawhide or retire it in favor of fldigi. What say you? 73 de Randy N3LRX (a.k.a. Dp67) From jonstanley at gmail.com Thu Jul 16 04:00:57 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 16 Jul 2009 00:00:57 -0400 Subject: Plan for Friday's (20090717) FESCo meeting Message-ID: I know this is a little early, but I'm going to try to get the agenda out by Wednesday evening in the future. At any rate, here's the plan for Friday's meeting, at 17:00UTC in #fedora-meeting on irc.freenode.net: 190 application for packaging sponsor - ianweller 189 Consideration for provenpackager - jsteffan 192 provenpackager self-nomination: oget 175 Exception to link against bundled copy of crypsetup in volume_key 186 Yum langpack plugin - https://fedoraproject.org/wiki/Features/YumLangpackPlugin 191 Proposal: Classifying the Audio&Video/Multimedia desktop menu 193 Anaconda MDRaid - https://fedoraproject.org/wiki/Anaconda/Features/MDRaid 194 ABRT F12 - https://fedoraproject.org/wiki/Features/ABRTF12 195 Gnome 2.28 - https://fedoraproject.org/wiki/Features/Gnome2.28 196 KVM NIC Hotplug - https://fedoraproject.org/wiki/Features/KVM_NIC_Hotplug 197 noarch subpackages - https://fedoraproject.org/wiki/Features/NoarchSubpackages 198 Rebootless Installer - https://fedoraproject.org/wiki/Features/RebootlessInstaller 199 SR-IOV - https://fedoraproject.org/wiki/Features/SR-IOV 200 libguestfs - https://fedoraproject.org/wiki/Features/libguestfs 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 eric at christensenplace.us Thu Jul 16 04:03:52 2009 From: eric at christensenplace.us (Eric Christensen) Date: Thu, 16 Jul 2009 00:03:52 -0400 Subject: Proposal to drop gMFSK in favor of fldigi In-Reply-To: <4A5E99DB.4010703@gmail.com> References: <4A5E99DB.4010703@gmail.com> Message-ID: <1247717032.2633.10.camel@thunder.christensenplace.us> On Wed, 2009-07-15 at 23:09 -0400, Randall J. Berry wrote: > This is a proposal to drop gMFSK > (http://koji.fedoraproject.org/koji/packageinfo?packageID=5883) in favor > of fldigi > (http://koji.fedoraproject.org/koji/packageinfo?packageID=5817) which > already supports all the same modes as gMFSK and then some. > > Also; gMFSK has not been updated in a while whereas fldigi seems to > still be an active project. gMFSK is also having troubles being built on > rawhide (https://bugzilla.redhat.com/show_bug.cgi?id=511780) Shall we > work on the error and build it for rawhide or retire it in favor of > fldigi. What say you? > > 73 de Randy N3LRX (a.k.a. Dp67) > Randy, Sounds good to me as I only use fldigi. I wonder how many users out there are using gMFSK? Eric W4OTN -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mtasaka at ioa.s.u-tokyo.ac.jp Thu Jul 16 04:52:08 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 16 Jul 2009 13:52:08 +0900 Subject: Fedora rawhide rebuild in mock status 2009-07-10 x86_64 In-Reply-To: <1247698735.2685.55.camel@localhost> References: <20090714182235.GA1967@mock.linuxdev.us.dell.com> <1247600517.15109.326.camel@localhost> <20090715212231.GA6834@auslistsprd01.us.dell.com> <1247698735.2685.55.camel@localhost> Message-ID: <4A5EB1F8.7080106@ioa.s.u-tokyo.ac.jp> Christoph Wickert wrote, at 07/16/2009 07:58 AM +9:00: > Am Mittwoch, den 15.07.2009, 16:22 -0500 schrieb Matt Domsch: > >> I wonder... My build systems are running F11 using ext4 file system, >> while the koji buildsystems will still be using ext3. It seems like >> make is getting confused as to whether or not something got created; >> timestamps may not be getting updated correctly. > > Indeed. Builds fine in my homdir, which is ext3, but when I build it > inside /usr/src/ it goes into an infinite loop. Weird. Where is the bug, > or where to file it? > > Regards, > Christoph I only tried to rebuild lxappearance-0.2.1-1.fc12 and the infinite loop on po/ directory can be reproduced on Kevin's 64 bits machine (however not reproducible on i586 machine). What is the problem here is that po/Makefile (after po/Makefile is created) says: ------------------------------------------------------------- 212 Makefile POTFILES: stamp-it 213 @if test ! -f $@; then \ 214 rm -f stamp-it; \ 215 $(MAKE) stamp-it; \ 216 fi 217 218 stamp-it: Makefile.in.in $(top_builddir)/config.status POTFILES.in 219 cd $(top_builddir) \ 220 && CONFIG_FILES=$(subdir)/Makefile.in CONFIG_HEADERS= CONFIG_LINKS= \ 221 $(SHELL) ./config.status ------------------------------------------------------------- So, po/Makefile expects that po/stamp-it exists and po/stamp-it expects that it is created by config.status, however config.status does not create po/stamp-it, which will cause occasional infinite loop. Note that config.status is created by configure. Then configure.in says: ------------------------------------------------------------- 29 dnl Add the languages which your application supports here. 30 ALL_LINGUAS="af ar cs da de es et eu fa fi fr gl hr hu id it ja ko lt ml ms nb nl nn pl ps pt pt_BR ru sk sl sv tr uk ur ur_PK vi zh_CN zh_TW" 31 AM_GLIB_GNU_GETTEXT ------------------------------------------------------------- So this configure uses glib's gettext method, however po/ directory uses "stamp-it" method Makefile.in.in, which is actually based on /usr/share/intltool/Makefile.in.in in intltool and not /usr/share/glib-2.0/gettext/po/Makefile.in.in in glib2-devel. So po/Makefile.in.in needs fixing, however the easiest workaround is: -------------------------------------------------------------- %build %configure touch -r po/Makefile po/stamp-it make %{?_smp_mflags} -------------------------------------------------------------- Regards, Mamoru From christoph.wickert at googlemail.com Thu Jul 16 09:00:15 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Thu, 16 Jul 2009 11:00:15 +0200 Subject: Purging the F12 orphans In-Reply-To: <20090715174719.21aac89a@laposte.net> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> <20090715174719.21aac89a@laposte.net> Message-ID: <1247734815.8760.0.camel@localhost> Am Mittwoch, den 15.07.2009, 17:47 +0200 schrieb Pablo Martin-Gomez: > Le Tue, 14 Jul 2009 10:58:43 -0700, > Jesse Keating a ?crit : > > I've taken all the following packages, co-maintainer are welcome : > > Unblocked orphan gconf-cleaner > > Unblocked orphan gnome-specimen > > Unblocked orphan gtkperf > > Unblocked orphan notecase > > Unblocked orphan qemu-launcher > > Unblocked orphan wifi-radar > > If someone want to take the ownership of one of the package, tell me > and I will orphan it. notecase is discontinued upstream, so think twice befor taking it. > Pablo Regards, Christoph From mail at marcus-moeller.de Thu Jul 16 09:46:27 2009 From: mail at marcus-moeller.de (Marcus Moeller) Date: Thu, 16 Jul 2009 11:46:27 +0200 Subject: using yumdownloader to fetch sources from koji Message-ID: Hi all, is there a way to add http://kojipkgs.fedoraproject.org/packages/ as yum repository, as I wanted to make use of yumdownloader to fetch some SRPMs from there. Best Regards Marcus From dan at danny.cz Thu Jul 16 11:59:38 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Thu, 16 Jul 2009 13:59:38 +0200 Subject: creating minimal boot image for network installations Message-ID: <1247745578.3796.44.camel@eagle.danny.cz> I don't know about a simple way to start a network installation of Fedora from USB stick. Creating of boot.img, that server that purpose, was stopped by rel-engs some releases ago. I have found a blog post [1] that makes possible to transform a boot.iso image into a bootable USB stick. But it still requires to download the 200+ MB large boot.iso file and do it by hand, while in theory only initrd.img and vmlinuz files should be needed and the whole process could be automated. So I have created mkbootimg.sh script [2] that automates all required steps and has a bootable disk image as a result. It can be transferred to real USB disk by the dd command. I find it useful when testing rawhide installations, but can be used for releases too. There is naturally no warranty for the script, it can eat whole your system :-) Dan [1] http://hansdegoede.livejournal.com/4573.html [2] http://fedora.danny.cz/misc/mkbootimg.sh From buc at odusz.so-cdu.ru Thu Jul 16 12:06:55 2009 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Thu, 16 Jul 2009 16:06:55 +0400 Subject: creating minimal boot image for network installations In-Reply-To: <1247745578.3796.44.camel@eagle.danny.cz> References: <1247745578.3796.44.camel@eagle.danny.cz> Message-ID: <4A5F17DF.1060704@odu.neva.ru> Dan Hor?k wrote: > I don't know about a simple way to start a network installation of > Fedora from USB stick. Creating of boot.img, that server that purpose, > was stopped by rel-engs some releases ago. I have found a blog post [1] > that makes possible to transform a boot.iso image into a bootable USB > stick. But it still requires to download the 200+ MB large boot.iso file > and do it by hand, while in theory only initrd.img and vmlinuz files > should be needed and the whole process could be automated. So I have > created mkbootimg.sh script [2] that automates all required steps and > has a bootable disk image as a result. It can be transferred to real USB > disk by the dd command. I find it useful when testing rawhide > installations, but can be used for releases too. There is naturally no > warranty for the script, it can eat whole your system :-) > > > Dan > > [1] http://hansdegoede.livejournal.com/4573.html > [2] http://fedora.danny.cz/misc/mkbootimg.sh > > > See the makebootfat package -- it has in the doc the description of the similar procedure... (AFAIK Anaconda had started to use makebootfat as well). Regards, Dmitry Butskoy From karsten at redhat.com Thu Jul 16 12:16:05 2009 From: karsten at redhat.com (Karsten Hopp) Date: Thu, 16 Jul 2009 14:16:05 +0200 Subject: Mock issue with ifarch BuildRequires In-Reply-To: References: Message-ID: <4A5F1A05.5000404@redhat.com> Am 14.07.2009 01:50, schrieb Gianluca Sforna: > Sorry for the cross-posting, I'm trying to get a clue... > > > ---------- Forwarded message ---------- > From: Gianluca Sforna > Date: Mon, Jul 13, 2009 at 1:38 AM > Subject: Mock issue with ifarch BuildRequires > To: Discussion of Fedora build system > > > I am trying to run the tests included in the BuildBot package during > the RPM build, and one of the tests requires darcs, which is built in > Fedora ExclusiveArch %{ix86} x86_64 ppc alpha. > Now, I'm adding to buildbot's spec[1] file an ifarch like: > > %ifarch %{ix86} x86_64 ppc alpha > # darcs ExclusiveArchs > BuildRequires: darcs > %endif > > but it seems darcs is never installed in the buildroot [2] > > am I just doing something stupid or there's a bug somewhere? > > [1] http://cvs.fedoraproject.org/viewvc/rpms/buildbot/devel/buildbot.spec?view=log > [2] http://koji.fedoraproject.org/koji/getfile?taskID=1470380&name=root.log > > %ifarch and %ifnarch unfortunately don't work in noarch packages. I think that's a bug, the arch information is there as p.e. ExcludeArch works, and just those two don't get evaluated. CC: our rpm maintainers for comments From mschwendt at gmail.com Thu Jul 16 13:05:53 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 16 Jul 2009 13:05:53 -0000 Subject: Broken dependencies in Fedora 11 - 2009-07-16 Message-ID: <20090716130553.10315.68444@faldor.intranet> ====================================================================== The results in this summary consider Test Updates! ====================================================================== Summary of broken packages (by src.rpm name): beagle gauche-gl gauche-gtk guiloader-c++ libvirt-qpid mono-tools ppl python-repoze-what tomboy unetbootin ====================================================================== Broken packages in fedora-11-i386: gauche-gl-0.4.4-4.fc11.i586 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.i586 requires gauche = 0:0.8.13 guiloader-c++-2.13.0-2.fc11.i586 requires libguiloader.so.0 ====================================================================== Broken packages in fedora-11-ppc: gauche-gl-0.4.4-4.fc11.ppc requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.ppc requires gauche = 0:0.8.13 guiloader-c++-2.13.0-2.fc11.ppc requires libguiloader.so.0 guiloader-c++-2.13.0-2.fc11.ppc64 requires libguiloader.so.0()(64bit) ====================================================================== Broken packages in fedora-11-ppc64: guiloader-c++-2.13.0-2.fc11.ppc64 requires libguiloader.so.0()(64bit) ====================================================================== Broken packages in fedora-11-x86_64: gauche-gl-0.4.4-4.fc11.x86_64 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.x86_64 requires gauche = 0:0.8.13 guiloader-c++-2.13.0-2.fc11.i586 requires libguiloader.so.0 guiloader-c++-2.13.0-2.fc11.x86_64 requires libguiloader.so.0()(64bit) ====================================================================== Broken packages in fedora-updates-11-i386: libvirt-qpid-0.2.16-2.fc11.i586 requires libqpidclient.so.0 libvirt-qpid-0.2.16-2.fc11.i586 requires libqpidcommon.so.0 libvirt-qpid-0.2.16-2.fc11.i586 requires libqmfagent.so.0 ====================================================================== Broken packages in fedora-updates-11-ppc: libvirt-qpid-0.2.16-2.fc11.ppc requires libqpidclient.so.0 libvirt-qpid-0.2.16-2.fc11.ppc requires libqpidcommon.so.0 libvirt-qpid-0.2.16-2.fc11.ppc requires libqmfagent.so.0 ====================================================================== Broken packages in fedora-updates-11-ppc64: libvirt-qpid-0.2.16-2.fc11.ppc64 requires libqmfagent.so.0()(64bit) libvirt-qpid-0.2.16-2.fc11.ppc64 requires libqpidcommon.so.0()(64bit) libvirt-qpid-0.2.16-2.fc11.ppc64 requires libqpidclient.so.0()(64bit) ====================================================================== Broken packages in fedora-updates-11-x86_64: libvirt-qpid-0.2.16-2.fc11.x86_64 requires libqmfagent.so.0()(64bit) libvirt-qpid-0.2.16-2.fc11.x86_64 requires libqpidcommon.so.0()(64bit) libvirt-qpid-0.2.16-2.fc11.x86_64 requires libqpidclient.so.0()(64bit) ====================================================================== Broken packages in fedora-updates-testing-11-i386: ppl-swiprolog-0.10.2-3.fc11.i586 requires libpl.so.5.7.6 ppl-yap-0.10.2-3.fc11.i586 requires libYap.so python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 ====================================================================== Broken packages in fedora-updates-testing-11-ppc: ppl-swiprolog-0.10.2-3.fc11.ppc requires libpl.so.5.7.6 ppl-yap-0.10.2-3.fc11.ppc requires libYap.so python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 unetbootin-0-5.356bzr.fc11.ppc requires syslinux ====================================================================== Broken packages in fedora-updates-testing-11-ppc64: beagle-0.3.9-9.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0 beagle-0.3.9-9.fc11.ppc64 requires mono(gsf-sharp) = 0:0.0.0.7 beagle-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 beagle-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 beagle-0.3.9-9.fc11.ppc64 requires mono(taglib-sharp) = 0:2.0.3.2 beagle-evolution-0.3.9-9.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0 beagle-evolution-0.3.9-9.fc11.ppc64 requires mono(evolution-sharp) = 0:5.0.0.0 beagle-gnome-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 beagle-gnome-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 beagle-thunderbird-0.3.9-9.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0 mono-tools-2.4-12.fc11.ppc64 requires mono(gtkhtml-sharp) >= 0:3.0 ppl-swiprolog-0.10.2-3.fc11.ppc64 requires libpl.so.5.7.6()(64bit) ppl-yap-0.10.2-3.fc11.ppc64 requires libYap.so()(64bit) python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 tomboy-0.14.3-1.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(Mono.Addins.Setup) = 0:0.4.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(gnome-panel-sharp) = 0:2.24.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(Mono.Addins) = 0:0.4.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(Mono.Addins.Gui) = 0:0.4.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 unetbootin-0-5.356bzr.fc11.ppc64 requires syslinux ====================================================================== Broken packages in fedora-updates-testing-11-x86_64: ppl-swiprolog-0.10.2-3.fc11.x86_64 requires libpl.so.5.7.6()(64bit) ppl-yap-0.10.2-3.fc11.x86_64 requires libYap.so()(64bit) python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 From sahartsu at xs4all.nl Thu Jul 16 13:54:34 2009 From: sahartsu at xs4all.nl (Stefan Hartsuiker) Date: Thu, 16 Jul 2009 15:54:34 +0200 (CEST) Subject: Against what do I file this bug? Message-ID: <2894.145.100.24.27.1247752474.squirrel@webmail.xs4all.nl> On Wed, July 15, 2009 17:31, Matthew Woehlke wrote: > S.A. Hartsuiker wrote: >> On 07/15/2009 01:24 AM, Matthew Woehlke wrote: >>> This sounds like an initrd problem to me, but I am no expert. >> >> Uhm, no. I am in the ''Fedora Interactive'' bit, the >> /etc/rc.d/rc.sysinit at that moment. > > What I mean is, if you aren't getting something mounted, my first guess > would be that the contents of the initrd are wrong. That might be a > mkinitrd problem, but it might be something else. I am not a boot > process expert... ergo I probably will not be of further help; sorry. > Thanks for the effort anyway :) > I can think of one other question that might help someone else help you, > however. Is it only /boot that doesn't mount? What about /, swap, and > any other disk mounts (i.e. /proc, /sys are likely not interesting) you > have configured? The fakeraid mirrored device only contains two partitions, namely p2 ( to be mounted on /) and p1 (to be mounted on /boot). All other things that are to be mounted can be mounted (at the point of the error not everything is yet moounted though) One other bit of an odd thing that may not have been made completely clear is that for the fakeraid mirrored device no device files exist. This includes the root partition/mount even though it is actually mounted ro at the point of the error. Another thing I just noticed is that the devicenode numbers (major/minor) that are used for the fakeraid mirrored device during a livecd run are 253/0, 253/1 and 253/2. These numbers are in a ''normal'' boot sequence (the one that fails to startup correctly) used by the second fakeraid device. Does devicemapper or somesuch remove pre-existing devices if they don't match it's idea of waht is should be or does devicemapper just start at the ''beginning'' when creating devicenodes? Kind regards, Stefan Hartsuiker [snip signature] From katzj at redhat.com Thu Jul 16 14:05:06 2009 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 16 Jul 2009 10:05:06 -0400 Subject: creating minimal boot image for network installations In-Reply-To: <1247745578.3796.44.camel@eagle.danny.cz> References: <1247745578.3796.44.camel@eagle.danny.cz> Message-ID: <20090716140506.GA46251@redhat.com> On Thursday, July 16 2009, Dan Hor?k said: > I don't know about a simple way to start a network installation of > Fedora from USB stick. Creating of boot.img, that server that purpose, > was stopped by rel-engs some releases ago. I have found a blog post [1] > that makes possible to transform a boot.iso image into a bootable USB > stick. But it still requires to download the 200+ MB large boot.iso file > and do it by hand, while in theory only initrd.img and vmlinuz files > should be needed and the whole process could be automated. So I have > created mkbootimg.sh script [2] that automates all required steps and > has a bootable disk image as a result. It can be transferred to real USB > disk by the dd command. I find it useful when testing rawhide > installations, but can be used for releases too. There is naturally no > warranty for the script, it can eat whole your system :-) With Fedora 12, you'll be able to just dd the boot.iso onto a USB stick since we're making isohybrid'd images. Note that while kernel + initrd is all you "need", not having the stage2 means we have to ask where to find it rather than being able to automate the use of the mirror list for everything Jeremy From yaneti at declera.com Thu Jul 16 14:22:34 2009 From: yaneti at declera.com (Yanko Kaneti) Date: Thu, 16 Jul 2009 17:22:34 +0300 Subject: creating minimal boot image for network installations In-Reply-To: <20090716140506.GA46251@redhat.com> References: <1247745578.3796.44.camel@eagle.danny.cz> <20090716140506.GA46251@redhat.com> Message-ID: <1247754154.7760.17.camel@d2> On Thu, 2009-07-16 at 10:05 -0400, Jeremy Katz wrote: > On Thursday, July 16 2009, Dan Hor?k said: > > I don't know about a simple way to start a network installation of > > Fedora from USB stick. Creating of boot.img, that server that purpose, > > was stopped by rel-engs some releases ago. I have found a blog post [1] > > that makes possible to transform a boot.iso image into a bootable USB > > stick. But it still requires to download the 200+ MB large boot.iso file > > and do it by hand, while in theory only initrd.img and vmlinuz files > > should be needed and the whole process could be automated .. > > Note that while kernel + initrd is all you "need", not having the stage2 > means we have to ask where to find it rather than being able to automate > the use of the mirror list for everything Anything in particular that prevents the loader from using the mirror list to find a suitable location for stage2 ? ..other than "no patches for it yet" From rvinyard at cs.nmsu.edu Thu Jul 16 14:32:13 2009 From: rvinyard at cs.nmsu.edu (Rick L. Vinyard, Jr.) Date: Thu, 16 Jul 2009 08:32:13 -0600 Subject: Fedora 11 / EPEL 5 MD5 Issue Message-ID: I've built the following package on Fedora 10 and 11 in mock without any problems. http://miskatonic.cs.nmsu.edu/pub/libMini-9.0.3-2.fc11.src.rpm However, when I try and build for EPEL 5 using mock on a F11 machine I get the following in root.log: DEBUG util.py:256: error: unpacking of archive failed on file /builddir/build/SOURCES/MINI-9.0.3.zip;4a5f3532: cpio: MD5 sum mismatch Any suggestions? From john5342 at googlemail.com Thu Jul 16 14:33:31 2009 From: john5342 at googlemail.com (John5342) Date: Thu, 16 Jul 2009 15:33:31 +0100 Subject: Against what do I file this bug? In-Reply-To: <2894.145.100.24.27.1247752474.squirrel@webmail.xs4all.nl> References: <2894.145.100.24.27.1247752474.squirrel@webmail.xs4all.nl> Message-ID: <6dc6523c0907160733w4b784594nd9846d5acea4ecda@mail.gmail.com> 2009/7/16 Stefan Hartsuiker : > On Wed, July 15, 2009 17:31, Matthew Woehlke wrote: >> S.A. Hartsuiker wrote: >>> On 07/15/2009 01:24 AM, Matthew Woehlke wrote: >>>> This sounds like an initrd problem to me, but I am no expert. >>> >>> ?Uhm, no. I am in the ''Fedora Interactive'' bit, the >>> /etc/rc.d/rc.sysinit at that moment. >> >> What I mean is, if you aren't getting something mounted, my first guess >> would be that the contents of the initrd are wrong. That might be a >> mkinitrd problem, but it might be something else. I am not a boot >> process expert... ergo I probably will not be of further help; sorry. >> > > Thanks for the effort anyway :) > >> I can think of one other question that might help someone else help you, >> however. Is it only /boot that doesn't mount? What about /, swap, and >> any other disk mounts (i.e. /proc, /sys are likely not interesting) you >> have configured? > > The fakeraid mirrored device only contains two partitions, namely p2 ( to be > mounted on /) ?and p1 (to be mounted on /boot). > All other things that are to be mounted can be mounted (at the point of the > error not everything is yet moounted though) > > One other bit of an odd thing that may not have been made completely clear > is that for the fakeraid mirrored device no device files exist. This includes > the root partition/mount even though it is actually mounted ro at the point of > the error. > > Another thing I just noticed is that the devicenode numbers (major/minor) that > are used for the fakeraid mirrored device during a livecd run are 253/0, 253/1 > and 253/2. These numbers are in a ''normal'' boot sequence (the one that fails > to startup correctly) used by the second fakeraid device. > > Does devicemapper or somesuch remove pre-existing devices if they don't match > it's idea of waht is should be or does devicemapper just start at the > ''beginning'' when creating devicenodes? > > Kind regards, > Stefan Hartsuiker This may be completely un-related but ever since i first started using FC3 (up to and including F11) i have had the same issue with nvidia fake raid. I wasn't installing to the raid but the symptoms were almost identical. My problem was that the dmraid command (which also creates the devicemapper entries in /dev/) wasn't making it into the initrd image. All i did was run the install dvd in rescue mode, chroot to the install, run 'dmraid -ay' to make sure the fakeraid was enabled and then recreate the initrd using mkinitrd. Since you installed to the disk i can't imagine why dmraid didn't make it into initrd but you're situation did sound familiar. Hope it helps. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... From sgallagh at redhat.com Thu Jul 16 14:35:54 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 16 Jul 2009 10:35:54 -0400 Subject: Fedora 11 / EPEL 5 MD5 Issue In-Reply-To: References: Message-ID: <4A5F3ACA.5070204@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/16/2009 10:32 AM, Rick L. Vinyard, Jr. wrote: > I've built the following package on Fedora 10 and 11 in mock without any > problems. > http://miskatonic.cs.nmsu.edu/pub/libMini-9.0.3-2.fc11.src.rpm > > However, when I try and build for EPEL 5 using mock on a F11 machine I get > the following in root.log: > > DEBUG util.py:256: error: unpacking of archive failed on file > /builddir/build/SOURCES/MINI-9.0.3.zip;4a5f3532: cpio: MD5 sum mismatch > > Any suggestions? > To extract sources from an SRPM: rpm2cpio | cpio --extract (Do this in its own directory) To enable the old checksum (for building RHEL packages): rpmbuild -bs --define _source_filedigest_algorithm=1 This will recreate the SRPM using an MD5 sum instead of a SHA1 sum. You can then use that in mock. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpfOsUACgkQeiVVYja6o6OzogCghnA7UWmp04TNNf24xZ3W1c8e 6rgAn0eeVb8mvQwi5T9EYWycBuB/rn8a =ftcD -----END PGP SIGNATURE----- From jreiser at bitwagon.com Thu Jul 16 14:35:48 2009 From: jreiser at bitwagon.com (John Reiser) Date: Thu, 16 Jul 2009 07:35:48 -0700 Subject: creating minimal boot image for network installations In-Reply-To: <1247754154.7760.17.camel@d2> References: <1247745578.3796.44.camel@eagle.danny.cz> <20090716140506.GA46251@redhat.com> <1247754154.7760.17.camel@d2> Message-ID: <4A5F3AC4.4040305@bitwagon.com> Yanko Kaneti wrote: > On Thu, 2009-07-16 at 10:05 -0400, Jeremy Katz wrote: >> Note that while kernel + initrd is all you "need", not having the stage2 >> means we have to ask where to find it rather than being able to automate >> the use of the mirror list for everything > > Anything in particular that prevents the loader from using the mirror > list to find a suitable location for stage2 ? ..other than "no patches > for it yet" Especially for testing rawhide, I find that using the mirror list is problematic. Some mirrors sync quickly (a couple hours), others take significantly longer (*many* hours). I would rather specify the mirror explicitly. -- From dan at danny.cz Thu Jul 16 14:42:40 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Thu, 16 Jul 2009 16:42:40 +0200 Subject: creating minimal boot image for network installations In-Reply-To: <20090716140506.GA46251@redhat.com> References: <1247745578.3796.44.camel@eagle.danny.cz> <20090716140506.GA46251@redhat.com> Message-ID: <1247755360.3796.53.camel@eagle.danny.cz> Jeremy Katz p??e v ?t 16. 07. 2009 v 10:05 -0400: > On Thursday, July 16 2009, Dan Hor?k said: > > I don't know about a simple way to start a network installation of > > Fedora from USB stick. Creating of boot.img, that server that purpose, > > was stopped by rel-engs some releases ago. I have found a blog post [1] > > that makes possible to transform a boot.iso image into a bootable USB > > stick. But it still requires to download the 200+ MB large boot.iso file > > and do it by hand, while in theory only initrd.img and vmlinuz files > > should be needed and the whole process could be automated. So I have > > created mkbootimg.sh script [2] that automates all required steps and > > has a bootable disk image as a result. It can be transferred to real USB > > disk by the dd command. I find it useful when testing rawhide > > installations, but can be used for releases too. There is naturally no > > warranty for the script, it can eat whole your system :-) > > With Fedora 12, you'll be able to just dd the boot.iso onto a USB stick > since we're making isohybrid'd images. That will be appreciated :-) > Note that while kernel + initrd is all you "need", not having the stage2 > means we have to ask where to find it rather than being able to automate > the use of the mirror list for everything On other side one can prefer setting the mirror manually e.g. when having a private/local mirror. Dan From nushio at fedoraproject.org Thu Jul 16 14:45:31 2009 From: nushio at fedoraproject.org (Juan Rodriguez) Date: Thu, 16 Jul 2009 09:45:31 -0500 Subject: Fedora 11 / EPEL 5 MD5 Issue In-Reply-To: References: Message-ID: On Thu, Jul 16, 2009 at 9:32 AM, Rick L. Vinyard, Jr. wrote: > I've built the following package on Fedora 10 and 11 in mock without any > problems. > http://miskatonic.cs.nmsu.edu/pub/libMini-9.0.3-2.fc11.src.rpm > > However, when I try and build for EPEL 5 using mock on a F11 machine I get > the following in root.log: > > DEBUG util.py:256: error: unpacking of archive failed on file > /builddir/build/SOURCES/MINI-9.0.3.zip;4a5f3532: cpio: MD5 sum mismatch > > Any suggestions? > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > IIRC, Fedora 11 uses SHA-1 instead of MD5 for checksums, which makes new rpms not verifyable on pre-F11 computers. Its part of the Stronger Hashes feature [1]. [1] http://fedoraproject.org/wiki/Features/StrongerHashes Regards, -- Ing. Juan M. Rodriguez Moreno Desarrollador de Sistemas Abiertos Sitio: http://proyectofedora.org/mexico -------------- next part -------------- An HTML attachment was scrubbed... URL: From bochecha at fedoraproject.org Thu Jul 16 14:51:32 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Thu, 16 Jul 2009 16:51:32 +0200 Subject: Fedora 11 / EPEL 5 MD5 Issue In-Reply-To: References: Message-ID: <2d319b780907160751p1a317d85ta14e34cfd1219b5e@mail.gmail.com> On Thu, Jul 16, 2009 at 16:32, Rick L. Vinyard, Jr. wrote: > I've built the following package on Fedora 10 and 11 in mock without any > problems. > ? ? http://miskatonic.cs.nmsu.edu/pub/libMini-9.0.3-2.fc11.src.rpm > > However, when I try and build for EPEL 5 using mock on a F11 machine I get > the following in root.log: > > DEBUG util.py:256: ?error: unpacking of archive failed on file > /builddir/build/SOURCES/MINI-9.0.3.zip;4a5f3532: cpio: MD5 sum mismatch > > Any suggestions? I did the following two days ago (all on a F11 host) : - rebuild the F11 srpm in a F10 mock chroot - rebuild the F10 srpm in a EL5 mock chroot F11 and F10 rpm versions are compatible, and so are F10 and EL5. Totally suboptimal, but it works, and I didn't have time to search more thoroughly for a better solution :) ---------- Mathieu Bridon (bochecha) From yaneti at declera.com Thu Jul 16 14:54:02 2009 From: yaneti at declera.com (Yanko Kaneti) Date: Thu, 16 Jul 2009 17:54:02 +0300 Subject: creating minimal boot image for network installations In-Reply-To: <4A5F3AC4.4040305@bitwagon.com> References: <1247745578.3796.44.camel@eagle.danny.cz> <20090716140506.GA46251@redhat.com> <1247754154.7760.17.camel@d2> <4A5F3AC4.4040305@bitwagon.com> Message-ID: <1247756042.7760.23.camel@d2> On Thu, 2009-07-16 at 07:35 -0700, John Reiser wrote: > Yanko Kaneti wrote: > > On Thu, 2009-07-16 at 10:05 -0400, Jeremy Katz wrote: > > >> Note that while kernel + initrd is all you "need", not having the stage2 > >> means we have to ask where to find it rather than being able to automate > >> the use of the mirror list for everything > > > > Anything in particular that prevents the loader from using the mirror > > list to find a suitable location for stage2 ? ..other than "no patches > > for it yet" > > Especially for testing rawhide, I find that using the mirror list is problematic. > Some mirrors sync quickly (a couple hours), others take significantly longer > (*many* hours). I would rather specify the mirror explicitly. No need for the possibility of one to exclude the other. Given a command line parameter(s) (or the lack of it) the loader might decide to: - use the mirrorlist and proceed with getting stage2 all automatically. - use the mirrorlist and give option of choosing a particular mirror or enter a new one. - not use the mirror list at all and use the supplied url or ask for it if there isn't one. Like it does now. All useful options depending on the use case. From fedora at matbooth.co.uk Thu Jul 16 14:59:49 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Thu, 16 Jul 2009 15:59:49 +0100 Subject: Plan for Friday's (20090717) FESCo meeting In-Reply-To: References: Message-ID: <9497e9990907160759y50369f4btafb063ca136b56f8@mail.gmail.com> On Thu, Jul 16, 2009 at 5:00 AM, Jon Stanley wrote: > 197 ? ? noarch subpackages - > https://fedoraproject.org/wiki/Features/NoarchSubpackages Huh. I'm already using this functionality in F-11 for my LPG package. [1] Am I wrong to be doing so? I did notice scratch builds don't seem to like noarch subpackages very much. [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=114402 -- 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 katzj at redhat.com Thu Jul 16 15:02:32 2009 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 16 Jul 2009 11:02:32 -0400 Subject: creating minimal boot image for network installations In-Reply-To: <1247754154.7760.17.camel@d2> References: <1247745578.3796.44.camel@eagle.danny.cz> <20090716140506.GA46251@redhat.com> <1247754154.7760.17.camel@d2> Message-ID: <20090716150232.GA46402@redhat.com> On Thursday, July 16 2009, Yanko Kaneti said: > On Thu, 2009-07-16 at 10:05 -0400, Jeremy Katz wrote: > > On Thursday, July 16 2009, Dan Hor?k said: > > > I don't know about a simple way to start a network installation of > > > Fedora from USB stick. Creating of boot.img, that server that purpose, > > > was stopped by rel-engs some releases ago. I have found a blog post [1] > > > that makes possible to transform a boot.iso image into a bootable USB > > > stick. But it still requires to download the 200+ MB large boot.iso file > > > and do it by hand, while in theory only initrd.img and vmlinuz files > > > should be needed and the whole process could be automated > .. > > > > Note that while kernel + initrd is all you "need", not having the stage2 > > means we have to ask where to find it rather than being able to automate > > the use of the mirror list for everything > > Anything in particular that prevents the loader from using the mirror > list to find a suitable location for stage2 ? ..other than "no patches > for it yet" No patches and it's probably not worth the effort -- having stage2 on media also helps a lot with memory usage as we're not shoving stage2 into memory Jeremy From sahartsu at xs4all.nl Thu Jul 16 15:13:42 2009 From: sahartsu at xs4all.nl (Stefan Hartsuiker) Date: Thu, 16 Jul 2009 17:13:42 +0200 (CEST) Subject: Against what do I file this bug? Message-ID: <3474.145.100.24.27.1247757222.squirrel@webmail.xs4all.nl> On Thu, July 16, 2009 16:33, John5342 wrote: > 2009/7/16 Stefan Hartsuiker : >> On Wed, July 15, 2009 17:31, Matthew Woehlke wrote: >>> S.A. Hartsuiker wrote: >>>> On 07/15/2009 01:24 AM, Matthew Woehlke wrote: >>>>> This sounds like an initrd problem to me, but I am no expert. >>>> >>>> ??Uhm, no. I am in the ''Fedora Interactive'' bit, the >>>> /etc/rc.d/rc.sysinit at that moment. >>> >>> What I mean is, if you aren't getting something mounted, my first guess >>> would be that the contents of the initrd are wrong. That might be a >>> mkinitrd problem, but it might be something else. I am not a boot >>> process expert... ergo I probably will not be of further help; sorry. >>> >> >> Thanks for the effort anyway :) >> >>> I can think of one other question that might help someone else help you, >>> however. Is it only /boot that doesn't mount? What about /, swap, and >>> any other disk mounts (i.e. /proc, /sys are likely not interesting) you >>> have configured? >> >> The fakeraid mirrored device only contains two partitions, namely p2 ( to be >> mounted on /) ??and p1 (to be mounted on /boot). >> All other things that are to be mounted can be mounted (at the point of the >> error not everything is yet moounted though) >> >> One other bit of an odd thing that may not have been made completely clear >> is that for the fakeraid mirrored device no device files exist. This >> includes >> the root partition/mount even though it is actually mounted ro at the point >> of >> the error. >> >> Another thing I just noticed is that the devicenode numbers (major/minor) >> that >> are used for the fakeraid mirrored device during a livecd run are 253/0, >> 253/1 >> and 253/2. These numbers are in a ''normal'' boot sequence (the one that >> fails >> to startup correctly) used by the second fakeraid device. >> >> Does devicemapper or somesuch remove pre-existing devices if they don't >> match >> it's idea of waht is should be or does devicemapper just start at the >> ''beginning'' when creating devicenodes? >> >> Kind regards, >> Stefan Hartsuiker > > This may be completely un-related but ever since i first started using > FC3 (up to and including F11) i have had the same issue with nvidia > fake raid. I wasn't installing to the raid but the symptoms were > almost identical. My problem was that the dmraid command (which also > creates the devicemapper entries in /dev/) wasn't making it into the > initrd image. All i did was run the install dvd in rescue mode, chroot > to the install, run 'dmraid -ay' to make sure the fakeraid was enabled > and then recreate the initrd using mkinitrd. > Hmm, dmraid refuses to activate the fakeraid mirrored device. See the output below: [root at sparhawk ~]# dmraid -d -ay -v DEBUG: _find_set: searching nvidia_ddcacjcd DEBUG: _find_set: not found nvidia_ddcacjcd DEBUG: _find_set: searching nvidia_ddcacjcd DEBUG: _find_set: not found nvidia_ddcacjcd DEBUG: _find_set: searching nvidia_bcfahchh DEBUG: _find_set: searching nvidia_bcfahchh DEBUG: _find_set: not found nvidia_bcfahchh DEBUG: _find_set: not found nvidia_bcfahchh DEBUG: _find_set: searching nvidia_bcfahchh DEBUG: _find_set: not found nvidia_bcfahchh DEBUG: _find_set: searching nvidia_bcfahchh DEBUG: _find_set: found nvidia_bcfahchh DEBUG: _find_set: searching nvidia_bcfahchh DEBUG: _find_set: found nvidia_bcfahchh DEBUG: checking nvidia device "/dev/sdc" DEBUG: set status of set "nvidia_ddcacjcd" to 16 DEBUG: checking nvidia device "/dev/sda" DEBUG: checking nvidia device "/dev/sdb" DEBUG: set status of set "nvidia_bcfahchh" to 16 RAID set "nvidia_ddcacjcd" already active INFO: Activating linear raid set "nvidia_ddcacjcd" RAID set "nvidia_bcfahchh" was not activated <-- why? DEBUG: _find_set: searching nvidia_ddcacjcdp1 DEBUG: _find_set: not found nvidia_ddcacjcdp1 RAID set "nvidia_ddcacjcdp1" already active INFO: Activating partition raid set "nvidia_ddcacjcdp1" DEBUG: freeing devices of RAID set "nvidia_ddcacjcd" DEBUG: freeing device "nvidia_ddcacjcd", path "/dev/sdc" DEBUG: freeing devices of RAID set "nvidia_bcfahchh" DEBUG: freeing device "nvidia_bcfahchh", path "/dev/sda" DEBUG: freeing device "nvidia_bcfahchh", path "/dev/sdb" DEBUG: freeing devices of RAID set "nvidia_ddcacjcdp1" DEBUG: freeing device "nvidia_ddcacjcdp1", path "/dev/mapper/nvidia_ddcacjcd" Here the nvidia_bcfahchh is the fakeraid mirrored device and nvidia_ddcacjcd is the other one. nvidia_bcfahchh consists of /dev/sda and /dev/sdb. Does anyone have an idea as to why dmraid does not activate nvidia_bcfahchh? > Since you installed to the disk i can't imagine why dmraid didn't make > it into initrd but you're situation did sound familiar. Hope it helps. > I think dmraid is actually in the initrd (not checked yet, will do later tonight), since it can find nvidia_ddcacjcd. But al least your tip gives me a tool to produce more debugging output :) Kind regards, Stefan Hartsuiker [snip signature] From mikeb at redhat.com Thu Jul 16 15:49:10 2009 From: mikeb at redhat.com (Mike Bonnet) Date: Thu, 16 Jul 2009 11:49:10 -0400 Subject: using yumdownloader to fetch sources from koji In-Reply-To: References: Message-ID: <4A5F4BF6.2090203@redhat.com> On 07/16/2009 05:46 AM, Marcus Moeller wrote: > Hi all, > > is there a way to add http://kojipkgs.fedoraproject.org/packages/ as > yum repository, as I wanted to make use of yumdownloader to fetch some > SRPMs from there. Using: koji download-build --arch=src might be easier. There's no way to add the /packages/ directory as a yum repository (nor would we want to encourage that). From christof at damian.net Thu Jul 16 15:58:38 2009 From: christof at damian.net (Christof Damian) Date: Thu, 16 Jul 2009 17:58:38 +0200 Subject: creating minimal boot image for network installations In-Reply-To: <20090716140506.GA46251@redhat.com> References: <1247745578.3796.44.camel@eagle.danny.cz> <20090716140506.GA46251@redhat.com> Message-ID: On Thu, Jul 16, 2009 at 16:05, Jeremy Katz wrote: > > With Fedora 12, you'll be able to just dd the boot.iso onto a USB stick > since we're making isohybrid'd images. > Does this mean we will might be able to dd the install dvd iso to a usb stick too and I can finally get rid of some drives? Christof From katzj at redhat.com Thu Jul 16 16:03:27 2009 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 16 Jul 2009 12:03:27 -0400 Subject: creating minimal boot image for network installations In-Reply-To: References: <1247745578.3796.44.camel@eagle.danny.cz> <20090716140506.GA46251@redhat.com> Message-ID: <20090716160326.GC46402@redhat.com> On Thursday, July 16 2009, Christof Damian said: > On Thu, Jul 16, 2009 at 16:05, Jeremy Katz wrote: > > With Fedora 12, you'll be able to just dd the boot.iso onto a USB stick > > since we're making isohybrid'd images. > > Does this mean we will might be able to dd the install dvd iso to a > usb stick too and I can finally get rid of some drives? There's more work that's going to be needed to make it generally work across the realm of install methods and due to the short runway of Fedora 12, it's unlikely to happen there. It's something that at least I'd like to continue working towards, though over the next release or two. Jeremy From mtasaka at ioa.s.u-tokyo.ac.jp Thu Jul 16 16:11:27 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 17 Jul 2009 01:11:27 +0900 Subject: Any Ruby Packagers Here? In-Reply-To: <4A5CC1DE.9030202@gmail.com> References: <4A5CC1DE.9030202@gmail.com> Message-ID: <4A5F512F.5050208@ioa.s.u-tokyo.ac.jp> Frank Murphy wrote, at 07/15/2009 02:35 AM +9:00: > I don't know ruby. > > But: > http://tinyurl.com/9m4wzr > > is some ruby stuff to identify snippets of Code. > Any ruby knowing people willing to package it? > > > Regards, > > Frank It would be appreciated if you would add the request on here [1] so that we can keep track of this. However as far as I checked quickly rubygem-chrislo-sourceclassifier 0.2.3 depends on rubygem-echoe and rubygem-echoe is legally problematic [2] So it cannot be expected that rubygem-chrislo-sourceclassifier will be imported into Fedora soon. [1] https://fedoraproject.org/wiki/Package_maintainers_wishlist [2] http://rubyforge.org/forum/forum.php?thread_id=44709&forum_id=13986 Regards, Mamoru From jkeating at j2solutions.net Thu Jul 16 16:10:51 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 16 Jul 2009 09:10:51 -0700 Subject: Mock issue with ifarch BuildRequires In-Reply-To: <4A5F1A05.5000404@redhat.com> References: <4A5F1A05.5000404@redhat.com> Message-ID: <437A36BE-65B0-40AD-A699-5184CBB53C4B@j2solutions.net> On Jul 16, 2009, at 5:16, Karsten Hopp wrote: > Am 14.07.2009 01:50, schrieb Gianluca Sforna: >> Sorry for the cross-posting, I'm trying to get a clue... >> >> >> ---------- Forwarded message ---------- >> From: Gianluca Sforna >> Date: Mon, Jul 13, 2009 at 1:38 AM >> Subject: Mock issue with ifarch BuildRequires >> To: Discussion of Fedora build system> list at redhat.com> >> >> >> I am trying to run the tests included in the BuildBot package during >> the RPM build, and one of the tests requires darcs, which is built in >> Fedora ExclusiveArch %{ix86} x86_64 ppc alpha. >> Now, I'm adding to buildbot's spec[1] file an ifarch like: >> >> %ifarch %{ix86} x86_64 ppc alpha >> # darcs ExclusiveArchs >> BuildRequires: darcs >> %endif >> >> but it seems darcs is never installed in the buildroot [2] >> >> am I just doing something stupid or there's a bug somewhere? >> >> [1] http://cvs.fedoraproject.org/viewvc/rpms/buildbot/devel/buildbot.spec?view=log >> [2] http://koji.fedoraproject.org/koji/getfile?taskID=1470380&name=root.log >> >> > > > %ifarch and %ifnarch unfortunately don't work in noarch packages. I > think that's a bug, > the arch information is there as p.e. ExcludeArch works, and just > those two don't get evaluated. > > CC: our rpm maintainers for comments > ExcludeArch only works due to some hacks in our compose tools that looks at the srpm info to see if the srpm has that info. The info itself does not make it to the noarch rpm file. -- Jes From a.badger at gmail.com Thu Jul 16 16:15:39 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 16 Jul 2009 09:15:39 -0700 Subject: Plan for Friday's (20090717) FESCo meeting In-Reply-To: <9497e9990907160759y50369f4btafb063ca136b56f8@mail.gmail.com> References: <9497e9990907160759y50369f4btafb063ca136b56f8@mail.gmail.com> Message-ID: <4A5F522B.6080304@gmail.com> On 07/16/2009 07:59 AM, Mat Booth wrote: > On Thu, Jul 16, 2009 at 5:00 AM, Jon Stanley wrote: >> 197 noarch subpackages - >> https://fedoraproject.org/wiki/Features/NoarchSubpackages > > Huh. I'm already using this functionality in F-11 for my LPG package. [1] > You're fine. The Feature seems to be about mandating that a large percentage of our packages switch to noarch subpackages. So it's fine to be doing this early. > Am I wrong to be doing so? I did notice scratch builds don't seem to > like noarch subpackages very much. > > [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=114402 > -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From rvinyard at cs.nmsu.edu Thu Jul 16 16:36:17 2009 From: rvinyard at cs.nmsu.edu (Rick L. Vinyard, Jr.) Date: Thu, 16 Jul 2009 10:36:17 -0600 Subject: Fedora 11 / EPEL 5 MD5 Issue In-Reply-To: <4A5F3ACA.5070204@redhat.com> References: <4A5F3ACA.5070204@redhat.com> Message-ID: Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/16/2009 10:32 AM, Rick L. Vinyard, Jr. wrote: >> I've built the following package on Fedora 10 and 11 in mock without any >> problems. >> http://miskatonic.cs.nmsu.edu/pub/libMini-9.0.3-2.fc11.src.rpm >> >> However, when I try and build for EPEL 5 using mock on a F11 machine I >> get >> the following in root.log: >> >> DEBUG util.py:256: error: unpacking of archive failed on file >> /builddir/build/SOURCES/MINI-9.0.3.zip;4a5f3532: cpio: MD5 sum mismatch >> >> Any suggestions? >> > > To extract sources from an SRPM: > rpm2cpio | cpio --extract > (Do this in its own directory) > > To enable the old checksum (for building RHEL packages): > rpmbuild -bs --define _source_filedigest_algorithm=1 > > This will recreate the SRPM using an MD5 sum instead of a SHA1 sum. > > You can then use that in mock. > Excellent. Thanks. From dennis at ausil.us Thu Jul 16 16:42:40 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 16 Jul 2009 11:42:40 -0500 Subject: Fedora 11 / EPEL 5 MD5 Issue In-Reply-To: <2d319b780907160751p1a317d85ta14e34cfd1219b5e@mail.gmail.com> References: <2d319b780907160751p1a317d85ta14e34cfd1219b5e@mail.gmail.com> Message-ID: <200907161142.45760.dennis@ausil.us> On Thursday 16 July 2009 09:51:32 am Mathieu Bridon (bochecha) wrote: > On Thu, Jul 16, 2009 at 16:32, Rick L. Vinyard, Jr. wrote: > > I've built the following package on Fedora 10 and 11 in mock without any > > problems. > > http://miskatonic.cs.nmsu.edu/pub/libMini-9.0.3-2.fc11.src.rpm > > > > However, when I try and build for EPEL 5 using mock on a F11 machine I > > get the following in root.log: > > > > DEBUG util.py:256: error: unpacking of archive failed on file > > /builddir/build/SOURCES/MINI-9.0.3.zip;4a5f3532: cpio: MD5 sum mismatch > > > > Any suggestions? > > I did the following two days ago (all on a F11 host) : > - rebuild the F11 srpm in a F10 mock chroot > - rebuild the F10 srpm in a EL5 mock chroot > > F11 and F10 rpm versions are compatible, and so are F10 and EL5. > > Totally suboptimal, but it works, and I didn't have time to search > more thoroughly for a better solution :) just for this type of thing i added a new script to fedora-packager rpmbuild- md5 it creates rpms/srpms with the old style hashes. its a simple bash script that is a wrapper around rpmbuild with the defines for old style hashes. the fedora-packager with it is in updates-testing. 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 silfreed at silfreed.net Thu Jul 16 17:07:42 2009 From: silfreed at silfreed.net (Doug Warner) Date: Thu, 16 Jul 2009 13:07:42 -0400 Subject: Fedora 11 / EPEL 5 MD5 Issue In-Reply-To: <200907161142.45760.dennis@ausil.us> References: <2d319b780907160751p1a317d85ta14e34cfd1219b5e@mail.gmail.com> <200907161142.45760.dennis@ausil.us> Message-ID: <4A5F5E5E.4030408@silfreed.net> On 07/16/2009 12:42 PM, Dennis Gilmore wrote: > On Thursday 16 July 2009 09:51:32 am Mathieu Bridon (bochecha) wrote: >> On Thu, Jul 16, 2009 at 16:32, Rick L. Vinyard, Jr. > wrote: >>> I've built the following package on Fedora 10 and 11 in mock without any >>> problems. >>> http://miskatonic.cs.nmsu.edu/pub/libMini-9.0.3-2.fc11.src.rpm >>> >>> However, when I try and build for EPEL 5 using mock on a F11 machine I >>> get the following in root.log: >>> >>> DEBUG util.py:256: error: unpacking of archive failed on file >>> /builddir/build/SOURCES/MINI-9.0.3.zip;4a5f3532: cpio: MD5 sum mismatch >>> >>> Any suggestions? >> I did the following two days ago (all on a F11 host) : >> - rebuild the F11 srpm in a F10 mock chroot >> - rebuild the F10 srpm in a EL5 mock chroot >> >> F11 and F10 rpm versions are compatible, and so are F10 and EL5. >> >> Totally suboptimal, but it works, and I didn't have time to search >> more thoroughly for a better solution :) > > just for this type of thing i added a new script to fedora-packager rpmbuild- > md5 it creates rpms/srpms with the old style hashes. its a simple bash > script that is a wrapper around rpmbuild with the defines for old style hashes. > the fedora-packager with it is in updates-testing. > Would it be possible to update the mock configs with these settings as well? -Doug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From dennis at ausil.us Thu Jul 16 17:16:09 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 16 Jul 2009 12:16:09 -0500 Subject: Fedora 11 / EPEL 5 MD5 Issue In-Reply-To: <4A5F5E5E.4030408@silfreed.net> References: <200907161142.45760.dennis@ausil.us> <4A5F5E5E.4030408@silfreed.net> Message-ID: <200907161216.10044.dennis@ausil.us> On Thursday 16 July 2009 12:07:42 pm Doug Warner wrote: > On 07/16/2009 12:42 PM, Dennis Gilmore wrote: > > On Thursday 16 July 2009 09:51:32 am Mathieu Bridon (bochecha) wrote: > >> On Thu, Jul 16, 2009 at 16:32, Rick L. Vinyard, > >> Jr. > > > > wrote: > >>> I've built the following package on Fedora 10 and 11 in mock without > >>> any problems. > >>> http://miskatonic.cs.nmsu.edu/pub/libMini-9.0.3-2.fc11.src.rpm > >>> > >>> However, when I try and build for EPEL 5 using mock on a F11 machine I > >>> get the following in root.log: > >>> > >>> DEBUG util.py:256: error: unpacking of archive failed on file > >>> /builddir/build/SOURCES/MINI-9.0.3.zip;4a5f3532: cpio: MD5 sum mismatch > >>> > >>> Any suggestions? > >> > >> I did the following two days ago (all on a F11 host) : > >> - rebuild the F11 srpm in a F10 mock chroot > >> - rebuild the F10 srpm in a EL5 mock chroot > >> > >> F11 and F10 rpm versions are compatible, and so are F10 and EL5. > >> > >> Totally suboptimal, but it works, and I didn't have time to search > >> more thoroughly for a better solution :) > > > > just for this type of thing i added a new script to fedora-packager > > rpmbuild- md5 it creates rpms/srpms with the old style hashes. its a > > simple bash script that is a wrapper around rpmbuild with the defines for > > old style hashes. the fedora-packager with it is in updates-testing. > > Would it be possible to update the mock configs with these settings as > well? > > -Doug It is nothing to do with what is in the mock configs. the issue is that if you create a srpm on F-11 or rawhide then it uses internal hashing that is not understood by anything previous. F-10 uses md5 but understands the new style also. inside the mock chroot they use what is the default for that release. 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 silfreed at silfreed.net Thu Jul 16 17:22:56 2009 From: silfreed at silfreed.net (Doug Warner) Date: Thu, 16 Jul 2009 13:22:56 -0400 Subject: Fedora 11 / EPEL 5 MD5 Issue In-Reply-To: <200907161216.10044.dennis@ausil.us> References: <200907161142.45760.dennis@ausil.us> <4A5F5E5E.4030408@silfreed.net> <200907161216.10044.dennis@ausil.us> Message-ID: <4A5F61F0.1070407@silfreed.net> On 07/16/2009 01:16 PM, Dennis Gilmore wrote: > It is nothing to do with what is in the mock configs. the issue is that if you > create a srpm on F-11 or rawhide then it uses internal hashing that is not > understood by anything previous. F-10 uses md5 but understands the new style > also. > > inside the mock chroot they use what is the default for that release. Great, thanks for the explanation. I apparently didn't read enough of the thread to understand. -Doug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From opensource at till.name Thu Jul 16 17:52:35 2009 From: opensource at till.name (Till Maas) Date: Thu, 16 Jul 2009 19:52:35 +0200 Subject: Packages tracked by FEver that need to be updated In-Reply-To: References: <200907102243.14776.opensource@till.name> Message-ID: <200907161952.47891.opensource@till.name> On Saturday 11 July 2009 13:29:59 Rakesh Pandit wrote: > Thanks for nice work. I too mailed other some time back .. but did not > recieved any mail back. May you share the program ;) My current code is available at http://fedorapeople.org/gitweb?p=till/public_git/cnucnu.git;a=summary But don't be disappointed, because it does not yet do very much. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From john5342 at googlemail.com Thu Jul 16 17:59:49 2009 From: john5342 at googlemail.com (John5342) Date: Thu, 16 Jul 2009 18:59:49 +0100 Subject: Against what do I file this bug? In-Reply-To: <3474.145.100.24.27.1247757222.squirrel@webmail.xs4all.nl> References: <3474.145.100.24.27.1247757222.squirrel@webmail.xs4all.nl> Message-ID: <6dc6523c0907161059l264fe724he08a35c8f04e236@mail.gmail.com> 2009/7/16 Stefan Hartsuiker : > On Thu, July 16, 2009 16:33, John5342 wrote: >> 2009/7/16 Stefan Hartsuiker : >>> On Wed, July 15, 2009 17:31, Matthew Woehlke wrote: >>>> S.A. Hartsuiker wrote: >>>>> On 07/15/2009 01:24 AM, Matthew Woehlke wrote: >>>>>> This sounds like an initrd problem to me, but I am no expert. >>>>> >>>>> ?Uhm, no. I am in the ''Fedora Interactive'' bit, the >>>>> /etc/rc.d/rc.sysinit at that moment. >>>> >>>> What I mean is, if you aren't getting something mounted, my first guess >>>> would be that the contents of the initrd are wrong. That might be a >>>> mkinitrd problem, but it might be something else. I am not a boot >>>> process expert... ergo I probably will not be of further help; sorry. >>>> >>> >>> Thanks for the effort anyway :) >>> >>>> I can think of one other question that might help someone else help you, >>>> however. Is it only /boot that doesn't mount? What about /, swap, and >>>> any other disk mounts (i.e. /proc, /sys are likely not interesting) you >>>> have configured? >>> >>> The fakeraid mirrored device only contains two partitions, namely p2 ( to be >>> mounted on /) ?and p1 (to be mounted on /boot). >>> All other things that are to be mounted can be mounted (at the point of the >>> error not everything is yet moounted though) >>> >>> One other bit of an odd thing that may not have been made completely clear >>> is that for the fakeraid mirrored device no device files exist. This >>> includes >>> the root partition/mount even though it is actually mounted ro at the point >>> of >>> the error. >>> >>> Another thing I just noticed is that the devicenode numbers (major/minor) >>> that >>> are used for the fakeraid mirrored device during a livecd run are 253/0, >>> 253/1 >>> and 253/2. These numbers are in a ''normal'' boot sequence (the one that >>> fails >>> to startup correctly) used by the second fakeraid device. >>> >>> Does devicemapper or somesuch remove pre-existing devices if they don't >>> match >>> it's idea of waht is should be or does devicemapper just start at the >>> ''beginning'' when creating devicenodes? >>> >>> Kind regards, >>> Stefan Hartsuiker >> >> This may be completely un-related but ever since i first started using >> FC3 (up to and including F11) i have had the same issue with nvidia >> fake raid. I wasn't installing to the raid but the symptoms were >> almost identical. My problem was that the dmraid command (which also >> creates the devicemapper entries in /dev/) wasn't making it into the >> initrd image. All i did was run the install dvd in rescue mode, chroot >> to the install, run 'dmraid -ay' to make sure the fakeraid was enabled >> and then recreate the initrd using mkinitrd. >> > > Hmm, dmraid refuses to activate the fakeraid mirrored device. See the output > below: > [root at sparhawk ~]# dmraid -d -ay -v > DEBUG: _find_set: searching nvidia_ddcacjcd > DEBUG: _find_set: not found nvidia_ddcacjcd > DEBUG: _find_set: searching nvidia_ddcacjcd > DEBUG: _find_set: not found nvidia_ddcacjcd > DEBUG: _find_set: searching nvidia_bcfahchh > DEBUG: _find_set: searching nvidia_bcfahchh > DEBUG: _find_set: not found nvidia_bcfahchh > DEBUG: _find_set: not found nvidia_bcfahchh > DEBUG: _find_set: searching nvidia_bcfahchh > DEBUG: _find_set: not found nvidia_bcfahchh > DEBUG: _find_set: searching nvidia_bcfahchh > DEBUG: _find_set: found nvidia_bcfahchh > DEBUG: _find_set: searching nvidia_bcfahchh > DEBUG: _find_set: found nvidia_bcfahchh > DEBUG: checking nvidia device "/dev/sdc" > DEBUG: set status of set "nvidia_ddcacjcd" to 16 > DEBUG: checking nvidia device "/dev/sda" > DEBUG: checking nvidia device "/dev/sdb" > DEBUG: set status of set "nvidia_bcfahchh" to 16 > RAID set "nvidia_ddcacjcd" already active > INFO: Activating linear raid set "nvidia_ddcacjcd" > RAID set "nvidia_bcfahchh" was not activated ? ? ? ? ? ? <-- why? > DEBUG: _find_set: searching nvidia_ddcacjcdp1 > DEBUG: _find_set: not found nvidia_ddcacjcdp1 > RAID set "nvidia_ddcacjcdp1" already active > INFO: Activating partition raid set "nvidia_ddcacjcdp1" > DEBUG: freeing devices of RAID set "nvidia_ddcacjcd" > DEBUG: freeing device "nvidia_ddcacjcd", path "/dev/sdc" > DEBUG: freeing devices of RAID set "nvidia_bcfahchh" > DEBUG: freeing device "nvidia_bcfahchh", path "/dev/sda" > DEBUG: freeing device "nvidia_bcfahchh", path "/dev/sdb" > DEBUG: freeing devices of RAID set "nvidia_ddcacjcdp1" > DEBUG: freeing device "nvidia_ddcacjcdp1", path "/dev/mapper/nvidia_ddcacjcd" > > Here the nvidia_bcfahchh is the fakeraid mirrored device and nvidia_ddcacjcd is > the other one. nvidia_bcfahchh consists of /dev/sda and /dev/sdb. > > Does anyone have an idea as to why dmraid does not activate nvidia_bcfahchh? > >> Since you installed to the disk i can't imagine why dmraid didn't make >> it into initrd but you're situation did sound familiar. Hope it helps. >> > I think dmraid is actually in the initrd (not checked yet, will do later > tonight), since it can find nvidia_ddcacjcd. By dmraid being in initrd i actually meant the call to the command but given the error your getting i would say what i suggested is not the same problem you are facing. > But al least your tip gives me a tool to produce more debugging output :) Glad it was at least of some use. A google for RAID set nvidia was not activated turned up a few results. No solid answers from any of the links i found but most of them seem to have one of 3 causes. Bad connections on sata drives, hardware issues or a bug in dmraid so to answer your original question check connections, then try filing a bug against dmraid and see if the experts have any better ideas. In the meantime see if you have any more luck with google. Good luck. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... From rvinyard at cs.nmsu.edu Thu Jul 16 18:07:37 2009 From: rvinyard at cs.nmsu.edu (Rick L. Vinyard, Jr.) Date: Thu, 16 Jul 2009 12:07:37 -0600 Subject: Fedora 11 / EPEL 5 MD5 Issue In-Reply-To: <200907161142.45760.dennis@ausil.us> References: <2d319b780907160751p1a317d85ta14e34cfd1219b5e@mail.gmail.com> <200907161142.45760.dennis@ausil.us> Message-ID: <98e8ac7c6f3c4840664ca53f82175698.squirrel@intranet.cs.nmsu.edu> Dennis Gilmore wrote: > On Thursday 16 July 2009 09:51:32 am Mathieu Bridon (bochecha) wrote: >> On Thu, Jul 16, 2009 at 16:32, Rick L. Vinyard, >> Jr. > wrote: >> > I've built the following package on Fedora 10 and 11 in mock without >> any >> > problems. >> > http://miskatonic.cs.nmsu.edu/pub/libMini-9.0.3-2.fc11.src.rpm >> > >> > However, when I try and build for EPEL 5 using mock on a F11 machine I >> > get the following in root.log: >> > >> > DEBUG util.py:256: error: unpacking of archive failed on file >> > /builddir/build/SOURCES/MINI-9.0.3.zip;4a5f3532: cpio: MD5 sum >> mismatch >> > >> > Any suggestions? >> >> I did the following two days ago (all on a F11 host) : >> - rebuild the F11 srpm in a F10 mock chroot >> - rebuild the F10 srpm in a EL5 mock chroot >> >> F11 and F10 rpm versions are compatible, and so are F10 and EL5. >> >> Totally suboptimal, but it works, and I didn't have time to search >> more thoroughly for a better solution :) > > just for this type of thing i added a new script to fedora-packager > rpmbuild- > md5 it creates rpms/srpms with the old style hashes. its a simple bash > script that is a wrapper around rpmbuild with the defines for old style > hashes. > the fedora-packager with it is in updates-testing. > Even better. Thanks. From fkooman at tuxed.net Thu Jul 16 18:56:29 2009 From: fkooman at tuxed.net (=?UTF-8?Q?Fran=C3=A7ois_Kooman?=) Date: Thu, 16 Jul 2009 20:56:29 +0200 Subject: Taking over dumpasn1 Message-ID: Hi, I would like to take over maintaining "dumpasn1". I was a bit premature in pressing the "take ownership button", I hope this is not a problem. Since it was last modified longer than 3 months ago there is a review request at https://bugzilla.redhat.com/show_bug.cgi?id=512228. Thanks, Fran?ois From ville.skytta at iki.fi Thu Jul 16 19:17:13 2009 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 16 Jul 2009 22:17:13 +0300 Subject: Taking over dumpasn1 In-Reply-To: References: Message-ID: <200907162217.15969.ville.skytta@iki.fi> On Thursday 16 July 2009, Fran?ois Kooman wrote: > Hi, > > I would like to take over maintaining "dumpasn1". I was a bit > premature in pressing the "take ownership button", I hope this is not > a problem. Not at all. Thanks. > Since it was last modified longer than 3 months ago there is a review > request at https://bugzilla.redhat.com/show_bug.cgi?id=512228. Oh, I could have sworn it was already updated to latest upstream. Will review. From lfarkas at lfarkas.org Thu Jul 16 19:17:33 2009 From: lfarkas at lfarkas.org (Farkas Levente) Date: Thu, 16 Jul 2009 21:17:33 +0200 Subject: Fedora 11 / EPEL 5 MD5 Issue In-Reply-To: <200907161142.45760.dennis@ausil.us> References: <2d319b780907160751p1a317d85ta14e34cfd1219b5e@mail.gmail.com> <200907161142.45760.dennis@ausil.us> Message-ID: <4A5F7CCD.30308@lfarkas.org> Dennis Gilmore wrote: > On Thursday 16 July 2009 09:51:32 am Mathieu Bridon (bochecha) wrote: >> On Thu, Jul 16, 2009 at 16:32, Rick L. Vinyard, Jr. > wrote: >>> I've built the following package on Fedora 10 and 11 in mock without any >>> problems. >>> http://miskatonic.cs.nmsu.edu/pub/libMini-9.0.3-2.fc11.src.rpm >>> >>> However, when I try and build for EPEL 5 using mock on a F11 machine I >>> get the following in root.log: >>> >>> DEBUG util.py:256: error: unpacking of archive failed on file >>> /builddir/build/SOURCES/MINI-9.0.3.zip;4a5f3532: cpio: MD5 sum mismatch >>> >>> Any suggestions? >> I did the following two days ago (all on a F11 host) : >> - rebuild the F11 srpm in a F10 mock chroot >> - rebuild the F10 srpm in a EL5 mock chroot >> >> F11 and F10 rpm versions are compatible, and so are F10 and EL5. >> >> Totally suboptimal, but it works, and I didn't have time to search >> more thoroughly for a better solution :) > > just for this type of thing i added a new script to fedora-packager rpmbuild- > md5 it creates rpms/srpms with the old style hashes. its a simple bash > script that is a wrapper around rpmbuild with the defines for old style hashes. > the fedora-packager with it is in updates-testing. the real problem is that you can't rebuild fedora's src.rpm on epel. the real good thing would be add a script which will be rebuild the new src.rpms. -- Levente "Si vis pacem para bellum!" From wcohen at redhat.com Thu Jul 16 19:44:33 2009 From: wcohen at redhat.com (William Cohen) Date: Thu, 16 Jul 2009 15:44:33 -0400 Subject: Adding 32-bit packages to ppc64 and x86_64 composes and yum repos Message-ID: <4A5F8321.6090701@redhat.com> I was looking through the oprofile rpms included in the Fedora yum repos for ppc64 and x86_64. Oprofile 0.9.4 has support for java profiling that uses shared libraries. These shared libraries are packaged in the oprofile-jit rpm. 64-bit platforms such as ppc64 and x86_64 can run 32-bit versions of java. Thus, the 32-bit versions of the oprofile-jit rpm need to be included in the repositories. How does one get those rpms added to the rpms? -Will From poelstra at redhat.com Thu Jul 16 20:11:21 2009 From: poelstra at redhat.com (John Poelstra) Date: Thu, 16 Jul 2009 13:11:21 -0700 Subject: Proposal to Drop Fedora 12 Features Message-ID: <4A5F8969.4070206@redhat.com> Hi FESCo, After requesting status updates, including direct email to the feature owners, the following feature pages do not have a current status. https://fedoraproject.org/wiki/Features/DebuginfoFS https://fedoraproject.org/wiki/Features/Multiseat https://fedoraproject.org/wiki/Features/SystemtapStaticProbes https://fedoraproject.org/wiki/Features/XZRpmPayloads https://fedoraproject.org/wiki/Features/F12X86Support In accordance with our recorded process about providing status, I am proposing that they reviewed and dropped from the Fedora 12 feature list at tomorrow's FESCo meeting. https://fedoraproject.org/wiki/Features/Policy/Dropping Thank you, John _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From rvinyard at cs.nmsu.edu Thu Jul 16 20:30:16 2009 From: rvinyard at cs.nmsu.edu (Rick L. Vinyard, Jr.) Date: Thu, 16 Jul 2009 14:30:16 -0600 Subject: Fedora 11 / EPEL 5 MD5 Issue In-Reply-To: <4A5F7CCD.30308@lfarkas.org> References: <2d319b780907160751p1a317d85ta14e34cfd1219b5e@mail.gmail.com> <200907161142.45760.dennis@ausil.us> <4A5F7CCD.30308@lfarkas.org> Message-ID: <057cc486d356afb3f1999dc7950c8e81.squirrel@intranet.cs.nmsu.edu> Farkas Levente wrote: > Dennis Gilmore wrote: >> On Thursday 16 July 2009 09:51:32 am Mathieu Bridon (bochecha) wrote: >>> On Thu, Jul 16, 2009 at 16:32, Rick L. Vinyard, >>> Jr. >> wrote: >>>> I've built the following package on Fedora 10 and 11 in mock without >>>> any >>>> problems. >>>> http://miskatonic.cs.nmsu.edu/pub/libMini-9.0.3-2.fc11.src.rpm >>>> >>>> However, when I try and build for EPEL 5 using mock on a F11 machine I >>>> get the following in root.log: >>>> >>>> DEBUG util.py:256: error: unpacking of archive failed on file >>>> /builddir/build/SOURCES/MINI-9.0.3.zip;4a5f3532: cpio: MD5 sum >>>> mismatch >>>> >>>> Any suggestions? >>> I did the following two days ago (all on a F11 host) : >>> - rebuild the F11 srpm in a F10 mock chroot >>> - rebuild the F10 srpm in a EL5 mock chroot >>> >>> F11 and F10 rpm versions are compatible, and so are F10 and EL5. >>> >>> Totally suboptimal, but it works, and I didn't have time to search >>> more thoroughly for a better solution :) >> >> just for this type of thing i added a new script to fedora-packager >> rpmbuild- >> md5 it creates rpms/srpms with the old style hashes. its a simple bash >> script that is a wrapper around rpmbuild with the defines for old style >> hashes. >> the fedora-packager with it is in updates-testing. > > the real problem is that you can't rebuild fedora's src.rpm on epel. the > real good thing would be add a script which will be rebuild the new > src.rpms. > It wouldn't be that hard... just unpack and repack with MD5. The only problem I see is that a corrupted file would be repacked with a valid checksum. From jlaska at redhat.com Thu Jul 16 20:33:46 2009 From: jlaska at redhat.com (James Laska) Date: Thu, 16 Jul 2009 16:33:46 -0400 Subject: Reminder - Alpha Blocker Bug Meeting: Friday 2009-07-17 In-Reply-To: <4A5BBAB7.8040100@redhat.com> References: <4A5BBAB7.8040100@redhat.com> Message-ID: <1247776426.2712.56.camel@flatline.devel.redhat.com> What: F12Alpha Blocker bug meeting (https://bugzilla.redhat.com/showdependencytree.cgi?id=F12Alpha&hide_resolved=1) When: Friday, 2009-07-17 @ 17:00 UTC (1 PM EDT) Where: #fedora-bugzappers In accordance with the SOP [1], just sending out a quick reminder. There will be a Alpha Blocker bug meeting held tomorrow in #fedora-bugzappers. While the blocker list is currently fairly small, the plan is to hold regular blocker review meetings [2] during the F12 cycle to minimize surprises. Bring out your blockers ... Thanks, James [1] https://fedoraproject.org/wiki/User:Poelstra/blocker_bug_meeting_sop [2] http://poelstra.fedorapeople.org/schedules/f-12/f-12-releng-tasks.html -------------- next part -------------- A 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 drago01 at gmail.com Thu Jul 16 20:35:49 2009 From: drago01 at gmail.com (drago01) Date: Thu, 16 Jul 2009 22:35:49 +0200 Subject: Proposal to Drop Fedora 12 Features In-Reply-To: <4A5F8969.4070206@redhat.com> References: <4A5F8969.4070206@redhat.com> Message-ID: On Thu, Jul 16, 2009 at 10:11 PM, John Poelstra wrote: > Hi FESCo, > https://fedoraproject.org/wiki/Features/XZRpmPayloads > https://fedoraproject.org/wiki/Features/F12X86Support Afaik those are blocking on 1) xz review request 2) rel-eng to coordinate a mass rebuild From mschwendt at gmail.com Thu Jul 16 12:30:59 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 16 Jul 2009 14:30:59 +0200 Subject: Audacious 2.1 coming - SONAME change Message-ID: <20090716143059.0113f6af@faldor> Audacious 2.1 is going to land in Rawhide soon. src.rpm updates have been comitted to Fedora package cvs/devel already. Compared with 1.5.1 this new final release changes the SONAME version of essential libraries within the audacious-libs package. Dependencies will need to be rebuilt. Plugins may need a minor update to sync with modified plugin API structures. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jgarzik at pobox.com Thu Jul 16 20:58:37 2009 From: jgarzik at pobox.com (Jeff Garzik) Date: Thu, 16 Jul 2009 16:58:37 -0400 Subject: koji build dependencies in cloud computing project? Message-ID: <4A5F947D.4090707@pobox.com> I just opened bugs #511938, #511941, #511944 to review the 3 new packages that compromise my little cloud computing project: cld, chunkd and tabled. cld and chunkd built just fine in koji, but tabled does not: it BuildRequires both cld and chunkd. I thought 'koji chain-build' might help, if I passed all three to chain-build on the koji cmd line, but there is very little documentation anywhere on chain-build. Also, chain-build does not support --scratch, which I wanted to use. Is there any way to convince koji to SCRATCH build tabled, short of including cld and chunkd in Fedora rawhide? Thanks, Jeff (a bit rusty at pkg mgmt, admittedly) From dennis at ausil.us Thu Jul 16 21:12:30 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 16 Jul 2009 16:12:30 -0500 Subject: koji build dependencies in cloud computing project? In-Reply-To: <4A5F947D.4090707@pobox.com> References: <4A5F947D.4090707@pobox.com> Message-ID: <200907161612.36734.dennis@ausil.us> On Thursday 16 July 2009 03:58:37 pm Jeff Garzik wrote: > I just opened bugs #511938, #511941, #511944 to review the 3 new > packages that compromise my little cloud computing project: cld, chunkd > and tabled. > > cld and chunkd built just fine in koji, but tabled does not: it > BuildRequires both cld and chunkd. > > I thought 'koji chain-build' might help, if I passed all three to > chain-build on the koji cmd line, but there is very little documentation > anywhere on chain-build. Also, chain-build does not support --scratch, > which I wanted to use. > > Is there any way to convince koji to SCRATCH build tabled, short of > including cld and chunkd in Fedora rawhide? > > Thanks, > > Jeff (a bit rusty at pkg mgmt, admittedly) Its not possible you can only build against what is released in fedora 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 mjg at redhat.com Thu Jul 16 21:28:57 2009 From: mjg at redhat.com (Matthew Garrett) Date: Thu, 16 Jul 2009 22:28:57 +0100 Subject: ASPM enabled by default - mild potential for breakage Message-ID: <20090716212857.GA23301@srcf.ucam.org> I've just flicked ASPM (Active State Power Management - runtime power saving on PCIe hardware) on by default, and it'll be that way in the next rawhide kernel build. There's the potential for some buggy hardware to be upset by this. If your system no longer boots or some hardware doesn't work, try booting with the pcie_aspm=off argument. If that fixes things please file a bug against the kernel and assign it to me (mjg at redhat.com). Include dmesg and the output of lspci -n. There's some reasonable heuristics in the kernel to detect supported hardware, so I'm hoping that people shouldn't see any adverse affects. -- Matthew Garrett | mjg59 at srcf.ucam.org From zaitcev at redhat.com Thu Jul 16 22:36:46 2009 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 16 Jul 2009 16:36:46 -0600 Subject: koji build dependencies in cloud computing project? In-Reply-To: <200907161612.36734.dennis@ausil.us> References: <4A5F947D.4090707@pobox.com> <200907161612.36734.dennis@ausil.us> Message-ID: <20090716163646.55d8c491@redhat.com> On Thu, 16 Jul 2009 16:12:30 -0500, Dennis Gilmore wrote: > On Thursday 16 July 2009 03:58:37 pm Jeff Garzik wrote: > > cld and chunkd built just fine in koji, but tabled does not: it > > BuildRequires both cld and chunkd. > Its not possible you can only build against what is released in fedora Do I understand it right that CLD has to get into Rawhide first, then? And once it's established there, chunk and tabled can move in? -- Pete From tcallawa at redhat.com Thu Jul 16 22:38:34 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 16 Jul 2009 18:38:34 -0400 Subject: koji build dependencies in cloud computing project? In-Reply-To: <20090716163646.55d8c491@redhat.com> References: <4A5F947D.4090707@pobox.com> <200907161612.36734.dennis@ausil.us> <20090716163646.55d8c491@redhat.com> Message-ID: <4A5FABEA.9060008@redhat.com> On 07/16/2009 06:36 PM, Pete Zaitcev wrote: > On Thu, 16 Jul 2009 16:12:30 -0500, Dennis Gilmore wrote: >> On Thursday 16 July 2009 03:58:37 pm Jeff Garzik wrote: > >>> cld and chunkd built just fine in koji, but tabled does not: it >>> BuildRequires both cld and chunkd. > >> Its not possible you can only build against what is released in fedora > > Do I understand it right that CLD has to get into Rawhide first, then? > And once it's established there, chunk and tabled can move in? You can't do chained scratch builds like Jeff wanted to do. So, if Package Foo BuildRequires packages Bar and Baz, Bar and Baz need to be in Fedora and built for the target. Then, you can do a scratch build of Foo. ~spot From jkeating at redhat.com Thu Jul 16 23:05:21 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 16 Jul 2009 16:05:21 -0700 Subject: Adding 32-bit packages to ppc64 and x86_64 composes and yum repos In-Reply-To: <4A5F8321.6090701@redhat.com> References: <4A5F8321.6090701@redhat.com> Message-ID: <1247785521.3012.24.camel@localhost.localdomain> On Thu, 2009-07-16 at 15:44 -0400, William Cohen wrote: > I was looking through the oprofile rpms included in the Fedora yum repos for > ppc64 and x86_64. Oprofile 0.9.4 has support for java profiling that uses shared > libraries. These shared libraries are packaged in the oprofile-jit rpm. 64-bit > platforms such as ppc64 and x86_64 can run 32-bit versions of java. Thus, the > 32-bit versions of the oprofile-jit rpm need to be included in the repositories. > How does one get those rpms added to the rpms? They have to get picked up by the multilib algorithm that mash runs, or they have to be hardcoded into being picked up (or the algorithm has to be expanded to pick up other packages for this reason). Best to file a ticket with rel-eng trac to get this worked out. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From awilliam at redhat.com Thu Jul 16 23:16:59 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 16 Jul 2009 16:16:59 -0700 Subject: koji build dependencies in cloud computing project? In-Reply-To: <4A5FABEA.9060008@redhat.com> References: <4A5F947D.4090707@pobox.com> <200907161612.36734.dennis@ausil.us> <20090716163646.55d8c491@redhat.com> <4A5FABEA.9060008@redhat.com> Message-ID: <1247786219.13021.22.camel@adam.local.net> On Thu, 2009-07-16 at 18:38 -0400, Tom "spot" Callaway wrote: > On 07/16/2009 06:36 PM, Pete Zaitcev wrote: > > On Thu, 16 Jul 2009 16:12:30 -0500, Dennis Gilmore wrote: > >> On Thursday 16 July 2009 03:58:37 pm Jeff Garzik wrote: > > > >>> cld and chunkd built just fine in koji, but tabled does not: it > >>> BuildRequires both cld and chunkd. > > > >> Its not possible you can only build against what is released in fedora > > > > Do I understand it right that CLD has to get into Rawhide first, then? > > And once it's established there, chunk and tabled can move in? > > You can't do chained scratch builds like Jeff wanted to do. So, if > Package Foo BuildRequires packages Bar and Baz, Bar and Baz need to be > in Fedora and built for the target. Then, you can do a scratch build of Foo. Or you can use mock to give you a clean shell, and do your scratch builds inside it manually. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From jgarzik at pobox.com Thu Jul 16 23:45:32 2009 From: jgarzik at pobox.com (Jeff Garzik) Date: Thu, 16 Jul 2009 19:45:32 -0400 Subject: koji build dependencies in cloud computing project? In-Reply-To: <20090716163646.55d8c491@redhat.com> References: <4A5F947D.4090707@pobox.com> <200907161612.36734.dennis@ausil.us> <20090716163646.55d8c491@redhat.com> Message-ID: <4A5FBB9C.4040800@pobox.com> Pete Zaitcev wrote: > On Thu, 16 Jul 2009 16:12:30 -0500, Dennis Gilmore wrote: >> On Thursday 16 July 2009 03:58:37 pm Jeff Garzik wrote: > >>> cld and chunkd built just fine in koji, but tabled does not: it >>> BuildRequires both cld and chunkd. > >> Its not possible you can only build against what is released in fedora > > Do I understand it right that CLD has to get into Rawhide first, then? > And once it's established there, chunk and tabled can move in? Until you submit your next batch of chunkd work upstream, both cld and chunkd are independent of any other dependencies... :) tabled can move in after those two, it appears. Jeff From jussilehtola at fedoraproject.org Thu Jul 16 23:47:30 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Fri, 17 Jul 2009 02:47:30 +0300 Subject: koji build dependencies in cloud computing project? In-Reply-To: <1247786219.13021.22.camel@adam.local.net> References: <4A5F947D.4090707@pobox.com> <200907161612.36734.dennis@ausil.us> <20090716163646.55d8c491@redhat.com> <4A5FABEA.9060008@redhat.com> <1247786219.13021.22.camel@adam.local.net> Message-ID: <1247788050.21955.1.camel@hawking.theorphys.helsinki.fi> On Thu, 2009-07-16 at 16:16 -0700, Adam Williamson wrote: > > You can't do chained scratch builds like Jeff wanted to do. So, if > > Package Foo BuildRequires packages Bar and Baz, Bar and Baz need to be > > in Fedora and built for the target. Then, you can do a scratch build of Foo. > > Or you can use mock to give you a clean shell, and do your scratch > builds inside it manually. Or build the BR:s with mock and make a local repo and add it to the mock config. Then you can build the package normally. ... and, as said before, you can build it in Fedora once the requirements have been approved and built. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From jonstanley at gmail.com Thu Jul 16 23:53:00 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 16 Jul 2009 19:53:00 -0400 Subject: Plan for tomorrow's (20090717) FESCo meeting, version 2.0 Message-ID: It slices, it dices, it's the new improved FESCo agenda! Coming soon to an IRC channel near you, the following topics are sure to entertain! 190 application for packaging sponsor - ianweller 189 Consideration for provenpackager - jsteffan 192 provenpackager self-nomination: oget 175 Exception to link against bundled copy of crypsetup in volume_key 201 Drop features for F12 that have not been updated 186 Yum langpack plugin - https://fedoraproject.org/wiki/Features/YumLangpackPlugin 191 Proposal: Classifying the Audio&Video/Multimedia desktop menu 193 Anaconda MDRaid - https://fedoraproject.org/wiki/Anaconda/Features/MDRaid 194 ABRT F12 - https://fedoraproject.org/wiki/Features/ABRTF12 195 Gnome 2.28 - https://fedoraproject.org/wiki/Features/Gnome2.28 196 KVM NIC Hotplug - https://fedoraproject.org/wiki/Features/KVM_NIC_Hotplug 197 noarch subpackages - https://fedoraproject.org/wiki/Features/NoarchSubpackages 198 Rebootless Installer - https://fedoraproject.org/wiki/Features/RebootlessInstaller 199 SR-IOV - https://fedoraproject.org/wiki/Features/SR-IOV 200 libguestfs - https://fedoraproject.org/wiki/Features/libguestfs 202 KVM Stable Guest ABI - https://fedoraproject.org/wiki/Features/KVM_Stable_Guest_ABI 203 KVM qcow2 performance - https://fedoraproject.org/wiki/Features/KVM_qcow2_Performance 204 NFSv4 default - https://fedoraproject.org/wiki/Features/NFSv4Default 205 NetBeans 6.7 - https://fedoraproject.org/wiki/Features/NetBeans_6.7 206 Network Interface Management - https://fedoraproject.org/wiki/Features/Network_Interface_Management 207 PK Browser Plugin - https://fedoraproject.org/wiki/Features/PackageKitBrowserPlugin 208 PK Command not found - https://fedoraproject.org/wiki/Features/PackageKitCommandNotFound If you want something else discussed, don't bother, we won't get through these! :D From limb at jcomserv.net Fri Jul 17 00:25:36 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 16 Jul 2009 19:25:36 -0500 Subject: Proposal to Drop Fedora 12 Features In-Reply-To: References: <4A5F8969.4070206@redhat.com> Message-ID: <4e03af3108c02a3b7ca3b9486da3f22e.squirrel@secure.jcomserv.net> > On Thu, Jul 16, 2009 at 10:11 PM, John Poelstra > wrote: >> Hi FESCo, > >> https://fedoraproject.org/wiki/Features/XZRpmPayloads >> https://fedoraproject.org/wiki/Features/F12X86Support > > Afaik those are blocking on > 1) xz review request > 2) rel-eng to coordinate a mass rebuild Has anyone taken concrete steps for a i586 secondary arch yet? > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- in your fear, speak only peace in your fear, seek only love -d. bowie -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis at ausil.us Fri Jul 17 00:42:16 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 16 Jul 2009 19:42:16 -0500 Subject: Proposal to Drop Fedora 12 Features In-Reply-To: <4e03af3108c02a3b7ca3b9486da3f22e.squirrel@secure.jcomserv.net> References: <4A5F8969.4070206@redhat.com> <4e03af3108c02a3b7ca3b9486da3f22e.squirrel@secure.jcomserv.net> Message-ID: <200907161942.21629.dennis@ausil.us> On Thursday 16 July 2009 07:25:36 pm Jon Ciesla wrote: > > On Thu, Jul 16, 2009 at 10:11 PM, John > > Poelstra > > > wrote: > >> Hi > > FESCo, > > > https://fedoraproject.org/wiki/Features/XZRpmPayloads > > https://fedoraproject.org/wiki/Features/F12X86Support > > > Afaik those are blocking on > > > 1) xz review request > > 2) > > rel-eng to coordinate a mass rebuild > > Has anyone taken concrete > steps for a i586 secondary arch yet? no one has come to me with anything at all yet. 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 Fri Jul 17 01:01:32 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 16 Jul 2009 20:01:32 -0500 Subject: Proposal to Drop Fedora 12 Features In-Reply-To: (drago's message of "Thu\, 16 Jul 2009 22\:35\:49 +0200") References: <4A5F8969.4070206@redhat.com> Message-ID: >>>>> "d" == drago01 writes: d> Afaik those are blocking on xz review request rel-eng to coordinate d> a mass rebuild The xz review had stalled; notting asked me to step in but somehow it slipped my mind for a day. I just went ahead and took it over; there are a couple of things to look at but it should all be wrapped up tomorrow if notting's around. - J< From arjan at infradead.org Fri Jul 17 04:49:56 2009 From: arjan at infradead.org (Arjan van de Ven) Date: Thu, 16 Jul 2009 21:49:56 -0700 Subject: ASPM enabled by default - mild potential for breakage In-Reply-To: <20090716212857.GA23301@srcf.ucam.org> References: <20090716212857.GA23301@srcf.ucam.org> Message-ID: <20090716214956.0811c8e5@infradead.org> On Thu, 16 Jul 2009 22:28:57 +0100 Matthew Garrett wrote: > I've just flicked ASPM (Active State Power Management - runtime power > saving on PCIe hardware) on by default, and it'll be that way in the > next rawhide kernel build. There's the potential for some buggy > hardware to be upset by this. If your system no longer boots or some > hardware doesn't work, try booting with the > are you sure you want to do this? the bios is supposed to set this up already... ... except on chipsets where there's known hw issues (first generations) .... (including ICH7's etc) so enabling it by force is maybe not always a good idea. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org From mjg at redhat.com Fri Jul 17 05:01:37 2009 From: mjg at redhat.com (Matthew Garrett) Date: Fri, 17 Jul 2009 06:01:37 +0100 Subject: ASPM enabled by default - mild potential for breakage In-Reply-To: <20090716214956.0811c8e5@infradead.org> References: <20090716212857.GA23301@srcf.ucam.org> <20090716214956.0811c8e5@infradead.org> Message-ID: <20090717050137.GA29657@srcf.ucam.org> On Thu, Jul 16, 2009 at 09:49:56PM -0700, Arjan van de Ven wrote: > On Thu, 16 Jul 2009 22:28:57 +0100 > Matthew Garrett wrote: > > > I've just flicked ASPM (Active State Power Management - runtime power > > saving on PCIe hardware) on by default, and it'll be that way in the > > next rawhide kernel build. There's the potential for some buggy > > hardware to be upset by this. If your system no longer boots or some > > hardware doesn't work, try booting with the > > > > are you sure you want to do this? > the bios is supposed to set this up already... "supposed to"? Spec doesn't require it. If the BIOS flags it as being unsupported then we won't enable it. > ... except on chipsets where there's known hw issues (first > generations) .... (including ICH7's etc) > > so enabling it by force is maybe not always a good idea. We're using the same heuristics as Microsoft here - don't use it if the FADT asks us not to, and don't use it if the endpoint or bridge are PCIe 1.0. I don't expect this to cause problems, but if it does there's plenty of time to revert it. -- Matthew Garrett | mjg59 at srcf.ucam.org From jarod at redhat.com Fri Jul 17 13:57:30 2009 From: jarod at redhat.com (Jarod Wilson) Date: Fri, 17 Jul 2009 09:57:30 -0400 Subject: Proposal to Drop Fedora 12 Features In-Reply-To: <4e03af3108c02a3b7ca3b9486da3f22e.squirrel@secure.jcomserv.net> References: <4A5F8969.4070206@redhat.com> <4e03af3108c02a3b7ca3b9486da3f22e.squirrel@secure.jcomserv.net> Message-ID: <200907170957.31235.jarod@redhat.com> On Thursday 16 July 2009 20:25:36 Jon Ciesla wrote: > > > On Thu, Jul 16, 2009 at 10:11 PM, John > Poelstra > > wrote: > >> Hi > FESCo, > > > >> > https://fedoraproject.org/wiki/Features/XZRpmPayloads > >> > https://fedoraproject.org/wiki/Features/F12X86Support > > > > > Afaik those are blocking on > > 1) xz review request > > 2) > rel-eng to coordinate a mass rebuild > > Has anyone taken concrete > steps for a i586 secondary arch yet? For the most part, its not (yet) necessary. We throttled back the definition of i686 from "i686 + cmov + sse2" or some such to just "i686 + cmov", so there are very few systems that would be served by an i586 secondary arch right now. i.e., Athlon XP, Pentium III, etc., which *would* have been relegated to i586, are still going to be supported by i686, and we've talked about adding a cmov trap-and-emu function to keep supporting the few i686 procs w/o cmov, which really leaves only the original Pentium series that would benefit from an i586 secondary arch. At least, that's my vague recollection of it all right now... :) -- Jarod Wilson jarod at redhat.com From notting at redhat.com Fri Jul 17 14:00:42 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 17 Jul 2009 10:00:42 -0400 Subject: Proposal to Drop Fedora 12 Features In-Reply-To: <4A5F8969.4070206@redhat.com> References: <4A5F8969.4070206@redhat.com> Message-ID: <20090717140042.GC8346@nostromo.devel.redhat.com> John Poelstra (poelstra at redhat.com) said: > https://fedoraproject.org/wiki/Features/XZRpmPayloads > https://fedoraproject.org/wiki/Features/F12X86Support Both updated now. Apologies for the dlay. Bill From limb at jcomserv.net Fri Jul 17 14:04:19 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 17 Jul 2009 09:04:19 -0500 Subject: Proposal to Drop Fedora 12 Features In-Reply-To: <200907170957.31235.jarod@redhat.com> References: <4A5F8969.4070206@redhat.com> <4e03af3108c02a3b7ca3b9486da3f22e.squirrel@secure.jcomserv.net> <200907170957.31235.jarod@redhat.com> Message-ID: <4A6084E3.2090006@jcomserv.net> Jarod Wilson wrote: > On Thursday 16 July 2009 20:25:36 Jon Ciesla wrote: > >>> On Thu, Jul 16, 2009 at 10:11 PM, John >>> >> Poelstra >> >>> wrote: >>> >>>> Hi >>>> >> FESCo, >> >> https://fedoraproject.org/wiki/Features/XZRpmPayloads >> >> https://fedoraproject.org/wiki/Features/F12X86Support >> >>> >> Afaik those are blocking on >> >>> 1) xz review request >>> 2) >>> >> rel-eng to coordinate a mass rebuild >> >> Has anyone taken concrete >> steps for a i586 secondary arch yet? >> > > For the most part, its not (yet) necessary. We throttled back the > definition of i686 from "i686 + cmov + sse2" or some such to just > "i686 + cmov", so there are very few systems that would be served by > an i586 secondary arch right now. i.e., Athlon XP, Pentium III, etc., > which *would* have been relegated to i586, are still going to be > supported by i686, and we've talked about adding a cmov trap-and-emu > function to keep supporting the few i686 procs w/o cmov, which really > leaves only the original Pentium series that would benefit from an > i586 secondary arch. At least, that's my vague recollection of it all > right now... :) > > If this is the case, which is what I was hoping I remembered, then I agree with you that we don't *really* need it. Bill, can you clarify the sse2 or no sse2 distinction, and possibly on the wiki page as well, since it was such a large thread? :) It's a shame to end old hardware support, as it's always been one of my favourite things about Linux in general, but if I ever have any of that sort of hardware, I can make do. . . -- in your fear, speak only peace in your fear, seek only love -d. bowie From sundaram at fedoraproject.org Fri Jul 17 14:08:00 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 17 Jul 2009 19:38:00 +0530 Subject: Plan for tomorrow's (20090717) FESCo meeting, version 2.0 In-Reply-To: References: Message-ID: <4A6085C0.7080505@fedoraproject.org> On 07/17/2009 05:23 AM, Jon Stanley wrote: > 194 ABRT F12 - https://fedoraproject.org/wiki/Features/ABRTF12 Last time, this one was approved, it wasn't in a usable state by default and was never dropped. I hope we get it right, this time. > 207 PK Browser Plugin - > https://fedoraproject.org/wiki/Features/PackageKitBrowserPlugin Unless we are a building a web interface in Fedora infrastructure like the amber project, I am not sure this is a feature worth advertising. > 208 PK Command not found - > https://fedoraproject.org/wiki/Features/PackageKitCommandNotFound Unusable at the moment. Install it in Fedora 11. Type a single letter, let's say "s" and after 5 mins, I am still waiting for it to return anything. Rahul From wcohen at redhat.com Fri Jul 17 14:34:03 2009 From: wcohen at redhat.com (William Cohen) Date: Fri, 17 Jul 2009 10:34:03 -0400 Subject: Adding 32-bit packages to ppc64 and x86_64 composes and yum repos In-Reply-To: <1247785521.3012.24.camel@localhost.localdomain> References: <4A5F8321.6090701@redhat.com> <1247785521.3012.24.camel@localhost.localdomain> Message-ID: <4A608BDB.9070401@redhat.com> Jesse Keating wrote: > On Thu, 2009-07-16 at 15:44 -0400, William Cohen wrote: >> I was looking through the oprofile rpms included in the Fedora yum repos for >> ppc64 and x86_64. Oprofile 0.9.4 has support for java profiling that uses shared >> libraries. These shared libraries are packaged in the oprofile-jit rpm. 64-bit >> platforms such as ppc64 and x86_64 can run 32-bit versions of java. Thus, the >> 32-bit versions of the oprofile-jit rpm need to be included in the repositories. >> How does one get those rpms added to the rpms? > > They have to get picked up by the multilib algorithm that mash runs, or > they have to be hardcoded into being picked up (or the algorithm has to > be expanded to pick up other packages for this reason). > > Best to file a ticket with rel-eng trac to get this worked out. > > Hi Jesse, Thanks, filed a rel-eng trac ticket for this: https://fedorahosted.org/rel-eng/ticket/2002 -Will From harald at redhat.com Fri Jul 17 14:36:17 2009 From: harald at redhat.com (Harald Hoyer) Date: Fri, 17 Jul 2009 16:36:17 +0200 Subject: [ANNOUNCEMENT] dracut-0.5 Message-ID: <4A608C61.9060501@redhat.com> Information: https://fedoraproject.org/wiki/Dracut Download: F-11: http://koji.fedoraproject.org/koji/buildinfo?buildID=114853 Rawhide: http://koji.fedoraproject.org/koji/buildinfo?buildID=114854 or if the mirrors have synced: # yum update dracut Bugs can be filed in bugzilla: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=dracut Debugging ========= Create your image with the debug module: # dracut -a debug /boot/test-$(uname -r) $(uname -r) Add "rdshell" to the kernel command line, remove "rhgb" and "quiet" and boot the image. Once you are dropped to a shell do: # dmesg|grep dracut Add the output and your kernel command line to the bug report. see also: https://fedoraproject.org/wiki/Dracut/Debugging What's new in dracut-0.5: ========================= - more generic (all plymouth modules, all keyboards, all console fonts) - more kernel command line parameters (see also man dracut(8)) - a helper tool, which generates the kernel command line (dracut-gencmdline) for my machine this looks like this: # /sbin/dracut-gencmdline rd_DM_UUID=nvidia_dddhfead rd_LUKS_UUID=luks-227fe0ce-7e8c-453a-823f-d5bf34ca1da3 rd_LVM_VG=VolGroup00 KEYBOARDTYPE=pc KEYTABLE=de-latin1 SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 If you have encrypted partitions you should at least set "KEYTABLE" to have the correct keyboard setting. rd_DM_UUID, rd_LUKS_UUID, rd_MD_UUID help you, if dracut does more than you want in its automatic mode. So if you want to be more specific on what dracut is allowed to assemble, uncrypt etc. just specify the exact parameters. For those with an Intel fake software raid onboard (imsm/isw), you might not want MD handle those, but fallback to the old behaviour with DM. To do so add rd_NO_MDIMSM to the kernel command line. New kernel command line parameters: I18N e.g. LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=de-latin1-nodeadkeys KEYBOARDTYPE=sun|pc will be written to /etc/sysconfig/keyboard in the initramfs KEYTABLE= will be written to /etc/sysconfig/keyboard in the initramfs SYSFONT= Console font will be written to /etc/sysconfig/i18n in the initramfs SYSFONTACM= Unicode font map will be written to /etc/sysconfig/i18n in the initramfs UNIMAP= Unicode font map will be written to /etc/sysconfig/i18n in the initramfs LANG= will be written to /etc/sysconfig/i18n in the initramfs Bootsplash - plymouth rd_plytheme= specify the plymouth bootsplash theme (fallback is text) LVM rd_NO_LVM disable LVM detection rd_LVM_VG= only activate the volume groups with the given name crypto LUKS rd_NO_LUKS disable crypto LUKS detection rd_LUKS_UUID= only activate the LUKS partitions with the given UUID MD rd_NO_MD disable MD RAID detection rd_NO_MDIMSM no MD RAID for imsm/isw raids, use dmraid instead rd_MD_UUID= only activate the raid sets with the given UUID DMRAID rd_NO_DM disable DM RAID detection rd_DM_UUID= only activate the raid sets with the given UUID From mike at cchtml.com Fri Jul 17 15:42:56 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Fri, 17 Jul 2009 10:42:56 -0500 Subject: Does anything require /proc/bus/usb? Message-ID: <4A609C00.2080801@cchtml.com> If not, should it be phased out? I'm referencing a use case with VirtualBox that looks for /proc/bus/usb by default and will use that instead of libusb for USB device access. This has caused issues for people wishing to use VirtualBox on Fedora in that they cannot use USB devices without a little tinkering. They either have to remove the /proc/bus/usb mount from rc.sysinit or adjust their fstab to allow other users access. I'll even go as far as providing a patch! *gasp* Most of you probably don't care about VirtualBox and would rather us use libvirt, but some folks use different software. Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: rm-proc-usb.patch Type: text/x-patch Size: 665 bytes Desc: not available URL: From notting at redhat.com Fri Jul 17 15:45:59 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 17 Jul 2009 11:45:59 -0400 Subject: Proposal to Drop Fedora 12 Features In-Reply-To: <4A6084E3.2090006@jcomserv.net> References: <4A5F8969.4070206@redhat.com> <4e03af3108c02a3b7ca3b9486da3f22e.squirrel@secure.jcomserv.net> <200907170957.31235.jarod@redhat.com> <4A6084E3.2090006@jcomserv.net> Message-ID: <20090717154559.GM8346@nostromo.devel.redhat.com> Jon Ciesla (limb at jcomserv.net) said: > If this is the case, which is what I was hoping I remembered, then I > agree with you that we don't *really* need it. Bill, can you clarify > the sse2 or no sse2 distinction, and possibly on the wiki page as well, > since it was such a large thread? :) It doesn't require sse2. Emulating CMOV requires someone to merge that patch, which wasn't a committed part of the feature and no one has done that yet, AFAIK. Bill From thomasj at fedoraproject.org Fri Jul 17 15:56:02 2009 From: thomasj at fedoraproject.org (Thomas Janssen) Date: Fri, 17 Jul 2009 15:56:02 +0000 Subject: Does anything require /proc/bus/usb? In-Reply-To: <4A609C00.2080801@cchtml.com> References: <4A609C00.2080801@cchtml.com> Message-ID: 2009/7/17 Michael Cronenworth : > If not, should it be phased out? > > I'm referencing a use case with VirtualBox that looks for /proc/bus/usb > by default and will use that instead of libusb for USB device access. > This has caused issues for people wishing to use VirtualBox on Fedora in > that they cannot use USB devices without a little tinkering. They either > have to remove the /proc/bus/usb mount from rc.sysinit or adjust their > fstab to allow other users access. > > I'll even go as far as providing a patch! *gasp* Patch would be welcome. Would make my life easier in #fedora helping people with that problem. > Most of you probably don't care about VirtualBox and would rather us use > libvirt, but some folks use different software. A lot. -- LG Thomas Dubium sapientiae initium From mike at cchtml.com Fri Jul 17 15:58:30 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Fri, 17 Jul 2009 10:58:30 -0500 Subject: Does anything require /proc/bus/usb? In-Reply-To: References: <4A609C00.2080801@cchtml.com> Message-ID: <4A609FA6.7040908@cchtml.com> Thomas Janssen on 07/17/2009 10:56 AM wrote: > > Patch would be welcome. Would make my life easier in #fedora helping > people with that problem. > The patch should have been attached to the original post. Did you see it? From sundaram at fedoraproject.org Fri Jul 17 15:56:58 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 17 Jul 2009 21:26:58 +0530 Subject: Packages tracked by FEver that need to be updated In-Reply-To: <200907161952.47891.opensource@till.name> References: <200907102243.14776.opensource@till.name> <200907161952.47891.opensource@till.name> Message-ID: <4A609F4A.2000701@fedoraproject.org> On 07/16/2009 11:22 PM, Till Maas wrote: > On Saturday 11 July 2009 13:29:59 Rakesh Pandit wrote: > >> Thanks for nice work. I too mailed other some time back .. but did not >> recieved any mail back. May you share the program ;) > > My current code is available at > http://fedorapeople.org/gitweb?p=till/public_git/cnucnu.git;a=summary > > But don't be disappointed, because it does not yet do very much. It would be useful to have a dynamically generated webpage that shows how close we are to upstream versions across different Fedora versions similar to the distrowatch packages page. Maybe allow package maintainers to add in comments indicating what their plans are, even. For example, if a update is going to break the ABI in a intrusive way (let's say XULRunner) or change the configuration file format (nagios), I as a package maintainer would like to convey that information to my users so they know why I haven't pushed an update despite new features or even minor bug fixes. Rahul From sundaram at fedoraproject.org Fri Jul 17 15:59:19 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 17 Jul 2009 21:29:19 +0530 Subject: Does anything require /proc/bus/usb? In-Reply-To: <4A609C00.2080801@cchtml.com> References: <4A609C00.2080801@cchtml.com> Message-ID: <4A609FD7.2000403@fedoraproject.org> On 07/17/2009 09:12 PM, Michael Cronenworth wrote: > If not, should it be phased out? > > I'm referencing a use case with VirtualBox that looks for /proc/bus/usb > by default and will use that instead of libusb for USB device access. > This has caused issues for people wishing to use VirtualBox on Fedora in > that they cannot use USB devices without a little tinkering. They either > have to remove the /proc/bus/usb mount from rc.sysinit or adjust their > fstab to allow other users access. > > I'll even go as far as providing a patch! *gasp* > > Most of you probably don't care about VirtualBox and would rather us use > libvirt, but some folks use different software. Libvirt of course is a library. Even VirtualBox could be using it. Rahul From berrange at redhat.com Fri Jul 17 16:10:44 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 17 Jul 2009 17:10:44 +0100 Subject: Does anything require /proc/bus/usb? In-Reply-To: <4A609C00.2080801@cchtml.com> References: <4A609C00.2080801@cchtml.com> Message-ID: <20090717161043.GB22591@redhat.com> On Fri, Jul 17, 2009 at 10:42:56AM -0500, Michael Cronenworth wrote: > If not, should it be phased out? > > I'm referencing a use case with VirtualBox that looks for /proc/bus/usb > by default and will use that instead of libusb for USB device access. > This has caused issues for people wishing to use VirtualBox on Fedora in > that they cannot use USB devices without a little tinkering. They either > have to remove the /proc/bus/usb mount from rc.sysinit or adjust their > fstab to allow other users access. Why not do a patch for VirtualBox to make it look in the right place first ? We've just done that for QEMU too, changing its search order to be /sys/bus/usb, /dev/bus/usb and only then /proc/bus/usb. Removing the whole /proc/bus/usb mount to solve one application's problem does not seem ideal. > I'll even go as far as providing a patch! *gasp* > > Most of you probably don't care about VirtualBox and would rather us use > libvirt, but some folks use different software. FYI the distinction VirtualBox vs libvirt isn't correct. libvirt is an API for any virtualization technology, and has drivers for Xen, KVM, QEMU, VirtualBox and more. 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 sundaram at fedoraproject.org Fri Jul 17 16:13:32 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 17 Jul 2009 21:43:32 +0530 Subject: Heads UP - PHP 5.3.0 in rawhide with new ABI/API. In-Reply-To: <4A5A2017.3090409@FamilleCollet.com> References: <4A5A2017.3090409@FamilleCollet.com> Message-ID: <4A60A32C.3030901@fedoraproject.org> On 07/12/2009 11:10 PM, Remi Collet wrote: > Hi, > > PHP 5.3.0 freshly build in Rawhide. Thanks for all your work. Added a note to https://fedoraproject.org/wiki/Fedora_12_Alpha_release_notes#PHP_5.3 Rahul From awilliam at redhat.com Fri Jul 17 16:16:12 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 17 Jul 2009 09:16:12 -0700 Subject: Does anything require /proc/bus/usb? In-Reply-To: <20090717161043.GB22591@redhat.com> References: <4A609C00.2080801@cchtml.com> <20090717161043.GB22591@redhat.com> Message-ID: <1247847372.6035.0.camel@adam.local.net> On Fri, 2009-07-17 at 17:10 +0100, Daniel P. Berrange wrote: > On Fri, Jul 17, 2009 at 10:42:56AM -0500, Michael Cronenworth wrote: > > If not, should it be phased out? > > > > I'm referencing a use case with VirtualBox that looks for /proc/bus/usb > > by default and will use that instead of libusb for USB device access. > > This has caused issues for people wishing to use VirtualBox on Fedora in > > that they cannot use USB devices without a little tinkering. They either > > have to remove the /proc/bus/usb mount from rc.sysinit or adjust their > > fstab to allow other users access. > > Why not do a patch for VirtualBox to make it look in the right place > first ? Because we don't package VirtualBox, because it requires not-in-tree kernel modules. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From mike at cchtml.com Fri Jul 17 16:20:56 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Fri, 17 Jul 2009 11:20:56 -0500 Subject: Does anything require /proc/bus/usb? In-Reply-To: <20090717161043.GB22591@redhat.com> References: <4A609C00.2080801@cchtml.com> <20090717161043.GB22591@redhat.com> Message-ID: <4A60A4E8.6060006@cchtml.com> Daniel P. Berrange on 07/17/2009 11:10 AM wrote: > > Why not do a patch for VirtualBox to make it look in the right place > first ? We've just done that for QEMU too, changing its search order > to be /sys/bus/usb, /dev/bus/usb and only then /proc/bus/usb. Removing > the whole /proc/bus/usb mount to solve one application's problem does > not seem ideal. > The VirtualBox developers state: "/proc/bus/usb is deprecated, and most people have already got rid of it. If VBox finds it mounted, it uses legacy code to handle USB. We do this to avoid breaking existing working setups. Otherwise we use newer, alternative code." > > FYI the distinction VirtualBox vs libvirt isn't correct. libvirt is > an API for any virtualization technology, and has drivers for Xen, > KVM, QEMU, VirtualBox and more. > My analogy was poor, yes, as most Internet comments are, but my point was being VB vs what libvirt provides, not what libvirt is (a library). From berrange at redhat.com Fri Jul 17 16:21:26 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 17 Jul 2009 17:21:26 +0100 Subject: Does anything require /proc/bus/usb? In-Reply-To: <1247847372.6035.0.camel@adam.local.net> References: <4A609C00.2080801@cchtml.com> <20090717161043.GB22591@redhat.com> <1247847372.6035.0.camel@adam.local.net> Message-ID: <20090717162126.GC22591@redhat.com> On Fri, Jul 17, 2009 at 09:16:12AM -0700, Adam Williamson wrote: > On Fri, 2009-07-17 at 17:10 +0100, Daniel P. Berrange wrote: > > On Fri, Jul 17, 2009 at 10:42:56AM -0500, Michael Cronenworth wrote: > > > If not, should it be phased out? > > > > > > I'm referencing a use case with VirtualBox that looks for /proc/bus/usb > > > by default and will use that instead of libusb for USB device access. > > > This has caused issues for people wishing to use VirtualBox on Fedora in > > > that they cannot use USB devices without a little tinkering. They either > > > have to remove the /proc/bus/usb mount from rc.sysinit or adjust their > > > fstab to allow other users access. > > > > Why not do a patch for VirtualBox to make it look in the right place > > first ? > > Because we don't package VirtualBox, because it requires not-in-tree > kernel modules. I know that, but that doesn't prevent motivated people sending a patch to rpmfusion, or virtualbox upstream to solve this problem. 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 mike at cchtml.com Fri Jul 17 16:23:21 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Fri, 17 Jul 2009 11:23:21 -0500 Subject: Does anything require /proc/bus/usb? In-Reply-To: <20090717161043.GB22591@redhat.com> References: <4A609C00.2080801@cchtml.com> <20090717161043.GB22591@redhat.com> Message-ID: <4A60A579.1070209@cchtml.com> Daniel P. Berrange on 07/17/2009 11:10 AM wrote: > > Why not do a patch for VirtualBox to make it look in the right place > first ? We've just done that for QEMU too, changing its search order > to be /sys/bus/usb, /dev/bus/usb and only then /proc/bus/usb. Removing > the whole /proc/bus/usb mount to solve one application's problem does > not seem ideal. > Furthermore, my original question still stands: Does anything require usbfs? You did not answer my original question. From notting at redhat.com Fri Jul 17 16:30:48 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 17 Jul 2009 12:30:48 -0400 Subject: Does anything require /proc/bus/usb? In-Reply-To: <4A60A579.1070209@cchtml.com> References: <4A609C00.2080801@cchtml.com> <20090717161043.GB22591@redhat.com> <4A60A579.1070209@cchtml.com> Message-ID: <20090717163048.GC12095@nostromo.devel.redhat.com> Michael Cronenworth (mike at cchtml.com) said: > Furthermore, my original question still stands: > Does anything require usbfs? > > You did not answer my original question. mkinitrd does; that being said, that's only in the initramfs. Bill From mike at cchtml.com Fri Jul 17 16:32:32 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Fri, 17 Jul 2009 11:32:32 -0500 Subject: Does anything require /proc/bus/usb? In-Reply-To: <20090717163048.GC12095@nostromo.devel.redhat.com> References: <4A609C00.2080801@cchtml.com> <20090717161043.GB22591@redhat.com> <4A60A579.1070209@cchtml.com> <20090717163048.GC12095@nostromo.devel.redhat.com> Message-ID: <4A60A7A0.6060505@cchtml.com> Bill Nottingham on 07/17/2009 11:30 AM wrote: > > mkinitrd does; that being said, that's only in the initramfs. > OK, anything else? If mkinitrd bites the bullet in the new F12 feature then usbfs could be deprecated as well? From limb at jcomserv.net Fri Jul 17 16:45:21 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 17 Jul 2009 11:45:21 -0500 Subject: Proposal to Drop Fedora 12 Features In-Reply-To: <20090717154559.GM8346@nostromo.devel.redhat.com> References: <4A5F8969.4070206@redhat.com> <4e03af3108c02a3b7ca3b9486da3f22e.squirrel@secure.jcomserv.net> <200907170957.31235.jarod@redhat.com> <4A6084E3.2090006@jcomserv.net> <20090717154559.GM8346@nostromo.devel.redhat.com> Message-ID: <4A60AAA1.7060507@jcomserv.net> Bill Nottingham wrote: > Jon Ciesla (limb at jcomserv.net) said: > >> If this is the case, which is what I was hoping I remembered, then I >> agree with you that we don't *really* need it. Bill, can you clarify >> the sse2 or no sse2 distinction, and possibly on the wiki page as well, >> since it was such a large thread? :) >> > > It doesn't require sse2. Emulating CMOV requires someone to merge that > patch, which wasn't a committed part of the feature and no one has done > that yet, AFAIK. > > Bill > > Yay! Thanks. -- in your fear, speak only peace in your fear, seek only love -d. bowie From mclasen at redhat.com Fri Jul 17 16:50:43 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 17 Jul 2009 12:50:43 -0400 Subject: Fit and Finish test day: batteries and suspend Message-ID: <1247849443.1614.8.camel@planemask> Just a reminder: The next 'fit and finish' test day will take place on July 21, which is next Tuesday. We want to look at issues with the user experience around batteries, suspend and power management in general. https://fedoraproject.org/wiki/Test_Day:2009-07-21_Fit_and_Finish:Batteries_and_Suspend Please join us in #fedora-fit-and-finish. Matthias From daryll.strauss at gmail.com Fri Jul 17 16:49:38 2009 From: daryll.strauss at gmail.com (Daryll Strauss) Date: Fri, 17 Jul 2009 09:49:38 -0700 Subject: Does anything require /proc/bus/usb? In-Reply-To: <4A60A7A0.6060505@cchtml.com> References: <4A609C00.2080801@cchtml.com> <20090717161043.GB22591@redhat.com> <4A60A579.1070209@cchtml.com> <20090717163048.GC12095@nostromo.devel.redhat.com> <4A60A7A0.6060505@cchtml.com> Message-ID: <4A60ABA2.9030307@gmail.com> On 07/17/2009 09:32 AM, Michael Cronenworth wrote: > OK, anything else? > > If mkinitrd bites the bullet in the new F12 feature then usbfs could be > deprecated as well? > There's an outside the tree application which breaks when /proc/bus/usb exists so you want to remove /proc/bus/usb from the tree to work around it. How do you know there isn't some other outside the tree application that needs /proc/bus/usb? Asking on this list clearly doesn't prove that nothing else exists. I'd argue you're covering up the symptom not fixing the cause. VirtualBox should fix their code not to use /proc/bus/usb if /sys/bus/usb exists. They can always add a switch to revert to the old behaviour should anyone actually need it. Changing your OS to fix a broken app is always the wrong solution and that mentality is going to detrimental to Linux in general. - |Daryll From mike at cchtml.com Fri Jul 17 16:59:49 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Fri, 17 Jul 2009 11:59:49 -0500 Subject: Does anything require /proc/bus/usb? In-Reply-To: <4A60ABA2.9030307@gmail.com> References: <4A609C00.2080801@cchtml.com> <20090717161043.GB22591@redhat.com> <4A60A579.1070209@cchtml.com> <20090717163048.GC12095@nostromo.devel.redhat.com> <4A60A7A0.6060505@cchtml.com> <4A60ABA2.9030307@gmail.com> Message-ID: <4A60AE05.6080506@cchtml.com> Daryll Strauss on 07/17/2009 11:49 AM wrote: > > Changing your OS to fix a broken app is always the wrong solution and > that mentality is going to detrimental to Linux in general. > You missed the entire point of this thread. Let me say this so that no one else drags this on: I could care less about VirtualBox. If usbfs is globally being deprecated and could be removed, why shouldn't it? Why are you arguing to keep in old cruft? From mike at cchtml.com Fri Jul 17 17:05:43 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Fri, 17 Jul 2009 12:05:43 -0500 Subject: Fit and Finish test day: batteries and suspend In-Reply-To: <1247849443.1614.8.camel@planemask> References: <1247849443.1614.8.camel@planemask> Message-ID: <4A60AF67.8060005@cchtml.com> Matthias Clasen on 07/17/2009 11:50 AM wrote: > Just a reminder: > > The next 'fit and finish' test day will take place on July 21, which is > next Tuesday. We want to look at issues with the user experience around > batteries, suspend and power management in general. > This test day should not be limited to laptops. Even thought the wiki page doesn't state any restrictions, it is implied that this is for laptops. There are some folks that have UPS battery backups that used to function under HAL and F10. Now that DeviceKit has removed all references to UPS devices until they figure out how they want to add them back in, I, and other UPS owners are left without methods of adjusting settings or even using the shutdown feature. I don't want to install httpd and configure config files for apcupsd. If you are going to suggest such, then Fedora has lost touch with reality. From johannbg at hi.is Fri Jul 17 17:12:05 2009 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Fri, 17 Jul 2009 17:12:05 +0000 Subject: [ANNOUNCEMENT] dracut-0.5 In-Reply-To: <4A608C61.9060501@redhat.com> References: <4A608C61.9060501@redhat.com> Message-ID: <4A60B0E5.7030001@hi.is> On 07/17/2009 02:36 PM, Harald Hoyer wrote: > Debugging > ========= The debugging page has been updated with regards to relevant changes. What's the diffrence between rdshell and rdinitdebug -x ? > What's new in dracut-0.5: > ========================= > > # /sbin/dracut-gencmdline Helper command added to the https://fedoraproject.org/wiki/Dracut#Getting_started > > New kernel command line parameters: Added to the https://fedoraproject.org/wiki/Dracut/Options JBG -------------- next part -------------- A non-text attachment was scrubbed... Name: johannbg.vcf Type: text/x-vcard Size: 356 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Fri Jul 17 17:14:56 2009 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 17 Jul 2009 19:14:56 +0200 Subject: Does anything require /proc/bus/usb? In-Reply-To: <4A609C00.2080801@cchtml.com> (Michael Cronenworth's message of "Fri\, 17 Jul 2009 10\:42\:56 -0500") References: <4A609C00.2080801@cchtml.com> Message-ID: <87d47zz0xb.fsf@fc5.bigo.ensc.de> Michael Cronenworth writes: > If not, should it be phased out? Is there some upstream (linux kernel) discussion to remove usbfs? If not, it should stay as-is. I use it regularly because it a) is accessibly by ordinary users b) provides more terse information than 'lsusb -v' c) gives information about used drivers > I'm referencing a use case with VirtualBox that looks for /proc/bus/usb > by default and will use that instead of libusb for USB device access. Why not patch VirtualBox to do it correctly? Enrico From harald at redhat.com Fri Jul 17 17:21:35 2009 From: harald at redhat.com (Harald Hoyer) Date: Fri, 17 Jul 2009 19:21:35 +0200 Subject: [ANNOUNCEMENT] dracut-0.5 In-Reply-To: <4A60B0E5.7030001@hi.is> References: <4A608C61.9060501@redhat.com> <4A60B0E5.7030001@hi.is> Message-ID: <4A60B31F.3080006@redhat.com> Am 17.07.2009 19:12, schrieb "J?hann B. Gu?mundsson": > On 07/17/2009 02:36 PM, Harald Hoyer wrote: >> Debugging >> ========= > > The debugging page has been updated with regards to relevant changes. > > What's the diffrence between rdshell and rdinitdebug -x ? rdshell will drop you to a shell, if no root is found rdinitdebug will run the init in debug mode. > >> What's new in dracut-0.5: >> ========================= >> >> # /sbin/dracut-gencmdline > > Helper command added to the > https://fedoraproject.org/wiki/Dracut#Getting_started > >> New kernel command line parameters: > > Added to the https://fedoraproject.org/wiki/Dracut/Options > > JBG > From mike at cchtml.com Fri Jul 17 17:22:04 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Fri, 17 Jul 2009 12:22:04 -0500 Subject: Does anything require /proc/bus/usb? In-Reply-To: <87d47zz0xb.fsf@fc5.bigo.ensc.de> References: <4A609C00.2080801@cchtml.com> <87d47zz0xb.fsf@fc5.bigo.ensc.de> Message-ID: <4A60B33C.5020206@cchtml.com> Enrico Scholz on 07/17/2009 12:14 PM wrote: > Is there some upstream (linux kernel) discussion to remove usbfs? If > not, it should stay as-is. Fedora/RHEL are the last major distros to retain usbfs support apparently. > > Why not patch VirtualBox to do it correctly? Why not patch your utilities? Again: The issue is not VirtualBox. I provided it as an example and people are running away with it. Stop. From enrico.scholz at informatik.tu-chemnitz.de Fri Jul 17 17:42:09 2009 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 17 Jul 2009 19:42:09 +0200 Subject: Does anything require /proc/bus/usb? In-Reply-To: <4A60B33C.5020206@cchtml.com> (Michael Cronenworth's message of "Fri\, 17 Jul 2009 12\:22\:04 -0500") References: <4A609C00.2080801@cchtml.com> <87d47zz0xb.fsf@fc5.bigo.ensc.de> <4A60B33C.5020206@cchtml.com> Message-ID: <878winyzny.fsf@fc5.bigo.ensc.de> Michael Cronenworth writes: >> Why not patch VirtualBox to do it correctly? > > Why not patch your utilities? You want to change something which is not broken and requests that I adapt my workflow and spent work into something to retain old functionality? > Again: The issue is not VirtualBox. VirtualBox seems to be the issue. Or do you have other examples of software which uses crappy heuristics based upon the existence of /proc/bus/usb? Enrico From mclasen at redhat.com Fri Jul 17 17:42:53 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 17 Jul 2009 13:42:53 -0400 Subject: Fit and Finish test day: batteries and suspend In-Reply-To: <4A60AF67.8060005@cchtml.com> References: <1247849443.1614.8.camel@planemask> <4A60AF67.8060005@cchtml.com> Message-ID: <1247852573.1614.9.camel@planemask> On Fri, 2009-07-17 at 12:05 -0500, Michael Cronenworth wrote: > Matthias Clasen on 07/17/2009 11:50 AM wrote: > > Just a reminder: > > > > The next 'fit and finish' test day will take place on July 21, which is > > next Tuesday. We want to look at issues with the user experience around > > batteries, suspend and power management in general. > > > > This test day should not be limited to laptops. Even thought the wiki > page doesn't state any restrictions, it is implied that this is for laptops. > > There are some folks that have UPS battery backups that used to function > under HAL and F10. Now that DeviceKit has removed all references to UPS > devices until they figure out how they want to add them back in, I, and > other UPS owners are left without methods of adjusting settings or even > using the shutdown feature. I don't want to install httpd and configure > config files for apcupsd. If you are going to suggest such, then Fedora > has lost touch with reality. Do you feel like writing up a use case involving a UPS ? From awilliam at redhat.com Fri Jul 17 18:06:56 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 17 Jul 2009 11:06:56 -0700 Subject: Fit and Finish test day: batteries and suspend In-Reply-To: <4A60AF67.8060005@cchtml.com> References: <1247849443.1614.8.camel@planemask> <4A60AF67.8060005@cchtml.com> Message-ID: <1247854016.6035.6.camel@adam.local.net> On Fri, 2009-07-17 at 12:05 -0500, Michael Cronenworth wrote: > Matthias Clasen on 07/17/2009 11:50 AM wrote: > > Just a reminder: > > > > The next 'fit and finish' test day will take place on July 21, which is > > next Tuesday. We want to look at issues with the user experience around > > batteries, suspend and power management in general. > > > > This test day should not be limited to laptops. Even thought the wiki > page doesn't state any restrictions, it is implied that this is for laptops. > > There are some folks that have UPS battery backups that used to function > under HAL and F10. Now that DeviceKit has removed all references to UPS > devices until they figure out how they want to add them back in, I, and > other UPS owners are left without methods of adjusting settings or even > using the shutdown feature. I don't want to install httpd and configure > config files for apcupsd. If you are going to suggest such, then Fedora > has lost touch with reality. On a practical basis, though, if there's no support in the current code, we can't really _do_ a lot on a Test Day, can we? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From mike at cchtml.com Fri Jul 17 18:37:09 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Fri, 17 Jul 2009 13:37:09 -0500 Subject: Does anything require /proc/bus/usb? In-Reply-To: <878winyzny.fsf@fc5.bigo.ensc.de> References: <4A609C00.2080801@cchtml.com> <87d47zz0xb.fsf@fc5.bigo.ensc.de> <4A60B33C.5020206@cchtml.com> <878winyzny.fsf@fc5.bigo.ensc.de> Message-ID: <4A60C4D5.8050900@cchtml.com> Enrico Scholz on 07/17/2009 12:42 PM wrote: > > You want to change something which is not broken and requests that I adapt > my workflow and spent work into something to retain old functionality? What about old /dev (pre udev)? It was not broken. Sure, you couldn't add nice new functionality quickly, but it wasn't broken. Should we have kept HAL then? Keep using HAL forever? This type of mindset works until there is a better solution. There are better solutions to usbfs today. Most distros use the newer alternative. You ignored my initial comment on this and seem to want to be ignorant of such a fact. > > VirtualBox seems to be the issue. Or do you have other examples of > software which uses crappy heuristics based upon the existence of > /proc/bus/usb? > That particular software does not depend on usbfs, but it seems that VBox will be a scape goat for your whining until I convince you otherwise. If you had read the thread beforehand you probably would not have replied. Please read the whole thread. From mike at cchtml.com Fri Jul 17 18:38:22 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Fri, 17 Jul 2009 13:38:22 -0500 Subject: Fit and Finish test day: batteries and suspend In-Reply-To: <1247852573.1614.9.camel@planemask> References: <1247849443.1614.8.camel@planemask> <4A60AF67.8060005@cchtml.com> <1247852573.1614.9.camel@planemask> Message-ID: <4A60C51E.2050903@cchtml.com> Matthias Clasen on 07/17/2009 12:42 PM wrote: > > Do you feel like writing up a use case involving a UPS ? > As Adam stated in his reply, there is really nothing we can do since UPS devices are not supported at all. I haven't gotten around to bug hunting, but is there a bug for UPS support in DeviceKit? Anything? Thanks, Mike From bochecha at fedoraproject.org Fri Jul 17 18:43:49 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Fri, 17 Jul 2009 20:43:49 +0200 Subject: Fit and Finish test day: batteries and suspend In-Reply-To: <4A60C51E.2050903@cchtml.com> References: <1247849443.1614.8.camel@planemask> <4A60AF67.8060005@cchtml.com> <1247852573.1614.9.camel@planemask> <4A60C51E.2050903@cchtml.com> Message-ID: <2d319b780907171143h72af4328s31bb1b63d8942cc5@mail.gmail.com> >> Do you feel like writing up a use case involving a UPS ? >> > > As Adam stated in his reply, there is really nothing we can do since UPS > devices are not supported at all. > > I haven't gotten around to bug hunting, but is there a bug for UPS > support in DeviceKit? Anything? >From today's update in Fedora 11: $ rpm -q --changelog DeviceKit-power | head * lun. juil. 06 2009 Richard Hughes - 009-1 - Update to 009 - Fixes many problems with multi-battery laptops - Use pm-powersave like HAL used to - Fix detecting UPS devices - Add support for recalled laptop batteries Notice the line about UPS. Now, I have no idea if that means proper support or not, but it seems like it is coming :) ---------- Mathieu Bridon (bochecha) From hun at n-dimensional.de Fri Jul 17 18:47:16 2009 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Fri, 17 Jul 2009 20:47:16 +0200 Subject: New maintainer needed: dumpasn1, freedroid, http_ping, id3v2, pscan, zzuf In-Reply-To: <200907012321.43913.ville.skytta@iki.fi> References: <200907012321.43913.ville.skytta@iki.fi> Message-ID: <20090717204716.3bc0ba93@n-dimensional.de> I have just picked up id3v2, as I use it occasionally. -- Hans Ulrich Niedermann From dmc.fedora at filteredperception.org Fri Jul 17 18:50:32 2009 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 17 Jul 2009 12:50:32 -0600 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A5C3C12.9050009@filteredperception.org> References: <4A5C3C12.9050009@filteredperception.org> Message-ID: <4A60C7F8.1080600@filteredperception.org> Feature rejected. That combined with the potential of unionfs making this rebootless LiveOS installer not work in F13+, leads me to not be able to personally justify engaging in the process required to bring this package into the repos myself. If someone would like to adopt this package, I would be a very responsive upstream. Also, I do think it was lame that people wasted time bringing up criticisms in the fesco meeting, instead of here, or on the feature talk page. Just as much because it seemed to make a long meeting unnecessarily longer, in addition to my preference for having a better forum than IRC to address criticisms. peace... -dmc Douglas McClendon wrote: > Fedorans, > > Can you spare 50 or 100K? If you can spare 100K/700M in the forthcoming > Fedora-12 LiveCD, I can provide you with a rebootless installation > experience. > > http://fedoraproject.org/wiki/Features/RebootlessInstaller > > The short story is that you boot the LiveCD/USB, run the installation, > and then, instead of rebooting into the installed OS, you are already > looking at and using it. > > I just threw together a decent first pass at a feature page, with all > the relevent info, as well as a couple links to youtube videos showing > the complete user experience. Or, if you are the adventurous kind with > an idle test system (obviously with no important unbacked up data), simply > > a) boot an f11-i686 livecd or usb, with an internet connection > b) firefox http://viros.org/rebootless > c) click the i386 rpm link, and submit to packagekit > d) do any partitioning beforehand with fdisk, or whatever gui tool (is > palimpsest really supposed to be able to repartition?) > e) launch the new desktop icon > f) run the installer, simply selecting target root/boot/swap partitions > g) enjoy the coolness that is rebootless installation, and my gratitude > for being one of the first, if not the second tester :) > > I would obviously love to see this in F12 even though it could use quite > a bit of polish. It is fairly important that it go in sooner rather > than later, as when unionfs percolates to fedora, this feature may no > longer be technically possible. In the event the feature were wildly > popular, and sticks around, obviously integration with anaconda would be > next, i.e. simply a checkbox before beginning installation stating > whether you want rebootless instead of traditional. > > In any event, I'd love to hear what people think. I suppose if space is > the issue, it could even be a feature just getting the package into the > fedora repos so that it could be advertised, with users just needing an > internet connection, and not having to see a complaint about lack of > signature on the package. But cmon, can you spare 100K? (50 of that is > ego/logo I can probably part with :) > > peace... > > -dmc > From sundaram at fedoraproject.org Fri Jul 17 18:56:08 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 18 Jul 2009 00:26:08 +0530 Subject: Feature proposal: Rebootless Installer In-Reply-To: <4A60C7F8.1080600@filteredperception.org> References: <4A5C3C12.9050009@filteredperception.org> <4A60C7F8.1080600@filteredperception.org> Message-ID: <4A60C948.7000900@fedoraproject.org> On 07/18/2009 12:20 AM, Douglas McClendon wrote: > Also, I do think it was lame that people wasted time bringing up > criticisms in the fesco meeting, instead of here, or on the feature talk > page. Just as much because it seemed to make a long meeting > unnecessarily longer, in addition to my preference for having a better > forum than IRC to address criticisms. Yes, this has been a common trait for a long time and despite similar comments continue to happen quite often. Unfortunate. Rahul From hughsient at gmail.com Fri Jul 17 19:07:07 2009 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 17 Jul 2009 20:07:07 +0100 Subject: Fit and Finish test day: batteries and suspend In-Reply-To: <2d319b780907171143h72af4328s31bb1b63d8942cc5@mail.gmail.com> References: <1247849443.1614.8.camel@planemask> <4A60AF67.8060005@cchtml.com> <1247852573.1614.9.camel@planemask> <4A60C51E.2050903@cchtml.com> <2d319b780907171143h72af4328s31bb1b63d8942cc5@mail.gmail.com> Message-ID: <15e53e180907171207q7aa8c7eeo7c796030632a172c@mail.gmail.com> 2009/7/17 Mathieu Bridon (bochecha) : > >From today's update in Fedora 11: > $ rpm -q --changelog DeviceKit-power | head > * lun. juil. 06 2009 Richard Hughes - 009-1 > - Update to 009 > - Fixes many problems with multi-battery laptops > - Use pm-powersave like HAL used to > - Fix detecting UPS devices > - Add support for recalled laptop batteries > > Notice the line about UPS. > > Now, I have no idea if that means proper support or not, but it seems > like it is coming :) It should work fine with 009. If it doesn't work, and it used to work with HAL (without nut installed) then please file bugs. I've recently been regression testing with my APC UPS, and this seems to work fine now. Richard. From hughsient at gmail.com Fri Jul 17 19:07:48 2009 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 17 Jul 2009 20:07:48 +0100 Subject: Fit and Finish test day: batteries and suspend In-Reply-To: <8204a4fe0907171035o6cf0c7fei931b02d99ca4b69e@mail.gmail.com> References: <1247849443.1614.8.camel@planemask> <8204a4fe0907171035o6cf0c7fei931b02d99ca4b69e@mail.gmail.com> Message-ID: <15e53e180907171207i1a18a0c6nae19ee3965f564a9@mail.gmail.com> 2009/7/17 Fulko Hew : > (Personally, I have a little 'service' that disables the power management > on my laptop (on F8), but I haven't found where to execute it when the > laptop comes out of 'suspend'?) Check out pm-utils, it allows you do what you want. Richard. From hughsient at gmail.com Fri Jul 17 19:09:29 2009 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 17 Jul 2009 20:09:29 +0100 Subject: Fit and Finish test day: batteries and suspend In-Reply-To: <4A60AF67.8060005@cchtml.com> References: <1247849443.1614.8.camel@planemask> <4A60AF67.8060005@cchtml.com> Message-ID: <15e53e180907171209w4664adb9lf79c94a37229b3b6@mail.gmail.com> 2009/7/17 Michael Cronenworth : > There are some folks that have UPS battery backups that used to function > under HAL and F10. Now that DeviceKit has removed all references to UPS > devices until they figure out how they want to add them back in, There were two bugs that stopped UPS devices being detected correctly. There was nothing removed. > I, and > other UPS owners are left without methods of adjusting settings or even > using the shutdown feature. I don't want to install httpd and configure > config files for apcupsd. If you are going to suggest such, then Fedora > has lost touch with reality. I think you need to test the latest version in updates before speculating. Richard. From jonstanley at gmail.com Fri Jul 17 19:13:53 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Fri, 17 Jul 2009 15:13:53 -0400 Subject: FESco meeting summary for 20090717 Message-ID: Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-17/fedora-meeting.2009-07-17-17.01.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-07-17/fedora-meeting.2009-07-17-17.01.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-17/fedora-meeting.2009-07-17-17.01.log.html ---- 17:01:35 #startmeeting FESCo meeting - 2009-07-17 17:02:07 #chair dgilmore jwb notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler 17:02:16 sorry, phone call 17:02:24 * j-rod here 17:02:25 * sharkcz is here 17:02:25 here 17:02:26 full agenda :) 17:02:30 * Kevin_Kofler is here. 17:02:31 * nirik is present. 17:02:35 * notting is here 17:02:57 alright, without further ado 17:03:11 #topic Sponsor nomination - ianweller 17:03:18 .fesco 190 17:03:29 * jds2001 saw no objections on the list, but little feedback 17:03:40 +1 17:04:15 +1 17:04:15 The request is not very high on specifics. 17:04:30 though the reviews are a little light, he's helped new packagers in numerous ways. 17:04:31 * skvidal is here but may not be in a moment 17:04:36 But whatever, I saw no objections either, so +1 from me. 17:04:56 +1 17:05:13 * j-rod has no strong feeling one way or the other 17:05:14 +1 here. I think it's good he wants to help sponsor people at that POSEE thing perhaps? 17:05:31 yeah, that's pretty much the reason. 17:05:40 and teaching open source is a great thing. 17:05:45 +1 17:05:52 #agreed ianweller sponsor nomination is approved 17:06:06 #topic provenpackager request - jsteffan 17:06:18 .fesco 189 17:06:59 I think it's important that packages with non responsive maintainers get responsive ones... 17:07:06 yeah, me too. 17:07:17 that said, it's sometimes also good to fix them when they are broken in a more timely manner. 17:07:24 As long as somebody fixes them, who cares whether they're officially the maintainers? 17:07:47 well, they dont directly get bug reports, for one. 17:07:49 Kevin_Kofler: because then bugs go unanswered, no one is watching upstream for updates or fixes, or in general being a maintainer. 17:07:49 urgh. phone. need to drop off for a minute 17:08:25 drive by fixes are great if the problem needs fixing, but long term we need maintainers, not a bunch of people driving around tweaking things as they notice them. at least IMHO. 17:08:33 in any case +1 to this request for me. 17:08:50 +1 to the request from me as well. 17:08:54 +1 17:09:00 +1 here too, but get responsive maintainers :) 17:09:11 request comaintainership if you have to. 17:09:16 * nirik was just trying to note that lots of provenpackager requests seem to say 'I want to fix unresponsive packages' which is fine, but we should urge people to get them responsive maintainers also. 17:09:31 yeah, they need good TLC :) 17:09:35 jds2001: The problem is that the nonresponsive or lazy maintainers usually don't react to ACL requests either. 17:09:46 +1 17:09:49 +1 17:10:05 #agreed jsteffan provenpackager request is approved 17:10:14 Kevin_Kofler: yeah. Need to run the non responsive process, but it's sometimes a lot of hassle. ;( 17:10:21 #topic provenpackager request - oget 17:10:29 +1 17:10:33 +1 17:10:34 +1 17:10:43 +1 17:10:48 +1 17:10:49 +1 17:10:57 #agreed oget provenpackager request is approved. 17:11:38 #topic volume_key bundled cryptsetup 17:11:58 so we know a little more than last week 17:12:14 I think with the additional info and the fact that this is going to be temp and upstream knows whats going on, I'd be ok with approving it. 17:12:26 do I take the comments in the ticket to mean the API won't change? 17:12:30 do we know if the new upstream release will be in time for F12? 17:12:42 ticket #? 17:12:50 oops 17:12:51 https://fedorahosted.org/fesco/ticket/175 17:12:55 .fesco 175 17:13:41 so, it implies the api/abi of the 'upstream' version might change 17:14:02 but volume_key will be the only user (internal) of the api from now. 17:14:04 but no ETA 17:14:17 Eh... knowing that mitr and mbroz are working from the same office and that cryptsetup can update in mid-Fedora release despite having API/ABI changes makes the bundling a bit more acceptable. 17:14:34 * nirik nods. 17:14:37 I believe it will be fairly easy to fix volume_key to use the final API if it has to change (and it might not even have to change). 17:14:40 * sharkcz also nods 17:15:21 +1 here 17:15:32 * jds2001 wants to see it gone by f13, though. 17:15:35 +1 17:15:39 I don't like mitr's original reasoning but these later reasons are better. I think we need to track these libraries better but I'll talk to spot about what we could setup. 17:15:39 +1 17:15:40 which i dont think is a problem 17:15:42 yeah, so a reluctant +1 here... but perhaps we should file a followup ticket to make sure it's gone? 17:15:53 +1 from me too (as already said last week). 17:16:02 nirik: we can just leave this one open 17:16:04 reluctant +1 here too 17:16:09 jds2001: I'm not doing it. 17:16:14 For now, we need to make sure there's an open bug against volume_key that is blocking the bundled libraries tracker 17:16:20 f13: :D 17:16:38 f13: I think you need to change your nick now :) 17:16:44 abadger1999: can you file that? or I guess it needs to have cvs done on the new package first? 17:17:00 nirik: what's the problem with leaving this ticket open? 17:17:01 nirik: Right. First the package has to be approved and added to bz. 17:17:16 oh, you mean a bz :) 17:17:19 jds2001: thats ok, as long as we don't forget it's there. 17:17:47 yeah, i take a look at all of em every week to see if any are relevant 17:18:01 anyhow 17:18:21 #agreed volume_key can temporarily bundle a newer cryptsetup 17:18:49 #topic drop F12 features not updated 17:19:09 The list given in the ticket is not up to date. 17:19:14 debuginfofs i suspect was -ENOTIME 17:19:17 XZRpmPayloads and F12X86Support got updated today. 17:19:26 Kevin_Kofler: im well aware of that. 17:19:38 can we do them one at a time please? 17:19:42 yes 17:19:49 * dgilmore is here 17:20:05 And we have some feedback from the owner of SystemtapStaticProbes, he's requesting a small subset of the feature to be approved instead and he's moving the main feature to Fedora 13. 17:20:05 so like i just said, debuginfofs i think was -ENOTIME with the autoqa stuff 17:20:14 yes, debuginfofs is -ENOTIME 17:20:15 wwoods is only one person. 17:20:26 Kevin_Kofler: one at a time 17:20:45 So we're at debuginfofs now? 17:20:45 Multiseat 17:20:51 ok, so move debuginfofs to next release? 17:20:55 we're done with that, dropped. 17:21:32 multiseat next 17:21:41 although we may want to see what's left with debuginfofs - if it's at 85%, maybe it can be helped even in a non-Feature status 17:21:41 Are we sure debuginfofs won't be ready by F12? It's supposedly already 85% done. 17:21:49 ctyler not around? 17:22:04 I think the important question to ask is whether the feature can be done by F12 or not. 17:22:20 It doesn't make sense to drop a feature as a "Feature" when it actually lands anyway. 17:22:28 done by F12 == done in the next two weeks. 17:22:48 actually less 17:22:52 Kevin_Kofler: if it partially lands it may not be worth advertising 17:22:56 jlaska: ping ^^^ 17:23:08 (and/or wwoods) 17:23:08 jds2001: Except for freeze exemptions, slips etc. 17:23:45 I already know jlaska has said elsewhere that there just aren't resources to finish debuginfofs soon enough 17:23:57 Kevin_Kofler: we have never slipped feature freeze to my knowledge. 17:23:57 j-rod: yeah, it's not currently a focus on the QA radar 17:24:36 jds2001: But there are exemptions, and the more the release slips, the more exemptions get requested and granted. 17:24:43 jlaska: so we good with punt-to-fedora-13 on this Feature? 17:24:48 very very few for features 17:25:09 and maybe it gets done by the time F12 is out, and can be used in F12, but we won't market it 'til F13 17:25:19 jds2001: That's kinda the problem, the stuff goes in anyway, it just doesn't get listed as a feature. 17:25:21 yeah, that's fine. 17:25:39 long story short: I'm not proposing debuginfofs for F12, drop it from the list 17:25:39 the PoC implementation is 85% complete but it's 85% of The Wrong Way To Do It 17:26:01 j-rod: yeah ... and notting confirmed w/ wwoods 17:26:02 100% of the wrong way is better than 0% of nothing. 17:26:14 Kevin_Kofler: it can be listed as a feature in the next release when its feature complete 17:26:16 I also don't have time to finish it 17:26:26 working on autoqa / israwhidebroken / etc. 17:26:30 and I don't agree that it's entirely the wrong way -- it's organized enough that chunks can be swapped out for The Right Way piecemeal. 17:26:35 ok, so punt that and next feature? (since we have about a zillion can we move on) 17:26:35 anyhow, we have much to get to, let's not beat a dead horse. 17:26:40 (but yes, "I don't have time" is fair.) 17:26:45 OK, based on the feedback from wwoods and jlaska, I'd say we just punt the debuginfofs feature to F13. 17:26:51 pjones: let's talk about it outside this meeting 17:26:54 wwoods: fair. 17:26:56 done 17:26:59 NEXT! 17:27:15 #agreed debuginfofs is deferred to F13 17:27:32 Multiseat. 17:27:35 Multiseat looks like it's going pretty much nowhere, unfortunately. 17:27:47 * dgilmore thinks punt multiseat 17:27:52 me too. 17:27:53 * nirik nods. 17:27:56 yup 17:27:58 +1, punt. 17:28:00 Best of luck for next release. 17:28:00 +1 17:28:06 i just pinged ctyler, just in case he's got something to add 17:28:13 Last updated more than 5 months ago, 10%, looks pretty dead. 17:28:26 Xi2 just getting merged should make it easier next go 'round 17:28:36 or so I'd think 17:28:39 #agreed multiseat feature is deferred to F13 17:28:56 Systemtap Static probes 17:29:01 owner wants this deferred 17:29:14 another feature page will be needed for the other parrt 17:29:25 ain't gonna force 'em 17:29:29 It's already there: https://fedoraproject.org/wiki/Features/SystemtapTracingRefresh 17:29:30 defer it, next 17:29:41 But we don't have it on the meeting agenda so far. 17:29:46 ok, not in my queue at the moment, probably will be next week. 17:30:03 it's still pending wrangling. 17:30:10 not in the right state to be on my radar. 17:30:15 OK. 17:30:23 We'll have that one next week, hopefully. 17:30:34 #agreed systemtap static probes feature is deferred to F13 17:30:53 XZ RPM payloads 17:31:03 Got updated today, keep. 17:31:09 there's been some movement on this. 17:31:13 yep 17:31:14 * nirik nods. The review shoudl be pretty close to done. 17:31:20 ok, great 17:31:43 #agreed XZ RPM payloads remains an F12 feature 17:31:51 and finally, the F12X86 support 17:31:52 jds2001: with this and the next, there's still a large 'mass rebuild' elephant in the room 17:31:59 we're running out of them for the rebuild. 17:32:01 was blocking on xz, keep 17:32:06 er, time. 17:32:15 That one also got updated today, keep +1. 17:32:41 i think i'm going to do the x86 support bits today, it can start before the mass rebuild and be done piecemeal until we get one 17:32:54 ok, cool 17:33:10 #agreed F12 x86 support remains a feature 17:33:11 NEXT 17:33:29 notting: what changes are we doing? 17:33:30 #topic yum langpack plugin 17:33:42 notting: ill take it offline with you 17:33:42 #topic F12 X86 support changes 17:33:44 dgilmore: see scope on the feature page, can discuss outside of meeting? 17:33:46 ok 17:34:04 #topic yum langpack plugin 17:34:09 alrighty 17:34:17 .fesci 186 17:34:21 .fesco 186 17:34:29 no update, defer again? 17:34:38 worksforme 17:34:46 * notting realizes he's probably part of the update-providing team that fell down on this 17:35:05 #agreed deferred until updates received 17:35:19 #topic Feature - FedoraStudio 17:35:23 .fesco 191 17:35:54 i just conglomerated this filed proposal into the feature. 17:36:33 +1 to the feature 17:36:39 Multimedia / Sound & Video -> Creation -> Jack ?? 17:36:54 +1 to having a *-menus package. i don't think this needs to be in the default menu/spin 17:36:55 I think the question was whether to integrate this into redhat-menus or have a separate package 17:37:06 This one is always tough: one big "Multimedia" or "Sound & Video" menu is crazy, but tons of levels can quickly be annoying too. 17:37:36 notting: But should the optional menu be required by some packages or not? 17:37:42 * dgilmore thinks it might be confusing to some 17:37:58 In other words, should users be allowed/forced to choose between one big menu or many subcategories or should the apps request their subcategories? 17:38:21 I also think that those subcategories are probably too many. 17:38:33 next? 17:38:38 Kevin_Kofler: ... maybe? but i think either the desktop or kde installs, by default, don't install so many things that it would be needed. looking at the menus now, the sound&video is shorter than other ones 17:38:48 nirik: well, it hasn't gotten enough votes one way or another yet :) 17:38:53 notting: Indeed. 17:39:03 So having those subcategories by default would just be annoying. 17:39:07 notting: it's sort of like the games menu 17:39:11 sorry, my connection died... I was nexting something a while back. 17:39:27 or the Electronics Lab one 17:39:29 * jds2001 is in favor of it being a separate package, just like the games menus are today 17:39:49 The FEL menu is just a single Electronics menu. 17:39:56 Not a whole hierarchy. 17:40:04 jds2001: right. i don't object to the package, i just don't think it's needed by default out-of-the-box 17:40:10 notting: +1 17:40:11 it's the sort of thing for a special spin (are they doing one?) 17:40:41 The electronics-menu package is required by several electronics packages, which is why I brought that issue up. 17:41:00 yeah, I wouldn't require it. 17:41:06 It makes sense for that menu, but for this one? 17:41:30 no, it already has someplace to go. 17:41:47 the electronics one is a new top-level menu, correct? 17:41:51 notting: i could go with that 17:41:52 Correct. 17:42:16 yeah, we can already put stuff in the sound & video menu 17:42:34 So we're approving this feature as long as it's implemented in an optional package which is not required by any other package? 17:42:48 sure. 17:43:04 Let's vote for that proposal? 17:43:07 +1 17:43:09 +1 from me, obviously. 17:43:10 +1 17:43:12 +1 to that... 17:43:13 +1 17:43:14 +1 17:43:41 #agreed FedoraStudio menus are approved, as long as the package is optional and required by no other package. 17:43:58 #topic anaconda mdraid 17:44:01 .fesco 193 17:44:17 +1, seems good. 17:44:27 well it's not like it didn't support mdraid before ;) 17:44:32 but +1 to mdraid for imsm 17:44:34 +1 except the fixme stuff needs fixed. ;) 17:44:44 +1 17:44:50 +1 17:44:50 in the short term, copy relnotes to docs 17:44:52 no, this is some dmraid stuff becoming mdraid :) 17:45:04 (anything making less fakeraid is good) 17:45:07 +1 17:45:15 indeed, fakeraid sucks 17:45:23 nirik: Well, it's still as fake as before. 17:45:29 it's still the same raid. just a different assembling tool 17:45:32 Just implemented differently in software. 17:45:37 #agreed Anaconda mdraid feature is approved. 17:45:41 yeah, I suppose. 17:45:45 oh, well then it still sucks :) 17:46:11 i would approve a feature for anaconda to throw up a dialog "go buy some real hardware" :D 17:46:16 anyhow, i digress 17:46:28 #topic ABRT F12 17:46:33 .fesco 194 17:47:19 +1 17:47:22 +1 17:47:25 +1 17:47:28 +1 17:47:30 +1 17:47:41 #agreed ABRT F12 feature is accepted 17:47:56 #topic Gnome 2.28 17:48:01 .fesco 195 17:48:05 +1 17:48:08 * jds2001 is concerned about the timing 17:48:09 but +1 17:48:13 +1 17:48:22 Isn't it somehow redundant to list both the new GNOME and individual GNOME features as features? 17:48:51 is this going to land in time? 17:49:02 jds2001: I'm fairly sure GNOME 2.28 won't be out later than September - Early October due to that distribution with a 'U'. 17:49:07 +1 if so... but from the schedule it's not clear to me that it will. 17:49:35 Sep 23 GNOME 2.28.0 stable release 17:49:36 sep 23rd it looks like on their schedule currently. 17:49:52 yeah, and sep 22 freeze 17:50:00 does not compute 17:50:12 I think they can pull this off. 17:50:13 Sep 21 GNOME 2.28.0 stable tarballs due 17:50:28 yeah, they often get them hot off the presses... 17:50:32 +1 17:50:32 it's very tight tho. ;( 17:50:33 If it's just 2-3 days late, an exemption is certainly possible. 17:50:37 It has been done for KDE too. 17:50:43 assuming that they can get the tarballs soon after there done they could pull it off 17:50:45 And also for GNOME in the past. 17:50:56 yeah, but thats assuming no slips in their schedule... 17:50:59 i think +1 17:51:09 anyhow, we can deal with it when/if it happens.... +1 here. 17:51:09 emapthy i suppose is special because it's a switch of a distro default that wasn't part of the official gnome stack before 17:51:11 nirik: There's that big distro with a 'U' which is releasing in October. 17:51:15 They can't afford any slips. 17:51:19 if we have rc12 instead of the release version, so be it 17:51:20 but any slips then we would need to evaluate things 17:51:26 Kevin_Kofler: opensUse? 17:51:31 notting: LOL 17:51:33 +1 to GNOME 2.28 from me. 17:51:35 linpUs? 17:52:02 #agreed GNOME 2.28 feature is accpeted 17:52:12 #topic KVM NIC hotplug 17:52:17 notting: i thought empathy was default upstream 17:52:20 .fesco 196 17:52:22 we dirverged from it 17:52:27 dgilmore: it is 17:52:31 * notting suspects upstream gnome and kde are historically better at keeping their schedules than we are :/ 17:52:32 dgilmore: has been for awhile 17:52:41 +1 for KVM_NIC_Hotplug 17:52:47 +1 17:52:50 +1 17:52:57 +1 17:53:01 +1 17:53:02 +1 17:53:12 +1. although there are a couple of refs to F11 in the page that could be fixed 17:53:20 #agreed KVM NIC hotplug feature is approved. 17:53:31 #topic noarch subpackages 17:53:37 .fesco 197 17:53:44 As I wrote in the ticket: I don't see how this is a Fedora 12 feature. This is available already now and has been before F11 got released, and some packages in F10 updates and F11 are already noarch subpackages. 17:53:47 * jds2001 is unsure this is a feature 17:54:05 this is more an FPC proposal than a feature 17:54:36 well, I think they want to tout it, but not sure most people will care. ;) 17:54:39 -1; the technical bits were in prior releases, and the per-package bits should be packager discretion 17:55:15 -1 too, same as notting, plus if anything is to be done for the per-package bits, that's something for FPC. 17:55:19 nirik: if i read it correctly, there were changes to guidelines to require noarch subpackages in here. 17:55:28 -1 not a feature this time 17:55:35 -1 17:55:35 -1 17:55:53 Guideline changes need to go through FPC, not FESCo (unless you're trying to appeal FPC's decision). 17:55:55 yeah, -1... but might suggest going to FPC to add a suggestion on it. 17:56:17 #agreed noarch subpackages feature is rejected, the technical bits were in previous releases, and the per-package bits are an FPC matter. 17:56:35 #topic rebootless installer 17:56:43 .fesco 198 17:56:48 feature owner here: note, inclusion in spins is desired, not mandatory (user can install from network) 17:57:11 dmc414: is your package under review yet? or not yet? 17:57:18 notyet 17:57:34 dmc414: But you're advertising it as included in the spins. 17:57:34 * jds2001 is also wondering why this couldn't be integrated into anaconda 17:57:43 -1 to having multiple installers on the live cds 17:57:48 Kevin_Kofler: ? 17:58:06 "An experimental new rebootless installer has been included with the LiveCD/USB." 17:58:16 I can change the feature page to reflect that, if needed to get acceptance 17:58:45 dmc414: did you try to work with the anaconda guys to get this feature integrated into anaconda? 17:58:48 jds2001: time would be the reason for no anaconda integ for f12 17:59:02 jds2001: anaconda people have known about this for years, no interest 17:59:31 I can try to get some feedback on this from Sebastian Vahl (the KDE Live CD maintainer) if wanted. 17:59:52 can I get it approved as network-only, then revise to in-spin if buyin? 18:00:03 also, do we have feedback from desktop folks? 18:00:21 dmc414: i think id rather see it integrated into anaconda 18:00:38 there is a unionfs issue that may preclude it from f13, see the dependenies 18:00:53 my concern is that touting a feature of an installer that would require the user respin their own livecd first (if it's just in-repo) is likely to confuseusers 18:00:59 i'm only kind of authoritative for desktop, but: seriously, no. 18:01:00 dgilmore: no time for anaconda integration for f12 18:01:15 notting: no, you just need to yum install the package 18:01:27 (if you have network) 18:01:50 ajax: ? 18:01:53 dmc414: then id advocate waiting till it can be done right 18:02:02 we already have too much skew between what gets installed between live image and dvd media. more seems like a really bad idea. 18:02:26 I'm not going to advocate any further, I think you are passing up something really cool 18:02:51 dmc414: you can defintely get the package reviewed and have it available. 18:03:04 Not being a feature doesn't mean we're outright rejecting the idea. 18:03:14 I would also like to see it in anaconda. Failing that I would like to see it in as a package and tested and such. 18:03:54 nirik: anaconda people have had the opportunity to show interest for 2 years 18:04:17 dmc414: did you provide a patch? was there a bug for this? 18:04:20 I'd like to run with this on my own, for a purely experimental demonstration in f12 18:04:32 I'm sorry, but I think the lack of interest from Anaconda people says something about the usefulness (or lack thereof) of the feature. 18:04:34 nirik: I don't need a patch, I have a complete implementation 18:04:44 Kevin_Kofler: or politics 18:04:46 dmc414: you're more than welcome to, like I said, I don't think that's a feature, though. 18:04:58 fair enough 18:05:51 dmc414: I think it's cool... but having 2 installers seems like a bad idea... 2x the testing, having to ask everyone how they installed, more docs, more confusion. 18:06:05 nirik: marked as *experimental* 18:06:26 right, but surely it goes beyond experimental at some stage. 18:06:27 but if the package is in and popular, perhaps you can get the anaconda folks interested in adding that functionality? espcially if it's popular and tests well? 18:06:31 dmc414: its still confusing to people 18:06:43 the main benefit of inclusion in f12, is to guage feedback, to possibly prevent a unionfs liveos architecture that precludes it from f13+ 18:07:03 dmc414: can you expand on the unionfs issue? 18:07:21 From releng side, I'd prefer that the package got in, but not listed as a feature. We aren't ready to promote this as a supported install method 18:07:23 nirik: I don't think this is the place for that discussion 18:07:43 nirik: it works by using device-mapper to pull in current changes. unionfs would break that 18:07:45 (short answer) 18:08:10 In other words, the design is not future proof and may become obsolete as soon as the next release of Fedora. 18:08:14 f13: agreed. i see no issue with having it in the repos 18:08:23 though id prefer anaconda integration 18:08:34 ok, but I don't think thats very nice... trying to get in a feature to prevent a change that might otherwise be good from a technical standpoint. 18:08:42 dgilmore: as said, anaconda integration is the f12+ plan, if people like it 18:08:44 and would prefer to wait to tout it as a feature until its in anaconda 18:08:46 nirik: Right. 18:09:17 nirik: it's only 'trying' if people like it so much that it outweighs the tradeoffs of that other decision 18:09:21 -1 to feature now, but I would encourage dmc414 to add the package and get feedback and try and get anaconda folks interested in adding the feature down the road. 18:09:29 unionfs for live CDs could provide better support for persistence. 18:09:52 and make the readonly root support in rc.sysinit actually sane 18:09:52 I think that's much more valuable than saving a single reboot at installation time (which is probably something you do exactly once, as you can't upgrade from a live CD). 18:09:55 Kevin_Kofler: true, but thats more argument to include it in f12 to see if there are counter-tradeoffs against unionfs 18:09:59 -1 to the feature, +1 to the package (but that doens't need FESCo approval) 18:10:56 jds2001: agreed -1 as a feature, but do get the package in 18:11:30 * notting agrees with jds2001 18:11:44 * sharkcz laos agrees with jds2001 18:11:57 I think its cool enough that with the experimental tag, it would generate good press 18:12:06 but I'm biased :) 18:12:17 your loss... 18:12:25 We don't want an experimental feature to generate press. 18:12:31 ext4 in f9? 18:12:35 #agreed Rebootless installer is rejected as a feature, however, the package is encouraged to go in the repos 18:12:39 The more press it generates, the more people will want to use it and complain if it doesn't work. 18:12:55 anyhow, we have much to get to. 18:12:57 For the record, -1 to the feature from me too. 18:13:04 #topic SR-IOV 18:13:10 .fesco 199 18:13:51 only one controller supported? 18:14:00 seems that way 18:14:33 Looks like most hardware doesn't support this at all. 18:15:02 And the driver side is implemented only for that one. 18:15:17 But I don't know how much hardware could support it given an appropriate driver. 18:15:54 /msg zodbot fasinfo chrisw 18:15:58 bah 18:16:15 cdub, usually. don't see him. 18:16:22 I think the big question here is whether this is worth advertising as a Fedora feature. 18:16:23 it seems odd to tout this as a feature with only one device supported. 18:16:27 but... meh, +1 18:16:29 me too. 18:16:44 (although those cards are pretty common) 18:16:53 It's definitely good to have this kernel feature, but there are more important features which don't have feature pages. 18:16:58 and will only get more common 18:17:04 and more hardware will start to support this 18:17:06 +0 18:17:07 I just pinged cdub and he's going to turn up in a mo 18:17:11 +1, I mean 18:17:14 +1 18:17:18 rwmjones: cool 18:18:19 * dgilmore wonders what this gives us over virtual nics etc 18:18:35 yeah. increased performance? 18:18:35 dgilmore: presumably talking directly to the PCI device 18:19:02 ask cdub :-) 18:19:05 Is SR-IOV something inherently specific to Ethernet controllers or could it also be used in other hardware? 18:19:15 jds2001: but you have multiple vms accessing it so there is some control overhead 18:19:30 it's not sepcific to Ethernet controllers 18:19:39 dgilmore: one per VF, iiuc 18:19:44 cdub, there was also a question earlier about the amount of hardware which supports this ... only one piece of hardware is mentioned on the feat page 18:19:52 Kevin_Kofler: it's also not available in any hardware other than NICs right now 18:19:56 * jds2001 not a kernel guy, so im not sure 18:19:57 cdub: what does it mean to us? the feature really doesnt let me knwo whats so great about it 18:20:16 rwmjones: there are now two devices 18:20:50 dgilmore: it means one can allocate resources from a PCI device to assign to a Virtual Machine 18:20:52 ok, does this take advantage of multiple hardware queues on the card, and basically allocate a queue per VM? 18:21:05 or am i misunderstanding entirely? 18:21:06 jds2001: essentially, yes 18:21:11 cdub: and? that doesnt seem like a big deal to me 18:21:35 virtualized nics have a performance penalty to them 18:21:39 dgilmore: right now, if you want to assign a PCI device to a VM (typically for performance reasons) 18:21:40 direct access to the hardware is better 18:21:53 dgilmore: you have to have X number of physical devices in the box 18:22:16 dgilmore: w/ SR-IOV, you need only 1 physical device which is capable for multiple virtual devices 18:22:31 dgilmore: so you can get bare metal I/O performance in a VM 18:22:50 cdub: and the overhead is less than vitualising the devices for each host? 18:23:03 dgilmore: yes, it is 18:23:27 perhaps adding something to the feature page about why its a big win would help educate folks why this is a Good Thing 18:23:28 dgilmore: the device is driven directly by the guest OS 18:23:35 cdub: so this needs hardware support, which right now is mostly lacking in the wide world 18:23:52 network perf numbers for virt nic vs. sr-iov nic 18:23:56 j-rod: indeed because it doesnt really explain much 18:24:22 dgilmore: yes, there are few devices that support this mode (2 to be exact) 18:24:50 cdub: is it ever going to grow beyond intel gigabit/10gb device ? 18:24:53 * j-rod already knew what it was, but yeah, looking at the feature page again, could stand to explain a bit more for the average reader 18:24:57 cdub: which makes me wonder if we should do a big job of touting it 18:25:00 j-rod: yes, i can add that to the feature page 18:25:05 * nirik is +1 , but the page could be pimped up and such. 18:25:07 notting: yes 18:25:23 dgilmore: it's a huge buzz in the virt world 18:25:30 * dgilmore thinsg the feature page is lacking and needs more detail 18:25:40 dgilmore: for the rest of the normal world...not a big deal ;-) 18:25:51 * jds2001 steps away for a minute, but +1 18:25:58 it's my fault for not adding better details to the page 18:26:03 +1 here, definitely 18:26:34 that's jds, j-rod, nirik, notting, sharkcz 18:26:39 im 0 for now. i think it could be intresting but its something that we are going to need more info to educate people 18:26:51 #approved SR-IOV is approved as a feature. Please clarify the feature page with more details. 18:27:11 0 from me too, I really don't care either way. 18:27:30 i will update the page w/ better details 18:27:53 I'm noticing that the virt folks are currently the most effective at touting their features. 18:28:03 A lot of the listed Fedora features are virtualization-related. 18:28:19 specifically, which cards support SR-IOV, and clearer description of benefits 18:28:33 #agreed SR-IOV is approved as a feature. Please clarify the feature page with more details. 18:28:48 notting: wrong command :) 18:28:56 heh 18:29:13 anyhow 18:29:26 #topic libguestfs 18:29:29 .fesco 200 18:29:43 Kevin_Kofler: that is probably because a lot of other features can be implemented upstream and just get inherited by Fedora, while virt needs distro integration 18:29:59 +1 to libguestfs here. 18:30:02 +1 18:30:04 +1 18:30:09 +1 18:30:16 +1 18:30:26 #agreed libguestfs feature is accepted 18:30:33 that was easy ... 18:30:34 #topic KVM Stable guest ABI 18:30:36 .fesco 202 18:30:36 +1 could do with having more info 18:31:07 so this is basically so you dont have to reactivate windoze when you upgrade? 18:31:16 A lot of work for the benefit of inferior operating systems not liking hardware changes. :-( 18:31:40 Kevin_Kofler: yeah, but lots of people use it :) 18:31:41 it's also to prevent things like ethernet card renumbering 18:31:44 * nirik has never run into this with linux guests. 18:31:56 so, it lists options there... which is going to be done? 18:32:04 option 2 18:32:05 ah, #2 18:32:09 that's listed too :) 18:32:16 -1 the feature page is way incomplete 18:32:22 the stable ABI may be necessary for live migration, too 18:32:36 otherwise you may not be able to live migrate a guest from Fedora 11 to Fedora 12, for example 18:32:47 (because the destination host emulates slightly different hardware) 18:33:07 riel: right the feature page needs to ay what its going to do. not present options 18:33:24 it looks like the feature is very immature and not ready to be considered 18:33:33 yeah, I would say nuke or archive the options, present whats going to happen. 18:33:41 i think it needs doing but its not close to ready yet 18:33:46 it was in a kind of "upstream hell" for a long time (until recently) 18:33:59 The patch got accepted upstream now. 18:34:06 So it's not being done as a Fedora-specific hack. 18:34:32 Kevin_Kofler: thats fine it doesnt excuse an immature feature page 18:34:32 do you guys think this can land before feature freeze? 18:34:42 The only thing one could possibly object to is the part where libvirt defaults to saving the ABI version. 18:35:51 id like to see a way that guests can be upgraded to take advantage of new qemu abi features 18:35:52 * nirik suggests cleaning up the feature page and we can revisit it next week? 18:35:55 we're not saying the feature isobjectionable 18:36:03 nirik: right 18:36:08 yeah, sounds good, we only have 25 minutes left 18:36:19 dgilmore, that's a large, difficult problem 18:36:20 dgilmore: Me too, but isn't that just a matter of changing the version in the virtualization GUI? 18:36:23 because i dont run windows machines i dont care for the feature personally 18:36:40 dgilmore: as mentioned, there are other uses 18:36:47 rwmjones: Huh? It's just a matter of bumping/removing the hardcoded version. 18:36:48 rwmjones: it needs a solution, because for my uses this feature is a hinderance 18:37:48 jds2001: sure. I just think this feature is very incomplete and needs to be revisited when its more definate 18:37:49 windows guests are designed (because of "activation") to be hard to fix, they are designed to check if details of the hardware changes 18:37:53 anyhow, shall we defer to next week 18:38:23 #agreed this is deferred til next week, when the feature page is cleaned up more. 18:38:43 #topic KVM qcow2 performance 18:38:47 .fesco 203 18:39:40 +1 18:39:56 -1! we should make performance worse! 18:39:59 oh wait. +1. 18:40:09 +1 18:40:09 +1 18:40:14 notting: :-) 18:40:18 +1 18:40:36 #agreed KVM qcow2 performance feature is accepted 18:40:46 +1 18:40:47 * jwb finally rejoins 18:40:50 #topic NFSv4 default 18:41:02 .fesco 204 18:41:15 +1, NFSv4 good. 18:41:24 +1 18:41:28 +1 18:41:28 (if one has to use NFS, which is bad :D) 18:41:43 Can't stay with an ancient FS forever. 18:41:48 +1 18:41:50 v4 is at least merely old. ;-) 18:41:59 +1 18:42:00 doesn't v4 need kerberos infrastrucutre? 18:42:06 smooge: nope 18:42:12 +1 18:42:15 +1 18:42:16 does it help the firewall issues? 18:42:21 jwb: yep 18:42:26 well then +1 18:43:04 single tcp port :) 18:43:07 #agreed NFSv4 as default feature is accepted. 18:43:31 #topic NetBeans 6.7 18:43:38 .fesco 205 18:43:40 Are we going to get a feature page for every single updated application now? 18:43:59 we've done netbeans before 18:44:12 Kevin_Kofler: if it requires a lot of coordination between package maintainers, yes. 18:44:23 well, major ones where new features are added, or needs coordination. 18:44:24 and it's a significant change that users would care about 18:44:48 and had similar questions, iirc :) 18:44:48 +1 18:44:48 +1 18:44:49 this one doesn't seem to require any coordination, though 18:44:54 +1 18:45:04 it's updating two packages, and adding new dependencies of them 18:45:18 -1, it's just a rebase-to-upstream of a non-default IDE 18:45:26 i think its helpful to advertise what developers/users can get from using fedora 18:45:55 https://fedoraproject.org/wiki/Features/Policy/Definitions 18:46:19 I think alot of developers might like it. we have done features for Eclipse upgrades in the past 18:46:39 hee. it adds support for sun's version of fedorahosted 18:47:35 anyhow, i see 3 +1's, one -1. Anyone else? 18:47:37 Hmmm, OK, if this one is a feature, KDevelop 4 (most likely headed for Fedora 13) will be one too. 18:47:49 Kevin_Kofler: sure thing. 18:48:22 hrrm 18:48:29 http://www.netbeans.org/community/releases/67/relnotes.html has 18:48:33 Ubuntu 9.04: 18:48:33 Processor: 800MHz Intel Pentium III or equivalent 18:48:33 Memory: 512 MB 18:48:34 Disk space: 650 MB of free disk space 18:48:39 * jds2001 would like to dispense with this feature expeditiously :D 18:48:41 as a minimum requirement 18:48:51 ok, that seems fine. 18:49:02 +1 to the feature from me, I don't want to be the bad guy who blocks it. :-) 18:49:32 i think that we should push the feature owners to get fedora included in the upstream os requirements list 18:49:37 IDEs can be interesting to developers. 18:49:47 dgilmore: It gives a minimum requirement, Fedora is better. :-p 18:49:51 the only linux mentioned upstream is ubuntu :( 18:50:21 and RHEL under "various other Linux distros" 18:50:26 so without us touting it. people will look and think they need ubuntu to use it in linux 18:50:32 we cna push for that independently of the features. 18:50:58 Yeah, that's an upstream issue, completely separate from the feature. 18:51:08 sharkcz: i dont see that 18:51:18 And actually, advertising NetBeans as a Fedora feature is the best way to fight that misconception. 18:51:57 dgilmore: small letters below "big list of OSes" 18:51:57 We have 4 +1 votes, we just need one more to be done with this. 18:52:16 sharkcz: just found it 18:52:47 +1, sorry 18:52:52 #agreed NetBeans 6.7 feature is accepted 18:53:01 * j-rod distracted... 18:53:12 #topic Network Interface Management 18:53:16 .fesco 206 18:53:34 +1 18:53:35 +1, looks awesome 18:53:44 +1 18:53:58 * nirik nods. +1 here 18:54:07 +1. although i'm not sure why the configuration tool needs up/down commands 18:54:16 #agreed Network Interface Management feature is accepted 18:54:27 didn't join a second too soon :) 18:54:29 #topic pk browser plugin 18:54:35 +1 though id like to see NM and system-config-network support 18:54:46 lutter: :) 18:55:24 lutter: is there plans to get this integrated with the resgular management tools? 18:55:43 lutter: because NM blows chunks on bachines with bridges right now 18:55:56 it does not... it just doesn't support them. ;) 18:55:59 dgilmore: yes, definitely with NM .. we had a more ambitious feature written up efore, but I wrote this one up because it reflects what can be working in F12 18:56:17 dgilmore: I know .. 18:56:25 +1 18:56:27 * notting suspects that NM might end up obsoleting s-c-n (from a writing-of-configs standpoint) before s-c-n gets ported to a new lib 18:56:27 lutter: ok. i know people who want to use bridges with NM controlled boxes 18:56:46 notting: :) thats ok 18:57:02 dgilmore: yes, very common .. people who use their laptops for running VM's 18:57:25 lutter: right. is there any chance to get this support for F-12? 18:57:27 +1 to pk-browser-plugin. although it leaves out the missing scope of "get the internet to put the metadata on their web page" 18:57:41 * nirik looks for the url here. 18:57:52 dgilmore: from talking to dcbw, no .. he says he's busy with lots of higher-priority things in NM 18:58:33 +1 to pk-browser-plugin 18:58:37 lutter: :( 18:58:39 In what browsers has the browser plugin been tested yet? There are no details. 18:58:51 apparently epiphany and firefox. 18:58:53 The README just says that there are some GTK+ calls in there. 18:59:10 So I'm worried about what happens in Konqueror, Arora etc. 18:59:23 * nirik nods. I was wondering about that too. 18:59:34 worst case, the same thing that happens today, right? 18:59:38 It also requires the GLib event loop, but that one's enabled by default in our Qt builds. 18:59:45 there are a lot iof plugins that use gtk .. how do they behave theire? 18:59:54 Worst case, the browser crashes and you have to disable or delete the plugin. 19:00:09 drago01: It depends, some work, some don't work. 19:00:26 Mozilla plugins are a fairly fragile ad-hoc interface, unfortunately. 19:00:47 so NEEDINFO? 19:00:55 yes 19:01:05 so, what about having a web page that says to install some known vulnerable thing (before a fedora security update happens). I guess thats pretty far fetched. 19:01:31 #agreed feature is deferred until more information on plugin compatibility with various browsers can be obtained, 19:01:53 #topic PK Command Not Found 19:01:57 .fesco 208 19:01:58 pk-cnf looks neat 19:02:02 it does 19:02:13 only concern is performance hit 19:02:22 +1 to that, but mether pointed out some performance concerns 19:02:32 but his example was pretty far fetched 19:02:33 +1, and also what about other shells? :) 19:02:41 does the shell seem to freeze while waiting for yum/pk? 19:02:51 bash is the One True Shell :) 19:02:53 +1 would like to make sure it works in bash and zsh 19:02:55 I assume this one only works with gnome-packagekit? 19:02:58 j-rod: i believe so. 19:03:07 Kevin_Kofler: it's a commandline thing 19:03:14 j-rod: I had to turn off bash-completion for yum stuff because it would slaughter my system every time I tried to tab complete some yum thing 19:03:19 Kevin_Kofler: should work with anything 19:03:34 Kevin_Kofler: that would be annoying as hell (don't want some fancy popups while working in a terminal) 19:03:36 f13: yeah, that's exactly the sort of thing I'm thinking of 19:03:37 j-rod: I would worry about the PK tool doing the same. 19:03:40 f13: its ok here. but i have a mirror on my lan 19:03:50 same here 19:03:57 dgilmore: wasn't just getting of repodata, it was all the disk I/O to read it into memory and do the search 19:04:04 OK, I'm looking at the screencast, it's indeed text only. 19:04:14 Looks like a cool feature. 19:04:28 * nirik hopes it also doesn't do anything if there is no net enabled. ;) 19:04:31 +1 to the feature from me. 19:04:32 f13: yeah rpm -q a does the same (heavy disk io and blocked shell) 19:04:43 one more? 19:04:46 +1 19:04:59 +1, but would like performance/blocking concerns addressed 19:05:07 #agreed packagekit command not found feature is approved. 19:05:13 j-rod: not sure that's possible :( 19:05:31 anyhow, anything else, or put a fork in it? 19:05:35 jds2001: do the processing in a diferent process 19:05:40 well, "addressed" could be "documented and explained" 19:05:44 jds2001: how much is left on the agenda? 19:05:50 nirik: none 19:05:54 wow. 19:06:22 * nirik has 2 small followup items for open floor... 19:06:39 k, i guess we can go late :) 19:06:44 feel free :) 19:06:48 2 seconds... 19:06:57 the c-n-f thing... 19:07:00 dgilmore: did you ever get a chance to revise/give feedback on that ThreatAssessment doc? 19:07:17 ixs: did you ever gather data we were looking for on the flags thing? 19:07:17 oh, we fixed the cvs ctrl-c thing yesterday, too. 19:07:20 would be cool if it could be "Command not found. Search for similar? y/n" 19:08:07 so you could opt in for the disk thrashing 19:08:07 nirik: no its one issue 19:08:07 if you just made a typo and know it, its faster to retype than sit there while the system spins 19:08:13 nirik: I provided a list of several (mostly KDE) packages using country flags, and I'm fairly sure there are a lot more. 19:08:25 * j-rod is done now 19:08:42 nirik: yeah, I did actually. 19:08:50 Kevin_Kofler: yes, I know. We asked ixs to gather a bunch more data. Was just wondering if he had a chance. 19:08:56 ixs: ok, next weeks meeting? 19:09:01 nirik: sounds good. 19:09:07 FWIW, there's some effort within KDE to make them share the flags instead of shipping many copies, but still it means many apps need flags (and not necessarily in the same format, there are apps using small icons, apps using large SVGs, apps using 3D flags). 19:09:08 nirik: the issues was a minor one about how thinsg land in the lookaside hace in cvs 19:09:27 dgilmore: ok. We should get that tweaked and release it (as we agreed to do) 19:09:38 nirik: we should 19:09:43 ixs: thanks. 19:09:46 nirik: mmcgrath it on pto today 19:09:50 Upstream KDE is explicitly NOT considering the option to stop shipping or using flags. 19:09:57 going to watch the harry potter movie! 19:10:03 * jds2001 wouldn't take PTO for that :) 19:10:05 They're considering them a worthwhile feature, and I agree with them. 19:10:14 * nirik has nothing else. 19:10:39 ok, put a fork in it now? 19:11:01 yes please 19:11:02 #info flags will be discussed next week 19:11:16 #endmeeting From philipp_subx at redfish-solutions.com Fri Jul 17 19:50:41 2009 From: philipp_subx at redfish-solutions.com (Philip A. Prindeville) Date: Fri, 17 Jul 2009 12:50:41 -0700 Subject: Need a sponsor: mod_proxy_html (apache) Message-ID: <4A60D611.9010501@redfish-solutions.com> Hi. I need a sponsor for this. An RPM has been built on several systems (including FC8 and FC9 and Centos5) and tested on all of those. The ticket has been languishing now unassigned for almost a year. https://bugzilla.redhat.com/show_bug.cgi?id=452636 Can someone please pick this up? It's just an .src.rpm for Apache's mod_proxy_html. It's pretty trivial. Thanks, -Philip From awilliam at redhat.com Fri Jul 17 19:57:31 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 17 Jul 2009 12:57:31 -0700 Subject: F12 Alpha Blocker Bug review meeting recap 2009-07-17 Message-ID: <1247860651.6035.15.camel@adam.local.net> A quick recap of today's blocker bug review meeting for Fedora 12 (especially Alpha). Attendees at various times were myself, James Laska, Jesse Keating, Matthias Clasen, Toshio Kuratomi, Adam Miller and Denise Dumas. Thanks to all attendees. We reviewed in full both the F12Alpha and F12Blocker lists, dropping several bugs from each, and adding two from F12Blocker to F12Alpha. We also worked to clarify the status of work on several of the bugs. If you are aware of any bugs that you think should be blockers for either Fedora 12 Alpha or Fedora 12 final release, please bring them to the attention of test-list, or simply set them to block the appropriate bugs (F12Alpha and F12Blocker, respectively) yourself, and we will review them at the next meeting. Please do actively think about this: we want to catch all critical bugs, and we don't mind downgrading a few 'false positives' if it means not missing any important issues! The next meeting is due next Friday, 2009-07-24. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From opensource at till.name Fri Jul 17 20:16:11 2009 From: opensource at till.name (Till Maas) Date: Fri, 17 Jul 2009 22:16:11 +0200 Subject: Packages tracked by FEver that need to be updated In-Reply-To: <4A609F4A.2000701@fedoraproject.org> References: <200907102243.14776.opensource@till.name> <200907161952.47891.opensource@till.name> <4A609F4A.2000701@fedoraproject.org> Message-ID: <200907172216.22078.opensource@till.name> On Fri July 17 2009, Rahul Sundaram wrote: > On 07/16/2009 11:22 PM, Till Maas wrote: > It would be useful to have a dynamically generated webpage that shows > how close we are to upstream versions across different Fedora versions > similar to the distrowatch packages page. A static webpage that is regenerated every now and then should be easy enough, that I might create it. On my blog the project leader of http://oswatershed.org/ mentioned his project, which is something similiar for different distributions, but it currently does not show any packages for Fedora. > Maybe allow package > maintainers to add in comments indicating what their plans are, even. > For example, if a update is going to break the ABI in a intrusive way > (let's say XULRunner) or change the configuration file format (nagios), > I as a package maintainer would like to convey that information to my > users so they know why I haven't pushed an update despite new features > or even minor bug fixes. The bug report could be linked on the page and then the maintainer can use it for this. This should also then be easily doable. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From enrico.scholz at informatik.tu-chemnitz.de Fri Jul 17 20:41:04 2009 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 17 Jul 2009 22:41:04 +0200 Subject: Does anything require /proc/bus/usb? In-Reply-To: <4A60C4D5.8050900@cchtml.com> (Michael Cronenworth's message of "Fri\, 17 Jul 2009 13\:37\:09 -0500") References: <4A609C00.2080801@cchtml.com> <87d47zz0xb.fsf@fc5.bigo.ensc.de> <4A60B33C.5020206@cchtml.com> <878winyzny.fsf@fc5.bigo.ensc.de> <4A60C4D5.8050900@cchtml.com> Message-ID: <87vdlr11r3.fsf@sheridan.bigo.ensc.de> Michael Cronenworth writes: >> You want to change something which is not broken and requests that >> I adapt my workflow and spent work into something to retain old >> functionality? > > What about old /dev (pre udev)? It was not broken. Sure, you couldn't > add nice new functionality quickly, but it wasn't broken. Static /dev still exists and works perfectly in servers or embedded devices. Recent udev did not removed features (as you are requesting) and its extras seem to outweight its drawbacks (high boot times). > Should we have kept HAL then? Keep using HAL forever? Dunno; I did and do not use hal on pre FC11 machines. > This type of mindset works until there is a better solution. There > are better solutions to usbfs today. Most distros use the newer > alternative. There is not needed an alternative. usbfs and the udev/sysfs based approach coexist nicely. > You ignored my initial comment on this and seem to want to be ignorant > of such a fact. Which initial comment? That you want to remove a feature to workaround bugs in an application? >> VirtualBox seems to be the issue. Or do you have other examples of >> software which uses crappy heuristics based upon the existence of >> /proc/bus/usb? > > That particular software does not depend on usbfs, but it seems that > VBox will be a scape goat for your whining until I convince you > otherwise. If you had read the thread beforehand you probably would not > have replied. > > Please read the whole thread. Sorry; you must be subscribed to another maillist than me. Here, no article in this thread justifies removal of usbfs with anything else than the broken VirtualBox. Enrico From mike at cchtml.com Fri Jul 17 20:46:28 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Fri, 17 Jul 2009 15:46:28 -0500 Subject: Does anything require /proc/bus/usb? In-Reply-To: <87vdlr11r3.fsf@sheridan.bigo.ensc.de> References: <4A609C00.2080801@cchtml.com> <87d47zz0xb.fsf@fc5.bigo.ensc.de> <4A60B33C.5020206@cchtml.com> <878winyzny.fsf@fc5.bigo.ensc.de> <4A60C4D5.8050900@cchtml.com> <87vdlr11r3.fsf@sheridan.bigo.ensc.de> Message-ID: <4A60E324.5080707@cchtml.com> Enrico Scholz on 07/17/2009 03:41 PM wrote: > > Which initial comment? That you want to remove a feature to workaround > bugs in an application? > Michael Cronenworth wrote: > Fedora/RHEL are the last major distros to retain usbfs support apparently. > > Sorry; you must be subscribed to another maillist than me. Here, no > article in this thread justifies removal of usbfs with anything else > than the broken VirtualBox. > You're trolling now. For the last time: This has nothing to do with VirtualBox. There is no "bug" in VirtualBox. There is no patch required for VirtualBox. From mjg at redhat.com Fri Jul 17 20:50:28 2009 From: mjg at redhat.com (Matthew Garrett) Date: Fri, 17 Jul 2009 21:50:28 +0100 Subject: Does anything require /proc/bus/usb? In-Reply-To: <4A60E324.5080707@cchtml.com> References: <4A609C00.2080801@cchtml.com> <87d47zz0xb.fsf@fc5.bigo.ensc.de> <4A60B33C.5020206@cchtml.com> <878winyzny.fsf@fc5.bigo.ensc.de> <4A60C4D5.8050900@cchtml.com> <87vdlr11r3.fsf@sheridan.bigo.ensc.de> <4A60E324.5080707@cchtml.com> Message-ID: <20090717205028.GA13205@srcf.ucam.org> On Fri, Jul 17, 2009 at 03:46:28PM -0500, Michael Cronenworth wrote: > For the last time: This has nothing to do with VirtualBox. There is no > "bug" in VirtualBox. There is no patch required for VirtualBox. The bug in virtualbox is that it prefers the deprecated interface over the current one. There's no pressing reason for us to disable usbfs yet, and while we'll probably do so eventually I doubt it'll be happening in F12. We generally prefer not to remove interfaces that may be in use unless we gain anything by doing so. -- Matthew Garrett | mjg59 at srcf.ucam.org From jussilehtola at fedoraproject.org Fri Jul 17 20:50:39 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Fri, 17 Jul 2009 23:50:39 +0300 Subject: Proposal to Drop Fedora 12 Features In-Reply-To: <20090717140042.GC8346@nostromo.devel.redhat.com> References: <4A5F8969.4070206@redhat.com> <20090717140042.GC8346@nostromo.devel.redhat.com> Message-ID: <1247863839.2595.2.camel@localhost.localdomain> On Fri, 2009-07-17 at 10:00 -0400, Bill Nottingham wrote: > John Poelstra (poelstra at redhat.com) said: > > https://fedoraproject.org/wiki/Features/XZRpmPayloads > > https://fedoraproject.org/wiki/Features/F12X86Support > > Both updated now. Apologies for the dlay. > > Bill A possibly stupid question: The above page states that the flags will be "-march=i686 -mtune=atom" on i386, but a build I just did in rawhide has "-march=i686 -mtune=generic" so -march has changed but -mtune hasn't? -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From notting at redhat.com Fri Jul 17 20:57:58 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 17 Jul 2009 16:57:58 -0400 Subject: Proposal to Drop Fedora 12 Features In-Reply-To: <1247863839.2595.2.camel@localhost.localdomain> References: <4A5F8969.4070206@redhat.com> <20090717140042.GC8346@nostromo.devel.redhat.com> <1247863839.2595.2.camel@localhost.localdomain> Message-ID: <20090717205758.GA21736@nostromo.devel.redhat.com> > A possibly stupid question: > > The above page states that the flags will be > "-march=i686 -mtune=atom" > on i386, but a build I just did in rawhide has > "-march=i686 -mtune=generic" > so -march has changed but -mtune hasn't? What version of redhat-rpm-config was in the buildroot? (You should be able to pull this from one of the log files.) Bill From notting at redhat.com Fri Jul 17 21:02:53 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 17 Jul 2009 17:02:53 -0400 Subject: Proposal to Drop Fedora 12 Features In-Reply-To: <20090717205758.GA21736@nostromo.devel.redhat.com> References: <4A5F8969.4070206@redhat.com> <20090717140042.GC8346@nostromo.devel.redhat.com> <1247863839.2595.2.camel@localhost.localdomain> <20090717205758.GA21736@nostromo.devel.redhat.com> Message-ID: <20090717210251.GB21736@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > > A possibly stupid question: > > > > The above page states that the flags will be > > "-march=i686 -mtune=atom" > > on i386, but a build I just did in rawhide has > > "-march=i686 -mtune=generic" > > so -march has changed but -mtune hasn't? > > What version of redhat-rpm-config was in the buildroot? (You should > be able to pull this from one of the log files.) Actually, looking myself: DEBUG util.py:256: redhat-rpm-config noarch 9.0.3-9.fc12 build 56 k So, your build started before the buildroot had been regenerated with the new redhat-rpm-config package. Later builds such as http://kojipkgs.fedoraproject.org/packages/libev/3.70/2.fc12/data/logs/i686/build.log) pull in the new redhat-rpm-config, and get the flags set. (And no, I wouldn't worry about a rebuild just for that.) Bill From mike at cchtml.com Fri Jul 17 21:20:23 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Fri, 17 Jul 2009 16:20:23 -0500 Subject: Fit and Finish test day: batteries and suspend In-Reply-To: <15e53e180907171207q7aa8c7eeo7c796030632a172c@mail.gmail.com> References: <1247849443.1614.8.camel@planemask> <4A60AF67.8060005@cchtml.com> <1247852573.1614.9.camel@planemask> <4A60C51E.2050903@cchtml.com> <2d319b780907171143h72af4328s31bb1b63d8942cc5@mail.gmail.com> <15e53e180907171207q7aa8c7eeo7c796030632a172c@mail.gmail.com> Message-ID: <4A60EB17.6080402@cchtml.com> Richard Hughes on 07/17/2009 02:07 PM wrote: > > It should work fine with 009. If it doesn't work, and it used to work > with HAL (without nut installed) then please file bugs. I've recently > been regression testing with my APC UPS, and this seems to work fine > now. > 009 displays my UPS's again. I believe I had mistakenly stated that the change from HAL to DeviceKit removed UPS device information, but this was related to something else. Thanks for the update. From sundaram at fedoraproject.org Fri Jul 17 21:19:36 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 18 Jul 2009 02:49:36 +0530 Subject: Updates and delays in signing packages Message-ID: <4A60EAE8.3010705@fedoraproject.org> Hi, I have a concern with the recent delays in signing packages and how best to handle that. I maintain Gnote in Fedora. This is very actively maintained and has frequent releases, even weekly. It is also a rather young project (original release in Apr 1) and I do get bug reports on crashes and other issues that are better fixed quickly. I prefer not to push things directly to stable repository. With the recommended time of 7 days in updates-testing and the delay in signing the package for that and signing it for updates repo, the package gets obsoleted by Bodhi with the next release update. What would be the best way to handle this? Rahul From drago01 at gmail.com Fri Jul 17 21:41:45 2009 From: drago01 at gmail.com (drago01) Date: Fri, 17 Jul 2009 23:41:45 +0200 Subject: Updates and delays in signing packages In-Reply-To: <4A60EAE8.3010705@fedoraproject.org> References: <4A60EAE8.3010705@fedoraproject.org> Message-ID: On Fri, Jul 17, 2009 at 11:19 PM, Rahul Sundaram wrote: > Hi, > > I have a concern with the recent delays in signing packages and how best > to handle that. I maintain Gnote in Fedora. This is very actively > maintained and has frequent releases, even weekly. It is also a rather > young project (original release in Apr 1) and I do get bug reports on > crashes and other issues that are better fixed quickly. I prefer not to > push things directly to stable repository. With the recommended time of > 7 days in updates-testing and the delay in signing the package for that > and signing it for updates repo, the package gets obsoleted by Bodhi > with the next release update. ?What would be the best way to handle this? You don't have to push _every_ upstream release as an update. From sundaram at fedoraproject.org Fri Jul 17 22:01:29 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 18 Jul 2009 03:31:29 +0530 Subject: Updates and delays in signing packages In-Reply-To: References: <4A60EAE8.3010705@fedoraproject.org> Message-ID: <4A60F4B9.2040003@fedoraproject.org> On 07/18/2009 03:11 AM, drago01 wrote: > On Fri, Jul 17, 2009 at 11:19 PM, Rahul >> Hi, >> >> I have a concern with the recent delays in signing packages and how best >> to handle that. I maintain Gnote in Fedora. This is very actively >> maintained and has frequent releases, even weekly. It is also a rather >> young project (original release in Apr 1) and I do get bug reports on >> crashes and other issues that are better fixed quickly. I prefer not to >> push things directly to stable repository. With the recommended time of >> 7 days in updates-testing and the delay in signing the package for that >> and signing it for updates repo, the package gets obsoleted by Bodhi >> with the next release update. What would be the best way to handle this? > > You don't have to push _every_ upstream release as an update. Was I not clear? In my case, I do often have to. They fix important bugs. Rahul From drago01 at gmail.com Fri Jul 17 22:30:15 2009 From: drago01 at gmail.com (drago01) Date: Sat, 18 Jul 2009 00:30:15 +0200 Subject: Updates and delays in signing packages In-Reply-To: <4A60F4B9.2040003@fedoraproject.org> References: <4A60EAE8.3010705@fedoraproject.org> <4A60F4B9.2040003@fedoraproject.org> Message-ID: On Sat, Jul 18, 2009 at 12:01 AM, Rahul Sundaram wrote: > On 07/18/2009 03:11 AM, drago01 wrote: >> On Fri, Jul 17, 2009 at 11:19 PM, Rahul >>> Hi, >>> >>> I have a concern with the recent delays in signing packages and how best >>> to handle that. I maintain Gnote in Fedora. This is very actively >>> maintained and has frequent releases, even weekly. It is also a rather >>> young project (original release in Apr 1) and I do get bug reports on >>> crashes and other issues that are better fixed quickly. I prefer not to >>> push things directly to stable repository. With the recommended time of >>> 7 days in updates-testing and the delay in signing the package for that >>> and signing it for updates repo, the package gets obsoleted by Bodhi >>> with the next release update. ?What would be the best way to handle this? >> >> You don't have to push _every_ upstream release as an update. > > Was I not clear? In my case, I do often have to. They fix important bugs. Sure but lets say upstream releases every week and you rebase every second week, whats wrong with that? Unless they are really critical bugs (dataloss / security). From sundaram at fedoraproject.org Fri Jul 17 23:32:15 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 18 Jul 2009 05:02:15 +0530 Subject: Updates and delays in signing packages In-Reply-To: References: <4A60EAE8.3010705@fedoraproject.org> <4A60F4B9.2040003@fedoraproject.org> Message-ID: <4A6109FF.1@fedoraproject.org> On 07/18/2009 04:00 AM, drago01 wrote: > Sure but lets say upstream releases every week and you rebase every > second week, whats wrong with that? > Unless they are really critical bugs (dataloss / security). Yes, there has been critical bugs. Crashes within a number of releases and atleast one potential data loss issue. I really do mean that I have a need to update often. Rahul From oget.fedora at gmail.com Fri Jul 17 23:46:52 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Fri, 17 Jul 2009 19:46:52 -0400 Subject: Updates and delays in signing packages In-Reply-To: <4A60EAE8.3010705@fedoraproject.org> References: <4A60EAE8.3010705@fedoraproject.org> Message-ID: On Fri, Jul 17, 2009 at 5:19 PM, Rahul Sundaram wrote: > Hi, > > I have a concern with the recent delays in signing packages and how best > to handle that. I maintain Gnote in Fedora. This is very actively > maintained and has frequent releases, even weekly. It is also a rather > young project (original release in Apr 1) and I do get bug reports on > crashes and other issues that are better fixed quickly. I prefer not to > push things directly to stable repository. With the recommended time of > 7 days in updates-testing and the delay in signing the package for that > and signing it for updates repo, the package gets obsoleted by Bodhi > with the next release update. ?What would be the best way to handle this? > > Rahul > I think that marking the package that is already in testing as stable and submitting a new version to the testing even before the former one makes its place in the stable repo is the proper way to go. This way the old version does not get obsoleted. I did this once and it worked. Orcan From jwboyer at gmail.com Fri Jul 17 23:57:41 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 17 Jul 2009 19:57:41 -0400 Subject: Updates and delays in signing packages In-Reply-To: <4A60EAE8.3010705@fedoraproject.org> References: <4A60EAE8.3010705@fedoraproject.org> Message-ID: <20090717235741.GA3312@hansolo.jdub.homelinux.org> On Sat, Jul 18, 2009 at 02:49:36AM +0530, Rahul Sundaram wrote: >Hi, > >I have a concern with the recent delays in signing packages and how best >to handle that. I maintain Gnote in Fedora. This is very actively >maintained and has frequent releases, even weekly. It is also a rather >young project (original release in Apr 1) and I do get bug reports on >crashes and other issues that are better fixed quickly. I prefer not to >push things directly to stable repository. With the recommended time of >7 days in updates-testing and the delay in signing the package for that >and signing it for updates repo, the package gets obsoleted by Bodhi >with the next release update. What would be the best way to handle this? I am not exaggerating when I say that updates are getting pushed out as fast as I can possibly make them. And signing is NOT, by any means, the hold up or the slow part. It takes me roughly an hour to get all the pending updates signed for a push (both testing and stable). It takes a push between 2 and 3 days to actually complete right now. We've had some significant delays due to a variety of factors over the past couple of weeks. I think we now have most of the big ones fixed, with the master mirrors allowing more rsync access, and the updates composes now being able to hardlink again (reduces mash time). There is another issue involving deltarpms that I've filed a bug on, and we should get some speed-up if we can get that figured out too. That being said, the updates push will still take quite some time to generate deltas. I'm hoping we can get it down to being able to do a complete push to within a 24 hour period for now, but that remains to be seen. Also keep in mind that as F11 grows older, the mash time for it will increase. I can understand your concern with a very active package like that. At the moment, we can't do anything we aren't already trying to do to get official updates out faster. Have patience. josh From sundaram at fedoraproject.org Sat Jul 18 00:40:49 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 18 Jul 2009 06:10:49 +0530 Subject: Updates and delays in signing packages In-Reply-To: <20090717235741.GA3312@hansolo.jdub.homelinux.org> References: <4A60EAE8.3010705@fedoraproject.org> <20090717235741.GA3312@hansolo.jdub.homelinux.org> Message-ID: <4A611A11.5070508@fedoraproject.org> On 07/18/2009 05:27 AM, Josh Boyer wrote: > > I can understand your concern with a very active package like that. At the > moment, we can't do anything we aren't already trying to do to get official > updates out faster. Have patience. The question wasn't about why there was delays but how I can handle it within my workflow (I thought of just running my own repo but that doesn't seem ideal) but it is good to know more of the inside details on why there are delays in the first place. On a related point, do we have good documentation on the entire process? If there is a need for more to help with signing the packages, I can volunteer (assuming you let me). Rahul From mjg at redhat.com Sat Jul 18 01:00:30 2009 From: mjg at redhat.com (Matthew Garrett) Date: Sat, 18 Jul 2009 02:00:30 +0100 Subject: Updates and delays in signing packages In-Reply-To: <4A6109FF.1@fedoraproject.org> References: <4A60EAE8.3010705@fedoraproject.org> <4A60F4B9.2040003@fedoraproject.org> <4A6109FF.1@fedoraproject.org> Message-ID: <20090718010030.GA16301@srcf.ucam.org> On Sat, Jul 18, 2009 at 05:02:15AM +0530, Rahul Sundaram wrote: > Yes, there has been critical bugs. Crashes within a number of releases > and atleast one potential data loss issue. I really do mean that I have > a need to update often. If software is that unstable then I think it's reasonable to ask whether it's ready to be shipped in a stable distribution release. -- Matthew Garrett | mjg59 at srcf.ucam.org From sundaram at fedoraproject.org Sat Jul 18 01:15:21 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 18 Jul 2009 06:45:21 +0530 Subject: Updates and delays in signing packages In-Reply-To: <20090718010030.GA16301@srcf.ucam.org> References: <4A60EAE8.3010705@fedoraproject.org> <4A60F4B9.2040003@fedoraproject.org> <4A6109FF.1@fedoraproject.org> <20090718010030.GA16301@srcf.ucam.org> Message-ID: <4A612229.9070309@fedoraproject.org> On 07/18/2009 06:30 AM, Matthew Garrett wrote: > On Sat, Jul 18, 2009 at 05:02:15AM +0530, Rahul Sundaram wrote: > >> Yes, there has been critical bugs. Crashes within a number of releases >> and atleast one potential data loss issue. I really do mean that I have >> a need to update often. > > If software is that unstable then I think it's reasonable to ask whether > it's ready to be shipped in a stable distribution release. I think it is. It is not crashing and burning for all the users using it including me all the time. Let's take the latest bug report I have received https://bugzilla.redhat.com/show_bug.cgi?id=511053 It requires you to access the help in a particular way to get it to crash but I consider a crash a problem that needs to be fixed quickly. This doesn't make it in unstable enough to be excluded compared to rest of what we have been included by default in the past and Gnote is not the default in any stable release. Anyway, you are sort of missing the point by focusing on the example given without understanding that for a certain class of software (new project where upstream is active, user demand new features etc) with frequent updates, the current system isn't working out well. I doubt I am the only maintainer with this problem. I Rahul From jwboyer at gmail.com Sat Jul 18 01:26:59 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 17 Jul 2009 21:26:59 -0400 Subject: Updates and delays in signing packages In-Reply-To: <4A611A11.5070508@fedoraproject.org> References: <4A60EAE8.3010705@fedoraproject.org> <20090717235741.GA3312@hansolo.jdub.homelinux.org> <4A611A11.5070508@fedoraproject.org> Message-ID: <20090718012659.GB3312@hansolo.jdub.homelinux.org> On Sat, Jul 18, 2009 at 06:10:49AM +0530, Rahul Sundaram wrote: >On 07/18/2009 05:27 AM, Josh Boyer wrote: > >> >> I can understand your concern with a very active package like that. At the >> moment, we can't do anything we aren't already trying to do to get official >> updates out faster. Have patience. > >The question wasn't about why there was delays but how I can handle it >within my workflow (I thought of just running my own repo but that >doesn't seem ideal) but it is good to know more of the inside details on It might not be ideal, but given that you're waiting for pushes to get your builds into repos it might also be the most convenient for the people that want those builds. Putting repos on a fedorapeople page is not unheard of. >why there are delays in the first place. On a related point, do we have >good documentation on the entire process? If there is a need for more to No. I think our documentation of the entire push process doesn't exist. Some of it we don't want to exist, like how to get onto the signing machine. Some of it really can't be documented because it's dealing with issues as they come up in one form or another and there is no "common" error scenario. Other parts are changing at a somewhat rapid pace as we introduce new fixes and features. I think the best way to start is to get better documentation on the various software components involved first. Those would be bodhi, mash, createrepo, and deltarpm for the most part. Bodhi and mash would be good (and daunting) places to start. >help with signing the packages, I can volunteer (assuming you let me). Signing is not the hurdle. Adding more people to help there won't really make anything faster. We're also toying with making koji do auto-signing at build time, which makes it basically go away. I do appreciate the offer though. josh From sundaram at fedoraproject.org Sat Jul 18 01:34:44 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 18 Jul 2009 07:04:44 +0530 Subject: Updates and delays in signing packages In-Reply-To: <20090718012659.GB3312@hansolo.jdub.homelinux.org> References: <4A60EAE8.3010705@fedoraproject.org> <20090717235741.GA3312@hansolo.jdub.homelinux.org> <4A611A11.5070508@fedoraproject.org> <20090718012659.GB3312@hansolo.jdub.homelinux.org> Message-ID: <4A6126B4.7070609@fedoraproject.org> On 07/18/2009 06:56 AM, Josh Boyer wrote: > > I think the best way to start is to get better documentation on the various > software components involved first. Those would be bodhi, mash, createrepo, > and deltarpm for the most part. Bodhi and mash would be good (and daunting) > places to start. I think I might be able to help. So, let's suppose I come up on IRC and ask questions to get them documented, who can help me with that? Rahul From mjg at redhat.com Sat Jul 18 03:23:47 2009 From: mjg at redhat.com (Matthew Garrett) Date: Sat, 18 Jul 2009 04:23:47 +0100 Subject: Updates and delays in signing packages In-Reply-To: <4A612229.9070309@fedoraproject.org> References: <4A60EAE8.3010705@fedoraproject.org> <4A60F4B9.2040003@fedoraproject.org> <4A6109FF.1@fedoraproject.org> <20090718010030.GA16301@srcf.ucam.org> <4A612229.9070309@fedoraproject.org> Message-ID: <20090718032347.GA17409@srcf.ucam.org> On Sat, Jul 18, 2009 at 06:45:21AM +0530, Rahul Sundaram wrote: > On 07/18/2009 06:30 AM, Matthew Garrett wrote: > > If software is that unstable then I think it's reasonable to ask whether > > it's ready to be shipped in a stable distribution release. > > I think it is. It is not crashing and burning for all the users using it > including me all the time. Let's take the latest bug report I have received > > https://bugzilla.redhat.com/show_bug.cgi?id=511053 > > It requires you to access the help in a particular way to get it to > crash but I consider a crash a problem that needs to be fixed quickly. If it's not a common pathway then I don't think it's urgent - certainly not urgent enough that waiting an extra week is a big problem. > This doesn't make it in unstable enough to be excluded compared to rest > of what we have been included by default in the past and Gnote is not > the default in any stable release. Anyway, you are sort of missing the > point by focusing on the example given without understanding that for a > certain class of software (new project where upstream is active, user > demand new features etc) with frequent updates, the current system isn't > working out well. I doubt I am the only maintainer with this problem. I Most of our users wait 6 months between releases. If they can wait that long to get a new piece of software in the first place, the difference between an upload a week and an upload every two weeks shouldn't be much of an issue. I just really don't see how feature requests can be that high a priority during a stable release. -- Matthew Garrett | mjg59 at srcf.ucam.org From sundaram at fedoraproject.org Sat Jul 18 05:19:12 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 18 Jul 2009 10:49:12 +0530 Subject: Updates and delays in signing packages In-Reply-To: <20090718032347.GA17409@srcf.ucam.org> References: <4A60EAE8.3010705@fedoraproject.org> <4A60F4B9.2040003@fedoraproject.org> <4A6109FF.1@fedoraproject.org> <20090718010030.GA16301@srcf.ucam.org> <4A612229.9070309@fedoraproject.org> <20090718032347.GA17409@srcf.ucam.org> Message-ID: <4A615B50.7060909@fedoraproject.org> On 07/18/2009 08:53 AM, Matthew Garrett wrote: > > Most of our users wait 6 months between releases. If they can wait that > long to get a new piece of software in the first place, the difference > between an upload a week and an upload every two weeks shouldn't be much > of an issue. I just really don't see how feature requests can be that > high a priority during a stable release. A day after the release when I get six mails, I would say that is high priority. Rahul From rawhide at fedoraproject.org Sat Jul 18 03:11:11 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sat, 18 Jul 2009 03:11:11 +0000 Subject: rawhide report: 20090717 changes Message-ID: <20090718031111.GA16045@releng2.fedora.phx.redhat.com> Compose started at Fri Jul 17 06:15:04 UTC 2009 New package adf-accanthis-fonts A ?modernized? garaldic serif typeface, ?Galliard? alternative New package apa-new-athena-unicode-fonts New Athena Unicode is a libre/open multilingual font New package cim-schema Common Information Model (CIM) Schema New package compat-libgdamm C++ wrappers for libgda New package compat-readline5 A library for editing typed command lines New package conakry-fonts N'Ko font by Michael Everson New package congruity Application to program Logitech Harmony universal remote controls New package dansguardian Content filtering web proxy New package gnujump A jumping game which is a clone of xjump New package gtg Personal organizer for the GNOME desktop New package hunspell-kn Kannada hunspell dictionaries New package ibus-table-array30 The Array 30 Chinese input method for ibus-table New package javanotes Introduction to Programming Using Java, By David J. Eck New package klavaro Typing tutor New package lpg LALR Parser Generator New package mediawiki-rss Displays an RSS feed on a mediawiki page New package moblin-gtk-engine GTK engine for Moblin New package mythes-hu Hungarian thesaurus New package netcf Cross-platform network configuration library New package olpc-switch-desktop OLPC desktop switching utilities New package pathfinder X.509 Path Discovery and Validation New package perl-TAP-Formatter-HTML TAP Test Harness output delegate for html output New package perl-accessors Create accessor methods in caller's package New package pothana2000-fonts Unicode compliant OpenType font for Telugu New package pypoppler Python bindings for the Poppler PDF rendering library New package python-kaa-display Python API providing Low level support for various displays New package python-repoze-who-plugins-sa The repoze.who SQLAlchemy plugin New package rubygem-state_machine Adds support for creating state machines for attributes on any Ruby class New package sendxmpp A perl script to send xmpp messages New package sipcalc An "advanced" console based ip subnet calculator New package solang A photo manager for GNOME New package spacewalk-proxy-docs Spacewalk Proxy Server Documentation New package unetbootin Create bootable Live USB drives for a variety of Linux distributions New package valide An integrated development environment (IDE) for the Vala programming language New package wacomexpresskeys Wacom ExpressKeys and Touch Strips configuration utility New package yokadi Command line oriented todo list system New package zikula-module-MultiHook MultiHook is a simple replacement for the old AutoLinks module for Zikula Removed package bchunk Removed package epel-release Removed package evolution-zimbra Removed package php-pecl-Fileinfo Removed package php-pecl-phar Updated Packages: NetworkManager-openvpn-0.7.1-1.git20090714.fc12 ----------------------------------------------- * Tue Jul 14 2009 Dan Williams - 1:0.7.1-1.20090714 - Fix a misconfiguration with 'subnet' topology - Fix detection of password requests by the OpenVPN management interface PyQt4-4.5.2-1.fc12 ------------------ * Thu Jul 16 2009 Rex Dieter - 4.5.2-1 - PyQt4-4.5.2 R-msm-0.9.1-2.fc12 ------------------ * Tue Jul 14 2009 Denis Arnaud 0.9.1-2 - Suppressed the unused definition of the packrel variable R-mvtnorm-0.9-7.fc12 -------------------- * Tue Jul 14 2009 Denis Arnaud - 0.9-7 - Update to 0.9-7 afpfs-ng-0.8.1-3.fc12 --------------------- * Tue Jul 14 2009 Lubomir Rintel - 0.8.1-3 - Fix up license tag alsa-tools-1.0.20-2.fc12 ------------------------ anjuta-2.27.3.0-1.fc12 ---------------------- * Tue Jul 14 2009 Debarshi Ray - 1:2.26.2.2-1 - Version bump to 2.26.2.2. * Git plugin: + Fixed a crash. (GNOME Bugzilla #584347) * Project manager plugin: + Fixed segmentation fault when adding a file to a project. (GNOME Bugzilla #579118) + Make gbf-am-parse work with subdirectory targets. (GNOME Bugzilla * Subversion plugin: + Do not show a commit number in the info pane if no files are given. + Do not crash if no paths are selected for committing. * Symbol-db plugin: + Fixed viewing of local symbols. + Plugged a memory leak that broke completion. (GNOME Bugzilla #585498) * Tools plugin: + Handle patch files with whitespaces in their names. (GNOME Bugzilla * http://ftp.gnome.org/pub/GNOME/sources/anjuta/2.26/anjuta-2.26.2.2.news * http://ftp.gnome.org/pub/GNOME/sources/anjuta/2.26/anjuta-2.26.2.1.news * http://ftp.gnome.org/pub/GNOME/sources/anjuta/2.26/anjuta-2.26.2.0.news - Explicitly set docdir to /usr/share/doc/anjuta-2.26.2.2. * Tue Jul 14 2009 Debarshi Ray - 1:2.26.2.2-2 - Fixed the value of PACKAGE_DOC_DIR. (GNOME Bugzilla #588506) * Tue Jul 14 2009 Debarshi Ray - 1:2.26.2.2-3 - Added patch against class generator plugin to fix wrong copyright and license notices. (GNOME Bugzilla #575147) * Tue Jul 14 2009 Debarshi Ray - 1:2.27.3.0-1 - Version bump to 2.27.3.0. Improvements in auto-completion speed. Improvements in Git and Subversion plugins. Ported to GtkBuilder. (GNOME Bugzilla #530740) * Git plugin: + Commit dialog should have the "amend" option. (GNOME Bugzilla #580340) * GTodo plugin: + Use g_timeout_add_seconds to reduce wakeups. (GNOME Bugzilla #582710) * Language support (C, C++, Java) plugin: + Fixed crash when dismissing auto-completion popup and deleting some characters. (GNOME Bugzilla #582464) * Project wizard plugin: + Infer project name from project path. (GNOME Bugzilla #568779) + wxWidget projects should not depend on libglade and Gtk+. (GNOME Bugzilla #581074) * Scintilla editor plugin: + Fixed position of tooltips. (GNOME Bugzilla #577721) * Search plugin: + Point to correct line number. (GNOME Bugzilla #576959) * http://ftp.gnome.org/pub/GNOME/sources/anjuta/2.26/anjuta-2.27.3.0.news * http://ftp.gnome.org/pub/GNOME/sources/anjuta/2.26/anjuta-2.27.2.0.news - Do not drop schemas translations from po files. - Replaced 'BuildRequires: e2fsprogs-devel' with 'BuildRequires: libuuid-devel'. - Removed 'Requires: libglade2 >= 2.6.3-2'. apanov-heuristica-fonts-20090507-1.fc12 --------------------------------------- * Tue Jul 14 2009 Nicolas Mailhot - 20090507-1 appliance-tools-004.4-2.fc12 ---------------------------- * Tue Jul 07 2009 David Huff -004.4 - added functionality include additional modules in ramdisk apr-1.3.6-1.fc12 ---------------- * Wed Jul 15 2009 Bojan Smojver - 1.3.6-1 - bump up to 1.3.6 apr-util-1.3.8-2.fc12 --------------------- * Wed Jul 15 2009 Bojan Smojver 1.3.7-5 - BR: +libuuid-devel, -e2fsprogs-devel * Wed Jul 15 2009 Bojan Smojver 1.3.8-1 - bump up to 1.3.8 * Wed Jul 15 2009 Bojan Smojver 1.3.8-2 - adjust apr-util-1.3.7-nodbmdso.patch arora-0.7.1-3.fc12 ------------------ * Thu Jul 16 2009 Jaroslav Reznik - 0.7.1-3 - Arora-gnome subpackage now requires Arora package audacious-2.1-1.fc12 -------------------- * Tue Jul 14 2009 Michael Schwendt - 2.1-1 - Upgrade to 2.1 final. * Mon Jun 29 2009 Michael Schwendt - 2.1-0.1.beta1 - Upgrade to 2.1beta1. - Drop obsolete patches. audacious-plugin-fc-0.3-4 ------------------------- * Sun Jun 07 2009 Michael Schwendt - 0.3-4 - Patch for Audacious 2. audacious-plugins-2.1-1.fc12 ---------------------------- * Tue Jul 14 2009 Michael Schwendt - 2.1-1 - Upgrade to 2.1 final. auriferous-1.0.1-8.fc12 ----------------------- * Wed Jul 15 2009 Hans de Goede 1.0.1-8 - Fix FTBFS caused by automake input file timestamp issues (#511454) autofs-5.0.4-34 --------------- * Fri Jul 17 2009 Ian Kent - 1:5.0.4-34 - fix typo in patch to allow dumping core. * Wed Jul 15 2009 Ian Kent - 1:5.0.4-32 - fix an RPC fd leak. - don't block signals we expect to dump core. - fix pthread push order in expire_proc_direct(). batik-1.7-5.fc12 ---------------- * Wed Jul 15 2009 Lillian Angel - 1.7-5 - Fixed javadocs issue. - Resolves: rhbz#511767 binutils-2.19.51.0.11-27.fc12 ----------------------------- * Tue Jul 14 2009 Nick Clifton 2.19.51.0.11-25 - Fix build-id patch to avoid memory corruption. (BZ 501582) * Tue Jul 14 2009 Nick Clifton 2.19.51.0.11-26 - Import orphan section placement patch from mainline. (BZ 510384) * Tue Jul 14 2009 Nick Clifton 2.19.51.0.11-27 - Add patch to allow moxie target to build, and hence --enable-targets=all to work. blktool-4-10.fc12 ----------------- * Thu Jul 16 2009 Jeff Garzik - 4-10 - specfile cleanups bltk-1.0.9-1.fc12 ----------------- * Tue Jul 14 2009 Jiri Skala 1.0.9-1 - merged with latest upstream sources bmake-20090222-1.fc12 --------------------- * Wed Jul 15 2009 Stepan Kasal - 20090222-1 - new upstream version bmpx-0.40.14-14.fc12 -------------------- * Tue Jul 14 2009 Caol?n McNamara - 0.40.14-14 - Resolves: rhbz#489552 fix to compile * Thu Mar 05 2009 josef radinger - 0.40.14-13 - needs even more - and i forgot to update the version-number * Tue Feb 24 2009 josef radinger - 0.40.14-11 - specfile merge * Tue Feb 24 2009 josef radinger - 0.40.14-12 - fix compile error because of missing header-file - but needs more * Mon Feb 23 2009 Fedora Release Engineering - 0.40.14-9 - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild * Mon Feb 23 2009 josef radinger - 0.40.14-10 - reenable cdparanoia bouncycastle-mail-1.43-2.fc12 ----------------------------- * Mon Jul 13 2009 Orcan Ogetbil - 1.43-2 - Re-enable AOT bits thanks to Andrew Haley. bouncycastle-tsp-1.43-3.fc12 ---------------------------- * Mon Jul 13 2009 Orcan Ogetbil - 1.43-3 - Re-enable AOT bits thanks to Andrew Haley. btrfs-progs-0.19-5.fc12 ----------------------- * Wed Jul 15 2009 Josef Bacik 0.19-4 - change BuildRequires for e2fsprogs-devel to libuuid-devel * Wed Jul 15 2009 Josef Bacik 0.19-5 - add e2fsprogs-devel back to BuildRequires since its needed for the converter calf-0.0.18.5-2.fc12 -------------------- * Mon Jul 13 2009 Orcan Ogetbil - 0.0.18.5-2 - Add a .desktop file for the DSSI plugin - Add X-Synthesis category to the existing .desktop file of the JACK plugin - Backport the LADSPA URI fix from trunk cdrkit-1.1.9-8.fc12 ------------------- * Thu Jul 16 2009 Nikola Pajkovsky 1.1.9-8 - fix buffer overflow * Fri Jul 10 2009 Adam Jackson 1.1.9-7 - Move dirsplit to a subpackage to isolate the perl dependency. * Mon Jun 15 2009 Roman Rakus - 1.1.9-6 - rename functions as they conflict with glibc - Don't push cdda2mp3 because we don't have any mp3 coder Resolves: #505918 * Tue Jun 02 2009 Roman Rakus - 1.1.9-5 - Added Requires vorbis-tools in icedax (rhbz #503699) clipper-2.1-8.20090714cvs.fc12 ------------------------------ * Tue Jul 14 2009 Tim Fenn - 2.1-8.20090714cvs - update to 090714 codeblocks-8.02-8.fc12 ---------------------- * Mon Jun 15 2009 Dan Hor?k 8.02-8 - fix gsocket between glib >= 2.21 and wxGTK in rawhide compat-wxGTK26-2.6.4-10.fc12 ---------------------------- * Wed Jul 15 2009 Michael Schwendt - 2.6.4-10 - apply rediffed fix for CVE-2009-2369 (#511279) control-center-2.27.4-1.fc12 ---------------------------- * Wed Jul 15 2009 Matthias Clasen - 2.27.4-1 - Update to 2.27.4 * Tue Jul 14 2009 Adel Gadllah - 2.27.3-3 - Reenable firefox options in the default applications capplet (RH #509565) cppcheck-1.34-1.fc12 -------------------- * Thu Jul 16 2009 Jussi Lehtola - 1.34-1 - Update to 1.34. cryptsetup-luks-1.0.7-0.2.fc12 ------------------------------ * Wed Jul 15 2009 Till Maas - 1.0.7-0.2 - update BR because of libuuid splitout from e2fsprogs csound-5.10.1-9.fc12 -------------------- * Thu Jul 16 2009 Peter Robinson - 5.10.1-8 - Apply patch to fix libcsnd.so * Thu Jul 16 2009 Peter Robinson - 5.10.1-9 - Update included files cups-1.4-0.rc1.10.fc12 ---------------------- * Wed Jul 15 2009 Tim Waugh 1:1.4-0.rc1.10 - Applied patch to prevent bad job control files crashing cupsd on start-up (STR #3253, bug #509741). - Correctly handle CUPS-Get-PPDs requests for models with '+' in their names (STR #3254, bug #509586). - Accept incorrect device URIs in the (non-libusb) usb backend for compatibility with Fedora 11 before bug #507244 was fixed. - Applied patch to fix incorrect device URIs (STR #3259, bug #507244). - Applied patch to fix job-hold-until for remote queues (STR #3258, bug #497376). cups-pk-helper-0.0.4-3.fc12 --------------------------- * Thu Jul 16 2009 Marek Kasik - 0.0.4-3 - Add devices_get() function. dbus-1.2.16-1.fc12 ------------------ * Tue Jul 14 2009 Colin Walters - 1:1.2.16-1 - Upstream 1.2.16 - Remove inotify patch, now upstreamed - Remove timeout patch, obsolete with upstream change to infinite timeout maximum by default devhelp-0.23-8.fc12 ------------------- * Wed Jul 15 2009 Matthew Barnes - 0.23-8 - Add patch for GNOME bug #588655 (work around GLib deprecations). directfb-1.4.1-1.fc12 --------------------- * Thu Jul 16 2009 kwizart < kwizart at gmail.com > - 1.4.1-1 - Update to 1.4.1 eclipse-dtp-1.7.0-3.fc12 ------------------------ * Tue Jul 14 2009 Mat Booth 1.7.0-3 - Disable jar repacking because of a bug in redhat-rpm-config, see #461854. - Update dependency on wsdl4j. * Sun Jul 05 2009 Mat Booth 1.7.0-2 - Build all features. - Add dependency on LPG. em8300-0.17.3-1.fc12 -------------------- * Thu Jul 16 2009 Felix Kaechele - 0.17.3-1 - new upstream version emelfm2-0.6.1-1.fc12 -------------------- * Fri Jul 17 2009 Christoph Wickert - 0.6.1-1 - Update 0.6.1 - Enable auto (un)mounting using devicekit-disks - Use new LIB_DIR option instead of PLUGINS_DIR - Build with "STRIP=0" instead of using nostrip.patch empathy-2.27.4-2.fc12 --------------------- * Thu Jul 16 2009 Matthias Clasen - 2.27.4-2 - Deal with some stubborn buttons * Wed Jul 15 2009 Brian Pepple - 2.27.4-1 - Update to 2.27.4. - See http://download.gnome.org/sources/empathy/2.27/empathy-2.27.4.news - Drop mission-control-convert patch. - Add BR on NetworkManager-glib-devel. eog-2.27.4-1.fc12 ----------------- * Tue Jul 14 2009 Matthias Clasen 2.27.4-1 - Update to 2.27.4 epiphany-2.27.4-1.fc12 ---------------------- * Mon Jul 13 2009 Matthias Clasen - 2.27.4-1 - Update to 2.27.4 epiphany-extensions-2.27.4-1.fc12 --------------------------------- * Tue Jul 14 2009 Matthias Clasen - 2.27.4-1 - Update to 2.27.4 ethtool-6-5.20090306git.fc12 ---------------------------- * Thu Jul 16 2009 Jeff Garzik 6-5.20090306git - minor specfile cleanups fig2ps-1.4.1-1.fc12 ------------------- * Wed Jul 15 2009 Stepan Kasal - 1.4.1-1 - new upstream version fldigi-3.11.6-1.fc12 -------------------- * Thu Jul 16 2009 Randall J. Berry 3.11.6-1 - Upstream upgrade to 3.11.6 - Remove fldigi-gcc44.patch (applied upstream) - Man pages added upstream fontforge-20090622-1.fc12 ------------------------- * Thu Jul 16 2009 Kevin Fenzi - 20090622-1 - Upgrade to 20090622 fuse-emulator-0.10.0.2-1.fc12 ----------------------------- * Wed Jul 15 2009 Lucian Langa - 0.10.0.2-1 - new upstream release g2clib-1.1.9-1.fc12 ------------------- * Thu Jul 16 2009 Orion Poplawski - 1.1.9-1 - Update to 1.1.9 gcalctool-5.27.4-1.fc12 ----------------------- * Tue Jul 14 2009 Matthias Clasen - 5.27.4-1 - Update ot 5.27.4 gearmand-0.8-1.fc12 ------------------- * Tue Jul 14 2009 Ruben Kerkhof 0.8-1 - Upstream released new version - Enable libmemcached backend gedit-2.27.2-2.fc12 ------------------- * Thu Jul 16 2009 Matthias Clasen - 1:2.27.2-2 - Make some stubborn buttons behave gifsicle-1.55-1.fc12 -------------------- * Thu Jul 16 2009 - Orion Poplawski - 1.55-1 - Update to 1.55 gimp-2.6.6-7.fc12 ----------------- * Thu Jul 16 2009 Nils Philippsen - 2:2.6.6-7 - rebuild against gegl-0.1 (#510209) gnome-applets-2.27.3-5.fc12 --------------------------- * Wed Jul 15 2009 Matthias Clasen - 1:2.27.3-5 - Rebuild against new libgnomekbd gnome-desktop-2.27.4-1.fc12 --------------------------- * Wed Jul 15 2009 Matthias Clasen - 2.27.4-1 - Update to 2.27.4 - Some EDID handling improvements gnome-menus-2.27.4-1.fc12 ------------------------- * Wed Jul 15 2009 Matthias Clasen 2.27.4-1 - Update to 2.27.4 gnome-panel-2.27.4-1.fc12 ------------------------- * Wed Jul 15 2009 Matthias Clasen - 2.27.4-1 - Update to 2.27.4 gnome-python2-desktop-2.27.2-1.fc12 ----------------------------------- * Tue Jul 14 2009 Matthew Barnes - 2.27.2-1.fc12 - Update to 2.27.2 gnome-screensaver-2.27.0-3.fc12 ------------------------------- * Wed Jul 15 2009 Matthias Clasen 2.27.0-3 - Rebuild against new libgnomekbd gnome-session-2.27.4-1.fc12 --------------------------- * Wed Jul 15 2009 Matthias Clasen - 2.27.4-1 - Update to 2.27.4 * Fri Jul 10 2009 Matthias Clasen - 2.26.1-5 - Avoid pointless warnings gnome-settings-daemon-2.27.4-2.fc12 ----------------------------------- * Wed Jul 15 2009 Matthias Clasen 2.27.4-2 - Rebuild against new libgnomekbd * Tue Jul 14 2009 Matthias Clasen 2.27.4-1 - Update ot 2.27.4 gnome-terminal-2.26.2-2.fc12 ---------------------------- * Wed Jul 15 2009 Matthias Clasen - 2.26.2-2 - Fix a stubborn icon gnonlin-0.10.11.2-0.1.fc12 -------------------------- * Thu Jul 16 2009 Jeffrey C. Ollie - 0.10.11.2-0.1 - Update to gnonlin prerelease. gnote-0.5.3-1.fc12 ------------------ * Wed Jul 15 2009 Rahul Sundaram - 0.5.3-1 - Few minor bug fixes - http://mail.gnome.org/archives/gnote-list/2009-July/msg00002.html gparted-0.4.5-2.fc12.1 ---------------------- gstreamer-0.10.23.2-1.fc12 -------------------------- * Thu Jul 16 2009 Bastien Nocera 0.10.23.2-1 - Update to 0.10.23.2 gstreamer-plugins-base-0.10.23.2-1.fc12 --------------------------------------- * Thu Jul 16 2009 Bastien Nocera 0.10.23.2-1 - Update to 0.10.23.2 gt-0.4-9.fc12 ------------- * Wed Jul 15 2009 Hans de Goede 0.4-9 - Add missing BR flex, fixing FTBFS (#511363) gtksourcecompletion-0.7.0-1.fc12 -------------------------------- * Tue Jul 14 2009 Michel Salim - 0.7.0-1 - Update to 0.7.0 gtkwave-3.2.1-2.fc12 -------------------- * Wed Jul 15 2009 Paul Howarth 3.2.1-2 - add upstream patch for crash on print to file (#511858) gtranslator-1.9.5-2.fc12 ------------------------ * Tue Jul 14 2009 Alexey Torkhov - 1.9.5-2 - Update for new gdl and requiring libuuid directly gucharmap-2.26.3.1-2.fc12 ------------------------- * Wed Jul 15 2009 Matthias Clasen - 2.26.3.1-2 - Fix some stubborn button images guile-1.8.7-1.fc12 ------------------ * Thu Jul 16 2009 Miroslav Lichvar - 5:1.8.7-1 - update to 1.8.7 gutenprint-5.2.3-6.fc12 ----------------------- * Wed Jul 15 2009 Tim Waugh 5.2.3-6 - Don't build CUPS PPDs (instead build a CUPS driver that can generate them). Fixes build (bug #511538). hal-info-20090716-1.fc12 ------------------------ * Thu Jul 16 2009 Richard Hughes - 20090716-1 - New upstream release to fix some more music players, resume problems and keymaps. See http://lists.freedesktop.org/archives/hal/2009-July/013481.html for full list. hamster-applet-2.27.4-1.fc12 ---------------------------- * Tue Jul 14 2009 Mads Villadsen - 2.27.4-1 - Update to latest development release - Better autocompletion - Better dbus-support - Export to different formats (TSV, XML, iCal) - Task filtering - Better statistics * Thu May 14 2009 Mads Villadsen - 2.27.1-1 - Update to latest development release - Remove pygtk2-libglade from Requires as hamster-applet has been ported to gtkbuilder hunspell-te-0.20050929-3.fc12 ----------------------------- * Fri Jul 17 2009 Parag - 0.20050929-3 - Use aspell source instead to pull source as BR:aspell-te - Resolves:rh#511262 buildrequires aspell-te hydrogen-0.9.4-0.4.rc1.1.fc12 ----------------------------- * Tue Jul 14 2009 Orcan Ogetbil - 0.9.4-0.4.rc1.1 - Rebuild against new lash build on F-12 due to the e2fsprogs split hyphen-hsb-0.20080619-2.fc12 ---------------------------- * Tue Jul 14 2009 Caolan McNamara - 0.20080619-2 - links doesn't have a -no-references mode anymore ibus-table-cangjie-1.2.0.20090717-2.fc12 ---------------------------------------- * Fri Jul 17 2009 Caius 'kaio' Chance - 1.2.0.20090717-1.fc12 - Rebuilt with IBus 1.2. * Fri Jul 17 2009 Caius 'kaio' Chance - 1.2.0.20090717-2.fc12 - Updated file list. ibus-table-wubi-1.2.0.20090715-1.fc12 ------------------------------------- * Wed Jul 15 2009 Caius 'kaio' Chance - 1.2.0.20090715-1.fc12 - Rebuilt with IBus version 1.2. icewm-1.2.37-1.fc12 ------------------- * Wed Jul 15 2009 Gilboa Davara - 1.2.37-1 - 1.2.37. - Fix missing directory ownership. (#511639) icu-4.2.1-2.fc12 ---------------- * Tue Jul 14 2009 Caolan McNamara - 4.2.1-2 - rpmlint warnings inn-2.5.0-3.fc12 ---------------- * Mon Jul 13 2009 Nikola Pajkovsky 2.5.0-3 - ugly sed script for file section was deleted and rewrite in classic style - fix init script(does not start correctly and shutdown when pid does not exist when service run) insight-6.8-8.fc12 ------------------ * Wed Jul 15 2009 Patrick Monnerat 6.8-8 - Fix bug #511501: combobox.tcl installed twice causes build failure. - Patch "readline6" to use system readline version 6. ipsec-tools-0.7.2-2.fc12 ------------------------ * Wed Jul 15 2009 Tomas Mraz - 0.7.2-2 - fix FTBFS (#511556) - fix some memory leaks and compilation warnings found by review jack_capture-0.9.35-1.fc12 -------------------------- * Wed Jul 15 2009 Orcan Ogetbil - 0.9.35-1 - Update to 0.9.35 jbrout-0.3.174-3.0.20090714svn223.1.fc12 ---------------------------------------- * Tue Jul 14 2009 Mat?j Cepl 0.3.174-3.0.20090714svn223.1 - Attempt to build a new upstream SVN checkout. Fixes bug 510642 - Remove unneeded files (*.exe, *.c) jfsutils-1.1.13-7.fc12 ---------------------- * Wed Jul 15 2009 Josh Boyer - 1.1.13-7 - Update for e2fsprogs package split-up jmol-11.6-11.11223svn.fc12 -------------------------- * Thu Jul 16 2009 Jussi Lehtola - 11.6-9.11223svn - Update to svn revision 11223. * Thu Jul 16 2009 Jussi Lehtola - 11.6-10.11223svn - Bump release to be able to rebuild in koji. * Thu Jul 16 2009 Jussi Lehtola - 11.6-11.11223svn - Include desktop file in the spec. kde-l10n-4.2.96-1.fc12 ---------------------- * Tue Jul 14 2009 Than Ngo - 4.2.96-1 - 4.3rc2 kdeaccessibility-4.2.96-1.fc12 ------------------------------ * Thu Jul 09 2009 Than Ngo - 4.2.96-1 - 4.3rc2 kdeadmin-4.2.96-1.fc12 ---------------------- * Thu Jul 09 2009 Than Ngo - 4.2.96-1 - 4.3rc2 kdebase-4.2.96-1.fc12 --------------------- * Thu Jul 09 2009 Than Ngo - 4.2.96-1 - 4.3rc2 kdebase-runtime-4.2.96-2.fc12 ----------------------------- * Thu Jul 16 2009 Rex Dieter - 4.2.96-2 - respin (soprano-2.3.0) - License: LGPLv2+ * Thu Jul 09 2009 Than Ngo - 4.2.96-1 - 4.3rc2 * Thu Jul 02 2009 Rex Dieter 4.2.95-3 - drop unneeded BR: ImageMagick (#509241) kdebase-workspace-4.2.96-1.fc12 ------------------------------- * Thu Jul 09 2009 Than Ngo - 4.2.96-1 - 4.3rc2 kdeedu-4.2.96-1.fc12 -------------------- * Fri Jul 10 2009 Than Ngo - 4.2.96-1 - 4.3rc2 kdegraphics-4.2.96-1.fc12 ------------------------- * Fri Jul 10 2009 Than Ngo - 4.2.96-1 - 4.3rc2 kdelibs-4.2.96-2.fc12 --------------------- * Thu Jul 16 2009 Rex Dieter - 4.2.96-2 - soprano_ver 2.3.0 - License: LGPLv2+ kdelibs-experimental-4.2.96-1.fc12 ---------------------------------- * Fri Jul 10 2009 Than Ngo - 4.2.96-1 - 4.3rc2 kdepim-4.2.96-1.fc12 -------------------- * Sat Jul 11 2009 Than Ngo - 4.2.96-1 - 4.3rc2 * Tue Jul 07 2009 Rex Dieter 4.2.95-2 - Requires: kdepim-runtime (< F-12) kdepimlibs-4.2.96-1.fc12 ------------------------ * Sat Jul 11 2009 Than Ngo - 4.2.96-1 - 4.3rc2 kdesvn-1.3.2-1.fc12 ------------------- * Thu Jul 16 2009 - Orion Poplawski - 1.3.2-1 - Update to 1.3.2 kernel-2.6.31-0.69.rc3.fc12 --------------------------- * Thu Jul 16 2009 Dave Airlie 2.6.31-0.69.rc3 - linux-2.6-vga-arb.patch - add VGA arbiter. - drm-vga-arb.patch - add VGA arbiter support to drm * Tue Jul 14 2009 Kyle McMartin 2.6.31-0.68-rc3 - 2.6.31-rc3 - config changes: - RTL8192SU is not set, (staging) knetstats-1.6.2-1.fc12 ---------------------- * Thu Jul 16 2009 Chitlesh Goorah - 1.6.2-1 - New upstream release kpackagekit-0.4.1.1-3.fc12 -------------------------- * Thu Jul 16 2009 Steven M. Parrish 0.4.1.1-3 - Now includes Sloval(sk) translations lash-0.5.4-6.fc12 ----------------- * Tue Jul 14 2009 Orcan Ogetbil - 0.5.4-6 - Build against libuuid on F-12 (e2fsprogs got split up) lasi-1.1.0-5.fc12 ----------------- * Tue Jul 14 2009 - Orion Poplawski - 1.1.0-5 - Fix font BR libXi-1.2.99-5.20090716.fc12 ---------------------------- * Thu Jul 16 2009 Peter Hutterer 1.2.99-5.20090716 - Update to today's git master libcmpiutil-0.5-1.fc12 ---------------------- * Wed Jul 15 2009 Kaitlin Rupert - 0.5-1 - Updated to official 0.5 source release libdrm-2.4.12-0.2.fc12 ---------------------- * Fri Jul 17 2009 Ben Skeggs 2.4.12-0.2 - rebase onto git snapshot libetpan-0.58-1.fc12 -------------------- * Wed Jul 15 2009 Andreas Bierfert - 0.58-1 - version upgrade libgnomekbd-2.27.4-1.fc12 ------------------------- * Wed Jul 15 2009 Matthias Clasen - 2.27.4-1 - Update to 2.27.4 libguestfs-1.0.61-1.fc12 ------------------------ * Wed Jul 15 2009 Richard W.M. Jones - 1.0.60-2 - Fix runtime Requires so they use epoch correctly. * Wed Jul 15 2009 Richard W.M. Jones - 1.0.61-1 - New upstream release 1.0.61. - New tool / subpackage 'virt-cat'. - New BR perl-libintl. * Tue Jul 14 2009 Richard W.M. Jones - 1.0.60-1 - New upstream release 1.0.60. libselinux-2.0.85-1.fc12 ------------------------ libsoup22-2.2.105-5.fc12 ------------------------ * Wed Jul 15 2009 Matthew Barnes - 2.2.105-5 - Add patch for RH bug #511673 (dprintf conflict). libunwind-0.99-0.11.20090430betagit4b8404d1.fc12 ------------------------------------------------ * Wed Jul 15 2009 Jan Kratochvil - 0.99-0.11.20090430betagit4b8404d1 - Disable the libunwind-setjmp library as no longer compatible with glibc and no Fedora dependencies on it (FTBSFS BZ 511562). libvirt-cim-0.5.6-1.fc12 ------------------------ * Tue Jul 14 2009 Kaitlin Rupert - 0.5.6-1 - Updated to latest upstream source libwnck-2.27.4-1.fc12 --------------------- * Wed Jul 15 2009 Matthias Clasen - 2.27.4-1 - Update to 2.27.4 libxcb-1.3-1.fc12 ----------------- * Tue Jul 14 2009 Adam Jackson 1.3-1 - libxcb 1.3 - List DSO versions explicitly. - Don't package any xprint bits. Seriously, no. limph-1.9.6-4.fc12 ------------------ * Tue Jul 14 2009 Jon Ciesla - 1.9.6-1 - New upstream to move from deprecated mhash to hash. - Dropped php-mhash requires. linux-libertine-fonts-4.4.1-1.fc12 ---------------------------------- * Tue Jul 14 2009 Kevin Fenzi - 4.4.1-1 - Upgrade to 4.4.1 - Fix to match current font guidelines * Sun Mar 15 2009 Nicolas Mailhot - 4.1.8-3 ? Make sure F11 font packages have been built with F11 fontforge * Wed Feb 25 2009 Fedora Release Engineering - 4.1.8-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild lordsawar-0.1.5-3.fc12 ---------------------- * Wed Jul 15 2009 Ian Weller - 0.1.5-3 - Fix build dependency on uuid.h lvm2-2.02.49-1.fc12 ------------------- * Wed Jul 15 2009 Alasdair Kergon - 2.02.49-1 - Exclude VG_GLOBAL from vg_write_lock_held so scans open devs read-only again. - Fix dev name mismatch in vgcreate man page example. - Check md devices for a partition table during device scan. - Add extended device (blkext) and md partition (mdp) types to filters. - Make text metadata read errors for segment areas more precise. - Fix text segment metadata read errors to mention correct segment name. - Include segment and LV names in text segment import error messages. - Fix memory leak in vgsplit when re-reading the vg. - Permit several segment types to be registered by a single shared object. - Update the man pages to document size units uniformly. - Allow commandline sizes to be specified in terms of bytes and sectors. - Update 'md_chunk_alignment' to use stripe-width to align PV data area. - Fix segfault in vg_release when vg->cmd is NULL. - Add dm_log_with_errno and dm_log_with_errno_init, deprecating the old fns. - Fix whitespace in linear target line to fix identical table line detection. - Add device number to more log messages during activation. * Fri Jul 10 2009 Fabio M. Di Nitto 2.02.48-2 - BuildRequires and Requires on stable versions of both corosync-lib (1.0.0-1) and cluster-lib (3.0.0-20). maniadrive-1.2-16.fc12 ---------------------- * Tue Jul 14 2009 Hans de Goede 1.2-16 - Rebuild for new php 5.3.0 mediawiki-1.15.1-48.fc12 ------------------------ * Mon Jul 13 2009 Axel Thimm - 1.15.1-48 - Update to 1.15.1 (Fixes XSS vulnerability). mingw32-wpcap-4.1.beta5-8.fc12 ------------------------------ * Wed Jul 15 2009 Thomas Sailer - 4.1.beta5-7 - fix BR * Wed Jul 15 2009 Thomas Sailer - 4.1.beta5-8 - fix BR minicom-2.3-5.fc12 ------------------ * Thu Jul 16 2009 Miroslav Lichvar 2.3-5 - rename getline to avoid conflict with glibc (#511715) - remove makefiles from docs - drop wchar patch mk-files-20081111-1.fc12 ------------------------ * Wed Jul 15 2009 Stepan Kasal - 20081111-1 - new upstream version mojito-0.18.1-1.fc12 -------------------- moreutils-0.36-1.fc12 --------------------- * Thu Jul 16 2009 Marc Bradshaw 0.36-1.fc12 - new upstream version 0.36 released with these changes - * parallel: New program, contributed by Tollef Fog Heen, that can run multiple jobs in parallel, optionally checking load average. - * mispipe: Fix closing of extra pipe FD before starting command so it is not inherited by daemons. Closes: #533448 (Thanks, Jeremie Koenig) nagios-3.1.2-2.fc12 ------------------- * Wed Jul 15 2009 Mike McGrath 3.2.1-2 - Release bump for rebuild * Mon Jun 29 2009 Robert M. Albrecht 3.2.1-1 - Upstream released a new version * Mon Jun 22 2009 Mike McGrath - 3.0.6-4 - Removing httpd requires for #487411 nautilus-open-terminal-0.13-1.fc12 ---------------------------------- * Tue Jul 14 2009 Paul W. Frields - 0.13-1 - Update to upstream 0.13 netatalk-2.0.4-1.fc12 --------------------- * Tue Jul 14 2009 Jiri Skala - 4:2.0.4-1 - updated to latest upstream version netcdf-perl-1.2.4-1.fc12 ------------------------ * Wed Jul 15 2009 Orion Poplawski - 1.2.4-1 - Update to 1.2.4, fixes build issue (bug #511613) nmap-5.00-1.fc12 ---------------- * Fri Jul 17 2009 Michal Hlavinka - 2:5.0-1 - updated to 5.0 * Wed Jul 15 2009 Michal Hlavinka - 2:4.90-0.RC1 - updated to 4.90RC1 nspluginwrapper-1.3.0-7.fc12 ---------------------------- * Wed Jul 15 2009 Martin Stransky 1.3.0-6 - Package kit plugin is ignored now (#511385) * Wed Jul 15 2009 Martin Stransky 1.3.0-7 - NPIdentifiers fix by Tristan Schmelcher (Google) obexd-0.15-1.fc12 ----------------- * Thu Jul 16 2009 Bastien Nocera 0.15-1 - Update to 0.15 ocaml-libvirt-0.6.1.0-5.fc12 ---------------------------- * Wed Jul 15 2009 Richard W.M. Jones - 0.6.1.0-5 - Force rebuild to test FTBFS issue. opencv-1.1.0-0.3.pre1.fc12 -------------------------- * Thu Jul 16 2009 kwizart < kwizart at gmail.com > - 1.1.0-0.2.pre1 - Fix FTBFS #511705 * Thu Jul 16 2009 kwizart < kwizart at gmail.com > - 1.1.0-0.3.pre1 - Build with gstreamer support - #491223 - Backport gcc43 fix from trunk openhpi-2.14.0-3.fc12 --------------------- * Tue Jul 14 2009 Dan Horak - 2.14.0-3 - add BR: libuuid-devel openoffice.org-3.1.1-15.2.fc12 ------------------------------ * Thu Jul 16 2009 Caol?n McNamara - 1:3.1.1-15.2 - add workspace.vcl103.patch - mythes-hu available - Resolves(maybe): rhbz#510327 openoffice.org-3.1.0.oooXXXXX.svx.64bit.patch oprofile-0.9.4-12.fc12 ---------------------- * Thu Jul 16 2009 Will Cohen - 0.9.4-12 - Add shadow-utils to requires. Resolves: rhbz #501357 - Add LGPL license to provided java support. Resolves: rhbz #474666 - Correct handling of --verbose. Resolves: rhbz #454969 pam_ssh-1.97-1.fc12 ------------------- * Wed Jul 15 2009 Dmitry Butskoy - 1.97-1 - update to 1.97 - drop no more needed patches - specfile cleanup - run autoreconf to re-libtoolize properly pdfchain-0.123-1.fc12 --------------------- * Thu Jul 16 2009 Jussi Lehtola - 0.123-1 - Update to 0.123. perl-AnyEvent-4.820-1.fc12 -------------------------- * Wed Jul 15 2009 kwizart < kwizart at gmail.com > - 4.820-1 - Update to 4.82 (rpm version : 4.820 perl-Bio-Graphics-1.97-1.fc12 ----------------------------- * Thu Jul 16 2009 Alex Lancaster - 1.97-1 - Update to latest upstream (1.97) to fix FTBFS (#511633) and disable tests temporarily (reported upstream: http://rt.cpan.org/Public/Bug/Display.html?id=47935) perl-SystemPerl-1.330-1.fc12 ---------------------------- * Wed Jul 15 2009 Chitlesh GOORAH < chitlesh [AT] fedoraproject DOT org > 1.330-1 - uint_t bug file #RHBZ 511400 - Header Include Bug - New upsteam release perl-Template-Plugin-Class-0.14-1.fc12 -------------------------------------- * Wed Jul 15 2009 Paul Howarth - 0.14-1 - Update to 0.14 (fixes FTBFS #511438) - No README in upstream distribution this time pg_top-3.6.2-5.fc12 ------------------- * Wed Jul 15 2009 Itamar Reis Peixoto - 3.6.2-5 - fix buildrequires, systemtap-sdt-devel is required for php-5.3.0-4.fc12 ---------------- * Thu Jul 16 2009 Joe Orton 5.3.0-3 - update to v6 of systzdata patch; various fixes * Thu Jul 16 2009 Joe Orton 5.3.0-4 - rediff systzdata patch * Tue Jul 14 2009 Joe Orton 5.3.0-2 - update to v5 of systzdata patch; parses zone.tab and extracts timezone->{country-code,long/lat,comment} mapping table php-eaccelerator-0.9.6-0.1.svn358.fc12 -------------------------------------- * Tue Jul 14 2009 Remi Collet - 1:0.9.6-0.1.svn358 - rebuild for new PHP 5.3.0 ABI (20090626) - update to latest SVN snapshot - remove shared-memory, sessions and content-caching options php-pear-Net-SMTP-1.3.3-1.fc12 ------------------------------ * Tue Jul 14 2009 Remi Collet 1.3.3-1 - update to 1.3.3 - rename Net_SMTP.xml to php-pear-Net-SMTP.xml pidgin-latex-1.3.2-1.fc12 ------------------------- * Thu Jul 16 2009 Jussi Lehtola - 1.3.2-1 - Update to 1.3.2. pygrace-0.4-1.fc12 ------------------ * Thu Jul 16 2009 Jussi Lehtola - 0.4-1 - Update to 0.4. pykickstart-1.58-1.fc12 ----------------------- * Fri Jul 17 2009 Chris Lumens - 1.58-1 - Adjust writePriority to fix lvm-on-raid0 test cases (jlaska). - Add F12 to the version number tests. (clumens) - F12_User test case. (dcantrell) - Add --gecos argument to the 'user' command (dcantrell) - Convert user.py to use _getArgsAsStr() (dcantrell) pyparted-2.1.0-1.fc12 --------------------- * Thu Jul 16 2009 David Cantrell - 2.1.0-1 - Upgrade to pyparted-2.1.0, requires parted-1.9.0-1 or higher python-peak-rules-0.5a1.dev-8.2582.fc12 --------------------------------------- * Tue Jul 14 2009 Kyle VanderBeek - 0.5a1.dev-8.2582 - SVN r2600 to fix python 2.6 deprecation warnings from BitmapIndex python-setuptools-0.6c9-4.fc12 ------------------------------ * Tue Jul 14 2009 Konstantin Ryabitsev - 0.6c9-4 - Apply SVN-1.6 versioning patch (rhbz #511021) python-tftpy-0.4.6-4.fc12 ------------------------- * Wed Jul 15 2009 John A. Khvatov - 0.4.6-4 - Delete unnecessary excludes *.pyc, *.pyo files in bindir qbittorrent-1.4.0-0.5.20090715svn.fc12 -------------------------------------- * Wed Jul 15 2009 Leigh Scott - 1.4.0-0.5.20090715svn - update to svn 2385 qemu-0.10.50-12.kvm88.fc12 -------------------------- * Thu Jul 16 2009 Mark McLoughlin - 2:0.10.50-11.kvm88 - Update to kvm-88, see http://www.linux-kvm.org/page/ChangeLog - Package mutiboot.bin - Update for how extboot is built - Fix sf.net source URL - Drop qemu-fix-ppc-softmmu-kvm-disabled-build.patch - Drop qemu-fix-pcspk-build-with-kvm-disabled.patch - Cherry-pick fix for esound support build failure * Thu Jul 16 2009 Daniel P. Berrange - 2:0.10.50-12.kvm88 - Add 'qemu' user and group accounts - Force disable xen until it can be made to build * Wed Jul 15 2009 Daniel Berrange - 2:0.10.50-10.kvm87 - Add udev rules to make /dev/kvm world accessible & group=kvm (rhbz #497341) - Create a kvm group if it doesn't exist (rhbz #346151) qt-creator-1.2.1-1.fc12 ----------------------- * Tue Jul 14 2009 Itamar Reis Peixoto - 1.2.1-1 - new version 1.2.1 quagga-0.99.12-2.fc12 --------------------- * Tue Jul 14 2009 Jiri Skala - 0.99.12-2 - replaced Obsoletes by Conflicts qzion-0.4.0-2.fc12 ------------------ * Thu Jul 16 2009 John5342 0.4.0-2 - Fix char* conversion (#511583) ratpoison-1.4.4-4.fc12 ---------------------- * Tue Jul 14 2009 Kevin Fenzi - 1.4.4-4 - Add libXi-devel to BuildRequires readahead-1.4.9-2.fc12 ---------------------- * Wed Jul 15 2009 Harald Hoyer 1.4.9-2 - add libblkid-devel BuildRequirement readline-6.0-1.fc12 ------------------- * Tue Jul 14 2009 Miroslav Lichvar 6.0-1 - update to 6.0 - include patches 001, 002, 003 rednotebook-0.7.6-1.fc12 ------------------------ * Wed Jul 15 2009 Fabian Affolter - 0.7.6-1 - Updated to new upstream version 0.7.6 rest-0.5-1.fc12 --------------- * Tue Jul 14 2009 Peter Robinson 0.5-1 - Update to 0.5 roundcubemail-0.2.2-2.fc12 -------------------------- * Wed Jul 15 2009 Jon Ciesla = 0.2.2-2 - Incorporated Chris Eveleigh's config changes to fix mimetype bug, BZ 511857. rsyslog-4.2.0-1.fc12 -------------------- * Tue Jul 14 2009 Tomas Heinrich 4.2.0-1 - upgrade rubygem-RedCloth-4.1.9-5.fc12 ----------------------------- * Tue Jul 14 2009 Darryl Pierce - 4.1.9-5 - Resolves: rhbz#505589 - rubygem-RedCloth-debuginfo created from stripped binaries safecopy-1.4-1.fc12 ------------------- * Fri Jul 17 2009 Fabian Affolter - 1.4-1 - Updated to new upstream version 1.4 samba-3.4.0-0.40.fc12 --------------------- * Fri Jul 03 2009 Guenther Deschner - 3.4.0-0.40 - Update to 3.4.0 * Fri Jun 19 2009 Guenther Deschner - 3.4.0rc1-0.39 - Update to 3.4.0rc1 * Mon Jun 08 2009 Guenther Deschner - 3.4.0pre2-0.38 - Update to 3.4.0pre2 selinux-policy-3.6.22-1.fc12 ---------------------------- * Tue Jul 14 2009 Dan Walsh 3.6.22-1 - Update to upstream * Fri Jul 10 2009 Dan Walsh 3.6.21-4 - Allow clamscan read amavis spool files sems-1.1.1-2.fc12 ----------------- * Wed Jul 15 2009 J?n ONDREJ (SAL) - 1.1.1-2 - disabled py_sems (python) subpackage until upstream fixes sip-4.8 compatibility * Sat Jul 11 2009 Peter Lemenkov 1.1.1-1 - Ver. 1.1.1 setroubleshoot-2.2.14-1.fc12 ---------------------------- * Wed Jul 15 2009 Dan Walsh - 2.2.14-1 - Update to upstream 2009-7-15 Dan Walsh - Fix handling of syscall record a1 field - Translate "/" to mountpoint when returned by kernel shadow-utils-4.1.4.1-4.fc12 --------------------------- * Thu Jul 16 2009 Peter Vrabec 2:4.1.4.1-3 - reduce the reuse of system IDs * Thu Jul 16 2009 Peter Vrabec 2:4.1.4.1-4 - fix a list of owned directories (#510366) * Wed Jul 15 2009 Peter Vrabec 2:4.1.4.1-2 - speed up sys users look up on LDAP boxes (#511813) slapi-nis-0.17-3.fc12 --------------------- * Wed Jul 15 2009 Nalin Dahyabhai - 0.17-3 - change buildreq from fedora-ds-base-devel to 389-ds-base-devel, which should avoid multilib conflicts from installing both arches of the new package (#511504) * Tue Jul 14 2009 Nalin Dahyabhai - 0.17-2 - fixup changelog entries that resemble possible macro invocations soprano-2.3.0-1.fc12 -------------------- * Thu Jul 16 2009 Rex Dieter - 2.3.0-1 - soprano-2.3.0 - upstream dropped virtuoso backend ): supybot-meetbot-0.1.2-1.fc12 ---------------------------- * Wed Jul 15 2009 Kevin Fenzi - 0.1.2-1 - Update to 0.1.2 release. syck-0.61-8.3.fc12 ------------------ * Tue Jul 14 2009 Remi Collet - 0.61-8.3 - rebuild for new PHP 5.3.0 ABI (20090626) - add syck-nan.patch tar-1.22-5.fc12 --------------- * Thu Jul 16 2009 Ondrej Vasik 2:1.22-5 - Fix restoring of directory default acls(#511145) - Do not patch generated autotools files taskjuggler-2.4.3-1 ------------------- * Thu Jul 16 2009 Ondrej Vasik - 2.4.3-1 - New upstream release 2.4.3 tasks-0.16-1.fc12 ----------------- * Wed Jul 15 2009 Dan Young - 0.16-1 - New upstream release - Drop libsexy-devel BR, as SexyIconEntry is no longer used testdisk-6.11-4.fc12 -------------------- * Wed Jul 15 2009 Christophe Grenier 6.11-4 - Add "BuildRequires: libuuid-devel" texmaker-1.9.2-1.fc12 --------------------- * Fri Jul 17 2009 Deji Akingunola - 1.9.2-1 - New Release tig-0.14.1-2.fc12 ----------------- * Tue Jul 14 2009 Todd Zullinger - 0.14.1-2 - Temporarily disable asciidoc's safe mode until bug 506953 is fixed tomoe-gtk-0.6.0-9.fc12 ---------------------- * Thu Jul 16 2009 Ding-Yi Chen - 0.6.0-9 - Add back autoconf, automake to fix RH Bug 499880: tomoe-gtk not built with $RPM_OPT_FLAGS trac-mercurial-plugin-0.11.0.7-4.20090715svn8072.fc12 ----------------------------------------------------- * Wed Jul 15 2009 Jesse Keating - 0.11.0.7-3.20090715svn8072 - New upstream snapshot to work with mercurial-1.2 * Wed Jul 15 2009 Jesse Keating - 0.11.0.7-4.20090715svn8072 - Update tarball generation steps trac-spamfilter-plugin-0.2.1-0.5.20090714svn8330.fc12 ----------------------------------------------------- * Tue Jul 14 2009 Paul Howarth - 0.2.1-0.5.20090714svn8330 - Update to rev8330, addresses upstream tickets #6130, #7627, #8032, #8121, #8257 udev-145-1.fc12 --------------- * Tue Jul 14 2009 Harald Hoyer 145-1 - version 145 - add "udevlog" kernel command line option to redirect the output of udevd to /dev/.udev/udev.log vala-0.7.4-2.fc12 ----------------- * Tue Jul 14 2009 Michel Salim - 0.7.4-2 - Patch broken ModuleInit attribute (upstream bug 587444) vdradmin-am-3.6.4-3.fc12 ------------------------ * Wed Jul 15 2009 Ville Skytt? - 3.6.4-3 - Add dependency on TT JavaScript plugin, some templates use it. webkitgtk-1.1.11-1.fc12 ----------------------- * Mon Jul 13 2009 Matthias Clasen - 1.1.11-1 - Update to 1.1.11 wesnoth-1.6.4-2.fc12 -------------------- * Fri Jul 10 2009 Jon Ciesla - 1.6.4-2 - Fribidi patch, BZ 504526. wgrib2-1.7.8j-1.fc12 -------------------- * Thu Jul 16 2009 Orion Poplawski - 1.7.8j-1 - Update to 1.7.8j - Drop flags patch, can now pass flags to make wise2-2.2.0-6.fc12 ------------------ * Thu Jul 16 2009 Alex Lancaster - 2.2.0-6 - Add -D_POSIX_C_SOURCE=200112L to CFLAGS as a workaround to fix FTBFS (#511627) wxGTK-2.8.10-3.fc12 ------------------- * Wed Jul 15 2009 Dan Hor?k - 2.8.10-3 - add fix for CVE-2009-2369 (#511279) x86info-1.24-1.42.fc12 ---------------------- * Tue Jul 14 2009 Adam Jackson - Fix parallel build. xcb-util-0.3.5-1.fc12 --------------------- * Mon Jul 13 2009 Adam Jackson 0.3.5-1 - xcb-util 0.3.5 xchat-2.8.6-9.fc12 ------------------ * Thu Jul 16 2009 Kevin Kofler - 1:2.8.6-9 - Fix literal underscore in "C_onnect" button (#512034, Matthias Clasen) xgridfit-1.19-1.b.fc12 ---------------------- * Tue Jul 14 2009 Nicolas Mailhot - 1.19-1.b ? Rework to use upstream makefile now there is one xorg-x11-drv-acecad-1.3.0-2.fc12 -------------------------------- * Thu Jul 16 2009 Peter Hutterer 1.3.0-2 - acecad-1.3.0-abi.patch: cope with XINPUT ABI 7. * Wed Jul 15 2009 Adam Jackson - 1.3.0-1.1 - ABI bump xorg-x11-drv-aiptek-1.2.0-2.fc12 -------------------------------- * Thu Jul 16 2009 Peter Hutterer 1.2.0-2 - aiptek-1.2.0-abi.patch: cope with XINPUT ABI 7. * Wed Jul 15 2009 Adam Jackson - 1.2.0-1.1 - ABI bump xorg-x11-drv-apm-1.2.1-3.fc12.1 ------------------------------- * Wed Jul 15 2009 Adam Jackson - 1.2.1-3.1 - ABI bump xorg-x11-drv-ast-0.87.0-3.fc12.1 -------------------------------- * Wed Jul 15 2009 Adam Jackson - 0.87.0-3.1 - ABI bump xorg-x11-drv-ati-6.12.2-19.fc12.1 --------------------------------- * Wed Jul 15 2009 Adam Jackson - 6.12.2-19.1 - ABI bump xorg-x11-drv-cirrus-1.3.1-1.fc12.1 ---------------------------------- * Wed Jul 15 2009 Adam Jackson - 1.3.1-1.1 - ABI bump xorg-x11-drv-dummy-0.3.2-1.fc12.1 --------------------------------- * Wed Jul 15 2009 Adam Jackson - 0.3.2-1.1 - ABI bump xorg-x11-drv-elographics-1.2.3-3.fc12 ------------------------------------- * Fri Jul 17 2009 Peter Hutterer - 1.2.3-3 - elographics-1.2.3-abi.patch: Cope with XINPUT ABI 7. * Wed Jul 15 2009 Adam Jackson - 1.2.3-2.1 - ABI bump xorg-x11-drv-evdev-2.2.99-3.20090629.fc12.1 ------------------------------------------- * Wed Jul 15 2009 Adam Jackson - 2.2.99-3.20090629.1 - ABI bump xorg-x11-drv-fbdev-0.4.0-5.fc12.1 --------------------------------- * Wed Jul 15 2009 Adam Jackson - 0.4.0-5.1 - ABI bump xorg-x11-drv-fpit-1.3.0-3.fc12 ------------------------------ * Fri Jul 17 2009 Peter Hutterer - 1.3.0-3 - fpit-1.3.0-abi.patch: Cope with XINPUT ABI 7. * Wed Jul 15 2009 Adam Jackson - 1.3.0-2.1 - ABI bump xorg-x11-drv-geode-2.11.2-2.fc12.1 ---------------------------------- * Wed Jul 15 2009 Adam Jackson - 2.11.2-2.1 - ABI bump xorg-x11-drv-glint-1.2.3-1.fc12.1 --------------------------------- * Wed Jul 15 2009 Adam Jackson - 1.2.3-1.1 - ABI bump xorg-x11-drv-hyperpen-1.3.0-2.fc12 ---------------------------------- * Fri Jul 17 2009 Peter Hutterer - 1.3.0-2 - hyperpen-1.3.0-abi.patch: Cope with XINPUT ABI 7. * Wed Jul 15 2009 Adam Jackson - 1.3.0-1.1 - ABI bump xorg-x11-drv-i128-1.3.2-1.fc12.1 -------------------------------- * Wed Jul 15 2009 Adam Jackson - 1.3.2-1.1 - ABI bump xorg-x11-drv-i740-1.3.1-1.fc12.1 -------------------------------- * Wed Jul 15 2009 Adam Jackson - 1.3.1-1.1 - ABI bump xorg-x11-drv-intel-2.8.0-0.3.fc12 --------------------------------- * Wed Jul 15 2009 Matthias Clasen - 2.8.0-0.3 - Rebuild for new API * Tue Jul 14 2009 Adam Jackson 2.8.0-0.2 - Today's git snapshots (driver and gpu tools) - intel-2.7-dont-vsync-xv.patch: Drop, should be working now. xorg-x11-drv-keyboard-1.3.99-2.20090715.fc12.1 ---------------------------------------------- * Wed Jul 15 2009 Peter Hutterer 1.3.99-1.20090715 - Today's git snapshot. - keyboard-1.3.2-terminate.patch: Drop. * Wed Jul 15 2009 Peter Hutterer 1.3.99-2.20090715 - Rebuild, this time with the right tarball. * Wed Jul 15 2009 Adam Jackson - 1.3.99-2.20090715.1 - ABI bump xorg-x11-drv-mach64-6.8.1-1.fc12 -------------------------------- * Wed Jul 15 2009 Adam Jackson - 6.8.0-3.1 - ABI bump * Wed Jul 15 2009 Adam Jackson 6.8.1-1 - mach64 6.8.1 - mach64-6.8.1-defaultdepth.patch: Default to depth 16 (#472687) xorg-x11-drv-mga-1.4.10-2.fc12.1 -------------------------------- * Wed Jul 15 2009 Adam Jackson - 1.4.10-2.1 - ABI bump xorg-x11-drv-mouse-1.4.99-2.20090619.fc12.1 ------------------------------------------- * Wed Jul 15 2009 Adam Jackson - 1.4.99-2.20090619.1 - ABI bump xorg-x11-drv-mutouch-1.2.1-3.fc12 --------------------------------- * Fri Jul 17 2009 Peter Hutterer - 1.2.1-3.1 - mutouch-1.2.1-abi.patch: Cope with XINPUT ABI 7. * Wed Jul 15 2009 Adam Jackson - 1.2.1-2.1 - ABI bump xorg-x11-drv-neomagic-1.2.3-1.fc12.1 ------------------------------------ * Wed Jul 15 2009 Adam Jackson - 1.2.3-1.1 - ABI bump xorg-x11-drv-nouveau-0.0.14-3.20090717gitb1b2330.fc12 ----------------------------------------------------- * Fri Jul 17 2009 Ben Skeggs 0.0.14-2.20090717gitb1b2330 - build fixes for recent X changes * Fri Jul 17 2009 Ben Skeggs 0.0.14-3.20090717gitb1b2330 - somehow missed updated patches to go on top * Wed Jul 15 2009 Adam Jackson - 1:0.0.14-1.20090701git6d14327.1 - ABI bump xorg-x11-drv-nv-2.1.14-1.fc12.1 ------------------------------- * Wed Jul 15 2009 Adam Jackson - 2.1.14-1.1 - ABI bump xorg-x11-drv-openchrome-0.2.903-11.fc12.1 ----------------------------------------- * Wed Jul 15 2009 Adam Jackson - 0.2.903-11.1 - ABI bump * Thu Jun 18 2009 Xavier Bachelot - 0.2.903-11 - Update to latest snapshot (svn 751) : - Add support for VX800 integrated TMDS encoder. - Make sure Chrome9 chipsets use software rasterizer for 3D. - Various small fixes. - Add patch for VX855 support. - Add patch to fix cursor on secondary display. - Add patch to disable TMDS by default. xorg-x11-drv-penmount-1.4.0-3.fc12 ---------------------------------- * Fri Jul 17 2009 Peter Hutterer - 1.4.0-3 - penmount-1.4.0-abi.patch: Cope with XINPUT ABI 7. * Wed Jul 15 2009 Adam Jackson - 1.4.0-2.1 - ABI bump xorg-x11-drv-r128-6.8.0-3.fc12.1 -------------------------------- * Wed Jul 15 2009 Adam Jackson - 6.8.0-3.1 - ABI bump xorg-x11-drv-radeonhd-1.2.5-2.10.20090714git.fc12 ------------------------------------------------- * Wed Jul 15 2009 Hans Ulrich Niedermann - 1.2.5-2.10.20090714git - compile with DRI support again (add mesa-libGL-devel build requirement) * Tue Jul 14 2009 Hans Ulrich Niedermann - 1.2.5-2.9.20090714git - New snapshot (upstream commit bc42c63d0cf7756a9d31c16d68d1c33a9e225b83): For details, run git log. Short summary: - Build fixes - initial power management support - man page improvements - misc bugs fixes xorg-x11-drv-rendition-4.2.2-1.fc12.1 ------------------------------------- * Wed Jul 15 2009 Adam Jackson - 4.2.2-1.1 - ABI bump xorg-x11-drv-s3virge-1.10.3-1.fc12.1 ------------------------------------ * Wed Jul 15 2009 Adam Jackson - 1.10.3-1.1 - ABI bump xorg-x11-drv-savage-2.3.0-1.fc12.1 ---------------------------------- * Wed Jul 15 2009 Adam Jackson - 2.3.0-1.1 - ABI bump xorg-x11-drv-siliconmotion-1.7.2-1.fc12.1 ----------------------------------------- * Wed Jul 15 2009 Adam Jackson - 1.7.2-1.1 - ABI bump xorg-x11-drv-sis-0.10.1-3.fc12.1 -------------------------------- * Wed Jul 15 2009 Adam Jackson - 0.10.1-3.1 - ABI bump xorg-x11-drv-sisusb-0.9.2-1.fc12.1 ---------------------------------- * Wed Jul 15 2009 Adam Jackson - 0.9.2-1.1 - ABI bump xorg-x11-drv-synaptics-1.1.99-3.20090717.fc12 --------------------------------------------- * Fri Jul 17 2009 Peter Hutterer 1.1.99-3-20090717 - Update to today's git master. * Wed Jul 15 2009 Adam Jackson - 1.1.99-2.20090710.1 - ABI bump xorg-x11-drv-tdfx-1.4.2-1.fc12.1 -------------------------------- * Wed Jul 15 2009 Adam Jackson - 1.4.2-1.1 - ABI bump xorg-x11-drv-trident-1.3.2-1.fc12.1 ----------------------------------- * Wed Jul 15 2009 Adam Jackson - 1.3.2-1.1 - ABI bump xorg-x11-drv-v4l-0.2.0-2.fc12.1 ------------------------------- * Wed Jul 15 2009 Adam Jackson - 0.2.0-2.1 - ABI bump xorg-x11-drv-vesa-2.2.0-3.fc12.1 -------------------------------- * Wed Jul 15 2009 Adam Jackson - 2.2.0-3.1 - ABI bump xorg-x11-drv-vmmouse-12.6.4-2.fc12.1 ------------------------------------ * Wed Jul 15 2009 Adam Jackson - 12.6.4-2.1 - ABI bump xorg-x11-drv-vmware-10.16.0-4.fc12.1 ------------------------------------ * Wed Jul 15 2009 Adam Jackson - 10.16.0-4.1 - ABI bump xorg-x11-drv-void-1.2.0-2.fc12.1 -------------------------------- * Wed Jul 15 2009 Adam Jackson - 1.2.0-2.1 - ABI bump xorg-x11-drv-voodoo-1.2.2-1.fc12.1 ---------------------------------- * Wed Jul 15 2009 Adam Jackson - 1.2.2-1.1 - ABI bump xorg-x11-proto-devel-7.4-21.fc12 -------------------------------- * Thu Jul 16 2009 Adam Jackson 7.4-21 - randrproto 1.3.0 * Wed Jul 15 2009 Peter Hutterer 7.4-19 - renderproto 0.11 - inputproto 1.9.99.14 * Wed Jul 15 2009 Adam Jackson 7.4-20 - Clean up %install slightly. xorg-x11-server-1.6.99-14.20090715.fc12 --------------------------------------- * Wed Jul 15 2009 Peter Hutterer 1.6.99-13.20090715 - Today's git snapshot. * Wed Jul 15 2009 Adam Jackson 1.6.99-14.20090715 - Move PAM config file here from xdm. * Tue Jul 14 2009 Adam Jackson 1.6.99-12.20090714 - Today's git snapshot. - Drop the %pre script for Xorg, everyone ought to be migrated by now. * Fri Jul 10 2009 Peter Hutterer 1.6.99-11.20090710 - Today's git snapshot. - xserver-1.6.0-no-i810.patch: Drop. * Tue Jul 07 2009 Adam Jackson 1.6.99-10.20090707 - Today's git snapshot. - xserver-1.4.99-pic-libxf86config.patch: Drop. - xserver-1.4.99-document-fontpath-correctly.patch: Typo fixes. - libxf86config subpackages. xulrunner-1.9.1-3.fc12 ---------------------- * Mon Jul 13 2009 Jan Horak - 1.9.1-3 - Fixed wrong version of Firefox when loading 'about:' as location - Added patch to compile against latest GTK yakuake-2.9.6-1.fc12 -------------------- * Fri Jul 10 2009 Johan Cwiklinski 2.9.6-1 - 2.9.6 zile-2.3.9-1.fc12 ----------------- * Wed Jul 15 2009 Rakesh Pandit - 2.3.9-1 - Updated to 2.3.9 Summary: Added Packages: 37 Removed Packages: 5 Modified Packages: 258 Broken deps for i386 ---------------------------------------------------------- CodeAnalyst-gui-2.8.54-15.fc12.i586 requires libbfd-2.19.51.0.11-24.fc12.so R-RScaLAPACK-0.5.1-19.fc11.i586 requires openmpi-libs audacious-plugin-xmp-2.5.1-5.fc12.i586 requires libaudclient.so.1 clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) conky-1.7.1.1-1.fc12.i586 requires libaudclient.so.1 gauche-gl-0.4.4-4.fc11.i586 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.i586 requires gauche = 0:0.8.13 gedit-vala-0.4.1-2.fc11.i586 requires libgtksourcecompletion-1.0.so.1 kdebase-workspace-python-applet-4.2.96-1.fc12.i586 requires PyKDE4 >= 0:4.2.96 libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 limph-hostagent-1.9.6-4.fc12.noarch requires php-mhash perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) php-ZendFramework-1.7.7-2.fc11.noarch requires php-Fileinfo php-idn-1.2-5.fc12.i586 requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.i386 requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.i386 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.i586 requires libgeos-3.0.3.so qtparted-0.4.5-19.fc11.i586 requires libparted-1.8.so.8 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.i586 requires libpqxx-2.6.8.so springlobby-0.0.1.10461-1.fc12.i586 requires libtorrent-rasterbar.so.3 thunderbird-lightning-1.0-0.6.20090513hg.fc12.i586 requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 Broken deps for x86_64 ---------------------------------------------------------- CodeAnalyst-gui-2.8.54-15.fc12.i586 requires libbfd-2.19.51.0.11-24.fc12.so CodeAnalyst-gui-2.8.54-15.fc12.x86_64 requires libbfd-2.19.51.0.11-24.fc12.so()(64bit) R-RScaLAPACK-0.5.1-19.fc11.x86_64 requires openmpi-libs audacious-plugin-xmp-2.5.1-5.fc12.x86_64 requires libaudclient.so.1()(64bit) clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.x86_64 requires pkgconfig(clutter-0.8) conky-1.7.1.1-1.fc12.x86_64 requires libaudclient.so.1()(64bit) gauche-gl-0.4.4-4.fc11.x86_64 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.x86_64 requires gauche = 0:0.8.13 gedit-vala-0.4.1-2.fc11.x86_64 requires libgtksourcecompletion-1.0.so.1()(64bit) kdebase-workspace-python-applet-4.2.96-1.fc12.x86_64 requires PyKDE4 >= 0:4.2.96 libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.x86_64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 libprojectM-1.2.0-9.fc11.x86_64 requires libftgl.so.0()(64bit) limph-hostagent-1.9.6-4.fc12.noarch requires php-mhash perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) php-ZendFramework-1.7.7-2.fc11.noarch requires php-Fileinfo php-idn-1.2-5.fc12.x86_64 requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.x86_64 requires libgeos-3.0.3.so()(64bit) qtparted-0.4.5-19.fc11.x86_64 requires libparted-1.8.so.8()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.x86_64 requires libpqxx-2.6.8.so()(64bit) springlobby-0.0.1.10461-1.fc12.x86_64 requires libtorrent-rasterbar.so.3()(64bit) thunderbird-lightning-1.0-0.6.20090513hg.fc12.x86_64 requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 Broken deps for ppc ---------------------------------------------------------- R-RScaLAPACK-0.5.1-19.fc11.ppc requires openmpi-libs audacious-plugin-xmp-2.5.1-5.fc12.ppc requires libaudclient.so.1 clutter-cairo-0.8.2-3.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) conky-1.7.1.1-1.fc12.ppc requires libaudclient.so.1 gauche-gl-0.4.4-4.fc11.ppc requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.ppc requires gauche = 0:0.8.13 gedit-vala-0.4.1-2.fc11.ppc requires libgtksourcecompletion-1.0.so.1 kdebase-workspace-python-applet-4.2.96-1.fc12.ppc requires PyKDE4 >= 0:4.2.96 libchamplain-0.2.9-1.fc11.ppc requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc requires libftgl.so.0 libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) limph-hostagent-1.9.6-4.fc12.noarch requires php-mhash perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) php-ZendFramework-1.7.7-2.fc11.noarch requires php-Fileinfo php-idn-1.2-5.fc12.ppc requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.ppc requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.ppc requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.ppc requires libgeos-3.0.3.so qtparted-0.4.5-19.fc11.ppc requires libparted-1.8.so.8 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc requires libpqxx-2.6.8.so thunderbird-lightning-1.0-0.6.20090513hg.fc12.ppc requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 Broken deps for ppc64 ---------------------------------------------------------- R-RScaLAPACK-0.5.1-19.fc11.ppc64 requires openmpi-libs audacious-plugin-xmp-2.5.1-5.fc12.ppc64 requires libaudclient.so.1()(64bit) clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) conky-1.7.1.1-1.fc12.ppc64 requires libaudclient.so.1()(64bit) gedit-vala-0.4.1-2.fc11.ppc64 requires libgtksourcecompletion-1.0.so.1()(64bit) kdebase-workspace-python-applet-4.2.96-1.fc12.ppc64 requires PyKDE4 >= 0:4.2.96 libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) limph-hostagent-1.9.6-4.fc12.noarch requires php-mhash perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) php-ZendFramework-1.7.7-2.fc11.noarch requires php-Fileinfo php-idn-1.2-5.fc12.ppc64 requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.ppc64 requires libgeos-3.0.3.so()(64bit) python-mwlib-0.11.2-2.20090522hg2956.fc12.ppc64 requires LabPlot qtparted-0.4.5-19.fc11.ppc64 requires libparted-1.8.so.8()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc64 requires libpqxx-2.6.8.so()(64bit) thunderbird-lightning-1.0-0.6.20090513hg.fc12.ppc64 requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 From belegdol at gmail.com Sat Jul 18 08:09:48 2009 From: belegdol at gmail.com (Julian Sikorski) Date: Sat, 18 Jul 2009 10:09:48 +0200 Subject: orphaning goffice04 in fedora Message-ID: <4A61834C.1090401@gmail.com> Hi, given that F-9 went EOL and thus gchemutils requires the older goffice in none of the branches, I've decided to orphan it. Createrepo suggests that abiword is the only remaining user. I've CCed the maintainer and orphaned it in pkgdb. Regards, Julian From pbrobinson at gmail.com Sat Jul 18 08:51:49 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Sat, 18 Jul 2009 09:51:49 +0100 Subject: Review swaps Message-ID: <5256d0b0907180151r5f969000t81ea19015faab8f6@mail.gmail.com> Hi All, I have a couple of package reviews I'd like to swap some reviews with someone. They are: https://bugzilla.redhat.com/show_bug.cgi?id=511895 https://bugzilla.redhat.com/show_bug.cgi?id=506804 Cheers, Peter From xavier at bachelot.org Sat Jul 18 14:45:40 2009 From: xavier at bachelot.org (Xavier Bachelot) Date: Sat, 18 Jul 2009 16:45:40 +0200 Subject: Packages tracked by FEver that need to be updated In-Reply-To: <4A609F4A.2000701@fedoraproject.org> References: <200907102243.14776.opensource@till.name> <200907161952.47891.opensource@till.name> <4A609F4A.2000701@fedoraproject.org> Message-ID: <4A61E014.504@bachelot.org> Rahul Sundaram wrote: > It would be useful to have a dynamically generated webpage that shows > how close we are to upstream versions across different Fedora versions > similar to the distrowatch packages page. There is something doing that for perl packages at http://perl.biggerontheinside.net. Unfortunately, it's down at the moment, but I find this to be really useful. Regards, Xavier From caolanm at redhat.com Sat Jul 18 14:59:26 2009 From: caolanm at redhat.com (=?ISO-8859-1?Q?Caol=E1n?= McNamara) Date: Sat, 18 Jul 2009 15:59:26 +0100 Subject: Packages tracked by FEver that need to be updated In-Reply-To: <200907161952.47891.opensource@till.name> References: <200907102243.14776.opensource@till.name> <200907161952.47891.opensource@till.name> Message-ID: <1247929166.2751.333.camel@Vain> On Thu, 2009-07-16 at 19:52 +0200, Till Maas wrote: > On Saturday 11 July 2009 13:29:59 Rakesh Pandit wrote: > > > Thanks for nice work. I too mailed other some time back .. but did not > > recieved any mail back. May you share the program ;) > > My current code is available at > http://fedorapeople.org/gitweb?p=till/public_git/cnucnu.git;a=summary FWIW I stuck my own dubious hacky little script I use to keep track of the latest versions of packages I maintain, which include a lot of painfully upstream sequenced packages at http://people.redhat.com/caolanm/latestpackages/ if it helps anyone. C. From rawhide at fedoraproject.org Sat Jul 18 15:13:19 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sat, 18 Jul 2009 15:13:19 +0000 Subject: rawhide report: 20090718 changes Message-ID: <20090718151319.GA17434@releng2.fedora.phx.redhat.com> Compose started at Sat Jul 18 06:15:04 UTC 2009 New package 389-admin-console 389 Admin Server Management Console New package 389-adminutil Utility library for 389 administration New package 389-ds 389 Directory, Administration, and Console Suite New package 389-ds-console 389 Directory Server Management Console New package bchunk CD image format converter from .bin/.cue to .iso/.cdr New package cld Coarse locking daemon New package dracut-modules-olpc OLPC modules for dracut initramfs New package gdpc A program for visualising molecular dynamics simulations data New package olpc-contents OLPC contents manifest tools New package olpc-update OLPC system update tools New package perl-CGI-Application-Plugin-DebugScreen Add Debug support to CGI::Application New package perl-Proc-Simple Launch and control background processes New package psimedia Audio and video RTP services for Psi-like IM clients New package robotfindskitten A game/zen simulation. You are robot. Your job is to find kitten. New package rubygem-coderay Fast syntax highlighter engine for many programming languages New package surl A URL shortening command line tool New package xz LZMA compression utilities Removed package adminutil Removed package fedora-ds Removed package fedora-ds-admin Removed package fedora-ds-admin-console Removed package fedora-ds-base Removed package fedora-ds-console Removed package fedora-ds-dsgw Updated Packages: GMT-4.5.0-1.fc12 ---------------- * Fri Jul 17 2009 Orion Poplawski 4.5.0-1 - Update to 4.5.0 GMT-coastlines-2.0-1.fc12 ------------------------- * Fri Jul 17 2009 Orion Poplawski 2.0-1 - Update to 2.0 afpfs-ng-0.8.1-4.fc12 --------------------- * Fri Jul 17 2009 Lubomir Rintel - 0.8.1-4 - Don't refer to AppleTalk in Summary buildbot-0.7.11p1-1.fc12 ------------------------ * Fri Jul 17 2009 Gianluca Sforna - 0.7.11p1-1 - New upstream release - Change Source0 URI - Make tests optional chrony-1.23-6.20081106gitbe42b4.fc12 ------------------------------------ * Fri Jul 17 2009 Miroslav Lichvar 1.23-6.20081106gitbe42b4 - switch to editline - support arbitrary chronyc commands in init script clipper-2.1-9.20090714cvs.fc12 ------------------------------ * Thu Jul 16 2009 Tim Fenn - 2.1-9.20090714cvs - trim down patches, stick with upstream - add pkgconfig to buildrequires clutter-0.9.8-1.fc12 -------------------- * Fri Jul 17 2009 Bastien Nocera 0.9.6-2 - Patch from Owen Taylor to add gobject- introspection support to clutter (#512260) * Fri Jul 17 2009 Bastien Nocera 0.9.8-1 - Update to 0.9.8 conduit-0.3.16-1.fc12 --------------------- * Fri Jul 17 2009 Bernard Johnson - 0.3.16-1 - v 0.3.16 (bz #512406) - don't include TODO file (bz #510899) - remove defaults patch - remove cpu usage patch ctdb-1.0.87-1.fc12 ------------------ * Fri Jul 17 2009 : Version 1.0.87 - Add a new event "stopped" that is called when a node is stopped. - Documentation of the STOPPED flag and the stop/continue commands - Make it possible to start a node in STOPPED mode. - Add a new node flag : STOPPED and commands "ctdb stop" "ctdb continue" These commands are similar to "diasble/enable" but will also remove the node from the vnnmap, while disable only fails all ip addresses over. - tests for NFS , CIFS by martins - major updates to the init script by martins - Send gratious arps with a 1.1 second stride instead of a 1 second stride to workaround interesting "features" of common linux stacks. - Various test enhancements from martins: - additional other tests - add tests for grat arp generation, ping during failover, ssh and failover - New/updated tcp tickle tests and supprot functions - provide better debugging when a test fails - make ctdbd restarts more reliable in the tests - update the "wait bar" to make the wait progress in tests more obvious - various cleanups - when dispatching a message to a handler, make the message a real talloc object so that we can reparent the object in the tallic hierarchy. - document the ipreallocate command - Updates to enable/disable to use the ipreallocate command to block until the following ipreallocation has completed. - Update the main daemon and the tools to allow debug level to be a string instead of an integer. - Update the sysconfig file to show using string literals instead of numeric values for the debuglevels used. - If no debuglevel is specific, make "ctdb setdebug" show the available options. - When trying to allocate network packets, add explicit checks if the network transport has been shutdown before trying and failing, to make log messages easier to read. Add this extra check and logging to every plave packets are allocated. * Fri Jul 17 2009 Sumit Bose - 1.0.87-1 - Update to ctdb version 1.0.87 dracut-0.5-1.fc12 ----------------- * Fri Jul 17 2009 Harald Hoyer 0.5-1 - version 0.5 e2fsprogs-1.41.8-2.fc12 ----------------------- * Fri Jul 17 2009 Eric Sandeen 1.41.8-2 - Address some package review concerns (#225714) eclipse-egit-0.5.0-1.fc12 ------------------------- * Fri Jul 17 2009 Alexander Kurtakov 0.5.0-1 - Update to 0.5.0. eclipse-pydev-1.4.7-1.fc12 -------------------------- * Fri Jul 17 2009 Alexander Kurtakov 1:1.4.7-1 - Update to 1.4.7. Adds IronPython projects support. emacs-mew-6.2.51-3.fc12 ----------------------- * Fri Jul 17 2009 Akira TAGOH - 6.2.51-3 - Fix FTBFS issue. (#511618) emelfm2-0.6.1-2.fc12 -------------------- firefox-3.5.1-1.fc12 -------------------- * Fri Jul 17 2009 Christopher Aillon - 3.5.1-1 - Update to 3.5.1 firstaidkit-0.2.3-4.fc12 ------------------------ * Fri Jul 17 2009 Martin Sivak - 0.2.3-4 - Simple enhancement to the API (inreplyto) florence-0.4.2-1.fc12 --------------------- * Fri Jul 17 2009 Simon Wesp - 0.4.2-1 - New upstream release fluidsynth-1.0.9-2.fc12 ----------------------- * Fri Jul 17 2009 Orcan Ogetbil - 1.0.9-2 - Disable portaudio support. It somehow messes up jack. gallery2-2.3-14.fc12 -------------------- * Fri Jul 17 2009 Jon Ciesla - 2.3-14 - Upgrader patch, BZ 506983. - Removed extra slash from installer patch. gcc-4.4.0-14 ------------ * Fri Jul 17 2009 Jakub Jelinek 4.4.0-14 - update from gcc-4_4-branch - PRs c++/40740, libstdc++/40691, middle-end/40747 - fix ICE in gimplify_conversion (#511229, PR c++/40780) glib2-2.21.4-1.fc12 ------------------- * Fri Jul 17 2009 Matthias Clasen - 2.21.4-1 - Update to 2.21.4 gnome-python2-extras-2.25.3-6.fc12 ---------------------------------- * Fri Jul 17 2009 Matthew Barnes - 2.25.3-6 - Rebuild against newer gecko. gridengine-6.2u3-1.fc12 ----------------------- * Tue Jul 14 2009 - Orion Poplawski - 6.2u3-1 - Update to 6.2u3 - Drop ppc patch fixed upstream - Update rctemplates patch grubby-7.0.1-1.fc12 ------------------- * Fri Jul 17 2009 Jeremy Katz - 7.0.1-1 - Fix blkid usage (#124246) gtk2-2.17.5-1.fc12 ------------------ * Fri Jul 17 2009 Matthias Clasen - 2.17.5-1 - Update to 2.17.5 hdparm-9.16-1.fc12 ------------------ * Fri Jul 17 2009 Karsten Hopp 9.16-1 - update to 9.16, fixes disk spindowns ibus-table-erbi-1.2.0.20090717-1.fc12 ------------------------------------- * Fri Jul 17 2009 Caius Chance - 1.1.0.20090717-1.fc12 - Rebuilt with IBus 1.2. ibus-table-yong-1.2.0.20090717-1.fc12 ------------------------------------- * Fri Jul 17 2009 Caius 'kaio' Chance - 1.1.0.20090717-1.fc12 - Rebuilt with IBus 1.2. ikiwiki-3.1415-1.fc12 --------------------- * Fri Jul 17 2009 Thomas Moschny - 3.1415-1 - Update to 3.1415. kde-style-skulpture-0.2.3-1.fc12 -------------------------------- * Fri Jul 17 2009 Jaroslav Reznik - 0.2.3-1 - update to 0.2.3 (minor bug fixes) - removed F10 stuff * Mon Mar 30 2009 Jaroslav Reznik - 0.2.2-5 - add reference to ExcludeArch bug kdeartwork-4.2.96-1.fc12 ------------------------ * Thu Jul 09 2009 Than Ngo - 4.2.96-1 - 4.3.rc2 kdegames-4.2.96-1.fc12 ---------------------- * Fri Jul 10 2009 Than Ngo - 4.2.96-1 - 4.3rc2 kdemultimedia-4.2.96-1.fc12 --------------------------- * Sat Jul 11 2009 Than Ngo - 4.2.96-1 - 4.3rc2 kdenetwork-4.2.96-1.fc12 ------------------------ * Sat Jul 11 2009 Than Ngo - 4.2.96-1 - 4.3rc2 kdepim-runtime-4.2.96-1.fc12 ---------------------------- * Sat Jul 11 2009 Than Ngo - 4.2.96-1 - 4.3rc2 kdeplasma-addons-4.2.96-2.fc12 ------------------------------ * Thu Jul 16 2009 Rex Dieter - 4.2.96-2 - BR: libXcomposite-devel (lancelot eye-candy) * Sun Jul 12 2009 Than Ngo - 4.2.96-1 - 4.3rc2 kdesdk-4.2.96-1.fc12 -------------------- * Sun Jul 12 2009 Than Ngo - 4.2.96-1 - 4.3rc2 kmymoney2-0.9.3-3.fc12 ---------------------- * Fri Jul 17 2009 Rex Dieter - 0.9.3-3 - validate .desktop file - -libs unconditional - use %_isa where appropriate - optimize scriptlets libev-3.70-2.fc12 ----------------- * Fri Jul 17 2009 Michal Nowak - 3.70-1 - v3.7 - list libev soname explicitly * Fri Jul 17 2009 Michal Nowak - 3.70-2 - spec file change, which prevented uploading most recent tarball so the RPM was "3.70" but tarball was from 3.60 libpng10-1.0.47-1.fc12 ---------------------- * Fri Jul 17 2009 Paul Howarth 1.0.47-1 - update to 1.0.47 (changes to unknown chunk handling and documentation) limph-1.9.6-5.fc12 ------------------ * Fri Jul 17 2009 Jon Ciesla - 1.9.6-5 - Dropped php-mhash requires from subpackage. - Fixed EVR. . . man-pages-3.21-2.fc12 --------------------- * Fri Jul 17 2009 Ivana Varekova - 3.21-2 - fix major.3 man page mbuffer-20090628-1.fc12 ----------------------- * Fri Jul 17 2009 Fabian Affolter - 20090628-1 - Fixed license (since 20080910 GPLv3+) - Removed --enable-networking, is no longer needed - Added make install to install section - Added NEWS to doc and changed COPYRIGHT to LICENSE - Added macro for bin dir - Updated to new upstream version 20090628 mpfi-1.3.4-0.6.RC3.fc12 ----------------------- * Fri Jul 17 2009 Conrad Meyer - 1.3.4-0.6.RC3 - Add missing BR on texinfo. muse-1.0-0.7.rc3.fc12 --------------------- * Fri Jul 17 2009 Orcan Ogetbil 1:1.0-0.7.rc3 - Bugfix: muse doesn't start properly on x86_64 on F-11+. Backport glibc-2.10 patch from trunk - Remove BR: e2fsprogs-devel offlineimap-6.1.2-1.fc12 ------------------------ * Fri Jul 17 2009 Christoph H?ger - 6.1.2-1 - Update to latest version - remove patch -> upstream - fixes #510036 peppy-0.10.0-1.fc12 ------------------- * Fri Jul 17 2009 Simon Wesp - 0.10.0-1 - New upstream release perl-Glib-1.201-3.fc12 ---------------------- * Fri Jul 17 2009 Stepan Kasal - 1.201-3 - create devel subpackage, so that the main one does not require the whole perl-devel (#509419) perl-Wx-Perl-DataWalker-0.02-4.fc12 ----------------------------------- * Fri Jun 19 2009 Stepan Kasal 0.02-4 - rebuild php-ZendFramework-1.8.4-1.PL1.fc12 ---------------------------------- * Thu Jul 16 2009 Alexander Kahl - 1.8.4-1.PL1 - update to 1.8.4 patch 1 (it's about time!) - Requires php 5.1.4 -> 5.2.4 - list all files explicitly for easier future updates - incubator no more (Zend_Tool stable now) - Request now part of Controller - new components: Application, CodeGenerator, Crypt, Navigation, Reflection, Tag - Soap and Services require php-soap now plague-0.4.5.7-5.20090612cvs.fc12 --------------------------------- * Fri Jul 17 2009 Michael Schwendt - 0.4.5.7-5.20090612cvs - patch with fix from cvs (SSLConnection.py shutdown) psi-0.13-0.2.rc4.fc12 --------------------- * Fri Jul 17 2009 Sven Lankes 0.13-0.2.rc4 - 0.13 rc4 redhat-rpm-config-9.0.3-10.fc12 ------------------------------- * Fri Jul 17 2009 Bill Nottingham 9.0.3-10 - apply fedora 12 default buildflags sugar-implode-5-3.20090717.fc12 ------------------------------- * Fri Jul 17 2009 Fabian Affolter - 5-3.20090717 - Changed release because it's still a git checkout - Modified donwload script - Translation support will follow, I hope - Changed URL to new upstream location teg-0.11.2-20.fc12 ------------------ * Fri Jul 17 2009 josef radinger - 0.11.2-20 - fix and reenable help * Sat Jul 11 2009 josef radinger - 0.11.2-19 - fix and reenable help * Sat Jun 27 2009 josef radinger - 0.11.2-18 - disable help tucan-0.3.8-0.1.alpha.fc12 -------------------------- * Fri Jul 17 2009 Simon Wesp - 0.3.8-0.1.alpha - New upstream release - Close to tray as default RHBZ #502416 (feature request) - Upstream solved RHBZ #502437 (feature request) * Thu Mar 26 2009 Simon Wesp - 0.3.6-0.1.alpha - Initial package build * Thu Mar 26 2009 Simon Wesp - 0.3.6-0.2.alpha - Correct python_sitelib definition - honor timestamp of install in the Makefile via patch - add python as BR - Correct the binfile * Thu Mar 26 2009 Simon Wesp - 0.3.7-0.1.alpha - New upstream release ugene-1.5.1-1.fc12 ------------------ * Fri Jul 17 2009 Ivan Efremov - 1.5.1-1 - Upstream version change - Fix for lrelease removed due to upstream package changes xorg-x11-util-macros-1.2.2-1.fc12 --------------------------------- * Sat Jul 18 2009 Peter Hutterer 1.2.2-1 - util-macros 1.2.2 xulrunner-1.9.1.1-1.fc12 ------------------------ * Fri Jul 17 2009 Christopher Aillon - 1.9.1.1-1 - Update to 1.9.1.1 Summary: Added Packages: 17 Removed Packages: 7 Modified Packages: 60 Broken deps for i386 ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin CodeAnalyst-gui-2.8.54-15.fc12.i586 requires libbfd-2.19.51.0.11-24.fc12.so Miro-2.0.5-1.fc12.i586 requires gecko-libs = 0:1.9.1 R-RScaLAPACK-0.5.1-19.fc11.i586 requires openmpi-libs audacious-plugin-xmp-2.5.1-5.fc12.i586 requires libaudclient.so.1 blam-1.8.5-10.fc12.i586 requires gecko-libs = 0:1.9.1 clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) conky-1.7.1.1-1.fc12.i586 requires libaudclient.so.1 gauche-gl-0.4.4-4.fc11.i586 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.i586 requires gauche = 0:0.8.13 gedit-vala-0.4.1-2.fc11.i586 requires libgtksourcecompletion-1.0.so.1 gnome-python2-gtkmozembed-2.25.3-6.fc12.i586 requires gecko-libs = 0:1.9.1 gnome-web-photo-0.8-1.fc12.i586 requires gecko-libs = 0:1.9.1 kdebase-workspace-python-applet-4.2.96-1.fc12.i586 requires PyKDE4 >= 0:4.2.96 libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 mozvoikko-0.9.7-0.3.rc1.fc12.i586 requires gecko-libs = 0:1.9.1 pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.i586 requires xulrunner = 0:1.9.1 perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) perl-Gtk2-MozEmbed-0.08-6.fc12.1.i586 requires gecko-libs = 0:1.9.1 php-ZendFramework-1.8.4-1.PL1.fc12.noarch requires php-Fileinfo php-idn-1.2-5.fc12.i586 requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.i386 requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.i386 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.i586 requires libgeos-3.0.3.so qtparted-0.4.5-19.fc11.i586 requires libparted-1.8.so.8 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.i586 requires libpqxx-2.6.8.so springlobby-0.0.1.10461-1.fc12.i586 requires libtorrent-rasterbar.so.3 thunderbird-lightning-1.0-0.6.20090513hg.fc12.i586 requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 Broken deps for x86_64 ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin CodeAnalyst-gui-2.8.54-15.fc12.i586 requires libbfd-2.19.51.0.11-24.fc12.so CodeAnalyst-gui-2.8.54-15.fc12.x86_64 requires libbfd-2.19.51.0.11-24.fc12.so()(64bit) Miro-2.0.5-1.fc12.x86_64 requires gecko-libs = 0:1.9.1 R-RScaLAPACK-0.5.1-19.fc11.x86_64 requires openmpi-libs audacious-plugin-xmp-2.5.1-5.fc12.x86_64 requires libaudclient.so.1()(64bit) blam-1.8.5-10.fc12.x86_64 requires gecko-libs = 0:1.9.1 clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.x86_64 requires pkgconfig(clutter-0.8) conky-1.7.1.1-1.fc12.x86_64 requires libaudclient.so.1()(64bit) gauche-gl-0.4.4-4.fc11.x86_64 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.x86_64 requires gauche = 0:0.8.13 gedit-vala-0.4.1-2.fc11.x86_64 requires libgtksourcecompletion-1.0.so.1()(64bit) gnome-python2-gtkmozembed-2.25.3-6.fc12.x86_64 requires gecko-libs = 0:1.9.1 gnome-web-photo-0.8-1.fc12.x86_64 requires gecko-libs = 0:1.9.1 kdebase-workspace-python-applet-4.2.96-1.fc12.x86_64 requires PyKDE4 >= 0:4.2.96 libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.x86_64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 libprojectM-1.2.0-9.fc11.x86_64 requires libftgl.so.0()(64bit) mozvoikko-0.9.7-0.3.rc1.fc12.x86_64 requires gecko-libs = 0:1.9.1 pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.x86_64 requires xulrunner = 0:1.9.1 perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) perl-Gtk2-MozEmbed-0.08-6.fc12.1.x86_64 requires gecko-libs = 0:1.9.1 php-ZendFramework-1.8.4-1.PL1.fc12.noarch requires php-Fileinfo php-idn-1.2-5.fc12.x86_64 requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.x86_64 requires libgeos-3.0.3.so()(64bit) qtparted-0.4.5-19.fc11.x86_64 requires libparted-1.8.so.8()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.x86_64 requires libpqxx-2.6.8.so()(64bit) springlobby-0.0.1.10461-1.fc12.x86_64 requires libtorrent-rasterbar.so.3()(64bit) thunderbird-lightning-1.0-0.6.20090513hg.fc12.x86_64 requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 Broken deps for ppc ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin Miro-2.0.5-1.fc12.ppc requires gecko-libs = 0:1.9.1 R-RScaLAPACK-0.5.1-19.fc11.ppc requires openmpi-libs audacious-plugin-xmp-2.5.1-5.fc12.ppc requires libaudclient.so.1 blam-1.8.5-10.fc12.ppc requires gecko-libs = 0:1.9.1 clutter-cairo-0.8.2-3.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) conky-1.7.1.1-1.fc12.ppc requires libaudclient.so.1 gauche-gl-0.4.4-4.fc11.ppc requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.ppc requires gauche = 0:0.8.13 gedit-vala-0.4.1-2.fc11.ppc requires libgtksourcecompletion-1.0.so.1 gnome-python2-gtkmozembed-2.25.3-6.fc12.ppc requires gecko-libs = 0:1.9.1 gnome-web-photo-0.8-1.fc12.ppc requires gecko-libs = 0:1.9.1 kdebase-workspace-python-applet-4.2.96-1.fc12.ppc requires PyKDE4 >= 0:4.2.96 libchamplain-0.2.9-1.fc11.ppc requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc requires libftgl.so.0 libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) mozvoikko-0.9.7-0.3.rc1.fc12.ppc requires gecko-libs = 0:1.9.1 pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.ppc requires xulrunner = 0:1.9.1 perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) perl-Gtk2-MozEmbed-0.08-6.fc12.1.ppc requires gecko-libs = 0:1.9.1 php-ZendFramework-1.8.4-1.PL1.fc12.noarch requires php-Fileinfo php-idn-1.2-5.fc12.ppc requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.ppc requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.ppc requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.ppc requires libgeos-3.0.3.so qtparted-0.4.5-19.fc11.ppc requires libparted-1.8.so.8 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc requires libpqxx-2.6.8.so thunderbird-lightning-1.0-0.6.20090513hg.fc12.ppc requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 Broken deps for ppc64 ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin Miro-2.0.5-1.fc12.ppc64 requires gecko-libs = 0:1.9.1 R-RScaLAPACK-0.5.1-19.fc11.ppc64 requires openmpi-libs audacious-plugin-xmp-2.5.1-5.fc12.ppc64 requires libaudclient.so.1()(64bit) clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) conky-1.7.1.1-1.fc12.ppc64 requires libaudclient.so.1()(64bit) gedit-vala-0.4.1-2.fc11.ppc64 requires libgtksourcecompletion-1.0.so.1()(64bit) gnome-python2-gtkmozembed-2.25.3-6.fc12.ppc64 requires gecko-libs = 0:1.9.1 gnome-web-photo-0.8-1.fc12.ppc64 requires gecko-libs = 0:1.9.1 kdebase-workspace-python-applet-4.2.96-1.fc12.ppc64 requires PyKDE4 >= 0:4.2.96 libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) mozvoikko-0.9.7-0.3.rc1.fc12.ppc64 requires gecko-libs = 0:1.9.1 pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.ppc64 requires xulrunner = 0:1.9.1 perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) perl-Gtk2-MozEmbed-0.08-6.fc12.1.ppc64 requires gecko-libs = 0:1.9.1 php-ZendFramework-1.8.4-1.PL1.fc12.noarch requires php-Fileinfo php-idn-1.2-5.fc12.ppc64 requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.ppc64 requires libgeos-3.0.3.so()(64bit) python-mwlib-0.11.2-2.20090522hg2956.fc12.ppc64 requires LabPlot qtparted-0.4.5-19.fc11.ppc64 requires libparted-1.8.so.8()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc64 requires libpqxx-2.6.8.so()(64bit) thunderbird-lightning-1.0-0.6.20090513hg.fc12.ppc64 requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 From opensource at till.name Sat Jul 18 15:54:42 2009 From: opensource at till.name (Till Maas) Date: Sat, 18 Jul 2009 17:54:42 +0200 Subject: Packages tracked by FEver that need to be updated In-Reply-To: <1247929166.2751.333.camel@Vain> References: <200907102243.14776.opensource@till.name> <200907161952.47891.opensource@till.name> <1247929166.2751.333.camel@Vain> Message-ID: <200907181754.48683.opensource@till.name> On Sat July 18 2009, Caol?n McNamara wrote: > FWIW I stuck my own dubious hacky little script I use to keep track of > the latest versions of packages I maintain, which include a lot of > painfully upstream sequenced packages at > http://people.redhat.com/caolanm/latestpackages/ > if it helps anyone. It looks interesting, especially the advanced support to define search patterns. I created a new section to store pointers to projects of this kind at: https://fedoraproject.org/wiki/Using_FEver_to_track_upstream_changes#Related_Projects Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From paul at all-the-johnsons.co.uk Sat Jul 18 21:44:32 2009 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 18 Jul 2009 22:44:32 +0100 Subject: Mono heads up Message-ID: <1247953473.5772.3.camel@PB3.linux> Hi, As of next week, I'll be starting the weekly builds of mono from svn and putting them into rawhide. It is my intention to push 2.4.2.2 into F11 in about a months time (it should hit rawhide tomorrow). TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From clydekunkel7734 at cox.net Sun Jul 19 03:26:16 2009 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Sat, 18 Jul 2009 23:26:16 -0400 Subject: [ANNOUNCEMENT] dracut-0.5 In-Reply-To: <4A608C61.9060501@redhat.com> References: <4A608C61.9060501@redhat.com> Message-ID: <4A629258.3060507@cox.net> On 07/17/2009 10:36 AM, Harald Hoyer wrote: > Information: > https://fedoraproject.org/wiki/Dracut > > Download: > F-11: http://koji.fedoraproject.org/koji/buildinfo?buildID=114853 > Rawhide: http://koji.fedoraproject.org/koji/buildinfo?buildID=114854 > > or if the mirrors have synced: > # yum update dracut > > Bugs can be filed in bugzilla: > https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=dracut > > Debugging > ========= > > Create your image with the debug module: > > # dracut -a debug /boot/test-$(uname -r) $(uname -r) > > Add "rdshell" to the kernel command line, remove "rhgb" and "quiet" and > boot the image. > > Once you are dropped to a shell do: > > # dmesg|grep dracut > > Add the output and your kernel command line to the bug report. > > see also: https://fedoraproject.org/wiki/Dracut/Debugging > > What's new in dracut-0.5: > ========================= > > - more generic (all plymouth modules, all keyboards, all console fonts) > - more kernel command line parameters (see also man dracut(8)) > - a helper tool, which generates the kernel command line > (dracut-gencmdline) > > for my machine this looks like this: > # /sbin/dracut-gencmdline > rd_DM_UUID=nvidia_dddhfead > rd_LUKS_UUID=luks-227fe0ce-7e8c-453a-823f-d5bf34ca1da3 > rd_LVM_VG=VolGroup00 KEYBOARDTYPE=pc KEYTABLE=de-latin1 > SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 > > If you have encrypted partitions you should at least set "KEYTABLE" to > have the correct keyboard setting. > > rd_DM_UUID, rd_LUKS_UUID, rd_MD_UUID help you, if dracut does more than > you want in its automatic mode. So if you want to be more specific on > what dracut is allowed to assemble, uncrypt etc. just specify the exact > parameters. > > For those with an Intel fake software raid onboard (imsm/isw), you might > not want MD handle those, but fallback to the old behaviour with DM. To > do so add > rd_NO_MDIMSM to the kernel command line. > > New kernel command line parameters: > > I18N > e.g. LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 > KEYTABLE=de-latin1-nodeadkeys > > KEYBOARDTYPE=sun|pc > will be written to /etc/sysconfig/keyboard in the initramfs > > KEYTABLE= > will be written to /etc/sysconfig/keyboard in the initramfs > > SYSFONT= Console font > will be written to /etc/sysconfig/i18n in the initramfs > > SYSFONTACM= Unicode font map > will be written to /etc/sysconfig/i18n in the initramfs > > UNIMAP= Unicode font map > will be written to /etc/sysconfig/i18n in the initramfs > > LANG= > will be written to /etc/sysconfig/i18n in the initramfs > > Bootsplash - plymouth > rd_plytheme= > specify the plymouth bootsplash theme (fallback is text) > > LVM > rd_NO_LVM > disable LVM detection > > rd_LVM_VG= > only activate the volume groups with the given name > > crypto LUKS > rd_NO_LUKS > disable crypto LUKS detection > > rd_LUKS_UUID= > only activate the LUKS partitions with the given UUID > > MD > rd_NO_MD > disable MD RAID detection > > rd_NO_MDIMSM > no MD RAID for imsm/isw raids, use dmraid instead > > rd_MD_UUID= > only activate the raid sets with the given UUID > > DMRAID > rd_NO_DM > disable DM RAID detection > > rd_DM_UUID= > only activate the raid sets with the given UUID > # dracut -a debug /boot/debug-$(uname -r) $(uname -r) W: Possible missing firmware /lib/firmware/ql8100_fw.bin for module qla2xxx.ko W: Possible missing firmware /lib/firmware/ql2500_fw.bin for module qla2xxx.ko W: Possible missing firmware /lib/firmware/aic94xx-seq.fw for module aic94xx.ko E: Failed to install strace [root at P5K-EWIFI ~]# ls /boot/debug* ls: cannot access /boot/debug*: No such file or directory bz updated: https://bugzilla.redhat.com/show_bug.cgi?id=509576 From chris at tylers.info Sun Jul 19 05:13:31 2009 From: chris at tylers.info (Chris Tyler) Date: Sun, 19 Jul 2009 01:13:31 -0400 Subject: Mock Failures on F11 Message-ID: <1247980411.15906.1260.camel@concord3.proximity.on.ca> I'm having a ton of trouble getting "mock --rebuild" to work in F11 -- I've tried it on several systems (both i386 and x86_64) with Fedora-{10,11}-{i386,x86_64} config files and various input SRPMS. None of the builds work: mock fails on a "yum depsolv" command with an --installroot option. When I run that yum command outside of Mock, it works without the --installroot option and fails with it; I think that points to a misconfiguration of something within the chroot image (RPM database version, I suspect). Clearing the root image cache has no effect. Mock on F10 with the same input SRPMS is successful. I'm losing my mind here, and am feeling the crunch because I'd like to use mock under F11 for POSSE this week. (1) Is anyone else seeing these issues? (2) Is there a known fix or workaround? Many thanks-- -Chris From thomasj at fedoraproject.org Sun Jul 19 08:06:03 2009 From: thomasj at fedoraproject.org (Thomas Janssen) Date: Sun, 19 Jul 2009 08:06:03 +0000 Subject: Does anything require /proc/bus/usb? In-Reply-To: <4A609FA6.7040908@cchtml.com> References: <4A609C00.2080801@cchtml.com> <4A609FA6.7040908@cchtml.com> Message-ID: 2009/7/17 Michael Cronenworth : > Thomas Janssen on 07/17/2009 10:56 AM wrote: >> >> Patch would be welcome. Would make my life easier in #fedora helping >> people with that problem. >> > > The patch should have been attached to the original post. Did you see it? Ah, overlooked it, sorry. -- LG Thomas Dubium sapientiae initium From jgarzik at pobox.com Sun Jul 19 08:06:42 2009 From: jgarzik at pobox.com (Jeff Garzik) Date: Sun, 19 Jul 2009 04:06:42 -0400 Subject: review req: remaining 2 cloud computing daemons (simple, I promise) In-Reply-To: <4A62D305.4080209@pobox.com> References: <4A62D305.4080209@pobox.com> Message-ID: <4A62D412.1030208@pobox.com> Jeff Garzik wrote: > Thanks to Mike Bonnet, the first package of three, "cld", is now in > rawhide (BZ# 511934). Correction: cld is BZ# 511938, as the BZ URL correctly indicated... > cld (done): https://bugzilla.redhat.com/show_bug.cgi?id=511938 Jeff From jgarzik at pobox.com Sun Jul 19 08:14:22 2009 From: jgarzik at pobox.com (Jeff Garzik) Date: Sun, 19 Jul 2009 04:14:22 -0400 Subject: review req: remaining 2 cloud computing daemons Message-ID: <4A62D5DE.8090100@pobox.com> (resending; not sure where the original went) My little cloud computing project has three small server daemons, plus associated client libs, ready for Fedora. Thanks to Mike Bonnet, the first package of three, "cld", is now in rawhide (BZ# 511938). The remaining two packages, "chunkd" (BZ# 511941) and "tabled" (BZ# 511944), are practically the same as "cld" in package structure, build system, etc. They are all small packages, around 10k LOC each IIRC. Hopefully, that means a quick and easy review. Can anyone help me out? Thanks, Jeff From jgarzik at pobox.com Sun Jul 19 08:02:13 2009 From: jgarzik at pobox.com (Jeff Garzik) Date: Sun, 19 Jul 2009 04:02:13 -0400 Subject: review req: remaining 2 cloud computing daemons (simple, I promise) Message-ID: <4A62D305.4080209@pobox.com> My little cloud computing project has three small server daemons, plus client libs, ready for Fedora. Thanks to Mike Bonnet, the first package of three, "cld", is now in rawhide (BZ# 511934). The remaining two packages, "chunkd" (BZ# 511941) and "tabled" (BZ# 511944), are practically the same as "cld" in package structure, build system, etc. They are all small packages, around 10k LOC each IIRC. I hope all that means it would be a quick and easy review for... some helpful volunteer like you, gentle reader! :) Can anyone help me out? Also, as mentioned in another thread, "tabled" requires both "chunkd" and "cld" in rawhide simply to build in koji. Clearing that build dependency would be most helpful. project homepage: http://hail.wiki.kernel.org/ cld (done): https://bugzilla.redhat.com/show_bug.cgi?id=511938 chunkd: https://bugzilla.redhat.com/show_bug.cgi?id=511941 tabled: https://bugzilla.redhat.com/show_bug.cgi?id=511944 Thanks, Jeff From pbrobinson at gmail.com Sun Jul 19 09:38:46 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Sun, 19 Jul 2009 10:38:46 +0100 Subject: review req: remaining 2 cloud computing daemons In-Reply-To: <4A62D5DE.8090100@pobox.com> References: <4A62D5DE.8090100@pobox.com> Message-ID: <5256d0b0907190238x7036307bwce87db0b4785d7fb@mail.gmail.com> Hi Jeff, On Sun, Jul 19, 2009 at 9:14 AM, Jeff Garzik wrote: > > (resending; not sure where the original went) > > My little cloud computing project has three small server daemons, plus > associated client libs, ready for Fedora. > > Thanks to Mike Bonnet, the first package of three, "cld", is now in rawhide > (BZ# 511938). > > The remaining two packages, "chunkd" (BZ# 511941) and "tabled" (BZ# 511944), > are practically the same as "cld" in package structure, build system, etc. > ?They are all small packages, around 10k LOC each IIRC. > > Hopefully, that means a quick and easy review. ? Can anyone help me out? I'll grab both these for you. If you could look at 506804 and 506833 for me for my little effort that would be great. Both should be pretty simple as well. Peter From pbrobinson at gmail.com Sun Jul 19 09:41:41 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Sun, 19 Jul 2009 10:41:41 +0100 Subject: Mock Failures on F11 In-Reply-To: <1247980411.15906.1260.camel@concord3.proximity.on.ca> References: <1247980411.15906.1260.camel@concord3.proximity.on.ca> Message-ID: <5256d0b0907190241u3557898cyb6cd057e8fd4b457@mail.gmail.com> > I'm having a ton of trouble getting "mock --rebuild" to work in F11 -- > I've tried it on several systems (both i386 and x86_64) with > Fedora-{10,11}-{i386,x86_64} config files and various input SRPMS. None > of the builds work: mock fails on a "yum depsolv" command with an > --installroot option. > > When I run that yum command outside of Mock, it works without the > --installroot option and fails with it; I think that points to a > misconfiguration of something within the chroot image (RPM database > version, I suspect). Clearing the root image cache has no effect. > > Mock on F10 with the same input SRPMS is successful. > > I'm losing my mind here, and am feeling the crunch because I'd like to > use mock under F11 for POSSE this week. > > (1) Is anyone else seeing these issues? > (2) Is there a known fix or workaround? I'm seeing issues with mock on F-11 but haven't had time to revisit the issue. It gets as far as the package list that yum wants to install and then crashes from memory. Peter From dtimms at iinet.net.au Sun Jul 19 14:04:58 2009 From: dtimms at iinet.net.au (David Timms) Date: Mon, 20 Jul 2009 00:04:58 +1000 Subject: meeting minutes posts - line / wordwrap in Message-ID: <4A63280A.8010109@iinet.net.au> Hi, what would be the best location to list an issue with the meeting minutes, where the entries overflow the width of the user's screen ? DaveT. From alsadi at gmail.com Sun Jul 19 15:06:36 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Sun, 19 Jul 2009 18:06:36 +0300 Subject: Interested in scanning? In-Reply-To: References: <1244197410.30768.2379.camel@cookie.hadess.net> <4A29160F.4000208@redhat.com> <1244217602.2876.50.camel@localhost.localdomain> Message-ID: <385866f0907190806l4a8e3482p362c81e7eb3cb88a@mail.gmail.com> I got a BenQ scanner lsusb Bus 002 Device 002: ID 04a5:20f8 Acer Peripherals Inc. (now BenQ Corp.) Benq 5000 I have the firmware installed and set in snapscan backend conf, and it used to work in other distros but scanning fails scanimage -x 100 -y 100 --format=tiff >image.tiff [snapscan] Scanner warming up - waiting 30 seconds. scanimage: sane_start: Error during device I/O User defined signal 1 From sundaram at fedoraproject.org Sun Jul 19 15:40:55 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 19 Jul 2009 21:10:55 +0530 Subject: meeting minutes posts - line / wordwrap in In-Reply-To: <4A63280A.8010109@iinet.net.au> References: <4A63280A.8010109@iinet.net.au> Message-ID: <4A633E87.7020907@fedoraproject.org> On 07/19/2009 07:34 PM, David Timms wrote: > Hi, what would be the best location to list an issue with the meeting > minutes, where the entries overflow the width of the user's screen ? Not enough context. If it is a wiki, you can very well edit it yourself, I think. You need a Fedora account which you can sign up within minutes. Rahul From mschwendt at gmail.com Sun Jul 19 16:49:51 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 19 Jul 2009 16:49:51 -0000 Subject: Broken dependencies in Fedora 11 - 2009-07-19 Message-ID: <20090719164951.21907.18514@faldor.intranet> ====================================================================== The results in this summary consider Test Updates! ====================================================================== Summary of broken packages (by src.rpm name): beagle gauche-gl gauche-gtk guiloader-c++ libguestfs libvirt-qpid mono-tools ppl python-repoze-what tomboy wine ====================================================================== Broken packages in fedora-11-i386: gauche-gl-0.4.4-4.fc11.i586 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.i586 requires gauche = 0:0.8.13 guiloader-c++-2.13.0-2.fc11.i586 requires libguiloader.so.0 ====================================================================== Broken packages in fedora-11-ppc: gauche-gl-0.4.4-4.fc11.ppc requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.ppc requires gauche = 0:0.8.13 guiloader-c++-2.13.0-2.fc11.ppc requires libguiloader.so.0 guiloader-c++-2.13.0-2.fc11.ppc64 requires libguiloader.so.0()(64bit) ====================================================================== Broken packages in fedora-11-ppc64: guiloader-c++-2.13.0-2.fc11.ppc64 requires libguiloader.so.0()(64bit) ====================================================================== Broken packages in fedora-11-x86_64: gauche-gl-0.4.4-4.fc11.x86_64 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.x86_64 requires gauche = 0:0.8.13 guiloader-c++-2.13.0-2.fc11.i586 requires libguiloader.so.0 guiloader-c++-2.13.0-2.fc11.x86_64 requires libguiloader.so.0()(64bit) ====================================================================== Broken packages in fedora-updates-11-i386: libvirt-qpid-0.2.16-2.fc11.i586 requires libqpidclient.so.0 libvirt-qpid-0.2.16-2.fc11.i586 requires libqpidcommon.so.0 libvirt-qpid-0.2.16-2.fc11.i586 requires libqmfagent.so.0 virt-df2-1.0.58-2.fc11.i586 requires libguestfs = 0:1.0.58-2.fc11 ====================================================================== Broken packages in fedora-updates-11-ppc: libvirt-qpid-0.2.16-2.fc11.ppc requires libqpidclient.so.0 libvirt-qpid-0.2.16-2.fc11.ppc requires libqpidcommon.so.0 libvirt-qpid-0.2.16-2.fc11.ppc requires libqmfagent.so.0 virt-df2-1.0.58-2.fc11.ppc requires libguestfs = 0:1.0.58-2.fc11 ====================================================================== Broken packages in fedora-updates-11-ppc64: beagle-0.3.9-9.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0 beagle-0.3.9-9.fc11.ppc64 requires mono(gsf-sharp) = 0:0.0.0.7 beagle-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 beagle-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 beagle-0.3.9-9.fc11.ppc64 requires mono(taglib-sharp) = 0:2.0.3.2 beagle-evolution-0.3.9-9.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0 beagle-evolution-0.3.9-9.fc11.ppc64 requires mono(evolution-sharp) = 0:5.0.0.0 beagle-gnome-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 beagle-gnome-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 beagle-thunderbird-0.3.9-9.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0 libvirt-qpid-0.2.16-2.fc11.ppc64 requires libqmfagent.so.0()(64bit) libvirt-qpid-0.2.16-2.fc11.ppc64 requires libqpidcommon.so.0()(64bit) libvirt-qpid-0.2.16-2.fc11.ppc64 requires libqpidclient.so.0()(64bit) virt-df2-1.0.58-2.fc11.ppc64 requires libguestfs = 0:1.0.58-2.fc11 ====================================================================== Broken packages in fedora-updates-11-x86_64: libvirt-qpid-0.2.16-2.fc11.x86_64 requires libqmfagent.so.0()(64bit) libvirt-qpid-0.2.16-2.fc11.x86_64 requires libqpidcommon.so.0()(64bit) libvirt-qpid-0.2.16-2.fc11.x86_64 requires libqpidclient.so.0()(64bit) virt-df2-1.0.58-2.fc11.x86_64 requires libguestfs = 0:1.0.58-2.fc11 wine-esd-1.1.23-1.fc11.i586 requires wine-core = 0:1.1.23-1.fc11 wine-jack-1.1.23-1.fc11.i586 requires wine-core = 0:1.1.23-1.fc11 wine-nas-1.1.23-1.fc11.i586 requires wine-core = 0:1.1.23-1.fc11 ====================================================================== Broken packages in fedora-updates-testing-11-i386: ppl-swiprolog-0.10.2-3.fc11.i586 requires libpl.so.5.7.6 ppl-yap-0.10.2-3.fc11.i586 requires libYap.so python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 ====================================================================== Broken packages in fedora-updates-testing-11-ppc: ppl-swiprolog-0.10.2-3.fc11.ppc requires libpl.so.5.7.6 ppl-yap-0.10.2-3.fc11.ppc requires libYap.so python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 ====================================================================== Broken packages in fedora-updates-testing-11-ppc64: mono-tools-2.4-12.fc11.ppc64 requires mono(gtkhtml-sharp) >= 0:3.0 ppl-swiprolog-0.10.2-3.fc11.ppc64 requires libpl.so.5.7.6()(64bit) ppl-yap-0.10.2-3.fc11.ppc64 requires libYap.so()(64bit) python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 tomboy-0.14.3-1.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(Mono.Addins.Setup) = 0:0.4.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(gnome-panel-sharp) = 0:2.24.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(Mono.Addins) = 0:0.4.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(Mono.Addins.Gui) = 0:0.4.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 ====================================================================== Broken packages in fedora-updates-testing-11-x86_64: ppl-swiprolog-0.10.2-3.fc11.x86_64 requires libpl.so.5.7.6()(64bit) ppl-yap-0.10.2-3.fc11.x86_64 requires libYap.so()(64bit) python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 From rawhide at fedoraproject.org Sun Jul 19 16:43:26 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sun, 19 Jul 2009 16:43:26 +0000 Subject: rawhide report: 20090719 changes Message-ID: <20090719164326.GA13613@releng2.fedora.phx.redhat.com> Compose started at Sun Jul 19 06:15:07 UTC 2009 Updated Packages: arts-1.5.10-6.fc12 ------------------ * Sat Jul 18 2009 Rex Dieter - 8:1.5.10-6 - FTBFS arts-1.5.10-5.fc11 (#511653) - -devel: Requires: %{name}%_isa ... bluez-4.46-1.fc12 ----------------- * Sun Jul 19 2009 Bastien Nocera 4.46-1 - Update to 4.46 bognor-regis-0.4.7-1.fc12 ------------------------- * Sat Jul 18 2009 Peter Robinson 0.4.7-1 - New upstream 0.4.7 release bug-buddy-2.27.1-3.fc12 ----------------------- * Sat Jul 18 2009 Matthias Clasen - 1:2.27.1-3 - Rebuild deco-archive-1.5-1.fc12 ----------------------- * Thu Jul 09 2009 Orcan Ogetbil 1.5-1 - Version update. New extensions: deb, udeb, tar.xz, txz, xz - Handle .lzma via xz-lzma-compat from now on e2tools-0.0.16-13.fc12 ---------------------- * Sat Jul 18 2009 Hans Ulrich Niedermann - 0.0.16-13 - Add libcom_err-devel buildreq on F12 and later (e2fsprogs-devel split) ethtool-6-6.20090323git.fc12 ---------------------------- * Sat Jul 18 2009 Robert Scheck 6-6.20090323git - Upgrade to GIT 20090323 exo-0.3.101-2.fc12 ------------------ * Fri Jul 17 2009 Kevin Fenzi - 0.3.101-2 - Add patch to fix url quoting (bug #509730) fedora-package-config-apt-11.89-4 --------------------------------- * Sat Jul 18 2009 Axel Thimm - 11.89-4 - Use MM URLs. fedora-package-config-smart-11.89-18 ------------------------------------ * Sat Jul 18 2009 Axel Thimm - 11.89-18 - Use MM URLs. gc-7.1-8.fc12 ------------- * Thu Jul 16 2009 Rex Dieter - 4.9.2-1 - Update to release 4.9.2 gmime-2.4.7-1.fc12 ------------------ * Sat Jul 18 2009 Matthias Clasen - 2.4.7-1 - Update to 2.4.7 * Mon May 25 2009 Xavier Lamien - 2.4.3-5 - Build arch ppc64. - Fix uu??code binaries. * Tue Mar 31 2009 Debarshi Ray - 2.4.3-4 - Merge review feedback (#225808) ibus-1.2.0.20090719-1.fc12 -------------------------- * Sun Jul 19 2009 Peng Huang - 1.2.0.20090719-1 - Update to 1.2.0.200907179 jasper-1.900.1-11.fc12 ---------------------- * Sat Jul 18 2009 Rex Dieter - 1.900.1-11 - FTBFS jasper-1.900.1-10.fc11 (#511743) kdebase3-3.5.10-11.fc12 ----------------------- * Sat Jul 18 2009 Rex Dieter 3.5.10-11 - FTBFS kdebase3-3.5.10-8.fc11 (#511656) - Requires: %name-libs%?_isa ... * Wed Apr 22 2009 Karsten Hopp 3.5.10-10.1 - disable firewire stuff on s390(x) * Thu Mar 26 2009 Rex Dieter - 3.5.10-10 - optimize scriptlets kdebindings-4.2.96-2.fc12 ------------------------- * Thu Jul 16 2009 Rex Dieter - 4.2.96-2 - fix pykdeuic4-related install bits (kdebug#198162) - pyqt4_version 4.5.2 - License: LGPLv2+ * Fri Jul 10 2009 Than Ngo - 4.2.96-1 - 4.3rc2 kdelibs3-3.5.10-11.fc12 ----------------------- * Sat Jul 18 2009 Rex Dieter - 3.5.10-12 - FTBFS kdelibs3-3.5.10-11.fc11 (#511571) - -devel: Requires: %{name}%_isa ... kdetoys-4.2.96-1.fc12 --------------------- * Sun Jul 12 2009 Than Ngo - 4.2.96-1 - 4.3rc2 kdeutils-4.2.96-1.fc12 ---------------------- * Mon Jul 13 2009 Than Ngo - 4.2.96-1 - 4.3rc2 kdevelop-3.5.4-4.fc12 --------------------- * Sat Jul 18 2009 Rex Dieter - 9:3.5.4-4 - FTBFS kdevelop-3.5.4-3.fc11 (#511768) kdnssd-avahi-0.1.3-0.8.20080116svn.fc12 --------------------------------------- * Sat Jul 18 2009 Rex Dieter 0.1.3-0.8.20080116svn - FTBFS kdnssd-avahi-0.1.3-0.7.20080116svn.fc11 (#511519) - -devel: Requires: %name%?_isa ... kopete-cryptography-1.3.0-10.fc12 --------------------------------- * Sat Jul 18 2009 Rex Dieter - 1.3.0-10 - 1.3.0-kde4.2.4 * Fri May 08 2009 Rex Dieter - 1.3.0-9 - 1.3.0-kde4.2.3 - cleanup docdir/HTML ownership - sync from F-10 branch libbeagle-0.3.9-4.fc12 ---------------------- * Sat Jul 18 2009 Matthias Clasen - 0.3.9-3 - Rebuild libgnomeprint22-2.18.6-2.fc12 ----------------------------- * Sat Jul 18 2009 Matthias Clasen - 2.18.6-2 - Rebuild libisofs-0.6.20-1.fc12 ---------------------- * Sat Jul 18 2009 Robert Scheck 0.6.20-1 - Upgrade to 0.6.20 libplist-0.13-1.fc12 -------------------- mojito-0.19-1.fc12 ------------------ * Sat Jul 18 2009 Peter Robinson 0.19-1 - Update to 0.19 mono-2.4.2.2-1.fc12 ------------------- * Fri Jul 17 2009 Paul F. Johnson 2.4.2.2-1 - Patch for cve-2009-0217 nautilus-search-tool-0.3.0-2.fc12 --------------------------------- * Sat Jul 18 2009 Paul W. Frields - 0.3.0-1 - Update to upstream 0.3.0 - Fixes bug #477810 * Sat Jul 18 2009 Paul W. Frields - 0.3.0-2 - Fix missing BuildRequires openmpi-1.3.1-4.fc12 -------------------- * Sat Jul 18 2009 Jussi Lehtola - 1.3.1-4 - Add Provides: openmpi-devel to fix other package builds in rawhide. parted-1.9.0-3.20090610git32dc.fc12 ----------------------------------- * Sat Jul 18 2009 Lubomir Rintel - 1.9.0-3.20090610git32dc - Fix a typo in the errno patch pm-utils-1.2.5-4.fc12 --------------------- * Sat Jul 18 2009 Till Maas - 1.2.5-4 - Remove atd script - create filesystem subpackage for hooks * Fri Jul 17 2009 Marcela Ma?l??ov? - 1.2.5-3 - move atd script into pm-utils * Thu Jun 25 2009 Till Maas - 1.2.5-2 - add check for hdparm in hd-apm-restore rapidsvn-0.10.0-1.fc12 ---------------------- * Sat Jul 18 2009 Tim Jackson 0.10.0-1 - Update to v0.10.0 - Set default attrs for subpackages seahorse-plugins-2.27.1-2.fc12 ------------------------------ * Sat Jul 18 2009 Matthias Clasen 2.27.1-2 - Temporarily drop epiphany extension spr-3.3.2-2.fc12 ---------------- springlobby-0.3-1.fc12 ---------------------- * Sat Jul 18 2009 Aurelien Bompard 0.3 - version 0.3 sugar-0.85.2-1.fc12 ------------------- * Sat Jul 18 2009 Tomeu Vizoso - 0.85.2-1 - New upstream release sugar-artwork-0.85.1-2.fc12 --------------------------- * Sat Jul 18 2009 Tomeu Vizoso - 0.85.1-1 - New upstream release * Sat Jul 18 2009 Tomeu Vizoso - 0.85.1-2 - Remove matchbox theme dir sugar-base-0.85.2-1.fc12 ------------------------ * Sat Jul 18 2009 Tomeu Vizoso - 0.85.2-1 - New upstream release sugar-toolkit-0.85.2-1.fc12 --------------------------- * Sat Jul 18 2009 Tomeu Vizoso - 0.85.2-1 - New upstream release wormux-0.8.4-1.fc12 ------------------- * Sat Jul 18 2009 Wart 0.8.4-1 - Update to 0.8.4 wxMaxima-0.8.2-3.fc12 --------------------- * Sat Jul 18 2009 Rex Dieter - 0.8.2-2 - output window of wxMaxima is not visible in RtL locales (#455863) * Sat Jul 18 2009 Rex Dieter - 0.8.2-3 - Requires: maxima >= 5.18 xchat-2.8.6-10.fc12 ------------------- * Sat Jul 18 2009 Kevin Kofler - 1:2.8.6-10 - Fixed patch for the "C_onnect" issue (#512034, Edward Sheldrake) xorg-x11-drv-openchrome-0.2.903-12.fc12 --------------------------------------- * Sat Jul 18 2009 Xavier Bachelot - 0.2.903-12 - Update to latest snapshot (svn 758) : - Basic VX855 support. - Fix pci space corruption on P4M900 (RHBZ#506622). - Fix null pointer dereference in viaExaCheckComposite (RHBZ#449034). - Add patch to allow 1200x900 panel (X0-1.5). - Add patch to remove loader symbol lists, needed for xserver 1.7 (RHBZ#510206). - Add experimental patch for better VT1625 support. - Drop upstreamed patches. yelp-2.27.2-3.fc12 ------------------ * Sat Jul 18 2009 Matthias Clasen - 2.27.2-3 - Drop unused direct dependencies Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 46 Broken deps for i386 ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin CodeAnalyst-gui-2.8.54-15.fc12.i586 requires libbfd-2.19.51.0.11-24.fc12.so Miro-2.0.5-1.fc12.i586 requires gecko-libs = 0:1.9.1 R-RScaLAPACK-0.5.1-19.fc11.i586 requires openmpi-libs audacious-plugin-xmp-2.5.1-5.fc12.i586 requires libaudclient.so.1 blam-1.8.5-10.fc12.i586 requires gecko-libs = 0:1.9.1 clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) conky-1.7.1.1-1.fc12.i586 requires libaudclient.so.1 gauche-gl-0.4.4-4.fc11.i586 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.i586 requires gauche = 0:0.8.13 gedit-vala-0.4.1-2.fc11.i586 requires libgtksourcecompletion-1.0.so.1 gnome-python2-gtkmozembed-2.25.3-6.fc12.i586 requires gecko-libs = 0:1.9.1 gnome-web-photo-0.8-1.fc12.i586 requires gecko-libs = 0:1.9.1 libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 mozvoikko-0.9.7-0.3.rc1.fc12.i586 requires gecko-libs = 0:1.9.1 pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.i586 requires xulrunner = 0:1.9.1 perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) perl-Gtk2-MozEmbed-0.08-6.fc12.1.i586 requires gecko-libs = 0:1.9.1 php-ZendFramework-1.8.4-1.PL1.fc12.noarch requires php-Fileinfo php-idn-1.2-5.fc12.i586 requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.i386 requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.i386 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.i586 requires libgeos-3.0.3.so qtparted-0.4.5-19.fc11.i586 requires libparted-1.8.so.8 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.i586 requires libpqxx-2.6.8.so thunderbird-lightning-1.0-0.6.20090513hg.fc12.i586 requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 Broken deps for x86_64 ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin CodeAnalyst-gui-2.8.54-15.fc12.i586 requires libbfd-2.19.51.0.11-24.fc12.so CodeAnalyst-gui-2.8.54-15.fc12.x86_64 requires libbfd-2.19.51.0.11-24.fc12.so()(64bit) Miro-2.0.5-1.fc12.x86_64 requires gecko-libs = 0:1.9.1 R-RScaLAPACK-0.5.1-19.fc11.x86_64 requires openmpi-libs audacious-plugin-xmp-2.5.1-5.fc12.x86_64 requires libaudclient.so.1()(64bit) blam-1.8.5-10.fc12.x86_64 requires gecko-libs = 0:1.9.1 clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.x86_64 requires pkgconfig(clutter-0.8) conky-1.7.1.1-1.fc12.x86_64 requires libaudclient.so.1()(64bit) gauche-gl-0.4.4-4.fc11.x86_64 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.x86_64 requires gauche = 0:0.8.13 gedit-vala-0.4.1-2.fc11.x86_64 requires libgtksourcecompletion-1.0.so.1()(64bit) gnome-python2-gtkmozembed-2.25.3-6.fc12.x86_64 requires gecko-libs = 0:1.9.1 gnome-web-photo-0.8-1.fc12.x86_64 requires gecko-libs = 0:1.9.1 libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.x86_64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 libprojectM-1.2.0-9.fc11.x86_64 requires libftgl.so.0()(64bit) mozvoikko-0.9.7-0.3.rc1.fc12.x86_64 requires gecko-libs = 0:1.9.1 pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.x86_64 requires xulrunner = 0:1.9.1 perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) perl-Gtk2-MozEmbed-0.08-6.fc12.1.x86_64 requires gecko-libs = 0:1.9.1 php-ZendFramework-1.8.4-1.PL1.fc12.noarch requires php-Fileinfo php-idn-1.2-5.fc12.x86_64 requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.x86_64 requires libgeos-3.0.3.so()(64bit) qtparted-0.4.5-19.fc11.x86_64 requires libparted-1.8.so.8()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.x86_64 requires libpqxx-2.6.8.so()(64bit) thunderbird-lightning-1.0-0.6.20090513hg.fc12.x86_64 requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 Broken deps for ppc ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin Miro-2.0.5-1.fc12.ppc requires gecko-libs = 0:1.9.1 R-RScaLAPACK-0.5.1-19.fc11.ppc requires openmpi-libs audacious-plugin-xmp-2.5.1-5.fc12.ppc requires libaudclient.so.1 blam-1.8.5-10.fc12.ppc requires gecko-libs = 0:1.9.1 clutter-cairo-0.8.2-3.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) conky-1.7.1.1-1.fc12.ppc requires libaudclient.so.1 gauche-gl-0.4.4-4.fc11.ppc requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.ppc requires gauche = 0:0.8.13 gedit-vala-0.4.1-2.fc11.ppc requires libgtksourcecompletion-1.0.so.1 gnome-python2-gtkmozembed-2.25.3-6.fc12.ppc requires gecko-libs = 0:1.9.1 gnome-web-photo-0.8-1.fc12.ppc requires gecko-libs = 0:1.9.1 libchamplain-0.2.9-1.fc11.ppc requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc requires libftgl.so.0 libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) mozvoikko-0.9.7-0.3.rc1.fc12.ppc requires gecko-libs = 0:1.9.1 pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.ppc requires xulrunner = 0:1.9.1 perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) perl-Gtk2-MozEmbed-0.08-6.fc12.1.ppc requires gecko-libs = 0:1.9.1 php-ZendFramework-1.8.4-1.PL1.fc12.noarch requires php-Fileinfo php-idn-1.2-5.fc12.ppc requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.ppc requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.ppc requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.ppc requires libgeos-3.0.3.so qtparted-0.4.5-19.fc11.ppc requires libparted-1.8.so.8 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc requires libpqxx-2.6.8.so thunderbird-lightning-1.0-0.6.20090513hg.fc12.ppc requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 Broken deps for ppc64 ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin Miro-2.0.5-1.fc12.ppc64 requires gecko-libs = 0:1.9.1 R-RScaLAPACK-0.5.1-19.fc11.ppc64 requires openmpi-libs audacious-plugin-xmp-2.5.1-5.fc12.ppc64 requires libaudclient.so.1()(64bit) clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) conky-1.7.1.1-1.fc12.ppc64 requires libaudclient.so.1()(64bit) gedit-vala-0.4.1-2.fc11.ppc64 requires libgtksourcecompletion-1.0.so.1()(64bit) gnome-python2-gtkmozembed-2.25.3-6.fc12.ppc64 requires gecko-libs = 0:1.9.1 gnome-web-photo-0.8-1.fc12.ppc64 requires gecko-libs = 0:1.9.1 libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) mozvoikko-0.9.7-0.3.rc1.fc12.ppc64 requires gecko-libs = 0:1.9.1 pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.ppc64 requires xulrunner = 0:1.9.1 perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) perl-Gtk2-MozEmbed-0.08-6.fc12.1.ppc64 requires gecko-libs = 0:1.9.1 php-ZendFramework-1.8.4-1.PL1.fc12.noarch requires php-Fileinfo php-idn-1.2-5.fc12.ppc64 requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.ppc64 requires libgeos-3.0.3.so()(64bit) python-mwlib-0.11.2-2.20090522hg2956.fc12.ppc64 requires LabPlot qtparted-0.4.5-19.fc11.ppc64 requires libparted-1.8.so.8()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc64 requires libpqxx-2.6.8.so()(64bit) thunderbird-lightning-1.0-0.6.20090513hg.fc12.ppc64 requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 From vpivaini at cs.helsinki.fi Sun Jul 19 17:02:56 2009 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Sun, 19 Jul 2009 20:02:56 +0300 Subject: rawhide report: 20090719 changes - xulrunner breakage In-Reply-To: <20090719164326.GA13613@releng2.fedora.phx.redhat.com> References: <20090719164326.GA13613@releng2.fedora.phx.redhat.com> Message-ID: <1248022976.2575.17.camel@localhost.localdomain> su, 2009-07-19 kello 16:43 +0000, Rawhide Report kirjoitti: > mozvoikko-0.9.7-0.3.rc1.fc12.i586 requires gecko-libs = 0:1.9.1 What's the problem here? If I do a 'repoquery --disablerepo \* --enablerepo rawhide --whatprovides gecko-libs = 0:1.9.1' it returns xulrunner-0:1.9.1-2.fc12.i586 on this system. Why do the rawhide reports keep telling me there is no gecko-libs = 0:1.9.1 then? -- Ville-Pekka Vainio From a.badger at gmail.com Sun Jul 19 17:28:30 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 19 Jul 2009 10:28:30 -0700 Subject: rawhide report: 20090719 changes - xulrunner breakage In-Reply-To: <1248022976.2575.17.camel@localhost.localdomain> References: <20090719164326.GA13613@releng2.fedora.phx.redhat.com> <1248022976.2575.17.camel@localhost.localdomain> Message-ID: <4A6357BE.2020805@gmail.com> On 07/19/2009 10:02 AM, Ville-Pekka Vainio wrote: > su, 2009-07-19 kello 16:43 +0000, Rawhide Report kirjoitti: >> mozvoikko-0.9.7-0.3.rc1.fc12.i586 requires gecko-libs = 0:1.9.1 > > What's the problem here? If I do a 'repoquery --disablerepo \* > --enablerepo rawhide --whatprovides gecko-libs = 0:1.9.1' it returns > xulrunner-0:1.9.1-2.fc12.i586 on this system. Why do the rawhide reports > keep telling me there is no gecko-libs = 0:1.9.1 then? > I think your mirror is out of date: $ repoquery --disablerepo \* --enablerepo rawhide --provides xulrunner | grep gecko-libs gecko-libs = 1.9.1.1 $ repoquery --disablerepo \* --enablerepo rawhide --whatprovides 'gecko-libs = 0:1.9.1' $ -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From mschwendt at gmail.com Sun Jul 19 17:42:42 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 19 Jul 2009 17:42:42 -0000 Subject: Broken dependencies in Fedora 10 - 2009-07-19 Message-ID: <20090719174242.26717.96149@faldor.intranet> ====================================================================== The results in this summary consider Test Updates! ====================================================================== Summary of broken packages (by src.rpm name): db4o gadget gauche-gl gauche-gtk guiloader-c++ libvirt-qpid llvm php ppl python-morbid python-repoze-what trac-customfieldadmin-plugin wine ====================================================================== Broken packages in fedora-10-i386: gauche-gl-0.4.4-3.fc9.i386 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-17.fc9.i386 requires gauche = 0:0.8.13 ====================================================================== Broken packages in fedora-10-ppc: db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607 gauche-gl-0.4.4-3.fc9.ppc requires gauche = 0:0.8.13 gauche-gtk-0.4.1-17.fc9.ppc requires gauche = 0:0.8.13 llvm-devel-2.3-2.fc10.ppc64 requires llvm = 0:2.3-2.fc10 php-devel-5.2.6-5.ppc64 requires php = 0:5.2.6-5 ====================================================================== Broken packages in fedora-10-x86_64: gauche-gl-0.4.4-3.fc9.x86_64 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-17.fc9.x86_64 requires gauche = 0:0.8.13 php-devel-5.2.6-5.i386 requires php = 0:5.2.6-5 ====================================================================== Broken packages in fedora-updates-10-i386: guiloader-c++-2.13.0-1.fc10.i386 requires libguiloader.so.0 libvirt-qpid-0.2.16-2.fc10.i386 requires libqpidclient.so.0 libvirt-qpid-0.2.16-2.fc10.i386 requires libqpidcommon.so.0 libvirt-qpid-0.2.16-2.fc10.i386 requires libqmfagent.so.0 python-morbid-0.8.6.1-1.fc10.noarch requires python-stomper trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin ====================================================================== Broken packages in fedora-updates-10-ppc: guiloader-c++-2.13.0-1.fc10.ppc requires libguiloader.so.0 guiloader-c++-2.13.0-1.fc10.ppc64 requires libguiloader.so.0()(64bit) libvirt-qpid-0.2.16-2.fc10.ppc requires libqpidclient.so.0 libvirt-qpid-0.2.16-2.fc10.ppc requires libqpidcommon.so.0 libvirt-qpid-0.2.16-2.fc10.ppc requires libqmfagent.so.0 python-morbid-0.8.6.1-1.fc10.noarch requires python-stomper trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin ====================================================================== Broken packages in fedora-updates-10-ppc64: gadget-0.0.3-2.fc10.noarch requires ejabberd guiloader-c++-2.13.0-1.fc10.ppc64 requires libguiloader.so.0()(64bit) libvirt-qpid-0.2.16-2.fc10.ppc64 requires libqmfagent.so.0()(64bit) libvirt-qpid-0.2.16-2.fc10.ppc64 requires libqpidcommon.so.0()(64bit) libvirt-qpid-0.2.16-2.fc10.ppc64 requires libqpidclient.so.0()(64bit) python-morbid-0.8.6.1-1.fc10.noarch requires python-stomper trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin ====================================================================== Broken packages in fedora-updates-10-x86_64: guiloader-c++-2.13.0-1.fc10.i386 requires libguiloader.so.0 guiloader-c++-2.13.0-1.fc10.x86_64 requires libguiloader.so.0()(64bit) libvirt-qpid-0.2.16-2.fc10.x86_64 requires libqmfagent.so.0()(64bit) libvirt-qpid-0.2.16-2.fc10.x86_64 requires libqpidcommon.so.0()(64bit) libvirt-qpid-0.2.16-2.fc10.x86_64 requires libqpidclient.so.0()(64bit) python-morbid-0.8.6.1-1.fc10.noarch requires python-stomper trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin wine-esd-1.1.23-1.fc10.i386 requires wine-core = 0:1.1.23-1.fc10 wine-jack-1.1.23-1.fc10.i386 requires wine-core = 0:1.1.23-1.fc10 wine-nas-1.1.23-1.fc10.i386 requires wine-core = 0:1.1.23-1.fc10 ====================================================================== Broken packages in fedora-updates-testing-10-i386: ppl-swiprolog-0.10.2-3.fc10.i386 requires libpl.so.5.6.60 ppl-yap-0.10.2-3.fc10.i386 requires libYap.so python-repoze-what-docs-1.0.8-1.fc10.noarch requires python-repoze-what-1.0.8 ====================================================================== Broken packages in fedora-updates-testing-10-ppc: ppl-swiprolog-0.10.2-3.fc10.ppc requires libpl.so.5.6.60 ppl-yap-0.10.2-3.fc10.ppc requires libYap.so python-repoze-what-docs-1.0.8-1.fc10.noarch requires python-repoze-what-1.0.8 ====================================================================== Broken packages in fedora-updates-testing-10-ppc64: ppl-swiprolog-0.10.2-3.fc10.ppc64 requires libpl.so.5.6.60()(64bit) ppl-yap-0.10.2-3.fc10.ppc64 requires libYap.so()(64bit) python-repoze-what-docs-1.0.8-1.fc10.noarch requires python-repoze-what-1.0.8 ====================================================================== Broken packages in fedora-updates-testing-10-x86_64: ppl-swiprolog-0.10.2-3.fc10.x86_64 requires libpl.so.5.6.60()(64bit) ppl-yap-0.10.2-3.fc10.x86_64 requires libYap.so()(64bit) python-repoze-what-docs-1.0.8-1.fc10.noarch requires python-repoze-what-1.0.8 From vpivaini at cs.helsinki.fi Sun Jul 19 17:52:21 2009 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Sun, 19 Jul 2009 20:52:21 +0300 Subject: rawhide report: 20090719 changes - xulrunner breakage In-Reply-To: <4A6357BE.2020805@gmail.com> References: <20090719164326.GA13613@releng2.fedora.phx.redhat.com> <1248022976.2575.17.camel@localhost.localdomain> <4A6357BE.2020805@gmail.com> Message-ID: <1248025941.2575.18.camel@localhost.localdomain> su, 2009-07-19 kello 10:28 -0700, Toshio Kuratomi kirjoitti: > I think your mirror is out of date: Thanks, that must have been it, rebuilt in https://koji.fedoraproject.org/koji/taskinfo?taskID=1485357 -- Ville-Pekka Vainio From jgarzik at pobox.com Sun Jul 19 18:49:18 2009 From: jgarzik at pobox.com (Jeff Garzik) Date: Sun, 19 Jul 2009 14:49:18 -0400 Subject: review req: remaining 2 cloud computing daemons In-Reply-To: <5256d0b0907190238x7036307bwce87db0b4785d7fb@mail.gmail.com> References: <4A62D5DE.8090100@pobox.com> <5256d0b0907190238x7036307bwce87db0b4785d7fb@mail.gmail.com> Message-ID: <4A636AAE.3080503@pobox.com> Peter Robinson wrote: > Hi Jeff, > > On Sun, Jul 19, 2009 at 9:14 AM, Jeff Garzik wrote: >> (resending; not sure where the original went) >> >> My little cloud computing project has three small server daemons, plus >> associated client libs, ready for Fedora. >> >> Thanks to Mike Bonnet, the first package of three, "cld", is now in rawhide >> (BZ# 511938). >> >> The remaining two packages, "chunkd" (BZ# 511941) and "tabled" (BZ# 511944), >> are practically the same as "cld" in package structure, build system, etc. >> They are all small packages, around 10k LOC each IIRC. >> >> Hopefully, that means a quick and easy review. Can anyone help me out? > > I'll grab both these for you. If you could look at 506804 and 506833 > for me for my little effort that would be great. Both should be pretty > simple as well. I reviewed them as best I could, but seeing as how rusty I am with the package process (I'm so old, it's basically a new process :)), the fedora-review flag was left untouched... Both look good to me, though. Jeff From sundaram at fedoraproject.org Sun Jul 19 18:48:56 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 20 Jul 2009 00:18:56 +0530 Subject: Interesting in extending the lifcycle of Fedora? Message-ID: <4A636A98.9090209@fedoraproject.org> Hi, While the Fedora Board is contemplating the approval of the proposal, now would be a good time to show your interest in contributing. Sign up at https://fedoraproject.org/wiki/Features/Extended_Life_Cycle#Interested_People Rahul From mjs at clemson.edu Sun Jul 19 21:05:44 2009 From: mjs at clemson.edu (Matthew Saltzman) Date: Sun, 19 Jul 2009 17:05:44 -0400 Subject: Sage in F11 Message-ID: <1248037544.3613.113.camel@valkyrie.localdomain> Sorry to bother the -devel list with this, but nobody on fedora-list responded to my question, and I know there is some effort to package Sage for Fedora. I hope one of those packagers can help me out. I've installed sage-4.1 on F11 using the F10 binary installation tarball. But when I run sage, it fails with the following error: /usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/sage ---------------------------------------------------------------------- | Sage Version 4.1, Release Date: 2009-07-09 | | Type notebook() for the GUI, and license() for information. | ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/bin/sage-ipython", line 18, in import IPython File "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/lib/python2.6/site-packages/IPython/__init__.py", line 58, in __import__(name,glob,loc,[]) File "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/lib/python2.6/site-packages/IPython/ipstruct.py", line 22, in from IPython.genutils import list2dict2 File "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/lib/python2.6/site-packages/IPython/genutils.py", line 59, in from IPython.external.path import path File "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/lib/python2.6/site-packages/IPython/external/path.py", line 35, in import md5 File "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/lib/python/md5.py", line 10, in from hashlib import md5 File "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/lib/python/hashlib.py", line 136, in md5 = __get_builtin_constructor('md5') File "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/lib/python/hashlib.py", line 63, in __get_builtin_constructor import _md5 ImportError: No module named _md5 I assume I'm missing a dependency, but what is it? Or is there something else going on? Sage worked fine in F10. This error occurred also with sage-4.0.2 in F11. TIA. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From cemeyer at u.washington.edu Sun Jul 19 21:19:50 2009 From: cemeyer at u.washington.edu (Conrad Meyer) Date: Sun, 19 Jul 2009 14:19:50 -0700 Subject: Sage in F11 In-Reply-To: <1248037544.3613.113.camel@valkyrie.localdomain> References: <1248037544.3613.113.camel@valkyrie.localdomain> Message-ID: <200907191419.50822.cemeyer@u.washington.edu> On Sunday 19 July 2009 02:05:44 pm Matthew Saltzman wrote: > Sorry to bother the -devel list with this, but nobody on fedora-list > responded to my question, and I know there is some effort to package > Sage for Fedora. I hope one of those packagers can help me out. > > I've installed sage-4.1 on F11 using the F10 binary installation > tarball. But when I run sage, it fails with the following error: > > > /usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/sage > ---------------------------------------------------------------------- > > | Sage Version 4.1, Release Date: 2009-07-09 > | | Type notebook() for the GUI, and license() for information. > | | > > > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/b >in/sage-ipython", line 18, in import IPython > File > "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/l >ib/python2.6/site-packages/IPython/__init__.py", line 58, in > __import__(name,glob,loc,[]) > File > "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/l >ib/python2.6/site-packages/IPython/ipstruct.py", line 22, in from > IPython.genutils import list2dict2 > File > "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/l >ib/python2.6/site-packages/IPython/genutils.py", line 59, in from > IPython.external.path import path > File > "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/l >ib/python2.6/site-packages/IPython/external/path.py", line 35, in > import md5 > File > "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/l >ib/python/md5.py", line 10, in from hashlib import md5 > File > "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/l >ib/python/hashlib.py", line 136, in md5 = > __get_builtin_constructor('md5') > File > "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/l >ib/python/hashlib.py", line 63, in __get_builtin_constructor import _md5 > ImportError: No module named _md5 > > I assume I'm missing a dependency, but what is it? Or is there something > else going on? > > Sage worked fine in F10. This error occurred also with sage-4.0.2 in F11. > > TIA. > -- > Matthew Saltzman > > Clemson University Math Sciences > mjs AT clemson DOT edu > http://www.math.clemson.edu/~mjs $ rpm -qf /usr/lib64/python2.6/lib-dynload/_md5module.so python-2.6-9.fc11.x86_64 I'm guessing the version of python shipped with Sage is missing the native md5 module (which is in %{_libdir}/python2.6/lib-dynload/_md5module.so on F-11). Regards, -- Conrad Meyer From ricky at fedoraproject.org Thu Jul 16 23:55:57 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 16 Jul 2009 19:55:57 -0400 Subject: CVS ctrl-c issue Message-ID: <20090716235557.GA2807@alpha.rzhou.org> Hi, we have just made some modifications to the version of cvs on cvs.fedoraproject.org that should help to prevent ctrl-c from killing notification mails at times. If anybody notices any breakage that resulted from this, please let us know. Also, if anybody has previously been able to reproduce the ctrl-c issue, we would appreciate it if you could test and make sure that it is no longer possible with the current setup. Thanks a lot, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 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 poelstra at redhat.com Mon Jul 20 03:37:51 2009 From: poelstra at redhat.com (John Poelstra) Date: Sun, 19 Jul 2009 20:37:51 -0700 Subject: Are all your Fedora 12 Features Where They Should be? Message-ID: <4A63E68F.90908@redhat.com> Thanks to everyone who helped pull together status last week. Nine days remain before Fedora 12 Feature freeze. No more features can be added after 2009-07-28. Please do a quick check to make sure your feature page is where you expect it to be. It is actively being tracked for Fedora 12 if it appears in one of the following categories: 1) https://fedoraproject.org/wiki/Category:FeatureAcceptedF12 3) https://fedoraproject.org/wiki/Category:FeatureReadyForFesco If you do you not see your feature page in any of the categories above it is *NOT* being tracked for Fedora 12. If you need help determining why, please do not hesitate to contact me. Thanks, John _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From hedayat at grad.com Mon Jul 20 05:58:31 2009 From: hedayat at grad.com (Hedayat Vatankhah) Date: Mon, 20 Jul 2009 10:28:31 +0430 Subject: Can anybody help me with this build issue? (related to pdflatex) Message-ID: <4A640787.3050609@grad.com> Hi all, Recently, one of my packages does not build against rawhide. Using pdflatex to generate documentation fails in rawhide. I don't know what's the problem specially that it seems that tex related packages have not bean changed since Fedora 11. (I can successfully build the package on an updated Fedora 11). This is the build log: https://bugzilla.redhat.com/attachment.cgi?id=353754 Thanks in Advance, Hedayat From paul at all-the-johnsons.co.uk Mon Jul 20 06:21:17 2009 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 20 Jul 2009 07:21:17 +0100 Subject: Are all your Fedora 12 Features Where They Should be? In-Reply-To: <4A63E68F.90908@redhat.com> References: <4A63E68F.90908@redhat.com> Message-ID: <1248070877.5010.4.camel@PB3.linux> Hi, > Nine days remain before Fedora 12 Feature freeze. No more features can > be added after 2009-07-28. I'm missing 2 features (still). No sound and no mounting of USB drives. I can get sound by a combination of su / chown -R paul:audio /dev/snd / exit / pulseaudio -k. USB I have to create a directory in /home/paul, su, mount /dev/sd*1 newdir and then can only do things as su to that directory, but as paul for taking from it. TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From josephine.tannhauser at googlemail.com Mon Jul 20 06:51:28 2009 From: josephine.tannhauser at googlemail.com (=?ISO-8859-1?Q?Josephine_Tannh=E4user?=) Date: Mon, 20 Jul 2009 08:51:28 +0200 Subject: Can anybody help me with this build issue? (related to pdflatex) In-Reply-To: <4A640787.3050609@grad.com> References: <4A640787.3050609@grad.com> Message-ID: <3668e9f50907192351o15160cb9qcf15a75c41d959f@mail.gmail.com> Hi Hedayat Vatankhah https://bugzilla.redhat.com/show_bug.cgi?id=508522 latex in rawhide is broken Greetings Josephine 2009/7/20 Hedayat Vatankhah > Hi all, > Recently, one of my packages does not build against rawhide. Using pdflatex > to generate documentation fails in rawhide. I don't know what's the problem > specially that it seems that tex related packages have not bean changed > since Fedora 11. (I can successfully build the package on an updated Fedora > 11). > This is the build log: > https://bugzilla.redhat.com/attachment.cgi?id=353754 > > Thanks in Advance, > Hedayat > > -- > 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 Mon Jul 20 06:52:30 2009 From: tomek at pipebreaker.pl (Tomasz Torcz) Date: Mon, 20 Jul 2009 08:52:30 +0200 Subject: Are all your Fedora 12 Features Where They Should be? In-Reply-To: <1248070877.5010.4.camel@PB3.linux> References: <4A63E68F.90908@redhat.com> <1248070877.5010.4.camel@PB3.linux> Message-ID: <20090720065230.GA29892@mother.pipebreaker.pl> On Mon, Jul 20, 2009 at 07:21:17AM +0100, Paul wrote: > Hi, > > > Nine days remain before Fedora 12 Feature freeze. No more features can > > be added after 2009-07-28. > > I'm missing 2 features (still). > > No sound and no mounting of USB drives. I can get sound by a combination > of su / chown -R paul:audio /dev/snd / exit / pulseaudio -k. USB I have > to create a directory in /home/paul, su, mount /dev/sd*1 newdir and then > can only do things as su to that directory, but as paul for taking from > it. Could you try running "gparted" as root after plugging USB drive? For me it triggers some kind of scan, after which proper HAL-based mount proccess works. -- Tomasz Torcz Only gods can safely risk perfection, xmpp: zdzichubg at chrome.pl it's a dangerous thing for a man. -- Alia From liangsuilong at gmail.com Mon Jul 20 07:37:59 2009 From: liangsuilong at gmail.com (=?UTF-8?B?5qKB56mX6ZqG?=) Date: Mon, 20 Jul 2009 15:37:59 +0800 Subject: Chromium-3.0.195 fails to start Message-ID: I download and install the latest rpm of chromium-3.0.195. But it fails to start. It shows us that things in gnome-terminal: [fedora at fedora-desktop disk]$ chromium-browser /usr/lib/chromium-browser/chromium-browser: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking [21121:21121:2856690408:FATAL:/mnt/chromium/rpmbuild/BUILD/chromium-20090716svn20889/src/app/gfx/font_skia.cc(90)] Check failed: tf. Could not find font: WenQuanYi Zen Hei Could not detect where Chinese fonts stays? In the older version, the error does not appear. My Fedora is Fedora 10 i386. The error also appear on Fedora 11 x86_64. Another things, chromium-3.0.195 add a new dependency: nss-mdns. I hope the bug will be fixed soon. -- http://liangsuilong.co.cc 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 sundaram at fedoraproject.org Mon Jul 20 07:45:00 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 20 Jul 2009 13:15:00 +0530 Subject: Chromium-3.0.195 fails to start In-Reply-To: References: Message-ID: <4A64207C.4020807@fedoraproject.org> On 07/20/2009 01:07 PM, ??? wrote: > I download and install the latest rpm of chromium-3.0.195. But it fails > to start. > Chromium is not in Fedora officially. You will have to contact the package maintainer directly. Rahul From frankly3d at gmail.com Mon Jul 20 07:47:20 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Mon, 20 Jul 2009 08:47:20 +0100 Subject: Chromium-3.0.195 fails to start In-Reply-To: References: Message-ID: <4A642108.8080708@gmail.com> On 20/07/09 08:37, ??? wrote: > I download and install the latest rpm of chromium-3.0.195. But it fails > to start. > I hope the bug will be fixed soon. > Not a Fedora Package. Maybe contact Google? Regards, Frank From schaiba at gmail.com Mon Jul 20 07:57:24 2009 From: schaiba at gmail.com (Aioanei Rares) Date: Mon, 20 Jul 2009 10:57:24 +0300 Subject: Chromium-3.0.195 fails to start In-Reply-To: References: Message-ID: <4A642364.1020905@gmail.com> On 07/20/2009 10:37 AM, ??? wrote: > I download and install the latest rpm of chromium-3.0.195. But it > fails to start. > > It shows us that things in gnome-terminal: > > [fedora at fedora-desktop disk]$ chromium-browser > /usr/lib/chromium-browser/chromium-browser: Symbol > `SSL_ImplementedCiphers' has different size in shared object, consider > re-linking > [21121:21121:2856690408:FATAL:/mnt/chromium/rpmbuild/BUILD/chromium-20090716svn20889/src/app/gfx/font_skia.cc(90)] > Check failed: tf. Could not find font: WenQuanYi Zen Hei > > Could not detect where Chinese fonts stays? In the older version, the > error does not appear. > > My Fedora is Fedora 10 i386. The error also appear on Fedora 11 x86_64. > > Another things, chromium-3.0.195 add a new dependency: nss-mdns. > > I hope the bug will be fixed soon. > > -- > http://liangsuilong.co.cc > Fight for freedom!!!!(3F? > Ask not what your Linux distro can do for you! > Ask what you can do for your Linux distro! AFAIK, there is a problem with nss-mdns; check bugzilla.redhat.com for that. An update will likely fix this. From thomasj at fedoraproject.org Mon Jul 20 08:24:13 2009 From: thomasj at fedoraproject.org (Thomas Janssen) Date: Mon, 20 Jul 2009 08:24:13 +0000 Subject: Chromium-3.0.195 fails to start In-Reply-To: References: Message-ID: 2009/7/20 ??? : > I download and install the latest rpm of chromium-3.0.195. But it fails to > start. Looks like you want a chromium.repo [chromium] name=Chromium Test Packages baseurl=http://spot.fedorapeople.org/chromium/F$releasever/ enabled=1 gpgcheck=0 > Another things, chromium-3.0.195 add a new dependency: nss-mdns. > > I hope the bug will be fixed soon. You can workaround that multilib/dep issue by installing the nss-mdns.x86_64 package. And a dependency isn't a bug by the way. The nss-mdns is as well installed when you install the latest wine builds. -- LG Thomas Dubium sapientiae initium From alsadi at gmail.com Mon Jul 20 08:46:44 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Mon, 20 Jul 2009 11:46:44 +0300 Subject: Are all your Fedora 12 Features Where They Should be? In-Reply-To: <20090720065230.GA29892@mother.pipebreaker.pl> References: <4A63E68F.90908@redhat.com> <1248070877.5010.4.camel@PB3.linux> <20090720065230.GA29892@mother.pipebreaker.pl> Message-ID: <385866f0907200146i5fbe00d7lfb3f326c91b3b5e4@mail.gmail.com> my feature is https://fedoraproject.org/wiki/Features/MediaRepo and the feature works, the rest is to minor fixes, license issues, communication with upstream. I've just added https://fedoraproject.org/wiki/Category:FeatureReadyForWrangler how much time do I have to make it 100% complete ? should it be 100% complete before http://fedoraproject.org/wiki/Category:FeatureReadyForFesco From rjones at redhat.com Mon Jul 20 09:43:52 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 20 Jul 2009 10:43:52 +0100 Subject: Broken dependencies in Fedora 11 - 2009-07-19 In-Reply-To: <20090719164951.21907.18514@faldor.intranet> References: <20090719164951.21907.18514@faldor.intranet> Message-ID: <20090720094352.GA8796@amd.home.annexia.org> On Sun, Jul 19, 2009 at 04:49:51PM -0000, Michael Schwendt wrote: > libguestfs We messed up the dependencies in this package when we introduced an epoch bump. Should be fixed by newer packages which are already in updates-testing. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.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 hughsient at gmail.com Mon Jul 20 12:03:10 2009 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 20 Jul 2009 13:03:10 +0100 Subject: Are all your Fedora 12 Features Where They Should be? In-Reply-To: <385866f0907200146i5fbe00d7lfb3f326c91b3b5e4@mail.gmail.com> References: <4A63E68F.90908@redhat.com> <1248070877.5010.4.camel@PB3.linux> <20090720065230.GA29892@mother.pipebreaker.pl> <385866f0907200146i5fbe00d7lfb3f326c91b3b5e4@mail.gmail.com> Message-ID: <15e53e180907200503i730c6b67n4604ce83b024e8ee@mail.gmail.com> 2009/7/20 Muayyad AlSadi : > and the feature works, the rest is to minor fixes, license issues, > communication with upstream. > how much time do I have to make it 100% complete ? > should it be 100% complete before You're going to have to sort out the licence issues and get it upstream to packagekit.org before it's going to get into F12. Getting the code into a release surely blocks this feature. Richard. From alsadi at gmail.com Mon Jul 20 12:11:11 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Mon, 20 Jul 2009 15:11:11 +0300 Subject: Are all your Fedora 12 Features Where They Should be? In-Reply-To: <15e53e180907200503i730c6b67n4604ce83b024e8ee@mail.gmail.com> References: <4A63E68F.90908@redhat.com> <1248070877.5010.4.camel@PB3.linux> <20090720065230.GA29892@mother.pipebreaker.pl> <385866f0907200146i5fbe00d7lfb3f326c91b3b5e4@mail.gmail.com> <15e53e180907200503i730c6b67n4604ce83b024e8ee@mail.gmail.com> Message-ID: <385866f0907200511qae15172i27340ad2594d367@mail.gmail.com> as I said in the IRC, I'm going to replace that file completely and things like that are the 50% I have not made yet, but should I do those now ? can't the feature be 50% complete to be Ready For Wrangler From tcallawa at redhat.com Mon Jul 20 12:12:20 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 20 Jul 2009 08:12:20 -0400 Subject: Chromium-3.0.195 fails to start In-Reply-To: References: Message-ID: <4A645F24.3070801@redhat.com> On 07/20/2009 04:24 AM, Thomas Janssen wrote: > You can workaround that multilib/dep issue by installing the > nss-mdns.x86_64 package. And a dependency isn't a bug by the way. The > nss-mdns is as well installed when you install the latest wine builds. No, that dependency actually is a bug because I hardcoded the %{_isa} to force it to a specific architecture target: nss-mdns(x86-32). That's wrong, it shouldn't have the hardcoding. I'll fix it in the next build. ~spot From johannbg at hi.is Mon Jul 20 12:29:14 2009 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Mon, 20 Jul 2009 12:29:14 +0000 Subject: Are all your Fedora 12 Features Where They Should be? In-Reply-To: <385866f0907200146i5fbe00d7lfb3f326c91b3b5e4@mail.gmail.com> References: <4A63E68F.90908@redhat.com> <1248070877.5010.4.camel@PB3.linux> <20090720065230.GA29892@mother.pipebreaker.pl> <385866f0907200146i5fbe00d7lfb3f326c91b3b5e4@mail.gmail.com> Message-ID: <4A64631A.60907@hi.is> On 07/20/2009 08:46 AM, Muayyad AlSadi wrote: > my feature is > https://fedoraproject.org/wiki/Features/MediaRepo > > Will this support usb key's as well ? JBG -------------- next part -------------- A non-text attachment was scrubbed... Name: johannbg.vcf Type: text/x-vcard Size: 356 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Mon Jul 20 12:31:52 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 20 Jul 2009 14:31:52 +0200 Subject: Rawhide fonts problem report for 2009-07-20 Message-ID: <1248093112.13758.5.camel@arekh.okg> Statistics: ? packages that declare font metadata: ? 1287 files (327 MiB) in 276 packages (204 MiB) generated from 119 source packages. Format Files rpm srpm Files (MiB) rpm (MiB) CFF 115 46 34 7 8 PCF 204 6 6 32 52 TrueType 400 203 76 243 130 Type 1 231 22 6 13 13 Format Files rpm srpm Files (MiB) rpm (MiB) noarch 1230 266 115 324 202 x86_64 57 10 4 2 1 ? File size is computed as extracted, while rpm is a compressed format. ? Mid-term, files in legacy PCF or Type1 formats need to be converted or removed. ? font files in other packages (we should not find any!) ? 4716 files (137 MiB) in 90 packages (816 MiB) generated from 52 source packages. Format Files rpm srpm Files (MiB) rpm (MiB) CFF 106 3 2 12 241 PCF 872 10 5 13 55 TrueType 138 48 34 39 533 Type 1 1075 12 9 47 256 Format Files rpm srpm Files (MiB) rpm (MiB) i586 38 6 6 0 31 noarch 4516 53 22 118 532 x86_64 162 31 29 18 252 ? Bad packaging may result in arched packages or mixed content. Problem report: ? font files in arch packages: a2ps.i586 a2ps.x86_64 faust-doc.x86_64 flumotion.x86_64 glob2.x86_64 GraphicsMagick-perl.x86_64 groff.x86_64 hedgewars.x86_64 ImageMagick-perl.x86_64 jfbterm.x86_64 k3d.x86_64 kdebase3.x86_64 kdebase-workspace.i586 kdebase-workspace.x86_64 kst.i586 kst.x86_64 libdockapp-fonts.x86_64 libeXosip2-devel.i586 libeXosip2-devel.x86_64 [lilypond-aybabtu-fonts.x86_64] [lilypond-century-schoolbook-l-fonts.x86_64] [lilypond-emmentaler-fonts.x86_64] [lilypond-feta-alphabet-fonts.x86_64] [lilypond-feta-braces-fonts.x86_64] [lilypond-feta-fonts.x86_64] [lilypond-parmesan-fonts.x86_64] manaworld.x86_64 [mscore-fonts.x86_64] nethack-vultures.x86_64 [openoffice.org-opensymbol-fonts.x86_64] openscap-devel.i586 openscap-devel.x86_64 poker2d.x86_64 pygame.x86_64 rosegarden4-feta-fonts.x86_64 rosegarden4-parmesan-fonts.x86_64 scim-doc.x86_64 TeXmacs.x86_64 tuxpaint.x86_64 tuxtype2.x86_64 widelands.x86_64 wine-core.i586 x3270-x11.x86_64 xpilot-ng-server.x86_64 xpilot-ng.x86_64 xplanet.x86_64 [zvbi-fonts.x86_64] ? 257 files (21 MiB) in 47 packages (285 MiB) generated from 34 source packages. ? font files installed outside /usr/share/fonts: a2ps e16-themes faust-doc flumotion glob2 GraphicsMagick-perl groff hedgewars ImageMagick-perl k3d kdebase3 kdebase-workspace kst libdockapp-fonts libeXosip2-devel manaworld nethack-vultures openscap-devel pgfouine phoronix-test-suite poker2d poker3d-data pygame python-reportlab scim-doc seahorse-adventures stxxl-doc texlive-texmf-doc texlive-texmf-fonts TeXmacs tuxpaint tuxtype2 widelands wine-core x3270-x11 xorg-x11-fonts-100dpi xorg-x11-fonts-75dpi xorg-x11-fonts-cyrillic xorg-x11-fonts-ethiopic xorg-x11-fonts-ISO8859-1-100dpi xorg-x11-fonts-ISO8859-14-100dpi xorg-x11-fonts-ISO8859-14-75dpi xorg-x11-fonts-ISO8859-15-100dpi xorg-x11-fonts-ISO8859-15-75dpi xorg-x11-fonts-ISO8859-1-75dpi xorg-x11-fonts-ISO8859-2-100dpi xorg-x11-fonts-ISO8859-2-75dpi xorg-x11-fonts-ISO8859-9-100dpi xorg-x11-fonts-ISO8859-9-75dpi xorg-x11-fonts-misc xorg-x11-fonts-Type1 xpilot-ng xpilot-ng-server xplanet yofrankie-bge ? 3978 files (95 MiB) in 60 packages (786 MiB) generated from 38 source packages. ? Font files need to be installed under the /usr/share/fonts root for fontconfig to expose them. ? fonts in packages that contain non-font data: a2ps e16-themes flumotion fonts-ISO8859-2 fonts-ISO8859-2-100dpi fonts-ISO8859-2-75dpi glob2 GraphicsMagick-perl groff hedgewars ImageMagick-perl [japanese-bitmap-fonts] jfbterm k3d kdebase3 kdebase-workspace kst libdockapp-fonts libeXosip2-devel manaworld mathml-fonts nethack-vultures openscap-devel pgfouine phoronix-test-suite poker2d poker3d-data pygame python-reportlab seahorse-adventures taipeifonts texlive-texmf-doc texlive-texmf-fonts TeXmacs tuxpaint tuxtype2 widelands wine-core [wqy-zenhei-fonts] x3270-x11 xorg-x11-fonts-100dpi xorg-x11-fonts-75dpi xorg-x11-fonts-cyrillic xorg-x11-fonts-ethiopic xorg-x11-fonts-ISO8859-1-100dpi xorg-x11-fonts-ISO8859-14-100dpi xorg-x11-fonts-ISO8859-14-75dpi xorg-x11-fonts-ISO8859-15-100dpi xorg-x11-fonts-ISO8859-15-75dpi xorg-x11-fonts-ISO8859-1-75dpi xorg-x11-fonts-ISO8859-2-100dpi xorg-x11-fonts-ISO8859-2-75dpi xorg-x11-fonts-ISO8859-9-100dpi xorg-x11-fonts-ISO8859-9-75dpi xorg-x11-fonts-misc xorg-x11-fonts-Type1 xpilot-ng xpilot-ng-server xplanet yofrankie-bge ? 4639 files (139 MiB) in 65 packages (813 MiB) generated from 41 source packages. ? Every font should be installable as-is without pulling in other material. ? fonts in packages that do not declare font metadata: a2ps baekmuk-bdf-fonts e16-themes faust-doc flumotion fonts-hebrew-fancy fonts-ISO8859-2 fonts-ISO8859-2-100dpi fonts-ISO8859-2-75dpi fonts-KOI8-R fonts-KOI8-R-100dpi fonts-KOI8-R-75dpi ghostscript-fonts glob2 GraphicsMagick-perl groff hedgewars ImageMagick-perl jfbterm jisksp16-1990-fonts k3d kdebase3 kdebase-workspace kst libdockapp-fonts libeXosip2-devel manaworld mathml-fonts myanmar3-unicode-fonts nethack-vultures openscap-devel padauk-fonts pgfouine phoronix-test-suite poker2d poker3d-data pygame python-reportlab rosegarden4-feta-fonts rosegarden4-parmesan-fonts scim-doc seahorse-adventures stxxl-doc taipeifonts texlive-texmf-doc texlive-texmf-fonts TeXmacs tuxpaint tuxtype2 un-extra-fonts-bom un-extra-fonts-jamobatang un-extra-fonts-jamodotum un-extra-fonts-jamonovel un-extra-fonts-jamosora un-extra-fonts-pen un-extra-fonts-penheulim un-extra-fonts-pilgia un-extra-fonts-shinmun un-extra-fonts-taza un-extra-fonts-vada un-extra-fonts-yetgul urw-fonts widelands wine-core x3270-x11 xorg-x11-fonts-100dpi xorg-x11-fonts-75dpi xorg-x11-fonts-cyrillic xorg-x11-fonts-ethiopic xorg-x11-fonts-ISO8859-1-100dpi xorg-x11-fonts-ISO8859-14-100dpi xorg-x11-fonts-ISO8859-14-75dpi xorg-x11-fonts-ISO8859-15-100dpi xorg-x11-fonts-ISO8859-15-75dpi xorg-x11-fonts-ISO8859-1-75dpi xorg-x11-fonts-ISO8859-2-100dpi xorg-x11-fonts-ISO8859-2-75dpi xorg-x11-fonts-ISO8859-9-100dpi xorg-x11-fonts-ISO8859-9-75dpi xorg-x11-fonts-misc xorg-x11-fonts-Type1 xpilot-ng xpilot-ng-server xplanet yofrankie-bge ? 4716 files (137 MiB) in 90 packages (816 MiB) generated from 52 source packages. ? Automatic font installation relies on this metadata being present to work. ? fonts in packages that do not use font package naming conventions: a2ps blender cave9 childsplay cjkuni-fonts-compat directfb e16 e16-themes [efont-unicode-bdf] egoboo-data ember-media enigma extremetuxracer faust-doc fillets-ng-data flumotion fonts-hebrew-fancy fonts-ISO8859-2 fonts-ISO8859-2-100dpi fonts-ISO8859-2-75dpi fonts-KOI8-R fonts-KOI8-R-100dpi fonts-KOI8-R-75dpi freecol glob2 gnubg GraphicsMagick-perl groff hedgewars htmldoc ImageMagick-perl jfbterm k3d kdebase3 kdebase-workspace [knm_new-fonts] kst libeXosip2-devel libprojectM lincity-ng-data manaworld mapserver moodle moodle-km moodle-sm moodle-to munin nethack-vultures neverball nted ogre-samples openscap-devel pgfouine phoronix-test-suite php-ZendFramework-tests poker2d poker3d-data pokerth pygame python-reportlab rosegarden4 scim-doc scorched3d sdljava-demo seahorse-adventures simspark spring stellarium stxxl-doc taipeifonts tex-cm-lgc tex-kerkis texlive-texmf-doc TeXmacs TnL-data trackballs tuxpaint tuxtype2 un-extra-fonts-bom un-extra-fonts-jamobatang un-extra-fonts-jamodotum un-extra-fonts-jamonovel un-extra-fonts-jamosora un-extra-fonts-pen un-extra-fonts-penheulim un-extra-fonts-pilgia un-extra-fonts-shinmun un-extra-fonts-taza un-extra-fonts-vada un-extra-fonts-yetgul wesnoth-data widelands wine-core wormux-data x3270-x11 xmoto xorg-x11-fonts-100dpi xorg-x11-fonts-75dpi xorg-x11-fonts-cyrillic xorg-x11-fonts-ethiopic xorg-x11-fonts-ISO8859-1-100dpi xorg-x11-fonts-ISO8859-14-100dpi xorg-x11-fonts-ISO8859-14-75dpi xorg-x11-fonts-ISO8859-15-100dpi xorg-x11-fonts-ISO8859-15-75dpi xorg-x11-fonts-ISO8859-1-75dpi xorg-x11-fonts-ISO8859-2-100dpi xorg-x11-fonts-ISO8859-2-75dpi xorg-x11-fonts-ISO8859-9-100dpi xorg-x11-fonts-ISO8859-9-75dpi xorg-x11-fonts-misc xorg-x11-fonts-Type1 xpilot-ng xpilot-ng-server xplanet yofrankie-bge ? 3787 files (100 MiB) in 124 packages (1722 MiB) generated from 82 source packages. ? fonts that declare face attributes in family names: Antykwa Torunska Condensed texlive-texmf-fonts BPG Nino Medium Cond GPL&GNU [bpg-nino-medium-cond-fonts] BPG Nino Medium GPL&GNU [bpg-nino-medium-fonts] BPG Sans Medium GPL&GNU [bpg-sans-medium-fonts] BPG Sans Regular GPL&GNU [bpg-sans-regular-fonts] Charis SIL Compact [sil-charis-compact-fonts] cursor_large_black.pcf kdebase3 kdebase-workspace Ethiopic WashRa Bold [senamirmir-washra-fonts] Gentium Book Basic [sil-gentium-basic-book-fonts] Hershey-Plain-Duplex-Italic ghostscript-fonts Hershey-Plain-Triplex-Italic ghostscript-fonts Khmer OS Muol Light [khmeros-muol-fonts] LMRoman10 Demi texlive-texmf-fonts LMRoman10 Oblique texlive-texmf-fonts LMRoman10 Regular texlive-texmf-fonts LMRoman12 Oblique texlive-texmf-fonts LMRoman12 Regular texlive-texmf-fonts LMRoman17 Regular texlive-texmf-fonts LMRoman5 Regular texlive-texmf-fonts LMRoman6 Regular texlive-texmf-fonts LMRoman7 Regular texlive-texmf-fonts LMRoman8 Oblique texlive-texmf-fonts LMRoman8 Regular texlive-texmf-fonts LMRoman9 Oblique texlive-texmf-fonts LMRoman9 Regular texlive-texmf-fonts LMSans10 Regular texlive-texmf-fonts LMSans12 Regular texlive-texmf-fonts LMSans17 Regular texlive-texmf-fonts LMSans8 Regular texlive-texmf-fonts LMSans9 Regular texlive-texmf-fonts LMSansExt8 Regular texlive-texmf-fonts LMTypewriter10 Oblique texlive-texmf-fonts LMTypewriter10 Regular texlive-texmf-fonts LMTypewriter12 Regular texlive-texmf-fonts LMTypewriter8 Regular texlive-texmf-fonts LMTypewriter9 Regular texlive-texmf-fonts LMTypewriterProp10 Regular texlive-texmf-fonts Serafettin Cartoon Condensed [serafettin-cartoon-fonts] Silkscreen Expanded [silkscreen-expanded-fonts] ? 84 files (14 MiB) in 15 packages (99 MiB) generated from 11 source packages. ? To be properly processed by applications face qualifiers need to be declared in face names (there may be a few false positives here as some common face qualifiers can be used with a different meaning in family names; if that's not the case, please ask the font upstream to fix its naming). ? fonts that declare non-WWS compliant faces: Aharoni CLM, Book Oblique [culmus-aharoni-clm-fonts] AirCut, OneHundedandOne e16-themes AntykwaPoltawskiego, BoldItalic texlive-texmf-fonts AntykwaTorunska, BoldItalic texlive-texmf-fonts AntykwaTorunskaCond, BoldItalic texlive-texmf-fonts AntykwaTorunskaCond, Med-Italic texlive-texmf-fonts AntykwaTorunskaCond, Med-Regular texlive-texmf-fonts AntykwaTorunskaLigh, t-Italic texlive-texmf-fonts AntykwaTorunskaLigh, t-Regular texlive-texmf-fonts Aurulent Sans, BoldItalic [hartke-aurulent-sans-fonts] Century Schoolbook L, BoldItalic [lilypond-century-schoolbook-l-fonts] Century Schoolbook L, Roma [lilypond-century-schoolbook-l-fonts] Comic040Sans040MS0408b, 040Bold texlive-texmf-fonts Comic040Sans040MS0408b, 040Bold040Italic texlive-texmf-fonts Comic040Sans040MS0408b, 040Italic texlive-texmf-fonts David CLM, BoldItalic [culmus-david-clm-fonts] David CLM, MediumItalic [culmus-david-clm-fonts] DejaVu LGC Sans, Condensed Bold [dejavu-lgc-sans-fonts] DejaVu LGC Sans, Condensed Bold Oblique [dejavu-lgc-sans-fonts] DejaVu LGC Serif, Condensed Bold [dejavu-lgc-serif-fonts] DejaVu LGC Serif, Condensed Bold Italic [dejavu-lgc-serif-fonts] DejaVu Sans, Condensed Bold [dejavu-sans-fonts] DejaVu Sans, Condensed Bold Oblique [dejavu-sans-fonts] DejaVu Serif, Condensed Bold [dejavu-serif-fonts] DejaVu Serif, Condensed Bold Italic [dejavu-serif-fonts] Edrip, BoldItalic [apanov-edrip-fonts] Emmentaler, 11 [lilypond-emmentaler-fonts] Emmentaler, 13 [lilypond-emmentaler-fonts] Emmentaler, 14 [lilypond-emmentaler-fonts] Emmentaler, 16 [lilypond-emmentaler-fonts] Emmentaler, 18 [lilypond-emmentaler-fonts] Emmentaler, 20 [lilypond-emmentaler-fonts] Emmentaler, 23 [lilypond-emmentaler-fonts] Emmentaler, 26 [lilypond-emmentaler-fonts] Essays1743, BoldItalic [thibault-essays1743-fonts] European Computer Modern, Bold Extended 10pt TeXmacs European Computer Modern, Italic Regular 10pt TeXmacs European Computer Modern, Oblique Regular 10pt TeXmacs European Computer Modern, Regular Extended 10pt TeXmacs European Computer Modern, Roman Regular 10pt TeXmacs European Computer Modern Sans, Regular 10pt TeXmacs European Computer Modern, Small caps Regular 10pt TeXmacs European Computer Modern Typewriter, Regular 10pt TeXmacs feta11, .22 [lilypond-feta-fonts] feta14, .14 [lilypond-feta-fonts] feta-alphabet11, .22 [lilypond-feta-alphabet-fonts] feta-alphabet14, .14 [lilypond-feta-alphabet-fonts] feta-braces-a, 20 [lilypond-feta-braces-fonts] feta-braces-b, 40 [lilypond-feta-braces-fonts] feta-braces-c, 60 [lilypond-feta-braces-fonts] feta-braces-d, 80 [lilypond-feta-braces-fonts] feta-braces-e, 100 [lilypond-feta-braces-fonts] feta-braces-f, 120 [lilypond-feta-braces-fonts] feta-braces-g, 140 [lilypond-feta-braces-fonts] feta-braces-h, 160 [lilypond-feta-braces-fonts] feta-braces-i, 180 [lilypond-feta-braces-fonts] Fixed, ja xorg-x11-fonts-misc Fixed, ko xorg-x11-fonts-misc Fixed, Oblique SemiCondensed xorg-x11-fonts-misc FreeMono, BoldOblique [gnu-free-mono-fonts] tuxpaint FreeSans, BoldOblique [gnu-free-sans-fonts] tuxpaint xpilot-ng xpilot-ng-server FreeSerif, BoldItalic [gnu-free-serif-fonts] tuxpaint fxd, Bold Italic semicondensed [japanese-bitmap-fonts] fxd, Italic semicondensed [japanese-bitmap-fonts] Garuda, BoldOblique [thai-scalable-garuda-fonts] Geometr415 Lt BT, Lite e16-themes Geometr415 Lt BT, Lite Italic e16-themes , Gothic-Regular [sazanami-gothic-fonts] tuxpaint Heuristica, BoldItalic [apanov-heuristica-fonts] Inuit, b texlive-texmf-fonts Inuit, o texlive-texmf-fonts Kerkis, Bold SmallCaps [ctan-kerkis-serif-fonts] KerkisSans, SmallCaps [ctan-kerkis-sans-fonts] Kerkis, Small Caps [ctan-kerkis-serif-fonts] Kinnari, BoldItalic [thai-scalable-kinnari-fonts] Kinnari, BoldOblique [thai-scalable-kinnari-fonts] Laconic, Shadow [woodardworks-laconic-shadow-fonts] Latin Modern Typewriter, Regular 10 texlive-texmf-fonts LettErrorRobot, Chrome python-reportlab Letters Laughing, at their Execution [chisholm-letterslaughing-fonts] Letters Laughing, by Quantized and Calibrated [chisholm-letterslaughing-fonts] Letters Laughing, Dissection and Destruction [chisholm-letterslaughing-fonts] LilyPond-feta-nummer-rosegarden, 10 rosegarden4-feta-fonts LilyPond-feta-rosegarden, 20 rosegarden4-feta-fonts LilyPond-parmesan-rosegarden, 20 rosegarden4-parmesan-fonts LMMathItalic10, BoldItalic texlive-texmf-fonts LMMathItalic5, BoldItalic texlive-texmf-fonts LMMathItalic7, BoldItalic texlive-texmf-fonts LMMathSymbols10, BoldItalic texlive-texmf-fonts LMMathSymbols5, BoldItalic texlive-texmf-fonts LMMathSymbols7, BoldItalic texlive-texmf-fonts LMRoman10, BoldItalic texlive-texmf-fonts LMRoman10, BoldOblique texlive-texmf-fonts LMRoman10, CapsOblique texlive-texmf-fonts LMRoman10, CapsRegular texlive-texmf-fonts LMRoman10, DemiOblique texlive-texmf-fonts LMRoman10, Dunhill texlive-texmf-fonts LMRoman10, DunhillOblique texlive-texmf-fonts LMRoman10, Unslanted texlive-texmf-fonts LMSans10, BoldOblique texlive-texmf-fonts LMSans10, DemiCondensed texlive-texmf-fonts LMSans10, DemiCondensedOblique texlive-texmf-fonts LMSansQuotation8, BoldOblique texlive-texmf-fonts LMTypewriter10, CapsOblique texlive-texmf-fonts LMTypewriter10, CapsRegular texlive-texmf-fonts LMTypewriter10, Dark texlive-texmf-fonts LMTypewriter10, DarkOblique texlive-texmf-fonts LMTypewriter10, LightCondensed texlive-texmf-fonts LMTypewriter10, LightCondensedOblique texlive-texmf-fonts LMTypewriter10, LightOblique texlive-texmf-fonts LMTypewriterVarWd10, Dark texlive-texmf-fonts LMTypewriterVarWd10, DarkOblique texlive-texmf-fonts LMTypewriterVarWd10, LightOblique texlive-texmf-fonts Loma, BoldOblique [thai-scalable-loma-fonts] Lucida, Sans xorg-x11-fonts-100dpi xorg-x11-fonts-75dpi xorg-x11-fonts-ISO8859-1-100dpi xorg-x11-fonts-ISO8859-1-75dpi Lucida, Sans Bold xorg-x11-fonts-100dpi xorg-x11-fonts-75dpi xorg-x11-fonts-ISO8859-1-100dpi xorg-x11-fonts-ISO8859-1-75dpi Lucida, Sans Bold Italic xorg-x11-fonts-100dpi xorg-x11-fonts-75dpi xorg-x11-fonts-ISO8859-1-100dpi xorg-x11-fonts-ISO8859-1-75dpi Lucida, Sans Italic xorg-x11-fonts-100dpi xorg-x11-fonts-75dpi xorg-x11-fonts-ISO8859-1-100dpi xorg-x11-fonts-ISO8859-1-75dpi LucidaTypewriter, Sans xorg-x11-fonts-100dpi xorg-x11-fonts-75dpi xorg-x11-fonts-ISO8859-1-100dpi xorg-x11-fonts-ISO8859-1-75dpi LucidaTypewriter, Sans Bold xorg-x11-fonts-100dpi xorg-x11-fonts-75dpi xorg-x11-fonts-ISO8859-1-100dpi xorg-x11-fonts-ISO8859-1-75dpi MathDesign-CH, Bold Extension 10 texlive-texmf-fonts MathDesign-CH, Bold Italic MathItalic 10 texlive-texmf-fonts MathDesign-CH, Bold Italic OT1 10 texlive-texmf-fonts MathDesign-CH, Bold Italic T1 10 texlive-texmf-fonts MathDesign-CH, Bold Italic TS1 10 texlive-texmf-fonts MathDesign-CH, Bold MathDesignSymbolA 10 texlive-texmf-fonts MathDesign-CH, Bold MathDesignSymbolB 10 texlive-texmf-fonts MathDesign-CH, Bold MathItalic 10 texlive-texmf-fonts MathDesign-CH, Bold OT1 10 texlive-texmf-fonts MathDesign-CH, Bold Symbol 10 texlive-texmf-fonts MathDesign-CH, Bold T1 10 texlive-texmf-fonts MathDesign-CH, Bold TS1 10 texlive-texmf-fonts MathDesign-CH, Regular 10 texlive-texmf-fonts MathDesign-CH, Regular Extension 10 texlive-texmf-fonts MathDesign-CH, Regular Italic MathItalic 10 texlive-texmf-fonts MathDesign-CH, Regular Italic OT1 10 texlive-texmf-fonts MathDesign-CH, Regular Italic OT1 5 texlive-texmf-fonts MathDesign-CH, Regular Italic OT1 6 texlive-texmf-fonts MathDesign-CH, Regular Italic OT1 7 texlive-texmf-fonts MathDesign-CH, Regular Italic OT1 8 texlive-texmf-fonts MathDesign-CH, Regular Italic OT1 9 texlive-texmf-fonts MathDesign-CH, Regular Italic T1 10 texlive-texmf-fonts MathDesign-CH, Regular Italic TS1 10 texlive-texmf-fonts MathDesign-CH, Regular MathDesignSymbolA 10 texlive-texmf-fonts MathDesign-CH, Regular MathDesignSymbolB 10 texlive-texmf-fonts MathDesign-CH, Regular MathItalic 10 texlive-texmf-fonts MathDesign-CH, Regular OT1 10 texlive-texmf-fonts MathDesign-CH, Regular OT1 5 texlive-texmf-fonts MathDesign-CH, Regular OT1 6 texlive-texmf-fonts MathDesign-CH, Regular OT1 7 texlive-texmf-fonts MathDesign-CH, Regular OT1 8 texlive-texmf-fonts MathDesign-CH, Regular OT1 9 texlive-texmf-fonts MathDesign-CH, Regular Symbol 10 texlive-texmf-fonts MathDesign-CH, Regular T1 10 texlive-texmf-fonts MathDesign-CH, Regular TS1 10 texlive-texmf-fonts MathDesign-GM, Medium Extension 10 texlive-texmf-fonts MathDesign-GM, Medium Italic MathItalic 10 texlive-texmf-fonts MathDesign-GM, Medium Italic OT1 10 texlive-texmf-fonts MathDesign-GM, Medium Italic T1 10 texlive-texmf-fonts MathDesign-GM, Medium Italic TS1 10 texlive-texmf-fonts MathDesign-GM, Medium MathDesignSymbolA 10 texlive-texmf-fonts MathDesign-GM, Medium MathDesignSymbolB 10 texlive-texmf-fonts MathDesign-GM, Medium MathItalic 10 texlive-texmf-fonts MathDesign-GM, Medium OT1 10 texlive-texmf-fonts MathDesign-GM, Medium Symbol 10 texlive-texmf-fonts MathDesign-GM, Medium T1 10 texlive-texmf-fonts MathDesign-GM, Medium TS1 10 texlive-texmf-fonts MathDesign-GM, Regular Extension 10 texlive-texmf-fonts MathDesign-GM, Regular Italic MathItalic 10 texlive-texmf-fonts MathDesign-GM, Regular Italic OT1 10 texlive-texmf-fonts MathDesign-GM, Regular Italic T1 10 texlive-texmf-fonts MathDesign-GM, Regular Italic TS1 10 texlive-texmf-fonts MathDesign-GM, Regular MathDesignSymbolA 10 texlive-texmf-fonts MathDesign-GM, Regular MathDesignSymbolB 10 texlive-texmf-fonts MathDesign-GM, Regular MathItalic 10 texlive-texmf-fonts MathDesign-GM, Regular OT1 10 texlive-texmf-fonts MathDesign-GM, Regular Symbol 10 texlive-texmf-fonts MathDesign-GM, Regular T1 10 texlive-texmf-fonts MathDesign-GM, Regular TS1 10 texlive-texmf-fonts MathDesign-UT, Bold Extension 10 texlive-texmf-fonts MathDesign-UT, Bold Italic MathItalic 10 texlive-texmf-fonts MathDesign-UT, Bold Italic OT1 10 texlive-texmf-fonts MathDesign-UT, Bold Italic T1 10 texlive-texmf-fonts MathDesign-UT, Bold Italic TS1 10 texlive-texmf-fonts MathDesign-UT, Bold MathDesignSymbolA 10 texlive-texmf-fonts MathDesign-UT, Bold MathDesignSymbolB 10 texlive-texmf-fonts MathDesign-UT, Bold MathItalic 10 texlive-texmf-fonts MathDesign-UT, Bold OT1 10 texlive-texmf-fonts MathDesign-UT, Bold Symbol 10 texlive-texmf-fonts MathDesign-UT, Bold T1 10 texlive-texmf-fonts MathDesign-UT, Bold TS1 10 texlive-texmf-fonts MathDesign-UT, Regular Extension 10 texlive-texmf-fonts MathDesign-UT, Regular Italic MathItalic 10 texlive-texmf-fonts MathDesign-UT, Regular Italic OT1 10 texlive-texmf-fonts MathDesign-UT, Regular Italic T1 10 texlive-texmf-fonts MathDesign-UT, Regular Italic TS1 10 texlive-texmf-fonts MathDesign-UT, Regular MathDesignSymbolA 10 texlive-texmf-fonts MathDesign-UT, Regular MathDesignSymbolB 10 texlive-texmf-fonts MathDesign-UT, Regular MathItalic 10 texlive-texmf-fonts MathDesign-UT, Regular OT1 10 texlive-texmf-fonts MathDesign-UT, Regular Symbol 10 texlive-texmf-fonts MathDesign-UT, Regular T1 10 texlive-texmf-fonts MathDesign-UT, Regular TS1 10 texlive-texmf-fonts MgOpen Modata, BoldOblique [mgopen-modata-fonts] MgOpen Moderna, BoldOblique [mgopen-moderna-fonts] , Mincho-Regular [sazanami-mincho-fonts] Miriam Mono CLM, Book Oblique [culmus-miriam-mono-clm-fonts] MScore1, 20 [mscore-fonts] MScore, 20 [mscore-fonts] Nimbus Mono L, Regular Oblique texlive-texmf-fonts urw-fonts Nimbus Roman No9 L, Regular Italic texlive-texmf-fonts urw-fonts Nimbus Sans L, Regular Condensed texlive-texmf-fonts urw-fonts Nimbus Sans L, Regular Condensed Italic texlive-texmf-fonts urw-fonts Nimbus Sans L, Regular Italic texlive-texmf-fonts urw-fonts Norasi, BoldItalic [thai-scalable-norasi-fonts] Norasi, BoldOblique [thai-scalable-norasi-fonts] ntedfont, 20 [nted-ntedfont-fonts] OmegaSerifCommon, BoldItalic texlive-texmf-fonts OmegaSerifGreek, BoldItalic texlive-texmf-fonts OmegaSerifLatin, BoldItalic texlive-texmf-fonts PaperCuts 2.0, BoldOblique [extremetuxracer-papercuts-fonts] [extremetuxracer-papercuts-outline-fonts] parmesan11, .22 [lilypond-parmesan-fonts] parmesan14, .14 [lilypond-parmesan-fonts] PLMathItalic10, BoldItalic texlive-texmf-fonts PLMathSymbols10, BoldItalic texlive-texmf-fonts PLRoman10, BoldItalic texlive-texmf-fonts PLSans10, BoldItalic texlive-texmf-fonts PLSlanted10, BoldItalic texlive-texmf-fonts QuasiChancery, MediumItalic texlive-texmf-fonts QuasiCourier, BoldItalic texlive-texmf-fonts QuasiCourier, RegularItalic texlive-texmf-fonts QuasiCourierTTF, Regular Italic texlive-texmf-fonts QuasiSwiss, BoldItalic texlive-texmf-fonts QuasiSwissCondensed, BoldItalic texlive-texmf-fonts QuasiSwissCondensed, RegularItalic texlive-texmf-fonts QuasiSwissCondensedTTF, Regular Italic texlive-texmf-fonts QuasiSwiss, RegularItalic texlive-texmf-fonts QuasiSwissTTF, Regular Italic texlive-texmf-fonts RaghuMalayalam, Sans [smc-raghumalayalam-fonts] Sawasdee, BoldOblique [thai-scalable-sawasdee-fonts] Steve, Hand [sj-stevehand-fonts] TeX040cmex7, 040Regular texlive-texmf-fonts TeX040cmex8, 040Regular texlive-texmf-fonts TeX040cmex9, 040Regular texlive-texmf-fonts TeX040feybl10, 040Regular texlive-texmf-fonts TeX040feybo10, 040Regular texlive-texmf-fonts TeX040feybr10, 040Regular texlive-texmf-fonts TeX040feyml10, 040Regular texlive-texmf-fonts TeX040feymo10, 040Regular texlive-texmf-fonts TeX040feymr10, 040Regular texlive-texmf-fonts TeX040hcaption, 040Regular texlive-texmf-fonts TeX040hclassic, 040Regular texlive-texmf-fonts TeX040pccsc10, 040Regular texlive-texmf-fonts TeX040pcmi10, 040Regular texlive-texmf-fonts TeX040pcr10, 040Regular texlive-texmf-fonts TeX040pcr5, 040Regular texlive-texmf-fonts TeX040pcr6, 040Regular texlive-texmf-fonts TeX040pcr7, 040Regular texlive-texmf-fonts TeX040pcr8, 040Regular texlive-texmf-fonts TeX040pcr9, 040Regular texlive-texmf-fonts TeX040pcsl10, 040Regular texlive-texmf-fonts TeX040pcslc9, 040Regular texlive-texmf-fonts TeX040pcti10, 040Regular texlive-texmf-fonts TeXGyreBonum, BoldItalic texlive-texmf-fonts TeXGyrePagella, BoldItalic texlive-texmf-fonts TeXGyreSchola, BoldItalic texlive-texmf-fonts TeXGyreTermes, BoldItalic texlive-texmf-fonts TeX Palladio L, Bold Italic Old Style Figures texlive-texmf-fonts TeX Palladio L, Bold Old Style Figures texlive-texmf-fonts TeX Palladio L, Italic Old Style Figures texlive-texmf-fonts TeX Palladio L, Small Caps & Old Style Figures texlive-texmf-fonts TlwgMono, BoldOblique [thai-scalable-tlwgmono-fonts] TlwgTypewriter, BoldOblique [thai-scalable-tlwgtypewriter-fonts] Tlwg Typist, BoldOblique [thai-scalable-tlwgtypist-fonts] Tlwg Typo, BoldOblique [thai-scalable-tlwgtypo-fonts] Umpush, BoldOblique [thai-scalable-umpush-fonts] Umpush, LightOblique [thai-scalable-umpush-fonts] URW Bookman L, Demi Bold texlive-texmf-fonts urw-fonts URW Bookman L, Demi Bold Italic texlive-texmf-fonts urw-fonts URW Gothic L, Book Oblique texlive-texmf-fonts urw-fonts Vietnamese040Computer040Modern, Medium040 texlive-texmf-fonts Vn TeX Palladio L, Small Caps & Old Style Figures texlive-texmf-fonts Waree, BoldOblique [thai-scalable-waree-fonts] XYATIP, 10 texlive-texmf-fonts XYBSQL, 10 texlive-texmf-fonts XYBTIP, 10 texlive-texmf-fonts XYCIRC, 10 texlive-texmf-fonts XYCMAT, 10 texlive-texmf-fonts XYCMBT, 10 texlive-texmf-fonts XYDASH, 10 texlive-texmf-fonts XYEUAT, 10 texlive-texmf-fonts XYEUBT, 10 texlive-texmf-fonts ? 480 files (38 MiB) in 61 packages (148 MiB) generated from 29 source packages. ? This WWS-like test checks if font faces use the: ?weight width slant [regular]? naming convention. (Microsoft resolves over a combined ?Family Face? string, since our applications use ?Family? and ?Face? separately this test considers ?Face? alone. We also reject weight abbreviations and suffixes, if a font uses them check compliance manually.) If your font is listed here please ask its upstream to fix its naming. ? exact file duplication (ignoring multilib): ? Ignoring multilib to keep it short /usr/share/fonts/jfbterm/8x13-ISO8859-1.pcf.gz jfbterm.x86_64 /usr/share/X11/fonts/misc/8x13-ISO8859-1.pcf.gz xorg-x11-fonts-misc.noarch /usr/share/texmf/fonts/type1/bitstrea/charter/bchri8a.pfb texlive-texmf-fonts.noarch /usr/share/X11/fonts/Type1/c0649bt_.pfb xorg-x11-fonts-Type1.noarch /usr/share/e16/themes/BlueSteel/ABOUT/vixar.ttf e16-themes.noarch /usr/share/e16/themes/BlueSteel/ttfonts/vixar.ttf e16-themes.noarch /usr/share/tuxpaint/fonts/FreeMonoBold.ttf tuxpaint.x86_64 /usr/share/xplanet/fonts/FreeMonoBold.ttf xplanet.x86_64 /usr/share/texmf/fonts/type1/urw/zapfding/uzdr.pfb texlive-texmf-fonts.noarch /usr/share/fonts/default/Type1/d050000l.pfb urw-fonts.noarch /usr/share/texmf/fonts/type1/urw/symbol/usyr.pfb texlive-texmf-fonts.noarch /usr/share/fonts/default/Type1/s050000l.pfb urw-fonts.noarch /usr/share/fonts/default/ghostscript/putb.pfa ghostscript-fonts.noarch /usr/share/X11/fonts/Type1/UTB_____.pfa xorg-x11-fonts-Type1.noarch /usr/share/texmf/fonts/type1/adobe/courier/pcrbi8a.pfb texlive-texmf-fonts.noarch /usr/share/texmf/fonts/type1/adobe/courier/pcrbo8a.pfb texlive-texmf-fonts.noarch /usr/share/fonts/bitstream-vera/VeraIt.ttf [bitstream-vera-sans-fonts.noarch] /usr/share/k3d/fonts/VeraIt.ttf k3d.x86_64 /usr/share/poker3d/data/VeraIt.ttf poker3d-data.noarch /usr/lib/python2.6/site-packages/reportlab/fonts/VeraIt.ttf python-reportlab.noarch /usr/share/fonts/jfbterm/hanglg16.pcf.gz jfbterm.x86_64 /usr/share/X11/fonts/misc/hanglg16.pcf.gz xorg-x11-fonts-misc.noarch /usr/share/fonts/jfbterm/8x13-ISO8859-9.pcf.gz jfbterm.x86_64 /usr/share/X11/fonts/misc/8x13-ISO8859-9.pcf.gz xorg-x11-fonts-misc.noarch /usr/share/fonts/bitstream-vera/VeraMoIt.ttf [bitstream-vera-sans-mono-fonts.noarch] /usr/share/k3d/fonts/VeraMoIt.ttf k3d.x86_64 /usr/share/texmf/fonts/type1/bitstrea/charter/bchbi8a.pfb texlive-texmf-fonts.noarch /usr/share/X11/fonts/Type1/c0633bt_.pfb xorg-x11-fonts-Type1.noarch /usr/share/xpilot-ng/fonts/FreeSansBoldOblique.ttf xpilot-ng-server.x86_64 /usr/share/xpilot-ng/fonts/FreeSansBoldOblique.ttf xpilot-ng.x86_64 /usr/share/fonts/jfbterm/gb16fs.pcf.gz jfbterm.x86_64 /usr/share/X11/fonts/misc/gb16fs.pcf.gz xorg-x11-fonts-misc.noarch /usr/share/fonts/bitstream-vera/VeraMoBI.ttf [bitstream-vera-sans-mono-fonts.noarch] /usr/share/k3d/fonts/VeraMoBI.ttf k3d.x86_64 /usr/share/fonts/un-extra/UnPenheulim.ttf un-extra-fonts-penheulim.noarch /usr/share/fonts/un-extra/UnPenheulim.ttf un-extra-fonts-pen.noarch /usr/share/fonts/jfbterm/8x13-ISO8859-5.pcf.gz jfbterm.x86_64 /usr/share/X11/fonts/misc/8x13-ISO8859-5.pcf.gz xorg-x11-fonts-misc.noarch /usr/share/fonts/bitstream-vera/VeraSe.ttf [bitstream-vera-serif-fonts.noarch] /usr/share/k3d/fonts/VeraSe.ttf k3d.x86_64 /usr/games/vulturesclaw/fonts/VeraSe.ttf nethack-vultures.x86_64 /usr/games/vultureseye/fonts/VeraSe.ttf nethack-vultures.x86_64 /usr/share/e16/themes/BrushedMetal-Tigert/ABOUT/aircut3.ttf e16-themes.noarch /usr/share/e16/themes/ShinyMetal/ABOUT/aircut3.ttf e16-themes.noarch /usr/share/fonts/jfbterm/8x13-ISO8859-2.pcf.gz jfbterm.x86_64 /usr/share/X11/fonts/misc/8x13-ISO8859-2.pcf.gz xorg-x11-fonts-misc.noarch /usr/share/fonts/jfbterm/8x13-ISO8859-8.pcf.gz jfbterm.x86_64 /usr/share/X11/fonts/misc/8x13-ISO8859-8.pcf.gz xorg-x11-fonts-misc.noarch /usr/share/fonts/jfbterm/jisksp16-1990.pcf.gz jfbterm.x86_64 /usr/share/fonts/jisksp16-1990/jisksp16-1990.pcf.gz jisksp16-1990-fonts.noarch /usr/share/e16/themes/Ganymede/ABOUT/ganymede.ttf e16-themes.noarch /usr/share/e16/themes/Ganymede/ttfonts/ganymede.ttf e16-themes.noarch /usr/share/fonts/google-droid/DroidSansFallback.ttf [google-droid-sans-fonts.noarch] /usr/share/hedgewars/Data/Fonts/DroidSansFallback.ttf hedgewars.x86_64 /usr/share/fonts/jfbterm/8x13-ISO8859-14.pcf.gz jfbterm.x86_64 /usr/share/X11/fonts/misc/8x13-ISO8859-14.pcf.gz xorg-x11-fonts-misc.noarch /usr/share/texmf/fonts/type1/bitstrea/charter/bchr8a.pfb texlive-texmf-fonts.noarch /usr/share/X11/fonts/Type1/c0648bt_.pfb xorg-x11-fonts-Type1.noarch /usr/share/fonts/jfbterm/8x13-ISO8859-15.pcf.gz jfbterm.x86_64 /usr/share/X11/fonts/misc/8x13-ISO8859-15.pcf.gz xorg-x11-fonts-misc.noarch /usr/share/fonts/default/ghostscript/putri.pfa ghostscript-fonts.noarch /usr/share/X11/fonts/Type1/UTI_____.pfa xorg-x11-fonts-Type1.noarch /usr/share/fonts/default/ghostscript/putr.pfa ghostscript-fonts.noarch /usr/share/X11/fonts/Type1/UTRG____.pfa xorg-x11-fonts-Type1.noarch /usr/share/texmf/fonts/type1/adobe/courier/pcri8a.pfb texlive-texmf-fonts.noarch /usr/share/texmf/fonts/type1/adobe/courier/pcrro8a.pfb texlive-texmf-fonts.noarch /usr/share/fonts/jfbterm/8x13-ISO8859-7.pcf.gz jfbterm.x86_64 /usr/share/X11/fonts/misc/8x13-ISO8859-7.pcf.gz xorg-x11-fonts-misc.noarch /usr/share/fonts/bitstream-vera/Vera.ttf [bitstream-vera-sans-fonts.noarch] /usr/lib64/flumotion/python/flumotion/component/converters/overlay/Vera.ttf flumotion.x86_64 /usr/share/k3d/fonts/Vera.ttf k3d.x86_64 /usr/lib/python2.6/site-packages/reportlab/fonts/Vera.ttf python-reportlab.noarch /usr/share/texmf/fonts/type1/bitstrea/charter/bchb8a.pfb texlive-texmf-fonts.noarch /usr/share/X11/fonts/Type1/c0632bt_.pfb xorg-x11-fonts-Type1.noarch /usr/share/doc/faust-doc-0.9.9.4/latex/FreeSans.ttf faust-doc.x86_64 /usr/share/doc/libeXosip2-devel-3.1.0/latex/FreeSans.ttf libeXosip2-devel.i586 /usr/share/doc/openscap-devel-0.3.3/latex/FreeSans.ttf openscap-devel.i586 /usr/share/doc/scim-doc-1.4.9/html/FreeSans.ttf scim-doc.x86_64 /usr/share/doc/stxxl-doc-1.2.1/latex/FreeSans.ttf stxxl-doc.noarch /usr/share/fonts/bitstream-vera/VeraBd.ttf [bitstream-vera-sans-fonts.noarch] /usr/share/k3d/fonts/VeraBd.ttf k3d.x86_64 /usr/share/poker3d/data/VeraBd.ttf poker3d-data.noarch /usr/lib/python2.6/site-packages/reportlab/fonts/VeraBd.ttf python-reportlab.noarch /usr/share/fonts/bitstream-vera/VeraMoBd.ttf [bitstream-vera-sans-mono-fonts.noarch] /usr/share/k3d/fonts/VeraMoBd.ttf k3d.x86_64 /usr/share/xpilot-ng/fonts/VeraMoBd.ttf xpilot-ng-server.x86_64 /usr/share/xpilot-ng/fonts/VeraMoBd.ttf xpilot-ng.x86_64 /usr/share/fonts/bitstream-vera/VeraMono.ttf [bitstream-vera-sans-mono-fonts.noarch] /usr/share/k3d/fonts/VeraMono.ttf k3d.x86_64 /usr/share/fonts/bitstream-vera/VeraSeBd.ttf [bitstream-vera-serif-fonts.noarch] /usr/share/k3d/fonts/VeraSeBd.ttf k3d.x86_64 /usr/share/fonts/default/ghostscript/putbi.pfa ghostscript-fonts.noarch /usr/share/X11/fonts/Type1/UTBI____.pfa xorg-x11-fonts-Type1.noarch /usr/share/fonts/japanese/efont-unicode-bdf/b16.pcf.gz [efont-unicode-bdf.noarch] /usr/share/fonts/jfbterm/b16.pcf.gz jfbterm.x86_64 /usr/share/fonts/jfbterm/8x16.pcf.gz jfbterm.x86_64 /usr/share/X11/fonts/misc/8x16.pcf.gz xorg-x11-fonts-misc.noarch /usr/share/fonts/bitstream-vera/VeraBI.ttf [bitstream-vera-sans-fonts.noarch] /usr/share/k3d/fonts/VeraBI.ttf k3d.x86_64 /usr/share/poker3d/data/VeraBI.ttf poker3d-data.noarch /usr/lib/python2.6/site-packages/reportlab/fonts/VeraBI.ttf python-reportlab.noarch ? 101 files (14 MiB) in 30 packages (291 MiB) generated from 25 source packages. ? font faces duplicated by different packages: ? Excluding multilib and PCF fonts (because they are pretty much hopeless). 9 FreeSans Medium faust-doc [gnu-free-sans-fonts] libeXosip2-devel openscap-devel poker3d-data scim-doc stxxl-doc tuxpaint widelands 4 FreeSerif Medium [gnu-free-serif-fonts] poker2d tuxpaint widelands 4 FreeSans BoldOblique [gnu-free-sans-fonts] tuxpaint xpilot-ng xpilot-ng-server 4 FreeSans Bold [gnu-free-sans-fonts] poker3d-data pygame tuxpaint 4 Bitstream Vera Sans Roman [bitstream-vera-sans-fonts] flumotion k3d python-reportlab 4 Bitstream Vera Sans Oblique [bitstream-vera-sans-fonts] k3d poker3d-data python-reportlab 4 Bitstream Vera Sans Mono Bold [bitstream-vera-sans-mono-fonts] k3d xpilot-ng xpilot-ng-server 4 Bitstream Vera Sans Bold Oblique [bitstream-vera-sans-fonts] k3d poker3d-data python-reportlab 4 Bitstream Vera Sans Bold [bitstream-vera-sans-fonts] k3d poker3d-data python-reportlab 3 FreeMono Bold [gnu-free-mono-fonts] tuxpaint xplanet 3 DejaVu Sans Book [dejavu-sans-fonts] glob2 pgfouine 3 Bitstream Vera Serif Roman [bitstream-vera-serif-fonts] k3d nethack-vultures 2 UnPenheulim Regular un-extra-fonts-pen un-extra-fonts-penheulim 2 Tuffy Regular ImageMagick-perl [tulrich-tuffy-fonts] 2 PaperCuts 2.0 BoldOblique [extremetuxracer-papercuts-fonts] [extremetuxracer-papercuts-outline-fonts] 2 Lohit Hindi Regular [lohit-hindi-fonts] tuxtype2 2 Lohit Gujarati Regular [lohit-gujarati-fonts] tuxpaint 2 Liberation Sans Regular [liberation-sans-fonts] phoronix-test-suite 2 Garuda Bold [thai-scalable-garuda-fonts] tuxpaint 2 FreeSerif Italic [gnu-free-serif-fonts] tuxpaint 2 FreeSerif BoldItalic [gnu-free-serif-fonts] tuxpaint 2 FreeSerif Bold [gnu-free-serif-fonts] tuxpaint 2 FreeSans Oblique [gnu-free-sans-fonts] tuxpaint 2 FreeMono Oblique [gnu-free-mono-fonts] tuxpaint 2 FreeMono Medium [gnu-free-mono-fonts] tuxpaint 2 FreeMono BoldOblique [gnu-free-mono-fonts] tuxpaint 2 Droid Sans Fallback Regular [google-droid-sans-fonts] hedgewars 2 Doulos SIL Regular [sil-doulos-fonts] tuxtype2 2 DejaVu Sans Condensed [dejavu-sans-fonts] tuxpaint 2 DejaVu Sans Bold [dejavu-sans-fonts] manaworld 2 Bitstream Vera Serif Bold [bitstream-vera-serif-fonts] k3d 2 Bitstream Vera Sans Mono Roman [bitstream-vera-sans-mono-fonts] k3d 2 Bitstream Vera Sans Mono Oblique [bitstream-vera-sans-mono-fonts] k3d 2 Bitstream Vera Sans Mono Bold Oblique [bitstream-vera-sans-mono-fonts] k3d ? 95 files (26 MiB) in 42 packages (279 MiB) generated from 34 source packages. ? Face duplication wastes resources infrastructure and user side. Very often an upstream that copied some fonts will forget to keep them up to date, and the duplication will result in the distribution of old buggy data. Even if some duplicate font files are a genuine fork with different features from the original, applications won't be able to select them relyably because of naming collisions. We should alway ship a single version of any font face in a dedicated font package, and use fontconfig or symlinks to share it accross packages. ? font faces duplicated within a package (ignoring legacy formats): dejavu-lgc-serif-fonts DejaVu LGC Serif Condensed /usr/share/fonts/dejavu/DejaVuLGCSerifCondensed-Italic.ttf dejavu-lgc-serif-fonts DejaVu LGC Serif Condensed /usr/share/fonts/dejavu/DejaVuLGCSerifCondensed.ttf dejavu-serif-fonts DejaVu Serif Condensed /usr/share/fonts/dejavu/DejaVuSerifCondensed-Italic.ttf dejavu-serif-fonts DejaVu Serif Condensed /usr/share/fonts/dejavu/DejaVuSerifCondensed.ttf e16-themes AirCut OneHundedandOne /usr/share/e16/themes/BrushedMetal-Tigert/ABOUT/aircut3.ttf e16-themes AirCut OneHundedandOne /usr/share/e16/themes/ShinyMetal/ABOUT/aircut3.ttf e16-themes Geometr415 Lt BT Lite /usr/share/e16/themes/Ganymede/ABOUT/ganymede.ttf e16-themes Geometr415 Lt BT Lite /usr/share/e16/themes/Ganymede/ttfonts/ganymede.ttf e16-themes Vixar ASCI Regular /usr/share/e16/themes/BlueSteel/ABOUT/vixar.ttf e16-themes Vixar ASCI Regular /usr/share/e16/themes/BlueSteel/ttfonts/vixar.ttf nethack-vultures Bitstream Vera Serif Roman /usr/games/vulturesclaw/fonts/VeraSe.ttf nethack-vultures Bitstream Vera Serif Roman /usr/games/vultureseye/fonts/VeraSe.ttf stix-integrals-fonts STIXIntegrals Bold /usr/share/fonts/stix/STIXIntDisBol.otf stix-integrals-fonts STIXIntegrals Bold /usr/share/fonts/stix/STIXIntSmaBol.otf stix-integrals-fonts STIXIntegrals Bold /usr/share/fonts/stix/STIXIntUpBol.otf stix-integrals-fonts STIXIntegrals Bold /usr/share/fonts/stix/STIXIntUpDisBol.otf stix-integrals-fonts STIXIntegrals Bold /usr/share/fonts/stix/STIXIntUpSmaBol.otf stix-integrals-fonts STIXIntegrals Regular /usr/share/fonts/stix/STIXIntDis.otf stix-integrals-fonts STIXIntegrals Regular /usr/share/fonts/stix/STIXIntSma.otf stix-integrals-fonts STIXIntegrals Regular /usr/share/fonts/stix/STIXIntUpDis.otf stix-integrals-fonts STIXIntegrals Regular /usr/share/fonts/stix/STIXIntUp.otf stix-integrals-fonts STIXIntegrals Regular /usr/share/fonts/stix/STIXIntUpSma.otf xorg-x11-fonts-ethiopic Goha-Tibeb Zemen Regular /usr/share/X11/fonts/OTF/GohaTibebZemen.otf xorg-x11-fonts-ethiopic Goha-Tibeb Zemen Regular /usr/share/X11/fonts/TTF/GohaTibebZemen.ttf ? 24 files (1 MiB) in 6 packages (39 MiB) generated from 5 source packages. ? Face duplication within a package is almost certainly a bug, except for special symbol font families. ? packages that mix several font families (ignoring legacy formats): texlive-texmf-fonts (47) tuxpaint (15) mathml-fonts (10) stix-sizes-fonts (5) e16-themes (5) tuxtype2 (4) poker3d-data (4) k3d (4) wine-core (3) widelands (3) linux-libertine-fonts (3) khmeros-muol-fonts (3) khmeros-base-fonts (3) xpilot-ng-server (2) xpilot-ng (2) un-extra-fonts-pen (2) serafettin-cartoon-fonts (2) senamirmir-washra-fonts (2) python-reportlab (2) mscore-fonts (2) khmeros-handwritten-fonts (2) google-droid-sans-fonts (2) ? Reliable font autoinstallation requires shipping only one font family per font package. This indicates problems in the packaging or the packaged font metadata. ? packages that symlink font files: blender cave9 childsplay cjkuni-fonts-compat directfb e16 egoboo-data ember-media enigma extremetuxracer fillets-ng-data freecol gnubg hedgewars htmldoc libprojectM lincity-ng-data manaworld mapserver moodle moodle-km moodle-sm moodle-to munin neverball nted ogre-samples php-ZendFramework-tests pokerth rosegarden4 scorched3d sdljava-demo seahorse-adventures simspark spring stellarium tex-cm-lgc tex-kerkis TnL-data trackballs wesnoth-data wormux-data xmoto xplanet ? 206 files (0 MiB) in 47 packages (1019 MiB) generated from 41 source packages. 5 most symlinked packages: 30 dejavu-sans-fonts-0:2.29-3.fc12.noarch 8 dejavu-sans-mono-fonts-0:2.29-3.fc12.noarch 2 urw-fonts-0:2.4-7.fc11.noarch 2 dejavu-serif-fonts-0:2.29-3.fc12.noarch 2 bitstream-vera-sans-fonts-0:1.10-17.fc12.noarch ? Symlinking font files is a way for non-font packages to comply with guidelines and avoid duplicating files, but it is also a symptom of missing or incomplete fontconfig support in the package. Please ask upstream to use fontconfig (possibly, via a higher-level library such as pangocairo). ? broken symlinks to font files: /usr/share/fillets-ng/font/font_console.ttf ? /usr/share/fonts/freefont/FreeSansBold.ttf fillets-ng-data-0:0.8.1-3.noarch /usr/share/fillets-ng/font/font_menu.ttf ? /usr/share/fonts/freefont/FreeSansBold.ttf fillets-ng-data-0:0.8.1-3.noarch /usr/share/fillets-ng/font/font_subtitle.ttf ? /usr/share/fonts/freefont/FreeSansBold.ttf fillets-ng-data-0:0.8.1-3.noarch /usr/share/doc/mapserver-5.4.1/tests/vera/VeraBd.ttf ? /usr/share/fonts/bitstream-vera/Verabd.ttf mapserver-0:5.4.1-1.fc12.x86_64 /usr/share/wesnoth/fonts/sazanami-gothic.ttf ? /usr/share/fonts/sazanami-fonts-gothic/sazanami-gothic.ttf wesnoth-data-0:1.6.4-2.fc12.noarch ? 5 files (0 MiB) in 3 packages (304 MiB) generated from 3 source packages. ? packages with fonts rpmlint errors on: [cjkuni-uming-fonts] e16-themes flumotion fonts-ISO8859-2 fonts-ISO8859-2-100dpi fonts-ISO8859-2-75dpi groff k3d kdebase3 kdebase-workspace [liberation-mono-fonts] nethack-vultures phoronix-test-suite python-reportlab texlive-texmf-doc TeXmacs [un-core-batang-fonts] [un-core-dinaru-fonts] [un-core-dotum-fonts] [un-core-graphic-fonts] [un-core-gungseo-fonts] [un-core-pilgi-fonts] wine-core [wqy-zenhei-fonts] xpilot-ng-server ? 472 files (70 MiB) in 26 packages (340 MiB) generated from 18 source packages. ? packages with font files not identified as such by libmagic: 12 a2ps-0:4.14-8.fc11.x86_64 (a2ps-4.14-8.fc11.src.rpm) 12 a2ps-0:4.14-8.fc11.i586 (a2ps-4.14-8.fc11.src.rpm) ? 24 files (0 MiB) in 2 packages (2 MiB) generated from 1 source packages. ? Either libmagic has a bug or the files are malformed and need to be fixed or dumped. ? packages with font files fc-query can not parse: 225 xorg-x11-fonts-misc-0:7.2-8.fc11.noarch (xorg-x11-fonts-7.2-8.fc11.src.rpm) 190 fonts-ISO8859-2-75dpi-0:1.0-20.fc11.noarch (fonts-ISO8859-2-1.0-20.fc11.src.rpm) 190 fonts-ISO8859-2-100dpi-0:1.0-20.fc11.noarch (fonts-ISO8859-2-1.0-20.fc11.src.rpm) 186 xorg-x11-fonts-ISO8859-9-75dpi-0:7.2-8.fc11.noarch (xorg-x11-fonts-7.2-8.fc11.src.rpm) 186 xorg-x11-fonts-ISO8859-9-100dpi-0:7.2-8.fc11.noarch (xorg-x11-fonts-7.2-8.fc11.src.rpm) 186 xorg-x11-fonts-ISO8859-2-75dpi-0:7.2-8.fc11.noarch (xorg-x11-fonts-7.2-8.fc11.src.rpm) 186 xorg-x11-fonts-ISO8859-2-100dpi-0:7.2-8.fc11.noarch (xorg-x11-fonts-7.2-8.fc11.src.rpm) 186 xorg-x11-fonts-ISO8859-15-75dpi-0:7.2-8.fc11.noarch (xorg-x11-fonts-7.2-8.fc11.src.rpm) 186 xorg-x11-fonts-ISO8859-15-100dpi-0:7.2-8.fc11.noarch (xorg-x11-fonts-7.2-8.fc11.src.rpm) 186 xorg-x11-fonts-ISO8859-14-75dpi-0:7.2-8.fc11.noarch (xorg-x11-fonts-7.2-8.fc11.src.rpm) 186 xorg-x11-fonts-ISO8859-14-100dpi-0:7.2-8.fc11.noarch (xorg-x11-fonts-7.2-8.fc11.src.rpm) 155 japanese-bitmap-fonts-0:0.20080710-7.fc12.noarch (japanese-bitmap-fonts-0.20080710-7.fc12.src.rpm) 154 terminus-fonts-0:4.28-8.fc11.noarch (terminus-fonts-4.28-8.fc11.src.rpm) 114 fonts-KOI8-R-75dpi-0:1.0-11.fc11.noarch (fonts-KOI8-R-1.0-11.fc11.src.rpm) 82 xorg-x11-fonts-cyrillic-0:7.2-8.fc11.noarch (xorg-x11-fonts-7.2-8.fc11.src.rpm) 60 fonts-KOI8-R-100dpi-0:1.0-11.fc11.noarch (fonts-KOI8-R-1.0-11.fc11.src.rpm) 42 baekmuk-bdf-fonts-0:2.2-7.fc11.noarch (baekmuk-bdf-fonts-2.2-7.fc11.src.rpm) 32 x3270-x11-0:3.3.6-8.fc11.x86_64 (x3270-3.3.6-8.fc11.src.rpm) 24 mona-bitmap-fonts-0:2.90-8.fc11.noarch (monafont-2.90-8.fc11.src.rpm) 16 fonts-KOI8-R-0:1.0-11.fc11.noarch (fonts-KOI8-R-1.0-11.fc11.src.rpm) 15 fonts-ISO8859-2-0:1.0-20.fc11.noarch (fonts-ISO8859-2-1.0-20.fc11.src.rpm) 13 a2ps-0:4.14-8.fc11.x86_64 (a2ps-4.14-8.fc11.src.rpm) 13 a2ps-0:4.14-8.fc11.i586 (a2ps-4.14-8.fc11.src.rpm) 12 jfbterm-0:0.4.7-21.fc11.x86_64 (jfbterm-0.4.7-21.fc11.src.rpm) 8 xorg-x11-fonts-75dpi-0:7.2-8.fc11.noarch (xorg-x11-fonts-7.2-8.fc11.src.rpm) 8 xorg-x11-fonts-100dpi-0:7.2-8.fc11.noarch (xorg-x11-fonts-7.2-8.fc11.src.rpm) 6 kst-0:1.7.0-6.fc11.x86_64 (kst-1.7.0-6.fc11.src.rpm) 6 kst-0:1.7.0-6.fc11.i586 (kst-1.7.0-6.fc11.src.rpm) 4 knm_new-fonts-0:1.1-5.fc11.noarch (knm_new-fonts-1.1-5.fc11.src.rpm) 2 libdockapp-fonts-0:0.6.2-2.fc11.x86_64 (libdockapp-0.6.2-2.fc11.src.rpm) 2 groff-0:1.18.1.4-17.fc11.x86_64 (groff-1.18.1.4-17.fc11.src.rpm) 1 jisksp16-1990-fonts-0:0.983-4.fc11.noarch (jisksp16-1990-fonts-0.983-4.fc11.src.rpm) ? 2862 files (54 MiB) in 32 packages (73 MiB) generated from 15 source packages. ? Either fontconfig has a bug or the files are malformed and need to be fixed or dumped. ? packages with localized metadata but no English variant: /usr/share/fonts/gfs-theokritos/GFSTheokritos.otf gfs-theokritos-fonts-0:20070415-13.fc11.noarch /usr/share/fonts/sazanami/gothic/sazanami-gothic.ttf sazanami-gothic-fonts-0:0.20040629-7.20061016.fc11.noarch /usr/share/fonts/sazanami/mincho/sazanami-mincho.ttf sazanami-mincho-fonts-0:0.20040629-7.20061016.fc11.noarch /usr/share/tuxpaint/fonts/locale/ja.ttf tuxpaint-1:0.9.20-3.fc11.x86_64 /usr/share/tuxpaint/fonts/locale/zh_tw.ttf tuxpaint-1:0.9.20-3.fc11.x86_64 ? 5 files (18 MiB) in 4 packages (18 MiB) generated from 3 source packages. ? The font files need to be fixed to declare metadata in English too. -- Nicolas Mailhot From alsadi at gmail.com Mon Jul 20 12:35:26 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Mon, 20 Jul 2009 15:35:26 +0300 Subject: Are all your Fedora 12 Features Where They Should be? In-Reply-To: <4A64631A.60907@hi.is> References: <4A63E68F.90908@redhat.com> <1248070877.5010.4.camel@PB3.linux> <20090720065230.GA29892@mother.pipebreaker.pl> <385866f0907200146i5fbe00d7lfb3f326c91b3b5e4@mail.gmail.com> <4A64631A.60907@hi.is> Message-ID: <385866f0907200535o7f6202dfs2aa4780711350103@mail.gmail.com> no, should it ? it currently check for optical media CD/DVD that matches the media.repo file like the DVD used for installation. please use the talk page to tell us why do you think it should check for all removable media not just CDs/DVDs From martind1111 at gmail.com Mon Jul 20 12:56:42 2009 From: martind1111 at gmail.com (Martin Dubuc) Date: Mon, 20 Jul 2009 08:56:42 -0400 Subject: boost-1.39.0-3.fc12.src.rpm Message-ID: <7a0107ba0907200556t43915875qabb98513dfa900ba@mail.gmail.com> I would like to build boost 1.39 on RHEL 5.3. In the past, I have been successful building boost library found in rawhide for RHEL 5.x distributions. However, I have not been susccessful building boost 1.39 using boost-1.39.0-2.fc12.src.rpm. I saw a message earlier this month that stated that boost-1.39.0-3.fc12.src.rpm had been released and wanted to see if that version would address the problems I encountered with boost-1.39.0-2.fc12.src.rpm. However, when installing the boost-1.39.0-3.fc12.src.rpm source RPM, I get the following errors: # rpm -ivh boost-1.39.0-3.fc12.src.rpm 1:boost warning: user mockbuild does not exist - using root warning: group mockbuild does not exist - using root ########################################### [100%] error: unpacking of archive failed on file /usr/src/redhat/SOURCES/boost-bitset.patch;4a646479: cpio: MD5 sum mismatch I am wondering if the source RPM is OK or not. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From limb at jcomserv.net Mon Jul 20 13:03:44 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 20 Jul 2009 08:03:44 -0500 Subject: boost-1.39.0-3.fc12.src.rpm In-Reply-To: <7a0107ba0907200556t43915875qabb98513dfa900ba@mail.gmail.com> References: <7a0107ba0907200556t43915875qabb98513dfa900ba@mail.gmail.com> Message-ID: <4A646B30.6000501@jcomserv.net> Martin Dubuc wrote: > I would like to build boost 1.39 on RHEL 5.3. In the past, I have been > successful building boost library found in rawhide for RHEL 5.x > distributions. However, I have not been susccessful building boost > 1.39 using boost-1.39.0-2.fc12.src.rpm. I saw a message earlier this > month that stated that boost-1.39.0-3.fc12.src.rpm had been released > and wanted to see if that version would address the problems I > encountered with boost-1.39.0-2.fc12.src.rpm. However, when installing > the boost-1.39.0-3.fc12.src.rpm source RPM, I get the following errors: > > # rpm -ivh boost-1.39.0-3.fc12.src.rpm > > 1:boost warning: user mockbuild does not exist - > using root > warning: group mockbuild does not exist - using root > ########################################### [100%] > error: unpacking of archive failed on file > /usr/src/redhat/SOURCES/boost-bitset.patch;4a646479: cpio: MD5 sum > mismatch > > I am wondering if the source RPM is OK or not. > > Martin > This is due to a signature change in RPM from F-11. Blatanly ripping off Mr. Gallagher's post of a few days back: To extract sources from an SRPM: rpm2cpio | cpio --extract (Do this in its own directory) To enable the old checksum (for building RHEL packages): rpmbuild -bs --define _source_filedigest_algorithm=1 This will recreate the SRPM using an MD5 sum instead of a SHA1 sum. -- in your fear, speak only peace in your fear, seek only love -d. bowie From limb at jcomserv.net Mon Jul 20 13:21:47 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 20 Jul 2009 08:21:47 -0500 Subject: F-11 updates seem hosed today In-Reply-To: <4A5B7F72.4070708@redhat.com> References: <27515.1247510172@sss.pgh.pa.us> <4A5B7F72.4070708@redhat.com> Message-ID: <4A646F6B.6010400@jcomserv.net> Dodji Seketeli wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Le 13/07/2009 20:36, Tom Lane a ?crit : > >> (Not sure if this is the right list to complain on, but ...) >> >> Trying to do a routine "yum update" on an F-11 x86 machine is not >> working today. It successfully downloaded a bunch of packages, >> but cannot find these: >> > > Yeah, a bug has been filed at > https://bugzilla.redhat.com/show_bug.cgi?id=510898 for this. > I guess we just have to wait for the mirrors to sync to the right content ... > > - -- > Dodji Seketeli > Red Hat > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkpbf3IACgkQPejI7lrem2EjuQCgppHSF1zzH7P8CBaZVuFUbool > /wcAnRoZocAyKQlLtDEnme0/gaYSLKcG > =n0bC > -----END PGP SIGNATURE----- > > Any word on this? I still don't seem to have anything on the mirror I sync from. . . -- in your fear, speak only peace in your fear, seek only love -d. bowie From pmachata at redhat.com Mon Jul 20 13:31:41 2009 From: pmachata at redhat.com (Petr Machata) Date: Mon, 20 Jul 2009 15:31:41 +0200 Subject: boost-1.39.0-3.fc12.src.rpm In-Reply-To: <7a0107ba0907200556t43915875qabb98513dfa900ba@mail.gmail.com> References: <7a0107ba0907200556t43915875qabb98513dfa900ba@mail.gmail.com> Message-ID: <4A6471BD.7090007@redhat.com> 20.07.2009 14:56, Martin Dubuc wrote: > /usr/src/redhat/SOURCES/boost-bitset.patch;4a646479: cpio: MD5 sum mismatch > > I am wondering if the source RPM is OK or not. Yes, the src rpm is OK, but on F11, rpm changed the digest algorithm to I think SHAsomething. If you have F11 handy, just install the src rpm there, and rebuild it with rpmbuild -bs --define _source_filedigest_algorithm=0 boost.spec If all you have is References: <7a0107ba0907200556t43915875qabb98513dfa900ba@mail.gmail.com> <4A646B30.6000501@jcomserv.net> Message-ID: <7a0107ba0907200635j3a4a7a84v75b0b215290dea7@mail.gmail.com> Thanks for the tip Jon. I was able to build boost RPM on RHEL 5.3. Martin On Mon, Jul 20, 2009 at 9:03 AM, Jon Ciesla wrote: > Martin Dubuc wrote: > >> I would like to build boost 1.39 on RHEL 5.3. In the past, I have been >> successful building boost library found in rawhide for RHEL 5.x >> distributions. However, I have not been susccessful building boost 1.39 >> using boost-1.39.0-2.fc12.src.rpm. I saw a message earlier this month that >> stated that boost-1.39.0-3.fc12.src.rpm had been released and wanted to see >> if that version would address the problems I encountered with >> boost-1.39.0-2.fc12.src.rpm. However, when installing the >> boost-1.39.0-3.fc12.src.rpm source RPM, I get the following errors: >> >> # rpm -ivh boost-1.39.0-3.fc12.src.rpm >> >> 1:boost warning: user mockbuild does not exist - using >> root >> warning: group mockbuild does not exist - using root >> ########################################### [100%] >> error: unpacking of archive failed on file >> /usr/src/redhat/SOURCES/boost-bitset.patch;4a646479: cpio: MD5 sum mismatch >> >> I am wondering if the source RPM is OK or not. >> >> Martin >> >> This is due to a signature change in RPM from F-11. > > Blatanly ripping off Mr. Gallagher's post of a few days back: > > To extract sources from an SRPM: > rpm2cpio | cpio --extract > (Do this in its own directory) > > To enable the old checksum (for building RHEL packages): > rpmbuild -bs --define _source_filedigest_algorithm=1 > > This will recreate the SRPM using an MD5 sum instead of a SHA1 sum. > > > > -- > in your fear, speak only peace > in your fear, seek only love > > -d. bowie > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwboyer at gmail.com Mon Jul 20 13:36:18 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 20 Jul 2009 09:36:18 -0400 Subject: F-11 updates seem hosed today In-Reply-To: <4A646F6B.6010400@jcomserv.net> References: <27515.1247510172@sss.pgh.pa.us> <4A5B7F72.4070708@redhat.com> <4A646F6B.6010400@jcomserv.net> Message-ID: <20090720133618.GG3312@hansolo.jdub.homelinux.org> On Mon, Jul 20, 2009 at 08:21:47AM -0500, Jon Ciesla wrote: > Dodji Seketeli wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Le 13/07/2009 20:36, Tom Lane a ?crit : >> >>> (Not sure if this is the right list to complain on, but ...) >>> >>> Trying to do a routine "yum update" on an F-11 x86 machine is not >>> working today. It successfully downloaded a bunch of packages, >>> but cannot find these: >>> >> >> Yeah, a bug has been filed at >> https://bugzilla.redhat.com/show_bug.cgi?id=510898 for this. >> I guess we just have to wait for the mirrors to sync to the right content ... >> >> - -- Dodji Seketeli >> Red Hat >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (GNU/Linux) >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAkpbf3IACgkQPejI7lrem2EjuQCgppHSF1zzH7P8CBaZVuFUbool >> /wcAnRoZocAyKQlLtDEnme0/gaYSLKcG >> =n0bC >> -----END PGP SIGNATURE----- >> >> > Any word on this? I still don't seem to have anything on the mirror I > sync from. . . Use a different mirror? I have successfully updated this morning using the stock fedora configs. josh From limb at jcomserv.net Mon Jul 20 13:41:45 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 20 Jul 2009 08:41:45 -0500 Subject: F-11 updates seem hosed today In-Reply-To: <20090720133618.GG3312@hansolo.jdub.homelinux.org> References: <27515.1247510172@sss.pgh.pa.us> <4A5B7F72.4070708@redhat.com> <4A646F6B.6010400@jcomserv.net> <20090720133618.GG3312@hansolo.jdub.homelinux.org> Message-ID: <4A647419.2060701@jcomserv.net> Josh Boyer wrote: > On Mon, Jul 20, 2009 at 08:21:47AM -0500, Jon Ciesla wrote: > >> Dodji Seketeli wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Le 13/07/2009 20:36, Tom Lane a ?crit : >>> >>> >>>> (Not sure if this is the right list to complain on, but ...) >>>> >>>> Trying to do a routine "yum update" on an F-11 x86 machine is not >>>> working today. It successfully downloaded a bunch of packages, >>>> but cannot find these: >>>> >>>> >>> Yeah, a bug has been filed at >>> https://bugzilla.redhat.com/show_bug.cgi?id=510898 for this. >>> I guess we just have to wait for the mirrors to sync to the right content ... >>> >>> - -- Dodji Seketeli >>> Red Hat >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.9 (GNU/Linux) >>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ >>> >>> iEYEARECAAYFAkpbf3IACgkQPejI7lrem2EjuQCgppHSF1zzH7P8CBaZVuFUbool >>> /wcAnRoZocAyKQlLtDEnme0/gaYSLKcG >>> =n0bC >>> -----END PGP SIGNATURE----- >>> >>> >>> >> Any word on this? I still don't seem to have anything on the mirror I >> sync from. . . >> > > Use a different mirror? I have successfully updated this morning using the > stock fedora configs. > > josh > > How queer. That works. Should I notify that mirror? -- in your fear, speak only peace in your fear, seek only love -d. bowie From rawhide at fedoraproject.org Mon Jul 20 14:13:01 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Mon, 20 Jul 2009 14:13:01 +0000 Subject: rawhide report: 20090720 changes Message-ID: <20090720141301.GA23549@releng2.fedora.phx.redhat.com> Compose started at Mon Jul 20 06:15:21 UTC 2009 New package lxrandr Simple monitor configuration tool Updated Packages: Miro-2.0.5-2.fc12 ----------------- * Sun Jul 19 2009 Alex Lancaster - 2.0.5-2 - Rebuild against newer gecko Terminal-0.2.99.1-1.fc12 ------------------------ * Sun Jul 19 2009 Kevin Fenzi - 0.2.99.1-1 - Update to 0.2.99.1 at-3.1.10-34.fc12 ----------------- * Mon Jul 20 2009 Marcela Ma?l??ov? - 3.1.10-34 - require pm-utils-filesystem instead of pm-utils which should help minimal installation. blam-1.8.5-12.fc12 ------------------ * Sun Jul 19 2009 Alex Lancaster - 1.8.5-12 - Rebuild against newer gecko cld-0.2-0.2.g023a127d.fc12 -------------------------- * Sun Jul 19 2009 Jeff Garzik - 0.2-0.2.g023a127d - improve package description - per guidelines, indicate how to regenerate tarball from git repo gst-mixer-2.26.0-3.fc12 ----------------------- * Sun Jul 19 2009 Christoph Wickert - 2.26.0-3 - Fix 'Help' button (#508531) - Add category 'Mixer' to menu enty for nested menus in multimedia-menus html-xml-utils-5.4-1.fc12 ------------------------- * Sun Jul 19 2009 Milos Jakubicek - 5.4-1 - Update to 5.4 (bug in removal of /./ fixed. Now leaves one / instead of none). hulahop-0.5.0-0.fc12 -------------------- * Sat Jul 18 2009 Tomeu Vizoso - 0.5.0-1 - New upstream release kernel-2.6.31-0.76.rc3.git4.fc12 -------------------------------- * Sun Jul 19 2009 Dave Jones 2.6.31-0.74.rc3.git4 - 2.6.31-rc3-git4 * Sun Jul 19 2009 Dave Jones 2.6.31-0.75.rc3.git4 - build a 'full' package on i686 (Bill Nottingham) * Sat Jul 18 2009 Matthew Garrett - linux-2.6-driver-level-usb-autosuspend.diff - allow drivers to enable autopm - linux-2.6-fix-usb-serial-autosuspend.diff - fix generic usb-serial autopm - linux-2.6-qcserial-autosuspend.diff - enable autopm by default on qcserial - linux-2.6-bluetooth-autosuspend.diff - enable autopm by default on btusb - linux-2.6-usb-uvc-autosuspend.diff - enable autopm by default on uvc mozvoikko-0.9.7-0.5.rc1.fc12 ---------------------------- * Sun Jul 19 2009 Ville-Pekka Vainio - 0.9.7-0.5.rc1 - Rebuild against newer gecko - Bump Release to fix upgrade path nntpgrab-0.5.1-1.fc12 --------------------- * Sun Jul 19 2009 Erik van Pienbroek - 0.5.1-1 - Update to 0.5.1 php-pear-PEAR-Command-Packaging-0.2.0-2.fc12 -------------------------------------------- * Sun Jul 19 2009 Remi Collet 0.2.0-2 - change %{pear-name}.xml to %{name}.xml scidavis-0.2.3-5.fc12 --------------------- * Sun Jul 19 2009 Eric Tanguy - 0.2.3-4 - Rebuild * Sun Jul 19 2009 Eric Tanguy - 0.2.3-5 - Rebuild * Fri Jul 17 2009 Eric Tanguy - 0.2.3-3 - Patch for manual path * Mon Jul 13 2009 Eric Tanguy - 0.2.3-2 - BZ #510968 selinux-policy-3.6.22-2.fc12 ---------------------------- * Sun Jul 19 2009 Dan Walsh 3.6.22-2 - Fix context for VirtualBox setroubleshoot-2.2.15-1.fc12 ---------------------------- * Sun Jul 19 2009 Dan Walsh - 2.2.15-1 - Fix a1 handling setroubleshoot-plugins-2.1.11-1.fc12 ------------------------------------ * Sun Jul 19 2009 - 2.1.11-1 - Remove allow_default_t boolean - Fix global_ssp.py to report boolean name slashem-0.0.8-0.4.E0F1.fc12 --------------------------- * Sun Jul 19 2009 Iain Arnell 0.0.8-0.4.E0F1 - require nethack-bitmap-fonts-core, not nethack anymore spring-0.79.1.2-2.fc12 ---------------------- * Sun Jul 19 2009 Aurelien Bompard 0.79.1.2-2 - use OpenJDK's version of Java * Sat Jul 18 2009 Aurelien Bompard 0.79.1.2-1 - version 0.79.1.2 - remove obsolete fonts hack - build dedicated server * Sat May 23 2009 Aurelien Bompard 0.79.0.2-1 - version 0.79.0.2 - update URL wine-1.1.26-1.fc12 ------------------ * Sat Jul 18 2009 Andreas Bierfert - 1.1.26-1 - version upgrade - WinePulse 0.29 - require Xrender isa for x86_64 (#510947) xlog-2.0.3-1.fc12 ----------------- * Mon Jul 20 2009 Lucian Langa - 2.0.3-1 - new upstream release xmp-2.5.1-6.fc12 ---------------- * Sun Jul 19 2009 Michael Schwendt - 2.5.1-6 - patch for Audacious 2 (xmp-2.5.1-audacious2.patch) Summary: Added Packages: 1 Removed Packages: 0 Modified Packages: 21 Broken deps for i386 ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin CodeAnalyst-gui-2.8.54-15.fc12.i586 requires libbfd-2.19.51.0.11-24.fc12.so R-RScaLAPACK-0.5.1-19.fc11.i586 requires openmpi-libs clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) conky-1.7.1.1-1.fc12.i586 requires libaudclient.so.1 gauche-gl-0.4.4-4.fc11.i586 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.i586 requires gauche = 0:0.8.13 gedit-vala-0.4.1-2.fc11.i586 requires libgtksourcecompletion-1.0.so.1 gnome-python2-gtkmozembed-2.25.3-6.fc12.i586 requires gecko-libs = 0:1.9.1 gnome-web-photo-0.8-1.fc12.i586 requires gecko-libs = 0:1.9.1 libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.i586 requires xulrunner = 0:1.9.1 perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) perl-Gtk2-MozEmbed-0.08-6.fc12.1.i586 requires gecko-libs = 0:1.9.1 php-ZendFramework-1.8.4-1.PL1.fc12.noarch requires php-Fileinfo php-idn-1.2-5.fc12.i586 requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.i386 requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.i386 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.i586 requires libgeos-3.0.3.so qtparted-0.4.5-19.fc11.i586 requires libparted-1.8.so.8 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.i586 requires libpqxx-2.6.8.so thunderbird-lightning-1.0-0.6.20090513hg.fc12.i586 requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 Broken deps for x86_64 ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin CodeAnalyst-gui-2.8.54-15.fc12.i586 requires libbfd-2.19.51.0.11-24.fc12.so CodeAnalyst-gui-2.8.54-15.fc12.x86_64 requires libbfd-2.19.51.0.11-24.fc12.so()(64bit) R-RScaLAPACK-0.5.1-19.fc11.x86_64 requires openmpi-libs clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.x86_64 requires pkgconfig(clutter-0.8) conky-1.7.1.1-1.fc12.x86_64 requires libaudclient.so.1()(64bit) gauche-gl-0.4.4-4.fc11.x86_64 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.x86_64 requires gauche = 0:0.8.13 gedit-vala-0.4.1-2.fc11.x86_64 requires libgtksourcecompletion-1.0.so.1()(64bit) gnome-python2-gtkmozembed-2.25.3-6.fc12.x86_64 requires gecko-libs = 0:1.9.1 gnome-web-photo-0.8-1.fc12.x86_64 requires gecko-libs = 0:1.9.1 libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.x86_64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 libprojectM-1.2.0-9.fc11.x86_64 requires libftgl.so.0()(64bit) pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.x86_64 requires xulrunner = 0:1.9.1 perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) perl-Gtk2-MozEmbed-0.08-6.fc12.1.x86_64 requires gecko-libs = 0:1.9.1 php-ZendFramework-1.8.4-1.PL1.fc12.noarch requires php-Fileinfo php-idn-1.2-5.fc12.x86_64 requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.x86_64 requires libgeos-3.0.3.so()(64bit) qtparted-0.4.5-19.fc11.x86_64 requires libparted-1.8.so.8()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.x86_64 requires libpqxx-2.6.8.so()(64bit) thunderbird-lightning-1.0-0.6.20090513hg.fc12.x86_64 requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 Broken deps for ppc ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin R-RScaLAPACK-0.5.1-19.fc11.ppc requires openmpi-libs clutter-cairo-0.8.2-3.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) conky-1.7.1.1-1.fc12.ppc requires libaudclient.so.1 gauche-gl-0.4.4-4.fc11.ppc requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.ppc requires gauche = 0:0.8.13 gedit-vala-0.4.1-2.fc11.ppc requires libgtksourcecompletion-1.0.so.1 gnome-python2-gtkmozembed-2.25.3-6.fc12.ppc requires gecko-libs = 0:1.9.1 gnome-web-photo-0.8-1.fc12.ppc requires gecko-libs = 0:1.9.1 libchamplain-0.2.9-1.fc11.ppc requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc requires libftgl.so.0 libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.ppc requires xulrunner = 0:1.9.1 perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) perl-Gtk2-MozEmbed-0.08-6.fc12.1.ppc requires gecko-libs = 0:1.9.1 php-ZendFramework-1.8.4-1.PL1.fc12.noarch requires php-Fileinfo php-idn-1.2-5.fc12.ppc requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.ppc requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.ppc requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.ppc requires libgeos-3.0.3.so qtparted-0.4.5-19.fc11.ppc requires libparted-1.8.so.8 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc requires libpqxx-2.6.8.so thunderbird-lightning-1.0-0.6.20090513hg.fc12.ppc requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 Broken deps for ppc64 ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin R-RScaLAPACK-0.5.1-19.fc11.ppc64 requires openmpi-libs clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) conky-1.7.1.1-1.fc12.ppc64 requires libaudclient.so.1()(64bit) gedit-vala-0.4.1-2.fc11.ppc64 requires libgtksourcecompletion-1.0.so.1()(64bit) gnome-python2-gtkmozembed-2.25.3-6.fc12.ppc64 requires gecko-libs = 0:1.9.1 gnome-web-photo-0.8-1.fc12.ppc64 requires gecko-libs = 0:1.9.1 libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.ppc64 requires xulrunner = 0:1.9.1 perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) perl-Gtk2-MozEmbed-0.08-6.fc12.1.ppc64 requires gecko-libs = 0:1.9.1 php-ZendFramework-1.8.4-1.PL1.fc12.noarch requires php-Fileinfo php-idn-1.2-5.fc12.ppc64 requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires python(abi) = 0:2.5 python-basemap-0.99.2-3.fc11.ppc64 requires libgeos-3.0.3.so()(64bit) python-mwlib-0.11.2-2.20090522hg2956.fc12.ppc64 requires LabPlot qtparted-0.4.5-19.fc11.ppc64 requires libparted-1.8.so.8()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc64 requires libpqxx-2.6.8.so()(64bit) thunderbird-lightning-1.0-0.6.20090513hg.fc12.ppc64 requires thunderbird < 0:3.0-2.3.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 From fangqq at gmail.com Mon Jul 20 14:32:09 2009 From: fangqq at gmail.com (Qianqian Fang) Date: Mon, 20 Jul 2009 10:32:09 -0400 Subject: Rawhide fonts problem report for 2009-07-20 In-Reply-To: <4A647B3B.8080906@redhat.com> References: <1248093112.13758.5.camel@arekh.okg> <4A64792B.6070101@gmail.com> <4A647B3B.8080906@redhat.com> Message-ID: <4A647FE9.9040300@gmail.com> Behdad Esfahbod wrote: > On 07/20/2009 10:03 AM, Qianqian Fang wrote: >> Nicolas Mailhot wrote: >>> ? Mid-term, files in legacy PCF or Type1 formats need to be converted >>> or removed. >> >> just curious, for PCF, what format you plan to convert to ? >> >> I had tried SFNT TTF/OTF, neither of them works with the current >> fontconfig >> (cache file could not be generated). > > File a bug?!?!? > > behdad yes, I brought it up on fontconfig's mailing list in 2006, mpsuzuki posted a patch, but it has never been committed. http://lists.freedesktop.org/archives/fontconfig/2006-August/002364.html also, it seemed there were some intrinsic difficulties for fontconfig to handle multi-strike sfnt ttf. Qianqian > > >> Qianqian > From fangqq at gmail.com Mon Jul 20 14:46:44 2009 From: fangqq at gmail.com (Qianqian Fang) Date: Mon, 20 Jul 2009 10:46:44 -0400 Subject: Rawhide fonts problem report for 2009-07-20 In-Reply-To: <4A6481AE.7030602@redhat.com> References: <1248093112.13758.5.camel@arekh.okg> <4A64792B.6070101@gmail.com> <4A647B3B.8080906@redhat.com> <4A647FE9.9040300@gmail.com> <4A6481AE.7030602@redhat.com> Message-ID: <4A648354.1080101@gmail.com> Behdad Esfahbod wrote: > On 07/20/2009 10:32 AM, Qianqian Fang wrote: >> >> Behdad Esfahbod wrote: >>> On 07/20/2009 10:03 AM, Qianqian Fang wrote: >>>> Nicolas Mailhot wrote: >>>>> ? Mid-term, files in legacy PCF or Type1 formats need to be converted >>>>> or removed. >>>> >>>> just curious, for PCF, what format you plan to convert to ? >>>> >>>> I had tried SFNT TTF/OTF, neither of them works with the current >>>> fontconfig >>>> (cache file could not be generated). >>> >>> File a bug?!?!? >>> >>> behdad >> >> yes, I brought it up on fontconfig's mailing list in 2006, > > That's not filing a bug. > > >> mpsuzuki posted a patch, but it has never been committed. > > That's exactly why one should file a bug. alright, will do that later today. > > >> http://lists.freedesktop.org/archives/fontconfig/2006-August/002364.html >> >> also, it seemed there were some intrinsic difficulties for fontconfig to >> handle multi-strike sfnt ttf. >> >> Qianqian > > behdad > From chitlesh.goorah at gmail.com Mon Jul 20 15:04:25 2009 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Mon, 20 Jul 2009 17:04:25 +0200 Subject: Porting amarok-1.4 to F11 In-Reply-To: <4A3968BD.6040302@maths.otago.ac.nz> References: <1675759158.193971245113727260.JavaMail.root@claudius.linpro.no> <4A3968BD.6040302@maths.otago.ac.nz> Message-ID: <50baabb30907200804q3a007c3am2ac8a541c73d241e@mail.gmail.com> > Ingvar Hagelund wrote: >> If anyone are interested in the packages, they are available from >> http://ingvar.blog.linpro.no/2009/06/11/amarok-14-for-fedora-11/ On Thu, Jun 18, 2009 at 12:05 AM, Greg Trounsonwrote: > Thank you Ingvar. ?After using Amarok 2 for a couple of months I'm convinced > it has a long way to go before it comes near Amarok 1.4 in terms of > features, usability and robustness. Thanks, Actually, I also feel amarok 2.0 has a long way to go. I feel that Amarok is another good opensource product turning into a crappy one. Amarok 1.4's features : ipod support and cuesheet support are missing in the 2.0 version since a long time and upstream is not giving enough love to them. cuesheet is broken release after release while upstream is claiming better cuesheet support in their release notes. Sadly. Chitlesh From mtasaka at ioa.s.u-tokyo.ac.jp Mon Jul 20 15:26:05 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 21 Jul 2009 00:26:05 +0900 Subject: rpms/rubygem-activeldap/F-10 .cvsignore, 1.6, 1.7 rubygem-activeldap.spec, 1.7, 1.8 sources, 1.6, 1.7 In-Reply-To: <20090720145132.7755A11C00D5@cvs1.fedora.phx.redhat.com> References: <20090720145132.7755A11C00D5@cvs1.fedora.phx.redhat.com> Message-ID: <4A648C8D.4080807@ioa.s.u-tokyo.ac.jp> Hello: Darryl L. Pierce wrote, at 07/20/2009 11:51 PM +9:00: > Author: mcpierce > > Update of /cvs/pkgs/rpms/rubygem-activeldap/F-10 > In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv22509 > > Modified Files: > .cvsignore rubygem-activeldap.spec sources > Log Message: > * Mon Jul 20 2009 Darryl Pierce - 1.1.0-1 > - Release 1.1.0 of ActiveLdap. > - Dependency on rubygem-hoe changed to 2.3.2. > - Dependency on rubygem-activerecord changed to 2.3.2. > - Dependency on rubygem-locale added. > - Dependency on rubygem-gettext added. > - Dependency on rubygem-gettext_activerecord added. Please don't on F-10. F-10 rubygem-activerecord is 2.1.1 and due to this F-10 rubygem-gettext is 1.93.0 and so rubygem-locale or rubygem-gettext_activerecord is not available on F-10. Also, on F-11/10 rubygem-hoe is 1.12.2. Regards, Mamoru From bill at bfccomputing.com Mon Jul 20 15:56:02 2009 From: bill at bfccomputing.com (Bill McGonigle) Date: Mon, 20 Jul 2009 11:56:02 -0400 Subject: Updates and delays in signing packages In-Reply-To: <20090717235741.GA3312@hansolo.jdub.homelinux.org> References: <4A60EAE8.3010705@fedoraproject.org> <20090717235741.GA3312@hansolo.jdub.homelinux.org> Message-ID: <4A649392.5040208@bfccomputing.com> On 07/17/2009 07:57 PM, Josh Boyer wrote: > It takes a push between 2 and > 3 days to actually complete right now. > > We've had some significant delays due to a variety of factors over the past > couple of weeks. I think we now have most of the big ones fixed, with the > master mirrors allowing more rsync access, and the updates composes now being > able to hardlink again (reduces mash time). There is another issue involving > deltarpms that I've filed a bug on, and we should get some speed-up if we can > get that figured out too. Josh - it sounds like you're working hard on this; much appreciated. Is there a clear resource constraint in the process - lack of hardware, insufficient bandwidth (locally or at the mirrors)? It sounds like current manpower is covered - are there software improvements (optimizations, pipelining, architectural) on the wishlist that would improve throughput? Thanks, -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/ Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: bill at bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf From ricky at fedoraproject.org Mon Jul 20 16:05:24 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Mon, 20 Jul 2009 12:05:24 -0400 Subject: Updates and delays in signing packages In-Reply-To: <4A649392.5040208@bfccomputing.com> References: <4A60EAE8.3010705@fedoraproject.org> <20090717235741.GA3312@hansolo.jdub.homelinux.org> <4A649392.5040208@bfccomputing.com> Message-ID: <20090720160524.GM20460@alpha.rzhou.org> On 2009-07-20 11:56:02 AM, Bill McGonigle wrote: > Is there a clear resource constraint in the process - lack of hardware, > insufficient bandwidth (locally or at the mirrors)? It sounds like > current manpower is covered - are there software improvements > (optimizations, pipelining, architectural) on the wishlist that would > improve throughput? Currently, two of our three (?) master mirror netapps are down due to various reasons, leaving us with a single point of failure (and on top of that, the last mirror was moved very recently, I believe). At the same time, we had an issue where timestamps were getting unnecessarily updated at each push. A combination of all of these has made it very hard for us to get updates out to mirrors :-/ I think people are working on getting the other netapps back up, and as Josh mentioned, we've fixed the timestamp issue already. Unfortunately, not all of these parts are run by Fedora Infrastructure, so there's a lot of information-passing going on with us as the middlemen between mirror admins and the people working on finding out what the cause of the issues are. Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From MathStuf at gmail.com Mon Jul 20 16:05:49 2009 From: MathStuf at gmail.com (Ben Boeckel) Date: Mon, 20 Jul 2009 12:05:49 -0400 Subject: Porting amarok-1.4 to F11 References: <1675759158.193971245113727260.JavaMail.root@claudius.linpro.no> <4A3968BD.6040302@maths.otago.ac.nz> <50baabb30907200804q3a007c3am2ac8a541c73d241e@mail.gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chitlesh GOORAH wrote: >> Ingvar Hagelund wrote: >>> If anyone are interested in the packages, they are available from >>> http://ingvar.blog.linpro.no/2009/06/11/amarok-14-for- fedora-11/ > > On Thu, Jun 18, 2009 at 12:05 AM, Greg Trounsonwrote: >> Thank you Ingvar. After using Amarok 2 for a couple of months I'm convinced >> it has a long way to go before it comes near Amarok 1.4 in terms of >> features, usability and robustness. > > Thanks, > Actually, I also feel amarok 2.0 has a long way to go. I feel that > Amarok is another good opensource product turning into a crappy one. > > Amarok 1.4's features : ipod support and cuesheet support are missing > in the 2.0 version since a long time and upstream is not giving enough > love to them. cuesheet is broken release after release while upstream > is claiming better cuesheet support in their release notes. Sadly. > > Chitlesh > Someone stated that 2.2 got the look-and-feel of 1.4 as an option. Maybe you'd like to try that? Currently would need build-from-source. - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpkld4ACgkQiPi+MRHG3qSXOgCfV4G4ZhDG4hHtIPK3NrcZpi/B y6QAoIfBbPOhDSO6xTkzwIkpHK+7Qdvq =2fYL -----END PGP SIGNATURE----- From nicolas.mailhot at laposte.net Mon Jul 20 16:11:04 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 20 Jul 2009 18:11:04 +0200 Subject: Rawhide fonts problem report for 2009-07-20 In-Reply-To: <4A64792B.6070101@gmail.com> References: <1248093112.13758.5.camel@arekh.okg> <4A64792B.6070101@gmail.com> Message-ID: <1248106264.16195.3.camel@arekh.okg> Le lundi 20 juillet 2009 ? 10:03 -0400, Qianqian Fang a ?crit : > Nicolas Mailhot wrote: > > ? Mid-term, files in legacy PCF or Type1 formats need to be converted or removed. > > > > just curious, for PCF, what format you plan to convert to ? Can I just dream bitmap fonts will go away ? Otherwise, it would be awesome if one of the 2-3 ways to create Opentype bitmap fonts actually worked - > I had tried SFNT TTF/OTF, neither of them works with the current fontconfig > (cache file could not be generated). Please open bugs upstream so Behdad can fix support for SFNT bitmap fonts -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jwboyer at gmail.com Mon Jul 20 16:23:21 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 20 Jul 2009 12:23:21 -0400 Subject: Updates and delays in signing packages In-Reply-To: <4A649392.5040208@bfccomputing.com> References: <4A60EAE8.3010705@fedoraproject.org> <20090717235741.GA3312@hansolo.jdub.homelinux.org> <4A649392.5040208@bfccomputing.com> Message-ID: <20090720162321.GH3312@hansolo.jdub.homelinux.org> On Mon, Jul 20, 2009 at 11:56:02AM -0400, Bill McGonigle wrote: >On 07/17/2009 07:57 PM, Josh Boyer wrote: >> It takes a push between 2 and >> 3 days to actually complete right now. >> >> We've had some significant delays due to a variety of factors over the past >> couple of weeks. I think we now have most of the big ones fixed, with the >> master mirrors allowing more rsync access, and the updates composes now being >> able to hardlink again (reduces mash time). There is another issue involving >> deltarpms that I've filed a bug on, and we should get some speed-up if we can >> get that figured out too. > >Josh - it sounds like you're working hard on this; much appreciated. > >Is there a clear resource constraint in the process - lack of hardware, >insufficient bandwidth (locally or at the mirrors)? It sounds like Hardware has been taken care of recently. Mirror bandwidth is also now back to normal. >current manpower is covered - are there software improvements >(optimizations, pipelining, architectural) on the wishlist that would >improve throughput? There is general knowledge that makedeltarpm is slow. However, we're working an issue that could speed things up due to us doing work we don't need to at the moment. So before getting into specifics, I'd like to see that issue resolved first. josh From liangsuilong at gmail.com Mon Jul 20 16:25:47 2009 From: liangsuilong at gmail.com (=?UTF-8?B?5qKB56mX6ZqG?=) Date: Tue, 21 Jul 2009 00:25:47 +0800 Subject: Chromium-3.0.195 fails to start Message-ID: >No, that dependency actually is a bug because I hardcoded the >%{_isa} to >force it to a specific architecture target: nss-mdns(x86-32). >That's wrong, it shouldn't have the hardcoding. I'll fix it in the >next build. Thank you, spot! ~spot -- http://liangsuilong.co.cc 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 poelstra at redhat.com Mon Jul 20 16:40:11 2009 From: poelstra at redhat.com (John Poelstra) Date: Mon, 20 Jul 2009 09:40:11 -0700 Subject: Are all your Fedora 12 Features Where They Should be? In-Reply-To: <385866f0907200146i5fbe00d7lfb3f326c91b3b5e4@mail.gmail.com> References: <4A63E68F.90908@redhat.com> <1248070877.5010.4.camel@PB3.linux> <20090720065230.GA29892@mother.pipebreaker.pl> <385866f0907200146i5fbe00d7lfb3f326c91b3b5e4@mail.gmail.com> Message-ID: <4A649DEB.8070405@redhat.com> Muayyad AlSadi said the following on 07/20/2009 01:46 AM Pacific Time: > my feature is > https://fedoraproject.org/wiki/Features/MediaRepo > > and the feature works, the rest is to minor fixes, license issues, > communication with upstream. > > I've just added > > https://fedoraproject.org/wiki/Category:FeatureReadyForWrangler > The release note section is empty. It needs a release note before it can go on to FESCo. > how much time do I have to make it 100% complete ? > should it be 100% complete before > Features must be 100% complete by Final Freeze (2009-09-22). Features must be significantly complete and testable by Feature Freeze (2009-07-28). Hope that helps, John From bruno at wolff.to Mon Jul 20 16:40:19 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 20 Jul 2009 11:40:19 -0500 Subject: F-11 updates seem hosed today In-Reply-To: <4A646F6B.6010400@jcomserv.net> References: <27515.1247510172@sss.pgh.pa.us> <4A5B7F72.4070708@redhat.com> <4A646F6B.6010400@jcomserv.net> Message-ID: <20090720164019.GA12206@wolff.to> On Mon, Jul 20, 2009 at 08:21:47 -0500, Jon Ciesla wrote: >> > Any word on this? I still don't seem to have anything on the mirror I > sync from. . . See: https://fedorahosted.org/fedora-infrastructure/ticket/1531 Based on comments it looks like things should start returning to normal soon, but I am still not seeing a lot of up to date mirrros. I did have pretty good success with the mirror at ftp-stud.hs-esslingen.de . From awilliam at redhat.com Mon Jul 20 17:26:11 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 20 Jul 2009 10:26:11 -0700 Subject: Porting amarok-1.4 to F11 In-Reply-To: References: <1675759158.193971245113727260.JavaMail.root@claudius.linpro.no> <4A3968BD.6040302@maths.otago.ac.nz> <50baabb30907200804q3a007c3am2ac8a541c73d241e@mail.gmail.com> Message-ID: <1248110771.6035.32.camel@adam.local.net> On Mon, 2009-07-20 at 12:05 -0400, Ben Boeckel wrote: > Someone stated that 2.2 got the look-and-feel of 1.4 as an > option. Maybe you'd like to try that? Currently would need > build-from-source. He explained carefully that his problem with 2.x is the lack of features that worked well in 1.4; how would a 'look and feel' change help? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From fangqq at gmail.com Mon Jul 20 17:41:00 2009 From: fangqq at gmail.com (Qianqian Fang) Date: Mon, 20 Jul 2009 13:41:00 -0400 Subject: Rawhide fonts problem report for 2009-07-20 In-Reply-To: <1248106264.16195.3.camel@arekh.okg> References: <1248093112.13758.5.camel@arekh.okg> <4A64792B.6070101@gmail.com> <1248106264.16195.3.camel@arekh.okg> Message-ID: <4A64AC2C.5080405@gmail.com> Nicolas Mailhot wrote: > Le lundi 20 juillet 2009 ? 10:03 -0400, Qianqian Fang a ?crit : > >> Nicolas Mailhot wrote: >> >>> ? Mid-term, files in legacy PCF or Type1 formats need to be converted or removed. >>> >>> >> just curious, for PCF, what format you plan to convert to ? >> > > Can I just dream bitmap fonts will go away ? Otherwise, it would be > awesome if one of the 2-3 ways to create Opentype bitmap fonts actually > worked > AFAIK, there exist at least 30% of the Chinese users who prefer bitmaps over vector (even we dream all free CJK vector fonts having good hinting in the future, I still don't think this fraction can be lower than 15% in the next 3 years. They made this choice because their monitors, their sensitivity to blurry, or just because they are used to windows (9x to xp, even vista). Getting opentype bitmap/sfnt wrapper to work for bitmaps is definitely the way to go: it not only saves more than half of the space, but also makes rendering a lot faster. The only concern is the support to GTK1 applications which reply on the legacy X font settings. > - > >> I had tried SFNT TTF/OTF, neither of them works with the current fontconfig >> (cache file could not be generated). >> > > Please open bugs upstream so Behdad can fix support for SFNT bitmap > fonts > > From MathStuf at gmail.com Mon Jul 20 17:48:07 2009 From: MathStuf at gmail.com (Ben Boeckel) Date: Mon, 20 Jul 2009 13:48:07 -0400 Subject: Porting amarok-1.4 to F11 References: <1675759158.193971245113727260.JavaMail.root@claudius.linpro.no> <4A3968BD.6040302@maths.otago.ac.nz> <50baabb30907200804q3a007c3am2ac8a541c73d241e@mail.gmail.com> <1248110771.6035.32.camel@adam.local.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Williamson wrote: > On Mon, 2009-07-20 at 12:05 -0400, Ben Boeckel wrote: > >> Someone stated that 2.2 got the look-and-feel of 1.4 as an >> option. Maybe you'd like to try that? Currently would need >> build-from-source. > > He explained carefully that his problem with 2.x is the lack of features > that worked well in 1.4; how would a 'look and feel' change help? > He also stated usability, which is one thing the interface can help with. Personally, I don't own an ipod nor do I use cuesheets, so I am not sure of theire status related to 1.4. As for robustness, I haven't had any issues besides it sometimes hanging when network goes down with last.fm playing. - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpkrdcACgkQiPi+MRHG3qSY2wCcDtHcR0+pa8Ab2WCwi7MJbFQY a3cAn3/b5zqiMq9RENIB+1+l0Qu/cpGw =n4So -----END PGP SIGNATURE----- From valent.turkovic at gmail.com Mon Jul 20 18:08:49 2009 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 20 Jul 2009 20:08:49 +0200 Subject: Open Source Activity Map (for Red Hat marketing) Message-ID: <64b14b300907201108k6477f897m2a2d276377159d6a@mail.gmail.com> http://www.redhat.com/about/where-is-open-source/activity/ The map that Red Hat produced is really nice, but it is a shame that www.openstreetmap.org maps aren't used and promoted. It is strange to see Red Hat promote Google maps when more open data is available but closed data is used. There is openlayers package in Fedora repositories, and it would be nice to see it used on Red Hat servers and on Open Source Activity page. Cheers. -- 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 sundaram at fedoraproject.org Mon Jul 20 18:21:47 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 20 Jul 2009 23:51:47 +0530 Subject: Open Source Activity Map (for Red Hat marketing) In-Reply-To: <64b14b300907201108k6477f897m2a2d276377159d6a@mail.gmail.com> References: <64b14b300907201108k6477f897m2a2d276377159d6a@mail.gmail.com> Message-ID: <4A64B5BB.1080003@fedoraproject.org> On 07/20/2009 11:38 PM, Valent Turkovic wrote: > http://www.redhat.com/about/where-is-open-source/activity/ > > The map that Red Hat produced is really nice, but it is a shame that > www.openstreetmap.org maps aren't used and promoted. > It is strange to see Red Hat promote Google maps when more open data > is available but closed data is used. > > There is openlayers package in Fedora repositories, and it would be > nice to see it used on Red Hat servers and on Open Source Activity > page. This is neither related to Fedora development or marketing. If you have feedback about Red Hat specific things unrelated to Fedora, please contact Red Hat directly. On the other hand, this is probably work commissioned off to a third party and they would have picked Google Maps. Nevertheless, I agree it would have been better to use openlayers. That is off-topic for these forums though. Rahul From bjorn at xn--rombobjrn-67a.se Mon Jul 20 18:50:18 2009 From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=) Date: Mon, 20 Jul 2009 20:50:18 +0200 Subject: Is BuildRoot still mandatory? Message-ID: <200907202050.36351.bjorn@xn--rombobjrn-67a.se> I understand that RPMbuild in the current versions of Fedora uses a buildroot under %_topdir/BUILDROOT, regardless of any BuildRoot tag in the spec file, so it appears that the only reason to have a BuildRoot tag in a Fedora package is if it will also be built for EPEL. The packages I've made would at least need several workarounds to build on EPEL 4 or 5, and they might not even work at all. I don't feel ready to get into EPEL yet anyway, so I decided that I may try to build my packages for EPEL 6 when that time comes, but not before that. Therefore I found BuildRoot tags to be unnecessary and left them out, but RPMlint complains and so do the commenters. So my question is: If there are no plans to build a package on any distribution release where a BuildRoot tag is needed, and it is known that the package won't build cleanly on such a release, is a BuildRoot tag still required for the package to be approved for Fedora? For reference, these are my review requests: https://bugzilla.redhat.com/show_bug.cgi?id=509158 https://bugzilla.redhat.com/show_bug.cgi?id=509159 https://bugzilla.redhat.com/show_bug.cgi?id=509160 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 sundaram at fedoraproject.org Mon Jul 20 18:51:06 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 21 Jul 2009 00:21:06 +0530 Subject: Is BuildRoot still mandatory? In-Reply-To: <200907202050.36351.bjorn@xn--rombobjrn-67a.se> References: <200907202050.36351.bjorn@xn--rombobjrn-67a.se> Message-ID: <4A64BC9A.8020801@fedoraproject.org> On 07/21/2009 12:20 AM, Bj?rn Persson wrote: > So my question is: If there are no plans to build a package on any > distribution release where a BuildRoot tag is needed, and it is known that > the package won't build cleanly on such a release, is a BuildRoot tag still > required for the package to be approved for Fedora? > > For reference, these are my review requests: > https://bugzilla.redhat.com/show_bug.cgi?id=509158 > https://bugzilla.redhat.com/show_bug.cgi?id=509159 > https://bugzilla.redhat.com/show_bug.cgi?id=509160 It is still needed till packaging committee approves https://fedoraproject.org/w/index.php?title=Phase_out_buildroot_tag_%28draft%29 Rahul From tibbs at math.uh.edu Mon Jul 20 18:53:22 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 20 Jul 2009 13:53:22 -0500 Subject: Is BuildRoot still mandatory? In-Reply-To: <200907202050.36351.bjorn@xn--rombobjrn-67a.se> (=?utf-8?Q?=22Bj=C3=B6rn?= Persson"'s message of "Mon\, 20 Jul 2009 20\:50\:18 +0200") References: <200907202050.36351.bjorn@xn--rombobjrn-67a.se> Message-ID: >>>>> "BP" == Bj?rn Persson writes: BP> So my question is: If there are no plans to build a package on any BP> distribution release where a BuildRoot tag is needed, and it is BP> known that the package won't build cleanly on such a release, is a BP> BuildRoot tag still required for the package to be approved for BP> Fedora? The packaging guidelines have yet to be changed to indicate any circumstances where a buildroot tag is not required. That may happen in the future, but it has not happened yet. - J< From bill at bfccomputing.com Mon Jul 20 19:22:20 2009 From: bill at bfccomputing.com (Bill McGonigle) Date: Mon, 20 Jul 2009 15:22:20 -0400 Subject: Open Source Activity Map (for Red Hat marketing) In-Reply-To: <64b14b300907201108k6477f897m2a2d276377159d6a@mail.gmail.com> References: <64b14b300907201108k6477f897m2a2d276377159d6a@mail.gmail.com> Message-ID: <4A64C3EC.9090602@bfccomputing.com> On 07/20/2009 02:08 PM, Valent Turkovic wrote: > There is openlayers package in Fedora repositories, and it would be > nice to see it used on Red Hat servers and on Open Source Activity > page. FWIW, I got nothing in the map box until I let NoScript allow access to openlayers.org. Has anybody looked at packaging JOSM, et. al in Fedora? -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/ Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: bill at bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf From tibbs at math.uh.edu Mon Jul 20 19:32:56 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 20 Jul 2009 14:32:56 -0500 Subject: Open Source Activity Map (for Red Hat marketing) In-Reply-To: <4A64C3EC.9090602@bfccomputing.com> (Bill McGonigle's message of "Mon\, 20 Jul 2009 15\:22\:20 -0400") References: <64b14b300907201108k6477f897m2a2d276377159d6a@mail.gmail.com> <4A64C3EC.9090602@bfccomputing.com> Message-ID: >>>>> "BM" == Bill McGonigle writes: BM> Has anybody looked at packaging JOSM, et. al in Fedora? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=508351 Feel free to help review it. - J< From jkeating at redhat.com Mon Jul 20 20:07:56 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 20 Jul 2009 13:07:56 -0700 Subject: Release Engineering meeting summary for 2009-07-20 Message-ID: <1248120476.25689.11.camel@localhost.localdomain> Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-20/fedora-meeting.2009-07-20-18.18.html Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-20/fedora-meeting.2009-07-20-18.18.log.html Meeting log ----------- * **Roll Call** (f13-18:18:42_) * **old business** (f13-18:21:09_) * *ACTION*: f13 to send an updated list of orphans to be purged (f13-18:26:51_) * *ACTION*: f13 will /really/ spend time on FAD this week. (f13-18:27:32_) * *ACTION*: f13 still needs to file ticket about backing down how aggressive the gpg signed copy cleanup is in koji (f13-18:28:23_) * **Critical Path** (f13-18:28:50_) * *ACTION*: lmacken to report next week on bodhi changes for Critical Path Packages (f13-18:39:15_) * *ACTION*: f13 will work on getting offtrac packaged up in Fedora and a 'make tag-request' target added to the make system. Also tied into checking if critical path package or not. (f13-18:50:05_) * *LINK*: http://www.flickr.com/photos/iamjessekeating/3736843791/ <--EVIDENCE (skvidal-19:05:46_) * **No Frozen Rawhide** (f13-19:06:37_) * *ACTION*: f13 will try to get folks together to define missing parts of the no frozen rawhide proposal this week (f13-19:23:36_) * **Fedora 12 Alpha** (f13-19:26:25_) * **open floor** (f13-19:31:45_) * **Mass Rebuild** (f13-19:33:08_) * *AGREED*: We should attempt a mass rebuild driven by releng for arch and XZ support. (f13-19:51:20_) * *ACTION*: notting will copy the F11 mass rebuild wiki page for F12 (f13-19:51:37_) * *AGREED*: Mass rebuilds will start Thursday the 23rd, to finish by Tuesday the 28th. Cleanups will target completion by tuesday the 4th (f13-19:55:57_) * *ACTION*: notting will announce the mass rebuild to fedora-devel-announce (f13-20:01:33_) The logs mention the F12 schedule needing to be updated, but poelcat actually did that and I didn't find it earlier. I forgot to note that during the meeting but I'm noting it here and I removed the action items from the list. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Mon Jul 20 20:14:39 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 20 Jul 2009 16:14:39 -0400 Subject: Mass rebuild for Fedora 12 Message-ID: <20090720201439.GA11912@nostromo.devel.redhat.com> Fedora Release Enginerering is going to be starting a mass rebuild this Thursday, July 28th, for the following Fedora 12 features: - XZ RPM Payloads - x86 Architecture Support Just as in the Fedora 11 mass rebuild, if you'd like to opt out for your packages, check a file into your package's devel/ branch, named 'noautobuild'. This file should contain a short rationale of why you wish to do the build yourself. Note that if you do not do a rebuild during the timeframe before Alpha, one will be done regardless of the presence of this file. Also note that delta RPMS will be disabled in rawhide for the duration of this mass rebuild; delta rpms across payload format changes in RPM are not useful. For more information, see: https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From paul at all-the-johnsons.co.uk Mon Jul 20 20:35:57 2009 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 20 Jul 2009 21:35:57 +0100 Subject: Are all your Fedora 12 Features Where They Should be? In-Reply-To: <20090720065230.GA29892@mother.pipebreaker.pl> References: <4A63E68F.90908@redhat.com> <1248070877.5010.4.camel@PB3.linux> <20090720065230.GA29892@mother.pipebreaker.pl> Message-ID: <1248122157.26592.0.camel@PB3.linux> Hi, > Could you try running "gparted" as root after plugging USB drive? > For me it triggers some kind of scan, after which proper HAL-based mount > proccess works. Still says i'm not authorised to mount the drive... TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Mon Jul 20 20:43:05 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 20 Jul 2009 16:43:05 -0400 Subject: Mass rebuild for Fedora 12 In-Reply-To: <20090720201439.GA11912@nostromo.devel.redhat.com> References: <20090720201439.GA11912@nostromo.devel.redhat.com> Message-ID: <20090720204305.GA13195@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > Fedora Release Enginerering is going to be starting a mass rebuild this > Thursday, July 28th, for the following Fedora 12 features: That would be Thursday the 23rd, as per the web page. > - XZ RPM Payloads > - x86 Architecture Support Bill _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jkeating at redhat.com Mon Jul 20 21:43:57 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 20 Jul 2009 14:43:57 -0700 Subject: Purging the F12 orphans In-Reply-To: <1247594323.3073.1169.camel@localhost.localdomain> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> Message-ID: <1248126237.25689.12.camel@localhost.localdomain> On Tue, 2009-07-14 at 10:58 -0700, Jesse Keating wrote: > The first list was incomplete due to an API change. Here is the > complete list: Here is an updated list. I'm still trying to work out some code to repoclose with each of these gone. Unblocked orphan apollon Unblocked orphan bes Unblocked orphan bytelist Unblocked orphan constantine Unblocked orphan cryptix Unblocked orphan dap-freeform_handler Unblocked orphan dap-hdf4_handler Unblocked orphan dap-netcdf_handler Unblocked orphan dap-server Unblocked orphan drapes Unblocked orphan elsa Unblocked orphan flpsed Unblocked orphan fmit Unblocked orphan fontypython Unblocked orphan galago-daemon Unblocked orphan galago-filesystem Unblocked orphan garmin-sync Unblocked orphan gdhcpd Unblocked orphan gfa Unblocked orphan gift Unblocked orphan gift-gnutella Unblocked orphan gift-openft Unblocked orphan gimp-lqr-plugin Unblocked orphan glipper Unblocked orphan gnochm Unblocked orphan gnome-audio Unblocked orphan gnome-compiz-manager Unblocked orphan gnome-vfs2-obexftp Unblocked orphan gnubiff Unblocked orphan goffice04 Unblocked orphan gstm Unblocked orphan ht2html Unblocked orphan jcodings Unblocked orphan jflex Unblocked orphan jline Unblocked orphan joni Unblocked orphan jrexx Unblocked orphan jruby Unblocked orphan junitperf Unblocked orphan jvyamlb Unblocked orphan klear Unblocked orphan ldapvi Unblocked orphan libatomic_ops Unblocked orphan libchmxx Unblocked orphan libdap Unblocked orphan libdockapp Unblocked orphan libgtksourceviewmm Unblocked orphan liblqr-1 Unblocked orphan libnc-dap Unblocked orphan lxsession-lite Unblocked orphan macchanger Unblocked orphan metamonitor Unblocked orphan msv Unblocked orphan musicbox Unblocked orphan otl Unblocked orphan pam_keyring Unblocked orphan pcmanx-gtk2 Unblocked orphan perl-LWP-Authen-Wsse Unblocked orphan perl-Text-CHM Unblocked orphan pessulus Unblocked orphan piccolo Unblocked orphan pidgin-knotify Unblocked orphan plexus-container-default Unblocked orphan plexus-interactivity Unblocked orphan plexus-velocity Unblocked orphan puretls Unblocked orphan pystatgrab Unblocked orphan python-cjson Unblocked orphan python-dbsprockets Unblocked orphan qt-qsa Unblocked orphan quickfix Unblocked orphan ruby-flexmock Unblocked orphan scim-input-pad Unblocked orphan scim-skk Unblocked orphan scim-tomoe Unblocked orphan shapelib Unblocked orphan skkdic Unblocked orphan surfraw Unblocked orphan themes-backgrounds-gnome Unblocked orphan thinkfinger Unblocked orphan tomoe Unblocked orphan tremulous-data Unblocked orphan viewmtn Unblocked orphan w3lib Unblocked orphan wdm Unblocked orphan wmix Unblocked orphan wxdfast Unblocked orphan xml-commons-apis12 Unblocked orphan xml-commons-which Unblocked orphan xmms-cdread Unblocked orphan xyz-gallery -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Mon Jul 20 22:38:25 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 21 Jul 2009 00:38:25 +0200 Subject: Rawhide fonts problem report for 2009-07-20 In-Reply-To: <4A64AC2C.5080405@gmail.com> References: <1248093112.13758.5.camel@arekh.okg> <4A64792B.6070101@gmail.com> <1248106264.16195.3.camel@arekh.okg> <4A64AC2C.5080405@gmail.com> Message-ID: <1248129505.16195.5.camel@arekh.okg> Le lundi 20 juillet 2009 ? 13:41 -0400, Qianqian Fang a ?crit : > Getting opentype bitmap/sfnt wrapper to work for bitmaps is > definitely the way to go: it not only saves more than half of > the space, but also makes rendering a lot faster. The only > concern is the support to GTK1 applications which reply on the > legacy X font settings. Well GTK1 passed in WE_DON'T_CARE land a long time ago. It never even supported UTF-8 in a satisfactory way, IIRC -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rodd at clarkson.id.au Tue Jul 21 03:10:58 2009 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 21 Jul 2009 13:10:58 +1000 Subject: Fit and Finish test day: batteries and suspend In-Reply-To: <1247849443.1614.8.camel@planemask> References: <1247849443.1614.8.camel@planemask> Message-ID: <1248145858.6202.19.camel@moose.localdomain> I'd really like to join in with this having experienced issues with suspend/resume with: * Dell Inspiron 9300 (using nvidia driver as nouveau/nv don't support suspend/resume) * Dell Studion XPS 16 (using either radeon or radionhd as the catalyst driver won't compile on kernel 2.6.29) * EeePC 1000 series with the 160GB HDD (using the default x driver) However, I'm a little confused how to build myself a livecd with rawhide on is and to be honest, I don't have the time to figure it out (as it appears it's going to take some investigation). It would be great if the test day (and others) could link to a iso for rawhide that fits on a CD to make this part of the process simple. hint, hint ;-] Rodd On Fri, 2009-07-17 at 12:50 -0400, Matthias Clasen wrote: > Just a reminder: > > The next 'fit and finish' test day will take place on July 21, which is > next Tuesday. We want to look at issues with the user experience around > batteries, suspend and power management in general. > > https://fedoraproject.org/wiki/Test_Day:2009-07-21_Fit_and_Finish:Batteries_and_Suspend > > Please join us in #fedora-fit-and-finish. > > > Matthias > -- MOOSE technology po box 6061, north croydon, vic 3136 mobile: 0403 338 731 http://www.moosetech.com.au phone: 03 9726 9457 mailto:rodd at moosetech.com.au fax: 03 9726 9456 "Share your knowledge. It is a way to achieve immortality." -- The Dalai Lama From jkeating at redhat.com Tue Jul 21 03:11:32 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 20 Jul 2009 20:11:32 -0700 Subject: Purging the F12 orphans In-Reply-To: <1248126237.25689.12.camel@localhost.localdomain> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> <1248126237.25689.12.camel@localhost.localdomain> Message-ID: <1248145892.25689.15.camel@localhost.localdomain> On Mon, 2009-07-20 at 14:43 -0700, Jesse Keating wrote: > Here is an updated list. I'm still trying to work out some code to > repoclose with each of these gone. > > Unblocked orphan apollon > Unblocked orphan bes > Unblocked orphan bytelist > Unblocked orphan constantine > Unblocked orphan cryptix > Unblocked orphan dap-freeform_handler > Unblocked orphan dap-hdf4_handler > Unblocked orphan dap-netcdf_handler > Unblocked orphan dap-server > Unblocked orphan drapes > Unblocked orphan elsa > Unblocked orphan flpsed > Unblocked orphan fmit > Unblocked orphan fontypython > Unblocked orphan galago-daemon > Unblocked orphan galago-filesystem > Unblocked orphan garmin-sync > Unblocked orphan gdhcpd > Unblocked orphan gfa > Unblocked orphan gift > Unblocked orphan gift-gnutella > Unblocked orphan gift-openft > Unblocked orphan gimp-lqr-plugin > Unblocked orphan glipper > Unblocked orphan gnochm > Unblocked orphan gnome-audio > Unblocked orphan gnome-compiz-manager > Unblocked orphan gnome-vfs2-obexftp > Unblocked orphan gnubiff > Unblocked orphan goffice04 > Unblocked orphan gstm > Unblocked orphan ht2html > Unblocked orphan jcodings > Unblocked orphan jflex > Unblocked orphan jline > Unblocked orphan joni > Unblocked orphan jrexx > Unblocked orphan jruby > Unblocked orphan junitperf > Unblocked orphan jvyamlb > Unblocked orphan klear > Unblocked orphan ldapvi > Unblocked orphan libatomic_ops > Unblocked orphan libchmxx > Unblocked orphan libdap > Unblocked orphan libdockapp > Unblocked orphan libgtksourceviewmm > Unblocked orphan liblqr-1 > Unblocked orphan libnc-dap > Unblocked orphan lxsession-lite > Unblocked orphan macchanger > Unblocked orphan metamonitor > Unblocked orphan msv > Unblocked orphan musicbox > Unblocked orphan otl > Unblocked orphan pam_keyring > Unblocked orphan pcmanx-gtk2 > Unblocked orphan perl-LWP-Authen-Wsse > Unblocked orphan perl-Text-CHM > Unblocked orphan pessulus > Unblocked orphan piccolo > Unblocked orphan pidgin-knotify > Unblocked orphan plexus-container-default > Unblocked orphan plexus-interactivity > Unblocked orphan plexus-velocity > Unblocked orphan puretls > Unblocked orphan pystatgrab > Unblocked orphan python-cjson > Unblocked orphan python-dbsprockets > Unblocked orphan qt-qsa > Unblocked orphan quickfix > Unblocked orphan ruby-flexmock > Unblocked orphan scim-input-pad > Unblocked orphan scim-skk > Unblocked orphan scim-tomoe > Unblocked orphan shapelib > Unblocked orphan skkdic > Unblocked orphan surfraw > Unblocked orphan themes-backgrounds-gnome > Unblocked orphan thinkfinger > Unblocked orphan tomoe > Unblocked orphan tremulous-data > Unblocked orphan viewmtn > Unblocked orphan w3lib > Unblocked orphan wdm > Unblocked orphan wmix > Unblocked orphan wxdfast > Unblocked orphan xml-commons-apis12 > Unblocked orphan xml-commons-which > Unblocked orphan xmms-cdread > Unblocked orphan xyz-gallery List of deps left behind by orphan removal: Orphan: bes dap-freeform_handler requires libbes_dap.so.3 dap-freeform_handler requires bes-devel = 3.6.2-4.fc11 dap-freeform_handler requires libbes_dispatch.so.7 dap-hdf4_handler requires libbes_dap.so.3 dap-hdf4_handler requires bes-devel = 3.6.2-4.fc11 dap-hdf4_handler requires libbes_dispatch.so.7 dap-netcdf_handler requires libbes_dap.so.3 dap-netcdf_handler requires bes-devel = 3.6.2-4.fc11 dap-netcdf_handler requires libbes_dispatch.so.7 dap-server requires libbes_dap.so.3 dap-server requires bes-devel = 3.6.2-4.fc11 dap-server requires libbes_dispatch.so.7 Orphan: bytelist jruby requires bytelist = 1.0.1-0.2.svn9177.fc11 jvyamlb requires bytelist = 1.0.1-0.2.svn9177.fc11 Orphan: constantine jruby requires constantine = 0.4-3.fc11 Orphan: cryptix cryptix-asn1 requires cryptix = 3.2.0-12.fc11 puretls requires cryptix = 3.2.0-12.fc11 Orphan: dap-freeform_handler dap-server-cgi requires dap-freeform_handler = 3.7.9-2.fc11 Orphan: dap-hdf4_handler dap-server-cgi requires dap-hdf4_handler = 3.7.9-2.fc11 Orphan: dap-netcdf_handler dap-server-cgi requires dap-netcdf_handler = 3.7.9-2.fc11 Orphan: gift apollon requires libgift.so.0 apollon requires gift-devel = 0.11.8.1-12.fc11 gift-gnutella requires libgift.so.0 gift-gnutella requires libgiftproto.so.0 gift-gnutella requires gift-devel = 0.11.8.1-12.fc11 gift-openft requires libgift.so.0 gift-openft requires libgiftproto.so.0 gift-openft requires gift-devel = 0.11.8.1-12.fc11 Orphan: ht2html jython requires ht2html = 2.0-9.fc11 Orphan: jcodings bytelist requires jcodings = 1.0.1-2.fc11 joni requires jcodings = 1.0.1-2.fc11 jruby requires jcodings = 1.0.1-2.fc11 jvyamlb requires jcodings = 1.0.1-2.fc11 Orphan: jflex opengrok requires jflex = 1.4.1-0.4.fc11 qdox requires jflex = 1.4.1-0.4.fc11 Orphan: jline jruby requires jline = 0.9.94-0.3.fc11 lucene requires jline = 0.9.94-0.3.fc11 maven-wagon requires jline = 0.9.94-0.3.fc11 maven2 requires jline = 0.9.94-0.3.fc11 plexus-interactivity requires jline = 0.9.94-0.3.fc11 rhino requires jline = 0.9.94-0.3.fc11 scala requires jline = 0.9.94-0.3.fc11 Orphan: joni jruby requires joni = 1.1.3-1.fc11 Orphan: junitperf dom4j requires junitperf = 1.9.1-3.2.fc11 Orphan: jvyamlb jruby requires jvyamlb = 0.2.5-2.fc11 Orphan: libatomic_ops gc requires libatomic_ops-devel = 1.2-6.fc12 pulseaudio requires libatomic_ops-devel = 1.2-6.fc12 Orphan: libdap bes requires libdap-devel = 3.8.2-3.fc11 bes requires libdapserver.so.6 bes requires libdap.so.9 bes-devel requires libdap-devel = 3.8.2-3.fc11 bes-devel requires pkgconfig(libdapserver) = 3.8.2 dap-freeform_handler requires libdap-devel = 3.8.2-3.fc11 dap-freeform_handler requires libdapserver.so.6 dap-freeform_handler requires libdap.so.9 dap-hdf4_handler requires libdap-devel = 3.8.2-3.fc11 dap-hdf4_handler requires libdapserver.so.6 dap-hdf4_handler requires libdap.so.9 dap-netcdf_handler requires libdap-devel = 3.8.2-3.fc11 dap-netcdf_handler requires libdapserver.so.6 dap-netcdf_handler requires libdap.so.9 dap-server requires libdap-devel = 3.8.2-3.fc11 dap-server requires libdapserver.so.6 dap-server requires libdapclient.so.3 dap-server requires libdap.so.9 gdal requires libdap-devel = 3.8.2-3.fc11 gdal requires libdapserver.so.6 gdal requires libdapclient.so.3 gdal requires libdap.so.9 gdal-perl requires libdapserver.so.6 gdal-perl requires libdapclient.so.3 gdal-perl requires libdap.so.9 gdal-python requires libdapserver.so.6 gdal-python requires libdapclient.so.3 gdal-python requires libdap.so.9 gdal-ruby requires libdapserver.so.6 gdal-ruby requires libdapclient.so.3 gdal-ruby requires libdap.so.9 grads requires libdap.so.9 libnc-dap requires libdap-devel = 3.8.2-3.fc11 libnc-dap requires libdapclient.so.3 libnc-dap requires libdap.so.9 libnc-dap-devel requires libdap-devel = 3.8.2-3.fc11 libnc-dap-devel requires pkgconfig(libdapclient) = 3.8.2 ncl requires libdapclient.so.3 ncl requires libdap.so.9 Orphan: libdockapp wmacpi requires libdockapp.so.2 wmacpi requires libdockapp-devel = 0.6.2-2.fc11 Orphan: liblqr-1 gimp-lqr-plugin requires liblqr-1.so.0 gimp-lqr-plugin requires liblqr-1-devel = 0.1.0-7.fc11 Orphan: libnc-dap grads requires libnc-dap.so.3 grads requires libnc-dap-devel = 3.7.3-2.fc11 ncl requires libnc-dap.so.3 ncl requires libnc-dap-devel = 3.7.3-2.fc11 nco requires libnc-dap-devel = 3.7.3-2.fc11 octave-forge requires libnc-dap-devel = 3.7.3-2.fc11 Orphan: lxsession-lite lxde-common requires lxsession = 0.3.6-4.fc12 lxsession-edit requires lxsession = 0.3.6-4.fc12 Orphan: msv dom4j requires msv-xsdlib = 1:1.2-0.3.20050722.3.4.fc12.1 dom4j requires msv-msv = 1:1.2-0.3.20050722.3.4.fc12.1 Orphan: pcmanx-gtk2 gnash-plugin requires /usr/lib/mozilla/plugins gnome-chemistry-utils-mozplugin requires /usr/lib/mozilla/plugins java-1.6.0-openjdk-plugin requires /usr/lib/mozilla/plugins mozilla-opensc-signer requires /usr/lib/mozilla/plugins swfdec-mozilla requires /usr/lib/mozilla/plugins Orphan: plexus-container-default maven-doxia requires plexus-container-default = 1.0-0.2.a8.1.2.fc11 maven-wagon requires plexus-container-default = 1.0-0.2.a8.1.2.fc11 maven2 requires plexus-container-default = 1.0-0.2.a8.1.2.fc11 maven2-plugin-source requires plexus-container-default = 1.0-0.2.a8.1.2.fc11 modello requires plexus-container-default = 1.0-0.2.a8.1.2.fc11 plexus-ant-factory requires plexus-container-default = 1.0-0.2.a8.1.2.fc11 plexus-appserver requires plexus-container-default = 1.0-0.2.a8.1.2.fc11 plexus-archiver requires plexus-container-default = 1.0-0.2.a8.1.2.fc11 plexus-bsh-factory requires plexus-container-default = 1.0-0.2.a8.1.2.fc11 plexus-cdc requires plexus-container-default = 1.0-0.2.a8.1.2.fc11 plexus-compiler requires plexus-container-default = 1.0-0.2.a8.1.2.fc11 plexus-i18n requires plexus-container-default = 1.0-0.2.a8.1.2.fc11 plexus-interactivity requires plexus-container-default = 1.0-0.2.a8.1.2.fc11 plexus-maven-plugin requires plexus-container-default = 1.0-0.2.a8.1.2.fc11 plexus-runtime-builder requires plexus-container-default = 1.0-0.2.a8.1.2.fc11 plexus-velocity requires plexus-container-default = 1.0-0.2.a8.1.2.fc11 plexus-xmlrpc requires plexus-container-default = 1.0-0.2.a8.1.2.fc11 Orphan: plexus-interactivity maven-wagon requires plexus-interactivity = 1.0-0.2.a5.2.3.fc11 maven2 requires plexus-interactivity = 1.0-0.2.a5.2.3.fc11 maven2-plugin-release requires plexus-interactivity = 1.0-0.2.a5.2.3.fc11 Orphan: plexus-velocity maven-doxia requires plexus-velocity = 1.1.2-4.2.fc11 maven2 requires plexus-velocity = 1.1.2-4.2.fc11 maven2-plugin-checkstyle requires plexus-velocity = 1.1.2-4.2.fc11 modello requires plexus-velocity = 1.1.2-4.2.fc11 plexus-runtime-builder requires plexus-velocity = 1.1.2-4.2.fc11 Orphan: pystatgrab ldtp requires pystatgrab = 0.5-5.fc11 Orphan: python-cjson sugar-datastore requires python-cjson = 1.0.5-3.fc11 Orphan: qt-qsa LabPlot requires qt-qsa-devel = 1.1.5-6.fc11 LabPlot requires libqsa.so.1 Orphan: ruby-flexmock rubygem-cobbler requires ruby-flexmock = 0.7.1-4.fc11 rubygem-rake requires ruby(flexmock) = 0.7.1 Orphan: shapelib python-basemap requires shapelib-devel = 1.2.10-19.20060304cvs xastir requires libshp.so.1 xastir requires shapelib-devel = 1.2.10-19.20060304cvs Orphan: skkdic cmigemo requires skkdic = 20080904-2.fc11 scim-skk requires skkdic = 20080904-2.fc11 uim-skk requires skkdic = 20080904-2.fc11 Orphan: tomoe scim-tomoe requires tomoe-devel = 0.6.0-14.fc12 scim-tomoe requires libtomoe.so.0 scim-tomoe requires tomoe = 0.6.0-14.fc12 tomoe-gtk requires tomoe-devel = 0.6.0-14.fc12 tomoe-gtk requires libtomoe.so.0 tomoe-gtk requires tomoe = 0.6.0-14.fc12 tomoe-gtk-devel requires tomoe-devel = 0.6.0-14.fc12 tomoe-gtk-devel requires pkgconfig(tomoe) = 0.6.0 tomoe-gtk-devel requires libtomoe.so.0 Orphan: xml-commons-apis12 dom4j requires jaxp = 1.2 -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A 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 dgboles at comcast.net Tue Jul 21 03:18:53 2009 From: dgboles at comcast.net (David) Date: Mon, 20 Jul 2009 23:18:53 -0400 Subject: Mass rebuild for Fedora 12 In-Reply-To: <20090720201439.GA11912@nostromo.devel.redhat.com> References: <20090720201439.GA11912@nostromo.devel.redhat.com> Message-ID: <4A65339D.1020901@comcast.net> On 7/20/2009 4:14 PM, Bill Nottingham wrote: > Fedora Release Enginerering is going to be starting a mass rebuild this > Thursday, July 28th, for the following Fedora 12 features: > - XZ RPM Payloads > - x86 Architecture Support > > Just as in the Fedora 11 mass rebuild, if you'd like to opt out for > your packages, check a file into your package's devel/ branch, named > 'noautobuild'. This file should contain a short rationale of why you > wish to do the build yourself. Note that if you do not do a rebuild > during the timeframe before Alpha, one will be done regardless of > the presence of this file. > > Also note that delta RPMS will be disabled in rawhide for the duration > of this mass rebuild; delta rpms across payload format changes in > RPM are not useful. > > For more information, see: > https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild Recommendation? Continue to update Fedora 12/Rawhide during the rebuild? Or wait until the rebuild is completed? -- David From jonstanley at gmail.com Tue Jul 21 03:41:04 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Mon, 20 Jul 2009 23:41:04 -0400 Subject: Mass rebuild for Fedora 12 In-Reply-To: <4A65339D.1020901@comcast.net> References: <20090720201439.GA11912@nostromo.devel.redhat.com> <4A65339D.1020901@comcast.net> Message-ID: On Mon, Jul 20, 2009 at 11:18 PM, David wrote: > Continue to update Fedora 12/Rawhide during the rebuild? > > Or wait until the rebuild is completed? The rebuild will land all at once as the builds get moved from dist-f12-rebuild to dist-f12. So keep on updating, you'll have one massive update one day :) From mclasen at redhat.com Tue Jul 21 04:01:42 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 21 Jul 2009 00:01:42 -0400 Subject: Fit and Finish test day: batteries and suspend In-Reply-To: <1248145858.6202.19.camel@moose.localdomain> References: <1247849443.1614.8.camel@planemask> <1248145858.6202.19.camel@moose.localdomain> Message-ID: <1248148903.1510.12.camel@planemask> On Tue, 2009-07-21 at 13:10 +1000, Rodd Clarkson wrote: > > It would be great if the test day (and others) could link to a iso for > rawhide that fits on a CD to make this part of the process simple. > > hint, hint ;-] > Yeah, I'm working on it. However, todays (and yesterdays) spins so far had the unfortunate tendency to not boot at all, at least in qemu. From fangqq at gmail.com Tue Jul 21 04:30:48 2009 From: fangqq at gmail.com (Qianqian Fang) Date: Tue, 21 Jul 2009 00:30:48 -0400 Subject: Rawhide fonts problem report for 2009-07-20 In-Reply-To: <4A6481AE.7030602@redhat.com> References: <1248093112.13758.5.camel@arekh.okg> <4A64792B.6070101@gmail.com> <4A647B3B.8080906@redhat.com> <4A647FE9.9040300@gmail.com> <4A6481AE.7030602@redhat.com> Message-ID: <4A654478.8070100@gmail.com> hey, I am so supprised, I downloaded the SFNT ttf font I made 3 years ago, and did an fc-cache, you know what? it worked! some magic must had happened in the past 3 years, and I am really glad that this multi-strike SFNT bitmap font is now supported. This cuts the package size from 6.2M for the original PCF font down to only 2M, and I believe the rendering speed will also boost significantly. Nicolas: when do you want the bitmap format conversion to happen? the sooner the better or convert them all together at some point? Qianqian Behdad Esfahbod wrote: > On 07/20/2009 10:32 AM, Qianqian Fang wrote: >> >> Behdad Esfahbod wrote: >>> On 07/20/2009 10:03 AM, Qianqian Fang wrote: >>>> Nicolas Mailhot wrote: >>>>> ? Mid-term, files in legacy PCF or Type1 formats need to be converted >>>>> or removed. >>>> >>>> just curious, for PCF, what format you plan to convert to ? >>>> >>>> I had tried SFNT TTF/OTF, neither of them works with the current >>>> fontconfig >>>> (cache file could not be generated). >>> >>> File a bug?!?!? >>> >>> behdad >> >> yes, I brought it up on fontconfig's mailing list in 2006, > > That's not filing a bug. > > >> mpsuzuki posted a patch, but it has never been committed. > > That's exactly why one should file a bug. > > >> http://lists.freedesktop.org/archives/fontconfig/2006-August/002364.html >> >> also, it seemed there were some intrinsic difficulties for fontconfig to >> handle multi-strike sfnt ttf. >> >> Qianqian > > behdad > From arxs at fedoraproject.org Tue Jul 21 05:44:14 2009 From: arxs at fedoraproject.org (Niels Haase) Date: Tue, 21 Jul 2009 07:44:14 +0200 Subject: F-11 updates seem hosed today In-Reply-To: <20090720164019.GA12206@wolff.to> References: <27515.1247510172@sss.pgh.pa.us> <4A5B7F72.4070708@redhat.com> <4A646F6B.6010400@jcomserv.net> <20090720164019.GA12206@wolff.to> Message-ID: <571dcba60907202244h1a1977aexd42603c88275d28c@mail.gmail.com> 2009/7/20 Bruno Wolff III : > On Mon, Jul 20, 2009 at 08:21:47 -0500, > ?Jon Ciesla wrote: >>> >> Any word on this? ?I still don't seem to have anything on the mirror I >> sync from. . . > > See: > https://fedorahosted.org/fedora-infrastructure/ticket/1531 > > Based on comments it looks like things should start returning to normal > soon, but I am still not seeing a lot of up to date mirrros. > > I did have pretty good success with the mirror at ftp-stud.hs-esslingen.de . > the hs-esslingen mirror provides some nice information about the sync state to the master servers. For Fedora you can find the information for Updates [1] Development [2] Release [3] [1] http://ftp-stud.hs-esslingen.de/info/status.php4?details=57 [2] http://ftp-stud.hs-esslingen.de/info/status.php4?details=58 [3] http://ftp-stud.hs-esslingen.de/info/status.php4?details=60 -- Regards, Niels > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From nicolas.mailhot at laposte.net Tue Jul 21 06:10:49 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 21 Jul 2009 08:10:49 +0200 Subject: Rawhide fonts problem report for 2009-07-20 In-Reply-To: <4A654478.8070100@gmail.com> References: <1248093112.13758.5.camel@arekh.okg> <4A64792B.6070101@gmail.com> <4A647B3B.8080906@redhat.com> <4A647FE9.9040300@gmail.com> <4A6481AE.7030602@redhat.com> <4A654478.8070100@gmail.com> Message-ID: <1248156649.16195.12.camel@arekh.okg> Le mardi 21 juillet 2009 ? 00:30 -0400, Qianqian Fang a ?crit : > when do you want the bitmap format conversion to happen? the sooner > the better or convert them all together at some point? I don't think Fedora will want to do the conversion unilaterally. So that leaves out single-day conversion. It will take a long time to reach all the upstreams we package PCF fonts from, and to convince them to change (and then some will probably never move so there will probably be a "dump remaining pcfs" days). It will probably also expose a few bugs application-side so they'll have to be reported and fixed. If you can make a few upstreams to switch and document the conversion somewhere I'll be happy to make it an error in the checking switch and them propose to ban new pcf fonts in Fedora guidelines. Having some high-visibility projects such as terminus to convert first would be a good start (I'm pretty sure using opentype features such as locl would help terminus shed all the optional patches it carries). -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Tue Jul 21 06:18:16 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 21 Jul 2009 08:18:16 +0200 Subject: Rawhide fonts problem report for 2009-07-20 In-Reply-To: <1248156649.16195.12.camel@arekh.okg> References: <1248093112.13758.5.camel@arekh.okg> <4A64792B.6070101@gmail.com> <4A647B3B.8080906@redhat.com> <4A647FE9.9040300@gmail.com> <4A6481AE.7030602@redhat.com> <4A654478.8070100@gmail.com> <1248156649.16195.12.camel@arekh.okg> Message-ID: <1248157096.14215.3.camel@arekh.okg> Le mardi 21 juillet 2009 ? 08:10 +0200, Nicolas Mailhot a ?crit : > I don't think Fedora will want to do the conversion unilaterally. So > that leaves out single-day conversion. It will take a long time to reach > all the upstreams we package PCF fonts from, Though on reflection the audit script only reports 11 affected srpms Format Files rpm srpm Files (MiB) rpm (MiB) PCF 204 6 6 32 52 ? font files in other packages (we should not find any!) Format Files rpm srpm Files (MiB) rpm (MiB) PCF 872 10 5 13 55 So it looks manageable. And xorg is probably the bulk of it. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From valent.turkovic at gmail.com Tue Jul 21 07:35:10 2009 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 21 Jul 2009 09:35:10 +0200 Subject: Open Source Activity Map (for Red Hat marketing) In-Reply-To: References: <64b14b300907201108k6477f897m2a2d276377159d6a@mail.gmail.com> <4A64C3EC.9090602@bfccomputing.com> Message-ID: <64b14b300907210035v279dda43j40cf6e878ccc8a49@mail.gmail.com> On Mon, Jul 20, 2009 at 9:32 PM, Jason L Tibbitts III wrote: >>>>>> "BM" == Bill McGonigle writes: > > BM> Has anybody looked at packaging JOSM, et. al in Fedora? > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=508351 > > Feel free to help review it. I also found out that there is a Fedora Geo Spin: https://fedoraproject.org/wiki/User:Ynemoy/Fedora_Geo_Spin It would greatly benefit from JOSM in repositories, just a warning JOSM is stable but versions change quite rapidly. ps. can't wait to see OpenStreetMap replace Google Maps background. Cheers! -- 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 ovasik at redhat.com Tue Jul 21 08:39:35 2009 From: ovasik at redhat.com (=?UTF-8?Q?Ond=C5=99ej_Va=C5=A1=C3=ADk?=) Date: Tue, 21 Jul 2009 10:39:35 +0200 Subject: Mass rebuild for Fedora 12 In-Reply-To: <20090720201439.GA11912@nostromo.devel.redhat.com> References: <20090720201439.GA11912@nostromo.devel.redhat.com> Message-ID: <1248165575.3850.12.camel@dhcp-lab-219.englab.brq.redhat.com> Bill Nottingham wrote: > Fedora Release Enginerering is going to be starting a mass rebuild this > Thursday, July 28th, for the following Fedora 12 features: > - XZ RPM Payloads > - x86 Architecture Support I'm a bit aware of quite recent change in FORTIFY_SOURCES - which added some checks to prevent buffer overflows. It caused (many) testsuite failures in tar and sigabrting TCL's (and I'm sure some more). Source code was almost without change, compiled just fine, but application was later SIGABRTing. There is a lot of applications without testsuite coverage, so they likely just compile well and rpm will be tagged. Later it would mean troubles for users (and potentially unstable situation) as the response time of some Fedora maintainers is quite high. I guess that gcc warning should be changed to error before that rebuild: FILE:LINE: warning: call to __builtin___strcpy_chk will always overflow destination buffer Otherwise it could mean many SIGABRTing applications, as some old dirty C practices are now failing with SIGABRTs. Changing this compilation warning to an error would mean easier detection of such dirty things and would prevent (at least some) later SIGABRTs. Should the bugzilla with request for change be filled? Greetings, Ond?ej Va??k -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Toto je digit?ln? podepsan? ??st zpr?vy URL: From jakub at redhat.com Tue Jul 21 08:46:35 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 21 Jul 2009 10:46:35 +0200 Subject: Mass rebuild for Fedora 12 In-Reply-To: <1248165575.3850.12.camel@dhcp-lab-219.englab.brq.redhat.com> References: <20090720201439.GA11912@nostromo.devel.redhat.com> <1248165575.3850.12.camel@dhcp-lab-219.englab.brq.redhat.com> Message-ID: <20090721084635.GC4462@tyan-ft48-01.lab.bos.redhat.com> On Tue, Jul 21, 2009 at 10:39:35AM +0200, Ond?ej Va??k wrote: > Bill Nottingham wrote: > > Fedora Release Enginerering is going to be starting a mass rebuild this > > Thursday, July 28th, for the following Fedora 12 features: > > - XZ RPM Payloads > > - x86 Architecture Support > > I'm a bit aware of quite recent change in FORTIFY_SOURCES - which added > some checks to prevent buffer overflows. It caused (many) testsuite > failures in tar and sigabrting TCL's (and I'm sure some more). Source > code was almost without change, compiled just fine, but application was > later SIGABRTing. There is a lot of applications without testsuite > coverage, so they likely just compile well and rpm will be tagged. Later > it would mean troubles for users (and potentially unstable situation) as > the response time of some Fedora maintainers is quite high. See http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01136.html Due to popular demand, constructs similar to flexible array members in unions at the end of structures are allowed again for str*/stp* with -D_FORTIFY_SOURCE=2, will be in the next rawhide build (today or tomorrow). > I guess that gcc warning should be changed to error before that rebuild: > FILE:LINE: warning: call to __builtin___strcpy_chk will always overflow > destination buffer It shouldn't be an error, this warning (rarely) has false positives and warns even about code that is never executed. That doesn't mean we shouldn't be grepping build logs for those warnings and letting maintainers know that they should analyse them (a job for rpmdiff or similar). Jakub From pertusus at free.fr Tue Jul 21 08:48:45 2009 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 21 Jul 2009 10:48:45 +0200 Subject: Purging the F12 orphans In-Reply-To: <1248145892.25689.15.camel@localhost.localdomain> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> <1248126237.25689.12.camel@localhost.localdomain> <1248145892.25689.15.camel@localhost.localdomain> Message-ID: <20090721084835.GA22378@free.fr> On Mon, Jul 20, 2009 at 08:11:32PM -0700, Jesse Keating wrote: > > List of deps left behind by orphan removal: bes, dap-*_handler and dap-server are associated and should either all be owned or none. > Orphan: libdap > Orphan: libnc-dap Somebody has to take those, they are a dependency of many packages. In the future they will be included within netcdf, but it isn't the case right now. -- Pat From ovasik at redhat.com Tue Jul 21 09:43:02 2009 From: ovasik at redhat.com (=?UTF-8?Q?Ond=C5=99ej_Va=C5=A1=C3=ADk?=) Date: Tue, 21 Jul 2009 11:43:02 +0200 Subject: Mass rebuild for Fedora 12 In-Reply-To: <20090721084635.GC4462@tyan-ft48-01.lab.bos.redhat.com> References: <20090720201439.GA11912@nostromo.devel.redhat.com> <1248165575.3850.12.camel@dhcp-lab-219.englab.brq.redhat.com> <20090721084635.GC4462@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <1248169382.3850.19.camel@dhcp-lab-219.englab.brq.redhat.com> Jakub Jelinek wrote: > On Tue, Jul 21, 2009 at 10:39:35AM +0200, Ond?ej Va??k wrote: > > Bill Nottingham wrote: > > > Fedora Release Enginerering is going to be starting a mass rebuild this > > > Thursday, July 28th, for the following Fedora 12 features: > > > - XZ RPM Payloads > > > - x86 Architecture Support > > > > I'm a bit aware of quite recent change in FORTIFY_SOURCES - which added > > some checks to prevent buffer overflows. It caused (many) testsuite > > failures in tar and sigabrting TCL's (and I'm sure some more). Source > > code was almost without change, compiled just fine, but application was > > later SIGABRTing. There is a lot of applications without testsuite > > coverage, so they likely just compile well and rpm will be tagged. Later > > it would mean troubles for users (and potentially unstable situation) as > > the response time of some Fedora maintainers is quite high. > > See http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01136.html > Due to popular demand, constructs similar to flexible array members in > unions at the end of structures are allowed again for str*/stp* with > -D_FORTIFY_SOURCE=2, will be in the next rawhide build (today or > tomorrow). Ok, thanks for info, it will reduce the number of unwanted failures a bit... > > I guess that gcc warning should be changed to error before that rebuild: > > FILE:LINE: warning: call to __builtin___strcpy_chk will always overflow > > destination buffer > > It shouldn't be an error, this warning (rarely) has false positives and > warns even about code that is never executed. That doesn't mean we > shouldn't be grepping build logs for those warnings and letting maintainers > know that they should analyse them (a job for rpmdiff or similar). Ok, not possible to make it an error. So what about not tagging automatically packages with those "always overflow destination buffer" warnings in Mass rebuild to prevent possible later mass SIGABRTs? Just greping for that message and later posting suspicious packages on fedora-devel-list - to let those package maintainers choose whether it is false positive or thing affecting the package functionality... Greetings, Ond?ej Va??k -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Toto je digit?ln? podepsan? ??st zpr?vy URL: From jakub at redhat.com Tue Jul 21 09:46:04 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 21 Jul 2009 11:46:04 +0200 Subject: Mass rebuild for Fedora 12 In-Reply-To: <1248169382.3850.19.camel@dhcp-lab-219.englab.brq.redhat.com> References: <20090720201439.GA11912@nostromo.devel.redhat.com> <1248165575.3850.12.camel@dhcp-lab-219.englab.brq.redhat.com> <20090721084635.GC4462@tyan-ft48-01.lab.bos.redhat.com> <1248169382.3850.19.camel@dhcp-lab-219.englab.brq.redhat.com> Message-ID: <20090721094604.GD4462@tyan-ft48-01.lab.bos.redhat.com> On Tue, Jul 21, 2009 at 11:43:02AM +0200, Ond?ej Va??k wrote: > > It shouldn't be an error, this warning (rarely) has false positives and > > warns even about code that is never executed. That doesn't mean we > > shouldn't be grepping build logs for those warnings and letting maintainers > > know that they should analyse them (a job for rpmdiff or similar). > > Ok, not possible to make it an error. > So what about not tagging automatically packages with those "always > overflow destination buffer" warnings in Mass rebuild to prevent > possible later mass SIGABRTs? Just greping for that message and later > posting suspicious packages on fedora-devel-list - to let those package > maintainers choose whether it is false positive or thing affecting the > package functionality... If we can have some kind of white list for that, why not. E.g. glibc build has a whole bunch of them, in the testcases that verify the -D_FORTIFY_SOURCE functionality and those are all intentional. Jakub From mcepl at redhat.com Tue Jul 21 10:13:07 2009 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 21 Jul 2009 10:13:07 +0000 (UTC) Subject: Purging the F12 orphans References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> <1248126237.25689.12.camel@localhost.localdomain> <1248145892.25689.15.camel@localhost.localdomain> Message-ID: Jesse Keating, Mon, 20 Jul 2009 20:11:32 -0700: > Orphan: qt-qsa > LabPlot requires qt-qsa-devel = 1.1.5-6.fc11 LabPlot requires > libqsa.so.1 I am not Qt user, but isn't qt-qsa the only how to get SSL/TLS for many (all?) Qt projects? (I know I had to install it for kopete and psi to have TLS for my Jabber account). Just that removing this might cause a bit of problem (and of course, cursed be RPM for not having Suggests/ Recommends, which would caught this). Mat?j From sven at lank.es Tue Jul 21 10:42:07 2009 From: sven at lank.es (Sven Lankes) Date: Tue, 21 Jul 2009 12:42:07 +0200 Subject: Purging the F12 orphans In-Reply-To: References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> <1248126237.25689.12.camel@localhost.localdomain> <1248145892.25689.15.camel@localhost.localdomain> Message-ID: <20090721104207.GA22143@killefiz> On Tue, Jul 21, 2009 at 10:13:07AM +0000, Matej Cepl wrote: > > Orphan: qt-qsa > I am not Qt user, but isn't qt-qsa the only how to get SSL/TLS for many > (all?) Qt projects? Yes and no. qt-qsa is the 'old' variant. The package containing the current code is "qca2" and that is still maintained. -- sven === jabber/xmpp: sven at lankes.net From stickster at gmail.com Tue Jul 21 12:46:20 2009 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 21 Jul 2009 08:46:20 -0400 Subject: Fit and Finish test day: batteries and suspend In-Reply-To: <1248145858.6202.19.camel@moose.localdomain> References: <1247849443.1614.8.camel@planemask> <1248145858.6202.19.camel@moose.localdomain> Message-ID: <20090721124620.GH1753@localhost.localdomain> On Tue, Jul 21, 2009 at 01:10:58PM +1000, Rodd Clarkson wrote: > I'd really like to join in with this having experienced issues with > suspend/resume with: > > * Dell Inspiron 9300 (using nvidia driver as nouveau/nv don't support > suspend/resume) > * Dell Studion XPS 16 (using either radeon or radionhd as the catalyst > driver won't compile on kernel 2.6.29) > * EeePC 1000 series with the 160GB HDD (using the default x driver) > > However, I'm a little confused how to build myself a livecd with rawhide > on is and to be honest, I don't have the time to figure it out (as it > appears it's going to take some investigation). I wrote this a while ago and finally moved it to a better name where more people could find it: https://fedoraproject.org/wiki/How_to_build_a_Rawhide_ISO_image_for_testing -- 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 bnocera at redhat.com Tue Jul 21 13:18:47 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 21 Jul 2009 14:18:47 +0100 Subject: AES4000 owners, please test this package! Message-ID: <1248182327.23466.1665.camel@localhost.localdomain> Hey, I've committed this patch to Fedora 12, which removes the requirement for ImageMagick, and uses gdk-pixbuf for image manipulation instead: https://bugzilla.redhat.com/show_bug.cgi?id=472103#c0 I'd appreciate if owners of AES4000 fingerprint readers could test and report problems with the patch, compared to the older versions. Fedora 11/12 packages available at: http://koji.fedoraproject.org/koji/buildinfo?buildID=115289 Cheers From fulko.hew at gmail.com Tue Jul 21 13:29:46 2009 From: fulko.hew at gmail.com (Fulko Hew) Date: Tue, 21 Jul 2009 09:29:46 -0400 Subject: How to RPM'ify Perl Modules In-Reply-To: <8204a4fe0907210621v4994548dv341dece48433ebb8@mail.gmail.com> References: <8204a4fe0907210621v4994548dv341dece48433ebb8@mail.gmail.com> Message-ID: <8204a4fe0907210629v291fbfbla8992a7442b3f61f@mail.gmail.com> I'd like to create an RPM (spec file) to package my Perl based product so that its easy to distribute and easy to add to a Fedora kickstart file, but I'm not too sure where to start. I've looked around and found cpan2rpm and rpmpan, but I'd like to know what the 'official' approach is for Fedora. Can anyone point me in the right direction? TIA Fulko From mike at cchtml.com Tue Jul 21 13:33:04 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Tue, 21 Jul 2009 08:33:04 -0500 Subject: How to RPM'ify Perl Modules In-Reply-To: <8204a4fe0907210629v291fbfbla8992a7442b3f61f@mail.gmail.com> References: <8204a4fe0907210621v4994548dv341dece48433ebb8@mail.gmail.com> <8204a4fe0907210629v291fbfbla8992a7442b3f61f@mail.gmail.com> Message-ID: <4A65C390.9090704@cchtml.com> Fulko Hew on 07/21/2009 08:29 AM wrote: > > Can anyone point me in the right direction? > https://fedoraproject.org/wiki/Packaging/Perl ? From katzj at redhat.com Tue Jul 21 13:38:02 2009 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 21 Jul 2009 09:38:02 -0400 Subject: Fit and Finish test day: batteries and suspend In-Reply-To: <1248148903.1510.12.camel@planemask> References: <1247849443.1614.8.camel@planemask> <1248145858.6202.19.camel@moose.localdomain> <1248148903.1510.12.camel@planemask> Message-ID: <20090721133801.GA27727@redhat.com> On Tuesday, July 21 2009, Matthias Clasen said: > On Tue, 2009-07-21 at 13:10 +1000, Rodd Clarkson wrote: > > It would be great if the test day (and others) could link to a iso for > > rawhide that fits on a CD to make this part of the process simple. > > > > hint, hint ;-] > > Yeah, I'm working on it. However, todays (and yesterdays) spins so far > had the unfortunate tendency to not boot at all, at least in qemu. It should be fixed with today's rawhide (mkinitrd-6.0.92) -- Jens mentioned that something was broken last night on IRC and I tracked it down to set -e in the /init of the initramfs breaking something again. Also need to figure out why we end up losing all of the (useful) output when plymouthd is running during the live /init, but at this point, I'm going to see if it continues happening once I get live images booting with dracut and just fix it there if so Jeremy From rawhide at fedoraproject.org Tue Jul 21 15:30:08 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Tue, 21 Jul 2009 15:30:08 +0000 Subject: rawhide report: 20090721 changes Message-ID: <20090721153008.GA24473@releng2.fedora.phx.redhat.com> Compose started at Tue Jul 21 06:15:03 UTC 2009 New package ghc-editline Haskell %{pgk_name} library New package gnome-do-plugins Plugins for GNOME Do New package perl-Algorithm-IncludeExclude Build and evaluate include/exclude lists New package quitcount A tool for people who quit smoking New package rpmconf Tool to handle rpmnew and rpmsave files New package xylib Library for reading x-y data from several file formats Removed package anacron Updated Packages: CodeAnalyst-gui-2.8.54-17.fc12 ------------------------------ * Mon Jul 20 2009 - Parag Nemade - 2.8.54-16 - Rebuild against new libbfd-2.19.51.0.11-24.fc12.so * Mon Jul 20 2009 - Suravee Suthikulpanit - 2.8.54-17 - Add Patch1 (ca-fix-oprofile-ibs-check.patch) - Add Patch2 (ca-fix-basename.patch) - Add Patch3 (ca-use-lbfd.patch) Terminal-0.4.0-1.fc12 --------------------- * Mon Jul 20 2009 Christoph Wickert - 0.4.0-1 - Update to 0.4.0 - Use desktop-file-install anaconda-12.3-1.fc12 -------------------- * Mon Jul 20 2009 David Cantrell - 12.3-1 - Set GECOS field for new user accounts specific in ks files (dcantrell) - Show MAC address of network device in text mode too. (rvykydal) - Fix selection of alternative iface in UI after fail (#507084). (rvykydal) - Stop the cdrom device before ejecting (#505067) (msivak) - Add hipersockets to NETTYPE description (bhinson, #511962). (clumens) - Don't show formatting progress bar after mkfs has exited. (eric_kerin) - Run firstaidkit-qs script instead of the shell (shows rescue menu) (#508512) Add dialog package required for firstaidkit Create /etc/fstab in ramdisk to make mount commands easier (#440327) (msivak) - When ignoring partitions make sure lvm also ignores them (hdegoede) - 70-anaconda.rules: pass --ignorelockingfailure to lvm invocation (hdegoede) - Call mdadm -I with --no-degraded for all disks but the last (hdegoede) - There is no /bin on the initrd so sleep needs to go into /sbin. (clumens) - Add deviceNameToDiskByPath(). (dcantrell) - Display drive model and size in MB in partitioning UI (#460697) (dcantrell) - Lots of small grammar and wording changes. (pjones) - Edit user-visible dialogs for style. (pjones) - Get rid of sloppy elipses usage. (pjones) - Don't write optical devices to /etc/fstab (#505697). (clumens) - error messages of zFCP on s390: log or pass to the UI (maier) - correctly delete a SCSI device provided by a zFCP LUN on s390 (maier) - All other teardown methods take a "recursive" argument (#506166). (clumens) - Clean yum caches following preupgrade, too (#503096). (clumens) apr-api-docs-1.3.6-1.fc12 ------------------------- * Fri Jul 17 2009 Bojan Smojver 1.3.6-1 - Bump up to 1.3.6 audacity-1.3.8-0.2.beta.fc12 ---------------------------- * Mon Jul 20 2009 Michael Schwendt - 1.3.8-0.1.beta - upgrade to 1.3.8-beta - BR taglib-devel - patches merged/obsoleted upstream: audacity-1.3.7-portaudio-non-mmap-alsa.patch audacity-1.3.7-repeat.patch audacity-1.3.6-flac-import.patch * Mon Jul 20 2009 Michael Schwendt - 1.3.8-0.2.beta - glib2 2.21.1's gio in Rawhide F-12 introduces a GSocket that conflicts with wxGTK's GSocket class (gsocket.h): as a work-around, include less glib headers boinc-client-6.6.37-1.r18631svn.fc12 ------------------------------------ * Sun Jul 19 2009 Milos Jakubicek - 6.6.37-1.r18631svn - Update to 6.6 branch - Removed boinc-locales.patch (merged upstream) - Added boinc-macbuild.patch to fix ppc/ppc64 build failure - Fixed typo in upstream bugtracker link * Thu May 14 2009 Milos Jakubicek - 6.4.7-11.r17542svn - Condrestart the service after package update. - Added R: initscripts (needed for /sbin/service), chkconfig R: moved to scriptlets. bzr-1.17-1.fc12 --------------- * Mon Jul 20 2009 Henrik Nordstrom - 1.17-1 - Upgade to 1.17 chntpw-0.99.6-10.fc12 --------------------- * Mon Jul 20 2009 Richard W.M. Jones - 0.99.6-10 - Three patches from Jim Meyering aiming to improve the general robustness of the code. coda-6.9.4-5.fc12 ----------------- * Mon Jul 20 2009 Neil Horman - 6.9.4-4 - Further changes to support compat-readline5 (bz 511305) * Mon Jul 20 2009 Neil Horman - 6.9.4-5 - Fix some sname stack overflows * Fri Jul 17 2009 Neil Horman - 6.9.4-3 - Change spec to require compat-readline5 (bz 511305) colordiff-1.0.9-1.fc12 ---------------------- * Tue Jul 21 2009 Ville Skytt? - 1.0.9-1 - Update to 1.0.9; wget 1.11, lzma and destdir patches applied upstream. - Patch cdiff for xz support. conky-1.7.1.1-2.fc12 -------------------- * Mon Jul 20 2009 Miroslav Lichvar - 1.7.1.1-2 - Rebuild for new audacious - Buildrequire libxml2-devel cronie-1.4-2.fc12 ----------------- * Mon Jul 20 2009 Marcela Ma?l??ov? - 1.4-2 - merge cronie and anacron in new release of cronie - obsolete/provide anacron in spec eclipse-pydev-1.4.7-2.fc12 -------------------------- * Mon Jul 20 2009 Alexander Kurtakov 1:1.4.7-2 - Require pylint to fix errors in pydev settings. emelfm2-0.6.2-1.fc12 -------------------- * Mon Jul 20 2009 Christoph Wickert - 0.6.2-1 - Update to 0.6.2 fslint-2.40-1.fc12 ------------------ * Tue Jul 21 2009 P?draig Brady

- 2.40-1 - Update to 2.40. Note this updates GTK+ and Python dependencies to 2.4 and 2.3 respectively (Fedora Core 2). garmindev-0.3.0-1.fc12 ---------------------- * Mon Jul 20 2009 Dan Hor?k 0.3.0-1 - update to version 0.3.0 gdm-2.27.4-2.fc12 ----------------- * Mon Jul 20 2009 Ray Strode 1:2.27.4-1 - Update to 2.27.4 * Mon Jul 20 2009 Ray Strode 1:2.27.4-2 - Use correct multi-stack patch gmime22-2.2.23-6.fc12 --------------------- * Mon Jul 20 2009 Bernard Johnson - 2.2.23-6 - don't autoreconf, use included configure gnome-python2-extras-2.25.3-7.fc12 ---------------------------------- * Mon Jul 20 2009 Jan Horak - 2.25.3-7 - Rebuild against newer gecko gnome-session-2.27.4-2.fc12 --------------------------- * Mon Jul 20 2009 Matthias Clasen - 2.27.4-2 - Require polkit-gnome, we need an authentication agent in the session gnome-web-photo-0.8-2.fc12 -------------------------- * Mon Jul 20 2009 Jan Horak - 0.8-2 - Rebuild against newer gecko gstreamer-0.10.23.3-1.fc12 -------------------------- * Tue Jul 21 2009 Bastien Nocera 0.10.23.3-1 - Update to 0.10.23.3 hugin-0.8.0-1.fc12 ------------------ * Fri Jul 17 2009 Bruno Postle 0.8.0-1 - 0.8.0 release iok-1.3.6-1.fc12 ---------------- * Mon Jul 20 2009 Parag Nemade - 1.3.6-1 - Update to Next release 1.3.6 - Add BR:intltool kazehakase-0.5.6-14.svn3773_trunk.fc12 -------------------------------------- * Tue Jul 21 2009 Mamoru Tasaka - 0.5.6-14.svn3773_trunk - Attempt to compile with GTK 2.17.5 kdebindings-4.2.96-4.fc12 ------------------------- * Mon Jul 20 2009 Than Ngo - 4.2.96-3 - fix build issue with php-5.3.x * Mon Jul 20 2009 Than Ngo - 4.2.96-4 - allow for build php-5.2.x kernel-2.6.31-0.81.rc3.git4.fc12 -------------------------------- * Mon Jul 20 2009 Dave Jones 2.6.31-0.77.rc3.git4 - Don't build 586 kernels any more. * Mon Jul 20 2009 Dave Jones 2.6.31-0.78.rc3.git4 - Enable CONFIG_RTC_HCTOSYS (#489494) * Mon Jul 20 2009 Adam Jackson - Revive 4k framebuffers for intel gen3 * Mon Jul 20 2009 Adam Jackson - Disable VGA arbiter patches for a moment krazy2-2.9-2.20090719svn.fc12 ----------------------------- * Mon Jul 20 2009 Ben Boeckel 2.9-1.20090719svn - Updated SVN - Conditionalize patch - Fix DESTDIR/PREFIX for doc - Remove %check section * Mon Jul 20 2009 Ben Boeckel 2.9-2.20090719svn - Fix %changelog - Fix CVS mistakes (update tarball) * Mon Mar 16 2009 Ben Boeckel 2.8-9.20090314svn - Updated SVN lftp-3.7.14-4.fc12 ------------------ * Mon Jul 20 2009 Adam Jackson 3.7.14-4 - Split utility scripts to subpackage to isolate perl dependency. (#510813) libXrandr-1.3.0-1.fc12 ---------------------- * Thu Jul 16 2009 Adam Jackson 1.3.0-1 - libXrandr 1.3.0 liberation-fonts-1.05.1.20090721-1.fc12 --------------------------------------- * Tue Jul 21 2009 Caius 'kaio' Chance - 1.05.1.20090721-1.fc12 - Fixed fontforge scripting of sfd -> ttf generation. - Checked existance of traditionat kern table in Sans and Serif. libgdata-0.4.0-1.fc12 --------------------- * Mon Jul 20 2009 Bastien Nocera 0.4.0-1 - Update to 0.4.0 libgweather-2.26.1-5.fc12 ------------------------- * Mon Jul 20 2009 Matthias Clasen 2.26.1-5 - Keep locations in gettext catalogs libhugetlbfs-2.5-2.fc12 ----------------------- * Mon Jul 20 2009 Eric Munson 2.5-2 - Update Group for -utils package to Applications/System libibmad-1.3.2-1.fc12 --------------------- * Mon Jul 20 2009 Doug Ledford - 1.3.2-1 - Update to latest upstream version - Require the same version of libibumad as our version libibumad-1.3.2-2.fc12 ---------------------- * Mon Jul 20 2009 Doug Ledford - 1.3.2-1 - Update to latest upstream version - Remove requirement on libibcommon since that library is no longer needed - Fix a problem with man page listing * Mon Jul 20 2009 Doug Ledford - 1.3.2-2 - Forgot to remove both instances of the libibcommon requires - Add build requires on glibc-static libsynce-0.14-1.fc12 -------------------- * Tue Jul 21 2009 Andreas Bierfert - 0.14-1 - version upgrade mingw32-nsis-2.45-1.fc12 ------------------------ * Tue Jul 21 2009 Kevin Kofler - 2.45-1 - Update to 2.45 (#512429) * Tue Jun 30 2009 Stu Tomlinson - 2.44-2 - Re-enable System.dll plugin, inline Microsoft assembler code was replaced in 2.42 (#509234) mkinitrd-6.0.92-1.fc12 ---------------------- * Mon Jul 20 2009 Jeremy Katz - 6.0.92-1 - Fix live image booting with udev creating /dev/mapper/control - Workaround to try to stop the live image dm backing images from showing up in devkit-disks (#495170) ocrad-0.18-1.fc12 ----------------- * Mon Jul 20 2009 Tomas Smetana 0.18-1 - new upstream version openbox-3.4.7.2-9.fc12 ---------------------- * Mon Jul 20 2009 Luke Macken - 3.4.7.2-8 - Require the gnome-menus package to get our xdg-menu dynamic pipe menu to work out of the box. opensm-3.3.2-1.fc12 ------------------- * Mon Jul 20 2009 Doug Ledford - 3.3.2-1 - Update to latest upstream version optipng-0.6.3-1.fc12 -------------------- * Sun Jul 19 2009 Ville Skytt? - 0.6.3-1 - Update to 0.6.3. - Use %global instead of %define. perl-Devel-StackTrace-1.22-1.fc12 --------------------------------- * Mon Jul 20 2009 Ralf Cors?pius - 1:1.22-1 - Upstream update. perl-File-Find-Rule-Perl-1.08-1.fc12 ------------------------------------ * Mon Jul 20 2009 Ralf Cors?pius - 1.08-1 - Upstream update. perl-Gtk2-MozEmbed-0.08-6.fc12.3 -------------------------------- * Mon Jul 20 2009 Jan Horak - 0.08-6.2 - Rebuild against newer gecko * Mon Jul 20 2009 Remi Collet - 0.08-6.3 - fix BR perl-HTTP-Server-Simple-Mason-0.12-1.fc12 ----------------------------------------- * Mon Jul 20 2009 Ralf Cors?pius - 0.12-1 - Upstream update. perl-PDL-2.4.4_05-1.fc12 ------------------------ * Wed Jul 15 2009 Orion Poplawski - 2.4.4_05-1 - Update to 2.4.4_05 and PDL-Graphics-PLplot-0.50 - Drop test patch, no longer needed perl-TAP-Harness-JUnit-0.32-2.fc12 ---------------------------------- * Mon Jul 20 2009 Lubomir Rintel (Good Data) 0.32-2 - Apply the ASCII patch, disable test perl-Test-ClassAPI-1.06-1.fc12 ------------------------------ * Mon Jul 20 2009 Ralf Cors?pius - 1.06-1 - Upstream update. perl-Test-HTTP-Server-Simple-StashWarnings-0.04-1.fc12 ------------------------------------------------------ * Mon Jul 20 2009 Ralf Cors?pius corsepiu at fedoraproject.org> - 0.04-1 - Upstream update. - Change Source0-URL to reflect upstream maintainer change. - Disallow testsuite to fail. perl-Test-Inline-2.211-1.fc12 ----------------------------- * Mon Jul 20 2009 Ralf Cors?pius - 2.211-1 - Upstream update. perl-Test-MinimumVersion-0.011-1.fc12 ------------------------------------- * Mon Jul 20 2009 Ralf Cors?pius - 0.011-1 - Upstream update. php-ZendFramework-1.8.4-2.PL1.fc12 ---------------------------------- * Mon Jul 20 2009 Alexander Kahl - 1.8.4-2.PL1 - removed Fileinfo dependency - don't make zf.sh symlink absolute (breaks the script) polkit-0.93-2.fc12 ------------------ * Mon Jul 20 2009 David Zeuthen - 0.93-1 - Update to 0.93 * Mon Jul 20 2009 David Zeuthen - 0.93-2 - Rebuild polkit-gnome-0.93-2.fc12 ------------------------ * Mon Jul 20 2009 David Zeuthen - 0.93-1 - Update to 0.93 * Mon Jul 20 2009 David Zeuthen - 0.93-2 - Rebuild portecle-1.4-3.fc12 ------------------- * Mon Jul 20 2009 Ville Skytt? - 1.4-3 - Drop excess arguments to %jpackage_script. pygoocanvas-0.14.0-2.fc12 ------------------------- * Mon Jul 20 2009 Bernard Johnson - 0.14.0-2 - add patch to fix upstream API breakage (bz #511658) * Thu Jun 25 2009 Denis Leroy - 0.14.0-1 - Update to upstream 0.14.0, as part of general goocanvas update python-basemap-0.99.2-4.fc12 ---------------------------- * Mon Jul 20 2009 Caol?n McNamara - 0.99.2-4 - Resolves: rhbz#511576 FTBFS showimg numpy -> numpy-f2py python-clientform-0.2.7-5.fc12 ------------------------------ * Mon Jul 20 2009 Luke Macken - 0.2.7-5 - Remove duplicate README html file (#480678) python-repoze-who-plugins-sa-1.0-0.3.rc1.fc12 --------------------------------------------- * Mon Jul 20 2009 Luke Macken - 1.0-0.3.rc1 - Remove the test suite, since it conflicts with other packages (#512759) qlandkartegt-0.14.1-1.fc12 -------------------------- * Mon Jul 20 2009 Dan Horak 0.14.1-1 - update to 0.14.1 - add workaround for #498111 rpm-4.7.0-9.fc12 ---------------- * Mon Jul 20 2009 Bill Nottingham - 4.7.0-9 - enable XZ support rubygem-activeldap-1.1.0-1.fc12 ------------------------------- * Mon Jul 20 2009 Darryl Pierce - 1.1.0-1 - Release 1.1.0 of ActiveLdap. - Dependency on rubygem-hoe changed to 2.3.2. - Dependency on rubygem-activerecord changed to 2.3.2. - Dependency on rubygem-locale added. - Dependency on rubygem-gettext added. - Dependency on rubygem-gettext_activerecord added. sdcc-2.9.0-3.fc12 ----------------- * Mon Jul 20 2009 Conrad Meyer - 2.9.0-3 - Fix double-free (rhbz# 509278) with patch from upstream. sos-1.8-13.fc12 --------------- * Mon Jul 20 2009 Adam Stokes = 1.8-13 - Add requirements for tar,bzip2 during minimal installs - More merges from reports against RHEL version of plugins - Remove unecessary definition of localdir in spec squeak-vm-3.10.5-1.fc12 ----------------------- * Mon Jul 20 2009 Gavin Romig-Koch - 3.10.5-1 - upgrade to new upstream - work around dprintf problem - UUID lib now in libuuid-devel (moved from e2fsprogs-devel) sysstat-9.0.4-1.fc12 -------------------- * Mon Jul 20 2009 Ivana Varekova - 9.0.4-1 - update to 9.0.4 tcsh-6.17-1.fc12 ---------------- * Mon Jul 20 2009 Vitezslav Crhonek - 6.17-1 - Update to tcsh-6.17.00 trac-mercurial-plugin-0.11.0.7-5.20090715svn8072.fc12 ----------------------------------------------------- * Mon Jul 20 2009 Jesse Keating - 0.11.0.7-5.20090715svn8072 - Patch for hg 1.3 tzdata-2009k-1.fc12 ------------------- * Mon Jul 20 2009 Petr Machata - 2009k-1 - Upstream 2009k - Mauritius will not continue to observe DST the coming summer - Arbitrarily end DST at the end of 2009 so that a POSIX-sytle time zone string can appear in the Dhaka binary file unshield-0.6-1.fc12 ------------------- * Tue Jul 21 2009 Andreas Bierfert - 0.6 - version upgrade valide-0.5.1-0.14.20090720svn291.fc12 ------------------------------------- * Mon Jul 20 2009 Jonathan MERCIER 0.5.1-0.14.20090720svn291 - Update valide to revision 291 xmp-2.5.1-7.fc12 ---------------- * Mon Jul 20 2009 Michael Schwendt - 2.5.1-7 - patch further for Audacious 2, because the bmp_cfg_* symbols are gone since Audacious 1.5 already xorg-x11-xdm-1.1.6-12.fc12 -------------------------- * Mon Jul 20 2009 Adam Jackson 1.1.6-12 - Fix FTBFS due to Xaw xprint build macro disappearing. (#511508) * Wed Jul 15 2009 Adam Jackson 1.1.6-11 - Remove xserver PAM config file, it belongs (unsurprisingly) in xserver. (#500469) xorg-x11-xsm-1.0.2-10.fc12 -------------------------- * Mon Jul 20 2009 Adam Jackson 1.0.2-10 - Fix FTBFS due to Xaw xprint macro disappearing. (#511614) xsane-0.996-8.fc12 ------------------ * Mon Jul 20 2009 Nils Philippsen 0.996-8 - don't use obsolete SANE_CAP_ALWAYS_SETTABLE macro (#507823) * Tue Jul 07 2009 Tom "spot" Callaway 0.996-7 - don't own %{_datadir}/applications/ (filesystem package owns it) * Fri May 29 2009 Nils Philippsen - Merge review (#226658): - convert documentation files to UTF-8 - don't BR: sed - don't own /usr/share/applications, /etc/gimp, /etc/gimp/plugins.d - don't package unnecessary documentation z88dk-1.9-1.fc12 ---------------- * Tue Jul 21 2009 Kevin Kofler - 1.9-1 - update to 1.9 (#512391) - update 64bit patch (one issue fixed upstream, many left) zsh-4.3.10-2.fc12 ----------------- * Mon Jul 20 2009 James Antill - 4.3.10-1 - Import new upstream 4.3.10 * Wed Jun 10 2009 Karsten Hopp 4.3.9-4.1 - skip D02glob test on s390, too Summary: Added Packages: 6 Removed Packages: 1 Modified Packages: 79 Broken deps for i386 ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin R-RScaLAPACK-0.5.1-19.fc11.i586 requires openmpi-libs clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.i586 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.i586 requires gauche = 0:0.8.13 gedit-vala-0.4.1-2.fc11.i586 requires libgtksourcecompletion-1.0.so.1 libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.i586 requires xulrunner = 0:1.9.1 perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) php-idn-1.2-5.fc12.i586 requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.i386 requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.i386 requires python(abi) = 0:2.5 qtparted-0.4.5-19.fc11.i586 requires libparted-1.8.so.8 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.i586 requires libpqxx-2.6.8.so thunderbird-lightning-1.0-0.6.20090513hg.fc12.i586 requires thunderbird < 0:3.0-2.3.b4 totem-youtube-2.27.1-2.fc12.i586 requires libgdata.so.4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 Broken deps for x86_64 ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin R-RScaLAPACK-0.5.1-19.fc11.x86_64 requires openmpi-libs clutter-cairo-0.8.2-3.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.x86_64 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.x86_64 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.x86_64 requires gauche = 0:0.8.13 gedit-vala-0.4.1-2.fc11.x86_64 requires libgtksourcecompletion-1.0.so.1()(64bit) libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.x86_64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 libprojectM-1.2.0-9.fc11.x86_64 requires libftgl.so.0()(64bit) pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.x86_64 requires xulrunner = 0:1.9.1 perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) php-idn-1.2-5.fc12.x86_64 requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires python(abi) = 0:2.5 qtparted-0.4.5-19.fc11.x86_64 requires libparted-1.8.so.8()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.x86_64 requires libpqxx-2.6.8.so()(64bit) thunderbird-lightning-1.0-0.6.20090513hg.fc12.x86_64 requires thunderbird < 0:3.0-2.3.b4 totem-youtube-2.27.1-2.fc12.x86_64 requires libgdata.so.4()(64bit) trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 Broken deps for ppc ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin R-RScaLAPACK-0.5.1-19.fc11.ppc requires openmpi-libs clutter-cairo-0.8.2-3.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.ppc requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.ppc requires gauche = 0:0.8.13 gedit-vala-0.4.1-2.fc11.ppc requires libgtksourcecompletion-1.0.so.1 libchamplain-0.2.9-1.fc11.ppc requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc requires libftgl.so.0 libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.ppc requires xulrunner = 0:1.9.1 perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) php-idn-1.2-5.fc12.ppc requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gst-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.ppc requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.ppc requires python(abi) = 0:2.5 qtparted-0.4.5-19.fc11.ppc requires libparted-1.8.so.8 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc requires libpqxx-2.6.8.so thunderbird-lightning-1.0-0.6.20090513hg.fc12.ppc requires thunderbird < 0:3.0-2.3.b4 totem-youtube-2.27.1-2.fc12.ppc requires libgdata.so.4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 Broken deps for ppc64 ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin R-RScaLAPACK-0.5.1-19.fc11.ppc64 requires openmpi-libs clutter-cairo-0.8.2-3.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairo-devel-0.8.2-3.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) gedit-vala-0.4.1-2.fc11.ppc64 requires libgtksourcecompletion-1.0.so.1()(64bit) libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.ppc64 requires xulrunner = 0:1.9.1 perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) php-idn-1.2-5.fc12.ppc64 requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires python(abi) = 0:2.5 python-mwlib-0.11.2-2.20090522hg2956.fc12.ppc64 requires LabPlot qtparted-0.4.5-19.fc11.ppc64 requires libparted-1.8.so.8()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc64 requires libpqxx-2.6.8.so()(64bit) thunderbird-lightning-1.0-0.6.20090513hg.fc12.ppc64 requires thunderbird < 0:3.0-2.3.b4 totem-youtube-2.27.1-2.fc12.ppc64 requires libgdata.so.4()(64bit) trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 From Jochen at herr-schmitt.de Tue Jul 21 15:33:54 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 21 Jul 2009 17:33:54 +0200 Subject: Need help about XEmacs packaging Message-ID: <4A65DFE2.70807@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo, I have a package with a xemacs lisp file which refer to lpr-command. If I try to compile this file, I will get an error message that the symbol's value may be void. So I want to ask for the best practice to fix this issue. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpl39gACgkQT2AHK6txfgxrdACgt+0w2wnwq5UbB0cK1m+RsYHS fv0An2O7Wzbgmxq/maREC6uC3v2HoJkS =aFaU -----END PGP SIGNATURE----- From bruno at wolff.to Tue Jul 21 15:54:59 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 21 Jul 2009 10:54:59 -0500 Subject: Fit and Finish test day: batteries and suspend In-Reply-To: <20090721124620.GH1753@localhost.localdomain> References: <1247849443.1614.8.camel@planemask> <1248145858.6202.19.camel@moose.localdomain> <20090721124620.GH1753@localhost.localdomain> Message-ID: <20090721155459.GB18726@wolff.to> On Tue, Jul 21, 2009 at 08:46:20 -0400, "Paul W. Frields" wrote: > On Tue, Jul 21, 2009 at 01:10:58PM +1000, Rodd Clarkson wrote: > > I'd really like to join in with this having experienced issues with > > suspend/resume with: > > > > * Dell Inspiron 9300 (using nvidia driver as nouveau/nv don't support > > suspend/resume) > > * Dell Studion XPS 16 (using either radeon or radionhd as the catalyst > > driver won't compile on kernel 2.6.29) > > * EeePC 1000 series with the 160GB HDD (using the default x driver) > > > > However, I'm a little confused how to build myself a livecd with rawhide > > on is and to be honest, I don't have the time to figure it out (as it > > appears it's going to take some investigation). > > I wrote this a while ago and finally moved it to a better name where > more people could find it: > > https://fedoraproject.org/wiki/How_to_build_a_Rawhide_ISO_image_for_testing Doesn't that cover just install images? I didn't think pungi could create live images (maybe I am wrong)? I would have expected a mention of either livecd-creator or revisor in instructions for creating live images. Also I no longer edit installed kickstarts (from spin-kickstarts) and prefer to use a kickstart file that includes the base kickstart file I want to use (or test) and add overrides of repos (you may need a dummy repo when overriding two repos and only using rawhide) and do whatever other minor changes I want. This keeps the installed stuff pristine and keeps my changes in one place. From braden at endoframe.com Tue Jul 21 16:06:14 2009 From: braden at endoframe.com (Braden McDaniel) Date: Tue, 21 Jul 2009 12:06:14 -0400 Subject: Purging the F12 orphans In-Reply-To: <1248145892.25689.15.camel@localhost.localdomain> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> <1248126237.25689.12.camel@localhost.localdomain> <1248145892.25689.15.camel@localhost.localdomain> Message-ID: <1248192374.4653.8682.camel@localhost> On Mon, 2009-07-20 at 20:11 -0700, Jesse Keating wrote: [snip] > Orphan: pcmanx-gtk2 > gnash-plugin requires /usr/lib/mozilla/plugins > gnome-chemistry-utils-mozplugin requires /usr/lib/mozilla/plugins > java-1.6.0-openjdk-plugin requires /usr/lib/mozilla/plugins > mozilla-opensc-signer requires /usr/lib/mozilla/plugins > swfdec-mozilla requires /usr/lib/mozilla/plugins Umm.... What??? Sigh. pcmanx-gtk2.spec includes: # We need to own this dir, because we don't want to Requires: firefox %{_libdir}/mozilla/plugins/ I think not. The package already "Requires: xulrunner"; which requires mozilla-filesystem, which is what owns %{_libdir}/mozilla/plugins. (Not that owning this directory is reasonably even if it didn't already have this dependency.) -- Braden McDaniel From mcepl at redhat.com Tue Jul 21 16:23:49 2009 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 21 Jul 2009 16:23:49 +0000 (UTC) Subject: Purging the F12 orphans References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> <1248126237.25689.12.camel@localhost.localdomain> <1248145892.25689.15.camel@localhost.localdomain> <20090721104207.GA22143@killefiz> Message-ID: Sven Lankes, Tue, 21 Jul 2009 12:42:07 +0200: > qt-qsa is the 'old' variant. The package containing the current code is > "qca2" and that is still maintained. Cool. I suspected I am out-of-date. Mat?j From jreznik at redhat.com Tue Jul 21 16:34:35 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Tue, 21 Jul 2009 18:34:35 +0200 Subject: KDE-SIG weekly report (30/2009) Message-ID: <200907211834.36074.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: 30/2009 Time: 2009-07-21 14:00 UTC NEW MEETING TIME! Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-07-21 Meeting minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-21/fedora- meeting.2009-07-21-14.10.html Full log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-21/fedora- meeting.2009-07-21-14.10.log.html ---------------------------------------------------------------------------------- = Participants = * JaroslavReznik * KevinKofler * LukasTinkl * RexDieter * ThanNgo * StevenParrish * Thomas Janssen ---------------------------------------------------------------------------------- = Agenda = topics to discuss: * should we support old artwork + fedora system logo * defining @critical-path-kde group (task delegated to the SIG for each spin by FESCo) = Summary = should we support old artwork + fedora system logo * should we ship old artwork? o most of KDE SIG members voted yes if it's not broken o we need testers * problem with fedora system logo o should we use system-logo-white or our own system-logo-kde? o install it to /usr/share/pixmaps o what about generic logo? * jreznik will ask design team and start mailing list thread (this one? :D) defining @critical-path-kde group (task delegated to the SIG for each spin by FESCo) * KDM into @critical-path-kde * do we want to be involved? o or we want our own testing? * who will be responsible for QA? * KevinKofler will check it... = Tasks = 1. jreznik checks logos with Design team 2. KevinKofler asks on fedora-devel about critical paths = Links = ---------------------------------------------------------------------------------- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-07-28 -- Jaroslav ?ezn?k Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ From bruno at wolff.to Tue Jul 21 16:37:39 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 21 Jul 2009 11:37:39 -0500 Subject: How to RPM'ify Perl Modules In-Reply-To: <8204a4fe0907210629v291fbfbla8992a7442b3f61f@mail.gmail.com> References: <8204a4fe0907210621v4994548dv341dece48433ebb8@mail.gmail.com> <8204a4fe0907210629v291fbfbla8992a7442b3f61f@mail.gmail.com> Message-ID: <20090721163739.GB25595@wolff.to> On Tue, Jul 21, 2009 at 09:29:46 -0400, Fulko Hew wrote: > I'd like to create an RPM (spec file) to package my Perl based product so that > its easy to distribute and easy to add to a Fedora kickstart file, but > I'm not too sure > where to start. I've looked around and found cpan2rpm and rpmpan, but I'd > like to know what the 'official' approach is for Fedora. > > Can anyone point me in the right direction? Have you read: https://fedoraproject.org/wiki/Packaging:Perl From nando at ccrma.Stanford.EDU Tue Jul 21 16:48:32 2009 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Tue, 21 Jul 2009 09:48:32 -0700 Subject: midi seq interface vs. fc11: #505421 Message-ID: <1248194912.5887.50.camel@localhost.localdomain> Hi... anyone out there could help with the bugzilla bug 505421?? Filed on 2009-06-11, no answers of substance yet and no workaround suggested. Should be easy, a module is not being loaded on demand, it was before. I keep getting questions about this on the Planet CCRMA list, it makes midi unusable for a normal user, anyone installing fc11 for audio _will_ stumble into this problem. It was working, it is broken, please fix it! -- Fernando From tmz at pobox.com Tue Jul 21 17:09:59 2009 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 21 Jul 2009 13:09:59 -0400 Subject: Any asciidoc users? In-Reply-To: <1247704867.3572.3.camel@clockmaker.usersys.redhat.com> References: <20090715140107.GQ19992@inocybe.localdomain> <1247704867.3572.3.camel@clockmaker.usersys.redhat.com> Message-ID: <20090721170959.GE4338@inocybe.localdomain> Dave Airlie wrote: > just apply the --unsafe as default patch I suppose, I'm not sure its > actually a useful feature, I created an 'unsafe' mode by default patch and sent it upstream, as well as noted it in the bug report. I'll go apply for privileges to asciidoc so I can apply this, if no one notices any glaring problems with the changes in the next day or so. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Not only is life a bitch, it has puppies. -- Adrienne E. Gusoff -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From cassmodiah at fedoraproject.org Tue Jul 21 17:25:44 2009 From: cassmodiah at fedoraproject.org (Simon Wesp) Date: Tue, 21 Jul 2009 19:25:44 +0200 Subject: gnaughty is a hot babe In-Reply-To: <20090528130643.50677d14@schafwiese> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> Message-ID: <20090721192544.1e9676fc@schafwiese> Am Donnerstag, 28 Mai 2009 13:06:43 schrieb Simon Wesp: SW> I created a review with the FE-LEGAL blocker, because I didn't see this SW> email. Lifted FE-Legal! https://bugzilla.redhat.com/show_bug.cgi?id=503013 -- Mit freundlichen Gr??en aus dem sch?nen Hainzell Simon Wesp The G in GNU stands for GNU http://fedoraproject.org/wiki/SimonWesp From tcallawa at redhat.com Tue Jul 21 17:35:08 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 21 Jul 2009 13:35:08 -0400 Subject: Purging the F12 orphans In-Reply-To: <1248192374.4653.8682.camel@localhost> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> <1248126237.25689.12.camel@localhost.localdomain> <1248145892.25689.15.camel@localhost.localdomain> <1248192374.4653.8682.camel@localhost> Message-ID: <4A65FC4C.2000401@redhat.com> On 07/21/2009 12:06 PM, Braden McDaniel wrote: > On Mon, 2009-07-20 at 20:11 -0700, Jesse Keating wrote: > > [snip] > >> Orphan: pcmanx-gtk2 >> gnash-plugin requires /usr/lib/mozilla/plugins >> gnome-chemistry-utils-mozplugin requires /usr/lib/mozilla/plugins >> java-1.6.0-openjdk-plugin requires /usr/lib/mozilla/plugins >> mozilla-opensc-signer requires /usr/lib/mozilla/plugins >> swfdec-mozilla requires /usr/lib/mozilla/plugins > > Umm.... What??? > > Sigh. pcmanx-gtk2.spec includes: > > # We need to own this dir, because we don't want to Requires: firefox > %{_libdir}/mozilla/plugins/ > > I think not. > > The package already "Requires: xulrunner"; which requires > mozilla-filesystem, which is what owns %{_libdir}/mozilla/plugins. Yeah, that predates mozilla-filesystem. pcmanx-gtk2 is safe to die if no one wants it (although, having a telnet client plugin for firefox is somewhat cool). ~spot From ville.skytta at iki.fi Tue Jul 21 17:48:51 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-15?q?Skytt=E4?=) Date: Tue, 21 Jul 2009 20:48:51 +0300 Subject: Need help about XEmacs packaging In-Reply-To: <4A65DFE2.70807@herr-schmitt.de> References: <4A65DFE2.70807@herr-schmitt.de> Message-ID: <200907212048.56535.ville.skytta@iki.fi> On Tuesday 21 July 2009, Jochen Schmitt wrote: > Hallo, > > I have a package with a xemacs lisp file which refer to lpr-command. > > If I try to compile this file, I will get an error message that the > symbol's value may be void. As far as I can tell, lpr-command is a customizable variable defined in the ps-print lisp package which is part of the xemacs-packages-extra package in Fedora. > So I want to ask for the best practice to fix this issue. Is it really an error or just a warning? If a warning, it's possibly a harmless one. Anyway, try adding xemacs-packages-extra as a build dependency and if the thing invoking lpr-command _really_ needs it to be available when your package is installed, add a Requires on xemacs-packages-extra too. From mw_triad at users.sourceforge.net Tue Jul 21 18:27:11 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Tue, 21 Jul 2009 13:27:11 -0500 Subject: Purging the F12 orphans In-Reply-To: <1248145892.25689.15.camel@localhost.localdomain> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> <1248126237.25689.12.camel@localhost.localdomain> <1248145892.25689.15.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > List of deps left behind by orphan removal: > > Orphan: jline > lucene requires jline = 0.9.94-0.3.fc11 ...which is required by OpenOffice.org. That's going to be a problem... except that F11 lucene doesn't need jline. > Orphan: libatomic_ops > pulseaudio requires libatomic_ops-devel = 1.2-6.fc12 Obviously, this is also a problem, except that again F11 has no such dependency. Are these really both different in rawhide? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "NT was a marketing name that stood for New Technology, but it was still an amusing coincidence that WNT was VMS with each letter replaced by the next one." -- Jeremy Reimer From jgarzik at pobox.com Tue Jul 21 19:13:15 2009 From: jgarzik at pobox.com (Jeff Garzik) Date: Tue, 21 Jul 2009 15:13:15 -0400 Subject: koji buildroot inconsistencies? chain-build does not fix... Message-ID: <4A66134B.5000302@pobox.com> Fighting against in-buildroot-or-not? dependencies ;-) I have three packages, cld depends: none chunkd depends: cld tabled depends: cld chunkd 1) I updated all three packages in cvs devel (rawhide), and tagged them. 2) 'make build' on cld succeeded http://koji.fedoraproject.org/koji/taskinfo?taskID=1490075 3) Waited 45 minutes. 4) 'make build' on chunkd failed, because it was building against an outdated cld package. http://koji.fedoraproject.org/koji/taskinfo?taskID=1490259 5) So, I try chain-build, which is supposed to get dependencies right: $ cd /spare/repo/fedora/tabled/devel # Fedora CVS for tabled $ make chain-build CHAIN='cld : chunkd :' this fails, because cld is already built (step #2). http://koji.fedoraproject.org/koji/taskinfo?taskID=1490341 6) So, ok, I try chain-build without cld, since koji tells me it is already built: $ make chain-build CHAIN='chunkd :' this fails, for the same reason as step #4 -- outdated cld. http://koji.fedoraproject.org/koji/taskinfo?taskID=1490371 If I build assuming up-to-date cld is in rawhide, it fails. If I build NOT assuming up-to-date cld in rawhide, it fails. How to fix this paradox? I guess this is punishment for not using chain-build from the beginning... Jeff From ian at ianweller.org Tue Jul 21 19:16:07 2009 From: ian at ianweller.org (Ian Weller) Date: Tue, 21 Jul 2009 15:16:07 -0400 Subject: koji buildroot inconsistencies? chain-build does not fix... In-Reply-To: <4A66134B.5000302@pobox.com> References: <4A66134B.5000302@pobox.com> Message-ID: <20090721191607.GE2915@hovercraft.mobile.ianweller.org> On Tue, Jul 21, 2009 at 03:13:15PM -0400, Jeff Garzik wrote: > How to fix this paradox? > Just bump the release, recommit and retag. -- 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 edwin at tenbrink-bekkers.nl Tue Jul 21 19:25:57 2009 From: edwin at tenbrink-bekkers.nl (Edwin ten Brink) Date: Tue, 21 Jul 2009 21:25:57 +0200 Subject: Red Hat Bugzilla Front Page query "In Progress" broken Message-ID: <4A661645.5020203@tenbrink-bekkers.nl> I'm not sure where to file this bug against Red Hat Bugzilla. On my Red Hat Bugzilla Front Page, under "Open Issues: In Progress Reported by You", no bugs appear even though there should be one in progress. It seems that the query generating the list is broken. The link for "show list" starts with: https://bugzilla.redhat.com/buglist.cgi?bug_status=&bug_status=1&bug_status=1&bug_status=1&bug_status=1&bug_status=1&bug_status=1&bug_status=1&bug_status=1&bug_status=1&bug_status=1 ... which does not feel entirely correct. Could somebody please fix this, or tell me where to file this bug? Regards, Edwin From martind1111 at gmail.com Tue Jul 21 19:31:25 2009 From: martind1111 at gmail.com (Martin Dubuc) Date: Tue, 21 Jul 2009 15:31:25 -0400 Subject: Building boost-1.39.0-3.fc12.src.rpm on Fedora11 Message-ID: <7a0107ba0907211231l1b1a7844je2b8e423cdfde705@mail.gmail.com> I was successful building boost 1.39.0 from rawhide source RPM (using boost-1.39.0-3.fc12.src.rpm) for RHEL 5.3. Now, I need to compile the same package on a Fedora 11 server but I am getting some build error in the process: # rpm -ivh boost-1.39.0-3.fc12.src.rpm # cd /root/rpmbuild/SPECS # rpmbuild -bb boost.spec ... cp "bin.v2/libs/iostreams/build/gcc-4.4.0/release/debug-symbols-on/threading-multi/libboost_iostreams-mt.so" "stage/lib/libboost_iostreams-mt.so" ...failed updating 1 target... ...skipped 3 targets... ...updated 1424 targets... error: Bad exit status from /var/tmp/rpm-tmp.nuiY8Y (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.nuiY8Y (%build) I am wondering if there is an known incompatibility between the rawhide version of boost and Fedora 11. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis at ausil.us Tue Jul 21 19:34:17 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 21 Jul 2009 14:34:17 -0500 Subject: koji buildroot inconsistencies? chain-build does not fix... In-Reply-To: <20090721191607.GE2915@hovercraft.mobile.ianweller.org> References: <4A66134B.5000302@pobox.com> <20090721191607.GE2915@hovercraft.mobile.ianweller.org> Message-ID: <200907211434.19273.dennis@ausil.us> On Tuesday 21 July 2009 02:16:07 pm Ian Weller wrote: > On Tue, Jul 21, 2009 at 03:13:15PM -0400, Jeff Garzik wrote: > > How to fix this paradox? > > Just bump the release, recommit and retag. ummmmmmmmmmm no you need to wait for a new repo you can do a koji wait repo then your chain build for the remain two packages. 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 ricky at fedoraproject.org Tue Jul 21 19:34:46 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Tue, 21 Jul 2009 15:34:46 -0400 Subject: Red Hat Bugzilla Front Page query "In Progress" broken In-Reply-To: <4A661645.5020203@tenbrink-bekkers.nl> References: <4A661645.5020203@tenbrink-bekkers.nl> Message-ID: <20090721193446.GB29823@alpha.rzhou.org> On 2009-07-21 09:25:57 PM, Edwin ten Brink wrote: > I'm not sure where to file this bug against Red Hat Bugzilla. > > On my Red Hat Bugzilla Front Page, under "Open Issues: In Progress > Reported by You", no bugs appear even though there should be one in > progress. It seems that the query generating the list is broken. > > The link for "show list" starts with: > https://bugzilla.redhat.com/buglist.cgi?bug_status=&bug_status=1&bug_status=1&bug_status=1&bug_status=1&bug_status=1&bug_status=1&bug_status=1&bug_status=1&bug_status=1&bug_status=1 > ... > which does not feel entirely correct. > > Could somebody please fix this, or tell me where to file this bug? There's a bugzilla product in bugzilla :-) Thanks, Ricky -------------- 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 Tue Jul 21 19:45:46 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 21 Jul 2009 21:45:46 +0200 Subject: koji buildroot inconsistencies? chain-build does not fix... In-Reply-To: <4A66134B.5000302@pobox.com> References: <4A66134B.5000302@pobox.com> Message-ID: <20090721214546.1a6fedc6@faldor> On Tue, 21 Jul 2009 15:13:15 -0400, Jeff wrote: > Fighting against in-buildroot-or-not? dependencies ;-) > > I have three packages, > cld depends: none > chunkd depends: cld > tabled depends: cld chunkd > > 1) I updated all three packages in cvs devel (rawhide), and tagged them. > > 2) 'make build' on cld succeeded > http://koji.fedoraproject.org/koji/taskinfo?taskID=1490075 > > 3) Waited 45 minutes. Randomly chosen 45 minutes or did it just take 45 minutes for the newrepo tasks to include the new cld? $ koji wait-repo --target dist-f12 --build cld-0.2-0.3.gc5b5f962.fc12 Successfully waited 0:02 for cld-0.2-0.3.gc5b5f962.fc12 to appear in the dist-f12-build repo And since koji says the new cld is in the buildroot, if you resubmit your "chunkd" job now, it still fails? From edwin at tenbrink-bekkers.nl Tue Jul 21 20:11:34 2009 From: edwin at tenbrink-bekkers.nl (Edwin ten Brink) Date: Tue, 21 Jul 2009 22:11:34 +0200 Subject: Red Hat Bugzilla Front Page query "In Progress" broken In-Reply-To: <20090721193446.GB29823@alpha.rzhou.org> References: <4A661645.5020203@tenbrink-bekkers.nl> <20090721193446.GB29823@alpha.rzhou.org> Message-ID: <4A6620F6.6080200@tenbrink-bekkers.nl> On 07/21/2009 09:34 PM, Ricky Zhou wrote: > On 2009-07-21 09:25:57 PM, Edwin ten Brink wrote: > >> I'm not sure where to file this bug against Red Hat Bugzilla. >> >> On my Red Hat Bugzilla Front Page, under "Open Issues: In Progress >> Reported by You", no bugs appear even though there should be one in >> progress. It seems that the query generating the list is broken. >> > There's a bugzilla product in bugzilla :-) > Ok, thanks, let me rephrase: I'm not sure if it is the /product/ bugzilla as shipped with Fedora XX which has the bug, or the specific /configuration of Red Hat Bugzilla/, which might make a difference in where to report this. Regards, Edwin From jussilehtola at fedoraproject.org Tue Jul 21 20:14:16 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Tue, 21 Jul 2009 23:14:16 +0300 Subject: Building boost-1.39.0-3.fc12.src.rpm on Fedora11 In-Reply-To: <7a0107ba0907211231l1b1a7844je2b8e423cdfde705@mail.gmail.com> References: <7a0107ba0907211231l1b1a7844je2b8e423cdfde705@mail.gmail.com> Message-ID: <1248207256.16465.4.camel@hawking.theorphys.helsinki.fi> On Tue, 2009-07-21 at 15:31 -0400, Martin Dubuc wrote: > I was successful building boost 1.39.0 from rawhide source RPM (using > boost-1.39.0-3.fc12.src.rpm) for RHEL 5.3. Now, I need to compile the > same package on a Fedora 11 server but I am getting some build error > in the process: > > # rpm -ivh boost-1.39.0-3.fc12.src.rpm > # cd /root/rpmbuild/SPECS > # rpmbuild -bb boost.spec DO NOT BUILD RPMS AS ROOT! EVER! For example, a single wrongly placed 'rm' in the spec file can botch your system. To build RPMS: Make sure the following packages are installed # yum -y install rpmdevtools redhat-rpm-macros Setup an rpm build tree in your homedir $ rpmdev-setuptree and build the rpm with $ rpmbuild --rebuild boost-1.39.0-3.fc12.src.rpm Or, even better, you can use mock. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From john5342 at googlemail.com Tue Jul 21 20:30:04 2009 From: john5342 at googlemail.com (John5342) Date: Tue, 21 Jul 2009 21:30:04 +0100 Subject: Red Hat Bugzilla Front Page query "In Progress" broken In-Reply-To: <4A6620F6.6080200@tenbrink-bekkers.nl> References: <4A661645.5020203@tenbrink-bekkers.nl> <20090721193446.GB29823@alpha.rzhou.org> <4A6620F6.6080200@tenbrink-bekkers.nl> Message-ID: <6dc6523c0907211330u2879f840jd0e264f864c3accb@mail.gmail.com> 2009/7/21 Edwin ten Brink : > On 07/21/2009 09:34 PM, Ricky Zhou wrote: >> >> On 2009-07-21 09:25:57 PM, Edwin ten Brink wrote: >> >>> >>> I'm not sure where to file this bug against Red Hat Bugzilla. >>> >>> On my Red Hat Bugzilla Front Page, under "Open Issues: In Progress >>> Reported by You", no bugs appear even though there should be one in >>> progress. It seems that the query generating the list is broken. >>> >> >> There's a bugzilla product in bugzilla :-) >> > > Ok, thanks, let me rephrase: I'm not sure if it is the /product/ bugzilla as > shipped with Fedora XX which has the bug, or the specific /configuration of > Red Hat Bugzilla/, which might make a difference in where to report this. In short if it is the bugzilla instance located at bugzilla.rehat.com then file it under the Bugzilla Product. If it is your own instance of bugzilla run using the bugzilla package installed on your system then file it under the Bugzilla Component within the Fedora Product -- There are 10 kinds of people in the world: Those who understand binary and those who don't... From ricky at fedoraproject.org Tue Jul 21 21:06:05 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Tue, 21 Jul 2009 17:06:05 -0400 Subject: Red Hat Bugzilla Front Page query "In Progress" broken In-Reply-To: <4A6620F6.6080200@tenbrink-bekkers.nl> References: <4A661645.5020203@tenbrink-bekkers.nl> <20090721193446.GB29823@alpha.rzhou.org> <4A6620F6.6080200@tenbrink-bekkers.nl> Message-ID: <20090721210605.GD29823@alpha.rzhou.org> On 2009-07-21 10:11:34 PM, Edwin ten Brink wrote: > On 07/21/2009 09:34 PM, Ricky Zhou wrote: >> On 2009-07-21 09:25:57 PM, Edwin ten Brink wrote: >> >>> I'm not sure where to file this bug against Red Hat Bugzilla. >>> >>> On my Red Hat Bugzilla Front Page, under "Open Issues: In Progress >>> Reported by You", no bugs appear even though there should be one in >>> progress. It seems that the query generating the list is broken. >>> >> There's a bugzilla product in bugzilla :-) >> > > Ok, thanks, let me rephrase: I'm not sure if it is the /product/ > bugzilla as shipped with Fedora XX which has the bug, or the specific > /configuration of Red Hat Bugzilla/, which might make a difference in > where to report this. Sorry if I was unclear, the Bugzilla product I was referring to is a product (just like the Fedora product) and that's where bugs go (see 507268 for an example of what I'm talking about). If it were an issue with the bugzilla package, you'd file it in the bugzilla component in the Fedora product :-) Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From christoph.wickert at googlemail.com Tue Jul 21 21:08:14 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Tue, 21 Jul 2009 23:08:14 +0200 Subject: Red Hat Bugzilla Front Page query "In Progress" broken In-Reply-To: <4A661645.5020203@tenbrink-bekkers.nl> References: <4A661645.5020203@tenbrink-bekkers.nl> Message-ID: <1248210494.3179.159.camel@localhost> Am Dienstag, den 21.07.2009, 21:25 +0200 schrieb Edwin ten Brink: > I'm not sure where to file this bug against Red Hat Bugzilla. > > On my Red Hat Bugzilla Front Page, under "Open Issues: In Progress > Reported by You", no bugs appear even though there should be one in > progress. It seems that the query generating the list is broken. > > The link for "show list" starts with: > https://bugzilla.redhat.com/buglist.cgi?bug_status=&bug_status=1&bug_status=1&bug_status=1&bug_status=1&bug_status=1&bug_status=1&bug_status=1&bug_status=1&bug_status=1&bug_status=1 > ... > which does not feel entirely correct. > > Could somebody please fix this, or tell me where to file this bug? Already being worked on: https://bugzilla.redhat.com/show_bug.cgi?id=512531 and https://bugzilla.redhat.com/show_bug.cgi?id=512381 Kind regards, Christoph From mjs at clemson.edu Tue Jul 21 21:08:05 2009 From: mjs at clemson.edu (Matthew Saltzman) Date: Tue, 21 Jul 2009 17:08:05 -0400 Subject: Sage in F11 In-Reply-To: <200907191419.50822.cemeyer@u.washington.edu> References: <1248037544.3613.113.camel@valkyrie.localdomain> <200907191419.50822.cemeyer@u.washington.edu> Message-ID: <1248210485.29135.322.camel@valkyrie.localdomain> On Sun, 2009-07-19 at 14:19 -0700, Conrad Meyer wrote: > On Sunday 19 July 2009 02:05:44 pm Matthew Saltzman wrote: > > Sorry to bother the -devel list with this, but nobody on fedora-list > > responded to my question, and I know there is some effort to package > > Sage for Fedora. I hope one of those packagers can help me out. > > > > I've installed sage-4.1 on F11 using the F10 binary installation > > tarball. But when I run sage, it fails with the following error: > > [...] > > "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/l > >ib/python/hashlib.py", line 63, in __get_builtin_constructor import _md5 > > ImportError: No module named _md5 > > > > I assume I'm missing a dependency, but what is it? Or is there something > > else going on? > > > > Sage worked fine in F10. This error occurred also with sage-4.0.2 in F11. > > > > TIA. > > $ rpm -qf /usr/lib64/python2.6/lib-dynload/_md5module.so > python-2.6-9.fc11.x86_64 > > I'm guessing the version of python shipped with Sage is missing the native md5 > module (which is in %{_libdir}/python2.6/lib-dynload/_md5module.so on F-11). Rebuilding from source in F11 seems to have mitigated the problem. You're right, though. There is no _md5module in the Sage Python libs. Thanks. > > Regards, -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From braden at endoframe.com Tue Jul 21 22:43:47 2009 From: braden at endoframe.com (Braden McDaniel) Date: Tue, 21 Jul 2009 18:43:47 -0400 Subject: NPAPI plug-in dependencies In-Reply-To: <4A65FC4C.2000401@redhat.com> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> <1248126237.25689.12.camel@localhost.localdomain> <1248145892.25689.15.camel@localhost.localdomain> <1248192374.4653.8682.camel@localhost> <4A65FC4C.2000401@redhat.com> Message-ID: <4A6644A3.70003@endoframe.com> On 7/21/09 1:35 PM, Tom "spot" Callaway wrote: > On 07/21/2009 12:06 PM, Braden McDaniel wrote: >> On Mon, 2009-07-20 at 20:11 -0700, Jesse Keating wrote: >> >> [snip] >> >>> Orphan: pcmanx-gtk2 >>> gnash-plugin requires /usr/lib/mozilla/plugins >>> gnome-chemistry-utils-mozplugin requires /usr/lib/mozilla/plugins >>> java-1.6.0-openjdk-plugin requires /usr/lib/mozilla/plugins >>> mozilla-opensc-signer requires /usr/lib/mozilla/plugins >>> swfdec-mozilla requires /usr/lib/mozilla/plugins >> Umm.... What??? >> >> Sigh. pcmanx-gtk2.spec includes: >> >> # We need to own this dir, because we don't want to Requires: firefox >> %{_libdir}/mozilla/plugins/ >> >> I think not. >> >> The package already "Requires: xulrunner"; which requires >> mozilla-filesystem, which is what owns %{_libdir}/mozilla/plugins. > > Yeah, that predates mozilla-filesystem. pcmanx-gtk2 is safe to die if no > one wants it (although, having a telnet client plugin for firefox is > somewhat cool). This does actually bring up a more general issue. webkitgtk doesn't depend on mozilla-filesystem; should it? NPAPI plug-ins ought to have a dependency that can be satisfied by any NPAPI container. Does Fedora need to define such a thing? -- Braden McDaniel e-mail: Jabber: From orion at cora.nwra.com Tue Jul 21 22:57:41 2009 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 21 Jul 2009 16:57:41 -0600 Subject: Purging the F12 orphans In-Reply-To: <20090721084835.GA22378@free.fr> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> <1248126237.25689.12.camel@localhost.localdomain> <1248145892.25689.15.camel@localhost.localdomain> <20090721084835.GA22378@free.fr> Message-ID: <4A6647E5.7020100@cora.nwra.com> On 07/21/2009 02:48 AM, Patrice Dumas wrote: > On Mon, Jul 20, 2009 at 08:11:32PM -0700, Jesse Keating wrote: >> List of deps left behind by orphan removal: > > bes, dap-*_handler and dap-server are associated and should either all > be owned or none. > >> Orphan: libdap >> Orphan: libnc-dap > > Somebody has to take those, they are a dependency of many packages. In the > future they will be included within netcdf, but it isn't the case right now. I'll take them all. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From jkeating at redhat.com Tue Jul 21 23:04:50 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 21 Jul 2009 16:04:50 -0700 Subject: No Frozen Rawhide Message-ID: <1248217490.2861.2.camel@localhost.localdomain> I've done some updating to the no frozen rawhide proposal[1]. There is still time to enact this for Fedora 12, which would take effect when we reach Alpha freeze in a couple weeks. I'd like another round of people reviewing it and giving feedback before we take it to FESCo. Thanks! [1]: https://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Tue Jul 21 23:18:59 2009 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 22 Jul 2009 01:18:59 +0200 Subject: Purging the F12 orphans In-Reply-To: <4A6647E5.7020100@cora.nwra.com> References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> <1248126237.25689.12.camel@localhost.localdomain> <1248145892.25689.15.camel@localhost.localdomain> <20090721084835.GA22378@free.fr> <4A6647E5.7020100@cora.nwra.com> Message-ID: <20090721231844.GA31321@free.fr> On Tue, Jul 21, 2009 at 04:57:41PM -0600, Orion Poplawski wrote: > > I'll take them all. Thanks! -- Pat From kevin.kofler at chello.at Wed Jul 22 01:08:36 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 22 Jul 2009 03:08:36 +0200 Subject: Critical Path Packages - Enforcement? Message-ID: Hi, I have a few questions for the folks involved with the Critical Path Packages proposal, as I'm still confused about the implementation details: 1. How will the policy be enforced? Will Bodhi withhold submitted updates for packages in the depsolving hull of @critical-path until they get approval from QA and/or rel-eng, like it currently does for security updates until security team approval? Assuming the answer to 1. is "Yes": 2. Will critical-path-gnome also get the same enforcement? 3. Will critical-path-kde also get the same enforcement? 4. Will critical-path-* for spins.fp.o spins also get the same enforcement? If the answer to any of the above (1. to 4.) is "No", what kind of enforcement will there be? When we discussed critical-path-kde today at KDE SIG, we were very much confused about what exactly the practical implications will be. I think it won't be of much use to define critical path packages if that definition doesn't lead to some actual enforcement. What we basically agreed on in KDE SIG (see also our meeting log [1]) was: * The KDE spin being one of the primary spins, critical-path-kde should get the same kind of enforcement as critical-path-gnome. (We have no official opinion about stuff like critical-path-xfce as that's out of the scope of our SIG.) * It doesn't make much sense for us to define critical path packages if it won't have any actual practical implications. (We already know what's critical to what extent, so a purely-informative critical-path-kde won't be of much use to us.) But we need the clarification I requested above to make any further decisions. Another open question is who is going to QA critical-path-kde, as we still don't have a dedicated tester in KDE SIG. Anybody volunteering to be a tester for KDE SIG is requested to talk to us on the #fedora-kde IRC chan and/or the fedora-kde mailing list. Being a tester has a much lower barrier to entry than most other forms of contribution, you just need some HD space to install test systems to (ideally, you'd have Rawhide, Fn and Fn-1 on at least one machine each, but even just testing one release is helpful) and some spare time. No programming, drawing, technical writing etc. skills required. I will post a call for help to the fedora-test-list as well. (Note that we do have a KDE SIG member in rel-eng (rdieter), so that part is covered.) Kevin Kofler [1] http://urlx.eu/_Mzk4MQ From debarshi.ray at gmail.com Wed Jul 22 04:25:40 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Wed, 22 Jul 2009 09:55:40 +0530 Subject: Gajim is now GPLv3 only Message-ID: <3170f42f0907212125o3acfddabg7ab093115b67318e@mail.gmail.com> Apologies for the belated notice. Gajim's license had been changed from GPLv2 to GPLv3 when Gajim 0.12 alpha1 was released. I have committed the change in CVS now which will be available with gajim-0.12.3-1. Cheers, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From hedayat at grad.com Wed Jul 22 05:40:27 2009 From: hedayat at grad.com (Hedayat Vatankhah) Date: Wed, 22 Jul 2009 10:10:27 +0430 Subject: Can anybody help me with this build issue? (related to pdflatex) In-Reply-To: <3668e9f50907192351o15160cb9qcf15a75c41d959f@mail.gmail.com> References: <4A640787.3050609@grad.com> <3668e9f50907192351o15160cb9qcf15a75c41d959f@mail.gmail.com> Message-ID: <4A66A64B.4060206@grad.com> Hi, Thanks a lot. Hedayat On 07/20/2009 11:21 AM, ? wrote: > Hi Hedayat Vatankhah > > https://bugzilla.redhat.com/show_bug.cgi?id=508522 > latex in rawhide is broken > > Greetings > Josephine > > 2009/7/20 Hedayat Vatankhah > > > Hi all, > Recently, one of my packages does not build against rawhide. Using > pdflatex to generate documentation fails in rawhide. I don't know > what's the problem specially that it seems that tex related > packages have not bean changed since Fedora 11. (I can > successfully build the package on an updated Fedora 11). > This is the build log: > https://bugzilla.redhat.com/attachment.cgi?id=353754 > > Thanks in Advance, > Hedayat > > -- > 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 philipp_subx at redfish-solutions.com Wed Jul 22 06:37:48 2009 From: philipp_subx at redfish-solutions.com (Philip A. Prindeville) Date: Tue, 21 Jul 2009 23:37:48 -0700 Subject: Need a sponsor: mod_proxy_html (apache) In-Reply-To: <4A60D611.9010501@redfish-solutions.com> References: <4A60D611.9010501@redfish-solutions.com> Message-ID: <4A66B3BC.90303@redfish-solutions.com> Philip A. Prindeville wrote: > Hi. > > I need a sponsor for this. An RPM has been built on several systems > (including FC8 and FC9 and Centos5) and tested on all of those. > > The ticket has been languishing now unassigned for almost a year. > > https://bugzilla.redhat.com/show_bug.cgi?id=452636 > > Can someone please pick this up? > > It's just an .src.rpm for Apache's mod_proxy_html. > > It's pretty trivial. > > Thanks, > > -Philip > > Wow. Who knew sponsors were that hard to come by? Especially when most of the work is already done... -Philip From yersinia.spiros at gmail.com Wed Jul 22 07:45:03 2009 From: yersinia.spiros at gmail.com (yersinia) Date: Wed, 22 Jul 2009 09:45:03 +0200 Subject: Need a sponsor: mod_proxy_html (apache) In-Reply-To: <4A66B3BC.90303@redfish-solutions.com> References: <4A60D611.9010501@redfish-solutions.com> <4A66B3BC.90303@redfish-solutions.com> Message-ID: > Wow. ?Who knew sponsors were that hard to come by? ?Especially when most > of the work is already done... FWIW, having I the need to use this module on Fedora and RHEL I have already included it in my RPM repository, and so I am using it in production without a problem. Regards From sundaram at fedoraproject.org Wed Jul 22 08:05:23 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 22 Jul 2009 13:35:23 +0530 Subject: rawhide report: 20090721 changes In-Reply-To: <20090721153008.GA24473@releng2.fedora.phx.redhat.com> References: <20090721153008.GA24473@releng2.fedora.phx.redhat.com> Message-ID: <4A66C843.40107@fedoraproject.org> On 07/21/2009 09:00 PM, Rawhide Report wrote: > Compose started at Tue Jul 21 06:15:03 UTC 2009 > > New package ghc-editline > Haskell %{pgk_name} library Obvious typo and it passed through review as well. Rahul From dan at danny.cz Wed Jul 22 08:11:15 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Wed, 22 Jul 2009 10:11:15 +0200 Subject: Purging the F12 orphans In-Reply-To: References: <1247589637.3073.1162.camel@localhost.localdomain> <1247594323.3073.1169.camel@localhost.localdomain> <1248126237.25689.12.camel@localhost.localdomain> <1248145892.25689.15.camel@localhost.localdomain> Message-ID: <1248250275.25339.75.camel@eagle.danny.cz> Matthew Woehlke p??e v ?t 21. 07. 2009 v 13:27 -0500: > Jesse Keating wrote: > > List of deps left behind by orphan removal: > > > > Orphan: libatomic_ops > > pulseaudio requires libatomic_ops-devel = 1.2-6.fc12 > > Obviously, this is also a problem, except that again F11 has no such > dependency. libatomic_ops will survive either as a standalone package or as a subpackage of the "gc" package. Process has been started. Dan From cemeyer at u.washington.edu Wed Jul 22 08:32:21 2009 From: cemeyer at u.washington.edu (Conrad Meyer) Date: Wed, 22 Jul 2009 01:32:21 -0700 Subject: rawhide report: 20090721 changes In-Reply-To: <4A66C843.40107@fedoraproject.org> References: <20090721153008.GA24473@releng2.fedora.phx.redhat.com> <4A66C843.40107@fedoraproject.org> Message-ID: <200907220132.22209.cemeyer@u.washington.edu> On Wednesday 22 July 2009 01:05:23 am Rahul Sundaram wrote: > On 07/21/2009 09:00 PM, Rawhide Report wrote: > > Compose started at Tue Jul 21 06:15:03 UTC 2009 > > > > New package ghc-editline > > Haskell %{pgk_name} library > > Obvious typo and it passed through review as well. > > Rahul I noticed this, but I don't think it's a typo. In the rpm it gets evaluated as "Haskell editline library", I imagine. -- Conrad Meyer From pbrobinson at gmail.com Wed Jul 22 08:35:34 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 22 Jul 2009 09:35:34 +0100 Subject: rawhide report: 20090721 changes In-Reply-To: <200907220132.22209.cemeyer@u.washington.edu> References: <20090721153008.GA24473@releng2.fedora.phx.redhat.com> <4A66C843.40107@fedoraproject.org> <200907220132.22209.cemeyer@u.washington.edu> Message-ID: <5256d0b0907220135y69628571tcf9e9b2e3b580234@mail.gmail.com> >> On 07/21/2009 09:00 PM, Rawhide Report wrote: >> > Compose started at Tue Jul 21 06:15:03 UTC 2009 >> > >> > New package ghc-editline >> > ? ? ? ? Haskell %{pgk_name} library >> >> Obvious typo and it passed through review as well. >> >> Rahul > > I noticed this, but I don't think it's a typo. In the rpm it gets evaluated as > "Haskell editline library", I imagine. I think he means pgk should read pkg, or maybe even just use the standard rpm %{name} variable. Peter From cemeyer at u.washington.edu Wed Jul 22 08:42:55 2009 From: cemeyer at u.washington.edu (Conrad Meyer) Date: Wed, 22 Jul 2009 01:42:55 -0700 Subject: rawhide report: 20090721 changes In-Reply-To: <5256d0b0907220135y69628571tcf9e9b2e3b580234@mail.gmail.com> References: <20090721153008.GA24473@releng2.fedora.phx.redhat.com> <200907220132.22209.cemeyer@u.washington.edu> <5256d0b0907220135y69628571tcf9e9b2e3b580234@mail.gmail.com> Message-ID: <200907220142.55379.cemeyer@u.washington.edu> On Wednesday 22 July 2009 01:35:34 am Peter Robinson wrote: > >> On 07/21/2009 09:00 PM, Rawhide Report wrote: > >> > Compose started at Tue Jul 21 06:15:03 UTC 2009 > >> > > >> > New package ghc-editline > >> > Haskell %{pgk_name} library > >> > >> Obvious typo and it passed through review as well. > >> > >> Rahul > > > > I noticed this, but I don't think it's a typo. In the rpm it gets > > evaluated as "Haskell editline library", I imagine. > > I think he means pgk should read pkg, or maybe even just use the > standard rpm %{name} variable. > > Peter Oh, wow, I didn't notice pgk either. Sorry! %{name} isn't entirely correct because you get ghc-%{pkg_name} instead of %{pkg_name}. -- Conrad Meyer From limb at jcomserv.net Wed Jul 22 12:07:58 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 22 Jul 2009 07:07:58 -0500 Subject: Need a sponsor: mod_proxy_html (apache) In-Reply-To: <4A66B3BC.90303@redfish-solutions.com> References: <4A60D611.9010501@redfish-solutions.com> <4A66B3BC.90303@redfish-solutions.com> Message-ID: <4A67011E.8020304@jcomserv.net> Philip A. Prindeville wrote: > Philip A. Prindeville wrote: > >> Hi. >> >> I need a sponsor for this. An RPM has been built on several systems >> (including FC8 and FC9 and Centos5) and tested on all of those. >> >> The ticket has been languishing now unassigned for almost a year. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=452636 >> >> Can someone please pick this up? >> >> It's just an .src.rpm for Apache's mod_proxy_html. >> >> It's pretty trivial. >> >> Thanks, >> >> -Philip >> >> >> > > Wow. Who knew sponsors were that hard to come by? Especially when most > of the work is already done... > > -Philip > > I'll have a look. .. -- in your fear, seek only peace in your fear, seek only love -d. bowie From christoph.wickert at googlemail.com Wed Jul 22 12:50:37 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Wed, 22 Jul 2009 14:50:37 +0200 Subject: rpms/parrot/F-9 parrot-1.x.0.patch, NONE, 1.1 .cvsignore, 1.2, 1.3 import.log, 1.1, 1.2 parrot.spec, 1.1, 1.2 sources, 1.2, 1.3 parrot-1.0.0-rpath-removal.patch, 1.1, NONE parrot-install_files.patch, 1.1, NONE In-Reply-To: <20090721164702.6979811C005E@cvs1.fedora.phx.redhat.com> References: <20090721164702.6979811C005E@cvs1.fedora.phx.redhat.com> Message-ID: <1248267037.2778.4.camel@localhost> Am Dienstag, den 21.07.2009, 16:47 +0000 schrieb Gerd Pokorra: > Author: gerd > > Update of /cvs/pkgs/rpms/parrot/F-9 ?hm, F-9 ist end of lifetime, da kannst Du keine Updates mehr machen. Ich w?rde dich bitten, die ?nderungen im CVS wieder auf den Stand vorher zur?ckzusetzen, damit es mit dem, was tats?chlich released wurde, auch synchron ist. > Log Message: > > Bitte immer eine Log message machen, also cvs -m "blala" commit. Oder aber einfacher make clog cvs commit -F clog Damit bekommst Du automatisch den letzen Eintrag im Changelog als Log. > %changelog > +* Tue Jul 21 2009 Gerd Pokorra 1.4.0-1 > +- add the new disable-rpath configure option Update to 1.4.0 h?tte man noch dazuschreiben k?nnen, aber ist nicht so wichtig. C U Christoph From christoph.wickert at googlemail.com Wed Jul 22 12:52:39 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Wed, 22 Jul 2009 14:52:39 +0200 Subject: rpms/parrot/F-9 parrot-1.x.0.patch, NONE, 1.1 .cvsignore, 1.2, 1.3 import.log, 1.1, 1.2 parrot.spec, 1.1, 1.2 sources, 1.2, 1.3 parrot-1.0.0-rpath-removal.patch, 1.1, NONE parrot-install_files.patch, 1.1, NONE In-Reply-To: <1248267037.2778.4.camel@localhost> References: <20090721164702.6979811C005E@cvs1.fedora.phx.redhat.com> <1248267037.2778.4.camel@localhost> Message-ID: <1248267159.2778.6.camel@localhost> Am Mittwoch, den 22.07.2009, 14:50 +0200 schrieb Christoph Wickert: > ... Sorry, this wasn't supposed to go to the list. Christoph From jarod at redhat.com Wed Jul 22 14:57:13 2009 From: jarod at redhat.com (Jarod Wilson) Date: Wed, 22 Jul 2009 10:57:13 -0400 Subject: No Frozen Rawhide In-Reply-To: <1248217490.2861.2.camel@localhost.localdomain> References: <1248217490.2861.2.camel@localhost.localdomain> Message-ID: <200907221057.13253.jarod@redhat.com> On Tuesday 21 July 2009 19:04:50 Jesse Keating wrote: > I've done some updating to the no frozen rawhide proposal[1]. There is > still time to enact this for Fedora 12, which would take effect when we > reach Alpha freeze in a couple weeks. I'd like another round of people > reviewing it and giving feedback before we take it to FESCo. Thanks! Only thing I'm not terribly wild about is storing the pre-release tree in /pub/fedora/linux/releases/#/Everything/. Its bound to cause some confusion amongst the general population. Any reason not to keep it at /pub/fedora/linux/releases/test/#/Everything/ instead? -- Jarod Wilson jarod at redhat.com From jkeating at redhat.com Wed Jul 22 15:58:11 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 22 Jul 2009 08:58:11 -0700 Subject: No Frozen Rawhide In-Reply-To: <200907221057.13253.jarod@redhat.com> References: <1248217490.2861.2.camel@localhost.localdomain> <200907221057.13253.jarod@redhat.com> Message-ID: <1248278291.2861.20.camel@localhost.localdomain> On Wed, 2009-07-22 at 10:57 -0400, Jarod Wilson wrote: > Only thing I'm not terribly wild about is storing the pre-release tree > in /pub/fedora/linux/releases/#/Everything/. Its bound to cause some > confusion amongst the general population. Any reason not to keep it at > /pub/fedora/linux/releases/test/#/Everything/ instead? Churn on the mirror configs and the repo files, as well as on the mirrors when we move to the final destination. Also it makes having test/12/Everything and test/12-Alpha and test/12-Beta a tad bit confusing when all in the same dir. But those are just my gut feelings, I'm not particularly sold on any way and welcome suggestions. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A 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 cdahlin at redhat.com Wed Jul 22 16:07:36 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Wed, 22 Jul 2009 12:07:36 -0400 Subject: Packaging StumpWM Message-ID: <4A673948.4070704@redhat.com> I've been using StumpWM ( http://www.nongnu.org/stumpwm/ ) perpetually for awhile now, and I would like to see it as a package in Fedora. The trouble is, its in Common Lisp (which I'm not terribly comfortable with) and I've run into some trouble with building it (something to do with prelink I think. RPM complains about the checksum, and when I try to turn prelink off, the RPM I get out has a mangled binary that's 6MB smaller than it should be and won't execute). Is there anyone else who would use this sort of thing and is a bit more familiar with common lisp and how to package it on Fedora? --CJD From mclasen at redhat.com Wed Jul 22 16:19:41 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 22 Jul 2009 12:19:41 -0400 Subject: Batteries and Suspend Test day summary Message-ID: <1248279581.1693.9.camel@planemask> The 'Fit and Finish' test day about batteries and suspend took place yesterday. Thanks to everybody who came by and helped us find, fix and test things ! If you could not make it, our test cases are still available here: http://www.fedoraproject.org/wiki/Test_Day:2009-07-21_Fit_and_Finish:Batteries_and_Suspend That page also contains the results of our yesterdays testing efforts, if you are interested. Amazingly, Richard fixed quite a few of the incoming bugs already, while the test day was still ongoing, and people were able to confirm that the fixes are working. Well done! I'll post the date an topic for our next 'Fit and Finish' test day in the next few days. Matthias From jarod at redhat.com Wed Jul 22 16:36:38 2009 From: jarod at redhat.com (Jarod Wilson) Date: Wed, 22 Jul 2009 12:36:38 -0400 Subject: No Frozen Rawhide In-Reply-To: <1248278291.2861.20.camel@localhost.localdomain> References: <1248217490.2861.2.camel@localhost.localdomain> <200907221057.13253.jarod@redhat.com> <1248278291.2861.20.camel@localhost.localdomain> Message-ID: <200907221236.39006.jarod@redhat.com> On Wednesday 22 July 2009 11:58:11 Jesse Keating wrote: > On Wed, 2009-07-22 at 10:57 -0400, Jarod Wilson wrote: > > Only thing I'm not terribly wild about is storing the pre-release tree > > in /pub/fedora/linux/releases/#/Everything/. Its bound to cause some > > confusion amongst the general population. Any reason not to keep it at > > /pub/fedora/linux/releases/test/#/Everything/ instead? > > Churn on the mirror configs and the repo files, That much sort of sucks, yeah, but meh. We change it at least once anyway though, going from rawhide to release, so is one more change here a huge undertaking? (I ask because have no idea) > as well as on the > mirrors when we move to the final destination. $ cd .../pub/fedora/linux/releases/test/ $ mv 12 ../ ? Of course, most mirrors are auto-updating via rsync, so perhaps that doesn't translate particularly well... But it would also make it easier for mirror admins who don't want to mirror anything but the actual released releases. > Also it makes having > test/12/Everything and test/12-Alpha and test/12-Beta a tad bit > confusing when all in the same dir. I think this is less confusing than having a release/12 well before the actual release of 12 though. Perhaps test/12/Everything would more accurately be called test/12/Nightly in this scenario? > But those are just my gut feelings, I'm not particularly sold on any way > and welcome suggestions. Okay, I'll keep 'em coming 'til you say otherwise. :) -- Jarod Wilson jarod at redhat.com From bruno at wolff.to Wed Jul 22 16:39:32 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 22 Jul 2009 11:39:32 -0500 Subject: No Frozen Rawhide In-Reply-To: <200907221057.13253.jarod@redhat.com> References: <1248217490.2861.2.camel@localhost.localdomain> <200907221057.13253.jarod@redhat.com> Message-ID: <20090722163932.GA24564@wolff.to> On Wed, Jul 22, 2009 at 10:57:13 -0400, Jarod Wilson wrote: > On Tuesday 21 July 2009 19:04:50 Jesse Keating wrote: > > I've done some updating to the no frozen rawhide proposal[1]. There is > > still time to enact this for Fedora 12, which would take effect when we > > reach Alpha freeze in a couple weeks. I'd like another round of people > > reviewing it and giving feedback before we take it to FESCo. Thanks! > > Only thing I'm not terribly wild about is storing the pre-release tree > in /pub/fedora/linux/releases/#/Everything/. Its bound to cause some > confusion amongst the general population. Any reason not to keep it at > /pub/fedora/linux/releases/test/#/Everything/ instead? Having it in /pub/fedora/linux/releases/#/Everything/ (where # is an integer, not the *.9? stuff) makes it easier for people following development in that scripts for syncing repositories will be consistant between when you are on rawhide and when you are on a release. Assuming that fedora-release also starts using compatible version naming, then you can also consistantly use $releasever in development as well. I think the confusion for normal users will be minimal, because normal users won't be looking at the raw repos in any case. Livna has recently started doing this. I don't know if they plan to continue this long term, but the already have a /12 directory. From hughsient at gmail.com Wed Jul 22 16:50:25 2009 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 22 Jul 2009 17:50:25 +0100 Subject: Batteries and Suspend Test day summary In-Reply-To: <1248279581.1693.9.camel@planemask> References: <1248279581.1693.9.camel@planemask> Message-ID: <15e53e180907220950v7b947df3t96d2fbbd71803791@mail.gmail.com> 2009/7/22 Matthias Clasen : > Amazingly, Richard fixed quite a few of the incoming bugs already, while > the test day was still ongoing, and people were able to confirm that the > fixes are working. Well done! Sure, and in mutual back-patting, Matthias did a great job coordinating things. I'm sure gnome-power-manager and DeviceKit-power will be in better shape thanks to this test day. Thanks to all of you who opened bugs, and identified issues on IRC. Richard. From martin.langhoff at gmail.com Wed Jul 22 16:54:37 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Wed, 22 Jul 2009 18:54:37 +0200 Subject: Batteries and Suspend Test day summary In-Reply-To: <15e53e180907220950v7b947df3t96d2fbbd71803791@mail.gmail.com> References: <1248279581.1693.9.camel@planemask> <15e53e180907220950v7b947df3t96d2fbbd71803791@mail.gmail.com> Message-ID: <46a038f90907220954p167eec8cnd03ec2781c7aab3c@mail.gmail.com> On Wed, Jul 22, 2009 at 6:50 PM, Richard Hughes wrote: > 2009/7/22 Matthias Clasen : >> Amazingly, Richard fixed quite a few of the incoming bugs already, while >> the test day was still ongoing, and people were able to confirm that the >> fixes are working. Well done! > > Sure, and in mutual back-patting, Matthias did a great job Great to hear this is going well. What hardware did you have available? Any of it with green ears? (Got a shipping address?) cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From hughsient at gmail.com Wed Jul 22 17:07:34 2009 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 22 Jul 2009 18:07:34 +0100 Subject: Batteries and Suspend Test day summary In-Reply-To: <46a038f90907220954p167eec8cnd03ec2781c7aab3c@mail.gmail.com> References: <1248279581.1693.9.camel@planemask> <15e53e180907220950v7b947df3t96d2fbbd71803791@mail.gmail.com> <46a038f90907220954p167eec8cnd03ec2781c7aab3c@mail.gmail.com> Message-ID: <15e53e180907221007s7394bcfeub9f81bbbc2780993@mail.gmail.com> 2009/7/22 Martin Langhoff : > On Wed, Jul 22, 2009 at 6:50 PM, Richard Hughes wrote: >> 2009/7/22 Matthias Clasen : >>> Amazingly, Richard fixed quite a few of the incoming bugs already, while >>> the test day was still ongoing, and people were able to confirm that the >>> fixes are working. Well done! >> >> Sure, and in mutual back-patting, Matthias did a great job > > Great to hear this is going well. What hardware did you have > available? Any of it with green ears? (Got a shipping address?) We were testing mostly laptops and netbooks. We didn't test any OLPC devices to my knowledge, although I have a B1 and a C1 sitting on my desk right now :-) Richard. From bruno at wolff.to Wed Jul 22 17:21:17 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 22 Jul 2009 12:21:17 -0500 Subject: No Frozen Rawhide In-Reply-To: <200907221236.39006.jarod@redhat.com> References: <1248217490.2861.2.camel@localhost.localdomain> <200907221057.13253.jarod@redhat.com> <1248278291.2861.20.camel@localhost.localdomain> <200907221236.39006.jarod@redhat.com> Message-ID: <20090722172117.GA27882@wolff.to> On Wed, Jul 22, 2009 at 12:36:38 -0400, Jarod Wilson wrote: > > $ cd .../pub/fedora/linux/releases/test/ > $ mv 12 ../ You actually want overlap for a while so that when rsyncing you can use hardlinks instead of having to redownload files you already have. This is going to be more relevant if koji signing happens and packages don't get different signatures depending on which repo they are in. From kevin.kofler at chello.at Wed Jul 22 17:51:16 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 22 Jul 2009 19:51:16 +0200 Subject: Sage in F11 References: <1248037544.3613.113.camel@valkyrie.localdomain> Message-ID: Matthew Saltzman wrote: > I assume I'm missing a dependency, but what is it? It's trying to load the old F10 version of OpenSSL. Kevin Kofler From jkeating at redhat.com Wed Jul 22 18:14:32 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 22 Jul 2009 11:14:32 -0700 Subject: No Frozen Rawhide In-Reply-To: <200907221236.39006.jarod@redhat.com> References: <1248217490.2861.2.camel@localhost.localdomain> <200907221057.13253.jarod@redhat.com> <1248278291.2861.20.camel@localhost.localdomain> <200907221236.39006.jarod@redhat.com> Message-ID: <1248286472.2861.70.camel@localhost.localdomain> On Wed, 2009-07-22 at 12:36 -0400, Jarod Wilson wrote: > On Wednesday 22 July 2009 11:58:11 Jesse Keating wrote: > > On Wed, 2009-07-22 at 10:57 -0400, Jarod Wilson wrote: > > > Only thing I'm not terribly wild about is storing the pre-release tree > > > in /pub/fedora/linux/releases/#/Everything/. Its bound to cause some > > > confusion amongst the general population. Any reason not to keep it at > > > /pub/fedora/linux/releases/test/#/Everything/ instead? > > > > Churn on the mirror configs and the repo files, > > That much sort of sucks, yeah, but meh. We change it at least once > anyway though, going from rawhide to release, so is one more change > here a huge undertaking? (I ask because have no idea) Well every change has potential to break users who have had to do some customization, and it hurts 3rd party repo setups. It'd be nice to install a repo config at Alpha and have the paths used remain useful and valid through the entire release. Would make it easier to attract users at Alpha/Beta and not suddenly drop them off the face or drag them into the next rawhide. > > > as well as on the > > mirrors when we move to the final destination. > > $ cd .../pub/fedora/linux/releases/test/ > $ mv 12 ../ > > ? > > Of course, most mirrors are auto-updating via rsync, so perhaps that > doesn't translate particularly well... But it would also make it easier > for mirror admins who don't want to mirror anything but the actual > released releases. Yeah, sucks for mirrors. If you don't do hardlinks for a while first, they'd have to re-sync the entire pile of packages. And if you're going to do the hardlink dance, might as well use the base location first. Most of our mirrors tend to use the fedora-enchilada path so we're not likely to break too many expectations by having something in releases/ change, any more than by having something in releases/test/ change. > > > Also it makes having > > test/12/Everything and test/12-Alpha and test/12-Beta a tad bit > > confusing when all in the same dir. > > I think this is less confusing than having a release/12 well before the > actual release of 12 though. Perhaps test/12/Everything would more > accurately be called test/12/Nightly in this scenario? This is why we'll set the expectation of the release on having the Fedora/ path show up. Since that's really what signifies the release, having gpg signed checksummed isos show up, and torrents getting turned on, etc.. There will have to be some expectation changes, but really the kind of people digging at raw mirror paths are going to be the kind of people that can adjust their expectations. > > > But those are just my gut feelings, I'm not particularly sold on any way > > and welcome suggestions. > > Okay, I'll keep 'em coming 'til you say otherwise. :) > > -- > Jarod Wilson > jarod at redhat.com > -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A 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 stickster at gmail.com Wed Jul 22 18:41:38 2009 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 22 Jul 2009 14:41:38 -0400 Subject: No Frozen Rawhide In-Reply-To: <20090722172117.GA27882@wolff.to> References: <1248217490.2861.2.camel@localhost.localdomain> <200907221057.13253.jarod@redhat.com> <1248278291.2861.20.camel@localhost.localdomain> <200907221236.39006.jarod@redhat.com> <20090722172117.GA27882@wolff.to> Message-ID: <20090722184138.GM21921@localhost.localdomain> On Wed, Jul 22, 2009 at 12:21:17PM -0500, Bruno Wolff III wrote: > On Wed, Jul 22, 2009 at 12:36:38 -0400, > Jarod Wilson wrote: > > > > $ cd .../pub/fedora/linux/releases/test/ > > $ mv 12 ../ > > You actually want overlap for a while so that when rsyncing you can use > hardlinks instead of having to redownload files you already have. > This is going to be more relevant if koji signing happens and packages don't > get different signatures depending on which repo they are in. Surely we could work that overlap into the schedule, especially since package data should be frozen pretty hard for the last couple of weeks? -- 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 roland at redhat.com Wed Jul 22 18:55:27 2009 From: roland at redhat.com (Roland McGrath) Date: Wed, 22 Jul 2009 11:55:27 -0700 (PDT) Subject: No Frozen Rawhide In-Reply-To: Bruno Wolff III's message of Wednesday, 22 July 2009 12:21:17 -0500 <20090722172117.GA27882@wolff.to> References: <1248217490.2861.2.camel@localhost.localdomain> <200907221057.13253.jarod@redhat.com> <1248278291.2861.20.camel@localhost.localdomain> <200907221236.39006.jarod@redhat.com> <20090722172117.GA27882@wolff.to> Message-ID: <20090722185527.BB36B67B6E@magilla.sf.frob.com> > You actually want overlap for a while so that when rsyncing you can use > hardlinks instead of having to redownload files you already have. > This is going to be more relevant if koji signing happens and packages don't > get different signatures depending on which repo they are in. That would be nice for updates/updates-testing moves too. For that, I've thought it might work to put them all in updates/.all or someplace, with updates/... or updates/testing/... being hardlinks to that. From pasik at iki.fi Wed Jul 22 19:05:53 2009 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Wed, 22 Jul 2009 22:05:53 +0300 Subject: Batteries and Suspend Test day summary In-Reply-To: <1248279581.1693.9.camel@planemask> References: <1248279581.1693.9.camel@planemask> Message-ID: <20090722190553.GQ24960@edu.joroinen.fi> On Wed, Jul 22, 2009 at 12:19:41PM -0400, Matthias Clasen wrote: > The 'Fit and Finish' test day about batteries and suspend took place > yesterday. Thanks to everybody who came by and helped us find, fix and > test things ! > Hello, A friend of mine has been having a lot of problems with his laptop about battery life.. When using Linux (Fedora,Ubuntu) the battery life is a lot worse than when using Windows. He's been trying to identify the problem with powertop, disable services etc, but hasn't been able to match the battery life of Windows. Have you guys thought about this? Sounds like something to test during these 'Fit and Finish' days.. -- Pasi From bkoz at redhat.com Wed Jul 22 19:16:35 2009 From: bkoz at redhat.com (Benjamin Kosnik) Date: Wed, 22 Jul 2009 12:16:35 -0700 Subject: Building boost-1.39.0-3.fc12.src.rpm on Fedora11 In-Reply-To: <7a0107ba0907211231l1b1a7844je2b8e423cdfde705@mail.gmail.com> References: <7a0107ba0907211231l1b1a7844je2b8e423cdfde705@mail.gmail.com> Message-ID: <20090722121635.1d5a3f56@mcgee.artheist.org> > I am wondering if there is an known incompatibility between the > rawhide version of boost and Fedora 11. Builds fine for me on F11, F12 on x86_64 -benjamin From jwboyer at gmail.com Wed Jul 22 19:35:06 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 22 Jul 2009 15:35:06 -0400 Subject: No Frozen Rawhide In-Reply-To: <20090722185527.BB36B67B6E@magilla.sf.frob.com> References: <1248217490.2861.2.camel@localhost.localdomain> <200907221057.13253.jarod@redhat.com> <1248278291.2861.20.camel@localhost.localdomain> <200907221236.39006.jarod@redhat.com> <20090722172117.GA27882@wolff.to> <20090722185527.BB36B67B6E@magilla.sf.frob.com> Message-ID: <20090722193506.GN3312@hansolo.jdub.homelinux.org> On Wed, Jul 22, 2009 at 11:55:27AM -0700, Roland McGrath wrote: >> You actually want overlap for a while so that when rsyncing you can use >> hardlinks instead of having to redownload files you already have. >> This is going to be more relevant if koji signing happens and packages don't >> get different signatures depending on which repo they are in. > >That would be nice for updates/updates-testing moves too. >For that, I've thought it might work to put them all in updates/.all or >someplace, with updates/... or updates/testing/... being hardlinks to that. Releases prior to F-11 wouldn't benefit from that at all, as the RPMs actually change when going from updates-testing to updates due to being signed with different keys. That might be worth looking into once F-10 dies. josh From roland at redhat.com Wed Jul 22 19:42:44 2009 From: roland at redhat.com (Roland McGrath) Date: Wed, 22 Jul 2009 12:42:44 -0700 (PDT) Subject: No Frozen Rawhide In-Reply-To: Josh Boyer's message of Wednesday, 22 July 2009 15:35:06 -0400 <20090722193506.GN3312@hansolo.jdub.homelinux.org> References: <1248217490.2861.2.camel@localhost.localdomain> <200907221057.13253.jarod@redhat.com> <1248278291.2861.20.camel@localhost.localdomain> <200907221236.39006.jarod@redhat.com> <20090722172117.GA27882@wolff.to> <20090722185527.BB36B67B6E@magilla.sf.frob.com> <20090722193506.GN3312@hansolo.jdub.homelinux.org> Message-ID: <20090722194244.0E33E2D36@magilla.sf.frob.com> > Releases prior to F-11 wouldn't benefit from that at all, as the RPMs > actually change when going from updates-testing to updates due to being > signed with different keys. I think it still helps a lot with rsync. The old .all/* files are there to be seen as almost the same and get rsync goodness, before rsync sees the updates/testing/* file is gone and updates/* is a link to .all/*. Thanks, Roland From sven at lank.es Wed Jul 22 19:53:39 2009 From: sven at lank.es (Sven Lankes) Date: Wed, 22 Jul 2009 21:53:39 +0200 Subject: No Frozen Rawhide In-Reply-To: <1248286472.2861.70.camel@localhost.localdomain> References: <1248217490.2861.2.camel@localhost.localdomain> <200907221057.13253.jarod@redhat.com> <1248278291.2861.20.camel@localhost.localdomain> <200907221236.39006.jarod@redhat.com> <1248286472.2861.70.camel@localhost.localdomain> Message-ID: <20090722195339.GB9480@killefiz> On Wed, Jul 22, 2009 at 11:14:32AM -0700, Jesse Keating wrote: > Well every change has potential to break users who have had to do some > customization, and it hurts 3rd party repo setups. It'd be nice to > install a repo config at Alpha and have the paths used remain useful and > valid through the entire release. Would make it easier to attract users > at Alpha/Beta and not suddenly drop them off the face or drag them into > the next rawhide. +1 Let's at least try it that way for one release. It works well for most other distros and from my pov fedora is making stuff difficult for everyone by sticking to the "we cannot have anything called F12 anywhere until the release is officially out"-mantra. -- sven === jabber/xmpp: sven at lankes.net From rawhide at fedoraproject.org Wed Jul 22 20:43:01 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Wed, 22 Jul 2009 20:43:01 +0000 Subject: rawhide report: 20090722 changes Message-ID: <20090722204301.GA18593@releng2.fedora.phx.redhat.com> Compose started at Wed Jul 22 06:15:05 UTC 2009 New package chunkd Data storage daemon for cloud computing New package python-tgext-crud Crud Controller Extension for TG2 New package zikula-module-News Manages news articles on your Zikula site Removed package clutter-cairo Updated Packages: 389-admin-1.1.8-3.fc12 ---------------------- * Tue Jul 21 2009 Rich Megginson - 1.1.8-2 - change adminutil to 389-adminutil * Tue Jul 21 2009 Rich Megginson - 1.1.8-3 - bump rev for final rebuild ardour-2.8.2-2.fc12 ------------------- * Tue Jul 21 2009 Orcan Ogetbil 2.8.2-1 - New upstream release 2.8.2. * Tue Jul 21 2009 Orcan Ogetbil 2.8.2-2 - Fix libdir once more arora-0.8.0-1.fc12 ------------------ * Tue Jul 21 2009 Jaroslav Reznik - 0.8.0-1 - Update to 0.8.0 - Removed custom arora.xml bind-9.6.1-4.fc12 ----------------- * Mon Jul 20 2009 Adam Tkac 32:9.6.1-4 - remove useless bind-9.3.3rc2-rndckey.patch boinc-client-6.6.37-2.r18632svn.fc12 ------------------------------------ * Tue Jul 21 2009 Milos Jakubicek - 6.6.37-2.r18632svn - Rebase to 6.6a branch (resolves BZ#477882) - Ship shared libraries too, link client dynamically to them - Dropped boinc-rsa.patch (merged upstream) - Dropped boinc-client-6.4.5-event.patch (merged upstream) - Dropped boinc-cuda.patch (merged upstream) - Dropped boinc-gccflags.patch (merged upstream) - Updated boinc-gcc44.patch (merged partially) - Disable newly appeared standard rpaths - Added short user guide exported from wiki as USAGE_FEDORA bonnie++-1.03e-2.fc12 --------------------- * Fri Jun 12 2009 Ville Skytt? - 1.03e-2 - Don't strip binaries before -debuginfo is generated (#505570). chkrootkit-0.48-12.fc12 ----------------------- * Tue Jul 21 2009 Jon Ciesla 0.48-12 - Patch to fix crash in chkutmp on x86_64. cld-0.2-0.4.gc5b5f962.fc12 -------------------------- * Tue Jul 21 2009 Jeff Garzik - 0.2-0.3.gc5b5f962 - update to commit c5b5f9622334b273c47e7aad5bd53e280041a045 * Tue Jul 21 2009 Jeff Garzik - 0.2-0.4.gc5b5f962 - rebuild for koji silliness docbook-style-xsl-1.75.2-2.fc12 ------------------------------- * Wed Jul 22 2009 Ondrej Vasik 1.75.2-2 - upstream changed tarballs after release * Tue Jul 21 2009 Ondrej Vasik 1.75.2-1 - New upstream release 1.75.2 docbook5-style-xsl-1.75.2-2.fc12 -------------------------------- * Wed Jul 22 2009 Ondrej Vasik 1.75.2-2 - upstream changed tarballs after release * Tue Jul 21 2009 Ondrej Vasik 1.75.2-1 - new upstream release 1.75.2 dumpasn1-20090318-2.fc12 ------------------------ * Fri Jul 17 2009 Fran?ois Kooman - 20090318-2 - cfg file already has unix line endings - create patch instead of using sed to replace BYTE with char * Thu Jul 16 2009 Fran?ois Kooman - 20090318-1 - Update to 20090318 and config to 20090531 eclipse-checkstyle-4.0.1-13.fc12 -------------------------------- * Tue Jul 21 2009 Alexander Kurtakov 4.0.1-13 - Fix build with Eclipse 3.5. - Remove gcj_support. ecryptfs-utils-76-1.fc12 ------------------------ * Mon Jul 20 2009 Michal Hlavinka 76-1 - updated to 76 * Thu May 21 2009 Michal Hlavinka 75-1 - removed executable permission from ecryptfs-dot-private (#500817) - require cryptsetup-luks for encrypted swap (#500824) - use blkid instead of vol_id (#500820) - don't rely on cryptdisks service (#500829) - add icon for Access-Your-Private-Data.desktop file * Mon May 04 2009 Michal Hlavinka 75-1 - updated to 75 - restrict mount.ecryptfs_private to ecryptfs group members only * Thu Apr 23 2009 Michal Hlavinka 74-1 - updated to 74 emelfm2-0.6.2-2.fc12 -------------------- * Tue Jul 21 2009 Christoph Wickert - 0.6.2-2 - Fix a typo that prefented the debuginfo from being built (#513031) fprintd-0.1-14.git04fd09cfa.fc12 -------------------------------- * Tue Jul 21 2009 Bastien Nocera 0.1-13.git04fd09cfa - Make the -devel package noarch (#507698) * Tue Jul 21 2009 Bastien Nocera 0.1-14.git04fd09cfa - Merge polkit patch and fix for polkit patch fwbackups-1.43.3-0.4.rc2.fc12 ----------------------------- * Tue Jul 21 2009 Stewart Adam 1.43.3-0.4.rc2 - Add patch to fix one-time backups (#512356) gajim-0.12.3-1.fc12 ------------------- * Wed Jul 22 2009 Debarshi Ray - 0.12.3-1 - Version bump to 0.12.3. (Red Hat Bugzilla #510803) * Better keepalive / ping behaviour. * Fixed custom port handling. * Fixed PEP discovery. * Fixed PLAIN authentication (in particular with Google Talk). * Fixed SSL with some servers. * Handle XFCE notification-daemon. * Improve Kerberos support. * NetworkManager 0.7 support. * Restore old behaviour of click on systray: left click to open events. * Totem support for played music. * Tue Jul 14 2009 Debarshi Ray - 0.12.1-2 - Replaced 'License: GPLv2' with 'License: GPLv3'. - Added 'Requires: gnupg python-crypto python-GnuPGInterface'. (Red Hat Bugzilla #510804) gcc-4.4.0-15 ------------ * Tue Jul 21 2009 Jakub Jelinek 4.4.0-15 - update from gcc-4_4-branch - PRs libfortran/40714, target/39943, target/40809, tree-optimization/40792 - fix ICE in gsi_insert_seq_nodes_after (#505798, PR tree-optimization/40813) - slightly relax -D_FORTIFY_SOURCE=2 rules for flexible-array-member like constructs (#512689, #511573) - vectorize unsigned int -> {float,double} conversions on x86/x86_64 (PR target/40811) - update for i586.rpm -> i686.rpm switch (default to -march=i686 -mtune=generic in i686.rpm gcc and also with -m32 in x86_64.rpm gcc) ghc-6.10.4-1.fc12 ----------------- * Tue Jul 21 2009 Bryan O'Sullivan - 6.10.4-1 - update to 6.10.4 ghc-editline-0.2.1.0-5.fc12 --------------------------- * Tue Jul 21 2009 Jochen Schmitt 0.2.1.0-5 - Fix typo in %{pkg_name} macro * Mon Jul 20 2009 Jochen Schmitt 0.2.1.0-4 - Fix typo in definition of %{pkg_libdir} gnome-bluetooth-2.27.8-1.fc12 ----------------------------- * Tue Jul 21 2009 Bastien Nocera 2.27.8-1 - Update to 2.27.8 gnome-power-manager-2.27.3-0.1.20090721git.fc12 ----------------------------------------------- * Tue Jul 21 2009 Richard Hughes - 2.27.3-0.1.20090721git - Update to todays git snapshot to fix many issues with multiple composite laptop batteries and notifications. gnome-settings-daemon-2.27.4-3.fc12 ----------------------------------- * Tue Jul 21 2009 Matthias Clasen 2.27.4-3 - Make locate-pointer not interfere with media keys grace-5.1.22-4.fc12 ------------------- * Tue Jul 21 2009 Jos? Matos - 5.1.22-4 - Fix #504413 (remove last newline in FontDataBase) gstreamer-plugins-base-0.10.23.3-2.fc12 --------------------------------------- * Tue Jul 21 2009 Bastien Nocera 0.10.23.3-1 - Udpate to 0.10.23.3 * Tue Jul 21 2009 Bastien Nocera 0.10.23.3-2 - Remove old patches (the input-selector has been moved to be an internal playbin2 plugin) hplip-3.9.2-6.fc12 ------------------ * Tue Jul 21 2009 Tim Waugh 3.9.2-6 - Fixed device-id reporting. ibus-1.2.0.20090722-1.fc12 -------------------------- * Wed Jul 22 2009 Peng Huang - 1.2.0.20090722-1 - Update to 1.2.0.20090722 ibus-table-cangjie-1.2.0.20090717-5.fc12 ---------------------------------------- * Wed Jul 22 2009 Caius 'kaio' Chance - 1.2.0.20090717-4.fc12 - Removed unneccessary BuildRequires. - Removed unneccessary owned directories. - Changed autogen.sh into configure. * Wed Jul 22 2009 Caius 'kaio' Chance - 1.2.0.20090717-5.fc12 - Rebuilt. * Mon Jul 20 2009 Caius 'kaio' Chance - 1.2.0.20090717-3.fc12 - Rebuilt. ibus-table-erbi-1.2.0.20090717-2.fc12 ------------------------------------- * Wed Jul 22 2009 Caius 'kaio' Chance - 1.1.0.20090717-2.fc12 - Removed unneccessary BuildRequires. - Removed unneccessary owned directories. - Changed autogen.sh into configure. ibus-table-wubi-1.2.0.20090715-2.fc12 ------------------------------------- * Wed Jul 22 2009 Caius 'kaio' Chance - 1.2.0.20090715-2.fc12 - Removed unneccessary BuildRequires. - Removed unneccessary owned directories. - Changed autogen.sh into configure. ibus-table-yong-1.2.0.20090717-2.fc12 ------------------------------------- * Wed Jul 22 2009 Caius 'kaio' Chance - 1.1.0.20090717-2.fc12 - Removed unneccessary BuildRequires. - Removed unneccessary owned directories. - Changed autogen.sh into configure. lam-7.1.4-8.fc12 ---------------- * Tue Jul 21 2009 Doug Ledford - 2:7.1.4-8 - Update module file - Fix Group listing (bz512542) - Fix build (bz511490) libfprint-0.1.0-9.pre2.fc12 --------------------------- * Tue Jul 21 2009 Bastien Nocera 0.1.0-9.pre2 - Use gdk-pixbuf for image manipulation instead of ImageMagick (#472103) libnice-0.0.8-2.fc12 -------------------- * Tue Jul 21 2009 Warren Togami - 0.0.8-2 - stun sha1 patch from upstream to make it work at all libopensync-plugin-synce-0.22.1-1.fc12 -------------------------------------- * Tue Jul 21 2009 Andreas Bierfert - 1:0.22.1-1 - version upgrade librapi-0.14-1.fc12 ------------------- * Tue Jul 21 2009 Andreas Bierfert - 0.14-1 - version upgrade librra-0.14-1.fc12 ------------------ * Tue Jul 21 2009 Andreas Bierfert - 0.14-1 - version upgrade lirc-0.8.6-0.3.pre1.fc12 ------------------------ * Tue Jul 21 2009 Jarod Wilson 0.8.6-0.3.pre1 - Set up tools to use /dev/lirc0 instead of /dev/lirc by default - Set a default font for xmode2 most people actually have (#467339) nasm-2.07-1.fc12 ---------------- * Tue Jul 21 2009 Adam Tkac - 2.07-1 - update to 2.07 ncl-5.1.1-1.fc12 ---------------- * Mon Jul 13 2009 - Orion Poplawski - 5.1.1-1 - Update to 5.1.1 notification-daemon-0.4.0-4.fc12 -------------------------------- * Tue Jul 21 2009 Adam Tkac - 0.4.0-4 - improve libsexy patch notification-daemon-engine-nodoka-0.1.0-9.fc12 ---------------------------------------------- * Tue Jul 21 2009 Matthias Clasen - 0.1.0-9 - Fix the libsexy removal patch nted-1.6.1-1.fc12 ----------------- * Tue Jul 21 2009 Hans Ulrich Niedermann - 1.6.1-1 - Upstream release 1.6.0/1.6.1 ntp-4.2.4p7-3.fc12 ------------------ * Tue Jul 21 2009 Miroslav Lichvar 4.2.4p7-3 - handle system time jumps better - don't wake up every second for refclocks without timer - don't crash in ntpstat when unknown clock type is received (#505564) - make ntpstat process first packet in multipacket response - switch to editline - set pool.ntp.org vendor zone in spec (#512711) - compile with -fno-strict-aliasing openmpi-1.3.3-2.fc12 -------------------- * Tue Jul 21 2009 Doug Ledford - 1.3.3-1 - Make sure all created dirs are owned (bz474677) - Fix loading of pkgconfig file (bz476844) - Resolve file conflict between us and libotf (bz496131) - Resolve dangling symlinks issue (bz496909) - Resolve unexpanded %{mode} issues (bz496911) - Restore -devel subpackage (bz499851) - Make getting the default openmpi devel environment easier (bz504357) - Make the -devel package pull in the base package (bz459458) - Make it easier to use alternative compilers to build package (bz246484) * Tue Jul 21 2009 Doug Ledford - 1.3.3-2 - Add MPI_BIN and MPI_LIB to the modules file (related bz511099) openssh-5.2p1-14.fc12 --------------------- * Fri Jul 17 2009 Jan F. Chadima - 5.2p1-14 - changed internal-sftp context to sftpd_t * Fri Jul 03 2009 Jan F. Chadima - 5.2p1-13 - changed home length path patch to upstream version parted-1.9.0-4.20090721git980c.fc12 ----------------------------------- * Tue Jul 21 2009 Joel Granados - 1.9.0-4.20090721git980c - New snapshot. - Add patches to make dasd duplicate disk work. pcmanx-gtk2-0.3.8-7.fc12 ------------------------ * Tue Jul 21 2009 Caol?n McNamara - 0.3.8-7 - Resolves: rhbz#511615 FTBFS * Mon Jul 20 2009 Jan Horak - 0.3.8-6 - Rebuild against newer gecko pdfedit-0.4.3-1.fc12 -------------------- * Tue Jul 21 2009 Bernard Johnson - 0.4.3-1 - 0.4.3 pidgin-2.6.0-0.3.20090721.fc12 ------------------------------ * Tue Jul 21 2009 Warren Togami 2.6.0-0.1.20090721 - 2.6.0 snapshot with voice and video support via farsight2 * Tue Jul 21 2009 Warren Togami 2.6.0-0.3.20090721 - prevent crash with no camera when closing vv window pixman-0.15.18-1.fc12 --------------------- * Tue Jul 21 2009 Soren Sandmann 0.15.18-1 - pixman 0.15.18 prelude-lml-0.9.15-1.fc12 ------------------------- * Tue Jul 21 2009 Steve Grubb 0.9.15-1 - new upstream release proguard-4.4-1.fc12 ------------------- * Tue Jul 21 2009 Fran?ois Kooman - 4.4-1 - update to ProGuard 4.4 pygrace-0.4-2.fc12 ------------------ * Tue Jul 21 2009 Jussi Lehtola - 0.4-2 - Change Requires: python-numeric to numpy. pymol-1.2-6.20090709svn3827.fc12 -------------------------------- * Tue Jul 21 2009 Tim Fenn - 1.2-6.20090709svn3827 - include chempy, pmg_tk and tut subdirectories in data folder python-beaker-1.3.1-5.fc12 -------------------------- * Tue Jul 21 2009 Kyle VanderBeek - 1.3.1-5 - Add patch based on upstream hg 403ef7c82d32 for config overwriting that breaks Pylons unit tests redhat-rpm-config-9.0.3-11.fc12 ------------------------------- * Tue Jul 21 2009 Tom "spot" Callaway - 9.0.3-10 - always delete %buildroot as first step of %install (as long as /builddir/build/BUILDROOT/redhat-rpm-config-9.0.3-11.fc12.noarch is not /) rpm-4.7.1-1.fc12 ---------------- * Tue Jul 21 2009 Panu Matilainen - 4.7.1-1 - update to 4.7.1 ((http://rpm.org/wiki/Releases/4.7.1) - fix source url scidavis-0.2.3-6.fc12 --------------------- * Tue Jul 21 2009 Eric Tanguy - 0.2.3-6 - Touch manual/scidavis.adp to make Assistant update the cache scim-qtimm-0.9.4-12.fc12 ------------------------ * Wed Jul 22 2009 Jens Petersen - 0.9.4-12 - correct the Group name (reported by Edwin ten Brink, #512544) scribus-1.3.5-0.15.rc3.fc12 --------------------------- * Tue Jul 21 2009 Dan Hor?k - 1.3.5-0.15.rc3 - update to 1.3.5-rc3 - use system hyphen library (#506074) - fix update path for the doc subpackage (#512498) - preserve directories when installing headers (#511800) setroubleshoot-2.2.16-1.fc12 ---------------------------- * Tue Jul 21 2009 Dan Walsh - 2.2.16-1 - Fix sesearch handling setup-2.8.7-1.fc12 ------------------ * Tue Jul 21 2009 Ondrej Vasik 2.8.7-1 - increase threshold for uidgid reservations to 200 - reserve uidgid pair 107:107 for qemu (libvirt,#511957) - reflect threshold in profile and bashrc, do inform about uidgid file existence there - remove old remnants about portmap from hosts.deny(#509919) synce-hal-0.14-1.fc12 --------------------- * Tue Jul 21 2009 Andreas Bierfert - 0.14-1 - version upgrade synce-kpm-0.14-1.fc12 --------------------- * Tue Jul 21 2009 Andreas Bierfert - 0.14-1 - version upgrade synce-sync-engine-0.14-1.fc12 ----------------------------- * Tue Jul 21 2009 Andreas Bierfert - 0.14-1 - version upgrade tog-pegasus-2.9.0-2.fc12 ------------------------ * Tue Jul 21 2009 Vitezslav Crhonek - 2:2.9.0-2 - Fix Group xorg-x11-proto-devel-7.4-22.fc12 -------------------------------- * Tue Jul 21 2009 Adam Jackson 7.4-22 - xextproto 7.0.99.1 - fixesproto snapshot xsane-0.996-9.fc12 ------------------ * Tue Jul 21 2009 Nils Philippsen 0.996-9 - don't show EULA, mention bugzilla in about dialog (#504344) Summary: Added Packages: 3 Removed Packages: 1 Modified Packages: 69 Broken deps for i386 ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin R-RScaLAPACK-0.5.1-19.fc11.i586 requires openmpi-libs clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.i586 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.i586 requires gauche = 0:0.8.13 gedit-vala-0.4.1-2.fc11.i586 requires libgtksourcecompletion-1.0.so.1 ghc-HTTP-devel-4000.0.6-3.fc12.i586 requires ghc = 0:6.10.3 ghc-HTTP-devel-4000.0.6-3.fc12.i586 requires ghc = 0:6.10.3 ghc-HTTP-doc-4000.0.6-3.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-HTTP-doc-4000.0.6-3.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-HTTP-prof-4000.0.6-3.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-X11-devel-1.4.5-11.fc12.i586 requires ghc = 0:6.10.3 ghc-X11-devel-1.4.5-11.fc12.i586 requires ghc = 0:6.10.3 ghc-X11-doc-1.4.5-11.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-X11-doc-1.4.5-11.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-X11-prof-1.4.5-11.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-cairo-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-cairo-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-cairo-prof-0.10.1-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-cpphs-devel-1.6-8.fc12.i586 requires ghc = 0:6.10.3 ghc-cpphs-devel-1.6-8.fc12.i586 requires ghc = 0:6.10.3 ghc-cpphs-doc-1.6-8.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-cpphs-doc-1.6-8.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-cpphs-prof-1.6-8.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-editline-devel-0.2.1.0-5.fc12.i686 requires ghc = 0:6.10.3 ghc-editline-doc-0.2.1.0-5.fc12.i686 requires ghc-doc = 0:6.10.3 ghc-editline-doc-0.2.1.0-5.fc12.i686 requires ghc-doc = 0:6.10.3 ghc-editline-prof-0.2.1.0-5.fc12.i686 requires ghc-prof = 0:6.10.3 ghc-gconf-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gconf-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gconf-prof-0.10.1-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-ghc-paths-devel-0.1.0.5-7.fc12.i586 requires ghc = 0:6.10.3 ghc-ghc-paths-devel-0.1.0.5-7.fc12.i586 requires ghc = 0:6.10.3 ghc-ghc-paths-doc-0.1.0.5-7.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-ghc-paths-doc-0.1.0.5-7.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-ghc-paths-prof-0.1.0.5-7.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-gio-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gio-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gio-prof-0.10.1-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-glade-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-glade-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-glade-prof-0.10.1-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-glib-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-glib-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-glib-prof-0.10.1-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-gstreamer-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gstreamer-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gstreamer-prof-0.10.1-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-gtk-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtk-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtk-prof-0.10.1-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-gtkglext-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtkglext-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtkglext-prof-0.10.1-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-gtksourceview2-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtksourceview2-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtksourceview2-prof-0.10.1-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-haskell-src-exts-devel-1.0.1-1.fc12.i586 requires ghc = 0:6.10.3 ghc-haskell-src-exts-devel-1.0.1-1.fc12.i586 requires ghc = 0:6.10.3 ghc-haskell-src-exts-doc-1.0.1-1.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-haskell-src-exts-doc-1.0.1-1.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-haskell-src-exts-prof-1.0.1-1.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-hscolour-devel-1.13-1.fc12.i586 requires ghc = 0:6.10.3 ghc-hscolour-devel-1.13-1.fc12.i586 requires ghc = 0:6.10.3 ghc-hscolour-doc-1.13-1.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-hscolour-doc-1.13-1.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-hscolour-prof-1.13-1.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-soegtk-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-soegtk-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-soegtk-prof-0.10.1-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-svgcairo-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-svgcairo-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-svgcairo-prof-0.10.1-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-uniplate-devel-1.2.0.3-4.fc12.i586 requires ghc = 0:6.10.3 ghc-uniplate-devel-1.2.0.3-4.fc12.i586 requires ghc = 0:6.10.3 ghc-uniplate-doc-1.2.0.3-4.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-uniplate-doc-1.2.0.3-4.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-uniplate-prof-1.2.0.3-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-utf8-string-devel-0.3.5-2.fc12.i586 requires ghc = 0:6.10.3 ghc-utf8-string-devel-0.3.5-2.fc12.i586 requires ghc = 0:6.10.3 ghc-utf8-string-doc-0.3.5-2.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-utf8-string-doc-0.3.5-2.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-utf8-string-prof-0.3.5-2.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-xmonad-devel-0.8.1-13.fc12.i586 requires ghc = 0:6.10.3 ghc-xmonad-devel-0.8.1-13.fc12.i586 requires ghc = 0:6.10.3 ghc-xmonad-doc-0.8.1-13.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-xmonad-doc-0.8.1-13.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-xmonad-prof-0.8.1-13.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-zlib-devel-0.5.0.0-9.fc12.i586 requires ghc = 0:6.10.3 ghc-zlib-devel-0.5.0.0-9.fc12.i586 requires ghc = 0:6.10.3 ghc-zlib-doc-0.5.0.0-9.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-zlib-doc-0.5.0.0-9.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-zlib-prof-0.5.0.0-9.fc12.i586 requires ghc-prof = 0:6.10.3 gnome-phone-manager-0.65-2.fc12.i586 requires libgnome-bluetooth.so.6 libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.i586 requires libclutter-cairo-0.8.so.0 libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) php-idn-1.2-5.fc12.i586 requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.i586 requires libclutter-cairo-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.i586 requires clutter-cairo pyclutter-gst-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.i386 requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.i386 requires python(abi) = 0:2.5 python-tgext-crud-0.2.4-1.fc12.noarch requires python-sprox >= 0:0.5.4.1 qtparted-0.4.5-19.fc11.i586 requires libparted-1.8.so.8 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.i586 requires libpqxx-2.6.8.so thunderbird-lightning-1.0-0.6.20090513hg.fc12.i586 requires thunderbird < 0:3.0-2.3.b4 totem-youtube-2.27.1-2.fc12.i586 requires libgdata.so.4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 Broken deps for x86_64 ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin R-RScaLAPACK-0.5.1-19.fc11.x86_64 requires openmpi-libs clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-cairo-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.x86_64 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.x86_64 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.x86_64 requires gauche = 0:0.8.13 gedit-vala-0.4.1-2.fc11.x86_64 requires libgtksourcecompletion-1.0.so.1()(64bit) ghc-HTTP-devel-4000.0.6-3.fc12.i586 requires ghc = 0:6.10.3 ghc-HTTP-devel-4000.0.6-3.fc12.i586 requires ghc = 0:6.10.3 ghc-HTTP-devel-4000.0.6-3.fc12.x86_64 requires ghc = 0:6.10.3 ghc-HTTP-devel-4000.0.6-3.fc12.x86_64 requires ghc = 0:6.10.3 ghc-HTTP-doc-4000.0.6-3.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-HTTP-doc-4000.0.6-3.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-HTTP-prof-4000.0.6-3.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-X11-devel-1.4.5-11.fc12.i586 requires ghc = 0:6.10.3 ghc-X11-devel-1.4.5-11.fc12.i586 requires ghc = 0:6.10.3 ghc-X11-devel-1.4.5-11.fc12.x86_64 requires ghc = 0:6.10.3 ghc-X11-devel-1.4.5-11.fc12.x86_64 requires ghc = 0:6.10.3 ghc-X11-doc-1.4.5-11.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-X11-doc-1.4.5-11.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-X11-prof-1.4.5-11.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-cairo-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-cairo-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-cairo-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-cairo-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-cairo-prof-0.10.1-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-cpphs-devel-1.6-8.fc12.i586 requires ghc = 0:6.10.3 ghc-cpphs-devel-1.6-8.fc12.i586 requires ghc = 0:6.10.3 ghc-cpphs-devel-1.6-8.fc12.x86_64 requires ghc = 0:6.10.3 ghc-cpphs-devel-1.6-8.fc12.x86_64 requires ghc = 0:6.10.3 ghc-cpphs-doc-1.6-8.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-cpphs-doc-1.6-8.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-cpphs-prof-1.6-8.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-editline-devel-0.2.1.0-5.fc12.i686 requires ghc = 0:6.10.3 ghc-editline-devel-0.2.1.0-5.fc12.x86_64 requires ghc = 0:6.10.3 ghc-editline-doc-0.2.1.0-5.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-editline-doc-0.2.1.0-5.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-editline-prof-0.2.1.0-5.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-gconf-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gconf-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gconf-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gconf-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gconf-prof-0.10.1-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-ghc-paths-devel-0.1.0.5-7.fc12.i586 requires ghc = 0:6.10.3 ghc-ghc-paths-devel-0.1.0.5-7.fc12.i586 requires ghc = 0:6.10.3 ghc-ghc-paths-devel-0.1.0.5-7.fc12.x86_64 requires ghc = 0:6.10.3 ghc-ghc-paths-devel-0.1.0.5-7.fc12.x86_64 requires ghc = 0:6.10.3 ghc-ghc-paths-doc-0.1.0.5-7.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-ghc-paths-doc-0.1.0.5-7.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-ghc-paths-prof-0.1.0.5-7.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-gio-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gio-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gio-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gio-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gio-prof-0.10.1-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-glade-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-glade-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-glade-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-glade-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-glade-prof-0.10.1-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-glib-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-glib-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-glib-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-glib-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-glib-prof-0.10.1-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-gstreamer-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gstreamer-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gstreamer-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gstreamer-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gstreamer-prof-0.10.1-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-gtk-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtk-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtk-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gtk-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gtk-prof-0.10.1-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-gtkglext-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtkglext-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtkglext-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gtkglext-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gtkglext-prof-0.10.1-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-gtksourceview2-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtksourceview2-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtksourceview2-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gtksourceview2-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gtksourceview2-prof-0.10.1-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-haskell-src-exts-devel-1.0.1-1.fc12.i586 requires ghc = 0:6.10.3 ghc-haskell-src-exts-devel-1.0.1-1.fc12.i586 requires ghc = 0:6.10.3 ghc-haskell-src-exts-devel-1.0.1-1.fc12.x86_64 requires ghc = 0:6.10.3 ghc-haskell-src-exts-devel-1.0.1-1.fc12.x86_64 requires ghc = 0:6.10.3 ghc-haskell-src-exts-doc-1.0.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-haskell-src-exts-doc-1.0.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-haskell-src-exts-prof-1.0.1-1.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-hscolour-devel-1.13-1.fc12.i586 requires ghc = 0:6.10.3 ghc-hscolour-devel-1.13-1.fc12.i586 requires ghc = 0:6.10.3 ghc-hscolour-devel-1.13-1.fc12.x86_64 requires ghc = 0:6.10.3 ghc-hscolour-devel-1.13-1.fc12.x86_64 requires ghc = 0:6.10.3 ghc-hscolour-doc-1.13-1.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-hscolour-doc-1.13-1.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-hscolour-prof-1.13-1.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-soegtk-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-soegtk-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-soegtk-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-soegtk-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-soegtk-prof-0.10.1-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-svgcairo-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-svgcairo-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-svgcairo-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-svgcairo-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-svgcairo-prof-0.10.1-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-uniplate-devel-1.2.0.3-4.fc12.i586 requires ghc = 0:6.10.3 ghc-uniplate-devel-1.2.0.3-4.fc12.i586 requires ghc = 0:6.10.3 ghc-uniplate-devel-1.2.0.3-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-uniplate-devel-1.2.0.3-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-uniplate-doc-1.2.0.3-4.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-uniplate-doc-1.2.0.3-4.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-uniplate-prof-1.2.0.3-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-utf8-string-devel-0.3.5-2.fc12.i586 requires ghc = 0:6.10.3 ghc-utf8-string-devel-0.3.5-2.fc12.i586 requires ghc = 0:6.10.3 ghc-utf8-string-devel-0.3.5-2.fc12.x86_64 requires ghc = 0:6.10.3 ghc-utf8-string-devel-0.3.5-2.fc12.x86_64 requires ghc = 0:6.10.3 ghc-utf8-string-doc-0.3.5-2.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-utf8-string-doc-0.3.5-2.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-utf8-string-prof-0.3.5-2.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-xmonad-devel-0.8.1-13.fc12.i586 requires ghc = 0:6.10.3 ghc-xmonad-devel-0.8.1-13.fc12.i586 requires ghc = 0:6.10.3 ghc-xmonad-devel-0.8.1-13.fc12.x86_64 requires ghc = 0:6.10.3 ghc-xmonad-devel-0.8.1-13.fc12.x86_64 requires ghc = 0:6.10.3 ghc-xmonad-doc-0.8.1-13.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-xmonad-doc-0.8.1-13.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-xmonad-prof-0.8.1-13.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-zlib-devel-0.5.0.0-9.fc12.i586 requires ghc = 0:6.10.3 ghc-zlib-devel-0.5.0.0-9.fc12.i586 requires ghc = 0:6.10.3 ghc-zlib-devel-0.5.0.0-9.fc12.x86_64 requires ghc = 0:6.10.3 ghc-zlib-devel-0.5.0.0-9.fc12.x86_64 requires ghc = 0:6.10.3 ghc-zlib-doc-0.5.0.0-9.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-zlib-doc-0.5.0.0-9.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-zlib-prof-0.5.0.0-9.fc12.x86_64 requires ghc-prof = 0:6.10.3 gnome-phone-manager-0.65-2.fc12.x86_64 requires libgnome-bluetooth.so.6()(64bit) libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.i586 requires libclutter-cairo-0.8.so.0 libchamplain-0.2.9-1.fc11.x86_64 requires libclutter-cairo-0.8.so.0()(64bit) libchamplain-0.2.9-1.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.x86_64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 libprojectM-1.2.0-9.fc11.x86_64 requires libftgl.so.0()(64bit) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) php-idn-1.2-5.fc12.x86_64 requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.x86_64 requires libclutter-cairo-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.x86_64 requires clutter-cairo pyclutter-gst-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.x86_64 requires python(abi) = 0:2.5 python-tgext-crud-0.2.4-1.fc12.noarch requires python-sprox >= 0:0.5.4.1 qtparted-0.4.5-19.fc11.x86_64 requires libparted-1.8.so.8()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.x86_64 requires libpqxx-2.6.8.so()(64bit) thunderbird-lightning-1.0-0.6.20090513hg.fc12.x86_64 requires thunderbird < 0:3.0-2.3.b4 totem-youtube-2.27.1-2.fc12.x86_64 requires libgdata.so.4()(64bit) trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 Broken deps for ppc ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin R-RScaLAPACK-0.5.1-19.fc11.ppc requires openmpi-libs clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-cairo-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) gauche-gl-0.4.4-4.fc11.ppc requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.ppc requires gauche = 0:0.8.13 gedit-vala-0.4.1-2.fc11.ppc requires libgtksourcecompletion-1.0.so.1 ghc-HTTP-devel-4000.0.6-3.fc12.ppc requires ghc = 0:6.10.3 ghc-HTTP-devel-4000.0.6-3.fc12.ppc requires ghc = 0:6.10.3 ghc-HTTP-doc-4000.0.6-3.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-HTTP-doc-4000.0.6-3.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-HTTP-prof-4000.0.6-3.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-X11-devel-1.4.5-11.fc12.ppc requires ghc = 0:6.10.3 ghc-X11-devel-1.4.5-11.fc12.ppc requires ghc = 0:6.10.3 ghc-X11-doc-1.4.5-11.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-X11-doc-1.4.5-11.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-X11-prof-1.4.5-11.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-cairo-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-cairo-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-cairo-prof-0.10.1-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-cpphs-devel-1.6-8.fc12.ppc requires ghc = 0:6.10.3 ghc-cpphs-devel-1.6-8.fc12.ppc requires ghc = 0:6.10.3 ghc-cpphs-doc-1.6-8.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-cpphs-doc-1.6-8.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-cpphs-prof-1.6-8.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-editline-devel-0.2.1.0-5.fc12.ppc requires ghc = 0:6.10.3 ghc-editline-doc-0.2.1.0-5.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-editline-doc-0.2.1.0-5.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-editline-prof-0.2.1.0-5.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-gconf-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gconf-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gconf-prof-0.10.1-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-ghc-paths-devel-0.1.0.5-7.fc12.ppc requires ghc = 0:6.10.3 ghc-ghc-paths-devel-0.1.0.5-7.fc12.ppc requires ghc = 0:6.10.3 ghc-ghc-paths-doc-0.1.0.5-7.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-ghc-paths-doc-0.1.0.5-7.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-ghc-paths-prof-0.1.0.5-7.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-gio-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gio-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gio-prof-0.10.1-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-glade-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-glade-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-glade-prof-0.10.1-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-glib-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-glib-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-glib-prof-0.10.1-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-gstreamer-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gstreamer-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gstreamer-prof-0.10.1-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-gtk-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gtk-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gtk-prof-0.10.1-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-gtkglext-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gtkglext-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gtkglext-prof-0.10.1-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-gtksourceview2-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gtksourceview2-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gtksourceview2-prof-0.10.1-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-haskell-src-exts-devel-1.0.1-1.fc12.ppc requires ghc = 0:6.10.3 ghc-haskell-src-exts-devel-1.0.1-1.fc12.ppc requires ghc = 0:6.10.3 ghc-haskell-src-exts-doc-1.0.1-1.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-haskell-src-exts-doc-1.0.1-1.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-haskell-src-exts-prof-1.0.1-1.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-hscolour-devel-1.13-1.fc12.ppc requires ghc = 0:6.10.3 ghc-hscolour-devel-1.13-1.fc12.ppc requires ghc = 0:6.10.3 ghc-hscolour-doc-1.13-1.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-hscolour-doc-1.13-1.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-hscolour-prof-1.13-1.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-soegtk-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-soegtk-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-soegtk-prof-0.10.1-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-svgcairo-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-svgcairo-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-svgcairo-prof-0.10.1-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-uniplate-devel-1.2.0.3-4.fc12.ppc requires ghc = 0:6.10.3 ghc-uniplate-devel-1.2.0.3-4.fc12.ppc requires ghc = 0:6.10.3 ghc-uniplate-doc-1.2.0.3-4.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-uniplate-doc-1.2.0.3-4.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-uniplate-prof-1.2.0.3-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-utf8-string-devel-0.3.5-2.fc12.ppc requires ghc = 0:6.10.3 ghc-utf8-string-devel-0.3.5-2.fc12.ppc requires ghc = 0:6.10.3 ghc-utf8-string-doc-0.3.5-2.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-utf8-string-doc-0.3.5-2.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-utf8-string-prof-0.3.5-2.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-xmonad-devel-0.8.1-13.fc12.ppc requires ghc = 0:6.10.3 ghc-xmonad-devel-0.8.1-13.fc12.ppc requires ghc = 0:6.10.3 ghc-xmonad-doc-0.8.1-13.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-xmonad-doc-0.8.1-13.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-xmonad-prof-0.8.1-13.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-zlib-devel-0.5.0.0-9.fc12.ppc requires ghc = 0:6.10.3 ghc-zlib-devel-0.5.0.0-9.fc12.ppc requires ghc = 0:6.10.3 ghc-zlib-doc-0.5.0.0-9.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-zlib-doc-0.5.0.0-9.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-zlib-prof-0.5.0.0-9.fc12.ppc requires ghc-prof = 0:6.10.3 gnome-phone-manager-0.65-2.fc12.ppc requires libgnome-bluetooth.so.6 libchamplain-0.2.9-1.fc11.ppc requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.ppc requires libclutter-cairo-0.8.so.0 libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-cairo-0.8.so.0()(64bit) libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc requires libftgl.so.0 libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) php-idn-1.2-5.fc12.ppc requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.ppc requires libclutter-cairo-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.ppc requires clutter-cairo pyclutter-gst-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-gtk-0.8.so.0 pypar-2.1.0_66-3.fc10.ppc requires libpython2.5.so.1.0 pypar-2.1.0_66-3.fc10.ppc requires python(abi) = 0:2.5 python-tgext-crud-0.2.4-1.fc12.noarch requires python-sprox >= 0:0.5.4.1 qtparted-0.4.5-19.fc11.ppc requires libparted-1.8.so.8 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc requires libpqxx-2.6.8.so thunderbird-lightning-1.0-0.6.20090513hg.fc12.ppc requires thunderbird < 0:3.0-2.3.b4 totem-youtube-2.27.1-2.fc12.ppc requires libgdata.so.4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 Broken deps for ppc64 ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin R-RScaLAPACK-0.5.1-19.fc11.ppc64 requires openmpi-libs clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-cairo-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) gedit-vala-0.4.1-2.fc11.ppc64 requires libgtksourcecompletion-1.0.so.1()(64bit) gnome-phone-manager-0.65-2.fc12.ppc64 requires libgnome-bluetooth.so.6()(64bit) libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-cairo-0.8.so.0()(64bit) libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) php-idn-1.2-5.fc12.ppc64 requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.ppc64 requires libclutter-cairo-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.ppc64 requires clutter-cairo pyclutter-gst-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-gtk-0.8.so.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires libpython2.5.so.1.0()(64bit) pypar-2.1.0_66-3.fc10.ppc64 requires python(abi) = 0:2.5 python-mwlib-0.11.2-2.20090522hg2956.fc12.ppc64 requires LabPlot python-tgext-crud-0.2.4-1.fc12.noarch requires python-sprox >= 0:0.5.4.1 qtparted-0.4.5-19.fc11.ppc64 requires libparted-1.8.so.8()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc64 requires libpqxx-2.6.8.so()(64bit) thunderbird-lightning-1.0-0.6.20090513hg.fc12.ppc64 requires thunderbird < 0:3.0-2.3.b4 totem-youtube-2.27.1-2.fc12.ppc64 requires libgdata.so.4()(64bit) trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 From bruno at wolff.to Wed Jul 22 20:49:16 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 22 Jul 2009 15:49:16 -0500 Subject: No Frozen Rawhide In-Reply-To: <20090722193506.GN3312@hansolo.jdub.homelinux.org> References: <1248217490.2861.2.camel@localhost.localdomain> <200907221057.13253.jarod@redhat.com> <1248278291.2861.20.camel@localhost.localdomain> <200907221236.39006.jarod@redhat.com> <20090722172117.GA27882@wolff.to> <20090722185527.BB36B67B6E@magilla.sf.frob.com> <20090722193506.GN3312@hansolo.jdub.homelinux.org> Message-ID: <20090722204916.GA28385@wolff.to> On Wed, Jul 22, 2009 at 15:35:06 -0400, Josh Boyer wrote: > On Wed, Jul 22, 2009 at 11:55:27AM -0700, Roland McGrath wrote: > >> You actually want overlap for a while so that when rsyncing you can use > >> hardlinks instead of having to redownload files you already have. > >> This is going to be more relevant if koji signing happens and packages don't > >> get different signatures depending on which repo they are in. > > > >That would be nice for updates/updates-testing moves too. > >For that, I've thought it might work to put them all in updates/.all or > >someplace, with updates/... or updates/testing/... being hardlinks to that. > > Releases prior to F-11 wouldn't benefit from that at all, as the RPMs > actually change when going from updates-testing to updates due to being > signed with different keys. I think that it will still help with large enough rpms since rsync will try to use parts of the files if they match names. (There options to try to use files with similar names, but I don't think that is very useful for compressed files since they change almost everywhere.) The resources used are different though (bandwidth vs random disk IO) so it could actually make things worse. From sundaram at fedoraproject.org Wed Jul 22 20:53:37 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 23 Jul 2009 02:23:37 +0530 Subject: rawhide report: 20090722 changes In-Reply-To: <20090722204301.GA18593@releng2.fedora.phx.redhat.com> References: <20090722204301.GA18593@releng2.fedora.phx.redhat.com> Message-ID: <4A677C51.1090502@fedoraproject.org> On 07/23/2009 02:13 AM, Rawhide Report wrote: > pidgin-2.6.0-0.3.20090721.fc12 > ------------------------------ > * Tue Jul 21 2009 Warren Togami 2.6.0-0.1.20090721 > - 2.6.0 snapshot with voice and video support via farsight For which protocols? Rahul From jkeating at redhat.com Wed Jul 22 21:24:58 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 22 Jul 2009 14:24:58 -0700 Subject: No Frozen Rawhide In-Reply-To: <20090722204916.GA28385@wolff.to> References: <1248217490.2861.2.camel@localhost.localdomain> <200907221057.13253.jarod@redhat.com> <1248278291.2861.20.camel@localhost.localdomain> <200907221236.39006.jarod@redhat.com> <20090722172117.GA27882@wolff.to> <20090722185527.BB36B67B6E@magilla.sf.frob.com> <20090722193506.GN3312@hansolo.jdub.homelinux.org> <20090722204916.GA28385@wolff.to> Message-ID: <1248297898.2861.72.camel@localhost.localdomain> On Wed, 2009-07-22 at 15:49 -0500, Bruno Wolff III wrote: > I think that it will still help with large enough rpms since rsync will > try to use parts of the files if they match names. (There options to > try to use files with similar names, but I don't think that is very > useful for compressed files since they change almost everywhere.) > The resources used are different though (bandwidth vs random disk IO) so > it could actually make things worse. The rpms have compressed payloads, but the changes for gpg sigs are just in the small header section so it would save some time. There is a thread going on about this on the mirror list already. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A 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 jarod at redhat.com Wed Jul 22 21:37:18 2009 From: jarod at redhat.com (Jarod Wilson) Date: Wed, 22 Jul 2009 17:37:18 -0400 Subject: No Frozen Rawhide In-Reply-To: <1248286472.2861.70.camel@localhost.localdomain> References: <1248217490.2861.2.camel@localhost.localdomain> <200907221236.39006.jarod@redhat.com> <1248286472.2861.70.camel@localhost.localdomain> Message-ID: <200907221737.18762.jarod@redhat.com> On Wednesday 22 July 2009 14:14:32 Jesse Keating wrote: ... > > > Churn on the mirror configs and the repo files, > > > > That much sort of sucks, yeah, but meh. We change it at least once > > anyway though, going from rawhide to release, so is one more change > > here a huge undertaking? (I ask because have no idea) > > Well every change has potential to break users who have had to do some > customization, and it hurts 3rd party repo setups. It'd be nice to > install a repo config at Alpha and have the paths used remain useful and > valid through the entire release. Would make it easier to attract users > at Alpha/Beta and not suddenly drop them off the face or drag them into > the next rawhide. ... > > Of course, most mirrors are auto-updating via rsync, so perhaps that > > doesn't translate particularly well... But it would also make it easier > > for mirror admins who don't want to mirror anything but the actual > > released releases. > > Yeah, sucks for mirrors. If you don't do hardlinks for a while first, > they'd have to re-sync the entire pile of packages. And if you're going > to do the hardlink dance, might as well use the base location first. > Most of our mirrors tend to use the fedora-enchilada path so we're not > likely to break too many expectations by having something in releases/ > change, any more than by having something in releases/test/ change. ... > This is why we'll set the expectation of the release on having the > Fedora/ path show up. Since that's really what signifies the release, > having gpg signed checksummed isos show up, and torrents getting turned > on, etc.. > > There will have to be some expectation changes, but really the kind of > people digging at raw mirror paths are going to be the kind of people > that can adjust their expectations. All good points... Okay, I think I've been sufficiently convinced that dropping the bits into /pub/fedora/linux/releases/ is just fine after all. Thank you for the enlightenment. ;) -- Jarod Wilson jarod at redhat.com From peter.hutterer at who-t.net Wed Jul 22 21:51:38 2009 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Thu, 23 Jul 2009 07:51:38 +1000 Subject: xextproto and libXext changes - possible build breaks Message-ID: <20090722215137.GA1675@dingo.bne.redhat.com> As part of an upstream cleanup of the xextproto and libXext repositories, some header files that didn't belong to the former were moved to the latter. Along with that, some header files got renamed to match the common naming scheme. The rawhide packages for xorg-x11-proto-devel and libXext now have these cleanup bits. These changes affects most graphics drivers and these drivers will be updated accordingly. The changes should not affect clients directly, but the packaging is affected. Clients may be affected by this change if they include one ore more of the following headers: dmps.h lbxbuf.h lbxbufstr.h lbximage.h MITMisc.h multibuf.h security.h shape.h sync.h Xag.h Xcup.h Xdbe.h Xext.h XEVI.h Xge.h xtestext1.h XShm.h XTest.h XLbx.h The BuildRequires should be adjusted to libXext-devel. In the case of XTest.h the new BuildRequires is libXtst-devel. If your package has build errors, please contact me off-list and we can sort it out. Cheers, Peter From hughsient at gmail.com Wed Jul 22 22:17:29 2009 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 22 Jul 2009 23:17:29 +0100 Subject: Batteries and Suspend Test day summary In-Reply-To: <20090722190553.GQ24960@edu.joroinen.fi> References: <1248279581.1693.9.camel@planemask> <20090722190553.GQ24960@edu.joroinen.fi> Message-ID: <15e53e180907221517g225d70c3te68590963798d59f@mail.gmail.com> 2009/7/22 Pasi K?rkk?inen : > He's been trying to identify the problem with powertop, disable services > etc, but hasn't been able to match the battery life of Windows. > Have you guys thought about this? Depends on the hardware. If it's friendly graphics and intel networking, we should compare quite well. If it's a macbook with nvidia graphics and broadcom networking then all bets are off; as we just don't know how to power down the hardware when idle. Richard. From bill at bfccomputing.com Wed Jul 22 22:24:40 2009 From: bill at bfccomputing.com (Bill McGonigle) Date: Wed, 22 Jul 2009 18:24:40 -0400 Subject: No Frozen Rawhide In-Reply-To: <20090722163932.GA24564@wolff.to> References: <1248217490.2861.2.camel@localhost.localdomain> <200907221057.13253.jarod@redhat.com> <20090722163932.GA24564@wolff.to> Message-ID: <4A6791A8.6000601@bfccomputing.com> On 07/22/2009 12:39 PM, Bruno Wolff III wrote: > I think the confusion for normal users will be minimal, because normal users > won't be looking at the raw repos in any case. There's a class of users between active developers/QA folk and people who only use GUI package managers who are apt to go to a download site looking for RPM's. That said, I think a succinct README ("This is pre-release code, there be goblins here") in the right directory that Apache auto-displays for index listings would be sufficient to warn off those users. Otherwise, _somebody_ is going to say, "oh, cool, 12 is out, I missed that." -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/ Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: bill at bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf From stickster at gmail.com Wed Jul 22 23:51:10 2009 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 22 Jul 2009 19:51:10 -0400 Subject: No Frozen Rawhide In-Reply-To: <4A6791A8.6000601@bfccomputing.com> References: <1248217490.2861.2.camel@localhost.localdomain> <200907221057.13253.jarod@redhat.com> <20090722163932.GA24564@wolff.to> <4A6791A8.6000601@bfccomputing.com> Message-ID: <20090722235110.GZ21921@localhost.localdomain> On Wed, Jul 22, 2009 at 06:24:40PM -0400, Bill McGonigle wrote: > On 07/22/2009 12:39 PM, Bruno Wolff III wrote: > > I think the confusion for normal users will be minimal, because normal users > > won't be looking at the raw repos in any case. > > There's a class of users between active developers/QA folk and people > who only use GUI package managers who are apt to go to a download site > looking for RPM's. > > That said, I think a succinct README ("This is pre-release code, there > be goblins here") in the right directory that Apache auto-displays for > index listings would be sufficient to warn off those users. Otherwise, > _somebody_ is going to say, "oh, cool, 12 is out, I missed that." This would be hard to enforce with mirrors, some of which may not use those automatic features. Any user trying to install from Rawhide, though, receives the famous betanag up front, which basically tells them "I'm a pre-release, are you sure you want to install me?" -- 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 MathStuf at gmail.com Thu Jul 23 00:43:17 2009 From: MathStuf at gmail.com (Ben Boeckel) Date: Wed, 22 Jul 2009 20:43:17 -0400 Subject: No Frozen Rawhide References: <1248217490.2861.2.camel@localhost.localdomain> <200907221057.13253.jarod@redhat.com> <20090722163932.GA24564@wolff.to> <4A6791A8.6000601@bfccomputing.com> <20090722235110.GZ21921@localhost.localdomain> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul W. Frields wrote: > On Wed, Jul 22, 2009 at 06:24:40PM -0400, Bill McGonigle wrote: >> On 07/22/2009 12:39 PM, Bruno Wolff III wrote: >> > I think the confusion for normal users will be minimal, because normal users >> > won't be looking at the raw repos in any case. >> >> There's a class of users between active developers/QA folk and people >> who only use GUI package managers who are apt to go to a download site >> looking for RPM's. >> >> That said, I think a succinct README ("This is pre-release code, there >> be goblins here") in the right directory that Apache auto- displays for >> index listings would be sufficient to warn off those users. Otherwise, >> _somebody_ is going to say, "oh, cool, 12 is out, I missed that." > > This would be hard to enforce with mirrors, some of which may not use > those automatic features. Any user trying to install from Rawhide, > though, receives the famous betanag up front, which basically tells > them "I'm a pre-release, are you sure you want to install me?" > Should we also have warnings in preupgrade? Or is this not how it works? I haven't used it myself yet. Also, should yum repo configs grow a "eatsbabies=1" (or warnonenable to be more descriptive, but I'm partial to the eating babies or a "here-there-be-dragons" option) for rawhide to have yum confirm when using --enablerepo=rawhide on a non- rawhide install? This may be good anyways since cherry picking from rawhide has other problems (such as xz payload this time, libssl/gcc/hash upgrades before) that may drag in the world as dependencies. - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpnsiUACgkQiPi+MRHG3qRfIgCfVPhT45wJ4hXdbsciLUl7w8tp VX0AoJFxiaOAZLfQqlsSF/HeZ+yyH5YM =N52C -----END PGP SIGNATURE----- From braden at endoframe.com Thu Jul 23 06:38:40 2009 From: braden at endoframe.com (Braden McDaniel) Date: Thu, 23 Jul 2009 02:38:40 -0400 Subject: xulrunner-1.9.1.1-1.fc11.x86_64 update pulls in i586 packages Message-ID: <1248331120.4653.13417.camel@localhost> Is this as it should be? Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Updating: xulrunner x86_64 1.9.1.1-1.fc11 updates 9.5 M Installing for dependencies: GConf2 i586 2.26.2-1.fc11 updates 1.7 M ORBit2 i586 2.14.17-1.fc11 fedora 186 k PolicyKit i586 0.9-6.fc11 fedora 165 k alsa-lib i586 1.0.20-1.fc11 fedora 419 k atk i586 1.25.2-2.fc11 fedora 222 k audit-libs i586 1.7.13-1.fc11 updates 83 k avahi i586 0.6.25-3.fc11 updates 292 k avahi-glib i586 0.6.25-3.fc11 updates 19 k bzip2-libs i586 1.0.5-5.fc11 fedora 39 k cairo i586 1.8.8-1.fc11 updates 514 k cracklib i586 2.8.13-4 fedora 50 k cups-libs i586 1:1.4-0.b2.18.fc11 fedora 341 k cyrus-sasl-lib i586 2.1.22-22.fc11 fedora 145 k db4 i586 4.7.25-11.fc11 fedora 669 k dbus-glib i586 0.80-2.fc11 fedora 178 k dbus-libs i586 1:1.2.12-2.fc11 updates 132 k e2fsprogs-libs i586 1.41.4-10.fc11 fedora 154 k expat i586 2.0.1-6 fedora 86 k fontconfig i586 2.6.99.behdad.20090508-1.fc11 fedora 203 k freetype i586 2.3.9-3.fc11 fedora 388 k gamin i586 0.1.10-4.fc11 fedora 134 k glib2 i586 2.20.4-1.fc11 updates 1.5 M glibc i686 2.10.1-2 fedora 5.8 M gnome-vfs2 i586 2.24.1-2.fc11 fedora 947 k gnutls i586 2.6.6-1.fc11 fedora 379 k gtk2 i586 2.16.2-1.fc11 updates 4.3 M hal-libs i586 0.5.12-26.20090226git.fc11 fedora 70 k jasper-libs i586 1.900.1-10.fc11 fedora 155 k keyutils-libs i586 1.2-5.fc11 fedora 19 k krb5-libs i586 1.6.3-20.fc11 fedora 705 k libICE i586 1.0.4-7.fc11 fedora 55 k libIDL i586 0.8.13-1.fc11 fedora 89 k libSM i586 1.1.0-4.fc11 fedora 27 k libX11 i586 1.2.1-2.fc11 updates 1.0 M libXau i586 1.0.4-5.fc11 fedora 21 k libXcomposite i586 0.4.0-7.fc11 fedora 16 k libXcursor i586 1.1.9-4.fc11 fedora 30 k libXdamage i586 1.1.1-6.fc11 fedora 12 k libXext i586 1.0.99.1-2.fc11 fedora 35 k libXfixes i586 4.0.3-5.fc11 fedora 16 k libXft i586 2.1.13-2.fc11 fedora 52 k libXi i586 1.2.1-1.fc11 fedora 32 k libXinerama i586 1.0.3-4.fc11 fedora 14 k libXrandr i586 1.2.99.4-3.fc11 fedora 31 k libXrender i586 0.9.4-5.fc11 fedora 30 k libXt i586 1.0.5-2.fc11 fedora 182 k libacl i586 2.2.47-4.fc11 fedora 24 k libattr i586 2.4.43-3.fc11 fedora 15 k libbonobo i586 2.24.1-1.fc11 fedora 487 k libcap i586 2.16-4.fc11.1 updates 32 k libdaemon i586 0.13-2.fc11 fedora 28 k libgcc i586 4.4.0-4 fedora 94 k libgcrypt i586 1.4.4-6.fc11 updates 234 k libgnome i586 2.26.0-1.fc11 fedora 732 k libgpg-error i586 1.6-3 fedora 66 k libjpeg i586 6b-45.fc11 fedora 145 k libpng i586 2:1.2.37-1.fc11 updates 256 k libselinux i586 2.0.80-1.fc11 fedora 107 k libstdc++ i586 4.4.0-4 fedora 323 k libtasn1 i586 1.8-2.fc11 fedora 302 k libthai i586 0.1.9-7.fc11 fedora 189 k libtiff i586 3.8.2-14.fc11 updates 309 k libxcb i586 1.2-4.fc11 updates 131 k libxml2 i586 2.7.3-2.fc11 fedora 855 k ncurses-libs i586 5.7-2.20090207.fc11 fedora 334 k nspr i586 4.8-1.fc11 updates 123 k nss i586 3.12.3.99.3-2.11.3.fc11 updates 1.0 M nss-softokn-freebl i586 3.12.3.99.3-2.11.3.fc11 updates 136 k openldap i586 2.4.15-3.fc11 fedora 338 k openssl i686 0.9.8k-5.fc11 updates 1.4 M pam i586 1.0.91-6.fc11 fedora 767 k pango i586 1.24.4-1.fc11 updates 400 k pixman i586 0.14.0-2.fc11 fedora 123 k popt i586 1.13-5.fc11 fedora 41 k python-libs i586 2.6-9.fc11 updates 663 k readline i586 5.2-14.fc11 fedora 187 k sqlite i586 3.6.12-3.fc11 fedora 322 k xulrunner i586 1.9.1-0.20.beta4.fc11 fedora 10 M zlib i586 1.2.3-22.fc11 fedora 75 k Updating for dependencies: cairo x86_64 1.8.8-1.fc11 updates 506 k cairo-devel x86_64 1.8.8-1.fc11 updates 185 k dbus x86_64 1:1.2.12-2.fc11 updates 234 k dbus-devel x86_64 1:1.2.12-2.fc11 updates 45 k dbus-libs x86_64 1:1.2.12-2.fc11 updates 133 k dbus-x11 x86_64 1:1.2.12-2.fc11 updates 39 k epiphany x86_64 2.26.3-1.fc11 updates 4.9 M epiphany-extensions x86_64 2.26.1-4.fc11 updates 1.0 M glib2 x86_64 2.20.4-1.fc11 updates 1.6 M glib2-devel x86_64 2.20.4-1.fc11 updates 1.3 M pango x86_64 1.24.4-1.fc11 updates 407 k pango-devel x86_64 1.24.4-1.fc11 updates 321 k xulrunner-devel x86_64 1.9.1.1-1.fc11 updates 3.9 M Transaction Summary ================================================================================ Install 79 Package(s) Update 14 Package(s) Remove 0 Package(s) -- Braden McDaniel From mschwendt at gmail.com Thu Jul 23 07:27:54 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 23 Jul 2009 09:27:54 +0200 Subject: Fw: [Fedora Update] [comment] python-repoze-what-1.0.8-1.fc11 Message-ID: <20090723092754.2db170ab@faldor> Why would you push a broken package (-1) that has also been in the broken deps reports for over a month? [...] Begin forwarded message: The following comment has been added to the python-repoze-what-1.0.8-1.fc11 update: lmacken - 2009-07-22 21:01:34 (karma: 0) This update has been submitted for stable To reply to this comment, please visit the URL at the bottom of this mail ================================================================================ python-repoze-what-1.0.8-1.fc11 ================================================================================ Update ID: FEDORA-2009-5742 Release: Fedora 11 Status: testing Type: newpackage Karma: -1 Request: stable Bugs: 476789 - Review Request: python-repoze-what - Authorization for : WSGI applications Submitter: lmacken Submitted: 2009-05-29 21:00:41 Comments: lmacken - 2009-05-29 21:00:46 (karma 0) This update has been submitted for testing bodhi - 2009-06-02 14:21:44 (karma 0) This update has been pushed to testing mschwendt - 2009-06-02 15:41:32 (karma -1) unresolved deps: python-repoze-what-1.0.8 lmacken - 2009-07-22 21:01:34 (karma 0) This update has been submitted for stable http://admin.fedoraproject.org/updates/F11/FEDORA-2009-5742 From mschwendt at gmail.com Thu Jul 23 09:36:26 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 23 Jul 2009 09:36:26 -0000 Subject: Broken dependencies in Fedora 11 - 2009-07-23 Message-ID: <20090723093626.9213.8623@faldor.intranet> ====================================================================== The results in this summary consider Test Updates! ====================================================================== Summary of broken packages (by src.rpm name): beagle CodeAnalyst-gui epiphany gauche-gl gauche-gtk libguestfs mono-tools pcmanx-gtk2 ppl python-repoze-what tomboy wine ====================================================================== Broken packages in fedora-11-i386: CodeAnalyst-gui-2.8.38-11.fc11.i586 requires libbfd-2.19.51.0.2-17.fc11.so gauche-gl-0.4.4-4.fc11.i586 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.i586 requires gauche = 0:0.8.13 pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.i586 requires xulrunner = 0:1.9.1 ====================================================================== Broken packages in fedora-11-ppc: gauche-gl-0.4.4-4.fc11.ppc requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.ppc requires gauche = 0:0.8.13 pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.ppc requires xulrunner = 0:1.9.1 ====================================================================== Broken packages in fedora-11-ppc64: pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.ppc64 requires xulrunner = 0:1.9.1 ====================================================================== Broken packages in fedora-11-x86_64: CodeAnalyst-gui-2.8.38-11.fc11.x86_64 requires libbfd-2.19.51.0.2-17.fc11.so()(64bit) gauche-gl-0.4.4-4.fc11.x86_64 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.x86_64 requires gauche = 0:0.8.13 pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.x86_64 requires xulrunner = 0:1.9.1 ====================================================================== Broken packages in fedora-updates-11-i386: epiphany-2.26.3-1.fc11.i586 requires gecko-libs = 0:1.9.1 epiphany-devel-2.26.3-1.fc11.i586 requires gecko-devel = 0:1.9.1 ppl-swiprolog-0.10.2-3.fc11.i586 requires libpl.so.5.7.6 ppl-yap-0.10.2-3.fc11.i586 requires libYap.so virt-df2-1.0.58-2.fc11.i586 requires libguestfs = 0:1.0.58-2.fc11 ====================================================================== Broken packages in fedora-updates-11-ppc: epiphany-2.26.3-1.fc11.ppc requires gecko-libs = 0:1.9.1 epiphany-devel-2.26.3-1.fc11.ppc requires gecko-devel = 0:1.9.1 epiphany-devel-2.26.3-1.fc11.ppc64 requires gecko-devel = 0:1.9.1 ppl-swiprolog-0.10.2-3.fc11.ppc requires libpl.so.5.7.6 ppl-yap-0.10.2-3.fc11.ppc requires libYap.so virt-df2-1.0.58-2.fc11.ppc requires libguestfs = 0:1.0.58-2.fc11 ====================================================================== Broken packages in fedora-updates-11-ppc64: beagle-0.3.9-9.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0 beagle-0.3.9-9.fc11.ppc64 requires mono(gsf-sharp) = 0:0.0.0.7 beagle-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 beagle-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 beagle-0.3.9-9.fc11.ppc64 requires mono(taglib-sharp) = 0:2.0.3.2 beagle-evolution-0.3.9-9.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0 beagle-evolution-0.3.9-9.fc11.ppc64 requires mono(evolution-sharp) = 0:5.0.0.0 beagle-gnome-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 beagle-gnome-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 beagle-thunderbird-0.3.9-9.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0 epiphany-2.26.3-1.fc11.ppc64 requires gecko-libs = 0:1.9.1 epiphany-devel-2.26.3-1.fc11.ppc64 requires gecko-devel = 0:1.9.1 ppl-swiprolog-0.10.2-3.fc11.ppc64 requires libpl.so.5.7.6()(64bit) ppl-yap-0.10.2-3.fc11.ppc64 requires libYap.so()(64bit) tomboy-0.14.3-1.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(Mono.Addins.Setup) = 0:0.4.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(gnome-panel-sharp) = 0:2.24.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(Mono.Addins) = 0:0.4.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(Mono.Addins.Gui) = 0:0.4.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 virt-df2-1.0.58-2.fc11.ppc64 requires libguestfs = 0:1.0.58-2.fc11 ====================================================================== Broken packages in fedora-updates-11-x86_64: epiphany-2.26.3-1.fc11.x86_64 requires gecko-libs = 0:1.9.1 epiphany-devel-2.26.3-1.fc11.i586 requires gecko-devel = 0:1.9.1 epiphany-devel-2.26.3-1.fc11.x86_64 requires gecko-devel = 0:1.9.1 ppl-swiprolog-0.10.2-3.fc11.x86_64 requires libpl.so.5.7.6()(64bit) ppl-yap-0.10.2-3.fc11.x86_64 requires libYap.so()(64bit) virt-df2-1.0.58-2.fc11.x86_64 requires libguestfs = 0:1.0.58-2.fc11 wine-esd-1.1.23-1.fc11.i586 requires wine-core = 0:1.1.23-1.fc11 wine-jack-1.1.23-1.fc11.i586 requires wine-core = 0:1.1.23-1.fc11 wine-nas-1.1.23-1.fc11.i586 requires wine-core = 0:1.1.23-1.fc11 ====================================================================== Broken packages in fedora-updates-testing-11-i386: python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 ====================================================================== Broken packages in fedora-updates-testing-11-ppc: python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 ====================================================================== Broken packages in fedora-updates-testing-11-ppc64: mono-tools-2.4-12.fc11.ppc64 requires mono(gtkhtml-sharp) >= 0:3.0 python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 ====================================================================== Broken packages in fedora-updates-testing-11-x86_64: python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 From mschwendt at gmail.com Thu Jul 23 09:37:01 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 23 Jul 2009 09:37:01 -0000 Subject: Broken dependencies in Fedora 10 - 2009-07-23 Message-ID: <20090723093701.9219.9946@faldor.intranet> ====================================================================== The results in this summary consider Test Updates! ====================================================================== Summary of broken packages (by src.rpm name): db4o gadget gauche-gl gauche-gtk libvirt-qpid llvm php ppl python-morbid python-repoze-what trac-customfieldadmin-plugin wine ====================================================================== Broken packages in fedora-10-i386: gauche-gl-0.4.4-3.fc9.i386 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-17.fc9.i386 requires gauche = 0:0.8.13 ====================================================================== Broken packages in fedora-10-ppc: db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607 gauche-gl-0.4.4-3.fc9.ppc requires gauche = 0:0.8.13 gauche-gtk-0.4.1-17.fc9.ppc requires gauche = 0:0.8.13 llvm-devel-2.3-2.fc10.ppc64 requires llvm = 0:2.3-2.fc10 php-devel-5.2.6-5.ppc64 requires php = 0:5.2.6-5 ====================================================================== Broken packages in fedora-10-x86_64: gauche-gl-0.4.4-3.fc9.x86_64 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-17.fc9.x86_64 requires gauche = 0:0.8.13 php-devel-5.2.6-5.i386 requires php = 0:5.2.6-5 ====================================================================== Broken packages in fedora-updates-10-i386: libvirt-qpid-0.2.16-2.fc10.i386 requires libqpidclient.so.0 libvirt-qpid-0.2.16-2.fc10.i386 requires libqpidcommon.so.0 libvirt-qpid-0.2.16-2.fc10.i386 requires libqmfagent.so.0 ppl-swiprolog-0.10.2-3.fc10.i386 requires libpl.so.5.6.60 ppl-yap-0.10.2-3.fc10.i386 requires libYap.so python-morbid-0.8.6.1-1.fc10.noarch requires python-stomper trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin ====================================================================== Broken packages in fedora-updates-10-ppc: libvirt-qpid-0.2.16-2.fc10.ppc requires libqpidclient.so.0 libvirt-qpid-0.2.16-2.fc10.ppc requires libqpidcommon.so.0 libvirt-qpid-0.2.16-2.fc10.ppc requires libqmfagent.so.0 ppl-swiprolog-0.10.2-3.fc10.ppc requires libpl.so.5.6.60 ppl-yap-0.10.2-3.fc10.ppc requires libYap.so python-morbid-0.8.6.1-1.fc10.noarch requires python-stomper trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin ====================================================================== Broken packages in fedora-updates-10-ppc64: gadget-0.0.3-2.fc10.noarch requires ejabberd libvirt-qpid-0.2.16-2.fc10.ppc64 requires libqmfagent.so.0()(64bit) libvirt-qpid-0.2.16-2.fc10.ppc64 requires libqpidcommon.so.0()(64bit) libvirt-qpid-0.2.16-2.fc10.ppc64 requires libqpidclient.so.0()(64bit) ppl-swiprolog-0.10.2-3.fc10.ppc64 requires libpl.so.5.6.60()(64bit) ppl-yap-0.10.2-3.fc10.ppc64 requires libYap.so()(64bit) python-morbid-0.8.6.1-1.fc10.noarch requires python-stomper trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin ====================================================================== Broken packages in fedora-updates-10-x86_64: libvirt-qpid-0.2.16-2.fc10.x86_64 requires libqmfagent.so.0()(64bit) libvirt-qpid-0.2.16-2.fc10.x86_64 requires libqpidcommon.so.0()(64bit) libvirt-qpid-0.2.16-2.fc10.x86_64 requires libqpidclient.so.0()(64bit) ppl-swiprolog-0.10.2-3.fc10.x86_64 requires libpl.so.5.6.60()(64bit) ppl-yap-0.10.2-3.fc10.x86_64 requires libYap.so()(64bit) python-morbid-0.8.6.1-1.fc10.noarch requires python-stomper trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin wine-esd-1.1.23-1.fc10.i386 requires wine-core = 0:1.1.23-1.fc10 wine-jack-1.1.23-1.fc10.i386 requires wine-core = 0:1.1.23-1.fc10 wine-nas-1.1.23-1.fc10.i386 requires wine-core = 0:1.1.23-1.fc10 ====================================================================== Broken packages in fedora-updates-testing-10-i386: python-repoze-what-docs-1.0.8-1.fc10.noarch requires python-repoze-what-1.0.8 ====================================================================== Broken packages in fedora-updates-testing-10-ppc: python-repoze-what-docs-1.0.8-1.fc10.noarch requires python-repoze-what-1.0.8 ====================================================================== Broken packages in fedora-updates-testing-10-ppc64: python-repoze-what-docs-1.0.8-1.fc10.noarch requires python-repoze-what-1.0.8 ====================================================================== Broken packages in fedora-updates-testing-10-x86_64: python-repoze-what-docs-1.0.8-1.fc10.noarch requires python-repoze-what-1.0.8 From mschwendt at gmail.com Thu Jul 23 10:14:24 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 23 Jul 2009 12:14:24 +0200 Subject: Broken dependencies in Fedora 10 - 2009-07-23 In-Reply-To: <20090723093701.9219.9946@faldor.intranet> References: <20090723093701.9219.9946@faldor.intranet> Message-ID: <20090723121424.20b26302@faldor> Similar to how I've done it with Fedora 9, for some time this will be the last report for Fedora 10. From notting at redhat.com Thu Jul 23 13:18:03 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 23 Jul 2009 09:18:03 -0400 Subject: Mass rebuild slightly delayed... Message-ID: <20090723131738.GA32511@nostromo.devel.redhat.com> ... as we sort through some toolchain issues. It will start as soon as reasonably possible. Bill _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From mtasaka at ioa.s.u-tokyo.ac.jp Thu Jul 23 14:26:59 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 23 Jul 2009 23:26:59 +0900 Subject: xulrunner-1.9.1.1-1.fc11.x86_64 update pulls in i586 packages In-Reply-To: <1248331120.4653.13417.camel@localhost> References: <1248331120.4653.13417.camel@localhost> Message-ID: <4A687333.60909@ioa.s.u-tokyo.ac.jp> Braden McDaniel wrote, at 07/23/2009 03:38 PM +9:00: > Is this as it should be? > > Dependencies Resolved > > ================================================================================ > Package Arch Version Repository > Size > ================================================================================ > Updating: > xulrunner x86_64 1.9.1.1-1.fc11 updates 9.5 M > Installing for dependencies: > GConf2 i586 2.26.2-1.fc11 updates 1.7 M > ORBit2 i586 2.14.17-1.fc11 fedora 186 k > xulrunner i586 1.9.1-0.20.beta4.fc11 fedora 10 M > zlib i586 1.2.3-22.fc11 fedora 75 k > Updating for dependencies: > epiphany x86_64 2.26.3-1.fc11 updates 4.9 M > epiphany-extensions x86_64 2.26.1-4.fc11 updates 1.0 M > glib2 x86_64 2.20.4-1.fc11 updates 1.6 M > glib2-devel x86_64 2.20.4-1.fc11 updates 1.3 M > pango x86_64 1.24.4-1.fc11 updates 407 k > pango-devel x86_64 1.24.4-1.fc11 updates 321 k > xulrunner-devel x86_64 1.9.1.1-1.fc11 updates 3.9 M rel-eng team is now working on this: https://fedorahosted.org/rel-eng/ticket/2008 Regards, Mamoru From Axel.Thimm at ATrpms.net Thu Jul 23 15:29:22 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 23 Jul 2009 18:29:22 +0300 Subject: Mass rebuild for Fedora 12 In-Reply-To: <20090720201439.GA11912@nostromo.devel.redhat.com> References: <20090720201439.GA11912@nostromo.devel.redhat.com> Message-ID: <20090723152922.GA20343@victor.nirvana> Hi, On Mon, Jul 20, 2009 at 04:14:39PM -0400, Bill Nottingham wrote: > Fedora Release Enginerering is going to be starting a mass rebuild this > Thursday, July 28th, for the following Fedora 12 features: > - XZ RPM Payloads > - x86 Architecture Support > > Just as in the Fedora 11 mass rebuild, if you'd like to opt out for > your packages, check a file into your package's devel/ branch, named > 'noautobuild'. This file should contain a short rationale of why you > wish to do the build yourself. Note that if you do not do a rebuild > during the timeframe before Alpha, one will be done regardless of > the presence of this file. > > Also note that delta RPMS will be disabled in rawhide for the duration > of this mass rebuild; delta rpms across payload format changes in > RPM are not useful. > > For more information, see: > https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild if I touch a package today, would it need to be rebuilt, and if not, would I need to create the noautobuild file? Thanks! -- 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 jakub at redhat.com Thu Jul 23 15:33:25 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 23 Jul 2009 17:33:25 +0200 Subject: Mass rebuild for Fedora 12 In-Reply-To: <20090723152922.GA20343@victor.nirvana> References: <20090720201439.GA11912@nostromo.devel.redhat.com> <20090723152922.GA20343@victor.nirvana> Message-ID: <20090723153325.GU4462@tyan-ft48-01.lab.bos.redhat.com> On Thu, Jul 23, 2009 at 06:29:22PM +0300, Axel Thimm wrote: > > For more information, see: > > https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild > > if I touch a package today, would it need to be rebuilt, Yes. Although we have the right binutils in the repo for an hour or three, the right gcc isn't there yet. Jakub From notting at redhat.com Thu Jul 23 15:33:46 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 23 Jul 2009 11:33:46 -0400 Subject: Mass rebuild for Fedora 12 In-Reply-To: <20090723152922.GA20343@victor.nirvana> References: <20090720201439.GA11912@nostromo.devel.redhat.com> <20090723152922.GA20343@victor.nirvana> Message-ID: <20090723153345.GA892@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > if I touch a package today, would it need to be rebuilt, and if not, > would I need to create the noautobuild file? Any package that builds after redhat-rpm-config-9.0.3-12.fc12 is added to the buildroot is OK. This has not happened yet. (waiting on a newRepo task.) Bill From braden at endoframe.com Thu Jul 23 15:39:24 2009 From: braden at endoframe.com (Braden McDaniel) Date: Thu, 23 Jul 2009 11:39:24 -0400 Subject: xulrunner-1.9.1.1-1.fc11.x86_64 update pulls in i586 packages In-Reply-To: <4A687333.60909@ioa.s.u-tokyo.ac.jp> References: <1248331120.4653.13417.camel@localhost> <4A687333.60909@ioa.s.u-tokyo.ac.jp> Message-ID: <1248363564.4653.14513.camel@localhost> On Thu, 2009-07-23 at 23:26 +0900, Mamoru Tasaka wrote: [snip] > rel-eng team is now working on this: > https://fedorahosted.org/rel-eng/ticket/2008 Er... So why did a missing update result in pulling down i586 packages rather than a dependency check failure? -- Braden McDaniel From skvidal at fedoraproject.org Thu Jul 23 15:41:26 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 23 Jul 2009 11:41:26 -0400 (EDT) Subject: xulrunner-1.9.1.1-1.fc11.x86_64 update pulls in i586 packages In-Reply-To: <1248363564.4653.14513.camel@localhost> References: <1248331120.4653.13417.camel@localhost> <4A687333.60909@ioa.s.u-tokyo.ac.jp> <1248363564.4653.14513.camel@localhost> Message-ID: On Thu, 23 Jul 2009, Braden McDaniel wrote: > On Thu, 2009-07-23 at 23:26 +0900, Mamoru Tasaka wrote: > > [snip] > >> rel-eng team is now working on this: >> https://fedorahosted.org/rel-eng/ticket/2008 > > Er... So why did a missing update result in pulling down i586 packages > rather than a dependency check failure? > if I had to guess it worked like this: the dep was provided by two pkgs - the i586 one and the x86_64 one. but the dep itself was not arch-specific. So yum said: I can only find an i586 pkg providing this, so I'll install that. Normally yum would say: I have an i586 and an x86_64 pkg - x86_64 is better if: (the requiring package is also x86_64 or if the system is an x86_64) but in this case it could not and it satisfied the dep however it could. -sv From jakub at redhat.com Thu Jul 23 15:35:40 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 23 Jul 2009 17:35:40 +0200 Subject: Mass rebuild for Fedora 12 In-Reply-To: <20090723153345.GA892@nostromo.devel.redhat.com> References: <20090720201439.GA11912@nostromo.devel.redhat.com> <20090723152922.GA20343@victor.nirvana> <20090723153345.GA892@nostromo.devel.redhat.com> Message-ID: <20090723153540.GV4462@tyan-ft48-01.lab.bos.redhat.com> On Thu, Jul 23, 2009 at 11:33:46AM -0400, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at ATrpms.net) said: > > if I touch a package today, would it need to be rebuilt, and if not, > > would I need to create the noautobuild file? > > Any package that builds after redhat-rpm-config-9.0.3-12.fc12 is added > to the buildroot is OK. This has not happened yet. (waiting on a newRepo > task.) And gcc-4.4.1-2. Jakub From braden at endoframe.com Thu Jul 23 15:55:57 2009 From: braden at endoframe.com (Braden McDaniel) Date: Thu, 23 Jul 2009 11:55:57 -0400 Subject: xulrunner-1.9.1.1-1.fc11.x86_64 update pulls in i586 packages In-Reply-To: References: <1248331120.4653.13417.camel@localhost> <4A687333.60909@ioa.s.u-tokyo.ac.jp> <1248363564.4653.14513.camel@localhost> Message-ID: <1248364557.4653.14575.camel@localhost> On Thu, 2009-07-23 at 11:41 -0400, Seth Vidal wrote: > > On Thu, 23 Jul 2009, Braden McDaniel wrote: > > > On Thu, 2009-07-23 at 23:26 +0900, Mamoru Tasaka wrote: > > > > [snip] > > > >> rel-eng team is now working on this: > >> https://fedorahosted.org/rel-eng/ticket/2008 > > > > Er... So why did a missing update result in pulling down i586 packages > > rather than a dependency check failure? > > > > if I had to guess it worked like this: > > the dep was provided by two pkgs - the i586 one and the x86_64 one. > > but the dep itself was not arch-specific. > > So yum said: I can only find an i586 pkg providing this, so I'll install > that. > > Normally yum would say: I have an i586 and an x86_64 pkg - x86_64 is > better if: (the requiring package is also x86_64 or if the system is an > x86_64) > > but in this case it could not and it satisfied the dep however it could. Is the problem that the gecko-libs dependency is not arch-specific? How do we fix that? -- Braden McDaniel From skvidal at fedoraproject.org Thu Jul 23 15:59:55 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 23 Jul 2009 11:59:55 -0400 (EDT) Subject: xulrunner-1.9.1.1-1.fc11.x86_64 update pulls in i586 packages In-Reply-To: <1248364557.4653.14575.camel@localhost> References: <1248331120.4653.13417.camel@localhost> <4A687333.60909@ioa.s.u-tokyo.ac.jp> <1248363564.4653.14513.camel@localhost> <1248364557.4653.14575.camel@localhost> Message-ID: On Thu, 23 Jul 2009, Braden McDaniel wrote: > > Is the problem that the gecko-libs dependency is not arch-specific? Not necessarily. > How do we fix that? %{__isa} istr. -sv From mschwendt at gmail.com Thu Jul 23 16:12:00 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 23 Jul 2009 18:12:00 +0200 Subject: rpms/ghc-editline/F-11 ghc-editline.spec,1.3,1.4 In-Reply-To: <20090723155139.B46B611C0093@cvs1.fedora.phx.redhat.com> References: <20090723155139.B46B611C0093@cvs1.fedora.phx.redhat.com> Message-ID: <20090723181200.7a833ecd@faldor> On Thu, 23 Jul 2009 15:51:39 +0000 (UTC), Jochen wrote: > Author: s4504kr > > Update of /cvs/pkgs/rpms/ghc-editline/F-11 > Requires(pos): ghc = %{ghc_version} ^^^ Typo! From mschwendt at gmail.com Thu Jul 23 16:13:28 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 23 Jul 2009 18:13:28 +0200 Subject: xulrunner-1.9.1.1-1.fc11.x86_64 update pulls in i586 packages In-Reply-To: <1248364557.4653.14575.camel@localhost> References: <1248331120.4653.13417.camel@localhost> <4A687333.60909@ioa.s.u-tokyo.ac.jp> <1248363564.4653.14513.camel@localhost> <1248364557.4653.14575.camel@localhost> Message-ID: <20090723181328.161e9bb5@faldor> On Thu, 23 Jul 2009 11:55:57 -0400, Braden wrote: > Is the problem that the gecko-libs dependency is not arch-specific? How > do we fix that? You could make it arch-specific by depending on gecko-libs%{?_isa} = ... From rjones at redhat.com Thu Jul 23 16:12:56 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 23 Jul 2009 17:12:56 +0100 Subject: Broken dependencies in Fedora 11 - 2009-07-23 In-Reply-To: <20090723093626.9213.8623@faldor.intranet> References: <20090723093626.9213.8623@faldor.intranet> Message-ID: <20090723161203.GA3855@amd.home.annexia.org> On Thu, Jul 23, 2009 at 09:36:26AM -0000, Michael Schwendt wrote: > libguestfs As for last time, still waiting for a package that is good enough to push to stable. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 75 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From Axel.Thimm at ATrpms.net Thu Jul 23 16:18:52 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 23 Jul 2009 19:18:52 +0300 Subject: Mass rebuild for Fedora 12 In-Reply-To: <20090723153345.GA892@nostromo.devel.redhat.com> References: <20090720201439.GA11912@nostromo.devel.redhat.com> <20090723152922.GA20343@victor.nirvana> <20090723153345.GA892@nostromo.devel.redhat.com> Message-ID: <20090723161852.GA25329@victor.nirvana> Hi, On Thu, Jul 23, 2009 at 11:33:46AM -0400, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at ATrpms.net) said: > > if I touch a package today, would it need to be rebuilt, and if not, > > would I need to create the noautobuild file? > > Any package that builds after redhat-rpm-config-9.0.3-12.fc12 is added > to the buildroot is OK. This has not happened yet. (waiting on a newRepo > task.) could this be automated in a way that if a package is built after that it doesn't get tagged for the mass rebuild? -- 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 braden at endoframe.com Thu Jul 23 16:21:52 2009 From: braden at endoframe.com (Braden McDaniel) Date: Thu, 23 Jul 2009 12:21:52 -0400 Subject: xulrunner-1.9.1.1-1.fc11.x86_64 update pulls in i586 packages In-Reply-To: References: <1248331120.4653.13417.camel@localhost> <4A687333.60909@ioa.s.u-tokyo.ac.jp> <1248363564.4653.14513.camel@localhost> <1248364557.4653.14575.camel@localhost> Message-ID: <1248366112.4653.14632.camel@localhost> On Thu, 2009-07-23 at 11:59 -0400, Seth Vidal wrote: > > On Thu, 23 Jul 2009, Braden McDaniel wrote: > > > > > Is the problem that the gecko-libs dependency is not arch-specific? > > Not necessarily. Well, there are a few more candidate dependencies; but that seems like the most likely one. Or did you have something else in mind? > > How do we fix that? > > %{__isa} istr. Well, I wouldn't be the least bit surprised if no one using gecko-libs does that; though if what you're suggesting is correct, I suspect nearly everyone needs to. But why does yum assume that a dependency of an x86_64 package can be satisfied by an i586 one? -- Braden McDaniel From skvidal at fedoraproject.org Thu Jul 23 16:23:16 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 23 Jul 2009 12:23:16 -0400 (EDT) Subject: xulrunner-1.9.1.1-1.fc11.x86_64 update pulls in i586 packages In-Reply-To: <1248366112.4653.14632.camel@localhost> References: <1248331120.4653.13417.camel@localhost> <4A687333.60909@ioa.s.u-tokyo.ac.jp> <1248363564.4653.14513.camel@localhost> <1248364557.4653.14575.camel@localhost> <1248366112.4653.14632.camel@localhost> Message-ID: On Thu, 23 Jul 2009, Braden McDaniel wrote: >>> How do we fix that? >> >> %{__isa} istr. > > Well, I wouldn't be the least bit surprised if no one using gecko-libs > does that; though if what you're suggesting is correct, I suspect nearly > everyone needs to. > > But why does yum assume that a dependency of an x86_64 package can be > satisfied by an i586 one? Why not? If something requires FOO and something else provides FOO - what difference does it make if it is from another arch as long as the arch is compatible with the system? -sv From rawhide at fedoraproject.org Thu Jul 23 16:27:21 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Thu, 23 Jul 2009 16:27:21 +0000 Subject: rawhide report: 20090723 changes Message-ID: <20090723162721.GA28329@releng2.fedora.phx.redhat.com> Compose started at Thu Jul 23 06:15:13 UTC 2009 New package matahari Qpid QMF Agent for Ovirt Nodes New package openssh-blacklist Fingerprints of the openssh keys affected by CVE-2008-0166 Updated Packages: ConsoleKit-0.3.0-11.fc12 ------------------------ * Wed Jul 22 2009 Ray Strode - 0.3.0-11 - Rebuild DeviceKit-power-010-1.fc12 -------------------------- * Wed Jul 22 2009 Richard Hughes - 010-1 - Update to 010 - Fixes a few problems with multi-battery laptops - Port to GUdev and PolicyKit1 PyYAML-3.08-5.fc12 ------------------ * Wed Jul 22 2009 - John Eckersberg - 3.08-5 - Minor tweaks to spec file aligning with latest Fedora packaging guidelines - Enforce inclusion of libyaml in build with --with-libyaml option to setup.py - Deliver to %{python_sitearch} instead of %{python_sitelib} due to _yaml.so - Thanks to Gareth Armstrong a2ps-4.14-9.fc12 ---------------- * Wed Jul 22 2009 Adam Jackson 4.14-9 - Requires: psutils-perl for fixps amanda-2.6.0p2-10.fc12 ---------------------- * Wed Jul 22 2009 Daniel Novotny 2.6.0p2-10 - fix #510961 - FTBFS: amanda-2.6.0p2-9 anaconda-12.5-1.fc12 -------------------- * Wed Jul 22 2009 David Cantrell - 12.4-1 - Add scripts/makeupdates to generate updates.img files. (dcantrell) - Add python-decorator to the stage2 image for pyparted (#513175). (clumens) - Set stage2= on x86 boot.iso (katzj) - Try to auto-find the CD even if stage2= is specified (katzj) - Make sure we have a device before check if it's protected. (#510033) (dlehman) - Remove unresolvable file devices from the devicetree. (#503830) (dlehman) - Support multiple fstab entries of a single nodev fstype. (#505969) (dlehman) - Refer to nodev devices as "none", not "nodev". (dlehman) - Change DeviceTree.devices from a dict to a list. (dlehman) - Show locked LUKS devices as "Encrypted (LUKS)", not "LUKS". (dlehman) - Allow creation of four primary partitions on a disk. (#505269) (dlehman) - Add a bunch more stuff to the initrd needed for networking. (clumens) - Add more things to /sbin on the initrd that udev requires. (clumens) - Add dmesg to the images. (clumens) * Wed Jul 22 2009 David Cantrell - 12.5-1 - New build because koji hates me. bes-3.7.2-1.fc12 ---------------- * Tue Jul 21 2009 Orion Poplawski - 3.7.2-1 - update to 3.7.2, enable tcp_wrapper support - Drop gcc43 patch fixed upstream binutils-2.19.51.0.13-28.fc12 ----------------------------- * Wed Jul 22 2009 Nick Clifton 2.19.51.0.11-28 - Rebase sources on 2.19.51.0.113 tarball. Remove redundant orphan section placement patch. (BZ 512937) c-ares-1.6.0-1.fc12 ------------------- * Wed Jul 22 2009 Tom "spot" Callaway - 1.6.0-1 - update to 1.6.0 ca-certificates-2009-1.fc12 --------------------------- * Wed Jul 22 2009 Joe Orton 2009-1 - update to certdata.txt r1.53 chkrootkit-0.48-13.fc12 ----------------------- * Wed Jul 22 2009 Jon Ciesla 0.48-13 - Additional items in chkutmp patch. chntpw-0.99.6-12.fc12 --------------------- * Wed Jul 22 2009 Richard W.M. Jones - 0.99.6-12 - Two^W Three more patches from Jim Meyering to improve general code quality. cld-0.2-0.5.g988e17d1.fc12 -------------------------- cryptsetup-luks-1.0.7-1.fc12 ---------------------------- * Wed Jul 22 2009 Milan Broz - 1.0.7-1 - Update to upstream final release. - Split libs subpackage. - Remove rpath setting from cryptsetup binary. curl-7.19.5-8.fc12 ------------------ * Wed Jul 22 2009 Kamil Dudka 7.19.5-8 - do not pre-login to all PKCS11 slots, it causes problems with HW tokens - try to select client certificate automatically when not specified, thanks to Claes Jakobsson dap-freeform_handler-3.7.12-1.fc12 ---------------------------------- * Wed Jul 22 2009 Orion Poplawski - 3.7.12-1 - Update to 3.9.12 - Drop gcc43 patch fixed upstream dap-server-3.9.3-1.fc12 ----------------------- * Wed Jul 22 2009 Orion Poplawski - 3.9.3-1 - Update to 3.9.3 - Add BR on cppunit-devel and make check dbus-1.2.16-2.fc12 ------------------ * Wed Jul 22 2009 Colin Walters - 1:1.2.16-2 - Explicitly add a dbus group id, fixes dbus files getting a random group id in cases where the RPM install order varies. Fixes https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=458183 farsight2-0.0.12-3.fc12 ----------------------- * Wed Jul 22 2009 Warren Togami - 0.0.12-3 - rebuild file-5.03-5.fc12 ---------------- * Wed Jul 22 2009 Daniel Novotny 5.03-5 - #513079 - RFE: file - recognize xfs metadump images * Fri Jul 10 2009 Adam Jackson 5.03-4 - Clean up %description. firefox-3.5.1-2.fc12 -------------------- * Wed Jul 22 2009 Jan Horak - 3.5.1-2 - New icons fixed gcc-4.4.1-1 ----------- * Wed Jul 22 2009 Jakub Jelinek 4.4.1-1 - update from gcc-4_4-branch - GCC 4.4.1 release ghc-editline-0.2.1.0-7.fc12 --------------------------- * Thu Jul 23 2009 Jens Petersen - 0.2.1.0-7 - pkg_libdir is redundant - devel requires libedit-devel * Wed Jul 22 2009 Jochen Schmitt 0.2.1.0-6 - Rebuild for new ghc release on rawhide gnome-panel-2.27.4-2.fc12 ------------------------- * Wed Jul 22 2009 Matthias Clasen - 2.27.4-2 - Make category icons follow the menu-images setting gob2-2.0.16-1.fc12 ------------------ * Wed Jul 22 2009 Daniel Novotny 2.0.16-1 - new upstream version 2.0.16 hmaccalc-0.9.9-1.fc12 --------------------- * Sat Jul 11 2009 Nalin Dahyabhai 0.9.9-1 - look for prelink at compile-time, and if we find it try to invoke it using a full pathname before trying with $PATH (#512275) - buildrequires: prelink so that it will be found at compile-time hyphen-2.4-4.fc12 ----------------- * Wed Jul 22 2009 Caolan McNamara - 2.4-4 - make hyphen-en a noarch subpackage icu-4.2.1-3.fc12 ---------------- * Wed Jul 22 2009 Caolan McNamara - 4.2.1-3 - make documentation noarch jd-2.4.2-0.1.svn2964_trunk.fc12 ------------------------------- * Thu Jul 23 2009 Mamoru Tasaka - rev 2964 kdelibs-4.2.98-1.fc12 --------------------- * Wed Jul 22 2009 Than Ngo - 4.2.98-1 - 4.3rc3 kdepimlibs-4.2.98-1.fc12 ------------------------ * Wed Jul 22 2009 Than Ngo - 4.2.98-1 - 4.3rc3 * Thu Jul 16 2009 Rex Dieter - 4.2.96-2 - License: LGPLv2+ kernel-2.6.31-0.86.rc3.git5.fc12 -------------------------------- * Wed Jul 22 2009 Ben Skeggs - Update nouveau from upstream (initial suspend/resume + misc bugfixes) * Wed Jul 22 2009 Ben Skeggs 2.6.31-0.82.rc3.git4 - Enable KMS for nouveau * Wed Jul 22 2009 Dave Jones - 2.6.31-rc3-git5 * Wed Jul 22 2009 Tom "spot" Callaway - We have to override the new %install behavior because, well... the kernel is special. libXext-1.0.99.4-1.fc12 ----------------------- * Wed Jul 22 2009 Peter Hutterer 1.0.99.4-1 - libXext 1.0.99.4 - fix.patch: Drop. * Tue Jul 21 2009 Adam Jackson 1.0.99.2-0 - libXext snapshot libXi-1.2.99-6.20090723.fc12 ---------------------------- * Thu Jul 23 2009 Peter Hutterer 1.2.99-6.20090723 - Update to today's git master libXtst-1.0.99.1-1.fc12 ----------------------- * Wed Jul 22 2009 Adam Jackson 1.0.99.1-1 - libXtst 1.0.99.1 libdap-3.9.3-1.fc12 ------------------- * Wed Jul 22 2009 Orion Poplawski - 3.9.3-1 - Update to 3.9.3 libgnome-2.26.0-4.fc12 ---------------------- * Wed Jul 22 2009 Matthias Clasen - 2.26.0-4 - Turn off icons in buttons and menus by default libnc-dap-3.7.4-1.fc12 ---------------------- * Wed Jul 22 2009 Orion Poplawski - 3.7.3-3 - Rebuild for libdap 3.9.3 - Add patch to support 3.9.3 * Wed Jul 22 2009 Orion Poplawski - 3.7.4-1 - Update to 3.7.4 - Drop templates patch applied upstream libpcap-1.0.0-1.20090716git6de2de.fc12 -------------------------------------- * Wed Jul 22 2009 Miroslav Lichvar 14:1.0.0-1.20090716git6de2de - update to 1.0.0, git snapshot 20090716git6de2de libtool-2.2.6-12.fc12 --------------------- * Wed Jul 22 2009 Matthias Clasen - 2.2.6-12 - Rebuild for gcc 4.4.1 libyaml-0.1.2-4.fc12 -------------------- * Wed Jul 22 2009 John Eckersberg - 0.1.2-4 - Minor tweaks to spec file - Enable %check section - Thanks Gareth Armstrong mailman-2.1.12-7.fc12 --------------------- * Wed Jul 22 2009 Daniel Novotny 3:2.1.12-7 - fix bz#512798 - Mailman path in /usr/bin/mailman-update-cfg is incorrect on x86_64. - added explanation comment in mailman-update-cfg, to justify why this script is needed mhash-0.9.9.9-2.fc12 -------------------- * Wed Jul 22 2009 Tom "spot" Callaway - 0.9.9.9-1 - update to 0.9.9.9 - apply all the fixes that I could find * Wed Jul 22 2009 Tom "spot" Callaway - 0.9.9.9-2 - bump rawhide, fixed the last bug mpich2-1.1.1-1.fc12 ------------------- * Wed Jul 22 2009 Deji Akingunola - 1.1.1-1 - Update to 1.1.1 - Remove (and obsolete) the -libs subpackage, it is not necessary. - Change e2fsprogs BR to libuuid notification-daemon-0.4.0-5.fc12 -------------------------------- * Wed Jul 22 2009 Matthias Clasen - 0.4.0-5 - Copy nodoka patch from F11 nss_ldap-264-5.fc12 ------------------- * Wed Jul 22 2009 Nalin Dahyabhai 264-5 - fix some minor leaks in pam_ldap, part of upstream #326,#333 openoffice.org-3.1.1-16.1.fc12 ------------------------------ * Wed Jul 22 2009 Caol?n McNamara - 1:3.1.1-16.1 - next milestone - drop integrated openoffice.org-3.1.1-ooo102679.sdext.buildfix.patch - drop integrated workspace.aw073.patch - Resolves: rhbz#512355 add openoffice.org-3.1.0.ooo103651.canvas.nosubpixel.patch oxygen-icon-theme-4.2.98-1.fc12 ------------------------------- * Wed Jul 22 2009 Than Ngo - 4.2.98-1 - 4.3rc3 * Mon Jul 13 2009 Than Ngo - 4.2.96-1 - 4.3rc2 parrot-1.4.0-3.fc12 ------------------- * Tue Jul 21 2009 Gerd Pokorra 1.4.0-1 - add the new disable-rpath configure option parted-1.9.0-5.20090721git980c.fc12 ----------------------------------- * Wed Jul 22 2009 Joel Granados - 1.9.0-5.20090721git980c - Better handle a duplicate error. perl-Array-Diff-0.05002-1.fc12 ------------------------------ * Wed Jul 22 2009 Daniel P. Berrange - 0.05002-1 - Update to new 0.05002 release perl-Curses-1.27-1.fc12 ----------------------- * Thu Jul 16 2009 kwizart < kwizart at gmail.com > - 1.27-1 - Update to 1.27 - Remove exec perm for demo* provided as %doc - Fix #510186 perl-Data-Section-0.091820-1.fc12 --------------------------------- * Wed Jul 22 2009 Daniel P. Berrange - 0.091820-1 - Update to 0.091820 release perl-Module-CPANTS-Analyse-0.85-1.fc12 -------------------------------------- * Wed Jul 22 2009 Daniel P. Berrange - 0.85-1 - Update to 0.85 release perl-Software-License-0.012-1.fc12 ---------------------------------- * Wed Jul 22 2009 Daniel P. Berrange - 0.012-1 - Update to 0.012 release perl-Test-AutoBuild-1.2.2-8.fc12 -------------------------------- * Wed Jul 22 2009 Daniel P. Berrange - 1.2.2-8 - Fix BZR repository tests (rhbz #511594) - Add missing perl(Class::MethodMaker) dep (rhbz #432714) perl-Test-YAML-Meta-0.12-1.fc12 ------------------------------- * Wed Jul 22 2009 Daniel P. Berrange - 0.12-1 - Update to 0.12 release printer-filters-1.1-3.fc12 -------------------------- * Wed Jul 22 2009 Adam Jackson 1.1-3 - Un-Requires: netpbm-progs, none of the foomatic ppds require it. psutils-1.17-31.fc12 -------------------- * Wed Jul 22 2009 Adam Jackson 1.17-31 - Split perl scripts to a subpackage. pypar-2.1.0_66-4.fc12 --------------------- * Thu Jul 23 2009 Jussi Lehtola - 2.1.0_66-4 - Openmpi seems to have been fixed, fix build in rawhide. python-docs-2.6-4.fc12 ---------------------- * Wed Jul 22 2009 Roman Rakus - 2.6-4 - Fix import error (#511647) * Wed May 06 2009 Roman Rakus - 2.6-3 - Spec file cleanup (#226341) python-netaddr-0.6.3-2.fc12 --------------------------- * Wed Jul 22 2009 John Eckersberg - 0.6.3-2 - Minor tweaks to spec file aligning with latest Fedora packaging guidelines - Enforce python 2.4 dependency as needed by netaddr >= 0.6.2 - Drop BR on python-setuptool as it is not imported in setup.py - Drop BR on dos2unix use sed instead - Align description with that of delivered PKG-INFO - Rip out python shebangs - Add %check section to enable tests - Thanks to Gareth Armstrong python-py-1.0.0-0.b8.fc12 ------------------------- * Wed Jul 22 2009 Thomas Moschny - 1.0.0-0.b8 - Update to 1.0.0b8. - Remove patches applied upstream. - Greenlets have been removed upstream. So, package is noarch and - installs to %{python_sitelib} again - %ifarch sections have been removed. - Don't remove files used by the testsuite for now. - Add dependency on python-pygments, pylint and pexpect (for the testsuite). python-pylons-0.9.7-1.fc12 -------------------------- * Wed Jul 22 2009 Kyle VanderBeek - 0.9.7-1 - Update to 0.9.7 final - Remove some cleanups that have been fixed upstream ratpoison-1.4.5-1.fc12 ---------------------- * Wed Jul 22 2009 Kevin Fenzi - 1.4.5-1 - Update to 1.4.5 rednotebook-0.8.0-1.fc12 ------------------------ * Wed Jul 22 2009 Fabian Affolter - 0.8.0-1 - Icon cache update added - Updated to new upstream version 0.8.0 scidavis-0.2.3-7.fc12 --------------------- * Wed Jul 22 2009 Eric Tanguy - 0.2.3-7 - Requires scidavis for scidavis-manual - Change categories in scidavis.desktop ser2net-2.6-1.fc12 ------------------ * Wed Jul 22 2009 Tom "spot" Callaway - 2.6-1 - update to 2.6 setools-3.3.6-1.fc12 -------------------- * Wed Jul 22 2009 Chris PeBenito 3.3.6-1 - New upstream release. system-config-printer-1.1.10-1.fc12 ----------------------------------- * Wed Jul 22 2009 Tim Waugh 1.1.10-1 - 1.1.10: - New udev rules for adding/enabling/disabling USB printers automatically. - Now uses gnome-packagekit utility to install packages instead of the D-Bus API. - Fixed detection of stopped jobs with CUPS 1.4. - Fixed tracebacks when adding a new printer and when receiving IPP notifications. - Fixed 'location' field for printers added on remote CUPS servers. - Fixed handling of incorrect authentication. - Some UI and troubleshooter fixes have been made. * Mon Jul 06 2009 Tim Waugh 1.1.8-6 - Requires gnome-packagekit for gpk-install-package-name. tcl-snack-2.2.10-11.fc12 ------------------------ * Wed Jul 22 2009 Tom "spot" Callaway - 2.2.10-11 - turn alsa back on, /dev/dsp is dead telepathy-gabble-0.7.31-1.fc12 ------------------------------ * Wed Jul 22 2009 Brian Pepple - 0.7.31-1 - Update to 0.7.31. tex-fonts-hebrew-0.1-12.fc12 ---------------------------- * Wed Jul 22 2009 Dan Kenigsberg - 0.1-12 - Rebuilt against existing David Type1 fonts. Bug #509697 - Require specific culmus font packages and obsolete tetex-fonts-hebrew-0.1-9. Bug #485639 uget-1.4.9.1-1.fc12 ------------------- * Thu Jul 23 2009 Mamoru Tasaka - 1.4.9.1-1 - 1.4.9.1 wireshark-1.2.1-1.fc12 ---------------------- * Wed Jul 22 2009 Radek Vokal - 1.2.1 - upgrade to 1.2.1 - http://www.wireshark.org/docs/relnotes/wireshark-1.2.1.html xine-ui-0.99.5-14.fc12 ---------------------- * Thu Jul 23 2009 Jussi Lehtola - 0.99.5-14 - Fix build in rawhide. * Mon Jul 20 2009 Jussi Lehtola - 0.99.5-13 - Added -skins subpackage. * Wed Jul 15 2009 Jussi Lehtola - 0.99.5-12 - Added BR: xorg-x11-proto-devel. xorg-x11-proto-devel-7.4-24.fc12 -------------------------------- * Wed Jul 22 2009 Peter Hutterer 7.4-23 - xextproto 7.0.99.2 - inputproto 1.9.99.15 * Wed Jul 22 2009 Peter Hutterer 7.4-24 - xextproto 7.0.99.3 yum-3.2.23-10.fc12 ------------------ * Wed Jul 22 2009 Seth Vidal - 3.2.23-10 - remove exactarchlist by request for rawhide znc-0.072-3.fc12 ---------------- * Wed Jul 22 2009 Nick Bebout - 0.072-1 - Upgrade to 0.072 of ZNC, fixes security issue in bug # 513152 * Wed Jul 22 2009 Nick Bebout - 0.072-2 - Backport patch to fix webadmin skins issue introduced in 0.072 * Wed Jul 22 2009 Nick Bebout - 0.072-3 - Fix date in changelog, disable c-ares zoneminder-1.24.2-2.fc12 ------------------------ * Wed Jul 22 2009 Jason L Tibbitts III - 1.24.2-1 - Initial update to 1.24.2. - Rebase patches. - Update mootools download location. - Update to mootools 1.2.3. - Add additional dependencies for some optional features. * Wed Jul 22 2009 Jason L Tibbitts III - 1.24.2-2 - Bump release since 1.24.2-1 was mistakenly tagged a few months ago. Summary: Added Packages: 2 Removed Packages: 0 Modified Packages: 80 Broken deps for i386 ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin R-RScaLAPACK-0.5.1-19.fc11.i586 requires openmpi-libs clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) dap-hdf4_handler-3.7.9-2.fc11.i586 requires libdap.so.9 dap-hdf4_handler-3.7.9-2.fc11.i586 requires libdapserver.so.6 dap-netcdf_handler-3.7.9-2.fc11.i586 requires libdap.so.9 dap-netcdf_handler-3.7.9-2.fc11.i586 requires libdapserver.so.6 gauche-gl-0.4.4-4.fc11.i586 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.i586 requires gauche = 0:0.8.13 gdal-1.6.0-8.fc11.i586 requires libdap.so.9 gdal-1.6.0-8.fc11.i586 requires libdapserver.so.6 gdal-perl-1.6.0-8.fc11.i586 requires libdap.so.9 gdal-perl-1.6.0-8.fc11.i586 requires libdapserver.so.6 gdal-python-1.6.0-8.fc11.i586 requires libdap.so.9 gdal-python-1.6.0-8.fc11.i586 requires libdapserver.so.6 gdal-ruby-1.6.0-8.fc11.i586 requires libdap.so.9 gdal-ruby-1.6.0-8.fc11.i586 requires libdapserver.so.6 gedit-vala-0.4.1-2.fc11.i586 requires libgtksourcecompletion-1.0.so.1 ghc-HTTP-devel-4000.0.6-3.fc12.i586 requires ghc = 0:6.10.3 ghc-HTTP-devel-4000.0.6-3.fc12.i586 requires ghc = 0:6.10.3 ghc-HTTP-doc-4000.0.6-3.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-HTTP-doc-4000.0.6-3.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-HTTP-prof-4000.0.6-3.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-X11-devel-1.4.5-11.fc12.i586 requires ghc = 0:6.10.3 ghc-X11-devel-1.4.5-11.fc12.i586 requires ghc = 0:6.10.3 ghc-X11-doc-1.4.5-11.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-X11-doc-1.4.5-11.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-X11-prof-1.4.5-11.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-cairo-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-cairo-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-cairo-prof-0.10.1-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-cpphs-devel-1.6-8.fc12.i586 requires ghc = 0:6.10.3 ghc-cpphs-devel-1.6-8.fc12.i586 requires ghc = 0:6.10.3 ghc-cpphs-doc-1.6-8.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-cpphs-doc-1.6-8.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-cpphs-prof-1.6-8.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-gconf-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gconf-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gconf-prof-0.10.1-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-ghc-paths-devel-0.1.0.5-7.fc12.i586 requires ghc = 0:6.10.3 ghc-ghc-paths-devel-0.1.0.5-7.fc12.i586 requires ghc = 0:6.10.3 ghc-ghc-paths-doc-0.1.0.5-7.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-ghc-paths-doc-0.1.0.5-7.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-ghc-paths-prof-0.1.0.5-7.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-gio-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gio-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gio-prof-0.10.1-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-glade-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-glade-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-glade-prof-0.10.1-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-glib-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-glib-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-glib-prof-0.10.1-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-gstreamer-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gstreamer-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gstreamer-prof-0.10.1-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-gtk-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtk-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtk-prof-0.10.1-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-gtkglext-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtkglext-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtkglext-prof-0.10.1-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-gtksourceview2-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtksourceview2-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtksourceview2-prof-0.10.1-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-haskell-src-exts-devel-1.0.1-1.fc12.i586 requires ghc = 0:6.10.3 ghc-haskell-src-exts-devel-1.0.1-1.fc12.i586 requires ghc = 0:6.10.3 ghc-haskell-src-exts-doc-1.0.1-1.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-haskell-src-exts-doc-1.0.1-1.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-haskell-src-exts-prof-1.0.1-1.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-hscolour-devel-1.13-1.fc12.i586 requires ghc = 0:6.10.3 ghc-hscolour-devel-1.13-1.fc12.i586 requires ghc = 0:6.10.3 ghc-hscolour-doc-1.13-1.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-hscolour-doc-1.13-1.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-hscolour-prof-1.13-1.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-soegtk-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-soegtk-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-soegtk-prof-0.10.1-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-svgcairo-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-svgcairo-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-svgcairo-prof-0.10.1-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-uniplate-devel-1.2.0.3-4.fc12.i586 requires ghc = 0:6.10.3 ghc-uniplate-devel-1.2.0.3-4.fc12.i586 requires ghc = 0:6.10.3 ghc-uniplate-doc-1.2.0.3-4.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-uniplate-doc-1.2.0.3-4.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-uniplate-prof-1.2.0.3-4.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-utf8-string-devel-0.3.5-2.fc12.i586 requires ghc = 0:6.10.3 ghc-utf8-string-devel-0.3.5-2.fc12.i586 requires ghc = 0:6.10.3 ghc-utf8-string-doc-0.3.5-2.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-utf8-string-doc-0.3.5-2.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-utf8-string-prof-0.3.5-2.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-xmonad-devel-0.8.1-13.fc12.i586 requires ghc = 0:6.10.3 ghc-xmonad-devel-0.8.1-13.fc12.i586 requires ghc = 0:6.10.3 ghc-xmonad-doc-0.8.1-13.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-xmonad-doc-0.8.1-13.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-xmonad-prof-0.8.1-13.fc12.i586 requires ghc-prof = 0:6.10.3 ghc-zlib-devel-0.5.0.0-9.fc12.i586 requires ghc = 0:6.10.3 ghc-zlib-devel-0.5.0.0-9.fc12.i586 requires ghc = 0:6.10.3 ghc-zlib-doc-0.5.0.0-9.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-zlib-doc-0.5.0.0-9.fc12.i586 requires ghc-doc = 0:6.10.3 ghc-zlib-prof-0.5.0.0-9.fc12.i586 requires ghc-prof = 0:6.10.3 gnome-phone-manager-0.65-2.fc12.i586 requires libgnome-bluetooth.so.6 grads-1.9b4-26.fc11.i586 requires libdap.so.9 libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.i586 requires libclutter-cairo-0.8.so.0 libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 ncl-5.1.1-1.fc12.i686 requires libdap.so.9 perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) php-idn-1.2-5.fc12.i586 requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.i586 requires libclutter-cairo-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.i586 requires clutter-cairo pyclutter-gst-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.i586 requires libclutter-gtk-0.8.so.0 python-tgext-crud-0.2.4-1.fc12.noarch requires python-sprox >= 0:0.5.4.1 qtparted-0.4.5-19.fc11.i586 requires libparted-1.8.so.8 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.i586 requires libpqxx-2.6.8.so thunderbird-lightning-1.0-0.6.20090513hg.fc12.i586 requires thunderbird < 0:3.0-2.3.b4 totem-youtube-2.27.1-2.fc12.i586 requires libgdata.so.4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.i586 requires vtkdata = 0:5.2.1 Broken deps for x86_64 ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin R-RScaLAPACK-0.5.1-19.fc11.x86_64 requires openmpi-libs clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-cairo-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.x86_64 requires pkgconfig(clutter-0.8) dap-hdf4_handler-3.7.9-2.fc11.x86_64 requires libdap.so.9()(64bit) dap-hdf4_handler-3.7.9-2.fc11.x86_64 requires libdapserver.so.6()(64bit) dap-netcdf_handler-3.7.9-2.fc11.i586 requires libdap.so.9 dap-netcdf_handler-3.7.9-2.fc11.i586 requires libdapserver.so.6 dap-netcdf_handler-3.7.9-2.fc11.x86_64 requires libdap.so.9()(64bit) dap-netcdf_handler-3.7.9-2.fc11.x86_64 requires libdapserver.so.6()(64bit) gauche-gl-0.4.4-4.fc11.x86_64 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.x86_64 requires gauche = 0:0.8.13 gdal-1.6.0-8.fc11.i586 requires libdap.so.9 gdal-1.6.0-8.fc11.i586 requires libdapserver.so.6 gdal-1.6.0-8.fc11.x86_64 requires libdap.so.9()(64bit) gdal-1.6.0-8.fc11.x86_64 requires libdapserver.so.6()(64bit) gdal-perl-1.6.0-8.fc11.x86_64 requires libdap.so.9()(64bit) gdal-perl-1.6.0-8.fc11.x86_64 requires libdapserver.so.6()(64bit) gdal-python-1.6.0-8.fc11.x86_64 requires libdap.so.9()(64bit) gdal-python-1.6.0-8.fc11.x86_64 requires libdapserver.so.6()(64bit) gdal-ruby-1.6.0-8.fc11.x86_64 requires libdap.so.9()(64bit) gdal-ruby-1.6.0-8.fc11.x86_64 requires libdapserver.so.6()(64bit) gedit-vala-0.4.1-2.fc11.x86_64 requires libgtksourcecompletion-1.0.so.1()(64bit) ghc-HTTP-devel-4000.0.6-3.fc12.i586 requires ghc = 0:6.10.3 ghc-HTTP-devel-4000.0.6-3.fc12.i586 requires ghc = 0:6.10.3 ghc-HTTP-devel-4000.0.6-3.fc12.x86_64 requires ghc = 0:6.10.3 ghc-HTTP-devel-4000.0.6-3.fc12.x86_64 requires ghc = 0:6.10.3 ghc-HTTP-doc-4000.0.6-3.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-HTTP-doc-4000.0.6-3.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-HTTP-prof-4000.0.6-3.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-X11-devel-1.4.5-11.fc12.i586 requires ghc = 0:6.10.3 ghc-X11-devel-1.4.5-11.fc12.i586 requires ghc = 0:6.10.3 ghc-X11-devel-1.4.5-11.fc12.x86_64 requires ghc = 0:6.10.3 ghc-X11-devel-1.4.5-11.fc12.x86_64 requires ghc = 0:6.10.3 ghc-X11-doc-1.4.5-11.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-X11-doc-1.4.5-11.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-X11-prof-1.4.5-11.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-cairo-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-cairo-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-cairo-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-cairo-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-cairo-prof-0.10.1-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-cpphs-devel-1.6-8.fc12.i586 requires ghc = 0:6.10.3 ghc-cpphs-devel-1.6-8.fc12.i586 requires ghc = 0:6.10.3 ghc-cpphs-devel-1.6-8.fc12.x86_64 requires ghc = 0:6.10.3 ghc-cpphs-devel-1.6-8.fc12.x86_64 requires ghc = 0:6.10.3 ghc-cpphs-doc-1.6-8.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-cpphs-doc-1.6-8.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-cpphs-prof-1.6-8.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-gconf-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gconf-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gconf-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gconf-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gconf-prof-0.10.1-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-ghc-paths-devel-0.1.0.5-7.fc12.i586 requires ghc = 0:6.10.3 ghc-ghc-paths-devel-0.1.0.5-7.fc12.i586 requires ghc = 0:6.10.3 ghc-ghc-paths-devel-0.1.0.5-7.fc12.x86_64 requires ghc = 0:6.10.3 ghc-ghc-paths-devel-0.1.0.5-7.fc12.x86_64 requires ghc = 0:6.10.3 ghc-ghc-paths-doc-0.1.0.5-7.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-ghc-paths-doc-0.1.0.5-7.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-ghc-paths-prof-0.1.0.5-7.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-gio-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gio-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gio-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gio-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gio-prof-0.10.1-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-glade-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-glade-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-glade-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-glade-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-glade-prof-0.10.1-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-glib-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-glib-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-glib-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-glib-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-glib-prof-0.10.1-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-gstreamer-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gstreamer-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gstreamer-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gstreamer-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gstreamer-prof-0.10.1-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-gtk-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtk-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtk-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gtk-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gtk-prof-0.10.1-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-gtkglext-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtkglext-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtkglext-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gtkglext-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gtkglext-prof-0.10.1-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-gtksourceview2-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtksourceview2-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-gtksourceview2-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gtksourceview2-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-gtksourceview2-prof-0.10.1-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-haskell-src-exts-devel-1.0.1-1.fc12.i586 requires ghc = 0:6.10.3 ghc-haskell-src-exts-devel-1.0.1-1.fc12.i586 requires ghc = 0:6.10.3 ghc-haskell-src-exts-devel-1.0.1-1.fc12.x86_64 requires ghc = 0:6.10.3 ghc-haskell-src-exts-devel-1.0.1-1.fc12.x86_64 requires ghc = 0:6.10.3 ghc-haskell-src-exts-doc-1.0.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-haskell-src-exts-doc-1.0.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-haskell-src-exts-prof-1.0.1-1.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-hscolour-devel-1.13-1.fc12.i586 requires ghc = 0:6.10.3 ghc-hscolour-devel-1.13-1.fc12.i586 requires ghc = 0:6.10.3 ghc-hscolour-devel-1.13-1.fc12.x86_64 requires ghc = 0:6.10.3 ghc-hscolour-devel-1.13-1.fc12.x86_64 requires ghc = 0:6.10.3 ghc-hscolour-doc-1.13-1.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-hscolour-doc-1.13-1.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-hscolour-prof-1.13-1.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-soegtk-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-soegtk-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-soegtk-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-soegtk-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-soegtk-prof-0.10.1-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-svgcairo-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-svgcairo-devel-0.10.1-4.fc12.i586 requires ghc = 0:6.10.3 ghc-svgcairo-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-svgcairo-devel-0.10.1-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-svgcairo-prof-0.10.1-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-uniplate-devel-1.2.0.3-4.fc12.i586 requires ghc = 0:6.10.3 ghc-uniplate-devel-1.2.0.3-4.fc12.i586 requires ghc = 0:6.10.3 ghc-uniplate-devel-1.2.0.3-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-uniplate-devel-1.2.0.3-4.fc12.x86_64 requires ghc = 0:6.10.3 ghc-uniplate-doc-1.2.0.3-4.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-uniplate-doc-1.2.0.3-4.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-uniplate-prof-1.2.0.3-4.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-utf8-string-devel-0.3.5-2.fc12.i586 requires ghc = 0:6.10.3 ghc-utf8-string-devel-0.3.5-2.fc12.i586 requires ghc = 0:6.10.3 ghc-utf8-string-devel-0.3.5-2.fc12.x86_64 requires ghc = 0:6.10.3 ghc-utf8-string-devel-0.3.5-2.fc12.x86_64 requires ghc = 0:6.10.3 ghc-utf8-string-doc-0.3.5-2.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-utf8-string-doc-0.3.5-2.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-utf8-string-prof-0.3.5-2.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-xmonad-devel-0.8.1-13.fc12.i586 requires ghc = 0:6.10.3 ghc-xmonad-devel-0.8.1-13.fc12.i586 requires ghc = 0:6.10.3 ghc-xmonad-devel-0.8.1-13.fc12.x86_64 requires ghc = 0:6.10.3 ghc-xmonad-devel-0.8.1-13.fc12.x86_64 requires ghc = 0:6.10.3 ghc-xmonad-doc-0.8.1-13.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-xmonad-doc-0.8.1-13.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-xmonad-prof-0.8.1-13.fc12.x86_64 requires ghc-prof = 0:6.10.3 ghc-zlib-devel-0.5.0.0-9.fc12.i586 requires ghc = 0:6.10.3 ghc-zlib-devel-0.5.0.0-9.fc12.i586 requires ghc = 0:6.10.3 ghc-zlib-devel-0.5.0.0-9.fc12.x86_64 requires ghc = 0:6.10.3 ghc-zlib-devel-0.5.0.0-9.fc12.x86_64 requires ghc = 0:6.10.3 ghc-zlib-doc-0.5.0.0-9.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-zlib-doc-0.5.0.0-9.fc12.x86_64 requires ghc-doc = 0:6.10.3 ghc-zlib-prof-0.5.0.0-9.fc12.x86_64 requires ghc-prof = 0:6.10.3 gnome-phone-manager-0.65-2.fc12.x86_64 requires libgnome-bluetooth.so.6()(64bit) grads-1.9b4-26.fc11.x86_64 requires libdap.so.9()(64bit) libchamplain-0.2.9-1.fc11.i586 requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.i586 requires libclutter-cairo-0.8.so.0 libchamplain-0.2.9-1.fc11.x86_64 requires libclutter-cairo-0.8.so.0()(64bit) libchamplain-0.2.9-1.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.i586 requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.x86_64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 libprojectM-1.2.0-9.fc11.x86_64 requires libftgl.so.0()(64bit) ncl-5.1.1-1.fc12.x86_64 requires libdap.so.9()(64bit) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) php-idn-1.2-5.fc12.x86_64 requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.x86_64 requires libclutter-cairo-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.x86_64 requires clutter-cairo pyclutter-cairo-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.x86_64 requires libclutter-gtk-0.8.so.0()(64bit) python-tgext-crud-0.2.4-1.fc12.noarch requires python-sprox >= 0:0.5.4.1 qtparted-0.4.5-19.fc11.x86_64 requires libparted-1.8.so.8()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.x86_64 requires libpqxx-2.6.8.so()(64bit) thunderbird-lightning-1.0-0.6.20090513hg.fc12.x86_64 requires thunderbird < 0:3.0-2.3.b4 totem-youtube-2.27.1-2.fc12.x86_64 requires libgdata.so.4()(64bit) trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.x86_64 requires vtkdata = 0:5.2.1 Broken deps for ppc ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin R-RScaLAPACK-0.5.1-19.fc11.ppc requires openmpi-libs clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-cairo-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc requires pkgconfig(clutter-0.8) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) dap-hdf4_handler-3.7.9-2.fc11.ppc requires libdap.so.9 dap-hdf4_handler-3.7.9-2.fc11.ppc requires libdapserver.so.6 dap-netcdf_handler-3.7.9-2.fc11.ppc requires libdap.so.9 dap-netcdf_handler-3.7.9-2.fc11.ppc requires libdapserver.so.6 dap-netcdf_handler-3.7.9-2.fc11.ppc64 requires libdap.so.9()(64bit) dap-netcdf_handler-3.7.9-2.fc11.ppc64 requires libdapserver.so.6()(64bit) gauche-gl-0.4.4-4.fc11.ppc requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.ppc requires gauche = 0:0.8.13 gdal-1.6.0-8.fc11.ppc requires libdap.so.9 gdal-1.6.0-8.fc11.ppc requires libdapserver.so.6 gdal-1.6.0-8.fc11.ppc64 requires libdap.so.9()(64bit) gdal-1.6.0-8.fc11.ppc64 requires libdapserver.so.6()(64bit) gdal-perl-1.6.0-8.fc11.ppc requires libdap.so.9 gdal-perl-1.6.0-8.fc11.ppc requires libdapserver.so.6 gdal-python-1.6.0-8.fc11.ppc requires libdap.so.9 gdal-python-1.6.0-8.fc11.ppc requires libdapserver.so.6 gdal-ruby-1.6.0-8.fc11.ppc requires libdap.so.9 gdal-ruby-1.6.0-8.fc11.ppc requires libdapserver.so.6 gedit-vala-0.4.1-2.fc11.ppc requires libgtksourcecompletion-1.0.so.1 ghc-HTTP-devel-4000.0.6-3.fc12.ppc requires ghc = 0:6.10.3 ghc-HTTP-devel-4000.0.6-3.fc12.ppc requires ghc = 0:6.10.3 ghc-HTTP-doc-4000.0.6-3.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-HTTP-doc-4000.0.6-3.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-HTTP-prof-4000.0.6-3.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-X11-devel-1.4.5-11.fc12.ppc requires ghc = 0:6.10.3 ghc-X11-devel-1.4.5-11.fc12.ppc requires ghc = 0:6.10.3 ghc-X11-doc-1.4.5-11.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-X11-doc-1.4.5-11.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-X11-prof-1.4.5-11.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-cairo-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-cairo-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-cairo-prof-0.10.1-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-cpphs-devel-1.6-8.fc12.ppc requires ghc = 0:6.10.3 ghc-cpphs-devel-1.6-8.fc12.ppc requires ghc = 0:6.10.3 ghc-cpphs-doc-1.6-8.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-cpphs-doc-1.6-8.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-cpphs-prof-1.6-8.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-gconf-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gconf-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gconf-prof-0.10.1-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-ghc-paths-devel-0.1.0.5-7.fc12.ppc requires ghc = 0:6.10.3 ghc-ghc-paths-devel-0.1.0.5-7.fc12.ppc requires ghc = 0:6.10.3 ghc-ghc-paths-doc-0.1.0.5-7.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-ghc-paths-doc-0.1.0.5-7.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-ghc-paths-prof-0.1.0.5-7.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-gio-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gio-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gio-prof-0.10.1-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-glade-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-glade-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-glade-prof-0.10.1-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-glib-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-glib-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-glib-prof-0.10.1-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-gstreamer-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gstreamer-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gstreamer-prof-0.10.1-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-gtk-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gtk-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gtk-prof-0.10.1-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-gtkglext-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gtkglext-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gtkglext-prof-0.10.1-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-gtksourceview2-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gtksourceview2-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-gtksourceview2-prof-0.10.1-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-haskell-src-exts-devel-1.0.1-1.fc12.ppc requires ghc = 0:6.10.3 ghc-haskell-src-exts-devel-1.0.1-1.fc12.ppc requires ghc = 0:6.10.3 ghc-haskell-src-exts-doc-1.0.1-1.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-haskell-src-exts-doc-1.0.1-1.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-haskell-src-exts-prof-1.0.1-1.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-hscolour-devel-1.13-1.fc12.ppc requires ghc = 0:6.10.3 ghc-hscolour-devel-1.13-1.fc12.ppc requires ghc = 0:6.10.3 ghc-hscolour-doc-1.13-1.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-hscolour-doc-1.13-1.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-hscolour-prof-1.13-1.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-soegtk-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-soegtk-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-soegtk-prof-0.10.1-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-svgcairo-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-svgcairo-devel-0.10.1-4.fc12.ppc requires ghc = 0:6.10.3 ghc-svgcairo-prof-0.10.1-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-uniplate-devel-1.2.0.3-4.fc12.ppc requires ghc = 0:6.10.3 ghc-uniplate-devel-1.2.0.3-4.fc12.ppc requires ghc = 0:6.10.3 ghc-uniplate-doc-1.2.0.3-4.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-uniplate-doc-1.2.0.3-4.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-uniplate-prof-1.2.0.3-4.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-utf8-string-devel-0.3.5-2.fc12.ppc requires ghc = 0:6.10.3 ghc-utf8-string-devel-0.3.5-2.fc12.ppc requires ghc = 0:6.10.3 ghc-utf8-string-doc-0.3.5-2.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-utf8-string-doc-0.3.5-2.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-utf8-string-prof-0.3.5-2.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-xmonad-devel-0.8.1-13.fc12.ppc requires ghc = 0:6.10.3 ghc-xmonad-devel-0.8.1-13.fc12.ppc requires ghc = 0:6.10.3 ghc-xmonad-doc-0.8.1-13.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-xmonad-doc-0.8.1-13.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-xmonad-prof-0.8.1-13.fc12.ppc requires ghc-prof = 0:6.10.3 ghc-zlib-devel-0.5.0.0-9.fc12.ppc requires ghc = 0:6.10.3 ghc-zlib-devel-0.5.0.0-9.fc12.ppc requires ghc = 0:6.10.3 ghc-zlib-doc-0.5.0.0-9.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-zlib-doc-0.5.0.0-9.fc12.ppc requires ghc-doc = 0:6.10.3 ghc-zlib-prof-0.5.0.0-9.fc12.ppc requires ghc-prof = 0:6.10.3 gnome-phone-manager-0.65-2.fc12.ppc requires libgnome-bluetooth.so.6 grads-1.9b4-26.fc11.ppc requires libdap.so.9 libchamplain-0.2.9-1.fc11.ppc requires libclutter-glx-0.8.so.0 libchamplain-0.2.9-1.fc11.ppc requires libclutter-cairo-0.8.so.0 libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-cairo-0.8.so.0()(64bit) libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc requires pkgconfig(clutter-0.8) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc requires libftgl.so.0 libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) ncl-5.1.1-1.fc12.ppc requires libdap.so.9 perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) php-idn-1.2-5.fc12.ppc requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.ppc requires libclutter-cairo-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-cairo-0.8.2-2.fc11.ppc requires clutter-cairo pyclutter-gst-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-glx-0.8.so.0 pyclutter-gtk-0.8.2-2.fc11.ppc requires libclutter-gtk-0.8.so.0 python-tgext-crud-0.2.4-1.fc12.noarch requires python-sprox >= 0:0.5.4.1 qtparted-0.4.5-19.fc11.ppc requires libparted-1.8.so.8 rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc requires libpqxx-2.6.8.so thunderbird-lightning-1.0-0.6.20090513hg.fc12.ppc requires thunderbird < 0:3.0-2.3.b4 totem-youtube-2.27.1-2.fc12.ppc requires libgdata.so.4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc requires vtkdata = 0:5.2.1 Broken deps for ppc64 ---------------------------------------------------------- 389-ds-1.1.3-3.fc12.noarch requires 389-ds-admin R-RScaLAPACK-0.5.1-19.fc11.ppc64 requires openmpi-libs clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-cairo-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gst-0.8.0-4.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-gst-devel-0.8.0-4.fc11.ppc64 requires pkgconfig(clutter-0.8) dap-hdf4_handler-3.7.9-2.fc11.ppc64 requires libdap.so.9()(64bit) dap-hdf4_handler-3.7.9-2.fc11.ppc64 requires libdapserver.so.6()(64bit) dap-netcdf_handler-3.7.9-2.fc11.ppc64 requires libdap.so.9()(64bit) dap-netcdf_handler-3.7.9-2.fc11.ppc64 requires libdapserver.so.6()(64bit) gdal-1.6.0-8.fc11.ppc64 requires libdap.so.9()(64bit) gdal-1.6.0-8.fc11.ppc64 requires libdapserver.so.6()(64bit) gdal-perl-1.6.0-8.fc11.ppc64 requires libdap.so.9()(64bit) gdal-perl-1.6.0-8.fc11.ppc64 requires libdapserver.so.6()(64bit) gdal-python-1.6.0-8.fc11.ppc64 requires libdap.so.9()(64bit) gdal-python-1.6.0-8.fc11.ppc64 requires libdapserver.so.6()(64bit) gdal-ruby-1.6.0-8.fc11.ppc64 requires libdap.so.9()(64bit) gdal-ruby-1.6.0-8.fc11.ppc64 requires libdapserver.so.6()(64bit) gedit-vala-0.4.1-2.fc11.ppc64 requires libgtksourcecompletion-1.0.so.1()(64bit) gnome-phone-manager-0.65-2.fc12.ppc64 requires libgnome-bluetooth.so.6()(64bit) grads-1.9b4-26.fc11.ppc64 requires libdap.so.9()(64bit) libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-cairo-0.8.so.0()(64bit) libchamplain-0.2.9-1.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) libchamplain-devel-0.2.9-1.fc11.ppc64 requires pkgconfig(clutter-0.8) libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) ncl-5.1.1-1.fc12.ppc64 requires libdap.so.9()(64bit) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) php-idn-1.2-5.fc12.ppc64 requires php-api = 0:20041225 pyclutter-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.ppc64 requires libclutter-cairo-0.8.so.0()(64bit) pyclutter-cairo-0.8.2-2.fc11.ppc64 requires clutter-cairo pyclutter-cairo-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gst-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) pyclutter-gtk-0.8.2-2.fc11.ppc64 requires libclutter-gtk-0.8.so.0()(64bit) python-mwlib-0.11.2-2.20090522hg2956.fc12.ppc64 requires LabPlot python-tgext-crud-0.2.4-1.fc12.noarch requires python-sprox >= 0:0.5.4.1 qtparted-0.4.5-19.fc11.ppc64 requires libparted-1.8.so.8()(64bit) rubygem-main-2.8.4-2.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 showimg-pgsql-0.9.5-22.fc11.ppc64 requires libpqxx-2.6.8.so()(64bit) thunderbird-lightning-1.0-0.6.20090513hg.fc12.ppc64 requires thunderbird < 0:3.0-2.3.b4 totem-youtube-2.27.1-2.fc12.ppc64 requires libgdata.so.4()(64bit) trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 vtk-examples-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 vtk-testing-5.2.1-2.fc12.ppc64 requires vtkdata = 0:5.2.1 From jkeating at redhat.com Thu Jul 23 16:27:06 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 23 Jul 2009 09:27:06 -0700 Subject: Mass rebuild for Fedora 12 In-Reply-To: <20090723161852.GA25329@victor.nirvana> References: <20090720201439.GA11912@nostromo.devel.redhat.com> <20090723152922.GA20343@victor.nirvana> <20090723153345.GA892@nostromo.devel.redhat.com> <20090723161852.GA25329@victor.nirvana> Message-ID: <1248366426.2861.78.camel@localhost.localdomain> On Thu, 2009-07-23 at 19:18 +0300, Axel Thimm wrote: > > could this be automated in a way that if a package is built after that > it doesn't get tagged for the mass rebuild? Yes it is automated. The script checks to see if the build was done after a certain timestamp and if so, avoids building it again. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Thu Jul 23 16:33:04 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 23 Jul 2009 12:33:04 -0400 Subject: Mass rebuild for Fedora 12 In-Reply-To: <20090723161852.GA25329@victor.nirvana> References: <20090720201439.GA11912@nostromo.devel.redhat.com> <20090723152922.GA20343@victor.nirvana> <20090723153345.GA892@nostromo.devel.redhat.com> <20090723161852.GA25329@victor.nirvana> Message-ID: <20090723163304.GA2797@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > could this be automated in a way that if a package is built after that > it doesn't get tagged for the mass rebuild? This will get covered, yes. Bill From skvidal at fedoraproject.org Thu Jul 23 16:26:49 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 23 Jul 2009 12:26:49 -0400 (EDT) Subject: xulrunner-1.9.1.1-1.fc11.x86_64 update pulls in i586 packages In-Reply-To: <20090723181328.161e9bb5@faldor> References: <1248331120.4653.13417.camel@localhost> <4A687333.60909@ioa.s.u-tokyo.ac.jp> <1248363564.4653.14513.camel@localhost> <1248364557.4653.14575.camel@localhost> <20090723181328.161e9bb5@faldor> Message-ID: On Thu, 23 Jul 2009, Michael Schwendt wrote: > On Thu, 23 Jul 2009 11:55:57 -0400, Braden wrote: > >> Is the problem that the gecko-libs dependency is not arch-specific? How >> do we fix that? > > You could make it arch-specific by depending on gecko-libs%{?_isa} = ... > yah - I said it with two _'s not one. my mistake. -sv From email.ahmedkamal at googlemail.com Thu Jul 23 18:16:10 2009 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Thu, 23 Jul 2009 21:16:10 +0300 Subject: RFE: FireKit Message-ID: <3da3b5b40907231116p1f08c8epb93b0fe3c85d7ab4@mail.gmail.com> Hi, Here's a RFE for FireKit, a firewall desktop "kit". What this does is: 1- Exposes a dbus interface for applications to programatically open/close ports 2- Monitors as new daemons/applications that listen on non lo interfaces are started, checks if iptables is currently blocking them, and if so, warns the user that application X is currently blocked by the firewall User Experience: ======= 1- Joe wants some help from his co-worker, he shares his Gnome desktop through vino. Vino kicks FireKit to ask Joe if he would like to open port 5900, and asks for a period of time. Joe selects yes, and chooses 30 minutes. FireKit instructs iptables to open that port, and waits for 30 mins. 2- Sally wants to share last night's photos with her team. She drops the photos in /var/www/html, and starts apache. While apache does not know about FireKit, FireKit still detects that port 80 is now listening on 0.0.0.0, FireKit pops a notification that process "apache" is listening on port 80, and is being blocked by the firewall. FireKit asks Sally if she'd like to open port 80, and for how long. Sally accepts and chooses 5 hours I'm no hot shot developer, so I am not quite sure about which architecture is best, or details about integration with policy-kit, however, this seems to me like a really missing integration point on the free desktop front. Comments and opinions are welcome. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From mw_triad at users.sourceforge.net Thu Jul 23 18:46:32 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 23 Jul 2009 13:46:32 -0500 Subject: xulrunner-1.9.1.1-1.fc11.x86_64 update pulls in i586 packages In-Reply-To: References: <1248331120.4653.13417.camel@localhost> <4A687333.60909@ioa.s.u-tokyo.ac.jp> <1248363564.4653.14513.camel@localhost> <1248364557.4653.14575.camel@localhost> <1248366112.4653.14632.camel@localhost> Message-ID: Seth Vidal wrote: > On Thu, 23 Jul 2009, Braden McDaniel wrote: >> But why does yum assume that a dependency of an x86_64 package can be >> satisfied by an i586 one? > > Why not? > > If something requires FOO and something else provides FOO - what > difference does it make if it is from another arch as long as the arch > is compatible with the system? That only works if FOO is an executable and not a library, no? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "What is a release plan, anyway?" -- Oswald Buddenhagen ...who I'm sure did not mean it seriously ;-) From skvidal at fedoraproject.org Thu Jul 23 18:50:32 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 23 Jul 2009 14:50:32 -0400 (EDT) Subject: xulrunner-1.9.1.1-1.fc11.x86_64 update pulls in i586 packages In-Reply-To: References: <1248331120.4653.13417.camel@localhost> <4A687333.60909@ioa.s.u-tokyo.ac.jp> <1248363564.4653.14513.camel@localhost> <1248364557.4653.14575.camel@localhost> <1248366112.4653.14632.camel@localhost> Message-ID: On Thu, 23 Jul 2009, Matthew Woehlke wrote: > Seth Vidal wrote: >> On Thu, 23 Jul 2009, Braden McDaniel wrote: >>> But why does yum assume that a dependency of an x86_64 package can be >>> satisfied by an i586 one? >> >> Why not? >> >> If something requires FOO and something else provides FOO - what difference >> does it make if it is from another arch as long as the arch is compatible >> with the system? > > That only works if FOO is an executable and not a library, no? libraries that are auto-prov'd - will get arch-specifc on their own. -sv From braden at endoframe.com Thu Jul 23 19:53:39 2009 From: braden at endoframe.com (Braden McDaniel) Date: Thu, 23 Jul 2009 15:53:39 -0400 Subject: xulrunner-1.9.1.1-1.fc11.x86_64 update pulls in i586 packages In-Reply-To: References: <1248331120.4653.13417.camel@localhost> <4A687333.60909@ioa.s.u-tokyo.ac.jp> <1248363564.4653.14513.camel@localhost> <1248364557.4653.14575.camel@localhost> <1248366112.4653.14632.camel@localhost> Message-ID: <4A68BFC3.1030305@endoframe.com> On 7/23/09 2:50 PM, Seth Vidal wrote: > > > On Thu, 23 Jul 2009, Matthew Woehlke wrote: > >> Seth Vidal wrote: >>> On Thu, 23 Jul 2009, Braden McDaniel wrote: >>>> But why does yum assume that a dependency of an x86_64 package can be >>>> satisfied by an i586 one? >>> >>> Why not? >>> >>> If something requires FOO and something else provides FOO - what >>> difference does it make if it is from another arch as long as the >>> arch is compatible with the system? >> >> That only works if FOO is an executable and not a library, no? > > libraries that are auto-prov'd - will get arch-specifc on their own. Which isn't the case for gecko-libs; or for anything that's getting dlopen'd. The packaging guidelines probably need to raise the visibility of this issue. -- Braden McDaniel e-mail: Jabber: From Matt_Domsch at dell.com Thu Jul 23 20:45:32 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 23 Jul 2009 15:45:32 -0500 Subject: No Frozen Rawhide In-Reply-To: <1248278291.2861.20.camel@localhost.localdomain> References: <1248217490.2861.2.camel@localhost.localdomain> <200907221057.13253.jarod@redhat.com> <1248278291.2861.20.camel@localhost.localdomain> Message-ID: <20090723204532.GA31230@auslistsprd01.us.dell.com> On Wed, Jul 22, 2009 at 08:58:11AM -0700, Jesse Keating wrote: > On Wed, 2009-07-22 at 10:57 -0400, Jarod Wilson wrote: > > Only thing I'm not terribly wild about is storing the pre-release tree > > in /pub/fedora/linux/releases/#/Everything/. Its bound to cause some > > confusion amongst the general population. Any reason not to keep it at > > /pub/fedora/linux/releases/test/#/Everything/ instead? > > Churn on the mirror configs and the repo files, as well as on the > mirrors when we move to the final destination. Also it makes having > test/12/Everything and test/12-Alpha and test/12-Beta a tad bit > confusing when all in the same dir. repo files? metalink?repo=fedora-12&arch=i386 could point to any directory we so wish. -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From mschwendt at gmail.com Thu Jul 23 21:02:46 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 23 Jul 2009 21:02:46 -0000 Subject: Broken dependencies in Fedora 11 - 2009-07-23 Message-ID: <20090723210246.13493.90708@faldor.intranet> ====================================================================== The results in this summary consider Test Updates! ====================================================================== Summary of broken packages (by src.rpm name): beagle CodeAnalyst-gui gauche-gl gauche-gtk gnome-bluetooth gnome-phone-manager mono-tools openmpi pcmanx-gtk2 ppl python-repoze-what python-tgext-crud R-RScaLAPACK synce-kde tomboy vdccm vtk ====================================================================== Broken packages in fedora-11-i386: CodeAnalyst-gui-2.8.38-11.fc11.i586 requires libbfd-2.19.51.0.2-17.fc11.so R-RScaLAPACK-0.5.1-19.fc11.i586 requires openmpi-libs gauche-gl-0.4.4-4.fc11.i586 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.i586 requires gauche = 0:0.8.13 gnome-phone-manager-0.65-1.fc11.i586 requires libgnome-bluetooth.so.2 openmpi-vt-1.3.1-1.fc11.i586 requires openmpi-libs = 0:1.3.1-1.fc11 pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.i586 requires xulrunner = 0:1.9.1 synce-kde-0.9.1-4.fc11.i586 requires synce-serial vdccm-0.10.1-5.fc11.i586 requires synce-serial ====================================================================== Broken packages in fedora-11-ppc: R-RScaLAPACK-0.5.1-19.fc11.ppc requires openmpi-libs gauche-gl-0.4.4-4.fc11.ppc requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.ppc requires gauche = 0:0.8.13 gnome-phone-manager-0.65-1.fc11.ppc requires libgnome-bluetooth.so.2 openmpi-vt-1.3.1-1.fc11.ppc requires openmpi-libs = 0:1.3.1-1.fc11 pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.ppc requires xulrunner = 0:1.9.1 synce-kde-0.9.1-4.fc11.ppc requires synce-serial vdccm-0.10.1-5.fc11.ppc requires synce-serial ====================================================================== Broken packages in fedora-11-ppc64: R-RScaLAPACK-0.5.1-19.fc11.ppc64 requires openmpi-libs gnome-phone-manager-0.65-1.fc11.ppc64 requires libgnome-bluetooth.so.2()(64bit) openmpi-vt-1.3.1-1.fc11.ppc64 requires openmpi-libs = 0:1.3.1-1.fc11 pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.ppc64 requires xulrunner = 0:1.9.1 synce-kde-0.9.1-4.fc11.ppc64 requires synce-serial vdccm-0.10.1-5.fc11.ppc64 requires synce-serial ====================================================================== Broken packages in fedora-11-x86_64: CodeAnalyst-gui-2.8.38-11.fc11.x86_64 requires libbfd-2.19.51.0.2-17.fc11.so()(64bit) R-RScaLAPACK-0.5.1-19.fc11.x86_64 requires openmpi-libs gauche-gl-0.4.4-4.fc11.x86_64 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.x86_64 requires gauche = 0:0.8.13 gnome-phone-manager-0.65-1.fc11.x86_64 requires libgnome-bluetooth.so.2()(64bit) openmpi-vt-1.3.1-1.fc11.x86_64 requires openmpi-libs = 0:1.3.1-1.fc11 pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.x86_64 requires xulrunner = 0:1.9.1 synce-kde-0.9.1-4.fc11.x86_64 requires synce-serial vdccm-0.10.1-5.fc11.x86_64 requires synce-serial ====================================================================== Broken packages in fedora-updates-11-i386: ppl-swiprolog-0.10.2-3.fc11.i586 requires libpl.so.5.7.6 ppl-yap-0.10.2-3.fc11.i586 requires libYap.so ====================================================================== Broken packages in fedora-updates-11-ppc: ppl-swiprolog-0.10.2-3.fc11.ppc requires libpl.so.5.7.6 ppl-yap-0.10.2-3.fc11.ppc requires libYap.so ====================================================================== Broken packages in fedora-updates-11-ppc64: beagle-0.3.9-9.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0 beagle-0.3.9-9.fc11.ppc64 requires mono(gsf-sharp) = 0:0.0.0.7 beagle-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 beagle-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 beagle-0.3.9-9.fc11.ppc64 requires mono(taglib-sharp) = 0:2.0.3.2 beagle-evolution-0.3.9-9.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0 beagle-evolution-0.3.9-9.fc11.ppc64 requires mono(evolution-sharp) = 0:5.0.0.0 beagle-gnome-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 beagle-gnome-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 beagle-thunderbird-0.3.9-9.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0 ppl-swiprolog-0.10.2-3.fc11.ppc64 requires libpl.so.5.7.6()(64bit) ppl-yap-0.10.2-3.fc11.ppc64 requires libYap.so()(64bit) tomboy-0.14.3-1.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(Mono.Addins.Setup) = 0:0.4.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(gnome-panel-sharp) = 0:2.24.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(Mono.Addins) = 0:0.4.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(Mono.Addins.Gui) = 0:0.4.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 ====================================================================== Broken packages in fedora-updates-11-x86_64: ppl-swiprolog-0.10.2-3.fc11.x86_64 requires libpl.so.5.7.6()(64bit) ppl-yap-0.10.2-3.fc11.x86_64 requires libYap.so()(64bit) ====================================================================== Broken packages in fedora-updates-testing-11-i386: gnome-bluetooth-2.27.8-1.fc11.i586 requires bluez >= 0:4.42 python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 python-tgext-crud-0.2.4-1.fc11.noarch requires python-sprox >= 0:0.5.4.1 vtk-examples-5.4.2-33.fc11.i586 requires vtkdata = 0:5.4.2 vtk-testing-5.4.2-33.fc11.i586 requires vtkdata = 0:5.4.2 ====================================================================== Broken packages in fedora-updates-testing-11-ppc: gnome-bluetooth-2.27.8-1.fc11.ppc requires bluez >= 0:4.42 python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 python-tgext-crud-0.2.4-1.fc11.noarch requires python-sprox >= 0:0.5.4.1 vtk-examples-5.4.2-33.fc11.ppc requires vtkdata = 0:5.4.2 vtk-testing-5.4.2-33.fc11.ppc requires vtkdata = 0:5.4.2 ====================================================================== Broken packages in fedora-updates-testing-11-ppc64: gnome-bluetooth-2.27.8-1.fc11.ppc64 requires bluez >= 0:4.42 mono-tools-2.4-12.fc11.ppc64 requires mono(gtkhtml-sharp) >= 0:3.0 python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 python-tgext-crud-0.2.4-1.fc11.noarch requires python-sprox >= 0:0.5.4.1 vtk-examples-5.4.2-33.fc11.ppc64 requires vtkdata = 0:5.4.2 vtk-testing-5.4.2-33.fc11.ppc64 requires vtkdata = 0:5.4.2 ====================================================================== Broken packages in fedora-updates-testing-11-x86_64: gnome-bluetooth-2.27.8-1.fc11.x86_64 requires bluez >= 0:4.42 python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8 python-tgext-crud-0.2.4-1.fc11.noarch requires python-sprox >= 0:0.5.4.1 vtk-examples-5.4.2-33.fc11.x86_64 requires vtkdata = 0:5.4.2 vtk-testing-5.4.2-33.fc11.x86_64 requires vtkdata = 0:5.4.2 From awilliam at redhat.com Thu Jul 23 21:08:49 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 23 Jul 2009 14:08:49 -0700 Subject: F12 Alpha Blocker Bug Meeting: Friday 2009-07-24 Message-ID: <1248383329.2863.34.camel@adam.local.net> What: F12Alpha Blocker bug meeting (https://bugzilla.redhat.com/show_bug.cgi?id=f12alpha) When: Friday, 2009-07-24 @ 15:00 UTC (11 AM EDT) Where: #fedora-bugzappers Yes, ladies and gentlemen, tomorrow marks the second blocker bug review meeting for Fedora 12 Alpha. Please do come along to provide your insight and wisdom as we go through the list of bugs blocking the Alpha release (and probably do a quick sweep of those blocking the final release, too). If you are aware of any bugs you think should block the Alpha, please do set them to block 'F12Alpha' - and come to the meeting, if you can, to chime in when we discuss them. Please note the change of time, to avoid conflicting with the FESCO meeting: this review will be at 15:00 UTC (11:00 EDT), changed from 17:00 UTC last week. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From jkeating at redhat.com Thu Jul 23 21:09:09 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 23 Jul 2009 14:09:09 -0700 Subject: No Frozen Rawhide In-Reply-To: <20090723204532.GA31230@auslistsprd01.us.dell.com> References: <1248217490.2861.2.camel@localhost.localdomain> <200907221057.13253.jarod@redhat.com> <1248278291.2861.20.camel@localhost.localdomain> <20090723204532.GA31230@auslistsprd01.us.dell.com> Message-ID: <1248383349.2861.84.camel@localhost.localdomain> On Thu, 2009-07-23 at 15:45 -0500, Matt Domsch wrote: > repo files? metalink?repo=fedora-12&arch=i386 could point to any > directory we so wish. We still have the fallback repo lines that point directly to content, and people who point directly to mirrors. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From schaiba at gmail.com Thu Jul 23 21:36:31 2009 From: schaiba at gmail.com (Aioanei Rares) Date: Fri, 24 Jul 2009 00:36:31 +0300 Subject: RFE: FireKit In-Reply-To: <3da3b5b40907231116p1f08c8epb93b0fe3c85d7ab4@mail.gmail.com> References: <3da3b5b40907231116p1f08c8epb93b0fe3c85d7ab4@mail.gmail.com> Message-ID: <4A68D7DF.2060608@gmail.com> On 07/23/2009 09:16 PM, Ahmed Kamal wrote: > Hi, > > Here's a RFE for FireKit, a firewall desktop "kit". What this does is: > 1- Exposes a dbus interface for applications to programatically > open/close ports > 2- Monitors as new daemons/applications that listen on non lo > interfaces are started, checks if iptables is currently blocking them, > and if so, warns the user that application X is currently blocked by > the firewall > > User Experience: > ======= > 1- Joe wants some help from his co-worker, he shares his Gnome desktop > through vino. Vino kicks FireKit to ask Joe if he would like to open > port 5900, and asks for a period of time. Joe selects yes, and chooses > 30 minutes. FireKit instructs iptables to open that port, and waits > for 30 mins. > 2- Sally wants to share last night's photos with her team. She drops > the photos in /var/www/html, and starts apache. While apache does not > know about FireKit, FireKit still detects that port 80 is now > listening on 0.0.0.0, FireKit pops a notification that process > "apache" is listening on port 80, and is being blocked by the > firewall. FireKit asks Sally if she'd like to open port 80, and for > how long. Sally accepts and chooses 5 hours > > I'm no hot shot developer, so I am not quite sure about which > architecture is best, or details about integration with policy-kit, > however, this seems to me like a really missing integration point on > the free desktop front. Comments and opinions are welcome. > > Regards To me it seems like a great idea, but your usual computer user does not really know about Apache and ports, IP's and the like. Other than that, if you need help, ask. What language do you intend to implement this in? From bjorn at xn--rombobjrn-67a.se Thu Jul 23 21:46:17 2009 From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=) Date: Thu, 23 Jul 2009 23:46:17 +0200 Subject: weird debuginfo problem Message-ID: <200907232346.31853.bjorn@xn--rombobjrn-67a.se> I seem to have finally discovered the cause of a problem I've had with debuginfo packages. Apparently the component that extracts debuginfo doesn't like symlinks. /home on this system is a symlink to /disk/data/home, and %_topdir was "/home/beorn/rpm". This caused debuginfo packages without sources, where the .debug files referenced the sources in the build directory. After I changed %_topdir to "/disk/data/home/beorn/rpm" the debuginfo packages seem correct. Is this expected behaviour or should I file a bug report against RPM? 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 roland at redhat.com Thu Jul 23 21:53:20 2009 From: roland at redhat.com (Roland McGrath) Date: Thu, 23 Jul 2009 14:53:20 -0700 (PDT) Subject: weird debuginfo problem In-Reply-To: Björn Persson's message of Thursday, 23 July 2009 23:46:17 +0200 <200907232346.31853.bjorn@xn--rombobjrn-67a.se> References: <200907232346.31853.bjorn@xn--rombobjrn-67a.se> Message-ID: <20090723215320.3DAD61C7@magilla.sf.frob.com> > /home on this system is a symlink to /disk/data/home, and %_topdir was > "/home/beorn/rpm". This caused debuginfo packages without sources, where the > .debug files referenced the sources in the build directory. After I changed > %_topdir to "/disk/data/home/beorn/rpm" the debuginfo packages seem correct. Hmm. Can you look at: eu-readelf --debug-dump=info FILE | fgrep comp_dir on some of those .debug files and see what directory names got embedded there? It looks for %{_builddir} and rewrites that to /usr/src/... names. I guess maybe it needs to look for both %{_builddir} and `cd %{_builddir}; pwd`. I think both the name you use and the canonical name can get embedded in DWARF source file names, depending how things are compiled. Thanks, Roland From jgarzik at pobox.com Thu Jul 23 21:53:24 2009 From: jgarzik at pobox.com (Jeff Garzik) Date: Thu, 23 Jul 2009 17:53:24 -0400 Subject: F12 Alpha Blocker Bug Meeting: Friday 2009-07-24 In-Reply-To: <1248383329.2863.34.camel@adam.local.net> References: <1248383329.2863.34.camel@adam.local.net> Message-ID: <4A68DBD4.3060703@pobox.com> Adam Williamson wrote: > What: F12Alpha Blocker bug meeting > (https://bugzilla.redhat.com/show_bug.cgi?id=f12alpha) > When: Friday, 2009-07-24 @ 15:00 UTC (11 AM EDT) > Where: #fedora-bugzappers > > Yes, ladies and gentlemen, tomorrow marks the second blocker bug review > meeting for Fedora 12 Alpha. Please do come along to provide your > insight and wisdom as we go through the list of bugs blocking the Alpha > release (and probably do a quick sweep of those blocking the final > release, too). If you are aware of any bugs you think should block the > Alpha, please do set them to block 'F12Alpha' - and come to the meeting, > if you can, to chime in when we discuss them. I can't come to the meeting, but I just added this one: https://bugzilla.redhat.com/show_bug.cgi?id=512377 Upgrading nfs-utils disrupts ALL active NFS clients, and further, prevents them from re-connecting after the upgrade. Jeff From email.ahmedkamal at googlemail.com Thu Jul 23 21:54:36 2009 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Fri, 24 Jul 2009 00:54:36 +0300 Subject: RFE: FireKit In-Reply-To: <4A68D7DF.2060608@gmail.com> References: <3da3b5b40907231116p1f08c8epb93b0fe3c85d7ab4@mail.gmail.com> <4A68D7DF.2060608@gmail.com> Message-ID: <3da3b5b40907231454s6a151e67h44684e59eed0b45a@mail.gmail.com> >To me it seems like a great idea, but your usual computer user > does not really know about Apache and ports, IP's and the like. Exactly the point, the user shares his desktop, or starts some service using the services GUI, and FireKit should offer to help. Moreover, this actually would improve desktop security, since without FireKit, a typical user after wasting half an hour, would understand it was the firewall blocking him, and would simply disable it for good. This happens on any OS. However, with FireKit, pro-actively offering to help the user, and requesting by default a limited time-window for opening the ports, actually ensures a better desktop security > Other than that, if you need help, ask. I do :) I'm not sure how this should integrate with policy-kit for allowing which users should be able to control the firewall. Should FireKit launch its own daemon that runs all the time, or is there some other way. How to control iptables without running shell commands, and how to hook on ports creation events. I guess I should be using some python RTNETLINK bindings, any ideas? Any examples, design decisions, and pointers to code samples to make my life easier, are highly appreciated > What language do you intend to implement this in? But of course python ;) Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From awilliam at redhat.com Thu Jul 23 22:01:35 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 23 Jul 2009 15:01:35 -0700 Subject: F12 Alpha Blocker Bug Meeting: Friday 2009-07-24 In-Reply-To: <4A68DBD4.3060703@pobox.com> References: <1248383329.2863.34.camel@adam.local.net> <4A68DBD4.3060703@pobox.com> Message-ID: <1248386495.2863.36.camel@adam.local.net> On Thu, 2009-07-23 at 17:53 -0400, Jeff Garzik wrote: > Adam Williamson wrote: > > What: F12Alpha Blocker bug meeting > > (https://bugzilla.redhat.com/show_bug.cgi?id=f12alpha) > > When: Friday, 2009-07-24 @ 15:00 UTC (11 AM EDT) > > Where: #fedora-bugzappers > > > > Yes, ladies and gentlemen, tomorrow marks the second blocker bug review > > meeting for Fedora 12 Alpha. Please do come along to provide your > > insight and wisdom as we go through the list of bugs blocking the Alpha > > release (and probably do a quick sweep of those blocking the final > > release, too). If you are aware of any bugs you think should block the > > Alpha, please do set them to block 'F12Alpha' - and come to the meeting, > > if you can, to chime in when we discuss them. > > > I can't come to the meeting, but I just added this one: > https://bugzilla.redhat.com/show_bug.cgi?id=512377 > > Upgrading nfs-utils disrupts ALL active NFS clients, and further, > prevents them from re-connecting after the upgrade. Going on strict criteria, this probably isn't an Alpha blocker (as it doesn't stop the critical functions of the system working). It certainly looks like a final release blocker, though. Anyway, I'll leave it on the list and we'll discuss it at the meeting tomorrow and take appropriate action. Thanks for contributing to the process! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From mike at cchtml.com Thu Jul 23 22:01:38 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Thu, 23 Jul 2009 17:01:38 -0500 Subject: RFE: FireKit In-Reply-To: <3da3b5b40907231454s6a151e67h44684e59eed0b45a@mail.gmail.com> References: <3da3b5b40907231116p1f08c8epb93b0fe3c85d7ab4@mail.gmail.com> <4A68D7DF.2060608@gmail.com> <3da3b5b40907231454s6a151e67h44684e59eed0b45a@mail.gmail.com> Message-ID: <4A68DDC2.4020504@cchtml.com> Ahmed Kamal on 07/23/2009 04:54 PM wrote: > Exactly the point, the user shares his desktop, or starts some service > using the services GUI, and FireKit should offer to help. Moreover, this > actually would improve desktop security, since without FireKit, a > typical user after wasting half an hour, would understand it was the > firewall blocking him, and would simply disable it for good. This > happens on any OS. However, with FireKit, pro-actively offering to help > the user, and requesting by default a limited time-window for opening > the ports, actually ensures a better desktop security > The user should simply be prompted: "Do you want "Vino Remote Desktop" to be allowed network access?" (Yes or No) That's if the port is not already open. FireKit, or something like it, has been needed for a long time. The user experience for everyone will be greatly improved. It's great you are starting this initiative. I hope you are able to get something out of it. > > > But of course python ;) > Great, so it'll be just as slow as all the other system administration tools. The folks involved with system-config-* may not notice it, but on slightly older systems (say, P4 generation) the firewall tool or services tool takes ages to start. Easily 30 seconds to a minute. Thanks Python. From jgarzik at pobox.com Thu Jul 23 22:12:33 2009 From: jgarzik at pobox.com (Jeff Garzik) Date: Thu, 23 Jul 2009 18:12:33 -0400 Subject: F12 Alpha Blocker Bug Meeting: Friday 2009-07-24 In-Reply-To: <1248386495.2863.36.camel@adam.local.net> References: <1248383329.2863.34.camel@adam.local.net> <4A68DBD4.3060703@pobox.com> <1248386495.2863.36.camel@adam.local.net> Message-ID: <4A68E051.5060006@pobox.com> Adam Williamson wrote: > On Thu, 2009-07-23 at 17:53 -0400, Jeff Garzik wrote: >> Adam Williamson wrote: >>> What: F12Alpha Blocker bug meeting >>> (https://bugzilla.redhat.com/show_bug.cgi?id=f12alpha) >>> When: Friday, 2009-07-24 @ 15:00 UTC (11 AM EDT) >>> Where: #fedora-bugzappers >>> >>> Yes, ladies and gentlemen, tomorrow marks the second blocker bug review >>> meeting for Fedora 12 Alpha. Please do come along to provide your >>> insight and wisdom as we go through the list of bugs blocking the Alpha >>> release (and probably do a quick sweep of those blocking the final >>> release, too). If you are aware of any bugs you think should block the >>> Alpha, please do set them to block 'F12Alpha' - and come to the meeting, >>> if you can, to chime in when we discuss them. >> >> I can't come to the meeting, but I just added this one: >> https://bugzilla.redhat.com/show_bug.cgi?id=512377 >> >> Upgrading nfs-utils disrupts ALL active NFS clients, and further, >> prevents them from re-connecting after the upgrade. > > Going on strict criteria, this probably isn't an Alpha blocker (as it > doesn't stop the critical functions of the system working). It certainly > looks like a final release blocker, though. Anyway, I'll leave it on the > list and we'll discuss it at the meeting tomorrow and take appropriate > action. Thanks for contributing to the process! [tone note: not a sarcastic question...] What are "critical functions of the system"? I'd say access to one's filesystem is quite critical. :) Either way things go... thanks! Jeff From mw_triad at users.sourceforge.net Thu Jul 23 22:17:41 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 23 Jul 2009 17:17:41 -0500 Subject: RFE: FireKit In-Reply-To: <4A68DDC2.4020504@cchtml.com> References: <3da3b5b40907231116p1f08c8epb93b0fe3c85d7ab4@mail.gmail.com> <4A68D7DF.2060608@gmail.com> <3da3b5b40907231454s6a151e67h44684e59eed0b45a@mail.gmail.com> <4A68DDC2.4020504@cchtml.com> Message-ID: Michael Cronenworth wrote: > Ahmed Kamal on 07/23/2009 04:54 PM wrote: >> Exactly the point, the user shares his desktop, or starts some service >> using the services GUI, and FireKit should offer to help. Moreover, this >> actually would improve desktop security, since without FireKit, a >> typical user after wasting half an hour, would understand it was the >> firewall blocking him, and would simply disable it for good. This >> happens on any OS. However, with FireKit, pro-actively offering to help >> the user, and requesting by default a limited time-window for opening >> the ports, actually ensures a better desktop security > > The user should simply be prompted: > > "Do you want "Vino Remote Desktop" to be allowed network access?" > (Yes or No) I have to ask... when are we going to see Linux allow network access based on the checksum of the process that wants to use it? After all, 'doze has had this ability for years. (Maybe SELinux can provide this already?) Having said that, something like FireKit is obviously a step in the right direction. I presume in addition to