Bug#1080045: Should octave-tisean be removed from unstable?
Dear Helmut, Le vendredi 30 août 2024 à 07:33 +0200, Helmut Grohne a écrit : > Source: octave-tisean > Severity: serious > Justification: grab attention of maintainer > User: helm...@debian.org > Usertags: sidremove > > Dear maintainer, > > I suggest removing octave-tisean from Debian for the following reasons: > * It accumulated one RC-bug: >+ #874116: octave-tisean FTBFS on !amd64: test failure > Last modified: 2 years > > * It is not part of bookworm or trixie and is not a key package. The Debian Octave Group is ok with the removal. Upstream looks dead, and we don’t really have the time to investigate the unit test failures. So please proceed. 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#1081727: marked as pending in octave-statistics
Control: tag -1 pending Hello, Bug #1081727 in octave-statistics 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/pkg-octave-team/octave-statistics/-/commit/df96aa025443432fdfcbef3f3444935d41cfeba6 test-ClassificationPartitionedModel.patch: new patch Disables tests that randomly enters an infinite loop. Closes: #1081727 Gbp-Dch: Full (this message was generated automatically) -- Greetings https://bugs.debian.org/1081727
Bug#1081727: octave-statistics: Cannot install octave-statistics because of dependency problem:
Control: retitle -1 octave-statistics: FTBFS on several architectures: test timeout Control: tags -1 + ftbfs Control: notfound -1 1.7 Control: found -1 1.7.0-1 Control: forwarded -1 https://github.com/gnu-octave/statistics/issues/160 Dear Matthias, Le samedi 14 septembre 2024 à 10:31 +0200, Matthias Brennwald a écrit : > Package: octave-statistics > Version: 1.7 > Severity: serious > Justification: Cannot use it the package because it cannot be installed. > X-Debbugs-Cc: mbren...@gmail.com > I am trying to install on Debian SID for ARM64: > > Unsatisfied dependencies: > octave-statistics : Depends: octave-statistics-common (= 1.7.0-1) but > 1.6.7-1 is to be installed > > octave-statistics-common is not available in the 1.7 version in the Debian > repositories. The root cause is that the newest version of the package fails to build on several architectures, and this impacts the arch:all -common package. Fixing metadata accordingly. Thanks for your report, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1077977: marked as pending in octave
Control: tag -1 pending Hello, Bug #1077977 in octave 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/pkg-octave-team/octave/-/commit/9ebc88791743960d311c8b4901dd017af397c814 Use the “zero” JVM on archs where the “server” JVM does not exist Closes: #1077977 (this message was generated automatically) -- Greetings https://bugs.debian.org/1077977
Bug#1077977: package assumes that the default JVM is the server VM
Le jeudi 15 août 2024 à 13:31 +0200, Matthias Klose a écrit : > that test is wrong in any case. > call java -client|-zero|-server -version and parse the output This does not seem to be the right test. On amd64, “java -client -version” returns a valid output, but there is no usr/lib/jvm/default-java/lib/client/libjvm.so. The Octave build system needs to be given the directory path where libjvm.so lies. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1077977: package assumes that the default JVM is the server VM
Le jeudi 15 août 2024 à 09:23 +0200, Matthias Klose a écrit : > Control: severity -1 serious > > armel is still a release architecture. Ok, I see, this bug exists because the default JDK has recently been switched to OpenJDK 21, which has a different set of default JVMS. It would have been useful to give that element of context. Also, you did not answer to my question. Thanks, > On 13.08.24 09:56, Sébastien Villemot wrote: > > Control: severity -1 important > > Control: reassign -1 octave 9.2.0-2 > > Control: affects -1 + octave-io > > Control: retitle -1 JVM detection is incorrect on archs where the default > > is the "zero" JVM > > > > Le lundi 05 août 2024 à 13:53 +0200, Matthias Klose a écrit : > > > Package: src:octave-io > > > Version: 2.6.4-3 > > > Severity: serious > > > Tags: sid trixie > > > > > > The package assumes that the default JVM is the server VM. Please don't > > > make such an assumption. > > > > > > Failing autopkg tests on all architectures where zero is the default JVM. > > > > > > [...] > > > 132s autopkgtest [19:09:49]: test xls-poi: [--- > > > 133s Testing POI interface for XLS... > > > 134s error: /usr/lib/jvm/default-java/lib/server/libjvm.so: failed to load > > > 134s Incompatible version or missing dependency? > > > 134s /usr/lib/jvm/default-java/lib/server/libjvm.so: cannot open shared > > > object file: No such file or directory > > > 134s error: called from > > > 134s javaclasspath at line 66 column 16 > > > 134s getinterfaces at line 76 column 11 > > > 134s xlsopen at line 204 column 18 > > > 134s xlsfinfo at line 127 column 7 > > > 134s testhelper at line 12 column 5 > > > > Downgrading the severity because as far as I can tell, this problem > > does not affect any release architecture. On debci, only loong64 seems > > affected. > > > > Also reassigning to octave because this is where the choice of the > > default JVM is done. > > > > Actually there is no assumption that the server JVM is the default one > > on every architecture. There is a test which decides whether to use the > > client or server JVM, see: > > https://salsa.debian.org/pkg-octave-team/octave/-/blob/debian/latest/debian/rules?ref_type=heads#L15 > > > > It seems that this test is not (or no longer) correct. Can you possibly > > tell us what is the correct test to determine the default JVM on a > > given architecture? > > > > 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#1077977: package assumes that the default JVM is the server VM
Control: severity -1 important Control: reassign -1 octave 9.2.0-2 Control: affects -1 + octave-io Control: retitle -1 JVM detection is incorrect on archs where the default is the "zero" JVM Le lundi 05 août 2024 à 13:53 +0200, Matthias Klose a écrit : > Package: src:octave-io > Version: 2.6.4-3 > Severity: serious > Tags: sid trixie > > The package assumes that the default JVM is the server VM. Please don't > make such an assumption. > > Failing autopkg tests on all architectures where zero is the default JVM. > > [...] > 132s autopkgtest [19:09:49]: test xls-poi: [--- > 133s Testing POI interface for XLS... > 134s error: /usr/lib/jvm/default-java/lib/server/libjvm.so: failed to load > 134s Incompatible version or missing dependency? > 134s /usr/lib/jvm/default-java/lib/server/libjvm.so: cannot open shared > object file: No such file or directory > 134s error: called from > 134s javaclasspath at line 66 column 16 > 134s getinterfaces at line 76 column 11 > 134s xlsopen at line 204 column 18 > 134s xlsfinfo at line 127 column 7 > 134s testhelper at line 12 column 5 Downgrading the severity because as far as I can tell, this problem does not affect any release architecture. On debci, only loong64 seems affected. Also reassigning to octave because this is where the choice of the default JVM is done. Actually there is no assumption that the server JVM is the default one on every architecture. There is a test which decides whether to use the client or server JVM, see: https://salsa.debian.org/pkg-octave-team/octave/-/blob/debian/latest/debian/rules?ref_type=heads#L15 It seems that this test is not (or no longer) correct. Can you possibly tell us what is the correct test to determine the default JVM on a given architecture? 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#1069542: marked as pending in octave
Control: tag -1 pending Hello, Bug #1069542 in octave 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/pkg-octave-team/octave/-/commit/ce4450bee4aebd52749576606e5512d5c7854f5f Enable Java on armel, it now works there By the way, update the list of archs which do not have a JDK. Closes: #1069542 Gbp-Dch: Full (this message was generated automatically) -- Greetings https://bugs.debian.org/1069542
Bug#1070013: should not ship with trixie
Source: atlas Version: 3.10.3-14 Severity: serious User: debian-scie...@lists.debian.org Usertags: atlas-rm 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 This bug prevents it from migrating back to testing. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
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#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(&F77M, &F77N, A, &F77lda, tau, work, &F77lwork, &F77info); > |^~~~ > > 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#1065548: marked as pending in octave-statistics
Control: reopen -1 Le mercredi 06 mars 2024 à 17:25 +, Rafael Laboissière a écrit : > Control: tag -1 pending > > Hello, > > Bug #1065548 in octave-statistics 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/pkg-octave-team/octave-statistics/-/commit/5d7e5e9addd6ad613ee6dae349a8551a2a369888 > > > d/rules: Do not FTBFS if empty doc/ directory does not exist > > Closes: #1065548 > The build still fails for arch:any. -- ⢀⣴⠾⠻⢶⣦⠀ 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#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&ver=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#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#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#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#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#1042933: marked as pending in octave-statistics
Control: tag -1 pending Hello, Bug #1042933 in octave-statistics 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/pkg-octave-team/octave-statistics/-/commit/548989993dc2aa7c39380e1dc49f016158875763 test-failures-cameratarget.patch: new patch by Graham Inggs Taken from Ubuntu. Fixes random autopkgtest failures. Closes: #1042933 Gbp-Dch: Full (this message was generated automatically) -- Greetings https://bugs.debian.org/1042933
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#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#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&arch=mips64el&ver=0.3.23%2Bds-2&stamp=1686760279&raw=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#1041460: marked as pending in octave
Control: tag -1 pending Hello, Bug #1041460 in octave 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/pkg-octave-team/octave/-/commit/91bfe75f2babba0c0c37b9e2ff4083fc3c3c4b2c Disable SPQR on 32-bit architectures This is a (hopefully temporary) workaround for the breakage of suitesparse 7 on those architectures. Also add a new suitesparse7-patch2.patch. Closes: #1041460 Gbp-Dch: Full (this message was generated automatically) -- Greetings https://bugs.debian.org/1041460
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#1040130: marked as pending in octave-parallel
Control: tag -1 pending
Hello,
Bug #1040130 in octave-parallel 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/pkg-octave-team/octave-parallel/-/commit/d549d260c437587f1f81d9b8924962181d544918
octave8-part{1,2}.patch: new patches, fix FTBFS against Octave 8
Closes: #1040130
(this message was generated automatically)
--
Greetings
https://bugs.debian.org/1040130
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#1033011: marked as pending in octave
Control: tag -1 pending Hello, Bug #1033011 in octave 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/pkg-octave-team/octave/-/commit/756d8bb0d94d16f4c95f0f4e41bee6d5c433625c d/control: add missing Breaks+Replaces of octave-dev on old liboctave-dev Closes: #1033011 (this message was generated automatically) -- Greetings https://bugs.debian.org/1033011
Bug#1033011: marked as pending in octave
Control: tag -1 pending Hello, Bug #1033011 in octave 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/pkg-octave-team/octave/-/commit/cdb6c2437fb69d0cf86246143c7d08c538f776db d/control: add missing Breaks+Replaces of octave-dev on old liboctave-dev Closes: #1033011 (this message was generated automatically) -- Greetings https://bugs.debian.org/1033011
Bug#1033011: octave-dev: missing Breaks+Replaces against older liboctave-dev
Le mercredi 15 mars 2023 à 17:51 +0100, Sébastien Villemot a écrit : > As a consequence, upgrades from Buster to Bookworm with liboctave-dev > installed can fail I meant from Bullseye 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#1033011: octave-dev: missing Breaks+Replaces against older liboctave-dev
Package: octave-dev Version: 6.3.0-1 Severity: serious liboctave-dev has been renamed octave-dev, but the latter misses a Breaks+Replaces against the former. As a consequence, upgrades from Buster to Bookworm with liboctave-dev installed can fail, because the new octave-dev wants to overwrite files which are provided by the old liboctave-dev. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1012016: libapache-poi-java breaks octave-io autopkgtest: assert (size (d) == [1001, 2]) failed
Control: severity -1 important Le mardi 31 janvier 2023 à 18:09 +0100, Sébastien Villemot a écrit : > Alternatively, I could try to patch octave-io so that it no longer uses > libapache-poi-java for reading XLSX files. That is an inferior > solution, because that will remove an important functionality from the > package, but I may not have the choice. I ended up implementing this “solution” in octave-io 2.4.6-3. So in effect it no longer relies on libapache-poi-java + libxmlbeans-java for reading XLSX files (fortunately octave-io has another, less efficient, backend for reading XLSX files). As a consequence, downgrading the severity of this 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#1012016: libapache-poi-java breaks octave-io autopkgtest: assert (size (d) == [1001, 2]) failed
Le mercredi 28 décembre 2022 à 22:46 +0100, Paul Gevers a écrit : > Control: retitle -1 libapache-poi-java needs updates for newer xmlbeans > > On Fri, 24 Jun 2022 09:54:32 +0200 =?ISO-8859-1?Q?S=E9bastien?= Villemot > wrote: > > octave-io’s upstream > > thinks that the problem comes from an incorrect combination of versions > > between libapache-poi-java and xmlbeans. That seems confirmed by the > > minimal test case that I attached to my previous email (which used to > > work but no longer does, without any indication that the API used > > therein is deprecated). > > So, let's give this bug a (hopefully) better title such that it's > potentially a bit clearer during RC bug triaging for bookworm. Would the > new upstream version solve the issue? My minimal test case works fine if I combine the latest Apache POI (5.2.3) with the latest XMLBeans (5.1.1). So it seems that upgrading these two packages to newer versions in Debian would fix the problem (just upgrading Apache POI to the latest version is not enough, because that version requires a newer XMLBeans than the one currently in Debian). However, I don’t know if it is realistic to expect this to happen for Bookworm, given the stage we’re at in the freeze. I am not familiar enough with this ecosystem to NMU, and the maintainers have been unresponsive so far. Alternatively, I could try to patch octave-io so that it no longer uses libapache-poi-java for reading XLSX files. That is an inferior solution, because that will remove an important functionality from the package, but I may not have the choice. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1027402: overwrites file from libsundials-nvecparallel-mpi4 without declaring proper relationship
Package: libsundials-nvecparallel-mpi6 Version: 6.4.1+dfsg1-2 Severity: serious Dear Maintainer, When upgrading, I got the following dpkg error: Preparing to unpack .../libsundials-nvecparallel-mpi6_6.4.1+dfsg1-2+b1_amd64.deb ... Unpacking libsundials-nvecparallel-mpi6:amd64 (6.4.1+dfsg1-2+b1) ... dpkg: error processing archive /var/cache/apt/archives/libsundials-nvecparallel-mpi6_6.4.1+dfsg1-2+b1_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/libsundials_fnvecmpimanyvector_mod.so.6.4.1', which is also in package libsundials-nvecparallel-mpi4:amd64 6.4.1+dfsg1-1 Errors were encountered while processing: /var/cache/apt/archives/libsundials-nvecparallel-mpi6_6.4.1+dfsg1-2+b1_amd64.deb I guess a Breaks+Replaces relationship is missing. Thanks for your work, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1026055: lapack breaks openturns autopkgtest: undefined reference to `ztrsyl3_' (and 3 more)
Le vendredi 16 décembre 2022 à 13:47 +0100, Jochen Sprickerhof a
écrit :
> Hi Sébastien,
>
> * Sébastien Villemot [2022-12-16 10:30]:
> > Le jeudi 15 décembre 2022 à 21:16 +0100, Paul Gevers a écrit :
> > > On 13-12-2022 21:59, Sébastien Villemot wrote:
> > > > The problem is that atlas needs to be recompiled against lapack 3.11.0.
> > > > Which has been done in atlas 3.10.3-13. But atlas itself cannot migrate
> > > > to testing because of #1025699.
> > >
> > > While I understand recompiling "solves" the issue, normally this error
> > > "undefined reference" hints at removal of symbols. Normally that should
> > > be handled by a SONAME bump which would trigger auto trackers to be
> > > generated for the transition. Such trackers notify the release team of
> > > transitions and they can trigger rebuilds (you know that drill,
> > > including the transition bug filing for coordination). Why do you think
> > > that a SONAME bump wasn't the right solution in this case?
> >
> > Actually the error is not due to a symbol removed, but to a symbol
> > *added*. So no SONAME bump is warranted.
> >
> > Let me explain:
> >
> > In lapack 3.11.0, several new symbols ({z,c,d,s}trsyl3_) were added to
> > liblapack.so.3 (a linear algebra library with a Fortran interface).
> > As a consequence, new wrapper functions around these symbols were also
> > added to liblapacke.so.3 (note the “e”), which is a C wrapper around
> > liblapack.so.3, and which is also shipped by src:lapack. Hence the
> > latest liblapacke.so.3 depends on the new symbols in liblapack.so.3.
> >
> > Now, libatlas3-base (compiled from src:atlas) also provides its own
> > version of liblapack.so.3 (through the alternatives system¹). But,
> > until it is recompiled against lapack 3.11.0, that version of
> > liblapack.so.3 does not contain the new symbols. Hence, when
> > liblapack.so.3 is provided by libatlas3-base, loading liblapacke.so.3
> > produces the error that is seen in the failing test.
> >
> > Essentially, what is missing is a restriction which would forbid the
> > co-installation of liblapacke ⩾ 3.11 and libatlas3-base compiled
> > against lapack < 3.11. I don’t know how to express that using our
> > tooling, but maybe I’m unimaginative.
>
> I think you can get that with a virtual abi package, something like:
>
> Provides: libblas-abi (= 3.11)
>
> And have downstream packages shlibs depend on that virtual package:
>
> override_dh_makeshlibs:
> dh_makeshlibs -plibfoo -V 'libblas-abi (= 3.11)'
> dh_makeshlibs --remaining-packages
>
> Maybe also add a:
>
> Conflicts: libblas-abi (= 3.11)
>
> So only one lib can be installed at the same time and drop the
> alternatives system.
In the current system, in which the BLAS and LAPACK implementation are
decided through the alternatives system, it’s not possible to solve the
problem through versioned provides. Because even if the dependency on
the versioned provides is satisfied, this does not prevent another
flavour of LAPACK (not satisfying the dependency) to be installed and
selected through the alternatives system.
So indeed the only clean way of solving this issue seems to forbid
coinstallability of several BLAS or LAPACK flavours. But the latter is
considered as a feature, not as a bug. I agree that using the
alternatives system for a shared library is a bit ugly and does not
play well with our tooling, but that’s a choice that was made long ago
and it also brings some flexibility for the user (it’s easy to switch
from one implementation to the other).
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
signature.asc
Description: This is a digitally signed message part
Bug#1026055: lapack breaks openturns autopkgtest: undefined reference to `ztrsyl3_' (and 3 more)
Hi Paul,
Le jeudi 15 décembre 2022 à 21:16 +0100, Paul Gevers a écrit :
> On 13-12-2022 21:59, Sébastien Villemot wrote:
> > The problem is that atlas needs to be recompiled against lapack 3.11.0.
> > Which has been done in atlas 3.10.3-13. But atlas itself cannot migrate
> > to testing because of #1025699.
>
> While I understand recompiling "solves" the issue, normally this error
> "undefined reference" hints at removal of symbols. Normally that should
> be handled by a SONAME bump which would trigger auto trackers to be
> generated for the transition. Such trackers notify the release team of
> transitions and they can trigger rebuilds (you know that drill,
> including the transition bug filing for coordination). Why do you think
> that a SONAME bump wasn't the right solution in this case?
Actually the error is not due to a symbol removed, but to a symbol
*added*. So no SONAME bump is warranted.
Let me explain:
In lapack 3.11.0, several new symbols ({z,c,d,s}trsyl3_) were added to
liblapack.so.3 (a linear algebra library with a Fortran interface).
As a consequence, new wrapper functions around these symbols were also
added to liblapacke.so.3 (note the “e”), which is a C wrapper around
liblapack.so.3, and which is also shipped by src:lapack. Hence the
latest liblapacke.so.3 depends on the new symbols in liblapack.so.3.
Now, libatlas3-base (compiled from src:atlas) also provides its own
version of liblapack.so.3 (through the alternatives system¹). But,
until it is recompiled against lapack 3.11.0, that version of
liblapack.so.3 does not contain the new symbols. Hence, when
liblapack.so.3 is provided by libatlas3-base, loading liblapacke.so.3
produces the error that is seen in the failing test.
Essentially, what is missing is a restriction which would forbid the
co-installation of liblapacke ⩾ 3.11 and libatlas3-base compiled
against lapack < 3.11. I don’t know how to express that using our
tooling, but maybe I’m unimaginative.
I hope this clarifies.
Best,
¹ See https://wiki.debian.org/DebianScience/LinearAlgebraLibraries
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
signature.asc
Description: This is a digitally signed message part
Bug#1026055: lapack breaks openturns autopkgtest: undefined reference to `ztrsyl3_' (and 3 more)
Control: block -1 by 1025699 Le mardi 13 décembre 2022 à 21:50 +0100, Paul Gevers a écrit : > Source: lapack, openturns > Control: found -1 lapack/3.11.0-2 > Control: found -1 openturns/1.20-5 > Severity: serious > Tags: sid bookworm > User: debian...@lists.debian.org > Usertags: breaks needs-update > > With a recent upload of lapack the autopkgtest of openturns fails in > testing when that autopkgtest is run with the binary packages of lapack > from unstable. It passes when run with only packages from testing. In > tabular form: > > passfail > lapack from testing3.11.0-2 > openturns from testing1.20-5 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. > > Currently this regression is blocking the migration of lapack to testing > [1]. Due to the nature of this issue, I filed this bug report against > both packages. Can you please investigate the situation and reassign the > bug to the right package? Thanks Paul. The problem is that atlas needs to be recompiled against lapack 3.11.0. Which has been done in atlas 3.10.3-13. But atlas itself cannot migrate to testing because of #1025699. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1025699: autopkgtest fails on armel against atlas 3.10.3-13
Source: scipy Version: 1.8.1-14 Severity: serious Control: affects -1 atlas Dear Maintainer, Since the upload of atlas 3.10.3-13 to unstable, the autopkgtest of scipy fails on armel. See: https://ci.debian.net/data/autopkgtest/testing/armel/s/scipy/29064436/log.gz More precisely, a test in sparse/linalg/_eigen/tests/test_svds.py fails because the error is now slightly above tolerance. Simply increasing the tolerance should fix the problem. Note that the only numerically significant change in 3.10.3-13 was the rebuild against lapack 3.11, hence the latter is probably the real cause of the problem (though it may also be a change in the toolchain). In particular, note that this issue transitively prevents lapack 3.11 from migrating to testing/bookworm. Incidentally, you should be aware that atlas has not seen a stable major upstream since 2016; it has also been superseded by better alternatives like OpenBLAS and BLIS; I’m therefore considering its possible removal during the trixie development cycle. Thanks for your work, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1017829: elpa-ess: emacs-gtk 28.1 install fails with installed elpa-ess
Le vendredi 14 octobre 2022 à 13:33 -0500, Dirk Eddelbuettel a écrit : > On 14 October 2022 at 20:10, Sébastien Villemot wrote: > > Le dimanche 21 août 2022 à 09:17 -0500, Dirk Eddelbuettel a écrit : > > > That is a problem, and it is somewhat know. ESS used to release every > > > six or > > > so months, now we are many years behind with no official release. Your > > > best > > > bet may be to install directly from melpa and removing the package. > > > > > > I will bring this to the ESS list but last time this was brought up > > > everybody > > > more or less agreed but no release tarball was made because "it's > > > complicated". > > > > Would you be willing to consider shipping a snapshot of the git > > repository (as is available on MELPA)? This would be a temporary > > solution until upstream finally makes a formal release. Otherwise it > > looks like ESS will not be part of bookworm… > > Correct. > > See https://stat.ethz.ch/pipermail/ess-help/2022-September/thread.html > and _many_ earlier threads over the years bemoaning (in more polite words) > the irritating stale mate among that team and the inability to make a release > for four years now. (Mailmain archives are a pain to search but you know how > to condition a search engine to a site etc.) > > > Shipping a git snapshot is established practice in Debian, especially > > for situations like the present one. > > > > I am willing to help if needed. > > I don't actually speak (e)lisp so I cannot help, and I have no appetite > getting into issues with upstream. > > If you want to take over the package, I would welcome that and happily pass > it on to you. I was care taker for a while, but it may be time to pass that > torch on. Thank you for your feedback, and for the good work you put into this package over the years! I’m going to take it over as you suggest. Amicalement, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1017829: elpa-ess: emacs-gtk 28.1 install fails with installed elpa-ess
Hi Dirk! Le dimanche 21 août 2022 à 09:17 -0500, Dirk Eddelbuettel a écrit : > That is a problem, and it is somewhat know. ESS used to release every six or > so months, now we are many years behind with no official release. Your best > bet may be to install directly from melpa and removing the package. > > I will bring this to the ESS list but last time this was brought up everybody > more or less agreed but no release tarball was made because "it's > complicated". Would you be willing to consider shipping a snapshot of the git repository (as is available on MELPA)? This would be a temporary solution until upstream finally makes a formal release. Otherwise it looks like ESS will not be part of bookworm… Shipping a git snapshot is established practice in Debian, especially for situations like the present one. I am willing to help if needed. 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#1012917: marked as pending in dynare
Control: tag -1 pending Hello, Bug #1012917 in dynare 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/pkg-octave-team/dynare/-/commit/7579336bd207f6cdbe9923e57c47ace5f7942050 gcc-12.patch: new patch, fixes FTBFS against GCC 12 Closes: #1012917 (this message was generated automatically) -- Greetings https://bugs.debian.org/1012917
Bug#1012016: libapache-poi-java breaks octave-io autopkgtest: assert (size (d) == [1001, 2]) failed
Control: reassign libapache-poi-java 4.0.1-4 Le mardi 07 juin 2022 à 16:45 +0200, Sébastien Villemot a écrit : > Le samedi 28 mai 2022 à 21:28 +0200, Paul Gevers a écrit : > > Source: libapache-poi-java, octave-io > > Control: found -1 libapache-poi-java/4.0.1-4 > > Control: found -1 octave-io/2.6.4-1 > > Severity: serious > > Tags: sid bookworm > > User: debian...@lists.debian.org > > Usertags: breaks needs-update > > > With a recent upload of libapache-poi-java the autopkgtest of octave-io > > fails in testing when that autopkgtest is run with the binary packages > > of libapache-poi-java from unstable. It passes when run with only > > packages from testing. > > First note that the only change between libapache-poi-java 4.0.1-3 and > 4.0.1-4 is the upgrade to xmlbeans 4.0.0. > > Attached is a minimal test case that reproduces what octave-io does in > its autopkgtest. I’m reassigning this issue to libapache-poi-java. octave-io’s upstream thinks that the problem comes from an incorrect combination of versions between libapache-poi-java and xmlbeans. That seems confirmed by the minimal test case that I attached to my previous email (which used to work but no longer does, without any indication that the API used therein is deprecated). -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1012016: libapache-poi-java breaks octave-io autopkgtest: assert (size (d) == [1001, 2]) failed
Hi,
Le samedi 28 mai 2022 à 21:28 +0200, Paul Gevers a écrit :
> Source: libapache-poi-java, octave-io
> Control: found -1 libapache-poi-java/4.0.1-4
> Control: found -1 octave-io/2.6.4-1
> Severity: serious
> Tags: sid bookworm
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
> With a recent upload of libapache-poi-java the autopkgtest of octave-io
> fails in testing when that autopkgtest is run with the binary packages
> of libapache-poi-java from unstable. It passes when run with only
> packages from testing.
First note that the only change between libapache-poi-java 4.0.1-3 and
4.0.1-4 is the upgrade to xmlbeans 4.0.0.
Attached is a minimal test case that reproduces what octave-io does in
its autopkgtest.
Before running it, you should put the following file in your current
directory:
https://salsa.debian.org/pkg-octave-team/octave-io/-/blob/debian/latest/debian/tests/test.xlsx
The example can be run with:
java -cp
/usr/share/java/poi.jar:/usr/share/java/poi-ooxml.jar:/usr/share/java/commons-compress.jar:/usr/share/java/commons-collections4.jar:/usr/share/java/xmlbeans.jar
bug1012016.java
This example works fine with libapache-poi-java 4.0.1-3 and
libxmlbeans-java 3.0.2-1. But it crashes with libapache-poi-java 4.0.1-
4 and libxmlbeans-java 4.0.0-1 (currently in unstable).
The relevant part seems to be:
Caused by: java.lang.ClassNotFoundException:
org.apache.xmlbeans.metadata.system.s036263A03D2D3FD117889707DB51207A.TypeSystemHolder
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
... 31 more
My Java skills are limited so I cannot make further debugging. Could
some Java expert chime in?
P.S.: Why was libapache-poi-java 4.0.1-4 allowed to migrate to testing?
Autopkgtest regressions are supposed to be blockers for testing
migration.
Cheers,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
import java.io.*;
import org.apache.poi.ss.usermodel.*;
public class Main {
public static void main(String[] args) throws FileNotFoundException, IOException {
InputStream xlsin = new FileInputStream("test.xlsx");
Workbook wb = WorkbookFactory.create(xlsin);
}
}
signature.asc
Description: This is a digitally signed message part
Bug#1010164: fails autopkgtest against Octave 7
Package: octave-bart Version: 0.7.00-2 Severity: serious Tags: patch Control: block 1009865 by -1 Dear Maintainer, The autopkgtest for octave-bart fails against octave 7.1.0-2 recently uploaded to unstable. See: https://ci.debian.net/data/autopkgtest/testing/amd64/b/bart/21135046/log.gz The problem comes from a message that is printed to stderr: error: ignoring const execution_exception& while preparing to exit This message only appears when running the autopkgtest in a dedicated chroot as done on the DebCI infrastructure. I wasn’t able to reproduce it in other contexts, and I could not figure out what causes it. Since this message is essentially harmless, and given that the test passes otherwise, I would suggest to simply add the “allow-stderr” keyword to “Restrictions” in the octave-integration stanza of debian/tests/control. Thanks for your work, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1009183: FTBFS in sid: “Error: The configuration option 'pages' was removed from MkDocs”
Source: nlopt Version: 2.7.1-3 Severity: serious Tags: ftbfs Dear Maintainer, nlopt currently fails to build in sid. A build log is attached. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org nlopt_2.7.1-3_amd64-2022-04-08T12:00:38Z.build.gz Description: application/gzip
Bug#1003020: openblas breaks hypre autopkgtest on armhf: test times out after 2:47h
Hi, Le dimanche 02 janvier 2022 à 21:19 +0100, Paul Gevers a écrit : > Source: openblas, hypre > Control: found -1 openblas/0.3.19+ds-1 > Control: found -1 hypre/2.22.1-3 > Severity: serious > Tags: sid bookworm > X-Debbugs-CC: debian...@lists.debian.org > User: debian...@lists.debian.org > Usertags: breaks needs-update > > With a recent upload of openblas the autopkgtest of hypre fails in > testing when that autopkgtest is run with the binary packages of > openblas from unstable on armhf due to a timeout after 2:47 h. It passes > when run with only packages from testing in about 9-12 minutes. In > tabular form: > > passfail > openblas from testing0.3.19+ds-1 > hypre from testing2.22.1-3 > all others from testingfrom testing > > I copied some of the output at the bottom of this report, but as the > test times out, I suspect it just hangs and there's not much useful to see. > > Currently this regression is blocking the migration of openblas 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? First note that there has been no change to the ARM32-specific code of openblas between 0.3.18+ds-1 and 0.3.19+ds-1. Also, I tried to replicate the problem on a porterbox (abel), but the autopkgtest succeeds (with hypre 2.22.1-3 and openblas 0.3.19+ds-2, in an armhf chroot): Running tests for HYPRE testing began at Fri Jan 14 13:24:29 UTC 2022 running TEST_ams ... ok test TEST_ams for HYPRE completed in 54 s skipping TEST_bench skipping TEST_examples running TEST_fac ... ok test TEST_fac for HYPRE completed in 106 s skipping TEST_fei running TEST_ij ... ok test TEST_ij for HYPRE completed in 256 s running TEST_lobpcg ... ok test TEST_lobpcg for HYPRE completed in 116 s running TEST_longdouble ... ok test TEST_longdouble for HYPRE completed in 136 s running TEST_single ... ok test TEST_single for HYPRE completed in 78 s running TEST_sstruct ... ok test TEST_sstruct for HYPRE completed in 271 s running TEST_struct ... ok test TEST_struct for HYPRE completed in 186 s running TEST_superlu ... ok test TEST_superlu for HYPRE completed in 58 s skipping TEST_timing all tests for HYPRE completed at Fri Jan 14 13:45:30 UTC 2022 in 1261s So at this point I don’t know how to tackle this issue. Drew, any idea? 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#995846: FTBFS: Fatal TYPE-ERROR and tests incompatible with PG14
Le vendredi 10 décembre 2021 à 10:27 +0100, Sébastien Villemot a écrit : > > The problem seems again related to cl-esrap. I noticed that the Debian > package tracks an old (dead) upstream, while there is a new alive fork. > I’ll take over that package and hopefully fix the problem. I’ve uploaded a new cl-esrap. It seems pgloader builds again. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#995846: FTBFS: Fatal TYPE-ERROR and tests incompatible with PG14
Le jeudi 09 décembre 2021 à 16:10 +0100, Christoph Berg a écrit :
> Re: To Sébastien Villemot
> > Unfortunately, pgloader still doesn't compile:
>
> > While evaluating the form starting at line 21, column 0
> > of
> > #P"/srv/projects/postgresql/pgloader/pgloader/dumper-2SKVI5f7.lisp":Fatal
> > SIMPLE-ERROR:
> > Compilation failed: * is not permitted as an argument to the FUNCTION
> > type specifier in /usr/share/common-lisp/source/esrap/src/evaluator.lisp
>
> Looking around for something else I discovered #999625 in cl-esrap
> which fixes this problem. I uploaded the fix in an NMU. (I guess you
> might also take over that package?)
>
> But pgloader still doesn't build: :(
>
> ; wrote
> /srv/projects/postgresql/pgloader/pgloader/debian/home/.cache/common-lisp/sbcl-2.1.11.debian-linux-x64/usr/share/common-lisp/source/abnf/abnf-tmp5FHTGX61.fasl
> ; compilation finished in 0:00:00.080
> While evaluating the form starting at line 21, column 0
> of
> #P"/srv/projects/postgresql/pgloader/pgloader/dumper-2SKVI5f7.lisp":Fatal
> TYPE-ERROR:
> The values
> (# :IN
>
> "/srv/projects/postgresql/pgloader/pgloader/debian/home/.cache/common-lisp/sbcl-2.1.11.debian-linux-x64/usr/share/common-lisp/source/abnf/abnf.fasl")
> {53C1EADB}>
> NIL NIL)
>
> are not of type
> (VALUES FUNCTION &OPTIONAL)
The problem seems again related to cl-esrap. I noticed that the Debian
package tracks an old (dead) upstream, while there is a new alive fork.
I’ll take over that package and hopefully fix the problem.
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
signature.asc
Description: This is a digitally signed message part
Bug#1001447: missing Depends on cl-esrap and cl-ppcre
Package: cl-abnf Version: 20150608-1.1 Severity: serious Tags: patch The subject says it all. The abnf system requires the esrap and cl-ppcre systems, but this is not reflected at the level of Debian dependencies. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#995846: FTBFS: Fatal TYPE-ERROR and tests incompatible with PG14
Le mardi 02 novembre 2021 à 17:07 +0100, Christoph Berg a écrit : > Re: Sébastien Villemot > > I am going to package cl-uax-15 and cl-global-vars (ITPs are marked as > > blocking the present bug), and then upgrade cl-postmodern. > > That sounds excellent, merci! The updated cl-postmodern just entered unstable. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#998541: marked as pending in dynare
Control: tag -1 pending Hello, Bug #998541 in dynare 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/pkg-octave-team/dynare/-/commit/111c6dae6ea4add5dcdb61b4b6b07b1b591b8923 sphinx4.patch: new patch, fixes FTBFS against sphinx 4 Closes: #998541 (this message was generated automatically) -- Greetings https://bugs.debian.org/998541
Bug#995846: FTBFS: Fatal TYPE-ERROR and tests incompatible with PG14
Hi Christoph, Le mercredi 06 octobre 2021 à 23:14 +0200, Christoph Berg a écrit : > Package: pgloader > Version: 3.6.2-1 > Severity: grave > Tags: ftbfs > > pgloader is currently not supporting PG14's new default of scram > authentication: > > https://ci.debian.net/data/autopkgtest/testing/amd64/p/pgloader/15809976/log.gz > > KABOOM! > FATAL error: Failed to connect to pgsql at "localhost" (port 5433) as user > "postgres": 10 fell through ECASE expression. Wanted one of (0 2 3 4 5 6 7 8). > Date/time: 2021-10-06-16:12! > An unhandled error condition has been signalled: >Failed to connect to pgsql at "localhost" (port 5433) as user "postgres": > 10 fell through ECASE expression. Wanted one of (0 2 3 4 5 6 7 8). > > To fix this, cl-postmodern needs upgrading, but the new version > requires (at least) the yet-unpackaged "uax-15" and "global-vars" CL > modules. I am going to package cl-uax-15 and cl-global-vars (ITPs are marked as blocking the present bug), and then upgrade cl-postmodern. 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#994457: r-cran-gnm autopkgtest needs to be adapted for lapack 3.10
Dear Heather, Please find attached the patch that I am going to apply to r-cran-gnm in Debian. With this patch applied, the test now works with both lapack 3.9 and 3.10. Feel free to use it (or not) for the next release of gnm. Best wishes, Le lundi 27 septembre 2021 à 12:01 +0100, Heather Turner a écrit : > Hi Andreas, > > Thanks for forwarding this bug report and thanks to Sébastien for the > detailed and accurate analysis. I will need to submit an update to CRAN, > which should be feasible in the next week or two. Is there a deadline that I > need to work to? > > Best wishes, > > Heather > > On Mon, Sep 27, 2021, at 10:12 AM, Andreas Tille wrote: > > Control: tags -1 upstream > > Control: forwarded -1 Heather Turner > > > > Hi Heather, > > > > the Debian packaged gnm recieved a bug report about a failing test in > > connection with the upgrade to lapack 3.10.0 on the machine running the > > test. Please read the bug report below. > > > > We admit we need your help to solve this issue that might affect > > other systems as well. > > > > Kind regards > > > > Andreas. > > > > On Thu, Sep 16, 2021 at 10:59:19AM +0200, Sébastien Villemot wrote: > > > Package: r-cran-gnm > > > Version: 1.1-1-2 > > > Severity: serious > > > Tags: sid bookworm > > > X-Debbugs-CC: debian...@lists.debian.org > > > User: debian...@lists.debian.org > > > Usertags: needs-update > > > > > > Dear Maintainer, > > > > > > Since the upload of lapack 3.10.0-1, the autopkgtest of r-cran-gnm > > > fails in unstable. See for example: > > > https://ci.debian.net/data/autopkgtest/unstable/amd64/r/r-cran-gnm/15155026/log.gz > > > > > > More precisely, test-biplot.R fails, because some results have the > > > opposite sign compared to the one which is expected. > > > > > > My understanding is that this comes from the SVD of barleyMatrix in > > > that test file, which is different between lapack 3.9 and 3.10. > > > Mathematically, the SVD is not unique, and lapack 3.10 returns a > > > different (still valid) solution. More precisely, I verified that one > > > of the right-singular vector of that matrix has the opposite sign in > > > lapack 3.10. I also verified that the decomposition is correct by > > > checking that: > > > > > > max(abs(barleySVD$u %*% diag(barleySVD$d) %*% t(barleySVD$v) - > > > barleyMatrix)) > > > > > > is a small value (about 2e-14). > > > > > > Also note that the hardcoded expected values already partially differ > > > from those of the original research paper mentioned in that test > > > (Gabriel (1998): Generalised bilinear regression). More precisely, half > > > of the values were hardcoded with the opposite sign. It seems that now > > > all values need to be hardcoded with the opposite sign. > > > > > > The testsuite of r-cran-gnm thus needs to be adapted, by being more > > > tolerant to such sign changes. > > > > > > N.B. : when trying to reproduce the problem, please ensure that your > > > lapack alternative (as given by “update-alternatives --display > > > liblapack.so.3-x86_64-linux-gnu) points to /usr/lib/x86_64-linux- > > > gnu/lapack/liblapack.so.3, and not to the binary provided by either > > > openblas or atlas (because these two have not yet been recompiled > > > against lapack 3.10, and thus do not expose the problem). > > > > > > Best regards, > > > > > > -- > > > ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot > > > ⣾⠁⢠⠒⠀⣿⡁ Debian Developer > > > ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name > > > ⠈⠳⣄ https://www.debian.org > > > > > > > > > > > > ___ > > > R-pkg-team mailing list > > > r-pkg-t...@alioth-lists.debian.net > > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team > > > > > > -- > > http://fam-tille.de -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org Description: Fix test-biplot.R with lapack 3.10 With lapack 3.10, test-biplot.R fails, because some results have the opposite sign compared to the one which is expected. . This comes from the SVD of barleyMatrix in that test file, which is different between lapack 3.9 and 3.10. Mathematically, the SVD is not unique, and lapack 3.10 returns a different (still valid) solution. . This
Bug#994475: wannier90 autopkgtest needs to be adapted for lapack 3.10
Package: wannier90 Version: 3.1.0+ds-4 Severity: serious Tags: sid bookworm X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: needs-update Dear Maintainer, Since the upload of lapack 3.10.0-1, the autopkgtest of wannier90 fails in unstable. See for example: https://ci.debian.net/data/autopkgtest/testing/amd64/w/wannier90/15283094/log.gz It seems that it’s only a matter of slightly increasing a test tolerance, most likely because some lapack algorithm is now implemented in a different way. However, if you think that this is a bug in lapack, feel free to reassign it, ideally with the details of your analysis. N.B. : when trying to reproduce the problem, please ensure that your lapack alternative (as given by “update-alternatives --display liblapack.so.3-x86_64-linux-gnu) points to /usr/lib/x86_64-linux- gnu/lapack/liblapack.so.3, and not to the binary provided by either openblas or atlas (because these two have not yet been recompiled against lapack 3.10, and thus do not expose the problem). 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#994457: r-cran-gnm autopkgtest needs to be adapted for lapack 3.10
Package: r-cran-gnm Version: 1.1-1-2 Severity: serious Tags: sid bookworm X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: needs-update Dear Maintainer, Since the upload of lapack 3.10.0-1, the autopkgtest of r-cran-gnm fails in unstable. See for example: https://ci.debian.net/data/autopkgtest/unstable/amd64/r/r-cran-gnm/15155026/log.gz More precisely, test-biplot.R fails, because some results have the opposite sign compared to the one which is expected. My understanding is that this comes from the SVD of barleyMatrix in that test file, which is different between lapack 3.9 and 3.10. Mathematically, the SVD is not unique, and lapack 3.10 returns a different (still valid) solution. More precisely, I verified that one of the right-singular vector of that matrix has the opposite sign in lapack 3.10. I also verified that the decomposition is correct by checking that: max(abs(barleySVD$u %*% diag(barleySVD$d) %*% t(barleySVD$v) - barleyMatrix)) is a small value (about 2e-14). Also note that the hardcoded expected values already partially differ from those of the original research paper mentioned in that test (Gabriel (1998): Generalised bilinear regression). More precisely, half of the values were hardcoded with the opposite sign. It seems that now all values need to be hardcoded with the opposite sign. The testsuite of r-cran-gnm thus needs to be adapted, by being more tolerant to such sign changes. N.B. : when trying to reproduce the problem, please ensure that your lapack alternative (as given by “update-alternatives --display liblapack.so.3-x86_64-linux-gnu) points to /usr/lib/x86_64-linux- gnu/lapack/liblapack.so.3, and not to the binary provided by either openblas or atlas (because these two have not yet been recompiled against lapack 3.10, and thus do not expose the problem). 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#994241: ruby-lapack autopkgtest needs to be adapted for LAPACK 3.10
Package: ruby-lapack
Version: 1.8.1-1
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: needs-update
Dear Maintainer,
Since the upload of lapack 3.10.0-1, the autopkgtest of ruby-lapack
fails in unstable. See for example:
https://ci.debian.net/data/autopkgtest/unstable/amd64/r/ruby-lapack/15155031/log.gz
More precisely, the tests about generalized singular value
decomposition (GSVD) fail.
Mathematically, the GSVD does not have a unique solution. For some
reason, lapack 3.10 now returns a different (still valid) solution, but
the ruby-lapack testsuite hardcodes another, specific, solution.
Please find attached a Fortran 2008 source code through which I
verified that the decomposition given by both lapack 3.9 and 3.10 is
valid, though the Q matrix is different between the two versions. The
code needs to be compiled with gfortran, and linked against -llapack. I
verified only the double float decomposition (dggsvd), but the single
float decomposition test (sggsvd) most likely fails for the same
reason.
The testsuite of ruby-lapack thus needs to be adapted, by allowing
alternative solutions (either accept both the old and the new
solutions, or completely rethink the test by only verifying the the
decomposition is valid as I did in my program).
N.B. : when trying to reproduce the problem, please ensure that your
lapack alternative (as given by “update-alternatives --display
liblapack.so.3-x86_64-linux-gnu) points to /usr/lib/x86_64-linux-
gnu/lapack/liblapack.so.3, and not to the binary provided by either
openblas or atlas (because these two have not yet been recompiled
against lapack 3.10, and thus do not expose the problem).
Best regards,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
program ggsvd
use iso_fortran_env
implicit none
interface
subroutine dggsvd(jobu, jobv, jobq, m, n, p, k, l, a, lda, b, &
ldb, alpha, beta, u, ldu, v, ldv, q, ldq, work, &
iwork, info)
import :: real64
real(real64), dimension(*), intent(inout) :: a, b
real(real64), dimension(*), intent(out) :: alpha, beta, q, u, v, work
character, intent(in) :: jobq, jobu, jobv
integer, intent(in) :: lda, ldb, ldq, ldu, ldv, m, n, p
integer, intent(out) :: info, k, l
integer, dimension(*), intent(out) :: iwork
end subroutine dggsvd
end interface
real(real64) :: a(4,3), b(2,3), alpha(3), beta(3), u(4,4), v(2,2), q(3,3),
work(12), d1(4,3), d2(2,3), a_bak(4,3), b_bak(2,3)
integer :: info, k, l, iwork(3)
a = reshape(source = [ real(real64) :: 1., 3., 4., 7., 2., 2., 5., 8., 3.,
1., 6., 8. ], shape = [4,3])
b = reshape(source = [ real(real64) :: -2., 4., -3., 6., 3., 5. ], shape = [
2, 3 ])
print '("A=",/,4(3es12.4,:,/))', transpose(a)
print '("B=",/,2(3es12.4,:,/))', transpose(b)
a_bak = a
b_bak = b
call dggsvd("U", "V", "Q", 4, 3, 2, k, l, a, 4, b, 2, alpha, beta, u, 4, v,
2, q, 3, work, iwork, info)
print '("U=",/,4(4es12.4,:,/))', transpose(u)
print '("V=",/,2(2es12.4,:,/))', transpose(v)
print '("Q=",/,3(3es12.4,:,/))', transpose(q)
print '("k=",i1)', k
print '("l=",i1)', l
if (k /= 1) stop "k is incorrect"
if (l /= 2) stop "l is incorrect"
! We are in the case where M-K-L>0
! Also note that N-K-L=0
d1 = 0._real64
d1(1,1) = 1._real64
d1(2,2) = alpha(2)
d1(3,3) = alpha(3)
d2 = 0._real64
d2(1,2) = beta(2)
d2(2,3) = beta(3)
associate (r => a(1:3,1:3))
associate (a2 => matmul(u, matmul(d1, matmul(r, transpose(q, &
b2 => matmul(v, matmul(d2, matmul(r, transpose(q)
print '("Error on reconstructed A: ", es12.4)', maxval(abs(a_bak-a2))
print '("Error on reconstructed B: ", es12.4)', maxval(abs(b_bak-b2))
end associate
end associate
end program ggsvd
signature.asc
Description: This is a digitally signed message part
Bug#993338: octave: Setting up octave fails due to missing libGL.so.1
Control: reassign -1 dpkg 1.20.9 Dear Witold, Le dimanche 12 septembre 2021 à 15:24 +, Witold Baryluk a écrit : > Package: octave > Version: 6.2.0-1 > Followup-For: Bug #993338 > X-Debbugs-Cc: witold.bary...@gmail.com > > After a lof of trial and error and minimizing my package list from ~7000 > to just few, I got it easily reproducible using live-build. It is somehow > related to multiarch. > > Here and attached below is a script that should reproduce the issue. It > uses /tmp-live-build as a scratch space, so be sure to clean it after. > (I cannot use /tmp as it often has nodev / nosuid set). > > I am also attaching compressed output log from the script and live-build, > as well the apt / dpkg logs from inside the target chroot. Thanks for sending a way of reproducing the problem. I have no idea what’s going on. But it seems clear to me that the bug is not in octave. I’m reassign to dpkg, for lack of a better idea, in the hope that its maintainer can give some guidance. 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#993338: octave: Setting up octave fails due to missing libGL.so.1
Le lundi 30 août 2021 à 22:32 +, Witold Baryluk a écrit : > Package: octave > Version: 6.2.0-1 > Severity: serious > Justification: Policy 3.5 > X-Debbugs-Cc: witold.bary...@gmail.com > > Dear Maintainer, > > when debootstrapping using live-build: > > Setting up octave (6.2.0-1) ... > /usr/bin/octave-cli: error while loading shared libraries: libGL.so.1: cannot > open shared object file: No such file or directory > dpkg: error processing package octave (--configure): > installed octave package post-installation script subprocess returned error > exit status 127 > > > Mesa is installed later by apt. Pre-Depends maybe required? Also weird a > bit that octave-cli requires OpenGL. Policy §6.5 is clear about the fact that, when the postinst script is called, dependencies are unpacked and configured (unless there are circular dependencies, which I don’t think is the case here). So if libgl1 is really unpacked after octave is configured, the bug probably lies in dpkg. Do you have a way of reproducing the problem? -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#986240: make-guile: broken symlink: /usr/bin/gmake -> /make
Control: tags -1 + patch pending Dear Maintainer, On Thu, 01 Apr 2021 12:59:16 +0200 Andreas Beckmann wrote: > Package: make-guile > Version: 4.3-4 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > during a test with piuparts I noticed your package ships (or creates) > a broken symlink. > > From the attached log (scroll to the bottom...): > > 0m14.7s ERROR: FAIL: Broken symlinks: > /usr/share/man/man1/gmake.1.gz -> /make.1.gz (make-guile) > /usr/bin/gmake -> /make (make-guile) I have uploaded to DELAYED/2 a fix for this bug. Don’t hesitate to tell me if I should delay it longer. The debdiff is attached. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org diff -u make-dfsg-4.3/debian/changelog make-dfsg-4.3/debian/changelog --- make-dfsg-4.3/debian/changelog +++ make-dfsg-4.3/debian/changelog @@ -1,3 +1,11 @@ +make-dfsg (4.3-4.1) unstable; urgency=medium + + * Non-maintainer upload. + * make-guile: fix broken symlinks /usr/bin/gmake and +/usr/share/man/man1/gmake.1.gz. (Closes: #986240) + + -- Sébastien Villemot Sat, 10 Apr 2021 15:55:15 +0200 + make-dfsg (4.3-4) unstable; urgency=high * Cherry picked [SV 58232] Disable inheritance of jobserver FDs for diff -u make-dfsg-4.3/debian/make-guile.links make-dfsg-4.3/debian/make-guile.links --- make-dfsg-4.3/debian/make-guile.links +++ make-dfsg-4.3/debian/make-guile.links @@ -1,2 +1,2 @@ -make usr/bin/gmake -make.1.gz usr/share/man/man1/gmake.1.gz +usr/bin/make usr/bin/gmake +usr/share/man/man1/make.1.gz usr/share/man/man1/gmake.1.gz signature.asc Description: This is a digitally signed message part
Bug#985524: iso2mesh-tools: broken symlink: /usr/bin/tetgen1.5 -> tetgen
Le vendredi 02 avril 2021 à 14:56 -0400, Qianqian Fang a écrit : > On 4/2/21 9:26 AM, Sébastien Villemot wrote: > > Thanks for looking at this issue. > > > > I don’t think that creating those symlinks in iso2mesh-tools is the > > right solution. Such symlinks should only be created by the tetgen > > package, otherwise this only creates confusion over package > > boundaries. > > > > I think the right solution is to drop the symlinks, and rather to > > create a Debian-specific patch that replaces “tetgen1.5” with > > “tetgen” in brain2mesh.m. > > understood. I agree patching brain2mesh and other related demo > scripts is a better solution than the symbolic link, however, > iso2mesh has been used by other widely distributed tools, like > brainstorm, fieldtrip etc, and I am afraid that dropping this link > can lead to broken scripts (unless all upstream codes are patched). Note that I’m not suggesting that you patch the code upstream at this stage. Only that you modify the code shipped by Debian. > can we upload this temporary fix for now, and I will add a fall-back > mechanism (in mcpath.m) in the next release of iso2mesh? once that is > added, I will remove the symbolic link. I still think that the symlink is the wrong solution. Nevertheless, in the context of the freeze, the ultimate decision will be taken by the Release Team members, who will decide to unblock (or not) your proposed fix. I therefore suggest that you submit a so-called “pre-approval” unblock request, so that we know their decision. If it is positive, then I will make the upload. For instructions on unblock requests, see: https://release.debian.org/bullseye/freeze_policy.html#appropriate (you should explicitly say in your bug report that this is a “pre- approval” unblock request) 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#985524: iso2mesh-tools: broken symlink: /usr/bin/tetgen1.5 -> tetgen
Le vendredi 02 avril 2021 à 09:16 -0400, Qianqian Fang a écrit : > On 4/2/21 5:19 AM, Sébastien Villemot wrote: > > > But are those symlinks really needed in the first place? I could not find a > > place in the package where “tetgen1.5” is called (with the version number > > as a suffix). Only “tetgen” seems to be called. But maybe am I missing > > something. > > > we noticed that the mesh output are not reproducible across different > versions of tetgen. They also behave differently - some crash for > certain input, some don't. therefore, in iso2mesh, we embedded different > versions of iso2mesh and allow users to specifically choose using a flag > in several core functions. > > Because debian only provides tetgen1.5 as tetgen, to allow some existing > scripts/demos to run (at least), for example, in the octave-brain2mesh > package > > https://salsa.debian.org/pkg-octave-team/octave-brain2mesh/-/blob/master/brain2mesh.m#L205 > > > I need to create the tetgen1.5 link. > > let me know if there is a better solution. Thanks for looking at this issue. I don’t think that creating those symlinks in iso2mesh-tools is the right solution. Such symlinks should only be created by the tetgen package, otherwise this only creates confusion over package boundaries. I think the right solution is to drop the symlinks, and rather to create a Debian-specific patch that replaces “tetgen1.5” with “tetgen” in brain2mesh.m. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#985524: iso2mesh-tools: broken symlink: /usr/bin/tetgen1.5 -> tetgen
Hi Qianqian, Le vendredi 19 mars 2021 à 12:53 +0100, Andreas Beckmann a écrit : > Package: iso2mesh-tools > Version: 1.9.6+ds-5 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > during a test with piuparts I noticed your package ships (or creates) > a broken symlink. > > From the attached log (scroll to the bottom...): > > 0m23.8s ERROR: FAIL: Broken symlinks: > /usr/share/man/man1/tetgen1.5.1.gz -> tetgen.1.gz (iso2mesh-tools) > /usr/bin/tetgen1.5 -> tetgen (iso2mesh-tools) Can you please clarify the situation regarding the above bug? As I understand it, /usr/bin/tetgen and its corresponding manpage are provided by the tetgen package, which is *not* a dependency of iso2mesh-tools. So there are installation scenarios where those symlinks may be dangling. Hence the release critical bug. But are those symlinks really needed in the first place? I could not find a place in the package where “tetgen1.5” is called (with the version number as a suffix). Only “tetgen” seems to be called. But maybe am I missing something. 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#985282: dnsmasq: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE
Control: tags -1 + patch pending Dear Maintainer, On Mon, 15 Mar 2021 13:19:07 +0100 Andreas Beckmann wrote: > Package: dnsmasq > Version: 2.84-1 > Severity: serious > User: debian...@lists.debian.org > an upgrade test with piuparts revealed that your package installs files > over existing symlinks and possibly overwrites files owned by other > packages. This usually means an old version of the package shipped a > symlink but that was later replaced by a real (and non-empty) > directory. This kind of overwriting another package's files cannot be > detected by dpkg. > > This was observed on the following upgrade paths: > > buster -> bullseye I have prepared an NMU fixing this bug, versioned 2.84-1.1, and uploaded it to DELAYED/2. Please tell me if I should delay it longer. The debdiff is attached. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org diff -u dnsmasq-2.84/debian/changelog dnsmasq-2.84/debian/changelog --- dnsmasq-2.84/debian/changelog +++ dnsmasq-2.84/debian/changelog @@ -1,3 +1,13 @@ +dnsmasq (2.84-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix symlink to directory conversion for /usr/share/doc/dnsmasq. +This is achieved by directly calling dpkg-maintscript-helper in the preinst, +postinst, and postrm scripts, since the package does not use debhelper. +(Closes: #985282) + + -- Sébastien Villemot Sun, 28 Mar 2021 10:55:07 +0200 + dnsmasq (2.84-1) unstable; urgency=low * New upstream. diff -u dnsmasq-2.84/debian/postinst dnsmasq-2.84/debian/postinst --- dnsmasq-2.84/debian/postinst +++ dnsmasq-2.84/debian/postinst @@ -1,6 +1,9 @@ #!/bin/sh set -e +# /usr/share/doc/dnsmasq was a symlink in versions < 2.81-1 (see #985282) +dpkg-maintscript-helper symlink_to_dir /usr/share/doc/dnsmasq dnsmasq-base 2.81-1~ dnsmasq -- "$@" + # Code copied from dh_systemd_enable -- # This will only remove masks created by d-s-h on package removal. deb-systemd-helper unmask dnsmasq.service >/dev/null || true diff -u dnsmasq-2.84/debian/postrm dnsmasq-2.84/debian/postrm --- dnsmasq-2.84/debian/postrm +++ dnsmasq-2.84/debian/postrm @@ -1,6 +1,9 @@ #!/bin/sh set -e +# /usr/share/doc/dnsmasq was a symlink in versions < 2.81-1 (see #985282) +dpkg-maintscript-helper symlink_to_dir /usr/share/doc/dnsmasq dnsmasq-base 2.81-1~ dnsmasq -- "$@" + if [ purge = "$1" ]; then update-rc.d dnsmasq remove >/dev/null fi diff -u dnsmasq-2.84/debian/rules dnsmasq-2.84/debian/rules --- dnsmasq-2.84/debian/rules +++ dnsmasq-2.84/debian/rules @@ -176,7 +176,7 @@ -d debian/trees/daemon/usr/lib/tmpfiles.d \ -d debian/trees/daemon/etc/insserv.conf.d install -m 644 debian/conffiles debian/trees/daemon/DEBIAN - install -m 755 debian/postinst debian/postrm debian/prerm debian/trees/daemon/DEBIAN + install -m 755 debian/postinst debian/postrm debian/preinst debian/prerm debian/trees/daemon/DEBIAN if ! dpkg-vendor --derives-from Ubuntu; then \ rm -f debian/dnsmasq.postinst.debhelper debian/dnsmasq.postrm.debhelper; \ dh_runit -pdnsmasq -Pdebian/trees/daemon; \ only in patch2: unchanged: --- dnsmasq-2.84.orig/debian/preinst +++ dnsmasq-2.84/debian/preinst @@ -0,0 +1,5 @@ +#!/bin/sh +set -e + +# /usr/share/doc/dnsmasq was a symlink in versions < 2.81-1 (see #985282) +dpkg-maintscript-helper symlink_to_dir /usr/share/doc/dnsmasq dnsmasq-base 2.81-1~ dnsmasq -- "$@" signature.asc Description: This is a digitally signed message part
Bug#977012: octave-level-set FTBFS with Octave 6.1.0: error: ‘const class Array’ has no member named ‘length’
Le jeudi 10 décembre 2020 à 04:39 +0200, Adrian Bunk a écrit :
> Source: octave-level-set
> Version: 0.3.0-11
> Severity: serious
> Tags: ftbfs
I attach a patch that fixes the compilation of the source code (some
functions were deprecated). But then there is a failure in the tests,
which I don’t understand (maybe another regression in Octave core?).
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
--- a/src/geomGamma.cpp
+++ b/src/geomGamma.cpp
@@ -192,7 +192,7 @@ DEFUN_DLD (__levelset_geomGamma, args, n
const Matrix inout = args(4).matrix_value ();
/* Extract and check the dimensions. */
- const unsigned nNodes = phi.nelem ();
+ const unsigned nNodes = phi.numel ();
const unsigned nElem = getDimension (nodelist, -1, 4);
const unsigned nBdryEl = getDimension (bdryInd, -1, 1);
getDimension (edges, nBdryEl, 4);
--- a/src/internal_mesh.cpp
+++ b/src/internal_mesh.cpp
@@ -300,7 +300,7 @@ getInnerSegment (const octave_scalar_map
assert (innerPts.empty ());
const ColumnVector inners = segs.contents ("inners").column_vector_value ();
- const unsigned nInners = inners.nelem ();
+ const unsigned nInners = inners.numel ();
for (unsigned i = 0; i < nInners; ++i)
innerPts.push_back (inners(nInners - i - 1) - 1);
}
@@ -387,7 +387,7 @@ DEFUN_DLD (__levelset_internal_mesh, arg
{
const unsigned cur = bdryElems(i) - 1;
const Cell cellSegs = bdryelSegs(i).cell_value ();
- const unsigned nSegs = cellSegs.nelem ();
+ const unsigned nSegs = cellSegs.numel ();
std::vector segs;
indexArr endEdges;
--- a/src/internal_fastmarching.cpp
+++ b/src/internal_fastmarching.cpp
@@ -74,7 +74,7 @@ DEFUN_DLD (__levelset_internal_fastmarch
{
const Array idx = getOctaveIdx (c);
assert (c.size () == D
- && static_cast (idx.length ()) == D);
+ && static_cast (idx.numel ()) == D);
if (domain(idx))
{
@@ -99,7 +99,7 @@ DEFUN_DLD (__levelset_internal_fastmarch
{
const Array idx = getOctaveIdx (c);
assert (c.size () == D
- && static_cast (idx.length ()) == D);
+ && static_cast (idx.numel ()) == D);
const Grid& constGrid(grid);
const Entry* e = constGrid.get (c);
signature.asc
Description: This is a digitally signed message part
Bug#977013: marked as pending in octave-communications
Control: tag -1 pending Hello, Bug #977013 in octave-communications 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/pkg-octave-team/octave-communications/-/commit/d3522a7848460795d2b0e5fb7970ea1eb99dc313 Add epstool to Build-Depends Closes: #977013 (this message was generated automatically) -- Greetings https://bugs.debian.org/977013
Bug#977010: marked as pending in octave-optim
Control: tag -1 pending Hello, Bug #977010 in octave-optim 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/pkg-octave-team/octave-optim/-/commit/61589a30783902cf5fbee63891ff95647ecfd464 octave6.patch: new patch, fixes FTBFS against octave 6 Closes: #977010 (this message was generated automatically) -- Greetings https://bugs.debian.org/977010
Bug#976501: marked as pending in dynare
Control: tag -1 pending Hello, Bug #976501 in dynare 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/pkg-octave-team/dynare/-/commit/6f9de9502ef29cb35636c929f7e08eef5b7df2a4 texlive-20201203.patch: new patch, fixes FTBFS against texlive-base ≥ 20201203 Closes: #976501 (this message was generated automatically) -- Greetings https://bugs.debian.org/976501
Bug#976198: FTBFS on i386: Build killed with signal TERM after 150 minutes of inactivity
Package: src:octave-image Version: 2.12.0-5 Severity: serious Tags: ftbfs octave-image 2.12.0-5 FTBFS on i386. I tried a giveback but it gave the same outcome. See: https://buildd.debian.org/status/fetch.php?pkg=octave-image&arch=i386&ver=2.12.0-5&stamp=1606751200&raw=0 -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org
Bug#971902: Don't upload scilab
Control: tags -1 + pending Le vendredi 20 novembre 2020 à 10:46 +0100, Julien Puydt a écrit : > please push your commit but don't upload : > > - I'll report upstream and forward your patch ; > > - I'll take the occasion to do some little things on the package, so > I'll upload when I'll be done (probably before next monday). Ok, I’ve pushed the patch. 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#917485: ckermit: relax openssl version check or tighten libssl1.x.y dependencies
Control: notfound -1 305~alpha02-1 Control: close -1 Hi Paul, There was no need to reopen this bug. The metadata was correct. The bug was fixed by a patch in 302-5.3+deb9u1. The reintroduction of the package, even if it no longer contains the patch, did not reintroduce the bug, because upstream fixed it in another way: the dynamic check against the version of OpenSSL has been improved, in the sense that it accept changes in the patchlevel version (e.g. if the package was compiled against OpenSSL 1.1.0, the dynamic check will allow execution against 1.1.1, since there is ABI stability). Closing again and fixing versions accordingly. 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#970820: missing bid_functions.h header
Package: libintelrdfpmath-dev Version: 2.0u2-2 Severity: serious Dear Maintainer, The bid_functions.h header is not included in the package. This header is required when compiling a program against the library. In particular, it defines the BID_UINT32, BID_UINT64 and BID_UINT128 types, and declares the prototypes of most functions. Thanks for your work, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org
Bug#963646: marked as pending in dynare
Control: tag -1 pending Hello, Bug #963646 in dynare 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/pkg-octave-team/dynare/-/commit/d839037429d19f7fa37e42cf17c715933db48ff7 sphinx3.patch: new patch, fixes FTBFS against Sphinx 3.1 Closes: #963646 (this message was generated automatically) -- Greetings https://bugs.debian.org/963646
Bug#963036: marked as pending in octave-symbolic
Control: tag -1 pending Hello, Bug #963036 in octave-symbolic 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/pkg-octave-team/octave-symbolic/-/commit/90a88e7b3feb9097c938fc5c34b5b70823658f7e sympy-1.6.patch: new patch, fixes FTBFS against SymPy 1.6 A temporary (build-)dependency on python3-six has been added to make the patch work. Closes: #963036 Thanks: Georges Khaznadar onx (this message was generated automatically) -- Greetings https://bugs.debian.org/963036
Bug#963036: Wild guess to fix this bug
Dear Georges, Le jeudi 18 juin 2020 à 18:12 +0200, Georges Khaznadar a écrit : > Dear maintainer(s) of octave-symbolic, here is a wild guess, inspired by > a simple remark: > > 8< > $ python3 -c "import six; print(six.integer_types)" (,) > $ python2 -c "import six; print(six.integer_types)" (, 'long'>) > 8< > > Would it be enough to patch octave-symbolic source, to replace > 'sympy.core.compatibility.integer_types' by 'six.integer_types' ? Thanks for this suggestion. This seems to fix this issue (a similar fix is needed for string_types). Then there are five test failures (over more than 2,000 tests) that I don’t know how to fix. I’ve temporarily disabled those test to facilitate the migration. Hopefully upstream will soon provide a real fix. 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#961725: libopenblas-dev: On some cpus, openmp and pthread dead-lock
Hi Dirk, Le jeudi 28 mai 2020 à 07:07 -0500, Dirk Eddelbuettel a écrit : > Package: libopenblas-dev > Version: 0.3.8+ds-1 > Severity: serious > In short, when libopenblas-dev is installed (as e.g. from r-base-dev as a > dependency from libblas-dev, liblapack-dev) then > > libopenblas0-pthread > > is installed first via our depends ranking as libopenblas-pthread-dev comes > first. > > This has served us well over the years but can exhibit a bug which I for > example saw with (Ubuntun's) 0.3.8+ds-1 package. Running a simple > > example(solve) > > in R hangs in an unsuspendable session (ie no Ctrl-C, kill is needed). > Simplest test is on the command-line via > > $ Rscript -e 'example(solve)' > > Removing libopenbkas0-pthread and installing libopenblas-openmp-dev helps. As > does a manual reordering of the alternatives. > > This bug is reproducible on my system with a i7-8700k. I’ve tried to reproduce it on my i7-8700K, without success. I used a clean sid chroot (with r-base 4.0.0-3 and openblas 0.3.9+ds-1). Downgrading to openblas 0.3.8+ds-1 (which is the version against which you reported the bug) does not change anything. So it’s not clear that this bug is tied to a specific hardware. At least, a given CPU model is not a guarantee of reproducibility. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#959535: closing 959535
close 959535 4.0.0-2 thanks Tests disabled at build time, since they canât be run without having the package installed. Tests are still run by autopkgtests. -- â¢â£´â ¾â »â¢¶â£¦â Sébastien Villemot ⣾â ⢠â â ⣿⡠Debian Developer ⢿â¡â â ·â â â http://sebastien.villemot.name â â ³â£â â â â http://www.debian.org
Bug#953367: geneweb-gui binary package might need to be removed for Bullseye
Le mercredi 08 avril 2020 à 08:10 -0400, Guillaume Brochu a écrit : > As I can see, lablgtk2 should be repaired soon: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885677#95 > > My understanding is that geneweb-gui does not depend on the problematic > component (gtksourceview2) of lablgtk2. > > So I propose to wait for this fix. Then, I might need your help if there are > some manual operations to do in order to bring back geneweb in testing. > > As I can also see, this bug (953367) is now tagged as an "issues preventing > migration", which was not my intent. > https://tracker.debian.org/pkg/geneweb geneweb has been removed from testing and cannot migrate back because this bug (#953367) is of severity serious. geneweb will automatically migrate back to testing when this bug is fixed (or, alternatively, if it is downgraded to a lesser severity). 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#953367: geneweb-gui binary package might need to be removed for Bullseye
Dear Guillaume, Le dimanche 08 mars 2020 à 11:54 -0400, Guillaume Brochu a écrit : > Package: geneweb-gui > Version: 6.08+git20181019+dfsg-2 > Severity: serious > X-Debbugs-CC: sebast...@debian.org > > geneweb-gui binary package might need to be removed for Bullseye, for > the two following reasons: As you may have seen, geneweb has been removed from testing because of this bug. Isn’t it the time for dropping the geneweb-gui package, so that geneweb can get back into testing? 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#948458: marked as pending in octave-symbolic
Control: tag -1 pending Hello, Bug #948458 in octave-symbolic 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/pkg-octave-team/octave-symbolic/commit/bc5a6dae3cf2b0ee69b9203c57c440bdf448253f sympy-1.5.patch: new patch, fixes testsuite against SymPy 1.5 Closes: #948458 (this message was generated automatically) -- Greetings https://bugs.debian.org/948458
Bug#941742: FTBFS against Octave 5
Package: src:pfstools Version: 2.1.0-4 Severity: serious Tags: patch ftbfs Control: block 934630 by -1 Dear Maintainer, The Octave 5 transition has started, and pfstools FTBFS against the new version. The failure comes from the fact that mkoctfile now passes -Werror=format-security. I’m going to create a merge request on salsa with a proposed patch (once I have the bug number), just adding -Wno-error=format-security on the mkoctfile command line. Please tell me whether it’s ok for me to NMU, or if you want to fix this issue yourself. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org
Bug#939807: sbcl build-depends on package that is cruft in unstable and gone in testing.
Hi Steve, Le mardi 01 octobre 2019 à 14:58 -0700, Steve Langasek a écrit : > Package: sbcl > Followup-For: Bug #939807 > User: ubuntu-de...@lists.ubuntu.com > > Usertags: origin-ubuntu eoan ubuntu-patch > > Dear maintainers, > > Attached is a straightforward patch for this issue. Note that this issue had already been fixed in Debian. It looks like sbcl in Ubuntu is out-of-sync. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#931795: sbcl: FTBFS with gcc-9, uses deprecated armv5 target on armhf
Control: notforwarded -1 Dear Gianfranco, Le mercredi 10 juillet 2019 à 15:43 +0200, Gianfranco Costamagna a écrit : > Source: sbcl > Version: 2:1.5.4-1 > Severity: serious > Justification: uses non-optimized code > Tags: patch > Forwarded: > https://github.com/sbcl/sbcl/pull/34 Thanks for the report. Just one thing: upstream repository is not on github (you submitted your pull request against a mirror). Bug reports should be sent to Launchpad: https://bugs.launchpad.net/sbcl/ Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#928130: marked as pending in octave-control
Control: tag -1 pending Hello, Bug #928130 in octave-control 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/pkg-octave-team/octave-control/commit/d67e86413e8dde4aab1ddea44bc5dc16be286501 comment-out-failing-unit-tests.patch: add more tests from ltimodels.m Closes: #928130 (this message was generated automatically) -- Greetings https://bugs.debian.org/928130
Bug#926047: marked as pending in octave
Control: tag -1 pending Hello, Bug #926047 in octave 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/pkg-octave-team/octave/commit/58abc9e0f348c30b95af99710ba1c692717cd7dc d/copyright: add entry for etc/fonts/* Closes: #926047 (this message was generated automatically) -- Greetings https://bugs.debian.org/926047
Bug#926047: marked as pending in octave
Control: tag -1 pending Hello, Bug #926047 in octave 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/pkg-octave-team/octave/commit/57584a053eda0f7b3231a474fe52493ac4a3373d d/copyright: add entry for etc/fonts/* Note that currently we hit a bug in libconfig-model-dpkg-perl, see #928597. Closes: #926047 (this message was generated automatically) -- Greetings https://bugs.debian.org/926047
Bug#927007: libopenblas-base: Disable TLS (thread-local storage) to work around #903514
Le samedi 13 avril 2019 à 13:10 +0200, Niels Thykier a écrit : > Source: openblas > Severity: serious > User: release.debian@packages.debian.org > Usertags: buster-is-blocker > > Hi, > > Please disable the usage of TLS (thread-local storage) to work around > #903514 (deadlocks in glibc with TLS) for now. TLS is already disabled in openblas, as I explained in message #124 of bug #903514: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903514#124 Or did the issue reappear in some other way that I missed? -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#923715: ceph-osd: missing systemd service in package: ceph-volume@.service
tags 923715 + patch user debian-rele...@lists.debian.org usertags 923715 + bsp-2019-03-fr-paris thank you I submitted a merge request with a fix: https://salsa.debian.org/ceph-team/ceph/merge_requests/1/ I am not familiar enough with the package to test it properly, so I’d prefer is someone else could review it before uploading. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#884033: scilab segfaults building scilab-{ann,celestlab,plotlib}
affects 884033 - src:scilab-plotlib src:scilab-celestlab src:scilab-ann
block 884033 by 907607
reassign 884033 src:scilab-celestlab 3.0.0-1-2
tags 884033 + sid
retitle 884033 src:scilab-celestlab: FTBFS, scilab hangs
clone 884033 -1
reassign -1 src:scilab-ann 0.4.2.4-1
retitle -1 src:scilab-ann: FTBFS, scilab hangs
thanks
Actually scilab-{ann,celestlab} now FTBFS due to scilab hanging in
console mode (see #907607).
Reaffecting to the two affected packages and updating the metadata.
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name
⠈⠳⣄ http://www.debian.org
signature.asc
Description: This is a digitally signed message part
Bug#924844: thin-provisioning-tools: FTBFS: ft-lib/bcache.c:35:13: error: conflicting types for 'raise'
user debian-rele...@lists.debian.org
usertags 924844 + bsp-2019-03-fr-paris
tags 924844 + ftbfs patch pending
thank you
Dear Maintainers,
On Sun, 17 Mar 2019 19:01:41 +0100 Lucas Nussbaum wrote:
> Source: thin-provisioning-tools
> Version: 0.7.6-2
> Severity: serious
> Justification: FTBFS in buster on amd64
I am about to NMU a fix for that bug. The debdiff is attached.
Note that I did not submit a merge request to salsa since:
1) the Vcs-Git field points to a different location
2) I am not familiar with your git workflow (where the quilt patches
are applied on the master branch)
Cheers,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name
⠈⠳⣄ http://www.debian.org
diff -Nru thin-provisioning-tools-0.7.6/debian/changelog thin-provisioning-tools-0.7.6/debian/changelog
--- thin-provisioning-tools-0.7.6/debian/changelog 2019-01-13 12:42:46.0 +0100
+++ thin-provisioning-tools-0.7.6/debian/changelog 2019-03-31 11:35:25.0 +0200
@@ -1,3 +1,13 @@
+thin-provisioning-tools (0.7.6-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * 0002-fix-FTBFS-against-libaio-0.3.112.patch: new patch, renames
+static raise() function in ft-lib/bcache.c to avoid symbol conflict
+with raise() from signal.h
+(Closes: #924844)
+
+ -- Sébastien Villemot Sun, 31 Mar 2019 11:35:25 +0200
+
thin-provisioning-tools (0.7.6-2) unstable; urgency=medium
* Fix prototype for open in test preload wrapper. (closes: #893557)
diff -Nru thin-provisioning-tools-0.7.6/debian/patches/0002-fix-FTBFS-against-libaio-0.3.112.patch thin-provisioning-tools-0.7.6/debian/patches/0002-fix-FTBFS-against-libaio-0.3.112.patch
--- thin-provisioning-tools-0.7.6/debian/patches/0002-fix-FTBFS-against-libaio-0.3.112.patch 1970-01-01 01:00:00.0 +0100
+++ thin-provisioning-tools-0.7.6/debian/patches/0002-fix-FTBFS-against-libaio-0.3.112.patch 2019-03-31 11:35:25.0 +0200
@@ -0,0 +1,86 @@
+Description: Fix FTBFS against libaio 0.3.112
+ Since version 0.3.112, libaio.h includes signal.h, which conflicts with the
+ (static) raise() function in ft-lib/bcache.c. This patch renames the latter
+ to fix the conflict.
+Author: Sébastien Villemot
+Bug-Debian: https://bugs.debian.org/924844
+Forwarded: no
+Last-Update: 2019-03-31
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/ft-lib/bcache.c
b/ft-lib/bcache.c
+@@ -32,7 +32,7 @@ static void warn(const char *fmt, ...)
+ }
+
+ // FIXME: raise a condition somehow?
+-static void raise(const char *fmt, ...)
++static void raise_condition(const char *fmt, ...)
+ {
+ va_list ap;
+
+@@ -52,7 +52,7 @@ static inline struct list_head *list_pop
+ struct list_head *l;
+
+ if (head->next == head)
+- raise("list is empty\n");
++ raise_condition("list is empty\n");
+
+ l = head->next;
+ list_del(l);
+@@ -99,7 +99,7 @@ static struct cb_set *cb_set_create(unsi
+ static void cb_set_destroy(struct cb_set *cbs)
+ {
+ if (!list_empty(&cbs->allocated))
+- raise("async io still in flight");
++ raise_condition("async io still in flight");
+
+ free(cbs->vec);
+ free(cbs);
+@@ -714,13 +714,13 @@ struct bcache *bcache_simple(const char
+ uint64_t s;
+
+ if (fd < 0) {
+- raise("couldn't open cache file");
++ raise_condition("couldn't open cache file");
+ return NULL;
+ }
+
+ r = fstat(fd, &info);
+ if (r < 0) {
+- raise("couldn't stat cache file");
++ raise_condition("couldn't stat cache file");
+ return NULL;
+ }
+
+@@ -752,9 +752,9 @@ void bcache_destroy(struct bcache *cache
+ static void check_index(struct bcache *cache, block_address index)
+ {
+ if (index >= cache->nr_data_blocks)
+- raise("block out of bounds (%llu >= %llu)",
+- (unsigned long long) index,
+- (unsigned long long) cache->nr_data_blocks);
++ raise_condition("block out of bounds (%llu >= %llu)",
++(unsigned long long) index,
++(unsigned long long) cache->nr_data_blocks);
+ }
+
+ uint64_t get_nr_blocks(struct bcache *cache)
+@@ -803,7 +803,7 @@ static struct block *lookup_or_read_bloc
+ // FIXME: this is insufficient. We need to also catch a read
+ // lock of a write locked block. Ref count needs to distinguish.
+ if (b->ref_count && (flags & (GF_DIRTY | GF_ZERO)))
+- raise("concurrent write lock attempt");
++ raise_condition("concurrent write lock attempt");
+
+ if (test_flags(b, BF_IO_PENDING)) {
+ miss(cache, flags);
+@@ -859,7 +859,7 @@ struct block *get_block(struct bcache *c
+ return b;
+ }
+
+- raise("couldn't get block");
++ raise_condition("couldn't get block");
+ return NULL;
+ }
+
diff -Nru thin-provisioning-too
Bug#919481: Fix for RC #919481
retitle 919481 guile-2.0: FTBFS when fr_FR.ISO-8859-1 locale is installed user debian-rele...@lists.debian.org usertags 919481 + bsp-2019-03-fr-paris thank you Dear Maintainer, I am about to NMU guile-2.0 using Frédéric's patch. The debdiff is attached. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org diff -Nru guile-2.0-2.0.13+1/debian/changelog guile-2.0-2.0.13+1/debian/changelog --- guile-2.0-2.0.13+1/debian/changelog 2017-12-05 08:41:29.0 +0100 +++ guile-2.0-2.0.13+1/debian/changelog 2019-03-30 19:24:44.0 +0100 @@ -1,3 +1,12 @@ +guile-2.0 (2.0.13+1-5.1) unstable; urgency=medium + + * Non-maintainer upload. + * 0005-fix-french-locale-test.patch: new patch by Frédéric Bonnard. +Fixes FTBFS when locale fr_FR.ISO-8859-1 is installed. +(Closes: #919481) + + -- Sébastien Villemot Sat, 30 Mar 2019 19:24:44 +0100 + guile-2.0 (2.0.13+1-5) unstable; urgency=medium * Add upstream 0004-ia64-Fix-crash-in-thread-context-switch.patch to diff -Nru guile-2.0-2.0.13+1/debian/patches/0005-fix-french-locale-test.patch guile-2.0-2.0.13+1/debian/patches/0005-fix-french-locale-test.patch --- guile-2.0-2.0.13+1/debian/patches/0005-fix-french-locale-test.patch 1970-01-01 01:00:00.0 +0100 +++ guile-2.0-2.0.13+1/debian/patches/0005-fix-french-locale-test.patch 2019-03-30 19:24:22.0 +0100 @@ -0,0 +1,65 @@ +Description: Fix French locale test + In i18n tests, some test fail because of non-breaking spaces not being + matched. The tests convert values to strings in fr_FR.iso88591 which insert a + "locale-thousands-separator" which, in this locale, is a non-breaking space. + This string is compared to the hardcoded expected result which contains a + standard space (UTF8 hex. 20). As the file is UTF8, this patch replaces the bad + space with the UTF8 non-breaking space equivalent (hex. C2 A0). +Author: Frédéric Bonnard +Bug-Debian: https://bugs.debian.org/919481 +Forwarded: no +Reviewed-By: Sébastien Villemot +Last-Updated: 2019-03-30 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +Index: guile-2.0-2.0.13+1/test-suite/tests/i18n.test +=== +--- guile-2.0-2.0.13+1.orig/test-suite/tests/i18n.test 2016-10-22 22:09:34.0 +0200 guile-2.0-2.0.13+1/test-suite/tests/i18n.test 2019-03-19 13:36:43.022766801 +0100 +@@ -514,19 +514,19 @@ + (under-french-locale-or-unresolved +(lambda () + (let ((fr (make-locale LC_ALL %french-locale-name))) +- (string=? "123 456" (number->locale-string 123456 #t fr)) ++ (string=? "123 456" (number->locale-string 123456 #t fr)) + + (pass-if "fraction" + (under-french-locale-or-unresolved +(lambda () + (let ((fr (make-locale LC_ALL %french-locale-name))) +- (string=? "1 234,567" (number->locale-string 1234.567 #t fr)) ++ (string=? "1 234,567" (number->locale-string 1234.567 #t fr)) + + (pass-if "fraction, 1 digit" + (under-french-locale-or-unresolved +(lambda () + (let ((fr (make-locale LC_ALL %french-locale-name))) +- (string=? "1 234,5" ++ (string=? "1 234,5" + (number->locale-string 1234.567 1 fr + + (with-test-prefix "format ~h" +@@ -542,7 +542,7 @@ +(lambda () + (if (null? (locale-digit-grouping %french-locale)) + (throw 'unresolved) +- (string=? "12 345,6789" ++ (string=? "12 345,6789" +(format #f "~:h" 12345.6789 %french-locale))) + + (with-test-prefix "English" +@@ -564,12 +564,12 @@ + (under-french-locale-or-unresolved +(lambda () + (let ((fr (make-locale LC_ALL %french-locale-name))) +- (string=? "123 456 +EUR" ++ (string=? "123 456 +EUR" + (monetary-amount->locale-string 123456 #f fr)) + + (pass-if "fraction" + (under-french-locale-or-unresolved +(lambda () + (let ((fr (make-locale LC_ALL %french-locale-name))) +- (string=? "1 234,56 EUR " ++ (string=? "1 234,56 EUR " + (monetary-amount->locale-string 1234.567 #t fr diff -Nru guile-2.0-2.0.13+1/debian/patches/series guile-2.0-2.0.13+1/debian/patches/series --- guile-2.0-2.0.13+1/debian/patches/series 2017-12-05 08:30:59.0 +0100 +++ guile-2.0-2.0.13+1/debian/patches/series 2019-03-30 19:21:50.0 +0100 @@ -2,3 +2,4 @@ 0002-Look-for-guile-procedures.txt-in-pkglibdir.patch 0003-tests-Avoid-race-condition-in-REPL-server-test.patch 0004-ia64-Fix-crash-in-thread-context-switch.patch +0005-fix-french-locale-test.patch signature.asc Description: This is a digitally signed message part
Bug#864827: zotero-standalone: ask for removal?
Le mercredi 13 mars 2019 à 14:08 +0100, Félix Sipma a écrit : > It may be time to ask for removal... What do you think? Indeed. I have filed the removal request (see #926033). -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://seb astien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#924232: python{,3}-notebook: unhandled symlink to directory conversion: /usr/lib/python{2.7,3}/dist-packages/notebook/static/components/bootstrap
user debian-rele...@lists.debian.org usertags 924232 + bsp-2019-03-fr-paris tags 924232 + patch pending thank you Dear Maintainer, I am about to NMU a fix this bug. I submitted a merge request corresponding to the contents of the upload: https://salsa.debian.org/python-team/modules/jupyter-notebook/merge_requests/1/ Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://seb astien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#884033: scilab segfaults building scilab-{ann,celestlab,plotlib}
As agreed with jcristau at Paris BSP, the plan is to remove scilab-
celestlab from buster (the other two, scilab-{ann,plotlib}, are not in
buster either), and then to tag this bug as buster-ignore.
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ http://seb
astien.villemot.name
⠈⠳⣄ http://www.debian.org
signature.asc
Description: This is a digitally signed message part
Bug#925618: Bug #925618 in octave-fits marked as pending
Control: tag -1 pending Hello, Bug #925618 in octave-fits 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/pkg-octave-team/octave-fits/commit/73b1cace484cdceb344acc2c4922ef99cc17c8b3 Add missing Build-Depends on pkg-config Closes: #925618 (this message was generated automatically) -- Greetings https://bugs.debian.org/925618
Bug#925618: Working on it
user debian-rele...@lists.debian.org usertags -1 + bsp-2019-03-fr-paris thank you -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://seb astien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#864827: Whither Zotero 5?
Le vendredi 29 mars 2019 à 01:23 -0400, Borden Rhodes a écrit : > On Sun, 24 Mar 2019 17:47:38 +0100 =?ISO-8859-1?Q?S=E9bastien?= > Villemot wrote: > > The main reason is lack of manpower (a lot of work in the > > Javascript > > packages need to happen first). > > Thank you for the explanation. Is there a to-do list or some > elaboration on the work that needs to be done? Please see the discussion in bug #871502. If you are interested in adopting Zotero, please make your intentions known relatively soon (by converting bug #907928 into an ITA, as explained in the Developers Reference). I intend to request the removal of Zotero from Debian in the near future if nobody is interested in adopting it (note that it does not prevent somebody from reintroducing it later). -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
