The following 30 packages, with respective FTBFS bugs, have been open since the Fedora 11 time frame, and continue to fail to build. These are the oldest non-building packages in the distribution, everything else (over 8800) managed to build for Fedora 12 or newer already.
awn-extras-applets-0.3.2.1-8.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511628 evolution-brutus-1.2.35-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511451 geronimo-specs-1.0-2.M2.fc10.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511494 gmfsk-0.7-0.6.pre1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511780 gnome-scan-0.6.2-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511591 Io-language-20071010-10.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511617 knm_new-fonts-1.1-5.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=555487 libFoundation-1.1.3-11.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511470 ohm-0.1.1-9.39.20091215git.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539200 perl-AnyEvent-XMPP-0.4-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511749 perl-Class-InsideOut-1.09-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539136 perl-Jemplate-0.23-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=538984 perl-MooseX-Traits-Attribute-CascadeClear-0.03-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511570 perl-RRD-Simple-1.43-3.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=464964 perl-SVN-Mirror-0.75-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511770 perl-SVN-Simple-0.27-7.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511729 prctl-1.4-5.2.1.src.rpm (last built July 12, 2006, ExclusiveArch ia64) python-openhpi-1.1-3.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511675 qtiplot-0.9-11.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511688 recordmydesktop-0.3.8.1-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=538931 skychart-3.0.1.5-6.20081026svn.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539202 smarteiffel-2.3-2.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511362 synce-kde-0.9.1-4.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539195 unifdef-1.171-8.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511553 widelands-0-0.13.Build13.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511430 xpilot-ng-4.7.2-16.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511717 xqilla10-1.0.2-6.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511599 xqilla-2.1.3-0.6.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511425
If these are removed, the whole list of RPMs to then drop looks like:
------------------------ Removing awn-extras-applets removes these: awn-extras-applets-devel-0:0.3.2.1-8.fc11.x86_64 awn-extras-applets-devel-0:0.3.2.1-8.fc11.i586 ------------------------ Removing evolution-brutus removes these: evolution-brutus-devel-0:1.2.35-2.fc11.i586 evolution-brutus-devel-0:1.2.35-2.fc11.x86_64 ------------------------ Removing geronimo-specs removes these: geronimo-specs-compat-0:1.0-2.M2.fc10.x86_64 ------------------------ Removing gmfsk removes these: ------------------------ Removing gnome-scan removes these: ------------------------ Removing Io-language removes these: Io-language-devel-0:20071010-10.fc11.i586 Io-language-graphics-and-sound-0:20071010-10.fc11.x86_64 Io-language-postgresql-0:20071010-10.fc11.x86_64 Io-language-extras-0:20071010-10.fc11.x86_64 Io-language-mysql-0:20071010-10.fc11.x86_64 Io-language-devel-0:20071010-10.fc11.x86_64 ------------------------ Removing knm_new-fonts removes these: ------------------------ Removing libFoundation removes these: libFoundation-devel-0:1.1.3-11.fc9.i386 libFoundation-devel-0:1.1.3-11.fc9.x86_64 ------------------------ Removing ohm removes these: ohm-devel-0:0.1.1-9.39.20091215git.fc11.i586 ------------------------ Removing perl-AnyEvent-XMPP removes these: ------------------------ Removing perl-Class-InsideOut removes these: ------------------------ Removing perl-Jemplate removes these: ------------------------ Removing perl-MooseX-Traits-Attribute-CascadeClear removes these: ------------------------ Removing perl-RRD-Simple removes these: ------------------------ Removing perl-SVN-Mirror removes these: ------------------------ Removing perl-SVN-Simple removes these: ------------------------ Removing prctl removes these: ------------------------ Removing python-openhpi removes these: ------------------------ Removing qtiplot removes these: ------------------------ Removing recordmydesktop removes these: qt-recordmydesktop-0:0.3.8-2.fc12.noarch gtk-recordmydesktop-0:0.3.8-2.fc12.noarch ------------------------ Removing skychart removes these: ------------------------ Removing smarteiffel removes these: smarteiffel-doc-0:2.3-2.fc9.x86_64 ------------------------ Removing synce-kde removes these: synce-kde-devel-0:0.9.1-4.fc11.i586 synce-kde-devel-0:0.9.1-4.fc11.x86_64 ------------------------ Removing unifdef removes these: ------------------------ Removing widelands removes these: ------------------------ Removing xpilot-ng removes these: ------------------------ Removing xqilla10 removes these: xqilla10-devel-0:1.0.2-6.fc11.x86_64 xqilla10-devel-0:1.0.2-6.fc11.i586 ------------------------ Removing xqilla removes these: dbxml-utils-0:2.4.16-0.5.fc12.x86_64 dbxml-python-0:2.4.16-0.5.fc12.x86_64 dbxml-devel-0:2.4.16-0.5.fc12.x86_64 dbxml-0:2.4.16-0.5.fc12.x86_64 xqilla-devel-0:2.1.3-0.6.fc11.x86_64 xqilla-devel-0:2.1.3-0.6.fc11.i586 dbxml-devel-0:2.4.16-0.5.fc12.i686 qpidd-xml-0:0.5.819819-1.fc13.x86_64
Of these, xqilla looks the most interesting, being used by the growing-popular qpid work.
I'd like to propose the above list be dropped from the distribution, prior to Fedora 13 Alpha freeze, unless the package is made to build in rawhide before that.
Thanks, Matt
On Fri, Jan 15, 2010 at 12:00:50AM -0600, Matt Domsch wrote:
recordmydesktop-0.3.8.1-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=538931
I just fixed this as provenpackager. The original maintainer seems to be unresponsive, because there was already another bug open since 2009-11-07 with a working patch attached.
The original maintainer is: Sindre Pedersen Bjørdal aka sindrepb https://admin.fedoraproject.org/pkgdb/users/packages/sindrepb
Regards Till
Matt Domsch píše v Pá 15. 01. 2010 v 00:00 -0600:
python-openhpi-1.1-3.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511675
finally got to fix it with a svn snapshot
Dan
On Fri, 2010-01-15 at 00:00 -0600, Matt Domsch wrote:
awn-extras-applets-0.3.2.1-8.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511628
Fixed this trivial one.
C.
2010/1/15 Matt Domsch Matt_Domsch@dell.com:
Removing geronimo-specs removes these: geronimo-specs-compat-0:1.0-2.M2.fc10.x86_64
Eek! I think geronimo-specs-compat is (transitively) needed by a bunch of other Java packages including maven; on my computer, "yum remove geronimo-specs" attempts to remove 45 packages (mostly maven-*). The issue is that geronimo-specs-compat has a bunch of virtual provides which don't show up in repoquery.
For reference, repoquery --whatrequires --recursive jms jacc jta ejb | wc -l returns 112 on my computer (F12, x86_64).
MEF
2010/1/15 Mary Ellen Foster mefoster@gmail.com:
2010/1/15 Matt Domsch Matt_Domsch@dell.com:
Removing geronimo-specs removes these: geronimo-specs-compat-0:1.0-2.M2.fc10.x86_64
Eek! I think geronimo-specs-compat is (transitively) needed by a bunch of other Java packages including maven; on my computer, "yum remove geronimo-specs" attempts to remove 45 packages (mostly maven-*). The issue is that geronimo-specs-compat has a bunch of virtual provides which don't show up in repoquery.
For reference, repoquery --whatrequires --recursive jms jacc jta ejb | wc -l returns 112 on my computer (F12, x86_64).
MEF
You can use:
$ repoquery --whatrequires --alldeps geronimo-specs-compat
To catch all the virtual provides.
On Fri, Jan 15, 2010 at 10:23:44AM +0000, Mary Ellen Foster wrote:
2010/1/15 Matt Domsch Matt_Domsch@dell.com:
Removing geronimo-specs removes these: geronimo-specs-compat-0:1.0-2.M2.fc10.x86_64
Eek! I think geronimo-specs-compat is (transitively) needed by a bunch of other Java packages including maven; on my computer, "yum remove geronimo-specs" attempts to remove 45 packages (mostly maven-*). The issue is that geronimo-specs-compat has a bunch of virtual provides which don't show up in repoquery.
For reference, repoquery --whatrequires --recursive jms jacc jta ejb | wc -l returns 112 on my computer (F12, x86_64).
OK, re-run, removing the three packages noted as fixed overnight.
----------------- Removing evolution-brutus also removes: evolution-brutus-devel-0:1.2.35-2.fc11.i586 evolution-brutus-devel-0:1.2.35-2.fc11.x86_64 ----------------- Removing geronimo-specs also removes: maven-shared-0:8-4.fc13.noarch maven2-plugin-pmd-0:2.0.8-3.fc12.noarch maven2-plugin-help-0:2.0.8-3.fc12.noarch maven2-plugin-changes-0:2.0.8-3.fc12.noarch maven-shared-verifier-0:1.2-4.fc13.noarch maven-shared-osgi-0:0.2.0-4.fc13.noarch maven-shared-file-management-0:1.2-4.fc13.noarch maven2-plugin-rar-0:2.0.8-3.fc12.noarch checkstyle-optional-0:4.1-7.fc12.noarch jython-demo-0:2.2.1-4.3.fc13.x86_64 maven-shared-plugin-testing-tools-0:1.0-4.fc13.noarch maven2-plugin-stage-0:2.0.8-3.fc12.noarch plexus-velocity-0:1.1.8-5.fc13.noarch maven-shared-downloader-0:1.2-4.fc13.noarch maven2-plugin-plugin-0:2.0.8-3.fc12.noarch maven2-plugin-idea-0:2.0.8-3.fc12.noarch castor-0:0.9.5-5.fc12.1.x86_64 maven-scm-0:1.2-4.fc13.noarch maven-shared-plugin-tools-model-0:2.2-4.fc13.noarch maven-surefire-report-maven-plugin-0:2.3-7.7.fc12.noarch xdoclet-0:1.2.3-11.4.fc12.x86_64 maven2-plugin-site-0:2.0.8-3.fc12.noarch maven-plugin-exec-0:1.1-1.fc12.noarch maven-surefire-maven-plugin-0:2.3-7.7.fc12.noarch maven-surefire-provider-junit4-0:2.3-7.7.fc12.noarch maven2-plugin-checkstyle-0:2.0.8-3.fc12.noarch maven-shared-app-configuration-model-0:1.1-4.fc13.noarch maven-shared-dependency-analyzer-0:1.0-4.fc13.noarch velocity-0:1.4-10.4.fc12.x86_64 maven2-plugin-clean-0:2.0.8-3.fc12.noarch maven-plugin-cobertura-0:2.3-3.fc12.noarch eclipse-pydev-mylyn-1:1.5.3-1.fc13.x86_64 maven-shared-io-0:1.1-4.fc13.noarch maven-shared-plugin-tools-beanshell-0:2.2-4.fc13.noarch pki-ca-0:1.3.0-6.fc13.noarch maven-shared-dependency-tree-0:1.1-4.fc13.noarch maven-shared-monitor-0:1.0-4.fc13.noarch maven2-plugin-changelog-0:2.0.8-3.fc12.noarch plexus-runtime-builder-0:1.0-0.4.a9.1.9.fc12.x86_64 maven-shared-plugin-tools-ant-0:2.2-4.fc13.noarch maven-doxia-0:1.0-0.8.a10.4.fc13.noarch maven2-plugin-deploy-0:2.0.8-3.fc12.noarch maven2-plugin-jar-0:2.0.8-3.fc12.noarch maven2-plugin-ant-0:2.0.8-3.fc12.noarch jgroups-0:2.2.9.2-6.6.fc12.x86_64 maven-scm-test-0:1.2-4.fc13.noarch maven-plugin-bundle-0:2.0.0-4.fc12.noarch maven-embedder-0:2.0.4-6.fc12.noarch maven2-plugin-antrun-0:2.0.8-3.fc12.noarch maven-shared-jar-0:1.1-4.fc13.noarch maven-shared-model-converter-0:2.3-4.fc13.noarch plexus-maven-plugin-0:1.3.5-1.3.fc12.noarch maven-shared-common-artifact-filters-0:1.0-4.fc13.noarch maven2-plugin-assembly-0:2.0.8-3.fc12.noarch checkstyle-demo-0:4.1-7.fc12.noarch castor-xml-0:0.9.5-5.fc12.1.x86_64 checkstyle-0:4.1-7.fc12.noarch maven2-plugin-enforcer-0:2.0.8-3.fc12.noarch maven-doxia-sitetools-0:1.0-0.2.a10.2.fc13.noarch maven-shared-invoker-0:2.0.7-4.fc13.noarch maven2-plugin-remote-resources-0:2.0.8-3.fc12.noarch maven-jflex-plugin-0:1.4.3-1.fc13.noarch pki-common-javadoc-0:1.3.0-6.fc13.noarch maven2-plugin-ejb-0:2.0.8-3.fc12.noarch pki-silent-0:1.3.0-5.fc13.noarch maven2-plugin-repository-0:2.0.8-3.fc12.noarch maven2-plugin-invoker-0:2.0.8-3.fc12.noarch maven2-plugin-doap-0:2.0.8-3.fc12.noarch maven-shared-plugin-testing-harness-0:1.2-4.fc13.noarch maven-shared-reporting-impl-0:2.1-4.fc13.noarch maven2-plugin-compiler-0:2.0.8-3.fc12.noarch maven2-0:2.0.8-3.fc12.noarch maven2-plugin-one-0:2.0.8-3.fc12.noarch velocity-demo-0:1.4-10.4.fc12.x86_64 geronimo-specs-compat-0:1.0-2.M2.fc10.x86_64 maven2-plugin-docck-0:2.0.8-3.fc12.noarch jython-0:2.2.1-4.3.fc13.x86_64 maven-shared-repository-builder-0:1.0-4.fc13.noarch maven-shared-ant-0:1.0-4.fc13.noarch maven-shared-plugin-tools-java-0:2.2-4.fc13.noarch maven-enforcer-rule-api-0:1.0-0.1.a2.1.5.fc12.noarch maven-shared-plugin-tools-api-0:2.2-4.fc13.noarch maven2-plugin-source-0:2.0.8-3.fc12.noarch maven-surefire-0:2.3-7.7.fc12.noarch eclipse-checkstyle-0:4.0.1-14.fc12.noarch maven-jxr-0:2.1-6.fc12.noarch castor-test-0:0.9.5-5.fc12.1.x86_64 maven-shared-archiver-0:2.3-4.fc13.noarch maven-shared-app-configuration-web-0:1.1-4.fc13.noarch maven-archiver-0:2.4-1.fc13.noarch maven-plugin-cobertura-javadoc-0:2.3-3.fc12.noarch maven2-plugin-install-0:2.0.8-3.fc12.noarch maven2-plugin-javadoc-0:2.0.8-3.fc12.noarch modello-0:1.0-0.4.a15.0.1.fc12.noarch maven2-plugin-eclipse-0:2.0.8-3.fc12.noarch avalon-logkit-0:1.2-8.fc12.x86_64 maven2-plugin-shade-0:1.2.2-2.fc13.noarch maven2-plugin-gpg-0:2.0.8-3.fc12.noarch maven-surefire-provider-junit-0:2.3-7.7.fc12.noarch maven2-plugin-project-info-reports-0:2.0.8-3.fc12.noarch maven2-plugin-antlr-0:2.0.8-3.fc12.noarch maven-shared-test-tools-0:1.0-4.fc13.noarch maven2-plugin-ear-0:2.0.8-3.fc12.noarch maven2-plugin-war-0:2.0.8-3.fc12.noarch castor-demo-0:0.9.5-5.fc12.1.x86_64 maven2-plugin-dependency-0:2.0.8-3.fc12.noarch mysql-connector-java-1:5.1.8-2.fc13.x86_64 maven2-plugin-verifier-0:2.0.8-3.fc12.noarch maven2-plugin-resources-0:2.0.8-3.fc12.noarch eclipse-pydev-1:1.5.3-1.fc13.x86_64 pki-common-0:1.3.0-6.fc13.noarch ----------------- Removing gmfsk also removes: ----------------- Removing gnome-scan also removes: ----------------- Removing Io-language also removes: TnL-0:071111-11.fc12.x86_64 Io-language-devel-0:20071010-10.fc11.i586 Io-language-graphics-and-sound-0:20071010-10.fc11.x86_64 Io-language-postgresql-0:20071010-10.fc11.x86_64 Io-language-extras-0:20071010-10.fc11.x86_64 Io-language-mysql-0:20071010-10.fc11.x86_64 Io-language-devel-0:20071010-10.fc11.x86_64 TnL-data-0:071111-5.fc12.noarch ----------------- Removing knm_new-fonts also removes: ----------------- Removing libFoundation also removes: libFoundation-devel-0:1.1.3-11.fc9.i386 libFoundation-devel-0:1.1.3-11.fc9.x86_64 ----------------- Removing ohm also removes: ohm-devel-0:0.1.1-9.39.20091215git.fc11.i586 ----------------- Removing perl-AnyEvent-XMPP also removes: ----------------- Removing perl-Class-InsideOut also removes: ----------------- Removing perl-Jemplate also removes: ----------------- Removing perl-MooseX-Traits-Attribute-CascadeClear also removes: perl-Fedora-Bugzilla-0:0.10-3.fc13.noarch ----------------- Removing perl-RRD-Simple also removes: ----------------- Removing perl-SVN-Mirror also removes: perl-Test-AutoBuild-svk-0:1.2.2-9.fc12.x86_64 perl-SVK-0:2.2.1-5.fc13.noarch ----------------- Removing perl-SVN-Simple also removes: perl-Test-AutoBuild-svk-0:1.2.2-9.fc12.x86_64 perl-SVN-Mirror-0:0.75-2.fc11.noarch perl-SVK-0:2.2.1-5.fc13.noarch ----------------- Removing prctl also removes: ----------------- Removing qtiplot also removes: ----------------- Removing skychart also removes: ----------------- Removing smarteiffel also removes: smarteiffel-doc-0:2.3-2.fc9.x86_64 ----------------- Removing synce-kde also removes: synce-kde-devel-0:0.9.1-4.fc11.i586 synce-kde-devel-0:0.9.1-4.fc11.x86_64 ----------------- Removing unifdef also removes: ----------------- Removing widelands also removes: ----------------- Removing xpilot-ng also removes: ----------------- Removing xqilla10 also removes: xqilla10-devel-0:1.0.2-6.fc11.x86_64 xqilla10-devel-0:1.0.2-6.fc11.i586 ----------------- Removing xqilla also removes: dbxml-utils-0:2.4.16-0.5.fc12.x86_64 dbxml-python-0:2.4.16-0.5.fc12.x86_64 dbxml-devel-0:2.4.16-0.5.fc12.x86_64 dbxml-0:2.4.16-0.5.fc12.x86_64 dbxml-perl-0:2.0040016-2.fc12.x86_64 xqilla-devel-0:2.1.3-0.6.fc11.x86_64 xqilla-devel-0:2.1.3-0.6.fc11.i586 dbxml-devel-0:2.4.16-0.5.fc12.i686 qpidd-xml-0:0.5.819819-1.fc13.x86_64
On Fri, 2010-01-15 at 07:27 -0600, Matt Domsch wrote:
Removing gmfsk also removes:
This one is now fixed.
Removing gnome-scan also removes:
There's a patch logged against this now FWIW
Removing Io-language also removes:
This one is now fixed.
Removing knm_new-fonts also removes:
This one is already a dead package, needs to be blocked I guess. Logged a ticket for that.
C.
Hi,
On 01/15/2010 02:48 PM, Caolán McNamara wrote:
On Fri, 2010-01-15 at 07:27 -0600, Matt Domsch wrote:
<snip>
There's a patch logged against this now FWIW
Removing Io-language also removes:
Thanks, given I owned this once upon a time I was also working on a fix (np), but it took me a bit longer as I also rebased to the latest upstream while at it.
Note I've also fixed: xpilot-ng
And I'm working on fixing: widelands (also rebasing to latest upstream),
Regards,
Hans
On Fri, 2010-01-15 at 13:48 +0000, Caolán McNamara wrote:
On Fri, 2010-01-15 at 07:27 -0600, Matt Domsch wrote:
Removing gmfsk also removes:
This one is now fixed.
Removing gnome-scan also removes:
There's a patch logged against this now FWIW
There is also a newer version 0.7.1 (a year old, actually), which needs a small patch as well to build against current babl. I would just build it, but I don't have a scanner around to do any testing. I've put the patch in the same bug, if somebody else wants to jump in...
2010/1/15 Matt Domsch Matt_Domsch@dell.com:
OK, re-run, removing the three packages noted as fixed overnight.
Removing geronimo-specs also removes:
[ lots of stuff! ]
Almost all of these are due to the dependency chain jms (virtual provide) -> avalon-logkit -> velocity -> (all of maven). avalon-logkit is basically a dead project, and velocity is the only package that requires it; akurtakov and I are currently working on patching the avalon-logkit requirement out of velocity (it's only optional anyway), which should clean things up a bit.
MEF
On 15/01/10 09:04 AM, Mary Ellen Foster wrote:
2010/1/15 Matt DomschMatt_Domsch@dell.com:
OK, re-run, removing the three packages noted as fixed overnight.
Removing geronimo-specs also removes:
[ lots of stuff! ]
Almost all of these are due to the dependency chain jms (virtual provide) -> avalon-logkit -> velocity -> (all of maven). avalon-logkit is basically a dead project, and velocity is the only package that requires it; akurtakov and I are currently working on patching the avalon-logkit requirement out of velocity (it's only optional anyway), which should clean things up a bit.
MEF
I talked it over with akurtakov. I propose reverting the F-12 and rawhide spec files to the F-11 version in the time-being while you and he work at removing the need for it. This will allow it to build.
None of the changes in the F-12 spec file since F-11 have ever been built (e.g. 1.1 shows up in the changelog along with various changes and then 1.2, but 1.1 nor 1.2 was ever built). The 1.1 version sources appear never to even have been imported; backing up the sources file 1 revision results in the F-11 1.0-M2 tarball.
I have applied for commit/ACL rights in Fedora admin for devel and I also got Fernando to give me rights for F-12 which he currently still owns.
-- Jeff J.
2010/1/15 Matt Domsch Matt_Domsch@dell.com:
ohm-0.1.1-9.39.20091215git.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539200
This should be a dead package, upstream is no longer being maintained.
Richard.
On Fri, Jan 15, 2010 at 12:00:50AM -0600, Matt Domsch wrote:
The following 30 packages, with respective FTBFS bugs, have been open since the Fedora 11 time frame, and continue to fail to build. These are the oldest non-building packages in the distribution, everything else (over 8800) managed to build for Fedora 12 or newer already.
A more up to date list is available here: https://bugzilla.redhat.com/showdependencytree.cgi?id=511348&hide_resolv...
I'd like to propose the above list be dropped from the distribution, prior to Fedora 13 Alpha freeze, unless the package is made to build in rawhide before that.
This is in a month (2010-02-16).
Regards Till
On Fri, Jan 15, 2010 at 12:00:50AM -0600, Matt Domsch wrote:
perl-SVN-Simple-0.27-7.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511729
Fixed.
Regards Till
On Fri, Jan 15, 2010 at 12:00:50AM -0600, Matt Domsch wrote:
The following 30 packages, with respective FTBFS bugs, have been open since the Fedora 11 time frame, and continue to fail to build. These are the oldest non-building packages in the distribution, everything else (over 8800) managed to build for Fedora 12 or newer already.
awn-extras-applets-0.3.2.1-8.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511628 evolution-brutus-1.2.35-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511451 geronimo-specs-1.0-2.M2.fc10.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511494 gmfsk-0.7-0.6.pre1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511780 gnome-scan-0.6.2-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511591 Io-language-20071010-10.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511617 knm_new-fonts-1.1-5.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=555487 libFoundation-1.1.3-11.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511470 ohm-0.1.1-9.39.20091215git.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539200 perl-AnyEvent-XMPP-0.4-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511749 perl-Class-InsideOut-1.09-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539136 perl-Jemplate-0.23-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=538984 perl-MooseX-Traits-Attribute-CascadeClear-0.03-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511570 perl-RRD-Simple-1.43-3.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=464964 perl-SVN-Mirror-0.75-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511770 perl-SVN-Simple-0.27-7.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511729 prctl-1.4-5.2.1.src.rpm (last built July 12, 2006, ExclusiveArch ia64) python-openhpi-1.1-3.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511675 qtiplot-0.9-11.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511688 recordmydesktop-0.3.8.1-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=538931 skychart-3.0.1.5-6.20081026svn.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539202 smarteiffel-2.3-2.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511362 synce-kde-0.9.1-4.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539195 unifdef-1.171-8.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511553 widelands-0-0.13.Build13.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511430 xpilot-ng-4.7.2-16.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511717 xqilla10-1.0.2-6.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511599 xqilla-2.1.3-0.6.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511425
Folks, while I appreciate you fixing these packages so they build again, _please_ do take the time to consider if they are unloved enough to be orphaned and dropped anyhow. If it's a leaf node in the dependency tree, dead upstream, and unresponsive Fedora maintainer, it should be orphaned and dropped rather than having a little bit of tape applied to it and sent back into the game...
On Fri, 15 Jan 2010 11:13:41 -0600, Matt wrote:
Folks, while I appreciate you fixing these packages so they build again, _please_ do take the time to consider if they are unloved enough to be orphaned and dropped anyhow. If it's a leaf node in the dependency tree, dead upstream, and unresponsive Fedora maintainer, it should be orphaned and dropped rather than having a little bit of tape applied to it and sent back into the game...
For heaven's sake, yes, yes, *YES*!
We want responsive maintainers (at least _one per package_) for every package in the Fedora package collection.
On 15.1.2010 07:00, Matt Domsch wrote:
synce-kde-0.9.1-4.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539195
Synce-kde should be EOL'd already a long time (it has been replaced by something else, can't remember details unfortunately anymore) -- I spoke about this with the maintainer some months ago and wonder this is still on the list...
Regards, Milos
On Fri, 15 Jan 2010 18:17:21 +0100, Milos wrote:
On 15.1.2010 07:00, Matt Domsch wrote:
synce-kde-0.9.1-4.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539195
Synce-kde should be EOL'd already a long time (it has been replaced by something else, can't remember details unfortunately anymore) -- I spoke about this with the maintainer some months ago and wonder this is still on the list...
I only remember that synce-hal replaced synce-serial, ... but in case synce-kde really has been replaced by something, what is so difficult about removing files in cvs and adding a dead.package? I can understand that creating a releng ticket for the remaining steps is a bit of a hurdle, but removing files in cvs/devel is easy enough.
On Fri, 2010-01-15 at 20:04 +0100, Michael Schwendt wrote:
On Fri, 15 Jan 2010 18:17:21 +0100, Milos wrote:
On 15.1.2010 07:00, Matt Domsch wrote:
synce-kde-0.9.1-4.fc11.src.rpm
https://bugzilla.redhat.com/show_bug.cgi?id=539195
Synce-kde should be EOL'd already a long time (it has been replaced
by
something else, can't remember details unfortunately anymore) -- I
spoke
about this with the maintainer some months ago and wonder this is
still
on the list...
I only remember that synce-hal replaced synce-serial, ... but in case synce-kde really has been replaced by something, what is so difficult about removing files in cvs and adding a dead.package? I can understand that creating a releng ticket for the remaining steps is a bit of a hurdle, but removing files in cvs/devel is easy enough.
synce-kde is replaced by synce-kpm. The maintainer seems somewhat erratic in his availability - I may ask to be made a co-maintainer for the synce stuff so I can take a shot at keeping it up to date (I really need to look into whether opensync 0.4 is vaguely usable yet).
On 01/15/2010 01:00 AM, Matt Domsch wrote:
perl-AnyEvent-XMPP-0.4-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511749
This one is awaiting an upstream fix (probably coming with 0.6).
perl-Class-InsideOut-1.09-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539136
Looks like Ralf took care of this one.
perl-Jemplate-0.23-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=538984
Fixed in rawhide: perl-Jemplate-0.23-5.fc13
perl-MooseX-Traits-Attribute-CascadeClear-0.03-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511570
This is dead upstream (the code is there, but it doesn't do anything and is marked as deprecated) and should be killed off. I've updated perl-Fedora-Bugzilla to the latest version which no longer depends on it.
/me wonders where cweyl went... :(
perl-RRD-Simple-1.43-3.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=464964
Bit rotted. If nothing deps on it, I say drop it.
perl-SVN-Mirror-0.75-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511770
Debian dropped this package, I vote we also do the same. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543099
~spot
On Fri, Jan 15, 2010 at 12:00:50AM -0600, Matt Domsch wrote:
The following 30 packages, with respective FTBFS bugs, have been open since the Fedora 11 time frame, and continue to fail to build. These are the oldest non-building packages in the distribution, everything else (over 8800) managed to build for Fedora 12 or newer already.
At today's FESCo meeting, it was agreed that all the below packages would be marked orphan. I know several of these have been fixed by provenpackagers already - you are welcome to un-orphan and maintain them going forward, or the original package owner may choose to do so.
awn-extras-applets-0.3.2.1-8.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511628 evolution-brutus-1.2.35-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511451 geronimo-specs-1.0-2.M2.fc10.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511494 gmfsk-0.7-0.6.pre1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511780 gnome-scan-0.6.2-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511591 Io-language-20071010-10.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511617 knm_new-fonts-1.1-5.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=555487 libFoundation-1.1.3-11.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511470 ohm-0.1.1-9.39.20091215git.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539200 perl-AnyEvent-XMPP-0.4-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511749 perl-Class-InsideOut-1.09-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539136 perl-Jemplate-0.23-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=538984 perl-MooseX-Traits-Attribute-CascadeClear-0.03-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511570 perl-RRD-Simple-1.43-3.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=464964 perl-SVN-Mirror-0.75-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511770 perl-SVN-Simple-0.27-7.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511729 prctl-1.4-5.2.1.src.rpm (last built July 12, 2006, ExclusiveArch ia64) python-openhpi-1.1-3.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511675 qtiplot-0.9-11.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511688 recordmydesktop-0.3.8.1-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=538931 skychart-3.0.1.5-6.20081026svn.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539202 smarteiffel-2.3-2.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511362 synce-kde-0.9.1-4.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539195 unifdef-1.171-8.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511553 widelands-0-0.13.Build13.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511430 xpilot-ng-4.7.2-16.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511717 xqilla10-1.0.2-6.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511599 xqilla-2.1.3-0.6.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511425
Any package still orphaned as of the Feb 16 F13 Alpha freeze will be dropped per standard operating procedure.
Thanks, Matt
On Fri, 2010-01-15 at 13:17 -0600, Matt Domsch wrote:
Any package still orphaned as of the Feb 16 F13 Alpha freeze will be dropped per standard operating procedure.
I might attempt to drop them a bit earlier than alpha freeze, so that if there is unexpected fallout we have time to fix it prior to the freeze.
On Fri, Jan 15, 2010 at 01:17:28PM -0600, Matt Domsch wrote:
On Fri, Jan 15, 2010 at 12:00:50AM -0600, Matt Domsch wrote:
The following 30 packages, with respective FTBFS bugs, have been open since the Fedora 11 time frame, and continue to fail to build. These are the oldest non-building packages in the distribution, everything else (over 8800) managed to build for Fedora 12 or newer already.
At today's FESCo meeting, it was agreed that all the below packages would be marked orphan. I know several of these have been fixed by provenpackagers already - you are welcome to un-orphan and maintain them going forward, or the original package owner may choose to do so.
What about the other packages of these maintainers? E.g. in the recordmydesktop case, there were four bugs open with working patches attached for that package. I did not yet check the other packages, but in case a packager does not have the time anymore to maintain one package from this list, why do we assume that he has the time to maintain the others? So before the mass orphaning is done, it would be nice to do it in a way that allows to at least easily spot which maintainers owned the packages before the orphage, so non responsive maintainers can be found easier. Or tell all maintainers in question and orphan all their packages. But the current solution seems to be only half-baked.
Regards Till
On Fri, Jan 15, 2010 at 09:01:20PM +0100, Till Maas wrote:
On Fri, Jan 15, 2010 at 01:17:28PM -0600, Matt Domsch wrote:
On Fri, Jan 15, 2010 at 12:00:50AM -0600, Matt Domsch wrote:
The following 30 packages, with respective FTBFS bugs, have been open since the Fedora 11 time frame, and continue to fail to build. These are the oldest non-building packages in the distribution, everything else (over 8800) managed to build for Fedora 12 or newer already.
At today's FESCo meeting, it was agreed that all the below packages would be marked orphan. I know several of these have been fixed by provenpackagers already - you are welcome to un-orphan and maintain them going forward, or the original package owner may choose to do so.
What about the other packages of these maintainers? E.g. in the recordmydesktop case, there were four bugs open with working patches attached for that package. I did not yet check the other packages, but in case a packager does not have the time anymore to maintain one package from this list, why do we assume that he has the time to maintain the others? So before the mass orphaning is done, it would be nice to do it in a way that allows to at least easily spot which maintainers owned the packages before the orphage, so non responsive maintainers can be found easier. Or tell all maintainers in question and orphan all their packages. But the current solution seems to be only half-baked.
I made sure that no one who fixed a package was actually the package owner.
Pre-orphaning:
evolution-brutus bpepple geronimo-specs fnasser gmfsk bjensen (fixed by caolanm) gnome-scan deji Io-language orphan (fixed by caolanm) knm_new-fonts orphan libFoundation athimm ohm cjb (should be dead) perl-AnyEvent-XMPP allisson (WIP by spot) perl-Class-InsideOut cweyl (fixed by Ralf) perl-Jemplate cweyl (fixed by Spot) perl-MooseX-Traits-Attribute-CascadeClear cweyl (spot says kill it) perl-RRD-Simple cweyl (spot says kill it) perl-SVN-Mirror iburrell (fixed by Till Maas; spot says kill it) perl-SVN-Simple iburrell prctl karsten qtiplot frankb skychart lkundrak smarteiffel orphan synce-kde awjb unifdef dwmw2 widelands karlik (WIP by hdegoede) xpilot-ng wart (fixed by hdegoede) xqilla10 orphan xqilla orphan
On Fri, Jan 15, 2010 at 02:06:09PM -0600, Matt Domsch wrote:
On Fri, Jan 15, 2010 at 09:01:20PM +0100, Till Maas wrote:
What about the other packages of these maintainers? E.g. in the recordmydesktop case, there were four bugs open with working patches attached for that package. I did not yet check the other packages, but in case a packager does not have the time anymore to maintain one package from this list, why do we assume that he has the time to maintain the others? So before the mass orphaning is done, it would be nice to do it in a way that allows to at least easily spot which maintainers owned the packages before the orphage, so non responsive maintainers can be found easier. Or tell all maintainers in question and orphan all their packages. But the current solution seems to be only half-baked.
I made sure that no one who fixed a package was actually the package owner.
But what about the other packages by these maintainers that do not fail to build but are probably as unmaintained as the packages that fail to build?
perl-SVN-Mirror iburrell (fixed by Till Maas; spot says kill it) perl-SVN-Simple iburrell
There is a minor error: I fixed the -Simple package with a patch submitted in the upstream bugtracker iirc 7 days ago. But I also noticed that the -Mirror package was removed from debian.
But what about the other packages from this maintainer? He maintains around 36 other packages: https://admin.fedoraproject.org/pkgdb/users/packages/iburrell
E.g. the jigdo packages also has 4 bug. I looked at two an both did not receive any comments from the maintainer: https://bugzilla.redhat.com/show_bug.cgi?id=426847 https://bugzilla.redhat.com/show_bug.cgi?id=503833
Therefore the non responsive maintainer procedure, i.e. orphaning all packages from the affected maintainers, seems to me to be more appropriate.
Regards Till
On Fri, 15 Jan 2010 22:58:54 +0100 Till Maas opensource@till.name wrote:
But what about the other packages by these maintainers that do not fail to build but are probably as unmaintained as the packages that fail to build?
There may be some cases of that. If so, the non responsive maintainer procedure should be used on those maintainers.
perl-SVN-Mirror iburrell (fixed by Till Maas; spot says kill it) perl-SVN-Simple iburrell
There is a minor error: I fixed the -Simple package with a patch submitted in the upstream bugtracker iirc 7 days ago. But I also noticed that the -Mirror package was removed from debian.
But what about the other packages from this maintainer? He maintains around 36 other packages: https://admin.fedoraproject.org/pkgdb/users/packages/iburrell
E.g. the jigdo packages also has 4 bug. I looked at two an both did not receive any comments from the maintainer: https://bugzilla.redhat.com/show_bug.cgi?id=426847 https://bugzilla.redhat.com/show_bug.cgi?id=503833
Indeed. I don't see much activity from them. Have you tried sending them an email? If not, I can.
Therefore the non responsive maintainer procedure, i.e. orphaning all packages from the affected maintainers, seems to me to be more appropriate.
In this particular case, yes.
kevin
On Fri, Jan 15, 2010 at 04:05:04PM -0700, Kevin Fenzi wrote:
On Fri, 15 Jan 2010 22:58:54 +0100 Till Maas opensource@till.name wrote:
perl-SVN-Mirror iburrell (fixed by Till Maas; spot says kill it) perl-SVN-Simple iburrell
There is a minor error: I fixed the -Simple package with a patch submitted in the upstream bugtracker iirc 7 days ago. But I also noticed that the -Mirror package was removed from debian.
But what about the other packages from this maintainer? He maintains around 36 other packages: https://admin.fedoraproject.org/pkgdb/users/packages/iburrell
E.g. the jigdo packages also has 4 bug. I looked at two an both did not receive any comments from the maintainer: https://bugzilla.redhat.com/show_bug.cgi?id=426847 https://bugzilla.redhat.com/show_bug.cgi?id=503833
Indeed. I don't see much activity from them. Have you tried sending them an email? If not, I can.
No, please go ahead.
Regards Till
On Sat, 16 Jan 2010 10:39:54 +0100 Till Maas opensource@till.name wrote:
Indeed. I don't see much activity from them. Have you tried sending them an email? If not, I can.
No, please go ahead.
I took the liberty right after I posted.
(Hopefully Ian doesn't mind me passing this along:)
Ian Burrell wrote:
I am still around but haven't been busy recently and haven't done anything with my packages.
I'll take a look at this weekend.
- Ian
On Sat, Jan 16, 2010 at 10:39:50AM -0700, Kevin Fenzi wrote:
On Sat, 16 Jan 2010 10:39:54 +0100 Till Maas opensource@till.name wrote:
Indeed. I don't see much activity from them. Have you tried sending them an email? If not, I can.
No, please go ahead.
I took the liberty right after I posted.
Did also contact the recordmydesktop maintainer?
Regards Till
On Sun, 17 Jan 2010 20:48:25 +0100 Till Maas opensource@till.name wrote:
On Sat, Jan 16, 2010 at 10:39:50AM -0700, Kevin Fenzi wrote:
On Sat, 16 Jan 2010 10:39:54 +0100 Till Maas opensource@till.name wrote:
Indeed. I don't see much activity from them. Have you tried sending them an email? If not, I can.
No, please go ahead.
I took the liberty right after I posted.
Did also contact the recordmydesktop maintainer?
I didn't then, but I did just now.
(Of course that meant I had to send two emails... perhaps next time you could just mail them directly? :)
kevin
On Tue, Jan 19, 2010 at 02:42:17PM -0700, Kevin Fenzi wrote:
On Sun, 17 Jan 2010 20:48:25 +0100 Till Maas opensource@till.name wrote:
On Sat, Jan 16, 2010 at 10:39:50AM -0700, Kevin Fenzi wrote:
On Sat, 16 Jan 2010 10:39:54 +0100 Till Maas opensource@till.name wrote:
Indeed. I don't see much activity from them.
^^^^
Have you tried sending them an email?
^^^^
If not, I can.
No, please go ahead.
I took the liberty right after I posted.
Did also contact the recordmydesktop maintainer?
I didn't then, but I did just now.
(Of course that meant I had to send two emails... perhaps next time you could just mail them directly? :)
You offered to write both of them and I agreed afaics. Nevertheless I did not mail them directly, because I hoped the full situation could be resolved in some clean way, e.g. just perform a non responsive maintainer procedure on all affected maintainers at once instead of all these quick actions that leave a lot of confusion. Nevertheless, it is too late now, anyhow.
Regards Till
On Fri, 2010-01-15 at 22:58 +0100, Till Maas wrote:
But what about the other packages by these maintainers that do not fail to build but are probably as unmaintained as the packages that fail to build?
Because this isn't a fully proper non-responsive maintainer approach, we felt it was only necessary to orphan the particular packages in question. These maintainers may have been active elsewhere, and wholesale orphaning with very little notice does not seem appropriate.
Hi,
On 01/16/2010 12:14 AM, Jesse Keating wrote:
On Fri, 2010-01-15 at 22:58 +0100, Till Maas wrote:
But what about the other packages by these maintainers that do not fail to build but are probably as unmaintained as the packages that fail to build?
Because this isn't a fully proper non-responsive maintainer approach, we felt it was only necessary to orphan the particular packages in question. These maintainers may have been active elsewhere, and wholesale orphaning with very little notice does not seem appropriate.
I don't see who the orphaning without following proper procedure is appropriate at all. Simply blocking the ones which FTBFS bugs were not fixed from F-13 inclusion would have been the appropriate response (as documented in our procedures), not some adhoc almost random response.
Regards,
Hans
On Sat, 16 Jan 2010 11:08:30 +0100 Hans de Goede hdegoede@redhat.com wrote:
I don't see who the orphaning without following proper procedure is appropriate at all. Simply blocking the ones which FTBFS bugs were not fixed from F-13 inclusion would have been the appropriate response (as documented in our procedures), not some adhoc almost random response.
These packages have failed to build for over a year.
Sure, we could allow them to continue if someone steps in to build them, but then who is answering bugzilla tickets on them? Who is following upstream and updating them, in short: who is maintaining them? Not the maintainer of record it seems.
if you want them to go on, take ownership.
Sorry for the bug that prevented people from doing this, it's been fixed.
kevin
On Sat, 2010-01-16 at 11:08 +0100, Hans de Goede wrote:
Simply blocking the ones which FTBFS bugs were not fixed from F-13 inclusion would have been the appropriate response (as documented in our procedures), not some adhoc almost random response.
We are blocking them. Every release we round up the orphans and block them from the release. Since this practice already existed, it made sense to orphan the FTBFS packages and give folks a chance to reclaim them before we block all the orphans, not just the FTBFS ones.
On Fri, Jan 15, 2010 at 1:58 PM, Till Maas opensource@till.name wrote:
perl-SVN-Mirror iburrell (fixed by Till Maas; spot says kill it) perl-SVN-Simple iburrell
There is a minor error: I fixed the -Simple package with a patch submitted in the upstream bugtracker iirc 7 days ago. But I also noticed that the -Mirror package was removed from debian.
The SVN::Mirror module seems to have problems with subversion 1.6. The author doesn't seem to have done anything with the module since 2008 including responding to the upstream bug. It will probably need to be removed since I don't have the knowledge to fix it. The perl-SVK package requires perl-SVN-Mirror but it is for an optional feature. I could make a new package that removes the dependency.
But what about the other packages from this maintainer? He maintains around 36 other packages: https://admin.fedoraproject.org/pkgdb/users/packages/iburrell
E.g. the jigdo packages also has 4 bug. I looked at two an both did not receive any comments from the maintainer: https://bugzilla.redhat.com/show_bug.cgi?id=426847 https://bugzilla.redhat.com/show_bug.cgi?id=503833
Therefore the non responsive maintainer procedure, i.e. orphaning all packages from the affected maintainers, seems to me to be more appropriate.
Sorry, I have been neglecting my packages for all the usual reasons. I'll give them the attention they need.
- Ian
Hi,
On 01/15/2010 09:06 PM, Matt Domsch wrote:
On Fri, Jan 15, 2010 at 09:01:20PM +0100, Till Maas wrote:
On Fri, Jan 15, 2010 at 01:17:28PM -0600, Matt Domsch wrote:
On Fri, Jan 15, 2010 at 12:00:50AM -0600, Matt Domsch wrote:
The following 30 packages, with respective FTBFS bugs, have been open since the Fedora 11 time frame, and continue to fail to build. These are the oldest non-building packages in the distribution, everything else (over 8800) managed to build for Fedora 12 or newer already.
At today's FESCo meeting, it was agreed that all the below packages would be marked orphan. I know several of these have been fixed by provenpackagers already - you are welcome to un-orphan and maintain them going forward, or the original package owner may choose to do so.
What about the other packages of these maintainers? E.g. in the recordmydesktop case, there were four bugs open with working patches attached for that package. I did not yet check the other packages, but in case a packager does not have the time anymore to maintain one package from this list, why do we assume that he has the time to maintain the others? So before the mass orphaning is done, it would be nice to do it in a way that allows to at least easily spot which maintainers owned the packages before the orphage, so non responsive maintainers can be found easier. Or tell all maintainers in question and orphan all their packages. But the current solution seems to be only half-baked.
I made sure that no one who fixed a package was actually the package owner.
Pre-orphaning:
evolution-brutus bpepple geronimo-specs fnasser gmfsk bjensen (fixed by caolanm) gnome-scan deji Io-language orphan (fixed by caolanm)
Used to be owned by: hdegoede, who took ownership of it again yesterday as he didn't knew it was orphaned. I hope you didn't orphan it again, but I'll check.
knm_new-fonts orphan libFoundation athimm ohm cjb (should be dead) perl-AnyEvent-XMPP allisson (WIP by spot) perl-Class-InsideOut cweyl (fixed by Ralf) perl-Jemplate cweyl (fixed by Spot) perl-MooseX-Traits-Attribute-CascadeClear cweyl (spot says kill it) perl-RRD-Simple cweyl (spot says kill it) perl-SVN-Mirror iburrell (fixed by Till Maas; spot says kill it) perl-SVN-Simple iburrell prctl karsten qtiplot frankb skychart lkundrak smarteiffel orphan synce-kde awjb unifdef dwmw2 widelands karlik (WIP by hdegoede)
I'll pick up this one.
xpilot-ng wart (fixed by hdegoede)
I know wart as a very active Games SIG contributor, and I'm against just orphaning this single package of him. I've not heard anything from him in a while. It might be a good idea to actually use the awol maintainer procedure here. This way we can find out if he really is MIA, and if so deal with all his packages.
Note the same argument can be made for all of the packagers in this list!
xqilla10 orphan xqilla orphan
Regards,
Hans
On Fri, Jan 15, 2010 at 02:06:09PM -0600, Matt Domsch wrote:
On Fri, Jan 15, 2010 at 09:01:20PM +0100, Till Maas wrote:
On Fri, Jan 15, 2010 at 01:17:28PM -0600, Matt Domsch wrote:
On Fri, Jan 15, 2010 at 12:00:50AM -0600, Matt Domsch wrote:
The following 30 packages, with respective FTBFS bugs, have been open since the Fedora 11 time frame, and continue to fail to build. These are the oldest non-building packages in the distribution, everything else (over 8800) managed to build for Fedora 12 or newer already.
At today's FESCo meeting, it was agreed that all the below packages would be marked orphan. I know several of these have been fixed by provenpackagers already - you are welcome to un-orphan and maintain them going forward, or the original package owner may choose to do so.
I made sure that no one who fixed a package was actually the package owner.
Pre-orphaning:
[...]
The list of packages you announced that are going to be orphaned and the list of packages that were orphaned are not the same. recordmydesktop was on the to-be-orphaned list but afaics was not orphaned and also was not mentioned in your list about which provenpackager fixed which package.
Regards Till
On Sun, 17 Jan 2010 20:52:12 +0100 Till Maas opensource@till.name wrote:
The list of packages you announced that are going to be orphaned and the list of packages that were orphaned are not the same. recordmydesktop was on the to-be-orphaned list but afaics was not orphaned and also was not mentioned in your list about which provenpackager fixed which package.
Odd. Not sure why it wasn't there.
I mailed the maintainer and can orphan it.
kevin
On Tue, Jan 19, 2010 at 02:42:58PM -0700, Kevin Fenzi wrote:
On Sun, 17 Jan 2010 20:52:12 +0100 Till Maas opensource@till.name wrote:
The list of packages you announced that are going to be orphaned and the list of packages that were orphaned are not the same. recordmydesktop was on the to-be-orphaned list but afaics was not orphaned and also was not mentioned in your list about which provenpackager fixed which package.
Odd. Not sure why it wasn't there.
I mailed the maintainer and can orphan it.
It is still not orphaned afaics.
Regards Till
On Wed, 27 Jan 2010 15:43:40 +0100 Till Maas opensource@till.name wrote:
On Tue, Jan 19, 2010 at 02:42:58PM -0700, Kevin Fenzi wrote:
On Sun, 17 Jan 2010 20:52:12 +0100 Till Maas opensource@till.name wrote:
The list of packages you announced that are going to be orphaned and the list of packages that were orphaned are not the same. recordmydesktop was on the to-be-orphaned list but afaics was not orphaned and also was not mentioned in your list about which provenpackager fixed which package.
Odd. Not sure why it wasn't there.
I mailed the maintainer and can orphan it.
It is still not orphaned afaics.
Sorry about that, was hoping I would get a reply.
Orphaned in devel.
If someone wants to pick it up in other branches just let me know.
kevin
On Wed, Jan 27, 2010 at 10:39:38AM -0700, Kevin Fenzi wrote:
On Wed, 27 Jan 2010 15:43:40 +0100 Till Maas opensource@till.name wrote:
On Tue, Jan 19, 2010 at 02:42:58PM -0700, Kevin Fenzi wrote:
On Sun, 17 Jan 2010 20:52:12 +0100 Till Maas opensource@till.name wrote:
The list of packages you announced that are going to be orphaned and the list of packages that were orphaned are not the same. recordmydesktop was on the to-be-orphaned list but afaics was not orphaned and also was not mentioned in your list about which provenpackager fixed which package.
Odd. Not sure why it wasn't there.
I mailed the maintainer and can orphan it.
It is still not orphaned afaics.
Sorry about that, was hoping I would get a reply.
Oh, then I misunderstood, I thought you got a reply saying that you can orphan it. I will then go on with a non responsive maintainer procedure.
Regards Till
Hi,
On 01/15/2010 09:01 PM, Till Maas wrote:
On Fri, Jan 15, 2010 at 01:17:28PM -0600, Matt Domsch wrote:
On Fri, Jan 15, 2010 at 12:00:50AM -0600, Matt Domsch wrote:
The following 30 packages, with respective FTBFS bugs, have been open since the Fedora 11 time frame, and continue to fail to build. These are the oldest non-building packages in the distribution, everything else (over 8800) managed to build for Fedora 12 or newer already.
At today's FESCo meeting, it was agreed that all the below packages would be marked orphan. I know several of these have been fixed by provenpackagers already - you are welcome to un-orphan and maintain them going forward, or the original package owner may choose to do so.
What about the other packages of these maintainers? E.g. in the recordmydesktop case, there were four bugs open with working patches attached for that package. I did not yet check the other packages, but in case a packager does not have the time anymore to maintain one package from this list, why do we assume that he has the time to maintain the others? So before the mass orphaning is done, it would be nice to do it in a way that allows to at least easily spot which maintainers owned the packages before the orphage, so non responsive maintainers can be found easier. Or tell all maintainers in question and orphan all their packages. But the current solution seems to be only half-baked.
You know we have a procedure for this it is called the awol maintainer procedure and it would be nice if FESco would follow its on procedures here.
Ah well I guess the rules don't apply to those who make them :(
Regards,
Hans
Regards Till
On Sat, 16 Jan 2010 10:59:56 +0100, Hans wrote:
On 01/15/2010 09:01 PM, Till Maas wrote:
What about the other packages of these maintainers? E.g. in the recordmydesktop case, there were four bugs open with working patches attached for that package. I did not yet check the other packages, but in case a packager does not have the time anymore to maintain one package from this list, why do we assume that he has the time to maintain the others? So before the mass orphaning is done, it would be nice to do it in a way that allows to at least easily spot which maintainers owned the packages before the orphage, so non responsive maintainers can be found easier. Or tell all maintainers in question and orphan all their packages. But the current solution seems to be only half-baked.
You know we have a procedure for this it is called the awol maintainer procedure and it would be nice if FESco would follow its on procedures here.
Ah well I guess the rules don't apply to those who make them :(
That view is overly pessimistic.
We are in need of more automated procedures and more automated triggers. And we need to find ways how to detect non-responsive, inactive or overwhelmed contributors sooner. Fedora has grown out of proportions. It's good to see the community of contributors grow further, but in some areas it doesn't scale nevertheless.
There is only a single package owner in pkgdb. A single person who is the default assignee of tickets in bugzilla. We should aim at making every assignee in bz a person who is responsive OR have enough co-maintainers on the watchbugzilla list to be responsive instead.
It doesn't work well if arbitrary packagers "keep alive" a package without being the package's official maintainers -- and if the assignee is like /dev/null for problem reports or perhaps has left the project already. We can't wait for the one in a thousand bug reporters who will escalate a problem instead of resigning in disappointment. Two months without a reply, three months without a reply ... what to expect?
FESCo ought to give the FTBFS tickets a special status. Unhandled FTBFS tickets will trigger the AWOL procedure for the assignee in bugzilla. The assignee will have to respond to the various pings and fix the package ownership in pkgdb if appropriate. A single reply in multiple weeks or an extended period of time. No harm is done if others need to take care of the package temporarily anyway. If somebody else has fixed the FTBFS meanwhile, consider yourself lucky. Then you've avoided the FTBFS->AWOL trigger, and some other monitoring software will need to detect non-responsiveness, inactivity, orphans.
On Sat, 2010-01-16 at 10:59 +0100, Hans de Goede wrote:
You know we have a procedure for this it is called the awol maintainer procedure and it would be nice if FESco would follow its on procedures here.
Ah well I guess the rules don't apply to those who make them :(
The non-responsive maintainer process is a rather lengthy and involved process, one which wouldn't lead to these packages being blocked in time. Due to that we decided it would be best to special case these and orphan them right away, so that this current set of packages can be dealt with appropriately.
If a volunteer wishes to instigate a non-responsive process on all the maintainers, that is a separate matter which can happen concurrently to the current actions.
On 01/15/2010 08:17 PM, Matt Domsch wrote:
On Fri, Jan 15, 2010 at 12:00:50AM -0600, Matt Domsch wrote:
The following 30 packages, with respective FTBFS bugs, have been open since the Fedora 11 time frame, and continue to fail to build. These are the oldest non-building packages in the distribution, everything else (over 8800) managed to build for Fedora 12 or newer already.
At today's FESCo meeting, it was agreed that all the below packages would be marked orphan.
Well, if FESCO thinks this was a good idea ... I think you guys stopped half-ways: You better should have launched AWOL-processes against these maintainers.
I know several of these have been fixed by provenpackagers already - you are welcome to un-orphan and maintain them going forward, or the original package owner may choose to do so.
Unfortunately, this has proven to be hard/impossible so far.
perl-Class-InsideOut-1.09-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539136
I intended to take this one, but the packagedb doesn't offer me an option to take it:
C.f.: https://admin.fedoraproject.org/pkgdb/packages/name/perl-Class-InsideOut
This package appears to be owned by owner "orphan" and doesn't offer the "Take Ownership" button, I see on packages listed on https://admin.fedoraproject.org/pkgdb/packages/orphans otherwise.
Ralf
On Sat, Jan 16, 2010 at 05:13:29AM +0100, Ralf Corsepius wrote:
On 01/15/2010 08:17 PM, Matt Domsch wrote: Unfortunately, this has proven to be hard/impossible so far.
perl-Class-InsideOut-1.09-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539136
I intended to take this one, but the packagedb doesn't offer me an option to take it:
C.f.: https://admin.fedoraproject.org/pkgdb/packages/name/perl-Class-InsideOut
This package appears to be owned by owner "orphan" and doesn't offer the "Take Ownership" button, I see on packages listed on https://admin.fedoraproject.org/pkgdb/packages/orphans otherwise.
Indeed, I see the same thing when logged in - no "Take Ownership" button. Toshio?
On Fri, Jan 15, 2010 at 10:39:17PM -0600, Matt Domsch wrote:
On Sat, Jan 16, 2010 at 05:13:29AM +0100, Ralf Corsepius wrote:
On 01/15/2010 08:17 PM, Matt Domsch wrote: Unfortunately, this has proven to be hard/impossible so far.
perl-Class-InsideOut-1.09-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539136
I intended to take this one, but the packagedb doesn't offer me an option to take it:
C.f.: https://admin.fedoraproject.org/pkgdb/packages/name/perl-Class-InsideOut
This package appears to be owned by owner "orphan" and doesn't offer the "Take Ownership" button, I see on packages listed on https://admin.fedoraproject.org/pkgdb/packages/orphans otherwise.
My apologies,
Fixed in the db now. Working on backporting the pkgdb server fix that went into trunk but not the production setup that prevents this from happening.
-Toshio
On Sat, 16 Jan 2010 05:13:29 +0100, Ralf wrote:
On 01/15/2010 08:17 PM, Matt Domsch wrote:
At today's FESCo meeting, it was agreed that all the below packages would be marked orphan.
Well, if FESCO thinks this was a good idea ... I think you guys stopped half-ways: You better should have launched AWOL-processes against these maintainers.
It's a more fundamental problem, though. The AWOL-process is for people, not for packages. The people may still be active (and even known to be active somewhere) and not AWOL, but the packages which are assigned to them would still look orphaned. FTBFS is just one way to find packages that don't even build. However, if that happens, it may be much too late. Such a package may have been in an unmaintained desolate state for a long time already. With nobody handling the incoming bugzilla tickets. With some bug reports having been killed in an automated way at dist EOL. And worse if it turns out that packages which do build are unmaintained nevertheless, with the same symptoms in bugzilla and in package scm.
Makes me wonder what bugzilla status report scripts we have? To create a list of potentially unmaintained packages earlier and to detect packages with non-responsive owners.
On Sat, Jan 16, 2010 at 10:13:32AM +0100, Michael Schwendt wrote:
On Sat, 16 Jan 2010 05:13:29 +0100, Ralf wrote:
On 01/15/2010 08:17 PM, Matt Domsch wrote:
At today's FESCo meeting, it was agreed that all the below packages would be marked orphan.
Well, if FESCO thinks this was a good idea ... I think you guys stopped half-ways: You better should have launched AWOL-processes against these maintainers.
It's a more fundamental problem, though. The AWOL-process is for people, not for packages. The people may still be active (and even known to be active somewhere) and not AWOL, but the packages which are assigned to them would still look orphaned. FTBFS is just one way to find packages that don't even build.
If the maintainers are still active and still do not ask for help for the packages they cannot handle, then this is imho a behaviour that should not be supported. If we orphan all packages for maintainers with long standing FTBFS bugs that are not worked on and the maintainer still care about some of their packages, they can just unorphan these particular packages.
However, if that happens, it may be much too late. Such a package may have been in an unmaintained desolate state for a long time already. With nobody handling the incoming bugzilla tickets. With some bug reports having been killed in an automated way at dist EOL. And worse if it turns out that packages which do build are unmaintained nevertheless, with the same symptoms in bugzilla and in package scm.
I agree.
Makes me wonder what bugzilla status report scripts we have? To create a list of potentially unmaintained packages earlier and to detect packages with non-responsive owners.
There are the probably not working anymore scripts that were used ages ago for the weekly(?) Fedora package status reports: http://cvs.fedoraproject.org/viewvc/status-report-scripts/?root=fedora
Regards Till
On Sat, Jan 16, 2010 at 10:13:32AM +0100, Michael Schwendt wrote:
It's a more fundamental problem, though. The AWOL-process is for people, not for packages. The people may still be active (and even known to be active somewhere) and not AWOL, but the packages which are assigned to them would still look orphaned. FTBFS is just one way to find packages that don't even build. However, if that happens, it may be much too late. Such a package may have been in an unmaintained desolate state for a long time already.
In general I've been running the FTBFS scripts about monthly; maybe less so as we approach a release (nearly all packages get rebuilt, especially if there's a mass rebuild that happens). I think that's frequent enough to detect FTBFS; also we're not yet proposing dropping packages that don't rebuild in F13 yet; only those that never got rebuilt for F12. So the FTBFS now-orphaned packages are at 1 year old with no real progress to speak of.
With nobody handling the incoming bugzilla tickets. With some bug reports having been killed in an automated way at dist EOL. And worse if it turns out that packages which do build are unmaintained nevertheless, with the same symptoms in bugzilla and in package scm.
We could easily create a new class of bugzilla ticket, say "MAINTAINED". An automated process would generate such tickets, blocking F13MAINTAINED. The ticket would ask the maintainer to close the ticket to remain the owner of the package. Tickets still open after $SOMEDELAY would be candidates for orphan or non-responsive maintainer process. Repeat at $SOMEINTERVAL, perhaps once per release cycle (more would be too onerous I think).
With a slight modification, my ftbfs bugzilla script could generate the tickets.
Thoughts?
Thanks, Matt
Hi,
On 01/16/2010 03:50 PM, Matt Domsch wrote:
On Sat, Jan 16, 2010 at 10:13:32AM +0100, Michael Schwendt wrote:
It's a more fundamental problem, though. The AWOL-process is for people, not for packages. The people may still be active (and even known to be active somewhere) and not AWOL, but the packages which are assigned to them would still look orphaned. FTBFS is just one way to find packages that don't even build. However, if that happens, it may be much too late. Such a package may have been in an unmaintained desolate state for a long time already.
In general I've been running the FTBFS scripts about monthly; maybe less so as we approach a release (nearly all packages get rebuilt, especially if there's a mass rebuild that happens). I think that's frequent enough to detect FTBFS; also we're not yet proposing dropping packages that don't rebuild in F13 yet; only those that never got rebuilt for F12. So the FTBFS now-orphaned packages are at 1 year old with no real progress to speak of.
With nobody handling the incoming bugzilla tickets. With some bug reports having been killed in an automated way at dist EOL. And worse if it turns out that packages which do build are unmaintained nevertheless, with the same symptoms in bugzilla and in package scm.
We could easily create a new class of bugzilla ticket, say "MAINTAINED". An automated process would generate such tickets, blocking F13MAINTAINED. The ticket would ask the maintainer to close the ticket to remain the owner of the package. Tickets still open after $SOMEDELAY would be candidates for orphan or non-responsive maintainer process. Repeat at $SOMEINTERVAL, perhaps once per release cycle (more would be too onerous I think).
With a slight modification, my ftbfs bugzilla script could generate the tickets.
Thoughts?
Bad idea (says someone who owns 150 packages). I don't feel like getting 150 bugzilla mails and having to (mass) close them each release.
Regards,
Hans
On Sat, Jan 16, 2010 at 12:47:35AM +0100, Hans de Goede wrote:
Bad idea (says someone who owns 150 packages). I don't feel like getting 150 bugzilla mails and having to (mass) close them each release.
OK; add a fedora-packager script that mass-closes bugs; or use the bugzilla web interface to select all bugs owned by you also blocking the blocker bug, and apply the same change to them all; again in one fell swoop. This is solvable. This may still not be the "best" approach, but it is possible and doesn't have to be onerous.
On Sat, Jan 16, 2010 at 05:10:17PM -0600, Matt Domsch wrote:
On Sat, Jan 16, 2010 at 12:47:35AM +0100, Hans de Goede wrote:
Bad idea (says someone who owns 150 packages). I don't feel like getting 150 bugzilla mails and having to (mass) close them each release.
OK; add a fedora-packager script that mass-closes bugs; or use the bugzilla web interface to select all bugs owned by you also blocking the blocker bug, and apply the same change to them all; again in one fell swoop. This is solvable. This may still not be the "best" approach, but it is possible and doesn't have to be onerous.
We could also include a cron script, that does it all twice a year. ;-) There are already afaik three such timeouts that hit maintainers, can't we use this data? One is asked to change the password in FAS and bugzilla regularly and the client certificate to create builds and upload to the lookaside cache expire every 6 months iirc.
Imho the solution to detect whether a package is still maintained should support maintainers as much as much is possible and not just be created in a way that's easy to implement, but highly annoying to maintainers.
Regards Till
On Sat, Jan 16, 2010 at 08:50:14AM -0600, Matt Domsch wrote:
On Sat, Jan 16, 2010 at 10:13:32AM +0100, Michael Schwendt wrote:
With nobody handling the incoming bugzilla tickets. With some bug reports having been killed in an automated way at dist EOL. And worse if it turns out that packages which do build are unmaintained nevertheless, with the same symptoms in bugzilla and in package scm.
We could easily create a new class of bugzilla ticket, say "MAINTAINED". An automated process would generate such tickets, blocking F13MAINTAINED. The ticket would ask the maintainer to close the ticket to remain the owner of the package. Tickets still open after $SOMEDELAY would be candidates for orphan or non-responsive maintainer process. Repeat at $SOMEINTERVAL, perhaps once per release cycle (more would be too onerous I think).
I do not like such artificial conditions that should show that a package is still maintained. It will bother all maitainers that already maintain their packages correctly. But this could be a techninal implementation but with other conditions when such tickets are created, e.g. these tickets could have been created for all maintainers still having FTBFS packages without commenting on their bug reports recently. But there could also be other conditions that trigger this, which still need to be implemented.
Regards Till
On Sat, 16 Jan 2010, Matt Domsch wrote:
We could easily create a new class of bugzilla ticket, say "MAINTAINED". An automated process would generate such tickets, blocking F13MAINTAINED. The ticket would ask the maintainer to close the ticket to remain the owner of the package. Tickets still open after $SOMEDELAY would be candidates for orphan or non-responsive maintainer process. Repeat at $SOMEINTERVAL, perhaps once per release cycle (more would be too onerous I think).
With a slight modification, my ftbfs bugzilla script could generate the tickets.
Thoughts?
I like the idea. I like it even more if we could make a make-target for saying "I'm here, shut the hell up" so it can be done easily.
So, for Hans' situation - if he has 150 pkgs - we file a 'MAINTAINED' bug on any of the pkgs which has not had any change in a full release.
that should narrow the number of bugs he has to deal with, I'd think.
-sv
On Sun, Jan 17, 2010 at 10:46:18PM -0500, Seth Vidal wrote:
On Sat, 16 Jan 2010, Matt Domsch wrote:
We could easily create a new class of bugzilla ticket, say "MAINTAINED". An automated process would generate such tickets, blocking F13MAINTAINED. The ticket would ask the maintainer to close the ticket to remain the owner of the package. Tickets still open after $SOMEDELAY would be candidates for orphan or non-responsive maintainer process. Repeat at $SOMEINTERVAL, perhaps once per release cycle (more would be too onerous I think).
With a slight modification, my ftbfs bugzilla script could generate the tickets.
Thoughts?
I like the idea. I like it even more if we could make a make-target for saying "I'm here, shut the hell up" so it can be done easily.
So, for Hans' situation - if he has 150 pkgs - we file a 'MAINTAINED' bug on any of the pkgs which has not had any change in a full release.
that should narrow the number of bugs he has to deal with, I'd think.
yes, it would. Help generating the list of (packages which have not been rebuilt since X except by the rel-eng rebuild script) would be welcome.
I do have a concern with how bugzilla will handle mass filing 9000 bugs in one fell swoop. Perhaps pkgdb would be a more appropriate tool to do this in? Just a thought.
I agree FTBFS isn't really special-case. It only highlighted the 30 or so packages which were truly unloved for a long time (no rebuild to f12 or f13). My goal with FTBFS is to ensure the whole distro is self-hosting; it has the side effect of noticing packages that prevent this. FESCo wasn't ready to declare the owners thereof "non-responsive", they just wanted to prepare the distro for the possibility of the packages being removed, which orphan status on the specific package does do.
But note: there are 2 cases we're dealing with: 1) the owner has updated some of their packages (so, responsive to some), but unresponsive to others (FTBFS, other longstanding unresolved bugs) 2) the owner hasn't updated _any_ of their packages in some time, even in presence of filed bugs (non-responsive maintainer).
It's worth distinguishing, as case 1) calls for selective orphaning of packages (just the ones not getting the attention necessary), whereas case 2) calls for orphaning all the owner's packages. Ideally in case 1) the owner, being still somewhat responsive, would choose to orphan their unloved packages themselves.
The other thing to remember is that it doesn't have to be a badge of shame to have your packages orphaned, or for you to orphan a package yourself. Individual's priorities and capabilities do change over time; we need a healthy way to gracefully let people bow out of maintaining some or all of their packages. And we do, I see orphan notices with others picking them up quite often on devel@. That's a sign of a healthy community.
On 01/16/2010 03:50 PM, Matt Domsch wrote:
On Sat, Jan 16, 2010 at 10:13:32AM +0100, Michael Schwendt wrote:
With nobody handling the incoming bugzilla tickets. With some bug reports having been killed in an automated way at dist EOL. And worse if it turns out that packages which do build are unmaintained nevertheless, with the same symptoms in bugzilla and in package scm.
We could easily create a new class of bugzilla ticket, say "MAINTAINED". An automated process would generate such tickets, blocking F13MAINTAINED. The ticket would ask the maintainer to close the ticket to remain the owner of the package. Tickets still open after $SOMEDELAY would be candidates for orphan or non-responsive maintainer process. Repeat at $SOMEINTERVAL, perhaps once per release cycle (more would be too onerous I think).
With a slight modification, my ftbfs bugzilla script could generate the tickets.
Thoughts?
I don't like this idea, because I don't see how this is would be essentially different from the AWOL process.
The only difference would be, with proposal non-reponsive maintainer would be urged to "take action on one package otherwise you'll loose ownership on this package" vs. "take action on one or package, otherwise you'll loose ownershp on all packages" as with the AWOL process.
That said, I seriously think, * non-responsive maintainers should be confronted with an AWOL-process in all cases of non-responsiveness. They always have the opportunity to "take action". * we might need a better, formalized AWOL process.
Also consider that FTBS breakdowns only are one situation amongst many similar situations of "non-responsive maintainers" - I don't see any need to special case FTBS.
Ralf
Matt Domsch (Matt_Domsch@dell.com) said:
With nobody handling the incoming bugzilla tickets. With some bug reports having been killed in an automated way at dist EOL. And worse if it turns out that packages which do build are unmaintained nevertheless, with the same symptoms in bugzilla and in package scm.
We could easily create a new class of bugzilla ticket, say "MAINTAINED". An automated process would generate such tickets, blocking F13MAINTAINED. The ticket would ask the maintainer to close the ticket to remain the owner of the package. Tickets still open after $SOMEDELAY would be candidates for orphan or non-responsive maintainer process. Repeat at $SOMEINTERVAL, perhaps once per release cycle (more would be too onerous I think).
Ugh, this seems like it would just create a lot of make-work for the common case where packages *are* maintained. Perhaps only do this for packages that appear via some criteria (have not been built, have not been committed to, have lots of bugs with no response, etc.), but doing it for *every* package seems like overkill.
Bill
On Mon, 18 Jan 2010, Bill Nottingham wrote:
Ugh, this seems like it would just create a lot of make-work for the common case where packages *are* maintained. Perhaps only do this for packages that appear via some criteria (have not been built, have not been committed to, have lots of bugs with no response, etc.), but doing it for *every* package seems like overkill.
Right - so maybe last check into devel branch since the last release of the distro.
If we do that check before the alpha release that should let us track down awol maintainers and unmaintained pkgs pretty easily, I think.
thoughts? -sv
On Mon, Jan 18, 2010 at 12:25:44PM -0500, Seth Vidal wrote:
On Mon, 18 Jan 2010, Bill Nottingham wrote:
Ugh, this seems like it would just create a lot of make-work for the common case where packages *are* maintained. Perhaps only do this for packages that appear via some criteria (have not been built, have not been committed to, have lots of bugs with no response, etc.), but doing it for *every* package seems like overkill.
Right - so maybe last check into devel branch since the last release of the distro.
If we do that check before the alpha release that should let us track down awol maintainers and unmaintained pkgs pretty easily, I think.
The majority of my packages does not get updated that often (15 from 21) and there are also no bug reports unhandled for them.
I am not sure how the ratio is for others, but it does not seem to be such a got criterion.
Regards Till
On Mon, 18 Jan 2010, Till Maas wrote:
On Mon, Jan 18, 2010 at 12:25:44PM -0500, Seth Vidal wrote:
On Mon, 18 Jan 2010, Bill Nottingham wrote:
Ugh, this seems like it would just create a lot of make-work for the common case where packages *are* maintained. Perhaps only do this for packages that appear via some criteria (have not been built, have not been committed to, have lots of bugs with no response, etc.), but doing it for *every* package seems like overkill.
Right - so maybe last check into devel branch since the last release of the distro.
If we do that check before the alpha release that should let us track down awol maintainers and unmaintained pkgs pretty easily, I think.
The majority of my packages does not get updated that often (15 from 21) and there are also no bug reports unhandled for them.
I am not sure how the ratio is for others, but it does not seem to be such a got criterion.
so 15/21 your packages don't get rebuilt, atall, from release to release? Really?
-sv
On Mon, 2010-01-18 at 12:25 -0500, Seth Vidal wrote:
On Mon, 18 Jan 2010, Bill Nottingham wrote:
Ugh, this seems like it would just create a lot of make-work for the common case where packages *are* maintained. Perhaps only do this for packages that appear via some criteria (have not been built, have not been committed to, have lots of bugs with no response, etc.), but doing it for *every* package seems like overkill.
Right - so maybe last check into devel branch since the last release of the distro.
If we do that check before the alpha release that should let us track down awol maintainers and unmaintained pkgs pretty easily, I think.
thoughts?
I think there should be at least two conditions which would have to be fulfilled for the nagging bug to be created - the package was not touched by the maintainer during recent x months and at least one bug is opened not closed in the bugzilla on the package.
On Mon, 18 Jan 2010, Tomas Mraz wrote:
I think there should be at least two conditions which would have to be fulfilled for the nagging bug to be created - the package was not touched by the maintainer during recent x months and at least one bug is opened not closed in the bugzilla on the package.
I disagree about the bug being open. A lack of filed bugs could mean that no one CARES about the pkg at all. And if we have pkgs which are not being maintained AND no one cares enough to file a bug about then either they are:
1. extraordinarily stable 2. dead upstreams 3. unmaintained 4. unusued
in ANY of those cases I'd want to start thinking about nuking the pkg from fedora.
-sv
On Mon, 2010-01-18 at 14:04 -0500, Seth Vidal wrote:
On Mon, 18 Jan 2010, Tomas Mraz wrote:
I think there should be at least two conditions which would have to be fulfilled for the nagging bug to be created - the package was not touched by the maintainer during recent x months and at least one bug is opened not closed in the bugzilla on the package.
I disagree about the bug being open. A lack of filed bugs could mean that no one CARES about the pkg at all. And if we have pkgs which are not being maintained AND no one cares enough to file a bug about then either they are:
- extraordinarily stable
- dead upstreams
- unmaintained
- unusued
in ANY of those cases I'd want to start thinking about nuking the pkg from fedora.
So that means that for example for the openoffice.org-dict-cs_CZ package I'll get the nag bug report before each and every Fedora release?
It is definitely not 4. however 1. and 2. apply to it. As this is just a czech spelling and hyphenation dictionary which is pretty good one and we do not have any alternative anyway I do not think that 2. matters much.
OK, I think my next changelog entry in the .spec will be something like: - rebuilding just for the sake of not getting a nonsense bug report opened against the package
On Mon, 18 Jan 2010, Tomas Mraz wrote:
On Mon, 2010-01-18 at 14:04 -0500, Seth Vidal wrote:
On Mon, 18 Jan 2010, Tomas Mraz wrote:
I think there should be at least two conditions which would have to be fulfilled for the nagging bug to be created - the package was not touched by the maintainer during recent x months and at least one bug is opened not closed in the bugzilla on the package.
I disagree about the bug being open. A lack of filed bugs could mean that no one CARES about the pkg at all. And if we have pkgs which are not being maintained AND no one cares enough to file a bug about then either they are:
- extraordinarily stable
- dead upstreams
- unmaintained
- unusued
in ANY of those cases I'd want to start thinking about nuking the pkg from fedora.
So that means that for example for the openoffice.org-dict-cs_CZ package I'll get the nag bug report before each and every Fedora release?
It is definitely not 4. however 1. and 2. apply to it. As this is just a czech spelling and hyphenation dictionary which is pretty good one and we do not have any alternative anyway I do not think that 2. matters much.
OK, I think my next changelog entry in the .spec will be something like:
- rebuilding just for the sake of not getting a nonsense bug report
opened against the package
Really? We need all this drama?
I have another radical idea - we could whitelist all sorts of things which are unchanging and yet used. We could act like reasonable folks and realize that one extra bug report A YEAR that you have to close as 'fixed' is really not that big of a deal.
-sv
On Mon, Jan 18, 2010 at 02:32:10PM -0500, Seth Vidal wrote:
I have another radical idea - we could whitelist all sorts of things which are unchanging and yet used. We could act like reasonable folks and realize that one extra bug report A YEAR that you have to close as 'fixed' is really not that big of a deal.
First of all, that would be two bug reports per year, as we have a 6 month development cycle. But it also will not be that useful, as we already have three things that have to be done by every maintainer once or twice a year, so they can be easily used to track, whether or not a maintainer is still around at all: FAS password, Koji certificate Bugzilla password. Then if you intend to catch unused packages, this will also fail unless you also plan to implement some captcha for this for every package, because there will be a script that a maintainer can run to close all bugs for all of his packages at once, even for the packages he does not maintain properly. So you will still only track down, whether or not a packager is still around and not whether he cares about a certain package.
Regards Till
On Mon, 18 Jan 2010, Till Maas wrote:
First of all, that would be two bug reports per year, as we have a 6 month development cycle. But it also will not be that useful, as we already have three things that have to be done by every maintainer once or twice a year, so they can be easily used to track, whether or not a maintainer is still around at all: FAS password, Koji certificate Bugzilla password. Then if you intend to catch unused packages, this will also fail unless you also plan to implement some captcha for this for every package, because there will be a script that a maintainer can run to close all bugs for all of his packages at once, even for the packages he does not maintain properly. So you will still only track down, whether or not a packager is still around and not whether he cares about a certain package.
Yes, I believe the expression you're looking for is:
"Perfect is the enemy of the good"
What is being suggested is not perfect. It is, however, good.
-sv
On Mon, Jan 18, 2010 at 02:55:36PM -0500, Seth Vidal wrote:
Yes, I believe the expression you're looking for is:
"Perfect is the enemy of the good"
What is being suggested is not perfect. It is, however, good.
Here we disagree. As I explained I see little use in it, since there are other methods that work at least as good as this on, but are less annoying. And they might even perform better, wrt to the challenge to find unmaintained packages. Or in other words, I do not trust in the mass bugfiling method, so the other methods still need to be implemented to get the information I am interested in.
Also I cannot remember any argument from you that explains why your solution is superior to the other solutions.
Regards Till
On Mon, 18 Jan 2010, Till Maas wrote:
On Mon, Jan 18, 2010 at 02:55:36PM -0500, Seth Vidal wrote:
Yes, I believe the expression you're looking for is:
"Perfect is the enemy of the good"
What is being suggested is not perfect. It is, however, good.
Here we disagree. As I explained I see little use in it, since there are other methods that work at least as good as this on, but are less annoying. And they might even perform better, wrt to the challenge to find unmaintained packages. Or in other words, I do not trust in the mass bugfiling method, so the other methods still need to be implemented to get the information I am interested in.
Also I cannot remember any argument from you that explains why your solution is superior to the other solutions.
I've not heard any other solutions which aren't "oh just let it be."
-sv
On Mon, 2010-01-18 at 16:22 -0500, Seth Vidal wrote:
I've not heard any other solutions which aren't "oh just let it be."
It might have been missed in the passing but:
We have to reset our bugzilla password frequently We have to renew our Koji cert once a year
We should be able to detect when either of those goes wrong, probably easiest to do the koji cert one. If there was some way to take the list of accounts in pkgdb, and compare them to the active valid certs, and any discrepancies where the account owns packages, we can tag those for needing attention.
On Mon, 2010-01-18 at 13:39 -0800, Jesse Keating wrote:
It might have been missed in the passing but:
We have to reset our bugzilla password frequently We have to renew our Koji cert once a year
We should be able to detect when either of those goes wrong, probably easiest to do the koji cert one. If there was some way to take the list of accounts in pkgdb, and compare them to the active valid certs, and any discrepancies where the account owns packages, we can tag those for needing attention.
To be fair, this is a Maintainer down approach, as opposed to a package up approach. Seth is looking at this from the package point of view, where as the above looks at it from a maintainer point of view.
On Monday 18 January 2010 03:39:47 pm Jesse Keating wrote:
On Mon, 2010-01-18 at 16:22 -0500, Seth Vidal wrote:
I've not heard any other solutions which aren't "oh just let it be."
It might have been missed in the passing but:
We have to reset our bugzilla password frequently We have to renew our Koji cert once a year
Actually it has to be renewed every 6 months
We should be able to detect when either of those goes wrong, probably easiest to do the koji cert one. If there was some way to take the list of accounts in pkgdb, and compare them to the active valid certs, and any discrepancies where the account owns packages, we can tag those for needing attention.
there is an index file we can use to see if a user renewed there cert or not.
Dennis
On Mon, 2010-01-18 at 20:24 +0100, Tomas Mraz wrote:
So that means that for example for the openoffice.org-dict-cs_CZ package I'll get the nag bug report before each and every Fedora release?
It is definitely not 4. however 1. and 2. apply to it. As this is just a czech spelling and hyphenation dictionary which is pretty good one and we do not have any alternative anyway I do not think that 2. matters much.
OK, I think my next changelog entry in the .spec will be something like:
- rebuilding just for the sake of not getting a nonsense bug report opened against the package
Yet, this package still gets built nearly once a year, sometimes twice a year, due to changes in the distribution. You may not be doing the builds, but the package is getting touched and built.
Can the drama please.
On Mon, Jan 18, 2010 at 02:04:14PM -0500, Seth Vidal wrote:
I disagree about the bug being open. A lack of filed bugs could mean that no one CARES about the pkg at all. And if we have pkgs which are not being maintained AND no one cares enough to file a bug about then either they are:
- extraordinarily stable
- dead upstreams
- unmaintained
- unusued
in ANY of those cases I'd want to start thinking about nuking the pkg from fedora.
I would like to have more packages matching case 1 in Fedora! ;-) But I guess as soon as you look at non GUI packages that have a specialized use case, you will find a lot packages that do not need to be updated that often once they are old enough.
I use most of my packages, that are extraordinarily stable regularly. Upstream might be dead (or is in at least one case), but as far as they work for me without any problems, I do not see any problem there. If there is no change, there is also a less higher change that something is breaking. Examples of my packages: latex-mk, last change by me was 2007-07-28 and I know people who are using it daily with me being the first contact in case of problems. But there are none.
Then next example, fcgi. One change since 2007-08-23 by me (and two by Chris Weyl because of perl changes). Works fine for me every day for at least one service using fastcgi. Maybe there are more, I do not remember which do depend on it, but I know one that definitly does.
Then there is unclutter, the tarball is from 1994 and it still does it's job without any problems: hiding the mouse cursor when it's idle.
Imho the only real problem from your list is, if a package is unmaintained, because if it is maintained, the maintainer usually uses it, otherwise he would just drop it. If upstream is dead but the maintainer fixes bugs, when they are found, I do not see a problem, either.
Regards Till
On Mon, 2010-01-18 at 20:44 +0100, Till Maas wrote:
Imho the only real problem from your list is, if a package is unmaintained, because if it is maintained, the maintainer usually uses it, otherwise he would just drop it. If upstream is dead but the maintainer fixes bugs, when they are found, I do not see a problem, either.
Often maintainers don't realize they have some of these packages, or the maintainers have left the project.
Even your most stable packages get touched nearly once a year due to distribution changes. With a more active rpm upstream I suspect we'll be seeing even more need to rebuild everything, at least once a year.
In fact, if we were only checking once a year, I bet many of these packages are going to get hidden behind the mass rebuilder.
On Mon, 2010-01-18 at 11:55 -0800, Jesse Keating wrote:
On Mon, 2010-01-18 at 20:44 +0100, Till Maas wrote:
Imho the only real problem from your list is, if a package is unmaintained, because if it is maintained, the maintainer usually uses it, otherwise he would just drop it. If upstream is dead but the maintainer fixes bugs, when they are found, I do not see a problem, either.
Often maintainers don't realize they have some of these packages, or the maintainers have left the project.
Even your most stable packages get touched nearly once a year due to distribution changes. With a more active rpm upstream I suspect we'll be seeing even more need to rebuild everything, at least once a year.
In fact, if we were only checking once a year, I bet many of these packages are going to get hidden behind the mass rebuilder.
But these rebuilds are mostly automated ones by Fedora releng and as such not countable against the nag bug report.
On Mon, Jan 18, 2010 at 11:55:13AM -0800, Jesse Keating wrote:
On Mon, 2010-01-18 at 20:44 +0100, Till Maas wrote:
Imho the only real problem from your list is, if a package is unmaintained, because if it is maintained, the maintainer usually uses it, otherwise he would just drop it. If upstream is dead but the maintainer fixes bugs, when they are found, I do not see a problem, either.
Often maintainers don't realize they have some of these packages, or the maintainers have left the project.
Even your most stable packages get touched nearly once a year due to distribution changes. With a more active rpm upstream I suspect we'll be seeing even more need to rebuild everything, at least once a year.
The problem with this is that we mass rebuild for it. In the early days we had one or two massrebuilds that weren't automated in order to catch packages that were no longer maintained. We could go back to that model but is it desirable?
-Toshio
On Mon, 2010-01-18 at 15:08 -0500, Toshio Kuratomi wrote:
On Mon, Jan 18, 2010 at 11:55:13AM -0800, Jesse Keating wrote:
On Mon, 2010-01-18 at 20:44 +0100, Till Maas wrote:
Imho the only real problem from your list is, if a package is unmaintained, because if it is maintained, the maintainer usually uses it, otherwise he would just drop it. If upstream is dead but the maintainer fixes bugs, when they are found, I do not see a problem, either.
Often maintainers don't realize they have some of these packages, or the maintainers have left the project.
Even your most stable packages get touched nearly once a year due to distribution changes. With a more active rpm upstream I suspect we'll be seeing even more need to rebuild everything, at least once a year.
The problem with this is that we mass rebuild for it. In the early days we had one or two massrebuilds that weren't automated in order to catch packages that were no longer maintained. We could go back to that model but is it desirable?
Not in the least.
On Mon, Jan 18, 2010 at 11:55:13AM -0800, Jesse Keating wrote:
On Mon, 2010-01-18 at 20:44 +0100, Till Maas wrote:
Imho the only real problem from your list is, if a package is unmaintained, because if it is maintained, the maintainer usually uses it, otherwise he would just drop it. If upstream is dead but the maintainer fixes bugs, when they are found, I do not see a problem, either.
Often maintainers don't realize they have some of these packages, or the maintainers have left the project.
Do maintainer really "often" forget, that they own a certain package? Ok, maybe if they are forced to do this from Red Hat, I do not know. But I am happy for every package that I do not have to maintain.
But I think packages with no bug reports because they are not used are also not that big of a problem if they exist, unless they are really big or take very long to be rebuilt. It's imho at least not a problem that needs to be checked for every year. Or can you point to any known issues because of such packages since Fedora started?
Regards Till
On Mon, 18 Jan 2010, Till Maas wrote:
Often maintainers don't realize they have some of these packages, or the maintainers have left the project.
Do maintainer really "often" forget, that they own a certain package? Ok, maybe if they are forced to do this from Red Hat, I do not know. But I am happy for every package that I do not have to maintain.
But I think packages with no bug reports because they are not used are also not that big of a problem if they exist, unless they are really big or take very long to be rebuilt. It's imho at least not a problem that needs to be checked for every year. Or can you point to any known issues because of such packages since Fedora started?
Sure - we're expanding with no end in sight. Every pkg increases the load of metadata and crap that EVERYONE has to download and has to deal with.
If we have pkgs which are NOT being used then we can save everyone the bandwidth.
Let's call it a cleanliness thing.
-sv
On Mon, 2010-01-18 at 11:55 -0800, Jesse Keating wrote:
On Mon, 2010-01-18 at 20:44 +0100, Till Maas wrote:
Imho the only real problem from your list is, if a package is unmaintained, because if it is maintained, the maintainer usually
uses
it, otherwise he would just drop it. If upstream is dead but the maintainer fixes bugs, when they are found, I do not see a problem, either.
Often maintainers don't realize they have some of these packages, or the maintainers have left the project.
Even your most stable packages get touched nearly once a year due to distribution changes. With a more active rpm upstream I suspect we'll be seeing even more need to rebuild everything, at least once a year.
In fact, if we were only checking once a year, I bet many of these packages are going to get hidden behind the mass rebuilder.
So...the argument is we should worry about packages that don't get touched every six months, but no-one should be bothered about this, because everything gets touched at least every six months, even if it's not by the maintainer so the touch doesn't prove anything one way or another about the activeness or otherwise of the maintainer?
I'm a bit lost. :)
On Mon, Jan 18, 2010 at 10:27:04PM -0800, Adam Williamson wrote:
On Mon, 2010-01-18 at 11:55 -0800, Jesse Keating wrote:
On Mon, 2010-01-18 at 20:44 +0100, Till Maas wrote:
Imho the only real problem from your list is, if a package is unmaintained, because if it is maintained, the maintainer usually
uses
it, otherwise he would just drop it. If upstream is dead but the maintainer fixes bugs, when they are found, I do not see a problem, either.
Often maintainers don't realize they have some of these packages, or the maintainers have left the project.
Even your most stable packages get touched nearly once a year due to distribution changes. With a more active rpm upstream I suspect we'll be seeing even more need to rebuild everything, at least once a year.
In fact, if we were only checking once a year, I bet many of these packages are going to get hidden behind the mass rebuilder.
So...the argument is we should worry about packages that don't get touched every six months, but no-one should be bothered about this, because everything gets touched at least every six months, even if it's not by the maintainer so the touch doesn't prove anything one way or another about the activeness or otherwise of the maintainer?
I'm a bit lost. :)
After some talk on IRC yesterday, skvidal is the person doing work on this at them moment. His plan is to implement tests that try to tell if individual packages are maintained and get people to orphan those that are not. Here's his general plan for what to test:
""" 1. all the pkgs which have no devel checkins in > 365 days 1a, if the only checkins they have correspond to a massrebuild date - then they still get counted as potentially abandoned 2. all the pkgs which have no builds, other than mass rebuilds in > 365 days then take that set of pkgs and if it is a LARGE number of pkgs - then intersect that with pkgs which have bugs open to reduce the set a bit b/c open bugs AND not looked at == problems for fedora """
We discussed whether to do reporting from this via bugzilla or another tool and I'm leaning towards another tool so it's easy for a maintainer to look through and a list of packages and check which ones they still care about. skvidal would like to get the tests working first to see if we're talking about a huge number of packages or only a few.
-Toshio
On Tue, 19 Jan 2010, Toshio Kuratomi wrote:
After some talk on IRC yesterday, skvidal is the person doing work on this at them moment. His plan is to implement tests that try to tell if individual packages are maintained and get people to orphan those that are not. Here's his general plan for what to test:
"""
- all the pkgs which have no devel checkins in > 365 days 1a, if the only checkins they have correspond to a massrebuild date - then they still get counted as potentially abandoned
- all the pkgs which have no builds, other than mass rebuilds in > 365 days then take that set of pkgs and if it is a LARGE number of pkgs
a bit b/c open bugs AND not looked at == problems for fedora
- then intersect that with pkgs which have bugs open to reduce the set
"""
We discussed whether to do reporting from this via bugzilla or another tool and I'm leaning towards another tool so it's easy for a maintainer to look through and a list of packages and check which ones they still care about. skvidal would like to get the tests working first to see if we're talking about a huge number of packages or only a few.
I'm going to try and generate a couple of lists today if I can get all my koji-foo working properly.
-sv
2010/1/18 Seth Vidal skvidal@fedoraproject.org:
- extraordinarily stable
[...] in ANY of those cases I'd want to start thinking about nuking the pkg from fedora.
Are you serious?
- Thomas
On Tue, 19 Jan 2010, Thomas Moschny wrote:
2010/1/18 Seth Vidal skvidal@fedoraproject.org:
- extraordinarily stable
[...] in ANY of those cases I'd want to start thinking about nuking the pkg from fedora.
Are you serious?
As a heart attack.
-sv
On Mon, 18 Jan 2010 20:01:23 +0100, Tomas wrote:
I think there should be at least two conditions which would have to be fulfilled for the nagging bug to be created - the package was not touched by the maintainer during recent x months and at least one bug is opened not closed in the bugzilla on the package.
Taking into account bugzilla ticket statistics is much more interesting anyway, especially if combined with a package's FTBFS status *and* FAS account status *and* bugzilla account status (= password renewed and date of last login) *and* perhaps even scm-commit/koji-access status.
There are automated mass-rebuilds. There are provenpackagers who rebuild packages for SONAME bumps and even for FTBFS. Packages are touched regularly. But what does that tell about the package's owner and the package itself?
Who notices if a package has N open tickets, of which N have not seen any comment from the package's single maintainer in M months? With X additional tickets CLOSED/INSUFFICIENT_DATA at EOL because reporters didn't respond to the very late EOL NEEDINFO query either. How much do N, M and X grow before an orphan package or a non-responsive maintainer is discovered?
On Mon, 2010-01-18 at 22:51 +0100, Michael Schwendt wrote:
On Mon, 18 Jan 2010 20:01:23 +0100, Tomas wrote:
I think there should be at least two conditions which would have to be fulfilled for the nagging bug to be created - the package was not touched by the maintainer during recent x months and at least one bug is opened not closed in the bugzilla on the package.
Taking into account bugzilla ticket statistics is much more interesting anyway, especially if combined with a package's FTBFS status *and* FAS account status *and* bugzilla account status (= password renewed and date of last login) *and* perhaps even scm-commit/koji-access status.
There are automated mass-rebuilds. There are provenpackagers who rebuild packages for SONAME bumps and even for FTBFS. Packages are touched regularly. But what does that tell about the package's owner and the package itself?
Who notices if a package has N open tickets, of which N have not seen any comment from the package's single maintainer in M months? With X additional tickets CLOSED/INSUFFICIENT_DATA at EOL because reporters didn't respond to the very late EOL NEEDINFO query either. How much do N, M and X grow before an orphan package or a non-responsive maintainer is discovered?
That's why I think it is pretty clear that we have to have two approaches to the problem. One approach is about the maintainer, and when we discover a non-responsive maintainer (however long that takes) we drop all their packages.
The other approach is driven by the package, which will pick up things that are "owned" by somebody but they may not pay attention to it, or even remember they own it. That's the approach when we discover mismaintained packages, and orphan them at the package level.
These two approaches are not mutually exclusive, and can likely use some of the same data.
On Mon, 2010-01-18 at 12:25 -0500, Seth Vidal wrote:
If we do that check before the alpha release that should let us track down awol maintainers and unmaintained pkgs pretty easily, I think.
thoughts?
There's trivial packages which simply don't really need touching. I just updated congruity for the first time in a couple of months. it got a (very trivial) upstream release; upstream could easily have held off and I'd have had absolutely no reason to touch it. it's a simple package that just does what it's supposed to do, it doesn't need much TLC. I wouldn't want to be considered 'unresponsive' just because it hadn't needed touching for an arbitrary period.
On Mon, 18 Jan 2010, Adam Williamson wrote:
On Mon, 2010-01-18 at 12:25 -0500, Seth Vidal wrote:
If we do that check before the alpha release that should let us track down awol maintainers and unmaintained pkgs pretty easily, I think.
thoughts?
There's trivial packages which simply don't really need touching. I just updated congruity for the first time in a couple of months. it got a (very trivial) upstream release; upstream could easily have held off and I'd have had absolutely no reason to touch it. it's a simple package that just does what it's supposed to do, it doesn't need much TLC. I wouldn't want to be considered 'unresponsive' just because it hadn't needed touching for an arbitrary period.
which is why All we're suggesting is filing a bug and/or some other kind of notification that says "are you alive".
-sv
----- "Seth Vidal" skvidal@fedoraproject.org wrote:
which is why All we're suggesting is filing a bug and/or some other kind of notification that says "are you alive".
To clarify, only for FTBFS, right?
Jens
On Tue, 19 Jan 2010, Jens Petersen wrote:
----- "Seth Vidal" skvidal@fedoraproject.org wrote:
which is why All we're suggesting is filing a bug and/or some other kind of notification that says "are you alive".
To clarify, only for FTBFS, right?
There's a lot more details involved. When I have the full specs on what will get flagged I'll let everyone know.
-sv
On Sat, 16 Jan 2010 10:13:32 +0100 Michael Schwendt mschwendt@gmail.com wrote:
It's a more fundamental problem, though. The AWOL-process is for people, not for packages. The people may still be active (and even known to be active somewhere) and not AWOL, but the packages which are assigned to them would still look orphaned. FTBFS is just one way to find packages that don't even build. However, if that happens, it may be much too late. Such a package may have been in an unmaintained desolate state for a long time already. With nobody handling the incoming bugzilla tickets. With some bug reports having been killed in an automated way at dist EOL. And worse if it turns out that packages which do build are unmaintained nevertheless, with the same symptoms in bugzilla and in package scm.
Makes me wonder what bugzilla status report scripts we have? To create a list of potentially unmaintained packages earlier and to detect packages with non-responsive owners.
Yeah, there was talk a while back about setting something up to try and detect poorly maintained/unmaintained packages, but I fear nothing ever came of it.
I think it would be great to have some automated script that used a variety of input info to try and come up with a list of packages and/or maintainers who are not responsive. Unfortunately, this will be tricky to get right as there are a lot of corner cases: This could include:
- Process bugzilla. Maintainers: How many bugs are assigned to each maintainer. How many of those have never had a comment by that maintainer. How many of those are over a month old How many of those are over a year old How many of those are over 5 years old.
Packages: Packages with the most bugs (would need to weight somehow things like the kernel or X, and/or abrt bugs). Perhaps divide by co-maintainers? Packages that have upstream updates that haven't been acted on.
-SCM Commits / Bodhi / Koji
Packages:
Packages that have had no SCM commits in a cycle. Packages that have had no updates in a cycle.
Maintainers: Maintainers who have not commited to anything in a cycle Maintainers who have never submitted an update. Maintainers who have never built anything in koji. Maintainers who haven't built anything in a cycle. Maintainers who haven't built anything in a year. - Mail / FAS: Maintainers who have never posted to fedora* Maintainers who's fedora account system email bounces Maintainers who's fedora account system email is never responded to. Sponsors who have never sponsored anyone. Sponsors who have not sponsored anyone in a year. Sponsors who have not sponsored anyone in 5 years.
- Planet: Maintainers who have a feed, but no posts.
etc.
You can see there is a lot of info out there, but much of it may not apply in reality. Ie, there is a package that doesn't update because it's quite stable. It has no bugs against it and the maintainer isn't doing anything else in Fedora. :)
So, it might be nice to have such a tool and have it generate a list of possible maintainers/packages that need help. Then a human should look over the list and try and contact maintainers/gather info on packages and/or start unresponsive maintainer, etc.
Any takers for writing such a script?
kevin
On Sat, Jan 16, 2010 at 05:13:29AM +0100, Ralf Corsepius wrote:
perl-Class-InsideOut-1.09-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539136
I intended to take this one, but the packagedb doesn't offer me an option to take it:
C.f.: https://admin.fedoraproject.org/pkgdb/packages/name/perl-Class-InsideOut
This package appears to be owned by owner "orphan" and doesn't offer the "Take Ownership" button, I see on packages listed on https://admin.fedoraproject.org/pkgdb/packages/orphans otherwise.
Fixed in pkgdb now, thanks to Toshio.
Hi,
On 01/15/2010 08:17 PM, Matt Domsch wrote:
On Fri, Jan 15, 2010 at 12:00:50AM -0600, Matt Domsch wrote:
The following 30 packages, with respective FTBFS bugs, have been open since the Fedora 11 time frame, and continue to fail to build. These are the oldest non-building packages in the distribution, everything else (over 8800) managed to build for Fedora 12 or newer already.
At today's FESCo meeting, it was agreed that all the below packages would be marked orphan. I know several of these have been fixed by provenpackagers already - you are welcome to un-orphan and maintain them going forward, or the original package owner may choose to do so.
awn-extras-applets-0.3.2.1-8.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511628 evolution-brutus-1.2.35-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511451 geronimo-specs-1.0-2.M2.fc10.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511494 gmfsk-0.7-0.6.pre1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511780 gnome-scan-0.6.2-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511591 Io-language-20071010-10.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511617 knm_new-fonts-1.1-5.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=555487 libFoundation-1.1.3-11.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511470 ohm-0.1.1-9.39.20091215git.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539200 perl-AnyEvent-XMPP-0.4-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511749 perl-Class-InsideOut-1.09-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539136 perl-Jemplate-0.23-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=538984 perl-MooseX-Traits-Attribute-CascadeClear-0.03-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511570 perl-RRD-Simple-1.43-3.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=464964 perl-SVN-Mirror-0.75-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511770 perl-SVN-Simple-0.27-7.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511729 prctl-1.4-5.2.1.src.rpm (last built July 12, 2006, ExclusiveArch ia64) python-openhpi-1.1-3.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511675 qtiplot-0.9-11.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511688 recordmydesktop-0.3.8.1-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=538931 skychart-3.0.1.5-6.20081026svn.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539202 smarteiffel-2.3-2.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511362 synce-kde-0.9.1-4.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539195 unifdef-1.171-8.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511553
widelands-0-0.13.Build13.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511430 xpilot-ng-4.7.2-16.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511717
Ah, how nice, these 2 are orphaned now and I cannot take ownership due to a pkgdb bug, just great! Can some pkgdb admin please make me (jwrdegoede) the owner of xpilot-ng and widelands for devel ?
Thanks,
Hans
On Sat, Jan 16, 2010 at 11:12:03AM +0100, Hans de Goede wrote:
widelands-0-0.13.Build13.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511430 xpilot-ng-4.7.2-16.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511717
Ah, how nice, these 2 are orphaned now and I cannot take ownership due to a pkgdb bug, just great! Can some pkgdb admin please make me (jwrdegoede) the owner of xpilot-ng and widelands for devel ?
My apologies. Issue fixed in the database, have assigned the two packages to you, and backporting the fixfor this that went into pkgdb trunk but hasn't gone to the production instance yet.
-Toshio
On Fri, Jan 15, 2010 at 01:17:28PM -0600, Matt Domsch wrote:
unifdef-1.171-8.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511553
i fixed this, but i think we should still remove it because it has been superceded by the superior sunifdef.
regards, kyle
On Fri, Jan 15, 2010 at 01:17:28PM -0600, Matt Domsch wrote:
On Fri, Jan 15, 2010 at 12:00:50AM -0600, Matt Domsch wrote:
The following 30 packages, with respective FTBFS bugs, have been open since the Fedora 11 time frame, and continue to fail to build. These are the oldest non-building packages in the distribution, everything else (over 8800) managed to build for Fedora 12 or newer already.
At today's FESCo meeting, it was agreed that all the below packages would be marked orphan. I know several of these have been fixed by provenpackagers already - you are welcome to un-orphan and maintain them going forward, or the original package owner may choose to do so.
Why were the packages only orphaned for devel and not all supported branches? It is kind of strange to have a new maintainer only for devel, but not for the other branches as the qtiplot case shows.
Regards Till
On Wed, 2010-01-27 at 15:46 +0100, Till Maas wrote:
On Fri, Jan 15, 2010 at 01:17:28PM -0600, Matt Domsch wrote:
On Fri, Jan 15, 2010 at 12:00:50AM -0600, Matt Domsch wrote:
The following 30 packages, with respective FTBFS bugs, have been open since the Fedora 11 time frame, and continue to fail to build. These are the oldest non-building packages in the distribution, everything else (over 8800) managed to build for Fedora 12 or newer already.
At today's FESCo meeting, it was agreed that all the below packages would be marked orphan. I know several of these have been fixed by provenpackagers already - you are welcome to un-orphan and maintain them going forward, or the original package owner may choose to do so.
Why were the packages only orphaned for devel and not all supported branches? It is kind of strange to have a new maintainer only for devel, but not for the other branches as the qtiplot case shows.
It was easier to just do devel, and that's the only place a package would be blocked if these don't get owners. For the packages that do get owners, we can free up whichever branches the new maintainer wishes, which may not be all of them.
On Wed, Jan 27, 2010 at 08:56:30AM -0800, Jesse Keating wrote:
It was easier to just do devel, and that's the only place a package would be blocked if these don't get owners. For the packages that do get owners, we can free up whichever branches the new maintainer wishes, which may not be all of them.
But then the package appears to be still maintained in the stable branches in PkgDB, if they are only orphaned/blocked/retired in devel. This is something that may normally happen, e.g. when a package is obsoleted by another package.
Nevertheless, what is the recommended procedure to claim the other branches? Is it a ticket to FESCo trac or a CVS Admin procedure request?
Regards Till
On Thu, 2010-01-28 at 11:14 +0100, Till Maas wrote:
Nevertheless, what is the recommended procedure to claim the other branches? Is it a ticket to FESCo trac or a CVS Admin procedure request?
Honestly that's a good question. I'd start with a FESCo ticket and see what happens?
On Fri, 2010-01-15 at 00:00 -0600, Matt Domsch wrote:
xqilla-2.1.3-0.6.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511425
This one also has a major policy breach issue:
https://bugzilla.redhat.com/show_bug.cgi?id=555836
(it ships its own copy of xerces)
On Fri, Jan 15, 2010 at 01:12:14PM -0800, Adam Williamson wrote:
On Fri, 2010-01-15 at 00:00 -0600, Matt Domsch wrote:
xqilla-2.1.3-0.6.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511425
This one also has a major policy breach issue:
https://bugzilla.redhat.com/show_bug.cgi?id=555836
(it ships its own copy of xerces)
A new maintainer has stepped up and I've been working with him so he can get this bug fixed up as well. Hopefully we'll get this package will be ship shape soon.
-Toshio
On Fri, 2010-01-15 at 17:24 -0500, Toshio Kuratomi wrote:
On Fri, Jan 15, 2010 at 01:12:14PM -0800, Adam Williamson wrote:
On Fri, 2010-01-15 at 00:00 -0600, Matt Domsch wrote:
xqilla-2.1.3-0.6.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511425
This one also has a major policy breach issue:
https://bugzilla.redhat.com/show_bug.cgi?id=555836
(it ships its own copy of xerces)
A new maintainer has stepped up and I've been working with him so he can get this bug fixed up as well. Hopefully we'll get this package will be ship shape soon.
It'd be good to explain that on the bug reports, so we know the package shouldn't be blocked.
I want to take qtiplot, because the maintainer of qtiplot becomes unresponsive for nearly one year.
Since I am not a fedora packages yet, I need a sponser to review some of my packages such as https://bugzilla.redhat.com/show_bug.cgi?id=541207.
Chen Lei,
?
On 15/01/10 01:00 AM, Matt Domsch wrote:
The following 30 packages, with respective FTBFS bugs, have been open since the Fedora 11 time frame, and continue to fail to build. These are the oldest non-building packages in the distribution, everything else (over 8800) managed to build for Fedora 12 or newer already.
geronimo-specs-1.0-2.M2.fc10.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511494
This was a bit of a mess.
This package was last built successfully for F-11.
I have taken ownership of the orphaned package and built it for F-12. For F-13, there were numerous upgrades from 1.0-M4 all the way to 1.2. Unfortunately, none of these ever built, most were never tagged, and 1.2 has a number of build dependencies for packages that don't exist currently in Fedora.
It's not pretty, but I regressed the F-13 spec file back to the F-12 version (1.0-3.2.M2) which is the last successful version to build. I have documented what I did and what packages were missing so 1.2 work can resume if/when needed. There is work under-way by akurtakov to try and remove the need for the geronimo-specs package altogether.
The package has been built in rawhide and the FTBFS bug 511494 has been closed.
-- Jeff J.