[Pkg-samba-maint] debian-only patches break upgrading our python3 bindings (was: Re: Bug#814928: build python3 bindings)

Andrew Bartlett abartlet at samba.org
Sun Apr 3 20:26:51 UTC 2016


On Mon, 2016-04-04 at 07:33 +1200, Andrew Bartlett wrote:
> On Sun, 2016-04-03 at 13:24 +0000, Jelmer Vernooij wrote:
> > On Mon, Apr 04, 2016 at 12:51:00AM +1200, Andrew Bartlett wrote:
> > > On Tue, 2016-02-16 at 18:10 +0100, Matthias Klose wrote:
> > > > Package: src:talloc
> > > > Version: 2.1.5-1
> > > > Tags: patch
> > > > 
> > > > This is a first shot of building python3 bindings for talloc
> > > > (to
> > > > be
> > > > followed up 
> > > > by ldb and tdb bindings).  The packaging certainly can be
> > > > improved,
> > > > making it 
> > > > more robust for version changes. however there is one change
> > > > which
> > > > should be 
> > > > applied upstream: The library *name* for the helper library
> > > > includes
> > > > the whole 
> > > > SOABI name for a python extension, including the multiarch name
> > > > in
> > > > Python 3.5. 
> > > > This leads to different sonames on different architectures.
> > > > Maybe
> > > > this should be 
> > > > fixed so that distros rely on a common name for python3 builds.
> > > 
> > > How important is this? 
> > > 
> > > I ask because it is causing chaos now that we have added new
> > > functions
> > > to the pytalloc-util library.  If we had built with developer
> > > mode,
> > > we
> > > would have noticed it totally breaking the ABI checking, but as
> > > it
> > > is,
> > > we only noticed when upstream (me) added new functions.  (That
> > > triggered the symbols checker in our packaging process.)
> > > 
> > > It causes an empty (essentially) vscript to be written, meaning
> > > all
> > > symbols are regarded as new each release, because other parts of
> > > the
> > > code expected the previous name.
> > > 
> > > https://git.samba.org/?p=samba.git;a=commitdiff;h=9ef47d253179472
> > > 48
> > > b079
> > > 6059e6f0a851ba3cb07
> > > 
> > > For the changes symbols, see 
> > > https://git.samba.org/abartlet/talloc-debi
> > > an.git/?p=abartlet/talloc-debian.git;a=blobdiff;f=debian/python3
> > > -talloc.symbols;h=00fd4296d269ffc6acebeee2c9cb85be8a789813;hp=8bc
> > > 5b
> > > 8487
> > > b809160757bb69f743f282a9e49654b;hb=fa48dc43b7e48662879c0cddaa65ef
> > > de
> > > 7444
> > > 3b6b;hpb=e64cd98c001e05b9c7311b49df010784b25313ae
> > > 
> > > I would prefer to drop this from the package until an acceptable
> > > solution is found upstream.  I've tried changing the
> > > SAMBA_LIBRARY
> > > code
> > > to match, but I still get .py3 and -py3 mixups.  As Fedora is
> > > happy
> > > to
> > > keep the cpython* part of the .so name, I propose we do the same.
> > >  It
> > > is Red Hat staff who have been leading the python3 work, I would
> > > rather
> > > follow them if possible:
> > > 
> > > http://pkgs.fedoraproject.org/cgit/rpms/libtalloc.git/tree/libtal
> > > lo
> > > c.sp
> > > ec#n135
> > > 
> > > It should be safe to revert this in unstable, nobody seems to be
> > > using
> > > this yet.
> > 
> > How about we for the moment:
> > 
> >  * upload a package to experimental that keeps the python3 support
> > in
> >    talloc
> >  * remove python3 support in talloc in unstable
> > 
> > Then we can work out how to name the symbols, without obstructing
> > any
> > of the work for the security release and without risking that the
> > incorrect symbol names end up in a Debian or Ubuntu release.
> 
> Sounds good.

I've uploaded patches to my repo to do exactly this (master removes
python3, experimental just removes the SOABI fix and has the new
version that breaks unpatched Samba < 4.4.0 (and is needed for 4.4).
Let me know what you think.

Thanks,

Andrew Bartlett
-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba






More information about the Pkg-samba-maint mailing list