Bug#1071613: octave-dev: Inconsistent behavior of %!error and mexErrMsgIdAndTxt on different architectures

[Rafael Laboissière]

Package: octave-dev
Version: 9.1.0-3
Severity: normal
Tags: upstream
Control: forwarded -1 https://savannah.gnu.org/bugs/?65767
Control: block 1069477 by -1

Hi,

A bug has been reported in the upstream bug system for Octave [1], 
with all the details, concerning a possible problem related to the 
compilation of MEX files. This problem probably causes the FTBFS of 
octave-stk (Bug#1069477 [2]).

Best,

Rafael Laboissière

 [1] https://savannah.gnu.org/bugs/?65767
 [2] https://bugs.debian.org/1069477

Bug#1071499: RM: octave-fits -- ROM; dead upstream, does not compile against Octave 9

[Rafael Laboissière]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: octave-f...@packages.debian.org
Control: affects -1 + src:octave-fits
User: ftp.debian@packages.debian.org
Usertags: remove

Please remove octave-zenity.

It is dead upstream, the last release was in 2015.  It FTBFS against 
Octave 9, the version which will soon migrate into testing.

This package has been superseded by the Octave-Forge cfitsio package. We, 
the Debian Octave Group, are planing to package it for Debian in the 
near future.

Thanks, 
 
Rafael Laboissière

Bug#1070994: src:praat: fails to migrate to testing for too long: FTBFS on arm64, armel, armhf, ppc64el and riscv64

[Rafael Laboissière]

I just realize that I forgot the "Control:" header in my previous 
message.


At any rate, after verifying that the package builds correctly in a armhf 
chroot on abel.debian.org, I gave back the build on the armhf 
autobuilders and the package did not FTBFS this time.


Best,

Rafael Laboissière

* Rafael Laboissière  [2024-05-15 06:48]:


reopen -1 found -1 6.4.12+dfsg-3

I partially fixed Bug#1070994 in version 6.4.12+dfsg-3. Indeed, this 
version correctly builds on arm64, armel, ppc64el, and riscv64. 
However, build on armhf fails for an unrelated reason. I am currently 
investigating this. I am hereby reopen the bug report.


Best,

Rafael

* Paul Gevers  [2024-05-12 18:51]:


Source: praat
Version: 6.4.05+dfsg-1
Severity: serious
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between 
testing and unstable for more than 30 days as having a Release 
Critical bug in testing [1]. Your package src:praat has been trying 
to migrate for 74 days [2]. Hence, I am filing this bug. The version 
in unstabled failed to build on most architectures where it build 
before.


If a package is out of sync between unstable and testing for a 
longer period, this usually means that bugs in the package in 
testing cannot be fixed via unstable. Additionally, blocked packages 
can have impact on other packages, which makes preparing for the 
release more difficult. Finally, it often exposes issues with the 
package and/or its (reverse-)dependencies. We expect maintainers to 
fix issues that hamper the migration of their package in a timely 
manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is 
auto-removed.


I have immediately closed this bug with the version in unstable, so 
if that version or a later version migrates, this bug will no longer 
affect testing. I have also tagged this bug to only affect sid and 
trixie, so it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release 
Team.


Paul

[1] 
https://lists.debian.org/debian-devel-announce/2023/06/msg1.html 
[2] https://qa.debian.org/excuses.php?package=praat

Bug#1070994: src:praat: fails to migrate to testing for too long: FTBFS on arm64, armel, armhf, ppc64el and riscv64

[Rafael Laboissière]

reopen -1 
found -1 6.4.12+dfsg-3


I partially fixed Bug#1070994 in version 6.4.12+dfsg-3. Indeed, this 
version correctly builds on arm64, armel, ppc64el, and riscv64. However, 
build on armhf fails for an unrelated reason. I am currently 
investigating this. I am hereby reopen the bug report.


Best,

Rafael

* Paul Gevers  [2024-05-12 18:51]:


Source: praat
Version: 6.4.05+dfsg-1
Severity: serious
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between 
testing and unstable for more than 30 days as having a Release 
Critical bug in testing [1]. Your package src:praat has been trying to 
migrate for 74 days [2]. Hence, I am filing this bug. The version in 
unstabled failed to build on most architectures where it build before.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot 
be fixed via unstable. Additionally, blocked packages can have impact 
on other packages, which makes preparing for the release more 
difficult. Finally, it often exposes issues with the package and/or 
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is 
auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer 
affect testing. I have also tagged this bug to only affect sid and 
trixie, so it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release 
Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html 
[2] https://qa.debian.org/excuses.php?package=praat

Bug#1065309: transition: gnat (12 -> 13 + time_t64)

[Rafael Laboissière]

* Graham Inggs  [2024-05-08 10:25]:


It looks like the last blocker for this transition is plplot 
5.15.0+dfsg2-10 failing its own autopkgtests [1].


I will soon upload version 5.15.0+dfsg2-11, with the fix proposed by 
Nicolas in Bug#1070746.


Best,

Rafael

Bug#1069847: rolo FTCBFS: multiple issues

[Rafael Laboissière]

Hello Helmut,

Thanks for the bug report and, in partiuclar, for the patch. I will 
get to this ASAP.


Best,

Rafael Laboissière

* Helmut Grohne  [2024-04-25 20:05]:


Source: rolo
Version: 019-4.1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

rolo fails to cross build from source for two distinct reasons.

For one thing, configure.ac hard codes the build architecture 
pkg-config. It is recommended to use the PKG_CHECK_MODULES macro which 
automatically gets this right.


For another, tests/Makefile.am runs tests during the all target which is 
usually run during build. Hence tests fail despite passing 
DEB_BUILD_OPTIONS=nocheck. Moving tests to the check target causes tests 
to not be run during all, but still be run in a debian package build as 
dh_auto_test runs make check (unless DEB_BUILD_OPTIONS contains 
nocheck).


I'm attaching a patch for your convenience.

Helmut


--- rolo-019.orig/configure.ac 
+++ rolo-019/configure.ac 
@@ -19,12 +19,13 @@ 
CFLAGS="$CFLAGS -I/usr/include/ncursesw/"


# Glib settings 
-LIBS="$LIBS $(pkg-config glib-2.0 --libs)" 
-CFLAGS="$CFLAGS $(pkg-config glib-2.0 --cflags)" 
+PKG_CHECK_MODULES([GLIB],[glib-2.0])


# Libunac settings 
-LIBS="$LIBS $(pkg-config unac --libs)" 
-CFLAGS="$CFLAGS $(pkg-config unac --cflags)" 
+PKG_CHECK_MODULES([UNAC],[unac]) 
+ 
+LIBS="$LIBS $GLIB_LIBS $UNAC_LIBS" 
+CFLAGS="$CFLAGS $GLIB_CFLAGS $UNAC_CFLAGS"


# Checks for header files. 
AC_CHECK_INCLUDES_DEFAULT 
--- rolo-019.orig/test/Makefile.am 
+++ rolo-019/test/Makefile.am 
@@ -1,4 +1,4 @@ 
-all: 
+check: 
	@if [ "$(HAS_SHUNIT2)" = yes ] ; then	\ 
	./run-tests ; 			\ 
	else	\

Bug#1069576: blhc: False positive NONVERBOSE BUILD in src:fim

[Rafael Laboissière]

Package: blhc
Version: 0.14-1
Severity: normal
Tags: patch

Dear Maintainer,

blhc triggers a NONVERBOSE BUILD error in src:fim

https://salsa.debian.org/debian/fim/-/jobs/5618524

  [snip]
  $ blhc --debian --line-numbers --color ${SALSA_CI_BLHC_ARGS} 
${WORKING_DIR}/*.build || [ $? -eq 1 ]
  338:NONVERBOSE BUILD: CXX  : g++
  [snip]

blhc is complaining about the output of the upstream configure script, 
which indicates to the user which C++ compiler will be used.

The patch attached to this bug report fixes the problem for me. 
Hopefully, it will not introduce false negatives.

Best regards,

Rafael Laboissi
--- blhc	2024-04-20 15:10:28.965108347 -0300
+++ blhc-new	2024-04-20 15:10:38.509055996 -0300
@@ -554,7 +554,7 @@
 }
 
 if (not (index($line, 'checking if you want to see long compiling messages... no') == 0
-or $line =~ /^\s*\[?(?:CC|CCLD|C\+\+|CXX|CXXLD|LD|LINK)\]?\s+(.+?)$/
+or $line =~ /^\s*\[?(?:CC|CCLD|C\+\+|CXX|CXXLD|LD|LINK)\]?\s+([^:]+?)$/
 or $line =~ /^\s*[][\/0-9 ]*[Cc]ompiling\s+(.+?)(?:\.\.\.)?$/
 or $line =~ /^\s*[Bb]uilding (?:program|shared library)\s+(.+?)$/
 or $line =~ /^\s*\[[\d ]+%\] Building (?:C|CXX) object (.+?)$/)) {

Bug#1066594: octave-iso2mesh: FTBFS: nl_single_file.c:2505:26: error: implicit declaration of function ‘lsame_’ [-Werror=implicit-function-declaration]

[Rafael Laboissière]

* Qianqian Fang  [2024-03-29 10:52]:


On 3/29/24 01:24, Rafael Laboissière wrote:

It seems so. If we fix Bug#1066594, then both octave-iso2mesh and
octave-brain2mesh will be able to migrate into testing.



thanks Rafael, replying to #1066594

it looks like someone from Fedora had submitted a patch last year 
fixing the same problem - see


https://github.com/fangq/meshfix/pull/1

can you help me update this folder and try rebuilding the package?

https://salsa.debian.org/pkg-octave-team/octave-iso2mesh/-/tree/debian/latest/meshfix?ref_type=heads


Thanks for the link. The package is fixed and version 1.9.6+ds-10 of the 
package has been uploaded to unstable.



I no longer have access to octave-iso2mesh on salsa.


You are still a member of the octave-iso2mesh project at Salsa.d.o, with 
login fangq.


Best,

Rafael Laboissière

Bug#1067222: dgit yields unparseable patches when color.ui=always

[Rafael Laboissière]

Package: dgit
Version: 11.6
Severity: normal

Dear Maintainer,

I have stumbled on a problem related to this specific Git configuration:

[color]
ui = always

With such a configuration, the internal calls to "git diff" in dgit 
yield unparseable patches, making dgit unusable.

Would it be possible to add the option "-c color.ui=never" wherever 
"git diff" is called in dgit?

Best,

Rafael Laboissière

Bug#1065597: racket: Inclusion of mzdyn.o in the binary package

[Rafael Laboissière]

* David Bremner  [2024-03-08 20:23]:


Rafael Laboissière  writes:


At any rate, I wonder why the following mzscheme code:

 (begin
  (require dynext/link)
  (with-handlers
   (((lambda args #t) (lambda args #f)))
   (for-each (lambda (x) (printf "~a" x))
 (expand-for-link-variant (current-standard-link-libraries)



I'm not sure what will come of it, but I have reported this issue as

   https://github.com/racket/cext-lib/issues/4


Great, thanks !

I have already added a comment to that issue.

I haven't marked this Debian bug as forwarded as I believe they are 
different bugs.


Indeed, these are different, although interrelated, bugs.

Best,

Rafael

Bug#1065597: racket: Inclusion of mzdyn.o in the binary package

[Rafael Laboissière]

Package: racket
Version: 8.10+dfsg1-2
Severity: wishlist

Dear Maintainer,

We are updating the Debian package for SWIG (a generator of scripting 
interfaces to C/C++ code), in order to include support for 
MzScheme/Racket.

However, it does not work because the file mzdyn.o is needed and 
cannot be found anywhere. Indeed, this file is mentioned in the Racket 
documentation.[*]

The SWIG's configure script try to find the path for that file by 
running this command:

mzscheme --eval '(begin (require dynext/link) (with-handlers (((lambda args 
#t) (lambda args #f))) (for-each (lambda (x) (printf "~a" x)) 
(expand-for-link-variant (current-standard-link-libraries)'

which yields:

/usr/lib/racket/mzdyn.o

Subsequently, the activation of the MzScheme support fails because this 
path does not exist.

I see that, in the source for the Debian package racket, there is a 
file src/bc/dynsrc/mzdyn.c, that could be compiled into mzdyn.o and 
installed in /usr/lib/racket/.

Do you think that this would be possible?

Best,

Rafael Laboissière

[*] 
https://docs.racket-lang.org/inside/Writing_Racket_Extensions.html#(part._.C.G.C_.Extensions)

Bug#1040138: changelog-file-missing-explicit-entry needs exception for bookworm

[Rafael Laboissière]

* Cyril Brulebois  [2023-10-28 14:43]:


Marc Haber  (2023-10-09):

On Mon, Oct 09, 2023 at 02:06:58AM +0200, Cyril Brulebois wrote:

That exception only hides the root of the bug, which includes (at
least) a messed up version sorting.


What is the recommended way to get rid of this? Re-sorting 
changelog entries? Adding an override?


On the lintian user side: Ignoring silly results works for me.

On the lintian developer side: Fixing whatever produces the weird and of 
course incorrect ordering that's then expected and complained about.


Adding another exception for bookworm will only lead to more 
whack-a-mole down the line (see #1051140).


I don't see the connection here.


Adding an exception hides the bug. Then it's going to appear again when 
the next suite is around the corner, until an exception is added again, 
etc. That doesn't seem like a good idea to me.


I have the impression that the discussion went astray. The original 
reported issue is that the sequence of versions:


0.18.3-1 ⇒ 0.18.3-1+deb12u1 ⇒ 0.18.3-1+deb12u2

is perfectly valid but, yet, Lintian says that the third one is not 
allowed to follow the second one.


According to the Debian Developer's Reference, section 5.14.3:

“Version numbers are usually selected by appending +debXuY, where X is 
the major release number of Debian and Y is a counter starting at 1. 
e.g. 1:2.4.3-4+deb12u1.”


Mu understanding is that the last number (Y) is expected to increase in 
successive releases.


Could the code in Lintian be changed such that the warning 
changelog-file-missing-explicit-entry will only be triggered when 
Z+debXu1 does not follow Z? For now, it seems to be triggered whenever 
Z+debXu\d+ follows Z.


Best,

Rafael Laboissière

Bug#1062613: librsb: NMU diff for 64-bit time_t transition

[Rafael Laboissière]

Hello Steve,

* Rafael Laboissière  [2024-02-02 18:19]:


Control: tags -1 - upstream

* Steve Langasek  [2024-02-02 08:48]:


On Fri, Feb 02, 2024 at 02:06:38PM +0100, Rafael Laboissière wrote:

Control: tags -1 + upstream


Thanks for this bug report and for the upload to experimental, 
Steve.   I am hereby forwarding your message to the upstream 
author.


Note that this is an ABI change introduced by a distro-wide change 
in default build flags; there is no action for upstream to take in 
this regards.


Oops, it is true, thanks for this correction.


I have added your changes to Git.[*]

Thanks,

Rafael Laboissière

[*] 
https://salsa.debian.org/science-team/librsb/-/commit/324c1a7d7fbff0bb9bcc0b9e2b0b174026f77d5d

Bug#1063045: vibes: NMU diff for 64-bit time_t transition

[Rafael Laboissière]

Thanks, Steve. I have added your changes to Git [*]

Best,

Rafael Laboissière

[*] 
https://salsa.debian.org/debian/vibes/-/commit/566014ea0e7b29684b4391fbabd3ae5b8090c6e8

* Steve Langasek  [2024-02-04 17:47]:


Source: vibes
Version: 0.2.3+dfsg-1
Severity: serious
Tags: patch pending sid trixie
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit 
architectures in 2038 and beyond 
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified 
vibes as a source package shipping runtime libraries whose ABI 
either is affected by the change in size of time_t, or could not be 
analyzed via abi-compliance-checker (and therefore to be on the safe 
side we assume is affected).


To ensure that inconsistent combinations of libraries with their 
reverse-dependencies are never installed together, it is necessary to 
have a library transition, which is most easily done by renaming the 
runtime library package.


Since turning on 64-bit time_t is being handled centrally through a change 
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is 
important that libraries affected by this ABI change all be uploaded close 
together in time.  Therefore I have prepared a 0-day NMU for vibes 
which will initially be uploaded to experimental if possible, then to 
unstable after packages have cleared binary NEW.


Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although 
this package will be uploaded to experimental immediately, there will be a 
period of several days before we begin uploads to unstable; so if information 
becomes available that your package should not be included in the transition, 
there is time for us to amend the planned uploads.




-- System Information: 
Debian Release: trixie/sid 
 APT prefers unstable 
 APT policy: (500, 'unstable') 
Architecture: amd64 (x86_64)


Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE 
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set 
Shell: /bin/sh linked to /usr/bin/dash 
Init: systemd (via /run/systemd/system)


diff -Nru vibes-0.2.3+dfsg/debian/changelog vibes-0.2.3+dfsg/debian/changelog 
--- vibes-0.2.3+dfsg/debian/changelog	2023-12-25 15:52:39.0 + 
+++ vibes-0.2.3+dfsg/debian/changelog	2024-02-04 17:45:50.0 + 
@@ -1,3 +1,10 @@ 
+vibes (0.2.3+dfsg-1.1) experimental; urgency=medium 
+ 
+  * Non-maintainer upload. 
+  * Rename libraries for 64-bit time_t transition. 
+ 
+ -- Steve Langasek   Sun, 04 Feb 2024 17:45:50 + 
+ 
vibes (0.2.3+dfsg-1) unstable; urgency=medium


  * Initial release. (Closes: #1059434)
diff -Nru vibes-0.2.3+dfsg/debian/control vibes-0.2.3+dfsg/debian/control 
--- vibes-0.2.3+dfsg/debian/control	2023-12-17 16:01:21.0 + 
+++ vibes-0.2.3+dfsg/debian/control	2024-02-04 17:45:50.0 + 
@@ -32,7 +32,7 @@ 
Package: libvibes-dev 
Section: libdevel 
Architecture: any 
-Depends: libvibes0 (= ${binary:Version}), 
+Depends: libvibes0t64 (= ${binary:Version}), 
 ${shlibs:Depends}, 
 ${misc:Depends}, 
Description: visualizer for intervals and boxes (development files) 
@@ -47,7 +47,10 @@ 
 This package contains the header files for creating clients in C++ 
 for VIBes, as well as the code examples.


-Package: libvibes0 
+Package: libvibes0t64 
+Provides: ${t64:Provides} 
+Replaces: libvibes0 
+Breaks: libvibes0 (<< ${source:Version}) 
Section: libs 
Architecture: any 
Depends: ${shlibs:Depends}, 
diff -Nru vibes-0.2.3+dfsg/debian/libvibes0.install vibes-0.2.3+dfsg/debian/libvibes0.install 
--- vibes-0.2.3+dfsg/debian/libvibes0.install	2023-12-17 13:44:14.0 + 
+++ vibes-0.2.3+dfsg/debian/libvibes0.install	1970-01-01 00:00:00.0 + 
@@ -1 +0,0 @@ 
-viewer/build/libvibes.so.* usr/lib/${DEB_HOST_MULTIARCH} 
diff -Nru vibes-0.2.3+dfsg/debian/libvibes0.lintian-overrides vibes-0.2.3+dfsg/debian/libvibes0.lintian-overrides 
--- vibes-0.2.3+dfsg/debian/libvibes0.lintian-overrides	2023-12-17 13:44:14.0 + 
+++ vibes-0.2.3+dfsg/debian/libvibes0.lintian-overrides	1970-01-01 00:00:00.0 + 
@@ -1,3 +0,0 @@ 
-# "For C++ libraries it is often better not to ship symbols files." 
-# Reference: https://wiki.debian.org/UsingSymbolsFiles#C.2B-.2B-_libraries 
-libvibes0: no-symbols-control-file usr/lib/*/libvibes.so.* 
diff -Nru vibes-0.2.3+dfsg/debian/libvibes0t64.install vibes-0.2.3+dfsg/debian/libvibes0t64.install 
--- vibes-0.2.3+dfsg/debian/libvibes0t64.install	1970-01-01 00:00:00.0 + 
+++ vibes-0.2.3+dfsg/debian/libvibes0t64.install	2023-12-17 13:44:14.0 + 
@@ -0,0 +1 @@ 
+viewer/build/libvibes.so.* usr/lib/${DEB_HOST_MULTIARCH} 
diff -Nru vibes-0.2.3+dfsg/deb

Bug#1062613: librsb: NMU diff for 64-bit time_t transition

[Rafael Laboissière]

Control: tags -1 - upstream

* Steve Langasek  [2024-02-02 08:48]:


On Fri, Feb 02, 2024 at 02:06:38PM +0100, Rafael Laboissière wrote:

Control: tags -1 + upstream


Thanks for this bug report and for the upload to experimental, Steve.   I am 
hereby forwarding your message to the upstream author.


Note that this is an ABI change introduced by a distro-wide change in 
default build flags; there is no action for upstream to take in this 
regards.


Oops, it is true, thanks for this correction.

@Michele: as said, nothing to do on your side !

Best,

Rafael Laboissière

Bug#1062613: librsb: NMU diff for 64-bit time_t transition

[Rafael Laboissière]

Control: tags -1 + upstream

Thanks for this bug report and for the upload to experimental, Steve. 
 
I am hereby forwarding your message to the upstream author.


Best,

Rafael Laboissière

* Steve Langasek  [2024-02-02 06:09]:


Source: librsb
Version: 1.3.0.2+dfsg-6
Severity: serious
Tags: patch pending
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit 
architectures in 2038 and beyond 
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified 
librsb as a source package shipping runtime libraries whose ABI 
either is affected by the change in size of time_t, or could not be 
analyzed via abi-compliance-checker (and therefore to be on the safe 
side we assume is affected).


To ensure that inconsistent combinations of libraries with their 
reverse-dependencies are never installed together, it is necessary to 
have a library transition, which is most easily done by renaming the 
runtime library package.


Since turning on 64-bit time_t is being handled centrally through a change 
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is 
important that libraries affected by this ABI change all be uploaded close 
together in time.  Therefore I have prepared a 0-day NMU for librsb 
which will initially be uploaded to experimental if possible, then to 
unstable after packages have cleared binary NEW.


Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although 
this package will be uploaded to experimental immediately, there will be a 
period of several days before we begin uploads to unstable; so if information 
becomes available that your package should not be included in the transition, 
there is time for us to amend the planned uploads.




-- System Information: 
Debian Release: trixie/sid 
 APT prefers unstable 
 APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') 
Architecture: amd64 (x86_64)


Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE 
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set 
Shell: /bin/sh linked to /usr/bin/dash 
Init: systemd (via /run/systemd/system)


diff -Nru librsb-1.3.0.2+dfsg/debian/.gitignore librsb-1.3.0.2+dfsg/debian/.gitignore 
--- librsb-1.3.0.2+dfsg/debian/.gitignore	2023-06-13 09:19:25.0 + 
+++ librsb-1.3.0.2+dfsg/debian/.gitignore	1970-01-01 00:00:00.0 + 
@@ -1,15 +0,0 @@ 
-/.debhelper/ 
-/*.debhelper.log 
-/debhelper-build-stamp 
-/autoreconf.after 
-/autoreconf.before 
-/files 
-/librsb-dev.substvars 
-/librsb-dev/ 
-/librsb-doc.substvars 
-/librsb-doc/ 
-/librsb-tools.substvars 
-/librsb-tools/ 
-/librsb0.substvars 
-/librsb0/ 
-/tmp/ 
diff -Nru librsb-1.3.0.2+dfsg/debian/changelog librsb-1.3.0.2+dfsg/debian/changelog 
--- librsb-1.3.0.2+dfsg/debian/changelog	2023-06-13 09:19:25.0 + 
+++ librsb-1.3.0.2+dfsg/debian/changelog	2024-02-02 05:59:18.0 + 
@@ -1,3 +1,10 @@ 
+librsb (1.3.0.2+dfsg-6.1) experimental; urgency=medium 
+ 
+  * Non-maintainer upload. 
+  * Rename libraries for 64-bit time_t transition. 
+ 
+ -- Steve Langasek   Fri, 02 Feb 2024 05:59:18 + 
+ 
librsb (1.3.0.2+dfsg-6) unstable; urgency=medium


  * Upload to unstable
diff -Nru librsb-1.3.0.2+dfsg/debian/control librsb-1.3.0.2+dfsg/debian/control 
--- librsb-1.3.0.2+dfsg/debian/control	2023-06-13 09:19:25.0 + 
+++ librsb-1.3.0.2+dfsg/debian/control	2024-02-02 05:59:18.0 + 
@@ -16,7 +16,10 @@ 
Vcs-Browser: https://salsa.debian.org/science-team/librsb 
Rules-Requires-Root: no


-Package: librsb0 
+Package: librsb0t64 
+Provides: ${t64:Provides} 
+Replaces: librsb0 
+Breaks: librsb0 (<< ${source:Version}) 
Architecture: any 
Depends: ${shlibs:Depends}, ${misc:Depends} 
Multi-Arch: same 
@@ -35,7 +38,7 @@ 
Package: librsb-dev 
Section: libdevel 
Architecture: any 
-Depends: librsb0 (= ${binary:Version}), ${misc:Depends} 
+Depends: librsb0t64 (= ${binary:Version}), ${misc:Depends} 
Description: shared-memory Sparse BLAS library using the RSB matrix format (development) 
 This is a library for sparse matrix computations featuring the Recursive 
 Sparse Blocks (RSB) matrix format. This format allows cache efficient and 
@@ -51,7 +54,7 @@


Package: librsb-tools
Architecture: any
-Depends: librsb0 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends} 
+Depends: librsb0t64 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends} 
Description: shared-memory Sparse BLAS library using the RSB matrix format (tools) 
 This is a library for sparse matrix computations featuring the Recursive 
 Sparse Blocks (RSB) matrix format. This format allows cache efficient and 
diff -Nru librsb-1.3.0.2+dfsg/debian/librsb0.install librsb-1.3.0.2+dfsg/

Bug#1061644: octave-dev: The package should include an ld.so.conf fragment pointing to the shared libraries

[Rafael Laboissière]

Control: tags -1 - moreinfo + confirmed

* Antony N. Donovan  [2024-01-28 21:44]:


Without the octave-dev.conf fragment in place, compile the attached file using

$ ​mkoctfile --link-stand-alone embedded.cc -o embedded

when I run created executable I see

 $ ./embedded
 ./embedded: error while loading shared libraries: liboctinterp.so.10: cannot 
open shared object file: No such file or directory

After putting octave-dev.conf in /etc/ld.so.conf.d and running ldconfig I see

 $ ./embedded
 Available Octave Graphics Toolkits:
 fltk
 gnuplot

Please let me know if you have any other questions or need anything else from 
me.


Thank you for the example. I can reproduce the issue and I am hereby 
tagging this bug report accordingly.


Best,

Rafael

Bug#1061644: octave-dev: The package should include an ld.so.conf fragment pointing to the shared libraries

[Rafael Laboissière]

Control: tags -1 - patch + moreinfo

* Antony Donovan  [2024-01-27 15:52]:


Package: octave-dev
Version: 7.3.0-2
Severity: normal
Tags: patch

Dear Maintainer,

I installed octave-dev and after building a standalone executable with 
mkoctfile it failed to run.


I realized that what was needed was an ld.so.conf fragment containing 
the directory where the shared libraries were located.


I created that fragment, with the contents 
/usr/lib/x86_64-linux-gnu/octave/7.3.0, named it octave-dev.conf, 
put that file in /etc/ld.so.conf.d, and ran ldconfig.


This fixed the issue of running the standalone octave executable.


Thank you for your bug report.

Could you please provide us with a complete example that reproduces 
the bug?


Best,

Rafael Laboissière

Bug#1060801: Bug#1061392: swig 4.2.0 needed for Python 3.12 compatibility

[Rafael Laboissière]

Control: assign 1060801 src:swig
Control: severity 1060801 important
Control: merge 1060801 -1

* Matthias Klose  [2024-01-23 18:12]:


Package: src:swig
Version: 4.1.0-0.3
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

please update to swig 4.2.0 needed for Python 3.12 compatibility, at 
least that's what the upstream changelog suggests at


https://www.swig.org/

Bug#1055228: Bug#1055750: Bug#1055228: plplot: FTBFS on armhf (test segfault)

[Rafael Laboissière]

* Emanuele Rocca  [2024-01-17 16:22]:

as a workaround for this issue, you could disable stack-clash-protection 
when building for armhf. The following snippet in debian/rules should do 
the trick:


 ifeq ($(DEB_TARGET_ARCH),armhf)
   DEB_BUILD_MAINT_OPTIONS = hardening=+all,-stackclash
 else
   DEB_BUILD_MAINT_OPTIONS = hardening=+all
 endif


Thanks for this suggestion, Emanuele.

I added your changes to version 5.15.0+dfsg2-7+deb13u1 of the package, 
uploaded to unstable, and it worked:


https://buildd.debian.org/status/fetch.php?pkg=plplot=armhf=5.15.0%2Bdfsg2-7%2Bdeb13u1=1705741947=0

Best,

Rafael

Bug#1060702: tcl-itcl4-dev: incr Tcl programs do not compile with tcl8.7-dev

[Rafael Laboissière]

Package: tcl-itcl4-dev
Version: 4.2.3-1
Severity: important
Tags: upstream patch

With the versions of tcl-itcl4-dev (4.2.3-1) and tcl8.7-dev 
(8.7.0~a5+dfsg-3) currently in experimental, this simple example does 
not work:

$ echo "#include " > test.c
$ gcc -c test.c -I/usr/include/tcl
In file included from test.c:1:
/usr/include/itcl/itcl.h:144:5: error: unknown type name 'Tcl_Size'
  144 | Tcl_Size len;  /* number of values on stack */
  | ^~~~
/usr/include/itcl/itcl.h:145:5: error: unknown type name 'Tcl_Size'
  145 | Tcl_Size max;  /* maximum size of stack */
  | ^~~~
/usr/include/itcl/itcl.h:164:5: error: unknown type name 'Tcl_Size'
  164 | Tcl_Size num;  /* number of elements */
  | ^~~~

It does work in unstable.

Currently, in experimental, tcl-dev depends on tcl8.7-dev. If this 
packages migrate into unstable, then tcl-itcl4-dev will be broken in a 
serious way. Hence, I am am hereby setting the severity level to 
important.

The patch attached to this bug report seems to fix the problem.

Best,

Rafael

-- System Information: 
Debian Release: 12.0 
  APT prefers testing 
  APT policy: (650, 'testing'), (600, 'unstable') 
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tcl-itcl4-dev depends on: 
pn  tcl-dev 
pn  tcl-itcl4  

tcl-itcl4-dev recommends no packages.

Versions of packages tcl-itcl4-dev suggests: 
pn  tcl-itcl4-doc  
diff -Nru itcl4-4.2.3/debian/changelog itcl4-4.2.3/debian/changelog
--- itcl4-4.2.3/debian/changelog2022-11-27 08:34:33.0 -0300
+++ itcl4-4.2.3/debian/changelog2024-01-13 04:53:27.0 -0300
@@ -1,3 +1,10 @@
+itcl4 (4.2.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * d/p/tcl-size-define.patch: New patch
+
+ -- Rafael Laboissière   Sat, 13 Jan 2024 04:53:27 -0300
+
 itcl4 (4.2.3-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru itcl4-4.2.3/debian/patches/series itcl4-4.2.3/debian/patches/series
--- itcl4-4.2.3/debian/patches/series   2022-11-27 08:34:33.0 -0300
+++ itcl4-4.2.3/debian/patches/series   2024-01-13 04:53:27.0 -0300
@@ -1 +1 @@
-# nothing here
+tcl-size-define.patch
diff -Nru itcl4-4.2.3/debian/patches/tcl-size-define.patch 
itcl4-4.2.3/debian/patches/tcl-size-define.patch
--- itcl4-4.2.3/debian/patches/tcl-size-define.patch1969-12-31 
21:00:00.0 -0300
+++ itcl4-4.2.3/debian/patches/tcl-size-define.patch2024-01-13 
04:41:42.0 -0300
@@ -0,0 +1,16 @@
+Description: Allow compilation with Tcl 8.7
+Author: Rafael Laboissière 
+Forwarded: no
+Last-Update: 2024-01-13
+
+--- itcl4-4.2.3.orig/generic/itcl.h
 itcl4-4.2.3/generic/itcl.h
+@@ -132,7 +132,7 @@ ITCL_EXTERN int Itcl_SafeInit(Tcl_Interp
+ #define ITCL_PRIVATE  3
+ #define ITCL_DEFAULT_PROTECT  4
+ 
+-#if (TCL_MAJOR_VERSION == 8) && (TCL_MINOR_VERSION < 7) && !defined(Tcl_Size)
++#if (TCL_MAJOR_VERSION == 8) && (TCL_MINOR_VERSION < 8) && !defined(Tcl_Size)
+ #define Tcl_Size int
+ #endif
+ 

Bug#1059040: libxml2: ABI change? (undefined references)

[Rafael Laboissière]

* Thorsten Glaser  [2024-01-12 17:56]:


On Fri, 12 Jan 2024, Rafael Laboissière wrote:

experimental, the configure script does detect the absence of the 
xmlNanoFTPNewCtxt function in the libxml2 library (version 
2.12.3+dfsg-0exp1) and disables the call to the xmlNanoFTP* functions. 
However, this rebuilt will not be automatically triggered without a 
bump in the SONAME version of libxml2.


In summary, the introduction of version 2.12 of libxml2 in unstable 
will need a proper and coordinated transition.


No, this will still break partial upgrades.

Losing symbols needs a major shlib version change *including*, in 
Debian, changing the binary package name so that the old and new 
shlibs are coïnstallable.


And this needs to be exercised in experimental first, not only 
when introducing this to unstable.


Alternatively, bring the symbols back.


Thanks for the clarification, this is exactly what I meant. I apologized 
for not being clear enough.


Best,

Rafael Laboissière

Bug#1059040: libxml2: ABI change? (undefined references)

[Rafael Laboissière]

Rafael

* Rene Engelhard  [2023-12-25 23:48]:


Hi,

Am 25.12.23 um 22:57 schrieb Rene Engelhard:

I didn't file it for the plain build issue. Nevertheless, if it
broke so many projects you probably should do a full-fledged rebuild
and send


Well, mitigated by 2.12.3, but still.

But again, this is completely off-topic to what I filed in this bug 
which is the ABI break.


Which *maybe* could be ignored. Maybe one can do Breaks: after a 
rebuild (then you might get a problem inbetween only when in this case 
libreoffice is to be rebuilt. But here libreoffice fails its tests 
even).


But not until one knows what is affected.

*You* need to do a test as the library maintainer/the one who wants to 
update it, not me.


The current issue has the potential of introducing a *huge* breakage in 
the distribution, due to the chain of (build-)dependencies. For instance, 
I tried to rebuild the plplot package in my up-to-date experimental 
chroot, in order to make it comply with the upcoming gnat-12 ⇒ gnat-13 
transition. I ran into this, when trying to install the 
build-dependencies for plplot :


$ pdebuild
[…]
Setting up octave (8.4.0-1+b1) ...
/usr/bin/octave-cli: symbol lookup error: /lib/libGraphicsMagick-Q16.so.3: 
undefined symbol: xmlNanoFTPInit, version LIBXML2_2.4.30
dpkg: error processing package octave (--configure):
[…]
Errors were encountered while processing:
 octave
E: Sub-process /usr/bin/dpkg returned an error code (1)

If a new version of graphicsmagick were uploaded to experimental, then 
the problem would go away. Indeed, when the graphicsmagick package is 
rebuilt in experimental, the configure script does detect the absence of 
the xmlNanoFTPNewCtxt function in the libxml2 library (version 
2.12.3+dfsg-0exp1) and disables the call to the xmlNanoFTP* functions. 
However, this rebuilt will not be automatically triggered without a bump 
in the SONAME version of libxml2.


In summary, the introduction of version 2.12 of libxml2 in unstable will 
need a proper and coordinated transition.


Best,

Rafael Laboissière

Bug#1013584: octave-iso2mesh: FTBFS: dh_missing: error: missing files, aborting

[Rafael Laboissière]

Control: notfixed -1 1.9.6+ds-8
Control: fixed -1 1.9.6+ds-9

* Yue Gui  [2024-01-05 22:53]:


Source: octave-iso2mesh
Version: 1.9.6+ds-7
Severity: serious
Justification: FTBFS
Tags: sid ftbfs

Dear octave-iso2mesh Maintainer,

About the issue reported, there is a solution that add "not-installed" 
file to /debian. This solution refers to Bug Report #964666. More 
details can be found in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964666 and 
https://salsa.debian.org/multimedia-team/libopenshot/-/commit/43689f7b3b058dfd0ee83dd7ff6a6bc863a02004#1823cfdb97f631de92d185f9a7ef6c1f58bc9147


The dh_missing error is caused by *.m exists in debian/tmp but is not 
installed to anywhere, so the solution is effective.I have tested it 
successfully in local. Please let me know if the solution accepted.


The "not-installed" file is in the attachment.


I went too fast and released version 1.9.6+ds-8 with eh proposed "fix" 
(adding debian/not-installed). Actually, this is not the right thing to 
do, since the files in debian/tmp/usr/share/octave/packages/ should go 
into the binary package octave-iso2mesh.


I am hereby rectifying the situation.

Best,

Rafael Laboissière

Bug#1060133: mailagent: New upstream change for coping with MIME-encoded (RFC 2047) headers

[Rafael Laboissière]

Package: mailagent
Version: 1:3.1-106-1
Severity: normal
Tags: patch

Dear Maintainer,

The upstream author, Raphaël Manfredi, has recently committed a change 
to the sources that allows mailagent to cope with MIME-encoded (RFC 
2047) headers [*].

According to him, “[t]his allows transparent filtering of encoded 
headers with a simple UTF-8 regular expression, without having to know 
about the original header encoding (which might not have been UTF-8).”

Please, consider integrating this very useful improvement in the 
Debian package for mailagent.

Best,

Rafael Laboissière

[*] 
https://github.com/rmanfredi/mailagent/commit/b0aa16fc2252ec0a0b51e1f9caec9417ada3b39e

Bug#1055228: Bug#1055750: Bug#1055228: plplot: FTBFS on armhf (test segfault)

[Rafael Laboissière]

Control: severity -1 important

* Sebastiaan Couwenberg  [2024-01-01 20:13]:

plplot got removed from armhf, the severity of this issue could be 
lowered to important to not have the package removed from testing.


Thanks, I am doing it hereby.

Best,

Rafael Laboissière

Bug#1059652: Proposed-RM: slpvm -- RoQA; PVM no longer maintained

[Rafael Laboissière]

* Ansgar  [2023-12-29 20:24]:


Source: slpvm
Version: 0.1.5-17
Severity: serious
Control: block 1055957 by -1

Please consider removing src:slpvm. The last upstream release (0.1.5) 
is from 2005-10-28 and PVM itself doesn't seem relevant for parallel 
applications these days and is also unmaintained.


If there are no objections, I'll reassign this bug to the FTP team. 
I'll wait at least two weeks, i.e., at least until 2024-01-13; though 
it might take longer until I look at this again.


Please, reassign this bug to ftp.debian.org.

Thanks for your QA work.

Best,

Rafael Laboissière

Bug#1057591: octave-vibes: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...

[Rafael Laboissière]

* Rafael Laboissière  [2023-12-22 04:36]:


* Sébastien Villemot  [2023-12-21 15:23]:


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


Thanks, Sébastien.

I think that it is possible to do something similar in Perl (the 
language in which dh_octave_check is written) by using the %SIG hash. 
I will take a look at it.


I got confused, sorry. Actually, dh_octave_check is written in Shell.

I have uploaded version 1.6.0 of dh-octave with the needed changes.

Best,

Rafael

Bug#1059434: ITP: vibes -- visualizer for intervals and boxes

[Rafael Laboissière]

Package: wnpp
Severity: wishlist
Owner: Rafael Laboissière 
X-Debbugs-Cc: debian-de...@lists.debian.org

 * Package name: vibes
   Version : 0.2.3
   Upstream Contact: https://github.com/ENSTABretagneRobotics
 * URL : http://enstabretagnerobotics.github.io/VIBES/
 * License : GPL-3+, LGPL-3+
   Programming Lang: C++
   Description : visualizer for intervals and boxes

VIBes is a visualization system that aims at providing people working 
with interval methods a way to display results (boxes, pavings), 
without worrying with GUI programming. It provides drawing functions 
accessible from a lot of programming languages, without complex 
installation and library dependencies. The main design goal of VIBes 
is to be cross-platform, available from different programming 
languages, simple to set-up, easy to port to a new language.

A preliminary version of the package is available at 
https://salsa.debian.org/debian/vibes

This package is a dependency for the octave-vibes package, which was 
part of the Debian distribution, but is useless without the 
VIBes-viewer.

Bug#1057591: octave-vibes: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...

[Rafael Laboissière]

* Sébastien Villemot  [2023-12-21 15:23]:


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


Thanks, Sébastien.

I think that it is possible to do something similar in Perl (the language 
in which dh_octave_check is written) by using the %SIG hash. I will take 
a look at it.


Best,

Rafael

Bug#1057591: octave-vibes: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...

[Rafael Laboissière]

* 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.


Best,

Rafael Laboissière

Bug#1057591: octave-vibes: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...

[Rafael Laboissière]

* Santiago Vila  [2023-12-20 13:43]:


El 16/12/23 a las 22:30, Rafael Laboissière escribió:

I did the investigation again, using pbuilder. Here is what I found:

– In my case, pbuilder sets HOME=/nonexistent/ and debhelper (compat level = 
13) keeps that setting. Hence, the package FTBFS.

– If I use "export HOME = /tmp", for instance, in debian/rules, then the build 
succeeds.


Thanks for the additional investigation. This is why I was sorry to see this 
package being removed, as you have just confirmed that the FTBFS problem 
was indeed easy to fix... Nevermind, I take note of course that it was not 
the main reason for the removal.


Yes, the real reason is elsewhere.

I guess a more standard approach, if you ever have to do this in a real package, 
would be to do this:


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 ?


Best,

Rafael

Bug#1058281: Request for action on Bug#1057589, Bug#1057590, and Bug#1058281

[Rafael Laboissière]

Hi Santiago and Lucas,

You have filed bug reports against octave-netcdf (Bug#1057590) and 
octave-ncarray (Bug#1057589 and Bug#1058281). These packages FTBFS due to 
an issue in the netcdf package (Bug#1058281), which has been fixed 
thanks to the recent upload of version 4.9.2-3.


Would it be possible to check the build of octave-netcdf and 
octave-ncarray on your systems, such that we can close the bug reports?


Best,

Rafael

Bug#1057591: octave-vibes: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...

[Rafael Laboissière]

* Rafael Laboissière  [2023-12-15 21:44]:


* Santiago Vila  [2023-12-15 18:15]:

The thing I don't understand here is why this problem in 
octave-vibes was diagnosed as an "unwritable $HOME" in the first 
place.


This is what I concluded after running some tests, but I do not 
remember the details. I will try to replicate it.


I did the investigation again, using pbuilder. Here is what I found:

– In my case, pbuilder sets HOME=/nonexistent/ and debhelper (compat 
level = 13) keeps that setting. Hence, the package FTBFS.


– If I use "export HOME = /tmp", for instance, in debian/rules, then 
the build succeeds.


Best,

Rafael Laboissière

Bug#1057591: octave-vibes: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...

[Rafael Laboissière]

* Santiago Vila  [2023-12-15 18:15]:

The thing I don't understand here is why this problem in octave-vibes 
was diagnosed as an "unwritable $HOME" in the first place.


This is what I concluded after running some tests, but I do not 
remember the details. I will try to replicate it.


Best,

Rafael Laboissière

Bug#1058281: octave-ncarray: FTBFS: make: *** [debian/rules:5: binary] Error 139

[Rafael Laboissière]

Control: block -1 by 1058621
Control: merge -1 1057590

Trying again…

Bug#1057591: octave-vibes: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...

[Rafael Laboissière]

Rafael

* Santiago Vila  [2023-12-15 12:59]:


El 13/12/23 a las 9:27, Rafael Laboissière escribió:

i.e. you may rely on a writable $HOME if it's for a "good cause" (i.e. 
dh_auto_test).

So, the simple question: Should this not be also implemented in dh_octave_check 
as well, which is what octave-vibes was using?


Thanks for bringing this to my knowledge. However, I do not quite understand 
the text above. Does it mean that, when the package Build-Depends on 
debhelper-compat = 13, then $HOME will be set automatically to a writable 
directory? Well, octave-vibes that compatibility level of debhelper, but the 
autobuilders set HOME=/nonexistent/.


Sorry, I don't really know for sure.

I just remember this case where the debhelper feature allowed for an "easy" fix:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025654


There is something that I definitively do not understand here. Let's 
take your build log for octave-vibes: 
https://people.debian.org/~sanvila/build-logs/202312/octave-vibes_0.2.0-8_amd64-20231205T162533.194Z


We see that debhelper-compat = 13 is used (line #76) in the build. 
However, we see the following in line #3199:


User Environment


[…]
HOME=/sbuild-nonexistent
[…]

It seems that your building system is setting HOME to an non-existent 
directory. How do you explain that ?


Best,

Rafael

Bug#1058281: octave-ncarray: FTBFS: make: *** [debian/rules:5: binary] Error 139

[Rafael Laboissière]

Control: blocked -1 by 1058621
Control: merge -1 1057590

I hope that the merge goes well this time.

Best,

Rafael Laboissière

Bug#1058281: octave-ncarray: FTBFS: make: *** [debian/rules:5: binary] Error 139

[Rafael Laboissière]

Control: reassign -1 src:octave-netcdf
Control: forwarded -1 https://savannah.gnu.org/bugs/index.php?64999
Control: merge -1 1057590

* Lucas Nussbaum  [2023-12-12 09:39]:


Source: octave-ncarray
Version: 1.0.5-3
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20231212 ftbfs-trixie

During a rebuild of all packages in sid, your package failed to build 
on amd64.


Thanks for this bug report, but the issue has been already reported. I 
am hereby reassigning and merging this bug report.


Best,

Rafael Laboissière

Bug#1058621: netcdf: Finalize HDF5 library at exit

[Rafael Laboissière]

* Sebastiaan Couwenberg  [2023-12-13 18:37]:


On 12/13/23 17:52, Rafael Laboissière wrote:

The bug has been forwarded upstream [1]. The upstream author of 
octave-netcdf, John Donoghue, discovered that the problem is not 
caused by the netcdf package nor by Octave itself, but is rather a 
problem within the netcdf library, in the way the HDF5 support is 
unloaded. He proposed a patch to the upstream authors of the netcdf 
library [2]. It would be great if that patch can be integrated to the 
netcdf package for Debian.


The patch is added in git.


Thanks for that. I apologize for proposing that useless merge request. I 
did it before noticing that the patch has been added to the repository.


I'm going to wait at least for #2827 to get merged, as there might be 
further changes.


This is a wise decision. Indeed, there is an ongoing discussion between 
one of the upstream author and the patch's author. They seem to disagree 
on the proposed fix.


Best,

Rafael Laboissière

Bug#1058621: netcdf: Finalize HDF5 library at exit

[Rafael Laboissière]

Control: tags -1 + patch

I just created a merge request for fixing the current bug: 
https://salsa.debian.org/debian-gis-team/netcdf/-/merge_requests/2


Best,

Rafael

* Rafael Laboissière  [2023-12-13 17:52]:


Source: netcdf
Version: 1:4.9.2-2
Severity: important
Tags: upstream
Control: block 1057590 by -1

Bug#1057590 has been recently filed against the octave-netcdf package, 
which currently FTBFS. This bug is exposed at the end of the Octave 
session where the binding functions for the netcdf library are used, 
causing a segmentation fault.


The bug has been forwarded upstream [1]. The upstream author of 
octave-netcdf, John Donoghue, discovered that the problem is not caused 
by the netcdf package nor by Octave itself, but is rather a problem 
within the netcdf library, in the way the HDF5 support is unloaded. He 
proposed a patch to the upstream authors of the netcdf library [2]. It 
would be great if that patch can be integrated to the netcdf package for 
Debian.


I confirm that the patch fixes the segfault problem of octave-netcdf and 
that the netcdf package builds correctly with it.


I am hereby setting the severity level to "important", since the bug here 
reported is blocking Bug#1057590, which has severity level "serious". 
Please feel free to change the severity level to whatever you see fit.


Best,

Rafael Laboissière

[1] https://savannah.gnu.org/bugs/index.php?64999 
[2] https://github.com/Unidata/netcdf-c/pull/2827

Bug#1058621: netcdf: Finalize HDF5 library at exit

[Rafael Laboissière]

Source: netcdf
Version: 1:4.9.2-2
Severity: important
Tags: upstream
Control: block 1057590 by -1

Bug#1057590 has been recently filed against the octave-netcdf package, 
which currently FTBFS. This bug is exposed at the end of the Octave 
session where the binding functions for the netcdf library are used, 
causing a segmentation fault.

The bug has been forwarded upstream [1]. The upstream author of 
octave-netcdf, John Donoghue, discovered that the problem is not caused 
by the netcdf package nor by Octave itself, but is rather a problem 
within the netcdf library, in the way the HDF5 support is unloaded. He 
proposed a patch to the upstream authors of the netcdf library [2]. It 
would be great if that patch can be integrated to the netcdf package for 
Debian.

I confirm that the patch fixes the segfault problem of octave-netcdf and 
that the netcdf package builds correctly with it.

I am hereby setting the severity level to "important", since the bug here 
reported is blocking Bug#1057590, which has severity level "serious". 
Please feel free to change the severity level to whatever you see fit.

Best,

Rafael Laboissière

 [1] https://savannah.gnu.org/bugs/index.php?64999
 [2] https://github.com/Unidata/netcdf-c/pull/2827

Bug#1057589: Reassign Bug#1057589 and merge it with #1057590

[Rafael Laboissière]

reassign 1057589 src:octave-netcdf 
merge 1057589 1057590 
stop

Bug#1057591: octave-vibes: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...

[Rafael Laboissière]

* Santiago Vila  [2023-12-12 20:25]:


I'm sorry to see this package removed because of this bug which I filed.


Actually, the main reason for requesting the removal is the fact that the 
package is unusable without the VIBES viewer. Note that if the latter is 
packaged for Debian, then the octave-vibes package can be resurrected.


I trust that removing the package was the right thing to do, but I just 
read the removal request you did to ftpmasters (#1058025) and would 
like to make a minor comment which is only indirectly related:


This is caused by the fact that the VIBES API uses the file 
$HOME/.vibes.json to communicate with the VIBES server. Since the 
Debian autobuilders set HOME="/nonexistent/" [3], then the unit 
tests for octave-vibes fail.


There is actually a debhelper feature for cases like this one. 
This is from debhelper(7):


  HOME, XDG_*
  In compat 13 and later, these environment variables are reset
  before invoking the upstream build system via the dh_auto_*
  helpers.  The variables HOME (all dh_auto_* helpers) and
  XDG_RUNTIME_DIR (dh_auto_test only) will be set to a writable
  directory. All remaining variables and XDG_RUNTIME_DIR
  (except for during dh_auto_test) will be cleared.

  The HOME directory will be created as an empty directory but
  it will be reused between calls to dh_auto_*.  Any content
  will persist until explicitly deleted or dh_clean.

i.e. you may rely on a writable $HOME if it's for a "good cause" (i.e. 
dh_auto_test).


So, the simple question: Should this not be also implemented in 
dh_octave_check as well, which is what octave-vibes was using?


Thanks for bringing this to my knowledge. However, I do not quite 
understand the text above. Does it mean that, when the package 
Build-Depends on debhelper-compat = 13, then $HOME will be set 
automatically to a writable directory? Well, octave-vibes that 
compatibility level of debhelper, but the autobuilders set 
HOME=/nonexistent/.



Also, while we are at it, the Policy paragraph that you quoted:

The Debian autobuilders set HOME to /nonexistent so that packages 
which try to write to a home directory will fail to build.


would probably need to be reworded a little bit.


I agree. I think that a bug report should be filed against 
debian-policy on this issue.


Best,

Rafael Laboissière

Bug#1058025: RM: octave-vibes -- ROM; package is unusable

[Rafael Laboissière]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: octave-vi...@packages.debian.org, debian-oct...@lists.debian.org
Control: affects -1 + src:octave-vibes

I am hereby requesting the removal package octave-vibes from Debian, on 
behalf of the Debian Octave Group.

This package only makes sense when used together with the VIBES 
Viewer [1], which has never been packaged for Debian. Furthermore, the 
package currently FTBFS [2]. This is caused by the fact that the VIBES 
API uses the file $HOME/.vibes.json to communicate with the VIBES server. 
Since the Debian autobuilders set HOME="/nonexistent/" [3], then the unit 
tests for octave-vibes fail.

We are not going to the trouble of fixing the octave-vibes package, neither 
packaging VIBES for Debian.

Best,

Rafael Laboissière

 [1] https://github.com/ENSTABretagneRobotics/VIBES
 [2] http://bugs.debian.org/1057591
 [3] 
https://www.debian.org/doc/debian-policy/ch-opersys.html#non-existent-home-directories

Bug#1057589: octave-ncarray: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...

[Rafael Laboissière]

Control: tags -1 + upstream confirmed
Control: forwarded -1 https://savannah.gnu.org/bugs/index.php?64999
Control: reassign -1 octave-netcdf
Control: merge -1 1057590

Thanks for the bug report.

I verified with gdb and I think that this bug is very certainly caused by 
the octave-netcdf package, on which octave-ncarray depends. I am hereby 
merging the present bug report with Bug#1057590


Best,

Rafael Laboissière

* Santiago Vila  [2023-12-05 23:08]:


Package: src:octave-ncarray
Version: 1.0.5-3
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:


[...]
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-ncarray/ -O--buildsystem=octave
octave --no-gui --no-history --silent --no-init-file --no-window-system 
/usr/share/dh-octave/install-pkg.m 
/<>/debian/octave-ncarray/usr/share/octave/packages 
/<>/debian/octave-ncarray/usr/lib/x86_64-linux-gnu/octave/packages
For information about changes from previous versions of the ncarray package, 
run 'news ncarray'.
  dh_octave_check -O--buildsystem=octave
Checking package...
Checking m files ...
warning: function /usr/share/octave/packages/statistics-1.6.0/shadow9/std.m 
shadows a core library function
warning: called from
   /usr/share/octave/packages/statistics-1.6.0/PKG_ADD at line 13 column 3
   load_packages_and_dependencies at line 56 column 5
   load_packages at line 53 column 3
   pkg at line 639 column 7
   /tmp/tmp.DHPTjFH6go at line 9 column 9

warning: function /usr/share/octave/packages/statistics-1.6.0/shadow9/var.m 
shadows a core library function
warning: called from
   /usr/share/octave/packages/statistics-1.6.0/PKG_ADD at line 13 column 3
   load_packages_and_dependencies at line 56 column 5
   load_packages at line 53 column 3
   pkg at line 639 column 7
   /tmp/tmp.DHPTjFH6go at line 9 column 9

warning: function /usr/share/octave/packages/statistics-1.6.0/shadow9/mean.m 
shadows a core library function
warning: called from
   /usr/share/octave/packages/statistics-1.6.0/PKG_ADD at line 13 column 3
   load_packages_and_dependencies at line 56 column 5
   load_packages at line 53 column 3
   pkg at line 639 column 7
   /tmp/tmp.DHPTjFH6go at line 9 column 9

warning: function /usr/share/octave/packages/statistics-1.6.0/shadow9/median.m 
shadows a core library function
warning: called from
   /usr/share/octave/packages/statistics-1.6.0/PKG_ADD at line 13 column 3
   load_packages_and_dependencies at line 56 column 5
   load_packages at line 53 column 3
   pkg at line 639 column 7
   /tmp/tmp.DHPTjFH6go at line 9 column 9

warning: function /usr/share/octave/packages/statistics-1.6.0/shadow9/mad.m 
shadows a core library function
warning: called from
   /usr/share/octave/packages/statistics-1.6.0/PKG_ADD at line 13 column 3
   load_packages_and_dependencies at line 56 column 5
   load_packages at line 53 column 3
   pkg at line 639 column 7
   /tmp/tmp.DHPTjFH6go at line 9 column 9

[inst/test_ncarray_nan.m]

/<>/inst/test_ncarray_nan.m

* test
test_ncarray_nan ()
warning: test: file /<>/inst/test_ncarray_nan.m leaked global 
variables: CACHED_DECOMPRESS_DIR CACHED_DECOMPRESS_LOG_FID CACHED_DECOMPRESS_MAX_SIZE
1 test, 1 passed, 0 known failure, 0 skipped
[inst/test_ncarray.m]

/<>/inst/test_ncarray.m

* test
test_ncarray()
creating directory /tmp/oct-n6O7Cg for temporary files.

All tests passed.
1 test, 1 passed, 0 known failure, 0 skipped
Checking C++ files ...
fatal: caught signal Segmentation fault -- stopping myself...
Segmentation fault
make: *** [debian/rules:5: binary] Error 139
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


The above is just how the build ends and not necessarily the most relevant part.
If required, the full build log is available here:

https://people.debian.org/~sanvila/build-logs/202312/

About the archive rebuild: The build was made using virtual machines
from AWS, with enough memory, enough disk, and either one or two
CPUs, using a reduced chroot with only build-essential packages.

If you could not reproduce the bug please contact me privately, as I
am willing to provide ssh access to a virtual machine where the bug is
fully reproducible.

If this is really a bug in one of the build-depends, please use
reassign and affects, so that this is still visible in the BTS web
page for this package.

Thanks.

Bug#1057590: octave-netcdf: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...

[Rafael Laboissière]

Control: tags -1 + upstream confirmed
Control: forwarded -1 https://savannah.gnu.org/bugs/index.php?64999

* Santiago Vila  [2023-12-05 23:08]:


Package: src:octave-netcdf
Version: 1.0.17-1
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:

[snip] 
fatal: caught signal Segmentation fault -- stopping myself... 
Segmentation fault


Thanks for the bug report. It seems to be an upstream problem. I have 
forwarded the bug to the upstream developers.


Best,

Rafael Laboissière

Bug#1055228: Processed (with 1 error): Re: Bug#1055750: Bug#1055228: plplot: FTBFS on armhf (test segfault)

[Rafael Laboissière]

severity 1055750 serious 
merge 1055750 1055228

Bug#1055228: Bug#1055750: Bug#1055228: plplot: FTBFS on armhf (test segfault)

[Rafael Laboissière]

Control: reassign -1 plplot
Control: forwarded 1055228 https://sourceforge.net/p/plplot/bugs/206/
Control: merge -1 1055228

* Emanuele Rocca  [2023-11-16 09:30]:

To be honest I think it's safe to close 1055750 (gfortran) and mark 
1055228 (plplot) as forwarded upstream though, I don't think we have 
any reasons to believe the compiler is at fault really.


Thanks for the suggestion, Emanuele.

I am hereby merging both bugs, which are now both assigned to plplot.

Best,

Rafael Laboissière

Bug#1055750: Bug#1055228: plplot: FTBFS on armhf (test segfault)

[Rafael Laboissière]

Control: forwarded -1 https://sourceforge.net/p/plplot/bugs/206/

* Rafael Laboissière  [2023-11-16 07:51]:

My guess is that the bug is in PLplot and not in gfortran, but this is 
just a guess. I will eventually inform the PLplot upstream authors 
about the issue.


Done !

R.

Bug#1055750: Bug#1055228: plplot: FTBFS on armhf (test segfault)

[Rafael Laboissière]

* Emanuele Rocca  [2023-11-15 20:11]:


On 2023-11-15 06:47, Rafael Laboissière wrote:

Does this mean that the origin of the bug is upstream or that it still may
be a bug in gfortran?


At this point we know for sure that the issue is not armhf-specific, and 
also that it is not caused by stack-clash-protection. On the contrary, 
enabling stack-clash-protection on armhf allowed us to discover a 
problem that would have otherwise gone unnoticed.


Whether the bug is in plplot or gfortran I really have no idea. I would 
tend not to think of a compiler issue unless we have some evidence in 
that direction though, and suggest raising the issue with plplot 
upstream. Showing them the x86 reproducer with -fsanitize=address should 
be a good starting point.


Ok, thanks.

FYI, I can reproduce the segfault on armhf and amd64 with 
-fsanitize=address.


My guess is that the bug is in PLplot and not in gfortran, but this is 
jsut a guess. I will eventually inform the PLplot upstream authors about 
the issue.


Best,

Rafael Laboissière

Bug#1055750: Bug#1055228: plplot: FTBFS on armhf (test segfault)

[Rafael Laboissière]

Hi Emanuele,

Our messages crossed.

* Emanuele Rocca  [2023-11-15 18:20]:


On 2023-11-09 05:11, Rafael Laboissière wrote:

The Fortran example x09f.f90, which is exercised during the building of
plplot, now fails on armhf, due to the use of the compiler option
-fstack-clash-protection.


The problem seems unrelated to stach-clash-protection I think, enabling 
the feature on armhf just made it evident.


Building the program on a x86 system without -fstack-clash-protection 
but with -fsanitize=address, it segfaults:


/usr/bin/gfortran -g -O2 x09f.f90 -o x09f -I/usr/lib/x86_64-linux-gnu/fortran/modules/plplot -lplplotfortran -fsanitize=address 
./x09f -dev ps -o /dev/null


Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

The SIGSEGV happens in plplot_single::pltransformf2c, which is about 
where the SIGBUS happens on armhf with stack-clash-protector enabled:


 Program received signal SIGSEGV, Segmentation fault.
 0x75a000a8 in ?? ()
 (gdb) bt
 #0  0x75a000a8 in ?? ()
 #1  0x77f05683 in plplot_single::pltransformf2c (x=x@entry=0, 
y=y@entry=1, tx=4.9406564584124654e-324,
 ty=6.9533558054215925e-310, data=)
 at ./bindings/fortran/plplot_single.f90:114

Here's the SIGBUS on armhf with stack-clash-protection:

 Program received signal SIGBUS, Bus error.
 0x00400822 in x09f::mypltr (x=0, y=1, xt=0, yt=0) at x09f.f90:38
 38  xt = tr(1) * x + tr(2) * y + tr(3)
 (gdb) bt
 #0  0x00400822 in x09f::mypltr (x=0, y=1, xt=0, yt=0) at x09f.f90:38
 #1  0xf7f58a06 in plplot_single::pltransformf2c (x=, y=, tx=-9.8841854819221187e+269,
 ty=-nan(0xe5db40001), data=) at 
./bindings/fortran/plplot_single.f90:114


Does this mean that the origin of the bug is upstream or that it still 
may be a bug in gfortran?


Best,

Rafael Laboissière

Bug#1055750: gfortran: [armhf] Yield SIGBUS when compiling with -fstack-clash-protection

[Rafael Laboissière]

* Rafael Laboissière  [2023-11-15 18:37]:


* Rafael Laboissière  [2023-11-15 18:06]:

I have investigated the issue a little bit deeper. Please, find here 
attached a new tarball with a simplified version of the x09f.f90 
file, that still triggers the bug. Running the resulting executable 
with gbd, yields the following:


Oops, with the correct tarball this time.


Grrr, with the correct one now, hopefully!

R.


bug-1055750.tgz
Description: application/gtar-compressed

Bug#1055750: gfortran: [armhf] Yield SIGBUS when compiling with -fstack-clash-protection

[Rafael Laboissière]

* Rafael Laboissière  [2023-11-15 18:06]:

I have investigated the issue a little bit deeper. Please, find here 
attached a new tarball with a simplified version of the x09f.f90 file, 
that still triggers the bug. Running the resulting executable with 
gbd, yields the following:


Oops, with the correct tarball this time.

Best,

Rafael Laboissière


bug-1055750.tgz
Description: application/gtar-compressed

Bug#1055750: gfortran: [armhf] Yield SIGBUS when compiling with -fstack-clash-protection

[Rafael Laboissière]

* Emanuele Rocca  [2023-11-14 12:01]:


On 2023-11-13 05:13, Rafael Laboissière wrote:

The attached file bug-1055750.tgz contains a minimal code that
triggers the bug on an armhf system


Thanks! For the record I can reproduce the issue in a armhf chroot, but 
*not* on armel and arm64. The only thing to change in the reproducer is 
the -I argument to gfortran:


 armhf: /usr/lib/arm-linux-gnueabihf
 armel: /usr/lib/arm-linux-gnueabi
 arm64: /usr/lib/aarch64-linux-gnu

I'll see if I can find out more.


Thanks for the followup, Emanuele.

I have investigated the issue a little bit deeper. Please, find here 
attached a new tarball with a simplified version of the x09f.f90 file, 
that still triggers the bug. Running the resulting executable with gbd, 
yields the following:


(gdb) run -dev ps -o /dev/null
Starting program: /home/rafael/bug-1055750/x09f -dev ps -o /dev/null
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
x09f::mypltr2 (x=0, y=1, xt=0, yt=7.300765e-43) at x09f.f90:48
48  yt = tr(1)

In this new code, there are two private functions mypltr1 and mypltr2. 
The bug only happens when the latter is invoked, in which a value coming 
from the global variable tr is assigned to yt. In mypltr1, the assignment 
is done to xt, instead of yt, and no segfault is triggered.


Best,

Rafael Laboissière


bug-1055750.tgz
Description: application/gtar-compressed

Bug#1055750: gfortran: [armhf] Yield SIGBUS when compiling with -fstack-clash-protection

[Rafael Laboissière]

The attached file bug-1055750.tgz contains a minimal code that 
triggers the bug on an armhf system : 
 
$ ./run 
* Compile without -fstack-clash-protection & run 
/usr/bin/ld: warning: /tmp/cc9l2GJa.o: requires executable stack (because the .note.GNU-stack section is executable) 
* Compile with -fstack-clash-protection & run 
/usr/bin/ld: warning: /tmp/ccP0miz5.o: requires executable stack (because the .note.GNU-stack section is executable)


Program received signal SIGBUS: Access to an undefined portion of a memory 
object.

Backtrace for this error:
Bus error

* Rafael Laboissière  [2023-11-10 15:52]:


Package: gfortran
Version: 13.2.0-1
Severity: normal

Dear Maintainer,

The motivation for the present bug report comes from Bug#1055228. Since 
version 1.22.1 of dpkg-dev was released (on October 30), the plplot 
package FTBFS due to a failing compilation of one of Fortran examples, 
which is exercised as a unit test during package building.


The package built fine previously. The problem is triggered by the change 
in dpkg-buildflags, which now includes -fstack-clash-protection in 
FFLAGS.


I am attaching to this bug message a shell script that can reliably 
trigger the bug on an armhf system. Here is the output:


   $ ./gfortran-stack-clash-protection-armhf-bug.sh
   […]
   Program received signal SIGBUS: Access to an undefined portion of a memory 
object.

   Backtrace for this error:
   Bus error

Note that the bug does not happen on amd64. Also, it does not happen on 
armhf when the option -fstack-clash-protection is not used in the 
invocation of gfortran.


As far as I can tell, the problem is due to a global variable (tr) that 
is not correctly accessed in a private function (mypltr) of the x09f 
program. Here is what gdb tells me:


   $ gdb x09f
   […]
   (gdb) run -dev ps -o /dev/null
   Starting program: /home/rafael/fortran/x09f -dev ps -o /dev/null
   [Thread debugging using libthread_db enabled]
   Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

   Program received signal SIGBUS, Bus error.
   0x00400dfe in x09f::mypltr (x=0, y=1, xt=1, yt=34) at x09f.f90:193
   193 xt = tr(1) * x + tr(2) * y + tr(3)

My knowledge of Fortran and gfortran is way too scarce and, therefore, I 
cannot debug the problem deeper.  There may be a programming error in 
x09f.f90 or this may be a problem with gfortran on armhf when option 
-fstack-clash-protection is given.


Any help will be appreciated.

Best,

Rafael Laboissière


bug-1055750.tgz
Description: application/gtar-compressed

Bug#1055228: plplot: FTBFS on armhf (test segfault)

[Rafael Laboissière]

* Rafael Laboissière  [2023-11-09 17:11]:


[snip]

There may be a programming error in x09f.f90 or this may be a problem 
with gfortran on armhf. My knowledge of Fortran is almost non existent 
and I will need the help of experts, in order to fix the issue.


Regarding this issue, I filed a bug against the gfortran package: 
https://bugs.debian.org/1055750


Best,

Rafael Laboissière

Bug#1055750: gfortran: [armhf] Yield SIGBUS when compiling with -fstack-clash-protection

[Rafael Laboissière]

Package: gfortran
Version: 13.2.0-1
Severity: normal

Dear Maintainer,

The motivation for the present bug report comes from Bug#1055228. Since 
version 1.22.1 of dpkg-dev was released (on October 30), the plplot 
package FTBFS due to a failing compilation of one of Fortran examples, 
which is exercised as a unit test during package building.

The package built fine previously. The problem is triggered by the change 
in dpkg-buildflags, which now includes -fstack-clash-protection in 
FFLAGS.

I am attaching to this bug message a shell script that can reliably 
trigger the bug on an armhf system. Here is the output:

$ ./gfortran-stack-clash-protection-armhf-bug.sh
[…]
Program received signal SIGBUS: Access to an undefined portion of a memory 
object.

Backtrace for this error:
Bus error

Note that the bug does not happen on amd64. Also, it does not happen on 
armhf when the option -fstack-clash-protection is not used in the 
invocation of gfortran.

As far as I can tell, the problem is due to a global variable (tr) that 
is not correctly accessed in a private function (mypltr) of the x09f 
program. Here is what gdb tells me:

$ gdb x09f
[…]
(gdb) run -dev ps -o /dev/null
Starting program: /home/rafael/fortran/x09f -dev ps -o /dev/null
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGBUS, Bus error.
0x00400dfe in x09f::mypltr (x=0, y=1, xt=1, yt=34) at x09f.f90:193
193 xt = tr(1) * x + tr(2) * y + tr(3)

My knowledge of Fortran and gfortran is way too scarce and, therefore, I 
cannot debug the problem deeper.  There may be a programming error in 
x09f.f90 or this may be a problem with gfortran on armhf when option 
-fstack-clash-protection is given.

Any help will be appreciated.

Best,

Rafael Laboissière


gfortran-stack-clash-protection-armhf-bug.sh
Description: Bourne shell script

Bug#1055228: plplot: FTBFS on armhf (test segfault)

[Rafael Laboissière]

Control: tags -1 + confirmed help

* Gianfranco Costamagna  [2023-11-02 15:09]:


Source: plplot
Version: 5.15.0+dfsg2-6
Severity: serious

Hello, I found the package FTBFS on Ubuntu, checked on amdahl and found the 
same issue.

 /usr/bin/make  -f examples/fortran/CMakeFiles/x31f.dir/build.make 
examples/fortran/CMakeFiles/x31f.dir/build
 make[5]: Entering directory 
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
 make[5]: Nothing to be done for 'examples/fortran/CMakeFiles/x31f.dir/build'.
 make[5]: Leaving directory 
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
 [ 46%] Built target x31f
 /usr/bin/make  -f examples/CMakeFiles/test_fortran_svg.dir/build.make 
examples/CMakeFiles/test_fortran_svg.dir/depend
 make[5]: Entering directory 
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
 cd /home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf && /usr/bin/cmake -E 
cmake_depends "Unix Makefiles" /home/locutusofborg/plplot-5.15.0+dfsg2 
/home/locutusofborg/plplot-5.15.0+dfsg2/examples 
/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf 
/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/examples 
/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/examples/CMakeFiles/test_fortran_svg.dir/DependInfo.cmake
 "--color="
 make[5]: Leaving directory 
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
 /usr/bin/make  -f examples/CMakeFiles/test_fortran_svg.dir/build.make 
examples/CMakeFiles/test_fortran_svg.dir/build
 make[5]: Entering directory 
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
 cd /home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/examples && 
/usr/bin/cmake -E echo "Generate fortran results for svg device"
 Generate fortran results for svg device
 cd /home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/examples && 
env 
EXAMPLES_PREFIX=/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/examples
 SRC_EXAMPLES_PREFIX=/home/locutusofborg/plplot-5.15.0+dfsg2/examples 
OUTPUT_DIR=/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/examples/test_examples_output_dir
 /bin/bash 
/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/plplot_test/plplot-test.sh
 --verbose --front-end=fortran --device=svg
 Testing front-end fortran
 x16af
 x00f
 x01f
 x02f
 x03f
 x04f
 x05f
 x06f
 x07f
 x08f
 x09f
 /home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/plplot_test/test_fortran.sh: line 54: 3932208 Bus 
error   $DEBUG_CMD "$fortrandir"/x${index}f -dev $device -o 
"${OUTPUT_DIR}"/x${index}${lang}%n.$dsuffix $options 2> fortran_${device}_test.error >| 
"${OUTPUT_DIR}"/x${index}${lang}_${dsuffix}.txt

Program received signal SIGBUS: Access to an undefined portion of a memory 
object.

 Backtrace for this error:
 make[5]: *** [examples/CMakeFiles/test_fortran_svg.dir/build.make:388: 
examples/test_examples_output_dir/x00f01.svg] Error 1
 make[5]: *** Deleting file 'examples/test_examples_output_dir/x00f01.svg'
 make[5]: Leaving directory 
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
 make[4]: *** [CMakeFiles/Makefile2:5049: 
examples/CMakeFiles/test_fortran_svg.dir/all] Error 2
 make[4]: Leaving directory 
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
 make[3]: *** [CMakeFiles/Makefile2:7121: 
examples/CMakeFiles/test_noninteractive.dir/rule] Error 2
 make[3]: Leaving directory 
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
 make[2]: *** [Makefile:2243: test_noninteractive] Error 2
 make[2]: Leaving directory 
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
 make[1]: *** [debian/rules:55: override_dh_auto_test] Error 2
 make[1]: Leaving directory '/home/locutusofborg/plplot-5.15.0+dfsg2'
 make: *** [debian/rules:48: binary] Error 2


Full log attached


Thanks for this bug report. I can indeed reproduce the problem.

It was triggered by the recent change in dpkg-buildflags, which now 
includes -fstack-clash-protection in FFLAGS. This was done through commit 
1d46b351f [1], , intended to fix Bug#1054583 [2], and which got included 
in version 1.22.1 of dpkg-dev, released on October 30.


The Fortran example x09f.f90, which is exercised during the building of 
plplot, now fails on armhf, due to the use of the compiler option 
-fstack-clash-protection. I did not check whether this is also the case 
for arm64 and armel.


As far as I can tell, this is due to a global variable (tr) that is not 
correctly accessed in a private function (mypltr) of the x09f program.


There may be a programming error in x09f.f90 or this may be a problem 
with gfortran on armhf. My knowledge of Fortran is almost non existent 
and I will need the help of experts, in order to fix the issue.


Best,

Rafael Laboissière

 [1] https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=1d46b351f
 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054583

Bug#1054573: RM: praat [s390x ppc64] -- ROM; buggy on big endian systems

[Rafael Laboissière]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: pr...@packages.debian.org
Control: affects -1 + src:praat

Since upstream version 6.3.18 of Praat, changes have been introduced that 
make praat segfault at startup and make the package FTBFS on big endian 
architectures. This issue has been reported upstream [1], but there is no 
sign of reaction for now.

In the meanwhile, would it be possible to remove the package for s390x 
and ppc64 ? This is blocking the migration of praat into testing.

Thanks,

Rafael Laboissière

[1] https://github.com/praat/praat/issues/2545#issuecomment-1774119930

Bug#1053314: Depends: python3-h5py-mpi without python3-h5py

[Rafael Laboissière]

* Rafael Laboissière  [2023-10-09 08:30]:

[…] At least, I hope that version 3.1.0+dfsg2-5 will really fix 
Bug#1053314 and the h5py transition will be completed.


Unfortunately, it is still not working: 
https://ci.debian.net/data/autopkgtest/testing/arm64/x/xmds2/38836874/log.gz


I guess that the problem comes from the absence of /usr/bin/h5cc, which 
is in the hdf5-helpers package. This package, which is a dependency of 
libhdf5-dev, is not installed at the autopkgtest run.


I confess that I am confused and need your advice here. Currently, the 
xmds2 package depends on libhdf5-mpi-dev. Should hdf5-helpers or 
libhdf5-dev be added to Depends?


Best,

Rafael

Bug#1053314: Depends: python3-h5py-mpi without python3-h5py

[Rafael Laboissière]

Thanks for this detailed explanation, Drew. I released version 
3.1.0+dfsg2-5 of the xmds2 package before reading it. I added 
python3-h5py to Build-Depends and libhdf5-mpi-dev to Depends, as you 
suggested (even though there is a typo in the debian/changelog entry, 
stating eroneaously that libhdf5-serial-dev has been added; I will fix 
this in the next release).


I also used H5PY_ALWAYS_USE_MPI=1, as you mentioned.

As regards adding also python3-h5py-serial to Depends and putting a 
fallback code in place, I will have to give it a little thought. Maybe, I 
should discuss this with the upstream authors, to know what they thing. 
Let us see how things evolve. At least, I hope that version 3.1.0+dfsg2-5 
will really fix Bug#1053314 and the h5py transition will be completed.


Best,

Rafael

* Drew Parsons  [2023-10-09 02:23]:

Nilesh explained most of the situation correctly.  I can give some 
more background.It made sense (to me) to have h5py built against 
hdf5-mpi, since I figured that if you need the complexity of the hdf5 
file format then you probably want to use it in an MPI environment.


There was a complaint from a user though, who wanted to make use of a 
massive ensemble of HDF5 (h5py) serial jobs, and the small cost of 
loading up MPI support was interfering with their throughput.


So the compromise solution was to provide both builds, with a custom 
__init__.py to select the serial or MPI build depending on runtime 
environment.  If an MPI environment is detected then the h5py MPI 
build is loaded, otherwise the serial build is loaded.


If you want to run h5py in a serial process, then one might say you'd 
normally want the serial build.  As Nilesh noted, I put in a mechanism 
to load the MPI build if you really want to access the mpi build in a 
serial process (mpirun -n 1 is not a "serial" process as such, it's 
still an MPI environment even though using only 1 process).


The mechanism to force MPI loading is NOT to set OMPI_COMM_WORLD_SIZE. 
I recommend NOT doing that. I couldn't promise it won't mess up other 
things, certainly it will get in the way of an MPICH environment.  No, 
the mechanism for handling this for h5py is described in 
/usr/share/doc/python3-h5py/README.Debian: set H5PY_ALWAYS_USE_MPI=1


Is there a way to force h5py to import _debian_h5py_serial instead of 
_debian_h5py_mpi, via the generic h5py namespace?


It sounds like there is some confusion about how xmds2 should be used. 
Is it intended to be used as a serial process or MPI?  I noted in the 
bug report that xmds2 Depends: libhdf5-serial-dev.  Is it even using 
MPI?  If you want it to be using h5py-serial, then why does xmsd2 
depend on python3-h5py-mpi?


It seems to me that xmds2's h5py dependency should be the same as its 
hdf5 dependency.  If it uses libhdf5-serial then should it be 
depending on just python3-h5py (implying python3-h5py-serial, make it 
explicit if needed) and not depend on python3-h5py-mpi?


If xmds2 is intended to be flexible, equally happy in serial and MPI 
environments (and can actually make use of h5py-mpi) then perhaps the 
dependency should cover all cases, 
 Depends: python3-h5py, python3-h5py-serial, python3-h5py-mpi 
all three explicitly, since otherwise one or the other of -serial or 
-mpi would be missed.


The problem raises interesting questions about h5py configuration. I 
set up it so you could choose how you want it to work, with or without 
MPI support.  But it looks like an edge case is missing: it's failing 
in serial jobs if you chose to set up your installation with 
python3-h5py-mpi and explicitly don't want python3-h5py-serial (unless 
you always set H5PY_ALWAYS_USE_MPI). Perhaps I should add an 
additional fallback to try h5py-mpi if h5py-serial is not found (in a 
serial job), the same way that h5py-serial is loaded as a fallback in 
an MPI job if h5py-mpi is not found. On the other hand maybe that just 
hides the real problem, that h5py-serial was not installed when 
actually it was wanted after all.  The ImportError correctly 
identifies that case.





On 2023-10-08 17:38, Nilesh Patra wrote:

Hello,

On 10/8/23 17:22, Rafael Laboissière wrote:

Ok, I tried to fix the building problem by including python3-h5py,
alongside with python3-h5py-mpi, into Build-Depends, as suggested
by Drew, but the xmds2 package FTBFS.

Here is a way to reproduce the problem without building the package:

  $ dpkg -l python3-h5py\*
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name    Version  Architecture Description
  
+++-===---===
  ii  python3-h5py    3.9.0-3  all 
general-purpose Python interface to hdf5 
  ii  python3-h5py-mpi    3.9.0-3  amd64    
general-purpose Python interface to hd

Bug#1052973: marked as done (octave-image: FTBFS: make: *** [debian/rules:12: binary] Error 1)

[Rafael Laboissière]

* Sébastien Villemot  [2023-10-07 08:23]:


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.


Ok, thanks for the advise.

Also, it may be possible that octave-image builds against an old 
version of octave-dev that was not affected by the bug.


Apparently (but I did not check it thoroughly) , the “bug” in mkoctifle 
was always there, but has only been exposed when the Debian build tools 
started injecting some new -f* options into CFLAGS that was propagated 
into the call of mkoctfile. This confuses mkoctfile's options parser, 
resulting into a wrong behavior.


Best,

Rafael Laboissière

Bug#1053314: Depends: python3-h5py-mpi without python3-h5py

[Rafael Laboissière]

Ok, I tried to fix the building problem by including python3-h5py, 
alongside with python3-h5py-mpi, into Build-Depends, as suggested by 
Drew, but the xmds2 package FTBFS.


Here is a way to reproduce the problem without building the package:

  $ dpkg -l python3-h5py\*
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ NameVersion  Architecture Description
  
+++-===---===
  ii  python3-h5py3.9.0-3  all  general-purpose Python 
interface to hdf5
  ii  python3-h5py-mpi3.9.0-3  amd64general-purpose Python 
interface to hdf5 (Python 3 MPI)
  un  python3-h5py-serial   (no description available)
  $ echo 'import h5py' | python3
  Traceback (most recent call last):
File "", line 1, in 
File "/usr/lib/python3/dist-packages/h5py/__init__.py", line 21, in 
  from . import _debian_h5py_serial as _h5py
  ImportError: cannot import name '_debian_h5py_serial' from partially 
initialized module 'h5py' (most likely due to a circular import) 
(/usr/lib/python3/dist-packages/h5py/__init__.py)

Is there a way to force h5py to import _debian_h5py_serial instead of 
_debian_h5py_mpi, via the generic h5py namespace?


Best,

Rafael

* Rafael Laboissière  [2023-10-08 10:27]:


* Nilesh Patra  [2023-10-04 02:24]:


On Sun, 01 Oct 2023 15:25:43 +0200 Drew Parsons  wrote:

Package: xmds2
Version: 3.1.0+dfsg2-4
Severity: serious
Justification: debci

xmds2 Depends: python3-h5py-mpi without depending on python3-h5py

python3-h5py-mpi only provides the h5py._debian_h5py_mpi 
namespace, not h5py.  Hence tests using h5py without specifying 
_debian_h5py_mpi fail.  This is the case with h5py 3.9.0. (Marking 
Severity: serious due to debci failure)


python3-h5py provides the h5py namespace, so if xmds2 strictly 
needs the mpi build, but accessing via the generic h5py namespace, 
then the Depends should specify both packages  Depends: 
python3-h5py python3-h5py-mpi Note there seems to be an 
inconsistency in the xmds2 package configuration. It has MPI 
dependencies (python3-h5py-mpi, also mpi-default-dev, 
libfftw3-mpi-dev), but with respect to hdf5 it has Depends: 
libhdf5-serial-dev Should that instead be Depends: libhdf5-mpi-dev 
?


Seems you're right, taking a brief look at it. I've CC'ed Rafael to further 
comment/upload a fix.

@Rafael, this seems to be the last blocker on h5py transition to 
testing, so prompt action would be really cool!


Thanks to Drew for the bug report and Nilesh for the remainder. I was 
out of town these last days and could not react to your messages. I am 
taking a look at the issue right now.


Best,

Rafael

Bug#1053314: Depends: python3-h5py-mpi without python3-h5py

[Rafael Laboissière]

* Nilesh Patra  [2023-10-04 02:24]:


On Sun, 01 Oct 2023 15:25:43 +0200 Drew Parsons  wrote:

Package: xmds2
Version: 3.1.0+dfsg2-4
Severity: serious
Justification: debci

xmds2 Depends: python3-h5py-mpi without depending on python3-h5py

python3-h5py-mpi only provides the h5py._debian_h5py_mpi namespace, 
not h5py.  Hence tests using h5py without specifying _debian_h5py_mpi 
fail.  This is the case with h5py 3.9.0. (Marking Severity: serious due 
to debci failure)


python3-h5py provides the h5py namespace, so if xmds2 strictly needs 
the mpi build, but accessing via the generic h5py namespace, then the 
Depends should specify both packages 
 Depends: python3-h5py python3-h5py-mpi 
Note there seems to be an inconsistency in the xmds2 package 
configuration. It has MPI dependencies (python3-h5py-mpi, also 
mpi-default-dev, libfftw3-mpi-dev), but with respect to hdf5 it has 
Depends: libhdf5-serial-dev 
Should that instead be 
Depends: libhdf5-mpi-dev ?


Seems you're right, taking a brief look at it. I've CC'ed Rafael to further 
comment/upload a fix.

@Rafael, this seems to be the last blocker on h5py transition to testing, so prompt action would 
be really cool!


Thanks to Drew for the bug report and Nilesh for the remainder. I was 
out of town these last days and could not react to your messages. I am 
taking a look at the issue right now.


Best,

Rafael

Bug#1052973: marked as done (octave-image: FTBFS: make: *** [debian/rules:12: binary] Error 1)

[Rafael Laboissière]

Hi,

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 ?


Best,

Rafael

* Debian Bug Tracking System  [2023-09-30 19:09]:

Your message dated Sat, 30 Sep 2023 19:04:59 + 
with message-id  
and subject line Bug#1052973: fixed in octave 8.3.0-3 
has caused the Debian Bug report #1052973, 
regarding octave-image: FTBFS: make: *** [debian/rules:12: binary] Error 1 
to be marked as done.


This means that you claim that the problem has been dealt with. 
If this is not the case it is now your responsibility to reopen the 
Bug report if necessary, and/or fix the problem forthwith.


(NB: If you are a system administrator and have no idea what this 
message is talking about, this may indicate a serious mail system 
misconfiguration somewhere. Please contact ow...@bugs.debian.org 
immediately.)



--
1052973: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052973
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



From: Lucas Nussbaum 
Subject: octave-image: FTBFS: make: *** [debian/rules:12: binary] Error 1
Date: Tue, 26 Sep 2023 15:46:13 +0200
To: sub...@bugs.debian.org
Message-ID: 

Source: octave-image
Version: 2.14.0-4
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230925 ftbfs-trixie

Hi,

During a rebuild of all packages in sid, your package failed to build 
on amd64.



Relevant part (hopefully):

Summary: 2073 tests, 1744 passed, 36 known failures, 0 skipped
Some tests failed.  Giving up...
make: *** [debian/rules:12: binary] Error 1



The full build log is available from: 
http://qa-logs.debian.net/2023/09/25/octave-image_2.14.0-4_unstable.log


All bugs filed during this archive rebuild are listed at: 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20230925;users=lu...@debian.org 
or: 
https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20230925=lu...@debian.org=1=1=1=1#results


A list of current common problems and possible solutions is available at 
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!


If you reassign this bug to another package, please mark it as 'affects'-ing 
this package. See https://www.debian.org/Bugs/server-control#affects


If you fail to reproduce this, please provide a build log and diff it with mine 
so that we can identify if something relevant changed in the meantime.



From: Debian FTP Masters 
Subject: Bug#1052973: fixed in octave 8.3.0-3
Date: Sat, 30 Sep 2023 19:04:59 +
To: 1052973-cl...@bugs.debian.org
Reply-To: Rafael Laboissière 
Message-Id: 

Source: octave
Source-Version: 8.3.0-3
Done: Rafael Laboissière 

We believe that the bug you reported is fixed in the latest version of 
octave, which is due to be installed in the Debian FTP archive.


A summary of the changes between this version and the previous one is 
attached.


Thank you for reporting the bug, which will now be closed.  If you 
have further comments please address them to 1052...@bugs.debian.org, 
and the maintainer will reopen the bug report if appropriate.


Debian distribution maintenance software 
pp. 
Rafael Laboissière  (supplier of updated octave package)


(This message was generated automatically at their request; if you 
believe that there is a problem with it please contact the archive 
administrators by mailing ftpmas...@ftp-master.debian.org)



-BEGIN PGP SIGNED MESSAGE- 
Hash: SHA256


Format: 1.8
Date: Sat, 30 Sep 2023 10:35:07 -0300
Source: octave
Architecture: source
Version: 8.3.0-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Octave Group 
Changed-By: Rafael Laboissière 
Closes: 1052973
Changes: 
octave (8.3.0-3) unstable; urgency=medium 
. 
  * d/p/mkoctfile-skip-options.patch: Update patch. 
Thanks to Markus Mützel  (Closes: #1052973) 
Checksums-Sha1: 
cede5a06bc26a1717cf59f29e3daf0a132867020 3452 octave_8.3.0-3.dsc 
44d80983a0848c228544957a373b2a72422f8225 63276 octave_8.3.0-3.debian.tar.xz 
Checksums-Sha256: 
5c725301cd046ef5a62e3d6039ad0e7ad333864c8c0a578f6c9a72bc21080f4f 3452 octave_8.3.0-3.dsc 
34f4f8d890a5a9268102241a2847d76d2bb1e72c9738ea5151a023a7d54f95fa 63276 octave_8.3.0-3.debian.tar.xz 
Files: 
a4a7d3b2ebfee85ae8d90a9c6fab6e8c 3452 math optional octave_8.3.0-3.dsc 
1bdf47d3560fdbf1bbd656eacaa7307f 63276 math optional octave_8.3.0-3.debian.tar.xz


-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEEP0ZDkUmP6HS9tdmPISSqGYN4XJAFAmUYaOoSHHJhZmFlbEBk 
ZWJpYW4ub3JnAAoJECEkqhmDeFyQzuIQAIVEaYdWmkJjSUx2D+4EBLKxOEqDOZhv 
4GlAOIvYCRwM/OOe8UQJY/cXAg89KVMFKGnewuAljKz+sR7hGdt4EQp1GAcujAsQ 
QXHqh3UhNNn6t8oiDE5LXyu8I8Apy/EqdNss1cLQWq03D4WVNP2YttAEfXs3KRd5 
NJQRMEZ8QIgEGeUad80lLtKqIQoIM75iUMUKcwPx7BwgfAp3PJDV6tuY5CJzseFc 
9cyzgyiZGHlVoSB26D7LSERyGejm3osrwNpv0d4p8+QTFUblDBXhXNyjIR5Tw

Bug#1052973: octave-image: FTBFS: make: *** [debian/rules:12: binary] Error 1

[Rafael Laboissière]

Control: reassign -1 octave-dev 8.3.0-1
Control: affects -1 octave-image
Control: notfound -1 octave-image/2.14.0-4
Control: forwarded -1 https://savannah.gnu.org/bugs/index.php?64725

* Rafael Laboissière  [2023-09-26 22:00]:


Control: tags -1 + confirmed upstream

* Lucas Nussbaum  [2023-09-26 15:46]:


 Source: octave-image
 Version: 2.14.0-4
 Severity: serious
 Justification: FTBFS
 Tags: trixie sid ftbfs
 User: lu...@debian.org
 Usertags: ftbfs-20230925 ftbfs-trixie

Hi,

During a rebuild of all packages in sid, your package failed to 
build on amd64.



Relevant part (hopefully):


 Summary: 2073 tests, 1744 passed, 36 known failures, 0 skipped
 Some tests failed.  Giving up...
 make: *** [debian/rules:12: binary] Error 1


I think that this problem is triggered by a changing in behavior of 
the mkoctfile program, in the way it process its arguments, between 
versions 8.2 and 8.3 of Octave. I will try to get to this, as time 
permits.


As I suspected, this bug is related to Bug#1050082 and is caused by a 
misbehavior of mkoctfile, a tool used to build the *.oct files needed by 
Octave, when options -f* are given to it.


I have already filed a bug report upstream and I am hereby reassigning 
the present bug report to the octave-dev package.


Best,

Rafael Laboissière

Bug#1052973: octave-image: FTBFS: make: *** [debian/rules:12: binary] Error 1

[Rafael Laboissière]

Control: tags -1 + confirmed upstream

* Lucas Nussbaum  [2023-09-26 15:46]:


Source: octave-image
Version: 2.14.0-4
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230925 ftbfs-trixie

Hi,

During a rebuild of all packages in sid, your package failed to build 
on amd64.



Relevant part (hopefully):


 Summary: 2073 tests, 1744 passed, 36 known failures, 0 skipped
 Some tests failed.  Giving up...
 make: *** [debian/rules:12: binary] Error 1


I think that this problem is triggered by a changing in behavior of the 
mkoctfile program, in the way it process its arguments, between versions 
8.2 and 8.3 of Octave. I will try to get to this, as time permits.


Best,

Rafael Laboissière

Bug#1042933: octave-statistics autopkg tests fail in unstable on amd64

[Rafael Laboissière]

* 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?

Rafael Laboissière

Bug#1042933: octave-statistics autopkg tests fail in unstable on amd64

[Rafael Laboissière]

* 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.

Rafael Laboissière

Bug#1050796: octave-interval tests need an update with mpfr4 4.2.1

[Rafael Laboissière]

Control: forwarded -1 https://savannah.gnu.org/bugs/?64607
Control: tags -1 + patch confirmed upstream

Thank you for the bug report, Matthias.

This issue has been reported in the upstream bug tracking system. The fix 
seems to be trivial, cf patch attached to this message. Let us see if a 
new upstream version of interval package for Octave is released soon. If 
not, I will released a patched version of octave-interval.


Best,

Rafael Laboissière

* Matthias Klose  [2023-08-29 12:20]:


Package: octave-interval
Version: 3.2.1-5
Severity: serious
Tags: sid trixie
Forwarded: https://savannah.gnu.org/bugs/index.php?64607
Affects: src:mpfr4

the octave-interval tests need an update with mpfr4 4.2.1:

see 
https://ci.debian.net/data/autopkgtest/testing/amd64/o/octave-interval/37232402/log.gz



Description: Adjust BISTs in src/intervaltotext.cc for MPFR v2.4.1
 GNU MPFR had a bug in the formatting function, causing the "+" flag
 to be ignored for Inf and NaN. It is now honored in version 2.4.1.
 The BISTs in src/intervaltotext.cc are fixed for the coping with the
 correct behavior.
Author: Rafael Laboissière 
Bug: https://savannah.gnu.org/bugs/?64607
Bug-Debian: https://bugs.debian.org/1050796
Forwarded: not-needed
Last-Update: 2023-08-29

--- octave-interval-3.2.1.orig/src/intervaltotext.cc
+++ octave-interval-3.2.1/src/intervaltotext.cc
@@ -1281,7 +1281,7 @@ DEFUN_DLD (intervaltotext, args, nargout
 %!assert (intervaltotext (infsup (), "[cg]"), "[empty]");
 
 %!assert (intervaltotext (infsup (-inf, inf), "[g]"), "[Entire]");
-%!assert (intervaltotext (infsup (-inf, inf), "[

Bug#1050082: octave-image: could FTBFS due to missing .oct files

[Rafael Laboissière]

Control: tags -1 - moreinfo unreproducible ftbfs patch
Control: tags -1 + confirmed upstream
Control: reassign -1 octave-dev 8.3.0-1
Control: affects -1 octave-image
Control: notfound -1 octave-image/2.14.0-4
Control: forwarded -1 https://savannah.gnu.org/bugs/index.php?64590

* Graham Inggs  [2023-08-24 11:37]:


Hi Rafael

On Thu, 24 Aug 2023 at 10:38, Rafael Laboissière  wrote:

Thanks for your bug report, but I am afraid I cannot reproduce this
bug on my sid system.

Could you please post the full log for the failing build?


Here are build logs from the recent rebuild against octave-abi-58 in 
Ubuntu 23.10 [1], as well as a test rebuild in Ubuntu 23.04 [2] from 
2023-03-24.


The builds for riscv64 succeeded because they were built with 
'nocheck', but the logs do show the presence of the incorrect files 
connectivity.oct and strel.oct in the package contents.


Regards 
Graham



 [1] https://launchpad.net/ubuntu/+source/octave-image/2.14.0-4build1
 [2] 
https://launchpad.net/ubuntu/+archive/test-rebuild-20230324-lunar/+sourcepub/14575637/+listing-archive-extra


Thanks for the links, Graham.

After inspection, I concluded that the problem comes from mkoctfile. I 
am hereby reassign this bug report. I also reported it upstream.


Even though your patch ”fixes” the problem for the octave-image package, 
I would prefer that the upstream developers of Octave cope with the 
issue. Hence, I am thereby removing tags ftbfs and patch.


Best,

Rafael Laboissière

Bug#1050082: octave-image: could FTBFS due to missing .oct files

[Rafael Laboissière]

Control: tags -1 + unreproducible moreinfo

* Graham Inggs  [2023-08-19 13:27]:


Source: octave-image
Version: 2.14.0-4
Tags: ftbfs patch

Hi Maintainer

While rebuilding octave-* packages for the octave-abi-58 transition in 
Ubuntu 23.10, octave-image FTBFS due to missing .oct files.  I've 
copied some of the output below.


Upon investigation, I found the following files were not built:

 bwconncomp.oct
 bwlabeln.oct
 conndef.oct
 imerode.oct
 imreconstruct.oct
 watershed.oct

Instead, the following were:

 connectivity.oct
 strel.oct

I was able to solve it with a simple patch:

 --- a/src/Makefile.in
 +++ b/src/Makefile.in
 @@ -24,10 +24,10 @@
 $(FLAGGED_MKOCTFILE) -c $<

 $(conn_dependent): %.oct: %.cc connectivity.o
 -$(FLAGGED_MKOCTFILE) $^
 +$(FLAGGED_MKOCTFILE) $^ -o $@

 $(strel_dependent): %.oct: %.cc strel.o
 -$(FLAGGED_MKOCTFILE) $^
 +$(FLAGGED_MKOCTFILE) $^ -o $@

 %.oct: %.cc
 $(FLAGGED_MKOCTFILE) $<

I'm not sure what changed, or when, but I was able to reproduce this 
failure in the Ubuntu 23.04 release.


Regards

Graham

 ! test failed
 'conndef' undefined near line 48, column 12

 The ’conndef’ function belongs to the image package from Octave Forge
 which seems to not be installed in your system.


Thanks for your bug report, but I am afraid I cannot reproduce this 
bug on my sid system.


Could you please post the full log for the failing build?

Best,

Rafael Laboissière

Bug#1049935: jed: tabs are being inserted by the indent line routine when USE_TABS is off

[Rafael Laboissière]

Control: tags -1 + unreproducible moreinfo

* Brad Lanam  [2023-08-16 17:59]:


Package: jed
Version: 1:0.99.20~pre.178+dfsg-6

I have been using jed for a very long time, and this current release is now 
inserting tab characters when an automatic indent is done (C mode).  This 
wasn't the case before.


I have  USE_TABS=0 and TAB=0.  The tab key works as I want it to, inserting 
only spaces (I do not have it attached to the indent line hook), but when I 
press the enter key, the indent-line hook executes and tab characters are 
inserted.


The enter key / indent line hook did not insert tab characters in version : 
jed 1:0.99.19-8 (debian bullseye).


 PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
 NAME="Debian GNU/Linux"
 VERSION_ID="12"
 VERSION="12 (bookworm)"
 VERSION_CODENAME=bookworm
 ID=debian


Thanks for your bug report, but I am afraid I cannot reproduce this bug.

I am using:

$ jed --version
jed version: pre0.99.20-180/Unix
Compiled with GNU C 12.2
S-Lang version: 2.3.3

jed compile-time options:
 +LINE_ATTRIBUTES +BUFFER_LOCAL_VARS +SAVE_NARROW +TTY_MENUS
 +EMACS_LOCKING +MULTICLICK +SUBPROCESSES +DFA_SYNTAX +ABBREVS
 +COLOR_COLUMNS +LINE_MARKS +GPM_MOUSE +IMPORT

Using JED_ROOT=/usr/share/jed

(from Debian package version 0.99.20~pre.180+dfsg-2)

When I start jed in the following way, with an non-existing file test.c 
(and avoiding my own ~/.jedrc):


$ jed -n test.c

and I type “int main() {”, I see the following:

F10 key ==> File   Edit   Mode   Search   Buffers   Windows   System   Help
int main()
{
   █

(where character “█” indicates the prompt)

If I continue typing “int a;“ and the enter key, then I see:

F10 key ==> File   Edit   Mode   Search   Buffers   Windows   System   Help
int main()
{
   int a;
   █

No tab is inserted, only three spaces before the prompt.

I also tried to start jed without the “-n” option and with this 
minimalistic ~/.jedrc file:


USE_TABS=0;
TAB=0;

but the results are the same.

I will need more information from you, in order to debug this issue.

Best,

Rafael Laboissière

Bug#1042933: octave-statistics autopkg tests fail in unstable on amd64

[Rafael Laboissière]

* 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.


Best,

Rafael Laboissière

Bug#1038343: fim: Depends on SDL 1.2

[Rafael Laboissière]

* Simon McVittie  [2023-06-22 01:20]:


On Sun, 18 Jun 2023 at 22:27:26 +0200, Rafael Laboissière wrote:

* Simon McVittie  [2023-06-18 17:10]:

In the meantime, please could you check whether fim works as
intended with libsdl1.2-compat-shim, which is meant to be a drop-in
replacement? I'm trying to track whether there are any blockers to
replacing "classic" SDL 1.2.


if you think I 
should upload a new version of the package with that build-dependency, 
please tell me


No, please *don't* change the build-dependency. I'm hoping to make 
sdl12-compat take over the libsdl1.2debian and libsdl1.2-dev binary 
package names from classic SDL 1.2, so that no source changes or 
recompilation are needed.


Ok, thaks.

Best,

Rafael Laboissière

Bug#1038343: fim: Depends on SDL 1.2

[Rafael Laboissière]

* Michele Martone  [2023-06-21 23:43]:


On 20230618@22:27, Rafael Laboissière wrote:

* Simon McVittie  [2023-06-18 17:10]:


On Sat, 17 Jun 2023 at 21:11:25 +0200, Rafael Laboissière wrote:

Thanks for this bug report. I forwarded it upstream and I am also sending
this message with Cc to the upstream author.


Thanks. In the meantime, please could you check whether fim works as 
intended with libsdl1.2-compat-shim, which is meant to be a drop-in 
replacement? I'm trying to track whether there are any blockers to 
replacing "classic" SDL 1.2.


The package builds fine against libsdl1.2-compat-dev on my sid amd64 system. 
All tests also passed, but I am not sure this would be enough. I would 
rather let the upstream author have the final word, but if you think I 
should upload a new version of the package with that build-dependency, 
please tell me.


Dear Rafael, dear Simon,

If using the compatibility layer and:

* `make tests` passes


It is not straightforward for me to do this test, because I build the 
package on a remote system, and SDL does not play well with xvfb-run.


On the other hand the unit tests that are exercised in file 
debian/test/run-tests succeeded. Essentially, this corresponds to:


make -C src/testdir

* you can start `fim -o sdl $FILE` and move around by pressing 
  n, p, then enlarging/shrinking with + and -, using the arrows 
  to scroll, and : to start the console, and after : typing 
  'quit' and it quits, plus the window is resizable


The window starts with the image flushed to the bottom right, and not 
centered as with the previous version.


Keys n, p, + and - work correctly. The arrow keys work also, but there is 
some flickering that I did not observe previously.


Typing ":quit" works, but there is no echo of the console at the 
bottom of the window.


So, it mainly works but the behavior with the compatibility version of 
the SDL library is not exactly the same as with the old version of SDL.


Best,

Rafael

Bug#1038343: fim: Depends on SDL 1.2

[Rafael Laboissière]

* Simon McVittie  [2023-06-18 17:10]:


On Sat, 17 Jun 2023 at 21:11:25 +0200, Rafael Laboissière wrote:

Thanks for this bug report. I forwarded it upstream and I am also sending
this message with Cc to the upstream author.


Thanks. In the meantime, please could you check whether fim works as 
intended with libsdl1.2-compat-shim, which is meant to be a drop-in 
replacement? I'm trying to track whether there are any blockers to 
replacing "classic" SDL 1.2.


The package builds fine against libsdl1.2-compat-dev on my sid amd64 
system. All tests also passed, but I am not sure this would be enough. I 
would rather let the upstream author have the final word, but if you 
think I should upload a new version of the package with that 
build-dependency, please tell me.


Best,

Rafael Laboissière

Bug#1038343: fim: Depends on SDL 1.2

[Rafael Laboissière]

Control: forwarded -1 https://savannah.nongnu.org/bugs/index.php?64313

Hello Simon,

Thanks for this bug report. I forwarded it upstream and I am also sending 
this message with Cc to the upstream author.


Best,

Rafael

* Simon McVittie  [2023-06-17 10:28]:


Source: fim
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which 
is unmaintained upstream.


If possible, please port this package to SDL 2 and close this bug. There 
is a migration guide at , 
and examples of successful ports from SDL 1.2 to SDL 2 can be found in 
the commit history of packages like darkplaces and ioquake3.


If it is not possible to port to SDL 2, please test the package with 
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave 
this bug open to track the package as still using SDL 1.2 APIs.


libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2 
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2 
library in some other distributions like Fedora and Arch, and my intention 
is to do the same in Debian during the trixie release cycle.


Please don't change dependencies from libsdl1.2debian to 
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev. 
The -compat packages have Provides for the old package names, and my 
intention is to make a future version of sdl12-compat take over the old 
package names, to minimize the changes that are required in dependent 
packages.


The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment, 
  such as "GNOME on Xorg" or XFCE. 
  ($XDG_RUNTIME_DIR/wayland-* should not exist) 
2. Install libsdl1.2-compat-shim and run the program in a Wayland 
  environment such as GNOME's default mode, using Xwayland. 
  ($XDG_RUNTIME_DIR/wayland-* should exist) 
3. Install libsdl1.2-compat-shim and run the program in a Wayland 
  environment, but this time with environment variable 
  SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface 
  (this is not currently the default for SDL 2). 
4. Install libsdl1.2-compat-dev and recompile the package.


Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if 
the package contains programs that are setgid games. See 
 
for more information.


If any of those fail, please report it as a bug in the 
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate, 
with "affects" pointing to the program that is affected.


Thanks, 
   smcv


--
This bug report is part of a mass-bug-filing:

Bug#1037988: vlfeat: FTBFS when graphicsmagick-imagemagick-compat is installed and imagemagick is not

[Rafael Laboissière]

Source: vlfeat
Version: 0.9.21+full-1
Severity: normal
Tags: ftbfs

Dear Maintainer,

Package vlfeat build-depends on imagemagick. This dependency will be 
satified when package graphicsmagick-imagemagick-compat (which provides 
the virtual package imagemagick) is installed.

However, when the real package imagemagick is not installed, vlfeat 
FTBFS, because it needs the file /etc/ImageMagick-6/policy.xml, 
referenced in debian/rules. Actually, this file is in package 
imagemagick-6-config, which is a dependency of imagemagick.

I think that "Build-Conflicts: graphicsmagick-imagemagick-compat" is 
necessary for fixing the issue.

Best,

Rafael Laboissière

Bug#1035684: swig: Update octave files for Octave v8

[Rafael Laboissière]

* Rafael Laboissière  [2023-05-07 20:38]:


Source: swig
Version: 4.1.0-0.2
Severity: important
Tags: upstream patch

Dear Maintainer,

Version 8 of the octave package is now in experimental and will be 
uploaded to unstable as soon as bookworm is released. The version of the 
swig package currently in unstable (4.1.0-0.2) produces Octave bindings 
that do not work with Octave 8. This makes packages that build Octave 
bindings via SWIG, like plplot, fail to build from source.


This issue has been reported upstream [1] and a patch is available via a 
pull request on GitHub [2]. I prepared a patch for the swig package, 
which has been submitted as a merge request on Salsa.d.o.


With this patched version, the plplot package builds correctly against 
Octave 8.


I am hereby setting the severity of this bug report to "important", but 
it should be raised to "serious" when Octave 8 will be uploaded to 
unstable.


Best,

Rafael Laboissière

 [1] https://github.com/swig/swig/issues/2508
 [2] https://github.com/swig/swig/pull/2512.patch
 [3] https://salsa.debian.org/debian/swig/-/merge_requests/8


If nobody objects, I will soon merge the pull request mentioned above and 
will do an NMU of the swig package with the mentioned patch.


Now that bookworm is released, Octave 8 is ready to enter unstable and 
this will prevent the transition into testing because the plplot 
package (which yields the binary package octave-plplot) FTBFS against 
the current version of swig in sid.


Best regards,

Rafael Laboissière

Bug#1036787: unblock: jed/0.99.20~pre.178+dfsg-6

[Rafael Laboissière]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: 1035...@bugs.debian.org, j...@packages.debian.org
Control: affects -1 + src:jed

Please unblock package jed.

The version in unstable fixes the RC bug #1036096. This bug was intended 
to be fixed in version jed/0.99.20~pre.178+dfsg-5 of the package, but was 
reopened by Andreas Beckmann, who spotted a problem in the 
{jed,xjed}.maintscript files, namely the lack of epoch in version 
numbers.

I am attaching to this message the debdiff between versions 
0.99.20~pre.178+dfsg-5 and -6.

unblock jed/0.99.20~pre.178+dfsg-6

Best,

Rafael Laboissière
diff -Nru jed-0.99.20~pre.178+dfsg/debian/changelog 
jed-0.99.20~pre.178+dfsg/debian/changelog
--- jed-0.99.20~pre.178+dfsg/debian/changelog   2023-05-16 14:19:52.0 
-0300
+++ jed-0.99.20~pre.178+dfsg/debian/changelog   2023-05-25 04:40:36.0 
-0300
@@ -1,3 +1,15 @@
+jed (1:0.99.20~pre.178+dfsg-6) unstable; urgency=medium
+
+  * d/*.maintscript: Add epoch to the version number in symlink_to_dir setting.
+The version in the {jed,xjed}.maintscript files is bumped to
+1:0.99.20~pre.178+dfsg-6~, such that the cleanup is performed on both
+upgrades from stable to testing (missed cleanup) and from testing to
+unstable (fixed cleanup).
+Thanks to Andreas Beckmann for spotting the problem and suggesting its 
solution.
+(Closes: #1036096)
+
+ -- Rafael Laboissière   Thu, 25 May 2023 04:40:36 -0300
+
 jed (1:0.99.20~pre.178+dfsg-5) unstable; urgency=medium
 
   * Add files d/{jed,xjed}.maintscript.
diff -Nru jed-0.99.20~pre.178+dfsg/debian/jed.maintscript 
jed-0.99.20~pre.178+dfsg/debian/jed.maintscript
--- jed-0.99.20~pre.178+dfsg/debian/jed.maintscript 2023-05-16 
14:19:52.0 -0300
+++ jed-0.99.20~pre.178+dfsg/debian/jed.maintscript 2023-05-25 
04:32:20.0 -0300
@@ -1 +1 @@
-symlink_to_dir /usr/share/doc/jed jed-common 0.99.20~pre.151+dfsg-1~
+symlink_to_dir /usr/share/doc/jed jed-common 1:0.99.20~pre.178+dfsg-6~
diff -Nru jed-0.99.20~pre.178+dfsg/debian/xjed.maintscript 
jed-0.99.20~pre.178+dfsg/debian/xjed.maintscript
--- jed-0.99.20~pre.178+dfsg/debian/xjed.maintscript2023-05-16 
14:19:52.0 -0300
+++ jed-0.99.20~pre.178+dfsg/debian/xjed.maintscript2023-05-25 
04:32:11.0 -0300
@@ -1 +1 @@
-symlink_to_dir /usr/share/doc/xjed jed-common 0.99.20~pre.151+dfsg-1~
+symlink_to_dir /usr/share/doc/xjed jed-common 1:0.99.20~pre.178+dfsg-6~

Bug#1035843: unblock: jed/0.99.20~pre.178+dfsg-4

[Rafael Laboissière]

Control: tags -1 - moreinfo

* Paul Gevers  [2023-05-15 21:11]:


Control: tags -1 moreinfo

On 10-05-2023 07:33, Rafael Laboissière wrote:

The version in unstable fixes the RC bug #1035839. I introduced a
regression in the d/jed-common.preinst script when I tried to fix
Bug#1035780.


And a new RC bug against the version in unstable got filed today. 
Please remove the moreinfo tag once that bug has been triaged and/or 
fixed.


Bug#1036096 is fixed in version 0.99.20~pre.178+dfsg-5, now in unstable.

I am hereby removing the moreinfo tag, as you suggested. Please, tell me 
whether anything else should be done to unblock the jed package.


Thanks,

Rafael

Bug#1035839: closed by Debian FTP Masters (reply to Rafael Laboissière ) (Bug#1035839: fixed in jed 1:0.99.20~pre.178+dfsg-4)

[Rafael Laboissière]

Great, thanks for your help!

* Axel Beckert  [2023-05-10 13:20]:


Hi Rafael,

Debian Bug Tracking System wrote:

 jed (1:0.99.20~pre.178+dfsg-4) unstable; urgency=medium
 .
   * d/jed-common.preinst: Avoid non-fatal abortion of the script.
 Thanks to Axel Beckert for the fix (Closes: #1035839)


Thanks! Just wanted to confirm that I could now upgrade jed and 
jed-common without issues from 1:0.99.20~pre.178+dfsg-1 to 
1:0.99.20~pre.178+dfsg-4.


Regards, Axel

 --
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
 : :' :  |  Debian Developer, ftp.ch.debian.org Admin
 `. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1035843: unblock: jed/0.99.20~pre.178+dfsg-4

[Rafael Laboissière]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: 1035...@bugs.debian.org, j...@packages.debian.org
Control: affects -1 + src:jed

Please unblock package jed.

The version in unstable fixes the RC bug #1035839. I introduced a 
regression in the d/jed-common.preinst script when I tried to fix 
Bug#1035780.

I am attaching to this message the debdiff between versions 
0.99.20~pre.178+dfsg-1 and -4. The debian/changelog is pretty large, 
because some changes for version -2 (in an attempt to fix Bug#1035692 
that caused Bug#1035780) where canceled in version -3. The final 
difference is quite small: one line removed from debian/rules, one line 
removed from debian/jed-common.links, and a new small file added 
(debian/jed-common.preinst).

unblock jed/0.99.20~pre.178+dfsg-4

Best,

Rafael Laboissière
diff -Nru jed-0.99.20~pre.178+dfsg/debian/changelog 
jed-0.99.20~pre.178+dfsg/debian/changelog
--- jed-0.99.20~pre.178+dfsg/debian/changelog   2023-01-10 15:10:00.0 
-0300
+++ jed-0.99.20~pre.178+dfsg/debian/changelog   2023-05-10 01:20:42.0 
-0300
@@ -1,3 +1,45 @@
+jed (1:0.99.20~pre.178+dfsg-4) unstable; urgency=medium
+
+  * d/jed-common.preinst: Avoid non-fatal abortion of the script.
+Thanks to Axel Beckert for the fix (Closes: #1035839)
+
+ -- Rafael Laboissière   Wed, 10 May 2023 01:20:42 -0300
+
+jed (1:0.99.20~pre.178+dfsg-3) unstable; urgency=medium
+
+  * Fix upgrade of jed-common (closes: #1035780)
+
+The previous version, which tried to fix Bug#1035692, messed up
+with the directory /usr/share/doc/jed-common/txt. This directory
+is not really needed and has been removed, with all filesit
+contained being kept in /usr/share/jed/doc/txt/. This version
+should allow a smooth transition of jed-common from both bullseye
+(version 0.99.19-8) and testing (version 0.99.20~pre.178+dfsg-1)
+into bookworm.
+
++ d/clean: Restore previous version
++ d/jed-common.links: Reintroduce this file (for symlink etc/jed.d/README)
++ d/jed-common.maintscript: Remove file
++ d/rules: Keep files in /usr/share/jed/doc/txt
++ d/jed-common.preinst: Remove obsolete directory
+  /usr/share/doc/jed-common/txt
+
+ -- Rafael Laboissière   Tue, 09 May 2023 08:42:07 -0300
+
+jed (1:0.99.20~pre.178+dfsg-2) unstable; urgency=medium
+
+  * Avoid installing the *.txt help file over a directory symlink
+(closes: #1035692)
++ d/jed-common.maintscript: Add symlink_to_dir command for the
+  directory /usr/share/jed/doc/txt
++ d/jed-common.links: Removed file
++ d/rules: Create file d/jed-common.links by adding individual
+  symbolic links /usr/share/jed/doc/txt/*.txt point to the files in
+  /usr/share/doc/jed-common/txt/
++ d/clean: Remove the file d/jed-common.links
+
+ -- Rafael Laboissière   Mon, 08 May 2023 12:19:26 -0300
+
 jed (1:0.99.20~pre.178+dfsg-1) unstable; urgency=medium
 
   * New upstream version 0.99.20~pre.178+dfsg
diff -Nru jed-0.99.20~pre.178+dfsg/debian/jed-common.links 
jed-0.99.20~pre.178+dfsg/debian/jed-common.links
--- jed-0.99.20~pre.178+dfsg/debian/jed-common.links2023-01-10 
15:10:00.0 -0300
+++ jed-0.99.20~pre.178+dfsg/debian/jed-common.links2023-05-09 
08:31:49.0 -0300
@@ -1,2 +1 @@
 usr/share/doc/jed-common/README.Debian-startup etc/jed.d/README
-usr/share/doc/jed-common/txt usr/share/jed/doc/txt
diff -Nru jed-0.99.20~pre.178+dfsg/debian/jed-common.preinst 
jed-0.99.20~pre.178+dfsg/debian/jed-common.preinst
--- jed-0.99.20~pre.178+dfsg/debian/jed-common.preinst  1969-12-31 
21:00:00.0 -0300
+++ jed-0.99.20~pre.178+dfsg/debian/jed-common.preinst  2023-05-10 
01:20:12.0 -0300
@@ -0,0 +1,10 @@
+#!/bin/sh
+set -e
+
+# Remove obsolete txt directory
+txtdir=/usr/share/doc/jed-common/txt
+if [ -d $txtdir ] ; then
+rm -rf $txtdir
+fi
+
+#DEBHELPER#
diff -Nru jed-0.99.20~pre.178+dfsg/debian/rules 
jed-0.99.20~pre.178+dfsg/debian/rules
--- jed-0.99.20~pre.178+dfsg/debian/rules   2023-01-10 15:10:00.0 
-0300
+++ jed-0.99.20~pre.178+dfsg/debian/rules   2023-05-09 08:31:49.0 
-0300
@@ -83,7 +83,6 @@
 
 execute_after_dh_installdocs-indep:
# Fix package-contains-documentation-outside-usr-share-doc
-   mv $(docdir)/txt $(shrdir)/doc/jed-common
rm -f $(jeddir)/lib/colors/README
 
 override_dh_compress:

Bug#1035825: unblock: jed/0.99.20~pre.178+dfsg-3

[Rafael Laboissière]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: 1035...@bugs.debian.org, 1035...@bugs.debian.org, 
j...@packages.debian.org
Control: affects -1 + src:jed
Content-Language: en-us

Please unblock package jed.

The version in unstable fixes two RC bugs that have been recently filed 
against the jed package, triggered by piuparts (Bug#1035692 and 
Bug#1035780). The version of the package now in unstable passes piuparts 
[1] and transitions smoothly from both bullseye (version 0.99.19-8) and 
testing (0.99.20~pre.178+dfsg-1).

I am attaching to this message the debdiff between versions 
0.99.20~pre.178+dfsg-1 and -3. The debian/changelog is pretty large, 
because some changes for version -2 (in an attempt to fix Bug#1035692 
that caused Bug#1035780) where canceled in version -3. The final 
difference is quite small: one line removed from debian/rules, one line 
removed from debian/jed-common.links, and a new small file added 
(debian/jed-common.preinst).

unblock jed/0.99.20~pre.178+dfsg-3

Best,

Rafael Laboissière

[1] 
https://piuparts.debian.org/testing2sid/pass/jed-common_1:0.99.20~pre.178+dfsg-3.log
diff -Nru jed-0.99.20~pre.178+dfsg/debian/changelog 
jed-0.99.20~pre.178+dfsg/debian/changelog
--- jed-0.99.20~pre.178+dfsg/debian/changelog   2023-01-10 15:10:00.0 
-0300
+++ jed-0.99.20~pre.178+dfsg/debian/changelog   2023-05-09 08:42:07.0 
-0300
@@ -1,3 +1,38 @@
+jed (1:0.99.20~pre.178+dfsg-3) unstable; urgency=medium
+
+  * Fix upgrade of jed-common (closes: #1035780)
+
+The previous version, which tried to fix Bug#1035692, messed up
+with the directory /usr/share/doc/jed-common/txt. This directory
+is not really needed and has been removed, with all filesit
+contained being kept in /usr/share/jed/doc/txt/. This version
+should allow a smooth transition of jed-common from both bullseye
+(version 0.99.19-8) and testing (version 0.99.20~pre.178+dfsg-1)
+into bookworm.
+
++ d/clean: Restore previous version
++ d/jed-common.links: Reintroduce this file (for symlink etc/jed.d/README)
++ d/jed-common.maintscript: Remove file
++ d/rules: Keep files in /usr/share/jed/doc/txt
++ d/jed-common.preinst: Remove obsolete directory
+  /usr/share/doc/jed-common/txt
+
+ -- Rafael Laboissière   Tue, 09 May 2023 08:42:07 -0300
+
+jed (1:0.99.20~pre.178+dfsg-2) unstable; urgency=medium
+
+  * Avoid installing the *.txt help file over a directory symlink
+(closes: #1035692)
++ d/jed-common.maintscript: Add symlink_to_dir command for the
+  directory /usr/share/jed/doc/txt
++ d/jed-common.links: Removed file
++ d/rules: Create file d/jed-common.links by adding individual
+  symbolic links /usr/share/jed/doc/txt/*.txt point to the files in
+  /usr/share/doc/jed-common/txt/
++ d/clean: Remove the file d/jed-common.links
+
+ -- Rafael Laboissière   Mon, 08 May 2023 12:19:26 -0300
+
 jed (1:0.99.20~pre.178+dfsg-1) unstable; urgency=medium
 
   * New upstream version 0.99.20~pre.178+dfsg
diff -Nru jed-0.99.20~pre.178+dfsg/debian/jed-common.links 
jed-0.99.20~pre.178+dfsg/debian/jed-common.links
--- jed-0.99.20~pre.178+dfsg/debian/jed-common.links2023-01-10 
15:10:00.0 -0300
+++ jed-0.99.20~pre.178+dfsg/debian/jed-common.links2023-05-09 
08:42:07.0 -0300
@@ -1,2 +1 @@
 usr/share/doc/jed-common/README.Debian-startup etc/jed.d/README
-usr/share/doc/jed-common/txt usr/share/jed/doc/txt
diff -Nru jed-0.99.20~pre.178+dfsg/debian/jed-common.preinst 
jed-0.99.20~pre.178+dfsg/debian/jed-common.preinst
--- jed-0.99.20~pre.178+dfsg/debian/jed-common.preinst  1969-12-31 
21:00:00.0 -0300
+++ jed-0.99.20~pre.178+dfsg/debian/jed-common.preinst  2023-05-09 
08:42:07.0 -0300
@@ -0,0 +1,8 @@
+#!/bin/sh
+set -e
+
+# Remove obsolete txt directory
+txtdir=/usr/share/doc/jed-common/txt
+test -d $txtdir && rm -rf $txtdir
+
+#DEBHELPER#
diff -Nru jed-0.99.20~pre.178+dfsg/debian/rules 
jed-0.99.20~pre.178+dfsg/debian/rules
--- jed-0.99.20~pre.178+dfsg/debian/rules   2023-01-10 15:10:00.0 
-0300
+++ jed-0.99.20~pre.178+dfsg/debian/rules   2023-05-09 08:42:07.0 
-0300
@@ -83,7 +83,6 @@
 
 execute_after_dh_installdocs-indep:
# Fix package-contains-documentation-outside-usr-share-doc
-   mv $(docdir)/txt $(shrdir)/doc/jed-common
rm -f $(jeddir)/lib/colors/README
 
 override_dh_compress:

Bug#1035684: swig: Update octave files for Octave v8

[Rafael Laboissière]

Source: swig
Version: 4.1.0-0.2
Severity: important
Tags: upstream patch

Dear Maintainer,

Version 8 of the octave package is now in experimental and will be 
uploaded to unstable as soon as bookworm is released. The version of the 
swig package currently in unstable (4.1.0-0.2) produces Octave bindings 
that do not work with Octave 8. This makes packages that build Octave 
bindings via SWIG, like plplot, fail to build from source.

This issue has been reported upstream [1] and a patch is available via a 
pull request on GitHub [2]. I prepared a patch for the swig package, 
which has been submitted as a merge request on Salsa.d.o.

With this patched version, the plplot package builds correctly against 
Octave 8.

I am hereby setting the severity of this bug report to "important", but 
it should be raised to "serious" when Octave 8 will be uploaded to 
unstable.

Best,

Rafael Laboissière

 [1] https://github.com/swig/swig/issues/2508
 [2] https://github.com/swig/swig/pull/2512.patch
 [3] https://salsa.debian.org/debian/swig/-/merge_requests/8

Bug#1035652: unblock: plplot/5.15.0+dfsg2-6

[Rafael Laboissière]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: 1034...@bugs.debian.org, plp...@packages.debian.org, Ole 
Streicher 
Control: affects -1 + src:plplot

Please unblock package plplot.

The version in unstable adds a missing Breaks+Replaces needed for upgrade 
from bullseye (see Bug#1034936).

I reviewed the changes between this version and the version currently in 
testing (5.15.0+dfsg2-6), which are minimal (only two lines added to 
debian/control). The debdiff is attached to this message.

unblock plplot/5.15.0+dfsg2-6

Best,

Rafael Laboissière
diff -Nru plplot-5.15.0+dfsg2/debian/changelog plplot-5.15.0+dfsg2/debian/changelog
--- plplot-5.15.0+dfsg2/debian/changelog	2023-01-07 17:42:41.0 -0300
+++ plplot-5.15.0+dfsg2/debian/changelog	2023-04-28 06:34:58.0 -0300
@@ -1,3 +1,10 @@
+plplot (5.15.0+dfsg2-6) unstable; urgency=medium
+
+  * d/control: Add necessary Breaks+Replaces for libplplotada5
+(Closes: #1034936)
+
+ -- Ole Streicher   Fri, 28 Apr 2023 11:34:58 +0200
+
 plplot (5.15.0+dfsg2-5) unstable; urgency=medium
 
   * Upload to unstable
diff -Nru plplot-5.15.0+dfsg2/debian/control plplot-5.15.0+dfsg2/debian/control
--- plplot-5.15.0+dfsg2/debian/control	2023-01-07 17:42:41.0 -0300
+++ plplot-5.15.0+dfsg2/debian/control	2023-04-28 06:34:58.0 -0300
@@ -539,6 +539,8 @@
  libqsastime-dev,
  ${misc:Depends}
 Recommends: libplplot-dev
+Replaces: libplplotada3-dev (<< 5.15.0+dfsg-26)
+Breaks: libplplotada3-dev (<< 5.15.0+dfsg-26)
 Description: Ada support for PLplot, a plotting library (development files)
  PLplot is relatively small, portable, freely distributable, and is rich
  enough to satisfy most users.  It has a wide range of plot types including

Bug#1026014: libdebhelper-perl: addsubstvar should check validity of its arguments

[Rafael Laboissière]

Package: libdebhelper-perl
Version: 13.11.1
Severity: normal

Dear Maintainer,

This bug report is motivated by the discussion around Bug#1025714 
(https://bugs.debian.org/1025714).  That bug was caused by the 
dh_octave_substvar script (from package dh-octave), which was calling 
the addsubstvar function (from library Dh_Lib) with a non-valid 
argument. This caused the creation of an invalid debian/*.substvars 
file, which triggered an error in dpkg-gencontrol and provoked an FTBFS.

In that case, the problem was caused by an extraneous leading newline in 
the deppackage argument of addsubstvar.

In the meanwhile, the issue in dh-octave has been fixed. However, Niels 
Thykier suggested that addsubstvar should catch and reject invalid 
arguments and I agree with his proposal.

Best,

Rafael Laboissière

 -- System Information:
 Debian Release: bullseye/sid
   APT prefers testing
   APT policy: (650, 'testing'), (600, 'unstable')
 Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

 Versions of packages libdebhelper-perl depends on:
 ii  perl  5.36.0-4

libdebhelper-perl recommends no packages.

libdebhelper-perl suggests no packages.

-- no debconf information

Bug#1025714: octave-vrml: FTBFS randomly in sid (dpkg-gencontrol failure)

[Rafael Laboissière]

* Niels Thykier  [2022-12-09 16:45]:


Rafael Laboissière:


[snip]

The issue is caused by a bug in the dh_octave_substvar script, from 
the dh-octave package. I am looking at it. More to come soon.


Best,

Rafael Laboissière


I had hoped that debhelper's addsubstvar would catch an unescaped 
newline in the input bug already in the addsubstvar's call if it was 
done via `Dh_Lib`.  If you find that is not the case, please do file a 
bug against debhelper for that bit.


Your wording above is a bit harder to parse. Are you suggesting that 
addsubstvar should be tolerant to arguments (at least deppackage) with 
trailing newlines, or even trailing whitespace, more generally?


Best,

Rafael Laboissière

Bug#1025714: octave-vrml: FTBFS randomly in sid (dpkg-gencontrol failure)

[Rafael Laboissière]

* Santiago Vila  [2022-12-09 00:30]:


 affects 1025714 src:octave-vrml
 thanks

Rafael Laboissière escribió:

The issue is caused by a bug in the dh_octave_substvar script, from
the dh-octave package. I am looking at it. More to come soon.


Great. I'm using affects so that people can see this bug in the page 
for octave-vrml as well.


Thanks, I indeed forgot to set this affects.

Version 1.2.5 of dh-octave has been uploaded to unstable. It should fix 
the issue. I will make also a new release of octave-vrml that 
build-depends on dh-octave >= 1.2.5.


Best,

Rafael Labossière

Bug#1025714: octave-vrml: FTBFS randomly in sid (dpkg-gencontrol failure)

[Rafael Laboissière]

Control: tags -1 + confirmed
Control: notfound -1 1.0.13-7
Control: reassign -1 dh-octave
Control: found -1 1.2.4

* Santiago Vila  [2022-12-07 22:30]:


Package: src:octave-vrml
Version: 1.0.13-7
Tags: ftbfs

Dear Maintainer:

Today I tried to build this package from source and this is what happened:

   dh_missing -i -O--buildsystem=octave
   dh_octave_substvar -i -O--buildsystem=octave
   dh_installdeb -i -O--buildsystem=octave
   dh_gencontrol -i -O--buildsystem=octave
 dpkg-gencontrol: error: bad line in substvars file
 debian/octave-vrml.substvars at line 2
 dh_gencontrol: error: dpkg-gencontrol -poctave-vrml -ldebian/changelog 
-Tdebian/octave-vrml.substvars -Pdebian/octave-vrml returned exit code 255
 dh_gencontrol: error: Aborting due to earlier error
 make: *** [debian/rules:7: binary-indep] Error 2
 dpkg-buildpackage: error: debian/rules binary-indep subprocess
 returned exit status 2

The file debian/octave-vrml.substvars seems in fact to be broken:

 octave:Depends=octave (>= 7.3.0), octave-linear-algebra,
 octave-miscellaneous, octave-statistics
 , octave-struct
 octave:Upstream-Description=3D graphics using VRML
 misc:Depends=
 misc:Pre-Depends=


After getting this build failure for the first time I tried to build 
it more times to be sure and it failed most of the time, but not 
always, so be warned that the bug is random and you might have to try 
several times before getting a build failure.


For what is worth: The failure also happens here, so I'm quite 
confident that my build environment is not to blame:


https://tests.reproducible-builds.org/debian/logs/unstable/amd64/octave-vrml_1.0.13-7.build2.log.gz

[ I'm using X-debbugs-cc with debhelper maintainers in case they have 
something to say about this ].


Thanks for the bug report.

The issue is caused by a bug in the dh_octave_substvar script, from the 
dh-octave package. I am looking at it. More to come soon.


Best,

Rafael Laboissière

Bug#1016332: librsb: FTBFS: gmake[3]: *** [Makefile:920: qtests] Error 1

[Rafael Laboissière]

* Michele Martone  [2022-12-05 15:31]:


In my 20221204@23:42 (yesterday) email I forgot to add that on my chroot 
setup, I can reproduce latex failing to compile the file I was attaching. 
In that setup I have a utf8x.def too, sized 8036 bytes and with md5sum 
21f7ac37aafb6cfeddbb196b8bfd6280 .


To the goal of fixing the librsb package: that test is the last one in 
`make tests`, and it it's just to make sure rsbtest can produce a buildable 
LaTeX file; it's nothing core or important, so sed'ing out that line 
seems the solution to me -- librsb itself is functional.


Ok, thanks, I applied the patch you suggested (s/utf8x//) and uploaded 
version 1.3.0.1+dfsg-3 of the package to unstable. So far, it built 
correctly on all official architectures for bookworm.


Let us see what will happen with the next automatic rebuild of all 
package in sid.


@Lucas: if the rebuild goes fine, will this bug report be automatically 
closed? Otherwise, is there a web page where the results can be tracked?


Best,

Rafael

Bug#1025501: pvm: Uninstallable in sid when openssh-client is installed

[Rafael Laboissière]

* Rafael Laboissière  [2022-12-06 10:08]:


* Rafael Laboissière  [2022-12-05 22:55]:

The pvm package is currently installable in sid when openssh-client 
is installed and there is no other package providing rsh-client:


Of course, I meant *uninstallable* in the sentence above.

The pvm package is orphaned. If nobody objects, I will do a QA upload 
to fix this release-critical bug.


I just did it. Version 3.4.6-4 (QA upload) has been uploaded to unstable.

I did some QA work in the Git repository at Salsa.d.o. NMU versions 
3.4.6-3, 3.4.6-3.1, and 3.4.6-3.2 have diverged from the repository, 
since release 3.4.6-2. I injected those version into the repository and I 
included, in version 3.4.6-4, the changes that have been cumulated there.


Hopefully, this discipline will be kept in the future.

Rafael Laboissière

[*] https://salsa.debian.org/debian/pvm

Bug#1025501: pvm: Uninstallable in sid when openssh-client is installed

[Rafael Laboissière]

* Rafael Laboissière  [2022-12-05 22:55]:

The pvm package is currently installable in sid when openssh-client is 
installed and there is no other package providing rsh-client:


Of course, I meant *uninstallable* in the sentence above.

The pvm package is orphaned. If nobody objects, I will do a QA upload 
to fix this release-critical bug.


Rafael Laboissière

Bug#1025501: pvm: Uninstallable in sid when openssh-client is installed

[Rafael Laboissière]

Package: pvm
Version: 3.4.6-3.2
Severity: serious

Dear Maintainer,

The pvm package is currently installable in sid when openssh-client is 
installed and there is no other package providing rsh-client:

  # apt install pvm
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  pvm is already the newest version (3.4.6-3.2+b1).
  pvm set to manually installed.
  0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
  2 not fully installed or removed.
  After this operation, 0 B of additional disk space will be used.
  Do you want to continue? [Y/n]
  Setting up pvm (3.4.6-3.2+b1) ...
  update-alternatives: error: alternative path /usr/bin/rsh doesn't exist
  dpkg: error processing package pvm (--configure):
   installed pvm package post-installation script subprocess returned error 
exit status 2
  dpkg: dependency problems prevent configuration of pvm-dev:
   pvm-dev depends on pvm; however:
Package pvm is not configured yet.

This is caused by a recent change in openssh-client:

  openssh (1:9.1p1-1) unstable; urgency=medium
[...]
* Remove obsolete and misleading rcp/rlogin/rsh alternatives, and stop
  providing rsh-client (closes: #197037).

A simple fix for this issue is changing the Depends field from:

  openssh-client | rsh-client

to:

  rsh-client

Best,

Rafael

-- System Information: 
Debian Release: bullseye/sid 
  APT prefers testing 
  APT policy: (650, 'testing'), (600, 'unstable') 
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pvm depends on: 
ii  libc62.36-6 
pn  libpvm3   
ii  openssh-client [rsh-client]  1:9.1p1-1

pvm recommends no packages.

pvm suggests no packages.

Bug#1016332: librsb: FTBFS: gmake[3]: *** [Makefile:920: qtests] Error 1

[Rafael Laboissière]

* Michele Martone  [2022-12-04 23:42]:

latex is not able to compile a rsbtest-generated 
file looking like the one I attach. 
The problematic line is:


\usepackage[utf8x]{inputenc} 
[...]


It compiles fine here:

$ pdflatex test.tex > /dev/null && grep utf8x.def test.log
(/usr/share/texlive/texmf-dist/tex/latex/ucs/utf8x.def
File: utf8x.def 2022/08/07 UCS: Input encoding UTF-8

The utf8x.def file belongs to this package:

$ dpkg -S /usr/share/texlive/texmf-dist/tex/latex/ucs/utf8x.def
texlive-latex-extra: /usr/share/texlive/texmf-dist/tex/latex/ucs/utf8x.def

texlive-latex-extra is one of the dependencies of doxygen-latex, which 
is a build-dependency of librsb.


In conclusion, I do not think that the problem is caused by using the 
utf8x option for the LaTeX package inputenc.


Best,

Rafael

Bug#1016332: librsb: FTBFS: gmake[3]: *** [Makefile:920: qtests] Error 1

[Rafael Laboissière]

Control: forwarded -1 michelemart...@users.sourceforge.net
Control: tags -1 unreproducible

Hi Michele,

There is a bug report filed against the librsb package (Bug#1016332 [1]) 
that has severity level "serious". This is blocking the package entering 
testing and, therefore, librsb will be removed from the upcoming bookworm 
release, unless the bug is fixed. This means that octave-sparsersb would 
also be absent from the next Debian release if nothing is done.


I cannot reproduce the bug and I am hereby tagging this bug report 
accordingly. Skimming over the full build log [2], I could not find the 
source of the problem. If you could take a look at this, it will be 
great.


Best,

Rafael

 [1] https://bugs.debian.org/1016332
 [2] http://qa-logs.debian.net/2022/07/28/librsb_1.3.0.1+dfsg-2_unstable.log

* Lucas Nussbaum  [2022-07-29 20:37]:


Source: librsb
Version: 1.3.0.1+dfsg-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20220728 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build 
on amd64.


[snip]

The full build log is available from: 
http://qa-logs.debian.net/2022/07/28/librsb_1.3.0.1+dfsg-2_unstable.log


All bugs filed during this archive rebuild are listed at: 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20220728;users=lu...@debian.org 
or: 
https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20220728=lu...@debian.org=1=1=1=1#results


A list of current common problems and possible solutions is available at 
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!


If you reassign this bug to another package, please marking it as 'affects'-ing 
this package. See https://www.debian.org/Bugs/server-control#affects


If you fail to reproduce this, please provide a build log and diff it with mine 
so that we can identify if something relevant changed in the meantime.

Bug#1006682: /usr/lib/cmake/mathgl2/MathGL2Config.cmake: Could NOT find OpenMP_CXX

[Rafael Laboissière]

Control: tags -1 - moreinfo
Control: tags -1 + wontfix

* Sylvain Joubert  [2022-08-31 10:17]:

Ok, I just figured out why you probably can't reproduce the issue: you need 
to use clang as a compiler. 
If you use `CXX=clang++-14 cmake [...]` as a configure command line you'll 
likely trigger the error.


Thanks for this additional information. I can now reproduce the bug, 
which is not triggered when using CXX=g++.


And the required package providing OpenMP for clang must match the clang 
version used: if I install libomp-13-dev while using clang++-14 for example 
I'll still get the error.


With this additional info I get that the issue is triggered with a 
non-default setup, so I'm not sure how or even if it can be fixed 
correctly. Especially given that the proper dependency is heavily dependent 
on the clang version used/installed. 
Given that understanding I'd be fine with leaving things as is. And maybe 
it's the upstream MathGL2Config.cmake that needs a rework to deal more 
easily with various setups.


I am not sure whether the issue can be fixed in a trivial way. I am 
hereby tagging this bug report "wontfix", for now.


Best,

Rafael Laboissière

Bug#1006682: /usr/lib/cmake/mathgl2/MathGL2Config.cmake: Could NOT find OpenMP_CXX

[Rafael Laboissière]

Control: tags -1 moreinfo

* Sylvain Joubert  [2022-03-02 11:17]:


 Package: libmgl-dev
 Version: 8.0.1-1
 Severity: normal

Dear Maintainer,

Trying to use libmgl-dev through find_package(MathGL2) in CMake I'm facing the 
following error:


 CMake Error at 
/usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230
 (message): Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS 
OpenMP_CXX_LIB_NAMES)
 Call Stack (most recent call first):
 /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594
 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-3.22/Modules/FindOpenMP.cmake:544
 (find_package_handle_standard_args)
  /usr/share/cmake-3.22/Modules/CMakeFindDependencyMacro.cmake:47
 (find_package)
  /usr/lib/cmake/mathgl2/MathGL2Config.cmake:22 (find_dependency)
 [...]

It appears the libmgl-dev package is missing a dependency on an OpenMP 
related package. Installing libomp-dev fixes the issue though I'm not 
sure this is the correct package to depend on.


Thank you for the bug report.

Could you please provide an example that trigger the bug? For 
inspiration, look at Bug #1004218 [1] or #1004219 [2].


Best,

Rafael Laboissière

 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004218
 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004219