[Debian-med-packaging] Bug#919742: orthanc-wsi FTBFS 'class GlobalDcmDataDictionary' has no member named 'unlock'

[peter green]

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.