Bug#922107: marked as done (nmu: scalapack_2.0.2-7 mocassin_2.02.73-1 netpipe_3.7.2-7.4)
Your message dated Tue, 12 Feb 2019 11:06:32 +0100
with message-id <222ac0f9-348c-536c-5fb6-0f7fbe514d61@debian.org>
and subject line Re: Bug#922107: nmu: scalapack_2.0.2-7 mocassin_2.02.73-1 netpipe_3.7.2-7.4
has caused the Debian Bug report #922107,
regarding nmu: scalapack_2.0.2-7 mocassin_2.02.73-1 netpipe_3.7.2-7.4
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)
--
922107: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922107
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: binnmu
nmu scalapack_2.0.2-7 . ANY . unstable . -m "Rebuild against mpich 3.3 release."
nmu mocassin_2.02.73-1 . ANY . unstable . -m "Rebuild against mpich 3.3 release."
nmu netpipe_3.7.2-7.4 . ANY . unstable . -m "Rebuild against mpich 3.3 release."
We have to rebuild all packages that were built against an alpha/beta/rc
of mpich 3.3 (i.e. a mpich package versioned 3.3~<something>-<rev>
instead of 3.x-<rev>) because their libmpich12 actually contains
libmpich.so.0 instead of libmpich.so.12
e.g.:
# ldd /usr/bin/mocassin
linux-vdso.so.1 (0x00007ffc19163000)
libgfortran.so.5 => /usr/lib/x86_64-linux-gnu/libgfortran.so.5 (0x00007f2c0badd000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2c0b95a000)
libmpichfort.so.0 => not found
libmpich.so.0 => not found
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2c0b940000)
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f2c0b8ff000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2c0b73c000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2c0b51e000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2c15486000)
Luckily there are only 12 source packages building packages dependening
on libmpich12, so I could check the age of their builds manually.
Is there some tool that can examine buildinfo files (or build logs) to
find any builds (that are still in sid (or $distro)) that were done with
a particular bad package installed?
In this case I would have wanted 'libmpich12 (<< 3.3-1)' as bad version.
Andreas
--- End Message ---
--- Begin Message ---
On 12/02/2019 04:51, Andreas Beckmann wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: binnmu
>
> nmu scalapack_2.0.2-7 . ANY . unstable . -m "Rebuild against mpich 3.3 release."
> nmu mocassin_2.02.73-1 . ANY . unstable . -m "Rebuild against mpich 3.3 release."
> nmu netpipe_3.7.2-7.4 . ANY . unstable . -m "Rebuild against mpich 3.3 release."
>
> We have to rebuild all packages that were built against an alpha/beta/rc
> of mpich 3.3 (i.e. a mpich package versioned 3.3~<something>-<rev>
> instead of 3.x-<rev>) because their libmpich12 actually contains
> libmpich.so.0 instead of libmpich.so.12
Huh. That should have been flagged by lintian...
>
> e.g.:
>
> # ldd /usr/bin/mocassin
> linux-vdso.so.1 (0x00007ffc19163000)
> libgfortran.so.5 => /usr/lib/x86_64-linux-gnu/libgfortran.so.5 (0x00007f2c0badd000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2c0b95a000)
> libmpichfort.so.0 => not found
> libmpich.so.0 => not found
> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2c0b940000)
> libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f2c0b8ff000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2c0b73c000)
> libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2c0b51e000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f2c15486000)
>
> Luckily there are only 12 source packages building packages dependening
> on libmpich12, so I could check the age of their builds manually.
>
>
> Is there some tool that can examine buildinfo files (or build logs) to
> find any builds (that are still in sid (or $distro)) that were done with
> a particular bad package installed?
> In this case I would have wanted 'libmpich12 (<< 3.3-1)' as bad version.
Not afaik. There is a getbuildlog script in devscripts, so you could use that
(or pkgkde-getbuildlogs) and grep the logs.
Scheduled the current list, so closing this. Please reopen if you find that
other packages also need a binNMU.
Cheers,
Emilio
--- End Message ---
Reply to: