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
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
