I've been on +1 maintenance over the last two days. I'm not sure I've achieved anything very significant but oh well. I'll come back tonight to check on things and probably file a few removal request bugs.
I mostly started at the bottom of excuses and worked my way up. There are two big messes I saw: rust-* and golang-*. I think the rust packages can mostly be ignored or deleted but there are some useful packages held up by the go mess. Maybe at some point one of the people on the +1 rotation should focus on just that for a couple of days. I looked at the r transition. https://people.canonical.com/~ubuntu-archive/transitions/html/html/r-api-combined.html showed only three bad packages, all of which were due to rgtk2's failure to build on s390x. Completely failed to understand the build failure (if you run the tests a second time in a failing tree, they pass!?). Given the package is dead upstream, has few rdeps, depends on the obsolete gtk2 and that the number of people running a graphical r application on s390x must be 0, the pragmatic way forward is likely to delete these binaries. Looked into the pcs/python-tornado/mitmproxy knot. Tried a simple upstream update of mitmproxy but it now depends on https://pypi.org/project/zstandard/ which does not appear to be packaged. I fixed sctk's ftbfs and sent the patch to debian ( bugs.debiagolang-github-prometheus-client-golangn.org/962439 <http://bugs.debian.org/962439>). rocksdb from debian experimental builds fine on Ubuntu. I wonder what's preventing it from being uploaded to unstable? I spent a while on qosmic before finding doko's debian bug report had been moved to another package and realizing that the builds just needed to be retried. python-gmpy2 hangs on armhf... need to look into that There is a knot of go packages related to prometheus held up by what might be flaky tests on arm64. postgresql-filedump's autopkgtest was failing on s390x and it turns out that pg dump files are endian dependent and the test uses one generated on a little endian system. I uploaded a version that will skip the test on a big endian system (and send the patch to Debian). I fixed a couple of build issues in nux and uploaded. nss-wrapper needs its i386 hint bumping, filed an MP for that. There is a mess around ndpi / ntopng. Debian started a transition to ndpi 3 some time ago but it ftbfs on some arches and the maintainer seems to have given up. Some guy called "Dimitri" tried to engage with upstream on the big endian problems: https://github.com/ntop/nDPI/issues/843 gnuift ftbfs, has for a long time, is orphaned and not in unstable --> we should remove it gkrellm2-cpufreq now depends on a package that the debian src:linux builds but ours does not (libcpupower-dev) ggcov also seems fairly dead I fixed python-django-gravatar2's autopkgtest in debian, presumably it will sync over soon. Cheers, mwh
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
