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

[Sébastien Jodogne]

Dear Peter,

Many thanks for your contributions!

This week, the Orthanc project released 2 new versions of its core, and
3 plugins were updated as well (including the whole-slide imaging
framework that was released today). Because of this heavy work, I
wasn't able to fix earlier this Debian issue that was reported one week
ago.

The just-released upstream release 0.6 of the WSI framework is now
fully compatible with DCMTK 3.6.4.

This unfortunately means that your patch is not needed anymore... I'm
really sorry about the fact that you spent time trying to fix this
issue on the now outdated upstream version 0.5, just a few hours before
0.6 was officially released.

Regards,
Sébastien-



On sam, 2019-01-26 at 03:44 +0000, peter green wrote:
> 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/orth
> anc-wsi_0.5-2+rpi1.debdiff
> 
> No intent to NMU in Debian.
> 
> _______________________________________________
> Debian-med-packaging mailing list
> Debian-med-packaging at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-p
> ackaging
-- 
Sébastien Jodogne
Mail: s.jodogne at orthanc-labs.com
Web: http://www.orthanc-labs.com/
Twitter: https://twitter.com/sjodogne