[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Static linking without using a Built-Using attribute



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,  :)
> 


Reply to: