Bug#923607: openblas: FTBFS if CPU is not detected

2019-03-07 Thread Sébastien Villemot
Control: forwarded -1 https://github.com/xianyi/OpenBLAS/issues/2048
Control: tags -1 + upstream
Control: severity -1 important

Le samedi 02 mars 2019 à 21:28 +0100, Santiago Vila a écrit :
> > Still there seems to be an issue with your specific build environment,
> > and of course this is a bug (but maybe not an RC one, since you are the
> > first to report such a build failure after many years). Could you give
> > more details about the hardware you are using?
> 
> I'm currently using Scaleway 1-XS and 1-S instances. On both types of
> instances the package always fail to build. I didn't find a way to
> move the "unbuildability property" to a non-failing machine (for
> example, by taking /proc/cpuinfo in the failing machine and using
> bind-mount on the non-failing machine), so I decided to report it anyway
> without a "recipe to reproduce it" but with an offer to ssh into a failing
> machine instead.

I've tried to fix the issue by myself on the host you provided me
access to, but without success so far. Hence I have forwarded it
upstream.

I am also downgrading the severity, since the FTBFS is specific to a
seemingly small subset of machines (and in particular it never occurred
on buildds).

Best,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: This is a digitally signed message part


Bug#923607: openblas: FTBFS if CPU is not detected

2019-03-02 Thread Santiago Vila
> Still there seems to be an issue with your specific build environment,
> and of course this is a bug (but maybe not an RC one, since you are the
> first to report such a build failure after many years). Could you give
> more details about the hardware you are using?

I'm currently using Scaleway 1-XS and 1-S instances. On both types of
instances the package always fail to build. I didn't find a way to
move the "unbuildability property" to a non-failing machine (for
example, by taking /proc/cpuinfo in the failing machine and using
bind-mount on the non-failing machine), so I decided to report it anyway
without a "recipe to reproduce it" but with an offer to ssh into a failing
machine instead.

Thanks.



Bug#923607: openblas: FTBFS if CPU is not detected

2019-03-02 Thread Sébastien Villemot
Dear Santiago,

Le samedi 02 mars 2019 à 18:11 +, Santiago Vila a écrit :
> Package: src:openblas
> Version: 0.3.5+ds-2
> Severity: serious
> Tags: ftbfs
> 
> I tried to build this package in buster but it failed:

[…]
> make[2]: *** [Makefile.prebuild:66: getarch_2nd] Error 1
> Makefile:135: *** OpenBLAS: Detecting CPU failed. Please set TARGET 
> explicitly, e.g. make TARGET=your_cpu_target. Please read README for the 
> detail..  Stop.
> make[2]: Leaving directory '/<>/openblas-0.3.3+ds'
> make[1]: *** [debian/rules:77: override_dh_auto_build] Error 2
> make[1]: Leaving directory '/<>/openblas-0.3.3+ds'
> make: *** [debian/rules:74: binary-arch] Error 2
> dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
> status 2
> 
> 
> The error message says it all: Please set TARGET explicitly.
> 
> The fact that this package tries to detect the CPU is probably the
> reason the executables built in buildd.debian.org do not work
> everywhere:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743490
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781998
> 
> which in addition to the FTBFS bug, it's also a baseline violation.

As mentioned in the package description, on amd64, arm64 and i386, the
binary contains specialized kernels for many different micro-
architectures, and the selection  of the kernel is done at runtime. So
the design is correct and there is no baseline violation.

Still there seems to be an issue with your specific build environment,
and of course this is a bug (but maybe not an RC one, since you are the
first to report such a build failure after many years). Could you give
more details about the hardware you are using?

Thanks,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: This is a digitally signed message part


Bug#923607: openblas: FTBFS if CPU is not detected

2019-03-02 Thread Santiago Vila
Package: src:openblas
Version: 0.3.5+ds-2
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules binary-arch
dh binary-arch
   dh_update_autotools_config -a
   dh_autoreconf -a
   dh_auto_configure -a
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>/openblas-0.3.3+ds'
/usr/bin/make NO_LAPACKE=1 NO_AFFINITY=1 USE_OPENMP=0 NO_WARMUP=1 
CFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-fdebug-prefix-map=/<>/openblas-0.3.3+ds=. -fstack-protector-strong 
-Wformat -Werror=format-security" FFLAGS="-g -O2 
-fdebug-prefix-map=/<>/openblas-0.3.3+ds=. -fstack-protector-strong" 
COMMON_OPT= FCOMMON_OPT=-frecursive NUM_THREADS=64 DYNAMIC_ARCH=1 
DYNAMIC_OLDER=1
make[2]: Entering directory '/<>/openblas-0.3.3+ds'
getarch_2nd.c: In function 'main':
getarch_2nd.c:12:35: error: 'SGEMM_DEFAULT_UNROLL_M' undeclared (first use in 
this function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
 printf("SGEMM_UNROLL_M=%d\n", SGEMM_DEFAULT_UNROLL_M);
   ^~
   XGEMM_DEFAULT_UNROLL_M
getarch_2nd.c:12:35: note: each undeclared identifier is reported only once for 
each function it appears in
getarch_2nd.c:13:35: error: 'SGEMM_DEFAULT_UNROLL_N' undeclared (first use in 
this function); did you mean 'XGEMM_DEFAULT_UNROLL_N'?
 printf("SGEMM_UNROLL_N=%d\n", SGEMM_DEFAULT_UNROLL_N);
   ^~
   XGEMM_DEFAULT_UNROLL_N
getarch_2nd.c:14:35: error: 'DGEMM_DEFAULT_UNROLL_M' undeclared (first use in 
this function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
 printf("DGEMM_UNROLL_M=%d\n", DGEMM_DEFAULT_UNROLL_M);
   ^~
   XGEMM_DEFAULT_UNROLL_M
getarch_2nd.c:15:35: error: 'DGEMM_DEFAULT_UNROLL_N' undeclared (first use in 
this function); did you mean 'XGEMM_DEFAULT_UNROLL_N'?
 printf("DGEMM_UNROLL_N=%d\n", DGEMM_DEFAULT_UNROLL_N);
   ^~
   XGEMM_DEFAULT_UNROLL_N
getarch_2nd.c:19:35: error: 'CGEMM_DEFAULT_UNROLL_M' undeclared (first use in 
this function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
 printf("CGEMM_UNROLL_M=%d\n", CGEMM_DEFAULT_UNROLL_M);
   ^~
   XGEMM_DEFAULT_UNROLL_M
getarch_2nd.c:20:35: error: 'CGEMM_DEFAULT_UNROLL_N' undeclared (first use in 
this function); did you mean 'XGEMM_DEFAULT_UNROLL_N'?
 printf("CGEMM_UNROLL_N=%d\n", CGEMM_DEFAULT_UNROLL_N);
   ^~
   XGEMM_DEFAULT_UNROLL_N
getarch_2nd.c:21:35: error: 'ZGEMM_DEFAULT_UNROLL_M' undeclared (first use in 
this function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
 printf("ZGEMM_UNROLL_M=%d\n", ZGEMM_DEFAULT_UNROLL_M);
   ^~
   XGEMM_DEFAULT_UNROLL_M
getarch_2nd.c:22:35: error: 'ZGEMM_DEFAULT_UNROLL_N' undeclared (first use in 
this function); did you mean 'XGEMM_DEFAULT_UNROLL_N'?
 printf("ZGEMM_UNROLL_N=%d\n", ZGEMM_DEFAULT_UNROLL_N);
   ^~
   XGEMM_DEFAULT_UNROLL_N
getarch_2nd.c:69:50: error: 'SGEMM_DEFAULT_Q' undeclared (first use in this 
function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
 printf("#define SLOCAL_BUFFER_SIZE\t%ld\n", (SGEMM_DEFAULT_Q * 
SGEMM_DEFAULT_UNROLL_N * 4 * 1 *  sizeof(float)));
  ^~~
  XGEMM_DEFAULT_UNROLL_M
getarch_2nd.c:70:50: error: 'DGEMM_DEFAULT_Q' undeclared (first use in this 
function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
 printf("#define DLOCAL_BUFFER_SIZE\t%ld\n", (DGEMM_DEFAULT_Q * 
DGEMM_DEFAULT_UNROLL_N * 2 * 1 *  sizeof(double)));
  ^~~
  XGEMM_DEFAULT_UNROLL_M
getarch_2nd.c:71:50: error: 'CGEMM_DEFAULT_Q' undeclared (first use in this 
function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
 printf("#define CLOCAL_BUFFER_SIZE\t%ld\n", (CGEMM_DEFAULT_Q * 
CGEMM_DEFAULT_UNROLL_N * 4 * 2 *  sizeof(float)));
  ^~~
  XGEMM_DEFAULT_UNROLL_M
getarch_2nd.c:72:50: error: 'ZGEMM_DEFAULT_Q' undeclared (first use in this 
function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
 printf("#define ZLOCAL_BUFFER_SIZE\t%ld\n", (ZGEMM_DEFAULT_Q * 
ZGEMM_DEFAULT_UNROLL_N * 2 * 2 *  sizeof(double)));
  ^~~