Le 2024-12-22 12:59, p...@debian.org a écrit :
Le 2024-12-22 09:07, Paul Gevers a écrit :On 22-12-2024 00:36, p...@debian.org wrote:There are a few autopkgtest regressions. I briefly looked at fast5 and it looks like its examples need changes for the new API. I haven't looked at the others. Can you take a look and file bugs as appropriate?* fclib: autopkgtest is successful on my boxI assume you test in a pure unstable/sid environment. Indeed on ci.d.n fclib also passes on unstable. Most of the times that means we're missing a *versioned* (test-) Depends or Breaks somewhere. The test infrastructure tries to test in a testing/trixie environment with as little as possible from unstable. Do you have any idea what that could be?* fenics-dolfinx: autopkgtest is successful on my boxSame.* gatb-core: autopkgtest is successful on my boxSame.* petsc: autopkgtest is successful on my boxSame.Should I upload a new HDF5 revision with versioned `Breaks:` against these packages?
As I understand it the failing test for fclib depends on libfclib-dev which brings the transitioning libhdf5-dev. This leads to an executable linked to both libhdf5_serial_hl.so.100 and libhdf5_serial_hl.so.310, causing the failure.
What is the best practice to prevent this?I thought about adding `Breaks: libfclib-dev (<< 3.1.0+dfsg-3+b4)` to libhdf5-dev but it seems inappropriable because the binNMU number is not the same for all architectures.
Best, _g.
signature.asc
Description: OpenPGP digital signature
