Re: [ACTION REQUIRED v4] Retiring packages for F-18
Bruno Wolff III writes: > On Thu, Jul 26, 2012 at 20:13:18 -0400, >Tom Lane wrote: >> I'm still hoping to kill libpng-compat (and libtiff-compat) before we >> branch F18. > Should libpng12 obsolete libpng-compat? Doh. I didn't think about that, but you're probably right. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Thu, Jul 26, 2012 at 20:13:18 -0400, Tom Lane wrote: I'm still hoping to kill libpng-compat (and libtiff-compat) before we branch F18. Should libpng12 obsolete libpng-compat? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On 07/25/2012 06:24 PM, Bill Nottingham wrote: > Package libharu (fails to build) Fixed it (libpng 1.5 issues), bumped it to 2.2.1. This required a rebuild of deps (perl-PDF-Haru, EMBOSS), which I also kicked off in rawhide. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On 12-07-30 4:46 PM, Jerry James wrote: I'm happy to take it, if you will orphan it in pkgdb. Great, done! Regards, Stewart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Mon, Jul 30, 2012 at 2:04 PM, Stewart Adam wrote: > On 12-07-25 6:24 PM, Bill Nottingham wrote: >> >> Package gnofract4d (fails to build) >> comaintained by: firewing > > > Sorry I didn't see this earlier. It looks like this FTBFS was fixed by > jjames on the Jul 26, my thanks! You're welcome. > That said, I no longer have any use for this package. If jjames (or anyone > else) would like to continue maintaining it please feel free to take it. I'm happy to take it, if you will orphan it in pkgdb. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On 12-07-25 6:24 PM, Bill Nottingham wrote: Package gnofract4d (fails to build) comaintained by: firewing Sorry I didn't see this earlier. It looks like this FTBFS was fixed by jjames on the Jul 26, my thanks! That said, I no longer have any use for this package. If jjames (or anyone else) would like to continue maintaining it please feel free to take it. Regards, Stewart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
Hi all, On 07/26/2012 12:24 AM, Bill Nottingham wrote: Removing: quesoglc chromium-bsu requires quesoglc-devel = 0.7.2-2.fc15 chromium-bsu requires libGLC.so.0 rss-glx requires quesoglc-devel = 0.7.2-2.fc15 rss-glx requires libGLC.so.0 warzone2100 requires quesoglc-devel = 0.7.2-2.fc15 As the maintainer of chromium-bsu I've taken care of fixing the FTBFS for quesoglc, while at it I also fixed the multilib conflict bug which was open against it. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Fri, 2012-07-27 at 10:15 -0700, Toshio Kuratomi wrote: > For packagers and developers of the software, the revision id portion is > usually what we want but (as tgl pointed out) the date still comes in handy > if upstream changes their SCM. I don't think it does, in practice. the 0.n part covers any such situation just fine. *any* time you build the package, you are supposed to increment n. I don't think it's possible for a situation to exist where a change in SCM would cause a problem for sorting. The SCM stuff is put behind the 0.n bit for precisely this reason. > For endusers, the date is more handy for seeing whether the package is based > on newer or older upstream versions than the scm's hash. That's why I suggested making the date _optional_. If the packager reckons it's useful information, they could still include it. My point is just that it's probably wrong nowadays to have the date as mandatory but the revision as optional, when the opposite would seem to make more sense. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Thu, Jul 26, 2012 at 09:48:13 -0500, Bruno Wolff III wrote: On Wed, Jul 25, 2012 at 18:24:52 -0400, Bill Nottingham wrote: Updated with new list of packages that have failed to build. Package stratagus (fails to build) statagus is currently FTBFS because it isn't using the newer libpng API. Assuming that's all that's wrong with it, I'll be able to fix this soon. stratagus builds now. It hasn't been really tested though as there is no game for it that is in Fedora and only one of the games listed as playable on the project web site didn't require game data from a commercial game. That game didn't work, but maybe because the Fedora version of stratagus is behind upstream. The error didn't look related to png. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Fri, Jul 27, 2012 at 1:38 PM, Jesse Keating wrote: > On 07/27/2012 11:29 AM, Jon Ciesla wrote: >> >> I'd agree, but git hashes don't do in sortable order. I mean, they >> do, but only Discordian sort. > > > I'm not suggesting you have rpm sort on git hashes. The release string is > required to have a numeric prefix before the date and/or git hash. I'm > talking about removing the date part of it so that you still have a numeric > prefix (e.g. 0.5) before the git hash. Ordering happens on the 0.X part, > not on the git hash. OIC. Right. It's Friday. Worth considering. -J > > -- > Jesse Keating > Fedora -- Freedom² is a feature! > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On 07/27/2012 11:29 AM, Jon Ciesla wrote: I'd agree, but git hashes don't do in sortable order. I mean, they do, but only Discordian sort. I'm not suggesting you have rpm sort on git hashes. The release string is required to have a numeric prefix before the date and/or git hash. I'm talking about removing the date part of it so that you still have a numeric prefix (e.g. 0.5) before the git hash. Ordering happens on the 0.X part, not on the git hash. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On 07/27/2012 11:29 AM, Toshio Kuratomi wrote: That's hyperbolic. A date tells you something meaningful even if it is specifying something that turns out to be a range of valid entries. I might not know if 20120106 is more recent code than 20110610 but I know that it isn't older code, for instance. No, you don't. All you know is that "20120106" is the date the checkout was made. The checkout could be code from 2 years ago, where as the checkout that was done on 20110610 was of code that was at the time brand new (and then later determined to be too full of errors to continue using). The date things were checked out is pretty meaningless. More context is needed, even on SCMs without a canonical revision identifier. You'd want to know what branch or tag the checkout was from. That kind of detail goes in the changelog, not shoved into the release string. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Fri, Jul 27, 2012 at 1:26 PM, Jesse Keating wrote: > On 07/27/2012 11:13 AM, Jon Ciesla wrote: >> >> If you can suggest a clarification of wording, it sounds like an >> EASYFIX for FPC. >> >> -J >> >>> > > > > I would suggest just dropping the date field for SCMs that have a canonical > revision identifier. I'd agree, but git hashes don't do in sortable order. I mean, they do, but only Discordian sort. -J > -- > Jesse Keating > Fedora -- Freedom² is a feature! > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Fri, Jul 27, 2012 at 11:11:24AM -0700, Jesse Keating wrote: > On 07/27/2012 10:15 AM, Toshio Kuratomi wrote: > >For endusers, the date is more handy for seeing whether the package is based > >on newer or older upstream versions than the scm's hash. > > But do we specifically say what you're supposed to put in the date > field? Is it the date the hash was created? The date the hash was > added to a specific branch? The date the hash was checked out by the > Fedora dev and built in the build system? > > The guidelines say at one place that the date used should be the date > the snapshot was made, which can be pretty disconnected from the date > the hash was created or merged. > > A date without clear rules or context is just meaningless digits. > That's hyperbolic. A date tells you something meaningful even if it is specifying something that turns out to be a range of valid entries. I might not know if 20120106 is more recent code than 20110610 but I know that it isn't older code, for instance. -Toshio pgpnleFhqyTUj.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On 07/27/2012 11:13 AM, Jon Ciesla wrote: If you can suggest a clarification of wording, it sounds like an EASYFIX for FPC. -J > I would suggest just dropping the date field for SCMs that have a canonical revision identifier. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Fri, Jul 27, 2012 at 1:11 PM, Jesse Keating wrote: > On 07/27/2012 10:15 AM, Toshio Kuratomi wrote: >> >> For endusers, the date is more handy for seeing whether the package is >> based >> on newer or older upstream versions than the scm's hash. > > > But do we specifically say what you're supposed to put in the date field? > Is it the date the hash was created? The date the hash was added to a > specific branch? The date the hash was checked out by the Fedora dev and > built in the build system? > > The guidelines say at one place that the date used should be the date the > snapshot was made, which can be pretty disconnected from the date the hash > was created or merged. > > A date without clear rules or context is just meaningless digits. If you can suggest a clarification of wording, it sounds like an EASYFIX for FPC. -J > -- > Jesse Keating > Fedora -- Freedom² is a feature! > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On 07/27/2012 10:15 AM, Toshio Kuratomi wrote: For endusers, the date is more handy for seeing whether the package is based on newer or older upstream versions than the scm's hash. But do we specifically say what you're supposed to put in the date field? Is it the date the hash was created? The date the hash was added to a specific branch? The date the hash was checked out by the Fedora dev and built in the build system? The guidelines say at one place that the date used should be the date the snapshot was made, which can be pretty disconnected from the date the hash was created or merged. A date without clear rules or context is just meaningless digits. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Thu, Jul 26, 2012 at 05:32:54PM -0700, Adam Williamson wrote: > On Thu, 2012-07-26 at 19:52 -0400, Tom Lane wrote: > > Jesse Keating writes: > > > On Thu, 2012-07-26 at 15:37 -0700, Adam Williamson wrote: > > >> The date is useful for making it > > >> immediately obvious how up-to-date a package is, I guess, but it has no > > >> really key function for differentiating builds any more.) > > > > > It's not even that. With CVS you could have done a checkout of a tag > > > which could be quite old compared to the day's date you did the > > > checkout. Using the date somewhat assumes you're doing a checkout of > > > HEAD, which isn't always the case. I'd move that embedding the date in > > > there is of little use. > > > > The good thing about putting the date in there is that it's likely to > > help the NEVR sort correctly, whereas git hashes for instance will > > certainly not help. Upstreams have been known to change SCMs from time > > to time, as well. I realize we're supposed to bump the "0.n" part, > > but I'd just as soon the upstream-ID part was likely to sort correctly > > as well. > > I really think the 0.n part is sufficient for this. You can always just > bump it to avoid, really, any kind of difficulty. For example, the very > case that prompted my aside: I just had to bump the 0.n part one digit > to ensure that correcting the rest of the tag - which involved > substantial changes, which would have ordered completely differently > without the 0.n part - wouldn't cause any problems. > The Release tag serves multiple audiences. For packagers and developers of the software, the revision id portion is usually what we want but (as tgl pointed out) the date still comes in handy if upstream changes their SCM. For endusers, the date is more handy for seeing whether the package is based on newer or older upstream versions than the scm's hash. -Toshio pgphPVTmu8Jkq.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Thu, Jul 26, 2012 at 5:37 PM, Adam Williamson wrote:
> On Thu, 2012-07-26 at 13:47 -0500, Jon Ciesla wrote:
>> On Thu, Jul 26, 2012 at 1:41 PM, Bill Nottingham wrote:
>> > Jonathan Dieter (jdie...@lesbg.com) said:
>> >> On Wed, 2012-07-25 at 18:24 -0400, Bill Nottingham wrote:
>> >> > Package numptyphysics (fails to build)
>> >>
>> >> I've updated this to build and posted at
>> >> https://bugzilla.redhat.com/show_bug.cgi?id=843250
>> >>
>> >> If a package FTBFS and the current maintainer doesn't fix it, will we
>> >> have a chance to take ownership of it before it gets blocked?
>> >
>> > I'd suggest finding a willing provenpackager to help you fix it
>> > if you can't get the maintainer to apply or approve a comaintainership
>> > request.
>>
>> I'm a PP and I've helped with several of Lubo's pacakges in the past.
>> I'm willing to help with this if you like.
>
> Just for the record - Jon went ahead and applied Jonathan's patch, but
> it did not correctly follow the pre-release naming guidelines:
D'oh! Sorry, I was blinded by the BuildRequires*.
> https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages
>
> I've gone ahead and pushed a further build which simply corrects this.
> The incorrect NEVR that Jonathan's patch included was
> 0.1.git.20120726.a22cde2%{?dist} . The date is supposed to come before
> 'git', and there are not supposed to be periods between 'git',
> '20120726' and 'a22cde2'. I corrected these errors and bumped the rev,
> so the new build uses a NEVR of 0.2.20120726gita22cde2%{?dist} .
>
> (FWIW, I'm not sure the guidelines are appropriate for Modern Times; the
> date of checkout was only really the most important thing back in the
> days of CVS, where there was really no such thing as a canonical
> revision for the entire project. These days every modern RCS, as far as
> I'm aware, includes the notion of a canonical revision - yet we still
> *require* the date and make it *optional* to include a specific revision
> ID, even though the revision ID is clearly more accurate and specific
> than a date. Maybe we ought to make the revision the key thing to
> include, and make the date optional, except in the special case of the
> few projects still using CVS. Would the packaging committee be
> interested in a proposal? Am I wrong? The date is useful for making it
> immediately obvious how up-to-date a package is, I guess, but it has no
> really key function for differentiating builds any more.)
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
> http://www.happyassassin.net
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
*strung up like a deuce and somethingsomething in the night. . .
--
http://cecinestpasunefromage.wordpress.com/
in your fear, seek only peace
in your fear, seek only love
-d. bowie
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Fri, Jul 27, 2012 at 08:19:50AM +0100, Peter Robinson wrote: > On Fri, Jul 27, 2012 at 3:26 AM, Adam Williamson wrote: > > (I don't know if it'd make sense to bump parted to 3.1 in F17. Probably > > not.) > > Please no, it had changed that caused problems when it was bumped in > rawhide that may or may not have been pulled back. I don't think it's > worth the risk. Actually parted 3.1 fixes a major bug in 3.0: that it sends error messages to stdout which makes it virtually impossible to parse the output of the parted command in programs (RHBZ#745606). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Fri, Jul 27, 2012 at 3:26 AM, Adam Williamson wrote: > On Thu, 2012-07-26 at 15:45 -0700, Adam Williamson wrote: >> On Thu, 2012-07-26 at 13:15 +0200, Michael Schwendt wrote: >> > > Package qtparted (fails to build) >> > >> > H... >> > >> > http://bugz.fedoraproject.org/qtparted >> > >> > 750566 Fedora new qtparted won't install because it is from F15 >> > and requires libparted.so.0, and F16 has so.1 >> > 802782 Fedora new qtparted fails to install due to missing >> > dependency >> > 715847 Fedora new FTBFS qtparted-0.4.5-26.fc15 >> > 502802 Fedora new switch to using PolicyKit >> > >> > # yum list qtparted|tail -1 >> > qtparted.x86_64 0.4.5-26.fc15 >> > fedora >> > >> > http://qtparted.sourceforge.net/ >> > lists 0.5.0 (stable), but that's probably an old release, too. >> >> There's a 0.6.0 release available from the sourceforge Files page. It >> claims to support parted 3.0 and later. I'll grab that and see if I can >> get it to fly. > > So, I got 0.6.0 building against Rawhide. There's a bit of a problem, > though - it doesn't build against F17. > > F17 has parted 3.0. Rawhide has parted 3.1. parted 3.1 restored some > bits of API that 3.0 removed, and that qtparted uses. So it can build > against 3.1, but not 3.0. > > I don't have a Rawhide install handy. I just tried upgrading a VM to > Rawhide but I can't get X to run on it at all. So I can't test the > build, because I can't run Rawhide and I can't build qtparted in a way > that'll work on F17 so I can test it there. > > So reluctantly I've pushed the build through to Rawhide blind. If anyone > has a functioning Rawhide install and can test it, I'd really appreciate > it. Particularly I'd like to know if the usermode stuff works - i.e. if > you try and run it as a regular user, does it prompt for root password > and correctly run as root? Also is it still _necessary_ - if you bypass > the usermode stuff and run qtparted directly as a regular user (just > call /usr/sbin/qtparted directly), does it handle privilege escalation > on its own when necessary? If so, we can drop the usermode guff. Aside > from that, just the usual 'does it actually run/work' smoke test. > thanks! I have a netbook running rawhide, I'll try and test it over the weekend. > (I don't know if it'd make sense to bump parted to 3.1 in F17. Probably > not.) Please no, it had changed that caused problems when it was bumped in rawhide that may or may not have been pulled back. I don't think it's worth the risk. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Thu, 2012-07-26 at 15:45 -0700, Adam Williamson wrote: > On Thu, 2012-07-26 at 13:15 +0200, Michael Schwendt wrote: > > > Package qtparted (fails to build) > > > > H... > > > > http://bugz.fedoraproject.org/qtparted > > > > 750566 Fedora new qtparted won't install because it is from F15 > > and requires libparted.so.0, and F16 has so.1 > > 802782 Fedora new qtparted fails to install due to missing > > dependency > > 715847 Fedora new FTBFS qtparted-0.4.5-26.fc15 > > 502802 Fedora new switch to using PolicyKit > > > > # yum list qtparted|tail -1 > > qtparted.x86_64 0.4.5-26.fc15 > > fedora > > > > http://qtparted.sourceforge.net/ > > lists 0.5.0 (stable), but that's probably an old release, too. > > There's a 0.6.0 release available from the sourceforge Files page. It > claims to support parted 3.0 and later. I'll grab that and see if I can > get it to fly. So, I got 0.6.0 building against Rawhide. There's a bit of a problem, though - it doesn't build against F17. F17 has parted 3.0. Rawhide has parted 3.1. parted 3.1 restored some bits of API that 3.0 removed, and that qtparted uses. So it can build against 3.1, but not 3.0. I don't have a Rawhide install handy. I just tried upgrading a VM to Rawhide but I can't get X to run on it at all. So I can't test the build, because I can't run Rawhide and I can't build qtparted in a way that'll work on F17 so I can test it there. So reluctantly I've pushed the build through to Rawhide blind. If anyone has a functioning Rawhide install and can test it, I'd really appreciate it. Particularly I'd like to know if the usermode stuff works - i.e. if you try and run it as a regular user, does it prompt for root password and correctly run as root? Also is it still _necessary_ - if you bypass the usermode stuff and run qtparted directly as a regular user (just call /usr/sbin/qtparted directly), does it handle privilege escalation on its own when necessary? If so, we can drop the usermode guff. Aside from that, just the usual 'does it actually run/work' smoke test. thanks! (I don't know if it'd make sense to bump parted to 3.1 in F17. Probably not.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Thu, 2012-07-26 at 19:52 -0400, Tom Lane wrote: > Jesse Keating writes: > > On Thu, 2012-07-26 at 15:37 -0700, Adam Williamson wrote: > >> The date is useful for making it > >> immediately obvious how up-to-date a package is, I guess, but it has no > >> really key function for differentiating builds any more.) > > > It's not even that. With CVS you could have done a checkout of a tag > > which could be quite old compared to the day's date you did the > > checkout. Using the date somewhat assumes you're doing a checkout of > > HEAD, which isn't always the case. I'd move that embedding the date in > > there is of little use. > > The good thing about putting the date in there is that it's likely to > help the NEVR sort correctly, whereas git hashes for instance will > certainly not help. Upstreams have been known to change SCMs from time > to time, as well. I realize we're supposed to bump the "0.n" part, > but I'd just as soon the upstream-ID part was likely to sort correctly > as well. I really think the 0.n part is sufficient for this. You can always just bump it to avoid, really, any kind of difficulty. For example, the very case that prompted my aside: I just had to bump the 0.n part one digit to ensure that correcting the rest of the tag - which involved substantial changes, which would have ordered completely differently without the 0.n part - wouldn't cause any problems. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
Bruno Wolff III writes: > On Wed, Jul 25, 2012 at 18:24:52 -0400, >Bill Nottingham wrote: >> Updated with new list of packages that have failed to build. >> Package stratagus (fails to build) > statagus is currently FTBFS because it isn't using the newer libpng API. > Assuming that's all that's wrong with it, I'll be able to fix this soon. FWIW, quite a few of the packages in Bill's FTBFS list have dependencies on libpng-compat, which makes me suspicious that the libpng API changes might be the reason (or one reason) why they FTBFS. I've spent this afternoon preparing patches for the remaining old-libpng dependencies that are *not* on that list. I'm willing to help out with libpng issues in these too, assuming that their maintainers care about keeping them alive. I'm still hoping to kill libpng-compat (and libtiff-compat) before we branch F18. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
Jesse Keating writes: > On Thu, 2012-07-26 at 15:37 -0700, Adam Williamson wrote: >> The date is useful for making it >> immediately obvious how up-to-date a package is, I guess, but it has no >> really key function for differentiating builds any more.) > It's not even that. With CVS you could have done a checkout of a tag > which could be quite old compared to the day's date you did the > checkout. Using the date somewhat assumes you're doing a checkout of > HEAD, which isn't always the case. I'd move that embedding the date in > there is of little use. The good thing about putting the date in there is that it's likely to help the NEVR sort correctly, whereas git hashes for instance will certainly not help. Upstreams have been known to change SCMs from time to time, as well. I realize we're supposed to bump the "0.n" part, but I'd just as soon the upstream-ID part was likely to sort correctly as well. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Thu, 2012-07-26 at 15:37 -0700, Adam Williamson wrote: > The date is useful for making it > immediately obvious how up-to-date a package is, I guess, but it has no > really key function for differentiating builds any more.) It's not even that. With CVS you could have done a checkout of a tag which could be quite old compared to the day's date you did the checkout. Using the date somewhat assumes you're doing a checkout of HEAD, which isn't always the case. I'd move that embedding the date in there is of little use. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Thu, 2012-07-26 at 13:15 +0200, Michael Schwendt wrote: > > Package qtparted (fails to build) > > H... > > http://bugz.fedoraproject.org/qtparted > > 750566Fedora new qtparted won't install because it is from F15 > and requires libparted.so.0, and F16 has so.1 > 802782Fedora new qtparted fails to install due to missing > dependency > 715847Fedora new FTBFS qtparted-0.4.5-26.fc15 > 502802Fedora new switch to using PolicyKit > > # yum list qtparted|tail -1 > qtparted.x86_64 0.4.5-26.fc15 > fedora > > http://qtparted.sourceforge.net/ > lists 0.5.0 (stable), but that's probably an old release, too. There's a 0.6.0 release available from the sourceforge Files page. It claims to support parted 3.0 and later. I'll grab that and see if I can get it to fly. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Thu, 2012-07-26 at 13:47 -0500, Jon Ciesla wrote:
> On Thu, Jul 26, 2012 at 1:41 PM, Bill Nottingham wrote:
> > Jonathan Dieter (jdie...@lesbg.com) said:
> >> On Wed, 2012-07-25 at 18:24 -0400, Bill Nottingham wrote:
> >> > Package numptyphysics (fails to build)
> >>
> >> I've updated this to build and posted at
> >> https://bugzilla.redhat.com/show_bug.cgi?id=843250
> >>
> >> If a package FTBFS and the current maintainer doesn't fix it, will we
> >> have a chance to take ownership of it before it gets blocked?
> >
> > I'd suggest finding a willing provenpackager to help you fix it
> > if you can't get the maintainer to apply or approve a comaintainership
> > request.
>
> I'm a PP and I've helped with several of Lubo's pacakges in the past.
> I'm willing to help with this if you like.
Just for the record - Jon went ahead and applied Jonathan's patch, but
it did not correctly follow the pre-release naming guidelines:
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages
I've gone ahead and pushed a further build which simply corrects this.
The incorrect NEVR that Jonathan's patch included was
0.1.git.20120726.a22cde2%{?dist} . The date is supposed to come before
'git', and there are not supposed to be periods between 'git',
'20120726' and 'a22cde2'. I corrected these errors and bumped the rev,
so the new build uses a NEVR of 0.2.20120726gita22cde2%{?dist} .
(FWIW, I'm not sure the guidelines are appropriate for Modern Times; the
date of checkout was only really the most important thing back in the
days of CVS, where there was really no such thing as a canonical
revision for the entire project. These days every modern RCS, as far as
I'm aware, includes the notion of a canonical revision - yet we still
*require* the date and make it *optional* to include a specific revision
ID, even though the revision ID is clearly more accurate and specific
than a date. Maybe we ought to make the revision the key thing to
include, and make the date optional, except in the special case of the
few projects still using CVS. Would the packaging committee be
interested in a proposal? Am I wrong? The date is useful for making it
immediately obvious how up-to-date a package is, I guess, but it has no
really key function for differentiating builds any more.)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Thu, 2012-07-26 at 13:47 -0500, Jon Ciesla wrote: > On Thu, Jul 26, 2012 at 1:41 PM, Bill Nottingham wrote: > > Jonathan Dieter (jdie...@lesbg.com) said: > >> On Wed, 2012-07-25 at 18:24 -0400, Bill Nottingham wrote: > >> > Package numptyphysics (fails to build) > >> > >> I've updated this to build and posted at > >> https://bugzilla.redhat.com/show_bug.cgi?id=843250 > >> > >> If a package FTBFS and the current maintainer doesn't fix it, will we > >> have a chance to take ownership of it before it gets blocked? > > > > I'd suggest finding a willing provenpackager to help you fix it > > if you can't get the maintainer to apply or approve a comaintainership > > request. > > I'm a PP and I've helped with several of Lubo's pacakges in the past. > I'm willing to help with this if you like. That would be much appreciated, but it was meant to be more of a general question about what the procedure is for blocking FTBFS packages. Anyhow, if you're happy to apply the fix and Lubo doesn't mind, I sure won't complain. A number of my students love numptyphysics and I'd hate to see it lost. Jonathan signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Wed, Jul 25, 2012 at 4:24 PM, Bill Nottingham wrote: > Package gnofract4d (fails to build) > comaintained by: firewing Fixed in Rawhide, with F16 and F17 builds coming soon. Firewing is both maintainer and comaintainer; I've applied to comaintain. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Thu, 2012-07-26 at 13:47 -0500, Jon Ciesla wrote: > On Thu, Jul 26, 2012 at 1:41 PM, Bill Nottingham wrote: > > Jonathan Dieter (jdie...@lesbg.com) said: > >> On Wed, 2012-07-25 at 18:24 -0400, Bill Nottingham wrote: > >> > Package numptyphysics (fails to build) > >> > >> I've updated this to build and posted at > >> https://bugzilla.redhat.com/show_bug.cgi?id=843250 > >> > >> If a package FTBFS and the current maintainer doesn't fix it, will we > >> have a chance to take ownership of it before it gets blocked? > > > > I'd suggest finding a willing provenpackager to help you fix it > > if you can't get the maintainer to apply or approve a comaintainership > > request. > > I'm a PP and I've helped with several of Lubo's pacakges in the past. > I'm willing to help with this if you like. I think I saw one or two similar posts earlier in the thread and was planning to go through the whole thread again and take care of any cases where a PP was needed, but help welcome! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Wed, 2012-07-25 at 18:24 -0400, Bill Nottingham wrote: > Updated with new list of packages that have failed to build. > Package fbdesk (fails to build) > Package gimmix (fails to build) > Package libopensync-plugin-opie (fails to build) Fixed. -- Andreas Bierfert signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Thu, Jul 26, 2012 at 1:41 PM, Bill Nottingham wrote: > Jonathan Dieter (jdie...@lesbg.com) said: >> On Wed, 2012-07-25 at 18:24 -0400, Bill Nottingham wrote: >> > Package numptyphysics (fails to build) >> >> I've updated this to build and posted at >> https://bugzilla.redhat.com/show_bug.cgi?id=843250 >> >> If a package FTBFS and the current maintainer doesn't fix it, will we >> have a chance to take ownership of it before it gets blocked? > > I'd suggest finding a willing provenpackager to help you fix it > if you can't get the maintainer to apply or approve a comaintainership > request. I'm a PP and I've helped with several of Lubo's pacakges in the past. I'm willing to help with this if you like. -J > Bill > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
Jonathan Dieter (jdie...@lesbg.com) said: > On Wed, 2012-07-25 at 18:24 -0400, Bill Nottingham wrote: > > Package numptyphysics (fails to build) > > I've updated this to build and posted at > https://bugzilla.redhat.com/show_bug.cgi?id=843250 > > If a package FTBFS and the current maintainer doesn't fix it, will we > have a chance to take ownership of it before it gets blocked? I'd suggest finding a willing provenpackager to help you fix it if you can't get the maintainer to apply or approve a comaintainership request. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
80 (karlthe...@gmail.com) said:
> libgtksourceviewmm can be safely (?) dropped since it is no more
> actively maintained and all packages i'm aware of that relied on it
> moved to newer gtksourceviewmm{,3} packages (repoquery didn't find any
> other packages relying on it)
If you want to get this accomplished before it happens automatically,
please follow the procedure at:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
> Package txt2man (fails to build) Fixed. Everything needed to fix it was in the f15 branch, whereas master was older and incomplete and had failed to build for f16 already. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Thu, Jul 26, 2012 at 18:55:19 +0400, Peter Lemenkov wrote: 2012/7/26 Bruno Wolff III : Package stratagus (fails to build) statagus is currently FTBFS because it isn't using the newer libpng API. Assuming that's all that's wrong with it, I'll be able to fix this soon. Just fyi - there is a new version 2.2.6 released and it seems that the development was restarted: I actually checked upstream status briefly to see if it was likely worth keeping stratagus around. Seeing there was an update available was encouraging. * http://stratagus.sourceforge.net/ * https://launchpad.net/stratagus/ Btw I don't feel like I'm a good maintainer for that - is anyone interested in (co)maintainership? I'll apply as a co-maintainer, though I stretched pretty thin and probably won't put a lot of time into it. Initially I'll probably just do the libpng fix. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
2012/7/26 Bruno Wolff III : >> Package stratagus (fails to build) > > > statagus is currently FTBFS because it isn't using the newer libpng API. > Assuming that's all that's wrong with it, I'll be able to fix this soon. Just fyi - there is a new version 2.2.6 released and it seems that the development was restarted: * http://stratagus.sourceforge.net/ * https://launchpad.net/stratagus/ Btw I don't feel like I'm a good maintainer for that - is anyone interested in (co)maintainership? -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Wed, Jul 25, 2012 at 18:24:52 -0400, Bill Nottingham wrote: Updated with new list of packages that have failed to build. Package stratagus (fails to build) statagus is currently FTBFS because it isn't using the newer libpng API. Assuming that's all that's wrong with it, I'll be able to fix this soon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Wed, 2012-07-25 at 18:24 -0400, Bill Nottingham wrote: > Package numptyphysics (fails to build) I've updated this to build and posted at https://bugzilla.redhat.com/show_bug.cgi?id=843250 If a package FTBFS and the current maintainer doesn't fix it, will we have a chance to take ownership of it before it gets blocked? Jonathan signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
> Package qtparted (fails to build) H... http://bugz.fedoraproject.org/qtparted 750566 Fedora new qtparted won't install because it is from F15 and requires libparted.so.0, and F16 has so.1 802782 Fedora new qtparted fails to install due to missing dependency 715847 Fedora new FTBFS qtparted-0.4.5-26.fc15 502802 Fedora new switch to using PolicyKit # yum list qtparted|tail -1 qtparted.x86_64 0.4.5-26.fc15 fedora http://qtparted.sourceforge.net/ lists 0.5.0 (stable), but that's probably an old release, too. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
> Package audtty (fails to build) Fixed (as this has been spotted on Dennis' list a few days ago already). -- Fedora release 17 (Beefy Miracle) - Linux 3.4.6-2.fc17.x86_64 loadavg: 0.14 0.13 0.24 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Thu, 26 Jul 2012 09:54:03 +0200, 80 wrote:
> Hi,
>
> libgtksourceviewmm can be safely (?) dropped since it is no more
> actively maintained and all packages i'm aware of that relied on it
> moved to newer gtksourceviewmm{,3} packages (repoquery didn't find any
> other packages relying on it)
>
> repoquery --whatrequires "libgtksourceviewmm-1.0.so.2()(64bit)"
> libgtksourceviewmm-devel-1:0.3.1-7.fc15.x86_64
You can simply run "repoquery --whatrequires libgtksourceviewmm" which
defaults to the --alldeps option.
--
Fedora release 17 (Beefy Miracle) - Linux 3.4.6-2.fc17.x86_64
loadavg: 0.29 0.21 0.31
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
Hi,
libgtksourceviewmm can be safely (?) dropped since it is no more
actively maintained and all packages i'm aware of that relied on it
moved to newer gtksourceviewmm{,3} packages (repoquery didn't find any
other packages relying on it)
repoquery --whatrequires "libgtksourceviewmm-1.0.so.2()(64bit)"
libgtksourceviewmm-devel-1:0.3.1-7.fc15.x86_64
best regards,
H.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Wed, Jul 25, 2012 at 04:41:09PM -0700, Adam Williamson wrote: > On Wed, 2012-07-25 at 23:53 +0100, Richard W.M. Jones wrote: > > On Wed, Jul 25, 2012 at 06:24:52PM -0400, Bill Nottingham wrote: > > > Package rpmdepsize (fails to build) > > > comaintained by: rjones > > > > Wooaa there, this is the first time I'm aware this one FTBFS. > > See the discussion in the v3 thread, just today. It was discovered that > there are a number of packages that have been FTBFS since F15 or earlier > but which weren't previously included in the list. Yes, I saw that thanks. Re rpmdepsize, there is a build problem in F17 which I'm fixing. I can't fix this for F18 yet because we're waiting for an upstream fix in a dependent package. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
> Package Panini (fails to build) > Package fedora-idm-console (fails to build) > comaintained by: rmeggins > Package gdmap (fails to build) For these packages, I have filed patches to fix them in the bugzilla bugs. > Package python-batchhttp (orphan) I have taken over this one. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Wed, 2012-07-25 at 23:53 +0100, Richard W.M. Jones wrote: > On Wed, Jul 25, 2012 at 06:24:52PM -0400, Bill Nottingham wrote: > > Package rpmdepsize (fails to build) > > comaintained by: rjones > > Wooaa there, this is the first time I'm aware this one FTBFS. See the discussion in the v3 thread, just today. It was discovered that there are a number of packages that have been FTBFS since F15 or earlier but which weren't previously included in the list. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Wed, Jul 25, 2012 at 06:24:52PM -0400, Bill Nottingham wrote: > Package rpmdepsize (fails to build) > comaintained by: rjones Wooaa there, this is the first time I'm aware this one FTBFS. (I'm sure there may have been a BZ, but I have 1000s of BZs open and the Bugzilla "UI" makes them impossible to cope with.) This one won't build in F18 because it requires ocaml-sexplib where we're still waiting for an upstream fix, and that's something that cannot be helped at the moment. I will do a F17 build soon, fixing things if necessary. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[ACTION REQUIRED v4] Retiring packages for F-18
Updated with new list of packages that have failed to build. Before we branch for Fedora 18, as is custom, we will block currently orphaned packages and packages that have failed to build since Fedora 16. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. If no one claims any of these packages, they will be blocked before we branch for Fedora 18. That is currently scheduled to happen on or around August 7th. Note that if you're receiving this mail directly, it's because you are a co-maintainer of one of these packages. Please work with your comaintainers to take up maintenance if you desire. Package Panini (fails to build) Package UnihanDb (fails to build) Package alevt (fails to build) Package apache-commons-launcher (fails to build) Package archmage (orphan) Package audtty (fails to build) Package autoarchive (fails to build) Package boolstuff (orphan) Package boolstuff (orphan) Package cmucl (orphan) comaintained by: green Package eboard (fails to build) Package eclipse-collabnet-merge (fails to build) Package eclipse-emf-query (fails to build) Package eclipse-emf-transaction (fails to build) Package eclipse-emf-validation (fails to build) Package eclipse-m2m-qvtoml (fails to build) Package eclipse-mdt-ocl (fails to build) Package eclipse-mdt-uml2 (fails to build) Package ext3grep (fails to build) Package ezmorph (fails to build) Package fbdesk (fails to build) Package fedora-idm-console (fails to build) comaintained by: rmeggins Package fillmore-lombard (fails to build) comaintained by: salimma Package freenx-client (fails to build) Package gant (fails to build) Package gconf-cleaner (fails to build) Package gdmap (fails to build) Package gimmix (fails to build) Package globalplatform (orphan) Package gnofract4d (fails to build) comaintained by: firewing Package gnome-do-docklets (fails to build) Package gnome-speech (fails to build) Package gooddata-cl (fails to build) Package gpshell (orphan) Package gtkmm-utils (orphan) Package gtkmm-utils (orphan) Package hamster-applet (orphan) Package hartke-aurulent-sans-fonts (orphan) Package ibus-table-code (fails to build) Package ibus-table-others (fails to build) comaintained by: nkumar Package jpoker (fails to build) Package json (orphan) Package json-lib (fails to build) Package k12linux-quick-start-guide (orphan) Package kadu (fails to build) comaintained by: gajownik radekl Package komparator (fails to build) Package krecipes (fails to build) Package ksplice (fails to build) Package libcrystalhd (fails to build) comaintained by: kwizart Package libgdbus (fails to build) Package libgtkhotkey (orphan) Package libgtksourceviewmm (fails to build) Package libharu (fails to build) Package libhid (fails to build) Package libkml (fails to build) Package libmnetutil (fails to build) Package libopensync-plugin-opie (fails to build) Package libpano12 (fails to build) Package libqttracker (fails to build) comaintained by: jreznik Package libsoup22 (orphan) Package libsoup22 (orphan) Package libvpd (fails to build) comaintained by: lnykryn Package lsvpd (fails to build) comaintained by: lnykryn Package metapixel (fails to build) Package mimetic (fails to build) Package mod_scgi (fails to build) Package munipack (fails to build) Package natus (fails to build) Package ntfs-config (fails to build) Package numptyphysics (fails to build) Package nvi (orphan) Package openoffice.org-diafilter (fails to build) Package perl-Nagios-Plugin-Beanstalk (orphan) Package pfqueue (orphan) Package php-pear-File-Find (fails to build) Package pianobooster (fails to build) Package pino (fails to build) Package pngcrush (fails to build) Package polyester (orphan) Package polyester3 (orphan) Package postgresql-odbcng (fails to build) Package printoxx (fails to build) Package putty (fails to build) comaintained by: tremble Package pxe-kexec (fails to build) Package python-batchhttp (orphan) Package python-chm (orphan) Package python-modjkapi (fails to build) Package python-pywt (fails to build) Package python-remoteobjects (orphan) Package python-typepad (orphan) Package qalculate-kde (fails to build) Package qtparted (fails to build) Package quesoglc (fails to build) Package ragel (fails to build) Package raul (fails to build) Package rpmdepsize (fails to build) comaintained by: rjones Package scite (fails to build) Package selenium-core (fails to build) Package selenium-remote-control (fails to build) Package sofsip-cli (fails to build) comaintained by: itamarjp Package specto (fails to build) Package stratagus (fails to build) Package subcommander (fails to build) Package svnkit (fails to build) Package tangogps (fails to build) Package tesseract (fails to build) Package torque (orphan) Package txt2man (fails to build) Package typepad-motion (orphan) Package upstart (orphan) Package winwrangler (orpha
