[Git][debian-gis-team/lerc][master] 9 commits: Exclude pre-built binaries

Sebastiaan Couwenberg sebastic at xs4all.nl
Fri Jul 22 08:37:47 BST 2022


On 7/22/22 09:02, Antonio Valentino wrote:
> Il 21/07/22 09:47, Sebastiaan Couwenberg ha scritto:
>> Because of the SONAME bump a transition will be required, hence the 
>> package should be uploaded to experimental first. Once it passes NEW 
>> it won't immediately trigger an uncoordinated transition in unstable. 
>> With the package in experimental, and automatic ben tracker will be 
>> also generated on release.debian.org, so you won't need to include ben 
>> configuration in the transition bugreport (which reportbug still 
>> generates for you).
>>
>> To prepare transitions, you can use the permanent trackers on my ben 
>> instance. It shows tiff to be only rdep which makes rebuild testing 
>> quite easy:
>>
>>   https://linuxminded.nl/debian/gis-transitions/html/lerc.html
>>
>> See also the workflow documented in the transition documentation 
>> linked from the tracker:
>>
>>   https://wiki.debian.org/Teams/ReleaseTeam/Transitions
> 
> Thanks a lot for the guidance.
> Indeed I have never triggered a transition before.
> I still need some time for final checks on the package.
> Also, when the package will be in experimental, probably I will need to 
> update the symbol file for architectures different form amd64.

Yes, you'll need to update the symbols for the other architectures once 
the package in experimental is built at least on all release 
architectures (ports have more limited buildd capacity for experimental).

pkgkde-symbolshelper makes this quite easy:

  # Download buildlogs
  pkgkde-getbuildlogs

  # Update symbols file
  pkgkde-symbolshelper batchpatch -v 4.0.0 lerc_experimental_logs/*

  # Remove missing symbols
  sed -i '/^#MISSING: .*/d' debian/*symbols

  # Commit changes
  dch <-i|-a> "Update symbols for other architectures."
  debcommit -a

> Regarding libtiff I don't know the if it is currently able to build with 
> lerc4. I will check and submit a patch upstream if necessary.

Having the new lerc in experimental makes it much easier for the rdep 
maintainers to test with the new version.

I generally put such packages in my sid+rebuild repo while its in NEW, 
this repo is used by my base-sid-rebuild.cow chroot, and is used in turn 
to rebuild all rdeps:

  pdebuild --pbuilder cowbuilder -- \
           --basepath /var/cache/pbuilder/base-sid+rebuild.cow

For transitions with multiple dependency levels the rebuilt packages get 
included in the sid+rebuild repo too to make them available for the 
rebuilds of the rdeps that also (build) depend on those.

> In any case I will not trigger the transition process if libtiff is not 
> able to build with the new lerc version.

You should keep lerc in experimental until tiff has committed the 
changes required to build successfully with the new lerc.

When filing the transition bugreport you should have it blocked by the 
bugreports filed for the rdeps, that will help the Release Team to 
decide the impact of the transition:

  Control: block -1 by <NNNNNNN>[ <NNNNNNN>]

Since tiff is a key package they won't start the transition until it 
builds successfully with the new lerc.

If you use the experimental branch in git for lerc 4.0.0 you can keep 
using master for any uploads of 3.0 that might be required to fix issues 
reported while the transition to 4.0.0 hasn't started yet.

> Finally I'm wondering why also gdal is not in the rdep list.
> I'm pretty sure that also other drivers, beyond GTIFF,  use lerc.

Because gdal uses the embedded copy:

 
https://salsa.debian.org/debian-gis-team/gdal/-/blob/master/debian/rules#L74

This is default behavior for GDAL, the autotools build did the same 
without any specific LERC configure options:

   LERC support:              internal

https://buildd.debian.org/status/fetch.php?pkg=gdal&arch=amd64&ver=3.4.3%2Bdfsg-1&stamp=1651663546&raw=0

Now that lerc is also packaged separately, we could switch gdal to use 
that instead of the embedded copy.

Kind Regards,

Bas

-- 
  GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1




More information about the Pkg-grass-devel mailing list