Bug#1072963: jpeg-xl: Failing autopkgtests on non-amd64
Julian, On Tue, Jun 11, 2024 at 1:06 AM Jeremy Bícha wrote: > > Source: jpeg-xl > Version: 0.9.2-6 > Severity: serious > Tags: experimental > > jpeg-xl in experimental has autopkgtests that are failing on all > architectures except for amd64. > > Specifically, the problem is that debian/libjxl-gdk-pixbuf.postinst > and debian/libjxl-gdk-pixbuf.postrm have hardcoded the amd64 > architecture which means that libjxl-gdk-pixbuf is uninstallable on > architectures other than amd64. > > https://ci.debian.net/packages/j/jpeg-xl/unstable/arm64/ > > https://salsa.debian.org/debian-phototools-team/libjxl/-/blob/debian/experimental/debian/libjxl-gdk-pixbuf.postinst Could you comment on the above ? Thanks
Bug#1072963: jpeg-xl: Failing autopkgtests on non-amd64
Julian, On Tue, Jun 11, 2024 at 1:06 AM Jeremy Bícha wrote: > > Source: jpeg-xl > Version: 0.9.2-6 > Severity: serious > Tags: experimental > > jpeg-xl in experimental has autopkgtests that are failing on all > architectures except for amd64. > > Specifically, the problem is that debian/libjxl-gdk-pixbuf.postinst > and debian/libjxl-gdk-pixbuf.postrm have hardcoded the amd64 > architecture which means that libjxl-gdk-pixbuf is uninstallable on > architectures other than amd64. > > https://ci.debian.net/packages/j/jpeg-xl/unstable/arm64/ > > https://salsa.debian.org/debian-phototools-team/libjxl/-/blob/debian/experimental/debian/libjxl-gdk-pixbuf.postinst Could you comment on the above ? Thanks
Bug#1072963: jpeg-xl: Failing autopkgtests on non-amd64
Julian, On Tue, Jun 11, 2024 at 1:06 AM Jeremy Bícha wrote: > > Source: jpeg-xl > Version: 0.9.2-6 > Severity: serious > Tags: experimental > > jpeg-xl in experimental has autopkgtests that are failing on all > architectures except for amd64. > > Specifically, the problem is that debian/libjxl-gdk-pixbuf.postinst > and debian/libjxl-gdk-pixbuf.postrm have hardcoded the amd64 > architecture which means that libjxl-gdk-pixbuf is uninstallable on > architectures other than amd64. > > https://ci.debian.net/packages/j/jpeg-xl/unstable/arm64/ > > https://salsa.debian.org/debian-phototools-team/libjxl/-/blob/debian/experimental/debian/libjxl-gdk-pixbuf.postinst Could you comment on the above ? Thanks
Bug#1055306: jpeg-xl: CVE-2023-35790
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#1055306: jpeg-xl: CVE-2023-35790
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
SONAME transition vs reverse dependencies
Hi folks, I am being asked to rebuild all reverse dependencies of dcmtk to transition to 3.6.8 (*). I have tried without success to get access to debomatic-amd64 with no luck so far. Would anyone have any other suggestions to get this transition rolling (stuck for 5 months now). Thanks, (*) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060704#10
Re: t64 suffix
On Mon, May 27, 2024 at 10:26 PM Steve Langasek wrote: > > On Thu, May 23, 2024 at 08:14:20PM +0200, Mathieu Malaterre wrote: > > Dear all, > > > I am trying to find the status of t64 suffix, but I cannot find it > > neither in my mailbox nor on the page: > > > https://wiki.debian.org/ReleaseGoals/64bit-time#Transition_in_place > > > What is expected from Debian packager now ? > > > 1. Remove the t64 suffix upon next version upload ? > > Does the new version have a new soname? if not it would be incorrect to undo > this transition. Ack. Now that makes sense. > > 2. Keep the package-name-doesnt-match-sonames lintian warning (for now) ? > > What package are you seeing such a warning on? The mass-NMUs included a > lintian override to suppress this warning. I think I am missing something big here...anyway here it goes: * https://udd.debian.org/lintian/?packages=highway (I'll fix the symbols-file-contains-current-version-with-debian-revision asap). Thanks all for your kind help -M
t64 suffix
Dear all, I am trying to find the status of t64 suffix, but I cannot find it neither in my mailbox nor on the page: https://wiki.debian.org/ReleaseGoals/64bit-time#Transition_in_place What is expected from Debian packager now ? 1. Remove the t64 suffix upon next version upload ? 2. Keep the package-name-doesnt-match-sonames lintian warning (for now) ? Thanks all -M
Bug#1053866: transition: jpeg-xl
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#1053866: transition: jpeg-xl
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
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#1060704: transition: dcmtk
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
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#1061627: jpeg-xl: 0.8 failing autopkgtest
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#1061627: jpeg-xl: 0.8 failing autopkgtest
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)
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#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)
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
Re: Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)
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
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#1060704: transition: dcmtk
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
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#1062022: dcmtk: NMU diff for 64-bit time_t transition
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)
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)
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)
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#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)
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
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#1053866: transition: jpeg-xl
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
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#1060704: transition: dcmtk
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
[med-svn] [Git][med-team/dcmtk][debian/experimental] 2 commits: d/rules: Fix armel buildd
Mathieu Malaterre pushed to branch debian/experimental at Debian Med / dcmtk Commits: 42583dfe by Emanuele Rocca at 2024-01-12T17:08:37+01:00 d/rules: Fix armel buildd - - - - - f4c27faa by Mathieu Malaterre at 2024-01-12T17:09:28+01:00 d/changelog: Upload 3.6.8-3 to experimental - - - - - 2 changed files: - debian/changelog - debian/rules Changes: = debian/changelog = @@ -1,3 +1,10 @@ +dcmtk (3.6.8-3) experimental; urgency=medium + + [ Emanuele Rocca ] + * d/rules: Fix armel buildd + + -- Mathieu Malaterre Fri, 12 Jan 2024 17:09:17 +0100 + dcmtk (3.6.8-2) experimental; urgency=medium * d/rules: Fix test suite on x87 hardware = debian/rules = @@ -2,7 +2,12 @@ #export DH_VERBOSE=1 # export DEB_BUILD_MAINT_OPTIONS = hardening=+pie -export DEB_BUILD_MAINT_OPTIONS = hardening=+all optimize=+lto +ifeq ($(DEB_TARGET_ARCH),armel) + # https://lists.debian.org/debian-arm/2024/01/msg00031.html + export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-stackclash optimize=+lto +else + export DEB_BUILD_MAINT_OPTIONS = hardening=+all optimize=+lto +endif # needed for the tests export DCMDICTPATH=$(CURDIR)/dcmdata/data/dicom.dic View it on GitLab: https://salsa.debian.org/med-team/dcmtk/-/compare/0616f774e336978a9e909a638b3776a3e49ce9eb...f4c27faad1a6420f5050ee251fecb3353d973055 -- View it on GitLab: https://salsa.debian.org/med-team/dcmtk/-/compare/0616f774e336978a9e909a638b3776a3e49ce9eb...f4c27faad1a6420f5050ee251fecb3353d973055 You're receiving this email because of your account on salsa.debian.org. ___ debian-med-commit mailing list debian-med-com...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
[med-svn] [Git][med-team/dcmtk] Pushed new tag debian/3.6.8-3
Mathieu Malaterre pushed new tag debian/3.6.8-3 at Debian Med / dcmtk -- View it on GitLab: https://salsa.debian.org/med-team/dcmtk/-/tree/debian/3.6.8-3 You're receiving this email because of your account on salsa.debian.org. ___ debian-med-commit mailing list debian-med-com...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
Bug#1060677: Acknowledgement (Rounding error in OFStandard::atof)
forwarded -1 https://support.dcmtk.org/redmine/issues/1100
Bug#1060677: Rounding error in OFStandard::atof
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;
}
Error: bad immediate value for offset (4100)
[CC me please] Dear ARM porters, Could someone please confirm what I see on the armel/buildd: * https://buildd.debian.org/status/fetch.php?pkg=dcmtk=armel=3.6.8-2=1705054390=0 Is this a 32bits/limited RAM issue ? Is there a way to fix the symptoms ? Thanks !
[med-svn] [Git][med-team/dcmtk] Pushed new tag debian/3.6.8-2
Mathieu Malaterre pushed new tag debian/3.6.8-2 at Debian Med / dcmtk -- View it on GitLab: https://salsa.debian.org/med-team/dcmtk/-/tree/debian/3.6.8-2 You're receiving this email because of your account on salsa.debian.org. ___ debian-med-commit mailing list debian-med-com...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
[med-svn] [Git][med-team/dcmtk][debian/experimental] 3 commits: d/rules: Fix test suite on x87 hardware
Mathieu Malaterre pushed to branch debian/experimental at Debian Med / dcmtk
Commits:
55e72fc5 by Mathieu Malaterre at 2024-01-12T10:33:11+01:00
d/rules: Fix test suite on x87 hardware
- - - - -
2dce6668 by Mathieu Malaterre at 2024-01-12T10:33:52+01:00
d/patches: Import bug fix from upstream
- - - - -
0616f774 by Mathieu Malaterre at 2024-01-12T10:34:53+01:00
d/changelog: Upload 3.6.8-2 to experimental
- - - - -
4 changed files:
- debian/changelog
- + debian/patches/da5370947226783ce3548bf1e5b7112fac70de46.patch
- debian/patches/series
- debian/rules
Changes:
=
debian/changelog
=
@@ -1,3 +1,10 @@
+dcmtk (3.6.8-2) experimental; urgency=medium
+
+ * d/rules: Fix test suite on x87 hardware
+ * d/patches: Import bug fix from upstream
+
+ -- Mathieu Malaterre Fri, 12 Jan 2024 10:34:32 +0100
+
dcmtk (3.6.8-1) experimental; urgency=medium
* New upstream version 3.6.8
=
debian/patches/da5370947226783ce3548bf1e5b7112fac70de46.patch
=
@@ -0,0 +1,57 @@
+From da5370947226783ce3548bf1e5b7112fac70de46 Mon Sep 17 00:00:00 2001
+From: Joerg Riesmeier
+Date: Wed, 8 Nov 2023 11:38:54 +0100
+Subject: [PATCH] Fixed issue with delimiters being converted.
+
+Fixed issue with delimiter character "\" being converted when converting
+a DICOM dataset that uses a Specific Character Set of "ISO 2022 IR 13\ISO
+2022 IR 87" to UTF-8. The delimiter "\" was incorrectly converted to the
+Yen sign when processing the value of an "LO" data element that contains
+multiple values but does not use any escape sequences. This issues has
+been fixed now by always treating the delimiters in a special way.
+
+Thanks to Mathieu Malaterre for the report
+and David Gobbi for the analysis and testing.
+---
+ dcmdata/libsrc/dcspchrs.cc | 14 --
+ 1 file changed, 8 insertions(+), 6 deletions(-)
+
+diff --git a/dcmdata/libsrc/dcspchrs.cc b/dcmdata/libsrc/dcspchrs.cc
+index c327a1aa8..69d14a160 100644
+--- a/dcmdata/libsrc/dcspchrs.cc
b/dcmdata/libsrc/dcspchrs.cc
+@@ -1,6 +1,6 @@
+ /*
+ *
+- * Copyright (C) 2011-2022, OFFIS e.V.
++ * Copyright (C) 2011-2023, OFFIS e.V.
+ * All rights reserved. See COPYRIGHT file for details.
+ *
+ * This software and supporting documentation were developed by
+@@ -548,8 +548,9 @@ OFCondition DcmSpecificCharacterSet::convertString(const
char *fromString,
+const OFString )
+ {
+ OFCondition status = EC_Normal;
+-// check whether there are any code extensions at all
+-if (EncodingConverters.empty() || !checkForEscapeCharacter(fromString,
fromLength))
++// check whether there are or could be any code extensions
++const OFBool hasEscapeChar = checkForEscapeCharacter(fromString,
fromLength);
++if (EncodingConverters.empty() || (!hasEscapeChar && delimiters.empty()))
+ {
+ DCMDATA_DEBUG("DcmSpecificCharacterSet: Converting '"
+ << convertToLengthLimitedOctalString(fromString, fromLength) <<
"'");
+@@ -564,10 +565,11 @@ OFCondition DcmSpecificCharacterSet::convertString(const
char *fromString,
+ } else {
+ DCMDATA_DEBUG("DcmSpecificCharacterSet: Converting '"
+ << convertToLengthLimitedOctalString(fromString, fromLength)
+-<< "' (with code extensions and delimiters '" << delimiters
<< "')");
++<< "' (with " << (hasEscapeChar ? "code extensions and " : "")
++<< "delimiters '" << delimiters << "')");
+ }
+-// code extensions according to ISO 2022 used, so we need to check for
+-// particular escape sequences in order to switch between character
sets
++// code extensions according to ISO 2022 (possibly) used, so we need
to check
++// for particular escape sequences in order to switch between
character sets
+ toString.clear();
+ size_t pos = 0;
+ // some (extended) character sets use more than 1 byte per character
=
debian/patches/series
=
@@ -10,3 +10,4 @@
#1c8cca4bf6f7c92fc16f9e66faf49409c891a2b0.patch
#f06a867513524664a1b03dfcf812d8b60fdd02cc.patch
remove_version.patch
+da5370947226783ce3548bf1e5b7112fac70de46.patch
=
debian/rules
=
@@ -14,8 +14,13 @@ else
BUILDDOC = ON
endif
+ifeq ($(DEB_HOST_ARCH_CPU),i386)
+ DEB_CXXFLAGS_MAINT_APPEND += -fexcess-precision=fast
+endif
+
# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001703
-export DEB_CXXFLAGS_MAINT_APPEND=-DENABLE_DCMJPLS_INTERLEAVE_NONE
+DEB_CXXFLAGS_MAI
[med-svn] [Git][med-team/dcmtk] Pushed new tag upstream/3.6.8
Mathieu Malaterre pushed new tag upstream/3.6.8 at Debian Med / dcmtk -- View it on GitLab: https://salsa.debian.org/med-team/dcmtk/-/tree/upstream/3.6.8 You're receiving this email because of your account on salsa.debian.org. ___ debian-med-commit mailing list debian-med-com...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
[med-svn] [Git][med-team/dcmtk] Pushed new tag debian/3.6.8-1
Mathieu Malaterre pushed new tag debian/3.6.8-1 at Debian Med / dcmtk -- View it on GitLab: https://salsa.debian.org/med-team/dcmtk/-/tree/debian/3.6.8-1 You're receiving this email because of your account on salsa.debian.org. ___ debian-med-commit mailing list debian-med-com...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
[med-svn] [Git][med-team/dcmtk][debian/experimental] 4 commits: New upstream version 3.6.8
Mathieu Malaterre pushed to branch debian/experimental at Debian Med / dcmtk Commits: 2ffc893b by Mathieu Malaterre at 2024-01-11T15:40:43+01:00 New upstream version 3.6.8 - - - - - 67a6f7c4 by Mathieu Malaterre at 2024-01-11T15:40:43+01:00 Update upstream source from tag upstream/3.6.8 Update to upstream version 3.6.8 with Debian dir 9197f93b8f3af0afd6f1f4f0edb87e66c45db77f - - - - - 33a56d33 by Mathieu Malaterre at 2024-01-11T15:41:58+01:00 d/patches: Refresh patches - - - - - b5de3ce3 by Mathieu Malaterre at 2024-01-11T16:08:30+01:00 d/changelog: Upload 3.6.8-1 to experimental - - - - - 12 changed files: - ANNOUNCE - CMake/3rdparty.cmake - CMake/GenerateDCMTKConfigure.cmake - CMake/dcmtkPrepare.cmake - INSTALL - VERSION - config/configure - config/configure.in - config/confmod - config/include/dcmtk/config/osconfig.h.in - dcmdata/apps/Makefile.dep - dcmdata/docs/dcm2json.man The diff was not included because it is too large. View it on GitLab: https://salsa.debian.org/med-team/dcmtk/-/compare/0ea5fd8da1ae341de09c6d3b7e52756412d8ee0a...b5de3ce34821fb7526b1c0eabd0f1ffe5fe112e1 -- View it on GitLab: https://salsa.debian.org/med-team/dcmtk/-/compare/0ea5fd8da1ae341de09c6d3b7e52756412d8ee0a...b5de3ce34821fb7526b1c0eabd0f1ffe5fe112e1 You're receiving this email because of your account on salsa.debian.org. ___ debian-med-commit mailing list debian-med-com...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
[med-svn] [Git][med-team/dcmtk][upstream] New upstream version 3.6.8
Mathieu Malaterre pushed to branch upstream at Debian Med / dcmtk Commits: 2ffc893b by Mathieu Malaterre at 2024-01-11T15:40:43+01:00 New upstream version 3.6.8 - - - - - 12 changed files: - ANNOUNCE - CMake/3rdparty.cmake - CMake/GenerateDCMTKConfigure.cmake - CMake/dcmtkPrepare.cmake - INSTALL - VERSION - config/configure - config/configure.in - config/confmod - config/include/dcmtk/config/osconfig.h.in - dcmdata/apps/Makefile.dep - dcmdata/docs/dcm2json.man The diff was not included because it is too large. View it on GitLab: https://salsa.debian.org/med-team/dcmtk/-/commit/2ffc893bd2908fc7292313d53c5bdcee3f2951b1 -- View it on GitLab: https://salsa.debian.org/med-team/dcmtk/-/commit/2ffc893bd2908fc7292313d53c5bdcee3f2951b1 You're receiving this email because of your account on salsa.debian.org. ___ debian-med-commit mailing list debian-med-com...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
Bug#1060442: DCMTK Release 3.6.8 available
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#1056953: marked as pending in gdcm
Control: tag -1 pending Hello, Bug #1056953 in gdcm reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/med-team/gdcm/-/commit/263554ea8b9f71b92542a66a3ccad7936b93185c d/patches: Revert changes breaking binary ABI. Closes: #1056953 (this message was generated automatically) -- Greetings https://bugs.debian.org/1056953
[med-svn] [Git][med-team/gdcm][master] Update debian/series
Mathieu Malaterre pushed to branch master at Debian Med / gdcm Commits: ff202349 by Mathieu Malaterre at 2023-12-07T10:39:39+01:00 Update debian/series - - - - - 1 changed file: - debian/patches/series Changes: = debian/patches/series = @@ -3,3 +3,4 @@ rename-pdf.patch 03_linkvtkdoc.patch 04_multiarch.patch 6631a74c39145b71dedcbe07c43bd6b1631b100d.patch +dircos_rev.patch View it on GitLab: https://salsa.debian.org/med-team/gdcm/-/commit/ff202349a797f1554ee184de2157a8f65ecb945d -- View it on GitLab: https://salsa.debian.org/med-team/gdcm/-/commit/ff202349a797f1554ee184de2157a8f65ecb945d You're receiving this email because of your account on salsa.debian.org. ___ debian-med-commit mailing list debian-med-com...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
[med-svn] [Git][med-team/gdcm] Pushed new tag debian/3.0.22-2
Mathieu Malaterre pushed new tag debian/3.0.22-2 at Debian Med / gdcm -- View it on GitLab: https://salsa.debian.org/med-team/gdcm/-/tree/debian/3.0.22-2 You're receiving this email because of your account on salsa.debian.org. ___ debian-med-commit mailing list debian-med-com...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
[med-svn] [Git][med-team/gdcm] Pushed new tag upstream/3.0.22
Mathieu Malaterre pushed new tag upstream/3.0.22 at Debian Med / gdcm -- View it on GitLab: https://salsa.debian.org/med-team/gdcm/-/tree/upstream/3.0.22 You're receiving this email because of your account on salsa.debian.org. ___ debian-med-commit mailing list debian-med-com...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
[med-svn] [Git][med-team/gdcm] Pushed new tag debian/3.0.22-1
Mathieu Malaterre pushed new tag debian/3.0.22-1 at Debian Med / gdcm -- View it on GitLab: https://salsa.debian.org/med-team/gdcm/-/tree/debian/3.0.22-1 You're receiving this email because of your account on salsa.debian.org. ___ debian-med-commit mailing list debian-med-com...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
[med-svn] [Git][med-team/gdcm][master] 2 commits: d/patches: Revert changes breaking binary ABI. Closes: #1056953
Mathieu Malaterre pushed to branch master at Debian Med / gdcm
Commits:
263554ea by Mathieu Malaterre at 2023-12-07T10:37:06+01:00
d/patches: Revert changes breaking binary ABI. Closes: #1056953
- - - - -
c297d79a by Mathieu Malaterre at 2023-12-07T10:37:33+01:00
d/changelog: Upload 3.0.22-2 to unstable
- - - - -
2 changed files:
- debian/changelog
- + debian/patches/dircos_rev.patch
Changes:
=
debian/changelog
=
@@ -1,3 +1,9 @@
+gdcm (3.0.22-2) unstable; urgency=medium
+
+ * d/patches: Revert changes breaking binary ABI. Closes: #1056953
+
+ -- Mathieu Malaterre Thu, 07 Dec 2023 10:37:28 +0100
+
gdcm (3.0.22-1) unstable; urgency=medium
* Team upload.
=
debian/patches/dircos_rev.patch
=
@@ -0,0 +1,30 @@
+Description: Revert gdcmDirectionCosines destructor change
+Author: Gianfranco Costamagna
+Bug-Debian: https://bugs.debian.org/1056953
+Origin: upstream
+Forwarded: no
+Reviewed-By: Mathieu Malaterre
+Last-Update: 2023-12-07
+
+--- gdcm-3.0.22.orig/Source/MediaStorageAndFileFormat/gdcmDirectionCosines.cxx
gdcm-3.0.22/Source/MediaStorageAndFileFormat/gdcmDirectionCosines.cxx
+@@ -40,6 +40,8 @@ DirectionCosines::DirectionCosines(const
+ Values[5] = dircos[5];
+ }
+
++DirectionCosines::~DirectionCosines() = default;
++
+ void DirectionCosines::Print(std::ostream ) const
+ {
+ os << Values[0] << ",";
+--- gdcm-3.0.22.orig/Source/MediaStorageAndFileFormat/gdcmDirectionCosines.h
gdcm-3.0.22/Source/MediaStorageAndFileFormat/gdcmDirectionCosines.h
+@@ -29,7 +29,7 @@ public:
+ DirectionCosines(const double dircos[6]);
+ // Cannot get the following signature to be wrapped with swig...
+ //DirectionCosines(const double *dircos = 0 );
+- ~DirectionCosines() = default;
++ ~DirectionCosines();
+
+ /// Print
+ void Print(std::ostream &) const;
View it on GitLab:
https://salsa.debian.org/med-team/gdcm/-/compare/15bb6e93f5d503d605f3a76ef085607fe97d34d3...c297d79acfd90e26a0fa9b3049accd90b74df845
--
View it on GitLab:
https://salsa.debian.org/med-team/gdcm/-/compare/15bb6e93f5d503d605f3a76ef085607fe97d34d3...c297d79acfd90e26a0fa9b3049accd90b74df845
You're receiving this email because of your account on salsa.debian.org.
___
debian-med-commit mailing list
debian-med-com...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
Bug#1056048: Acknowledgement (Memory leak in dcm2json)
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
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
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)
Current work-around: % dcmconv +ti RTStruct_VRDSAsVRUN.dcm - | dcm2json - output.json
Bug#1055872: Acknowledgement (CP-2275: "NaN", "+Infinity" and "-Infinity")
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
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"
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
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)
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
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.
> 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 :)
[med-svn] [Git][med-team/dcmtk] Pushed new tag debian/3.6.8_git20231027.1549d8c-2
Mathieu Malaterre pushed new tag debian/3.6.8_git20231027.1549d8c-2 at Debian Med / dcmtk -- View it on GitLab: https://salsa.debian.org/med-team/dcmtk/-/tree/debian/3.6.8_git20231027.1549d8c-2 You're receiving this email because of your account on salsa.debian.org. ___ debian-med-commit mailing list debian-med-com...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
[med-svn] [Git][med-team/dcmtk][debian/experimental] 2 commits: d/patches: Fix install path for docs
Mathieu Malaterre pushed to branch debian/experimental at Debian Med / dcmtk
Commits:
2318cc44 by Mathieu Malaterre at 2023-11-06T12:04:04+01:00
d/patches: Fix install path for docs
- - - - -
0ea5fd8d by Mathieu Malaterre at 2023-11-06T12:07:55+01:00
d/changelog: Upload 3.6.8~git20231027.1549d8c-2 to experimental
- - - - -
4 changed files:
- debian/changelog
- debian/dcmtk-doc.doc-base
- debian/dcmtk-doc.docs
- debian/patches/remove_version.patch
Changes:
=
debian/changelog
=
@@ -1,3 +1,9 @@
+dcmtk (3.6.8~git20231027.1549d8c-2) experimental; urgency=medium
+
+ * d/patches: Fix install path for docs
+
+ -- Mathieu Malaterre Mon, 06 Nov 2023 12:07:47 +0100
+
dcmtk (3.6.8~git20231027.1549d8c-1) experimental; urgency=medium
* New upstream version 3.6.8~git20231027.1549d8c
=
debian/dcmtk-doc.doc-base
=
@@ -8,5 +8,5 @@ Abstract: This manual comprises the complete on-line
documentation for the
Section: Science/Medicine
Format: HTML
-Index: /usr/share/doc/dcmtk/dcmtk/html/index.html
-Files: /usr/share/doc/dcmtk/dcmtk/html/*
+Index: /usr/share/doc/dcmtk/dcmtk-3.6.8/html/index.html
+Files: /usr/share/doc/dcmtk/dcmtk-3.6.8/html/*
=
debian/dcmtk-doc.docs
=
@@ -1 +1 @@
-usr/share/doc/dcmtk/
+usr/share/doc/dcmtk-*/
=
debian/patches/remove_version.patch
=
@@ -7,16 +7,14 @@ Index: dcmtk/CMake/GenerateDCMTKConfigure.cmake
===
--- dcmtk.orig/CMake/GenerateDCMTKConfigure.cmake
+++ dcmtk/CMake/GenerateDCMTKConfigure.cmake
-@@ -180,9 +180,9 @@ else()
+@@ -180,8 +180,8 @@ else()
# Modify the installation paths for configuration files, data files and
documents
# by adding a subdirectory with the DCMTK name and version number
- set(CMAKE_INSTALL_FULL_SYSCONFDIR
"${CMAKE_INSTALL_FULL_SYSCONFDIR}/dcmtk-${DCMTK_COMPLETE_PACKAGE_VERSION}")
- set(CMAKE_INSTALL_FULL_DATADIR
"${CMAKE_INSTALL_FULL_DATADIR}/dcmtk-${DCMTK_COMPLETE_PACKAGE_VERSION}")
-- set(CMAKE_INSTALL_FULL_DOCDIR
"${CMAKE_INSTALL_FULL_DOCDIR}-${DCMTK_COMPLETE_PACKAGE_VERSION}")
+ set(CMAKE_INSTALL_FULL_SYSCONFDIR "${CMAKE_INSTALL_FULL_SYSCONFDIR}/dcmtk")
+ set(CMAKE_INSTALL_FULL_DATADIR "${CMAKE_INSTALL_FULL_DATADIR}/dcmtk")
-+ set(CMAKE_INSTALL_FULL_DOCDIR "${CMAKE_INSTALL_FULL_DOCDIR}")
+ set(CMAKE_INSTALL_FULL_DOCDIR
"${CMAKE_INSTALL_FULL_DOCDIR}-${DCMTK_COMPLETE_PACKAGE_VERSION}")
# These variables are defined as macros in osconfig.h and must end with a
path separator
- set(DCMTK_DEFAULT_CONFIGURATION_DIR "${CMAKE_INSTALL_FULL_SYSCONFDIR}/")
View it on GitLab:
https://salsa.debian.org/med-team/dcmtk/-/compare/65eb9aabe6d249c6dcf34842d5ab6766caf46934...0ea5fd8da1ae341de09c6d3b7e52756412d8ee0a
--
View it on GitLab:
https://salsa.debian.org/med-team/dcmtk/-/compare/65eb9aabe6d249c6dcf34842d5ab6766caf46934...0ea5fd8da1ae341de09c6d3b7e52756412d8ee0a
You're receiving this email because of your account on salsa.debian.org.
___
debian-med-commit mailing list
debian-med-com...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
[med-svn] [Git][med-team/dcmtk] Pushed new tag upstream/3.6.8_git20231027.1549d8c
Mathieu Malaterre pushed new tag upstream/3.6.8_git20231027.1549d8c at Debian Med / dcmtk -- View it on GitLab: https://salsa.debian.org/med-team/dcmtk/-/tree/upstream/3.6.8_git20231027.1549d8c You're receiving this email because of your account on salsa.debian.org. ___ debian-med-commit mailing list debian-med-com...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
[med-svn] [Git][med-team/dcmtk] Pushed new tag debian/3.6.8_git20231027.1549d8c-1
Mathieu Malaterre pushed new tag debian/3.6.8_git20231027.1549d8c-1 at Debian Med / dcmtk -- View it on GitLab: https://salsa.debian.org/med-team/dcmtk/-/tree/debian/3.6.8_git20231027.1549d8c-1 You're receiving this email because of your account on salsa.debian.org. ___ debian-med-commit mailing list debian-med-com...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
[med-svn] [Git][med-team/dcmtk][upstream] New upstream version 3.6.8~git20231027.1549d8c
Mathieu Malaterre pushed to branch upstream at Debian Med / dcmtk Commits: 53c26ca1 by Mathieu Malaterre at 2023-11-06T09:21:23+01:00 New upstream version 3.6.8~git20231027.1549d8c - - - - - 30 changed files: - CMake/3rdparty.cmake - CMake/FindICU.cmake - CMake/GenerateDCMTKConfigure.cmake - CMake/dcmtk.pc.in - CMake/dcmtkMacros.cmake - CMake/dcmtkPrepare.cmake - CMake/dcmtkTryRun.cmake - CMake/dcmtkUseAndroidSDK.cmake - CMake/dcmtkUseWine.cmake - CMake/osconfig.h.in - CMakeLists.txt - COPYRIGHT - INSTALL - config/configure - config/configure.in - config/confmod - config/docs/cxx11.dox - config/docs/macros.txt - config/include/dcmtk/config/osconfig.h.in - dcmdata/apps/dcm2json.cc - dcmdata/apps/dcm2pdf.cc - dcmdata/apps/dcm2xml.cc - dcmdata/apps/dcmconv.cc - dcmdata/apps/dcmcrle.cc - dcmdata/apps/dcmdrle.cc - dcmdata/apps/dcmdump.cc - dcmdata/apps/dump2dcm.cc - dcmdata/apps/img2dcm.cc - dcmdata/apps/mdfconen.cc - dcmdata/apps/xml2dcm.cc The diff was not included because it is too large. View it on GitLab: https://salsa.debian.org/med-team/dcmtk/-/commit/53c26ca1d802b9c97a2141b7447044da094fbfab -- View it on GitLab: https://salsa.debian.org/med-team/dcmtk/-/commit/53c26ca1d802b9c97a2141b7447044da094fbfab You're receiving this email because of your account on salsa.debian.org. ___ debian-med-commit mailing list debian-med-com...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
[med-svn] [Git][med-team/dcmtk][debian/experimental] 5 commits: New upstream version 3.6.8~git20231027.1549d8c
Mathieu Malaterre pushed to branch debian/experimental at Debian Med / dcmtk Commits: 53c26ca1 by Mathieu Malaterre at 2023-11-06T09:21:23+01:00 New upstream version 3.6.8~git20231027.1549d8c - - - - - b516ac9b by Mathieu Malaterre at 2023-11-06T09:21:23+01:00 Update upstream source from tag upstream/3.6.8_git20231027.1549d8c Update to upstream version 3.6.8~git20231027.1549d8c with Debian dir fc782cdbeb7763e3df9730ee289589274a82634b - - - - - f0f9dfaa by Mathieu Malaterre at 2023-11-06T10:25:50+01:00 d/patches: Remove version from install paths - - - - - 079527fb by Mathieu Malaterre at 2023-11-06T10:27:28+01:00 d/rules: Start using LTO - - - - - 65eb9aab by Mathieu Malaterre at 2023-11-06T10:28:25+01:00 d/changelog: Upload 3.6.8~git20231027.1549d8c-1 to experimental - - - - - 30 changed files: - CMake/3rdparty.cmake - CMake/FindICU.cmake - CMake/GenerateDCMTKConfigure.cmake - CMake/dcmtk.pc.in - CMake/dcmtkMacros.cmake - CMake/dcmtkPrepare.cmake - CMake/dcmtkTryRun.cmake - CMake/dcmtkUseAndroidSDK.cmake - CMake/dcmtkUseWine.cmake - CMake/osconfig.h.in - CMakeLists.txt - COPYRIGHT - INSTALL - config/configure - config/configure.in - config/confmod - config/docs/cxx11.dox - config/docs/macros.txt - config/include/dcmtk/config/osconfig.h.in - dcmdata/apps/dcm2json.cc - dcmdata/apps/dcm2pdf.cc - dcmdata/apps/dcm2xml.cc - dcmdata/apps/dcmconv.cc - dcmdata/apps/dcmcrle.cc - dcmdata/apps/dcmdrle.cc - dcmdata/apps/dcmdump.cc - dcmdata/apps/dump2dcm.cc - dcmdata/apps/img2dcm.cc - dcmdata/apps/mdfconen.cc - dcmdata/apps/xml2dcm.cc The diff was not included because it is too large. View it on GitLab: https://salsa.debian.org/med-team/dcmtk/-/compare/e6af2e43d57b8d399274e2e3cc8e5817aedac53d...65eb9aabe6d249c6dcf34842d5ab6766caf46934 -- View it on GitLab: https://salsa.debian.org/med-team/dcmtk/-/compare/e6af2e43d57b8d399274e2e3cc8e5817aedac53d...65eb9aabe6d249c6dcf34842d5ab6766caf46934 You're receiving this email because of your account on salsa.debian.org. ___ debian-med-commit mailing list debian-med-com...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
Bug#1055276: Acknowledgement (Valgrind does not read properly DWARF5 as generated by Clang14)
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
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==
dpkg: error processing archive /var/cache/apt/archives/usr-is-merged_38_all.deb (--unpack):
Hi folks, Would anyone know what to do with perotto.d.n ? Thanks Here is what I get today: % sessionid=$(schroot -b -c sid) % dd-schroot-cmd -c $sessionid apt-get update % dd-schroot-cmd -c $sessionid apt-get upgrade [..] Preparing to unpack .../usr-is-merged_38_all.deb ... ** * * The usr-is-merged package cannot be installed because this system does * not have a merged /usr. * * Please install the usrmerge package to convert this system to merged-/usr. * * For more information please read https://wiki.debian.org/UsrMerge. * ** dpkg: error processing archive /var/cache/apt/archives/usr-is-merged_38_all.deb (--unpack): new usr-is-merged package pre-installation script subprocess returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/usr-is-merged_38_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Command apt-get --assume-yes -o Dpkg::Options::=--force-confnew upgrade exited with exit code 1.
[med-svn] [Git][med-team/charls] Pushed new tag debian/2.4.2-2
Mathieu Malaterre pushed new tag debian/2.4.2-2 at Debian Med / charls -- View it on GitLab: https://salsa.debian.org/med-team/charls/-/tree/debian/2.4.2-2 You're receiving this email because of your account on salsa.debian.org. ___ debian-med-commit mailing list debian-med-com...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
[med-svn] [Git][med-team/charls][master] 4 commits: d/maintscript: Remove leftover
Mathieu Malaterre pushed to branch master at Debian Med / charls
Commits:
990d2728 by Mathieu Malaterre at 2023-10-30T15:54:38+01:00
d/maintscript: Remove leftover
- - - - -
70e94213 by Mathieu Malaterre at 2023-10-30T15:56:10+01:00
d/rules: Migrate to ninja build
- - - - -
b6d8467a by Mathieu Malaterre at 2023-10-30T15:56:31+01:00
d/control: Bump Std-Vers to 4.6.2 no changes needed
- - - - -
29c05755 by Mathieu Malaterre at 2023-10-30T15:57:38+01:00
d/changelog: Upload 2.4.2-2 to unstable
- - - - -
4 changed files:
- debian/changelog
- debian/control
- − debian/libcharls-dev.maintscript
- debian/rules
Changes:
=
debian/changelog
=
@@ -1,3 +1,12 @@
+charls (2.4.2-2) unstable; urgency=medium
+
+ * Team upload.
+ * d/maintscript: Remove leftover
+ * d/rules: Migrate to ninja build
+ * d/control: Bump Std-Vers to 4.6.2 no changes needed
+
+ -- Mathieu Malaterre Mon, 30 Oct 2023 15:56:47 +0100
+
charls (2.4.2-1) unstable; urgency=medium
* Team upload.
=
debian/control
=
@@ -4,9 +4,8 @@ Uploaders: Andreas Tille ,
Shayan Doust
Section: science
Priority: optional
-Build-Depends: cmake,
- debhelper-compat (= 13)
-Standards-Version: 4.6.1
+Build-Depends: cmake, debhelper-compat (= 13), ninja-build
+Standards-Version: 4.6.2
Vcs-Browser: https://salsa.debian.org/med-team/charls
Vcs-Git: https://salsa.debian.org/med-team/charls.git
Homepage: https://github.com/team-charls/charls
@@ -16,8 +15,7 @@ Package: libcharls-dev
Architecture: any
Multi-Arch: same
Section: libdevel
-Depends: libcharls2 (= ${binary:Version}),
- ${misc:Depends}
+Depends: libcharls2 (= ${binary:Version}), ${misc:Depends}
Breaks: libdcmtk-dev (<< 3.6.5-1~)
Replaces: libdcmtk-dev (<< 3.6.5-1~)
Description: Implementation of the JPEG-LS standard (development libraries)
@@ -36,8 +34,7 @@ Package: libcharls2
Architecture: any
Multi-Arch: same
Section: libs
-Depends: ${misc:Depends},
- ${shlibs:Depends}
+Depends: ${misc:Depends}, ${shlibs:Depends}
Pre-Depends: ${misc:Pre-Depends}
Description: Implementation of the JPEG-LS standard
CharLS is an optimized implementation of the JPEG-LS standard for lossless and
=
debian/libcharls-dev.maintscript deleted
=
@@ -1,2 +0,0 @@
-# See #971425, #971431 & #971435:
-dir_to_symlink /usr/include/CharLS /usr/include/charls 2.1.0+dfsg-6~
libcharls-dev
=
debian/rules
=
@@ -15,7 +15,7 @@ CMAKE_EXTRA_FLAGS += \
-DCHARLS_PEDANTIC_WARNINGS:BOOL=ON
%:
- dh $@ --buildsystem=cmake
+ dh $@ --buildsystem=cmake+ninja
override_dh_auto_configure:
dh_auto_configure -- $(CMAKE_EXTRA_FLAGS)
View it on GitLab:
https://salsa.debian.org/med-team/charls/-/compare/d24a8a71382d8b0da459b2fb154281ec7de2b00c...29c05755886a12c8d43e390c88ac1f07b17e4034
--
View it on GitLab:
https://salsa.debian.org/med-team/charls/-/compare/d24a8a71382d8b0da459b2fb154281ec7de2b00c...29c05755886a12c8d43e390c88ac1f07b17e4034
You're receiving this email because of your account on salsa.debian.org.
___
debian-med-commit mailing list
debian-med-com...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
[med-svn] [Git][med-team/charls] Pushed new tag debian/2.4.2-1
Mathieu Malaterre pushed new tag debian/2.4.2-1 at Debian Med / charls -- View it on GitLab: https://salsa.debian.org/med-team/charls/-/tree/debian/2.4.2-1 You're receiving this email because of your account on salsa.debian.org. ___ debian-med-commit mailing list debian-med-com...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
Bug#1054696: marked as pending in gdcm
Control: tag -1 pending Hello, Bug #1054696 in gdcm reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/med-team/gdcm/-/commit/9142bd4db25a4375de6c8f38e30843e0c7eea6b3 d/patches: Fix compilation with charls. Closes: #1054696 (this message was generated automatically) -- Greetings https://bugs.debian.org/1054696
[med-svn] [Git][med-team/gdcm][upstream] New upstream version 3.0.22
Mathieu Malaterre pushed to branch upstream at Debian Med / gdcm Commits: 5c264060 by Mathieu Malaterre at 2023-10-30T15:26:41+01:00 New upstream version 3.0.22 - - - - - 30 changed files: - + .clang-tidy - − .gitignore - − .gitmodules - Applications/Cxx/gdcmanon.cxx - Applications/Cxx/gdcmclean.cxx - Applications/Cxx/gdcmconv.cxx - Applications/Cxx/gdcmdump.cxx - Applications/Cxx/gdcmgendir.cxx - Applications/Cxx/gdcmpap3.cxx - Applications/Cxx/gdcmscanner.cxx - Applications/Cxx/gdcmtar.cxx - CMakeLists.txt - Examples/Cxx/DiscriminateVolume.cxx - Examples/Cxx/DumpADAC.cxx - Examples/Cxx/DumpExamCard.cxx - Examples/Cxx/DumpImageHeaderInfo.cxx - Examples/Cxx/DumpPhilipsECHO.cxx - Examples/Cxx/DumpSiemensBase64.cxx - Examples/Cxx/DumpToshibaDTI.cxx - Examples/Cxx/DumpToshibaDTI2.cxx - Examples/Cxx/FixJAIBugJPEGLS.cxx - Examples/Cxx/GetSubSequenceData.cxx - Examples/Cxx/LargeVRDSExplicit.cxx - Examples/Cxx/ReadExplicitLengthSQIVR.cxx - Examples/Cxx/VolumeSorter.cxx - Examples/Cxx/pmsct_rgb1.cxx - Examples/Cxx/rle2img.cxx - Source/Common/CMakeLists.txt - Source/Common/gdcmASN1.cxx - Source/Common/gdcmBase64.cxx The diff was not included because it is too large. View it on GitLab: https://salsa.debian.org/med-team/gdcm/-/commit/5c26406000857ed370af14deb81fa87d5a430f8b -- View it on GitLab: https://salsa.debian.org/med-team/gdcm/-/commit/5c26406000857ed370af14deb81fa87d5a430f8b You're receiving this email because of your account on salsa.debian.org. ___ debian-med-commit mailing list debian-med-com...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
[med-svn] [Git][med-team/gdcm][master] 4 commits: New upstream version 3.0.22
Mathieu Malaterre pushed to branch master at Debian Med / gdcm Commits: 5c264060 by Mathieu Malaterre at 2023-10-30T15:26:41+01:00 New upstream version 3.0.22 - - - - - 6057456e by Mathieu Malaterre at 2023-10-30T15:26:41+01:00 Update upstream source from tag upstream/3.0.22 Update to upstream version 3.0.22 with Debian dir 10290e56513b1b561663d612ef2a54d3d3bd4158 - - - - - 9142bd4d by Mathieu Malaterre at 2023-10-30T15:31:48+01:00 d/patches: Fix compilation with charls. Closes: #1054696 - - - - - 15bb6e93 by Mathieu Malaterre at 2023-10-30T15:37:05+01:00 d/changelog: Upload 3.0.22-1 to unstable - - - - - 30 changed files: - + .clang-tidy - − .gitignore - − .gitmodules - Applications/Cxx/gdcmanon.cxx - Applications/Cxx/gdcmclean.cxx - Applications/Cxx/gdcmconv.cxx - Applications/Cxx/gdcmdump.cxx - Applications/Cxx/gdcmgendir.cxx - Applications/Cxx/gdcmpap3.cxx - Applications/Cxx/gdcmscanner.cxx - Applications/Cxx/gdcmtar.cxx - CMakeLists.txt - Examples/Cxx/DiscriminateVolume.cxx - Examples/Cxx/DumpADAC.cxx - Examples/Cxx/DumpExamCard.cxx - Examples/Cxx/DumpImageHeaderInfo.cxx - Examples/Cxx/DumpPhilipsECHO.cxx - Examples/Cxx/DumpSiemensBase64.cxx - Examples/Cxx/DumpToshibaDTI.cxx - Examples/Cxx/DumpToshibaDTI2.cxx - Examples/Cxx/FixJAIBugJPEGLS.cxx - Examples/Cxx/GetSubSequenceData.cxx - Examples/Cxx/LargeVRDSExplicit.cxx - Examples/Cxx/ReadExplicitLengthSQIVR.cxx - Examples/Cxx/VolumeSorter.cxx - Examples/Cxx/pmsct_rgb1.cxx - Examples/Cxx/rle2img.cxx - Source/Common/CMakeLists.txt - Source/Common/gdcmASN1.cxx - Source/Common/gdcmBase64.cxx The diff was not included because it is too large. View it on GitLab: https://salsa.debian.org/med-team/gdcm/-/compare/afe4d3c3e7e5717d1574819f51acf3c8b654b0e5...15bb6e93f5d503d605f3a76ef085607fe97d34d3 -- View it on GitLab: https://salsa.debian.org/med-team/gdcm/-/compare/afe4d3c3e7e5717d1574819f51acf3c8b654b0e5...15bb6e93f5d503d605f3a76ef085607fe97d34d3 You're receiving this email because of your account on salsa.debian.org. ___ debian-med-commit mailing list debian-med-com...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
Upload commands to debomatic-amd64
Dear all,
I am trying to follow documentation from:
* http://debomatic-amd64.debian.net/
and:
* https://deb-o-matic.readthedocs.io/en/stable/upload.html#prepare-command-files
Which does not seems to be working for me today;
% dcut -U debomatic jxl.commands
usage: dcut [-h] [-d] [-f] [-c FILE] [-m MAINTAINER] [-k KEYID] [-S]
[-O FILENAME] [-P] [-s] [-v]
[HOST]
{debomatic-binnmu,debomatic-builddep,debomatic-kill,debomatic-porter,debomatic-rebuild,debomatic-rm}
...
dcut: error: argument
{debomatic-binnmu,debomatic-builddep,debomatic-kill,debomatic-porter,debomatic-rebuild,debomatic-rm}:
invalid choice: 'jxl.commands' (choose from 'debomatic-binnmu',
'debomatic-builddep', 'debomatic-kill', 'debomatic-porter',
'debomatic-rebuild', 'debomatic-rm')
Would anyone spot the issue ?
Thanks
For reference:
% cat /etc/dput.d/profiles/debomatic.json
{
"allow_dcut": true,
"meta": "debomatic",
"fqdn": "debomatic-amd64.debian.net",
"incoming": "/srv/debomatic-amd64",
"login": "debomatic",
"method": "sftp",
"check-debs": { "skip": true }
}
% apt-cache policy dput-ng
dput-ng:
Installed: 1.35+deb12u1
Candidate: 1.35+deb12u1
Version table:
*** 1.35+deb12u1 500
500 http://deb.debian.org/debian bookworm/main amd64 Packages
500 http://deb.debian.org/debian bookworm/main i386 Packages
100 /var/lib/dpkg/status
% 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
Bug#1054149: manpages-dev: Bizarre rendering of pointers (restrict .n)
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
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
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
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#1053866: transition: jpeg-xl
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";
[med-svn] [Git][med-team/charls] Pushed new tag upstream/2.4.2
Mathieu Malaterre pushed new tag upstream/2.4.2 at Debian Med / charls -- View it on GitLab: https://salsa.debian.org/med-team/charls/-/tree/upstream/2.4.2 You're receiving this email because of your account on salsa.debian.org. ___ debian-med-commit mailing list debian-med-com...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
[med-svn] [Git][med-team/charls] Pushed new tag upstream/2.4.1
Mathieu Malaterre pushed new tag upstream/2.4.1 at Debian Med / charls -- View it on GitLab: https://salsa.debian.org/med-team/charls/-/tree/upstream/2.4.1 You're receiving this email because of your account on salsa.debian.org. ___ debian-med-commit mailing list debian-med-com...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
[med-svn] [Git][med-team/charls] Pushed new tag debian/2.4.1-1
Mathieu Malaterre pushed new tag debian/2.4.1-1 at Debian Med / charls -- View it on GitLab: https://salsa.debian.org/med-team/charls/-/tree/debian/2.4.1-1 You're receiving this email because of your account on salsa.debian.org. ___ debian-med-commit mailing list debian-med-com...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
Bug#1051905: jpeg-xl: Please add support for Loongarch
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#1051905: jpeg-xl: Please add support for Loongarch
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
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
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#1053641: transition: libavif
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:
Control: tags -1 wontfix GCC-13 works as expected. Turns out to be a UB case in highway source code. Closing
Bug#1050933:
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
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#1052677: Fixed in 1.0.7-1
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#1052677: Fixed in 1.0.7-1
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
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#1051384: bookworm-pu: package highway/1.0.3-3
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)
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#1033656: closed by Debian FTP Masters (reply to Mathieu Malaterre ) (Bug#1033656: fixed in highway 1.0.7-1)
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.
[valgrind] [Bug 461074] valgrind: m_debuginfo/readdwarf.c:2396 (copy_convert_CfiExpr_tree): Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.
https://bugs.kde.org/show_bug.cgi?id=461074 --- Comment #7 from Mathieu Malaterre --- (In reply to Mark Wielaard from comment #4) > Thanks, so that is in libhwy_contrib.so.1.0.7 which is > https://packages.debian.org/sid/libhwy1 and can be downloaded through > http://ftp.debian.org/debian/pool/main/h/highway/libhwy1_1.0.7-7_arm64.deb > > Without an arm64 debian setup trying to unpack that and looking for the any > DW_CFA expressions with suspecious DW_OP expressions might be helpful. Just fyi % curl -O http://ftp.debian.org/debian/pool/main/h/highway/libhwy1_1.0.7-7_arm64.deb % ar x libhwy1_1.0.7-7_arm64.deb % tar tvf data.tar.xz [...] -rw-r--r-- root/root 2295800 2023-09-15 11:47 ./usr/lib/aarch64-linux-gnu/libhwy_contrib.so.1.0.7 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 461074] valgrind: m_debuginfo/readdwarf.c:2396 (copy_convert_CfiExpr_tree): Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.
https://bugs.kde.org/show_bug.cgi?id=461074 --- Comment #6 from Mathieu Malaterre --- Created attachment 161747 --> https://bugs.kde.org/attachment.cgi?id=161747=edit % valgrind --debug-dump=frames ./fails >& /tmp/frames.txt -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 461074] valgrind: m_debuginfo/readdwarf.c:2396 (copy_convert_CfiExpr_tree): Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.
https://bugs.kde.org/show_bug.cgi?id=461074 --- Comment #3 from Mathieu Malaterre --- (In reply to Mark Wielaard from comment #2) > The first issue seems to be because we cannot handle the CFI from this > libamath.so library. > For the second it isn't clear which library causes the issue. Could you > rerun with -v ? Sorry for being sloppy here. Here you: % valgrind -v ./fails ==284860== Memcheck, a memory error detector ==284860== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==284860== Using Valgrind-3.19.0-8d3c8034b8-20220411 and LibVEX; rerun with -h for copyright info ==284860== Command: ./fails ==284860== --284860-- Valgrind options: --284860---v --284860-- Contents of /proc/version: --284860-- Linux version 5.10.0-25-arm64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.191-1 (2023-08-16) --284860-- --284860-- Arch and hwcaps: ARM64, LittleEndian, v8 --284860-- Page sizes: currently 4096, max supported 65536 --284860-- Valgrind library directory: /usr/libexec/valgrind --284860-- Reading syms from /home/malat/pr110643/fails --284860-- Reading syms from /lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 --284860-- Considering /usr/lib/debug/.build-id/e3/1f8e686f102995033b5b17cc829c67c7efbc90.debug .. --284860-- .. build-id is valid --284860-- Reading syms from /usr/libexec/valgrind/memcheck-arm64-linux --284860--object doesn't have a symbol table --284860--object doesn't have a dynamic symbol table --284860-- Scheduler: using generic scheduler lock implementation. --284860-- Reading suppressions file: /usr/libexec/valgrind/default.supp ==284860== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-284860-by-malat-on-??? ==284860== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-284860-by-malat-on-??? ==284860== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-284860-by-malat-on-??? ==284860== ==284860== TO CONTROL THIS PROCESS USING vgdb (which you probably ==284860== don't want to do, unless you know exactly what you're doing, ==284860== or are doing some strange experiment): ==284860== /usr/bin/vgdb --pid=284860 ...command... ==284860== ==284860== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==284860== /path/to/gdb ./fails ==284860== and then give GDB the following command ==284860== target remote | /usr/bin/vgdb --pid=284860 ==284860== --pid is optional if only one valgrind process is running ==284860== --284860-- REDIR: 0x401c080 (ld-linux-aarch64.so.1:strlen) redirected to 0x580bb9f4 (???) --284860-- REDIR: 0x401b7c0 (ld-linux-aarch64.so.1:strcmp) redirected to 0x580bba48 (???) --284860-- REDIR: 0x401b700 (ld-linux-aarch64.so.1:index) redirected to 0x580bba1c (???) --284860-- Reading syms from /usr/libexec/valgrind/vgpreload_core-arm64-linux.so --284860--object doesn't have a symbol table --284860-- Reading syms from /usr/libexec/valgrind/vgpreload_memcheck-arm64-linux.so --284860--object doesn't have a symbol table --284860-- Reading syms from /usr/lib/aarch64-linux-gnu/libhwy_contrib.so.1.0.7 --284860--object doesn't have a symbol table --284860-- 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: ==284860==at 0x58040D44: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860==by 0x58040E93: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860==by 0x58040FFB: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860==by 0x580C3BB7: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860==by 0x580C3D53: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860==by 0x580C91E3: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860==by 0x5807A497: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860==by 0x5806F613: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860==by 0x5809E927: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860==by 0x580AB983: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860==by 0x5809AA1B: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860==by 0x5809647F: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860==by 0x5809882F: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860==by 0x580DFC5F: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) ==284860==by 0x: ??? sched status: running_tid=1 Thread 1: status = VgTs_Runnable syscall 222 (lwpid 284860) ==284860==at 0x401AB6C: __mmap64 (mmap64.c:58) ==284860==by 0x401AB6C: mmap (mmap64.c:46) ==284860==by 0x40066F3: _dl_map_segments (dl-map-segments.h:139) ==284860==by 0x40066F3: _dl_map_object_from_fd (dl-load.c:1268) ==284860==by 0x40078BF: _dl_map_object (dl-load.c:2272)
