Bug#1055306: jpeg-xl: CVE-2023-35790

[Mathieu Malaterre]

Control: fixed -1 0.8.2-4

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

0.8.2-4 is in unstable now. Closing

Bug#1053866: transition: jpeg-xl

[Mathieu Malaterre]

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

Finally fixed today. Sorry for the delay.

Bug#1060704: transition: dcmtk

[Mathieu Malaterre]

Jeremy,

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

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

Thank you

Bug#1061627: jpeg-xl: 0.8 failing autopkgtest

[Mathieu Malaterre]

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

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

I'll incorporate the changes.

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

[Mathieu Malaterre]

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

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

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

-M

Bug#1060704: transition: dcmtk

[Mathieu Malaterre]

Sebastian,

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

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

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

[Mathieu Malaterre]

Hi,

On Wed, Jan 31, 2024 at 1:09 AM  wrote:
> If you have any concerns about this patch, please reach out ASAP.  Although
> this package will be uploaded to experimental immediately, there will be a

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

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

[Mathieu Malaterre]

Control: severity -1 important

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

Done ! Thanks

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

[Mathieu Malaterre]

Control: fixed -1 3.6.8-3

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

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

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

Thanks!

Bug#1053866: transition: jpeg-xl

[Mathieu Malaterre]

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

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

Thanks!

Bug#1060704: transition: dcmtk

[Mathieu Malaterre]

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

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

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

Thanks

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

[Mathieu Malaterre]

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

Bug#1060677: Rounding error in OFStandard::atof

[Mathieu Malaterre]

Source: dcmtk
Version: 3.6.7-8+b1

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

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

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

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

Thanks !

ref code is

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

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

  return 0;
}

Bug#1060442: DCMTK Release 3.6.8 available

[Mathieu Malaterre]

Source: dcmtk

Dear DCMTK Package Maintainer,

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

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

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

or via git repos:

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


With best regards,
Dr. Marco Eichelberg

Bug#1056048: Acknowledgement (Memory leak in dcm2json)

[Mathieu Malaterre]

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


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

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


Which gives now the reduced set of leaks:

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

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

[Mathieu Malaterre]

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

Somewhat related to #988644.

Steps:

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

Gives

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

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

Bug#1056048: Memory leak in dcm2json

[Mathieu Malaterre]

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

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

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

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

Reports:

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

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

[Mathieu Malaterre]

Current work-around:

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

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

[Mathieu Malaterre]

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

Confirmed by upstream.

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

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

[Mathieu Malaterre]

Source: dcmtk
Version: 3.6.7-9

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

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

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

[Mathieu Malaterre]

Source: dcmtk
Version: 3.6.7-9

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

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

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

[Mathieu Malaterre]

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

PEBKAC

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

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

[Mathieu Malaterre]

For ref:

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

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

[Mathieu Malaterre]

Package: recode
Version: 3.6-25

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

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


ref:

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

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

[Mathieu Malaterre]

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

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

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

[Mathieu Malaterre]

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

Seems to be fixed in 3.20

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

[Mathieu Malaterre]

Source: valgrind
Version: 1:3.19.0-1

valgrind does not handle clang 14 and up.

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

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

[Mathieu Malaterre]

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

Dear Maintainer,

Consider the following: `man 3 memcpy`

You'll be presented with the following signature:

<...>
SYNOPSIS
   #include 

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

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

Thanks

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

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

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

manpages-dev recommends no packages.

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

-- no debconf information

Bug#1053866: transition: jpeg-xl

[Mathieu Malaterre]

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

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

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


will post back when I get access.

Thanks !

Bug#1053866: transition: jpeg-xl

[Mathieu Malaterre]

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

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

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

Thanks

Ben file:

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

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

[Mathieu Malaterre]

Control: fixed -1 0.7.0-10.2

I see that it builds fine on loong64:

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

Closing.

Thanks

Bug#1053753: libpng1.6 shlibs contains debian revision

[Mathieu Malaterre]

Source: libpng1.6
Version: 1.6.40-1

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

For reference:

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

Thanks

Bug#1053641: transition: libavif

[Mathieu Malaterre]

Hi,


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

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

Thanks,

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

Bug#1050933:

[Mathieu Malaterre]

Control: tags -1 wontfix

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

Closing

Bug#1052677: Fixed in 1.0.7-1

[Mathieu Malaterre]

Version: 1.0.7-1

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

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

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

[Mathieu Malaterre]

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

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

Here is the correct debdiff this time.

Thanks


debdiff-bookworkm
Description: Binary data

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

[Mathieu Malaterre]

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

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

Bug#1052141: Simplified

[Mathieu Malaterre]

Steps:

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

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

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

sched status:
  running_tid=1

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


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

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

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

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

[Mathieu Malaterre]

Reproducer

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

#ifndef HIGHWAY_HWY_ALIGNED_ALLOCATOR_H_
#define HIGHWAY_HWY_ALIGNED_ALLOCATOR_H_

// Memory allocator with support for alignment and offsets.

#include 
#include 

#include "hwy/base.h"

namespace hwy {

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

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

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

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

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

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

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

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

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

  FreePtr free_;
  void* opaque_ptr_;
};

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

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

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

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

[Mathieu Malaterre]

Source: valgrind
Version: 1:3.19.0-1

On amdhal.d.o:

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

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

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

sched status:
  running_tid=1

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


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

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

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

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

[Mathieu Malaterre]

Total Test time (real) =  26.65 sec

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

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

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

[Mathieu Malaterre]

Package: gcc-13
Version: 13.2.0-3

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

On yttrium with gcc-13:

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

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

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./tests/copy_test...
(gdb) r
Starting program: /home/malat/highway-1.0.7/obj-ia64-linux-gnu/tests/copy_test
Failed to read a valid object file image from memory.
Running main() from ./googletest/src/gtest_main.cc

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

Bug#1051769: ia64 generates wrong-code with LTO

[Mathieu Malaterre]

Package: gcc-12
Version: 12.2.0-12

highway does not seems to work on ia64 with LTO:

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

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

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

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from tests/copy_test...
(gdb) r
Starting program: /home/malat/highway-1.0.7/obj-ia64-linux-gnu/tests/copy_test
Failed to read a valid object file image from memory.
Running main() from ./googletest/src/gtest_main.cc

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

Bug#1051764: Missing TARGET_OPTION_SAVE/RESTORE on riscv

[Mathieu Malaterre]

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

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

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

[Mathieu Malaterre]

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

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

[ Reason ]
See #1033656

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

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

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

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

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

Bug#1016903: really closing for real

[Mathieu Malaterre]

Version: 12.2.0-18

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

Thanks

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

[Mathieu Malaterre]

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

cvise started today.

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

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

[Mathieu Malaterre]

Package: ftp.debian.org
Severity: normal

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

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

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

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

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

Thanks

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

[Mathieu Malaterre]

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

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

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

-M

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

[Mathieu Malaterre]

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

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

Bug#1050992: hwcap default search paths changed

[Mathieu Malaterre]

Source: glibc
Version: 2.37-1

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

Typical output on sid/i386:

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

Same goes for:

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

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

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

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

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

Possibly other packages might be impacted.

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

Comments ?

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

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

[Mathieu Malaterre]

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

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

Bug#1050930: Obsolete hwcap section

[Mathieu Malaterre]

Package: manpages-dev
Version: 6.03-2

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

My Debian system reports:

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

Debian sid reports:

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


Please tweak the section:

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

Thanks !

Bug#1050849: creduce upstream homepage

[Mathieu Malaterre]

Source: creduce
Version: 2.11.0~20230819-1

Could someone please document where creduce homepage is located nowadays.

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

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

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

***

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

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

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

***

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

Thank you !

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

[Mathieu Malaterre]

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

This caused a FTBFS in the original bug report.

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

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

Thanks,

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

[Mathieu Malaterre]

Forwarded as #1050506

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

[Mathieu Malaterre]

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

Original bug report is #1042246

Here is a minimal reproduce:

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

find_package(EXPAT REQUIRED)
find_package(VTK REQUIRED)

The above gives:

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

It is unclear why changing:

cmake_minimum_required(VERSION 3.9.2)

into

cmake_minimum_required(VERSION 3.27)

make the symptoms go away.

Thanks for comments,

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

[Mathieu Malaterre]

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

I see this is exactly:

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

In my case:

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

on barriere.d.o:

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


How did you setup your schroot ? Mine is:

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

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

[Mathieu Malaterre]

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

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

Here you go:

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

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

for reference:

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

and

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

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

[Mathieu Malaterre]

Control: tags -1 patch

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

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

2cts

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

Bug#1050415: Acknowledgement (PermissionError: [Errno 13] Permission denied)

[Mathieu Malaterre]

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

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

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

[Mathieu Malaterre]

Package: cvise
Version: 2.8.0-1

I cannot run cvise in Debian/sid:

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


with:

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

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

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

[Mathieu Malaterre]

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

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

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

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

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

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

[Mathieu Malaterre]

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

uh ?

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

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

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

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

[Mathieu Malaterre]

Source: boost1.81
Version: 1.81.0-5.2

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

Thanks !

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

[Mathieu Malaterre]

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

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

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

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

[Mathieu Malaterre]

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

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

Good luck :)  Thanks for packaging nanosvg !

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

[Mathieu Malaterre]

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

https://github.com/memononen/nanosvg

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

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

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

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

[Mathieu Malaterre]

Source: xmlformat

-- Forwarded message -
From: Jordi Sola

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

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

link:

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

Message ID: 

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

[Mathieu Malaterre]

Control: tags -1 wontfix

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

Thanks :)

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

[Mathieu Malaterre]

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

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

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

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

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

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

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

Differences between JSON number and DICOM DS are thus:

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

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

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

[Mathieu Malaterre]

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

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

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

[Mathieu Malaterre]

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

src:highway fails to compile on arm64. Confirmed upstream

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

[Mathieu Malaterre]

Source: libjpeg6b
Version: 1:6b2-3.1

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

libjpeg62-turbo (>= 1.3.1)

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

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

Please update the Provides field.

Thanks for maintaining libjpeg62

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

[Mathieu Malaterre]

Control: tags -1 wontfix

This has been recently implemented in -turbo:

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

Thus closing.

Thanks all.

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

[Mathieu Malaterre]

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

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

Here is the full verbatim quote from upstream about this:

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

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

Bug#1001786: jpeg-xl: Please build plugins

[Mathieu Malaterre]

Control: tags -1 - wontfix

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

Very neat ! Thanks.

Uploaded to exp a minute ago.

-M

Bug#1036042: build-depends on libgmock-dev

[Mathieu Malaterre]

Control: tags -1 invalid wontfix

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

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

Since no debuidd machines are failing, closing as invalid.

Thanks

Bug#566801: jeuclid-cli does not work on simple example

[Mathieu Malaterre]

Control: fixed -1 3.1.9-5

On Sun, May 28, 2023 at 5:39 PM Mathieu Malaterre  wrote:
>
> On Sun, May 28, 2023 at 3:21 PM Pierre Gruet  wrote:
> >
> > Control: tags -1 moreinfo unreproducible
> >
> > Hi Matthieu,
> >
> > Doing some bug triaging...
> >
> > Does the issue you submitted still show up? On my machine with
> > jeuclid-cli/3.1.9-5, is does not.
>
> Can you post your exact command line ?

Nevermind this is included in my original report.

I cannot reproduce it today. Let's close this issue for good.

Thank you

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

[Mathieu Malaterre]

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

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

Yes please ! Thanks very much

> cu Andreas
>
>

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

[Mathieu Malaterre]

Control: tags -1 - patch

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

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

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

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

[Mathieu Malaterre]

Control: tags -1 patch

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

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

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

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

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

[Mathieu Malaterre]

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

openjpeg2/java compilation appears to be broken:

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


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

Bug#1016903: closing for real

[Mathieu Malaterre]

Version: 12.2.0-8

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

Thanks

Bug#1034554: internal compiler error: in finalize_new_accesses, at rtl-ssa/changes.cc:471

[Mathieu Malaterre]

Source: gcc-13
Version:  13-20230411-1

I cannot compile highway on riscv/rv64gcv1p0 with gcc-13.

Compilation fais with:

% /usr/bin/g++-13 -freport-bug -DHWY_SHARED_DEFINE
-I"/home/malat/highway-1.0.4~git20230317.8681eb8" -g -O2
-ffile-prefix-map=/home/malat/highway-1.0.4~git20230317.8681eb8=.
-fstack-protector-strong -Wformat -Werror=format-security
-DHWY_BROKEN_EMU128=0 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIE
-fvisibility=hidden -fvisibility-inlines-hidden
-Wno-builtin-macro-redefined -D__DATE__=\"redacted\"
-D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\"
-fmerge-all-constants -Wall -Wextra -Wconversion -Wsign-conversion
-Wvla -Wnon-virtual-dtor -fmath-errno -fno-exceptions
-march=rv64gcv1p0 -Werror -DHWY_IS_TEST=1 -DGTEST_HAS_PTHREAD=1 -MD
-MT CMakeFiles/transform_test.dir/hwy/contrib/algo/transform_test.cc.o
-MF CMakeFiles/transform_test.dir/hwy/contrib/algo/transform_test.cc.o.d
-o CMakeFiles/transform_test.dir/hwy/contrib/algo/transform_test.cc.o
-c 
'/home/malat/highway-1.0.4~git20230317.8681eb8/hwy/contrib/algo/transform_test.cc'
during RTL pass: vsetvl
/home/malat/highway-1.0.4~git20230317.8681eb8/hwy/contrib/algo/transform_test.cc:
In function 'void
hwy::N_RVV::ForeachCountAndMisalign::operator()(T, D) const
[with T = unsigned char; D = hwy::N_RVV::Simd;
Test = hwy::N_RVV::TestGenerate]':
/home/malat/highway-1.0.4~git20230317.8681eb8/hwy/contrib/algo/transform_test.cc:133:3:
internal compiler error: in finalize_new_accesses, at
rtl-ssa/changes.cc:471
  133 |   }
  |   ^
0xf4b18d rtl_ssa::function_info::finalize_new_accesses(rtl_ssa::insn_change&)
../../src/gcc/rtl-ssa/changes.cc:471
0xf4c0a7 
rtl_ssa::function_info::change_insns(array_slice)
../../src/gcc/rtl-ssa/changes.cc:659
0xb4f1e7 rtl_ssa::function_info::change_insn(rtl_ssa::insn_change&)
../../src/gcc/rtl-ssa/changes.cc:717
0xb4f1e7 change_insn
../../src/gcc/config/riscv/riscv-vsetvl.cc:1028
0xb4f1e7 pass_vsetvl::cleanup_insns() const
../../src/gcc/config/riscv/riscv-vsetvl.cc:3951
0xb59891 pass_vsetvl::lazy_vsetvl()
../../src/gcc/config/riscv/riscv-vsetvl.cc:4211
0xb59a7d pass_vsetvl::execute(function*)
../../src/gcc/config/riscv/riscv-vsetvl.cc:4241
0xb59a7d pass_vsetvl::execute(function*)
../../src/gcc/config/riscv/riscv-vsetvl.cc:4222
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.

Bug#1034353: mime-type: image/jpeg instead of image/jls

[Mathieu Malaterre]

Source: file
Version: 1:5.44-3

Steps:

% wget -O filelogo.jls
"https://bugs.astron.com/file_download.php?file_id=214=bug;
% file --mime-type filelogo.jls
filelogo.jls: image/jpeg

However upstream claims this is fixed since 5.41, some kind of regression ?

* https://bugs.astron.com/view.php?id=252

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

[Mathieu Malaterre]

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

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

Feel free to downgrade severity if my understanding is incorrect.

Thanks

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

[Mathieu Malaterre]

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

Dear Maintainer,

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

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

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



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

Bug#1033656: bt full with dbgsym

[Mathieu Malaterre]

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

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from cjxl...
Reading symbols from
/usr/lib/debug/.build-id/ab/48fb952e2934f68e4c2a25c9f41febf3647a3a.debug...
(gdb) r
Starting program: /usr/bin/cjxl
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
hwy::(anonymous namespace)::robust_statistics::CountingSort (values=0xbeffeda8, num_values=256) at
./hwy/nanobenchmark.cc:214
214   std::vector unique;
(gdb) bt full
#0  hwy::(anonymous
namespace)::robust_statistics::CountingSort
(values=0xbeffeda8, num_values=256) at ./hwy/nanobenchmark.cc:214
unique = std::vector of length 0, capacity 200277594
p = 
#1  0xb6e32256 in hwy::(anonymous
namespace)::robust_statistics::Mode
(num_values=256, values=0xbeffeda8) at ./hwy/nanobenchmark.cc:286
No locals.
#2  hwy::(anonymous namespace)::robust_statistics::Mode (values=...) at ./hwy/nanobenchmark.cc:292
No locals.
#3  hwy::platform::TimerResolution () at ./hwy/nanobenchmark.cc:480
samples = {1760, 680, 760, 720, 720, 760, 720, 640, 600, 680,
720, 720, 720, 720, 720, 640, 600, 680, 720, 720, 720, 720, 720, 640,
600, 680, 760, 720, 720, 720, 720, 680, 640, 680, 720, 760, 720,
  760, 720, 680, 640, 639, 720, 720, 720, 760, 720, 680, 600,
680, 720, 720, 760, 720, 720, 680, 640, 680, 720, 760, 720, 760, 720,
680, 600, 640, 720, 720, 720, 760, 720, 640, 600, 680, 760, 720,
  720, 720, 760, 680, 640, 680, 720, 720, 720, 720, 720, 680,
640, 680, 720, 720, 720, 760, 720, 680, 600, 680, 720, 720, 720, 760,
720, 680, 600, 640, 720, 760, 720, 720, 720, 680, 600, 640, 720,
  720, 760, 720, 720, 680, 600, 640, 720, 720, 720, 720, 720,
680, 640, 680, 720, 720, 760, 720, 720, 680, 600, 680, 760, 760, 720,
720, 720, 680, 600, 680, 760, 720, 720, 720, 720, 680, 600, 640,
  720, 760, 720, 720, 760, 680, 640, 680, 760, 720, 720, 720,
760, 680, 640, 680, 720, 720, 720, 720, 720, 680, 640, 680, 720, 720,
720, 760, 720, 680, 600, 680, 720, 720, 720, 760, 720, 680, 600,
  640, 720, 760, 720, 720, 720, 680...}
i = 
t0 = 
t1 = 
rep = 
can_use_stop = true
repetitions = {0 , 13186041144842129408, 1,
17592186044416, 15272538, 142541998690477, 17592186048511, 0, 1,
142541374619648, 5777693, 132592, 264, 2164, 1680014893, 15272538,
  1680014820, 620070873, 1680014820, 624070829, 1675175164, 0,
0, 4294967550, 0, 13762973729367785472, 13186241022805295247,
13185760231415605028, 545357767376899, 0, 0, 0, 0, 562949953421312,
  550391469175956, 4096, 562949953421317, 580748298035200,
17592186179636, 12885028864, 0, 204933623896, 13185811011904471040,
214748364800, 13186241019735179264, 13155823755177423432, 16089343920,
  13762973007813279746, 13185765720249593216, 0,
13185765720249593216, 0, 13185765720249593216, 0, 17595256270208,
16089343880, 13186532544935362560, 0, 13762975155296927744,
8309530817697147188,
  25769934848, 17595254339061, 580765477765120, 8589934595,
580768540979252, 65025, 5777693, 65025, 5777693, 4295000484, 0, 0,
132592, 4096, 264, 1680014893, 15272538, 1675175164, 0, 1680014820,
  13155827655007724148, 13186223049592012800,
13155827651937566720, 13185775014558756952, 13762975106961762556,
13185776139974469871, 13186226454276272160, 1, 3204442356, 1, 0,
4294967317,
  7365196392, 4294967306, 13762989606637072416, 2199023255566,
282579962709375, 0, 4297588739, 223338299392, 360292368236282336,
11259024840327220, 4296605722, 0, 550391469047808, 21474964628,
  4294971392, 578600814378556, 2147483782716, 25769804280,
8589938688, 579545707183896, 996432547608, 25769804008, 17179869188,
1047972020468, 154618822900, 17179869220, 7238662637146341380, 0, 0,
  25769803776, 7238662641441308688, 578600814378556,
1941325352508, 17179869636, 17179869185, 12884901908,
4116180958662970951, 6298471032490531664, 11912611826552620581,
38654705667, 25769803778,
  9799869300677419416, 42949672969, 17050484449554202637,
14311808551372633164, 16948032204727468581, 2814546232200178528,
215689415, 0, 0, 1136, 589827, 135212, 300649021443, 0, 68719476770,
0,
  100072738, 0, 876173328402, 0, 

Bug#1033656: HWY_CMAKE_ARM7:BOOL=ON vs Dynamic Dispatch

[Mathieu Malaterre]

Control: forwarded -1 https://github.com/google/highway/issues/1271

Technically we could just do a source upload with
HWY_CMAKE_ARM7:BOOL=OFF. HWY_CMAKE_ARM7:BOOL=ON is a hack for an old
clang version, if I understand correctly.

Bug#1033656: illegal hardware instruction cjxl

[Mathieu Malaterre]

Package: libjxl-tools
Version: 0.7.0-10
Severity: important

cjxl/djxl cannot be used on armhf neon-less system. They fails with:

% djxl
zsh: illegal hardware instruction  djxl

Full ref:

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

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/cjxl...
(No debugging symbols found in /usr/bin/cjxl)
(gdb) r
Starting program: /usr/bin/cjxl
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
0xb6e31fbe in ?? () from /usr/lib/arm-linux-gnueabihf/libhwy.so.1
(gdb) x/i $pc
=> 0xb6e31fbe:  vmov.i32d16, #0 @ 0x
(gdb) bt full
#0  0xb6e31fbe in ?? () from /usr/lib/arm-linux-gnueabihf/libhwy.so.1
No symbol table info available.
#1  0xb6e32256 in hwy::platform::TimerResolution() () from
/usr/lib/arm-linux-gnueabihf/libhwy.so.1
No symbol table info available.
#2  0xb6e30e0e in ?? () from /usr/lib/arm-linux-gnueabihf/libhwy.so.1
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) quit

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

[Mathieu Malaterre]

Control: reopen -1

> the upstream fix went into 12.2.0-2.

Would be so kind as to demonstrate how ?

Here is what I see on my side:

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

Then a simple check within the sid schroot:

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

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

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

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

Compared with:

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

Per discussion with gcc-upstream:

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

Bug#1016903: vect: Don't allow vect_emulated_vector_p type in vectorizable_call [PR106322]

[Mathieu Malaterre]

Control: severity -1 grave

By default packages on Debian are build with -O2 since I see that it
affects release arches:

* armel
* i386
* mips64el
* mipsel

Would it be possible to include fix:

https://gcc.gnu.org/g:9f532fec01d6651cc3cc136073f044a7953d8560

Thanks,

Bug#1032118: riscv64: error: too few arguments to function 'long unsigned int __riscv_vsetvlmax_e8mf8(void)'

[Mathieu Malaterre]

Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108927
Control: tags -1 confirmed upstream patch

[PATCH] RISC-V: Remove void_type_node of void_args for vsetvlmax intrinsic

https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612858.html

Bug#1032118: riscv64: error: too few arguments to function 'long unsigned int __riscv_vsetvlmax_e8mf8(void)'

[Mathieu Malaterre]

Source: gcc-snapshot

riscv64 intrisincs are currently broken.

% cat t.c
#include 

int main()
{
   size_t vl = __riscv_vsetvlmax_e8mf8();
   return vl;
}

Gives:

g++  -march=rv64gcv1p0   t.c
t.c: In function 'int main()':
t.c:5:39: error: too few arguments to function 'long unsigned int
__riscv_vsetvlmax_e8mf8(void)'
5 |size_t vl = __riscv_vsetvlmax_e8mf8();
  |~~~^~
In file included from t.c:1:
/usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/13/include/riscv_vector.h:94:25:
note: declared here
   94 | #pragma riscv intrinsic "vector"
  | ^~~~

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

[Mathieu Malaterre]

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

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

Steps:

% cat p.cxx
#include 

int main() { return 0; }

Lead to:

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

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

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

Bug#1031866: /usr/bin/ld: cannot find -lgcc_s: No such file or directory

[Mathieu Malaterre]

Package: gcc-snapshot
Version: 1:20230108-1

on riscv64, here is what I see:

$ cat /tmp/bla.c
int main() {}

$  /usr/lib/gcc-snapshot/bin/gcc /tmp/bla.c
/usr/bin/ld: cannot find -lgcc_s: No such file or directory
collect2: error: ld returned 1 exit status

Thanks

Bug#1024141: gtest: Normal execution is halted

[Mathieu Malaterre]

On Tue, Nov 15, 2022 at 3:05 PM Steven Robbins  wrote:
>
> On Tuesday, November 15, 2022 7:44:13 A.M. CST Mathieu Malaterre wrote:
>
> > jpeg-xl unit tests cannot be run on GNU/Hurd. It seems to be stuck for
> > infinite time.
>
> That is curious.  It would help greatly if you had a minimal example.

Looks like an Heisenbug. Sometime I can reproduce it some time not. So
if you are luck in gdb you can reproduce the infinite loop behavior
(as if stuck):

(gdb) r
Starting program:
/home/malat/jpeg-xl-0.7.0/obj-i686-gnu/lib/tests/codec_test
"--gtest_filter=CodecTest.TestRoundTrip"

Running main() from ./googletest/src/gtest_main.cc
Note: Google Test filter = CodecTest.TestRoundTrip
[==] Running 1 test from 1 test suite.
[--] Global test environment set-up.
[--] 1 test from CodecTest
[ RUN  ] CodecTest.TestRoundTrip
^C[New Thread 29923.13]
[New Thread 29923.14]
[New Thread 29923.15]
[New Thread 29923.16]
[New Thread 29923.17]
[New Thread 29923.18]
[New Thread 29923.19]
[New Thread 29923.20]
[New Thread 29923.21]
[New Thread 29923.22]
[New Thread 29923.23]
[New Thread 29923.24]
[New Thread 29923.25]

Thread 4 received signal SIGINT, Interrupt.
0x0189c7ac in ?? () from /lib/i386-gnu/libc.so.0.3
(gdb) bt
#0  0x0189c7ac in ?? () from /lib/i386-gnu/libc.so.0.3
#1  0x0189cf60 in mach_msg () from /lib/i386-gnu/libc.so.0.3
#2  0x01876e7c in ?? () from /lib/i386-gnu/libpthread.so.0.3
#3  0x018755f0 in pthread_cond_broadcast () from /lib/i386-gnu/libpthread.so.0.3
#4  0x015ef8c8 in std::condition_variable::notify_all() () from
/lib/i386-gnu/libstdc++.so.6
#5  0x08096e1b in jpegxl::ThreadParallelRunner::StartWorkers
(worker_command=18446744073709551613, this=0x1037620) at
./lib/threads/thread_parallel_runner_internal.h:136
#6  
jpegxl::ThreadParallelRunner::RunOnEachThread > (func=..., this=0x1037620) at
./lib/threads/thread_parallel_runner_internal.h:90
#7  jpegxl::ThreadParallelRunner::ThreadParallelRunner
(this=, num_worker_threads=) at
./lib/threads/thread_parallel_runner_internal.cc:199
#8  0x08050998 in jxl::ThreadPoolInternal::ThreadPoolInternal
(num_worker_threads=, this=) at
./lib/jxl/base/thread_pool_internal.h:33
#9  jxl::extras::(anonymous
namespace)::CodecTest_TestRoundTrip_Test::TestBody (this=) at ./lib/extras/codec_test.cc:272
#10 0x082c9a8a in void
testing::internal::HandleExceptionsInMethodIfSupported(testing::Test*, void (testing::Test::*)(), char const*) ()
#11 0x082b9717 in testing::Test::Run() ()
#12 0x082b9919 in testing::TestInfo::Run() ()
#13 0x082b9e87 in testing::TestSuite::Run() ()
#14 0x082bf935 in testing::internal::UnitTestImpl::RunAllTests() ()
#15 0x082ca00a in bool
testing::internal::HandleExceptionsInMethodIfSupported(testing::internal::UnitTestImpl*, bool
(testing::internal::UnitTestImpl::*)(), char const*)
()
#16 0x082b9a00 in testing::UnitTest::Run() ()
#17 0x0804a033 in main ()
(gdb) bt full
#0  0x0189c7ac in ?? () from /lib/i386-gnu/libc.so.0.3
No symbol table info available.
#1  0x0189cf60 in mach_msg () from /lib/i386-gnu/libc.so.0.3
No symbol table info available.
#2  0x01876e7c in ?? () from /lib/i386-gnu/libpthread.so.0.3
No symbol table info available.
#3  0x018755f0 in pthread_cond_broadcast () from /lib/i386-gnu/libpthread.so.0.3
No symbol table info available.
#4  0x015ef8c8 in std::condition_variable::notify_all() () from
/lib/i386-gnu/libstdc++.so.6
No symbol table info available.
#5  0x08096e1b in jpegxl::ThreadParallelRunner::StartWorkers
(worker_command=18446744073709551613, this=0x1037620) at
./lib/threads/thread_parallel_runner_internal.h:136
No locals.
#6  
jpegxl::ThreadParallelRunner::RunOnEachThread > (func=..., this=0x1037620) at
./lib/threads/thread_parallel_runner_internal.h:90
thread = 
#7  jpegxl::ThreadParallelRunner::ThreadParallelRunner
(this=, num_worker_threads=) at
./lib/threads/thread_parallel_runner_internal.cc:199
i = 
#8  0x08050998 in jxl::ThreadPoolInternal::ThreadPoolInternal
(num_worker_threads=, this=) at
./lib/jxl/base/thread_pool_internal.h:33
No locals.
#9  jxl::extras::(anonymous
namespace)::CodecTest_TestRoundTrip_Test::TestBody (this=) at ./lib/extras/codec_test.cc:272
pool = { = {
runner_ = 0x8096560
,
runner_opaque_ = 0x1037620}, runner_ = {memory_manager =
{opaque = 0x, alloc = 0x1ae65c0 <_IO_file_jumps>, free =
0x82f3950}, static kWorkerWait = 18446744073709551614,
static kWorkerOnce = 18446744073709551613, static
kWorkerExit = 18446744073709551612, threads_ = std::vector of length
12, capacity 12 = {{_M_id = {_M_thread = 3}}, {_M_id = {_M_thread =
4}}, {
_M_id = {_M_thread = 5}}, {_M_id = {_M_thread = 6}},
{_M_id = {_M_thread = 7}}, {_M_id = {_M_thread = 8}}, {_M_id =
{_M_thread = 9}}, {_M_id = {_M_thread = 10}}, {_M_id = {_M_thread =
11}}, {
_M_id = {_M_thread = 12}}, {_M_id = {_M_thread = 13}},
{_M_id = {_M_thread = 14}}}, num_worker_threads_ = 

Bug#1029698: ColorManagementTestInstantiation/ColorManagementTest.VerifyAllProfiles/ColorEncoding/RGB_D65_SRG_Per_709 (Failed)

[Mathieu Malaterre]

Source: jpeg-xl
Version: 0.8.0~git20230118.bcacd51-1

Seems like there is a regression in the testsuite since 0.7.0

See:
https://github.com/libjxl/libjxl/issues/1910

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

[Mathieu Malaterre]

Control: tags -1 patch

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

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

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

Typical patch would be:

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