Dear all,
> Indeed, and there is a simple fix too, which has been uploaded to
> experimental only so far:
yes, there is a simple fix (that disables the error), but there is also a more
fundamental fix that (hopefully) solves the issue at its core:
https://git.dcmtk.org/?p=dcmtk.git;a=commi
Hi Mathieu et al.,
it seems that the stack problem is limited to the "drttest" tool, which is not
really needed for a Linux distribution like Debian.
Anyway, in the meantime, I have revised the implementation of this test tool to
avoid the creation of huge data structures on the stack. See this
Mathieu,
> Yes, this is what I defined as "support will be equivalent".
>
> Further detailed at:
>
> https://salsa.debian.org/med-team/dcmtk/-/commit/a533a4acb57242e8c9e9f011e3
> ba083c8382da97#92c53ca292f6a209c5328fba1c6a1801e28e51c3_151_163
thank you for pointing me (again) to the relevant do
Hi Mathieu
> I've removed explicit usage of ICU, since support will be equivalent
> when using stdlibc (iconv), with the added bonus that we remove a
> dependency to ICU.
I'm not sure whether "stdlibc (iconv)" really supports all DICOM character
sets, e.g. "ISO 2022 IR 87" and "ISO 2022 IR 159"
> Could you please clarify the following statement then:
>
> [...]
> As far as I understand it ISO 2022 JP is also a set containing
> multiple character sets that can be switched via escape sequences. The
> ICU handles these escape sequences internally whereas the libiconv
> doesn't. This is why t
> I see that people also directly called the cleanup API directly, eg:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=890127
> -> https://hg.mozilla.org/mozilla-central/rev/c77439f57dfc
This was also my proposal to the author of this code, i.e. the ICU integration
into DCMTK. For other purpose
I can confirm that DCMTK with ICU enabled does not support the same set of
DICOM character sets (i.e. all) in contrast to the original implementation
based on libiconv. That's the reason why I personally would still prefer
libiconv over the other two character set options in DCMTK.
By the way,
> The DCMTK library seems to leaves memory around after the end of the
> process.
Thank you for the report. I talked to the co-developer who introduced support
for ICU to the DCMTK. He pointed me to the following discussion on ICU:
https://sourceforge.net/p/icu/mailman/icu-support/thread/51379D6E
Hi Andreas,
> > 05_performance.patch [...]
> > 04_Fixed-OFoptional-by-introducing-OFalign.patch [...]
> I've just removed these patches[1]
thank you for your quick response and for fixing this.
>> Is there a defined process of checking whether patches are still needed
>> for a new upstream rele
By the way, there are still patches enabled for the most recent Debian package
that are no longer needed, e.g.
05_performance.patch is not needed because of this commit: http://
git.dcmtk.org/?p=dcmtk.git;a=commit;h=8df1f5e517b8629ae09088d0935c2a8dd333c76f
04_Fixed-OFoptional-by-introducing-OFal
Hi Helmut,
>> I just tested it and it seems to work. What do you think?
> I fear that I lack CMake experience and I didn't know that this was
> possible. Still if it works at all, it looks like the better solution
> indeed.
I'm also not an expert when it comes to CMake "magic"...
> It seems tha
Helmut,
> While trying to make dcmtk cross buildable, I found a little bug in the
> build system. It assumes that CMAKE_SYSTEM_VERSION is non-empty. This is
> true most of the time, but CMakeDetermineSyste.cmake says:
>
> # CMAKE_SYSTEM_VERSION - on unix this is uname -r, for windows it is empty
Fixed by this commit:
http://git.dcmtk.org/?p=dcmtk.git;a=commitdiff;h=875181643364142274b105f9b655649f08e4db8c
... which is also part of the recently released DCMTK 3.6.2.
The following commit fixes this issue:
http://git.dcmtk.org/?p=dcmtk.git;a=commit;h=7a000a8bc84d58fab5368964d49757f7e33036b2
> When executing movescu with explicit incoming port setting it would
> make sense to return a proper error code at least on UNIX. Otherwise
> it is very difficult to detect invalid C-MOVE setup.
This should have been fixed by the the following commits:
http://git.dcmtk.org/?p=dcmtk.git;a=commit;
The current DCMTK Snapshot now supports three alternative character set
conversion libraries: libiconv, libicu and the iconv() function from stdlibc:
http://dcmtk.org/download/dcmtk/snapshot/dcmtk-3.6.1_20170228.tar.gz
It took a little longer than expected... See this commit:
http://git.dcmtk.org/web?p=dcmtk.git;a=commit;h=beaf5a5c24101daeeafa48c375120b16197c9e95
Regards,
Jörg
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@
> Package: dcmtk
> Tags: patch
>
> It would be nice to include this patch for next upload to fix simple
> spelling typos.
Done. I also fixed a couple of other typos.
http://git.dcmtk.org/web?p=dcmtk.git;a=commit;h=d7931db838311e3b07837c130803785bda51d801
Thanks for reporting!
--
To UNSUBS
> dcmtk package is trying to set CMAKE_BUILD_TYPE to Release instead of
> letting the user decide what best to use.
> It would be nice to have an option to override this default, as Debian
> requires specific compilation flags, which conflicts with what
> CMAKE_BUILD_TYPE:Release sets.
> I am atta
> Package: dcmtk
>
> It would be nice to have support for WSI in dcmtk:
>
> $ storescu --call REMOTE localhost 5679 wsi.dcm
> E: No presentation context for: (VLw) 1.2.840.10008.5.1.4.1.1.77.1.6
> E: Store SCU Failed: 0006:0208 DIMSE No valid Presentation Context ID
>
> $ storescu --version
> $
Mathieu,
>> - Are you referring to the "Unknown Tag & Data"?
> Correct (instead of StackSequence).
thank you for the report. There was indeed a bug in the code that prevented
the element name of private tags from being printed.
Here's the commit that fixes this issue:
http://git.dcmtk.org/web
Hi Mathieu,
what exactly do you mean by "Looks odd to me"?
- Which version of the DCMTK are you using?
- Is the "private.dic" file loaded in both cases?
- Are you referring to the "Unknown Tag & Data"?
Jörg
> Package: dcmtk
>
> Looks like something is going on wrong with CP-246 file(s) and dic
Hi Mathieu!
Thank you for the report. This issue has been introduced with this commit
(after DCMTK 3.6.0 release)
http://git.dcmtk.org/web?p=dcmtk.git;a=commit;h=17872db6c2fef53ba4a243fd7425934ed887ee9f
and was just fixed by this one
http://git.dcmtk.org/web?p=dcmtk.git;a=commit;h=6fe9ad
Thank you for the response! The fix is now committed to DCMTK's git repository:
http://git.dcmtk.org/web?p=dcmtk.git;a=commit;h=b1e96e8582895ff1f122d24b9d2cab2a22198873
Regards
Jörg
> tags 706062 pending
> thanks
>
> On Mon, Jun 3, 2013 at 3:39 PM, Jörg Riesmeier wrote:
>
Thank you for the feedback. It seems that I forgot the Presentation State case
:-/ What do you think about the following patch?
http://sprunge.us/iEKF?diff
I will commit the required changes, as soon as I have your (hopefully
positive) feedback :)
Regards,
Jörg
> Looks like a pretty good
Thank you for the suggestion. I just implemented the requested feature with
the following commits:
http://git.dcmtk.org/web?p=dcmtk.git;a=commit;h=0df7cbcbe71fb0ee31ffd5a53ea003b9c1efdb0e
http://git.dcmtk.org/web?p=dcmtk.git;a=commit;h=6826ff093f114c77edaeea320f42a53a07812d66
Regards,
Jörg
> Pa
Thanks for reporting this issue, but it is a known issue that is already
listed in the (still internal) DCMTK bug tracker as Feature #368.
Regards
Jörg
PS: I'm one of the main DCMTK developers and also the person who added
libiconv support to the DCMTK some time ago. Also see this blog posting
DCMTK comes with CharLS library as convenient library. This is in
violation with debian policy §4.13
This is something that has also been fixed by the Fedora people:
https://bugzilla.redhat.com/show_bug.cgi?id=573910#c22
Maybe, it's helpful to check what they have done :-)
--
To UNSUBSCR
This issue has already been solved some time ago for the upstream package:
http://git.dcmtk.org/web?p=dcmtk.git;a=commit;h=12c35ca81e7f01392fb37fe1855bda4428a963fa
Unfortunately, not before but after the release of DCMTK 3.6.0.
Regards,
Joerg
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ
29 matches
Mail list logo
