Bug#1068683: zmat: FTBFS: ar: blosc2/blosc/*.o: No such file or directory
Le mardi 09 avril 2024 à 10:14 +0800, Bo YU a écrit : > The package has ftbfs issue but on amd64 and i386, the common issue is > follows: > > ``` > CC obj/conf_91c451f6ae5e059804729dd256611361/static/cover.o > CC obj/conf_91c451f6ae5e059804729dd256611361/static/divsufsort.o > CC obj/conf_91c451f6ae5e059804729dd256611361/static/fastcover.o > CC obj/conf_91c451f6ae5e059804729dd256611361/static/zdict.o > compiling single-threaded static library 1.5.5 > make[4]: Leaving directory > '/<>/src/blosc2/internal-complibs/zstd' > make[3]: Leaving directory '/<>/src/blosc2' > Building ../lib/libzmat.a > ar cr -o ../lib/libzmat.a zmatlib.o miniz/miniz.o easylzma/compress.o > easylzma/decompress.o easylzma/lzma_header.o easylzma/lzip_header.o > easylzma/common_internal.o easylzma/pavlov/LzmaEnc.o > easylzma/pavlov/LzmaDec.o easylzma/pavlov/LzmaLib.o easylzma/pavlov/LzFind.o > easylzma/pavlov/Bra.o easylzma/pavlov/BraIA64.o easylzma/pavlov/Alloc.o > easylzma/pavlov/7zCrc.o blosc2/blosc/*.o > blosc2/internal-complibs/zstd/obj/*/static/*.o > ar: blosc2/blosc/*.o: No such file or directory The problem is actually that zmat tries to compile a file with -msse2, which of course is only available on amd64 and i386. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1067842: transition: octave-9
Package: release.debian.org Severity: normal X-Debbugs-Cc: debian-oct...@lists.debian.org User: release.debian@packages.debian.org Usertags: transition Dear Release Team, Please schedule a transition for the latest major upstream version of Octave, version 9. All the arch:any Octave addons need to be rebuild. Octave 9 has already been uploaded to experimental. A rebuild of all the packages affected by the transition has been performed. Several problems were fixed, and to the best of our knowledge, all packages are ready. We stand ready to upload and NMU as needed if other issues arise. Thanks, Ben file: title = "octave-9"; is_affected = .depends ~ "octave-abi-58" | .depends ~ "octave-abi-59"; is_good = .depends ~ "octave-abi-59"; is_bad = .depends ~ "octave-abi-58"; -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#524073: python-numpy: please split atlas support into an optional package
Control: retitle -1 python3-numpy: please split BLAS/LAPACK support into an optional package On Tue, 14 Apr 2009 10:23:11 -0700 Ondrej Certik wrote: > On Tue, Apr 14, 2009 at 10:09 AM, Neil Williams wrote: > > Package: python-numpy > > Version: 1:1.2.1-1 > > Severity: normal > > > > In #489253, ATLAS support was re-enabled. > > > > In #519233, python-gtk2 was made to depend on python-numpy. > > > > The net result is that something as small and simple as wicd now depends > > on libgfortran and libblas in unstable. > > > > I ran my own systems for some time without python-numpy, it was only that > > one issue in the sodoku game. I don't think that is sufficient justification > > for adding such a huge dependency chain like ATLAS. > > > > I was going to recommend wicd as the wireless network support tool for > > Emdebian Grip but I cannot do that if that means installing fortran! > > > > Making fortran essential for all GUI python support isn't going to help > > developments like openmoko or other embedded / small machine purposes. > > Yes, I agree, that this should be resolved. I always thought you can > install python-numpy without atlas. At least it used to be that way, > if this is not the case, it's a bug to be fixed. Please also note that ATLAS is now obsolete and in the process of being removed from Debian, see this thread: https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org This bug is actually more about BLAS/LAPACK in general than about a specific implementation (ATLAS). I’m therefore changing the title accordingly. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1066361: atlas: FTBFS: probe_comp.c:653:13: error: implicit declaration of function ‘CompIsClang’ [-Werror=implicit-function-declaration]
Le samedi 16 mars 2024 à 17:32 +0500, Andrey Rakhmatullin a écrit : > On Wed, Mar 13, 2024 at 12:35:48PM +0100, Lucas Nussbaum wrote: > > > /<>/build/..//CONFIG/src/probe_comp.c:653:13: error: > > > implicit declaration of function ‘CompIsClang’ > > > [-Werror=implicit-function-declaration] > > > /<>/build/..//CONFIG/src/probe_comp.c:1140:24: error: > > > implicit declaration of function ‘CompIsMinGW’ > > > [-Werror=implicit-function-declaration] > The fix for these is adding > > int CompIsClang(char *comp); > int CompIsMinGW(char *comp); > > to CONFIG/include/atlconf_misc.h (after CompIsGcc). > > I have no idea how to fix the next errors though: > > /<>/build/..//src/testing/ATL_f77gelqf.c: In function > ‘ATL_df77gelqf’: > /<>/build/..//include/atlas_misc.h:127:16: error: implicit > declaration of function ‘dgelqf_’ [-Werror=implicit-function-declaration] > 127 |#define PRE d > |^ > /<>/build/..//include/atlas_misc.h:74:27: note: in definition of > macro ‘my_join’ >74 | #define my_join(pre, nam) pre ## nam > | ^~~ > /<>/build/..//src/testing/ATL_f77gelqf.c:40:21: note: in > expansion of macro ‘Mjoin’ >40 |#define F77GELQF Mjoin(PRE,gelqf_) > | ^ > /<>/build/..//src/testing/ATL_f77gelqf.c:40:27: note: in > expansion of macro ‘PRE’ >40 |#define F77GELQF Mjoin(PRE,gelqf_) > | ^~~ > /<>/build/..//src/testing/ATL_f77gelqf.c:58:4: note: in > expansion of macro ‘F77GELQF’ >58 |F77GELQF(, , A, , tau, work, , ); > |^~~~ > > In file included from /<>/build/..//src/testing/ATL_f77gels.c:30: > /<>/build/..//src/testing/ATL_f77gels.c: In function > ‘ATL_df77gels’: > /<>/build/..//include/atlas_misc.h:127:16: error: implicit > declaration of function ‘dgels_’ [-Werror=implicit-function-declaration] > 127 |#define PRE d > |^ > /<>/build/..//include/atlas_misc.h:74:27: note: in definition of > macro ‘my_join’ >74 | #define my_join(pre, nam) pre ## nam > | ^~~ > /<>/build/..//src/testing/ATL_f77gels.c:39:20: note: in > expansion of macro ‘Mjoin’ >39 |#define F77GELS Mjoin(PRE,gels_) > |^ > /<>/build/..//src/testing/ATL_f77gels.c:39:26: note: in > expansion of macro ‘PRE’ >39 |#define F77GELS Mjoin(PRE,gels_) > | ^~~ > /<>/build/..//src/testing/ATL_f77gels.c:99:4: note: in expansion > of macro ‘F77GELS’ >99 |F77GELS(args); > |^~~ > > > This seems like some autogenerated code with heavy C macro usage. Thanks for the suggested fix. Note that atlas is obsolete scheduled for removal before trixie, see the thread at: https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org So I may fix this issue, but I’d rather have atlas removed sooner. The remaining blockers are there: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=atlas-rm;users=debian-scie...@lists.debian.org -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#902739: RFP: matlab-mode -- major mode for editing Matlab dot-m / .m files
Control: retitle -1 ITP: matlab-mode -- major mode for editing MATLAB .m files Control: owner -1 ! On Sat, 30 Jun 2018 13:57:50 -0400 Nicholas D Steeves wrote: > On Sat, Jun 30, 2018 at 07:55:30AM -0300, David Bremner wrote: > > > > melpa is packaging > > > > https://git.code.sf.net/p/matlab-emacs/src > > > > it seems to more up to date than either of the options you mention > > That link seems to be dead. Do you mean: > > https://github.com/ayonga/matlab-emacs > > ? I intend to package the version in MELPA. Homepage: https://matlab-emacs.sourceforge.net/ Git repository: https://sourceforge.net/p/matlab-emacs/src/ci/master/tree/ It will be maintained under the umbrella of the Debian Emacsen team. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#967941: Bug appeared again
Le jeudi 13 juillet 2023 à 20:32 +0200, fred a écrit : > Still encountering this annoying bug on my testing (trixie) system > (main computer) > > However I am unable to remove the libopenblas0-pthread:amd64 0.3.23+ds- > 2 package without destroying my operating system (too many programs > depend on it) Have you tried replacing libopenblas0-pthread by libopenblas0-serial? -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1061644: octave-dev: The package should include an ld.so.conf fragment pointing to the shared libraries
Le dimanche 28 janvier 2024 à 22:18 +0100, Rafael Laboissière a écrit : > * Antony Donovan [2024-01-27 15:52]: > > > Package: octave-dev > > Version: 7.3.0-2 > > Severity: normal > > Tags: patch > > > > Dear Maintainer, > > > > I installed octave-dev and after building a standalone executable with > > mkoctfile it failed to run. > > > > I realized that what was needed was an ld.so.conf fragment containing > > the directory where the shared libraries were located. > > > > I created that fragment, with the contents > > /usr/lib/x86_64-linux-gnu/octave/7.3.0, named it octave-dev.conf, > > put that file in /etc/ld.so.conf.d, and ran ldconfig. > > > > This fixed the issue of running the standalone octave executable. > > Thank you for your bug report. > > Could you please provide us with a complete example that reproduces > the bug? I suppose that the issue appears with option --link-stand-alone of mkoctfile. I’m not sure that modifying the dynamic linker configuration for the whole system, as suggested by Antony, is the right thing to do, especially for a feature that is seldom used (mkoctfile is primarily used for building .oct and .mex files, not standalone executable). Octave libraries are private on purpose. Another solution is simply to set the rpath in the created ELF executable. I think we should ask upstream about the intended use of the --link- stand-alone option, and about the proper way of dealing with dynamic loading of private Octave libraries in that case. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1061123: suitesparse breaks octave autopkgtest: it hangs
Control: reassign -1 libsuitesparse-dev 1:7.4.0+dfsg-1 Control: forcemerge 1061049 -1 Le jeudi 18 janvier 2024 à 19:48 +0100, Paul Gevers a écrit : > Source: suitesparse, octave > Control: found -1 suitesparse/1:7.5.1+dfsg-1 > Control: found -1 octave/8.4.0-1 > Severity: serious > Tags: sid trixie > User: debian...@lists.debian.org > Usertags: breaks needs-update > > Dear maintainer(s), > > With a recent upload of suitesparse the autopkgtest of octave fails in > testing when that autopkgtest is run with the binary packages of > suitesparse from unstable. It passes when run with only packages from > testing. In tabular form: > > passfail > suitesparsefrom testing1:7.5.1+dfsg-1 > octave from testing8.4.0-1 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. Normally the > test only takes a couple of minutes, now it times out after 2:47 hours. > I'm notifying you already as this is currently also impacting the perl > transition via texinfo. > > Currently this regression is blocking the migration of suitesparse 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? Thanks. This is due to a ABI break in suitesparse. We’re currently discussing the best fix with upstream. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1061018: octave-splines: FTBFS: make: *** [debian/rules:5: binary] Error 134
Control: block -1 by 1061049 Le mardi 16 janvier 2024 à 20:43 +0100, Lucas Nussbaum a écrit : > Source: octave-splines > Version: 1.3.5-2 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240115 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > debian/rules binary > > dh binary --buildsystem=octave > >dh_update_autotools_config -O--buildsystem=octave > >dh_autoreconf -O--buildsystem=octave > >dh_octave_version -O--buildsystem=octave > > Checking the Octave version... ok > >dh_auto_configure -O--buildsystem=octave > >dh_auto_build -O--buildsystem=octave > >dh_auto_test -O--buildsystem=octave > >create-stamp debian/debhelper-build-stamp > >dh_testroot -O--buildsystem=octave > >dh_prep -O--buildsystem=octave > >dh_auto_install --destdir=debian/octave-splines/ -O--buildsystem=octave > > octave --no-gui --no-history --silent --no-init-file --no-window-system > > /usr/share/dh-octave/install-pkg.m > > /<>/debian/octave-splines/usr/share/octave/packages > > /<>/debian/octave-splines/usr/lib/x86_64-linux-gnu/octave/packages > > For information about changes from previous versions of the splines > > package, run 'news splines'. > >dh_octave_check -O--buildsystem=octave > > Checking package... > > Run the unit tests... > > Checking m files ... > > [inst/tps_val_der.m] > > > > > > > /<>/inst/tps_val_der.m > > * shared a,b,x,y,x1,x2,y1,c,dy,dy0 > > a = 2; b = -3; x = ([1:2:10 10.5 11.3])'; y = a*x; > > c = tpaps(x,y,1); > > * assert (a*ones(size(x)), tps_val_der(x,c,x), 1E3*eps); > > [x1 x2] = meshgrid(x, x); > > y1 = a*x1+b*x2; > > c = tpaps([x1(:) x2(:)],y1(:),0.5); > > dy = tps_val_der([x1(:) x2(:)],c,[x1(:) x2(:)]); > > dy0 = tps_val_der([x1(:) x2(:)],c,[x1(:) x2(:)],false); > > * assert (a*ones(size(x1(:))), dy(:, 1), 1E3*eps); > > * assert (b*ones(size(x2(:))), dy(:, 2), 1E3*eps); > > * assert (dy0, dy, 1E3*eps); > > 4 tests, 4 passed, 0 known failure, 0 skipped > > [inst/bin_values.m] > > > > > > > /<>/inst/bin_values.m > > * shared x, y, x_bin, y_bin, w_bin, n_bin > > x = [1; 2; 2; 3; 4]; > > y = [0 0; 1 1; 2 1; 3 4; 5 NaN]; > > [x_bin y_bin w_bin n_bin] = bin_values(x, y); > > * assert (x_bin, [1; 7/3]); > > * assert (y_bin, [0 0; 2 2]); > > * assert (!any(isfinite(w_bin(1, :; > > * assert (w_bin(2, :), [3 1]); > > * assert (n_bin, [1; 3]); > > 5 tests, 5 passed, 0 known failure, 0 skipped > > [inst/csaps_sel.m] > > > > > > > /<>/inst/csaps_sel.m > > * shared x,y,ret,p,sigma2,unc_y > > x = [0:0.01:1]'; y = sin(x); > > [ret,p,sigma2,unc_y] = csaps_sel(x,y,x); > > malloc(): invalid size (unsorted) > > fatal: caught signal Aborted -- stopping myself... > > Aborted > > make: *** [debian/rules:5: binary] Error 134 Thanks. This is a consequence of the ABI break in libcholmod5. Tagging accordingly. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1061017: octave-divand: FTBFS: make: *** [debian/rules:5: binary] Error 134
Control: block -1 by 1061049 Le mardi 16 janvier 2024 à 20:43 +0100, Lucas Nussbaum a écrit : > Source: octave-divand > Version: 1.1.2+dfsg-6 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240115 ftbfs-trixie > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > debian/rules binary > > dh binary --buildsystem=octave > >dh_update_autotools_config -O--buildsystem=octave > >dh_autoreconf -O--buildsystem=octave > >dh_octave_version -O--buildsystem=octave > > Checking the Octave version... ok > >dh_auto_configure -O--buildsystem=octave > >dh_auto_build -O--buildsystem=octave > >dh_auto_test -O--buildsystem=octave > >create-stamp debian/debhelper-build-stamp > >dh_testroot -O--buildsystem=octave > >dh_prep -O--buildsystem=octave > >dh_auto_install --destdir=debian/octave-divand/ -O--buildsystem=octave > > octave --no-gui --no-history --silent --no-init-file --no-window-system > > /usr/share/dh-octave/install-pkg.m > > /<>/octave-divand-1.1.2\+dfsg/debian/octave-divand/usr/share/octave/packages > > > > /<>/octave-divand-1.1.2\+dfsg/debian/octave-divand/usr/lib/x86_64-linux-gnu/octave/packages > > For information about changes from previous versions of the divand package, > > run 'news divand'. > >dh_octave_check -O--buildsystem=octave > > Checking package... > > Run the unit tests... > > Checking m files ... > > [inst/statevector_init.m] > > > > > > > /<>/inst/statevector_init.m > > * test > > mask = rand(10,10) > .5; > > mask_u = rand(9,10) > .5; > > mask_v = rand(10,9) > .5; > > sv = statevector_init(mask,mask_u,mask_v); > > var = rand(10,10); > > var(mask==0) = 0; > > var_u = rand(9,10); > > var_u(mask_u==0) = 0; > > var(mask==0) = 0; > > var_v = rand(10,9); > > var_v(mask_v==0) = 0; > > [E] = statevector_pack(sv,var,var_u,var_v); > > [Ezeta2,Eu2,Ev2] = statevector_unpack(sv,E); > > assert(Ezeta2,var) > > assert(Eu2,var_u) > > assert(Ev2,var_v) > > 1 test, 1 passed, 0 known failure, 0 skipped > > Checking C++ files ... > > Run tests in debian/check.m > > [test_divand] > > run test_interp_1d: (max difference=2.77556e-16) [42m OK [0m > > run test_interp_2d: (max difference=2.22045e-16) [42m OK [0m > > run test_interp_regular: (max difference=2.22045e-16) [42m OK [0m > > run test_sparse_diff: (max difference=0) [42m OK [0m > > run test_1dvar: malloc(): invalid size (unsorted) > > fatal: caught signal Aborted -- stopping myself... > > Aborted > > make: *** [debian/rules:5: binary] Error 134 Thanks. This is a consequence of the ABI break in libcholmod5. Tagging accordingly. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1061049: libsuitesparse-dev: libsuitesparse-dev 7.4.0 has an ABI break in libcholmod5 without bumping to "libcholmod6"
Hi Dima,
Le mardi 16 janvier 2024 à 15:06 -0800, Dima Kogan a écrit :
> Hi. I'm chasing down
>
> http://bugs.debian.org/1060986
>
> The problem is that mrcal uses libdogleg, which contains
>
> typedef struct
> {
> cholmod_common common;
>
> } dogleg_solverContext_t;
>
> The existing "libdogleg2" package was built against libsuitesparse-dev
> 7.3, so it must be linked with packages that use that ABI. But in
> suitesparse 7.4 the cholmod_common structure has a new member at the
> end:
>
> FILE *blas_dump ; // only used if CHOLMOD is compiled with -DBLAS_DUMP
>
> This is in CHOLMOD/Include/cholmod.h
>
> This extra member changes sizeof(cholmod_common), which changes the ABI,
> causing the crash. One way to fix this is to bump the SONAME of
> libcholmod.
I was indeed suspecting an ABI break in suitesparse, after having
noticed unexpected autopkgtest failures.
Thanks for investigating and finding the cause of the problem, you
saved me a lot of time!
I’ll report this upstream and fix it properly in Debian.
Best wishes,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
signature.asc
Description: This is a digitally signed message part
Bug#1056673: [Help] Re: build-depends on atlas, which is obsolete and scheduled for removal
Control: tags -1 + patch Hi Andreas, Le jeudi 11 janvier 2024 à 17:52 +0100, Andreas Tille a écrit : > Control: tags -1 help > > Hi Sébastien, > > I tried my luck in Git[1] but this is obviously not sufficient to port > to LAPACKE[2]. I'd be really happy if you could spent some of your > valuable time on this issue as you managed with emmax for intance. I have made a merge request that fixes the build against LAPACKE: https://salsa.debian.org/med-team/ghmm/-/merge_requests/1 Note that I verified that it builds correctly, but not that it delivers correct results at runtime. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1056680: closed by Debian FTP Masters (reply to Andreas Tille ) (Bug#1056680: fixed in odin 2.0.5-4)
Le jeudi 11 janvier 2024 à 17:39 +, Debian Bug Tracking System a écrit : > This is an automatic notification regarding your Bug report > which was filed against the src:odin package: > > #1056680: (build-)depends on atlas, which is obsolete and scheduled for > removal > > It has been closed by Debian FTP Masters > (reply to Andreas Tille ). Thanks for fixing this bug. Note that libatlas-base-dev is still listed as an alternative dependency of odin. This does not prevent the removal of src:atlas, so I’m not reopening this bug, but you might still want to fix this. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#988164: rdiff-backup: obsolete conffile not removed
Le vendredi 12 janvier 2024 à 15:06 -0800, Otto Kekäläinen a écrit : > Thanks Sebastien for bringing this up. Would you like to file a MR at > https://salsa.debian.org/python-team/packages/rdiff-backup/-/merge_requests > to get this fixed? Done in: https://salsa.debian.org/python-team/packages/rdiff-backup/-/merge_requests/3 -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1060249: mrpt FTBFS with libsuitesparse-dev 1:7.4.0+dfsg-2
Control: reassign -1 libsuitesparse-dev 1:7.4.0+dfsg-2 Control: affects -1 src:mrpt Le lundi 08 janvier 2024 à 11:14 +0200, Adrian Bunk a écrit : > Source: mrpt > Version: 1:2.11.3+ds-1 > Severity: serious > Tags: ftbfs > X-Debbugs-Cc: Debian Science Team > , Sébastien Villemot > > Control: affects -1 libsuitesparse-dev > > https://buildd.debian.org/status/logs.php?pkg=mrpt=1%3A2.11.3%2Bds-1%2Bb2 > > ... > /<>/libs/math/include/mrpt/math/CSparseMatrix.h:23:10: fatal > error: cs.h: No such file or directory >23 | #include "cs.h" > | ^~ > compilation terminated. > ... > > > This is likely related to the following change in libsuitesparse-dev: > /usr/include/suitesparse/cs.h -> /usr/include/suitesparse/suitesparse/cs.h This change of location is unintended. I am going to fix it in suitesparse. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1056687: marked as pending in scikit-misc
Hi Diane, Please note that libopenblas-dev is *not* the replacement of libatlas- base-dev. Because it is not available on all architectures, and thus your package will fail to build on some archs. The right replacement is "libblas-dev | libblas.so". Best, Le dimanche 31 décembre 2023 à 17:41 +, Diane Trout a écrit : > Control: tag -1 pending > > Hello, > > Bug #1056687 in scikit-misc reported by you has been fixed in the > Git repository and is awaiting an upload. You can see the commit > message below and you can check the diff of the fix at: > > https://salsa.debian.org/python-team/packages/scikit-misc/-/commit/c165c7ddffb8d856af61f53fe0dc620f6aed3dcc > > > Remove libatlas-base-dev from build-depends (Closes: #1056687) > > Already added the replacement libopenblas-dev > > > (this message was generated automatically) -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1056687: closed by Debian FTP Masters (reply to Diane Trout ) (Bug#1056687: fixed in scikit-misc 0.3.1+dfsg-1)
Le vendredi 15 décembre 2023 à 08:09 +0100, Sébastien Villemot a écrit : > Control: reopen -1 > > Le vendredi 15 décembre 2023 à 00:27 +, Debian Bug Tracking System > a écrit : > > This is an automatic notification regarding your Bug report > > which was filed against the src:scikit-misc package: > > > > #1056687: (build-)depends on atlas, which is obsolete and scheduled for > > removal > > > > It has been closed by Debian FTP Masters > > (reply to Diane Trout ). > > I’m reopening this bug. > > The build dependency on libatlas-base-dev is still there in version > 0.3.1+dfsg-1. Also note that since 0.3.1+dfsg-1 incorrectly added a build dependency on libopenblas-dev, the package no longer builds on armel, and thus cannot migrate to testing. The right fix is to drop the Build-Depends on both libatlas-base-dev and libopenblas-dev, and to instead Build-Depend on libblas-dev. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1056671: closed by Debian FTP Masters (reply to Andreas Tille ) (Bug#1056671: fixed in emmax 0~beta.20100307-4)
Thanks Andreas for uploading a fixed package. Unfortunately the updated package won’t build on some architectures (notably armel), because you put libopenblas-dev as a first alternative in Build-Depends, and libopenblas-dev is not available on all archs. One should put libblas-dev as the first alternative. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1056681: build-depends on atlas, which is obsolete and scheduled for removal
Control: tags -1 + patch Hi Andreas, Le mercredi 29 novembre 2023 à 11:53 +0100, Andreas Tille a écrit : > Control: tags -1 help > > [Ritika Ramani in CC to inform that Debian tries to get rid of Atlas > which also affects phast. see https://bugs.debian.org/1056681] > > Hi, > > I tried to replace clapack by LAPACKE. Unfortunately this is not a > drop-in replacement. As you can see in the raw(! normal log is to > long!) build log on Salsa[1] when seeking for the string > too few arguments to function > you see > > ... > phast_eigen.c: In function 'mat_diagonalize': > phast_eigen.c:62:3: error: too few arguments to function 'dgeev_' >62 | dgeev_(, , , tmp, , wr, wi, vl, > | ^~ > In file included from /usr/include/lapack.h:11, > from > /builds/med-team/phast/debian/output/source_dir/src/../include/phast/external_libs.h:43, > from > /builds/med-team/phast/debian/output/source_dir/src/../include/phast/vector.h:19, > from > /builds/med-team/phast/debian/output/source_dir/src/../include/phast/matrix.h:18, > from > /builds/med-team/phast/debian/output/source_dir/src/../include/phast/eigen.h:18, > from phast_eigen.c:18: > /usr/include/lapack.h:1828:6: note: declared here > 1828 | void LAPACK_dgeev_base( > | ^ > phast_eigen.c: In function 'mat_eigenvals': > phast_eigen.c:199:3: error: too few arguments to function 'dgeev_' > 199 | dgeev_(, , , tmp, , wr, wi, NULL, > | ^~ > ... Actually we had already completed the migration away from the old CLAPACK in clapack.patch. Only a minor cleanup was still needed to remove ATLAS. I opened a merge request that seems to do the job: https://salsa.debian.org/med-team/phast/-/merge_requests/1 Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1056671: Help for emmax needed (Was: Removing ATLAS?)
Control: tags -1 + patch
Hi Andreas,
Le mercredi 29 novembre 2023 à 10:06 +0100, Andreas Tille a écrit :
> Control: tags -1 help
>
> Am Fri, Jul 14, 2023 at 01:40:22AM +0200 schrieb Sébastien Villemot:
> > Le lundi 10 juillet 2023 à 22:01 +0200, Andreas Tille a écrit :
> > > I've checked my responsibility for the dependencies and stumbled about
> > > emmax
> > >
> > >
> > > emmax.c:10:10: fatal error: clapack.h: No such file or directory
> > >10 | #include
> > > | ^~~
> > > compilation terminated.
> > > ...
> >
> > clapack.h is apparently an early attempt at providing a C interface to
> > some LAPACK functions (which are in Fortran). It indeed looks ATLAS-
> > specific.
> >
> > The modern solution for that problem is to use LAPACKE (note the final
> > “E”), which is provided by liblapacke-dev. It is a standardized and
> > maintained C interface to all LAPACK routines.
> >
> > I guess it should be feasible to adapt emmax to make it work with
> > LAPACKE.
>
> I tried to do so in Salsa. Unfortunately LAPACKE is not a drop in
> replacement and I'm lacking the necessary knowledge about all these
> LAPACK implementations. For instance I have no idea how to fix the
> error you can see in Salsa CI[1] which has
>
> ...
> emmax.c: In function 'dsyevd':
> emmax.c:1633:17: error: conflicting types for 'dsyevd_'; have 'void(char *,
> char *, int *, double *, int *, double *, double *, int *, int *, int *, int
> *)'
> 1633 | extern void dsyevd_ (char *JOBZp, char *UPLOp, int *Np,
> | ^~~
> In file included from /usr/include/lapack.h:11,
> from emmax.c:10:
> /usr/include/lapack.h:17096:6: note: previous declaration of 'dsyevd_' with
> type 'void(const char *, const char *, const int32_t *, double *, const
> int32_t *, double *, double *, const int32_t *, int32_t *, const int32_t *,
> int32_t *, size_t, size_t)' {aka 'void(const char *, const char *, const int
> *, double *, const int *, double *, double *, const int *, int *, const int
> *, int *, long unsigned int, long unsigned int)'}
> 17096 | void LAPACK_dsyevd_base(
> | ^~
> emmax.c: In function 'dsyevr':
> emmax.c:1652:17: error: conflicting types for 'dsyevr_'; have 'void(char *,
> char *, char *, int *, double *, int *, double *, double *, int *, int *,
> double *, int *, double *, double *, int *, int *, double *, int *, int *,
> int *, int *)'
> 1652 | extern void dsyevr_ (char *JOBZp, char *RANGEp, char *UPLOp, int
> *Np,
> | ^~~
>
> Looking at the last line of this snippet (line 901 in the linked CI
> log[1]) the parameter char *RANGEp is not part of the declaration of
> LAPACK_dsyevd_base given in line 17096 of /usr/include/lapack.h.
>
> I admit this is hard to solve for me and I would love if someone
> with some knowledge of LAPACK could provide some patch. A similar
> issue exists for dgetrf.
>
> Any help would be appreciated.
I opened a merge request that completes the migration away from ATLAS:
https://salsa.debian.org/med-team/emmax/-/merge_requests/1
Best,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
signature.asc
Description: This is a digitally signed message part
Bug#1057591: octave-vibes: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...
Le jeudi 21 décembre 2023 à 08:49 +0100, Rafael Laboissière a écrit :
> * Santiago Vila [2023-12-20 22:03]:
>
> > El 20/12/23 a las 21:08, Rafael Laboissière escribió:
> > > > HOME := $(shell mktemp -d)
> > > >
> > > > so that the same directory is never used twice between consecutive
> > > > builds.
> > >
> > > Yes, this is a much better solution. Thanks for the suggestion. I am
> > > just wondering: is there a simple way to delete the temporary
> > > directory after he build is finished ?
> >
> > I don't know, but most people build packages in temporary/disposable
> > chroots,
> > so if the package just writes a few files which are also small, it's not
> > something for which I would worry too much.
>
> Yes, it not really a worrisome issue. However, I have just noticed that
> the solution that you proposed with mktemp is a little bit intrusive.
> Indeed, a new temporary directory is created at each invocation of
> debain/rules, such that I end up with five /tmp/tmp.* directories after
> package building, with only the last one being actually used. I will try
> another approach, probably by changing the dh_octave_check script, which
> is the one that eventually needs a writable $HOME directory.
Note that within the context of a shell script, the following ensures
that the directory is automatically deleted upon exit:
tmpdir=$(mktemp -d)
cleanup ()
{
rm -rf "${tmpdir}"
}
trap cleanup EXIT
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
signature.asc
Description: This is a digitally signed message part
Bug#1056687: closed by Debian FTP Masters (reply to Diane Trout ) (Bug#1056687: fixed in scikit-misc 0.3.1+dfsg-1)
Control: reopen -1 Le vendredi 15 décembre 2023 à 00:27 +, Debian Bug Tracking System a écrit : > This is an automatic notification regarding your Bug report > which was filed against the src:scikit-misc package: > > #1056687: (build-)depends on atlas, which is obsolete and scheduled for > removal > > It has been closed by Debian FTP Masters > (reply to Diane Trout ). I’m reopening this bug. The build dependency on libatlas-base-dev is still there in version 0.3.1+dfsg-1. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1055600: transition: suitesparse-7.3
Le vendredi 17 novembre 2023 à 07:43 +0100, Sebastian Ramacher a écrit : > On 2023-11-08 18:00:20 +0100, Sébastien Villemot wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > Control: forwarded -1 > > https://release.debian.org/transitions/html/auto-suitesparse.html > > Please schedule a transition for suitesparse 7.3, which currently sits in > > experimental. > > > > One the shared libraries got a SOVERSION bump (libcholmod4 → libcholmod5). > > The > > ABI change is minor and I’m therefore fairly confident that there won’t be > > any > > issue. > > Please go ahead. The transition is mostly complete. The only remaining issue is an autopkgtest failure of octave in testing, reported as #1056392. I’ve argued there that this issue only affects partial upgrades, and that I’m not sure how to fix it (if fixing is needed at all). Please advise. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1056694: depends on atlas, which is obsolete and scheduled for removal
Source: python-escript
Version: 5.6-5
Severity: normal
Tags: sid trixie
User: debian-scie...@lists.debian.org
Usertags: atlas-rm
Dear Maintainer,
python3-escript and python3-escript-mpi both depend (only on armel) on
libatlas3-base, which is produced by the source package atlas. At this stage I
admit I don’t really understand where that dependency comes from.
atlas is obsolete and scheduled to be removed from Debian, ideally by the
trixie release. See the following thread on the Debian Science list for more
details:
https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org
As a consequence, please drop any (build-)dependency on atlas.
This should normally be straightforward to achieve, by simply replacing atlas
with another BLAS (and possibly also LAPACK) implementation.
Ideally, packages should Build-Depend on the Netlib reference implementation
(libblas-dev, and liblapack-dev where required), and not enforce anything in
the Depends field of binary packages (dpkg-shlibdeps will automatically add the
appropriate "libblas3 | libblas.so.3" entry to ${shlibs:Depends}).
Alternative implementations may be given in Build-Depends for the ease
of users making local builds with an optimized implementation installed,
but the generic reference implementation should be placed first to be
used by buildds. The simplest example is
Build-Depends: libblas-dev | libblas.so,
liblapack-dev | liblapack.so
where specific optimized implementations may provide the
libblas.so/liblapack.so pseudo-package.
Similarly, if one wants to encourage users to install an optimized
implementation at runtime, then one can add
Recommends: libopenblas0 | libblis4
in binary packages.
Also note that if your package needs libcblas (which is currently only provided
by libatlas-base-dev), then the solution is to modify the build system so that
it rather uses libblas (because, under Debian, the latter already incorporates
the symbols provided by libcblas).
Thanks for your work,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
Bug#1056693: depends on atlas, which is obsolete and scheduled for removal
Package: python3-nipy-lib
Version: 0.5.0-8
Severity: normal
Tags: sid trixie
User: debian-scie...@lists.debian.org
Usertags: atlas-rm
Dear Maintainer,
python3-nipy-lib depends (only on armel) on libatlas3-base, which is produced
by the source package atlas. At this stage I admit I don’t really understand
where that dependency comes from.
atlas is obsolete and scheduled to be removed from Debian, ideally by the
trixie release. See the following thread on the Debian Science list for more
details:
https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org
As a consequence, please drop any (build-)dependency on atlas.
This should normally be straightforward to achieve, by simply replacing atlas
with another BLAS (and possibly also LAPACK) implementation.
Ideally, packages should Build-Depend on the Netlib reference implementation
(libblas-dev, and liblapack-dev where required), and not enforce anything in
the Depends field of binary packages (dpkg-shlibdeps will automatically add the
appropriate "libblas3 | libblas.so.3" entry to ${shlibs:Depends}).
Alternative implementations may be given in Build-Depends for the ease
of users making local builds with an optimized implementation installed,
but the generic reference implementation should be placed first to be
used by buildds. The simplest example is
Build-Depends: libblas-dev | libblas.so,
liblapack-dev | liblapack.so
where specific optimized implementations may provide the
libblas.so/liblapack.so pseudo-package.
Similarly, if one wants to encourage users to install an optimized
implementation at runtime, then one can add
Recommends: libopenblas0 | libblis4
in binary packages.
Also note that if your package needs libcblas (which is currently only provided
by libatlas-base-dev), then the solution is to modify the build system so that
it rather uses libblas (because, under Debian, the latter already incorporates
the symbols provided by libcblas).
Thanks for your work,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
Bug#1056688: (build-)depends on atlas, which is obsolete and scheduled for removal
Source: source-extractor
Version: 2.28.0+ds-1
Severity: normal
Tags: sid trixie
User: debian-scie...@lists.debian.org
Usertags: atlas-rm
Dear Maintainer,
source-extractor build-depends on libatlas-base-dev and depends on
libatlas3-base, which are produced by the source package atlas.
atlas is obsolete and scheduled to be removed from Debian, ideally by the
trixie release. See the following thread on the Debian Science list for more
details:
https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org
As a consequence, please drop any (build-)dependency on atlas.
This should normally be straightforward to achieve, by simply replacing atlas
with another BLAS (and possibly also LAPACK) implementation.
Ideally, packages should Build-Depend on the Netlib reference implementation
(libblas-dev, and liblapack-dev where required), and not enforce anything in
the Depends field of binary packages (dpkg-shlibdeps will automatically add the
appropriate "libblas3 | libblas.so.3" entry to ${shlibs:Depends}).
Alternative implementations may be given in Build-Depends for the ease
of users making local builds with an optimized implementation installed,
but the generic reference implementation should be placed first to be
used by buildds. The simplest example is
Build-Depends: libblas-dev | libblas.so,
liblapack-dev | liblapack.so
where specific optimized implementations may provide the
libblas.so/liblapack.so pseudo-package.
Similarly, if one wants to encourage users to install an optimized
implementation at runtime, then one can add
Recommends: libopenblas0 | libblis4
in binary packages.
Also note that if your package needs libcblas (which is currently only provided
by libatlas-base-dev), then the solution is to modify the build system so that
it rather uses libblas (because, under Debian, the latter already incorporates
the symbols provided by libcblas).
Thanks for your work,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
Bug#1056689: build-depends on atlas, which is obsolete and scheduled for removal
Source: theli
Version: 3.1.4-1
Severity: normal
Tags: sid trixie
User: debian-scie...@lists.debian.org
Usertags: atlas-rm
Dear Maintainer,
theli build-depends on libatlas-base-dev, which is produced by the source
package atlas.
atlas is obsolete and scheduled to be removed from Debian, ideally by the
trixie release. See the following thread on the Debian Science list for more
details:
https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org
As a consequence, please drop any (build-)dependency on atlas.
This should normally be straightforward to achieve, by simply replacing atlas
with another BLAS (and possibly also LAPACK) implementation.
Ideally, packages should Build-Depend on the Netlib reference implementation
(libblas-dev, and liblapack-dev where required), and not enforce anything in
the Depends field of binary packages (dpkg-shlibdeps will automatically add the
appropriate "libblas3 | libblas.so.3" entry to ${shlibs:Depends}).
Alternative implementations may be given in Build-Depends for the ease
of users making local builds with an optimized implementation installed,
but the generic reference implementation should be placed first to be
used by buildds. The simplest example is
Build-Depends: libblas-dev | libblas.so,
liblapack-dev | liblapack.so
where specific optimized implementations may provide the
libblas.so/liblapack.so pseudo-package.
Similarly, if one wants to encourage users to install an optimized
implementation at runtime, then one can add
Recommends: libopenblas0 | libblis4
in binary packages.
Also note that if your package needs libcblas (which is currently only provided
by libatlas-base-dev), then the solution is to modify the build system so that
it rather uses libblas (because, under Debian, the latter already incorporates
the symbols provided by libcblas).
Thanks for your work,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
Bug#1056687: (build-)depends on atlas, which is obsolete and scheduled for removal
Source: scikit-misc
Version: 0.1.4+dfsg-1
Severity: normal
Tags: sid trixie
User: debian-scie...@lists.debian.org
Usertags: atlas-rm
Dear Maintainer,
scikit-misc build-depends on libatlas-base-dev and python3-skmisc depends on
libatlas3-base, which are produced by the source package atlas.
atlas is obsolete and scheduled to be removed from Debian, ideally by the
trixie release. See the following thread on the Debian Science list for more
details:
https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org
As a consequence, please drop any (build-)dependency on atlas.
This should normally be straightforward to achieve, by simply replacing atlas
with another BLAS (and possibly also LAPACK) implementation.
Ideally, packages should Build-Depend on the Netlib reference implementation
(libblas-dev, and liblapack-dev where required), and not enforce anything in
the Depends field of binary packages (dpkg-shlibdeps will automatically add the
appropriate "libblas3 | libblas.so.3" entry to ${shlibs:Depends}).
Alternative implementations may be given in Build-Depends for the ease
of users making local builds with an optimized implementation installed,
but the generic reference implementation should be placed first to be
used by buildds. The simplest example is
Build-Depends: libblas-dev | libblas.so,
liblapack-dev | liblapack.so
where specific optimized implementations may provide the
libblas.so/liblapack.so pseudo-package.
Similarly, if one wants to encourage users to install an optimized
implementation at runtime, then one can add
Recommends: libopenblas0 | libblis4
in binary packages.
Also note that if your package needs libcblas (which is currently only provided
by libatlas-base-dev), then the solution is to modify the build system so that
it rather uses libblas (because, under Debian, the latter already incorporates
the symbols provided by libcblas).
Thanks for your work,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
Bug#1056686: (build-)depends on atlas, which is obsolete and scheduled for removal
Source: scamp
Version: 2.10.0-2
Severity: normal
Tags: sid trixie
User: debian-scie...@lists.debian.org
Usertags: atlas-rm
Dear Maintainer,
scamp build-depends on libatlas-base-dev and depends on libatlas3-base, which
arp produced by the source package atlas.
atlas is obsolete and scheduled to be removed from Debian, ideally by the
trixie release. See the following thread on the Debian Science list for more
details:
https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org
As a consequence, please drop any (build-)dependency on atlas.
This should normally be straightforward to achieve, by simply replacing atlas
with another BLAS (and possibly also LAPACK) implementation.
Ideally, packages should Build-Depend on the Netlib reference implementation
(libblas-dev, and liblapack-dev where required), and not enforce anything in
the Depends field of binary packages (dpkg-shlibdeps will automatically add the
appropriate "libblas3 | libblas.so.3" entry to ${shlibs:Depends}).
Alternative implementations may be given in Build-Depends for the ease
of users making local builds with an optimized implementation installed,
but the generic reference implementation should be placed first to be
used by buildds. The simplest example is
Build-Depends: libblas-dev | libblas.so,
liblapack-dev | liblapack.so
where specific optimized implementations may provide the
libblas.so/liblapack.so pseudo-package.
Similarly, if one wants to encourage users to install an optimized
implementation at runtime, then one can add
Recommends: libopenblas0 | libblis4
in binary packages.
Also note that if your package needs libcblas (which is currently only provided
by libatlas-base-dev), then the solution is to modify the build system so that
it rather uses libblas (because, under Debian, the latter already incorporates
the symbols provided by libcblas).
Thanks for your work,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
Bug#1056685: (build-)depends on atlas, which is obsolete and scheduled for removal
Source: qm-dsp
Version: 1.7.1-6
Severity: normal
Tags: sid trixie
User: debian-scie...@lists.debian.org
Usertags: atlas-rm
Dear Maintainer,
qm-dsp build-depends on libatlas-base-dev and libqm-dsp0 depends on
libatlas3-base, which are produced by the source package atlas.
atlas is obsolete and scheduled to be removed from Debian, ideally by the
trixie release. See the following thread on the Debian Science list for more
details:
https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org
As a consequence, please drop any (build-)dependency on atlas.
This should normally be straightforward to achieve, by simply replacing atlas
with another BLAS (and possibly also LAPACK) implementation.
Ideally, packages should Build-Depend on the Netlib reference implementation
(libblas-dev, and liblapack-dev where required), and not enforce anything in
the Depends field of binary packages (dpkg-shlibdeps will automatically add the
appropriate "libblas3 | libblas.so.3" entry to ${shlibs:Depends}).
Alternative implementations may be given in Build-Depends for the ease
of users making local builds with an optimized implementation installed,
but the generic reference implementation should be placed first to be
used by buildds. The simplest example is
Build-Depends: libblas-dev | libblas.so,
liblapack-dev | liblapack.so
where specific optimized implementations may provide the
libblas.so/liblapack.so pseudo-package.
Similarly, if one wants to encourage users to install an optimized
implementation at runtime, then one can add
Recommends: libopenblas0 | libblis4
in binary packages.
Also note that if your package needs libcblas (which is currently only provided
by libatlas-base-dev), then the solution is to modify the build system so that
it rather uses libblas (because, under Debian, the latter already incorporates
the symbols provided by libcblas).
Thanks for your work,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
Bug#1056684: (build-)depends on atlas, which is obsolete and scheduled for removal
Source: psfex
Version: 3.24.2-1
Severity: normal
Tags: sid trixie
User: debian-scie...@lists.debian.org
Usertags: atlas-rm
Dear Maintainer,
psfex build-depends on libatlas-base-dev and depends on libatlas3-base, which
are produced by the source package atlas.
atlas is obsolete and scheduled to be removed from Debian, ideally by the
trixie release. See the following thread on the Debian Science list for more
details:
https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org
As a consequence, please drop any (build-)dependency on atlas.
This should normally be straightforward to achieve, by simply replacing atlas
with another BLAS (and possibly also LAPACK) implementation.
Ideally, packages should Build-Depend on the Netlib reference implementation
(libblas-dev, and liblapack-dev where required), and not enforce anything in
the Depends field of binary packages (dpkg-shlibdeps will automatically add the
appropriate "libblas3 | libblas.so.3" entry to ${shlibs:Depends}).
Alternative implementations may be given in Build-Depends for the ease
of users making local builds with an optimized implementation installed,
but the generic reference implementation should be placed first to be
used by buildds. The simplest example is
Build-Depends: libblas-dev | libblas.so,
liblapack-dev | liblapack.so
where specific optimized implementations may provide the
libblas.so/liblapack.so pseudo-package.
Similarly, if one wants to encourage users to install an optimized
implementation at runtime, then one can add
Recommends: libopenblas0 | libblis4
in binary packages.
Also note that if your package needs libcblas (which is currently only provided
by libatlas-base-dev), then the solution is to modify the build system so that
it rather uses libblas (because, under Debian, the latter already incorporates
the symbols provided by libcblas).
Thanks for your work,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
Bug#1056683: build-depends on atlas, which is obsolete and scheduled for removal
Source: plink2
Version: 2.00~a3.5-220809+dfsg-1
Severity: normal
Tags: sid trixie
User: debian-scie...@lists.debian.org
Usertags: atlas-rm
Dear Maintainer,
plink2 build-depends on libatlas-base-dev, which is produced by the source
package atlas.
atlas is obsolete and scheduled to be removed from Debian, ideally by the
trixie release. See the following thread on the Debian Science list for more
details:
https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org
As a consequence, please drop any (build-)dependency on atlas.
This should normally be straightforward to achieve, by simply replacing atlas
with another BLAS (and possibly also LAPACK) implementation.
Ideally, packages should Build-Depend on the Netlib reference implementation
(libblas-dev, and liblapack-dev where required), and not enforce anything in
the Depends field of binary packages (dpkg-shlibdeps will automatically add the
appropriate "libblas3 | libblas.so.3" entry to ${shlibs:Depends}).
Alternative implementations may be given in Build-Depends for the ease
of users making local builds with an optimized implementation installed,
but the generic reference implementation should be placed first to be
used by buildds. The simplest example is
Build-Depends: libblas-dev | libblas.so,
liblapack-dev | liblapack.so
where specific optimized implementations may provide the
libblas.so/liblapack.so pseudo-package.
Similarly, if one wants to encourage users to install an optimized
implementation at runtime, then one can add
Recommends: libopenblas0 | libblis4
in binary packages.
Also note that if your package needs libcblas (which is currently only provided
by libatlas-base-dev), then the solution is to modify the build system so that
it rather uses libblas (because, under Debian, the latter already incorporates
the symbols provided by libcblas).
Thanks for your work,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
Bug#1056682: build-depends on atlas, which is obsolete and scheduled for removal
Source: plink1.9
Version: 1.90~b6.26-220402-1
Severity: normal
Tags: sid trixie
User: debian-scie...@lists.debian.org
Usertags: atlas-rm
Dear Maintainer,
plink1.9 build-depends on libatlas-base-dev, which is produced by the source
package atlas.
atlas is obsolete and scheduled to be removed from Debian, ideally by the
trixie release. See the following thread on the Debian Science list for more
details:
https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org
As a consequence, please drop any (build-)dependency on atlas.
This should normally be straightforward to achieve, by simply replacing atlas
with another BLAS (and possibly also LAPACK) implementation.
Ideally, packages should Build-Depend on the Netlib reference implementation
(libblas-dev, and liblapack-dev where required), and not enforce anything in
the Depends field of binary packages (dpkg-shlibdeps will automatically add the
appropriate "libblas3 | libblas.so.3" entry to ${shlibs:Depends}).
Alternative implementations may be given in Build-Depends for the ease
of users making local builds with an optimized implementation installed,
but the generic reference implementation should be placed first to be
used by buildds. The simplest example is
Build-Depends: libblas-dev | libblas.so,
liblapack-dev | liblapack.so
where specific optimized implementations may provide the
libblas.so/liblapack.so pseudo-package.
Similarly, if one wants to encourage users to install an optimized
implementation at runtime, then one can add
Recommends: libopenblas0 | libblis4
in binary packages.
Also note that if your package needs libcblas (which is currently only provided
by libatlas-base-dev), then the solution is to modify the build system so that
it rather uses libblas (because, under Debian, the latter already incorporates
the symbols provided by libcblas).
Thanks for your work,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
Bug#1056681: build-depends on atlas, which is obsolete and scheduled for removal
Source: phast
Version: 1.6+dfsg-3
Severity: normal
Tags: sid trixie
User: debian-scie...@lists.debian.org
Usertags: atlas-rm
Dear Maintainer,
phast build-depends on libatlas-base-dev, which is produced by the source
package atlas.
atlas is obsolete and scheduled to be removed from Debian, ideally by the
trixie release. See the following thread on the Debian Science list for more
details:
https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org
As a consequence, please drop any (build-)dependency on atlas.
This should normally be straightforward to achieve, by simply replacing atlas
with another BLAS (and possibly also LAPACK) implementation.
Ideally, packages should Build-Depend on the Netlib reference implementation
(libblas-dev, and liblapack-dev where required), and not enforce anything in
the Depends field of binary packages (dpkg-shlibdeps will automatically add the
appropriate "libblas3 | libblas.so.3" entry to ${shlibs:Depends}).
Alternative implementations may be given in Build-Depends for the ease
of users making local builds with an optimized implementation installed,
but the generic reference implementation should be placed first to be
used by buildds. The simplest example is
Build-Depends: libblas-dev | libblas.so,
liblapack-dev | liblapack.so
where specific optimized implementations may provide the
libblas.so/liblapack.so pseudo-package.
Similarly, if one wants to encourage users to install an optimized
implementation at runtime, then one can add
Recommends: libopenblas0 | libblis4
in binary packages.
Also note that if your package needs libcblas (which is currently only provided
by libatlas-base-dev), then the solution is to modify the build system so that
it rather uses libblas (because, under Debian, the latter already incorporates
the symbols provided by libcblas).
Thanks for your work,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
Bug#1056680: (build-)depends on atlas, which is obsolete and scheduled for removal
Source: odin
Version: 2.0.5-3
Severity: normal
Tags: sid trixie
User: debian-scie...@lists.debian.org
Usertags: atlas-rm
Dear Maintainer,
odin build-depends on libatlas-base-dev and also depends on libatlas-base-dev,
which is produced by the source package atlas.
atlas is obsolete and scheduled to be removed from Debian, ideally by the
trixie release. See the following thread on the Debian Science list for more
details:
https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org
As a consequence, please drop any (build-)dependency on atlas.
This should normally be straightforward to achieve, by simply replacing atlas
with another BLAS (and possibly also LAPACK) implementation.
Ideally, packages should Build-Depend on the Netlib reference implementation
(libblas-dev, and liblapack-dev where required), and not enforce anything in
the Depends field of binary packages (dpkg-shlibdeps will automatically add the
appropriate "libblas3 | libblas.so.3" entry to ${shlibs:Depends}).
Alternative implementations may be given in Build-Depends for the ease
of users making local builds with an optimized implementation installed,
but the generic reference implementation should be placed first to be
used by buildds. The simplest example is
Build-Depends: libblas-dev | libblas.so,
liblapack-dev | liblapack.so
where specific optimized implementations may provide the
libblas.so/liblapack.so pseudo-package.
Similarly, if one wants to encourage users to install an optimized
implementation at runtime, then one can add
Recommends: libopenblas0 | libblis4
in binary packages.
Also note that if your package needs libcblas (which is currently only provided
by libatlas-base-dev), then the solution is to modify the build system so that
it rather uses libblas (because, under Debian, the latter already incorporates
the symbols provided by libcblas).
Thanks for your work,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
Bug#1056679: build-depends on atlas, which is obsolete and scheduled for removal
Source: ncl
Version: 6.6.2.dfsg.1-2
Severity: normal
Tags: sid trixie
User: debian-scie...@lists.debian.org
Usertags: atlas-rm
Dear Maintainer,
ncl build-depends on libatlas-base-dev and libatlas3-base, which are produced
by the source package atlas.
atlas is obsolete and scheduled to be removed from Debian, ideally by the
trixie release. See the following thread on the Debian Science list for more
details:
https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org
As a consequence, please drop any (build-)dependency on atlas.
This should normally be straightforward to achieve, by simply replacing atlas
with another BLAS (and possibly also LAPACK) implementation.
Ideally, packages should Build-Depend on the Netlib reference implementation
(libblas-dev, and liblapack-dev where required), and not enforce anything in
the Depends field of binary packages (dpkg-shlibdeps will automatically add the
appropriate "libblas3 | libblas.so.3" entry to ${shlibs:Depends}).
Alternative implementations may be given in Build-Depends for the ease
of users making local builds with an optimized implementation installed,
but the generic reference implementation should be placed first to be
used by buildds. The simplest example is
Build-Depends: libblas-dev | libblas.so,
liblapack-dev | liblapack.so
where specific optimized implementations may provide the
libblas.so/liblapack.so pseudo-package.
Similarly, if one wants to encourage users to install an optimized
implementation at runtime, then one can add
Recommends: libopenblas0 | libblis4
in binary packages.
Also note that if your package needs libcblas (which is currently only provided
by libatlas-base-dev), then the solution is to modify the build system so that
it rather uses libblas (because, under Debian, the latter already incorporates
the symbols provided by libcblas).
Thanks for your work,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
Bug#1056678: (build-)depends on atlas, which is obsolete and scheduled for removal
Source: iml
Version: 1.0.5-1
Severity: normal
Tags: sid trixie
User: debian-scie...@lists.debian.org
Usertags: atlas-rm
Dear Maintainer,
iml build-depends on libatlas-base-dev and libiml0 depends on libatlas3-base,
which are produced by the source package atlas.
atlas is obsolete and scheduled to be removed from Debian, ideally by the
trixie release. See the following thread on the Debian Science list for more
details:
https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org
As a consequence, please drop any (build-)dependency on atlas.
This should normally be straightforward to achieve, by simply replacing atlas
with another BLAS (and possibly also LAPACK) implementation.
Ideally, packages should Build-Depend on the Netlib reference implementation
(libblas-dev, and liblapack-dev where required), and not enforce anything in
the Depends field of binary packages (dpkg-shlibdeps will automatically add the
appropriate "libblas3 | libblas.so.3" entry to ${shlibs:Depends}).
Alternative implementations may be given in Build-Depends for the ease
of users making local builds with an optimized implementation installed,
but the generic reference implementation should be placed first to be
used by buildds. The simplest example is
Build-Depends: libblas-dev | libblas.so,
liblapack-dev | liblapack.so
where specific optimized implementations may provide the
libblas.so/liblapack.so pseudo-package.
Similarly, if one wants to encourage users to install an optimized
implementation at runtime, then one can add
Recommends: libopenblas0 | libblis4
in binary packages.
Also note that if your package needs libcblas (which is currently only provided
by libatlas-base-dev), then the solution is to modify the build system so that
it rather uses libblas (because, under Debian, the latter already incorporates
the symbols provided by libcblas).
Thanks for your work,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
Bug#1056677: build-depends on atlas, which is obsolete and scheduled for removal
Source: hpcc
Version: 1.5.0-3
Severity: normal
Tags: sid trixie
User: debian-scie...@lists.debian.org
Usertags: atlas-rm
Dear Maintainer,
hpcc build-depends on libatlas-base-dev, which is produced by the source
package atlas.
atlas is obsolete and scheduled to be removed from Debian, ideally by the
trixie release. See the following thread on the Debian Science list for more
details:
https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org
As a consequence, please drop any (build-)dependency on atlas.
This should normally be straightforward to achieve, by simply replacing atlas
with another BLAS (and possibly also LAPACK) implementation.
Ideally, packages should Build-Depend on the Netlib reference implementation
(libblas-dev, and liblapack-dev where required), and not enforce anything in
the Depends field of binary packages (dpkg-shlibdeps will automatically add the
appropriate "libblas3 | libblas.so.3" entry to ${shlibs:Depends}).
Alternative implementations may be given in Build-Depends for the ease
of users making local builds with an optimized implementation installed,
but the generic reference implementation should be placed first to be
used by buildds. The simplest example is
Build-Depends: libblas-dev | libblas.so,
liblapack-dev | liblapack.so
where specific optimized implementations may provide the
libblas.so/liblapack.so pseudo-package.
Similarly, if one wants to encourage users to install an optimized
implementation at runtime, then one can add
Recommends: libopenblas0 | libblis4
in binary packages.
Also note that if your package needs libcblas (which is currently only provided
by libatlas-base-dev), then the solution is to modify the build system so that
it rather uses libblas (because, under Debian, the latter already incorporates
the symbols provided by libcblas).
Thanks for your work,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
Bug#1056675: build-depends on atlas, which is obsolete and scheduled for removal
Source: halide
Version: 16.0.0-3
Severity: normal
Tags: sid trixie
User: debian-scie...@lists.debian.org
Usertags: atlas-rm
Dear Maintainer,
halide build-depends (on armel) on libatlas-base-dev, which is produced by the
source package atlas.
atlas is obsolete and scheduled to be removed from Debian, ideally by the
trixie release. See the following thread on the Debian Science list for more
details:
https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org
As a consequence, please drop any (build-)dependency on atlas.
This should normally be straightforward to achieve, by simply replacing atlas
with another BLAS (and possibly also LAPACK) implementation.
Ideally, packages should Build-Depend on the Netlib reference implementation
(libblas-dev, and liblapack-dev where required), and not enforce anything in
the Depends field of binary packages (dpkg-shlibdeps will automatically add the
appropriate "libblas3 | libblas.so.3" entry to ${shlibs:Depends}).
Alternative implementations may be given in Build-Depends for the ease
of users making local builds with an optimized implementation installed,
but the generic reference implementation should be placed first to be
used by buildds. The simplest example is
Build-Depends: libblas-dev | libblas.so,
liblapack-dev | liblapack.so
where specific optimized implementations may provide the
libblas.so/liblapack.so pseudo-package.
Similarly, if one wants to encourage users to install an optimized
implementation at runtime, then one can add
Recommends: libopenblas0 | libblis4
in binary packages.
Also note that if your package needs libcblas (which is currently only provided
by libatlas-base-dev), then the solution is to modify the build system so that
it rather uses libblas (because, under Debian, the latter already incorporates
the symbols provided by libcblas).
Thanks for your work,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
Bug#1056672: (build-)depends on atlas, which is obsolete and scheduled for removal
Source: ergo
Version: 3.8-1
Severity: normal
Tags: sid trixie
User: debian-scie...@lists.debian.org
Usertags: atlas-rm
Dear Maintainer,
ergo build-depends on libatlas-base-dev and depends on libatlas3-base, which
are produced by the source package atlas.
atlas is obsolete and scheduled to be removed from Debian, ideally by the
trixie release. See the following thread on the Debian Science list for more
details:
https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org
As a consequence, please drop any (build-)dependency on atlas.
This should normally be straightforward to achieve, by simply replacing atlas
with another BLAS (and possibly also LAPACK) implementation.
Ideally, packages should Build-Depend on the Netlib reference implementation
(libblas-dev, and liblapack-dev where required), and not enforce anything in
the Depends field of binary packages (dpkg-shlibdeps will automatically add the
appropriate "libblas3 | libblas.so.3" entry to ${shlibs:Depends}).
Alternative implementations may be given in Build-Depends for the ease
of users making local builds with an optimized implementation installed,
but the generic reference implementation should be placed first to be
used by buildds. The simplest example is
Build-Depends: libblas-dev | libblas.so,
liblapack-dev | liblapack.so
where specific optimized implementations may provide the
libblas.so/liblapack.so pseudo-package.
Similarly, if one wants to encourage users to install an optimized
implementation at runtime, then one can add “Recommends: libopenblas0 |
libblis4” in binary packages.
Also note that if your package needs libcblas (which is currently only provided
by libatlas-base-dev), then the solution is to modify the build system so that
it rather uses libblas (because, under Debian, the latter already incorporates
the symbols provided by libcblas).
Thanks for your work,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
Bug#1056673: build-depends on atlas, which is obsolete and scheduled for removal
Source: ghmm
Version: 0.9~rc3-4
Severity: normal
Tags: sid trixie
User: debian-scie...@lists.debian.org
Usertags: atlas-rm
Dear Maintainer,
ghmm build-depends on libatlas-base-dev, which is produced by the source
package atlas.
atlas is obsolete and scheduled to be removed from Debian, ideally by the
trixie release. See the following thread on the Debian Science list for more
details:
https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org
As a consequence, please drop any (build-)dependency on atlas.
This should normally be straightforward to achieve, by simply replacing atlas
with another BLAS (and possibly also LAPACK) implementation.
Ideally, packages should Build-Depend on the Netlib reference implementation
(libblas-dev, and liblapack-dev where required), and not enforce anything in
the Depends field of binary packages (dpkg-shlibdeps will automatically add the
appropriate "libblas3 | libblas.so.3" entry to ${shlibs:Depends}).
Alternative implementations may be given in Build-Depends for the ease
of users making local builds with an optimized implementation installed,
but the generic reference implementation should be placed first to be
used by buildds. The simplest example is
Build-Depends: libblas-dev | libblas.so,
liblapack-dev | liblapack.so
where specific optimized implementations may provide the
libblas.so/liblapack.so pseudo-package.
Similarly, if one wants to encourage users to install an optimized
implementation at runtime, then one can add
Recommends: libopenblas0 | libblis4
in binary packages.
Also note that if your package needs libcblas (which is currently only provided
by libatlas-base-dev), then the solution is to modify the build system so that
it rather uses libblas (because, under Debian, the latter already incorporates
the symbols provided by libcblas).
Thanks for your work,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
Bug#1056671: (build-)depends on atlas, which is obsolete and scheduled for removal
Source: emmax
Version: 0~beta.20100307-3
Severity: normal
Tags: sid trixie
User: debian-scie...@lists.debian.org
Usertags: atlas-rm
Dear Maintainer,
emmax build-depends on libatlas-base-dev, and depends on libatlas3-base and
libatlas-base-dev, which are produced by the source package atlas.
atlas is obsolete and scheduled to be removed from Debian, ideally by the
trixie release. See the following thread on the Debian Science list for more
details:
https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org
As a consequence, please drop any (build-)dependency on atlas.
This should normally be straightforward to achieve, by simply replacing atlas
with another BLAS (and possibly also LAPACK) implementation.
Ideally, packages should Build-Depend on the Netlib reference implementation
(libblas-dev, and liblapack-dev where required), and not enforce anything in
the Depends field of binary packages (dpkg-shlibdeps will automatically add the
appropriate "libblas3 | libblas.so.3" entry to ${shlibs:Depends}).
Alternative implementations may be given in Build-Depends for the ease
of users making local builds with an optimized implementation installed,
but the generic reference implementation should be placed first to be
used by buildds. The simplest example is
Build-Depends: libblas-dev | libblas.so,
liblapack-dev | liblapack.so
where specific optimized implementations may provide the
libblas.so/liblapack.so pseudo-package.
Similarly, if one wants to encourage users to install an optimized
implementation at runtime, then one can add “Recommends: libopenblas0 |
libblis4” in binary packages.
Also note that if your package needs libcblas (which is currently only provided
by libatlas-base-dev), then the solution is to modify the build system so that
it rather uses libblas (because, under Debian, the latter already incorporates
the symbols provided by libcblas).
In the specific case of emmax, I understand that it needs clapack.h which is
currently shipped by libatlas-base-dev. clapack.h is apparently an early
attempt at providing a C interface to some LAPACK functions (which are in
Fortran). The modern solution for that problem is to use LAPACKE (note the
final “E”), which is provided by liblapacke-dev. It is a standardized and
maintained C interface to all LAPACK routines.
If migrating to LAPACKE is too complicated, then I guess an easy solution is to
embed clapack.h into src:emmax.
Thanks for your work,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
Bug#1056669: (build-)depends on atlas, which is obsolete and scheduled for removal
Source: dune-common
Version: 2.9.0-3
Severity: normal
Tags: sid trixie
User: debian-scie...@lists.debian.org
Usertags: atlas-rm
Dear Maintainer,
dune-common build-depends on libatlas-base-dev and libdune-common-dev depends
on libatlas-base-dev and libatlas3-base, which are produced by the source
package atlas.
atlas is obsolete and scheduled to be removed from Debian, ideally by the
trixie release. See the following thread on the Debian Science list for more
details:
https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org
As a consequence, please drop any (build-)dependency on atlas.
This should normally be straightforward to achieve, by simply replacing atlas
with another BLAS (and possibly also LAPACK) implementation.
Ideally, packages should Build-Depend on the Netlib reference implementation
(libblas-dev, and liblapack-dev where required), and not enforce anything in
the Depends field of binary packages (dpkg-shlibdeps will automatically add the
appropriate "libblas3 | libblas.so.3" entry to ${shlibs:Depends}).
Alternative implementations may be given in Build-Depends for the ease
of users making local builds with an optimized implementation installed,
but the generic reference implementation should be placed first to be
used by buildds. The simplest example is
Build-Depends: libblas-dev | libblas.so,
liblapack-dev | liblapack.so
where specific optimized implementations may provide the
libblas.so/liblapack.so pseudo-package.
Similarly, if one wants to encourage users to install an optimized
implementation at runtime, then one can add “Recommends: libopenblas0 |
libblis4” in binary packages.
Also note that if your package needs libcblas (which is currently only provided
by libatlas-base-dev), then the solution is to modify the build system so that
it rather uses libblas (because, under Debian, the latter already incorporates
the symbols provided by libcblas).
Thanks for your work,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
Bug#1056666: (build-)depends on atlas, which is obsolete and scheduled for removal
Source: ceres-solver
Version: 2.2.0+dfsg-3
Severity: normal
Tags: sid trixie
User: debian-scie...@lists.debian.org
Usertags: atlas-rm
Dear Maintainer,
ceres-solver build-depends on libatlas-base-dev, libceres-dev depends on
libatlas-base-dev and libceres4 depends on libatlas3-base, which are produced by
the source package atlas.
atlas is obsolete and scheduled to be removed from Debian, ideally by the
trixie release. See the following thread on the Debian Science list for more
details:
https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org
As a consequence, please drop any (build-)dependency on atlas.
This should normally be straightforward to achieve, by simply replacing atlas
with another BLAS (and possibly also LAPACK) implementation.
Ideally, packages should Build-Depend on the Netlib reference implementation
(libblas-dev, and liblapack-dev where required), and not enforce anything in
the Depends field of binary packages (dpkg-shlibdeps will automatically add the
appropriate "libblas3 | libblas.so.3" entry to ${shlibs:Depends}).
Alternative implementations may be given in Build-Depends for the ease
of users making local builds with an optimized implementation installed,
but the generic reference implementation should be placed first to be
used by buildds. The simplest example is
Build-Depends: libblas-dev | libblas.so,
liblapack-dev | liblapack.so
where specific optimized implementations may provide the
libblas.so/liblapack.so pseudo-package.
Similarly, if one wants to encourage users to install an optimized
implementation at runtime, then one can add “Recommends: libopenblas0 |
libblis4” in binary packages.
Also note that if your package needs libcblas (which is currently only provided
by libatlas-base-dev), then the solution is to modify the build system so that
it rather uses libblas (because, under Debian, the latter already incorporates
the symbols provided by libcblas).
Thanks for your work,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
Bug#1056392: suitesparse breaks the octave autopkgtest on 32bit
Hi Adrian, Le mercredi 22 novembre 2023 à 09:43 +0200, Adrian Bunk a écrit : > Source: suitesparse > Version: 1:7.3.1+dfsg-2 > Tags: ftbfs > > https://tracker.debian.org/pkg/suitesparse > > Issues preventing migration: > ∙ ∙ autopkgtest for octave/8.4.0-1: amd64: Pass, arm64: Pass, armel: > Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: > Regression ♻ (reference ♻), ppc64el: Pass, s390x: Pass > > > ... > 254s libinterp/corefcn/qr.cc-tst fatal: > caught signal Segmentation fault -- stopping myself... I think the problem is the following: – suitesparse 1:7.3.1+dfsg-2 (in unstable) exhibits a SONAME bump compared to the version in testing: it ships libcholmod5 instead of libcholmod4 – libumfpack6, which is also produced by src:suitesparse, depends on libcholmod – when running the autopkgtest above, the octave binary from testing is used: that binary is linked directly against libcholmod4 and libumfpack6 – but since libumfpack6 that is used for the autopkgtest comes from the suitesparse in unstable, it is linked against libcholmod5 – hence in the same binary, both libcholmod4 and libcholmod5 are used – most likely, the crash comes from an opaque pointer structure that is passed from one version of libcholmod to the other, and whose structure is ABI-incompatible (there is indeed such a structure whose ABI changed only on 32-bit archs from libcholmod4 to libcholmod5). Note that I’m just speculating here, because I did not investigate the crash. However I’m positively sure that the crash is transient and will disappear once the suitesparse transition is over. Because the octave testsuite is also exercised at build time, and it did not crash on 32- bit archs when binNMUing octave 8.4.0-1+b1 against suitesparse 1:7.3.1+dfsg-2. So I agree that this is a problem for partial upgrades. But I don’t really know how to add a Breaks relationship that prevents the problem. Because adding something like "Breaks: octave (<< 8.4.0-1+b1)" is fragile: the binNMU number may theoretically differ across architectures; and such a version number may not even make sense for our derivatives. Any advice is welcome. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1055600: transition: suitesparse-7.3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: forwarded -1 https://release.debian.org/transitions/html/auto-suitesparse.html Dear Release Team, Please schedule a transition for suitesparse 7.3, which currently sits in experimental. One the shared libraries got a SOVERSION bump (libcholmod4 → libcholmod5). The ABI change is minor and I’m therefore fairly confident that there won’t be any issue. Thanks for your work, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1052973: marked as done (octave-image: FTBFS: make: *** [debian/rules:12: binary] Error 1)
Hi Rafael, Le samedi 07 octobre 2023 à 14:15 +0200, Rafael Laboissière a écrit : > I have a question for the Debian Octave Group, related to Bug#1052973, > which has been fixed in version 8.3.0-3 of octave-dev. This bug was > preventing the building of the octave-image package. Should we include > octave-dev >= 8.3.0-3 in Build-Depends of the otave-image package ? I would say no. If every time that a bug is fixed in a dependency, we were to bump the version requirement, then we would basically always depend on the latest version of every package. Also, it may be possible that octave-image builds against an old version of octave-dev that was not affected by the bug. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1053007: transition: suitesparse-7.2
Le mercredi 27 septembre 2023 à 19:09 +0200, Sebastian Ramacher a écrit : > On 2023-09-26 22:59:30 +0200, Sébastien Villemot wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-Cc: suitespa...@packages.debian.org > > Control: affects -1 + src:suitesparse > > Control: forwarded -1 > > https://release.debian.org/transitions/html/auto-suitesparse.html > > > > Dear Release Team, > > > > Please schedule a transition for suitesparse 7.2. The new version is > > already in > > experimental. > > Please go ahead. Thanks, uploaded and built on all release architectures. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1053007: transition: suitesparse-7.2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: suitespa...@packages.debian.org Control: affects -1 + src:suitesparse Control: forwarded -1 https://release.debian.org/transitions/html/auto-suitesparse.html Dear Release Team, Please schedule a transition for suitesparse 7.2. The new version is already in experimental. One of the binary packages produced by src:suitesparse got a SOVERSION bump (libspqr3 → libspqr4). Three reverse dependencies are affected. I rebuilt them without trouble against the new version. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1052458: elpa-ess: ESS mode in Emacs fails with many errors on startup
Control: tags -1 unreproducible Control: severity -1 important Dear Hugh, Le vendredi 22 septembre 2023 à 14:27 +0100, Hugh Pumphrey a écrit : > Package: elpa-ess > Version: 18.10.2+git20220915.f45542e-3 > Severity: grave > Justification: renders package unusable > X-Debbugs-Cc: hugh.pumph...@gmail.com >* What led up to the situation? > > I (as a long time user of R and the Emacs ESS mode) upgraded from > bullseye to bookworm. >* What exactly did you do (or not do) > > Attempted to edit an R source file in Emacs. (I am using emacs-lucid on > account of Bug#1043326 in emacs-gtk, but the bug I report here occurs > in both emacs-lucid and emacs-gtk.) > >* What was the outcome of this action? > > ESS mode fails to start up and many error and warning messages are > emitted --- see below. > >* What outcome did you expect instead? > > I expected ESS mode to start as normal, as it did for many debian releases > before bookworm. > > To check that this was not some oddity of upgrading from bullseye to > bookworm I purged packages ess and elpa-ess and re-installed them; the > problem did not go away. > > The error message appeared to be: > > File mode specification error: (error Loading file > /usr/share/emacs/site-lisp/elpa/ess-18.10.3snapshot/ess-rd.el > failed to provide feature 'essddr') > > A buffer containing many warning messages appeared which I copy here: > > Warning (comp): Cannot look-up eln file as no source file was found for > /usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess-r-mode.elc Disable showing > Disable logging > Warning (comp): Cannot look-up eln file as no source file was found for > /usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess-mode.elc Disable showing > Disable logging > Warning (comp): Cannot look-up eln file as no source file was found for > /usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess.elc Disable showing Disable > logging > Warning (comp): Cannot look-up eln file as no source file was found for > /usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess-custom.elc Disable showing > Disable logging > Warning (comp): Cannot look-up eln file as no source file was found for > /usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess-utils.elc Disable showing > Disable logging > Warning (comp): Cannot look-up eln file as no source file was found for > /usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess-generics.elc Disable showing > Disable logging > Warning (comp): Cannot look-up eln file as no source file was found for > /usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess-inf.elc Disable showing > Disable logging > Warning (comp): Cannot look-up eln file as no source file was found for > /usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess-tracebug.elc Disable showing > Disable logging > Warning (comp): Cannot look-up eln file as no source file was found for > /usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess-noweb-mode.elc Disable > showing Disable logging > Warning (comp): Cannot look-up eln file as no source file was found for > /usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess-help.elc Disable showing > Disable logging > Warning (comp): Cannot look-up eln file as no source file was found for > /usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess-s-lang.elc Disable showing > Disable logging > Warning (comp): Cannot look-up eln file as no source file was found for > /usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess-roxy.elc Disable showing > Disable logging I tried to reproduce your problem on a fresh installation of Debian “bookworm” 12, but I got no problem. I also have several machines which I upgraded from bullseye to bookworm, and elpa-ess also works fine on them. So something specific to your installation is causing the problem, but I don’t know what. At the very least, what strikes me is that the directory /usr/share/emacs/site-lisp/elpa/ess-18.10.2/ should not exist. It looks like a remnant of an old ESS version that did not get purged on upgrade, for an unknown reason. You could try to delete that directory. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1052250: pkg-config file incorrect for static linking
Package: libhdf5-dev Version: 1.10.8+repack1-1 Severity: normal Dear Maintainer, Trying to statically link an executable (like h5_write.c¹) against HDF5 using the pkg-config profile fails: $ gcc -static h5_write.c $(pkg-config --cflags hdf5) $(pkg-config --static --libs hdf5) /usr/bin/ld: /usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5.a(H5PLint.o): in function `H5PL__open': (.text+0x46b): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/bin/ld: /usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5.a(H5Fint.o): in function `H5F_track_metadata_read_retries': (.text+0x3c09): undefined reference to `log10' /usr/bin/ld: /usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5.a(H5Fint.o): in function `H5F_set_retries': (.text+0x3d42): undefined reference to `log10' /usr/bin/ld: /usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5.a(H5Tconv.o): in function `H5T__conv_f_i': (.text+0x631a4): undefined reference to `pow' /usr/bin/ld: /usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5.a(H5Tconv.o): in function `H5T__conv_i_f': (.text+0x64a73): undefined reference to `pow' /usr/bin/ld: (.text+0x64d82): undefined reference to `pow' /usr/bin/ld: /usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5.a(H5Z.o): in function `H5Z__init_package': (.text+0x60b): undefined reference to `SZ_encoder_enabled' /usr/bin/ld: /usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5.a(H5Zdeflate.o): in function `H5Z__filter_deflate': (.text+0x114): undefined reference to `compress2' /usr/bin/ld: (.text+0x212): undefined reference to `inflateInit_' /usr/bin/ld: (.text+0x23d): undefined reference to `inflate' /usr/bin/ld: (.text+0x25e): undefined reference to `inflateEnd' /usr/bin/ld: (.text+0x2b4): undefined reference to `inflateEnd' /usr/bin/ld: (.text+0x33e): undefined reference to `inflateEnd' […] Obviously the libraries on which HDF5 depends should be added to the Libs.private and Requires.private fields.² Thanks for your work, ¹ https://raw.githubusercontent.com/HDFGroup/hdf5/develop/examples/h5_write.c ² See for example https://people.freedesktop.org/~dbn/pkg-config-guide.html -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#933347: -d option doesn't work as expected for gettext with -M
On Mon, 29 Jul 2019 23:46:57 +0900 Osamu Aoki wrote: > Package: src:sphinx > Version: 1.8.4-1 > Severity: normal > > -M option doesn't work well except for a very simple case. I faced this > problem while building multi-language source. […] > I wanted to move the cache directory to a particular FOO, so I did: > $ sphinx-build -M gettext -d FOO source build > > This creates: > new file: FOO/gettext/environment.pickle > new file: FOO/gettext/index.doctree > new file: FOO/gettext/scope.doctree > new file: build/index.pot > new file: build/scope.pot I experience a similar problem with -M latexpdf in combination with the -D option. If I do: sphinx-build -M latexpdf -D release=v1.0 source build Then a directory “release=v1.0” is created (populated by doctrees) and the build breaks when trying to compile the LaTeX source to PDF. Experienced with sphinx-build 5.3.0-7. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#967951: OpenBLAS ILP64 with symbol suffixes
On Wed, 05 Aug 2020 17:19:11 + Leonard Lausen wrote: > Package: libopenblas64-0 > Version: 0.3.10+ds-3 > > As per https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=878121 libopenblas64-0 > has been made available containing the ILP64 build of OpenBLAS. Debian uses the > same symbol names in libopenblas64-0 and libopenblas0, which leads to conflicts > if users load multiple libraries into the same process that expect 32bit and 64bit interfaces respectively as the dynamic loader will only resolve the symbols once. > > For example, python3-numpy may depend on the 32bit libraries, but users can > compile a package against libopenblas64-0 and load both into the same Python > process. > > I believe that for this reason Debian's Julia package bundles OpenBlas "compiled > with SONAME=libopenblas64_.so, INTERFACE64=1 and all symbols suffixed by "64_" > as of 1.2.0+dfsg-1. See https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=905826 > > Why not provide libopenblas64_-0 packages with symbol name suffixes? This should > allow Julia package to stop bundling OpenBlas as well as ease the life of users > that want to compile against OpenBLAS ILP64 interface on Debian systems while > avoiding symbol name conflicts. This seems to be the approach taken by Fedora: > https://src.fedoraproject.org/rpms/openblas/blob/HEAD/f/openblas.spec For the record, see also the file docs/distributing.md that explains the current (and possibly future) conventions for distributing ILP64 builds. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1050867: marked as pending in jekyll
Le mardi 05 septembre 2023 à 21:02 -0300, Antonio Terceiro a écrit : > yes. I just submitted a stable update bug about it (#1051302) This is great, thanks! -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1047168: opendmarc: no longer able to send email reports due to sandboxing
Hi David, Sorry for my late reply, but I did not get your answer. The Debian BTS does not send a copy to bug reporters by default (you need to explicitly CC the bug reporter, either using their personal address or using the special nnn-submit...@bugs.debian.org address). See /usr/share/doc/debian/bug-maint-info.txt.gz for details. On Fri, 18 Aug 2023 08:59:16 +0200 David =?utf-8?Q?B=C3=BCrgin?= wrote: > I was worried something like this would come up … Can you try removing > the setting > > RestrictSUIDSGID=yes > > in the systemd service file (‘sudo systemctl edit --full opendmarc’)? > If this doesn’t work can you try also removing the setting > > NoNewPrivileges=yes > > Please let us know what works, thank you. I’ve removed both settings and it still does not work. Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1042933: octave-statistics autopkg tests fail in unstable on amd64
Le jeudi 31 août 2023 à 15:12 +0200, Rafael Laboissière a écrit :
> * Rafael Laboissière [2023-08-31 15:01]:
>
> > * Sébastien Villemot [2023-08-31 12:05]:
> >
> > > Le jeudi 03 août 2023 à 08:33 +0200, Rafael Laboissière a écrit :
> > > >
> > > > Just for the record, this is the offending unit test:
> > > >
> > > > 308s [inst/ConfusionMatrixChart.m]
> > > > 308s >>>>>
> > > >
> > > > /tmp/autopkgtest-lxc.9x_h6bvs/downtmp/build.BGX/src/inst/ConfusionMatrixChart.m
> > > > 308s * demo
> > > > 308s ## Create a simple ConfusionMatrixChart Object
> > > > 308s
> > > > 308s cm = ConfusionMatrixChart (gca, [1 2; 1 2],
> > > > {"A","B"},{"XLabel","LABEL A"})
> > > > 308s NormalizedValues = cm.NormalizedValues
> > > > 308s ClassLabels = cm.ClassLabels
> > > > 308s * shared visibility_setting
> > > > 308s visibility_setting = get (0, "DefaultFigureVisible");
> > > > 308s * test
> > > > 308s set (0, "DefaultFigureVisible", "off");
> > > > 308s cm = ConfusionMatrixChart (gca, [1 2; 1 2],
> > > > {"A","B"},{"XLabel","LABEL A"});
> > > > 308s assert (isa (cm, "ConfusionMatrixChart"), true);
> > > > 308s set (0, "DefaultFigureVisible", visibility_setting);
> > > > 308s warning: Non-positive limit for logarithmic axis ignored
> > > > 308s ! test failed
> > > > 308s set: "cameratarget" must be finite
> > > > 308s shared variables visibility_setting = on
> > > > 308s 1 test, 0 passed, 0 known failure, 0 skipped
> > > >
> > > > We have seen this problem already elsewhere. I will try to
> > > > investigate it.
> > >
> > > Did you get to a conclusion?
> >
> > No progress on my side, sorry.
>
> At any rate, the last autopkgtest run (on 2023-08-26) succeded:
> https://ci.debian.net/data/autopkgtest/unstable/amd64/o/octave-statistics/37186503/log.gz
>
> Should we close this bug report?
It seems that the failures are random. They also occurred on Ubuntu.
I’m going to apply the patch that was added there.
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
signature.asc
Description: This is a digitally signed message part
Bug#1050867: marked as pending in jekyll
Hi Antonio, Le mercredi 30 août 2023 à 15:33 +, Antonio Terceiro a écrit : > Bug #1050867 in jekyll reported by you has been fixed in the > Git repository and is awaiting an upload. You can see the commit > message below and you can check the diff of the fix at: > > https://salsa.debian.org/ruby-team/jekyll/-/commit/78d57aff39390464d023660c55803806b6b7f06f > > > Allow YAML aliases > > Closes: #1050867 > Thanks for swiftly fixing this issue! Shouldn’t the fix be backported to bookworm? -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1042933: octave-statistics autopkg tests fail in unstable on amd64
Le jeudi 03 août 2023 à 08:33 +0200, Rafael Laboissière a écrit :
> * Matthias Klose [2023-08-03 04:23]:
>
> > Package: src:octave-statistics
> > Version: 1.6.0-1
> > Severity: serious
> > Tags: sid trixie
> >
> > octave autopkg tests fail in unstable on amd64 (triggered by gcc-13).
> >
> > https://ci.debian.net/data/autopkgtest/testing/amd64/o/octave-statistics/36329437/log.gz
> >
> > Not sure which ones are the regressions, because all failures seem to
> > be marked as "known failure".
>
> Thanks for the bug report, Matthias.
>
> Just for the record, this is the offending unit test:
>
> 308s [inst/ConfusionMatrixChart.m]
> 308s >>>>>
>
> /tmp/autopkgtest-lxc.9x_h6bvs/downtmp/build.BGX/src/inst/ConfusionMatrixChart.m
> 308s * demo
> 308s ## Create a simple ConfusionMatrixChart Object
> 308s
> 308s cm = ConfusionMatrixChart (gca, [1 2; 1 2],
> {"A","B"},{"XLabel","LABEL A"})
> 308s NormalizedValues = cm.NormalizedValues
> 308s ClassLabels = cm.ClassLabels
> 308s * shared visibility_setting
> 308s visibility_setting = get (0, "DefaultFigureVisible");
> 308s * test
> 308s set (0, "DefaultFigureVisible", "off");
> 308s cm = ConfusionMatrixChart (gca, [1 2; 1 2],
> {"A","B"},{"XLabel","LABEL A"});
> 308s assert (isa (cm, "ConfusionMatrixChart"), true);
> 308s set (0, "DefaultFigureVisible", visibility_setting);
> 308s warning: Non-positive limit for logarithmic axis ignored
> 308s ! test failed
> 308s set: "cameratarget" must be finite
> 308s shared variables visibility_setting = on
> 308s 1 test, 0 passed, 0 known failure, 0 skipped
>
> We have seen this problem already elsewhere. I will try to investigate
> it.
Did you get to a conclusion?
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
signature.asc
Description: This is a digitally signed message part
Bug#1050867: support for YAML aliases broken by switch from safe_yaml to Psych
Le mercredi 30 août 2023 à 16:05 +0200, Sébastien Villemot a écrit : > In jekyll 4.3.1+dfsg-1, a Debian-specific patch was added to rely on Psych > instead of safe_yaml for reading YAML files (see #1026427). > > This change has however broken support for YAML aliases. […] > An easy fix is to explicitly allow aliases. I attach a patch (which must be > applied on top of 0016-Drop-usage-of-safe_yaml.patch). Note that my patch has been incorporated into the upstream pull request on which the Debian-specific patch is based: https://github.com/jekyll/jekyll/pull/8772#issuecomment-1699309363 -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1050867: support for YAML aliases broken by switch from safe_yaml to Psych
Package: jekyll Version: 4.3.1+dfsg-2 Severity: normal Tags: patch Dear Maintainers, In jekyll 4.3.1+dfsg-1, a Debian-specific patch was added to rely on Psych instead of safe_yaml for reading YAML files (see #1026427). This change has however broken support for YAML aliases. More precisely, I’m no longer able to use the minimal-mistakes theme, because this theme triggers the parsing of the following YAML file: https://github.com/mmistakes/minimal-mistakes/blob/master/_data/ui-text.yml This YAML file has aliases (symbol names starting with an ampersand), which are not supported by the Psych.safe_load() method with its default arguments. I thus get this error message (truncated trace): /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:430:in `visit_Psych_Nodes_Alias': Unknown alias: DEFAULT_EN (Psych::BadAlias) from /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:30:in `visit' from /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:6:in `accept' from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:35:in `accept' from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:345:in `block in revive_hash' from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `each' from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `each_slice' from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `revive_hash' from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:167:in `visit_Psych_Nodes_Mapping' from /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:30:in `visit' from /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:6:in `accept' from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:35:in `accept' from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:345:in `block in revive_hash' from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `each' from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `each_slice' from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `revive_hash' from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:167:in `visit_Psych_Nodes_Mapping' from /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:30:in `visit' from /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:6:in `accept' from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:35:in `accept' from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:318:in `visit_Psych_Nodes_Document' from /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:30:in `visit' from /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:6:in `accept' from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:35:in `accept' from /usr/lib/ruby/3.1.0/psych.rb:335:in `safe_load' from /usr/share/rubygems-integration/all/gems/jekyll-4.3.1/lib/jekyll/utils.rb:321:in `safe_load_yaml' from /usr/share/rubygems-integration/all/gems/jekyll-4.3.1/lib/jekyll/utils.rb:330:in `safe_load_yaml_file' […] An easy fix is to explicitly allow aliases. I attach a patch (which must be applied on top of 0016-Drop-usage-of-safe_yaml.patch). Thanks for your work, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org --- /usr/share/rubygems-integration/all/gems/jekyll-4.3.1/lib/jekyll/utils.rb 2023-04-16 23:35:56.0 +0200 +++ utils.rb2023-08-30 15:56:26.028936881 +0200 @@ -318,7 +318,7 @@ # Safely load YAML strings def safe_load_yaml(yaml) - Psych.safe_load(yaml, :permitted_classes => [Date, Time]) + Psych.safe_load(yaml, :permitted_classes => [Date, Time], aliases: true) rescue ArgumentError # Psych versions < 3.1 had a different safe_load API and used # problematic language.
Bug#1050303: extension no longer works with Gnome 44
Actually I reported this problem in the Debian BTS because I was not 100% sure that this is an upstream issue (the error message is actually compatible with a missing file in the .deb). I prefer that you report it upstream yourself if your are confident that this is not an issue in the packaging. Thanks! Le mardi 22 août 2023 à 13:30 -0700, Francois Marier a écrit : > Bonjours Sébastien, > > It does look like a different error message indeed. > > Are you happy to also report this new problem upstream, or would you prefer > I forward your email to upstream's GitHub issue tracker myself? > > Francois > > On 2023-08-22 at 12:35:24, Sébastien Villemot (sebast...@debian.org) wrote: > > Package: workrave-gnome > > Version: 1.10.51.1-2 > > Severity: normal > > > > Dear Maintainer, > > > > After upgrading to gnome-shell 44, the extension no longer works. > > > > In the Extensions application, I am unable to activate the extension, and > > the > > following message is displayed: > > > > Requiring Workrave, version 2.0: Typelib file for namespace 'Workrave', > > version '2.0' not found > > > > Note that this seems to be a different issue than the following upstream > > one: > > https://github.com/rcaelers/workrave/issues/487 > > > > Thanks for your work, > > > > -- > > ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot > > ⣾⠁⢠⠒⠀⣿⡁ Debian Developer > > ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name > > ⠈⠳⣄ https://www.debian.org -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1050303: extension no longer works with Gnome 44
Package: workrave-gnome Version: 1.10.51.1-2 Severity: normal Dear Maintainer, After upgrading to gnome-shell 44, the extension no longer works. In the Extensions application, I am unable to activate the extension, and the following message is displayed: Requiring Workrave, version 2.0: Typelib file for namespace 'Workrave', version '2.0' not found Note that this seems to be a different issue than the following upstream one: https://github.com/rcaelers/workrave/issues/487 Thanks for your work, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1047168: no longer able to send email reports due to sandboxing
Package: opendmarc Version: 1.4.2-3 Severity: normal Dear Maintainer, Since version 1.4.2-3, opendmarc is no longer able to send reports, presumably due to sandboxing features that were added in this Debian revision. More precisely, I have enabled the “FailureReports” option. Reports are then sent via the sendmail binary, which on my system is handled by postfix. I have many messages such as this one in my log: août 13 23:41:22 rama postfix/postdrop[3510103]: warning: mail_queue_enter: create file maildrop/323242.3510103: Permission denied The sendmail and postdrop process ard spawned by opendmarc, and thus belong to the same systemd unit. Because of the sandboxing, they are no longer able to push mail to the postfix queue (since that process involves a change in UID/GID). Thanks for your work, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1043048: Please give back statsmodels on mips64el Re: (Bug#1043048: fixed in openblas 0.3.23+ds-3)
Le lundi 07 août 2023 à 19:13 +0100, Rebecca N. Palmer a écrit : > This does seem to have worked: the openblas build log no longer contains > FATAL ERROR. > > Hence, please give back statsmodels on mips64el. (DMs aren't allowed to > use the self-service link.) Done. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1043048: openblas: gives wrong results on mips64el, ignores test failures
Control: found -1 0.3.22+ds-1 Control: forwarded -1 https://github.com/xianyi/OpenBLAS/issues/4181 Le samedi 05 août 2023 à 13:24 +0100, Rebecca N. Palmer a écrit : > Control: tags -1 upstream > > Upstream CI's mips64 qemu test has what look like the same FATAL ERRORs, > in MIPS64_GENERIC but not SICORTEX, but is still listed as passing. Thanks. Forwarded upstream. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1043048: openblas: gives wrong results on mips64el, ignores test failures
Dear Rebecca, Thanks for your report. Le samedi 05 août 2023 à 09:25 +0100, Rebecca N. Palmer a écrit : > Package: libopenblas0-pthread > Version: 0.3.23+ds-2 > Control: affects -1 src:statsmodels > Severity: serious > Justification: the default BLAS should NOT silently give wrong answers > (i.e. if there's no easy way to actually fix this, please switch the > default on mips64el back to atlas, and consider removing this package > from mips64el) > > statsmodels recently (between 0.14.0+dfsg-1 and -2) started to FTBFS on > mips64el with multiple wrong test results. The most obviously relevant > change between those is that the installed BLAS changed from atlas to > openblas. > > openblas' own tests on mips64el ( > https://buildd.debian.org/status/fetch.php?pkg=openblas=mips64el=0.3.23%2Bds-2=1686760279=0 > > ) have 64 instances of "FATAL ERROR - COMPUTED RESULT IS LESS THAN HALF > ACCURATE". (I don't know why this isn't failing the build, which is > possibly a bug in itself.) > > openblas upstream are not _obviously_ aware of this. Given the > existence of .github/workflows/mips64.yml, this suggests it _may_ be > nontrivial to reproduce in qemu. It looks like version 0.3.21+ds-4 is not affected by this issue and passes its testsuite. Can you possibly check whether statsmodels builds against that version? My guess is that this bug is caused by the switch to the MIPS64_GENERIC kernel that I made in version 0.3.22+ds-1. If this is indeed the cause, then an easy short term fix is to roll back this change and go back to the SICORTEX kernel. For a longer term fix, I would need to work with upstream to determine why the MIPS64_GENERIC kernel is broken. Also note that in any case, using ATLAS is not a good solution because we are considering its removal, see the thread on debian-science@.¹ BLIS is a better alternative to OpenBLAS. I also agree that the fact that the OpenBLAS testsuite fails without triggering an FTBFS is abnormal. I’m surprised by this, and this should be investigated. Cheers, ¹ https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1039470: bullseye-pu: package openblas/0.3.13+ds-3+deb11u1
Le dimanche 30 juillet 2023 à 15:00 +0100, Jonathan Wiltshire a écrit : > On Mon, Jun 26, 2023 at 12:58:07PM +0200, Sébastien Villemot wrote: > > The problem that I am trying to fix is the following: the AVX512 kernel > > (nicknamed > > “SkylakeX”) is miscompiled in openblas 0.3.13+ds-3, so that openblas gives > > incorrect numerical results in the DGEMM function (basic matrix > > multiplication) > > on AVX512-capable hardware. > > Please go ahead. Thanks, uploaded. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1038943: bullseye-pu: package lapack/3.9.0-3+deb11u1
Le mardi 25 juillet 2023 à 21:37 +0100, Jonathan Wiltshire a écrit : > On Fri, Jun 23, 2023 at 03:11:18PM +0200, Sébastien Villemot wrote: > > [ Reason ] > > This oldstable update fixes important bug #1037188. > > > > The bug is in LAPACKE (the C interface to LAPACK, which is in Fortran). > > > > For symmetric eigenvalue problems, the returned eigenvector matrix > > is incorrect (when row-major layout of matrices is used). > > > > This is a regression from buster. The bug has been fixed in bookworm and > > sid. > > Please go ahead. Thanks, uploaded. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1041227: transition: suitesparse
Le dimanche 16 juillet 2023 à 18:50 +0200, Sebastian Ramacher a écrit : > On 2023-07-15 23:25:28 +0200, Sébastien Villemot wrote: > > Please schedule a transition for suitesparse 7, which currently sits in > > experimental. > > Please go ahead. Thanks for driving this transition so far. I have noticed the build failures of octave on 32-bit architectures (that you reported in #1041460). Actually, it turns out that suitesparse 7 is partly broken on 32-bit architectures. Contrarily to what I said previously, there is an ABI change on 32-bit architectures. And due to the way that this ABI change was performed, it had the unintended consequence of breaking libspqr3 (provided by src:suitesparse) on 32-bit architectures. Upstream realized this too late (and did not make much publicity around it, so I was not aware of the issue before starting the transition). Upstream seems to be working on a fix, but at this point there is none available. The only affected package seems to be octave, for which there is a workaround (disabling libspqr use on 32-bit archs, which implies that some functionalities won’t be available there). I hope this situation is only temporary. There are two other reverse dependencies of libspqr (petsc and apbs) but so far they don’t seem to be affected (they probably are to some extent, but at least no FTBFS or autopkgtest failure in sight). Ideally I should have waited longer before starting this transition but it’s now too late (unless you think that the transition should be rolled back, though that seems a bit extreme given the limited extent of the breakage; in particular, 32-bit archs are probably not used that much for number crunching these days). -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1041059: FTBFS against suitesparse 7
Hi Dima, Le vendredi 14 juillet 2023 à 10:08 -0700, Dima Kogan a écrit : > Hello. Thank you for the report. This is already fixed in the libdogleg > upstream repo. I will push a new package when a new libdogleg is > released or when the new suitesparse moves to unstable, whichever comes first. Thanks. FYI, suitesparse 7 has been uploaded to unstable. Please let me know if you need help in fixing libdogleg. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1041227: transition: suitesparse
Le dimanche 16 juillet 2023 à 18:50 +0200, Sebastian Ramacher a écrit : > On 2023-07-15 23:25:28 +0200, Sébastien Villemot wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-Cc: suitespa...@packages.debian.org > > Control: affects -1 + src:suitesparse > > Control: forwarded -1 > > https://release.debian.org/transitions/html/auto-suitesparse.html > > Control: block -1 by 1041059 1037905 1037622 1040694 1041225 1037858 > > > > Dear Release Team, > > > > Please schedule a transition for suitesparse 7, which currently sits in > > experimental. > > Please go ahead. Thanks, it’s now uploaded and built on all release architectures. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1041227: transition: suitesparse
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: suitespa...@packages.debian.org Control: affects -1 + src:suitesparse Control: forwarded -1 https://release.debian.org/transitions/html/auto-suitesparse.html Control: block -1 by 1041059 1037905 1037622 1040694 1041225 1037858 Dear Release Team, Please schedule a transition for suitesparse 7, which currently sits in experimental. In this new major release, the SOVERSION of all libraries has been bumped, because some integer types part of the API have been redefined; however, this redefinition does not change anything on our release architectures. There are also a couple of other changes in headers that impact three reverse dependencies: libdogleg, siconos and octave. A fix is available for the three of them, and I stand ready to upload as needed. Four other reverse dependencies (yade, dolfin, openturns, sight) currently FTBFS for unrelated reasons. As a consequence, I could not verify that they build correctly against suitesparse 7 (but if they don’t, I’m fairly confident that they can be adapted). Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1041225: FTBFS against suitesparse 7
Source: siconos Version: 4.4.0+dfsg-2 Severity: important Tags: ftbfs sid trixie patch User: sebast...@debian.org Usertags: suitesparse7 Dear Maintainer, siconos fails to build against suitesparse 7, which is currently available in experimental. A patch is attached. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org Description: Fix FTBFS against suitesparse 7 In SuiteSparse 7.1.0, CXSparse now unconditionally enables the complex number support. In particular, cs.h now unconditonally includes . But "I" is a preprocessor macro when is included, and this conflicts with names used inside siconos and boost. So undefine that macro. Author: Sébastien Villemot Bug-Debian: https://bugs.debian.org/ Forwarded: no Last-Update: 2023-07-15 --- This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ --- a/numerics/src/tools/CSparseMatrix_internal.h +++ b/numerics/src/tools/CSparseMatrix_internal.h @@ -45,6 +45,7 @@ #define NCOMPLEX #include "cs.h" +#undef I #include "CSparseMatrix.h"
Bug#1020471: Interest in patch?
Hi Soren, Le samedi 15 juillet 2023 à 10:51 -0700, Soren Stoutner a écrit : > Would you be interested in a patch implementing this functionality? In principle I would be interested in a patch. But actually I’m considering the possibility of removing src:hunspell- fr and having its binary packages taken over by src:grammalecte. So I don’t know if it’s the right time to implement such a change. And I can’t guarantee that your patch will apply as-is in the new setup. Best wishes, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1041058: does not respect compilation flags from dpkg-buildflags
Le vendredi 14 juillet 2023 à 16:59 +0200, Sébastien Villemot a écrit : > The build process of ceres-solver does not respect the flags from > dpkg-buildflags. > > More precisely, it unconditionally adds -O3. It means that the default -O2 > level is not respected. It also means that DEB_BUILD OPTIONS=noopt does not > work as expected (it should use -O0). > > I think this comes from the fact that cmake is passed > -DCMAKE_BUILD_TYPE=Release in debian/rules. The right option to pass for > Debian > packaging is -DCMAKE_BUILD_TYPE=None (as is done for example by dh, see > /usr/share/perl5/Debian/Debhelper/Buildsystem/cmake.pm). I just realized that using -O3 is allowed by Policy, if there is a good reason for using it (see §10.1). However it is still recommended to support DEB_BUILD_OPTIONS=noopt. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1041188: does not respect compilation flags from dpkg-buildflags
Le samedi 15 juillet 2023 à 14:39 +0200, Sébastien Villemot a écrit : > The build process of rheolef does not respect the flags from dpkg-buildflags. > > More precisely, it unconditionally adds -O3. It means that the default -O2 > level is not respected. It also means that DEB_BUILD OPTIONS=noopt does not > work as expected (it should use -O0). I just realized that using -O3 is allowed by Policy, if there is a good reason for using it (see §10.1). However it is still recommended to support DEB_BUILD_OPTIONS=noopt. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1041187: does not respect compilation flags from dpkg-buildflags
Le samedi 15 juillet 2023 à 14:14 +0200, Sébastien Villemot a écrit : > The build process of python-escript does not respect the flags from > dpkg-buildflags. > > For many source files, those flags are not injected. Moreover, the build > process unconditionally adds -O3. It means that the default -O2 level is not > respected. It also means that DEB_BUILD OPTIONS=noopt does not work as > expected > (it should use -O0). I just realized that using -O3 is allowed by Policy, if there is a good reason for using it (see §10.1). However it is still recommended to inject all other flags provided by dpkg-buildflags, and to support DEB_BUILD_OPTIONS=noopt. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1041188: does not respect compilation flags from dpkg-buildflags
Source: rheolef Version: 7.2-2 Severity: normal Dear Maintainer, The build process of rheolef does not respect the flags from dpkg-buildflags. More precisely, it unconditionally adds -O3. It means that the default -O2 level is not respected. It also means that DEB_BUILD OPTIONS=noopt does not work as expected (it should use -O0). Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1041187: does not respect compilation flags from dpkg-buildflags
Source: python-escript Version: 5.6-4 Severity: normal Dear Maintainer, The build process of python-escript does not respect the flags from dpkg-buildflags. For many source files, those flags are not injected. Moreover, the build process unconditionally adds -O3. It means that the default -O2 level is not respected. It also means that DEB_BUILD OPTIONS=noopt does not work as expected (it should use -O0). Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1041059: FTBFS against suitesparse 7
Source: libdogleg Version: 0.15.4-2 Severity: important Tags: ftbfs User: sebast...@debian.org Usertags: suitesparse7 Dear Maintainer, libdogleg fails to build against suitesparse 7, which is currently available in experimental. More precisely, it tries to include cholmod_function.h, which has disappeared in that release. If I understand correctly, this header was a backward compatibility layer consisting of a few macros. I guess you should either stop using these macros, or embed a copy of cholmod_function.h from suitessparse 5. I attach a build log. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org dpkg-buildpackage -us -uc -ui -B dpkg-buildpackage: info: source package libdogleg dpkg-buildpackage: info: source version 0.15.4-2 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Dima Kogan dpkg-source --before-build . dpkg-buildpackage: info: host architecture amd64 fakeroot debian/rules clean dh clean dh: warning: Compatibility levels before 10 are deprecated (level 9 in use) debian/rules override_dh_auto_clean make[1]: Entering directory '/home/sebastien/debian/transitions/suitesparse7/libdogleg-0.15.4' dh_auto_clean dh_auto_clean: warning: Compatibility levels before 10 are deprecated (level 9 in use) make -j1 clean make[2]: Entering directory '/home/sebastien/debian/transitions/suitesparse7/libdogleg-0.15.4' rm -f libdogleg.so* *.o *.a *.d libdogleg.a libdogleg.so libdogleg.so.2.0.15.4 libdogleg.so.2 libdogleg.3 sample make[2]: Leaving directory '/home/sebastien/debian/transitions/suitesparse7/libdogleg-0.15.4' rm -f libdogleg.html pod2htm*.tmp make[1]: Leaving directory '/home/sebastien/debian/transitions/suitesparse7/libdogleg-0.15.4' dh_clean dh_clean: warning: Compatibility levels before 10 are deprecated (level 9 in use) debian/rules build-arch dh build-arch dh: warning: Compatibility levels before 10 are deprecated (level 9 in use) dh_update_autotools_config -a dh_auto_configure -a dh_auto_configure: warning: Compatibility levels before 10 are deprecated (level 9 in use) debian/rules override_dh_auto_build make[1]: Entering directory '/home/sebastien/debian/transitions/suitesparse7/libdogleg-0.15.4' dh_auto_build dh_auto_build: warning: Compatibility levels before 10 are deprecated (level 9 in use) make -j1 make[2]: Entering directory '/home/sebastien/debian/transitions/suitesparse7/libdogleg-0.15.4' cc -g -O2 -ffile-prefix-map=/home/sebastien/debian/transitions/suitesparse7/libdogleg-0.15.4=. -fstack-protector-strong -Wformat -Werror=format-security -ggdb -Wall -Wextra -MMD -fno-omit-frame-pointer -I/usr/include/suitesparse --std=gnu99 -Wdate-time -D_FORTIFY_SOURCE=2 -c -o dogleg.o dogleg.c dogleg.c:19:10: fatal error: suitesparse/cholmod_function.h: No such file or directory 19 | #include | ^~~~ compilation terminated. make[2]: *** [: dogleg.o] Error 1 make[2]: Leaving directory '/home/sebastien/debian/transitions/suitesparse7/libdogleg-0.15.4' dh_auto_build: error: make -j1 returned exit code 2 make[1]: *** [debian/rules:10: override_dh_auto_build] Error 25 make[1]: Leaving directory '/home/sebastien/debian/transitions/suitesparse7/libdogleg-0.15.4' make: *** [debian/rules:7: build-arch] Error 2 dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2
Bug#1041058: does not respect compilation flags from dpkg-buildflags
Source: ceres-solver Version: 2.1.0+really2.1.0+dfsg-1 Severity: normal Dear Maintainer, The build process of ceres-solver does not respect the flags from dpkg-buildflags. More precisely, it unconditionally adds -O3. It means that the default -O2 level is not respected. It also means that DEB_BUILD OPTIONS=noopt does not work as expected (it should use -O0). I think this comes from the fact that cmake is passed -DCMAKE_BUILD_TYPE=Release in debian/rules. The right option to pass for Debian packaging is -DCMAKE_BUILD_TYPE=None (as is done for example by dh, see /usr/share/perl5/Debian/Debhelper/Buildsystem/cmake.pm). Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1040001: To strict version restrictions injected by dh-r (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
Le jeudi 06 juillet 2023 à 22:09 +0200, Andreas Tille a écrit : > Am Thu, Jul 06, 2023 at 09:13:46PM +0200 schrieb Sébastien Villemot: > > > I'm not sure so please explain in more detail. dh-r was designed to put > > > the lowest restriction regarding the versions. I remember some > > > discussion some time ago that Dirk thought we should put stronger > > > restrictions (and he is sometimes adding version restrictions manually > > > that are not helpful for backporting). If I will be sure I understand > > > your point exactly I can check the code and the relevant discussion. > > > (Feel free to file a bug report about this and we can discuss it there > > > if you think this makes more sense.) > > > > It comes from this line: > > https://salsa.debian.org/r-pkg-team/dh-r/-/blob/master/dh/R.pm#L272 > > > > More precisely the “r-base-core (>= $rbase_version)” part, which > > imposes an unnecessarily tight restriction on the r-base-core version. > > Got it, thanks for the explanation. […] > I'd consider it sensible if you open a bug against dh-r where we can > document the change you are suggesting. Done in #1040515. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1040515: adds unnecessarily strict versioned Depends on r-base-core
Package: dh-r Version: 20230121 Severity: normal dh-r adds "r-base-core (>= $VERSION)" in Depends, where VERSION is the one which was used at build time. Since dh-r already adds pseudo-packages in Depends that are meant to track ABI changes (r-api-*, r-graphics-engine-*), adding such a versioned depends on r-base-core is not needed in general, and actually creates a unnecessarily strict restriction. For example, if the version in r-base is more recent in unstable than in testing, and assuming that the ABI has not changed between those two versions, then a R addon built in unstable won’t be able to migrate to testing before r-base does, while there is no reason to forbid this. In particular, this can be a problem during freeze (see the discussion in #1035428 for an instance of this). Fixing this issue is probably just a matter of modifying the following line: https://salsa.debian.org/r-pkg-team/dh-r/-/blob/master/dh/R.pm#L272 See also the discussion in #1040001. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
Le jeudi 06 juillet 2023 à 21:02 +0200, Andreas Tille a écrit : > Am Thu, Jul 06, 2023 at 07:08:04PM +0200 schrieb Paul Gevers: > > PS: in a private discussion I had today, we noticed that r-* packages often > > (always?) have a dependency on r-base-core with a lower limited version > > equal to the r-base-core that was used during the build. With the > > appropriate API in Provides of r-base-core, this should no longer be > > necessary and ease migrations in the future. > > Could you please give some example to make sure I understand correctly? > > > We should probably file a bug > > against dh-r (I guess) to fix that dependency. Or did we conclude that > > wrong? > > I'm not sure so please explain in more detail. dh-r was designed to put > the lowest restriction regarding the versions. I remember some > discussion some time ago that Dirk thought we should put stronger > restrictions (and he is sometimes adding version restrictions manually > that are not helpful for backporting). If I will be sure I understand > your point exactly I can check the code and the relevant discussion. > (Feel free to file a bug report about this and we can discuss it there > if you think this makes more sense.) It comes from this line: https://salsa.debian.org/r-pkg-team/dh-r/-/blob/master/dh/R.pm#L272 More precisely the “r-base-core (>= $rbase_version)” part, which imposes an unnecessarily tight restriction on the r-base-core version. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1038933: transition: octave
Le samedi 01 juillet 2023 à 10:15 +0200, Sebastian Ramacher a écrit : > On 2023-06-23 10:32:52 +0200, Sébastien Villemot wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-Cc: oct...@packages.debian.org, debian-oct...@lists.debian.org > > Control: affects -1 + src:octave > > > > Dear Release Team, > > > > Please schedule a transition for the latest major upstream version of > > Octave, > > version 8. All the arch:any Octave addons need to be rebuild. > > Please go ahead. Thanks for your help! It looks like the transition is complete. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1025480: another manifestation of the problem with AVX-512 kernel, workarond
Dear Enzo, Le mardi 18 avril 2023 à 11:31 -0300, Enzo Alberto Dari a écrit : > This bug was correctly retitled by the maintainer as related to the > AVX-512 kernel. > However, it is filed against the libopenblas0-pthread debian package > while I have found another case that gives wrong results even using > one thread. Thanks for providing more information on this issue. I am happy to let you know that, with upstream’s help, I have finally been able to identify the cause of the problem and the relevant fix. I am going to fix this issue in Debian “Bullseye” 11 (see bug #1039470 for the details). I also confirm that Debian “Bookworm” 12 (which has recently been released) is not affected by this bug. Best wishes, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1039470: bullseye-pu: package openblas/0.3.13+ds-3+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: openb...@packages.debian.org Control: affects -1 + src:openblas Dear Release Team, [ Reason ] This oldstable update fixes important bug #1025480. As a reminder, OpenBLAS is a BLAS (basic linear algebra) implementation that provides kernels optimized for different generations of CPUs (ISAs). All the kernels are embedded in the library binary, and the kernel selection is done at runtime depending on the CPU model (this is called “dynamic arch” in the OpenBLAS jargon). The problem that I am trying to fix is the following: the AVX512 kernel (nicknamed “SkylakeX”) is miscompiled in openblas 0.3.13+ds-3, so that openblas gives incorrect numerical results in the DGEMM function (basic matrix multiplication) on AVX512-capable hardware. The cause of the problem is the following: the build-time check for determining whether the compiler is able to understand AVX512 assembly/intrinsics was doubly incorrect. It would test the build machine capabilities (instead of the compiler capabilities); and it would check for AVX2 instead of AVX512. As a consequence, on pre-AVX2 hardware, the build system would conclude that the compiler is not able to understand AVX512 primitives, and would create a broken AVX512 (SkylakeX) DGEMM kernel (essentially a Haswell kernel, but with some wrong assumptions, hence leading to incorrect numerical results). Versions 0.3.13+ds-3 and 0.3.13+ds-2, which are affected by the bug, were built on the x86-csail-01 build daemon in 2021, which I suppose was pre-Ivybridge. Binary packages built for e.g. on x86-conova-01 or x86-ubc-01 are not affected by the bug, so I suppose these machines has at least AVX2. But I do not have access to the build machine specifications to verify these conclusions. [ Impact ] Incorrect results in DGEMM (basic matrix multiplication) on AVX512-capable hardware (hence a pretty serious bug for numerical software). [ Tests ] I manually verified that, on an Ivybridge machine, the package built without the patch is buggy (i.e. gives incorrect results on AVX512-capable hardware), and the package built with the patch works fine. The internal testsuite of OpenBLAS still passes with the patch. [ Risks ] Risk is limited, since the patch should only affect AVX512 kernels (which are already broken anyways). [ Checklist ] [X] *all* changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in (old)stable [X] the issue is verified as fixed in unstable [ Changes ] A quilt patch added, containing an upstream pull request. The patch removes the dependency of the binary package produced on the build machine specifications (i.e. it will build correct AVX512 kernel, irrespectively of the build machine). -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org diff -Nru openblas-0.3.13+ds/debian/changelog openblas-0.3.13+ds/debian/changelog --- openblas-0.3.13+ds/debian/changelog 2021-04-18 10:36:29.0 +0200 +++ openblas-0.3.13+ds/debian/changelog 2023-06-25 21:56:08.0 +0200 @@ -1,3 +1,11 @@ +openblas (0.3.13+ds-3+deb11u1) bullseye; urgency=medium + + * avx512-dgemm.patch: new patch taken from upstream. Fixes incorrect numerical +results of DGEMM on AVX512-capable hardware, when the package has been built +on pre-AVX2 hardware (e.g. Intel Ivybridge). (Closes: #1025480) + + -- Sébastien Villemot Sun, 25 Jun 2023 21:56:08 +0200 + openblas (0.3.13+ds-3) unstable; urgency=medium * fix-arm64-sigill.patch: new patch, fixes SIGILL on arm64 with numpy. diff -Nru openblas-0.3.13+ds/debian/patches/avx512-dgemm.patch openblas-0.3.13+ds/debian/patches/avx512-dgemm.patch --- openblas-0.3.13+ds/debian/patches/avx512-dgemm.patch1970-01-01 01:00:00.0 +0100 +++ openblas-0.3.13+ds/debian/patches/avx512-dgemm.patch2023-06-25 21:56:08.0 +0200 @@ -0,0 +1,80 @@ +Description: Fix incorrect results of AVX512 DGEMM kernel when built on pre-AVX2 machine + When building OpenBLAS with dynamic arch selection on x86-64 hardware + that does not support AVX2 (e.g. Intel Ivybridge or earlier), then + the AVX512 (SkylakeX) kernel for DGEMM would produce incorrect + results (of course when run on AVX512-capable hardware). + . + The problem was that the check for determining whether the compiler + is able to understand AVX512 assembly/intrinsics was doubly + incorrect: it would test the build machine capabilities (instead of + the compiler capabilities); and it would check for AVX2 instead of + AVX512. As a consequence, on pre-AVX2 hardware, the build system + would conclude that the compiler is not able to understand AVX512 + primitives, and would create a broken AVX512 (SkylakeX) DGEMM kernel + (essentially a Haswell kernel, but with some wrong assumptions, hence
Bug#1037242: liblapacke: dsyev() only returns upper/lower triangle of eigenvector matrix
Dear David, Le vendredi 09 juin 2023 à 10:16 +, David Houseman a écrit : > Package: liblapacke > Version: 3.9.0-3 > Severity: important > X-Debbugs-Cc: da...@grey-house.net > > Given a symmetric matrix, LAPACKE dsyev() should return in place the matrix > of eigenvectors > (when JOBZ = 'V'). The eigenvector matrix is not symmetric (it is > orthogonal). However, > it appears that dsyev() only returns the upper/lower triangle of the > eigenvector matrix, > which is not enough to easily construct the full eigenvector matrix. […] > This is a fairly critical problem that would silently lead > to quite wrong answers for certain mathematical techniques > possibly including symmetric matrix inversion and/or > multilinear regression. I think it would be better to have > it fixed but I have no idea how difficult it would be to > patch debian stable. I will try the new debian testing and > see whether it is also affected. Thanks for your report. I confirm that the bug is present in Debian “Bullseye” 11, and that it is fixed in the recently Debian “Bookworm” 12. I am going to fix it in bullseye (see #1038943 for the details). Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1038943: bullseye-pu: package lapack/3.9.0-3+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: lap...@packages.debian.org
Control: affects -1 + src:lapack
Dear Release Team,
[ Reason ]
This oldstable update fixes important bug #1037188.
The bug is in LAPACKE (the C interface to LAPACK, which is in Fortran).
For symmetric eigenvalue problems, the returned eigenvector matrix
is incorrect (when row-major layout of matrices is used).
This is a regression from buster. The bug has been fixed in bookworm and sid.
[ Impact ]
Incorrect numerical result (one of the worst kind of bug for numerical
software)
[ Tests ]
I verified that the proposed upload fixes the bug.
It introduces no regression in the internal LAPACK testsuite.
[ Risks ]
The patch affects a couple of leaf functions, so the risk
is limited.
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
A quilt patch added, containing an upstream commit.
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
diff -Nru lapack-3.9.0/debian/changelog lapack-3.9.0/debian/changelog
--- lapack-3.9.0/debian/changelog 2020-08-01 16:15:54.0 +0200
+++ lapack-3.9.0/debian/changelog 2023-06-23 14:53:50.0 +0200
@@ -1,3 +1,11 @@
+lapack (3.9.0-3+deb11u1) bullseye; urgency=medium
+
+ * lapacke-syev-heev.patch: new patch, fixes eigenvector matrix in
+LAPACKE’s interface to symmetric eigenvalue problem (syev and heev
+functions) (Closes: #1037242)
+
+ -- Sébastien Villemot Fri, 23 Jun 2023 14:53:50 +0200
+
lapack (3.9.0-3) unstable; urgency=medium
[ Sébastien Villemot ]
diff -Nru lapack-3.9.0/debian/patches/lapacke-syev-heev.patch
lapack-3.9.0/debian/patches/lapacke-syev-heev.patch
--- lapack-3.9.0/debian/patches/lapacke-syev-heev.patch 1970-01-01
01:00:00.0 +0100
+++ lapack-3.9.0/debian/patches/lapacke-syev-heev.patch 2023-06-23
14:53:50.0 +0200
@@ -0,0 +1,215 @@
+Description: Fix eigenvector matrix in LAPACKE’s interface to symmetric
eigenvalue problem
+ The syev and heev functions, when passed jobz=V and called in row major order
+ mode, would return an incorrect eigenvector matrix (incorrect lower- or
+ upper-triangle part).
+Origin: upstream,
https://github.com/Reference-LAPACK/lapack/commit/7d5bb9e5e641772227022689162dd9cc47e64de0
+Bug: https://github.com/Reference-LAPACK/lapack/issues/850
+Bug-Debian: https://bugs.debian.org/1037242
+Last-Update: 2023-06-23
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+diff --git a/LAPACKE/src/lapacke_cheev_work.c
b/LAPACKE/src/lapacke_cheev_work.c
+index f505dfab0..aa78e678e 100644
+--- a/LAPACKE/src/lapacke_cheev_work.c
b/LAPACKE/src/lapacke_cheev_work.c
+@@ -78,7 +78,11 @@ lapack_int LAPACKE_cheev_work( int matrix_layout, char
jobz, char uplo,
+ info = info - 1;
+ }
+ /* Transpose output matrices */
+-LAPACKE_che_trans( LAPACK_COL_MAJOR, uplo, n, a_t, lda_t, a, lda );
++if ( jobz == 'V') {
++LAPACKE_cge_trans( LAPACK_COL_MAJOR, n, n, a_t, lda_t, a, lda );
++} else {
++LAPACKE_che_trans( LAPACK_COL_MAJOR, uplo, n, a_t, lda_t, a, lda
);
++}
+ /* Release memory and exit */
+ LAPACKE_free( a_t );
+ exit_level_0:
+diff --git a/LAPACKE/src/lapacke_cheevd_2stage_work.c
b/LAPACKE/src/lapacke_cheevd_2stage_work.c
+index e9e6a5d1d..d26c84785 100644
+--- a/LAPACKE/src/lapacke_cheevd_2stage_work.c
b/LAPACKE/src/lapacke_cheevd_2stage_work.c
+@@ -79,7 +79,11 @@ lapack_int LAPACKE_cheevd_2stage_work( int matrix_layout,
char jobz, char uplo,
+ info = info - 1;
+ }
+ /* Transpose output matrices */
+-LAPACKE_che_trans( LAPACK_COL_MAJOR, uplo, n, a_t, lda_t, a, lda );
++if ( jobz == 'V') {
++LAPACKE_cge_trans( LAPACK_COL_MAJOR, n, n, a_t, lda_t, a, lda );
++} else {
++LAPACKE_che_trans( LAPACK_COL_MAJOR, uplo, n, a_t, lda_t, a, lda
);
++}
+ /* Release memory and exit */
+ LAPACKE_free( a_t );
+ exit_level_0:
+diff --git a/LAPACKE/src/lapacke_cheevd_work.c
b/LAPACKE/src/lapacke_cheevd_work.c
+index 4c5f352a8..e8f212efb 100644
+--- a/LAPACKE/src/lapacke_cheevd_work.c
b/LAPACKE/src/lapacke_cheevd_work.c
+@@ -79,8 +79,11 @@ lapack_int LAPACKE_cheevd_work( int matrix_layout, char
jobz, char uplo,
+ info = info - 1;
+ }
+ /* Transpose output matrices */
+-LAPACKE_che_trans( LAPACK_COL_MAJOR, uplo, n, a_t, lda_t, a, lda );
+-
++if ( jobz == 'V') {
++LAPACKE_cge_trans( LAPACK_COL_MAJOR, n, n, a_t, lda_t, a, lda );
++} else {
++LAPACKE_che_trans( LAPACK_COL_MAJOR, uplo, n, a_t
Bug#1038933: transition: octave
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: oct...@packages.debian.org, debian-oct...@lists.debian.org Control: affects -1 + src:octave Dear Release Team, Please schedule a transition for the latest major upstream version of Octave, version 8. All the arch:any Octave addons need to be rebuild. Octave 8 has already been uploaded to experimental. A rebuild of all the packages affected by the transition has been performed. Several problems were fixed, and to the best of our knowledge, only one package is not ready (octave-stk; since it is a leaf package, it will be possible to temporarily exclude it from testing if it is not fixed by the time of the transition). We stand ready to upload and NMU as needed if other issues arise. Ben file: title = "octave"; is_affected = .depends ~ "octave-abi-57" | .depends ~ "octave-abi-58"; is_good = .depends ~ "octave-abi-58"; is_bad = .depends ~ "octave-abi-57"; -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1038210: please provide a way to use UCRT instead of MSVCRT
Le vendredi 16 juin 2023 à 16:42 +0200, Sébastien Villemot a écrit : > 2. at runtime, by passing a modified specs file to the cross-compiler (more >specifically, replacing -lmsvcrt by -lucrt in the libgcc section) Actually I realize that this solution probably does not work very reliably, in particular for C++ programs (because libstdc++ would still be built against MSVCRT). So the only reliable solution may be to provide different binary packages with cross-compilers for UCRT. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1038210: please provide a way to use UCRT instead of MSVCRT
Source: gcc-mingw-w64 Version: 25.2 Severity: wishlist Dear Maintainer, Recent versions of Windows ship a newer C runtime, UCRT, meant to supersede the historical one, MSVCRT. In particular, the MSYS2 project now produces packages compiled against UCRT and considers them as the recommended ones: https://www.msys2.org/docs/environments/ Currently, MinGW cross-compilers in Debian produce binaries linked against MSVCRT. It would be nice if there was an easy and supported way of producing binaries linked against UCRT. As I understand it, there are two ways of achieving this: 1. at compile time of src:gcc-mingw-w64, by passing option --with-default-msvcrt=ucrt 2. at runtime, by passing a modified specs file to the cross-compiler (more specifically, replacing -lmsvcrt by -lucrt in the libgcc section) Option 2 already works with the current version of src:gcc-mingw-w64. But it would be better if there was an easier and less tricky way of achieving the same (for example by providing different package flavours; or by providing a specs file explictly designed for that purpose, possibly activated by the alternatives system). Thanks for your work, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1038010: RM: octave-zenity -- ROM; dead upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: octave-zen...@packages.debian.org, debian-oct...@lists.debian.org Control: affects -1 + src:octave-zenity Dear ftpmasters, Please remove octave-zenity. It is dead upstream, the last release was in 2009. It has not been migrated to the new centralized database of Octave addons (https://gnu-octave.github.io/packages/). Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1038008: RM: octave-specfun -- ROM; dead upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: octave-spec...@packages.debian.org, debian-oct...@lists.debian.org Control: affects -1 + src:octave-specfun Dear ftpmasters, Please remove octave-specfun. It is dead upstream, the last release was in 2011. It has not been migrated to the new centralized database of Octave addons (https://gnu-octave.github.io/packages/). Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1038007: RM: octave-missing-functions -- ROM; dead upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: octave-missing-functi...@packages.debian.org, debian-oct...@lists.debian.org Control: affects -1 + src:octave-missing-functions Dear ftpmasters, Please remove octave-missing-functions. It is dead upstream, the last release was in 2009. It has not been migrated to the new centralized database of Octave addons (https://gnu-octave.github.io/packages/). Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#712781: src:scilab: please use SLICOT Debian package instead of embedded copy
Hi Pierre, Le mercredi 24 mai 2023 à 10:45 +0200, Pierre Gruet a écrit : > This is quite an old bug, bu I guess you might still have some interest in it. Thanks for looking into it. > I tried to use the contents of the slicot Debian package instead of the > embedded files in scilab, but I get > > /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to > `zb02mw_' > /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to > `ricdmf_' > /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to > `riccsl_' > /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to > `fstair_' > /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to `polmc_' > /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to > `zb02ow_' > /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to > `zb02mv_' > /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to `ssxmc_' > /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to > `ricdsl_' > /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to `inva_' > /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to > `ereduc_' > /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to > `zb02ox_' > /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to > `riccms_' > /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to > `zb03od_' > > At least some of the missing routines here are defined in > scilab/modules/cacsd/src/slicot/Ex-schur.f > which has no equivalent in the source of the slicot Debian package. > > By looking at the slicot website and at the contents of the Debian package > for slicot, I guess no newer version of slicot should be expected to land > into Debian? The Debian package src:slicot contains a pre-release of version 5.0 of Slicot, which was the last version distributed by upstream under the GPL (later versions are proprietary). However at some point upstream changed their mind and decided to stop distributing the 5.0 release under the GPL, so they removed it from their website. The website now has only has version 4.5 under the GPL. We kept 5.0 in Debian because there is nothing that prevents us from doing so from a legal point of view. Other projects (e.g. the “control” package for Octave) do the same. But it looks like the version of Slicot embedded in Scilab is even older than 4.5, and corresponds to version 4.0. My guess is that the missing symbols that you get correspond to functions that were removed between 4.0 and 5.0. Unfortunately this probably means that fixing the present bug requires more work than just patching the build system (i.e. Scilab upstream needs to move to a more recent Slicot). Best wishes, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1036566: missing LTO plugin
Package: gcc-13
Version: 13.1.0-3
Severity: normal
Dear Maintainer,
When installing the gcc dependency package version 4:13.1.0-1 from
experimental, /usr/lib/bfd-plugins/liblto_plugin.so becomes a dangling symlink.
It looks like /usr/lib/gcc/${DEB_HOST_MULTIARCH}/13/liblto_plugin.so is missing
in gcc-13.
Best wishes,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
Bug#1035438: cl-quicklisp: installation instructions do not work
Le samedi 13 mai 2023 à 04:45 -0400, Michael P. Soulier a écrit : > On 13/05/23 Sébastien Villemot said: > > > Indeed it looks like the recommendation to use “sbcl --script …” is > > incorrect, since SBCL terminates after loading the file, without giving > > access to a REPL from which you could do the installation. > > > > You should follow the other installation option given in the same > > README file, which is to use (load #p"/usr/share/common- > > lisp/source/quicklisp/quicklisp.lisp") in the REPL before running > > (quicklisp-quickstart:install). > > I found that it did not work for me. I had to grab the latest quicklisp from > the > website. I tested it locally and this alternative method works. Can you share the error message you get? -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1035438: cl-quicklisp: installation instructions do not work
Control: severity -1 minor Dear Michael, Le mercredi 03 mai 2023 à 09:23 -0400, Michael P. Soulier a écrit : > Package: cl-quicklisp > Version: 20150128-1 > Severity: grave > Justification: renders package unusable > X-Debbugs-Cc: msoul...@digitaltorque.ca > > Dear Maintainer, > > I followed the instructions in the README > > msoulier@cortado:~$ sbcl --script /usr/share/common- > lisp/source/quicklisp/quicklisp.lisp > > quicklisp quickstart 2015-01-28 loaded > > To continue with installation, evaluate: (quicklisp-quickstart:install) > > For installation options, evaluate: (quicklisp-quickstart:help) > > So I loaded sbcl and ran the command: > > * (quicklisp-quickstart:install) > > debugger invoked on a SB-INT:SIMPLE-READER-PACKAGE-ERROR in thread > #: > Package QUICKLISP-QUICKSTART does not exist. > > So the installation did not make the library available, and it cannot be used. Thanks for your report. Indeed it looks like the recommendation to use “sbcl --script …” is incorrect, since SBCL terminates after loading the file, without giving access to a REPL from which you could do the installation. You should follow the other installation option given in the same README file, which is to use (load #p"/usr/share/common- lisp/source/quicklisp/quicklisp.lisp") in the REPL before running (quicklisp-quickstart:install). Best regards, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1020669: O: geneweb -- genealogy software with web interface
Also note that geneweb 7 requires the “jingoo” and “markup” OCaml libraries, which are currently not packaged in Debian. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
