On 12/1/18 5:16 PM, Gilles Filippini wrote: > On Fri, 30 Nov 2018 15:53:29 +0100 Gilles Filippini <pini@debian.org> wrote: >> On 2018-11-30 14:31, Emilio Pozuelo Monfort wrote: >>> On 17/11/2018 11:54, Emilio Pozuelo Monfort wrote: >>>> Control: tags -1 confirmed >>>> >>>> On 15/11/2018 21:37, Gilles Filippini wrote: >>>>> Package: release.debian.org >>>>> Severity: normal >>>>> User: release.debian.org@packages.debian.org >>>>> Usertags: transition >>>>> >>>>> Hi Release Team, >>>>> >>>>> I hereby request a transition slot for hdf5 1.10.4 currently in >>>>> experimental. >>>>> >>>>> Ben file: >>>>> >>>>> title = "hdf5"; >>>>> is_affected = .depends ~ /libhdf5/ | .build-depends ~ /hdf5/; >>>>> is_good = .depends ~ >>>>> /libhdf5-103|libhdf5-openmpi-103|libhdf5-mpich-103/; >>>>> is_bad = .depends ~ >>>>> /libhdf5-100|libhdf5-openmpi-100|libhdf5-mpich-100/; >>>>> >>>>> I've checked the build of all the reverse dependencies against this >>>>> release, and from the 110+ of them, only those - which are not in >>>>> testing - aren't binnmu ready: >>>> >>>> Go ahead. >>> >>> gnudatelanguage's autopkgtests fail with the new hdf5/netcdf, which >>> block >>> netcdf's testing migration. Can you take a look? >>> >>> https://ci.debian.net/packages/g/gnudatalanguage/testing/amd64/ >> >> I'll have a look this w-e, but I'm not very optimistic because these >> failures are segmentation faults. >> Since gnudatalanguage has a not so high popcon, an option would be to >> temporarily remove it from testing, to gain time to investigate the >> problem. > > I really don't know how to debug this. You shouldn't have to, you're not the maintainer of that package. > What I can say is that it isn't related to the current HDF5 1.10.4 transition: I've rebuilt gnudatalanguage against HDF5 1.10.0-patch1+docs-4+b2 from testing (with netcdf and grib-api rebuilt as well) and the very same failure occurs, at least for TEST_POINT_LUN: gnudatalanguage has been problematic in a prior netcdf transition too. I would just file an RC bug for the failing tests and let the maintainer take it from there. If they are unable to fix the issue, the package will be autoremoved from testing. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Attachment:
signature.asc
Description: OpenPGP digital signature