Your message dated Thu, 29 Dec 2022 18:18:27 +0100
with message-id <bcd7f465b1642f977221c4401ddbcf9274a7902e.ca...@debian.org>
and subject line Re: Bug#1026055: lapack breaks openturns autopkgtest:
undefined reference to `ztrsyl3_' (and 3 more)
has caused the Debian Bug report #1026055,
regarding lapack breaks openturns autopkgtest: undefined reference to
`ztrsyl3_' (and 3 more)
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 ow...@bugs.debian.org
immediately.)
--
1026055: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026055
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: lapack, openturns
Control: found -1 lapack/3.11.0-2
Control: found -1 openturns/1.20-5
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update
Dear maintainer(s),
With a recent upload of lapack the autopkgtest of openturns fails in
testing when that autopkgtest is run with the binary packages of lapack
from unstable. It passes when run with only packages from testing. In
tabular form:
pass fail
lapack from testing 3.11.0-2
openturns from testing 1.20-5
all others from testing from testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of lapack to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=lapack
https://ci.debian.net/data/autopkgtest/testing/amd64/o/openturns/29301955/log.gz
/usr/bin/ld: /lib/x86_64-linux-gnu/liblapacke.so.3: undefined reference
to `ztrsyl3_'
/usr/bin/ld: /lib/x86_64-linux-gnu/liblapacke.so.3: undefined reference
to `ctrsyl3_'
/usr/bin/ld: /lib/x86_64-linux-gnu/liblapacke.so.3: undefined reference
to `dtrsyl3_'
/usr/bin/ld: /lib/x86_64-linux-gnu/liblapacke.so.3: undefined reference
to `strsyl3_'
collect2: error: ld returned 1 exit status
autopkgtest [01:16:06]: test cxx-Ceres-test
OpenPGP_signature
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
Le vendredi 16 décembre 2022 à 18:41 +0100, Jochen Sprickerhof a
écrit :
> * Sébastien Villemot <sebast...@debian.org> [2022-12-16 16:26]:
> > In the current system, in which the BLAS and LAPACK implementation are
> > decided through the alternatives system, it’s not possible to solve the
> > problem through versioned provides. Because even if the dependency on
> > the versioned provides is satisfied, this does not prevent another
> > flavour of LAPACK (not satisfying the dependency) to be installed and
> > selected through the alternatives system.
>
> I think those alternatives names would need to be per ABI version (of
> the virtual package) anyhow.
>
> > So indeed the only clean way of solving this issue seems to forbid
> > coinstallability of several BLAS or LAPACK flavours. But the latter is
> > considered as a feature, not as a bug. I agree that using the
> > alternatives system for a shared library is a bit ugly and does not
> > play well with our tooling, but that’s a choice that was made long ago
> > and it also brings some flexibility for the user (it’s easy to switch
> > from one implementation to the other).
>
> Is ease of switching the only reason for using the alternatives system
> here?
The other obvious solution is to use conflicting packages. Having
shared libraries not co-installable may be manageable, but having -dev
packages not co-installable is going to create some trouble.
> Maybe we should rethink this decision as it really does not play well
> with our tooling and you could just as well use apt to switch the
> implementation.
If you think there is a technically superior solution to the statu quo,
you should send a message to debian-science@l.d.o which is the proper
place to discuss such a change.
Also, since atlas 3.10.3-13 has migrated to testing, I’m closing the
present bug.
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀ https://www.debian.org
signature.asc
Description: This is a digitally signed message part
--- End Message ---
