Bug#1078033: opendnssec: FTBFS with GCC 14: implicit function declarations

[Mathieu Mirmont]

On Fri, Aug 16, 2024 at 07:04:43AM -0400, Reinhard Tartler wrote:
> Niko Tyni  writes:
> 
> >
> > This package fails to build from source on current sid.
> >
> >../../../enforcer/src/utils/kaspcheck.c:101:33: error: implicit 
> > declaration of function ‘exit’ [-Wimplicit-function-declaration]
> >  101 | exit(0);
> >   | ^~~~
> >../../../enforcer/src/utils/kaspcheck.c:35:1: note: include ‘’ 
> > or provide a declaration of ‘exit’
> >
> > A full build log is at
> >
> >   
> > https://perl.debian.net/rebuild-logs/sid/opendnssec_2.1.13-1.1/opendnssec_2.1.13-1.1.buildlog
> >
> > I'm not sure why this wasn't filed with the other GCC-14 test rebuild
> > bugs, but it's pretty clearly similar fallout. Usertagging accordingly.
> >
> > See https://gcc.gnu.org/gcc-14/porting_to.html for information on GCC 14,
> > including the change that made implicit function declarations hard errors.
> >
> > Trivial patch attached. Hope it helps.
> 
> I took the liberty of uploading the patch above as an NMU to the
> delayed/2-days queue, following the recommendation as per
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#when-and-how-to-do-an-nmu
> (maybe this would have even warranted a 0-day upload, but I'm not seeing
> the urgency).
> 
> Please let me know if you need me to cancel or delay the upload, ideally
> by making a maintainer upload.

I'm on holidays at the moment, I'll be back next week to have a
look. If there's a hurry then sure you can upload the NMU in the
meantime.

-- 
Mathieu Mirmont 


signature.asc
Description: Digital signature

Bug#1075094: ipsvd: ftbfs with GCC-14

[Mathieu Mirmont]

On Wed, 03 Jul 2024 12:30:54 + Matthias Klose  wrote:
> Package: src:ipsvd
> Version: 1.0.0-6
> Severity: important
> Tags: sid trixie
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-14

Here's a MR that fixes the FTBFS (on salsa):

https://salsa.debian.org/debian/ipsvd/-/merge_requests/1

-- 
Mathieu Mirmont 


signature.asc
Description: Digital signature

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

Here is what I have no my side:

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

since I manually simplified it to:

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

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

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

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

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

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


Thanks,

Bug#1075795: orthanc FTBFS with DCMTK 3.6.8

[Mathieu Malaterre]

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

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


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

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

Bug#1075794: orthanc-wsi FTBFS with DCMTK 3.6.8

[Mathieu Malaterre]

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

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


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

Bug#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#1071149: socklog: diff for NMU version 2.1.0+repack-5.1

[Mathieu Mirmont]

Hi Chris,

Sorry for being slow to respond, I'm quite busy at the moment. Would
you mind removing this NMI for the time being so I can think about
what would be best? I don't suppose there is much urgency here.

As Lorenzo noted, this package is really only meaningful in a runit
based system. I understand that the intention is to standardise within
Debian, but I also want to consider the consequences for downstream
distros.

Thanks.

Mathieu.


On Wed, Jun 12, 2024 at 09:14:24PM +0200, Chris Hofstaedtler wrote:
> Control: tags 1071149 + pending
> 
> 
> Dear maintainer,
> 
> I've prepared an NMU for socklog (versioned as 2.1.0+repack-5.1) and
> uploaded it to DELAYED/10. Please feel free to tell me if I
> should delay it longer.
> 
> I've replaced the execute_after_dh_installinit: target with a B-D on
> dh-sequence-installsysusers, which seems to be the canonical way of
> doing the same thing.
> 
> Regards.
> 

> diff -Nru socklog-2.1.0+repack/debian/changelog 
> socklog-2.1.0+repack/debian/changelog
> --- socklog-2.1.0+repack/debian/changelog 2023-03-06 22:01:18.0 
> +0100
> +++ socklog-2.1.0+repack/debian/changelog 2024-06-12 21:08:18.0 
> +0200
> @@ -1,3 +1,13 @@
> +socklog (2.1.0+repack-5.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +
> +  [ Timo Röhling ]
> +  * Replace dh-sysusers with dh-sequence-installsysusers.
> +(Closes: #1071149)
> +
> + -- Chris Hofstaedtler   Wed, 12 Jun 2024 21:08:18 +0200
> +
>  socklog (2.1.0+repack-5) unstable; urgency=medium
>  
>* Various uninteresting changes
> diff -Nru socklog-2.1.0+repack/debian/control 
> socklog-2.1.0+repack/debian/control
> --- socklog-2.1.0+repack/debian/control   2023-03-06 21:52:36.0 
> +0100
> +++ socklog-2.1.0+repack/debian/control   2024-06-12 21:08:18.0 
> +0200
> @@ -8,8 +8,9 @@
>  Standards-Version: 4.6.2
>  Homepage: http://smarden.org/socklog
>  Build-Depends: debhelper-compat (= 13),
> +   debhelper (>= 13.3),
> dh-runit,
> -   dh-sysuser,
> +   dh-sequence-installsysusers,
> doc-base
>  Rules-Requires-Root: no
>  
> diff -Nru socklog-2.1.0+repack/debian/rules socklog-2.1.0+repack/debian/rules
> --- socklog-2.1.0+repack/debian/rules 2023-03-06 21:52:36.0 +0100
> +++ socklog-2.1.0+repack/debian/rules 2024-06-12 21:08:18.0 +0200
> @@ -8,7 +8,7 @@
>  CONF_LD = src/conf-ld
>  
>  %:
> - dh $@ --with runit,sysuser
> + dh $@ --with runit
>  
>  override_dh_auto_clean:
>   rm -rf compile command
> diff -Nru socklog-2.1.0+repack/debian/socklog-run.sysuser 
> socklog-2.1.0+repack/debian/socklog-run.sysuser
> --- socklog-2.1.0+repack/debian/socklog-run.sysuser   2023-03-06 
> 21:52:36.0 +0100
> +++ socklog-2.1.0+repack/debian/socklog-run.sysuser   1970-01-01 
> 01:00:00.0 +0100
> @@ -1,5 +0,0 @@
> -_socklog-unix defaults
> -_socklog-klog defaults
> -_socklog-inet defaults
> -_socklog-ucspi-tcp defaults
> -_socklog-notify defaults
> diff -Nru socklog-2.1.0+repack/debian/socklog-run.sysusers 
> socklog-2.1.0+repack/debian/socklog-run.sysusers
> --- socklog-2.1.0+repack/debian/socklog-run.sysusers  1970-01-01 
> 01:00:00.0 +0100
> +++ socklog-2.1.0+repack/debian/socklog-run.sysusers  2024-06-12 
> 21:07:15.0 +0200
> @@ -0,0 +1,6 @@
> +u_socklog-unix   -   "Socklog unix user"
> +u_socklog-klog   -   "Socklog klog user"
> +u_socklog-inet   -   "Socklog inet user"
> +u_socklog-ucspi-tcp  -   "Socklog ucspi-tcp user"
> +u_socklog-notify -   "Socklog notify user"
> +


-- 
Mathieu Mirmont 


signature.asc
Description: Digital signature

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#1069918: npm: depedency issue prevent to install npm while neovim is installed

[Mathieu R.]

Package: npm
Version: 9.2.0~ds1-2
Severity: normal
X-Debbugs-Cc: report...@ecl.400iso.net

When trying to install npm on testing, it tries to pull libuv1t64, that appear 
to
be incompatible with libuv1, on wich neovim depends: 

Unsatisfied dependencies:
 libuv1t64 : Breaks: libuv1 (< 1.48.0-1.1)


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'stable-updates'), (500, 
'stable-security'), (450, 'unstable'), (400, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE=fr_FR:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages npm depends on:
ii  ca-certificates20240203
pn  node-abbrev
pn  node-agent-base
pn  node-aproba
pn  node-archy 
pn  node-base64-js 
pn  node-binary-extensions 
pn  node-cacache   
pn  node-chalk 
pn  node-chownr
pn  node-ci-info   
pn  node-cli-table3
pn  node-colors
pn  node-columnify 
pn  node-cssesc
pn  node-debug 
pn  node-depd  
pn  node-diff  
pn  node-emoji-regex   
pn  node-encoding  
pn  node-events
pn  node-glob  
pn  node-got   
pn  node-graceful-fs   
pn  node-gyp   
pn  node-hosted-git-info   
pn  node-http-proxy-agent  
pn  node-https-proxy-agent 
pn  node-ieee754   
pn  node-ini   
pn  node-ip
pn  node-ip-regex  
pn  node-json-parse-better-errors  
pn  node-jsonparse 
pn  node-lru-cache 
pn  node-minimatch 
pn  node-minipass  
pn  node-mkdirp
pn  node-ms
pn  node-negotiator
pn  node-nopt  
pn  node-normalize-package-data
pn  node-npm-bundled   
pn  node-npm-normalize-package-bin 
pn  node-npm-package-arg   
pn  node-npmlog
pn  node-once  
pn  node-p-map 
pn  node-postcss-selector-parser   
pn  node-promise-retry 
pn  node-promzard  
pn  node-read  
pn  node-read-package-json 
pn  node-rimraf
pn  node-semver
pn  node-ssri  
pn  node-string-width  
pn  node-strip-ansi
pn  node-tar   
pn  node-text-table
pn  node-validate-npm-package-license  
pn  node-validate-npm-package-name 
pn  node-which 
pn  node-wrappy
pn  node-write-file-atomic 
pn  node-yallist   
ii  nodejs 18.19.1+dfsg-3

Versions of packages npm recommends:
ii  git   1:2.43.0-1+b1
pn  node-tap  

Versions of packages npm suggests:
pn  node-opener  

Bug#1069155: libreswan: TCP encapsulation fails for lack of support in kernel build config

[Mathieu Baudier]

Package: libreswan
Version: 4.10-2+deb12u1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Trying to use TCP encapsulation (enable-tcp=yes) between two Debian 12 hosts,
in order to work around the connection freezing after a while when using
defaults.

On the client (initiator, roaming) we get:

ERROR setsockopt(SOL_TCP, TCP_ULP) failed (connect_to_tcp_endpoint() +546
/programs/pluto/iface_tcp.c): No such file or directory (errno 2)

On the server (responder, online server) we get:

IKETCP ACCEPTED: socket 14: accepted connection
IKETCP ACCEPTED: socket 14: closing socket; setsockopt(14, SOL_TCP, TCP_ULP,
"espintcp") failed: No such file or directory (errno 2)

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Issue raised to libreswan developers
https://github.com/libreswan/libreswan/issues/1681

who helped with the analysis.

   * What was the outcome of this action?

It appears that the following config parameters are required when building the
kernel:

CONFIG_XFRM_ESPINTCP=y
CONFIG_INET_ESPINTCP=y

But they are not available in the config file:

$ cat /boot/config-$(uname -r) | grep ESPINTCP
# CONFIG_INET_ESPINTCP is not set
# CONFIG_INET6_ESPINTCP is not set

$ cat /boot/config-$(uname -r) | grep CONFIG_XFRM_ESPINTCP


Is it thinkable to ask for these kernel build config parameters to be enabled
in Debian Stable at some point, or is it a no-go?


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

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

Versions of packages libreswan depends on:
ii  bind9-host [host]1:9.18.24-1
ii  debconf [debconf-2.0]1.5.82
ii  dns-root-data2023010101
ii  iproute2 6.1.0-3
ii  iptables 1.8.9-2
ii  libaudit11:3.0.9-1
ii  libc62.36-9+deb12u4
ii  libcap-ng0   0.8.3-1+b3
ii  libcrypt11:4.4.33-2
ii  libcurl3-nss 7.88.1-10+deb12u5
ii  libevent-core-2.1-7  2.1.12-stable-8
ii  libevent-pthreads-2.1-7  2.1.12-stable-8
ii  libldap-2.5-02.5.13+dfsg-5
ii  libldns3 1.8.3-1+b1
ii  libnspr4 2:4.35-1
ii  libnss3  2:3.87.1-1
ii  libnss3-tools2:3.87.1-1
ii  libpam0g 1.5.2-6+deb12u1
ii  libselinux1  3.4-1+b6
ii  libsystemd0  252.22-1~deb12u1
ii  libunbound8  1.17.1-2+deb12u2

Versions of packages libreswan recommends:
ii  python3  3.11.2-1+b1

libreswan suggests no packages.

-- Configuration Files:
/etc/ipsec.conf changed [not included]

-- no debconf information

Bug#1066479: opendnssec: FTBFS: ../../common/scheduler/task.c:137:25: error: implicit declaration of function ‘clamp’ [-Werror=implicit-function-declaration]

[Mathieu Mirmont]

On Tue, Mar 26, 2024 at 02:36:06PM +0100, Cyril Brulebois wrote:
> Control: tag -1 patch pending
> 
> Lucas Nussbaum  (2024-03-13):
> > This is most likely caused by a change in dpkg 1.22.6, that enabled
> > -Werror=implicit-function-declaration. For more information, see
> > https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration
> > 
> > Relevant part (hopefully):
> > > ../../common/scheduler/task.c: In function ‘task_perform’:
> > > ../../common/scheduler/task.c:137:25: error: implicit declaration of 
> > > function ‘clamp’ [-Werror=implicit-function-declaration]
> > >   137 | task->backoff = clamp(task->backoff * 2, 60, 
> > > ODS_SE_MAX_BACKOFF);
> > >   | ^
> > > cc1: some warnings being treated as errors
> > > make[4]: *** [Makefile:601: scheduler/task.o] Error 1
> 
> I thought there would be several things but apparently that's just the
> one. A quick look upstream shows there are more PRs and more fixups
> needed for even newer compilers, but I'm limiting my patch to the bare
> minimum.
> 
> Since that's been open for 10+ days, and since reverse dependencies
> could get kicked out of testing, I'm uploading an NMU right now so that
> I don't forget, but to DELAYED/2 so there's some room to do things
> differently if desired. I'm happy to reschedule/cancel if needed.

Thanks for the NMU.

I had a look at the new warnings and they all seem to be false
positives. I'd rather not introduce unnecessary changes in the
packaged version compared to upstream just to silence them. This
missing header will do.

-- 
Mathieu Mirmont 


signature.asc
Description: Digital signature

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#1064026: Not a bug : environment issue due to wrong charmap

[Mathieu G]

Hello,

After further investigation, I found my problem was due to a wrong
environment : the charmap was not UTF-8 :
$ locale -c charmap
LC_CTYPE
ISO-8859-1

I've fixed this by modifying /etc/default/locale
was :
LANG=fr_FR
Fixed with
LANG=fr_FR.UTF-8

Then
$ sudo update-locale
$ locale -c charmap
LC_CTYPE
UTF-8

Bug should be closed,

Mathieu

Bug#1064026: minetest-data: Strings in french language are replaced by ""

[Mathieu Godlewski]

Package: minetest-data
Version: 5.6.1+dfsg+~1.9.0mt8+dfsg-2
Severity: important
Tags: l10n
X-Debbugs-Cc: mathieu.godlew...@gmail.com

Dear Maintainer,

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 6.1.0-rpi8-rpi-v8 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=ISO-8859-1) (ignored: 
LC_ALL set to fr_FR), LANGUAGE=fr_FR
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages minetest-data depends on:
ii  fonts-croscore20201225-1
ii  fonts-droid-fallback  1:6.0.1r16-1.1

minetest-data recommends no packages.

minetest-data suggests no packages.

-- no debconf information

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&suite=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(), &success);
  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 by

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#1056035: mirror submission for mirror.matnetwrk.net

[Mathieu Mafille]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.matnetwrk.net
Archive-architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el 
riscv64 s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Mathieu Mafille 
Country: CH Switzerland
Location: Saint-Imier / Switzerland
Sponsor: MATNETWRK https://matnetwrk.net




Trace Url: http://mirror.matnetwrk.net/debian/project/trace/
Trace Url: 
http://mirror.matnetwrk.net/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.matnetwrk.net/debian/project/trace/mirror.matnetwrk.net

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#1055237: does not conform to the standards for library packaging

[Mathieu Mirmont]

Hi,

Thanks both of you for the feedback. I'm short on time at the moment
but I'll make the changes you suggested, they makes sense.

And sorry for pushing this version without notice, I didn't realise
other packages were using it and depended on its API.

Cheers.

Mathieu.


On Wed, Nov 08, 2023 at 09:57:39AM +0100, Pierre Gruet wrote:
> Control: severity -1 important
> 
> Hi,
> 
> Thanks Andrius for the advice given here.
> 
> On Wed, 8 Nov 2023 09:44:58 +0200 Andrius Merkys  wrote:
> > Hello,
> >
> > On Thu, 02 Nov 2023 18:10:19 +0100 Pierre Gruet  wrote:
> > > Recently catch2/3.4.0-1 was uploaded to Debian, great. Yet the
> binary packages
> > > do not follow the layout for libraries that is described in
> Policy Section 8.
> > > For instance I think we should provide a shared library and if
> there are enough
> > > reasons not to do so (see Policy 8.3), at least the binary
> package name should
> > > be changed to libcatch2-dev.
> > >
> > > Also this is not a header-only library anymore, the description
> of the package
> > > should be changed.
> >
> > I agree, binary package could be renamed and descriptions should be
> > adapted as well. I am not sure about shared library, though.
> >
> > First, upstream uses full source package version for soversion. This
> > means a transition for even a patch level upstream release. I maintain a
> > couple of packages like this and it is tiring.
> >
> > Second, I do not expect any real binary package depending on catch2
> > shared library as only test objects are linked with it. But I may be
> > wrong here.
> 
> This seems like a good reason to keep a static library, at least for
> the moment.
> 
> If there remains only the renaming of the package and its
> description to be changed, then downgrading the severity looks
> sensible.
> 
> >
> > > As a side note, the upload of the major version 3.x came out
> with many breaking
> > > interface changes giving rise to RC bugs in e.g. genomicsdb,
> netgen, spdlog,
> > > therion just to name a few, also to failing autopkgtests in many
> rdeps. I would
> > > have been more comfortable with such a huge version change being
> advertised and
> > > more prepared, with some kind of a library transition process
> for instance.
> >
> > Right. Such changes should be announced beforehand since catch2 is used
> > widely in the archive. Transition would have been nice indeed.
> 
> If you, Mathieu, have some insight into the best ways to transition
> reverse dependencies, I think giving it in the related bug reports
> would be very helpful.
> 
> >
> > > In any case, thanks for your work on catch2,
> >
> > Seconded - thanks for maintaining this package.
> >
> > Best wishes,
> > Andrius
> >
> >
> 
> Have a great day,
> 
> -- 
> Pierre




-- 
Mathieu Mirmont 


signature.asc
Description: Digital signature

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#1052064: libelogind0: need to be updated to ≥254

[Mathieu Mirmont]

On Sat, Sep 16, 2023 at 09:55:25PM +0200, Adam Borowski wrote:
> Package: libelogind0
> Version: 246.10-1debian1
> Severity: normal
> 
> Hi!
> While this problem hasn't hit amd64 yet due to procps FTBFSing, on riscv64
> it already requires symbols from libsystemd0 (>= 254~rc1).  So it does on
> most other architectures.  And we can expect amd64+i386 to join soon.
> 
> Thus: please update libelogind to provide systemd 254 symbols, quite
> urgently (procps being a Priority: important package).

It has now happened on amd64. Unfortunately upstream elogind is only
on version 252 so it will need to be updated first.

-- 
Mathieu Mirmont 


signature.asc
Description: Digital signature

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&suite=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&arch=loong64&ver=0.7.0-10.2&stamp=1696728916&raw=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#1053580: mirror submission for mirror.matnetwrk.net

[Mathieu Mafille]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.matnetwrk.net
Archive-architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el 
riscv64 s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Mathieu Mafille 
Country: CH Switzerland
Location: Saint-Imier / Switzerland
Sponsor: MATNETWRK https://matnetwrk.net




Trace Url: http://mirror.matnetwrk.net/debian/project/trace/
Trace Url: 
http://mirror.matnetwrk.net/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.matnetwrk.net/debian/project/trace/mirror.matnetwrk.net

Bug#1053516: catch2: new v3 upstream release available

[Mathieu Mirmont]

On Thu, Oct 05, 2023 at 04:03:47PM +0200, Drew Parsons wrote:
> 
> Could catch2 please be updated to the latest upstream release?

Sure. I wasn't planning on packaging the 3.x series initially because
they abandonned the header-only approach that got me interested in
catch2, but if there's demand for it then I can do that.

-- 
Mathieu Mirmont 

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&arch=armhf&ver=1.0.7-6&stamp=1694727847&raw=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&arch=ia64&ver=1.0.7-3&stamp=1694507301&raw=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 !