Bug#1000332: libopenblas64-openmp-dev: CMAKE cannot find OpenBLAS's files

2021-11-21 Thread Juan Jose Garcia Ripoll
Package: libopenblas64-openmp-dev Version: 0.3.13+ds-3 Severity: normal X-Debbugs-Cc: juanjose.garciarip...@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I try to use OpenBLAS in various open

Bug#486376: [Ecls-list] Bug#486376: Bug#486376: ecl: /usr/lib/libecl.so doesn't provide a SONAME

2008-09-10 Thread Juan Jose Garcia-Ripoll
On Wed, Sep 10, 2008 at 12:27 AM, Luca Capello [EMAIL PROTECTED] wrote: I prefer to keep the ECL situation as it is now: Debian ships only one version, which is the latest release [1]. Luca, I think you are thinking too way ahead. Currently, there is no Debian program that depends on an

Bug#486376: [Ecls-list] Bug#486376: Bug#486376: ecl: /usr/lib/libecl.so doesn't provide a SONAME

2008-09-09 Thread Juan Jose Garcia-Ripoll
Last change in CVS ( 2008/09/09 ) - We switch to an Ubuntu-like versioning system, based on $(year).$(month).x where x is 0 for a release or any higher number for a patched version. - In Unix-type systems, ECL now installs with a soname and using versioned directory names, such as

Bug#486376: [Ecls-list] Bug#486376: Bug#486376: ecl: /usr/lib/libecl.so doesn't provide a SONAME

2008-09-09 Thread Juan Jose Garcia-Ripoll
On Tue, Sep 9, 2008 at 11:15 PM, Luca Capello [EMAIL PROTECTED] wrote: On Tue, 09 Sep 2008 21:38:13 +0200, Juan Jose Garcia-Ripoll wrote: Last change in CVS ( 2008/09/09 ) - We switch to an Ubuntu-like versioning system, based on $(year).$(month).x where x is 0 for a release or any

Bug#486376: [Ecls-list] Bug#486376: Bug#486376: ecl: /usr/lib/libecl.so doesn't provide a SONAME

2008-09-07 Thread Juan Jose Garcia-Ripoll
On Sun, Sep 7, 2008 at 2:18 AM, Gabriel Dos Reis [EMAIL PROTECTED] wrote: Well, I really think SONAME's decision belongs to developers, not to package maintainers. Let's say that Debian uses a SONAME of 0.1 while Ubuntu 0.2 [1]: then every effort done with the LSB [2] is lost. This

Bug#486376: [Ecls-list] Bug#486376: Bug#486376: ecl: /usr/lib/libecl.so doesn't provide a SONAME

2008-09-03 Thread Juan Jose Garcia-Ripoll
On Wed, Sep 3, 2008 at 4:12 PM, Luca Capello [EMAIL PROTECTED] wrote: That is not something ECL has to provide. It is more a configuration option that operating systems may provide. Sorry, I'm not a skilled programmed, but I don't understand why this is not ECL task: ECL provides the

Bug#486376: [Ecls-list] Bug#486376: ecl: /usr/lib/libecl.so doesn't provide a SONAME

2008-08-30 Thread Juan Jose Garcia-Ripoll
On Sat, Aug 30, 2008 at 1:07 AM, Luca Capello [EMAIL PROTECTED] wrote: This bug has nothing to do with the rpath issue (now solved [1]). Thus, the problem remains: is there any particular reason for /usr/lib/libecl.so not providing a SONAME? That is not something ECL has to provide. It is more

Bug#495756: [Ecls-list] Bug#495756: ecl has rpath to insecure location (/tmp/buildd/ecl-0.9j-20080306/build/)

2008-08-25 Thread Juan Jose Garcia-Ripoll
On Mon, Aug 25, 2008 at 11:54 PM, Luca Capello [EMAIL PROTECTED] wrote: For the ECL list: this is a 'serious' bug in the Debian BTS [1]. For the reason why rpath is considered harmful by Debian see [2] and [3]. ECL does not use rpath. The guessing of how it works is still in the autoconf

Bug#339318: Bug in fesetenv() [LIBC6.1]

2005-11-15 Thread Juan Jose Garcia Ripoll
Package:libc6.1 Version:2.2.5-11.5 Summary:Under some circumstances, invoking fesetenv() results in a floating point exception being raised. Description: I have a piece of code which may result in underflows. I enclose the code in between fenv_t

Bug#339319: Bug in fesetenv() [LIBC6.1]

2005-11-15 Thread Juan Jose Garcia Ripoll
Package:libc6.1 Version:2.2.5-11.5 Architecture: Linux usf-cf-alpha-linux-1 2.2.20 #2 Wed Mar 20 19:57:28 EST 2002 alpha unknown Summary:Under some circumstances, invoking fesetenv() results in a floating point exception being raised. Description: I