Dear Nilesh, Thank so much for your great explanations! They were really useful for me to understand what is happening here.
Dear Étienne, Wow, I am extremely grateful for your resolution... I would never have managed to get it by myself given my lack of experience. I'm obviously fine with your changes (to which I had a look), as they seem to be perfectly in line with Nilesh's explanations. It would indeed be great if you could do the team upload: This would prevent any mishandling of the bullseye branch on my side. Once the team upload is accepted, I will try to fix by myself the three plugin packages by adding the "Built-Using" attribute in their bullseye branch, replicating your process on the main "orthanc" source package. Many thanks again to both of you, Sébastien- On 5/06/21 10:38, Étienne Mollier wrote: > Hi Sébastien, > > Étienne Mollier, on 2021-06-04: >> Sébastien Jodogne, on 2021-06-04: >>> In practice, should I first sync my git repository with the tag >>> "orthanc-1.9.2+dfsg-1", do the modifications and upload to unstable, >>> then merge back my modifications in the mainline of the git repository, >>> and finally upload "orthanc-1.9.3+dfsg-2" to experimental? >> >> As I understand things, again in the context of a revert from to >> 1.9.2+dfsg-1 to 1.9.1+dfsg-1, I would probably checkout the >> 1.9.1+dfsg-1 to get to the state of the package as it was, both >> regarding the upstream and debian branches, then append in >> d/changelog the unmodified content of the 1.9.2+dfsg-1 upload >> and the entry for 1.9.2+really1.9.1+dfsg-1, which should only >> indicate the revert of the package to the state it was in in >> version 1.9.1+dfsg-1, and tag debian/1.9.2+really1.9.1+dfsg-1. >> >> The resulting debdiff between orthanc_1.9.1+dfsg-1.dsc and >> orthanc_1.9.2+really1.9.1+dfsg-1.dsc should, ideally, only show >> the added entries in the changelog. >> >> Note I may not have the best git skills in the world, it just >> sounds like the simplest approach to me. > > I implemented the idea I had in mind in the attached debdiff > against the source code of the orthanc version in testing. Note > that I adjusted a filter on the package version, in order to get > the right upstream version out of the package version in case a > +really field is applied, otherwise the package would fail to > build from source due to attempts to move around libraries with > an 1.9.2 soversion, instead of 1.9.1. In doubt I also ran a > binary debdiff, to make sure there were no other surprises, at > least in terms of file naming. The binary debdiff in attachment > shows no difference other than the bump to the +really version. > > Please have a look and let me know if you are fine with the > changes. I'm happy to push the bullseye branch I forked from > orthanc debian/1.9.1+dfsg-1 in Salsa if you are okay with it; or > you can just cherry pick the debdiff and make the adjustments I > might have missed if you prefer. > > Just a VCS note if you go the bullseye branch route: it won't > need to be merged back to your main trunk, but will remain > dedicated to the bullseye release life cycle. > > Have a nice day, :) >
