Friday 21 January 2022

+1 maintenance report

Here's my report for the week of Jan 17-21.
I have been working mostly on the long tail of universe packages that fail to
build from source, as collected and reported by ginggs [0].

### bagel ###

bagel / 1.2.2-2

Fails to build with C++17/GCC-11 due to an ambiguous variable name, that
is now also provided in std::legendre (the source imports is by calling
'using std;').

I submitted the fix upstream and sent it over to Debian.
https://github.com/qsimulate-open/bagel/pull/237
https://bugs.debian.org/983979


### argus-clients ###

argur-clients / 1:3.0.8.2-6ubuntu3

Merged revision 1:3.0.8.2-6.1 NMU of argur-clients from Debian unstable
in order to fix the FTBFS with autoconf 2.70+.

https://bugs.debian.org/980017


### doc-linux-fr ###

doc-linux-fr / 2013.01-3ubuntu1

Fails to build because of an invalid LaTeX UTF-8 byte sequence. Setting the
output encoding of the xslt processor to UTF-8 fixes this.

https://bugs.debian.org/910813
https://bugs.debian.org/880786 (Also submitted this old patch while on it)


### astropy ###

astropy / 4.3.1-4ubuntu1

Syncing 5.0-1 from Debian unstable after verifying the build passes on all
architectures and autopkgtests pass, too (at least when tested against
all-proposed=1). Dropping the Ubuntu delta that isn't needed anymore.


### gringo ###

gringo / 5.4.1-3ubuntu2

The (outdated) embedded copies of catch v1 & catch v2 are incompatible
with glibc-2.34+, due to SIGSTKSZ/MINSIGSTKSZ not being a constant anymore.
This issue was resolved in newer versions of catch2 upstream and patched to
be compatible in Ubuntu's version of catch v1.
Unfortunately libgringo, libclingo, libreify and libpotassco are all using
outdated embedded versions of catch. I made it use the versions shipped
by the distro and added catch and catch2 as build-depends to fix this.
C.f.: https://github.com/catchorg/Catch2/issues/2178

Reported the issue (especially for catch v1) to upstream libpotasco:
https://github.com/potassco/libpotassco/issues/12


### clasp ###

clasp / 3.3.5-4

The embedded copy of catch v1 is incompatible with glibc-2.34+, due to SIGSTKSZ
not being a constant anymore. This issue was patched to be compatible in
Ubuntu's version of catch v1. Unfortunately clasp and libpotassco are using
outdated embedded versions of catch. I made it use the versions shipped
by the distro and added catch v1 as build-dependency to fix this.
C.f.: https://github.com/catchorg/Catch2/issues/2178

Reported the issue to upstream clasp:
https://github.com/potassco/clasp/issues/73
https://bugs.debian.org/1004022


### dnsmasq ###

dnsmasq / 2.86-1.1

I triaged an autopkgtest failure together with cpaelzer:
dnsmasq needs some patches from systemd-stable that will be fixed once
systemd >= 249.7 is merged (due in the next couple of weeks).

https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1957086


### fuzzylite ###

fuzzylite / 6.0+dfsg-3

Same same as above with gringo/clasp, fixing catch v1 vs glibc 2.34 compat.


### soci ###

soci / 4.0.1-5

Same same as above with gringo/clasp, fixing catch v1 vs glibc 2.34 compat.

https://github.com/SOCI/soci/pull/886


### sponsorings ###

cpio /  2.13+dfsg-7
acl / 2.3.1-1
libdatrie / 0.2.13-2

Sponsoring some syncs from Debian unstable for xypron (https://pad.lv/1958131),
schopin (https://pad.lv/1958244) and waveform (https://pad.lv/1958415).
All Ubuntu delta has been applied upstream.


### libodb ###

libodb / 2.4.0-1build2

Fix FTFBFS with C++17/GCC-11, by avoiding dynamic exception specification.
GCC 11 defaults to C++17 which does not allow dynamic exception specifications
anymore. Replace them as described in https://gcc.gnu.org/gcc-11/porting_to.html
Patch by Adrian Bunk
Triggered no-change rebuilds for libodb-[boost,mysql,pgsql,qt,sqlite], to build
against new, C++17 compatible libodb headers.

https://bugs.debian.org/984189


### fwbuilder ###

fwbuilder / 5.3.7-4.1build2

Package is using dynamic exception specification, which is deprecated as of
C++17/GCC-11. Upstream fixed the code and we can cleanly apply the upstream fix
to resolve the issue.

https://github.com/fwbuilder/fwbuilder/commit/ed4db20
https://bugs.debian.org/984144


### osmium-tool ###

osmium-tool / 1.13.2-1

Cherry-pick upstream commit, switching to catch2 >= 2.13.5 to fix compatibility
with glibc 2.34 and FTBFS. This was entangled with https://pad.lv/1958235,
(pandoc vs libcmark-gfm.so.0.29.0.gfm.0), thanks utkarsh and cpaelzer for
resolving this in a timely manner!

https://github.com/osmcode/osmium-tool/commit/db7cf4e


### junos-eznc ###

junos-eznc / 2.1.7-3

The 'collections.MutableMapping' alias was removed in Python 3.10,
'collections.abc.MutableMapping' should be used instead. I cherry-picked some
upstream commits (partly) to fix the FTBFS with Python 3.10+ (b9bff50 & 74631fc)

https://github.com/Juniper/py-junos-eznc/commit/b9bff50
https://github.com/Juniper/py-junos-eznc/commit/74631fc
https://bugs.debian.org/1002187


### salt ###

salt / 3004+dfsg1-6

After fixing the junos-eznc FTBFS, which crashed the tests of salt, another
failure showed up in test_yaml.py: This test is still using the outdated
'collections.MutableMapping' alias, too. I cherry-picked an upstream commit
to fix the issue. This should now allow for the removal of python-crypto.

https://github.com/saltstack/salt/commit/78525c9
https://github.com/saltstack/salt/pull/61295

Cheers,
  Lukas

[0] https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20211217-jammy-jammy.html