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
_______________________________________________
Pkg-grass-devel mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-grass-devel
