Bug#1061627: jpeg-xl: 0.8 failing autopkgtest

[Mathieu Malaterre]

Control: tags -1 upstream patch fixed-upstream
Control: forwarded -1 https://github.com/libjxl/libjxl/issues/2391

On Sat, Jan 27, 2024 at 4:51 PM Jeremy Bícha  wrote:
[...]
> Test - Lossless Roundtrip
> JPEG XL encoder v0.8.2 [AVX2,SSE4,SSSE3,SSE2]
> ./lib/extras/dec/color_hints.cc:54: No color_space/icc_pathname given,
> assuming sRGB
> Read 320x320 image, 1228816 bytes, 814.0 MP/s
> Encoding [Modular, lossless, effort: 7],
> ./lib/jxl/encode.cc:263: Only JXL_BIT_DEPTH_FROM_PIXEL_FORMAT is
> implemented for float types.

I'll incorporate the changes.

Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)

[Mathieu Malaterre]

On Tue, Mar 19, 2024 at 8:44 AM Emanuele Rocca  wrote:
>
> Hi,
>
> On 2024-03-19 06:24, Sébastien Jodogne wrote:
> > Because of bug #1060104, a large majority of the packages related to
> > medical imaging have just disappeared from Debian Unstable.
> >
> > But, if I correctly understand #1060104, it is specific to one single
> > platform (armel).
>
> Indeed, and there is a simple fix too, which has been uploaded to
> experimental only so far:
> https://salsa.debian.org/med-team/dcmtk/-/commit/42583dfe9fd344a63cdbc278268d4176d4a22ec4
>
> Mathieu (or someone else from debian-med), could you please apply that
> to unstable as well? It seems that with the current state of unstable
> the transition will take a while anyways.

I will be away from any Debian tasks for at least another month
unfortunately. The patch was suggested by an armel porter so I believe
this is the right thing to do.

> Worth pointing out that right now dcmtk cannot be built in sid/armel due
> to a missing build depend, namely graphviz. It seems worth applying the
> fix to unstable anyways so that it does not fall through the cracks, and
> we can schedule a binNMU later when graphviz is available again.

-M

Bug#1062022: dcmtk: NMU diff for 64-bit time_t transition

[Mathieu Malaterre]

Hi,

On Wed, Jan 31, 2024 at 1:09 AM  wrote:
> 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

Are you going to nuke my work on dcmtk 3.6.8 transition ?

Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)

[Mathieu Malaterre]

Control: severity -1 important

On Mon, Jan 15, 2024 at 1:49 PM Emanuele Rocca  wrote:
[...]
> For this reason I would
> suggest to disable stackclash on the armel build of dcmtk (just like you
> did in experimental) to make sure the package builds properly again, but
> keep #1060104 open at a lower severity so that we don't lose track of
> this.

Done ! Thanks

Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)

[Mathieu Malaterre]

Control: fixed -1 3.6.8-3

On Sat, Jan 13, 2024 at 9:42 PM Emanuele Rocca  wrote:
>
> Control: user -1 debian-...@lists.debian.org
> Control: usertag -1 + 32bit-stackclash
>
> Hi,
>
> On Fri, Jan 05, 2024 at 11:45:28PM +0100, Sebastian Ramacher wrote:
> > /tmp/ccm0eYhx.s: Assembler messages:
> > /tmp/ccm0eYhx.s:537: Error: bad immediate value for offset (4100)
>
> This is caused by stack-clash-protection on armel and a workaround is in
> version 3.6.8-3 currently in experimental, see:
> https://tracker.debian.org/news/1494233/accepted-dcmtk-368-3-source-into-experimental/
>
> We should downgrade the severity to minor once the fix enters unstable, but
> keep the bug open as this seems to be an interesting case of
> stack-clash-protection malfunctioning on 32bit arm to further look into.

Bit lost here... I do not see the bug reported against GCC-13 package.

In the end do you want me to upload a patched 3.6.7 or is it ok to
wait for transition ?

Thanks!

Bug#1056953: marked as pending in gdcm

[Mathieu Malaterre]

Control: tag -1 pending

Hello,

Bug #1056953 in gdcm reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/med-team/gdcm/-/commit/263554ea8b9f71b92542a66a3ccad7936b93185c


d/patches: Revert changes breaking binary ABI. Closes: #1056953


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1056953

Bug#1054696: marked as pending in gdcm

[Mathieu Malaterre]

Control: tag -1 pending

Hello,

Bug #1054696 in gdcm reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/med-team/gdcm/-/commit/9142bd4db25a4375de6c8f38e30843e0c7eea6b3


d/patches: Fix compilation with charls. Closes: #1054696


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1054696

Bug#1052677: Fixed in 1.0.7-1

[Mathieu Malaterre]

Version: 1.0.7-1

> Looks like this was already fixed in 1.0.7-1 a couple of weeks ago. I
> updated and the problem went away. Sorry for the dupe.

Sorry for the mess. Just for reference, this is also fixed on 1.0.3-3+deb12u1

Bug#1016903: really closing for real

[Mathieu Malaterre]

Version: 12.2.0-18

malat@barriere ~ % apt-cache policy gcc-12
gcc-12:
  Installed: 12.2.0-18
  Candidate: 12.2.0-18
  Version table:
 *** 12.2.0-18 100
  1 https://deb.debian.org/debian experimental/main i386 Packages
100 /var/lib/dpkg/status
 12.2.0-14 500
500 https://deb.debian.org/debian sid/main i386 Packages
malat@barriere ~ % gcc-12 -O2 pr106322.c && ./a.out && echo fixed
fixed

Thanks

Bug#1042246: gdcm: FTBFS: make[1]: *** [debian/rules:107: override_dh_auto_configure] Error 2

[Mathieu Malaterre]

Forwarded as #1050506

Bug#1050506: Could NOT find EXPAT (missing: EXPAT_LIBRARY) (found version "2.5.0")

[Mathieu Malaterre]

Source: cmake
Version: 3.27.3-1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230726 ftbfs-trixie
Affects: src:gdcm

Original bug report is #1042246

Here is a minimal reproduce:

% cat ../CMakeLists.txt
cmake_minimum_required(VERSION 3.9.2)
#cmake_minimum_required(VERSION 3.27)
project(p)

find_package(EXPAT REQUIRED)
find_package(VTK REQUIRED)

The above gives:

% rm CMakeCache.txt && cmake ..
[...]
CMake Error at 
/usr/share/cmake-3.27/Modules/FindPackageHandleStandardArgs.cmake:230
(message):
  Could NOT find EXPAT (missing: EXPAT_LIBRARY) (found version "2.5.0")
Call Stack (most recent call first):
  /usr/share/cmake-3.27/Modules/FindPackageHandleStandardArgs.cmake:600
(_FPHSA_FAILURE_MESSAGE)
  /usr/lib/x86_64-linux-gnu/cmake/vtk-9.1/FindEXPAT.cmake:65
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  
/usr/lib/x86_64-linux-gnu/cmake/vtk-9.1/VTK-vtk-module-find-packages.cmake:1243
(find_package)
  /usr/lib/x86_64-linux-gnu/cmake/vtk-9.1/vtk-config.cmake:150 (include)
  CMakeLists.txt:6 (find_package)

It is unclear why changing:

cmake_minimum_required(VERSION 3.9.2)

into

cmake_minimum_required(VERSION 3.27)

make the symptoms go away.

Thanks for comments,

Bug#1042246: marked as pending in gdcm

[Mathieu Malaterre]

Control: tag -1 pending

Hello,

Bug #1042246 in gdcm reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/med-team/gdcm/-/commit/aa371fe473c4c892343eaafb3ce29f96006ad59e


d/rules: Hack to work around FTBFS. Closes: #1042246


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1042246

Bug#1042246: gdcm: FTBFS: make[1]: *** [debian/rules:107: override_dh_auto_configure] Error 2

[Mathieu Malaterre]

Control: tags -1 patch

On Wed, Jul 26, 2023 at 10:30 PM Lucas Nussbaum  wrote:
 [...]
> > CMake Error at 
> > /usr/share/cmake-3.27/Modules/FindPackageHandleStandardArgs.cmake:230 
> > (message):
> >   Could NOT find EXPAT (missing: EXPAT_LIBRARY) (found version "2.5.0")
> > Call Stack (most recent call first):

I'll upload a quick hack ASAP (*). But there is something
fundamentally wrong with the find_package + expat mechanism. Possibly
in cmake itself...

2cts

(*)
% git diff
diff --git a/debian/rules b/debian/rules
index 32ab32e..bfb08fc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -77,6 +77,7 @@ CMAKE_EXTRA_FLAGS += -DCMAKE_SKIP_RPATH=ON \
-DGDCM_USE_PVRG:BOOL=ON \
-DGDCM_USE_SYSTEM_PVRG:BOOL=ON \
-DGMCS_EXECUTABLE:FILEPATH=/usr/bin/mono-csc \
+
-DEXPAT_LIBRARY:FILEPATH=/usr/lib/$(DEB_HOST_MULTIARCH)/libexpat.so \
-DGDCM_BUILD_TESTING:BOOL=OFF \
-DGDCM_USE_SYSTEM_EXPAT:BOOL=ON \
-DGDCM_USE_SYSTEM_UUID:BOOL=ON \

Bug#1036584: libopenjpip-viewer: broken symlink: /usr/bin/opj_jpip_viewer -> ../share/opj_jpip_viewer/opj_jpip_viewer.jar

[Mathieu Malaterre]

Le jeu. 25 mai 2023, 19:15, Andreas Metzler  a écrit :

> Hello,
>
> if you have not got time for an upload I can look into it.
>

Yes please ! Thanks very much

> cu Andreas
>
>

Bug#1036584: libopenjpip-viewer: broken symlink: /usr/bin/opj_jpip_viewer -> ../share/opj_jpip_viewer/opj_jpip_viewer.jar

[Mathieu Malaterre]

Control: tags -1 - patch

On Wed, May 24, 2023 at 6:21 PM Andreas Metzler  wrote:
>
> Control: retitle -1 libopenjpip-viewer is basically empty
>
> On 2023-05-23 Mathieu Malaterre  wrote:
> > On Tue, May 23, 2023 at 10:46 AM Mathieu Malaterre  wrote:
> > >
> > > Control: retitle -1 No java compiler found. Won't be able to build java 
> > > viewer
> > >
> > > openjpeg2/java compilation appears to be broken:
> [...]
>
> > default-jdk is defined in B-D-I which looks wrong IMHO:
>
> > * 
> > https://salsa.debian.org/debian-phototools-team/openjpeg2/-/blob/master/debian/control#L16
>
> > [...]
> > Build-Depends-Indep: default-jdk,
> > [...]
>
> Why does this look wrong? libopenjpip-viewer is arch-all.
>
> Correct patch attached. Stuff was built but the respective dh_install
> call was shadowed and therefore content was not shipped in the package.

[...]
-override_dh_install-indep:
- dh_install -p$(pkg_doc) debian/tmp/usr/share/doc
-
[...]

Isn't this going to break the openjpeg-doc package ?

Bug#1036584: libopenjpip-viewer: broken symlink: /usr/bin/opj_jpip_viewer -> ../share/opj_jpip_viewer/opj_jpip_viewer.jar

[Mathieu Malaterre]

Control: tags -1 patch

On Tue, May 23, 2023 at 10:46 AM Mathieu Malaterre  wrote:
>
> Control: retitle -1 No java compiler found. Won't be able to build java viewer
>
> openjpeg2/java compilation appears to be broken:
>
> -- Could NOT find Java (missing: Java_JAVA_EXECUTABLE
> Java_JAVAC_EXECUTABLE Java_JAR_EXECUTABLE Java_JAVADOC_EXECUTABLE
> Java_JAVAH_EXECUTABLE Development) (Required is at least version
> "1.8")
> CMake Warning at src/bin/jpip/CMakeLists.txt:160 (message):
>   No java compiler found.  Won't be able to build java viewer

default-jdk is defined in B-D-I which looks wrong IMHO:

* 
https://salsa.debian.org/debian-phototools-team/openjpeg2/-/blob/master/debian/control#L16

[...]
Build-Depends-Indep: default-jdk,
[...]

Bug#1036584: libopenjpip-viewer: broken symlink: /usr/bin/opj_jpip_viewer -> ../share/opj_jpip_viewer/opj_jpip_viewer.jar

[Mathieu Malaterre]

Control: retitle -1 No java compiler found. Won't be able to build java viewer

openjpeg2/java compilation appears to be broken:

-- Could NOT find Java (missing: Java_JAVA_EXECUTABLE
Java_JAVAC_EXECUTABLE Java_JAR_EXECUTABLE Java_JAVADOC_EXECUTABLE
Java_JAVAH_EXECUTABLE Development) (Required is at least version
"1.8")
CMake Warning at src/bin/jpip/CMakeLists.txt:160 (message):
  No java compiler found.  Won't be able to build java viewer


ref:
* 
https://buildd.debian.org/status/fetch.php?pkg=openjpeg2=amd64=2.5.0-1%2Bb1=1673540495=0

Bug#1016903: closing for real

[Mathieu Malaterre]

Version: 12.2.0-8

malat@barriere ~ % apt-cache policy gcc-12
gcc-12:
  Installed: 12.2.0-18
  Candidate: 12.2.0-18
  Version table:
 *** 12.2.0-18 100
  1 https://deb.debian.org/debian experimental/main i386 Packages
100 /var/lib/dpkg/status
 12.2.0-14 500
500 https://deb.debian.org/debian sid/main i386 Packages
malat@barriere ~ % gcc-12 -O2 pr106322.c && ./a.out && echo fixed
fixed

Thanks

Bug#1033931: UB: memcmp is not atomic in C11 either

[Mathieu Malaterre]

The bugzilla thread is rather long. But I took the liberty to report
the issue as grave following the comment:

https://sourceware.org/bugzilla/show_bug.cgi?id=29863#c11

Feel free to downgrade severity if my understanding is incorrect.

Thanks

Bug#1033931: Fwd: Novice needs help submitting a bug report

[Mathieu Malaterre]

Package: libc-bin
Version: 2.36-8
Severity: grave
Justification: renders package unusable

Dear Maintainer,

There is a bug in glibc 2.36 that has been fixed in 2.37. The two
links below detail the original bug report and the fix.

- Upstream bug report - https://sourceware.org/bugzilla/show_bug.cgi?id=29863

- Upstream commit fixing said bug report –
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b712be52645282c706a5faa038242504feb06db5



This bug causes fis-gtm to randomly crash on a SIGSEGV. Depending upon
process activity, the crash could result in database damage.

Bug#1016903: git-updates.diff not applied ?

[Mathieu Malaterre]

Control: reopen -1

> the upstream fix went into 12.2.0-2.

Would be so kind as to demonstrate how ?

Here is what I see on my side:

% ssh barriere.debian.org
% sessionid=$(schroot -b -c sid_i386-dchroot)
% dd-schroot-cmd -c $sessionid apt-get update
% dd-schroot-cmd -c $sessionid apt-get upgrade
% dd-schroot-cmd -c $sessionid apt-get build-dep gcc-12
% dget -u http://deb.debian.org/debian/pool/main/g/gcc-12/gcc-12_12.2.0-14.dsc
% schroot -r -c $sessionid

Then a simple check within the sid schroot:

% cd gcc-12-12.2.0
% grep -r "use emulated vector type for call" .
./debian/patches/git-updates.diff:+  "use emulated
vector type for call\n");
% grep -r git-updates .
./debian/rules.patch:#  git-updates \

So yes I can see PR106322 patch in file "git-updates.diff". But it
looks as if it is never applied to the source tree.

To reproduce the issue, just use the test from gcc-testsuite:

% wget -O pr106322.c
"https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=gcc/testsuite/gcc.target/i386/pr106322.c;h=31333c5fdccbe02ce7cf5055ce852edc0da1af67;hb=9f532fec01d6651cc3cc136073f044a7953d8560;
% gcc -O2 pr106322.c && ./a.out
zsh: IOT instruction  ./a.out

Compared with:

% /usr/lib/gcc-snapshot/bin/gcc -O2 pr106322.c  && ./a.out && echo "success"
success

Per discussion with gcc-upstream:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322#c54
[...]
OK. Thanks for the update! FWIW, with the reduced test case in comment
#45, I just tried with releases/gcc-12 r12-8709 (without my fix), the
aborting was reproduced; while with r12-8710 (my fix), it executed
well.
[...]

Bug#1021165: floatn-common.h:214:9: error: multiple types in one declaration

[Mathieu Malaterre]

Control: reassign -1 libc6.1-dev 2.36-5

Looks like the issue is not fixed on ia64 / sparc64.

Steps:

% cat p.cxx
#include 

int main() { return 0; }

Lead to:

malat@yttrium ~ % /usr/lib/gcc-snapshot/bin/g++ -v p.cxx
Using built-in specs.
COLLECT_GCC=/usr/lib/gcc-snapshot/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/ia64-linux-gnu/13/lto-wrapper
Target: ia64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
20221021-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++,m2
--prefix=/usr/lib/gcc-snapshot --with-gcc-major-version-only
--program-prefix= --enable-shared --enable-linker-build-id
--disable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libssp --disable-libitm
--disable-libsanitizer --enable-plugin --with-system-zlib
--enable-objc-gc=auto --enable-multiarch --disable-werror
--with-system-libunwind --enable-checking=yes --build=ia64-linux-gnu
--host=ia64-linux-gnu --target=ia64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221021 (experimental) [master
r13-3434-ga9de836c2b2] (Debian 20221021-1)
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-dumpdir' 'a-'
 /usr/lib/gcc-snapshot/libexec/gcc/ia64-linux-gnu/13/cc1plus -quiet -v
-imultilib . -imultiarch ia64-linux-gnu -D_GNU_SOURCE p.cxx -quiet
-dumpdir a- -dumpbase p.cxx -dumpbase-ext .cxx -version -o
/tmp/ccMCj3Mu.s
GNU C++17 (Debian 20221021-1) version 13.0.0 20221021 (experimental)
[master r13-3434-ga9de836c2b2] (ia64-linux-gnu)
compiled by GNU C version 13.0.0 20221021 (experimental)
[master r13-3434-ga9de836c2b2], GMP version 6.2.1, MPFR version 4.1.0,
MPC version 1.2.1, isl version isl-0.25-GMP

warning: MPFR header version 4.1.0 differs from library version 4.2.0.
warning: MPC header version 1.2.1 differs from library version 1.3.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/usr/local/include/ia64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc-snapshot/lib/gcc/ia64-linux-gnu/13/include-fixed/ia64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc-snapshot/lib/gcc/ia64-linux-gnu/13/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc-snapshot/lib/gcc/ia64-linux-gnu/13/../../../../ia64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc-snapshot/lib/gcc/ia64-linux-gnu/13/../../../../include/c++/13
 
/usr/lib/gcc-snapshot/lib/gcc/ia64-linux-gnu/13/../../../../include/c++/13/ia64-linux-gnu/.
 
/usr/lib/gcc-snapshot/lib/gcc/ia64-linux-gnu/13/../../../../include/c++/13/backward
 /usr/lib/gcc-snapshot/lib/gcc/ia64-linux-gnu/13/include
 /usr/local/include
 /usr/lib/gcc-snapshot/include
 /usr/include/ia64-linux-gnu
 /usr/include
End of search list.
GNU C++17 (Debian 20221021-1) version 13.0.0 20221021 (experimental)
[master r13-3434-ga9de836c2b2] (ia64-linux-gnu)
compiled by GNU C version 13.0.0 20221021 (experimental)
[master r13-3434-ga9de836c2b2], GMP version 6.2.1, MPFR version 4.1.0,
MPC version 1.2.1, isl version isl-0.25-GMP

warning: MPFR header version 4.1.0 differs from library version 4.2.0.
warning: MPC header version 1.2.1 differs from library version 1.3.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 46cce3a938a51610ba7278d8fb426d84
In file included from /usr/include/stdio.h:430,
 from p.cxx:1:
/usr/include/ia64-linux-gnu/bits/floatn.h:84:9: error: multiple types
in one declaration
   84 | typedef __float128 _Float128;
  | ^~
/usr/include/ia64-linux-gnu/bits/floatn.h:84:20: error: declaration
does not declare anything [-fpermissive]
   84 | typedef __float128 _Float128;
  |^
In file included from /usr/include/ia64-linux-gnu/bits/floatn.h:117:
/usr/include/ia64-linux-gnu/bits/floatn-common.h:214:9: error:
multiple types in one declaration
  214 | typedef float _Float32;
  | ^
/usr/include/ia64-linux-gnu/bits/floatn-common.h:214:15: error:
declaration does not declare anything [-fpermissive]
  214 | typedef float _Float32;
  |   ^~~~
/usr/include/ia64-linux-gnu/bits/floatn-common.h:251:9: error:
multiple types in one declaration
  251 | typedef double _Float64;
  | ^~
/usr/include/ia64-linux-gnu/bits/floatn-common.h:251:16: error:
declaration does not declare anything [-fpermissive]
  251 | typedef double _Float64;
  |^~~~
/usr/include/ia64-linux-gnu/bits/floatn-common.h:268:9: error:
multiple types in one declaration
  268 | typedef double _Float32x;
  | ^~
/usr/include/ia64-linux-gnu/bits/floatn-common.h:268:16: error:
declaration does not declare anything [-fpermissive]
  268 | typedef double _Float32x;
  |

Bug#1027965: Add libvtk6-qt-dev to dependencies

[Mathieu Malaterre]

Control: tags -1 patch

Since 2016 it seems that a hack has been put in place in vtk package
consumer to always include vtk-qt package:

https://salsa.debian.org/med-team/vtk-dicom/-/commit/0d3fde678cd86459a485df7492307b94a5afc97e

I suspect it would be better done in vtk9 package itself.

Typical patch would be:

 % git diff
diff --git a/debian/control b/debian/control
index 5d7b4d36..38fda9b3 100644
--- a/debian/control
+++ b/debian/control
@@ -88,6 +88,7 @@ Package: libvtk9-dev
 Architecture: any
 Section: libdevel
 Depends: ${misc:Depends},
+ libvtk9-qt-dev (= ${binary:Version}),
  ${shlibs:Depends},
  default-jdk [!hppa !hurd-any !kfreebsd-any],
  default-libmysqlclient-dev,

Bug#1027965: gdcm: FTBFS everywhere

[Mathieu Malaterre]

Control: reassign -1 vtk9 9.1.0+really9.1.0+dfsg2-4

On Thu, Jan 5, 2023 at 11:03 AM Sebastian Ramacher  wrote:
[...]
> CMake Error at 
> /usr/lib/x86_64-linux-gnu/cmake/vtk-9.1/VTK-vtk-module-find-packages.cmake:115
>  (find_package):
>   By not providing "FindQt5.cmake" in CMAKE_MODULE_PATH this project has
>   asked CMake to find a package configuration file provided by "Qt5", but
>   CMake did not find one.

Dear vtk9 maintainer, please fix the vtk9/cmake config file. Qt5 is an
implementation detail of one vtk9 plugin. We should not force vtk9
consumers to install Qt5 (for no good reason).

Thanks

Bug#1026559: fop: FTBFS: [javadoc] /<>/fop-core/src/main/java/org/apache/fop/servlet/FopServlet.java:29: error: package javax.servlet does not exist

[Mathieu Malaterre]

Control: fixed -1 1:2.8-2

Seems to build fine now:

https://buildd.debian.org/status/fetch.php?pkg=fop=all=1%3A2.8-2=1672905531=0

Closing.

Bug#1025203: r-cran-glmmtmb: FTBFS on mipsel

[Mathieu Malaterre]

On Fri, Dec 9, 2022 at 10:29 AM Andreas Tille  wrote:
>
> Hi Mathieu,
>
> Am Tue, Dec 06, 2022 at 08:38:43AM +0100 schrieb Mathieu Malaterre:
> > I do not have a clean answer to this, but in my experience it is
> > getting more and more difficult to compile anything on mipsel with
> > g++-12. The default option `-g -O2` seems to imply `take as much
> > memory as you want to get things to compile` so this end up crossing
> > the 2GB hard-limit.
> >
> > For example here is what webkit is doing to work around the symptoms:
> >
> > * 
> > https://salsa.debian.org/webkit-team/webkit/-/blob/debian/2.39.1-1/debian/rules#L66-71
>
> Thanks for the hint.  I tried this but this does not work since the R
> build system does not respect external set variables.  Since chances
> are really low that this package will be used on mipsel I asked for
> removal on this architecture.

Totally agree! Let's start the cabal against mipsel as a release arch.

Bug#1025203: r-cran-glmmtmb: FTBFS on mipsel

[Mathieu Malaterre]

I do not have a clean answer to this, but in my experience it is
getting more and more difficult to compile anything on mipsel with
g++-12. The default option `-g -O2` seems to imply `take as much
memory as you want to get things to compile` so this end up crossing
the 2GB hard-limit.

For example here is what webkit is doing to work around the symptoms:

* 
https://salsa.debian.org/webkit-team/webkit/-/blob/debian/2.39.1-1/debian/rules#L66-71

Previous reports on this issue:

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882490
* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78971

On Tue, Dec 6, 2022 at 8:10 AM Andreas Tille  wrote:
>
> Ping?  If this can't be clarified I'd probably ask ftpmaster for removal
> of the package for mipsel.
> Kind regards, Andreas.
>
> Am Thu, Dec 01, 2022 at 07:15:27AM +0100 schrieb Andreas Tille:
> > Hi,
> >
> > Am Wed, Nov 30, 2022 at 10:08:14PM +0100 schrieb Paul Gevers:
> > > Source: r-cran-glmmtmb
> > > Version: 1.1.4+dfsg-3
> > > Severity: serious
> > > Tags: ftbfs
> > > Justification: ftbfs
> > >
> > > Dear maintainer(s),
> > >
> > > Your package failed to build from source on mipsel, where it built
> > > successfully in the past.
> > >
> > > https://buildd.debian.org/status/fetch.php?pkg=r-cran-glmmtmb=mipsel=1.1.5%2Bdfsg-1=1669057119=0
> > > ...
> > > cc1plus: out of memory allocating 1058400 bytes after a total of 59473920 
> > > bytes
> >
> > Isn't this just a matter of the autobuilders hardware?
> >
> > If not I do not see any other clue but removing the package for mipsel.
> >
> > Kind regards
> >
> >  Andreas.
> >
> > --
> > http://fam-tille.de
>
> --
> http://fam-tille.de
>

Bug#1021857: CMake Error at /usr/lib/llvm-14/lib/cmake/llvm/LLVMExports.cmake:1598 (message):

[Mathieu Malaterre]

Salut Sylvestre !

On Wed, Nov 30, 2022 at 9:21 PM Sylvestre Ledru  wrote:
>
> btw, do you know what caused this in cmake? (seems that it is caused by
> a new cmake version).
>
> (or not to make sure that all binaries aren't exported?)

If you have a build-tree of llvm-14, here is what I would do:

$ cd obj-*
$ DESTDIR=/tmp/sylvestre make install
$ find /tmp/sylvestre -name mlir-tblgen
 output1
$ grep mlir-tblgen
/tmp/sylvestre/usr/lib/llvm-14/lib/cmake/llvm/LLVMExports.cmake
 output2
-> verify output1 & output2 matches


>
> Le 28/11/2022 à 12:07, Mathieu Malaterre a écrit :
> > Control: found 1021857 1:14.0.6-2
> >
> > -- Found LibXml2: /usr/lib/x86_64-linux-gnux32/libxml2.so (found
> > version "2.9.14")
> > CMake Error at /usr/lib/llvm-14/lib/cmake/llvm/LLVMExports.cmake:1598 
> > (message):
> >The imported target "mlir-tblgen" references the file
> >
> >   "/usr/lib/llvm-14/bin/mlir-tblgen"
> >
> >but this file does not exist.  Possible reasons include:
> >
> >* The file was deleted, renamed, or moved to another location.
> >
> >* An install or uninstall procedure did not complete successfully.
> >
> >* The installation package was faulty and contained
> >
> >   "/usr/lib/llvm-14/lib/cmake/llvm/LLVMExports.cmake"
> >
> >but not all the files it references.
> >
> > Call Stack (most recent call first):
> >/usr/lib/llvm-14/cmake/LLVMConfig.cmake:323 (include)
> >openvdb_ax/openvdb_ax/CMakeLists.txt:105 (find_package)
> >
> >
> >
> > * 
> > https://buildd.debian.org/status/fetch.php?pkg=openvdb=x32=10.0.0-7=1669627540=0
> >
> > ___
> > Pkg-llvm-team mailing list
> > pkg-llvm-t...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-llvm-team

Bug#1021857: CMake Error at /usr/lib/llvm-14/lib/cmake/llvm/LLVMExports.cmake:1598 (message):

[Mathieu Malaterre]

Control: found 1021857 1:14.0.6-2

-- Found LibXml2: /usr/lib/x86_64-linux-gnux32/libxml2.so (found
version "2.9.14")
CMake Error at /usr/lib/llvm-14/lib/cmake/llvm/LLVMExports.cmake:1598 (message):
  The imported target "mlir-tblgen" references the file

 "/usr/lib/llvm-14/bin/mlir-tblgen"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

 "/usr/lib/llvm-14/lib/cmake/llvm/LLVMExports.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  /usr/lib/llvm-14/cmake/LLVMConfig.cmake:323 (include)
  openvdb_ax/openvdb_ax/CMakeLists.txt:105 (find_package)



* 
https://buildd.debian.org/status/fetch.php?pkg=openvdb=x32=10.0.0-7=1669627540=0

Bug#1021117:

[Mathieu Malaterre]

Control: fixed -1 1:15.0.2-2~exp4
Control: fixed -1 1:15.0.3-1

Ok nevermind I see that the issue is still in riscv64. But I do not
understand why I see in llvm-14...

Bug#1021117: Fixed since 1:15.0.2-2~exp4

[Mathieu Malaterre]

> Fixed since 1:15.0.2-2~exp4

Seems it came back:

* 
https://buildd.debian.org/status/fetch.php?pkg=openvdb=riscv64=10.0.0-6=1669407006=0

CMake Error at /usr/lib/llvm-15/lib/cmake/llvm/LLVMExports.cmake:1631 (message):
  The imported target "mlir-tblgen" references the file

 "/usr/lib/llvm-15/bin/mlir-tblgen"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

 "/usr/lib/llvm-15/lib/cmake/llvm/LLVMExports.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  /usr/lib/llvm-15/cmake/LLVMConfig.cmake:328 (include)
  openvdb_ax/openvdb_ax/CMakeLists.txt:105 (find_package)

And it seems it was present in 14.x series:


* 
https://buildd.debian.org/status/fetch.php?pkg=openvdb=x32=10.0.0-6=1669406822=0

CMake Error at /usr/lib/llvm-14/lib/cmake/llvm/LLVMExports.cmake:1598 (message):
  The imported target "mlir-tblgen" references the file

 "/usr/lib/llvm-14/bin/mlir-tblgen"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

 "/usr/lib/llvm-14/lib/cmake/llvm/LLVMExports.cmake"

  but not all the files it references.

Bug#1013156: gdcm: vtk[6,7] removal

[Mathieu Malaterre]

On Wed, Oct 26, 2022 at 11:19 AM Andreas Tille  wrote:
>
> Hi Mathieu,
>
> Am Wed, Oct 26, 2022 at 11:16:30AM +0200 schrieb Mathieu Malaterre:
> > > > https://salsa.debian.org/med-team/gdcm/-/commits/debian/experimental/
> > >
> > > Ups, sorry for missing this.  I've merged your changes into master but the
> > > said problem remains[1].
> > >
> > > Kind regards
> > > Andreas.
> > >
> > > [1] https://salsa.debian.org/med-team/gdcm/-/jobs/3427720
> >
> > AFAIK, this is a new bug in vtk9.1 package:
> >
> > CMake Error at 
> > /usr/lib/x86_64-linux-gnu/cmake/vtk-9.1/VTK-vtk-module-find-packages.cmake:115
> > (find_package):
> > 5432 By not providing "FindQt5.cmake" in CMAKE_MODULE_PATH this project has
>
> OK, may be this is an explanation for the issue.  Do you see any chance
> for a workaround?  Finally we should upload a VTK 9.x enabled gdcm to
> unstable in a foreseable time frame.

If you open VTK-vtk-module-find-packages.cmake at line 115 you'll see
a 'CMAKE_ERROR', change that into 'CMAKE_WARNING'. that is the patch I
would suggest to vtk9 packager.

2cts
-M

Bug#1013156: gdcm: vtk[6,7] removal

[Mathieu Malaterre]

On Wed, Oct 26, 2022 at 10:35 AM Andreas Tille  wrote:
>
> Hi Mathieu,
>
> Am Wed, Oct 26, 2022 at 08:10:42AM +0200 schrieb Mathieu Malaterre:
> > On Wed, Oct 26, 2022 at 7:53 AM Andreas Tille  wrote:
> > >
> > > Hi,
> > >
> > > in the bug log there is some discussion to drop C# and Java VTK
> > > bindings.  This would mean to drop the packages libvtkgdcm-cil and
> > > libvtkgdcm-java.  I'm perfectly fine with this and I just pushed
> > > a change in d/control where I replaced s/vtk7/vtk9/ globally.  The
> > > build[1] is currently failing at a probably simple Java issue:
> > >
> > > /usr/lib/jvm/default-java/include/jni.h:45:10: fatal error: jni_md.h: No 
> > > such file or directory
> > >45 | #include "jni_md.h"
> > >   |  ^~
> > > compilation terminated.
> > >
> > > I have no idea whether we might keep on supporting the Java bindings if
> > > this can be solved.  But I'm pretty sure we should act on droping
> > > what needs to be droped in a timely manner to make sure gdcm will
> > > remain in testing.
> > >
> > > Any help is welcome.
> >
> > See my original work at:
> >
> > https://salsa.debian.org/med-team/gdcm/-/commits/debian/experimental/
>
> Ups, sorry for missing this.  I've merged your changes into master but the
> said problem remains[1].
>
> Kind regards
> Andreas.
>
> [1] https://salsa.debian.org/med-team/gdcm/-/jobs/3427720

AFAIK, this is a new bug in vtk9.1 package:

CMake Error at 
/usr/lib/x86_64-linux-gnu/cmake/vtk-9.1/VTK-vtk-module-find-packages.cmake:115
(find_package):
5432 By not providing "FindQt5.cmake" in CMAKE_MODULE_PATH this project has

Bug#1013156: gdcm: vtk[6,7] removal

[Mathieu Malaterre]

On Wed, Oct 26, 2022 at 7:53 AM Andreas Tille  wrote:
>
> Hi,
>
> in the bug log there is some discussion to drop C# and Java VTK
> bindings.  This would mean to drop the packages libvtkgdcm-cil and
> libvtkgdcm-java.  I'm perfectly fine with this and I just pushed
> a change in d/control where I replaced s/vtk7/vtk9/ globally.  The
> build[1] is currently failing at a probably simple Java issue:
>
> /usr/lib/jvm/default-java/include/jni.h:45:10: fatal error: jni_md.h: No such 
> file or directory
>45 | #include "jni_md.h"
>   |  ^~
> compilation terminated.
>
> I have no idea whether we might keep on supporting the Java bindings if
> this can be solved.  But I'm pretty sure we should act on droping
> what needs to be droped in a timely manner to make sure gdcm will
> remain in testing.
>
> Any help is welcome.

See my original work at:

https://salsa.debian.org/med-team/gdcm/-/commits/debian/experimental/

Bug#1021165: Gcc 13 requires some (older) glibc headers to be fixed up .

[Mathieu Malaterre]

For reference:

malat@amdahl /tmp % apt-cache policy libc6-dev
libc6-dev:
  Installed: 2.35-1
  Candidate: 2.35-1
  Version table:
 *** 2.35-1 500
500 https://deb.debian.org/debian sid/main armhf Packages
100 /var/lib/dpkg/status

Bug#1021165: armhf: floatn-common.h:214:9: error: multiple types in one declaration

[Mathieu Malaterre]

Source: gcc-snapshot
Version: 1:20220920-1
Severity: grave

Per original reference:

--- Comment #1 from Andrew Pinski  ---
Is this a packaging issue?
> ignoring nonexistent directory 
> "/usr/lib/gcc-snapshot/lib/gcc/arm-linux-gnueabihf/13/include-fixed/arm-linux-gnueabihf"
ignoring nonexistent directory
"/usr/lib/gcc-snapshot/lib/gcc/arm-linux-gnueabihf/13/include-fixed"

Gcc 13 requires some (older) glibc headers to be fixed up .

See:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107128

Bug#1017752: Do you see any chance to fix the "virtual memory exhausted" for nheko on mipsel VM

[Mathieu Malaterre]

On Wed, Sep 28, 2022 at 10:06 PM Andreas Tille  wrote:
>
> Hi mips porters,
>
> in bug #1017752 a
>
>FTBFS on mipsel: virtual memory exhausted: Cannot allocate memory
>
> is reported.  This remains for the new upstream version I've just
> uploaded to experimental[1].  Do you see any chance to fix the memory
> constraint for the autobuilder VM?  If not I'll remove mipsel from the
> list of supported architectures to enable testing migration.

Here is the trick I used on those arches for openvdb:

[...]
# Disable optimization on mipsel because the compiler is running out of memory
# see #847752 / #879636
ifneq (,$(filter $(DEB_BUILD_ARCH), armel armhf i386 mipsel hppa
riscv64 sh4 x32))
  CXXFLAGS:=$(filter-out -O2,$(CXXFLAGS)) --param ggc-min-expand=10 -O1
endif
[...]

https://salsa.debian.org/multimedia-team/openvdb/-/blob/debian/9.1.0-7/debian/rules#L22-26

Bug#1017752: Do you see any chance to fix the "virtual memory exhausted" for nheko on mipsel VM

[Mathieu Malaterre]

On Thu, Sep 29, 2022 at 9:14 AM Mathieu Malaterre  wrote:
>
> On Wed, Sep 28, 2022 at 10:06 PM Andreas Tille  wrote:
> >
> > Hi mips porters,
> >
> > in bug #1017752 a
> >
> >FTBFS on mipsel: virtual memory exhausted: Cannot allocate memory
> >
> > is reported.  This remains for the new upstream version I've just
> > uploaded to experimental[1].  Do you see any chance to fix the memory
> > constraint for the autobuilder VM?  If not I'll remove mipsel from the
> > list of supported architectures to enable testing migration.
>
> Here is the trick I used on those arches for openvdb:
>
> [...]
> # Disable optimization on mipsel because the compiler is running out of memory
> # see #847752 / #879636
> ifneq (,$(filter $(DEB_BUILD_ARCH), armel armhf i386 mipsel hppa
> riscv64 sh4 x32))
>   CXXFLAGS:=$(filter-out -O2,$(CXXFLAGS)) --param ggc-min-expand=10 -O1
> endif
> [...]
>
> https://salsa.debian.org/multimedia-team/openvdb/-/blob/debian/9.1.0-7/debian/rules#L22-26

Here is another simpler one:

* 
https://salsa.debian.org/webkit-team/webkit/-/blob/debian/2.38.0-1/debian/rules#L66

Bug#1020642: webkit2gtk: FTBFS on mipsel: virtual memory exhausted

[Mathieu Malaterre]

On Sat, Sep 24, 2022 at 7:42 PM Simon McVittie  wrote:
> webkit2gtk repeatedly failed to compile on the mipsel buildds:

Here is the trick I used on those arches for openvdb:

[...]
# Disable optimization on mipsel because the compiler is running out of memory
# see #847752 / #879636
ifneq (,$(filter $(DEB_BUILD_ARCH), armel armhf i386 mipsel hppa
riscv64 sh4 x32))
  CXXFLAGS:=$(filter-out -O2,$(CXXFLAGS)) --param ggc-min-expand=10 -O1
endif
[...]

https://salsa.debian.org/multimedia-team/openvdb/-/blob/debian/9.1.0-7/debian/rules#L22-26

Bug#997080: marked as pending in openvdb

[Mathieu Malaterre]

Control: tag -1 pending

Hello,

Bug #997080 in openvdb reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/multimedia-team/openvdb/-/commit/228ff6a6ea16bc030bfd53c6bae663ec5fc085db


d/rules: Do not use gcc/visibility flags. Closes: #997080


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/997080

Bug#997080: openvdb: FTBFS: help2man: can't get `--help' info from ./debian/tmp/usr/bin/vdb_view

[Mathieu Malaterre]

Control: tags -1 - patch
Control: block -1 by 1001457

[Written communication is hard]
It should be noticed that I did communicate privately with Tobias and
I mentioned multiple times both issues are linked.

> I was debugging into this, and IMHO this is not a compiler issue, but a 
> packaging problem:

No. I've uploaded 9.1.0-4 so that this is plain obvious there is no
packaging issue. I apologize for the bumpy transition debhelper 11 ->
13. I did not pay attention openvdb was messed up with debhelper >=
13.

> The attached build should be able to proof that.

Thanks for time and work.

> As this is NOT a libstd++ bug, I'm removing the indication that #1001457 
> blocks this bug.

Yes. It is *exactly* this bug. Although I am not familiar with GCC
internals so the description of the bug may be a bit inaccurate. In
any case, the 9.1.0-4 upload made it extremely clear there is an issue
(I claim this is a 'wrong-code' per GCC bugzilla terminology).

To be extra pedantic, I also included a (commented out) patch in 9.1.0-4:

* 
https://salsa.debian.org/multimedia-team/openvdb/-/blob/debian/9.1.0-4/debian/patches/gcc_pr_103629.patch

For anyone interested in solving #1001457, you can activate this patch
in the d/p/series file.

-M

---

I've spent an insane amount of time reducing the (large!) openvdb
codebase into something GCC dev would accept as Problem Report in
bugzilla. I will now give up and simply remove the visibility flag
stuff. openvdb never provided a symbol flag so this should be
acceptable.

Bug#1018015: src:ilmbase will be removed

[Mathieu Malaterre]

Control: severity -1 normal

I think this is acceptable as-is since imath does Provides:
libilmbase-dev. Reducing severity.

Sorry for the noise.

Bug#1018013: src:ilmbase will be removed

[Mathieu Malaterre]

Control: severity -1 normal

I think this is acceptable as-is since imath does Provides:
libilmbase-dev. Reducing severity.

Sorry for the noise.

Bug#1018015: src:ilmbase will be removed

[Mathieu Malaterre]

Source: openimageio
Version: 2.3.18.0+dfsg-3
Severity: serious

I am planning to remove ilmbase now that openexr 3.1.5 has migrated to
testing. Please replace dependency from  libilmbase-dev into
libimath-dev. There should not be any other difference.

Bug#1018013: src:ilmbase will be removed

[Mathieu Malaterre]

Source: nvidia-texture-tools
Version: 2.0.8-1+dfsg-8.2
Severity: serious

I am planning to remove ilmbase now that openexr 3.1.5 has migrated to
testing. Please replace dependency from  libilmbase-dev into
libimath-dev. There should not be any other difference.

Bug#997080: openvdb / clang

[Mathieu Malaterre]

> This bug is blocking openimageio, which blocks blender. Can this be
> fixed, is it still not reproducible?

I naively thought I could switch to clang instead of gcc to workaround
the issue. It turns out that the Debian tools do not handle object
files generated by clang:

[...]
   dh_fixperms -O--buildsystem=cmake
   dh_missing -O--buildsystem=cmake
   dh_dwz -a -O--buildsystem=cmake
dwz: 
debian/python3-openvdb/usr/lib/python3/dist-packages/pyopenvdb.cpython-310-x86_64-linux-gnu.so:
Unknown debugging section .debug_addr
dwz: debian/libopenvdb9.1/usr/lib/x86_64-linux-gnu/libopenvdb.so.9.1.0:
Unknown debugging section .debug_addr
dh_dwz: error: dwz --
debian/libopenvdb9.1/usr/lib/x86_64-linux-gnu/libopenvdb.so.9.1.0
returned exit code 1
dh_dwz: error: dwz --
debian/python3-openvdb/usr/lib/python3/dist-packages/pyopenvdb.cpython-310-x86_64-linux-gnu.so
returned exit code 1
dwz: debian/libopenvdb-tools/usr/bin/vdb_lod: Unknown debugging
section .debug_addr
dwz: debian/libopenvdb-tools/usr/bin/vdb_print: Unknown debugging
section .debug_addr
dwz: debian/libopenvdb-tools/usr/bin/vdb_render: Unknown debugging
section .debug_addr
dwz: debian/libopenvdb-tools/usr/bin/vdb_view: Unknown debugging
section .debug_addr
dwz: Too few files for multifile optimization
dh_dwz: error: dwz
-mdebian/libopenvdb-tools/usr/lib/debug/.dwz/x86_64-linux-gnu/libopenvdb-tools.debug
-M/usr/lib/debug/.dwz/x86_64-linux-gnu/libopenvdb-tools.debug --
debian/libopenvdb-tools/usr/bin/vdb_lod
debian/libopenvdb-tools/usr/bin/vdb_print
debian/libopenvdb-tools/usr/bin/vdb_render
debian/libopenvdb-tools/usr/bin/vdb_view returned exit code 1
dh_dwz: error: Aborting due to earlier error
make: *** [debian/rules:58: binary] Error 25
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess
returned exit status 2
[...]

Bug#1017547: openexr-viewers FTBFS with openexr 3.1.5

[Mathieu Malaterre]

Hi Pino !

Since openexr-viewers does not build anymore against openexr 3.x and
it is dead upstream, do you want me to fill in a RM for you ?

Thanks

Bug#1017512: freeimage FTBFS with openexr 3.1.5

[Mathieu Malaterre]

Control: tags -1 patch

See attached. Thanks
From f40352706436a15d09767011ec9c9c0df33a57a1 Mon Sep 17 00:00:00 2001
From: Mathieu Malaterre 
Date: Wed, 17 Aug 2022 15:04:22 +0200
Subject: [PATCH] d/patches: Refresh patch to handle openexr 3.x split

---
 debian/patches/Disable-vendored-dependencies.patch | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/debian/patches/Disable-vendored-dependencies.patch b/debian/patches/Disable-vendored-dependencies.patch
index c948008..7844a7e 100644
--- a/debian/patches/Disable-vendored-dependencies.patch
+++ b/debian/patches/Disable-vendored-dependencies.patch
@@ -84,7 +84,7 @@ Index: freeimage-3.18.0+ds2/Source/FreeImage/PluginEXR.cpp
 ===
 --- freeimage-3.18.0+ds2.orig/Source/FreeImage/PluginEXR.cpp
 +++ freeimage-3.18.0+ds2/Source/FreeImage/PluginEXR.cpp
-@@ -28,16 +28,16 @@
+@@ -28,16 +28,17 @@
  #pragma warning (disable : 4800) // ImfVersion.h - 'const int' : forcing value to bool 'true' or 'false' (performance warning)
  #endif 
  
@@ -107,7 +107,8 @@ Index: freeimage-3.18.0+ds2/Source/FreeImage/PluginEXR.cpp
 +#include 
 +#include 
 +#include 
-+#include 
++#include 
++#include 
  
  
  // ==
@@ -404,7 +405,7 @@ Index: freeimage-3.18.0+ds2/Source/FreeImage/PluginTIFF.cpp
 +#include 
  #include "../Metadata/FreeImageTag.h"
 -#include "../OpenEXR/Half/half.h"
-+#include "OpenEXR/half.h"
++#include "Imath/half.h"
  
  #include "FreeImageIO.h"
  #include "PSDParser.h"
-- 
2.30.2

Bug#1017495: Missing Breaks on libopenexr-dev ?

[Mathieu Malaterre]

Dear imath maintainer;

I believe there is something missing for a proper upgrade path of imath (*).

Would it be possible to add a

Breaks: libopenexr-dev (<= 2.5.7-2)

% sudo apt install libimath-dev
[...]
(Reading database ... 189739 files and directories currently installed.)
Preparing to unpack .../libopenexr-dev_3.1.5-2_amd64.deb ...
Unpacking libopenexr-dev (3.1.5-2) over (2.5.7-1) ...
dpkg: error processing archive
/var/cache/apt/archives/libopenexr-dev_3.1.5-2_amd64.deb (--unpack):
 trying to overwrite '/usr/include/OpenEXR/Iex.h', which is also in
package libilmbase-dev:amd64 2.5.7-2
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/libopenexr-dev_3.1.5-2_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#1017495: libopenexr-dev: trying to overwrite '/usr/include/OpenEXR/Iex.h', which is also in package libilmbase-dev

[Mathieu Malaterre]

On Wed, Aug 17, 2022 at 2:24 AM Christian Marillat  wrote:
>
> Package: libopenexr-dev
> Version: 2.5.7-1
> Severity: serious
>
> Dear Maintainer,
>
> I can't upgrade this package.
>
> ,
> | Preconfiguring packages ...
> | (Reading database ... 325236 files and directories currently installed.)
> | Preparing to unpack .../libopenexr-dev_3.1.5-2_amd64.deb ...
> | Unpacking libopenexr-dev (3.1.5-2) over (2.5.7-1) ...
> | dpkg: error processing archive 
> /var/cache/apt/archives/libopenexr-dev_3.1.5-2_amd64.deb (--unpack):
> |  trying to overwrite '/usr/include/OpenEXR/Iex.h', which is also in package 
> libilmbase-dev:amd64 2.5.7-2
> | dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> | Errors were encountered while processing:
> |  /var/cache/apt/archives/libopenexr-dev_3.1.5-2_amd64.deb
> `

What's the actual exact command ?

Thanks

Bug#1009308:

[Mathieu Malaterre]

Control: tags -1 wontfix
Control: tags -1 - patch
Control: severity -1 normal

I am not sure I can integrate your patch since libimath-dev does
Provide: libilmbase-dev.

Also:

% sudo apt install libimath-dev
[...]
The following packages will be REMOVED:
  libilmbase-dev
The following NEW packages will be installed:
  libimath-dev
0 upgraded, 1 newly installed, 1 to remove and 0 not upgraded.
Need to get 117 kB of archives.
After this operation, 342 kB of additional disk space will be used.

I suspect there is something else going on wrong on your end. I am
tempted to just close.

Bug#1016331: marked as pending in gdcm

[Mathieu Malaterre]

Control: tag -1 pending

Hello,

Bug #1016331 in gdcm reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/med-team/gdcm/-/commit/03bc56ee308df00a816be236a634aba5ec98783d


d/patches: Fix doxygen/pdf generation. Closes: #1016331


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1016331

Bug#964654: kcov: FTBFS: ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libbfd.a(plugin.o): undefined reference to symbol 'dlclose@@GLIBC_2.2.5'

[Mathieu Malaterre]

Dear Alessandro,

Any chance you could merge the suggested MR  ?

Thanks

Bug#1014091: armhf: gcc has wrong configuration

[Mathieu Malaterre]

Hi Richard !

On Thu, Jun 30, 2022 at 4:45 PM Richard Earnshaw
 wrote:
>
> I think the problem is valgrind's Makefiles are passing -mcpu=cortex-a8
> to the compiler.  Cortex-a8 has Neon and the compiler now makes use of that.
>
> On the subject of the configuration of GCC
>
> --with-arch=armv7-a+fp

Thanks for the quick response.

> *is* the correct configuration for the baseline GCC; it adds a vfpv3
> with 16 double-precision registers.  +vfpv3-fp16 would add support for
> the float16 load/store operations, while +nosimd is a nop because no
> other options have been added to enable SIMD.

I managed to misread the gcc arm options page (fp16 != d16). Thanks
for the explanation.

I've suggested valgrind people the following patch:

% sed -i -e 's/cortex-a8/generic-armv7-a+vfpv3-d16/g' Makefile.all.am

Hopefully my understanding is correct this time.

-M

Bug#928224: patch

[Mathieu Malaterre]

valgrind should apply the following patch:

sed -i -e 's/cortex-a8/generic-armv7-a+vfpv3-d16/g' Makefile.all.am

Bug#928224: Valgrind is broken on armhf

[Mathieu Malaterre]

% gdb "/usr/libexec/valgrind/memcheck-arm-linux"
GNU gdb (Debian 12.1-2) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/libexec/valgrind/memcheck-arm-linux...
Reading symbols from
/usr/lib/debug/.build-id/c8/4acaae37749c83c7183bc7a37bbde299e52e82.debug...
(gdb) r
Starting program: /usr/libexec/valgrind/memcheck-arm-linux

Program received signal SIGILL, Illegal instruction.
vgPlain_am_startup (sp_at_startup=3204445888) at
m_aspacemgr/aspacemgr-linux.c:1626
1626   init_nsegment();
(gdb) bt full
#0  vgPlain_am_startup (sp_at_startup=3204445888) at
m_aspacemgr/aspacemgr-linux.c:1626
seg = {kind = 0, start = 0, end = 0, smode = SmLower, dev = 0,
ino = 0, offset = 5376491600740352, mode = 3204445892, fnIdx =
-1090521408, hasR = 0 '\000', hasW = 160 '\240', hasX = 37 '%',
  hasT = 88 'X', isCH = 248 '\370'}
suggested_clstack_end = 
__PRETTY_FUNCTION__ = "vgPlain_am_startup"
#1  0x580cc5e4 in valgrind_main (envp=0xbefff6cc, argv=0xbefff6c4,
argc=1) at m_main.c:1387
loglevel = 
i = 
vex_archinfo = {hwcaps = 0, endness = 0, hwcache_info =
{num_levels = 0, num_caches = 0, caches = 0x0,
icaches_maintain_coherence = 0 '\000'}, ppc_icache_line_szB = 0,
ppc_dcbz_szB = 0,
  ppc_dcbzl_szB = 0, arm64_dMinLine_lg2_szB = 0,
arm64_iMinLine_lg2_szB = 0, arm64_requires_fallback_LLSC = 0 '\000'}
need_help = 
tid_main = 0
addr2dihandle = 0x0
wd = 
need_help = 
tid_main = 
loglevel = 
i = 
addr2dihandle = 
__PRETTY_FUNCTION__ = "valgrind_main"
vex_archinfo = 
wd = 
tmp_str = 
res = 
val = 
res = 
val = 
s = 
n = 
res = 
val = 
s = 
n = 
val = 
ok = 
errmsg = 
limLo = 
limHi = 
aLocal = 
p = 
cp = 
vex_arch = 
ok = 
buf = 
buf2 = 
fd = 
r = 
nul = 
exename = 
client_auxv = 
client_auxv_len = 
--Type  for more, q to quit, c to continue without paging--
arg = 
s = 
ok = 
seg_starts = 
n_seg_starts = 
anu = 
change_ownership_v_c_OK = 
co_start = 
co_endPlus = 
buf = 
seg_starts = 
n_seg_starts = 
j = 
n = 
seg = 
anl = 
inaccessible_len = 
seg = 
seg = 
#2  _start_in_C_linux (pArgc=0xbefff6c0) at m_main.c:3081
r = 
argc = 1
argv = 0xbefff6c4
envp = 0xbefff6cc
#3  0x in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Bug#1013258: autoreconf: error: /usr/bin/autoconf failed with exit status: 1

[Mathieu Malaterre]

Control: tags -1 wontfix

On Mon, Jun 20, 2022 at 1:39 PM Andreas Tille  wrote:
>
> Am Mon, Jun 20, 2022 at 10:38:12AM +0200 schrieb Mathieu Malaterre:
> > Source: openslide
> > Severity: important
> > Tags: ftbfs
> >
> > Dear Maintainer,
> >
> > It seems openslide does not build anymore. See for instance:
> >
> > * https://salsa.debian.org/med-team/openslide/-/jobs/2899560
>
> I wonder why you assume that this is an autoreconf issue after you
> removed Build-Depends that are seeked for:

Fixed: efaad2d.

> configure.ac:PKG_CHECK_MODULES(GLIB2, [glib-2.0 >= 2.16, gthread-2.0, 
> gio-2.0, gobject-2.0])

I was expecting a line saying the opposite of:

[...]
checking for glib-2.0 >= 2.16, gthread-2.0, gio-2.0, gobject-2.0... yes
[...]

Anyway, point taken, I'll stay away from autotool and such in the future.

Thanks,

Bug#1008798: gdcm: FTBFS on s390x

[Mathieu Malaterre]

Control: fixed -1 3.0.12-1

Fixed in latest upload

Bug#1007234: Test suite fails on all but amd64 arches

[Mathieu Malaterre]

Bryan,

On Tue, Mar 29, 2022 at 1:45 PM Mathieu Malaterre  wrote:
>
> Bryan,
>
> On Sat, Mar 26, 2022 at 2:00 AM Bryan Henderson  
> wrote:
> >
> > I don't know familiar you are with debuggers, C, or C arithmetic, so I'm
> > attaching a diagnostic version of the program and will also explain where I
> > think the problem lies in case you want to investigate on your own.

I am going to discard the test-suite result in Debian package.
Something is not quite right on my side.

Compiling netpbm with gcc-10+ubsan gives odd results on my amd64:

== palm-roundtrip.test ==
pamdepth: promoting from black and white to grayscale
pnmcolormap: making histogram...
pnmcolormap: Scanning image 0
pnmcolormap: 20314 colors so far
pnmcolormap: 20314 colors found
pnmcolormap: choosing 256 colors...
pnmremap: 256 colors found in colormap
pmfileio.c:664:26: runtime error: left shift of 128 by 24 places
cannot be represented in type 'int'
pmfileio.c:664:26: runtime error: left shift of 128 by 24 places
cannot be represented in type 'int'
pmfileio.c:664:26: runtime error: left shift of 128 by 24 places
cannot be represented in type 'int'
pmfileio.c:664:26: runtime error: left shift of 128 by 24 places
cannot be represented in type 'int'
palm-roundtrip.test: FAILURE

I am going to /assume/ code is not tested on arch other than amd64, so
I think this is acceptable behavior.


Thanks for your help.

Bug#1007234: Test suite fails on all but amd64 arches

[Mathieu Malaterre]

Bryan,

On Sat, Mar 26, 2022 at 2:00 AM Bryan Henderson  wrote:
>
> I don't know familiar you are with debuggers, C, or C arithmetic, so I'm
> attaching a diagnostic version of the program and will also explain where I
> think the problem lies in case you want to investigate on your own.
>
> If you put this .c file in converter/other/pnmtopalm/ and rebuild and run the
> 'palmtopnm' executable that results, it should detect the failure and write
> some useful diagnostic messages.  Tell me what happens.

Thanks !

Here is what I see on my local riscv64/chroot

== palm-roundtrip.test ==
pamdepth: promoting from black and white to grayscale
palmtopnm: Invalid Palm image input.  Header says 30 bytes per row
after uncompressing from 8-bit Packbits, but we counted 4294967069
bytes in a row, before we stopped processing the row
pnmcolormap: making histogram...
pnmcolormap: Scanning image 0
pnmcolormap: 20314 colors so far
pnmcolormap: 20314 colors found
pnmcolormap: choosing 256 colors...
pnmremap: 256 colors found in colormap
palmtopnm: Invalid Palm image input.  Header says 228 bytes per row
after uncompressing from 8-bit Packbits, but we counted 4294967044
bytes in a row, before we stopped processing the row
palm-roundtrip.test: FAILURE


Pay attention that I cannot do any kind of gdb locally:

 % gdb ./converter/other/pnmtopalm/palmtopnm
[...]
(gdb) r
Starting program:
/home/mathieu/debian/netpbm/converter/other/pnmtopalm/palmtopnm
warning: Could not trace the inferior process.
warning: ptrace: Function not implemented
During startup program exited with code 127.


>
> The problem is in function 'readPackBitsRow16'.  The variable 'j' is getting
> too large -- absurdly large, apparently because a bit code that is supposed to
> encode a negative signed integer is being interpreted as a positive unsigned
> one somewhere.  It should not be hard to pinpoint where the arithmetic is
> generating such a a large number.
>
> --
> Bryan Henderson   San Jose, California

Bug#1007234: Test suite fails on all but amd64 arches

[Mathieu Malaterre]

For some reason I never got your answer. So I've subscribed to
`1007...@bugs.debian.org`

> I'm sure this is easy to diagnose for someone who can reproduce it.

I've followed the instructions from:
* https://wiki.debian.org/RISC-V#debootstrap

I have now a RISCV-64 arch on my amd64 machine.

Now:

$ dget -u 
http://deb.debian.org/debian/pool/main/n/netpbm-free/netpbm-free_10.97.00-1.dsc
$ cd netpbm*
$ debuild -B

So I have a complete built tree of netpbm. What should I do now for issue:

...

== palm-roundtrip.test ==
pamdepth: promoting from black and white to grayscale
palmtopnm: Invalid Palm image input.  Header says 30 bytes per row
after uncompressing from 8-bit Packbits, but we counted 4294967069
bytes in a row, before we stopped processing the row
pnmcolormap: making histogram...
pnmcolormap: Scanning image 0
pnmcolormap: 20314 colors so far
pnmcolormap: 20314 colors found
pnmcolormap: choosing 256 colors...
pnmremap: 256 colors found in colormap
palmtopnm: Invalid Palm image input.  Header says 228 bytes per row
after uncompressing from 8-bit Packbits, but we counted 4294967044
bytes in a row, before we stopped processing the row
palm-roundtrip.test: FAILURE
...

Thanks

Bug#1007234: Test suite fails on all but amd64 arches

[Mathieu Malaterre]

Dear Bryan,

Could you comment on the buildds failures at:

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

For example on ppc64el (little endian system):

* 
https://buildd.debian.org/status/fetch.php?pkg=netpbm-free=ppc64el=2%3A10.97.00-1=1647179729=0


[...]

== palm-roundtrip.test ==
pamdepth: promoting from black and white to grayscale
palmtopnm: Invalid Palm image input.  Header says 30 bytes per row
after uncompressing from 8-bit Packbits, but we counted 4294967069
bytes in a row, before we stopped processing the row
pnmcolormap: making histogram...
pnmcolormap: Scanning image 0
pnmcolormap: 20314 colors so far
pnmcolormap: 20314 colors found
pnmcolormap: choosing 256 colors...
pnmremap: 256 colors found in colormap
palmtopnm: Invalid Palm image input.  Header says 228 bytes per row
after uncompressing from 8-bit Packbits, but we counted 4294967044
bytes in a row, before we stopped processing the row
palm-roundtrip.test: FAILURE

== palm-roundtrip2.test ==
pnmremap: 231 colors found in colormap
palmtopnm: Invalid Palm image input.  Header says 228 bytes per row
after uncompressing from 8-bit Packbits, but we counted 4294967088
bytes in a row, before we stopped processing the row
palm-roundtrip2.test: FAILURE
[...]

Thanks !

Bug#1007167: Acknowledgement (_clock_system.h:34:27: error: using-declaration for non-member at class scope)

[Mathieu Malaterre]

For reference:

* https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/synfig.html

Bug#1007167: _clock_system.h:34:27: error: using-declaration for non-member at class scope

[Mathieu Malaterre]

Source: synfix
Version: 1.4.0+dfsg-2.1
Severity: grave

I cannot compile synfig on sid/amd64. It fails with a cryptic c++
compilation error:

libtool: compile:  g++ -DHAVE_CONFIG_H -I../.. -I../../src -Wdate-time
-D_FORTIFY_SOURCE=2 -I/usr/include -I/usr/include/glibmm-2.4
-I/usr/lib/x86_64-linux-gnu/glibmm-2.4/include -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/sigc++-2.0
-I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -pthread
-I/usr/include/giomm-2.4 -I/usr/lib/x86_64-linux-gnu/giomm-2.4/include
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glibmm-2.4
-I/usr/lib/x86_64-linux-gnu/glibmm-2.4/include -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/sigc++-2.0
-I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include
-I/usr/include/libxml++-2.6
-I/usr/lib/x86_64-linux-gnu/libxml++-2.6/include
-I/usr/include/libxml2 -I/usr/include/glibmm-2.4
-I/usr/lib/x86_64-linux-gnu/glibmm-2.4/include -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/sigc++-2.0
-I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -fopenmp
-DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp
-DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp
-DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16
-I/usr/include/x86_64-linux-gnu//ImageMagick-6
-I/usr/include/ImageMagick-6
-I/usr/include/x86_64-linux-gnu//ImageMagick-6
-I/usr/include/ImageMagick-6
-I/usr/include/x86_64-linux-gnu//ImageMagick-6
-I/usr/include/ImageMagick-6 -I/usr/include/cairo
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
-I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2
-I/usr/include/libpng16 -pthread -I/usr/include/pango-1.0
-I/usr/include/harfbuzz -I/usr/include/pango-1.0
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi
-I/usr/include/harfbuzz -I/usr/include/cairo -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1
-I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16
-I/usr/include/mlt-7/mlt++ -I/usr/include/mlt-7 -I/usr/include/ETL
-I/usr/include/sigc++-2.0
-I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -DSYNFIG_NO_DEPRECATED
-DLOCALEDIR=\"/usr/share/locale\"
-DLIBDIR=\"/usr/lib/x86_64-linux-gnu\" -DSYSCONFDIR=\"/etc/synfig\"
-ffile-prefix-map=/home/malat/synfig-1.4.0+dfsg=.
-fstack-protector-strong -Wformat -Werror=format-security -O2 -DNDEBUG
-W -Wall -c target_tile.cpp  -fPIC -DPIC -o
.libs/libsynfig_la-target_tile.o
In file included from /usr/include/ETL/ETL/clock:56,
 from target_tile.cpp:37:
/usr/include/ETL/ETL/_clock_system.h:34:27: error: using-declaration
for non-member at class scope
   34 | # define __sys_clock::clock
  |   ^
In file included from /usr/include/c++/11/mutex:39,
 from node.h:40,
 from valuenode.h:39,
 from canvas.h:40,
 from target.h:39,
 from target_tile.h:32,
 from target_tile.cpp:39:
/usr/include/c++/11/chrono:3373:25: error: expected ';' before '=' token
 3373 |   using __sys_clock = chrono::system_clock;
  | ^
/usr/include/c++/11/chrono:3373:25: error: expected unqualified-id
before '=' token
/usr/include/c++/11/chrono:3385:63: error: type/value mismatch at
argument 1 in template parameter list for 'template struct std::chrono::time_point'
 3385 | _S_from_sys(const chrono::time_point<__sys_clock,
_Dur>& __t) noexcept
  |   ^
/usr/include/c++/11/chrono:3385:63: note:   expected a type, got 'clock'
/usr/include/c++/11/chrono:3394:45: error: type/value mismatch at
argument 1 in template parameter list for 'template struct std::chrono::time_point'
 3394 | chrono::time_point<__sys_clock, _Dur>
  | ^
/usr/include/c++/11/chrono:3394:45: note:   expected a type, got 'clock'
/usr/include/c++/11/chrono: In static member function 'static
std::filesystem::__file_clock::time_point
std::filesystem::__file_clock::now()':
/usr/include/c++/11/chrono:3355:27: error: no matching function for
call to 
'std::filesystem::__file_clock::_S_from_sys(std::chrono::_V2::system_clock::time_point)'
 3355 |   { return _S_from_sys(chrono::system_clock::now()); }
  |~~~^
/usr/include/c++/11/chrono:3385:9: note: candidate: 'template static std::chrono::time_point std::filesystem::__file_clock::_S_from_sys(const int&)'
 3385 | _S_from_sys(const chrono::time_point<__sys_clock,
_Dur>& __t) noexcept
  | ^~~
/usr/include/c++/11/chrono:3385:9: note:   template argument
deduction/substitution failed:
/usr/include/c++/11/chrono:3355:27: note:   couldn't deduce template
parameter '_Dur'
 3355 |   { return 

Bug#1002061: libjxl-dev: ships files already in libhwy-dev

[Mathieu Malaterre]

Control: fixed -1 0.6.1+ds-6

jpeg-xl (0.6.1+ds-6) experimental; urgency=medium
[...]
  * d/rules: Start using the system installed hwy

Thanks

Bug#999608: marked as pending in epubcheck

[Mathieu Malaterre]

Control: tag -1 pending

Hello,

Bug #999608 in epubcheck reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/java-team/epubcheck/-/commit/48941903878ff650f8979f0433b51810a50599f4


d/control: Add missing Depends on `default-jre`. Closes: #999608


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/999608

Bug#999900: epubcheck: java.lang.StackOverflowError

[Mathieu Malaterre]

Control: severity -1 important

Since this bug affects a limited set of architecture, I do not believe
severity can be set to `grave` (please correct if wrong).

On amd64:

```
% epubcheck /usr/share/doc/debian-policy/policy.epub
Validating using EPUB version 3.2 rules.
ERROR(PKG-006): /usr/share/doc/debian-policy/policy.epub(-1,-1):
Mimetype file entry is missing or is not the first file in the
archive.
INFO(HTM_053): /usr/share/doc/debian-policy/policy.epub/ch-opersys.xhtml(95,30):
Found an external file link (file://) in file: "reference external"
href="file:///usr/sh".

Check finished with errors
Messages: 0 fatals / 1 error / 0 warnings / 1 info

EPUBCheck completed
```

Bug#1003933: w3c-sgml-lib: catalogs for MathML 2.0 are incomplete

[Mathieu Malaterre]

Control: forwarded -1 https://github.com/w3c/markup-validator/issues/66
Control: tags -1 upstream

As discussed in upstream bug tracker there is something wrong with the
namespace "TR"...

Bug#1004067: closed by Debian FTP Masters (reply to Mathieu Malaterre ) (Bug#1004067: fixed in imath 3.1.3-10)

[Mathieu Malaterre]

Hi all,

On Sun, Jan 23, 2022 at 10:45 PM Matteo F. Vescovi  wrote:
>
> Version: 3.1.3-10
>
> On 2022-01-23 at 18:42 (+01), Matteo F. Vescovi wrote:
> > The build still ftbfs.
>
> Gosh, at the time of writing was still using -9 revision and it failed.
> Now, I've tested -10 revision of imath and openexr builds just fine with
> it.

My fix is rather a crude hack. I do not believe the python ecosystem
(AFAIK) is ever using cmake export files for package dependencies. So
I believe the right fix would be to "undeclare" the python module from
the list of exported cmake module. Maybe we'll need to forward the
issue upstream.

Bug#1002216: jpylyzer: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13

[Mathieu Malaterre]

Control: fixed -1 2.0.1-1

Bug#1003218: Processed: your mail

[Mathieu Malaterre]

Control: found -1 0.15.0-4

See:

* 
https://buildd.debian.org/status/fetch.php?pkg=highway=armhf=0.15.0-4=1641752465=0

Bug#984276: opencolorio: ftbfs with GCC-11

[Mathieu Malaterre]

Control: upstream confirmed fixed-upstream

https://github.com/AcademySoftwareFoundation/OpenColorIO/commit/2f87cca2e129471f57df0c3a8a3adc0c73a4811c.patch

Bug#1001136: Possible miscompilation triggered by -fvisibility=hidden

[Mathieu Malaterre]

See:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

Bug#997080: openvdb: FTBFS: help2man: can't get `--help' info from ./debian/tmp/usr/bin/vdb_view

[Mathieu Malaterre]

Control: notfound -1 8.1.0-3
Control: tags -1 wontfix

I cannot reproduce the issue:
* On my local sid schroot,
* On barriere.d.o
* The exp. buildds are working as expected:
** 
https://buildd.debian.org/status/fetch.php?pkg=openvdb=amd64=9.0.0-2=1638489598=0

Bug#1000220: marked as pending in dcmtk

[Mathieu Malaterre]

Control: tag -1 pending

Hello,

Bug #1000220 in dcmtk reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/med-team/dcmtk/-/commit/48c24b0f258b9503053b0583ce4c7cf84427c72c


d/patches: Fix compilation of dicomscope. Closes: #1000220


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1000220

Bug#1000222: marked as pending in orthanc

[Mathieu Malaterre]

Control: tag -1 pending

Hello,

Bug #1000222 in orthanc reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/med-team/orthanc/-/commit/fa9b65bf0c3cc68105d115483d904034933ac3cc


d/patches: Remove c++11 hardcoded value. Closes: #1000222


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1000222

Bug#1000222: orthanc force gnuc++11 reason

[Mathieu Malaterre]

Control: tags -1 patch

Could someone confirm; this is an acceptable patch ?

thanks


donotforcec++11.patch
Description: Binary data

Bug#1000222: orthanc force gnuc++11 reason

[Mathieu Malaterre]

Control: tags -1 upstream confirmed
Control: affects -1 dcmtk/3.6.6-2

For some reason orthanc forces the uses of gnuc++11 gcc compiler flag.
Unless there is a good reason, I would simply suggest to remove this
hard-coded value:

 % grep -r gnu++11 .
./OrthancFramework/Resources/CMake/DownloadOrthancFramework.cmake:
 set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=gnu++11")
./OrthancFramework/Resources/CMake/JsonCppConfiguration.cmake:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=gnu++11")
./OrthancFramework/UnitTestsSources/CMakeLists.txt:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=gnu++11")

Bug#1000220: /usr/include/dcmtk/dcmsr/dsrtlist.h:303:30: error: cannot convert 'std::__cxx11::list >::iterator'

[Mathieu Malaterre]

Control: tags -1 patch

Here is one possible fix:

https://github.com/DCMTK/dcmtk/pull/45

Thanks for consideration.

Bug#1000220: /usr/include/dcmtk/dcmsr/dsrtlist.h:303:30: error: cannot convert 'std::__cxx11::list >::iterator'

[Mathieu Malaterre]

Control: tags -1 upstream
Control: found -1 3.6.6-2

Dear DCMTK team,

The DCMTK package 3.6.6-2 currently in Debian/sid fails to build
because of (*). Could you please confirm that DCMTK_ENABLE_STL:BOOL=ON
is an acceptable option for releasing DCMTK in Debian, and that the
toolkit codebase should handle this with c++14 compiler ?

Thanks

(*)
 % cat t.cxx
#include 
int main()
{
  DSRListOfItems l;
  l.removeItem(0);
}

 % g++ t.cxx
In file included from t.cxx:1:
/usr/include/dcmtk/dcmsr/dsrtlist.h: In instantiation of 'OFCondition
DSRListOfItems::removeItem(size_t) [with T = int; size_t = long
unsigned int]':
t.cxx:5:15:   required from here
/usr/include/dcmtk/dcmsr/dsrtlist.h:303:30: error: cannot convert
'std::__cxx11::list >::iterator' to
'std::__cxx11::list >::const_iterator&'
  303 | if (gotoItemPos(idx, iterator))
  |  ^~~~
  |  |
  |  std::__cxx11::list >::iterator
/usr/include/dcmtk/dcmsr/dsrtlist.h:320:64: note:   initializing
argument 2 of 'OFBool DSRListOfItems::gotoItemPos(size_t, typename
std::__cxx11::list::const_iterator&) const [with T = int; OFBool =
bool; size_t = long unsigned int; typename
std::__cxx11::list::const_iterator = std::__cxx11::list >::const_iterator]'
  320 |OFLIST_TYPENAME OFListConstIterator(T)
) const
  |^

Bug#1000221: wontfix

[Mathieu Malaterre]

Control: tags -1 wontfix

See bug#1000320

...
error: ‘STATUS_N_PRINT_BSB_Fail_PrintQueueFull’ was not declared in
this scope; did you mean ‘STATUS_N_PRINT_BFB_Fail_PrintQueueFull’?
...

For reference upstream refactored the whole DIMSE status codes at:

https://git.dcmtk.org/?p=dcmtk.git;a=commit;h=5422b14947

Bug#996820: marked as pending in gdcm

[Mathieu Malaterre]

Control: tag -1 pending

Hello,

Bug #996820 in gdcm reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/med-team/gdcm/-/commit/0430689f0202806ba81218e5f2b10f7d20f2e2f1


d/rules: Build manpages before installing them. Closes: #996820


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/996820

Bug#989296: [RFR] libgdcm-dev/3.0.8-2 (to close #989296)

[Mathieu Malaterre]

Salut Étienne,

On Fri, Jul 30, 2021 at 9:21 PM Étienne Mollier  wrote:
>
> Hi Mathieu,
>
> Mathieu Malaterre, on 2021-07-30:
> > Hi all,
> >
> > I've reviewed commit 92bee7344b774b45b66185ed17b040f12fe31c43. I've
> > not verified it fixes the OP symptoms, but this is the right fix IMHO.
> >
> > I've also reviewed cddfeab955f486fba72745b66130480dfec1a2b6 and this
> > is not the right fix, sorry. See #711214 for more context.
>
> No worries, Thank you for your review!  :)
>
> So, if I understood correctly #711214 and #989296, then it seems
> to me that, once vtkgdcmsharpglue and vtkgdcmPython are detected
> properly, the remaining messages will be warnings only.  They
> won't impede the build; that is, until the shared objects are
> effectively needed, in which case one should install the
> components independently.  So the fix to d/rules is sufficient,
> no need to touch d/control to address that bug, I guess.

Right ! The point is that on some arch you still want to be able to
install libgdcm-dev without the cil (C# binding is not available
everywhere) or vtk (may require opengl related package which would be
hard to install on headless server).

Debian packages should not be monolithic just because upstream failed
to implement proper *.cmake components packaging.

2cts

Bug#989296: [RFR] libgdcm-dev/3.0.8-2 (to close #989296)

[Mathieu Malaterre]

Hi all,

I've reviewed commit 92bee7344b774b45b66185ed17b040f12fe31c43. I've
not verified it fixes the OP symptoms, but this is the right fix IMHO.

I've also reviewed cddfeab955f486fba72745b66130480dfec1a2b6 and this
is not the right fix, sorry. See #711214 for more context.

2cts

On Fri, Jul 30, 2021 at 9:17 AM Andreas Tille  wrote:
>
> Hi Étienne,
>
> thanks a lot for your work on this.  I'm explicitly putting current an
> past Uploaders in the row.  It would be great if you could review the
> changes to make sure we will not loose a lot of dependencies.
>
> Kind regards
>
>  Andreas.
>
> On Thu, Jul 29, 2021 at 11:55:35PM +0200, Étienne Mollier wrote:
> > Hello,
> >
> > I pushed a couple of changes to gdcm [1], in order to address
> > the important bug #989296, which ended up bumped to serious.
> > I'm not 100% confident I grasped the problem at play, but with
> > the window for bringing changes now closing, I'm afraid I can't
> > afford spending too much more time on verifications.  I intend
> > to file a (pre?) approval request to the Release Team and
> > upload, maybe tomorrow or Saturday.
> >
> > [1]: https://salsa.debian.org/med-team/gdcm/
> >
> > I am not a cmake expert, and am not sure how to reproduce
> > #989296, so I would appreciate if someone could have a seconde
> > look, just to make sure that what I wrapped up was sound.
> >
> > FYI, I already ran a bunch of build and autopkgtest with the
> > numerous reverse build dependencies of libgdcm-dev in Testing,
> > and I have not witnessed any regression.  So, I'm tempted to
> > think I am on the right track.
> >
> > Have a nice day,  :)
> > --
> > Étienne Mollier 
> > Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
> > Sent from /dev/pts/2, please excuse my verbosity.
>
>
>
> --
> http://fam-tille.de



-- 
Mathieu

Bug#976906: Possible lex issue for ppc64el (Was: Bug#976906: libpll: FTBFS on ppc64el: lex_utree.l:22:10: fatal error: parse_utree.h: No such file or directory)

[Mathieu Malaterre]

"make -j160"

that would be my guess :)

remove parallel from the dh option, and try again (fixes symptoms)

On Thu, Dec 10, 2020 at 10:49 AM Andreas Tille  wrote:
>
> Control: tags -1 help
>
> Hi,
>
> I tried to investigate the situation below and my guess is that lex has
> somehow problems to create the missing header files.  I've found the
> files in upstreams .gitignore file so these need to be created but this
> does not seem to work on ppc64el (any more - since the package has build
> successfully before).
>
> Any hint to tackle this is welcome
>
>   Andreas.
>
> On Wed, Dec 09, 2020 at 09:37:42AM +0100, Lucas Nussbaum wrote:
> > Source: libpll
> > Version: 0.3.2-3
> > Severity: serious
> > Justification: FTBFS on ppc64el
> > Tags: bullseye sid ftbfs
> > Usertags: ftbfs-20201209 ftbfs-bullseye ftbfs-ppc64el
> >
> > Hi,
> >
> > During a rebuild of all packages in sid, your package failed to build
> > on ppc64el. At the same time, it did not fail on amd64.
> >
> > I'm marking this bug as severity:serious since your package currently has
> > ppc64el binary packages in unstable (so this is a regression).
> >
> > Relevant part (hopefully):
> > > /bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
> > > -I..   -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE 
> > > -std=c99 -O3 -fPIC -g -c -o libpll_la-lex_utree.lo `test -f 'lex_utree.c' 
> > > || echo './'`lex_utree.c
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c fasta.c  -fPIC -DPIC -o .libs/libpll_la-fasta.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c pll.c  -fPIC -DPIC -o .libs/libpll_la-pll.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c likelihood.c  -fPIC -DPIC -o .libs/libpll_la-likelihood.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c maps.c  -fPIC -DPIC -o .libs/libpll_la-maps.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c output.c  -fPIC -DPIC -o .libs/libpll_la-output.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c utree.c  -fPIC -DPIC -o .libs/libpll_la-utree.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c utree_moves.c  -fPIC -DPIC -o .libs/libpll_la-utree_moves.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c models.c  -fPIC -DPIC -o .libs/libpll_la-models.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c parsimony.c  -fPIC -DPIC -o .libs/libpll_la-parsimony.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c core_partials.c  -fPIC -DPIC -o .libs/libpll_la-core_partials.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c derivatives.c  -fPIC -DPIC -o .libs/libpll_la-derivatives.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c utree_svg.c  -fPIC -DPIC -o .libs/libpll_la-utree_svg.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c gamma.c  -fPIC -DPIC -o .libs/libpll_la-gamma.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c rtree.c  -fPIC -DPIC -o .libs/libpll_la-rtree.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c list.c  -fPIC -DPIC -o .libs/libpll_la-list.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c partials.c  -fPIC -DPIC -o .libs/libpll_la-partials.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c 

Bug#973723:

[Mathieu Malaterre]

Control: tags -1 fixed-upstream

http://git.dcmtk.org/?p=dcmtk.git;a=commit;h=46b4b4c

Bug#974544: marked as pending in charls

[Mathieu Malaterre]

Control: tag -1 pending

Hello,

Bug #974544 in charls reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/med-team/charls/-/commit/2b7631c83029d528dbd4eb8f158985914f873332


d/control: Provide a clean upgrade path. Closes: #974544

libcharls-dev needs Breaks+Replaces: libdcmtk-dev (<< 3.6.5-1~)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/974544

Bug#974544: libcharls-dev needs Breaks+Replaces: libdcmtk-dev (<< 3.6.5-1~)

[Mathieu Malaterre]

Control: retitle -1 libcharls-dev needs Breaks: libdcmtk-dev (<< 3.6.5-1~)

On Thu, Nov 12, 2020 at 8:13 AM Adrian Bunk  wrote:
>
> On Thu, Nov 12, 2020 at 08:09:11AM +0100, Mathieu Malaterre wrote:
> > On Thu, Nov 12, 2020 at 8:06 AM Adrian Bunk  wrote:
> > >
> > > Control: reopen -1
> > >
> > > On Thu, Nov 12, 2020 at 08:02:07AM +0100, Mathieu Malaterre wrote:
> > > > Control: fixed -1 2.1.0+dfsg-7
> > > >
> > > > https://salsa.debian.org/med-team/charls/-/blob/debian/2.1.0+dfsg-7/debian/control#L22
> > > >
> > > > dcmtk 3.6.5 ships a convenient copy of CharLS with SOVERSION=1, while
> > > > libcharls-dev is SOVERSION=2, so I'll not add the Replaces.
> > >
> > > The conflict is on the unversioned libcharls.so symlink.
> >
> > Could you confirm you saw that dcmtk 3.6.5-1 does *not* ship
> > libcharls.so anymore ?
>
> https://buildd.debian.org/status/logs.php?pkg=odin=2.0.4-0.2%2Bb1=amd64

OK, I understand the issue now.

Thanks

Bug#974544: libcharls-dev needs Breaks+Replaces: libdcmtk-dev (<< 3.6.5-1~)

[Mathieu Malaterre]

On Thu, Nov 12, 2020 at 8:06 AM Adrian Bunk  wrote:
>
> Control: reopen -1
>
> On Thu, Nov 12, 2020 at 08:02:07AM +0100, Mathieu Malaterre wrote:
> > Control: fixed -1 2.1.0+dfsg-7
> >
> > https://salsa.debian.org/med-team/charls/-/blob/debian/2.1.0+dfsg-7/debian/control#L22
> >
> > dcmtk 3.6.5 ships a convenient copy of CharLS with SOVERSION=1, while
> > libcharls-dev is SOVERSION=2, so I'll not add the Replaces.
>
> The conflict is on the unversioned libcharls.so symlink.

Could you confirm you saw that dcmtk 3.6.5-1 does *not* ship
libcharls.so anymore ?

Thanks for your help

Bug#974544: libcharls-dev needs Breaks+Replaces: libdcmtk-dev (<< 3.6.5-1~)

[Mathieu Malaterre]

Control: fixed -1 2.1.0+dfsg-7

https://salsa.debian.org/med-team/charls/-/blob/debian/2.1.0+dfsg-7/debian/control#L22

dcmtk 3.6.5 ships a convenient copy of CharLS with SOVERSION=1, while
libcharls-dev is SOVERSION=2, so I'll not add the Replaces.

Bug#973723: libcharls-dev ships libcharls.so which is also in libdcmtk-dev

[Mathieu Malaterre]

Hi Gert,

On Wed, Nov 4, 2020 at 10:06 AM Mathieu Malaterre  wrote:
>
> Control: tags -1 patch upstream confirmed
>
> On Wed, Nov 4, 2020 at 9:13 AM Mathieu Malaterre  wrote:
> >
> > Control: reassign -1 src:dcmtk
> >
> > > trying to overwrite '/usr/lib/x86_64-linux-gnu/libcharls.so', which is 
> > > also in package libdcmtk-dev 3.6.4-2.1+b1
> >
> > Dear dcmtk maintainer,
> >
> > Would it make sense to rename the customized charls included as a
> > convenient copy in dcmtk as 'libdcmcharls.so' instead of simply
> > 'libcharls.so' ?
> >
> > Thanks for comments,
>
> Here is a suggested patch for cmake based build system to handle
> renaming of charls to dcmcharls.

I'd like to go ahead and apply the patch send in msg #19. Do you mind
if I apply it on top of dcmtk/experimental version, and upload to
unstable ? Or is there a reason to keep dcmtk 3.6.5 in experimental ?

Thanks for comment,

Bug#972867: marked as pending in charls

[Mathieu Malaterre]

Control: tag -1 pending

Hello,

Bug #972867 in charls reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/med-team/charls/-/commit/8b3ac29c6332194018fce3c827f99f3b3e11832c


d/rule: Really install symlink. Closes: #972867


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/972867

Bug#973723: libcharls-dev ships libcharls.so which is also in libdcmtk-dev

[Mathieu Malaterre]

Control: tags -1 patch upstream confirmed

On Wed, Nov 4, 2020 at 9:13 AM Mathieu Malaterre  wrote:
>
> Control: reassign -1 src:dcmtk
>
> > trying to overwrite '/usr/lib/x86_64-linux-gnu/libcharls.so', which is also 
> > in package libdcmtk-dev 3.6.4-2.1+b1
>
> Dear dcmtk maintainer,
>
> Would it make sense to rename the customized charls included as a
> convenient copy in dcmtk as 'libdcmcharls.so' instead of simply
> 'libcharls.so' ?
>
> Thanks for comments,

Here is a suggested patch for cmake based build system to handle
renaming of charls to dcmcharls.

Thanks
diff --git a/dcmjpls/apps/CMakeLists.txt b/dcmjpls/apps/CMakeLists.txt
index 2a9a452..eff767f 100644
--- a/dcmjpls/apps/CMakeLists.txt
+++ b/dcmjpls/apps/CMakeLists.txt
@@ -8,5 +8,5 @@ endforeach()
 
 # make sure executables are linked to the corresponding libraries
 foreach(PROGRAM dcmcjpls dcmdjpls dcml2pnm)
-  DCMTK_TARGET_LINK_MODULES(${PROGRAM} dcmjpls charls dcmimage dcmimgle dcmdata oflog ofstd ofstd)
+  DCMTK_TARGET_LINK_MODULES(${PROGRAM} dcmjpls dcmcharls dcmimage dcmimgle dcmdata oflog ofstd ofstd)
 endforeach()
diff --git a/dcmjpls/libcharls/CMakeLists.txt b/dcmjpls/libcharls/CMakeLists.txt
index 0c5b143..3ae8d07 100644
--- a/dcmjpls/libcharls/CMakeLists.txt
+++ b/dcmjpls/libcharls/CMakeLists.txt
@@ -2,6 +2,6 @@
 include_directories("${dcmjpls_SOURCE_DIR}/libcharls" "${ofstd_SOURCE_DIR}/include")
 
 # create library from source files
-DCMTK_ADD_LIBRARY(charls header intrface jpegls)
+DCMTK_ADD_LIBRARY(dcmcharls header intrface jpegls)
 
-DCMTK_TARGET_LINK_MODULES(charls ofstd oflog)
+DCMTK_TARGET_LINK_MODULES(dcmcharls ofstd oflog)
diff --git a/dcmjpls/libcharls/intrface.h b/dcmjpls/libcharls/intrface.h
index c8fdaa9..49bb777 100644
--- a/dcmjpls/libcharls/intrface.h
+++ b/dcmjpls/libcharls/intrface.h
@@ -10,7 +10,7 @@
 #include "dcmtk/ofstd/ofstd.h"/* for size_t */
 #include "dcmtk/ofstd/ofdefine.h" /* for DCMTK_DECL_EXPORT */
 
-#ifdef charls_EXPORTS
+#ifdef dcmcharls_EXPORTS
 #define DCMTK_CHARLS_EXPORT DCMTK_DECL_EXPORT
 #else
 #define DCMTK_CHARLS_EXPORT DCMTK_DECL_IMPORT
diff --git a/dcmjpls/libsrc/CMakeLists.txt b/dcmjpls/libsrc/CMakeLists.txt
index 314face..d48471a 100644
--- a/dcmjpls/libsrc/CMakeLists.txt
+++ b/dcmjpls/libsrc/CMakeLists.txt
@@ -4,4 +4,4 @@ include_directories("${dcmjpls_SOURCE_DIR}/include" "${ofstd_SOURCE_DIR}/include
 # create library from source files
 DCMTK_ADD_LIBRARY(dcmjpls djcparam djdecode djencode djrparam djcodecd djutils djcodece)
 
-DCMTK_TARGET_LINK_MODULES(dcmjpls ofstd oflog dcmdata dcmimgle dcmimage charls)
+DCMTK_TARGET_LINK_MODULES(dcmjpls ofstd oflog dcmdata dcmimgle dcmimage dcmcharls)
diff --git a/debian/control b/debian/control
index 0880d5e..974d8d0 100644
--- a/debian/control
+++ b/debian/control
@@ -6,7 +6,6 @@ Priority: optional
 Build-Depends: cmake,
debhelper (>= 9),
help2man,
-   libcharls-dev,
libpng-dev,
libsndfile1-dev,
libssl-dev,

Bug#973723: libcharls-dev ships libcharls.so which is also in libdcmtk-dev

[Mathieu Malaterre]

Control: reassign -1 src:dcmtk

> trying to overwrite '/usr/lib/x86_64-linux-gnu/libcharls.so', which is also 
> in package libdcmtk-dev 3.6.4-2.1+b1

Dear dcmtk maintainer,

Would it make sense to rename the customized charls included as a
convenient copy in dcmtk as 'libdcmcharls.so' instead of simply
'libcharls.so' ?

Thanks for comments,

Bug#972867: Patch

[Mathieu Malaterre]

Case sensitive systems are affected by 2.1.0 release.
diff --git a/CMake/FindCharLS.cmake b/CMake/FindCharLS.cmake
index 8f6bf19..b253a61 100644
--- a/CMake/FindCharLS.cmake
+++ b/CMake/FindCharLS.cmake
@@ -6,7 +6,7 @@
 #  For details see the accompanying COPYING-CMAKE-SCRIPTS file.
 #
 
-find_path(CHARLS_INCLUDE_DIR CharLS/charls.h
+find_path(CHARLS_INCLUDE_DIR charls/charls.h
 /usr/local/include
 /usr/include
 )
diff --git a/Utilities/gdcm_charls.h b/Utilities/gdcm_charls.h
index b80451c..e01d75b 100644
--- a/Utilities/gdcm_charls.h
+++ b/Utilities/gdcm_charls.h
@@ -18,7 +18,7 @@
 #include "gdcmTypes.h"
 #ifdef GDCM_USE_SYSTEM_CHARLS
 // It is expected that version 2.0.0 is used
-# include 
+# include 
 #else
 #include "gdcmcharls/charls.h"
 #endif

Bug#972430: nvidia-legacy-340xx-driver 340.108-6~bpo10+1

[Mathieu Malaterre]

Control: found -1 340.108-6~bpo10+1

Would be nice to have a bpo of -8 at some point.

Thanks very much ! This is my only option as nouveau is unstable on this system.

Bug#972867: CharLS should have changed its SOVERSION

[Mathieu Malaterre]

Control: tags -1 upstream

For details:

https://github.com/team-charls/charls/issues/81

Bug#970271: marked as pending in blender

[Mathieu Malaterre]

Control: tag -1 pending

Hello,

Bug #970271 in blender reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/multimedia-team/blender/-/commit/47ac40bef35a5e1af7ce29a31ef133cd132649bf


d/patches: Fix compilation with OpenVDB. Closes: #970271


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/970271

Bug#966670: marked as pending in pixelmed

[Mathieu Malaterre]

Control: tag -1 pending

Hello,

Bug #966670 in pixelmed reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/med-team/pixelmed/-/commit/a19e09be02dbb506e5c5756372dbc10109f404c9


d/patches: Add -c flag to iconv to prevent failure. Closes: #966670


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/966670

Bug#963444: update Google Guava dependency to v24.0

[Mathieu Malaterre]

Control: tags -1 fixed-upstream patch confirmed

See:

https://github.com/w3c/epubcheck/pull/833#issuecomment-367052775