Plus One Maintenance for Week of Jan 23-27, 2023
Here's notes for what I've worked on. Interspersed are some items that
may need further attention; sorry they're not flagged but hopefully my
notes may be of some use.
### node* cluster ###
nodejs is transitioning from 18.7.0 to 18.13.0.
* Latest version of npm hadn't run tests against nodejs 18.13, so I've
done a broad retrigger against that and node-undici. Succeeded.
* node-help-me needed node-mqtt retriggered, then migrated successfully
* node-rechoir needed node-liftoff and node-webpack retriggered;
both passed successfully, and node-rechoir migrated.
The following were just out of date on ABI, so I did no-change rebuilds:
* node-coveralls rebuilt as 3.1.1-2build1
* node-json5 rebuilt as 2.2.3+dfsg-1build1
* node-readable-stream rebuilt as 3.6.0+~cs3.0.0-4build1
* node-ts-jest rebuilt as 29.0.3+~cs0.2.6-1build1
Those four packages all built successfully, and their basic autopkgtests
succeeded with the old nodejs. I retriggered them all against the
new nodejs, and they all passed successfully as expected.
node-solid-keychain and node-trust-webcrypto are unmaintained upstream
and in fact the latter is flagged by upstream as recommended not to use
due to potential security issues. I filed a removal request for both
packages (LP: #2003831), and vorlon dropped them from the archive.
nodejs is now unblocked and is marked as "Will attempt migration."
### rubocop cluster ###
* ruby-rubocop-ast showed an implicit dependency between
ruby-rubocop-ast rubocop. I retriggered all the tests for rubocop
with ruby-rubocop-ast added as a trigger.
- This appears to have succeeded, and ruby-rubocop-ast is now marked
as "Will attempt migration" \o/
With that fixed, it looks like rubocop itself is also marked as "Will
attempt migration".
A few other *rubocop* packages that were blocked by the above two also
look likely to migrate now.
This entire cluster successfully migrated Thursday.
### ipython cluster ###
* ipywidgets was blocked by migration issue in q2-feature-table.
Retriggering that cleared it, and ipywidgets successfully migrated.
* python-pweave had an armhf migration error, but jbicha successfully
retriggered it to pass for ipython.
* python-qtconsole 5.4.0-1 hadn't been triggered against the new
ipython. I've done the retrigger, with triggers for other depends in
proposed.
* ipython itself I've retriggered against other python components in
proposed.
This entire cluster successfully migrated Thursday.
### python3-defaults cluster ###
python3 has been undergoing transition from 3.10 to 3.11. There's about
four dozen remaining migration issues, I pitched in on a few:
* python-django-tagging needed sync'd; succeeded.
* guake on arm64 needed retrigger with gobject-introspection; succeeded.
* q2cli needed retriggered with python3-defaults on arm64; succeeded.
* siconos on amd64 and arm64 needed retriggers; succeeded.
* python-configshell-fb needed retriggered with python3-defaults; succeeded.
* python-exchangelib needed retriggered with python3-defaults on all
arches; succeeded.
* python-xmlrunner needed retriggered with python3-defaults on all
arches; succeeded.
* fastapi needed retriggered with python3-defaults on all
arches; succeeded.
* conda-package-streaming needed retriggered with python3-defaults on all
arches; succeeded.
* dypi 1.5.0-7ubuntu1 was merged by graham inggs to fix tests, but
needed retriggered with python3-defaults.
* breezy 3.3.2-1ubuntu1 was introduced by Paride to disable flaky test
plugins. This needed retriggered with python3-defaults on all arches,
but also seems to still be flaky at least on amd64, so I also
retriggered the test for that arch a couple more times. Appears to
have finally resolved.
* deepnano/s390x:
- Debian has marked this package for removal. It has been failing in
testing and they no longer include it in CI. It's unmaintained
since 2017, and also depends on unmaintained package theano. See
Debian bugs #1026539, #1027215.
- I didn't file a removal request, but suspect we should...
* pytorch:
- There's a new 1.13.1 release that probably updates it to python
3.11. Debian hasn't merged that yet but there is some discussion to
do so. See LP: #2002685
- It looks like pytorch was removed from the archive instead (see LP:
#2003960). There are a few other pytorch packages that may also
#need attention.
* ceph:
- We're ahead of Debian with 17.2.0
- There are newer releases upstream, 17.2.[1-5]
https://ceph.com/en/news/blog/2022/v17-2-1-quincy-released/
https://ceph.com/en/news/blog/2022/v17-2-2-quincy-released/
https://ceph.com/en/news/blog/2022/v17-2-3-quincy-released/
https://ceph.com/en/news/blog/2022/v17-2-4-quincy-released/
https://ceph.com/en/news/blog/2022/v17-2-5-quincy-released/
- See LP: #1998958 "[SRU] ceph 17.2.5"
- However, the real issue is python3.11 support is missing, even in the
current upstream codebase. See line 20:
https://github.com/ceph/ceph/blob/main/cmake/modules/FindPython/Support.cmake
set(_${_PYTHON_PREFIX}_VERSIONS 3.10 3.9 3.8 3.7 3.6 3.5 3.4 3.3 3.2 3.1
3.0)
- Adding 3.11 to that line seems required, but more might be needed.
See this upstream PR:
https://github.com/ceph/ceph/pull/48947
- I filed an update-excuse bug, LP: #2004038
### graphicsmagick cluster ###
* asymptote on arm64 needed retrigger; succeeded.
* auto-multiple-choice on arm64 needed retrigger; succeeded.
* balsa on arm64 needed retrigger; succeeded.
* node-imagick on arm64 needed retriggered; succeeded.
* raster3d on arm64 needed retriggered; succeeded.
* recoverjpeg on arm64 needed retriggered; succeeded.
* ruby-mini-magickon arm64 needed retriggered; succeeded.
* cimg on all arches needed a broader retriggering against a bunch of
packages, including perl, nodejs, etc.
With all that cleared, graphicsmagick transitioned successfully, and
everything blocked by it has migrated successfully.
### r-base cluster (r-cran*, r-bioc*) ###
Many of the r-cran packages are blocked from migration until r-base is
ready to transition.
* r-cran-sftime FTBFS needed a rebuild; tests now running
* r-cran-epir FTBFS needed a rebuild; waiting on one armhf test, rest good.
* r-cran-flextable waiting on r-cran-epir (above)
* r-cran-stars FTBFS needed a rebuild
- One autopkgtest 'neutral' on s390x, but migration-reference/0 also
'neutral'.
- Retriggered test for s390x, with r-base, et al.
* r-bioc-basilisk's -4 changelog says "Due to conda dependencies this
package seems to work for amd64 only". With -4 its tests now fail on
arm64, armhf, and ppc64el. I'm wondering if we should not be testing
on these other architectures, but am unsure what would need done.
- I filed update-excuse LP: #2003827 about the problem; Graham Inggs
took care of hinting it, and it's successfully migrated.
A couple dozen r-cran* packages all have test failures on just the armhf
architecture. Spot checking, they seem to be web socket failures, or
other issues that might be armhf flaky hardware; it appears the errors
have happened intermittently in the past. Most of these have already
been retriggered by jbicha so I've left them as is, but there may be
more retriggering to do. (Since these armhf errors appear to occur
fairly regularly, it may be worth deeper investigation to see if things
can be made to work more robustly...)
The above work seems to have cleared the logjam for r-base, which
transitioned successfully and allowed a lot of r-bioc-* stuff to
migrate. There's still some r-cran* bits still in process but no
remaining migration issues. So this entire cluster may finish migration
today or tomorrow.
### tdb / squid cluster ###
* pulseaudio on ppc64el needed retriggered
* sssd on ppc64el needed retriggered
* squid on ppc64el needed retriggered
squid was actually blocking a number of items. I retriggered it with
the current -proposed versions of all of them, and it succeeded. squid
successfully migrated from 5.6 to the new 5.7 merge as a result.
sssd is clear of migration blockers, except for samba and
python3-defaults.
tdb is also free from migration blockers other than python3-defaults,
and should now migrate once that transitions.
### talloc / osmo cluster ###
* libosmo-sccp on amd64 needed retriggered
* osmo-pcu needed retriggered (all arches)
The armhf tests took a while to finish running, but everything cleared
Thursday. talloc should now complete migrating once python3-defaults
finishes its transition.
### libmoose-perl cluster ###
* libgeo-calc-perl on amd64 needed retriggered; succeeded
* libaudio-mpd-common-perl on amd64 needed retriggered; succeeded
* libterm-filter-perl is the only remaining failure. This has been
intermittently failing/passing for some time. Debian has a bug report
about the flaky test fail (Deb: #843052) which I've added to Launchpad
as an update-excuse bug (LP: #2003923). I think all we can do is keep
retrying the same triggers until it passes.
libterm-filter-perl finally passed Thursday, and libmoose-perl
successfully migrated.
### numpy cluster ###
* pygac on ppc64el needed retriggered for 1.7.1-2 against numpy,
bottleneck and python3-defaults (and maybe a few others); succeeded.
* einsteinpy on ppc64el failed to retrigger, but was a known issue in
Debian (Deb #1027198). A fixed version 0.4.0-1 sync'd in from Debian,
but failed on s390x. Another fixed version 0.4.0-2 brings a fix for
s390x as well, but tests haven't run for that.
(A bunch of the python packages I've listed elsewhere in this report were
blocked because they also needed retriggered against numpy in addition to
python3-defaults.)
### libcommons-net-java ###
Was blocked by autopkgtest issue for nrepl-clojure on arm64.
Passed successfully after retriggering, enabling it to migrate
successfully.
### maven-artifact-transfer ###
FTBFS needed simple rebuild.
Tests passed ok, and it's migrated successfully.
### golang-github-azure-azure-storage-blob-go ###
Was blocked by golang-gocloud on arm64, and migrated successfully after
that was retriggered.
### gscan2pdf on armhf timeout ###
Passed after a retrigger and migrated successfully.
This mentioned a timeout in its test log, however it looks like it was
something network related, so presumably was armhf hw flakiness. It's
failed intermittently with the same issue in the past, so may be worth
deeper investigation when it occurs in the future.
I did another, broader retriggering with systemd, graphicsmagick,
apache2, libpdf-builder-perl, etc. just in case there were any stray
things dependent on it. That succeeded without issue.
### ycmd on amd64 ###
This hit a timeout, and passed on retriggering, enabling
0+20220824+git2ee4100+ds-2build1 to successfully migrate.
However, there's a new git snapshot, 0+20230103+gitf53e7ac+ds-1, which
has just sync'd in from Debian but awaits python3-defaults to finish
transitioning.
### freedombox ###
Log shows it hit memory exhaustion. Attempted retrigger... succeeded
and migrated successfully.
### pkg-config / pkgconf ###
Autopkgtests fail due to a conflict of these two packages:
"pkg-config/amd64 in main cannot depend on pkgconf in universe."
This pkgconf / pkg-config conflict has been going on for a couple months
whenever these two get triggered together. There is a MIR for pkgconf
to replace pkg-config (LP: #1998095). I've tagged it update-excuse for
+1 maintenance reference.
## jaraco.text Impossible Depends ##
python3-jaraco.text is in main but the new 3.11.0 version depends on
python3-autocommand/2.2.2-2 and python3-inflect/2.1.0-4 which are in
universe. These were just added as build dependencies by Debian in
3.11.0-1.
James Page added a MIR (LP: #2001699), which is in progress.
I added a bugtask for jaraco.text with the update-excuse tag for
tracking.
## colord Impossible Depends ##
colord is bumped in debian from 1.4.6-1 to 1.4.6-2.1. Debian is
re-enabling Argyll support, however argyll is in universe for Ubuntu.
There is an existing MIR for argyll, LP: #821883, however it is old and
last active in 2018. I pinged it, and got attention from Eickmeyer and
Didrocks. Looks like it awaits input from RAOF regarding next actions.
- TODO: Update with his response
I've also opened LP: #2003833 against colord to track the update-excuse
migration problem, for future +1 maintainer reference.
## ceilometer Impossible Depends ##
python3-ceilometer/amd64 in main cannot depend on python3-xmltodict in universe
Impossible Depends: ceilometer -> python3-xmltodict/0.13.0-1/amd64
There is an existing MIR for xmltodict, LP: #2002576. Added bugtask for
ceilometer and tagged update-excuse.
## coreutils ##
coreutils 9.1-1ubuntu2 is merged, but blocked by datefudge on armhf
Debian runs into this issue as well, see Deb #1028587 and LP: #2002803.
Unfortunately per the upstream maintainer the package is no longer
maintained and he recommends moving things dependent on it to other
alternative libraries like libfaketime.
datefudge is required by gcc-12-base, libc6, etc. so doesn't seem like
we can just drop it.
It's a very small codebase (single .c file) so presumably shouldn't be
too time consuming to fix up...
Meanwhile, I've tagged LP: #2002803 as update-excuse.
## Merge plfit ##
Handled the merge for plfit from MoM. Delta just carries forward.
Builds succeeded and tests passed in the PPA, but migration might be
blocked by the python3-defaults transition.
## Stats ##
2023-01-22 1251 update excuse records found
2023-01-23 1232
2023-01-24 1172
2023-01-25 1687 <-- [debian autosync is re-enabled]
2023-01-26 1290
2023-01-27 1172
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
