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-

Reply via email to