Monday 24 January 2022

+1 maintenance report

Hello,

Amidst the mid-cycle sprints and being partly sick,
I was on +1 last week and did the following things:

## node-pbkdf2 (LP: #191828)

The tests have been failing on s390x because of it
being big-endian but I've been in touch with people
on the Debian side (we're all part of the JS team)
and we're trying to fix this. The upstream is dead
but we've proposed a first patch, which whilst doesn't
fully resolve the issue, it brings us a lot closer
to fix the issue at hand. I'll keep working with
them and keep updating the bug as and when we have
an update.

## bagel

One of the tests, ASD_DMRG, seemed to be failing on
s390x but when asked upstream, that test is "meant
to fail". Only by chance, it's failing on s390x for
us, so as intended upstream, I've patched bagel to
skip this test and everything seems to be working
(and passing) in bagel/1.2.2-3ubuntu1.

## mat2 (debbug #1002418)

src:mat2 was regressing with the new
libimage-exiftool-perl upload, resulting in an
AssertionError. This was already addressed
upstream but not in Debian or Ubuntu. Since there
was an RC bug (#1002418) open in Debian, I uploaded
an NMU there and things are now fixed via the
mat2/0.12.2-1.1 upload.

## ugrep

src:ugrep was stuck in proposed migration as it
was regressing src:forensics-extra on armhf.
Simply re-triggering the package on armhf made
it pass and src:ugrep has now migrated.

## esys-particles

Both, Gianfranco and myself, took a look at this
and the more we look at it, the crazier it gets. :)

This seems to be working in Debian perfectly
but somehow not on Ubuntu and the log says that
it can't find the said modules and this is very
much reproducible in an LXD container but we
couldn't find what was up with that. We suspect
that as the Python transition moves forward,
this will settle on its own, with a simple
re-trigger. So until then, we've left this as-is
and will revisit later, towards the end of the
cycle.

## ruby-fast-gettext (debbug #1002103)

There seemed to be FTBFS due to two reasons -
one, because of ruby3.0, related to tainting of
code, and two, because of API change in rails 6.
I was able to reproduce and fix them both via
2.0.3-1ubuntu2. Also, fixed the same in Debian
via 2.0.3-2 and furthermore, sent the patch
upstream via PR #136.

## python-sop

src:python-sop was stuck in proposed migration
as it was failing autopkgtest on armhf. Simply
re-triggering the package on armhf made it pass
and src:python-sop has now migrated.

## cmark-gfm (LP: #1958235)

This will probably be the highlight of my +1, heh.
cmark-gfm/0.29.0.gfm.2-1, which got auto-sync'd
from Debian was a soname bump and it started a
transition. It also slipped the maintainer's eye
and it resulted in breaking a handful of packages,
namely, pandoc, pandoc-citeproc, blogliterately,
gitit, and patat, at least. Christian noticed this
immediately and opened the bug and asked me to TAL.
I reverted the upstream version back to what it was
to temporarily stop the (bad) transition and uploaded
a fix via 0.29.0.gfm.2-1+really.0.29.0.gfm.0ubuntu1.
Quite a version, I know. :)

Meanwhile, this is being handled on the Debian side
and I'll make this a sync again later next week.

## phpmyadmin (LP: #1955284)

Two of the tests had been failing for so long
on s390x in Debian and Ubuntu, both. Whilst
Debian's failure doesn't prevent the migration,
Ubuntu's does. These tests have a problem on
32-bit problem and I wrote a patch for upstream
and it got accepted a few weeks back. However,
now it looks like these tests don't really
help with anything and are somewhat useless,
we (I and upstream) have decided to drop this.
As a result, I've dropped this in Ubuntu and
uploaded a fix via 4:5.1.1+dfsg1-5ubuntu1.

## php-symfony-polyfill

src:php-symfony-polyfill FTBFS'd with PHP 8.1.
I added a patch as a delta since Debian hasn't
yet reached that point of transition and
uploaded a fix via 1.24.0-1ubuntu1. It now works
well w/ PHP 8.1 and gets us closer to completing
the transition.

## php-league-commonmark

src:php-league-commonmark has a "risky" test that
was failing on s390x which stopped the migration
of php-symfony-polyfill upload. A couple of re-tries
made it pass and so did php-symfony-polyfill.

## libmarc-xml-perl

src:libxml-libxml-perl was stuck in proposed
migration as it regressed src:libmarc-xml-perl.
However, during the LHF, I investigated a bit
more and Gregor uploaded a fix and I re-triggered
the package with the right triggers and both,
src:libxml-libxml-perl and src:libmarc-xml-perl
have migrated.

## sdlgfx

src:sdlgfx was stuck in proposed migration as
it was regressing src:libalien-sdl-perl and
src:libsdl-perl on armhf. Since I am also a
part of the Perl team and I knew this was
a false-positive, simply re-triggering made
it pass and src:sdlgfx migrated to Jammy.

## libtap-parser-sourcehandler-pgtap-perl

src:libtap-parser-sourcehandler-pgtap-perl was
stuck in proposed migration as it was failing
autopkgtest on armhf. Simply re-triggering the
package on armhf made it pass and it has now
migrated.

## python-flask-marshmallow (debbug #989269)

The old version of python-flask-marshmallow was
rather useless and had no real documentation
available to the users. This version has been
there since Focal and I did the new upstream
release of the same in Debian via 0.14.0-1
and got it sync'd in for Jammy, the new LTS.

## doctrine/php-doctrine-*/php-defaults

This is a case of us running into a circular
dependency hellhole. To fix doctrine, we need
to fix php-doctrine-persistence, which needs
a fixed php-doctrine-common and a fixed
php-doctrine-persistence, which then depends
on doctrine, indirectly. This loop makes the
whole situation very chaotic and none of the
said packages build because of the "dependency
problem" now. As the first step, I opened
LP: #1958646 to drop the newer version of the two
source packages from jammy-proposed. Thanks,
Lukasz, for assisting that. After I worked this
whole thing out, it seems we will need an AA
to drop a few of these packages from Jammy
temporarily or introduce newer binary packages
in the archive. Either way, I'll follow with
some AA. (CC: Bryce).

## ruby-redis-rack, ruby-voight-kampff, thin

The above three packages were failing on arm64
and amd64 and simply re-trying the autopkgtest
made them pass, which in turn opened up the
gateway for a few more Ruby packages.

## ruby-rack

src:ruby-rack FTBFS'd and had a failing autopkgtest
because webrick is no more embedded in ruby3.0,
rather it is available as a separate package.
I uploaded a fix to Debian via 2.2.3-4 and to Ubuntu
via 2.1.4-5ubuntu1 - to prevent the new minor
version of rack auto-syncing, esp. until ruby3.0
has completely transitioned.


- u

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel