tags 919742 +patch thanks Since this seemed to be the last thing blocking the dcmtk transition in raspbian buster I decided to take a look.
It seems that orthanc-wsi has an embedded copy of an old version orthanc, it also build-depends on orthanc-dev, I am not sure if the system orthanc is unused or if the embedded copy is used for some things and the system copy for others. The patches needed are the same as were needed for orthanc as documented in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919193#10 The tricky bit was actually applying them, the embedded copy of orthanc is shipped as a tarball which is copied to locations where the upstream build system detects and unpacks it. I modified debian/rules to unpack, patch and repack the tarball before copying it to where the upstream build system expected it. Unfortunately the upstream build system then rejected it with a md5 mismatch, so I patched the upstream build system to remove the md5 check and to remove automatic downloading of the tarball (for safety since there was no longer any validation of it). While I was doing this I ran into a situation where the clean target was not cleaning up sufficiently so I fixed that too. With these changes I was able to get a succesful build in raspbian buster-staging, a debdiff can be found at https://debdiffs.raspbian.org/main/o/orthanc-wsi/orthanc-wsi_0.5-2+rpi1.debdiff No intent to NMU in Debian.
