[PATCHES] Generate shorter name for extra python files

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[PATCHES] Generate shorter name for extra python files

Samba - samba-technical mailing list
ehlo,

Generating different name with different architecture and with the same
version of python is not ideal. pkgconfig files should be architecture
independent and libraries for different architectures are stored in
different directories
 e.g. (/usr/lib64, /usr/lib, /usr/lib/x86_64-linux-gnu/ ...)

Therefore it will be simpler to remove architecture from names
/usr/lib64/pkgconfig/pyldb-util.cpython-36m-x86_64-linux-gnu.pc
vs.
/usr/lib64/pkgconfig/pyldb-util36.pc

LS

short_names.patches (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] Generate shorter name for extra python files

Samba - samba-technical mailing list
Hi Lukas,

> diff --git a/buildtools/wafsamba/samba_python.py b/buildtools/wafsamba/samba_python.py
> index f97439c945b4e986bacef39387cf4168d419e158..bfaf5e6250e0ec17e9d300fc7c839bae769cec1e 100644
> --- a/buildtools/wafsamba/samba_python.py
> +++ b/buildtools/wafsamba/samba_python.py
> @@ -85,10 +85,10 @@ def _check_python_headers(conf, mandatory):
>      if conf.env['PYTHON_VERSION'] > '3':
>          abi_pattern = os.path.splitext(conf.env['pyext_PATTERN'])[0]
>          conf.env['PYTHON_SO_ABI_FLAG'] = abi_pattern % ''
> +        conf.env['PYTHON_LIBNAME_SO_ABI_FLAG'] = conf.env['PYTHON_VERSION']
>      else:
>          conf.env['PYTHON_SO_ABI_FLAG'] = ''
> -    conf.env['PYTHON_LIBNAME_SO_ABI_FLAG'] = (
> -        conf.env['PYTHON_SO_ABI_FLAG'].replace('_', '-'))
> +        conf.env['PYTHON_LIBNAME_SO_ABI_FLAG'] = ''
>  
>      for lib in conf.env['LINKFLAGS_PYEMBED']:
>          if lib.startswith('-L'):
> @@ -170,7 +170,7 @@ Build.BuildContext.SAMBA_PYTHON = SAMBA_PYTHON
>  
>  def pyembed_libname(bld, name, extrapython=False):
>      if bld.env['PYTHON_SO_ABI_FLAG']:
> -        return name + bld.env['PYTHON_SO_ABI_FLAG']
> +        return name + bld.env['PYTHON_VERSION']
>      else:
>          return name
what is conf.env['PYTHON_LIBNAME_SO_ABI_FLAG'] used for?
It's write-only in this patchset.

metze


signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] Generate shorter name for extra python files

Samba - samba-technical mailing list
On (05/07/17 15:34), Stefan Metzmacher via samba-technical wrote:

>Hi Lukas,
>
>> diff --git a/buildtools/wafsamba/samba_python.py b/buildtools/wafsamba/samba_python.py
>> index f97439c945b4e986bacef39387cf4168d419e158..bfaf5e6250e0ec17e9d300fc7c839bae769cec1e 100644
>> --- a/buildtools/wafsamba/samba_python.py
>> +++ b/buildtools/wafsamba/samba_python.py
>> @@ -85,10 +85,10 @@ def _check_python_headers(conf, mandatory):
>>      if conf.env['PYTHON_VERSION'] > '3':
>>          abi_pattern = os.path.splitext(conf.env['pyext_PATTERN'])[0]
>>          conf.env['PYTHON_SO_ABI_FLAG'] = abi_pattern % ''
>> +        conf.env['PYTHON_LIBNAME_SO_ABI_FLAG'] = conf.env['PYTHON_VERSION']
>>      else:
>>          conf.env['PYTHON_SO_ABI_FLAG'] = ''
>> -    conf.env['PYTHON_LIBNAME_SO_ABI_FLAG'] = (
>> -        conf.env['PYTHON_SO_ABI_FLAG'].replace('_', '-'))
>> +        conf.env['PYTHON_LIBNAME_SO_ABI_FLAG'] = ''
>>  
>>      for lib in conf.env['LINKFLAGS_PYEMBED']:
>>          if lib.startswith('-L'):
>> @@ -170,7 +170,7 @@ Build.BuildContext.SAMBA_PYTHON = SAMBA_PYTHON
>>  
>>  def pyembed_libname(bld, name, extrapython=False):
>>      if bld.env['PYTHON_SO_ABI_FLAG']:
>> -        return name + bld.env['PYTHON_SO_ABI_FLAG']
>> +        return name + bld.env['PYTHON_VERSION']
>>      else:
>>          return name
>
>what is conf.env['PYTHON_LIBNAME_SO_ABI_FLAG'] used for?
>It's write-only in this patchset.
>

It is used for generating different name libraries used in python bindings.
And therefore it is also in pkgconfig files

sh$ git grep -n PYTHON_LIBNAME_SO_ABI_FLAG
buildtools/wafsamba/samba_python.py:88:        conf.env['PYTHON_LIBNAME_SO_ABI_FLAG'] = conf.env['PYTHON_VERSION']
buildtools/wafsamba/samba_python.py:91:        conf.env['PYTHON_LIBNAME_SO_ABI_FLAG'] = ''
lib/ldb/pyldb-util.pc.in:11:Libs: @LIB_RPATH@ -L${libdir} -lpyldb-util@PYTHON_LIBNAME_SO_ABI_FLAG@
lib/talloc/pytalloc-util.pc.in:9:Libs: @LIB_RPATH@ -L${libdir} -lpytalloc-util@PYTHON_LIBNAME_SO_ABI_FLAG@

BTW I added author(s) to CC because I would like to know their opinions.

LS

Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] Generate shorter name for extra python files

Samba - samba-technical mailing list
In reply to this post by Samba - samba-technical mailing list
On Wednesday, 5 July 2017 15:26:33 CEST Lukas Slebodnik via samba-technical
wrote:

> ehlo,
>
> Generating different name with different architecture and with the same
> version of python is not ideal. pkgconfig files should be architecture
> independent and libraries for different architectures are stored in
> different directories
>  e.g. (/usr/lib64, /usr/lib, /usr/lib/x86_64-linux-gnu/ ...)
>
> Therefore it will be simpler to remove architecture from names
> /usr/lib64/pkgconfig/pyldb-util.cpython-36m-x86_64-linux-gnu.pc
> vs.
> /usr/lib64/pkgconfig/pyldb-util36.pc
>
> LS

RB+

Could we get new releases for talloc and ldb including this? Also
f5cafee0c7a96396798d2b229ff3f9dced1d74f3 is not part of a release!


        Andreas

--
Andreas Schneider                   GPG-ID: CC014E3D
Samba Team                             [hidden email]
www.samba.org

Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] Generate shorter name for extra python files

Samba - samba-technical mailing list
On Thu, 2017-07-06 at 11:54 +0200, Andreas Schneider wrote:

> On Wednesday, 5 July 2017 15:26:33 CEST Lukas Slebodnik via samba-technical
> wrote:
> > ehlo,
> >
> > Generating different name with different architecture and with the same
> > version of python is not ideal. pkgconfig files should be architecture
> > independent and libraries for different architectures are stored in
> > different directories
> >  e.g. (/usr/lib64, /usr/lib, /usr/lib/x86_64-linux-gnu/ ...)
> >
> > Therefore it will be simpler to remove architecture from names
> > /usr/lib64/pkgconfig/pyldb-util.cpython-36m-x86_64-linux-gnu.pc
> > vs.
> > /usr/lib64/pkgconfig/pyldb-util36.pc
> >
> > LS
>
> RB+
>
> Could we get new releases for talloc and ldb including this? Also
> f5cafee0c7a96396798d2b229ff3f9dced1d74f3 is not part of a release!

I'm a bit nervous about this.  I tried to untangle a mess on Debian in
this area, and ended up abandoning the py3 package for talloc with the
parent commits to this:

https://anonscm.debian.org/cgit/pkg-samba/talloc.git/commit/?id=11a83cac638719df56d8115837f9b8b744d6a69e

I'm not opposed to the idea in the patches, but I'm not sure it is
changing enough, or the right things.  The variables there have become
a tangled mess!

I realise this was 'just' trying to sort out pkgconfig, but we do need
to sort out the ABI upstream, not in Debian etc, but I would love it if
someone else could help me ensure that we could now re-enabled py3 in
debian without hacks and with the right thing happening.  Ideally we
get this changed once, break the ABI once, and get this right.

I think we will need to break the symbol names for pytalloc-util.
(Does this matter?)

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


Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] Generate shorter name for extra python files

Samba - samba-technical mailing list
On Thursday, 6 July 2017 12:14:09 CEST Andrew Bartlett wrote:

> On Thu, 2017-07-06 at 11:54 +0200, Andreas Schneider wrote:
> > On Wednesday, 5 July 2017 15:26:33 CEST Lukas Slebodnik via
> > samba-technical
> >
> > wrote:
> > > ehlo,
> > >
> > > Generating different name with different architecture and with the same
> > > version of python is not ideal. pkgconfig files should be architecture
> > > independent and libraries for different architectures are stored in
> > > different directories
> > >
> > >  e.g. (/usr/lib64, /usr/lib, /usr/lib/x86_64-linux-gnu/ ...)
> > >
> > > Therefore it will be simpler to remove architecture from names
> > > /usr/lib64/pkgconfig/pyldb-util.cpython-36m-x86_64-linux-gnu.pc
> > > vs.
> > > /usr/lib64/pkgconfig/pyldb-util36.pc
> > >
> > > LS
> >
> > RB+
> >
> > Could we get new releases for talloc and ldb including this? Also
> > f5cafee0c7a96396798d2b229ff3f9dced1d74f3 is not part of a release!
>
> I'm a bit nervous about this.  I tried to untangle a mess on Debian in
> this area, and ended up abandoning the py3 package for talloc with the
> parent commits to this:
>
> https://anonscm.debian.org/cgit/pkg-samba/talloc.git/commit/?id=11a83cac6387
> 19df56d8115837f9b8b744d6a69e
>
> I'm not opposed to the idea in the patches, but I'm not sure it is
> changing enough, or the right things.  The variables there have become
> a tangled mess!
>
> I realise this was 'just' trying to sort out pkgconfig, but we do need
> to sort out the ABI upstream, not in Debian etc, but I would love it if
> someone else could help me ensure that we could now re-enabled py3 in
> debian without hacks and with the right thing happening.  Ideally we
> get this changed once, break the ABI once, and get this right.
>
> I think we will need to break the symbol names for pytalloc-util.
> (Does this matter?)

I don't think that python3 is used yet but we need to get it working correctly
for Samba 4.7.


        Andreas

--
Andreas Schneider                   GPG-ID: CC014E3D
Samba Team                             [hidden email]
www.samba.org

Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] Generate shorter name for extra python files

Samba - samba-technical mailing list
In reply to this post by Samba - samba-technical mailing list
On (05/07/17 15:34), Stefan Metzmacher via samba-technical wrote:

>Hi Lukas,
>
>> diff --git a/buildtools/wafsamba/samba_python.py b/buildtools/wafsamba/samba_python.py
>> index f97439c945b4e986bacef39387cf4168d419e158..bfaf5e6250e0ec17e9d300fc7c839bae769cec1e 100644
>> --- a/buildtools/wafsamba/samba_python.py
>> +++ b/buildtools/wafsamba/samba_python.py
>> @@ -85,10 +85,10 @@ def _check_python_headers(conf, mandatory):
>>      if conf.env['PYTHON_VERSION'] > '3':
>>          abi_pattern = os.path.splitext(conf.env['pyext_PATTERN'])[0]
>>          conf.env['PYTHON_SO_ABI_FLAG'] = abi_pattern % ''
>> +        conf.env['PYTHON_LIBNAME_SO_ABI_FLAG'] = conf.env['PYTHON_VERSION']
>>      else:
>>          conf.env['PYTHON_SO_ABI_FLAG'] = ''
>> -    conf.env['PYTHON_LIBNAME_SO_ABI_FLAG'] = (
>> -        conf.env['PYTHON_SO_ABI_FLAG'].replace('_', '-'))
>> +        conf.env['PYTHON_LIBNAME_SO_ABI_FLAG'] = ''
>>  
>>      for lib in conf.env['LINKFLAGS_PYEMBED']:
>>          if lib.startswith('-L'):
>> @@ -170,7 +170,7 @@ Build.BuildContext.SAMBA_PYTHON = SAMBA_PYTHON
>>  
>>  def pyembed_libname(bld, name, extrapython=False):
>>      if bld.env['PYTHON_SO_ABI_FLAG']:
>> -        return name + bld.env['PYTHON_SO_ABI_FLAG']
>> +        return name + bld.env['PYTHON_VERSION']
>>      else:
>>          return name
>
>what is conf.env['PYTHON_LIBNAME_SO_ABI_FLAG'] used for?
>It's write-only in this patchset.
>

BTW PYTHON_LIBNAME_SO_ABI_FLAG is used only for extra python
and therefore pkgconfig file is the same for all architectures with python2
   armv7hl https://koji.fedoraproject.org/koji/rpminfo?rpmID=10112827
   i686    https://koji.fedoraproject.org/koji/rpminfo?rpmID=10112802
   ppc64   https://koji.fedoraproject.org/koji/rpminfo?rpmID=10112787
   ppc64le https://koji.fedoraproject.org/koji/rpminfo?rpmID=10112771
   s390x   https://koji.fedoraproject.org/koji/rpminfo?rpmID=10112816
   x86_64  https://koji.fedoraproject.org/koji/rpminfo?rpmID=10112762
   aarch64 https://koji.fedoraproject.org/koji/rpminfo?rpmID=10112772

and different pkgconfig files with extra python (python3.6)
    armv7hl https://koji.fedoraproject.org/koji/rpminfo?rpmID=10112825
    i686    https://koji.fedoraproject.org/koji/rpminfo?rpmID=10112810
    ppc64   https://koji.fedoraproject.org/koji/rpminfo?rpmID=10112783
    ppc64le https://koji.fedoraproject.org/koji/rpminfo?rpmID=10112764
    s390x   https://koji.fedoraproject.org/koji/rpminfo?rpmID=10112819
    x86_64  https://koji.fedoraproject.org/koji/rpminfo?rpmID=10112760
    aarch64 https://koji.fedoraproject.org/koji/rpminfo?rpmID=10112777

It will be much simpler with this patchset and there still be unique name
for different version of python

/usr/lib64/libpyldb-util3.6.so
/usr/lib64/pkgconfig/pyldb-util3.6.pc

I assume that packagers on debian will appreciate it as well
because they build packages on more architectures.

LS

Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] Generate shorter name for extra python files

Samba - samba-technical mailing list
In reply to this post by Samba - samba-technical mailing list
On (06/07/17 22:14), Andrew Bartlett via samba-technical wrote:

>On Thu, 2017-07-06 at 11:54 +0200, Andreas Schneider wrote:
>> On Wednesday, 5 July 2017 15:26:33 CEST Lukas Slebodnik via samba-technical
>> wrote:
>> > ehlo,
>> >
>> > Generating different name with different architecture and with the same
>> > version of python is not ideal. pkgconfig files should be architecture
>> > independent and libraries for different architectures are stored in
>> > different directories
>> >  e.g. (/usr/lib64, /usr/lib, /usr/lib/x86_64-linux-gnu/ ...)
>> >
>> > Therefore it will be simpler to remove architecture from names
>> > /usr/lib64/pkgconfig/pyldb-util.cpython-36m-x86_64-linux-gnu.pc
>> > vs.
>> > /usr/lib64/pkgconfig/pyldb-util36.pc
>> >
>> > LS
>>
>> RB+
>>
>> Could we get new releases for talloc and ldb including this? Also
>> f5cafee0c7a96396798d2b229ff3f9dced1d74f3 is not part of a release!
>
>I'm a bit nervous about this.  I tried to untangle a mess on Debian in
>this area, and ended up abandoning the py3 package for talloc with the
>parent commits to this:
>
>https://anonscm.debian.org/cgit/pkg-samba/talloc.git/commit/?id=11a83cac638719df56d8115837f9b8b744d6a69e
>
>I'm not opposed to the idea in the patches, but I'm not sure it is
>changing enough, or the right things.  The variables there have become
>a tangled mess!
>
I tent to agree.

>I realise this was 'just' trying to sort out pkgconfig, but we do need
>to sort out the ABI upstream, not in Debian etc, but I would love it if
>someone else could help me ensure that we could now re-enabled py3 in
>debian without hacks and with the right thing happening.  Ideally we
>get this changed once, break the ABI once, and get this right.
>
It solved also libraries and not only pkgconfig files

/usr/lib64/libpyldb-util3.6.so
/usr/lib64/pkgconfig/pyldb-util3.6.pc

And we need to have different name for library because
libpyldb-util3.6.so is linked against python3.6 and have to be used
only by python module for 3.6.

Standard libpyldb-util.so is linked with standard python (usually 2.7)

I am open to another suggestion for names. Maybe libpyldb-util-3.6.so
but that's minimal change.

Could you describe what kind of packaging problems did you have on debian?
It is not obvious for me from that commit.

LS

Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] Generate shorter name for extra python files

Samba - samba-technical mailing list
On Thu, 2017-07-06 at 12:28 +0200, Lukas Slebodnik wrote:

> On (06/07/17 22:14), Andrew Bartlett via samba-technical wrote:
> > On Thu, 2017-07-06 at 11:54 +0200, Andreas Schneider wrote:
> > > On Wednesday, 5 July 2017 15:26:33 CEST Lukas Slebodnik via samba-technical
> > > wrote:
> > > > ehlo,
> > > >
> > > > Generating different name with different architecture and with the same
> > > > version of python is not ideal. pkgconfig files should be architecture
> > > > independent and libraries for different architectures are stored in
> > > > different directories
> > > >  e.g. (/usr/lib64, /usr/lib, /usr/lib/x86_64-linux-gnu/ ...)
> > > >
> > > > Therefore it will be simpler to remove architecture from names
> > > > /usr/lib64/pkgconfig/pyldb-util.cpython-36m-x86_64-linux-gnu.pc
> > > > vs.
> > > > /usr/lib64/pkgconfig/pyldb-util36.pc
> > > >
> > > > LS
> > >
> > > RB+
> > >
> > > Could we get new releases for talloc and ldb including this? Also
> > > f5cafee0c7a96396798d2b229ff3f9dced1d74f3 is not part of a release!
> >
> > I'm a bit nervous about this.  I tried to untangle a mess on Debian in
> > this area, and ended up abandoning the py3 package for talloc with the
> > parent commits to this:
> >
> > https://anonscm.debian.org/cgit/pkg-samba/talloc.git/commit/?id=11a83cac638719df56d8115837f9b8b744d6a69e
> >
> > I'm not opposed to the idea in the patches, but I'm not sure it is
> > changing enough, or the right things.  The variables there have become
> > a tangled mess!
> >
>
> I tent to agree.
>
> > I realise this was 'just' trying to sort out pkgconfig, but we do need
> > to sort out the ABI upstream, not in Debian etc, but I would love it if
> > someone else could help me ensure that we could now re-enabled py3 in
> > debian without hacks and with the right thing happening.  Ideally we
> > get this changed once, break the ABI once, and get this right.
> >
>
> It solved also libraries and not only pkgconfig files
>
> /usr/lib64/libpyldb-util3.6.so
> /usr/lib64/pkgconfig/pyldb-util3.6.pc
>
> And we need to have different name for library because
> libpyldb-util3.6.so is linked against python3.6 and have to be used
> only by python module for 3.6.
>
> Standard libpyldb-util.so is linked with standard python (usually 2.7)
>
> I am open to another suggestion for names. Maybe libpyldb-util-3.6.so
> but that's minimal change.
>
> Could you describe what kind of packaging problems did you have on debian?
> It is not obvious for me from that commit.

Here is the thread:

https://lists.alioth.debian.org/pipermail/pkg-samba-maint/2016-April/018139.html

It looks like I suggested following Fedora, so I'll generally stick to
that position.

When reading the thread and trying to read symbol versions, remember
the mail archiver has changed @ to _at_ just to confuse you/spammers.

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


Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] Generate shorter name for extra python files

Samba - samba-technical mailing list
On (06/07/17 22:44), Andrew Bartlett wrote:

>On Thu, 2017-07-06 at 12:28 +0200, Lukas Slebodnik wrote:
>> On (06/07/17 22:14), Andrew Bartlett via samba-technical wrote:
>> > On Thu, 2017-07-06 at 11:54 +0200, Andreas Schneider wrote:
>> > > On Wednesday, 5 July 2017 15:26:33 CEST Lukas Slebodnik via samba-technical
>> > > wrote:
>> > > > ehlo,
>> > > >
>> > > > Generating different name with different architecture and with the same
>> > > > version of python is not ideal. pkgconfig files should be architecture
>> > > > independent and libraries for different architectures are stored in
>> > > > different directories
>> > > >  e.g. (/usr/lib64, /usr/lib, /usr/lib/x86_64-linux-gnu/ ...)
>> > > >
>> > > > Therefore it will be simpler to remove architecture from names
>> > > > /usr/lib64/pkgconfig/pyldb-util.cpython-36m-x86_64-linux-gnu.pc
>> > > > vs.
>> > > > /usr/lib64/pkgconfig/pyldb-util36.pc
>> > > >
>> > > > LS
>> > >
>> > > RB+
>> > >
>> > > Could we get new releases for talloc and ldb including this? Also
>> > > f5cafee0c7a96396798d2b229ff3f9dced1d74f3 is not part of a release!
>> >
>> > I'm a bit nervous about this.  I tried to untangle a mess on Debian in
>> > this area, and ended up abandoning the py3 package for talloc with the
>> > parent commits to this:
>> >
>> > https://anonscm.debian.org/cgit/pkg-samba/talloc.git/commit/?id=11a83cac638719df56d8115837f9b8b744d6a69e
>> >
>> > I'm not opposed to the idea in the patches, but I'm not sure it is
>> > changing enough, or the right things.  The variables there have become
>> > a tangled mess!
>> >
>>
>> I tent to agree.
>>
>> > I realise this was 'just' trying to sort out pkgconfig, but we do need
>> > to sort out the ABI upstream, not in Debian etc, but I would love it if
>> > someone else could help me ensure that we could now re-enabled py3 in
>> > debian without hacks and with the right thing happening.  Ideally we
>> > get this changed once, break the ABI once, and get this right.
>> >
>>
>> It solved also libraries and not only pkgconfig files
>>
>> /usr/lib64/libpyldb-util3.6.so
>> /usr/lib64/pkgconfig/pyldb-util3.6.pc
>>
>> And we need to have different name for library because
>> libpyldb-util3.6.so is linked against python3.6 and have to be used
>> only by python module for 3.6.
>>
>> Standard libpyldb-util.so is linked with standard python (usually 2.7)
>>
>> I am open to another suggestion for names. Maybe libpyldb-util-3.6.so
>> but that's minimal change.
>>
>> Could you describe what kind of packaging problems did you have on debian?
>> It is not obvious for me from that commit.
>
>Here is the thread:
>
>https://lists.alioth.debian.org/pipermail/pkg-samba-maint/2016-April/018139.html
>
>It looks like I suggested following Fedora, so I'll generally stick to
>that position.
>
>When reading the thread and trying to read symbol versions, remember
>the mail archiver has changed @ to _at_ just to confuse you/spammers.
>

Most of the thread there was discussion about changed version symbols
in library which is not related to python3 work.

The only think which I do not understand is following sentence
  "I've tried changing the SAMBA_LIBRARY code
   to match, but I still get .py3 and -py3 mixups"

And I do not think that was solved by this patchset.

LS

Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] Generate shorter name for extra python files

Samba - samba-technical mailing list
On Thu, 2017-07-06 at 13:52 +0200, Lukas Slebodnik wrote:

> On (06/07/17 22:44), Andrew Bartlett wrote:
> > On Thu, 2017-07-06 at 12:28 +0200, Lukas Slebodnik wrote:
> > >
> > > It solved also libraries and not only pkgconfig files
> > >
> > > /usr/lib64/libpyldb-util3.6.so
> > > /usr/lib64/pkgconfig/pyldb-util3.6.pc
> > >
> > > And we need to have different name for library because
> > > libpyldb-util3.6.so is linked against python3.6 and have to be
> > > used
> > > only by python module for 3.6.
> > >
> > > Standard libpyldb-util.so is linked with standard python (usually
> > > 2.7)
> > >
> > > I am open to another suggestion for names. Maybe libpyldb-util-
> > > 3.6.so
> > > but that's minimal change.
> > >
> > > Could you describe what kind of packaging problems did you have
> > > on debian?
> > > It is not obvious for me from that commit.
> >
> > Here is the thread:
> >
> > https://lists.alioth.debian.org/pipermail/pkg-samba-maint/2016-Apri
> > l/018139.html
> >
> > It looks like I suggested following Fedora, so I'll generally stick
> > to
> > that position.
> >
> > When reading the thread and trying to read symbol versions,
> > remember
> > the mail archiver has changed @ to _at_ just to confuse
> > you/spammers.
> >
>
> Most of the thread there was discussion about changed version symbols
> in library which is not related to python3 work.

No, it is very related.  That is my point.  Debian was trying to work
around the same things, but it ended badly.  We need to solve it all,
not just bits of it.

> The only think which I do not understand is following sentence
>   "I've tried changing the SAMBA_LIBRARY code
>    to match, but I still get .py3 and -py3 mixups"
>
> And I do not think that was solved by this patchset.

OK.  Please continue working until it is.

The things we need:

Remove both cpython-35m-x86_64-linux-gnu and 3.5 from
 - ABI/*.sigs files

Then remove at least the cpython-* stuff from
 - the pkgconfig files
 - the installed library names

I'm not sure what to do with the .vscript files

The problem with the current patch is that it now puts more version
info in than we had before, the Samba ABI/*.sigs files are now being
generated per python version.

Sorry,

Andrew Bartlett


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





Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] Generate shorter name for extra python files

Samba - samba-technical mailing list
On (07/07/17 10:18), Andrew Bartlett wrote:

>On Thu, 2017-07-06 at 13:52 +0200, Lukas Slebodnik wrote:
>> On (06/07/17 22:44), Andrew Bartlett wrote:
>> > On Thu, 2017-07-06 at 12:28 +0200, Lukas Slebodnik wrote:
>> > >
>> > > It solved also libraries and not only pkgconfig files
>> > >
>> > > /usr/lib64/libpyldb-util3.6.so
>> > > /usr/lib64/pkgconfig/pyldb-util3.6.pc
>> > >
>> > > And we need to have different name for library because
>> > > libpyldb-util3.6.so is linked against python3.6 and have to be
>> > > used
>> > > only by python module for 3.6.
>> > >
>> > > Standard libpyldb-util.so is linked with standard python (usually
>> > > 2.7)
>> > >
>> > > I am open to another suggestion for names. Maybe libpyldb-util-
>> > > 3.6.so
>> > > but that's minimal change.
>> > >
>> > > Could you describe what kind of packaging problems did you have
>> > > on debian?
>> > > It is not obvious for me from that commit.
>> >
>> > Here is the thread:
>> >
>> > https://lists.alioth.debian.org/pipermail/pkg-samba-maint/2016-Apri
>> > l/018139.html
>> >
>> > It looks like I suggested following Fedora, so I'll generally stick
>> > to
>> > that position.
>> >
>> > When reading the thread and trying to read symbol versions,
>> > remember
>> > the mail archiver has changed @ to _at_ just to confuse
>> > you/spammers.
>> >
>>
>> Most of the thread there was discussion about changed version symbols
>> in library which is not related to python3 work.
>
>No, it is very related.  That is my point.  Debian was trying to work
>around the same things, but it ended badly.  We need to solve it all,
>not just bits of it.
>
>> The only think which I do not understand is following sentence
>>   "I've tried changing the SAMBA_LIBRARY code
>>    to match, but I still get .py3 and -py3 mixups"
>>
>> And I do not think that was solved by this patchset.
>
>OK.  Please continue working until it is.
>
>The things we need:
>
>Remove both cpython-35m-x86_64-linux-gnu and 3.5 from
> - ABI/*.sigs files
>

I am not sure whether I understand problem correctly.

Here is an output of objdump with **my patches**.
SONAME is obviously different.

[root@e71533851f88 ~]# objdump -p /usr/lib64/libpyldb-util.so | grep SONAME
  SONAME               libpyldb-util.so.1
[root@e71533851f88 ~]# objdump -p /usr/lib64/libpyldb-util3.5.so | grep SONAME
  SONAME               libpyldb-util3.5.so.1


Python3 version of library libpyldb-util has only version from 1.2.0
Python2 version of library libpyldb-util has all version since 1.1.2

[root@e71533851f88 ~]# objdump -p /usr/lib64/libpyldb-util3.5.so | sed -ne '/Version definitions/,/Version References/p'
Version definitions:
1 0x01 0x0c4f47b1 libpyldb-util3.5.so.1
2 0x00 0x064f6b10 PYLDB_UTIL3.5_1.2.0

Version References:
[root@e71533851f88 ~]# objdump -p /usr/lib64/libpyldb-util.so | sed -ne '/Version definitions/,/Version References/p'
Version definitions:
1 0x01 0x0a7956b1 libpyldb-util.so.1
2 0x00 0x0aa3e6f2 PYLDB_UTIL_1.1.2
3 0x02 0x0aa3e6f3 PYLDB_UTIL_1.1.3
        PYLDB_UTIL_1.1.2
4 0x02 0x0aa3e6f4 PYLDB_UTIL_1.1.4
        PYLDB_UTIL_1.1.3
5 0x02 0x0aa3e6f5 PYLDB_UTIL_1.1.5
        PYLDB_UTIL_1.1.4
6 0x02 0x0aa3e6f6 PYLDB_UTIL_1.1.6
        PYLDB_UTIL_1.1.5
7 0x02 0x0aa3e6f7 PYLDB_UTIL_1.1.7
        PYLDB_UTIL_1.1.6
8 0x02 0x0aa3e6f8 PYLDB_UTIL_1.1.8
        PYLDB_UTIL_1.1.7
9 0x02 0x0aa3e6f9 PYLDB_UTIL_1.1.9
        PYLDB_UTIL_1.1.8
10 0x02 0x0a3e6fe0 PYLDB_UTIL_1.1.10
        PYLDB_UTIL_1.1.9
11 0x02 0x0a3e6fe1 PYLDB_UTIL_1.1.11
        PYLDB_UTIL_1.1.10
12 0x02 0x0a3e6fe2 PYLDB_UTIL_1.1.12
        PYLDB_UTIL_1.1.11
13 0x02 0x0a3e6fe3 PYLDB_UTIL_1.1.13
        PYLDB_UTIL_1.1.12
14 0x02 0x0a3e6fe4 PYLDB_UTIL_1.1.14
        PYLDB_UTIL_1.1.13
15 0x02 0x0a3e6fe5 PYLDB_UTIL_1.1.15
        PYLDB_UTIL_1.1.14
16 0x02 0x0a3e6fe6 PYLDB_UTIL_1.1.16
        PYLDB_UTIL_1.1.15
17 0x02 0x0a3e6fe7 PYLDB_UTIL_1.1.17
        PYLDB_UTIL_1.1.16
18 0x02 0x0a3e6fe8 PYLDB_UTIL_1.1.18
        PYLDB_UTIL_1.1.17
19 0x02 0x0a3e6fe9 PYLDB_UTIL_1.1.19
        PYLDB_UTIL_1.1.18
20 0x02 0x0a3e6ff0 PYLDB_UTIL_1.1.20
        PYLDB_UTIL_1.1.19
21 0x02 0x0a3e6ff1 PYLDB_UTIL_1.1.21
        PYLDB_UTIL_1.1.20
22 0x02 0x0a3e6ff2 PYLDB_UTIL_1.1.22
        PYLDB_UTIL_1.1.21
23 0x02 0x0a3e6ff3 PYLDB_UTIL_1.1.23
        PYLDB_UTIL_1.1.22
24 0x02 0x0a3e6ff4 PYLDB_UTIL_1.1.24
        PYLDB_UTIL_1.1.23
25 0x02 0x0a3e6ff5 PYLDB_UTIL_1.1.25
        PYLDB_UTIL_1.1.24
26 0x02 0x0a3e6ff6 PYLDB_UTIL_1.1.26
        PYLDB_UTIL_1.1.25
27 0x02 0x0a3e6ff7 PYLDB_UTIL_1.1.27
        PYLDB_UTIL_1.1.26
28 0x02 0x0a3e6ff8 PYLDB_UTIL_1.1.28
        PYLDB_UTIL_1.1.27
29 0x02 0x0a3e6ff9 PYLDB_UTIL_1.1.29
        PYLDB_UTIL_1.1.28
30 0x02 0x0a3e6fc0 PYLDB_UTIL_1.1.30
        PYLDB_UTIL_1.1.29
31 0x02 0x0a3e6fc1 PYLDB_UTIL_1.1.31
        PYLDB_UTIL_1.1.30
32 0x00 0x0aa3e3f0 PYLDB_UTIL_1.2.0

Version References:

[root@e71533851f88 ~]# objdump -T /usr/lib64/libpyldb-util.so | grep PYLDB_UTIL | sort
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.10 PYLDB_UTIL_1.1.10
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.11 PYLDB_UTIL_1.1.11
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.12 PYLDB_UTIL_1.1.12
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.13 PYLDB_UTIL_1.1.13
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.14 PYLDB_UTIL_1.1.14
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.15 PYLDB_UTIL_1.1.15
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.16 PYLDB_UTIL_1.1.16
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.17 PYLDB_UTIL_1.1.17
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.18 PYLDB_UTIL_1.1.18
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.19 PYLDB_UTIL_1.1.19
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.2 PYLDB_UTIL_1.1.2
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.20 PYLDB_UTIL_1.1.20
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.21 PYLDB_UTIL_1.1.21
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.22 PYLDB_UTIL_1.1.22
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.23 PYLDB_UTIL_1.1.23
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.24 PYLDB_UTIL_1.1.24
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.25 PYLDB_UTIL_1.1.25
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.26 PYLDB_UTIL_1.1.26
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.27 PYLDB_UTIL_1.1.27
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.28 PYLDB_UTIL_1.1.28
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.29 PYLDB_UTIL_1.1.29
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.3 PYLDB_UTIL_1.1.3
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.30 PYLDB_UTIL_1.1.30
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.31 PYLDB_UTIL_1.1.31
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.4 PYLDB_UTIL_1.1.4
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.5 PYLDB_UTIL_1.1.5
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.6 PYLDB_UTIL_1.1.6
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.7 PYLDB_UTIL_1.1.7
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.8 PYLDB_UTIL_1.1.8
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.1.9 PYLDB_UTIL_1.1.9
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL_1.2.0 PYLDB_UTIL_1.2.0
00000000000014c0 g    DF .text  00000000000000c4  PYLDB_UTIL_1.1.2 pyldb_Object_AsDn
0000000000001590 g    DF .text  0000000000000081  PYLDB_UTIL_1.1.2 pyldb_Dn_FromDn
[root@e71533851f88 ~]# objdump -T /usr/lib64/libpyldb-util3.5.so | grep PYLDB_UTIL | sort
0000000000000000 g    DO *ABS*  0000000000000000  PYLDB_UTIL3.5_1.2.0 PYLDB_UTIL3.5_1.2.0
0000000000000b00 g    DF .text  00000000000000e4  PYLDB_UTIL3.5_1.2.0 pyldb_Object_AsDn
0000000000000bf0 g    DF .text  0000000000000081  PYLDB_UTIL3.5_1.2.0 pyldb_Dn_FromDn


I am not really sure how are symbols generated in libldb with waf
from files in directory lib/ldb/ABI/ because I am used to different definition
of version symbols in libraries http://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_25.html
But IIRC it does not work on all UNIX like systems which are supported by samba.

Could you describe what is a problematic? Why it is problematic?
And how it should look like?


>Then remove at least the cpython-* stuff from
> - the pkgconfig files
> - the installed library names
>
Already done in patchset

[root@e71533851f88 ~]# cat /usr/lib64/pkgconfig/pyldb-util
pyldb-util.pc     pyldb-util3.5.pc  
[root@e71533851f88 ~]# cat /usr/lib64/pkgconfig/pyldb-util*
prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib64
includedir=${prefix}/include
modulesdir=${prefix}/lib64/ldb/modules/ldb

Name: pyldb-util2.7
Description: Python bindings for LDB
Version: 1.2.0
Requires: ldb
Libs:  -L${libdir} -lpyldb-util
Cflags: -I${includedir}
URL: http://ldb.samba.org/
prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib64
includedir=${prefix}/include
modulesdir=${prefix}/lib64/ldb/modules/ldb

Name: pyldb-util3.5
Description: Python bindings for LDB
Version: 1.2.0
Requires: ldb
Libs:  -L${libdir} -lpyldb-util3.5
Cflags: -I${includedir}
URL: http://ldb.samba.org/


>I'm not sure what to do with the .vscript files
>
>The problem with the current patch is that it now puts more version
>info in than we had before, the Samba ABI/*.sigs files are now being
>generated per python version.
>

And you would like to remove dumplication of files. Is it correct?
sh$ ls lib/ldb/ABI/pyldb-util*
lib/ldb/ABI/pyldb-util-1.1.10.sigs  lib/ldb/ABI/pyldb-util-1.1.30.sigs
lib/ldb/ABI/pyldb-util-1.1.11.sigs  lib/ldb/ABI/pyldb-util-1.1.31.sigs
lib/ldb/ABI/pyldb-util-1.1.12.sigs  lib/ldb/ABI/pyldb-util-1.1.3.sigs
lib/ldb/ABI/pyldb-util-1.1.13.sigs  lib/ldb/ABI/pyldb-util-1.1.4.sigs
lib/ldb/ABI/pyldb-util-1.1.14.sigs  lib/ldb/ABI/pyldb-util-1.1.5.sigs
lib/ldb/ABI/pyldb-util-1.1.15.sigs  lib/ldb/ABI/pyldb-util-1.1.6.sigs
lib/ldb/ABI/pyldb-util-1.1.16.sigs  lib/ldb/ABI/pyldb-util-1.1.7.sigs
lib/ldb/ABI/pyldb-util-1.1.17.sigs  lib/ldb/ABI/pyldb-util-1.1.8.sigs
lib/ldb/ABI/pyldb-util-1.1.18.sigs  lib/ldb/ABI/pyldb-util-1.1.9.sigs
lib/ldb/ABI/pyldb-util-1.1.19.sigs  lib/ldb/ABI/pyldb-util-1.2.0.sigs
lib/ldb/ABI/pyldb-util-1.1.20.sigs  lib/ldb/ABI/pyldb-util.py3-1.1.23.sigs
lib/ldb/ABI/pyldb-util-1.1.21.sigs  lib/ldb/ABI/pyldb-util.py3-1.1.24.sigs
lib/ldb/ABI/pyldb-util-1.1.22.sigs  lib/ldb/ABI/pyldb-util.py3-1.1.25.sigs
lib/ldb/ABI/pyldb-util-1.1.23.sigs  lib/ldb/ABI/pyldb-util.py3-1.1.26.sigs
lib/ldb/ABI/pyldb-util-1.1.24.sigs  lib/ldb/ABI/pyldb-util.py3-1.1.27.sigs
lib/ldb/ABI/pyldb-util-1.1.25.sigs  lib/ldb/ABI/pyldb-util.py3-1.1.28.sigs
lib/ldb/ABI/pyldb-util-1.1.26.sigs  lib/ldb/ABI/pyldb-util.py3-1.1.29.sigs
lib/ldb/ABI/pyldb-util-1.1.27.sigs  lib/ldb/ABI/pyldb-util.py3-1.1.30.sigs
lib/ldb/ABI/pyldb-util-1.1.28.sigs  lib/ldb/ABI/pyldb-util.py3-1.1.31.sigs
lib/ldb/ABI/pyldb-util-1.1.29.sigs  lib/ldb/ABI/pyldb-util.py3-1.2.0.sigs
lib/ldb/ABI/pyldb-util-1.1.2.sigs

Could you point me to the code where these files are processed?

LS

Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] Generate shorter name for extra python files

Samba - samba-technical mailing list
On (07/07/17 14:30), Lukas Slebodnik via samba-technical wrote:

>On (07/07/17 10:18), Andrew Bartlett wrote:
>>OK.  Please continue working until it is.
>>
>>The things we need:
>>
>>Remove both cpython-35m-x86_64-linux-gnu and 3.5 from
>> - ABI/*.sigs files
>>
>
>I am not really sure how are symbols generated in libldb with waf
>from files in directory lib/ldb/ABI/ because I am used to different definition
>of version symbols in libraries http://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_25.html
>But IIRC it does not work on all UNIX like systems which are supported by samba.
>

I played a little bit with waf and python debuger (pdb)
And I found how and where is version script(vscript) generated.


>Could you describe what is a problematic? Why it is problematic?
>And how it should look like?
>

I just would like to know what is problematic for libpyldb-util generated from
standard python and for extra python.

LS

Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] Generate shorter name for extra python files

Samba - samba-technical mailing list
On Sat, 2017-07-08 at 21:16 +0200, Lukas Slebodnik wrote:

> On (07/07/17 14:30), Lukas Slebodnik via samba-technical wrote:
> > On (07/07/17 10:18), Andrew Bartlett wrote:
> > > OK.  Please continue working until it is.
> > >
> > > The things we need:
> > >
> > > Remove both cpython-35m-x86_64-linux-gnu and 3.5 from
> > > - ABI/*.sigs files
> > >
> >
> > I am not really sure how are symbols generated in libldb with waf
> > from files in directory lib/ldb/ABI/ because I am used to different definition
> > of version symbols in libraries http://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_25.html
> > But IIRC it does not work on all UNIX like systems which are supported by samba.
> >
>
> I played a little bit with waf and python debuger (pdb)
> And I found how and where is version script(vscript) generated.
>
>
> > Could you describe what is a problematic? Why it is problematic?
> > And how it should look like?
> >
>
> I just would like to know what is problematic for libpyldb-util generated from
> standard python and for extra python.

The ABI files, which we use in Samba to check when we add new symbols
or change function arguments, need not to be dependent on python
versions, as Samba developers have multiple python3 versions installed,
but we only want one ABI file.

However, the vscript and the generated library needs to be python
version specific.

The old code did this by removing the cpython... string from the ABI
file and symbol names before writing the file.  You need to (carefully,
as it is now a shorter and less unique string) do the same.

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


Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] Generate shorter name for extra python files

Samba - samba-technical mailing list
On (10/07/17 08:33), Andrew Bartlett via samba-technical wrote:

>On Sat, 2017-07-08 at 21:16 +0200, Lukas Slebodnik wrote:
>> On (07/07/17 14:30), Lukas Slebodnik via samba-technical wrote:
>> > On (07/07/17 10:18), Andrew Bartlett wrote:
>> > > OK.  Please continue working until it is.
>> > >
>> > > The things we need:
>> > >
>> > > Remove both cpython-35m-x86_64-linux-gnu and 3.5 from
>> > > - ABI/*.sigs files
>> > >
>> >
>> > I am not really sure how are symbols generated in libldb with waf
>> > from files in directory lib/ldb/ABI/ because I am used to different definition
>> > of version symbols in libraries http://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_25.html
>> > But IIRC it does not work on all UNIX like systems which are supported by samba.
>> >
>>
>> I played a little bit with waf and python debuger (pdb)
>> And I found how and where is version script(vscript) generated.
>>
>>
>> > Could you describe what is a problematic? Why it is problematic?
>> > And how it should look like?
>> >
>>
>> I just would like to know what is problematic for libpyldb-util generated from
>> standard python and for extra python.
>
>The ABI files, which we use in Samba to check when we add new symbols
>or change function arguments, need not to be dependent on python
>versions, as Samba developers have multiple python3 versions installed,
>but we only want one ABI file.
>
>However, the vscript and the generated library needs to be python
>version specific.
>
>The old code did this by removing the cpython... string from the ABI
>file and symbol names before writing the file.  You need to (carefully,
>as it is now a shorter and less unique string) do the same.
>
Here you are.

LS

short_names_v2.patches (25K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] Generate shorter name for extra python files

Samba - samba-technical mailing list
On Tue, 2017-07-11 at 10:50 +0200, Lukas Slebodnik wrote:

>
> > The ABI files, which we use in Samba to check when we add new symbols
> > or change function arguments, need not to be dependent on python
> > versions, as Samba developers have multiple python3 versions installed,
> > but we only want one ABI file.
> >
> > However, the vscript and the generated library needs to be python
> > version specific.
> >
> > The old code did this by removing the cpython... string from the ABI
> > file and symbol names before writing the file.  You need to (carefully,
> > as it is now a shorter and less unique string) do the same.
> >
>
> Here you are.

Is it safe to assert that we won't change the ABI with an IS_PYTHON3 or
similar macro?

If so, then these are OK (in that respect, I've not done a full
review), but if it is likely that we will add python3 only helper
functions to one or other of the py*-util libraries, then we need to
keep the distinct ABI files for 2 and 3, but not for 3.5, 3.6 et al.

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


Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] Generate shorter name for extra python files

Samba - samba-technical mailing list
On (14/07/17 08:43), Andrew Bartlett wrote:

>On Tue, 2017-07-11 at 10:50 +0200, Lukas Slebodnik wrote:
>>
>> > The ABI files, which we use in Samba to check when we add new symbols
>> > or change function arguments, need not to be dependent on python
>> > versions, as Samba developers have multiple python3 versions installed,
>> > but we only want one ABI file.
>> >
>> > However, the vscript and the generated library needs to be python
>> > version specific.
>> >
>> > The old code did this by removing the cpython... string from the ABI
>> > file and symbol names before writing the file.  You need to (carefully,
>> > as it is now a shorter and less unique string) do the same.
>> >
>>
>> Here you are.
>
>Is it safe to assert that we won't change the ABI with an IS_PYTHON3 or
>similar macro?
>

py*-util libraries are helper functions for python bindings. And new functions
are added there very rarely. (btw tevent and tdb does not need such libraries).

And these helper libraries will be used just by python bindings.
And IIUC python guarantee ABI in minor release (e.g. 3.4.*)
This is a reaon why there will be different version of library for different
python (2.6, 2.7, 3.5, 3.6 ...) But I am not python developer/mantainer.
Adding Petr Viktorin to CC

>If so, then these are OK (in that respect, I've not done a full
>review), but if it is likely that we will add python3 only helper
>functions to one or other of the py*-util libraries, then we need to
>keep the distinct ABI files for 2 and 3, but not for 3.5, 3.6 et al.
>

In theory, that could be solved with extra glob
"p?y?3?-" + $old_glob.

Thank you very much for review.

Sorry for duplicate mail I accidentally removed samba-technical from CC.

LS

Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] Generate shorter name for extra python files

Samba - samba-technical mailing list
In reply to this post by Samba - samba-technical mailing list
Hi,

as this will take a bit to discuss, I'll prepare new talloc, tevent
and ldb releases without this.

We need an ldb release for 4.7.0rc3 which is planed for next Tuesday.

metze

Am 13.07.2017 um 22:43 schrieb Andrew Bartlett via samba-technical:

> On Tue, 2017-07-11 at 10:50 +0200, Lukas Slebodnik wrote:
>>
>>> The ABI files, which we use in Samba to check when we add new symbols
>>> or change function arguments, need not to be dependent on python
>>> versions, as Samba developers have multiple python3 versions installed,
>>> but we only want one ABI file.
>>>
>>> However, the vscript and the generated library needs to be python
>>> version specific.
>>>
>>> The old code did this by removing the cpython... string from the ABI
>>> file and symbol names before writing the file.  You need to (carefully,
>>> as it is now a shorter and less unique string) do the same.
>>>
>>
>> Here you are.
>
> Is it safe to assert that we won't change the ABI with an IS_PYTHON3 or
> similar macro?
>
> If so, then these are OK (in that respect, I've not done a full
> review), but if it is likely that we will add python3 only helper
> functions to one or other of the py*-util libraries, then we need to
> keep the distinct ABI files for 2 and 3, but not for 3.5, 3.6 et al.
>
> Andrew Bartlett
>


signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] Generate shorter name for extra python files

Samba - samba-technical mailing list
On (21/07/17 14:39), Stefan Metzmacher wrote:
>Hi,
>
>as this will take a bit to discuss, I'll prepare new talloc, tevent
>and ldb releases without this.
>
>We need an ldb release for 4.7.0rc3 which is planed for next Tuesday.
>

I thought I answer all questions and Abrew wrote that:
"(in that respect, I've not done a full review)"

I am not sure how to move this forward. Or where is a problem.
But I would really appreciate solution which works for upstream
and all downstream debian, fedora ...

LS

Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] Generate shorter name for extra python files

Samba - samba-technical mailing list
Hi Lukas,

>> as this will take a bit to discuss, I'll prepare new talloc, tevent
>> and ldb releases without this.
>>
>> We need an ldb release for 4.7.0rc3 which is planed for next Tuesday.
>>
>
> I thought I answer all questions and Abrew wrote that:
> "(in that respect, I've not done a full review)"
>
> I am not sure how to move this forward. Or where is a problem.
> But I would really appreciate solution which works for upstream
> and all downstream debian, fedora ...
It's just time, some people are/will be on vacation, so it takes a bit
of time to have a solid solution.

We should not rush this into the release on Thursday. There will
be at least 1 or 2 rc's before 4.7.0.

But the most important thing is that we should not add a solution
to ldb-1.2.1, which we than have to revert for ldb-1.2.2.

Thanks in advance for your patience.
metze



signature.asc (853 bytes) Download Attachment
12