Bug#1076699: jpeg-xl: 0.10.3 failing autopkgtests

[Mathieu Malaterre]

Control: forwarded -1 https://github.com/libjxl/libjxl/issues/3714

On Mon, Jul 22, 2024 at 5:36 AM Jeremy Bícha  wrote:
> The autopkgtests for jpeg-xl 0.10.3 are failing. This will need to be
> fixed before it can migrate to Testing.

I am going to remove that section for now.

Thanks

Bug#1075917: marked as pending in dcmtk

[Mathieu Malaterre]

Control: tag -1 pending

Hello,

Bug #1075917 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/df880c7da1ec0b8f52e3e5e89236e55a0654c099


d/t/run-unit-test: Fix unit-test for new release. Closes: #1075917


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1075917

Bug#1074483: marked as pending in dcmtk

[Mathieu Malaterre]

Control: tag -1 pending

Hello,

Bug #1074483 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/71a4fcfd112d8be5d0b61e9c1509d255c3ac8e24


d/patches: Fixed possible overflows when allocating memory. Closes: #1074483


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1074483

Bug#1075916: libdcmtk-dev: Removed dependencies are required for a CMake target

[Mathieu Malaterre]

Control: reassign -1 liborthancframework-dev

On Sun, Jul 7, 2024 at 9:48 PM Adrian Bunk  wrote:
>
> Package: libdcmtk-dev
> Version: 3.6.8-5
> Severity: serious
> Tags: ftbfs
> Control: affects -1 src:orthanc-neuro
>
> https://buildd.debian.org/status/logs.php?pkg=orthanc-neuro&ver=1.1%2Bdfsg-1%2Bb1
>
> ...
> [ 90%] Linking CXX shared library libOrthancNeuro.so
> /usr/bin/cmake -E cmake_link_script CMakeFiles/OrthancNeuro.dir/link.txt 
> --verbose=1
> /usr/bin/c++ -fPIC -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -fstack-clash-protection -Wformat 
> -Werror=format-security -fcf-protection -DNDEBUG -Wdate-time 
> -D_FORTIFY_SOURCE=2 -Wall -Wno-long-long -Wno-variadic-macros -Wl,-z,relro 
> -Wl,-z,now -Wl,--no-undefined -Wl,--as-needed 
> -Wl,--version-script=/<>/Resources/Orthanc/Plugins/VersionScriptPlugins.map
>  -shared -Wl,-soname,libOrthancNeuro.so.1.1 -o libOrthancNeuro.so.1.1 
> CMakeFiles/OrthancNeuro.dir/Sources/Plugin/Plugin.cpp.o 
> CMakeFiles/OrthancNeuro.dir/Sources/Plugin/PluginFrameDecoder.cpp.o 
> CMakeFiles/OrthancNeuro.dir/Sources/Framework/BufferReader.cpp.o 
> CMakeFiles/OrthancNeuro.dir/Sources/Framework/CSAHeader.cpp.o 
> CMakeFiles/OrthancNeuro.dir/Sources/Framework/CSATag.cpp.o 
> CMakeFiles/OrthancNeuro.dir/Sources/Framework/DicomInstancesCollection.cpp.o 
> CMakeFiles/OrthancNeuro.dir/Sources/Framework/IDicomFrameDecoder.cpp.o 
> CMakeFiles/OrthancNeuro.dir/Sources/Framework/InputDicomInstance.cpp.o 
> CMakeFiles/OrthancNeuro.dir/Sources/Framework/NeuroToolbox.cpp.o 
> CMakeFiles/OrthancNeuro.dir/Sources/Framework/NiftiWriter.cpp.o 
> CMakeFiles/OrthancNeuro.dir/Sources/Framework/Slice.cpp.o 
> CMakeFiles/OrthancNeuro.dir/AUTOGENERATED/EmbeddedResources.cpp.o 
> CMakeFiles/OrthancNeuro.dir/Resources/Orthanc/Plugins/OrthancPluginCppWrapper.cpp.o
>   -lpthread -lrt -ldl -Wl,-Bstatic -lOrthancFramework -Wl,-Bdynamic -ldcmdata 
> -ldcmjpls -ldcmimage -ldcmjpeg -lofstd -lboost_filesystem -lboost_iostreams 
> -lboost_locale -lboost_regex -lboost_thread -lpugixml -luuid -ljsoncpp -lpng 
> -ljpeg -lz -lniftiio -lznz -lrt -ldl -Wl,-Bstatic -lOrthancFramework 
> -Wl,-Bdynamic -ldcmdata -ldcmjpls -ldcmimage -ldcmjpeg -lofstd 
> -lboost_filesystem -lboost_iostreams -lboost_locale -lboost_regex 
> -lboost_thread -lpugixml -luuid -ljsoncpp -lpng -ljpeg -lz -lniftiio -lznz
> /usr/bin/ld: cannot find -lpng: No such file or directory
> /usr/bin/ld: cannot find -ljpeg: No such file or directory
> /usr/bin/ld: cannot find -lpng: No such file or directory
> /usr/bin/ld: cannot find -ljpeg: No such file or directory
> collect2: error: ld returned 1 exit status
> make[3]: *** [CMakeFiles/OrthancNeuro.dir/build.make:300: 
> libOrthancNeuro.so.1.1] Error 1
>
>
>
> dcmtk (3.6.8-4) experimental; urgency=medium
> ...
>   * d/control: Reduce number of dependencies for -dev package
>
>
> That's problematic when the CMake files require them for some target:
>   /usr/lib/x86_64-linux-gnu/cmake/dcmtk/DCMTKTargets.cmake:  
> INTERFACE_LINK_LIBRARIES 
> "DCMTK::oflog;DCMTK::dcmdata;DCMTK::dcmimgle;/usr/lib/x86_64-linux-gnu/libtiff.so;/usr/lib/x86_64-linux-gnu/libjpeg.so;/usr/lib/x86_64-linux-gnu/libpng.so"
>

Here is what I have no my side:

% grep tiff  /usr/lib/x86_64-linux-gnu/cmake/dcmtk/DCMTKTargets.cmake
-> nothing

since I manually simplified it to:

[...]
  INTERFACE_LINK_LIBRARIES "DCMTK::oflog;DCMTK::dcmdata;DCMTK::dcmimgle"
[...]

Rebuilding orthanc-neuro with this new cmake file *still* triggers the
exact same symptoms. I suspect it is dues to orthanc-neuro d/rules:

[...]
"-DORTHANC_FRAMEWORK_ADDITIONAL_LIBRARIES=dcmdata [...] png jpeg
[...]

Fundamentally I believe the real linking error should occur with the
static libs:

% nm  /usr/lib/gcc/x86_64-linux-gnu/13/../../../../lib/libOrthancFramework.a
| grep png | head
 T
_ZN7Orthanc9PngReader7PngRabi14MemoryCallbackEP14png_struct_defPhm
 U png_create_info_struct

% apt-cache show liborthancframework-dev | grep Depends
Depends: liborthancframework1 (= 1.12.4+dfsg-2), libboost-all-dev,
libcivetweb-dev (>= 1.14), libdcmtk-dev, libjsoncpp-dev,
liblua5.3-dev, libpugixml-dev, libsqlite3-dev


Thanks,

Bug#1075795: orthanc FTBFS with DCMTK 3.6.8

[Mathieu Malaterre]

Source: orthanc
Version: 1.12.4+dfsg-1
Severity: serious
Tags: ftbfs

-- Could NOT find OpenSSL, try to set the path to OpenSSL root folder
in the system variable OPENSSL_ROOT_DIR (missing:
OPENSSL_CRYPTO_LIBRARY OPENSSL_INCLUDE_DIR)
CMake Error at 
/<>/OrthancFramework/Resources/CMake/OpenSslConfiguration.cmake:64
(message):
  Unable to find OpenSSL
Call Stack (most recent call first):
  
/<>/OrthancFramework/Resources/CMake/OrthancFrameworkConfiguration.cmake:260
(include)
  CMakeLists.txt:114 (include)


-- Configuring incomplete, errors occurred!
cd BuildStaticFramework && tail -v -n \+0 CMakeCache.txt

https://people.debian.org/~emollier/transitions/dcmtk/orthanc_dcmtk.build.xz

Bug#1075794: orthanc-wsi FTBFS with DCMTK 3.6.8

[Mathieu Malaterre]

Source: orthanc-wsi
Version: 2.0+dfsg-2
Severity: serious
Tags: ftbfs

/<>/Framework/Inputs/CytomineImage.cpp:36:10: fatal
error: openssl/hmac.h: No such file or directory
   36 | #include 
  |  ^~~~
compilation terminated.


https://people.debian.org/~emollier/transitions/dcmtk/orthanc-wsi_dcmtk.build.xz

Bug#1075792: sight FTBFS with DCMTK 3.6.8

[Mathieu Malaterre]

Source: sight
Version: 23.1.0-3
Severity: serious
Tags: ftbfs

sight::core::com::Slot&,
unsigned int, const std::__cxx11::basic_string&)>::sptr)’:
/<>/libs/io/dimse/SeriesEnquirer.cpp:140:41: error:
‘UID_RFC2557MIMEEncapsulationTransferSyntax’ was not declared in this
scope; did you mean
‘UID_RETIRED_RFC2557MIMEEncapsulationTransferSyntax’?
  140 | 
transferSyntaxes.DCMTK_EMPLACE_BACK(UID_RFC2557MIMEEncapsulationTransferSyntax);
  |
^~
  |
UID_RETIRED_RFC2557MIMEEncapsulationTransferSyntax
/<>/libs/io/dimse/SeriesEnquirer.cpp:141:41: error:
‘UID_XMLEncodingTransferSyntax’ was not declared in this scope; did
you mean ‘UID_RETIRED_XMLEncodingTransferSyntax’?
  141 | transferSyntaxes.DCMTK_EMPLACE_BACK(UID_XMLEncodingTransferSyntax);
  | ^
  |
UID_RETIRED_XMLEncodingTransferSyntax
[ 49%] Building CXX object
libs/geometry/data/CMakeFiles/geometry_data.dir/MeshFunctions.cpp.o

https://people.debian.org/~emollier/transitions/dcmtk/sight_dcmtk.build.xz

Bug#1075793: plastimatch FTBFS with DCMTK 3.6.8

[Mathieu Malaterre]

Source: plastimatch
Version: 1.9.4+dfsg.1-2
Severity: serious
Tags: ftbfs

/<>/src/plastimatch/base/dcmtk_rtss.cxx: In member
function ‘void Dcmtk_rt_study::rtss_save(const char*)’:
/<>/src/plastimatch/base/dcmtk_rtss.cxx:475:46: error:
‘DCM_ROIObservationLabel’ was not declared in this scope; did you mean
‘DCM_ObservationNumber’?
  475 | rtroio_item->putAndInsertString (DCM_ROIObservationLabel,
  |  ^~~
  |  DCM_ObservationNumber

https://people.debian.org/~emollier/transitions/dcmtk/plastimatch_dcmtk.build.xz

It has been retired:

% cat dcmdata/include/dcmtk/dcmdata/dcdeftag.h | grep 3006 | grep 85
#define DCM_RETIRED_ROIObservationLabel  DcmTagKey(0x3006, 0x0085)

Bug#1062022: marked as pending in dcmtk

[Mathieu Malaterre]

Control: tag -1 pending

Hello,

Bug #1062022 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/d24b828b56a7c7bc8a03d4ebdaab6c9baf60293f


Rename libraries for 64-bit time_t transition.

Closes: #1062022
Signed-off-by: Étienne Mollier 


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1062022

Bug#1073416: jpeg-xl: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=8 ninja test returned exit code 1

[Mathieu Malaterre]

Control: tags -1 fixed-upstream
Control: fixed -1 0.9.2-8

On Wed, Jun 19, 2024 at 10:24 AM Moritz Firsching  wrote:
>
>
>
> On Tue, Jun 18, 2024 at 5:44 PM Mathieu Malaterre  wrote:
>>
>> Control: tags -1 confirmed
>>
>> [0.9.x is pending the transition green light from debian-release team]
>>
>> On Sun, Jun 16, 2024 at 3:35 PM Lucas Nussbaum  wrote:
>> >
>> > Source: jpeg-xl
>> > Version: 0.8.2-4
>> > Severity: serious
>> > Justification: FTBFS
>> > Tags: trixie sid ftbfs
>> > User: lu...@debian.org
>> > Usertags: ftbfs-20240615 ftbfs-trixie
>> >
>> > Hi,
>> >
>> > During a rebuild of all packages in sid, your package failed to build
>> > on amd64.
>> [...]
>> > >
>> > > The following tests FAILED:
>> > >   1800 - DecodeTest.ExtentedBoxSizeTest (Failed)
>>
>> It looks like the testdata has changed one file in place. So libjxl
>> 0.8.x and 0.9.x test suite do not seem to have a consistent behavior
>> with the following file (*).
>>
>> Moritz, could you confirm that libjxl 0.8.x is expected to fail
>> DecodeTest.ExtentedBoxSizeTest and as such should be considered an
>> invalid release for Debian archive ?
>
> I can confirm that libjxl 0.8.x is expected to fail on that. I don't know the 
> consequences like making this an invalid release for Debian archive.

OK. In that case I'll leave the bug as-is and marked it as fixed on 0.9.x.

Thanks !

Bug#1073416: jpeg-xl: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=8 ninja test returned exit code 1

[Mathieu Malaterre]

Control: tags -1 confirmed

[0.9.x is pending the transition green light from debian-release team]

On Sun, Jun 16, 2024 at 3:35 PM Lucas Nussbaum  wrote:
>
> Source: jpeg-xl
> Version: 0.8.2-4
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240615 ftbfs-trixie
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
[...]
> >
> > The following tests FAILED:
> >   1800 - DecodeTest.ExtentedBoxSizeTest (Failed)

It looks like the testdata has changed one file in place. So libjxl
0.8.x and 0.9.x test suite do not seem to have a consistent behavior
with the following file (*).

Moritz, could you confirm that libjxl 0.8.x is expected to fail
DecodeTest.ExtentedBoxSizeTest and as such should be considered an
invalid release for Debian archive ?

(*)
% git log -- jxl/boxes/square-extended-size-container.jxl
commit 8a1dafb89c27ce0d31ab98b122bafa65869e129a
Author: Moritz Firsching 
Date:   Thu Nov 23 10:55:45 2023 +0100

fix extended size container

commit f5158aa87916ffad4b5497bd1edf3ebab8aadbab
Author: Moritz Firsching 
Date:   Wed Jun 15 13:53:10 2022 +0200

add jxl with extented size container (#5)

Bug#1072822: marked as pending in gdcm

[Mathieu Malaterre]

Control: tag -1 pending

Hello,

Bug #1072822 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/f923088d30f69598e1476f4fe7139e64b41ec8f2


d/patches: gdcm FTBFS with VTK 9.3.0. Closes: #1072822


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1072822

Bug#1072822: Patch available

[Mathieu Malaterre]

Control: tags -1 upstream fixed-upstream

On Mon, Jun 17, 2024 at 9:36 PM Adrien Nader  wrote:
> I've prepared a fixed version in Ubuntu and Graham uploaded it. There is
> another issue than this SPDX one.
>
> I'm attaching the patch and won't paraphrase it.

Thanks !

Bug#1072963: jpeg-xl: Failing autopkgtests on non-amd64

[Mathieu Malaterre]

Julian,

On Tue, Jun 11, 2024 at 1:06 AM Jeremy Bícha  wrote:
>
> Source: jpeg-xl
> Version: 0.9.2-6
> Severity: serious
> Tags: experimental
>
> jpeg-xl in experimental has autopkgtests that are failing on all
> architectures except for amd64.
>
> Specifically, the problem is that debian/libjxl-gdk-pixbuf.postinst
> and debian/libjxl-gdk-pixbuf.postrm have hardcoded the amd64
> architecture which means that libjxl-gdk-pixbuf is uninstallable on
> architectures other than amd64.
>
> https://ci.debian.net/packages/j/jpeg-xl/unstable/arm64/
>
> https://salsa.debian.org/debian-phototools-team/libjxl/-/blob/debian/experimental/debian/libjxl-gdk-pixbuf.postinst

Could you comment on the above ?

Thanks

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&arch=amd64&ver=2.5.0-1%2Bb1&stamp=1673540495&raw=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&arch=all&ver=1%3A2.8-2&stamp=1672905531&raw=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&arch=mipsel&ver=1.1.5%2Bdfsg-1&stamp=1669057119&raw=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&arch=x32&ver=10.0.0-7&stamp=1669627540&raw=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&arch=x32&ver=10.0.0-7&stamp=1669627540&raw=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&arch=riscv64&ver=10.0.0-6&stamp=1669407006&raw=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&arch=x32&ver=10.0.0-6&stamp=1669406822&raw=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(&seg);
(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&arch=ppc64el&ver=2%3A10.97.00-1&stamp=1647179729&raw=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 _S_from_sys(chrono::system_clock::now

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&arch=armhf&ver=0.15.0-4&stamp=1641752465&raw=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&arch=amd64&ver=9.0.0-2&stamp=1638489598&raw=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)
&iterator) 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 compress

Bug#973723:

[Mathieu Malaterre]

Control: tags -1 fixed-upstream

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