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#1075986: ITP: rotatepdf -- A simple utility to rotate PDF documents.

[Mathieu Malaterre]

On Tue, Jul 9, 2024 at 3:06 AM Joseph Warner  wrote:
>
> Package: wnpp
> Severity: wishlist
> Owner: Joseph Warner 
>
> * Package name: rotatepdf
>   Version : 1.0.0
>   Upstream Author : none
> * URL : none

^really ? no upstream source ?

> * License : GPL-2+
>   Programming Lang: Shell
>   Description : A simple utility to rotate PDF documents.

There are already plenty of cli tools in Debian.

> Rotate PDF files in place. Rotatepdf is a wrapper around PDFtk.
> Terminal usage and several GUI-based file managers are supported.
>
> Why?
> Provide a simpler method to rotate entire PDF files than PDFtk itslef, which
> is very powerful but extremely complicated for such a simple use case.

https://unix.stackexchange.com/questions/394065/command-line-how-do-you-rotate-a-pdf-file-90-degrees

> Additionally, provide the option to install file manager scripts so
> that PDF files can be rotated from the GUI via the right-click
> context menu.
>
> Maintenance?
> I should be capable of maintaining the package myself.
>

2cts

Bug#1056302: FreeBSD/iconv: ISO 2022 IR 13\ISO 2022 IR 87

[Mathieu Malaterre]

Control: fixed -1 3.6.8-5

On Mon, Nov 20, 2023 at 9:57 AM Mathieu Malaterre  wrote:
>
> Source: dcmtk
> Version: 3.6.8~git20231027.1549d8c-2
>
> Somewhat related to #988644.
>
> Steps:
>
> % curl -O https://dclunie.com/images/charset/charsettests.20070405.tar.bz2
> % tar xf charsettests.20070405.tar.bz2
> % cp charsettests/SCSH32 new.dcm
> % dcmodify -i "0018,1020=123\456" new.dcm
>
> Gives
>
>  % dcmdump +U8 new.dcm | grep "0018,1020\|0010,0010"
> (0010,0010) PN [ﾔﾏﾀﾞ^ﾀﾛｳ=山田^太郎=やまだ^たろう] #  56, 1 PatientName
> (0018,1020) LO [123¥456]   #   8, 1 
> SoftwareVersions
>
> It has been confirmed by upstream that this is a bug. Patch is under review

% dcmdump +U8 new.dcm | grep "0018,1020\|0010,0010"
(0010,0010) PN [ﾔﾏﾀﾞ^ﾀﾛｳ=山田^太郎=やまだ^たろう] #  56, 1 PatientName
(0018,1020) LO [123\456]#   8, 2
SoftwareVersions

Bug#1039465: DICOM/JSON: (0018,1411) DS [-3. ] # 4,1 Exposure Index

[Mathieu Malaterre]

Control: fixed -1 3.6.8-5

Seems to be fixed today.

% dcmodify -i 0018,1411=-3. test.dcm
% dcm2json test.dcm | grep -A 5 1411
  "00181411": {
"vr": "DS",
"Value": [
  -3.0
]
  },

Bug#1056048:

[Mathieu Malaterre]

Control: found -1 3.6.8-5

% valgrind  --leak-check=full --show-leak-kinds=all dcm2json
charsettests/SCSARAB  output.json
==58329== Memcheck, a memory error detector
==58329== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==58329== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info
==58329== Command: dcm2json charsettests/SCSARAB output.json
==58329==
==58329==
==58329== HEAP SUMMARY:
==58329== in use at exit: 842 bytes in 2 blocks
==58329==   total heap usage: 80,063 allocs, 80,061 frees, 2,121,516
bytes allocated
==58329==
==58329== 26 bytes in 1 blocks are still reachable in loss record 1 of 2
==58329==at 0x4840808: malloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==58329==by 0x4E5EC19: strdup (strdup.c:42)
==58329==by 0x4FB9CC9: ??? (in
/usr/lib/x86_64-linux-gnu/liboficonv.so.18.3.6.8)
==58329==by 0x4FB454D: ??? (in
/usr/lib/x86_64-linux-gnu/liboficonv.so.18.3.6.8)
==58329==by 0x4FB145B: ??? (in
/usr/lib/x86_64-linux-gnu/liboficonv.so.18.3.6.8)
==58329==by 0x4FB75DF: ??? (in
/usr/lib/x86_64-linux-gnu/liboficonv.so.18.3.6.8)
==58329==by 0x4AE71C6:
OFCharacterEncoding::selectEncoding(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&) (in
/usr/lib/x86_64-linux-gnu/libofstd.so.18.3.6.8)
==58329==by 0x49B2337:
DcmSpecificCharacterSet::selectCharacterSetWithoutCodeExtensions() (in
/usr/lib/x86_64-linux-gnu/libdcmdata.so.18.3.6.8)
==58329==by 0x49B291F:
DcmSpecificCharacterSet::selectCharacterSet(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&) (in
/usr/lib/x86_64-linux-gnu/libdcmdata.so.18.3.6.8)
==58329==by 0x498BBBA:
DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&, unsigned long, bool) (in
/usr/lib/x86_64-linux-gnu/libdcmdata.so.18.3.6.8)
==58329==by 0x498905A:
DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&, unsigned long,
bool) (in /usr/lib/x86_64-linux-gnu/libdcmdata.so.18.3.6.8)
==58329==by 0x4986CF0: DcmItem::convertToUTF8() (in
/usr/lib/x86_64-linux-gnu/libdcmdata.so.18.3.6.8)
==58329==
==58329== 816 bytes in 1 blocks are still reachable in loss record 2 of 2
==58329==at 0x4840808: malloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==58329==by 0x4FB9CB5: ??? (in
/usr/lib/x86_64-linux-gnu/liboficonv.so.18.3.6.8)
==58329==by 0x4FB454D: ??? (in
/usr/lib/x86_64-linux-gnu/liboficonv.so.18.3.6.8)
==58329==by 0x4FB145B: ??? (in
/usr/lib/x86_64-linux-gnu/liboficonv.so.18.3.6.8)
==58329==by 0x4FB75DF: ??? (in
/usr/lib/x86_64-linux-gnu/liboficonv.so.18.3.6.8)
==58329==by 0x4AE71C6:
OFCharacterEncoding::selectEncoding(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&) (in
/usr/lib/x86_64-linux-gnu/libofstd.so.18.3.6.8)
==58329==by 0x49B2337:
DcmSpecificCharacterSet::selectCharacterSetWithoutCodeExtensions() (in
/usr/lib/x86_64-linux-gnu/libdcmdata.so.18.3.6.8)
==58329==by 0x49B291F:
DcmSpecificCharacterSet::selectCharacterSet(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&) (in
/usr/lib/x86_64-linux-gnu/libdcmdata.so.18.3.6.8)
==58329==by 0x498BBBA:
DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&, unsigned long, bool) (in
/usr/lib/x86_64-linux-gnu/libdcmdata.so.18.3.6.8)
==58329==by 0x498905A:
DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&, unsigned long,
bool) (in /usr/lib/x86_64-linux-gnu/libdcmdata.so.18.3.6.8)
==58329==by 0x4986CF0: DcmItem::convertToUTF8() (in
/usr/lib/x86_64-linux-gnu/libdcmdata.so.18.3.6.8)
==58329==by 0x10C248: ??? (in /usr/bin/dcm2json)
==58329==
==58329== LEAK SUMMARY:
==58329==definitely lost: 0 bytes in 0 blocks
==58329==indirectly lost: 0 bytes in 0 blocks
==58329==  possibly lost: 0 bytes in 0 blocks
==58329==still reachable: 842 bytes in 2 blocks
==58329== suppressed: 0 bytes in 0 blocks
==58329==
==58329== For lists of detected and suppressed errors, rerun with: -s
==58329== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Bug#988644: Defined Term: ISO 2022 IR 87 is not supported

[Mathieu Malaterre]

Control: fixed -1 3.6.8-5

% curl -s --output test.dcm
"https://sourceforge.net/p/gdcm/gdcmdata/ci/master/tree/NM-PAL-16-PixRep1.dcm?format=raw;
% dcmconv +U8 test.dcm testU8.dcm
W: DcmSpecificCharacterSet: Escape sequences shall not be used in the
first component group of a Person Name (PN), using them anyway
W: DcmSpecificCharacterSet: Escape sequences shall not be used in the
first component group of a Person Name (PN), using them anyway
% dcmdump testU8.dcm | grep PatientName
(0010,0010) PN [テストです]#  16, 1 PatientName

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=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#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#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#1060704: transition: dcmtk

[Mathieu Malaterre]

On Sun, Jan 21, 2024 at 4:55 PM Sebastian Ramacher  wrote:
>
> Control: tags -1 moreinfo
>
> Hi Mathieu
>
> On 2024-01-13 11:47:40 +0100, Mathieu Malaterre wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> >
> > I'd like to migrate to dcmtk 3.6.8. This is a standard SONAME transition.
>
> Are the reverse dependencies known to build with the new dcmtk version?

I've integrated all changes from unstable back into the experimental package.

The debian-med team was kind enough to build the reverse dependencies
dependencies:

* https://lists.debian.org/debian-med/2024/06/msg3.html

Thanks!

Bug#1041234: libjpegli62 should provide libjpeg62-turbo (= 1:2.0.2)

[Mathieu Malaterre]

Jeremy,

On Wed, Jun 26, 2024 at 8:15 PM Jeremy Bícha  wrote:
> The patch provided doesn't make sense to me.
>
> The binary packages mentioned do not exist in Debian.
>
> jpeg-xl is now at version 0.9.2 in Debian so if upgrading to a new
> version was your only request, we can close this bug.

I am currently talking with jpegli team to understand the need for
convenient copy of libjpeg-turbo during built process. We'll see how
much has changed in the build process since, but I suspect the patch
does not apply anymore. Or does it ?

Thanks all,

Bug#1073537: transition: jpeg-xl

[Mathieu Malaterre]

On Wed, Jun 26, 2024 at 3:12 PM Emilio Pozuelo Monfort  wrote:
>
> On 26/06/2024 14:40, Jeremy Bícha wrote:
> > krita has been fixed by updating to a new version. I believe there are
> > no remaining blockers here.
>
> Thanks. You can go ahead then.

Uploaded to unstable a minute ago.

Thanks all !

Bug#1073537: transition: jpeg-xl

[Mathieu Malaterre]

Control: severity1073077 serious

On Thu, Jun 20, 2024 at 2:20 PM Jeremy Bícha  wrote:
>
> Control: block -1 by 1073077
>
> On Thu, Jun 20, 2024 at 4:10 AM Emilio Pozuelo Monfort  
> wrote:
> > On 20/06/2024 10:00, Mathieu Malaterre wrote:
> > > On Thu, Jun 20, 2024 at 9:40 AM Emilio Pozuelo Monfort  
> > > wrote:
> > >> Did you rebuild the rdeps against the new version?
> > >
> > > I personally did not, but through private communication @jbicha did so.
> >
> > And the results were successful? Would help if that information is posted 
> > on the
> > initial email. Assuming the test rebuilds went well, then you can go ahead.
>
> We successfully completed the jpeg-xl 0.9 transition in Ubuntu except
> for krita which I have added as a blocking bug here. Therefore, I
> believe we ought to fix krita before starting this transition in
> Debian.

Raising severity then.

Thanks !

Bug#1073537: transition: jpeg-xl

[Mathieu Malaterre]

On Thu, Jun 20, 2024 at 9:40 AM Emilio Pozuelo Monfort  wrote:
>
> Hi,
>
> On 17/06/2024 08:13, Mathieu Malaterre wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > X-Debbugs-Cc: jpeg...@packages.debian.org
> > Control: affects -1 + src:jpeg-xl
> >
> > As discussed previously I am filling a bug report for jpeg-xl 0.9
> > transition
>
> Did you rebuild the rdeps against the new version?

I personally did not, but through private communication @jbicha did so.

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: 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#1073537: transition: jpeg-xl

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: jpeg...@packages.debian.org
Control: affects -1 + src:jpeg-xl

As discussed previously I am filling a bug report for jpeg-xl 0.9
transition:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053866#79

Thanks

Ben file:

title = "jpeg-xl";
is_affected = .depends ~ "libjxl0.8" | .depends ~ "libjxl0.9";
is_good = .depends ~ "libjxl0.9";
is_bad = .depends ~ "libjxl0.8";

Bug#1053866: marked as done (transition: jpeg-xl)

[Mathieu Malaterre]

Emilio,

On Fri, May 31, 2024 at 12:40 PM Emilio Pozuelo Monfort
 wrote:
>
> Control: reopen -1
>
> On 31/05/2024 12:36, Debian Bug Tracking System wrote:
> >   jpeg-xl (0.8.2-4) unstable; urgency=medium
> >   .
> > * Upload 0.8.2-4 to unstable. Closes: #1053866
>
> Uploading to unstable doesn't close the transition bug. There are still things
> to do here, such as binNMUs, and ensuring things migrate to testing.

Sorry for the mess, thanks for the update.

Before doing another stupid thing, what should I do for the next
release transition. JPEG-XL ?  I am not clear if I should create
another bug report. 0.9.2 seems to be in good shape:

https://release.debian.org/britney/pseudo-excuses-experimental.html#jpeg-xl

But this may interfere with what I understand from:

https://release.debian.org/transitions/html/auto-jpeg-xl.html

The only blocker would be:

* https://bugs.debian.org/1073077

Thanks for guidance,

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#1055306: jpeg-xl: CVE-2023-35790

[Mathieu Malaterre]

Control: fixed -1 0.8.2-4

On Fri, Nov 3, 2023 at 8:27 PM Moritz Mühlenhoff  wrote:
> The following vulnerability was published for jpeg-xl.
>
> CVE-2023-35790[0]:

0.8.2-4 is in unstable now. Closing

Bug#1053866: transition: jpeg-xl

[Mathieu Malaterre]

On Sun, May 5, 2024 at 11:43 PM Jeremy Bícha  wrote:
>
> Control: block -1 by 1061627
>
> I was able to build all the reverse dependencies in Ubuntu 24.04 LTS
> against jpeg-xl from experimental. But jpeg-xl won't be able to
> migrate to Testing until its autopkgtests are fixed.
>
> https://release.debian.org/britney/pseudo-excuses-experimental.html#jpeg-xl

Finally fixed today. Sorry for the delay.

Bug#1060704: transition: dcmtk

[Mathieu Malaterre]

Jeremy,

On Wed, Jan 31, 2024 at 10:04 AM Mathieu Malaterre  wrote:
>
> Sebastian,
>
> On Sun, Jan 21, 2024 at 4:55 PM Sebastian Ramacher  
> wrote:
> >
> > Control: tags -1 moreinfo
> >
> > Hi Mathieu
> >
> > On 2024-01-13 11:47:40 +0100, Mathieu Malaterre wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: transition
> > >
> > > I'd like to migrate to dcmtk 3.6.8. This is a standard SONAME transition.
> >
> > Are the reverse dependencies known to build with the new dcmtk version?
>
> I still do not have access to debomatic-amd64. So I have not tested them yet.

I still do not have access to debomatic-amd64. Would you like to check
the reverse dependencies of dcmtk 3.6.8-3 for the transition to start
?

Thank you

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#1060704: transition: dcmtk

[Mathieu Malaterre]

Sebastian,

On Sun, Jan 21, 2024 at 4:55 PM Sebastian Ramacher  wrote:
>
> Control: tags -1 moreinfo
>
> Hi Mathieu
>
> On 2024-01-13 11:47:40 +0100, Mathieu Malaterre wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> >
> > I'd like to migrate to dcmtk 3.6.8. This is a standard SONAME transition.
>
> Are the reverse dependencies known to build with the new dcmtk version?

I still do not have access to debomatic-amd64. So I have not tested them yet.

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#1053866: transition: jpeg-xl

[Mathieu Malaterre]

On Tue, Oct 17, 2023 at 6:04 PM Sebastian Ramacher  wrote:
>
> Hi Mathieu
>
> On 2023-10-13 16:42:34 +0200, Mathieu Malaterre wrote:
> > On Fri, Oct 13, 2023 at 11:57 AM Sebastian Ramacher
> >  wrote:
> > >
> > > Control: tags -1 moreinfo
> > > Control: forwarded -1 
> > > https://release.debian.org/transitions/html/auto-jpeg-xl.html
> > >
> > > On 2023-10-13 10:44:31 +0200, Mathieu Malaterre wrote:
> > > > Package: release.debian.org
> > > > Severity: normal
> > > > User: release.debian@packages.debian.org
> > > > Usertags: transition
> > > >
> > > > This is a minor SONAME transiton. Two (unused anywhere) symbols were
> > > > removed.
> > >
> > > Are the reverse dependencies known to build with the new version?
> >
> > Nope. I've requested an account on debomatic-amd64 to run the following:
> >
> > % cat jxl.commands
> > rebuild ffmpeg_7:6.0-7 unstable experimental
> > rebuild geeqie_1:2.1-1 unstable experimental
> > rebuild gimp_2.10.34-1 unstable experimental
> > rebuild graphicsmagick_1.4+really1.3.42-1 unstable experimental
> > rebuild imlib2_1.12.1-1 unstable experimental
> > rebuild kimageformats_5.107.0-3 unstable experimental
> > rebuild krita_1:5.2.0+dfsg-1 unstable experimental
> > rebuild swayimg_1.12-1 unstable experimental
> > rebuild vips_8.14.5-1 unstable experimental
> > rebuild webkit2gtk_2.42.1-2 unstable experimental
> > rebuild wpewebkit_2.42.1-1 unstable experimental
> >
> >
> > will post back when I get access.
>
> Alright, thanks. Please let us know as soon as you have the results.

Turns out, I cannot connect to debomatic-amd64 online service. Is
there an alternate solution for me to rebuild a large set of packages
automatically ?

Thanks!

Bug#1060704: transition: dcmtk

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

I'd like to migrate to dcmtk 3.6.8. This is a standard SONAME transition.

Current status in exp:
https://buildd.debian.org/status/package.php?p=dcmtk=experimental

Thanks

Bug#1060677: Acknowledgement (Rounding error in OFStandard::atof)

[Mathieu Malaterre]

forwarded -1 https://support.dcmtk.org/redmine/issues/1100

Bug#1060677: Rounding error in OFStandard::atof

[Mathieu Malaterre]

Source: dcmtk
Version: 3.6.7-8+b1

I believe I found an edge case in OFStandard::atof logic. Consider the
following ASCII string float > 16 bytes (valid case for input such as
XML or JSON).

Here is what I see on my side Debian/stable (dcmtk 3.6.7):

$ ./fd
0x1.dp+3
0x1.cp+3

This has an impact when using DcmFloatingPointDouble::putString (VR:FD).

Thanks !

ref code is

% cat ../fd.cxx
#include "dcmtk/dcmdata/dcfilefo.h"

int main() {
  const uint8_t bytes[] = {0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0x2C, 0x40};
  std::string result;
  result = "14.399";
  OFBool success;
  double d2 = OFStandard::atof(result.c_str(), );
  std::cout << std::hexfloat << d2 << std::endl;
  double d3 = std::stod(result);
  std::cout << std::hexfloat << d3 << std::endl;

  return 0;
}

Bug#1060442: DCMTK Release 3.6.8 available

[Mathieu Malaterre]

Source: dcmtk

Dear DCMTK Package Maintainer,

we noticed that you are one the package maintainers helping to
distribute a DCMTK package for
some Linux distribution, BSD unix or other package management system.

We want to inform you that there is a a new DCMTK release 3.6.8 available.
You can download it here:

   https://dicom.offis.de/download/dcmtk/dcmtk368/dcmtk-3.6.8.tar.gz

or via git repos:

   https://git.dcmtk.org/ (Upstream)
   https://github.com/DCMTK/dcmtk/ (Github mirror)


With best regards,
Dr. Marco Eichelberg

Bug#1056048: Acknowledgement (Memory leak in dcm2json)

[Mathieu Malaterre]

As pointed out by upstream, one must export the following:


You should set the environment variable ICONV_MAX_REUSE to zero
before running such tests:

   export ICONV_MAX_REUSE=0
   valgrind  --leak-check=full ...


Which gives now the reduced set of leaks:

% valgrind  --leak-check=full --show-leak-kinds=all dcm2json
charsettests/SCSARAB  output.json
==1928491== Memcheck, a memory error detector
==1928491== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1928491== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==1928491== Command: dcm2json charsettests/SCSARAB output.json
==1928491==
==1928491==
==1928491== HEAP SUMMARY:
==1928491== in use at exit: 842 bytes in 2 blocks
==1928491==   total heap usage: 80,067 allocs, 80,065 frees, 2,124,652
bytes allocated
==1928491==
==1928491== 26 bytes in 1 blocks are still reachable in loss record 1 of 2
==1928491==at 0x48407B4: malloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1928491==by 0x4E037F9: strdup (strdup.c:42)
==1928491==by 0x4F5C7F1: UnknownInlinedFun (citrus_mapper.c:119)
==1928491==by 0x4F5C7F1: _citrus_csmapper_open.constprop.0
(citrus_csmapper.c:388)
==1928491==by 0x4F55B54: UnknownInlinedFun (citrus_iconv_std.c:186)
==1928491==by 0x4F55B54: UnknownInlinedFun (citrus_iconv_std.c:225)
==1928491==by 0x4F55B54: UnknownInlinedFun (citrus_iconv_std.c:283)
==1928491==by 0x4F55B54: _citrus_iconv_std_iconv_init_shared
(citrus_iconv_std.c:382)
==1928491==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:201)
==1928491==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:265)
==1928491==by 0x4F56B83: _citrus_iconv_open (citrus_iconv.c:349)
==1928491==by 0x4F59117: _iconv_open (oficonv_iconv.c:107)
==1928491==by 0x4AE71E2: UnknownInlinedFun (ofchrenc.cc:337)
==1928491==by 0x4AE71E2:
OFCharacterEncoding::selectEncoding(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&) (ofchrenc.cc:785)
==1928491==by 0x49B5F63:
DcmSpecificCharacterSet::selectCharacterSetWithoutCodeExtensions()
(dcspchrs.cc:338)
==1928491==by 0x49B6797:
DcmSpecificCharacterSet::selectCharacterSet(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&) (dcspchrs.cc:189)
==1928491==by 0x498F5A6:
DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&, unsigned long, bool) (dcitem.cc:4403)
==1928491==by 0x498CB96:
DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&, unsigned long,
bool) (dcitem.cc:4442)
==1928491==by 0x498A83C: DcmItem::convertToUTF8() (dcitem.cc:4465)
==1928491==
==1928491== 816 bytes in 1 blocks are still reachable in loss record 2 of 2
==1928491==at 0x48407B4: malloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1928491==by 0x4F5C7DD: UnknownInlinedFun (citrus_mapper.c:114)
==1928491==by 0x4F5C7DD: _citrus_csmapper_open.constprop.0
(citrus_csmapper.c:388)
==1928491==by 0x4F55B54: UnknownInlinedFun (citrus_iconv_std.c:186)
==1928491==by 0x4F55B54: UnknownInlinedFun (citrus_iconv_std.c:225)
==1928491==by 0x4F55B54: UnknownInlinedFun (citrus_iconv_std.c:283)
==1928491==by 0x4F55B54: _citrus_iconv_std_iconv_init_shared
(citrus_iconv_std.c:382)
==1928491==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:201)
==1928491==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:265)
==1928491==by 0x4F56B83: _citrus_iconv_open (citrus_iconv.c:349)
==1928491==by 0x4F59117: _iconv_open (oficonv_iconv.c:107)
==1928491==by 0x4AE71E2: UnknownInlinedFun (ofchrenc.cc:337)
==1928491==by 0x4AE71E2:
OFCharacterEncoding::selectEncoding(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&) (ofchrenc.cc:785)
==1928491==by 0x49B5F63:
DcmSpecificCharacterSet::selectCharacterSetWithoutCodeExtensions()
(dcspchrs.cc:338)
==1928491==by 0x49B6797:
DcmSpecificCharacterSet::selectCharacterSet(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&) (dcspchrs.cc:189)
==1928491==by 0x498F5A6:
DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&, unsigned long, bool) (dcitem.cc:4403)
==1928491==by 0x498CB96:
DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&, unsigned long,
bool) (dcitem.cc:4442)
==1928491==by 0x498A83C: DcmItem::convertToUTF8() (dcitem.cc:4465)
==1928491==by 0x10C7D3: main (dcm2json.cc:281)
==1928491==
==1928491== LEAK SUMMARY:
==1928491==definitely lost: 0 bytes in 0 blocks
==1928491==indirectly lost: 0 bytes in 0 blocks
==1928491==  possibly lost: 0 bytes in 0 blocks
==1928491==still reachable: 842 bytes in 2 blocks
==1928491== suppressed: 0 

Bug#1056302: FreeBSD/iconv: ISO 2022 IR 13\ISO 2022 IR 87

[Mathieu Malaterre]

Source: dcmtk
Version: 3.6.8~git20231027.1549d8c-2

Somewhat related to #988644.

Steps:

% curl -O https://dclunie.com/images/charset/charsettests.20070405.tar.bz2
% tar xf charsettests.20070405.tar.bz2
% cp charsettests/SCSH32 new.dcm
% dcmodify -i "0018,1020=123\456" new.dcm

Gives

 % dcmdump +U8 new.dcm | grep "0018,1020\|0010,0010"
(0010,0010) PN [ﾔﾏﾀﾞ^ﾀﾛｳ=山田^太郎=やまだ^たろう] #  56, 1 PatientName
(0018,1020) LO [123¥456]   #   8, 1 SoftwareVersions

It has been confirmed by upstream that this is a bug. Patch is under review.

Bug#1056048: Memory leak in dcm2json

[Mathieu Malaterre]

Source: dcmtk
Version: 3.6.8~git20231027.1549d8c-2

Looks like there is a memory leak using the new citrus/oficonv lib:

curl -O https://dclunie.com/images/charset/charsettests.20070405.tar.bz2
tar xf charsettests.20070405.tar.bz2
valgrind  --leak-check=full --show-leak-kinds=all dcm2json
charsettests/SCSARAB  output.json

I cannot reproduce the symptoms using default glibc/iconv (dcmtk 3.6.7-9).

Reports:

==1688197== Memcheck, a memory error detector
==1688197== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1688197== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==1688197== Command: dcm2json charsettests/SCSARAB output.json
==1688197==
==1688197==
==1688197== HEAP SUMMARY:
==1688197== in use at exit: 1,562 bytes in 18 blocks
==1688197==   total heap usage: 80,067 allocs, 80,049 frees, 2,124,652
bytes allocated
==1688197==
==1688197== 8 bytes in 1 blocks are still reachable in loss record 1 of 18
==1688197==at 0x48455EF: calloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1688197==by 0x4F594EA: _citrus_UTF8_stdenc_init
(citrus_stdenc_template.h:84)
==1688197==by 0x4F4E301: _citrus_stdenc_open (citrus_stdenc.c:118)
==1688197==by 0x4F55A69: _citrus_iconv_std_iconv_init_shared
(citrus_iconv_std.c:374)
==1688197==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:201)
==1688197==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:265)
==1688197==by 0x4F56B83: _citrus_iconv_open (citrus_iconv.c:349)
==1688197==by 0x4F59117: _iconv_open (oficonv_iconv.c:107)
==1688197==by 0x4AE71E2: UnknownInlinedFun (ofchrenc.cc:337)
==1688197==by 0x4AE71E2:
OFCharacterEncoding::selectEncoding(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&) (ofchrenc.cc:785)
==1688197==by 0x49B5F63:
DcmSpecificCharacterSet::selectCharacterSetWithoutCodeExtensions()
(dcspchrs.cc:338)
==1688197==by 0x49B6797:
DcmSpecificCharacterSet::selectCharacterSet(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&) (dcspchrs.cc:189)
==1688197==by 0x498F5A6:
DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&, unsigned long, bool) (dcitem.cc:4403)
==1688197==by 0x498CB96:
DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&, unsigned long,
bool) (dcitem.cc:4442)
==1688197==by 0x498A83C: DcmItem::convertToUTF8() (dcitem.cc:4465)
==1688197==
==1688197== 15 bytes in 1 blocks are still reachable in loss record 2 of 18
==1688197==at 0x48407B4: malloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1688197==by 0x4E037F9: strdup (strdup.c:42)
==1688197==by 0x4F56F9F: _citrus_mapper_open (citrus_mapper.c:370)
==1688197==by 0x4F5C6F1: _citrus_csmapper_open.constprop.0
(citrus_csmapper.c:411)
==1688197==by 0x4F55B54: UnknownInlinedFun (citrus_iconv_std.c:186)
==1688197==by 0x4F55B54: UnknownInlinedFun (citrus_iconv_std.c:225)
==1688197==by 0x4F55B54: UnknownInlinedFun (citrus_iconv_std.c:283)
==1688197==by 0x4F55B54: _citrus_iconv_std_iconv_init_shared
(citrus_iconv_std.c:382)
==1688197==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:201)
==1688197==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:265)
==1688197==by 0x4F56B83: _citrus_iconv_open (citrus_iconv.c:349)
==1688197==by 0x4F59117: _iconv_open (oficonv_iconv.c:107)
==1688197==by 0x4AE71E2: UnknownInlinedFun (ofchrenc.cc:337)
==1688197==by 0x4AE71E2:
OFCharacterEncoding::selectEncoding(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&) (ofchrenc.cc:785)
==1688197==by 0x49B5F63:
DcmSpecificCharacterSet::selectCharacterSetWithoutCodeExtensions()
(dcspchrs.cc:338)
==1688197==by 0x49B6797:
DcmSpecificCharacterSet::selectCharacterSet(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&) (dcspchrs.cc:189)
==1688197==by 0x498F5A6:
DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&, unsigned long, bool) (dcitem.cc:4403)
==1688197==by 0x498CB96:
DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&, unsigned long,
bool) (dcitem.cc:4442)
==1688197==
==1688197== 24 bytes in 1 blocks are still reachable in loss record 3 of 18
==1688197==at 0x48407B4: malloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1688197==by 0x4F4E2EA: _citrus_stdenc_open (citrus_stdenc.c:112)
==1688197==by 0x4F55A69: _citrus_iconv_std_iconv_init_shared
(citrus_iconv_std.c:374)
==1688197==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:201)
==1688197==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:265)
==1688197==by 0x4F56B83: _citrus_iconv_open (citrus_iconv.c:349)
==1688197== 

Bug#1055873: Acknowledgement (dcm2json is missing --convert-un for CP-1066 EVRLE)

[Mathieu Malaterre]

Current work-around:

% dcmconv +ti RTStruct_VRDSAsVRUN.dcm - | dcm2json - output.json

Bug#1055872: Acknowledgement (CP-2275: "NaN", "+Infinity" and "-Infinity")

[Mathieu Malaterre]

Control: forwarded -1 https://support.dcmtk.org/redmine/issues/1086

Confirmed by upstream.

On Mon, Nov 13, 2023 at 11:51 AM Debian Bug Tracking System
 wrote:
>
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 1055872: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055872.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Med Packaging Team 
>
> If you wish to submit further information on this problem, please
> send it to 1055...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 1055872: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055872
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#1055873: dcm2json is missing --convert-un for CP-1066 EVRLE

[Mathieu Malaterre]

Source: dcmtk
Version: 3.6.7-9

In some cases, DICOM enforces the serialization of VR:UN instead of
the actual correct Value Representation.

dcm2json does not permit on the fly conversion to correct VR and hence
generates VR:UN with InlineBinary.

Bug#1055872: CP-2275: "NaN", "+Infinity" and "-Infinity"

[Mathieu Malaterre]

Source: dcmtk
Version: 3.6.7-9

DICOM standard is about to clarify support for "NaN", "+Infinity" and
"-Infinity" in DICOM/JSON.

Currently dcm2json does not support it. It has been discussed with upstream.

Bug#1055490: Subscription to 1055...@bugs.debian.org successful

[Mathieu Malaterre]

Control: fixed -1 3.6-25
Control: tags -1 wontfix

PEBKAC

% echo -n 'ＡＢＣ' > t.txt
% recode -v UTF-8..JIS_X0208 t.txt
Request: UTF-8..:libiconv:..JIS_X0208
Shrunk to: UTF-8..JIS_X0208
Recoding t.txt... done
% recode -v JIS_X0208..UTF-8 t.txt
Request: JIS_X0208..:libiconv:..UTF-8
Shrunk to: JIS_X0208..UTF-8
Recoding t.txt... done

Bug#1055490: Acknowledgement (ISO-IR-87 encoding seems to be broken)

[Mathieu Malaterre]

For ref:

 % recode -l | grep IR-87
JIS_X0208 csISO87JISX0208 ISO-IR-87 JIS0208 JISX0208.1983-0
JISX0208.1990-0 JIS_X0208-1983 JIS_X0208-1990 X0208

Bug#1055490: ISO-IR-87 encoding seems to be broken

[Mathieu Malaterre]

Package: recode
Version: 3.6-25

For some reason I cannot get ISO-IR-87 to work on my Debian/stable system:

% echo 'foobar' > t.txt
% recode -v UTF-8..ISO-IR-87 t.txt
Request: UTF-8..:libiconv:..JIS_X0208
Shrunk to: UTF-8..JIS_X0208
Recoding t.txt... failed: Invalid input in step `UTF-8..JIS_X0208'


ref:

% apt-cache policy recode
recode:
  Installed: 3.6-25
  Candidate: 3.6-25
  Version table:
 *** 3.6-25 500
500 http://deb.debian.org/debian bookworm/main amd64 Packages
100 /var/lib/dpkg/status

Bug#409283: recode: man page author name does not seams well coded.

[Mathieu Malaterre]

> In man page author name is
>  Franc,ois
> when, in an UTF-8 system (default in etch), it should be
>  François

Quite funny when you realize that `recode` is exactly about encoding :)

Bug#1055276: Acknowledgement (Valgrind does not read properly DWARF5 as generated by Clang14)

[Mathieu Malaterre]

Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=452758
Control: tags -1 upstream fixed-upstream
Control: affects -1 clang-16

Seems to be fixed in 3.20

Bug#1055276: Valgrind does not read properly DWARF5 as generated by Clang14

[Mathieu Malaterre]

Source: valgrind
Version: 1:3.19.0-1

valgrind does not handle clang 14 and up.

% valgrind ./works2
==171243== Memcheck, a memory error detector
==171243== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==171243== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==171243== Command: ./works2
==171243==
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x23
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x1b
==171243== Valgrind: debuginfo reader: ensure_valid failed:
==171243== Valgrind:   during call to ML_(img_get)
==171243== Valgrind:   request for range [450185478, +4) exceeds
==171243== Valgrind:   valid image size of 554564 for image:
==171243== Valgrind:   "/home/mathieu/Perso/gcc-110622/pr111231/works2"
==171243==
==171243== Valgrind: debuginfo reader: Possibly corrupted debuginfo file.
==171243== Valgrind: I can't recover.  Giving up.  Sorry.
==171243==

Bug#1054149: manpages-dev: Bizarre rendering of pointers (restrict .n)

[Mathieu Malaterre]

Package: manpages-dev
Version: 6.03-2
Severity: normal

Dear Maintainer,

Consider the following: `man 3 memcpy`

You'll be presented with the following signature:

<...>
SYNOPSIS
   #include 

   void *memcpy(void dest[restrict .n], const void src[restrict .n],
size_t n);
<...>

I find it quite difficult to read the `restrict .n` is actually a
pointer. Could you please revert to the previous rendering mechanism ?

Thanks

-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-13-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages manpages-dev depends on:
ii  manpages  6.03-2

manpages-dev recommends no packages.

Versions of packages manpages-dev suggests:
ii  man-db [man-browser]  2.11.2-2

-- no debconf information

Bug#1053866: transition: jpeg-xl

[Mathieu Malaterre]

On Fri, Oct 13, 2023 at 11:57 AM Sebastian Ramacher
 wrote:
>
> Control: tags -1 moreinfo
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-jpeg-xl.html
>
> On 2023-10-13 10:44:31 +0200, Mathieu Malaterre wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> >
> > This is a minor SONAME transiton. Two (unused anywhere) symbols were
> > removed.
>
> Are the reverse dependencies known to build with the new version?

Nope. I've requested an account on debomatic-amd64 to run the following:

% cat jxl.commands
rebuild ffmpeg_7:6.0-7 unstable experimental
rebuild geeqie_1:2.1-1 unstable experimental
rebuild gimp_2.10.34-1 unstable experimental
rebuild graphicsmagick_1.4+really1.3.42-1 unstable experimental
rebuild imlib2_1.12.1-1 unstable experimental
rebuild kimageformats_5.107.0-3 unstable experimental
rebuild krita_1:5.2.0+dfsg-1 unstable experimental
rebuild swayimg_1.12-1 unstable experimental
rebuild vips_8.14.5-1 unstable experimental
rebuild webkit2gtk_2.42.1-2 unstable experimental
rebuild wpewebkit_2.42.1-1 unstable experimental


will post back when I get access.

Thanks !

Bug#1053866: transition: jpeg-xl

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

This is a minor SONAME transiton. Two (unused anywhere) symbols were
removed.

Current status in exp:
https://buildd.debian.org/status/package.php?p=jpeg-xl=experimental

Thanks

Ben file:

title = "jpeg-xl";
is_affected = .depends ~ "libjxl0.7" | .depends ~ "libjxl0.8";
is_good = .depends ~ "libjxl0.8";
is_bad = .depends ~ "libjxl0.7";

Bug#1051905: jpeg-xl: Please add support for Loongarch

[Mathieu Malaterre]

Control: fixed -1 0.7.0-10.2

I see that it builds fine on loong64:

https://buildd.debian.org/status/fetch.php?pkg=jpeg-xl=loong64=0.7.0-10.2=1696728916=0

Closing.

Thanks

Bug#1053753: libpng1.6 shlibs contains debian revision

[Mathieu Malaterre]

Source: libpng1.6
Version: 1.6.40-1

Just like symbols file
(symbols-file-contains-current-version-with-debian-revision), shlibs
should not contain debian revision, please remove it.

For reference:

 % cat libpng16-16.shlibs
libpng16 16 libpng16-16 (>= 1.6.2-1)
udeb: libpng16 16 libpng16-16-udeb (>= 1.6.2-1)

Thanks

Bug#1053641: transition: libavif

[Mathieu Malaterre]

Hi,


On Sat, Oct 7, 2023 at 9:36 PM Boyuan Yang  wrote:
>
> X-Debbugs-CC: ma...@debian.org
>
> 在 2023-10-07星期六的 20:32 +0200，Sebastian Ramacher写道：
> > Control: tags -1 confirmed
> >
> > On 2023-10-07 14:06:44 -0400, Boyuan Yang wrote:
> > > I am looking at starting the transition for package libavif,
> > > which comes with a SONAME bump
> > > (libavif15, v0.11.1-3 (sid) -> libavif16, v1.0.1-1 (exp)).
> > >
> > > * jpeg-xl (Current version FTBFS unconditionally due to a different reason
> > > in Testing/Sid; my NMU fix just accepted in Sid)
> > >
> > > Do we need to wait till my NMU-ed jpeg-xl to migrate to Testing before
> > > starting the libavif transition?
> >
> > No, that's not necessary. Please go ahead.
>
> Alright, here comes the tricky part.
>
> In the test build of reverse build-dependencies, only amd64 builds are 
> examined.
> Now, the rebuilt jpeg-xl has some new FTBFS on other architectures; and while 
> some
> issues are easy to solve (e.g., missing  header for arm64), some 
> issues are
> not (like the new test failures for i386 and s390x) [1].
>
> Probably I uploaded the libavif/1.0.1-1 to Sid too soon; and while I tried to 
> cancel
> the upload with "dcut rm" and "dcut cancel", these commands never successfully
> intercept the upload ("no such upload found", "no file to delete", etc), and 
> we are
> having the new libavif in Sid now to trigger the transition. This is the worst
> condition we could have, though I consciously tried to avoid it :-(
>
> I am now wondering what would be the best way to get this transition done in 
> a sane
> way. A few choices in my mind:
>
> (1) Make a sloppy upload to jpeg-xl in Sid to ignore post-build testing 
> errors (and
> possibly newly-emerged autopkgtest errors, if any?) so that the libavif 
> transition can
> finish, and count on the upcoming jpeg-xl (0.7 -> 0.8) transition to correct 
> these
> ignored errors;
>
> (2) Fix current jpeg-xl in Sid properly. That won't be too trivial since the 
> new
> testing error is likely triggered by some unclear changes in 
> build-dependencies over
> the past several months.
>
> (3) Wait till a sane jpeg-xl 0.8 upload (with transition) is ready, and 
> entangle
> jpeg-xl transition with libavif transition.

#1051131 has been fixed yesterday. I'll go ahead and do the 0.8 upload
this week.

Thanks,

> It would be great if you have any suggestion, or even better, some good 
> patches
> on it.
>
> Thanks,
> Boyuan Yang
>
>
> [1] https://buildd.debian.org/status/package.php?p=jpeg-xl

Bug#1050933:

[Mathieu Malaterre]

Control: tags -1 wontfix

GCC-13 works as expected. Turns out to be a UB case in highway source code.

Closing

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#1051384: bookworm-pu: package highway/1.0.3-3

[Mathieu Malaterre]

On Thu, Sep 7, 2023 at 1:23 PM Adam D. Barratt  wrote:
>
> Control: tags -1 + moreinfo
>
> On Thu, 2023-09-07 at 09:11 +0200, Mathieu Malaterre wrote:
> > I'd like to fix highway on armhf (neon-less) system.
> >
> > [ Reason ]
> > See #1033656
> >
>
> +highway (1.0.3-3+deb11u1) bullseye; urgency=medium
>
> Neither the version suffix nor the suite there match up with the
> subject.

I managed to mess up a simple upload...oh well.

Here is the correct debdiff this time.

Thanks


debdiff-bookworkm
Description: Binary data

Bug#1033656: closed by Debian FTP Masters (reply to Mathieu Malaterre ) (Bug#1033656: fixed in highway 1.0.7-1)

[Mathieu Malaterre]

On Thu, Sep 21, 2023 at 12:09 PM Uwe Kleine-König
 wrote:
>
> Hello,
>
> On Thu, Aug 31, 2023 at 10:39:05AM +, Debian Bug Tracking System wrote:
> > This is an automatic notification regarding your Bug report
> > which was filed against the src:highway package:
> >
> > #1033656: illegal hardware instruction cjxl
> >
> > It has been closed by Debian FTP Masters  
> > (reply to Mathieu Malaterre ).
> >
> > Their explanation is attached below along with your original report.
> > If this explanation is unsatisfactory and you have not received a
> > better one in a separate message then please contact Debian FTP Masters 
> >  (reply to Mathieu Malaterre 
> > ) by
> > replying to this email.
>
> Given this affects stable and breaks other packages (at least
> libjxl-tools, minidlna, but I guess all (transitive) rdepends of
> libhwy1), I wonder if this should be fixed for stable, too?!

Thanks for the reminder. I did prepare a stable fix, but messed up.
I'll work on it (again) asap.

Bug#1052141: Simplified

[Mathieu Malaterre]

Steps:

% clang++-16  -o fails math_test4.cc  -lhwy_contrib
% cat math_test4.cc
int main() {}
% clang++-16  -o fails math_test4.cc  -lhwy_contrib
% valgrind ./fails
==3733364== Memcheck, a memory error detector
==3733364== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==3733364== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==3733364== Command: ./fails
==3733364==
--3733364-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x92

valgrind: m_debuginfo/readdwarf.c:2761 (copy_convert_CfiExpr_tree):
Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.

host stacktrace:
==3733364==at 0x58040D44: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364==by 0x58040E93: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364==by 0x58040FFB: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364==by 0x580C3BB7: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364==by 0x580C3D53: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364==by 0x580C91E3: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364==by 0x5807A497: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364==by 0x5806F613: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364==by 0x5809E927: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364==by 0x580AB983: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364==by 0x5809AA1B: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364==by 0x5809647F: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364==by 0x5809882F: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364==by 0x580DFC5F: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3733364==by 0x: ???

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable syscall 222 (lwpid 3733364)
==3733364==at 0x401AB6C: __mmap64 (mmap64.c:58)
==3733364==by 0x401AB6C: mmap (mmap64.c:46)
==3733364==by 0x40066F3: _dl_map_segments (dl-map-segments.h:139)
==3733364==by 0x40066F3: _dl_map_object_from_fd (dl-load.c:1268)
==3733364==by 0x40078BF: _dl_map_object (dl-load.c:2272)
==3733364==by 0x400243B: openaux (dl-deps.c:64)
==3733364==by 0x40012FB: _dl_catch_exception (dl-catch.c:237)
==3733364==by 0x40028EB: _dl_map_object_deps (dl-deps.c:232)
==3733364==by 0x4017A47: dl_main (rtld.c:1972)
==3733364==by 0x4014E8B: _dl_sysdep_start (dl-sysdep.c:140)
==3733364==by 0x4016273: _dl_start_final (rtld.c:497)
==3733364==by 0x4016273: _dl_start (rtld.c:584)
==3733364==by 0x401A193: (below main) (dl-start.S:30)
client stack range: [0x1FFEFFE000 0x1FFF000FFF] client SP: 0x1FFEFFF150
valgrind stack range: [0x1002CB8000 0x1002DB7FFF] top usage: 17968 of 1048576


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.

Bug#1052141: Acknowledgement (valgrind: m_debuginfo/readdwarf.c:2761 (copy_convert_CfiExpr_tree): Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.)

[Mathieu Malaterre]

Reproducer

% clang++-16 -std=c++17 -Wfatal-errors -Wall -Wextra -Werror -O1 -o
fails 
'-DHWY_DISABLED_TARGETS=(HWY_NEON|HWY_SVE|HWY_SVE2|HWY_SVE_256|HWY_SVE2_128)'
math_test4.cc -lhwy -lhwy_contrib -lhwy_test
% valgrind ./fails
// Copyright 2020 Google LLC
// SPDX-License-Identifier: Apache-2.0
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//  http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

#ifndef HIGHWAY_HWY_ALIGNED_ALLOCATOR_H_
#define HIGHWAY_HWY_ALIGNED_ALLOCATOR_H_

// Memory allocator with support for alignment and offsets.

#include 
#include 

#include "hwy/base.h"

namespace hwy {

// Minimum alignment of allocated memory for use in HWY_ASSUME_ALIGNED, which
// requires a literal. This matches typical L1 cache line sizes, which prevents
// false sharing.
#define HWY_ALIGNMENT 64

// Pointers to functions equivalent to malloc/free with an opaque void* passed
// to them.
using AllocPtr = void* (*)(void* opaque, size_t bytes);
using FreePtr = void (*)(void* opaque, void* memory);

// Returns null or a pointer to at least `payload_size` (which can be zero)
// bytes of newly allocated memory, aligned to the larger of HWY_ALIGNMENT and
// the vector size. Calls `alloc` with the passed `opaque` pointer to obtain
// memory or malloc() if it is null.
HWY_DLLEXPORT void* AllocateAlignedBytes(size_t payload_size,
 AllocPtr alloc_ptr, void* opaque_ptr);

// Frees all memory. No effect if `aligned_pointer` == nullptr, otherwise it
// must have been returned from a previous call to `AllocateAlignedBytes`.
// Calls `free_ptr` with the passed `opaque_ptr` pointer to free the memory; if
// `free_ptr` function is null, uses the default free().
HWY_DLLEXPORT void FreeAlignedBytes(const void* aligned_pointer,
FreePtr free_ptr, void* opaque_ptr);

// Class that deletes the aligned pointer passed to operator() calling the
// destructor before freeing the pointer. This is equivalent to the
// std::default_delete but for aligned objects. For a similar deleter equivalent
// to free() for aligned memory see AlignedFreer().
class AlignedDeleter {
 public:
  AlignedDeleter() : free_(nullptr), opaque_ptr_(nullptr) {}
  AlignedDeleter(FreePtr free_ptr, void* opaque_ptr)
  : free_(free_ptr), opaque_ptr_(opaque_ptr) {}

  template 
  void operator()(T* aligned_pointer) const {
return DeleteAlignedArray(aligned_pointer, free_, opaque_ptr_,
  TypedArrayDeleter);
  }

 private:
  template 
  static void TypedArrayDeleter(void* ptr, size_t size_in_bytes) {
size_t elems = size_in_bytes / sizeof(T);
for (size_t i = 0; i < elems; i++) {
  // Explicitly call the destructor on each element.
  (static_cast(ptr) + i)->~T();
}
  }

  // Function prototype that calls the destructor for each element in a typed
  // array. TypeArrayDeleter would match this prototype.
  using ArrayDeleter = void (*)(void* t_ptr, size_t t_size);

  HWY_DLLEXPORT static void DeleteAlignedArray(void* aligned_pointer,
   FreePtr free_ptr,
   void* opaque_ptr,
   ArrayDeleter deleter);

  FreePtr free_;
  void* opaque_ptr_;
};

// Unique pointer to T with custom aligned deleter. This can be a single
// element U or an array of element if T is a U[]. The custom aligned deleter
// will call the destructor on U or each element of a U[] in the array case.
template 
using AlignedUniquePtr = std::unique_ptr;

// Aligned memory equivalent of make_unique using the custom allocators
// alloc/free with the passed `opaque` pointer. This function calls the
// constructor with the passed Args... and calls the destructor of the object
// when the AlignedUniquePtr is destroyed.
template 
AlignedUniquePtr MakeUniqueAlignedWithAlloc(AllocPtr alloc, FreePtr free,
   void* opaque, Args&&... args) {
  T* ptr = static_cast(AllocateAlignedBytes(sizeof(T), alloc, opaque));
  return AlignedUniquePtr(new (ptr) T(std::forward(args)...),
 AlignedDeleter(free, opaque));
}

// Similar to MakeUniqueAlignedWithAlloc but using the default alloc/free
// functions.
template 
AlignedUniquePtr MakeUniqueAligned(Args&&... args) {
  T* ptr = static_cast(AllocateAlignedBytes(
  sizeof(T), /*alloc_ptr=*/nullptr, /*opaque_ptr=*/nullptr));
  return AlignedUniquePtr(new (ptr) T(std::forward(args)...),
  

Bug#1052141: valgrind: m_debuginfo/readdwarf.c:2761 (copy_convert_CfiExpr_tree): Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.

[Mathieu Malaterre]

Source: valgrind
Version: 1:3.19.0-1

On amdhal.d.o:

% valgrind ./fails
==3527834== Memcheck, a memory error detector
==3527834== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==3527834== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==3527834== Command: ./fails
==3527834==
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x23
get_Form_szB: unhandled 35 (DW_FORM_rnglistx)
--3527834-- WARNING: Serious error when reading debug info
--3527834-- When reading debug info from /home/malat/pr110643/fails:
--3527834-- get_Form_contents: unhandled DW_FORM
--3527834-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x92

valgrind: m_debuginfo/readdwarf.c:2761 (copy_convert_CfiExpr_tree):
Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.

host stacktrace:
==3527834==at 0x58040D44: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x58040E93: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x58040FFB: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x580C3BB7: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x580C3D53: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x580C91E3: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x5807A497: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x5806F613: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x5809E927: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x580AB983: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x5809AA1B: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x5809647F: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x5809882F: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x580DFC5F: ??? (in
/usr/libexec/valgrind/memcheck-arm64-linux)
==3527834==by 0x: ???

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable syscall 222 (lwpid 3527834)
==3527834==at 0x401AB6C: __mmap64 (mmap64.c:58)
==3527834==by 0x401AB6C: mmap (mmap64.c:46)
==3527834==by 0x40066F3: _dl_map_segments (dl-map-segments.h:139)
==3527834==by 0x40066F3: _dl_map_object_from_fd (dl-load.c:1268)
==3527834==by 0x40078BF: _dl_map_object (dl-load.c:2272)
==3527834==by 0x400243B: openaux (dl-deps.c:64)
==3527834==by 0x40012FB: _dl_catch_exception (dl-catch.c:237)
==3527834==by 0x40028EB: _dl_map_object_deps (dl-deps.c:232)
==3527834==by 0x4017A47: dl_main (rtld.c:1972)
==3527834==by 0x4014E8B: _dl_sysdep_start (dl-sysdep.c:140)
==3527834==by 0x4016273: _dl_start_final (rtld.c:497)
==3527834==by 0x4016273: _dl_start (rtld.c:584)
==3527834==by 0x401A193: (below main) (dl-start.S:30)
client stack range: [0x1FFEFFE000 0x1FFF000FFF] client SP: 0x1FFEFFF130
valgrind stack range: [0x1002CC 0x1002DB] top usage: 17968 of 1048576


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.

Bug#1051126: armhf: Miscompilation at O2 level (O1 is working)

[Mathieu Malaterre]

Total Test time (real) =  26.65 sec

The following tests FAILED:
446 - HwyWidenMulTestGroup/HwyWidenMulTest.TestAllSatWidenMulPairwiseAdd/EMU128
 # GetParam() = 2305843009213693952 (Subprocess aborted)
452 - HwyWidenMulTestGroup/HwyWidenMulTest.TestAllSumOfMulQuadAccumulate/EMU128
 # GetParam() = 2305843009213693952 (Subprocess aborted)
Errors while running CTest
FAILED: CMakeFiles/test.util

https://buildd.debian.org/status/fetch.php?pkg=highway=armhf=1.0.7-6=1694727847=0

Bug#1051772: Fwd: ia64 generates wrong-code with LTO

[Mathieu Malaterre]

Package: gcc-13
Version: 13.2.0-3

highway does not seem to work on ia64 with LTO (see #1051769).

On yttrium with gcc-13:

% /usr/bin/g++-13 -g -O2 -ffile-prefix-map=/home/malat/highway-1.0.7=.
-flto=auto -ffat-lto-objects -specs=/usr/share/dpkg/pie-compile.specs
-Wformat -Werror=format-security -DHWY_BROKEN_EMU128=0 -Wdate-time
-D_FORTIFY_SOURCE=2 -flto=auto -ffat-lto-objects
-specs=/usr/share/dpkg/pie-link.specs -fPIE -pie
CMakeFiles/copy_test.dir/hwy/contrib/algo/copy_test.cc.o -o
tests/copy_test
-Wl,-rpath,/home/malat/highway-1.0.7/obj-ia64-linux-gnu
libhwy_test.so.1.0.7 libhwy_contrib.so.1.0.7
/usr/lib/ia64-linux-gnu/libgtest.a
/usr/lib/ia64-linux-gnu/libgtest_main.a libhwy.so.1.0.7
/usr/lib/ia64-linux-gnu/libgtest.a

% gdb ./tests/copy_test
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 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 "ia64-linux-gnu".
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 ./tests/copy_test...
(gdb) r
Starting program: /home/malat/highway-1.0.7/obj-ia64-linux-gnu/tests/copy_test
Failed to read a valid object file image from memory.
Running main() from ./googletest/src/gtest_main.cc

Program received signal SIGSEGV, Segmentation fault.
zsh: abort  gdb ./tests/copy_test

Bug#1051769: ia64 generates wrong-code with LTO

[Mathieu Malaterre]

Package: gcc-12
Version: 12.2.0-12

highway does not seems to work on ia64 with LTO:

https://buildd.debian.org/status/fetch.php?pkg=highway=ia64=1.0.7-3=1694507301=0

The fun part is that even gdb crash on the generated exe:

 % gdb tests/copy_test
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 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 "ia64-linux-gnu".
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 tests/copy_test...
(gdb) r
Starting program: /home/malat/highway-1.0.7/obj-ia64-linux-gnu/tests/copy_test
Failed to read a valid object file image from memory.
Running main() from ./googletest/src/gtest_main.cc

Program received signal SIGSEGV, Segmentation fault.
zsh: abort  gdb tests/copy_test

Bug#1051764: Missing TARGET_OPTION_SAVE/RESTORE on riscv

[Mathieu Malaterre]

Package: gcc-13
Version: 13.2.0-3
Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110812
Affects: src:highway

src:highway fails to compile on riscv64 with LTO. Confirmed upstream.

Bug#1051384: bookworm-pu: package highway/1.0.3-3

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

I'd like to fix highway on armhf (neon-less) system.

[ Reason ]
See #1033656

[ Impact ]
Only armhf system be affected by the rebuild.

[ Tests ]
Tested on abel.d.o (Thanks Wookey!)

[ Risks ]
Very minimal risk, only compiler flags are changed (on armhf).

[ Checklist ]
  [*] *all* changes are documented in the d/changelog
  [*] I reviewed all changes and I approve them
  [*] attach debdiff against the package in (old)stable
  [*] the issue is verified as fixed in unstable

[ Changes ]
Changed one single cmake option
diff -Nru highway-1.0.3/debian/changelog highway-1.0.3/debian/changelog
--- highway-1.0.3/debian/changelog  2023-02-24 08:52:20.0 +0100
+++ highway-1.0.3/debian/changelog  2023-09-07 09:04:55.0 +0200
@@ -1,3 +1,9 @@
+highway (1.0.3-3+deb11u1) bullseye; urgency=medium
+
+  * d/rules: Fix armhf neon-less system. Closes: #1033656
+
+ -- Mathieu Malaterre   Thu, 07 Sep 2023 09:04:55 +0200
+
 highway (1.0.3-3) unstable; urgency=medium
 
   [ Helmut Grohne ]
diff -Nru highway-1.0.3/debian/rules highway-1.0.3/debian/rules
--- highway-1.0.3/debian/rules  2023-02-24 08:51:28.0 +0100
+++ highway-1.0.3/debian/rules  2023-09-07 09:03:41.0 +0200
@@ -18,9 +18,8 @@
 endif
 
 ifeq ($(DEB_HOST_ARCH),$(filter $(DEB_HOST_ARCH),armhf))
-  # highway implement dynamic dipatch:
-  # https://github.com/google/highway/issues/891
-  CMAKE_EXTRA_FLAGS += -DHWY_CMAKE_ARM7:BOOL=ON
+  # https://github.com/google/highway/issues/1271
+  CMAKE_EXTRA_FLAGS += -DHWY_CMAKE_ARM7:BOOL=OFF
 endif
 
 include /usr/share/dpkg/buildtools.mk

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#1050933: aarch64: Miscompilation at O1 level (O0 is working)

[Mathieu Malaterre]

On Sun, Sep 3, 2023 at 9:23 AM Mathieu Malaterre  wrote:
>
> On Sat, Sep 2, 2023 at 1:31 PM Matthias Klose  wrote:
> > upstream asks for a self-contained test case. Not sure if that's something 
> > you
> > tried in https://bugs.debian.org/1050415
>
> Currently working on PR/111231. cresult is difficult to work with as
> it default to aggressive renaming. I've switch to cvise today.
>
> You might see me on amhdal.d.o running cvise but for PR/111231.
> PR/110643 will come next unless you beat me at it ;)

cvise started today.

Status:
[...]
06:48:23 INFO (66.8%, 5552 bytes, 129 lines)

Bug#1051131: RM: jpeg-xl/experimental -- ROM; Newer version upstream

[Mathieu Malaterre]

Package: ftp.debian.org
Severity: normal

Upstream has messed up the releases. 0.9.0snapshot was released *before*
0.8.0.

https://github.com/libjxl/libjxl/tags

I'd like to upload 0.8.0 to unstable, but since there is a SONAME
transition I am required to upload to experimental first.

So please remove all version in experimental so that I can upload 0.8.0.

Version that should be removed: 0.9.0~git20230623.689da0f-4

Thanks

Bug#1050933: aarch64: Miscompilation at O1 level (O0 is working)

[Mathieu Malaterre]

On Sat, Sep 2, 2023 at 1:31 PM Matthias Klose  wrote:
> upstream asks for a self-contained test case. Not sure if that's something you
> tried in https://bugs.debian.org/1050415

Currently working on PR/111231. cresult is difficult to work with as
it default to aggressive renaming. I've switch to cvise today.

You might see me on amhdal.d.o running cvise but for PR/111231.
PR/110643 will come next unless you beat me at it ;)

-M

Bug#1051126: armhf: Miscompilation at O2 level (O1 is working)

[Mathieu Malaterre]

Package: g++-13
Version: 13.2.0-2
Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
Affects: src:highway

I am getting some odd behavior for unit test of highway. I believe
there is some wrong-code generation using g++ + -O2 on armhf. I also
believe this is different from Debian bug #1050933.

Bug#1050992: hwcap default search paths changed

[Mathieu Malaterre]

Source: glibc
Version: 2.37-1

Previously defined hwcap search paths have been changed. Those
specified in `man 8 ld.so` are no longer accurate (bug #1050930).

Typical output on sid/i386:

% LD_DEBUG=libs LD_LIBRARY_PATH=. /bin/true
   3611433: find library=libc.so.6 [0]; searching
   3611433:  search path=.  (LD_LIBRARY_PATH)
   3611433:   trying file=./libc.so.6
   3611433:  search cache=/etc/ld.so.cache
   3611433:   trying file=/lib/i386-linux-gnu/libc.so.6
   3611433:
   3611433:
   3611433: calling init: /lib/ld-linux.so.2
   3611433:
   3611433:
   3611433: calling init: /lib/i386-linux-gnu/libc.so.6
   3611433:
   3611433:
   3611433: initialize program: /bin/true
   3611433:
   3611433:
   3611433: transferring control: /bin/true
   3611433:
   3611433:
   3611433: calling fini:  [0]
   3611433:
   3611433:
   3611433: calling fini: /lib/i386-linux-gnu/libc.so.6 [0]
   3611433:
   3611433:
   3611433: calling fini: /lib/ld-linux.so.2 [0]
   3611433:

Same goes for:

[...]
%  /lib/ld-linux.so.2 --help | tail
This program interpreter self-identifies as: /lib/ld-linux.so.2

Shared library search path:
  (libraries located via /etc/ld.so.cache)
  /lib/i386-linux-gnu (system search path)
  /usr/lib/i386-linux-gnu (system search path)
  /lib (system search path)
  /usr/lib (system search path)

No subdirectories of glibc-hwcaps directories are searched.
[...]

If I understand correctly, this render the following .so file obsolete (unused):

% file /usr/lib/i386-linux-gnu/i686/sse2/libx264.so.164
/usr/lib/i386-linux-gnu/i686/sse2/libx264.so.164: ELF 32-bit LSB
shared object, Intel 80386, version 1 (SYSV), dynamically linked,
BuildID[sha1]=e66974d10aef77af7ed504266cde974d103484d6, stripped

Possibly other packages might be impacted.

I suspect the best upgrade path is simply to document the old hwcap
search path have been removed, and Debian package(s) should not rely
on them anymore (lintian warning?).

Comments ?

Reference:
* https://lists.debian.org/debian-glibc/2023/08/msg00084.html

Bug#1050933: aarch64: Miscompilation at O1 level (O0 is working)

[Mathieu Malaterre]

Package: g++-13
Version: 13.2.0-2
Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110643
Affects: src:highway

I am getting some odd behavior for unit test of highway. I believe
there is some wrong-code generation using g++ + -O1.

Bug#1050930: Obsolete hwcap section

[Mathieu Malaterre]

Package: manpages-dev
Version: 6.03-2

Currently `ld.so` man page describes location hwcap libraries. This
appears to be obsolete in glibc 2.37.

My Debian system reports:

% LD_DEBUG=libs LD_LIBRARY_PATH=. /bin/true
   3624017: find library=libc.so.6 [0]; searching
   3624017:  search
path=./tls/haswell/x86_64:./tls/haswell:./tls/x86_64:./tls:./haswell/x86_64:./haswell:./x86_64:.
   (LD_LIBRARY_PATH)

Debian sid reports:

% LD_DEBUG=libs LD_LIBRARY_PATH=. /bin/true
   3626040: find library=libc.so.6 [0]; searching
   3626040:  search
path=./glibc-hwcaps/x86-64-v3:./glibc-hwcaps/x86-64-v2:.
 (LD_LIBRARY_PATH)


Please tweak the section:

NOTES
   Hardware capabilities
[...]
The following names are currently recognized:
[...]
   x86 (32-bit only)
  acpi, apic, clflush, cmov, cx8, dts, fxsr, ht, i386,
i486, i586, i686, mca, mmx, mtrr, pat, pbe, pge, pn, pse36, sep, ss,
sse, sse2, tm

Thanks !

Bug#1050849: creduce upstream homepage

[Mathieu Malaterre]

Source: creduce
Version: 2.11.0~20230819-1

Could someone please document where creduce homepage is located nowadays.

http://embed.cs.utah.edu/creduce/ seems to be gone.

I am not clear what to do with reports such as:

===< pass_clang_binsrch :: replace-function-def-with-decl >===
Segmentation fault

***

pass_clang_binsrch::replace-function-def-with-decl has encountered a bug:
crashed: "/usr/libexec/clang_delta"
--transformation=replace-function-def-with-decl --counter=1
--to-counter=25 /tmp/creduce-2sfsbN/mul_test.cc

Please consider tarring up /home/malat/creduce_bug_000
and mailing it to creduce-b...@flux.utah.edu and we will try to fix
the bug.

This bug is not fatal, C-Reduce will continue to execute.

***

===< pass_clang_binsrch :: remove-unused-function >===

Thank you !

Bug#1050506: [Pkg-cmake-team] Bug#1050506: Could NOT find EXPAT (missing: EXPAT_LIBRARY) (found version "2.5.0")

[Mathieu Malaterre]

On Fri, Aug 25, 2023 at 4:06 PM Timo Röhling  wrote:
>
> Control: severity -1 normal

This caused a FTBFS in the original bug report.

> Also, why do you think this is a CMake issue and not a VTK issue?

As explained in my original report, this is a change of behavior in
current cmake 3.27. If you use cmake from stable the combo works, so
this is clearly a change of behavior in cmake 3.27, it would be nice
to document what has changed and why.

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#1050415: PermissionError: [Errno 13] Permission denied

[Mathieu Malaterre]

On Thu, Aug 24, 2023 at 7:03 PM Matthias Klose  wrote:
>
> Control: tags -1 - moreinfo
>
> On 24.08.23 15:15, Mathieu Malaterre wrote:
> > On Thu, Aug 24, 2023 at 2:21 PM Matthias Klose  wrote:
> >>
> >> Control: tags -1 + moreinfo
> >>
> >> On 24.08.23 11:54, Mathieu Malaterre wrote:
> >>> Package: cvise
> >>> Version: 2.8.0-1
> >>>
> >>> I cannot run cvise in Debian/sid:
> >>
> >> [...]
> >>
> >>> with:
> >>>
> >>> % ls -al check.sh
> >>> -rwxr-xr-x 1 mathieu mathieu 335 Aug 24 09:50 check.sh
> >>>
> >>> % ls -al testcase.i
> >>> -rw-r--r-- 1 mathieu mathieu 4268253 Aug 24 09:41 testcase.i
> >>>
> >>
> >> an ls is not so useful.
> >
> > Ok, nevermind. I assumed this was something obvious in the python module.
> >
> > Here you go:
> >
> > $ curl -O 
> > https://raw.githubusercontent.com/malaterre/gcc-110622/main/new/testcase.i
> > $ curl -O 
> > https://raw.githubusercontent.com/malaterre/gcc-110622/main/new/check.sh
> > $ chmod +x check.sh
> > $ schroot -c sid32
> > $ cvise check.sh testcase.i
> >
> > If you do not have a sid32 chroot, you may want to use
> > barriere.debian.org + sid_i386-dchroot
>
> that works for me in a sid32 chroot, and also in a sid chroot.
>

I see this is exactly:

https://stackoverflow.com/questions/2009278/python-multiprocessing-permission-denied

In my case:

% ls -ld /dev/shm
drwxr-xr-x 2 root root 40 Aug 24 11:31 /dev/shm

on barriere.d.o:

% ls -ld /dev/shm
drwxrwxrwt 2 root root 40 Aug 25 06:28 /dev/shm


How did you setup your schroot ? Mine is:

% cat /etc/schroot/schroot.conf
[...]
[sid32]
description=Debian sid (unstable) 32-bit
directory=/home/mathieu/tmp/sid-chroot-i386
personality=linux32
root-groups=root
root-users=root
type=directory
users=mathieu

Bug#1050415: PermissionError: [Errno 13] Permission denied

[Mathieu Malaterre]

On Thu, Aug 24, 2023 at 2:21 PM Matthias Klose  wrote:
>
> Control: tags -1 + moreinfo
>
> On 24.08.23 11:54, Mathieu Malaterre wrote:
> > Package: cvise
> > Version: 2.8.0-1
> >
> > I cannot run cvise in Debian/sid:
>
> [...]
>
> > with:
> >
> > % ls -al check.sh
> > -rwxr-xr-x 1 mathieu mathieu 335 Aug 24 09:50 check.sh
> >
> > % ls -al testcase.i
> > -rw-r--r-- 1 mathieu mathieu 4268253 Aug 24 09:41 testcase.i
> >
>
> an ls is not so useful.

Ok, nevermind. I assumed this was something obvious in the python module.

Here you go:

$ curl -O 
https://raw.githubusercontent.com/malaterre/gcc-110622/main/new/testcase.i
$ curl -O 
https://raw.githubusercontent.com/malaterre/gcc-110622/main/new/check.sh
$ chmod +x check.sh
$ schroot -c sid32
$ cvise check.sh testcase.i

If you do not have a sid32 chroot, you may want to use
barriere.debian.org + sid_i386-dchroot

for reference:

% apt-cache policy cvise
cvise:
  Installed: 2.8.0-1
  Candidate: 2.8.0-1
  Version table:
 *** 2.8.0-1 500
500 http://deb.debian.org/debian sid/main i386 Packages
100 /var/lib/dpkg/status

and

% apt-cache policy creduce
creduce:
  Installed: 2.11.0~20230819-1
  Candidate: 2.11.0~20230819-1
  Version table:
 *** 2.11.0~20230819-1 500
500 http://deb.debian.org/debian sid/main i386 Packages
100 /var/lib/dpkg/status

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#1050415: Acknowledgement (PermissionError: [Errno 13] Permission denied)

[Mathieu Malaterre]

For reference, creduce seems to be happy with the exact same settings:

 % creduce check.sh testcase.i
===< 150190 >===
running 3 interestingness tests in parallel
===< pass_unifdef :: 0 >===
===< pass_comments :: 0 >===
===< pass_ifs :: 0 >===
===< pass_includes :: 0 >===
===< pass_line_markers :: 0 >===
===< pass_blank :: 0 >===
===< pass_clang_binsrch :: replace-function-def-with-decl >===
(0.1 %, 4263044 bytes)
(0.2 %, 4260250 bytes)
(0.3 %, 4256026 bytes)
(0.4 %, 4252741 bytes)
(0.4 %, 4251437 bytes)
(0.4 %, 4249928 bytes)
(0.5 %, 4248101 bytes)
(0.5 %, 4246010 bytes)
(0.5 %, 4245334 bytes)
(0.6 %, 4244584 bytes)
(0.6 %, 4243457 bytes)
(0.6 %, 4242382 bytes)
(0.6 %, 4241737 bytes)
(0.6 %, 4240846 bytes)
(0.7 %, 4240150 bytes)
(0.7 %, 4239316 bytes)
(0.7 %, 4238448 bytes)
(0.7 %, 4237766 bytes)
(0.7 %, 4237353 bytes)
(0.7 %, 4236623 bytes)
[...]

Bug#1050415: PermissionError: [Errno 13] Permission denied

[Mathieu Malaterre]

Package: cvise
Version: 2.8.0-1

I cannot run cvise in Debian/sid:

% cvise check.sh testcase.i
00:00:07 INFO ===< 150150 >===
00:00:07 INFO running 4 interestingness tests in parallel
00:00:07 INFO INITIAL PASSES
00:00:07 INFO ===< IncludesPass >===
Traceback (most recent call last):
  File "/usr/bin/cvise", line 312, in 
reducer.reduce(pass_group, skip_initial=args.skip_initial_passes)
  File "/usr/share/cvise/cvise.py", line 149, in reduce
self._run_additional_passes(pass_group['first'])
  File "/usr/share/cvise/cvise.py", line 172, in _run_additional_passes
self.test_manager.run_pass(p)
  File "/usr/share/cvise/utils/testing.py", line 530, in run_pass
success_env = self.run_parallel_tests()
  ^
  File "/usr/share/cvise/utils/testing.py", line 438, in run_parallel_tests
with pebble.ProcessPool(max_workers=self.parallel_tests) as pool:
 ^^^
  File "/usr/lib/python3/dist-packages/pebble/pool/process.py", line
60, in __init__
self._pool_manager = PoolManager(self._context, mp_context)
 ^^
  File "/usr/lib/python3/dist-packages/pebble/pool/process.py", line
202, in __init__
self.worker_manager = WorkerManager(context.workers,
  ^^
  File "/usr/lib/python3/dist-packages/pebble/pool/process.py", line
344, in __init__
self.pool_channel, self.workers_channel = channels(mp_context)
  
  File "/usr/lib/python3/dist-packages/pebble/pool/channel.py", line
35, in channels
WorkerChannel(read0, write1, (read1, write0), mp_context))
^
  File "/usr/lib/python3/dist-packages/pebble/pool/channel.py", line
83, in __init__
self.mutex = ChannelMutex(mp_context)
 
  File "/usr/lib/python3/dist-packages/pebble/pool/channel.py", line
129, in __init__
self.reader_mutex = mp_context.RLock()
^^
  File "/usr/lib/python3.11/multiprocessing/context.py", line 73, in RLock
return RLock(ctx=self.get_context())
   ^
  File "/usr/lib/python3.11/multiprocessing/synchronize.py", line 187,
in __init__
SemLock.__init__(self, RECURSIVE_MUTEX, 1, 1, ctx=ctx)
  File "/usr/lib/python3.11/multiprocessing/synchronize.py", line 57,
in __init__
sl = self._semlock = _multiprocessing.SemLock(
 ^
PermissionError: [Errno 13] Permission denied


with:

% ls -al check.sh
-rwxr-xr-x 1 mathieu mathieu 335 Aug 24 09:50 check.sh

% ls -al testcase.i
-rw-r--r-- 1 mathieu mathieu 4268253 Aug 24 09:41 testcase.i

Bug#1049960: ITP: half -- C++ library for half precision floating point arithmetics

[Mathieu Malaterre]

On Thu, Aug 17, 2023 at 1:27 PM Christian Kastner  wrote:
>
> Package: wnpp
> Severity: wishlist
> Owner: Christian Kastner 
> X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org
>
> * Package name: half
>   Version : 2.2.0
>   Upstream Author : Christian Rau
> * URL : https://sourceforge.net/projects/half/
> * License : MIT
>   Programming Lang: C++
>   Description : C++ library for half precision floating point arithmetics
>
> This is a C++ header-only library to provide an IEEE-754 conformant
> half-precision floating point type along with corresponding arithmetic

What's the difference with https://packages.debian.org/sid/libimath-dev ?

> operators, type conversions and common mathematical functions. It aims
> for both efficiency and ease of use, trying to accurately mimic the
> behaviour of the builtin floating point types at the best performance
> possible. It automatically uses and provides C++11 features when
> possible, but stays completely C++98-compatible when neccessary.

I believe gcc+c++20 provides _Float16 already. Who needs c++98 compat ?

> This is needed by MIOpen, which is also in the process of being
> packaged.
>
> This will be maintained by the Debian ROCm Team.
>

Bug#1050005: ITP: pdftopng -- Convert PDF to PNG

[Mathieu Malaterre]

On Fri, Aug 18, 2023 at 1:19 PM Marvin Renich  wrote:
>
> * Elena Grandi  [230818 05:27]:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Elena Grandi 
> >
> > * Package name: pdftopng
> >   Description : Convert PDF to PNG
> >
> > A command line tool and python library to convert PDFs to PNGs, based on
> > pdftoppm from poppler.

uh ?

% pdftoppm -h 2>&1| grep png
  -png : generate a PNG file

> > This is a dependency of camelot-py (#1049944) and I intend to maintain
> > it in the Python Team.
>
> Does pdftocairo from the poppler-utils package do what you need?  If
> not, would it make sense to submit patches to add pdftopng to the
> poppler-utils package instead of creating a separate package for it?

...or at least document why pdftoppm is not suitable.

Bug#1040935: Please provide a version-less package for libboost-json1.81-dev

[Mathieu Malaterre]

Source: boost1.81
Version: 1.81.0-5.2

As per title. For example I can Depends: on
libboost-program-options-dev and have a nice transition. I cannot do
the equivalent with libboost-json1.81-dev

Thanks !

Bug#1040823: PR target/110560: internal compiler error: in extract_constrain_insn_cached, at recog.cc:2704

[Mathieu Malaterre]

Package: g++-13
Version: 13.1.0-7
Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110560
Affects: src:highway

src:highway fails to compile on riscv64. Confirmed upstream. Already
fixed in GCC14, backported to GCC13:

* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110560#c2

Bug#1040751: ITP: nanosvg -- simple svg parsing library

[Mathieu Malaterre]

On Mon, Jul 10, 2023 at 10:08 AM Chow Loong Jin  wrote:
>
> On Mon, Jul 10, 2023 at 07:50:21AM +0200, Mathieu Malaterre wrote:
> > On Mon, Jul 10, 2023 at 6:03 AM Chow Loong Jin  wrote:
> > > * Package name: nanosvg
> > >   Version : 0~git20221204.1.9da543e
> > >   Upstream Contact: https://github.com/memononen/nanosvg/issues
> > > * URL : https://github.com/memonenen/nanosvg
> >
> > https://github.com/memononen/nanosvg
>
> Whoops, nice catch thanks.
>
> > > * License : zlib
> > >   Programming Lang: C
> > >   Description : simple svg parsing library
> > >
> > > NanoSVG is a simple stupid single-header-file SVG parse. The output of
> > > the parser is a list of cubic bezier shapes.
> > [...]
> > > I will be packaging this library under the Debian 3-D Printing Packages
> > > team as a build-dependency of slic3r-prusa.
> >
> > 4 years ago the project was declared as not actively maintained:
> >
> > * 
> > https://github.com/memononen/nanosvg/commit/25241c5a8f8451d41ab1b02ab2d865b01600d949
>
> Yep I realize that, but unfortunately, while there is a network of
> forks, there doesn't seem to be a clear de-facto "upstream" apart from
> this one as far as I can tell. fltk's fork[1] appears to be the only one
> with versioned git tags, but it has no issue tracker or way to contact
> upstream short of creating a pull request. memononen's repo seems to be
> the original and the only one in the network with issues enabled.
>
> My intention here is to package the latest git snapshot of
> memononen/nanosvg, with the patch for this commit[2] from fltk/nanosvg
> applied for the use of slic3r-prusa 2.6.0.
>
> If this isn't acceptable, the only alternative I can see is to bundle
> the nanosvg headers somewhere in `debian/` or as a separate component
> tarball in slic3r-prusa, and patch slic3r-prusa's build system to use
> that, now that slic3r-prusa upstream's unbundled their copy.
>
> I had also considered asking slic3r-prusa's upstream to just bundle the
> copy of nanosvg that they need, but I think Debian generally leans
> towards unbundling libraries, not bundling new ones.
>
> I'm open to ideas -- I'm not sure what the best course of action is
> here.

Fair enough, at least you are aware of the issue from day one.

Good luck :)  Thanks for packaging nanosvg !

Bug#1040751: ITP: nanosvg -- simple svg parsing library

[Mathieu Malaterre]

On Mon, Jul 10, 2023 at 6:03 AM Chow Loong Jin  wrote:
> * Package name: nanosvg
>   Version : 0~git20221204.1.9da543e
>   Upstream Contact: https://github.com/memononen/nanosvg/issues
> * URL : https://github.com/memonenen/nanosvg

https://github.com/memononen/nanosvg

> * License : zlib
>   Programming Lang: C
>   Description : simple svg parsing library
>
> NanoSVG is a simple stupid single-header-file SVG parse. The output of
> the parser is a list of cubic bezier shapes.
[...]
> I will be packaging this library under the Debian 3-D Printing Packages
> team as a build-dependency of slic3r-prusa.

4 years ago the project was declared as not actively maintained:

* 
https://github.com/memononen/nanosvg/commit/25241c5a8f8451d41ab1b02ab2d865b01600d949

Bug#1040394: Fwd: [someth2say/xmlformat] Submit to debian (Issue #23)

[Mathieu Malaterre]

Source: xmlformat

-- Forwarded message -
From: Jordi Sola

Oh, I didn't know debian was packaging XMLFormat.

They are using the original script from Kitebird (www.kitebird.com), not
this fork.
I wonder if they would be interested in bumping to this updated version!

link:

* https://github.com/someth2say/xmlformat/issues/23

Message ID: 

Bug#635765: /bin/dd: dd if=/dev/zero of=testfile_4G bs=4G count=1 produces a 2G file

[Mathieu Malaterre]

Control: tags -1 wontfix

On Tue, Jul 4, 2023 at 5:02 PM Jakub Wilk  wrote:
>
> * Mathieu Malaterre , 2011-07-28 17:49:
> >For some reason the following command:
> >
> >dd if=/dev/zero of=testfile_4G bs=4G count=1
> >
> >produces a 2G file:
> >
> >$ dd if=/dev/zero of=testfile_4G bs=4G count=1
> >0+1 records in
> >0+1 records out
> >2147479552 bytes (2.1 GB) copied, 64.1528 s, 33.5 MB/s
>
> This happens because:
>
> * "read() (and similar system calls) will transfer at most 0x7000
> (2,147,479,552) bytes".
>
> * dd does not continue after a short read, unless you use
> iflag=fullblock.

Thanks :)

Bug#1039465: DICOM/JSON: (0018,1411) DS [-3. ] # 4,1 Exposure Index

[Mathieu Malaterre]

Source: dcmtk
Version: 3.6.7-8+b1
Forwarded: https://support.dcmtk.org/redmine/issues/1079
Tags: upstream

dcm2json uses the method DcmJsonFormat::normalizeDecimalString() to
normalize DICOM DS values before writing them as JSON.
However, the method currently does not catch all cases where a legal
DICOM DS value is not permitted in JSON.
The JSON type number is defined in
https://www.rfc-editor.org/rfc/rfc7159#section-6 as follows:

number = [ minus ] int [ frac ] [ exp ]
  decimal-point = %x2E   ; .
  digit1-9 = %x31-39 ; 1-9
  e = %x65 / %x45; e E
  exp = e [ minus / plus ] 1*DIGIT
  frac = decimal-point 1*DIGIT
  int = zero / ( digit1-9 *DIGIT )
  minus = %x2D   ; -
  plus = %x2B; +
  zero = %x30; 0

The definition of DICOM DS relies on the ANSI X3.9 standard, i.e. the
specification of FORTRAN. The FORTRAN 'signed-real-literal-constant'
is defined (in slightly simplified form) as:

R709 kind-param is digit-string or scalar-int-constant-name
R710 signed-digit-string is [ sign ] digit-string
R711 digit-string is digit [ digit ] ...
R712 sign is + or –
R713 signed-real-literal-constant is [ sign ] real-literal-constant
R714 real-literal-constant is significand [ exponent-letter exponent ]
or digit-string exponent-letter exponent
R715 significand is digit-string . [ digit-string ] or . digit-string
R716 exponent-letter is E or D
R717 exponent is signed-digit-string

As a regular expression, DICOM DS values can thus be defined as

[+-]?([0-9]+.[0-9]*|.?[0-9]+)(E[+-]?[0-9]+)?

Differences between JSON number and DICOM DS are thus:

JSON does not permit a leading '+' in the significand (i.e. "+1.0" is
valid in DICOM but not in JSON)
JSON does not permit leading zeroes in the significand (i.e. "0003" is
valid in DICOM but not in JSON)
JSON does not permit a leading '.' in the significand (i.e. ".5" is
valid in DICOM but not in JSON)
JSON does not permit a trailing '.' in the significand (i.e. "5." is
valid in DICOM but not in JSON)

DcmJsonFormat::normalizeDecimalString() currently accounts for
differences 1 and 3, but not for 2 and 4. This should be fixed.

Bug#1038774: PR110264: internal compiler error: riscv_vector::vector_insn_info::get_avl_reg_rtx

[Mathieu Malaterre]

Package: g++-13
Version: 13.1.0-6
Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110264
Affects: src:highway

src:highway fails to compile on riscv64. Confirmed upstream. Fixed in GCC14

Bug#1038768: PR110280: internal compiler error: in const_unop, at fold-const.cc:1884

[Mathieu Malaterre]

Package: g++-13
Version: 13.1.0-6
Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110280
Affects: src:highway

src:highway fails to compile on arm64. Confirmed upstream

Bug#1038702: libjpeg6b: Should provide libjpeg62-turbo (>= 1.3.1)

[Mathieu Malaterre]

Source: libjpeg6b
Version: 1:6b2-3.1

As odd as it sounds it seems that libjpeg62 should now provides:

libjpeg62-turbo (>= 1.3.1)

Otherwise it cannot be installed on typical sid system, it would
remove jre for instance:

[...]
% apt-cache show openjdk-17-jre-headless | grep jpeg
Depends: [...] libjpeg62-turbo (>= 1.3.1),
[...]

Please update the Provides field.

Thanks for maintaining libjpeg62

Bug#298721: add lossless and 12/16 bit support to jpeg library

[Mathieu Malaterre]

Control: tags -1 wontfix

This has been recently implemented in -turbo:

* https://github.com/libjpeg-turbo/libjpeg-turbo/issues/402

Thus closing.

Thanks all.

Bug#1037981: Stop installing the header file jpegint.h

[Mathieu Malaterre]

Package: libjpeg62-turbo-dev
Version: 1:2.0.6-4

We should not be distributing jpegint.h header, it gives a false sense of API.

Here is the full verbatim quote from upstream about this:

```
jpegint.h is only included by jpeglib.h if JPEG_INTERNALS is defined.
jpegint.h is a project-private header that exposes internal interfaces
and structures in the libjpeg API library. Unlike the public libjpeg
API/ABI, those internal interfaces and structures are not guaranteed
to be backward or forward compatible in any way. Thus, downstream
projects that include jpegint.h must ensure that they are using a
libjpeg-turbo code base that is compatible with the version of
jpegint.h they are including. Because the libjpeg API has exposed API
structures, the internal structures in jpegint.h are used to store
additional API state that may be necessary in order to implement
certain features or fixes in libjpeg-turbo. Thus, those structures are
not guaranteed to be backward or forward compatible even within a
particular libjpeg-turbo branch/release series. That means that
downstream projects that use jpegint.h cannot rely on a central
(system-wide) installation of the libjpeg-turbo SDK, because there is
no guarantee that the SDK's internal interfaces and structures will
match the ones that the downstream project expects. The real danger is
that a downstream application or library may trigger a buffer overflow
if its expectation regarding the layout of the internal structures
does not match reality. Generally speaking, best practices are for
downstream projects that use jpegint.h to include an in-tree build of
libjpeg-turbo. (For instance, libjpeg-turbo could be included as a Git
submodule that pulls from a specific libjpeg-turbo commit.) The fact
that jpegint.h is not distributed in the libjpeg-turbo SDK encourages
those best practices, whereas distributing jpegint.h would create a
false sense that the interfaces and structures defined therein are
backward/forward compatible. They aren't and never have been, and that
is why jpegint.h has never been distributed in the 30-year history of
libjpeg and libjpeg-turbo. Downstream packages should ABSOLUTELY NEVER
distribute jpegint.h, and any issues caused by the failure to adhere
to those best practices are issues that downstream packagers must
address without the help of The libjpeg-turbo Project.
```

* 
https://github.com/libjpeg-turbo/libjpeg-turbo/pull/695#issuecomment-1591383190

Bug#1001786: jpeg-xl: Please build plugins

[Mathieu Malaterre]

Control: tags -1 - wontfix

On Fri, Jun 9, 2023 at 1:39 PM Julian Wollrath  wrote:
>
> Hi,
>
> > it seems, like upstream is moving the plugin to use lcms2 [1] which is
> > available in debian.
>
> I tried building a package with a new snapshot and enabled the building
> of the gdk-pixbuf plugin and ended up with the attached changes to the
> packaging. I hope that might be of use.

Very neat ! Thanks.

Uploaded to exp a minute ago.

-M

Bug#1036042: build-depends on libgmock-dev

[Mathieu Malaterre]

Control: tags -1 invalid wontfix

> it succeded once I installed the package libgmock-dev.

My crystal ball tells me the compilation error arises somewhere in the
*.cmake ot GTest package.

Since no debuidd machines are failing, closing as invalid.

Thanks