Hi Paul, > > Unfortunately, I cannot find a clear guide about how I could fix this > > issue, as unstable has already accepted two new releases > > (orthanc-wsi_3.1+dfsg-1 and orthanc-wsi_3.2+dfsg-1) [2]. > > If I read that other bug correctly, the changed path in dcmtk broke > orthanc. So, the right binary package of src:dcmtk should declare that > with a *versioned* Breaks on the right binary package of src:orthanc. It > seems that orthanc (and thus orthanc-wsi) from unstable works in > unstable (at least on amd64 and some other architectures, it seems > broken on arm64, loong64, ppc64el and s390x), but not with the older > src:dcmtk in testing. So the right package from src:orthanc should have > a *versioned* Depends on the right package from src:dcmtk.
Thanks so much for your explanations! Unfortunately, I am totally lost here. Even though I understand the general philosophy, I still do not see what I must do. Should I upload to testing? If yes, how to do so, since I am only familiar with unstable? Must also orthanc-wsi and dcmtk be updated, given that the issue seems to lie in liborthancframework (part of src:orthanc)? And what about the fact that orthanc-wsi_3.2+dfsg-1 is already there, while it seems like that it is orthanc-wsi_3.0+dfsg-1 for which a fix is expected? Sorry, I am unable to solve this without further instructions and a full example... Kind Regards, Sébastien-