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 (orphan) Package wmfire (fails to build) Package xaos (fails to build) Package xdrawchem (fails to build) Package xesam-glib (fails to build) Package yaws (fails to build) comaintained by: peter
List of deps left behind by packages which are orphaned or fail to build:
Removing: freenx-client kdenetwork requires pkgconfig(nxcl) = 1.0
Removing: gnome-speech dasher requires gnome-speech = 0.4.25-5.fc15 dasher requires gnome-speech-devel = 0.4.25-5.fc15 gok requires libgnomespeech.so.7 gok requires gnome-speech-devel = 0.4.25-5.fc15
Removing: ksplice fedora-ksplice requires ksplice = 0.9.9-2.fc15
Removing: libgtkhotkey synapse requires libgtkhotkey.so.1
Removing: libharu EMBOSS requires libhpdf-2.1.0.so EMBOSS requires libharu-devel = 2.1.0-3.fc15 EMBOSS-libs requires libhpdf-2.1.0.so libeplplot requires libhpdf-2.1.0.so perl-PDF-Haru requires libhpdf-2.1.0.so perl-PDF-Haru requires libharu-devel = 2.1.0-3.fc15
Removing: libmnetutil libmcrypto requires libmnetutil-devel = 0.8.0-0.3.20100629svn3775.fc15 libmcrypto requires libmnetutil.so.0 libmcrypto-devel requires pkgconfig(libmnetutil) = 0.8.0+r libmikey requires libmnetutil-devel = 0.8.0-0.3.20100629svn3775.fc15 libmikey requires libmnetutil.so.0 libmsip requires libmnetutil-devel = 0.8.0-0.3.20100629svn3775.fc15 libmsip requires libmnetutil.so.0 libmsip-devel requires pkgconfig(libmnetutil) = 0.8.0+r libmstun requires libmnetutil-devel = 0.8.0-0.3.20100629svn3775.fc15 libmstun requires libmnetutil.so.0 libmstun-devel requires pkgconfig(libmnetutil) = 0.8.0+r
Removing: libsoup22 libopensync-plugin-syncml requires libsoup22-devel = 2.2.105-9.fc15 libsyncml requires libsoup-2.2.so.8 libsyncml requires libsoup22-devel = 2.2.105-9.fc15
Removing: php-pear-File-Find php-pear-PHP-CompatInfo requires php-pear(File_Find) = 1.3.1
Removing: pngcrush gimp-help requires pngcrush = 1.6.10-7.fc15
Removing: printoxx fotoxx requires printoxx = 2.8.1-2.fc15
Removing: python-batchhttp django-typepad requires python-batchhttp = 1.1-5.fc18
Removing: python-chm chm2pdf requires python-chm = 0.8.4-12.fc18
Removing: python-modjkapi taboot-func requires python-modjkapi = 0.1.2.28-7.fc15
Removing: python-remoteobjects django-typepad requires python-remoteobjects = 1.1-5.fc18
Removing: python-typepad django-typepad requires python-typepad = 1.1.2-5.fc18
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
Removing: ragel rubygem-hpricot requires ragel = 6.6-3.fc15
Removing: selenium-core perl-Test-WWW-Selenium requires selenium-core = 1.0.2-0.5.20100324svn.fc15 selenium-remote-control requires selenium-core = 1.0.2-0.5.20100324svn.fc15
Removing: selenium-remote-control perl-Alien-SeleniumRC requires selenium-server = 1.0.3-8.20100318svn.fc15
Removing: svnkit eclipse-subclipse requires eclipse-svnkit = 1.3.4-2.fc15
Removing: tesseract tucan requires tesseract = 3.00-2.fc15
Removing: torque pbstop requires torque-client = 3.0.4-1.fc17 pdsh requires torque-devel = 3.0.4-1.fc17 pdsh-mod-torque requires torque = 3.0.4-1.fc17 pdsh-mod-torque requires libtorque.so.2 perl-PBS requires libtorque.so.2 perl-PBS requires libtorque-devel = 3.0.4-1.fc17 python-pbs requires torque-devel = 3.0.4-1.fc17 python-pbs requires libtorque.so.2 python3-pbs requires libtorque.so.2
Removing: txt2man OpenImageIO requires txt2man = 1.5.6-1.fc15 duply requires txt2man = 1.5.6-1.fc15 rfcdiff requires txt2man = 1.5.6-1.fc15 solfege requires txt2man = 1.5.6-1.fc15
Removing: upstart clamav-milter-upstart requires /sbin/initctl clamav-scanner-upstart requires /sbin/initctl dhcp-forwarder-upstart requires /sbin/initctl ip-sentinel-upstart requires /sbin/initctl milter-greylist-upstart requires /sbin/initctl tor-upstart requires /sbin/initctl
The script that generated this page can be found at https://fedorahosted.org/rel-eng/browser/scripts/find-unblocked-orphans.py There you can also report bugs and RFEs.
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.
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.
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.
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.
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.
80 (karlthered@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
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.
Package qtparted (fails to build)
Hmmmm...
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.
On Thu, 2012-07-26 at 13:15 +0200, Michael Schwendt wrote:
Package qtparted (fails to build)
Hmmmm...
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.
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)
Hmmmm...
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.)
On Fri, Jul 27, 2012 at 3:26 AM, Adam Williamson awilliam@redhat.com 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)
Hmmmm...
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
On Fri, Jul 27, 2012 at 08:19:50AM +0100, Peter Robinson wrote:
On Fri, Jul 27, 2012 at 3:26 AM, Adam Williamson awilliam@redhat.com 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.
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
Jonathan Dieter (jdieter@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
On Thu, Jul 26, 2012 at 1:41 PM, Bill Nottingham notting@redhat.com wrote:
Jonathan Dieter (jdieter@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
On Thu, 2012-07-26 at 13:47 -0500, Jon Ciesla wrote:
On Thu, Jul 26, 2012 at 1:41 PM, Bill Nottingham notting@redhat.com wrote:
Jonathan Dieter (jdieter@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!
On Thu, 2012-07-26 at 13:47 -0500, Jon Ciesla wrote:
On Thu, Jul 26, 2012 at 1:41 PM, Bill Nottingham notting@redhat.com wrote:
Jonathan Dieter (jdieter@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
On Thu, 2012-07-26 at 13:47 -0500, Jon Ciesla wrote:
On Thu, Jul 26, 2012 at 1:41 PM, Bill Nottingham notting@redhat.com wrote:
Jonathan Dieter (jdieter@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_packag...
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.)
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 jkeating@redhat.com 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
On Thu, 2012-07-26 at 19:52 -0400, Tom Lane wrote:
Jesse Keating jkeating@redhat.com 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.
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 jkeating@redhat.com 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
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.
On Fri, Jul 27, 2012 at 1:11 PM, Jesse Keating jkeating@redhat.com 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
On Fri, Jul 27, 2012 at 1:26 PM, Jesse Keating jkeating@redhat.com 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
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.
On Fri, Jul 27, 2012 at 1:38 PM, Jesse Keating jkeating@redhat.com 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
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
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.
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.
On Thu, Jul 26, 2012 at 5:37 PM, Adam Williamson awilliam@redhat.com wrote:
On Thu, 2012-07-26 at 13:47 -0500, Jon Ciesla wrote:
On Thu, Jul 26, 2012 at 1:41 PM, Bill Nottingham notting@redhat.com wrote:
Jonathan Dieter (jdieter@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_packag...
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. . .
On Wed, Jul 25, 2012 at 18:24:52 -0400, Bill Nottingham notting@redhat.com 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.
2012/7/26 Bruno Wolff III bruno@wolff.to:
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?
On Thu, Jul 26, 2012 at 18:55:19 +0400, Peter Lemenkov lemenkov@gmail.com wrote:
2012/7/26 Bruno Wolff III bruno@wolff.to:
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.
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.
Bruno Wolff III bruno@wolff.to writes:
On Wed, Jul 25, 2012 at 18:24:52 -0400, Bill Nottingham notting@redhat.com 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
On Thu, Jul 26, 2012 at 20:13:18 -0400, Tom Lane tgl@redhat.com wrote:
I'm still hoping to kill libpng-compat (and libtiff-compat) before we branch F18.
Should libpng12 obsolete libpng-compat?
Bruno Wolff III bruno@wolff.to writes:
On Thu, Jul 26, 2012 at 20:13:18 -0400, Tom Lane tgl@redhat.com 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
On Thu, Jul 26, 2012 at 09:48:13 -0500, Bruno Wolff III bruno@wolff.to wrote:
On Wed, Jul 25, 2012 at 18:24:52 -0400, Bill Nottingham notting@redhat.com 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.
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.
On Wed, Jul 25, 2012 at 4:24 PM, Bill Nottingham notting@redhat.com 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.
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
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
On Mon, Jul 30, 2012 at 2:04 PM, Stewart Adam maillist@diffingo.com 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.