+1 maintenance report

[Olivier Gayot]

Hi,

I was on +1 maintenance from October 10th to the 14th.
Thank you Simon for the pointers and for sponsoring some of my work!

libcamera:
[LP: #1992331] fixed FTBFS for libcamera on ppc64el. I've found multiple 
reports where long double expressions on powerpc were not considered 
valid constant expressions by GCC. This seems to be partly due to how 
powerpc implements long double [1]. For libcamera, I introduced a delta 
in Ubuntu where we change the expressions to avoid the use of long 
double. The patch was merged in Debian too so we should be able to go 
back to syncing.
The patch was forwarded to libcamera upstream and the maintainer seem to 
agree for now to merge it despite the lack of benefit on other 
architectures.

aseba:
[LP: #1992431] The last uploads in Debian reduced the list of 
architectures supported. Since we have binary packages for s390x and 
ppc64el in the archive from an older version, I filed a removal bug for 
those binary packages.

aft:
[LP: #1992672] The build was failing when copying over the 
documentation. I uploaded a debdiff to fix it. The failing package is in 
-proposed and a version that builds already exists in the -release 
pocket. No need to sponsor for kinetic AFAICT. Forwarded the patch to 
Debian.

haskell-hoogle:
* [LP: #1992769] The autopkgtest times out on kinetic. I filed a bug and 
found out that hoogle (the main binary from src:haskell-hoogle) takes 
forever to install on armhf. Adding the package to long_tests would not 
help because long_tests do not affect the --timeout-install option of 
autopkgtest. Brian rightly suggested that we keep the package timing out 
rather than marking it never_run and potentially forget about it.

libfirefox-marionette-perl:
The package is incompatible with firefox shipped as a snap and it makes 
autopkgtest time out. The package was already removed from the archive 
in kinetic but is still present in jammy. I added this package to 
never_run to avoid further autopkgtest timeout on jammy.

ball:
LP: #1992816] investigated FTBFS on armhf for src:ball. On armhf only, 
the package build-depends on both libgles-dev and libglew-dev.
This happens because ball build-depends on qtbase5-dev which in turn has 
the following depends:
   libgl-dev [not armhf]
       Vendor neutral GL dispatch library -- GL development files
   libgles-dev [armhf]
       Vendor neutral GL dispatch library -- GLES development files
Those two libraries have conflicting type declarations. Seems to be a 
known issue without a clear path forward. This needs more work. 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798408


asmjit:
* Investigating asmjit build failure on s390x. Seems to be an endianness 
issue but upstream only supports aarch64, x86 and x86_64 backends. I 
considered changing Architecture: any to a more reduced list including 
only supported backends but feedback from people using this package 
would be nice to see if cross-compilation for an architecture with 
supported backend is a thing we should consider.

insighttoolkit4:
I did not spend as much time as I should have on this package shown in 
the NBS report. As Steve brought to my attention, it should have been 
the top priority last week and I failed to consider it as such.
The build fails somewhere in the dh_auto_test phase. The build log is 
large and verbose ; which does not make it simple to find out what 
exactly failed.

Thanks,
Olivier

[1] 
https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format#Double-double_arithmetic