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

Reply via email to