I was looking at +1 maintenance items this week to make update-excuses
a better place. I've tackled a few cases that were more complex than "hit
retry" despite sprint and other duties trying to steal my time. For that I think
it became quite a list looking back at the end of the week.
All but the last cases here are for documentation for the interested,
but fully resolved and no problem for impish anymore.
The last case in this list still isn't fully complete and waiting for someone
pythonic to further debug module loading - so if that sounds tempting
or you are on +1 maintenance on next week - consider having a look :-)
# Iperf / Openvswitch
I looked into iperf being blocked by openvswitch tests as it rang some bells.
And indeed new bug 1936796 is the return of bug 1919432 which was also coming
up in +1 duty back then.
https://lists.ubuntu.com/archives/ubuntu-devel/2021-March/041419.html
Since nothing has changed since last time I went ahead and fixed mininet
in Impish via https://bugs.launchpad.net/ubuntu/+source/mininet/+bug/1936796
I also pinged upstream mininet about this still being a problem and that the
suggested patch helps at least all our cases.
After I got a review by James Pagewho dealt with mininet before I uploaded
a fix of mininet to impish. Sadly upstream didn#t reply yet, but that solves
our imminent issue.
After the new mininet was built I triggered the tests together and
everything related did migrate.
# xtensor
This is a autopkgtest fail that blocks src:xtensor and src:xtensor-blas.
The test fails on all architectures.
- s390x / arm64 / i386 fail on bad-package.
xtensor-dev became a transitional and is available on all arch.
But the actual dependency libxtensor-dev only exists on a few
libxtensor-dev | 0.22.0-5 | impish-proposed | amd64, armhf, ppc64el, riscv64
That explains the badpkg s390x issue, and I guess we can just reset it
instead of spending too much time fixing the package.
- also amd64 / ppc64 fail one of the tests by a build error.
The last good test was more than two years ago.
https://autopkgtest.ubuntu.com/packages/x/xtensor/impish/amd64
In debici this passes on amd64/arm64/armel/armhf/ppc64 but fails i386/s390x.
https://ci.debian.net/packages/x/xtensor/
And they are not all-skips.
The problem is reproducible locally and an OOM.
I filed https://bugs.launchpad.net/ubuntu/+source/xtensor/+bug/1936820
to track the various MPs to guide the testing into a better state.
It has 3 test-resets, 2 marked as big_package and one Debian MR to reduce
concurrency.
After all the changes were present tests worked as planned (now succeeding
on the architectures they can work on and ignored on the others). Thereby
xtensor and xtensor-blas migrated to impish-release.
# gegl
As usual, first of all file a launchpad update-excuse bug to avoid others
looking into the same case.
https://bugs.launchpad.net/ubuntu/+source/gegl/+bug/1936901
This turned out to be a real reproducible issue, most likely due to
the endianness. I did quite some debugging to ensure a high quality
bug report and then filed that issue upstream.
https://gitlab.gnome.org/GNOME/gegl/-/issues/289
Once we know if it is a regression (then we wait for a fix) or just
a new test exposing an issue we always had (then we might skip the tests)
we can decide on the next step.
# nftables / firewalld
I found nftables being blocked for more than two months due to a test
fail with firewalld.
As usual a LP bug will help to track any insight/effort and update-excuse
will make it show up for everyone:
https://bugs.launchpad.net/ubuntu/+source/nftables/+bug/1936902/+addcomment
After some debugging I found this to be a real regression in nftables which
had an upstream fix in the following version.
I did test builds, filed a Debian bug and some more verifications.
But it really looked all good when the fix was applied
After a kind review by fellow co-+1 Graham I did upload this to impish
and eventually that made nftables migrate.
# ntopng (3.8.1 rebuild) / ndpi (3.0 -> 3.4)
This is stuck since ntopng fails to build on arm*.
This rang a bell and I found some history on ubuntu-devel for this.
After an uncomfortably long trip through try-builds, dfsg crazyness
and updates to Debian bugs I ended up filing a removal request as
it seems the better approach for me after assessing the situation
in detail.
=> https://bugs.launchpad.net/ubuntu/+source/ntopng/+bug/1937016
And until removed the update-excuse tag ensures that no one else needs
to do archeology on this case again.
To resolve it long term I have bumped the Debian bug to clarify that the
new upstream version would fix the FTFBS
=> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977805#17
# pyspread
That was blocked by a autopkgtest-fail that happens in Ubuntu
https://autopkgtest.ubuntu.com/packages/p/pyspread
and Debian
https://ci.debian.net/packages/p/pyspread/
with the new 1.99.6-1 version.
This was already brought up in April in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986488
but not handled since then.
Note: This package is uncommon as it always runs the testsuite code and tests
against the same other packages but NOT against a packaged pyspread.
This happens because pyspread is not installed as dependency, only via the test
that extracts it. Therefore it is not necessarily always testing what you think.
For example you can not run the 1.99.6 test against the 1.99.5 binaries or
vice versa.
I found, debugged and fixed the broken testcase.
I reported it and a fix upstream
https://gitlab.com/pyspread/pyspread/-/issues/92
https://gitlab.com/pyspread/pyspread/-/merge_requests/36
I also bumped the Debian bug as FYI and filed a launchpad bug for other
plus-one people to be aware of.
Thanks to various people in #ubuntu-desktop for my journey through font-land.
I uploaded the fix to Impish to resolve it but did not migrate for another
issue this time on s390x due to big endian
https://bugs.launchpad.net/ubuntu/+source/pyspread/+bug/1937162
I fixed that new test as well - it is not a new regression, only a new
test coverage that was missed before.
I also reported it upstream in case there is a deeper underlying issue
that needs to be fixed.
https://gitlab.com/pyspread/pyspread/-/issues/93
With both applied it migrated.
# breezy / lintian-brush / breezy-debian
I have actually looked at those last plus-one-duty that I was on.
In the meantime
https://bugs.launchpad.net/ubuntu/+source/lintian-brush/+bug/1931369
were fixed through
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989634
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988909
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989633
But that wasn't all it seems, the breezy-debian bug
https://bugs.launchpad.net/ubuntu/+source/breezy-debian/+bug/1933034
now also affects lintian-brush at least in Ubuntu.
It turns out that there are staged issues.
First one would need to resolve the breezy 3.2.1 FTBFS
https://bugs.launchpad.net/ubuntu/+source/breezy/+bug/1937173
Once that FTBFS is solved breezy-debian and lintian-brush can be
rebuilt and will work.
Then finally the tests of silver-platter, breezy-debian, breezy and
lintian-brush all need to be re-triggered with combined triggers to each of
them.
The latter will then resolve bug 1933034.
But as I said first of all the breezy FTBFS in bug 1937173 needs to be solved.
I've done quite some debugging and documented it in the launchpad bug.
My current working theory is that the newer python that is in Impish is
not loading the test modules more than once.
The tests are designed to load modules that have "raise exception..." and
expect that to be processed.
That works once, but not ever again - as if python would keep it in some cache
and decide to "no I no more load that crap".
I've tried to clear loaded python modules sys.modules.items / sys.modules.pop
and also to make the module non-identical (in case they are hashed) but
neither approach has worked.
It is easily reproducible in e.g. a local sbuild but needs another pair
of pythonic eyes that want to dive deeper into the behavior of __import__.
This would be a great spot for next weeks +1 maintenance to continue on.
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
